Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Objektorientierte Analyse und Design mit UML 2.0 UML 2.0 Dokumentation by Markus Röder Copyright 2006 IT und Sytementwicklung :

Ähnliche Präsentationen


Präsentation zum Thema: "Objektorientierte Analyse und Design mit UML 2.0 UML 2.0 Dokumentation by Markus Röder Copyright 2006 IT und Sytementwicklung :"—  Präsentation transkript:

1

2 Objektorientierte Analyse und Design mit UML 2.0 UML 2.0 Dokumentation by Markus Röder Copyright 2006 IT und Sytementwicklung : NLP und Kommunikation :

3 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

4 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

5 Objektorientierte Analyse und Design mit UML 2.0 Die UML Softwarearchitektur

6 Objektorientierte Analyse und Design mit UML 2.0 Die UML Historie OMGObject Management Group OOSE Object Orientierte Software Entwicklung

7 Objektorientierte Analyse und Design mit UML 2.0 Historie

8 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

9 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

10 Objektorientierte Analyse und Design mit UML 2.0 Nachteile und Grenzen von UML siehe später… wir wollen zuerst die Möglichkeiten kennen lernen

11 Objektorientierte Analyse und Design mit UML 2.0 Inkrementelle Softwareentwicklung mit UML Planung Entwicklung Qualitätssicherung und Verifizierung Integration

12 Objektorientierte Analyse und Design mit UML 2.0 Der Entwicklungsprozess Analysieren Bewerten Modellieren Verifizieren

13 Objektorientierte Analyse und Design mit UML 2.0 Hauptanwendungsgebiete für UML Geschäftsmodellentwicklung IT Modell – Entwicklung IT Integration

14 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

15 Objektorientierte Analyse und Design mit UML 2.0 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!

16 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

17 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

18 Objektorientierte Analyse und Design mit UML 2.0 Modell des Geschäftssystems Knowhow für Business Professionals

19 Objektorientierte Analyse und Design mit UML 2.0 Gliederung

20 Objektorientierte Analyse und Design mit UML 2.0 Geschäftsanwendungsfälle

21 Objektorientierte Analyse und Design mit UML 2.0 Modell des IT Systems Entwicklung und Integration von IT-Systemen

22 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

23 Objektorientierte Analyse und Design mit UML 2.0

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

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

26 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

27 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

28 Objektorientierte Analyse und Design mit UML 2.0 Lesen von AWF Check in Express Checkin Boarding Card erstellen > Check-In MA Kunde eingeben > condition {Kunde nicht gefunden und genug Bares} extension Point : Kunde prüfen Systemgrenze

29 Objektorientierte Analyse und Design mit UML 2.0 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

30 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

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

32 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

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

34 Objektorientierte Analyse und Design mit UML 2.0 Anwendungsfallkatalog, BeispielBeispiel UseCase Verleihen, TODO, csi BezeichnerUseCase_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?

35 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

36 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 WENN card OK Card vermerken SONST Coupon detail ENDE WENN > Gültigkeit Boardkarte > registrieren > Coupon Details

37 Objektorientierte Analyse und Design mit UML 2.0 Alternativ ( gerade im Geschäftsprozess ) Aktivitätsdiagramm

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

39 Objektorientierte Analyse und Design mit UML 2.0 Die strukturelle Sicht Alles was ich anfassen kann muss definiert sein

40 Objektorientierte Analyse und Design mit UML 2.0 Objekt und Klassenbildung im UML Land ObjektKlassen TierKatze Reales Bauarbeiter Glühbirnenver -käufer Arbeiter

41 Objektorientierte Analyse und Design mit UML 2.0 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

42 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

43 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 ) * 0..1 verb

44 Objektorientierte Analyse und Design mit UML 2.0 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* Flughafen Name Flugnummer Zeit Art Airline 1 Ziel 1..* 1 Start 1..*

45 Objektorientierte Analyse und Design mit UML 2.0 Erstellen von Klassendiagrammen TOP-DOWN zuerst BOTTOM-UP nimmt als Ausgangsinfos Top-Down Elemente Verbinden

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

47 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

48 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 die gleiche Bedeutung haben Gibt es Attribute, die doppelt vorkommen

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

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

51 Objektorientierte Analyse und Design mit UML 2.0 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.

52 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

53 Objektorientierte Analyse und Design mit UML 2.0 CRC

54 Objektorientierte Analyse und Design mit UML 2.0 Verfeinern von Klassendiagrammen

55 Objektorientierte Analyse und Design mit UML 2.0 Die Verhaltenssicht Leben und Sterben in UML Land

56 Objektorientierte Analyse und Design mit UML 2.0 Das Leben eines Flugzeugs :Flugzeug Kennzeichen = Inbetriebnahme = Airline = Status = bestellt :Flugzeug Kennzeichen = IBBB Inbetriebnahme = Airline = MMM Status = aktiv :Flugzeug Kennzeichen = ? Inbetriebnahme = Airline = BBB Status = verkauft :Flugzeug Kennzeichen = ? Inbetriebnahme = Airline = ? Status = ausgemustert Bestellung Auslieferung Verkauf Ausmustern

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

58 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

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

60 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

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

62 Objektorientierte Analyse und Design mit UML 2.0 Lesen von Zustandsdiagrammen Beispiel aus dem Internet. Hier wurde zum Teil vergessen die Zustände genauer zu definieren

63 Objektorientierte Analyse und Design mit UML 2.0 Fehler Im Diagramm

64 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

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

66 Objektorientierte Analyse und Design mit UML 2.0 Die Ablaufsicht Reise in das Innere des Systems

67 Objektorientierte Analyse und Design mit UML 2.0


Herunterladen ppt "Objektorientierte Analyse und Design mit UML 2.0 UML 2.0 Dokumentation by Markus Röder Copyright 2006 IT und Sytementwicklung :"

Ähnliche Präsentationen


Google-Anzeigen