 |
| | | | | Beschreibung | | Eine weitere Ausarbeitung des Aktivitätsdiagramms aus Abbildung 1 im Baustein "Nutzfallablauf" könnte z. B. den Datenfluss innerhalb des Ablaufs hinzufügen.
Abbildung 1: Ablauf des Nutzfalles "Meilen gutschreiben" mit Datenflüssen"
Hier wurde eine andere Notation für Datenfluss als in Abbildung 1 im Baustein "Prozessablauf II" verwendet. Insgesamt gibt es drei alternative Notationen, die auch kombiniert werden können. Die traditionelle, an UML 1.x angelehnte Variante („freistehende“ Datenflussknoten)verbindet Aktionen und Objektflussknoten explizit mit DataFlow (dt.: Datenfluss(kante)), siehe Abbildung 2 (links). Diese Notation macht den Datenfluss explizit und erlaubt die notationelle Einbindung von Datenspeichern (siehe unten).
Die zweite Notationsvariante (Abbildung 2, zweites Fragment von links, „ergänzte“ Datenflussknoten) eignet sich besonders für die schrittweise Verfeinerung von Aktivitätsdiagrammen, da hier die Objektflussknoten (nachträglich und teilweise) an
Kontrollflusskanten ergänzt werden können. Die Datenflusskanten werden in dieser
Darstellung unterdrückt, sind aber im Modell vorhanden.
Abbildung 2: Drei gleichwertige Notationen von Datenfluss: "freistehende", "ergänzt" und "Pin" Datenflussknoten (von links nach rechts); Kombination dieser Notationen (rechts außen) sind zwar möglich, aber meist nicht sinnvoll und werden in der Regel unterdrückt
Die dritte Variante ist die so genannte Pin-Notation (Abbildung 2, zweites Fragment
von rechts). Dabei wird hervorgehoben, dass Daten Eingabe oder Ausgabe von Aktionen sein können, bzw. es wird für eine bestimmte Aktion angezeigt, welches ihre
Parameter und Resultate sind. Diese Varianten lassen sich im Prinzip kombinieren, siehe Abbildung 2 (rechts). Weitere Details zur Pin-Notation folgen unten. Das Aktivitätsdiagramm aus Abbildung 1 lässt sich um Partitionen ergänzen (siehe Abbildung 1 im Baustein "Einbettung"). Hier lässt sich ein wichtiger methodischer Zusammenhang ablesen. Das Diagramm zeigt, wo der Datenfluss im Gesamtsystem die Partitionsgrenzen, also die Subsystemgrenzen überschreitet und welche Daten jeweils weitergeleitet werden. Daraus kann man erschließen, dass z. B. zwischen „Air Partner System“ und „Meilenverwaltung“ eine Verbindung bestehen muss, über die „Passagier“-Daten ausgetauscht werden. Genauso lässt sich ablesen, dass zwischen „Meilenverwaltung“ und „Mitgliederverwaltung“ Daten des Typs „Meilenkonto“ ausgetauscht werden. Daraus kann man das Diagramm in Abbildung 1 im Baustein "Objektflussknoten" ableiten. Die Reihenfolge der Abbildungen Abbildung 1 im Baustein "Nutzfallablauf" bis Abbildung 1 im Baustein "Einbettung" entspricht einem methodischen Vorgehen in drei Schritten: Zuerst werden die zu erledigenden Aufgaben festgelegt. Dann werden diese Aufgaben durch die ein- und ausgehenden (relevanten) Daten näher beschrieben. Schließlich werden die Aufgaben an organisatorische oder technische Einheiten verteilt. Aus dieser Verteilung können Schnittstellen zwischen den Einheiten abgeleitet werden.
Zurück zum Überblick Aktivitäten UML 2.0 (Überblick)
Nächster Gliederungspunkt Einbettung
| |
| | | | | | | | | | | | | Zu dieser Seite wurden noch keine Kommentare oder Bewertungen abgegeben. |
|
| | | | |  | Übergeordnet | | | | | | | | | | | Datenfluss | | | | |  | Untergeordnet | | | | | | | | | | | | | | | |
|
Glossar 
Forschungsprojekte 
Anbieterverzeichnis 
Datenbanksuche 
Highlights 
Eintrag kommentieren
