Introduction to UML
Part II
By Michael Gold
In our last article we gave an introduction to the most useful diagrams in UML class, state, activity, use case and sequence diagrams. In this article we will tell you a little bit about some of the remaining diagrams which also have there place in the designers arsenal, so we'll mention them.
The Collaboration Diagram
The UML notation on this diagram makes it seem that this is not one diagram, but the composite of several different diagrams that were all lumped together and labeled "collaboration diagram". In the UML documentation you have parameterized collaboration diagrams, message flow collaboration diagrams. It seems to me that this particular diagram structure was probably a battle over the "three amigos" on how the heck to make it seem like it could be thrown in. After all, you had sequence diagrams coming from the Rumbaugh OMT camp, and collaboration diagrams coming from the Booch camp. The message flow collaboration diagram in many ways describes the same information as the sequence diagram. It is argued in the UML notation, that sequence diagrams show time flow of messages and collaboration diagram gives you a detailed view of relationships between objects and message passage. But relationships can already be seen in the class diagram, and timing of messages are labeled as sequences and subsequences in the collaboration diagram, so there are many overlaps here. Anyway, that said, let's talk about message flow collaboration diagrams. In our last article we had an example of a sequence diagram shown below:
Fig 1.
The equivalent collaboration diagram would look like below:
Fig 2.
The UML 1.3 Notation says the boxes represent the roles and the solid lines are the association paths representing association roles. I think that it is easier, though, to think of the boxes as instances of classes and the solid lines as interactions, just like the sequence diagram above. Each # on the interaction represents the order of the messages being passed. This is much easier to see on a sequence diagram because you just look down the graph vertically and you can see the time sequence. The sub numbering tells you something about the scope of the messages passed. In this example, Deposit (numbered 1), calls MyBank.ValidateAccount (numbered 1.1). In an implementation In C++ this might look something like this:
void Customer::Deposit()
{
MyAccount.ValidateAccount();
}
As you can see, ValidateAccount is in the scope of the Deposit method in Customer. Therefore it gets sub numbering. If ValidateAccount called a method AccessDatabase to an Object called MyDatabase, then AccessDatabase would get the sub numbering 1.1.1 as shown below:
Fig 3.
In the boxes, the colon is used just like in the sequence diagram. The instance name appears before the colon and the class name after the colon. You don't have to specify both the class name and the instance name, but you must supply the colon in order to see whether you are talking about an instance or a class.
Collaborations and patterns
One of the great design paradigms that has caught wind during the last few years is the concept of using patterns. Not that this concept hasn't been around forever, but it recently has been adopted strongly by the object-oriented community egged on by the book "Design Patterns" by Gamma. Because of Patterns huge popularity, the UML designers have eagerly added it to the UML notation as part of collaboration diagrams. The UML people have decided to call a pattern, "a parameterized collaboration). This is symbolized as the dotted oval as shown below in our example flyweight pattern. A flyweight is an object that is shared so that it can be used in multiple contexts. The client object is responsible for supplying context information to the flyweight. The example given in the gamma book is a document (the client) has information about font, color, and position of a character. Character, the flyweight keeps the character code information, but when it draws itself, it gets the shared information about font and color from the client. If the context information changes, it uses this information to draw itself differently. The diagram below shows the parameters of the pattern in the rectangle above the oval. The pattern structure is contained within the oval.
Fig 4. - Flyweight Pattern
The template parameters of the pattern can be "bound" by using dependency relationships:
Fig 5.
In our example, the Client of the flyweight pattern is shown bound to the document (which supplies context information). The flyweight is bound to the character object which is shared by different documents.
The Component Diagram
The component diagram is a UML attempt at showing the components used in your system. Components can be quite complex, as we know from developing with ActiveX, JavaBeans and more. Since components seem to be coming an extremely important part of doing development (and who really wants to reinvent the wheel), I suspect this model will get more complex in nature. For now, it's quite simple. A component is represented as below:
Fig 6.
Our simple example is a ListBox component with the property SelectedIndex and the method AddString. SelectIndex and AddString are interfaces on the component. They are the means in which the user manipulates or retrieves information from the component. In most IDE's these interfaces show up in fancy property windows in which the user can work with the interfaces. In our example, SelectedIndex would be the index of the item when a user selects a string in the listbox. The AddString method, allows the programmer to supply a string to add to the listbox. Most listbox components have many more methods and properties than this, but we have chosen only a few for our example. Also an intricate part of the component diagram, is the Node. The Node is the domain in which the physical components can be found:
Fig 7.
Above we see two components ListBox and TextBox located on the Node Mike's Machine. Note, Mike's Machine is type PC as seen with the colon separator. Dependency relationships can be used to indicate when one component talks to the interface of another:
Fig 8.
The dependency relationship connecting our database component on the Administrator's machine to the TextBox component on Mike's machine, shows us the interface TextString on the TextBox component is accessed by the db Component. Note also in this diagram that our component names are underlined. The underline indicates that the components are instances or each component running inside the node. Also again, the colon is used consistently to separate the component type (right) from the component instance (left). The communicates in the << >> is called a stereotype. We will conclude this article with a discussion of stereotypes.
Stereotypes
UML includes a notation called stereotypes and they can be found on all diagrams. Stereotypes are displayed as text inside a double less than, greater than, bracket. i.e. <<communicates>>. Stereotypes were invented by the designers of UML as a way to give different UML shapes more specialized roles to describe a diagram component. An example of a stereotype for Operations might be for all the operations such as getDate, getName, getFoo called <<accessors>>. <<accessors>> are a specialized operation for retrieval. Stereotypes are nice, because you don't have to keep inventing new shapes for things that already encompass the general case for something you need to describe. Component shapes can have stereotypes such as <<dll>, <<executable>>, <<file>>, <<library>>, <<table>>, <<java component>>, <<ActiveX>>.. Stereotypes are quite flexible and give the designer a very broad way of describing UML notation types. They also helped the UML designers to extend the UML notation without making it overly more complex.
This concludes Part II of our UML discussion. In Part III we will touch upon how UML relates directly to code so that a programmer can take a UML design and use it to benefit them in real world situations.