Dissertation

1
Klassendiagramm
3.6.3 Relationen ............................................................................................... 1
Assoziationen ........................................................................................................................................ 2
Rolle .................................................................................................................................................. 2
Sichtbarkeit der Assoziation .............................................................................................................. 4
Kardinalität ........................................................................................................................................ 4
Navigation ......................................................................................................................................... 5
Qualifizierte Assoziationen ............................................................................................................... 6
Aggregation ....................................................................................................................................... 6
Komposition ...................................................................................................................................... 7
Abhängigkeit ......................................................................................................................................... 8
Notation ............................................................................................................................................. 8
Verfeinerung ...................................................................................................................................... 8
Generalisierung...................................................................................................................................... 9
Definition........................................................................................................................................... 9
Diskriminator ..................................................................................................................................... 9
Notation ............................................................................................................................................. 9
3.6.4 Klassenarten ......................................................................................... 10
Metaklasse ........................................................................................................................................... 10
Abstrakte Klasse .................................................................................................................................. 11
Parametrisierbare Klasse ..................................................................................................................... 11
Schnittstelle ......................................................................................................................................... 12
Vorkommen? ................................................................................................................................... 12
Was ist ein Interface? ...................................................................................................................... 12
Notation ........................................................................................................................................... 12
Was zeigt ein Interface? .................................................................................................................. 14
Schnittstellen in Java ........................................................................................................................... 14
Definition einer Schnittstelle ........................................................................................................... 15
Implementieren einer Schnittstelle .................................................................................................. 16
Stereotypen .......................................................................................................................................... 17
3.6.5 Praktische Hinweise ............................................................................. 18
3.6.3 Relationen
Das Klassendiagramm besitzt außer Klassen auch Relationen.
Arten der Beziehungen:
 Assoziation ( ____ ): Sie repräsentiert strukturelle Beziehungen unter
Objekten.
 Abhängigkeit (
) : ist eine benutzt-Relation. Sie zeigt an, dass
eine Änderung der Spezifikation in der einen Klasse (Event), eine
Änderung in der anderen (Window) nach sich zieht.
Window
open()
close()
move()
display()
handleEvent()
 Generalisierung:
579861275-v5
Event
2
OOD
sie verbindet die allgemeinere Klasse mit der spezielleren.
 Realisierung:
sie verbindet eine Klasse mit einer Schnittstelle.
Assoziationen
Assoziationen sind Beziehungen zwischen verschiedenen Objekten einer
oder mehrerer Klassen. Sie können Rollennamen haben, die beschreiben,
welche Rolle jedes beteiligte Objekt spielt. Des weiteren können sie
Multiplizitäts-angaben haben, die besagen, wie viele Objekte auf einer Seite
mit wie vielen Objekten auf der anderen Seite verbunden sind.
Relationen werden mit Assoziationen hergestellt. Eine Assoziation
beschreibt eine Gruppe von Verknüpfungen mit einer gemeinsamen Struktur
und Semantik. Eine Person Arbeitet-für eine Firma ist ein Beispiel für eine
Assoziation. Alle Verknüpfungen einer Assoziation verbinden Objekte der
gleichen Klassen. Assoziationen haben in einer Problembeschreibung oft die
Form von Verben. Assoziationen sind inhärent bidirektional.
Binäre Assoziationen verbinden zwei Klassensymbole mittels einer Linie.
Die Linie kann eine Reihe von Zusätzen enthalten, um ihre Eigenschaften zu
definieren. Eine binäre Assoziation ist ein Beziehung zwischen genau zwei
Klassen, einschließlich der reflexiven Assoziation, wo eine Klasse in
Beziehung zu sich selbst steht.
Eine Assoziation ist also eine strukturelle Beziehung, die spezifiziert, dass
Objekte miteinander verbunden sind.
Bibliothek
1..*
1..*
Buch
Jedes Buch gehört zu einer Bibliothek. Zu jedem Buch können Sie die
Bibliothek finden und von einer gegebenen Bibliothek können Sie alle ihre
Bücher finden.
Es gibt Zusätze für Assoziationen:
 einen Namen (besitzt),
 eine Rolle an jedem Ende einer Assoziation (z.B. Zeile),
 Sichtbarkeit,
 eine Kardinalitätsangabe an jedem Ende einer Assoziation (z.B.
0..1),
 Navigation,
 Qualifizierung und
 eine Aggregation.
Rolle
3
Klassendiagramm
Jede Assoziation hat zwei Rollen, jede Rolle ist eine Richtung der
Assoziation. Eine Rolle kann explizit benannt werden. Wenn kein Name für
eine Rolle angegeben ist, so ist der Rollenname die Zielklasse.
Wenn eine Klasse an einer Assoziation teilnimmt, so spielt sie in der
betreffenden Beziehung eine Rolle. Eine Rolle ist einfach die Seite, die die
Klasse am einen Ende der Assoziation am anderen Ende der Assoziation
zukehrt.
Assoziation
Person
Unternehmen
n:IArbeitnehmer
g:IArbeitgeber
Rollennamen
Abb.: Rolle
Eine Klasse kann viele Schnittstellen realisieren. Ein Objekt einer Klasse
muss diese Schnittstellen unterstützen. Ein Objekt kann in einem gegebenen
Kontext nun nur eine oder einige jeweils relevanten Schnittstellen offen legen.
In diesem Fall repräsentiert jede Schnittstelle eine Rolle, die das Objekt spielt.
Eine Rolle bezeichnet ein Verhalten einer Einheit, die an einem bestimmten
Zusammenhang beteiligt ist.
Beispiel:
<<interface>>
Arbeitnehmer
getKarriere()
getLohn()
getPraemie()
Person
Unternehm
en
n:IArbeitnehmer
Ein weiteres Beispiel ist folgendes:
Mitarbeiter:IArbeitnehmer
Person
1..*
1
Assoziation
Vorgesetzter:IManger
579861275-v5
4
OOD
Schnittstellenspezifikation
Sichtbarkeit der Assoziation
BenutzerGruppe 0.. *
0..* Benutzer
+user
1
+owner
1..*
-key
Paßwort
Ausgehend von einem Benutzergruppen-Objekt können wir zu einem
Benutzer-Objekt navigieren, wir können aber nicht das Passwort des Benutzers
sehen. Durch Sichtbarkeitskriterien am Ende einer Assoziation, die wir dem
Rollennamen voranstellen, können wir dies angeben. Wenn nichts angegeben
wurde, ist die Sichtbarkeit der Rolle public. Private Sichtbarkeit zeigt an, dass
auf Objekte von außerhalb dieser Assoziation nicht zugegriffen werden kann.
Lit.: UML 1.4, S. 3-75
Booch, Grady; Rumbaugh, James; Jacobson, Ivar: The Unified Modeling Language Use Guide. Ready: Addison Wesley Longman, Inc., 1999, S. 181 ff.
Kardinalität
Jede Rolle hat eine Kardinalität (multiplicity), die angibt wie viele
Objekte an der gegebenen Beziehung partizipieren können. Allgemein
gesprochen, die Multiplizität gibt die untere und obere Grenzen für die
Teilnahme des Objekts an der Beziehung an. Der Stern (*) repräsentiert den
Bereich von 0 bis unendlich.
Die Multiplizität kann aus einer Untermenge nicht negativer Zahlen
bestehen, einer einzigen Zahl, z.B. 11 für 11 Spieler einer Mannschaft, oder aus
einer Menge unzusammenhängender Intervalle. So ist die Zahl der Türen eines
PKWs 2, 4 oder 5.
Die Kardinalitäten werden bei UML wie folgt angegeben:
1 B
A
Ein A ist immer mit einem B assoziiert.
A
1..* B
Ein A ist immer mit einem oder mehreren Bs assoziiert
A
0..1
B
5
Klassendiagramm
Ein A ist mit einem oder keinem B assoziiert.
0..*
A
B
Ein A ist mit keinem, einem oder mehreren Bs assoziiert.
Navigation
Im Bibliotheksbeispiel ist es möglich von der Bibliothek zu ihren Büchern
zu gelangen und von einem Buch zu den Bibliotheken, in denen die Bücher
stehen. Wenn nichts besonderes spezifiziert ist, ist eine Assoziation
bidirektional. Es gibt jedoch Umstände, die es wünschen lassen, nur in eine
Richtung zu navigieren.
Beispiel:
1
1.. *
Benutzer
Passwort
Werden die Aufgaben eines Betriebssystems modelliert, so ergibt sich
diese Assoziation zwischen Benutzer- und Passwort-Objekt.
In der Abbildung ist eine Assoziation dargestellt, die nur in eine Richtung
navigierbar ist.
Dargestellt wird die Navigation durch eine offene Pfeilspitze. Die
Pfeilrichtung gibt die zugelassene Navigationsrichtung an.
Eigentlich sind alle Assoziationen unidirektional, d.h. gerichtete
Assoziationen. Bidirektionale Assoziationen sind genaugenommen zwei
entgegengesetzt gerichtete Assoziationen.
0..1
A
2..4
B
2..4
A
0..1
B
Abb.: Bidirektionale Assoziationen = zwei gerichtete Assoziationen
579861275-v5
6
OOD
Qualifizierte Assoziationen
Verzeichnis
1
Verzeichnis
Dateiname
1..*
1
Datei
1
Datei
Qualifikation verbessert die semantische Genauigkeit und macht
Navigationspfade leicht nachvollziehbar.
Eine qualifizierte Assoziation verbindet zwei Klassen und eine
Qualifikationsangabe. Die Qualifikationsangabe ist ein besonderes Attribut, das
die effektive Multipliziät einer Assoziation herabsetzt. Qualifiziert werden
können 1:m und m:m Assoziationen. Die Qualifikationsangabe unterscheidet
die Menge von Objekten auf der m-Seite einer Assoziation.
Aggregation
Wir haben gesehen, dass eine Assoziation eine strukturelle Beziehung ist,
die spezifiziert, dass Objekte einer Klasse mit Objekten einer andere Klasse
verbunden sind. Es bedeutet auch, dass von einem Objekt zum anderen und
umgekehrt navigiert werden kann. Eine Assoziation zwischen zwei Klassen
repräsentiert eine strukturelle Beziehung zwischen Gleichen, das soll heißen,
beide Klassen sind konzeptionell auf der gleichen Ebene. Manchmal will man
jedoch eine Teile-Ganze-Beziehung modellieren, wo eine Klasse das Ganze
und andere Teile davon repräsentieren.
Eine spezielle Art der Assoziation ist die Aggregation. Aggregation
bezeichnet die "Teil-Ganze-" oder "ist-Teil-von"-Relation, in der Objekte - die
die Komponenten einer Sache repräsentieren - mit einem Objekt assoziiert
sind, das die Komponentengruppe repräsentiert.
Eigenschaft
Die wichtigste Eigenschaft einer Aggregation ist die Transitivität. Eine
Aggregation
ist
darüber
hinaus
antisymmetrisch.
In
einer
Aggregationsbeziehung zwischen zwei Klassen muss genau ein Ende der
Beziehung das Aggregat sein und das andere für die Einzelteile stehen.
7
Klassendiagramm
Notation
Unternehmen
Das Ganze
1
Aggregation
0..*
Mitarbeiter
Teil
Die unausgefüllte Raute unterscheidet zwischen dem Ganzen und den
Teilen davon - mehr nicht. Sie ändert nicht die Bedeutung der Navigation über
die Assoziation, noch besagt sie etwas über die Lebenszeit des Ganzen oder
der Teile.
Komposition
In manchen Fällen beschreiben Aggregation Beziehungen, in denen die
Teile vom Ganzen abhängig sind. Das heißt, wenn das Aggregat, also das
Ganze, gelöscht wird, werden alle Einzelteile ebenfalls gelöscht. Wird ein Teil
gelöscht, bleibt das Aggregat erhalten. Diese strenge Form heißt Komposition.
Beispiel:
Window
Ganzes
1
Komposition
0...*
Frame
Teil
Abb.: Komposition
In einer Kompositions-Beziehung kann ein Objekt zu einer bestimmten
Zeit nur Bestandteil eines Ganzen sein. Zusätzlich ist in einer KompositionsBeziehung das Ganze für die Zustände der Teile verantwortlich. Das bedeutet,
es muss die Erzeugung und Zerstörung seiner Teile managen. Erzeugt man
etwa einen Frame in einem Window-System, so muss man ihn seinem
übergeordneten Window hinzufügen. Ebenso muss beim Zerstören des
Window, das Window-Objekt seine Frame-Teile zerstören.
579861275-v5
8
OOD
Abhängigkeit
Eine Abhängigkeit ist eine Beziehung zwischen zwei Modellelementen,
die zeigt, dass eine Änderung in dem einen - unabhängigen - Element eine
Änderung in dem anderen - abhängigen - Element nach sich ziehen kann.
Notation
Dargestellt wird eine Abhängigkeit durch einen gestrichelten Pfeil, wobei
der Pfeil vom abhängigen auf das unabhängige Element zeigt.
abhängig
Beispiel (1)
unabhängig
SchnittstelleA
<<use>>
Nutzer_1
SchnittstellenAnbieter
<<use>>
SchnittstelleB
Nutzer_2
Beispiel (2)
FilmAufnahme
name
abspielenAuf(c : Kanal)
start( )
stop( )
zurücksetzen( )
Kanal
Abb.: Abhängigkeiten
Die Beispiele sind im Wesentlichen Benutzt-Beziehungen.
Eine Abhängigkeit kann einen Namen haben. Dies ist jedoch selten der
Fall, außer in Modellen mit vielen Abhängigkeiten, auf die verwiesen oder
zwischen denen unterschieden werden soll. Verbreiteter ist die Verwendung
von Stereotypen ( z.B. <<use>>, <<refine>>) , um verschiedene Nuancen von
Abhängigkeiten zu unterscheiden.
Verfeinerung
9
Klassendiagramm
Verfeinerungsbeziehungen sind Beziehungen zwischen gleichartigen
Elementen unterschiedlichen Detaillierungsgrades. Verfeinerungsbeziehungen
bestehen z.B. zwischen zwei unterschiedlich granulierten Elementen.
Tarifierung_1
<<refine>>
Tarifierung_2
Performance optimiert,
Berechnung läuft jetzt
auf lokal replizierten
Daten.
Abb.: Verfeinerung
Generalisierung
Definition
Generalisierung ist die taxonomische Beziehung zwischen einem
allgemeinen und einem speziellen Element. Die Sicht vom allgemeineren zum
speziellen ist die Spezialisierung. Bei der Generalisierung bzw. Spezialisierung
werden Eigenschaften hierarchisch gegliedert. Die Eigenschaften der
Oberklasse werden an die entsprechenden Unterklassen weitergegeben, d.h.
vererbt. Eine Unterklasse verfügt daher über die in ihr spezifizierten
Eigenschaften sowie über die Eigenschaften ihrer Oberklasse(n).
Diskriminator
Die Unterscheidung in Ober- und Unterklassen erfolgt häufig aufgrund
eines Diskriminators. Der Diskriminator bezeichnet den für die hierarchische
Strukturierung
der
Eigenschafen
maßgeblichen
Aspekt.
Das
Unterscheidungsmerkmal ist eine Modellierungsentscheidung. Es ist hilfreich
den Diskriminator während des Modellierens explizit zu vergegenwärtigen und
ihn auch in die Modellbildung aufzunehmen, da die Wahl des Diskriminators
dann eine dokumentierte Entwurfsentscheidung ist.
Notation
Die Vererbungsbeziehung wird mit einem nicht ausgefülltem Pfeil
dargestellt, wobei der Pfeil von der Unterklasse zur Oberklasse zeigt.
579861275-v5
10
OOD
Oberklasse
Diskriminator_2
Diskriminantor_2
Unterklasse_1
Unterklasse_4
Diskriminator_1
Unterklasse_2
Unterklasse_3
Oberklasse
Diskriminator_2
Diskriminantor_2
c Unterklasse_1
Unterklasse_4
Diskrminator_1
Unterklasse_2
Unterklasse_3
Abb.: Generalisierung
3.6.4 Klassenarten
Metaklasse
Metaklassen sind Klassifizierungen, deren Instanzen Klassen sind. In
Smalltalk, wie auch in CLOS, sind auch Klassen nur Objekte, d.h. es können
auch an Klassen Nachrichten gesendet werden. In C++ und Java können
Klassen jedoch nicht wie Objekte behandelt werden.
Die Klasse für Klassenobjekte werden Metaklasse genannt und in UML
wie folgt gekennzeichnet:
<<metaclass>>
KundeClass
11
Klassendiagramm
Abstrakte Klasse
Von einer abstrakten Klasse werden niemals Objekte erzeugt. Sie bildet
die Basis für weitere Unterklassen, die Exemplare haben können.
Eine abstrakte Klasse ist immer ein Oberklasse. Eine abstrakte Klasse, die
keine Unterklasse hat ist sinnlos.
Parametrisierbare Klasse
Bei einer parametrisierbaren Klasse wird keine konkrete Klasse definiert,
sondern lediglich eine Schablone (engl. Template) zur Erzeugung von Klassen.
Parametrisierbare Klassen sind in streng typgebundenen Sprachen ein Mittel,
um wiederverwendbaren Code zu schreiben.
Beispiel: Warteschlange
Eine parametrisierte Klasse stellt eine Klassenfamilie dar, deren Struktur
und Verhalten unabhängig von ihrem formalen Klassenparametern definiert
sind. Die formalen Parameter müssen durch aktuelle ersetzt werden, um eine
konkrete Klasse in dieser Familie zu bilden. Eine konkrete Klasse ist eine
Klasse, die Instanzen haben kann. Eine instantiierte Klasse definiert eine neue
Klasse, die sich von allen anderen konkreten Klassen derselben Familie durch
den aktuellen Parameter unterscheidet.
Wie sieht dies nun in der Notation aus?
Warteschlange i : Element
Stereotyp
<<bind>> Patient
anfuegen( )
entnehmen( )
<
Wartezimmer
<<bind>> PKW
Klasse
Objekte
Stau
parametrisierbare Klasse
Das gestrichelte Rechteck enthält eine Parameterliste und darf nicht leer
sein. „i“ ist der formale Parameter und „Element“ der Implementierungstyp.
579861275-v5
12
OOD
Schnittstelle
Vorkommen?
Schnittstellen kommen in Klassen- und Komponentendiagrammen vor.
Was ist ein Interface?
Im UML werden Interfaces genutzt um Nahtstellen in einem System zu
modellieren. Ein Interface ist eine Sammlung von Operationen, um einen
Dienst einer Klasse oder einer Komponente zu spezifizieren. In großen
Systemen können Interface benutzt werden, um die Außenansicht eines
Package oder Subsystems zu zeigen.
Schnittstellen haben keine Implementierung, ihnen fehlen Attribute,
Zustände, Assoziationen, sie haben nur Operationen.
Eine Schnittstelle kann durch viele Klassen oder Komponenten realisiert
werden. Eine Klasse oder Komponente kann viele Schnittstellen realisieren
(Booch et al. 99, S. 170).
Notation
Ein Interface ist ein Klassifizierer und kann daher als Rechteck mit den
drei Unterteilungen gekennzeichnet werden. Es enthält das Stereotyp
<<interface>>. Jedes Interface muss einen Namen haben. Ein Namen ist ein
Textstring.
Beispiele
In der Praxis sind Schnittstellennamen kurze Substantive oder
substantivierte Begriffe aus dem Vokabular des modellierten Systems. Um
Schnittstellen von Klassen zu unterscheiden, kann man den Buchstaben I für
interface vor jeden Schnittstellennamen setzen.
Eine Liste der Operationen, die durch das Interface unterstützt werden,
können im Operationsteil untergebracht werden. Der Attribut-Teil kann
unterdrückt werden, da er immer leer ist (Vers. 1.4, S. 3-53).
Beispiel:
InputStream
{abstract}
Generalisierung
DataInputStream
<<interface>>
IDataInput
<<use>>
OrderReader
Realization Relationship
Klassendiagramm
13
Abb.: Interface und abstrakte Klasse (nach Fowler97, S. 87)
Eine kompaktere Notation ist die sog. Lollipop-Notation:
IDataInput
<<use>>
OrderReader
DataInputStream
Realization (einfache Form)
Abb.: Lollipop-Notation
Die Linie zwischen Interface und Klasse gibt an, dass die Klasse alle
Operationen des Interface-Typ liefert. Die gelieferten Operationen werden
nicht angezeigt. Wenn es für das Verständnis des jeweiligen Modells
notwendig ist, kann man die Schnittstelle als stereotypisierte Klasse darstellen.
Im entsprechenden Abschnitt des Klassensymbols werden dann die
Operationen angegeben. Von Operationen kann nur der Name angegeben
werden oder ihre ganze Signatur. Eine Klasse, die die Operationen des
Interfaces nutzt wird mit einer gestrichelten Linie mit offenem Pfeil gezeichnet.
Die Realisierungsbeziehung wird mit einem gestricheltem, nicht ausgefülltem
Dreieckspfeil dargestellt.
579861275-v5
14
OOD
<<use>>
SortierteStringListe
ISortierbar
String
isEqual(String) : Boolean
isGreater(String) : Boolean
length() : Integer
SortierteStringListe
<<use>>
<<interface>>
Sortierbar
isEqual(String) : Boolean
isGreater(String) : Boolean
String
isEqual(String) : Boolean
isGreater(String) : Boolean
length() : Integer
Realisierung ist von Abhängigkeits-, Generalisierungs- und
Assoziationsbeziehungen hinreichend verschieden, um sie als eigene
Beziehungsart zu behandeln. Semantisch ist die Realisierung so etwas wie eine
Kreuzung zwischen Abhängigkeit und Generalisierung und die Notation ist
eine Kombination der Notation für Abhängigkeit und Generalisierung.
Was zeigt ein Interface?
Zunächst einen Satz von Operationen, die einen Dienst spezifizieren. Ein
tieferer Blick zeigt uns die Signatur dieser Operationen mit ihren properties.
Für ein besseres Verständnis der Operationen können Vor- und
Nachbedingungen für jede Operation angegeben werden. Des weiteren kann
ein Zustandsdiagramm dem Interface zugeordnet werden, sowie ein
Kollaborationsdiagramm.
Schnittstellen in Java
Beim Entwickeln geht man über verschiedene Stufen der Abstraktion.
Zunächst einmal interessiert man sich dafür welche Klassen benötigt werden
und welche Klassen miteinander Beziehungen haben. Dann interessiert man
sich dafür welche Schnittstellen eine Klasse hat und schließlich kümmert man
sich um die Implementierung der Methode.
15
Klassendiagramm
Bei Java gibt es keine Mehrfachvererbung von Klassen. Die möglichen
Schwierigkeiten beim Umgang mit mehrfacher Vererbung und die Einsicht,
dass das Erben nichttrivialer Methoden aus mehr als einer Klasse in der Praxis
selten zu realisieren ist, haben die Designer veranlasst, dieses Feature nicht zu
implementieren. Andererseits sah man es als wünschenswert an, dass Klassen
eine oder mehrer Schnittstellendefinitionen erben können, und hat mit den
Interfaces ein Ersatzkonstrukt geschaffen, das dieses Feature bietet.
Definition einer Schnittstelle
Ein Interface ist eine besondere Form der Klasse, die ausschließlich
abstrakte Methode (Operationen) und Konstanten enthält. Anstelle des
Schlüsselwortes class wird ein Interface mit dem Bezeichner "interface"
deklariert. Neben den Operationen kann ein Interface auch Konstanten
enthalten.
Die Schnittstellendefinition besteht aus zwei Teilen:
 der Schnittstellendeklaration und
 dem Schnittstellenkörper.
Die Schnittstellendeklaration setzt sich aus drei Elementen zusammen:
 einem optionalen Zugriffsmodifikator "public",
 dem Schlüsselwort "interface" und dem Schnittstellennamen,
 optional dem Schlüsselwort "extends" und durch Kommatat
getrennte Schnittstellen, von denen abgeleitet wird.
public interface Schnittstellenname extends Schnittstelle1,
Schnittstelle2
{
Schnittstellenkörper
}
Mit public deklarierte Schnittstellen können - genauso wie Klassen mittels der import-Anweisung in anderen Paketen sichtbar gemacht werden. im
eigenen Paket sichtbar.
Ein einfaches Beispiel soll das Vorgehen zeigen:
«interface»
PunktSchnittstelle
In Java sieht dies nun wie folgt aus;
Abb.: Schnittstellen
579861275-v5
Punkt
16
OOD
Das Ergebnis eines Programmablaufes wäre: Die Koordinate des Punktes
ist: 3
Ein erweitertes Beispiel ist folgendes: Wir haben Personen und
Nachrichtenquellen wie Zeitung, Radio
und Fernseher. Für die
Nachrichtenquellen (Zeitung, Radio, Fernseher) definieren wir eine
Schnittstelle die INachrichtenQuelle heißen soll. Für die Klasse Person eine
Schnittstelle mit dem Namen InachrichtenEmpfänger: In UML ausgedrückt,
ergibt sich folgendes Diagramm:
«interface»
«interface»
INachrichtenQuelle
INachrichtenEmpfänger
+anmelden()
+sendeNachricht()
Person
Radio
Fernseher
Zeitung
Schauen wir uns als ersten die interface-Definitionen an:
// Datei: Nachrichten.java
interface INachrichtenQuelle
{
public void anmelden (INachrichtenEmpfaenger empf);
public void sendeNachricht (String nachricht);
}
interface INachrichtenEmpfaenger
{
public void empfangeNachricht (String nachricht);
}
In diesem Beispiel wurden Schnittstellen definiert, NachrichtenQuelle und
NachrichtenEmpfänger.
Implementieren einer Schnittstelle
Durch die Definition des Interfaces haben wir die gewünschte
Funktionalität noch nicht zur Verfügung gestellt, sondern lediglich
beschrieben. Um die Funktionalität zu realisieren, müssen die entsprechenden
Methoden in einer Klasse implementiert werden. Hierfür wird die classAnweisung um eine implements-Klausel erweitert, hinter der der Name des zu
implementierenden Interfaces angegeben wird.
Klassendiagramm
17
Aus dem obigen Beispiel wird im folgenden Beispiel die Schnittstelle
Nachrichtenempfänger implementiert:
// Datei: Person.java
class Person implements INachrichtenEmpfaenger
{
private String name;
private String vorname;
public Person (String name, String vorname)
{
this.name = name;
this.vorname = vorname;
}
// Implementierung der Methode empfangeNachricht() der Schnitt// stelle INachrichtenEmpfaenger
public void empfangeNachricht (String nachricht)
{
System.out.println ("an: " + name + ", " + vorname
+ ", " + nachricht);
}
}
Des weiteren müssen wir noch die Klassen Zeitung, Radio usw. und die
main() Funktion Programmieren.
Abb.: Schnittstellen: Java-Beispiel
Stereotypen
Die Idee wurde von Rebecca Wirfs-Brock geprägt. Das Konzept wurde
von Schöpfern der UML übernommen, obwohl es dann nicht mehr dasselbe
war.
Die ursprüngliche Idee war eine high-level Klassifizierung eines Objektes,
die einen Hinweis darauf gab von welcher Art das Objekt ist.
Oft ergibt sich bei OO-Design folgendes: Wir haben eine Klasse, die die
gesamte Arbeit einer mächtigen doIT-Methode verrichtet und die anderen
Klassen zu nichts anderem da sind, als Daten zu kapseln. Dies ist ein schlechtes
Design, weil es dazu führt, dass der controler sehr komplex und schwierig zu
handhaben ist.
Um diese Situation zu verbessern, überträgt man Verhalten vom Controler
auf die relativ dummen Datenobjekte, so dass sie intelligenter werden und mehr
Verantwortung bekommen.
579861275-v5
18
OOD
Das Wesen der Stereotypen ist, dass sie die Verantwortlichkeit einer
Klasse umreißen. UML hat die Idee genommen und verwendet sie als
allgemeinen Mechanismus für die Sprache selbst.
Stereotypen geben in der Praxis vor allem die möglichen
Verwendungszusammenhänge einer Klasse, einer Beziehung oder eines Paketes
an. Stereotypen klassifizieren die möglichen Verwendungen eines
Modellelements. Einer oder mehreren Klassen werden bestimmte gemeinsame
Eigenheiten zugeschrieben. Sie ermöglichen eine mentale und visuelle
Unterscheidung und geben Hinweise auf die Verwendung, auf den Bezug zur
vorhandenen Anwendungsarchitektur, z.B. interface oder utility. Stereotypen
sollen nicht frei und willkürlich von den einzelnen Entwickler erfunden und
vergeben werden, sondern projekt-, unternehmens- oder werkzeugbezogen
definiert sein.
Beispiele für Stereotypen sind: <<complete>>, <<incomplete>>,
<<signal>>, <<primitve>>, <<include>>, <<extend>>.
Stereotypen werden in doppelten Winkelklammern angegeben.
3.6.5 Praktische Hinweise
 Der erste Schritt beim Bau eines Modells sollt nicht darin bestehen,
Klassen, Assoziationen und Vererbung zu Papier zu bringen. Es
kommt vielmehr darauf an, das anstehende Problem zunächst
überhaupt zu verstehen. Der Inhalt eines Modells richtet sich
ausschließlich nach seiner Relevanz für die angestrebte Lösung.
 Bemühen sie sich, Ihr Modell einfach zu halten. Vermeiden Sie
unnötige Komplikationen.
 Wählen sie Namen sorgfältig aus. Namen sind wichtig. Sie können
eine Fülle von Konnotationen (z.B. Blondinen) in sich bergen. Namen
sollten aussagekräftig, knapp und eindeutig sein. Sie sollten nicht einen
einzelnen Aspekt einer Klasse in den Vordergrund stellen. Die Wahl
guter Namen ist einer der wichtigsten Aspekte der Modellierung.
 Vergeben Sie Zeiger und andere Verweise auf Objekte nicht als
Attribute in den Objekten. Modellieren Sie sie statt dessen als
Assoziationen. Dies ist klarer und erfasst die eigentliche Absicht
besser als ein implementierungsnaher Ansatz.
 Versuchen Sie, allgemeine ternäre und n-äre Assoziationen zu
vermeiden. Die meisten dieser Assoziationen können in binäre
Assoziationen aufgelöst werden, möglicherweise unter Zuhilfenahme
von Qualifikationsangaben und Verknüpfungsattributen.
 Versuchen Sie nicht, alle Multiplizitätsfragen schon in einem sehr
frühen Stadium der Softwareentwicklung perfekt zu lösen.
 Bauen Sie Verknüpfungsattribute nicht in eine Klasse ein.
 Verwenden sie, wenn möglich, qualifizierte Assoziationen.
 Versuchen Sie, tiefverschachtelte Generalisierungen zu vermeiden.
Klassendiagramm
19
 Prüfen sie 1:1-Assoziationen. Oft ist eine "0- oder 1-" - Multiplizität
besser geeignet, weil das Objekt an einem der beiden Enden optional
ist. In anderen Fällen ist eine m-Multplizität erforderlich.
 Seien Sie nicht überrascht, wenn Sie Ihr Modell überarbeiten müssen.
Modelle erfordern häufig mehrere Durchgänge, um Namen zu klären.,
Fehler zu beheben, Details hinzuzufügen und strukturelle
Einschränkungen korrekt zu erfassen.
 Lassen Sie Ihr Modell möglichst von anderen Leuten überprüfen.
Modelle sind häufig der entscheidende Motivationsfaktor, andere in
ein Projekt einzubinden.
 Sie sollten Modelle immer dokumentieren. Das Diagramm spezifiziert
die Struktur des Modells, ohne die Überlegungen zu beschreiben, die
dahinterstehen. Der erklärende Text führt den Leser durch das Modell
und erklärt die tieferen Gründe, warum das Modell so und nicht anders
strukturiert wurde. Der erklärend Text verdeutlicht die Bedeutung von
Namen im Modell und sollte den Grund für die Existenz jeder Klasse
und jeder Relation vermitteln.
 Die Notation stellt eine Idealisierung dar. Nicht alle Konstrukte sind
für jedes Problem erforderlich. Viele Konstrukte sind optional und eine
Frage des persönlichen Geschmacks. Verwenden Sie nur Konstrukte,
die sie wirklich für anstehende Projekte benötigen.
579861275-v5