Anwendungsbereiche umfassen meist Konzepte, mit denen Software-Entwickler nicht vertraut sind. Der Lösungsbereich (Benutzerschnittstellenwerkzeuge, drahtlose Kommunikation, Datenbanksysteme, Transaktionsüberwachungssysteme, tragbare Rechner, und so weiter) ist oft noch nicht ausgereift und bietet dem Entwickler viele sich widersprechende Implementierungstechnologien an. Folglich werden das System und das Entwicklungsprojekt komplex, weil sie viele Werkzeuge, Methoden und Leute umfassen.
Komplexität und Änderung stellen Herausforderungen dar, die es für einen Einzelnen oft unmöglich machen, das System und seine Entwicklung zu kontrollieren. Bei unsachgemäßer Kontrolle vereiteln Komplexität und Änderung die Lösung noch vor der Fertigstellung, selbst wenn das Ziel schon in Sicht ist. Zu viele Fehler in der Interpretation des Anwendungsbereichs machen die Lösung für den Benutzer nutzlos und erzwingen möglicherweise einen Rückzug vom Markt. Unzulängliche und inkompatible Implementierungstechnologien haben Unzuverlässigkeit und Verzögerungen zur Folge. Fehler bei der Behandlung von Änderungen erzeugen neue Fehler im System und machen das Produkt unbrauchbar.
Abhilfe schafft die Unified Modeling Language (UML), deren Ziel es ist, eine Standardnotation für alle objektorientierten Methoden zu bieten und dabei die am besten geeigneten Elemente aus bereits bestehenden Notationen auszuwählen und einzubinden. So verwendet UML zum Beispiel die bei Object-Oriented Software Engineering (OOSE) eingeführten Anwendungsfalldiagramme sowie viele Merkmale der Klassendiagramme aus der Object Modeling Technique (OMT).
Die dreiteilige Artikelserie ist dem Buch Objektorientierte Softwareentwicklung der Autoren Bernd Brügge und Allen H. Dutoit entnommen. Das Buch ist im Verlag Pearson Studium erschienen. Sie können das komplette, 752 Seiten starke Werk im tecCHANNEL Bookshop bestellen oder direkt als E-Book downloaden.
Einführung
UML ist eine Bezeichnung, die sich bei der Vereinheitlichung von OMT (Object Modeling Technique), Booch und OOSE (Object-Oriented Software Engineering) ergeben hat. UML wurde aber auch von anderen objektorientierten Notationen beeinflusst, wie sie zum Beispiel von Shlaer/Mellor, Coad/Yourdon, Wirfs-Brock und Martin/Odell eingeführt wurden.
UML umfasst aber auch neue Konzepte, die bei anderen wichtigen Methoden nicht vorkommen, wie den Erweiterungsmechanismus und eine beschränkte Sprache. UML wurde für eine Vielzahl von Anwendungen entwickelt. Daher stellt es auch Konstrukte für eine große Menge von Systemen und Aktivitäten bereit (beispielsweise Echtzeitsysteme, verteilte Systeme, Analyse, Systementwurf oder Verteilung). Die Systementwicklung konzentriert sich auf drei verschiedene Systemmodelle:
Das funktionale Modell wird in UML durch Anwendungsfalldiagramme dargestellt und beschreibt die Funktionalität des Systems aus der Sicht des Benutzers.
Das statische Modell wird in UML durch Klassendiagramme dargestellt und beschreibt die Struktur eines Systems hinsichtlich der Objekte, Attribute, Assoziationen und Operationen. Wir bezeichnen das statische Modell aus historischen Gründen oft auch als Objektmodell und unterscheiden dabei drei Ausprägungen: Während der Anforderungsermittlung und der Analyse heißt es Analyse-Objektmodell und beschreibt Elemente, die für den Anwendungsbereich relevant sind. Während des Systementwurfs wird das statische Modell in das Systementwurfs-Objektmodell verfeinert und enthält Beschreibungen der Subsystemschnittstellen. Während des Objektentwurfs wird das statische Modell in das detaillierte Objektmodell verfeinert und enthält genaue Beschreibungen von Objekten aus dem Lösungsbereich.
Das dynamische Modell wird in UML durch Interaktionsdiagramme, Zustandsdiagramme und Aktivitätsdiagramme dargestellt und beschreibt das interne Verhalten des Systems. Ein Interaktionsdiagramm beschreibt das Verhalten zwischen mehreren Objekten als eine Folge von Nachrichten, die zwischen den Objekten ausgetauscht werden. Ein Zustandsdiagramm beschreibt dagegen das Verhalten eines einzelnen Objektes als eine Menge von Zuständen und den Übergängen zwischen den Zuständen.
Anwendungsfalldiagramme
Anwendungsfalldiagramme werden während der Anforderungsermittlung und der Analyse benutzt, um die Funktionalität des Systems darzustellen. Anwendungsfälle zeigen das Verhalten eines Systems aus externer Sicht. Ein Anwendungsfall beschreibt eine vom System bereitgestellte Funktion, die ein für einen Akteur sichtbares Ergebnis aufzeigt. Ein Akteur beschreibt eine beliebige Entität, die mit dem System in Wechselwirkung tritt (z.B. ein Benutzer, ein anderes System, die physikalische Umgebung des Systems). Die Identifizierung von Akteuren und Anwendungsfällen führt zur Bestimmung der Systemgrenze. Wir unterscheiden somit die vom System durchgeführten und die von seiner Umgebung durchgeführten Aufgaben. Die Akteure befinden sich außerhalb der Systemgrenze, wohingegen die Anwendungsfälle innerhalb dieser Systemgrenze liegen.
Beispiel: Bild 1veranschaulicht ein Anwendungsfalldiagramm für eine einfache Uhr. Der UhrBenutzer-Akteur kann entweder die Zeit auf seiner Uhr abfragen (mit Hilfe des ZeitAblesen-Anwendungsfalls) oder die Zeit einstellen (mit Hilfe des ZeitEinstellen-Anwendungsfalls). Jedoch kann nur der Uhrmacher-Akteur die Batterie der Uhr wechseln (mit Hilfe des BatterieWechseln-Anwendungsfalls).
Klassendiagramme
Wir benutzen Klassendiagramme, um die Struktur des Systems zu beschreiben. Klassen sind Abstraktionen, die die allgemeine Struktur und das Verhalten eines Satzes von Objekten spezifizieren. Objekte sind Instanzen von Klassen, die während der Systemausführung erzeugt, bearbeitet und gelöscht werden. Ein Objekt hat einen Zustand, der die Werte seiner Attribute und seine Verbindungen zu anderen Objekten beinhaltet. Klassendiagramme beschreiben das System nach Objekten, Klassen, Attributen und ihren Assoziationen. So zeigt Bild 2ein Klassendiagramm, das die Elemente der Klasse EinfacheUhr beschreibt.
Die Klasse EinfacheUhr hat Assoziationen zu der Taste-Klasse, der Anzeigefeld-Klasse, der Zeit-Klasse und der Batterie-Klasse. Die Zahlen am Ende der Assoziationen geben die Kardinalität an, die ein Objekt der Klasse EinfacheUhr mit Objekten der assoziierten Klassen haben kann. Eine Instanz der Klasse EinfacheUhr hat also genau zwei Objekte der Klasse Taste, ein Objekt der Klasse Anzeigefeld, zwei Objekte der Klasse Batterie und ein Objekt der Klasse Zeit. In ähnlicher Weise sind alle Taste-, Anzeigefeld-, Zeit-, und Batterie-Objekte immer nur genau einem EinfacheUhr-Objekt zugeordnet. Auf der Analyse-Ebene stellen Assoziationen existierende Beziehungen dar. Zum Beispiel verlangt EinfacheUhr die korrekte Anzahl von Tasten, Anzeigefeld, Batterie und Zeit. In unserem Beispiel ist die Assoziation symmetrisch: Die Klasse Taste kann ihre Funktion nicht ohne die Klasse EinfacheUhr ausführen. UML erlaubt auch nur in eine Richtung zeigende Assoziationen, dazu später mehr. Auf der Implementierungsebene werden Assoziationen als Referenzen (beispielsweise Zeiger) auf Objekte verwirklicht.
Interaktionsdiagramme
Ein Interaktionsdiagramm stellt die Wechselwirkung dar, die zwischen Objekten stattfindet, die an einem Anwendungsfall teilnehmen. Derartige Objekte nennen wir deshalb auch teilnehmende Objekte. Interaktionsdiagramme werden benutzt, um das Verhalten von Systemen zu formalisieren und die Kommunikation zwischen teilnehmenden Objekten sichtbar zu machen.
Das in Bild 3 gezeigte Beispiel ist ein spezieller Fall eines Interaktionsdiagramms, nämlich ein Sequenzdiagramm für den ZeitEinstellen-Anwendungsfall unserer einfachen Uhr. Die äußere linke Spalte zeigt immer den Akteur, der den Anwendungsfall initiiert, in diesem Fall den UhrBenutzer-Akteur. Beschriftete Pfeile stellen Signale dar, die ein Akteur oder ein Objekt zu einem anderen Objekt sendet. In diesem Fall drückt der UhrBenutzer Taste 1 zweimal und Taste 2 einmal, um die Uhr eine Minute vorzustellen. Der ZeitEinstellen-Anwendungsfall endet, wenn der Uhr-Benutzer beide Tasten gleichzeitig drückt.
Zustandsdiagramme
Zustandsdiagramme beschreiben das Verhalten eines einzelnen Objekts als eine Anzahl von Zuständen und Übergängen zwischen diesen Zuständen. Ein Zustand repräsentiert einen speziellen Satz von Werten für ein Objekt. Für einen gegebenen Zustand repräsentiert eine Transition einen zukünftigen Zustand, in den das Objekt übergehen kann, und die Bedingungen, die mit diesem Wechsel verbunden sind.
Bild 4 ist ein Zustandsdiagramm für EinfacheUhr. Man beachte, dass dieses Diagramm eine andere Information beinhaltet als das Sequenzdiagramm in Bild 3. Das Sequenzdiagramm konzentriert sich auf die Nachrichten, die zwischen den Objekten als Ergebnis der vom Akteur ausgelösten externen Ereignisse ausgetauscht werden. Das Zustandsdiagramm konzentriert sich auf die Transitionen zwischen Zuständen, die das Ergebnis externer Ereignisse für ein spezielles Objekt sind.
Aktivitätsdiagramme
Ein Aktivitätsdiagramm beschreibt das Verhalten eines Systems bezüglich der Aktivitäten.
Aktivitäten sind Modellierungselemente, die die Ausführung eines Satzes von Operationen repräsentieren. Die Beendigung dieser Operationen löst den Übergang zu einer anderen Aktivität aus. Aktivitätsdiagramme ähneln Flussdiagrammen, da sie dazu benutzt werden können, den Kontrollfluss (dass heißt die Reihenfolge, in der die Operationen abgearbeitet werden) und den Datenfluss (dass heißt die Objekte, die zwischen Operationen ausgetauscht werden) zu beschreiben. Zum Beispiel stellt Bild 5 ein Aktivitätsdiagramm dar, das die Aktivitäten bei der Behandlung eines Ereignisses Vorfall zeigt. Aktivitäten werden durch abgerundete Rechtecke dargestellt; beschriftete Pfeile repräsentieren Transitionen zwischen Aktivitäten; dicke Balken bedeuten Synchronisation des Kontrollflusses.
Bild 5 zeigt, dass TeileBetriebsmittelZu, KoordiniereBetriebsmittel und DokumentiereVorfall erst initiiert werden können, nachdem die EröffneVorfall-Aktivität abgeschlossen worden ist. Ebenso kann die ArchiviereVorfall-Aktivität erst nach Beendigung der Aktivitäten TeileBetriebsmittelZu, KoordiniereBetriebsmittel und DokumentiereVorfall begonnen werden. Die letzten drei Aktivitäten können auch gleichzeitig ausgeführt werden.
Fazit und Ausblick
Damit beenden wir unseren ersten Streifzug durch die fünf Grundnotationen von UML. Wir wollen nun mehr ins Detail gehen: Im nächsten Teil führen wir grundlegende Modellierungskonzepte ein, einschließlich der Definitionen von System, Modell, Typ, Instanz, Abstraktion und Falsifikation. Danach beschreiben wir Anwendungsfalldiagramme, Klassendiagramme, Interaktionsdiagramme, Zustandsdiagramme und Aktivitätsdiagramme detaillierter und wir erläutern ihre Anwendung an einem einfachen Beispiel.
Die dreiteilige Artikelserie ist dem Buch Objektorientierte Softwareentwicklung der Autoren Bernd Brügge und Allen H. Dutoit entnommen. Das Buch ist im Verlag Pearson Studium erschienen. Sie können das komplette, 752 Seiten starke Werk im tecCHANNEL Bookshop bestellen oder direkt als E-Book downloaden. (mja)