Eine domänenspezifische Sprache zur Generierung von Sichten der Unternehmensarchitektur

Fakultät für Informatik Technische Universität München Bachelorarbeit in Wirtschaftsinformatik Eine domänenspezifische Sprache zur Generierung von Sichten der Unternehmensarchitektur Philip Achenbach

Fakultät für Informatik Technische Universität München Bachelorarbeit in Wirtschaftsinformatik Eine domänenspezifische Sprache zur Generierung von Sichten der Unternehmensarchitektur A domain specific language for EA view generation Bearbeiter: Philip Achenbach Aufgabensteller: Prof. Dr. rer. nat. Florian Matthes Betreuer: Dipl.-Inf. Christian M. Schweda Abgabedatum: 15. Oktober 2010

Erklärung Ich versichere, dass ich diese Bachelorarbeit selbständig verfasst und nur die angegebenen Quellen und Hilfsmittel verwendet habe. München, den 15. Oktober 2010 Philip Achenbach

Danksagung An dieser Stelle möchte ich mich bei all jenen bedanken, die mir beim Erstellen dieser Arbeit durch ihre fachliche und persönliche Unterstützung zur Seite gestanden sind. An erster Stelle möchte ich mich bei Prof. Dr. Matthes für die Ermöglichung und Förderung dieser Arbeit bedanken. Christian Schweda danke ich nicht nur für die Betreuung dieser Arbeit, sondern auch als Kollege, der mir immer ein offener Diskussionspartner war, und mir durch kritisches Hinterfragen stets neue Anregungen gegeben hat. Ebenso gilt mein Dank den Mitgliedern des Lehrstuhls für Software Engineering betrieblicher Informationssysteme (sebis), für das freundliche und angenehme Arbeitsumfeld am Lehrstuhl sowie die konstruktiven Diskussionen. Mein ganz besonderer Dank gilt jedoch meiner Familie, die mir in all den Jahren durch ihren Zuspruch, ihre Unterstützung und ihr Vertrauen in mich zur Seite stand. Danke.

Zusammenfassung Unternehmensarchitekturen sind ein essentieller Teil heutiger Organisationen. Gleichzeitig bilden sie hochkomplexe und verwobene Systeme, deren Struktur nicht in einer einzigen Gesamtbetrachtung dargestellt werden kann. Da jede Organisation ein eigenes Verständnis einer Unternehmensarchitektur entwickelt, und darauf aufbauend eine eigene Terminologie und ein Unternehmensmodell bildet, zeichnen sich noch keine gemeinsamen Gesichtspunkte in der Beschreibung einer Unternehmensarchitektur ab. Der Lehrstuhl für Software Engineering betrieblicher Informationssysteme (sebis) der Technischen Universität München untersucht Methoden, die sowohl eine maximale Flexibilität bezüglich der zu modellierenden Information und der graphischen Darstellung bieten, als auch eine einfach zu nutzende Sprache darstellen, um Gesichtspunkte der Unternehmensarchitektur zu beschreiben. Eine solche Sprache wird in der folgenden Arbeit entwickelt und implementiert. Abstract Enterprise Architectures (EA) are an essential part of today s companies. At the same time, they are highly complex and intervowen systems, whose structure cannot be summarized in one comprehensive overview. As every enterprise is likely to have its own distinct terminology and enterprise-specific model, grounded in its own understanding of EA, no common viewpoints on Enterprise Architectures have yet emerged. The chair of Software Engineering for Business Information Systems (sebis) at the Technical University of Munich is examining techniques providing maximum flexibility with respect to the modeled information and the graphical representation, while still being an easy-to-use language for describing EA viewpoints. Such a language is being developed and implemented in the following thesis. I

Inhaltsverzeichnis Abkürzungsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis Verzeichnis der Listings IV V VII VIII 1. Einleitung und Motivation 1 1.1. Ziel der Arbeit........................... 2 1.2. Aufbau der Arbeit......................... 3 2. Einbettung in den thematischen Kontext 4 2.1. Anwendungslandschaft als Managementgegenstand....... 5 2.2. Dokumentation der Unternehmensarchitektur.......... 6 2.3. Softwarekarten zur Dokumentation................ 10 2.4. Generierung von Karten...................... 15 2.4.1. Modellbeschreibung..................... 17 2.4.2. Semantisches Modell.................... 18 2.4.3. Symbolisches Modell.................... 19 2.4.4. Transformation....................... 20 3. Analyse 22 3.1. Anwendungsfälle.......................... 22 3.2. Domänenspezifische Sprache.................... 25 3.3. Konzept der VDL.......................... 30 4. Design 33 4.1. Quellen und Senken......................... 33 4.1.1. Konzept der Verbindungspunkte.............. 33 II

Inhaltsverzeichnis 4.1.2. Graphische Repräsentation der Quellen und Senken... 34 4.2. Viewpoint Building Blocks..................... 35 4.2.1. Konzept der Viewpoint Building Blocks.......... 36 4.2.2. Übersicht zentraler Viewpoint Building Blocks...... 38 4.3. Transformationsgraphen...................... 41 5. Implementierung 45 5.1. Technische Umsetzung des Frameworks.............. 45 5.1.1. Zentrale Informationsträger................ 46 5.1.2. Interfaces der Quellen und Senken............. 47 5.1.3. Basisklasse der Viewpoint Building Blocks........ 48 5.2. Implementierung eines Viewpoint Building Blocks........ 49 5.3. Definition eines Viewpoints.................... 53 5.4. Realisierung des graphischen Editors............... 56 6. Zusammenfassung und Ausblick 60 6.1. Zusammenfassung.......................... 60 6.2. Ausblick............................... 61 Literaturverzeichnis 63 A. Anhang i A.1. Darstellungen zentraler Viewpoint Building Blocks....... ii III

Abkürzungsverzeichnis ATL.............. DSL............... EA................ HTTP............ IEEE.............. ISO............... JSON............. REST............. RSS............... SVG.............. UML.............. URL.............. VBB.............. VDL.............. Atlas Transformation Language Domain-Specific Language Enterprise Architecture Hypertext Transfer Protocol Institute of Electrical and Electronics Engineers International Organization for Standardization JavaScript Object Notation Representational State Transfer Really Simple Syndication Scalable Vector Graphics Unified Modeling Language Uniform Re Locator Viewpoint Building Block Viewpoint Description Language IV

Abbildungsverzeichnis 2.1. Gliederung einer Unternehmensarchitektur............ 5 2.2. Ausschnitt aus dem konzeptuellen Modell des IEEE Std. 1471-2000, ISO/IEC 42010:2007..................... 8 2.3. Darstellung des Schichtenprinzips................. 11 2.4. Softwarekartentyp Clusterkarte.................. 12 2.5. Softwarekartentyp Kartesische Karte (Prozessunterstützungskarte)................................ 13 2.6. Softwarekartentyp Kartesische Karte (Intervallkarte)...... 13 2.7. Softwarekarte ohne Verortung (Graphlayoutkarte)........ 14 2.8. Schema der Generierung von Visualisierungen im SyCaTool... 16 2.9. Beispiel eines semantischen Modells................ 18 2.10. Beispiel eines Informationsmodells................. 18 2.11. Beispiel eines symbolischen Modells................ 19 2.12. Beispiel eines Visualisierungsmodells............... 19 3.1. Anwendungsfälle bei der Nutzung von Viewpoints........ 23 3.2. Anwendungsfälle beim Design von Viewpoints.......... 24 3.3. Transformationsansatz nach Schweda [Sc06]........... 25 3.4. Transformationsansatz nach Wiegelmann [Wi08]......... 26 3.5. Abstraktionslücke bei Transformationsansätzen......... 28 3.6. Überbrückung der Abstraktionslücke............... 28 3.7. Transformationsansatz nach Ramacher [Ra09].......... 29 3.8. Editor der Yahoo!-Pipes Webanwendung mit beispielhafter Pipe [Ya10a]................................ 31 4.1. Darstellung des Cluster-VBBs................... 36 4.2. Darstellung des CreateSymbol-VBBs............... 37 4.3. Darstellung des BinaryMatrix-VBBs............... 38 4.4. Graphische Darstellung einer Viewpoint Definition........ 41 V

Abbildungsverzeichnis 4.5. Clusterkarte als Ergebnis einer Transformation.......... 42 4.6. Beispiel eines Transformationsgraphen.............. 43 4.7. Clusterkarte als Ergebnis einer Transformation.......... 44 5.1. Zentrale Informationsobjekte.................... 46 5.2. Interface der Senke......................... 47 5.3. Interface der Quelle......................... 47 5.4. Abstrakte Basisklasse der Viewpoint Building Blocks...... 48 5.5. Klassendiagramm des FilterClass-VBBs.............. 49 5.6. Darstellung des FilterClass-VBBs................. 49 5.7. Basis-Implementierung eines Ports................. 50 5.8. Basis-Implementierung einer Senke................ 51 5.9. Implementierung einer internen Quelle.............. 52 5.10. Abstrakte Basisklasse einer Viewpoint Definition......... 53 5.11. Graphische Darstellung eines Transformationsgraphen...... 54 5.12. Darstellung des ModelEditors................... 58 VI

Tabellenverzeichnis 4.1. Graphische Repräsentation verschiedener Typen von Quellen und Senken............................. 35 VII

Verzeichnis der Listings 2.1. Beispiel einer Transformationsbeschreibung in der ATL..... 21 5.1. Implementierung des FilterClass-VBB............... 51 5.2. Implementierung eines Transformationsgraphen......... 55 VIII

1. Einleitung und Motivation Geschäftsprozesse in Unternehmen werden heutzutage insbesondere durch eine Vielzahl betrieblicher Anwendungen unterstützt, oder durch deren Einsatz erst ermöglicht. Aufgrund dieser Bedeutung betrieblicher Informationssysteme müssen diese als Managementgegenstand verstanden werden, der wesentlich zum unternehmerischen Erfolg beitragen kann. Das Management dieser Informationssysteme, mit dem Ziel einer optimalen Bereitstellung der angebotenen Dienste und Informationen, gewinnt insbesondere vor dem Hintergrund einer wachsenden Bedeutung der Res Information an Priorität. Das Management der in einem Unternehmen vorhandenen betrieblichen Informationssysteme bestimmt über die Entwicklung und Pflege dieser, sowie der Einführung und Konsolidierung betrieblicher Anwendungen. Dabei ist Rücksicht zu nehmen auf die Beziehungen zwischen den Anwendungssystemen, die sowohl logischer und physischer Natur sein können, wie auch organisatorisch bedingt. Aufgrund der inhärenten Komplexität dieser Beziehungen ist eine Dokumentation der Unternehmensarchitektur, zu der auch die betrieblichen Informationssysteme gehören, unabdingbar. Diese Dokumentation findet immer häufiger auch mit Hilfe graphischer Darstellungen statt. Ein Forschungsprojekt des Lehrstuhls für Software Engineering betrieblicher Informationssysteme (sebis) an der Technischen Universität München ist die Dokumentation von Unternehmensarchitekturen, mit einem Fokus auf Methoden zur Dokumentation und der Visualisierung in sogenannten Softwarekarten. Im Rahmen dieses Forschungsprojekts wurden in Kooperation mit renommierten industriellen Projektpartnern wie der Siemens AG und der Deutschen Bank bestehende Verfahren zur Dokumentation der Unternehmensarchitektur untersucht. Dabei ist aufgefallen, dass die Dokumentation anhand von Visualisierungen aufgrund einer geringen Werkzeugunterstützung in einem langwierigen und 1

1. Einleitung und Motivation fehleranfälligen Prozess vornehmlich von Hand durchgeführt wurde. Als Reaktion darauf wurde vom Lehrstuhl ein Verfahren zur automatischen Generierung von Softwarekarten entwickelt und als SyCaTool prototypisch umgesetzt. Dieses Verfahren basiert auf zwei eng gekoppelten objektorientierten Modellen, die zum einen die Unternehmensarchitektur beschreiben, und in dieser Form bereits von vielen Projektpartnern gepflegt werden, zum anderen eine graphische Darstellung in Form eines Modells repräsentieren. Modelltransformationen stellen die Verbindung zwischen diesen zwei Modellen her und erlauben somit eine automatische Generierung von Visualisierungen der Unternehmensarchitektur. 1.1. Ziel der Arbeit Ziel der Arbeit ist die Entwicklung einer domänenspezifischen Sprache in Form eines Frameworks, das der Beschreibung der Modelltransformation anhand eines Transformationsgraphen dient. Der Transformationsgraph soll dabei ähnlich dem Pipe and Filter -Entwurfsmuster die Konfiguration eines Blickwinkels auf die Unternehmensarchitektur erlauben. Die Sprache soll die Definition einer Transformation dabei auf einem hohen Abstraktionsniveau ermöglichen, ohne die für eine individuelle Konfiguration einer Softwarekarte benötigte Flexibilität zu verlieren. Das Framework soll dabei insbesondere zur Definition und Anpassung eines Blickwinkels durch den Endanwender geeignet sein. Darüber hinaus soll im praktischen Teil dieser Arbeit eine Implementierung des Frameworks als Komponente des Softwarekartographie-Werkzeugs SyCaTool erfolgen. Es soll möglich sein, Blickwinkel in der domänenspezifischen Sprache des Frameworks zu erstellen, und Transformationen durch das Framework durchführen zu lassen. Die Komponente soll sich dazu in die vorhandene Struktur des SyCaTools eingliedern. Des Weiteren soll eine prototypische Umsetzung eines graphischen Editors entstehen, die es einem Endanwender erlaubt, Blickwinkel auf die Unternehmensarchitektur zu definieren und zu verändern. Mit diesem Editor erstellte Blickwinkel sollen anschließend im SyCaTool zur Generierung einer Softwarekarte verwendet werden können. 2

1. Einleitung und Motivation 1.2. Aufbau der Arbeit Der Aufbau der Arbeit ist dem klassischen Softwareentwicklungsprozess mit den Phasen Analyse, Design und Implementierung nachempfunden. Dem Voraus geht eine Einleitung in das thematische Umfeld, den Abschluss bildet eine Zusammenfassung der erhaltenen Ergebnisse. Kapitel 2 stellt eine Einleitung in den thematischen Kontext dar. Das Kapitel startet mit einer Einführung in die Begriffswelt der Problemdomäne. Anschließend wird die Bedeutung der Anwendungslandschaft als Managementgegenstand erörtert, worauf eine Einführung in den Kontext der Dokumentation der Unternehmensarchitektur folgt. Im Anschluss daran werden Softwarekarten als eine konkrete Möglichkeit der Dokumentation vorgestellt, sowie das Verfahren zur Generierung solcher Karten beschrieben. In Kapitel 3 folgt darauf die Analyse der Anforderungen. Dabei wird insbesondere auf Anwendungsfälle eingegangen, sowie der Begriff der domänenspezifischen Sprache in den Kontext der Problemdomäne gestellt. Im Anschluss daran folgt eine Vorstellung des dem Transformationsframeworks zugrundeliegenden Konzepts. Kapitel 4 beschreibt den Entwurf der domänenspezifischen Sprache. Dabei wird zuerst das Ein- und Ausgabekonzept des Transformationsgraphen besprochen, worauf eine Beschreibung der den Graphen bildenden Transformationsknoten folgt. Abgeschlossen wird das Kapitel mit der Erläuterung der Funktionsweise eines vollständigen Transformationsgraphens. In Kapitel 5 wird die Implementierung des entstandenen Frameworks vorgestellt. Dazu wird zuerst auf die technische Umsetzung der zentralen Komponenten eingegangen, worauf die Darstellung der Implementierung eines Transformationsbausteins folgt. Die Erläuterung der Definition eines Blickwinkels schließt daran an und führt ein in die Beschreibung der Realisierung des graphischen Editors. Kapitel 6 dient als Zusammenfassung der Arbeit und schließt mit einem Ausblick auf die mögliche weitere Entwicklung des Frameworks. 3

2. Einbettung in den thematischen Kontext Betriebliche Informationssysteme sind aus heutigen Unternehmen nicht mehr wegzudenken. Sie finden in der Administration ebenso Anwendung wie in der Durchführung operativer Prozesse das Rechnungswesen kann man sich heutzutage ohne Unterstützung durch betriebliche Informationssysteme ebenso wenig vorstellen wie die Lagerhaltung oder das Personalwesen. Als soziotechnische Systeme umfassen Informationssysteme menschliche und maschinelle Komponenten, die zum Ziel der optimalen Bereitstellung von Information und Kommunikation nach wirtschaftlichen Kriterien eingesetzt werden [SK04]. Die maschinellen Komponenten lassen sich wiederum aufteilen in Infrastrukturkomponenten, wie beispielsweise Hardware, Betriebssysteme oder Middleware, und betriebliche Anwendungssysteme. Letztere sind für die fachliche Datenverarbeitung und die Unterstützung der Geschäftsprozesse zuständig und sind daher direkt in die Wertschöpfungskette des Unternehmens eingebunden. Zusätzlich sind derartige Anwendungssysteme durch Aufbau, Wartung und Betrieb oft mit hohen Kosten verbunden, so dass diese auch als Investitionsgüter betrachtet werden müssen [Ra09]. Geht man von einzelnen Anwendungssystemen über zur Betrachtung der Gesamtheit der betrieblichen Anwendungen in einem Unternehmen, und ihrer Verbindungen untereinander, spricht man von einer Anwendungslandschaft [Sc06]. Diese bildet langlebige und hochkomplexe Strukturen, die in mittleren bis großen Unternehmen hunderte bis einige tausend Anwendungssysteme und über zehntausend Beziehungen umfassen können. Aufgrund der großen Bedeutung der Anwendungslandschaft für Unternehmen muss diese auch als Managementgegenstand verstanden werden, den es zu steuern und zu kontrollieren gilt. 4

2. Einbettung in den thematischen Kontext Abbildung 2.1.: Gliederung einer Unternehmensarchitektur 2.1. Anwendungslandschaft als Managementgegenstand Zusammen mit der IT-Infrastruktur und organisatorischen, d. h. menschlichen Komponenten bildet die Anwendungslandschaft die Informationssysteminfrastruktur eines Unternehmens. Der Lehrstuhl für Software Engineering betrieblicher Informationssysteme hat die in Abbildung 2.1 dargestellte Aufteilung als mögliche Gliederung der Unternehmensarchitektur (engl. Enterprise Architecture, EA)) vorgestellt [se05], ein Teil derer die Informationssysteminfrastruktur und somit die Anwendungslandschaft ist. Diese beinhaltet im Zentrum die Anwendungssystem-Schicht (Application & Information), die die Anwendungen und Informationsbestände beschreibt, die über Schnittstellen und Abstraktionen (Infrastruktur-Service-Schicht) auf die Infrastruktur-Schicht abgebildet werden. In die entgegengesetzte Richtung unterstützen die Anwendungen und Informationen die Geschäfts-Sicht, bestehend aus Aktivitäten, Prozessen und Organisationen. Auch diese Unterstützung erfolgt meist über eine Service-Schicht, die wiederum der Entkopplung dient. Daneben existieren Querschnittsaspekte, die Einfluss auf mehrere Schichten haben können: Die Visionen und Ziele, die für die Unternehmensarchitektur vorgegeben werden, werden durch Strategien und Projekte gestützt, die die Ar- 5

2. Einbettung in den thematischen Kontext chitektur verändern. Dabei können Richtlinien und Muster vorgegeben werden, die sich auf die Anwendungslandschaft auswirken. Kennzahlen und Metriken helfen dabei, den Zustand der Architektur zu verfolgen [Ma08a]. Dies macht deutlich, dass eine Anwendungslandschaft nicht als Ergebnis eines einfachen Managementprozesses angesehen werden kann, sondern vielmehr als ein sich dynamisch entwickelndes Artefakt, auf welches durch viele und nur zum Teil koordinierte Mikromanagementprozesse eingewirkt wurde. Sich ändernde Geschäftserfordernisse oder gesetzliche Richtlinien münden in Auswirkungen auf die Anwendungen all dies lässt die Landschaft wachsen [Sc06, Ra09]. Zudem oder gerade aufgrund dieser inhärenten Komplexität und Dynamik tragen Anwendungslandschaften wesentlich zum Kostenfaktor IT bei, den es als Kostenfaktor zu managen gilt. Treibende Kräfte sind dabei, neben dem Kostendruck, einerseits fachliche Erfordernisse im Sinne einer Ausrichtung der Informationstechnologie am Geschäft, andererseits technologische Anforderungen und Entwicklungen, wie bspw. die Umsetzung von Webservices [Sc06]. Typische Managementaufgaben sind dabei gemäß [se05] die Konsolidierung von Komponenten der Infrastruktur oder der Geschäftsprozessunterstützung. Dabei wird z. B. die Anzahl an verschiedenartigen, im Einsatz befindlichen Betriebssystemen reduziert, oder auch Anwendungssysteme zusammengefasst, die an verschiedenen Standorten denselben Geschäftsprozess unterstützen. Ein weiteres Beispiel wäre der Wechsel eines eingesetzten Datenbankmanagementsystems. Dies setzt jedoch voraus, dass Informationen über die Anwendungslandschaft vorhanden sind, um die vom Datenbanksystem abhängigen Informationssysteme und deren Beitrag zur Aufrechterhaltung der Geschäftsprozesse in Erfahrung bringen zu können, damit beim Wechsel darauf entsprechend Rücksicht genommen werden kann [Sc06]. Diese Aufgabe der Information über Anwendungslandschaften nimmt die Dokumentation der Unternehmensarchitektur ein. 2.2. Dokumentation der Unternehmensarchitektur Nebel liegt über der Anwendungslandschaft mit diesen Worten beschreibt Matthes in [Ma08a] die aktuelle Situation in großen Unternehmen verschieden- 6

2. Einbettung in den thematischen Kontext ster Branchen. Während IT-Projekte immer wieder mit einer Analyse bestehender Systeme und ihrer Schnittstellen beginnen, und immer wiederkehrende Befragungen stattfinden, um Informationen zur Struktur und zu Eigenschaften der Unternehmensarchitektur zu sammeln, beklagen Geschäft und Management die geringe Transparenz der Enterprise Architecture bezogen auf Kosten und Nutzen [Ma08a]. Als Werkzeuge für die Dokumentation von Systemen werden verschiedene Modelle entsprechend verschiedener Blickwinkel zum Einsatz gebracht. Eine konzeptionelle Grundlage für die Beschreibung der Architektur software-intensiver Systeme stellt der IEEE-Standard 1471-2000, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems [IE00] dar. Als softwareintensives System versteht man dabei Systeme, in denen Software essentiellen Einfluss auf Design, Konstruktion und Einsatz hat, und die auf Software angewiesen sind, um die ihnen zugedachte Aufgabe zu erfüllen [IE00]. Der Standard definiert zu diesem Zweck einen Begriffsapparat für die Dokumentation von Architekturen und zeigt die Beziehungen zwischen den Begriffen auf. Das zugrunde liegende konzeptuelle Modell illustriert Abbildung 2.2. Die Eignung zur Dokumentation von Anwendungslandschaften als Teil der Unternehmensarchitektur wurde in [LMW05a] von Lankes et al. dargestellt. Die essentiellen Begriffe des Standards sollen im Folgenden dargestellt werden. Im Jahr 2007 wurde der Standard auch von der International Organization for Standardization (ISO) übernommen und als ISO/IEC 42010:2007, Systems and software engineering Recommended practice for architectural description of software-intensive systems, veröffentlicht [IS07, MEH09]. Referenzen auf den IEEE-Standard gelten somit ebenfalls für den entsprechenden ISO-Standard, dessen Text identisch ist [MEH09]. System repräsentiert das zu beschreibende System. Dies kann sowohl die Unternehmensarchitektur selbst (als system of systems [IE00]) als auch die in ihr enthaltenen Teilsysteme sein. Mission entspricht dem Zweck, dem das System dienen soll. Der grundsätzliche Zweck der Anwendungslandschaft besteht in der Unterstützung der Unternehmensziele und -strategien ebenso wie der Geschäftsprozesse [Sc06]. 7

2. Einbettung in den thematischen Kontext Abbildung 2.2.: Ausschnitt aus dem konzeptuellen Modell des IEEE Std. 1471-2000, ISO/IEC 42010:2007 8

2. Einbettung in den thematischen Kontext Environment beschreibt die Umwelt oder den Kontext des Systems und übt Einfluss auf das System aus. Dies können andere Systeme ebenso sein wie technische Rahmenbedingungen oder Organisationsstrukturen. Stakeholder sind Personen, Gruppen, Rollen und Organisationseinheiten, die einen Bezug zum beschriebenen System haben. Concern beschreibt ein Interesse am beschriebenen System, wie bspw. gewünschte Eigenschaften im Hinblick auf Entwicklung, Betrieb, Wartung oder Kosten. Architecture beschreibt das Zusammenspiel der Komponenten des Systems, d. h. den grundlegenden Aufbau der Unternehmensarchitektur. Architectural Description stellt die Beschreibung der Architektur dar. Sie besteht aus verschiedenen Views. View stellt als Teil der Architekturbeschreibung eine Sicht auf die Architektur dar, bestehend aus einer oder mehreren konkreten Aufbereitungen der Dokumentation als Models. Viewpoint stellt einen speziellen Blickwinkel auf die Architekturbeschreibung dar und enthält Richtlinen zur Aufbereitung der Daten in einem View, sowie ihrer Analyse. Eine Architekturbeschreibung kann mehrere Blickwinkel auf die Architektur bieten, die durch Views konkretisiert werden. Model bezeichnet eine konkrete Aufbereitung der Daten einer Architekturbeschreibung, bspw. als Grafik, Tabelle oder Text. Zur Architektur eines Systems existiert gemäß dem Standard genau eine Architekturbeschreibung. Dabei wird davon ausgegangen, dass jedes System eine Architektur hat sei diese nun dokumentiert oder nicht [Re99]. Das zentrale Element in dem Standard stellt dabei die Architectural Description dar. Diese Beschreibung eines Systems kann man sich dabei als eine Sammlung von Informationen über die Unternehmensarchitektur vorstellen die Art und der Umfang der Informationen wird dabei durch die Interessen der Stakeholder bestimmt. Durch die Anwendung von Viewpoints lassen sich spezifische Aspekte der Architektur hervorheben [Ra09]. Die konkrete Darstellung von Informationen gemäß den Richtlinien eines Viewpoints wird gemäß dem Standard als View bezeichnet. Das Verhältnis von Viewpoint und View lässt sich 9

2. Einbettung in den thematischen Kontext dabei mit dem Verhältnis einer Klasse zu einem Objekt in der objektorientierten Programmierung vergleichen: Ein Viewpoint kann als Verfahren für die Aufbereitung von Informationen verstanden werden, ein View als dessen konkrete Instanziierung im Kontext einer speziellen Architekturbeschreibung [Sc06]. Um die universelle Anwendbarkeit des Standards zu gewährleisten geht dieser bewusst nicht über die Definition und Abgrenzung von Begrifflichkeiten hinaus er stellt somit nur einen allgemeinen Rahmen zur Dokumentation und Kommunikation von software-intensiven Systemen bereit. Die Softwarekartographie kann als eine konkrete Anwendung dieses Standards verstanden werden. Der folgende Abschnitt soll eine Einführung in diese Anwendung geben. 2.3. Softwarekarten zur Dokumentation Die Softwarekartographie versteht sich analog zur Kartographie als Wissenschaft und Technik zur Visualisierung von Informationen mit einem Bezug zur Anwendungslandschaft [Ma08a, HGM02] und dient der Gestaltung, Beschreibung und Bewertung von komplexen Unternehmensarchitekturen [MW04]. Da die Softwarekartographie eine ganzheitliche Betrachtung der Unternehmensarchitektur ermöglichen soll, haben Lankes et al. [LMW05b] die drei Betrachtungsebenen Wie?, Was? und Warum? definiert. Während die oberste Ebene, das Warum?, den unternehmerischen Zielen und Strategien Rechnung trägt, dient das Was? der Abbildung von Geschäftsprozessen und - objekten. Die unterste Ebene, das Wie?, schließlich zeigt die Unterstützung der Prozesse und Objekte durch betriebliche Informationssysteme und deren Beziehungen untereinander [LMW05b]. Der Fokus der Forschungsaktivitäten um die Softwarekartographie liegt jedoch bei den Softwarekarten. Diese sind definiert als graphische Repräsentation der Anwendungslandschaft oder Ausschnitte selbiger [MW04]. Die Abbildungen 2.4, 2.5 und 2.6 zeigen Beispiele für Softwarekarten. Wie auch bei der konventionellen Kartographie, bedient sich die Softwarekartographie des 10

2. Einbettung in den thematischen Kontext Abbildung 2.3.: Darstellung des Schichtenprinzips Schichtenprinzips (vgl. Abbildung 2.3). Dies bedeutet, dass thematisch zusammengehörige visuelle Elemente zu einer Schicht gruppiert werden. Jede Schicht bezieht sich dabei auf eine Referenzschicht, die sie mit Informationen anreichert. Zur selektiven Informationswahrnehmung können die Schichten einzeln ein- und ausgeblendet werden. Dem Kartengrund als unterster Schicht kommt dabei eine besondere Bedeutung zu: Er dient der Verortung der Elemente auf der Karte. Während auf einer konventionellen topographischen Karte, beispielsweise einer Landkarte, alle Elemente gemäß ihrer geographischen Position, d. h. ihrer Position nach Längen- und Breitengrad, angeordnet werden, fehlt dieser Bezug in der Softwarekartographie. Gerade diese räumliche Stabilität erlaubt es Menschen jedoch, bekannte Elemente auf verschiedenen Kartendarstellungen zu lokalisieren [Ma08a]. Eine wichtige Frage der Softwarekartographie ist deshalb, welche Bezugspunkte in der Unternehmensarchitektur existieren, und wie diese sich für eine stabile Verortung auf der Karte nutzen lassen. Lankes et al. haben in [LMW05b] die folgenden Kartentypen identifiziert: Clusterkarte Der Kartengrund einer Clusterkarte wird durch logische Domänen, die in dem Unternehmen existieren, gebildet. Diese Domänen können beispielsweise Funktionsbereiche, Organisationseinheiten oder Standorte sein. Durch Verschachtelung der Elemente können Zugehörigkeitsbeziehungen ausgedrückt werden [Ra09]. Mit einer Clusterkarte wird nicht spezifiziert, wie die Domänen platziert werden. Hier ist die Wahl von möglichst stabilen fach- 11

2. Einbettung in den thematischen Kontext Subsidiary Munich POS System (Germany/Munich) Monetary Transactions System (Germany) (300) Subsidiary Hamburg (1600) POS System (Germany/ Hamburg) (1620) Business Traveling System (1000) Worktime Management (Germany/Munich) (1800) Price Tag Printing System (Germany/ Munich) (1700) Customer Complaint System (1900) Price Tag Printing System (Germany/ Hamburg) (1720) Worktime Management (Germany/ Hamburg) (1820) Germany Warehouse Inventory Control System (200) Product Shipment System (Germany) (400) Data Warehouse (800) Fleet Management System (900) Online Shop (100) Human Res System (700) Financial Planning System (1400) Costing System (600) Headquarter Monetary Transactions System (Germany) (300) Document Management System (1100) Campaign Management System (1500) MIS (1300) Accounting System (500) Supplier Relationship Management System (1200) Customer Satisfaction Analysis System (2000) Customer Relationship Management System (2100) United Kingdom Subsidiary London Monetary Transactions System (Great Britain) (350) POS System (Great Britain) (1650) Price Tag Printing System (Great Britain) (1750) Worktime Management (Great Britain) (1850) Legend Map Symbols A B (1) C Organizational Unit Business Application Country Visualization Rules A B (1) C (2) Organizational Unit A hosting Business Applications B(1) and C(2) A B Organizational Unit B located at Country A B (1) C (2) Business Application C(1) reads or writes to B(2) Abbildung 2.4.: Softwarekartentyp Clusterkarte lichen Domänen ausschlaggebend [Ma08a]. Abbildung 2.4 zeigt eine Clusterkarte. Kartesische Karte Eine kartesische Karte verwendet die möglichen Ausprägungen zweier gewählter Merkmale zur Darstellung eines zweidimensionalen Raumes anhand einer x- und einer y-achse. Elemente werden auf Karten diesen Typs in der Schnittfläche zweier Intervalle verortet, die aus den Achsen hervorgehen. Die Prozessunterstützungskarte und die Intervallkarte sind zwei Spezialisierungen der kartesischen Karte. Bei der Prozessunterstützungskarte visualisiert die x-achse einzelne Prozessschritte entlang der Wertschöpfungskette des Unternehmens. Insbesondere lassen sich so Potentiale für vertikale und horizontale Integration in gewachsenen Unternehmensarchitekturen identifizieren [Ma08a]. Die Zeit wird bei einer Intervallkarte als intervallskaliertes Merkmal für die x-achse gewählt, sodass sich diese Karte insbesondere als Roadmap eignet [Ma08a]. Die Abbildungen 2.5 und 2.6 zeigen eine Prozessunterstützungskarte und eine Intervallkarte. 12

2. Einbettung in den thematischen Kontext Current Landscape SoCaStore Creation Date: 2006-12-31 Contact: EA-Group Acquisition Warehousing Distribution Headquarter Customer Relationship Management System (2100) Online Shop (100) Subsidiary Munich Subsidiary Hamburg Inventory Control System (200) Monetary Transactions System (Germany) (300) Price Tag Printing System (Germany/ Munich) (1700) Price Tag Printing System (Germany/ Hamburg) (1720) Inventory Control System (200) Campaign Management System (1500) POS System (Germany/Munich) (1600) POS System (Germany/Hamburg) (1620) Customer Complaint System (1900) Monetary Transactions System (Germany) (300) Subsidiary London Monetary Transaction System (Great Britain) (350) Price Tag Printing System (Great Britain) (1750) POS System (Great Britain) (1650) Monetary Transactions System (Great Britain) (350) Warehouse Monetary Transaction System (Germany) (300) Product Shipment System (Germany) (400) Legend Map Symbols & Visual Variables Visualization Rules A Business process A P1 is a predecessor of P2 A (1) supports P1 at O1 A (1) supports P1 and P2 at O1 A (1) supports P1 at O1 and O2 A (1) supports P1 and P2 at O1 and O2 A Organizational unit A P1 P2 P1 P2 P1 P2 P1 P2 P1 P2 A (1) Business application system A with id 1 and status unmodified O1 A (1) O1 A (1) O1 A (1) O1 A (1) O2 O2 O2 O2 x-sequence full y specific intersection full x specific intersection full y specific intersection full x specific intersection full y specific intersection full x specific intersection full y specific intersection full x specific intersection Abbildung 2.5.: Softwarekartentyp Kartesische Karte (Prozessunterstützungskarte) - Billing - Accounting v 1.5 v 2.0 v 2.5 Business Traveling System v 1.0 v 1.5 2008 2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec v 1.5 v 2.0 2.5 v1.0 v1.5 - Management Information System v 1.0 v 2.0 v1.0 v2.0 v2.5 Support v 3.0 Legend Map Symbols x Business Application v x.y Version x.y A Domain A Status of Application Versions: planned in development in production in retirement Visualization Rules A B v x.y Domain A contains Business Application B (Version v x.y) Abbildung 2.6.: Softwarekartentyp Kartesische Karte (Intervallkarte) 13

2. Einbettung in den thematischen Kontext Interconnections of O-Shop Creation Date: 2006-12-31 Contact: EA-Group CRM InvCon DMS MoTr-D O-Shop ProShip AC Cost DataWare Legend Map Symbols & Visual Variables Visualization Rules A Business application system A A B A reads from B A B A writes to B A B Interconnection between A and B A B A reads from and writes to B attachment attachment Abbildung 2.7.: Softwarekarte ohne Verortung (Graphlayoutkarte) 14

2. Einbettung in den thematischen Kontext Ohne Verortung Bei diesem Kartentyp besitzt die Position der Elemente keine Bedeutung. Die Anordnung geschieht hierbei manuell nach ästhetischen Gesichtspunkten, oder im Falle eines zu visualisierenden Graphen nach Graphlayout-Algorithmen. Dieser Kartentyp rückt damit in die Nähe von graphischen Darstellungen, die nicht auf Verortung basieren, wie bspw. UML- und E/R-Diagramme oder auch Petrinetze [LMW05b, Ma08a]. Abbildung 2.7 zeigt ein Beispiel einer Graphlayout-Karte. 2.4. Generierung von Karten Trotz des bereits dargestellten Umfangs typischer Anwendungslandschaften bei den Unternehmen, von einigen hundert bis mehreren tausend betrieblichen Anwendungssystemen, und den beschriebenen Anforderungen an die Softwarekarten, werden diese in der industriellen Praxis noch immer häufig in einem fehleranfälligen und langwierigem Prozess manuell erstellt. Zwar werden die Informationen der Architekturbeschreibung inzwischen zum Teil werkzeuggestützt als Informationsobjekte im Rahmen eines Modells der Unternehmensarchitektur gepflegt, eine durchgängige Werkzeugunterstützung konnte jedoch keines der vom Lehrstuhl für Software Engineering betrieblicher Informationssysteme in [se05] untersuchten EAM-Werkzeuge bieten. Die Werkzeugunterstützung entsprach dabei nicht selten dem Angebot einer leeren Zeichenfläche, auf der vordefinierte Symbole manuell positioniert werden mussten. Einige Werkzeuge boten darüber hinaus eine Auswahl an Standard-Layoutalgorithmen, die die Elemente nach rein ästhetischen Kriterien positionierten [se05, Sc06, Ra09]. Drawing is no management! dieser Kommentar eines Industriepartners [Ri05] verdeutlicht die Problematik der bestehenden Toolunterstützung: Die Entkopplung der Architekturbeschreibung und der Visualisierung im Rahmen einer Softwarekarte führt nicht nur dazu, dass die Konsistenz der Karte durch den fehleranfälligen manuellen Generierungsprozess nicht sichergestellt werden kann, sondern lässt darüber hinaus noch eine definierte Semantik missen. All dies führt zu fehlerhaften und veralteten Karten, die aufgrund unklarer Semantik nicht korrekt interpretiert und analysiert werden können [Bu07b]. 15

Headquarter Subsidiary Munich Subsidiary Hamburg Subsidiary London Warehouse Purchasing Goods receipt Inventory Control System (200) Acquisition Invoice verification Accounts payable management Monetary Transactions System (300) Warehousing Price Tag Printing System Inventory Control System (200) Campaign Management System (1500) Product Shipment System (Germany) (400) Distribution Customer Relationship Management System (2100) POS System Online Shop (100) Customer Complaint System (1900) Monetary Transactions System (300) Online Shop (100) Monetary Transactions System (Germany) (300) Accounting System (500) Costing System (600) Headquarter Subsidiary Subsidiary Hamburg Warehouse Subsidiary London Munich Human Res System (700) Business Traveling System (1000) MIS (1300) Financial Planning System (1400) POS System (Germany/ Munich) (1600) Worktime Management (Germany/ Munich) (1800) Price Tag Printing System (Germany/ Munich) (1700) Product Shipment System (Germany) (400) Fleet Management System (900) Document Management System (1100) Campaign Management System (1500) POS System (Germany/ Hamburg) (1620) Price Tag Printing System (Germany/ Hamburg) (1720) Worktime Management (Germany/ Hamburg) (1820) Customer Relationship Management System (2100) Inventory Control System (200) Data Warehouse (800) Supplier Relationship Management System (1200) Monetary Transactions System (Great Britain) (350) POS System (Great Britain) (1650) Price Tag Printing System (Great Britain) (1750) Worktime Management (Great Britain) (1850) Customer Complaint System (1900) Customer Satisfaction Analysis System (2000) 2. Einbettung in den thematischen Kontext Semantic Model Transformation Symbolic Model Information Model Visualization Model Transformation Model ABC 63% 32% 5% Meta Model z.b. Meta Object Facility (MOF) 2.0 Abbildung 2.8.: Schema der Generierung von Visualisierungen im SyCaTool Durch Lankes et al. ist in [LMW05b] ein Verfahren aufgezeigt worden, welches eine werkzeuggestützte, automatische Generierung von Softwarekarten aus semantischen Modellen einer Unternehmensarchitektur ermöglicht. Dieses Verfahren wurde durch Schweda im Rahmen von [Sc06] als SyCaTool prototypisch umgesetzt und von Wiegelmann [Wi08] und Ramacher [Ra09] erweitert. Dem Tool liegen als zentrale Bestandteile objektorientierte Modelle sowohl als Dokumentation der Unternehmensarchitektur zugrunde, als auch als zur Repräsentation einer Softwarekarte. Wie Buckl in [Bu05] darstellt entspricht dies dem Stand der Technik. Insbesondere im Bereich der Dokumentation der Unternehmensarchitektur werden objektorientierte Modelle bevorzugt. Die konsistente Verbindung der Informationen über die Architektur und der Visualisierungen wird durch Modelltransformationen bewerkstelligt. Abbildung 2.8 illustriert dieses zugrunde liegende Konzept. Die einzelnen Teile werden im Folgenden näher erörtert. 16

2. Einbettung in den thematischen Kontext 2.4.1. Modellbeschreibung Das beschriebene Verfahren verfolgt einen metamodellbasierten Ansatz zur Generierung von Softwarekarten. Wesentlich ist daher das Konzept des Modells, welches eine vereinfachende Abbildung eines natürlichen oder künstlichen Originals darstellt, die zu einem bestimmten Zweck stellvertretend für das zugrunde liegende Original verwendet wird. Dabei werden durch Verkürzung nur diejenigen Eigenschaften des Originals abgebildet, die für die spätere Nutzung relevant erscheinen [St73]. Dabei ist zu beachten, dass das Modell in einer wohldefinierten Modellierungssprache ausgezeichnet ist. Diese ist häufig, insbesondere beim Ansatz der objektorientierten Modellierung, wiederum ein Modell, das sogenannte Metamodell. Dieses wird als explizite Spezifikation einer Abstraktion definiert und beschreibt die Konzepte, die einem Modellierer bei der Beschreibung eines Originals anhand eines Modells zur Verfügung stehen. Der Modellierer instanziiert demnach die im Metamodell definierten Konzepte. Ein aus dieser Instanziierung hervorgehendes Modell wird als konform zum Metamodell bezeichnet [BG01]. Ein Metamodell selbst kann wiederum aus definierten Konzepten gebildet werden, wobei die Sammlung dieser Konzepte als Metametamodell bezeichnet wird. Modelle dieser Abstraktionsebene sind in der Lage, sich via Selbstreferenzierung, d. h. unter Verwendung der von ihnen selbst definerten Semantik, zu beschreiben. Die Metametamodell-Ebene braucht somit nicht weiter abstrahiert werden [Ec09]. Ein bekanntes Beispiel für ein solches Metametamodell ist die von der Object Management Group (OMG) entwickelte Meta Object Facitity (MOF). Ebenfalls äußerst prominent ist das Eclipse Modeling Framework (EMF), welches auf einer Teilmenge des MOF, dem Essential MOF (EMOF) aufbaut. Letzteres bildet im SyCaTool die Basis für die dem semantischen Modell und dem symbolischen Modell zugrunde liegenden Metamodelle und die darauf aufbauende Modelltransformation. 17

2. Einbettung in den thematischen Kontext Abbildung 2.9.: Beispiel eines semantischen Modells Abbildung 2.10.: Beispiel eines Informationsmodells 2.4.2. Semantisches Modell Das semantische Modell in Abbildung 2.8 auf der linken Seite verzeichnet stellt die Beschreibung der Unternehmensarchitektur dar. Es basiert auf dem Informationsmodell, welches die Kernkonzepte, wie bspw. Standorte, Prozesse, Organisationseinheiten und Anwendungen, einführt. Das Informationsmodell ist demnach das Metamodell des semantischen Modells. Die Instanzdaten im semantischen Modell werden auch als Informationsobjekte bezeichnet. Verschiedener Ansätze aus der Wissenschaft und auch der Praxis zum Trotz, konnte bisher noch kein Konsens bezüglich eines vollständigen Informationsmodells erreicht werden [Ma08a]. Die in der Praxis eingesetzten Informationsmodelle unterscheiden sich gravierend, sodass sie als unvereinbar angesehen werden müssen. Darüber hinaus betonen Forscher [Bu07c] wie Praktiker auch immer wieder die Notwendigkeit, dass jedes Unternehmen ein eigenes, auf seine individuellen Bedürfe zugeschnittenes Informationsmodell entwickelt [Ma08a]. Das Verfahren zur automatischen Generierung von Softwarekarten muss dem- 18

2. Einbettung in den thematischen Kontext Abbildung 2.11.: Beispiel eines symbolischen Modells Abbildung 2.12.: Beispiel eines Visualisierungsmodells nach möglichst generisch ausgelegt werden, damit es in der Lage ist, für beliebige Modelle einer Unternehmensarchitektur Visualisierungen zu erzeugen. Abbildung 2.9 zeigt ein vereinfachtes Beispiel eines semantischen Modells. Man sieht darin, welche betrieblichen Anwendungssysteme an welchem Standort betrieben werden. Abbildung 2.10 zeigt das dazugehörige Informationsmodell, in welchem die Konzepte Business Application und Location eingeführt werden, die über die Beziehung hosted at in Verbindung stehen. 2.4.3. Symbolisches Modell Die rechte Seite des in Abbildung 2.8 dargestellten Schemas zeigt die Modelle, die der Beschreibung der Visualisierung dienen. Das Visualisierungsmodell dient hier wiederum als Metamodell des symbolischen Modells und definiert einerseits sogenannte Gestaltungsmittel (engl. map symbols), wie beispiels- 19

2. Einbettung in den thematischen Kontext weise Rechtecke, Kreise oder Linien, andererseits Gestaltungsregeln (engl. visualization rules) z. B. Verschachtelung, die keine direkt sichtbaren Konzepte darstellen, sondern mehr als Regeln zu verstehen sind, die die Positionierung, Größe oder sonstige Erscheinung der Gestaltungsmittel beeinflussen [Bu07b]. Das Konzept der Verschachtelung (engl. nesting) beispielsweise legt fest, dass das über die outer-relation referenzierte Symbol alle über die inner-relation referenzierte Symbole enthalten muss. Abbildung 2.11 verdeutlicht dies anhand einer beispielhaften Instanziierung eines symbolischen Modells: Betriebliche Anwendungssysteme werden darin innerhalb eines Standortes geschachtelt. Abbildung 2.12 stellt den dazugehörigen vereinfachten Ausschnitt aus dem Visualisierungsmodell dar. Das vollständige Visualisierungsmodell wurde von Ernst et al. in [Er06] vorgestellt. 2.4.4. Transformation Eine automatische Generierung von Visualisierungen der Dokumentation einer Unternehmensarchitektur lässt sich auf Basis einer Verbindung zwischen den zugrunde liegenden Modellen erreichen. Diese Verknüpfung des semantischen und des symbolischen Modells wird durch eine Transformation gebildet, welche die Informationsobjekte des semantischen Modells in Visualisierungsobjekte des symbolischen Modells übersetzt. Die Transformation entspricht dabei einem Viewpoint im Sinne des IEEE-Standards 1471-2000, welcher einen Blickwinkel auf die Unternehmensarchitektur beschreibt (vgl. Abschnitt 2.2). Im Rahmen des SyCaTools wurden verschiedene Modell-zu-Modell Transformationssprachen erfolgreich verwendet: Schweda hat in [Sc06] in einer ersten Version damit begonnen, die Viewpoints in der Sprache Java zu programmieren. Wiegelmann konnte darauf aufbauend in [Wi08] zeigen, dass die Atlas Transformation Language (ATL), eine deklarative Modelltransformationssprache, ebenfalls geeignet ist. Das Abstraktionsniveau in der Beschreibung von Viewpoints konnte zwar somit weiter gehoben werden, jedoch machte der deklarative Ansatz der Sprache die Beschreibungen der Viewpoints schnell äußerst komplex. Listing 2.1 zeigt ein Beispiel einer Transformation in der ATL. Es beschreibt das Verschachteln von betrieblichen Anwendungssystemen in Organisationseinheiten. 20

2. Einbettung in den thematischen Kontext Listing 2.1: Beispiel einer Transformationsbeschreibung in der ATL 1 rule OrgUnit2Rectangle { 2 from 3 infoobject : Semantic.OrganizationalUnit 4 to 5 symbol : Symbolic.Rectangle ( 6 text = infoobject.name, 7 backgroundcolor = #CCCCCC 8 ) 9 } 10 11 rule BusinessApp2Rectangle { 12 from 13 infoobject : Semantic.BusinessApplication 14 to 15 symbol : Symbolic.Rectangle ( 16 text = infoobject.name + "(" + infoobject.id + ")" 17 ), 18 rule : Symbolic.Nesting ( 19 inner = symbol, 20 outer = transforming(infoobject.hostedat) 21 ) 22 } Ramacher konnte in [Ra09] weiter von der technischen Umsetzung der Transformation abstrahieren, indem er eine spezielle Viewpoint Definition Language (VDL) entworfen hat. Zentrale Idee dieser Sprache ist die Konfiguration eines Viewpoints aus Transformationsbausteinen, welche in einer Baumstruktur zusammengefügt werden. Diese Sprache konnte durch Anwendung von introspektiver modellgetriebener Entwicklung (engl. Introspective Model-Driven Development) die klare Semantik der Java-Programmiersprache mit den Vorzügen einer deklarativen domänenspezifischen Sprache kombinieren. Davon ausgehend soll im Folgenden eine alternative Realisierung der VDL entstehen, mit deren Hilfe Viewpoints über eine netzartige Struktur mit Knoten aus elementaren Transformationsbausteinen und Kanten aus spezifischen Eingabe-/Ausgabe-Operationen konfiguriert werden können, wie sie etwa in Yahoo!-Pipes [Ya10c] zur Transformation und Filterung von RSS-Feeds eingesetzt werden. 21

3. Analyse Ausgehend von dem in Kapitel 2 aufgezeigten Kontext soll in diesem Kapitel ein erster Schritt in Richtung Realisierung einer alternativen domänenspezifischen Sprache zur Beschreibung von Viewpoints unternommen werden. Dazu werden im Folgenden die Anforderungen für eine derartige Sprache erhoben. Es sollen zuerst relevante Aspekte der Außensicht ( Black-Box-Sicht ) auf ein Werkzeug für die Softwarekartographie dargestellt werden, indem wesentliche Nutzerrollen identifiziert und deren Anwendungsfälle aufgezeigt werden, um dann zu klären, was unter einer domänenspezifischen Sprache verstanden wird, und wie eine solche zur Problemlösung beiträgt. Im Anschluss daran soll das Konzept vorgestellt werden, welches dem Verfahren zur Generierung von Sichten auf die Unternehmensarchitektur zugrunde liegt. 3.1. Anwendungsfälle Relevante Anwendungsfälle im Kontext der beschriebenen Problemstellung drehen sich insbesondere um die Nutzung von Viewpoints zur Generierung von Softwarekarten aus Daten über die Unternehmensarchitektur. Als erste Nutzerrolle in diesem Kontext wird nun der Kartennutzer betrachtet. Diese Rolle dient dem Erzeugen und Analysieren von Sichten auf die Unternehmenslandschaft in Form von Visualisierungen. Abbildung 3.1 zeigt ein UML- Diagramm mit den assoziierten Anwendungsfällen. Diese werden im Folgenden erläutert. Betrachte Karte Dies ist ein abstrakter Anwendungsfall, der das Betrachten einer Softwarekarte repräsentiert. Er wird durch die Anwendungsfälle Lade Karte und Erzeuge Karte konkretisiert. 22

3. Analyse Abbildung 3.1.: Anwendungsfälle bei der Nutzung von Viewpoints Lade Karte Dieser Anwendungsfall stellt das Laden und Betrachten einer durch den Anwendungsfall Erzeuge Karte bereits erzeugten Karte dar. Erzeuge Karte Dieser Anwendungsfall dient dem automatischen Erzeugen einer neuen Karte aus den Daten eines gewählten semantischen Modells und unter Anwendung eines Blickwinkels, repräsentiert durch die Anwendungsfälle Wähle Blickwinkel und Wähle semantisches Modell. Wähle Blickwinkel Dieser Anwendungsfall stellt die Auswahl eines definierten Blickwinkels dar. Wähle semantisches Modell Dieser Anwendungsfall repräsentiert die Wahl des einer Karte zugrunde liegenden semantischen Modells. Lösche Karte Dies stellt das Löschen einer durch den Anwendungsfall Erzeuge Karte erzeugten Karte dar. Exportiere Karte Dieser Anwendungsfall erlaubt es dem Benutzer eine Softwarekarte in verschiedene Graphikformate zu exportieren. Zentral für dieses Nutzungsszenario ist der Anwendungsfall Erzeuge Karte. Bei diesem Anwendungsfall wendet der Kartennutzer einen definierten Viewpoint auf ein semantisches Modell an und erzeugt somit einen View auf die Daten 23

3. Analyse Abbildung 3.2.: Anwendungsfälle beim Design von Viewpoints in Form einer Softwarekarte. Die Viewpoints selbst werden durch den Blickwinkeldesigner erstellt. Die Anwendungsfälle dieser Rolle werden in Abbildung 3.2 aufgezeigt und im Folgenden näher erläutert. Erzeuge Blickwinkel Dieser Anwendungsfall repräsentiert das Erstellen eines neuen Blickwinkels: Der Blickwinkeldesigner muss dazu ein Informationsmodell wählen, und den zu visualisierenden Ausschnitt dessen festlegen. Außerdem muss er graphische Konzepte eines Visualisierungsmodells wählen, anhand derer die Daten visualisiert werden sollen. Wähle Informationsmodell Dieser Anwendungsfall dient der Wahl eines Informationsmodells, für welches ein Blickwinkel entworfen werden soll. Wähle zu visualisierende Daten Dies repräsentiert die Wahl der zu visualisierenden Aspekte der Anwendungslandschaft anhand des Informationsmodells. Wähle graphische Konzepte Dieser Anwendungsfall stellt die Wahl der graphischen Konzepte dar, die die Informationen darstellen. Bearbeite Blickwinkel Dies stellt das Bearbeiten eines durch den Anwendungsfall Erzeuge Blickwinkel angelegten Viewpoints dar. Lösche Blickwinkel Dieser Anwendungsfall erlaubt es dem Blickwinkeldesigner einen zuvor erstellten Viewpoint wieder zu löschen. 24

3. Analyse instanziiert ECore instanziiert anwendbar auf Informationsmodell Java Sprachspezifikation Visualisierungsmodell instanziiert verwendet entspricht Implementierung einer Transformation verwendet instanziiert Semantisches Modell Symbolisches Modell Abbildung 3.3.: Transformationsansatz nach Schweda [Sc06] Der Anwendungsfall Erzeuge Blickwinkel stellt in diesem von einem Blickwinkeldesigner ausgehenden Nutzungsszenario das zentrale Element dar. Der Nutzer greift dabei auf die in den folgenden Kapiteln skizzierte Sprache zur Beschreibung eines Viewpoints zurück, um einen Blickwinkel zu definieren. Dabei definiert er die durchzuführende Transformation auf Basis des Informationsmodells, welches als Metamodell des bei der konkreten Transformation zugrunde liegenden semantischen Modells dient. Ergebnis der Transformation und somit Resultat der Anwendung eines Viewpoints ist ein symbolisches Modell, welches in der Blickwinkel-Beschreibung durch das Visualisierungsmodell beschrieben wird. 3.2. Domänenspezifische Sprache Wie in Kapitel 2 bereits angesprochen wurden im Vorfeld dieser Arbeit bereits verschiedene Möglichkeiten untersucht, Viewpoints zu beschreiben. Schweda [Sc06], Wiegelmann [Wi08] und Ramacher [Ra09] nutzten dabei jeweils verschiedene Ansätze auf unterschiedlichen Abstraktionsniveaus: Der Transformationsansatz nach Schweda nutzt die Basisprogrammiersprache Java zur Beschreibung der Viewpoints. Abbildung 3.3 ordnet diesen Ansatz in das Schema der Generierung von Visualisierungen im SyCaTool ein. Die Implementierung einer Transformation erfolgt dabei durch direkten Zugriff sowohl auf das In- 25

3. Analyse instanziiert ECore instanziiert anwendbar auf Informationsmodell ATL Sprachspezifikation Visualisierungsmodell instanziiert verwendet entspricht Implementierung einer Transformation verwendet instanziiert Semantisches Modell Symbolisches Modell Abbildung 3.4.: Transformationsansatz nach Wiegelmann [Wi08] formationsmodell als Quelle als auch auf das Visualisierungsmodell als Ziel. Die Verwendung einer Basisprogrammiersprache wie Java stellt einen ersten Abstraktionsschritt bezüglich eines ausführbaren Systems dar, indem dem Entwickler Details des ausführbaren Systems wie bspw. die Ansteuerung konkreter Hardware oder die Speicherverwaltung verborgen bleiben. Dank der Turing- Vollständigkeit einer derartigen Programmiersprache ist gewährleistet, dass sich damit jede berechenbare Funktion und somit auch jegliche Transformationsregel beschreiben lässt. Bei der Definition eines Viewpoints auf diesem Abstraktionsniveau müssen jedoch wiederkehrende Bestandteile von Modelltransformationen explizit umgesetzt werden, so z. B. das Laden und der Zugriff auf Objekte des Quellmodells, das Ausführen von Abfragen auf das Modell und die Anwendung von Transformationsregeln gegen Objekte des Modells. Spezifische Modelltransformationssprachen, wie beispielsweise die von Wiegelmann in [Wi08] verwendete Atlas Transformation Language (ATL) [AT06], unterstützen demgegenüber einen höheren Grad der Abstraktion, indem sie für die Realisierung einer Modelltransformation unerhebliche Aspekte vor dem Entwickler verbergen und die Transformationsregeln somit direkt beschrieben werden können. Abbildung 3.4 ordnet diesen Ansatz in das Transformationskonzept des SyCaTools ein. Auch hier greift die Beschreibung einer Transformation direkt auf die zwei Modelle Informations- und Visualisierungsmodell zu. Die Allgemeinheit einer Modelltransformationssprache ermöglicht es beliebige Transformationen für verschiedene Modelle zu beschreiben. Aufgrund 26

3. Analyse dieser Allgemeinheit müssen jedoch auch bei diesem Ansatz Elemente des Transformationsverfahrens wiederholt umgesetzt werden, da keine speziellen Sprachkonstrukte zur Verfügung stehen, die die speziellen Anforderungen einer Transformation im Kontext der Softwarekartographie unterstützen. Solche speziellen Anforderungen sind z. B. [Ra09]: Ein graphisches Konzept der Softwarekartographie besteht in der Regel aus mehreren zusammenwirkenden Basis-Konzepten des Visualisierungsmodells. Das Konzept des Clusters beispielsweise besteht zumindest aus dem Gestaltungsmittel eines äußeren (umgebenden) Symbols, mit welchem eines oder mehrere Nesting-Konzepte verbunden sind (Gestaltungsregel), die wiederum Gestaltungsmittel für die Darstellung der inneren Symbole referenzieren (vgl. Abschnitt 2.4.3). Bei der Beschreibung einer Transformation semantischer Daten in ein solches graphisches Konzept muss deshalb eine ganze Reihe an Basis-Konzepten des Visualisierungsmodells instanziiert werden. Der Instanziierung eines graphischen Konzepts innerhalb einer Transformationsregel gehen in der Regel spezifische und zum Teil aufwendige Berechnungen voraus, die bei der Beschreibung einer Transformation durch den Entwickler wenig abstrakt umgesetzt werden müssen. Die Arbeit mit domänenspezifische Datentypen erfordert speziellen, vorwiegend technischen Code: Eine Farbe kann beispielsweise hexadezimal in der serialisierten Form #448f2c als Konstante beschrieben werden, die dann jedoch durch eine entsprechende Routine einem definierten Attribut eines Objektes zugewiesen werden muss. Diese fehlende Abstraktion der verwendeten Sprachkonstrukte wird im Allgemeinen als Abstraktionslücke bezeichnet. Abbildung 3.5 illustriert die Abstraktionslücke bei den beschriebenen Transformationsverfahren. Ein Mittel zur Überbrückung einer solchen Abstraktionslücke ist ein Framework (vgl. Abbildung 3.6). Ein Framework stellt einen allgemeinen Rahmen zur Lösung einer abgegrenzten Klasse von Problemen zur Verfügung [Bü07a]. Zur Lösung konkreter Problemstellungen muss ein Framework angepasst werden, weshalb es sogenannte Erweiterungspunkte (auch Hot-Spots genannt) zur Verfügung stellt, an denen diese Anpassungen konfiguriert werden können. Es werden 27

3. Analyse Softwarekartographie- Transformation Anforderungen Abstraktionslücke Modelltransformationssprache Basisprogrammiersprache Abstraktionsgrad Abstraktionslücke Anpassungen Framework Abstraktionsgrad Ausführbares System Ausführbares System Abbildung 3.5.: Abstraktionslücke bei Transformationsansätzen Abbildung 3.6.: Überbrückung der Abstraktionslücke zwei Arten von Frameworks unterschieden [Pr97]: Whitebox-Frameworks werden durch die Implementierung von Methoden und Klassen konfiguriert, die über die Erweiterungspunkte vorgegeben werden. Dabei wird die Vererbung als Mittel zur Anpassung eingesetzt. Im Gegensatz dazu setzt die Verwendung eines Blackbox-Frameworks keine Kenntnisse der Programmiersprache beim Framework-Nutzer voraus: Diese Art von Framework wird deklarativ durch Kombination fertig implementierter Klassen konfiguriert. Die Konfiguration eines Frameworks anhand seiner Erweiterungspunkte geschieht durch eine, meist deklarative, formale Sprache, deren Syntax die Erweiterungsmöglichkeiten des Frameworks wiederspiegelt. Diese Sprache verfügt nicht über die volle Ausdrucksmächtigkeit einer Turing-vollständigen General Purpose Language [Bü07a] sondern addressiert die problemspezifischen Eigenschaften der jeweiligen Anwendungsdomäne. Eine solche Sprache wird deshalb auch domänenspezifische Sprache (engl. domain-specific language (DSL)) bezeichnet. Derartige Sprachen können unterschieden werden in interne und externe DSLs. Interne domänenspezifische Sprachen nutzen Elemente der Basisprogrammiersprache zur Beschreibung der Probleminstanz. Die Konfiguration des Frameworks anhand dessen Erweiterungspunkten erfolgt durch Konstrukte der Basisprogrammiersprache. Im Gegensatz dazu sind externe DSLs dedizierte Sprachen, deren Syntax frei gewählt werden kann. Zur Überbrückung der Abstraktionslücke in den beschriebenen Ansätzen zur Beschreibung von Viewpoints hat Ramacher in [Ra09] eine erste Version eines 28

3. Analyse instanziiert ECore instanziiert anwendbar auf Informationsmodell VDL Metamodell verwendet Visualisierungsmodell instanziiert verwendet instanziiert Implementierung einer Transformation instanziiert Semantisches Modell Symbolisches Modell Abbildung 3.7.: Transformationsansatz nach Ramacher [Ra09] Transformationsframeworks entwickelt. Dieses Framework versteht eine zu realisierende Transformation im Kontext der Softwarekartographie als konkrete Probleminstanz, zu deren Lösung das Framework durch eine als Viewpoint Description Language (VDL) bezeichnete domänenspezifische Sprache konfiguriert wird. Wie in Abschnitt 3.1 gezeigt, steht bei der Definition eines Viewpoints die Auswahl der zu visualisierenden Daten aus der Unternehmensarchitektur und die darauf anzuwendenden graphischen Konzepte im Vordergrund. Diese graphischen Konzepte werden durch Abbildungsvorschriften beschrieben, die diese auf Basis-Konzepte des Visualisierungsmodells zurückführen (vgl. Abschnitt 2.4.3). Im Gegensatz zu den Ansätzen von Schweda [Sc06] und Wiegelmann [Wi08] werden die Abbildungsvorschriften beim Ansatz von Ramacher [Ra09] im Transformationsframework gekapselt. Abbildung 3.7 illustriert dies (vgl. Abbildungen 3.3 und 3.4). Somit wird ein allgemeiner Lösungsansatz zur Realisierung von Softwarekartographie-Transformationen angeboten. Die erforderliche Auswahl und Instanziierung graphischer Konzepte beschränkt sich demnach auf die Konfiguration des Frameworks an den Erweiterungspunkten durch die Viewpoint Description Language. Die VDL kann somit als Metamodell verstanden werden, dessen konkrete Instanziierung der Definition eines Viewpoints entspricht. Die Implementierung einer Transformation greift demzufolge nur mehr auf das Informationsmodell zu. Mit der Kapselung des Zugriffs auf das Visualisierungsmodell im Framework geht ein Verzicht auf die Ausdrucksmächigkeit von Programmier- und Mo- 29

3. Analyse delltransformationssprachen einher. Beliebige Abbildungsregeln können somit nicht beschrieben werden. Dieser bewusste Verzicht erfolgt unter der Annahme einer weitgehend feststehenden Sammlung von graphischen Konzepten in einer Viewpoint Library, deren Elemente durch Basiskonzepte eines definierten Visualisierungsmodells beschrieben werden können. Diese Annahme stützt sich auf die Analyse der in [Ma08b] aufgeführten Visualisierungen [Ra09]. Die Wahl der graphischen Konzepte zur Visualisierung von Daten der Anwendungslandschaft beschränkt sich somit auf eine entsprechende Konfiguration des Frameworks anhand dessen Erweiterungspunkten. Die gekapselten Abbildungsvorschriften müssen somit geeignet parameterisiert sein, um diese Konfiguration zu ermöglichen. Da kein festes Informationsmodell vorausgesetzt werden kann (vgl. Abschnitt 2.4.2), muss die Parameterisierung innerhalb des Frameworks auf Konzepten des Metametamodells basieren. Das Framework ist somit abhängig von einem dem Visualisierungsmodell und dem Informationsmodell zugrundeliegenden gemeinsamen Metametamodell. 3.3. Konzept der VDL Während Ramacher in [Ra09] von einem hierarchischen Aufbau der graphischen Konzepte ausgegangen ist, soll im Folgenden eine alternative Implementierung des Transformationsframeworks entstehen, dem eine netzartige Struktur zugrunde liegt. Die Knoten sollen dabei den durch Transformationsbausteine dargestellt werden, während die Kanten der Parameterisierung und dem Informationsfluss dienen. Ein vergleichbares Konzept liegt Yahoo!-Pipes [Ya10c] zugrunde. Yahoo!-Pipes ist eine kostenlose Webanwendung des amerikanischen Internetunternehmens Yahoo!, die es dem Nutzer erlaubt, Mashups, d. h. neue Zusammenstellungen von Inhalten aus bestehenden Quellen, zu erstellen und die erzeugten Daten zu publizieren. Die Anwendung stellt dazu einen visuellen Editor zur Verfügung, der das Anlegen und Editieren einer sogenannten Pipe ermöglicht. Abbilding 3.8 zeigt den Pipes-Editor mit einer einfachen Pipe [Ya10a]. Man erkennt die zwei Hauptkomponenten des Editors: Links im Bild die Modulbi- 30

3. Analyse Abbildung 3.8.: Editor der Yahoo!-Pipes Webanwendung mit beispielhafter Pipe [Ya10a] 31

3. Analyse bliothek, geordnet nach Kategorien, und mittig das Canvas (Leinwand), auf dem die Pipe zusammengestellt wird. Eine konkrete Pipe wird erstellt, indem vorgefertigte Module aus der Modulbibliothek auf das Canvas geschoben und dort verknüpft werden. Die Module stellen Verarbeitungsschritte dar, die Verknüpfungslinien den Datenfluss. Die dargestellte Pipe dient der Aggregation der Ergebnisse von einer Suche nach Nachrichten bei den Suchmaschinen Google und Yahoo!. Bei Ausführung nimmt die Pipe eine Eingabe des Nutzers entgegen, setzt mit dieser Eingabe je eine URL der Google- und Yahoo!-Nachrichtensuche um und nimmt die Ergebnisse in Form je eines RSS-Feeds entgegen. Im Anschluss folgt eine Aussortierung von Duplikaten anhand der URLs der Ergebnisse und eine Weitergabe des Resultats an das Ausgabe-Modul. Die Pipe kann dann beispielsweise über die Webseite von Yahoo!-Pipes aufgerufen werden [Ya10b], wo nach Eingabe des gewünschten Suchbegriffs die aggregierten Ergebnisse angezeigt werden. Eine weitere Möglichkeit ist die Ausführung über eine URL, der die nötigen Eingaben und das gewünschte Ausgabeformat als Parameter mitgegeben werden. Das Ergebnis kann dann beispielsweise als RSS-Feed oder im JSON-Format empfangen werden, sodass eine automatische Weiterverarbeitung möglich ist. Eine vergleichbare Funktionalität soll im Rahmen dieser Arbeit für die Definition und Durchführung von Transformationen im Bereich der Softwarekartographie entstehen. 32

4. Design Dieses Kapitel soll einen weiteren Schritt in Richtung Umsetzung der in den vorigen Kapiteln beschriebenen Anforderungen dokumentieren. Es sollen dabei vor allem Designentscheidungen vorgestellt und zentrale Konzepte erläutert werden. Die konkrete Implementierung wird dann im folgenden Kapitel dargestellt. Zur Darstellung des Designs des Frameworks sollen zunächst die Grundlagen des Informationsflusses in der Netzstruktur vorgestellt werden, um im Anschluss daran näher auf die Transformationsknoten einzugehen. Darauf aufbauend sollen Beispiele für Transformationsstrukturen in der Viewpoint Description Language vorgestellt und erläutert werden. 4.1. Quellen und Senken Wie in Abschnitt 3.3 beschrieben soll ein Transformationsframework entstehen, welches auf Basis von Bausteinen arbeitet, die über eine netzartige Struktur miteinander verbunden werden. Eine zentrale Frage beim Design der technischen Umsetzung ist daher, wie die Verbindungspunkte ausgestaltet werden. Es wurde dazu ein Konzept von Quellen und Senken entworfen, welches im Folgenden näher beschrieben wird. 4.1.1. Konzept der Verbindungspunkte Als Quelle (engl. ) wird dabei ein Verbindungspunkt bezeichnet, der Informationen anbietet. Dabei ist zu beachten, dass die Außensicht auf einen Transformationsbaustein verwendet wird, d. h. die Quelle kann als Ausgabepunkt des Bausteins verstanden werden. Äquivalent dazu fragt eine Senke 33

4. Design (engl. ) Informationen nach, entspricht also einer Eingabe in den Transformationsbaustein. Die angebotenen und nachgefragten Informationen können dabei unterschiedlichen Typs sein. So kann eine Quelle beispielsweise Objekte des Informationsmodells anbieten oder eine Senke Objekte des Visualisierungsmodells nachfragen. Diese Typinformationen werden mit der Quelle oder Senke publiziert. Damit eine Quelle die Informationen liefern kann, die durch eine Senke nachgefragt werden, können diese verbunden werden. Dabei gilt, dass mit einer Senke maximal eine Quelle verbunden werden darf, und umgekehrt mit einer Quelle auch maximal eine Senke. Des Weiteren gilt, dass der Typ der angebotenen Information mit dem Typ der Nachfrage übereinstimmen muss. Bei der Ausführung der Transformation muss standardmäßig jede Informationsnachfrage gesättigt werden, mit jeder Senke also eine Quelle verbunden sein. Im Gegensatz dazu muss die von Quellen angebotene Information nicht verwendet werden. Es besteht jedoch die Möglichkeit, Senken als optional zu markieren. In diesem Fall steht es dem Blickwinkeldesigner frei, eine Quelle mit einer so gekennzeichneten Senke zu verbinden. Eine weitere Möglichkeit besteht darin, die Informationsnachfrage einer Senke mit einer (konstanten) Standardinformation vorzubelegen. Auch in diesem Fall kann der Blickwinkeldesigner die Senke mit einer eigenen Quelle verbinden, falls er von dem Standard abweichende Informationen bereitstellen möchte. 4.1.2. Graphische Repräsentation der Quellen und Senken Für die graphische Darstellung des Transformationsnetzes sind zur Repräsentation von Quellen und Senken Symbole entstanden, die die essentiellen Informationstypen im Bereich der Softwarekartographie beschreiben. Tabelle 4.1 zeigt eine Übersicht über die enstandenen Symbole. Informationsobjekt bezeichnet dabei ein Objekt aus dem Informationsmodell, Visualisierungsobjekt ein Objekt des Visualisierungsmodells. Für eine Quelle und Senke wird jeweils ein Symbol für ein einzelnes dieser Objekte und für eine Menge solcher Objekte definiert. Zwei weitere Symbole stehen für alle 34

4. Design Quelle Typ Senke Einzelnes Informationsobjekt Mehrere Informationsobjekte Einzelnes Visualisierungsobjekt Mehrere Visualisierungsobjekte Objekt eines anderen Typs Tabelle 4.1.: Graphische Repräsentation verschiedener Typen von Quellen und Senken sonstigen Typen nachgefragter bzw. angebotener Information. Während erstgenannte Symbole ausreichend sind, um passende Quellen- und Senkenpaare zu identifizieren, muss der Typ bei Verwendung der letzgenannten Symbolik näher spezifiziert werden. Ein Beispiel für einen solchen weiteren Informationstyp ist ein Text oder auch eine Farbangabe. Verwendet werden Quellen und Senken insbesondere im Zusammenhang mit den Transformationsbausteinen, die im Folgenden vorgestellt werden sollen. 4.2. Viewpoint Building Blocks Neben der Frage der Ausgestaltung der Verbindungspunkte sind insbesondere die Transformationsbausteine von Bedeutung. Wie in den Abschnitten 3.2 und 3.3 beschrieben soll anhand dieser eine Transformation beschrieben werden können. Im Folgenden soll daher das Konzept dieser Bausteine dargestellt werden, sowie einige Beispiele für umgesetzte Transformationsbausteine erläutert werden. 35

4. Design outersymbol innersymbol Cluster outer2inner Abbildung 4.1.: Darstellung des Cluster-VBBs 4.2.1. Konzept der Viewpoint Building Blocks Die Bausteine einer Transformation im Bereich der Softwarekartographie stellen die Knoten des Transformationsnetzes dar. Wie in Abschnitt 3.2 beschrieben kapseln diese die konkreten Abbildungsvorschriften und erlauben die Definition eines Viewpoints auf hohem Abstraktionsniveau durch die Verbindung verschiedener Bausteine. Für diese Transformationsbausteine wird im Folgenden der Begriff Viewpoint Building Block (VBB) verwendet. Die Viewpoint Building Blocks werden anhand des in Abschnitt 4.1 erläuterten Quellen- und Senken-Konzepts konfiguriert. Die Senken repräsentieren dabei mögliche Eingaben in den Baustein, die Quellen die entsprechenden Ausgaben. Ein Viewpoint Building Block muss dabei mindestens eine Quelle oder Senke definieren, damit er im Transformationsnetz verwendet werden kann. Abbildung 4.1 zeigt ein Beispiel eines Viewpoint Building Blocks. Man erkennt darin je vier Quellen und Senken. Diese sind dargestellt durch die in Abschnitt 4.1.2 eingeführten Symbole. Des Weiteren erkennt man eine Gruppierung der Quellen und Senken in sogenannte Ports. Diese Ports dienen sowohl der Strukturierung der Building Blocks, als auch der semantischen Auszeichnung der enthaltenen Quellen und Senken. Im Beispiel sind die Ports outersymbol, innersymbol und outer2inner erkennbar. Je eine weitere Quelle und Senke sind außerhalb der Ports, jedoch innerhalb des Viewpoint Building Blocks, verzeichnet. Diese dienen dem grundlegenden Informationsfluss durch das Transformationsnetz. Im dargestellten Fall wird ein einzelnes Informationsobjekt als Eingabe erwartet und ein einzelnes Visualisierungsobjekt als Ausgabe des Building Blocks bereitgestellt. 36

4. Design width height Create Symbol text symbolclass Abbildung 4.2.: Darstellung des CreateSymbol-VBBs Der dargestellte Cluster -VBB dient dem in Abschnitt 2.4 angesprochenen Szenario der verschachtelten Darstellung von Informationsobjekten. Der Port outersymbol dient dabei der Umsetzung des äußeren (enthaltenden) Informationsobjektes in eine graphische Repräsentation in Form eines Visualisationsobjekts, der Port innersymbol der Umsetzung der inneren (enthaltenen) Informationsobjekte in entsprechende Visualisierungsobjekte. Der Port outer2inner dient der Navigation vom äußeren zu den inneren Informationsobjekten: Er bietet über die Quelle ein einzelnes Informationsobjekt als Ausgabe an, und erwartet eine Menge an Informationsobjekten als Eingabe. Der dargestellte Building Block ist somit ausschließlich für die Umsetzung der Verschachtelung zuständig. Sowohl die Navigation als auch die Visualisierung einzelner Informationsobjekte werden durch verbundene Transformationsknoten durchgeführt. Somit ist eine hohe Flexibilität trotz der Kapselung der konkreten Abbildungsvorschriften im Building Block gewährleistet. Abbildung 4.2 zeigt einen Ausschnitt des CreateSymbol -VBBs. Dieser Building Block dient der Transformation eines einzelnen Informationsobjektes in ein Visualisierungsobjekt. Er könnte somit mit den entsprechenden Quellen und Senken des in Abbildung 4.1 dargestellten Cluster-VBBs verbunden werden. Dieser Building Block verdeutlicht, dass selbst die Parameterisierung der Transformationsbausteine über Quellen und Senken vorgenommen wird. Neben der Wahl des Beschriftungstextes, der üblicherweise abhängig vom jeweiligen Informationsobjekt ist, ist auch die Wahl der visualisierenden Klasse, wie beispielsweise Rechteck, Kreis oder Linie möglich. Auch die Höhe und Breite kann über Senken beeinflusst werden. Dabei ist zu beachten, dass mit den Senken auch ein Building Block verbunden werden kann, der konstante Werte 37

4. Design rowtocolconnections colheadersymbol BinaryMatrix rowheadersymbol colsink rowsink connectionsymbol colsource rowsource Abbildung 4.3.: Darstellung des BinaryMatrix-VBBs liefert. Des Weiteren können diese Senken wie in Abschnitt 4.1 beschrieben als optional markiert oder mit Werten vorbelegt werden. Im Falle des dargestellten CreateSymbol-VBBs sind die Senken in den Ports width, height und symbolclass mit konstanten Werten vorbelegt, sowie die Senke im Port text als optional markiert. Der BinaryMatrix -VBB wird in Abbildung 4.3 dargstellt. Man erkennt darin, dass Quellen und Senken nicht immer paarweise vorkommen, sondern unabhängig voneinander verwendet werden können. Des Weiteren soll verdeutlicht werden, dass auch die Bezeichnungen der Quellen und Senken semantische Bedeutung haben können. Der dargestellte Transformationsbaustein visualisiert die Verbindungen zwischen zwei Klassen anhand einer binären Matrix. Über die Senken rowsink respektive colsink werden die Informationsobjekte übergeben, die die Zeilen bzw. Spalten der Matrix definieren sollen. Die Ports colheadersymbol und rowheadersymbol dienen der Visualisierung der einzelnen Zeilen- und Spaltenköpfe. Der Port rowtocolconnections wird verwendet, um alle mit einer Zeile verbundenen Spalten abzufragen. Die Senke im Port connectionsymbol schließlich dient dem Abfragen des Symbols, welches eine vorhandene Verbindung zwischen einer Zeile und einer Spalte repräsentiert. 4.2.2. Übersicht zentraler Viewpoint Building Blocks Abschnitt A.1 des Anhangs stellt weitere zentrale Viewpoint Building Blocks graphisch dar. Diese werden im Folgenden beschrieben: 38

4. Design Cluster Dieser Viewpoint Building Block dient der verschachtelten Darstellung von Informationsobjekten (siehe Abschnitt 4.2.1). RecursiveCluster Dieser Transformationsbaustein erweitert den Cluster-VBB mit einer rekursiven Abfrage weiterer äußerer Informationsobjekte. Dieser Building Block dient somit der Visualisierung beliebig tiefer Hierarchien. BinaryMatrix Dieser Transformationsknoten stellt Beziehungen anhand einer binären Matrix dar (siehe Abschnitt 4.2.1). Swimlane Dieser VBB visualisiert eine Many-to-Many-Beziehung. Über die Senke headersink übergebene Informationsobjekte spannen ein Gerüst auf, in welches die über die swimlanesink-senke übergebenen Informationsobjekte mit Hilfe des headertoswimlane-ports einsortiert werden. Die Ports swimlanesymbol und headersymbol dienen der Visualisierung der einzelnen Informationsobjekte. Ordering Der Viewpoint Building Block Ordering visualisiert eine azyklische Liste an Objekten, die jeweils maximal einen Vorgänger und Nachfolger haben. Die zu betrachtende Referenz wird über den reference-port übergeben. Über den Port symbol werden die einzelnen Objekte visualisiert, der Port direction gibt ab, ob die Liste horizontal oder vertikal ausgerichtet werden soll. CreateSymbol Dieser VBB dient der Transformation eines Informationsobjekts in ein Visualisierungsobjekt (siehe Abschnitt 4.2.1). SingleInstanceFilter Dieser Building Block erlaubt dem Kartennutzer beim Erzeugen einer Softwarekarte die Auswahl eines Informationsobjektes aus einer Liste möglicher Werte. Über den Port labelattribute wird das Attribut der Informationsobjekte angegeben, welches als Bezeichner für die Auswahl dient. MultiInstanceFilter Ähnlich dem SingleInstanceFilter erlaubt dieser Transformationsbaustein eine Auswahl mehrerer Informationsobjekte. FilterClass Dieser Viewpoint Building Block filtert eine Menge an Informationsobjekten nach einer Klasse des Informationsmodells. Die gefragte Klasse kann über den Port eclass konfiguriert werden. 39

4. Design FilterFeatureValue Dieser Transformationsknoten filtert eine Liste an Informationsobjekten nach dem Wert einer Eigentschaft. Diese Eigenschaft kann über den Port feature konfiguriert werden, der gesuchte Wert über den Port value. OneToMany Dieser Transformationsbaustein dient der Traversierung einer One-to-Many-Relation. Er erhält ein einzelnes Informationsobjekt und liefert eine Menge an verbundenen Informationsobjekten. Die Relation wird über den Port reference übergeben. OneToOne Dieser Building Block dient der Traversierung einer One-to-One- Relation. Er erhält ein einzelnes Informationsobjekt und gibt ein einzelnes, verbundenes Informationsobjekt zurück. Die Relation wird über den Port reference konfiguriert. SizeCodingDecorator Der SizeCodingDecorator setzt ein Informationsobjekt über den Port symbol in eine Visualisierung um und verändert diese graphische Darstellung, in Abhängigkeit von einer über den Port feature erhaltenen Eigenschaft des Informationsobjekts, in ihrer Größe. Visualisierungen können somit in Abhängigkeit einer Eigenschaft unterschiedlich prominent auf der Softwarekarte erscheinen. StringAttribute Dieser VBB wandelt ein über den Port attribute angegebenes Attribut des erhaltenen Informationsobjekts in eine Repräsentation in Textform. ContentReader Dieser Viewpoint Building Block dient dem Extrahieren der enthaltenen Informationsobjekte aus einem Informationsmodell. Das Informationsmodell wird dabei als spezielles Informationsobjekt behandelt. Root Der Root-Building Block dient bei der Konfiguration eines Viewpoints im graphischen Editor als Ein- und Ausgabe in den Transformationsgraphen. Zusätzlich zu den bereits vorgestellten Transformationsbausteinen sind im Rahmen dieser Arbeit weitere Viewpoint Building Blocks entstanden. Für die Beschreibung dieser weiteren Transformationsbausteine sei auf die Dokumentation des entstandenen Quellcodes verwiesen. 40

4. Design Root outersymbol innersymbol Cluster outer2inner Create Symbol Create Symbol width : 200 Filter Class text Content Reader eclass : Project String Attribute attribute : Project.name Abbildung 4.4.: Graphische Darstellung einer Viewpoint Definition 4.3. Transformationsgraphen Die Beschreibung eines Viewpoints in der Viewpoint Description Language entsteht durch Kombination von Building Blocks in einem Transformationsgraphen. Ein einfacher vollständiger Transformationsgraph ist in Abbildung 4.4 dargestellt. Zu beachten ist, dass die Viewpoint Building Blocks im gezeigten Transformationsgraphen auf das Wesentliche reduziert wurden. Des Weiteren wurden Ports, deren Senken mit konstanten Werten belegt wurden als Text dargestellt. Der jeweils übergebene konstante Wert wird unterstrichen angezeigt. Die Funktionsweise des dargestellten Graphen wird im Folgenden erläutert: Der zentrale Cluster-VBB wird mit dem Informationsmodell aus dem Root- Building Block gespeist. Die Cluster-Instanz liest dieses Modell über einen am Port outer2inner verbundenen ContentReader aus. Die Menge der gelesenen Informationsobjekte werden durch eine FilterClass-Instanz nach Objekten des Typs Projekt gefiltert und in den Cluster zurückgeschrieben. Der Cluster 41

4. Design Optimization of Monetary Transaction System Introduction of Knowledge Management Introduction of a new Management Informat... Integration of an auctioning platform into the... Replacement of the Customer Satisfaction... VAT change in POS System Introduction of a Bonus Card for Customers VAT change in Accounting System Reliability Improvement of the Online Shop Consolidation of Monetary Transaction Sys... Introduction of RFID in the Warehouse Database Consolidation VAT change in Price Tag Printing System VAT change in Online Shop Connection of Costing and Accounting System VAT change in Costing System Abbildung 4.5.: Clusterkarte als Ergebnis einer Transformation visualisiert die erhaltenen Projektobjekte über den Port innersymbol durch eine verbundene CreateSymbol-Instanz. Diese erhält vom verbundenen StringAttribute-VBB jeweils das Attribut name in Textform und verwendet dies zur Beschriftung der erzeugten Rechtecke. Den Rechtecken wird zusätzlich eine von der Vorgabe abweichende Breite von 200 gegeben. Über den Port outer- Symbol visualisiert das Cluster-VBB das äußere Informationsobjekt (in diesem Fall das Informationsmodell) und verschachtelt darin die erhaltenen inneren Symbole. Das Ergebnis in Form eines Visualisierungsobjekts wird über den Root-Building Block zurückgegeben. Die Clusterkarte in Abbildung 4.5 zeigt ein mögliches Ergebnis: Alle im Informationsmodell verzeichneten Projekte wurden darin in einem anonymen Container geschachtelt. Abbildung 4.6 zeigt ein weiteres Beispiel einer Viewpoint Definition in der Viewpoint Description Language. Dieser Transformationsgraph verschachtelt in Repräsentationen der Infrastrukturkomponenten die jeweils darauf verwendeten Applikationssysteme. Die Infrastrukturkomponenten selbst werden innerhalb eines anonymen Containers geclustert. Abbildung 4.7 zeigt das Ergebnis. 42

4. Design Root outersymbol innersymbol Cluster outer2inner outersymbol innersymbol Cluster Create Symbol Filter Class Create Symbol outer2inner symbolclass : CompositePlanarMapSymbol eclass : InfrastructureService valign : TOP halign : LEFT One To Many text Content Reader reference : InfrastructureService.deployedApplications String Attribute attribute : InfrastructureService.name Abbildung 4.6.: Beispiel eines Transformationsgraphen Create Symbol fillcolor : #FCFCB5 width : 180 height : 30 text String Attribute attribute : DeployedApplicationSystem.name 43

4. Design Oracle 9i Headquarter Online Shop Online Shop Accounting System Accounting System Accounting System Human Res System Document Management System Supplier Relationship Management System Proprietary Fat-Client London Monetary Transactions System (Great Br... POS System (Great Britain) POS System (Great Britain) Price Tag Printing System (Great Britain) Price Tag Printing System (Great Britain) Worktime Management System (Great Br... MySQL 2.1 Headquarter Costing System MIS (Management Information System) MIS (Management Information System) MIS (Management Information System) Apache 2.0.53 Warehouse Product Shipment System (Germany) Data Warehouse Fleet Management System DB2 6.0 London Monetary Transactions System (Great Br... IE 6.0 Headquarter Apache 2.0.53 Headquarter Tomcat 5.1 Headquarter Financial Planning System Online Shop MIS (Management Information System) Online Shop MIS (Management Information System) Online Shop MIS (Management Information System) Campaign Management System Online Shop MIS (Management Information System) Online Shop MIS (Management Information System) Online Shop Campaign Management System Customer Satisfaction Analysis System Accounting System Campaign Management System Accounting System Campaign Management System Accounting System Customer Satisfaction Analysis System Customer Satisfaction Analysis System Accounting System Customer Satisfaction Analysis System Accounting System Customer Satisfaction Analysis System Accounting System Customer Satisfaction Analysis System Customer Relationship Management S... Accounting System Customer Satisfaction Analysis System Accounting System Customer Satisfaction Analysis System Accounting System Customer Relationship Management S... Monetary Transaction System Human Res System Customer Relationship Management S... Human Res System Customer Relationship Management S... Supplier Relationship Management System Accounting and Costing System Accounting and Costing System Supplier Relationship Management System Accounting and Costing System Supplier Relationship Management System Accounting and Costing System MIS (Management Information System) Knowledge Managment System Knowledge Managment System MIS (Management Information System) Knowledge Managment System MIS (Management Information System) Knowledge Managment System MIS (Management Information System) Oracle 9i Munich Proprietary Fat-Client Munich Bea Weblogic 8.1 London Proprietary Fat-Client Hamburg Proprietary Fat-Client Headquarter Business Traveling System Business Traveling System Worktime Management System (Germa... Monetary Transactions System (Great Br... POS System (Germany/Hamburg) Monetary Transactions System (Germany) Business Traveling System Business Traveling System POS System (Great Britain) POS System (Germany/Hamburg) Costing System POS System (Germany/Munich) POS System (Germany/Munich) POS System (Great Britain) Price Tag Printing System (Germany/H... Document Management System POS System (Germany/Munich) POS System (Germany/Munich) Price Tag Printing System (Great Britain) Price Tag Printing System (Germany/H... Financial Planning System Worktime Management System (Germa... Price Tag Printing System (Germany/Mu... Price Tag Printing System (Great Britain) Worktime Management System (Germ... Monetary Transaction System Customer Complaint System Price Tag Printing System (Germany/Mu... Bea Weblogic 8.1 Hamburg Bea Weblogic 8.1 Munich Bea Weblogic 8.1 Headquarter Tomcat 5.1 Warehouse Oracle 9i London Oracle 9i Warehouse POS System (Germany/Hamburg) Business Traveling System Monetary Transactions System (Germany) Product Shipment System (Germany) POS System (Great Britain) Inventory Control System POS System (Germany/Hamburg) Business Traveling System Costing System Data Warehouse POS System (Great Britain) Inventory Control System Price Tag Printing System (Germany/H... Price Tag Printing System (Germany/Mu... Human Res System Fleet Management System Worktime Management System (Great Br... Data Warehouse Price Tag Printing System (Germany/H... Price Tag Printing System (Germany/Mu... Oracle 9i Hamburg MySQL 2.1 Warehouse MySQL 2.1 London MySQL 2.1 Hamburg Proprietary Fat-Client Warehouse MySQL 2.1 Munich POS System (Germany/Hamburg) Product Shipment System (Germany) Price Tag Printing System (Great Britain) Price Tag Printing System (Germany/H... Inventory Control System Price Tag Printing System (Germany/Mu... POS System (Germany/Hamburg) Fleet Management System Price Tag Printing System (Great Britain) Price Tag Printing System (Germany/H... Inventory Control System Price Tag Printing System (Germany/Mu... Worktime Management System (Germ... Apache 2.0.53 Munich Tomcat 51 Munich IE 6.0 Munich Bea Weblogic 8.1 Warehouse DB2 6.0 Headquarter IE 6.0 Warehouse Customer Complaint System Customer Complaint System Customer Complaint System Data Warehouse Monetary Transactions System (Germany) Abbildung 4.7.: Clusterkarte als Ergebnis einer Transformation 44

5. Implementierung Aufbauend auf den in Kapitel 4 vorgestellten Designkonzepten soll dieses Kapitel einen Einblick in die technische Umsetzung der Anforderungen geben. Dazu soll zuerst ein Überblick auf die Programmierung des Frameworks gegeben werden, um im Anschluss daran die Umsetzung konkreter Problemstellungen anhand von Beispielen zu demonstrieren. Die Darstellung der Realisierung eines graphischen Editors schließt dieses Kapitel ab. Aufgrund des Umfangs des entstandenen Quellcodes wird dieser im Rahmen dieser Arbeit nur in Auszügen dargestellt. Der vollständige Quellcode ist auf Anfrage beim Lehrstuhl für Software Engineering betrieblicher Informationssysteme der Technischen Universität München [se10a] oder beim Autor erhältlich. 5.1. Technische Umsetzung des Frameworks Die technische Umsetzung des Frameworks soll in diesem Abschnitt dargestellt werden. Dabei soll zuerst auf die Umsetzung des Quellen- und Senken-Konzepts eingegangen werden, um im Anschluss daran die Implementierung der Viewpoint Building Blocks zu erläutern. Aufgrund der Anforderung der Integration des entstandenen Frameworks in das Softwarekartographie-Werkzeug SyCaTool ist die Implementierung in der Programmiersprache Java erfolgt. Die Benennung der implementierten Klassen orientiert sich dabei an den Eclipse Namenskonventionen [Ec10] und den bereits im SyCaTool implementierten Klassen. So wird beispielsweise Interfacenamen ein I vorangestellt und abstrakten Basisklassen ein A. 45

5. Implementierung Abbildung 5.1.: Zentrale Informationsobjekte 5.1.1. Zentrale Informationsträger Abbildung 5.1 zeigt die zentralen Informationsträger des Transformationsframeworks. Analog zu den Bezeichnungen Informationsobjekt und Visualisierungsobjekt (vgl. Abschnitt 4.1.2) repräsentiert die Klasse InformationObject ein Objekt des Informationsmodells und die Klasse VisualizationObject ein Objekt des Visualisierungsmodells. Die Klassen dienen als Container für Objekte aus dem ECore-Metamodell des Eclipse Modeling Frameworks, welches die Grundlage der verwendeten Informations- und Visualisierungsmodelle darstellt (vgl. Abschnitt 2.4.1). Das gemeinsame Interface IVDLObject definiert die Methode getcontents() zum Zugriff auf die enthaltenen EObjects des ECore-Modells. Die vom InformationObject abgeleitete Klasse InformationModelObject dient der Repräsentation des Informationsmodells. Diese Klasse bietet eine zusätzliche Methode getre() zum Zugriff auf die Res, die das Informationsmodell beinhaltet. Der Zugriff auf das Visualisierungmodell findet über im SyCaTool bereits vorhandene Klassen und Methoden statt: Das Werkzeug bietet dazu eine Singleton-Klasse VisualizationPackage an, auf deren Instanz über das Feld VINSTANCE zugegriffen werden kann. 46

5. Implementierung Abbildung 5.2.: Interface der Senke Abbildung 5.3.: Interface der Quelle 5.1.2. Interfaces der Quellen und Senken Die Abbildungen 5.2 und 5.3 zeigen je ein UML-Klassendiagramm mit den Schnittstellen des realisierten Quellen- und Senken-Konzepts. Sowohl das Interface für die Quellen (ISource<T>) als auch für die Senken (ISink<T>) ist als generische Klasse implementiert. Der generische Typparameter (in den Abbildungen durch T gekennzeichnet) dient dabei der Auszeichnung des Typs der angebotenen bzw. nachgefragten Information. Eine Implementierung des Interfaces ISink<InformationObject> steht demnach für eine Nachfrage nach Objekten des Informationsmodells, eine Implementierung der Schnittstelle ISource<InformationObject> für ein entsprechendes Angebot. Die Methode get(ctx:icontext) des Interfaces ISource<T> dient dem Abruf von Informationen aus der Quelle. Der Methode wird eine Implementierung des Interfaces IContext übergeben, die den Transformationskontext darstellt und Methoden zum Durchsuchen des Informationsmodells oder der Interaktion mit dem Nutzer bereithält. Der Rückgabewert der Methode ist eine Instanz des angebotenen Informationstyps T. Die zweite Methode der Quelle, getoutputclassifier(), stellt einen ersten Schritt in Richtung einer näheren Spezifikation des Typparameters dar. Der Rückgabetyp IClassifier steht dabei für eine Repräsentation des Typparameters in der Meta-Ebene. Die Methoden des Interfaces ISink<T> dienen dem Verknüpfen mit einer Quelle (setsource(:isource<t>)), sowie dem Zugriff auf eine derart verbundene (getsource()). Des Weiteren kann ein Standardwert in Form einer 47

5. Implementierung Abbildung 5.4.: Abstrakte Basisklasse der Viewpoint Building Blocks Quelle gesetzt und abgefragt werden (setdefaultsource(defaultsource: ISource<T>) bzw. getdefaultsource()). Die Methode setoptional(optional:boolean) markiert eine Senke als optional, isoptional() fragt diesen Zustand ab. 5.1.3. Basisklasse der Viewpoint Building Blocks Die Programmierung eines Viewpoint Building Blocks ist im Gegensatz zu den Quellen und Senken nicht an die Implementierung einer Schnittstelle gebunden. Jedoch ist eine abstrakte Basisklasse entstanden, in der statische Hilfsmethoden gebündelt sind, die bei der Implementierung hilfreich sein können. Abbildung 5.4 stellt diese Klasse dar. Alle im Rahmen dieser Arbeit entstandenen VBBs erben von dieser Basisklasse. Die einzelnen Methoden werden im Folgenden erläutert. Die Methode setdefault(:isink<t>, constant:t) dient dem Setzen eines konstanten Standardwerts für eine Senke. setoptional(:isink<?>) markiert eine Senke als optional. Beide Methoden werden üblicherweise im Konstruktor verwendet, um bei der Instanziierung eines Building Blocks aufgerufen zu werden. Die Methode getvalue(:isink<t>, ctx:icontext) dient dem Erhalt des Wertes aus einer mit der gegebenen Senke verbundenen Quelle. Als weiterer Parameter wird der Transformationskontext übergeben. Die Methode fragt dabei sowohl eine ggf. durch den Blickwinkeldesigner verbundene Quelle ab, als auch den durch den Building-Block-Programmierer vorgegebenen Standardwert. Ist keine von beiden möglichen Quellen gesetzt wird eine Con- 48

5. Implementierung Abbildung 5.5.: Klassendiagramm des FilterClass-VBBs Filter Class eclass Abbildung 5.6.: Darstellung des FilterClass-VBBs figurationexception geworfen. Diese weist auf eine Fehlkonfiguration des Viewpoints hin. Um diese Fehlermeldung bei einer optionalen Senke zu vermeiden, kann vor dem Abruf des Wertes mit der Methode isset(:isink<?>) geprüft werden, ob eine Quelle gesetzt ist. Dabei wird sowohl ein konstanter Standard- Wert berücksichtigt, als auch eine durch den Blickwinkeldesigner verbundene Quelle. getclassifier(:isink<?>) schließlich kann verwendet werden, um den IClassifier einer mit der gegebenen Senke verbundenen Quelle abzufragen. Auch diese Methode prüft einen gegebenenfalls vorhandenen Standardwert. Ist keine Quelle verbunden wird eine generische Typbeschreibung zurückgegeben. 5.2. Implementierung eines Viewpoint Building Blocks Die Implementierung eins Viewpoint Building Blocks soll anhand des Filter- Class-Building Blocks erläutert werden. Abbildung 5.5 zeigt dazu das UML- 49

5. Implementierung Abbildung 5.7.: Basis-Implementierung eines Ports Klassendiagramm des Transformationsbausteins, Abbildung 5.6 die graphische Darstellung mit den Quellen und Senken. Man erkennt, dass sowohl der Port eclass als auch die zentrale Quelle und Senke als Attribute in der FilterClass-Klasse umgesetzt wurden. Quelle und Senke sind dabei Implementierungen der jeweiligen Schnittstellen, ihr Typ List<InformationObject> entspricht dem Informationstyp der dargestellten Quelle und Senke (vgl. Abschnitt 4.1.2). Der Port ist implementiert als eine Instanz der generischen Klasse BasicPort. Diese trägt zwei Typparameter, die jeweils dem Informationsangebot bzw. der -nachfrage der im Port enthaltenen Quelle (Typ List<InformationObject>) und Senke (Typ EClass) entsprechen. Wie ein Viewpoint Building Block ist auch die Implementierung eines Ports nicht an die Ableitung von einer Schnittstelle gebunden. Aufgrund der Häufigkeit eines Ports mit nur je einer Quelle und Senke (vgl. Anhang A.1) ist jedoch die Klasse BasicPort entstanden, mit der das wiederholte Implementieren dieser Funktionalität vermieden wird. Abbildung 5.7 zeigt den Aufbau dieser Klasse. Analog zur Definition in einem Building Block ist die Quelle und Senke in der Klasse BasicPort als Attribut definiert. Der Konstuktor erlaubt das Setzen einer Implementierung der Quelle durch einen Parameter, dem Attribut wird eine Instanz der Basis-Implementierung BasicSink<T> einer Senke zugewiesen. Da eine Senke keine Transformationslogik trägt (vgl. Abbildung 5.8), ist eine solche allgemein in der Klasse BasicSink<T> implementiert. Der generische Typparameter T entspricht dabei dem Typparameter der Senke. Implementiert wird die Transformationslogik in der Methode get(ctx:icontext) der Senke, wie die Implementierung des FilterClass-VBBs in Listing 5.1 zeigt. 50

5. Implementierung Abbildung 5.8.: Basis-Implementierung einer Senke Listing 5.1: Implementierung des FilterClass-VBB 1 public class FilterClass extends AViewpointBuildingBlock { 2 3 private final InternalSource<List<InformationObject>> internalsource = new InternalSource<List<InformationObject>>() { 4 @Override 5 public IClassifier getoutputclassifier() { 6 return getclassifier(filterclass.this.); 7 } 8 }; 9 10 public final BasicPort<EClass, List<InformationObject>> eclass = new BasicPort<EClass, List<InformationObject>>(this.internalSource); 11 12 public final ISink<List<InformationObject>> = new BasicSink<List<InformationObject>>(); 13 14 public final ISource<List<InformationObject>> = new ISource<List<InformationObject>>() { 15 16 @Override 17 public List<InformationObject> get(icontext ctx) throws ConfigurationException { 18 List<InformationObject> objects = getvalue(filterclass.this., ctx); 19 FilterClass.this.internalSource.setValue(objects); 51

5. Implementierung Abbildung 5.9.: Implementierung einer internen Quelle 20 EClass clazz = getvalue(filterclass.this.eclass., ctx); 21 22 List<InformationObject> filteredobjects = new LinkedList<InformationObject>(); 23 for (InformationObject currentobj : objects) { 24 if (clazz.isinstance(currentobj.getcontents())) { 25 filteredobjects.add(currentobj); 26 } 27 } 28 29 return filteredobjects; 30 } 31 32 @Override 33 public IClassifier getoutputclassifier() { 34 return getclassifier(filterclass.this.eclass.); 35 } 36 }; 37 } In dem dargestellten Codeabschnitt erkennt man in Zeile 10 die Definition eines Basis-Ports mit einer Informationsnachfrage vom Typ EClass und einem Informationsangebot vom Typ List<InformationObject>. Dem Konstruktor des BasicPorts wird die in Zeile 3f definierte InternalSource zur Verwendung als Quelle im Port übergeben. Diese dient als einfache Implementierung einer Quelle ohne Anwendungslogik, die einen zuvor gesetzten Wert über die get(ctx:icontext)-methode der Quellenschnittstelle zurückliefert. Abbildung 5.9 veranschaulicht dies. 52

5. Implementierung Abbildung 5.10.: Abstrakte Basisklasse einer Viewpoint Definition Die Senke des Transformationsbausteins wird in Zeile 12 definiert, die Quelle beginnt zwei Zeilen darunter. Letztere ist als anonyme innere Klasse ausgeführt und trägt die Transformationslogik. Diese wird in der get(ctx:icontext)- Methode definiert. In Zeile 18 werden darin mit der Hilfsmethode der abstrakten Basisklasse (vgl. Abschnitt 5.1.3) die zu filternden Informationsobjekte aus der Senke abgeholt. Diese werden darauf folgend der InternalSource übergeben und somit im Port eclass als Informationsangebot hinterlegt. In Zeile 20 wird die zu filternde Klasse aus der Senke des Ports abgefragt. Die Zeilen 22 27 dienen anschließend der Filterung anhand der gewonnenen Informationen. Zeile 29 schließlich zeigt die Rückgabe des Ergebnisses und somit des Informationsangebots des Transformationsbausteins. Die Zeile 33f zeigt die Methode zur Bestimmung des Typs des Rückgabewertes. Dieser entspricht der zu filternden Klasse und somit dem Rückgabetyp der Senke des Ports eclass. Die Zeilen 5f zeigen dies äquivalent für die Quelle des Ports: Diese bietet die aus der Senke des Transformationsbausteins gewonnenen Informationsobjekte an der Rückgabetyp entspricht somit dem dieser Senke. 5.3. Definition eines Viewpoints Im Folgenden soll auf die Möglichkeit der Definition eines Viewpoints in einer Java-Klasse eingegangen werden. Die weitere Möglichkeit der Konfiguration in einem graphischen Editor soll im nächsten Abschnitt behandelt werden. 53

5. Implementierung Root outersymbol innersymbol Cluster outer2inner Create Symbol Create Symbol width : 200 Filter Class text Content Reader eclass : Project String Attribute attribute : Project.name Abbildung 5.11.: Graphische Darstellung eines Transformationsgraphen Die in Abbildung 5.10 dargestellte abstrakte Klasse dient dabei als Basisklasse für alle Viewpoint-Implementierungen. Die darin verwendete Schnittstelle IViewpoint definiert mit der Methode getvisualizationsource(: ISource<InformationObject>) den Eintrittspunkt in den Transformationsgraphen. Ähnlich wie der von dem graphischen Editor verwendete Transformationsbaustein Root (vgl. Tabelle A.1) definiert diese eine Quelle vom Typ List<InformationObject> und erwartet eine Quelle vom Typ VisualizationObject als Ergebnis. Die zwei in der abstrakten Basisklasse definierten Methoden sind Hilfsmethoden, die das Verbinden einer Senke mit einer Quelle ermöglichen (connect(:isink<t>, :ISource<T>)), bzw. das Verbinden einer Senke mit einem konstanten Wert (connectconstant(: ISink<T>, constant:t)) erlauben. Der in Abbildung 5.11 dargestellte Graph wurde in Abschnitt 4.3 bereits erläutert. Er erzeugt eine Clusterkarte mit einer Übersicht über alle im Informationsmodell verzeichneten Projekte. Listing 5.2 zeigt eine Implementierung dieses Graphen als Klasse ViewpointDemo. 54

5. Implementierung Listing 5.2: Implementierung eines Transformationsgraphen 1 public class ViewpointDemo extends AViewpoint { 2 3 @Override 4 public ISource<VisualizationObject> getvisualizationsource(isource<informationobject> ) { 5 6 SyCaStoreModel.initialize(); 7 8 Cluster cluster = new Cluster(); 9 10 connect(cluster., ); 11 12 ContentReader contentreader = new ContentReader(); 13 14 FilterClass filter = new FilterClass(); 15 connectconstant(filter.eclass., SyCaStoreModel.project); 16 17 connect(contentreader., cluster.outer2inner.); 18 connect(filter., contentreader.); 19 connect(cluster.outer2inner., filter.); 20 21 CreateSymbol compositesymbol = new CreateSymbol(); 22 23 connect(compositesymbol., cluster.outersymbol.); 24 connect(cluster.outersymbol., compositesymbol.); 25 26 CreateSymbol projectsymbol = new CreateSymbol(); 27 connectconstant(projectsymbol.width., 200f); 28 29 connect(projectsymbol., cluster.innersymbol.); 30 connect(cluster.innersymbol., projectsymbol.); 31 32 StringAttribute projectname = new StringAttribute(); 33 connectconstant(projectname.attribute., SyCaStoreModel.name); 34 35 connect(projectname., projectsymbol.text.); 36 connect(projectsymbol.text., projectname.); 37 38 return cluster.; 39 } 40 } Der Transformationsgraph ist in der einzigen Methode der Klasse definiert. In Zeile 6 wird das Informationsmodell initialisiert. Dies ermöglicht den Zu- 55

5. Implementierung griff auf die im Modell enthaltenen Klassen und Felder über Attribute der SyCaStoreModel-Klasse. In Zeile 8 wird ein Objekt des zentralen Cluster- VBBs erzeugt. Im Anschluss ist erkennbar, wie dieses mit der als Methoden- Parameter übergebenen Quelle verbunden wird. Dies entspricht der Verbindung der Quelle des Root-VBBs mit dem Cluster in Abbildung 5.11. Darauf folgend wird in den Zeilen 12 und 14 je eine Instanz des ContentReader- und FilterClass-Transformationsbausteins erzeugt. In Zeile 15 wird die Senke des Ports eclass mit einer konstanten Referenz auf die Klasse Projekt des Informationsmodells verknüpft. Die Zeilen 17 19 dienen der Verbindung der Transformationsknoten Cluster, ContentReader und FilterClass. In den folgenden Zeilen werden analog zum beschriebenen Ablauf Instanzen der CreateSymbol-VBBs sowie des StringAttribute-Building Blocks initialisiert und entsprechend der Darstellung verbunden. In Zeile 38 schließlich wird die Quelle des Cluster-Bausteins als Endpunkt des Transformationsgraphen zurückgegeben. 5.4. Realisierung des graphischen Editors Neben der in Abschnitt 5.3 dargestellten Möglichkeit der Definition eines Viewpoints als Java-Klasse sollte eine prototypische Implementierung eines graphischen Editors erfolgen. Die Realisierung des Editors basiert auf dem Open Source-Werkzeug Oryx [Bu10]. Oryx ist ein web-basierter Editor zur Modellierung von Geschäftsprozessen und wird primär vom Hasso-Plattner-Institut (HPI) der Universität Potsdam entwickelt. Er basiert auf einem Client-Server- Modell, in dem die Modellierungsfunktionalität clientseitig in JavaScript implementiert wurde und die Datenhaltung serverseitig basierend auf Technologien der Java Enterprise Edition Platform (Java EE) basiert. Dierl hat in [Di10] mit einer Portierung des Editors auf das Enterprise Collaboration Tool Tricia [in10] begonnen. Dabei wurde die serverseitige Datenhaltung in Tricia integriert. Aufbauend auf dieser Arbeit verwendet der realisierte Editor Oryx zur clientseitigen Modellierung in einem Webbrowser, und Schnittstellen von Tricia zur Interaktion zwischen dem SyCaTool und den Modelldaten. Die Definition eines Viewpoints durch den Blickwinkeldesigner kann 56

5. Implementierung somit web-basiert erfolgen, während der Kartennutzer weiterhin die Möglichkeit hat, das Softwarekartographie-Werkzeug SyCaTool zu nutzen. Bei dem Erzeugen einer Karte macht es für den Kartennutzer somit keinen Unterschied, ob der Viewpoint in Form einer Java-Klasse implementiert wurde, oder von dem externen System geliefert wird. Die prototypische Implementierung auf Clientseite ist insbesondere durch das Erzeugen eines sogenannten Stencil Sets für den Oryx-Editor erfolgt. Ein Stencil Set ist ein Dokument in der JavaScript Object Notation (JSON), welches in Oryx als Beschreibung einer Modellierungssprache verwendet wird [Pe07]. Das Dokument kann Definitionen von Knoten, Kanten und Modellierungsregeln enthalten. Zu den Knoten und Kanten werden zusätzlich Bilder in Form von SVG-Dokumenten hinterlegt, die im Modelleditor zur Darstellung der Elemente verwendet werden. Die Modellierungsregeln beschränken sich dabei auf Vorgaben, die das Enthalten von Objekten beschreiben (Objekt A darf Objekt B enthalten) und Regeln, die das Verbinden zweier Objekte definieren (Objekt A kann über die Ecke E mit Objekt B verbunden werden). Des Weiteren besteht die Möglichkeit, Objekten Eigenschaften zu geben, die vom Nutzer geändert werden können. Abbildung 5.12 zeigt den realisierten Editor beim Bearbeiten eines Transformationsgraphen. Mittig ist die Zeichenfläche des Editors erkennbar, auf der der Ausschnitt einer Viewpoint-Definition zu erkennen ist. Auf der linken Seite sind die sogenannten Stencils, d. h. die möglichen Diagrammobjekte, aufgeführt. Rechts im Bild werden die Eigenschaften (engl. properties) des markierten Cluster-Objekts gezeigt. Die Leiste am oberen Rand des Editors bietet Möglichkeiten zum Speichern und Bearbeiten des Modells. Wie der Abbildung zu entnehmen ist, wurden die zentralen Elemente der Viewpoint Description Language als Stencils realisiert. Es wurden die Stencils Building Block, Port, Sink, Source, Parameter und Edge definiert. Das Stencil Building Block dient der Repräsentation eines Viewpoint Building Blocks im Modelleditor. In ihm können die Stencils Port, Sink und Source eingebettet werden. Ports können wiederum Quellen und Senken enthalten. Dies entspricht dem in Kapitel 4 vorgestellten Design. Zusätzlich ist ein Stencil Edge definiert, der einer Verbindung zwischen einer Quelle und einer Senke entspricht. 57

5. Implementierung Abbildung 5.12.: Darstellung des ModelEditors 58