[A] UML

nep

Inhaltsverzeichnis

1 Einleitung
    1.1 UML - Was ist das überhaupt und wozu ist es gut ?
    1.2 Einordnung von UML in den Softwareentwicklungsprozess
2 Use Cases
3 Das statische Modell
    3.1 Klassendiagramme
    3.2 Paketdiagramme
4 Das dynamische Modell
    4.1 Sequenzdiagramme
5 Ausblick
6 Literatur

1 Einleitung

1.1 UML - Was ist das überhaupt und wozu ist es gut ?

Bestimmt jeder, der das hier liest hat schon einmal etwas von UML gehört bzw. ist auch bestimmt schon mit UML-Diagrammen (sehr wahrscheinlich Klassendiagrammen) in Berührung gekommen.
Doch was ist UML überhaupt? UML steht für Unified Modeling Language, d.h. auch wenn man es nicht vermuten würde, handelt es sich bei UML tatsächlich um eine Sprache, welche aber anstatt von Grammatiken und vordefinierten Schlüsselwörtern, grafische Elemente zur Darstellung anbietet. Mithilfe dieser grafischen Notationsmöglichkeiten soll man in die Lage versetzt werden (komplexe) Softwaresysteme zu modellieren.
Der Zweck von UML ist es also, mithilfe seiner verschiedenen Diagrammtypen ein Softwaresystem zu beschreiben und zu designen. Zu diesem Zweck gibt es relativ viele verschiedene Diagramme, z.B. Use Case-Diagramme, Klassendiagramme, Paketdiagramme, Sequenzdiagramme, Aktivitätsdiagramme, Kollaborationsdiagramme, Zustandsautomaten, Objektdiagramme, und noch einige mehr. In UML 2 sind es meines Wissens an die 14 Diagramme. Von diesen 14 Diagrammen benötigt man aber nur einen Bruchteil in der Praxis; das liegt auch daran, dass verschiedene Diagramme für ein und diesselbe Sache gedacht sind, dafür aber unterschiedliche Notationen anbieten.
Einige Leute denken sich jetzt vielleicht "Toll...UML...den Scheiss brauch ich doch nicht zum Programmieren". Tja das mag vielleicht sogar stimmen, sofern man nur kleinere Programme erstellt, die noch im Tausender Bereich an Code-Zeilen liegen. Strebt man jedoch größere Projekte an, wird man nicht drum herum kommen sein Softwaresystem in irgendeiner Art und Weise zu modellieren. Ohne eine gute Planung und Modellierung ist man fast zwangsläufig zum Scheitern verurteilt. Genau das ist auch der Hauptgrund warum so viele Hobby-Projekte scheitern: Ungenügende Planung und mangelndes Design. Ob man für diese Aktivitäten nun UML oder andere Methoden einsetzt, ist dabei erst einmal zweitrangig. Wichtig ist eben nur, DASS man diese Dinge *sehr* ausführlich erledigt, BEVOR man ans Programmieren geht. UML ist dabei nur ein Werkzeug; nur durch den Einsatz von UML wird man keine Wunderdinge vollbringen. Die eigentliche Arbeit besteht darin komplexe Probleme zu erfassen, zu modellieren und zu abstrahieren (dazu mehr im nächsten Abschnitt). Das kann man im Prinzip auch analog auf Programmiersprachen übertragen: Ob man für die Programmierung eines Taschenrechners nun C++, Java oder meinetwegen Delphi verwendet ist relativ egal. Alle Sprachen bieten Features, mit welcher man diese Aufgabe bewältigen kann. Die Logik die man hierfür implementieren muss ist die gleiche, egal welche Sprache man einsetzt (es kann jedoch durchaus sein, dass die ein oder andere Sprache bessere Möglichkeiten bietet einen Taschenrechner zu programmieren). Genau gleich verhält es sich mit der UML: Es gibt noch weitaus mehr Möglichkeiten Softwaresysteme zu modellieren als nur die UML. UML bietet hierfür jedoch einige Vorteile und ist heutzutage der de-facto Standard, deshalb lohnt es auf jeden Fall sich mit UML auseinanderzusetzen (siehe dazu auch: Abschnitt 5 - Ausblick).

In diesem Artikel werden die, aus meiner Sicht, wichtigsten Diagramme behandelt; viel mehr wird man für die alltägliche Praxis auch selten benötigen.
Ein Ziel dieses Artikels soll es sein, dem Leser die grundlegenden Prinzipien der Softwareentwicklung aufzuzeigen und anhand dessen zu zeigen wie man UML sinnvoll als Werkzeug dafür benutzen kann. Natürlich steht dabei auch die "Syntax" von UML im Vordergrund, denn wie bei jeder (Programmier)Sprache muss man erst einmal die Syntax beherrschen, um sie sinnvoll anwenden zu können.

1.2 Einordnung von UML in den Softwareentwicklungs-Prozess

Der klassische Prozess der Softwareentwicklung sieht ungefähr so aus (Wasserfall-Modell):

Am Anfang steht also immer die Anforderungsermittlung. Dieser Punkt ist entscheidend für den späteren Verlauf (und Erfolg) des Projekts und je mehr Zeit man hierein investiert, desto besser. In der Praxis ist die Anforderungsermittlung oft ein langwieriger und komplexer Prozess, da hier viele unterschiedliche Personen in unterschiedlichen Rollen beteiligt sind (Entwickler, Kunde, Manager, usw...). Als Hobby-Entwickler hat man es da doch wesentlich einfacher: Man plant ein Projekt für sich selbst und kann somit auch selbst die Anforderungen festlegen, so dass diese Aktivität doch um einiges schneller als in der Berufswelt von statten geht. Das ändert aber nichts daran, dass dieser Schritt nach wie vor *sehr* wichtig ist. Wie man an der Grafik sieht, ist das Modell stufenförmig aufgebaut und es ist auch erlaubt zu einer vorangegangenen Phase zurückzukehren, um Änderungen zu berücksichtigen (z.B. kann man von der Implementierungsphase zurück in die Anforderungsermittlung). Je tiefer man aber schon im "Wasserfall" ist, desto schwieriger und zeitintensiver werden Änderungen in vorhergehenden Phasen. Deshalb sollte zu Beginn versucht werden, die Anforderungen möglichst komplett zu ermitteln. Natürlich wird man es nie schaffen alle Anforderungen zu Beginn ohne Änderungen zu ermitteln. Aber wie gesagt, je mehr desto besser; und das sollte sich insbesondere bei Hobby-Projekten als nicht allzu schwer herausstellen.
UML unterstützt den Softwareentwickler durch Use Cases bei der Anforderungsermittlung ( -> Abschnitt 2 ). Man kann dafür aber u.a. auch schon (weniger technische) Klassendiagramme benutzen.