Software Engineering for Students A Programming Approach

Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach

web.firat.edu.tr
from web.firat.edu.tr More from this publisher
21.08.2013 Views

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.

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.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!