Notation
Within this document and other ChiMu documents, some additions and modifications to UML notation are used. This chapter describes those modifications.
Design notation enhances communication among people. It is an important tool for both the design process itself and for communicating the finished design to clients and maintainers. Design notation needs to be standardized because it is shared among many people who must all interpret it consistently. On the other hand, the notation needs flexibility to grow and support the expression of newer ideas.
ChiMu uses a design notation based on UML (see [Rational-1 http://www.rational.com/uml/]), but it has some variations that are improvements, additions, or legacies from other notations. For example, we consider the work by Kilov and Ross on information modeling [Kilov+R 94] to be very useful and important. Although [Kilov+R 94] does not require a specific visual notation, they do suggest one, which we merged into our common notation.
The following describes our notation’s differences from UML. If something is not mentioned it should be assumed that the UML notation is the correct notation. Also, at no point is UML notation interpreted differently: UML notation is interpreted just as in UML. The notation below augments and can override UML but does not conflict with it. All of the items below could be described as stereotypes within UML.
Objects and Classes
|
The most obvious difference between UML and our notation is that we normally use hexagons instead of rectangles to identify objects and classes. This is to maintain the property from Booch notation of objects being distinctly recognizable and visible in diagrams. UML/OMT rectangles are neither distinct (other notations use rectangles to indicate tables, rows, layers, etc.) nor particularly visible in complex diagrams. These properties are very important for us.
|
 | Rumbaugh did have a legitimate argument that Booch clouds were difficult to draw and even to electronically use (because they are hard to connect to). Booch and Rumbaugh came up with a very good (synergistic) solution of using hexagons in early versions of the UML, but later versions of the UML abandoned them. This was unfortunate and we decided to reverse that mistake.
Methods
|
The "compartment" for methods extends beyond the edge of the hexagon because methods are potentially publicly visible. Methods can either all be in one compartment, or separated into different compartments for the different interfaces to the class.
If placed within one compartment, different protocols (groups of methods) are organized like lists are in UML.
We use standard UML method annotations.
|
 |
Attributes
|
An attribute is a public property of an object that shows the state of the object. We do not make any distinction between attributes and other methods other than possibly showing them as a separate protocol from other methods. If attributes are independently changable, they will have a corresponding ‘set’ method.
|
|
 | Frequently there is a minimal collection of attributes that uniquely determine the state of the object, but this should not be confused with the instance variables which may be used to store that state.
Instance Variables
|
Instance variables are private to a class and a shown in a compartment completely within the hexagon and (usually) below the methods. This is inverted from UML where frequently instance variables are considered attributes and are shown before the methods. Stylistically they are centered and italicized.
|
 |
Message Sends
|
Inter-class interfaces and message sends can be shown by connecting arrows to the appropriate method of a class.
|
 |
Shorthand for hand drawings
It is acceptable to fall back on just using a rectangle with three compartments (but having instance variables at the bottom) when drawing classes by hand.
Types
|
We use a separate notation for Types than for classes. Types are shown with a "Set-like" notation of a curly edged box. This distinguishes them from classes and makes them more distinct then just a rectangle again. Otherwise they have the same meaning as the rectangles in [Kilov+R 94].
|
 |
|
Method (and Attribute) compartments can be specified for a Type, but instance variables can not be.
|
 |
|
A Class (or Object) can be shown to implement a Type by an arrow pointing from the Class to the Type.
|
 |
|
When the class is not important enough to be very large, its symbol can be shrunk and the name placed outside. This is frequently useful for giving example implementations of a Type in a complicated diagram.
|
 |
Shorthand for hand drawings
It is acceptable to draw types as straight rectangles instead of the curly rectangles. It is also acceptable to use a Class notation to indicate a Type when doing Conceptual or Design model diagrams. This is the result of an inherent property of UML that during Conceptual and Design phases all models are external specification models.
Relationships
Generally we use UML notation when possible. Information Modeling [Kilov+R 94] has a richer set of relationships than UML and a cleaner decomposition of them, so in certain diagrams we will use them instead of the less precise UML notations.
Kilov and Ross relationship types
Code Blocks
|
We use the same dog-eared notation as Design Patterns [Gamma+HJV 95] for methods and other code annotations
|
 |
Other Notations
This section shows some other more unusual notations that are also interesting.
Functor
|
Functors are objects that model operations that can be performed. Their notation is interesting because of its distinctive combination of other notations already existing: hexagons for classes and dog-eared notes for Code blocks.
|
 |
Enhancement
|
An enhancement to a class is an added piece of functionality beyond the core class functionality. Enhancements allow you to manage portions of functionality of a cClass individually while still having all that functionality directly available on instance of the class. For example, you might want your presentation logic to be separate from your true (presentation independent) business domain logic. You could make the ability to create user-readable information an enhancement of your domain class. Since Java doesn’t support enhancements this notation is only useful for conceptual modeling.
|
 |
Private Functionality
|
A class can be considered to have a public interface that talks to an inner class that manages the state of the object. This means all communication from the public interface will go through private methods to access state information, which allows the object to change its state representation (e.g. delegating to another object) without impacting the public methods.
|
 |
| 
Previous TOC 
