Eigene Artefakttypen definieren
Wenn im Lebenszyklus Ihrer Produkte und Systeme Artefakte entstehen, die objectiF RPM standardmäßig nicht „kennt“, dann können Sie eigene Artefakttypen definieren. Der Lohn der Arbeit: Mit den selbst definierten Artefakten arbeiten Sie genauso wie mit denen, die objectiF RPM bereits mitbringt. Auch für Ihre eigenen Artefakte können Sie Revisionen und Varianten anlegen, sich die Historie anzeigen lassen und Auswertungen definieren. Sie können sie mit anderen teilen und zwischen Projekten austauschen. Auch in Ihre MS-Word Dokumente können Sie Ihre eigenen Artefakte einfügen. Wie sie bei der Definition von eigenen Artefakttypen am besten vorgehen, wollen wir Ihnen in einer Blogreihe vorstellen. Beginnen wir heute mit einigen, sehr wichtigen, grundsätzlichen Überlegungen.
Eigene, organisationsweite Artefakttypen
Sollen die eigenen Artefakttypen nicht nur in einem einzelnen, sondern allen Projekten der Organisation zur Verfügung stehen, dann führen Sie Ihre Erweiterungen bitte in einer Projektvorlage durch. Es bietet sich an, die Vorlage für ein agiles, skalierbares Projekt als Basis zu verwenden, die Sie standardmäßig in objectiF RPM vorfinden. So können Sie den Mustern, Auswertungen, Sichten, Dokumenten etc. profitieren, die darin bereits definiert sind. Und sicher ist sicher: Um Ihre Ideen auszuprobieren und ihre Lösungen zu testen, benutzen Sie am besten ein Übungsprojekt.
Wenn Sie eine Projektvorlage um eigene Artefakttypen erweitern, sollten Sie mit großer Sorgfalt vorgehen. Idealerweise machen Sie Ihre Schritte nachvollziehbar. Denn die Erweiterungen, die Sie an einer Projektvorlage vornehmen, werden ja in allen Projekten wirksam, die damit eingerichtet werden.
Wir empfehlen Ihnen deshalb,
- für die geplanten neuen Artefakttypen und ihre Beziehungen eine „Mini-Datenanalyse“ durchzuführen und das Ergebnis als Klassendiagramm in der Projektvorlage festzuhalten,
- dann erst die Artefakttypen anzulegen und
- das Verhalten der Artefakte mit einem Zustandsdiagramm zu beschreiben.
Die Erweiterung des Risikomanagements
Wie das geht, wollen wir Ihnen gerne am Beispiel „Risikomanagement“ zeigen. Stellen Sie sich vor, dass das Risikomanagement in Ihren Projekten einen besonders hohen Stellenwert besitzt und Ihnen die vorhandenen Möglichkeiten, Risiken zu definieren und zu überwachen nicht ausreichen, dann können Sie sich selbst die benötigten Mittel schaffen, indem Sie:
- das Metamodell, das das Tool mitbringt, um einen Artefakttyp für Risiken erweitern und seine Eigenschaften festlegen,
- das Verhalten eines Risikos bestehend aus seinen möglichen Zuständen und Zustandsübergängen beschreiben. Soll zum Beispiel beim Eintritt in einen Zustand automatisch eine Revision erzeugt oder jemand benachrichtigt werden?
- Beziehungen zwischen dem neuen Artefakttyp für Risiken und vorhandenen Artefakttypen definieren.
In der Vorlage für ein agiles, skalierbares Projekt sind die Ergebnisse, die im Rahmen dieses Beispiel zu erstellen sind, bereits weitgehend enthalten. Sie können sich einerseits daran also bei der Entwicklung eigener Artefakttypen orientieren. Anderseits können Sie sie auch ändern und spezifisch ausprägen, sodass Sie in jedem mit der Vorlage erstellen Projekt mit Risiken arbeiten können.
Wenn Sie eigene Artefakttypen benötigen, sollten Sie analysieren, ob sie in Beziehung zueinander oder zu bereits vorhandenen Artefakttypen stehen. Ist das der Fall, dann müssen Sie entscheiden, ob Sie die erkannten Beziehungen auch tatsächlich nutzen wollen – zum Beispiel im Rahmen von Abfragen. Diese Überlegungen stellen im Kern nichts anderes dar als eine Datenanalyse für einen begrenzten Scope.
Die Dokumentation der Datenanalyse
Wir empfehlen, das Ergebnis dieser „Mini“-Datenanalyse als Datenmodell zu dokumentieren und dazu Klassendiagramme der UML zu verwenden. objectiF RPM basiert auf einem Metamodell nach OMG-Standard Meta Object Facility (MOF). Das Metamodell ist ebenfalls mit Klassendiagrammen beschrieben. Sie dienen als Basis für die modellgetriebene Weiterentwicklung des Tools unter Einsatz von Modelltransformationen. Die neuen Artefakttypen bilden Sie darin als Klassen mit Beziehungen ab. Klassendiagramme haben in diesem Kontext gegenüber anderen Modellierungstechniken einige Vorteile: Sie müssen sich unter anderem nicht mit der Identifizierbarkeit der Artefakte beschäftigen, wie es z.B. beim Einsatz von Entity-Relationship-Modellen (ERM) erforderlich wäre. Im ERM ist ein eindeutiges Identifizieren nur mit einem Schlüsselattribut möglich. Alle Artefakte, auch die benutzereigenen erben Verhalten und Attribute von der „eingebauten“ abstrakten Klasse Element. Deshalb ist es nicht erforderlich, ein identifizierendes Attribut zu definieren. Ein Attribut Name müssen Sie ebenfalls nicht anlegen. Und um die Versionierbarkeit der Artefakte müssen Sie sich auch nicht kümmern. Das alles gehört zum „Erbe“ von Element.
Modellierungskonventionen für die Erweiterung um benutzereigene Artefakttypen
Bitte beachten Sie, dass die Klassen in den zu entwickelnden Klassendiagrammen die neuen Artefakttypen lediglich grafisch repräsentieren. Um die Erweiterungen zu realisieren, müssen Sie die Artefakttypen in einem weiteren Schritt explizit anlegen und im Detail definieren. Also doppelte Arbeit? Keineswegs. Die Modellierung der geplanten Erweiterungen in Form von Klassendiagrammen lohnt sich, denn sie schafft gedankliche Klarheit und liefert gleichzeitig eine grafische Dokumentation der Ihrer Lösung.
Wie Sie den neuen Artefakttypen modellieren, definieren und das Verhalten der Artefakte des neuen Typs festlegen, Formulare mit dem neuen objectiF RPM Formulardesigner für die eigenen Artefakttypen entwickeln, Auswertungen erzeugen und mit benutzerdefinierten Artefakten und Formularen arbeiten, darum wird es in unserer Blogreihe gehen. Im nächsten Beitrag geht es um die Modellierung eigener Artefakte. Machen Sie einfach mit und erweitern Sie objectiF RPM passend zu Ihrer Situation.
Haben Sie bereits Fragen oder Anmerkungen zu den grundsätzlichen Überlegungen beim Arbeiten mit benutzerdefinierten Artefakttypen? 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.