Tamagotchi-Spezifikation in UML

Transkript

1 Tamagotchi-Spezifikation in UML Christian Becker Steffen Glomb Michael Graf

2 Gliederung Grundlagen Notation Werkzeug Modellierung Details der Spezifikation Erfahrungen Beurteilung von Notation und Werkzeug Review Typische Fehler Fazit 2(21)

3 Grundlagen - UML als Notation Notation: UML (Unified Modeling Language), Version 1.1 Autoren: James Rumbaugh, Grady Booch, Ivar Jacobson u.a. Partner: Rational, IBM, Microsoft, HP, Oracle u.a. Ziel: Vereinigung bestehender OO-Entwicklungstechniken Erleichterung des Entwurfs beliebiger, komplexer Systeme Vorgehen: Nicht vorgeschrieben (UML ist nur Notation) Verwendung bekannter OO-Heuristiken 3(21)

4 Grundlagen - Entwicklungsgeschichte der UML Andere Methoden Booch 91 OMT-1 OOSE Fragmentierung Booch 93 OMT-2 OOPSLA 95 Unified Method 0.8 Unifizierung Juni 96, Oktober 96 UML 0.9 & 0.91 UML Partner Januar 97 UML 1.0 Herbst 97 UML 1.1 Standardisierung Juli 98 UML 1.2 Industrialisierung 4(21)

5 Grundlagen - Konzepte der UML Drei Dimensionen der Modellierung: Strukturelle Sicht Klassendiagramm Komponentendiagramm Funktionale Sicht Anwendungsfalldiagramm Aktivitätsdiagramm Verhaltenssicht Zustandsdiagramm Sequenzdiagramm Kollaborationsdiagramm 5(21)

6 Grundlagen - Werkzeug Werkzeug: Rhapsody, Version Hersteller: i-logix Basis: C++ Unterstützte UML - Diagramme: Anwendungsfalldiagramme ( Use Case Diagrams ) Klassendiagramme ( Object Model Diagrams ) Sequenzdiagramme ( Sequence Diagrams ) Zustandsdiagramme ( Statecharts ) 6(21)

7 Grundlagen - Werkzeug (2) Merkmale des Werkzeugs: Code-nahe Entwicklung Konsistenzcheck Codegenerierung Simulation mittels animierter Zustands- und Sequenzdiagramme 7(21)

8 Modellierung - Vorgehensweise Vorgehensweise: Unterteilung in Konzeptions- und Realisierungsphase Konzeptionsphase (ohne Werkzeug): Brainstorming Anwendungsfälle identifiziert Klassendiagramm aufgestellt Sequenzdiagramme zur Klärung von Abläufen 8(21)

9 Modellierung - Vorgehensweise (2) Konzeptionsphase Realisierungsphase Alle B-Anforderungen umgesetzt? nein ja Weiter mit Review Anwendungsfälle Klassendiagramm B-Anforderungen Inkrement festlegen Klassendiagramm erweitern/ anpassen ja nein Zustandsdiagramm erweitern/ anpassen Simulation des Inkrements Fehler? 9(21)

10 Modellierung - Arbeitsteilung Die Aufteilung der Anforderungen wird von Notation und Werkzeug unterstützt: Klassen als separate Verantwortungsbereiche Identifikation von Entwurfsinkrementen Versionsverwaltung mit Rhapsody möglich Dennoch keine Aufteilung der Seminargruppe: Werkzeug nur auf einem Rechner installiert Nur ein Gruppenmitglied hat Schulung erhalten Fehlervermeidung durch direkte Rückkopplung in der Gruppe 10(21)

11 Modellierung - Umfang der Spezifikation Umsetzung der Spezifikation: Alle Anforderungen wurden umgesetzt Vereinfachte Benutzungsschnittstelle Größe des Dokuments: 2 Klassendiagramme mit 20 Klassen 16 Zustandsdiagramme 5 Sequenzdiagramme Zeilen Code (generiert) 11(21)

12 Erfahrungen - Beurteilung der UML Erfahrungen: Große Diagrammvielfalt Leicht erlernbare Notation Für schrittweise verfeinerten Entwurf geeignet Unterstützung bei der Vorgehensweise fehlt Schwierigkeit bei der Festlegung der Klassen 12(21)

13 Erfahrungen - Beurteilung von Rhapsody Stärken: Intuitive Bedienbarkeit Automatischer Konsistenzcheck Animierte Simulation Einfache Fehlerlokalisierung Schwächen: Online-Hilfe und Dokumentation mangelhaft Keine Undo -Funktion Aktionen innerhalb von Zuständen nicht sichtbar 13(21)

14 Erfahrungen - Beurteilung von Rhapsody (2) Wünschenswerte Erweiterungen: Unterstützung weiterer UML-Diagrammtypen Simulator-Frontend Größere Compilerauswahl Verwendungsnachweis Verbessertes Drucken 14(21)

15 Erfahrungen - Review Vorgehensweise: Werkzeuggestütztes Review Bedienung des Werkzeugs durch jeweilige Expertengruppe Ohne Kenntnis der eigentlichen Notation Überdeckung der Spezifikation mit Benutzeranforderungen 15(21)

16 Erfahrungen - Review (2) Verständlichkeit: Rhapsody: Animierte Simulation erleichtert Verfolgbarkeit des Systemverhaltens Review auf Ausdruck kaum möglich SCR*: Überblick aufgrund Zwang zu umständlicher Modellierung schwierig Systemverhalten wegen Anzeigefehlern schlecht nachvollziehbar 16(21)

17 Erfahrungen - Review (3) Verfolgbarkeit: Rhapsody: Einige Anforderungen auf mehrere Zustandsdiagramme abgebildet Verwendungsnachweis wäre hilfreich SCR*: Spezifikation schlecht überprüfbar, da Variablen manuell zu setzen Variablenexplosion erschwert Verfolgbarkeit 17(21)

18 Erfahrungen - Typische Fehler Notation: Klasse Tamagotchi anfangs zu groß entworfen Szenarien zu spät eingesetzt Werkzeug: Multiplizität der Assoziationen vergessen Schwierigkeit bei der Reihenfolge der Konstruktoraufrufe Notwendige Includes vergessen 18(21)

19 Erfahrungen - Aufwand Einarbeitung: 40 Stunden Aufwand (zu gleichen Teilen für UML und Rhapsody) UML gut erlernbar, da auf bekanntem Konzept basierend Rhapsody schlecht dokumentiert, aber intuitiv bedienbar Modellierung des Tamagotchi: 230 Stunden Gesamtaufwand (Realisierung, Simulation und Review) Mehraufwand wegen unzureichend dokumentiertem Werkzeug Größter zeitlicher Anteil: Realisierung 19(21)

20 Fazit Einschätzung von UML: Identifizierung von Objekten entspricht der menschlichen Denkweise Schrittweise Entwicklung wird unterstützt Nebenläufiges Verhalten läßt sich gut beschreiben Einschätzung von Rhapsody: Übersichtliche Handhabung erleichtert Entwicklung Unterstützt Erstellung konsistenter Spezifikationen Code-nahes Arbeiten erfordert C++ -Kenntnisse Review auf ausgedruckten Diagrammen kaum möglich (fehlende Details) 20(21)

21 Literaturhinweise Objektorientierte Softwareentwicklung mit UML, Bernd Oestereich, Verlag Oldenbourg UML konzentriert, Martin Fowler u. Kendall Scott, Verlag Addison-Wesley-Longman Referenzwebsite: Adapting the Fusion Process to Support the UML, Colin Atkinson, Object Magazine, Sigs Publications, Nov (21)