Objektorientierte Modellierung mit UML

Transkript

1 Objektorientierte Modellierung mit UML Interaktionsdiagramm Der vorliegende Foliensatz basiert auf: M. Seidl, M. Brandsteidl, C. Huemer, G. Kappel: dpunkt.verlag, C. Larman: UML 2 und Patterns angewendet, mitp-verlag,

2 Was passierte bisher? Domänenmodell in Form eines Klassendiagramms wurde erstellt. Sample UP Artifact Relationships Requirements Domänenmodellierung Business Modeling Anforderungen Cashier date... Process Sale Operation: enteritem( ) Post-conditions: -... Sale Use Case Diagram Operation Contracts Domain Model 1 1..* Sales... LineItem Use-Case Model use case names system operations : Cashier quantity objects, attributes, associations Process Sale 1. Customer arrives Cashier makes new sale Use Case Text system events make NewSale() enteritem (id, quantity) : System System Sequence Diagrams... scope, goals, actors, features terms, attributes, validation non-functional reqs, quality attributes Vision Glossary Supplementary Specification Sequenzdiagramm Sequenzdiagramme für Standardablauf ausgewählter Anwendungsfälle sowie für komplexe alternative Szenarien erstellen requirements : Register Design Model : ProductCatalog : Sale Entwurf Design enteritem (itemid, quantity) spec = getproductspec( itemid ) addlineitem( spec, quantity ) Interaktionsdiagramme (dynamische Sicht)... Register makenewsale() enteritem(...)... * 1... ProductCatalog getproductdescription(...)... Klassendiagramme (statische Sicht) 2

3 Inhalt Objektentwurf CRC-Karten Objektdiagramm Interaktionsdiagramme Sequenzdiagramm Kommunikationsdiagramm Von den Anforderungen zum Entwurf Dynamischer OO-Entwurf Interaktionsdiagramm 3

4 Objektentwurf Welche Fragen sind zu beantworten? Welche Verantwortlichkeiten hat das Objekt? Mit welchen anderen Objekten kollaboriert/kommuniziert es? Welche Nachrichten und Daten werden ausgetauscht? CRC-Karten helfen, diese Fragen zu beantworten! 4

5 CRC-Karten Class-Responsibility-Collaboration-Karten Karteikarten Vorderseite Klassenname (Class) Oberklasse Rückseite Beschreibung Verantwortlichkeiten und Aufgaben der Klasse Was muss die Klasse tun? (kurz, Zeitwort) (Responsibilities) Klassen, die benötigt werden, um Aufgaben zu erfüllen. (Collaborators) Attribute Nicht nur Inhalt, sondern auch Anordnung der Karten spielt eine Rolle CRC-Karten sind nur Diskussionsgrundlage Vorteil: kein zwingender Formalismus, keine Einschränkung des Designers 5

6 CRC-Karten Anordnung Während Diskussionen: Verschieben und Umlegen von Karten, Zeigen auf Karten Rollenspiele ("Was-wäre-wenn-Szenarios" mit Objekten durchspielen; Szenarien durchspielen) Lockere Konventionen: nahe beieinander: Verwandtschaft, Kooperation, wechselseitige Abhängigkeit untereinander: Steuerung, Benutzung, Abhängigkeit der unteren Klasse von der oberen, Subklassenrelation zeitlicher Ablauf überlappend: Referenz, Besitz, logische oder physische Umschließung 6

7 CRC-Karten Beispiel Zusammenspiel der Klassen einer Bibliothek für graphische Benutzerschnittstellen Application Initialisierung Öffnen des Hauptfensters Verarbeitung von Ereignissen Aufräumen MenuBar Window Event Steuerung, Benutzung View Darstellung der Daten (Model) Bearbeiten von Befehlen Anpassung der Fensterdimension Window Öffnen, Bewegen, Schließen Verwalten der Menüs Delegieren d. Befehle an die enthaltende View Application Window Application Menü View Referenz, Besitz 7

8 CRC-Karten Lasst uns weiter machen... 8

9 Objektentwurf CRC-Karten Interaktionsdiagramm 9

10 Objektentwurf CRC-Karten 10

11 Objektdiagramm Beschreibt den strukturellen Aspekt eines Systems auf Instanzebene in Form von Objekten und Links Momentaufnahme (snapshot) des Systems konkretes Szenario Ausprägung zu einem Klassendiagramm Beispiel: Klasse Benutzer - name: String - berechtigung: Recht - pwd: String - anzahl: Integer + pruefepw(string): Boolean + ermittleanzahl(): Integer Objekt josef:benutzer - name: Josef - berechtigung: E/L - pwd: anzahl: 4 Objektname:Klassenname 11

12 Objektdiagramm Basiskonzepte Basiskonzepte des Objektdiagramms Instanz einer Klasse: Objekt Instanz einer Assoziation: Link Instanz eines Datentyps: Wert Einheitliche Notationskonventionen Gleiches Notationselement wie auf Typebene benutzen Unterstreichen (bei Links optional) Objektdiagramm muss nicht vollständig sein Z.B. können Werte benötigter Attribute fehlen, aber auch Instanzspezifikation abstrakter Klassen modelliert werden 12

13 Diagrammart Objektdiagramm Basiskonzepte - Beispiel Strukturdiagramm Interaktionsübersichtsdiagramm Sequenzdiagramm Verhaltensdiagramm Klassendiagramm Paketdiagramm Komponentendiagramm Verteilungsdiagramm Objektdiagramm Kompositionsstrukturdiagramm Zustandsdiagramm Aktivitätsdiagramm Anwendungsfalldiagramm Interaktionsdiagramm Kommunikationsdiagramm Zeitdiagramm Klassendiagramm 1..* gehört zu Kalender - benutzer: String - istoffen: boolean - + setzebenutzer(string) + istoffen(): Booelan + ermittleansicht(): Ansicht + ermittletermine(): Termine[] * Termin - beginn: DatumZeit - dauer: Zeit - + setzebeginn(datumzeit) + ermittledauer(): Zeit + gehört zu k1kalender : Kalender - benutzer = Josef t1 : Termin - - dauer = 2 Objektdiagramm gehört zu t2 : Termin - - dauer = 4 k2kalender : Kalender - benutzer = Max gehört zu 13

14 Diagrammart Strukturdiagramm Verhaltensdiagramm Interaktionsdiagramme Zeigen wie Nachrichten zwischen verschiedenen Interaktionspartnern in einem bestimmten Kontext ausgetauscht werden (Modellierung der Operationen einer Klasse). 4 Arten von Interaktionsdiagrammen: Interaktionsübersichtsdiagramm Sequenzdiagramm Klassendiagramm Paketdiagramm Komponentendiagramm Verteilungsdiagramm Objektdiagramm Kompositionsstrukturdiagramm Zustandsdiagramm Aktivitätsdiagramm Anwendungsfalldiagramm Interaktionsdiagramm Kommunikationsdiagramm Zeitdiagramm Sequenzdiagramm zeigt den zeitlichen und logischen Nachrichtenfluss sd P rolle1:typ rolle2:typ rolle3:typ rolle4:typ m1 m2 m3 Kommunikationsdiagramm ist "strukturell" orientiert comm P rolle1:typ 1:m1 rolle2:typ 1.1:m2 1.2:m3 c rolle3:typ rolle4:typ Interaktionsdiagramm 14

15 Diagrammart Sequenzdiagramm Einführung Zeigen Nachrichten- und Datenaustausch Zeitliche und logische Abfolge steht im Vordergrund Gut geeignet für exemplarische Darstellung von Abläufen (bspw. von konkreten Anwendungsfällen) Zwei Achsen Zeitachse vertikal Objekte horizontal Strukturdiagramm Interaktionsübersichtsdiagramm Sequenzdiagramm Verhaltensdiagramm Klassendiagramm Paketdiagramm Komponentendiagramm Verteilungsdiagramm Objektdiagramm Kompositionsstrukturdiagramm Zustandsdiagramm Aktivitätsdiagramm Anwendungsfalldiagramm Interaktionsdiagramm Kommunikationsdiagramm Zeitdiagramm Wie läuft die Kommunikation in meinem System ab? Wie soll das System mit seiner Umwelt interagieren? Interaktionsdiagramm 15

16 Basiskonzepte Diagrammrahmen Zeitachse Interaktionspartner sd Interaktionsname (p:typ): Typ loop (1,*) [a<1] Lebenslinie Nachricht Zustandsinvariante {p=15} p=15 p=15 {locked} locked locked Kombiniertes Fragment loop (1,*) [a<1] Interaktionsdiagramm 16

17 Basiskonzepte Parameter, lokale Attribute Darstellung von Parametern und lokalen Attributen Interaktion sdiagram m Lokale Attribute void func (int par1, int par2) { int x = 0; String y = " Test "; } Parameter sd func (int par1, int par2) x:int = 0 y:string = "Test" Variante 2: sd func (int par1, int par2) x:int = 0 y:string = "Test" 17

18 Basiskonzepte - Lebenslinie Eine Lebenslinie beschreibt genau einen Interaktionspartner (z.b. Klassen) Notation Name der Instanz Typname des Interaktionspartners pers1:person Lebenslinie, die eine benannte Instanz repräsentiert. Kopf der Lebenslinie rolle:typ Lebenslinie «destroy» Lebenszeit persons: ArrayList<Person> Lebenslinie, die eine Instanz einer ArrayList-Template-Klasse repräsentiert, die Person-Objekte speichern soll. Löschsymbol Interaktionsdiagramm 18

19 Basiskonzepte - Lebenslinie: Ereignisspezifikation Interaktionen werden als Folge von Ereignisspezifikationen auf Lebenslinien betrachtet Beispiel für Ereignisspezifikationen Senden und Empfangen von Nachrichten auf verschiedenen Lebenslinien oder der gleichen Lebenslinie s:sender e:empfänger Sendeereignis Nachricht() Empfangsereignis Interaktionsdiagramm 19

20 Basiskonzepte - Lebenslinie: Reihenfolge von Ereigniseintritten auf einer Lebenslinie auf verschiedenen Lebenslinien m3 m1 m3 m1 Trace1: m1 m3»zeitlich vor«trace1: m1 m3 Trace2: m3 m1 auf verschiedenen Lebenslinien, verbunden durch Nachrichtenaustausch m3 m2 m1 Trace1: m1 m2 m3 Trace = Folge von konkreten Ereigniseintritten - bestimmt den Ablauf einer Interaktion zur Laufzeit Interaktionsdiagramm 20

21 Basiskonzepte - Lebenslinie: Ausführungsspezifikation (-fokus) Die Ausführung einer Operation wird durch zwei Ereignisspezifikationen (Start und Ende) auf der gleichen Lebenslinie definiert Diese so genannte Ausführungsspezifikation (oft als Kontrollfokus bezeichnet) kann durch einen Balken dargestellt werden Ausführungsarten Direkt Interaktionspartner führt Verhalten selbst aus Nachrichtenaufruf Rücksprung Ablauf der Aktion (i. d. Regel ein Methodenaufruf) Startereignisspezifikation Ausführungsspezifikation Endeereignisspezifikation Indirekt Ausführung wird an andere Interaktionspartner delegiert Interaktionsdiagramm 21

22 Basiskonzepte - Nachricht Arten der Nachrichtenübermittlung Synchroner Kontrollfluss Der Sender wartet bis zur Beendigung der Interaktion, die durch die Nachricht ausgelöst wurde m1(p1,p2) Asynchroner Kontrollfluss Die Nachricht wird als Signal betrachtet Der Sender wartet nicht auf das Ende der Interaktion m2 Antwortnachricht (optional) att: Name eines Attributs dem der Rückgabewert zugewiesen werden soll m1: Name der Nachricht, auf die geantwortet wird wert: Rückgabewert att=m1:wert Antwortnachrichten sollten dort eingezeichnet werden, wo sie zusätzliche Informationen für den Leser bereitstellen sonst nicht, da Diagramme unübersichtlich wird. Interaktionsdiagramm 22

23 Basiskonzepte - Nachricht: Spezielle Nachrichtenarten Objekterzeugung Ermöglicht, einen Interaktionspartner erst im Laufe der Interaktion zu erzeugen Verlorene Nachricht Senden einer Nachricht an unbekannten oder nicht relevanten Interaktionspartner Gefundene Nachricht Empfang einer Nachricht von einem unbekannten oder nicht relevanten Interaktionspartner Zeitkonsumierende Übertragung new ( ) lost found Nachrichten an»self«oder»this«interaktionsdiagramm 23

24 Basiskonzepte - Lebenslinie: Aktives Objekt Aktive Objekte verfügen über eigenen Kontrollfluss (Prozess oder Thread) Können unabhängig von anderen Objekten operieren Notation Kopf der Lebenslinie wird links und rechts mit doppeltem Rand versehen durchgehender Balken über gesamte Lebenslinie Interaktionsdiagramm 24

25 Basiskonzepte - Aktives Objekt: Beispiel :ClockStarter "Rufe mit dem new-operator den Konstruktor auf." aktives Objekt startclock create :Clock run public class ClockStarter { public void startclock() { Thread t = new Thread(new Clock()); t.start(); //asynchronous call to the //run-method on the Clock... } } //... public class Clock implements Runnable { public void run() { while (true) //loop forever on own thread { //... } } //... } Interaktionsdiagramm 25

26 Basiskonzepte - Beispiel Beispiel: Berechnung der Dauer eines Termins sd Dauer berechnen b1 :Benutzer gesdauer :Kalender besprechung [1]:Termin besprechung [2]:Termin dauer dauer: sitzungszeit gesdauer: gesamt dauer dauer: sitzungszeit Interaktionsdiagramm 26

27 Basiskonzepte - Zustandsinvariante Zusicherung, dass eine bestimmte Bedingung zu einem bestimmten Zeitpunkt erfüllt ist Bezieht sich immer auf eine bestimmte Lebenslinie Wird vor Eintritt des darauf folgenden Ereignisses ausgewertet Falls Zustandsinvariante nicht erfüllt ist - Fehler Notationsvarianten: {p=15} {locked} p=15 locked p=15 locked Interaktionsdiagramm 27

28 Basiskonzepte - Aufruf von Klassenmethoden Nachricht an Klasse oder ein Aufruf einer statischen Methode Klassenobjekt wird als eine Instanz einer Metaklasse dargestellt. dox :Foo getavailablelocales() «metaclass» Calendar locales=getavailablelocales() public class Foo { public void dox() { // Aufruf einer statischen Methode der Klasse Calendar Locale[] locales = Calendar.getAvailableLocales(); //... } //... } Interaktionsdiagramm 28

29 Basiskonzepte - Polymorphe Nachrichten {abstract} Payment authorize() {abstract}... Payment ist eine abstrakte Oberklasse mit konkreten Unterklassen, die die polymorphe authorize-operation implementieren. CreditPayment authorize()... DebitPayment authorize()... :Register polymorphe Nachricht {abstract} :Payment Objekt in der Rolle einer abstrakten Klasse dox authorize Weitere Details über diese Nachricht sollten nicht mehr modelliert/gezeigt werden :DebitPayment :Foo :CreditPayment :Bar authorize doa authorize dox dob Interaktionsdiagramm 29 Separate Diagramme für jeden polymorphen konkreten Fall

30 Kombinierte Fragmente Modellierung von Kontrollstrukturen Bestandteile: Operator und Operanden Operator Definiert Art des kombinierten Fragments 12 vordefinierte Operatoren Operand Ein Operator enthält ein oder mehrere Operanden, je nach Operatorart Kann Interaktionen, kombinierte Fragmente (Schachtelung!) und Referenzen auf Sequenzdiagramme umfassen Interaktionsdiagramm 30

31 Kombinierte Fragmente - Notation Kombiniertes Fragment wird wie Sequenzdiagramm mit Rahmen dargestellt Art des Fragments wird durch Operator im Pentagon festgelegt (default: seq) Operatoren sd Beispiel alt Kombinierte Fragmente Operand 1 Operanden werden durch gestrichelte Linien voneinander getrennt loop Operand1 Operand 2 Interaktionsdiagramm 31

32 Filterungen und Zusicherungen Parallelität und Ordnung Verzweigungen und Schleifen Sequenzdiagramm Kombinierte Fragmente - Operatorarten Operator alt opt break loop seq strict par critical ignore consider assert neg Zweck Alternative Interaktionen Optionale Interaktionen Ausnahme Interaktionen Iterative Interaktionen Sequentielle Interaktionen mit schwacher Ordnung (Default-Operator) Sequentielle Interaktionen mit strenger Ordnung Parallele Interaktionen Atomare Interaktionen Irrelevante Interaktionen Relevante Interaktionen Zugesicherte Interaktionen Ungültige Interaktionen 32

33 Kombinierte Fragmente Verzweigungen: alt-operator Darstellung von zwei oder mehreren alternativen Interaktionsabläufen Zur Laufzeit wird maximal ein Operand ausgeführt Auswahl eines Operanden anhand von Überwachungsbedingungen Boolscher Ausdruck in eckigen Klammern Vordefinierte else-bedingung: Operand wird ausgeführt, falls die Bedingungen aller anderen Operanden nicht erfüllt sind Überwachungsbedingung alt [a<1] [else] Interaktionsdiagramm 33

34 Kombinierte Fragmente Verzweigungen: opt- und break-operator Überwachungsbedingung steuert Durchlauf der Interaktionen Optionale Interaktionen Ausnahme-Interaktionen opt [a<1] break [a<1] } Interaktionen die unabhängig vom opt-fragment ausgeführt werden } Interaktionen die im Falle des break ([a<1]) nicht ausgeführt werden Interaktionsdiagramm 34

35 Kombinierte Fragmente Schleifen: loop-operator Darstellung einer Schleife über einen bestimmten Interaktionsablauf Fragment enthält nur einen Operanden Ausführungshäufigkeit wird durch Zähler mit Unter- und Obergrenze dargestellt Optional: Überwachungsbedingung, wird bei jedem Durchlauf überprüft Zählergrenzen Überwachungsbedingung Schleife wird solange durchlaufen, bis a >= 1 loop (1,*) [a<1] Interaktionsdiagramm 35

36 Kombinierte Fragmente loop-operator: Beispiel Iteration über eine Collection Repräsentiert eine Instanz aus einer Collection von SalesLineItem-Objekte. Der Wert i bezieht sich auf dasselbe i in der Schleifenbedingung. :Sale lineitems[i]:saleslineitem t=gettotal loop [i < lineitems.size] st = getsubtotal i++ Aktionselement kann beliebige Sprachbefehle enthalten (Inkrement auch als Notiz darstellbar) :Sale lineitems[i]:saleslineitem t=gettotal loop st = getsubtotal Interaktionsdiagramm 36

37 Kombinierte Fragmente Verzweigungen und Schleifen: Beispiel 1/6 Aufgabe: Der Anwendungsfall "Termin löschen" des Onlinekalenders soll mittels Sequenzdiagramm modelliert werden. Zunächst muss sich der Benutzer in der Terminmaske mittels Passwort einloggen. Der Onlinekalender prüft das Passwort. Der Benutzer wird nach jeder Eingabe des PW informiert, ob es korrekt war. Der Benutzer hat 3 Versuche für die PW-Eingabe. Nach dem 3. Versuch wird er informiert, dass der Vorgang abgebrochen wird, und die gesamte Interaktion "Termin löschen" wird abgebrochen. Konnte sich der Benutzer einloggen, so wird ihm der aktuelle Kalender mit den gesamten Terminen gezeigt. Der Benutzer kann nun einen Termin wählen und versuchen diesen zu löschen. Interaktionsdiagramm 37

38 Kombinierte Fragmente Verzweigungen und Schleifen: Beispiel 2/6 Der Termin überprüft durch eine Anfrage beim Onlinekalender, ob der Benutzer berechtigt ist, diesen Termin zu löschen, indem der Termin die Benutzerkennung b anfordert. Ist der Benutzer nicht berechtigt, wird er darüber informiert. Ansonsten werden alle Notifikationen aus der Queue der noch zu versendenden Notifikationen gelöscht. die Einträge dieses Termins aus den Terminlisten aller Teilnehmer gelöscht. die Teilnehmer, die online sind, durch einen Hinweis informiert. Schließlich wird die Terminmaske beendet. Interaktionsdiagramm 38

39 Kombinierte Fragmente Verzweigungen und Schleifen: Beispiel 3/6 sd Termin löschen b1 :Benutzer :Termin- Maske te[i] :Termin :Kalender n[j] :Notifikation :Queue tn[k] :Teilnehmer loop (1,3) prüfe Passwort (pwd) anzeige (ergebnis) [richtiges Passwort] prüfe Passwort (pwd) ergebnis= prüfepasswort(pwd) Interaktionsdiagramm 39

40 Kombinierte Fragmente Verzweigungen und Schleifen: Beispiel 4/6 sd Termin löschen b1 :Benutzer :Termin- Maske te[i] :Termin :Kalender n[j] :Notifikation :Queue tn[k] :Teilnehmer break [falsches Passwort] melde Abbrechen Abbrechen anzeige Kalender anzeige Kalender lösche(te[i]) lösche(te[i]) benutzer benutzer:b b: Benutzeridentifikation Interaktionsdiagramm 40

41 Kombinierte Fragmente Verzweigungen und Schleifen: Beispiel 5/6 sd Termin löschen b1 :Benutzer :Termin- Maske alt melde kein Löschrecht te[i] :Termin kein Löschrecht [b ist nicht berechtigt] :Kalender n[j] :Notifikation :Queue tn[k] :Teilnehmer [b ist berechtigt] loop (0,anzahlNotifikationen) lösche loop... siehe nächste Folie x deq(n[j]) j:=nrakt- Durchlauf Interaktionsdiagramm 41

42 Kombinierte Fragmente Verzweigungen und Schleifen: Beispiel 6/6 sd Termin löschen b1 :Benutzer :Termin- Maske te[i] :Termin :Kalender n[j] :Notifikation :Queue tn[k] :Teilnehmer alt Operand 1... siehe vorige Folie x Operand 2... siehe teilweise vorige Folie loop (1,anzahlTeilnehmer) löschetermin(self) info(self,te[i]) x k:=nrakt- Durchlauf opt [tn[k] ist online] f :Infonew(hinweis) Fenster Interaktionsdiagramm 42

43 Modularisierung Zweck: Wiederverwendung und Reduktion der Komplexität Interaktionsreferenz Zur Referenzierung anderer Sequenzdiagramme Dadurch können Interaktionsabläufe und Lebenslinien zerlegt werden Verknüpfungspunkt Zur Verbindung von Nachrichten zwischen Sequenzdiagrammen, Interaktionsreferenzen oder kombinierten Fragmenten Interaktionsdiagramm 43

44 Modularisierung - Interaktionsreferenz 1/3 Interaktionen des referenzierten Sequenzdiagramms werden ausgeführt, so als wären sie direkt in das referenzierende Diagramm eingebettet Eventuell vorhandene Parameter werden gebunden Nach Ausführung der referenzierten Interaktionen wird unterhalb der Interaktionsreferenz fortgesetzt Interaktionsdiagramm 44

45 Modularisierung - Interaktionsreferenz 2/3 Zerlegung von Interaktionsabläufen Rahmen mit Pentagon in der linken oberen Ecke Pentagon enthält Schlüsselwort ref Rahmen enthält Namen der referenzierten Interaktion, optional Parameter und Rückgabewerte sd Beispiel X Y Z Bezieht sich auf das benannte Sequenzdiagramm sdname ref sdname(par1, par2): rückgabewert sd sdname(par1, par2):rückgabewert X Y Z Interaktionsdiagramm 45

46 Modularisierung - Interaktionsreferenz 3/3 Zerlegung von Lebenslinien Lebenslinien können interne Strukturen aufweisen, für die eigene Sequenzdiagramme spezifiziert werden können Schlüsselwort ref im Kopf der Lebenslinie sd b1 sd b2 t z:u ref b2 :teil1 :teil2 v1 v1 v2 v2 Interaktionsdiagramm 46

47 Modularisierung - Verknüpfungspunkt 1/2 Zweck: ermöglicht den Nachrichtenfluss zwischen Sequenzdiagrammen und/oder kombinierten Fragmenten und/oder Interaktionsreferenzen Dadurch können hereinkommende oder hinausgehende Nachrichten modelliert werden Verknüpfungspunkte zwischen Sequenzdiagrammen können entweder implizit über Namensgleichheit oder explizit über eine Interaktionsreferenz modelliert werden Interaktionsdiagramm 47

48 Modularisierung - Verknüpfungspunkt 2/2 Spitze oder Ende eines Nachrichtenpfeils berührt Rand des Rahmes Optional: Name für Verknüpfungspunkt wird neben Schnittpunkt von Nachrichtenpfeil und Rahmen angegeben sd b1 Verknüpfungspunkte- Sequenzdiagramm Verknüpfungspunkte- Interaktionsreferenz Verknüpfungspunktekombiniertes Fragment t v1 v2 m1 ref opt u b2 v1 v2 sd b2 X v1 v2 Y Interaktionsdiagramm 48

49 Modularisierung - Beispiel: Interaktionsreferenz sd Termin löschen b1 :Benutzer ref break melde Löschen Abbrechen :Termin- Maske te[i] :Termin PrüfePasswort löschen Abbrechen :Kalender [falsches Passwort] sd PrüfePasswort b1 :Benutzer :Termin- Maske loop (1,3) [richtiges n[j] Passwort] tn[k] :Notifikation Passwort(pwd) nehmer prüfe prüfe :Queue :Teil- Passwort(pwd) anzeige (ergebnis) ergebnis= prüfepasswort(pwd) :Kalender anzeige Kalender anzeige Kalender lösche(te[i]) lösche(te[i]) benutzer b 49

50 Lasst uns weiter machen... 50

51 Zusammenfassung "If you want to explore multiple alternative interactions quickly, you may be better off with CRC cards, as that avoids a lot of drawing and erasing. It's often handy to have a CRC card session to explore design alternatives and then use sequence diagrams to capture any interactions that you want to refer to later." [Fowler] Zeigt klar die Abfolge oder die zeitliche Reihenfolge von Nachrichten (~ Message Passing) Beispielhaft wichtige (kritische) Interaktionssequenzen modellieren Auf Nebensächlichkeiten verzichten, Sequenzdiagramme sind schnell überladen Kontrollstrukturen lassen sich mit Sequenzdiagrammen nur umständlich darstellen (Aktivitätsdiagramm bzw. Code ist dafür besser geeignet) Zwang, Diagramme nach rechts zu erweitern, wenn neue Objekte hinzugefügt werden; braucht den horizontalen Raum schnell auf Interaktionsdiagramm 51

52 Zusammenfassung Sie haben die Modellierung mit Interaktionsdiagrammen verstanden, wenn Sie wissen wofür Interaktionsdiagramme verwendet werden. aus welchen Komponenten ein Sequenzdiagramm besteht. was mit einer Lebenslinie gemeint ist. wie die Reihenfolge von Ereigniseintritten im Sequenzdiagramm definiert ist. was der Unterschied zwischen direkter und indirekter Ausführung, sowie aktiven und passiven Objekten ist. welche Operatoren im Sequenzdiagramm zur Verfügung stehen. wie Nebenläufigkeit ausgedrückt werden kann. Interaktionsdiagramm 52

53 Exkurs: Design Pattern: Singleton Interaktionsdiagramm 53