Wiederverwendung mittels OBSE

gehalten wird.

Dem investierten Aufwand steht bei OBSE zunächst Zeitgewinn ge-genüber, der sich durch einen Import (Import-Brücke) von Elementen aus der Domänen-Ontologie während der Anforderungsanalyse ergibt. Das trägt zur Reduzierung des Gesamtaufwands bei. Sie ist um so gröÿer, je mehr Ele-mente beziehungsweise ganze Modell-Ausschnitte direkt in das konzeptuelle Modell eines Projekts übernommen werden können. Auch die Anzahl der Projekte, die die Import-Brücke anwenden, verbessert die Bilanz der Wie-derverwendung, da dadurch die Anzahl der wiederverwendeten Elemente steigt. Zusätzlich führt diese Vorgehensweise zu einem strukturellen Ge-winn, der sich aus der Vereinheitlichung der Modellierung gleicher Sachver-halte ergibt.

OBSE setzt auf einer Ebene auf, in der die Fehlerfreiheit bei der Über-setzung der Anforderungen und die Qualität der daraus erstellten Modelle für die spätere Produkt-Qualität eine entscheidene Rolle spielen. Bereits im Jahre 1979 machte Tom DeMarco darauf aufmerksam, dass die Kosten für die Fehlerbehebung um so höher sind, je früher dieser Fehler in einem Projekt gemacht wurde²⁶[DeM79]. Interessanterweise wies er ebenfalls dar-auf hin, dass die meisten Fehler während der Anforderungsanalyse gemacht werden (siehe Abbildung 3.3).

Diese Besonderheit bei der Verteilung der Fehlerhäugkeit und der Fehlerbehebungskosten auf die von ihm untersuchten Artefakte der Softwa-re-Entwicklung (Anforderungen, Code, Entwurf), führt dazu, dass die indi-rekten Auswirkungen der Wiederverwendung auf der konzeptuellen Ebene einen hohen Stellenwert bekommen, da sie in der Regel die Qualität des zukünftigen Software-Produkts nachhaltig beeinussen.

Die Import-Brücke kann zusätzlich zur direkten Wiederverwendung von Elementen dazu beitragen, dass mögliche Lücken in den Anforderungen auf-gedeckt werden. Da die Ontologie mit der wachsenden Zahl der exportie-renden Projekte immer mehr und detailliertere Informationen über die ent-sprechende Domäne enthält und diese Informationen in der Form von Kon-zepten und Relationen über die Import-Brücke den Projekten zur Verfügung gestellt werden, ist zu erwarten, dass die im konzeptuellen Modell möglicher-weise fehlenden oder inkonsistenten Elemente auallen und zusätzlich mit dem Fachverantwortlichen diskutiert und ggf. übernommen werden. Wird zum Beispiel ein Sachverhalt in der Domänen-Ontologie anders modelliert als in dem konzeptuellen Modell eines Projekts, könnte das ein Hinweis auf

26Eine neuere Untersuchung [Car00] hat diese Einschätzung weitgehend bestätigt.

Abbildung 3.3: Kosten und die Häugkeit von Fehlern in den Software-Projekten [DeM79]

die fehlerhafte Modellierung sein. Wichtig ist in diesem Zusammenhang, dass ein Analyst bzw. System-Entwickler durch die Anwendung der Import-Brücke auf diese Fälle aufmerksam wird. Setzt er entsprechende Elemente im Software-Projekt anders als in der Domänen-Ontologie um, dann handelt es sich um eine projektspezische Abweichung, die in diesem Fall bewusst hingenommen wurde und gegebenenfalls zu begründen wäre.

Von den anderen Verfahren aus dem Szenario Ontologie als ein Arte-fakt zur Software-Herstellung unterscheidet sich OBSE hauptsächlich da-durch, dass die konzeptuelle Wiederverwendung im Vordergrund steht. So ermöglicht zwar das Verfahren von Oliveira [OVRT06] das Erzeugen von Software-Artefakten wie Anwendungsfällen oder einem Datenbank-Modell aus einer Ontologie. Allerdings muss diese Ontologie speziell für das jeweili-ge Projekt erstellt werden und stellt somit ein zusätzliches Artefakt dar. Au-ÿerdem kann es vorkommen, dass beim Erstellen einer Domänen-Ontologie Zeit in Konzepte und Relationen investiert wird, die möglicherweise später in dem Projekt nicht mehr verwendet werden.

Der Gedanke der Wiederverwendung und eines Wissenstransfers zwi-schen den Projekten ndet sich dagegen in der Arbeit von Decker at al [DRR⁺05]. Der Unterschied zu OBSE liegt in der verwendeten Infrastruk-tur. Während Semantische Wikis, welche Decker für den Aufbau der Onto-logie vorschlägt, eine mit Meta-Daten versehene Verknüpfung der

Beschrei-bungen von Begrien darstellen und somit zu den strukturierten Glossa-ren (siehe Abbildung 2.13 im Kapitel 2.2.4) gehöGlossa-ren, baut die Domänen-Ontologie in OBSE auf der konzeptuellen Modellierungssprache CPL²⁷auf.

Diese Repräsentationsform ermöglicht eine direkte Integration in den Mo-dellierungsprozess, die auf der Benutzung von Brücken und Transforma-tionen zwischen CPL und UML basiert. Die Semantischen Wikis tragen dagegen eher einen informativen Charakter und werden in dem Modellie-rungsprozess indirekt verwendet [KVV06].

27Die Einordnung von CPL in die Landschaft der Wissensrepräsentatiosformen wird im Kapitel 4.1.3 behandelt.

OBSE-Infrastruktur: 4

Prozess-Bausteine

Nachdem die grundlegenden Elemente¹von OBSE (Konzeptuelles und Ana-lyse-Modell, Domänen-Ontologie und Brücken) im Kapitel 3.2.3 vorgestellt wurden, geht dieses Kapitel ins Detail und zeigt, wie diese Bestandteile konzipiert sind, und wie die verschiedenen dafür eingesetzten Techniken aufeinander abgestimmt werden. Anhand eines durchgehenden Beispiels soll auÿerdem verdeutlicht werden, wie verschiedene Artefakte im Rahmen von OBSE entstehen, verwendet werden, und wie die Übergänge zwischen diesen funktionieren.

Während in Abbildung 3.2 (auf Seite 75) eine Prozess-orientierte Sicht auf die Grundstruktur von OBSE vorgestellt wurde, stellt das Diagramm in Abbildung 4.1 die Elemente der Infrastruktur aus der Sicht ihrer Model-lierung dar.

Die OBSE-Infrastruktur baut auf der mehrschichtigen Meta-Modellie-rungs-Architektur auf². Eine Grundlage für alle Infrastrukturelemente des OBSE-Prozesses bilden somit Meta-Modelle, die ihrerseits mit Hilfe von EMOF³, der vereinfachten Version von MOF, beschrieben werden.

Die Modellierung der OBSE-Infrastruktur (Abbildung 4.1) kann ent-sprechend der MOF -Architektur in insgesamt drei Schichten (M1 bis M3) unterteilt werden. EMOF/Ecore bilden als ein Super-Meta-Modell die

1In diesem Kapitel werden mit Elementen zusammenfassend Bausteine der Infrastruk-tur wie Meta-Modelle, darauf aufbauende Modelle und Transformationen bezeichnet.

Es sind nicht die Ausprägungen von diesen Modellen und deren Elemente gemeint.

2Siehe auch Kapitel 2.1, Seite 10.

3Genau betrachtet wird zwecks Werkzeug-Entwicklung eine EMOF -ähnliche Implemen-tierung ECore als Meta-Modell verwendet. Sie ist im Rahmen der Eclipse-Plattform entstanden und bietet im Unterschied zu EMOF eine breite Werkzeugunterstützung.

Die beiden Meta-Modelle unterscheiden sich dagegen minimal [Wil08].

Abbildung 4.1: OBSE-Infrastruktur

oberste Schicht dieser Architektur M3. Eine Ebene tiefer M2 stehen Meta-Modelle für Sprachen und Transformationen. Die Infrastruktur selbst stellt Modelle zur Verfügung, mit denen Konzepte einer Domäne und die zugehö-rigen Software-Objekte beschrieben werden. Entsprechend dieser Aufgabe stehen alle OBSE-Infrastruktur-Elemente auf der Ebene M1.

Vertikal lässt sich dieses Diagramm anhand der drei Meta-Modelle in der Ebene M2 in drei Stränge unterteilen. Auf der linken Seite steht das vom UML-Meta-Modell instantiierte Analyse-Modell. In der Mitte sind die Trans-formationen von CPL nach UML und zurück abgebildet. Sie bauen auf der Atlas Transformation Language⁴ auf. Rechts stehen die auf dem CPL-Meta-Modell basierenden OBSE-Grundelemente. Dazu zählt neben dem konzep-tuellen Modell auch die Domänen-Ontologie. Die Elemente in der Ebene M1 sind so angeordnet, dass der Abstraktionsgrad der Modelle in dieser Ebene von links nach rechts zunimmt.

Die Infrastruktur des OBSE-Prozesses setzt gezielt Techniken ein, die auf der MOF-Architektur aufbauen. Diese Vorgehensweise soll helfen, ver-schiedene Elemente des Prozesses, die ursprünglich unabhängig voneinander entwickelt wurden, auf eine einheitliche Basis zu stellen. So werden sowohl

4ATL besitzt ebenfalls ein von ECore instantiiertes Meta-Modell. Da sie aber weitere Bestandteile wie eine eigene virtuelle Maschine mitbringt und somit mehr als ein Meta-Modell für Transformationen ist, wird in dem Diagramm in der Abbildung 4.1 statt eine Instanz von die Beschriftung konform zu bei der Beziehung zu EMOF/Ecore verwendet. Für weitere Informationen siehe Kapitel 2.1.4

alle Modelle der OBSE-Infrastruktur (Rechtecke) als auch Transformatio-nen zwischen diesen (Parallelogramme) konform zu dem Super-Meta-Modell EMOF/Ecore beschrieben.

Als eine von OMG standardisierte Modellierungssprache wurde UML ab der Version 2.0 vollständig mit MOF beschrieben. Auch ein ECorebasiertes MetaModell dieser Sprache wurde im Rahmen des Eclipse UML2 -Projekts erstellt. ATL als eine Sprache für Modell-zu-Modell-Transformatio-nen, die auf Ecore-basierten Modellen aufbaut, lässt sich ebenfalls problem-los in die OBSE-Architektur integrieren. Nur die vorgefundene Situation bei dem letzten Baustein in der Ebene M2 dem CPL-Meta-Modell erforderte eine Reihe an Anpassungen, um dieses Meta-Modell ebenfalls EMOF/Eco-re-konform zu machen und somit eine Integration des konzeptuellen Modells und der Domänen-Ontologie zu ermöglichen.

4.1 CPL-Meta-Modell für die OBSE-Infrastruktur

Ursprünglich für die Kommunikation über Projektanforderungen mit Fach-verantwortlichen entwickelt, besaÿ CPL zunächst nur ein skizzenhaftes Me-ta-Modell, das hauptsächlich zur Erklärung der Sprachelemente und in Prä-sentationen verwendet wurde. Dieser Teil des Meta-Modells wurde in UML⁵ verfasst. Der vollständig zur Verfügung stehende Sprachumfang von CPL wurde mittels eines Datenbank-Modells festgelegt, das von allen bis dahin entwickelten CPL-Werkzeugen genutzt wurde.

Um die Konformität zur MOF -Architektur zu erreichen, bestand der wichtigste Schritt zunächst darin, alle Sprachkonstrukte von CPL einheit-lich mittels EMOF/Ecore zu beschreiben. Diese Umschreibung von einem Datenbank- zu einem EMOF/Ecore-basierten Meta-Modell wurde gleich-zeitig benutzt, um das Meta-Modell der Sprache zu revidieren⁶ und Op-timierungen, aber auch Anpassungen im Bezug auf OBSE durchzuführen.

Die Änderungen reichten von einheitlichen englischen Bezeichnern bis hin zur Spezikation von neuen Sprachelementen.

5Allerdings nur in der Version 1.x dieser Sprache, die noch nicht MOF -konform war.

6Siehe auch [Ruÿ07]