Meta-Modell-Anpassungen

Abbildung 4.2: Elemente 1. und 2. Klasse in CPL

Meta-Klasse ModelingElement) oder Einschränkungen (Meta-Klasse Cons-traint) zu versehen.

Auÿerdem führt diese Klassizierung zu einer hierarchischen Struktur mit wenigen Modellelementen, die als Wurzelelemente angesehen werden können. Ein Wurzelelement der Programmiersprache Java ist die Klasse Object. Alle weitere Klassen werden von dieser Klasse abgeleitet. Dadurch wird ermöglicht, bei Bedarf alle Klassen in Java einheitlich zu behandeln.

Ähnlich verhält es sich mit den Modellierungselementen in der CPL. So ist es zum Beispiel für die Entwicklung von OBSE-Werkzeugen hilfreich, wenn bei einem Vergleich von zwei Glossaren über alle Elemente 1. Klasse einheitlich iteriert werden kann.

Generalisierung/Spezialisierung

Eine weitere wichtige Anpassung des CPL-Meta-Modells war die Einfüh-rung einer Möglichkeit zur GeneralisieEinfüh-rung/SpezialisieEinfüh-rung von Dingtypen.

Die Notwendigkeit für diese zusätzliche Beziehung ergab sich aus mehreren Gründen.

Auf der einen Seite stand die in der Praxis gesammelte Erfahrung, die es deutlich machte, dass die Fachverantwortlichen im Umgang mit der Generalisierung meist vertraut sind und diese von einer konzeptuellen Mo-dellierungssprache erwarten. Auf der anderen Seite ist diese Beziehung aus der Sicht eines Entwicklers für die konzeptuelle Modellierung heute funda-mental. Ein weiteres Argument ergab sich aus der anvisierten Verwendung

Abbildung 4.3: IsA-Beziehung in CPL

von CPL als Ontologie-Sprache. Es ist eine Tatsache, dass die Aufstellung von Taxonomien zu den wichtigsten Modellierungstechniken beim Verfas-sen von (Domänen)-Ontologien zählt [Gua99]. Die Erweiterung des Meta-Modells um die Generalisierung trägt damit wesentlich zur Steigerung der Ausdruckskraft der Sprache CPL bei und wurde in die Sprache aufgenom-men.

Bereits vor der Revision des CPL-Meta-Modells in Rahmen dieser Ar-beit wurde Generalisierung in den Sprachumfang eingebaut. Bei dieser Lö-sung [MK02] handelte es sich um eine verborgene Semantik in dem CPL-Meta-Modell. Sie äuÿerte sich dadurch, dass die IsA-Beziehung nicht als ein eigenes Element in dem Meta-Modell speziziert wurde, sondern als Perspektiven (Perspective) eines Zusammenhangstyps (ConnectionType), die mit speziellen Schlüsselworten wie generalization und specialization markiert wurden⁹. Ein Problem dieser Lösung ist die mangelnde Transparenz. Je-mand, der die Schlüsselworte nicht kennt, wird dieses Modellierungselement nicht als solches wahrnehmen, da es sich von einem typischen Zusammen-hangstyp bis auf die Schlüsselworte nicht unterscheidet. Ein so deniertes Modellierungselement bringt keine durch das Meta-Modell dierenzierte, explizit denierte Semantik mit sich. Aus diesem Grund wurde dieser spe-zielle Zusammenhangstyp in das neue CPL-Meta-Modell aufgenommen.

Die Generalisierung wurde mittels der Meta-Klassen GeneralConnec-tionType und IsA (siehe Abbildung 4.3) speziziert. Die abstrakte Klasse GeneralConnectionType dient als gemeinsame Oberklasse der

Meta-9für weiterführende Informationen siehe auch [KMZ04] und [Ruÿ07]

Klassen ConnectionType und IsA. Sie fasst die gemeinsamen Elemente dieser Beziehungen zusammen. Da ihre beiden Unterklassen zu den Elementen 1.

Klasse zählen, spezialisiert GeneralConnectionType die Meta-Klasse Mode-lingElement. Das Feld classication, das vergleichbar zu Stereotypen in UML verwendet werden kann und jedem Modellierungselement 1. Klasse zur Ver-fügung steht, wird für die IsA-Beziehung neu deniert und auf einen kon-stanten Wert GenSpec gesetzt. Eine zusätzliche Klassizierung dieser Be-ziehung ist auf Grund des speziellen Einsatzzwecks nicht erforderlich.

Behandlung von Synonymen

Die Sprache CPL bietet für ThingTypes eine spezielle Beziehung synonym, um im Rahmen eines Projekts synonym verwendete Begrie auszuzeichnen.

In einem natürlichsprachlichen Text werden oft aus stilistischen Gründen für ein Konzept der Domäne verwandte Begrie verwendet. Diese Beson-derheit der natürlichsprachlichen Texte wird in CPL unterstützt, was ei-ne einfache Zuordnung synonym verwendeter Begrie zueinander und ihre schnelle Identikation im Anforderungsdokument ermöglicht.

Die im ursprünglichen Meta-Modell vorgefundene isSynonymeTo-Be-ziehung hat einen entscheidenden Nachteil. Alle dadurch verbundenen Syn-onyme sind gleichwertige Dingtypen. Aus diesem Grund können Synony-me unabhängig voneinander an verschiedenen Beziehungen beteiligt sein, die das CPL-Meta-Modell für einen ThingType erlaubt. Diese Freiheit kann einerseits, falls sie exzessiv ausgenutzt wird, zu einem überladenen Mo-dell führen¹⁰und andererseits kann dadurch suggeriert werden, dass es sich (trotz Synonym-Beziehung) um verschiedene Konzepte handelt.

Diese Flexibilität bringt keine Vorteile mit sich und steigert nicht die Ausdruckskraft der Sprache. Die isSynonymeTo-Beziehung kann als eine Hülle betrachtet werden, mit der mehrere ThingTypes zusammengefast wer-den und nach auÿen als ein ThingType agieren. Deswegen macht es keinen Unterschied, welches der Synonyme eine Beziehung hat. Sie gilt automatisch für alle beteiligten Dingtypen, den sonst sind die Konzepte nicht synonym.

Aus diesem Grund bietet das neue Meta-Modell eine Möglichkeit, ein Thing-Type als Repräsentanten (das Feld mainSynonyme ist in diesem Fall auf true gesetzt) auszuzeichnen, der alle Beziehungen zu dieser Synonyme-Gruppe auf sich bindet.

Um sicherzustellen, dass die Synonyme unter Berücksichtigung der

10Schlimmstenfalls kann ein solches Modell gleiche Beziehungen zu jedem Synonym mehrfach und somit viel Redundanz enthalten.

Trennung (in Repräsentant und zugehörige Synonyme verwendet werden, enthält das neue CPL-Meta-Modell eine mit dem ThingType verbundene, in OCL verfasste Einschränkung (siehe Listing 4.1). Zunächst wird dort in den Zeilen 6 und 7 festgelegt, dass innerhalb einer Synonym-Gruppe¹¹ nur ein Repräsentant (mainSynonyme) deniert werden darf. Zusätzlich unter-bindet sie die Möglichkeit (ab Zeile 9), dass ein Nicht-Repräsentant eine Beziehung auÿer isSynonymeTo eingehen kann.

1 context ThingType inv Synonym

2

3 def: reachable() : Collection(ThingType) =

4 self−>closure(synonyme−>select(synonyme <> null))

5

6 self .synonyme.reachable()−>

7 select (s | s.mainSynonyme = true) −> size() <=1

8

9 self .synonyme −> forall (s : ThingType |

10 s.mainSynonyme = false implies s.superType.isEmpty() and

11 s.subType.isEmpty() and s.executingActor.isEmpty() and

12 s.involvedThingType.isEmpty() and s.parameter.isEmpty() and

13 s.perspectivedeterminer.isEmpty() and

14 s.connectionTypeDeterminer.isEmpty() and

15 s.conditionInvolvedThingType.isEmpty() and

16 s.operationTypeDeterminer.isEmpty() and

17 s. callingActor .isEmpty())

Listing 4.1: OCL-Einschränkungen für Synonyme

Einbau der Kommentare

Eine zusätzliche Anpassung des Meta-Modells der Sprache CPL wurde durchgeführt, um Modellelemente kommentieren zu können. Beinahe je-de künstliche Beschreibungssprache sieht diese Möglichkeit vor. Ein Grund dafür ist, dass es zu den Informationen über einen Gegenstandsbereich, die in einem Modell abgebildet werden, in der Regel ergänzende Informationen gibt, die keine Elemente des Gegenstandsbereichs sind, sondern seine Ele-mente weiter charakterisieren. Sie stellen somit Zusatz-Informationen über diese Elemente dar. Dadurch stehen Kommentare inhaltlich auf einer

ande-11Die entsprechende Hülle wird mittels der Operation reachable() ermittelt, die alle über die Synonyme-Beziehung erreichbare Dingtypen in eine Menge aufnimmt.

Abbildung 4.4: CPL-Meta-Modell ergänzt um Kommentare

ren Ebene als die Modellelemente selbst und sollen von diesen abgegrenzt werden.

Primär ermöglicht es die Sprache CPL, alle ihre Elemente 1. Klasse und ausgewählte Elemente 2. Klasse mit Hilfe des Meta-Attributs description zu beschreiben. Um zu vermeiden, dass dieses Feld sowohl für die Beschreibung eines Elements als auch für das Festhalten der Meta-Informationen über dieses Element verwendet wird, wurde das CPL-Modell um die Meta-Klasse Comment ergänzt (siehe Abbildung 4.4).

CPL-Kommentare sind ein einfacher Text und werden eindeutig einem Element der Sprache zugeordnet. Kommentiert werden können alle Elemen-te 1. und 2. Klasse und Quellenangaben (Origin). Es ist erlaubt, mehrere Kommentare zu einem Modellierungelement zu formulieren.