Teach Yourself UML in 24 Hours 3rd phần 3 doc

HOUR 5 Understanding Aggregations, Composites, Interfaces, and Realizations What You’ll Learn in This Hour: . How to model classes that consist of other classes . How to model interfaces and their connections with classes . The concept of visibility You’ve learned about associations, multiplicities, and inheritance. You’re almost ready to create meaningful class diagrams. In this hour, you’ll learn the final pieces of the puzzle, as you delve into additional types of relationships and other issues connected with classes. The ultimate goal is to be able to create a static view of a system, complete with all the interconnections among the system’s classes. Aggregations Sometimes a class consists of a number of component classes. This is a special type of relationship called an aggregation. The components and the class they constitute are in a part-whole association. In Hour 2, “Understanding Object-Orientation,” I mentioned that your home computer system is an aggregation that consists of a CPU box, a keyboard, a mouse, a monitor, a CD-ROM drive, one or more hard drives, a modem, a disk drive, a printer, and possibly some speakers. Along with the drives, the CPU box holds RAM, a graphics card, and a sound card (and probably some other items). 08.067232640X.chap05.qxd 2/20/04 10:34 AM Page 79 80 Hour 5 You represent an aggregation as a hierarchy with the “whole” class (for instance, the computer system) at the top and the components below. A line joins a whole to a component, with an open diamond on the line near the whole. Figure 5.1 shows the computer system as an aggregation. RAM GraphicsCard Speaker CPUBox Keyboard Monitor Mouse HomeComputer CD-ROM SoundCardHardDriveDisketteDrive Button MouseBall is connected to 1 21 111 2 1 1 **11 11 3 1 1 1 1 FIGURE 5.1 An aggregation (part-whole) association is represented by a line between the component and the whole with an open diamond adjoining the whole. Although this example shows each component belonging to one whole, in an aggregation this isn’t necessarily the case. For example, in a home entertainment system, a single remote control might be a component both of a television and of a VCR. Constraints on Aggregations Sometimes the set of possible components in an aggregation falls into an Or rela- tionship. In some restaurants, a meal consists of soup or salad, a main course, and a dessert. To model this, you would use a constraint—the word or within curly brack- ets on a dotted line that connects the two part-whole lines, as Figure 5.2 shows. Soup Salad MainCourse Dessert Meal 1 111 1 {or} FIGURE 5.2 You can place a constraint on an aggregation to show that one component or another is part of the whole. 08.067232640X.chap05.qxd 2/20/04 10:34 AM Page 80 Understanding Aggregations, Composites, Interfaces, and Realizations 81 Consistency in Constraints Note the consistency between the use of {or} in Figure 5.2 (which shows a con- straint on an aggregation) and the previous use of {or} in Figure 4.6 (which shows a constraint in an association). Composites A composite is a strong type of aggregation. Each component in a composite can belong to just one whole. The components of a coffee table—the tabletop and the legs—make up a composite. The symbol for a composite is the same as the sym- bol for an aggregation except the diamond is filled, as shown in Figure 5.3. By the Way Ta bl eTop Leg CoffeeTable 1 1 4 FIGURE 5.3 In a composite, each component belongs to exactly one whole. A closed diamond represents this relationship. Composite Structure Diagram The composite is one way to show the components of a class. If you want to give the sense of showing the class’s internal structure, you can go a step further with the UML 2.0 composite structure diagram. Here’s an example. Suppose you’re creating a model of a shirt. Figure 5.4 shows the shirt as a large class rectangle with its components nested inside. The nested diagram shows how the components of the shirt relate to one another. The composite structure diagram focuses attention on the shirt and its internal components. This type of diagramming isn’t totally new in UML 2.0. In version 1.x this was a technique called context diagramming. 08.067232640X.chap05.qxd 2/20/04 10:34 AM Page 81 82 Hour 5 Interfaces and Realizations In Hour 2, I mentioned encapsulation—the idea that an object hides its operations from other objects. When you lock your car, for example, the car doesn’t show you how it performs the lockup operation. When you change channels on your TV, your TV doesn’t let you see how it’s done. If these operations are hidden, how do you get the car or the TV to perform them? The car and the TV both receive a message (a request to perform an operation) through an interface. An interface is a set of operations that specifies some aspect of a class’s behavior, and it’s a set of operations a class presents to other classes. An example will help clarify the interface concept. Every time you use a washing machine, you don’t rip it apart to get to the underlying circuitry so that you can turn it on and set the time parameters. You don’t get into the plumbing to start and stop the water flow. Instead, you get the washing machine to perform those operations by turning a control knob, shown in Figure 5.5. As a result of manipu- lating the knob, you can turn the machine on or off or set some parameter related to washing your clothes. Button ButtonHole ButtonSystem 1 1 1 1 buttons into 1 Sleeve Body Collar 2 is sewn on 1 1 is sewn on 1 1 1 1 1 5,6 is sewn on is sewn on 0,2,3 Shirt is sewn on FIGURE 5.4 A composite structure diagram shows the compo- nents of a class as a diagram nested inside a large class rectangle. 08.067232640X.chap05.qxd 2/20/04 10:34 AM Page 82 Understanding Aggregations, Composites, Interfaces, and Realizations 83 The control knob is the washing machine’s interface. What operations does the control knob have? They’re pretty simple. The control knob can close a connec- tion or break a connection, and it can turn clockwise or counterclockwise by some number of degrees. The control knob’s operations are, in a sense, abstract. Closing or breaking a con- nection, turning clockwise or counterclockwise—these don’t accomplish anything of value unless the control knob is attached to something. In this case it’s attached to a washing machine. It’s almost as if the washing machine makes the control knob’s operations “real” by translating them into washing-related opera- tions—like turning the machine on or off, or setting a parameter (the duration of the wash cycle, for example). In UMLspeak, we’d say that the washing machine guarantees that part of its behavior will “realize” the control knob’s behavior. For this reason, the relation- ship between a class and its interface is called realization. Why “part of its behavior”? Because it’s not the case that all of the washing machine’s operations have to do with control knobs. Some operations, like acceptClothes() and acceptDetergent(), are accessible via the washing machine’s drum. FIGURE 5.5 The control knob, an interface to a washing machine, allows you to get the washing machine to carry out some of the washing machine’s operations. 08.067232640X.chap05.qxd 2/20/04 10:34 AM Page 83 84 Hour 5 Throughout all this, you might have noticed numerous references to an inter- face’s operations, but nothing about its attributes. That’s because as far as we’re concerned, it doesn’t have any. Yes, a control knob has a radius and thickness, and perhaps attributes like make and model. The point is that we don’t care about them. When it comes to interfaces, all we’re concerned with are their operations. You model an interface the same way you model a class, with a rectangle icon. The difference is that this icon has no attributes. You’ll recall that you can elide the attributes out of the representation of a class. How then do you distinguish between an interface and a class that just doesn’t show its attributes? One way is to add the keyword «interface» above the name of the interface in the rectangle. Another is to put the letter I at the beginning of the name of any interface. The symbol for the realization relationship between a class and its interface looks like the symbol for inheritance, except the line to the open triangle is dashed instead of solid. Figure 5.6 shows the realization between WashingMachine and ControlKnob. WashingMachine ControlKnob «interface» FIGURE 5.6 An interface is a collection of operations that a class carries out. A class is related to an interface via real- ization, indicated by a dashed line with an open triangle that points to the interface. Another (elided) way to represent a class and an interface is with a small circle connected by a line to the class, as in Figure 5.7. (This is sometimes called a lollipop diagram.) WashingMachine ControlKnob FIGURE 5.7 The elided way of representing a class realizing an interface. 08.067232640X.chap05.qxd 2/20/04 10:34 AM Page 84 Understanding Aggregations, Composites, Interfaces, and Realizations 85 Inheritance Versus Realization Because of the similarity in the notation for inheritance and the notation for realiza- tion, you might take a moment to consider these two. Think of inheritance as the relationship between a parent and a child: The parent passes on physical attributes (eye color, hair color, and so on) to the child, and the child also takes on behaviors from the parent. Think of realization as something like the relationship between a teacher and a student: The teacher doesn’t pass on any physical attributes to the student, but the student learns behaviors and procedures from the teacher. The stu- dent might reuse those behaviors to accomplish his or her own goals. A class can realize more than one interface, and an interface can be realized by more than one class. Interfaces Everywhere Interfaces are all around us. In fact, we’re so accustomed to seeing them that we typically think of them as integral parts of whatever they happen to be attached to. Control knobs, in particular, are part of all kinds of appliances. In addition to helping us manipulate washing machines, for example, they enable us to turn radios on and off and to adjust the volume and the reception. You can undoubtedly think of all kinds of other places where you see control knobs. Leveraging our intuitive use of this little interface, one enterprising company markets a control knob as an input device for computers: Nashville, Tennessee-based Griffin Technology sells PowerMate, a USB-connected control knob you can program to per- form just about any function you can do with a keyboard. Proud owners typically say, “It’s incredibly useless—and I use it every day!” Because we depend on the interface to get us to the washing machine’s opera- tions, we model the interaction through the interface as a dependency. In Hour 4, “Working with Relationships,” you saw that the dependency symbol is a dashed line with an arrowhead. Figure 5.8 shows what I mean. By the Way By the Way WashingMachine PersonControlKnob «interface» FIGURE 5.8 To model interaction with a class through its interface, use a dependency symbol. 08.067232640X.chap05.qxd 2/20/04 10:34 AM Page 85 86 Hour 5 In UML 1.x, the dependency arrow worked with both the full and elided notations for the interface. UML 2.0 introduces the “ball-and-socket” symbol for the elided version (see Figure 5.9). WashingMachine Person ControlKnob FIGURE 5.9 UML 2.0’s “ball-and-socket” notation for modeling interaction through an elided interface symbol. Interfaces and Ports UML 2.0 takes the interface concept a step further by allowing you to model the connection between an interface and a class. Think of your mouse as an interface to your computer. You can do a couple of things with it—point and click (and roll that little wheel in the middle, if you have that kind of mouse). By themselves these operations are worthless until your computer “realizes” them. That is, you can use these operations to locate the cur- sor and to select items. How does the mouse connect to your computer? Follow the cable from the mouse to the back of your computer and you’ll see a port—an access point that the mouse plugs into. Of course, your computer also has a serial port, a parallel port, and one or more USB ports. These ports are the points through which the comput- er interacts with its environment. UML 2.0 provides a symbol that models these interaction points. As Figure 5.10 shows, the port symbol is a small square on the border of the class icon, and the square is connected to the interface. Computer Mouse Mouseport FIGURE 5.10 UML 2.0’s symbol for the port shows the point through which a class interacts with its environment. 08.067232640X.chap05.qxd 2/20/04 10:34 AM Page 86 Understanding Aggregations, Composites, Interfaces, and Realizations 87 Visibility Closely related to interfaces and realizations is the concept of visibility. Visibility applies to attributes or operations and specifies the extent to which other classes can use a given class’s attributes or operations (or an interface’s operations). Three levels of visibility are possible. At the public level, usability extends to other classes. At the protected level, usability is open only to classes that inherit from the original class. At the private level, only the original class can use the attribute or operation. In a television set, changeVolume() and changeChannel() are public operations, paintImageOnScreen() is a private one. In an automobile, accelerate() and brake() are public operations, updateMileageCount() is pro- tected. Realization, as you might imagine, implies that the public level applies to every operation in an interface. Shielding the operations via either of the other levels would make no sense, as an interface is intended for realization by a multitude of classes. To denote the public level, precede the attribute or operation with a “+”; to denote the protected level, precede it with a “#”; and to denote private, precede it with a “–”. Figure 5.11 shows the aforementioned public, protected, and private opera- tions in a television and in an automobile. Television + brandName + modelName + changeVolume() + changeChannel() - paintImageOnScreen() … … Automobile + make + modelName … + accelerate() + brake() # updateMileageCount() … FIGURE 5.11 Public and private operations in a television, and public and protect- ed operations in an automobile. Scope Scope is another concept relevant to attributes and operations and how they relate across a system. Two kinds of scope are possible. In instance scope, each instance of a class has its own value for the attribute or operation. In classifier scope, only one value of the attribute or operation exists across all instances of the class. A classifier-scoped attribute or operation appears with its name under- lined. This type of scoping is usually used when a specified group of instances (and no others) has to share the exact values of a private attribute. Instance scop- ing is by far the more common type of scope. 08.067232640X.chap05.qxd 2/20/04 10:34 AM Page 87 88 Hour 5 Summary To complete your knowledge about classes and how they connect, it’s necessary to understand some additional relationships. An aggregation specifies a part-whole association: A “whole” class is made up of component classes. A component in an aggregation may be part of more than one whole. A composite is a strong form of aggregation, in that a component in a composite can be part of only one whole. The UML representation of aggregations is similar to the representation of composites. The association line joining a part to a whole has a diamond adjoin- ing the whole. In an aggregation, the diamond is open; in a composite it’s closed. A composite structure diagram visualizes the internal structure of a class by show- ing classes nested inside that class. A realization is an association between a class and an interface, a collection of operations that a number of classes can use. An interface is represented as a class with no attributes. To distinguish it from a class whose attributes have been elided from the diagram, the keyword «interface» appears above the interface’s name or an uppercase “ I” precedes the interface’s name. Realization is represented in the UML as a dashed line that connects the class to the interface, with an open triangle adjoining the interface and pointing to it. Another way to represent a realization is with a solid line connecting a class to a small circle, with the circle standing for the interface. UML 2.0 adds a symbol for the port, a point through which a class interacts with its environment. The symbol is a small square on the border of the class. The square connects to the interface. In terms of visibility, all the operations in an interface are public, so that any class can use them. Two other levels of visibility are protected (usability extends to children of the class that owns the attributes and operations) and private (attrib- utes and operations are usable only by the owning class). A “+” denotes public visibility, “#” denotes protected, and “–” denotes private. Scope is another aspect of attributes and operations. In instance scoping, each object in a class has its own value of an attribute or operation. In classification scoping, one value exists for a particular attribute or operation throughout a set of objects in a class. Objects not in that set have no access to the classification- scoped value. 08.067232640X.chap05.qxd 2/20/04 10:34 AM Page 88 [...]... Unexpose the inside As you can see, “Restock” and “Collect” include the new use cases Accordingly, this technique of reusing a use case is referred to as including a use case More on Including Early versions of the UML referred to including a use case as using a use case You might still see the old way in print The term including has two advantages First, it’s clearer: The steps in one use case include... the line, you add the keyword «include» Figure 7 .3 shows the inclusion relationship in the use case model of the soda machine In the text notation that tracks the steps in the sequence, you indicate the included use cases The first step in the “Restock” use case would be «include» (expose the inside) 10.067 232 640X.chap07.qxd 2/20/04 10:46 AM Page 107 Working with Use Case Diagrams 107 FIGURE 7 .3 Soda... use case by adding steps to an existing use case Two other kinds of relationships are generalization and grouping As is the case for classes, generalization has one use case inheriting from another Grouping is a simple way of organizing a set of use cases Inclusion Let’s examine the “Restock” and “Collect” use cases from the Hour 6 example Both begin with unsecuring the machine and pulling it open, and... included in several others If it’s included in Use Case 3 and Use Case 4, is it Use Case 3. 1? Or is it 4.1? Suppose it’s the first included use case in Use Case 3, but the second in Use Case 4 Then what? It’s best to understand that the intent of the use case diagram is to show what the use cases are without specifying their order of occurrence (In that spirit, see the accompanying sidebar “Extension, Inclusion,... according to sales” along with the inclusion relationships for “Restock” and “Collect.” FIGURE 7.4 A use case diagram showing extension and inclusion «include» Expose the inside Restock Extension Point Before filling the compartments «include» Unexpose the inside «extend» Restock according to sales It’s important to be aware that the locations of the use cases in the use case diagram don’t signify anything... get the user’s point of view, you interview a number of potential users as to how they’ll interact with the machine 09.067 232 640X.chap06.qxd 2/20/04 10:18 AM Page 93 Introducing Use Cases 93 Because the main function of a soda machine is to allow a customer to buy a can of soda, it’s likely the users will quickly tell you that you’re concerned with a set of scenarios—a use case, in other words—that... customers, collectors, and suppliers want, the result will be a machine that all these groups can easily use Including a Use Case In the “Restock” use case and the “Collect” use case, you’ll note some common steps Both begin with unsecuring the machine and pulling it open, both end with closing the machine and securing it Can we eliminate the duplication of steps from use case to use case? We can The... Soda Machine The soda machine use case model with inclusion Buy soda Customer Customer «include» Restock «include» Unexpose the inside Supplier's Representative «include» Collect Collector Expose the inside Supplier's Representative Expose the inside «include» Unexpose the inside Collector Extension Hour 6 showed that the “Restock” use case could be the basis of another use case: “Restock according to... users involved in the early stages of system analysis and design This increases the likelihood that the system ultimately becomes a boon to the people it’s supposed to help—instead of a monument to clever cutting-edge computing concepts that business users find incomprehensible and impossible to work with An Example: The Soda Machine Suppose you’re starting out to design a soda machine In order to get... potential confusion of putting using near the use in use case That way, we won’t have to say we “promote reuse by using a use case.” Extending a Use Case It’s possible to reuse a use case in a way other than inclusion Sometimes we create a new use case by adding some steps to an existing use case Let’s go back to the “Restock” use case Before putting new cans of soda into the machine, suppose the supplier’s . washing machine’s drum. FIGURE 5.5 The control knob, an interface to a washing machine, allows you to get the washing machine to carry out some of the washing machine’s operations. 08.067 232 640X.chap05.qxd. 2.0. 08.067 232 640X.chap05.qxd 2/20/04 10 :34 AM Page 90 HOUR 6 Introducing Use Cases What You’ll Learn in This Hour: . What use cases are . The ideas behind creating, including, and extending use. diagramming isn’t totally new in UML 2.0. In version 1.x this was a technique called context diagramming. 08.067 232 640X.chap05.qxd 2/20/04 10 :34 AM Page 81 82 Hour 5 Interfaces and Realizations In