当前位置：Introduction
You're proficient in C++, Java or another OO language, you're designing class hierarchies, using inheritance, and manipulating complex pointer relationships to store the necessary links between your classes. You've probably drawn blobs (representing classes in some way) on whiteboards, with connecting lines to indicate the relationships between classes (inheritance or other). Perhaps you're feeling the need for a more formal notation to express your designs - using something that is language independent, and that enables you to consider the important aspects of design leaving the detail for later.
Alternatively, perhaps you're a Project Manager, looking to formalise the OO design process a little to make sure you're getting the most from your move to C++/Java or a similar language.
In this paper, I take a look at the UML (Unified Modelling Language) notation for Object Oriented Analysis and Design - the emerging standard designed by Booch, Rumbaugh and Jacobson, each of whom previously had their own notations published independently.
The starting point is Object Modelling, a technique that enables you to focus on class structure, inheritance, etc., whilst avoiding language specifics such as pointer dereferencing.
Object Modelling In UML
Figure 1 - Subset of UML Object Modelling Notation - A Summary
Object Modelling is the central technique in UML. It is a language independent notation allowing the specification of classes, their data or attributes(private) and methods (public), inheritance, and other more general relationships between classes. The notation itself is fairly simple to grasp (see figure 1), however this hides the somewhat more subtle thought processes underlying a good model.
The best way to understand the notation is to look at an example. The following Object Model shows a simple Banking System, containing classes for Head-Office, Branch, Accounts held at that Branch, and the Customers who the Accounts belong to:
Figure 2 - A Simple Banking System Object Model
Examining this Object Model in more detail, we can see the following information about our class structure:
- A Head-Office class (containing "bankName" and "address" fields, otherwise known as attributes) "administers" an (unspecified) number of Branch classes; whilst a Branch is "administered-by" exactly one Head-Office (the little black arrows indicates the direction in which the name given to a relationship should be read). On the diagram this relationship is represented by the line from the Head-Office class to the Brach class which is labelled "administers". The "1" at the Head-Office end of the line shows that exactly one Head-Office is associated with each Branch (as you would expect). The "*" at the Branch end of the line shows that a Head-Office "administers" many Branches - again as you would expect.