UML (Unified Modeling Language)

Im Wesentlichen unterscheidet die UML 2.0 zwischen einfachen Datentypen, primitiven Datentypen und Aufzählungstypen, wie man in dem Metamodell sehen kann. Dabei ist der Begriff »einfacher Datentyp« der Oberbegriff der primitiven Datentypen und der Aufzählungstypen, der so genannten Enumerations. Ein einfacher Datentyp ist ein Typ, dessen Werte keine Identität haben. Hier ist genau der Unterschied zu einer Klasse zu sehen. Jedes Objekt einer Klasse unterscheidet sich eindeutig und besitzt eine eigene Identität. Werte eines Datentyps hingegen kann man nicht voneinander unterscheiden.

Das Einsatzgebiet der Klassendiagramme beginnt mit dem Projekt, in den meisten Fällen nach der Erstellung der Anwendungsfallanalyse und des Aktivitätsdiagramms. Es ist durchaus sinnvoll, bereits in der Analysephase mit den Klassendiagrammen zu beginnen. Hier würde man sicherlich noch nicht detailliert planen, sondern eine erste Grobplanung erstellen. Letztendlich wird während des Projekts noch einiges geändert, und das Klassendiagramm bietet eine gute Hilfestellung, um die Komplexität einer Anwendung beziehungsweise eines Teiles davon aufzunehmen und zu beschreiben. Während der Erfassung der Kundenwünsche sollen erst einmal die allgemeinen Zusammenhänge mit Hilfe des Klassendiagramms grundlegend beschrieben werden. Die Details werden erst dann hinzugefügt oder geändert, wenn die einzusetzende Technik, Technologie, ja in manchen Fällen sogar die Programmiersprache feststeht. Im ersten Schritt fehlen häufig die Datentypen, Schnittstellen und Methoden, und die Klasse erfasst auch namentlich erst einmal nur die Aufgabe, für die sie später zuständig ist. Ein Klassendiagramm enthält alle Informationen über die eigentliche Programmierung, der enthaltenen Eigenschaften und Funktionalitäten der Klassen und der Beziehung der Klassen untereinander.

Die im Deutschen so genannten Anwendungsfalldiagramme (Spezifikation: Use Cases) zeigen den Nutzen eines Systems, also das, was ein System dem Nutzer an Funktionalität bereitstellt. Somit sind die Anwendungsfalldiagramme insbesondere dazu geeignet, die Funktionalität der zu programmierenden Software genau darzustellen. Die so genannte Use-Case-Beschreibung ist zunächst rein textuell und wird nicht mit UML-2.0-Notationselementen beschrieben. Diese rein textuelle Beschreibung ist damit nicht Gegenstand der Prüfung, sondern vielmehr die UML-Variante, die nachfolgend beschrieben wird.

Mit den Verhaltensdiagrammen werden im Wesentlichen die einzelnen Elemente und deren Veränderungen zur Laufzeit beschrieben. Mit den Verhaltensdiagrammen der UML 2.0 soll also Klarheit über die Geschäftsprozesse, internen Abläufe, des Zusammenspiels des Systems und vieles mehr geschaffen werden. Es geht sozusagen um die Veränderungen der einzelnen Classifier eines Systems zur Laufzeit. Für diese Veränderungen gibt es verschiedene Diagrammtypen, die jeweils einen anderen Aspekt genauer beleuchten. Da die UML 2.0 komplett objektorientiert ist, gibt es immer nur Objekte, die ihre Zustände durch Verhalten ändern. Verhalten ist sozusagen beobachtbar, man kann sich also die Eigenschaften der beteiligten Elemente im Verlauf der Zeit ansehen und die Veränderungen beobachten.

Die Interaktionsdiagramme verhelfen generell sowohl Entwicklern als auch Planern, den Informationsaustausch zwischen den Kommunikationspartnern aufzuzeigen. Die einzelnen Kommunikationspartner tauschen dabei Daten und Nachrichten aus. Eines der Interaktionsdiagramme ist das so genannte Sequenzdiagramm, das hauptsächlich für den Fundamental-Test von großer Bedeutung ist. Mit seiner Hilfe wird der Nachrichtenfluss zwischen einzelnen Objekten beschrieben und daneben die chronologischen Abläufe dargestellt. Die Beziehung zwischen den einzelnen Kommunikationspartnern ist hierbei nicht das Thema des Sequenzdiagramms, hier findet der Entwickler im Kommunikationsdiagramm der UML 2.0 mehr Informationen. Dabei können Kommunikationspartner sowohl Objekte als auch Systeme sein. In der Praxis sieht man sehr häufig den Einsatz der Sequenzdiagramme als Interaktionsdiagramm, wobei darüber hinaus noch weitere Interaktionsdiagramme existieren, zum Beispiel das Kommunikationsdiagramm. Das Kommunikationsdiagramm hat seinen Schwerpunkt in der Darstellung der Beziehung der Kommunikationspartner zueinander.

Mit Hilfe eines Aktivitätsdiagramms beschreibt man Aktivitäten, also allgemeine Abläufe und deren chronologische Reihenfolge, wie sie zur Laufzeit eines Programms vorkommen. Meist sind diese dynamischen Beschreibungen der Realität nicht ganz so einfach, wie es in manchen Abhandlungen beschrieben wird. In der natürlichen Sprache entsteht allerdings fast nie ein umfassender Überblick über die Abläufe, so dass ein Diagramm zur Beschreibung sicherlich bessere Dienste leistet. Die UML 2.0 stellt daher eine ganze Reihe an Notationselementen bereit, die dieser Aufgabe der komplexen Beschreibung Rechnung trägt. Eine Aktivität enthält dabei im Wesentlichen Knoten, gerichtete Kanten (Spezifikation: Flows), Aktionen und Kontrollknoten.