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