Modeling Business Systems
For the external view actors are adopted from the use case diagram. Each actor is
responsible for a certain action and is recorded in a partition (swimlane) as the
responsible party.
The individual activities are assigned to the responsible parties. The division of the
activity diagram into partitions allows a clear overview of responsibilities. However,
partitions can also be formed on the basis of other criteria.
An activity diagram could, for instance, be divided in such a way that manual, automated,
and semi-automated actions would each make up one partition. This would be a good
foundation for the conversion of flows into IT systems.
Verify the View—Is Everything Correct?
Just like use case diagrams, activity diagrams also have to be verified in terms of
correctness of content, in cooperation with knowledge carriers.
Checklist Verifying Activity Diagrams in the External View :
When constructing activity diagrams from the external view, always
remember that internal procedures and business processes are irrelevant.
Restrict your consideration to the description of those functionalities of the
business system that are utilized by outsiders.
The conditions of different outputs should not overlap. Otherwise, the control
flow is ambiguous, meaning that it is not clear where the flow proceeds after
a decision node.
The conditions have to include all possibilities; otherwise, the control flow
can get stuck. In case of doubt, insert an output with the condition 'else'.
Forks and joins should be well balanced. The number of flows that leave a
branch should match the number of flows that end in the corresponding join.
3.3.7 Sequence Diagrams
UML provides two types of diagrams for the representation of interactions: the sequence
diagram and the communication diagram. Both diagrams visualize the exchange of
information. However, the emphasis is different:
communication diagrams emphasize
the relationships of individual objects and their topology;
sequence diagrams emphasize
the chronological course of exchanged information. In the external view, we opt for the
representation through sequence diagrams and do without communication diagrams for
two reasons:
Chapter 3
Sequence diagrams are easier to understand for developers and readers. In
our practical work in projects we have observed a much higher acceptance of
sequence diagrams because of their simplicity.
We avoid using unnecessarily many diagram types for the same facts. Less is
often more!
If a customer or business partner uses an offered service, partners communicate with each
other. The process can be described as a series of interactions. These interactions are
clearly laid out in the sequence diagram, whereas the activities of each partner and the
conditions under which the interactions take place are omitted in the diagram. However,
they can be described with supplementary comments.
Like the activity diagrams, sequence diagrams can be modeled spanning several use
cases, as well as being used to refine business use cases. A sequence diagram illustrates
the various scenarios of a business use case.
Sequence diagrams can be used as the basis for message exchange between the business
system and outside parties (Figure 3.22). We will treat this topic in Chapter 5,
System Integration :
Figure 3.22 The elements of the sequence diagram
In a sequence diagram, we work with the following elements:
Comment: Sequence diagrams can be annotated with comments (UML generally permits
comments in all diagrams.):

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.