Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr....
Transcript of Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr....
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 1
1. Motivation
Objektorientierte Analyse und Design
Einige Folien dieser Vorlesung entstammen Präsentationen von A. del Pino, U. Andelfinger, B. Humm, G. Raffius
SS 2014
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 2
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3
Planspiel
Stellen Sie sich vor, Sie sollen Software entwickeln
für ein Projekt, dessen Fachgebiet Sie nicht kennen
(z. B. ein Verwaltungssystem für ein Krankenhaus)
Randbedingungen
der Kunde kennt sich nicht mit IT aus
die Aufgabe ist nicht ganz trivial
die Software hat eine Wartungsverpflichtung von 10 Jahren
1. Motivation
Wie würden Sie vorgehen?
Welche Arbeitsergebnisse würden Sie anstreben?
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 4
Grundidee OOAD
Problem: Wie entwickle ich ein komplexes System?
Analysiere die reale Welt
Abstrahiere daraus ein Modell mit den
wesentlichen Daten und Klassen (Objekten)
und deren Beziehungen zueinander
Entwerfe ein detailliertes Modell, das
auf dem abstrakten Modell basiert
Setze das Ergebnis um Arzt.cpp
1. Motivation
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 5
Abstraktionsebenen
Abstraktionsebenen der objektorientierten Systementwicklung (4-Schichten-Modell)
Arzt.cpp
Reale Welt
OOA-Ebene
OOD-Ebene
Programm
Abstraktion
Codierung
Implementierungs-konzepte
gedankliche Ebene
logische Ebene (Modell)
physische Ebene (Implementierungsebene)
1. Motivation
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 6
Phasenmodell der objektorientierten Systementwicklung
Informations-gehalt
Entwicklungs-phase
OOP (Programmierung)
OOD (Design)
OOA (Analyse)
reale Welt
Analyse-Modell
Design-Modell
Coderahmen
Abstraktion
Konkretisierung
Abbildung
Isomorphismus
Code
Konsistenz
1. Motivation
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 7
Phasen und Tätigkeiten (I)
OOA: Objektorientierte Analyse
Ziele:
- Anforderungen an das zu entwickelnde Softwaresystem erfassen und beschreiben
- ein gemeinsames Verständnis der Produktidee bei Auftraggeber, Auftragnehmer,
Benutzer und Entwicklern schaffen
Tätigkeiten:
- Herausarbeiten der wesentlichen Sachverhalte, Vernachlässigen von Details
- Dokumentation von Anwendungsfällen (Szenarien)
- Dokumentation der Systemidee, der Leistungsmerkmale, der Rahmenbedingungen
und Voraussetzungen
- Entwicklung eines objektorientierten Analysemodells
(„OOA-Modell“, „Domänenmodell“)
Umsetzung
- als Text und/oder als Modell
- weitgehend unabhängig von der späteren konkreten Umsetzung
- Modellierung oft mit Elementen der Unified Modeling Language (UML)
1. Motivation
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 8
Phasen und Tätigkeiten (II)
OOD: Objektorientiertes Design
Ziele:
- Erarbeitung eines Lösungskonzepts zu einem gegebenen Problem oder gegebenen Anforderungen (vgl. OOA)
- Dokumentation des Konzept als Vorarbeit für die Implementierung
Tätigkeiten:
- das in der OOA erstellte Analysemodell wird kontinuierlich weiterentwickelt und darauf aufbauend ein objektorientiertes Designmodell („Architektur/Design“) erstellt
- Festlegung von Verantwortlichkeiten, Schnittstellen, Implementierungsvorgaben
- Dokumentation von Klassen, Objekten, Komponenten (u. v. m.) und deren Interaktion
Umsetzung
- Modellierung in der Regel mit Elementen der Unified Modeling Language (UML)
- Das Designmodell berücksichtigt neben den fachlichen Aspekten des Auftraggebers auch technische Gegebenheiten (Betriebssystem, Zielsprache etc.)
OOP: Objektorientierte Programmierung
Umsetzung des OOD-Modells in ein objektorientiertes Computerprogramm
1. Motivation
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 9
Modelle und Inhalte
Detaillierte Beschreibung von
Klassen, Operationen,
Attributen in der Zielsprache
Code
Analyse-Modell
Design-Modell
Forward Engineering
Reverse Engineering
Round-trip Engineering
Case-Tool macht den
Abgleich zwischen
Designmodell und Code
Beschreibung der
wesentlichen Klassen mit
Verantwortlichkeit & Attributen
unabhängig vom Zielsystem
Konkretisierung Ergänzung um
Umsetzungsdetails
1. Motivation
Komponenten mit
Verantwortlichkeit & Schnittstellen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 10
Inhalte der Vorlesungen zur Softwaretechnik
OO: Grundlagen der Objektorientierung
OOAD: Analyse und Design
UML:
einheitliche und präzise „Sprache“ zur Dokumentation
Modellierung und Darstellung
Inhalt und Einsatz der diversen Diagramme
OOAD
SWE
Projekt- mgmt
1. Motivation
Entwicklung: Entstehung der Softwaretechnik
Vorgehen Techniken zum Vorgehen in Projekten
Prozesse allgemeine und systematische Vorgehensmöglichkeiten
Qualität Beurteilung der Arbeitsergebnisse
Planung Arbeiten mit Plänen und Ressourcen
Organisation Aufbau von Teams
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 11
Konzept von Praktikum und Vorlesung zur Softwaretechnik
OOAD
Objektorientierung
Analyse und Design
Dokumentation der Arbeit
- UML
„Handwerkszeug“ für SW-Entwickler
- Gutes Design
SWE
Gesamtkonzept/Zusammenhänge
- Arbeit in großen Projekten
- Anwendung des Handwerkszeugs
- Qualitätssicherung
- Organisation
Praktikum OOAD
Umgang mit dem Handwerkszeug
- Erste Modellierung
- „Entwickeln“ eines Mini-Projekts
- Arbeit mit der UML
- Kennenlernen des CASE-Tools
- Kennenlernen der
Entwicklungsumgebung
Praktikum SWE
Anwendung der Verfahren aus
OOAD und SWE
Entwicklung eines Systems in kleinen
Teams
Möglichst hohe Realitätsnähe
- Eigenständige Lösung der Aufgaben
- Überprüfung durch Reviews
- Aufteilung der Arbeiten im Team
1. Motivation
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 12
Themen in OOAD im Detail
OOAD
1. Motivation
2. Grundkonzepte der Objektorientierung
3. Objektorientierte Software-Entwicklung
4. Objektorientierte Analyse
- Use Cases
- Aktivitätsdiagramme
- Analysemodell
5. Objektorientiertes Design
- Darstellung der Statik eines Systems (Klassendiagramm)
- Umsetzung von Klassen in C++
- Darstellung der Dynamik eines Systems (Sequenz-, Zustandsdiagramme)
- Weitere Diagramme in der UML
6. Welches Design ist das Richtige?
1. Motivation
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 13
Lernziele der Veranstaltung OOAD
Sie beherrschen die Grundprinzipien der Objektorientierung
Sie können Anforderungen an ein zu entwickelnde Softwaresystem erfassen und
beschreiben
Sie beherrschen die UML als Standard zur Darstellung der (meisten) Ergebnisse
Sie können die Statik eines Systems in Diagrammen darstellen
Sie können die Dynamik eines Systems in Diagrammen darstellen
Sie können ein adäquates Lösungskonzept zu einem gegebenen Problem
erarbeiten
1. Motivation
Sie beherrschen das Handwerkszeug
zur Mitarbeit in einem modernen Projekt!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 14
Literatur
Mario Winter: Methodische objektorientierte Software-Entwicklung dpunkt-Verlag, 2005
Rupp, die SOPHISTen, Queins: UML2 glasklar; 4. Auflage Hanser-Verlag, 2012
Chonoles, Schardt: UML2 für Dummies Wiley-VCH, 2003
Brett D. McLaughlin, G. Pollice, D. West:
Objektorientierte Analyse & Design von Kopf bis Fuß
O'REILLY, 2007
1. Motivation
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 15
2. Grundkonzepte der Objektorientierung
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 16
Historie
„Erfinder“ der objektorientierten SW-Entwicklung
Prof. Dr. e. h. Kristen Nygaard
(1926–2002), Oslo, Norwegen
Department of Informatics
University of Oslo
- Erfinder der Programmiersprache SIMULA 67,
die das Klassenkonzept in die Programmiersprachenwelt einführte
(zusammen mit Ole-Johan Dahl)
- Erfinder der objektorientierten Programmiersprache BETA
(zusammen mit B. B. Kristensen, O. L. Madsen, B. Møller-Pedersen).
Bertrand Meyer, Programmiersprache Eiffel, 1988; kurz danach auch C++
2. Grundkonzepte der Objektorientierung
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 17
Objektorientierung (OO)
OO ist ein Ansatz zur Entwicklung von Software
vorhergehende Ansätze betrachteten Daten und Operationen darauf unabhängig
voneinander
nun werden die zu verarbeitenden Daten anhand ihrer Eigenschaften und der
möglichen Operationen klassifiziert und gruppiert
- Teile die zu beschreibende „Welt“ in Objekte mit Eigenschaften und Operationen auf
- das Zusammenspiel der Objekte erfolgt über Kommunikation untereinander
Anspruch, die „reale Welt“ besser nachbilden zu können
Umsetzung durch unterstützende Konzepte
Klassen
Vererbung
...
Objektorientierung ist seit den 90-ern das zentrale Programmierparadigma
2. Grundkonzepte der Objektorientierung
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 18
Grundidee Objektorientierung
Problem: Wie entwickle ich ein komplexes System?
Analysiere die Welt der Anwendung
bestimme Objekte die darin vorkommen
Entwickle die Anwendung basierend auf den
wesentlichen Daten und Klassen (Objekten)
und deren Beziehungen zueinander
Arzt.cpp
2. Grundkonzepte der Objektorientierung
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 19
Die Herausforderung
Objektorientierung an sich ist einfach.
Betrachte (und definiere) Dinge in der Welt der Anwendung und extrahiere die
wesentlichen Teile ( Objekte/Attribute/Klassen)
Untersuche das Zusammenspiel (die Kommunikation) der einzelnen Objekte
( Operationen)
Betrachte die Welt aus der Sicht eines einzelnen Objekts
Gehe davon aus, dass die anderen Objekte schon alles richtig machen
spiele iterativ die Anwendungsfälle durch, bis das skizzierte System die
gewünschte Leistung erbringen kann
2. Grundkonzepte der Objektorientierung
Bildquelle: Wikipedia
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 20
Objekte
Haben Attribute
Bieten Operationen an
2. Grundkonzepte der Objektorientierung
:Einfamilienhaus
Haustyp = Landhaus
Besitzer = Dr. Kaiser
Adresse = Königstein
Wohnfläche = 400 [qm]
Anzahl Bäder = 3
Hat Schwimmbad = ja
Garten = 5000 [qm]
Baujahr = 1976
Verkaufspreis = 2 Mio. [€]
anfragenVerkaufspreis
:Einfamilienhaus
Haustyp = Bungalow
Besitzer = Herzog
Adresse = Stiepel
Wohnfläche = 250 [qm]
Anzahl Bäder = 2
Hat Schwimmbad = nein
Garten = 1500 [qm]
Baujahr = 1986
Verkaufspreis = 1,5 Mio. [€]
anfragenVerkaufspreis
:Einfamilienhaus
Haustyp = Stadthaus
Besitzer = Urban
Adresse = Bochum
Wohnfläche = 200 [qm]
Anzahl Bäder = 2
Hat Schwimmbad = nein
Garten = 400 [qm]
Baujahr = 1990
Verkaufspreis = 1 Mio. [€]
anfragenVerkaufspreis
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 21
Abstraktion für Objekte
Trenne Konzept
und Umsetzung (Abstraktion)
Je nach Anwendung sind
unterschiedliche Abstraktionen
sinnvoll
(je nachdem was für die Anwendung
wesentlich ist
z. B. Makler, Architekt, Katasteramt, ...)
Eine Klasse definiert die (gemeinsamen) ...
Attribute ihrer Objekte
Operationen ihrer Objekte
Objekte werden oft auch
„Instanzen“ einer Klasse genannt
2. Grundkonzepte der Objektorientierung
Einfamilienhaus
Haustyp
Besitzer
Adresse
Wohnfläche
Anzahl Bäder
Hat Schwimmbad
Garten
Baujahr
Verkaufspreis
anfragenVerkaufspreis
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 22
Mitarbeiter-Objek t Mitarbeiter-Objek t
ändern Name
ändern Geh alt
ändern Name
ändern Gehalt
Nam e
Gehalt
Name
Geh alt
Von Objekten zu Klassen ...
Klasse als Schablone
2. Grundkonzepte der Objektorientierung
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 23
Kapselung
Da Objekte nur noch über Methoden
interagieren, kann das Innenleben
der Objekte und Klassen verborgen
werden
Eine Klasse „kapselt“
Attribute und Operationen
Zugriff auf die Daten erfolgt
nur über die Operationen
Die interne Realisierung ist
von außen nicht sichtbar
Operation 1
Operation 2
AuswahleinerOperation
Objekt
Daten
Botschaft
2. Grundkonzepte der Objektorientierung
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 24
Kapselung und Klassen – ein Beispiel
Aufgabe: Entwerfe eine Klasse für die Verwaltung von Personen
Name und Geschlecht sollen erfasst werden
Das Alter soll später ausgegeben werden können
2. Grundkonzepte der Objektorientierung
Attribute
- Name
- Gender
- DateOfBirth
Operationen
- SetName() und GetName();
- SetGender() und GetGender();
- SetDateOfBirth() und GetDateOfBirth();
- GetAge();
Operationen können mehr leisten als nur Attribute zurückliefern!
Berechnungen durchführen (z. B. das Alter aus Datum und Geb.datum berechnen)
Gültigkeitsprüfungen machen (z. B. bei SetDateOfBirth)
Automatische Ergänzungen (z. B. in SetName Gender nach Vornamen vorbelegen)
...
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 25
Wiederverwendung
Klassen verbergen die Realisierung und bieten zum Objekt passende
Schnittstellen
Klassen können in verschiedenen Kontexten eingesetzt werden
Klassen fördern die (systematische) Wiederverwendung
2. Grundkonzepte der Objektorientierung
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 26
Beziehungen (Assoziationen)
Objekte (bzw. Klassen)
stehen oft untereinander in Beziehung (z. B. ein Haus wird von einer Person bewohnt)
bestehen oft aus mehreren anderen Objekten – „Aggregation“ (ein Auto besteht aus Reifen, Karosserie,... )
Konkretisieren die Eigenschaften einer anderen Klasse – „Spezialisierung“ (bei Programmierung „Vererbung“); invers: „Generalisierung“ (Ein LKW ist ein spezielles Kfz; ein Kfz ist eine Verallgemeinerung von PKW und LKW)
können als Hierarchie dargestellt werden – „Generalisierungshierarchie“ bzw. „Vererbungshierarchie“ (Ein Cabrio ist ein spezieller Pkw und ein Pkw ist ein spezielles Kfz)
2. Grundkonzepte der Objektorientierung
ausführlich im Kapitel UML…
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 27
Polymorphismus
Vielgestaltigkeit
Konzept der Programmierung, das es erlaubt, einem Wert oder einer Variablen
mehrere Datentypen zuzuordnen
gleiche Operation anwendbar auf unterschiedliche Objekte
innerhalb einer Vererbungshierarchie oder
gleiche Operation anwendbar auf Objekte mit einem Datentyp, der als Parameter
übergeben wird („Template“)
Vorteile:
Vermeidung von typbasierten Fallunterscheidungen bzw. Casts
konkrete Umsetzung erfolgt über Compiler bzw. Linker
erleichtert die Benutzung von Klassen
2. Grundkonzepte der Objektorientierung kennen Sie evtl. von generischen Daten-strukturen (Stack, Vector, Queue, etc.)
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 28
Prinzipien der Objektorientierung: Zusammenfassung
Sie kennen jetzt
Objekte
Klassen
Attribute
Operationen/Methoden
Abstraktion
Kapselung
Spezialisierung bzw. Generalisierung
Polymorphismus
2. Grundkonzepte der Objektorientierung
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 29
3. Objektorientierte Software-Entwicklung
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 30
Lernziele
Sie sollen in diesem Kapitel verstehen,
wie die objektorientierte Entwicklungsmethode mit den traditionellen
Entwicklungsmethoden zusammenhängen
welche Vorteile die neuen Entwicklungsmethoden bieten
welche Nachteile dadurch überwunden werden
wie es zur Entstehung der UML kam und was sie beinhaltet
welche Unterstützung Werkzeuge bei der objektorientierten SW-Entwicklung
bieten
Hinterher ahnen Sie, warum man in professionellen Projekten so entwickelt!
3. Objektorientierte SW-Entwicklung
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 31
class CSpeicher {
private:
double mStack[255]; public:
CSpeicher(void); public:
void push(double p); public:
bool pop(double &p); public:
void clear(); public:
double readTop(); public:
void dump(); };
class CTaschenrechner { private:
CSpeicher m_cSpeicher; private:
CEinAusgabe m_cEinAusgabe; private:
CProzessor m_cProzessor; public:
CTaschenrechner(void); public:
void benutze();
};
Klassen wie Sie es bisher kennen
Sie kennen C++-Klassen aus Programmieren 1
mit C++ Header:
3. Objektorientierte SW-Entwicklung: Einleitung
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 32
Bewertung der C++ Darstellung (I)
Nachteile
Verweise auf andere Klassen sind als Pointer oder Klassenobjekte in der
Klassendefinition zwischen lokalen Variablen etc. „versteckt“
viele Details sind im Code (.cpp) versteckt
bei komplexen Aufgaben geht der Überblick schnell verloren
Einarbeitung in fremden Code ist schwierig
Idee
Stelle die Inhalte übersichtlich dar
Trenne in der Darstellung die Beziehungen zwischen Klassen von lokalen Daten
Umsetzung
UML bietet solche Darstellungsmöglichkeiten
3. Objektorientierte SW-Entwicklung: Einleitung
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 33
Klassen etwas anders (Design-Klassendiagramm)
„besteht aus“
„kennt“
3. Objektorientierte SW-Entwicklung: Einleitung
CTaschenrechner
-m_cSpeicher: CSpeicher
-m_cEinAusgabe: CEinAusgabe
-m_cProzessor: CProzessor
+CTaschenrechner()
+benutze()
CSpeicher
-tip: int
-mStack : double [255]
+CSpeicher()
+push( p: double)
+pop(p: double): boolean
+clear()
+readTop(): double
+dump()
CProzessor
-m_cSpeicher: CSpeicher
+berechne(c: char, p1: double, p2: double ) : double
CEinAusgabe
-txt: char [255]
-name: string
+read( c : char, d : double ) : int
UML-Syntax für Attribute attributname [ : attributtyp [ = initialwert ] ] UML-Syntax für Methoden methodenname [( parametername [ : parametertyp] [, ...] )] [ : rückgabetyp]
verallgemeinerte Datentypen
Diese Attribute realisieren Beziehungen (und können
ausgeblendet werden)
Klassen noch mal anders (Analyse-Klassendiagramm)
Im Analyse-Klassendiagramm wird beschrieben
welche Elemente (Klassen) es geben soll,
welche Eigenschaften (Attribute) sie haben und
wie sie interagieren (Beziehungen)
Die konkrete Umsetzung (Datentypen und Methoden) ist noch uninteressant
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 34
3. Objektorientierte SW-Entwicklung: Einleitung
CTaschenrechner
CSpeicher
-top
-stack
CProzessor CEinAusgabe
-text
Beziehungen
Klassen oft ohne Datentypen und
Methoden
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 35
Bewertung der Darstellung als UML-Klassendiagramm
Vorteile
übersichtliche Darstellung
leicht verständlich
Beziehung sind explizit dargestellt
unabhängig von der Programmiersprache
Modellierung auf hoher Abstraktionsebene – auch mit Konstrukten, welche die
Zielsprache evtl. nicht bietet
Code-Rahmen können (für verschiedene Sprachen) generiert werden
Nachteile
für Anfänger oft verwirrend
Syntax der UML muss erlernt werden (oder im Tool beachtet werden)
Spezielle Konstrukte von Programmiersprachen (z. B. Pointer in C++) müssen
besonders dargestellt werden
Umsetzung
UML bietet diese - und noch viele weitere - Darstellungsmöglichkeiten
...wenn man sich dran gewöhnt hat
3. Objektorientierte SW-Entwicklung: Einleitung
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 36
Und nun das Ganze andersrum
In einem „grüne Wiese-Projekt“
werden zuerst die Anforderungen
erarbeitet und darauf basierend der
Entwurf und der Code erstellt
das ist schön anschaulich
Im „echten Leben“ gibt es das aber
nur selten
Es gibt viele Projekte, in denen das
prinzipielle Vorgehen vom Code hin
zum Analyse-Modell geht
(Aufarbeitung von Altanwendung)
Die Anforderungen und Modelle
werden aus dem Code
rekonstruiert
Der Übergang vom Design- zum
Analysemodell erfolgt manuell
3. Objektorientierte SW-Entwicklung: Einleitung
Code
Analyse-Modell
Design-Modell
Round-trip Engineering
Konkretisierung
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 37
3.1 Objektorientierte SW-Entwicklung: UML
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 38
Die Entstehungsgeschichte der UML
Quelle und Literaturhinweis: http://www.uml.org
3.1 Objektorientierte SW-Entwicklung: UML
MOSES
Henderson-Sellers; 1994
OBA
Rubin; 1992
OML
Firesmith, Henderson-
Sellers, Page-Jones; 1998
SOMA
Graham; 1994
SCOOP
Cherry; 1990
HOOD
ESA; 1990
OBA
Bailin; 1989
OMT
Rumbaugh, et. al.; 1991
OOA
Coad, Yourdan; 1991
State Charts
Harel; 1987
OOSA
Shlear, Mellor; 1991
OOAD&I
Henderson-Sellers,
Macrone; 1992
RDD
Wirfs-Brock; 1990
OOSE
Jacobson; 1992
OSA
Embley; 1991
BON
Nerson; 1992
OOA&D
Martin, Odell; 1992
Fusion
Coleman, et. al.; 1994
Catalysis
D´Souza, Willes; 1996 Unified Method
Booch, Rumbaugh; 1995
Unified Modeling Language v1.0
Booch, Jacobson, Rumbaugh;
1997
OOD
Booch; 1992
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 39
UML als Vorgehensmodell?
Es existier(t)en verschiedene objektorientierte Methoden
Am bekanntesten: OMT: Object Modelling Technique (James Rumbaugh)
Kein Vorgehensmodell! „Nur“ Sammlung von Beschreibungsmitteln.
OMT: Object Modelling Technique v. Rumbaugh,...
OOD: Object Oriented Design v. Booch
OOSE: Object Oriented Software-Eng. v. Jacobson
OOA: Object Oriented Analysis v. Coach/Yourdon
OSA: Object Oriented System Analysis v. Shlaer/Mellor
Rumbaugh, Booch, Jacobson, Firma Rational. Standardisierungsvorschlag bei OMG eingereicht: 1997
3.1 Objektorientierte SW-Entwicklung: UML
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 40
UML Inhalte
Die UML eignet sich zur durchgängigen (OO)-Modellierung
vom Entwurf bis zur Implementierung:
3.1 Objektorientierte SW-Entwicklung: UML
Struktur-Diagramme
1. Klassendiagramm
2. Objektdiagramm
3. Komponentendiagramm
4. Paketdiagramm
5. Verteilungsdiagramm
6. Kompositionsstrukturdiagramm
7. Profildiagramm
Verhaltens-Diagramme
8. Use-Case-Diagramm
9. Zustandsautomat
10. Aktivitätsdiagramm
Interaktionsdiagramme
11. Sequenzdiagramm
12. Kommunikationsdiagramm
13. Zeitverlaufsdiagramm
14. Interaktionsübersichtsdiagramm
Statische Aspekte Dynamische Aspekte
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 41
Quellen zur UML
OOSE: http://www.oose.de
Übersetzungstabelle Deutsch – English
UML-Notationsübersicht
Glossar
und vieles mehr…
OMG (Object Management Group): http://www.uml.org
Offizielle Spezifikation
und vieles mehr...
3.1 Objektorientierte SW-Entwicklung: UML
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 42
3.2 Werkzeuge zur objektorientierten SW-Entwicklung
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 43
Werkzeuge für die objektorientierte Entwicklung
lange Zeit nur Werkzeuge für spezifische Teile der Entwicklung verfügbar
Editoren
Programmierumgebungen
Analysetools
Designtools
Seit einigen Jahren „CASE-Tools“, die den gesamten SW-Lebenszyklus
unterstützen
z. B. MagicDraw, Innovator, Eclipse, Rational Rose, Visual Studio .Net, …
Generieren Designmodell aus Code („Reverse Engineering“)
Generieren Code(rahmen) aus Designmodell („Forward Engineering“)
Zusammen „Round-Trip-Engineering“
Unterstützen die UML
Unterstützen Arbeit in großen Projekten und Teams
Leider meist proprietär! kein echter Im-/Export
3.2 Objektorientierte SW-Entwicklung: Werkzeuge
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 44
Warum sind diese Tools so kompliziert?
Entwicklung in mehreren Teams an mehreren Standorten
Schutz gegen gleichzeitiges Ändern an einem Modul: „Sperren (Locking)“
Sicherung von Zwischenständen: „Versionsverwaltung“
Verbergen von Zwischenständen vor anderen: „Freigabe“-Mechanismen
Ergänzen von „Namespaces“ zum Schutz vor gleichen Variablennamen
Auslieferung von mehreren Releases
Wiederherstellung von Zwischenständen (Releases) z. B. zum Bug-Tracking:
erfordert Anbindung an „Konfigurationsmanagement“
Pflege der Abhängigkeiten zwischen Modellen und Code
Änderungen werden automatisch nachgezogen: „Round-Trip-Engineering“
Arbeit mit sehr vielen Informationen
Darstellung ausgewählter Teilinformationen: „Sichten und verschiedene
Diagramme“
3.2 Objektorientierte SW-Entwicklung: Werkzeuge
Viele Dinge sind in großen Projekten einfach kompliziert –
und deshalb auch die Verwendung dieser Tools!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 45
Überblick Objektorientierte Programmiersprachen
C++
Bjarne Stroustrup (1986)
Ziel: Erweiterung von C um Objektorientierung
Viele Bibliotheken und Klassen verfügbar
Pointer
Speicherplatzverwaltung in Eigen-Regie
3.2 Objektorientierte SW-Entwicklung: Werkzeuge
Performanz statt Entwicklungskomfort
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 46
Überblick Objektorientierte Programmiersprachen
Java
SUN Microsystems (1995)
Ziel: Plattformunabhängigkeit (Java Virtual Machine)
Keine (fehlerträchtigen) Pointer
Komponententechnik integriert
Viele Bibliotheken und Klassen verfügbar
Einsatz im Web-Umfeld
Automatische Speicherverwaltung
Rechnerleistung wird vorausgesetzt
3.2 Objektorientierte SW-Entwicklung: Werkzeuge
Entwicklungskomfort statt Performanz
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 47
Überblick Objektorientierte Programmiersprachen
C#
Microsoft (2001?)
Ziel: Kombination der Vorteile von C++ & Java
keine Header, keine Makros
Compilierung des Codes in eine Zwischensprache
Ausführung in der proprietären .NET-Laufzeitumgebung
3.2 Objektorientierte SW-Entwicklung: Werkzeuge
Entwicklungskomfort und Performanz (?)
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 48
Kontrollfragen
Warum verwendet man in der UML eine spezielle Syntax zum spezifizieren von
Attributen und Methoden?
Wodurch unterscheidet sich das Analysemodell vom Designmodell?
Was ist Polymorphismus?
Was ist Kapselung?
Ist jedes C++-Programm auch objektorientiert?
Kann man auch in Assembler objektorientiert entwickeln?
In welchem Zusammenhang stehen Code und Designmodell?
Warum kam es zur Entstehung der UML?
Ist die UML ein Vorgehensmodell?
Ahnen Sie jetzt, warum man in großen Projekten so entwickelt?
3. Objektorientierte SW-Entwicklung
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 49
4. Objektorientierte Analyse
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 50
Zur Erinnerung: Abstraktionsebenen
Abstraktionsebenen der objektorientierten Systementwicklung (4-Schichten-Modell)
Arzt.cpp
4. Objektorientierte Analyse
Reale Welt
OOA-Ebene
OOD-Ebene
Programm
Abstraktion
Codierung
Implementierungs-konzepte
gedankliche Ebene
logische Ebene (Modell)
physische Ebene (Implementierungsebene)
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 51
Anforderungsanalyse
Typische Situation:
Der Kunde oder Auftraggeber kommt und erklärt was er haben will...
d. h. er beschreibt mehr oder weniger präzise seine Anforderungen
In seiner eigenen Sprache
mit Hinweisen auf Vorgängersysteme
mit Lösungsideen
Anforderungen können sein
funktionale Anforderungen:
- Gesamtablauf (Workflow): Beschreibt auch interne Abläufe
- Anwendungsfälle: Beschreiben das Verhalten eines „Systems“ an der Systemgrenze
nicht funktionale Anforderungen:
- Qualitäten des zukünftigen Systems:
z. B. Performance, Ausfallsicherheit, Benutzerfreundlichkeit, Robustheit, ...
- Fertigstellungstermin, HW, SW
Aber wie schreibt man das auf?
4. Objektorientierte Analyse
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 52
Lernziele
Sie sollen in diesem Kapitel verstehen,
Wie die Ergebnisse der Anforderungsanalyse dokumentiert werden
Was zur Dokumentation einer Anforderung gehört
Welche Möglichkeiten Use Cases bieten
Wie man Use Cases in Textform aufschreibt
Wie man Use Cases in UML darstellt
Wie man ein gesamtes System mit Use Cases beschreibt
Welche alternativen Beschreibungsmöglichkeiten es gibt
Hinterher wissen Sie wie man die Ergebnisse einer objektorientierten Analyse dokumentieren kann!
4. Objektorientierte Analyse
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 53
4.1 Textuelle Beschreibung von Use Cases
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 54
Beispiel: Kundenanforderungen Geldautomat (ATM)
Verbale Beschreibung eines (ungewöhnlich präzisen) Kunden:
„Geld abheben“
Nachdem der Kunde die Karte eingeschoben und die PIN und den Betrag
eingegeben hat, wird der Betrag vom Konto abgebucht und die Karte und das
Geld ausgegeben. Falls die PIN das 1. oder 2. Mal falsch eingegeben wurde,
wird der Kunde benachrichtigt und die PIN wird erneut eingegeben. Falls die PIN
ein 3. Mal falsch eingegeben wurde, protokolliert das System den Versuch, zieht
die Karte ein und bricht die Kommunikation ab. Falls die Karte nicht gültig ist,
wird dies dem Kunden mitgeteilt und die Karte wieder ausgegeben.
Welche Teile müssen sequentiell ablaufen, was darf oder soll parallel laufen?
Ist bei „oder“ eventuell „entweder-oder“ gemeint?
Natürliche Sprachen sind oft nicht eindeutig genug für eine exakte Beschreibung!
4.1 Textuelle Beschreibung von Use Cases
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 55
Notation am Beispiel: Geldautomat
Exakte Beschreibung: „Geld abheben“
1. Kunde schiebt Karte ein.
2. Das System stellt fest, dass die Karte gültig ist.
3. Kunde gibt PIN ein.
4. Das System stellt fest, dass die PIN die richtige PIN zur Karte ist.
5. Kunde gibt gewünschten Betrag ein.
6. System bucht Betrag vom Konto ab.
7. System gibt Karte aus.
8. System gibt Geld aus. „Aktionen“
(„Action-Steps“)
Ablauf („Basic Course“)
Ziel („Goal“)
Verwenden Sie einfache und klare Sätze! Aktive Formulierungen mit Subjekt, Prädikat, Objekt!
4.1 Textuelle Beschreibung von Use Cases
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 56
Ergebnis eines Anwendungsfalls (Use Case)
Der Benutzer des Systems erwartet ein bestimmtes Ergebnis, wenn der
Anwendungsfall erfolgreich verläuft
Success Guarantees oder Use Case-Business-Result
Sind Bedingungen, die im Erfolgsfall erfüllt werden
Der Use Case wurde bis zum Ende durchgeführt und nicht abgebrochen
Beispiele für Success Guarantees
- „Das Geld wurde vom Automat ausgegeben und vom Konto abgebucht“
- „Die Karte wurde vom Automat ausgegeben“
Minimal Guarantees
Bedingungen, die immer – d. h. im Erfolgsfall und auch bei Abbruch – erfüllt sind
Beispiele für Minimal Guarantees
- „Alle Fehler- und Transaktionsdaten wurden protokolliert“
- „Das System ist wieder bereit für den nächsten Kunden“
Aber was passiert, wenn der Use Case nicht erfolgreich abläuft?
4.1 Textuelle Beschreibung von Use Cases
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 57
Alternativer Ablauf eines Use Cases
Alternative Course:
4a. Das System erkennt, dass die PIN das 1. oder 2. Mal falsch eingegeben wurde:
4a1. Das System protokolliert den Fehlversuch.
4a2. Das System benachrichtigt den Kunden.
4a3. Rückkehr nach 3.
Alternative Course:
4b. Das System erkennt, dass die PIN das 3. Mal falsch eingegeben wurde:
4b1. Das System protokolliert den Versuch.
4b2. Das System zieht endgültig die Karte ein.
4b3. Das System benachrichtigt den Kunden.
4b4. Use Case wird abgebrochen.
Bezug zum Basic Course
„Alternative Course“
4.1 Textuelle Beschreibung von Use Cases
Bedingung
„Aktionen“ („Action-Steps“)
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 58
Alternative Course: Übung
Es wird eine ungültige Karte in den Geldautomaten eingeschoben
(z. B. die Mensakarte).
Beschreiben Sie den alternativen Ablauf!
Alternative Course:
2a. Das System erkennt, dass die Karte nicht gültig ist:
2a1. Das System protokolliert den Versuch.
2a2. Das System benachrichtigt den Kunden
2a3. Das System gibt die Karte aus.
2a4. Der Use Case wird abgebrochen.
4.1 Textuelle Beschreibung von Use Cases
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 59
Auslösung eines Use Cases
Ein Use Case wird durch ein bestimmtes Ereignis gestartet
ein Kunde ruft an
um 19:00 Uhr startet die Datensicherung
das System stellt einen Fehler fest
Der „Trigger“ ist die erste Aktion, die mit unserem System interagiert
Der „Primary Actor“ ist derjenige, der die erste Aktion des Use Case
anstößt, um ein Ziel zu erreichen
Das muss nicht derjenige sein, der selbst direkt mit dem System kommuniziert,
sondern evtl. auch der Anrufer, der die Erfassung eines Auftrags durch einen
Sachbearbeiter anstößt.
Beispiel: Ein Kunde ruft an und will einen Auftrag vergeben. Die erste Aktion
(mit unserem Auftragserfassungssystem) ist dann: Der Sachbearbeiter ruft das
Auftragserfassungsprogramm auf
„Trigger“
„Primary Actor“
4.1 Textuelle Beschreibung von Use Cases
„Actor“
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 60
Wer definiert Use Cases?
Alle Personen, die ein berechtigtes Interesse an
einem bestimmten Verhalten des Systems haben
nicht nur die Akteure, sondern auch: • Besitzer des zukünftigen Systems,
• der Abteilungsleiter,
• die interne Revisionsabteilung
• aber nicht der Einbrecher für eine Alarmanlage
Die Akteure sind oft für die Definition der Use Cases gar nicht so wichtig
Die Interessen der Stakeholder äußern sich in den Action-Steps
z. B. Interesse des Kunden/der Bank: „keine unberechtigte Abhebung“:
- Einschieben EC-Karte, PIN-Überprüfung
Interesse des Kunden: „Falls Karte/Geld nach Ausgabe nicht entnommen wird,
soll dem Kunde kein Schaden entstehen“:
- Wieder-Einziehen der Karte/des Geldes
und späteres Abholen der Karte am Schalter/Gutschrift des Gelds aufs Konto
„Stakeholders“ & „Interests“
4.1 Textuelle Beschreibung von Use Cases
ist zwar Actor, aber kein Stakeholder!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 61
Muster für Use Case-Spezifikation (I)
4.1 Textuelle Beschreibung von Use Cases
Use Case Name <name = Use Case-Goal>
Primary Actor <a role name for the primary actor or description>
Further Actors <Role Name for further actors or description>
Stakeholders and their Interests
<list of stakeholders and their key interests in the use case>
Success Guarantees <the state of the world if goal succeeds>
Minimal Guarantees <how the interests are protected under all exits>
Trigger <what starts the Use Case (may be a time event)>
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 62
Muster für Use Case-Spezifikation (II)
4.1 Textuelle Beschreibung von Use Cases
Basic Course (Main Success Scenario)
<put here the steps of the scenario from trigger to
goal delivery and any cleanup after>
<step#> <action description>
<step#> <action description> …
Alternative Course
<step# with reference to step in Basic Course
(same step-number with following a. or b. ...,
e.g. 2a.)> <Condition>
<step# of the Alternative Course, e.g. 2a1.>
<action description>...
(Return point is specified in the action description in step(s)
in the alternative Course)
Es gibt diverse ähnliche Templates für die Beschreibung! Häufig mit weiteren Rubriken
(z. B. Vor- & Nachbedingungen oder Ausnahmen)
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 63
Beispiel „Geld abheben“: Use Case-Spezifikation (I)
4.1 Textuelle Beschreibung von Use Cases
Use Case Name
Primary Actor
Further Actors
Stakeholders and their Interests
Success Guarantees
Minimal Guarantees
Trigger
Kunde
--
Bank: Schutz vor unberechtigtem Zugriff
Kunde: Abbuchung nur nach Auszahlung
Das Geld wurde vom Automat ausgegeben und vom Konto abgebucht
Die Karte wurde vom Automat ausgegeben.
Alle Fehler– und Transaktionsdaten wurden protokolliert
Das System ist bereit für den nächsten Kunden.
Kunde schiebt Karte ein
Geld abheben
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 64
Beispiel „Geld abheben“: Use Case-Spezifikation (II)
4.1 Textuelle Beschreibung von Use Cases
Basic Course (Main Success Scenario)
1.Kunde schiebt Karte ein.
2.Das System stellt fest, dass die Karte gültig ist.
3.Kunde gibt PIN ein.
4.Das System stellt fest, dass die PIN die richtige PIN zur Karte ist.
5.Kunde gibt gewünschten Betrag ein.
6.System bucht Betrag vom Konto ab.
7.System gibt Karte aus.
8.System gibt Geld aus.
Alternative Course (2a)
2a. System erkennt, dass die Karte nicht gültig ist:
2a1. Das System protokolliert den Versuch.
2a2. Das System benachrichtigt den Kunden
2a3. Das System gibt die Karte aus.
2a4. Use Case wird abgebrochen.
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 65
Beispiel „Geld abheben“: Use Case-Spezifikation (III)
4.1 Textuelle Beschreibung von Use Cases
Alternative
Course (4a)
4a. Das System erkennt, dass die PIN das 1. oder
2. Mal falsch eingegeben wurde:
4a1. Das System protokolliert den Versuch.
4a2. Das System benachrichtigt den Kunden.
4a3. Rückkehr nach 3.
Alternative
Course (4b)
4b. Das System erkennt, dass die PIN das 3. Mal
falsch eingegeben wurde:
4b1. Das System protokolliert den Versuch.
4b2. System zieht die Karte endgültig ein.
4b3. Das System benachrichtigt den Kunden.
4b4. Use Case wird abgebrochen.
(2a) und (4b) sind „Exceptions“, d. h. hier sind die Success Guarantees nicht erfüllt – die Minimal Guarantees aber schon!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 66
Gedanken zu Use Cases
Ein Use Case beschreibt eine Menge von Aktionsfolgen, einschließlich
Varianten, die ein System ausführt, um ein erkennbares, für einen Aktor
nützliches Ergebnis zu erarbeiten.
Ein Use Case stellt eine funktionale Anforderung an das System als Ganzes dar
Ein Use Case beschreibt nicht, wie das Verhalten implementiert wird
Use Cases sind geeignet um das Verhalten eines Systems in der Außensicht zu
visualisieren, zu spezifizieren, und zu dokumentieren
Use Cases bieten eine Basis für die Verständigung von Entwicklern,
Endanwendern und Fachleuten für den Anwendungsbereich;
für die Requirements, für die Überprüfung der Architektur, und für den Test
4.1 Textuelle Beschreibung von Use Cases
Die Sammlung der Use Cases ergibt noch keine vollständige Sammlung der Requirements!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 67
Tipps für die Beschreibung des Ablaufs
Benutze eine einfache Grammatik
Zeige immer klar: „Wer hat den Ball“:
System gibt Meldung ... aus
Kunde wählt am System ... aus
System führt ... aus, bis ... eintritt
Schreibe aus der User- (bzw. Vogel)perspektive (keine System-Interna!)
Vermeide Passiv („Es wird ... angezeigt“) und Konjunktiv
wenn sinnvoll, erwähne die Zeit
Zeige wie sich der Prozess fortbewegt
Zeige was der Aktor will, nicht seine Bewegungen
Benutze eine sinnvolle Menge von Aktionen
Wähle exakte Begriffe und Wörter
„Der Kunde gibt eine PIN ein“ ist ungenau – es sollte schon die richtige PIN sein!
4.1 Textuelle Beschreibung von Use Cases
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 68
Lange Use Cases
Geld abheben
1. Kunde schiebt Karte ein.
2. Das System stellt fest,
dass die Karte gültig ist.
3. PIN-Eingabe:
Kunde gibt PIN ein.
4. PIN-Prüfung:
Das System stellt fest,
dass die PIN die richtige
PIN zur Karte ist.
5. Kunde gibt gewünschten Betrag ein.
6. System bucht Betrag vom Konto ab.
7. System gibt Karte aus.
8. System gibt Geld aus.
Annahmen
In Schritt 5 können alternativ neue
Schecks angefordert werden
(mit Angabe der Anzahl)
In Schritt 5 kann zusätzlich ein
Kontoauszug gedruckt werden
Nach der Eingabe des Betrags in
Schritt 5 kann die Stückelung des
Geldes (Große oder kleine Scheine)
gewählt werden.
Diese Schritte werden auch von
anderen Use-Cases verwendet
...
4.1 Textuelle Beschreibung von Use Cases
Wie kann das dargestellt werden ohne alles
mehrfach in verschiedenen Use Cases zu
beschreiben?
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 69
Auslagern von Teilen von Use Cases
Es gibt für Use Cases einen Mechanismen um Teile auszulagern
Include
Analog zu dem Include von C++, d. h. durch einen Include-Befehl im Hauptablauf
wird der ausgelagerte Ablauf eingelesen und an dieser Stelle eingefügt
Die ausgelagerten Include-Use Cases
- werden möglichst als vollständige Use Cases beschrieben!
- sollten eine Funktionalität aus Benutzersicht erbringen
Es gibt eigentlich noch einen zweiten Mechanismus: Extend
Diesen Mechanismus verwenden wir nicht
4.1 Textuelle Beschreibung von Use Cases Aber bitte nicht zum
„Programmieren“ verwenden!
Das bisherige Use Case Template muss um
entsprechende Verweise erweitert werden!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 70
Erweiterung des Use Case Templates um Include
Use Case Name <name = Use Case-Goal>
Primary Actor <a role name for the primary actor or description>
Further Actors <Role Name for further actors or description>
Stakeholders and their Interests
<list of stakeholders and their key interests in the use case>
Success Guarantees <the state of the world if goal succeeds>
Minimal Guarantees <how the interests are protected under all exits>
Trigger <what starts the Use Case (may be a time event)>
Basic Course (Main
Success Scenario)
<step #> ...
<step #> Include: <Name of Included
Use Case>
Alternative Course <step# with reference to step in Basic Course
(same step-number with following a. or b. ...,
e.g. 2a.)> <Condition>
<step# of the Alternative Course, e.g. 2a1.>
<action description>...
(Return point is specified in the action description in step(s)
in the alternative Course)
Use Case Name <name = Use Case-Goal>
Primary Actor <a role name for the primary actor or
description>
Further Actors <Role Name for further actors or description>
Stakeholders and their Interests
<list of stakeholders and their key interests in the use case>
Success Guarantees <the state of the world if goal succeeds>
Minimal Guarantees <how the interests are protected under all exits>
Trigger <what starts the Use Case (may be a time event)>
Basic Course
(Main Success
Scenario)
<step #> ...
<step #> Include: <Name of Included Use
Case>
<step #> ...
4.1 Textuelle Beschreibung von Use Cases
Include Use Case
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 71
Beispiel: Der bisherige Use Case „Geld abheben“
4.1 Textuelle Beschreibung von Use Cases
Basic Course 1. Kunde schiebt Karte ein.
2. Das System stellt fest, dass die Karte gültig ist.
3. Kunde gibt PIN ein.
4. Das System stellt fest, dass die PIN die richtige PIN zur Karte ist.
5. Kunde gibt gewünschten Betrag ein.
6. System bucht Betrag vom Konto ab.
7. System gibt Karte aus.
8. System gibt Geld aus.
Alternative Course (2a)
2a. Das System erkennt, dass die Karte nicht gültig ist:
2a1. Das System protokolliert den Versuch.
2a2. Das System benachrichtigt den Kunden
2a3. Das System gibt die Karte aus.
2a4. Use Case wird abgebrochen.
Modelliere den Alternative Course 2a als eigenständigen
Include-Use Case „Karte überprüfen“!
„Karte überprüfen“ wird auch in anderen Use-Cases gebraucht!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 72
Beispiel: „Geld abheben“ ‒ Änderungen wegen Include (I)
4.1 Textuelle Beschreibung von Use Cases
Use Case Name Geld abheben
Primary Actor Kunde
Further Actors --
Stakeholders and their Interests
Bank: Schutz vor unberechtigtem Zugriff
Kunde: Abbuchung nur nach Auszahlung
Success Guarantees
Das Geld wurde vom Automat ausgegeben und vom
Konto abgebucht
Die Karte wurde vom Automat ausgegeben.
Minimal Guarantees
Alle Fehler– und Transaktionsdaten wurden protokolliert
Das System ist bereit für den nächsten Kunden.
Trigger Kunde schiebt Karte ein
Beispiel: „Geld abheben“ ‒ Änderungen wegen Include (II)
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 73
4.1 Textuelle Beschreibung von Use Cases
Basic Course (Main Success Scenario)
1. Kunde schiebt Karte ein.
2. Include <Karte prüfen>
3. Kunde gibt PIN ein.
4. Das System stellt fest, dass die PIN die richtige PIN zur Karte ist.
5. Kunde gibt gewünschten Betrag ein.
6. System bucht Betrag vom Konto ab.
7. System gibt Karte aus.
8. System gibt Geld aus.
Alternative Course
(4a)
4a. Das System erkennt, dass die PIN das 1. oder 2.
Mal falsch eingegeben wurde:
4a1. Das System protokolliert den Versuch.
4a2. Das System benachrichtigt den Kunden.
4a3. Rückkehr nach 3.
Alternative Course
(4b)
4b. Das System erkennt, dass die PIN das 3. Mal
falsch eingegeben wurde:....
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 74
Beispiel: Include-Use Case „Karte überprüfen“
4.1 Textuelle Beschreibung von Use Cases
Use Case Name Karte überprüfen
Primary Actor Kunde
Further Actors --
Stakeholders & Interests
Bank: Schutz vor unberechtigtem Zugriff
Success Guarantees
Die Karte ist gültig
Minimal Guarantees
Alle Fehler- und Transaktionsdaten wurden
protokolliert
Der Automat hat kein Geld ausgegeben und auch
kein Geld abgebucht
Trigger Aufruf durch anderen Use Cases
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 75
Beispiel: Include-Use Case „Karte überprüfen“ (II)
4.1 Textuelle Beschreibung von Use Cases
Basic Course (Main Success Scenario)
1. Das System stellt fest, dass die Karte gültig ist.
2. Use Case wird beendet
Alternative Course (1a)
1a. Das System erkennt, dass die Karte nicht gültig ist:
1a1. Das System protokolliert den Versuch.
1a2. Das System benachrichtigt den Kunden
1a3. Das System gibt die Karte aus.
1a4. Use Case wird abgebrochen.
Der Include-Use Case verhält sich wie ein Unterprogramm!
Es gibt ein erfolgreiches Ende (Return) und einen Abbruch (Exit)
Bewertung von Include-Use Cases
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 76
4.1 Textuelle Beschreibung von Use Cases
Quelle: UML Glasklar
Wenn ein Use Case A einen Use Case B includiert
schließt der Ablauf von A immer den Ablauf von B ein
Der Ablauf von B kann so in verschiedenen Use-Cases
genutzt werden (als eine Art Unterprogramm)
A ist meist unvollständig und wird erst durch Inklusion
von B zu einem vollständigen Ablauf
B ist häufig künstlich zur Redundanzvermeidung gebildet
A muss B bei der Modellierung berücksichtigen
B wird unabhängig von A modelliert, um die Nutzung
durch weitere Use-Cases zu ermöglichen
B muss in sich nicht vollständig sein („B weiß nicht, durch
wen es inkludiert wird“).
Use Case Name <name = Use Case-Goal>
Primary Actor <a role name for the primary actor or description>
Further Actors <Role Name for further actors or description>
Stakeholders and their Interests
<list of stakeholders and their key interests in the use case>
Success Guarantees <the state of the world if goal succeeds>
Minimal Guarantees <how the interests are protected under all exits>
Trigger <what starts the Use Case (may be a time event)>
Basic Course (Main
Success Scenario) <step #> ...
<step #> Include: <Name of Included
Use Case>
Alternative Course <step# with reference to step in Basic Course
(same step-number with following a. or b. ...,
e.g. 2a.)> <Condition>
<step# of the Alternative Course, e.g. 2a1.>
<action description>...
(Return point is specified in the action description in step(s) in
the alternative Course)
Use Case Name <name = Use Case-Goal>
Primary Actor <a role name for the primary actor or
description>
Further Actors <Role Name for further actors or description>
Stakeholders and their Interests
<list of stakeholders and their key interests in the use case>
Success Guarantees <the state of the world if goal succeeds>
Minimal Guarantees <how the interests are protected under all exits>
Trigger <what starts the Use Case (may be a time event)>
Basic Course
(Main Success
Scenario)
<step #> ...
<step #> Include: <Name of Included Use
Case>
<step #> ...
Include Use Case B
Use Case A
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 77
Tipps (I): Allgemeines
Halte die Benutzeroberfläche heraus
Stelle sicher, dass die enthaltenen Schritte die wahre Absicht (die funktionale
Anforderung) des Aktors widerspiegeln und nicht die Bewegungen des Aktors
beim Manipulieren der Oberfläche.
Man kann Use Cases aber auch einsetzen um Benutzer-Oberflächen zu
dokumentieren (dann ist die Bedienung der Oberfläche die Anforderung)
Jeder Use Case hat zwei Enden: Erfolg und Misserfolg
Beachte, dass auch ein Include-Use Case mit Erfolg oder Misserfolg enden kann
Wenn der Use Case abgeschlossen wird, muss die Erfolgsbedingung gelten!
Ansonsten muss abgebrochen werden
Taucht ein Sonderfall im Hauptablauf auf, wird er ausgelagert
(alternative Course)
In einer Auslagerung werden sowohl Erfolg als auch Fehlerbehandlung
beschrieben
4.1 Textuelle Beschreibung von Use Cases
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 78
Tipps (II): Mache die Use Cases einfach lesbar (jeden einzelnen)
Halte dich kurz und bringe es auf den Punkt
starte vom Trigger und fahre fort bis das Ziel erreicht oder aufgegeben ist
Ein Use Case hat zwischen 3 und 9 Schritten. Wenn mehr als 9 Schritten
vorhanden sind, fasse die Schritte zusammen ‒ oder lagere Teile als Einzel-Use
Cases aus
Schreibe volle Sätze mit aktiven Verben, die das Unterziel, das erreicht werden
soll, ausdrücken (Das System zieht ..., Kunde gibt ...)
Stelle sicher, dass der Aktor und seine Absicht in jedem Schritt sichtbar werden
Stelle sicher, dass die Fehlerbedingungen gut erkennbar und die Aktionen zur
Fehlerbehandlung gut lesbar sind.
Stelle sicher, dass gut erkennbar ist, was als nächstes passiert ‒ auch ohne die
Nummern der Schritte
Füge alternatives Verhalten in den alternative Course ein
(und nicht als „if“ in den Hauptablauf)
4.1 Textuelle Beschreibung von Use Cases
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 79
Literatur
Alistair Cockburn: „Writing Effective Use Cases“
Addison-Wesley-Verlag, 2000
4.1 Textuelle Beschreibung von Use Cases
Alistair Cockburn: „Use Cases effektiv erstellen“
Mitp-Verlag, 2003
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 80
4.2 Use Cases für ein System
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 81
Ein System als Beispiel
Ein System hat
viele Use Cases
mit vielen Aktoren und Stakeholdern
Beispiel
Use Cases für den Aktor „Kunde“:
Geld abheben
PIN prüfen
Kontostand abfragen
weitere Use Cases:
Status Remote abfragen (Servicetechniker)
Geld einfüllen (Geldbote)
...
www.wincor-nixdorf.com
Die bisherige Notation in Textform wird schnell unübersichtlich!
Ergänze um ein „High-Level-Modell“ mit Abhängigkeiten!
4.2 Use Cases für ein System
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 82
Notation am Beispiel: Use Case Diagramm „Geldautomat“
Aktor
System
4.2 Use Cases für ein System
Assoziation
Geldautomat
Geld abheben
Use Case
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 83
4.2 Use Cases für ein System
Zusammenhang von textueller Beschreibung und graphischer Darstellung
Es existieren 2 Welten:
1. Textuelle Beschreibung mit
Basic Course + Alternative Courses
Beschreibung in Templates, keine standardisierten Inhalte
enthält detaillierte Abläufe
keine UML
2. Graphische Modellierung der Use Cases
Standardisierte Modellelemente, UML
Beziehungen zwischen Use Cases, System und Aktoren
Die Beziehung zwischen den beiden Darstellungen wird
in Tools oft mit Hyperlinks realisiert
durch Anklicken eines Use Cases im UML-Modell öffnet sich dann ein (externes)
Dokument mit der textuellen Beschreibung
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 84
Beispiel: Use Case Diagramm für das System „Geldautomat“
4.2 Use Cases für ein System
Geldautomat
Hardware
Selbsttest
Geld
abheben
Kontostand
abfragen
Geld
einfüllen
Remote den
Status abfragen
Fehlerprotokoll
auslesen
Fehlerbenachrichtigung
schicken
Bankkunde
Geldbote
Servicetechniker
System
Bankverantwortlicher
für Geldautomat
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 85
Beziehungen zwischen Use Cases
Include
Der Basisanwendungsfall bezieht explizit das Verhalten
des anderen Anwendungsfalls ein
Generalisierung
der spezialisierte Anwendungsfall ererbt das Verhalten
des allgemeineren Anwendungsfalls und kann dieses
ergänzen oder überschreiben
4.2 Use Cases für ein System
«include»
Geldautomat
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 86
Beziehungen zwischen Use Cases am Beispiel
4.2 Use Cases für ein System
Kontostand
ansehen Geld abheben
Geldkarte
aufladen
Benutzer
validieren
Retina
abtasten
Pin
überprüfen
<<include>> <<include>>
<<include>>
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 87
11 Schritte zu Use Cases für ein System (I)
1. Bestimme die Grenzen des Systems
(Was geht rein? Was geht raus?)
2. Brainstorme und liste die Aktoren
3. Brainstorme und liste die Ziele der Aktoren in Bezug
auf das System
4. Modelliere Use Cases, die das Gefundene zusammenfassen
5. Überdenke und verbessere die Use Cases.
Füge Ziele hinzu, entferne Ziele und fasse zusammen
6. Füge die Stakeholder und deren Interessen hinzu, formuliere
Vorbedingungen und Garantien. Überprüfe sie doppelt.
7. Schreibe das Haupterfolgsszenario (main success scenario).
Vergleiche es mit den Interessen und Garantien
4.2 Use Cases für ein System
System
Gutfall
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 88
11 Schritte zu Use Cases für ein System (II)
8. Brainstorme und liste die möglichen Fehlerbedingungen
und die alternativen Erfolgsbedingungen
9. Beschreibe wie die Aktoren und das System sich in den
Erweiterungen (Alternative Courses) verhalten sollen
10. Breche jeden Unter Use Case heraus, der eine eigenständige
Funktionalität bietet und der von anderen Use Cases benötigt wird
11. Beginne vom Anfang und verbessere die Use Cases.
Füge hinzu, entferne oder fasse zusammen wenn angebracht.
Überprüfe Vollständigkeit, Lesbarkeit und Fehlerbedingungen.
4.2 Use Cases für ein System
Ausnahme- Behandlung
Optimierung
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 89
4.3 Aktivitätsdiagramme
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 90
Ausgangssituation
Situation:
Use Cases- und Use Case Diagramme bieten adäquate Mittel
zur Darstellung der funktionalen Anforderungen!
- Aber die Abläufe sind in den Use Case -Templates nicht wirklich übersichtlich
dargestellt
- Parallele Vorgänge sind sprachlich schwer auszudrücken
Wie kann man Abläufe anschaulich beschreiben?
- übersichtlich und leicht verständlich
- inklusive Kontrollstrukturen (Schleifen und Bedingungen)
- inklusive paralleler Ausführung von Teilabläufen (Concurrency)
4.3 Aktivitätsdiagramme
Aktivitätsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 91
Notation am Beispiel: „Essen zahlen“
4.3 Aktivitätsdiagramme
Kasse Display-Kasse Lese-Schreib-Einheit
KarteAusschieben
EssenEintippen
BetragAnzeigen
KarteEinschieben
KarteLesen
BetragAbbuchen
VorgangStorno
AnzeigeKarteAufladen
[Geld reicht nicht]
[Geld reicht]
Startknoten
Aktion
Kontrollfluss(kante)
Verantwortungs-bereich
(swim lane)
Synchronisationsknoten
Entscheidungs- knoten
Endknoten
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 92
Notation am Beispiel: „Betragsfunktion“
4.3 Aktivitätsdiagramme
Aktivität
Action
Ergebnis Ergebnis [=Zahl]
Ergebnis [= -1*Zahl] Zahl
[Zahl >= 0]
[Zahl < 0] Zusammen-führungs-
knoten
Parameter
Objektknoten
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 93
Tokenprinzip
Aktivitätsdiagramme erlauben Verzweigungen des Kontrollflusses und
gleichzeitig ablaufende, parallele Pfade
Belege die aktiven Zweige mit je einer imaginären Marke („Token“) um zu
verstehen, wie der Ablauf funktioniert!
4.3 Aktivitätsdiagramme
- Nachdem der Ablauf gestartet wurde, wird das erste Token erzeugt. Danach wird die Aktion a1 ausgeführt und
das Token auf den Ausgang von a1 gelegt. Durch die Verzweigung in die beiden Threads p1 und p2 wird am
Anfang beider Threads je ein Token gesetzt. Die Aktionen p1 und p2 werden ausgeführt; die Tokens werden
auf die Ausgänge von p1 und p2 gelegt. Erst wenn auch das Token über p3 gewandert ist und beide Tokens da
sind, wird das Eingangstoken für a2 gestartet.
Dann wird a2 ausgeführt, das Token auf den Ausgang von a2 gelegt, die Aktivität beendet und das Token
vernichtet.
1 2
3
3
4
4 5
6 7 a1 a2
p1 p3
p2
Kasse Display-Kasse Lese-Schreib-Einheit
BetragAnzeigen
EssenEintippen KarteEinschieben
Tokenprinzip am Beispiel: „Essen zahlen“ (erfolgreich)
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 94
4.3 Aktivitätsdiagramme
1 3
2 4
3 5
6
7
8
9 10
KarteAusschieben
KarteLesen
BetragAbbuchen
VorgangStorno
AnzeigeKarteAufladen
[Geld reicht nicht]
[Geld reicht]
Aktion ZZZ
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 95
Elemente in Aktivitätsdiagrammen (I)
Aktion
Ist das Basiselement zur Spezifikation von Verhalten. Es beschreibt
einen Einzelschritt wie z. B. „Summe berechnen“
Eine Aktion kann als nicht weiter zerlegbare Funktion angesehen
werden. Sie transformiert eine Eingabe zu einer Ausgabe.
Aktivität
Eine Aktivität setzt sich aus Aktionen und anderen Aktivitäten
zusammen, die im Aktivitätsdiagramm enthalten sind.
Symbole in einer Aktivität stellen Aktionen dar aus denen die
Aktivität aufgebaut ist und Pfeile den Kontrollfluss.
Objektknoten
können in Aktivitätsdiagrammen Objekte oder Daten repräsentieren
Sie können als unabhängige Knoten in einem Diagramm benutzt
werden, bzw. als Parameter für Aktionen (Input, Output Pin)
4.3 Aktivitätsdiagramme
Ergebnis
[=Basis]
Aktivität XXX
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 96
Elemente in Aktivitätsdiagrammen (II)
Entscheidungsknoten
Es wird eine der herausführenden Kontrollflusskanten
weiterverfolgt (abhängig davon, welche Bedingung wahr ist).
Zu jedem Zeitpunkt darf nur genau eine Bedingung wahr
sein.
Zusammenführungsknoten
Schaltet eine von mehreren hineinführenden
Kontrollflusskanten, wird die herausführende
Kontrollflusskante weiterverfolgt
Synchronisationsknoten
Der aus dem Balken herausführende Ablauf kann nur dann
weitergeführt werden, wenn alle einmündenden Abläufe
beendet sind
Splittingknoten
Aus dem Balken herausführende Abläufe können gleichzeitig,
also parallel ausgeführt werden
(Aufspaltung des Kontrollflusses in mehrere parallele Teile)
4.3 Aktivitätsdiagramme
[else]
[x = 1]
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 97
Anwendung
Aktivitätsdiagramme
werden zur Modellierung von Abläufen und deren Steuerung benutzt
stellen die einzelnen Verfahrensschritte von Aktivitäten dar; zusammen mit der
Reihenfolge in der sie ausgeführt werden
können durch Verantwortungsbereiche („swim lanes“) die modellierten Aktionen
bestimmten Modellelementen zuordnen
können von der Modellierung von Geschäftsprozessen bis zur Visualisierung von
Kontrollflüssen benutzt werden
4.3 Aktivitätsdiagramme
Aktivitätsdiagramme können in einem Projekt überall verwendet
werden, wo Verhalten beschrieben werden muss,
bzw. wo Datenflüsse oder Kontrollflüsse modelliert werden sollen!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 98
Weiteres Beispiel: Geschäftsprozess „Getränk bereiten“
4.3 Aktivitätsdiagramme
Kaffeemaschine Barkeeper Cola-Automat
Maschine anschalten
Cola
entnehmen
Hole Dose
Cola
Suche
Getränk
Gast vertrösten Wasser eingießen Kaffee in Filter
geben
Getränk aushändigen
Kaffee eingießen
Kaffee
brühen
[Keine Cola vorhanden]
[Cola vorhanden]
[kein Kaffeepulver vorhanden]
[Kaffeepulver vorhanden]
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 99
4.4 Alternative Beschreibung von Use Cases
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 100
4.4 Alternative Beschreibungen von Use Cases
Möglichkeiten zur Beschreibung der Basic- und Alternative Courses
Zielsetzung Use Cases:
Beschreibung der Interaktion zwischen Benutzer(n) und einem System
Bisherige Ausdrucksmittel:
normaler Text
strukturierter Text (pro Satz eine Aktion), in Tabellen
Anforderungen
Möglichkeit zum Ausdruck von sequentiellen Abläufen zwischen System und der
Außenwelt
If-Konstrukt für alternative Abläufe
Schleifen
Auslagern von Teilabläufen
Das können Aktivitätsdiagramme auch!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 101
4.4 Alternative Beschreibungen von Use Cases
Alternative: Aktivitätsdiagramme für Basic und Alternative Course
Geld abheben
: Kunde
Geld ausgeben Karte ausgeben Betrag abbuchen Betrag eingeben
Kunde
benachrichtigen Karte einziehen
Fehlversuch
protokollieren
Kunde
benachrichtigen
PIN-Eingabe
Karte ausgeben
Kunde
benachrichtigen
Fehlversuch
protokollieren
Karte einschieben
[Karte gültig] [Karte ungültig]
[PIN gültig]
[PIN falsch]
[PIN 3. mal falsch]
[PIN 1. oder 2. mal falsch]
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 102
4.4 Alternative Beschreibungen von Use Cases
Bewertung
Die Beschreibung der Abläufe von Use Cases kann auch in UML erfolgen
Aktivitätsdiagramme sind dafür geeignet
dann muss man kein neues Sprach-Konstrukt zu erlernen
und die Beschreibungsmittel sind standardisiert
und es gibt Tools
aber
die Verständlichkeit nimmt ab
(versteht der Kunde/Auftraggeber überhaupt Aktivitätsdiagramme?)
eine derartige Verwendung der UML ist nicht allgemein üblich
es fehlen Ausdrucksmöglichkeiten für Stakeholder, Trigger, Guarantees,...
Die meisten UML-Diagramme können zu
unterschiedlichen Zwecken eingesetzt werden!
Der Vorteil der „internationalen Sprache“ UML geht dann
aber schnell verloren!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 103
Es geht auch ganz anders! Agile Softwareentwicklung (vereinfacht)
Das Erstellen von Use Cases verursacht erheblichen Aufwand
es hilft bei der Klärung der Anforderungen
aber es kostet Zeit und Geld
und oft weiß der Kunde nicht genau, was er will
In der „agilen Softwareentwicklung“ wird die Software schnell und iterativ
entwickelt. Ca. alle 2 Wochen gibt es einen lauffähigen (Teil-)Release
Ein lauffähiges System sagt mehr aus, als jeder Use Case
man muss nur die Anforderungen genau verstehen, die gerade entwickelt
werden
„User Storys“ beschreiben in wenigen Worten (oft auf einer Karteikarte),
wer was warum möchte, also den Wunsch und den Nutzen für einen User
Beispiel: Als Kunde möchte ich, dass ... weil ich dann ...
Die User Storys werden vor der Implementierung im Detail besprochen
4.4 Alternative Beschreibungen von Use Cases
In der Veranstaltung „Software Engineering“ wird die agile Entwicklung
ausführlicher betrachtet!
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 104
4.5 Analysemodell
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 105
Analysemodell
Bei der Beschreibung der Anwendungsfälle stößt man auf materielle und
immaterielle Dinge (Objekte!) mit zu verwaltenden Informationen
Identifizieren von Objekten, Klassen, Attributen, Beziehungen
nur Klassen und Attribute, d. h. keine Operationen
keine Richtungen bei Beziehungen
evtl. Gemeinsamkeiten als Generalisierungsbeziehungen
evtl. weitere Eigenschaften der Klassen, die nicht in Diagrammform ausdrückbar
sind, in Textform
die Klassen des Analysemodells/Domainmodells nennt man Analyse-/Domain-
Klassen
Modelliere diese Objekte der Domäne als
„Klassen“ mit Eigenschaften und Beziehungen
Analysemodell/Domänenmodell
4.5 Analysemodell
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 106
Analyseklassendiagramm
Klassendiagramme werden im Kapitel „Design“
ausführlich behandelt!
allgemeine Datentypen
keine Methoden
4.5 Analysemodell
CTaschenrechner
CSpeicher
-top: int
-stack: double
CProzessor CEinAusgabe
-text: String
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 107
Ergebnis des Analysemodells
Statische Systemsicht
Klassendiagramme mit rudimentären Klassen (Domain-/Analyseklassen)
die zu Objekten gehören, die ein Anwender wahrnimmt
Erstellungsregeln:
- jede Domainklasse muss in mindestens einem Anwendungsfall vorkommen
- jede Domainklasse sollte mindestens ein Attribut haben
- Domainklassen enthalten keine Realisierungsdetails einer potentiellen Lösung
Dynamische Systemsicht
Aktivitätsdiagramme zur Verdeutlichung der Abläufe
Das Analysemodell stellt einen ganz groben Entwurf für das Design dar
es dient der Verständigung zwischen Auftraggeber und -nehmer
die tatsächliche Umsetzung kann sich später deutlich unterscheiden
In der Designphase kommen weitere Diagramme hinzu (z. B. Zustands- und
Komponentendiagramme)
4.5 Analysemodell
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 108
Kontrollfragen
Welche Zielsetzung hat die Anforderungsanalyse?
Warum beschreibt man Anforderungen nicht in einer natürlichen Sprache?
Ist ein Dieb ein Stakeholder für einen Geldautomaten? Ein Aktor?
Was ist der Unterschied zwischen Include und Extend?
Wie stellt man Use Cases in UML dar?
Wie beschreibt man ein gesamtes System mit Use Cases?
Welche Beziehungen gibt es in der UML zwischen Use Cases?
Kann man Use Cases komplett in der UML beschreiben?
Was ist das Tokenprinzip?
Was sind „Swim Lanes“?
Was unterscheidet Zusammenführungsknoten von Synchronisationsknoten?
Was ist das Analysemodell?
Sie wissen jetzt wie man die Ergebnisse einer objektorientierten Analyse dokumentieren kann!
4. Objektorientierte Analyse
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 109
5. Objektorientiertes Design
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 110
Zur Erinnerung: Abstraktionsebenen
Abstraktionsebenen der objektorientierten Systementwicklung (4-Schichten-Modell)
Arzt.cpp
5. Objektorientiertes Design
Reale Welt
OOA-Ebene
OOD-Ebene
Programm
Abstraktion
Codierung
Implementierungs-konzepte
gedankliche Ebene
logische Ebene (Modell)
physische Ebene (Implementierungsebene)
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 111
Zur Erinnerung: Phasenmodell der objektorientierten Systementwicklung
Informations-gehalt
Entwicklungs-phase
OOP (Programmierung)
OOD (Design)
OOA (Analyse)
reale Welt
Analyse-Modell
Design-Modell
Coderahmen
Abstraktion
Konkretisierung
Abbildung
Isomorphismus
Code
Konsistenz
5. Objektorientiertes Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 112
Zwischenstand
Sie ahnen jetzt
wie man die Welt der Anwendung analysiert und
daraus Objekte und Klassen extrahiert
Sie wissen jetzt
wie man die Ergebnisse dokumentiert
- als textuelle Use Cases, als Use Case Diagramme (UML)
- als Aktivitätsdiagramme (UML)
- als Analysemodell
Das ist alles recht abstrakt und hat wenig mit der Umsetzung zu tun!?
ergänze nun Umsetzungsdetails (Programmiersprache, Betriebssystem,...)
modifiziere die Analyseklassen
- um weitere Klassen für die Realisierung
- um Methoden, weitere Attribute
Objektorientiertes Design
5. Objektorientiertes Design
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 113
5.1 Darstellung der Statik eines Systems
Objektorientierte Analyse und Design
5.1.1 Klassen und die UML
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 114
Lernziele
Sie sollen in diesem Kapitel verstehen,
wie man Klassen darstellt
wie man Klassen und deren Assoziationen findet
welche Arten von Beziehungen es zwischen Klassen gibt
Was Generalisierung und Spezialisierung ist
wie man Klassen und die Beziehungen zwischen Klassen in UML darstellt
wie man Klassen und Beziehungen in C++ umsetzt
Hinterher können Sie Klassen und deren Beziehungen in
einem Klassendiagramm darstellen!
5.1.1 Darstellung der Statik eines Systems: Klassen und die UML
Window
# groesseX : Integer
# groesseY : Integer
- sichtbar : Boolean = TRUE
+ position : (x : Integer, y : Integer)
- standardGroesse: Flaeche
+ darstellen_Icons ()
+ maximieren ()
+ minimieren ()
# create ()
+ veraendern_Groesse (offsetX, offsetY)
+ ausgeben_Flaeche () : Flaeche
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 115
Darstellung von Klassen, Attributen und Methoden
geschütztes Attribut
privates Attribut
öffentliches Attribut
Klassenattribut
Öffentliche Operation
Klassenmethode
Typ
Initialisierung
Parameter
Rückgabewert-Typ
Spezifikation Beschreibung...
5.1.1 Darstellung der Statik eines Systems: Klassen und die UML
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 116
Darstellung von Klassen, Attributen und Methoden (II)
Klassenmethode:
Bezieht sich nicht auf Instanz (Instanzmethode) sondern auf die Klasse als die
Menge aller ihrer Objekte z. B.: Konstruktor, Berechnung Durchschnittsgehalt
etc.
Klassenattribute:
Attributwert ist nicht einer Instanz (Instanzattribut) sondern der Klasse
zugeordnet und existiert nur 1x für die Klasse. z. B.: maxGeschwindigkeit eines
Fahrzeugtyps
Spezifikation:
Text, der die Verantwortlichkeit / den Zweck einer Klasse, eines Attributs oder
einer Methode beschreibt
Methoden für das Schreiben und Lesen von Attributen:
SetXXX, GetXXX sind trivial werden nicht in die Klassendef. auf Analyse-
Ebene aufgenommen
Bei Verwendung eines CASE-Tools:
Einzelangaben können, um die Übersicht des Gesamtdiagramms zu erhöhen,
ausgeblendet werden
5.1.1 Darstellung der Statik eines Systems: Klassen und die UML
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 117
Wie findet man Kandidaten für Klassen (und Attribute)?
Aus den Beschreibungen der Anwendungsfälle (Use Cases)!
Suche nach Substantiven (Kandidaten für Klassen, evtl. Attribute), z. B.
- Personen, Orte, konkrete Dinge
(Artikel, Rechnungen, Abteilung, Messwerte etc.)
- Schnittstellen eines Systems
(Masken, Anbindungen an Datenbanken etc.)
- Abstrakte Dinge (ein Algorithmus, eine Information etc.)
Ordne nach Klassenkandidaten/Attributen zu Klassenkandidaten
Sondere überflüssige Klassenkandidaten aus!
Ist Kunde eine eigene Klasse oder nur eine Rolle in einer gemeinsamen Klasse?
(z. B. Klasse Person mit Rollen: Kunde, Vorgesetzter etc.)
Ergänze später im Lauf der Modellierung
fehlende Klassen fallen auf, wenn man mit dem Modell arbeitet
5.1.1 Darstellung der Statik eines Systems: Klassen und die UML
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 118
Wie findet man weitere Attribute und Methoden?
Attribute und Methoden ergeben sich aus
Beobachtungen des Anwendungsgebiets (der „Domäne“)
- Attribute: Eigenschaften der Objekte
- Methoden: Operationen auf den Objekten
oder aus der Analyse von Vorgängersystemen
- Attribute: Einträge in Formularen, Bildschirmmasken, Datenmodell etc.
- Methoden: Aktionen und Buttons in Formularen, Bildschirmmasken etc.
oder aus Anwendungsfällen (Use Cases)
- Attribute: z. B. ...für jeden Kunden wird das Alter erfasst...
- Methoden: Suche Verben, die Aktionen auf den Objekten ausführen
und auch bei der Weiterarbeit mit dem Modell
- fehlende Attribute und Methoden fallen auf, wenn man mit dem Modell arbeitet
5.1.1 Darstellung der Statik eines Systems: Klassen und die UML
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 119
Trennung von Zuständigkeiten – Wie viele Klassen braucht der Mensch?
Es gibt viele Möglichkeiten, die gefundenen Attribute und Methoden auf eine
oder mehrere Klassen zu verteilen
Eine Leitlinie für die Verteilung gibt die „Trennung von Zuständigkeiten“
Verwende eine Klasse für jedes Tätigkeitsgebiet!
Sorge dafür, dass (innerhalb einer Klasse) alles miteinander zu tun hat!
Dies führt zu einem feingranularen Entwurf mit verhältnismäßig vielen Klassen
Im „echten Leben“ werden diese Klassen aber schnell größer, sobald mehr
Details implementiert werden
Überprüfe die Trennung von Zuständigkeiten mit „Tätigkeitsbeschreibungen“
Wenn die Aufgabe einer Klasse konkret und kompakt mit einem Satz
beschrieben werden kann, hat sie tatsächlich nur eine Aufgabe
Eine Aufzählung in der Tätigkeitsbeschreibung ist ein Indiz für mehrere
Zuständigkeiten
5.1.1 Darstellung der Statik eines Systems: Klassen und die UML
Die Trennung von Zuständigkeiten wird im
Kapitel „Gutes Design“ ausführlich behandelt!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 120
Wie findet man Klassen, Operationen und Attribute? Beispiel
Aus der Beschreibung eines Anwendungsfalls:
Ein Dauerauftrag überweist einen bestimmten Betrag in regelmäßigen
Zeitabständen von einem Girokonto auf ein Anderes.
Der Dauerauftrag gehört immer zu einem bestimmten Girokonto. Daueraufträge
können angelegt und wieder gelöscht werden.
Dauerauftrag
Betrag
Zeitabstand
Girokonto
Anderes (Girokonto)
Überweisen
Anlegen
Löschen
Klasse
Attribut in Klasse Dauerauftrag
Attribut in Klasse Dauerauftrag
Klasse!? Assoziation von Dauerauftrag? Oder Attribut?
Assoziation von Dauerauftrag? Oder Attribut?
Operation in Klasse Dauerauftrag? Oder Girokonto?
Operation in Klasse Dauerauftrag? Oder Konstruktor?
Operation in Klasse Dauerauftrag? Oder Destruktor?
5.1.1 Darstellung der Statik eines Systems: Klassen und die UML
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 121
5.1.2 Darstellung der Statik eines Systems:
Generalisierung, Spezialisierung und Vererbung
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 122
Grundidee Generalisierung
Aus der Menge der Klassen sucht man
nach Klassenpaaren wobei:
Die eine Klasse („Superklasse“) ist
ein allgemeiner Typ und die
andere Klasse („Subklasse“) ist ein
spezieller Typ, der die
Superklasse erweitert
Es besteht eine Ist-Ein-Beziehung!
Ein Objekt der Superklasse ist
durch ein Objekt der Subklasse
ersetzbar!
Unter der Subklasse ist eine
Teilmenge der Menge der
Instanzen der Superklasse
angesiedelt
5.1.2 Darstellung der Statik eines Systems: Generalisierung, Spezialisierung und Vererbung
Konto
- Kontonummer - KontoStand
+ GeldAbheben()
+ GeldEinzahlen()
Sparkonto
- Kontonummer - KontoStand - Sperrfrist
+ GeldAbheben()
+ GeldEinzahlen()
+ SetzeSperrfrist()
+ LeseSperrfrist()
Girokonto
- Kontonummer - KontoStand - ÜberziehungsLimit
+ GeldAbheben()
+ GeldEinzahlen()
+ PrüfeÜberziehungsLimit()
+ SetzeÜberziehungsLimit()
+ LeseÜberziehungsLimit()
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 123
Begriffe
Generalisierung:
„Ist-ein-Beziehung“ von der Subklasse aus gesehen.
Ein Konto ist ein (verallgemeinertes) Girokonto
Spezialisierung:
„Ist-ein-Beziehung“ von der Superklasse aus gesehen
Ein Girokonto ist ein (spezialisiertes) Konto
Die spezielle Klasse besitzt alle
Merkmale der Superklasse
Vererbung:
ist ein Konzept der Programmierung.
Die Subklasse übernimmt („erbt“)
alle Merkmale von der Superklasse
Die Subklasse besitzt alle Merkmale (Attribute, Operationen, Assoziationen,
Aggregationen) der Superklasse und noch zusätzliche Merkmale
5.1.2 Darstellung der Statik eines Systems: Generalisierung, Spezialisierung und Vererbung
Konto
- Kontonummer - KontoStand
+ GeldAbheben()
+ GeldEinzahlen()
Sparkonto
- Sperrfrist
+ SetzeSperrfrist()
+ LeseSperrfrist()
Girokonto
- ÜberziehungsLimit
+ PrüfeÜberziehungsLimit()
+ SetzeÜberziehungsLimit()
+ LeseÜberziehungsLimit()
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 124
Beispiel: Vererbungshierarchie
Pumpe, Tank, etc. als spezielle Geräte mit Zusatzeigenschaften
5.1.2 Darstellung der Statik eines Systems: Generalisierung, Spezialisierung und Vererbung
...
...
Welche Attribute besitzt eine
Membranpumpe?
Gerät
- Name - Hersteller - Gewicht - Preis
Pumpe
- Ansaugdruck - Auslassdruck - Durchflussmenge
Wärmetauscher
- Oberfläche - Behälterdurchmesser - Behälterlänge - Behälterdruck - Manteldruck
Tank
- Volumen - Druck - Durchmesser - Höhe
Zentrifugalpumpe
- Schaufeldurchmesser - ZahlDerSchaufeln - Rotationsachse
Membranpumpe
- Membranmaterial
Kolbenpumpe
- Kolbenlänge - Kolbendurchmesser - ZahlDerZylinder
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 125
Lösung: Welche Attribute besitzen die Objekte der Klassen?
5.1.2 Darstellung der Statik eines Systems: Generalisierung, Spezialisierung und Vererbung
Instanzen:
m:Membranpumpe
Name = P101 Hersteller = Simplex Gewicht = 100 kg Preis = 8.000 € Ansaugdruck = 1,1 atm Auslassdruck = 3,3 atm Durchflussrate = 300 l/h Membranmat. = Teflon
w:Wärmetauscher
Name = E302 Hersteller = Braun Gewicht = 5000 kg Preis = 30.000 € Oberfläche = 300 m Behälterdurchm. = 2 cm Behälterlänge = 6 m Behälterdruck = 15 atm Manteldruck = 1,7 atm
t:Tank
Name = T111 Hersteller = Simplex Gewicht = 10.000 kg Preis = 80.000 € Volumen = 400.000 l Druck = 1,1 atm Durchmesser = 8 m Höhe = 9 m
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 126
Sichtbarkeit
Man unterscheidet 4 verschiedene Sichtbarkeitsstufen:
Public: für alle anderen Klassen sichtbar, d. h. öffentlich
(in der UML: + )
Private: außerhalb der Klasse nicht sichtbar, auch nicht für Unterklassen
(in der UML: - )
Protected: nur für alle Unterklassen sichtbar
(in der UML: # )
Package: nur für Klassen im gleichen Paket („Ordner“) sichtbar
(in der UML: ~)
innerhalb einer Generalisierung-/Spezialisierungshierarchie
können verschiedene Stufen der Sichtbarkeit eingesetzt werden
„kennt“ jede Klasse nur ihre eigenen Attribute, Operationen und Beziehungen
und die ihrer Oberklassen – sofern diese für sie sichtbar sind
5.1.2 Darstellung der Statik eines Systems: Generalisierung, Spezialisierung und Vererbung
Wegen der Kapselung
sind Attribute in der
Regel Private oder
Protected
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 127
Regeln
In Subklassen dürfen nicht nur zusätzliche Merkmale
definiert werden, sondern auch geerbte Merkmale
überschrieben werden:
- Operationen (Reimplementierung/Polymorphie)
- Einschränkungen von Attribut-Typen auf Untertypen (int statt float)
- Einschränkungen der Typen oder Wertebereiche von Argumenten und
Rückgabewerten von Operationen
In der Subklasse können Berechnungen spezialisiert werden:
z. B. kann die Operation GeldAbheben der Klasse Girokonto zusätzlich das
Überziehungslimit prüfen
Aber:
Durch Überschreiben darf nie die Semantik des Attributs bzw.
der Operation geändert werden!
(Die Ist-ein-Beziehung darf nie verletzt werden!)
5.1.2 Darstellung der Statik eines Systems: Generalisierung, Spezialisierung und Vererbung
Wie kann man das in einer
Programmiersprache
umsetzen?
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 128
Einschränkungen bezüglich des Überschreibens der Merkmale (I)
Integritätsbedingungen einer Klasse dürfen nicht verletzt werden:
Wenn eine Klasse eine bestimmt Bedingung vorschreibt, muss diese Bedingung
in der abgeleiteten Klasse auch gelten
Beispiel: Ellipse-Kreis – Wer erbt von wem?
- Eine Ellipse ist keine Spezialisierung eines Kreises, da die Kreiseigenschaft zweier
gleichlanger Achsen durch die Ellipse verletzt würde. Ein Kreis ist jedoch eine
spezielle Ellipse, bei der die Achsen gleich lang sind.
Überschreiben von Methoden
Andere Implementierungen (z. B. Performance-Verbesserung) mit gleicher
Funktionalität sind erlaubt.
Die Schnittstelle (Name, Anzahl von Argumenten) der Operation der Superklasse
muss jedoch eingehalten werden.
Typen von Argumenten und Rückgabewerten dürfen nur eingeschränkt werden
5.1.2 Darstellung der Statik eines Systems: Generalisierung, Spezialisierung und Vererbung
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 129
Einschränkungen bezüglich des Überschreibens der Merkmale (II)
Der Typ eines Attributs der Subklasse muss vom Typ der Superklasse
isomorph umschlossen sein
z. B.: Superklasse Attribut von Typ REAL
in Subklasse Attribut von Typ INTEGER
z. B.: Superklasse Attribut von Typ der Klasse KONTO
in Subklasse Attribut von Typ einer Subklasse
von KONTO (z. B. GIROKONTO)
Der Wertebereich von Attributen darf eingeschränkt,
jedoch nicht erweitert werden
z. B.: Superklasse Mitarbeiter: Gehalt 1... 150.000,- €
Subklasse Arbeiter: Gehalt 1... 80.000,- €
5.1.2 Darstellung der Statik eines Systems: Generalisierung, Spezialisierung und Vererbung
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 130
Gleiche Eigenschaften – aber keine Generalisierung
2 Klassen haben gleiche Attribute, Operationen...
Dann kann man die gemeinsamen Merkmale in eine Superklasse extrahieren!?
Achtung! Es muss eine „ist-ein-Beziehung“ bestehen!
Die Generalisierung darf nicht zur reinen Vereinfachung der Implementierung
missbraucht werden!
1. Beispiel: Klasse Rollstuhl und Klasse Kraftfahrzeug:
Gleiche Attribute: Gewicht, Anzahl Räder, Farbe; Operation: fortbewegen
Kraftfahrzeug besitzt zusätzliches Attribut kW
Aber: trotzdem ist ein Kraftfahrzeug keine Spezialisierung eines Rollstuhls.
2. Beispiel: Klasse See und Klasse Papierformat:
Gleiche Attribute: Breite und Länge
Dieselben Attribute, aber:
es liegt keine „ist-ein-Beziehung“ vor; aus semantischer Sicht
haben die Klassen keine (sinnvolle) gemeinsame Superklasse
5.1.2 Darstellung der Statik eines Systems: Generalisierung, Spezialisierung und Vererbung
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 131
Darstellung von Randbedingungen für Vererbung/Mehrfachvererbung
Constraints
Constraints
Default: {overlapping, incomplete} – wird meist weggelassen
5.1.2 Darstellung der Statik eines Systems: Generalisierung, Spezialisierung und Vererbung
Fahrzeug
{incomplete, disjoint}
Landfahrzeug Wasserfahrzeug Luftfahrzeug
Segelboot Amphibienfahzeug Lastwagen
{complete, overlapping}
{incomplete, disjoint}
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 132
5.1.3 Darstellung der Statik eines Systems:
Spezielle Klassen
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 133
Abstrakte Klassen (I)
Eine abstrakte Klasse ist eine spezielle Art von Klasse, von der niemals
Instanzen erzeugt werden; sie ist bewusst unvollständig und bildet die Basis für
weitere Unterklassen, die Exemplare haben können
Eine abstrakte Klasse
beinhaltet mindestens eine abstrakte Operation
wird in C++ durch eine Klasse umgesetzt, die mindestens eine pure virtual
Methode enthält
kann Default-Implementierungen enthalten
Wozu ?
um davon andere Klassen abzuleiten !
Klassenhierarchien sind „Begriffshierarchien“– abstrakte Klassen definieren
Oberbegriffe für Klassenhierarchien und setzen somit Begriffe und Standards fest
Abstrakte Klassen definieren den Kern einer Klassenhierarchie,
d. h. die zentralen Gemeinsamkeiten!
5.1.3 Darstellung der Statik eines Systems: Spezielle Klassen Abstrakte Klassen werden durch das
Schlüsselwort abstract markiert – oder
auch durch Kursivschreiben des Namens!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 134
Abstrakte Klassen (II)
Klassen, die nicht abstrakt sind und Instanzen bilden können, werden
konkrete Klassen genannt.
Konkrete Klassen, die von abstrakten Klassen erben, definieren alle abstrakten
Operationen ihrer Superklassen, d. h. sie implementieren Methoden dafür.
Polymorphie
gleiche Methoden anwendbar auf unterschiedliche Objekte
(innerhalb einer Vererbungshierarchie)
dynamisches/spätes Binden
Die Verknüpfung zwischen Methodenaufruf und Methodenimplementierung findet
erst zur Laufzeit statt
(Wird nicht von allen Sprachen unterstützt!)
5.1.3 Darstellung der Statik eines Systems: Spezielle Klassen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 135
Abstrakte Klassen (Beispiel)
5.1.3 Darstellung der Statik eines Systems: Spezielle Klassen
Fahrzeug
+ fortbewegen()
{incomplete, disjoint}
Landfahrzeug Wasserfahrzeug Luftfahrzeug
Segelboot
+ fortbewegen()
Lastwagen
+ fortbewegen()
{complete, overlapping}
{incomplete, disjoint}
Amphibienfahrzeug
+ fortbewegen()
kursiv d.h. abstrakt!
Ähnliche Klassen (im Sinne der
Vererbung) mit gemeinsamer
Funktionalität!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 136
Schnittstelle: Definition
Eine Schnittstelle (Interface) ist ein Modellierungselement, das mit Signaturen
einen ausgewählten Teil eines extern sichtbaren Verhaltens beschreibt.
Es gibt bereitgestellte und benötigte Schnittstellen.
Ein Schnittstelle
legt durch Signaturen eine Schnittstelle für mehrere Klassen fest
kann nicht instanziiert werden
beinhaltet keine Implementierung
ist oft mit dem Stereotyp «interface» im Kopf gekennzeichnet
enthält in der Regel keine Attribute (darf es aber prinzipiell)
wird in C++ durch eine Klasse umgesetzt, die nur pure virtual Methoden enthält
wird realisiert, indem Klassen von der Schnittstellen ableiten und dann die
Methoden implementieren
5.1.3 Darstellung der Statik eines Systems: Spezielle Klassen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 137
Schnittstelle: Beispiel
5.1.3 Darstellung der Statik eines Systems: Spezielle Klassen
Mensch
+ fortbewegen()
Vogel
+ fortbewegen()
Segelboot
+ fortbewegen()
Bewegung
+ fortbewegen()
Interface
Eine Schnittstelle ermöglicht gleiche Methodenaufrufe für
mehrere Klassen, die sonst recht wenig gemeinsam haben!
Bewegung
+ fortbewegen()
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 138
Schnittstelle: Notation
Bereitstellung und Verwendung einer Schnittstelle
oder alternativ
5.1.3 Darstellung der Statik eines Systems: Spezielle Klassen
« realize»
bereitgestellte
Schnittstelle
(Lollipop)
benötigte
Schnittstelle
(Mund)
Schnittstelle_A
Anbieter Nutzer
Anbieter Nutzer
« use»
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 139
Schnittstelle: Zweck
Wozu?
Schnittstellen definieren einen Teil der Außenschnittstelle
d. h. eine Zugriffsmöglichkeit, die mehrere Klassen gemeinsam nutzen
Es werden Operationen (und nicht die Methoden!) definiert, wobei die Aufrufer
der Operationen zum Zeitpunkt der Definition der Schnittstelle evtl. noch nicht
bekannt sind
Beispiel
Wenn Sie unter Windows ein Programm schreiben, das sich an die
Mechanismen zur Umschaltung von Fenstern halten soll, müssen Sie bestimmte
Methoden implementieren, damit das Verschieben und Überlappen der Fenster
funktioniert (z. B. redraw)
Diese Methoden sind in einem Interface innerhalb Windows definiert – aber die
Implementierung müssen Sie machen! Windows fordert, dass Ihre Anwendung
diese Methoden bietet – d.h. das Interface realisiert.
5.1.3 Darstellung der Statik eines Systems: Spezielle Klassen
Iwindow
Myapplication Windows
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 140
Schnittstelle oder abstrakte Klasse?
Eine abstrakte Klasse, die ausschließlich abstrakte Methoden enthält,
ist identisch zu einer Schnittstelle
auch wenn die Konzepte sehr ähnlich sind, gibt es grundlegende Unterschiede
5.1.3 Darstellung der Statik eines Systems: Spezielle Klassen
Schnittstelle Abstrakte Klasse
Kern oder Rand
Schnittstellen definieren die
Außenschnittstelle einer Klasse,
d. h. lediglich eine
Zugriffsmöglichkeit, die mehrere
Klassen nutzen können
Abstrakte Klassen beschreiben den
Kern einer Vererbungshierarchie,
den alle Spezialisierungen
gemeinsam haben
Implementierung
von Methoden
kein Code erlaubt; lediglich
Festlegung von Signaturen
Code ist erlaubt; kann von erbenden
Klassen überschrieben werden
Erweiterung der
Funktionalität um
eine neue Methode
Alle Implementierungen der
Schnittstelle müssen aufgefunden
und um die neue Methode erweitert
werden
Durch Vererbung einer Default-
Implementierung können alle
erbenden Klassen leicht mit einer
Implementierung versorgt werden
Auszug aus: Rahman Mahmoodi „Abstract Class versus Interface“
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 141
Schnittstelle vs. abstrakte Klasse
5.1.3 Darstellung der Statik eines Systems: Spezielle Klassen
Verstehen Sie den Unterschied zwischen
Schnittstellen und abstrakten Klassen?
abstrakte Klasse Fahrzeug
+ fortbewegen()
Landfahrzeug
+ fortbewegen()
Wasserfahrzeug
+ fortbewegen()
Luftfahrzeug
+ fortbewegen()
Mensch
+ fortbewegen()
Vogel
+ fortbewegen()
Segelboot
+ fortbewegen()
Bewegung
+ fortbewegen()
Interface
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 142
5.1.4 Darstellung der Statik eines Systems:
Durchgängiges Beispiel
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 143
Durchgängiges Beispiel
In diesem Abschnitt werden die theoretisch eingeführten Konzepte mit Hilfe
eines Beispiels detailliert erläutert. Das Beispiel ist so gewählt, dass es durch
das gesamte Kapitel weiterentwickelt und zu einem konsistenten
objektorientierten Modell integriert wird.
Die aufeinander aufbauenden Teile des Beispiels in den einzelnen Abschnitten
sind so formuliert, dass die Ziele, die zu erreichen sind, in Form einer
Aufgabenstellung beschrieben werden. Danach folgt die fachliche Beschreibung
der zu modellierenden Inhalte.
Sie sollten die Lösung selbst erarbeiten.
Die Lösung wird aber direkt im Anschluss präsentiert.
5.1.4 Darstellung der Statik eines Systems: Durchgängiges Beispiel
Aufgabe
Analysieren Sie die nachfolgenden verbal formulierten Anforderungen an das
System „Hochschulverwaltung“:
Identifizieren Sie die Klassen des Problembereichs (Domäne) und ihre Attribute
durch Textanalyse.
Identifizieren Sie die Generalisierungs-/Spezialisierungs-Beziehungen zwischen
den Klassen.
Integrieren Sie die Klassen zu einer Vererbungshierarchie (Klassendiagramm).
Anforderungen:
In einer Hochschulverwaltung sind mehrere Personengruppen tätig. Die
Hochschule hat Angestellte, die Professoren, Labor-Ingenieure, Lehrbeauftragte,
Sekretärinnen oder Tutoren sein können. An einer Hochschule studieren
Studenten, die auch als Tutoren in einzelnen Lehrveranstaltungen eingesetzt
werden können. Jede Person hat einen Namen, Geburtsdatum und Geburtsort.
Alle Angestellten verfügen über ein Gehaltskonto. Dozenten haben einen
akademischen Titel und leisten pro Semester eine bestimmte Anzahl
Semesterwochenstunden (SWS).
Jeder Student hat eine identifizierende Matrikelnummer.
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 144
5.1.4 Darstellung der Statik eines Systems: Durchgängiges Beispiel
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 145
Lösungsweg zu den Klassen und Attributen
Zur Identifizierung der Klassenkandidaten wird zunächst eine Liste aller
Substantive der Problembeschreibung erstellt:
Hochschulverwaltung, Personengruppen, Hochschule, Angestellte, Professoren,
Labor-Ingenieure, Lehrbeauftragte, Sekretärinnen, Tutoren, Studenten, Person,
Namen, Geburtsdatum, Geburtsort, Gehaltskonto, Dozenten, Titel, Semester,
Anzahl, Semesterwochenstunden, Matrikelnummer
Hochschulverwaltung, Personengruppen, Hochschule, Angestellte, Professoren,
Labor-Ingenieure, Lehrbeauftragte, Sekretärinnen, Tutoren, Studenten, Person,
Namen, Geburtsdatum, Geburtsort, Gehaltskonto, Dozenten, Titel, Semester,
Anzahl, Semesterwochenstunden, Matrikelnummer.
Hochschulverwaltung, Personengruppen, Hochschule, Angestellte, Professoren,
Labor-Ingenieure, Lehrbeauftragte, Sekretärinnen, Tutoren, Studenten, Person,
Namen, Geburtsdatum, Geburtsort, Gehaltskonto, Dozenten, Titel, Semester,
Anzahl, Semesterwochenstunden, Matrikelnummer.
5.1.4 Darstellung der Statik eines Systems: Durchgängiges Beispiel
Dann werden überflüssige Begriffe (redundant oder irrelevant) eliminiert:
Hochschulverwaltung, Personengruppen, Hochschule, Semester, Anzahl
Folgende Begriffe werden als Klassenkandidaten eliminiert, weil sie
Eigenschaften (Attribute) anderer Substantive (Klassenkandidaten) bezeichnen:
Namen, Geburtsdatum, Geburtsort, Gehaltskonto, Titel,
Semesterwochenstunden, Matrikelnummer.
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 146
Lösung: Klassen und Attribute
Daraus ergibt sich dann folgende grobe Klassenstruktur mit Attributen
Klasse Attribute
Person Name, Geburtsdatum, Geburtsort
Student Matrikelnummer
Angestellter Gehaltskonto
Tutor
Dozent Titel, Semesterwochenstunden
Sekretärin
Labor-Ingenieur
Professor
Lehrbeauftragter
Studentischer Tutor
Selbstverständlich haben noch andere Klassen Attribute. Diese sind aber den
Dokumenten (Anforderungen), die in dieser Projektphase (Analyse) vorliegen, noch
nicht zu entnehmen. Deswegen werden sie zunächst offen gelassen und in
späteren Projektphasen ergänzt (iterativer Entwicklungsprozess).
5.1.4 Darstellung der Statik eines Systems: Durchgängiges Beispiel Alle Klassen im Singular!
Der Plural entsteht bei
Bedarf durch das
Anlegen von Objekten
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 147
Zwischenschritt: Darstellung der Klassen
5.1.4 Darstellung der Statik eines Systems: Durchgängiges Beispiel Gibt es
Generalisierungs-
beziehungen? Person
#Name : String
#GebDatum : Datum
#Geburtsort : String
Angestellter
#Gehaltskonto
+Vergütung()
Student
#Matrikelnr : Integer
Sekretärin Lab-Ing Tutor Dozent
#akademTitel : String
#SWS : Integer
+Vergütung()
studentischerTutor Professor Lehrbeauftragter
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 148
Lösung als Klassendiagramm
5.1.4 Darstellung der Statik eines Systems: Durchgängiges Beispiel
Person
#Name : String
#GebDatum : Datum
#Geburtsort : String
Angestellter
#Gehaltskonto
+Vergütung()
Student
#Matrikelnr : Integer
Sekretärin Lab-Ing Tutor Dozent
#akademTitel : String
#SWS : Integer
+Vergütung()
studentischerTutor Professor Lehrbeauftragter
{complete, overlapping}
{complete, disjoint}
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 149
Offene Punkte
Was passiert, wenn ein Student eine Tutorenstelle annimmt?
Das Objekt „Student“ müsste zerstört und ein neues Objekt der Klasse
„StudentischerTutor“ erzeugt und mit denselben Daten belegt werden.
Was passiert, wenn ein Labor-Ingenieur einen Lehrauftrag erhält?
dann stimmt das „disjoint“ nicht mehr
es gibt keine Klasse für diese Konstruktion
5.1.4 Darstellung der Statik eines Systems: Durchgängiges Beispiel
Wie können diese Sachverhalte geschickter modelliert werden?
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 150
Zwischenstand Klassen(diagramme)
Klassendiagramme – behandelte Themen
Finden von Klassen
Bestandteile einer Klasse (Attributen und Operationen)
Sichtbarkeit
Vererbung/Generalisierung/Spezialisierung
Abstrakte Klasse
Schnittstelle
Offen: welche Beziehungen gibt es außer der Vererbung zwischen Klassen?
5.1.1 Darstellung der Statik eines Systems: Klassen und die UML
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 151
5.1.5 Darstellung der Statik eines Systems:
Assoziationen
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 152
Grundidee
Beobachtung:
Zwischen Objekten gibt es häufig Beziehungen – die Objekte „kennen sich“
Viele der Beziehungen gelten für alle Objekte einer Klasse
Idee: Abstrahiere gleichartige Beziehungen zwischen Objekten
zu Beziehungen zwischen Klassen!
(analog zur Abstraktion von gleichartigen Objekten zu Klassen)
„Assoziationen“
stellen logische Beziehungen zwischen Klassen dar;
die Klassen „kennen sich“
sind Verknüpfungsmöglichkeiten zwischen Objekten dieser Klassen
definieren ebenso mögliche Kommunikationswege zwischen Objekten der
Klassen.
5.1.5 Darstellung der Statik eines Systems: Assoziationen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 153
Notation am Beispiel
1 Person (als Arbeitnehmer) arbeitet für 0..n Firmen (als Arbeitgeber)
1 Firma (als Arbeitgeber) beschäftigt 1..n Personen (als Arbeitnehmer)
1 Person (als Vorgesetzter) ist vorgesetzt für 0..n Personen (als Untergebene)
1 Person (als Untergebener) hat 0..1 Personen als Vorgesetzten
5.1.5 Darstellung der Statik eines Systems: Assoziationen
Firma Person
*
arbeitet für
1…*
-Vorgesetzter
ist vorgesetzt
-Untergebener *
0…1
Leserichtung Name der Assoziation Multiplizität
Rolle
W. Orker : Person
h_da : Firma
Employer Inc :
Firma B. Igboss :
Person
MoD : Firma
I. N. Dianer :
Person
T. Unix : Person
P. Rof : Person
A. R. Beitslos :
Person
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 154
Interpretation des Beispiels mit Objekten
Betrachten Sie die folgenden Objekte
ist
vorgesetzt
arbeitet für
ist
vorgesetzt
Person ohne Vorgesetzten
und ohne Firma
2 Personen bei der gleichen
Firma ohne Beziehung
(Assoziation) untereinander
W. Orker ist Vorgesetzter
von I. N. Dianer, aber I. N.
Dianer arbeitet gar nicht für
die gleiche Firma.
Vom Modell her ok, wenn
auch fachlich eher falsch.
(Lösung später durch
„Constraints“)
Person ohne Vorgesetzten
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 155
Navigationsrichtungen bei Assoziationen
Bei der Modellierung des dynamischen Verhaltens (Entwurf der Kommunikation
zwischen Klassen) wird festgestellt, in welche Richtung eine
Assoziationsbeziehung durchlaufen wird.
Diese Navigationsrichtung kann angegeben werden (offene Pfeilspitze)
Die Navigationsrichtung gibt beim späteren Programmentwurf Auskunft darüber,
in welchen Klassen Verweise auf Objekte anderer Klassen angelegt werden
müssen.
Beispiel:
Ein Auftrag muss seine assoziierten Artikel kennen
(z. B. Gesamtsumme berechnen, Nachschauen was disponiert werden muss).
Es ist noch nicht festgelegt, ob ein Artikel wissen muss in welchen Aufträgen er
bestellt wurde.
5.1.5 Darstellung der Statik eines Systems: Assoziationen
unspezifiziert navigierbar
Nicht mit der
Leserichtung
verwechseln!
Auftrag
1…*
Artikel
*
Klasse2
Klasse2
Klasse2
Klasse2
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 156
Notation für Navigationsrichtungen
In UML 1.x steht die Assoziation in Linienform (ohne Pfeilspitzen)
für eine bidirektionale Beziehung
es gab keine Möglichkeit auszudrücken, dass man sich über die Richtung
„noch keine Gedanken gemacht“ hat
In UML 2.x:
getrennte Notation für „navigierbar“ und „unspezifiziert“ (default)
UML 2! geändert ggü. UML 1.x
beidseitig unspezifiziert:
einseitig navigierbar:
beidseitig navigierbar:
nicht navigierbar
eins. nicht navigierbar:
unspezifiziert
5.1.5 Darstellung der Statik eines Systems: Assoziationen
navigierbar Klasse1
Klasse1
Klasse1
Klasse1
X
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 157
Multiplizität
Eine Assoziation sagt aus, dass sich Objekte der beteiligten Klassen kennen
Die Multiplizität spezifiziert, wie viele Objekte ein bestimmtes Objekt kennen
kann
Beim Lesen einer Assoziation wird immer die Multiplizität am
Ausgangspunkt der Beziehung als „1“ gelesen!
1 genau 1
0..2 0 bis 2
* 0 bis viele
3..* 3 bis viele
5.1.5 Darstellung der Statik eines Systems: Assoziationen
m Ein Objekt x der Klasse X kennt m Objekte der Klasse Y; Ein Objekt y der Klasse Y kennt n Objekte der Klasse X
n
Klasse
Y
Klasse
Klasse
Klasse
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 158
Wie findet man Assoziationen?
a) Dokumentenanalyse
Verben in Dokumenten (Use Cases, Dokumentationen, Spezifikationen
Interview-Protokoll etc.)
Aber: Nicht alle Assoziationen sind für den zu modellierenden Problembereich
wichtig!
b) Weitere Hinweise auf Assoziationen:
Verwaltung von Dingen (Firma hat Kunden, Abteilung gliedert sich in Gruppen)
Besitz (Motor besitzt Benzinpumpe, Auftrag besteht aus Positionen)
Kommunikation zwischen Objekten
c) In späteren Schritten:
Bei dynamischer Modellierung wird die Kommunikation zwischen Klassen
dargestellt:
- Kommunikation läuft über vorhandene Assoziation – oder auch nicht
Falls nicht oft zusätzliche Assoziation !
5.1.5 Darstellung der Statik eines Systems: Assoziationen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 159
Modellierung
Regeln:
Verbindungen zwischen Objekten stets als Assoziation modellieren
(und nicht als Zeiger-Attribut)!
- übersichtliche Darstellung
- das Modell bleibt unabhängig von den Fähigkeiten der Programmiersprache
Voneinander unabhängige Beziehungen können (und sollten) durch mehrere
Assoziationen (mit gleicher Quelle und gleichem Ziel) ausgedrückt werden
- durch Rollen ausdrücken, warum es mehrere Beziehungen gibt
Multiplizität sollte angegeben werden
- muss (spätestens) im Design angegeben werden, damit die Coderahmen mit
entsprechenden Attributen generiert werden können
Implementierung erfolgt erst später (auf niedrigerer Abstraktionsebene)
Leserichtung immer angeben, wenn sie von links → rechts bzw. oben → unten
abweicht
5.1.5 Darstellung der Statik eines Systems: Assoziationen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 160
Übung „Linien und Schnittpunkte“
Entwickeln Sie ein Klassendiagramm zur Darstellung von Linien, die sich in
Schnittpunkten schneiden können.
L1
L2
L3
L4L5
P1
P2
P3
5.1.5 Darstellung der Statik eines Systems: Assoziationen
Schnittpunkt
-Name
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 161
„Linien und Schnittpunkte“: Analyse des Problems
1) Klassen und Attribute durch „Suchen der Substantive“
2) Erweiterung um Assoziationen
schneidet
5.1.5 Darstellung der Statik eines Systems: Assoziationen
Schnittpunkt
-Name
Linie
-Name
Linie
-Name
L1 : Linie
L2 : Linie
L3 : Linie
L4 : Linie
L5 : Linie
P3 :
Schnittpunkt
P1 :
Schnittpunkt
P2 :
Schnittpunkt
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 162
Assoziationen (Vorarbeit durch Betrachtung der Objekte) Objektdiagramm
5.1.5 Darstellung der Statik eines Systems: Assoziationen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 163
? ?
? ?
„Linien und Schnittpunkte“: Lösung als Klassendiagramm
3) Multiplizitäten aus dem Beispiel extrahieren:
Die Linien und Schnittpunkte sind Exemplare der Klassen „Linie“ und
„Schnittpunkt“. Die Linien L1, L3 und L4 besitzen jeweils zwei Schnittpunkte mit
anderen Linien (P1,P3 bzw. P1,P2 bzw. P3,P2), L2 hat einen Schnittpunkt, L5
hat keinen Schnittpunkt. P2 und P3 haben 2 Linien, Schnittpunkt P1 hat 3 Linien.
5.1.5 Darstellung der Statik eines Systems: Assoziationen
schneidet
schneidet * 2..*
4) Abstraktion:
2 Linien können aufeinander liegen (haben unendlich viele Schnittpunkte)
beliebig viele Linien können durch einen Schnittpunkt gehen
0..2 2..3 Linie
-Name
Linie
-Name
Schnittpunkt
-Name
Schnittpunkt
-Name
Employer Inc :
Firma
W. Orker :
Person
B. Igboss :
Person
MoD : Firma
I. N. Dianer :
Person
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 164
Ein Problem
Die bisherige Modellierung von Person und Firma soll so erweitert werden, dass
ein Gehalt verwaltet und Urlaub beantragt werden kann
Betrachten Sie das Attribut Gehalt und die Methode Urlaub_beantragen()
Wie und wo sollten diese Elemente modelliert werden?
Denken Sie daran, dass eine Person in mehreren Firmen arbeiten kann!
ist
vorgesetzt
arbeitet für
ist
vorgesetzt Gehalt
Urlaub_beantragen()
Diese Attribute und Methoden gehören jeweils zu der
Assoziation zwischen einer Firma und einer Person!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 165
Assoziationsklassen
Es gibt Attribute und Operationen, die vom Vorhandensein einer Assoziation
abhängig sind. In anderem Kontext sind sie nicht nötig.
- Person bekommt das Gehalt nur/kann nur dann Urlaub beantragen, wenn sie
angestellt ist und zwar von der Firma, bei der sie angestellt ist.
- Gehalt und Urlaub_beantragen sind Merkmale der Assoziation.
auch Assoziationen können Merkmale, d. h. Attribute und Operationen besitzen.
„Assoziationsobjekt“
Die Merkmale existieren für jede einzelne aufgebaute Verbindung zwischen zwei
Objekten dieser Klassen genau einmal
Abstraktion zur „Assoziationsklasse“ im Klassendiagramm
5.1.5 Darstellung der Statik eines Systems: Assoziationen
Firma
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 166
Darstellung einer Assoziationsklasse
Bemerkung:
Auch wenn jede Person in genau einer Firma arbeiten würde, gehören Gehalt
und Urlaub_beantragen semantisch zur Assoziation
5.1.5 Darstellung der Statik eines Systems: Assoziationen
Arbeitnehmer Arbeitgeber
* 1..* Anstellung
*
0..1
Vorgesetzter
ist_ vorgesetzt
Untergebener
Assoziationsklasse
Anstellung
-Gehalt
+Urlaub_beantragen()
Person
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 167
Durchgängiges Beispiel – Fortsetzung
Die bisher modellierte Vererbungshierarchie ist korrekt, jedoch bezüglich
Flexibilität und Wiederverwendung ungünstig modelliert:
Wird ein Objekt der Klasse Student erzeugt, so müsste dieses Objekt seine
Klasse wechseln, sobald der Student Tutor wird. Nach der bisher modellierten
Hierarchie müsste das Objekt zerstört und ein neues Objekt der Klasse
StudentischerTutor erzeugt und mit denselben Daten belegt werden.
Der Unterschied zwischen den Personengruppen (im Hinblick auf ein
Hochschulverwaltungssystem) besteht in der Art der Vergütung.
Die Vergütung taucht aber nur „versteckt“ als Methode auf.
Nachdem wir Assoziationen und Assoziationsklassen kennengelernt haben,
können wir durch ein geschicktes Design der bisherigen Klassenhierarchie
dieses Problem beseitigen.
5.1.5 Darstellung der Statik eines Systems: Assoziationen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 168
Durchgängiges Beispiel (Lösung mit Assoziationen)
Die Klassen (Sekretärin etc.) sind in diesem Diagramm nicht dargestellt, weil es hier um die Aufteilung zwischen Person und Gehalt geht!
Es gibt Personen, Vergütungen – und
Beziehungen dazwischen
5.1.5 Darstellung der Statik eines Systems: Assoziationen
Person
#Name : String
#GebDatum : Datum
#Geburtsort : String
Gehaltskonto
FH_Person
+Vergütung()
Gehaltskonto
Vergütung
+Vergütung()
Tutor
Vergütung
+Vergütung()
BAT
+Vergütung()
Lehrbeauftragten
Vergütung
+Vergütung()
Professor
Vergütung
+Vergütung()
Student
#Matrikelnr : Integer
Dozent
#akademTitel : String
#SWS : Integer
0..1 *
abstract
Polygon Punkt
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 169
Randbedingungen für Assoziationen (Constraints)
Zu Assoziationen können Randbedingungen hinzudefiniert werden.
Eine Randbedingung ist eine zusätzliche Information zum vorhandenen
Modellelement, um es konsistent zu machen.
Constraints geben Bedingungen für die Implementierungsphase.
Beispiel 1:
Bei einem Polygon kommt es auf die Reihenfolge der Punkte an
5.1.5 Darstellung der Statik eines Systems: Assoziationen
wird_definiert
3..* 0..1 {ordered}
Constraint
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 170
Randbedingungen für Assoziationen (Beispiel)
Randbedingungen mit langem Text können als Kommentar angegeben werden
z. B.: Der Vorgesetzte und dessen untergebener Arbeitnehmer müssen bei
demselben Arbeitgeber beschäftigt sein.
5.1.5 Darstellung der Statik eines Systems: Assoziationen
{ Person.Arbeitgeber = Person.Vorgesetzter.Arbeitgeber }
Firma Arbeitnehmer Arbeitgeber
* 1..* Anstellung
*
0..1
Vorgesetzter
ist_ vorgesetzt
Untergebener
Anstellung
-Gehalt
+Urlaub_beantragen()
Person
Randbedingung formuliert in OCL (Object Constraint Language)
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 171
Durchgängiges Beispiel (mit Constraints)
Unsere bereits veränderte Vererbungshierarchie des ersten
Klassenhierarchieentwurfs kann nun durch die Verwendung von
selbstdefinierten Constraints vollständig und widerspruchsfrei modelliert werden.
Es ist klar, dass nicht jedes Objekt willkürlich mit jedem Gehalt kombiniert
werden kann. Durch ein entsprechendes Constraint sind nun (gemäß der
Aufgabe eines Modells) alle Regeln des Anwendungsbereichs widergespiegelt
und hinreichende Vorgaben für die Implementierung gegeben.
5.1.5 Darstellung der Statik eines Systems: Assoziationen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 172
Durchgängiges Beispiel (Lösung mit Constraints)
5.1.5 Darstellung der Statik eines Systems: Assoziationen
Person
#Name : String
#GebDatum : Datum
#Geburtsort : String
Gehaltskonto
FH_Person
+Vergütung()
Gehaltskonto
Vergütung
+Vergütung()
Tutor
Vergütung
+Vergütung()
BAT
+Vergütung()
Lehrbeauftragten
Vergütung
+Vergütung()
Professor
Vergütung
+Vergütung()
Student
#Matrikelnr : Integer
Dozent
#akademTitel : String
#SWS : Integer
0..1 *
typeOf (Student.Vergütungsberechnung) =
Tutorvergütung;
typeOf (FH_Person.Vergütungsberechnung) = BAT;
typeOf (Dozent.Vergütungsberechnung)
(ProfessorVergütung, LehrbeauftragtenVergütung)
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 173
Durchgängiges Beispiel
Aufgabe:
Erweitern Sie das bisherige Klassendiagramm des Hochschulverwaltungs-
systems so, dass es die folgenden Klassen und Assoziationen integriert.
Analysieren Sie zur Identifikation der Klassen und Assoziationen den Text.
Bestimmen Sie die Multiplizitäten der Assoziationen und benennen Sie die
Assoziationen und/oder die Rollen, die die beteiligten Klassen in einer Asso-
ziation spielen, wenn dadurch die Verständlichkeit des Modells verbessert wird.
Anforderungen:
Die Dozenten und die Studenten gehören einem Fachbereich an.
Studenten nehmen an Lehrveranstaltungen teil, welche die Dozenten halten
Lehrveranstaltungen werden mit einem benoteten Leistungsnachweis
abgeschlossen. Besteht ein Student nicht, kann er die Klausur wiederholen
Studenten werden während der Masterarbeit von einem Professor betreut.
Thema und Abgabetermin der Masterarbeit sind zu erfassen. Studenten können
natürlich eine Masterarbeit auch unvollendet abbrechen.
Lehrveranstaltungen im Semester können von Tutoren mitbetreut werden.
5.1.5 Darstellung der Statik eines Systems: Assoziationen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 174
Durchgängiges Beispiel (überarbeitet)
5.1.5 Darstellung der Statik eines Systems: Assoziationen
Fachbereich
Student
Masterarbeit
-Thema -Abgabe
+abbrechen()
Leistung
-Note
+wiederholen()
Lehrveranstaltung
-Semester -Raumnummer -Kurs
Professor
Sekretärin
Angestellter Dozent
Lab-Ing
Tutor
gehört_FB_an Lehrkörper
* 1
*
1
*
gehört_FB_an
* 0…1
Masterstudent Betreuer
1
*
hält_Veranstaltung
Referent
*
* Betreuer
betreut_Veranstaltung
*
besucht_Veranstaltung
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 175
Durchgängiges Beispiel: Zusatzfragen
Sie sitzen gerade in einer Vorlesung. Wo ist die Beziehung zu Ihrem Professor?
Was verändert sich, wenn 2 Professoren eine Masterarbeit betreuen?
Was verändert sich, wenn wir darstellen wollen, dass Lehrbeauftragte zu
mehreren Fachbereichen gehören können, Professoren aber nur zu einem?
In Lehrveranstaltungen werden Werte von Attributen redundant gespeichert (In
der OOAD-LV von Herrn Weber, als auch in der OOAD-LV von Herrn Hahn
stehen Titel und ECTS). Wie könnte man das vermeiden?
5.1.5 Darstellung der Statik eines Systems: Assoziationen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 176
Spezielle Assoziationen: Aggregation und Komposition
Aggregation/Komposition bedeutet „Teil-von-Beziehung“ (oder „besteht-aus-
Beziehung“) d. h. ein Objekt ist Bestandteil eines anderen
5.1.5 Darstellung der Statik eines Systems: Assoziationen
Aggregation und Komposition sind
transitiv: A ist Teil von B, B ist Teil von C. Somit ist A Teil von C
asymmetrisch: A ist Teil von B, aber B ist nicht Teil von A
Computersystem 1 Monitor
Netzwerkkarte Motherboard Festplatte
0…1
1…* 1 1…*
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 177
Spezielle Assoziationen: Aggregation (Shared Aggregation)
Aggregation:
spezifiziert Referenz auf das aggregierte Objekt
Aggregiertes Objekt ist zwar Bestandteil, existiert aber unabhängig vom
aggregierenden Objekt
„shared“ Aggregation (kann zu mehreren Objekten gleichzeitig gehören,
d. h. die Multiplizität darf > 1 sein)
Symbol: leere Raute
5.1.5 Darstellung der Statik eines Systems: Assoziationen
Computersystem
Monitor
1
0…1
Vorlesung
Studierender
0...*
1…*
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 178
Spezielle Assoziationen: Komposition (Composite Aggregation)
Komposition
Teile eines Ganzen
- werden beim Zerstören des „Ganzes-Objektes“ automatisch (kaskadierend) zerstört
- dürfen nicht Teil anderer Kompositionen sein
- dürfen nur von Operationen der „Ganzes-Klasse“ entfernt oder ersetzt werden
Komposition (=„unshared“ Aggregation)
Symbol: ausgefüllte Raute
5.1.5 Darstellung der Statik eines Systems: Assoziationen
Computersystem
Motherboard
1
1
Vorlesung
Studierender
1
1…*
Methode
lokaleVariable
1
1…*
Kann weggelassen werden, da bei
Composite Aggregation immer 1
Was würde das
bedeuten?
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 179
Durchgängiges Beispiel mit Aggregationen
Aufgabe:
Erweitern Sie das Klassendiagramm der Hochschulverwaltung um die
nachfolgenden Inhalte
Anforderungen:
Ein Fachbereich kann eine Bibliothek und mehrere Labore besitzen, in denen
Laboringenieure arbeiten
Jeder Fachbereich beschäftigt viele Angestellte
Die Laborräume sind zur Vermeidung von Diebstählen mit Sicherheitstüren
ausgestattet
Labor-Ingenieure arbeiten in einem bestimmten Labor
5.1.5 Darstellung der Statik eines Systems: Assoziationen
Durchgängiges Beispiel mit Aggregationen (Lösung)
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 180
Bibliothek Labor Sicherheitstür
0…1
1…*
* *
arbeitet_in_Labor
1
beschäftigt
1 *
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 181
Durchgängiges Beispiel (Erklärung)
Labors und eine Bibliothek sind Teile eines Fachbereichs, die aber jederzeit
einem anderen Fachbereich zugewiesen werden können. Daher ist die Teil-von-
Beziehung eine Aggregation (shared Aggregation)
Eine Sicherheitstür ist fester Bestandteil des Labors und ist deswegen eine
Komposition (unshared Aggregation)
5.1.5 Darstellung der Statik eines Systems: Assoziationen
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 182
5.1.6 Darstellung der Statik eines Systems:
Zusammenfassung
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 183
Schritte zum Entwickeln von Klassendiagrammen
1. Klassen(kandidaten) finden
Substantive bestimmen
überflüssige Begriffe rausfiltern
Attribute identifizieren
Methoden über Verben suchen
2. Vererbungsbeziehungen suchen
Ähnliche Klassen identifizieren (Aber: „Ist-ein-Regel“ beachten!)
Evtl. Schnittstellen durch abstrakte Klasse und Vererbung definieren
3. Assoziationen zwischen Klassen bestimmen
„Kennt“-Beziehungen: normale Assoziation
„Besteht aus“-Beziehung: Aggregation bzw. Komposition
evtl. Leserichtung und Rollen angeben
Objekte, deren Existenz an einer Assoziation hängt: Assoziationsklasse
4. Multiplizitäten und Navigationsrichtungen eintragen
5.1.6 Darstellung der Statik eines Systems: Zusammenfassung
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 184
Wert von Klassendiagrammen
Klassendiagramme sind eines der wichtigsten Beschreibungsmittel in der
Modellierung
Für ein (komplexes) System werden viele Klassendiagramme erstellt
Tipps:
- niemals versuchen, gleich alles perfekt zu machen;
auch Klassendiagramme werden iterativ entwickelt
- Details wie Navigationsrichtungen und Multiplizität erst dann eintragen,
wenn die Modellierung hinreichend stabil scheint
- Bei der Modellierung an die Systemgrenze denken!
Nur das System modellieren – nicht die komplette Außenwelt!
- immer nur einen Aspekt auf einem Diagramm darstellen;
wenn das Diagramm nicht mehr auf eine Seite passt – aufteilen!
- die Begriffe für alle Elemente mit großer Sorgfalt wählen
- Assoziationen so konkret wie möglich spezifizieren
- keine unverständlichen Pseudoprogramme in Constraints schreiben
– es geht (auch) um Verständlichkeit
- ein Pointer als Attribut einer Klasse ist meist eine falsch modellierte Assoziation
5.1.6 Darstellung der Statik eines Systems: Zusammenfassung
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 185
Zusammenfassung Klassendiagramme
Klassendiagramme enthalten
Klassen mit Attributen und Methoden
Generalisierung/Spezialisierung
Abstrakte Klasse/Schnittstelle
Constraints
Assoziationen
- (normale) Assoziationen: einfache, mehrfache
- Aggregation
- Komposition
Navigationsrichtung
Assoziationsklassen
Das sind die Elemente im „Modellierungs-Baukasten“
– aber wie werden die in Code umgesetzt?
5.1.1 Darstellung der Statik eines Systems: Klassen und die UML
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 186
5.2 Umsetzung von UML-Klassen in C++
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 187
class CTaschenrechner { private:
CSpeicher m_cSpeicher; private:
CEinAusgabe m_cEinAusgabe; private:
CProzessor m_cProzessor; public:
CTaschenrechner(void); public:
void benutze();
};
Das Grundproblem
5.2 Umsetzung von UML-Klassen in C++
OOD - Modell Abbildung Coderahmen in bestimmter
Programmiersprache (hier C++)
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 188
Umsetzung von Klassen und Assoziationen
Umsetzung von Attributen, Methoden
Diese Konstrukte werden von OO-Sprachen direkt angeboten und können 1:1
umgesetzt werden
Spezialisierung/Generalisierung
Vererbung
Schnittstellen
Klassen mit ausschließlich pure virtual Methoden
Umsetzung von Assoziationen
Realisierung über Attribute mit Referenz(en) auf ein anderes Objekt
- Multiplizität = 0..1, 1..1 ein Zeiger
- Multiplizität = 0..*, 1..* Verweis auf eine Menge von Objekten über Zeiger
(Container-Klasse, z. B. Menge, Liste, Bäume,
statische und dynamische Arrays, Hash-Tabellen)
- Name des Attributes = Rollenname/Name der assoziierten Klasse
5.2 Umsetzung von UML-Klassen in C++
Automatische Umsetzung durch Code(rahmen)generator ist möglich!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 189
5.2 Umsetzung von UML-Klassen in C++
...und wie sieht der C++ Code aus?
generierbar generierbar
Assoziationen als Klassenattribute
Umsetzung Dozent und Veranstaltung aus unserem Beispiel
Dozent
1
Veranstaltung Referent
hält_Veranstaltung *
Veranstaltung
-Referent: Dozent* -name: string
+getReferent(): Dozent*
Dozent
-gehaltene_Veranstaltung: Liste <Veranstaltung*>
+getVeranstaltung(name: string): Veranstaltung*
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 190
Assoziationen als Klassenattribute in C++
5.2 Umsetzung von UML-Klassen in C++
// Spezifikation von Veranstaltung
class Veranstaltung {
protected:
Dozent* Referent;
public:
Veranstaltung* getVeranstaltung (string name) {
...
}
// Spezifikation von Dozent
class Dozent {
protected:
Liste<Veranstaltung*> gehaltene_Veranstaltung;
public:
...
}
Umsetzung folgender Assoziation?
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 191
5.2 Umsetzung von UML-Klassen in C++
Arbeitnehmer Arbeitgeber
* 1...* arbeitet _für FirmaA : Firma Maier : Person
Müller : Person FirmaB : Firma
Firma Person
Firma
-Arbeitnehmer: Liste<Person*>
+getArbeitnehmer(name: string): Person*
Person
-Arbeitgeber: Liste <Firma*>
+getArbeitgeber(name: string): Firma*
a kennt 1..n Objekte der Klasse B und
daran „hängt“ je ein Objekt der Klasse C
a wählt ein Objekt der Klasse B aus und
erhält dazu ein Objekt c
A
Umsetzung von Assoziationsklassen
a kennt 1..n Objekte der Klasse C und
daran hängt je ein Objekt der Klasse B
a durchsucht die Objekte der Klasse C
bis das gesuchte b gefunden ist
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 192
5.2 Umsetzung von UML-Klassen in C++
* 1..*
* 1..*
1 1
A B B
C C
Firma Person
Beispiel: Assoziationsklassen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 193
5.2 Umsetzung von UML-Klassen in C++
Arbeitnehmer Arbeitgeber
* 1..* arbeitet _für
* 1..*
1 1
-1.
-2.
Firma Person
Anstellung
Anstellung
-Gehalt
-Urlaub_von_bis
+Urlaub_beantragen()
Firma
-Arbeitnehmer: Liste <Anstellung*>
+getAnstellung(p: Person*): Anstellung*
Anstellung
-Arbeitgeber: Firma* -Arbeitnehmer: Person*
+getArbeitgeber(): Firma* +getArbeitnehmer(): Person*
Person
-Arbeitgeber: Liste <Anstellung*>
+getAnstellung(f: Firma): Anstellung*
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 194
Beispiel: Assoziationsklassen (I)
class Anstellung {
protected:
Firma* m_Arbeitgeber; // Referenz auf assoziiertes Objekt
Person* m_Arbeitnehmer; // Referenz auf assoziiertes Objekt
unsigned int Gehalt; // Attribut der Assoziation
string urlaub_von_bis; // Attribut der Assoziation ...
public:
virtual Person* getArbeitnehmer (void) const{ return (m_Arbeitnehmer); }
virtual Anstellung* setArbeitnehmer (const Person* einArbeitnehmer){
m_Arbeitnehmer = einArbeitnehmer;
return (this);
}
virtual Firma* getArbeitgeber (void) const{ return (m_Arbeitgeber);}
virtual Anstellung* setArbeitgeber (const Firma* einArbeitgeber){
m_Arbeitgeber = einArbeitgeber;
return (this);
}
virtual void Urlaub_beantragen (string anfang_ende){
urlaub_von_bis = anfang_ende;
}; ... } // class Anstellung
5.2 Umsetzung von UML-Klassen in C++
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 195
Beispiel: Assoziationsklassen (II)
class Person {
protected:
Liste<*Anstellung> m_Arbeitgeber;
public:
Anstellung* getAnstellung (const Firma* dieFirma) const {
// Navigieren auf dem Container gemäß gegebener Datenstruktur (Liste). // Liefert die Referenz auf das Objekt der Assoziationsklasse, das die // Referenz auf die übergebene Firma hält. So ist das Setzen und Lesen von // Attributen bzw. das Ausführen von Methoden der Assoziation möglich.
}
virtual unsigned getAnstellungsGehalt (const Firma* derArbeitgeber) const {
// Zugriff auf ein Assoziationsklassen-Attribut:
return (getAnstellung (derArbeitgeber)-> getGehalt());
}
void do_Anstellung_Urlaub_beantragen (const Firma* derArbeitgeber, string anfang_ende) {
// Ausführen einer Assoziationsklassen-Methode:
getAnstellung(derArbeitgeber)->Urlaub_beantragen(string anfang_ende);
} ... } // class Person
5.2 Umsetzung von UML-Klassen in C++
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 196
Umsetzung von Aggregation und Komposition
Normale Aggregation (Shared Aggregation)
Attribut vom Typ Zeiger auf das aggregierte Objekt
(d. h. genau wie eine Assoziation)
Komposition (Unshared Aggregation)
Attribut vom Typ der Klasse selbst
(Die Klasse ist im aggregierenden Objekt integriert)
5.2 Umsetzung von UML-Klassen in C++
Stirbt das Ganze, leben die Teile weiter!
Stirbt das Ganze, sterben auch die Teile!
Computersystem 1 Monitor
Netzwerkkarte Motherboard Festplatte
0…1
1…* 1 1…*
Computersystem
-m_Motherboard: Motherboard
+getMotherboard(): Motherboard
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 197
Komposition
Umsetzung der Komposition zwischen Computersystem und Motherboard aus
unserem Beispiel
5.2 Umsetzung von UML-Klassen in C++
1
...und wie sieht der C++Code aus?
Computersystem Motherboard
Motherboard
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 198
Beispiel: Komposition als Klassenattribute in C++
// Spezifikation von Computersystem
class Computersystem {
protected:
Motherboard m_Motherboard;
public:
Motherboard getMotherboard();
...
}
// Spezifikation von Motherboard
class Motherboard {
protected:
...
public:
...
}
5.2 Umsetzung von UML-Klassen in C++
kein Pointer, sondern echte Instanz der Klasse!
Frage: Was ändert sich (im Diagramm und im Code),
wenn es mehrere Motherboards geben darf?
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 199
Kontrollfragen
Wissen Sie jetzt, wie die UML Konstrukte auf C++ abgebildet werden?
Klassen mit Attributen und Methoden
Generalisierung/Spezialisierung
Abstrakte Klasse/Schnittstelle
Assoziationen
Aggregation
Komposition
Navigationsrichtung
Assoziationsklassen
Sie können jetzt ein UML-Klassendiagramm in C++-Code überführen!?
5.2 Umsetzung von UML-Klassen in C++
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 200
5.3 Darstellung der Dynamik eines Systems
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 201
Grenzen von Klassendiagrammen
Klassendiagramme liefern einen Überblick über die Bestand-
teile des Systems und deren Beziehungen untereinander
Klassen mit Attributen, Methoden und Spezifikation beschreiben die
(potenziellen) Fähigkeiten und die Verantwortlichkeiten der Bestandteile
Assoziationen stellen logische Beziehungen zwischen Klassen dar und zeigen
(potenzielle) Kommunikations- und Verknüpfungsmöglichkeiten zwischen
Objekten der Klassen
Beschreibung der Statik des Systems: „Strukturdiagramme“
sie liefern keine Information darüber in welcher Art und Reihenfolge Objekte und
Methoden interagieren müssen, um eine geforderte Funktionalität zu liefern!
5.3 Darstellung der Dynamik eines Systems
Ergänze die Beschreibung des Systems um „Verhaltensdiagramme“
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 202
Lernziele
Sie sollen in diesem Kapitel verstehen,
Was man mit Sequenzdiagrammen ausdrücken kann
Wie man mit Sequenzdiagrammen Programmabläufe ausdrückt
Worauf man bei Sequenzdiagrammen achten muss
Welche Modellierungselemente die UML dafür bietet
Was man mit Kommunikationsdiagrammen ausdrücken kann
Wie Zustandsdiagramme funktionieren
Wozu Zustandsdiagramme eingesetzt werden
Hinterher können Sie die Dynamik eines Systems in Diagrammen darstellen!
5.3 Darstellung der Dynamik eines Systems
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 203
Grundidee
Wie stellt man die Dynamik eines Systems dar?
„spiele“ mit Instanzen der (bereits gefundenen) Klassen
die Methodenaufrufe durch, die erforderlich sind,
um eine geforderte Funktionalität zu liefern
Beschreibe
die Reihenfolge der Interaktionen beim Ablauf eines Anwendungsfalls
die (prinzipiellen) Aufrufe im Code
die Interaktion von Objekten
Zustände und Übergänge von Objekten
die Erzeugung und Zerstörung von Objekten
Aus lauffähigem Code kann die Sequenz der Methodenaufrufe leicht extrahiert
werden, indem man mit dem Debugger die Methodenaufrufe verfolgt!
Wir machen es jetzt andersrum – und entwerfen so die Sequenz der Aufrufe!
5.3 Darstellung der Dynamik eines Systems
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 204
5.3.1 Darstellung der Dynamik eines Systems:
Sequenzdiagramme
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 205
Notation am Beispiel
Betrachten Sie ein Kino-
Reservierungssystem:
Es gibt Aktoren, Objekte und
verschiedene Aufrufe:
Nachrichten, Aufrufe und Returns
Objekte werden in Bahnen
nebeneinander dargestellt
Die Aktivität eines Objekts wird durch
einen Balken symbolisiert
Nur ein aktiviertes Objekt kann Aufrufe
machen!
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
Return (optional)
Objekt
Aktor
Steuerungsfokus (Aktivierungsbalken)
(rekursiver)Aufruf
Nachricht
CineMinn :
TicketSystem : KinoFan
1: in("StarteVerkauf")
2: SaalplanAusgeben()
3: out(Saalplan)
4: in(Reihe, Sitz)
5: Verkaufen(Reihe, Platz)
6: istVerkauft(Reihe, Platz)
7: out("Bitte bezahlen Sie")
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 206
Notationen für synchrone Aufrufe und asynchrone Nachrichten
Synchron:
Der Sender wartet, bis der Empfänger die Nachricht empfangen und vollständig
abgearbeitet hat. Erst dann arbeitet er weiter.
Der Aktivierungsbalken dauert genau vom Aufruf bis zum Return
Asynchron:
Sender setzt Nachricht ab und arbeitet sofort weiter, ohne auf den Empfänger zu
warten. Der Empfänger arbeitet parallel zum Sender die Nachricht ab.
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
synchroner Aufruf
Rückgabewert
asynchrone Nachricht
Aufruf einer Operation
Ablauf der Methode
Return der Methode
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 207
Durchgängiges Beispiel
Aufgabe
Wir formulieren nun ein Sequenzdiagramm zu einem konkreten Anwendungsfall:
Anwendungsfall „Student immatrikulieren“
Ein Sachbearbeiter der Hochschule erfasst am Bildschirm neue Studenten.
Wurde ein Student bisher noch nicht erfasst, so wird ein neuer Eintrag angelegt
und der Sachbearbeiter erhält eine Rückmeldung über den Erfolg der Erfassung.
Die Kommunikation des Systems „Hochschulverwaltung“ mit der Außenwelt
(Sachbearbeiter) soll über Bildschirmmasken erfolgen.
Es wurden folgende Klassen identifiziert
Maske, Studentenverwalter, Student, Popup
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 208
Durchgängiges Beispiel – Lösung
Szenario zu Use Case „Student immatrikulieren“:
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
Objekt erzeugen
Objekt zerstören
:Klasse nur die Klasse ist festgelegt
es ist klar welches Objekt gemeint ist
Objekt:Klasse ein bestimmtes
Objekt einer Klasse
Return (optional)
Immatrikulation :
Maske
1: in(Name)
: Studenten-
Verwalter
StudentNeu :
Student
Bestaetigung :
Popup
: Sachbearbeiter
2: existiertStudent(Name)
3: return(false)
4: [Student existiert nicht] anlegen(Name)
5: pop()
6: out("Bitte bestätigen")
7: in("ok")
8:
9:
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 209
Durchgängiges Beispiel – Erläuterung
Über eine Erfassungsmaske zur Immatrikulation werden Studentendaten erfasst.
Ein Objekt Student wird kreiert, wenn es noch nicht vorhanden ist.
Um dies herauszufinden, wird der StudentenVerwalter befragt, der alle
Studenten kennt und verwaltet.
Ist die Immatrikulation (das Kreieren des Studenten) erfolgreich, so teilt dies der
neu angelegte Eintrag dem Sachbearbeiter selbst mit, indem er ein Popup mit
der entsprechenden Nachricht öffnet, die bestätigt werden muss.
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 210
Anmerkungen
UML-CASE-Tools
bieten Ihnen beim Erstellen eines Sequenzdiagramms
die in den Klassen vorhandenen Operationen zur Auswahl an
können aus neu definierten Aufrufen neue Operationen erzeugen
erlauben teilweise nur Operationen, die bereits definiert sind
ein Sequenzdiagramm konkretisiert häufig einen Anwendungsfall
ein Sequenzdiagramm kann aber auch Sachverhalte illustrieren, die den
Anwender nicht interessieren (z. B. zur Veranschaulichung der Initialisierung)
Konventionen
Sequenzdiagramme haben die Leserichtung links→rechts, oben→unten
Überkreuzungen von Aufrufen (in der Darstellung) sind möglichst zu vermeiden
Aktoren (d. h. Personen oder andere Systeme, die nicht im modellierten System
enthalten sind) stehen üblicherweise links außen
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 211
Zweites Beispiel
Anwendungsfall „Student exmatrikulieren“
Ein Sachbearbeiter der Hochschule erfasst an einer Bildschirmmaske Studenten,
die exmatrikuliert werden. Die Löschung der Studentenakte darf nur erfolgen,
wenn darin keine entliehenen Gegenstände mehr eingetragen sind. Der
Sachbearbeiter erhält eine Rückmeldung über den Erfolg der Exmatrikulation.
Es wurden bereits folgende Klassen identifiziert:
- Maske
- Studentenverwalter
- Student
- Popup
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 212
Zweites Beispiel – Lösung
Szenario zu Use Case „Student exmatrikulieren“:
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
Exmatrikulation :
Maske
1: in(MatrNr)
: Studenten-
Verwalter
ExStudi :
Student
Loeschbestätigung
: Popup
Tom : Sachbearbeiter
2: existiertStudent(MatrNr)
3: return(ExStudi))
4: [Student existiert] hat_etwas_entliehen()
5:
6: [hat nichts entliehen] exmatrikulieren()
8: out("Löschen Bitte bestätigen")
7:
9: in(ok)
10: 11:
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 213
Tipps zur Erstellung von Sequenzdiagrammen
Überlegen Sie zuerst, was (nicht) dargestellt werden soll
welche Aufruftiefe soll dargestellt werden?
welche konkreten Abläufe („Szenarien“) sollen dargestellt werden?
(nur wenige Pfade bei Verzweigungen; nicht alle Alternativen gleichzeitig)
Achten Sie auf eine geordnete Aufrufreihenfolge
Die Aktivierung eines Objekts startet mit einem synchronen Aufruf und endet mit
einem „Return“ (auf eine klammerartige Schachtelung achten!)
Methodenaufrufe können nur von „aktiven“ Objekten erfolgen. Wird eine Methode
aufgerufen, geht die Aktivität an dieses Objekt über und kommt erst mit dessen
„Return“ zurück
die Kommunikation mit Aktoren und anderen eigenständigen Systemen erfolgt
asynchron
Stellen Sie – zur Verbesserung der Lesbarkeit – auch optionale Konstrukte dar
(Returns von Konstruktoren/Destruktoren bzw. Aktivierungsbalken)
- Dann kann man die synchronen Aufrufe und Returns eines korrekten Diagramms von
oben links nach unten links „durchfahren“.
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 214
Schwierigeres Beispiel
Anwendungsfall „Essen zahlen“ (in der Mensa)
Ein Mensakunde kommt mit seinem Essen zur Kasse. Die Kassenfrau gibt die
Artikelnummern ein und die Kasse zeigt den Betrag an. Der Kunde schiebt seine
Mensakarte in das Lesegerät und der Betrag wird abgebucht. Reicht das
Guthaben nicht aus, wird eine Fehlermeldung angezeigt. Der Kunde entnimmt in
beiden Fällen seine Karte.
Es wurden bereits folgende Klassen identifiziert:
- Kasse
- Display
- LeseSchreibEinheit
- MensaKarte
Welche Aktoren gibt es?
Wie laufen die Aufrufe?
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 215
Schwierigeres Beispiel – Diskussion einer Lösung
Anmerkungen:
In dieser Lösung
kontrolliert die Schreib-
Lese-Einheit den
Gesamtvorgang.
Die Kasse wäre
realistischer.
Der Input ist sichtbar,
der Output nicht
Gehört die Karte zu
unserem System?
Hat sie wirklich eine
Methode „lies“?
Was würde passieren,
wenn die Bezahlung
durch einen
Daumenabdruck und
direkte Abbuchung von
einem Bank-Konto
ersetzt würde?
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
triviale Returns fehlen
(optional)
:Kasse mLSE:
LeseSchreib-
Einheit 1: essenEin(EssenNr))
:KassenFrau
2: zeige(Betrag))
3:
4: KarteEin(meineKarte) 5: lies()
6: Betrag
8: Preis
7: holePreis()
:Kunde
9: vergleiche()
alt
[Preis > Betrag] 10: Fehler()
11:
12: schreibe(mBetrag)
13:
[Preis <= Betrag]
14: KarteRaus()
mDisplay :
Display meineKarte :
MensaKarte
Verzweigung
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 216
Häufige Fehler
1. Fehler: Methodenaufruf beim Aktor
Ein Aktor ist in der Regel menschlich. Er hat deshalb
keine Methoden, die man aufrufen könnte.
2. Fehler: Kontrollverlust durch synchronen Aufruf
Ein Aktor führt ein eigenständiges Leben. Er hat
seine eigene „CPU“. Wegen des synchronen Aufrufs
darf das aufrufende System aber erst weitermachen,
wenn der Aktor ein Return zurückschickt – und das
tut er vielleicht nie. Ein „Timeout-Verhalten“ kann so
nicht mehr implementiert werden.
Lösung
Richtig wäre, eine asynchrone Nachricht (als
Ausgabe) an den Aktor zu schicken, und zu hoffen,
dass er wie gewünscht reagiert. Falls nicht, kann
nach einem Timeout entsprechend reagiert werden.
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
MeinSystem:
System
1: TuEtwas
: Student
MeinSystem:
System
1: out("Bitte tun Sie es")
: Student
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 217
Häufige Ungeschicklichkeiten
Verletzung der Kapselung
Der Kartenleser sagt der Kasse was sie tun soll
(CheckePin). Der Kartenleser kann (bzw. soll) aber
gar nicht wissen, ob eine Pin geprüft werden muss.
Ob die Prüfung über eine PIN erfolgt (oder über einen
Daumenabdruck) gehört zur Verantwortung der Kasse.
Besser wäre, nur das zu sagen, was in der eigenen
Verantwortung liegt. Dann kann die Kasse so
reagieren wie sie es für richtig hält.
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
meineKasse:
Kasse
1: CheckePin()
RW:
Kartenleser
meineKasse:
Kasse
1: NeueKarteErkannt()
RW:
Kartenleser
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 218
Schwierigeres Beispiel ‒ 2. Versuch
Anwendungsfall „Essen zahlen“ (in der Mensa)
Ein Mensakunde kommt mit seinem Essen zur Kasse. Die Kassenfrau gibt die
Artikelnummern ein und die Kasse zeigt den Betrag an. Der Kunde schiebt seine
Mensakarte in das Lesegerät und der Betrag wird abgebucht. Reicht das
Guthaben nicht aus, wird eine Fehlermeldung angezeigt. Der Kunde entnimmt in
beiden Fällen seine Karte.
Es wurden bereits folgende Klassen identifiziert:
- Kasse
- Display
- SchreibLeseEinheit
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 219
Schwierigeres Beispiel – Alternative Lösung
Anmerkungen:
In dieser Lösung kontrolliert
die Kasse den
Gesamtvorgang.
Die RW_Unit kümmert sich
bloß um die Karte.
Der Output erfolgt über die
Klasse Display
Die Karte wird nicht mehr
modelliert, sondern
übergeben
Was würde jetzt passieren,
wenn die Bezahlung durch
einen Daumenabdruck und
direkte Abbuchung von
einem Bank-Konto ersetzt
würde?
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
1: essenEin(EssenNr))
Emma: KassenFrau
2: Zeige(Preis) 3: out(Preis)
15: KarteAuswerfen()
5:
6: in(Karte)
16: out(Karte)
11: Zeige(Fehler)
Tom: Kunde
7: Lies ()
alt
[Preis > Guthaben] 12: out(Fehler) 14:
10: [Preis <= Guthaben]
17:
4: out(Preis)
13: out(Fehler)
9:Schreibe(NeuGuthaben)
8:KarteErkannt(Guthaben)
m_Kasse:
Kasse
m_RW_Unit:
RW_Unit
m_Display:
Display
Besonderheiten bei der Notation
Objekt erzeugen, zerstören
Das Erzeugen eines Objektes wird durch eine Nachricht,
die im Kopf des Objekts endet, dargestellt
Das Zerstören (Löschen) eines Objektes wird durch ein x
auf der Lebenslinie markiert
Rekursiver Aufruf
Ein Aufruf eines Objekts bei sich selbst (z.B. der Aufruf
einer privaten Methode), wird durch einen neuen
Aktivierungsbalken angezeigt, auf den der Aufrufpfeil zeigt
Das Return wird oft nicht dargestellt
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 220
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
:Klasse
Kontrollstrukturen in Sequenzdiagrammen
Kombinierte Fragmente (combined fragments)
Mit kombinierten Fragmenten können die Kontrollstrukturen
aus Programmiersprachen dargestellt werden:
Schleifen, Verzweigungen und Unterprogrammaufrufe
So können Sequenzdiagramme verschachtelt werden
Ein kombiniertes Fragment wird als rechteckiger Block
dargestellt. In der linken, oberen Ecke trägt es eine
Bezeichnung, die den Typ der Kontrollstruktur angibt
Die wichtigsten Typen sind ref (Unterprogramm),
alt (Verzweigung) und loop (Schleife)
Im Beispiel
verweist der Ref-Block auf ein anderes
Sequenzdiagramm mit Namen SD2
stellt der Alt-Block eine Verzweigung mit Bedingung dar.
Die gestrichelte Linie trennt den if und den else-Fall
Wird der Loop-Block ausgeführt bis die Bedingung erfüllt ist
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 221
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
myA:A myB:B
interaction Ref
SD2
ref
alt
tuEtwas()
TuWasAnderes()
[b==wahr]
[else]
loop
tuEtwas()
[nicht_genug]
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 222
Übung: Mikrowellenherd
Modellieren Sie einen Mikrowellenherd.
Die Funktionsweise wird stichwortartig zusammengefasst:
Die Bedienelemente für den Benutzer sind der Einschaltknopf und die Tür
Durch Drücken des Knopfes wird die Mikrowelle (die „Backröhre“) eingeschaltet
Die Kochzeit wird über eine interne Zeituhr auf eine Minute festgelegt
Durch weiteres n-maliges Drücken des Knopfes wird die Kochzeit um n Minuten
verlängert
Wenn die Zeit abgelaufen ist, wird die Backröhre ausgeschaltet, ein Piepton
ertönt und als nächstes muss die Tür geöffnet werden bevor die Mikrowelle
erneut gestartet werden kann
Durch Öffnen der Tür wird die Backröhre abgeschaltet und die verbleibende
Kochzeit gelöscht
Der Mikrowellenherd startet nur bei geschlossener Tür
Wenn die Tür offen ist oder wenn der Herd an ist, leuchtet das Licht
Wenn der Mikrowellenherd ein- bzw. ausschaltet, muss die Backröhre ebenfalls
ein- bzw. ausgeschaltet werden
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 223
Übung: Mikrowellenherd
Erstellen Sie
ein Klassendiagramm
- mit Klassen, Attribute, Methoden, Beziehungen
Sequenzdiagramme für die Szenarien
- 2 Minuten kochen
- Tür öffnen und schließen
- Kochvorgang mit Abbruch durch Tür öffnen
Versuchen Sie die Diagramme selbst zu entwerfen, bevor Sie sich die folgenden
Lösungen anschauen!
Entwickeln Sie zuerst ein Klassendiagramm und vergleichen Sie Ihr Ergebnis mit
der Lösung
Entwickeln Sie die Sequenzdiagramme mit den Klassen und Methoden aus dem
Lösungs-Klassendiagramm
Beachten Sie dabei, dass es nicht nur eine einzige richtige Lösung gibt
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 224
Lösung Mikrowellenherd: Klassendiagramm
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
Mikrowelle
+getTuerStatus(): bool
1
Timer
-zeit: int
+start() +stop() +reset() +erhoehe()
Backroehre
-backstatus: bool
+an() +aus()
Licht
-lichtstatus: bool
+an() +aus()
1 1
1
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 225
Lösung Mikrowellenherd: Sequenzdiagramm „2 Minuten kochen“
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
MyMikro :
Mikrowelle
1: in(Knopf)
: Koch MyTimer :
Timer
myLicht :
Licht
MyBack :
Backroehre
2: erhoehe()
3:
4: start()
5:
6: an()
7:
8: an()
9:
11: erhoehe()
12:
13: out(alert) Zeit abgelaufen
14: aus()
15:
16: aus()
17: 18: out(Piep)
Fertig!
Die Mikrowelle ist gefüllt und die Tür ist zu!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 226
Lösung Mikrowellenherd: Sequenzdiagramm „Tür öffnen und schließen“
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
1: in(Tür_auf)
: Koch
Fertig zum Be- oder Entladen!
2: aus()
3:
4: stop()
5:
6: an()
7:
8: in(Tür_zu) 9: reset()
10:
11: aus()
12:
Die Tür ist zu!
Die Tür ist auf!
MyMikro:
Mikrowelle
MyTimer:
Timer
myLicht:
Licht
MyBack:
Backroehre
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 227
Lösung Mikrowellenherd: Sequenzdiagramm „Kochen mit Abbruch“
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
1: in(Knopf)
: Koch
4: an()
5:
8: in(Tür_auf)
2: stop()
3:
15: an()
16:
6: start()
7:
8: an()
9:
11: aus()
12:
13: stop()
14:
MyMikro:
Mikrowelle
MyTimer:
Timer
myLicht:
Licht
MyBack:
Backroehre
Die Mikrowelle ist gefüllt und die Tür ist zu!
Die Zeit ist noch nicht abgelaufen!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 228
Anwendung
Sequenzdiagramme sind z. B. in folgenden Situationen nützlich:
vor Implementierungsbeginn
- zur Verifikation des Designs: besonders interessante (oder schwierige)
Systemzustände anschaulich darstellen und „testen“ (z. B. Anwendungsfälle)
- um zu verifizieren ob die Klassenaufteilung (Design) gut gewählt ist und alle
benötigten Assoziationen vorhanden sind
im Team
- verbesserte Kommunikation der wesentlichen Abläufe
beim Test
- kritische Abläufe im System können für Tests spezifiziert (und evtl. generiert) werden
Das Sequenzdiagramm ist eines der wichtigsten Interaktionsdiagramme in der UML!
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 229
Tipps
Sequenzdiagramme sind sehr leicht zu lesen…
… aber gar nicht so leicht zu erstellen!
Welche Objekte sind (nicht) erforderlich?
- Auf das Beschränken was wichtig ist bzw. dargestellt werden soll
- aber auch nicht zu wenige Objekte
Wer ruft wen auf?
- Überlegen, wer den Trigger erhält, der die Aktion startet
Welche bzw. wie viele Alternativen sollen dargestellt werden?
- nur die wichtigsten für das Szenario. Lieber mehrere Diagramme!
- oder kombinierte Fragmente verwenden – aber bitte nicht programmieren!
- nicht versuchen, alles auf einmal darzustellen!
Sequenzdiagramme zeigen immer nur je ein Szenario!
Wie wird die Interaktion mit der Außenwelt (Aktoren) modelliert?
- Tipp: Asynchrone Aufrufe und I/O-Objekte verwenden
immer iterativ vorgehen!
5.3.1 Darstellung der Dynamik eines Systems: Sequenzdiagramme
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 230
5.3.2 Darstellung der Dynamik eines Systems:
Kommunikationsdiagramme
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 231
Inhalt
Ein Kommunikationsdiagramm beschreibt
die Interaktion zwischen Objekten im Überblick
die zeitliche Reihenfolge, in der die Nachrichten gesendet werden
die Beziehungen zwischen den Objekten und die Nachrichten,
die übertragen werden
Dabei steht der Überblick der Kommunikationsstruktur im Vordergrund
Das kommt Ihnen bekannt vor?
Kommunikationsdiagramme werden für die selben Zwecke eingesetzt wie
Sequenzdiagramme!
5.3.2 Darstellung der Dynamik eines Systems: Kommunikationsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 232
Notation am Beispiel: „Essen zahlen“
Bedingung [guard]
mehrstellige Nummerierung
gliedert und erlaubt leichtere Änderung
5.3.2 Darstellung der Dynamik eines Systems: Kommunikationsdiagramme entspricht der ersten Lösung
der „Mensa-Aufgabe“ als Sequenzdiagramm!
mLeseSchreibEinheit :
LeseSchreibEinheit
1: essenEin(EssenNr)
: Kasse mDisplay : Display
meineKarte :
MensaKarte
: KassenFrau
: Kunde
1.1: zeige(Betrag)
2.3: [Fehler]cerr() 2: KarteEin(meineKarte)
2.2: holePreis()
2.1: lies()
2.4: schreibe(mBetrag)
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 233
Kommunikationsdiagramm vs. Sequenzdiagramm
Kommunikationsdiagramm Sequenzdiagramm
Objekte in der Fläche verteilt Objekte in einer Linie
Sequenz der Nachrichten durch
Nummerierung
Sequenz der Nachrichten graphisch
auf Zeitachse
Stärke: viele Objekte, die wenige
Nachrichten austauschen
Stärke: wenige Objekte, die viele
Nachrichten austauschen
Parallelität und Alternativen durch
Nummerierung mit Buchstaben
(in manchen Tools nicht unterstützt)
Parallelität durch Asynchronität
(wird mit offenen Pfeilen angedeutet)
Keine Verschachtelung verschachtelte Diagramme möglich
Kommunikationsdiagramme bieten nur eine Untermenge der Sequenzdiagramme!
5.3.2 Darstellung der Dynamik eines Systems: Kommunikationsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 234
Anwendung
Kommunikationsdiagramme sind z. B. in folgenden Situationen nützlich:
wenn das Zusammenspiel zwischen vielen interagierenden Teilen möglichst
einfach dargestellt werden soll
wenn es um das grundsätzliche Verständnis des Ablaufs und der
Verantwortungen geht – weniger um Details im Timing
5.3.2 Darstellung der Dynamik eines Systems: Kommunikationsdiagramme
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 235
5.3.3 Darstellung der Dynamik eines Systems:
Zustandsdiagramme
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 236
Beobachtung
Betrachten Sie die Zustände, in der sich Ihre Digitalkamera befinden kann:
Das Verhalten der Kamera ist sehr stark davon abhängig, in welchem Zustand
sie sich gerade befindet: Kamera reagiert beim Drücken eines Knopfes abhängig
vom Zustand in dem sie sich gerade befindet (z. B. wird durch Drücken des
rechten Knopfes im Zustand Display das nächste Bild angezeigt, im Zustand
Fotografieren der Zustand des Blitzlichtes verändert)
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 237
Beobachtung
Betrachten Sie die Zustände, in denen sich ein
typischer Laserdrucker befinden kann:
Das Verhalten eines Druckers ist sehr stark davon abhängig, in welchem
Zustand er sich gerade befindet
Der Drucker geht unter bestimmten Bedingungen von einem Zustand in den
anderen über
Betriebsbereit Papierstau
Kein Papier eingelegt
Keine Toner-kassette eingelegt
Toner fast leer
Selbsttest
Druckend
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
Es handelt sich offensichtlich um Dynamik eines Systems,
aber wie beschreiben und implementieren wir das?
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 238
Grundidee Zustandsautomat (State Machine)
Wie stellt man die Zustände und Übergänge eines Systems dar?
Modelliere das System als eventgetriebenes System mit
Zuständen, Übergängen und Ereignissen
„Zustandsdiagramm“ (State (Machine) Diagram)
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
Es ist immer nur ein Zustand in einem Zustandsautomaten aktiv!
Schließen
Schranke offen
Schranke geschlossen
Öffnen
Anfangszustand
Ereignis
Zustandsübergang
Zustand
Endzustand
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 239
Interpretation des Beispiels
Zustandsdiagramm zu einer Schranke
Eine Schranke wird eingebaut und erreicht nach ihrer Fertigstellung ihren Anfangszustand (hier: Schranke offen). Sie ist betriebsbereit. Während ihrer Existenz kann sie die Zustände „Schranke offen“ und „Schranke geschlossen“ einnehmen.
Durch die Ereignisse „Schließen“ und „Öffnen“, die von anderen Objekten (z. B. einem Benutzer, Kontaktschleife) verursacht werden, ändert sie ihren Zustand. Die Schranke reagiert aber in jedem Zustand nur auf bestimmte Ereignisse. Ist die Schranke im Zustand geschlossen, so reagiert sie nur auf das Ereignis „Öffnen“. Ist die Schranke im Zustand offen, so reagiert sie nur auf das Ereignis „Schließen“.
Alle Nachrichten, die in einem Zustand eines Objektes nicht sinnvoll sind (es existiert kein vom Zustand herausführender Pfeil mit diesem Ereignis), werden ignoriert und verursachen keine Reaktion des Objekts. Beispiel: „Öffnen“ im Zustand „Schranke offen“
Das Erreichen des finalen Zustandes bedeutet die Zerstörung des Objekts
Das Modell könnte bei Bedarf um weitere Zustände ergänzt werden: z. B. „Schranke öffnend“, „Schranke schließend“
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
Schließen
Schranke offen
Schranke geschlossen
Öffnen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 240
Was ist ein Zustand?
Der Zustand eines Objekts ist eine Zeitspanne, in der
das Objekt eine bestimmte Aktivität ausführt und
das Objekt auf ein oder mehrere bestimmte Ereignisse wartet oder
das Objekt wartet, bis eine bestimmte Bedingung erfüllt ist
Ein Objekt kann sich im Laufe der Zeit in verschiedenen, klar voneinander
abgegrenzten Zuständen befinden
Schranke offen
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 241
Was ist kein Zustand?
Verwechseln Sie die Zustände, die ein Objekt oder das System
einnehmen kann, nicht
mit den Objekten oder Komponenten des Systems selbst
oder mit Aktivitäten
Beispiel: Betrachten Sie die Steuerung einer Parkhausschranke.
Falsch:
oder
Richtig:
Schranke
Schranke offen
Schranke geschlossen
Schranke öffnen
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 242
Was ist ein Zustandsübergang?
Beispiel:
Betrachten Sie einen typischen Laserdrucker.
Der Toner ist leer und Sie legen eine neue Tonerkassette ein.
- Erkennen Sie einen Übergang von einem Zustand zu einem anderen?
- Welche Elemente sind an dem Übergang beteiligt?
Beschreibung: Wenn der Drucker keinen Toner mehr hat und eine Tonerkassette
eingelegt wird und der Deckel geschlossen wird, dann wird ein Reset
durchgeführt und anschließend ist der Drucker im Zustand „Selbsttest“
Ein Zustandsübergang („Transition“) liegt vor, wenn ein Objekt
in einem bestimmten Zustand ist, und
ein bestimmtes Ereignis eintrifft, und
bestimmte Bedingungen erfüllt sind und
dann eine bestimmte (kurze) Aktion ausgeführt wird und
das Objekt sich anschließend in einem anderen Zustand befindet
Zustandsübergänge benötigen keine Zeit!
Die Aktionen müssen entsprechend schnell
ablaufen!
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 243
Notation von Zustandsübergängen
Zustandsübergänge werden durch Pfeile zwischen dem aktuellen Zustand und
einem Folgezustand dargestellt.
An einem solchen Pfeil werden die Details des Zustandsübergangs notiert:
Tür offen Tür zu
EC-Karte ins Lesegerät gesteckt
[EC-Karte ist gültig]
/ Kartennummer mit Zeitstempel ins Logfile schreiben; Tür öffnen
Liste von Auslösern („Trigger“)
(durch Kommata getrennt)
Eine optionale Bedingung („Guard“)
(in eckigen Klammern)
Aktionen („Action“) die beim Zustandswechsel
stattfindet (durch ‘/‘ abgetrennt)
Für einen Trigger sollte immer nur
ein Zustandsübergang möglich sein!
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 244
Verhalten in Zuständen
Beispiel:
Betrachten Sie einen Beamer, den Sie anschalten.
- Erkennen Sie Aktivitäten, die dann ausgeführt werden? Wann werden sie ausgeführt?
Im Zustand „Systemstart“ wird zuerst eine rote LED angeschaltet, dann wird
die Birne vorgewärmt bis die Betriebstemperatur erreicht ist. Ist dies der Fall, wird
der Beamer aktiviert und statt der roten eine grüne LED angeschaltet. Während
der Aufwärmphase wird alle 5 Sek. geprüft, ob die Temperatur erreicht ist.
Verhalten in einem Zustand tritt auf, als
Eintrittsverhalten (entry behavior)
- Verhalten eines Objekts, wenn es einen bestimmten Zustand einnimmt
Zustandsverhalten (state behavior oft auch do behavior)
- Verhalten eines Objekts, solange es sich in dem Zustand befindet
Austrittsverhalten (exit behavior)
- Verhalten eines Objekts, wenn es den Zustand verlässt
Interne Transition (internal transition)
- bedingtes Verhalten bei Ereignissen, die den Zustand nicht verlassen
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
Vorgänge, die Zeit kosten, müssen innerhalb
der Zustände umgesetzt werden!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 245
Systemstart
entry / roteLEDAn() do / Birne aufheizen() exit / roteLEDAus()
alle 5 Sek. [true] / CheckTemp()
Notation des Verhaltens
Darstellung in einem eigenen Bereich unterhalb des Zustandsnamens
Das Verhalten wird mit Schrägstrich von den Labels entry, do und exit abgetrennt
Interne Übergänge werden analog zu Transitionen beschrieben
Mehrere Aktionen werden durch ‘,‘ getrennt
Eintrittsverhalten
Aktionen, die beim Eintritt in den
Zustand ausgeführt werden
Zustandsverhalten Aktivitäten, die ausgeführt werden, solange man sich in dem Zustand befindet (es findet
jedoch keine automatische Wiederholung statt)
Austrittsverhalten
Aktionen, die beim Verlassen des
Zustands ausgeführt werden
Interne Transition
Aktionen, die ausgeführt werden, wenn der Trigger (hier
Time-Trigger) auftritt und der (optionale) Guard erfüllt ist
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 246
Aktionen und Aktivitäten
Aktionen („actions“)
sind ein nicht unterbrechbares Verhalten, das an bestimmten Stellen in einem
Zustandsautomat ausgeführt wird
Von Aktionen wird angenommen, dass Sie keine Zeit verbrauchen
Eine Aktion kann wiederum aus einer Sequenz von Aktionen bestehen, die dann
auch nicht unterbrechbar ist
in Zustandsübergängen können Aktionen ausgeführt werden
Eine Aktion kann daraus bestehen, eine Nachricht an andere Objekte (oder sich
selbst) zu verschicken
Aktivitäten („activities“)
sind Verhalten, die endliche Zeit benötigen
Aktivitäten werden nur innerhalb des Zustandsverhaltens ausgeführt
(do behavior)
Aktivitäten bestehen normalerweise aus mehreren Aktionen
Aktivitäten werden unterbrochen, wenn ein Ereignis einen Zustandswechsel auslöst
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 247
Schalten einer Transition bei Eintreffen eines Ereignisses
Eine Transition mit Trigger
feuert (schaltet), wenn ein Ereignis (hier z. B. „Witz erzählt“) eintrifft, d. h. es
erfolgt ein Zustandsübergang (hier zu Zustand B).
Trifft ein Ereignis ein, für das kein Zustandsübergang existiert (hier z. B.
„Kopfweh haben“), dann wird kein Zustandsübergang ausgeführt und das
Ereignis verfällt.
B
do / lachen
C
do / essen
Hunger verspüren
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
Witz erzählt A
do / nichts tun
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 248
Reihenfolge der Aktionsausführung nach Eingang eines Triggers
Bei einem Zustandsübergang werden
die Aktivitäten in folgender Reihenfolge ausgeführt
Do-Aktivität wird unterbrochen
Austrittsverhalten des alten Zustands
Aktionen, die zur Transition gehören
Eintrittsverhalten des neuen Zustands
Zustandsverhalten des neuen Zustands
Auch bei rekursiven Transitionen (Loop's)
werden alle diese Aktionen ausgeführt
Bei internen Transitionen
werden nur die Aktivitäten ausgeführt, aber
kein Exit und kein Entry behavior
wird eine laufende do-Aktivität unterbrochen, die
Aktionen der internen Transition ausgeführt und
anschließend wird die do-Aktivität fortgeführt
Exit behavior (actions) des
vorhergehenden Zustands
Transition actions
Entry behavior (actions)
State behavior (activity)
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
LOOP
entry/ z=read()
INT
entry/ z=read() alle 5 Sek. / doIt()
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 249
Transitionen im Detail
Transition ohne Trigger (Automatische Transition/Completion Transition)
1. Fall: ohne Guard
feuert von selbst, sobald das Zustandsverhalten (do behavior) abgearbeitet ist
2. Fall: mit Guard
feuert von selbst, sobald das Zustandsverhalten (do behavior) abgearbeitet ist,
aber nur wenn der Guard erfüllt ist
ist der Guard nicht erfüllt, kann der Zustand nur über eine andere Transition
verlassen werden
- Nach dem Lachen werden – falls der Bauch weh tut – die Muskeln gelockert
A
do / grinsen
B
do / Muskeln lockern
A
do / lachen
B
do / Muskeln lockern
[Bauch tut weh]
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 250
Transitionen im Detail II
Änderungsauslöser (Change Trigger)
an der Transition steht eine When-Bedingung
falls die Bedingung erfüllt ist, erfolgt die Transition (auch vor oder während der
do-Aktivität)
falls die Bedingung nicht erfüllt ist, erfolgt der Zustandsübergang dann, wenn sich
die Bedingung von false auf true ändert
die Bedingung wird „ständig“ neu ausgewertet und bei Erfüllung wird die
Transition ausgelöst
- damit die Auswertung der Bedingung technisch möglich ist, wird die Überwachung in
der Praxis auf bestimmte Zeitpunkte, bestimmt Ereignisse oder die Attribute des
Zustands eingeschränkt
- Das Lachen wird unterbrochen, sobald der Bauch weh tut !
A
do / lachen
B
do / Muskeln lockern
when (Bauch tut weh)
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 251
Ereignisse im Detail
Wenn ein Ereignis eintrifft, gibt es entweder
eine Transition, die feuern kann
- das ist der Normalfall; im Beispiel für z='+'
mehrere Transitionen, die feuern können
- Der Trigger passt zu mehreren Transitionen und der Guard
liefert 'true'; im Beispiel für z='*'
- das Verhalten der Zustandsmaschine ist nicht vorhersagbar;
es wird eine zufällig bestimmte Transition durchlaufen
- Dieser Fall sollte vermieden werden!
keine Transition, die feuern kann
- Der Trigger passt zu keiner Transitionen oder der Guard
liefert false'; im Beispiel für z='/'
- dann verfällt das Ereignis und es wird keine Transition ausgeführt
Bei Automatischen Transitionen (Transitionen ohne Ereignis)
gilt das Gleiche – auch wenn es kein echtes Ereignis gibt
SX
entry/ z=read()
Ereignis1 [z='*']
Ereignis1 [z!='/']
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
SY
entry/ z=read()
[z='*']
[z!='/']
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 252
Sonderfälle: Kreuzungen vs. Entscheidungen
Eine Kreuzung erlaubt, bei Kombinationen von Zustandsübergängen das
Diagramm zu vereinfachen.
Aber Vorsicht – es gibt einen wichtigen Unterschied zu Entscheidungen
B
A
do / z = 17
Trigger / z++
[z gerade] [z ungerade]
C B
Trigger / z++
A
do / z = 17
[z gerade] [z ungerade]
C
Kreuzung Entscheidung
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 253
Kreuzungen vs. Entscheidungen (Darstellung transformiert)
Die Kreuzung kann als 2 Transitionen, die Entscheidung mit 3 Transitionen und Zwischenzustand dargestellt werden:
Die Auswertung der Bedingung erfolgt bei der Kreuzung VOR der Ausführung der Aktion; bei der Entscheidung nach der Aktion!
B
A
do / z = 17
Trigger [z ungerade] / z++
C B
Trigger / z++
A
do / z = 17
[z gerade] [z ungerade]
C
Trigger [z gerade] / z++
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
Zwischen- zustand
ohne Aktivitäten oder Aktionen
Kreuzung Entscheidung
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 254
Wie findet man Zustände, Übergänge und Ereignisse?
Analysiere, in welchen unterschiedlichen Zuständen
sich das System befinden kann
Suche nach gleichem Verhalten über einen Zeitraum
Analysiere welche Ereignisse in dem System auftauchen
löst das Ereignis einen Zustandsübergang aus?
welche Aktion erfolgt als Reaktion auf das Ereignis?
welche Aktionen werden dauerhaft ausgeführt und welche Aktionen nur beim
Eintreten oder Verlassen eines Zustands?
Analysiere die Übergänge zwischen den Zuständen
sollte es einen Übergang zwischen einem Zustandspaar geben?
achte darauf, dass jedes Ereignis höchstens einen Übergang auslöst
Analysiere auch vorliegende
Use Cases und Sequenzdiagramme!
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
Übung: Ein C++ Kommentarfilter
Zeichnen Sie das Zustandsdiagramm eines Filters, welcher einen (gültigen)
C++-Text aus einem Eingabestrom einliest, alle C++ Kommentare entfernt
und das Ergebnis in den Ausgabestrom schreibt
Tipps:
Überlegen Sie sich zuerst, warum Sie dafür ein Zustandsdiagramm brauchen.
Es müssen mehrzeilige Kommentare /* .... */
und einzeilige Kommentare // erkannt werden.
Jede Zeile wird durch EOLN abgeschlossen. Der Eingabestrom wird durch EOF
abgeschlossen.
Passen Sie auf Strings auf: s = "Hello /* world";
Durch z = read() wird das nächste Zeichen aus dem Eingabestrom
eingelesen, und durch write(z) wird das Zeichen in der Variablen z in den
Ausgabestrom geschrieben.
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 255
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 256
Lösung der Übung: C++ Kommentarfilter
Ein "/" gelesen
entry/ z=read()
In "/*"-Kommentar
entry/ z=read()
"*" im /* Kom. gelesen
entry/ z=read()
in String
entry/ z=read()
[z='/']
[z!='/' && z!='*'] /write('/'); write(z);
[z='/']
[z!=EOLN && z!=EOF]
[z=EOLN] /write(z);
[z='*']
[z!='*']
[z='*']
[z='*']
[z='/']
[z!='*' && z!='/']
[z='"'] /write(z)
[z='"'] /write(z)
[z!='"'] /write(z)
[z!='/' && z!='"' && z!=EOF] /write(z)
[z=EOF] /write(z)
In "//"-Kommentar entry/ z=read()
im Progr-Code
entry/ z=read()
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
Finden Sie noch
einen Fehler?
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 257
Beschreibung des Zustandsverhaltens
Grundsätzlich kann das Zustandsverhalten (do / Zustandsverhalten) auch
außerhalb des Zustandsdiagramms näher beschrieben werden:
verbal
als Aktivitätsdiagramm
als weiteres Zustandsdiagramm (Ein Zustand wird in Unterzustände mit
Zustandsübergängen zerlegt.)
oder auch mit dem Konzept der zusammengesetzten Zustände
(siehe nächste Folie)
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
Systemstart
entry / roteLEDAn() do / Birne aufheizen() exit / roteLEDAus()
alle 5 Sek. [true] / CheckTemp()
Birne aufheizen
Damit die Birne...
Birne aufheizen
Birne aufheizen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 258
Zusammengesetzte Zustände (composite states)
Bisher haben wir nur einfache Zustände betrachtet
Ein Zustand kann jedoch selbst wiederum als ein Automat mit Unterzuständen
beschrieben werden
Das Vorhandensein von Unterzuständen kann durch das Composite-Icon
(„Brille“) angedeutet werden
Zustandsname
entry / Eintrittsverhalten do / Zustandsverhalten
exit / Austrittsverhalten
Zustandsname
entry / Eintrittsverhalten do / Zustandsverhalten
exit / Austrittsverhalten
UZ1 UZ1
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 259
Eintritt in einen zusammengesetzten Zustand
Ein zusammengesetzter Zustand kann wie folgt betreten werden:
Default entry
Die Pfeilspitze des Zustandsübergangs zeigt
auf den Rand des zusammengesetzten Zustands.
Damit wird der Startzustand des zusammengesetzten
Zustands implizit als Folgezustand ausgewählt.
Explicit entry
Die Pfeilspitze zeigt direkt auf einen bestimmten
Unterzustand eines zusammengesetzten Zustands.
UZ
UZ2
UZ1
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 260
Verlassen eines zusammengesetzten Zustands
Ein zusammengesetzter Zustand kann auf folgende Arten verlassen werden:
Der zusammengesetzte Zustand erreicht seinen Endzustand (weiter mit C).
Ein Unterzustand wechselt explizit in einen anderen Zustand außerhalb des
zusammengesetzten Zustands (B nach D).
Ein Auslöser weg von dem zusammengesetzten Zustand findet statt
(Wechsel nach E – egal aus welchem Zustand).
C
D T1[G1]/A1
T2[G2]/A2 E
A B
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
Was passiert, wenn T1 eintrifft und G1 erfüllt ist, während der Do-Teil von A ausgeführt wird? Was passiert, wenn T1 eintrifft und G1 erfüllt ist, während der Do-Teil von B ausgeführt wird? Was passiert, wenn T2 eintrifft und G2 erfüllt ist, während der Do-Teil von A ausgeführt wird?
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 261
Zusammengesetzte Zustände: Beispiel
Was wird hier modelliert?
Warum ist der Espresso ab und zu kalt?
Aufheizen
when (Betriebstemp. erreicht)
Leerlauf Aktiv Taste „Espresso“
Taste „Reinigen“
Betriebsbereit
Selbstreinigung
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 262
Zwischenstand Zustandsdiagramme
Modellierungselemente
Zustände und Verhalten in Zuständen
Transitionen und Aktionen
Ereignisse
Zusammengesetzte Zustände
Bisher:
Beschreibung von zustandsbasierten Vorgängen (Laserdrucker, Tür)
Beschreibung von Algorithmen (C++-Parser)
eher als Mittel für die Analyse
Aber wie funktioniert das im Design,
d. h. mit Objektorientierung ‒ mit Klassen und Objekten?
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 263
Erste Beobachtung
Betrachten Sie die Zustände, in denen
sich ein typisches Objekt befinden
kann:
Objekt wird angelegt (Konstruktor)
Objekt ist vorhanden
- empfängt Nachrichten
bzw. macht Methodenaufrufe
- je nach Aufruf und Attributen des
Objekts werden Attribute verändert
oder weitere Nachrichten verschickt
- Ereignisse (z. B. Timer) können
Aktionen auslösen
Objekt wird zerstört (Destruktor)
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
Der Lebenszyklus von Objekten einer Klasse kann durch Zustandsdiagramme
beschrieben werden!
Neu
… und stirbt
Sterbend
Aktiv
Ein Objekt wird erzeugt...
... durchläuft
mehrere Zustände
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 264
Zweite Beobachtung
Objekte in einem Sequenzdiagramm zeigen Zustände an!
eingehende Signale ändern den Zustand
in(MatrNr)
return (ExStudi) d. h. when Studi existiert
Waiting
Checking Student
entry/SV.existiertStud(MatrNr)
Exmatriculating
entry/ExStudi.exmatrikulieren()
Waiting
Checking
Student
Exmatriculating
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
return(ok) d. h. when Studi exmatrikuliert
Zustandsdiagramm Exmatrikulationsmaske
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 265
Von Sequenzdiagrammen zum Zustandsdiagramm
Vorgehen zum Herausarbeiten der Zustände
1. Wähle ein Objekt aus und analysiere ein Sequenzdiagramm in dem es vorkommt
2. Markiere eintreffende Ereignisse für das betreffende Objekt
3. Wähle ein Paar von „benachbarten“ Ereignissen
4. Analysiere was das Objekt zwischen den beiden Ereignissen tut und vergebe einen entsprechenden Namen für diesen Zustand
5. Führe den vorigen Schritt für alle benachbarten Paare durch
6. Wiederhole das Vorgehen für weitere Sequenzdiagramme
Zeichne ein Zustandsdiagramm
1. Beginne das Diagramm mit einem Startzustand und den gefundenen Zuständen
2. Zeichne Transitionen zwischen Zuständen, die im Sequenzdiagramm benachbart sind
3. Ergänze das Diagramm um Ereignisse, Aktionen und bei Bedarf um einen Endzustand
4. Überprüfe, ob es weitere Transitionen geben sollte, die nicht in den Sequenzdiagrammen vorkommen
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 266
Übung: Mikrowellenherd
Modellieren Sie einen Mikrowellenherd.
Die Funktionsweise wird stichwortartig zusammengefasst:
Die Bedienelemente für den Benutzer sind der Einschaltknopf und die Tür
Durch Drücken des Knopfes wird die Mikrowelle (die „Backröhre“) eingeschaltet
Die Kochzeit wird über eine interne Zeituhr auf eine Minute festgelegt
Durch weiteres n-maliges Drücken des Knopfes wird die Kochzeit um n Minuten
verlängert
Wenn die Zeit abgelaufen ist, wird die Backröhre ausgeschaltet, ein Piepton
ertönt und als nächstes muss die Tür geöffnet werden bevor die Mikrowelle
erneut gestartet werden kann
Durch Öffnen der Tür wird die Backröhre abgeschaltet und die verbleibende
Kochzeit gelöscht
Der Mikrowellenherd startet nur bei geschlossener Tür
Wenn die Tür offen ist oder wenn der Herd an ist, leuchtet das Licht
Wenn der Mikrowellenherd ein- bzw. ausschaltet, muss die Backröhre ebenfalls
ein- bzw. ausgeschaltet werden
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme Die Aufgabe kennen Sie aus
dem Kapitel Sequenzdiagramme!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 267
Übung: Mikrowellenherd
Erstellen Sie
ein Klassendiagramm
- mit Klassen, Attribute, Methoden, Assoziationen
die Zustandsdiagramme der Klassen. Suchen Sie dazu:
- Zustände (z. B. auch in den Sequenzdiagrammen)
- Ereignisse
- Zustandsübergänge
- Aktivitäten
Die Sequenzdiagramme für folgende Szenarien sollen abgedeckt werden
- 2 Minuten kochen
- Tür öffnen und schließen
- Kochvorgang mit Abbruch durch Tür öffnen
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme Die Aufgabe kennen Sie aus
dem Kapitel Sequenzdiagramme!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 268
Lösung Mikrowellenherd: Klassendiagramm
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme Die Lösung kennen Sie aus
dem Kapitel Sequenzdiagramme!
Mikrowelle
+getTuerStatus(): bool
1
Timer
-zeit: int
+start() +stop() +reset() +erhoehe()
Backroehre
-backstatus: bool
+an() +aus()
Licht
-lichtstatus: bool
+an() +aus()
1 1
1
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 269
Lösung Mikrowellenherd: Sequenzdiagramm „2 Minuten kochen“
Analysiere die
Objekte auf Zustände
Backröhre
- an
- aus
Licht
- an
- aus
Timer
- aus
- aktiv
Mikrowelle
- wartend
- kochend
- kochen fertig
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
wartend
kochend
kochen fertig
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 270
Lösung Mikrowellenherd: Sequenzdiagramm „Tür öffnen und schließen“
Analysiere die Objekte
auf Zustände
Backröhre
- an
- aus
Licht
- an
- aus
Timer
- aus
- aktiv
Mikrowelle
- wartend
- geöffnet
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
schon bekannt
neu
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 271
Lösung Mikrowellenherd: Sequenzdiagramm „Kochen mit Abbruch“
Analysiere die Objekte
auf Zustände
Backröhre
- an
- aus
Licht
- an
- aus
Timer
- aus
- aktiv
Mikrowelle
- wartend
- kochend
- geöffnet
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 272
Licht an
entry / lichtstatus = on;
Lösung Mikrowellenherd: Zustandsdiagramme für Licht und Backröhre
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
Licht aus
entry / lichtstatus = off;
Licht
an aus
Backröhre an
entry / backstatus = on;
Backröhre aus
entry / backstatus = off;
Backroehre
an aus
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 273
Lösung Mikrowellenherd: Zustandsdiagramm Timer
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
Timer
Timer aus
entry / reset() erhoehe / zeit++;
Timer aktiv do / zähle zeit runter
erhoehe / zeit++;
start when zeit==0
/myback.alert stop
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 274
kochend
entry / MyBack.an, MyLicht.an, MyTimer.start
exit / MyBack.aus Knopf /MyTimer.erhoehe
wartend
entry /MyBack.aus, MyLicht.aus, MyTimer.reset
kochen fertig
entry / MyLicht.aus, out(Piep)
geöffnet
Lösung Mikrowellenherd: Zustandsdiagramm Mikrowelle
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
Knopf / MyTimer. erhoehe alert
Tür_auf / MyLicht.an Tür_zu
Tür_auf / MyTimer.stop
Tür_auf / MyLicht.an
Mikrowelle
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 275
Lösung Mikrowellenherd: Bewertung
Aktionen können häufig an verschiedenen Stellen umgesetzt werden
z. B. als Austrittverhalten des alten Zustands oder als Aktion, die zur Transition
gehört oder auch als Verhalten des neuen Zustands
achten Sie darauf, dass Aktionen nicht unnötig oder mehrfach ausgeführt wird
bedenken Sie, dass nur das Zustandsverhalten länger dauern darf
bei zyklischen Transitionen wird jeweils das Exit und Entry behavior ausgeführt
- bei internen Transitionen nicht!
Die Verwendung des Exit Verhaltens im Zustand „kochend“ verhindert,
dass in einem anderen Zustand versehentlich die Backröhre „an“ ist
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
kochend
entry / MyBack.an, MyLicht.aus, MyTimer.start
exit / MyBack.aus
Knopf / Timer.erhoehe
kochend
entry / MyBack.an, MyLicht.aus, MyTimer.start
exit / MyBack.aus Knopf / MyTimer.erhoehe
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 276
Orthogonale zusammengesetzte Zustände
Der Inhalt eines Zustands ist schwer auf Korrektheit zu prüfen, wenn darin
mehrere eigenständige Objekte behandelt werden
üblicherweise bei einer Aggregation im Klassendiagramm
(z. B. auch Timer, Licht, Backröhre)
Ein Zustand kann zur Verbesserung der Übersichtlichkeit in sogenannte
Regionen (oder Gebiete) aufgeteilt werden
jede enthält einen parallel ausführbaren
(„orthogonalen“) Unterzustandsautomaten
wenn der Oberzustand betreten wird,
werden alle Unterzustandsautomaten
parallel betreten
Auftretende Ereignisse werden
für jede Region betrachtet
das Ein- und Austrittsverhalten wird analog
zu den zusammengesetzten Zuständen
dargestellt
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
an entry / an exit / aus
Backröhre
kochend
an entry / an
Licht
aktiv entry / start Knopf / zeit++
Timer
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 277
Weitere Modellierungselemente: Gabelung und Vereinigung
Um parallele Abläufe für orthogonal zusammengesetzte Zustände explizit zu
machen, gibt es die Gabelung („Fork“)
die ausgehenden Kanten enthalten weder Trigger
noch Bedingung
jede ausgehende Kante führt in eine (andere) Region
nun können mehrere (Unter-)Zustände aktiv sein, allerdings müssen Sie
unabhängig voneinander sein und können deshalb auch leicht sequentialisiert
werden
Um die Synchronisation von parallelen Abläufen (innerhalb von orthogonal
zusammengesetzten Zuständen) explizit zu machen, gibt es die
Vereinigung („Join“)
jede der eingehenden Kanten stammt aus einer Region
die eingehenden Kanten haben weder Trigger
noch Bedingung
Die Verfolgung der aktiven Unterzustände erfolgt nach dem Tokenprinzip
Auslöser [Bedingung]
Verhalten Verhalten
Auslöser [Bedingung]
Verhalten Verhalten
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 278
Weitere Modellierungselemente: Grundidee Historie
Unterzustandsautomaten können auch komplizierter sein, als im
vorherigen Beispiel
stellen Sie sich z. B. ein Autoradio vor, das CD-Player, Radio usw. enthält
dann wird das Autoradio zu einem Zustandsautomaten, der viele Zustände
enthält und wiederum selbst Unterzustandsautomaten für CD und Radio enthält
beim Wiedereintritt in einen Unterzustand wäre es oft praktisch zu wissen, in
welchem Zustand der Unterautomat zuletzt war
- z. B. war das Radio auf MW, oder auf UKW, bevor Sie zur CD wechselten?
Man braucht so etwas wie einen „intelligenten Eingangszustand“, der sich den
letzten Zustand merkt
dann wird beim Wiedereintritt
in den Unterautomaten
der vorherige Zustand
wiederhergestellt
„Historie“
Radiobetrieb
FM
Taste AM
Taste FM
Taste RADIO
[CD eingelegt]
CD Betrieb
AM
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 279
Weitere Modellierungselemente: Flache Historie
Eine flache Historie („Shallow History“)
merkt sich den Zustand der beim Verlassen eines Unterzustandsautomaten
zuletzt aktiv war
kann eine Transition definieren, die ausgeführt wird, wenn die Historie noch nicht
„gesetzt“ ist bzw. gelöscht wurde
wird gelöscht (d. h. der Inhalt), wenn ein Endzustand des
Unterzustandsautomaten erreicht wird
merkt sich NICHT die Zustände von verschachtelten Unterzustandsautomaten
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
Radiobetrieb
H
FM
Taste AM
Taste FM
Taste RADIO
when(CD eingelegt)
CD Betrieb
AM
flache Historie
definiert Zielzustand bei leerer Historie
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 280
Weitere Modellierungselemente: Tiefe Historie
Eine tiefe Historie („Deep History“)
merkt sich den zuletzt aktiven Unterzustand in der aktuellen und in allen weiteren
Unterzustandsautomaten
kann eine Transition definieren, die ausgeführt wird, wenn die Historie noch nicht
„gesetzt“ ist bzw. gelöscht wurde
wird gelöscht (d. h. der Inhalt), wenn ein Endzustand des
Unterzustandsautomaten erreicht wird
merkt sich die Zustände von allen verschachtelten Unterzustandsautomaten
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
Radiobetrieb
FM
H*
FM1
Taste AM
Taste FM
Taste RADIO
[CD eingelegt]
CD Betrieb
AM
tiefe Historie
Taste FM
Taste FM
FM2
Vom Zustandsautomat zum laufenden Code (Prinzip)
Umsetzung eines Systems mit Zustandsautomaten
Die Implementierung der Klassen mit Methoden und Attributen ist bekannt
Die Zustände und Ereignisse kann man mit Switch/Case und Enum umsetzen
Das Eintreffen eines Ereignisses kann man durch Methodenaufrufe realisieren
Es gibt mächtige Tools/Frameworks für Zustandsautomaten (z. B. Rhapsody)
lesen Zustandsautomaten bzw. -diagramme ein
erzeugen lauffähigen Code
stellen die erforderliche Infrastruktur bereit (Timer, Messaging,...)
- zum Verschicken von Nachrichten, zum Aufrufen von Methoden, zum Verfolgen des
aktiven Zustands, usw.
unterstützen bei der Entwicklung mit „Debugger“, Analyseverfahren usw.
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 281
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
Das ist für jeden Zustandsautomat das Gleiche!
Verwende eine generische Laufzeitumgebung für Zustandsdiagramme!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 282
Parallelität, synchron oder asynchron? Aktive Objekte
In den Zustandsdiagrammen tauchen mehrere Objekte auf, die offensichtlich
eigenständig „leben“
z. B. muss der Timer weiterzählen, während die Mikrowelle auf einen
Tastendruck wartet; das heißt die Mikrowelle und der Timer arbeiten parallel
und die Backröhre heizt eigentlich für eine längere Zeitdauer – wir haben das
einfach auf das An-/Ausschalten beschränkt
in den Sequenzdiagrammen wurde das Problem schon angedeutet
(durch asynchrone Nachrichten mit einer in()-/out()-Notation)
– aber dort dürfen auch mehrere Objekte gleichzeitig aktiv sein!
In einem Zustandsautomaten darf immer nur ein Zustand aktiv sein!
Eigentlich braucht man mehrere Zustandsautomaten, die parallel arbeiten und
Nachrichten austauschen können!
Das Konzept der „aktiven Objekte“ erlaubt dies und die zuvor erwähnten Tools
unterstützen auch diese Fähigkeit
Durch Multitasking, kritische Bereiche, asynchrone Kommunikation etc. wird die
Umsetzung dann deutlich komplizierter... (und wird deshalb hier nicht behandelt)
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 283
Kontrollfragen
Welche Verhalten können innerhalb eines Zustands auftreten?
Wie ist die Ausführungsreihenfolge bei einem Zustandsübergang?
Was passiert, wenn es mehr als eine Transition gibt, deren Wächter und Trigger
erfüllt sind?
Was bedeutet eine Transition, die keinen Trigger hat, sondern nur einen
Wächter?
Was haben Zustandsdiagramme mit Objekten zu tun?
Wie extrahiert man aus Sequenzdiagrammen die Zustände?
Wie kann man Zustandsautomaten ausführbar machen?
5.3.3 Darstellung der Dynamik eines Systems: Zustandsdiagramme
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 284
5.3.4 Darstellung der Dynamik eines Systems:
Zusammenfassung
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 285
Kontrollfragen
Warum sind Verhaltensdiagramme eine wichtige Ergänzung zu
Strukturdiagrammen?
Welche Elemente enthält ein Sequenzdiagramm?
Gehört ein Aktor zum System?
Wann verwendet man (a)synchrone Aufrufe?
Welche Bedeutung hat die Aktivierung?
Was sind „Combined Fragments“?
Sind Sequenzdiagramme ausführbar?
Welchen Vorteil bieten Kommunikationsdiagramme?
Wann verwenden Sie Zustandsdiagramme?
Sind Zustandsdiagramme ausführbar?
Können Sie jetzt die Dynamik eines Systems in Diagrammen darstellen?
5.3.4 Darstellung der Dynamik eines Systems: Zusammenfassung
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 286
5.4 Weitere Diagramme in der UML
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 287
Zwischenstand Diagramme
der UML2.x
Verhaltens-
diagramme
Struktur-
diagramme
Interaktions-
diagramme
Klassen-
diagramm
Kompositions-
strukturdiagramm
Komponenten-
diagramm
Verteilungs-
diagramm
Paket-
diagramm
Objekt-
diagramm
Use Case –
diagramm *
Aktivitäts-
diagramm
Zustands-
diagramm
Sequenz-
diagramm
Kommunikations-
diagramm
Interaktionsübersicht-
diagramm
Timing-
diagramm
* Die Einordnung des Use Case Diagramms ist
strittig. Auch wenn es dabei um das Verhalten geht,
stellt es „nur“ die Struktur von Anwendungsfällen
und Akteuren dar. Damit wäre es eher ein Struktur-
als ein Verhaltensdiagramm.
5.4 Weitere Diagramme in der UML Die UML definiert insgesamt 14 verschiedene Diagrammtypen
einige weitere wichtige Diagramme werden nun kurz
behandelt
Profil-
diagramm
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 288
5.4.1 Objektdiagramme in der UML
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 289
Notation am Beispiel
Klassendiagramm:
Objektdiagramm:
Quelle: UML 2 glasklar, C. Rupp et.al.
5.4.1 Objektdiagramme in der UML
Objekt Link
Tom : Stud_Mitarbeiter
Matrikelnummer = “0815“ Name = “Müller“ Vorname = “Thomas“ Zugeordneter_Prof = “Zuse“
h_da : Firma
WebHackers : Firma
Wert
Student
-Matrikelnummer
+PruefungSchreiben()
Mitarbeiter
-Name -Vorname
Firma
Arbeitsverhältnis
-Einkommen: Geld
1…* 1…*
Arbeitsverhältnis
Stud_Mitarbeiter
-Zugeordneter_Prof
FHJob : Arbeitsverhältnis
Einkommen: Geld = “500“
WebJob : Arbeitsverhältnis
Einkommen: Geld = “400“
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 290
Inhalt
Ein Objektdiagramm enthält
folgende Elemente
Objekt (Instanz von Klassen)
Wert (Instanz von Attributen)
Link (Instanz von Assoziationen)
Ein Objektdiagramm zeigt
Einen „Snapshot“ des Systems
Instanzen zu einem bestimmten Zeitpunkt
eine statische Sicht des Systems zu einem bestimmten Zeitpunkt
Objektdiagramme sind UML-Strukturdiagramme
Objektdiagramme kann man gut zur Herleitung von Multiplizitäten in Klassendiagrammen verwenden! (vgl. „Schnittpunkte und Linien“)
5.4.1 Objektdiagramme in der UML
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 291
Diskussion
Vergleich mit dem Klassendiagramm
Klassendiagramm Objektdiagramm
stellt Vererbungsbeziehungen dar Stellt das Ergebnis der Vererbung dar
Zeigt Assoziationen in der allgemeinen
Form
Zeigt Assoziationen als konkrete Links
zu Objekten
Keine Darstellung von Werten
(außer Defaultwerten)
Konkrete Werte
Abstraktion teilweise schwer zu
verstehen
Unvollständige Darstellung in
„Beispielform“
5.4.1 Objektdiagramme in der UML
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 292
Anwendung
Objektdiagramme sind z. B. in folgenden Situationen nützlich:
zur Dokumentation von Architekturen mit abstrakten Klassen
zur Erläuterung von zirkulären Assoziationen
(z. B. n Personen kennen n Personen)
zur Überprüfung der Modellierung mit konkreten Beispielen
zur Darstellung von konkreten Daten zum Debugging / Testen
Zum Darstellen der Daten- bzw. Objekt-Verteilung in verteilten Systemen
5.4.1 Objektdiagramme in der UML
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 293
5.4.2 Komponentendiagramme in der UML
Objektorientierte Analyse und Design
<<component>>
Downloader
<<component>>
TCPIP
<<component>>
GlassTheme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 294
Notation am Beispiel
5.4.2 Komponentendiagramme in der UML
genutzte
Schnittstelle
(Mund)
bereitgestellte
Schnittstelle
(Lollipop)
<<component>>
WebBrowser
iNetwork
iTheme
iPlugin
Symbol
„Komponente“
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 295
Inhalt
Komponenten
sind modulare Systemteile, die ihren Inhalt kapseln
(und vor dem Benutzer verbergen)
sind eigenständige Anwendungen mit klar definierten
Schnittstellen (bereitgestellte bzw. benutzte Funktionalität)
bestehen aus enthaltenen Klassen oder Komponenten
Ein Komponentendiagramm beschreibt
die Komponenten, ihre Beziehungen und die öffentlichen
Schnittstellen
die (grobe) Struktur eines Systems
wie diese Strukturen erzeugt werden
die physikalischen Bestandteile eines Systems
Komponentendiagramme sind UML-Strukturdiagramme
Anpassung an den Komponenten-Begriff im Sinne
von CORBA, COM, Java,…
Dateien mit Source-Code,
Dokumentation, ByteCode etc.
heißen jetzt Artefakte (stereotyp «artifact»)
5.4.2 Komponentendiagramme in der UML
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 296
Anwendung
Komponentendiagramme sind z. B. in folgenden Situationen nützlich:
Grobentwurf eines größeren Systems (grobe Aufteilung des Systems mit
Zuständigkeiten und Schnittstellen statt detailliertem Entwurf mit Klassen etc.)
Entwicklung von SW-Komponenten zur Wiederverwendung
(Austauschbarkeit von Komponenten als Black-Box)
Verteilte SW-Entwicklung (Darstellung von Schnittstellen)
Entwicklung von SW mit Komponententechnologie
Zuordnung von Klassen zu Quellcodedateien
5.4.2 Komponentendiagramme in der UML
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 297
5.4.3 Paketdiagramme in der UML
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 298
Notation am Beispiel
Implementierung
Software System
5.4.3 Paketdiagramme in der UML
Paket
HMI
GUI Sprachbedienung
Applikation
MegaApp Text2Speech
Treiber
<<import>>
Abhängigkeit
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 299
Inhalt
Ein Paketdiagramm beschreibt
eine Aufteilung des Systems in Gruppen („Pakete“)
– ähnlich zu Ordnern in Dateisystemen
die Pakete und deren Beziehungen untereinander
Anmerkungen
Ein Modellelement darf nur zu einem Paket gehören
Ein Paket definiert einen Namensraum und eine Sichtbarkeit
Pakete können verschachtelt sein
Paketdiagramme sind UML-Strukturdiagramme
5.4.3 Paketdiagramme in der UML
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 300
Anwendung
Paketdiagramme sind z. B. in folgenden Situationen nützlich:
ein großes System soll in handhabbare Arbeitspakete aufgeteilt werden
Modellelemente werden nach Themen gruppiert
(Use Cases, Klassen, Diagramme,…)
funktional
logisch
in Schichten
...
5.4.3 Paketdiagramme in der UML
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 301
5.4.4 Überblick über die Diagramme der UML
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 302
Übersicht der UML-Diagramme
5.4.4 Überblick über die Diagramme der UML
Diagramme
der UML2.x
Verhaltens-
diagramme
Struktur-
diagramme
Interaktions-
diagramme
Klassen-
diagramm
Komponenten-
diagramm
Paket-
diagramm
Objekt-
diagramm
Use Case –
diagramm *
Aktivitäts-
diagramm
Zustands-
diagramm
Sequenz-
diagramm
Kommunikations-
diagramm
Interaktionsübersichts-
diagramm
Timing-
diagramm
* Die Einordnung des Use Case Diagramms ist
strittig. Auch wenn es dabei um das Verhalten geht,
stellt es „nur“ die Struktur von Anwendungsfällen
und Akteuren dar. Damit wäre es eher ein Struktur-
als ein Verhaltensdiagramm.
Kompositions-
strukturdiagramm
Verteilungs-
diagramm
Profil-
diagramm
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 303
Wichtige Diagramme im Vergleich
Use Cases Klassendiagramm Sequenzdiagramm Zustandsdiagramm
Was passiert? Woraus besteht das
System?
Wie passiert es in
einem Einzelfall?
Wie passiert es in
allen Fällen?
Einzelner Ablauf mit
Varianten
keinerlei Ablauf Ein einzelner Ablauf
(Szenario)
Alle möglichen Abläufe
auf einmal
Verbale Beschreibung Formale Darstellung Formale Sequenz Formale Darstellung
System als Black-Box Systembeschreibung System als White-Box System als White-Box
Aktoren und das
System
Klassen mit Attributen
und Methoden &
Assoziationen
Objekte und
Methodenaufrufe
Zustände mit Aktionen,
Aktivitäten und
Übergängen
alle diese Diagramme haben Ihre Stärken und Schwächen… …und sind alle sehr wichtig!
5.4.4 Überblick über die Diagramme der UML
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 304
Diagramme der UML – Anwendung (I)
5.4.4 Überblick über die Diagramme der UML
Diagrammtyp Diese zentrale Frage
beantwortet das Diagramm
Stärken
Klassendiagramm Aus welchen Klassen besteht
mein System und wie stehen
diese untereinander in
Beziehung?
Beschreibt die statische Struktur des Systems.
Enthält alle relevanten
Strukturzusammenhänge / Datentypen.
Brücke zu dynamischen Diagrammen.
Normalerweise unverzichtbar.
Paketdiagramm Wie kann ich mein Modell so
schneiden, dass ich den
Überblick bewahre?
Logische Zusammenfassung von
Modellelementen.
Modellierung von Abhängigkeiten / Inklusion
möglich
Objektdiagramm Welche innere Struktur besitzt
mein System zu einem
bestimmten Zeitpunkt zur
Laufzeit (Klassendiagramm-
schnappschuss)?
Zeigt Objekte und Attributbelegungen zu einem
bestimmten Zeitpunkt.
Verwendung beispielhaft zur
Veranschaulichung.
Detailniveau wie im Klassendiagramm.
Sehr gute Darstellung von
Mengenverhältnissen.
Quelle: „UML 2 –Ballast oder Befreiung?“ von Chris Rupp, SOPHIST GROUP, Agility Days 2003
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 305
Diagramme der UML – Anwendung (II)
5.4.4 Überblick über die Diagramme der UML
Diagrammtyp Diese zentrale Frage
beantwortet das Diagramm
Stärken
Kompositionsstruktur-
Diagramm
Wie sieht das Innenleben einer
Klasse, einer Komponente,
eines Systemteils aus?
Ideal für die Top-Down-Modellierung des
Systems (Ganz-Teil-Hierarchien).
Zeigt Teile eines „Gesamtelements“ und deren
Mengenverhältnisse.
Präzise Modellierung der Teile Beziehungen
über spezielle Schnittstellen (Ports) möglich.
Komponentendiagramm Wie werden meine Klassen zu
wieder verwendbaren,
verwaltbaren Komponenten
zusammengefasst und wie
stehen diese in Beziehung?
Zeigt Organisation und Abhängigkeiten
einzelner technischer Systemkomponenten.
Modellierung angebotener und benötigter
Schnittstellen möglich.
Verteilungsdiagramm Wie sieht das Einsatzumfeld
(Hardware, Server, Daten-
banken, ...) des Systems aus?
Wie werden die Komponenten
des Systems zur Laufzeit wohin
verteilt?
Zeigt das Laufzeitumfeld des Systems mit den
„greifbaren“ Systemteilen.
Hohes Abstraktionsniveau, kaum
Notationselemente.
Quelle: „UML 2 –Ballast oder Befreiung?“ von Chris Rupp, SOPHIST GROUP, Agility Days 2003
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 306
Diagramme der UML – Anwendung (III)
5.4.4 Überblick über die Diagramme der UML
Diagrammtyp Diese zentrale Frage
beantwortet das Diagramm
Stärken
Use-Case-Diagramm Was leistet mein System für
seine Umwelt (Nachbarsysteme,
Stakeholder)?
Außensicht auf das System.
Geeignet zur Kontextabgrenzung.
Hohes Abstraktionsniveau, einfache
Notationsmittel.
Aktivitätsdiagramm Wie läuft ein bestimmter
flussorientierten Prozess oder ein
Algorithmus ab?
Sehr detaillierte Visualisierung von Abläufen mit
Bedingungen, Schleifen, Verzweigungen.
Parallelisierung und Synchronisation.
Darstellung von Datenflüssen.
Zustandsautomat Welche Zustände kann ein
Objekt, eine Schnittstelle, ein
Use Case,... bei welchen
Ereignissen annehmen?
Präzise Abbildung eines Zustandsmodells mit
Zuständen, Ereignissen, Nebenläufigkeiten,
Bedingungen, Ein- und Austrittsaktionen.
Schachtelung möglich.
Sequenzdiagramm Wer tauscht mit wem welche
Informationen in welcher
Reihenfolge aus?
Darstellung des Informationsaustauschs
zwischen Kommunikationspartnern.
Sehr präzise Darstellung der zeitlichen Abfolge
auch mit Nebenläufigkeiten.
Quelle: „UML 2 –Ballast oder Befreiung?“ von Chris Rupp, SOPHIST GROUP, Agility Days 2003
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 307
Diagramme der UML – Anwendung (IV)
5.4.4 Überblick über die Diagramme der UML
Diagrammtyp Diese zentrale Frage
beantwortet das Diagramm
Stärken
Kommunikationsdiagr. Wer arbeitet mit wem? Wer
„arbeitet“ im System zusammen?
Stellt den Informationsaustausch zwischen
Kommunikationspartnern dar. Der Überblick steht
im Vordergrund (Details und zeitliche Abfolge ist
weniger wichtig).
Timingdiagramm Wann befinden sich verschiedene
Interaktionspartner in welchem
Zustand?
Visualisiert das exakte zeitliche Verhalten von
Klassen, Schnittstellen,... Geeignet für die
Detailbetrachtungen, bei denen es wichtig ist,
dass ein Ereignis zum richtigen Zeitpunkt eintritt.
Interaktionsüber-
sichtdiagramm Wann läuft welche Interaktion ab? Verbindet Interaktionsdiagramme (Sequenz-,
Kommunikations- und Timingdiagramme) auf Top-
Level-Ebene.
Hohes Abstraktionsniveau.
Profildiagramm Wie wurde die UML für dieses
Projekt angepasst?
(z. B. durch neue Stereotypen)
Darstellung von verwendeten UML-Profilen.
Erfordert Verständnis des UML Meta-Modells.
Erst seit UML 2.2 vorhanden.
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 308
5.4.4 Überblick über die Diagramme der UML
Wann verwende ich welches Diagramm?
Es gibt oft verschiedene Diagramme um ähnliche Sachverhalte darzustellen
z. B. Sequenzdiagramm vs. Kommunikationsdiagramm
Die gleiche Diagrammart kann in verschiedenen Entwicklungsphasen verwendet
werden
z. B. das Klassendiagramm in der Analyse und im Design
die Art des Einsatzes ist dann unterschiedlich
Ein Diagramm stellt in der Regel nur einen speziellen Ausschnitt des Systems
dar
Die Notwendigkeit einiger Diagramme hängt vom konkreten Projekt ab
z. B. Verteilungsdiagramm bei Einzelplatzanwendung oft nicht nötig
Die Anzahl der zu erstellenden Diagramme hängt von der Komplexität / dem
Kommunikationsbedarf im Projekt uvm. ab
Die Diagramme entstehen nach Bedarf
Die Festlegung der „erlaubten“ Diagrammtypen erfolgt oft im Projekt
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 309
6. Welches Design ist das Richtige?
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 310
Zur Erinnerung: Grundidee OOAD
Problem: Wie entwickle ich ein komplexes System?
Analysiere die reale Welt
Abstrahiere daraus ein Modell mit den
wesentlichen Daten und Klassen (Objekten)
und deren Beziehungen zueinander
Entwerfe ein detailliertes Modell, das
auf dem abstrakten Modell basiert
Setze das Ergebnis um Arzt.cpp
6. Welches Design ist das Richtige?
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 311
Zwischenstand
Sie kennen nun:
OOA, OOD, (OOP)
Dokumentation durch UML, Diagramme, Text
Bisher eher an Ausdrucksmöglichkeiten interessiert
weniger an der Sinnhaftigkeit
Sie wissen jetzt wie man Analyse und Designergebnisse dokumentiert
weitgehend unabhängig von Qualitätsanforderungen
6. Welches Design ist das Richtige?
Aber wie macht man GUTES Design?
Woran erkennt man ein gutes bzw. schlechtes Design?
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 312
Gutes Design vs. schlechtes Design
Gutes Design
Bietet die Funktionalität, die gewünscht
ist und nicht (viel) mehr
Ist leicht zu verstehen und adäquat
dokumentiert
Enthält keine unnötig redundanten
Elemente
Bereits absehbare Änderungen
können leicht integriert werden
Änderungen betreffen lediglich die
Systemteile, in denen sie auftreten
Der Aufwand, den eine Änderung
verursacht, ist proportional zur Größe
der Änderung
Schlechtes Design
Bietet nicht die Funktionalität, die
gefordert wurde oder
mehr Funktionalität als gefordert wurde
Enthält Elemente, die für andere
Designer nicht verständlich sind
Erfordert zusätzlich spezielles oder
undokumentiertes Know-how
Änderungen lösen Dominoeffekte aus
und betreffen verschiedene Teile
Geringfügige Änderungen der
Anforderungen verursachen große
Aufwände
In simple terms, OOAD is the art of designing and building programs for an extended lifetime (http://www.ooad.org)
6. Welches Design ist das Richtige?
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 313
Grundlegende Ziele im Design
Pflicht für die Akzeptanz des Systems
durch Kunden / Auftraggeber / Markt Funktionserfüllung
Erweiterbarkeit
Zuverlässigkeit
Wartbarkeit
Das System muss zuverlässig
funktionieren
Erweiterungen (in der Wartung) sollten
mit adäquatem Aufwand funktionieren
Entwerfe das System so, dass die
Wartung möglichst günstig ist
Neben diesen grundlegenden Zielen gibt es noch viele weitere
„Qualitätseigenschaften“ eines Systems, die – je nach Projekt –
ebenfalls sehr wichtig sind!
6. Welches Design ist das Richtige? Design is not just what it looks like
and feels like. Design is how it works. Steve Jobs
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 314
Überblick Qualitätseigenschaften
Qualitätsmerkmale aus
Benutzersicht
Qualitätsmerkmale aus
Entwicklersicht
Funktionserfüllung
HW-Effizienz Effizienz
Zuverlässigkeit
Benutzbarkeit
Sicherheit
Erweiterbarkeit
Wartbarkeit
Übertragbarkeit
Wiederverwendbarkeit
Testbarkeit
SW-Effizienz (Performance)
Robustheit
Fehlertoleranz
Änderbarkeit
Verständlichkeit
6. Welches Design ist das Richtige?
Catalog
- Topic - Inventory
+ getCatalog() + setCatalog()
Person
- Name - User_ID - ...
+ getPerson() ...
Item
- Titel - ISBN
Author - Publisher - Cost - Date_In - Qty - ...
+ getItem() + setItem()
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 315
Beispiel für ein schlechtes Design
Funktionserfüllung Zuverlässigkeit
Wartbarkeit Erweiterbarkeit
6. Welches Design ist das Richtige?
Bibliotheks-
verwaltung
Was ist schlecht an diesem Entwurf ?
*
*
*
Library_Main_Control
- Current_Catalog - Current_Item - User_ID - Fine_Amount - ...
- Do_Inventory() - Check_Out_Item(Item) - Check_In_Item(Item) - Add_Item(Item) - Delete_Item(Item) - Print_Catalog() - Sort_Catalog() - Search_Catalog(Params) - Edit_Item() - Find_Item() - Print() - Open_Library() - List_Catalogs() - Issue_Library_Card() - Archive_Catalogs() - Calculate_Late_Fine() - ...
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 316
Das Beispiel – eine überarbeitete Lösung
*
* *
*
Verbesserte Wartung,
Modifizierbarkeit,
Wiederverwendbarkeit...
6. Welches Design ist das Richtige?
Person
- Name - User_ID - Items_Out - Fines
+ getName() - calculateFine()
Library_Main_Control
- Current_Catalog - Current_Item - ...
+ Do_Inventory() + Search_Catalog(Params) + Print() + Open_Library() + Issue_Library_Card() + Calculate_Late_Fine() + ...
Catalog
- Topic - Inventory
+ Print_Catalog() + Sort_Catalog() + List_Catalogs() + Archive_Catalogs()
Checked_Out_Item
- Item - Due_Date - Holder
+ Check_In()
Item
- Titel - ISBN
Author - Publisher - Cost - Date_In - Qty - ...
+ Check_Out_Item() + Check_In_Item() + Add_Item() + Delete_Item() + Edit_Item() + Find_Item()
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 317
Wege zu einem guten Design
Was kann man tun?
Prinzipien lernen Designprinzipien
aus eigenen Fehlern lernen Üben
Regeln oder Tipps und Tricks lernen (Best Practices) Regeln
Bekannte (und gute) Lösungen einsetzen Design Patterns
aus bekannten Fehlern lernen Anti Patterns
6. Welches Design ist das Richtige?
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 318
Literatur
Johannes Siedersleben: Moderne Software-Architektur, dpunkt-Verlag, 2004
Brett D. McLaughlin, G. Pollice, D. West:
Objektorientierte Analyse & Design von Kopf bis Fuß,
O'REILLY, 2007
6. Welches Design ist das Richtige?
Andrew Hunt, David Thomas: Der pragmatische Programmierer,
Hanser Fachbuch, 2003
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 319
Lernziel
Sie sollen in diesen Kapitel verstehen,
Welche Grundprinzipien beim Entwurf gelten
Welche Regeln es zum Entwurf von Klassen und Assoziationen gibt
Welche Regeln es beim Entwurf von Operationen und Schnittstellen gibt
Was Entwurfsmuster (Design Patterns) sind
Anschließend können Sie besser entscheiden was ein guter bzw. schlechter Entwurf ist!
6. Welches Design ist das Richtige?
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 320
6.1 Grundprinzipien für das Design
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 321
Idee für das 1. Grundprinzip
Speziell für Klassen: „Starker Zusammenhalt“ (Strong Cohesion)
Kohäsion ist ein Maß dafür, wie eng die Beziehungen und der Fokus der
Verantwortlichkeiten einer Klasse sind
- Schwache Kohäsion:
• Eine Klasse ist verantwortlich für viele Aufgaben
- Starke Kohäsion:
• Jede Methode einer Klasse hat einen einzigen, klaren Zweck und
• die Operationen bilden eine Gruppe zusammengehörender Aufgaben
6.1 Grundprinzipien für das Design
Trenne das, was nicht zusammen gehört – oder andersrum:
Sorge dafür, dass (innerhalb einer Klasse) alles stark zusammenhängt!
EierlegendeWollmilchSau
+ legeEier () + gibMilch () + gibWolle () + gibFleisch ()
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 322
Grundprinzip 1: Trennung von Zuständigkeiten (Separation of Concerns)
Unterteile das System so in Teile, dass jeder Teil genau eine Aufgabe hat!
Diese Aufgabe wird auch nur von diesem Teil erledigt
Die Abgrenzung gegenüber anderen Teilen ist klar erkennbar
Die Aufgabe ist genau und prägnant definiert und spiegelt sich
im Namen des Teils wider
Trenne Teile an denen sich (voraussichtlich) keine Änderungen ergeben, von
Teilen an denen sich wahrscheinlich Änderungen ergeben!
Vorteile von getrennten Zuständigkeiten:
Ein Systemteil, der nur eine Zuständigkeit hat, ändert sich nur, wenn an dieser
einen Zuständigkeit eine Änderung nötig wird!
6.1 Grundprinzipien für das Design
Trennung von Zuständigkeiten fördert
die Wartbarkeit (Gute Verständlichkeit),
Erweiterbarkeit und Wiederverwendbarkeit!
Speziell für Klassen: „Schwache Kopplung“ (Loose Coupling)
Kopplung ist ein Maß dafür, wie sehr ein Element von anderen abhängt
Klasse A ist von B abhängig, wenn:
- A hat ein Attribut vom Typ B oder verwendet eine Methode eines Objekts vom Typ B
- A hat eine Methode mit Parameter/Return vom Typ B
- A ist von B abgeleitet oder A implementiert die Schnittstelle von B
Das Prinzip der schwachen Kopplung fordert Klassen so zu definieren, dass nur
die nötige Kopplung da ist
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 323
Idee für das 2. Grundprinzip
6.1 Grundprinzipien für das Design
Ein System ist schwer zu handhaben,
wenn jeder jeden kennt!
Reduziere die Anzahl der Beziehungen
auf das Nötige! C
+ f(): B* + g(d: D) + h(a: A*)
D
+ f(): B* + g(c: C) + h(a: A*)
B
+ f(): A*; + g(d: D) + h(c: C*)
A
+ f(): B* + g(d: D) + h(c: C*)
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 324
Grundprinzip 2: Minimierung von Abhängigkeiten
Minimiere die Abhängigkeiten zwischen Systemteilen!
fasse stark zusammenhängende Teile zusammen
überprüfe die Verantwortlichkeiten auf eine saubere Trennung
entkopple abhängige Teile (evtl. durch Auslagerung in einen neuen Teil)
Vorteile von minimierten Abhängigkeiten:
Veränderungen eines Systemteils tangieren nur wenige andere Klassen!
6.1 Grundprinzipien für das Design
Minimierung von Abhängigkeiten fördert die
Verständlichkeit, Wiederverwendbarkeit und Wartbarkeit!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 325
Idee für das 3. Grundprinzip
Eselsbrücke „Geheimagenten-Prinzip“:
Jeder „verrät“ nur das, was ein anderer wissen muss, um mit ihm zu arbeiten!
Jeder „weiß“ nur das, was er wissen muss, um seinen Job zu machen!
6.1 Grundprinzipien für das Design
Class Diagram: CRM
Die aufrufenden Objekte erfahren, dass
die Umsetzung über einen Stack erfolgt.
Die aufrufenden Objekte müssen sogar
Stackoperationen verwenden und die
Funktionsweise eines Stacks verstehen
Änderungen werden erschwert, wenn
die interne Realisierung eines Systemteils
anderen Systemteilen bekannt ist und diese
die Interna ansprechen und verwenden!
CustomerStack
+push(name: string , address: string ) +getPositionInStack(name: string ): int +modify(position: int, address: string )
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 326
Grundprinzip 3: Geheimnisprinzip („Information Hiding“)
Kapsele das interne Wissen eines Systemteils und verrate es niemand
anderem!
Abläufe, Daten und Strukturen sind gekapselt
Systemteile sind benutzbar ohne Kenntnis der Realisierung
interne Änderungen sind von außen nicht sichtbar
Umsetzung in C++:
Sichtbarkeit „private“ für alle Attribute und interne Methoden
Vorteile des Geheimnisprinzips:
unterstützt Trennung von Zuständigkeiten und Minimierung der Abhängigkeiten
erleichtert verteilte Entwicklung
6.1 Grundprinzipien für das Design
Das Geheimnisprinzip fördert die
Wartbarkeit, Änderbarkeit und Testbarkeit!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 327
Idee für das 4. Grundprinzip
6.1 Grundprinzipien für das Design
Ein uneinheitlicher Entwurf
erschwert das Verständnis!
If it hurts, don't do it!
Die Komponenten des Systems haben stark
unterschiedliche Komplexität
(erkennbar an der Zahl von Attributen und
Methoden der Gesamtkontrolle im Vergleich
zu den einfachen Datenhaltungsklassen)
Library_Main_Control
- Current_Catalog - Current_Item - User_ID - Fine_Amount - Etc. - ...
- Do_Inventory() - Check_Out_Item(Item) - Check_In_Item(Item) - Add_Item(Item) - Delete_Item(Item) - Print_Catalog() - Sort_Catalog() - Search_Catalog(Params) - Edit_Item() - Find_Item() - Print() - Open_Library() - List_Catalogs() - Issue_Library_Card() - Archive_Catalogs() - Calculate_Late_Fine() - ...
Topic
- Topic
+ getTopic() + setTopic()
Inventory
- Inventory
+ getInventory() + setInventory()
Person
- Name - User_ID
+ setPerson()
*
*
*
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 328
Grundprinzip 4: Homogenität
Löse ähnliche Probleme mit ähnlichen Lösungen und verwende ähnliche
Strukturierungsgrößen innerhalb einer Strukturierungsebene!
verwende bereits bekannte Lösungen erneut – sofern es keine wichtigen Gründe
für eine andere Lösung gibt
entwerfe Systemteile innerhalb einer Strukturierungsebene
(z. B. Anwendungsschicht) so, dass die Größe und Komplexität
ungefähr gleich ist
verwende bei Bedarf mehrere – jeweils homogene – Strukturierungsebenen
Vorteile der Homogenität:
vermeidet unnötiges Neuerfinden von vorhandenen Lösungen
erleichtert die Entscheidungsfindung
6.1 Grundprinzipien für das Design
Homogenität fördert die
Wartbarkeit und die Verständlichkeit!
CustomerManager
// Die Verwaltung der Kunden erfolgt so, dass...
// ... dabei ist zu beachten ...
CustomerManager
// Die Verwaltung der Kunden erfolgt so, dass... // ... dabei ist zu beachten .
- ...
CustomerUser
// Dies muss so sein, weil die Verwaltung der // Kunden so erfolgt, dass... // ... dabei ist zu beachten ...
- ...
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 329
Idee für das 5. Grundprinzip
6.1 Grundprinzipien für das Design
Know-how (in jeglicher Form), das an
mehreren Stellen im Entwurf auftaucht,
wird früher oder später inkonsistent
und führt zu Problemen!
If it hurts, don't do it!
Die spezielle Art der Kundenverwaltung
wird an mehreren Stellen berücksichtigt
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 330
Grundprinzip 5: Redundanzfreiheit (DRY – Don’t Repeat Yourself)
Entwerfe das System so, dass jedes Stück Know-how in dem System nur an
genau einer Stelle umgesetzt wird, die eindeutig und zuständig ist!
Damit ist nicht nur Code gemeint! Es kann sich um alle Teile handeln, in denen
Know-how steckt – also auch um Teile des Entwurfs, ein Datenbankschema oder
auch die Dokumentation
ziehe mehrfach verwendete Teil heraus und mache sie für andere verfügbar
finde eine eindeutige und sinnvolle „Heimat“ für das Know-how
vermeide „Copy & Paste – Entwicklung“
Vorteile der Redundanzfreiheit:
fördert die Trennung der Zuständigkeiten (man muss sich entscheiden)
Korrekturen müssen nur noch an einer Stelle erfolgen
6.1 Grundprinzipien für das Design
Redundanzfreiheit fördert die
Wiederverwendbarkeit, Wartbarkeit und die Verständlichkeit!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 331
Zusammenfassung der Grundprinzipien
5 Grundprinzipien
Trennung von Zuständigkeiten (Kohäsion / Zusammenhalt)
Minimierung von Abhängigkeiten (schwache Kopplung)
Geheimnisprinzip
Homogenität
Redundanzfreiheit
Es gibt weitere Prinzipien bzw. diverse Varianten dieser Prinzipien
die Kernaussage bzw. Zielrichtung ist allerdings seit vielen Jahren unumstritten
Diese Grundprinzipien sind anwendbar
für implementierungsnahen Entwurf („Feinentwurf“)
aber auch für viele andere Strukturierungsprobleme (z. B. „Software Architektur“)
6.1 Grundprinzipien für das Design
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 332
6.2 Regeln zum Entwurf von Klassen
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 333
Zur Erinnerung: Schritte zum Entwickeln von Klassendiagrammen
1. Klassen(kandidaten) finden
Substantive bestimmen
überflüssige Begriffe rausfiltern
Attribute identifizieren
Operationen über Verben suchen
2. Vererbungsbeziehungen suchen
Ähnliche Klassen identifizieren (Aber: „Ist-ein-Regel“ beachten!)
Evtl. Schnittstellen durch abstrakte Klasse + Vererbung definieren
3. Assoziationen zwischen Klassen bestimmen
„Kennt“-Beziehungen: normale Assoziation
„Besteht aus“-Beziehung: Aggregation bzw. Komposition
evtl. Leserichtung und Rollen angeben
Objekte, deren Existenz an einer Assoziation hängt: Assoziationsklasse
4. Multiplizitäten und Navigationsrichtungen eintragen
6.2 Regeln zum Entwurf von Klassen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 334
Entwurf von Klassen
Bisher kennen Sie ein „Standardverfahren“ zur Bestimmung von Klassen
und den Beziehungen dazwischen
es geht darum, die Klassen so zu entwerfen, dass die Qualitätsanforderungen
möglichst gut erfüllt werden
aber es gibt immer viele verschiedene Lösungen mit unterschiedlichen
Eigenschaften, welche die Qualitätseigenschaften mehr oder weniger gut erfüllen
Wir betrachten nun einige Beispiele und
erarbeiten jeweils eine (naheliegende) Lösung
analysieren die Nachteile dieser Lösung
diskutieren eine zweite Lösung, welche die Nachteile nicht hat
leiten daraus eine Regel für den Entwurf von Klassen ab
6.2 Regeln zum Entwurf von Klassen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 335
Aufgabe 1
Modellieren Sie folgenden Sachverhalt:
Ein Softwaresystem für eine Firma soll Kunden, Lieferanten und Mitarbeiter
verwalten
Alle werden durch Name und Adresse identifiziert
Ein Mitarbeiter ist entweder Arbeiter oder Manager
Prüfen Sie, wie die folgenden naheliegenden Punkte mit Ihrer Lösung umgesetzt
werden können:
Kunden können gleichzeitig auch Lieferanten sein
Arbeiter können zu Managern befördert werden
In Zukunft können auch weitere Personen wie Gesellschafter etc., aber auch
weitere Laufbahnstufen wie Ingenieur etc. relevant werden
6.2 Regeln zum Entwurf von Klassen
Huber: Kunde
name = “Huber“ adresse =“Huberweg“
Huber: Lieferant
name = “Huber“ adresse =“Huberweg“
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 336
Lösung A: mit Generalisierung / Spezialisierung
Object Diagram Person mit Vererbung
Name und Adresse sind
redundant, wenn Huber
sowohl Kunde als auch
Lieferant ist.
Bei der Beförderung von Schmidt
vom Arbeiter zum Manager muss das
Arbeiter-Objekt gelöscht, ein neues
Manager-Objekt angelegt und alle
Attribute vom Arbeiter- zum
Manager-Objekt kopiert werden.
Einfügen neuer Personen wie Gesellschafter etc.,
oder weiterer Laufbahnstufen wie Ingenieur etc.
erfordern eine strukturelle Änderung des Modells.
6.2 Regeln zum Entwurf von Klassen
Person
-name : string -adresse : string
Kunde Mitarbeiter Lieferant
Manager Arbeiter Schmidt: Arbeiter
name = “Schmidt“ adresse =“Schmidtweg“
SchmidtNeu: Manager
name = “Schmidt“ adresse =“Schmidtweg“
Kunde: Rolle
typ = “Kunde“
Lieferant: Rolle
typ = “Lieferant“
Schmidt: Person
name = “Schmidt“ adresse =“Schmidtweg“
Rolle
-typ: enum {Kunde, Lieferant, Arbeiter, Manager}
Person
-name : string -adresse : string
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 337
Lösung B: Mit Assoziation (bzw. Komposition, Aggregation)
Class Diagram Person mit Assoziation
*
Object Diagram Person mit Assoziation
Dieselbe Person kann verschiedene
Rollen haben. Name und Adresse
werden nur einmal gespeichert.
Die Beförderung vom Arbeiter zum
Manager wird durch Änderung des
Attribut-Typs dargestellt
Neue Rollen wie Gesellschafter
etc. können durch einfache
Erweiterung des Aufzählungstyps
dargestellt werden
6.2 Regeln zum Entwurf von Klassen
Warum nicht als Attribut Rolle[ ] in Person?
Huber: Person
name = “Huber“ adresse =“Huberweg“
Alt: Rolle
typ = “Arbeiter“
Neu: Rolle
typ = “Manager“
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 338
Regel 1: Setze Vererbung (Generalisierung / Spezialisierung) sparsam ein
Vererbung (Generalisierung / Spezialisierung) ist das am meisten überschätzte
und überbenutzte Konzept der Objekt-Orientierung
Setze Vererbung nur bei echter „ist ein“ Beziehung ein
Ersetze, wo sinnvoll möglich, eine Vererbung durch eine Assoziation
Beispiele:
Ein Kunde ist eine Person eine Person hat die Rolle Kunde
Eine Frau ist eine Person eine Person hat das Geschlecht weiblich
Ein Rothaariger ist eine Person eine Person hat die Haarfarbe rot
Verwende nur einfache Vererbung (Single Inheritance)
Bei der Einfachvererbung hat man nur einen Schuss – und der muss sitzen!
Schachtele Vererbungsbäume nicht zu tief
Tiefe 2-3 reicht meistens aus
Sparsame Verwendung von Vererbung fördert
die Einfachheit und Erweiterbarkeit von Modellen!
6.2 Regeln zum Entwurf von Klassen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 339
Aufgabe 2
Modellieren Sie folgenden Sachverhalt:
In einem MP3-Archiv sollen Lieder gespeichert werden
Für jedes Lied soll der Titel des Lieds, der Interpret und der Name des Albums
gespeichert werden
Prüfen Sie, wie die folgenden naheliegenden Punkte mit Ihrer Lösung umgesetzt
werden können:
Wurde der Name des Interpreten oder des Albums falsch geschrieben, so kann
dies leicht korrigiert werden
In der nächsten Version sollen zu einem Album weitere Daten gespeichert
werden wie z. B. das Genre (Klassik, Rock, ...)
6.2 Regeln zum Entwurf von Klassen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 340
Lösung A: mit Redundanzen
Class Diagram Lied
- titel: String
Object Diagram Lied
Ist der Name des Interpreten oder das Album
falsch geschrieben, so muss dies in allen
Objekten vom Typ Lied korrigiert werden.
Inkonsistente Einträge können leicht entstehen.
Sollen zum Album weitere Daten gespeichert
werden wie z. B. das Genre, so muss das
(redundant) in allen Liedern erfolgen.
6.2 Regeln zum Entwurf von Klassen
Lied
-interpret : string -album : string -titel : string
Not That Kind : Lied
album = “Not That Kind“
interpret = “Anastacia“
I‘m Outta Love : Lied
album = “Not that Kind“
interpret = “Anastacia“
Cowboys & Kisses : Lied
album = “Not That Kind“
interpret = “Anastasia“
Shine On You Crazy : Lied
album = “Wish You Were Here“
interpret = “Pink Floyd“
Album
-titel: string
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 341
Lösung B: normalisiert
Class Diagram Lied normalisiert
Interpret
- name: String 1..*
◄ von
Object Diagram Lied normalisiert
Ist der Name des Interpreten oder das Album
falsch geschrieben, so muss dies nur im Objekt
Interpret bzw. Album korrigiert werden.
Sollen zum Album weitere Daten gespeichert
werden wie z. B. das Genre, so muss das nur
einmal im Album-Objekt erfolgen.
6.2 Regeln zum Entwurf von Klassen
„Normalisierung“ reduziert
Redundanzen:
siehe Vorlesung Datenbanken!
Interpret
-name: string
Lied
-titel: string
I1: Interpret
name= “Anastacia“
A1: Album
titel= “Not That Kind“
L1: Lied
titel=“Not That Kind“
L2: Lied
titel=“I'm Outta Love“
L3: Lied
titel=„Cowboys&Kisses“
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 342
Regel 2: Normalisiere das Datenmodell
Bringe das Datenmodell in eine Normalform
1. Normalform:
Jedes Attribut der Relation muss einen atomaren Wertebereich haben
(vgl. Rolle als Komposition zu Person statt als Attribut)
2. Normalform:
jedes Nichtschlüsselattribut ist von jedem Schlüsselkandidaten voll funktional
abhängig
3. Normalform:
kein Nichtschlüssel hängt von irgendeinem Schlüsselkandidaten
transitiv ab
Normalisiere das Datenmodell, soweit fachlich sinnvoll
Meist reicht die 3. Normalform aus
Eine formale Betrachtung ist nicht notwendig
Die Normalisierung das Datenmodells
reduziert Redundanzen!
6.2 Regeln zum Entwurf von Klassen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 343
Aufgabe 3
Modellieren Sie folgenden Sachverhalt aus einem Auftragssystem:
Kunden können Bestellungen aufgeben
Mehrere Bestellungen zusammen bilden einen Auftrag
Ein Auftrag bezieht sich immer auf einen Kunden
6.2 Regeln zum Entwurf von Klassen
Bestellung
-B_Nr: int
K2: Kunde
name= “Huber“
K1: Kunde
name= “Müller“
B1: Bestellung
B_Nr= 17
A1: Auftrag
Datum=01.04.14
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 344
Lösung A: Transitive Assoziationen
Class Diagram Bestellung mit Zykel
1
gibt auf
* *
▲ von
1
*
1
Object Diagram Bestellung mit Zykel
▲ von gibt auf
Müller hat den Auftrag für Hubers Bestellungen. Das ist
natürlich fachlich falsch. Das Datenmodell erlaubt es aber.
Das Modell könnte durch eine entsprechende
Einschränkung (Constraint) korrigiert werden, aber es gäbe
immer noch eine redundante Assoziation.
6.2 Regeln zum Entwurf von Klassen
Kunde
-name: string
Auftrag
-Datum: date
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 345
Lösung B: Ohne transitive Assoziationen
Class Diagram Bestellung ohne Zykel
Object Diagram Bestellung ohne Zykel
Der Kunde als Auftraggeber ist
nun eindeutig bestimmt
6.2 Regeln zum Entwurf von Klassen
Bestellung
-B_Nr: int
*
▲ von
1
*
1
Kunde
-name: string
Auftrag
-Datum: date
K1: Kunde
name= “Müller“
B1: Bestellung
B_Nr= 17
A1: Auftrag
Datum=01.04.14
▲ von
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 346
Regel 3: Vermeide transitive Assoziationen
Zyklen bieten mehrere Wege für eine Beziehung
zwischen zwei Objekten
in Lösung A gibt es
- die direkte Beziehung „gibt auf“ von Kunde zu Bestellung
- eine Beziehung von Kunde über Auftrag zu Bestellung
falls auf den Wegen eine 1:n Beziehung liegt, kann man die Beziehungen mit
unterschiedlichen Objekten assoziieren (wie in Lösung A)
Vermeide transitive Assoziationen
Zyklen können meist durch Weglassen von (redundanten) Assoziationen
aufgelöst werden
Falls Zyklen nicht vermeidbar sind, müssen Widersprüche über Constraints
ausgeschlossen werden
z. B. Kunde der Bestellung muss gleich sein dem Kunden des Auftrags
Zyklenfreiheit reduziert Redundanzen und
erhöht die Korrektheit!
6.2 Regeln zum Entwurf von Klassen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 347
Aufgabe 4
Es soll ein Customer Relation Management (CRM) für einen Reiseveranstalter
entworfen werden. Modellieren Sie folgenden Sachverhalt:
Reisende können viele Reisen buchen (d. h. Reiseaufträge erteilen)
Ein Reiseauftrag kann mehrere Reisende umfassen
Prüfen Sie, wie der folgende naheliegende Punkt mit Ihrer Lösung umgesetzt
werden kann:
Das System soll in der Wartungsphase so umgebaut werden, dass zusätzlich der
Status eines Visa für jede Reise und jeden Reisenden erfasst werden kann
6.2 Regeln zum Entwurf von Klassen
V2: Visum
Inhaber=„Mayer“
K1: Kunde
name= “Huber“
K2: Kunde
name= “Mayer“
R1: Reiseauftrag
ziel= “Mallorca“
R2: Reiseauftrag
ziel= “Indien“
R3: Reiseauftrag
ziel= “Russland“
V1: Visum
Inhaber=„Huber“
Kunde
-name: string
Reiseauftrag
-ziel: string
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 348
Lösung A: m:n-Beziehungen
Object Diagram: CRM mit m:n Beziehungen Class Diagram: CRM mit m:n Beziehungen
1..*
*
Ein Visum ist abhängig vom Reisenden und vom
Reiseziel. Der Zustand muss in einer Assoziationsklasse
abgespeichert werden!
Das erfordert allerdings in der Realisierung eine neue
Klasse und Änderungen an Reisender oder Reiseauftrag!
6.2 Regeln zum Entwurf von Klassen
RV1: Reise-
voraussetzung
Visum=ok
RV2: Reise-
voraussetzung
Visum=ok
RV3: Reise-
voraussetzung
Visum=beantragt
RV4: Reise-
voraussetzung
Visum=offen
Reisevoraussetzung
- Visum_Status: enum
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 349
Lösung B: m:n-Beziehungen aufgelöst Class Diagram: CRM mit 1:n Beziehungen
Zu einem Reiseauftrag können nun für alle Kunden die
Reisevoraussetzungen gespeichert werden.
Damit keine transitive Assoziation entsteht, wird die Assoziation
zwischen Reiseauftrag und Kunde jetzt über die Reisevoraussetzung
geführt.
6.2 Regeln zum Entwurf von Klassen
*
1..*
1
Object Diagram: CRM mit 1:n Beziehungen
Huber:
Reisender
1
Kunde
-name: string
Reiseauftrag
-ziel: string
K1: Kunde
name= “Huber“
K2: Kunde
name= “Mayer“
R1: Reiseauftrag
ziel= “Mallorca“
R2: Reiseauftrag
ziel= “Indien“
R3: Reiseauftrag
ziel= “Russland“
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 350
Regel 4: Analysiere m:n-Beziehungen genau
Hinter m:n-Beziehungen können sich leicht Probleme verbergen
Hinter m:n-Beziehungen stecken oft eigenständige Klassen (vgl. Assoziations-
klassen) oder auch Attribute, die in der Analyse nicht aufgetaucht sind
- entdeckt man solche Klassen oder Attribute erst in der Wartungsphase, entsteht
unerwünschter Aufwand, weil die Änderung mehrere Klassen betrifft
Das gezielte Hinterfragen der m:n-Beziehung löst im Beispiel das Problem:
- „Gibt es irgendetwas das jeder einzelne Reisende für eine Reise braucht?“ liefert
„Ja, für diverse Länder braucht man ein spezielles Visum“ ( Reisevoraussetzung)
Wandle m:n-Beziehungen um, wenn es sinnvoll erscheint
Löse m:n-Beziehungen in (mehrere) 1:n-Beziehungen auf
Füge dazu neue Klassen ein (vgl. Umsetzung von Assoziationsklassen in C++)
und finde fachlich passende Begriffe für die neuen Entitäten.
- Manchmal gibt es noch keinen Begriff für die neue Entität. Dieser sollte dann
zusammen mit der Fachabteilung festgelegt werden
- Häufig enthalten die neu entstehenden Entitäten weitere fachliche Informationen
(z. B. ein Datum).
6.2 Regeln zum Entwurf von Klassen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 351
Weitere Regeln - eigentlich selbstverständlich, aber …
Vermeide 1:1-Beziehungen
Stehen zwei Entitäten in einer 1:1-Beziehung, so sollte man sie – sofern fachlich
sinnvoll – in eine Entität zusammenfassen. Das vereinfacht das Modell.
Beispiel: Auftrag und Auftragskopf Auftrag
Modelliere nur fachliche, nie technischen Aspekte
Beispiel: Eine Entität „Liste“ oder gar „VerketteteListe“ gibt es nicht
Beschränke Dich auf das für das System Notwendige
Beispiel: Sollen für einen Reisekatalog die Ausstattungen von Hotels (Pool,
Sauna, Tennis, etc.) modelliert werden, so sind nur die Kategorien relevant.
Irrelevant ist hier, dass Tennis eine Sportart ist, ob Pool und Saunabereich
aneinander grenzen etc.
6.2 Regeln zum Entwurf von Klassen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 352
Zusammenfassung der Regeln
Regeln zum Entwurf von Klassen
Setze Vererbung sparsam ein
Normalisiere das Datenmodell
Vermeide transitive Assoziationen
Analysiere m:n-Beziehungen genau
Vermeide 1:1-Beziehungen
Modelliere nur fachliche, nie technischen Aspekte
Beschränke Dich auf das für das System Notwendige
6.2 Regeln zum Entwurf von Klassen
Diese Regeln geben konkrete Leitlinien zum Entwurf von
Klassen und deren Beziehungen!
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 353
6.3 Regeln zum Entwurf von
Operationen und Schnittstellen
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 354
Entwurf von Operationen und Schnittstellen
Bisher haben wir noch gar nicht betrachtet wie man eine Schnittstelle
oder auch die Operationen einer Klasse entwirft
die Operationen sollen möglichst wenig über die interne Umsetzung verraten
(Frage: Welches Grundprinzip wird hier angewendet?)
die Benutzung soll einfach sein
potenzielle Bedienungsfehler und Unklarheiten beim Aufrufer sollen möglichst
vermieden werden
Wir betrachten nun
ein Beispiel und diverse Lösungen zur Umsetzung
analysieren die Nachteile der Lösungen
diskutieren eine andere Lösung, welche die Nachteile nicht hat
leiten daraus eine Regel für den Entwurf ab
6.3 Regeln zum Entwurf von Operationen und Schnittstellen
Aufgabe zum Entwurf von Operationen und Schnittstellen
Modellieren Sie folgenden Sachverhalt:
Eine Klasse zum Verwalten von Kunden soll Operationen anbieten
- um ein neues Element mit einem „Name“ und einer „Adresse“ als String einzufügen
- um die „Adresse“ eines Elements zu ändern
Prüfen Sie,
wie leicht Sie die interne Umsetzung der Operation austauschen könnten
wie viel ein Benutzer der Klasse über die interne Umsetzung wissen muss
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 355
6.3 Regeln zum Entwurf von Operationen und Schnittstellen
CustomerStack
+push(name: string, address: string ) +getPositionInStack(name: string ): int +modify(position: int, address: string )
SAP_CustomerManager
+insertCustomer (name: string , address: string ): int +modifyCustomer (SAPDebitorNumber: int, name: string, address: string )
CustomerManager
+ insertCustomer (name: string, address: string ): int + modifyCustomer (ID: int, name: string, address: string)
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 356
Verschiedene Lösungen
6.3 Regeln zum Entwurf von Operationen und Schnittstellen
Class Diagram: CRM 1. Versuch
Class Diagram: CRM 3. Versuch
Class Diagram: CRM 2. Versuch
Die aufrufenden Objekte erfahren, dass
die Umsetzung über einen Stack erfolgt.
Die aufrufenden Objekte müssen sogar
Stackoperationen verwenden und die
Funktionsweise eines Stacks verstehen
Die aufrufenden Objekte erfahren, dass
die Umsetzung intern ein SAP-Modul
und eine SAP-Nummer verwendet.
Es wird nur die geforderte Funktionalität
nach außen angeboten. Die interne
Umsetzung bleibt verborgen.
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 357
Regel 1: Operationen sind unabhängig von der verwendeten Technologie!
Das Sichtbarmachen der Umsetzungstechnik
verstößt gegen das Geheimnisprinzip
weicht die Trennung von Zuständigkeiten auf
erhöht die Abhängigkeit zwischen Systemteilen
verletzt im 1. Lösungsversuch die Homogenität, weil primitive Stack-Operationen
nicht dem Niveau der Strukturierungsebene entsprechen
Entwerfen Sie Operationen und Parameter so,
dass die angebotene Funktionalität möglichst intuitiv erkennbar ist
dass die angebotene Funktionalität dem Abstraktionsniveau der Klasse
entspricht
dass die interne Umsetzung ohne Seiteneffekte auf die „Außenwelt“
austauschbar ist
Operationen, die Technologie-unabhängig sind,
fördern die Wartbarkeit und die Erweiterbarkeit
6.3 Regeln zum Entwurf von Operationen und Schnittstellen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 358
Weitere Lösungen (I)
6.3 Regeln zum Entwurf von Operationen und Schnittstellen
Class Diagram: CRM 4. Versuch
Die aufrufenden Objekte hantieren mit
Referenzen auf interne Objekte des
CustomerManager's. Ein so abgefragter
und gespeicherter Pointer kann leicht
ungültig werden, ohne dass der Aufrufer
es erfährt.
Class Diagram: CRM 3. Versuch
Die geforderte Funktionalität wird durch
Standarddatentypen nach außen
angeboten. Die interne Umsetzung
bleibt verborgen.
CustomerManager
+ insertCustomer (name: string, address: string ): int + modifyCustomer (ID: int, name: string, address: string)
CustomerManager
+ insertCustomer (name: string, address: string): Customer* + modifyCustomer (c Customer*, name: string, address: string)
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 359
Regel 2: Gib keine Referenzen nach außen!
Das Herausgeben von Referenzen auf interne Objekte
erhöht die Abhängigkeit zwischen Systemteilen
erhöht die Gefahr von Fehlern durch Seiteneffekte
Entwerfen Sie sämtliche Parameter (Eingabe- und Ausgabe) so,
dass nur Standarddatentypen oder Datentypen aus dem Anwendungsgebiet
übergeben werden
Achtung Ausnahme!?
Wenn viele Daten ausgetauscht werden, ist das ständige Wandeln der Daten in
Standarddaten bzw. das Kopieren von Objekten ineffizient
Aus Effizienzgründen kann die Regel in diesem Fall übergangen werden
Vorher ist aber zu prüfen, ob die Ausnahme durch eine Neustrukturierung der
beteiligten Klassen (evtl. Zusammenlegen) vermieden werden kann
Operationen, die keine Referenzen nach außen geben,
fördern die Wartbarkeit und die Zuverlässigkeit
6.3 Regeln zum Entwurf von Operationen und Schnittstellen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 360
Weitere Lösungen (II)
6.3 Regeln zum Entwurf von Operationen und Schnittstellen
Class Diagram: CRM 5. Versuch
Das Einfügen eines neuen Kunden
kann durch „insertCustomer()“ oder
„modifyCustomer()“ erfolgen.
Der Aufrufer fragt sich, ob es einen
Unterschied gibt...
Class Diagram: CRM 6. Versuch
Class Diagram: CRM 7. Versuch
Die geforderte Funktionalität wird durch
zwei Operationen umgesetzt, die intuitiv
sind und genau eine Möglichkeit zur
Umsetzung bieten.
Das Einfügen eines neuen Kunden
kann durch „insertCustomer()“
(mit leerem Namen und Adresse) und
anschließendes Modifizieren erfolgen,
oder auch direkt durch Übergabe der
optionalen Parameter. Der Aufrufer fragt
sich, ob es einen Unterschied gibt...
CustomerManager
+ insertCustomer (name: string, address: string): int + modifyCustomer (Customer* c, name: string, address: string)
c=NULL für
Neueintrag
CustomerManager
+ insertCustomer (name: string="", address: string =""): int + modifyCustomer (ID: int, name: string, address: string)
CustomerManager
+ createCustomer(): int + modifyCustomer (ID: int, name: string, address: string )
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 361
Regel 3: Normalisiere die Schnittstelle!
Eine Schnittstelle, die mehrere Möglichkeiten bietet, um die gleiche
Funktionalität zu erhalten
enthält Redundanzen
irritiert den Aufrufer, der sich fragt, ob es einen Unterschied gibt
Eine Schnittstelle, welche eine erwartete Funktionalität
nicht (offensichtlich) bietet
verschlechtert die Wartbarkeit
Normalisiere die Schnittstelle
mache die Operationen vollständig und nicht-redundant
unterscheide schreibende Operationen und lesende Operationen
Schnittstellen, die den erwarteten Service vollständig
umsetzen und keine Redundanzen enthalten,
fördern die Wartbarkeit und die Zuverlässigkeit
6.3 Regeln zum Entwurf von Operationen und Schnittstellen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 362
Weitere Lösungen (III)
6.3 Regeln zum Entwurf von Operationen und Schnittstellen
Class Diagram: CRM 8. Versuch
Der Aufrufer muss wissen, dass
man zuerst newCustomer, dann
modifyXXX und dann insertCustomer
aufrufen muss. Die Implementierung und
Fehlerbehandlung liegt beim Aufrufer.
Class Diagram: CRM 7. Versuch
Die geforderte Funktionalität wird durch
zwei Operationen umgesetzt, die intuitiv
sind und genau eine Möglichkeit zur
Umsetzung bieten.
unverändert !
CustomerManager
+ createCustomer(): int + modifyCustomer (ID: int, name: string, address: string )
CustomerManager
+ newCustomer(): int + insertCustomer (ID: int) + modifyCustomerName (ID: int, name: string) + modifyCustomerAddress(ID: int, address: string)
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 363
Regel 4: Mache die Operationen grobgranular!
Eine feingranulare Schnittstelle bietet einen „Baukasten“ von
einfachen (atomaren) Funktionen
der Anwender muss wissen, wie er eine höherwertige Funktion aus den
atomaren Operationen zusammen baut
der Implementierungsaufwand für den „Zusammenbau“ fällt bei allen Aufrufern
an
Eine grobgranulare Schnittstelle
bietet mit einer Operation die Funktionalität, die der Aufrufer erwartet und braucht
verbirgt vor dem Aufrufer die Komplexität, die in der Umsetzung einer
Funktionalität durch atomare Operationen und Befehle steckt
Grobgranulare Schnittstellen fördern
die Wartbarkeit und die Benutzbarkeit
6.3 Regeln zum Entwurf von Operationen und Schnittstellen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 364
Weitere Lösungen (IV)
6.3 Regeln zum Entwurf von Operationen und Schnittstellen
Class Diagram: CRM 7. Versuch
Was passiert, wenn ein ungeduldiger
Anwender ständig auf den „Knopf
drückt“, der CreateCustomer aufruft?
Class Diagram: CRM 9. Versuch
Wenn createCustomer mehrfach mit den
gleichen Daten aufgerufen wird, wird
maximal ein neuer Eintrag erzeugt und
ansonsten immer die gleiche ID zurück
geliefert
Das ist die
bisherige
Lösung ! Es werden viele Einträge erzeugt, die
wahrscheinlich nie mit Daten gefüllt
werden!
CustomerManager
+ createCustomer(): int + modifyCustomer (ID: int, name: string, address: string )
CustomerManager
// legt einen Eintrag an, falls der Datensatz neu ist // liefert dessen ID, falls der Eintrag bereits existiert + createCustomer (name: string , address: string ): int //ID // ändere den Eintrag bei Bedarf + modifyCustomer(ID: int, name: string, address: string )
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 365
Regel 5: Mache die Operationen idempotent!
Eine Operation, deren Ergebnis davon abhängt, wie oft sie aufgerufen wird,
birgt die Gefahr von unerwarteten Ergebnissen
- wegen ungeduldigen Benutzern, die mehrfach die „Next-Taste“ drücken
(z. B. am CD-Player)
- wegen automatischen Retry's bei Netzwerkproblemen (der Befehl „Nächster Titel“
kommt wegen Netzwerkproblemen verzögert und mehrfach beim CD Player an)
- wegen mehrfachem Aufruf eines Batch-Jobs (z. B. Überweisungen im Bankumfeld)
- wegen Nachrichten, die nicht in der erwarteten Reihenfolge ankommen
erzeugt für verteilte Anwendungen oder im Multithreading-Umfeld schnell große
Probleme, die sehr schwer zu diagnostizieren sind
Eine idempotente Operation
liefert jeweils das gleiche Ergebnis – auch wenn der Aufruf (versehentlich)
mehrfach erfolgt
Beispiel: statt NextTrack() besser setTrack(5) aufrufen
Idempotente Operationen fördern die Zuverlässigkeit
(Robustheit) und die Wartbarkeit (Testbarkeit) !
6.3 Regeln zum Entwurf von Operationen und Schnittstellen
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 366
Weitere Lösungen (V)
Zusätzliche Anforderung:
Es können Kunden-Datensätze im Offline-Modus angelegt werden
6.3 Regeln zum Entwurf von Operationen und Schnittstellen
Class Diagram: CRM 9. Versuch
Wenn createCustomer wissen muss, ob
die Anwendung Online ist, so wird der
Modus intern selbst bestimmt und taucht
nicht in der Schnittstelle auf.
Class Diagram: CRM 10. Versuch
CreateCustomer hängt davon ab, ob
die Anwendung Online ist.
CreateCustomer verlässt sich auf die
(unzuverlässige!?) übergebene
Information. Der Aufrufer muss den
Modus selbst verwalten.
CustomerManager
// legt einen Eintrag an, falls der Datensatz neu ist // liefert dessen ID, falls der Eintrag bereits existiert + createCustomer (name: string , address: string , onlineMode: bool): int //ID // ändere den Eintrag bei Bedarf + modifyCustomer(ID: int, name: string, address: string )
CustomerManager
// legt einen Eintrag an, falls der Datensatz neu ist // liefert dessen ID, falls der Eintrag bereits existiert + createCustomer (name: string , address: string ): int //ID // ändere den Eintrag bei Bedarf + modifyCustomer(ID: int, name: string, address: string )
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 367
Regel 6: Mache die Operationen kontextfrei!
Eine Operation, die einen Kontext des Aufrufs als Parameter enthält
z. B. eine SessionID oder einen Betriebsmodus
verlagert die Verwaltung des Kontexts an den Aufrufer
birgt die Gefahr, dass der falsche Kontext übergeben wird
Eine kontextfreie Operation
besorgt sich selbst die erforderliche Kontext-Information
verbirgt das Thema Kontext vor dem Aufrufer und macht den Aufruf dadurch
einfacher
vermeidet viele Problemfälle im Vorfeld
Kontextfreie Operationen fördern die Zuverlässigkeit,
Robustheit und die Sicherheit!
6.3 Regeln zum Entwurf von Operationen und Schnittstellen
CustomerManager
// legt einen Eintrag an, falls der Datensatz neu ist // liefert dessen ID, falls der Eintrag bereits existiert + createCustomer (name: string , address: string ): int //ID // ändere den Eintrag bei Bedarf + modifyCustomer(ID: int, name: string, address: string )
CustomerManager
// legt einen Eintrag an, falls der Datensatz neu ist // falls der Eintrag bereits existiert, werden die Daten // geändert und dessen ID zurück geliefert // falls die Anwendung Offline ist, ... + modifyCustomer(ID: int, name: string, address: string ): int
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 368
Zusammenfassung der Regeln
Regeln zum Entwurf von
Operationen und Schnittstellen
Operationen sind unabhängig von
der verwendeten Technologie
Gib keine Referenzen nach außen
Normalisiere die Schnittstelle
Mache die Operationen
grobgranular
Mache die Operationen
idempotent
Mache die Operationen kontextfrei
Diese Regeln geben konkrete Leitlinien zum Entwurf von
Operationen und Schnittstellen!
6.3 Regeln zum Entwurf von Operationen und Schnittstellen
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 369
6.4 Entwurfsmuster
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 370
Muster (Patterns)
6.4 Entwurfsmuster
„Auf der Grundlage von
Erfahrung und der
Reflexion darüber...
...können wir
wiederkehrende
Muster erkennen ...
Einmal erkannte Muster
leiten unsere
Wahrnehmung.“ Hochzeitsturm Darmstadt
Quelle: Google Earth
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 371
Ein Problem aus der IT Welt
Von der zentralen Verwalterklasse MyClass (z. B. einer Systemuhr) soll es nur eine einzige Instanz
geben
Alle Aufrufe sollen an dieses Objekt gehen (und dort koordiniert werden)
Das Problem
Jeder Aufruf von new MyClass erzeugt ein Objekt der Klasse MyClass
Wenn der Konstruktor mehrmals aufgerufen wird, entstehen auch mehrere
Objekte der Klasse. Das kann man nicht verhindern!
Aber man kann den Aufruf verhindern! Bloß wie legt man dann ein Objekt an?
6.4 Entwurfsmuster
Sperre den normalen Konstruktor für Aufrufe von außen!
Biete einen „Alternativ-Konstruktor“ an, der immer das gleiche Objekt liefert
MyClass
-anyAttribute
// Was auch immer diese // Klasse tun soll... +AnyMethod() +MyClass()
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 372
Das Singleton-Muster
Eine vorhandene Klasse wird zu einem Singleton, indem man
den Konstruktor auf private setzt
ein Klassenattribut (Konvention: singletonInstance) hinzufügt und sich darin
das einzige Objekt merkt und
eine Klassenmethode (Konvention: getInstance) hinzufügt, die so etwas wie
einen Alternativ-Konstruktor darstellt
Das Singleton-Muster ist recht einfach – aber die Tücke liegt in den Details der
Implementierung (später mehr dazu)
6.4 Entwurfsmuster
Struktur
Ein Singleton ist
eine Menge mit
einem Element!
Jetzt als
Singleton!
MyClass
-anyAttribute
// Was auch immer diese // Klasse tun soll... +MyClass() +AnyMethod()
MyClass
-singletonInstance : MyClass = new MyClass
-anyAttribute
-MyClass()
+getInstance() : MyClass
// Was auch immer diese Klasse tun soll...
+AnyMethod()
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 373
Das Singleton-Muster – Code für C++
6.4 Entwurfsmuster
// MyClass.h
class MyClass {
// Der Konstruktor ist jetzt private, damit ihn
// sonst niemand aufrufen kann
private: MyClass( );
// Hier wird spaeter das einzige Objekt abgelegt
private: static MyClass * singletonInstance;
// Der "Alternativkonstruktor" kann von
// aussen aufgerufen werden
public: static MyClass * getInstance( );
//**** Was auch immer die Klasse sonst braucht ****
private: int anyAttribute;
public: AnyMethod( );
};
// MyClass.cpp
#include "MyClass.h"
// Der Konstruktor initialisiert bei Bedarf normale Attribute
MyClass::MyClass( ){ }
// Der Kern des Singleton –
// es kommt immer das gleiche Objekt zurueck
MyClass * MyClass::getInstance( ){
return singletonInstance;
}
// Static Variablen muessen im Code initialisiert werden.
// Hier wird das einzige Objekt angelegt.
MyClass * MyClass::singletonInstance = new MyClass;
//************* "Normale" Methoden der Klasse **************
void MyClass::AnyMethod ( ){ ... }
/* Aufruf */ MyClass* h2 = MyClass::getInstance();
/* Aufruf */ MyClass* h1 = MyClass::getInstance();
Das Singleton-Muster: Eigenschaften (I)
Zweck:
Das Singleton-Muster stellt sicher, dass es
nur eine Instanz einer Klasse gibt, und bietet
einen zentralen Zugriffspunkt für diese Instanz
Umsetzung:
Die Klasse wird um ein Attribut und eine Methode erweitert
Der Konstruktor wird auf private gesetzt
Der Rest der Klasse bleibt unberührt
Motivation:
Wenn eine Klasse nur ein einziges Objekt haben soll und man vermeiden will,
dass aus Versehen doch mehrere Objekte angelegt werden können
Anwendbarkeit
Das Singleton-Muster sollte nur eingesetzt werden, wenn es sich um eine Klasse
handelt, die einen zentralen Zugriff koordinieren soll. Singletons sind eher selten.
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 374
6.4 Entwurfsmuster MyClass
-singletonInstance : MyClass = new MyClass
-anyAttribute
-MyClass()
+getInstance() : MyClass
// Was auch immer diese Klasse tun soll...
+AnyMethod()
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 375
Das Singleton-Muster: Eigenschaften (II)
Probleme
Die Implementierung eines Singleton ist nicht ganz trivial und verletzt genau
genommen die Trennung von Zuständigkeiten
Bei der Umsetzung des Singletons gibt es oft Probleme, die z.B. durch Multi-
Threading oder Compiler-Optimierungen entstehen. Die Umsetzung des
Singletons in einer robusten Form hängt oft von der Laufzeitumgebung ab und ist
anspruchsvoll
Beispiele:
Ein Spooler-Klasse soll die Schnittstelle zu einem Drucker darstellen
Eine Logging-Klasse soll Informationen über den Fortschritt des
Programmablaufs (Traces) sammeln und in eine Log-Datei schreiben
6.4 Entwurfsmuster
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 376
Diskussion Singleton-Muster
Vorteile des Singleton-Musters
Eine Singleton-Klasse kann tatsächlich nur einmal instanziiert werden. Diese
Lösung ist robuster als ein Verbot den Konstruktor mehrfach aufzurufen:
Anstatt sich darauf zu verlassen, dass der Aufrufer nur eine Instanz anlegt,
entzieht man ihm mit dem Singleton die Möglichkeit solche Fehler zu machen
Klassen, die mit dem Singleton kommunizieren sollen, können sich einfach mit
getInstance die Instanz besorgen. Ohne ein Singleton muss die einzige
Instanz vom Ersteller an alle Interessenten weitergereicht werden.
Nachteile des Singleton-Musters
Singletons demonstrieren den Trick, wie man „lokale Variablen“ in die Welt der
Objektorientierung überträgt. Singletons können bei derartiger Verwendung
sogar schlechtes Design fördern
Die Abhängigkeit einer Klasse zur Singleton-Klasse kann vollständig im Code
„versteckt“ werden und taucht im Klassendiagramm nicht mehr auf (wenn keine
entsprechende Assoziation eingetragen ist)
6.4 Entwurfsmuster
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 377
Literatur zu Entwurfsmustern
Eric. Freeman & Elisabeth Freeman et.al.:
Entwurfsmuster von Kopf bis Fuß", O'REILLY, 2006
6.4 Entwurfsmuster
-Erich Gamma, Richard Helm, Ralph Johnson,
John Vlissides:
-"Design Patterns – Elements of Reusable
Object-Oriented Software",
(Addison-Wesley, 1994) deutsch: [GHJV96]
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 378
Fazit zu Entwurfsmustern
Entwurfsmuster
bieten bewährte Lösungen für immer wiederkehrende Probleme im Design
sind als Lösung durch Literatur dokumentiert und international bekannt
machen einen Entwurf änderbar und flexibel
helfen, existierende SW-Entwürfe zu analysieren und zu reorganisieren
Aber
Entwurfsmuster machen das Design oft komplizierter und abstrakter
es muss nicht jedes Problem mit einem Entwurfsmuster gelöst werden
Entwurfsmuster sollten nur dann eingebaut werden, wenn die Flexibilität auch
tatsächlich benötigt wird
6.4 Entwurfsmuster
Hat man ein Problem einmal selbst gelöst, weiß man das entsprechende Pattern zu
schätzen - vorher versteht man leider oft nicht, warum die Lösung so gut ist !
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 379
6.5 Zusammenfassung:
Welches Design ist das Richtige?
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 380
Fazit: Welches Design ist das Richtige (I)
Im Design
gibt es viele Lösungen
sind viele Lösungen ungeeignet, einige sind geeignet
je konkreter die Randbedingungen vorgegeben sind, desto weniger gute
Lösungen gibt es – bis hin zu überhaupt keiner
häufig wird eine Regel / ein Prinzip zu Gunsten eines anderen geopfert
Aber Sie kennen jetzt viele Regeln und Grundideen, die beim Entwurf helfen
Grundlegende Designprinzipien
Regeln zum Entwurf von Klassen und Assoziationen
Regeln zum Entwurf von Operationen und Schnittstellen
Das Singleton-Muster als bewährte Lösung für ein Standardproblem
Und in der Veranstaltung „Software Engineering“ lernen Sie noch
weitere Design Patterns
Anti-Patterns als häufig gemachte Entwurfsfehler
6.5 Zusammenfassung: Welches Design ist das Richtige?
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 381
Fazit: Welches Design ist das Richtige (II)
Es gibt noch weitere Dinge, die „Ihr Design“ verbessern
z. B. Refaktorierung (Refactoring)
- Beim Refactoring wird der Quelltext eines Computerprogramms systematisch
umgestaltet, wobei die eigentliche Programmfunktion unverändert bleiben soll
Änderung von Variablennamen, Verschieben, Auslagern oder Zusammenfassen
von Programmteilen etc.
z. B. Rahmenwerke (Frameworks)
- Ein Framework ist ein Programmiergerüst. In diesem Rahmen kann ein Programmierer
eine Anwendung erstellen, wobei er sich an die „Spielregeln“ halten muss, die das
Framework vorgibt.
Ein Framework definiert insbesondere den Kontrollfluss der Anwendung und die
Schnittstellen für die konkreten Klassen, die vom Programmierer erstellt und registriert
werden müssen.
... und natürlich Erfahrung, d. h. viel Üben!
6.5 Zusammenfassung: Welches Design ist das Richtige?
Aber trotz aller Regeln – Design ist und bleibt ein kreativer und nicht-trivialer Prozess
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 382
Kontrollfragen
Welche Grundprinzipien für den Entwurf kennen Sie?
Denken Sie an Ihre Entwürfe für „Programmieren 2“.
Haben Sie dabei Prinzipien verletzt?
Woher wissen Sie welche Klassen und Operationen ihr Entwurf enthalten sollte?
Kann man ein Singleton-Objekt mit „new“ anlegen?
Können Sie jetzt einen guten Entwurf machen?
6.5 Zusammenfassung: Welches Design ist das Richtige?
Hochschule Darmstadt Fachbereich Informatik
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 383
7. Zusammenfassung
Objektorientierte Analyse und Design
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 384
Behandelte Themen in OOAD
1. Motivation
2. Grundkonzepte der Objektorientierung
3. Objektorientierte Software-Entwicklung
4. Objektorientierte Analyse
- Use Cases
- Aktivitätsdiagramme
- Analysemodell
5. Objektorientiertes Design
- Darstellung der Statik eines Systems (Klassendiagramm)
- Umsetzung von Klassen in C++
- Darstellung der Dynamik eines Systems (Sequenz-, Zustandsdiagramme)
- Weitere Diagramme in der UML
6. Welches Design ist das Richtige?
- Entwurfsprinzipien
- Regeln für den Entwurf von Klassen, Operationen und Schnittstellen
- Design Pattern(s)
7. Zusammenfassung
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 385
Konzept von Praktikum und Vorlesung zur Softwaretechnik
OOAD
Objektorientierung
Analyse und Design
Dokumentation der Arbeit
- UML
„Handwerkszeug“ für SW-Entwickler
- Gutes Design
SWE
Gesamtkonzept / Zusammenhänge
- Arbeit in großen Projekten
- Anwendung des Handwerkszeugs
- Qualitätssicherung
- Organisation
Praktikum OOAD
Umgang mit dem Handwerkszeug
- Erste Modellierung
- „Entwickeln“ eines Mini-Projekts
- Arbeit mit der UML
- Kennenlernen des CASE-Tools
- Kennenlernen der Entw.umgebung
Praktikum SWE
Anwendung der Verfahren aus
OOAD und SWE
Entwicklung eines Systems in kleinen
Teams
Möglichst hohe Realitätsnähe
- Eigenständige Lösung der Aufgaben
- Überprüfung durch Reviews
- Aufteilung der Arbeiten im Team
7. Zusammenfassung
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 386
Abstraktionsebenen
Abstraktionsebenen der objektorientierten Systementwicklung (4-Schichten-Modell)
Arzt.cpp
Reale Welt
OOA-Ebene
OOD-Ebene
Programm
Abstraktion
Codierung
Implementierungs-konzepte
gedankliche Ebene
logische Ebene (Modell)
physische Ebene (Implementierungsebene)
Umsetzung von UML
C++-Klassendiagramme, Sequenz-, Zustands-,
Komponentendiagramme
(Analyse)modell, Klassen-, Zustands-,
Komponentendiagramme
7. Zusammenfassung
Use-Cases & UC-Diagramme
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 387
Gesammelte Kontrollfragen
Kennen Sie jetzt die Grundprinzipien der Objektorientierung?
Ahnen Sie, warum man in großen Projekten mit Objektorientierung und UML
entwickelt?
Können Sie Anforderungen an ein zu entwickelnde Softwaresystem erfassen
und beschreiben?
Können Sie Klassen und deren Beziehungen in einem Klassendiagramm
darstellen?
Können Sie die Dynamik eines Systems in Diagrammen darstellen?
Haben Sie einen Überblick über die verfügbaren Diagramme in der UML?
Können Sie ein adäquates Lösungskonzepts zu einem gegebenen Problem
erarbeiten?
Wissen Sie, wie man ein gutes Design macht bzw. ein Design beurteilt?
7. Zusammenfassung
Dann beherrschen Sie jetzt (hoffentlich) das „Handwerkszeug“ zur
Mitarbeit in einem modernen Projekt!
OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 388
Schlussbemerkungen
In einem echten Projekt kann es Ihnen passieren, dass
die vorgestellten Lösungsansätze mal mehr und mal weniger berücksichtigt
werden z. B.
- Das „Design“ wird nicht explizit gemacht und auch nicht dokumentiert
- Die UML wird auf ein paar Klassendiagramme reduziert
- Zustandsdiagramme sind das einzige „Modell“
Aber SIE wissen jetzt, was man tun kann und hoffentlich auch, wozu die
verschiedenen Konzepte und Diagramme gut sind
dann erkennen SIE Mängel in einem Projekt
dann können SIE sich bewusst für oder gegen ein Konzept entscheiden
dann können Sie gezielte Verbesserungsmaßnahmen anregen
dann sind Sie ein wertvolles Mitglied in einer Entwicklungsmannschaft
7. Zusammenfassung
Und das wird von einem Informatiker (auch) erwartet...