Objekt-orientierte Analyse (2) - Verhaltensbeschreibung -

Transkript

1 Objekt-orientierte Analyse (2) - Verhaltensbeschreibung - Software Engineering 1 WS 2011/2012 Dr. Ina Schaefer Software Systems Engineering Technische Universität Braunschweig (mit Folien von Prof. B. Rumpe)

2 Systemmodellierung Analyse (system analysis) Anforderungs- Ermittlung (requirements elicitation) Anforderungs- Spezifikation (Lastenheft) Systemmodellierung (system modelling) Systemspezifikation (Pflichtenheft) Entwurf! Präzise Beschreibung der Systemfunktionen Was ist zu realisieren, ohne das Wie vorherzubestimmen Dr. Ina Schaefer Software Engineering 1 Seite 2

3 Überblick Modellierung von Szenarien mit Sequenzdiagrammen Modellierung von Verhalten mit Zustandsdiagrammen (Statecharts) Modellierung von Abläufen in Aktivitätsdiagrammen Pflichtenheft Ziele und Aufgaben Gliederungsschema Dr. Ina Schaefer Software Engineering 1 Seite 3

4 Szenarien in der Objektorientierten Analyse Klassen finden Assoziationen und Aggregationen finden Attribute finden Operationen finden Szenarien finden und prüfen Vererbungsstrukturen finden Szenarien prüfen Klassenkandidaten finden und Verhalten zuordnen Assoziationen und Aggregationen finden Attribute finden Vererbungsstrukturen finden Datenorientierte Vorgehensweise z.b. OMT Objekt-Lebenszyklen erstellen Operationen spezifizieren Strukturen überprüfen Paket-Struktur finden Verhaltensorientierte Vorgehensweise z.b. OOSE Dr. Ina Schaefer Software Engineering 1 Seite 4

5 Szenarien Definition: Ein Szenario ist eine Beschreibung einer beispielhaften Folge von Interaktionen von Akteuren mit dem System zur Beschreibung eines Anwendungsfalls. Es gibt Szenarien für Normalfälle ('gut-fälle') und Ausnahmefälle. Anwendungsgebiete: Normalfall-Szenarien zur Diskussion mit Anwendern Ausnahmefall-Szenarien zur Erkennung abzufangender Fehlerquellen Testszenarien um festzulegen, welche Tests auszuprobieren sind In Abläufen erzeugte Szenarien, um Debugging durchzuführen Dr. Ina Schaefer Software Engineering 1 Seite 5

6 Einfaches Sequenzdiagramm Objekte werden oben angeordnet Die Zeitlinie schreitet für alle Objekte gleich voran Ein Sequenzdiagramm zeigt den Nachrichten- bzw. Ereignisfluss zwischen Objekten Objekt c:customer b:bank InsertCard getaccountnr Nachricht return( nr) Zeitlinie (nach unten) Dr. Ina Schaefer Software Engineering 1 Seite 6

7 Grundlegende SD Elemente Objektsymbol: Objektidentifikator c:customer Klassenname Zeitlinie: ohne Aktivierung Aktivierungsbalken Nachrichtenname Parameter: optional angeben Pfeile: transfer( amnt,rcva) Kommunikationsform nicht festgelegt synchrone Kommunikation asynchrone Kommunikation Dr. Ina Schaefer Software Engineering 1 Seite 7

8 Pfeilarten Neutrale Pfeile: legen den Kommunikationsmechanismus nicht fest erlauben diese Entscheidung später zu treffen Synchrone Pfeile: Interaktion ist ein gemeinsames Ereignis zwischen Sender und Empfänger keine Verzögerung, z.b. wie ein Telefongespräch Beispiele: Methodenaufruf Asynchrone Pfeile: Senden und Empfang einer Nachricht sind unterschiedliche Ereignisse Normalerweise ist Verzögerung im Spiel, wie bei SMS-Senden Empfänger muss nicht sofort bereit sein, die Nachricht zu empfangen Dr. Ina Schaefer Software Engineering 1 Seite 8

9 Aktivierungsbalken (Aktivierung) Aktivierungsbalken erlauben anzuzeigen, wenn ein Objekt aktiv ist können den Kontrollfluss im System darstellen können verschachtelt werden (Objektrekursion) c:customer b:bank transfer(receiver,amount) acknowledged logtransfer(amount) Dr. Ina Schaefer Software Engineering 1 Seite 9

10 Returns Returns zeigen an, wenn der Kontrollfluss zum Aufrufer zurück geht welches Ergebnis dabei übertragen wird Spezielle Pfeile zeigen Returns an (diese sind optional) Asynchrone Nachrichten erlauben keine Returns b1:bank b2:bank BTransfer (rcvb, rcva, amnt) true Expliziter Return Dr. Ina Schaefer Software Engineering 1 Seite 10

11 Objekterzeugung und -löschung Objekte die erzeugt werden, werden an der Erzeugungsstelle angegeben Eine create-nachricht zeigt direkt auf das Objekt Objektlöschung wird durch ein Kreuz am Ende der Zeitlinie angezeigt (Java kennt keine explizite Objektlöschung.) c:customer b1:bank Erzeugung b2:bank transfer ( rb,ra,a) Transaction( ra,a) t:transaction BTransfer(t) ack(t) delete Löschung Dr. Ina Schaefer Software Engineering 1 Seite 11

12 Zusammenfassung: Sequenzdiagramme Szenarien werden durch Sequenzdiagramme dargestellt Ein Sequenzdiagramm besteht aus einer horizontal angeordneten Menge von Objekten nach unten voranschreitenden Zeitlinien und synchronen oder asynchronen Interaktionen zwischen den Objekten Anwendungen: Systeminterne Kommunikation Kommunikation zwischen System und Anwender Sequenzdiagramme sind exemplarisch und können daher keine vollständigen Verhaltensbeschreibungen sein. Es gibt Erweiterungen für Alternativen, Wiederholung etc. Dr. Ina Schaefer Software Engineering 1 Seite 12

13 Verhalten in der Objektorientierten Analyse Klassen finden Assoziationen und Aggregationen finden Attribute finden Operationen finden Szenarien finden und prüfen Vererbungsstrukturen finden Szenarien prüfen Klassenkandidaten finden und Verhalten zuordnen Assoziationen und Aggregationen finden Attribute finden Vererbungsstrukturen finden Datenorientierte Vorgehensweise z.b. OMT Objekt-Lebenszyklen erstellen Operationen spezifizieren Strukturen überprüfen Paket-Struktur finden Verhaltensorientierte Vorgehensweise z.b. OOSE Dr. Ina Schaefer Software Engineering 1 Seite 13

14 Beispiel: Zustandsmodell einer Tür entriegeln,! schließen! öffnen,! verriegeln,! entriegeln! verriegeln! geschlossen! entriegeln! öffnen! schließen! offen! abgesperrt! öffnen,! schließen,! verriegeln! Dr. Ina Schaefer Software Engineering 1 Seite 14

15 Semantik eines Zustandsmodells Die Semantik eines Zustandsmodells ist definiert als Menge von Sequenzen: in der Theoretischen Informatik: Menge von "akzeptierten Wörtern" (über Grundalphabet von Ereignissen) in der Softwaretechnik: Menge von zulässigen Ereignisfolgen Wichtige Verallgemeinerung: "Automaten mit Ausgabe" Mealy-Automaten: Ausgabe bei Übergang Softwaretechnik: Aktion bei Übergang Moore-Automaten: Ausgabe bei Erreichen eines Zustands Softwaretechnik: Aktion bei Erreichen eines Zustands (entry action) Dr. Ina Schaefer Software Engineering 1 Seite 15

16 UML-Zustandsmodelle Definition: Ein Zustand ist eine Eigenschaft eines Systems, die über einen begrenzten Zeitraum besteht. Notation: Z! Was ist ein Zustand"? Anwendungsorientiert: Eigenschaft eines einzelnen Analyse-Objekts Eigenschaft eines ganzen, komplexen Softwaresystems Eigenschaft eines Arbeitsprozesses Eigenschaft eines Produkts eines Arbeitsprozesses Technisch: Ein Objekt oder eine Gruppe von Objekten Dr. Ina Schaefer Software Engineering 1 Seite 16

17 Ereignisse Definition: Ein Ereignis ist ein Geschehen von vernachlässigbarer Zeitdauer, das auf das betrachtete System Auswirkungen hat. Ein Ereignistyp wird durch den Namen und evtl. weitere Parameter beschrieben. Notation: E E (Par1,..., ParN) E (Par1 : Typ1,..., ParN : TypN) Dr. Ina Schaefer Software Engineering 1 Seite 17

18 Arten von Ereignissen Allgemeingültige Arten von Ereignissen: Empfang einer Nachricht von außen Ablaufen einer Zeitbedingung (time-out) Veränderung einer (überwachten) Bedingung (change event) Spezielle Arten von Ereignissen für einzelne Objekte: Eintreffen einer Nachricht bei einem Objekt Aufruf einer Operation (Methode) Signal (ohne zugehörige Methode, wird nur im Zustandsdiagramm behandelt) Erzeugen oder Löschen des Objekts Detaillierungsgrad in der Analysephase nutzt anwendungsbezogene, keine technischen Ereignisse. Dr. Ina Schaefer Software Engineering 1 Seite 18

19 Zustandsübergänge Definition: Ein Zustandsübergang von Zustand A nach Zustand B mit Ereignisnamen E besagt, dass im Zustand A bei Auftreten eines E Ereignisses der neue Zustand B angenommen wird. Notation: E! A! B! Beispiele: konfliktfrei! in Bau! Analyse! erfolgreiche Raumreservierung! Abnahme! fixiert! bezugsfertig! Entwurf! Dr. Ina Schaefer Software Engineering 1 Seite 19

20 Start- und Endzustand Jedes Zustandsdiagramm sollte einen Startzustand haben. Der Startzustand ist kein echter Zustand. Notation: Ein Zustandsdiagramm kann einen oder mehrere Endzustände haben. Die Angabe mindestens eines Endzustands ist wünschenswert. Notation: ("bull's eye") Dr. Ina Schaefer Software Engineering 1 Seite 20

21 Bedingungen Ereignis [Bedingung]! A! B! Definition: Eine Bedingung (guard) ist eine Boolesche Bedingung, die zusätzlich bei Auftreten des Ereignisses erfüllt sein muss, damit der beschriebene Übergang eintritt. Notation: Eine Bedingung wird in der Analysephase meist noch textuell beschrieben. In formalerer Beschreibung (v.a. im Entwurf) kann eine Bedingung folgende Informationen verwenden: Parameterwerte des Ereignisses Attributwerte und Assoziationsinstanzen (Links) der Objekte ggf. Navigation über Links zu anderen Objekten Beispiel: konfliktfrei! raumfestlegen()! [kein Raumproblem]! fixiert! Dr. Ina Schaefer Software Engineering 1 Seite 21

22 Aktionen Ereignis [Bedingung] / Aktion! A! B! Definition: Eine Aktion ist die Beschreibung einer ausführbaren Anweisung, wobei angenommen wird, dass die Dauer der Ausführung vernachlässigbar ist. Aktionen sind nicht unterbrechbar. Eine Aktion kann auch eine Folge von Einzelaktionen sein. Typische Arten von Aktionen: Lokale Änderung eines Attributwerts Versenden einer Nachricht an ein anderes Objekt Erzeugen oder Löschen eines Objekts Eine Aktion wird in der Analysephase meist textuell beschrieben. In formalerer Beschreibung kann als Aktionssprache auch die Implementierungsprache (z.b. Java) verwendet werden. Dr. Ina Schaefer Software Engineering 1 Seite 22

23 Verwendung von UML-Zustandsmodellen zur Steuerung: Für steuernde Systeme, eingebettete Systeme etc. Ereignisse sind Signale der Umgebung oder anderer Systemteile Reaktion in gegebenem Zustand auf ein bestimmtes Signal: neuer Zustand ausgelöste Aktion (wie im Zustandsmodell spezifiziert) Ähnlich zum Konzept von Mealy-Automaten Zustandsmodelle definieren die Reaktion auf mögliche Ereignisse. als Protokolle (oder Objekt-Lebenszyklen): Für Informationssysteme, Datenbankanwendungen etc. Ereignisse sind Operationsaufrufe. Reaktion in gegebenem Zustand auf bestimmten Aufruf: durch Methodenrumpf gegeben (komplex) Keine Aktionen im Zustandsmodell! Zustandsmodelle definieren zulässige Reihenfolgen von Aufrufen. Dr. Ina Schaefer Software Engineering 1 Seite 23

24 Beispiel: Zustandsmodell zur Steuerung Aufzugssteuerung: druck druck kommt Steuerung Aufzug- Bedienelemente ein/ aus Verhalten als Zustandsdiagramm: bereit Sensor (S) anfordg/ quittung auf/zu Steuerzentrale (Z) Türsteuerung (TS) untätig Auf.druck [S.bereit] / TS.auf Ab.druck [S.bereit] / TS.auf Auf.druck [S. bereit] / kommt.ein; SZ.anfordg(auf) Ab.druck [S. bereit] / kommt.ein; SZ.anfordg(ab) S.bereit / kommt.aus; TS.auf; SZ.quittung wartend Dr. Ina Schaefer Software Engineering 1 Seite 24

25 Objektlebenszyklus (Protokollmaschine) Zustände von Objekten der Klasse "Teambesprechung":! Terminbestätigung! [positiv, nicht letzte]! Terminbestätigung! [positiv, letzte]! geplant! abgestimmt! Terminbestätigung [negativ]! verschieben! in Konflikt! kein freier Raum gefunden! einladen! freier Raum gefunden! fixiert! absagen! absagen! absagen! absagen! einladen! eingeladen! abgelaufen! Dr. Ina Schaefer Software Engineering 1 Seite 25

26 Ober- und Unterzustände Um eine ganze Gruppe von Zuständen einheitlich zu behandeln, können Oberzustände eingeführt werden. Ein Objekt in einem Zustand ist gleichzeitig in allen Oberzuständen Ein Zustand in den Oberzustand ist ein Übergang in den Startzustand des enthaltenen Zustandsdiagramms. Transitionen können Zustandshierarchien kreuzen Äußere Transitionen wirken für jeden Unterzustand ab a e1 b e3 e2 c e4... Dr. Ina Schaefer Software Engineering 1 Seite 26

27 Zustandshierarchie verschieben! Terminbestätigung! [positiv, nicht letzte]! Terminbestätigung! [positiv, letzte]! einladen! in Bearbeitung! geplant! abgestimmt! fixiert! Terminbestätigung [negativ]! freier Raum gefunden! in Konflikt! kein freier Raum gefunden! Raumproblem! absagen! einladen! eingeladen! date > (beginn+dauer)! Dr. Ina Schaefer Software Engineering 1 Seite 27

28 Zusammenfassung: Statecharts Verhalten wird durch Statecharts dargestellt Statecharts bilden eine Erweiterung der Automatentheorie um Zustandshierarchieen Ein-/Ausgabe Parallele Zustände Anwendungen unter anderem: Modell einer Steuerung Protokollbeschreibung Objekt-Lebenslauf Im Gegensatz zu Sequenzdiagrammen sind Statecharts vollständige Verhaltensbeschreibungen. Dr. Ina Schaefer Software Engineering 1 Seite 28

29 Aktivitätsdiagramme Beschreibung von Verhalten, insbesondere Prozessen oder Workflows Beschreibung von parallelen Prozessen/Aktivitäten Verfeinerung von Use Cases Einbeziehung verschiedener Aktoren in UML 2: Semantik an Petrinetze angelehnt Dr. Ina Schaefer Software Engineering 1 Seite 29

30 !"#$%$#&#'()$*+,*-- Aktivitätsdiagramm - Beispiel Customer Sales Stockroom Request Take Order Pay Fill Order Deliver Order Dr. Ina Schaefer Software Engineering 1.// Seite 30

31 Aktivitätsdiagramme - Konzepte Oben stehen die Aktoren, Komponenten oder Klassen. Die Zeitachse verläuft von oben nach unten. Die Aktivitäten jedes Aktorsstehen in einer Swimlane. Aktivitäten (Rechtecke mit abgerundeten Ecken) Aktivitätsparameter repräsentieren Input und Output spezielle Send und Accept Message Aktivitäten Transitionen zwischen Aktivitäten: Kontrollfluss Gefüllter Kreis = Startknoten Bull s eye = Endknoten Einbeziehung von Zeit (Time Trigger und Events) Dr. Ina Schaefer Software Engineering 1 Seite 31

32 Modellierung des Kontrollflusses!"#$#%&'()*+,-./0"1"02-3"4+%45 Decision: Verzweigung im Kontrollfluss Merge: Zusammenfluss im Kontrollfluss Guards: Bedingungen, die wahr sein müssen, um eine Transition zu nehmen 5#%+#-*'$#!"#$%&'()*(+",-.+/$0(+(%&1*23"4(*15"6*78-0."91:+*+;+3"<1*=(0:*+>+"?$8(0)-01 7%#/'*$"0"'* /'*$"0"'* $#/"6"'*- *'$# Dr. Ina Schaefer Software Engineering 1 Seite 32!

33 ! An ausgehenden Transitionen dürfen keine Gua stehen! Vereinigung: Parallelität! Gabelung Bündelung (Fork): mehrerer eingehender Transitionen z eine ausgehenden Transition Verteilung einer eingehenden Transition auf mehrere parallele Ziele.! An An eingehenden ausgehenden Transitionen Transitionen dürfen keine dürfen Guards stehen. keine Bedingungen und Trigger stehen! Notation: Aktivität Aktivität Trigger [Guard] / h, Borner Aktivität Aktivität Trigger [Gu Dr. Ina Schaefer Software Engineering 1 Seite 33

34 iner eingehenden Transition auf rallele Ziele Vereinigung (Join): Parallelität (2) nden Transitionen dürfen keine Guards Bündelung mehrerer eingehender Transitionen zu einer ausgehenden Transition mehrerer eingehender Transitionen zu enden Transition Join wird ausgeführt, wenn alle parallelen Prozesse verfügbar sind. An eingehenden Transitionen dürfen keine Bedingungen und Trigger stehen. nden Transitionen dürfen keine n und Trigger stehen gger [Guard] / Aktivität Aktivität Aktivität Aktivität Trigger [Guard] / Dr. Ina Schaefer Software Engineering 1 Seite 34

35 ! $%&'('&)&*1'-./-002 Verfeinerung von Use Cases Dr. Ina Schaefer Software Engineering 1 Seite 35

36 Resultierendes Aktivitätsdiagramm Dr. Ina Schaefer Software Engineering 1 Seite 36

37 $%&'('&)&*+,'-./-00 Beschreibung von Kontrollfluss in Programmen! $%&'('&)&*1'-./-002 :,'**;(<<07*7 2*0* <&!"#$%3! $%&'('&)&*1'-./-002 Aktivitätsdiagramm :,'**;(<<07*7 2*0* <&!"#$%3 $%&'('&)&*+,'-./-00 RSO K-*8'*&8LMN O-*&95= DJ7'<=&95= PP$ QMD B0C79095&'9/45.*5-=9/8H9>/-4<=88 95&*C/'<=&8-7&958I65&/677J74**1'-./-0095 Programmcode K-*8'*&8LMN O-*&95= DJ7'<=&95= PP$ RSO QMD!"#$%&$'""()*&+&*,-./0(*1* 234 B0C79095&'9/45.*5-=9/8H9>/-4<=88! F-(-+G &*C/'<=&8-7&958I65&/677J74**1'-./ file Shuttle.java ! F-(-+G6192 =$'""()* ++&*0*> public class Shuttle!"# public void goto (Track tgt) {!"#$%&$'""()*&+&*,-./0(*1* 234 Track current = this.getat (); ----file while Shuttle.java (! current == tgt) { =(;.(> current = current.getneighbourtowards (tgt); =$'""()* ++&*0*> publicthis.setat class Shuttle (current);!"# $'""()*&+&$'""()*/0(*5(-0,67'"!78#"9. 2*0*34 public } void goto (Track tgt) { *,-./.(*1* 2$'""()*34 Track return; current = this.getat (); } while (! current == tgt) { =(;.(> } current = current.getneighbourtowards (tgt 345%&'65-7'&)&2 this.setat (current); $'""()*&+&$'""()*/0(*5(-0,67'"!78#"9. ' '5958%4/:9/8;9*<=/9'>45.*&9?&8@'98A;9/9<=598B519?8A8 2*0*34 } *,-./.(*1* 2$'""()*34 return; B0C79095&'9/45.*5-=8%-558-4<=8D*94168E8F-(-8G6198(9/@9519&8@9/195 } }!"# 345%&'65-7'&)&2 ' '5958%4/:9/8;9*<=/9'>45.*&9?&8@'98A;9/9<=598B519?8A8 B0C79095&'9/45.*5-=8%-558-4<=8D*94168E8F-(-8G6198(9/@9519&8@9/195 Dr. Ina Schaefer Software Engineering 1 Seite 37

38 Zusammenfassung: Aktivitätsdiagramme Beschreibung von Abläufen Mehrere Aktoren Reihenfolge der Ausführung von Aktionen Paralellität in der Ausführung (Fork, Join) Dr. Ina Schaefer Software Engineering 1 Seite 38

39 Vergleich Sequenzdiagramme Zustandsdiagramme Aktivitätsdiagramme Dr. Ina Schaefer Software Engineering 1 Seite 39

40 Zusammenfassung: OOA Ziel: Objektorientierte Systemmodellierung Anbindung an Anforderungen durch Anwendungsfälle (Use Cases) Verschiedene Vorgehensweisen: Verhaltensorientiert (OOSE) Datenorientiert (OMT) Verschiedene Sichten und Detaillierungsebenen Kernstück: Klassendiagramme Szenarien: Sequenzdiagramme Modellierung von Verhalten mit Zustandsdiagrammen (Statecharts) Modellierung von Abläufen mit Aktivitätsdiagrammen Dr. Ina Schaefer Software Engineering 1 Seite 40

41 Übersicht: UML-Diagramme Dr. Ina Schaefer Software Engineering 1 Seite 41