Tamagotchi-Spezifikation in UML - Software and Systems Engineering
Transcription
Tamagotchi-Spezifikation in UML - Software and Systems Engineering
Fraunhofer Einrichtung Experimentelles Software Engineering IESE Christian Becker Steffen Glomb Michael Graf Tamagotchi-Spezifikation in UML F A C H B E R E I C H I N F O R M A T I K • U N I V E R S I T Ä T K A I S E R S L A U T E RN Notation Werkzeug Gliederung München, den 01.02.1999 Beurteilung von Notation und Werkzeug Review Typische Fehler Seminarvortrag von C. Becker, S. Glomb, M. Graf Fazit • • • Erfahrungen Details der Spezifikation Modellierung • • Grundlagen F A C H B E R E I C H I N F O R M A T I K • U N I V E R S I T Ä T K A I S E R S L A U T E RN Fraunhofer 2(21) Einrichtung Experimentelles Software Engineering IESE Seminarvortrag von C. Becker, S. Glomb, M. Graf München, den 01.02.1999 Verwendung bekannter OO-Heuristiken • Erleichterung des Entwurfs beliebiger, komplexer Systeme • Nicht vorgeschrieben (UML ist nur Notation) Vereinigung bestehender OO-Entwicklungstechniken • Ziel: • Rational, IBM, Microsoft, HP, Oracle u.a. Partner: Vorgehen: James Rumbaugh, Grady Booch, Ivar Jacobson u.a. Autoren: 3(21) Einrichtung Experimentelles Software Engineering UML (Unified Modeling Language), Version 1.1 Grundlagen - UML als Notation Fraunhofer IESE Notation: F A C H B E R E I C H I N F O R M A T I K • U N I V E R S I T Ä T K A I S E R S L A U T E RN OMT-2 OMT-1 OOSE München, den 01.02.1999 UML 1.2 UML Partner UML 1.1 UML 1.0 UML 0.9 & 0.91 Seminarvortrag von C. Becker, S. Glomb, M. Graf Juli ‘98 Herbst ‘97 Booch ‘93 Booch ‘91 Unified Method 0.8 Juni ‘96, Oktober ‘96 OOPSLA ‘95 Andere Methoden Januar ‘97 Fraunhofer Einrichtung Experimentelles Software Engineering IESE 4(21) Industrialisierung Standardisierung Unifizierung Fragmentierung Grundlagen - Entwicklungsgeschichte der UML F A C H B E R E I C H I N F O R M A T I K • U N I V E R S I T Ä T K A I S E R S L A U T E RN Grundlagen - Konzepte der UML Verhaltenssicht • Zustandsdiagramm • Sequenzdiagramm • Kollaborationsdiagramm • München, den 01.02.1999 Funktionale Sicht • Anwendungsfalldiagramm • Aktivitätsdiagramm • Seminarvortrag von C. Becker, S. Glomb, M. Graf Strukturelle Sicht • Klassendiagramm • Komponentendiagramm • Drei Dimensionen der Modellierung: F A C H B E R E I C H I N F O R M A T I K • U N I V E R S I T Ä T K A I S E R S L A U T E RN Fraunhofer 5(21) Einrichtung Experimentelles Software Engineering IESE i-Logix C++ Hersteller: Basis: Sequenzdiagramme („Sequence Diagrams“) Zustandsdiagramme („Statecharts“) • • München, den 01.02.1999 Klassendiagramme („Object Model Diagrams“) • Seminarvortrag von C. Becker, S. Glomb, M. Graf Anwendungsfalldiagramme („Use Case Diagrams“) Fraunhofer • Unterstützte UML - Diagramme: Rhapsody, Version 2.0.1 Grundlagen - Werkzeug Werkzeug: F A C H B E R E I C H I N F O R M A T I K • U N I V E R S I T Ä T K A I S E R S L A U T E RN 6(21) Einrichtung Experimentelles Software Engineering IESE Grundlagen - Werkzeug (2) Simulation mittels animierter Zustands- und Sequenzdiagramme • München, den 01.02.1999 Codegenerierung • Seminarvortrag von C. Becker, S. Glomb, M. Graf Konsistenzcheck • 7(21) Einrichtung Experimentelles Software Engineering Code-nahe Entwicklung Fraunhofer IESE • Merkmale des Werkzeugs: F A C H B E R E I C H I N F O R M A T I K • U N I V E R S I T Ä T K A I S E R S L A U T E RN Modellierung - Vorgehensweise Fraunhofer Klassendiagramm aufgestellt Sequenzdiagramme zur Klärung von Abläufen • • München, den 01.02.1999 Anwendungsfälle identifiziert • Seminarvortrag von C. Becker, S. Glomb, M. Graf Brainstorming • Konzeptionsphase (ohne Werkzeug): IESE 8(21) Einrichtung Experimentelles Software Engineering Vorgehensweise: Unterteilung in Konzeptions- und Realisierungsphase F A C H B E R E I C H I N F O R M A T I K • U N I V E R S I T Ä T K A I S E R S L A U T E RN Fraunhofer ja ja München, den 01.02.1999 Simulation des Inkrements Zustandsdiagramm erweitern/ anpassen Klassendiagramm erweitern/ anpassen Inkrement festlegen Seminarvortrag von C. Becker, S. Glomb, M. Graf Anwendungsfälle Klassendiagramm B-Anforderungen nein Alle B-Anforderungen umgesetzt? Realisierungsphase nein Fehler? 9(21) Einrichtung Experimentelles Software Engineering IESE Weiter mit Review Modellierung - Vorgehensweise (2) Konzeptionsphase F A C H B E R E I C H I N F O R M A T I K • U N I V E R S I T Ä T K A I S E R S L A U T E RN Modellierung - Arbeitsteilung Fraunhofer Identifikation von Entwurfsinkrementen Versionsverwaltung mit Rhapsody möglich • • Fehlervermeidung durch direkte Rückkopplung in der Gruppe • München, den 01.02.1999 Nur ein Gruppenmitglied hat Schulung erhalten • Seminarvortrag von C. Becker, S. Glomb, M. Graf Werkzeug nur auf einem Rechner installiert • Dennoch keine Aufteilung der Seminargruppe: Klassen als separate Verantwortungsbereiche • 10(21) Einrichtung Experimentelles Software Engineering IESE Die Aufteilung der Anforderungen wird von Notation und Werkzeug unterstützt: F A C H B E R E I C H I N F O R M A T I K • U N I V E R S I T Ä T K A I S E R S L A U T E RN Fraunhofer Modellierung - Umfang der Spezifikation Vereinfachte Benutzungsschnittstelle • 5 Sequenzdiagramme 16.000 Zeilen Code (generiert) • • München, den 01.02.1999 16 Zustandsdiagramme • Seminarvortrag von C. Becker, S. Glomb, M. Graf 2 Klassendiagramme mit 20 Klassen • Größe des Dokuments: Alle Anforderungen wurden umgesetzt • Umsetzung der Spezifikation: F A C H B E R E I C H I N F O R M A T I K • U N I V E R S I T Ä T K A I S E R S L A U T E RN 11(21) Einrichtung Experimentelles Software Engineering IESE Fraunhofer Für schrittweise verfeinerten Entwurf geeignet Unterstützung bei der Vorgehensweise fehlt Schwierigkeit bei der Festlegung der Klassen • • • München, den 01.02.1999 Leicht erlernbare Notation • Seminarvortrag von C. Becker, S. Glomb, M. Graf Große Diagrammvielfalt Erfahrungen - Beurteilung der UML • Erfahrungen: F A C H B E R E I C H I N F O R M A T I K • U N I V E R S I T Ä T K A I S E R S L A U T E RN 12(21) Einrichtung Experimentelles Software Engineering IESE Fraunhofer Intuitive Bedienbarkeit Automatischer Konsistenzcheck Animierte Simulation Einfache Fehlerlokalisierung • • • • Erfahrungen - Beurteilung von Rhapsody Aktionen innerhalb von Zuständen nicht sichtbar • München, den 01.02.1999 Keine „Undo“-Funktion • Seminarvortrag von C. Becker, S. Glomb, M. Graf Online-Hilfe und Dokumentation mangelhaft • Schwächen: Stärken: F A C H B E R E I C H I N F O R M A T I K • U N I V E R S I T Ä T K A I S E R S L A U T E RN 13(21) Einrichtung Experimentelles Software Engineering IESE Fraunhofer Größere Compilerauswahl Verwendungsnachweis Verbessertes Drucken • • • München, den 01.02.1999 Simulator-Frontend • Seminarvortrag von C. Becker, S. Glomb, M. Graf Unterstützung weiterer UML-Diagrammtypen • Wünschenswerte Erweiterungen: Erfahrungen - Beurteilung von Rhapsody (2) F A C H B E R E I C H I N F O R M A T I K • U N I V E R S I T Ä T K A I S E R S L A U T E RN 14(21) Einrichtung Experimentelles Software Engineering IESE Überdeckung der Spezifikation mit Benutzeranforderungen • München, den 01.02.1999 Ohne Kenntnis der eigentlichen Notation • Seminarvortrag von C. Becker, S. Glomb, M. Graf Bedienung des Werkzeugs durch jeweilige „Expertengruppe“ • 15(21) Einrichtung Experimentelles Software Engineering Werkzeuggestütztes Review Erfahrungen - Review Fraunhofer IESE • Vorgehensweise: F A C H B E R E I C H I N F O R M A T I K • U N I V E R S I T Ä T K A I S E R S L A U T E RN 16(21) Systemverhalten wegen Anzeigefehlern schlecht nachvollziehbar • München, den 01.02.1999 Überblick aufgrund Zwang zu umständlicher Modellierung schwierig • SCR*: Review auf Ausdruck kaum möglich • Einrichtung Experimentelles Software Engineering Animierte Simulation erleichtert Verfolgbarkeit des Systemverhaltens Fraunhofer IESE • Rhapsody: Erfahrungen - Review (2) Seminarvortrag von C. Becker, S. Glomb, M. Graf • • Verständlichkeit: F A C H B E R E I C H I N F O R M A T I K • U N I V E R S I T Ä T K A I S E R S L A U T E RN Variablenexplosion erschwert Verfolgbarkeit • München, den 01.02.1999 Spezifikation schlecht überprüfbar, da Variablen manuell zu setzen • SCR*: Verwendungsnachweis wäre hilfreich • 17(21) Einrichtung Experimentelles Software Engineering Einige Anforderungen auf mehrere Zustandsdiagramme abgebildet Fraunhofer IESE • Rhapsody: Erfahrungen - Review (3) Seminarvortrag von C. Becker, S. Glomb, M. Graf • • Verfolgbarkeit: F A C H B E R E I C H I N F O R M A T I K • U N I V E R S I T Ä T K A I S E R S L A U T E RN Klasse „Tamagotchi“ anfangs zu groß entworfen Szenarien zu spät eingesetzt • Erfahrungen - Typische Fehler • Notwendige Includes vergessen • München, den 01.02.1999 Schwierigkeit bei der Reihenfolge der Konstruktoraufrufe • Seminarvortrag von C. Becker, S. Glomb, M. Graf Multiplizität der Assoziationen vergessen Fraunhofer • Werkzeug: Notation: F A C H B E R E I C H I N F O R M A T I K • U N I V E R S I T Ä T K A I S E R S L A U T E RN 18(21) Einrichtung Experimentelles Software Engineering IESE Rhapsody schlecht dokumentiert, aber intuitiv bedienbar • Größter zeitlicher Anteil: Realisierung • München, den 01.02.1999 Mehraufwand wegen unzureichend dokumentiertem Werkzeug • Seminarvortrag von C. Becker, S. Glomb, M. Graf 230 Stunden Gesamtaufwand (Realisierung, Simulation und Review) • Modellierung des Tamagotchi: UML gut erlernbar, da auf bekanntem Konzept basierend • 19(21) Einrichtung Experimentelles Software Engineering 40 Stunden Aufwand (zu gleichen Teilen für UML und Rhapsody) Erfahrungen - Aufwand Fraunhofer IESE • Einarbeitung: F A C H B E R E I C H I N F O R M A T I K • U N I V E R S I T Ä T K A I S E R S L A U T E RN Nebenläufiges Verhalten läßt sich gut beschreiben • Review auf ausgedruckten Diagrammen kaum möglich (fehlende Details) • 20(21) Code-nahes Arbeiten erfordert C++ -Kenntnisse • München, den 01.02.1999 Unterstützt Erstellung konsistenter Spezifikationen • Seminarvortrag von C. Becker, S. Glomb, M. Graf Übersichtliche Handhabung erleichtert Entwicklung • Einschätzung von Rhapsody: Schrittweise Entwicklung wird unterstützt • Einrichtung Experimentelles Software Engineering Identifizierung von Objekten entspricht der menschlichen Denkweise Fazit Fraunhofer IESE • Einschätzung von UML: F A C H B E R E I C H I N F O R M A T I K • U N I V E R S I T Ä T K A I S E R S L A U T E RN Referenzwebsite: www.rational.com „Adapting the Fusion Process to Support the UML“, Colin Atkinson, Object Magazine, Sigs Publications, Nov. ‘97 • • München, den 01.02.1999 „UML konzentriert“, Martin Fowler u. Kendall Scott, Verlag Addison-Wesley-Longman • Seminarvortrag von C. Becker, S. Glomb, M. Graf „Objektorientierte Softwareentwicklung mit UML“, Bernd Oestereich, Verlag Oldenbourg Literaturhinweise Fraunhofer • F A C H B E R E I C H I N F O R M A T I K • U N I V E R S I T Ä T K A I S E R S L A U T E RN 21(21) Einrichtung Experimentelles Software Engineering IESE