Ein Objekt ist eine abgeschlossene, für sich handlungsfähige Einheit, beispielsweise der Kunde "Hans Meier" oder der Vertrag "P-DFD-23". Bei der objektorientierten Entwicklung werden Objekte aus der physischen (realen) Welt in Objekte der Programmiersprache nachgebildet. Bei dieser digitalen Nachbildung werden aber nur die wichtigsten Eigenschaften wie Name, Vorname, Geburtsdatum oder Geschlecht übernommen. Eigenschaften wie Haarfarbe werden für die Aufgaben des Systems in den meisten Fällen nicht benötigt.
Eine Klasse liefert in der Objektorientierung die Struktur, die zur Bildung eines "digitalen Objekts" erforderlich ist. Auf Basis einer Klasse können beliebig viele Objekte erzeugt werden. Alle aus einer Klasse erzeugten Objekte haben die gleiche Struktur, also dieselben Attribute und Methoden. Aus welchen Klassen ein objektorientiertes System besteht und wie die Struktur der benötigten Klassen aussieht, wird in der Phase "objektorientiertes Design" festgelegt. Ausgangspunkt für das Design sind die ermittelten und spezifizierten Anforderungen.
Bei der objektorientierten Programmierung von IT-Systemen werden (fast) nur Klassen implementiert. Ein objektorientiertes System erzeugt dann bei Bedarf die entsprechenden Objekte, zum Beispiel aus Datenbankeinträgen oder Benutzereingaben. Durch die Beschreibung der Klassen wird gewährleistet, dass sich alle Objekte, die auf Basis dieser Klasse erzeugt werden, gleich verhalten. Alle Objekte einer Klasse haben dieselben Attribute und verfügen über die gleichen Funktionen und Routinen (Methoden). Damit können alle aus einer Klasse erzeugten Objekte von den Funktionen des Systems in gleicher Weise verarbeitet werden.
Die zentralen Aktivitäten bei der Analyse und später beim Design sind das Identifizieren und Beschreiben von Klassen. Obwohl die Sichtweise "Objektorientierung" heißt, stehen eigentlich vielmehr die Klassen im Vordergrund der Betrachtung.
Um bei der Analyse zu bestimmen, was ein System tun soll, und dann darauf aufbauend später beim Design festzulegen, aus
welchen Klassen das System bestehen soll, wird in einem ersten Schritt ein Analysemodell des Systems entwickelt:
Aus der Aufgabenstellung beziehungsweise den Anforderungen an das System müssen Kandidaten für Klassen identifiziert
und notiert werden.
Die etablierte Vorgehensweise zur Identifikation von Klassen kann wie folgt beschrieben werden:
Klassen werden immer in Form eines Rechtecks dargestellt, der Name der Klasse wird in das Rechteck geschrieben.
Beispiel:
Wie bereits beschrieben, bestehen Klassen (und damit auch Objekte) aus Attributen und Methoden. Die Attribute (auch:
Eigenschaft von Klassen, engl. property) sind statische Elemente von Klassen. In einem Attribut können konkrete Werte
zu dem Objekt gespeichert werden. Attribute dienen ausschließlich zum Speichern von Werten, man kann sie als freie
Speicherplätze innerhalb eines Objekts verstehen. Zusammengefasst beschreiben die Werte aller Attribute eines Objekts
dessen Zustand. Objekte, die aus einer Klasse erzeugt wurden und deren Attribute exakt die gleichen Werte haben, sind
identisch.
Attribute werden unterhalb des Klassennamens in einem eigenen Rechteck notiert.
Bei der Modellierung von Attributen können u.a. die unten in der Tabelle beschriebenen Eigenschaften festgelegt werden. Von diesen Eigenschaften ist in einem Analysemodell mindestens der Name erforderlich. Die fehlenden Eigenschaften werden im Verlauf des SW-Entwicklungsprozesses festgelegt.
| Eigenschaften eines Attributs | Beschreibung | Beispiel |
| Name | Name des Attributs | Vorname |
| Datentyp | Legt fest, wie die Werte zu dem Attribut aussehen, also ob es z.B. eine Zahl, eine Zeichenkette oder ein Datum ist |
Date(Datum) String (Zeichenkette) Integer (Ganze Zahl) |
| Konstante (ja/nein) | Legt fest, ob sich der Wert des Attributs ändern darf oder nicht |
Gerundete Kreiszahl Pi: 3,1415 |
| Defaultwert | Legt den voreingestellten Wert des Attributs fest | 2010-01-01 |
Methoden (auch: Funktionen, Operationen) sind dynamische Elemente von Klassen. Sie enthalten Algorithmen, Anweisungen und Abarbeitungsvorschriften, mit denen Werte erstellt, berechnet, verändert und gelöscht werden können. Die Ergebnisse der Methoden können in Attribute der Klasse oder in neu erzeugte Objekte gespeichert werden. Mit Methoden wird das Verhalten von Objekten beschrieben, also was ein Objekt macht.
Bei der Modellierung von Methoden können u.a. die unten in der Tabelle beschriebenen Elemente festgelegt werden. In einem Analysemodell wird mindestens der Name benötigt. Detaillierte Informationen zu Rückgabewert, Parameter und der Funktion der Methode können auch im Laufe des Entwicklungsprozesses Stück für Stück ergänzt werden.
| Elemente von Methoden | Beschreibung | Beispiel |
| Name | Name der Methode | getName() |
| Parameter | Benötigte Objekte und Werte, die zur Abarbeitung der Methode erforderlich sind |
(Date geburtsdatum) |
| Rückgabewert | Angabe des Datentyps des Objektes, in dem das Ergebnis der Methode gespeichert wird |
Date (Datum)String (Zeichenkette)Integer (Ganze Zahl) |
Wichtig ist in jedem Fall, dass die in den Attributen gespeicherten Werte wieder ausgelesen werden können. Von außen
darf auf Attribute nur über Methoden zugegriffen werden und niemals direkt.
Methoden einer Klasse werden in einem zusätzlichen Rechteck unterhalb der Attribute modelliert.
Ein Zusammenspiel verschiedener Klassen ist nur möglich, wenn während der Phasen des Entwicklungsprozesses Beziehungen (auch: Assoziationen) zwischen Klassen definiert werden. Durch die Festlegung von Beziehungen zwischen Klassen ist eine Kooperation zwischen Objekten überhaupt erst möglich.
Typische Beziehungen zwischen Klassen sind in untenstehender Tabelle erläutert:
| Beziehungstypen | Beschreibung | Beispiel |
| "hat/kennt" | Dieser Beziehungstyp drückt aus, dass eine Klasse eine andere Klasse "hat" oder "kennt". |
Ein Versicherungsnehmer hat Kinder. Ein Vertrag hat Versicherungsbedingungen. Ein Kalender hat Monate. Ein Verkäufer kennt seine Kunden. |
| "besteht aus" | Dieser Beziehungstyp drückt aus, dass eine Klasse ein Bestandteil einer anderen Klasse ist. Er wird genutzt, wenn eine Klasse ein größeres Konstrukt ist, dessen Elemente nicht durch einfache Attribute beschrieben werden können. |
Ein Auto besteht aus einem Motor, 4 Rädern, 3 Türen, 1 Getriebe und 2 Sitzen. Ein Haus besteht aus einem Dach, 23 Fenstern, 2 Türen, 6 Räumen und 1 Treppenhaus. |
| "ist ein" | Dieser Beziehungstyp drückt aus, dass eine Klasse A von der Art her eine Klasse B ist, aber eine spezifischere Bedeutung hat und sich ggf. um bestimmte Attribute und Methoden von Klasse B unterscheidet. |
Ein PKW ist ein Auto. Ein LKW ist ein Auto. Ein Kunde ist eine Person. Ein Buch ist ein Artikel. Ein Igel ist ein Säugetier. |
Um neben Klassen, Attributen und Methoden ebenfalls die Beziehungen grafisch darzustellen, werden Linien bzw. Pfeile zwischen den entsprechenden Klassen modelliert.
| Darstellung der Beziehung | Bedeutung |
 Durchgezogene Linie, ohne Pfeilspitze und ohne Beschriftung |
Vertrag und Adresse stehen in einer nicht näher beschriebenen Beziehung zueinander. |
 Durchgezogene Linie, Beschriftung der Linie mit einem Namen für die Beziehung |
Vertrag und Adresse sind über eine benannte Assoziation verbunden; die beiden Klassen sind verbunden durch die Beziehung "Rechnungsanschrift". |
 Durchgezogene Linie mit einer Pfeilspitze, ggf. Benennung der Beziehung |
Durch die Pfeilspitze wird eine Navigationsrichtung vorgegeben: vom Vertrag zur Adresse. Das bedeutet, dass der Vertrag eine Adresse kennt und man sich vom Vertrag zur Adresse durchhangeln kann. Jedoch nicht von der Adresse zum Vertrag: Ein Vertrag kennt seine Adresse, aber die Adresse weiß nichts von und über die Existenz des Vertrags. |
 An den Enden der Beziehung werden Multiplizitäten modelliert und damit Aussagen über die Anzahl der assozierten Objekte gemacht |
Ein Vertrag hat genau eine Rechnungsanschrift, eine Adresse kann jedoch die Rechnungsanschrift zu mindestens 1 aber maximal beliebig vielen Verträgen sein. |
Zu Beziehungen können mit Multiplizitäten (auch: Kardinalitäten) Mengenangaben festgelegt werden. Diese Angaben werden jeweils an das Ende und die Spitze einer Beziehung notiert: Links von ".." steht die Untergrenze und rechts von ".." die Obergrenze der Mengenangaben.
Überblick über mögliche Mengenangaben:
| Notation | Erklärung | Beispiel |
| 0..1 | Optionale Assoziation |  Zu einem Auto gehören 0..1 Anhänger. Zu einem Anhänger gehören 0..1 Autos. |
| 1 | Obligatorische Assoziation |  Zu einem Auto gehört genau 1 Fahrer. Ein Fahrer gehört zu genau 1 Auto. |
| 0..* | Optional beliebig |  Ein Student kann 0..* Kurse belegen. Ein Kurs kann von 1..* Studenten belegt sein. |
| 1..* | Beliebig, aber mindestens 1 |  Ein Tutor kann 1..* Kurse machen. Ein Kurs wird von genau 1 Tutor durchgeführt. |
| n..m | Mindestens n und maximal m |  Ein Auto hat mindestens 3 und maximal 4 Türen. Eine Tür gehört zu genau 1 Auto. |
| Keine Angabe entspricht 1 (sollte aber vermieden werden, um Missverständnisse zu vermeiden) |
 Ein Auto hat genau 1 Motor. Ein Motor gehört zu genau 1 Auto. |
Die Anwendung der Konzepte (Klasse, Objekt, Methode, Attribut) zieht sich durch alle Phasen eines objektorientierten Entwicklungsprozesses. Um die Ergebnisse der Phasen OOA und OOD geeignt zu dokumentieren, werden die identifizierten Klassen und deren Beziehungen in einer standardisierten Modellierungssprache dokumentiert.
Die Unified Modeling Language (kurz: UML) ist eine grafische Modellierungssprache, die etwa zeitgleich mit der
Objektorientierung in den frühen 1990er Jahren entwickelt wurde. Die UML umfasst mittlerweile 13 verschiedene
Diagrammtypen, mit denen verschiedene Aspekte eines Systems modelliert werden können.
Grundsätzlich lassen sich Diagramme zur Modellierung von Struktur und zur Modellierung von Verhalten unterscheiden.
Mit Strukturdiagrammen werden Aufbau, Elemente und Zusammensetzung sowie Schnittstellen von Systemen dargestellt.
Vereinfacht gesagt werden Strukturdiagramme eingesetzt, um zu modellieren, woraus ein System besteht.
Verhaltensdiagramme hingegen kommen zum Einsatz, wenn dargestellt werden soll, was in einem System abläuft.
Übersicht über UML-Diagrammtypen:
UML-Diagramme
Klassen mit ihren Attributen, Methoden und Beziehungen werden mit dem UML Klassendiagramm modelliert. Das UML Klassendiagramm ist weltweit eine der am häufigsten genutzen Dokumentationsformen bei der objektorientierten Systementwicklung. Alle anderen Strukturdiagramme der UML bauen mehr oder weniger auf den Modellierungskonzepten des Klassendiagramms auf.
Objektdiagramme sind eine Spezialform der Klassendiagramme. Mit ihnen kann man ganz konkrete Ausprägungen von Klassen darstellen. Dazu werden Objekte modelliert, deren Attribute Werte enthalten. Objekte unterscheiden sich von Klassen dahingehend, dass...
