Activity Diagram
Continuing the process ...
– Visualize workflows
– Visualize use case sequences
It is important to get a good understanding of the relevant business
processes, especially in large projects. The UML activity diagram is a
very helpful tool to model the important business processes
– to give the developer a better understanding
of the stakeholder requirements and
– to visualize the control flow of an individual scenario
in an overview diagram.
Martin Jud
Activity Diagram
Software-Engineering II - UseCases
1
Adapted from SWEED, Martin Kropp
Activity Diagram
•
What it is
– graphical representation of process and control flow
•
Purpose
1. Describe business processes
2. Describe individual use case scenarios
3. Model concurrent behavior
Martin Jud
Activity Diagram
Software-Engineering II - UseCases
2
Adapted
© 2001
from
by SWEED, Martin Kropp
Activity Diagram
•
•
•
Activity diagrams inherited a lot from event diagrams,
SDL state modeling, workflow modeling and Petri Nets.
These diagrams are especially helpful for modeling
workflow and use case scenarios without having to dive
into OO technology. They are very well understood
without any computer knowledge, so are an excellent
means for user communication
They are also very good means to describe concurrent
behavior in a process.
Activity Diagram
Software-Engineering II - UseCases
Martin Jud
3
Adapted from SWEED, Martin Kropp
Activity Diagras
Basic Elements of an Activity Diagram
• Registration
Activity
Start
Browse Course
Catalog
Guard
Confirm
Registration
Enter Personal
Data
Select Course
Info
Branch
[data correct]
End
[else]
Update Course
Martin Jud
Send Email
Activity Diagram
Software-Engineering II - UseCases
Print Bill
4
© 2001 by SWEED, Martin Kropp
Modellieren eines Geschäftsprozesses
Martin Jud
Activity Diagram
Software-Engineering II - UseCases
5
© 2002-2003 by Scott W. Ambler, www.modelingstyle.info
Start- und Endpunkte
• Jedes UML ActivityDiagramm
sollte einen Startpunkt haben,
vorzugsweise liegt dieser
links oben.
• Normalerweise hat ein UML
ActivityDiagramm einen
Endpunkt. (nach Fowler sind
Endpunkte aber optional)
Das Diagramm rechts hat z.B.
keinen Endpunkt weil es
einen endlosen Prozess
beschreibt.
Martin Jud
Activity Diagram
Software-Engineering II - UseCases
6
Adapted from Scott W. Ambler, www.modelingstyle.info
Entscheidungen
• Entscheidungen werden - wie in Flussdiagrammen - mit einer Raute
dargestellt.
• Allerdings steht im UML ActivityDiagram nichts in der Raute. Die
Verbindung zu nachfolgenden Aktivitäten, wird mit einem Guard der
Form [ Bedingung ] beschriftet.
• Jede von einer Entscheidung abgehende Verbindung muss einen
Guard haben. Die Bedingung muss zutreffen, damit die eine
Verbindung gewählt werden kann.
• Die Bedingungen müssen ausserdem so gewählt sein, dass nach der
Entscheidung immer weiter gefahren werden kann.
• Im ActivityDiagramm sollten nur für das Verständnis wichtige
Entscheidungen dargestellt werden.
Activity Diagram
Software-Engineering II - UseCases
Martin Jud
7
Adapted from Scott W. Ambler, www.modelingstyle.info
Additional Elements of an Activity Diagram
Customer
Browse Course
Catalog
Registration
System
Billing
System
Database
System
Select Course
Info
Swimlane
[else]
Enter Personal
Data
[data correct]
Confirm
Registration
Fork
Send Email
Update Course
Print Bill
Join
Martin Jud
Activity Diagram
Software-Engineering II - UseCases
8
© 2001 by SWEED, Martin Kropp
Parallele Abläufe
Forks und Joins
– Ein Ablauf kann sich in mehrere parallele Pfade
aufspalten (Fork) die an ihrem Ende wieder
zusammengeführt (Join) werden.
– Eine Gabelung hat nur einen Eingang, ein
Zusammenschluss hat nur einen Ausgang.
– Erst wenn alle parallelen Pfade zu Ende sind wird der
Ablauf nach dem Join weitergeführt.
Im ActivityDiagramm sollten nur für das Verständnis
wichtige Parallelitäten dargestellt werden
Martin Jud
Activity Diagram
Software-Engineering II - UseCases
9
Adapted from Scott W. Ambler, www.modelingstyle.info
Mehrere Rollen / Threads
Swimlanes
– Mit Swimlanes können Aktivitäten gruppiert werden, die zum
gleichen Actor oder zum gleichen Thread gehören.
– Die Anordnung der Bahnen hat keine semantische
Bedeutung. Allerdings verbessert es die Lesbarkeit, wenn
sie in der gleichen Reihenfolge dargestellt werden, in der sie
typischerweise auch abgearbeitet werden.
– Am besten eignen sich Swimlanes in linearen Prozessen, an
denen mehrere Akteure beteiligt sind.
Zuviele Swimlanes verringern die Lesbarkeit von
AktivityDiagrammen.
Martin Jud
Activity Diagram
Software-Engineering II - UseCases
10
Adapted from Scott W. Ambler, www.modelingstyle.info
Action-Objekte
Bei der Geschäftsfall-Modellierung können Action-Objekte für beliebige
Gegenstände stehen.
– Werden diese von mehreren Akteuren
verwendet, legt man sie auf die Swimlane.
– Erscheint ein Action-Objekte mehrmals
verwendet man Zustandsnamen.
Das Spesen-Formular ExpenseForm ist ein Beispiel für beides
Martin Jud
Activity Diagram
Software-Engineering II - UseCases
11
© 2002-2003 by Scott W. Ambler, www.modelingstyle.info
Verfeinernde Zerlegung
• Eine Aktivität kann in einem andern ActivityDiagramm
weiter verfeinert werden.
• Natürlich muss die Verfeinerung gleich viele Start- und
Endpunkte haben, wie die abstrakte Aktivität Ein- und
Ausgänge besitzt.
Martin Jud
Activity Diagram
Software-Engineering II - UseCases
12
When to Use
•
•
•
•
Analyzing Use Cases
Understanding Workflows
Describing complicated sequential algorithms
Modeling parallel behavior
Martin Jud
Activity Diagram
Software-Engineering II - UseCases
13
© 2001 by SWEED, Martin Kropp
When NOT to Use
• Analyzing Object Collaboration
• Analyzing an Objects lifetime
• Representing complex conditional logic
• Wenn ein Ablauf so komplex ist, dass Sie ein UML
ActivityDiagramm entwickeln müssen um ihn zu
verstehen, ist möglicherweise Refactoring angesagt...
Martin Jud
Activity Diagram
Software-Engineering II - UseCases
14
© 2001 by SWEED, Martin Kropp
Interaction Diagram
• What it is
– Graphical representation of collaborating objects
• Purpose
– Describe an individual use case scenario in the form of
collaborating objects
• Two Types
– Sequence Diagram
– Collaboration Diagram
Martin Jud
Interaction Diagram
Software-Engineering II - UseCases
15
© 2001 by SWEED, Martin Kropp
Sequence Diagram
• Purpose
– Displaying the exchange of messages between objects
within a limited period of time
• Ideal
– for short time period with few objects
– with low nesting / few branches
Martin Jud
Interaction => Sequence Diagram
Software-Engineering II - UseCases
16
© 2001 by SWEED, Martin Kropp
Elements of a Sequence Diagram
aRegistrationFo
rm
Object
aRegistrationM
anager
aCourse:
Course
register(Joe, aCourseList)
aCust = getCustomer(Joe)
Self Delegation
Message
Creation
[not aCust]
a Cust = new(Joe)
Condition
Joe:
Customer
*[for all courses]
addParticipant(aCust)
Iteration
Return
numPart
Activation Box
delete()
Deletion
Interaction => Sequence Diagram
Software-Engineering II - UseCases
Martin Jud
17
© 2001 by SWEED, Martin Kropp
Advanced Elements
aCustomer:
Customer
UML 1.4
aDatabase:
save()
aTransaction
addCustomer(aCustomer)
new()
Create its own
transaction thread
Asynchronous
Message
finished()
finished()
Martin Jud
Self Deletion
Interaction => Sequence Diagram
Software-Engineering II - UseCases
18
© 2001 by SWEED, Martin Kropp
Guidelines
•
Strive for ordering of messages
– arrange the classifiers (actors, classes, objects, and use cases)
in such a way as to depict message flow from left to right.
– a message that appears lower in the diagram is sent after one
that appears above it
•
Layer the classifiers
– First indicate the human actors, then a controller class representing the
logic of that scenario, then the user interface class(es), and then the
business class(es), finally technical classes wrapping your system
– Place human actors and proactive system actors, i.e. systems that
initiates interaction with yours, on the left-most side.
– Reactive system actors, systems that yours initiates interaction with
(through access techniques such as APIs, IDLs, message queues, or web
services), should be placed on the right-most side.
Martin Jud
Interaction => Sequence Diagram
Software-Engineering II - UseCases
19
© 2002-2003 by Scott W. Ambler, www.modelingstyle.info
More Guidelines
•
Name actors and classes consistently with Use Cases
– For the sake of consistency an actor that appears on a sequence diagram
should have the same name that it does on your use case diagram
– An actor can have the same name as a class, if the two represent the
same concept in the real world and in the application respectively.
•
Avoid modeling object destruction
– Although memory management issues are important, object destruction
introduces clutter into your diagrams.
•
Include a prose description of the logic
– Diagrams can be hard to follow, it is quite common to include
a business description of the logic you are modelin
Martin Jud
Interaction => Sequence Diagram
Software-Engineering II - UseCases
20
© 2002-2003 by Scott W. Ambler, www.modelingstyle.info
Messages
• Creating objects
– you can either send a message with the <<create>> stereotype or
– you can directly show creation by dropping the classifier down in
your diagram and invoking a message into its side.
• Message names
– for a message sent to a class, interface, or component it is
common convention to apply the operation signature.
– for messages involving human actors label it with brief prose
• Messages to classes indicate static operations
Martin Jud
Interaction => Sequence Diagram
Software-Engineering II - UseCases
21
© 2002-2003 by Scott W. Ambler, www.modelingstyle.info
Use Case Invocations
• a use case may be invoked in a sequence diagram via a
message with the <<include>> stereotype.
Martin Jud
Interaction => Sequence Diagram
Software-Engineering II - UseCases
22
© 2002-2003 by Scott W. Ambler, www.modelingstyle.info
Return Values
• Return values are optional
– indicate the return value when it is not obvious what is being
returned using a dashed arrow with a label .
– If you need to refer to a return value elsewhere in your sequence
diagram, typically as a parameter passed in another message
• Return values as part of a method invocation
– consider indicating the return value in the message name, using
the notation message(parameters): returnValue
• Types vs. actual values
– Prefer indicating actual values for simple values over indicating
types as return value placeholders.
Interaction => Sequence Diagram
Software-Engineering II - UseCases
Martin Jud
23
© 2002-2003 by Scott W. Ambler, www.modelingstyle.info
When to Use
• Use Case Analysis
• SW-Design
• Implementation
Use Case Analysis
– Using rather high level objects (objects, that may be split into
several classes), allows the illustration of individual scenarios on
different abstraction levels.
– They also give you a first impression of how your identified objects
collaborate, which means, how relationships between the
corresponding classes will be.
Martin Jud
Interaction => Sequence Diagram
Software-Engineering II - UseCases
24
Adapted from SWEED, Martin Kropp
When to Use
• Use Case Analysis
• SW-Design
• Implementation
SW-Design
– Select some typical and some complex and draw them up in
sequence diagrams, until you get a clear understanding of how the
objects are collaborating.
– Also use sequence diagrams when you want to emphasize the
behavior of the objects over time. Use sequence diagrams only
with few objects.
– Sequence diagrams help a lot in understanding and seeing the
over all flow of control in an OO-system.
Interaction => Sequence Diagram
Software-Engineering II - UseCases
Martin Jud
25
Adapted from SWEED, Martin Kropp
When to Use
• Use Case Analysis
• SW-Design
• Implementation
Implementation
– You can decompose sequence diagrams, and thus build
hierarchies of sequence diagrams until you come down to the
implementation level.
– This makes them such a great tool. In analysis they also give you
a first impression of how your identified objects collaborate, which
means, how relationships between the corresponding classes will
be.
Martin Jud
Interaction => Sequence Diagram
Software-Engineering II - UseCases
26
Adapted from SWEED, Martin Kropp
When NOT to Use
• Collaboration of many objects
• Complex logic
• Behavior of a single object
Interaction => Sequence Diagram
Software-Engineering II - UseCases
Martin Jud
27
© 2001 by SWEED, Martin Kropp
Kollaborationsdiagramm
Gleicher Informationsgehalt wie Sequenzdiagramm !
Message
Erika
2: Summton
4: Klingeln
8: Hier ist Heinz
1: Hörer abheben
3: Nummer wählen
5:Klingeln
:Telefonzentrale
Heinz
6: abheben
7:Hier ist Heinz!
Martin Jud
Interaction => Collaboration Diagram
Software-Engineering II - UseCases
28
von Jörg Hofstetter, HTA Luzern
Kollaborationsdiagramm
Link Role
Multiobject
servers
:Server
client
1: aServer:=find(specs)
«local» aServer
:Server
2: process()
Parameter
request
Martin Jud
Interaction => Collaboration Diagram
Software-Engineering II - UseCases
29
von Jörg Hofstetter, HTA Luzern
Nachrichten
1a,1b / [a >0] 1c * [x = 1..10]: return := doSomething(x1,x2)
Vorgänger-Bedingung
Bedingung
Sequenzausdruck
Return-Wert:=
Nachrichtenname
Parameterliste
Bsp :
1a,1b / [a>0] 1c *[x=1..10] p:= doSomething(x1,x2)
Martin Jud
Interaction => Collaboration Diagram
Software-Engineering II - UseCases
30
von Jörg Hofstetter, HTA Luzern
Nachrichten
:Bestellung
«parameter» b
1.1: *[i=1..*] bpos=gibBestellPosition()
1: reservieren(b)
1.3: reserviere(artikel,anzahl)
Artikel
Reservierung
Erika
:ArtikelLager
1.2.1: artikel:=gibArtikel()
1.2.2: anzahl:=gibAnzahl()
«local» bpos
:Bestellposition
Interaction => Collaboration Diagram
Software-Engineering II - UseCases
Martin Jud
31
von Jörg Hofstetter, HTA Luzern
Parallele Systeme
Thread a
1a: f1()
A
B
2a: putMsg()
D
MsgQueue
1c: getMsg()
C
Thread c
1b: putMsg()
Thread b
Martin Jud
Interaction => Collaboration Diagram
Software-Engineering II - UseCases
32
von Jörg Hofstetter, HTA Luzern
Anwendung
• Wie beim Sequenzdiagramm
aber:
• statische Verbindungen zwischen den Objekten
besser darstellbar
Martin Jud
Interaction => Collaboration Diagram
Software-Engineering II - UseCases
33
von Jörg Hofstetter, HTA Luzern
State Diagram
• State
– A state of an object describes the current values of its
attributes.
• Purpose
– Describes behavior of an object
– Shows all possible states of an object
– Shows object’s state changes
– Shows events and actions resulting from the events
Martin Jud
State Diagram
Software-Engineering II - UseCases
34
© 2001 by SWEED, Martin Kropp
A Simple State Diagram
Class: Course Offering
State
Start
Initialized
Canceled
do: Initialize course
Activity
new Participant /
Set Count = 0
Open
Canceled
when (count = 10)
entry: register participant
Canceled
entry: notify registered
participants
Canceled
Closed
entry: notify registered
students
End
Transition
new Participant [count < 10]
Martin Jud
State Diagram
Software-Engineering II - UseCases
35
© 2001 by SWEED, Martin Kropp
Transitions
• UML syntax for the transition from one state to another is
event [guard] /action
– The event causes the transition, the guard specifies
an additional constraint and the action is the function
that is executed with the transition. Once the action is
performed, the new state is entered. All three parts are
optional.
– The Initialized state has an activity associated, to
initialize the course offering.
Martin Jud
State Diagram
Software-Engineering II - UseCases
36
Adapted from SWEED, Martin Kropp
Activities
• The syntax for activities is:
do/activity
– When the first customer registers, the transition is
executed and the action “set Count = 0” is performed;
after this the Open state is entered.
– Note the difference between activity which is
associated with a state and which can take longer, and
the action which is associated with the transition and
which is executed before we enter the new state (and
which is usually short in execution time).
Martin Jud
State Diagram
Software-Engineering II - UseCases
37
Adapted from SWEED, Martin Kropp
Action Tags
You may have noticed the “entry” tag in the Open state in
the previous slide.
• entry action
this tag specifies the entry action, which is executed
whenever the state is entered, independent through which
transition:
entry: action
• exit action
there is also an exit action, which behaves appropriate on
exiting the state:
exit: action
Martin Jud
State Diagram
Software-Engineering II - UseCases
38
Adapted from SWEED, Martin Kropp
Events
important events that may be used with transitions are
• timeout event
with the keyword after,
after(10 seconds)
• conditional event
with the keyword when, when a specified condition
becomes true
when (count = 10)
State Diagram
Software-Engineering II - UseCases
Martin Jud
39
Adapted from SWEED, Martin Kropp
Advanced State Diagram
Class: Course Offering
Super State
Aktiv
Initialized
do: Initialize course
Canceled
Canceled
new Participant /
Set Count = 0
Open
entry: register participant
when
(count = 10)
Closed
notify registered
students
entry:
notify registered
participants
new Participant [count < 10]
Martin Jud
State Diagram
Software-Engineering II - UseCases
40
© 2001 by SWEED, Martin Kropp
General Guidelines
•
Create a state chart only when behavior differs based on state
– If a class or component, exhibits the same sort of behavior, regardless of
its current state then drawing a UML State Chart will be of little use.
– A state is a stage in the behaviour pattern of an entity.
States are represented by the values of the attributes of an entity.
•
Place the initial state in the top-left corner and the final state in the bottomright corner
•
Question “Black Hole” and “Miracle” States
– except for start and end points, black hole states and miracle states
respectively are indications that you have missed one or more transitions.
Martin Jud
State Diagram
Software-Engineering II - UseCases
41
© 2002-2003 by Scott W. Ambler, www.modelingstyle.info
Substate Modeling
• Model substates for targeted complexity
– Modeling substates makes sense when an existing state also
exhibits complex behavior, motivating you to explore its substates.
– Introducing a superstate makes sense when several existing
states share a common entry or exit condition.
• Aggregation vs. Hierarchy of State Charts
– aggregate Common Substate Transitions
guards and actions, if any, on the transitions being aggregated
should be identical.
– if the resulting diagrams can become quite complex create a
hierarchy UML State Chart diagrams.
Martin Jud
State Diagram
Software-Engineering II - UseCases
42
© 2002-2003 by Scott W. Ambler, www.modelingstyle.info
Transitions and Actions
• Indicate entry or exit actions only when applicable for all entry or exit
transitions respectively.
• Name transition events in past tense
– The transition events are written in past tense reflecting the fact
that transitions are the results of events – because the event
occurs before the transition it should be referred to in past tense.
• Guards
– guards should not overlap
– introduce junctions to visually localize guards
– guards need not form a complete set
Martin Jud
State Diagram
Software-Engineering II - UseCases
43
© 2002-2003 by Scott W. Ambler, www.modelingstyle.info
When to use
• To describe behavior of a single object over several uses
cases
• To fully record the behavior of an object
Martin Jud
State Diagram
Software-Engineering II - UseCases
44
© 2001 by SWEED, Martin Kropp