9. Operationenmodellierung mit Interaktionsdiagrammen

Größe: px

Ab Seite anzeigen:

Download "9. Operationenmodellierung mit Interaktionsdiagrammen"

Julius Fischer
vor 8 Jahren
Abrufe

1 Inhalt 1. Modellierung funktionaler Aspekte im objektorientierten Design 2. Sequenz- und Kollaborationsdiagramme: Notation und Vergleich 3. Beispiele aus dem POS Terminal Beispiel Lernziele: die UML-Notation für Sequenz- und Kollaborationsdiagramme als Modell der Nachrichtenflüsse zwischen Objekten kennenlernen die spezielle Aussagekraft dieser Diagramme einsetzen lernen ihre Unterschiede verstehen Besonderheiten: das methodische Vorgehen für den eigentlichen objektorientierten Operationendesign (welche Operation wohin?) wird erst im nächsten Kapitel behandelt - hier nur die Notation und der spezifische Modellinhalt Referenzen: Larman, Kapitel 15 G. Booch, J. Rumbaugh, I. Jacobson: The Unified Modelling Language User Guide, Addison-Wesley

Aussagekraft dieser Diagramme einsetzen lernen ihre Unterschiede verstehen Besonderheiten: das methodische Vorgehen für den eigentlichen objektorientierten Operationendesign (welche

2 Modellierung funktionaler Aspekte im objektorientierten Design Hauptziel des Klassendesigns ist die Modularisierung der Funktionen des Systems: Definition von Operationen, und deren Positionierung in geeigneten Klassen die Modellierung dieser Entwurfsentscheidungen kann nicht nur statisch in Klassendiagrammen erfolgen, sondern muss dynamisch in sogenannten Interaktionsdiagrammen erfolgen nur wenn man die Systemdynamik in Form von Nachrichtenfluss modelliert, kann man Entwurfsentscheidungen bewerten (eine Grundregel für alle objektorientierten Systeme, denn ihre Dynamik ist viel komplexer als die nicht-objektorientierter Systeme)

erfolgen, sondern muss dynamisch in sogenannten Interaktionsdiagrammen erfolgen nur wenn man die Systemdynamik in Form von Nachrichtenfluss modelliert, kann

3 was sind Interaktionsdiagramme? Interaktionsdiagramme der UML sind Diagramme, die in einem spezifischen Szenario einen Prozess zeigen, in welchem Objekte - Nachrichten an andere Objekte senden, - andere Objekte erzeugen (löschen) es gibt zwei Arten von Interaktionsdiagrammen: Sequenzdiagramme Kollaborationsdiagramme beide zeigen Objekte, Nachrichtensendung und Objekterzeugung Kollaborationsdiagramme sind aber ähnlicher zu Klassendiagrammen, und zeigen daher mehr Zusammenhang mit der statischen Sicht auf Klassen

Nachrichten an andere Objekte senden, - andere Objekte erzeugen (löschen) es gibt zwei Arten von Interaktionsdiagrammen:

4 message1() :ClassA Kollaborationsdiagramm 1: message2() 2: message3() zur zur Erinnerung (UML): (UML): :ClassA :ClassA ein ein (hier) (hier) unbenanntes Objekt Objekt von von ClassA ClassA mya:classa ein ein benanntes Objekt Objekt von von ClassA ClassA :ClassB :ClassA :ClassB message1() Sequenzdiagramm message2() message3()

Objekt von von ClassA ClassA mya:classa ein ein benanntes Objekt Objekt von von

5 was Interaktionsdiagramme nicht sind Algorithmenspezifikationen, oder Programme ein Interaktionsdiagramm zeigt nur einen möglichen Ablauf ein Algorithmus/Programm enthält alle möglichen Abläufe Datenflussdiagramm: dort fliessen Daten, keine Nachrichten Kontextdiagramm: dort werden nur Interaktionen zwischen Akteuren und dem System als Blackbox modelliert (in Interaktionsdiagrammen wird die Blackbox in ihre Objekte detailliert)

Datenflussdiagramm: dort fliessen Daten, keine Nachrichten Kontextdiagramm: dort werden nur Interaktionen

6 1. Kollaborationsdiagramme illustrieren in einem Netz von Objekten (Graph) Nachrichtenaustausch mit Sequenznummer über Objektverbindungen Richtung d. Nachricht erste interne Nachricht keine Kardinalität makepayment(cashtendered) 1: makepayment(cashtendered) : Register :Sale erste Nachricht (ohne Sequenznummer): stösst das Szenario an Parameter Objekt Beziehungsinstanz Objekterzeugung deutet man mit einer "create"- Nachricht an 1.1: create(cashtendered) :Payment

Nachricht erste interne Nachricht keine Kardinalität makepayment(cashtendered) 1: makepayment(cashtendered) :

7 es gibt mehrere Möglichkeiten für Objektbezeichnungen Sale :Sale s1: Sale Klasse (als Instanz) (anonymes) Objekt benanntes Objekt Objektnamen, a) wenn der Name noch woanders vorkommt, oder b) wenn er etwas über das Objekt in dem speziellen Szenario aussagt a) :classa 1: msg1() obj:classb 2: msg2( obj ) :classc b) :Register additem(...) currentsale:sale

vorkommt, oder b) wenn er etwas über das Objekt in dem speziellen Szenario aussagt a)

8 Nachrichtensequenzierung msg1() erste ;ClassA vierte 1: msg2() 2: msg4() sechste zweite legal numbering: um hierarchische Beziehungen anzuzeigen. z.b.: 2 bewirkt 2.1 und : msg6() :ClassB :ClassC :ClassD 1.1: msg3() 2.1: msg5() dritte fünfte "legal numbering scheme"

1 und 2.2 2.2: msg6() :ClassB :ClassC :ClassD 1.1: msg3() 2.

9 Nachrichtensyntax in Interaktionsdiagrammen variable := message( parameter : parametertype ) : returntype Beispiele: getproductspec(id) spec := getproductspec( id ) spec := getproductspec( id : ItemId ) spec := getproductspec( id : ItemId ) : ProductSpecification Zuweisungen an Variablen zeigt man i.a. nur dann, wenn die Variablen in weiteren Nachrichten vorkommen (z.b. als Parameter) :classa 1: var := msg1() :classb 2: msg2( var) Typen zeigt man nur als nicht-selbstverständliche Hervorhebung

: ProductSpecification Zuweisungen an Variablen zeigt man i.a. nur dann, wenn die Variablen in weiteren Nachrichten vorkommen (z.

10 bedingte Nachrichten werden nur gesendet, wenn die Bedingung wahr ist message1() bedingte Nachricht, mit Test 1 [ color = red ] : calculate() : Foo : Bar echte Verzweigungen der Nachrichtenflüsse schliessen sich aus immer nach msg2 oder msg4 msg1() 2: msg6() :ClassE :ClassA 1a und 1b sind wechselseitig exklusive Nachrichtenflüsse 1a [test1] : msg2() :ClassB :ClassD 1b [not test1] : msg4() 1b.1: msg5() :ClassC 1a.1: msg3()

aus immer nach msg2 oder msg4 msg1() 2: msg6() :ClassE :ClassA 1a und 1b sind wechselseitig exklusive

11 Iterationen / Schleifen runsimulation() : Simulator 1 * [i:=1..n]: num := nextint() : Random Iteration wird mit * angegeben optional kann man Schleifenvariable und Laufbereich angeben t := gettotal() : Sale 1 *: st := getsubtotal() * :SalesLineItem die beiden * Symbole zusammen bedeuten Iteration über Kollektion von Objekten: Nachricht an jedes Objekt doppelte Box: Kollektion

Schleifenvariable und Laufbereich angeben t := gettotal() : Sale 1 *: st := getsubtotal() *

12 Nachrichten an Klassen msg1() Nachricht an Klasse, (bzw. statische Methode) list := synchronizedlist( alist ) : InstanceOfFoo java.util.collections nicht unterstrichen: Klasse

13 Beziehungen zwischen Objekten message1() A:ClassA woher woher kennt kennt das das ClassA ClassA Objekt Objekt das das von von ClassB? ClassB? 1: message2() 2: message3() B:ClassB ein Objekt A kann eine Nachricht nur dann an ein Objekt B senden, wenn es B kennt: es besitzt auf B eine Referenz eine Referenz kann es besitzen auf statische Art als statische Beziehung zwischen Klassen, d.h. wie im Domänenmodell definiert, oder auf dynamische Art, nämlich nur in diesem Augenblick des Szenarios

14 statische «dynamische Beziehungen: Beispiel Heizungsregelung Regler solltemperatur differenztemperatur 1 regelt 1..* Heizung {abstract} status stufe einschalten ausschalten stufeeinstellen getsensoren 1 1..* gehört zu Sensor aktuelletemperatur gettemperatur Klassendiagramm: statische Sicht Ölheizung brennereinstellung brennereinstellen check Elektroheizung sparbetrieb sparbetriebein sparbetriebaus check

.* Heizung {abstract} status stufe einschalten ausschalten stufeeinstellen getsensoren 1 1.

15 statische «dynamische Beziehungen: Beispiel Heizungsregelung Hauptregler A:Regler regelt Ölheizung A:Ölheizung Ölheizung B:Ölheizung regelt 5: einschalten() 1: sensoren := getsensoren() gehört zu 2: gettemperatur() Sensor Treppe:Sensor 3: gettemperatur() «parameter» sensoren[1] Sensor Bad:Sensor «parameter» sensoren[3] Sensor Zimmer1:Sensor gehört zu «parameter» sensoren[2] 4: gettemperatur() Sensor Zimmer2:Sensor gehört zu Kollaborationsdiagramm: dynamische Sicht gehört zu

Treppe:Sensor 3: gettemperatur() «parameter» sensoren[1] Sensor Bad:Sensor «parameter» sensoren[3] Sensor

16 statische «dynamische Beziehungen eine dynamische Beziehung besteht nur temporär zwischen zwei Objekten im Kollaborationsdiagramm sollte angegeben werden dass es eine dynamische Beziehung ist eventuell, woher die Referenz kommt dynamische Beziehungen über folgende Stereotypen angeben: :ClassA «parameter» :ClassB Referenz über ein Parameter einer Methode von A: so kennt A den B :ClassA «global» :ClassB Referenz weil Objekt B global bekannt

Referenz kommt dynamische Beziehungen über folgende Stereotypen angeben: :ClassA «parameter» :ClassB Referenz

17 2. Sequenzdiagramme fokussieren die Aufmerksamkeit auf den zeitlichen Ablauf indem sie (einen Teil) der Lebenslinie von Objekten zeigen makepayment(cashtendered) : Register : Sale makepayment(cashtendered) create(cashtendered) : Payment

von Objekten zeigen makepayment(cashtendered) : Register :

18 Aktivierungsboxen : Register : Sale msg1() msg2() msg3() msg4() msg5() Aktivierungsboxen geben an die Dauer von Methoden ob Objekte rekursiv aufgerufen werden echt parallele Objekte (z.b. threads)

19 Aktivierungsboxen und Zeitangaben für eingebettete Systeme : : :

20 : Register : Sale erzeugte Objekte erst auf Höhe ihrer Erzeugung beginnen lassen makepayment(cashtendered) create(cashtendered) authorize() : Payment Erzeugung (Zerstörung) von Objekten delete() X

21 Verzweigungen in Sequenzdiagrammen: ausnahmsweise : A : B : C message1() [ x < 10 ] calculate() [ x > 15 ] calculate() mit Verzweigungen sparsam umgehen (nicht nötig, alle Fälle anzugeben) Interaktionsdiagramme beschreiben Szenarien, nicht Programme: also ein Durchlauf, nicht sämtliche Möglichkeiten!

22 Iterationen in Sequenzdiagrammen : Simulator : Random : Programmer runsimulation() hours := nextint() work( hours ) * [i:=1..n] eat() oder runsimulation() : Simulator : Random * [i:=1..n]: num := nextint()

23 Iterationen in Sequenzdiagrammen : Sale :SalesLineItem :SalesLineItem t := gettotal() * : st := getsubtotal() doppelte Box: Kollektion

24 Kontrollrückgaben in Sequenzdiagrammen oa : ClassA ob : ClassB oc : ClassC msg1() var := msg2() msg3() msg4(var) sind nur selten nötig

25 statische «dynamische Beziehungen: Beispiel Heizungsregelung hauptregler:regler öla:ölheizung sensoren[i]:sensor regeln() sensoren := getsensoren() gettemperatur() * [i:=1..anzsensoren] einschalten() Sequenzdiagramm: dynamische Beziehungen

Ähnliche Dokumente

Vgl. Oestereich Kap 2.7 Seiten 134-147

Vgl. Oestereich Kap 2.7 Seiten 134-147 1 Sequenzdiagramme beschreiben die Kommunikation/Interaktion zwischen den Objekten (bzw. verschiedenen Rollen) eines Szenarios. Es wird beschrieben, welche Objekte