© Till Hänisch, 2002 BA Heidenheim Objekte und UML "You can model 80 percent of most problems by using about 20 percent of the UML." -- Grady Booch But.

Präsentation zum Thema: "© Till Hänisch, 2002 BA Heidenheim Objekte und UML "You can model 80 percent of most problems by using about 20 percent of the UML." -- Grady Booch But."—  Präsentation transkript:

1 © Till Hänisch, 2002 BA Heidenheim Objekte und UML "You can model 80 percent of most problems by using about 20 percent of the UML." -- Grady Booch But which 20% was that again, please? More specifically, what parts of the UML do I need to get from use cases to code?

2 © Till Hänisch, 2002 BA Heidenheim Überblick Objekte Kendall Scott, An Introduction to the Unified Modeling Language (UML), http://www.iconixsw.com/umlzone.html UML ist "Sprache" zur Darstellung, keine Methode (Prozess) In der Vorlesung: Kein realer Prozess, aber ähnlich (vereinfacht) ICONIX (http://www.iconixsw.com) UML in der Analyse, am wichtigsten –Use cases –Klassen (-diagramme) –Zustandsdiagramm User Interface Beispiele Konzepte ausserhalb der UML

3 © Till Hänisch, 2002 BA Heidenheim Objekte Objekt –"wichtiger" Gegenstand –Dinge (Fahrrad, Büro) –Personen (Kunde, Mitarbeiter) –Begriffe (Programmiersprache, Krankheit) –Abstraktion (Modell !!) von realen "Objekten" Eigenschaften –befindet sich immer in einem bestimmten Zustand Zustand == Werte der Attribute –Attribute (deren aktuelle Werte) –Operationen –Attributwerte (=Zustand) kann nur durch Operationen geändert werden –Identität zwei Objekte können unterschieden werden, auch wenn die Werte aller Attribute gleich sind

4 © Till Hänisch, 2002 BA Heidenheim Objektidentität

5 © Till Hänisch, 2002 BA Heidenheim Objekte contd. Externe/Interne Objekte –Externe Objekte existieren real –Interne Objekte im (Software-) System –z.B. Kunde "Müller" (extern) erteilt Auftrag für das interne Kunde-Objekt sind nur manche Eigenschaften des externen Objekts (Name, Adresse, Zahlungsfähigkeit) von Interesse, andere nicht (Haarfarbe, Hobbies) --> Modellbildung Klasse –Menge von Objekten mit gleichen Attributen und Operationen –Jedes Objekt gehört zu (genau) einer Klasse –Gegensatz zu (den meisten) Programmiersprachen: Klasse ist "Schablone" für Objekte (Henne Ei Problem) –bei Analyse Vereinfachung: Klasse kennt ihre Objekte, kann Objekte erzeugen, löschen, suchen,... –Name muss (innerhalb eines Pakets) eindeutig sein (Paket::Klasse) Substantiv (im Singular) –Klassendiagramm: statische Beziehungen zwischen Klassen

6 © Till Hänisch, 2002 BA Heidenheim Klassendiagramm Assoziation zwischden Auto und Rad ist Komposition, Alternative: Aggregation, Darstellung "ungefüllt" Unterschied: Komponenten der Aggregation können auch selbstständig existieren, Teile der Komposition nicht (für Analyse eher irrelevant) Generalisierung hat keine Kardinalität !

7 © Till Hänisch, 2002 BA Heidenheim Stereotypen Klassen (andere Modellelemente auch) können durch Stereotypen näher qualifiziert werden, z.B. >, >, >, >, >,....

8 © Till Hänisch, 2002 BA Heidenheim Use cases Actor Klasse mit Stereotyp > Use case Beziehungen zwischen Use cases können sein >, >

9 © Till Hänisch, 2002 BA Heidenheim Use cases contd. Beschreibt die Interaktion des Anwenders mit dem System Use case ist ein "wichtiger" Vorgang, der durch einen Anwender ("Actor") ausgelöst wird, besteht aus mehreren, zusammenhängenden Aufgaben, die vom Anwender ausgeführt werden, um ein Ziel zu erreichen –1-100 Use cases pro System Anwender löst use case aus –Gegensatz zu functional requirements ! (Zur Darstellung der requirements, der Inhalt ist der gleiche, nur die Perspektive ist anders) "Use cases are simple in structure, but preparing them correctly is difficult" [Kulak00] Use cases sind (sehr) nützlich –sind sich alle einig –Darstellung in UML akzeptiert Beschreibung von Use cases als Text, ggf. mit Vorlage –kein Standard

10 © Till Hänisch, 2002 BA Heidenheim Beschreibung von Use cases Minimal –Name 2-3 Wörter, soll grob den Zweck verdeutlichen –Ziel Ergebnis (für den Actor) –Zusammenfassung (nicht allg. akzeptiert, aber sinnvoll, taucht manchmal als "rationale" in Texten auf) –beteiligte Akteure –Ablauf "häufigster" Ablauf, bei Erfolg Alternativen Fehlersituationen –evtl. Vor- und Nachbedingungen Plausibilität der Reihenfolge,...

11 © Till Hänisch, 2002 BA Heidenheim Top ten use case mistakes Don't write functional requirements instead of usage scenario text Don't describe attributes and methods rather than usage Don't write the use cases too tersely Don't divorce yourself completely from the user interface Don't avoid explicit names for your boundary objects Don't write in the passive voice, using a perspective other than the user's Don't describe only user interactions; ignore system responses Don't omit text for alternative courses of action Don't focus on something other than what is "inside" a use case Don't spend a month deciding whether to use includes or extends Aus Rosenberg, Scott, Applying use case driven object modeling with UML, Addison Wesley 2001

12 © Till Hänisch, 2002 BA Heidenheim Wie kommt man zu den Use cases ? Szenarien –konkrete Beispiele (Herr Müller bestellt 3 Schrauben,...) –Basis für Use cases (Abstraktion über den Einzelfall) und Test Alles auf einmal (Ablauf, Alternativen, Fehler,..) ? besser mehrere Phasen [Kulak00] –Facade (Actors, Use cases finden, Name und Zusammenfassung) –Filled (Ablauf, Alternativen, non-functional requirements, Test mit Szenarien) –Focused (Priorisierung, Gruppierung (extends,... Packages), Überprüfung auf z.B. Schnittstellen) –Finished (User interface requirements, baselining, review) Analogie zu RUP –Inception –Elaboration –Construction –Transition

13 © Till Hänisch, 2002 BA Heidenheim Zustandsdiagramme (State chart) Zustandsautomat (Finite State Machine FSM) besteht aus –Zuständen: Zeitspanne, in der ein Objekt auf ein Ereignis wartet –Übergängen: instantaner Wechsel zwischen zwei Zuständen, wird durch ein Ereignis ausgelöst Objekt befindet sich zu jedem Zeitpunkt in genau einem Zustand Tritt in einem Zustand ein Ereignis ein, hängt der nächste Zustand (nur) vom vorherigen Zustand und dem Ereignis ab Ein Anfangs- und Endzustand

14 © Till Hänisch, 2002 BA Heidenheim Zustandsdiagramm Beispiel

15 © Till Hänisch, 2002 BA Heidenheim User Interface UML bietet (direkt) keine Möglichkeit zur Darstellung der Benutzeroberfläche (insb. der Dynamik). Prinzipiell möglich aber unübersichtlich: Klassendiagramm (UI Element als Klasse/Objekt), Navigationswege als Assoziationen, Dynamik in Sequenzdiagrammen Alternative: (nicht UML) Window Navigation Diagram [Rosenberg00]