2.2. OBJEKTORIENTIERTE SPEZIFIKATION 41
Text
Abbildung 2.22: Notizen
Notizen Notizen können entweder an Klassenkategorien oder an Klassen direkt angehängt werden und dienen zur näheren Beschreibung bzw. Orientierung.
Klassenspezi?kation Die graphische Sicht der Klassen und deren Zusammenarbeit alleine helfen nicht bei der Systementwicklung. Klassen und später deren Operationen müssen näher spezi?ziert werden. Wie könnte eine solche Klassenspezi?kation nun aussehen? Hier ein Beispiel (die ersten sechs Einträge sollten unbedingt enthalten sein):
Name: Bezeichner
Definition: Text
Verantwortlichkeiten: Text
Attribute: Liste der Attribute
Operationen: Liste der Operationen
Einschränkungen: Liste der Einschränkungen Status Maschine: Referenz auf
Statusmaschine (s.u.) Exportsteuerung: public | protected | private |
implementation
Kardinalität: Ausdruck
Parameter: Liste formaler und generischer Parameter Persistenz:
transient | persistent
Nebenläufigkeit: sequentiell | überwacht | synchron | aktiv
Speicherkomplexität: Ausdruck
Operationsspezi?kation Eine Klasse beinhaltet verschiedene Operationen, die jede einzeln spezi?ziert werden mufl. Das folgende Beispiel zeigt, wie eine solche Spezi?kation aussehen könnte (die ersten vier Einträge sollten wieder unbedingt enthalten sein):
Name: Bezeichner
Definition: Text
Rückgabeklasse: Referenz auf die Klasse
Argumente: Liste formaler Argumente
Exportsteuerung: public | protected | private | implementation
Protokoll: Text
Vorbedingungen: Text | Referenz auf Quellcode | Referenz auf
Objektdiagramm
Semantik: Text | Referenz auf Quellcode | Referenz auf Objektdiagramm
Seite 41: vorherige Seite | nächste Seite | Übersicht
42 KAPITEL 2. SEMINARVORTRÄGE
Nachbedingungen: Text | Referenz auf Quellcode | Referenz auf
Objektdiagramm
Ausnahmen: Liste der Ausnahmen
Nebenläufigkeit: sequentiell | überwacht | synchron Speicherkomplexität:
Ausdruck
Zeitkomplexität: Ausdruck
2.2.5.2 Zustandsdiagramm
Das Zustandsdiagramm zeigt die Existenz von Klassen und, viel wichtiger, wie sie ihr Verhalten ändern. Mit Hilfe von Zustandsdiagrammen läflt sich das dynamische Verhalten von einzelnen Klassen modellieren.
Name
Attribute
Ereignis/Aktion
Start
Stop
Verschachtelung
Status-Icon
Histrory
H
Status 1
Status 2
Status 3
Oberstatus
Abbildung 2.23: Elemente des Zustandsdiagramms
Be?ndet sich ein Querstrich an der Pfeilspitze einer Aktion oder eines Ereignisses, handelt es sich bei dem Status, auf den der Pfeil zeigt, um einen verschachtelten Status, d.h. wird eine Hierarchieebene tiefer gegangen, so öö- net sich der Status zu einem neuen Oberstatus. Das History-Icon gibt an, dafl der Vorgängerzustand gespeichert wird und nach Abarbeitung der aktuellen Zustandsfolge in den Vorgängerzustand zurückgekehrt wird.
Das Beispiel zum Zustandsdiagramm in Abbildung 2.24 zeigt exemplarisch an der Klasse Zivi, in welchen Zuständen sich diese Klasse be?nden kann, bzw. wie ein Zivi modelliert werden kann.
2.2.5.3 Objektdiagramme
Das Objektdiagramm stellt die Existenz von Objekten und deren Beziehungen bzw. deren Interaktionen miteinander dar. Mit Hilfe von Objektdiagrammen können Szenarien durchgespielt werden, um zu testen, ob das System das gewünschte Verhalten modelliert. Im Beispiel in Abbildung 2.26 wird mit Hilfe eines Objektdiagramms modelliert, wie ein Zivi einen Schüler zur Schule bringt.
Seite 42: vorherige Seite | nächste Seite | Übersicht
2.2. OBJEKTORIENTIERTE SPEZIFIKATION 43
Betreuungs-
aufgabe
Betreuung
nichts zu tun
Probleme
H
Schulfahrt
fertig
unterwegs
einladen
einladend
ausladen
Schulfahrt
fertig
Probleme
Probleme
Probleme
erkennen melden beseitigen
in der Schule
unbeschäftigt
Abbildung 2.24: Beispiel für Zustandsdiagramme für die Klasse Zivis
Objekt-Icon
Link
Nachrichten/Objekt/Wert
Rolle
{Einschränkung}
[Schlüssel]
Name
Attribute
Synchronisation
einfach
synchron
eingeschränkt
timeout
asynchron
Sichtbarkeitsbereich
G global
P parameter
F field
L local
Abbildung 2.25: Elemente des Objektdiagramms
Seite 43: vorherige Seite | nächste Seite | Übersicht
44 KAPITEL 2. SEMINARVORTRÄGE
Max:Zivi
Schulfahrt
1:welcheAufg()
Dienstplan
AktPlan:
2:welcheFzg()
Schlüssel
DRKPark
Fuhrpark
3:benutze
Bus:Fzg
Moritz
Moritz:Schüler
Moritz
5:bringe(Schule)
XY:Schule
4:hole(Schüler)
muß pünktlich
sein
Abbildung 2.26: Beispiel für ein Objektdiagramm
2.2.5.4 Interaktionsdiagramm
Das Interaktionsdiagramm ist eine andere Darstellungsform des
Objektdiagramms. Es stellt die Interaktionen zwischen Objekten in
zeitlichem Ablauf dar.
Das Beispiel in Abbildung 2.27 ist direkt aus dem obigen Beispiel zum
Objektdiagramm abgeleitet.
2.2.5.5 Moduldiagramm
Anders als die vorhergehenden Diagramme bietet das Moduldiagramm keine logische Sicht auf das zu entwickelnde System, sondern eine physikalische. Das Moduldiagramm modelliert die Aufteilung in einzelne Module, d.h. die Hierarchiestufen der Implementierung. Innerhalb der Module be?nden sich die Klassen, die durch die Module in funktionale Einheiten gegliedert sind.
Mit Hilfe der Untersysteme lassen sich einzelne Modulbäume hierarchisch anordnen. Ob eine strikte Trennung zwischen Modulspezi?kation und Modulrumpf besteht, ist abhängig von der Programmiersprache.
Seite 44: vorherige Seite | nächste Seite | Übersicht
2.2. OBJEKTORIENTIERTE SPEZIFIKATION 45
Seite 45: vorherige Seite | Übersicht