Beziehungen im Metamodell auflösen
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 ersten Schritten zur Modellierung im zweiten Teil der Blogserie beleuchten wir heute, wie Sie Beziehungen im Metamodell von objectiF RPM auflösen.
Um Viele:Viele-Beziehungen im Metamodell des Tools aufzulösen, verwenden wir spezielle Konventionen, die Sie ebenfalls einhalten sollten. Gehen Sie wie folgt vor:
- Stellen Sie die Frage: Kann es in den beiden in Beziehung stehenden Klassen – hier also Requirement und Risk – Instanzen geben, die auch ohne Beziehung zu einer Instanz der jeweils anderen Klassen semantisch sinnvoll sind? Die Antwort lautet in unserem Beispiel: Ein Requirement (genauer eine Instanz der Klasse Requirement) wird man in der Regel anlegen, ohne ihm gleich ein Risk (eine Instanz der Klasse Risk) zuzuordnen. Es wird sicher auch Requirements geben, für die eine Risikobetrachtung unnötig ist. Umgekehrt: Eine Risikobetrachtung braucht immer einen Gegenstand, auf das sie sich bezieht. Risks wird man immer in Hinblick auf ein oder mehrere vorhandene Requirements identifizieren.
Wir bezeichnen die – in diesem semantischen Sinne – unabhängige Klasse, nämlich Requirement, als Target (d.h. als das Ziel, auf das sich die abhängige Klasse bezieht). Die abhängige Klasse – hier also Risk – nennen wir, weil sie die Quelle der semantischen Abhängigkeit darstellt, Source. - Legen Sie im Ordner Metamodelle/Beziehungstypen jetzt die Klasse an, mit der die Viele:Viele-Beziehung auflöst werden soll. Benennen Sie diese Beziehungsklasse nach dem Schema: TargetSourceRship.
In unserem Beispiel heißt die Beziehungsklasse also RequirementRiskRship.
Ziehen Sie die Beziehungsklasse in das Klassendiagramm. - Zeichnen Sie in das Klassendiagramm die beiden 1:Viele-Beziehungen ein, die die Viele:Viele-Beziehung zwischen Requirement und Risk ersetzen. Dafür gelten die folgende Konventionen:
Zwischen der Source-Klasse und der Beziehungsklasse wird eine Komposition angelegt.
Die Komposition ist eine starke Beziehung. Sie drückt aus, dass eine Instanz der Source-Klasse ohne mindestens eine in Beziehung stehende Instanz der Target-Klasse semantisch keinen Sinn ergibt.
Diese Modellierung hat auch in technischer Hinsicht Auswirkungen: Wenn Sie zum Beispiel eine Revision einer Instanz der Source-Klasse anlegen, werden die zugehörigen Instanzen der Target-Klasse versioniert und beim Wiederherstellen – falls es dann notwendig wird – ebenfalls wieder in den früheren Bearbeitungsstand zurückversetzt.
Zwischen der Target-Klasse und der Beziehungsklasse wird eine Assoziation angelegt.
Die Assoziation ist eine schwächere Form der Beziehung. Sie wird gewählt, um auszudrücken, dass eine Instanz der Target-Klasse semantisch sinnvoll ist, ohne eine Beziehung zu einer Instanz der Source-Klasse zu besitzen. Auch hier gibt es technische Auswirkungen. Ein Beispiel dafür ist der Datenaustausch mit anderen Projekten per Export/Import. Dabei werden „grüne“ Beziehungen, also Assoziationen, gekappt.
Wenn Sie also einem anderen Projekt Ihre Requirements zur Verfügung stellen wollen, dann werden beim Export die zugehörigen Instanzen von Risk nicht mitgenommen. Das inhaltlich durchaus gerechtfertigt, denn mit Ihren projektbezogenen Risiken kann ein fremdes Projekt im Allgemeinen wenig anfangen.
Ein kleiner Hinweis: Die Elemente, die objectiF RPM kennt, haben vielfältige Beziehungen zueinander. Ohne die Regel, Assoziation beim Export zu kappen, würde ein Export der Requirements aus einem Projekt dazu führen, dass große Teile des Datenbestandes des Projekts mit exportiert würden. Will man nur Requirements austauschen, ist das nicht die erwünschte Wirkung.
Nachfolgende Abbildung zeigt das bisher entstandene Datenmodell und fasst die bei der Modellierung verwendeten Konventionen zusammen:
Bisher entstandenes Datenmodell mit den verwendeten Konventionen
Für die Beziehung zwischen Risk und WorkPackage gilt: Risk ist hier die Target-Klasse, denn ein Risk kann man erkennen und beschreiben, ohne gleich über Maßnahmen zur Abwehr nachzudenken, also ohne ein WorkPackage anzulegen und zuzuordnen. Abwehrmaßnahmen, also WorkPackages zu planen, ohne zuvor ein Risk erkannt zu haben, ergibt wenig Sinn. WorkPackage ist in dieser Beziehung also die Source-Klasse. Die hier für die Auflösung der Viele:Viele-Beziehung benötigte Beziehungsklasse heißt dann der Konvention entsprechend RiskWorkPackageRship.
Das Datenmodell für die Erweiterung von objectiF RPM sieht jetzt so aus:
Das Datenmodell bis hier hin
Im nächsten Teil der Blogserie erfahren Sie, wie Attribute und Referenz-Attribute angelegt werden. Haben Sie Fragen zur Modellierung der Beziehungen im Metamodell, 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.
Diskutieren Sie mit und hinterlassen Sie einen Kommentar.