Activity Diagram

Transcription

Activity Diagram

Orientierung
Elemente der externen Sicht
Martin Jud 04.05.2004
•
UseCase Diagramme
zeigen Akteure, Business UseCases
und deren Beziehungen
=> Überblick über Funktionalität und
Kontext des Systems
•
Aktivitätsdiagramme
beschreiben die Geschäftsprozesse als
Sequenzen, Alternativen und Parallelen
von Abläufen
=> Interaktionen der Akteure,
Leistungen des Systems
•
Sequenzdiagramme
zeigen den Nachrichtenaustausch
mit Partnern und Kunden
in zeitlicher Reihenfolge
=> Überblick über Interaktionen
und Datenaustausch
Software-Engineering BusinessModel – Activity & Sequence
1
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.
2
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
3
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.
4
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
Send Email
Print Bill
5
© 2001 by SWEED, Martin Kropp
Modellieren eines Geschäftsprozesses
6
© 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.
7
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.
8
Partitions
UML 1.4: Swimlane
Martin Jud
AktivitätsdiagrammeSoftware-Engineering BusinessModel – Activity & Sequence
9
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
10
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
11
Mehrere Rollen / Threads
Swimlanes
– Mit Swimlanes können Aktivitäten gruppiert werden,
die zum gleichen Actor oder 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.
Zu viele Swimlanes verringern die Lesbarkeit der Diagramme.
12
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
13
Verfeinernde Zerlegung
• Eine Aktivität kann in einem andern ActivityDiagram
weiter verfeinert werden.
• Natürlich muss die Verfeinerung gleich viele Start- und
Endpunkte haben, wie die abstrakte Aktivität Ein- und
Ausgänge besitzt.
14
Dataflow
•
If the requirement involves process elements, each
taking inputs, and producing outputs, use data flow.
1. Identify the processing elements (usually high level);
show as circles or rectangles
2. Identify the data sources & destinations;
show as names between two horizontal lines
3. Show the data paths among processing elements.
Indicate types of data flowing on each
15
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Structured Analysis (SA)
• Edward Yourdon’s book written in 1989
• 3 grundlegende Modelle
– Environmental Model:
Statement of Purpose / Context Diagram / Event List
– Behavioral Model:
DFD / ERD / DataDict. / PSpec / STD
– Implementation Model:
SD (Transformation / Transaktion, Tom de Marco)
Martin Jud
SA Konzepte
•
hierarchisch angeordnete Datenflussdiagramme (DFDs),
– die einzelnen Datenflussdiagramme sind als Baum angeordnet.
Wurzel des Baumes ist das Kontextdiagramm
•
Data Dictionary-Einträge (DDs)
– definiert Datenflüsse und Datenspeicher sowie die Bedeutung
der verschiedenen Namen
Datenflüsse müssen zwischen Kind- und Elterndiagramm
ausbalanciert sein
•
Prozess-Spezifikationen (PSpecs)
– Prozesse dieser Datenflussdiagramme werden
durch PSpecs beschrieben.
17
DFD 0
=> Verfeinerung des Kontextdiagramms
Regeln:
– Prozess 0 wird in Teilprozesse (hier: P1 und P2) zerlegt.
– Datenflüsse werden ebenfalls verfeinert (hier: D1E und D2E).
– Speicher werden eingeführt (hier: Speicher 1).
– Neue Datenflüsse zwischen Prozessen und zwischen Prozessen
und Speicher werden eingetragen.
– Schnittstellen und Speicher können nicht verfeinert werden,
dürfen aber auf tiefern Diagrammen wiederholt werden.
18
Aus Lehrbuch der Software Technik von Helmut Balzert (Spektrum-Verlag)
DFD1, DFD2, ... DFD1.1, ...
•
Jeder Prozess kann weiter verfeinert werden
=> neues Diagramm
•
Die Anzahl der Prozesse pro Diagramm soll kleiner 7 sein.
•
Ist ein Prozess ausreichend verstanden,
dann erfolgt keine weitere Verfeinerung,
sondern eine Beschreibung durch eine PSpec.
19
Data Dictionary
•
Jeder Datenfluss und jeder Speicher wird im DD definiert
•
Der Zusammenhang zwischen den Datenflüssen
der einzelnen DFDs wird über die Definition im DD hergestellt.
•
Alle Datenflüsse eines untergeordneten DFDs müssen im
übergeordneten DFD
– entweder mit gleichem Namen (hier: D1A, D2A) erscheinen
– oder Teilkomponenten eines Datenflusses sein (hier: D1E = D1E1
+ D1E2, D2E = D2E1 + D2E2).
Gilt dies für alle DFDs, dann liegt Datenintegrität vor (balancing).
20
PSpec
beschreibt einen nicht weiter verfeinerten Prozess
– PSpec beschreibt, wie die Eingabedatenflüsse eines
Prozesses
in die Ausgabedatenflüsse transformiert werden.
– Beschreibung erfolgt durch Pseudocode,
Entscheidungstabellen oder Entscheidungsbäume.
21
Vorgehen SA
•
•
•
•
•
•
Festlegung der Schnittstellen zur
Umwelt des Systems.
Identifizierung aller Eingabe- und
Ausgabedatenflüsse von den
Schnittstellen zum
Prozess 0.
Ermitteln der Funktionen bzw.
Prozesse, die Eingaben in
Ausgaben transformieren.
Identifizierung der Speicher (aus
dem ER-Modell)
Verfeinern / ergänzen der
ermittelten Datenflüsse
Definition der Datenflüsse und
Speicher im Data Dictionary.
•
•
•
•
Überarbeiten des vorliegenden
Modells:
– allfällige Initialisierungen
weglassen
– allfällige Steuerflüsse
weglassen
– trivialen Fehlermeldungen
weglassen
– Sorgfältige und eindeutige
Namenswahl.
schrittweise Erarbeitung der
weiteren Ebenen.
PSpecs für alle nicht weiter
verfeinerten Prozesse erstellen.
Nicht unnötig tief verfeinern
22
UML 2: DataStore
Zentraler Speicherknoten für nicht-transiente Daten.
Bewahrt alle einkommenden Daten auf.
=> DFDs als UML ActivityDiagramme darstellen
«datastore»
Kosten
«datastore»
Personal
Datenbank
Einstellung
{weight=all}
Review der
Angestellten
Nur Neuangestellte
jährlich
Angestellte
einteilen
Martin Jud
Time Event Action
AktivitätsdiagrammeSoftware-Engineering BusinessModel – Activity & Sequence
23
Aus der Vorlesung Softwareengineering von Jörg Hofstetter HTA Luzern
… & Dataflow-Diagram (DFD)
ObjectFlow
Bestellung
Entgegennehmen
Bestellung
Kunde
Quittung
ObjectNode
«datastore»
Kosten
{tägliche
Kostensumme}
Martin Jud
Activity
Action
Bestellung
bearbeiten
Bestellung
Küche
{update Inventar}
DataStore
{update Kosten}
«datastore»
Inventar
Management
Reports
generieren
{tägliche
Bestandesänderungen}
Managment
Report
UML Element
EinführungSoftware-Engineering BusinessModel – Activity & Sequence
24
When to Use
•
•
•
•
Analyzing Use Cases
Understanding Workflows
Describing complicated sequential algorithms
Modeling parallel behavior
There are actually two main strengths to activity diagrams:
1. They can be used very well for visualizing business and workflow
processes. They are not yet SW related and can be easily
understood by users and customers.
2. The support modeling parallel behavior. This again makes them
a very good tool for workflow modeling.
25
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
ActivityDiagram entwickeln müssen um ihn zu verstehen,
ist möglicherweise Refactoring angesagt...
26
Exercise
– Describe the workflow and behavior
of a UseCase in an activtiy diagram:
Describe the standard scenario for
one UseCase.
Create the activity diagram showing
the general workflow and possible
concurrent behavior.
27
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
28
Elements of a Sequence Diagram
aRegistration
Form
Object
aRegistration
Manager
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
29
Advanced Elements
aCustomer:
Customer
UML 1.4
aDatabase:
save()
aTransaction
addCustomer(aCustomer)
new()
Synchronous
Message
Create its own
transaction thread
Asynchronous
Message
finished()
finished()
Self Deletion
30
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.
31
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
32
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
33
Use Case Invocations
a use case may be invoked in a sequence diagram
via a message with the <<include>> stereotype.
34
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.
35
When to Use
• 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.
• SW-Design
• Implementation
36
When NOT to Use
• Collaboration of many objects
• Complex logic
• Behavior of a single object
37
Sequence Diagram in UML 2.0
sd Reservation bestätigen
Lifeline
:Credit Card
System
:System
:Gast
Bereit für Reservation
Zahlungsinfo angeben
Interaction
meineInfo(Zahlungsinfo)
ref
Kreditkarte prüfen(Zahlungsinfo)
create
Reservation ok
Martin Jud
:Reservation
ReservationsNr
SequenzdiagrammeSoftware-Engineering BusinessModel – Activity & Sequence
38
Interaction
sd Kreditkarte prüfen
:Credit Card
System
:System
bittePrüfen(Betrag, Zahlungsinfo)
Autorisierungscode
Martin Jud
39
Lifeline
Lifeline
:System
Martin Jud
Class Name
• Ein Modell Element, welches einen
individuellen Teilnehmer einer Interaktion
repräsentiert.
• Nur eine einzige Entität.
40
Fragment
:Credit Card
System
:System
:Gast
Bereit für Reservation
Interaction
Zahlungsinfo angeben
Fragment
meineInfo(Zahlungsinfo)
ref
Operator
alt
Kreditkarte prüfen(Zahlungsinfo)
[Prüfung = OK]
create
guard
Reservation ok
:Reservation
ReservationsNr
[else]
Reservation fehlgeschlagen
Martin Jud
Separator
41
When NOT to Use
• Collaboration of many objects
• Complex logic
• Behavior of a single object
42
Exercise
• Describe the collaboration of
objects for one scenario.
Use the scenario from above.
Identify the important objects.
Create the sequence diagrams
for the scenario.
43

Activity Diagram

Transcription

Similar documents

Systementwurf mechatronischer Systeme

Vorlesung Softwaretechnik - Lehrstuhl für Betriebliche

12th Narrow Fabrics Conference 8. September

Informix Warehouse – neue Möglichkeiten der Informationsanalyse

XT Commerce - Wunschtacho

Traditionelle „strukturierte“ Spezifikationsmethoden

f i o web.de

Moderne Analyse Methoden (99k PDF)

Modellierung von IuK-Systemen

Zusammenfassung - Software Bakery