Innovator 11 Spezialkonzepte der Modellierung Spezialkonzepte zum Verständnis der Modellzusammenhänge in Innovator for Business Analysts Oliver Pera KundenInfo www.mid.de
Inhaltsverzeichnis Spezialkonzepte zum Verständnis der Modellzusammenhänge... 2 Kurzbeschreibung... 2 Kontextabhängige Anpassung von Elementtypen... 2 Automatische Anpassung von Ereignissen... 2 Abhängigkeit des Ereignistyps von ein- und ausfließenden Kanten... 3 Abhängigkeit des Ereignistyps von zugeordneten Ereignisdefinitionen... 3 Automatische Anpassung von Tasks... 6 Anpassung des Task-Typs... 6 Anpassung der Implementation... 6 Automatische Anpassung von Gateways... 7 Zusammenhang zwischen Aufrufaktivität und aufgerufenem Prozesselement... 8 Idee... 8 Datenein- und -ausgaben verknüpfen... 8 Datenelementverbindung lösen... 9 Automatismen bzgl. Datenassoziationen und datentragenden Elementen... 9 Anomalie der Anzeige... 9 Datenassoziation zwischen datentragendem Element und Task/Ereignis... 9 Datenassoziation zwischen datentragendem Element und Teilprozess... 9 Automatismen beim Erzeugen einer Datenassoziation... 9 Automatismen beim Umhängen einer Datenassoziation... 10 Automatismen beim Löschen einer Datenassoziation... 10 Unterscheidung von Definition und Referenz... 10 Grundkonzept... 10 Visuelle Unterscheidbarkeit... 11 Modellieren in einer Referenz... 11 Abgleich von Referenzen mit der Definition... 12 Referenzen entfernen und Definition löschen... 12 Teilprozesse, Prozessaufrufe und Teilnehmer auf- und zuklappen... 12 Korrektheit von Referenzen... 13 1
Spezialkonzepte zum Verständnis der Modellzusammenhänge Kurzbeschreibung Diese KundenInfo enthält eine Beschreibung von Konzepten, Vorgehensweisen sowie spezieller Automatismen und Abhängigkeiten von Elementen in Innovator for Business Analysts. Innovator for Business Analysts kombiniert Modellierungssprachen aus verschiedenen Standards in einem rollenspezifischen Werkzeug, mit dem Business Analysten sowohl mit BPMN 2.0 als auch mit UML Geschäftsprozesse und Anforderungen für IT-Applikationen und SOA spezifizieren können. Kontextabhängige Anpassung von Elementtypen Die Eigenschaften bestimmter Elementtypen können durch Innovator automatisch gepflegt werden. Diese Pflege umfasst die Festlegung des Typs oder der Flussrichtung. Sie sichert vor allem die Modellkonsistenz, also die Richtigkeit der Eigenschaften im Kontext der konkreten Elementverwendung. Die Option der automatischen Pflege betrifft die Modellelemente Ereignis, Task und Gateway. Automatische Anpassung von Ereignissen Der Ereignistyp besitzt eine komplexe Kontextabhängigkeit. Aus diesem Grund empfiehlt es sich, für Ereignisknoten die Eigenschaft Innovator bestimmt Typ zu setzen, damit eine automatische Anpassung des Typs erfolgen kann. Es gibt folgende Ereignistypen: Startereignis Eingetretenes Zwischenereignis Ausgelöstes Zwischenereignis Angeheftetes Zwischenereignis Endereignis Folgende Faktoren bestimmen die Zulässigkeit des Ereignistyps: Zahl der ein- und ausfließenden Sequenzflüsse Zahl der ein- und ausfließenden Nachrichtenflüsse Zahl und Typ der zugeordneten Ereignisdefinitionen Zuordnung des Ereignisses zu einer Aktivität Ereigniseigenschaft ist unterbrechend Ereigniseigenschaft ist parallel mehrfach 2
Teilprozesseigenschaft wird angestoßen von Ereignis Teilprozesseigenschaft Teilprozess-Typ mit dem Wert Transaktion Abhängigkeit des Ereignistyps von ein- und ausfließenden Kanten Der Typ... Startereignis ist zulässig, wenn - das Ereignis völlig isoliert (neu angelegt) ist, - für das Ereignis keine Aktivitätszuordnung besteht, - aus dem Ereignis keine Nachrichtenflüsse hinausgehen und - in das Ereignis keine Sequenzflüsse hineingehen Endereignis ist zulässig, wenn - das Ereignis völlig isoliert (neu angelegt) ist, - für das Ereignis keine Aktivitätszuordnung besteht, - in das Ereignis keine Nachrichtenflüsse hineingehen und - aus dem Ereignis keine Sequenzflüsse herausgehen Eingetretenes Zwischenereignis 1 ist zulässig, wenn: - für das Ereignis keine Aktivitätszuordnung besteht und - aus dem Ereignis keine Nachrichtenflüsse hinausgehen Ausgelöstes Zwischenereignis 1 ist zulässig, wenn - für das Ereignis keine Aktivitätszuordnung besteht und - in das Ereignis keine Nachrichtenflüsse hineingehen Angeheftetes (eingetretenes) Zwischenereignis ist zulässig, wenn - für das Ereignis keine Aktivitätszuordnung besteht, - aus dem Ereignis keine Nachrichtenflüsse hinausgehen und - in das Ereignis keine Sequenzflüsse hineingehen Abhängigkeit des Ereignistyps von zugeordneten Ereignisdefinitionen Der Typ... Startereignis auf Toplevel-Ebene ist zulässig, wenn eine oder mehrere Ereignisdefinitionen mit folgenden Typen zugeordnet sind: - Blanko 1 Sequenzflüsse werden für diesen Typ nicht berücksichtigt, da Sie durch Vervollständigen der Sequenzflüsse auch noch nachträglich die Bedingung für Zwischenereignisse (mindestens je ein ein- und ausfließender Sequenzfluss) erfüllen können. 3
- Timer - Bedingung Startereignis für ein Ereignis in einem Teilprozess ohne Eigenschaft wird angestoßen von Ereignis ist zulässig, wenn keine oder nur eine Ereignisdefinitionen mit folgenden Typ zugeordnet ist: - Blanko Startereignis 2 für ein unterbrechendes Ereignis in einem Teilprozess mit der Eigenschaft wird angestoßen von Ereignis ist zulässig, wenn eine oder mehrere Ereignisdefinitionen mit folgenden Typen zugeordnet sind: - Timer - Fehler - Eskalation - Kompensation - Bedingung Startereignis² für ein nicht unterbrechendes Ereignis in einem Teilprozess mit der Eigenschaft wird angestoßen von Ereignis ist zulässig, wenn eine oder mehrere Ereignis- Typen zugeordnet sind: definitionen mit folgenden - Timer - Eskalation - Bedingung Eingetretenes Zwischenereignis ist zulässig, wenn eine oder mehrere Ereignisdefinitio- sind: nen mit folgenden Typen zugeordnet 3 - Blanko - Timer - Bedingung - Link 2 In einem Teilprozess mit der Eigenschaft wird angestoßen von Ereignis muss es genau ein Startereignis geben. 3 Abweichend von der BPMN-Spezifikation ist Blanko aus Bedienbarkeitsgründen zugelassen. 4
Angeheftetes (eingetretenes) Zwischenereignis für ein unterbrechendes Ereignis ist zulässig, wenn eine oder mehrere Ereignisdefinitionen mit folgenden Typen zugeordnet sind: - Blanko 3 oben - Timer - Fehler - Eskalation - Abbruch (ausschließlich an Teilprozess mit Typ Transaktion) - Kompensation - Bedingung Angeheftetes (eingetretenes) Zwischenereignis für ein nicht unterbrechendes Ereignis ist zulässig, wenn eine oder mehrere Ereignisdefinitionen mit folgenden Typen zugeord- - Timer net sind: - Blanko 3 oben - Eskalation - Bedingung Ausgelöstes Zwischenereignis für ein nicht parallel mehrfaches Ereignis, ist zulässig, wenn eine oder mehrere Ereignisdefinitionen mit folgenden Typen zugeordnet sind: - Blanko - Eskalation - Kompensation - Link Endereignis für ein nicht parallel mehrfaches Ereignis, ist zulässig, wenn eine oder mehrere Ereignisdefinitionen mit folgenden Typen zugeordnet sind: - Blanko - Fehler - Eskalation - Abbruch 5
- Kompensation - Terminierung Automatische Anpassung von Tasks Anpassung des Task-Typs Ordnet man bestimmte Elemente einem Task zu, so schränkt sich die Liste der möglichen Task- Werte möglich: Typen ein. Grundsätzlich sind folgende Aufruf-Aktivität Ohne Typ Senden Empfangen Service Benutzer Manuell Skript Geschäftsregel Bei zugeordneter Service-Operation ergeben sich folgende gültige Typen: Senden Empfangen Service Benutzer Die Zuweisung einer Nachricht schränkt die Liste der möglichen Typen wie folgt ein: Senden Empfangen Durch die Zuordnung eines aufrufbaren Prozesselements entsteht eine sogenannte Aufruf-Aktivität Anpassung der Implementation Zusammen mit dem Task-Typ ändern sich auch die möglichen Werte für die Eigenschaft Implementation, dabei bestehen folgende Abhängigkeiten. 6
Für die Task-Typen Senden, Empfangen, Service sind folgende Implementationen möglich: Nicht spezifiziert Anders Webservice Für den Task-Typ Benutzer sind folgende Implementationen möglich: Anders Nicht spezifiziert Webservice HumanTask Webservice Für den Task-Typ Geschäftsregel sind folgende Implementationen möglich: Nicht spezifiziert Anders Webservice BusinessRule Webservice Automatische Anpassung von Gateways Wenn die Richtung eines Gateways aus der Zahl der ein- und ausfließenden Sequenzflüsse abgeleitet werden kann, wird die Eigenschaft Flussrichtung entsprechend angepasst, vorausgesetzt, die Eigenschaft Innovator bestimmt Richtung wurde aktiviert. Es gibt vier mögliche Werte für die Flussrichtung: Unspezifiziert Zusammenlaufend Auseinanderlaufend Gemischt Da der Wert Unspezifiziert für alle möglichen Sequenzflussverbindungen verwendet werden kann, wird die Richtung nur dann angepasst, wenn diese eindeutig bestimmt werden kann. So ergibt sich beispielsweise als neue Richtung Zusammenlaufend, wenn es mehrere einfließende und genau einen ausfließenden Sequenzfluss am Gateway gibt. Hat der Gateway dagegen sowohl mehrere einals auch mehrere ausfließende Sequenzflüsse, so wird er als Gemischt klassifiziert. Möchte der Benutzer explizit Gateways der Richtung Unspezifiziert nutzen, sollte das Auswahl- feld Innovator bestimmt Richtung deaktiviert bleiben. 7
Zusammenhang zwischen Aufrufaktivität und aufgerufenem Prozesselement Beschrieben wird die Verknüpfung der Außendarstellung der beiden Elemente, Aufrufaktivität und aufgerufener Prozess. Innovator bietet die Möglichkeit die Schnittstelle d.h. Datenein- und ausgaben beider Seiten explizit zu verbinden. Idee Die Aufrufaktivität ist im Prinzip eine verknappte Darstellung des eigentlichen Prozesses, mit dem Ziel, diesen an verschiedenen Stellen übersichtlich verwenden zu können. Vor diesem Hintergrund wird bereits klar, dass es einen gewissen Zusammenhang zwischen den Einund Ausgabedaten des aufgerufenen Prozesses mit denen der Aufrufaktivität geben muss. Anders ausgedrückt, müsste es jederzeit möglich sein, in der Darstellung die Aufrufaktivität durch den Prozesse zu ersetzen, ohne aber die Daten- und Sequenzflüsse verändern zu müssen. Dem Ansatz folgend, müsste es zu jeder Datenein-/ausgabe des Prozesses eine Entsprechung an der Aufrufaktivität geben. Dieser Ansatz wurde jedoch dahingehend eingeschränkt, dass man es dem Benutzer überlässt, ob in der kompakten Darstellung, an der Aufrufaktivität, tatsächlich alle Datenflüsse von Interesse sind. Datenein- und -ausgaben verknüpfen Legt man in einem aufgerufenen Prozess eine Datenein-/ausgabe auf oberster Ebene - also nicht in einem Teilprozess - an, so wird automatisch an allen zugehörigen Aufrufaktivitäten eine - wenn möglich - gleichnamige Datenein-/ausgabe erzeugt und es wird eine Referenz zwischen beiden Elementen angelegt. Gab es an der Aufrufaktivität bereits ein gleichnamiges, unverknüpftes Datenelement, so wird dieses referenziert. Die Referenz dient der beidseitigen Navigation. Äquivalent zum Erstellen ist das Verhalten, wenn man aus einem Teilprozess, eine Datenein- /ausgabe auf die oberste Ebene des aufgerufenen Prozesses zieht. Ob eine Datenein-/ausgabe eine andere referenziert, erkennt man im Toolfenster Eigenschaften auf der Merkmalskarte: Merkmal Datenein-/ausgabe des aufgerufenen Elements Merkmal Datenein-/ausgaben der aufrufenden Elemente Hinweis Beachten Sie, dass der Automatismus ausschließlich vom Prozess in Richtung Aufrufaktivität funktioniert, d.h. wenn Sie an einer der Aufrufaktivitäten eine Datenein-/ausgabe anlegen, so hat das keine Auswirkungen auf den aufgerufenen Prozess. Verknüpfungen zwischen Datenein-/ausgaben von Aufrufaktivität und aufgerufenem Prozess lassen sich auch manuell erstellen. Dies ist besonders von Bedeutung, wenn die Namensgleichheit zwischen den Elementen nicht oder nicht mehr gegeben ist. Zum Erzeugen einer Verknüpfung geht man über das Toolfenster Eigenschaften, selektiert bei den Merkmalen Datenein-/ausgabe des aufgerufenen Elements bzw. Datenein-/ausgaben der aufrufenden Elemente die Schaltfläche [...] und kann dann über den erscheinenden Dialog die Zuordnung festlegen. 8
Datenelementverbindung lösen Durch das Löschen einer Datenein-/ausgabe im aufgerufenen Prozess bzw. an der Aufrufaktivität, werden auch die Verknüpfungen entfernt, nicht aber die referenzierten Elemente. Die Verbindung zwischen den Datenelementen lassen sich außerdem über das Toolfenster Eigenschaften bei den Merkmalen Datenein-/ausgabe des aufgerufenen Elements und Datedirekt lösen, indem man das Merkmal entweder nein-/ausgaben der aufrufenden Elemente über den Dialog (Schaltfläche [...]) entfernt oder über das Kontextmenü via rechte Maustaste 'Wert löschen' aufruft. Äquivalent zum Entfernen einer Verknüpfung verhält es sich, wenn man eine Datenein-/ausgabe von der obersten Ebene des aufgerufenen Prozesses in eine tiefere Ebene, d. h. in einen Teilprozess, schiebt. Automatismen bzgl. Datenassoziationen und datentragenden Elementen Beschrieben wird die Besonderheit der Darstellung einer Datenassoziation im Diagramm im Gegensatz zur dahinterstehenden eigentlichen Verknüpfung. Außerdem wird der automatische Übertrag von Eigenschaften eines datentragenden Elements auf ein zu verbindendes Element beschrieben. Anomalie der Anzeige Datenassoziationen dürfen gemäß BPMN-Spezifikation nur datentragenden Elementen verbinden und müssen immer eine Aktivität oder ein Ereignis als Besitzer haben. In der Visualisierung verläuft die Kante aber stets zwischen der Besitzeraktivität und - auf der anderen Seite - dem datentragenden Element. Datenassoziation zwischen datentragendem Element und Task/Ereignis Zieht (Erzeugen oder Umhängen) man eine Kante von einem datentragenden Element zu einem Task/Ereignis, so wird die Kante dem Task/Ereignis zugeordnet und an dem Task/Ereignis wird ein nicht sichtbarer Daten-Input als Ziel der Kante erzeugt. Da das eigentliche Ziel der Kante nicht zu sehen ist, scheint es im Diagramm, als wäre die Datenassoziation direkt mit dem Task/Ereignis verbunden. Der umgekehrte Fall, dass man eine Kante von einem Task/Ereignis zu einem datentragenden Element zieht, läuft analog, nur dass hier ein nicht sichtbarer Daten-Output am Task/Ereignis erzeugt wird. Datenassoziation zwischen datentragendem Element und Teilprozess Zieht (Erzeugen oder Umhängen) man also eine Kante von einem datentragenden Element zu einem Teilprozess, so wird die Kante dem Teilprozess zugeordnet und innerhalb des Teilprozesses wird ein Daten-Input als Ziel der Kante erzeugt, jedoch nicht mit dieser grafisch verbunden. Aus diesem Grund scheint es im Diagramm, als wäre die Datenassoziation direkt mit dem Teilprozess verbunden. Der umgekehrte Fall, dass man eine Kante von einem Teilprozess zu einem datentragenden Element zieht, läuft analog, nur dass hier ein Daten-Output im Teilprozess erzeugt wird. Automatismen beim Erzeugen einer Datenassoziation Um eine Datenassoziation zu erzeugen, zieht man via Karussell zwischen einem datentragenden Element und einer Aktivität /einem Ereignis die Kante. Dabei wird implizit zuerst an der Aktivität/dem 9
Ereignis ein Daten-Input bzw. ein Daten-Output, je nachdem ob die Aktivität/das Ereignis Ziel oder Quelle der Assoziation ist, erzeugt. In Teilprozessen wird dieses Datenelement sichtbar, an Tasks/Ereignissen nicht. Im Modellinhalt kann man das Datenelement als der Aktivität/dem Ereignis zugeordnetes Sohnelement immer sehen. Der neue Daten-Input/-Output erhält denselben Namen wie das Datenelement auf der anderen Seite der Assoziation. Gegebenenfalls ist dieser Name jedoch noch so modifiziert, dass er im Namensraum der Aktivität/des Ereignisses eindeutig ist. Zuletzt wird dann die Datenassoziation zwischen den beiden Datenelementen angelegt. Automatismen beim Umhängen einer Datenassoziation Das Umhängen der Quell- oder Zielseite einer Datenassoziation im Diagramm ist immer nur auf ein Element derselben Elementklasse möglich d.h. entweder zwischen Aktivitäts-/Ereignisknoten oder von einem datentragenden Element auf ein anderes. Der Wechsel einer Datenassoziationsseite auf eine neue Aktivität/ein neues Ereignis impliziert zunächst einen Besitzerwechsel der Datenassoziation. Außerdem braucht man einen Daten-Input/- Output an der Aktivität/dem Ereignis um die Datenassoziation intern verknüpfen zu können. Um dieses Datenelement zu bekommen, wird zunächst nach einem freien, passenden Daten-Input/- Output an der Zielaktivität/am Zielereignis gesucht. Passend ist das Datenelement, wenn es bzgl. Namen, zugeordneter Objektstruktur und Elementklasse (Daten-Input/-Output) mit dem aktuell verbundenen Datenelement übereinstimmt. Frei ist ein solches Element, wenn es noch mit keiner Datenassoziation verknüpft ist. Wird kein freies und passendes Datenelement gefunden, so muss wie im Fall Erzeugen ein entspredas Neue zu übertragen. Dies betrifft den Namen, die verbundene Objektstruktur sowie eventuell chendes Element angelegt werden. In diesem Fall gilt es, Eigenschaften des Ausgangselements auf zugeordnete Zustände. Automatismen beim Löschen einer Datenassoziation Löscht man eine Datenassoziation, so werden außerdem die zugehörigen Daten-Inputs/-Outputs an Tasks und Ereignissen entfernt, falls diese keine sonstigen Verbindungen mehr haben d.h. sie dürfen mit keinen anderen Datenassoziationen verbunden sein oder im Fall von CallActivities (Task mit Task-Typ Aufrufaktivitität) keine Daten-Inputs/-Outputs des aufgerufenen Elements referen- zieren. Unterscheidung von Definition und Referenz Für Prozesse und Kollaborationen wird eine Definition von einer Referenz unterschieden. Definitionen und Referenzen sind Diagrammdarstellungen mit unterschiedlichem Fokus. Während die Definition die Gesamtheit der Modellzusammenhänge grafisch darstellen soll, nutzen Sie eine Referenz dazu, die im jeweiligen Diagrammkontext relevanten Modellinhalte darzustellen. Grundkonzept Ein BPMN-Prozess ist ohne eine grafische Darstellung nicht sinnvoll modellierbar. Er kann in verschiedenen Elementen zugeordnet werden, die ihrerseits grafisch visualisiert werden: in einem Teilnehmer einer Kollaboration und in einer Aufrufaktivität eines Prozesses. Der Prozess sollte dann auch innerhalb des Teilnehmers bzw. der Aufrufaktivität angezeigt werden können. 10
Innovator unterstützt bei Prozessen mehrere Visualisierungen in unterschiedlichen Diagrammen. Das Konzept wurde außerdem auf Kollaborationen übertragen, auch sie können in unterschiedlichen BPMN-Diagrammen dargestellt werden. Mehrere Darstellungen in unterschiedlichen Umgebungen müssen und sollen nicht immer gleich sein: Im Kontext einer Kollaboration ist es eventuell für dessen Modellierer irrelevant, welche Datenobjekte im Prozess des Teilnehmers verwendet werden. Auch die Unterteilung des Prozesses in Lanes mag aus Sicht dieses Modellierers irrelevant sein. Um eine übersichtliche Visualisierung der Kollaboration zu erhalten, sollte der Prozess also auf die nötigsten Schritte reduziert werden können. Innovator gibt Ihnen die Mittel an die Hand, um verschiedene Referenzen auf einen Prozess oder auf eine Kollaboration zu modellieren. Verschiedene Referenzen sind aber nur dann ein Segen, wenn sie auch konsistent sind mit der eigentlichen Definition des Prozesses bzw. der Kollaboration. Innovator zeigt Ihnen daher an einer Referenz an, ob sie vollständig ist und ob sie korrekt ist. Vollständig ist eine Referenz genau dann, wenn sie alle Elemente der Definition enthält. Auf einen Prozess bezogen heißt das, dass die Prozessreferenz nicht nur alle Flusselemente, sondern auch alle Lanes und Objekte enthält. Das heißt aber noch nicht, dass sie auch korrekt ist. Beispiel Wenn Sie in der Prozessdefinition ein Task aus der Lane Abteilungsleiter in die Lane Bereichsleiter ziehen, wird dies in der Prozessreferenz nicht nachgezogen, denn über die Referenz haben Sie die Modellierungshoheit. Wenn Ihre Referenz den Task noch in der Lane Abteilungsleiter hat, werden Sie beim nächsten Aktualisieren des Diagramms ein Symbol an Ihrer Referenz vorfinden, welches Sie darauf hinweist, dass die Prozessreferenz nicht mehr alle Zusammenhänge korrekt darstellt. Innovator aktualisiert Ihre Referenzen bewusst nicht: nur Sie als Modellierer entscheiden, was in einer Referenz relevant ist. Daher sollten Sie das Konzept der Referenzen mit all seinen Möglichkeiten erst dann nutzen, wenn die Definition des Prozesses bzw. der Kollaboration als relativ stabil gilt. Solange ein Prozess aus Ihrer Sicht noch nicht vollständig modelliert ist, sollten Sie möglichst sparsam mit Referenzen auf den Prozess sein, denn jede Referenz bedeutet für Sie später wieder Aufwand, um die Referenz zu komplettieren oder zu korrigieren. Visuelle Unterscheidbarkeit Innovator markiert Referenzen auf einen Prozess oder auf eine Kollaboration mit Symbolen, die darüber Auskunft geben, ob es sich in Abgrenzung zur Definition um eine Referenz handelt, ob die Referenz unvollständig und ob sie nicht korrekt ist. Modellieren in einer Referenz Die Definition ist immer vollständig und immer korrekt, daher sehen Sie dort auch keinerlei zusätzli- chen Symbole. Modellieren im Sinne von Modellerweiterungen und Änderungen können Sie nur innerhalb einer Definition Referenzen erlauben Ihnen lediglich die Reduzierung auf das Wesentliche. Wenn Ihnen also etwas fehlt, wechseln Sie mit dem Befehl Gehe zu zur Definition, erweitern die Definition und gleichen Ihre Referenz wieder ab. Hier ist zu beachten, dass Sie nicht selektiv nur einzelne Elemente in Ihre Referenz einfügen können. Sie können die Referenz insgesamt vervollständigen, was jedoch heißt, dass Sie die Definition komplett übernehmen samt ihrer grafischen Darstellung. Falls Sie in Ihrer Referenz bereits einige 11
Arbeit in die Positionierung der Elemente gesteckt haben, geht Ihnen diese Arbeit verloren. Daher sollten Sie verschiedene Referenzen möglichst auch erst dann einsetzen, wenn das Modell relativ stabil ist oder wenn Sie eh nur an vollständigen Referenzen interessiert sind. Sequenzflüsse und Nachrichtenflüsse können Sie einblenden und ausblenden, für eine einzelne fehlende Verbindung in der Referenz müssen sie also nicht die Referenz komplettieren. Abgleich von Referenzen mit der Definition Innovator mischt sich weitestgehend nicht ein in Ihre Entscheidung, was eine Referenz enthalten soll. Wenn Sie sehen, dass eine Referenz nicht vollständig ist oder sie nicht korrekt ist, nehmen Sie das ja eventuell bewusst in Kauf. In dem jeweiligen Kontext mag es für Sie nicht wichtig sein, dass beispielsweise der Task Mahnung versenden in einem Teilprozess Mahnungsabwicklung durchführen liegt, weil Sie an der Strukturierung des Prozesses über Unterprozesse nicht interessiert sind. Referenzen entfernen und Definition löschen Ohne eine definierende Ansicht lässt sich mit einem Prozess oder einer Kollaboration nicht umgehen. Sobald Sie eine Definition erstellt haben, bleibt sie mit dem jeweiligen Element untrennbar verknüpft und kann nur zusammen mit dem Element gelöscht werden. Würde man sie entfernen können, hätte Ihr Prozess jegliche grafische Information über die Anordnung der Elemente verloren. Innovator möchte außerdem verhindern, dass Sie die Definition versehentlich löschen. Das führt zu Einschränkungen bei einigen Funktionen, die in der Folge aufgelistet werden. Für Innovator wiegt der Verlust der Definition jedoch so schwer, dass die Einschränkungen bewusst akzeptiert wurden: Eine Definition lässt sich nicht im Diagramm löschen. Zum Löschen eines Prozesses oder einer Kollaboration selektieren Sie das Element in der Modellstruktur (Gehe zu>position in der Modellstruktur) und rufen den Befehl Aus Modell löschen auf. Ein Diagramm, welches mindestens eine Definition enthält, lässt sich nicht löschen. Um es zu lö- Prozessen einen Befehl im Kontextmenü einer Prozessdefinition (Umgestalten>Neues Diagramm schen, verlagern Sie die Definition zuvor in ein anderes Diagramm. Zu diesem Zweck finden Sie bei für Definition erstellen). Er verlagert die Definition in ein anderes Diagramm und lässt eine Referenz zurück. Ist ein Prozess einem Teilnehmer zugeordnet und wollen Sie diese Zuordnung lösen, so darf es kein grafisches Vorkommen des Teilnehmers geben, welches die Prozessdefinition enthält. Das Lösen der Zuordnung hätte das Entfernen der Definition aus dem Teilnehmer zur Folge und damit den Verlust der Definition. Eine Referenz lässt sich nur dann aus einem Diagramm entfernen, wenn sie keine Definitionen enthält. Eine Prozessreferenz könnte in einer Aufrufaktivität eine Prozessdefinition enthalten, ein Teilnehmer könnte ebenfalls eine Prozessdefinition enthalten. Teilprozesse, Prozessaufrufe und Teilnehmer auf- und zuklappen Während ein Teilnehmer und eine Aufrufaktivität eine Referenz auf einen Prozess bzw. eine Pro- im zugeklappten Zustand gar nicht vorhanden sein muss, kapselt der zessdefinition enthalten, welche Teilprozess lediglich einen Teil eines Gesamtprozesses, der unabhängig von seinem Zustand immer vorhanden ist und beim Aufklappen lediglich visualisiert wird. 12
Eine Definition muss immer vollständig sein und sollte, so die aktuelle Strategie in Innovator, auch alle Elemente des Prozesses zeigen. Daher können Sie einen Teilprozess in einer Prozessdefinition au ch nicht zuklappen. Die Definition zeigt immer die voll expandierte Ansicht. Die Vollansicht endet bei Aufrufen anderer Prozesse: der aufgerufene Prozess selbst gehört nicht zur Definition des aufrufenden Prozesses, daher können Sie eine Aufrufaktivität auch dann zuklappen, wenn sie in einer Prozessdefinition liegt. Die Definition einer Kollaboration lässt es nicht zu, Teilnehmer zuzuklappen. Dies würde hinsichtlich der Nachrichtenflüsse bedeuten, dass die Definition Quell- und Zielelemente der Nachrichtenflüsse nicht vollständig anzeigen würde. Korrektheit von Referenzen Als korrekt gilt eine Referenz, wenn sie keine Zusammenhänge suggeriert, die in der Definition nicht gegeben sind. Dies umfasst folgende Zusammenhänge: Zuordnung eines Flusselements zu einer Lane, falls Lanes in der Referenz angezeigt werden. Falls also Lanes angezeigt werden, dann muss ein Element auch in der richtigen Lane liegen, um als korrekt visualisiert zu gelten. Zugehörigkeit zum Flusselement-Container, also zu einem Teilprozess oder einem Prozess. Falls ein Element in einem Teilprozess liegt, der Teilprozess aber nicht in der Referenz dargestellt wird, so suggeriert die unvollständige Referenz, dass das Element zu dem Prozess selbst gehört. Darstellung eines Ereignisses als angeheftetes Zwischenereignis. Copyright 2011 MID GmbH Bei Fragen wenden Sie sich bitte an unsere Hotline. Telefon: +49 (0)911 96836-22, E-Mail: support@mid.de. Dieses Dokument finden Sie neben anderen auch im exklusiven Login-Download-Bereich für Innovator-Wartungskunden unter http://www.mid.de/support/. Ihre MID MID GmbH, Eibacher Hauptstraße 141, 90451 Nürnberg Telefon: +49 (0)911 96836-0, Fax: +49 (0)911 96836-10, E-Mail: info@mid.de, Internet: http://www.mid.de Innovator 11.3 KundenInfo Spezialkonzepte Modellierung I4BA 110224.doc 13