Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr....

388
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

Transcript of Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr....

Page 1: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 2: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

OOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 2

Page 3: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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?

Page 4: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 5: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 6: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 7: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 8: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 9: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 10: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 11: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 12: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 13: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 14: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 15: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 16: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 17: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 18: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 19: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 20: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 21: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 22: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 23: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 24: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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)

...

Page 25: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 26: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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…

Page 27: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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.)

Page 28: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 29: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 30: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 31: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 32: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 33: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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)

Page 34: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 35: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 36: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 37: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 38: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 39: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 40: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 41: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 42: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 43: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 44: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 45: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 46: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 47: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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 (?)

Page 48: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 49: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 50: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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)

Page 51: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 52: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 53: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 54: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 55: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 56: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 57: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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“)

Page 58: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 59: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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“

Page 60: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 61: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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)>

Page 62: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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)

Page 63: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 64: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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.

Page 65: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 66: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 67: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 68: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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?

Page 69: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 70: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 71: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 72: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 73: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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:....

Page 74: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 75: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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)

Page 76: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 77: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 78: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 79: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 80: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 81: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 82: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 83: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 84: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 85: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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»

Page 86: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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>>

Page 87: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 88: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 89: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 90: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 91: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 92: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 93: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 94: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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]

Page 95: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 96: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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]

Page 97: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 98: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie 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]

Page 99: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 100: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 101: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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]

Page 102: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 103: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 104: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 105: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 106: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 107: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 108: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 109: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 110: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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)

Page 111: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 112: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 113: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 114: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 115: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 116: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 117: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 118: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 119: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 120: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 121: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 122: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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()

Page 123: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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()

Page 124: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 125: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 126: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 127: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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?

Page 128: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 129: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 130: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 131: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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}

Page 132: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 133: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 134: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 135: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 136: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 137: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 138: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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»

Page 139: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 140: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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“

Page 141: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 142: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 143: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 144: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 145: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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.

Page 146: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 147: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 148: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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}

Page 149: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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?

Page 150: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 151: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 152: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 153: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 154: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 155: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

*

Page 156: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 157: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 158: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 159: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 160: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 161: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 162: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 163: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 164: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 165: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 166: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 167: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 168: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 169: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 170: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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)

Page 171: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 172: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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)

Page 173: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 174: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 175: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 176: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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…*

Page 177: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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…*

Page 178: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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?

Page 179: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 180: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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 *

Page 181: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 182: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 183: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 184: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 185: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 186: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 187: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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++)

Page 188: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 189: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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*

Page 190: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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:

...

}

Page 191: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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*

Page 192: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 193: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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*

Page 194: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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++

Page 195: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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++

Page 196: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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…*

Page 197: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 198: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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?

Page 199: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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++

Page 200: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 201: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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“

Page 202: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 203: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 204: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 205: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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")

Page 206: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 207: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 208: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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:

Page 209: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 210: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 211: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 212: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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:

Page 213: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 214: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 215: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 216: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 217: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 218: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 219: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 220: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 221: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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]

Page 222: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 223: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 224: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 225: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 226: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 227: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 228: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 229: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 230: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 231: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 232: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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)

Page 233: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 234: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 235: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 236: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 237: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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?

Page 238: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 239: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 240: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 241: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 242: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 243: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 244: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 245: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 246: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 247: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 248: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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()

Page 249: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 250: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 251: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!='/']

Page 252: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 253: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 254: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 255: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

Ü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

Page 256: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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?

Page 257: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 258: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 259: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 260: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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?

Page 261: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 262: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 263: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 264: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 265: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 266: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 267: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 268: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 269: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 270: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 271: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 272: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 273: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 274: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 275: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 276: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 277: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 278: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 279: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 280: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 281: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 282: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 283: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 284: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 285: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 286: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 287: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 288: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 289: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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“

Page 290: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 291: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 292: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 293: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 294: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

<<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“

Page 295: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 296: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 297: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 298: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 299: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 300: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 301: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 302: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 303: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 304: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 305: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 306: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 307: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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.

Page 308: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 309: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 310: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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?

Page 311: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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?

Page 312: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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?

Page 313: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 314: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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?

Page 315: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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() - ...

Page 316: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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()

Page 317: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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?

Page 318: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 319: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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?

Page 320: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 321: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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 ()

Page 322: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 323: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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*)

Page 324: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 325: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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 )

Page 326: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 327: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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()

*

*

*

Page 328: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 329: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 330: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 331: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 332: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 333: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 334: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 335: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 336: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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“

Page 337: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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“

Page 338: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 339: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 340: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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“

Page 341: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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“

Page 342: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 343: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 344: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 345: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 346: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 347: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 348: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 349: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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“

Page 350: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 351: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 352: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 353: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 354: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 355: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 356: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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.

Page 357: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 358: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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)

Page 359: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 360: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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 )

Page 361: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 362: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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)

Page 363: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 364: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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 )

Page 365: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 366: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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 )

Page 367: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 368: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 369: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 370: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 371: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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()

Page 372: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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()

Page 373: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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();

Page 374: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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()

Page 375: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 376: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 377: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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]

Page 378: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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 !

Page 379: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 380: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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?

Page 381: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 382: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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?

Page 383: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 384: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 385: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 386: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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

Page 387: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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!

Page 388: Hochschule Darmstadt Fachbereich Informatik ... · PDF fileOOAD, Prof. Dr. R. Hahn, Prof. Dr. W. Weber, SS2014, h_da, Fachbereich Informatik 3 Planspiel Stellen Sie sich vor, Sie sollen

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...