UML 2 0 Dokumentation by Markus Rder Copyright

UML 2. 0 Dokumentation by Markus Röder Copyright 2006 mr@erex. de IT und Sytementwicklung : www. erex. de NLP und Kommunikation : http: //www. training-deluxe. de Objektorientierte Analyse und Design mit UML 2. 0

Sünden im Softwareentwicklungsprozess • • • Fehlende Planung Keine Projektorganisation Projektaktivitäten zu verpassen, zb Meetings Risiken nicht einzukalkulieren Randbedingungen zu vergessen Verfahren unkritisch übernehmen Zulassen, dass sich Planung und Realität auseinander entwickeln Zu viele Details zu früh planen Nicht aus alten Planungsfehlern zu lernen psychologische und soziale Faktoren vergessen Projektmanagement soll helfen UML ist dessen Hilfsmittel Objektorientierte Analyse und Design mit UML 2. 0

Was ist UML • • • Standard der Object Management Group (OMG) Graphische Modellierungssprache Notation von Elementen Notation von Diagrammtypen Strukturierung eines Modells unterschiedliche Sichtweisen Verminderung der Komplexität Anpassungen Nutzergruppen Objektorientierte Analyse und Design mit UML 2. 0

Die UML Softwarearchitektur Objektorientierte Analyse und Design mit UML 2. 0

Die UML Historie OMG Object Management Group OOSE Object Orientierte Software Entwicklung Objektorientierte Analyse und Design mit UML 2. 0

Historie Objektorientierte Analyse und Design mit UML 2. 0

Ziele der UML • Übersichtlichkeit • • • Weniger graphische Modellkonstrukte Weniger Basiskonzepte Wiederverwendung von Basiskonzepten • • Präzisionssteigerung • • Reformulierung des Meta-Modells Weitestgehende OCL-Verwendung Unveränderte Wiederverwendung von Basiskonstrukten soweit sinnvoll möglich • • Ausführbarkeit • • Erweiterte Zustandsmaschinen Stärkere Beziehungen zwischen statischen und dynamischen Diagrammen Integration erprobter Konzepte außerhalb der UML Objektorientierte Analyse und Design mit UML 2. 0

Vorteile der Modell Driven Architecture mit UML • Das beschriebene Modell spiegelt das reale Sytem wieder • Es besteht die Möglichkeit, Fehler im Modell früh und durchgehend zu erkennen • Es besteht leicht die Möglichkeit ein Modell auf verschiedenen Plattformen zu implementieren • Kommunikation zwischen allen Beteiligten wird auf ein gehobenes Niveau gebracht • Visualisierung der Fakten • Überprüfung von Fakten frühzeitig Objektorientierte Analyse und Design mit UML 2. 0

Nachteile und Grenzen von UML • siehe später… • wir wollen zuerst die Möglichkeiten kennen lernen Objektorientierte Analyse und Design mit UML 2. 0

Inkrementelle Softwareentwicklung mit UML Planung Entwicklung Qualitätssicherung und Verifizierung Integration Objektorientierte Analyse und Design mit UML 2. 0

Der Entwicklungsprozess Verifizieren Modellieren Analysieren Bewerten Objektorientierte Analyse und Design mit UML 2. 0

Hauptanwendungsgebiete für UML • Geschäftsmodellentwicklung • IT Modell – Entwicklung • IT Integration Objektorientierte Analyse und Design mit UML 2. 0

Modelle und Sichten eines Systems • Modelle • • Die Landkarte ist nicht das Land Elemente, Inhalte werden weggelassen oder hervorgehoben • Windkanalmodell eines Automobils • Plan eines UBahnnetzes • Organigramm Je mehr Info im Modell, desto komplexer wird es. Ein Geschäftssystem enthält das IT System • Sichten • • Jedes Objekt kann von verschiedenen Seiten betrachtet werden demzufolge sind meist verschiedenen Sichten verschiedene Modelle • Detailgrad und Abstraktionsgrad • ist immer ein Kompromiss um verschiedene Zielgruppen zufrieden zu stellen Objektorientierte Analyse und Design mit UML 2. 0

Der Analyse Prozess für ein Modell • • Wissensträger WT liefern Fakten werden von Wissensträgern gefunden Fakten werden repräsentiert und wieder vom WT verifiziert • Das Erstellen eines Modells ohne Verifizierung ist für die Katz! Objektorientierte Analyse und Design mit UML 2. 0

Diagramme als Sichten eines Systems • Jeder Diagrammtyp im UML entspricht einer Sicht auf das Modell eines Systems • Je nach Diagrammtyp werden verschiedene Aspekte weggelassen • Alle Sichten ergeben ein ganz gutes Modell des Systems • Die meisten UML Diagramme sind Graphen mit Knoten und Linien Objektorientierte Analyse und Design mit UML 2. 0

Neues in UML 2. 0 Nur marginale Änderungen • Klassendiagramm • Use-Case-Diagramm • Objektdiagramm Klein(-e Änderungen) aber oho: • Paketdiagramm • Verteilungsdiagramm Massiv und tiefgreifend verändert: • Aktivitätsdiagramm • Sequenzdiagramm • Zustandsautomat Vollständig neu: • Kompositionsstrukturdiagramm • Interaktionsübersichtsdiagramm • Timing-Diagramm • Kommunikationsdiagramm Objektorientierte Analyse und Design mit UML 2. 0

Modell des Geschäftssystems • Knowhow für Business Professionals Objektorientierte Analyse und Design mit UML 2. 0

Gliederung Objektorientierte Analyse und Design mit UML 2. 0

Geschäftsanwendungsfälle Objektorientierte Analyse und Design mit UML 2. 0

Modell des IT Systems • Entwicklung und Integration von IT-Systemen Objektorientierte Analyse und Design mit UML 2. 0

Die Sichten der IT auf das System • Die Sicht von Außen • Anwendungsfalldiagramm oder use-cases • • • z. T auch mit GUI-Prototypen Anwendungsfall-Sequenzdiagramm Die einzelnen Anwendungsfälle werden als Abfolge von Ereignissen beschrieben, die an das System gesendet werden, • Die strukturelle Sicht • Klassendiagramm • Die Verhaltenssicht • • Zustandsdiagramm Für jede Klasse wird gezeigt, wie Ihre Objekte auf eingehende Ereignisse, reagieren • Die Ablaufsicht • • • Kommunikationsdiagramme Sequenzdiagramme Hier wird gezeigt, wie die einzelnen Ereignisse im IT-System an die betroffenen Objekte weitergegeben werden Objektorientierte Analyse und Design mit UML 2. 0

Objektorientierte Analyse und Design mit UML 2. 0

Die Sicht von Außen Es ist egal wie es funktioniert, Hauptsache es funktioniert Objektorientierte Analyse und Design mit UML 2. 0

Die Anwendersicht • Schreiben Sie grob Anwendungsfälle für ein System auf, mit dem Sie täglich zu tun haben • Stellen Sie sich dazu einfach konkret einen Anwender vor und beobachten Sie seine Aktionen • Ein Akteur hat meist mit dem Geschäftssystem und dem IT System zu tun. Objektorientierte Analyse und Design mit UML 2. 0

Elemente der Sicht • Anwendungsfalldiagramme zeigen Akteure und Aufgaben welche der Anwender ausführen kann – – – Hierzu gehören auch genau Beschreibungen und verschiedene mögliche Szenarien und Mutationsereignisse • Anwendungsfall. Sequenzdiagramm zeigt den Ablauf der Interaktion ( mit dem IT System ) • Oberflächenprototypen zeigen wie eine mögliche Oberfläche aussehen könnte Objektorientierte Analyse und Design mit UML 2. 0

Anwendungsfall-Diagramm AWF • • • Akteur • Anwender des IT-Sytems • Repräsentiert eine Rolle die ein Anwender annimmt • Eine Person kann mehrere Rollen annehmen Anwendungsfall • beschreibt eine Interaktion zwischen Akteur und IT System • repräsentiert einen Teil der Funktionalität • Nicht sichtbare Anwendungen sind nicht Teil der use cases • Akteure lösen Fälle aus Assoziation • beschreibt eine Verbindung zwischen Akteur und AWF • Assoziation sagt, dass der Akteur den Fall ausführen kann Include Beziehung • Ist eine Beziehung zwischen 2 Anwendungsfällen • Ein AWF ist im andern AWF enthalten und wird mit ausgeführt • Kann quasi als Unterprogramm des einen angesehen werden Extend Beziehung • modelliert die bedingte Einbindung einer Funktionalität • die Funktionalität des einen AWF kann in die eines anderen eingebunden werden • Vorsichtige Verwendung – Sonst Gefahr Programmabläufe zu modellieren Objektorientierte Analyse und Design mit UML 2. 0

Lesen von AWF Systemgrenze 1 Check in 4 condition {Kunde nicht gefunden und genug Bares} extension Point : Kunde prüfen Check-In MA 5 <<include>> <<extend>> 3 Kunde eingeben 6 <<include>> 2 Express Checkin Objektorientierte Analyse und Design mit UML 2. 0 Boarding Card erstellen

Checkliste • • • Detailgrad bestimmen – Wie genau will ich beschreiben Infomaterial sammeln – woher soll ich das wissen Mögliche Akteure finden – Wer arbeite mit dem System Mögliche AWF finden – Was kann ich mit dem System tun Akteure und AWF verbinden – Wer kann was mit dem System tun Akteure beschreiben – Wofür steht ein Akteur Weitere AWFs suchen - Was gehört in einem AWF zusammen AWT dokumentieren – Was passiert in einem AWF Beziehungen zwischen Anwendungsfällen modellieren – Was ist wiederverwendbar Sicht verifizieren Objektorientierte Analyse und Design mit UML 2. 0

Akteure finden • Welche A und MA des Systems haben direkt damit zu tun • Welche Personengruppen führen die Hauptarbeit durch, • Welche Personengruppen werden benötigt um sekundäre Systemfunktionen zu versorgen • Generalisierung/Spezialisierung von Akteuren ist ebenfalls möglich Objektorientierte Analyse und Design mit UML 2. 0

Mögliche AWF finden – Hilfe bei der Suche • • Welche AWF werden durch das GS unterstützt Wie hoch soll der Detailgrad sein Was ist Ziel und Zweck des Systems Was sind die Hauptfunktionen des Systems Wozu benötigen die Haupt-Akteure das System Welche sekundären Systemfunktionen sind noch wichtig Welche Funktionen hätte ein GUI Prototyp • Ausgehend von einem AWF • Gibt es etwas das man vorher / nachher machen muss bevor man einen AWF tut • Gibt es etwas, das man mit dem IT System tut, wenn man nicht den AWF ausführt • [ Das Beschaffen eines Tickets muss vor dem Check-In stattfinden ] • [ Das Boarding muss nach dem Check In stattfinden] • [ Flugticket ungültig, wenn Kunde nicht zum Check. In kommt ] Objektorientierte Analyse und Design mit UML 2. 0

Dokumentation • • • Anwendungsfalldiagramm Ausführliche Textliche Beschreibung Verschiedene Szenarien Prototypen für GUIs Abfrage und Mutationsereignisse für IT Systeme AWF – Sequenzdiagramm • Wichtig : beginne am besten jetzt schon ein fachliches Glossar anzulegen, das im weiteren Verlauf verfeinert wird Objektorientierte Analyse und Design mit UML 2. 0

Ein Anwendungsfall definiert • Name: Verb (o. Substantiv), Name des Vorgangs • Priorität: Priorität im Entwicklungsprozess • Beschreibung: • textuelle Beschreibung der Interaktion zwischen Benutzer und System, unter • • • Bezugnahme auf das Lastenheft (z. B. /LF 70/) Auflistung der einzelnen Schritte unter Nutzung der Begriffe des. Glossars alle Beschreibungen zusammen bilden Anwendungsfall-Katalog Objektorientierte Analyse und Design mit UML 2. 0

Anwendungsfallkatalog, Beispiel • • • Use. Case Verleihen, TODO, csi Bezeichner Use. Case_Verleihen Kurzbeschreibung: Jeder Benutzer kann sich ein Buch aus einer Bücherei ausleihen. Akteure: Entleiher, Verleiher Vorbedingungen: Der Entleiher ist am System angemeldet. Nachbedingungen: Keine. Durchführung: Der Entleiher sucht im Katalog, ob ein von ihm gewünschter Titel verfügbar ist. Die Suche soll über ISBN sowie über Autor und vollständigem Titel erfolgen. Wenn das Buch gefunden wurde, dann wird dieses Buch im Katalog für diesen Entleiher als ausgeliehen vermerkt. Das Ausleihdatum wird gespeichert, um die Einhaltung der Ausleihfrist zu überprüfen. Nachbehandlung Ausnahmen Beschreibung der Fehlersituation: Bei der Suche nach einem Buchexemplar im Katalog kann es vorkommen, daß das Buch nicht gefunden wird. Dann erscheint eine entsprechende Meldung auf dem Bildschirm. Offene Punkte: Für zukünftige Versionen ist eine Suche nach Schlagworten vorzusehen. Ebenfalls ist für die Zukunft die Möglichkeit vorzusehen, daß der Entleihvorgang ohne einen Entleiher durchführbar ist. Was ist, wenn ein Buch gefunden wird, aber es ist als „Verliehen“ vermerkt? Objektorientierte Analyse und Design mit UML 2. 0

Mutationsereignisse oder verschiedene Szenarien • Ein Ereignis ist etwas das passiert – Mutationsereignisse sind ( meist in einem IT System) etwas, die das Ablegen, Verändern oder Löschen von Informationen verursacht. Das Resultat hängt davon ab, ob die Mutation erfolgreich war. Änderung wird dem Anwender gemeldet – Ein Abfrageereignis ist etwas, das etwas mit dem Anzeigen von Informationen zu tun hat, und keine Daten verändert • Verschiedene Szenarien – Man kann je nach Detailierungsgrad unterschiedliche Szenarien durchspielen. Eine genaue ausformulierte Definition ist für eine spätere Entwicklung wichtig. Siehe Beispiel und Vorlage Objektorientierte Analyse und Design mit UML 2. 0

Anwendungsfall-Sequenzdiagramm • Nur einfach aufzubauende Abläufe A • Abfragen und Mutationsereignisse IT-SYSTEM-Airport Boardingkarte einlesen prüfen <<A>> Gültigkeit Boardkarte WENN card OK <<M>> registrieren Card vermerken SONST <<A>> Coupon Details Coupon detail ENDE WENN Objektorientierte Analyse und Design mit UML 2. 0

Alternativ ( gerade im Geschäftsprozess ) Aktivitätsdiagramm Objektorientierte Analyse und Design mit UML 2. 0

Check und Verifizierung • Syntax • Benennungen • Semantik • • Vollständigkeit ? Gibt es noch weitere AWF? Sind alle AWF korrekt – Verifizieren Ist der Detailgrad zweckmäßig, so dass folgende Aufgaben erfüllt sind • ein AWF bildet eine fachlich zusammengehörige Interaktionssequenz • Ein AWF wird durch einen Akteur eingeführt • Ein AWF liefert ein messbares und relevantes Ergebnis • wird in der Regel vollständig ausgeführt Sind die AWF richtig benannt? Die Namen der Anwendungsfälle beschreiben die Aktivität, die im System ausgeführt wird Sind die Akteure korrekt ? Sie repräsentieren Rollen zum System Sind die AWT Sequenzdiagramme vollständig – Jeder AWF sein Sequenzdiagramm. Nur ein Objekt das System beschreibt und setzt sich aus Abfrage und Mutationsereignissen zusammen Objektorientierte Analyse und Design mit UML 2. 0

Die strukturelle Sicht Alles was ich anfassen kann muss definiert sein Objektorientierte Analyse und Design mit UML 2. 0

Objekt und Klassenbildung im UML Land Reales Objekt Klassen Katze Tier Bauarbeiter Glühbirnenver -käufer Objektorientierte Analyse und Design mit UML 2. 0 Arbeiter

Bedeutung einer Klasse • Die Klasse ist ein Muster, nach dem Objekte gebildet werden • Die Klasse ist die Menge der Objekte, die nach Ihrem Muster gebildet worden ist • Klasse gibt Eigenschaften und Methoden vor • Generalisierungen und Spezialisierung von Klassen • Klassen hängen immer mit statischen und dynamischen Geschäftsregeln zusammen Objektorientierte Analyse und Design mit UML 2. 0

Statische und dynamische Geschäftsregeln • Fachliche Regeln, die nichts mit dem IT system zu tun haben. • • Ein Flug darf nicht gestrichen werden, wenn er bereits gestartet ist ein Sitzplatz kann nur einem Passagier zugewiesen werden. • Viele Anforderungen lassen sich nicht mit GR spezifizieren, dafür gibt es den Anforderungskatalog eines IT Systems • statische GR sind jederzeit überprüfbar • dynamische GR sind nur zu einem bestimmten Zeitpunkt, wenn etwas passiert, überprüfbar Objektorientierte Analyse und Design mit UML 2. 0

Die Elemente der Sicht • Klasse mit Attributen und Namen • Generalisierung • Assoziation mit Leserichtung und Aktivitätsbeschreibung • Multiplizität • Aggregation ( Ist Teil von ) • Komposition ( Ist fester Bestandteil von ) ( Ich kann ohne Dich nicht leben ) verb * 0. . 1 Objektorientierte Analyse und Design mit UML 2. 0

Lesen von Klassendiagrammen Kunde 1 Datum * besitzt Name Ticket Flughafen B-Code Name Nummer 1 Raucher Start 1 Ziel 1 1. . 4 1. . * Coupon Flugnummer Einlöse-Datum Zeit Klasse Art Mahlzeit Airline 1. . * • Ein Objekt einer Klasse hat eine Assoziation mit einem Obj einer anderen Klasse • Ein Kunde besitzt * Ticket (s) • Ein Kunde besitzt null oder ein oder mehrere Tickets • Assoziationen kann auch in die andere Richtung gelesen werden : Ein Ticket ist im Besitzt von genau einem Kunden • Ein Coupon ist Teil von genau einem Ticket / Ticket besteht aus 1. . 4 Coupons Objektorientierte Analyse und Design mit UML 2. 0

Erstellen von Klassendiagrammen TOP-DOWN • zuerst • BOTTOM-UP • nimmt als Ausgangsinfos Top-Down Elemente • Verbinden Objektorientierte Analyse und Design mit UML 2. 0

Top-Down • Klassen identifizieren und modellieren • • Basis ist meist: Inhalte der Use-Cases, Substantive der Beschreibung Aktivitäten und Verantwortlichkeiten der Elemente des Systems Welches sind die wichtigsten Dinge mit denen im System gearbeitet wird? Welche Klassen sich daraus bilden? • Assoziationen finden und modellieren • • Welche fachlichen Beziehungen stehen zwischen den Objekten? Wieviele Objekte einer Klasse sind an einer Beziehung beteiligt? • Attribute definieren • • Was will ich über das Objekt wissen Analyse von Eingaben und Abfragen kann helfen Objektorientierte Analyse und Design mit UML 2. 0

Top-Down • Geforderte Abfragen und Eingaben auflisten • • Welche Infos liefert das System Welche Infos nimmt das System an • Abfragen und Eingaben formalisieren • • Wie sieht die Darstellung konkret aus? ZB vorhandene Formulare oder ähnliches in Papierform • Informationsanalyse durchführen • • • Welche Klassen, Assoziationen, Attribute brauchen wir? Welche Datenelemente sind auf der Einausgabeseite vorhanden? Welche Objekte verstecken sich hinter Datenelementen? Welche Beziehungen zwischen den gefunden Elementen? Welche bereits modellierten Elemente können wieder verwendet werden? • Klassendiagramme konsolidieren Objektorientierte Analyse und Design mit UML 2. 0

Konsolidieren und verbinden • Beide Klassendiagramme zu einem verbinden • Gibt es Klassen, die unterschiedliche namen haben, aber das Gleiche abbilden? • Gibt es Beziehungen, die gleiche Bedeutung haben • Gibt es Attribute, die doppelt vorkommen Objektorientierte Analyse und Design mit UML 2. 0

Verifizieren • Ist das Klassendiagramm vollständig ? • Kann mit der Ablaufsicht überprüft werden • Ist das Klassendiagramm korrekt • Syntax, Semantik • Was sagen die Wissensträger beim gemeinsamen Lesen ? • Überarbeite und erweitere das Glossar • Hinterfrage Prozesswörter! • Prozesswörter sind Verben und substantivierte Verben wie reservieren, buchen, Mitteilung (mitteilen). Stelle für jedes Prozesswort die W-Fragen: wer, wo, was, wann, wie. Beispielsweise. Wer reserviert? . , . Was wird reserviert? . etc. • Hinterfrage alle Vergleiche und Steigerungen! • • • Vergleiche sind Formulierungen die Wörter wie. besser, schneller, einfacher. enthalten. Steigerungen enthalten Steigerungsformen dieser Wörter (. am besten. ). Frage jeweils, worauf sich die Steigerungen beziehen (. schneller als was? . ), wie man die geforderte Eigenschaft messen oder vergleichen kann und mit welcher Genauigkeit verglichen werden soll. Objektorientierte Analyse und Design mit UML 2. 0

Verifizieren • Hinterfrage alle Universalquantoren! • Universalquantoren sind Wörter wie. alle. , . nie. , . immer. , . jeder. , . stets. etc. , mit denen eine Menge oder Anzahl von etwas beschrieben wird. • • Frage hier nach den möglichen Ausnahmen und den damit verbundenen Annahmen: • Ist wirklich jeden Monat eine Monatsrechnung zu schreiben? Nein, nur wenn die Rechnungssumme 20, 00. übersteigt. • Hinterfrage alle Bedingungen, Ausnahmen und Varianten! • Bei Formulierungen, die Wörter wie. falls. , . wenn. , . dann. , . abhängig von. , . sofern. etc. enthalten, frage danach, ob dies wirklich alle Möglichkeiten sind oder ob es noch weitere gibt. • Definiere jede mögliche Variante, erstelle eine vollständige Liste aller Möglichkeiten. Objektorientierte Analyse und Design mit UML 2. 0

Verantwortlichkeiten • Oft modelliert man vor den Attributen und. Operationen zunächst die Verantwortlichkeiten der Klassen. • Verantwortlichkeit = Vertrag oder Verpflichtung einer Klasse • Beim Modellieren von Klassen ist es ein guter Ausgangspunkt, die Verantwortlichkeiten der Gegenstände des Vokabulars zu spezifizieren. • Eine Klasse kann beliebig viele Verantwortlichkeiten besitzen • • in der Praxis hat jedoch jede gut strukturierte Klasse mindestens eine und höchstens ein paar Verantwortlichkeiten. • Wenn man diese Modelle verfeinert, übersetzt man die Verantwortlichkeiten in eine Menge von Attributen und Operationen. • Verantwortlichkeiten bestehen einfach aus formlosem Text. Objektorientierte Analyse und Design mit UML 2. 0

CRC-Karten-Technik (Class , Responsibilities und Collaborators) • Problem: Wie finde ich Klassen und Verantwortlichkeiten in der Analyse? • • bewährtes Hilfsmittel für objekt-orientierte Analyse: CRC-Karten spielerisches. Erkunden der Aufgabe in Form eines Rollenspiels jedes Teammitglied übernimmt die Funktion. seiner. Klasse notiert während des Spiels die gerade benötigten Fähigkeiten auf der CRC-Karte • Ergebnis: erstes Papiermodell des zu erstellenden Systems • Es ist immer genau ein Spieler. am Zug. . (Hierzu Token verwenden!) • Der aktive Mitspieler erklärt laut, in welchen Schritten er seine aktuelle Aufgabe erledigen kann. • Tätigkeiten, die er alleine erledigen kann, vermerkt er als Verantwortlichkeiten seiner Klasse auf der Karte. • Bei Tätigkeiten, für die er die Mithilfe von anderen Akteuren braucht, vermerkt er diese als Mithelfer bei der Tätigkeit Objektorientierte Analyse und Design mit UML 2. 0

CRC Objektorientierte Analyse und Design mit UML 2. 0

Verfeinern von Klassendiagrammen Objektorientierte Analyse und Design mit UML 2. 0

Die Verhaltenssicht • Leben und Sterben in UML Land Objektorientierte Analyse und Design mit UML 2. 0

Das Leben eines Flugzeugs : Flugzeug Bestellung Kennzeichen = „“ Inbetriebnahme = „“ Airline = „“ Status = „bestellt“ : Flugzeug Auslieferung Kennzeichen = „IBBB“ Inbetriebnahme = „ 01012001“ Airline = „MMM“ Status = „aktiv“ Verkauf : Flugzeug Kennzeichen = „? “ Inbetriebnahme = „ 01012001“ Airline = „BBB“ Status = „verkauft“ Ausmustern : Flugzeug Kennzeichen = „? “ Inbetriebnahme = „ 01012001“ Airline = „? “ Status = „ausgemustert“ Objektorientierte Analyse und Design mit UML 2. 0

Objekt leben! • Auslöser für die Geburt eines Objekts im IT System ist ein Mutationsereignis. Bei GF ist dies meist schon vor dem System geschehen • Auslöser für den Tod eines Objekts im IT System ist ein Mutationsereignis. • Solange das Objekt lebt kann es in einem einfachen staischen Zustandsdiagramm beschrieben werden • Bei dynamischen GR wird aber erst das eigentliche Verhalten eines Objekts bestimmt. Dann wird es erst interessant • • Ein Flugzeug darf nicht ausgemustert werden, solange es noch für Flüge geplant ist ein Flugzeug darf keinem Flug zugeordnet werden, solange es sich noch in der Wartung befindet • In unterschiedlichen Zuständen reagieren Objekte anders. • [Überlegen Sie sich dynamische Geschäftsregeln für ein Objekt ] Objektorientierte Analyse und Design mit UML 2. 0

Zustandsdiagramm • State Machine Diagramm • Für Reaktionen des Systems • Gut für Modellierung einer Oberfläche, die meist auf Befehle eines Benutzers reagieren und keine eigene Aktivitäten initiieren • Gut für die Modellierung von Kommunikationsprotokollen. Sogg Protokoll. Zustandsdiagramme Objektorientierte Analyse und Design mit UML 2. 0

Elemente des Zustandsdiagramms • Startzustand – Elemente existieren noch nicht • Zustand wird durch die Werte seiner Attribute und Assoziationen bestimmt. Es repräsentiert eine Menge von Kombinationen von Assoziationen, in denen sich Objekt als Reaktion auf Ereignisse gleich verhält. Interne Übergänge <<M>> Ereignis/ bedeuten, dass das Objekt zwar reagiert aber seinen Zustand nicht verändert und somit auf sich selbst zurückkommt. Mutationsereignis ist Auslöser Ruhe <<M>> Ereignis/ • • Endzustand. Elemente existieren nicht mehr • Übergang von einem Zustand in den nächsten. Mutationsereignis ist der Auslöser • Aktion ist eine Tätigkeit des Objekts, welches durch das Ereignis ausgelöst wird. Text kann standardisiert oder textlich sein. Standards: ENTRY DO EXIT / CREATE SET DELETE • Wächterbedingung muss wahr sein, damit der Übergang stattfindet <<M>> Ereignis/Aktion [Wächerbedingung] Objektorientierte Analyse und Design mit UML 2. 0

Lesen von Zustandsdiagrammen • Beispiel Flugzeug • Wird nicht sequentiell gelesen, kann aber für Fragen benutzt werden: • • • Was passiert mit dem Objekt, wenn ein bestimmtes Ereignis eintritt? Wie reagiert ein Objekt, das sich in einem bestimmten Zustand befindet Welche Ereignisse sind für das Objekt relevant Wie, kann ein Zustand verlassen werden und wie kann er erreicht werden Objektorientierte Analyse und Design mit UML 2. 0

Lesen von Zustandsdiagrammen • Zustände können auch so gezeichnet werden, dass innerhalb eines Zustands wieder Unterzustände existieren. Objektorientierte Analyse und Design mit UML 2. 0

Fehler Im Diagramm Objektorientierte Analyse und Design mit UML 2. 0

Checkliste Zustandsdiagramm • • Identifikation der betroffenen Mutationsereignisse Zeitliche Gruppierung der relevanten Ereignisse Wie sieht ein normales Leben aus? Modellierung von Zuständen und Übergängen – Welche gibt es? • Zustandsdiagramm um Aktionen ergänzen – Was tun die Objekte so den ganzen Tag? • Verifizieren Objektorientierte Analyse und Design mit UML 2. 0

Verifizieren Zustandsdiagramm • Ist ein Endzustand formuliert = Oder lebt es ewig ? • Ist von jedem Zustand ein Übergang in den Endzustand möglich ( auch indirekt ) • Wird zwischen Einfrieren und Tod eines Objekts unterschieden • Gibt es für einen Zustand mindestens ein spezifisches Ereignis? • Falls 2 oder mehr Übergänge den Zustand verlassen – sind die Guards richtig gesetzt? Objektorientierte Analyse und Design mit UML 2. 0

Die Ablaufsicht • Reise in das Innere des Systems Objektorientierte Analyse und Design mit UML 2. 0

Objektorientierte Analyse und Design mit UML 2. 0