05-07-2012, 02:19 PM
UML Tutorial: Collaboration Diagrams
umlCollaborationDiagrams.pdf (Size: 28.19 KB / Downloads: 25)
Dynamic models
There are three kinds of diagrams in UML that depict dynamic models. State diagrams describe how a
system responds to events in a manner that is dependent upon its state. Systems that have a fixed number
of states, and that respond to a fixed set of events are called finite state machines (FSM). UML has a rich
set of notational tools for describing finite state machines. We’ll be investigating them in another column.
The other two kinds of dynamic diagram fall into a category called Interaction diagrams. They both
describe the flow of messages between objects. However, sequence diagrams focus on the order in which
the messages are sent. They are very useful for describing the procedural flow through many objects.
They are also quite useful for finding race conditions in concurrent systems. Collaboration diagram, on the
other hand, focus upon the relationships between the objects. They are very useful for visualizing the way
several objects collaborate to get a job done and for comparing a dynamic model with a static model
. Collaboration and sequence diagrams describe the same information, and can be transformed into one
another without difficulty. The choice between the two depends upon what the designer wants to make
visually apparent.
Sequence diagrams will be discussed in a future article. In this article we will be concentrating upon
collaboration diagrams.
The interplay between static and dynamic models.
There is a tendency among novice OO designers to put too much emphasis upon static models. Static
models depicting classes, inheritance relationships, and aggregation relationships are often the first
diagrams that novice engineers think to create. Disastrously, they are sometimes the only diagrams that
they create.
In fact, a static emphasis on object oriented design is inappropriate. Software design is about behavior; and
behavior is dynamic. Object oriented design is a technique used to separate and encapsulate behaviors.
Therefore an emphasis upon dynamic models is very important.
More important, however, is the interplay that exists between the static and dynamic models. A static
model cannot be proven accurate without associated dynamic models. Dynamic models, on the other hand,
do not adequately represent considerations of structure and dependency management. Thus, the designer
must iterate between the two kinds of models, driving them to converge on an acceptable solution.
Example: A Cellular Phone.
Consider the software that controls a very simple cellular telephone. Such a phone has buttons for dialing
digits, and a “send” button for initiating a call. It has “dialer” hardware and software that gathers the digits
to be dialed and emits the appropriate tones. It has a cellular radio that deals with the connection to the
cellular network. It has a microphone, a speaker, and a display.
Reconciling the static model with the dynamic model.
It should be clear that the structure of the objects in the dynamic model (Fig 1) does not look very much
like the structure of the classes in the static model (Fig 2). Yet by the rule we talked about above, a link
between objects must be represented by a relationship between the classes. Thus, we have a problem.
The problem could be that our dynamic model is incorrect. Perhaps we should force the dynamic model to
look like the static model. However, consider what such a dynamic model would look like. There would
be a Telephone object in the middle that would receive messages from the other objects. The
Telephone object would respond to each incoming message with outgoing messages of its own.
Such a design would be highly coupled. The Telephone object would be the master controller. It would
know about all the other objects, and all the other objects would know about it. It would contain all the
intelligence in the system, and all the other objects would be correspondingly stupid. This is not desirable
because such a “god” object becomes highly interconnected. When any part of it changes, other parts of it
may break.
Conclusion
We have completed two iterations of our static and dynamic model of a cellular phone. The first iteration
was simply a guess. In the case of the first static model, the guess was pretty bad. However, after the
second iteration we had resolved the disparity between the two models and had begun to explore more
subtle design issues. In a real project, this iteration would continue until the designer was satisfied that
both models were appropriately tuned.
Static models are necessary but insufficient for complete object oriented designs. A static model that is
produced without the benefit of dynamic analysis is bound to be incorrect. The appropriate static
relationships are a result of the dynamic needs of the application. UML Collaboration diagrams are a good
way to depict dynamic models and compare them to the static models that must support them.