FAQ zur Konfiguration

Um die Konfiguration eines Modells ändern zu können, muss das Profil, welches die Konfigurationseinstellungen enthält, vorab gesperrt werden – so wie jedes andere Modellelement auch. Auch in der Konfiguration wird über die Vergabe von Zugriffsrechten festgelegt, welche Benutzerrollen ein Profil sperren und verändern dürfen.

• Das Profil muss zunächst die Eigenschaft besitzen, dass die Benutzerrolle auf es zugreifen darf. Die Benutzerrolle muss also das "normale" Zugriffsrecht auf das Profil besitzen. Dieses Zugriffsrecht kann vom Administrator und vom Ersteller des Profils im Eigenschaftendialog vergeben werden.
• Zudem muss die Benutzerrolle für die Bearbeitung eines Profils über das Verfahrensrecht Konfigurieren verfügen. Diese Berechtigung muss der Benutzerrolle vom Administrator in der Benutzerverwaltung erteilt worden sein.

Zunächst ein Beispiel, warum dies nötig sein könnte: Die Konfiguration eines Modells enthält auch die Strukturen zur Generierung einer Dokumentation. Aufgrund fehlender Kenntnisse darf die Konfiguration als solche (hier v.a. gemeint: was darf Inhalt eines Stereotyps sein?) von den meisten Benutzern nicht verändert werden. Einem Benutzer muss es aber möglich sein, die Dokumentationsstrukturen auf seine Bedürfnisse anzupassen.

Das gewünschte Verhalten lässt sich erreichen, indem man

• eine separate Benutzerrolle (z.B. "Doku-Konfigurator") mit dem Verfahrensrecht Konfigurieren für das Bearbeiten von Profilen konfiguriert und

• ein separates Profil für die Dokumentationsstrukturen einrichtet.

  Für dieses "Doku-Profil" wird das Zugriffsrecht für die Benutzerrolle "Doku-Konfigurator" erteilt, für die restlichen Profile wird dieses Recht hingegen verweigert.

Ergebnis: Jedes Mitglied der Benutzerrolle "Doku-Konfigurator" darf in der Konfiguration ausschließlich das "Doku-Profil" sperren und verändern, alle übrigen Profile der Konfiguration sind dagegen vor Veränderungen geschützt.

Denken Sie zuerst in Ruhe darüber nach, was Sie eigentlich modellieren wollen. Skizzieren Sie auf Papier, wie Ihre Modellstruktur aussehen soll, welche Elemente an welcher Stelle des Modells abgelegt werden sollen, welche Diagramme Sie zum Erstellen dieser Elemente benutzen wollen und wo diese wiederum abgelegt werden usw.

Leiten Sie aus dem Vergleich dieser Informationen mit der entsprechenden Spezifikation (UML, IMM usw.) Ihren Bedarf an zusätzlichen Modellierungskonstrukten (Stereotype, deren Stereotypeigenschaften und Einschränkungen) ab.

Lesen Sie in dieser Hilfe nach, wie Sie aus diesen Konstrukten ein eigenes Profil machen.

Im Prinzip würde ein einziges ausreichen, in dem alle Einstellungen enthalten sind. Was sind also die Gründe dafür, dass ein Modell viele verschiedene Profile enthält?

Ein Innovator-Modell enthält üblicherweise mehrere Teilmodelle (Anforderungs-, Analyse-, Designmodell etc.). In jedem Modell soll nur ein definiertes Subset der jeweiligen Notation verwendet werden – im Anforderungsmodell z.B. Use-Cases, die in anderen Teilmodellen wiederum ausgeschlossen sein sollen. Um dies zu erreichen, könnte man aber auch einfach verschiedene "Modell"-Stereotype in einem einzigen Profil definieren und deren Inhalte dort festlegen. Das ist für sich genommen also nicht der Grund für die vielen Profile. Es gibt aber weitere Gründe, die eine Aufteilung auf verschiedene Profile rechtfertigen:

• Bildung austauschbarer Einheiten

  Ein Profil ist die kleinste versionierbare Einheit in einer Konfiguration. Beim Nachladen von Konfigurationsinformationen (dies geschieht in der Regel durch Importieren von Add-ons) werden Profile als in sich geschlossene Einheiten hinzugefügt bzw. bereits vorhandene komplett ersetzt. Erst das Aufteilen auf mehrere Profile erlaubt es, Teile einer Konfiguration auszutauschen, zu ergänzen oder auch wieder aus der Konfiguration zu löschen, ohne die Konfigurationseinstellungen einzeln von Hand anzufassen.

• Aufteilung in Verantwortungsbereiche

  Für jedes Profil gibt es einen Herausgeber, der für die Inhalte eines Profils verantwortlich ist. Dies kann z.B. eine Organisation wie die OMG (Object Management Group) sein oder ein Hersteller wie Sun Microsystems, der den EJB-3-Standard definiert hat. Die Profile aus diesen Quellen werden nach Möglichkeit 1:1 im Innovator abgebildet. Ein Profil wie z.B. "J2EE EJB3", das auf einem existierenden Standard aufsetzt, wird das entsprechende Profil dann nur noch importieren, aber nicht mehr selber enthalten.

• Variantenbildung

  Oft stellt das Einsatzgebiet eines neuen Profils nur eine Variante einer bekannten Konstellation dar. So unterscheidet sich die Modellierung einer SOA in den ersten Phasen nur unwesentlich von der einer EJB-Applikation, da es sich in beiden Fällen um interaktive Systeme für Geschäftsanwendungen handelt. Um die Gemeinsamkeiten nicht redundant pflegen zu müssen, wird man diese Teile in eigene Profile auslagern, die in beiden Konfigurationen nach Bedarf importiert werden. Eine ähnliche Konstellation findet man auch im Bereich der Datenmodellierung, wenn sich die einzelnen Varianten nur durch die verwendete Notation in den Diagrammen (Chen, James-Martin, DSA, etc.) unterscheiden, die Logik des Modells ansonsten aber identisch ist.

Jedes Profilelement befindet sich im Besitz genau eines Profils, kann jedoch in vielen Profilen verwendet und dort näher spezifiziert werden. Ein Profil der Konfiguration importiert ein anderes Profil, um dessen Stereotype (wieder) verwenden und erweitern zu können.

Im Modell wird ein Profil importiert (angewandt), um dessen konfigurierte Schablonen, Engineering-Aktionen, Prüfroutinen und Dokumentationskommandos über die konfigurierten Menübefehle nutzen zu können.

Der Eigenschaftendialog eines Profils zeigt im Register Importierte Profile nur die Profile an, die von diesem Profil auch tatsächlich importiert werden können. Folgende Profile werden Sie daher in der Liste nicht finden:

• Das Profil selbst – Eigenimport ist ausgeschlossen
• Alle sprachspezifischen Profile, wenn das Profil selbst sprachneutral ist – ein Import ist nur umgekehrt möglich
• Alle Profile, die das Profil selbst bereits (direkt oder transitiv) importieren – ein Ring aus wechselseitigen Importen wird immer verhindert

Die Einordnung der Elementtypen orientiert sich an den Kapitelstrukturen der jeweiligen Spezifikationen. Deren Kenntnis vereinfacht das Auffinden also erheblich.

Sie können auf verschiedene Arten durch die Teilbäume des linken Profilbaums navigieren, um die gewünschten Profilelemente angezeigt zu bekommen:

• Sie nutzen die inkrementelle Suche (analog zum Windows-Explorer) für die schnelle Selektion eines Profils oder Profilelements (Profilabschnitte etc.).
• Sie wechseln im Profilbaum zwischen den Profilelementen einer über- bzw. untergeordneten Ebene.
• Sie wechseln mit dem Menübefehl  Wechseln>Referenz... zum Profilelement in jedem Profil, in dem es vorkommt. Profile, in denen für das Element etwas konfiguriert ist, sind durch eine farbige Markierung leicht erkennbar.
• Sie wechseln zum Profilelement im nächsten oder vorherigen Profil mit den Menübefehlen Wechseln>Nächstes Profil ([Strg]+[Nach unten]) oder Wechseln>Vorheriges Profil ([Strg]+[Nach oben]).
• Sie wechseln nach einem Menübefehl Wechseln zum zuvor selektierte Element mit dem Menübefehl  Wechseln>Zurück.
• Sie wechseln mit dem Menübefehl  Wechseln>Zum Element zum besitzenden Profil des Elements und können so den Kontext des Profilelements erkennen.

Wechseln Sie zunächst in das Profil, in dem das Stereotyp definiert werden soll. Wählen Sie dann den Elementtyp aus, für den Sie das neue Stereotyp anlegen wollen. Die eigentliche Definition des Stereotyps umfasst dann die Festlegung von Stereotypsymbol (u.a. Unterscheidungsmerkmal bei der Einbindung in die Symbolleiste) und ggf. anderen Stereotypeigenschaften.

Um das Stereotyp im Modell zur Verfügung zu haben, muss zumindest eine Anlegeschablone für das Stereotyp erstellt werden und diese Schablone als Menübefehl verfügbar gemacht werden. In dem Modell, in dem dieser Menübefehl zur Verfügung stehen soll, muss das Profil importiert sein.

Das Stereotyp muss als Inhalt erlaubt sein, im Modell, im Paket und ggf. im Diagramm.

Bei der Festlegung von Stereotypeigenschaften haben Sie ggf. die Wahl, ob Sie deren Bestimmung dem Modellierer überlassen oder sie explizit vorgeben wollen. So können Sie z.B. für eine Klasse die Stereotypeigenschaft Zeichenkette wählen und dem Modellierer die Vergabe eines Eigenschaftswerts überlassen. Wollen Sie jedoch ein Set bestimmter Eigenschaftswerte vordefinieren, empfiehlt sich die Verwendung einer Stereotypeigenschaft des Typs Aufzählung und das Erstellen aufgezählter Werte mit den erlaubten Eigenschaftswerten.

Letzteres hat zwei entscheidende Vorteile. Zum einen kann der Modellierer über eine Auswahlliste nur einen der erlaubten Werte auswählen und zuweisen. Zum anderen können Sie jedem vordefinierten Wert ein eigenes Symbol zuweisen. Über die Anzeigeoptionen kann für dieses Stereotyp festgelegt werden, dass im Diagramm der jeweilige Eigenschaftswert symbolisch anzeigt wird.

Um Elemente des gleichen Stereotyps, aber mit unterschiedlichen Merkmals- oder Eigenschaftswerten zu erzeugen, können Sie mehrere Anlegeschablonen festlegen, die jeweils diese Spezifik repräsentieren und dies auch im Namen und im Symbol zum Ausdruck bringen können. (Ein typisches Beispiel hierfür sind Assoziationen, die sich v.a. durch die Multiplizität und Navigierbarkeit ihrer Assoziationsenden unterscheiden.)

Dies wird insbesondere dann sinnvoll sein, wenn die spezifischen Anlegeschablonen auch relativ gleichwertig im Modell Verwendung finden werden – für selten benötigte Einzelfälle lohnt sich eine eigene Schablone nicht, sie macht vielmehr die Symbolleiste und das Menü unübersichtlicher.

Für gerichtete Beziehungen sind die "source"- und die "target"-Seite zu bestimmen. In Innovator gilt für alle Arten von gerichteten Beziehungen, dass das Modellelement auf der "source"-Seite einer solchen Beziehung (also das abhängige Element) immer auch der Besitzer dieser Beziehung ist.

Je nach Selektion im Profilbaum sind wahlweise folgende Beziehungsrollen für die Festlegung einer gerichteten Beziehung zwischen einem "source"- und einem "target"-Knoten zu bearbeiten:

1. Am Stereotyp dieser gerichteten Beziehung: Beziehungsrolle Besitzer für die Zuordnung der als "source" erlaubten Knotenstereotype und anschließend Beziehungsrolle Ziel für die Zuordnung der als "target" erlaubten Knotenstereotype
2. An allen als "source" möglichen Knotenstereotypen: Für die Beziehungsrolle Zugeordnete Elemente diese gerichtete Beziehung zuordnen (das selektierte "source"-Stereotyp im Profilbaum wird der Besitzer dieser gerichteten Beziehung) und anschließend
   An allen als "target" möglichen Knotenstereotypen: Für die Beziehungsrolle Einlaufende Beziehung wiederum diese gerichtete Beziehung zuordnen.

Beachten Sie, dass Zielzuordnungen für Unterstereotype ggf. erneut vorzunehmen sind, da sie nicht automatisch auf diese erweitert werden.

Um das Stereotyp einer gerichteten Beziehung im Modell zur Verfügung zu haben, muss zumindest eine Anlegeschablone für das Stereotyp erstellt werden. Diese Anlegeschablone kann allerdings nicht im Modelleditor, sondern nur an zwei anderen Stellen verwendet werden:

• In allen Diagrammen, in denen einer der als "source" erlaubten Knotenstereotype als Grafikknoten vorkommen kann. In diesen Diagrammen kann diese Schablone als Menübefehl verfügbar gemacht werden.
• Im Eigenschaftendialog eines Elements eines als "source" erlaubten Stereotyps. Betätigt man auf dem dazugehörigen Register (meist Abhängigkeit) die Schaltfläche Neu, wird diese Anlegeschablone zum Erzeugen einer neuen gerichteten Beziehung angeboten.

In dem Modell, in dem diese Anlegeschablone zur Verfügung stehen soll, muss das Profil mit den o.g. Einstellungen importiert sein.

Beachten Sie weiterhin, dass gerichtete Beziehungen in Diagrammen nur dann grafisch modelliert werden können, wenn Quelle und Ziel der Beziehung als eigenständige Grafikknoten im Diagramm vorkommen. Gegenbeispiel: eine gerichtete Beziehung zwischen Attributen lässt sich im Diagramm grafisch nicht darstellen, da Attribute nur als Abschnittsinhalt, aber nicht als eigenständige Grafikknoten vorkommen.

Assoziationen können zwischen beliebigen Classifiern angelegt werden. Jede Assoziation beinhaltet dabei mindestens zwei Attribute als Rollen. Die Verbindung zu den Classifiern wird über die Typen der Attribute hergestellt. Die Reihenfolge der Rollen gibt die Leserichtung der Assoziation an.

Assoziationen sind selbst Classifier und können damit z.B. Paketen als Inhalt zugeordnet werden, aber genauso "nestedClassifier" einer Klasse sein. Im zweiten Fall ist dann nicht ein Paket, sondern eine Klasse Besitzer der Assoziation.

Assoziationen können nur in Diagrammen und nicht im Modelleditor angelegt werden. Diesen Diagrammen müssen sie als Diagramminhalt zugeordnet sein. Dann können sie auch im Menü zugeordnet werden (weitere Voraussetzungen wie bei gerichteten Beziehungen sind nicht zu erfüllen).

Aus dem Genannten ergeben sich folgende notwendige Konfigurationsschritte:

• Assoziation beinhaltet Attribute als Rolle, also "Zugeordnete Elemente" bzw. "Besitzer"
• Attribute haben Classifier als Typen, also "Typisiertes Element" bzw. "Typ"
• Der Besitzer des Diagramms (meist ein Paket mit bestimmtem Stereotyp) darf Assoziationen beinhalten, also "Zugeordnete Elemente" bzw. "Besitzer"
• Diagramme können Assoziationen beinhalten, also "Diagramminhalt" bzw. "Diagramm"

Für Assoziationen mit zwei Rollen können Sie die Navigierbarkeit der Rollen setzen. Eine navigierbare Rolle wird im Diagramm als offene Pfeilspitze und im gegenüberliegenden Classifier als Attribut angezeigt.

Notwendige (Inhalts-)Konfiguration:

• Classifier beinhaltet Attribute, also "Zugeordnete Elemente" bzw. "Besitzer"

• Anlegeschablonen von Assoziationen enthalten immer die eigentliche Assoziation und genau zwei Rollen

  Beim Anlegen einer Assoziation werden die Werte aus dieser Schablone übernommen. Die erste Rolle wird dabei mit dem zuerst selektierten Classifier verbunden. Die zweite Rolle wird mit den weiteren selektierten Classifiern verbunden. Eine Assoziation kann also über mehr als zwei Rollen verfügen.

Zunächst einmal haben Sie etwas richtig gemacht, nämlich Ihr Profil überhaupt einmal geprüft – das machen aus unserer Erfahrung leider viel zu wenige Anwender.

Bei der Prüfung haben Sie die Prüfmeldung "Element 'Name' aus Profil 'Name' verwendet, aber Profil-Import fehlt" erhalten.

Um in die Situation zu kommen, die den beschriebenen Fehler auslöst, muss "Profil Y" zu einem früheren Zeitpunkt einmal importiert gewesen sein. Das "Element X" ist dann in irgendeiner Form in Ihrem Profil verwendet worden, meist in Form eines erlaubten Stereotyps für eine konfigurierbare Beziehung (Zugeordnete Elemente, Diagramminhalt o.ä.), bevor der Import von "Profil Y" wieder zurückgenommen worden ist.

Zur Behebung des Fehlers muss "Profil Y" temporär wieder importiert werden. Bleiben Sie in der Ansicht des Konfigurationseditors, in der Sie die Prüfmeldung erhalten haben, und suchen Sie nach "Element X" im "Profil Y". Wenn Sie es gefunden haben, benutzen Sie den Menübefehl  Wechseln>Referenz..., um eine Liste der Profile zu erhalten, in denen "Element X" verwendet wird. Wählen Sie in der Liste das geprüfte Profil, so wechselt die Selektion im Konfigurationseditor automatisch an die Stelle der Verwendung von "Element X" in Ihrem Profil. Sobald Sie diese Stelle gefunden haben, können Sie beurteilen, ob die Verwendung an dieser Stelle (noch) sinnvoll ist oder nicht:

• Wird "Element X" tatsächlich noch in dieser Form verwendet, müssen Sie den Import von "Profil Y" beibehalten
• Wenn nicht, entfernen Sie die Verwendung von "Element X" an dieser Stelle, und entfernen Sie den Import von "Profil Y" wieder. Wiederholen Sie die ursprüngliche Prüfung, um ggf. weitere, nicht mehr benötigte Verwendungen aufzuspüren.

Nur dann, wenn die gewünschte Multiplizität von der des UML-2- bzw. IMM-Metamodells abweicht. Als Beispiel dazu ein Ausschnitt aus dem "CCM Component Profile Example" aus Annex D der UML-2-Spezifikation:

• Für eine Schnittstelle mit Stereotyp «CCMHome» wird gefordert, dass genau eine «Manages»-Abhängigkeit existieren muss:
• Elementtyp "Abhängigkeit"
• Von diesem Elementtyp nur das Stereotyp «CCMManages»
• Multiplizität: 1

Für den zugeordneten Inhalt «CCMManages» wird deshalb die Multiplizität der Zuordnung von "*" auf "1" geändert. Die Einhaltung der geforderten Multiplizität 1 kann dann im Rahmen einer Prüfroutine sichergestellt werden, indem dieser Prüfroutine folgende Einträge zugeordnet werden:

• Aus dem Prüfabschnitt Klassen die Prüfkategorie Schnittstelle
• Aus dieser Prüfkategorie die Prüfkategorie «CCMHome»
• In dieser Prüfkategorie die Prüfmeldung "Anzahl 'Nummer' von enthaltenen Elementen des Typs 'Name' mit Stereotyp "Name" liegt außerhalb der konfigurierten Multiplizität 'Name'."