eine Vergleichsbasis liefern, die zur Beurteilung der Qualitätsunterschiede zu den aus der Emulation entstandenen konzeptuellen Modellen verwendet wird.
System wurde in zwei Teilprojekten zum Teil Modell-getrieben mit Struts, Java und MySQL entwickelt. Im ersten Teilprojekt wurde kon-ventionell nach einem RUP-Ableger OpenUP entwickelt. Im zweiten Teilprojekt kam Scrum zum Einsatz. Die gesamte Projektdauer be-trug ein Jahr, die durchschnittliche Zahl der Projektmitglieder lag bei fünf. Die Funktionalität des Systems wurde aus 20 Anwendungsfällen zu den Bereichen System, Benutzer und Administrator abgeleitet.
Diese Projekte wurden ausgewählt, weil sie alle in einer Domäne Uni-versität am Beispiel der Philipps-UniUni-versität Marburg liegen und somit für den Wissensaustausch nach dem OBSE-Prozess geeignet sind. Gleichzeitig unterscheiden sie sich in mehreren Punkten voneinander und ermöglichen dadurch eine facettenreiche Untersuchung des OBSE-Prozesses. Folgende zentrale Fragestellungen können mit Hilfe dieser Projekte angesprochen werden:
• Die Gegenstandsbereiche der Projekte benden sich in unterschiedli-chen Bereiunterschiedli-chen der Universitäts-Domäne. Können die Projekte auch in diesem Fall von dem Wissenstransfer protieren?
• Unterschiedliche Programmiersprachen und Techniken bei der Anwen-dungsentwicklung machen es in der Regel unmöglich, Wiederverwen-dung auf der Entwurfs- oder Implementierungsebene einzusetzen. Ist dies auf der konzeptuellen Ebene mit OBSE gelungen?
Unabhängig von den Unterschieden in Projekten war bei der Evaluie-rung auÿerdem die Frage wichtig, ob und inwieweit mit Hilfe der Domänen-Ontologie die Qualität der Modelle in den Projekten verbessert werden konnte.
Der Ablauf der Evaluierung ist in dem Aktivitätsdiagramm in Ab-bildung 7.1 dargestellt. Die zeitliche Abfolge der Projekte wurde bei der Evaluierung beibehalten. So wurde das Projekt Scheinverwaltung als erstes und die Projekte SpSemOnline und FoPra-Verwaltung wurden anschlieÿend weitgehend parallel durchgeführt.
Als vorbereitenden Schritt für die Evaluierung, bei dem keine Analyse stattndet sondern zunächst die Domänen-Ontologie aufgebaut wird, wurde das Projekt Scheinverwaltung verwendet. Um möglichst viele Konzepte und Beziehungen aus der Domäne zu gewinnen, wurden sowohl die Anforderun-gen als auch der Code der Scheinverwaltung analysiert und als konzeptuelles Modell modelliert3. Auf das konzeptuelle Modell der Scheinverwaltung wur-de dann entsprechend wur-dem OBSE-Prozess die Export-Brücke angewenwur-det,
3Für weitere Informationen siehe auch [Hor10].
Abbildung 7.1: Evaluierung des OBSE-Prozesses
die ein Ontologie-Fragment zur Verfügung stellt. Da die Domänen-Ontologie zu diesem Zeitpunkt leer ist, wird dieses Fragment in die Ontologie ohne Integration übernommen.
Die Evaluierung der Projekte SpSemOnline und FoPra-Verwaltung wird parallel und auf die gleiche Weise durchgeführt. Für jedes Projekt werden zwei konzeptuelle Modelle erstellt:
rekonstruiertes KM Dieses Modell soll nur Konzepte und Beziehungen enthalten, die tatsächlich in dem jeweiligen Projekt umgesetzt wur-den. Aus diesem Grund wurden diese konzeptuelle Modelle in der Ak-tivität Erstelle KM des Projekts aus dem Code (SpSemOnline) oder UML-Modellen (FoPra-Verwaltung) rekonstruiert. Diese strukturier-te Aktivität ist in Abbildung 7.2 links detailliert dargesstrukturier-tellt. Im Falle von FoPra-Verwaltung reichte es auf Grund der Modell-basierten Ent-wicklung aus, nur das UML-Klassendiagramm einzubeziehen. Beim SpSemOnline-Projekt standen keine Modelle zur Verfügung.
Abbildung 7.2: Unterdiagramme des Evaluierungsablaufs
emuliertes KM Dieses Modell soll durch die Emulation der Analyse-Phase des OBSE-Prozesses (siehe Abbildung 7.2 rechts) entstehen. Die Quel-len für dieses Modell sind nur Anforderungen der Projekte und die Domänen-Ontologie. Dieses Modell wird somit unabhängig von der existierenden Projektrealisierung erstellt.
Schlieÿlich werden diese zwei Modelle verglichen (siehe Abbildung 7.1).
An dieser Stelle werden qualitative Unterschiede in der Modellierung ohne und mit OBSE untersucht.
Die Beurteilung der Modell-Qualität in diesem Schritt basiert auf der Klassikation von Fieber, Huhn und Rumpe [FHR08]. Die Autoren stellen eine Taxonomie auf, die auf der obersten Ebene zwischen der inneren und äuÿeren Qualität eines Modells unterscheidet. Dabei werden Qualitätsmerk-male, die ausschlieÿlich das untersuchte Modell betreen, der inneren Quali-tät zugeordnet. Die äuÿere QualiQuali-tät enthält Merkmale, die sich im Bezug auf andere Artefakte (meist Modelle) auswirken. Dieser Bereich wird zusätzlich in zwei Unterbereiche anhand der horizontalen und vertikalen Beziehungen zwischen Modellen aufgeteilt. Äuÿere horizontale Qualitätsmerkmale wir-ken sich auf Modelle aus, die in der gleichen Entwicklungsebene liegen. Ein Beispiel dafür ist ein Anforderungsmodell und ein zugehöriges, ergänzendes
Aktivitätsdiagramm. Äuÿere vertikale Merkmale betreen zugehörige Mo-delle auf verschiedenen Ebenen, wie im Falle von OBSE ein konzeptuelles und Analyse-Modell.
Die Taxonomie von Fieber, Huhn und Rumpe ist sehr breit gefächert, um alle Aspekte des Feldes Modellqualität abzudecken. Für die Evaluierung des OBSE-Prozesses spielen folgende Qualitätsmerkmale eine wichtige Rol-le, die anhand von entdeckten Unterschieden in den untersuchten Modellen identiziert wurden:
Präzision Nach diesem inneren Qualitätsmerkmal sollen alle relevanten Elemente der Domäne entsprechend der Detailliertheit des Modells wiedergegeben werden. Die Relevanz der Elemente ergibt sich aus den Anforderungen an das künftige System.
Einfachheit Einfachheit ist ein weiteres, inneres Qualitätsmerkmal, das be-sagt, dass die Modelle nicht komplizierter sein sollen als die Sachver-halte, die sie repräsentieren. Zum Beispiel soll die Verwendung von nicht relevanten Elementen vermieden werden.
konzeptionelle Integrität Dieses äuÿere horizontale Qualitätsmerkmal ver-langt, dass gleiche Sachverhalte auf gleicher Modellierungsebene auf die gleiche Art und Weise modelliert werden.
Verfolgbarkeit Verfolgbarkeit ist ein äuÿeres vertikales Merkmal. Dabei ist es wichtig, dass alle Elemente der unteren Ebenen zu ihrem Ursprung in den höheren Ebenen vervolgt werden können.
Korrektheit Korrektheit als ein äuÿeres vertikales Qualitätsmekmal bedeu-tet, dass das Modell die Anforderungen in den Modellketten präzise abbildet.
Änderbarkeit Änderbarkeit ist ein weiteres, äuÿeres, vertikales Qualitäts-merkmal, das sich wiederum aus den Merkmalen Wartbarkeit, Er-weiterbarkeit und Wiederverwendbarkeit zusammensetzt. Wartbarkeit ist der Aufwand, der betrieben werden muss, um im Modell Fehler zu beheben sowie Spezikationsänderungen zu modellieren. Erweiterbar-keit ist ein Maÿ für die LeichtigErweiterbar-keit, mit dem das System erweitert werden kann. Wiederverwendbarkeit ist die Eigenschaft des Modells, für andere Systeme oder andere Varianten des Systems z.B. in einer Produktlinie wiederverwendet werden zu können.
Neben dem speziell für die Evaluierung des OBSE-Prozesses vorgese-henen Vergleich der konzeptuellen Modelle lieferte noch eine Stelle in dem Evaluierungsablauf interessante Erkenntnisse über den OBSE-Prozess. Das ist die Anwendung der Import-Brücke in der Aktivität Emuliere
Projektver-lauf nach OBSE (siehe Abbildung 7.2 rechts). An dieser Stelle konnte die Auswirkung der Wiederverwendung auf der konzeptuellen Ebene untersucht werden.