UML 2.0 Dokumentation by Markus Röder Copyright 2006

Präsentation zum Thema: "UML 2.0 Dokumentation by Markus Röder Copyright 2006"—  Präsentation transkript:

1 UML 2.0 Dokumentation by Markus Röder Copyright 2006 mr@erex.de
IT und Sytementwicklung : NLP und Kommunikation :

2 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

3 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

4 Die UML Softwarearchitektur

5 Die UML Historie OMG Object Management Group
OOSE Object Orientierte Software Entwicklung

6 Historie

7 • Präzisionssteigerung
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

8 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

9 Nachteile und Grenzen von UML
siehe später… wir wollen zuerst die Möglichkeiten kennen lernen

10 Inkrementelle Softwareentwicklung mit UML
Planung Entwicklung Qualitätssicherung und Verifizierung Integration

11 Der Entwicklungsprozess
Verifizieren Modellieren Analysieren Bewerten

12 Hauptanwendungsgebiete für UML
Geschäftsmodellentwicklung IT Modell – Entwicklung IT Integration

13 Modelle und Sichten eines Systems
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

14 Der Analyse Prozess für ein Modell
Wissensträger WT liefern Fakten 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!

15 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

16 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

17 Modell des Geschäftssystems
Knowhow für Business Professionals

18 Gliederung

19 Geschäftsanwendungsfälle

20 Entwicklung und Integration von IT-Systemen
Modell des IT Systems Entwicklung und Integration von IT-Systemen

21 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

22

23 Es ist egal wie es funktioniert, Hauptsache es funktioniert
Die Sicht von Außen Es ist egal wie es funktioniert, Hauptsache es funktioniert

24 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.

25 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

26 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

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

28 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

29 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

30 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 CheckIn kommt ]

31 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

32 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. /LF70/) Auflistung der einzelnen Schritte unter Nutzung der Begriffe des . Glossars alle Beschreibungen zusammen bilden den Anwendungsfall-Katalog

33 Anwendungsfallkatalog, Beispiel
UseCase Verleihen, TODO, csi Bezeichner UseCase_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?

34 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

35 Anwendungsfall-Sequenzdiagramm
Nur einfach aufzubauende Abläufe A Abfragen und Mutationsereignisse IT-SYSTEM-Airport Boardingkarte einlesen prüfen WENN card OK Card vermerken SONST Coupon detail ENDE WENN <<A>> Gültigkeit Boardkarte <<M>> registrieren <<A>> Coupon Details

36 Alternativ ( gerade im Geschäftsprozess ) Aktivitätsdiagramm

37 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 das System beschreibt und setzt sich aus Abfrage und Mutationsereignissen zusammen

38 Die strukturelle Sicht
Alles was ich anfassen kann muss definiert sein

39 Objekt und Klassenbildung im UML Land
Reales Objekt Klassen Katze Tier Bauarbeiter Arbeiter Glühbirnenver-käufer

40 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

41 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

42 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 *

43 Lesen von Klassendiagrammen
Kunde Datum Name Ticket B-Code Nummer Raucher Flughafen Name 1 * besitzt 1 Start Ziel Rollen 1 1..4 1..* 1..* Coupon Einlöse-Datum Klasse Mahlzeit Flugnummer Zeit Art Airline 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

44 Erstellen von Klassendiagrammen
TOP-DOWN zuerst BOTTOM-UP nimmt als Ausgangsinfos Top-Down Elemente Verbinden

45 Klassen identifizieren und modellieren
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 lassen 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

46 Geforderte Abfragen und Eingaben auflisten
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

47 Konsolidieren und verbinden
Beide Klassendiagramme zu einem verbinden Gibt es Klassen, die unterschiedliche namen haben, aber das Gleiche abbilden? Gibt es Beziehungen, die die gleiche Bedeutung haben Gibt es Attribute, die doppelt vorkommen

48 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.

49 Hinterfrage alle Universalquantoren!
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.

50 Verantwortlichkeiten
Oft modelliert man vor den Attributen undOperationen 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.

51 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

52 CRC

53 Verfeinern von Klassendiagrammen

54 Leben und Sterben in UML Land
Die Verhaltenssicht Leben und Sterben in UML Land

55 Das Leben eines Flugzeugs
Kennzeichen = „“ Inbetriebnahme = „“ Airline = „“ Status = „bestellt“ Bestellung :Flugzeug Kennzeichen = „IBBB“ Inbetriebnahme = „ “ Airline = „MMM“ Status = „aktiv“ Auslieferung :Flugzeug Kennzeichen = „?“ Inbetriebnahme = „ “ Airline = „BBB“ Status = „verkauft“ Verkauf :Flugzeug Kennzeichen = „?“ Inbetriebnahme = „ “ Airline = „?“ Status = „ausgemustert“ Ausmustern

56 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 ]

57 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

58 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 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 Ruhe <<M>> Ereignis/ Ruhe <<M>> Ereignis/ <<M>> Ereignis/ <<M>> Ereignis/Aktion [Wächerbedingung]

59 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

60 Lesen von Zustandsdiagrammen
Zustände können auch so gezeichnet werden, dass innerhalb eines Zustands wieder Unterzustände existieren.

61 Lesen von Zustandsdiagrammen
Beispiel aus dem Internet. Hier wurde zum Teil vergessen die Zustände genauer zu definieren

62 Fehler Im Diagramm

63 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

64 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?

65 Reise in das Innere des Systems
Die Ablaufsicht Reise in das Innere des Systems

66