Visual Introduction to UML for Object-Oriented Design, Page 5
UML has another notation to indicate an even more structured relationship than aggregation. This relationship is called composite aggregation. For an aggregation to be composite, two conditions must be satisfied:
- Aggregated instances must belong to only one composite at a time.
- Some operations must propagate from the composite to its aggregated instances. For example, when a composite object is cloned, its Clone function will typically clone the aggregated instances so that the cloned composite will own clones of the original aggregated instances.
Figure 13: Composite Aggregation
Figure 13 is a class diagram that contains a composite aggregation. The class diagram shows a Document class. Document objects can contain Paragraph objects. Paragraph objects can contain DocChar objects. Because of the composite aggregation, you know that Paragraph objects do not share DocChar objects and Document objects do not share Paragraph objects. Because the classes involved in a composite aggregation propagate operations to each other, they generally implement a common interface or extend a common superclass.
Some associations are indirect. Instead of classes being directly associated with each other, they are associated indirectly through a third class. Consider the class diagram in Figure 14. The association in Figure 14 shows that instances of the Cache class refer to instances of the Object class through an instance of the ObjectID class.
Figure 14: Association Class
An association between classes or interfaces implies a dependency that involves an object reference connecting two objects. Other types of dependencies are possible. A dashed line with an open arrowhead is used to indicate a dependency in the more general sense. Figure 15 shows an example of such a dependency.
Figure 15: Dependency
The classes in a class diagram can be organized into packages. Packages are drawn as a large rectangle with a small rectangle above the large rectangle. The small rectangle contains the name of the package. The small and large rectangles are arranged to have an overall shape similar to a manila folder. The class diagram in Figure 16 contains a package named ServicePackage. A visibility indicator can precede the name of classes and interfaces that appear within a package. Public classes are accessible to classes outside of the package; private classes are not.
Figure 16: Package