<< zurück

MBSE Home

weiter >>

2.5 Stereotypen und Merkmale

Obwohl die UML als graphische Sprache für den Einsatz bei der Softwareentwicklung gedacht ist, hat sie eine Reihe von Eigenschaften mit natürlichen Sprachen gemeinsam. Die UML besitzt ein Grundgerüst, das einer Grammatik entspricht und dessen Aussagen in Form von Diagrammen gebildet werden. Ähnlich den natürlichen Sprachen gibt es Mechanismen, um das Sprachvokabular entsprechend den jeweils erforderlichen Bedürfnissen zu erweitern und anzupassen. Diese Mechanismen bilden die Grundlage für projekt- und unternehmensspezifische Dialekte bzw. Profile der UML.

Bereits die Einführung einer neuen Klasse erweitert das zur Verfügung stehende Vokabular, denn es erlaubt, diese Klasse an anderen Stellen zu nutzen. Von diesem Blickwinkel aus gesehen ist die Tätigkeit des Programmierens eine stetige Erweiterung des im System zur Verfügung stehenden Vokabulars. Während jedoch in einer Programmiersprache die Einführung einer neuen Kontrollstruktur nicht möglich ist, erlaubt die UML in restringierter Form die Einführung neuer Arten von Modellelementen, indem sie Stereotypen und Merkmale anbietet, mit denen vorhandene Modellelemente spezialisiert und angepasst werden können (siehe Abbildung 2.16).

Ohne einen expliziten Mechanismus dafür anzugeben, erlaubt die UML einerseits das syntaktische Aussehen durch Einschränkung oder Erweiterung der Sprache zu modifizieren andererseits aber auch die Bedeutung der Sprache zu verändern. Da die UML als „universelle“ Sprache konzipiert ist, ist je nach Einsatzform eine gewisse Bandbreite ihrer Bedeutung sinnvoll. Sogenannte „semantische Variabilität“ [Grö10] erlaubt die projektspezifische Anpassung der Bedeutung und der Werkzeuge. „Semantische Variationspunkte“ sind in der Standard-UML selbst nicht beschreibbar, weshalb in [GRR10, CGR09] dafür ein eigenständiger Mechanismus auf Basis von Featurediagrammen definiert ist und zur Profilbildung eingesetzt werden kann. Die allgemein möglichen Veränderungen gehen weit über das hier vorgestellte Konzept der Stereotypen und Merkmale hinaus.

In den vorangegangenen Beispielen dieses Kapitels wurden bereits vereinzelt Stereotypen, Merkmale⁴ und verwandte Mechanismen verwendet. In der in Abbildung 2.3 dargestellten Klasse wurden die Sichtbarkeitsangaben „+“, „#“, „?“ und „-“ eingeführt. Abbildung 2.13 zeigt die beiden Repräsentationsindikatoren „©“ und „… “, die sich auf die Repräsentation einer Sicht des Modells beziehen. Abbildung 2.6 zeigt den Stereotyp ≪interface≫, der eine „besondere“ Klasse, nämlich ein Interface kennzeichnet. Die Merkmale {ordered}, {frozen} und {addOnly} dienen schließlich zur Kennzeichnung von Assoziationsenden, wie das Beispiel 2.11 zeigt.

2.5.1 Stereotypen

Abbildung 2.17 zeigt drei Arten von Stereotypen. Während der Stereotyp ≪interface≫ standardmäßig von der UML zur Verfügung gestellt wird, sind die beiden rechten Stereotypen ≪JavaBean≫ und ≪Message≫ in einem Projekt, Werkzeug oder Framework selbst zu definieren.

Stereotypen werden standardmäßig in französischen Anführungszeichen (Guillemots) mit umgekehrten Spitzen angegeben. Im Prinzip kann jedes UML-Modellelement mit einem oder mehreren Stereotypen versehen werden. Meistens jedoch werden Stereotypen für Klassen verwendet, um ihnen spezialisierte Eigenschaften zuzuordnen.

Der Stereotyp ≪interface≫ markiert ein Interface, das als Sonderform der Klasse gilt. Der Stereotyp ≪JavaBean≫ wirkt als Indikator dafür, dass die markierte Klasse die von JavaBeans geforderte Funktionalität zur Verfügung stellt. Der Stereotyp ≪Message≫ wird im Auktionsprojekt verwendet, um in kompakter Form festzuhalten, dass die markierte Klasse eine Unterklasse von Message ist und damit der Nachrichtenübermittlung dient.

Stereotypen haben also eine Reihe verschiedener Anwendungsmöglichkeiten. Sie können Modellelemente klassifizieren, um ihnen beispielsweise zusätzliche Eigenschaften oder Funktionalitäten zuzuordnen oder Einschränkungen aufzuerlegen. Der UML-Standard bietet einen Metamodell-basierten und einen tabellarischen Ansatz zur informellen Definition von Stereotypen. Je nach Intention eines Stereotyps können einschränkende Bedingungen jedoch auch präziser formuliert oder nur Mechanismen für eine spezifische Umsetzung in Code angegeben werden. Folgende Liste zeigt einige der Verwendungsmöglichkeiten für Stereotypen:

• Ein Stereotyp beschreibt die syntaktischen Eigenschaften eines Modellelements, indem es zusätzliche Eigenschaften fordert oder vorhandene Eigenschaften spezialisiert.
• Ein Stereotyp kann die Form der Repräsentation eines Modells in der dem Benutzer zur Verfügung gestellten Sicht beschreiben. Der Indikator „©“ kann als eine solche spezielle Form angesehen werden.
• Ein Stereotyp kann anwendungsspezifische Anforderungen beschreiben. Zum Beispiel kann ≪persistent≫ charakterisieren, dass die Objekte dieser Klasse speicherbar sind. Jedoch wird nicht beschrieben, wie diese Speicherung vorzunehmen ist.
• Ein Stereotyp kann eine methodische Beziehung zwischen Modellelementen beschreiben. Dazu ist beispielsweise der im UML-Standard definierte Stereotyp ≪refine≫ gedacht.
• Ein Stereotyp kann die Intention des Modellierers widerspiegeln, die beschreibt, wie ein Programmierer ein Modellelement einsetzen sollte. Zum Beispiel kann eine Klasse als ≪adaptiv≫ markiert sein, um anzudeuten, dass es sich um einen guten Kandidaten für eine Erweiterung handelt. Solche Stereotypen sind speziell für Frameworks geeignet (siehe [FPR01]). Mit Stereotypen der Form ≪Wrapper≫ kann beispielsweise die Rolle einer Klasse in einem Entwurfsmuster dokumentiert werden.

Natürlich gibt es eine Reihe von Überlappungen zwischen den genannten und weiteren Anwendungsmöglichkeiten für Stereotypen.

Für eine weitere Detaillierung von Eigenschaften kann ein Stereotyp mit einer Menge von Merkmalen versehen sein. Die Anwendung eines Stereotyps auf ein Modellelement impliziert dann, dass die ihm zugeordneten Merkmale auf dem Modellelement ebenfalls definiert sind.

2.5.2 Merkmale

Abbildung 2.18 zeigt eine durch einen entsprechenden Stereotypen markierte Testklasse des Auktionssystems, bei der Informationen über den dargestellten Test und seine Ausführung in Form von Merkmalen gespeichert werden.

Merkmale können grundsätzlich an jedes Modellelement angefügt werden. Zusätzlich können Merkmale, wie in Abbildung 2.18 gezeigt, an einen Stereotyp gebunden und dadurch gemeinsam mit dem Stereotyp bei Modellelementen angewandt werden. Im Anwendungsbeispiel wird durch die Verwendung des Stereotyps ≪Testclass≫ die Existenz der letzten drei Merkmale gefordert, da im Auktionsprojekt diese drei Merkmale dem Stereotyp zugeordnet sind.

Ein Merkmal wird normalerweise in der Form {name = wert} notiert. Als Wertebereiche stehen grundsätzlich Zeichenreihen und Zahlen zur Verfügung. Eine explizite Typisierung der Merkmalswerte wäre wünschenswert, wird aber heute weder durch den UML-Sprachstandard noch durch Werkzeuge unterstützt. Spielt der Wert keine Rolle, oder handelt es sich um den booleschen Wert true, so kann dieser auch weggelassen werden. Zum Beispiel sind {sind_Tests_OK = true } und {sind_Tests_OK} zwei alternative Darstellungen. Der UML-Standard [OMG10a] bietet Merkmale wie {ordered} für Assoziationen standardmäßig an, erlaubt aber auch situationsspezifisch neue Merkmale zu definieren.

Auch wenn ein Merkmal einer Klasse zugeordnet wurde, unterscheidet es sich grundlegend von einem Attribut. Ein Merkmal ordnet dem Modellelement eine Eigenschaft zu, während ein Attribut bei jeder Instanz einer Klasse einen eigenständigen Wert hat. Attribute treten zur „Laufzeit“ eines Systems auf, während Merkmale dort nicht existieren. Dennoch können Merkmale Auswirkungen auf das System haben, wenn sie Eigenschaften des Modellelements in Bezug auf dessen Implementierung beeinflussen. Merkmale eignen sich unter anderem zur Darstellung folgender Eigenschaften:

• Der Initialwert eines Attributs kann so festgelegt werden.
• Abbildung 2.18 zeigt wie Projektinformationen in Form von Merkmalen dargestellt werden. Dazu gehören der Name des Erzeugers einer Klasse, das Erstellungsdatum, das Datum der letzten Änderung, die aktuelle Versionsnummer und ähnliches mehr.
• Informelle Kommentare können durch Merkmale dargestellt werden.
• Vorgesehene Techniken für Speicherung oder den Transfer der Daten über ein Netzwerk können so beispielsweise im Modell abgelegt werden.
• Für die graphische Darstellung in einem Werkzeug kann einem Modellelement ein geeignetes graphisches Symbol zugeordnet werden, dessen Dateiname im Merkmal abgelegt wird.

2.5.3 Einführung neuer Elemente

Die Vielfalt der Verwendungsmöglichkeiten für Stereotypen und Merkmale macht es nahezu unmöglich, eine Beschreibung der Bedeutung eines solchen Elements direkt mit der UML vorzunehmen. Bei der Definition eines Merkmals oder Stereotyps wird daher normalerweise eine informelle Beschreibung angegeben. Dadurch werden nicht nur das konkrete Aussehen, sondern vor allem auch die Intention und Einsatzgebiete beschrieben.

Der wichtigste Grund für die Einführung eines Stereotyps ist der methodische, werkzeugunterstützte Umgang während der Softwareentwicklung. Da für Stereotypen viele unterschiedliche Einsatzmöglichkeiten bestehen, die von der Steuerung der Codegenerierung bis hin zur Dokumentation von unfertigen Baustellen im Modell reichen, kann im Allgemeinen wenig über die Bedeutung von Stereotypen gesagt werden. Deshalb wird in der Tabelle 2.19 nur ein allgemeiner Notationsvorschlag für Stereotyp-Definitionen angegeben, der für konkrete Aufgabenstellungen und durch geeignete Werkzeuge jeweils angepasst und erweitert werden kann.

Die Definition eines Stereotyps folgt der allgemeinen Form der Entwurfsmuster [GHJV94], der Rezepte [FPR01] und der Prozessmuster [Amb98], indem sie auf informeller Basis Motivation, Voraussetzungen, Anwendungsform und Auswirkungen diskutiert. Diese Schablone sollte aber nicht als starre Form verstanden werden, sondern bei Bedarf um geeignete Abschnitte erweitert oder unnötige Abschnitte gekürzt werden.

Für Merkmale kann im Prinzip dieselbe Schablone verwendet werden. Merkmale sind jedoch im Allgemeinen einfacher strukturiert und verständlich, so dass eine derart detaillierte Schablone oft unnötig erscheint.

Die UML bietet eine dritte Form von Anpassungen für Modellelemente an. Bedingungen (engl.: constraints) sind ein Instrument zur detaillierten Spezifikation von Eigenschaften. Als Bedingungssprachen werden die im Kapitel 3 eingeführte OCL oder informeller Text vorgeschlagen. Eine Bedingung wird grundsätzlich in der Form {Bedingung} dargestellt. Der UML-Standard bietet standardmäßig einige Bedingungen an. Darunter ist die bereits bekannte Bedingung {ordered} für Assoziationen, die jedoch auch als Merkmal mit booleschen Wertebereich definiert werden kann. Insbesondere an diesem Beispiel ist zu sehen, dass die Unterschiede zwischen Bedingungen, Merkmalen und Stereotypen nicht immer zweifelsfrei geklärt werden können. So ist es auch nur wenig sinnvoll, einen Stereotyp einzuführen, der genau aus einem Merkmal besteht, weil dieses Merkmal auch direkt an ein Modellelement angefügt werden kann. Bei der Einführung neuer Stereotypen, Merkmale oder Bedingungen sind daher gewisse gestalterische Freiheiten gegeben, die von einem Modellierer genutzt werden können, um ein geeignetes Modell zu entwerfen.

Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012

<< zurück

MBSE Home

weiter >>