Modeling IT Systems
In reality, we do not document every flow of every query and every mutation. The effort
for this would be too much. We only document those flows that are especially important
or complex. The following considerations should help making the right choices:
For each query event we have to verify if all necessary classes, attributes, and
associations are present in the class diagram. For simple queries it can be
sufficient to check off the necessary data elements on a printout (see Section
4.4.5,
Constructing Communication Diagrams). For such queries a
communication diagram is not needed. This work step further helps to verify
or complete class diagrams.
Queries that are very important to the user, or that are very complex, should
be documented in a communication diagram.
4.4.3 Communication Diagram
Figure 4.59 Elements of the communication diagram
In communication diagrams, as illustrated in Figure 4.59, we work with the following
elements:
Actor "Somebody"
Actor "
somebody" represents any actor from a use case diagram. Since the query event
that is documented in the communication diagram can be contained in several use cases,
and since these use cases have different actors, we use the actor "somebody":
168
Chapter 4
In this way, we do not have to commit ourselves to a particular actor. (In communication
diagrams actors can also be omitted altogether. In our experience, however, this makes
the diagrams hard to understand.)
Query Event
A query event represents a query for information:
Normally, a query event from a use case is sent to the IT system, for example, a query for
detailed information about a ticket.
Parameter
Parameters allow for attaching information to an event, e.g., the number of a ticket, so
that the correct ticket can be read:
Iteration
An iteration indicates that all objects to which an association exists receive the event, for
instance, all the coupons of a ticket:
Object and Entry Object
The object represents an object of a class in the static view, for instance, "Henry
Johnson", who is an object of the class
passenger:
169
Modeling IT Systems
The entry object is the first object that receives a query event from an actor. At the entry
object the interaction path begins.
Reading Communication Diagrams
Figure 4.60 shows a communication diagram with the actor somebody and the objects
ticket, customer, coupon, flight, and flight number. The diagram documents the flow
of the query «
Q» coupon details.
Starting on the left, the communication diagram is read as follows: Actor
somebody (1)
sends the query event,
«Q» coupon details (2) to an object of the class coupon (3).
Actor "Somebody"
In our IT system model, use cases are the source of events. What is documented in this
communication diagram occurs in the context of a use case. It has proven to be of value
to use the undefined actor
somebody (1) instead of the actor of the use case. The flow of
an event that is described in the communication diagram can occur in various use cases
with different actors. The actor
somebody (1) substitutes for the actor of the use case
from which the query event «
Q» coupon details (2) stems:
Figure 4.60 Communication diagram
170

Get UML 2.0 in Action A Project-Based Tutorial now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.