Beziehungen

Unter dem Reiter „Beziehungen“ im Hauptanzeigebereich des Designers stehen folgende Funktionen zur Auswahl:

  • Neue Beziehungen: Kategorien stehen in den meisten Fällen in irgendeiner Beziehung zueinander, d.h. gewisse Aspekte Ihrer Charakteristiken sind wechselseitig relational, die Sie mit Hilfe dieser Funktion näher spezifizieren können. Sei es, weil ein Inhaltstyp wie die „Schnittstelle“ eines zu bauenden Systems einen allgemeineren Inhaltstyp wie z.B. „Systemteil“ spezialisiert oder weil das „System“ als Singleton-Kategorie aus mehreren dieser „Systemteile“ besteht. Um solche in erster Linie unidirektionalen Relationen zwischen je zwei Kategorien, von Quellkategorie (Pfeilursprung) nach Zielkategorie (Pfeilspitze), zu definieren, klicken Sie auf die Schaltfläche „Neue Beziehung“. Es wird ein Eingabefenster geöffnet (vgl. Abbildung 1 links), in dem Sie in Abhängigkeit von der unter „Stereotyp *“ gewählten Beziehungsart unterschiedliche Angaben tätigen müssen:
    • containedIn: Die Quellkategorie ist bei dieser Beziehungsart logischer Bestandteil der Zielkategorie, d.h. man drückt damit Zugehörigkeitsbeziehungen aus. Beispielsweise ist eine „Geschäftsaktivität“ immer Teil eines „Geschäftsprozesses“ und daher folgt

„Geschäftsaktivität“ — containedIn –> „Geschäftsprozess“

    • Der Name der Beziehung lautet typischerweise „Teil von“ und die Rückrichtung „besteht aus“. Mit der zu wählenden „Kardinalität“ bestimmen Sie die Multiplizität, d.h. quantitative Abhängigkeit zwischen den beiden Kategorien. Im diesem Fall könnte es naheliegen, dass ein Geschäftsprozess aus mindestens einer Geschäftsaktivität besteht und eine Geschäftsaktivität in mindestens einem Geschäftsprozess enthalten ist. Demnach wäre als Kardinalität „1..*—>1..*“ zu wählen (vgl. Abbildung 1 links oben).
    • requiredBy: Die Quellkategorie ist bei dieser Beziehungsart kein logischer Bestandteil der Zielkategorie, aber wird benötigt, um die Zielkategorie entweder vollständig zu beschreiben oder „funktionsfähig“ zu machen. Beispielsweise ist ein „Bearbeiter“ kein Teil einer „Geschäftsaktivität“, aber notwendig, um diese Geschäftsaktivität ausführen zu können, somit folgt

„Bearbeiter“ — requiredBy –> „Geschäftsaktivität“

    • Der Name der Beziehung könnte hier „für die Durchführung von … verantwortlich“ lauten und die Rückrichtung „durchgeführt von“. Unter der Annahme, dass ein Bearbeiter für mehrere Geschäftsaktivitäten verantwortlich ist, und eine Geschäftsaktivität von genau einem Bearbeiter durchgeführt wird, sollte „1—>*“ als Kardinalität gewählt werden (vgl. Abbildung 1 Mitte oben).
    • influencedBy: Die Quellkategorie ist bei dieser Beziehungsart weder logischer Bestandteil der Zielkategorie noch erforderlich, um letzteres vollständig zu beschreiben oder „funktionsfähig“ zu machen. Die Ausgestaltung der Quellkategorie ist jedoch beeinflusst von der Ausgestaltung der Zielkategorie. Beispielsweise ist ein „Ziel“ i.d.R. von einem „Problem“ beeinflusst, daher gilt

„Ziel“ — influencedBy –> „Problem“

    • Der Beziehungsname ist in dem Fall bidirektional eindeutig durch die Beziehungsart bestimmt, so dass Sie nur Quell- und Zielkategorie auswählen müssen. Selbiges gilt für die Kardinalität, die für diesen Beziehungstyp keine Rolle spielt (vgl. Abbildung 1 links unten).
    • specializes: Die Quellkategorie ist bei dieser Beziehungsart eine Unterart der Zielkategorie. Beispielsweise ist ein „Kernprozess“ eine spezielle Art eines „Geschäftsprozesses“, sodass gilt

„Kernprozess“ — specializes –> „Geschäftsprozess“

    • Der Beziehungsname sowie die Kardinalität sind hierbei wiederum eindeutig und haben keine Relevanz (vgl. Abbildung 1 Mitte unten).
Abbildung 1. Dialogfenster zum Hinzufügen (oben und unten links), Bearbeiten (oben und unten rechts) und Löschen (unten Mitte) verschiedener Beziehungstypen

Zum Bearbeiten einer bestehenden Beziehung zwischen Inhaltskategorien klicken auf das „Stift-Symbol“ in der letzten Spalte der entsprechenden Tabellenzeile. Es wird ein Bearbeitungsfenster geöffnet, das bzgl. Inhalt und Funktionalität dem zuvor behandelten Eingabefenster für eine neue Beziehung gleicht. Die einzige Ausnahme dabei bildet die Tatsache, dass Sie weder die Quell- noch die Zielkategorie zu einer bestehenden Beziehung ändern können (vgl. Abbildung 1 Mitte).

Eine Beziehung zwischen Kategorien können Sie unwiderruflich aus dem System löschen, indem Sie diese in der entsprechenden Liste auswählen, auf das „Mülleimer-Symbol“ im Listenkopf klicken und im erscheinenden Abfragedialog die Schaltfläche „Ok“ betätigen (vgl. Abbildung 1 rechts). Jeder der zuvor genannten Vorgänge kann mit Klick auf „Abbrechen“ im jeweiligen Dialog abgebrochen werden (vgl. Abbildung 1).

Hinweise und Regeln:

Achten Sie bei der Benennung von Beziehungen zwischen Kategorien, dass ein sprachlich korrekter und logisch passender Satz entsprechend folgenden Satzmustern entsteht:

  • Konfigurationssprache „Deutsch“: „Bestimmen Sie den/die/das <Quellkategorie>, der/die/das <Beziehung mit „…“ als Platzhalter für Instanz der Zielkategorie><Instanz der Zielkategorie> ist/sind.“
  • Konfigurationssprache „Englisch“: „Ask for the <Quellkategorie> that is/are <Beziehung><Instanz der Zielkategorie>.“

Für den Namen der Beziehungsrückrichtung gilt, dass man einen vollständigen Satz gemäß folgendem Satzmuster bilden kann:

  • „<Zielkategorie><Beziehung (Rückrichtung)>< Instanz der Quellkategorie>“

Bei der Definition einer „specializes“-Beziehung zwischen Inhaltstypen muss die Zielkategorie zuvor als „Abstract“ definiert worden sein, um diese im Dialogfenster zum Anlegen bzw. Bearbeiten einer Beziehung auswählen zu können. Danach steht die abstrakte Kategorie nicht mehr als Quellkategorie für eine weitere „specializes“-Beziehung zur Verfügung, da systemseitig nur eine Einfachvererbung zulässig ist.

Beachten Sie, dass die Vererbungstiefe beim Einsatz von „specialize“-Beziehungen maximal 1 betragen darf (Beispiel: Wenn „Kernprozess“ die Kategorie „Geschäftsprozess“ spezialisiert, dann darf weder „Geschäftsprozess“ eine andere Kategorie spezialisieren, noch darf „Kernprozess“ von einer weiteren Kategorie spezialisiert werden).

Abgesehen von einer „specializes“-Kante zwischen einem spezialisierenden und dem spezialisierten abstrakten Inhaltstyp darf es zwischen zwei Inhaltstypen immer nur eine Kante eines anderen Beziehungstyps geben (Beispiel: Wenn „Kernprozess“ die Kategorie „Geschäftsprozess“ spezialisiert, dann darf „Geschäftsprozess“ z.B. eine „containedIn“-Beziehung zu „Kernprozess“ eingehen, eine weitere Beziehung jedweden Typs zwischen diesen beiden Kategorien ist jedoch nicht zulässig).

Stellen Sie sicher, dass bei der Definition von Beziehungen zwischen Inhaltstypen grundsätzlich keine Zyklen entstehen (Beispiel: „Bearbeiter“ ist verantwortlich für „Geschäftsaktivität“ und „Geschäftsaktivität“ ist Teil von „Geschäftsprozess“. In dem Fall darf „Geschäftsprozess“ keine Beziehung zu „Bearbeiter“ wie z.B. „involviert“ eingehen).

Zur Auflösung möglicher Zyklen im Modellgraph, den man aus den Beziehungen als Kanten und Kategorien als Knoten bilden kann, sollte das Kontrollkästchen „im Process Guide ignorieren“ für betroffene Beziehungen zwischen Inhaltstypen aktiviert werden. Dadurch werden diese bei der Generierung der Reihenfolge von Arbeitsanweisungen für das Plug-in außen vor gelassen, sodass zyklische Abarbeitungspfade vermieden werden können (siehe Abbildung 1).