Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
11.5 Class–responsibility–collaborator cards 145 We shall see how the game software can be considerably simplified by making use of inheritance. 11.4 ● Using the library OOP is often called programming by extending the library because the libraries provided along with OO languages are so rich and so reusable. An organization will often also create its own library of classes that have been created in earlier projects. There are two distinct ways of using classes in a library: 1. creating objects from classes in the library 2. defining new classes by extending (inheriting from) classes in the library. For example, in designing the game program, we expect the library to provide classes that implement buttons and a panel – along with classes that support the event handling associated with these widgets. For example in the Java library we can use the Button class directly, by creating button objects as instances of the Button class: Button button = new Button("start"); The Java library also provides classes and methods that display the graphical images that the program uses. Another way in which the library is commonly used is to form new classes by inheritance. It is worthwhile looking in the library at the outset of design and then again at every stage of design, in case something useful can be incorporated into the design. This takes some self-discipline because it is tempting to write a method again, rather than develop an understanding of someone else’s code. 11.5 ● Class–responsibility–collaborator cards Class–responsibility–collaborator (CRC) cards are a way of helping to carry out OOD. The technique uses ordinary index cards, made out of cardboard and widely available. Each card describes an individual class as shown by the example of the Alien class in Figure 11.3. The designer begins by writing the class name at the head of the card. Then one area lists the methods provided by the class (its responsibilities). For the class Alien, these are move, display, etc. A second area lists the classes that use this class and the classes that are used by this class (the collaborators). For the class Alien, there is only one, the library class Graphics that supports displaying graphical images. The cards representing the constituent classes are placed on a table. This way the cards can be moved around easily; their interrelationships can be visualized and adjusted as necessary. CRC cards offer advantages as compared with a software tool. They are cheap, readily available and portable. Several people can easily collaborate, standing round the
146 Chapter 11 ■ Object-oriented design Class name: Alien Responsibilities Collaborators moves Graphics displays itself provides its x coordinate provides its y coordinate provides its height provides its width Figure 11.3 A Sample CRC card – the class Alien in the cyberspace invaders game table. It seems that the act of physically handling the cards contributes to an improved understanding of the structure of the software. 11.6 ● Iteration Iteration is a crucial ingredient of OOD. This is because there is no guaranteed formula for finding the right set of objects to model a problem. Therefore the process is exploratory and iterative; it is common for classes to be initially proposed during a design but subsequently be discarded as the design progresses. Similarly, the need for some classes will not emerge until the implementation (coding) stage. During each iteration, the design is refined and reanalyzed continuously. Indeed, whereas design and implementation are considered largely distinct activities in traditional software development, using the object-oriented paradigm the two activities are often indistinguishable. There are a number of reasons for this, which we will now discuss: Prototyping is seen as an integral part of the object-oriented software design and implementation process. Prototyping recognizes that in most cases the requirements for a system are at best vague or not well understood. It is an exploratory process providing early validation (or otherwise) of analysis, design and user interface alternatives. Prototyping dictates that design and implementation proceed in at least large-grain iterative steps. The activities which take place and the concerns which are addressed during the refinement of an OOD are identical whether it is the design or a working prototype that is being refined. Moreover, such activities as reorganizing the class to reflect some newly recognized abstraction (see Chapter 13 on refactoring) are just as likely to take place during the implementation of a prototype as during the design. The design must now be updated to reflect this change – design and implementation are now proceeding in small-grain iterative steps. Designers must be far more aware of the implementation environment because of the impact that a large reusable class library can have on a design. Designers must not only be aware of the library classes but also design patterns (see Chapter 12). To sum up, as noted by Meyer, one of the gurus of object-oriented development, designing is programming and programming is designing.
- Page 118 and 119: 7.4 Selecting control structures 95
- Page 120 and 121: while do if endif then else endWhil
- Page 122 and 123: • Exercises 7.1 Review the argume
- Page 124 and 125: count = 0 loop: count = count + 1 i
- Page 126 and 127: > 8.2 Case study 103 A statement th
- Page 128 and 129: start button event create defender
- Page 130 and 131: 8.3 ● Discussion Abstraction One
- Page 132 and 133: Exercises 109 skill. On the other h
- Page 134 and 135: CHAPTER 9 This chapter explains: 9.
- Page 136 and 137: 9.2 Identifying data flows 113 Noti
- Page 138 and 139: 9.3 Creation of a structure chart 1
- Page 140 and 141: SELF-TEST QUESTION 9.4 Discussion 1
- Page 142 and 143: Exercises 119 During the second sta
- Page 144 and 145: CHAPTER 10 This chapter explains:
- Page 146 and 147: In English, this reads: 10.2 A simp
- Page 148 and 149: 10.2 A simple example 125 Now comes
- Page 150 and 151: 10.4 Multiple input and output stre
- Page 152 and 153: Process header Process issue 10.4 M
- Page 154 and 155: 10.5 Structure clashes 131 As seen
- Page 156 and 157: 10.5 Structure clashes 133 Let us r
- Page 158 and 159: 10.6 Discussion 135 ■ teachable -
- Page 160 and 161: Exercises 137 2. a control block, s
- Page 162 and 163: CHAPTER 11 Object-oriented design T
- Page 164 and 165: Figure 11.1 The cyberspace invaders
- Page 166 and 167: SELF-TEST QUESTION 11.1 Derive info
- Page 170 and 171: 11.7 ● Discussion Summary 147 OOD
- Page 172 and 173: 11.11 Compare and contrast the prin
- Page 174 and 175: CHAPTER 12 This chapter explains: 1
- Page 176 and 177: 12.3 Delegation 153 The concepts of
- Page 178 and 179: 12.5 Factory method 155 The followi
- Page 180 and 181: 12.8 Model, view controller (observ
- Page 182 and 183: Figure 12.4 Pipe and Filter pattern
- Page 184 and 185: Figure 12.6 Layers in a distributed
- Page 186 and 187: Answers to self-test questions 163
- Page 188 and 189: CHAPTER 13 Refactoring This chapter
- Page 190 and 191: 13.3 ● Move Method 13.6 Inline Cl
- Page 192 and 193: class Sprite Instance variables x y
- Page 194 and 195: Summary Summary 171 it is making po
- Page 196: PART C PROGRAMMING LANGUAGES
- Page 199 and 200: 176 Chapter 14 ■ The basics and a
- Page 201 and 202: 178 Chapter 14 ■ The basics > > >
- Page 203 and 204: 180 Chapter 14 ■ The basics > Ear
- Page 205 and 206: 182 Chapter 14 ■ The basics > Cas
- Page 207 and 208: 184 Chapter 14 ■ The basics > > >
- Page 209 and 210: 186 Chapter 14 ■ The basics > } }
- Page 211 and 212: 188 Chapter 14 ■ The basics Unfor
- Page 213 and 214: 190 Chapter 14 ■ The basics Ada d
- Page 215 and 216: 192 Chapter 14 ■ The basics The w
- Page 217 and 218: 194 Chapter 14 ■ The basics In a
146 Chapter 11 ■ Object-oriented design<br />
Class name: Alien<br />
Responsibilities Collaborators<br />
moves Graphics<br />
displays itself<br />
provides its x coordinate<br />
provides its y coordinate<br />
provides its height<br />
provides its width<br />
Figure 11.3 A Sample CRC card – the class Alien in the cyberspace invaders game<br />
table. It seems that the act of physically handling the cards contributes to an improved<br />
understanding of the structure of the software.<br />
11.6 ● Iteration<br />
Iteration is a crucial ingredient of OOD. This is because there is no guaranteed <strong>for</strong>mula<br />
<strong>for</strong> finding the right set of objects to model a problem. There<strong>for</strong>e the process is<br />
exploratory and iterative; it is common <strong>for</strong> classes to be initially proposed during a<br />
design but subsequently be discarded as the design progresses. Similarly, the need <strong>for</strong><br />
some classes will not emerge until the implementation (coding) stage.<br />
During each iteration, the design is refined and reanalyzed continuously. Indeed,<br />
whereas design and implementation are considered largely distinct activities in traditional<br />
software development, using the object-oriented paradigm the two activities are often<br />
indistinguishable. There are a number of reasons <strong>for</strong> this, which we will now discuss:<br />
Prototyping is seen as an integral part of the object-oriented software design and implementation<br />
process. Prototyping recognizes that in most cases the requirements <strong>for</strong> a system<br />
are at best vague or not well understood. It is an exploratory process providing early<br />
validation (or otherwise) of analysis, design and user interface alternatives. Prototyping dictates<br />
that design and implementation proceed in at least large-grain iterative steps.<br />
The activities which take place and the concerns which are addressed during the<br />
refinement of an OOD are identical whether it is the design or a working prototype that<br />
is being refined. Moreover, such activities as reorganizing the class to reflect some newly<br />
recognized abstraction (see Chapter 13 on refactoring) are just as likely to take place<br />
during the implementation of a prototype as during the design. The design must now<br />
be updated to reflect this change – design and implementation are now proceeding in<br />
small-grain iterative steps.<br />
Designers must be far more aware of the implementation environment because of the<br />
impact that a large reusable class library can have on a design. Designers must not only<br />
be aware of the library classes but also design patterns (see Chapter 12).<br />
To sum up, as noted by Meyer, one of the gurus of object-oriented development,<br />
designing is programming and programming is designing.