3.10 UML-Klassendiagramme Wir werden uns in diesem Kapitel näher mit dem UML-Domänenmodell und mit UML-Klassendiagrammen beschäftigen

UML (Unified Modelling Language) UML ist eine umfassende Modellierungssprache zur Spezifikation von Anwendun- gen. Sie ermöglicht die Modellierung der verschiedensten Sachverhalte. Wir empfehlen nachdrücklich, größere Programme mit UML zu modellieren, bevor man sie implementiert. Wir führen jetzt das Domänenmodell und die Klassendiagramme ein. Literatur: Craig Larman: UML 2 und Patterns angewendet. mitp –Verlag, Heidelberg, 2005

Das Domänenmodell Ein Domänenmodell ist eine visuelle Repräsentation der problemrelevanten Kon-zepte einer Domäne in Form eines Diagramms. Domänenmodelle werden auch als conceptual models (konzeptuelle Modelle), domain object models (Domänenobjektmodelle) und analysis object models (Analyseobjektmodelle) bezeichnet.

Beispiel für ein Domänenmodell Sales LineItem quantity Payment amount Sale date time Register Store address name Item Records-sale-of 0..1 1 Contained-in Paid-by Stocked-in Captured-on ► Houses 1..* Begriff oder Domänenobjekt Assoziation Attribute *

Inhalt des Domänenmodells Das Domänenmodell zeigt konzeptuelle Klassen (conceptual classes) und verwendet dazu das Vokabular des Anwendungsbereiches. Informell ist eine konzeptuelle Klasse eine Idee, ein Ding oder ein Objekt aus dem Anwendungsbereich. Formaler ausgedrückt: Eine konzeptuelle Klasse ist durch ein Symbol, einen Inhalt und einen Umfang gekennzeichnet. Die Ähnlichkeit der Namen von konzeptuellen Klassen im Domänenmodell und der Namen von Softwareklassen im Klassendiagramm trägt dazu bei, dass die Lücke zwischen unserem mentalen Modell der Anwendung und seiner Repräsentation in Software möglichst klein gehalten wird.

„Low Representational Gap“ (1) Dies ist eine zentrale Idee bei der Objektorientierung: Wir verwenden die Namen aus dem Domänenmodell für die Namen der Softwareklassen, deren Objekte die ent- sprechenden anwendungsbereichsspezifischen Informationen enthalten! Diese Idee nennt man Low Representational Gap.

„Low Representational Gap“ (2) Domänenmodell zeigt die wesentlichen Konzepte aus der Sicht der Anwendung Payment amount Sale date time 1 Pays-for „Payment“ (Bezahlung) im Domänenmodell ist ein Konzept, „Payment“ im Klassendiagramm ist eine Softwareklasse. Dadurch wird der Ab-stand zwischen dem mentalen Modell und dem Softwaremodell (das „representional gap“) verkleinert. 1 liefert die Vorlage für Objekte und Namen date: Date start Time: Time getTotal (): Money … Sale Payment Pays-for amount: Money 1 getBalance(): Money Klassendiagramm

Modellierung als Klasse vs. Attribut Der vielleicht häufigste Fehler beim Erstellen eines Domänenmodells besteht darin, etwas als Attribut (Datenfeld) zu repräsentieren, das eigentlich eine konzeptuelle Klasse sein sollte. Faustregel: Wenn wir eine konzeptuelle Klasse X im Domänenmodell nicht als ein- fache Zahl oder als Text auffassen, ist X wahrscheinlich eine Java-Klasse und kein Attribut.

Beispiel 1 Ein Beispiel: Sollte „Store“ (Laden, Geschäftslokal) ein Attribut von „Sale“ oder ein separates Objekt (später eine Klasse) sein? Sale store oder…. Store phoneNumber In unserer Anwendung lässt der Begriff „store“ auf eine eigenständige Entität schließen, die Raum einnimmt und eigene Attribute haben kann (zum Beispiel „phoneNumber“). Deshalb sollte „store“ als ein eigenes Objekt (als Klasse) modelliert werden.

Beispiel 2 Wir nehmen ein weiteres Beispiel aus dem Bereich der Flugreservierung: Sollte „desti- nation“ ein Attribut von „Flight“ oder ein separates konzeptuelles Objekt „Airport“ sein? Flight destination Flight Airport name oder…. In unserer Anwendung wird ein Zielflughafen nicht als Zahl oder Text aufgefasst – es handelt sich um ein massives Ding, das Raum einnimmt und mehrere eigene Attribute haben kann. Deshalb sollte auch „Airport“ ein eigenes Objekt (und später eine Klasse) sein.

* bedeutet „beliebig viele“ Assoziationen Assoziationen stellen Beziehungen zwischen Objekten dar. Sie haben einen Namen und eine Multiplizität. Flight date number time Flies-to Airport name * 1 Rektor name Universität name Studierendenzahl 1 1 * bedeutet „beliebig viele“

Assoziationsnotation (1) Eine Assoziation wird als Linie zwischen zwei Klassen repräsentiert und mit einem groß geschriebenen Assoziationsnamen gekennzeichnet. Die Enden einer Assoziation können einen Multiplizitätsausdruck enthalten, der die numerische Beziehung zwischen den Instanzen der Klassen beschreibt. Die Assoziation ist von Natur aus bidirektional. Das bedeutet, dass von einer In- stanz einer Klasse (also einem Objekt in Java) ein logischer Weg zu einer Instanz der anderen Klasse führt und umgekehrt.

Assoziationsnotation (2) Die Multiplizität definiert, wieviele Instanzen einer Klasse A mit einer Instanz einer Klasse B verknüpft sein können. Store Item * 1 Stocks Multiplizität Im Beispiel kann eine einzelne Instanz eines „Store“ mit beliebig vielen (null oder mehr, angezeigt durch das Sternchen *) „Item“-Instanzen verknüpft sein.

Multiplizitätswerte T * null oder mehr; „viele“ 3, 5, 8 genau 3, 5 oder 8 1.. * eins oder mehr 1..40 eins bis 40 5 genau 5

Beispiele (1) Student Vorlesung Besucht * Person 0..1 ist verheiratet mit

UML-Klassendiagramme UML stellt Klassendiagramme (class diagrams) zur Verfügung, um Klassen, Inter-faces und Assoziationen zu veranschaulichen. Sie werden gerne für die statische Objektmodellierung verwendet.

SuperClassFoo (abstract) Ein erstes Beispiel SuperclassFoo oder SuperClassFoo (abstract) classOrStaticAttribute : Int + publicAttribute: String privateAttribute assumedPrivateAttribute isInitializedAttribute : Bool = true aCollection : VeggieBurger [*] attributeMayLegallyBeNull : String [0..1] finalConstantAttribute : Int = 5 {readOnly} /derivedAttribute + classOrStaticMethod() + publicMethod() assumedPublicMethod() privateMethod() # protectedMethod() ~ packageVisibleMethod() „constructor“ SuperclassFoo (Long) methodWithParms (parm1 : String, parm2 : Float) methodReturnsSomething() : VeggieBurger methodThrowsException (){exeption IOException} abstractMethod() abstractMethod2() {abstract} // alternate finalMethod() {leaf} // no override in subclass synchronizedMethod() {guarded} Offiziell trennt das obere Format in der UML den Paketnamen und den Klassennamen. Inoffiziell ist die zweite Variante gebräuchlich. 3 gebräuchliche Abschnitte Klassenname Attribute Operationen java.awt::Font oder java.awt.Font plain : Int = 0 { readOnly } bold : Int = 1 { readOnly } name : String style : Int = 0 … getFont(name : String) : Font getName() : String Ein Interface, das mit einem Schlüsselwort gezeigt wird „interface“ Runnable Fruit … run() Interface- Implementierung und Unterklassenbildung Abhängigkeit SuperclassFoo … run() 1 PurchaseOrder … order Fortsetzungspunkt (Ellipsen) „…“ bedeuten, dass es Elemente geben kann, die aber nicht gezeigt werden - Ein leerer Abschnitt bedeutet offiziell „unbekannt“, zeigt aber per Konvention an, dass „keine Elemente“ vorhanden sind. Assoziation mit Multiplizität

Attribute in Klassendiagrammen Die Attribute (Eigenschaften, Merkmale) werden in der UML auch als properties be- zeichnet (structural properties oder kurz properties). Es gibt mehrere Methoden, um Attribute anzuzeigen: Attributtext-Notation wie beispielweise „currentSale“ Assoziationslinien-Notation, Assoziation-Notation beides zusammen. Das komplette Format der Attributtextnotation lautet: Sichtbarkeit Name : Typ Multiplizität = Standardwert {Eigenschaftswert}

Beispiel für die drei Arten der Attributdarstellung currentSale : Sale … Register Sale Hier wird die Attribut-textnotation verwen-det, um anzuzeigen, dass Register eine Referenz auf eine Sale-Instanz hat. Man beachte: Dieser Stil betont visuell die Verbindung zwischen den Klassen. … Register Sale currentSale 1 Hier wird die Assoziationsnotation verwendet, um anzuzeigen, dass Register eine Referenz auf eine Sale-Instanz hat. Gründlich und eindeutig, aber einige Leute mögen die Redundanz nicht. currentSale : Sale … Register Sale currentSale 1

Navigationsrichtungspfeile Ein Navigationsrichtungspfeil zeigt von dem Quellobjekt (Register) zum Zielobjekt (Sale) und zeigt damit an, dass ein „Register“-Objekt einen „Sale“ als Attribut enthält. Am Zielende des Pfeils ist eine Multiplizität angegeben, am Quellende dagegen nicht. Der Attributname wird nur am Zielende als Rollennamen (currentSale) angegeben. Es gibt keinen Namen für den Richtungspfeil. Der Pfeil geht vom Objekt zum Attribut. Pfeile werden in Klassendiagrammen verwendet, nicht aber im Domänenmodell.

Die Pfeilrichtung bei Assoziationen in Klassendiagrammen Beispiel id: Int Register time: Date Time Sale 1 Capture-current-sale Domänenmodell Klassen-diagramm Register Sale 1 id: Int time: Date Time currentSale … …

Darstellung von Kollektionen public class Sale { private List<SaleLineItem> lineItems = new ArrayList<SalesLineItem>(); // … } time: DateTime lineItems : SalesLineItem [1..*] oder lineItems : SalesLineItems [1..*] {ordered} Sale … … SalesLineItem time: DateTime Sale … 1..* … SalesLineItem lineItems {ordered, List}

Anmerkungssymbole in UML-Diagrammen Anmerkungssymbole können in jedes UML-Diagramm eingefügt werden, sie werden besonders häufig in Klassendiagrammen verwendet. Ein UML-Anmerkungssymbol besteht aus einem Rechteck mit einem Eselsohr. Das Rechteck ist mit einer gestrichelten Linie mit dem Element verbunden, auf das sich die Anmerkung bezieht. Solche Anmerkungen sind schon in verschiedenen unserer Beispiele vorgekommen.

Darstellung von Methoden in Klassendiagrammen Meist stellt man Methoden in Form von Anwendungen dar. Anmerkung „method“ // Pseudocode oder eine spezielle Sprache public void enterItem(id, qty) { ProductDescription desc = catalog.getProductDescription(id); sale.makeLineItem(desc, qtv); } … Register endSale() enterItem(id, qty) makeNewSale() makePayment(cashTendered) Mit dieser Notation wird das statische Klassendiagramm mit dynamischen Elementen vermischt.

Generalisierung/Vererbung Generalisierung wird in UML mit einer durchgezogenen Linie mit einer dreieckigen Pfeilspitze dargestellt, die von der Unterklasse auf die Oberklasse zeigt. Beispiel: Konto Sparkonto Girokonto In einem Klassendiagramm bedeutet eine Generalisierung wie in Java eine Ver-erbung von Datenfeldern und Methoden von der Oberklasse zur Unterklasse.

Abhängigkeiten (1) Neben den Abhängigkeiten von Attributen von ihren Objekten und von Unterklassen von ihren Oberklassen lassen sich auch andere Arten von Abhängigkeiten in Klas- sendiagrammen darstellen. Beispiele sind: Ein Client sendet eine Nachricht an einen Supplier, der Supplier ist für das Objekt sichtbar, und die Sichtbarkeit kann in einer der folgenden Formen dargestellt werden: als ein Attribut, als eine Parametervariable, als eine lokale Variable, als eine globale Variable.

Abhängigkeiten (2) Die Abhängigkeit wird mit einem gestrichelten Pfeil vom Client zum Supplier dar- gestellt. Um die Art einer Abhängigkeit darzustellen oder um ein Werkzeug bei der Code- generierung zu unterstützen, kann eine Abhängigkeitslinie mit Schlüsselwörtern versehen werden.

Beispiel Sale muss die Parameter einer ProductDescription sehen und ist deshalb von dieser abhängig. … ProductDescription Sale … updatePriceFor( ProductDescription ) … … SalesLineItem 1..* lineItems

Die Komposition (1) Komposition (engl. composition oder auch composite aggregation) ist eine Teil- Ganzes-Aggregation („enthält“). Eine Kompositionsbeziehung impliziert, dass eine Instanz des Teils zu einem gegeben Zeitpunkt zu genau einer Kompositum- instanz gehört, das Teil immer zu einem Kompositum gehören muss, und das Kompositum für die Erstellung und Löschung seiner Teile verantwortlich ist – entweder, indem es diese Teile selbst erstellt und löscht, oder indem es zu diesem Zweck mit anderen Objekten zusammenarbeitet. Die UML-Notation für eine Komposition besteht aus einer gefüllten Raute an dem Ende einer Assoziationslinie, an dem das Kompositum liegt.

Die Komposition (2) Komposition bedeutet: Eine Teil-Instanz (Square) kann gleichzeitig nur Teil eines Kompositums (Board) sein. Das Kompositum ist allein für die Verwaltung seiner Teile, insbesondere für deren Erstellung und Zerstörung, verantwortlich. 1 Finger Hand 0..5 Komposition 1 1 Square Board 40 SalesLineItem Sale 1..*

Assoziationsklassen Mit einer Assoziationsklasse kann man eine Assoziation selbst als Klasse behan- deln und mit Attributen, Operationen und anderen Features modellieren. Wenn beispielsweise eine „Company“ viele „Person“-Objekte beschäftigt und diese Beziehung mit einer „Employs“-Assoziation modelliert wird, kann man die Assoziation als „Employment“-Klasse mit Attributen wie beispielweise „startDate“ (Eintrittsdatum) versehen. In UML wird dies als eine gestrichelte Linie von der Assoziation zur Assoziations- klasse dargestellt. Employs * * Employment salary startDate Company Person Eine Person kann bei mehreren Unternehmen angestellt sein. Assoziationsklassen sind vor allem dann nützlich, wenn die Assoziation eine Multi-plizität von n zu n hat (*….*).

Zusammenfassung Das UML-Domänenmodell wird dazu verwendet, eine Anwendungsdomäne im- plementierungsunabhängig zu modellieren. Im UML-Klassendiagramm gibt man dann die Klassen der objektorientierten Im- plementierung an. In Klassendiagrammen gibt es eine wohldefinierte Verwendung verschiedener Arten von Pfeilen für Klassenhierarchien (Unterklassen), Interfaces, Abhängigkeiten und Kompositionen.