Attribute und Referenz-Attribute anlegen
Wenn im Lebenszyklus Ihrer Produkte und Systeme Artefakte entstehen, die objectiF RPM standardmäßig nicht „kennt“, dann können Sie eigene Artefakttypen definieren. Nachdem Sie im dritten Teil der Blogserie Beziehungen im Metamodell von objectiF RPM modelliert haben, beschreiben wir heute das Anlegen von Attributen und Referenz-Attributen.
Was soll mit dem neuen Artefakttyp Risk erreicht werden? Die Projektteams haben Ihnen mit auf den Weg gegeben, dass es möglich sein soll, Risiken zu beschreiben und zu klassifizieren. Außerdem soll jedes Risiko bezogen auf seine Eintrittswahrscheinlichkeit, den möglichen Schaden und seine Priorität bewertet werden können. Aus Sicht der Datenmodellierung bedeutet das: Die Klasse Risk soll eine Reihe von Eigenschaften besitzen. Sie sollten sie als Attribute der Klasse im Modell festhalten.
Die Klasse Risk mit Attributen
Konkret bedeutet das: Um den Forderungen der Projektteams zu entsprechen, definieren Sie folgende Attribute: RiskDescription, RiskType, OccurenceProbability, EstimatedDamage und RiskPriority. Die Attribute können Sie direkt im Klassendiagramm eingeben. Verwenden Sie dazu im Kontextmenü der Klasse Risk den Befehl Komponenten anlegen/Attribut. Wählen Sie möglichst sprechende Namen. Wenn ein Name dennoch nicht selbsterklärend ist, können Sie zu dem Attribut eine kurze Erklärung hinterlegen. Jedes Attribut können Sie dabei gleich technisch deklarieren. Sie können aber auch einfach in das Deklationsfeld klicken (oder auf ein anderes Formularelement). Dann wird eine Defaultdeklaration der Form object Attributname erzeugt. Klicken Sie auf das kleine Dreieck in der rechten unteren Ecke des Klassensymbols, um es aufzuklappen. So sehen Sie die Attribute – wie in obiger Abbildung – direkt im Diagramm.
Vermissen Sie beim Blick auf die Attribute etwas? Wäre es nicht nützlich, zu einem Risiko auch den Autor festzuhalten, der das Risiko erkannt und die Eintrittswahrscheinlichkeit sowie den möglichen Schaden geschätzt hat? Er muss ja nicht unbedingt mit dem Bearbeiter identisch sein. Also einfach ein weiteres Attribut hinzufügen? Nein, es gibt eine bessere Lösung. Der Autor kann ja nur jemand sein, der am Projekt beteiligt ist, also den das Tool „kennt“. Wenn Sie in die Liste der Stereotypen schauen, finden Sie darin «ProjectUser». Dieser „eingebaute“ Artefakttyp wird von Tool zur Speicherung der Projektbeteiligten verwendet. Statt einen Attribut anzulegen, stellen Sie eine Beziehung zu ProjectUser her, sodass Sie in einem Risiko seinen „Erfinder“ referenzieren können. Wir sprechen hier von einem Referenzattribut.
Eine passende Klasse ProjectUser ist als Modellierungshilfe im Ordner Metamodell/
Entitytypen vorhanden. Ziehen Sie diese Klassen in das Diagramm. Stellen Sie dann eine einfache Beziehung – genauer eine Assoziation – zu ProjektUser her.
Das fertige Modell sieht dann so aus:
Das fertiggestellte Modell mit einer Assoziation zu ProjektUser
Wir haben Ihnen empfohlen, alle neuen Artefakttypen als Klassen mit Beziehungen in Klassendiagrammen zu modellieren, bevor Sie sie definieren und damit quasi realisieren. Die Klassen müssen aber im Modell keineswegs vollständig mit Attributen beschrieben sein. Für die Definition der Klassen reichen einige typische Attribute aus. Für Beziehungsklassen brauchen Sie sich über Attribute kaum Gedanken zu machen, denn sie besitzen nur selten explizite Eigenschaften. Es ist auch nicht nötig, dass Sie sich bei der Modellierung schon auf Typ oder Wertebereich der Attribute festlegen. Wir schlagen Ihnen vor, nur die wichtigsten Attribute im Modell festzuhalten. Das Ziel dabei ist es, zu prüfen, ob eine Klasse – und damit ein neuer Artefakttyp – semantisch eine Einheit darstellt oder nur eine kontextarme Sammlung von Eigenschaften ist. Benutzen Sie die Attribute also im Sinne eines Proof of Concept für Ihre Artefakttypen.
Warum ist ein Proof of Concept wichtig? Wenn Sie Artefakttypen anlegen, deren Bedeutung nicht eindeutig definiert ist, deren Beziehungen nicht gründlich durchdacht sind und die nicht den Konventionen der Modellierung entsprechen, werden Sie bei der Entwicklung der Formulare, also der Benutzeroberfläche Ihrer Artefakte sowie bei der Definition von Auswertung Probleme haben und sich möglicherweise Doppelarbeit einhandeln. Hingegen ist es sogar zu erwarten, dass Ihnen bei der Gestaltung der Formulare weitere Attribute zu Ihren Artefakttypen einfallen. Das ist kein Problem: Eigenschaften eines Artefakttyps können Sie, während Sie die Benutzeroberfläche entwickeln, jederzeit einfügen und natürlich auch löschen. Sie können also zwischen der Definition eines Artefakttyps und der Entwicklung der zugehörigen Benutzeroberfläche beliebig oft iterieren.
Im nächsten Teil der Blogserie erfahren Sie, wie die modellierten Artefakttypen realisiert werden. Haben Sie Fragen zum Anlegen von Attributen und Referenz-Attributen, 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.