OOA, OOD, OOE und OO Modellierung meinen alle verschiedene Aspekte des gleichen Prozesses,
vgl. CRC(Class Responsibility Collaboration), nämlich der Formung eines Objektmodells,
das letztenendes die Grundlage oder das Gerüst einer Software bilden soll.
Bevor auf die genannten Konzepte und die Unified Modelling Language als bisherigen Stand der
Dinge einer Vereinbarung von Terminologien, Symbolen und Verfahrensweisen im Einzelnen eingegangen
werden kann, geht es hier zunächst um eine Klärung der Arten und Eigenschaften von Objekten
und Klassen und deren Beziehungen untereinander.
Objekte
Lebensdauer : transient, persistent
Objekte sind entweder transient(vorübergehend), oder persistent(dauerhaft).
Erzeugung : statisch - frühe Bindung,
Compile - Time
dynamisch - späte Bindung
Laufzeit, Run - Time
Aktivität : aktiv : eigener Thread, eigener Stack
sendet selbst Nachrichten
passiv : ist aktiver Einheit
ständig oder temporär zugeordnet
shared protected object : nicht fest zugeordnet
Struktur : einfach - d.h. das Objekt existiert alleine
zusammengesetzt - das Objekt enthält Komponenten - Objekte
komplex - es enthält Objekte und Beziehungen zu anderen
Objekten, die ebenfalls komplex sein können.
Rolle (d.i. die Rolle, die ein Objekt semantisch gesehen spielt) :
individuell - z.B. meinKto
repräsentativ oder prototypisch - z.B. einKto
Klassen
Abstraktion
Die Abstraktion sagt bei Klassen aus, dass eine Klasse eine Abstraktion ihrer Instanzen ist,
insofern die Instanzen eine Konkretisierung der Klasse sind. Bezüglich der Vererbung sollte man auch so modellieren,
dass eine abgeleitete Klasse eine Konkretisierung ihrer Basisklasse ist, somit die Basisklasse
eine Abstraktion ihrer abgeleiteten Klasse(n). Dieses Modell ist umso besser realisiert, je mehr
die Syntax des Quellcodes (in vereinfachter Form) der Semantik des Problems entspricht, das
mit der geplanten Software gelöst werden soll.
Klassen sind 2 teilig:
Deklaration - in einer .h - Datei
Ausführung - in einer .cpp - Datei
(Methoden)
Demnach sind Klassen ein logisches Modell, eine Schablone und ein Datentyp.
UML Syntax für Funktionen
UML besitzt eine eigene Syntax, mit der sich Quellcode umschreiben lässt. Um Verwechslungen zu
vermeiden, unterscheidet sie sich von der Syntax der bekannteren Programmiersprachen :
NameOperation([NameParameter : NameTyp[ : =Defaultwert],...])[ : NameErgebnistyp]
Was auf den ersten Blick recht kompliziert aussieht, lässt sich anhand eines Beispiels
gut erläutern:
Wir haben eine Funktion, "Wurzel", deren Deklaration in C++ so aussieht:
double Wurzel(double eingabe = 1.0);
In UML sieht dieselbe Funktionsdeklaration so aus:
Wurzel(eingabe : double : = 1.0) : double
Erläuterung: das Zeichen ": =" steht hier für den Zuweisungsoperator.
statische Beziehungen zwischen Klassen
- Vererbungsbeziehung(Generalisierung / Spezialisierung)
- Nutzungsbeziehung(Assoziierung)
lässt sich z.B. durch soetwas, wie "ZObj *LiNf ;" realisieren.
- Importbeziehung
bei Vererbung
homogene Klassenstruktur <--> Typstruktur
| |
Unterklassen typkompatibel Unterklassen spezialisieren
zu allen Oberklassen die Oberklassen
bei Nutzung / Assoziation
In der Mitte auf der Verbindung der beiden Einheiten steht in diesem Fall ein aktives Verb,
hier können auch sogenannte Rollen stehen, wie Besitzer, Fahrer, Kommandant etc.
Multiplizität
In UML schreibt man statt des " n " gerne ein " * "(Asterisk).
Assoziationen können unidirektional (in eine Richtung) oder bidirektional (in beide Richtungen) sein.
Assoziationsklassen sind ganze Klassen, die nur den Inhalt einer Assoziation enthalten,
also Datenelemente in der Regel als Zeiger, die in den beiden assoziierten Klassen nicht mehr
vorkommen, da sie ja in die Assoziationsklasse ausgelagert wurden.
"Vokabel" ist hier eine Assoziationsklasse. Die Klasse "Deutsch" enthält Referenzen auf n Objekte
der Klasse Vokabel, die ihrerseits wieder jeweils eine Referenz auf ein bestimmtes Objekt der Klasse
"Englisch" enthalten. Das Beispiel hinkt ein bisschen an der Stelle, wo bestimmte Vokabeln
mehrere Entsprechungen in der anderen Sprache haben.
Zusätzlich zu Klassennamen und Multiplizität kann man in der grafischen Darstellung einer Assoziation
auch noch einen Qualifizierer angeben :
Auch restriktive Bedingungen, bzw. Constraints werden hier angegeben:
Bsp 1 :
Bsp 2 :
