Eigene Artefakttypen modellieren

Wenn im Lebenszyklus Ihrer Produkte und Systeme Artefakte entstehen, die objectiF RPM standardmäßig nicht „kennt“, dann können Sie eigene Artefakttypen definieren. Nach den grundsätzlichen Überlegungen im ersten Teil der Blogserie beleuchten wir heute die Modellierung von Artefakttypen.

Das vorbereitete Package

Für die Ergebnisse der Modellierung finden Sie in objectiF RPM in der Vorlage für ein agiles, skalierbares Projekt das vorbereitete Package (also den Ordner) Metamodell. Dieses Package enthält mehrere Sub-Packages:

• Entitytypen für die Klassen, mit denen Sie benutzereigene Arte­fakt­typen modellieren,
• Beziehungstypen für die Klassen, mit denen Sie die Beziehungen zwischen den Artefakttypen abbilden,
• Klassen­diagramme für die Diagramme, die die Zusammenhänge zwischen den definierten Klassen grafisch darstellen,
• Modellierungs­konzepte. Hier finden Sie ein Klassen­diagramm, das Ihnen eine Hilfestellung für die Modellierung bietet. Wir gehen darauf noch detailliert ein.

Diese Sub-Packages sind nicht leer. Entitytypen und Beziehungstypen ent­halten bereits eine Reihe von Klassen. Sie repräsentieren vorhandene Artefakt­typen, die häufig im Kontext von Erweiterungen vorkommen.

Package-Hierarchie zur Ablage der Ergebnisse, die bei der Modellierung von benutzereigenen Artefakttypen entstehen.

Ein Blick in diese beiden Packages zeigt: Die Metamodellelemente von objectiF RPM tragen englische Namen. Um die Einheitlichkeit des Metamodells zu bewahren, sollten Sie Ihre eigenen Artefakttypen und die Klassen, mit denen Sie sie darstellen, ebenfalls englisch be­zeichnen.

Das Beispiel: Risikomanagement

Wie Sie eigene Artefakttypen modellieren und dabei die vorbereitete Package-Hierarchie nutzen, betrachten wir nun am Beispiel Risikomanagement. Versetzen Sie sich in die Rolle des Tool- und Methodenverantwortlichen einer Organisation. Einige Projektteams kommen mit der Forderung auf Sie zu, objectiF RPM um einen Artefakttyp zu erweitern, mit dem Risiken beschrieben werden können. Die Begründung der Teams: Standard­mäßig kann man zwar auf dem Anforderungsformular eine Risikobeschreibung eingeben – aber eben nur eine. Die Projektteams wollen aber die Möglichkeit haben, zu einer Anforderung mehrere Risiken fest­zuhalten. Jedes Risiko soll beschrieben, klassifiziert und in Hinsicht auf seine Eintrittswahr­schein­lichkeit, den möglichen Schaden und seine Priorität bewertet werden können. Die Pro­jekt­teams weisen darauf hin, dass sich ein Risiko auch auf mehrere Anforde­rungen beziehen kann. Das heißt: Zwischen Anforderung und Risiko besteht eine Viele:Viele-Beziehung.

Die Forderungen der Projektteams reichen noch weiter: Es soll auch möglich sein, Maßnahmen zur Verhinderung des Eintretens von Risiken oder doch wenigstens zur Schadens­begrenzung zu planen. Ein Projektverantwortlicher gibt zu bedenken, dass solche Maßnahmen in der Regel auf­wands­relevant sind. Schön wäre es also, wenn die Maßnahmen auch in der Projekt­planung – zum Beispiel im Gantt Chart – als Aktivitäten sichtbar wären. Auch hier gilt: Zwischen Risiken und Maßnahmen zur Verhinderung oder Schadensbegrenzung besteht eine Viele:Viele-Beziehung.

Benötigt wird also ein Artefakttyp, der nach den Konventionen von objectiF RPM als Risk bezeichnet wird.

Die Entwicklung des Datenmodells

Um ein Datenmodell zu entwickeln, dass als Basis für das Anlegen eines Artefakttyps Risk einschließlich seiner Beziehungen dienen kann, gehen Sie in folgenden Schritten vor:

1. Legen Sie in der Vorlage für ein agiles, skalierbares Projekt unter Einstellungen im Package Metamodelle/Entitytypen eine Klasse Risk an. Benutzen Sie dazu den Kontextmenübefehl Kom­po­nenten anlegen/Klasse. Mehr als einen Namen benötigt die Klasse, die den neuen Artefakttyp repräsentiert, zunächst nicht.
2. Prüfen Sie, ob die in objectiF RPM vorhandenen Artefakttypen, die mit Risk in einer Beziehung stehen, ebenfalls als Klassen im Package Entitytypen vorkommen. Sie benötigen diese Klassen, um die Beziehungen zu Risk im Klassendiagramm grafisch abzubilden. Welche Klassen sind das in diesem konkreten Fall? Um den genannten Forde­rungen der Projektteams gerecht zu werden, müssen Beziehungen zu zwei Artefakt­typen berücksichtigt werden, nämlich zu Anforderungen und Aktivitäten. Beide sind bereits als Klassen im Package Entitytypen abgebildet. Sie heißen dort Requirement und WorkPackage. Hier gibt es also nichts weiter zu tun. Was aber können Sie tun, wenn Sie im Package Entitytypen keine Klasse finden, die den benötigten vorhandenen Artefakttyp repräsentiert? Da es hier um das reine Modellieren geht, können Sie die Klasse einfach anlegen. Sie sollten dabei allerdings den Namen verwenden, den der Artefakttyp in objectiF RPM besitzt. Um den Namen zu ermitteln, schauen Sie in die Liste der Stereotypen nach. Speziell unter DomainElement sollten Sie fündig werden.
   

   Schauen Sie sich die bereits definierten Stereotypen an

3. Erzeugen Sie jetzt ein Klassendiagramm, um die Klassen und ihre Beziehungen zu modellieren. Legen Sie es im Package Metamodelle/Klassendiagramme an. Benutzen Sie dazu den Befehl Komponenten anlegen/Klassendiagramm. Unser Vor­schlag: Benennen Sie das neue Diagramm nach dem oder den Artefakttypen, die darin abgebildet werden sollen. In unserem Beispiel sind das Risks, Require­ments, WorkPackages. Ziehen Sie anschließend die Klassen Risk, Requirements und WorkPackage aus dem Package Entitytypen in das leere Diagramm. Das sieht dann so aus:
   

   Die Klassen Risk, Requirements und WorkPackage im Klassendiagramm

4. Modellieren Sie nun die Beziehungen zwischen den Klassen. Sowohl zwischen Risk und Requirement als auch zwischen Risk und WorkPackage existieren Viele:Viele-Beziehungen. Sie lassen sich im Klassendiagramm zwar durch Viele:Viele-Assoziationen abbilden. Wir lösen sie aber mit Hilfe einer Beziehungsklasse in zwei 1:Viele-Bezieh­ungen auf. Das macht man üblicherweise, wenn man Klassen des Modells auf Tabellen einer relationalen Datenbank abbilden will. Hier kommt ein anderer gewichtiger Grund hinzu: Wird eine Beziehung explizit durch eine Klasse abgebildet, dann kann man sie attributieren, also Eigenschaften für die Beziehung definieren. Ein Beispiel dafür ist die Beziehung zwischen Stakeholdern und Anforderungen, die Sie in Anforderungsdiarammen sogar grafisch darstellen können. Eine solche Beziehung kann ein Gewicht besitzen. Gewicht bzw. Weight ist ein Attribut der Klasse, die die Beziehung zwischen Stakeholder und Requirement realisiert. Sie heißt StakeholderReqInterestRelationship.

Um Viele:Viele-Beziehungen im Metamodell des Tools auf­zulösen, verwenden wir spezielle Konventionen, die Sie ebenfalls einhalten sollten. Wie Sie dies am besten machen, erfahren Sie in unserem nächsten Teil der Blogserie. Falls Sie bereits Fragen zur Modellierung von Artefakttypen haben, dann melden Sie sich bitte bei uns. Wie immer stehen wir unter service@microtool.de bzw. 030/467086-20 sehr gerne zur Verfügung.

Hinweis:

Alles Wichtige zu objectiF RPM auf einen Blick haben wir für Sie im objectiF RPM Whitepaper zusammengestellt.