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

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

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

Die UML Softwarearchitektur

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

Historie

• 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

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

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

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

Der Entwicklungsprozess Verifizieren Modellieren Analysieren Bewerten

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

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

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!

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

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

Modell des Geschäftssystems Knowhow für Business Professionals

Gliederung

Geschäftsanwendungsfälle

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

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

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

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.

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

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

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

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

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

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 ]

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

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

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?

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

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

Alternativ ( gerade im Geschäftsprozess ) Aktivitätsdiagramm

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

Die strukturelle Sicht Alles was ich anfassen kann muss definiert sein

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

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

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

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

Lesen von Klassendiagrammen Kunde Datum Name Ticket B-Code Nummer Raucher Flughafen Name 1 * besitzt 1 Start 1 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

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

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

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

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

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.

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.

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.

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

CRC

Verfeinern von Klassendiagrammen

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

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

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 ]

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

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]

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

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

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

Fehler Im Diagramm

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

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?

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