Inhalt Softwaretechnik (MN) Kapitel 5

Inhalt Softwaretechnik (MN) Kapitel 5 1. Einführung 2. Anforderungsanalyse und Use Cases 3. Grundlagen der objektorientierten Analyse (OOA): Das Klassendiagramm 4. Von der objektorientierten Analyse (OOA) zum objektorientierten Design (OOD) und zum Code 5. Dynamische Diagramme der UML 5.1 Aktivitätsdiagramm 5.2 Sequenzdiagramm 5.3 Zustandsdiagramm 6. Entwurfsmuster (Pattern) 7. Testen Schestag Softwaretechnik (MN) Kapitel 5 / 1

Ergänzungen zu Kapitel 4 (1) Umsetzung eines UML Klassendiagramms Analysesicht Designsicht C++ Source Analysesicht (UML) Desingsicht (C++) Konto.cpp Schestag Softwaretechnik (MN) Kapitel 5 / 2

Ergänzungen zu Kapitel 4 (2) Implementierung der Navigationsrichtungen einer Assoziation durch Referenzattribute: Analysesicht (UML) Desingsicht (C++) Schestag Softwaretechnik (MN) Kapitel 5 / 3

Ergänzungen zu Kapitel 4 (3) Folgende strategische Überlegungen sind vor der Implementierung einer Navigationsrichtung durchzuführen bzw. zu bedenken: Dominiert die Zahl der Prozesse, in denen eine Fachbereichsinstanz ihre assoziierten Studenten kennen sollte? Wenn ja, dann implementiere das Referenzattribut students vom Typ set(student*) in der Klasse Fachbereich. Dominiert die Zahl der Prozesse, in denen eine Studenteninstanz ihren assoziierten Fachbereich kennen sollte? Wenn ja, dann implementiere das Referenzattribut *fachbereich vom Typ Fachbereich in der Klasse Student. Die Implementierung beider Referenzattribute erhöht die Geschwindigkeit beim Suchen von Informationen, aber sie fordert auch einen erhöhten Aufwand bei Updates: Bei der Immatrikulation eines Studenten für einen Fachbereich muss nicht nur die Studenteninstanz den entsprechenden Fachbereichspointer erhalten, sondern auch das set Attribut students einen zusätzlichen Eintrag erhalten. Eine Assoziation ist immer dann implementiert, wenn mindestens eine der beiden Navigationsrichtungen implementiert ist! Ist in der Analysesicht ein Rollenname angegeben, so bietet sich dieser an als Bezeichner für das entsprechende Referenzattribut. Schestag Softwaretechnik (MN) Kapitel 5 / 4

5 Dynamische UML Diagramme (1) Die Diagramme der UML 2.0 im Überblick: UML 1.4: Kollaborations diagramm Schestag Softwaretechnik (MN) Kapitel 5 / 5

5 Dynamische UML Diagramme (2) Die UML eignet sich zur durchgängigen (OO) Modellierung statischer und dynamischer Aspekte bis zur Implementierung und stellt dafür unterschiedliche Diagrammkategorien zur Verfügung: Statische Diagramme (Strukturdiagramme) Klassendiagramm Objektdiagramm Paketdiagramm Dynamische Diagramme (Verhaltensdiagramme) Use Case Diagramm Interaktionsdiagramme Sequenzdiagramm Kommunikationsdiagramm (bis UML 1.4: Kollaborationsdiagramm) Zustands(übergangs)diagramm Aktivitätendiagramm Implementationsdiagramme (behandeln wir nicht im Rahmen dieser Vorlesung) Komponentendiagramm Verteilungsdiagramm Schestag Softwaretechnik (MN) Kapitel 5 / 6

5 Dynamische UML Diagramme (3) Szenarien bilden die Grundlage für die Erstellung dynamischer Diagramme Ein Szenario ist eine Sequenz von Verarbeitungsschritten, die unter bestimmten Bedingungen auszuführen ist. Diese Schritte sollen das Hauptziel des Akteurs realisieren und ein entsprechendes Ergebnis liefern. Sie beginnen mit dem auslösenden Ereignis und werden fortgesetzt, bis das Ziel erreicht ist oder aufgegeben wird. Ein Anwendungsfall kann durch ein einzelnes Szenario oder durch eine Kollektion von Szenarien dokumentiert werden. Jedes Szenario wird durch eine oder mehrere Bedingungen definiert, die zu einem speziellen Ablauf des jeweiligen Anwendungsfalls führen. Ein Akteur ist eine außerhalb des Systems liegende Rolle, z.b. ein Benutzer oder ein externes System. Der Akteur löst ein Szenario aus. Schestag Softwaretechnik (MN) Kapitel 5 / 7

5 Dynamische UML Diagramme (4) Ziel der Erstellung unterschiedlicher UML Diagramme ist es, ein Gesamtsystem und dessen zu implementierenden Komponenten also die Klassen auf Vollständigkeit zu überprüfen im Gesamtentwurf. Hierbei ist es notwendig, das Gesamtsystem unter den unterschiedlichsten Aspekten zu betrachten. UseCase3 «extend» Actor 1 Use Case 1 Use Case 4 «include» Actor 2 UseCase2 Use Case Diagramm(e) Subjekt1 1 * 1 * KonkretesSubjekt1 Kennung Use Case: Titel Autor, Datum, Version Zweck (kurze Beschreibung) Kennung Use Case: Titel Kontext: NameSystem NameSubsystem NameProzeß Autor, Datum, Version beteiligte Aktoren Zweck (kurze Beschreibung) auslösende Ereignisse Kennung Use Case: Vorbedingungen, Titel die erfüllt sein müssen Kontext: NameSystem relevante NameSubsystem Eingangs- und Ausgangsdaten NameProzeßund -signale Autor, Datum, Version beteiligte Aktoren (Verweis auf die Schnittstellen-Spezifikation) Zweck (kurze Beschreibung) auslösende Ereignisse kritische Ausnahmesituationen bzw. Fehlerfälle Vorbedingungen, die erfüllt sein müssen Kontext: NameSystem relevante NameSubsystem Eingangs- und Ausgangsdaten NameProzeß und -signale (Verweis auf die wesentliche Schnittstellen-Spezifikation) Ergebnisse beteiligte Aktoren auslösende Ereignisse kritische Ausnahmesituationen Nachbedingungen bzw. Fehlerfälle Vorbedingungen, die erfüllt sein nachgeordnete müssen Nutzungsfälle relevante Eingangs- und Ausgangsdaten Verweis auf und zugehörige -signale Szenarios wesentliche Ergebnisse (Verweis auf die Schnittstellen-Spezifikation) relevante funktionale Anforderungen kritische Ausnahmesituationen Nachbedingungen bzw. Fehlerfälle nachgeordnete Nutzungsfälle Verweis auf zugehörige Szenarios wesentliche Ergebnisse relevante funktionale Anforderungen Nachbedingungen nachgeordnete Nutzungsfälle Verweis auf zugehörige Szenarios relevante funktionale Anforderungen... Szenario / Szenarien pro Use Case Subjekt2 KonkretesSubjekt2 Sind die Attribute vollständig? Sind die Methoden vollständig? Klassendiagramm Schestag Softwaretechnik (MN) Kapitel 5 / 8

5.1 Aktivitätsdiagramm die Funktionalität Aktivitätsdiagramme sind eine Variante des Zustandsdiagramms (vgl. 5.3) und eignen sich gut zur Geschäftsprozessmodellierung. Sie sind vergleichbar mit den «alten» Flussdiagrammen bzw. Programmablaufplänen (PAPs) und eignen sich deshalb gut für Kontrollflussdarstellungen Akitivitätsdiagramme dienen der Beschreibung von Abläufen: Was tun die einzelnen Schritte eines Ablaufs? In welcher Reihenfolge werden sie ausgeführt? Wer ist für einen Schritt verantwortlich (optional)? Einsatzfelder: Beschreibung zur Realisierung einer komplexen Operation: Die einzelnen Schritte eines Aktivitätsdiagramms repräsentieren die Folge von Anweisungen der Operation. Beschreibung einer Folge von Schritten eines Anwendungsfalls Beschreibung des Zusammenspiels von Anwendungsfällen Beschreibung von Geschäftsprozessen Schestag Softwaretechnik (MN) Kapitel 5 / 9

5.1 Aktivitätsdiagramm die Komponenten (1) Aktivitätsdiagramme benutzen die folgenden Komponenten: Beginn und Ende des Ablaufs werden durch einen eindeutigen Start und möglicherweise mehrere Endezustände markiert. Startzustand: Endezustand: Man unterscheidet zwischen Aktion und Aktivität: Eine Aktion ist atomar, d. h. sie kann nicht weiter zerlegt und darf nicht während ihrer Ausführung unterbrochen werden. Aktion Eine Aktivität besitzt eine komplexe Struktur und kann z. B. selbst wieder durch ein Aktivitätsdiagramm beschrieben werden. Aktivität Im Folgenden benutzen wir den generischen Ausdruck Aktivität(szustand) Schestag Softwaretechnik (MN) Kapitel 5 / 10

5.1 Aktivitätsdiagramm die Komponenten (2) Alle Zustände eines Aktivitätsdiagramms sind untereinander durch gerichtete Kontrollflusskanten verbunden, die die Ausführungsreihenfolge der einzelnen Schritte festlegen. Man spricht auch von Transition (Übergang) und von Transitionspfeilen. A B Ist die Ausführung von A abgeschlossen, so wird automatisch der Übergang nach B ausgelöst und mit der Ausführung von B begonnen. Bedingte Transitionen: [Bedingung] B1 A C [ Bedingung] B2 Schestag Softwaretechnik (MN) Kapitel 5 / 11

5.1 Aktivitätsdiagramm die Komponenten (3) Beschreibung von Nebenläufigkeiten: Die Gabelung (Splitting) kennzeichnet den Beginn einer Nebenläufigkeit: Von einem Synchronisationsbalken aus führen mehrere Transitionen weg. Die Synchronisation (Vereinigung, Join) zeigt das Ende der Nebenläufigkeit an: Gabelung Vereinigung (Join) Zusammenführung UND Entscheidungsknoten: Einem Entscheidungsknoten sind eine oder mehrere eingehende Transitionen und zwei oder mehrere ausgehende Transitionen zugeordnet. Komplexe Entscheidungen können so in Form von Entscheidungsbäumen dargestellt werden. Alle ausgehenden Transitionen müssen paarweise disjunkte Bedingungen tragen. Entscheidung Zusammenführung ODER Schestag Softwaretechnik (MN) Kapitel 5 / 12

5.1 Aktivitätsdiagramm Aktivitäten und Übergänge (Zusammenfassung) Eine Aktivität ist ein Zustand mit interner Aktion, sie entspricht einem Zustand bei Zustandsautomaten (vgl. 5.3). Übergänge (Transitionen) modellieren den Kontrollfluss und den Objektfluss, z.b. bei Anwendungsfällen, beim Zusammenspiel verschiedener Operationen, zur Beschreibung des Ablaufs in einer Operation. Übergänge (Transitionen) sind i. d. R. nicht abhängig von Ereignissen, können unter einer bestimmten Bedingungen ausgeführt werden, Können aufgeteilt und wieder synchronisiert werden durch einen Synchronisationsbalken, zusätzliche Synchronisationsbedingungen sind möglich. Schestag Softwaretechnik (MN) Kapitel 5 / 13

5.1 Aktivitätsdiagramm ein erstes einfaches Beispiel Schaden feststellen selbst bezahlen Schaden melden Schaden vermerken mit anderen Versicherungen verhandeln [Eigenverschulden] Prämie erhöhen [Fremdverschulden] [AND] Quelle: Dr. Michael Hahsler, Abteilung für Informationswirtschaft, WU Wien Schestag Softwaretechnik (MN) Kapitel 5 / 14

5.1 Aktivitätsdiagramm ein zweites Beispiel Das folgende Aktivitätsdiagramm zum Szenario Teepause enthält Aktivitäten und Übergänge mit Bedingungen zur Steuerung der Verzweigungen: Wasser kochen Tee auswählen [Wasser siedet] Tee in Filter tun [Tee grün] 10 Min. warten [Tee schwarz] Tee aufgießen 3 Min. warten Tasse holen Filter entfernen Tasse füllen Tasse nehmen Tee trinken Tasse abstellen [nicht leer] [leer] PIWIN lesen Schestag Softwaretechnik (MN) Kapitel 5 / 15

5.1 Aktivitätsdiagramm eine weitere Komponente: Swimlanes Swimlanes (Verantwortlichkeitsbereiche) erlauben die Definition von Rollen und Verantwortlichkeiten in Aktivitätsdiagrammen. Die Verantwortlichkeitsbereiche entsprechen den handelnden Instanzen: Gast Bedienung Theke Platz nehmen Zeitung nehmen Kaffee bestellen Bestellung aufnehmen Kaffee bereiten servieren Zeitung lesen Kaffee trinken Rechnung schreiben bezahlen Schestag Softwaretechnik (MN) Kapitel 5 / 16

5.2 Sequenzdiagramm und Kollaborationsdiagramm (1) Die UML 1.4 bietet zur Darstellung von Szenarien zwei Arten von Interaktionsdiagrammen an: Sequenzdiagramm und Kollaborationsdiagramm Beispiel: Gegeben sei folgendes Szenario als textuelle Beschreibung: Eine Touristin A übermittelt erst das Reiseziel und dann den Reisetermin an das Informationssystem Travel. Das System nennt ihr darauf den Preis der Reise. Sie ist einverstanden und gibt den Buchungsauftrag. Nach dessen Eingang erhält sie eine Bestätigung. Die Interaktionen dieses Szenarios können mit Interaktionsdiagrammen graphisch dargestellt werden: Sequenzdiagramm zeitliche Abfolge ist wichtig Kommunikationsdiagramm logische Abfolge ist wichtig Schestag Softwaretechnik (MN) Kapitel 5 / 17

5.2 Sequenzdiagramm und Kollaborationsdiagramm (2) Sequenzdiagramm (zeitliche Abfolge): A: Tourist Travel: System Reiseziel Reisetermin Reisepreis Buchungsauftrag Bestätigung Zeit Schestag Softwaretechnik (MN) Kapitel 5 / 18

5.2 Sequenzdiagramm und Kollaborationsdiagramm (3) Kollaborationsdiagramm (logischer Ablauf Informationsaustausch) : 1. Reiseziel 2. Reisetermin 4. Buchungsauftrag A: Tourist Travel: System 3. Reisepreis 5. Bestätigung zeitlicher Ablauf: 1. 5. Kollaborationsdiagramme werden im Rahmen dieser Vorlesung nicht weiter vertieft! Schestag Softwaretechnik (MN) Kapitel 5 / 19

5.2 Sequenzdiagramm die Komponenten (1) Das Sequenzdiagramm ist ein 2 dimensionales Diagramm, dessen vertikale Achse der Zeit und dessen horizontale Achse den beteiligten Objekten entspricht. myx : X Objektsymbol Objektsymbol Lebenslinie Lebenslinie Aktivitätsbalken Aktivitätsbalken Zeit Destruktorsymbol Destruktorsymbol Schestag Softwaretechnik (MN) Kapitel 5 / 20

5.2 Sequenzdiagramm die Komponenten (2) Der Nachrichtenaustausch zwischen Objekten (Kontrollfluss) wird durch gerichtete, horizontale Pfeile dargestellt, deren Bezeichner einem vorhandenen oder noch zu ergänzenden (!) Methodennamen entsprechen sollte. Wir unterscheiden die folgenden Kontrollflussvarianten: Synchroner Kontrollfluss: Der Sender der Nachricht wartet, bis die durch die Nachricht ausgelöste Teilinteraktion beendet ist. Im Allgemeinen entspricht dieser Nachrichtenaustausch in seiner Semantik einem Prozeduraufruf. Asynchroner Kontrollfluss: Die Nachricht wird als Signal betrachtet, und der Sender der Nachricht wartet nicht auf die Antwort des Empfängers. Rücksprunganweisungen werden durch gestrichtelte Pfeillinien dargestellt. Eine Objekterzeugung wird wie folgt dargestellt: myx : X Zeit new( ) Schestag Softwaretechnik (MN) Kapitel 5 / 21

5.2 Sequenzdiagramm die Komponenten (3) Nachrichten können durch Überwachungsbedingungen (guard condition) beschriftet sein. Hierdurch können Fallunterscheidungen zum Ausdruck gebracht werden. [Bedingung], [ Bedingung] oder auch [else] Bei Verzweigungen ist die Nennung der guard condition obligatorisch. Das gleichzeitige Versenden von Nachrichten wird genau so dargestellt werden, allerdings wird dann auf eine Nennung von guard conditions verzichtet: [B] m1() [ B] m2() m1() m2() Alternative Lebenslinien können dann verwendet werden, wenn ein und dem selben Objekt in Folge einer Verzweigung unterschiedliche Nachrichten übermittelt werden. Zeit [B] m1() [ B] m2() Schestag Softwaretechnik (MN) Kapitel 5 / 22

5.2 Sequenzdiagramm die Komponenten (4) Ein rekursiver Methodenaufruf wird wie folgt dargestellt: Käufer:Person [Geld > 0] einkaufen( ) x : X Eine Nachrichtensequenz, die wiederholt werden soll (Schleife) wird durch ein umschreibendes Rechteck zu einem Block zusammengefasst, der im unteren Bereich Angaben zur Schleifensteuerung enthält: Zeit für alle X-Objekte x Schestag Softwaretechnik (MN) Kapitel 5 / 23

5.2 Sequenzdiagramm Regeln zur Anwendung Sequenzdiagramme sollten primär für die Abbildung einzelner Szenarien verwendet werden. Ablaufvarianten sind häufig übersichtlicher durch mehrere einander ergänzende Sequenzdiagramme zu modellieren. Verzweigungen und Schleifen sollten sparsam eingesetzt werden man benötigt sie nur dann, wenn das Diagramm andernfalls nicht mehr eindeutig interpretierbar ist. Die Nachrichten, die zwischen den beteiligten Objekten eines Sequenzdiagramms ausgetauscht werden, sollten durch Methoden der entsprechenden Klassen abbildbar sein. Ist dies nicht der Fall, so ist dies ein Indikator dafür, dass in der zugehörigen Klasse eine geeignete Methode noch hinzugefügt werden muss. CASE Tools unterstützen die Überprüfung der Vollständigkeit von Methoden dadurch, dass sie für die Bezeichner der Nachrichten die vorhandenen Methoden des Ziel- Objektes(!) zur Verfügung stellen bzw. diese automatisch durch noch fehlende Methoden mit dem entsprechenden Nachrichtenbezeichner auf Wunsch ergänzt. Schestag Softwaretechnik (MN) Kapitel 5 / 24

5.2 Sequenzdiagramm Vollständigkeit der Methoden UseCase3 «extend» Actor 1 Use Case 1 Use Case 4 «include» Actor 2 Use Case 2 Use Case- Diagramm Subjekt1 1 * Kennung Use Case: Titel Autor, Datum, Version Zweck (kurze Beschreibung) Kennung Use Case: Titel Kontext: NameSystem NameSubsystem NameProzeß Autor, Datum, Version beteiligte Aktoren Zweck (kurze Beschreibung) auslösende Ereignisse Kennung Use Case: Vorbedingungen, Titel die erfüllt sein müssen Kontext: NameSystem relevante NameSubsystem Eingangs- und Ausgangsdaten NameProzeßund -signale Autor, Datum, Version beteiligte Aktoren (Verweis auf die Schnittstellen-Spezifikation) Zweck (kurze Beschreibung) auslösende Ereignisse kritische Ausnahmesituationen bzw. Fehlerfälle Vorbedingungen, die erfüllt sein müssen Kontext: NameSystem relevante NameSubsystem Eingangs- und Ausgangsdaten NameProzeß und -signale wesentliche Ergebnisse beteiligte Aktoren (Verweis auf die Schnittstellen-Spezifikation) auslösende Ereignisse kritische Ausnahmesituationen Nachbedingungen bzw. Fehlerfälle Vorbedingungen, die erfüllt sein nachgeordnete müssen Nutzungsfälle relevante Eingangs- und Ausgangsdaten Verweis auf und zugehörige -signale Szenarios wesentliche Ergebnisse (Verweis auf die Schnittstellen-Spezifikation) relevante funktionale Anforderungen kritische Ausnahmesituationen Nachbedingungen bzw. Fehlerfälle nachgeordnete Nutzungsfälle Verweis auf zugehörige Szenarios wesentliche Ergebnisse relevante funktionale Anforderungen Nachbedingungen nachgeordnete Nutzungsfälle Verweis auf zugehörige Szenarios... relevante funktionale Anforderungen Szenario / Szenarien pro Use Case Subjekt2 MyJdbc MyJdbc getconnection() DriverManager getconnection() MyJdbc DriverManager createstatement() getconnection() next() executequery() / executeupdate() getxxx() DriverManager createstatement() executequery() / executeupdate() con :Connection con createstatement() :Connection executequery() / executeupdate() next() close() getxxx() close() next() close() getxxx() close() con :Connection stmt :Statement X X stmt :Statement stmt :Statement [falls executequery()] [falls executequery()] [falls executequery()] rset :ResultSet X rset :ResultSet X close() close()... X rset :ResultSet X Sequenzdiagramm pro Szenario Vollständigkeit der Methoden? KonkretesSubjekt1 1 * KonkretesSubjekt2 Schestag Softwaretechnik (MN) Kapitel 5 / 25

5.3 Zustandsdiagramm (1) Die Aufgabe von Zustandsdiagrammen (State charts): Bei technischen Systemen ist es oft nützlich, wenn man die verschiedenen Zustände und die zulässigen Zustandsübergänge geeignet modellieren könnte. Erweiterung des Konzeptes der endlichen Automaten führt zum Zustandsautomat: Zustände und Zustandsübergänge Schachtelung in Super- und Subzustände Parallele Komposition von Zuständen Variablen, Kommunikation per Broadcast beispielsweise für technische Systeme viel verwendet Beispiele für Tools: StateMate, Rhapsody Schestag Softwaretechnik (MN) Kapitel 5 / 26

5.3 Zustandsdiagramm (2) Mit Hilfe von Zustandsdiagrammen werden von Objektzuständen Modellierung über den gesamten Lifecycle eines Objektes modelliert: Der jeweilige Zustand beschreibt die Eigenschaften des Objekts zu einem bestimmten Zeitpunkt. Attributwerte Beziehungen zu anderen Objekten Der Zustandsname soll daher kein Verb sein, sondern ein Adjektiv / Partizip. Ein Ereignis tritt zu einem bestimmten Zeitpunkt auf, es hat keine Dauer. neuer Attributwert Signal (z.b. Abschluss einer Operation) Ein Ereignis kann häufig als Nachricht angesehen werden Name kann entfallen, da Aktion (=Operation) gleichnamig Schestag Softwaretechnik (MN) Kapitel 5 / 27

5.3 Zustandsdiagramm die Komponenten Zustands (übergangs) diagramme in der UML: Quelle: Rational Corp. Schestag Softwaretechnik (MN) Kapitel 5 / 28

5.3 Zustandsdiagramm Beispiel 1 Die Zustände im Lebenszyklus eines Buch Objektes in einem Bibliothekssystem: Buch defekt / entfer nen() präsent neues Buch liegt vor / er fassen() after (Abholfrist vorbei) Ausleihwunsch / ausleihen() Leser gibt Buch z urück / zurückgeben() Bu ch erfassen() auslei hen() zurückgeben() vorbestellen() ent fer nen() Buch v erloren / entfer nen() Ausleihwunsch / vorbestellen() ausgeliehen Leser holt Buch ab / ausleihen() zur Abholung bereit vorbestellt Leser gibt Buch z ur ück / zurückgeben() Schestag Softwaretechnik (MN) Kapitel 5 / 29

5.3 Zustandsdiagramm Beispiel 2 Die Zustände im Lebenszyklus eines Tank Objektes: neues Soll / Soll einstellen leer Tank #maxfuellhoehe -sollfuellhoehe - istfuellhoehe +fuellen() +leeren() #solleinstellen() füllend do: füllen voll leerend do: leeren starte füllen ist voll starte leeren ist leer Schestag Softwaretechnik (MN) Kapitel 5 / 30

5.3 Zustandsdiagramm Beispiel 3 Der Zustandsautomat einer Digitaluhr sei durch folgende Daten in Tabellenform beschrieben: Zustandstabelle mit 4 Spalten: Aktueller Zustand Ereignis (Eingabe) Aktion (Ausgabe) Folgezustand Zustand Ereignis Aktion Folgezustand Normalzeit Knopf 1 Stunden blinken Stunden stellen Stunden stellen Knopf 1 Minuten blinken Minuten stellen Stunden stellen Knopf 2 Stunden erhöhen Stunden stellen Minuten stellen Knopf 1 Sekunden blinken Sekunden stellen Minuten stellen Knopf 2 Minuten erhöhen Minuten stellen Sekunden stellen Knopf 1 Normalanzeige Normalzeit Sekunden stellen Knopf 2 Sekunden stellen Sekunden stellen............ Schestag Softwaretechnik (MN) Kapitel 5 / 31

5.3 Zustandsdiagramm Beispiel 3 (Fortsetzung) Das Zustandsdiagramm zur Zustandstabelle einer Digitaluhr : Start Knopf 1 gedrückt / Stunden blinken Normalzeit Knopf 1 gedrückt / Normalanzeige Stunden stellen Sekunden stellen Knopf 2 gedrückt / Stunden erhöhen Knopf 1 gedrückt / Minuten blinken Minuten stellen Knopf 1 gedrückt / Sekunden blinken Knopf 2 gedrückt / Minuten erhöhen Knopf 2 gedrückt / Sekunden stellen Schestag Softwaretechnik (MN) Kapitel 5 / 32

5.3 Zustandsdiagramm Anwendung Zustandsautomaten und Zustandsdiagramme......eignen sich gut dazu, das Verhalten von Elementen, z.b. von Objekten oder Interaktionen, zu beschreiben,...werden am häufigsten dazu eingesetzt, den Lebenszyklus eines Objektes zu modellieren. Alle Objekte einer Klasse besitzen denselben Zustandsautomaten. Jedes Objekt kann einen individuellen Zustand einnehmen. Im Allgemeinen ist es nicht notwendig, für jede Klasse ein Zustandsdiagramm zu erstellen. Schestag Softwaretechnik (MN) Kapitel 5 / 33

5.3 Dynamische Diagramme der UML Zusammenfassung UseCase3 «extend» Actor 1 Use Case 1 Use Case 4 «include» Actor 2 Use Case 2 Use Case Diagramm Kennung Use Case: Titel Autor, Datum, Version Zweck (kurze Beschreibung) Kennung Use Case: Titel Kontext: NameSystem NameSubsystem NameProzeß Autor, Datum, Version beteiligte Aktoren Zweck (kurze Beschreibung) auslösende Ereignisse Kennung Use Case: Vorbedingungen, Titel die erfüllt sein müssen Kontext: NameSystem relevante NameSubsystem Eingangs- und Ausgangsdaten NameProzeßund -signale Autor, Datum, Version beteiligte Aktoren (Verweis auf die Schnittstellen-Spezifikation) Zweck (kurze Beschreibung) auslösende Ereignisse kritische Ausnahmesituationen bzw. Fehlerfälle Vorbedingungen, die erfüllt sein müssen Kontext: NameSystem relevante NameSubsystem Eingangs- und Ausgangsdaten NameProzeß und -signale wesentliche Ergebnisse beteiligte Aktoren (Verweis auf die Schnittstellen-Spezifikation) auslösende Ereignisse kritische Ausnahmesituationen Nachbedingungen bzw. Fehlerfälle Vorbedingungen, die erfüllt sein nachgeordnete müssen Nutzungsfälle relevante Eingangs- und Ausgangsdaten Verweis auf und zugehörige -signale Szenarios wesentliche Ergebnisse (Verweis auf die Schnittstellen-Spezifikation) relevante funktionale Anforderungen kritische Ausnahmesituationen Nachbedingungen bzw. Fehlerfälle nachgeordnete Nutzungsfälle Verweis auf zugehörige Szenarios wesentliche Ergebnisse relevante funktionale Anforderungen Nachbedingungen nachgeordnete Nutzungsfälle Verweis auf zugehörige Szenarios... relevante funktionale Anforderungen Szenario / Szenarien pro Use Case MyJdbc MyJdbc getconnection() DriverManager getconnection() MyJdbc DriverManager createstatement() getconnection() next() executequery() / executeupdate() getxxx() DriverManager createstatement() executequery() / executeupdate() con :Connection con createstatement() :Connection executequery() / executeupdate() next() close() getxxx() close() next() close() getxxx() close() con :Connection stmt :Statement X X stmt :Statement stmt :Statement [falls executequery()] [falls executequery()] [falls executequery()] rset :ResultSet X rset :ResultSet X close() close()... X rset :ResultSet X Sequenzdiagramm pro Szenario Vollständigkeit der Methoden? Subjekt1 1 * Subjekt2 Normalzeit Drücken Knopf 1 Drücken Knopf 1 Stunden stellen do/ Stunden blinken KonkretesSubjekt1 1 * KonkretesSubjekt2 Drücken Knopf 2 / Stunde erhöhen Zustandsdiagramm für geeignete Businessobjekte Vollständigkeit der Attribute und Methoden? Schestag Softwaretechnik (MN) Kapitel 5 / 34