The Unified Modeling Language User Guide SECOND EDITION [Electronic resources] نسخه متنی

Common Modeling Techniques

Modeling Simple Dependencies

A common kind of dependency relationship is the connection between a class that uses another class as a parameter to an operation.

To model this using relationship,

• Create a dependency pointing from the class with the operation to the class used as a parameter in the operation.

For example, Figure 5-9 shows a set of classes drawn from a system that manages the assignment of students and instructors to courses in a university. This figure shows a dependency from CourseSchedule to Course, because Course is used in both the add and remove operations of CourseSchedule.

If you provide the full signature of the operation as in this figure, you don't normally need to show the dependency as well, because the use of the class is already explicit in the signature. However, you'll want to show this dependency sometimes, especially if you've elided operation signatures or if your model shows other relationships to the used class.

This figure shows one other dependency, this one not involving classes in operations but rather modeling a common C++ idiom. The dependency from Iterator shows that the Iterator uses the CourseSchedule; the CourseSchedule knows nothing about the Iterator. The dependency is marked with the stereotype «permit», which is similar to the friend statement in C++.

Modeling Single Inheritance

In modeling the vocabulary of your system, you will often run across classes that are structurally or behaviorally similar to others. You could model each of these as distinct and unrelated abstractions. A better way would be to extract any common structural and behavioral features and place them in more-general classes from which the specialized ones inherit.

To model inheritance relationships,

• Given a set of classes, look for responsibilities, attributes, and operations that are common to two or more classes.

• Elevate these common responsibilities, attributes, and operations to a more general class. If necessary, create a new class to which you can assign these elements (but be careful about introducing too many levels).

• Specify that the more-specific classes inherit from the more-general class by placing a generalization relationship that is drawn from each specialized class to its more-general parent.

For example, Figure 5-10 shows a set of classes drawn from a trading application. You will find a generalization relationship from four classesCashAccount, Stock, Bond, and Propertyto the more-general class named Security. Security is the parent, and CashAccount, Stock, Bond, and Property are all children. Each of these specialized classes is a kind of Security. You'll notice that Security includes two operations: presentValue and history. Because Security is their parent, CashAccount, Stock, Bond, and Property all inherit these two operations, and for that matter, any other attributes and operations of Security that may be elided in this figure.

You may notice that the names Security and presentValue are written a bit differently than others. There's a reason for this. When you build hierarchies as in Figure 5-10, you often encounter nonleaf classes that are incomplete or are simply ones for which you don't want there to be any objects. Such classes are called

abstract . You can specify a class as abstract in the UML by writing its name in italics, such as for the class Security. This convention applies to operations such presentValue and means that the given operation provides a signature but is otherwise incomplete, so it must be implemented by some method at a lower level of abstraction. In fact, as the figure shows, all four of the immediate children of Security are concrete (meaning that they are nonabstract) and must each provide a concrete implementation of the operation presentValue.

Your generalization/specialization hierarchies don't have to be limited to only two levels. In fact, as Figure 5-10 shows, it is common to have more than two layers of inheritance. SmallCapStock and LargeCapStock are both children of Stock, which, in turn, is a child of Security. Security is therefore a root class because it has no parents. SmallCapStock and LargeCapStock are both leaf classes because they have no children. Stock has a parent as well as children, so it is neither a root nor a leaf class.

Although it is not shown here, you can also create classes that have more than one parent. This is called multiple inheritance and means that the given class has all the attributes, operations, and associations of all its parents.

Of course, there can be no cycles in an inheritance lattice; a given class cannot be its own ancestor.

Modeling Structural Relationships

When you model with dependencies or generalization relationships, you may be modeling classes that represent different levels of importance or different levels of abstraction. Given a dependency between two classes, one class depends on another but the other class has no knowledge of the one. Given a generalization relationship between two classes, the child inherits from its parent but the parent has no specific knowledge of its children. In short, dependency and generalization relationships are asymmetric.

When you model with association relationships, you are modeling classes that are peers of one another. Given an association between two classes, both rely on the other in some way, and you can often navigate in either direction. Whereas dependency is a using relationship and generalization is an is-a-kind-of relationship, an association specifies a structural path across which objects of the classes interact.

To model structural relationships,

• For each pair of classes, if you need to navigate from objects of one to objects of another, specify an association between the two. This is a data-driven view of associations.

• For each pair of classes, if objects of one class need to interact with objects of the other class other than as local variables in a procedure or parameters to an operation, specify an association between the two. This is more of a behavior-driven view of associations.

• For each of these associations, specify a multiplicity (especially when the multiplicity is not *, which is the default), as well as role names (especially if they help to explain the model).

• If one of the classes in an association is structurally or organizationally a whole compared with the classes at the other end that look like parts, mark this as an aggregation by adorning the association at the end near the whole with a diamond.

How do you know when objects of a given class must interact with objects of another class? The answer is that CRC cards and use case analysis help tremendously by forcing you to consider structural and behavioral scenarios. Where you find that two or more classes interact using data relationships, specify an association.

Figure 5-11 shows a set of classes drawn from an information system for a school. Starting at the bottom left of this diagram, you will find the classes named Student, Course, and Instructor. There's an association between Student and Course, specifying that students attend courses. Furthermore, every student may attend any number of courses and every course may have any number of students. Similarly, you'll find an association between Course and Instructor, specifying that instructors teach courses. For every course there is at least one instructor and every instructor may teach zero or more courses. Each course belongs to exactly one department.

The relationships between School and the classes Student and Department are a bit different. Here you'll see aggregation relationships. A school has zero or more students, each student may be a registered member of one or more schools, a school has one or more departments, and each department belongs to exactly one school. You could leave off the aggregation adornments and use plain associations, but by specifying that School is a whole and that Student and Department are some of its parts, you make clear which one is organizationally superior to the other. Thus, schools are somewhat defined by the students and departments they have. Similarly, students and departments don't really stand alone outside the school to which they belong. Rather, they get some of their identity from their school.

You'll also see that there are two associations between Department and Instructor. One of these associations specifies that every instructor is assigned to one or more departments and that each department has one or more instructors. This is modeled as an aggregation because organizationally, departments are at a higher level in the school's structure than are instructors. The other association specifies that for every department, there is exactly one instructor who is the department chair. The way this model is specified, an instructor can be the chair of no more than one department, and some instructors are not chairs of any department.

Note

Your school might not have departments. You might have chairs who are not instructors, or you might even have students who are also instructors. That doesn't mean that the model here is wrong, it's just different. You cannot model in isolation, and every model like this depends on how you intend to use these models.