Objektorientierte Analyse und Design mit UML 2.0 UML 2.0 Dokumentation by Markus Röder Copyright...

Objektorientierte Analyse und Design mit UML 2.0

UML 2.0

Dokumentation by Markus RöderCopyright 2006 [email protected]

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


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ätssicherungund Verifizierung

Integration


Der Entwicklungsprozess

Analysieren

Bewerten

Modellieren

Verifizieren


Hauptanwendungsgebiete für UML

• Geschäftsmodellentwicklung• IT Modell – Entwicklung• IT Integration


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


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• ObjektdiagrammKlein(-e Änderungen) aber oho:• Paketdiagramm• VerteilungsdiagrammMassiv und tiefgreifend verändert:• Aktivitätsdiagramm• Sequenzdiagramm• ZustandsautomatVollständig neu:• Kompositionsstrukturdiagramm• Interaktionsübersichtsdiagramm• Timing-Diagramm• Kommunikationsdiagramm


Modell des Geschäftssystems

• Knowhow für Business Professionals


Gliederung


Geschäftsanwendungsfälle


Modell des IT Systems

• Entwicklung und Integration vonIT-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


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

Check in

ExpressCheckin

Boarding Carderstellen

<<include>>

<<include>>

Check-In MA

1

2

3

Kunde eingeben

<<extend>>condition {Kunde nicht gefunden und genug Bares}

extension Point : Kunde prüfen

4

5

6

Systemgrenze


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

<UseCaseID>: <Use Case Name: Short Active Verb Phrase>

1. Characteristic Information The following defines information that pertains to this particular use case. Each piece of information is important in understanding the purpose behind the Use Case. Goal In Context: <Longer More Descriptive Statement Of The Goal>

Scope: <System Under Analysis or Design, This is the Black Box The Primary Actor is interacting with>

Level: <Select One: Strategic, Task, Sub-Functionality>

Pre-Condition: <What Must Be True Before The Use Case Is Started>

Success End Condition: <What Must Be True After The Use Case Is Completed>

Failed End Condition: <Describes What Must Be Avoided. If these are true, then the Use Case has failed>

Primary Actor: <Role Name>: <Description Of The Actor that is interacting with the system, an actor can be anything with behavior>

Trigger Event: <Action or Time event that starts the Use Case, often this is step 1>

2. Main Success Scenario This Scenario describes the steps that are taken from trigger event to goal completion when everything works without failure. It also describes any required cleanup that is done after the goal has been reached. The steps are listed below: Step Actor Action Description <Step #> <Name The

Actor> <Give A Description Of What The Actor Is Doing>

3. Scenario Extensions This is a listing of how each step in the Main Success Scenario can be extended. Another way to think of this is how can things go wrong. The extensions are followed until either the Main Success Scenario is rejoined or the Failed End Condition is met. The Step refers to the Failed Step in the Main Success Scenario and has a letter associated with it. I.E if Step 3 fails the Extension Step is 3a. Step Condition Action Description <Step #> <What Caused The

Branch To Occur> <Description Of The Action To Be Performed or the name of a Sub Use Case>


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

Objekt Klassen

TierKatze

Reales

Bauarbeiter

Glühbirnenver-käufer

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


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 )

* 0..1

verb


Lesen von Klassendiagrammen

• 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

Kunde

Datum

Name

Ticket

B-Code

Nummer

Raucher

Coupon

Einlöse-Datum

Klasse

Mahlzeit

besitzt

1 *

1

1..4

Flughafen

Name

Flugnummer

Zeit

Art

Airline

1 Ziel

1..*

1 Start

1..*


Erstellen von Klassendiagrammen

TOP-DOWN• zuerst

• BOTTOM-UP• nimmt als Ausgangsinfos Top-Down

Elemente

• Verbinden


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


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.


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ängigvon., .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


Die Verhaltenssicht

• Leben und Sterben in UML Land


Das Leben eines Flugzeugs

:Flugzeug

Kennzeichen = „“

Inbetriebnahme = „“

Airline = „“

Status = „bestellt“

:Flugzeug

Kennzeichen = „IBBB“

Inbetriebnahme = „01012001“

Airline = „MMM“

Status = „aktiv“

:Flugzeug

Kennzeichen = „?“


Airline = „BBB“

Status = „verkauft“

:Flugzeug

Kennzeichen = „?“


Airline = „?“

Status = „ausgemustert“

Bestellung

Auslieferung

Verkauf

Ausmustern


Objekt leben!

• Auslöser für die Geburt eines Objekts im IT Systemist ein Mutationsereignis. Bei GF ist dies meist schon vor dem System geschehen

• Auslöser für den Tod eines Objekts im IT Systemist 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

<<M>> Ereignis/

Ruhe<<M>> Ereignis/

Ruhe

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


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


Die Ablaufsicht

• Reise in das Innere des Systems


action activity activity diagram actor aggregation association association class association role attribute behavior diagram bidirectional association bound element cardinality class class diagram collaboration diagram component component diagram composition constraint CRC-Card decision dependency deployment diagram discriminator event focus of control generalization instance interaction diagram interface lifeline link message method multiplicity navigability node note object object diagram operation package parameterized class pattern problem domain property property string refinement relationship scenario

Aktion Aktivität Aktivitätsdiagramm Akteur Aggregation, Teile/Ganzes-Beziehung Assoziation (ungerichtet) Assoziationsklasse Assoziationsrolle Attribut Verhaltensdiagramm bidirektionale Assoziation gebundenes Element Kardinalität Klasse Klassendiagramm Kollaborationsdiagramm Komponente Komponentendiagramm Komposition Einschränkung CRC-Karte, Klassenkarte Entscheidung Abhängigkeit Verteilungsdiagramm Diskriminator, Unterscheidungsmerkmal Ereignis Steuerungsfokus Generalisierung Exemplar Interaktionsdiagramm Schnittstelle Lebenslinie Objektbeziehung Nachricht Methode Multiplizität Navigierbarkeit Knoten Notiz, Anmerkung Objekt Objektdiagramm Operation Paket parametrisierte Klasse Muster Problembereich Eigenschaft Eigenschaftswert Verfeinerung Beziehung Szenario

Objektorientierte Analyse und Design mit UML 2.0 UML 2.0 Dokumentation by Markus Röder Copyright...

Documents

Transcript of Objektorientierte Analyse und Design mit UML 2.0 UML 2.0 Dokumentation by Markus Röder Copyright...