Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

16.02.2006

Profile helfen bei der Arbeit mit UML

Chris Rupp, Stefan Queins 
Die Unified Modeling Language beschreibt Systeme, deckt im Standard aber nicht alle Praxisanforderungen ab. UML-Profile füllen die Lücke.
• Grafik A: Das Metamodell einer Anwendung wurde um ein von der UML standardmäßig vorgegebener Use Case um die Stereotypen
• Grafik A: Das Metamodell einer Anwendung wurde um ein von der UML standardmäßig vorgegebener Use Case um die Stereotypen
Grafik B: Der Stereotyp "Business" wird an zwei Stellen, der Stereotyp "Pure Business" einmal dargestellt. Nur die "Business"-Stereotypen modellieren in diesem Beispiel Use Cases, die für die Systementwicklung wichtig sind. Der Stereotyp "Pure Business" ist auch eine Aufgabe der Taxivermittlungszentrale, wird aber außerhalb des Systems implementiert.
Grafik B: Der Stereotyp "Business" wird an zwei Stellen, der Stereotyp "Pure Business" einmal dargestellt. Nur die "Business"-Stereotypen modellieren in diesem Beispiel Use Cases, die für die Systementwicklung wichtig sind. Der Stereotyp "Pure Business" ist auch eine Aufgabe der Taxivermittlungszentrale, wird aber außerhalb des Systems implementiert.

Gern wird die UML von der Industrie als Allheilmittel für die Beschreibung von Softwaresystemen be- worben. Im Projektalltag indes stößt ihre Notation im- mer 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.

Hier lesen Sie …

• warum UML-Profile nötig sind;

• wie sie sich einsetzen lassen;

• welche Rolle Stereotypen dabei spielen können;

• welchen Mehraufwand sie nach sich ziehen.

Regeln zum Erstellen von Profilen

Ein UML-Profil

• darf der semantischen Bedeutung der existierenden UML-Elemente nicht widersprechen;

• darf nur die Erweiterungsmechanismen Stereotype und Constraint nutzen;

• muss selbst ein austauschbares UML-Modell sein (Organisation der Stereotypen in Paketen und vollständige Definition von Profilabhängigkeiten etc.);

• soll bestehende relevante Elemente auflisten (zum Beispiel Bibliotheken, Typdefinitionen und Modelle);

• soll die Verknüpfung von Profilen zu einem neuen Profil berücksichtigen;

• soll formal definierte Tagged Values (Attribute der Stereotypen) enthalten (Typ, Wert, Beschreibung, eventuell mathematische Operationen);

• kann Regelungen zur grafischen Darstellung von Stereotypen enthalten;

• soll unabhängig von dem Modell sein, auf das es angewandt wird, das heißt, es soll dynamisch austauschen und mehrfach wiederverwenden lassen.

Verfügbare Profile (Auswahl)

Für ihre tägliche Arbeit können Anwender Profile selbst erstellen oder auf eine Reihe von weiterführenden Profilen zurückgreifen. Nachfolgend sind einige Beispiele angegeben, die sowohl auf Besonderheiten eines Anwendungsgebiets als auch auf die ein- gesetzten Techniken eingehen.

• UML Profile for Corba/Corba Component Model (CCM);

• UML Profile for Enterprise Application Integration (EAI);

• UML Profile for Enterprise Distributed Object Computing (EDOC);

• UML Profile for QoS and Fault Tolerance;

• UML Profile for Schedulability, Performance, and Time;

• UML Testing Profile;

• spezielle Typen von Systemen, beispielsweise Profile für eingebettete oder für Hardwaresysteme;

• spezielle Techniken und Implementierungssprachen wie zum Beispiel UML-Profile für .NET oder Programmiersprachen (C++, Java);

• spezielle Methoden und Vorgehensmodelle, beispielsweise zur Unterstützung der Model Driven Architecture (MDA) oder zur Abbildung von Vorgehensmodellen (RUP, V-Modell).

Mehr zum Thema

www.computerwoche.de/go/

554981: (Eclipse-UML);

535665: (UML 2.0).

Weiterführende Informationen zu UML und Profilen: www.uml.org.

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 Analyse- phase immer wiederkehrende Eigenschaften mit ihnen präzi- se 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. (as)