Reading UML Diagrams
From DANSE
| Table of contents |
Introduction
The Unified Modeling Language (UML) is an attempt to standardize how people draw diagrams to represent processes and relationships. One of the obvious applications of UML is to represent the relationships among classes and objects in object oriented (OO) programming.
Structure
Structure diagrams show what attributes and operations classes have, and how classes relate to one another structurally. This kind of information can be figured out by reading the code of each class, one class at a time.
Key class relationships include generalization (inheritance) and composition/aggregation. 
Generalization is denoted by an arrow with an open head pointing to the class that is more general. For DANSE, you can read this diagram as saying Class2 inherits from Class1.
Composition and aggregation (a filled or open diamond, respectively) indicate that an object of one class "has an" instance of another class. It's a whole-part relationship. The diamond sits next to the class that does the having.
Composition (filled diamond) expresses a closer relationship: the object which is contained belongs pretty exclusively to the container.
Aggregation (open diamond) is a looser relationship: the contained object may be known to many other objects besides the one in this diagram.
A closely relate concept is the multiplicity: at each end of a composition or aggregation, a number tells how many instances of a class participate in the relationship. In our example diagram, the asterisk (*) next to Class4 means many Class4 instances may be involved, while the 1 next to Class3 means there's only one Class3 instance involved. This is pretty common in composition relationships, along with the 1 and 1 relationship of Class7 and Class8.
Activity diagrams
Activity diagrams show how things get done as time progresses. Time is usually understood to pass as one moves down the diagram. Different states or activities bubbles represent things getting done. Arrows show how control flows from one activity to the next. One often adds vertical bars ("swim lanes") to show which object or actor is doing something. I like to use activity diagrams when I'm designing, and the activities are not very well defined.
In this example, I assume that there is one object doing the stuff at the left, and it communicates with some other objects or components in the swim lanes. Objects in square boxes show up as input to various activities: for example, the component will need to be told the path of a dataset within an hdf file in order to determine the appropriate portion of the dataset.
Sequence diagrams
Like activity diagrams, sequence diagrams show how objects interact in time. I tend to use them for more precise statements of what's going on. For instance, you can get a pretty good notion of what the call stack looks like at any moment with a sequence diagram. Time passes as you move down the page. When a method is invoked on any object, an "activation" is shown. It's understood that the arrows that come out of an activation represent function calls made by that method.
In this sequence diagram, we see the steps involved in a client object reading a dataset from an hdf file.
