OMT Class Diagrams

[Previous] [Next]

Every "Object Model" section in Part II of this book contains a class diagram in Object Modeling Technique (OMT) notation that describes in pictorial form the design pattern covered in the chapter. The following discussion provides a brief summary of a subset of the basic class diagram notation used in this book. Refer to the book Object-Oriented Modeling and Design by James Rumbaugh et al. (Prentice-Hall, 1991) for more information.

In OMT notation, classes are represented as rectangles. Classes can be either abstract or concrete. Showing the class name in an italic font indicates abstract classes (interfaces). Concrete classes show their class names in a roman font. In this book, I illustrate both abstract and concrete classes with and without attributes, as shown in Figure A-1.

An abstract class is equivalent to an interface in COM. It is not creatable, but it can be inherited by another interface. This type of interface inheritance is not supported as of version 6 of Microsoft Visual Basic, but it is supported in other COM-enabled languages such as Microsoft Visual J++ and Microsoft Visual C++. Concrete classes can also inherit interfaces, and Visual Basic does support this functionality. Furthermore, a concrete class defined in Visual Basic can inherit multiple interfaces. (See Figure A-2.)

Figure A-1. Class and interface entities depicted in an OMT diagram.

A concrete class is creatable and is considered a named implementation of an interface. Interfaces represent a type, whereas concrete classes represent a unique implementation of a type. When a concrete class inherits multiple interfaces, it must provide implementations for all properties and methods in each interface. An instance of a concrete class can therefore support multiple types. Conversely, multiple concrete classes can implement a single interface, resulting in unique classes of objects that support the same type. Consequently, you gain the benefit of polymorphism.

Unlike Visual J++ and Visual C++, Visual Basic doesn't support implementation inheritance, which is the ability for one concrete class to inherit the implementation of another. In general, two types of implementation inheritance exist: public and private. Public inheritance is when a concrete class inherits the interfaces supported by another concrete class and their implementation. Private inheritance is when a concrete class inherits only the implementation of another concrete class, not the interfaces. Even though it's not supported directly, public and private inheritance can be accomplished in Visual Basic with a combination of interface inheritance and composition. Composition is when a class defines a reference to another class. Implementation reuse is therefore possible without inheritance. Defining a reference from one class to another in OMT is referred to as an association. A solid line represents an association. (See Figure A-3.)

Figure A-2. OMT diagram depicting Visual Basic support of interface inheritance.

Figure A-3. Association depicted in OMT.

A class can also define multiple associations between other classes. This multiplicity is represented by various line endings, as illustrated in Figure A-4.

Figure A-4. Multiplicity of associations depicted in OMT.

Another type of association depicted in OMT is aggregation, shown in Figure A-5. Aggregation is represented by a diamond on the end of the association line that touches the class that contains the references to another class. The difference between normal association and aggregation is subtle but important to distinguish. If the class containing the references tightly defines itself in terms of the classes it references, aggregation is appropriate. For example, an entertainment system is an aggregation of a television, a DVD player, speakers, and so on.

Figure A-5. Aggregation depicted in OMT.