We have illustrated the patterns in this book with diagrams drawn using Unified Modeling Language (UML). This simple diagramming style was developed from work done by Grady Booch, James Rumbaugh, and Ivar Jacobson, which resulted in a merging of ideas into a single specification and, eventually, a standard. You can read details of how to use UML in any number of books such as those by Booch et al. (1998), Fowler and Scott (1997), and Grand (1998). We'll outline the basics you'll need in this introduction.
Basic UML diagrams consist of boxes representing classes. Let's consider the following class (which has very little actual function).
'Class Person Private age As Integer Private personName As String '----- Public Sub init(nm As String) personName = nm End Sub '----- Public Function makeJob() As String makeJob = "hired" End Function '----- Private Sub splitNames() End Sub '----- Public Function getAge() As Integer getAge = age End Function '----- Private Function getJob() As String End Function
We can represent this class in UML, as shown in Figure 2-1.
Figure 2-1. The Person class, showing private, protected, and public variables, and static and abstract methods
The top part of the box contains the class name and package name (if any). The second compartment lists the class's variables, and the bottom compartment lists its methods. The symbols in front of the names indicate that member's visibility, where “+” means public, “–” means private, and “#” means protected. Static methods are shown underlined. Abstract methods may be shown in italics or, as shown in Figure 2-1, with an “{abstract} ” label.
You can also show all of the type information in a UML diagram where that is helpful, as illustrated in Figure 2-2a.
UML does not require that you show all of the attributes of a class, and it is usual only to show the ones of interest to the discussion at hand. For example, in Figure 2-2b, we have omitted some of the method details.
Let's consider a VB7 version of Person that has public, protected, and private variables and methods, and an Employee class derived from it. We will also make the getJob method abstract in the base Person class, which means we indicate it with the MustOverride keyword.
Public MustInherit Class Person 'Class Person Private age As Short Protected personName As String '----- Public Sub init(ByRef nm As String) personName = nm End Sub '----- Public Function makeJob() As String makeJob = "hired" End Function '----- Private Sub splitNames() End Sub '----- Public Function getAge() As Short getAge = age End Function '----- Public MustOverride Function getJob() As String End Class
We now derive the Employee class from it, and fill in some code for the getJob method.
Public Class Employee Inherits Person Public Overrides Function getJob() As System.String Return "Worker" End Function End Class
You represent inheritance using a solid line and a hollow triangular arrow. For the simple Employee class that is a subclass of Person, we represent this in UML, as shown in Figure 2-3.
Note that the name of the Employee class is not in italics because it is now a concrete class and because it includes a concrete method for the formerly abstract getJob method. While it has been conventional to show the inheritance with the arrow pointing up to the superclass, UML does not require this, and sometimes a different layout is clearer or uses space more efficiently.
An interface looks much like inheritance, except that the arrow has a dotted line tail, as shown in Figure 2-4. The name <<interface>> may also be shown, enclosed in double angle brackets, or guillamets.
Much of the time, a useful representation of a class hierarchy must include how objects are contained in other objects. For example, a small company might include one Employee and one Person (perhaps a contractor).
Public Class Company Private emp as Employee Private pers as Person End Class
We represent this in UML, as shown in Figure 2-5.
The lines between classes show that there can be 0 to 1 instances of Person in Company and 0 to 1 instances of Employee in Company. The diamonds indicate the aggregation of classes within Company.
If there can be many instances of a class inside another, such as the array of Employees shown here
Public Class Company Private emp() as Employee Private pers End Class
we represent that object composition as a single line with either a “*” on it or “0, *” on it, as shown in Figure 2-6.
Some writers have used hollow and solid diamond arrowheads to indicate containment of aggregates and circle arrowheads for single object composition, but this is not required.
You will also find it convenient to annotate your UML or insert comments to explain which class calls a method in which other class. You can place a comment anywhere you want in a UML diagram. Comments may be enclosed in a box with a turned corner or just entered as text. Text comments are usually shown along an arrow line, indicating the nature of the method that is called, as shown in Figure 2-7.
UML is quite a powerful way of representing object relationships in programs, and there are more diagram features in the full specification. However, the preceding brief discussion covers the markup methods we use in this text.
All of the UML programs in this book were drawn using the WithClass program from MicroGold. This program reads in the actual compiled classes and generates the UML class diagrams we show here. We have edited many of these class diagrams to show only the most important methods and relationships. However, the complete WithClass diagram files for each design pattern are stored in that pattern's directory. Thus, you can run your demo copy of WithClass on the enclosed CD and read it and investigate the detailed UML diagram starting with the same drawings you see here in the book.