Abbildung von UML nach Java Klassendiagramm - Business ...

Abbildung von UML nach Java 

Beispiele 

Klassendiagramm 

Assoziationen 

Generalisierung (Mehrfachvererbung) 

Kollaboration (Patterns) 

Zustandsdiagramm 

Interaktionsdiagramm 

Zusammenfassung und Ausblick 

© 2005 Business Informatics Group, TU Wien 


Assoziationen - Optimierungen im Detailentwurf 

Abbildung von Assoziationen / Aggregationen 

auf OO Programmiersprache bzw. DB 

Realisierung von Beziehungen in Interaktionsdiagrammen 

festlegen (global, lokal, etc.) und 

entsprechende Änderung des Klassenmodells 

vornehmen 

Navigation - Zugriffspfade über redundante 

Assoziationen optimieren 

abgeleitete Attribute und Assoziationen 

materialisieren 

Sichtbarkeiten festlegen 


1 

2


Assoziationen - Bidirektionale 1:1-Assoziation 

-attrX: AXType 

+opX () 

X 

rX 


X 


-rY: Y 

+opX () 

+X (Y y) 

+assoc (Y y) 

+assoc (): Y {query} 

//Assoziationsverwaltung 

// Assoziationsverwaltung 

private Y rY; rY 

public X(Y y) { 

assoc(y); 

... 

} 

public void assoc(Y y) { 

if (rY ( rY != y) { 

rY = y; 

y.assoc(this); 

} 

} 

public Y assoc() { 

return rY; rY 

} 

© 2005 } Business Informatics Group, TU Wien 

assoc 

rY 

1 1 


Assoziationen - Bidirektionale 1:1-Assoziation 

class X { 

private AXType attrX; attrX 

public void opX() opX() 

{...} 

-attrY: AYType 

+opY () 

Y 

rX 

assoc 

rY 

-attrY: AYTyp 

1 1 

-rX: X 

Y 

+opY () 

+Y (X x) 

+Y () 

+assoc (X x) 

+assoc (): X {query} 

class Y { 

private AYType attrY; attrY 

public void opY() opY() 

{...} 

//Assoziationsverwaltung 

// Assoziationsverwaltung 

private X rX; rX 

public Y(X x) { 

assoc(x); 

... 

} 

public void assoc(X x) { 

if (rX ( rX != x) { 

rX = x; 

x.assoc(this); 

} 

} 

public X assoc() { 

return rX; rX 

} 

public Y() { ... } 

} 

3 

4


Assoziationen - Unidirektionale ?:1-Assoziation 

X 


-rY: Y 

+opX () 

+X (Y y) 

+assoc (Y y) 

+assoc (): Y {query} 

rX 

class X { 

private Y rY; rY 

public X(Y y) { 

assoc(y); 

... 

} 


rY = y; 

} 

public Y assoc() { 

return rY; rY 

} 

} 


X 


-rY: Y 

+opX () 

+X (Y y) 

+assoc (Y y) 

+assoc (): Y 

{query} 


assoc 

rY 

(egal egal) 1 


+opY () 

Y 

class Y { 

// keine Änderungen 

// notwendig 

} 

Viel einfacher – 

bidirektionale Assoziationen 

möglichst vermeiden! 


Assoziationen - Navigation und Kopplung (1/2) 

rX 

assoc 

1 1 

Y 


-rX: X 

+opY () 

+Y (X x) 

+Y () 

+assoc (X x) 

+assoc (): X 

{query} 

Zugriff eines Klienten von X auf Eigenschaften des 

assoziierten Y-Objekts: 

void klientenMethode (X einX) { 

... 

einX.assoc().opY(); // Kopplung an Y! 

} 

Koppelt den Klienten nicht nur an X, sondern auch an Y! 

rY 

5 

6


Assoziationen - Navigation und Kopplung (2/2) 

»Demeter-Gesetz«: 

Assoziation nicht öffentlich sichtbar machen 

Notwendige Y-Operation durch X anbieten 

X 


-rY: Y 

+opX () 

+X (Y y) 

-assoc (Y y) 

+opY () 

rX 

void klientenMethode (X einX) { 

... 

einX.opY(); 

} 



assoc 

rY 

1 1 

rY.opY() rY.opY() 


Assoziationen - Bidirektionale 1:n-Assoziation (1/2) 

-rY[0..k]:Y 

rY[0..k]:Y 

-nY:int nY:int 

X 

rX 

1 

assoc 

rY 

0..k 

Y 

«refine» «refine» 

X 

+assoc(y:Y assoc(y:Y) 

+rmAssoc(y:Y 

rmAssoc(y:Y) 

+nAssoc():int{query 

nAssoc():int{query} 

+assoc(i:int):Y{query 

assoc(i:int):Y{query} 

+findAssoc(y:Y):int{query 

findAssoc(y:Y):int{query} 

Obergrenze 

k ist fest 

Y 


-rX: X 

+opY () 

+Y (X x) 

+Y () 

-assoc (X x) 

+opX () 

-rX:X rX:X 

Y 

+Y(x:X) 

+assoc(x:X 

assoc(x:X) 

+assoc():X{query 

assoc():X{query} 

7 

8


Assoziationen - Bidirektionale 1:n-Assoziation (2/2) 

class X { 

./. 

private Y[] rY = new Y[k]; Y[ ]; 

private int nY = 0; 


public int nAssoc () { 

if (findAssoc(y)= 0) { 

for (i=0; i


Assoziationen - Iteration (2/3) 

-rY[0..k]:Y 

rY[0..k]:Y 

-nY:int nY:int 

rX 

assoc 

rY 

X Y 

1 

0..k 


X 

+assoc(y:Y assoc(y:Y) 

+rmAssoc(y:Y 

rmAssoc(y:Y) 



+assoc():Enumeration{query 

assoc():Enumeration{query} 

+findAssoc(y:Y):int{query 

findAssoc(y:Y):int{query} 


base 

1 

Enumeration 


«instantiate» 


Assoziationen - Iteration (3/3) 

-i:int i:int 

* 

-rX:X rX:X 

Y 

+Y(x:X) 

+assoc(x:X 

assoc(x:X) 

+assoc():X{query 

assoc():X{query} 

«use» 

Iter 

+Iter(x:X Iter(x:X) 

+hasMoreElements():boolean{query 

hasMoreElements():boolean{query} 

+nextElement():Object 

nextElement():Object 

class X { 

private Y[] rY = new Y[k]; Y[ ]; // k fest 

private int nY = 0; 

public void assoc(Y y) { ... } 

public void rmAssoc (Y y) { ... } 

public int nAssoc () { ... } 

public int findAssoc(Y y) { ... } 

private class Iter implements Enumeration { 

private X base; 

private int i = 0; 

public Iter (X x) { base = x; } 

public boolean hasMoreElements() {return i


Assoziationsklasse (1/3) 

a11 

x1 

x2 

value = 3 

X 

rX 

rY 

Y 

* 

* 

a12 

value = 1 



a13 

value = 4 



Assoc 

value:int 

a22 

value = 1 

a23 

value = 5 

X 

rX 

* 

rY 

* 

Y 

«refine» Assoc 

«refine» 

-rY:Hashtable 

rY:Hashtable 

X 

+assoc(y:Y assoc(y:Y, , a:Assoc) a:Assoc 

+rmAssoc(y:Y 

rmAssoc(y:Y) 





+findAssoc(y:Y):Assoc{query 

findAssoc(y:Y):Assoc{query} 

Schlüssel:Y 

Wert:A 

-rX:Hashtable 

rX:Hashtable 

Y 

y1 

y2 

y3 

13 

+assoc(x:X 

assoc(x:X, , a:Assoc) a:Assoc 

+rmAssoc(x:X 

rmAssoc(x:X) 





+findAssoc(x:X):Assoc{query 

findAssoc(x:X):Assoc{query} 

14



class X { 

private Hashtable rY = new Hashtable(); 

public void assoc(Y y, Assoc a) { 

if (findAssoc(y) == null) { 

rY.put(y, a); 

y.assoc(this, a); // »Gegen-Link« »Gegen Link« mit identem 

} // Assoziationsobjekt 

} // versehen 

public void rmAssoc (Y y){ 

if (rY.remove(y) != null) 

y.rmAssoc(this); 

} 

public int nAssoc () { return rY.size(); } 

public Assoc findAssoc(Y y) { return (Assoc)rY.get(y); } 

public Enumeration assoc () { return rY.keys(); } 

} 



Komposition 

Komposition bei Sprachen mit Wertsemantik (z.B. 

C++): 

X 

1 

rY 

k 

Y 

Wenn nur Referenzsemantik zur Verfügung steht 

(Java): 

Wertsemantik simulieren: 

Y stellt Methode clone() zur Verfügung, die Objektkopien 

erzeugt 

X ruft in den Assoziationsverwaltungsmethoden beim Zugriff 

auf die Y-Partner clone() auf 

Y-Partner »abschotten« und alle Y-Operationen direkt 

durch X anbieten (vgl. »Demeter-konforme« Assoziation) 


class X { 

Y rY[k]; // »eingelagerte« Y-Objekte 

Y Objekte 

... 

}; 

15 

16


Generalisierung – Mehrfachvererbung (1/3) 


B1 B2 

Bei Simulation von Mehrfachvererbung zu 

beachten: 

Spezifikationsvererbung (»Muss«): 

A erbt die nichtprivaten Schnittstellen von B1 und B2 

Implementationsvererbung (»Soll«): 

A erbt die Implementation von B1 und B2 

(Code-Wiederverwendung) 



A 

Vorgangsweise bei n-fach-Vererbung: 

1x: »echte« Vererbung von Basisklasse B1 

(n-1)x: simulierte Vererbung durch 

Interface-Realisierung (Spezifikationsvererbung) 

für die Basisklassen B2 ... Bn sind entsprechende 

Interfaces vorzusehen 

(im Beispiel B2) 

Komposition (»Implementationsvererbung«) 

der »ehemaligen« Basisklassen B2 ... Bn 

(im Beispiel B2I) 


17 

18



-attrB2 attrB2 


B2 

+opB2() 

«refine» 

B21 

+opB2() 

«interface interface» 

B2 

+opB2() 

«refine» 


1 

b2 

-attrA attrA 

+opA opA() () 

-attrA attrA 

A 


A 

+opA opA() () 

+opB2() 

0..1 


Kollaboration - Beispiel „Observer Pattern“ 

Observer: 


b2.opB2(); 


B1 

+opB1() 


B1 

+opB1() 

Ziel ist das automatische Benachrichtigen von abhängigen 

Objekten bei Zustandsänderungen eines Objekts 

ermöglicht Konsistenzsicherung bei lose gekoppelten 

Objekten 

wird hauptsächlich in graphischen Benutzeroberflächen 

angewendet 

Modellierung in UML mittels Kollaboration 

Definition: Anwendung: 

Observer 

subject * observer * 

subject 

kalender 

Aktualisierung: 

Observer 

19 

observer 

Kalender Kalenderansicht 

20


Kollaboration – Framework für das Observer Pattern 

Subject 

addObserver (Observer) 

removeObserver (Observer) 

notifyObservers() 

notifyObservers() 

Kalender 

kalenderState 

getState () 

setState () 


observers* 

observers 

for all o in observers 

o->update(this 

>update(this); ); 

subject 


return kalenderState; 

kalenderState 

// change state… state 

notifyObservers(); 

notifyObservers(); 

Observer 

update (Subject ( Subject) 

Kalenderansicht 

ansichtState 

update (Subject ( Subject) 

ansichtState=subject->getState 

ansichtState=subject >getState() () 


Kollaboration – Variante des Observer Pattern im Java API 

package java.util; 

java.util 

interface EventListener {} // A tagging interface that all event 

// listener interfaces must extend. 

class EventObject { 

protected Object source; source; 

// The object on which the Event 

// initially occurred 

} 

package java.beans; 

java.beans 

interface PropertyChangeListener extends EventListener { 

void propertyChange(PropertyChangeEvent evt); evt); 

// This method gets called when a bound property is changed. changed 

} 

class PropertyChangeEvent extends EventObject { 

private String propertyName; propertyName; 

// The property that has changed 

private Object oldValue, 

oldValue, 

newValue; newValue; 

// Old and new values of the prop. 

} 

21 

22


Beispiele 


Assoziationen 







Zustandsdiagramm (1/6) 

Varianten 

Transitionen 

Operation codiert Trigger sowie Aktion der 

Transitionen (d.h., Zustandsdiagramm spezifiziert 

Vor- und Nachbedingungen sowie 

zustandsspezifisches Verhalten) 

Zustände – mehrere Varianten 

Explizites Zustandsattribut beschreibt Zustand, 

oder 

Invarianten disjunkter Zustände als Prädikate, oder 

State-Pattern: Jedem Zustand ein eigenes Objekt 

zugeordnet 

Folien aus Bernhard Rumpe: Agile Modellierung mit UML – 

Codegenerierung, Testfälle, Refactoring. Springer-Verlag, 

2005 


23 

24


Disjunkte Invarianten für Zustände 

[vorb1] 

stimulus() / 

aktion1 

QuellzustandA 

[invarianteA] 


[vorb2] 

stimulus() / 

aktion2 

QuellzustandB 

[invarianteB] 

Zielzustand1 Zielzustand2 Zielzustand3 

public … stimulus() { 

if (invarianteA) { 

if (vorb1) { 

aktion1; 

} else if (vorb2) { 

aktion2; 

} else { 

// Fehlerbehandlung 

} 

else if (invarianteB) { 

… 

}} 

[vorb3] 

stimulus() / 

aktion3 

Zustandsmaschine 

Java 

Zustandsinvarianten und 

Vorbedingungen werden zur 

Unterscheidung der Transitionen 

genutzt 

Nachteil: Code „invarianteA“ 

wird mehrfach eingesetzt (wenn 

unterschiedliche Stimuli) 


Auslagerung Zustandsinvarianten in eigene Prädikate 

QuellzustandA 

[invarianteA] 

[vorb1] 

stimulus() / 

aktion1 


QuellzustandB 

[invarianteB] 

Zielzustand1 Zielzustand2 

public boolean invQuellzustandA() { 

return invarianteA; 

} 

public boolean invQuellzustandB() { 

return invarianteB; 

} 


if (invQuellzustandA()) { 

… 

} 

[vorb2] 

stimulus() / 

aktion2 

jeder Zustand wird zu 

einem Prädikat, das 

die Zustandsinvariante 

evaluiert 

25 



Vorteil: „invarianteA“ nur einmal 

generiert 

Nachteil: „invarianteA“ kann komplex 

sein und zeitaufwendig zu berechnen 

Besser: Zustandsattribut speichert 

aktuellen Zustand 

26


Einführung eines Zustandsattributs 

[vorb1] 

stimulus() / 

aktion1 

QuellzustandA 

[invarianteA] 


[vorb2] 

stimulus() / 

aktion2 

QuellzustandB 

[invarianteB] 


private int status; 

final static int QUELLZUSTAND_A=1; 

final static int QUELLZUSTAND_B=2; 

final static int ZIELZUSTAND1=3; … 

der Diagrammzustand wird als 

Aufzählung codiert 

Vorteil: Effizient 

Nachteile: evtl. redundante Speicherung, 

Konsistenz nicht gesichert: 

(status==QUELLZUSTAND_A) impliziert 

invarianteA 


Nutzung der Invarianten für Tests 

Ausgangsdiagramm wie 

auf vorheriger Folie 

[vorb1] 

stimulus() / 

aktion1 

QuellzustandA 

[invarianteA] 

[vorb2] 

stimulus() / 

aktion2 

QuellzustandB 

[invarianteB] 




[vorb3] 

stimulus() / 

aktion3 

Zustandsinvarianten und 

manche Vorbedingungen können 

als Zusicherungen zu 

Testzwecken eingesetzt werden, 

wenn angenommen wird, dass 

das Diagramm vollständig ist 

[vorb3] 

stimulus() / 

aktion3 




switch (status) { 

case QUELLZUSTAND_A: 

if (vorb1) { 

aktion1; 

status=ZIELZUSTAND1; 

} else if (vorb2) { 

aktion2; 


} … 

break; 

case QUELLZUSTAND_B: 

… 

27 

}} 


private int status; 

final static int QUELLZUSTAND_A=1; 

final static int QUELLZUSTAND_B=2; 

final static int ZIELZUSTAND1=3; 

… 


switch (status) { 

case QUELLZUSTAND_A: 

assert invarianteA; 

if (vorb1) { 

aktion1; 


} else { 

assert vorb2; 

aktion2; 


} … 

break; 

case QUELLZUSTAND_B: 

}} 

… 

28


Entwurfsmuster: State (Gamma et.al. 1994) 

Ausgangsdiagramm wie 

auf vorheriger Folie 

[vorb1] 

stimulus() / 

aktion1 

QuellzustandA 

[invarianteA] 

[vorb2] 

stimulus() / 

aktion2 

QuellzustandB 

[invarianteB] 




[vorb3] 

stimulus() / 

aktion3 

Klasse state StateKlasse 

stimulus() 

setState(StateKlasse k) 

UML 

stimulus(Klasse k) 

QuellzustandA QuellzustandB 

stimulus(Klasse k) stimulus(Klasse k) 


class Klasse { 

QuellzustandA quellzustandA = … 

Zielzustand1 zielzustand1 = … 


state.stimulus(this); 

} 

Vorteil: das State-Entwurfsmuster 

kann für zusätzliche Flexibilität verwendet werden 

Nachteil: Oberhead durch zusätzliche Objekte pro Zustand 


Beispiele 


Assoziationen 







} 

class QuellzustandA { 

public … stimulus(Klasse k) { 

assert invarianteA; 

if (vorb1) { 

aktion1´; 

k.setState(k.zielzustand1); 

} else 

… 

}} 

29 

30

Interaktionsdiagramm (1/3) 

Verwendungszwecke 

Interaktionsdiagramm zeigt mögliche Abläufe 

im System 

Verwendet zur Spezifikation von Testfällen 

Ableitung von Code für 

Testtreiber 

Ablaufvalidierung 

Folien aus Bernhard Rumpe: Agile Modellierung mit UML – 

Codegenerierung, Testfälle, Refactoring. Springer-Verlag, 

2005 



Interaktionsdiagramm definiert Testtreiber 

Eine Lebenslinie im 

Interaktionsdiagramm stellt 

den Testtreiber dar (oft ein 

Klientenobjekt) 

„fremder“ Methodenaufruf im 

Diagramm wird bei 

Codegenerierung für den 

Testtreiber ignoriert 

class Class { … 

public void runTestDiagramm(A a, B b, Type2 args2) { 

Type value = a.m1(); 

a.m2(args2); 

b.m3(); 

} 

} 


t:Class a:A b:B 

m1() 

m1:value 

m2(args2) 

m3() 

otherMethod() 

31 

UML 


32


Interaktionsdiagramm zur Validierung 

Interaktionsdiagramm beschreibt erlaubte/verbotene Abläufe 

Zur Beobachtung des Verhaltens ist eine Instrumentierung 

des Codes notwendig (Logging) - z.B. per “Adapter”-Muster 

Überprüfung des Logging-Protokolls entsprechend dem Diagr. 

class Ainstrumented extends A { … 


public Type method () { 

// Protokolliere Methodenaufruf (Objekt, Methode, Argumente) 

IDlog.call(this, "method", new Object[]); 

Type result; 

try { // Eigentlicher Aufruf 

result = super.method(); 

catch (Exception ex) { 

// Protokolliere Exception 

IDlog.exceptionReturn(this, "method", ex); 

throw ex; 

} 

// Protokolliere Return + Ergebnis 

IDlog.normalResult(this, "method", result); 

return result; } 



Beispiele 


Assoziationen 







33 

34



viele unterschiedliche Optionen 

Auswahl abhängig von benutzten 

Programmierrichtlinien, Frameworks, etc. 

Automatisierte Codegenerierung 

mit UML-Werkzeugen 

Problem der Anpassung des generierten Codes 

Model Engineering / Model Driven Architecture 

UML-Profile für spezielle Zielplattformen, z.B. 

Struts/J2EE, etc. 

Code-Generatoren anpassbar und/oder selber zu 

entwickeln 

Ziel: vollständige Codegenerierung 


35

Abbildung von UML nach Java Klassendiagramm - Business ...

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?