Sie sind auf Seite 1von 64

Eine architekturelle Lsung zur Integration von Code-Entscheidungsmodellen in Evolutionssichten

Bachelorarbeit von

Michael Junker
An der Fakultt fr Informatik Institute for Software Design and Quality (SDQ)

Erstgutachter: Zweitgutachter: Betreuender Mitarbeiter: Zweiter betreuender Mitarbeiter:

Prof. Dr. Ralf H. Reussner Jun.-Prof. Dr. Anne Koziolek Dipl.-Inform. Martin Kster Dipl.-Inform. Benjamin Klatt

Bearbeitungszeit: 09. Juli 2013

08. November 2013

KIT Universitt des Landes Baden-Wrttemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft

www.kit.edu

Ich versichere wahrheitsgem a, die Arbeit selbstst andig angefertigt, alle benutzten Hilfsmittel vollst andig und genau angegeben und alles kenntlich gemacht zu haben, was aus Arbeiten anderer unver andert oder mit Ab anderungen entnommen wurde. Karlsruhe, 07.11.2013

......................................... (Michael Junker)

Zusammenfassung
Moderne Softwaresysteme werden oftmals von einem Team entwickelt und von einem v ollig anderen Team gewartet. Dadurch steht das Wartungsteam vor dem Problem die Software zuerst vollst andig verstehen zu m ussen, bevor Anderungen daran vorgenommen werden k onnen. Um Anderungen dann fehlerfrei zu implementieren muss das Wissen u ber jede Stelle, die ge andert werden muss, vorhanden sein. An dieses Wissen gelangt man jedoch oftmals nur durch langes durchsuchen der Software. Eine Art diese Suche zu vermeiden, ist es Entwurfsentscheidungen schon w ahrend dem Entwicklungsprozess ordnungsgem a zu dokumentieren. Dabei gibt es die unterschiedlichsten Arten von Entscheidungen, die getroen werden k onnen. Diese Bachelorarbeit charakterisiert bestimmte Entscheidungen und stellt einen modellbasierten Ansatz vor, der es erlaubt unterschiedliche Entscheidungsmodelle in einen Ansatz zu integrieren. Die Validierung dieses Ansatzes ndet dabei u ber ein Code-Entscheidungsmodell statt.

iii

Inhaltsverzeichnis

1. Einleitung 2. Grundlagen 2.1. Entscheidungsdokumentation . . . . . . . 2.2. Merkmale von Entscheidungen . . . . . . 2.3. Modellierung von Entwurfsentscheidungen 2.4. Erweiterungsm oglichkeiten der IDE . . . . 2.5. Verwandte Arbeiten . . . . . . . . . . . . 3. Konzeption 3.1. Das Kern-Entscheidungsmodell . . 3.2. Integriertes Entscheidungsmodell . 3.3. Migration zum f oderierten Ansatz 3.4. Architektur der Modelle . . . . . . 3.4.1. Schnittstellendenition . . . 3.4.2. Daten usse . . . . . . . . .

1 3 3 4 4 6 7 11 12 16 17 18 19 21 23 24 28 30 33 33 33 34 35 39 45 45 46 47 49 51 51 53 53 54 55

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

4. Implementierung 4.1. Erweiterbarkeit der Modellierung . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Denition des Extension-Points . . . . . . . . . . . . . . . . . . . . . . . . . 4.3. Laden der Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Validierung 5.1. Validierung u ber Code-Entscheidungsmodell 5.1.1. Zweck des Modells . . . . . . . . . . 5.1.2. Code-Entscheidungsmodell . . . . . 5.2. Implementierung der Extension . . . . . . . 5.3. Ergebnis der Anbindung . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

6. Zusammenfassung und Ausblick 6.1. Oene Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Literaturverzeichnis 7. Anhang A. Extension-Point-Schema . . . . . . . . . B. Manifest-Datei der Schnittstelle . . . . . C. Decision-Modell mit Code-Entscheidung D. ExtensionPointExecutor . . . . . . . . . E. CodeDecisionRelatableImpl-Klasse . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

1. Einleitung
Motivation Moderne Software besteht immer mehr aus einem Zusammenspiel unterschiedlicher Application Programmable Interfaces (APIs) und dem selbst geschrieben Code. Dabei nimmt der selbst geschriebene Code trotz einer Vielzahl an verf ugbaren Bibliotheken einen so groen Teil ein, dass Software heutzutage selten von einem Programmierer alleine geschrieben wird, sondern von einem ganzen Team. Dabei werden vor und w ahrend der Implementierung eines Projektes immer wieder Entwurfsentscheidungen getroen, die sich auf das sp atere Endprodukt auswirken. Das Dokumentieren dieser Entscheidungen, vor allem das Dokumentieren der Begr undung weswegen genau diese Entscheidung gew ahlt wurde, wird jedoch oftmals vernachl assigt. Das kann zur Folge haben, dass das sp atere Warten der Software unn otig komplizierter und vor allem mehr Aufwand ben otigt, als wenn die getroenen Entwurfsentscheidungen ordnungsgem a dokumentiert worden w aren. Dazu soll das folgende Szenario soll ein kleines Beispiel daf ur geben wieso diese Art der Dokumentation ebenso wichtig ist wie das Kommentieren einzelner Methoden oder Klassen. Angenommen es soll die M oglichkeit geben in einem Projekt zwei-dimensionale Objekte zu erzeugen. Der Einfachheit halber erben alle zwei-dimensionalen Objekte von einer Oberklasse. Man steht nun vor der Entscheidung entweder eine Fabrikmethode zur Erzeugung dieser Objekte zu verwenden oder jeweils einen Konstruktor. Nach Abw agung der Vor- und Nachteile entscheidet man sich am Ende dazu die Fabrik zu nehmen, da sich der sp atere Benutzer der Objekte dann nicht mehr um eine korrekte Parameter ubergabe k ummern muss, da die Fabrik das nun u undung bernimmt. Die Entscheidung, und vor allem die Begr daf ur die Fabrik zu verwenden, wurde allerdings in keinster Weise dokumentiert. Bei der sp ateren Wartung durch ein anderes Team von Software-Entwicklern m ochte man nun eine drei-dimensionale Repr asentation der Objekte erreichen. Dazu muss der Entwickler, der damit beauftragt wird, s amtliche Stellen im Programm nden, die ge andert werden m ussen, um drei-dimensionale Objekte zu erzeugen. Da die Entscheidung eine Fabrik zu verwenden nicht dokumentiert wurde, muss der Entwickler nun das komplette Projekt nach Stellen durchsuchen, die ge andert werden m ussen, um das Gew unschte zu erreichen. Zu diesen Stellen k onnten die Fabrikmethode selbst, aber unter Umst anden auch alle zu erzeugenden Objekte geh oren. Die Fehleranf alligkeit erh oht sich dadurch unweigerlich, da es bei vielen zu andernden Klassen vorkommen kann, dass welche Ubersehen werden und so das Programm am Ende nicht mehr funktioniert. Dieser Aufwand liee sich allerdings sparen, wenn solche Entscheidungen explizit dokumentiert werden, sodass klar ist, welche

1. Einleitung

Klassen zu einer Entscheidung geh oren und ver andert werden m ussen. An diesem Szenario kann man erkennen, dass eine Entscheidungsdokumentation Vorteile mit sich bringt. Der Aufwand Entwurfsentscheidungen zu dokumentieren ist dabei um ein Vielfaches geringer als der sp atere Aufwand alle Stellen im Code zu suchen, auf die eine Entscheidung Auswirkungen hat. Das hier gegebene Szenario ist nur ein Beispiel von vielen, dass die Dokumentation von Code-Entscheidungen sinnvoll macht. Neben CodeEntscheidungen kann es allerdings auch noch andere Entscheidungstypen geben, wie beispielsweise Architektur-Entscheidungen. Diese beziehen sich nicht auf den Code, sondern rein auf die Architektur des Software-Systems. Ziele F ur die vern unftige Dokumentation von Entscheidungen existieren bereits verschiedene Ans atze. Einen vollkommen eigenst andigen Ansatz daf ur zu entwickeln, w are also nicht unbedingt sinnvoll. Deswegen beschr ankt sich diese Arbeit darauf einen bestehenden Ansatz so zu erweitern, dass es zuk unftig m oglich ist vollkommen unterschiedliche Entscheidungstypen in den Ansatz zu integrieren, ohne dass am bestehenden Ansatz etwas ver andert werden muss. Zur Validierung dieses Ansatzes wird dann ein bisher unbekanntes CodeEntscheidungsmodell integriert. Mit Hilfe des Code-Entscheidungsmodells sollen solche Code-Entscheidungen, wie im Szenario beschrieben, dokumentiert werden k onnen. Aufbau der Arbeit Diese Bachelorarbeit ist wie folgt aufgebaut. Kapitel 2 befasst sich mit Grundlagen, auf denen diese Arbeit aufbaut. Diese beziehen sich zum Teil auf die Charakterisierung von Entscheidungen, aber auch wie Entscheidungen am sinnvollsten dokumentiert werden oder auch welche Vorteile die verwendete Entwicklungsumgebung mit sich bringt. Das darauf folgenden Kapitel befasst sich mit der Konzeption dieser Arbeit. In diesem Teil wird sowohl der bestehende Ansatz betrachtet, als auch das eigentliche Ziel dieser Arbeit verfolgt. Dieser Teil stellt und dessen Implementierung stellt damit den eigenen Beitrag dar. Die konkrete Implementierung des neuen Ansatzes, wird in Kapitel 4 betrachtet. Dabei werden die Erweiterungsm oglichkeiten der Entwicklungsumgebung ausgenutzt und die bestehende Implementierung so angepasst, dass sie dem Ziel der Arbeit entspricht. Validiert wird dieser Ansatz u ber ein einfaches Code-Entscheidungsmodell, auf das in Kapitel 5 eingegangen wird. Den Abschluss dieser Arbeit bildet eine Zusammenfassung und ein Ausblick dessen, was am implementierten Ansatz ver andert werden k onnte und wie dieser nun genutzt werden kann.

2. Grundlagen

2.1. Entscheidungsdokumentation
Durch das Szenario sollte klar geworden sein, dass das explizite Dokumentieren von Entscheidungen seine Vorteile mit sich bringt. Neben dem Vorteil der geringeren Fehleranf alligkeit bei der Wartung von Software, gibt es jedoch noch eine Reihe weiterer Vorteile. Diese Vorteile werden von [BB08] genannt. So sind diese unter Anderem eine erh ohte Lebensdauer des gesamten Projektes, da es viel besser zu warten ist als ein vergleichbares Projekt ohne Dokumentation von Entwurfsentscheidungen. Durch die Entscheidungs dokumentation k onnen viel mehr Anderungen am Projekt vorgenommen werden, ohne dass dieses durch ein komplett neues Projekt ersetzt werden muss, da bekannt ist, welche Anderungen am Projekt u oglich sind. Weiterhin dienen dokumentierte Entberhaupt m scheidungen im Verlauf der weiteren Entwicklung der Software dazu Anforderungen f ur andere Entscheidungen zu nden oder festzulegen. Wenn beispielsweise festgelegt wurde, dass ein Algorithmus in einer bestimmten Zeit durchgef uhrt sein muss, fallen automatisch Performance-schw achere Teil-Algorithmen heraus. Das hat des Weiteren zur Folge, dass alte Entscheidungen verwendet werden k onnen, um neue schneller zu klassizieren. Man muss sich nicht mehr Gedanken darum machen, welches Entwurfsmuster verwendet werden soll, wenn man bereits eine dokumentierte Entscheidung dieser Art in einer ahnlichen Situation getroen hat. Ebenso entsteht durch das Dokumentieren von Entwurfsentscheidungen ein Transfer von Wissen zwischen einzelnen Akteuren. So wei nicht nur der, der die Entscheidung gef allt hat u ber die Entscheidung Bescheid, sondern auch andere Akteure, die m oglicherweise mit dieser Entscheidung im Verlaufe eines Projektes zu tun haben. Als letzten Vorteil nach Burge dient die Dokumentation als eine Art Ged achtnisst utze, sodass es im Nachhinein einfacher ist getroene Entscheidungen zu rekapitulieren und, falls man sich noch immer im Prozess der Umsetzung der Entscheidung bendet, sich beispielsweise nicht st andig Gedanken u ber Alternativen zu machen, die bereits aus guten Gr unden verworfen wurden. Eine weitere Arbeit, die sich unter Anderem mit der expliziten Dokumentation von Entwurfsentscheidungen und deren Vorteilen befasst ist [VPS96]. Zus atzlich zu den bereits genannten Vorteilen, wird hier noch explizit klargestellt, dass die Dokumentation von Entwurfsentscheidungen f ur den Kunden oftmals die einzige M oglichkeit darstellt das Projekt richtig beurteilen zu k onnen. Dies entsteht daraus, dass, im Falle eines Software-Projektes, sich der Kunde nicht notwendigerweise mit der Programmiersprache der Software auskennt. Selbst wenn f ur den Kunden die Programmiersprache bekannt ist, bedeutet das noch nicht,

2. Grundlagen

dass sich der Kunde den kompletten bestehenden Code anschaut. Die Entscheidungsdokumentation ist dabei viel k urzer und kann zusammen mit der Quellcode-Dokumentation als Nachschlagewerk dienen.

2.2. Merkmale von Entscheidungen


Wenn man sich Gedanken dar uber macht, was eine Entscheidung alles ausmacht, l asst sich die Denition von [WML+ 89] gut verwenden. Demnach besteht eine Entscheidung immer aus einem gegebenen Problem, dass es zu l osen gilt, einer oder mehreren Alternativen, die zur L osung dieses Problems verwendet werden k onnen, der gew ahlten L osung f ur dieses Problem und einer Erkl arung. Die gew ahlte L osung ist dann die getroene Entscheidung. Eine Erkl arung bzw. Rechtfertigung zur gew ahlten L osung sollte es immer geben, da nur so sp ater auch wirklich nachvollzogen werden kann wieso diese Alternative gew ahlt wurde und nicht eine andere. Diese Vorgehensweise ist wichtig, um nicht vorschnell eine Alternative auszuw ahlen, die in dieser Situation nicht passt. Diese Art der Dokumentation einer Entscheidung kann Situationen bei der Wartung des Projektes vereinfachen, wenn es darum geht getroene Entscheidungen anpassen zu m ussen. Die Denition von Wild et al wird von [CND07] noch ein wenig erweitert. Bei ihm beseht eine Entscheidung nicht nur aus einem Problem, mehreren Alternativen, einer gew ahlten L osung und einer Erkl arung zur gew ahlten L osung, sondern aus weiteren Attributen. Diese Attribute lassen sich unterteilen. Zum einen fallen Attribute darunter, die direkt mit einer Entscheidung assoziiert werden k onnen. Dies sind f ur Capilla et al sogenannte Pichtattribute. Zum anderen z ahlt er optionale Attribute auf, die zu dokumentieren f ur eine Entscheidung praktisch sein k onnen, aber nicht zwingend dokumentiert werden m ussen. Beispiele f ur optionale Attribute sind Interessengruppen oder in wessen Verantwortlichkeit die Entscheidung liegt. Hingegen sind Beispiele f ur Pichtattribute ein Entscheidungsname und -beschreibung, Constraints oder der Status der jeweiligen Entscheidung (noch ausstehend, verworfen, etc.). Alle hier aufgez ahlten und weitere Attribute werden vom bestehenden Kern-Entscheidungsmodell unterst utzt. Auf dieses Kern-Entscheidungsmodell wird in Kapitel 3.1 n aher eingegangen.

2.3. Modellierung von Entwurfsentscheidungen


Da nun bekannt ist, dass eine Entwurfsentscheidung nicht nur aus einem Freitext besteht, der die Entscheidung beschreibt, lohnt es sich u oglichkeiten zu diskutieren diese Entber M wurfsentscheidungen ordnungsgem a zu dokumentieren. Dabei gibt es viele unterschiedliche M oglichkeiten. Auf die g angigsten soll in diesem Abschnitt eingegangen werden. Dokumentation u ber Quellcode-Kommentare Die einfachste M oglichkeit w are Entscheidungen im Quellcode zu dokumentieren. Eine Quellcode-Dokumentation in Form von Kommentaren u ber Methoden oder Klassen sollte ohnehin gemacht werden, sodass es keinen groen Mehraufwand bedeuten w urde noch die Entscheidungen dahinter zu dokumentieren. Diese M oglichkeit bringt allerdings einige Nachteile mit sich. Nicht alle Entscheidungen, die getroen werden m ussen, sind Entscheidungen, die sich direkt auf den Quellcode beziehen. Andere Beispiele von Entscheidungen, die nichts mit dem Quellcode zu tun haben, sind beispielsweise die Wahl des Servers, auf dem eine Webapplikation laufen soll. Weiterhin gibt es funktionale Anforderungen an ein Projekt. Diese werden schon lange vor der Implementierung getroen und es w are deswegen unangebracht diese Entscheidungen erst im Quellcode zu erw ahnen. Ein letztes Beispiel hierf ur w aren architekturelle Artefakte eines Software-Systems, also beispielsweise Klassenoder Sequenzdiagramme. Weiterhin sind die dokumentierten Entwurfsentscheidungen bei

2.3. Modellierung von Entwurfsentscheidungen

dieser Methode nur dezentral vorhanden. Das hat zur Folge, dass man jede Klasse im Code absuchen m usste, um Entscheidungen zu nden, die im Bezug zueinander stehen. Bei gr oeren Programmen kann dies jedoch l angere Zeit in Anspruch nehmen, die an anderer Stelle besser aufgehoben ist. Weiterhin beziehen sich selbst Code-Entscheidungen nicht immer nur auf eine einzige Methode oder Klasse. Die Verwendung der Methode oder Klasse k onnte dabei auch eine Entscheidung sein, wodurch man f ur jede einzelne Verwendung den gleichen Dokumentationstext br auchte, der schon an anderer Stelle steht. Dies w urde das Programm jedoch viel zu un ubersichtlich machen. Ein letzter Punkt, der gegen eine Entscheidungsdokumentation in Form von Kommentaren im Quellcode spricht, ist der das Kommentare kurz und pr agnant gehalten werden sollten. Wie jedoch aus 2.2 hervorgegangen ist, haben Entscheidungen gen ugend Attribute, die den Kommentar um einiges l anger machen w urden, als die Methode oder Klasse eigentlich lang ist. Dokumentation u ber Verwaltung eines Dokumentes Eine weitere Art der Dokumentation von Entwurfsentscheidungen stellt das Anlegen eines So k Dokumentes dar (Word-Dokument o.A.). onnen alle Entscheidungen zumindest zentral verwaltet werden. Ebenso k onnen Entwurfsentscheidungen dokumentiert werden, die nichts mit dem eigentlichen Code zu tun haben. Weiterhin ist es m oglich vor-formatierte Seiten zu erstellen, sodass eine gewisse Ubersicht erhalten bleibt. Das Suchen nach bestimmten Entscheidungen kann allerdings immer noch lange dauern, da bei gr oeren Projekten auch viele zu dokumentierende Entscheidungen vorhanden sind. Ebenso m usste das zugeh orige Artefakt zu einer Entscheidung gesucht werden, falls diese ge andert werden soll. Auch diese Suche kann entsprechend lange dauern, wenn man nicht mit dem Aufbau des Software-Systems vollst andig vertraut ist. Ein weiteres Problem besteht darin, dass das Dokument nur lokal verf ugbar ist. Es muss also auf dem Server, auf dem sich das Projekt bendet, Platz f ur das Dokument geschaen werden, sodass jeder beteiligte des Projektes auch auf das Dokument zugreifen und es gegebenenfalls anpassen kann. Ein letzter Nachteil dieser Art der Dokumentation gilt f ur den Fall, dass neue Entscheidungstypen (z.B. Code-Entscheidungen) hinzukommen. Dann muss das komplette Layout des Dokumentes ge andert werden, um die zus atzlichen Attribute des Entscheidungstyps unterst utzen zu k onnen. Anlegung eines semantischen Wikis Eine M oglichkeit, um zumindest dem zu entgehen, dass das Dokument nur lokal verf ugbar ist, liegt im Anlegen eines semantischen Wikis, zu dem jeder Mitarbeiter am Projekt Zugri hat. Mit semantischen Wikis ist es m oglich viele Entscheidungen anzulegen und dennoch die Ubersicht zu erhalten. Weiterhin ist es m oglich Entwurfsentscheidungen in Bezug zueinander zu setzen, sodass man ausgehend von einer Entscheidung alle von dieser Entscheidung abh angigen Entwurfsentscheidungen nden kann. Ein Nachteil, den semantische Wikis allerdings mit sich bringen, ist, dass ein Wechsel der Technologie n otig ist. Es ist nicht m oglich zum einen in der Entwicklungsumgebung das Programm zu schreiben und zum anderen getroene Entscheidungen zu dokumentieren, da immer zwischen der Entwicklungsumgebung und dem Wiki hin und her gewechselt werden muss. Modellbasierte Ans atze Um das Wechseln der Technologie vermeiden zu k onnen, besteht die M oglichkeit einen modellbasierten Ansatz zu verwenden, um Entwurfsentscheidungen zu dokumentieren. Ein modellbasierter Ansatz hat sicherlich den mit Abstand gr oten Aufwand im Vergleich zu den anderen M oglichkeiten, bringt jedoch auch viele Vorteile mit sich. Zum Einen muss dieses Modell nur ein einziges Mal modelliert werden, um f ur beliebige Projekte Entwurfsentscheidungen dokumentieren zu k onnen. Weiterhin gelten die gleichen Vorteile wie die

2. Grundlagen

eines semantischen Wikis. Es muss zwar das Modell, das alle getroenen Entwurfsentscheidungen enth alt, auch immer wieder auf einen Server hochgeladen werden, sodass alle Mitarbeiter Zugri auf dieses Modell haben, jedoch kann dieses Modell zusammen mit dem Rest des Projektes aktualisiert werden. Damit ergibt sich auch ein weiterer Vorteil, den ein modellbasierter Ansatz mit sich bringt. Es ist kein Wechsel der Technologie mehr n otig, da der Ansatz so modelliert werden kann, dass er zusammen mit der Entwicklungsumgebung einsetzbar ist. Ein letzter Vorteil, der f ur einen modellbasierten Ansatz spricht, ist der, dass bei guter Modellierung das Einh angen zus atzlicher Entscheidungsmodelle, wie beispielsweise einem Code-Entscheidungsmodell, kein Problem mehr darstellt. Aufgrund dieser Vorteile, wird in dieser Arbeit der modellbasierte Ansatz n aher verfolgt und das vorhandene Modell so umgebaut, dass es ohne weiteres m oglich ist, weitere Entscheidungsmodelle diesem Ansatz hinzuzuf ugen.

2.4. Erweiterungsm oglichkeiten der IDE


Da das bestehende Modell so umgebaut werden soll, dass eine Erweiterbarkeit in dem Sinne gegeben ist, dass spezische Entscheidungsmodelle in den bestehenden Ansatz integriert werden k onnen ohne den bestehenden Ansatz zu andern, lohnt es sich sich u ber Erweiterungsm oglichkeiten der Entwicklungsumgebung (kurz: IDE ) Gedanken zu machen. Als Entwicklungsumgebung wird f ur diesen Ansatz Eclipse verwendet, weswegen sich die Erweiterungsm oglichkeiten auch ausschlielich auf Eclipse beziehen. Egal ob es sich bei der Entscheidungsdokumentation um Code-Entscheidungen oder rein architekturelle Entscheidungen handelt, alle Entscheidungen haben im Kern die gleichen Attribute. Deshalb erscheint es sinnvoll ein Modell zu denieren, dass eben diese Attribu te abdeckt. Dieses Modell kann dann von anderen Modellen erweitert werden. Ubertr agt man diese Vorgehensweise nun auf Eclipse, liee sich f ur das Kern-Modell ein Plug-in denieren und f ur die spezischeren Modelle jeweils ein weiteres Plug-in. Nun besteht eine M oglichkeit darin die einzelnen Plug-ins voneinander wissen zu lassen und so die entsprechenden weiteren Informationen zu einer Entscheidung abzurufen. Das h atte jedoch zur Folge, dass keine Erweiterbarkeit im oben genannten Sinne m oglich ist, da jedes Modell bei Hinzukommen oder Wegfallen eines anderen Modells neu angepasst werden m usste. Eine andere M oglichkeit, ohne jedes mal alle Plug-ins andern zu m ussen, besteht in sogenannten Extension-Points, die Eclipse bietet. Extension-Points werden in Eclipse dazu verwendet, um zwischen Plug-ins interagieren zu k onnen. Dabei stellt eines der beiden Plug-ins den Extension-Point zur Verf ugung, w ahrend das andere Plug-in den Extension-Point verwendet. Der Vorteil besteht darin, dass das Plug-in, das den Extension-Point bereit stellt, keine genauen Informationen zu den Plug-ins ben otigt, die den Extension-Point verwenden. Es k onnen weiterhin beliebig viele Plug-ins den bereitgestellten Extension-Point gleichzeitig verwenden, ohne dass Anpassungen gemacht werden m ussen. Das Plug-in, das den Extension-Point zur Verf ugung stellt, kann diesen dabei an mehrere Bedingungen kn upfen. Das kann f ur das Plug-in, das den Extension-Point verwendet (kurz: Die Extension ) bedeuten, dass ein Boolescher Wert, ein String, eine ID oder eine Ressource bereit gestellt werden muss. Das kann jedoch auch bedeuten, dass entweder mindestens ein Interface und/oder mindestens eine abstrakte Klasse von der Extension implementiert werden m ussen, damit die Anbindung an den Extension-Point korrekt funktionieren kann. Die Informationen bez uglich eines erstellen Extension-Points werden in einem Schema mit der Dateiendung .exsd gespeichert. Das Schema verwendet dabei die Extensible Markup Language, (kurz: XML) und kann somit von jedem beliebigen Text-Editor ge onet und ver andert werden. Jedoch stellt Eclipse eine graphische Ober ache bereit, in der die einzelnen Komponenten des Schemas ge andert werden k onnen. Die Eclipse IDE zeigt hierbei selbst, dass die Verwendung von Extension-Points funktioniert. Beispielsweise k onnen sogenannte Views u ber einen Extension-Point in die aktuelle Eclipse-Umgebung eingebettet werden und tau

2.5. Verwandte Arbeiten

Abbildung 2.1.: Illustration der verf ugbaren UML Elemente mit AREL - Quelle: [TJH07] Fig. 11 chen dann in einer Reihe mit den anderen Views wie beispielsweise der Konsole oder dem Projekt-Explorer auf. F ur die L osung des in dieser Arbeit vorgestellten Problems, wird demnach bei der Implementierung in Kapitel 4 auf den Extension-Point-Mechanismus zur uckgegrien.

2.5. Verwandte Arbeiten


Dieser Abschnitt soll einen Uberblick u ber bereits bestehende, verwandte Arbeiten geben. Die verwandten Arbeiten werden hierbei in drei Bereiche eingeteilt, die auch von dieser Arbeit angesprochen werden. Zu diesen Bereichen z ahlen der Bereich der Entscheidungsdokumentation, in dem verwandte Modelle betrachtet werden, die es auch erm oglichen Entwurfsentscheidungen zu dokumentieren. Weiterhin wird der Bereich API-Design betrachtet. Da der hier vorgestellte Ansatz auch eine nach Auen hin verf ugbare API bereitstellt, lohnt sich ebenfalls einen Blick in diesen Bereich. Der letzte Bereich der verwandten Arbeiten, der hier betrachtet werden soll, ist der Bereich der Nachverfolgbarkeit. Da der bisherige Ansatz so umgebaut werden soll, dass es m oglich ist zu einfachen Entscheidungen spezische Artefakte, die sich nur in speziellen Entscheidungsmodellen existieren, zu nden, stellt der Bereich Nachverfolgbarkeit auch eine wichtige Quelle an verwandten Arbeiten dar. Entscheidungsdokumentation Nach [TJH07] ist die explizite Dokumentation von Entscheidungen oftmals unstrukturiert. Deswegen wird in diesem Paper ein Ansatz vorgestellt, der es erlaubt Entscheidungen auf architektureller Ebene zu dokumentieren und diese mit Entwurfs-Artefakten in Verbindung zu bringen. F ur diesen Ansatz wurde die Unied Modeling Language (kurz: UML) verwendet. Der vorgestellte Ansatz erweitert das bisherige UML-Prol um die in Abbildung 2.1 auf der linken Seite gelisteten Elemente. AREL steht hierbei f ur Architecture Rationale and Elements Linkage, also das Festhalten von architekturellen Entscheidungen und das Verbinden der einzelnen Entscheidungen miteinander. F ur architekturelle Design-Entscheidungen bietet dieser Ansatz eine Erweiterbarkeit. Es lassen sich weitere Elemente hinzuf ugen, um die Entwicklung der architekturellen

2. Grundlagen

Entscheidungen n aher zu beleuchten. Allerdings unterst utzt dieser Ansatz keine gezielte Erweiterbarkeit bez uglich neuer Entscheidungsmodelle. Um diese in den bestehenden Ansatz einzugliedern, muss das komplette Modell angepasst werden und es w urde eine integrierte L osung entstehen, die schwieriger zu warten ist. Aufgrund dessen ist dieses Modell nicht f ur das weiter oben formulierte Ziel geeignet. Ein weiteres, bestehendes Modell ist das von [KZ10]. Nach K onemann und Zimmermann sind momentane Decision-Management-Systeme isoliert von den eigentlichen Modellen der modellbasierten Softwareentwicklung. Deswegen wird in diesem Paper eine Verbindung zwischen Entwurfsmodellen und Entwurfsentscheidungen hergestellt. Das von ihnen erzeugte Modell basiert auf dem Eclipse Modeling Framework (EMF). Damit stellt dieses Modell eine Erweiterung zur Eclipse IDE dar. Dieser Ansatz bezieht sich allerdings lediglich darauf eine Verbindung zwischen einer EMF-Komponente und der Entscheidung dahinter herzustellen. Somit kann dieser Ansatz auch nicht weiter verfolgt werden, wenn Code-Entscheidungen mit einbezogen werden sollen. Als letztes soll hier noch das System von [CND07] vorgestellt werden. Das in dem Paper vorgestellte System heit Architecture Design Decision Support System (kurz: ADDSS). ADDSS ist ein Web-basiertes Werkzeug, um architekturelle Entwurfs-Entscheidungen aufzunehmen und zu verwalten. Dabei werden vorgegebene Muster angeboten, um das Aufnehmen der Entscheidungen m oglichst einfach zu gestalten. Sollte keines der Muster allerdings passen, ist es m oglich Freitext zu verwenden, um die getroene Entscheidung zu dokumentieren. F ur diesen Ansatz ist es m oglich neben architekturellen Entscheidungen auch Code-Entscheidungen oder Andere in den Ansatz zu integrieren und anzulegen. Da dieser Ansatz jedoch ein Web-basiertes Werkzeug darstellt, muss immer ein Wechsel der Technologie stattnden, um eine neue Entscheidung anzulegen. Weiterhin ist es nur schwer m oglich n utzliche weitere Features in diesen Ansatz zu implementieren wie beispielsweise eine Direktansicht des Architektur-Artefakts, auf das sich die Entscheidung bezieht. Ebenso ist es auch f ur diesen Ansatz nicht m oglich neue Entscheidungsmodelle so zu integrieren, dass keine bestehenden Artefakte angepasst werden m ussen. API-Design Dieser Abschnitt bezieht sich auf [SM07]. Nach Stylos verbessern APIs die Produktion von Programmen durch erh ohte Wiederverwendbarkeit von Code. Eine API stellt dabei eine Menge von Schnittstellen (Interfaces) zwischen zwei Komponenten im selben Programm dar. Dadurch, dass diese Denition eine relativ groe Menge umfasst, werden in diesem Paper Kriterien genannt, die eine API gut machen. Dabei werden zwischen zwei Basis-Qualit aten einer guten API unterschieden. Zum einen ist dies die Verwendbarkeit der API, also der Nutzen der API beim Erschaen und Debuggen von Code und enth alt unter Anderem Attribute wie die Einfachheit der API, die Erlernbarkeit oder die Produktivit at der Programmierer beim Verwenden der API. Die zweite Basis-Qualit at ist M achtigkeit der API, also die Grenzen des Codes, der damit erzeugt werden kann. Diese Basis-Qualit at enth alt unter Anderem Attribute wie die Erweiterbarkeit, die Performance oder die Robust- bzw. Fehlerfreiheit der API. Beim Entwurf einer API m ussen jedoch auch Entscheidungen betrachtet werden, n amlich die, die im direkten Bezug dazu stehen. Solche Entscheidungen sind unter Anderem welche Klassen und Interfaces bereitgestellt werden sollen, ob spezielle ProgrammiersprachenFeatures wie statische oder synchronisierte Methoden zum Einsatz kommen oder ob das Objekt mittels einer Fabrik erzeugt werden muss oder aber mittels einem Konstruktor. Weitere Themen u uckgegeben werden ber die es sich lohnt zu diskutieren sind ob null zur soll, eine Exception geworfen wird oder ein leeres Objekt zur uckgegeben wird. Die Wichtigkeit einer Entscheidung im API Entwurf l asst sich immer anhand von vier Kriterien abw agen, wobei keines der vier Kriterien im Allgemeinen als wichtiger als das

2.5. Verwandte Arbeiten

andere eingestuft werden kann und die Wichtigkeit somit immer situationsabh angig ist. Zu den vier Kriterien z ahlen : 1. Die H augkeit beim Entwurf: Wie oft kommt diese Entscheidung im Entwurf der API vor? (Beispiel: Namenskonventionen) 2. Die Schwierigkeit beim Entwurf: In wie fern sich API-Entwickler suboptimal entscheiden k onnen 3. Die H augkeit beim Benutzen: Befasst sich mit der H augkeit mit der die Benutzer der API mit der Entscheidung konfrontiert werden 4. Die Schwierigkeit beim Benutzen: Befasst sich damit wie teuer eine schlecht getroene Entscheidung f ur den API-Benutzer ist Beim Entwurf der API f ur diese Bachelorarbeit habe ich mich nach dieser Arbeit gerichtet, um eine m oglichst einfach zu bedienende API bereitstellen zu k onnen. Nachverfolgbarkeit Da das Ziel dieser Arbeit mitunter darin besteht ausgehend von einer Entscheidung spezischere Artefakte nachverfolgen zu k onnen, die in anderen Entscheidungsmodellen liegen, lohnt sich auch einen Blick zu den verwandten Arbeiten im Bereich der Nachverfolgbarkeit. Dazu werden zun achst einige Grundlagen betrachtet, die auch auf diese Arbeit angewendet werden k onnen. Nach [GCHH+ 12] werden Elemente deniert, die f ur eine Nachverfolgbarkeit unerl asslich sind. Zu diesen Elementen geh ort beispielsweise ein sogenanntes Trace Artifact. Im Zuge von Entscheidungsmodellen ist so ein Trace Artifact mindestens ein Artefakt einer Entscheidung. Diese Artefakte lassen sich noch weiter unterteilen in Quell- und Zielartefakte und haben immer einen bestimmten Typ. Dieser kann zum Beispiel eine Anforderung, ein Entwurf oder ein Testfall sein. Weitere Elemente sind Trace Links als Verbindung zwischen einem Quell- und einem Zielartefakt oder Trace Relation als Zusammenfassung aller Trace Links zwischen Trace-Artefakten des selben Typs. Trace Links k onnen gerichtet oder aber auch ungerichtet sein. F ur den in dieser Arbeit vorgestellten Ansatz werden existieren nur gerichtete Trace Links, also von einer Entscheidung zu ihren spezischeren Artefakten, die in anderen Entscheidungsmodellen liegen. Die M oglichkeit der Nachverfolgbarkeit hat nach [IR12] vor allem Kostenvorteile, sofern die gegebene Nachverfolgbarkeit von einer guten Qualit at ist. Demnach lohnt es sich nur so ein System einzuf uhren, wenn damit ein bestimmtes Ziel erreicht werden kann, da sonst die Kosten zu hoch werden. Wenn ein Ziel jedoch ist, dass das Projekt u angeren ber einen l Zeitraum gewartet werden soll, l asst sich mit Hilfe der Nachverfolgbarkeit unn otiges Suchen im Quellcode verhindern und somit schneller Punkte nden, an denen das Programm wie gew unscht erweitert werden kann. Zuletzt sei hier noch einmal die Arbeit von [TJH07] erw ahnt, da das dort vorgestellte Modell (siehe 2.1) Nachverfolgbarkeit unterst utzt. Wie bei [GCHH+ 12] wird bei [TJH07] die Nachverfolgbarkeit mittels den Trace-Artefakten und Trace Links unterst utzt. Die Nachverfolgbarkeit bei Tang ist bidirektional, somit ist eine Auswirkungsanalyse und eine R uckw artsverfolgung zum Finden der Wurzel der gew ahlten Entscheidung m oglich. F ur eine Auswirkungsanalyse bzw. eine R uckw artsverfolgung muss jedoch entweder ein Graph vorhanden sein oder eine Entscheidung muss zumindest andere nachfolgende Entscheidungen kennen, die mit der Entscheidung in Verbindung stehen. Der bisherige und der hier erarbeitete Ansatz unterst utzt dies jedoch nicht.

3. Konzeption
Wie bereits in der Einleitung dieser Arbeit erw ahnt, sollt hier ein modellbasierter Ansatz zur Dokumentation von Entwurfsentscheidungen entstehen. F ur diesen gibt es zwei M oglichkeiten. Zum einen kann das ein integrierter Ansatz sein, in dem alle Entscheidungstypen (Code-Entscheidungen und architekturelle Entscheidungen) vereint sind. Dieser Ansatz wurde bereits f ur ein Architektur-Entscheidungsmodell implementiert. Zum anderen kann das ein f oderierter Ansatz sein, bei dem die Entscheidungstypen in unterschiedlichen Modellen liegen. Beide Ans atze werden in diesem Kapitel betrachtet und deren Vor- und Nachteile gegeneinander aufgewogen. Der Ansatz, der im Laufe dieser Arbeit weiter verfolgt wird, sollte jedoch m oglichst erweiterbar sein, sodass auch weitere Typen von Entscheidungen, die zum jetzigen Zeitpunkt noch nicht bekannt sind, in den Ansatz integriert werden k onnen. Um diese Eigenschaft gew ahrleisten zu k onnen, muss man sich vorher jedoch um die Art der Entscheidungen Gedanken machen. Jeder Typ von Entscheidung kann hierbei unterschiedliche Eigenschaften haben. Eine Code-Entscheidung beispielsweise k onnte als Eigenschaft Referenzen zum Quellcode haben. Somit k onnte man direkt von der Entscheidung in den Quellcode springen und sehen welche internen Auswirkungen die Entscheidung hat und sie gegebenenfalls anpassen. Eine rein architekturelle Entscheidung hingegen wird so eine Eigenschaft auf keinen Fall besitzen. Es ist also wichtig zuerst Eigenschaften zu identizieren, die f ur alle Entscheidungstypen gelten. Da diese Bachelorarbeit auf vorhandenen Arbeiten aufbaut, existiert bereits ein Modell, das den gemeinsamen Nenner aller Entscheidungstypen darstellt. Dieses Modell, das Kern-Entscheidungsmodell, wird in diesem Kapitel zuerst betrachtet. Nach der Betrachtung des Kern-Entscheidungsmodells folgt die Analyse der beiden modellbasierten Ans atze. Das konzeptionelle Ziel der Arbeit stellt hierbei der Umbau des bisherigen Ansatzes zum f oderierten Ansatz dar. Ziel der Migration zum f oderierten Ansatz ist dann, f ur das Kern-Entscheidungsmodell unbekannte Artefakte, die zu einem spezischen Entscheidungstyp geh oren, darstellen zu k onnen. Der Umbau erfolgt dabei so, dass es sp ater m oglich ist weitere Entscheidungsmodelle in den Ansatz zu integrieren, ohne den bestehenden Ansatz anpassen zu m ussen. Zusammen mit dem Umbau werden auch die einzelnen Komponenten genauer betrachtet, die zu diesem Umbau beitragen. Dabei wird ebenso auf den nun entstandenen Datenuss eingegangen, der zwischen den einzelnen Komponenten besteht, sodass die Darstellung spezischer Entscheidungsmerkmale m oglich ist. Der konzeptionelle Teil dieser Arbeit wird vollkommen unabh angig von einer Entwicklungsumgebung behandelt und l asst sich somit auf alle objektorientierten Sprachen unter Verwendung von beliebigen Entwicklungsumgebungen anwenden. Eine konkrete Implementierung dieses Ansatzes ndet im nachfolgenden Kapitel in der Sprache Java und der Eclipse IDE statt.

11

12

3. Konzeption

3.1. Das Kern-Entscheidungsmodell


Wie im einleitenden Teil dieses Kapitels beschrieben, soll dieser Abschnitt das bereits vorhandene Kern-Entscheidungsmodell behandeln. Das ist n utzlich, um sp ater zu verstehen welche Teile dieses Modells erweitert und somit f ur andere Entscheidungsmodelle verwendet werden k onnen. Das Kern-Entscheidungsmodell soll die Grundlage des modellbasierten Ansatzes darstellen. Das Kern-Entscheidungsmodell bildet hierbei ein Modell, das es erm oglicht grundlegende Entscheidungen zu dokumentieren. Es ist also komplett eigenst andig und auch ohne Erweiterungen verwendbar. Dabei besteht es aus zwei gr oeren Komponenten, die beide in diesem Abschnitt behandelt werden. Zum einen ist das die Komponente, die sich mit dem sogenannten Decision Model, also dem Modell, das in der Implementierung alle Entscheidungen verwaltet, befasst. Zum anderen ist das die Komponente, die sich mit dem Issue Model befasst. Wie in 2.2 bereits erw ahnt, referenziert jede Entscheidung mindestens ein Problem, das von der Entscheidung gel ost wird. Das Issue Model beinhaltet dabei unter Anderem alle gel osten und noch zu l osenden Probleme. In den folgenden Paragraphen wird erkl art wie diese beiden Komponenten miteinander zusammenh angen. Dabei wird zuerst auf das Issue Model eingegangen, da das Decision Model Teile des Issue Models verwendet. Issue Model Dieser Abschnitt behandelt das bestehende Issue Model, das im Kern-Entscheidungsmodell verwendet wird. Das Modell selbst ist in Abbildung 3.1 dargestellt. Die beiden Hauptklassen in diesem Modell sind Issue und IssueModel. Letztere stellt hierbei die Klasse dar, die unter Anderem eine Liste aller vorhanden Probleme enth alt. Im Modell sieht man ebenso, dass alle Referenzen, die von dieser Klasse ausgehen, Kompositionen sind. Das bedeutet, dass die anderen Klassen, zu denen das IssueModel Referenzen hat, nur dann existieren k onnen, wenn es bereits eine Instanz des IssueModels gibt. Wenn es ein solches IssueModel gibt, k onnen in dieses weitere Objekte eingebunden werden. Dies k onnen beispielsweise Projekte sein (Project ), die in Verbindung zu diesem spezischen IssueModel stehen oder auch Versionen (Version ). Alle Kompositionen, mit Ausnahme der Komposition zur Klasse Issue, die von der Klasse IssueModel ausgehen, existieren von der Klasse Issue ausgehend als Assoziation. Das wiederum bedeutet, dass eine Instanz der Issue-Klasse bereits vorhandene Instanzen der anderen Klassen referenzieren kann. Zu diesen Klassen geh oren User, Component und die beiden bereits erw ahnten Klassen Project und Version. Somit ist es beispielsweise m oglich einem Problem weitere beteiligte Komponenten zu verlinken, falls die Attribute der Issue-Klasse nicht ausreichen, um das Problem eindeutig zu klassizieren. Weiterhin erbt die Issue-Klasse von der Klasse UpdatableElement. Das hat zur Folge, dass ein Issue-Objekt zwei weitere Attribute erh alt. Zum einen ist das das Datum, an dem das Problem identiziert wurde und zum anderen das Datum, an dem das Problem zuletzt aktualisiert wurde. Die weiteren wichtigen Attribute dieser Klasse sind eine eindeutige ID des Problems (key ), eine kurze Zusammenfassung sowie eine Ausf uhrliche Beschreibung des Problems. Weiterhin ist ein Status unabdingbar, sodass f ur alle Benutzer des IssueModels klar ist, ob ein Problem bereits gel ost wurde oder ob es weiterhin besteht. Falls ein Problem gel ost wurde, kann dies im Attribut resolution beschrieben werden. Diese Dokumentation kann f ur zuk unftige Probleme n utzlich sein, die ahnlich zum bereits gel osten Problem sind. F ur das Projektmanagement noch wichtig ist das Attribut priority. Damit k onnen verschiedenen Probleme priorisiert werden, sodass nicht die unwichtigen Probleme zuerst angegangen werden. Nun bestehen zwei Referenzen von der Klasse Issue zur Klasse Version. Die obere Referenz gibt dabei die Versionen an, die von diesem Problem betroen sind, w ahrend die untere Referenz die Versionen angibt, zu denen das Problem nicht mehr bestehen soll. Eine Version hat dabei wie ein Problem immer eine Beschreibung. Die Beschreibung sollte hierbei das Projekt beinhalten, auf das

12

3.1. Das Kern-Entscheidungsmodell

13 13

Abbildung 3.1.: IssueModel-Komponenten des kern-Entscheidungsmodells - Quelle: [Unk]

14

3. Konzeption

sich diese Version bezieht. Das ist deshalb n otig, da das IssueModel mehrere Projekte verwalten kann. Weiterhin besitzt die Klasse Version zwei boolesche Attribute. Das erste Attribut gibt dabei an ob die Version bereits archiviert wurde, w ahrend das zweite angibt, ob die Version bereits ver oentlicht wurde. Das letzte Attribut dieser Klasse gibt das Ver oentlichungsdatum dieser Version an. Weitere relevante Referenzen, die von Issue ausgehen, beziehen sich auf die Klasse User. Zum einen gibt es zwei direkte Referenzen auf diese Klasse. Die Referenz reporter stellt den Benutzer dar, der das Problem entdeckt hat. Die andere Referenz stellt hingegen den Benutzer dar, der dem Problem zugewiesen wurde. Zum anderen gibt es drei indirekte Referenzen, auf die hier zuletzt noch eingegangen wird. Die auerste Referenz verl auft u ber die Klasse Attachment. Ein Attachment stellt dabei einen Anhang zu einem bestehenden Problem dar und hat unter Anderem einen Dateinamen, eine Dateigr oe und einen Autor, der den Anhang erstellt hat. Die anderen beiden Referenzen zur Klasse User gehen von AuthorUpdatableElement aus. Dieses Element hat einerseits einen festen Autor, kann jedoch auch einen zweiten Autor haben, der das Element als letztes aktualisiert hat. AuthorUpdatableElement erbt hierbei wie auch Issue von UpdatableElement. Weiterhin existieren zwei Subklassen von AuthorUpdatableElement. Die Comment -Klasse stellt hierbei einen Kommentar zu einem Problem dar. Es k onnen beliebig viele Kommentar-Objekte in Relation zu einem Problem stehen. Die zweite Subklasse von AuthorUpdatableElement stellt die Klasse Worklog dar. Ein Worklog stellt hierbei die Dauer dar, die der Autor des Worklogs mit diesem Problem verbracht hat und hat dementsprechend die Anzahl der Minuten und das Start-Datum als Attribute. Diese hier betrachteten Klassen sollen einen Uberblick u ber das bestehende Issue Model geben. Die meisten der hier dargestellten Klassen sind optional. Nutzt man jedoch das volle Potenzial, das dieses Modell bietet, lassen sich so umfassende Daten dar uber sammeln wie lange man durchschnittlich f ur das L osen bestimmter Probleme braucht. Weiterhin bildet ein solches Modell r uckwirkend eine gute Basis f ur andere L osungsstrategien, um schwierige Probleme m oglichst umgehen zu k onnen. Nachfolgend wird der zweite Teil des Kern-Entscheidungsmodells betrachtet und in einen Zusammenhang mit dem Issue Model gebracht. Decision Model Der zweite, und essentielle Teil des Kern-Entscheidungsmodells ist das Decision Model. Dieses Modell umfasst alle Merkmale einer Entwurfsentscheidung wie auch in 2.2 beschrieben und bietet die meisten Erweiterungsm oglichkeiten f ur weitere Entscheidungsmodelle. Das Decision Model ist hierbei in Abbildung 3.1 dargestellt. Wie auch beim Issue Model gibt es hier zwei Hauptklassen. Die Klasse Decision stellt dabei eine Entscheidung dar, w ahrend die Klasse DecisionModel alle bereits bekannten Entscheidungen enth alt. Eine Entscheidung hat hierbei mehrere Attribute. Die ID wird ben otigt, um die Entscheidung eindeutig zuordnen zu k onnen. Der Zeitstempel gibt an, wann die Entscheidung dokumentiert wurde. Der Titel sollte die Entscheidung kurz zusammenfassen, w ahrend die Beschreibung die Entscheidung ausf uhrlicher beschreiben sollte. Die beiden letzten Attribute stellen Schl usselw orter dar, die mit der Entscheidung in Verbindung gebracht werden k onnen sowie einen Status. Der Status kann dabei einen von insgesamt f unf Werten annehmen, die im Enum DecisionStatus deniert sind. Weiterhin bestehen Kompositionen von der Entscheidungsklasse zur Klasse Alternative und zur Klasse Rationale. Alternative stellt hierbei eine m ogliche Alternative zur dokumentierten Entscheidung dar. Diese kann u agt werden. Rationale hingeber Vor- und Nachteile abgew gen repr asentiert die Begr undung zur dokumentierten Entscheidung. Diese ist wichtig, um u onnen wieso diese Entscheidung getroen und verwirklicht berhaupt nachvollziehen zu k wurde. Ebenso stellt die Begr undung die Abw agung zwischen den Vor- und Nachteilen der vorhandenen Alternativen dar, die sonst keiner Gewichtung unterliegen w urden. Eine

14

3.1. Das Kern-Entscheidungsmodell

15

Abbildung 3.2.: DecisionModel-Komponenten des Kern-Entscheidungsmodells - Quelle: [K u]

Rationale muss nach diesem Modell immer zu einer Entscheidung geh oren. Alternativen hingegen kann es keine oder beliebig viele zu einer Entscheidung geben. Die Klasse Decision hat jedoch auch Assoziationen. Unter Anderem existiert eine Assoziation zur Klasse Decision selbst. Diese gibt an, ob eine Entscheidung durch eine andere Entscheidung ersetzt wurde. Weiterhin bestehen zwei Assoziationen zur Issue-Klasse, die aus dem Modell in Abbildung 3.1 entnommen wurde. Zum einen l ost eine Entscheidung immer mindestens ein Problem, zum anderen kann es aber auch passieren, dass durch das treen einer Entscheidung weitere Probleme entstehen. Weiterhin besteht eine Referenz zur Klasse Stakeholder. Ein Stakeholder stellt dabei immer einen Akteur dar, der genau eine Identit at besitzt und mehrere Rollen zugewiesen bekommen kann. Eine Entscheidung wird also immer durch einen Akteur erstellt. Gleichzeitig kann ein Akteur mehrere Entscheidungen getroen haben sowie mehrere Probleme aufdecken. Eine spezielle Form einer Entscheidung, die im Kern-Entscheidungsmodell existiert, ist ein Constraint. Constraints stellen dabei immer zus atzliche Bedingungen dar, die erf ullt bleiben m ussen. Aus diesem Grund hat ein Constraint in diesem Modell als zus atzliches Attribut eine bestimmte Anzahl an Invarianten, die erf ullt sein m ussen. Ist eine der Invarianten nicht erf ullt, kann die zugeh orige Entscheidung nicht getroen und gegebenenfalls implementiert werden. Zum Abschluss dieses Abschnitts wird die Klasse DecisionModel genauer betrachtet. Alle Referenzen sind hier, wie auch bei der Klasse IssueModel in Abbildung3.1, als Kompositionen dargestellt. Die Besonderheit an der Klasse DecisionModel ist jedoch, dass auch eine Komposition zur IssueModel-Klasse besteht. Ein IssueModel kann also nicht ohne eine DecisionModel-Instanz existieren. Damit ist festgelegt, dass zuerst ein DecisionModel und danach ein IssueModel erzeugt werden muss, um beliebige andere Komponenten des Kern-Entscheidungsmodells erstellen zu k onnen. Damit wurde das Kern-Entscheidungsmodell vollst andig betrachtet. Dieses Modell wurde sowohl f ur den bisherigen Ansatz als auch f ur den Umbau zum f oderierten Ansatz verwendet. Der bisher verfolgte Ansatz wird im n achsten Abschnitt betrachtet.

15

16

3. Konzeption

<<component>> Decison Model

<<component>> Core Decision Model

uses

Design Decision Editor

<<component>> Architecture Decision Model

Abbildung 3.3.: Darstellung des bisherigen Ansatzes

3.2. Integriertes Entscheidungsmodell


F ur den bisher verwendeten Ansatz werden noch zwei weitere Modelle eingef uhrt. Das Architektur-Entscheidungsmodell erm oglicht es hierbei architekturelle Entwurfsentscheidungen zu dokumentieren und stellt somit eine Erweiterung zum Kern-Entscheidungsmodell dar. Der genaue Aufbau dieses Modells wird in dieser Arbeit allerdings nicht beschrieben, da dieses Modell hier nur eine untergeordnete Rolle spielt. Das zweite Modell, das an dieser Stelle eingef uhrt werden soll ist der Design Decision Editor. Dieser Editor ist f ur die Darstellung und Anpassung von Entscheidungen verantwortlich. Er ndet vor allem im Implementierungsteil dieser Arbeit n ahere Betrachtung. Der bisher verfolgte Ansatz ist in Abbildung 3.3 dargestellt und wird nachfolgend analysiert. F ur den bisherigen Ansatz wurde ein integriertes Modell gew ahlt. Es gibt hierbei ein Entscheidungsmodell, das alle weiteren Entscheidungsmodelle enthalten soll. Im bisherigen Ansatz bedeutet dies, dass sich das Kern-Entscheidungsmodell sowie das ArchitekturEntscheidungsmodell in diesem Modell benden. Das Architektur-Entscheidungsmodell erbt dabei vom Kern-Entscheidungsmodell, um dessen Funktionalit aten erweitern zu k onnen. Der Design Decision Editor, der nun Zugri auf dieses Modell hat, kennt dementsprechend beide Entscheidungsmodelle. Er verwendet Informationen aus den beiden bestehenden Entscheidungsmodellen, um die Darstellung der Entscheidungselemente im Editor zu erm oglichen. Solange zu diesem Architektur-Entscheidungsmodell kein weiteres Modell hinzu kommt, funktioniert dieser Ansatz recht gut. Es ist so m oglich, dass sowohl einfache Entscheidungen, als auch spezielle Architektur-Entscheidungen angelegt und verwaltet werden k onnen. Beabsichtigt man nun jedoch ein Code-Entscheidungsmodell in diesen Ansatz zu integrieren, m ussen mehrere Dinge beachtet werden. Zum einen muss das Code-Entscheidungsmodell an die gleiche Stelle wie das Kern-Entscheidungsmodell und das Architektur-Entscheidungsmodell. Dies hat zur Folge, dass Code, der aus dem Modell generiert wird, ebenso im selben Projekt landet und die Ubersichtlichkeit verloren geht. M ochte man etwas in nur einem einzigen Entscheidungsmodell andern, m usste man dieses erst einmal suchen. Weiterhin besteht die Gefahr, dass bei Anderungen an einem Entscheidungsmodell, alle weiteren Entscheidungsmodelle ebenso angepasst werden m ussen, da die Funktionalit aten der Entscheidungsmodelle ineinander u bergehen. Das ei-

16

3.3. Migration zum f oderierten Ansatz

17

<<component>> Core Decision Model

<<component>> Design Decision Editor


Get further decison artifacts

<<component>> Architecture Decision Model

<<component>> Code Decision Model

uses

<<component>> ...

Abbildung 3.4.: Darstellung des f oderierten Ansatzes gentliche Ziel sollte jedoch sein alle Modelle unabh angig voneinander warten zu k onnen und gegebenenfalls noch weitere Entscheidungsmodelle in den Ansatz integrieren zu k on nen, sodass dennoch die Ubersichtlichkeit bewahrt bleibt. Um dieses Ziel verwirklichen zu k onnen, muss ein Umbau des bestehenden Ansatzes stattnden. Dieser wird im n achsten Abschnitt erl autert.

3.3. Migration zum f oderierten Ansatz


Aufgrund der Nachteile, die ein integrierter Ansatz mit sich bringt, wird dieser Ansatz zu einem f oderierten Ansatz migriert. Ein f oderierter Ansatz bedeutet in diesem Fall, dass die einzelnen Entscheidungsmodelle voneinander entkoppelt werden. Dadurch lassen sie sich unabh angig voneinander warten und die Ubersichtlichkeit bleibt erhalten. Weiterhin nimmt der Komplexit atsgrad des Ansatzes deutlich ab. Zur besseren Vorstellung zeigt Abbildung 3.4 den Aufbau des f oderierten Ansatzes. Wie man an der Abbildung erkennt, liegen die Entscheidungsmodelle nun alle getrennt vom Kern-Entscheidungsmodell in eigenen Komponenten. Die am weitesten rechts liegende Komponente ... ist dabei Repr asentant f ur beliebige weitere Entscheidungsmodelle. Des Weiteren wird deutlich, dass jedes einzelne Entscheidungsmodell eine Erweiterung zum Kern-Entscheidungsmodell darstellt, da es von diesem erbt. Das hat nun zur Folge, dass die spezischeren Entscheidungsmodelle zwar das Kern-Entscheidungsmodell kennen, umgekehrt ist das jedoch nicht der Fall. Auerdem bedeutet das nun, dass der Design Decision Editor ebenfalls nur noch das Kern-Entscheidungsmodell kennt, man also nur noch Artefakte von Entscheidungen bearbeiten und sehen kann, die im KernEntscheidungsmodell liegen. Diese Vorgehensweise hat nun jedoch den Vorteil, dass am Kern-Entscheidungsmodell, sobald dieses einmal implementiert ist, keine Anderungen mehr daran vorgenommen werden m ussen, um weitere Entscheidungsmodelle unterst utzen zu

17

18

3. Konzeption

k onnen. Um jedoch auch die Abh angigkeit von den spezischen Entscheidungsmodellen zum Kern-Entscheidungsmodell entfernen zu k onnen, w are ein vollkommen generischer Ansatz n otig, der allerdings den Rahmen dieser Bachelorarbeit sprengen w urde und deswegen auch nicht betrachtet wird. Da der Design Decision Editor, nun da er nur noch das Kern-Entscheidungsmodell kennt, auch nur noch Artefakte darstellen kann, die in diesem Modell liegen, muss eine Erweiterung bereitgestellt werden, sodass auch spezische Entscheidungsartefakte dargestellt werden k onnen. Diese Erweiterung kann in der Form geschehen, dass eine Schnittstelle bereitgestellt wird. Diese Schnittstelle muss von allen spezischen Entscheidungsmodellen verwendet werden. Uber die Schnittstelle kann der Design Decision Editor dann weitere Entscheidungsartefakte in seine Darstellung integrieren ohne die Artefakte genau kennen zu m ussen. Somit wird eine Erweiterbarkeit des f oderierten Ansatzes erm oglicht. Es soll m oglich sein, dass beliebig viele Entscheidungsmodelle diese Schnittstelle verwenden k onnen, sodass es keine Rolle mehr spielt, ob ein Entscheidungsmodell ausgetauscht wird oder ein neues hinzukommt. Der Nachteil, den dieser f oderierte Ansatz nun mit sich bringt, ist der Mehraufwand zur Implementierung der Schnittstelle. Allerdings u berwiegen hier die Vorteile, die dieser Ansatz bietet, sodass der Umbau zum f oderierten Ansatz auch das konzeptionelle Ziel dieser Arbeit darstellt. Dabei ist der Kern dieses Umbaus zum f oderierten Ansatz die Realisierung der Schnittstelle und die Anpassungen des Design Decision Editors, um die weiteren Artefakte der Entscheidungen darstellen zu k onnen. Um beurteilen zu k onnen, ob der Umbau erfolgreich war und welchen Mehrwert dieser nun bringt, ndet die Validierung anhand eines einfachen Code-Entscheidungsmodells statt, das auch in Abbildung 3.4 dargestellt ist. Die Validierung selbst stellt Kapitel 5 dar. Bevor nun jedoch n aher auf die Schnittstelle eingegangen werden kann, ist noch ein wenig Wissen u ber den bestehenden Design Decision Editor so wie den Aufbau eines .decison-Modells n otig, das f ur die Verwaltung von Entscheidungen verwendet wird.

3.4. Architektur der Modelle


S amtliche Entscheidungen, die zu einem oder mehreren verwandten Projekten dokumentiert werden, werden mit Hilfe dieses Ansatzes in einem .decision-Modell gespeichert. Ein solches Modell ist dabei immer eine Datei im XML-Format mit Endung .decision. Die .decision-Modelle enthalten dabei immer mindestens ein XML-Element <decision:DecisionModel> sowie ein weiteres Element <issueModel>. Das erste Element enth alt dabei alle getroenen Entscheidungen mit den dazugeh origen Attributen wie Alternativen oder der Begr undung zur Entscheidung. Das zweite Element kann hingegen alle Elemente beinhalten, die in Abbildung 3.1 u upft ber eine Komposition mit dem IssueModel verkn sind. Uber ein solches Modell ist es also m oglich alle getroenen Entscheidungen zu verwalten und gegebenenfalls neue hinzuzuf ugen. F ur die graphische Darstellung der getroenen Entscheidungen wird, wie bereits erw ahnt, auf den bestehenden Decision Decision Editor zur uckgegrien. Neben der Darstellung der einzelnen Artefakte, ist es auch m oglich in diesem Editor bestimmte Artefakte einer Entscheidung zu bearbeiten. Nachdem ein .decision-Modell gew ahlt wurde, hat der Design Decision Editor Zugri auf alle sich darin bendenden Entscheidungen. Diese k onnen einzeln u ahlt werden. Je nach Auswahl wird die entber ein sogenanntes Outline ausgew sprechende Entscheidung im Editor-Fenster dargestellt. Die Klassen, die in diesem Editor f ur den sp ateren Zweck eine gr oere Rolle spielen, sind DecisionPage und DecisionEditor. Auf diese beiden Klassen wird in der Implementierung in Kapitel 4 n aher eingegangen, wenn es darum geht geeignete Stellen zu nden, an denen die Schnittstelle eingesetzt werden kann. Weitere zu betrachtende Modelle sind das Code-Entscheidungsmodell, dass in Kapitel 5 betrachtet wird sowie die eigentliche Schnittstelle, die f ur die Migration zum f oderierten Ansatz n otig ist. Diese wird im n achsten Abschnitt genauer betrachtet.

18

3.4. Architektur der Modelle

19

3.4.1. Schnittstellendenition
Dieser Abschnitt behandelt die Realisierung der Schnittstelle im f oderierten Ansatz auf architektureller Ebene. Wie in 3.3 erw ahnt ist die Schnittstelle an einige Voraussetzungen gebunden, die beim Entwurf und der sp ateren Implementierung ber ucksichtigt werden m ussen. Diese Voraussetzungen lassen sich in den folgenden vier Punkten zusammenfassen. 1. Die speziellen Entscheidungsmodelle kennen das Kern-Entscheidungsmodell 2. Das Kern-Entscheidungsmodell kennt die speziellen Entscheidungsmodelle nicht 3. Die Schnittstelle soll bewirken, dass zus atzliche Artefakte zu einer Entscheidung abgerufen werden k onnen 4. Die abgerufenen Informationen m ussen sich in die Darstellung der Entscheidung einf ugen k onnen F ur die Gew ahrleistung der Punkte zwei und drei wird bei der sp ateren Implementierung auf den Extension-Point-Mechanismus von Eclipse zur uckgegrien. Punkt eins l asst sich damit erreichen, dass die spezischen Entscheidungsmodelle vom Kern-Entscheidungsmodell erben d urfen. Um die Gew ahrleistung des letzten Punktes erl autern zu k onnen, ist Abbildung 3.4.1 gegeben. Diese Abbildung stellt dabei ein UML-Klassendiagramm dar, das die Schnittstelle charakterisiert. Das hier gezeigte UML-Klassendiagramm enth alt Klassen aus dem Design Decision Editor, aus dem Kern-Entscheidungsmodell, dem Code-Entscheidungsmodell auf das sp ater eingegangen wird und die beiden Klassen, die die Schnittstelle darstellen. Durch die Darstellung dieser Klassen, soll die Integration der Schnittstelle verdeutlicht werden. Die Schnittstelle selbst besteht hierbei aus der Klasse ExtensionPointExecutor sowie dem Interface DecisionRelatable. Das Interface stellt wie abgebildet die Methode public Composite getRelatedDecisionArtifacts(Section parent, Decision d) bereit. Eine Implementierung dieser Methode hat die Aufgabe Entscheidungsmodell-spezische Artefakte zu einer Entscheidung zu suchen und diese zur uck zu geben. Der R uckgabetyp der Methode ist ein Composite aus dem Package org.eclipse.swt.widgets. Damit ist speziziert, dass sich die zur uck gegebenen Artefakte in eine SWT-Umgebung einf ugen m ussen. Der erste Parameter, der dieser Methode u bergeben wird, stellt eine Section aus dem Package org.eclipse.ui.forms.jface dar. Die Section sollte beim Ubergeben bereits initialisiert worden sein, sodass in dieser Methode nur noch das Composite in die Section eingef ugt werden muss. Der Parameter muss allerdings u bergeben werden, da bereits beim Initialisieren einer SWT-Komponente die Vater-Komponente mit angegeben werden muss und ein nachtr agliches Hinzuf ugen nicht m oglich ist. Der zweite Parameter, der dieser Methode u bergeben wird, ist eine Entscheidung. F ur diese Entscheidung muss in einer Implementierung dieser Methode u uft berpr werden, ob die Entscheidung eine spezische Entscheidung ist und somit weitere Artefakte existieren. Falls weitere Artefakte existieren k onnen die zusammen in ein Composite gepackt und zur uck gegeben werden. Sollte die Entscheidung keine spezische Entscheidung sein, die dem implementierenden Entscheidungsmodell bekannt ist, sollte von der Methode ein Null-Objekt zur uckgegeben werden. Durch die R uckgabe eines Null-Objekts wei der Design Decision Editor, dass es in diesem Entscheidungsmodell keine weiteren Artefakte zur gew ahlten Entscheidung gibt und kann dann entweder auf den R uckgabewert anderer Entscheidungsmodelle warten oder den Teil f ur die weiteren Artefakte leer lassen. Um jedoch u onnen, ob es weitere Entscheidungsmoberhaupt feststellen zu k delle gibt, stellt der ExtensionPointExecutor eine Methode bereit. Die Methode public List<DecisionRelatable> execute() hat bei Aufruf die Aufgabe alle Klassen zu nden, die das DecisionRelatable-Interface implementieren. Nach dem Finden einer solchen Klasse soll eine Instanz davon initialisiert werden. Anschlieend wird diese Instanz einer Liste

19

3. Konzeption

Decision
- ID: String - timestamp: Date - title: String - description: String - keywords: List<String> - status: DecisionStatus 0..* decisionModel

DecisionEditor DecisionModel
1 decisionModel

decisions

- resourcePath: String - decisionPage: DecisionPage - model: DecisionModel - isDirty: boolean - outline: DecisionMOutlinePage - structuredSelection: ISturcturedSelection

+ dispose() + doSave(monitor: IProgressMonitor) + doSaveAs() + init(site: IEditorSite, input: IEditorInput) + getAdapter(adapter: Class): Object # addPages()

1 <<Interface>>

editor

ExtensionPointExecutor
execute(): List<DecisionRelatable>

1
executor

DecisionRelatable
getRelatedDecisionArtifacts(parent: Section, d: Decision): Composite

decisionPage

CodeDecisionRelatable CodeDecision
- type: CodeDecisionType

+ getRelatedDecisionArtifacts(parent: Section, d: Decision): Composite - getCompilationUnitsByClassName(className: String, packageName: String): List<ICompilationUnit> - getCompilationUnitsForProject(className: String, iJavaProject: IJavaProject, packageName: String): List<ICompilationUnit>

- text_ID: Text - text_Date: Text - text_description: Text - text_Rationale: Text - comboViewer_state: ComboViewer - resolvedIssuesListViewer: ListViewer - triggeredIssuesListViewer: ListViewer - decision: Decision - text_Title: Text - sctnFurtherDecisionArtifacts: Section - managedForm: IManagedForm - related: List<DecisionRelatable>

20

+ doBinding() + select(decision: Decision) # createFormContent(managedForm: IManagedForm) redrawFurtherDecisionArtifactsSection( parent: Composite)

Abbildung 3.5.: UML-Klassendiagramm der Schnittstelle und deren Einf ugung in das bestehende Modell

20

DecisionPage

3.4. Architektur der Modelle

21

Benutzer

Decision Editor ffnen von .decisionModell DecisionPage mit 1. Entscheidung initialisieren

Decision Page

ExtensionPoint Executor

CodeDecision Relatable

Aufruf execute()-Methode
Rckgabe Liste von DecisionRelatableImplementierungen

Aufruf getRelatedDecisionArtifacts() mit 1. Entscheidung als Parameter

Rckgabe Composite

Darstellung Design Decision Editor

Finale DecisionPage

Abbildung 3.6.: Datenuss zwischen dem Onen eines .decision-Modells und der Darstellung der Komponenten hinzugef ugt, welche am Ende der Methode zur uck gegeben wird. F ur die zur uck gegebene Liste gilt dabei, dass sie zwar leer sein kann, jedoch niemals ein Null-Objekt darstellt. Das hat den Vorteil, dass auf die Uberpr ufung nach null verzichtet werden kann und keine unerwarteten Exceptions entstehen. Da die Schnittstelle als ein eigenst andiges Plug-in vorhanden sein soll, muss diese sich noch in den Ansatz einf ugen. Das wird dadurch erreicht, dass dem Design Decision Editor sowohl das Interface als auch der ExtensionPointExecutor bekannt gemacht wird. Dadurch erh alt der Design Decision Editor die M oglichkeit zu entscheiden wann nach weiteren Artefakten zu einer Entscheidung gesucht werden soll. Der n achste Abschnitt soll nun einen Einblick darin geben, wie der Datenuss zwischen dem Laden eines .decision-Modells bis hin zur Darstellung der ersten Entscheidung aussehen kann.

3.4.2. Datenu sse


Durch die Migration zum f oderierten Ansatz und durch den Einsatz der Schnittstelle, andert sich der Informationsaustausch zwischen den beteiligten Modellen. Der Design De cision Editor beispielsweise kann nicht mehr direkt auf alle Entscheidungsmodelle zugreifen, sondern muss das durch einen Umweg u ber die Schnittstelle machen. Dadurch lohnt es sich zu betrachten, welche Daten an welcher Stelle zwischen den einzelnen Modellen ieen. Der Datenuss, der hier betrachtet werden soll, wird m oglichst einfach gehalten. Das bedeutet, dass lediglich der Datenuss zwischen dem Laden eines .decision-Modells bis hin zur Darstellung der ersten und einzigen Entscheidung in diesem .decision-Modell betrachtet wird. Diese Entscheidung ist dabei eine Code-Entscheidung, sodass der Design Decision Editor die zus atzlichen Artefakte, die zu einer Code-Entscheidung geh oren, anzeigt. Weiterhin existiert lediglich ein Code-Entscheidungsmodell als spezisches Modell. Das heit, dass auch nur f ur ein Modell die Klasse gefunden werden muss, die das Interface DecisionRelatable implementiert. Dieser Datenuss liee sich noch wesentlich komplexer darstellen, indem zus atzlich zum Code-Entscheidungsmodell das ArchitekturEntscheidungsmodell hinzukommen w urde. Weiterhin k onnte das .decision-Modell mehr als eine Entscheidung enthalten und der Datenuss bis hin zur ersten Entscheidung, die keine Code-Entscheidung ist, betrachtet werden. Der Einfachheit und des besseren Verst andnisses wegen, wird darauf jedoch verzichtet. Der Datenuss selbst kann anhand des Sequenzdiagramms in Abbildung 3.4.2 erl autert werden.

21

22

3. Konzeption

Zu Beginn des Diagramms w ahlt der Benutzer ein .decision-Modell aus, das betrachtet werden soll. Das Modell selbst wird dabei an die Klasse DecisionEditor des Design Decision Editors weitergeleitet. Von dort aus wird das Modell in ein DecisionModel-Objekt geparsed. Damit ist es dann m oglich das DecisionPage-Objekt zu initialisieren. Dazu wird der DecisionPage die erste Entscheidung, die nun im DecisionModel-Objekt steht, u bergeben. Die Initialisierung der DecisionPage l auft dabei im Groen und Ganzen so ab, dass die einzelnen Komponenten der Seite initialisiert werden. Um nun noch m ogliche weitere Artefakte, die zur ersten Entscheidung geh oren darstellen zu k onnen, wird zus atzlich der ExtensionPointExecutor initialisiert. Im n achsten Schritt folgt der Aufruf der execute()-Methode des Executors. Dieser u bergibt dann eine Liste von DecisionRelatableImplementierungen zur uck an die DecisionPage. Im Falle dieses Beispiels besteht die Liste aus genau einem Element, n amlich der Implementierung des Interfaces auf Seiten des Code-Entscheidungsmodells. Im Anschluss an die R uckgabe der Liste, ruft die DecisionPage die Methode der DecisionRelatable-Implementierung auf. Dabei wird die Entscheidung, die die DecisionPage darstellen soll, u bergeben. Weiterhin wird die Section u bergeben, in die die weiteren Artefakte sich schlielich einf ugen sollen. Intern wird nun in dem CodeDecisionRelatable-Objekt u uft, ob es sich bei der u berpr bergebenen Entscheidung um einen Code-Entscheidung handelt. Da dies der Fall ist, wird ein neues Composite erzeugt, das der Section zugeordnet werden kann. Diesem Composite werden alle zus atzlichen Artefakte der Code-Entscheidung hinzugef ugt, die der Design Decision Editor nicht kennen kann. Die DecisionPage bekommt nun das fertige Composite u ugt bergeben und f es in die Seite ein. Im Anschluss daran hat der DecisionEditor eine fertig initialisierte DecisionPage, sodass diese dem Benutzer dargestellt werden kann. Sollte nun im Outline des Design Decision Editors eine andere Entscheidung gew ahlt werden, ndet lediglich eine Teil-Initialisierung der DecisionPage statt. Es wird nur die Section neu initialisiert, die die weiteren Artefakte zur Entscheidung enth alt, und die Methode der DecisionRelatableImplementierungen erneut aufgerufen. Die genaue Implementierung dieser Sequenz wird in den n achsten beiden Kapiteln n aher betrachtet.

22

4. Implementierung

Bevor der Umbau auf konzeptioneller Ebene auch implementiert werden kann, werden weitere Informationen zur bestehenden Architektur der Modelle ben otigt. Das Kern-Entscheidungsmodell besteht unter Anderem aus dem Modell an sich, das alle Klassen enth alt, die in Abbildung 3.1 und 3.1 beschrieben werden. Diese Klassen existieren sowohl als Interface, also auch mit ihrer Implementierung. Auf diese Weise ist es m oglich bei Bedarf auch Klassen zu erstellen, die eine Kombination aus zwei vorgegebenen Klassen darstellen. Der Name des Modells sei hier mit edu.kit.ipd.sdq.dm angegeben. Weiterhin werden f ur das Editieren und Anlegen von Entscheidungen weitere Komponenten ben otigt. Zum einen ist dies die edu.kit.ipd.sdq.dm.editor-Komponente. Mit dieser Komponente ist es m oglich .decision-Modelle anzulegen, die Entscheidungen aus dem Kern-Entscheidungsmodell unterst utzen. Neben der .editor-Komponente existiert noch eine edu.kit.ipd.sdq.edit-Komponente. Mit dieser Komponente ist es m oglich Entscheidungen und deren Komponenten anzulegen und bei Bedarf auch zu editieren. Das Anlegen neuer Entscheidungen ndet dabei u ber einen Decision Model Editor statt, der aufgrund der editor-Komponente des Kern-Entscheidungsmodells existiert. Das Kern-Entscheidungsmodell ist also ein Zusammenspiel aus diesen drei Komponenten. W urde eine davon fehlen, lieen sich Entscheidungen nicht in einem Modell speichern, anlegen oder k onnten u berhaupt existieren. F ur weitere Entscheidungsmodelle, die als Erweiterung zum Kern-Entscheidungsmodell dienen sollen, ben otigt man also mindestens ebenfalls ein dem Entscheidungsmodell zu Grunde liegendes Modell sowie eine .edit-Komponente. Die .editor-Komponente wird nicht ben otigt, da sich spezische Entscheidungen im vorhandenen Decision Model Editor anlegen lassen sollen. F ur die Implementierung des f oderierten Ansatzes, muss der bestehende Ansatz erweitert werden. Dazu geh oren unter Anderem die Anpassungen, die am vorhandenen Design Decision Editor gemacht werden m ussen, um die Schnittstelle unterst utzen zu k onnen. Weiterhin wird hier die Implementierung der Schnittstelle selbst betrachtet. Da diese mit Hilfe des Extension-Point-Mechanismus von Eclipse erstellt wurde, wird zus atzlich auch das Schema, das durch die Erstellung des Extension-Points entsteht, betrachtet. Es soll hier jedoch rein um die Implementierung der Schnittstelle gehen und nicht um die Implementierung des von der Schnittstelle bereitgestellten Interfaces. Die Implementierung des Interfaces, wird beispielhaft an einem Code-Entscheidungsmodell in Kapitel 5 gezeigt. Die Implementierung des Ansatzes wurde in Java geschrieben und als Entwicklungsumgebung wurde Eclipse verwendet.

23

24

4. Implementierung

Abbildung 4.1.: Aufbau des DecisionEditor-Plug-ins

4.1. Erweiterbarkeit der Modellierung


Um den fertigen Extension-Point u onnen, muss die Schnittstelle berhaupt verwenden zu k auch aufgerufen werden. Da der Design Decision Editor weitere zu einer Entscheidung geh orende Artefakte anzeigen soll, muss dieser auch angepasst werden, sodass eben diese Artefakte an den Editor geliefert werden. Dazu werden zuerst die bestehenden Klassen im Editor betrachtet, um einen geeigneten Punkt zu nden, an dem die Schnittstelle aufgerufen werden kann. Das Ziel hierbei ist, m oglichst wenig Code ver andern zu m ussen. Erweiterung des Design Decision Editors Der Design Decision Editor wurde durch das Plug-in edu.kit.ipd.sdq.decisioneditor implementiert. Abbildung 4.1 zeigt dabei den Aufbau des Plug-ins. Da es hierbei um die Anzeige von weiteren Komponenten im Editor geht, empehlt sich das Package edu.kit.ipd.sdq.decisioneditor.editors. Die anderen Packages enthalten lediglich Klassen zum starten des Plug-ins (activator ), Dialogfenster zum Andern bestimmter Eigenschaften von Entscheidungen (dialog ) oder Filter, um bereits gel oste Probleme zu ltern (lter ). Weitere Packages enthalten einen sogenannten Outline, um zwischen Entscheidungen hin und her zu springen (outline ), verwendete Ressourcen im Editor, beispielsweise Icons (reessources ) oder ein Interface f ur einen SelectionListener im Package listener. Das letzte Package enth alt lediglich vorgefertigte Klassen von Eclipse und ist demnach auch

24

4.1. Erweiterbarkeit der Modellierung

25

keine gute Stelle, um den Editor zu erweitern. Im editors-Package, das den besten Anlaufpunkt darstellt, benden sich vier Klassen, wobei eine lediglich Informationen zu diesem Package enth alt. Die anderen Klassen sind DecisionEditor, DecisionPage und FormLayoutFactory. Die Fabrik ist hierbei f ur das Layout von verschiedenen Komponenten zust andig und die Klasse des Editors ist f ur das Initialisieren und Speichern des gesamten Editors zust andig. Der Inhalt des Editors wird jedoch in der DecisionPage festgelegt. Dementsprechend lohnt sich ein genauerer Blick in die DecisionPage -Klasse. Die Seite des Editors ist dabei aufgeteilt in eine linke und eine rechte H alfte, was ohne eine Erweiterung zum Editor in Abbildung 4.1 f uhrt. Zus atzlich zum Editor selbst ist in dieser Abbildung auch noch der Outline gezeigt, der s amtliche Entscheidungen dieses .decision -Modells zeigt. Zum Wechseln der Entscheidung im Design Decision Editor ist also lediglich ein Klick auf die entsprechende Entscheidung im Outline n otig. F ur die Erweiterung bietet es sich also an auf der rechten Seite des Editorfensters zus atzliche Artefakte anzeigen zu lassen. Da sich der Inhalt der zu implementierenden Section je nach Entscheidung jedoch andern kann, muss eine M oglichkeit bestehen diese Section bei Bedarf neu zeichnen zu k onnen. Deswegen bietet sich eine eigene Methode zur Implementierung dieser Section an. Bevor diese Methode jedoch einen Nutzen hat, muss der ExtensionPointExecutor initialisiert werden und der DecisionPage die Liste von DecisionRelatable-Objekten zur Verf ugung stellen. Das muss nur ein einziges mal pro Initialisierung der DecisionPage gemacht werden, da w ahrend der Darstellung oder dem Bearbeiten von Entwurfsentscheidungen keine neuen, unbekannten Entscheidungsmodelle hinzukommen. Wann der Aufruf des Executors stattndet, spielt dabei keine Rolle, solange es vor dem Initialisieren der Section geschieht, die die zus atzlichen Artefakte darstellen soll. Deswegen wurde f ur diese Implementierung das Ende der Methode createRightComposite(...) gew ahlt. Direkt danach ndet die erstmalige Initialisierung der Section statt, die die weiteren Artefakte enth alt. Der Code dazu ist in Listing 4.1 dargestellt. Listing 4.1: Aufruf des Executors
1 2 3 4 ExtensionPointExecutor executor = new ExtensionPointExecutor(); related = executor.execute(); redrawFurtherDecisionArtifactsSection(compositeRight);

Das Attribut related stellt dabei die Liste der DecisionRelatable-Implementierungen dar. Da die danach aufgerufene Methode die Liste ben otigt und einmal bei der ersten Initialisierung sowie bei jedem Wechsel der dargestellten Entscheidung aufgerufen wird, ist die Liste nicht als lokale Variable, sondern als Attribut implementiert. Die Liste beinhaltet nach Aufruf der execute()-Methode nun genau ein Objekt pro Entscheidungsmodell, das den vorgegebenen Extension-Point verwendet. Wie bereits erw ahnt, wird eine eigene Methode f ur das Initialisieren der Komponenten zur Darstellung der weiteren Artefakte ben otigt. Diese ist in Listing 4.2 dargestellt.

25

4. Implementierung

Abbildung 4.2.: Darstellung des DecisionEditors ohne Erweiterung

26

26

4.1. Erweiterbarkeit der Modellierung Listing 4.2: Erweiterung der DecisionPage


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

27

private void redrawFurtherDecisionArtifactsSection(Composite parent) { if (sctnFurtherDecisionArtifacts != null) { sctnFurtherDecisionArtifacts.dispose(); } sctnFurtherDecisionArtifacts = managedForm.getToolkit().createSection(parent, Section.DESCRIPTION | Section.TITLE_BAR); GridData gd_sctnFurtherDecisionArtifacts = new GridData(SWT.LEFT, SWT.CENTER, false, false, 1, 1); sctnFurtherDecisionArtifacts.setLayoutData(gd_sctnFurtherDecisionArtifacts); sctnFurtherDecisionArtifacts.setDescription("In case the decision has further related artifacts they are shown here"); managedForm.getToolkit().paintBordersFor(sctnFurtherDecisionArtifacts); sctnFurtherDecisionArtifacts.setText("Further Decision Artifacts"); sctnFurtherDecisionArtifacts.setLayout(new GridLayout(1, true)); for (DecisionRelatable artifact : related) { Composite comp = artifact.getRelatableDecisionArtifacts( sctnFurtherDecisionArtifacts, decision); if (comp != null) { managedForm.getToolkit().adapt(comp); sctnFurtherDecisionArtifacts.setClient(comp); parent.redraw(); } } }

Die Methode bekommt immer ein Composite u bergeben. Dieses Composite stellt den Vater der Section dar, die neu gezeichnet werden soll. Dieser Parameter ist wichtig, da die Section bei der ersten Initialisierung noch nicht besteht und somit auch nicht klar ist, in welches Composite sie sich einf ugen muss. Wird die Section nicht das erste mal initialisiert, muss sie zuerst verworfen werden. Das geschieht, damit bei der erneuten Initialisierung nicht zwei identische Sections entstehen, die u bereinanderliegen. Die sieben Zeilen nach der Bedingung geben nun lediglich den Rahmen vor, in den sich die weiteren Artefakte einf ugen m ussen. In der Schleife wird nun f ur jedes Objekt in der Liste der DecisionRelatableImplementierungen dessen getRelatedDecisionArtifacts(...) -Methode aufgerufen, die bekanntermaen ein Composite zur uck gibt. Da der Executor bereits vorher initialisiert wurde und dessen execute()-Methode aufgerufen wurde, ist die Liste der DecisionRelatableImplementierungen maximal leer, aber nicht Null. Anschlieend wird u uft, ob das berpr Composite ungleich Null ist, also auch wirklich Artefakte zur gegebenen Entscheidung enth alt. Ist das der Fall, wird das Composite in den beiden Zeilen innerhalb der Bedingung zur vorher erzeugten Section hinzugef ugt. Diese Implementierung geht davon aus, dass eine Entscheidung beispielsweise eine Architektur-Entscheidung oder eine Code-Entscheidung ist, aber niemals beides. Das bedeutet, dass es nicht vorkommen kann, dass mehr als ein Composite ungleich Null von der Methode des Interfaces zur uck geliefert wird. Abschlieend wird das u ber der Section liegende Composite neu gezeichnet, sodass die zus atzlichen Artefakte auch angezeigt werden. Mit dieser Implementierung ist es nun m oglich seitens des Editors weitere Artefakte zu einer gegebenen Entscheidung darzustellen. Eine beispielhafte Implementierung eines CodeEntscheidungsmodells, dass diesen Extension-Point benutzt, wird in Kapitel 5 dargestellt. Erweiterung des Kern-Entscheidungsmodells Da es jedoch nicht nur m oglich sein soll, weitere Artefakte zu einer Entscheidung anzeigen zu k onnen, sondern nach M oglichkeit auch spezische Entscheidungen in das Modell einf ugen zu k onnen, muss das .genmodel des Kern-Entscheidungsmodells angepasst werden.

27

28

4. Implementierung

Ein .genmodel wird in EMF dazu verwendet, um Code zu generieren. Dem .genmodel liegt dabei immer ein Modell zu Grunde, von dem ausgehend Code generiert wird. In diesem Fall liegt dem .genmodel das Kern-Entscheidungsmodell zu Grunde. Der Code, der nun durch dieses .genmodel generiert werden kann, betrit die einzelnen Klassen im Modell. Weiterhin kann durch dieses .genmodel die .edit-Komponente sowie die .editor-Komponente generiert werden. Als letztes k onnen noch Testf alle zum bestehenden Modell generiert werden, die hier allerdings keine weitere Beachtung nden. Im bisherigen Zustand l asst es die Implementierung der .edit-Komponente nicht zu, dass andere Entscheidungen angelegt werden k onnen, die eine Erweiterung zu diesem Kern-Entscheidungsmodell darstellen. Dazu muss folgende Zeile im .genmodel des Kern-Entscheidungsmodells ge andert werden. Listing 4.3: Anpassung des .genmodels
1 2 <genPackages prefix="Decision" basePackage="edu.kit.ipd.sdq" disposableProviderFactory="true" extensibleProviderFactory="false" ecorePackage="dm.ecore#/">

Der Wert des Attributs extensibleProviderFactory muss nun auf true gesetzt werden, sodass es m oglich ist von diesem Modell Erweiterungen zu erstellen, die es erm oglichen spezische Entscheidungen in ein .decision-Modell einzuf ugen. Ein .decision-Modell enth alt dabei immer alle zu getroenen Entscheidungen zugeh origen Komponenten eines oder mehrerer Projekte. Beispielhaft sei in Listing 4.4 ein .decision-Modell gegeben, das eine Entscheidung mit ihren Attributen enth alt. Listing 4.4: Beispielhaftes .decision-Modell
1 2 3 4 5 6 7 <?xml version="1.0" encoding="ASCII"?> <decision:DecisionModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:decision="http://sdq.ipd.kit.edu/DecisionMetaModel/0.1"> <decisions ID="001" title="Decision Title" description="Simple Test Decision" madeBy="//@stakeholders.0" resolves=""> <rationale description="Simple Test Rationale"/> </decisions> <issueModel> <issues self="" key="" summary="Sample Issue" description="Simple Test Issue" issueType="" project="//@issueModel/@projects.0" affectedVersions="//@issueModel/@versions.0"/> <projects name="SampleProject"/> <versions name="1.0" description="Sample Version Description"/> </issueModel> <stakeholders identity="Michael Junker" decision="//@decisions.0" issues=""/> </decision:DecisionModel>

8 9 10 11 12

Durch das Listing ist zu Erkennen, dass .decision-Modelle immer im XML-Format gespeichert werden. Da dieses Modell nur ein Beispiel sein soll, enth alt es auch lediglich eine Entscheidung mit zugeh origem Problem. Das Grundger ust eines .decision-Modells besteht dabei immer aus den Elementen <decision:DecisionModel> und <issueModel>. Der n achste Abschnitt behandelt das Schema des bereitgestellten Extension-Points. Im Anschluss daran wird n aher auf den Executor eingegangen, der die einzelnen Extensions l adt und als Liste zur uck gibt.

4.2. Denition des Extension-Points


Dass das Schema in einer .exsd-Datei gespeichert wird und in XML geschrieben ist, wurde bereits in Kapitel 2.4 gekl art. In diesem Abschnitt geht es um den konkreten Inhalt

28

4.2. Denition des Extension-Points

29

des Schemas, das f ur den hier verwendeten Extension-Point geschrieben wurde. Das komplette Schema ist im Anhang abgebildet. Hier werden lediglich die wichtigsten Elemente beschrieben. Dabei hat jeder Extension-Point mindestens ein Element mit mindestens den folgenden drei Attributen: 1. ID: Stellt die ID der Extension dar und ist optional 2. Name: Ist ebenso wie die ID optional, im Unterschied dazu jedoch in andere Sprachen u bersetzbar, sofern entsprechende Sprachdateien im Projekt mit inbegrien sind 3. Point: Das einzige nicht-optionale Attribut. Wird jedoch beim Verwenden des ExtensionPoints automatisch gesetzt und enth alt die ID des Extension-Points F ur das Funktionieren dieses Schemas ist in diesem Element noch ein komplexer Typ n otig, auf den sp ater eingegangen wird. Zuerst sei jedoch das Listing 4.5 gegeben. Listing 4.5: Denition des Interfaces im Extension-Point-Schema
1 2 3 4 5 6 7 8 9 10 11 12 13 14 <element name="interface.definition"> <complexType> <attribute name="decisioninterface" type="string" use="required"> <annotation> <documentation> </documentation> <appinfo> <meta.attribute kind="java" basedOn=":edu.kit.ipd.sdq.dm. extensionpoint.definition.DecisionRelatable"/> </appinfo> </annotation> </attribute> </complexType> </element>

An dieser Stelle im Schema wird festgelegt, dass es in diesem Extension-Point noch ein weiteres Element gibt mit einem weiteren Attribut. Dieses Attribut ist eine Java-Klasse. Genau wie das Point-Attribut ist auch dieses Attribut nicht optional. An dieser Stelle im Schema wird festgelegt, dass, um dieses Attribut erf ullen zu k onnen, eine Java-Klasse in der Extension existieren muss, die das Interface DecisionRelatable implementiert. Damit das auch funktioniert, ben otigt nun das erste Element des Extension-Points, wie oben bereits bereits erw ahnt, einen zus atzlichen komplexen Typ, n amlich eine sogenannte Choice. Die Eigenschaften der Choice kommen erst dann richtig zur Geltung, wenn mehr als ein Element in der Choice referenziert wird. Dann hat man als Benutzer des Extension-Points die Wahl in welcher Reihenfolge welche referenzierten Elemente diesen Teil der Extension bilden. Die Choice ist in Listing 4.6 dargestellt. Listing 4.6: Anbindung des Interfaces an den Extension-Point
1 2 3 <choice> <element ref="interface.definition"/> </choice>

Anhand dieses Listings sieht man, dass die Choice nur ein weiteres Attribut hat, n amlich eine Referenz auf das vorher denierte Element. Die Choice, sowie das referenzierte Element, haben Mengenangaben, die im Schema nicht gelistet sind, da es f ur beide F alle die Standardmengen sind, n amlich als Minimum und Maximum jeweils eins. Die Mengenangabe der Choice beziehen sich darauf, dass man beim Verwenden dieses Extension-Points

29

30

4. Implementierung

nur ein einziges mal referenzierte Elemente aus der Choice verwenden darf. Das ist f ur den Fall des hier implementierten Extension-Points auch sinnvoll, da nur von einer Stelle weitere Entscheidungsartefakte an den Editor geliefert werden sollen. Die Mengenangabe im referenzierten Element, also dem interface.denition -Element, geben hierbei an, dass bei Verwendung der Choice auch das Interface genau einmal existieren muss. Die Verwendung des Interfaces liee sich auch variabel gestalten, wenn das Minimum auf null herunter gesetzt w urde, was jedoch in diesem Fall nicht sinnvoll ist. Um den Extension-Point jetzt noch f ur den Benutzer in anderen Plug-ins nutzbar zu machen, muss die MANIFEST.MFDatei angepasst werden. Damit andere Plug-ins, die den Extension-Point nutzen wollen, auch Zugri auf das Interface haben, muss das Package, das das Interface enth alt, noch exportiert werden. Damit kommt in der Manifest.MF-Datei noch die folgende Zeile hinzu: Listing 4.7: Erweiterung in der MANIFEST.MF-Datei
1 Export-Package: edu.kit.ipd.sdq.dm.extensionpoint.definition

Damit ist der Extension-Point der Schnittstelle vollst andig und kann von anderen Plug-ins verwendet werden. Der n achste Abschnitt behandelt das Laden der vorhandenen Entscheidungsmodelle, die diesen Extension-Point verwenden.

4.3. Laden der Extensions


Wie in Listing 4.2 bereits gezeigt, ist der ExtensionPointExecutor f ur das Laden der einzelnen Extensions zust andig. Er hat ebenso die Aufgabe die geladenen Extensions in eine Liste zu packen und diese dann zur uck zu geben. Diese Vorgehensweise hat den Zweck, dass sich der Benutzer des Extension-Points selbst entscheiden kann, wann die Methoden des zur uckgegebenen Interfaces aufgerufen werden sollen. Da der Executor lediglich eine Methode und einen leeren Konstruktor besitzt, sei hier auch nur die execute()-Methode gegeben. Listing 4.8: Die execute()-Methode des ExtensionPointExecutors
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 public List<DecisionRelatable> execute() { List<DecisionRelatable> relatedArtifacts = new ArrayList< DecisionRelatable>(); IExtensionRegistry registry = RegistryFactory.getRegistry(); IConfigurationElement[] config = registry.getConfigurationElementsFor( EXTENSION_POINT_ID); for (IConfigurationElement element : config) { try { final Object o = element.createExecutableExtension(" decisioninterface"); if (o instanceof DecisionRelatable) { relatedArtifacts.add((DecisionRelatable) o); } } catch (CoreException e) { e.printStackTrace(); return relatedArtifacts; } } return relatedArtifacts; }

Wie bereits mehrfach erw ahnt, gibt diese Methode eine Liste von DecisionRelatable s zur uck. F ur den Benutzer ist wichtig, dass die Liste zwar leer sein kann, jedoch niemals

30

4.3. Laden der Extensions

31

null. Das erspart unn otige Exceptions und zus atzliche Uberpr ufungen. Nachdem nun eine leere Liste von DecisionRelatables angelegt wurde, ben otigt der Executor eine sogenannte Registry. Diese enth alt s amtliche registrierten Extension-Points, Extensions und Namensr aume ([Fou]). Im n achsten Schritt werden nun alle Extensions in einem Array gespeichert, die eine bestimmte Extension-Point-ID besitzen. Die ID entspricht dabei edu.kit.ipd.sdq.dm.extensionpoint, ist also genau die ID vom vorher denierten ExtensionPoint. Wenn Extensions gefunden werden, wird f ur jede Extension versucht eine Instanz des DecisionRelatable-Interfaces zu erzeugen. Dazu wird der Methode in Zeile 43 der Name des Attributes u bergeben, das in der Extension-Point-Denition das zu implementierende Java-Interface enth alt, also decisioninterface. In diesem Schritt kann eine sogenannte CoreException auftreten. Diese tritt auf, wenn der Konstruktor der Klasse, der das Interface implementiert nicht oentlich ist oder beim Instanziieren der Klasse eine beliebige Exception auftritt. Zeile 44 stellt noch einmal sicher, dass es sich bei dem gerade instanziierten Objekt um eine DecisionRelatable-Instanziierung handelt. Somit kann im n achsten Schritt gefahrlos ein Cast des Objekts zu einem DecisionRelatable-Objekt stattnden. Dieses wird dann in die sp ater zur uck gegebene Liste eingef ugt.

31

5. Validierung
5.1. Validierung u ber Code-Entscheidungsmodell
Die Migration zum f oderierten Ansatz soll an dieser Stelle validiert werden. Dazu lohnt sich ein kleiner R uckblick auf den f oderierten Ansatz, um festlegen zu k onnen, was genau validiert werden muss. Der integrierte Ansatz wurde derart umgebaut, dass es nun m oglich ist spezische Entscheidungsmodelle als Erweiterung zum Kern-Entscheidungsmodell anzubinden, ohne dass das Kern-Entscheidungsmodell die neuen Entscheidungsmodelle kennen muss. Das wurde u ber eine Schnittstelle realisiert, die u ber den ExtensionPoint-Mechanismus von Eclipse funktioniert. Um nun zu zeigen, dass beliebige Entscheidungsmodelle in diesen Ansatz integriert werden k onnen, wird hier beispielhaft ein CodeEntscheidungsmodell implementiert, dass das von der Schnittstelle bereit gestellte Interface implementiert und eine Extension darstellt. Es wird dann gezeigt, dass es m oglich ist u ber den bestehenden Decision Model Editor neue Code-Entscheidungen anzulegen und deren Attribute zu setzen. Nach Anlegen der Entscheidungen kann dann gezeigt werden, dass der Extension-Point funktioniert, indem der DecisionEditor mit der neu erstellten CodeEntscheidung ge onet wird und die zus atzlichen Artefakte, die eine Code-Entscheidung bietet im Editor angezeigt werden. Das vorgestellte Code-Entscheidungsmodell ist dabei nur ein Prototyp, der lediglich zeigen soll, dass die Schnittstelle funktioniert, und ist nicht repr asentativ. An diesem Code-Entscheidungsmodell k onnten also noch weitere Features implementiert werden, die zum Teil in Kapitel 6.3 angesprochen werden. In den folgenden Abschnitten wird der genaue Zweck des Code-Entscheidungsmodells dargestellt, sowie das Modell selbst. Daraufhin folgt die Anbindung des Modells an den bestehenden Extension-Point und im Anschluss daran der fertige Editor, der die neu hinzugef ugten Code-Entscheidungen anzeigen kann.

5.1.1. Zweck des Modells


Das hier vorgestellte Code-Entscheidungsmodell hat den Zweck Entscheidungen, die auf Code basieren anlegen zu k onnen und, mit Hilfe des Extension-Points, auch anzeigen zu lassen. Merkmale von Code-Entscheidungen sind dabei, dass sie sich zum Einen auf bestimmte Code-Typen beziehen, wie beispielsweise eine Klasse, Interface, Plug-in oder Methode. Zum Anderen ist mit einer Code-Entscheidung auch immer mindestens eine Stelle im Code verbunden. Das kann beispielsweise die Methode selbst sein, die eine Code-Entscheidung darstellen soll, das kann aber auch eine Stelle sein, an der die Methode aufgerufen wird. Bei der Darstellung dieser Artefakte ist es auerdem noch wichtig, dass nicht einfach nur

33

34

5. Validierung

Abbildung 5.1.: Prototyp eines Code-Entscheidungsmodells die verschiedenen Code-Stellen benannt werden, sondern auch, dass die Code-Stellen einem g ultigen Muster unterliegen, sodass es m oglich ist, direkt von der Darstellung der Code-Stellen in den Quellcode selbst zu springen. Das wiederum erleichtert die Suche nach der entsprechenden Entscheidung, sodass das Andern einer Code-Entscheidung im Code kein Problem mehr darstellt. F ur dieses einfache Code-Entscheidungsmodell soll es jedoch lediglich m oglich sein, Pfade zu Klassen anzugeben, sodass in die entsprechende Klasse gesprungen werden kann. Da das Code-Entscheidungsmodell eine m ogliche Erweiterung des Kern-Entscheidungsmodells darstellt, besteht eine Code-Entscheidung nat urlich auch aus den bereits bekannten Attributen wie einer ID, einem Titel oder einer Beschreibung. Das bedeutet ebenso, dass sich Code-Entscheidungen auch in einem .decision-Modell speichern lassen wie auch Entscheidungen, die nur die Attribute des Kern-Entscheidungsmodells besitzen. Die technische Realisierung des Code-Entscheidungsmodells wird im n achsten Abschnitt beschrieben.

5.1.2. Code-Entscheidungsmodell
Wie zu Beginn des Kapitels bereits erw ahnt ist das Code-Entscheidungsmodell, das hier vorgestellt wird, lediglich ein Prototyp. Dieser soll verdeutlichen, dass der architekturelle Umbau des integrierten Ansatzes Erfolg hatte und weitere Artefakte zu einer Entscheidung dargestellt werden k onnen. Das Code-Entscheidungsmodell unterliegt daher dem in Abbildung 5.1.2 abgebildeten Modell. Wie man anhand der Abbildung erkennen kann, besteht das Modell der Einfachheit halber aus lediglich zwei modellbasierten Klassen und einem Enum. Zum Einen ist dies die Klasse CodeDecision. Diese erbt von der Klasse Decision, die im Kern-Entscheidungsmodell liegt. Damit ist der erste Schritt getan, um in einem Entscheidungsmodell-Editor CodeEntscheidungen anlegen zu k onnen. Die CodeDecision-Klasse hat dabei ein Attribut und eine Referenz zur zweiten Klasse. Das Attribut stellt hierbei den Typ der Entscheidung dar. Der Typ der Entscheidung kann ein beliebiges Literal aus dem gegebenen Enum sein. Die andere Klasse des Code-Entscheidungsmodells ist die SourceCodeReference -Klasse. Eine

34

5.2. Implementierung der Extension

35

Code-Referenz besteht dabei aus einer Beschreibung der Code-Stelle, aus dem PackageNamen, in dem sich die Code-Stelle bendet und aus dem Namen der Klasse. Die CodeStelle selbst ist dabei immer eine Kombination aus dem Package-Namen und dem Klassennamen, um somit doppelte Namen m oglichst ausschlieen zu k onnen. Damit die QuellcodeReferenz auch als Teil einer Code-Entscheidung angesehen werden kann, ist die Referenz zwischen Code-Entscheidung und Code-Referenz als Komposition modelliert. F ur eine funktionierende Integration in ein .decision-Modell muss jedoch noch eine Anderung am Code-Entscheidungsmodell vorgenommen werden. Vor der Erzeugung des Codes f ur die .edit-Komponente des Code-Entscheidungsmodells, muss diese nach [Mer08] im .genmodel des Code-Entscheidungsmodells noch angepasst werden. Dazu muss in der folgenden Zeile der Wert des Attributs childCreationExtenders auf true gesetzt werden. Listing 5.1: Ausschnitt des Genmodels des Code-Entscheidungsmodells
1 2 <genPackages prefix="Codedecision" basePackage="edu.kit.ipd.sdq.dm" resource=" XML" disposableProviderFactory="true" childCreationExtenders="false" ecorePackage="codedecision.ecore#/">

Das Setzen des Attributes auf true hat die Auswirkung, dass das Code-Entscheidungsmodell als Erweiterung eines bestehenden Modells angesehen werden kann. In diesem Fall stellt es eine Erweiterung zum Kern-Entscheidungsmodell dar, da die Klasse CodeDecision von Decision erbt. Uber das .genmodel kann nun der Code des Models und der .editKomponente erzeugt werden. Nach Erstellung dieser Komponenten sollte es nun m oglich sein ein .decision-Modell mit Hilfe eines bestehenden Decision Model Editor s zu o nen und neue Code-Entscheidungen anzulegen. Beim Erstellen des Code-Entscheidungsmodells war dies jedoch nicht der Fall. Zus atzlich mussten die plugin.xml -Dateien der .edit-Komponenten des Kern-Entscheidungsmodells sowie des Code-Entscheidungsmodells neu erstellt werden, da bestimmte Referenzen nicht korrekt beim Generieren des Codes in die plugin.xml-Datei geschrieben wurden. Auf diese Weise k onnen spezische Entscheidungsmodelle in den neu entstandenen Ansatz integriert werden. Das Endergebnis im Decision Model Editor sowie im Design Decision Editor wird in Abschnitt 5.3 gezeigt. Der n achste Abschnitt beschreibt die Anbindung des Code-Entscheidungsmodells an den in Kapitel 4.2 implementierten Extension-Point, sodass Code-Entscheidungen nicht nur in Baum-Struktur angelegt werden k onnen, sondern die einzelnen Artefakte auch im gegebenen Design Decision Editor dargestellt werden k onnen.

5.2. Implementierung der Extension


Um nun die weiteren Code-Artefakte auch im Design Decision Editor anzeigen lassen zu k onnen, muss der in Kapitel 4.2 denierte Extension-Point verwendet werden. Da zu wird in der Ubersicht des Plug-ins unter dem Reiter Extensions eine neue Extension edu.kit.ipd.sdq.dm.extensionpoint angelegt. Im Anschluss daran muss dieser Extension das interface.denition -Element hinzugef ugt werden. Bei diesem Element kann man nun eine Klasse ausw ahlen, die das vorgegebene Interface implementiert. Aufgrund der Denition des Extension-Points ist es nicht m oglich eine weitere Klasse zu diesem Extension-Point hinzuzuf ugen, die ebenso das Interface implementiert. Das Ergebnis des Einbindens des Extension-Points kann man Abbildung 5.2 entnehmen. Methoden-Implementierung Damit nun endg ultig im Design Decision Editor auch die Artefakte der Code-Entscheidungen angezeigt werden, muss nun noch die Methode getRelatedDecisionArtifacts(...) implementiert werden. Dazu sei das Listing in 5.2 gegeben.

35

5. Validierung

Abbildung 5.2.: Ubersicht des Plug-ins nach Anlegen des Extension-Points 36

36

5.2. Implementierung der Extension Listing 5.2: Implementierung der getRelatedDecisionArtifacts()-Methode


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 @Override public Composite getRelatableDecisionArtifacts(Section parent, Decision d) { CodeDecision match = null; try { match = (CodeDecision) d; } catch (ClassCastException e) { // return null since the decision is not a code decision return null; } Composite newComp = null; if (match != null) { ... } return newComp; }

37

Das Listing zeigt lediglich den Teil der Methode, der f ur das Uberpr ufen der Entscheidung zust andig ist. Das komplette Listing ist im Anhang der Bachelorarbeit dargestellt. Wie in 3.4.1 erw ahnt bekommt die Methode getRelatableDecisionArtifacts() zwei Parameter u bergeben. Der erste Parameter stellt hierbei die Section dar, in die sich das neue Composite einf ugen soll und der zweite Parameter stellt die Entscheidung dar, f ur die u uft berpr werden soll, ob es sich hierbei um eine Code-Entscheidung handelt. Das Uberpr ufen der Entscheidung gestaltet sich dadurch denkbar einfach, dass das Code-Entscheidungsmodell als Erweiterung zum Kern-Entscheidungsmodell gehandhabt wird. So wird es erm oglicht, dass ein einfacher Cast ausreicht, um zu testen ob die u bergebene Entscheidung eine CodeEntscheidung ist. Falls der Cast fehlschl agt und dadurch eine Exception geworfen wird, reicht es ein Null-Objekt zur uck zu liefern, um der DecisionPage zu signalisieren, dass es zur u bergebenen Entscheidung keine weiteren Artefakte in diesem Entscheidungsmodell gibt. Im weiteren Verlauf der Methode wird das Composite mit den darzustellenden Artefakten gef ullt und die Funktion eingef ugt, die es erlaubt bei einem Klick auf die dargestellte Code-Stelle direkt zur Klasse springen zu k onnen. Sprung zur Code-Stelle Die Code-Stelle wird im Design Decision Editor als Link angezeigt. F ur die Realisierung des Sprungs zur Klasse bei angeklicktem Link, wird f ur den Link ein SelectionAdapter implementiert. Die Methode des SelectionAdapters wird dabei immer dann aufgerufen, wenn der Link mit der Maus angeklickt wird. Die Methode des SelectionAdapters ist in Listing 5.3 dargestellt.

37

38 Listing 5.3: Methode des SelectionAdapters


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

5. Validierung

@Override public void widgetSelected(SelectionEvent e) { String className = reference.getClassName(); Shell parent = PlatformUI.getWorkbench().getActiveWorkbenchWindow().getShell (); try { List<ICompilationUnit> compilationUnits = getCompilationUnitsByClassName( className, reference.getPackageURL()); if (compilationUnits.size() > 0) { JavaUI.openInEditor(compilationUnits.get(0)); } else { MessageDialog.openInformation(parent, className, "Couldnt find " + className + " in the current workspace. If this class name is valid, the corresponding class has to be in the current workspace"); } } catch (PartInitException e1) { MessageDialog.openError(parent, "Exception!", "Editor failed to initialize. Cannot display class " + className); } catch (JavaModelException e1) { MessageDialog.openError(parent, "Exception!", "Exception occured while trying to access class " + className); } catch (CoreException e1) { MessageDialog.openError(parent, "Exception!", "The project containing class " + className + " is not in the workspace"); } }

Der Hauptteil dieser Methode bendet sich im try-catch-Block. Vorher wird lediglich der Klassenname in eine Variable geschrieben sowie die aktuelle Shell in einer Variable gespeichert. Die Shell, sowie der Klassenname werden ben otigt, falls etwas beim Finden oder Onen der gesuchten Klasse schief geht. Im try-catch-Block wird zuerst eine Liste von sogenannten ICompilationUnit s erzeugt. Eine solche Einheit ist in diesem Fall immer eine .java-Datei. Die Liste wird anhand des Package- und des Klassennamens geltert, sodass die Liste, sofern die Kombination aus Klassen- und Package-Namen einzigartig ist, immer aus h ochstens einem Element besteht. Eine genauere Betrachtung der Listenerzeugung folgt nach Listing 5.4. Sofern nun mindestens eine Einheit gefunden wurde, die dem Klassennamen und dem Package-Namen entspricht, kann ein Editor aufgerufen werden, der die Klasse zeigt. Dabei wird pro gefundener Einheit ein Fenster ge onet. Im Normalfall sollte jedoch nur ein Fenster ge onet werden, da eine Kombination aus Package- und Klassennamen einzigartig ist. Falls keine Klasse gefunden oder eine Exception geworfen wird, werden f ur jeden genannten Fall dem Benutzer ein Dialogfenster gezeigt, das erkl art was schief gelaufen ist. Nachfolgend gibt das Listing 5.4 Aufschluss dar uber, welchen Grenzen die Verfolgung von Code-Entscheidungen in den Quellcode unterliegen.

38

5.3. Ergebnis der Anbindung Listing 5.4: Finden der entsprechenden Klasse anhand des Klassennamens
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

39

private List<ICompilationUnit> getCompilationUnitsByClassName(String clazzName, String packageName) throws JavaModelException, CoreException { List<ICompilationUnit> compilationUnits = new ArrayList<ICompilationUnit>(); // Retrieve all the source roots IWorkspace workspace = ResourcesPlugin.getWorkspace(); IWorkspaceRoot workspaceRoot = workspace.getRoot(); IProject[] projects = workspaceRoot.getProjects(); for (IProject project : projects) { IJavaProject javaProject = (IJavaProject) project.getNature(JavaCore. NATURE_ID); if (javaProject != null) { compilationUnits.addAll(getCompilationUnitsForProject(clazzName, javaProject, packageName)); } } return compilationUnits; }

Diese private Methode l adt zuerst den aktuellen Workspace. Uber diesen k onnen dann alle Projekte geladen werden, die sich im aktuellen Workspace benden. Damit l asst sich anschlieend f ur jedes einzelne Projekt u ufen, ob sich in diesem Projekt die gesuchte berpr Klasse bendet. Dabei muss das Projekt ein Java-Projekt sein. Die Methode getCompilationUnitsForProject(...), die hier nicht aufgef uhrt ist, u uft dann lediglich f ur jedes berpr Package, ob es dem Package-Namen entspricht, der u bergeben wurde. Falls die Namen identisch sind, werden die Klassen durchsucht, die sich in diesem Package benden. Wenn die richtige Klasse anhand des Klassennamens gefunden wird, wird sie der Liste von CompilationUnits hinzugef ugt. Die vollst andige Klasse CodeDecisionRelatable ist im Anhang unter E-5 aufgef uhrt. Es ist in dieser Implementierung des Code-Entscheidungsmodells also lediglich m oglich zu vollst andigen Klassen-Implementierungen zu springen, die sich auch im aktuellen Workspace benden. Allerdings basieren die Code-Entscheidungen, die eine bestimmte Klasse beinhalten auch auf selbstgeschriebenen Klassen. Diese benden sich sowieso in dem aktuellen Workspace, sodass es f ur dieses einfache Code-Entscheidungsmodell keine Rolle spielt, dass nur zu solchen Klassen im Rahmen einer Code-Entscheidung gesprungen werden kann.

5.3. Ergebnis der Anbindung


Nachdem nun ein Modell besteht, das zur Validierung des f oderierten Ansatzes verwendet werden kann, muss dieses auch getestet werden. Onet man nun ein .decision-Modell mit dem Decision Model Editor, ist es m oglich Code-Entscheidungen in das Modell einzuf ugen. Abbildung 5.3 zeigt einen Screenshot, der beim Hinzuf ugen einer Code-Entscheidung gemacht wurde. Die anderen Arten von Entscheidungen, die hier noch gew ahlt werden k onnen auer Stakeholder, Decision und Constraint geh oren zum existierenden Architektur-Entscheidungsmodell, dass zum Zeitpunkt der Bachelorarbeit noch nicht als eigenst andiges Modell migriert wurde. Zus atzlich zum Anlegen einer Code-Entscheidung l asst sich nun ebenfalls eine Referenz zum Quellcode anlegen wie in Abbildung 5.3 dargestellt. Der Referenz kann man, wie einer Code-Entscheidung oder einem beliebigen anderen Artefakt einer Entscheidung, alle Attribute u ber die Properties-View der Entwicklungsumgebung hinzuf ugen. F ur eine Quellcode-Referenz enth alt die Properties-View drei Eintr age, die f ur die drei Attribute der Klasse SourceCodeReference stehen. Beispielhaft zeigt Abbildung 5.3 die Properties-View einer Quellcode-Referenz.

39

40

5. Validierung

Abbildung 5.3.: Das Anlegen einer Code-Entscheidung u ber den Decision Model Editor

40

5.3. Ergebnis der Anbindung

41

Abbildung 5.4.: Anlegen einer Referenz zum Quellcode u ber den Decision Model Editor

Abbildung 5.5.: Die Properties-View bei Auswahl einer Quellcode-Referenz

41

42

5. Validierung

Onet man das .decision-Modell nach dem Hinzuf ugen der Entscheidung mit einem TextEditor, sieht man in Listing 5.5, dass die folgenden Eintr age dabei entstanden sind. Listing 5.5: das .decision-Modell nach Hinzuf ugen einer Code-Entscheidung
1 <decisions xsi:type="codedecision:CodeDecision" ID="002" title="Test Code Decision" description="Simple Test Code Decision" madeBy="//@stakeholders.0 "> <sourceCodeReferences description="Code Reference to the generated code decision class" className="CodeDecisionImpl" packageURL="edu.kit.ipd. sdq.dm.codedecision.impl"/> </decisions>

Die angelegte Entscheidung ist also als Code-Entscheidung typisiert worden. Weiterhin wurde die Quellcode-Referenz hinzugef ugt. Die Attribute className und packageURL geben zusammen hierbei beispielhaft den Pfad an, der zur Implementierung der CodeDecision -Klasse f uhrt. Das vollst andige .decision-Modell mit dem in dieser Bachelorarbeit gearbeitet wurde, bendet sich im Anhang in Listing C-3. Nachdem gezeigt wurde, dass es m oglich ist neue Code-Entscheidungen in einem .decision-Modell anzulegen, folgt die Validierung des Extension-Points. Hierbei muss gezeigt werden, dass der Typ der CodeEntscheidung und die Referenz zum Quellcode im Design Decision Editor angezeigt werden, wenn eine Code-Entscheidung dem Code-Entscheidungsmodell u bergeben wird. Abbildung 5.3 zeigt, dass die Artefakte zur Code-Entscheidung korrekt dargestellt werden, wenn eine Code-Entscheidung ausgew ahlt wird. Durch einen Klick auf den als Link dargestellten Pfad, wird direkt zur Implementierung der Klasse CodeDecision gesprungen. Anhand dieser Abbildungen kann man also erkennen, dass die Migration zum f oderierten Ansatz erfolgreich war. Es ist also m oglich weitere Entscheidungsmodelle, die eine Erweiterung zum Kern-Entscheidungsmodell darstellen, in den Ansatz zu integrieren, ohne dass der bestehende Ansatz ver andert werden muss. Das folgende Kapitel behandelt m ogliche Erweiterungen dieses Ansatzes und m ogliche zuk unftige Arbeiten daran.

42

5.3. Ergebnis der Anbindung

43 43

Abbildung 5.6.: Korrekte Darstellung der Code-Entscheidung im Design Decision Editor

6. Zusammenfassung und Ausblick


Dieses Kapitel soll die gewonnenen Erkenntnisse noch einmal zusammenfassen, sowie einen Ausblick dar uber geben, was an dem nun entstandenen Ansatz verbessert und erweitert werden kann. Ebenso werden Probleme angesprochen, die im bestehenden Ansatz existieren und in zuk unftigen Arbeiten ausgebessert werden sollten. Weiterhin wird auf die Verwendungsm oglichkeiten dieses Ansatzes eingegangen.

6.1. Oene Probleme


Bevor eine Zusammenfassung der erreichten Ziele erfolgt, sollen hier noch Probleme angesprochen werden, die bereits vor dieser Bachelorarbeit bestanden, sowie Probleme, die erst im Zuge des f oderierten Ansatzes entstanden sind, die sich bis zum Ende der Arbeit jedoch nicht beheben lieen. Die bestehenden Probleme beziehen sich jedoch alle indirekt auf die Darstellung der Artefakte einer Entscheidung. Eines dieser Probleme ist, dass bei einem Klick auf eine beliebige Entscheidung im Outline des Design Decision Editors alle Entscheidungen oberhalb der ausgew ahlten Entscheidung zur gleichen Entscheidungen werden. Die Entscheidungen werden zwar nicht im Modell u berschrieben, dennoch ist es so nicht m oglich von einer sp aten Entscheidung wieder zur uck zu einer vorher getroenen Entscheidung im Editor zu gelangen. Die momentane L osung besteht nur darin den Editor zu schlieen und das .decision-Modell erneut zu onen. Ein weiteres Problem tritt dann auf, wenn aus spezischen Entscheidungsmodellen weitere Artefakte geladen werden. Da die Section mit den weiteren Artefakten neu geladen werden muss, wird die alte Section zuerst verworfen. Das Neuladen der Section hat dann zur Folge, dass diese nicht direkt im Editor dargestellt wird. Der Editor muss zuerst gr oer oder kleiner gemacht werden, bevor die Section zu sehen ist. Das Problem lie sich auch dadurch nicht beheben, dass explizit die redraw() -Methode der Section aufgerufen wurde. Die Dokumentation der Methode sagt zwar, dass der Editor bei der n achst m oglichen Gelegenheit neu gezeichnet wird, jedoch trit das nicht zwingend zu. Die n achst m ogliche Gelegenheit stellt dabei immer eine Ver anderung der Gr oe des gesamten Fensters dar, in dem die Methode aufgerufen wird. Diese Ver anderung muss momentan noch vom Benutzer stattnden, da selbst das manuelle Ver andern der Gr oe im Code nach Aufruf der Methode keine Wirkung erzielte. Ein letztes bestehendes Problem h angt mit dem Speichern von von Entscheidungen zusammen, die im Design Decision Editor ge onet sind. Falls das Attribut noch nicht existiert hat, wird es durch das Speichern auch nicht hinzugef ugt. Ein Beispiel daf ur ist die Begr undung einer getroenen Entscheidung (Rationale). Hat eine Entscheidung noch

45

46

6. Zusammenfassung und Ausblick

keine Rationale, ist das entsprechende Feld im Design Decision Editor leer. Es l asst sich nun zwar eine Begr undung zur Entscheidung in das Textfeld schreiben, das Speichern hat dann jedoch keinen Einuss darauf, da im .decison-Modell noch keine Begr undung zu dieser Entscheidung existiert hat. Existiert das Attribut jedoch vorher auch schon im .decision-Modell, stellt das Bearbeiten und Speichern kein Problem mehr dar. F ur Artefakte, die nicht im Kern-Entscheidungsmodell liegen, gilt das allerdings nicht. F ur diese ist es im Moment lediglich m oglich sie darzustellen. Eine Funktion, die das Bearbeiten und anschlieende Speichern der Artefakte erlaubt, ist also noch nicht vorhanden. Dazu w are ein funktionierendes Binding zwischen den Komponenten im Editor und dem Composite mit den zus atzlichen Artefakten n otig. Theoretisch liee sich dieses Binding u ber eine zus atzliche Methode im DecisionRelatable-Interface realisieren, die von den weiteren Entscheidungsmodellen implementiert werden muss. Die Praxis hat jedoch gezeigt, dass Plug-in- ubergreifende Bindings nicht ohne weiteres funktionieren, sodass auf diese Funktion aus Zeitgr unden verzichtet werden musste.

6.2. Zusammenfassung
Das urspr ungliche Problem, das dieser Arbeit vorangegangen ist, war, dass Entscheidungen bei der Entwicklung eines Softwaresystems nicht ausreichend dokumentiert werden. Dies wird jedoch zunehmend wichtiger, da die Wartung bestehender Software eine immer gr oere Zeitspanne einnimmt. Das Dokumentieren von Entwurfsentscheidungen bringt jedoch den Vorteil eines geringeren Wartungsaufwandes mit sich, da so bekannt ist, auf welche Komponenten des Softwaresystems eine Entscheidung Einuss hat. Somit k onnen die entsprechenden Komponenten leichter bearbeitet werden. Davon ausgehend wurden M oglichkeiten diskutiert Entwurfsentscheidungen sinnvoll zu dokumentieren. Dabei hat sich gezeigt, dass ein modellbasierter Ansatz die meisten Vorteile mit sich bringt. Deswegen wurde der bestehende integrierte Ansatz weiter verfolgt. Das Ziel dieser Bachelorarbeit war es dabei einen Ansatz zu nden, in den Code-Entscheidungsmodelle integriert werden k onnen, ohne den Ansatz f ur das Entscheidungsmodell anpassen zu m ussen. Das ist auf l angere Sicht betrachtet sinnvoll, da so der Wartungsaufwand des Ansatzes sinkt, sowie einzelne Entscheidungsmodelle ohne weiteres gegeneinander ausgetauscht werden k onnen. Dieses Ziel wurde mit der Einf uhrung des f oderierten Ansatzes erreicht. Der f oderierte Ansatz erm oglicht es nun das Kern-Entscheidungsmodell vollkommen unangetastet zu lassen, wenn neue Entscheidungsmodelle integriert werden sollen. F ur den f oderierten Ansatz wurden somit die Entscheidungsmodelle voneinander entkoppelt. Um nun noch spezische Entscheidungen anlegen zu k onnen, die dem Kern-Entscheidungsmodell unbekannt sind, kennen die spezischen Entscheidungsmodelle das Kern-Entscheidungsmodell. Somit ist es m oglich vom Kern-Entscheidungsmodell zu erben und neue Entscheidungstypen zu denieren. F ur die graphische Darstellung einer Entscheidung in einer Benutzerober ache ist der vorhandene Design Decision Editor zust andig. Damit dieser Editor jedoch auch Artefakte darstellen kann, die nicht zum Kern-Entscheidungsmodell geh oren, wurde weiterhin eine Schnittstelle eingef uhrt. Die Schnittstelle hat die Aufgabe bei Bedarf weitere Artefakte zu einer Entscheidung in einer Darstellungskomponente zu sammeln und an den Design Decision Editor weiter zu leiten. F ur diesen Zweck bot sich ein Interface an, das von allen spezischen Entscheidungsmodellen implementiert werden muss. Da der bestehende Ansatz bereits f ur die Entwicklungsumgebung Eclipse implementiert wurde, hat es sich angeboten den f oderierten Ansatz ebenfalls f ur Eclipse zu implementieren. Dadurch hat sich der Vorteil ergeben die Schnittstelle u ber den Extension-Point-Mechanismus der Entwicklungsumgebung zu realisieren. Mittels dem Extension-Point-Mechanismus ist es m oglich auf Plugins zuzugreifen, die nur u ber eine fest stehende ID dem Extension-Point bekannt sind. Damit besteht die M oglichkeit auf Klassen, die das angebotene Interface implementieren, zuzugreifen und somit auch an weitere Artefakte zu einer Entscheidung zu gelangen. Somit

46

6.3. Ausblick

47

lassen sich weitere Entscheidungsmodelle in den Ansatz integrieren, ohne dass das KernEntscheidungsmodell die weiteren Modelle kennen muss. Dadurch konnte auch eine Validierung u ber ein Code-Entscheidungsmodell stattnden. Das Code-Entscheidungsmodell ist dabei nur als Prototyp zu verstehen und zeigt, dass die Migration zum f oderierten Ansatz Erfolg hatte. Neben der Validierung bringt das Code-Entscheidungsmodell allerdings auch weitere Vorteile mit sich. Somit ist es nun m oglich, Entscheidungen, die sich auf den Quellcode beziehen, anzulegen und der angelegten Entscheidung Klassen zuzuweisen, die mit dieser Entscheidung in Verbindung stehen. Weiterhin ist es m oglich vom Design Decision Editor u achlichen ber einen Klick auf eine als Link dargestellte Code-Stelle in den tats Quellcode, der zur angelegten Entscheidung geh ort, zu springen, ohne die Klasse vorher suchen zu m ussen. Abschlieend werden noch m ogliche weitere Arbeiten diskutiert, die zuk unftig auf diesem Ansatz aufbauen k onnen.

6.3. Ausblick
Es existieren verschiedene Ansatzpunkte, um den f oderierten Ansatz oder das CodeEntscheidungsmodell noch zu erweitern. Diese Erweiterungen k onnen in zuk unftigen Arbeiten eingebaut werden. Nachfolgende werden beide Bereiche getrennt voneinander betrachtet. Struktur anderungen des Ansatzes Die hier entwickelte Schnittstelle ist in ihrer momentanen Implementierung sehr speziell und kann auch nur im Zusammenhang mit dem Kern-Entscheidungsmodell und einem ahnlich aufgebauten Design Decision Editor verwendet werden. F ur andere Einsatzgebiete m usste man die Schnittstelle ab andern. Dies k onnte zum Beispiel dahingehend geschehen, dass von der Methode des Interfaces kein Composite zur uckgegeben wird, sondern eine Map. Diese Map k onnte als key-value-Paare den Namen des Artefaktes und den entsprechenden Inhalt als String beinhalten. Damit liee sich selbst bestimmen, in welche Darstellungskomponenten sich die einzelnen Paare einf ugen sollte. Weiterhin k onnte so auch eine Konsolenausgabe erreicht werden. Um die Schnittstelle unabh angig vom verwendeten Kern-Entscheidungsmodell machen zu k onnen, muss die Ubergabe der Entscheidung verandert werden. Es d urfte kein Entscheidungsobjekt mehr u bergeben werden, sondern nur noch die ID der Entscheidung. Dann m ussten die spezischen Entscheidungsmodelle das zu Grunde liegende DecisionModel referenzieren, um die Entscheidung zur ID zu nden und dann k onnte getestet werden, ob es sich bei der gefundenen Entscheidung um eine spezische Entscheidung handelt. Der Mehraufwand, der so entsteht, h atte allerdings zur Folge, dass die Schnittstelle in ihrer jetzigen Form f ur beliebige Entscheidungsmodelle funktioniert und nicht nur f ur das vorhandene Kern-Entscheidungsmodell. Ein weiterer Punkt, an dem zuk unftige Arbeiten ansetzen k onnten, ist die Darstellung der weiteren Artefakte. Wie man anhand des Architektur-Entscheidungsmodells sehen kann, gibt es eine ganze Rei he von unterschiedlichen Architektur-Entscheidungen. Einen Uberblick aller ArchitekturEntscheidungen ist in 5.3 zu sehen. Jede dieser Entscheidungen kann dementsprechend die unterschiedlichsten Attribute aufweisen. Die Frage, die sich dann dabei stellt, ist, ob es noch sinnvoll ist den zus atzlichen Artefakten lediglich das rechte untere Eck des Design Decision Editors zu u amlich entsprechend viele Artefakte existieren, k onnte man berlassen. Sollten n diese sinnvollerweise auf einer eigenen Seite des Editors unterbringen. Dadurch w are die vorhandene DecisionPage nicht mehr die einzige Seite des Editors. Ein letzter Punkt, der in diesem Abschnitt noch angesprochen werden soll, behandelt den Aufbau der Entscheidungsmodelle. F ur Architektur- sowie Code-Entscheidungen kann es manchmal vorkommen, dass eine Entscheidung sowohl dem einen Modell zugesprochen werden kann als auch dem anderen. Das beste Beispiel daf ur sind Entwurfsmuster. Ein Entwurfsmuster kann einem architekturellen Artefakt zugesprochen werden, die Implementierung dessen jedoch

47

48

6. Zusammenfassung und Ausblick

einem Code-Artefakt. In der momentanen Implementierung m ussten f ur dieses Szenario zwei Entscheidungen angelegt werden, die keine Verbindung zueinander haben, obwohl Titel, Beschreibung, Rationale und Alternativen nahezu identisch sein k onnen. Es w are in diesem Fall also hilfreich, wenn man beim Anlegen einer Code-Entscheidung auch auf bereits bestehende Architektur-Entscheidungen zugreifen k onnte. F ur die Realisierung dessen w are allerdings ein generischer Ansatz n otig, der es dem Code-Entscheidungsmodell, oder anderen Entscheidungsmodellen, erlaubt andere bestehende Artefakte einzusehen. Generisch m usste dieser Ansatz deswegen sein, da ein Entscheidungsmodell nicht wissen kann welche anderen Entscheidungsmodelle bereits existieren. Anderungen am Code-Entscheidungsmodell Da es sich bei dem aktuellen Code-Entscheidungsmodell lediglich um einen Prototypen handelt, sind die m oglichen Anderungen daran vielz ahlig. Klar ist, dass das zu Grunde liegende Modell weitaus vielf altiger sein kann als das bisher bestehende. Zus atzlich zu m oglichen Modellklassen, lieen sich noch einige Features einbauen. Zum Beispiel sollte es erm oglicht werden nicht nur komplette Klassen von der Darstellung der Artefakte zum Quellcode nachverfolgen zu k onnen, sondern auch Methoden, statische Attribute oder Plug-ins. Vor allem, wenn bestimmte Klassen aus Plug-ins eine Entscheidung repr asentieren, sollte es m oglich sein, auch zu dieser Klasse zu springen, selbst wenn sie sich nicht im aktuellen Workspace bendet. Ebenso sollten Code-Stellen angegeben werden k onnen, in denen die Klasse zum Einsatz kommt. Solche Stellen beschr anken sich meistens nur auf wenige Zeilen und sind deshalb schwer zu nden. Um dem Benutzer die Arbeit abnehmen zu k onnen, selbst den Pfad zur Code-Stelle eintragen zu m ussen, k onnte das CodeEntscheidungsmodell auch dahingehend erweitert werden, sodass es m oglich ist, CodeZeilen zu markieren und diese direkt als neue Code-Entscheidung hinzuzuf ugen. Dadurch m usste man nicht von der eigentlichen Implementierung zum Decision Model Editor springen, sondern k onnte im aktuell ge oneten Java Editor bleiben und Code-Entscheidungen direkt anlegen. F ur dieses Feature ist jedoch Wissen u ber den internen Aufbau von Eclipse und dem JDT notwendig, da diese Funktion an der Stelle eingebaut werden m usste, an der man mittels einem Rechtsklick auf die markierte Code-Stelle klickt. Die bisherigen Funktio wird man dabei nicht einfach u nen wie Code formatieren o.A. berschreiben wollen, sodass sich das Feature in den bestehenden Ansatz einf ugen muss. Ein weiteres Feature, das f ur das Code-Entscheidungsmodell n utzlich sein kann, betrit die Syntaxhervorhebung. Dabei k onnten, sofern das Code-Entscheidungsmodell aktiv ist, alle Code-Stellen im Java Editor farblich hervorgehoben werden, die mit einer Code-Entscheidung zu tun haben. Somit l auft man nicht Gefahr eine Entscheidung zweimal anzulegen. Weiterhin k onnte man dann noch eine Funktion einrichten, die es erlaubt, vom Code direkt zur betreenden Entscheidung im Design Decision Editor zu springen. Damit w are eine bidirektionale Nachverfolgbarkeit gegeben, da man dann von der Entscheidung zum jeweiligen Code-Abschnitt springen kann und auch umgekehrt. Zusammenfassend l asst sich also sagen, dass nicht nur am Code-Entscheidungsmodell weitere Funktionen eingebaut werden k onnten, sondern auch allgemein bei der Art und Weise des Aufbaus der einzelnen Modelle.

48

Literaturverzeichnis
[BB08] Janet E. Burge and David C. Brown: Software engineering using rationale. J. Syst. Softw., 81(3):395413, March 2008, ISSN 0164-1212. http://dx. doi.org/10.1016/j.jss.2007.05.004. Rafael Capilla, Francisco Nava, and Juan C. Duenas: Modeling and documenting the evolution of architectural design decisions. In Proceedings of the Second Workshop on SHAring and Reusing architectural Knowledge Architecture, Rationale, and Design Intent, SHARK-ADI 07, pages 9, Washington, DC, USA, 2007. IEEE Computer Society, ISBN 0-7695-2951-8. http://dx.doi.org/10.1109/SHARK-ADI.2007.9. Eclipse Foundation: http://help.eclipse.org/indigo/index.jsp?topic=%2forg. eclipse.platform.doc.isv%2freference%2fapi%2forg%2feclipse%2fcore%2 fruntime%2extensionregistry.html. Release for Eclipse 3.7.

[CND07]

[Fou]

[GCHH+ 12] Orlena Gotel, Jane Cleland-Huang, JaneHuman Hayes, Andrea Zisman, Alexander Egyed, Paul Gr unbacher, Alex Dekhtyar, Giuliano Antoniol, Jonathan Maletic, and Patrick M ader: Traceability fundamentals. In Jane Cleland-Huang, Orlena Gotel, and Andrea Zisman (editors): Software and Systems Traceability, pages 322. Springer London, 2012, ISBN 978-1-4471-2238-8. http://dx.doi.org/10.1007/ 978-1-4471-2239-5_1. [IR12] Claire Ingram and Steve Riddle: Cost-benets of traceability. In Jane ClelandHuang, Orlena Gotel, and Andrea Zisman (editors): Software and Systems Traceability, pages 2342. Springer London, 2012, ISBN 978-1-4471-2238-8. http://dx.doi.org/10.1007/978-1-4471-2239-5_2. Martin K uster: https://svnserver.informatik.kit.edu/i43/svn/code/decision requirements/trunk/edu.kit.ipd.sdq.dm/model/dm core.ecorediag. CoreDecisionModel containing the DecisionModel part. Patrick K onemann and Olaf Zimmermann: Linking design decisions to design models in model-based software development. In MuhammadAli Babar and Ian Gorton (editors): Software Architecture, volume 6285 of Lecture Notes in Computer Science, pages 246262. Springer Berlin Heidelberg, 2010, ISBN 978-3-642-15113-2. http://dx.doi.org/10.1007/ 978-3-642-15114-9_19. Ed Merks: http://ed-merks.blogspot.de/2008/01/creating-children-you-didntknow.html, 2008. Last visited November, 07, 2013. Jerey Stylos and Brad Myers: Mapping the space of api design decisions. In Proceedings of the IEEE Symposium on Visual Languages and HumanCentric Computing, VLHCC 07, pages 5060, Washington, DC, USA, 2007. IEEE Computer Society, ISBN 0-7695-2987-9. http://dx.doi.org/10. 1109/VLHCC.2007.36.

[K u]

[KZ10]

[Mer08] [SM07]

49

50 [TJH07]

Literaturverzeichnis Antony Tang, Yan Jin, and Jun Han: A rationale-based architecture model for design traceability and reasoning. Journal of Systems and Software, 80(6):918 934, 2007, ISSN 0164-1212. http://www.sciencedirect. com/science/article/pii/S0164121206002287. Unknown: https://svnserver.informatik.kit.edu/i43/svn/code/decision requirements/trunk/edu.kit.ipd.sdq.dm/model/dm issue.ecorediag. CoreDecisionModel containing the IssueModel part. VassiliosC. Vescoukis, Nikolaos Papaspyrou, and Emmanuel Skordalakis: A logic-based framework for reasoning support in software evolution. In Panos Constantopoulos, John Mylopoulos, and Yannis Vassiliou (editors): Advanced Information Systems Engineering, volume 1080 of Lecture Notes in Computer Science, pages 4459. Springer Berlin Heidelberg, 1996, ISBN 978-3-540-61292-6. http://dx.doi.org/10.1007/ 3-540-61292-0_3.

[Unk]

[VPS96]

[WML+ 89] C. Wild, K. Maly, L. Liu, J. S. Chen, and T. Xu: Decision-based software development: design and maintenance. In Software Maintenance, 1989., Proceedings., Conference on, pages 297306, 1989.

50

7. Anhang
A. Extension-Point-Schema
Listing A-1: Denition des Interfaces im Extension-Point-Schema
1 2 3 4 5 6 <?xml version=1.0 encoding=UTF-8?> <!-- Schema file written by PDE --> <schema targetNamespace="edu.kit.ipd.sdq.dm.extensionpoint.definition" xmlns=" http://www.w3.org/2001/XMLSchema"> <annotation> <appinfo> <meta.schema plugin="edu.kit.ipd.sdq.dm.extensionpoint.definition" id= "edu.kit.ipd.sdq.decisioninterface.definition" name=" DecisionInterfaceDefinition"/> </appinfo> <documentation> This Extension Point should be used for plugins that contain specific decision models. Using this extension point provides the core decision model with further decision artifacts. </documentation> </annotation> <element name="extension"> <annotation> <appinfo> <meta.element /> </appinfo> </annotation> <complexType> <choice> <element ref="interface.definition"/> </choice> <attribute name="point" type="string" use="required"> <annotation> <documentation> </documentation> </annotation> </attribute> <attribute name="id" type="string"> <annotation> <documentation>

7 8 9

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

51

52
34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 </documentation> </annotation> </attribute> <attribute name="name" type="string"> <annotation> <documentation> </documentation> <appinfo> <meta.attribute translatable="true"/> </appinfo> </annotation> </attribute> </complexType> </element>

7. Anhang

<element name="interface.definition"> <complexType> <attribute name="decisioninterface" type="string" use="required"> <annotation> <documentation> </documentation> <appinfo> <meta.attribute kind="java" basedOn=":edu.kit.ipd.sdq.dm. extensionpoint.definition.DecisionRelatable"/> </appinfo> </annotation> </attribute> </complexType> </element> <annotation> <appinfo> <meta.section type="since"/> </appinfo> <documentation> 1.0 </documentation> </annotation>

81 82 83 84 85 86 87 88 89

<annotation> <appinfo> <meta.section type="apiinfo"/> </appinfo> <documentation> The user willing to use this extension point has to implement the interface DecisionRelatable which is provided by this extension point. The method that must be implemented gets a decision, should check if the decision is also a specific decision and, if it is, return a Composite containing to the decision related artifacts. If it is not a specific decision null should be returned </documentation> </annotation> <annotation> <appinfo> <meta.section type="implementation"/> </appinfo> <documentation> The implementation of this extension point simply gets all classes that implement DecisionRelateable and returns them as a list to the core decision model.

52

B. Manifest-Datei der Schnittstelle


90 91 92 93 94 </documentation> </annotation>

53

</schema>

B. Manifest-Datei der Schnittstelle


Listing B-2: MANIFEST.MF-Datei der verwendeten Schnittstelle
1 2 3 4 5 6 7 8 9 10 11 12 13 14 Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Definition Bundle-SymbolicName: edu.kit.ipd.sdq.dm.extensionpoint.definition;singleton:= true Bundle-Version: 1.0.0.qualifier Bundle-RequiredExecutionEnvironment: JavaSE-1.7 Require-Bundle: org.eclipse.core.runtime;bundle-version="3.8.0", org.eclipse.ui.forms;bundle-version="3.5.200", edu.kit.ipd.sdq.dm;bundle-version="1.0.0", org.eclipse.emf.databinding;bundle-version="1.3.0", org.eclipse.jface.databinding;bundle-version="1.6.0", org.eclipse.swt;bundle-version="3.100.1" Export-Package: edu.kit.ipd.sdq.dm.extensionpoint.definition, edu.kit.ipd.sdq.dm.extensionpoint.executor

C. Decision-Modell mit Code-Entscheidung


Listing C-3: Das verwendete .decision-Modell mit angelegter Code-Entscheidung
1 2 <?xml version="1.0" encoding="ASCII"?> <decision:DecisionModel xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:codedecision=" http://sdq.ipd.kit.edu/CodeDecisionModel/0.1" xmlns:decision="http://sdq. ipd.kit.edu/DecisionMetaModel/0.1"> <decisions ID="001" title="Decision Title" description="Simple Test Decision" madeBy="//@stakeholders.0"> <rationale description="Simple Test Rationale"/> </decisions> <decisions xsi:type="codedecision:CodeDecision" ID="002" title="Test Code Decision" description="Simple Test Code Decision" madeBy="//@stakeholders .0"> <sourceCodeReferences descr="Code Reference to the generated code decision class" codeURL="edu.kit.ipd.sdq.dm.codedecision.impl.CodeDecisionImpl"/ > </decisions> <issueModel> <issues self="" key="" summary="Sample Issue" description="Simple Test Issue" issueType="" project="//@issueModel/@projects.0" affectedVersions="//@issueModel/@versions.0"/> <projects name="SampleProject"/> <versions name="1.0" description="Sample Version Description"/> </issueModel> <stakeholders identity="Michael Junker" decision="//@decisions.0 //@decisions .1"/> </decision:DecisionModel>

3 4 5 6

8 9 10

11 12 13 14 15

53

54

7. Anhang

D. ExtensionPointExecutor
Listing D-4: Die ExtensionPointExecutor-Klasse
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 package edu.kit.ipd.sdq.dm.extensionpoint.executor; import java.util.ArrayList; import java.util.List; import import import import org.eclipse.core.runtime.CoreException; org.eclipse.core.runtime.IConfigurationElement; org.eclipse.core.runtime.IExtensionRegistry; org.eclipse.core.runtime.RegistryFactory;

import edu.kit.ipd.sdq.dm.extensionpoint.definition.DecisionRelatable; /** * This class execute()-method gathers all extensions that use the provided extension point in * order to get all related artifacts to a specific decision. * * @author Michael Junker * */ public class ExtensionPointExecutor { private static final String EXTENSION_POINT_ID = "edu.kit.ipd.sdq.dm. extensionpoint"; /** * Empty constructor for creating the executor */ public ExtensionPointExecutor() { } /** * Calls every available plugin using this extension and returns all DecisionArtifacts in a list * * @return a list of all DecisionArtifacts available. May be empty but never null */ public List<DecisionRelatable> execute() { List<DecisionRelatable> relatedArtifacts = new ArrayList< DecisionRelatable>(); IExtensionRegistry registry = RegistryFactory.getRegistry(); IConfigurationElement[] config = registry.getConfigurationElementsFor( EXTENSION_POINT_ID); for (IConfigurationElement element : config) { try { final Object o = element.createExecutableExtension(" decisioninterface"); if (o instanceof DecisionRelatable) { relatedArtifacts.add((DecisionRelatable) o); } } catch (CoreException e) { e.printStackTrace(); return relatedArtifacts; } } return relatedArtifacts;

54

E. CodeDecisionRelatableImpl-Klasse
54 55 } }

55

E. CodeDecisionRelatableImpl-Klasse
Listing E-5: Die CodeDecisionRelatableImpl-Klasse
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 package edu.kit.ipd.sdq.dm.codedecision.impl; import java.util.ArrayList; import java.util.List; import import import import import import import import import import import import import import import import import import import import import import import import import import import import import import import org.eclipse.core.resources.IProject; org.eclipse.core.resources.IWorkspace; org.eclipse.core.resources.IWorkspaceRoot; org.eclipse.core.resources.ResourcesPlugin; org.eclipse.core.runtime.CoreException; org.eclipse.jdt.core.ICompilationUnit; org.eclipse.jdt.core.IJavaElement; org.eclipse.jdt.core.IJavaProject; org.eclipse.jdt.core.IPackageFragment; org.eclipse.jdt.core.IPackageFragmentRoot; org.eclipse.jdt.core.JavaCore; org.eclipse.jdt.core.JavaModelException; org.eclipse.jdt.ui.JavaUI; org.eclipse.jface.dialogs.MessageDialog; org.eclipse.swt.SWT; org.eclipse.swt.events.SelectionAdapter; org.eclipse.swt.events.SelectionEvent; org.eclipse.swt.layout.GridData; org.eclipse.swt.layout.GridLayout; org.eclipse.swt.widgets.Composite; org.eclipse.swt.widgets.Label; org.eclipse.swt.widgets.Link; org.eclipse.swt.widgets.Shell; org.eclipse.swt.widgets.Text; org.eclipse.ui.PartInitException; org.eclipse.ui.PlatformUI; org.eclipse.ui.forms.widgets.Section; edu.kit.ipd.sdq.decision.Decision; edu.kit.ipd.sdq.dm.codedecision.CodeDecision; edu.kit.ipd.sdq.dm.codedecision.SourceCodeReference; edu.kit.ipd.sdq.dm.extensionpoint.definition.DecisionRelatable;

public class CodeDecisionRelatableImpl implements DecisionRelatable { public CodeDecisionRelatableImpl() { } @Override public Composite getRelatableDecisionArtifacts(Section parent, Decision d) { CodeDecision match = null; try { match = (CodeDecision) d; } catch (ClassCastException e) { // return null since the decision is not a code decision return null; } Composite newComp = null;

55

56
55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 if (match != null) { List<Text> cdReferenceNames = new ArrayList<Text>(); List<Link> cdReferenceURLs = new ArrayList<Link>(); newComp = new Composite(parent, SWT.BORDER); newComp.setLayout(new GridLayout(2, false));

7. Anhang

Label cdTypeLabel = new Label(newComp, SWT.NONE); cdTypeLabel.setText("Type of code decision: "); cdTypeLabel.setLayoutData(new GridData(SWT.FILL, SWT.CENTER, false, false, 1, 1)); Text cdType = new Text(newComp, SWT.NONE); cdType.setText(match.getType().toString().toLowerCase()); cdType.setLayoutData(new GridData(SWT.FILL, SWT.CENTER, false, false, 1, 1)); for (final SourceCodeReference reference : match. getSourceCodeReferences()) { Text cdReferenceLabel = new Text(newComp, SWT.NONE); cdReferenceLabel.setText(reference.getDescription()); cdReferenceLabel.setLayoutData(new GridData(SWT.FILL, SWT. CENTER, false, false, 1, 1)); cdReferenceNames.add(cdReferenceLabel); final Link cdReferenceLink = new Link(newComp, SWT.NONE); cdReferenceLink.setText("<a>" + reference.getPackageURL() + "." + reference.getClassName() + "</a>"); cdReferenceLink.setLayoutData(new GridData(SWT.FILL, SWT.CENTER , false, false, 1, 1)); cdReferenceLink.addSelectionListener(new SelectionAdapter() { @Override public void widgetSelected(SelectionEvent e) { String className = reference.getClassName(); Shell parent = null; try { List<ICompilationUnit> compilationUnits = getCompilationUnitsByClassName(className, reference.getPackageURL()); if (compilationUnits.size() > 0) { JavaUI.openInEditor(compilationUnits.get(0)); } else { parent = PlatformUI.getWorkbench(). getActiveWorkbenchWindow().getShell(); MessageDialog.openInformation(parent, className , "Couldnt find " + className + " in the current workspace. If this class name is valid, the corresponding class has to be in the current workspace"); } } catch (PartInitException e1) { MessageDialog.openError(parent, "Exception!", " Editor failed to initialize. Cannot display class " + className); } catch (JavaModelException e1) { MessageDialog.openError(parent, "Exception!", " Exception occured while trying to acces class " + className); } catch (CoreException e1) { MessageDialog.openError(parent, "Exception!", "The project containing class " + className + " is

88 89 90 91 92 93

94 95 96

97 98

99 100

56

E. CodeDecisionRelatableImpl-Klasse
not in the workspace"); 101 102 103 104 105 106 107 108 109 110 111 112 113 } } }); cdReferenceURLs.add(cdReferenceLink); } } return newComp; }

57

114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129

private List<ICompilationUnit> getCompilationUnitsByClassName(String clazzName, String packageName) throws JavaModelException, CoreException { List<ICompilationUnit> compilationUnits = new ArrayList< ICompilationUnit>(); // Retrieve all the source roots IWorkspace workspace = ResourcesPlugin.getWorkspace(); IWorkspaceRoot workspaceRoot = workspace.getRoot(); IProject[] projects = workspaceRoot.getProjects(); for (IProject project : projects) { IJavaProject javaProject = (IJavaProject) project.getNature( JavaCore.NATURE_ID); if (javaProject != null) { compilationUnits.addAll(getCompilationUnitsForProject(clazzName , javaProject, packageName)); } } return compilationUnits; } private List<ICompilationUnit> getCompilationUnitsForProject(String className, IJavaProject iJavaProject, String packageName) throws JavaModelException { List<ICompilationUnit> compilationUnits = new ArrayList< ICompilationUnit>(); IPackageFragmentRoot[] roots = iJavaProject.getPackageFragmentRoots(); for (IPackageFragmentRoot root : roots) { // Retrieve all the elements within the source root. for (IJavaElement iJavaElement : root.getChildren()) { // Test if the element is a package fragment. if (iJavaElement.getElementType() == IJavaElement. PACKAGE_FRAGMENT) { IPackageFragment iPackageFragment = (IPackageFragment) iJavaElement; if (iPackageFragment.getElementName().equals(packageName)) { for (ICompilationUnit iCompilationUnit : iPackageFragment.getCompilationUnits()) { // Recreate the package and class name to a fully // qualified classname. String cn = iCompilationUnit.getElementName(). substring(0, iCompilationUnit.getElementName(). indexOf(.)); if (cn.equals(className)) { compilationUnits.add(iCompilationUnit); }

130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145

146 147 148 149

57

58
150 151 152 153 154 155 156 157 158 } } } } } return compilationUnits; } }

7. Anhang

58