Systemanalyse und –entwurf:

Objektorientierte Analyse
und objektorientierter Entwurf

Prof. Dr. Jürgen Schwille

DHBW Stuttgart
[Link]@[Link]

Zentrale Literatur für diese Vorlesung:

Heide Balzert (2011): Lehrbuch der Objektmodellierung,
Analyse und Entwurf mit der UML 2, Nachdruck der 2. Auflage
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 1
Lernziele der Vorlesung
Nach dieser Vorlesung sollten Sie
 die Unterschiede zwischen objektorientierter und
klassischer Modellierung kennen,
 die Phasen Analyse, Entwurf und Implementierung klar voneinander
abgrenzen können,
 die Konzepte der Objektorientierung kennen und anwenden können,
 die Unified Modeling Language (UML) weitgehend beherrschen,
 wissen, wie objektorientierte Modelle schrittweise erstellt werden und wie
sich gute Modelle von schlechten Modellen unterscheiden,
 für eine gegebene Aufgabenstellung objektorientierte Modelle nach UML
für die Phasen Analyse und Entwurf erstellen können,
 die Vorteile und Grenzen eines UML-Werkzeugs wie Enterprise Architect
kennen.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 2
Inhaltsverzeichnis

1.–2. Termin:
 Einleitung
Einleitung,
Grundlagen
 Grundkonzepte der Objektorientierung

 Objektorientierte Analyse (OOA)

3.-4. Termin:
OOA

 Zusammenwirken von Objekten

 Finden von Klassen
5.-9. Termin:
OOD  Beziehungen zwischen Klassen
 Vererbung und Polymorphismus

 Weitere UML-Diagramme
 Enterprise Architect
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 3
 Einleitung: Lernziele dieses Kapitels

Nach diesem Kapitel sollten Sie

 wichtige Unterschiede zwischen
objektorientierter und klassischer
(= strukturierter) Modellierung kennen,
 die Begriffe OOA, OOD, OOP und UML
erklären können,
 wichtige Literatur zum Thema
Objektorientierung kennen.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 4
DHBW-Verwaltungssystem: Strukturierte Modellierung (klassisch)

Studien- Verträge
fächer Vorlesungen für Dozenten
anlegen erfassen drucken

Notenbe-
scheinigung
 Funktionale Zerlegung drucken
Klausur-
 Datenstrukturen ergebnisse
werden häufig in den eingeben
einzelnen Funktionen Noten via
definiert Internet
abfragen

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 5
DHBW-Verwaltungssystem: Objektorientierte Modellierung
Vererbung Person
Klasse Komposition

Kurs Student Dozent

Assoziation hat erhalten

Prüfungs-
 Datenorientierte ergebnis hält
Zerlegung
ist Ergebnis von
 Funktionen
wird gehalten für
werden den Vorlesung
Datenobjekten
zugeordnet gehört zu findet statt in

Fach Semester

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 6
Objektorientierte Analyse, Design und Programmierung
Objektorientierung = Durchgängiges Konzept für die Software-Entwicklung

OOA OOD OOP

Wünsche und Lösung auf Basis Zuvor
Anforderungen der ermittelten erstellten Entwurf
des Auftraggebers Anforderungen implementieren
an ein neues konzipieren (programmier-
Software-System (programmier- sprachen-
ermitteln und sprachen- spezifisch)
beschreiben unabhängig)

Anwendersicht Entwicklersicht Entwicklersicht

Detaillierungsgrad der Lösung nimmt über Phasen hinweg stetig zu

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 7
 Was ist die UML? UML

Die Unified Modeling Language (UML) Bauplan (Modell)

ist eine (graphische) Sprache zur Modellierung
objektorientierter Software.
 Notation zur Visualisierung von Modellelementen. Produkt

 Definierte Semantik von Modellelementen.

 Durchgängige Verwendung ab dem Beginn der Analyse
bis zur Fertigstellung des Detailentwurfs (Beginn OOA bis Ende OOD).
 Die UML wird daher in der Vorlesung Systemanalyse ständig eingesetzt.

Die UML ist keine Entwurfsmethode.

 Die UML beschreibt die Bedeutung von Modellelementen.
 Die UML gibt keine Anleitung, wie ein Modell entsteht.
 Die UML beschreibt, wie eine Klasse aussieht, nicht aber, wie man sie
entwickelt.
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 8
Literatur zu OOA und OOD
Aktuelle Bücher:
 H. Balzert (2011): Lehrbuch der Objektmodellierung: Analyse und Entwurf mit der
UML 2, Nachdruck der 2. Auflage. Spektrum Akademischer Verlag, Heidelberg.
 P. Stevens, R. Pooley (2006): Using UML, 2. Auflage. Addison-Wesley, München.
 B. Oestereich (2013): Analyse und Design mit der UML 2.5, Objektorientierte
Softwareentwicklung, 11. Auflage. Oldenbourg Verlag, München.
 B. McLaughlin, G. Pollice und D. West (2008): Objektorientierte Analyse und Design von
Kopf bis Fuß. O'Reilly, Köln.
 C. Rupp, S. Queins (2012): UML 2 glasklar, 4. Auflage. Carl Hanser Verlag, München.
 M. Seidl et al. (2012): UML @ Classroom: Eine Einführung in die objektorientierte
Modellierung, 1. Auflage. dpunkt Verlag, Heidelberg.
Klassiker:
 G. Booch (2000): Objektorientierte Analyse und Design. Addison-Wesley, München.
 J. Rumbaugh (1991): Object-Oriented Modeling and Design. Prentice-Hall, Englewood
Cliffs.
 I. Jacobson et al. (1992): Object-Oriented Software Engineering. Addison-Wesley,
Reading, MA.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 9
Literatur zu UML
Folgende Bücher geben einen schnellen Überblick:
 M. Fowler (2004): UML konzentriert: Eine kompakte Einführung in die
Standard-Objektmodellierungssprache. Zu UML 2.0.
3. aktualisierte Auflage, Addison-Wesley, München.
 G. Schneider, J.P. Winters (2001): Applying Use Cases: A Practical Guide,
2. Auflage. Addison-Wesley Longman, Amsterdam.
 T. Quatrani, J. Palistrant (2006): Visual Modeling with IBM Rational Software
Architect and UML. Addison-Wesley Longman, Amsterdam.
Detaillierte Informationen zur UML findet sich in:
 G. Booch et al. (2007): Das UML-Benutzerhandbuch. Aktuell zur Version 2.0.
Addison-Wesley, München.
 J. Rumbaugh et al. (2004): The Unified Modeling Language Reference Manual.
Covers UML 2.0, 2. Auflage. Addison-Wesley Longman, Amsterdam.
 I. Jacobson et al. (1999): The Unified Software Development Process.
Addison-Wesley Longman, Amsterdam.
Internet: [Link]/uml, [Link]
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 10
 Grundkonzepte der Objektorientierung
 Was ist ein Objekt?
 Was ist eine Klasse?
 Wie hängen Klassen und Objekte zusammen?
 Wie werden Klassen in der UML dargestellt?
 Was sind Attribute?
 Was sind Operationen?
 Wie funktioniert die Ausführung eines OO-Programms?
 Was ist Kapselung?

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 11
Lernziele dieses Kapitels
Nach diesem Kapitel sollten Sie
 die folgenden Grundbegriffe der Objektorientierung  verstehen
erklären können:
– Objekt und Klasse
– Attribut und Operation
– Klassenattribut und Klassenoperation
– Botschaften
– Kapselung
 das Grundprinzip der Objektorientierung der prozeduralen
Programmierung gegenüberstellen können,
 wichtige Vorteile der Objektorientierung erklären können,

 aus einer gegebenen Aufgabenstellung die notwendigen  anwenden

Objekte, Klassen, Attribute und Operationen ableiten und
in UML darstellen können.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 12
Was ist ein Objekt?
Objekte sind eigenständige, abgeschlossene Einheiten wie z. B.:

 Abbildung realer Dinge

 Abstraktion von Vorgängen

 Abstrakte Dinge

 Datenstrukturen

Merkmale von Objekten: a(1) a(2) a(3) a(4) a(5) a(6)

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 13
Merkmale eines Objekts: Zustand
 Zustand: Der Zustand (engl. state) eines Objekts setzt sich aus den aktuellen
Attributwerten des Objekts und den jeweiligen Verbindungen zu
anderen Objekten zusammen. Jedes Objekt befindet sich zu jedem
Zeitpunkt in einem Zustand. Dieser kann sich während der Lebenszeit
des Objekts verändern.

Attribute des
Objekts
Ein Mitarbeiter Mitarbeiter

personal-
nummer
Attribut vs.
name Attributwert?

gehalt

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 14
Merkmale eines Objekts: Verhalten
 Zustand
 Verhalten (engl. behavior)
Die Menge der definierten Operationen beschreibt das Verhalten
eines Objekts.
Änderung oder Abfrage des Zustandes ist nur mittels Operationen
möglich (vgl. Kapselung am Ende dieses Kapitels).

Mögliche Operationen des Objekts Mitarbeiter: Zusammenhang von

Zustand und Verhalten?

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 15
Merkmale eines Objekts: Identität

 Zustand
 Verhalten
 Identität
Peter Müller Hans Müller
Ein Objekt besitzt eine Identität,
die es von allen anderen Objekten unterscheidet.
- Die Identität eines Objekts kann sich nicht ändern.
- Keine zwei Objekte besitzen dieselbe Identität.
- Zwei Objekte sind auch dann verschieden, wenn… Zusammenhang
mit Zustand?

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 16
Übung: Welche Objekte befinden sich derzeit in diesem Raum?
Übung: Zeichnen Sie ein Objektdiagramm dieser Objekte in UML
Was ist eine Klasse?
In einem Programm gibt es viele Objekte mit teilweise Mitarbeiter
ähnlichen Eigenschaften. Eine Klasse fasst gleichartige personalnummer: Int
Objekte zusammen. name: String
gehalt: Währung
Eine Klasse definiert für eine Kollektion von
Objekten deren
Klasse
 Struktur (Attribute), (Modell)
 Verhalten (Operationen) und
Modell-
 Beziehungen (relationships). bildung
Eine Klasse besitzt einen Mechanismus, um neue
Objekte
Objekte zu erzeugen. (Realität)
Jedes erzeugte Objekt gehört zu genau einer Klasse.
Andere Bezeichnungen für Objekte einer Klasse:

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 19
Definition von Klassen
Eine Klasse stellt eine klar definierte Abstraktion dar.
 Jede Klasse sollte einen abgegrenzten Aufgabenbereich modellieren.
 Komplexere Aufgaben werden durch Zusammenwirken mit anderen Klassen gelöst.
Anzahl und Bedeutung von Klassen hängt immer von der gestellten Aufgabe ab.
Jede Klasse hat einen eindeutigen Namen.
 Substantiv im Singular, das durch ein Adjektiv ergänzt werden kann.
Zusammenhang von Klasse und Objekt:

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 20
Stereotypen und Eigenschaftswerte

Stereotypen dienen der Gruppierung von «Stammdaten»

Mitarbeiter
Modellelementen (Klassen, Attribute,
Operationen, Beziehungen).
 Bessere Übersicht in großen Modellen, indem
Klassen der gleichen Gruppe (z. B. Stammdaten)
zusammengefasst werden.

UML enthält vordefinierte Stereotypen, die ergänzt werden

können.

Eigenschaftswerte (engl. property strings) beschreiben Merkmale

von Modellelementen.
 Syntax: {Schlüsselwort}

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 21
Attribute (1) Attribut vs.
Objekt?
 Attribute beschreiben die Daten, die von den
Objekten einer Klasse angenommen werden können.
 Alle Objekte einer Klasse besitzen dieselben Attribute,
haben aber zumeist unterschiedliche Attributwerte.
 Jedes Attribut ist von einem bestimmten Typ.
– Die UML gibt keine Standardtypen für Attribute vor. In dieser Vorlesung
werden die in diversen Programmiersprachen üblichen Datentypen verwendet.
– Der Datentyp eines Attributs kann selbst wieder eine Klasse sein. In diesem Fall
sollte im Entwurf allerdings besser eine Beziehung vorgesehen werden.

Klasse Objekt

Student Instantiierung :Student Werte

matrikelnummer: Int matrikelnummer = individuell
ergänzen
name: String name =
geburtsdatum: Date geburtsdatum =
Abstraktion
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 22
Attribute (2)
Ausführlich werden Attribute in UML wie folgt beschrieben:
 Attributname: Typ = Anfangswert {Eigenschaftswert1, Eigenschaftswert2,...}
 Alle obigen Angaben außer des Attributnamens sind optional.
Der Attributname
 muss im Kontext der Klasse eindeutig sein,
 beginnt mit einem Kleinbuchstaben,
 beschreibt die gespeicherten Daten,
 ist normalerweise ein Substantiv.
Mitarbeiter
Durch Zusicherungen (engl. constraints)
personalnummer: Int
 werden Einschränkungen für Attributwerte {9999 < personalnummer < 100000}
eines Objektes angegeben, die während der
Ausführung eines Systems stets gelten müssen. name: String
gehalt: Währung {gehalt > 0}
 Eine Zusicherung stellt damit eine
Invariante dar, die zu jedem Zeitpunkt
erfüllt sein muss.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 23
 Ergänzen
Operationen (1)
 Eine Operation Student
beschreibt eine
ausführbare Tätigkeit.
 Alle Objekte einer
Klasse verwenden
dieselben Operationen.
 Jede Operation kann
auf alle Attribute eines
Objekts dieser Klasse
direkt zugreifen.
 Die Menge aller
Operationen wird als das
Verhalten der Klasse
oder als die Schnittstelle
der Klasse bezeichnet.
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 24
Operationen (2)

Der Name einer Operation

 soll ausdrücken, was die Operation leistet,
 sollte daher ein Verb enthalten,
– z. B. verschiebe(), erhöhe Gehalt(),
 beginnt mit einem Kleinbuchstaben,
 muss im Kontext der Klasse eindeutig sein.
 Bezeichnung außerhalb der Klasse: [Link]()

Die Signatur einer Operation besteht aus dem Namen, den

Argumenten und dem Ergebnistyp.
 Beispiel:

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 25
Klassenoperationen und Klassenattribute
Operationen, die sich auf alle oder mehrere Objekte einer Klasse, d. h. auf die Klasse
selbst beziehen, heißen Klassenoperationen.
 Typische Klassenoperationen sind das Erzeugen und Löschen von Objekten.
 Klassenoperationen benötigen kein Objekt zum Aufruf, sondern eine Klasse.
 Klassenoperationen werden in UML unterstrichen dargestellt.
Bei einem Klassenattribut existiert nur ein Attributwert für alle Objekte einer Klasse.
 Klassenattribute existieren auch dann, wenn es zu einer Klasse (noch) keine Objekte gibt und
 werden ebenfalls in der UML unterstrichen dargestellt.
Beispiele für die Klasse Student:

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 26
Zusammenwirken von Objekten durch Botschaften/Nachrichten
Eine Botschaft (Synonym: Nachricht) ist die Aufforderung eines Senders an
einen Empfänger eine Dienstleistung zu erbringen.
 Das Empfängerobjekt interpretiert diese Botschaft
und führt eine Operation gleichen Namens aus.
 Das Senderobjekt der Botschaft weiß nicht, wie die
entsprechende Operation ausgeführt wird (Kapselung).
 Die Ausführung eines Programms entsteht durch das
dynamische Zusammenwirken vieler Objekte.
 Operationen werden nur durch Botschaften aufgerufen.
Beispiel:  Aschmies:Student
alter = 21

WWI2020D:Kurs
Bauer:Student
alter = 22
:Benutzer 
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 27
Kapselung = Trennung von Schnittstelle und Implementierung
 Objekte verbergen ihre Daten
vor anderen Objekten.
 Die Daten eines Objektes
können nur über die
Operationen des Objektes ab-
gefragt oder geändert werden.
 Ein Objekt sendet dazu eine
Botschaft an ein anderes
Objekt, dadurch wird eine
Operation angestoßen.
 Ein Objekt realisiert das …

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 28
Vor- und Nachteile von Kapselung
Kapselung ist ein wichtiges Konzept mit vielen Vor- und wenigen Nachteilen:
Übung: prozedurale in objektorientierte Lösung überführen
Erstellen Sie einen Algorithmus (klassisch, nicht objektorientiert) zur Ausgabe
von Angeboten für Neuwagen. Zu Beginn werden Name und Adresse des
Kunden sowie die Modellnummer eingegeben. Anschließend werden die
Nummern der von dem Kunden gewünschten Ausstattungen eingegeben. Es
können maximal 20 derartige Nummern eingegeben werden, die alle über eine
Schleife sequentiell abgefragt und in ein Feld (Array) mit 20 Elementen
(ganzzahlige Werte) abgelegt werden.
Bezeichnung und Preis des Modells sowie der Ausstattungen sind in einer
Datenbank hinterlegt. Nach Eingabe aller Daten wird der Gesamtpreis
berechnet und das Angebot ausgedruckt. Hierfür notwendige
Datenbankzugriffe können Sie umgangssprachlich formulieren:
Suche Modell über Modellnummer in Modell-Datenbank
Drucke [Link]
Ihr Algorithmus muss keinerlei Fehlerbehandlung beinhalten.
Welche Klassen, Attribute und Operationen sind für eine objektorientierte
Lösung dieses Ablaufs notwendig?
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 30
Zusammenfassung
 Was sind Objekte?

 Welche Eigenschaften haben Objekte?

 Objekte kommunizieren über …

 Objekte sind ________________________________________ von Klassen.

 Klassen entstehen durch …

 Klassen sind , die nur das Wesentliche

hervorheben.

 Objekte und Klassen werden in UML durch Objekt- und Klassendiagramme

dargestellt. Durch Stereotypen, Eigenschaftswerte und Zusicherungen
können Modellelemente in der UML detailliert beschrieben werden.

 Kapselung hilft, lose gekoppelte Systeme zu entwerfen, bei denen ...

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 31
 Objektorientierte Analyse (OOA)
 Abgrenzung OOA und OOD
 Aufgaben der Anforderungsanalyse
– Funktionale und nicht-funktionale
Anforderungen
– Probleme, Aufgaben und
Ziele der Anforderungsanalyse
 Anwendungsfallmodell
– Akteur
– Rollen
– Anwendungsfallbeschreibung
– Szenarios
 Fortgeschrittene Konzepte in der UML

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 32
Lernziele dieses Kapitels
Nach diesem Kapitel sollten Sie
 die Phasen OOA und OOD  verstehen
klar voneinander abgrenzen können,
 die grundlegenden Elemente der
Anforderungsanalyse erläutern können,
 die folgenden Grundbegriffe der
objektorientierten Analyse erklären können:
– Akteur
– Anwendungsfall
– Szenario
 die Vorteile von Anwendungsfallmodellen kennen,

 für eine gegebene Aufgabenstellung ein vollständiges  anwenden

Anwendungsfallmodell nach UML erstellen können.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 33
Übersicht: OOA und OOD

Phase Aktivität Ergebnisse Kapitel

Anforderungs- Anwendungsfallmodell
OOA analyse Objektorientierte
Sonstiges Anforderungen Analyse
Testplan für Systemtests

Zusammenwirken
Realisierung Interaktionsdiagramm von Objekten
mit Objekten Klassendiagramm
Finden von Klassen

Beziehungen
Statische Klassenbeschreibung mit zwischen Klassen
OOD Attributen, Operationen
Klassenstruktur
und Beziehungen Vererbung

Dynamisches Aktivitätsdiagramme Weitere

Verhalten Zustandsdiagramme UML-Diagramme

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 34
Arten von Anforderungen
Funktionale Anforderungen Beschreibung
in UML
 Legen das nach außen sichtbare Systemverhalten fest.
 Werden über Anwendungsfälle („Use Cases“) definiert.
– Ein Anwendungsfall beschreibt einen typischen Einsatz des Systems.
– Die Summe aller Anwendungsfälle stellt die Gesamtfunktionalität des Systems
dar.
Beschreibung
Nicht-funktionale Anforderungen in Textform
 Diese werden nicht durch Anwendungsfälle beschrieben.
– Beschreibung wie in herkömmlichen Systemen.
 Beispiele:

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 35
Probleme der Anforderungsanalyse (= Systemanalyse)

Unterschiedliche Schwerpunkte von Auftraggeber und Entwickler.

Nachträgliche Anforderungen verändern ständig die Aufgabenstellung.
 Häufig sind diese Anforderungen für den Kunde klar, fehlen aber im
Pflichtenheft.
Unterschiedliche Interpretation des Pflichtenhefts.
 Das gemeinsame Verständnis von Auftraggeber und Entwickler für die
Anwendung fehlt.
 Pflichtenheft enthält viele Details, aber der Kontext fehlt.
 Oft wird die Sichtweise des Anwenders nicht genügend berücksichtigt.

Es geht nicht darum, ein (unvollständiges,

fehlerhaftes) Pflichtenheft zu erfüllen,
sondern ein nützliches System zu bauen!!!

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 36
Aufgaben und Ziele der Systemanalyse (allgemein)
Die Wünsche und Anforderungen des Auftraggebers an ein neues
Softwaresystem müssen ermittelt, analysiert und modelliert werden.
 Implementierungsaspekte werden weitgehend ausgeklammert
Der Systemanalytiker muss ein konsistentes, vollständiges, eindeutiges und
realisierbares Modell erstellen.
 Die Systemanalyse (und damit auch die objektorientierte Analyse) gehört zu den
anspruchsvollsten Tätigkeiten in einem Projekt, da die Anforderungen des
Auftraggebers in der Regel unklar, widersprüchlich und fallorientiert sind (d. h.
nur bestimmte Ausschnitte sind dokumentiert) sowie sich auf unterschiedlichen
Abstraktionsebenen befinden.

Es ist nicht Aufgabe des Auftraggebers, den Systemanalytiker

zu verstehen, sondern der Systemanalytiker wird dafür
bezahlt, sich dem Auftraggeber verständlich zu machen!

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 37
Objektorientierte Analyse und Entwurf: Einleitung
Ausgangsbasis für OOA und OOD sind Elemente aus der realen Welt.
 Elemente des Anwendungsbereiches (z. B. „Administrator“, „ERP-System“, „Jahres-
abschluss“) werden in Modellelemente überführt (z. B. Akteure, Anwendungsfälle,

________________________________________________________________).

 Nicht immer ist eine direkte Abbildung realer Elemente auf Elemente
objektorientierter Modelle sinnvoll.
 Suche geeigneter Abstraktionen

Modellelemente der objektorientierten Analyse nach UML sind insbesondere

Akteure und Anwendungsfälle.
 Zur Präsentation und Abnahme objektorientierter Modelle sind für Auftraggeber
häufig Prototypen sinnvoll.
Grund:

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 38
Elemente eines Anwendungsfallmodells
Alternative Darstellung:
Akteur (engl. actor)
 Rolle, die ein Benutzer des zu
erstellenden Systems einnimmt.

Name

Anwendungsfall (engl. use case)

 Besteht aus mehreren zusammen-
Anwendungsfall hängenden Aufgaben, die von
einem Akteur mit der zu erstellenden
Software durchgeführt werden.

Interaktionsbeziehung
 Verbindet Akteure mit den
Anwendungsfällen.
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 39
Was ist ein Akteur?
Akteure interagieren direkt mit der zu erstellenden Software.
 Akteure können aktiv Informationen in das System eingeben.
 Akteure können passiv Informationen vom System empfangen.
Akteure sind Abstraktionen. Name

 Akteure sind häufig Personen (genauer: Rollen, die Personen einnehmen).

 Akteure können auch andere Software-Systeme sein.
Akteure befinden sich immer außerhalb des Systems.
Beispiele für Akteure des DHBW-Verwaltungssystems:

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 40
Wie finde ich Akteure?

Checkliste:
 Wer soll das neue System benutzen?
 Welche Rollen nehmen diese Anwender ein?
 Welche Personen führen diese Aufgaben derzeit durch?
 Welche Personen sollen diese Aufgaben zukünftig
durchführen?
 Welche Schnittstellen zu anderen Systemen gibt es?
 Gibt es (Teil-)Systeme, die fest vorgegeben sind und deshalb
als externer Akteur modelliert werden?
– z. B. bereits bestehende Datenbank eines anderen Systems, die
eingebunden werden soll.
 Wer wartet das System?
 Welche Akteure werden für einen Anwendungsfall benötigt?

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 41
Was ist ein Anwendungsfall?
Ein Anwendungsfall (engl. use case) besteht aus mehreren zusammen-
hängenden Aufgaben, die von einem Akteur durchgeführt werden,
um ein Ziel zu erreichen bzw. ein gewünschtes Ergebnis zu erstellen.
 Dialog zwischen Akteur(en) und der zu erstellenden Software
 Wird stets von einem Akteur gestartet
Anwendungsfälle beschreiben die mit dem System auszuführenden Abläufe.
 Anwendungsfälle haben ein nach außen
sichtbares Verhalten, d. h. sind keine
Ein Anwendungsfall
 beschreibt immer einen kompletten Ablauf von Anfang bis Ende,
 besteht daher meistens aus mehreren Schritten,
 liefert ein Ergebnis für mindestens einen Akteur,
 sollte aussagekräftig benannt werden ( Substantiv und Verb).
Die Summe aller Anwendungsfälle beschreibt das Gesamtverhalten des Systems.
 Typische Systeme umfassen 10 bis 100 Anwendungsfälle.
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 42
Übung: Anwendungsfälle des DHBW-Verwaltungssystems
Merkmale von Anwendungsfällen
Wie finde ich Anwendungsfälle?

Die folgenden Fragen geben hierbei Hilfestellung:

 Diskussion mit den Anwendern.
 Literatur aus dem Fachbereich.
 Welche Funktionen enthält das bisherige System?
 Was muss das neue System leisten? Welche Funktionen sind sinnvoll?
 Wie wird das System gewartet?
 Wann ist das beschriebene System „vollständig“?
 Wie werden vorhandene Daten erzeugt, gespeichert, abgerufen, modifiziert
und gelöscht?
 Gibt es für jeden Akteur mindestens einen Anwendungsfall?
 Informiert das System einen Akteur selbständig von internen Ereignissen?
 Auf welche externen Ereignisse muss das System reagieren?
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 45
Übung: Internet-Frontend für Buchhändler
Sie sollen für einen Buchgroßhändler ein internetfähiges Auftragssystem für die
von ihm belieferten Buchhändler erstellen.
Derzeit bestellen Buchhändler für ihre Kunden Bücher via Telefon oder über ein
veraltetes Online-System bei dem Großhändler. Dieses veraltete System soll
durch ein neues, modernes Internet-Bestellsystem ersetzt werden.
Dabei sollen die vorhandenen Backend-Systeme des Großhändlers wie
Bestellabwicklungssystem, Kundenverwaltung und Bestandssystem nicht
ersetzt, sondern in das neue System eingebunden werden. Nur das Frontend
für die Buchhändler, das insbesondere die Buchbestellung ermöglicht, soll neu
gestaltet werden. Die bei dem Großhändler intern verwendeten Systeme sollen
unverändert bestehen bleiben.
Aufgabe: Welche Akteure und Use Cases enthält das neue System?

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 46
Ablaufszenarios (1)

Ein Anwendungsfall kann ver-

schiedene Varianten umfassen,
die durch Szenarios dargestellt
werden.
Ein Szenario ist eine Sequenz
von Verarbeitungsschritten, die
unter bestimmten Bedingungen
auszuführen ist.
 Ein Szenario ist ein festgelegter
Weg durch einen Anwendungsfall.
 Ein Szenario beschreibt einen
Wege durch den Anwendungsfall
beispielhaften Durchlauf durch
das System.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 47
Ablaufszenarios (2)

Ein Szenario ist eine ________________________

eines Anwendungsfalls.
Szenarios werden unterteilt in
 primäre Szenarios (normale, häufige Abläufe) und
 sekundäre Szenarios (Varianten, Fehlerfälle).

Die Summe aller Szenarios beschreibt den Anwendungsfall.

Pro Anwendungsfall gibt es ca. 5 bis 15 Szenarios.
Szenarios werden
 in der Objektorientierten Analyse textuell beschrieben,
 im Objektorientierten Entwurf durch Interaktionsdiagramme modelliert.
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 48
Dokumentation von Anwendungsfällen

Anwendungsfälle werden in
Textform dokumentiert:

 Name des Anwendungsfalls

 Zusammenfassung
(Kurzbeschreibung)
 Voraussetzungen
 Wer startet den
Eine vollständige Anwendungsfall?
Beschreibung eines  Strukturierte
Anwendungsfalls umfasst Ablaufbeschreibung
mehrere Seiten! – Beschreibung aller
Einzelschritte
– Beschreibung aller Alternativen

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 49
Beispiel: Bestellung bearbeiten (1)
Kurzbeschreibung:
Der Verkäufer kann aus einem bestehenden Angebot eine Bestellung erzeugen und diese
an den Hersteller versenden.

Voraussetzungen:
Es muss bereits ein Angebot vorliegen.

Beteiligte Akteure:
Verkäufer, Drucker, Hersteller

Primärer Ablauf:
Der Verkäufer meldet sich beim System an.
Der Verkäufer sucht das vorhandene Angebot.
Der Verkäufer legt die Zahlungsmodalitäten fest (Bar, Vorausüberweisung, beglaubigter
Scheck).
Die Bestellung wird ausgedruckt und vom Kunden unterschrieben.
Die Bestellung wird elektronisch über das CarOrder-System an den Hersteller verschickt.
Es wird eine Auftragsbestätigung gedruckt.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 50
Beispiel: Bestellung bearbeiten (2)
Weitere Abläufe:
 Angebot nicht vorhanden
– Der Verkäufer sucht ein Angebot.
– Das Angebot ist nicht vorhanden.
– Der Anwendungsfall wird mit einer Fehlermeldung abgebrochen.
 Angebot ist abgelaufen
– Wenn das Angebot bereits abgelaufen ist, muss die Genehmigung des Chefs eingeholt
werden. Die Bestellung kann erst ausgeführt werden, wenn das Angebot verlängert
wurde.
 Bestellung mit Finanzierung
 Bestellung mit Leasing
 Bestellung wird nicht unterschrieben
 Bestellung wird vom Hersteller abgelehnt

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 51
Fortgeschrittene Konzepte
Anwendungsfall-Modelle können verfeinert werden:
 Benutzt-Beziehungen zwischen Anwendungsfällen. Advanced
UML
 Erweiterungsbeziehungen zwischen Anwendungsfällen.
 Generalisierungen zwischen Anwendungsfällen.
 Generalisierungen zwischen Akteuren.
Die obigen Möglichkeiten sollten mit Vorsicht eingesetzt werden!
 Das Modell wird dadurch schwieriger zu verstehen.
 Das Modell muss insbesondere für den Anwender lesbar bleiben.
Zielsetzung der Anforderungsanalyse ist
 ein leicht verständliches Modell aller Anforderungen zu erstellen
 und nicht die Verwendung aller vorhandenen UML-Konzepte.
Die meisten guten Modelle kommen mit den Basiskonzepten aus.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 52
Benutzt-Beziehung
Ermöglicht es, dass gemeinsame Funktionalität
mehrerer Anwendungsfälle durch einen Advanced
UML
eigenen Anwendungsfall beschrieben wird.
 Vermeidung von redundanten Beschreibungen.

Gemeinsamer Teil muss

 in gewissem Sinn „vollständig“ sein und «include»
Angebot erfassen
 sinnvolles Verhalten beschreiben.

Große Gefahr: Funktionale Zerlegung !!! Verkäufer

anmelden
«include»
Darstellung:
Bestellung bearbeiten
 Beziehung mit vordefiniertem

__________________________________ «include».
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 53
Erweiterungsbeziehung
Hinzufügen von Erweiterungen
Advanced
 Der bestehende Anwendungsfall UML

wird an einem vorgegebenen Punkt

(dem „Extension Point“) erweitert.
 Erweiterungspunkte werden mit «extend»
(Zahlungsart)
Namen benannt.
Finanzierung
 Der bestehende Anwendungsfall abschließen
ist auch ohne Erweiterung sinnvoll.
Bestellung
 Unterteilung in vorgeschriebenes «extend»
bearbeiten
und optionales Verhalten. (Zahlungsart) Extension
Leasing Point:
abschließen „Zahlungsart“
Darstellung
 Beziehung mit vordefiniertem

______________________________ «extend».
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 54
Generalisierung zwischen Anwendungsfällen/Akteuren
Generalisierung zwischen Anwendungsfällen:
 Ähnliche Funktionalität zusammenfassen. Verkäufer Advanced
 Verhalten wird von oben nach unten anmelden UML

vererbt und kann ergänzt werden.

 Unteranwendungsfall kann an jeder
Stelle anstatt des Oberanwendungs- Anmeldung Anmeldung
falls verwendet werden. mit Passwort mit Chipkarte

Generalisierung zwischen Akteuren:

 Unterakteur kann alle Anwendungsfälle Kunde
des Oberakteurs nutzen.
 Innerhalb der Anwendungsfälle können
Unter- und Oberakteure unterschiedlich
behandelt werden.
Es gelten die Regeln aus dem Kapitel Privatkunde Firmenkunde

Vererbung.
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 55
Beispiel: Use-Case-Diagramm Autohandel in UML
uc Autohandel

Verkäufer anmelden
Kunde über Modelle informieren

«include»

Anmeldung mit Passwort Anmeldung mit Chipkarte

Privatkunde Firmenkunde
Angebot «include»
Drucker
erstellen

Verkäufer «extend»
Bestellung «extend» Hersteller
bearbeiten

Leasing abschließen Finanzierung abschließen

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 56
Übung: Reisekostenabrechnung (1)
Grobanforderungen für ein Programm, mit dem Angestellte einer Firma ihre
Reisekostenabrechnungen effizienter durchführen können.
 Das System verwaltet alle Reisen der Angestellten einer Firma.
 Für jede Reise werden Reisebeginn und -ende, Abfahrtsort, Zielort inklusive
Ankunfts- und Abfahrtszeiten sowie Zweck der Reise gespeichert.
 Umfasst die Reise mehrere Tätigkeitsstätten, sind die jeweiligen Zwischenorte
inklusive Ankunfts- und Abfahrtszeiten festzuhalten.
 An Transportmittel stehen PKW, Bahn, Bus, Taxi und Flugzeug zur Verfügung. Alle
Ausgaben sind durch Belege nachzuweisen. Bei einer Reise mit Privat-PKW erfolgt
die Abrechnung per Kilometerpauschale.
 Übernachtungen können nur nach Beleg abgerechnet werden.
 Die Verpflegung wird pauschal abgerechnet.
 Mögliche Zahlungsarten für Belege sind „Bar oder Privat“, Rechnung und
Firmenkreditkarte.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 57
Übung: Reisekostenabrechnung (2)
Zusätzliche Anforderungen:
 Angestellte geben die Reisedaten selbst in das Programm ein.
 Angestellte können einen Kontrollausdruck der Reisekostenabrechnung anfertigen.
 Ein Buchhalter überprüft die Angaben mit den Belegen.
 Die Abrechnungen werden nach Prüfung monatlich vom Buchhalter ausbezahlt: Die
Auszahlung erfolgt nach Wunsch bar, per Scheck oder Überweisung.
 Für jeden Angestellten kann eine Übersicht über alle Reisen in einem bestimmten
Zeitraum erstellt werden.
 Die Verpflegungspauschale richtet sich nach Ort und Dauer der Abwesenheit. Die
Pauschalen sind im Programm gespeichert und werden vom Buchhalter jedes Jahr
an die aktuellen Vorgaben des Finanzamts angepasst.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 58
Übung: Reisekostenabrechnung (3)
Besonderheiten bei Auslandsreisen:
 Ziel- und Zwischenorte haben Länderangaben.
 Bei Auslandsbelegen sind die Währung und der Wechselkurs anzugeben.
 Bei eintägigen Reisen gilt der Pauschalbetrag für das Land der (letzten)
Tätigkeitsstätte.
 Bei mehrtägigen Reisen gilt der Pauschalbetrag für das Land, welches der
Reisende vor 24:00 Ortszeit erreicht. Am Rückreisetag vom Ausland ins
Inland ist der letzte Tätigkeitsort für den Pauschalbetrag maßgebend.
 Bei Flugreisen gilt ein Land zum Landezeitpunkt als erreicht.
Zwischenlandungen bleiben unberücksichtigt.
 Inlands- und Auslandskilometer mit PKW werden wegen der Vorsteuer
unterschieden.
 Für Ankunfts- und Abfahrtszeit ist die Ortszeit zu verwenden.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 59
Übung: Reisekostenabrechnung (4)

Erstellen Sie ein Anwendungsfall-Modell für das Reisekosten-

Abrechnungsprogramm:
 Welche Anwendungsfälle gibt es? Welche Akteure?
 Erstellen Sie ein Use-Case-Diagramm.
 Geben Sie für die identifizierten Anwendungsfälle eine Kurzbeschreibung
an.

Vervollständigen Sie einen Anwendungsfall mit

 Vorbedingungen
 Beteiligten Akteuren
 Primärem Ablauf
 Sekundären Abläufen

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 60
Warum sind Anwendungsfälle so wichtig?
Anwendungsfälle sind die Basis für die komplette Software-Entwicklung.
 Sie grenzen klar den Projektumfang ab.
 Sie dienen als Basis für die Verständigung zwischen Auftraggeber, Anwender
und Entwickler und helfen Missverständnisse zu vermeiden.
 Verzögerungen und höhere Kosten durch nachträgliche Anforderungen werden
transparent.
 Aus den Anwendungsfällen wird das Klassenmodell abgeleitet.
 Anwendungsfälle definieren die Reihenfolge der Entwicklungsiterationen.
 Anwendungsfälle liefern die Basis für den Systemtest.
 Sie steuern den Abnahmeprozess durch den Auftraggeber.
 Anwendungsfälle sind das Gerüst für die Benutzerdokumentation.
Die Dokumentation der Anwendungsfälle sollte daher gut verständlich sein,
da sie von vielen verschiedenen Personen gelesen wird.
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 61
Iterative Entwicklung des Anwendungsfallmodells

Ad-hoc Anforderungen

Anwendungsfallmodell

abgelehnt

Entwickler
Kunde

Neues Modell

abgelehnt

Neues Modell

akzeptiert

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 62
Zusammenfassung
Ziel der Anforderungsanalyse ist:
Es werden funktionale und
nicht-funktionale Anforderungen unterschieden. Funktionale Anforderungen
werden in UML durch Anwendungsfälle dokumentiert.
 Anwendungsfälle beschreiben das Systemverhalten.
– Nur das nach außen sichtbare Verhalten wird beschrieben.

 ___________________ starten ________________________________________,

um das System zu verwenden.
 Ein Anwendungsfall kann mehrere Alterna-
tiven enthalten, die sich in verschiedenen _______________________ ausdrücken.

 Anwendungsfälle und Szenarios werden in ____________________ dokumentiert.

 UML enthält Erweiterungen für die Beschreibung von Anwendungsfällen.
 Anwendungsfälle stellen die Basis für die gesamte Entwicklung dar.
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 63
 Zusammenwirken von Objekten
 Verfeinerung von Anwendungsfällen
 Arten von Interaktionsdiagrammen
 Sequenzdiagramme
– Objekte
– und deren Interaktion Sequenzdiagramm
 Kommunikationsdiagramme

Kommunikationsdiagramm

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 64
Lernziele dieses Kapitels

Nach diesem Kapitel sollten Sie

 die Bestandteile von Interaktionsdiagrammen kennen,  verstehen
 Interaktionsdiagramme lesen und erläutern können,
 Gemeinsamkeiten und Unterschiede von Sequenz- und
Kommunikationsdiagrammen erläutern können,

 interne Abläufe eines objektorientierten Systems durch ein  anwenden

UML-Interaktionsdiagramm abbilden können.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 65
Verfeinerung von Anwendungsfällen
Die in Szenarios beschriebene Funktionalität wird intern durch die
Zusammenarbeit von Objekten erbracht.
 Objekte tauschen _________________________________________ aus.
 Der wird durch Interaktions-
______________________________ diagramme graphisch modelliert.

Zwei Arten von Interaktionsdiagrammen werden in der UML

unterschieden:
 Sequenzdiagramme: betonen den zeitlichen Aspekt der Objektinteraktion
 Kommunikationsdiagramme: betonen die Beziehungen der Objekte

Beide Diagramme beschreiben

 welche Objekte existieren sowie die
 Interaktion zwischen Objekten.
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 66
Sequenzdiagramme
Grundelemente von Sequenzdiagrammen:
 Objekte
– Benennung von Objekten:
 Ohne Klassenname: Name
 Mit Klassenname: Name : Klasse
 Anonymes Objekt: : Klasse
» Bezeichnet irgendeine Instanz der Klasse.
» Wird häufig zur Darstellung prinzipieller Mechanismen verwendet.
 Lebenslinien der Objekte
 Nachrichten zwischen Objekten in chronologischer Reihenfolge

Schwerpunkt liegt auf zeitlichem Verlauf des Informationsaustauschs.

 Erzeugen und Löschen von Objekten.
 Nachrichtenaustausch zwischen Objekten.
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 67
Darstellung von Objekten
Objekte werden horizontal
angeordnet.
Objekt1 Objekt2
 Die Reihenfolge ist ohne
Bedeutung.

Die Zeit verläuft vertikal.

 Normalerweise ist nur die
Reihenfolge der Nachrichten von
Bedeutung.
 Nachrichten benötigen im Modell
Lebenslinien normalerweise keine Laufzeit.
 Die Zeitachse kann aber auch
Zeit

eine Metrik enthalten.

– Z. B. absolute Werte für
Echtzeitanwendungen
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 68
Nachrichten (Botschaften)
Objekt1 Objekt2 Der Nachrichtenaustausch wird durch einen Pfeil
vom Sender zum Empfänger dargestellt.
 Der Pfeil trägt Name und optional die Argumente
der Nachricht.
 Objekte können sich selbst Nachrichten senden.
Nachrichten können Reihenfolgenummern tragen.
 Optional in Sequenzdiagrammen.
 Durch mehrstufige Numerierung (1.1, 1.2, 1.3,
2.1 usw.) sind zusammengehörige Nachrichten
erkennbar.
Rückkehr zum Aufrufer kann durch gestrichelten
Pfeil angezeigt werden.
 Optional kann ein Rückgabewert beim
Rückkehrpfeil angegeben werden.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 69
Lebensdauer von Objekten

Die Lebenslinie drückt aus, dass das

Objekt1 Objekt existiert.
create Objekt2  Normalerweise befinden sich Objekte am
{transient} oberen Rand.

create Objekt3 Erzeugen eines Objekts

{transient}
 Verschieben des Objekts nach unten.
 Erzeugende Nachricht endet am Objekt.

Löschen eines Objekts

destroy
X  Lebenslinie endet mit großem X.
X  Möglichkeiten:
– Löschen verursacht durch Nachricht.
– Selbständiges Zerstören.
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 70
Darstellung von Schleifen und Verzweigung
Schleifen werden durch den Operator
Objekt1 Objekt2 Objekt3 loop angezeigt.
loop (10)  Die Anzahl der Wiederholungen kann in
Klammern angegeben werden.
 Auch komplexere Schleifenbedingungen
sind möglich.

Eine Verzweigung wird durch den

alt [x < 0] Operator alt (für alternative Abläufe)
oder opt (für optionale Ausführung)
[else]
gekennzeichnet.
 Bei opt entfällt der Else-Zweig.
 Vorsicht beim Einsatz, führt schnell zu
unübersichtlichen Diagrammen!
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 71
Beispiel: Angebot ausgeben als UML-Sequenzdiagramm

angebotsdialog 500SL:Auto Radio : Drucker : Fax

: Verkäufer

Auto auswählen

Ausgabeart festlegen

Angebot ausgeben
drucken

Daten drucken

drucken

alt [ausgabe absenden

=Drucker]

[ausgabe=Fax] absenden

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 72
Gemeinsamkeiten und Unterschiede der beiden Diagrammarten

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 73
 Finden von Klassen

 Suchen nach Substantiven

 Dokumentenanalyse
 CRC-Karten
 Klassendiagramme

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 74
Suchen nach Substantiven
Unterstreichen von Substantiven in Anforderungsbeschreibungen und
Anwendungsfällen.
Substantive geben erste Anhaltspunkte für Klassen:
 Ergebnisliste muss gefiltert werden.
 Ergebnis ist nicht vollständig.
Probleme:
 Sprache ist mehrdeutig.
 Worte werden synonym verwendet.
– Dieselbe Klasse wird durch unterschiedliche Substantive bezeichnet.
– Ein Substantiv wird für unterschiedliche Klassen verwendet
 Substantive bezeichnen:

 Hoher Aufwand insbesondere bei langen Dokumenten.

 Kein Ersatz für Diskussionen!
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 75
Beispiel
„Der Kunde wählt ein Modell aus. Danach legt er die Farbe und Polsterung des
Autos fest. Er kann das Fahrzeug nach seinem persönlichen Geschmack mit
weiteren Extras ausstatten.“

Ungefilterte Liste: Gefilterte Liste:

Kunde
Modell
Farbe
Polsterung
Auto
Fahrzeug
Geschmack
Extra

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 76
Übungsaufgabe: Suchen von Klassen
Die folgende Liste ist das Ergebnis einer Substantivselektion in einer
Sammlung von Use Cases zur Beschreibung einer Anwendung zur
elektronischen Terminverwaltung. Streichen Sie aus der Liste alle Begriffe, die
keine Klasse darstellen. Begründen Sie ihre Antwort!

Ansicht, Beginnzeitpunkt, Benutzer, Berechtigungsstufe, Datum, Dauer,

Drucker, Eintrag, Einzeltermin, Erledigungsliste, Fälligkeitszeitpunkt,
Handhabung, Hardware-Plattform, Hauptfunktion, Internet, Jahr, Kalender,
Kalenderbesitzer, Kalendereintrag, Liste, Monatsansicht, Person,
Personengruppe, Serientermin, System, Tag, Tagesansicht, Teilnehmer,
Teilnehmergruppe, Termin, Terminbeginn, Terminkalender, Terminkollision,
Termintyp, Terminvorschlag, to-do-Liste, Wiederholungsdauer, Woche,
Wochenansicht, Zeit, Zeitpunkt.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 77
Dokumentanalyse

Die Dokumentanalyse ist ähnlich der Suche nach

Substantiven:
 Aus Dokumenten wie z. B. Formularen werden die zu
modellierenden Attribute ermittelt.
 Diese Attribute werden zu Klassen zusammengefasst.
 Gleichzeitig werden meist die notwendigen Beziehungen
ermittelt (siehe nächstes Kapitel).

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 78
Beispiel Dokumentanalyse: Seminaranmeldung

Anmeldung zu TEACHWARE-Seminaren
Aufgabe:
Als Teilnehmer zu nachfolgenden TEACHWARE- Leiten Sie die zu
Seminaren wird angemeldet:
modellierenden Klassen ab.
Titel Vorname Nachname

Seminar-Nr. Seminarbez. von - bis

Anmeldebestätigung und Rechnung erbeten an:

Titel Vorname Nachname

Firma Straße/Postfach

Land PLZ Ort

Telefon

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 79
CRC-Karten

CRC steht für:

Karteikarten anlegen mit Klassenname

Verantwortlichkeiten Beteiligte Klassen
 Klassenname
 Verantwortlichkeiten der Klasse
– Dienste nach außen
– interne Dienste
– internes Wissen
 anderen Klassen, mit denen die Klasse zusammenarbeitet.
– um Dienste in Anspruch zu nehmen
– und den eigenen Verantwortlichkeiten nachzukommen
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 80
CRC-Karten-Sitzung

Das Systemverhalten wird im Rollenspiel nachgestellt.

Für jede beteiligte Klasse im Szenario
wird eine Karteikarte angelegt.
 Zunächst werden Objekte identifiziert.
 Diese werden zu Klassen zusammengefasst.
 Für jede Klasse wird eine Karteikarte angelegt.

Beteiligte Personen erhalten einen Stapel von Karteikarten:

 Jede Person ist für ihre Klassen verantwortlich.
 Sie spielt die Rolle aller Objekte (Exemplare) der Klassen.

Die vorliegenden Szenarios werden schrittweise durchgespielt.

 Dabei werden die Karteikarten entsprechend ergänzt.
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 81
Vorteile von CRC-Karten
CRC-Karten sind insbesondere für unerfahrene Entwickler hilfreich:
 Sie fördern objektorientiertes Denken.
 Sie verhindern zu frühes Nachdenken über Implementierungsdetails.
 Sie verhindern zu frühe Generalisierung.
 Sie fördern fokussierte Diskussionen im Team.
Griffige Beschreibungstechnik
 Kurze Einarbeitung.
Billig, flexibel, überall einsetzbar.
Erlaubt Diskussionen mit Anwendern.
Erleichtert Verständnis für die Abläufe, da diese durch Rollenspiel transparent
werden. Dabei werden häufig Muster erkannt, was bei der Strukturierung des
Systems hilft.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 82
Klassendiagramme
bietet an
Identifizierte Klassen werden in einem Verkäufer Auto

Klassendiagramm dargestellt.
Es sollten mehrere Klassendiagramme Sonderausstattung

erstellt werden:
 Jedes Klassendiagramm hat
Polsterung Radio
einen bestimmten Schwerpunkt.
 Zuviel Information in einem Diagramm erschwert die Lesbarkeit.
 Besser mehrere kleine Diagramme als wenige umfangreiche Diagramme.
Beispiele für Diagramme:
 Vererbungshierarchie
 Klasse mit ihrem Umfeld (Collaborators von CRC-Karten).
 Klassen, die zum Verständnis eines Mechanismus notwendig sind.
Klassen müssen zusätzlich noch dokumentiert werden.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 83
Checkliste
Merkmale guter Entwürfe:
 Jede Klasse hat einen sinnvollen Namen aus dem Problembereich.
 Verantwortlichkeiten innerhalb einer Klasse passen zusammen.
 Wenige Verantwortlichkeiten pro Klasse.
 Eine Klasse arbeitet nur mit wenigen anderen Klassen zusammen.
Zu vermeiden ist:
 Gleiche Verantwortung bei mehreren Klassen.
 Klasse benötigt sehr viele andere Klassen zur Erfüllung ihrer Aufgaben.
 Kein Zusammenhang bei den Verantwortlichkeiten einer Klasse.
 Missverständliche Klassennamen.
 Verantwortlichkeiten beschreiben das „Wie“ und nicht das „Was“.
 Klasse ohne Verantwortlichkeiten (weder Attribute noch Operationen).
 Die Klasse ist über eine 1:1-Beziehung mit einer anderen Klasse
verbunden (Wirklich zwei unterschiedliche Klassen?).
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 84
Zusammenfassung

Es existieren mehrere Ansätze

zum Finden von Klassen.
 Suchen nach Substantiven,
Dokumentenanalyse und CRC-Karten
sind drei bekannte Ansätze.
 Es hat sich bewährt, die verschiedenen
Techniken in der Praxis zu kombinieren.
 Zum Erstellen eines guten Klassenentwurfs gehört viel Erfahrung. Gute
Klassen zu finden ist eine Kunst!
 Die besten Modelle entstehen iterativ.

Klassen und ihre Beziehungen werden in Klassendiagrammen

dargestellt.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 85
 Beziehungen zwischen Klassen

 Warum Beziehungen?
 Beziehungsarten
– Assoziation
– Aggregation
– Komposition
 Namensgebung
 Rollen
 Multiplizität
 Navigierbarkeit
 Vorgehensweise

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 86
Lernziele dieses Kapitels

Nach diesem Kapitel sollten Sie

 die Beziehungsarten der UML erklären können,  verstehen
 die unterschiedlichen Möglichkeiten schildern können,
wie Beziehungen detailliert in UML-Klassendiagrammen
spezifiziert werden können,
 UML-Klassendiagramme lesen, erläutern und beurteilen
können,
 das Zusammenwirken der unterschiedlichen
UML-Diagramme in einem Projekt erläutern können,

 Klassen und ihre Beziehungen systematisch identifizieren  anwenden

und in einem UML-Klassendiagramm präzise spezifizieren
können.
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 87
Wozu Beziehungen?
Objektorientierte Systeme bestehen aus vielen Objekten, die
zusammenarbeiten, um eine Aufgabe auszuführen.
Objekte tauschen Nachrichten über Verbindungen aus:
 Dazu müssen sich die Objekte kennen.
Für jede Verbindung zwischen Objekten (Object Link) muss eine
Beziehungen zwischen den zugehörigen Klassen bestehen.
 Ein Object Link ist eine Instanz einer Beziehung zwischen Klassen.
Es gibt eine Reihe unterschiedlicher Beziehungen:
 Assoziation
 Aggregation Siehe Folgeseiten
 Komposition

 Vererbung Siehe Kapitel Vererbung

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 88
Assoziation
Eine Assoziation beschreibt eine dauerhafte strukturelle
Beziehung zwischen Klassen:
 Dies bedeutet, dass zwischen Objekten dieser Klassen eine
Verbindung existiert, über welche die Objekte kommunizieren können.
 Diese Kommunikation kann, muss aber nicht, in beiden Richtungen erfolgen.
– Es gibt keine Vorzugsrichtung.

Eine bidirektionale Assoziation wird durch eine Verbindungslinie zwischen den

Klassensymbolen dargestellt.
Assoziationen können zur besseren Identifikation einen Namen erhalten:
 Der Name ist optional.
 Durch ein Dreieck kann die Leserichtung angegeben werden
(Standard: von links nach rechts).
 Als Name wird ein Verb oder ein
bietet an
kurzer Aussagesatz verwendet. Verkäufer Auto

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 89
Rollen
Klassen spielen Rollen in einer Beziehung.
Die Assoziation kann durch Angabe von Rollennamen identifiziert
werden:
 Rollennamen sind optional. Verkäufer Auto
 Der Rollenname wird am Anbieter Produkt
Linienende angegeben.
 Ein Rollenname kann auch nur an einem Ende angegeben werden.
 Für Rollennamen werden Substantive verwendet.

Rollennamen und Assoziationsnamen können gleichzeitig

verwendet werden.
 Meist ist eine von beiden Alternativen ausreichend
 Nachteil:

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 90
Reflexive Assoziation

Reflexive Assoziationen sind möglich:

 Eine Assoziation kann an derselben Klasse enden, an der sie beginnt.
 Startpunkt und Endpunkt sind verschieden.

Objekte der Klasse kommunizieren mit anderen Objekten

derselben Klasse:
 Objekte sind verschieden.
 Objekt kommuniziert nicht mit sich selbst.

Ein Angebot kann sich auf andere Angebote

Angebot beziehen, z. B. Nachverhandlungen oder alle
Angebote eines Rahmenvertrags.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 91
Multiplizität
Die Multiplizität (auch Kardinalität genannt) bei einer Klasse A legt fest, mit wie
vielen Objekten einer Klasse A ein einzelnes Objekt einer Klasse B verbunden
sein kann.
 Die Multiplizität wird für jede Rolle getrennt angegeben.
 Multiplizität sagt nichts über die Gesamtzahl der Objekte im System aus.
Beispiel:
Kunde Angebot
1 1..*

Jedes Angebot ist genau einem Kunden zugeordnet.

Jeder Kunde hat sich mindestens ein Angebot ausarbeiten lassen.

Gängige Werte: * Beliebig viele 1..* Ein oder mehrere

1 Genau eines 0..1 Null oder eins

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 92
Gerichtete Beziehungen
Assoziationen und ihre Verfeinerungen sind bidirektionale
Beziehungen.
 Man kann jeweils von einer Rolle zur anderen Rolle navigieren.
 Bidirektionale Beziehungen sind häufig aufwendig zu implementieren.

Oft genügt es, nur in eine Richtung zu navigieren.

 Ein Objekt benutzt ein anderes Objekt als Dienstleister.
 Das Objekt, welches den Dienst zur Verfügung stellt,
kennt die Aufrufer nicht (Navigation nur in eine Richtung).
 Rückgabewerte können trotzdem in umgekehrter Richtung fließen.
 Gerichtete Beziehungen werden durch Pfeile dargestellt.

Ausstattungspaket Ausstattung
0..*

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 93
Aggregation
Aggregation ist eine Verfeinerung der Assoziation.
 Beschreibt eine „Ganze-Teile-Beziehung“.

Aggregation ist vom Wesen her asymmetrisch:

 „A ist Teil von B“, aber nicht „B ist Teil von A“.
 Nur eine Klasse kann Aggregat (Ganzes) sein.
 Trotzdem ist eine Aggregation bidirektional:
– Aggregat kann zu seinen Teilen navigieren.
– Teile können zum Aggregat navigieren.

Eine Aggregation wird durch eine weiße Raute beim Aggregat

dargestellt.
Auto Rad

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 94
Wie erkennt man eine Aggregation?
Die Beziehung kann durch die Ausdrücke „hat“,
„besteht aus“ oder „ist Teil von“ beschrieben werden.
Aggregat nimmt Aufgaben stellvertretend für seine Teile wahr:
 Ändern von Eigenschaften des Ganzen ändert auch
die Eigenschaften der Teile
– Ändern der Wagenfarbe ändert die Farbe der Türen.
 Nachrichten, die an das Ganze gesendet werden, werden von diesem an die Teile
weitergeleitet.
– Bewegen des Autos bewegt die Türen.

Aggregation ist eine engere Beziehung als eine Assoziation.

Solange man nicht sicher ist, sollte man mit einer normalen Assoziation starten.
 Man kann eine Assoziation jederzeit verfeinern.
 Die Implementierung beider Konzepte unterscheidet sich normalerweise nicht.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 95
Komposition (1)
Komposition ist eine strengere Form der Aggregation:
 Alle Aussagen über Aggregation gelten auch für Komposition.
 Zusätzlich ist die Lebensdauer der Einzelteile
an die Lebensdauer des Aggregats gekoppelt. Aggregate

– Teile werden nach oder Teile

mit dem Aggregat erzeugt.
– Teile werden vor oder A1 A2
mit dem Aggregat zerstört. T1
– Wird das Aggregat gelöscht, werden T2
T3
automatisch auch die Teile gelöscht
(„they live an die with it“). X
– Ausnahme: Verantwortung kann an andere X X
Aggregate übertragen werden.
 Darstellung durch schwarze Raute. Verantwortung für T3
geht von A1 an A2 über

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 96
Komposition (2)
Multiplizität auf der Seite des Aggregats muss „0..1“ oder „1“ sein.
 Jedes Element ist Teil genau eines Aggregats.
 Ein Teil kann nicht gleichzeitig mit anderen Aggregaten geteilt werden.
 Beispiel: Ein Rad gehört
Auto Rad
zu genau einem Auto. 1 4

 Beispiel: Ein Rad gehört Auto Rad

entweder zu einem Auto
oder zu einem LKW.
LKW

Reflexive Aggregationen und Kompositionen sind erlaubt

 Multiplizität auf der Seite der Teile muss Null enthalten, da sonst eine
endlose Rekursion entstehen würde.
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 97
Beispiel: UML-Klassendiagramm DHBW-Verwaltungssystem

1 *
Kurs Student Dozent

Was ist hier falsch? 1 1 1

hat erhalten
Was fehlt hier? *
Prüfungs-
ergebnis
*
ist Ergebnis von
1
wird gehalten für 1
Vorlesung
*
* *
gehört zu 1 1 findet statt in

Fach Semester

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 98
Vorgehensweise

__________________________ werden ausgewertet, um heraus-

zufinden, welche Objekte miteinander in Verbindung stehen.
Anhand der folgenden Tabelle wird entschieden,
welche Beziehung zwischen den Klassen besteht.
Die Beziehung wird verfeinert, indem Name,
Multiplizität und Navigierbarkeit (gerichtet bzw.
bidirektional) berücksichtigt werden.
Im ersten Schritt ist es wichtig, Beziehungen überhaupt zu
erkennen.
 Im Zweifelsfall mit einer normalen Assoziation beginnen.
 Verfeinerungen können auch noch später durchgeführt werden.
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 99
Zusammenfassung

Beziehung Notation Zweck Navigierbarkeit Multiplizität

Abhängigkeit Allgemeine, zeitlich Gerichtet Sinnlos, da die

begrenzte Abhängig- Beziehung nur

zunehmende Abhängigkeit
keit zwischen Klassen kurzzeitig besteht

Assoziation Allgemeine Beziehung Gerichtet/ Ohne Einschränkung

zwischen Objekten Bidirektional
zweier Klassen

Aggregation Verfeinerung einer Gerichtet/ Ohne Einschränkung

Assoziation, die ein Bidirektional
Ganzes mit seinen Tei-
len in Beziehung setzt

Komposition Verfeinerung einer Gerichtet/ 0..1 oder 1 auf

Aggregation, bei der Bidirektional Kompositionsseite,
die Lebenszeiten keine Einschränkung
gekoppelt sind. bei den Teilen

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 100
 Vererbung und Polymorphismus
 Grundlagen der Vererbung
– Ähnlichkeiten zwischen Klassen
– Einfach- und Mehrfachvererbung
– Was wird vererbt?
 Vererbungshierarchien
 Klassifikation von
Programmiersprachen
 Vererbung und Polymorphismus
– Zusammenhang der beiden Konzepte
 Abstrakte Klassen und Schnittstellen
 Praktische Hinweise zum Einsatz der Vererbung

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 101
Grundlagen der Vererbung
Vererbung ist eine Beziehung zwischen einer
allgemeinen Klasse (Oberklasse) und einer
spezialisierten Klasse (Unterklasse), bei der die
Unterklasse über alle Eigenschaften der Oberklasse verfügt.
 Eine Klasse kann von einer oder mehreren
Oberklassen erben.
– Einfachvererbung
– Mehrfachvererbung
 Vererbung drückt Ähnlichkeiten zwischen Abstraktionen aus.
– Eine Unterklasse ist eine Oberklasse.
– Statt Vererbung wird auch der Begriff Generalisierung verwendet.

Vererbung ist eine Beziehung zwischen Klassen.

 Da keine Objekte betroffen sind, gibt es keine _____________________________.

 Die Beziehung hat eine festgelegte Bedeutung, so dass ein Name überflüssig ist.
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 102
Einfachvererbung

Vererbung wird durch einen

Ausstattung nicht ausgefüllten Pfeil
dargestellt.
 Der Pfeil verläuft von der
Unterklasse zur Oberklasse.
Radio Alufelgen ... Sitzheizung
 Der Pfeil lässt sich als
Abhängigkeit deuten:
– Die Unterklasse kennt die
Radio, Alufelgen usw. sind spezielle
Oberklasse.
Sonderausstattungen.
– Die Oberklasse kennt ihre
Sie sind Unterklassen von Unterklassen nicht!
Ausstattung und erben alle  Mehrere Einzelpfeile können zu
Eigenschaften dieser Klasse.
einem Baum zusammengefasst
werden.
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 103
Mehrfachvererbung

Bei der Mehrfachvererbung

Ausstattung Elektrischer Verbraucher erbt eine Unterklasse von
mehreren Oberklassen.
 Die Unterklasse besitzt
damit die Eigenschaften von
... ... allen Oberklassen.
Alufelgen Sitzheizung Fensterheber
Mehrfachvererbung wird
häufig falsch eingesetzt!
Es gibt zusätzlich eine Klasse Elektrischer Verbraucher, die gemeinsame
Eigenschaften wie die Berechnung der Leistungsaufnahme erlaubt.

Die Sitzheizung ist sowohl eine Sonderausstattung als auch ein elektrischer
Verbraucher und erbt daher von beiden Klassen.

Im Gegensatz dazu sind Fensterheber zwar elektrische Verbraucher, da diese aber

in der Serienausstattung enthalten sind, erben sie nicht von Ausstattung.
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 104
Was wird vererbt?

Unterklassen erben alle Eigenschaften der Oberklassen:

 Verhalten
 Zustand
 Beziehungen

Zusätzlich können Unterklassen

 neue Attribute, Operationen und Beziehungen hinzufügen,
 geerbte Operationen durch eine eigene Version ersetzen.

– Dies wird bezeichnet als: ____________________________________

– Dies wird im Zusammenhang mit Polymorphismus näher erläutert.

Vererbung betont die

Gemeinsamkeiten zwischen Klassen

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 105
Erben von Verhalten

Unterklassen erben alle Operationen der Oberklasse.

Unterklassen können neue Operationen hinzufügen.

Ausstattung
gibName() Ein Radio unterstützt alle Operationen der
gibPreis() Oberklasse Ausstattung, d. h. man kann z. B. den
drucken() Namen und Preis eines Radios erfragen.
Zusätzlich kann man radiospezifische Operationen
aufrufen und abfragen, z. B. ob das Autoradio
einen ARI-Verkehrsfunkempfänger oder einen
Radio CD-Player hat.
hatARI() : bool
hatCD() : bool

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 106
Erben des Zustands

Unterklassen erben alle Attribute der Oberklassen.

Unterklassen können neue Attribute hinzufügen.

Ausstattung
name : string Ein Radio besitzt drei Attribute:
preis : währung
Die Attribute name und preis werden von
Ausstattung vererbt.
Zusätzlich hat es ein eigenes Attribut, das
die Anzahl der Stationstasten speichert.
Radio
anzahlStationstasten : integer

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 107
Erben von Beziehungen

Unterklassen erben alle Beziehungen der Oberklasse.

Unterklassen können neue Beziehungen hinzufügen.

Ausstattung Auto Ein Radio ist wie alle Sonderaus-

0..* 1 stattungen ein Teil eines Autos.
Außerdem kann eine Radio einen
CD-Player enthalten.
Radio CDPlayer
1 0..1 Der CD-Player könnte übrigens auch
eine eigene Sonderausstattung sein
und deshalb von Ausstattung erben.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 108
Vererbungshierarchien
Vererbung kann über mehrere Ebenen erfolgen.
 Theoretisch ist die Anzahl der Ebenen unbegrenzt.
 Praktisch werden 3 bis 5 Ebenen selten überschritten.
Vererbungshierarchien entstehen auf verschiedene Weise:
 Generalisierung (Verallgemeinerung)
– Ausgehend von spezialisierten Klassen wird nach Gemeinsamkeiten gesucht, die dann in
eine Oberklasse ausgelagert werden.
– Vorgehensweise: bottom-up
 Spezialisierung
– Ausgehend von einer vorhandenen Klasse wird eine neue Unterklasse gebildet, in der die
Abweichungen von der Oberklasse modelliert werden.
– Vorgehensweise: top-down

In der Praxis treten beide Vorgehensweisen zusammen auf.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 109
Abstraktionsebenen

Vererbungshierarchien sind gleichzeitig

Abstraktionsebenen.
 Die Klassen auf einer Ebene sollten denselben
Abstraktionsgrad haben.
– Wenn man für jede Ebene einen Namen findet, ist es ein gutes
Zeichen.
 Oft ist es sinnvoll, fehlende Zwischenabstraktionen
einzuführen.
– Dies kann man auch tun, wenn sie nicht direkt verwendet werden.
– Meist ergeben sich später sowieso Gemeinsamkeiten, welche die
Zwischenstufe rechtfertigen.
– Die Vor- und Nachteile sollte man im Einzelfall gegeneinander
abwägen.
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 110
Vorteile der Vererbung
Vererbungshierarchien drücken Gemeinsamkeiten zwischen Klassen aus:

 Gemeinsame Attribute, Operationen und Beziehungen sind in der Oberklasse nur
einmal vorhanden.
 Dies reduziert den Umfang neu zu schreibenden Codes und erhöht die
Wiederverwendung.
 Dies fördert die Einheitlichkeit des Codes
– Dieselbe Aufgabe wird überall einheitlich behandelt.
– Einfache Änderung und Fehlerbehebung.

Durch Spezialisierung können vorhandene Klassen an neue Aufgaben

angepasst werden.
 Damit lassen sich vorhandene Klassen für neue Aufgaben nutzen.
 Bestehende Klassen bleiben unverändert.
– Dadurch können keine neuen Fehler in bestehendem Code entstehen.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 111
Nachteile der Vererbung

Enge Kopplung zwischen Unterklasse und Oberklasse.
 Unterklasse kann nicht allein wiederverwendet werden.
 Änderungen der Oberklasse können sich auf alle Unterklassen auswirken.

Viele Vorteile der Vererbung kann man auch durch Komposition

und Delegation erreichen.
 Vorhandene Klassen können über Komposition wiederverwendet werden.
 Vererbung bietet da Vorteile, wo Ähnlichkeiten zwischen Klassen bestehen
und vorhandene Funktionalität durch eigene ersetzt werden soll.
– Siehe „Polymorphismus und Vererbung“ im Anschluss.

Deshalb: Vererbung überlegt einsetzen!

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 112
Checkliste
Merkmale einer guten Vererbungshierarchie:
 Zwischen Ober- und Unterklasse liegt eine
„ist-ein“-Beziehung vor.
 Die Vererbungshierarchie entspricht der
Begriffshierarchie des Problembereichs.
 Die Unterklasse benötigt alle geerbten Attribute und
Operationen (keine Redefinitionen).
 Die Vererbungshierarchie ist flach (nicht mehr als drei Ebenen).
 Jede Klasse hat nur wenige (max. 7) direkte Unterklassen.
 Jede Klasse (auch jede abstrakte Klasse) hat einen sinnvollen
Namen.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 113
Übungsaufgabe: Vererbung
 Entwickeln Sie für folgende Klassen ein Vererbungsdiagramm:
Dreieck, Kreis, Quadrat, Rechteck
Falls Sie für ihre Vererbungsstruktur weitere Klassen benötigen, können
Sie neue Klassen einfügen.
Beschreiben Sie Attribute und Operationen der Klassen. Dreiecke,
Quadrate und Rechtecke sollen dabei über die Länge der einzelnen
Kanten beschrieben werden.
Beschreiben Sie genau die für die Attribute geltenden Randbedingungen.
Verwenden Sie hierfür die UML-Erweiterungsmechanismen.
 Stellen Sie für folgende Klassen ein Vererbungsdiagramm auf:
Ausführbare Datei, Datei, Dateiname, Dateisystem, Fest-
platte, Sektor, Spur, Textdatei, Verzeichnis, Zugriffsrecht
Führen Sie falls dies sinnvoll ist weitere Klassen ein.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 114
Klassifikation von Programmiersprachen (Peter Wegner)

 Objektbasierte Sprachen bieten die Möglichkeit, Objekte

im Sinne einer Datenkapsel bzw. eines Objektmoduls zu
realisieren.
+ Beispiel: Ada, Modula-2
 Klassenbasierte Sprachen bieten zusätzlich die
Möglichkeit, Objekttypen (Klassen) zu beschreiben. Jedes
Objekt ist ein Exemplar einer Klasse.
Beispiel: CLU, teilweise auch Ada und Modula-2
+
 Objektorientierte Sprachen enthalten zusätzlich die
Möglichkeit, Vererbungshierarchien aufzubauen. Klassen
können dadurch generalisiert und spezialisiert werden.
Beispiel: Smalltalk, C++, Java, Modula-3, Eiffel

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 115
Polymorphismus

Polymorphismus bedeutet _______________________________

 Zu einer Operationsschnittstelle gehören mehrere unterschiedliche
Implementierungen.
 Abhängig vom Typ des Objekts wird die zugehörige Implementierung zur
Laufzeit ausgewählt
– Dynamisches oder spätes Binden.
Hallo!
Sprich

Miau!
Bäääh!

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 116
Beispiel: Preisliste drucken
Ohne Polymorphismus
Mit Polymorphismus
druckePreisliste()
{ druckePreisliste()
// Schleife über alle Ausstattungen {
... // Schleife über alle Ausstattungen
switch ([Link]) { ...
case Sitzheizung: [Link]();
druckeHeizung(ausstattung); }
break;
case Polsterung:
druckePreisliste
druckePolster(ausstattung);
break; drucken
case Radio: : Radio
druckeRadio(ausstattung);
break;
: Preisliste
}
}
: Sitzheizung
drucken
Nicht Objektorientiert!

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 117
Polymorphismus und Vererbung (1)
Die Oberklasse gibt eine Operation vor.
 Diese Operation wird von allen Unterklassen geerbt.
 Damit ist sichergestellt, dass diese Operation in allen Unterklassen existiert.
Unterklassen können geerbte Operationen ersetzen (redefinieren).
 Damit lassen sich in den Unterklassen verschiedene Varianten einer Operation
realisieren.
 Zur Laufzeit wird automatisch die richtige Variante aufgerufen.
 Das Objekt reagiert je nach Typ unterschiedlich.
 Falls das Objekt die Operation nicht kennt, tritt ein Laufzeitfehler auf.
– Dies ist für viele Anwendungen nicht akzeptabel.

In vielen Sprachen werden Polymorphismus und Vererbung gekoppelt.

 Bei Sprachen mit strenger Typbindung werden derartige Fehler bereits vom
Compiler erkannt.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 118
Polymorphismus und Vererbung (2)

Objekte von Unterklassen können anstelle der Oberklasse treten

(aber nicht umgekehrt!).
 Jede Unterklasse hat mindestens die Funktionalität der Oberklasse.

Dies funktioniert nur dann, wenn bei der Implementierung der

Unterklasse folgende Regeln eingehalten werden:
 Die Semantik der ersetzten Operation muss erhalten bleiben.
 Die Vorbedingungen der neuen Operation dürfen nicht strenger sein als bei
der ersetzten Operation.
– Z. B. darf der Wertebereich eines Parameters nicht zusätzlich eingeschränkt
werden.
 Die Nachbedingungen der neuen Operation dürfen nicht allgemeiner sein
als bei der ersetzten Operation.
– Z. B. darf der Wertebereich eines Rückgabewerts nicht größer werden.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 119
Beispiel

Objekte werden über die

Ausstattung Operationen der
gibName() gemeinsamen Oberklasse
gibPreis() manipuliert.
drucken()
 Das Drucken eines
Angebots lässt sich
allgemein formulieren.
Alufelgen Radio Sitzheizung
 Trotzdem wird für jede
drucken() hatARI() drucken() Ausstattung die spezifische
hatCD()
drucken()
Information mit eigenem
Layout ausgedruckt.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 120
Vorteile des Polymorphismus

Polymorphismus ist eines der

mächtigsten Konzepte der
Objektorientierung:
 Er erlaubt, generische Anwendungen zu
schreiben, die je nach Klasse eines
Objekts unterschiedlich reagieren.
 Programme können um neue Typen erweitert werden, ohne
dass Aufrufe geändert werden müssen.
– Grundlage für evolutionäre Vorgehensweise.
 Ersetzt Typabfragen in herkömmlichen Programmen.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 121
Abstrakte Klassen und abstrakte Operationen
Was soll die Klasse Ausstattung in der Operation „drucken“ ausgeben?
 Sie kann nichts Sinnvolles ausdrucken, da die jeweilige Information erst in der
Unterklasse verfügbar ist.
Es ist nicht sinnvoll, Objekte der Klasse Ausstattung anzulegen.
 Die Klasse ist unvollständig.
 Sie dient nur als Basis für abgeleitete Klassen.
Klassen, von denen keine Objekte erzeugt werden dürfen heißen abstrakte
Klassen.
 Um sie anwenden zu können, muss es mindestens eine Ausstattung

nicht abstrakte Unterklasse geben. gibName()

gibPreis()
Abstrakte Klassen werden durch das Schlüsselwort „abstract“ drucken()

gekennzeichnet oder der Klassenname wird kursiv gesetzt.

Abstrakte Operationen werden auf die gleiche Weise dargestellt.
 Eine Klasse mit mindestens einer abstrakten Operation ist automatisch abstrakt.
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 122
Schnittstellen
Oft soll eine Klasse nur eine Reihe abstrakter
Operationen zur Verfügung stellen.
 Damit lassen sich generische Anwendungen entwerfen.
 Die Operationen werden typspezifisch in Unterklassen implementiert.
Abstrakte Klassen, die nur abstrakte Operationen beinhalten, definieren eine
Schnittstelle.
 Die Trennung von Schnittstelle und Implementierung ist so wichtig, dass sie in der
UML als eigenständiges Konzept vorhanden ist.
Eine Schnittstelle ist in UML ein eigenständiges Modellelement.
 Eine Schnittstelle definiert eine Reihe abstrakter Operationen.
 Schnittstellen können über mehrere Ebenen vererbt werden.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 123
Darstellung von Schnittstellen

Darstellung
in UML:
Klasse1 benutzt Klasse2 realisiert
Schnittstelle Schnittstelle

Klassen realisieren Schnittstellen.

 Alle Operationen der Schnittstelle müssen implementiert werden.
 Klassen stellen Dienste über Schnittstellen zur Verfügung.

Anwender benutzen Schnittstellen

 Anwender benutzen nur die Schnittstellen.
 Sie interessieren sich nicht dafür, wie diese implementiert sind.
© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 124
Sinnvoller Einsatz der Vererbung
Vererbung ist ein mächtiges Konzept.
 Das Vorhandensein von Vererbung unterscheidet
objektbasierte von objektorientierten Sprachen.
 Vererbung wird von Anfängern zu häufig und oft falsch eingesetzt.
 Tiefe Vererbungshierarchien sind nicht durchschaubar.
Oft muss genau geprüft werden, ob ein Problem mit Vererbung oder mit
Aggregation zu lösen ist.

Merkmal Vererbung Aggregation

Beziehungsart Beziehung zwischen Klassen Beziehung zwischen Objekten

verschiedener Klassen

Art der Ist-Beziehung Enthalten-Beziehung

Beziehung

Mehr als ein Nein Ja

Objekt?

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 125
Mehrfachvererbung
Mehrfachvererbung ist konzeptionell einfach zu verstehen.
In der Praxis ergeben sich eine Reihe von Schwierigkeiten.
 Probleme bei der Implementierung von Mehrfachvererbung:
– Mehrfaches Erben von Attributen.
– Mehrfaches Erben von Oberklassen.
 Mehrfachvererbung wird häufig falsch eingesetzt.
 Nicht alle Sprachen unterstützen Mehrfachvererbung.
Mehrfachvererbung sollte nur mit Vorsicht eingesetzt werden!
Die Mehrfachvererbung von Schnittstellen birgt weniger Gefahren:
 Schnittstellen geben nur abstrakte Operationen ohne Implementierung vor.
 Implementierung mehrerer Schnittstellen unterstützt den modularen
Systementwurf.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 126
Zusammenfassung
Vererbung drückt Ähnlichkeiten zwischen Klassen aus:
 Einfachvererbung bei einer Oberklasse.
 Mehrfachvererbung bei mehreren Oberklassen.
Es werden Attribute, Operationen und Beziehungen vererbt.
 Die Unterklasse kann die Oberklasse erweitern.
Vererbung ist häufig mit Polymorphismus gekoppelt.
Abstrakte Klassen sind Klassen, von denen keine Objekte erzeugt werden
dürfen.
 Sie dienen als Basis für abgeleitete Klassen.
 Schnittstellen sind abstrakte Klassen, die nur abstrakte Operationen enthalten.
Vererbung, insbesondere Mehrfachvererbung, muss richtig eingesetzt werden.
 Eine Vererbungshierarchie sollte Spezialisierungen darstellen.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 127
Beispiel Polymorphismus und Vererbung

A B Welche Fehler enthält das

a3 a1 Klassendiagramm? Berichtigen
a2
op3()
gehört
Sie die Fehler.
op1()
zu op2() Welche Nachrichten sind für
op3()
Objekte der Klassen A, C, D, E
und F erlaubt bzw. nicht
erlaubt? Welche Operation
C D E welcher Klasse wird
a3 op2() op3() aufgerufen?
op3() op4()
op4()
Beachte: Über die Beziehung
zwischen A und B können von
F A aus Operationen der
a1 Schnittstelle von B aufgerufen
op5() werden.

© Duale Hochschule Baden-Württemberg Stuttgart, Prof. Dr. Jürgen Schwille Methoden WI: Systemanalyse Stand: 01.03.2021, Folie 128