Post on 02-Apr-2018
Modellieren mit der Unified Modeling Language:
Klassen- und Objektdiagramme
11. November 2014
Taentzer Einführung in die Softwaretechnik 128
Überblick
Was ist die Unified Modeling Language (UML)? die Standardmodellierungssprache für Softwaresysteme von der Object Management Group entwickelt: www.uml.org Welche Systemaspekte werden modelliert?
Objektorientierte Software-Modellierung mit der UML Welche Objektstrukturen werden mit Klassendiagrammen
modelliert? Welche nicht? Wie unterscheiden sich Klassen- von Objektdiagrammen?
Wie ist die Beziehung zwischen Klassenmodellen und Java-Klassen? speziell: Vererbungsbeziehungen, Kardinalitäten > 1
Taentzer Einführung in die Softwaretechnik 129
Die UML ist eine einheitliche Modellierungssprache für Softwaresysteme.Verschiedene Systemaspekte werden mit verschiedenen Diagrammarten modelliert:(a) für die Datenstrukturen (Statische Strukturen):• Klassen- und Objektdiagramme (Class and Object Diagram)(b) für das Systemverhalten (Dynamik):• Anwendungsfalldiagramm (Use Case Diagram)• Interaktionsdiagramm (Interaction Diagram, früher: Sequence Diagram) • Kollaborationsdiagramm (Collaboration Diagram) • Zustandsdiagramm (State Diagram)• Aktivitätsdiagramm (Activity Diagram)(c) für den Systementwurf (Statische Strukturen):• Komponentendiagramm (Component Diagram) • Einsatzdiagramm (Deployment Diagram)
Die Unified Modeling Language (UML)
Taentzer Einführung in die Softwaretechnik 130
Ein Klassendiagramm zeigt die statische Struktur eines Systems bildet den Kern des Analysemodells enthält Elemente der folgenden Arten:
Paket
Objektklasse
Attribut und Operation
Assoziation (mit Bezeichnung, Kardinalitäten und Rollen)
Generalisierungs-/Spezialisierungsbeziehung
UML-Klassendiagramme
Taentzer Einführung in die Softwaretechnik 131
Klassen und Attribute Eine Klasse spezifiziert eine Klassifikation von Objekten mit
gleichen Strukturmerkmalen (Attributen) gleichen Verhaltensmerkmalen (Operationen) gleichen Beziehungen zu anderen Objekten
Objekte sind Instanzen von Klassen. Abstrakte Klassen haben keine Objekte.
Person
name: Stringvorname: Stringgeburtstag: Datumadresse: String
alterBerechnen()adresseDrucken()
Maier: Person
name = Maiervorname = Alfonsgeburtstag = 31.12.1975 adresse = Krummbogen 29, 35037 Marburg
Klasse: Objekt:
Taentzer Einführung in die Softwaretechnik 132
bidirektional / 2-stellig
unidirektional
Komposition / starke Aggregation
schwache Aggregation
Zusätzliche Charakterisierungen:
Rollen-Bez.Kardinalität
Rollen-Bez.Kardinalität
Assoziationsbezeichner[+ mögl. Pfeil f. Leserichtung]
Die Kardinalität (engl. multiplicity) a .. b gibt die minimale / maximale Anzahl (gleichzeitig) möglicher Objektbeziehungen an. * entspricht 0 .. beliebig viele1 entspricht 1 .. 1
Assoziationen
{ordered} - sortiert
Taentzer Einführung in die Softwaretechnik 133
Fachbereich ist angestellt bei
1 *
Vorlesung
Lehreinheit
1
*
Lehrveranstaltung
hält
*
Dozent
1..3
bietet an
1
*
Personist vorgesetzt
1*
vorgesetzter
untergebener besteht aus
Beispiele für Assoziationen
Taentzer Einführung in die Softwaretechnik 134
Objektbeziehungen: Assoziationsinstanzen
A B1 0..*
:A :B:B:B
Assoziation: Objektbeziehungen:
A B0..* 0..* :A :B:B:B
:A :B
:B
Taentzer Einführung in die Softwaretechnik 135
• Assoziationen können selbst komplex sein und eigene Attribute bzw. Methoden tragen.
• In diesem Fall ist oft eine Modellierung als eigene Klasse am zweckmäßigsten. Wir nennen diesen Vorgang Objektifizierung (engl. reification = Vergegenständlichung) und die entstehende Klasse Assoziationsklasse.
• In der UML gibt es eine eigene Notation dafür. Assoziationsklassen verhalten sich wie andere Klassen. Ihre Existenz ist aber von der Existenz der Klassen abhängig, welche die Assoziation begründen.
Beispiel: Student Lehrveranstaltungbesucht
* *
LV_Besuch
- status: Status- note: Note+ statusÄndern ()+ examenAblegen ()
Assoziationsklassen
Taentzer Einführung in die Softwaretechnik 136
Klassen lassen sich spezialisieren, dabei entstehen aus einer Oberklasse (i.a. mehrere) Unterklassen. Umgekehrt lassen sich ähnliche (Unter-) Klassen zu einer gemeinsamen (Ober-) Klasse generalisieren.
Jedes Objekt einer Unterklasse ist gleichzeitig auch Objekt der Oberklasse, aber nicht umgekehrt. Zwischen (Objekten) einer Oberklasse OK und einer Unterklasse UK besteht eine "ist_ein" (engl.: "is_a") -Beziehung. Die Umkehrung der Beziehung lässt sich charakterisieren als "kann_sein" .
Beispiel: Vorlesung ist_ein(e) Lehrveranstaltung, Seminar ist_ein(e) Lehrveranstaltung,Lehrveranstaltung kann_sein Vorlesung oder Seminar
Lehrveranstaltung
Generalisierung / Spezialisierung
SeminarVorlesung
Student besucht 3..* 0..*
Taentzer Einführung in die Softwaretechnik 137
Abstrakte und konkrete Klassen
Abstrakte Klassen haben keine Instanzen.
Abstrakte Klassen treten meist als Oberklassen auf. Sie vereinigen Klassenmerkmale, die alle Unterklassen haben.
Beispiel: Lehrveranstaltung ist eine abstrakte Klasse. Eine Lehrveranstaltung muss eine konkrete Ausprägung haben, also eine Vorlesung oder ein Seminar sein.
:Student
:Vorlesung
:Vorlesung
:Student
:Seminar:Student
:Student
Beispiel für ein Objektdiagramm:
:Lehrveranstaltung
Taentzer Einführung in die Softwaretechnik 138
Spezialisierung bzw. Generalisierung geht in der Regel einher mit Vererbung: Klassen-Merkmale (Attribute und Operationen) der Oberklasse werden an
alle Unterklassen weitergegeben ("vererbt").Ober- und Unterklassen bilden eine Vererbungshierarchie:
Die Vererbungshierarchie entspricht häufig einer
Baumstruktur ("Einfachvererbung", "single inheritance") zuweilen auch einer
Netzstruktur ("Mehrfachvererbung", "multiple inheritance")
Klasse_1
(Unter-) Klasse_3
Vererbung
. . .. . .
(Unter-) Klasse_2
Taentzer Einführung in die Softwaretechnik 139
Aggregation und KompositionSpezielle Assoziationen:
Enthaltenseins-Beziehungen Komposition: Teil gehört zu einem Ganzen.
Aggregation: Teil kann selbstständig existieren.
Beispiel:
Feld gehört zu Spielbrett.
Lehreinheit ist Teil einer Vorlesung.
FeldSpielbrett
Vorlesung Lehreinheit
0..*
1..*
Taentzer Einführung in die Softwaretechnik 140
Beispiele für Objektdiagramme
: Feld: Spielbrett
: Feld
: Feld
: Feld
: Feld
: Vorlesung : Lehreinheit: Lehreinheit: Lehreinheit: Lehreinheit
: Lehreinheit
Taentzer Einführung in die Softwaretechnik 141
Ausbau des Analysemodells
Analyse der Anwendungsfallbeschreibung bezüglich Objekteigenschaften und –fähigkeiten.
Welche Mengenangaben werden in der Anwendungsfall-beschreibung gemacht?
Analyse von Formularen hinsichtlich Objekteigenschaften. Falls generalisiert wird, ...
...ist die Oberklasse abstrakt? ...welche Klasse enthält welche Attribute und welche
Operationen? ...welche Klasse hält welche Beziehungen?
Taentzer Einführung in die Softwaretechnik 142
Anwendungsfall “Bestellung annehmen”
• Das Zentrum empfängt Bestellungen der Einzelhändlertelefonisch von 9 bis 17 Uhr (S7).
• Die eingehenden Bestellungen der Kunden werden vom Sachbearbeiter in Bestellformularen erfasst (S8).
• Eine Kundenbestellung kann aus mehreren Bestellpostenbestehen. Diese beziehen sich auf einzelne Produkte (S9).
• Jeder Bestellposten wird auf dem Formular in einer Zeile notiert (S10).
Analyse der Anwendungsfälle (1)
Mengenangaben
Taentzer Einführung in die Softwaretechnik 143
Anwendungsfall “Bestellung bearbeiten”
• Der Anwendungsfall “Lagerbestand ermitteln” wird benutzt, um für jeden Posten der gerade bearbeiteten Kundenbestellung den aktuellen Lagerbestand des zugehörigen Produktes zu ermitteln (S11).
• Wenn das Zentrum eine Bestellung entgegennimmt, wirdjeder Bestellposten in eine der beiden folgenden Karteieneingeordnet: (a) Lieferkartei, (b) Wartekartei (S13).
• Falls für einen Bestellposten genügend Waren auf Lager sind, dann wird dieser in die Lieferkartei eingetragen und der Lagerbestand entsprechend korrigiert (S14). Anderenfalls wird der Bestellposten in die Wartekarteieingetragen (S15).
Analyse der Anwendungsfälle (2)Mengenangaben
Generalisierung
Taentzer Einführung in die Softwaretechnik 144
Beispiel: Verfeinertes Analysemodell
Objektdiagramm: Beispiel
Taentzer Einführung in die Softwaretechnik 145
Aufzählungstypen
Ein Aufzählungstyp ist eine spezielle Klasse. Er wird durch den Stereotyp
<< enumeration>> markiert.
Er besteht aus einer Liste von Literalen. Ein Literal hat einen Namen und
einen Typ.
Ein Stereotyp kann ein Modellelement spezialisieren.
Taentzer Einführung in die Softwaretechnik 146
Taentzer Einführung in die Softwaretechnik 147
Überblick
Was ist die Unified Modeling Language (UML)? die Standardmodellierungssprache für Softwaresysteme Welche Systemaspekte werden modelliert?
Objektorientierte Modellierung mit der UML Welche Objektstrukturen werden mit Klassendiagrammen
modelliert? Welche nicht? Wie unterscheiden sich Klassen- von Objektdiagrammen?
Wie ist die Beziehung zwischen Klassenmodellen und Java-Klassen? speziell: Vererbungsbeziehungen, Kardinalitäten > 1
Taentzer Einführung in die Softwaretechnik 148
Eine Beziehung zwischen Klassenmodellen und Java-Klassen UML-Klasse → Java-Klasse
Sichtbarkeit ist nicht in UML modelliert.
Eigenschaft „abstract“ wird direkt übersetzt.
UML-Schnittstellenklasse → Java-Schnittstellenklasse
UML-Vererbung → Java-Vererbung Mehrfachvererbung muß in
Einfachvererbung + Implementierung von Schnittstellen aufgelöst werden
UML-Paket → Java-Paket <<access>>- Beziehung →
import-Anweisung in Java
UML-Attribut → Java-Feld Sichtbarkeit wird direkt übersetzt. Default-Wert wird auch übernommen. Datentyp muss eventuell angepasst
werden. Bei Kardinalität >1 wird eine Collection
von Objekten angelegt. für „ordered“ eine sortierte Menge
v. Objekten sonst: Menge (Set) von Objekten
UML-Operation → Java-Methode Sichtbarkeit wird direkt übersetzt. Rückgabetyp wird direkt übersetzt. UML-Parameterliste sollte nur Input-
Parameter enthalten. Diese werden direkt übersetzt.
Taentzer Einführung in die Softwaretechnik 149
Eine Beziehung zwischen Klassenmodellen und Java-Klassen
UML-Assoziation → ein oder zwei Java-Felder:
Für jedes navigierbare Ass.ende e: Entgegengesetztes Ass.ende d zeigt
auf die Klasse, die um ein Feld erweitert wird.
Rollenname von e wird der Feldname. Die Klasse, auf die e zeigt, wird der
Feldtyp. Sichtbarkeiten der Ass.enden werden
direkt übernommen. Ass.ende e hat Kardinalität j<= 1:
Feld zeigt auf ein Objekt.
Ass.ende e hat Kardinalität j>1: → Menge (Set) von Objekten {ordered} → sortierte Menge
(SortedSet) von Objekten Komposition:
Java-Code erzeugt die entsprechenden Objekte.
UML-Literal → Java-Konstante UML-Enumeration → Java
Enum Typ
A Be
d i..jk..l
Taentzer Einführung in die Softwaretechnik 150
Modellierte Klassen
public class Lieferkartei{//...}
Lieferkartei.java:
public abstract class Kartei{public void eintragen(Bestellposten posten){//...}public void loeschen(Bestellposten posten) {//...}}
Kartei.java:
public abstract class Kartei{//...public SortedSet<Bestellposten> bestellposten;}
Taentzer Einführung in die Softwaretechnik 151
Assoziationen
Kartei.java:
Bestellposten.java:
Assoziationsnamepublic class Bestellposten{private int nummer;private int menge;Kartei kartei;public void korrigieren(int nr, int m){//...}}
Taentzer Einführung in die Softwaretechnik 152
public class Kundenbestellung extends Bestellung{private Firma kunde;}
Kundenbestellung.java:
Vererbung
public abstract class Bestellung{private Date datum;private int nummer;public void aendern(Adresse lieferadr){//...}}
Bestellung.java:
Mehrfachvererbung
Taentzer Einführung in die Softwaretechnik 153
Fahrzeug
WasserfahrzeugMotorfahrzeug
Motorboot
public class Motorfahrzeug extends Fahrzeug{}
Motorfahrzeug.java:
public class Wasserfahrzeug extends Fahrzeug{}
Wasserfahrzeug.java:
public class Motorboot extends Wasserfahrzeugimplements IMotorfahzeug{
}
Motorboot.java:
public abstract class Fahrzeug{}
Fahrzeug.java:
Taentzer Einführung in die Softwaretechnik 154
public class Firma{private String name;private String kontakt;Set<Kundenbestellung> kundenbestellung;Set<Produzentenbestellung> produzentenbestellung;}
Firma.java:
public class Kundenbestellung extends Bestellung{private Firma kunde;}
Vererbung
Kundenbestellung.java:
Taentzer Einführung in die Softwaretechnik 155
Zusammenfassung
Die UML ist die Standardmodellierungssprache für Softwaresysteme. Sie bietet umfangreiche Konzepte zur Modellierung der statischen
Strukturen von Softwaresystemen.
Klassendiagramme beschreiben die Typebene. Objektdiagramme modellieren konkrete Objektstrukturen. Direkte Übersetzung eines Klassenmodells in Java-Code
UML-Klassen -> Java-Klassen UML-Attribute -> Java-Felder UML-Assoziationen -> Java-Felder Mehrfachvererbung -> Einfachvererbung + Schnittstellen