Modellierungstipps für die Anwendungsfallmodellierung

Transkript

1 Modellierungstipps für die Anwendungsfallmodellierung Identifiziere nur relativ grobe Abläufe als Anwendungsfälle! Anwendungsfälle werden nicht in weitere Anwendungsfälle zerlegt, höchstens unter Verwendung von Anwendungsfallbeziehungen weiter verfeinert! Schreibe Anwendungsfälle vom Standpunkt eines Akteurs im Aktiv! Definiere ein Use Case Template zur Dokumentation eines Anwendungsfalles, z.b. Nr. und Name des Anwendungsfalles, Kurzbeschreibung, beteiligte Akteure, Auslöser bzw. Vorbedingungen, Ergebnisse bzw. Nachbedingungen, Ablaufbeschreibung untergliedert in einzelne Schritte, die wiederum durch eine Kurzbeschreibung repräsentiert werden, Ausnahmen/Varianten, offene Punkte/Fragen, Dokumente/Referenzen Verbinde die Anwendungsfälle im Anwendungsfalldiagramm mit der verbalen Spezifikation über einen Hyperlink (meist unterstützt durch das UML-CASE-Tool)! Sei vorsichtig/sparsam mit <<extend>>-, <<include>>- und Vererbungsbeziehungen für Anwendungsfälle! Verwende die Anwendungsfälle als Ausgangspunkt für weitere Modellierung, Test, Dokumentation und Präsentationen!

2 Analysemodell (auml) vs. Entwurfsmodell (duml/juml) (Klassendiagramme) Analysemodell (fachliche Sicht) Klassen sind Fachbegriffe Attribute i. Allg. ohne Datentypen ggfs. mit Multiplizitäten Methoden ohne Parameter und Rückgabewert Bidirektionale Assoziationen/ Aggregationen/Kompositionen Beschreibung von Assoziationen (Multiplizitäten, Rollennamen, Assoziationsnamen (mit Leserichtung) ggfs. mit Qualifier Assoziationsklassen und n-äre- Beziehungen Generalisierung/Spezialisierung (Vererbung) Abgeleitete Attribute und Methoden Aufzählungen (Enumerationen) Entwurfsmodell (fachliche vereinigt mit technischer Sicht) Klassen abstrakt, Interface, Stereotyp, ggf. Klassen streichen, hinzufügen und umbenennen Attribute Sichtbarkeiten, Ableitung, Klassenattribute, Initialisierung, weitere spezielle Eigenschaften Operationen Parameter, Sichtbarkeiten, Rückgabewert, Klassenoperation Assoziationen gerichtet, geordnet / sortiert Auflösen von Ass.klassen/n-äre Beziehungen Abhängigkeiten Packages Hilfsmethoden (Konstruktoren, getters/setters, tostring() u.a.)

3 Ergänzende Modellierungskonventionen für Klassendiagramme Namenskonventionen wie aus Java gewöhnt (Substantiv im Singular für Klassennamen, Verb für Methodennamen, ) Generalisierung/Spezialisierung: Analyse: In der Analyse wird die Generalisierung/Spezialisierung auch oft für die Darstellung einer Klassifikation benutzt. D.h., wenn in der textuellen Spezifikation domänenspezifische Begriffe auftauchen, dann sollten diese im Modell berücksichtigt werden (auch wenn die entstehenden Unterklassen keine speziellen Attribute/Methoden haben). Entwurf: Vererbung macht nur Sinn, wenn wirklich eine Spezialisierung (neue Methoden bzw. Attribute bzw. überschriebene Methoden) stattfindet. In UML-Diagrammen werden in Unterklassen von Vererbungshierarchien nur zu überschreibende Methoden und zusätzliche Attribute/Methoden dargestellt. Attribute werden entweder als Attribut (wenn Standard-Datentyp wie int oder String) oder als Assoziation aufgeführt (nicht doppelt). Der typische Fall der Assoziation tritt auf, wenn der Typ eines Attributes ein nutzerdefinierter Typ ist. Jede Assoziation muss beschriftet sein (ein oder zwei Multiplizitäten und Assoziationsnamen mit Leserichtung oder mindestens ein Rollenname). Im Entwurfsmodell verwendete Rollennamen werden in der Implementation zum Attribut-(/Variablen-)Namen. Ebenso sollen zur besseren Lesbarkeit des Java-Codes auch alle anderen Namen (Klassen, Attribute, Methoden) wie im Entwurfsmodell verwendet werden. Fehlende Multiplizitäten: werden im Analysemodell als nicht bekannt/unterspezifiziert interpretiert (falls aus der textuellen Beschreibung nicht erkennbar) werden im Entwurfsmodell als 1 wenn relevant (navigierbares Assoziationsende) als nicht relevant (keine Navigation an diesem Assoziationsende) interpretiert.

4 Klassifikation von UML-Zustandsmodellen nach Abstraktionsebene Analyseebene Entwurfsebene Analysezustandsmodell (ASM) Entwurfszustandsmodell (DSM) danach, worauf sich das Zustandsmodell bezieht Objekt Anwendungsfall Objektlebenszyklus (OLC) Anwendungsfalllebenszyklus (ULC) Beschreibung eines technischen Gerätes/Systemes (technische) Steuerungsmachine (CSM) entsprechend der UML2.0-Spezifikation Spezifikation des Verhaltens Verhaltens(zustands)maschine (BSM) (Behavioral state machine) Spezifikation der zulässigen Reihenfolge von Operationen Protokollmaschine (PSM) (Protocol State Machine) U11

5 BSM Beispiele für Zustandsmodelle OLC ULC CSM (Flug)Buchung [Störlle2005, Abschnitt 10.2] (ASM) Einchecken [Störlle2005, Abschnitt 10.3] (Oft aber im Aktivitätsdiagramm modelliert) Anrufbeantworter WS08/09 U11 Fahrkartenautomat SS08 Klausur Raumheizung WS01/02 Klausur Infrarot-Wärmekabine WS06/07 Klausur Garagentor WS07/08 U14 MarkIV Coffeemaker WS05/06 U9/U10 PSM Konto WS08/09 U11 Submission WS07/08 Klausur Buchausleihe SS07 Klausur Car SS09 Klausur Idee WS09/10 Klausur (COOLIDEAS) (ASM) Online-Shop (Warenkorb) WS00/01 Klausur Videokonferenzgerät SS06 Klausur Temperaturfernanzeige WS05/06 Klausur U11

6 Synonyme für Fachbegriffe in der Modellierung ST Vorlesung/ Übung Kontextdiagramm (U12) Top-Level-Architektur (U12) Anwendungsfall/Use Case (U12) Analyse-Klassendiagramm, Domänenmodell (U09, U10) Entwurfs-Klassendiagramm (U13) Zustandsmodell/-maschine (U11) Verhaltensmaschinezustandsmaschine Protokollmaschine Steuerungsmachine (U11) Lehrbuch für Einsteiger Kontextdiagramm (S. 58) Facharchitekturdiagramm (S. 60) Nutzfall (S. 62) Analyse-Klassendiagramm (S. 80) mit geringen Unterschieden im Verständnis (insbesondere mit Navigation) Entwurfs- und Implementations- Klassendiagramm (S. 91, S. 107) Zustandsautomat (S. 117) (einfacher) Zustandsautomat (S. 117) Protokollautomat (S. 126) Steuerungsautomat (S. 130)