Das Objektmodell beschreibt durch Objektdiagramme die statische Struktur der Objekte eines Systems und ihre Beziehungen zueinander. Objekte mit Zuständen und eigenem Verhalten sind gut geeignet, um den Ausschnitt der realen Welt, den das System repräsentieren soll, in einem Modell abzubilden. Ein Ziel der Modellierung ist, Objekte mit gleichen Eigenschaften und Verhalten zu einer Klasse zusammenzufassen, welche nur die für die Anwendung wichtigen Eigenschaften der Objekte enthält. Die Attribute einer Klasse spezifizieren die Datenstruktur und somit die unterscheidbaren Eigenschaften eines Objekts. Die Methoden einer Klasse sind Operationen auf den Datenstrukturen und beschreiben das Verhalten eines Objekts. Eine Klasse kann in beliebig viele gleichartige Objekte mit eigener Identität instantiiert werden. Objekte kapseln die Datenstrukturen (Attribute) und Operationen für den Zugriff (Methoden), um die interne Realisierung vor dem Benutzer zu verbergen.
Das Objektmodell ist ein Graph, dessen Knoten Objektklassen sind und dessen Kanten Relationen zwischen den Klassen darstellen. Ein Objektdiagramm ist die graphische Repräsentation des Objektmodells. Abbildung 3.6 zeigt die Notation für eine allgemeine Klasse:
Eine Klasse ist durch Angabe des Namens, der Attribute und der Signatur der Methoden bestimmt. Namen sind innerhalb einer Klasse eindeutig, das heißt, verschiedene Klassen können Attribute und Methoden mit gleichem Namen besitzen. Attribute sind Datentypen mit einem festgelegten Wertebereich. Der Zustand einer Objektinstanz wird durch die aktuelle Belegung der Attribute mit Datenwerten ausgedrückt. Die Angabe des Typs und eines Default-Werts, welcher dem Attribut bei Instantiierung des Objekts zugewiesen wird, sind im Objektdiagramm optional.
Eine Operation ist eine Funktion, die von einem Objekt auf einem Zielobjekt angewendet werden kann. Die Operation wird von einer Methode des Zielobjekts implementiert. Durch Aufruf einer Methode kann der Zustand einer Objektinstanz verändert werden. Kann die gleiche Operation auf verschiedenen Klassen angewendet werden, ist sie polymorph. Die zugehörigen Methoden haben die gleiche semantische Bedeutung, sie sind aber in der Regel unterschiedlich implementiert. Die Methoden polymorpher Operationen sollten in jedem Fall eine einheitliche Signatur haben. Die Signatur legt den Operationsnamen, Anzahl und Typ der Parameter und den Ergebnistyp fest. Die Angabe der Parameter und des Ergebnistyps für die Methoden im Objektdiagramm ist wiederum optional.
Die Identifikation geeigneter Objektklassen aus der Problembeschreibung der Analyse ist ein wichtiges Ziel der Modellierung. Das OMT-Objektmodell betrachtet aber auch die Beziehungen zwischen den Objektklassen. OMT kennt die drei unterschiedlichen Beziehungen Assoziation, Generalisierung und Aggregation.
Namen für Assoziationen werden meist aus Verben gebildet. Obwohl durch die Namen die Beziehung in der Regel nur in eine Richtung ausgedrückt wird, sind Assoziationen inhärent bidirektional. Die Umkehrung der Beziehung in obigem Beispiel könnte «führt aus» heißen. Assoziationsnamen sind optional.
Neben den binären Assoziationen sind auch Assoziationen zwischen drei (ternär) oder mehreren (n-är) Klassen möglich. Dies wird im Diagramm durch ein Rautensymbol ausgedrückt, welches über Linien die in Beziehung stehenden Klassen verbindet. In der Praxis sind höhere Ordnungen als ternär aber selten, da diese Relationen schwieriger zu verstehen und zu implementieren sind. Assoziationen werden in der Regel durch Zeiger auf verknüpfte Objekte implementiert.
Ferner gibt es Symbole zum Bezeichnen der Multiplizität. Die Multiplizität spezifiziert, wieviele Instanzen einer Klasse mit einer Instanz der anderen Klasse verknüpft sein können. Möglich sind 1:1, 1:n, n:1 und n:m-Assoziationen. Für ,,n`` bzw. ,,m`` können auch feste Werte oder fixe Intervalle definiert sein. Ein ausgefüllter, schwarzer Punkt am Linienende steht für ,,n``, der Zusatz ,,1+`` bedeutet n >= 1. Ein transparenter Punkt steht für den Multiplizitätswert null oder eins. Fehlen Symbole oder Zahlen- bzw. Intervallangaben, handelt es sich um eine 1:1-Assoziation. In obigem Beispiel liegt eine n:1-Assoziation vor. Mehrere Prozesse laufen auf genau einem System.
Besitzt eine Assoziation eigene Attribute, so ist es sinnvoll, die Beziehung durch eine sog. Beziehungsklasse zu modellieren. Eine neue Verknüpfung zwischen zwei Objekten führt dann zu einer neuen Instanz der Beziehungsklasse. Abbildung 3.8 zeigt die Beziehung «exportiert» zwischen der Klasse NFS_Server und der Klasse Filesystem. Die Optionen für den Export werden durch die Attribute der Beziehungsklasse ExportOptions modelliert.
Generalisierung und Vererbung sind transitiv. Unterklassen dürfen geerbte Methoden für Operationen überschreiben, d.h. eine eigene Implementierung für die Methode bereitstellen. Auch der Default-Wert eines geerbten Attributs kann in einer Unterklasse überschrieben werden. OMT geht allerdings von strikter Vererbung aus. Das bedeutet, daß Unterklassen geerbte Attribute oder Methoden nicht weglassen dürfen. Ferner sollte der Datentyp von Attributen sowie die Signatur von Methoden nicht verändert werden. Eine Einschränkung bzw. Erweiterung des Wertebereichs für ein Attribut muß abhängig vom Anwendungsfall vorsichtig vorgenommen werden.
Aus den Informationen des Objektmodells können Code-Gerüste zur Implementierung der Klassen in verschiedenen objektorientierten Programmiersprachen, wie z.B. C++, Java, Smalltalk etc., generiert werden.