Gern wird die UML von der Industrie als Allheilmittel für die Beschreibung von Softwaresystemen be- worben. Im Projektalltag indes stößt ihre Notation immer wieder an Grenzen. An fehlenden Features liegt das nicht. Vielmehr wurde die UML mit Version 2.0 nochmals erheblich überarbeitet und ermöglicht es heute, praktisch jede Anforderungen auch im Modell darzustellen.

Die entscheidende Frage ist aber, wie gut und wie einfach der Entwickler und Architekt dies tun kann. In diesem Punkt setzen die UML-Profile an, die ebenfalls zum Standard gehören. Sie sollen gerade die Besonderheiten eines Problems oder einen individuellen Lösungsansatz formulieren helfen. Bevor sich jedoch der Anwender mit Profilen beschäftigt, sollte ihm klar sein, dass er mit ihnen den Sprachumfang der UML individuell erweitert und sicherstellen muss, dass andere Leser die Profile noch verstehen können.

Allgemein erweitern Profile die UML um so genannte leichtgewichtige Änderungen (siehe Kasten "Regeln zum Erstellen von Profilen"). Dies bedeutet, dass sich anhand vorgegebener Konstrukte das Metamodell der UML erweitern oder einschränken lässt.

Individuelle Anforderungen

Erfahrungen aus kleinen und großen Projekten haben gezeigt, dass der Einsatz von Profilen sich oft aus den Anforderungen in einem spezifischen Anwendungsgebiet ergibt. So wollen Projektteams in der Analysephase immer wiederkehrende Eigenschaften mit ihnen präzise und einfach beschreiben - seien es die Unterschiede zwischen Hard- und Software, eine besondere Art von Sensoren oder auch die Differenzen zwischen System- und Geschäftsprozessen.

Manche Teams wollen den eigenen Entwicklungsprozess an das Anwendungsgebiet anpassen und einige Artefakte dieses Prozesses mit Hilfe von Profilen besonders kennzeichnen. Ein anderes häufiges Motiv für die Verwendung von Profilen neben dem UML-Standard ist der Wunsch, bei der Beschreibung einer Architektur und im Feindesign die eingesetzten Techniken detaillierter beschreiben zu können. So soll das Profil beispielsweise darstellen, welche Teile des Modells als Javabeans implementiert sind oder welche Klasse die Rolle eines Senders von Informationen übernimmt.

Mit den nötigen Kenntnissen kann jeder Anwender ein Profil definieren. Aber auch das Industriekonsortium Object Management Group (OMG) hat als Verantwortlicher für die Standardisierung der UML schon einige Profile definiert.

Standardprofile erhältlich

So beinhaltet die UML von Haus aus zwei Standardprofile, in denen zum Beispiel spezielle Artefakt- und Komponententypen definiert sind. Zudem gibt es heute eine Reihe von weiterführenden Profilen, die sowohl auf Besonderheiten eines Anwendungsgebietes als auch auf die eingesetzten Technologien eingehen (siehe Kaste "Verfügbare Profile").

Wie sieht die Arbeit mit Profilen nun aus? Dies soll ein Beispiel verdeutlichen, in dem die UML-Notation erweitert wird. Das geschieht in der Praxis häufiger, als dass umgehrt die UML in ihrer Bedeutung eingeschränkt werden soll. Die Erweiterung erfolgt in diesem Beispiel mit Hilfe von UML-Stereotypen. Dies sind Mechanismen, mit denen sich die Bedeutung und Darstellung der UML ergänzen lässt. Stereotypen werden als eigene Piktogramme (Icons) mit eckigen Klammern dargestellt. Sie erlauben eine weitere Einteilung der Klassen, Abhängigkeiten und Assoziationen. Die Definition der jeweiligen Stereotypen erfolgt durch eine Erweiterung des Metamodells mit Hilfe der dafür definierten Erweiterungsbeziehung. Sie verbindet eine Metaklasse mit einer Klasse, die einen neuen Stereotypen darstellt.

Praxisbeispiel zum Business

Im Beispiel (siehe Grafik A) wurden der von der UML vorgegebenen Use Case um den Stereo- typen "Business" erweitert, um ihn so vom Stereotypen "System" unterscheiden zu können. Auch sind zusätzlich Multiplizitäten (Ausprägungen) an der Erweiterungsbeziehung erkennbar. Multiplizität bezieht sich in der UML auf ein Intervall nicht-negativer, ganzer Zahlen. Im Beispiel wurden die Multiplizitäten 0..1 verwendet. Sie geben unter anderem an, ob ein Stereotyp zu benutzen ist oder nicht. Somit lässt sich bei einem Use Case einer der angegebenen Stereotypen verwenden. Das ist aber nicht zwingend. Weiterhin ist in Grafik A die mögliche Spezialisierung von Stereotypen dargestellt: Geschäftsprozesse müssen nicht zwangsläufig von einem System unterstützt werden, was hier durch den Stereotyp "Pure Business" modelliert ist.

Verschiedene Beschreibungen

Da die Stereotypen im Metamodell durch spezielle Klassen definiert werden, sind hier noch weitere Beschreibungsmöglichkeiten wie beispielsweise Attribute möglich. Darüber hinaus können Anwender wie bei jeder Definition innerhalb des Metamodells auch hier spezielle Randbedingungen für die Verwendung der Stereotypen mit Hilfe von "Constraints" als Text beschreiben.

Grafik B zeigt, wie sich die in der Grafik A definierten Stereotypen am Beispiel einer Taxivermittlungszentrale verwenden lassen. Hier ist explizit modelliert, welche Business-Use-Cases für eine Systementwicklung betrachtet werden müssen ("Auftrag entgegennehmen" und "Taxifahrer informieren"). Aus ihnen können die vom System geforderten Funktionen abgeleitet werden. Der Use Case "Ablösung informieren" ist in diesem Beispiel zwar auch eine Aufgabe der Taxivermittlungszentrale, wird jedoch nicht vom System unterstützt und muss daher für die Systementwicklung nicht betrachtet werden. Für jeden neu eingeführten Stereotypen lässt sich auch eine neue Darstellungsform definieren. Diese Stereotyp-Icons können dann - müssen aber nicht - anstelle der expliziten Nennung des Stereotypen (wie Grafik A) verwendet werden. Erweiterungen am Metamodell müssen, um formal korrekt zu sein, innerhalb eines Pakets definiert sein. Ein Paket ist ein Modellelement der UML. Es definiert in diesem Fall das neue Profil, kann innerhalb eines Werkzeugs eingebunden werden und steht so den anderen Projektbeteiligten zur Verfügung.

Insgesamt zeigt die Erfahrung, dass Profile sehr hilfreich sind, wenn es darum geht, die UML fit für neue Anwendungsbereiche jenseits der Standard-Systemmodellierung zu machen. Und dies betrifft nicht nur die eigentliche Dokumentation eines Systems. Einige Tools unterstützen auch die durch Stereotypen angepasste Generierung von Code. Trotzdem erfordert der Einsatz von Profilen einen gewissen Mehraufwand für alle Projektbeteiligten, da sie diese zusätzlich erstellen, anwenden und verstehen lernen müssen. Daher sollte in jedem Einzelfall sorgfältig geprüft werden, ob die Standard-UML nicht doch adäquate Mittel für die gewünschten Modellierungszwecke bereitstellt. Auch der Einsatz von Stereotyp-Icons ist mit Vorsicht zu genießen. Ein UML-Modell, das als solches nicht erkennbar ist, verliert seinen Sinn als gemeinsame Notationssprache.