Analyse von Ko-Refaktorisierungen in der modellgetriebenen Entwicklung am Beispiel von UML und Java

Größe: px
Ab Seite anzeigen:

Download "Analyse von Ko-Refaktorisierungen in der modellgetriebenen Entwicklung am Beispiel von UML und Java"

Transkript

1 Universität in Hagen Fakultät für Mathematik und Informatik Lehrgebiet Programmiersysteme Prof. Dr. Friedrich Steimann M A S T E R A R B E I T in der Fachrichtung Master of Science in Praktische Informatik (Applied Computer Science) T H E M A Analyse von Ko-Refaktorisierungen in der modellgetriebenen Entwicklung am Beispiel von UML und Java Eingereicht von: Jochen Schröer (Matrikelnr ) Hohentorsheerstraße Bremen Jochen-Schroeer@gmx.de Gutachter: Prof. Dr. Friedrich Steimann

2 ii Inhaltsverzeichnis. Abstract xii 1. Einleitung Motivation und Zielsetzung Eigener Beitrag Aufbau der Arbeit Grundlagen / Verwandte Arbeiten Refaktorisierung Rename-Refaktorisierung PullUp-Refaktorisierung Grundlagen der modellgetriebenen Entwicklung Model Driven Development Domänenspezifische Sprachen Model Driven Architecture Unified Modeling Language (UML) Modell-zu-Modell Transformationen Integrierte Entwicklungsumgebungen Eclipse Plugin-Architektur Eclipse Language Toolkit (LTK) Eclipse Modeling Project Eclipse Modeling Framework (EMF) Code-Generatoren EMF Code-Generator Acceleo Constraintbasierte Refaktorisierungen Refacola Überführung von Wohlgeformtheit-Regeln zu Constraint-Regeln Bestehende Ansätze für Modell-Refaktorisierungen Generic Model Refactorings (GenericMT) EMF Refactor Ableitung der funktionalen Anforderungen Automatische Durchführung der Ko-Refaktorisierungen Erhaltung der Bedeutung des Modells und des Codes Annullierung von Refaktorisierungen Ableitung der nicht-funktionalen Anforderungen Übertragung auf mehrere Zielplattformen/Generatoren Erweiterungsmöglichkeiten für weitere Refaktorisierungen Benutzeroberfläche Effizienz/Performance Bewertung bestehender Ansätze Zusammenfassung Ko-Refaktorisierungen mittels eines constraintbasierten Ansatzes Vorgehen Sprachdefinition von UML2 im Refacola-Kontext Constraint-Regeln von UML Constraint-Regeln zu Classifier Constraint-Regeln zu Namespace

3 Inhaltsverzeichnis iii Constraint-Regeln zu Property Constraint-Regeln zu NamedElement Constraint-Regeln zu Element Sprachdefinition und Constraint-Regeln von Java Constraint-Regeln für sprachübergreifende Refaktorisierungen Analyse des EMF in Bezug auf Refaktorisierungen Analyse des Acceleo-Generators in Bezug auf Refaktorisierungen Definition von sprachübergreifenden Refaktorisierungen zwischen UML2 und Java Rename Property-Refaktorisierung PullUp Property-Refaktorisierung Zusammenfassung Konzeption und Implementierung des Ko-Refaktorisierung-Plugins Gesamtarchitektur Komponenten Factory-Komponente Allgemeine Komponenten (Framework für Ko-Refaktorisierungen) 57 Info-Provider und Tracing Accessor-Functions Composed-Generator Post-Regenerierung Spezifische Komponenten für EMF Code-Generator Spezifische Komponenten für Acceleo-Generator Refacola-Definitionen Benutzeroberfläche / Integration in die Entwicklungsumgebung Zusammenfassung Evaluierung Einführung Durchführung der Refaktorisierungen Ergebnis der Durchführung Gesamtfazit und Ausblick 80 A. Prototyp / Benutzungsanleitung 81 A.1. Installationshinweise A.2. Benutzung des Refactoring-Plugin für Ko-Refaktorisierungen A.3. Benutzung des Evaluierungs-Plugin A.4. Schritte zur Benutzung B. Abbildungen 86 C. Tabellen 87 D. Listings 89 D.0.1. Acceleo-Listings D.0.2. Mitra-Transformationen D.0.3. Refacola-Definitionen Refacola-Definitionen für de.feu.ps.refacola.ecore.lang.uml- Komponente Refacola-Definitionen für de.feu.ps.refacola.ecore.lang.javaxuml- Komponente Refacola-Definitionen für de.feu.ps.refacola.ecore.lang.javaxuml.emf- Komponente

4 Inhaltsverzeichnis iv Refacola-Definitionen für de.feu.ps.refacola.ecore.lang.javaxuml.acceleo- Komponente E. CD-ROM-Beilage 104. Literaturverzeichnis 107. Eidesstattliche Erklärung 110

5 v Abbildungsverzeichnis 2.1. Beispiel RenameRefaktorisierung Beispiel PullUp-Refaktorisierung OMG MOF Ebenen-Architektur Infrastructure Library Pakete Gemeinsamer Infrastruktur Kern für UML und MOF Zusammenhang von Meta-Metamodell in M2M-Transformationen Eclipse Plugin-Architektur Beispiel für ein AST Bestandteile des LTK-Plugins für Refaktorisierungen Zyklus einer Refaktorisierung im LTK-Rahmenwerk OMG MOF Ebenen-Architektur im EMF-Kontext Code-Generierung mit EMF Code-Generator Code-Generierung mit UML-Modell als Ausgangsbasis Code-Generierung mit Acceleo Übersicht Refacola Refacola-Komponentenarchitektur Übersicht GenericMT GenericMT PullUp Refaktorisierung GenericMT Aspekt zur Adaption des UML-Metamodells PullUp-Refactorisierung mit EMF Refactor Use Cases für Ko-Refaktorisierungen Beispiel UML-Modell/Generierter Code und manueller Code Transformation UML-Metamodell in Refacola-Instanz Klassenhierarchie von Property gemäß UML-Superstruktur-Spezifikation Beispiel für AssociationOpposite-Constraint Beispiel für eine Property mit Assoziationen GenModel-Transformation nach PullUp-Refaktorisierung Transformation/Trace-Modell TracesEMFCodeGenerator Traces Acceleo Code-Generator Generierte Traces mit Acceleo Code-Generator in Eclipse Gesamtübersicht Komponenten-Modell Factory-Komponente im Kontext Abstrakte Factory-Klassen für Trace Info-Provider und Refactoring MultiProgrammInfoProvider für Ko-Refaktorisierungen Trace Info-Provider und Trace Info-Provider mit Trace-Generatoren Funktionen zur Generierung und Constraint-Überprüfung der Accessor- Methodennamen Funktionen zur Generierung der korrespondierenden Besitzer der Accessor-Methoden Composed Generator Post-Regenerierung Ablauf Post-Regenerierung Funktionen zur Generierung und Constraint-Überprüfung der EMFspezifischen Accessor-Methodennamen und Feldnamen Funktionen zur Generierung und Constraint-Überprüfung der EMFspezifischen Accessor-Methodennamen und Feldnamen

6 Abbildungsverzeichnis vi Funktionen zur Generierung und Constraint-Überprüfung der EMFspezifischen Accessor-Methodennamen und Feldnamen Funktionen zur Generierung der korrespondierenden Besitzer der EMFspezifischen Accessor-Methoden EMF-spezifische Trace-Generatoren und Post-Code-Generierungen Acceleo-spezifische Trace-Generatoren KindsRelatedQuery-Klasse in der Refacola-API Komponente Überschreitung Größe Static Initializer in der generierten Refacola-Klasse UmlPackage Benutzeroberflächen des Plugins in Eclipse Architektur Benutzeroberfläche und Integration in Eclipse Refactoring Tool Tester-Interfaces Durchführung der Evaluierung für einen Probanden A.1. Refactoring-Plugin für Ko-Refaktorisierungen Schritt A.2. Refactoring-Plugin für Ko-Refaktorisierungen Schritt 2a A.3. Refactoring-Plugin für Ko-Refaktorisierungen Schritt 2b A.4. Refactoring-Plugin für Ko-Refaktorisierungen Schritt A.5. Evaluierungs-Plugin für Ko-Refaktorisierungen Schritt A.6. Evaluierungs-Plugin für Ko-Refaktorisierungen Schritt B.1. Ablauf Constraint-Erzeugung und Constraint-Solving in Refacola

7 vii Tabellenverzeichnis 2.1. Bewertungsmatrix Constraints in Classifier Constraints in Namespace Feststehende und veränderbare Eigenschaften Constraints in Property Constraints in NamedElement Constraints in Element Evaluierung mit EMF Code-Generator Evaluierung mit Acceleo-Generator C.1. Constraints in MultiplicityElement C.2. Constraints in RedefinableElement

8 viii Listings 2.1. Beispielhafte Refacola-Module für Java in der Refacola-DSL inheritablemembers-operation für Classifier hasvisibilityof-operation für Classifier membersaredistinguishable-operation für Namespace isdistinguishablefrom-operation für Namespace getnamesofmember-operation für Namespace subsettingcontext-operation für Property conformsto-operation für Namespace allparents-operation für Namespace parents-operation für Classifier allownedelements-operation für Element mustbeowned-operation für Element Ausschnitt per EMF generierter Code im Package-Interface Interface Accessor-Function in Constraint-Regel Übergreifende Constraint-Regel Accessor-Owner Beispiel-Anwendung des ComposedGenerators in der Refacola-Definition membersaredistinguishable-constraint-regel in Refacola für Rename- Refaktorisierung Spezifische Abfragen und Constraint-Regeln für EMF-Generator Unit-Tests für Evaluierung von Wiki Table für EMF D.1. Acceleo Model-to-text (MTL) Modul zur Generierung von Java-Code aus UML-Modellen, Quelle: aus Acceleo Examples D.2. Mitra-Regeln zur Transformation von Ecore- in Refacola-Modellen, Quelle: aus FernUniversität Hagen Clare Subversion Repository D.3. Ergebnis der Mitra-Transformation UML zu Refacola (Auszug, im XMI- Format) D.4. Refacola UML-Sprachdefinition D.5. Allgemeine Constraint-Regeln zu UML D.6. Abhängige Constraint-Regeln zu UML für Rename-Refaktorisierungen.. 95 D.7. Abhängige Constraint-Regeln zu UML für PullUp-Refaktorisierungen D.8. Allgemeine übergreifende Refacola-Sprachdefinition für Java und UML.. 97 D.9. Allgemeine übergreifende Constraint-Regeln für Java und UML D.10.Spezifische übergreifende Refacola-Sprachdefinition für Java (EMF) und UML D.11.Spezifische übergreifende Constraint-Regeln für Java (EMF) und UML.. 99 D.12.Spezifische übergreifende Constraint-Regeln für Java (EMF) und UML (spezifisch für Rename-Refaktorisierung) D.13.Spezifische übergreifende Constraint-Regeln für Java (EMF) und UML (spezifisch für PullUp-Refaktorisierung) D.14.Spezifische übergreifende Refaktorisierungsdefinition (Rename- Refaktorisierung) für Java (EMF) und UML D.15.Spezifische übergreifende Refaktorisierungsdefinition (PullUP- Refaktorisierung) für Java (EMF) und UML D.16.Spezifische übergreifende Refaktorisierungsdefinition (Rename- Refaktorisierung) für Java (Acceleo) und UML

9 Listings ix D.17.Spezifische übergreifende Refaktorisierungsdefinition (PullUP- Refaktorisierung) für Java (Acceleo) und UML

10 x Abkürzungsverzeichnis API Application Programming Interface AST Abstract Syntax Tree CSP Constraint-Satisfaction-Problem DSL Domain-specific language EMF Eclipse Modeling Framework EMOF Essential MetaObject Facility GWT Google Web Toolkit IDE Integrated Development Environment / Integrierte Entwicklungsumgebung IEEE Institute of Electrical and Electronics Engineers JEE Java Enterprise JDT Eclipse Java Development Tools LTK Eclipse Language Toolkit M2M Modell-zu-Modell MDA Model Driven Architecture

11 Listings xi MDD Model Driven Development MDE Model Driven Engineering MDT Eclipse Model Development Tools MOF MetaObject Facility OSGI Open Services Gateway initiative UML Unified Modeling Language XMI CML Metadata Interchange XML Extensible Markup Language

12 xii Abstract Die Diziplin der Refaktorisierung gerade in agilen Vorgehensweisen der Softwareentwicklung gewinnt einen immer größeren Stellenwert. Bei der Refaktorierung handelt es sich dabei um eine interne qualitäts-erhöhende Strukturänderung von Software-Artefakten, wobei das nach außen sichtbare Verhalten der Software unverändert bleibt. Um hier den Refaktorisierungsprozess in Verbindung mit der modellgetriebenen Entwicklung effizienter zu gestalten, sollen im Rahmen dieser Arbeit Ko-Refaktorisierungen zwischen Modell und Code auf Basis verschiedener Code-Generatoren analysiert werden und ein Ansatz konzipiert werden, mit dem Modell und Code-Refaktorisierungen vereint werden, wodurch manuelle redundante Refaktorisierungen jeweils im Modell und im Code vermieden werden. In dieser Arbeit wird dies anhand verschiedener Refaktorisierungen in Form eines zu erstellenden Eclipse-Plugins für UML-Modelle und Java-Code aufgezeigt.

13 1 1. Einleitung Die Diziplin der Refaktorisierung gerade in agilen Vorgehensweisen der Softwareentwicklung gewinnt einen immer größeren Stellenwert und stellt heute einen wesentlichen Bestandteil in modernen Softwareentwicklungsprozessen dar. Im Laufe einer Weiterentwicklung einer Software kommt es oft zu Unsauberkeiten in den Software-Artefakten selbst und in der Struktur einer Software. Um diesen entgegen zu wirken, werden Refaktorisierungen in Software-Artefakten durchgeführt. Bei der Refaktorierung handelt es sich dabei um eine interne qualitäts-erhöhende Strukturänderung im Code, wobei das nach außen sichtbare Verhalten der Software unverändert bleibt. Adaptiert auf die modellgetriebene Softwareentwicklung kommt ergänzend die Strukturänderung unter Beibehaltung der Semantik des Modells hinzu. Martin Fowler hat diese Disziplin der Refaktorisierung vor allem durch sein Buch Refactoring - Improving the Design of Existing Code vorangebracht. Um hier den Refaktorisierungsprozess im Kontext der modellgetriebenen Softwareentwicklung effizienter zu gestalten, soll im Rahmen dieser Arbeit Ko-Refaktorisierungen zwischen Modellen und Code tiefergehend analysiert werden und ein Ansatz konzipiert werden, mit dem Modell- und Code-Refaktorisierungen vereint werden Motivation und Zielsetzung In der modellgetriebenen Softwareentwicklung stellt das Refaktorisieren eine zeitaufwändige Angelegenheit dar. Um das Modell und den Code synchron zu halten, muss entweder manuell im Code und im Modell die Refaktorisierung durchgeführt werden oder der Code muss nach dem Refaktorisieren neu generiert werden, was wiederum zu Problemen führt, wenn händisch codierte Bestandteile auf den generierten Code zugreifen. Modellgetriebene Projekte finden sich primär in der kommerziellen Software-Entwicklung und der Wirtschaftsinformatik wieder, in denen zunächst fachliche Entitäten (bspw. für eine Verwaltungssoftware für Dienstfahrzeuge) modelliert werden, aus denen dann der Code automatisiert, z. B. für Java Enterprise Webapplikationen, generiert wird. Die Umbenennung einer fachlichen Entität oder eines fachlichen Attributs im Modell kann daher abhängig vom eingesetzten Code-Generator zu weitreichenden Änderungen in den Code-Bestandteilen führen. Ziel dieser Arbeit ist es daher auf Basis der Analyse zur Ko-Refaktorisierungen eine Plugin-Komponente für integrierte Entwicklungsumgebungen wie bspw. Eclipse zu konzipieren, zu implementieren und zu evaluieren, um so den Refaktorierungsprozess in der modellgetriebenen Softwareentwicklung effizienter zu gestalten und dadurch den gesamten Entwicklungsprozess zu optimieren. Gemäß der Definition der Refaktorisierung darf sich nach dessen Durchführung die Bedeutung des Modells und das Verhalten des Programms nicht ändern. Folglich sind hier die Bedingungen für eine Refaktorisierung für die Modelle, für den generierten und nicht-generierten (Java-)Code, und für den Übergang eines Modells in generierten Code zu definieren und zu implementieren. Die aus einer Refaktorisierung resultierenden Änderungen müssen demnach im UML-Modell und auf den Abstact Syntax Tree (AST) des Codes angewendet werden.

14 1.2 Eigener Beitrag Eigener Beitrag Parallel und unabhängig zu dieser Arbeit ist ein Konferenzbeitrag mit ähnlicher Themenstellung am Lehrgebiet Programmiersysteme verfasst worden, der zur 28. IE- EE/ACM International Conference on Automated Software Engineering im November 2013 veröffentlicht worden ist. Abgrenzend zu dem Konferenzbeitrag sind im Rahmen dieser Arbeit constraintbasierte Ko-Refaktorisierungen unterschiedlicher Komplexitätsstufen und unter Nutzung unterschiedlicher Code-Generatoren durchgehend auf Basis des UML-Metamodells analysiert und evaluiert worden, welche ebenso die formalen Ableitungen aus der UML-Spezifikation beinhalten. Des weiteren wird das Thema bezüglich der Verwendung von Traces kritisch beurteilt (vgl. Kapitel 3.5). Zur Realisierung textbasierter Constraints, welche bspw. für die Namensbildung von Zugriffsmethoden relevant sind, ist im Unterschied zu dem Konferenzbeitrag ein funktionsorientierter Ansatz gewählt worden (vgl. Kapitel 4.2.2). In diesem Kontext wird im Rahmen dieser Arbeit auch die Erweiterung der domänenspezifischen Sprache von Refacola um weitere eingebettete Abfragen diskutiert und die Verwendung unterschiedlicher Code- Generatoren und dessen Auswirkungen auf die Architektur für constraintbasierte Ko- Refaktorisierungen beleuchtet. Bei der Evaluierung wird der modellgetriebene Ansatz adaptiert und abweichend von dem Konferenzbeitrag ausgehend von dem Modell Code erzeugt, auf dessen Basis die Evaluierungen für constraintbasierte Ko-Refaktorisierungen durchgeführt werden Aufbau der Arbeit Im Rahmen der Einleitung sollen die Motivation, Problemstellung und Zielsetzung der Arbeit vorgestellt werden. Im Kapitel Grundlagen / Verwandte Arbeiten werden die theoretischen Aspekte zu Refaktorisierung, modellgetriebenen Entwicklung und der integrierten Entwicklungsumgebung Eclipse thematisiert, wobei hier die Schwerpunkte auf der Plugin-Architektur, dem Eclipse Language Toolkit, dem Eclipse Modeling Framework Project (EMF) und der Model Development Tools (MDT) liegen. Zudem wird auf die domänenspezifische Sprache Refacola und dem dazugehörigen Framework, mit der sich Constraints für bestimmte Refaktorisierungen formulieren lassen, sowie auf verwandte Ansätze zur Modell-Refaktorisierung eingegangen. Auf Basis dieser Aspekte und Grundlagen werden die Lösungsansätze in den nachfolgenden Kapiteln erörtert. In Kapitel 3 werden die im vorherigen Kapitel thematisierten Technologien und Methoden in Hinblick auf die Zielsetzung dieser Arbeit analysiert und die Regeln und Bedingungen für die constraintbasierten Refaktorisierungen zum einen für die Modelle und zum anderen für den Code und für die Transformation des Modells in Code definiert. Darauf aufbauend werden in Kapitel 4 die Konzeption und Implementierung des Eclipse Plugins behandelt, in denen die in Kapitel 2 vorgestellten Technologien Eclipse Language Toolkit, EMF, MDT und Refacola Verwendung finden und die Analysen aus Kapitel 3 integriert werden. Das Plugin wird im Kapitel 5 anhand von Beispiel-Projekten evaluiert. Die Arbeit schließt mit dem Gesamtfazit ab, in dem die Ergebnisse der Evaluierung erörtert und die der gesamten Arbeit zusammengefasst werden. Zudem werden mögliche Erweiterungen des Plugins aufgezeigt und ein Ausblick bzgl. der Refaktorisierung in der modellgetriebenen Entwicklung gegeben.

15 3 2. Grundlagen / Verwandte Arbeiten In diesem Kapitel werden die theoretischen Grundlagen sowie der Bezug zu bestehenden Arbeiten im Umfeld Refaktorisierung und modellgetriebener Softwareentwicklung erörtert, auf dessen Basis die weiteren Kapitel aufbauen Refaktorisierung Die erste tiefergehende Auseinandersetzung mit Refaktorisierung ist von William F. Opdyke im Rahmen der Dissertertation Refactoring Object-Oriented Frameworks durchgeführt worden. Nach Opdyke handelt es sich bei einer Refaktorisierung um die Reorganisationen einer Software im mittleren Umfang wobei das Verhalten eines Programms durch eine Refaktorisierung nicht geändert wird. 1 Fowler definiert eine Refaktorisierung als einen Prozess, in dem die interne Struktur eines Software-Systems verbessert, das Verhalten des Software-Systems nach außen aber nicht verändert wird, um die Verständlichkeit des Programm-Codes zu erhöhen. 2 Motivation für eine Refaktorisierung sind unter anderem die sogenannten Code Smells (wie bspw. zu lange Methoden oder zu große Klassen) 3, die im Rahmen eines Software- Entwicklungsprozess entstehen, wenn Erweiterungen an einem bestehenden Programm realisiert werden, dabei aber die notwendigen Anpassungen zur Beibehaltung und Verbesserung der Wartbarkeit nicht durchgeführt werden. In diesem Zusammenhang wird auch von Softwarefäulnis gesprochen. 4 Fowler katalogisiert die verschiedenen Refaktorisierungen in Methoden- und Datenorganisation, Vereinfachung von Bedingungen und Einsatz von Generalisierung. 5 Der generelle Aufbau einer Refaktorisierung setzt sich dabei aus einer textuellen Beschreibung der durchzuführenden Refaktorisierungsschritte, den Vorbedingungen und den Nachbedingungen zusammen. 6 Bspw. darf beim Verschieben einer Eigenschaft oder Methode diese nicht mit gleichen Namen bzw. Signatur in der Zielklasse existieren. Die Nachbedingungen repräsentieren den Zielzustand nach Durchführung der Refaktorisierung. Programme, die eine Refaktorisierung automatisiert durchführen, werden auf Ebene der Metaprogramme eingeordnet, da andere Programme (in diesem Fall die das zu refaktorisierende Programm) als Eingabe dienen. Fowler nennt folgende Kriterien für ein Refaktorisierungsprogramm: 7 Programm-Datenbank, um Programmelemente und Referenzen auf Elemente innerhalb eines Programms suchen zu können Zugriff auf den Syntaxbaum, um Änderungen an Eigenschaften von Programmelementen, die im Zuge einer Refaktorisierung notwendig sind, durchführen zu können; Bei dem Syntaxbaum handelt es sich um eine strukturelle Abbildung von Programmelementen und deren Eigenschaften; Der Abstract Syntax Tree (AST) 1 vgl. (Opdyke 1992) S. 2 2 vgl. (Fowler 2000) S. 9, S vgl. (Fowler 2000) S vgl. (Steimann 2010) S vgl. (Fowler 2000) S. 9 6 vgl. (Opdyke 1992) S vgl. (Fowler 2000) S. 401ff

16 2.1 Refaktorisierung 4 ist dabei eine Option der Quellcodeanalyse und dessen strukturelle Abbildung Akkuranz (Genauigkeit) bei der Anwendung einer Refaktorisierung, damit das definierte Verhalten einer Software nicht geändert wird. Es können aber auch andere Kriterien für die Akkuranz angegeben werden, bspw. dass sich die Geschwindigkeit eines Programms durch eine Refaktorisierung nicht minimiert; Akkuranz impliziert ebenfalls, dass die Vor- und Nachbedingungen eingehalten werden Effizienz der Refaktorisierung Möglichkeit, Refaktorisierungen zu widerufen (Annullierung) Integration mit anderen Tools, wie bspw. eine Integrierte Entwicklungsumgebung In Hinblick auf die modellgetriebene Entwicklung (siehe Kapitel 2.2) werden Modelle analog zum Programm-Code ebenfalls als Artefakte betrachtet und sind daher bei Refaktorisierungen miteinzubeziehen. In Kapitel und werden zwei beispielhafte Refaktorisierungen aus dem Katalog von Fowler vorgestellt, die im Rahmen dieser Arbeit aufgrund ihrer unterschiedlichen Komplexitätsgrade für Ko-Refaktorisierungen tiefergehend untersucht werden (äquivalent einer Fallstudie). Bei Ko-Refaktorisierungen handelt es sich um Refaktorisierungen, die gleichzeitig auf mehrere Artefakte unterschiedlicher Sprachen (wie bspw. zum einen ein Klassen-Modell und zum anderen der korrespondierende Code) angewendet werden Rename-Refaktorisierung Bei der Rename-Refaktorisierung handelt es sich um eine der einfacheren Refaktorisierungen. Namen von Programmelementen wie von Feldern/Attributen und Methoden sollen ihre Intention ausdrücken und selbsterklärend sein. 8 In diesem Zuge kann es erforderlich sein, dass in Folge von Erweiterungen Programmelemente umbenannt werden müssen. Elemente müssen unterscheidbar und eindeutig sein. Daher ist als Vorbedingung für diese Refaktorisierung zu prüfen, ob bereits ein Element mit gleichem Namen existiert (bei Methoden ist zusätzlich die Signatur hinzuzuziehen). Wenn dies nicht der Fall ist, kann der Name des Elements geändert werden. Nachbedingung ist, dass das Element selbst und alle Referenzen für dieses Element ebenfalls umbenannt werden. 9 Als Beispiel ist in Abbildung 2.1 aufgrund des Hinzufügens des Attributes accentcolor die Bedeutung des Attributes color anhand des Namens nicht mehr zu erfassen und sollte daher umbenannt werden (bspw. in maincolor ) PullUp-Refaktorisierung PullUp-Refaktorisierungen sind insbesondere in der objektorientierten Programmierung relevant. Hierbei geht es im Kontext der Ober- und Unterklassenbildung darum, Gemeinsamkeiten zu identifizieren, wie bspw. gemeinsame Felder/Attribute und Methoden, die bei bestehenden Unterklassen in die Oberklasse heraufgezogen werden. 10 Hierdurch 8 vgl. (Fowler 2000) S vgl. (Fowler 2000) S vgl. (Fowler 2000) S. 320

17 2.2 Grundlagen der modellgetriebenen Entwicklung 5 Abbildung 2.1.: Beispiel Rename-Refaktorisierung soll eines der Grundprinzipien guter Programmierung gewährleistet werden( Do not repeat yourself ). Als Vorbedingung ist zu definieren, dass die Oberklasse kein Element mit gleichem Namen besitzt (analog zur Rename-Refaktorisierung ist bei Methoden zusätzlich die Signatur hinzuziehen). Zudem sind die Sichtbarkeiten bezüglich der Referenzierungen zu beachten. Nach Abschluss der Refaktorisierung ist das entsprechende Element in der Oberklasse verfügbar und aus der Unterklasse entfernt. 11 In Abbildung 2.2 ist beispielhaft eine Ober-/Unterklassenbeziehung zwischen Vehicle, Car und Truck dargestellt. Das Attribut color ist in der Klasse Car angesiedelt. Da davon auszugehen ist, dass ein Truck ebenfalls eine Farbe hat, bietet es sich an, dass Feld color in die gemeinsame Oberklasse Vehicle zu verschieben. Die besitzende Klasse eines Elements wird auch als Kontext des Elements bezeichnet, der durch die Refaktorisierung revidiert wird. Abbildung 2.2.: Beispiel PullUp-Refaktorisierung 2.2. Grundlagen der modellgetriebenen Entwicklung Model Driven Development Nach Stahl stellt der Terminus modellgetriebener Entwicklung (Model Driven Development, MDD), oder auch modellgetriebene Softwareentwicklung (MDSD) genannt, einen Sammelbegriff für Techniken dar, die aus formalen Modellen automatisiert ausführbare Software generieren. 12. Czarnecki sieht das Ziel von Model Driven Development, dass 11 vgl. (Fowler 2000) S vgl. (Stahl u. a. 2007) S. 11

18 2.2 Grundlagen der modellgetriebenen Entwicklung 6 jeder relevante Teil eines Software-Systems in einem Modell erfasst wird, wobei das Modell eine abstrakte Repräsentation des Systems verkörpert. Bei Modellen handelt es sich dabei folglich nicht mehr ausschließlich um Artefakte zur Dokumentation, sondern ebenfalls um Artefakte aus denen automatisiert Code-Bestandteile für spezifische Plattformen erstellt werden. 13 Folglich werden abstrakte Eigenschaften einer Applikation von Plattform-spezifischen Eigenschaften getrennt. 14 Um dieses zu erreichen, wird zunächst basierend auf einem Metamodell ein fachliches Modell der Applikation erstellt, das mittels Transformationen in ein Modell und in ausführbaren Programmcode für eine bestimmte Zielplattform überführt wird. Unter Plattform werden in diesem Kontext die Programmiersprache, Framework und verwendete Komponenten gesehen. In der Regel wird auf Basis des generierten Codes individueller Code entwickelt, der sich nicht direkt generieren lässt (bspw. Benutzeroberfläche). 15 Neben der Separation von der technischen Plattform soll durch die Benutzung von Modellen der Softwareentwicklungsprozess optimiert werden und ein größerer Bezug zur Anwendungsdomäne hergestellt werden Domänenspezifische Sprachen Domänenspezifische Sprachen (Domain-specific language, DSL) sind eng mit dem Themenkomplex Model Driven Development verbunden. Bei einer DSL handelt es sich um eine formale Sprache, die auf einen bestimmten Anwendungsbereich zugeschnitten ist. 16 Im Rahmen von Model Driven Development wird das zu erstellende Modell eines Softwaresystems, das später in ausführbaren Code transformiert werden soll, oftmals mittels einer DSL beschrieben. Neben einer DSL existiert auch die Möglichkeit die Modellierung mittels einer universalen Sprache, wie bspw. BPMN oder UML, durchzuführen. 17 Jede DSL basiert auf einem Metamodell (welches wiederum auf einem Meta-Metamodell basiert), das die Syntax und Semantik der Modellelemente vorgibt und somit die Kernelemente der DSL definiert. Die statische Semantik gibt den Rahmen für die Wohlgeformtheit (Well-formedness) und für die Konsistenz eines Modells vor und wird oftmals mittels sogenannten Wohlgeformheit-Regeln spezifiziert. Ein Modell ist wohlgeformt, wenn dieses vollständig die definierten Regeln einhält. Das Metamodell einer DSL wird auch als abstrakte Syntax einer DSL bezeichnet, wohingegen die konkrete Syntax die textuelle oder graphische Ausprägung einer DSL repräsentiert. 18 DSLs unterscheiden sich in externe und interne DSLs. Bei einer internen DSL handelt es sich um eine Sprache, die auf Sprachelemente einer bereits vorhandenen Wirtssprache aufsetzt und somit auch auf dessen Metamodell zurückgreift. Eine externe DSL ist hingegen vollständig neudefiniert und besitzt ihre eigenen Sprachelemente und ein vollständig eigenes Metamodell Model Driven Architecture Der von OMG eingeführte Begriff Model Driven Architecture (MDA) kann als konkreter Ansatz und als Spezialisierung für die modellgetriebene (Software-)Entwicklung betrachtet werden und gibt entsprechende Standards vor. 20. Eines in diesem Rahmen von der 13 vgl. (Czarnecki u. a. 2005) S vgl. (Beydeda u. a. 2005) S vgl. (Stahl u. a. 2007) S. 29ff 16 vgl. (Stahl u. a. 2007), S vgl. (Fröming u. a. 2008) S. 92 ff. 18 vgl. (Stahl u. a. 2007), S. 29f. 19 vgl. (Fowler 2010) S vgl. (Stahl u. a. 2007) S. 36

19 2.2 Grundlagen der modellgetriebenen Entwicklung 7 OMG spezifiziertes Konzept ist die Meta Object Facility (MOF). Abbildung 2.3 veranschaulicht die MOF Ebenen-Architektur. Auf Ebene M3 ist das MOF Meta-Metamodell lokalisiert, dass grundlegende Konzepte wie Klassen und Assoziationen spezifiziert, die für die Beschreibung aller Metamodelle relevant sind. Das UML-Metamodell (Ebene M2) ist eine Instanz des MOF Meta-Metamodells und legt auf Basis des MOF Meta- Metamodells die Sprachelemente von UML fest (vgl. Kapitel 2.3). Auf Ebene M1 werden Systeme mittels UML modelliert. Die daraus instanziierten Objekte repräsentieren die realen Objekte und sind Bestandteil der Ebene M0. Ein Subset von MOF ist Essential MOF (EMOF). Die OMG sieht bei dem MDA Ansatz vor, dass das Metamodell (abstrak- Abbildung 2.3.: OMG MOF Ebenen-Architektur nach (OMG 2011a) S. 20 und (Stahl u. a. 2007) S. 62 te Syntax) von domänenspezifischen Sprachen auf Basis des MOF Meta-Metamodells beschrieben wird (vgl. Kapitel 2.2.2). Dabei muss MOF nicht direkt verwendet werden, sondern die abstrakte Syntax kann bspw. auch mit UML spezifiziert werden, da UML ebenfalls auf MOF basiert (vgl. Abbildung 2.3). MDA sieht verschiedene Perspektiven für eine zu entwickelnde Software vor, die jeweils in einem eigenen Modell beschrieben werden. Das Plattform Independant Model (PIM) stellt ein System aus einer fachlichen Perspektive dar, ohne auf Details der Zielplattform einzugehen. Dieses wird mittels Model-to-Model Transformationen mit weiteren Informationen angereichert und in ein Plattform Specific Model (PSM) überführt, welches den Bezug zu der Zielplattform herstellt (bspw. Java Enterprise). Auf Basis des PSM wird das Modell in ausführbaren Code transformiert. Hierfür wird eine Beschreibung der Zielplattform benötigt, welche in Form eines sogenannten Plattform-Modell modelliert wird. 21 Die entsprechenden Modelle wie PIM und PSM werden dabei auf Basis eines MOF konformen Metamodell erstellt (siehe oben). OMG definiert die Vorgehensweise mit den verschiedenen Modellarten als Muster, wobei aber auch direkte Code-Generierungen aus einem PIM nicht ausgeschlossen werden vgl. (OMG 2003) S vgl. (OMG 2003) S. 3-7

20 2.3 Unified Modeling Language (UML) 8 Wie deutlich wird, sind Modell-zu-Modell Transformationen ein wichtiger Aspekt im MDA Kontext. Für die konkrete Durchführung von Modell-zu-Modell Transformationen sieht MDA den Standard QVT vor, wobei verschiedene Vorgehensweisen herangezogen werden können 23, die in Kapitel detailliert werden Unified Modeling Language (UML) Die Unified Modeling Language (UML) 24 ist von der Object Management Group als visuelle Modellierungssprache definiert, die für die Spezifizierung, Konstruktion und Dokumentation von Artefakten eines Software-Systems angewendet wird. Es handelt sich dabei um eine universelle Sprache, die für verschiedene fachliche und technische Domänen eingesetzt werden kann. 25. Das UML-Metamodell (abstrakte Syntax) wird in zwei Dokumenten spezifiziert, zum einen die Infrastruktur-Spezifikation und zum anderen die Superstruktur-Spezifikation. Abbildung 2.4.: Infrastructure Library Pakete aus (OMG 2011a) S. 12 übernommen In der Infrastruktur Spezifikation werden die grundlegenden Elemente (wie bspw. Classifier und Features) von UML und die Beziehungen zum Meta-Metamodell MOF beschrieben (vgl. Abbildung 2.3, bei dem UML-Metamodell handelt es sich um eine Instanz des MOF Meta-Metamodells). Diese Basiselemente werden in der sogenannten Infrastructure Library zusammengefasst (vgl. Abbildung 2.4). Primitiven Typen sind ebenfalls Bestandteile der Infrastructure Library. Die Elemente in der Superstruktur-Spezifikation spezialisieren die Elemente der Infrastruktur-Spezifikation. Besonders an der Infrastructure Library ist, dass der Kern auch von dem MOF Meta-Metamodell genutzt wird (vgl. Abbildung 2.5), so dass letztendlich sich die Infrastructure Library selbst beschreibt und somit Elemente des UML-Metamodells auch Instanzen der Metaklassen der Infrastructure Library sind. Die Infrastructure Library wird folglich auf M3 als auch auf M2 Ebene verwendet. 26. In der Superstruktur-Spezifikation werden auf Basis der Infrastruktur- Spezifikation alle Modellierungselemente des UML2-Metamodells zusammen mit deren jeweiligen Eigenschaften, Assoziationen und Semantik definiert. Die Modellierungselemente werden nach Spracheinheiten kategorisiert, wobei folgende Einheiten in UML 2.4 existieren: 27 Classes 23 vgl. (OMG 2003) S im Rahmen dieser Arbeit wird auf Version 2.4 referenziert 25 vgl. (OMG 2011a) S vgl. (OMG 2011a) S S vgl. (OMG 2011b)

21 2.3 Unified Modeling Language (UML) 9 Abbildung 2.5.: Gemeinsamer Infrastruktur Kern für UML und MOF aus (OMG 2011a) S. 13 übernommen Components Composite Structures Deployments Actions Activities Common Behaviors Interactions State Machines Use Cases Die Spracheinheiten lassen sich übergeordnet in zwei Gruppen separieren, zum einen, die die Struktur (Classes,Components, Composite Structures, Deployments) und zum anderen, die das Verhalten (Actions, Activities, Interactions, State Machines, Use Cases) eines Systems beschreiben. Die statische Semantik der einzelnen Elemente sind mittels der Object Constaint Language (OCL) beschrieben, so dass anhand dieser die Wohlgeformheit eines UML-Modells geprüft werden kann. Bei OCL handelt es sich ebenfalls um einen Standard der OMG Modell-zu-Modell Transformationen Wie aus den vorherigen Kapiteln deutlich geworden ist, sind Modell-zu-Modell Transformationen ein wichtiger Bestandteil in der modellgetriebenen Entwicklung, beispielsweise für die Überführung des PIM- zu dem PSM-Modell oder zur Umwandlung von Modellen in domänenspezifischer Sprachen. Nach Helsen fungieren Modell-zu-Modell Transformationen dazu, Distanzen zwischen unterschiedlichen Abstraktionsstufen zu überwinden. 29 Transformationen können hinsichtlich des Ausgangsmodells und des Zielmodells differenziert werden, ob diese Modelle jeweils auf dem gleichen oder auf unterschiedlichen 28 vgl. (OMG 2012) 29 vgl. (Stahl u. a. 2007) S. 195

22 2.3 Unified Modeling Language (UML) 10 Metamodellen beruhen. 30 Zur Durchführung von Modell-zu-Modell Transformationen existieren verschiedene Ansätze, wobei generell zwischen imperativ/operational und deklarativen Ansätzen unterschieden wird. Czarnecki schlüsselt die imperativen und deklarativen Ansätze weiter auf und klassifiziert folgende Vorgehen: 31 Direct-Manipulation Ansatz, bspw. über ein bestimmtes Application Interface (API) ein Modell zu erstellen und verändern Relationaler Ansatz, Technologie-Beispiel: QVT/R Graph-Transformationen, Technologie-Beispiel: Henshin Structure-Driven Ansatz / imperativ bzw. operationaler Ansatz, Technologie- Beispiele: QVT/O, Mitra, Kermeta Hybrid-Ansatz, Technologie-Beispiel: ATL Andere Modell-zu-Modell Ansätze, bspw. XSLT Als tiefergehendes Beispiel für einen imperativ bzw. operationalen Ansatz sei Mitra erwähnt 32, bei dem die Transformationslogik einer Modell-zu-Modell Transformation in Transformations-Regeln implementiert wird. Wie in Abbildung 2.6 dargestellt, werden die Transformations-Regeln (mittlere Ebene) mittels der Transformations-Engine für ein konkretes Modell (untere Ebene) angewendet, wodurch die Transformation ausgeführt wird. In den Transformations-Regeln wird dabei auf die durch die jeweilige Metamodelle vorgegebenen Elemente des Ausgangsmodells und des Zielmodells referenziert und definiert, wie die Ausgangselemente zu den Zielelementen verarbeitet werden. Abbildung 2.6.: Zusammenhang von Meta-Metamodell in M2M-Transformationen aus (von Pilgrim 2011) S. 104 übernommen Ein weiterer Aspekt im Kontext der Modell-zu-Modell Transformationen ist das so genannte Tracing, durch das die Transformation eines Ausgangsmodell und Zielmodell und die Beziehungen zwischen den Ausgangselementen und den Zielelementen dokumentiert werden. Im Standard-Glossar für Software Engineering des Instituts of Electrical and Electronics Engineers (IEEE) ist Tracing folgendermaßen definiert: vgl. (Beydeda u. a. 2005) S vgl. (Czarnecki u. Helsen 2003) S. 10ff. 32 vgl. (von Pilgrim 2011) 33 vgl. (IEEE 1990)

23 2.4 Integrierte Entwicklungsumgebungen 11 (1) A record of the execution of a computer program, showing the sequence of instructions executed, the names and values of variables, or both. Types include execution trace, retrospective trace, subroutine trace, symbolic trace, variable trace. (2) To produce a record as in (1). (3) To establish a relationship between two or more products of the development process; for example, to establish the relationship between a given requirement and the design element that implements that requirement. Bezogen auf Modell-zu-Modell Transformationen gelten die Definitionen (1) und (3) gleichermaßen. 34 Das Tracing-Konzept kann ebenso auf Code-Generierungen aus Modellen übertragen werden, indem den Elementen im Ausgangsmodell die generierten Code-Elemente zugeordnet werden. Mitra verfügt über ein Trace-Modell und Traces werden explizit erstellt. Um Tracing für eine Transformation zu aktivieren, sind die betreffenden Transformationsregeln in Mitra mit dem Schlüsselwort mit traced zu versehen. Bei weiteren Ansätzen zur Umsetzung von Tracing werden Traces durch Abfangen von Transformationsereignissen mittels Aspekten generiert (Beispiel ETraceTool) Integrierte Entwicklungsumgebungen Eclipse Plugin-Architektur Eclipse stellt die derzeitig verbreitetste integrierte Entwicklungsumgebung für die Java Entwicklung dar. 36 Neben der Funktion als Entwicklungsumgebung fungiert Eclipse auch als Plattform, auf deren Basis Applikationen und Plugins entwickelt werden können. Plugins erweitern die Entwicklungsumgebung um spezifische Funktionalitäten. Abbildung 2.7.: Eclipse Plugin-Architektur aus (Kehn) übernommen Abbildung 2.7 visualisiert die Architektur der Eclipse-Plattform, aus der deutlich wird, dass alle Standard-Komponenten (wie bspw. die Workbench oder die JFace- Komponenten für die Benutzeroberfläche) und ebenso alle weiteren Plugins auf der Platform-Runtime basieren. Seit Version 3.0 beruht die Runtime von Eclipse auf der OS- 34 vgl. (von Pilgrim 2011) S vgl.(amar u. a. 2008) 36 vgl. (Ueberhorst 2010)

24 2.4 Integrierte Entwicklungsumgebungen 12 Gi Spezifikation (Open Services Gateway initiative). 37, welches ein Modell zur Verfügung stellt, das es erlaubt eine Anwendung in Komponenten (sogenannte Bundles ) zu modularisieren und über eine einheitliche Registrierung zu verwalten. Folglich stellen Eclipse- Plugins ebenso Bundles dar. Plugins bzw. Bundles können dabei auf andere Bundles referenzieren, wenn diese für die Ausführung des Plugins benötigt werden. Die JFace- Komponenten der Eclipse-Plattform stehen folglich auch allen weiteren Plugins zur Realisierung einer Benutzeroberfläche zur Verfügung. Neben dem Java Code eines Plugins besteht ein Eclipse-Plugin aus folgenden Bestandteilen: 38 plugin.xml MANIFEST.MF In der plugin.xml wird unter anderem der Erweiterungspunkt des Plugins bezüglich der Eclipse-Plattform angeben. In der MANIFEST.MF werden die Beziehungen zu anderen Plugins definiert und Metainformationen wie bspw. Name des Bundles/Plugins festgelegt. Wie aus Abbildung 2.7 deutlich wird, sind die Plugins Plattform Development Environment (PDE) und Java Development Tools (JDT) für die Entwicklung von Java- Programmen standardmäßig integriert. Mit den Java Development Tools besteht die Möglichkeit auf den Abstrakten Syntaxbaum eines Java Programms zuzugreifen, wobei die einzelnen Elemente der Java-Sprachdefinition wie Klassen, Methoden und Felder jeweils als Klassen mit den entsprechenden Eigenschaften Programmelemente modelliert sind. 39 Bei einem konkreten Java-Programm werden die Elemente des Programm folglich als Objekte dieser Klassen instanziiert. Abbildung 2.8 zeigt einen beispielhaften Syntaxbaum auf Basis der JDT Abbildung 2.8.: Beispiel für ein AST Eclipse Language Toolkit (LTK) Für Refaktorisierungs-Plugins offeriert Eclipse bereits mit dem Eclipse Language Toolkit (LTK) ein Rahmenwerk, das ebenfalls als OSGi Bundle zur Verfügung steht. Zentrale Bestandteile sind die abstrakten Klassen Refactoring und Change 40, die durch Ableitung 37 vgl. (Clayberg u. Rubel 2008) S vgl. (Clayberg u. Rubel 2008) S vgl. (EclipseFoundation 2013) 40 vgl. (Frenzel 2006)

25 2.4 Integrierte Entwicklungsumgebungen 13 jeweils spezifisch implementiert werden können. Die Klasse Refactoring stellt die Implementierung einer Refaktorisierung dar, wobei diese optional in Processor / Participants weiter unterteilt werden kann (vgl. Abbildung 2.9) 41. In der Refaktorisierung-Implementierung werden auf Basis der aus der Benutze- Abbildung 2.9.: Bestandteile des LTK-Plugins für Refaktorisierungen aus (Petito 2007) übernommen roberfläche vorgegebenen Parameter und des zu refaktorisierenden Elements unter Berücksichtigung des in Abbildung 2.7 skizzierten Lebenszyklus nach Überprüfen der initialen und finalen Bedingungen, welche zusammen die Vorbedingungen ergeben, die Änderungen berechnet. Bei den initialen Bedingungen handelt es sich um die Bedingungen, die bereits ohne weitere Informationen, bspw. durch die von dem Benutzer eingegeben werden, überprüft werden können. Sobald die weiteren Informationen zur Verfügung stehen, werden die finalen Bedingungen verifiziert. Die Änderungen werden durch ein Change-Objekt repräsentiert, die bei Anwendung bspw. bei einem JDT-Change die Anpassungen für die Refaktorisierung auf dem Syntaxbaum ausführen. Ein Change kann dabei aus mehreren Changes bestehen (vgl. Abbildung 2.9) und bietet Methoden zum Erstellen eines Undo-Changes, um Änderungen wieder rückgängig zu machen. Abbildung 2.10.: Zyklus einer Refaktorisierung im LTK-Rahmenwerk aus (Petito 2007) übernommen 41 vgl. (Petito 2007), S. 3

26 2.5 Eclipse Modeling Project Eclipse Modeling Project Eclipse Modeling Framework (EMF) Das Eclipse Modeling Framework (EMF) als Teil des Eclipse Modeling Project stellt ein Modellierungs-Rahmenwerk auf Eclipse-Basis dar. Es wird als Eclipse-Plugin eingebunden, 42, mit dem ausgehend von strukturierten Modellen Java-Code erzeugt werden kann. EMF kann somit als Rahmenwerk und Werkzeug für die modellgetriebene Softwareentwicklung betrachtet werden. EMF adaptiert das MOF-Konzept der OMG und definiert für die Beschreibung von Modellen ein Meta-Metamodell, welches Ecore genannt wird. EMF/Ecore realisiert nicht die gesamte MOF-Spezifikation, sondern ein Subset dieser (EMOF) 43. Die Eclipse Modeling Tools-UML2 (MDT-UML2) sind eine Erweiterung des Eclipse Modeling Frameworks und setzen auf dem Ecore Meta-Metamodell auf, so dass das UML-Metamodell folglich mit dem Ecore Meta-Metamodell beschrieben ist (vgl. Abbildung2.11). 44 Die Eclipse Modeling Tools für UML2 stellen auf Basis des Ecore Meta- Metamodells eine Java-Implementierung des UML2-Metamodells bereit, welches analog zu den Java Development Tools zu sehen ist und den Zugriff auf die Struktur eines UML-Modells erlaubt. Abbildung 2.11.: OMG MOF Ebenen-Architektur im EMF Kontext nach (OMG 2011a) S. 2-3 und (Stahl u. a. 2007) S Code-Generatoren EMF Code-Generator Der EMF Code-Generator ist Bestandteil des Eclipse Modeling Frameworks und ist ebenfalls in Eclipse als Plugin integriert. Ausgehend von einem auf Ecore basierenden Modell 42 vgl. (Steinberg u. a. 2009), S vgl. (OMG 2013), S vgl. (Steinberg u. a. 2009), S. 127

27 2.5 Eclipse Modeling Project 15 (wie UML) wird dieses zunächst importiert und in ein Ecore-Modell transformiert. Parallel wird das sogenannte EMG Generator Model (GenModel) erstellt (vgl. Abbildung 2.12). Das GenModel-Modell referenziert auf die im Ecore-Modell enthaltenen Classifier und erweitert das Modell um ausschließlich für die Code-Generierung benötigen Informationen. Das GenModel-Modell dekoriert folglich das Ecore-Modell und dient als Basis für die Code-Generierung. 45 In das GenModel-Modell fließen ebenfalls Eigenschaften in Abbildung 2.12.: Code-Generierung mit EMF Code-Generator Form von so genannten genannotations ein, die je nach Ausgangsmodell unterschiedlich sind. Bei einem UML-Modell ist dies bspw. wie mit Subsetting and Redefinition (vgl. Abbildung 2.13) umgegangen werden soll. Subsetting ist in der UML-Superstruktur vorgesehen (vgl. Kapitel 2.3), um zu spezifizieren, wenn Instanzen dieses Attributes einer Untermenge von Instanzen eines anderen Attributes im selben Kontext ausdrücken. Mit Redefinition können Assoziationen in Generalisierungsbeziehungen in einer Unterklasse in Bezug auf eine Assoziation/Eigenschaft der Oberklasse neu definiert werden, wobei die redefinierte Eigenschaft bestimmten Regeln folgen muss (es darf bspw. ausschließlich eingeschränkt werden). Definiertes Verhalten in UML-Modellen bspw. in State Machines Abbildung 2.13.: Code-Generierung mit UML-Modell als Ausgangsbasis wird bei der Code-Generierung ignoriert. Intern werden im EMF Code-Generator Java Emitter Template (JET) für die Code-Generierung verwendet. Folgende Artefakte werden durch den EMF Code-Generator erzeugt: Interfaces für die einzelnen Entitäten (Klassen), die im UML-Modell angelegt sind 45 vgl. (Steinberg u. a. 2009), S. 28

28 2.5 Eclipse Modeling Project 16 Factory-Interface, welches Methoden zum Instanziieren der Entitäten anbietet Package-Interface, welches Zugriffsmethoden auf die Ecore Meta Objekte der einzelnen Entitäten (inklusive der jeweiligen Attribute) anbietet und für jede Entität und Attribut eine ID als statische Konstante enthält (Object-IDs für Entitäten und Feature-IDs für Attribute) Klassen für die Implementierung der einzelnen Entitäten Implementierung des Factory-Interfaces Implementierung des Package-Interfaces Die erzeugten Interfaces und Klassen leiten von Interfaces und Klassen des EMF- Frameworks ab, so dass der erzeugte Code abhängig vom EMF-Framework. Der erstellte Code wird gewöhnlich um manuell codierte Bestandteile erweitert. In der Regel erfolgt dies dadurch, dass manuell geschriebene Komponenten und Klassen auf den generierten Code referenzieren, wobei das EMF-Framework es auch zulässt im generierten Code selbst Anpassungen durchzuführen. Dies wird dadurch ermöglicht, dass erzeugte Bestandteile während der Code-Generierung mit versehen werden und somit von manuell erstellten Code differenziert werden können. 46 Des weiteren bietet der EMF Code-Generator neben der Erzeugung des Modell-Code (zu diesem auch die oben genannten Factory- und Package-Classifier gehören) die Möglichkeit Editoren für die graphische Oberfläche in Form eine Eclipse-Plugins zu generieren, mit denen Instanzen des Modells angelegt und verwaltet werden können. Acceleo Bei Acceleo handelt es sich um ein Code-Generator der Firma Obeo, der den MDA-Ansatz der OMG realisiert. 47. Abbildung 2.14 veranschaulicht den Code- Generierungsprozess mit Acceleo. In den Modulen, die im Acceleo-Kontext in Form von Model-to-text (MTL) Dateien erstellt werden, werden die Vorlagen für die Code- Generierung (Templates) definiert (ähnlich Xpand 48 ). In diesen wird letztendlich beschrieben, was aus den Elementen im UML-Modell an Code generiert werden soll. Die Module sind folglich technologieabhängig verfasst. Die Acceleo Engine generiert letztendlich aus den UML-Modellen und den Modulen/Templates den Code. Bezogen auf MDA wird somit direkt aus einem PIM-Modell Code erzeugt. Acceleo ist als Eclipse-Plugin verfügbar, so dass direkt aus der Entwicklungsumgebung die Code-Generierung initiiert werden kann. Des weiteren bietet Acceleo Module/Templates, bspw. für Java, die standardmäßig bei der Code-Generierung in Acceleo verwendet werden. Es können aber ebenso individuelle Module/Templates erstellt werden. Bei den von Acceleo generierten Java-Klassen handelt es sich standardmäßig im Kontrast zu den mittels EMF Generator erzeugten Klassen um sogenannte Plain old java objects, d. h., dass diese keine Abhängigkeiten zu externen Frameworks haben. Listing D.1 zeigt beispielhaft ein Modul mit Template, mit dem aus einem Interface in einem UML-Modell ein Java-Interface erzeugt wird. Darüber hinaus bietet Acceleo Tracing, d. h. bei jedem Code-Generierungsvorgang werden Traces erzeugt, in der die Beziehungen zwischen Model und dem generierten Code dokumentiert werden. 46 vgl. (Steinberg u. a. 2009), S vgl. (Acceleo 2013) 48 vgl. (Xpand 2013)

29 2.6 Constraintbasierte Refaktorisierungen 17 Abbildung 2.14.: Code-Generierung mit Acceleo 2.6. Constraintbasierte Refaktorisierungen Für die Realisierung und Durchführung von Refaktorisierungen existieren mehrere Ansätze. In klassischen Ansätzen, so wie sie auch bei den Eclipse Refaktorisierungs- Plugins Anwendung finden, werden die Vorbedingungen und die einzelnen Schritte der Refaktorisierung imperativ formuliert. Hierbei liegt die Verantwortung darin, dass die Refaktorisierung korrekt durchgeführt und die Bedeutung eines Programms nicht verändert wird, was ebenfalls inkludiert, dass es nach der Refaktorisierung nicht zu Kompilierungsfehlern kommt, in der imperativen Implementierung des Refaktorisierungsprogramms. Bei constraintbasierten Refaktorisierungen, die zunächst unter anderem in Abhandlungen zu Refaktorisierungen von Generalisierungen von Tip untersucht worden sind 49, wird hingegen das zu refaktorisierende Programm in ein Constraint-Satisfaction-Problem (CSP) transformiert und folgt daher einem deklarativen Ansatz. 50 Bei einem Constraint-Satisfaction-Problem (dt.: Bedingungserfüllungsproblem, abgekürzt CSP) handelt es sich dabei um eine Problemstellung aus dem Bereich der künstlichen Intelligenz 51. Ein CSP besteht dabei vereinfacht aus einer Menge von Variablen und einer Menge von Constraints. 52 Ein Constraint ist eine logische Bedingung, die hinsichtlich der Wertebelegung der Variablen einzuhalten ist. Mithilfe der constraintbasierten Programmierung, die als Erweiterung der logischen Programmierung betrachtet werden kann, können direkt CSPs formuliert werden, die auf Basis eines sogenannten Constraint-Solvers gelöst werden. Hier wird mit Hilfe verschiedener Verfahren, wie bspw. Backtracking, solange eine Lösung gesucht, bis das CSP mit gültigen Variablenbelegungen erfüllt ist. Wenn alle möglichen Belegungen der Variablen geprüft worden sind und keine passende Belegung gefunden wird, mit denen die Constraints erfüllt werden, existiert keine Lösung für das CSP. In Bezug auf die constraintbasierte Refaktorisierung stellen die Eigenschaften der Programmelemente, wie bspw. der Name einer Methode, die Constraint-Variablen dar. Um Constraints und Constraint-Variablen zur Laufzeit erzeugen, werden zur Entwicklungszeit sogenannte Constraint-Regeln definiert, welche folgendermaßen aufgebaut sind: vgl. (Tip u. a. 2003) 50 vgl. (Steimann 2011) S vgl. (Ghedira 2013) S vgl. (Ghedira 2013) S vgl. (Steimann u. a. 2011) S. 5

30 2.6 Constraintbasierte Refaktorisierungen 18 Queries Constraints (2.1) Bei einer Query handelt es sich um einen logischen Ausdruck mit Platzhaltern zur Abfrage von Fakten aus dem zu refaktorisierenden Artefakt. Während der Anwendung der Regel werden diese Platzhalter durch die konkreten Programmelemente des zu refaktorisierenden Dokumentes ersetzt und ermittelt, ob das Faktum für die eingesetzten Programmelemente zutrifft. Für die mittels dieser Abfragen identifizierten Programmelemente werden die im Nenner angegebenen Constraints generiert. Um die Queries/Abfragen durchzuführen ist eine entsprechende Programm-Datenbank und ein Zugriff auf den abstrakten Syntaxbaum erforderlich (vgl. Kapitel 2.1). Dieser ist des Weiteren notwendig, um die Lösung des Refaktorisierungsproblems auf den AST des Programms zu übertragen und somit die Refaktorisierung zu finalisieren. 54 Die Constraint-Regel in 2.2 veranschaulicht dieses Prinzip. binds(f ieldref erence, f ield) f ieldref erence.name = f ield.name (2.2) Durch diese Constraint-Regel wird bspw. in einem Java-Programm für jede Feldreferenz (fieldreference-platzhalter in der Constraint-Regel) die auf ein bestimmtes Feld (field-platzhalter) zeigt und an dieses gebunden ist, ein Constraint generiert, durch den bedingt wird, dass der Name der Feldreferenz gleich dem Namen des Feldes ist, was insbesondere für Rename-Refaktorisierungen relevant ist. Da jedes Aufkommen von Elementen in einem Programm, für die der Query-Ausdruck zutrifft, berücksichtigt wird, wird deutlich, dass Constraint-Regeln implizit allquantifiziert sind. Darüber hinaus ist bei constraintbasierten Refaktorisierungen die Refaktorisierungsintention anzugeben, da per se jede Belegung des CSP valide ist, wenn diese die generierten Constraints erfüllen. 55 Durch die Refaktorisierungsintention wird spezifiziert, welche Eigenschaft durch eine bestimmte Refaktorisierung zwingend geändert wird und variabel ist. Zudem werden die Eigenschaften spezifiziert, welche geändert werden dürfen, wodurch indirekt die Menge der konstanten Eigenschaften bekannt ist und die Menge der zu generierenden Constraints entsprechend optimiert und minimiert werden kann. Am Beispiel der Rename-Refaktorisierung ist der Name eines Attributs oder eine Methode die zwingend zu ändernde Eigenschaft, welche durch den Benutzer vorgegeben wird. In diesem Zuge sind die Namen der jeweiligen Methoden- und Attributreferenzen entsprechend anzupassen und als erlaubte Änderung zu definieren. Analog gilt die für die PullUp-Refaktorisierung, bei der der Besitzer eines Attributs oder Methode als intendierend zu ändernde Eigenschaft zu betrachten ist. Es kann hierbei erforderlich sein, die Sichtbarkeit des Attributs oder Methode anzupassen, was je nach Intention des Benutzers als erlaubte Änderung spezifiziert werden kann. Die zur Laufzeit instanziierten Eigenschaften haben einen Wertebereich, der auch Domäne (Domain) bezeichnet wird. Der Bereich der möglichen Werte, die eine Eigenschaft nach Lösen des CSPs haben soll, wird auch Codomäne (Codomain) genannt und kann die gesamte Ausgangsdomäne präsentieren, eine Teilmenge dieser darstellen oder neue Werte dem Wertebereich hinzufügen.

31 2.6 Constraintbasierte Refaktorisierungen 19 Abbildung 2.15.: Übersicht Refacola aus (Steimann u. a. 2011) S. 13 übernommen Refacola Refacola ist ein domänenspezifische Sprache und zugleich ein Framework zur Realisierung von constraintbasierten Refaktorisierungen, welches an der Universität Hagen entwickelt worden ist. Mittels der domänenspezifschen Sprache Refacola werden zur Entwicklungszeit der jeweiligen Refaktorisierungswerkzeuge die Sprachdefinition für die Artefakte, auf welche das Refaktorisierungswerkzeug angewendet werden soll (wie bspw. Java- Programme etc.), die Regeldefinition zu dieser Sprache und die sprachabhängige Refaktorisierungsdefinition selbst formuliert. 56 Auf Basis dieser Refacola-Dokumente werden die Refaktorisierungswerkzeuge mit dem Refacola-Compiler gewöhnlich in Java generiert (linke Seite in Abbildung 2.15). In der Refacola-Sprachdefinition werden folgende Aspekte zu einer Sprache wie bspw. Java oder auch UML in Syntax der Refacola-DSL spezifiziert: Kinds (Sprachelemente, wie bspw. Klasse oder Methode in Java) Properties (Eigenschaften zu Sprachelementen, wie bspw. Name einer Methode) Domains (Wertebereiche der jeweiligen Eigenschaften) Queries (Faktenabfragen, wie bspw. alle Methoden zu einer Klasse in Java) Wie im vorherigen Kapitel dargestellt dienen die Constraint-Regeln zur Erzeugung der Constraints und der Constraint-Variablen, die in Refacola in der Regeldefinition als Regelmenge definiert werden und sicherstellen, dass ein Programm durch eine Refaktorisierung nicht invalide und unkompilierbar wird bzw. die Refaktorisierung im entsprechenden Fall zurückgewiesen wird. 57 In der Refaktorisierungsdefinition wird die Intention der Refaktorisierung festgehalten (siehe vorheriges Kapitel) und welche Eigenschaften durch diese Refaktorisierung geändert werden dürfen. Zudem wird definiert welche Regelmengen für diese Refaktorisierung gelten 58 Zusammengefasst besteht ein Refacola-Programm folglich aus den Einheiten Sprachdefinition, Regeldefinition mit den Constraint-Regeln und Refaktorisierungsdefinition. Das daraus generierte Refaktorisierungsprogramm basiert dabei auf der Refacola-API 54 vgl. (Steimann u. a. 2011) S vgl. (Steimann u. a. 2011) S. 6f. 56 vgl. (Steimann u. a. 2011) S vgl. (Steimann u. a. 2011) S. 11 f. 58 vgl. (Steimann u. a. 2011) S. 12

32 2.6 Constraintbasierte Refaktorisierungen 20 des Refacola-Frameworks (rechte Seite in Abbildung 2.15). Listing veranschaulicht auszugsweise diese Module für Java. language Java kinds abstract Entity <: ENTITY abstract MethodOrConstructor <: MemberOrConstructor { parameters } abstract Field <: HideableMember, TypedEntity... queries binds(reference: NonTypeReference, entity: Entity) overrides(overridingmethod : InstanceMethod, overriddenmethod: InstanceMethod) ruleset Names languages Java rules ReferenceIdentifier for all reference: Java.NamedTypedReference entity: Java.NamedEntity do if Java.binds(reference, entity) then reference.identifier = entity.identifier end refactoring RenameMember languages Java uses Accessibility, Types, Names, Locations, Reflection forced changes identifier of Java.NamedEntity as NewName allowed changes identifier of Java.NamedReference {initial, forced}... Listing 2.1: Beispielhafte Refacola-Module für Java in der Refacola-DSL Die aus diesen Refacola-Dokumenten mittels des Refacola-Compilers generierten Refaktorisierungsprogramme basieren auf der Refacola API (vgl. de.feu.ps.refacola.api in Abbildung 2.16), die den Kern des Refacola-Frameworks repräsentiert. Zur Lösung eines Refaktorisierungsproblems wird an die Solver-Komponente delegiert (vgl. de.feu.ps.refacola.solver in Abbildung 2.16) Abbildung 2.16.: Refacola-Komponentenarchitektur 59 aus FernUniversität Hagen Clare Subversion Repository übernommen

33 2.6 Constraintbasierte Refaktorisierungen 21 Um die Constraints für ein konkret zu refaktorisierendes Artefakt/Programm zu generieren sind die Faktenabfragen in den Constraint-Regeln auf diesem Artefakt durchzuführen, welches mittels eines sogenannten Info-Providers durchgeführt wird, der vergleichbar mit einer Programm-Datenbank ist, und dessen Basisimplementierung in der Refacola API-Komponente lokalisiert ist. Im Info-Provider wird auch die Logik für die Übersetzung der in Refacola und durch das Constraint-Solving ermittelten Änderungen in die native Change-Objekte der jeweiligen Umgebung bzw. Plattform implementiert (Writing Back Komponente). Für Refacola existiert bereits eine Umsetzung eines Info-Providers zur Abfrage von Java-Programmen, welcher auf den Java Development Tools basiert und per AST (vgl. Abbildung 2.15 rechts) auf das jeweilige Programm zugreift (vgl. de.feu.ps.refacola.lang.java und de.feu.ps.refacola.lang.java.jdt in Abbildung 2.16). Zudem ist in Refacola ein generischer Info-Provider für den Zugriff auf Modelle, die mit dem Ecore Meta-Metamodell beschrieben sind, implementiert (vgl. de.feu.ps.refacola.ecore in Abbildung 2.16). Basierend auf den generierten Constraints und den Eigenschaften (Constraint-Variablen) der Programmelemente, deren Wertebereiche für den Solving-Prozess Integer-Werten zugeordnet werden, löst der Constraint-Solver (rechte Seite in Abbildung 2.15 bzw. de.feu.ps.refacola.solver in Abbildung 2.16) das Refaktorisierungsprogramm. Wenn eine Lösung für das Refaktorisierungsproblem gefunden wird, wird diese durch den Solver zurückgegeben. Der gesamte Prozess der Constraintgenerierung ausgehend von den Constraint-Regeln bis zum Lösen des Refaktorisierungsproblem in Refacola ist in B.1 abgebildet. Wenn eine Constraint-Überprüfung aufgrund bestimmter Limitation, bspw. bei Text- Operationen, nicht direkt im Constraint-Solver erfolgen kann, kann die Überprüfung an externe Klassen delegiert werden, die das IConstraintChecker-Interface implementieren. Diese sind als sogenannte Functions (Bestandteil der Refacola-DSL) in der jeweiligen Refacola-Sprachdefinition zu registrieren und können dann in der Definition der Constraint-Regeln verwendet werden. Zudem ist es in Refacola möglich, die Zielwertebereiche (Codomäne) für die in der Refaktorisierungsdefinition angegebenen änderbaren Eigenschaften durch externe Java-Klassen zu generieren, welche das IGenerator-Interface implementieren. Diese beiden Interfaces sind ebenfalls Bestanteil der Refacola API-Komponente Überführung von Wohlgeformtheit-Regeln zu Constraint-Regeln Wie in Kapitel dargelegt ist die statische Semantik von universellen und domänenspezifischen Sprachen oftmals in Wohlgeformheit-Regeln spezifiziert, die folglich bei Anwendung von Refaktorisierungen auf Artefakte, die in dieser Sprache verfasst sind, einzuhalten sind. Die Transformation dieser Wohlgeformheit-Regeln in Constraint-Regeln für constraintbasierte Refaktorisierungen ist in (Steimann 2013) erörtert worden. Da keine weitere Ansätze existieren 60, die diese Problematik ebenfalls adäquat adressieren, wird im Rahmen dieser Arbeit detailliert auf diesen Ansatz eingegangen. Der Ausdruck 2.3 zeigt exemplarisch eine Wohlgeformheit-Regel in erster Prädikatenlogik, welche aussagt, dass jedes Attribut in einem Artefakt einen Besitzer und einen Namen haben muss: p properties : p.owner > 0 p.name > 0 (2.3) 60 vgl. (Steimann 2013) S. 2

34 2.6 Constraintbasierte Refaktorisierungen 22 Ein Aspekt zur Überführung von Wohlgeformtheit-Regeln zu Constraint-Regeln ist der Umgang mit Quantoren, welche in den Wohlgeformtheit-Regeln enthalten sind. Wie in Kapitel 2.6 konstatiert sind Constraint-Regeln implizit allquantifiziert. Wenn in einer Wohlgeformtheit-Regel Allquantoren enthalten sind, sind diese allquantifizierten Ausdrücke für die Transformation folglich zunächst auf die linke Seite zu bewegen und dann als Bestandteil der Query einer Constraint-Regel zu betrachten. 61 Existenzquantoren in Wohlgeformtheit-Regeln deuten hingegen auf eine Unterspezifizierung der statischen Semantik der jeweiligen Sprache hin, welche durch Skolem-Funktionen eliminiert werden können. 62 Skolemisierung kann als virtuelles Hinzufügen einer weiteren Assoziation im zugrundeliegenden Metamodell betrachtet werden, um das Metamodell weiter zu spezifizieren und die semantische Unterspezifizierung aufzuheben. 63 Bei der Überführung von Wohlgeformtheit-Regeln zu Constraint-Regeln sind Existenzquantoren dementsprechend für die Bedeutungserhaltung durch Skolemisierung zu entfernen. Wenn dies nicht möglich ist, ist der existenzquantifizierte Ausdruck für jedes Element auszurollen, was jedoch dazu führen kann, dass die Bedeutung des Modells nach Durchführung der Refaktorisierung nicht mehr der Intuition des Benutzers entspricht, obwohl die Bedeutung aus technischer Sicht erhalten bleibt. 64 Darauf aufbauend sind die weiteren Elemente der Wohlgeformtheit-Regel in die Constraint-Regel zu übertragen und dem Query- und dem Constraint-Teil einer Constraint-Regel zuzuordnen. Generell sind Constraint-Regeln bis zu einem bestimmten Punkt unabhängig von der jeweiligen Refaktorisierung. 65, wobei diese abhängig von den konstanten und variablen Eigenschaften einer Refaktorisierung, die sich aus der Refaktorisierungsintention ergeben (vgl. Kapitel 2.6), umgeschrieben werden können, was für die Transformation von Wohlgeformtheit-Regeln zu Constraint-Regeln adaptiert werden kann. Queries dürfen ausschließlich Ausdrücke mit Eigenschaften enthalten, die durch die jeweilige Refaktorisierung nicht geändert werden, so dass diese zur Anwendungszeit der Regel bei der Constraintgenerierung ausgewertet werden können, wohingegen der Constraint-Teil die Bedingungen mit variablen Eigenschaften besitzt, die bei Lösen des Refaktorisierungsproblem mit Werten belegt werden. Für die Transformation von Wohlgeformtheit-Regeln in Constraint-Regeln sind daher die konstanten und variablen Eigenschaften je nach Refaktorisierung zu seperarieren und auf Basis dieser Unterteilung die weitere Ableitung der Constraint-Regel vorzunehmen. 66 Bezogen auf das Beispiel 2.3 ist die name-eigenschaft in Hinblick auf Rename-Refaktorisierungen variabel und Bestandteil des Constraints (Nenner der Constraint-Regel), wohingegen die owner- Eigenschaft konstant und somit Teil der Query ist. Der Ausdruck 2.4 visualisiert die abgeleitete Constraint-Regel 2.3 für Rename-Refaktorisierungen: p properties p.owner > 0 p.name > 0 (2.4) Des Weiteren sind die Variablen in Wohlgeformtheit-Regeln auf Wertesemantik abzubilden, da diese Referenzsemantik besitzen können, aber ein Constraint-Solver bei constraintbasierten Refaktorisierungen ausschließlich mit Wertesemantik umgehen kann. Zudem sind Indirektionen aufzulösen (Verkettung von Variablen/Eigenschaften) und Variablen mit höheren Multiplizitäten als eins auf Constraint-Variablen mit Mengen- Wertebereichen abzubilden vgl. (Steimann 2013) S vgl. (Steimann 2013) S vgl. (Steimann 2013) S vgl. (Steimann 2013) S vgl. (Steimann 2013) S vgl. (Steimann 2013) S. 19f. 67 vgl. (Steimann 2013) S. 20 ff.

35 2.7 Bestehende Ansätze für Modell-Refaktorisierungen Bestehende Ansätze für Modell-Refaktorisierungen Im Bereich der Modell Refaktorisierungen sind bereits mehrere Ansätze erarbeitet, wobei im Folgenden auf zwei Vertreter näher eingegangen wird. Die beiden Vertreter sind ausgewählt, da sie sich jeweils konzeptionell unterscheiden. Bei GenericMT werden Refaktorisierungen auf M3 Ebene definiert, wohingegen bei EMF Refactor dies auf Ebene M2 erfolgt Generic Model Refactorings (GenericMT) Abbildung 2.17.: Übersicht GenericMT aus (Moha u. a. 2009) S. 635 übernommen GenericMT ist vom IRISA-Institut konzipiert worden und hat den Anspruch Refaktorisierungen unabhängig von der jeweiligen Sprache bzw. des Metamodells zu spezifizieren. 68 Um dieses zu erzielen wird ein generisches gemeingültiges Meta-Metamodell, welches mit dem MOF Meta-Metamodell vergleichbar ist und die Basiskonzepte der konkreten Metamodelle zusammenfasst, definiert (vgl. Abbildung 2.17). Auf Basis dieses Metamodells werden die Refaktorisierungen generisch mit Kermeta spezifiziert (vgl. Abbildung 2.18 für PullUp-Refaktorisierung). 69 Bei Kermata handelt es sich zum einen Abbildung 2.18.: GenericMT PullUp Refaktorisierung aus (Moha u. a. 2009) S. 636 übernommen um eine Meta-Sprache zur Definition von (Meta-)Modellen und ist in dieser Hinsicht 68 vgl. (Moha u. a. 2009) S vgl. (Moha u. a. 2009) S. 635

36 2.7 Bestehende Ansätze für Modell-Refaktorisierungen 24 mit Ecore vergleichbar, zum anderen repräsentiert es eine Modell-zu-Modell Transformationssprache. In GenericMT werden Refaktorisierungen folglich als operationale Modelltransformationen realisiert. Die Vorbedingungen für eine Refaktorisierung werden ebenfalls zusammen mit der Durchführungsbeschreibung generisch spezifiziert. Damit eine generisch spezifizierte Refaktorisierung auf ein konkretes Artefaktes, welche Instanz eines bestimmten Metamodells ist, angewendet und durchgeführt werden kann, sind Adaptionsaspekte zu beschreiben (vgl. Abbildung 2.19 für das UML-Metamodell), die das konkrete Metamodell in das generische Modell abbilden. 70 Die Java-Sprache wird ebenfalls als Metamodell aufgefasst, welches ebenfalls in Form eines Adaptionsaspektes für das generische GenericMT-Metamodell adaptiert wird. Diese Adaptionsaspekte werden zur Laufzeit der Refaktorisierung hinein gewoben (analog aspektorientierter Programmierung). Welches Adaptionsaspekt bzw. Metamodell bei Anwendung einer Refaktorisierung heranzuziehen ist, ist dementsprechend vor der Durchführung zu konfigurieren, wobei ausschließlich die Angabe eines Adaptionsaspektes bzw. Metamodell zulässig ist. 71 Abbildung 2.19.: GenericMT Aspekt zur Adaption des UML-Metamodells aus (Moha u. a. 2009) S. 637 übernommen EMF Refactor Abbildung 2.20.: PullUp-Refactorisierung mit EMF Refactor aus (Arendta u. a. 2010b) S. 7 übernommen EMF Refactor ist ein an der Universität Marburg entwickeltes Eclipse Plugin, mit dem Modell-Refaktorisierungen auf Basis von graphorientierte Modell-zu-Modell Transfor- 70 vgl. (Moha u. a. 2009) S vgl. (Moha u. a. 2009) S. 638f.

37 2.8 Ableitung der funktionalen Anforderungen 25 mationen (vgl. Kapitel 2.3.1) durchgeführt werden. 72 Refaktorisierungen werden dabei mittels Henshin-Regeln (vormals EMF Tiger) für auf Ecore basierende Metamodelle definiert. Bei Henshin handelt es sich um ein Open Source Rahmenwerk für graphorientierte Modell-zu-Modell Transformationen. Im Kontext von Graph-Transformationen wird zwischen der so genannten Left-hand Side (LHS) und der Right-hand Side (RHS) unterschieden, wobei die Left-hand Side die Ausgangssituation eines zu transformierenden Modells und die Right-hand Side die Zielkonstellation des Modells darstellt. In Henshin wird die Left-hand Side durch Objekte, die mit preserve- und delete-markierungen versehen sind, präsentiert (vgl. Beispiel in Abbildung 2.20), die entweder durch die Transformation erhalten bleiben oder entfernt werden, wohingegen die Right-hand Side durch Objekte, die mit create- und preserve-markierungen annotiert sind, abgebildet wird (vgl. Abbildung 2.20). Bezogen auf Refaktorisierungen stellt die Left-hand Side die Vorbedingung und Right-hand Side die Nachbedingung und das Resultat der Refaktorisierung dar. Die Regeln sind dabei jeweils für jede Refaktorisierung zu definieren. Des Weiteren ist es möglich mit dem forbid-schlüsselwort negative Bedingungen zu formulieren, d. h. alle in den Henshin-Regeln mit diesem Schlüsselwort gekennzeichneten Objekte dürfen nicht existieren, wenn die Transformation/Refaktorisierung angewendet werden soll, was für für Überprüfung von Vorbedingungen nützlich ist Ableitung der funktionalen Anforderungen Auf Basis der vorherigen Kapitel werden in diesem Kapitel zunächst die allgemeinen funktionalen Anforderungen für Ko-Refaktorisierungen abgeleitet Automatische Durchführung der Ko-Refaktorisierungen Abbildung 2.21.: Use Cases für Ko-Refaktorisierungen Wie das Use Case Diagramm (vgl. 2.21) veranschaulicht, inkludiert die Durchführung einer Ko-Refaktorisierung die Refaktorisierung des Modells und des Codes. Aus Kapitel 2.2 lässt sich ableiten, dass es im Kontext der modellgetriebenen Entwicklung nicht ausreichend ist, dass nach einer Modell-Refaktorisierung der Code neugeneriert wird, da in der Regel von nicht-generierten Code auf den generierten Code zugegriffen wird, so dass es in Folge einer Code-Regenerierung zu Kompilierfehlern kommt, da die manuell 72 vgl. (Arendta u. a. 2009) S vgl. (Arendta u. a. 2010a) S. 3

38 2.8 Ableitung der funktionalen Anforderungen 26 codierten Bestandteile durch der Modell-Refaktorisierung und der nachfolgenden Regenerierung nicht berücksichtigt werden. Um auf das Beispiel Fahrzeugverwaltung und Java Enterprise Anwendungen aus Kapitel 1.1 zurückzukommen, werden oftmals aufgrund des individuellen Charakters Benutzeroberflächen händisch codiert, die die erstellten fachlichen Klassen und dessen Operationen wie die Getter/Setter-Methoden, welche auch Accessoren genannt und eine gängige Praxis in Java-Programmen zum Zugriff auf Felder in einer Klasse darstellen, aufrufen, um Daten in der Benutzeroberfläche anzuzeigen oder um neue Werte aus der Benutzeroberfläche in den Instanzen einer Klasse zu setzen. Abbildung 2.22 illustriert dieses Beispiel für ein in der Oberfläche anzuzeigendes DataGrid auf Basis des Web-Framework Google GWT. Wenn ein Attribut einer fachlichen Klas- Abbildung 2.22.: Beispiel UML-Modell/Generierter Code und manueller Code sen im Modell umgenannt wird, sind folglich die generierten Getter/Setter-Accessoren ebenfalls für die Konsistenz und somit auch die Referenzen auf diese Methoden in den manuell implementierten Code-Bestandteilen, wie in diesem Beispiel die Benutzeroberfläche, umzubenennen, da es sonst zu Kompilierfehlern kommt. Des weiteren genügt es nicht, dass nach einer Modell-Refaktorisierung eine bestimmte Refaktorisierung auf den generierten Code ausgeführt wird. Wie aus Kapitel hervorgeht, werden bei dem EMF Code-Generator andere Code-Bestandteile erzeugt wie bspw. bei der Acceleo Code-Generierung. Die Beziehungen zwischen Modell und Code müssen daher für die Refaktorisierung transparent sein, so dass deutlich wird, was aus den Elementen im Modell an Code generiert wird (Tracing), um dieses entsprechend bei der Refaktorisierung zu berücksichtigen. In Hinblick auf den manuell erstellten Code, die auf diese generierten Code-Elemente zugreifen, sind Modell- und Code-Refaktorisierungen folglich synchron durchzuführen, wie auch anhand des oben dargestellten Beispiels deutlich wird. Diese weiteren konsumiert diese Anforderung die von Fowler formulierten Kriterien bzgl. der Programm-Datenbank und des Zugriff auf den Syntaxbaum (vgl. Kapitel 2.1). Adaptiert auf Ko-Refaktorisierungen resultiert daraus, dass neben dem Zugriff auf Programm- Code ebenso der Zugriff auf die Struktur des UML-Modells möglich sein muss.

39 2.8 Ableitung der funktionalen Anforderungen Erhaltung der Bedeutung des Modells und des Codes Die Erhaltung der Bedeutung eines Software-Artifakts ergibt sich bereits aus der Definition der Refaktorisierung, in der Hinsicht, dass durch eine Refaktorisierung das Verhalten nicht geändert wird (vgl. Kapitel 2.1). Fowler verstärkt diese Anforderung durch das geforderte Kriterium der Akkuranz einer Refaktorisierung. Bezogen auf Ko-Refaktorisierungen bedeutet dies, dass sowohl die Bedeutung des Ausgangsmodell (in diesem Kontext das UML-Modell) als auch die des codierten Programms und auch die Beziehungen zwischen Modell und Code erhalten bleiben müssen. Mittels der in OCL formulierten Bedingungen für UML (vgl. Kapitel 2.3) wird die statische Semantik definiert und die Wohlgeformtheit eines Modell gewährleistet. Diese sind folglich eine notwendige Bedingung zur Erhaltung der Bedeutung des Modells bei einer Refaktorisierung, da bei Nicht-Einhaltung das Modell nicht wohlgeformt und daher bedeutungslos ist. 74 Wie in Kapitel dargelegt, ist die statische Semantik durch die Wohlgeformtheit-Regeln teilweise unterspezifiziert, welches im weiteren Verlauf der Analyse zu identifizieren und eliminieren ist, um entsprechende Bedeutungsänderungen nach einer Refaktorisierung, die infolge von Unterspezifizierungen der statischen Semantik entstehen, zu vermeiden. In den UML-Editoren der Eclipse Modeling Tools findet nach eigener Analyse selbst keine Constraintüberprüfung für die Wohlgeformtheit eines Modells statt, so dass diese im Refaktorisierungsprogramm zu berücksichtigen ist. Die dynamische Semantik eines Modells zu erhalten und dies zu prüfen ist nicht trivial, da diese gewöhnlich nicht durch Constraints ausgedrückt wird. 75 Die dynamische Semantik ergibt sich oftmals erst in Verbindung mit weiteren UML-Modellen, die verhaltensorientierte Elemente der UML verwenden (wie bspw. State Machines oder Lifelines), oder textuellen Beschreibungen. Bezogen auf den Code ist eine formale Verifikation für die dynamische Bedeutung eines Programms ebenfalls schwierig 76, so dass diese oftmals durch Unit-Tests überprüft wird. Da bei Ko-Refaktorisierungen sich das dynamische Verhalten ebenfalls im Code widerspiegelt (und bspw. bei dem EMF Code-Generator verhaltensorientierte Elemente der UML bei der Code-Generierung ignoriert werden) und die dynamische Semantik nicht in Constraints ausgedrückt wird, wird die Betrachtung der Ko-Refaktorisierungen mit UML auf die Erhaltung der statischen Semantik und somit auf Refaktorisierungen, die die statische Struktur eines Modells betreffen, eingegrenzt. Hierzu sind folglich bei einem constraintbasierten Ansatz die in OCL spezifizierten Regeln in Constraint-Regeln zu transformieren (vgl. Kapitel 2.6.2) Annullierung von Refaktorisierungen Fowler postuliert, dass Refaktorisierungen wieder zurückgesetzt werden können (vgl. Kapitel 2.1), welches der sogenannten Undo-Funktionalität gleichkommt. Für Ko- Refaktorisierungen bedeutet dies, dass analog zu sowohl Änderungen in Folge von Refaktorisierungen transaktional im Modell als auch im Code zu widerufen, um Code und Modell synchron und konsistent zu halten. 74 vgl. (Steimann 2013) S vgl. (Steimann 2013) S vgl. (Steimann 2010) S. 24ff.

40 2.9 Ableitung der nicht-funktionalen Anforderungen Ableitung der nicht-funktionalen Anforderungen Neben den funktionalen Anforderungen für Ko-Refaktorisierungen sind ebenfalls die nicht-funktionalen Anforderungen zu betrachten, die sich in der Architektur widerspiegeln sollen und die in diesem Kapitel diskutiert werden Übertragung auf mehrere Zielplattformen/Generatoren Im Rahmen dieser Arbeit werden Acceleo und das EMF Code-Generation Framework als Code-Generator analysiert (vgl. Kapitel 2.5.2). Um weitere Code-Generatoren einbinden zu können, ist die Architektur der Plugin-Komponenten dementsprechend darauf auszulegen. Dieses soll ebenfalls ohne Modifikationen an bestehendem Code realisiert werden (Open-Closed-Prinzip). Wie aus Kapitel hervorgeht, bietet der EMF Code- Generator im Kontrast zu Acceleo kein Tracing. Des weiteren unterscheidet sich die Code-Generierung zwischen Acceleo und EMF und die Generierung kann gegebenenfalls durch Parameter und eigene Generierungsmodule individualisiert werden. Hier ist folglich eine Lösung zu finden, das Tracing, mit dem die Beziehungen zwischen Model und dem generierten Code ersichtlich sind, entsprechend zu abstrahieren Erweiterungsmöglichkeiten für weitere Refaktorisierungen Neben der Erweiterung für weitere Code-Generatoren soll auch das Hinzufügen weiterer Refaktorisierungen (über Rename und PullUp Refaktorisierungen hinaus) ohne größeren Aufwand unterstützt werden. Dieses ist ebenfalls ohne Modifikationen an bestehendem Code zu implementieren Benutzeroberfläche In den Eclipse Modeling Tools existieren für die auf dem Ecore Meta-Metamodell aufbauenden Metamodelle, wie bspw. MDT-UML2, Eclipse-Plugins, mit denen über eine Oberfläche Modelle erstellt und editiert werden (vgl. Kapitel 2.5). Ein Werkzeug zur Unterstützung von Ko-Refaktorisierungen ist daher direkt in diese Oberfläche zu integrieren, so dass sich Refaktorisierungen direkt von dort aus ausführen und auf das Modell und den Code übertragen lassen. Über die Oberfläche soll auch der Code-Generator auswählbar sein, da sich Refaktorisierungen auf den Code je nach Generator anders verhalten. Des weiteren ist die Architektur so zu gestalten, dass weitere graphische UML Editoren wie bspw. Papyrus 77 unterstützt werden Effizienz/Performance Wie in Kapitel 1 beschrieben, ist ein Ziel, den Refaktorisierungsprozess in der modellgetriebenen Entwicklung zu optimieren und effizienter zu gestalten. Daraus lässt sich direkt ableiten, dass die Ko-Refaktorisierungen selbst effizient durchzuführen sind. Dieses Kriterium wird ebenfalls von Fowler gefordert. Bei Verwendung eines constraintbasierten Ansatzes ist dabei folglich zu berücksichtigen, dass ausschließlich die notwendigen 77 vgl. (Papyrus 2013)

41 2.10 Bewertung bestehender Ansätze 29 Constraints generiert werden und somit die Constraint-Menge möglichst minimal ist. Des weiteren sind die möglichen Belegungen der Constraint-Variabeln (Domain) soweit wie möglich einzuschränken. Diese nicht funktionale Anforderung wird ebenfalls in der Evaluierung berücksichtigt Bewertung bestehender Ansätze In Kapitel 2.7 sind die bestehenden Ansätze GenericMT und EMF Refactor thematisiert worden, die im Folgenden hinsichtlich der Verwendung von Ko-Refaktorisierungen bewertet werden. In der dafür aufgestellten Bewertungsmatrix (vgl. Tabelle 2.1) sind die Kriterien und Anforderungen für Ko-Refaktorisierungen in der modellgetriebenen Entwicklung eingeflossen. Wie in Kapitel beschrieben, werden bei GenericMT die Refaktorisierungen und ebenso die Vorbedingungen generisch auf Ebene M3 definiert, was für Generizität vorteilhaft hat, aber den Nachteil mit sich bringt, dass sich spezielle Eigenschaften und Bedingungen einer Sprache nicht abbilden lassen. Bei UML sind die Spracheigenschaften und die statische Semantik, welche die Bedingungen für die Wohlgeformheit repräsentieren in der Superstruktur-Spezifikation, folglich auf Ebene M2, festgelegt, die ebenfalls für die korrekte Durchführung einer Refaktorisierung einfließen müssen. Bspw. existieren in der UML-Spezifikation spezielle Bedingungen für Redefinition und Subsetting von Attributen einer Klasse, welche unter anderem für PullUp-Refaktorisierungen relevant sind, die in der generischen Definition und für andere Metamodelle nicht vorhanden sind. Bei EMF Refactor werden die Vorbedingungen und die Durchführung der Refaktorisierung selbst, in der ebenfalls die Erhaltung der Bedeutung sichergestellt werden muss, mit graphischen Transformationsregeln für ein konkretes Metamodell (Ebene M2) beschrieben (vgl. Kapitel 2.7.2). Hier ist folglich ein Ansatz zu finden, wie die in OCL formulierten Bedingungen zur Erhaltung der Wohlgeformheit eines UML-Modells in graphische Transformationsregeln abgebildet werden, welches nicht intuitiv ist. Kriterium GenericMT EMF Refactor Erhaltung der statischen Semantik durch generischen Ansatz können spezifische Regeln für die statische Semantik nicht ohne Weiteres formuliert werden durch Henshin-Regeln theoretisch abbildbar Abbildung von übergreifenden Refaktorisierungen durch generischen Ansatz und Adaption auf ein Metamodell nicht ohne Weiteres möglich möglich, wobei mit Henshin-Regeln ausschließlich auf Ecore basierte Metamodelle zurückgegriffen werden kann Refaktorisierung von nicht-generierten Code-Elementen nicht möglich prinzipiell möglich

42 2.10 Bewertung bestehender Ansätze 30 Erweiterungsmöglichkeiten für weitere Code-Generatoren nicht vorhanden prinzipiell vorhanden Erweiterungsmöglichkeiten für weitere Refaktorisierungen vorhanden vorhanden Integration in Modellierungs- Benutzeroberflächen vorhanden für Eclipse vorhanden für Eclipse Tabelle 2.1.: Bewertungsmatrix Bei GenericMT wird für eine konkrete Refaktorisierung ein konkretes Metamodell in eine generische GenericMT-Refaktorisierungsdefinition eingesetzt (ähnlich dem Generics- Konzept bei Java, vgl. Kapitel 2.7.1), so dass es für die Abbildung von übergreifenden Refaktorisierungen nicht ohne Weiteres möglich ist, auf mehrere Metamodelle in einer Definition gleichzeitig zurückzugreifen. Zudem können einer GenericMT-Klasse ausschließlich eine Metaklasse (vgl. Kapitel 2.7.1) und nicht mehrere Metaklassen, denen zudem unterschiedliche Metamodelle zugrunde liegen, zugeordnet werden, was für Ko-Refaktorisierungen und den damit verbundenen Refaktorisierungen im Modell und von generierten und nicht-generierten Code essentiell ist. Bei EMF Refactor kann sich eine Refaktorisierungsdefinition auf mehrere Metamodelle beziehen, wobei diese auf dem Ecore Meta-Metamodell als Vorraussetzung für die Graph-Transformationen mit Henshin basieren müssen. Da bei Refaktorisierungen für Java durch das Eclipse LTK überwiegend ein AST-basierter Ansatz verwendet wird, ist daher die Java- Sprachdefinition in ein Ecore konformes Modell zu überführen, um EMF Refactor für Java und Ko-Refaktorisierungen nutzen zu können. Zudem ist ein Adapter nötig, der das konkrete zu refaktorisierende Java-Programm in das auf Ecore basierende Java-Metamodell übersetzt bzw. die errechneten Änderungen im Ecore-Modell wieder zurückübersetzt. Dies gilt ebenso für die Refaktorisierung von nicht generierten Code- Bestandteilen. Wenn in den Henshin-Regeln mittels der Left-hand Side und der Righthand Side die Beziehungen zwischen Modell und Code und zudem die entsprechenden Java-Eigenarten modelliert sind, wie bspw. dass bei Änderung eines Feldnamens der Name der Referenzen auf dieses Feld gleich dem neuen Namen ist, und der Adapter entsprechend den gesamten Code analysiert, werden auch nicht-generierte Code-Bestandteile refaktorisiert. Die Erweiterungsmöglichkeit für weitere Code-Generatoren lässt sich bei GenericMT aus dem bereits diskutierten Kriterium bezüglich der Abbildung von übergreifenden Refaktorisierungen ableiten. Da bei GenericMT die Grundvoraussetzungen für übergreifenden Refaktorisierungen nicht gegeben sind, sind folglich auch keine Erweiterungsmöglichkeiten für weitere Code-Generatoren vorhanden. Bei EMF Refactor können übergreifenden Refaktorisierungen für weitere Code-Generatoren realisiert werden, wobei neue Refaktorisierungsdefinitionen zu erstellen sind, in denen die angepassten Beziehungen zwischen Modell und Code für den jeweiligen Code-Generator abgebildet werden. Nachteilig in diesem Kontext ist, dass hier bei EMF Refactor die UML- Wohlgeformtheitsbedingungen erneut in der Definition formuliert werden müssen, obwohl diese prinzipiell gemeingültig und unabhängig vom jeweiligen Code-Generator sind.

43 2.11 Zusammenfassung 31 Erweiterungsmöglichkeiten für weitere Refaktorisierungen und die Integration in Benutzeroberflächen als Plugins sind bei beiden Ansätzen analog zu Refacola grundsätzlich vorhanden, indem neue Refaktorisierungsdefinitionen in der jeweiligen Sprache implementiert werden und für Einbindung in eine Entwicklungsumgebung auf die bestehenden Eclipse-Komponenten zurückgegriffen wird (vgl. Kapitel 2.4). Zusammenfassend lässt sich daher sagen, dass die ausschlaggebenden Kriterien für Ko- Refaktorisierungen bei GenericMT nicht und bei EMF Refactor ausschließlich diffizil erfüllt werden Zusammenfassung Zusammenfassend lässt sich sagen, dass die in den vorherigen Kapiteln diskutierten Konzepte die erforderliche Basis für Ko-Refaktorisierungen darstellen. So steht mit der Eclipse Plugin-Architektur, den Eclipse JDT und dem Eclipse LTK bereits ein Rahmenwerk für Refaktorisierungsprogramme zur Verfügung, mit dem auch der Zugriff auf den AST gewährleistet ist, und somit bereits eine der von Opyke und Fowler formulierten Anforderungen erfüllt wird. Refacola offeriert darauf aufbauend mit dem Info-Provider-Prinzip den Zugriff auf eine Programm-Datenbank. Wie in Kapitel dargelegt, existiert für JDT bereits eine Implementierung eines Info-Providers. Bezüglich der Realisierung des UML-Metamodells besteht mit den Eclipse MDT und dem Eclipse EMF ein Framework, das mit dem Ecore Meta-Metamodell auf Standards der OMG (EMOF) aufsetzt, so dass für UML-Modelle eine konforme Implementierung im Eclipse Ökosystem existiert, die als Basis für Ko-Refaktorisierungen herangezogen werden kann. Auf Basis dieser Grundlagen und der verwandten Arbeiten sind die Anforderungen zu Ko-Refaktorisierungen abgeleitet und bestehende Ansätze für Modell-Refaktorisierungen bewertet worden, inwieweit diese die Anforderungen für Ko-Refaktorisierungen erfüllen. In der weitergehenden Analyse ist zu erörtern, wie sich die Beziehungen zwischen Modell und Code modellieren lassen, die Spracheigenschaften von UML transformieren lassen und wie die entsprechenden Eigenschaften von Code-Generatoren, wie der EMF Code- Generator und Acceleo, für Ko-Refaktorisierungen bei einem constraintbasierten Ansatz abstrahiert werden können.

44 32 3. Ko-Refaktorisierungen mittels eines constraintbasierten Ansatzes 3.1. Vorgehen Wie sich aus Kapitel 2.10 herauskristallisiert, sind die bestehenden Ansätze zur Modell- Refaktorisierungen für Ko-Refaktorisierungen beschränkt einsatzbar. Daher wird im weiteren Verlauf dieser Arbeit auf den constraintbasierten Ansatz zurückgegriffen und daraufhin die Code-Generatoren, Sprachdefinitionen und Constraint-Regeln für übergreifende Refaktorisierungen untersucht. Da in Refacola die Refaktorisierungen auf Basis der Elemente der jeweilige Sprache (in diesem Fall UML) definiert werden, was analog auch für die Constraint-Regeln gilt, wird die Refaktorisierung demzufolge auf Ebene M2 und nicht auf Ebene M3 spezifiziert, was ggf. generischer wäre, aber ebenso die im vorherigen Kapitel aufgezeigten Nachteile nach sich zieht, und die statisch-semantischen Eigenschaften von UML sich nicht formulieren ließen. Wie in Kapitel erörtert, sind bei Ko-Refaktorisierungen die Erhaltung der Bedeutung des Modells, des Codes und der Beziehungen zwischen Modell und Code relevant, so dass im folgenden ausgehend von der UML2-Sprachdefinition und den UML2- Constraint-Regeln, die Java-Sprachdefinition und Java-Constraint-Regeln und die Beziehungen zwischen Modell und Code bezogen auf die jeweiligen Code-Generatoren als übergreifende Definition und Constraint-Regeln analysiert werden Sprachdefinition von UML2 im Refacola-Kontext In Kapitel 2.3 ist dargestellt, dass es sich bei dem UML2-Metamodell um eine Instanz des MOF Meta-Metamodells handelt. In Bezug auf das Eclipse Modeling Framework ist das UML2-Metamodell mit Ecore als MOF konformes Metamodell beschrieben, wobei Ecore ebenso als Instanz des Ecore Meta-Metamodells auftritt. Bei constraintbasierten Refaktorisierungen ist neben den Constraint-Regeln die Sprachdefinition zu verfassen (vgl. Kapitel 2.6), auf dessen Basis Refaktorisierungen durchgeführt werden sollen. Im Kontext des Refacola-Frameworks wird dies mit der dazugehörigen domänenspezifischen Sprache durchgeführt, die mittels Xtext spezifiziert ist (vgl. Kapitel 2.6.1). Aus Xtext- Beschreibungen werden Ecore-Modelle erzeugt, so dass die abstrakte Syntax (Metamodell) von Refacola ebenso als Instanz des Ecore Meta-Metamodells betrachtet werden kann. Dieser Zusammenhang kann für Modell-zu-Modell Transformationen genutzt werden, bei denen das Quellmodell und das Zielmodel auf dem gleichen Meta-Metamodell basieren (vgl. Kapitel 2.3.1). In Abbildung 3.1 ist dieser Zusammenhang visualisiert, welche entsprechend aus Abbildung 2.6 in Kapitel adaptiert ist. Mittels einer generischen Modell-zu-Modell Transformationsbeschreibung kann folglich jede Sprache, dessen Metamodell auf Ecore basiert, in eine Refacola-Sprachdefinition transformiert werden, wobei bei Anpassung der Transformationssbeschreibung auch andere domänenspezifischen Sprachen für constraintbasierte Refaktorisierungen möglich sind. Da das UML-Metamodell Instanz des Ecore-Metamodells ist, wird die generische Transformationssbeschreibung benötigt, die das entsprechende Ecore-Modell einliest (in diesem Fall das Ecore UML-Modell UML.ecore) und in eine Instanz des Refacola-

45 3.3 Constraint-Regeln von UML2 33 Abbildung 3.1.: Transformation UML-Metamodell in Refacola-Instanz adaptiert aus Kapitel 2.3.1(Model-zu-Modell Transformationen) Metamodells transformiert, die wiederum in konkrete Refacola-Definitionen übersetzt werden kann. Für die Modell-zu-Modell Transformation zur Übersetzung des UML2- Metamodell in die Refacola-Sprachdefinition kann Mitra (vgl. Kapitel 2.3.1) genutzt werden. Eine beispielhafte Transformationssbeschreibung für Mitra, die dieses realisiert, ist unter D.2 zu finden. Das Ergebnis (Auszug) der Mitra-Transformation im XML Metadata Interchange-Format (XMI-Format) ist in Listing D.3 zu sehen, welches wiederum mit entsprechenden Programmen in native Refacola-DSL Modelle konvertiert werden kann (vgl. Kapitel E). Die Wertebereiche (Domain) und Queries zur Abfrage von Fakten in einem Artefakt werden ebenfalls auf Basis der Elemente und Eigenschaften im Ecore UML-Metamodell automatisiert abgeleitet und generiert. Der Ansatz zur Generierung von Sprachdefinitionen wird ebenfalls in (von Pilgrim u. a. 2013) erörtert Constraint-Regeln von UML2 Zur Erhaltung der Wohlgeformheit eines UML-Modells (vgl. Kapitel 2.3) sind die OCL formulierten Wohlgeformtheit-Regeln bei einem constraintbasierten Ansatz in Constraint-Regeln zu transformieren, wofür bereits konzeptionelle Ansätze existieren, die Kapitel vorgestellt worden sind. Die Überführung aller in OCL formulierten Wohlgeformtheit-Regeln der UML Superstruktur-Spezifikation würde den Rahmen dieser Arbeit sprengen. Daher soll auf die Wohlgeformtheit-Regeln, die für in dieser Arbeit zu evaluierenden Refaktorisierungen Rename und PullUp von Attributen relevant sind, eingegangen werden. Um die relevanten Wohlgeformtheit-Regeln zu identifizieren, werden zunächst die Klassenhierarchie und die Assoziationen des Attributs (in UML Property genannt) des UML-Metamodells aus der UML Superstruktur-Spezifikation betrachtet, welche in Abbildung 3.2 visualisiert sind. Wie aus diesem Diagramm deutlich wird, besitzt eine Property eine Assoziation zu einer Class, die bei einem konkreten Modell die Klasse widerspiegelt, zu dem die Property gehört. Diese Assoziation ist für Rename- und PullUp-Refaktorisierungen in der Hinsicht relevant, da bei diesen Refaktorisierungen bestimmte Bedingungen hinsichtlich der bereits existierenden Poperties in einer Klasse einzuhalten sind (vgl. Kapitel und 2.1.2). In der UML Superstruktur-Spezifikation werden zu den einzelnen Begriffen der UML die Wohlgeformtheit-Regeln in Form von OCL-Constraints definiert, in denen optional auf bestimmte Operationen Bezug genommen wird. Im Kontext dieser OCL-

46 3.3 Constraint-Regeln von UML2 34 Abbildung 3.2.: Klassenhierarchie von Property gemäß UML Superstruktur- Spezifikation nach (OMG 2011b) Constraints sind Operationen komplexe Abfragen gegen ein UML-Modell 1, die anhand bestimmter Parameter einen Rückgabewert liefern. Gemäß der Hierarchie eines Begriffs der UML wie Property oder Class gelten neben den Constraints für den jeweiligen Begriff ebenso die Constraints, die diesen Begriff generalisieren (bspw. bei Class der Begriff Classifier). Falls notwendig, werden in den spezialisierten Begriffen weitere Constraints hinzugefügt, aber nicht überschrieben, wohingegen Operationen überschrieben werden können. Da die class-eigenschaft bzw. Assoziation für Property den Container und Kontext der Property repräsentiert und infolgedessen relevant für die zu untersuchenden Refaktorisierungen hinsichtlich der Bedeutungserhaltung ist (vgl. Kapitel 2.8.2), werden im Folgenden die Constraints von Class entlang der Hierarchie aus der UML Superstruktur- Spezifikation analysiert und die Constraints hinsichtlich der Bedeutung für Rename- 1 Anm.: Bei diesen Operation/Abfragen handelt es sich nicht um Abfragen, die sich aus dem UML2- Metamodell ergeben und automatisch als Fakten-Abfragen in constraintbasierten Refaktorisierungen/Refacola generiert werden (vgl. Kapitel 3.2), sondern diese sind der UML2 Superstruktur- Spezifikation autark definiert

47 3.3 Constraint-Regeln von UML2 35 und PullUp-Refaktorisierungen bewertet. Nachfolgend wird dies analog für Property als Subjekt dieser Refaktorisierungen durchgeführt Constraint-Regeln zu Classifier Für Class sind selbst keine Constraints definiert 2. In der generalisierten Klasse Classifier sind Constraints spezifiziert 3, die in Tabelle 3.1 gelistet sind. Nr. Beschreibung Constraint in OCL 1 The general classifiers are the classifiers referenced by the generalization relationships. Relevant Rename für general = self.parents() nein nein Relevant PullUp für 2 Generalization hierarchies must be directed and acyclical. A classifier cannot be both a transitively general and transitively specific classifier of the same classifier. not self.allparents()-> includes(self) nein nein 3 A classifier may only specialize classifiers of a valid type. self.parents()-> forall(c self.mayspecializetype(c)) nein nein 4 The inheritedmember association is derived by inheriting the inheritable members of the parents. self.inheritedmember = self.inherit( self. parents()-> collect(p p. inheritablemembers(self))-> asset()) nein nein 5 The parents of a classifier must be non-final. self.parents()-> forall(not isfinalspecialization) nein nein Tabelle 3.1.: Constraints in Classifier Wie sich aus Tabelle 3.1 manifestiert, beziehen sich die Constraints in Classifier mit Ausnahme des inheritedmember-constraints [4] auf die Generalisierungsbeziehungen selbst ohne Bezug zu enthaltenden Elementen des Classifiers, zu denen auch Properties gehören, so dass diese für Rename- und PullUp-Refaktorisierungen keine unmittelbare Relevanz haben, da durch die Intention dieser Refaktorisierungen Generalisierungsbeziehungen zwischen Classifiern nicht tangiert werden (bzgl. der Refaktorisierungsintention vgl. Kapitel und 3.6). Der inheritedmember-constraint legt hingegen fest, dass sich die inheritedmember- Assoziation, welche die geerbten Elemente repräsentiert, sich aus den vererbbaren Elementen der Eltern-Klasse zusammensetzt. Da die inheritedmember-assoziation entspre- 2 vgl. (OMG 2011b) S vgl. (OMG 2011b) S. 52

48 3.3 Constraint-Regeln von UML2 36 chend der UML-Spezifikation eine abgeleitete Assoziation ist 4, die nicht explizit gesetzt wird, stellt dieser Constraint im engeren Sinne keine Wohlgeformheit-Regel dar, sondern eine Bildungsregel, wie sich die inheritedmember-menge auf Basis der vorhandenen Elemente des UML-Modells errechnet. Dieser Constraint referenziert unter anderem auf inheritablemembers- und hasvisibilityof-abfrage (vgl. Listing 3.1 und 3.2), aus denen deutlich wird, dass ausschließlich Elemente vererbt werden, deren Sichbarkeit nicht #private ist. Ob die Sichtbarkeit bei Heraufziehen einer Property zu ändern ist, wenn dieses als #private deklariert ist, lässt sich aus diesem Constraint folglich nicht ableiten, sondern beispielsweise bei Ko-Refaktorisierungen daraus, ob der direkte Zugriff auf dieses Attribut in den Unterklassen im Code weiter benötigt wird. Demzufolge wäre die Sichtbarkeit übergreifend wiederum im Modell anzupassen, damit Modell und Code konsistent sind, was in Kapitel 3.5 erörtert wird. Des weiteren wird durch die Absicht der Refaktorisierung selbst ausgedrückt, ob die Sichbarkeitseigenschaft eines Elements geändert werden darf. Die inheritablemembers-operation in Classifier: 5 Classifier::inheritableMembers(c: Classifier): Set(NamedElement); pre: c.allparents()->includes(self) inheritablemembers = member -> select(m c.hasvisibilityof(m)) Listing 3.1: inheritablemembers-operation für Classifier Die hasvisibilityof-operation in Classifier: 6 Classifier::hasVisibilityOf(n: NamedElement) : Boolean; pre: self.allparents()->collect(c c.member) -> includes(n) hasvisibilityof = (n.visibility <> #private) Listing 3.2: hasvisibilityof-operation für Classifier Constraint-Regeln zu Namespace Des weiteren ist Classifier von Namespace abgeleitet (vgl. Abbildung 3.2), so dass im Folgenden die Constraints von Namespace zu analysieren sind (vgl. Tabelle 3.2). Nr. Beschreibung Constraint in OCL 1 2 All the members of a Namespace are distinguishable within it. The importedmember property is derived from the ElementImports and the PackageImports. Relevant Rename für membersaredistinguishable() ja ja importedmember = self. elementimport.importedelement.asset()-> union(self. packageimport.importedpackage -> collect(p p. visiblemembers())) nein Relevant PullUp nein für Tabelle 3.2.: Constraints in Namespace 4 vgl. (OMG 2011b) S vgl. (OMG 2011b) S vgl. (OMG 2011b) S. 53

49 3.3 Constraint-Regeln von UML2 37 Der Constraint membersaredistinguishable[1] definiert, dass Attribute im jeweiligen Kontext (bspw. einer Klasse) unterscheidbar und eindeutig sind, was in der Regel unter anderem unter Berücksichtigung des Namens realisiert wird. Dieses ist bei Umbenennen von Attributen bzw. bei Heraufziehen eines Attributs in eine Oberklasse relevant, da bei diesen Refaktorisierungen durch deren Intention bei Ersterem die Namen-Eigenschaft des Attributs und bei Zweiterem der Kontext des Attributs geändert wird (vgl. Kapitel 2.6). Die Eindeutigkeit und Unterscheidbarkeit von Attributen muss nach Durchführung dieser Refaktorisierungen gewährleistet bleiben. Im membersaredistinguishable-constraint wird auf die membersaredistinguishable()-abfrage und indirekt auf weitere Abfragen referenziert: Die membersaredistinguishable-operation in Namespace: 7 Namespace::membersAreDistinguishable() : Boolean; membersaredistinguishable = self.member -> forall( memb self.member -> excluding(memb) -> forall(other memb.isdistinguishablefrom(other, self))) Listing 3.3: membersaredistinguishable-operation für Namespace Detaillierung der isdistinguishablefrom-operation in NamedElement: 8 NamedElement::isDistinguishableFrom(n:NamedElement, ns: Namespace): Boolean; isdistinguishable = if self.ocliskindof(n.ocltype) or n.ocliskindof(self.ocltype) then ns.getnamesofmember(self)->intersection (ns.getnamesofmember(n)) -> isempty() else true endif Listing 3.4: isdistinguishablefrom-operation für Namespace getnamesofmember-operation in Namespace: 9 Namespace::getNamesOfMember(element: NamedElement): Set(String); getnamesofmember = if self.ownedmember -> includes(element) then Set{}->include(element.name) else let elementimports: ElementImport = self.elementimport -> select(ei ei. importedelement = element) in if elementimports -> notempty() then elementimports->collect(el el.getname()) else self.packageimport -> select(pi pi.importedpackage.visiblemembers() -> includes(element)) -> collect(pi pi.importedpackage.getnamesofmember( element)) endif endif Listing 3.5: getnamesofmember-operation für Namespace Die Bestandteile zu elementimport und packageimport in der getnamesofmember- Operation beziehen sich auf den Import von Elementen vom Typ PackageableElement (Rückgabetyp von self.elementimport und visiblemembers()), wenn diese mehrfach mit jeweils anderen Alias-Namen in einen Namespace importiert werden. Da Property nicht von PackageableElement erbt, kann eine Property nicht mehrfach unter einem anderen Namen in einem Namespace deklariert werden, so dass diese Teile des Constraints durch die ocliskindof-bedingung keine direkte Auswirkung für Rename Property- und Pullup Property-Refaktorisierungen haben. Aus dem membersaredistinguishable-constraint und den entsprechenden Abfragen lässt sich daher folgende vereinfachter Ausdruck schließen: n namespaces, m1 n.member, m2 n.member, m1! = m2 : (ocliskindof(m1, m2) ocliskindof(m2, m1)) = m1.name! = m2.name (3.1) 7 vgl. (OMG 2011b) S vgl. (OMG 2011b) S vgl. (OMG 2011b) S. 102

50 3.3 Constraint-Regeln von UML2 38 Wie in Kapitel dargelegt, sind Constraint-Regeln implizit allquantifiziert und die weitere Ableitung ist abhängig von den feststehenden und die durch eine Refaktorisierung veränderbaren Eigenschaften, was ebenso Auswirkung auf die erzeugten Constraints und folglich auf die Effizienz (vgl. Kapitel 2.9.4) hat. Tabelle 3.3 veranschaulicht die feststehenden und veränderbaren Eigenschaften, die sich aus der Intention der jeweiligen Refaktorisierung schließen lassen. Refaktorisierung Rename Property PullUp Property Eigenschaft name veränderbar feststehend member(abgeleitet) feststehend veränderbar ownedmember feststehend veränderbar Tabelle 3.3.: Feststehende und veränderbare Eigenschaften Bezogen auf die Rename-Refaktorisierung resultiert unter Berücksichtigung der fixen und variablen Eigenschaften für den membersaredistinguishable-constraint folgende Constraint-Regel: n namespaces m1, m2 n.member m1! = m2 (ocliskindof(m1, m2) ocliskindof(m2, m1)) m1.name! = m2.name (3.2) Aufgrund der Variabilität der member-eigenschaft bei der PullUp-Refaktorisierung kann diese nicht Bestandteil der Query der Constraint-Regel sein, so dass sich folgende Constraint-Regel für die PullUp-Refaktorisierung ergibt: n namespaces m1! = m2 (ocliskindof(m1, m2) ocliskindof(m2, m1) m1, m2 n.member = m1.name! = m2.name (3.3) Im Rahmen der Realisierung der constraintbasierten Refaktorisierungen ist die member- Eigenschaften in Namespace, unter Anderem auf Basis des inheritedmember-constraints in Classifier und der Operationen in Listings 3.1 und 3.2, weiter aufzuschlüsseln, um diese im Constraint verwenden zu können, da es sich bei dieser gemäß UML Superstruktur- Spezifikation um eine abgeleitete und als Derived Union gekennzeichnete Eigenschaft handelt, die selbstbesitzende als auch geerbte Elemente einschließt vgl. (OMG 2011b) S. 101

51 3.3 Constraint-Regeln von UML Constraint-Regeln zu Property Da zu den nächstfolgenden Generalisierungen Type und Packageable Element keine Constraints in der UML-Spezifikation vorgegeben sind und die weiteren Generalisierungen zu Namespace ebenfalls auf Property zutreffen (vgl. Abbildung 3.2), werden ausgehend von Property, was das eigentliche Subjekt der zu betrachtenden Rename- und PullUp- Refakotorisierung ist, die weiteren Wohlgeformtheit-Regeln für die Transformation untersucht. Für Property selbst sind diese in Tabelle 3.4 mit der jeweiligen Refaktorisierungsrelevanz dargestellt. 11 Nr. Beschreibung Constraint in OCL 1 If this property is owned by a class associated with a binary association, and the other end of the association is also owned by a class, then opposite gives the other end. opposite = if owningassociation -> isempty ()and association.memberend -> size()= 2 then let otherend = (association. memberend - self)-> any()in if otherend.owningassociation -> isempty()then otherend else Set{} endif else Set {} endif Relevant Rename nein für Relevant PullUp nein für 2 A multiplicity on an aggregate end of a composite aggregation must not have an upper bound greater than 1. iscomposite implies ( upperbound()-> isempty()or upperbound()<= 1) nein nein 3 4 Subsetting may only occur when the context of the subsetting property conforms to the context of the subsetted property. A redefined property must be inherited from a more general classifier containing the redefining property. subsettedproperty -> notempty ()implies (subsettingcontext ()-> notempty()and subsettingcontext()-> forall (sc subsettedproperty -> forall(sp sp. subsettingcontext()-> exists( c sc.conformsto(c))))) if (redefinedproperty -> notempty())then (redefinitioncontext -> notempty()and redefinedproperty -> forall( rp ((redefinitioncontext -> collect(fc fc.allparents() ))-> asset())-> collect(c c.allfeatures())-> asset()-> includes(rp)) nein nein ja nein 5 A subsetting property may strengthen the type of the subsetted property, and its upper bound may be less. subsettedproperty -> forall( sp type.conformsto(sp.type) and ((upperbound()-> notempty ()and sp.upperbound()-> notempty())implies upperbound ()<= sp.upperbound())) nein nein 6 A derived union is derived. isderivedunion implies isderived nein nein 11 vgl. (OMG 2011b) S. 126

52 3.3 Constraint-Regeln von UML A derived union is read only. isderivedunion implies isreadonly nein nein 8 The value of iscomposite is true only if aggregation is composite. iscomposite = (self. aggregation = #composite) nein nein 9 A Property cannot be subset by a Property with the same name. if (self.subsettedproperty -> notempty())then self. subsettedproperty -> forall( sp sp.name <> self.name) ja nein Tabelle 3.4.: Constraints in Property Mit dem opposite-constraint [1] wird ausgesagt, dass im Falle einer binären Assoziation zwischen zwei Klassen das Gegenstück eines Attributs, wenn dieses nicht selbst durch die Assoziation sondern durch die Klasse besitzt wird, das Attribut des anderes Endes (ausgedrückt durch memberend) der Assoziation ist, wenn dieses ebenfalls nicht von Assoziation sondern von der Klasse besitzt wird. Dieser Constraint und der Bezug zu den zu untersuchenden Refaktorisierungen soll anhand eines Beispiels veranschaulicht werden. Die Abbildung 3.3 zeigt eine Klassenbeziehung zwischen ClassA und ClassB mit dem Abbildung 3.3.: Beispiel für AssociationOpposite-Constraint darunterliegenden UML-Modell. Die Attribute memberclassb (in der Klasse ClassA) und memberclassa (in der Klasse ClassB) werden nicht von der Assoziation gehalten, sondern sind im Besitz der jeweiligen Klassen, so dass gemäß dem Constraint das Attribut memberclassa das Gegenstück (opposite) des Attributs memberclassb darstellt und umgekehrt. Wenn im Rahmen einer PullUp-Refaktorisierung das Attribut mem-

53 3.3 Constraint-Regeln von UML2 41 berclassb in die Klasse AbstractA heraufgezogen wird (vgl. Abbildung 3.4), wird der opposite-constraint davon nicht tangiert und bleibt weiterhin gültig, da die memberend- Eigenschaft der Assoziation weiterhin die gleichen Referenzen auf die Attribute hat und das Gegenstück des hochgezogenen Attributs memberclassb weiterhin memberclassa ist, so dass formal gesehen dieser Constraint für PullUp-Refaktorisierungen nicht relevant ist. Im Constraint [1] wird der Umstand, ob das Attribut im Besitz einer Klasse ist, daran geprüft, dass owningassociation keinen Wert hat. Es wird aber kein Bezug auf den Besitzer selbst genommen, der durch die Intention der PullUp-Refaktorisierung geändert wird. Intuitiv wäre anzunehmen, dass mit der PullUp-Refaktorisierung der Typ des At- Abbildung 3.4.: Beispiel für eine Property mit Assoziationen tributs memberclassa in der Klasse ClassB in AbstractA geändert werden. Es existiert jedoch kein Constraint in der UML-Superstruktur, das ausdrückt, dass im Kontext einer Assoziation das Gegenstück des Attributs vom Typ der besitzenden Klasse des ausgehenden Attributs sein muss. Dies kann ebenfalls als semantische Schwäche ausgelegt werden. Im ECore-Genmodel-Metamodell selbst existiert dieser Constraint aber, was durch die Abbildung 3.5.: GenModel-Transformation nach PullUp-Refaktorisierung Transformation eines UML-Modells in ein GenModell-Modells deutlich wird (vgl. Abbildung 3.5), so dass diese Bedingungen in den spezifischen Constraint-Regeln für EMF zu berücksichtigen sind. In Constraint [3] wird auf den Kontext Bezug genommen, wenn die Property eine Untermenge anderer Properties repräsentiert, was durch die subsettedproperty-eigenschaft ausgedrückt wird. Da sich der Kontext einer Property durch die PullUp-Refaktorisierung ändert, ist dieser Constraint für diese Refaktorisierung entscheidend. In diesem Constraint wird auf Abfragen referenziert, die im folgenden analog zu den vorherigen Ableitungen zu untersuchen sind:

54 3.3 Constraint-Regeln von UML2 42 Die subsettingcontext-operation in Property: 12 Property::subsettingContext() : Set(Type) subsettingcontext = if association -> notempty() then association.endtype-type else if classifier -> notempty() then Set{classifier} else Set{} endif endif Listing 3.6: subsettingcontext-operation für Property conformsto-operation in Classifier: 13 Classifier::conformsTo(other: Classifier): Boolean; conformsto = (self=other) or (self.allparents() -> includes(other)) Listing 3.7: conformsto-operation für Namespace allparents-operation in Classifier: 14 Classifier::allParents(): Set(Classifier); allparents = self.parents() -> union(self.parents() -> collect(p p.allparents() )) Listing 3.8: allparents-operation für Namespace parents-operation in Classifier: 15 Classifier::parents(): Set(Classifier); parents = generalization.general Listing 3.9: parents-operation für Classifier Der subsettingcontext-constraint 16 mit den entsprechenden Abfragen lässt sich zusammenfassend als folgende Gleichung formulieren, wobei bezüglich der subsettingcontext- Operation im Rahmen der zu untersuchenden PullUp-Refaktorisierungen angenommen wird, dass der Besitzer der korrespondierenden Property ein Classifier ist 17 : p properties, sp p.subsettedp roperty, sc p.classif ier : p.subsettedp roperty > 0 = p.classifier > 0 spc sp.classifier : sc = spc spc sc.allp arents()) (3.4) Die weitere Ableitung ist analog von den feststehenden und variablen Eigenschaften der jeweiligen Refaktorisierung abhängig. Die subsettedproperty-eigenschaft ist bei der PullUp-Refaktorisierung feststehend, jedoch wird der Kontext, d. h. die classifier- Eigenschaft, durch die Refaktorisierung geändert, so dass sich folgende Constraint-Regel implizieren lässt: p properties p.subsettedp roperty > 0 sp p.subsettedp roperty sc p.classifier > 0 sc p.classifier = spc sp.classifier : sc = spc spc sc.allp arents() (3.5) 12 vgl. (OMG 2011b) S vgl. (OMG 2011b) S vgl. (OMG 2011b) S vgl. (OMG 2011b) S diese Wohlgeformheit-Regel wird als Beispiel auch in (Steimann 2013) S. 23 behandelt 17 vgl. (OMG 2011b) S. 129

55 3.3 Constraint-Regeln von UML2 43 Durch den Existenzquantor ist die Wohlgeformheit-Regel statisch-semantisch unterspezifziert und die abgeleitete Constraint-Regel somit mehrdeutig, so dass das Modell nach einer Refaktorisierung eine anderen Bedeutung erlangen kann (vgl. Kapitel 2.8.2). Da im Rahmen dieser Arbeit bei der zu untersuchenden PullUp-Property Refaktorisierung ein Classifier als Besitzer der Property angenommen wird (vgl. Kapitel 2.1.2) und der Rückgabewert der subsettingcontext-operation in diesem Falle eine Menge mit ausschließlich einem Element ist, welches den Classifier repräsentiert, kann der Existenzquantor entfernt werden. Demzufolge resultiert folgende Constraint-Regel: p properties p.subsettedp roperty > 0 sp p.subsettedp roperty sc p.classifier > 0 sc p.classifier = (sc = sp.classif ier sp.classif ier sc.allp arents()) (3.6) Hinsichtlich der allparents-operation, welche Bestandteil des Constraints ist, ist zu beachten, dass diese rekursiv definiert und daher vor der Constraint-Erzeugung aufzulösen bzw. auszurollen ist. Da der sp.classifier in sc.allparents()-ausdruck eine transitive Relation gleichen Typs ausdrückt, was durch Listing?? deutlich wird, lässt sich diese allparents-abfrage als Relation-Constraint abbilden und somit die transitive Hülle erzeugen. Constraint [4] ist ähnlich zu Constraint [3] zu charakterisieren und definiert, dass eine Property ausschließlich eine Property redefinieren kann, die Element einer generalisierten Klasse ist. Da die redefinedproperty-eigenschaft durch Rename- und PullUp- Refaktorisierung nicht variiert wird und sich der redefinitioncontext ausschließlich auf die owningassociation-assoziation bezieht 18, was bedeutet, dass die Property nicht von einer Klasse sondern direkt von einer Assoziation besitzt wird, wird dieser Constraint aufgrund der getroffenen Annahme nicht weiter verfolgt, was ebenso für die Constraints für RedefinableElement (vgl. Tabelle C.2) zutreffend ist. Constraint [9] in Property formuliert die Bedingung, dass eine Property, wenn diese andere Properties subsetted nicht den gleichen Namen der subsetted Properties besitzen darf. Da die name-eigenschaft durch die die Rename-Refaktorisierungen geändert wird, ist dieser Constraint relevant. Constraint [9] lässt sich folgendermaßen in Prädikatenlogik erster Stufe formulieren: p properties, sp p.subsettedp roperty : p.subsettedp roperty > 0 = sp.name! = p.name (3.7) Da folglich bis auf die name-eigenschaften alle anderen Eigenschaften nicht durch die Rename-Refaktorisierungen variiert werden, sind diese Bestandteil der Query, so dass sich folgende Constraint-Regel ergibt: p properties sp p.subsettedp roperty p.subsettedp roperty > 0 sp.name! = p.name (3.8) Die Aggregation-, Composite-, DerivedUnion- und Multiplizitäten-Eigenschaften einer Property werden nicht durch die Intention der Rename- und PullUp-Refaktorisierungen beeinflusst, welche die übrigen Wohlgeformtheit-Regeln von Property und die 18 vgl. (OMG 2011b) S. 125

56 3.3 Constraint-Regeln von UML2 44 Wohlgeformheit-Regeln ([2], [5], [6], [7], [8]) der generalisierten Klasse MultiplicityElement (vgl. Tabelle C.1) betreffen Constraint-Regeln zu NamedElement In StructuralFeature, Feature, TypedElement sind in der UML-Spezifikation keine Contraints spezifiziert, so dass fortfolgend die Constraints von NamedElement 19 zu analysieren sind (vgl. Tabelle 3.5). Nr. Beschreibung Constraint in OCL 1 2 If there is no name, or one of the containing namespaces has no name, there is no qualified name. When there is a name, and all of the containing namespaces have a name, the qualified name is constructed from the names of the containing namespaces. (self.name -> isempty()or self.allnamespaces()-> select (ns ns.name -> isempty()) -> notempty())implies self. qualifiedname -> isempty() (self.name -> notempty()and self.allnamespaces()-> select (ns ns.name -> isempty ())-> isempty())implies self.qualifiedname = self. allnamespaces()-> iterate( ns : Namespace; result: String = self.name ns.name -> union(self.separator())-> union(result)) Relevant Rename nein nein für Relevant PullUp nein nein für 3 If a NamedElement is not owned by a Namespace, it does not have a visibility. namespace -> isempty()implies visibility -> isempty() nein nein Tabelle 3.5.: Constraints in NamedElement Die Constraints zu der NamedElement-Klasse thematisieren zum einen die Konstruktion des qualifizierenden Namen anhand des Namespaces (Constraints [1] und [2] in Kapitel 3.5). Da der qualifizierte Name (qualifiedname in NamedElement) als Werte-Attribut folglich nicht auf andere Elemente referenziert und somit nicht durch Subsetting/Derived Union in den Unterklassen sondern auf Basis dieser Constraints abgeleitet wird und ebenfalls nicht explizit gesetzt wird, handelt es sich bei diesen Constraints um Bildungsregeln, die durchgehend erfüllt sind. Bezüglich Constraint [3] in Kapitel 3.5 ist zu sagen, dass Property gemäß UML-Spezifikation einen Namespace besitzt, so dass Constraint [3] zur Vorgabe des Besitzes einer Sichtbarkeit für Property nicht zutrifft und infolgedessen nicht auf die Wohlgeformheit bei Rename- und PullUp-Property-Refaktorisierungen einwirkt Constraint-Regeln zu Element Die zu Element zugeordneten Constraints, welches die Wurzel-Entität aller Sprachelemente des UML-Metamodells ist, legen die Wohlgeformheit bezüglich der 19 vgl. (OMG 2011b) S. 99

57 3.3 Constraint-Regeln von UML2 45 OwnedElements- und Owner-Eigenschaften fest (vgl. Tabelle und Listings 3.10 und 3.11), wobei es sich bei diesen beiden Eigenschaften um abgeleitete Attribute, die als Derived Union gekennzeichnet sind und in den Unterklassen von Element über Subsetting konkretisiert werden. Da diese Eigenschaften durch die PullUp-Refaktorisierung tangiert werden, werden diese Constraints diskutiert. Nr. Beschreibung Constraint in OCL 1 An element may not directly or indirectly own itself. Relevant Rename für not self.allownedelements()-> includes(self) nein ja Relevant PullUp für 2 Elements that must be owned must have an owner. self.mustbeowned()implies owner -> notempty() nein ja allownedelements-operation in Element: 21 Tabelle 3.6.: Constraints in Element Element::allOwnedElements(): Set(Element); allownedelements = ownedelement -> union(ownedelement -> collect(e e. allownedelements())) Listing 3.10: allownedelements-operation für Element mustbeowned-operation in Element: 22 --The query mustbeowned() indicates whether elements of this type must have an owner. Subclasses of Element that do not require an owner must override this operation. Element::mustBeOwned() : Boolean; mustbeowned = true Listing 3.11: mustbeowned-operation für Element Aus Constraint [1] und Listing 3.10 lässt sich somit zusammenfassend folgende Constraint-Regeln transformieren: e element (e e.allownedelements()) (3.9) Analog zu der allparents-abfrage ist die allownedelements-operation rekursiv definiert und repräsentiert eine reflexiv-transitive Relation, so dass diese ein entsprechender Relation-Constraint gebildet werden kann. In Bezug auf Constraint [2] von Element ist die mustbeowned-operation in Property nicht überschrieben, so dass diese für Property zutrifft. Die owner-eigenschaft ist abgeleitet und heruntergebrochen auf Property handelt sich gemäß UML-Spezifikation um die class- oder owningassociation-assoziation 23, so dass folgende Constraint-Regel resultiert: 20 vgl. (OMG 2011b) S vgl. (OMG 2011b) S vgl. (OMG 2011b) S vgl. (OMG 2011b) S. 125f.

58 3.4 Sprachdefinition und Constraint-Regeln von Java 46 p properties p.class > 0 p.owningassociation > 0 (3.10) 3.4. Sprachdefinition und Constraint-Regeln von Java Für die Sprachdefinition, Faktenabfragen und Constraint-Regeln für constraintbasierte Refaktorisierungen von Java-Artefakten sind die Java Language Specifications von Oracle heranzuziehen (vgl. Kapitel 2.6.1). Da diese bereits Gegenstand vorangegangener Arbeiten waren und für Refacola bereits eine Realisierung der Java-Sprachdefinition inklusive des Info-Providers existiert, die ebenfalls die Constraint-Regeln auf Basis der Java Syntaxregeln umfasst, wird die Ableitung der Sprachdefinition und der Constraint- Regeln von Java daher als gegeben vorausgesetzt und an dieser Stelle nicht weiter vertieft Constraint-Regeln für sprachübergreifende Refaktorisierungen Wie in Kapitel erörtert, sind die Beziehungen zwischen Modell und Code bei Refaktorisierungen im modellgetriebenen Umfeld konsistent zu halten, so dass diese Beziehungen als Fakten für constraintbasierte Ko-Refaktorisierungen aufzufassen und durch die darauf anzuwendende Constraint-Regeln mit den erforderlichen Bedingungen zu belegen sind. Je nach Code-Generator werden Traces generiert (vgl. Kapitel 2.3.1), welche während der Ausführung die Transformation von Modell zu Code protokollieren und für die sprachübergreifende Faktenermittlung mit den darin enthaltenden Beziehungen zwischen Quell- und Zielelement verwendet werden können. Ein generischer Zugriff auf die Trace-Fakten 24 kann zum einen dann erfolgen, wenn die Trace-Fakten gleichartig sind und sich ausschließlich inhaltlich unterscheiden, was sich aber durch die nachfolgenden Kapitel zu EMF und Acceleo herauskristallisiert, nicht der Fall ist, da teilweise weitere und andere Elemente durch den jeweiligen Generator produziert werden. Zum anderen können die Trace-Fakten generisch abgefragt werden, wenn die generierten Traces analog zu dem UML-Metamodell auf Basis eines Modells mit entsprechendem Metamodell instanziiert werden und jeweils das gleiche Metamodell verwendet wird (vgl. Abbildung 3.6). Hierfür sind in der übergreifenden Sprachdefinition (vgl. Kapitel 2.6.1) die spezifischen Trace-Faktenabfragen zu definieren, die folglich auf den Transformationsregeln, die zur Generierung des Codes aus dem Modell herangezogen worden sind und generatorspezifisch sind, basieren, aber durch das Metamodell zur Laufzeit für ein bestimmtes Artefakt generisch ermittelt werden. Wenn die Transformationsregeln ebenfalls explizit auf Grundlage eines Modells vorliegen (vgl. Abbildung 3.6 UMLClass ->JavaKlasse), können diese Trace Abfrage-Definitionen analog zu UML durch Modell-zu-Modell Transformation erzeugt werden (vgl. Kapitel 3.2). Wenn keine Traces durch den Generator erstellt werden, sind diese folglich programmatisch zu erzeugen, um constraintbasierte Ko-Refaktorisierungen durchführen zu können.

59 3.5 Constraint-Regeln für sprachübergreifende Refaktorisierungen 47 Abbildung 3.6.: Transformation/Trace-Modell Analyse des EMF in Bezug auf Refaktorisierungen Abbildung 3.7 veranschaulicht, die Beziehungen zwischen Modell und Code und welche Code-Elemente aus den Elementen (Attribute und Klassen) im UML-Modell von dem EMF-Generator erzeugt werden. Neben der Generierung der korrespondierenden Java- Implementierungsklasse (C:Class) und der darin enthaltenden Getter-/Setter-Methoden (pgetterclass:method, psetterclass:method) werden ebenfalls automatisch zu jeder Klasse ein Java-Interface (C:Interface), welches nicht im UML-Modell modelliert ist, und zu jedem Attribut um Modell spezielle statische Felder (ID und Literal-Konstanten) und globale Zugriffsmethoden (pgetterpackageinterface:method) im sogenannten Package- Interface (vgl. Kapitel 2.5.2) produziert. Die Namen der generierten Java-Klassen werden mit dem Postfix Impl zu dem eigentlichen Entitätsnamen konkateniert, wohingegen die erzeugten Interfaces ausschließlich mit dem Entitätsnamen benannt werden. Diese Verbindungen (Traces) zwischen Modell und Code sind bei einem constraintbasierten Ansatz folglich als Faktenabfragen und darauf aufbauend in Constraint-Regeln zu definieren (vgl. Kapitel 3.5). Zum einen sind die Namenskonventionen zwischen dem Modellelement und den generierten Elementen einzuhalten, was insbesondere für Rename-Refakorisierungen entscheidend ist. Demzufolge ist der Name der Property im Namen des Getter-Accessors der Java-Implementierungsklasse enthalten, was durch folgenden Constraint-Regel ausgedrückt wird: p uml.properties getter java.methods getterinimplementation(p, getter) getter.name = get +p.name (3.11) Durch die übergreifende Trace-Faktabfrage getterinimplementation werden die zu einer Property korrespondiereden Getter-Methoden in der Implementierungsklasse ermittelt. Für die Getter-Methode in dem generierten Java-Interface ist eine vergleichbare Constraint-Regel zu definieren: 24 vgl. (von Pilgrim u. a. 2013) S. 685

60 3.5 Constraint-Regeln für sprachübergreifende Refaktorisierungen 48 Abbildung 3.7.: Traces EMF Code-Generator p uml.properties getter java.methods getterininterf ace(p, getter) getter.name = get +p.name (3.12) Analog gelten diese Constraint-Regeln für die Setter-Methoden. Für das eigentliche Feld in der Java-Implementierungsklasse sind in gleicher Weise die Constraint-Regeln zu deklarieren: p uml.properties f java.f ields f ieldinimplemenation(p, f) p.name = f.name (3.13) Für die EMF charakteristischen Felder und Methoden im Package-Interface sind desgleichen übergreifenden Constraint-Regeln festzulegen. Bezogen auf dem Beispiel in Kapitel wird die Methode getcar Color und das statische Feld CAR COLOR zu dem color-attribut im Package-Interface generiert. Diese Beziehung wird durch die folgenden Constraint-Regeln verifiziert, wobei getterinpackageinterface und fieldidinpackageinterface wiederum die Trace-Faktenabfragen verkörpern:

61 3.5 Constraint-Regeln für sprachübergreifende Refaktorisierungen 49 p uml.properties c uml.class getter java.methods getterinp ackageinterf ace(p, getter) p.class = c = f.name = get + c.name + + p.name (3.14) p uml.properties c uml.class f java.staticf ields f ieldidinp ackageinterf ace(p, f) p.class = c = f.name = upper(c.name) + + upper(p.name) (3.15) Anstelle des direkten Zugriffs mittels upper(p.class.name) in diesen Constraints, wird eine Implikation verwendet, um die Indirektion aufzulösen, da die class-eigenschaft bei PullUp-Refaktorisierungen variabel ist. Für das Literal-Feld ist eine gleichsame Constraint-Regel zu deklarieren, wobei das Literal-Feld äquivalent dem ID-Feld benannt und in einem inneren Interface innerhalb des Package-Inteface lokalisiert ist. Des weiteren sind die Besitzer der Property im Modell und Code konsistent zu halten, die primär bei PullUp-Refaktorisierungen variiert werden. Dazu ist für jedes zu einer Property generierte Element eine Constraint-Regel zu definieren, was exemplarisch für die Getter-Methode in der Implementierungsklasse demonstriert wird: p uml.properties getter java.methods uc uml.class jc Java.class getterinimplementation(p, getter) implementationof U mlclass(uc, jc) p.class = c = getter.owner = jc (3.16) Die Owner-Eigenschaft repräsentiert den Besitzer eines Elements und implementationofumlclass die Faktenabfrage, welche die generierte Java-Implementierungsklasse zu einer UML-Klasse recherchiert. Analog sind die Constraint-Regeln zu der Owner-Eigenschaft für die Getter-Methode im Interface, für die Setter-Methoden im Interface und der Implementierungsklasse und dem eigentlichen Feld in der Implementierungsklasse zu definieren. In Kapitel ist skizziert, dass bei der EMF Code-Generierung zunächst das UML- Modell in ein Ecore-Modell transformiert wird, so dass sich unter Umständen die Ko- Refaktorisierung auf eine Ecore Ko-Refaktorisierung reduzieren ließe. Da aber spezifische Eigenschaften in Form von Annotationen nicht über da Ecore-Modell, sondern direkt in das GenModel-Modell einfließen, die nicht im transformierten Ecore-Modell vorhanden sind (beispielsweise Einstellungen zu Redefiniton / Subsetting, welche als Annotationen im GenModel-Modell persistiert werden), ist die Ko-Refaktorisierung generell ausgehend vom UML-Modell bis zur Java Code-Generierung in den übergreifenden Constraint-Regeln zu betrachten. Wenn diese Annotationen, zum Beispiel ob Redefinition oder Subsetting für die Code-Generierung ignoriert oder verarbeitet werden soll, und diese für die sprachübergreifenden Constraint-Regeln relevant sind, sind folglich diese als Fakten neben den Trace-Fakten aus dem GenModel-Modell auszulesen. Im Hinblick auf das Tracing wird während der Code-Generierung von EMF kein Trace produziert, so dass dieser programmatisch zu erstellen ist. Ebenso liegen die Code- Transformationsregeln nicht explizit als Modell vor (JET-Template). Des weiteren wird bei detaillierter Analyse des von EMF generierten Codes (vgl. Listing 5.1) deutlich, dass die generierte Zuweisung des Wertes an die Feld-ID (in dem Beispiel- Listing CAR COLOR) nach einer Refaktorisierung, beispielsweise wenn das Color-Feld in eine andere Klasse verschoben wird, nicht mehr valide ist. Dieser Aspekt lässt sich constraintbasiert nur bedingt bzw. diffizil abbilden, da auf die Variabeln-Initialisierung und den Methoden-Body zurückgegriffen werden muss und bereits als dynamische Semantik ausgelegt werden kann (vgl. Kapitel 2.8.2). Hier ist folglich eine Regenerierung

62 3.5 Constraint-Regeln für sprachübergreifende Refaktorisierungen 50 nach der Ko-Refaktorisierung durchzuführen, um die Konsistenz zu wahren, was entsprechend in die Architektur zu integrieren ist. /** * The feature id for the <em><b>color</b></em> reference. * <!-- begin-user-doc --> * <!-- end-user-doc --> */ int CAR COLOR = VEHICLE_FEATURE_COUNT + 0; /** * The number of structural features of the <em>car</em> class. * <!-- begin-user-doc --> * <!-- end-user-doc --> */ int CAR_FEATURE_COUNT = VEHICLE_FEATURE_COUNT + 1; Listing 3.12: Ausschnitt per EMF generierter Code im Package-Interface Interface Analyse des Acceleo-Generators in Bezug auf Refaktorisierungen Abbildung 3.8.: Traces Acceleo Code-Generator Durch Abbildung 3.8 werden die Beziehungen zwischen Modell und generiertem Code visualisiert, wenn der Code mit der Standard-Vorlage von Acceleo erzeugt wird (vgl. Kapitel 2.5.2). Neben den Accessoren und der Java-Klasse werden keine spezifischen und weiteren Code-Elemente produziert, so dass die Constraint-Regeln 3.11, 3.13 und 3.16, die in Kapitel zu EMF diskutiert worden sind, analog für Acceleo gelten, wobei die Ermittlung der Trace-Fakten unterschiedlich ist. Zum einen werden bei EMF keine Trace erzeugt und zum anderen ist bei programmatischer Ermittlung der Traces der Klassenname zwischen Acceleo und EMF unterschiedlich. Während bei EMF die Namen der erzeugten Klassen auf Impl enden (vgl. Kapitel 3.5.1), wird bei Accelo kein Postfix hinzugefügt. Im Kontrast zu EMF werden bei Acceleo Traces erstellt, die in der Entwicklungsumgebung sichtbar sind (vgl. Abbildung 3.9). Jedoch werden diese nicht serialisiert, so dass

63 3.6 Definition von sprachübergreifenden Refaktorisierungen zwischen UML2 und Java51 ohne Erweiterung an Acceleo keine generische Abfrage der Trace-Fakten möglich ist und die Abfragen nicht generiert und selbst zu definieren sind, wobei diese aber mit den Abfragen von EMF korrespondieren, wie bspw. implementationofumlclass. Unter der Vorraussetzung, dass die Traces serialisiert werden und das Trace-Modell beispielsweise auf dem Ecore Meta-Metamodell basiert, kann die Faktenabfrage generisch erfolgen, auch wenn das Acceleo-Template zur Code-Generierung angepasst wird. In diesem Fall sind ausschließlich die Fakten-Abfragen für die Traces in der (Refacola-)Sprachdefinition anzupassen bzw. zu erweitern. Abbildung 3.9.: Generierte Traces mit Acceleo Code-Generator in Eclipse 3.6. Definition von sprachübergreifenden Refaktorisierungen zwischen UML2 und Java Rename Property-Refaktorisierung Wie aus Kapitel und dem Kapitel zur Ableitung der Constraint-Regeln (Kapitel 3.3) deutlich wird, wird die name-eigenschaft der Property im UML-Modell durch die Intention dieser Refaktorisierung geändert, so dass diese Eigenschaft variabel ist. Diese Änderung zieht im Zusammenhang mit übergreifen Ko-Refaktorisierungen zwischen Modell und Code weitere Anpassungen nach sich, so dass die von Anpassungen betreffenden Eigenschaften den variablen und erlaubten Änderungen der Refaktorisierung zuzuordnen sind, die sich aus den oben stehenden Beziehungen zwischen Modell und Code resultieren: Name (Identifier) von Java-Feldern (korrespondierendes Feld der UML-Property) Name (Identifier) von Java Feldreferenzen Name (Identifier) von Java-Methoden(für die Accessor- und weitere Methoden, die laut Trace mit dem geänderten Attribut in Beziehung stehen) Name (Identifier) von Java-Methodenreferenzen Im Kontrast zu der AST-basierten Abbildung von Java-Programmen, bei denen Referenzen, wie Feldreferenzen und Methodenreferenzen, als eigene Entität in der Sprachdefinition vorliegen, existieren bei dem UML-Metamodell keine Referenzentitäten. Dieses

64 3.7 Zusammenfassung 52 ist so, da ein Modell als Instanz eines Metamodells (vgl. Kapitel 2.2.3) direkt auf die jeweiligen Objekte referenziert, so dass durch die gegebene Referenzsemantik geänderte Eigenschaftswerte an den Stellen im Modell, an denen auf das jeweilige Objekt verwiesen wird, nicht angepasst werden müssen bzw. können. Demzufolge sind bei den erlaubten Änderungen der Rename-Refaktorisierung keine weiteren Eigenschaften für das Modell zu definieren PullUp Property-Refaktorisierung Durch die Intention der PullUp Property-Refaktorisierung wird die class-eigenschaft eines Attributs geändert und durch die Oberklasse ersetzt (vgl. Kapitel 2.1.2). Aufgrund der bidirektionalen Assoziation zwischen Property und Class 25 wird die ownedattribute- Eigenschaft von Class, welche eine Untermenge der member-assoziation darstellt 26, ebenfalls implizit aktualisiert (vgl. Kapitel zur Ableitung der Constraint-Regeln 3.3). Aus der Änderung der class-eigenschaft ergeben sich im Kontext der Ko-Refaktorisierung weitere Änderungen, die aus der Relation zwischen Modell und Code resultieren und folglich als variable und erlaubte Änderungen für diese Refaktorisierung zu definieren sind: Besitzer (Owner) von Java-Feldern (korrespondierendes Feld der UML-Property) Besitzer (Owner) von Java-Methoden (für die korrespondierenden Accessor- Methoden Ob die Sichtbarkeit angepasst werden darf, ist von der Intention des Benutzers abhängig und ließe sich gleichermaßen als erlaubte Änderung spezifizieren. Wie aus Kapitel hervorgeht, werden bei EMF Code-Elemente produziert, dessen Namen aus Klassen- und Attributnamen kombiniert werden (bspw. der Name für die Getter-Methode im PackageInterface). Da sich die Klasse durch die Refaktorisierungsintention ändert, sind weitere erlaubte Änderungen für EMF zu deklarieren, so dass sich die variablen Änderungen zwischen EMF und Acceleo unterscheiden. Ferner sind daher folgende Eigenschaften zu bestimmen: Name (Identifier) von Java-Feldern (für ID- und Literal-Felder im Package- Interface, der sich aus Klassen- und Attributnamen zusammensetzt) Name (Identifier) von Java Feldreferenzen Name (Identifier) von Java-Methoden (für Getter-Methoden im Package-Interface, der sich aus Klassen- und Attributnamen zusammensetzt) Name (Identifier) von Java-Methodenreferenzen 3.7. Zusammenfassung Im Verlauf dieses Kapitels ist der constraintbasierte Ansatz tiefergehend untersucht worden. Die für Rename- und PullUp Property Refaktorisierungen relevanten Wohlgeformt- 25 vgl. (OMG 2011b) S vgl. (OMG 2011b) S. 48

65 3.7 Zusammenfassung 53 heitsbedingungen des UML Superstruktur-Spezifikation sind dabei in Constraint-Regeln transformiert worden, die nun in domänenspezifische Sprachen für constraint-basierte Refaktorisierungen unter den genannten Bedingungen wie Refacola implementiert werden können. Wie sich hier gezeigt ist die Transformation der Wohlgeformtheitsbedingungen ein umfangreicher und von der jeweiligen Refaktorisierung und dem Refaktorisierungssubjekt abhängiger Prozess. Die abgeleiteten Eigenschaften in der UML- Spezifikation sind jeweils in eigenen Constraint-Regel bezogen auf den jeweiligen Typ zu konkretisieren, so dass aus einer Wohlgeformtheit-Regel mehrere Constraint-Regeln folgen. Wie in Kapitel 3.5 erörtert, ist die generische Abfrage der Trace-Fakten davon abhängig, ob zum einen Traces auf Basis eines Trace-Modells in serialisierter Form erstellt werden und zum andern ob analog des UML-Metamodells das Transformations- und Trace- Metamodell Instanz eines Meta-Metamodells ist und dessen Beziehungen explizit sind, was für EMF und Acceleo nicht zutrifft. Ferner ist aus Kapitel 3.5 deutlich geworden, dass die sprachübergreifende Abfragen und Constraint-Regeln für Ko-Refaktorisierungen sich je nach Code-Generationsprogramm differenzieren. Hinsichtlich der Architektur sind die Trace-Beziehungen und übergreifenden Constraint-Regeln so zu gestalten, dass gemeinsame herausgearbeitet und abstrahiert werden, und diese entsprechend durch die speziellen Eigenschaften der Code-Generierungsprogramm erweitert werden können. Auf dieser Basis der Analyse wird die Architektur für Ko-Refaktorisierungen und deren Umsetzung diskutiert.

66 54 4. Konzeption und Implementierung des Ko-Refaktorisierung-Plugins In diesem Kapitel wird die Architektur für Ko-Refaktorisierungsprogramme auf Grundlage der in Kapitel 2 erörterten Methoden und Anforderungen sowie der Analysen in Kapitel 3 diskutiert Gesamtarchitektur Aus Basis der Analyse in Kapitel 3 leitet sich die Gesamtarchitektur ab, die in Abbildung 4.1 visualisiert ist. Zentraler Kern ist die Komponente de.feu.ps.refacola.ecore.lang.javaxuml. Wie in Abbildung 4.1.: Gesamtübersicht Komponenten-Modell Kapitel 2.8 und 2.9 resümiert, soll die Architektur auf Erweiterbarkeit ausgelegt sein. Um dieses in Hinsicht auf die Einbindung weiterer Code-Generatoren für Ko-Refaktorisierungen zu gewährleisten, wird diese Komponente durch weitere Komponenten für spezifische Generatoren, wie EMF und Acceleo, analog einem Framework-Konzept konkretisiert, in dem die spezifischen Beziehungen zwischen Modell und Code und die spezifischen Ko-Refaktorisierungen implementiert werden. Dieses ist erforderlich, da sich Ko-Refaktorisierungen abhängig vom Generator individuell verhalten (vgl. Kapitel 3.5.1,3.5.2 und 3.6). Des weiteren ist es für constraintbasierten Refaktorisierungen notwendig, die Fakten, Eigenschaften und Elemente des zu refaktorisierenden Artefakts abzufragen, um Constraint-Regeln auf dem Artefakt anzuwenden und Constraints zu erzeugen, die

67 4.2 Komponenten 55 an dem Constraint-Solver weitergegeben werden. Im Refacola-Kontext wird dazu das Artefakt in eine Instanz der domänenspezifischen Refacola-Sprache transformiert, welches mittels eines Info-Providers durchgeführt wird. Da bei constraintbasierten Refaktorisierungen das Artefakt aus dem UML-Modell und dem Java-Code besteht, sind folglich Info-Provider für UML, Java und ein Info-Provider für die Beziehungen zwischen Modell und Code (Traces, vgl. Kapitel 2.8.1), die in einem Info-Provider bestehend aus mehreren Info-Providern (Multinfo-Provider) in der de.feu.ps.refacola.ecore.lang.javaxuml-komponente zusammengefasst werden. Für Java existiert bei Refacola bereits ein Info-Provider, der mit den Java Development Tools (JDT) auf den AST eines Programms zugreift. Die Refacola-Sprachdefinition, Queries, und Constraint-Regeln für Java-Programme sind in der de.feu.ps.refacola.lang.java- Komponente enthalten, die vom JDT Info-Provider auf Basis des konkreten Artefakts entsprechend instanziiert werden (vgl. Grundlagen und Architektur von Refacola in Kapitel 2.6.1). Bezüglich des Info-Providers für UML-Modelle ist aus Kapitel 2 und 3 deutlich geworden, dass ein Metamodell wie das von UML2 eine Instanz eines Meta-Metamodells ist. Da UML2 im Eclipse-Kontext auf dem Ecore Meta-Metamodell basiert, kann für die Ermittlung der Fakten eines UML2-Modell der GenericEcoreInfoProvider aus der de.feu.ps.refacola.ecore-komponente verwendet werden, für den ebenfalls bereits eine Implementierung im Refacola-Framework vorliegt (vgl. Kapitel 2.6.1), so dass keine spezifische Implementierung eines Info-Providers für UML2, so wie es bei Java/JDT der Fall ist, notwendig ist. Die Komponente de.feu.ps.refacola.ecore.lang.uml umfasst dabei die generierte Refacola-Sprachdefinition, welche die Elemente, Eigenschaften und Queries für UML2 beinhaltet (vgl. Kapitel 3.2), und die abgeleiteten UML2-Constraint- Regeln (vgl. Kapitel 3.3), die vom GenericEcoreInfoProvider auf Basis des Ecore UML-Metamodells für ein konkretes UML-Modells instanziiert werden. Folglich setzt sich die de.feu.ps.refacola.ecore.lang.javaxuml-komponente aus den de.feu.ps.refacola.api-, de.feu.ps.refacola.lang.java-, de.feu.ps.refacola.lang.java.jdt-, de.feu.ps.refacola.ecore- und de.feu.ps.refacola.ecore.lang.uml-komponenten zusammen. Der Info-Provider für die Beziehungen zwischen dem Modell und dem generierten Code (Trace Info-Provider) wird abstrakt in der de.feu.ps.refacola.ecore.lang.javaxuml- Komponente definiert und aufgrund der vom Code-Generator abhängigen Beziehungen in den spezialisierten Komponenten für EMF und Acceleo implementiert und erweitert. Infolgedessen besteht auch eine Abhängigkeit zur de.feu.ps.refacola.api-komponente, die den zentralen Kern von Refacola enthält (vgl. Grundlagen und Architektur von Refacola in Kapitel 2.6.1). Ebenso soll sich das Plugin für Ko-Refaktorisierungen in die Entwicklungsumgebung integrieren, was durch die de.feu.ps.ecore.lang.javaxuml.ui-komponente mit Verbindung zu dem Eclipse Language Toolkit (vgl. Kapitel 2.4.2) umgesetzt wird. Damit die Logik und Anwendungskern der Ko-Refaktorisierung in anderen Kontexten wiederverwendet werden kann, ist diese UI-Komponente von der de.feu.ps.ecore.lang.javaxuml- Komponente separiert Komponenten Factory-Komponente Um eine konkrete Abhängigkeit der oberen Schichten, zu denen auch die UI-Komponente zählt, zu den konkreten Implementierungen der Ko-Refaktorisierungskomponenten der jeweiligen spezifischen Code-Generatoren, wie in diesem Fall EMF und Acceleo, zu vermeiden, wird eine Factory-Komponente eingesetzt. Diese setzt das bekannte

68 4.2 Komponenten 56 Abbildung 4.2.: Factory-Komponente im Kontext Fabrik-Muster aus der Software-Architektur um. 1. Des weiteren dient die Factory- Komponente dazu, die konkreten Erzeugungen zu kapseln. Abbildung 4.2 zeigt die Factory-Komponente im Kontext. Wie aus Kapitel 3.5 und 3.6 hervorgeht, sind zum einen die Ko- Abbildung 4.3.: Abstrakte Factory-Klassen für Trace Info-Provider und Refactoring Refaktosierungendefinitionen, insbesondere bezüglich der variablen Eigenschaften einer Refaktorisierung, als auch zum anderen die Tracedefinitionen zwischen Modell und Code spezifisch. Daher wird eine Factory-Klasse für den Trace Info-Provider und eine Factory-Klasse je Refaktorisierung definiert, die jeweils die konkreten Implementierungen für das entsprechende Code-Generierungsframework instanziieren (vgl. Abbildung 4.3). Da die Refaktorisierung-Klassen mittels Refacola generiert werden, existiert pro Refaktorisierung eine Adapter-Klasse, der in der jeweiligen konkreten Komponente implementiert wird und folglich durch die jeweilige Factory-Klasse erzeugt wird. Gemäß dem Prinzip der abstrakten Fabrik besteht pro Code-Generator eine Ableitung der jeweiligen Factory-Klassen. Um von außen ausschließlich auf eine Fabrik-Oberklasse 1 vgl. (Gamma u. a. 1995) Kapitel 3

69 4.2 Komponenten 57 zugreifen zu müssen, ist hier die statische Methode zu Erzeugung deklariert Allgemeine Komponenten (Framework für Ko-Refaktorisierungen) Im Folgenden werden die Bestandteile abgeleitet, die die Komponente de.feu.ps.ecore.lang.javaxuml betreffen, und allgemein für Ko-Refaktorisierungen im UML- und Java-Kontext relevant sind. Info-Provider und Tracing Abbildung 4.4.: MultiProgrammInfoProvider für Ko-Refaktorisierungen Wie in Kapitel 4.1 aufgezeigt, besteht der Info-Provider für constraintbasierte Ko- Refaktorisierungen für UML und Java aus dem generischen Ecore Info-Provider für das UML-Model, dem Java Info-Provider und dem Info-Provider für die Traces. In Kapitel ist des weiteren thematisiert worden, dass im MDA-Kontext oftmals aus einem PIM-Modell zunächst ein PSM-Modell erstellt und nachfolgend der Code erzeugt wird. Um dieses ebenfalls abbilden zu können, wird die abstrakte Oberklasse AbstractArtifactXModelInfoProvider modelliert, in dem der Info-Provider für das Ausgangsmodell (source in Abbildung 4.4) der generische Ecore Info-Provider und der Info-Provider des Ziel-Artefakts (target in Abbildung 4.4) vom Typ eines abstrakten Info-Providers ist, so dass dieser entweder wieder mit dem generischen Ecore Info-Provider (bspw. in diesem Fall für das PSM-Modell) oder mit einem Info-Provider für Code instanziiert werden kann. Für eine durchgängige Refaktorisierung über mehrere Modelle hinweg bis zum Code, können die AbstractArtifactXModelInfoProvider durch den Multinfo-Provider wiederum verkettet werden. In der geerbten JavaXModelInfoProvider-Klasse, der im Endeffekt als übergreifender Info-Provider für Ko-Refaktorisierungen zwischen Modell- und Java-Artefakten dient, wird der Java Info-Provider instanziiert und als Target-Info-Provider zugewiesen.

70 4.2 Komponenten 58 Der JavaXModelInfoProvider dient im weiteren Verlauf als Info-Provider für Ko- Refaktorisierungen mit EMF und Acceleo, da Zwischenmodelle gemäß nach OMG bei EMF und Acceleo in der Standard-Version keine Relevanz haben (bezüglich des bei EMF vor der Code-Generierung zu erstellende Ecore- und GenModel-Modell handelt es sich nicht um ein PSM-Modell im eigentlichen Sinne, sondern um einen Zwischenschritt, der gegebenenfalls im Trace Info-Provider zu berücksichtigen ist, vgl. Kapitel und 3.5.1). Da der Info-Provider für die Traces, der die Fakten für die Beziehungen zwischen Modell und Code erfasst, abhängig vom jeweiligen Code-Generator sind (vgl. Kapitel 3.5), wird hierfür eine abstrakte Oberklasse (AbstractTraceInfoProvider) definiert (vgl. Abbildung 4.5). In einer von dieser Klasse geerbten Klasse können bspw. die von einem Code-Generator erzeugten Traces ausgelesen und darauffolgend als Fakten bereitgestellt werden. Wenn die Traces von dem Code-Generator nicht erstellt werden, so wie es bei EMF der Fall ist, sind diese programmatisch zu erzeugen, wofür die von der Basisklasse erweiterte AbstractTraceGeneratorInfoProvider-Klasse eingeführt wird, die eine Liste von Trace- Generatoren enthält (vgl. Abbildung 4.5). In der konkreten Implementierung ist die inittracegenerators-methode zu implementieren, die die für einen Code-Generator spezifischen Trace-Generatoren instanziiert und der Liste der Trace-Generatoren hinzufügt. Für die jeweilige Tracegenerierung steht das ITraceGenerator-Interface zur Verfügung, welche für das in der generatetrace-methode übergebene UML-Element den Trace zum generierten Code-Element zurückgibt. Im Rahmen der Faktenermittlung wird im TraceGeneratorInfoProvider über alle Elemente des Modells und darauffolgend über alle Trace-Generatoren iteriert, um alle Trace-Fakten zu registrieren. Abbildung 4.5.: Trace Info-Provider und Trace Info-Provider mit Trace-Generatoren Accessor-Functions Im Java-Kontext ist es gängige Konvention, dass der Zugriff auf Felder einer Klasse von außerhalb nicht direkt, sondern über Getter- und Setter-Methoden (Accessor- Methoden) erfolgt. Dieses wird ebenfalls bei gängigen Code-Generatoren (vgl. Kapitel 3.5 umgesetzt, so dass aus Attributen im Modell neben den Feldern im Code die Accessor- Methoden generiert werden. Diese Beziehung zwischen Attribut und generierten Getter-

71 4.2 Komponenten 59 und Setter-Methoden ist folglich auch bei Ko-Refaktorisierungen zu berücksichtigen und als übergreifende Constraint-Regel zu definieren (vgl. Kapitel 3.5), in der Hinsicht, dass der Name der Getter- und Setter-Methoden gleich dem Namen des Attributs inklusive der get bzw. set -Präfixe ist. In Refacola werden für die Generierung der Solver-Constraints die Werte einer Domäne, die für eine Eigenschaft (Constraint-Variable) eines Elements eingesetzt werden, Integer- Werte zugeordnet (vgl. Kapitel 2.6.1), so dass die String-Konkatenation aus get bzw. set und dem Attributnamen nicht direkt im Solver-Constraint abgebildet werden kann. Daher findet das Function-Konzept von Refacola Anwendung (vgl ), mit dem eine Funktionsrelation ausgedrückt wird und wofür Refacola das IConstraintChecker- Interface vorsieht (vgl. Kapitel 2.6.1). Während des Constraint-Solvings wird dabei die Überprüfung des Accessor-Constraints an eine Function-Klasse delegiert, die das IConstraintChecker-Interface und die arerelated-methode implementiert. In der Function-Klasse wird das übergebene Integer-Tupel, was in diesem Fall aus zwei Elementen besteht und effektiv auf die Namenseigenschaft des Attributs und auf die Namenseigenschaft der Accessor-Methode abbildet, wieder mithilfe der Identifier-Domäne, welche die Domäne von Namen von Programmelementen repräsentiert, in die stringbasierten Eigenschaftswerte übersetzt und der zusammengesetzte Methodenname gebildet, der mit dem im Tupel repräsentierten Methodennamen verglichen wird. Wenn der Vergleich positiv ist, ist das übergebene Tupel mit der Zuordnung folglich valide und der Constraint erfüllt, was durch den booleschen Rückgabewert entsprechend angezeigt wird. Die Function stellt dabei einen Operanden der Constraint-Regel dar (vgl. Listing 4.1) und ist analog zu den anderen Operandentypen in Refacola als Function-Klasse in der Refacola-API implementiert 2. language javaxuml queries getterinimplementationofumlproperty(aproperty: uml.property, getter: Java.Method)... functions Identifier accessorgettername (attributename: Identifier) "de.feu.ps.refacola.lang.javaxuml.functions.accessorgetternamefunction"... ruleset javaxuml languages javaxuml, Java, uml rules propertygetterimplemenation for all aproperty: uml.property getter: Java.Method do if javaxuml.getterinimplementationofumlproperty(aproperty, getter) then getter.identifier = call javaxuml.accessorgettername(aproperty.name) end... Listing 4.1: Accessor-Function in Constraint-Regel Da analog zu den Eigenschaften auch zu den Functions eine Codomäne generiert wird, kann der Durchschnitt zwischen der Codomäne der Eigenschaft und der Codomäne der Function gebildet werden, so dass vorab oftmals bei der Constraint-Generierung bereits die Domäne für die Lösung soweit reduziert werden kann, dass die Constraints mit den Function-Aufrufen für die Accessor-Namen bereits vor dem Solving erfüllt werden. Ein alternativer Ansatz, der in (von Pilgrim u. a. 2013) erörtert wird, ist, eine Sprachdefinition für Strings und eine Faktenbasis zu verwenden, in der alle relevanten String-Konkatenationen für Accessor-Methodennamen enthalten sind und die mittels einer Konkatenation-Query, die innerhalb der Constraint-Regel benutzt wird, abgefragt 2 im Rahmen dieser Arbeit in der Refacola API-Komponente die Function-Klasse angepasst worden, da diese nicht final implementiert war

72 4.2 Komponenten 60 werden kann. Da bspw. im Rahmen einer Rename-Refaktorisierung eines Attributs nicht unzählige Text- bzw. String-Kombinationen durch den Constraint-Solver getestet werden, bis der korrespondierende Methodenname eines Accessors gefunden wird, sondern die Ziel- Domäne (Codomäne) der einsatzbaren Belegungen für die änderbaren Eigenschaften einer Refaktorisierung auf die im Programm vorhanden Element-Instanzen des jeweiligen Typs bzw. auf den vom Benutzer vorgegebenen Eigenschaftswert beschränkt wird, wird folglich nach Definition des obigen Accessor-Constraints keine Lösung gefunden. Dies bedeutet, dass der entsprechende neue Accessor-Methodename zu generieren und der Codomäne für die Namenseigenschaft der Methode als möglicher Wert hinzuzufügen ist, damit der Constraint-Solver diesen Wert für den Accessor einsetzen und eine Lösung für das CSP finden kann, mit dem der obige sprachübergreifende Constraint für die Accessoren erfüllt wird. Da in der Function-Klasse für die Überprüfung des Constraints der Accessor-Methodennamen bereits erzeugt wird, implementiert diese Klasse ebenfalls das IGenerator-Interface, mit dem Werte für die Codomäne einer Eigenschaft eines bestimmten Elementes hinzugefügt werden (in diesem Fall die Methodennamen für die Accessoren). Zusammengefasst implementiert die Function-Klasse folglich Abbildung 4.6.: Funktionen zur Generierung und Constraint-Überprüfung der Accessor-Methodennamen das IConstraintChecker-Interface für die Constraint-Überprüfung und das IGenerator- Interface zur Generierung möglicher Werte für die Codomäne und nimmt somit unterschiedliche Rollen je nach Kontext wahr (Interface Segregation Principle) 3. Für die Accessoren-Namen wird dafür eine abstrakte Oberklasse AbstractNameFunction gebildet, die beide Interfaces implementiert, für die es jeweils für die Getter- und Setter-Methode eine Ableitung gibt (vgl. Abbildung 4.6). Die Implementierung des IGenerator-Interfaces erfolgt dabei durch Ableitung der AbstractGenerator-Klasse. In der AbstractGenerator-Klasse sind die Template-Parameter (Generics in Java) Source-Typ (SoureT) und Target-Typ (TargetT) definiert. Der Target-Typ Platzhalter repräsentiert den Typ der Codomäne, welcher bei den Functions für die Namen-Eigenschaften der Accessor-Methoden der String-Typ ist. Der Source-Typ bei den Name-Functions 3 vgl. (Martin 2002) S. 135

73 4.2 Komponenten 61 ist ebenfalls String, da die Werte für die Codomäne der Accessor-Methoden ausgehend von dem Namen einer Property im UML-Modell erstellt werden. Mittels der istracerelationship-methode dieser Klasse wird geprüft, ob zwischen dem Element aus dem UML-Modell, dessen (Namens-)Eigenschaft im Rahmen der Refaktorisierung geändert wird, und dem übergebene Programmelement, wie bspw. der Accessor- Methode, aus dem generierten Java-Code eine Beziehung besteht. Wenn dies zutrifft wird mittels der getcalculatedpropertyvalue-methode in der jeweiligen Unterklasse der neue Accessor-Methodenname errechnet und der Codomäne der Namenseigenschaft dieses Code-Element hinzugefügt. Dieses Vorgehen lässt sich folglich generell auf jede Eigenschaft anwenden und ist im Kontext dieses Kapitels aber anhand des Accessor- Methodennamen veranschaulicht worden. Bezüglich des Besitzers (Owner) der Accessor-Methoden ist ebenfalls einer Constraint- Regel zu definieren (vgl. Listing 4.2), welche primär bei PullUp-Refaktorisierungen einzuhalten ist, dass die besitzende Klasse des entsprechenden Attributs im UML-Modell gleich der korrespondierenden Klasse/Interface der Accessor-Methoden im Code ist. Hierfür ist keine Function/ConstraintChecker in der Constraint-Regel erforderlich, da die Abbildung 4.7.: Funktionen zur Generierung der korrespondierenden Besitzer der Accessor-Methoden möglichen Werte der Owner-Eigenschaft im Gegensatz zu den Accessor-Methodennamen in der entsprechenden Domäne vorhanden sind und somit für die Constraint-Generierung Integer-Tupeln zugeordnet werden können. propertygetterimplementationowner for all getter: Java.Method aproperty: uml.property javaclass : Java.TopLevelClass umlclass : uml.class do if javaxuml.getterinimplementationofumlproperty(aproperty, getter), javaxuml.implementationofumlclass(umlclass, javaclass) then aproperty. Class= umlclass -> (getter.owner = javaclass and getter.tlowner = javaclass)

74 4.2 Komponenten 62 end Listing 4.2: Übergreifende Constraint-Regel Accessor-Owner Es ist aber in der Refaktorisierungsdefinition sinnvoll, die Codomäne der änderbaren Owner-Eigenschaft der Accessor-Methode einzuschränken, um das Constraint-Solving zu optimieren und die Effizienz-Anforderung (vgl. Kapitel 2.9.4) zu erfüllen, da hier ausschließlich die korrespondierende Java-Klasse zu der UML-Klasse der Property Betracht kommt. Analog zu den Accessor-Methodennamen existiert dazu die Oberklasse AbstractAccessorOwnerFunction (vgl. Abbildung 4.7), die das IGenerator-Interface implementiert und die Codomäne der Owner-Eigenschaft der Accessor-Methoden auf Basis der refaktorisierten UML-Klasse mit der korrespondierenden Java-Klasse initialisiert. Hier ist der Target-Typ für die Codomäne der Owner-Eigenschaft die Refacola Java- Klasse (RefacolaTopLevelType, vgl. Abbildung 4.7) und der Source-Typ ist die Refacola UML-Klasse (RefacolaClass, vgl. Abbildung 4.7), auf dessen Basis die korrespondierende Java-Klasse für die Codomäne errechnet wird. Composed-Generator Abbildung 4.8.: Composed Generator Wie aus dem vorherigen Kapitel deutlich wird, ist die Zielmenge (Codomäne) der möglichen Werte für Eigenschaften von Programmelementen, die im Rahmen einer Refaktorisierung geändert und vom Constraint-Solver für die Lösung des CSPs getestet werden, mittels implementierter Generatoren zu erweitern, die bspw. angewendet auf Accessoren die Methodennamen auf Basis des Namens eines Attributs generieren und der Domäne hinzufügen. Da pro Eigenschaft in Refacola in der Refaktorisierungsdefinition ausschließlich ein Generator angegeben werden kann, aber bspw. für Accessoren sowohl die Getter- als auch die Setter-Namen für die Codomäne zu generieren sind, die jeweils in eigenen Generator/Function-Klassen gebildet werden, wird das Kompositum-Muster 4 angewendet (vgl. Abbildung 4.8), der die Getter- und Setter-Generatoren zusammenfasst und als ein Generator in der Refacola-Definition angegeben wird (vgl. Listing 4.3). refactoring renameproperty language javaemfxuml uses javaemfxuml, javaxuml, Names, uml forced changes name of uml.property as propertyname allowed changes name of uml.property to {initial, forced} identifier of Java.Method to {initial, computed } generator ".functions. ComposedAccessorNameGenerator" identifier of Java.MethodReference to {initial, computed} generator ".functions. ComposedAccessorNameGenerator" 4 vgl. (Gamma u. a. 1995) Kapitel 4

75 4.2 Komponenten Listing 4.3: Beispiel-Anwendung des ComposedGenerators in der Refacola-Definition Post-Regenerierung In Kapitel 3.5hat sich herauskristallisiert, dass es nach einer Ko-Refaktorisierung, durch die die relevanten Änderungen am Model und am generierten und nicht-generierten Code bereits durchgeführt worden sind, für die Konsistenz der inneren Struktur und der dynamischen Semantik des generierten Codes erforderlich sein kann, eine Regenerierung auf Basis des jeweiligen Code-Generators durchzuführen. Mit der applychangeset-methode im Info-Provider werden die aus der Refaktorisie- Abbildung 4.9.: Post-Regenerierung Ablauf rung im Refacola-Modell errechneten Anpassungen in Change-Objekte für die native Umgebung, bspw. für Eclipse auf Basis Eclipse Language Toolkit, übersetzt, die im Nachgang vollzogen werden (bei Eclipse LTK mit der perform-methode). Die Post- Regenerierung ist folglich dann durchzuführen, nachdem diese Änderungen auf das bzw. den Artefakten angewendet worden sind. In der AbstractArtifactXModelInfoProvider- Klasse ist die applypostgenerations-methode für diesen Zweck bestimmt, in der die zugeordneten Post-Generatoren ausgeführt werden (vgl. Sequenzdiagramm 4.9). Für die Realisierung der spezifischen Post-Regenerierungen ist das IGeneration-Interface vorgesehen, das entsprechend für den jeweiligen Code-Generator zu implementieren ist (vgl. Abbildung Da der Trace Info-Provider generator-spezifisch ist, ist hier die initpostgenerations-methode zu überschreiben, in der die konkreten Implementierungen der framework-abhängigen Post-Generatoren instanziiert und gesetzt werden, die in der applypostgenerations-methode der AbstractArtifactXModelInfoProvider-Klasse aufgerufen werden. Die Annullierung (Undo) von bereits abgeschlossenen Refaktorisierungen ist in diesem Kontext ebenfalls zu betrachten (vgl. Kapitel 2.8.3). Für die Erstellung der Undo-Aktionen, welche die vorangegangene Refaktorisierung wieder rückgängig machen, ist die vom Refacola-Framework vorgegebene createundochangeset-methode im Info Provider-Interface vorgesehen. 5. Diese Methode erzeugt die Undo-Änderungen im 5 Anm.: in der bestehenden JavaFactbase-Klasse ist die Undo-Funktionalität nicht implementiert

76 4.2 Komponenten 64 Abbildung 4.10.: Post-Regenerierung Refacola-Modell, welche wiederum mit der applychangeset-methode in native Change- Objekte transformiert werden können. Analog zu der eigentlichen Durchführung der Ko-Refaktorisierung ist die Post-Generation bei der Annullierung nach Anwendung der applychangeset-methode mit den Undo-Änderungen als Parameter und der nachfolgenden nativen Ausführung wieder anzustoßen, so dass der Code auf Basis rückgängig gemachten Anpassungen regeneriert wird Spezifische Komponenten für EMF Code-Generator Die konkreten Beziehungen zwischen UML-Modell und dem generierten Code für den EMF Code-Generator sind in Kapitel dargestellt worden. Diese spezifischen Beziehungen wie der zusätzlichen globalen Accessor-Methode und der FieldID/Literal-Felder im Package-Interface sind daher analog zu den Standard-Accessoren als zusätzliche Queries für die Traces und als sprachübergreifende Constraint-Regeln in Refacola zu realisieren. Folglich sind auch hierfür weitere Function-Klassen zu definieren, die von der AbstractNameFunction-Klasse erben (vgl. Abbildung 4.11). Da sich die Namen dieser Abbildung 4.11.: Funktionen zur Generierung und Constraint-Überprüfung der EMFspezifischen Accessor-Methodennamen und Feldnamen generierten Elementen aus Klassennamen und Attributnamen zusammensetzen (bspw. CAR COLOR für ID-Feld oder getcar Color für den globalen Accessor im Package- Interface, vgl. Kapitel 3.5.1), ist dies entsprechend sowohl bei den Rename- als auch

77 4.2 Komponenten 65 Abbildung 4.12.: Funktionen zur Generierung und Constraint-Überprüfung der EMFspezifischen Accessor-Methodennamen und Feldnamen Abbildung 4.13.: Funktionen zur Generierung und Constraint-Überprüfung der EMFspezifischen Accessor-Methodennamen und Feldnamen bei den PullUp-Refaktorisierungen zu berücksichtigen. Da je nach Refaktorisierung die geänderte Eigenschaft der Name (Identifier) oder der Besitzer (Owner) ist, ist dies unterschiedlich für die Generierung der Werte für die Codomäne der Namenseigenschaften der ID-Felder und Accessoren im Package-Interface zu behandeln. Beim ersteren wird das Postfix ( COLOR) des Namens dieser Elemente geändert, so dass der durch den vom Benutzer vorgegebene Namens-Wert (vgl. forcedchangeproperty in Abbildung 4.11, welches den Parameter widerspiegelt, der zwingend durch die Refaktorisierung geändert wird, vgl. Kapitel 2.6.1) auszulesen und zu übergeben ist, wohingegen beim zweiteren das Präfix (CAR ) durch die PullUp-Refaktorisierung angepasst wird (hier repräsentiert die forcedchangeproperty den Besitzer eines Attributs und der Source-Typ ist vom Typ einer UML-Klasse, vgl. Kapitel 4.2.2). Aus diesem Grunde existiert je nach änderbarer Eigenschaft eigene Functions/Generatoren in Form von Subklassen für die Codomänen der ID-Felder (vgl. Abbildung 4.12) und der Accessoren im Package-Interface (vgl. Abbildung 4.13). Analog zu der Namens-Eigenschaft gilt dies für die Owner-Eigenschaft dieser Elemente, deren Klassen zur Codomäne Einschränkung dienen. Bei EMF werden zu den modellierten Entitäten ebenfalls neben den Java-Implementierungsklassen auch korrespondiere Java-Interfaces generiert (vgl. Abbildung 4.14), was ebenfalls bei der Definition der Constraint-Regeln und der Trace-Generierung zu berücksichtigen ist. Da der EMF Code-Generator selbst keine Traces erzeugt, sind diese für die in Kapitel identifizierten Beziehungen zwischen Modell und Code programmatisch zu erstellen. Hierzu werden, wie Abbildung 4.15 veranschaulicht, jeweils Trace-

78 4.2 Komponenten 66 Abbildung 4.14.: Funktionen zur Generierung der korrespondierenden Besitzer der EMF-spezifischen Accessor-Methoden Generatoren, die das ITraceGenerator-Interface realisieren, implementiert, die in der EmfXUmlTraceInfoProvider-Klasse instanziiert und der Liste der Trace-Generatoren der Oberklasse hinzufügt werden. Die entsprechenden Trace-Generatoren begründen sich aus Abbildung 4.15.: EMF-spezifische Trace-Generatoren und Post-Code-Generierungen Kapitel 3.5.1, Abbildung 3.7. Zudem wird in der EmfXUmlTraceInfoProvider-Klasse der EMF-spezifische Post-Generator für die Regenerierung des Code initialisiert. Die EMF- Implementierung des IGeneration-Interfaces berücksichtigt dabei den in Kapitel beschriebenen Code-Generierungsprozess von EMF, der sich über die Transformation des ausgehenden UML-Modells in das Ecore-Modell und in das GenModel-Modell bis zur auf dem GenModel-Modell aufbauende Code-Generierung erstreckt. Für die finale Implementierung des EmfXUmlTraceInfoProvider ist neben dem Zugriff auf den Code für die Generierung der Traces der Zugriff auf das GenModell-Modell erforderlich, da in

79 4.3 Refacola-Definitionen 67 diesem während des Code-Generierungsprozesses ausgehend von dem UML-Modell Annotationen persistiert werden, die sich auf die Code-Generierung auswirken und gegebenenfalls in den übergreifenden Queries und Constraint-Regeln für Ko-Refaktorisierungen zu involvieren sind (vgl. Kapitel 3.5.1). Die in diesem Kapitel diskutierten EMF-spezifischen Implementierungen sind gemäß Gesamtarchitektur in der de.feu.ps.refacola.ecore.lang.javaxuml.emf-komponente lokalisiert Spezifische Komponenten für Acceleo-Generator Bei Acceleo werden in der Standard Code-Generierung neben Java-Klassen und Accessoren keine weiteren spezifischen Elemente im Gegensatz zu EMF generiert (vgl. Kapitel 3.5.2), so dass keine spezifischen Queries, Constraint-Regeln und Function-Klassen zu definieren sind, da diese bereits durch die de.feu.ps.refacola.ecore.lang.javaxuml- Komponente abgedeckt werden. Für Acceleo ist daher ausschließlich der Trace Info- Provider (AcceleoTraceInfoProvider) zu implementieren (vgl. Abbildung 4.16), der Bestandteil der de.feu.ps.refacola.ecore.lang.javaxuml.acceleo-komponente ist. Da in Acceleo Traces aber nicht serialisiert werden (vgl. Kapitel 3.5.2), werden analog zu EMF die Traces programmatisch erstellt (vgl. Abbildung 4.16). Die Implementierung der AcceleoTraceInfoProvider-Klasse kann jedoch zu einem späteren Zeitpunkt ausgetauscht werden, wenn Zugriff auf die serialisierten Acceleo-Traces besteht, so dass der Traces- Zugriff generisch erfolgen kann (wobei sich der generische Traces-Zugriff positiv auswirkt, wenn die Trace-Beziehungen äquivalent sind, vgl. Kapitel 3.5). Abbildung 4.16.: Acceleo-spezifische Trace-Generatoren 4.3. Refacola-Definitionen Die in Kapitel 3 analysierten Aspekte für constraintbasierte Refaktorisierungen sind für die Umsetzung in Refacola in dessen domänenspezifischen Sprachen zu realisieren, aus denen die Refacola-Refaktorisierungskomponenten (in Java) generiert werden. Die

80 4.3 Refacola-Definitionen 68 Refacola-Definitionen befinden sich in folgenden Komponenten: 6 de.feu.ps.refacola.ecore.lang.uml de.feu.ps.refacola.ecore.lang.javaxuml de.feu.ps.refacola.ecore.lang.javaxuml.emf de.feu.ps.refacola.ecore.lang.javaxuml.acceleo In der de.feu.ps.refacola.ecore.lang.uml-komponente sind die mittels Mitra generierte UML2 Refacola-Sprachdefinition (vgl. Kapitel 3.2) und die aus den UML2- Wohlgeformheitsregeln abgeleiteten und in Refacola verfassten Constraint-Regeln enthalten, wobei ein universelles Regelset, welche die Constraint-Regeln beinhalten, die unabhängig von einer Refaktorisierung sind, und jeweils ein Regelset mit Constraint- Regeln je Refaktorisierung aufgrund der variablen und konstanten Eigenschaften (vgl. Kapitel 3.3) definiert werden (siehe Anhang D.0.3). Listing 4.4 zeigt exemplarisch die abgeleitete membersaredistinguishable-constraint-regel aus Kapitel 3.3 in Refacola für die Rename-Refaktorisierung. ruleset uml_rename language uml rules membersaredistinguishable for all m1: uml.namedelement m2: uml.namedelement class: uml.namespace do if uml.member_of_namespace(class, m1), uml.member_of_namespace(class, m2), m1!= m2, kindsrelated(m1, m2) then m1.name!= m2.name end... Listing 4.4: membersaredistinguishable-constraint-regel in Refacola für Rename- Refaktorisierung Hinsichtlich der in OCL standardmäßig definierten ocliskindof-abfrage, die ebenfalls innerhalb der membersaredistinguishable-constraint-regel aufgerufen wird, ist Refacola um eine Abfrage zu erweitern, die diese abbildet. Da eine iskindof-abfrage prinzipiell von der jeweiligen Sprache bzw. Metamodell unabhängig ist, wird diese als universelle eingebettete Abfrage in der Refacola-DSL und in der Refacola-API (vgl. Abbildung 4.17) aufgenommen (bspw. analog zur NotEquals-Abfrage). Alternativ wäre es möglich diese Abfrage in der Refacola UML-Sprachdefinition zu integrieren, was jedoch zur Folge hätte, dass diese automatisch generierte Definition (vgl. Kapitel 3.2) manuell erweitert wird. Zudem stände diese Abfrage anderen Metamodellen nicht zur Verfügung und wäre für jedes Metamodell neu zu definieren. Gemäß OCL ist bei der iskindof-abfrage der ersten Parameter die Instanz und der zweiten Parameter der Typ als Literal. Für die Umsetzung in Refacola wird diese Abfrage leicht abgeändert, da die Refacola-DSL es nicht vorsieht direkt Typen (Kinds in Refacola, vgl. Kapitel 2.6.1) in einem Refacola-Dokument bzw. bei der Definition der Constraint-Regeln zu verwenden, so dass erster und zweiter Parameter jeweils Instanzen sind und innerhalb der implementierten Abfrage der Typ dieser Instanzen ermittelt und verglichen wird. Um dieses semantisch korrekt widerzuspiegeln, wird die iskindof-abfrage in Refacola 6 die gesamten Refacola-Definitionen sind auszugsweise im Anhang D.0.3 und vollständig auf der beigefügten CD-ROM zu finden

81 4.3 Refacola-Definitionen 69 Abbildung 4.17.: KindsRelatedQuery-Klasse in der Refacola-API Komponente kindsrelated genannt, die zugleich auch die reverse Abfrage realisiert ((iskindof(m1,m2) or iskindof(m2,m1) in der UML Wohlgeformheit-Regel). Des weiteren wird in abgeleiteten Constraint-Regeln, wie bspw. in Regel 3.10 in Kapitel 3.3.5, geprüft, dass eine Eigenschaft mit einem Wert versehen ist. Für die Realisierung in Refacola existiert das Literal Empty (vgl. bspw. Listing D.5), welches in der Refacola-DSL bereits spezifiziert, aber noch noch nicht implementiert ist, was demzufolge durchgeführt worden ist. Wenn bereits auf eine Eigenschaft in einer Constraint-Regel im Constraint-Teil referenziert wird, ist eine explizite Empty-Prüfung nicht notwendig, da dies bereits in der Implementierung des Refacola-Frameworks bei der Constraintgenerierung selbst geprüft wird. Bezüglich der UML2-Sprachdefinition ist einschränkend festzuhalten, dass die Generierung der Refacola-Komponenten aus der automatisiert erstellten Refacola UML2-Sprachdefinition aufgrund technischer Grenzen in Java zu Problemen führt. Angesichts des Umfangs des UML2-Metamodells und der daraus resultierenden Größe Abbildung 4.18.: Überschreitung Größe Static Initializer in der generierten Refacola- Klasse UmlPackage der Sprachdefinition in Refacola, wird bei der Code-Erzeugung in der generierten Refacola-LanguagePackage-Klasse UmlPackage, in der für jede Sprachelement, Eigenschaft, Wertebereich und Abfrage eine ID-Konstante in Form eines statisches Feldes angelegt wird, die von Java vorgegebene Größe des Static Initializer überschritten

82 4.3 Refacola-Definitionen 70 (vgl. Abbildung 4.18). Da im Rahmen dieser Arbeit im Kontext der modellgetriebenen Entwicklung primär Klassendiagramme verwendet werden, wird die Refacola UML2- Sprachdefinition auf die Elemente der Classes-Einheit beschränkt (vgl. Kapitel 2.3), um die vorgegebene Größe einzuhalten. In künftigen Refacola-Versionen ist hierfür das Konzept der LanguagePackage-Klasse zu überarbeiten, um den vollständigen Umfang des UML2-Metamodells abbilden zu können. Die Refacola-Definitionen in der de.feu.ps.refacola.ecore.lang.javaxuml-komponente umfassen die für Ko-Refaktorisierungen generell gültigen sprachübergreifenden Abfragen und Constraint-Regeln, die die Beziehungen zwischen Modell und Code verinnerlichen. Zum einen sind dies die Abfragen, welche Java-Klasse aus einer UML-Klasse und zum anderen die Abfragen und Constraint-Regeln zu Feldern und Accessoren, die aus Attributen im UML-Modell generiert werden und bereits in den Listings 4.1, 4.2 und 4.3 in Kapitel dargestellt worden sind. Des weiteren enthalten die Refacola-Definitionen in derde.feu.ps.refacola.ecore.lang.javaxuml.emf- und der de.feu.ps.refacola.ecore.lang.javaxuml.acceleo-komponente die für das jeweilige Code-Generator spezifischen Abfragen und Constraint-Regeln. Bei EMF sind dies die Abfragen und Constraint-Regeln zu den generierten Interfaces einer UML-Klasse, die zusätzlichen Accessor-Methoden, und der FieldID/Literal-Felder im Package-Interface (vgl. Listing 4.5). Die Fakten zu den generell gültigen sprachübergreifenden Abfragen aus der de.feu.ps.refacola.ecore.lang.javaxuml-komponente und den spezifischen Abfragen für das zu refaktorisierende Artefakt werden dabei jeweils aus dem von dem jeweiligen Trace Info-Provider in diesen Komponenten erstellt. Für die sprachübergreifenden Abfragen wird dies im Trace Info-Provider durch die jeweiligen Trace-Generatoren umgesetzt (vgl. Kapitel und 4.2.4). language javaemfxuml queries interfaceofumlclass(aclass: uml.class, javainterface: Java.Interface) getterinpackageinterfaceofumlproperty(aproperty: uml.property, setter: Java.Method) fieldidinpackageinterfaceofumlproperty(aproperty: uml.property, fieldidpackage: Java. Field) fieldliteralinpackageinterfaceofumlproperty(aproperty: uml.property, fieldidpackage: Java.Field)... functions Identifier accessorgetternamepackage(attributename: Identifier, classname: Identifier ) "de.feu.ps.refacola.lang.javaemfxuml.functions. AccessorGetterIdentifierNamePackageFunction" Identifier fieldidliteralnamepackage(attributename: Identifier, classname: Identifier ) "de.feu.ps.refacola.lang.javaemfxuml.functions. FieldIDLiteralIdentifierNamePackageFunction"... ruleset javaemfxuml languages javaemfxuml, javaxuml, Java, uml rules propertygetterpackagerename for all aproperty: uml.property getterpackage: Java.Method uml.attribute_of_classifier(class, aproperty) do if javaemfxuml.getterinpackageinterfaceofumlproperty(aproperty, getterpackage), uml.attribute_of_classifier(class, aproperty) then getterpackage.identifier = call javaemfxuml.accessorgetternamepackage( end... aproperty.name, class.name) Listing 4.5: Spezifische Abfragen und Constraint-Regeln für EMF-Generator

83 4.4 Benutzeroberfläche / Integration in die Entwicklungsumgebung Benutzeroberfläche / Integration in die Entwicklungsumgebung Abbildung 4.19.: Benutzeroberflächen des Plugins in Eclipse Die de.feu.ps.ecore.lang.javaxuml.ui-komponente repräsentiert die Komponente für die Benutzeroberfläche und Einbindung in die Eclipse Entwicklungsumgebung als Plugin (vgl. Kapitel 2.4.1). Analog zu den bestehenden Refekatorisierungs-Plugins erscheint das Plugin für Ko- Refaktorisierungen mit UML und Java im Kontext-Menü des Eclipse MDT-UML2 Editors (vgl. Abbildung 4.19). Wenn der entsprechende Eintrag im Kontext-Menü aufgerufen wird, erscheint der jeweilige Wizard-Dialog zur Eingabe der Refaktorisierungsparameter (vgl. Abbildung 4.19) Für alle Ko-Rekfatorisierungen im Java/UML-Kontext existiert zu den bestehenden Refacola Refaktorisierungs-Plugins eine gemeinsame Oberklasse AbstractRefacolaRefactoring, die von der Eclipse LTK spezifischen Refactoring-Klasse erbt und in der das gemeinsame Verhalten für Ko-Refaktorisierungen für die Integration in Eclipse gekapselt wird (vgl. Abbildung 4.20). Diese Klasse wird von der Wizard-Klasse für die Benutzeroberfläche (AbstractRefacolaRefactoringWizard) aufgerufen. Zudem implementiert diese Klasse das RTTInterface-Interface, um das Ko-Refaktorisierungs-Plugin im Rahmen der Evaluierung für die Refaktorisierung-Tool Tests nutzen zu können (vgl. nachfolgendes Kapitel 5). Für Refaktorisierungen, sich auf eine UML-Property als Subjekt beziehen, ist die Subklasse AbstractPropertyRefacolaRefactoring modelliert. Da bei Ko-Refaktorisierungen mehrere Info-Provider (vgl. Kapitel 4.2.2) kollektiv verwendet werden, werden folglich mehrere LTK-Change Objekte, zum einen für den Code und zum anderen für das UML-Modell, durch die entsprechenden applychangeset- Methoden der Info-Provider erzeugt, wobei die LTK Refactoring-Klasse ausschließlich ein Change-Objekt erwartet. wird die RefacolaCoChange-Klasse propagiert, die von der Eclipse LTK Change-Klasse erbt und die sich zur Laufzeit aus den jeweiligen anderen Change-Objekten für den Code und das Modell zusammensetzt und diese bei Aktivierung ausführt. Diese Container Change-Klasse wird folglich in der AbstractRefacolaRefactoring-Klasse instanziiert und im Rahmen des LTK-Frameworks weiter verarbeitet. In den von AbstractRefacolaRefactoring abgeleiteten Klassen werden die konkreten Refaktorisierungen und Info-Provider/Trace Info-Provider durch die Factory-Komponenten

84 4.5 Zusammenfassung 72 Abbildung 4.20.: Architektur Benutzeroberfläche und Integration in Eclipse auf Basis des vom Benutzer anzugebenen Code-Generierungswerkzeugs, welches für das MDD-Projekt verwendet wird, instanziiert (vgl. Kapitel 4.2.1) Zusammenfassung Wie aus diesem Kapitel deutlich wird, sind die abgeleiteten Anforderungen und Schlussfolgerungen im Rahmen der Architektur und der Implementierung auf Basis des Refacola-Frameworks mit der in Kapitel 4.3 dargelegten technischen Einschränkung umgesetzt worden, die nun zu evaluieren ist. Diese Architektur lässt sich folglich auf auch andere auf Ecore basierende Metamodelle als UML adaptieren. Die definierte Architektur für Ko-Refaktorisierungen ist gemäß dem Framework-Konzept auf Grundlage von Ableitungen der bestehenden Refacola-Komponenten entstanden, wobei Erweiterungen, die agnostisch von Ko-Refaktorisierungen und konkreten Metamodellen sind (wie bspw. die iskindof-abfrage), aus den genannten Gründen fachlich den allgemeinen Refacola API-Komponenten zugeordnet worden sind.

85 73 5. Evaluierung 5.1. Einführung Um das Konzept der constraintbasierten Ko-Refaktorisierung zu verifizieren, sind diese in geeigneter Form zu evaluieren, wobei eine formale Verifikation sich als schwierig erweist (vgl. Kapitel 2.8.2). Daher ist es ein gängiges Vorgehen, die Tragfähigkeit des Konzepts an realexistierenden Projekten zu überprüfen, wobei Open-Source Projekte, die modellgetrieben entwickelt sind, selten sind, was ebenfalls in (von Pilgrim u. a. 2013) attestiert wird. Ein Reverse-Ansatz, so wie er in der (von Pilgrim u. a. 2013) vorgeschlagen wird, in dem aus dem Code von Open-Source Projekten das entsprechende Modell erzeugt und darauf aufbauend die Evaluierungen durchgeführt werden, kommt nicht in Betracht, da, wie aus Kapitel 3.5 hervorgeht, bspw. dass bei EMF spezifische Klassen, Felder und Methoden generiert werden und diese folglich in den vorfindbaren Projekten im Code nicht existent sind. Daher soll die Evaluierung neben eines selbst erstellten mit Spezialfällen versehenen UML-Modells auf Basis vorhandener offener UML-Modelle erfolgen, die aus dem AtlanMod Modell-Zoo 1, den Acceleo Beispielen entnommen sind, aus denen jeweils mit dem EMF-Generator und nachfolgend mit dem Acceleo-Generator Code im Sinne der modellgetriebenen Entwicklung Code generiert wird (vgl. Kapitel 2.2.1). Auf dieser Basis werden die Rename- und PullUp Ko-Refaktorisierungen ausgeführt. Der Aufbau der Evaluierung orientiert sich an dem Konzept des Refactoring Tool Tester der Universität Hagen, bei dem die jeweilige Ko-Refaktorisierung auf alle passenden Elemente des Projekts bzw. des Artefakts angewendet wird und getestet wird. Damit die zu evaluierenden Refaktorisierungsprogramme durch einen Adapter Abbildung 5.1.: Refactoring Tool Tester-Interfaces (IRefactoringProvider) des Refactoring Tool Testers ausgeführt werden können, ist das RTTRefactoring-Interface (vgl. Abbildung 5.1) zu implementieren, was für die entwickelten Ko-Refaktorisierungsprogramme der Fall ist (vgl. Kapitel 4.4). Die canperform- Methode im IRefactoringProvider-Interface mit einem EObject als Paramenter überprüft dabei, ob eine Refaktorisierung für ein bestimmtes Element im Modell angewendet werden kann. Die EObject-Klasse ist die Oberklasse für Elemente eines Metamodells, die auf dem Ecore Meta-Metamodell basieren (vgl. Kapitel 2.5.1), wie unter Anderem UML. Die Auswahl der Projekte und Modelle erfolgt zum einen nach dem Gesichtspunkt, dass durch das Modell eine Fachlichkeit ausgedrückt wird und somit ein realitätsnaher Bezug gegeben ist, und zum anderen, dass bestimmte Faktoren wie Subsetting und Redefinition im UML-Modell vorkommen, die Gegenstand der in Kapitel3.3 abgeleiteten 1 vgl.

86 5.1 Einführung 74 Constraint-Regeln sind, damit diese entsprechend durch die Evaluierung abgedeckt werden. In diesem Kontext ist ebenfalls zu prüfen, ob die Wohlgeformtheit des UML-Modells bestehen bleibt, was eigentlich durch den constraintbasierten Ansatz beabsichtigt wird. Die Wohlgeformheit des UML-Modells wird mit externen Werkzeugen verifiziert. Wie in Kapitel dargelegt ist, wird in der Regel der generierte Code um manuelle Bestandteile erweitert, was gleichermaßen im Rahmen der Evaluierung zu berücksichtigen ist. Dieses wird durch manuell entwickelte Unit-Tests, die auf den generierten Code zugreifen, emuliert, die folglich ebenfalls durch Ko-Refaktorisierungen automatisch mitrefaktorisiert werden (sollen). Zudem wird in den Unit-Tests überprüft, ob das Verhalten des Codes unverändert bleibt (bspw. dass nach einer der Refaktorisierung bei den Accessoren die dahinter liegenden Felder einer Klasse nach wie vor richtig gesetzt werden). Da bei Rename und PullUp-Refaktorisierungen das Attribut einer Klasse der Gegenstand diese Refaktorisierung ist, sind insbesondere folgende Aspekte in den Unit-Tests zu testen, die gleichzeitig die Verhaltenserhaltung verifizieren und ebenso auf die entsprechenden Teile des generierten Codes zugreifen: Zugriff auf Getter-Methoden für bestimmte Attribute Zugriff auf Setter-Methoden für bestimmte Attribute Zugriff auf spezifische generierte Methoden und Felder für bestimmte Attribute (bspw. bei EMF Getter-Methoden im Package-Interface Zugriff auf spezifische generierte Felder für bestimmte Attribute (bspw. bei EMF ID-Feld im Package-Interface Polyphormes Verhalten der Accessor-Methoden (insbesondere für PullUp- Refaktorisierungen relevant) Insgesamt ergeben sich daher zusammenfassend folgende Kriterien, die evaluiert werden: Anzahl der potentiellen Refaktorisierungen im jeweiligen Projekt Anzahl der zurückgewiesenen Refaktorisierungen im jeweiligen Projekt Anzahl der erzeugten Constraints Anzahl der durchgeführten Änderungen im jeweiligen Projekt (Modell und Code) Durchschnittliche Geschwindigkeit der Constrainterzeugung und Lösung Durchschnittliche Geschwindigkeit der gesamten Durchführung (inklusive Einlesen der Fakten) Relativer Anteil der Refaktorisierungen, bei denen das UML-Modell wohlgeformt (valide) bleibt Relativer Anteil der Refaktorisierungen, bei denen die Kompilierfähigkeit des Codes (generiert und nicht-generiert) bestehen bleibt Relativer Anteil der Refaktorisierungen, bei denen die Unit-Tests nach der Refaktorisierung erfolgreich sind

87 5.2 Durchführung der Refaktorisierungen Durchführung der Refaktorisierungen Wie in Kapitel diskutiert, wird der Refactoring Tool Tester für Ko-Refaktorisierungen als Plugin angepasst und für die Refaktoriserungs-Plugins für Rename- und PullUp- Refaktorisierungen aus der de.feu.ps.ecore.lang.javaxuml.ui-komponente auf die relevanten Bereiche des Modells, welche sich im Rahmen dieser Arbeit auf Property-Elemente beschränken, der jeweiligen Probanden-Projekte angewendet (vgl. Abbildung 5.2). Abbildung 5.2.: Durchführung der Evaluierung für einen Probanden Das Car Management-Projekt ist dabei selbst instruiert, welches nicht aus den Acceleo- Beispielen und dem Modell-Zoo stammt, und Spezialfälle wie bspw. Subsetting enthält. In jedem Probanden ist eine JUnit-Klasse EvaluationTest vorhanden, die zugleich den manuellen Code repräsentiert (vgl. Listing, welches die EvaluationTest-Klasse für das Projekt Wiki Table für EMF darstellt). Die JUnits-Tests werden vor und nach der Refaktorisierung durchgeführt. 2. public class EvaluationTest public void testaccessors() { Table table = WikiTableFactory.eINSTANCE.createTable(); table.setstyle("teststyle"); Object style = table.getstyle(); asserttrue("teststyle".equals(style)); public void testpackageaccessors() { EReference ereference = WikiTablePackage.eINSTANCE.getRow_Cells(); String name = ereference.getname(); assertnotnull(name); public void testpackagefieldid() { Integer fieldid = WikiTablePackage.CAPTION CONTENT; assertnotnull(fieldid); public void testpackagefieldliteral() { EAttribute eattribute = WikiTablePackage.Literals.TABLE CLASS; assertnotnull(eattribute); } } Listing 5.1: Unit-Tests für Evaluierung von Wiki Table für EMF Die Validität von UML-Modellen wird nicht durch den auf Ko-Refaktorisierungen angepassten Refactoring Tool Tester erfasst, sondern wird nachgelagert durch XMI-Importer des Programms Visual Paradigm for UML 3 überprüft. Wenn ein UML-Modell invalide 2 Wenn ein JUnit-Test nicht mehr kompiliert, gilt dieser automatisch als fehlgeschlagen 3 vgl.

88 5.2 Durchführung der Refaktorisierungen 76 ist, wird durch dieses Programm je nach Schweregrad ein Parser-Fehler oder eine Warnung ausgegeben. Tabelle 5.1 zeigt die aggregierten Ergebnisse der Evaluierung für Ko-Refaktorisierungen für den EMF-Generator anhand der im vorherigen Kapitel dargestellten Kriterien. 4 Die detaillierten Ergebnisse sind als CSV-Dateien in E zu finden. Projekt # Modell-Elemente # Potent. Refakt. # Zurückgew. Refakt. Ø# Erzeugte Constraints Ø# Changes Øt Constraint- Erzeugung u. Lösung in ms Øt Gesamt in ms Rename Property % Modell Validität % Code kompiliert % Unit-Tests erfolgreich Acceleo Example (Car) Airline Book NA NA NA NA NA NA NA NA Person Car Management Healthcare Publication Wiki Table Acceleo Example (Car) PullUp Property Airline Book Car Management Die Evaluierung ist auf einem Max OS X mit 2.26 GHz Inter Core 2 Duo und 8 GB RAM durchgeführt worden.

89 5.2 Durchführung der Refaktorisierungen NA NA NA NA NA NA NA NA Person Healthcare Publication Wiki Table Tabelle 5.1.: Evaluierung mit EMF Code-Generator Tabelle 5.2 veranschaulicht analog die Resultate für Ko-Refaktorisierungen für den Acceleo-Generator. Projekt # Modell-Elemente # Potent. Refakt. # Zurückgew. Refakt. Ø# Erzeugte Constraints Ø# Changes Øt Constraint- Erzeugung u. Lösung in ms Øt Gesamt in ms % Modell Validität % Code kompiliert Rename Property % Unit-Tests erfolgreich Acceleo Example (Car) Airline Book Person Car Management Healthcare Publication Wiki Table

90 5.3 Ergebnis der Durchführung 78 Acceleo Example (Car) PullUp Property Airline Book Person Car Management Healthcare Publication Wiki Table Tabelle 5.2.: Evaluierung mit Acceleo-Generator 5.3. Ergebnis der Durchführung Aus den Ergebnissen der Evaluierung lässt sich schließen, dass bei constraintbasierten Ko-Refaktorisierungen die Validität des Modells, die Kompilierfähigkeit und Bedeutung von generierten und nicht generierten Code durchgängig erhalten bleibt. Bei den mit EMF generierten Probanden ist die die Anzahl der generierten Constraints signifikant höher als bei den mit Acceleo erzeugten, was darauf zurückzuführen ist, das bei EMF ein Mehrfaches an Code-Elementen aus einem Modell-Element produziert wird (vgl. Kapitel 3.5.1). Unter Berücksichtigung dieses Aspekts und in Relation der Anzahl der Modell-Elemente ist die Anzahl der Constraints durch das Konzept der Ableitung von Constraint-Regeln durch Differenzierung zwischen variablen und konstanten Eigenschaften aber verhältnismäßig gering. Des weiteren sind die Zurückweisungen von Refaktorisierungen, die ansonsten zu einer Invalidität des Modells geführt hätten, richtig erkannt worden, was sich bspw. an dem konstruierten Car Management-Projekt zeigt. Für das mit EMF erstellte Healthcare- Projekt kann die Evaluierung aufgrund eines Speicherproblems beim Einlesen der Fakten des Java-Programms nicht durchgeführt werden, wohingegen die Refaktorisierung bei dem korrespondierenden Acceleo-Projekt möglich ist, was wiederum auf die Anzahl der erzeugten Code-Elemente zu deduzieren ist. Bei 57% der EMF-Probanden werden die Refaktorisierungen durchschnittlich unter zehn Sekunden durchgeführt. Die durchschnittliche Gesamtzeit unter zehn Sekunden trifft bei den Acceleo-Projekten hingegen bei 81% der Probanden (75% bei Rename- und 87,5% bei den PullUp-Refaktorisierungen) zu. Die von der Gesamtzeit anteilige durchschnittli-

91 5.3 Ergebnis der Durchführung 79 che Zeit der Constraintgenerierung und des Lösens des Refaktorierungsproblems beläuft sich bei keinem der Probanden über zwei Sekunden, so dass primär das Einlesen der Fakten des Modells und des Java-Codes den Großteil der Gesamtzeit beansprucht (die Laufzeit der Post-Generierung ist dabei vernachlässigbar) und hier folglich Optimierungsbedarf besteht. Da das Einlesen der Fakten abhängig von der jeweiligen Infrastruktur ist, hat sich die constraintbasierte Refaktorierung per se, welche im Wesentlichen die Constraintgenerierung und das Solving umfasst, auch unter Verwendung von Generator- Konzepten zur Einschränkung der Codomänen (vgl. Kapitel 4.2.2), als effizient erwiesen. Zusammenfassend lässt sich daher sagen, dass Ko-Refaktorisierungen auf Basis des im Rahmen dieser Arbeit erörterten Ansatzes grundsätzlich erfolgreich evaluiert worden sind.

92 80 6. Gesamtfazit und Ausblick Im Rahmen dieser Arbeit sind Ko-Refaktorisierungen am Beispiel von Java- und UML anhand der Rename- und PullUp-Refaktorisierung analysiert worden, wobei auf Basis der Analyse auf den constraintbasierten Ansatz zurückgegriffen worden ist. Verallgemeinernd lässt sich daraus ableiten, dass Ko-Refaktorisierungen, mit dem Functions- Konzept und Post-Regenerierung durchführbar sind, was durch die Evaluierung bestätigt worden ist. Des weiteren ist mit der Konzeption in Kapitel 4 eine Architektur zur Umsetzung von Ko-Refaktorisierungen geschaffen worden, mit der weitere Code-Generatoren unter der Berücksichtig der spezifischen Beziehungen zwischen Modell und Code, was sich, wie gezeigt, auf das Tracing und Refaktorisierungsdefinitionen auswirkt. Diese Architektur lässt sich ebenfalls auf andere MOF/Ecore basierende Metamodelle adaptieren. Durch das Refacola-Framework und dessen domänenspezifische Sprache lassen sich zudem neben Rename- und PullUp-Refaktorisierungen weitere Ko-Refaktorisierungen realisieren. Einschränkend ist festzuhalten, dass bei Änderungen der (Standard-)Vorlagen zur Code-Generierung, so wie es bei Acceleo möglich ist, in der Regel die Ko- Refaktorisierungsprogramme auch bei Verwendung von generischen Traces anzupassen sind, da sich die Beziehungen zwischen Modell und Code ändern, wenn neue oder weitere Code-Elemente aus einem Element des UML-Modells auf Grundlage der neuen Vorlage erzeugt werden, und diese infolgedessen in den sprachübergreifenden Refacola- Definitionen als neue Fakten-Abfragen aufzunehmen sind. Um dieses zu lösen, sind die sprachübergreifenden Fakten-Abfragen nicht zur Entwicklungszeit statisch, sondern folglich dynamisch zur Laufzeit unter Berücksichtigung der Code-Generierungsvorlagen zu erstellen, was gegebenenfalls Thema weiterer Arbeiten sein kann. Wie sich in der Analyse zur Ableitung der Constraint-Regeln aus den OCL-Constraints, welche primär die statische Semantik und Wohlgeformheit eines Modells definieren, herauskristallisiert hat, ist diese Ableitung komplex. Hier wäre es vorteilhaft, OCL- Constraints direkt für die Constraint-Erzeugung für ein Refaktorisierungsproblem heranzuziehen, was Gegenstand aktueller Forschungen ist. 1 Um zudem die Constraint-Regeln, die im Rahmen dieser Arbeit je nach Refaktorisierung aufgrund der unterschiedlichen variablen und konstanten Eigenschaften differenziert abgeleitet worden sind, unabhängig von der Refaktorisierung zu definieren, sind diese zur Laufzeit auf Basis der variablen und konstanten Eigenschaften umzuschreiben, was im Rahmen dieser Arbeit nicht weiter erörtert wurde und bspw. in (Steimann 2012) diskutiert wird. Darüber hinaus sind im Rahmen dieser Arbeit die relevanten Wohlgeformtheit-Regeln berücksichtigt worden. Um alle Refaktorisierungen vollends abbilden zu können, sind dementsprechend alle Wohlgeformtheit-Regeln der UML Superstruktur-Spezifikation einzubeziehen. Im Weiteren ist das gesamte UML-Metamodell als Refacola-Sprachdefinition aufzunehmen, was aufgrund der in Kapitel 4.3 beschriebenen technischen Limitationen derzeitig nicht möglich ist, und eine Neu-Konzeption des Refacola-Compilers zur Generierung der Refocola Refaktorisierungsprogramme erfordert. 1 vgl. (Ulke u. Steimann 2013)

93 81 A. Prototyp / Benutzungsanleitung Die beiliegende CD-ROM enthält eine prototypische Implementierung des diskutierten Plugins zur Durchführung von constraintbasierten Refaktorisierungen. A.1. Installationshinweise Die Plugins sind unter Mac OS X mit folgenden Eclipse (gemäß Installieren) entwickelt und getestet worden: Eclipse Modeling Tools mit Xtend/Xpand Version: Juno Service Release 2 Build id: Ein Test auf Windows 7 war ebenso erfolgreich. Bezüglich der Installation des Plugins sind die jar-dateien (vgl. Auflistung der Inhalte in Anhang E) in das plugins-verzeichnis von Eclipse zu kopieren. Die Acceleo-Plugins sind über den MarketPlace installiert worden, sind aber für die Plugins nicht zwingend erforderlich. A.2. Benutzung des Refactoring-Plugin für Ko-Refaktorisierungen Um das Plugin auszuführen, ist zunächst ein UML-Modell, welches sich in einem Java-Project in Eclipse befindet, zu öffnen (bspw. aus den Probanden und den Simple-Projektn auf der CD-ROM). Bei Rechts-Klick auf eine Property sollte das Kontext erscheinen (vgl. Schritt 1). Je nachdem mit welchem Werkzeug der Code in dem Projekt generiert worden ist, ist der jeweilige Eintrag für die Refaktorisierung auszuwählen. Nach Auswahl sollte der entsprechende Dialog angezeigt werden (vgl. Schritt 2a und 2b). Nach der Durchführung der Refaktorisierung sollten der Code und das UML- Modell entsprechend angepasst sein, was bei EMF ebenfalls die Namen der Feld-ID und der globalen Accessor-Methoden einschliesst (vgl. Schritt 3): A.3. Benutzung des Evaluierungs-Plugin Um das Plugin auszuführen, ist zunächst ein Java-Project auszuwählen (bspw. Probanden auf der CD-ROM). Bei Rechts-Klick auf das Projekt sollte dann folgender Eintrag im Kontext-Menü erscheinen (vgl. Schritt 1)

94 A.4 Schritte zur Benutzung 82 Je nachdem mit welchem Werkzeug der Code in dem Projekt generiert worden ist, ist der jeweilige Eintrag auszuwählen. Nach Klick wird die Evaluierung für dieses Projekt gestartet und die Ergebnisse als CSV-Datei generiert (vgl. Schritt 2). A.4. Schritte zur Benutzung Abbildung A.1.: Refactoring-Plugin für Ko-Refaktorisierungen Schritt 1

95 A.4 Schritte zur Benutzung 83 Abbildung A.2.: Refactoring-Plugin für Ko-Refaktorisierungen Schritt 2a Abbildung A.3.: Refactoring-Plugin für Ko-Refaktorisierungen Schritt 2b

96 A.4 Schritte zur Benutzung 84 Abbildung A.4.: Refactoring-Plugin für Ko-Refaktorisierungen Schritt 3 Abbildung A.5.: Evaluierungs-Plugin für Ko-Refaktorisierungen Schritt 1

97 A.4 Schritte zur Benutzung 85 Abbildung A.6.: Evaluierungs-Plugin für Ko-Refaktorisierungen Schritt 2

98 86 B. Abbildungen Abbildung B.1.: Ablauf Constraint-Erzeugung und Constraint-Solving in Refacola aus FernUniversität Hagen Clare Subversion Repository übernommen

Model Driven Development im Überblick

Model Driven Development im Überblick Model Driven Development im Überblick Arif Chughtai Diplom-Informatiker (FH) www.digicomp-academy, Seite 1 September 05 Inhalt Motivation Überblick MDA Kleines Beispiel Werkzeuge www.digicomp-academy,

Mehr

Was ist EMF? Wie wird EMF eingesetzt? Was ist ecore? Das Generatormodell Fazit

Was ist EMF? Wie wird EMF eingesetzt? Was ist ecore? Das Generatormodell Fazit Was ist EMF? Wie wird EMF eingesetzt? Was ist ecore? Das Generatormodell Fazit EMF ist ein eigenständiges Eclipse-Projekt (Eclipse Modeling Framework Project) EMF ist ein Modellierungsframework und Tool

Mehr

Model Driven Architecture (MDA)

Model Driven Architecture (MDA) Model Driven Architecture (MDA) Vortrag im Fach Software Engineering II BA Mannheim / Fachrichtung Angewandte Informatik Torsten Hopp Gliederung Einleitung Motivation Grundzüge der MDA Ziele & Potenziale

Mehr

Einführung in modellgetriebene Softwareentwicklung. 24. Oktober 2012

Einführung in modellgetriebene Softwareentwicklung. 24. Oktober 2012 Einführung in modellgetriebene Softwareentwicklung 24. Oktober 2012 Überblick Was sind die Grundprinzipien der modellgetriebenen Softwareentwicklung? Entwicklung einer MDD-Infrastruktur Modellgetriebene

Mehr

Model Driven Architecture Praxisbeispiel

Model Driven Architecture Praxisbeispiel 1 EJOSA OpenUSS CampusSource Model Driven Architecture Praxisbeispiel 2 Situation von CampusSource-Plattformen Ähnliche Funktionen (Verwaltung von Studenten und Dozenten, Diskussionsforen,...), jedoch

Mehr

Das Metamodell der UML und in FUJABA. Vortrag von Alexander Geburzi

Das Metamodell der UML und in FUJABA. Vortrag von Alexander Geburzi Das Metamodell der UML und in FUJABA Vortrag von Alexander Geburzi Gliederung Metamodellierung Metamodell der UML Metamodell in FUJABA Metamodellierung - Metamodell der UML - Metamodell in FUJABA 2/20

Mehr

Jochen Bauer 08.01.2010

Jochen Bauer 08.01.2010 08.01.2010 Um was geht s und wie läuft s ab? Eclipse-EMP-MDT: Standards unter einem Dach! Gliederung 1. der Model (MDT) 2. Model-Driven- (MDD) und MDT 3. Interne Domain-Specific-Languages (DSL) 4. 5. 6.,

Mehr

Definition von domänenspezifischen Sprachen mit Xtext: Einführung. 19. November 2014

Definition von domänenspezifischen Sprachen mit Xtext: Einführung. 19. November 2014 Definition von domänenspezifischen Sprachen mit Xtext: Einführung 19. November 2014 Überblick Was ist zu tun, wenn wir selbst einen Ansatz für modellgetriebenen Entwicklung definieren wollen? Anforderungserfassung

Mehr

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel. EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.de/~mtr FRAGEN / ANMERKUNGEN Vorlesung Neue Übungsaufgaben MODELLIERUNG

Mehr

Beispielhaft MDSD in der Praxis. Dr. Shota Okujava shota.okujava@isento.de www.isento.de

Beispielhaft MDSD in der Praxis. Dr. Shota Okujava shota.okujava@isento.de www.isento.de Beispielhaft MDSD in der Praxis Dr. Shota Okujava shota.okujava@isento.de www.isento.de Agenda Einführung Softwareentwicklungsprozess und MDSD Technologien und Werkzeuge Demo Entwicklung der Metamodelle

Mehr

Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle

Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle Doktoranden-, Diplomandenseminar, Institut für Informatik, TU Clausthal 23. Juni 2009 Motivation: Modelle werden in der

Mehr

SEA. Modellgetriebene Softwareentwicklung in der BA

SEA. Modellgetriebene Softwareentwicklung in der BA SEA Modellgetriebene Softwareentwicklung in der BA MDA bei der BA Ziele/Vorteile: für die Fachabteilung für die Systementwicklung für den Betrieb Wie wird MDA in der BA umgesetzt? Seite 2 MDA bei der BA

Mehr

Verhindert, dass eine Methode überschrieben wird. public final int holekontostand() {...} public final class Girokonto extends Konto {...

Verhindert, dass eine Methode überschrieben wird. public final int holekontostand() {...} public final class Girokonto extends Konto {... PIWIN I Kap. 8 Objektorientierte Programmierung - Vererbung 31 Schlüsselwort: final Verhindert, dass eine Methode überschrieben wird public final int holekontostand() {... Erben von einer Klasse verbieten:

Mehr

Copyright 2014 Delta Software Technology GmbH. All Rights reserved.

Copyright 2014 Delta Software Technology GmbH. All Rights reserved. Karlsruhe, 21. Mai 2014 Softwareentwicklung - Modellgetrieben und trotzdem agil Daniela Schilling Delta Software Technology GmbH The Perfect Way to Better Software Modellgetriebene Entwicklung Garant für

Mehr

Daniel Warneke warneke@upb.de 08.05.2006. Ein Vortrag im Rahmen des Proseminars Software Pioneers

Daniel Warneke warneke@upb.de 08.05.2006. Ein Vortrag im Rahmen des Proseminars Software Pioneers Design Patterns Daniel Warneke warneke@upb.de 08.05.2006 Ein Vortrag im Rahmen des Proseminars Software Pioneers Design Patterns 1/23 Übersicht Einleitung / Motivation Design Patterns Beispiele Rolle des

Mehr

Produktskizze. 28. November 2005 Projektgruppe Syspect

Produktskizze. 28. November 2005 Projektgruppe Syspect 28. November 2005 Carl von Ossietzky Universität Oldenburg Fakultät II Department für Informatik Abteilung Entwicklung korrekter Systeme Inhaltsverzeichnis 1 Einleitung 3 2 Die graphische Oberfläche der

Mehr

Vortrag von: Ilias Agorakis & Robert Roginer

Vortrag von: Ilias Agorakis & Robert Roginer MDA Model Driven Architecture Vortrag von: Ilias Agorakis & Robert Roginer Anwendungen der SWT - WS 08/09 Inhalt Was ist MDA? Object Management Group (OMG) Ziele Konzepte der MDA Werkzeuge Vor- und Nachteile

Mehr

4. AuD Tafelübung T-C3

4. AuD Tafelübung T-C3 4. AuD Tafelübung T-C3 Simon Ruderich 17. November 2010 Arrays Unregelmäßige Arrays i n t [ ] [ ] x = new i n t [ 3 ] [ 4 ] ; x [ 2 ] = new i n t [ 2 ] ; for ( i n t i = 0; i < x. l e n g t h ; i ++) {

Mehr

Comparing Software Factories and Software Product Lines

Comparing Software Factories and Software Product Lines Comparing Software Factories and Software Product Lines Martin Kleine kleine.martin@gmx.de Betreuer: Andreas Wuebbeke Agenda Motivation Zentrale Konzepte Software Produktlinien Software Factories Vergleich

Mehr

Faktor-IPS. Modellgetriebene Softwareentwicklung mit Faktor-IPS. Faktor Zehn AG. Seite 1

Faktor-IPS. Modellgetriebene Softwareentwicklung mit Faktor-IPS. Faktor Zehn AG. Seite 1 Faktor-IPS Modellgetriebene Softwareentwicklung mit Faktor-IPS Seite 1 Faktor-IPS Faktor-IPS ist ein Werkzeug zur modellgetriebenen Entwicklung versicherungsfachlicher Systeme Bestandssysteme Außendienstsysteme

Mehr

ActiveCharts. Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0

ActiveCharts. Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0 Jens Kohlmeyer 05. März 2007 Institut für Programmiermethodik und Compilerbau ActiveCharts Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0 Seite 2 Übersicht

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Grobentwurf

Softwareentwicklungspraktikum Sommersemester 2007. Grobentwurf Softwareentwicklungspraktikum Sommersemester 2007 Grobentwurf Auftraggeber Technische Universität Braunschweig

Mehr

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Prof. Dr. Wilhelm Schäfer Paderborn, 15. Dezember 2014 Christian Brenner Tristan Wittgen Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Aufgabe 1 Codegenerierung

Mehr

Seminar Bassem Ben Helal

Seminar Bassem Ben Helal Requiline Seminar Bassem Ben Helal Inhalt Motivation Kernfunktionalitäten Architektur Hierarchie Typen Abhängigkeiten Variabilitätspunkte Produktkonfiguration Evaluierung Demo Diskussion Motivation RequiLine

Mehr

EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2

EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2 EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0 EDV Kurs 13/2 Inhaltsverzeichnis 1 Objekte... 1 2 Klassen... 3 2.1 Beziehungen zwischen Klassen... 4 2.1.1 Vererbung... 4 2.1.2

Mehr

Dokumentation. Schnittstelle IKISS Bayerischer Behördenwegweiser. Stand: 2008-10-21

Dokumentation. Schnittstelle IKISS Bayerischer Behördenwegweiser. Stand: 2008-10-21 Dokumentation Schnittstelle IKISS Bayerischer Behördenwegweiser Stand: 2008-10-21 Copyright 2008 Advantic Systemhaus GmbH. Alle Rechte vorbehalten. Dokumentationsmaterial, das von der Advantic Systemhaus

Mehr

UML-DSLs effizient eingesetzt. Insight 07, 13.11.2007 Klaus Weber

UML-DSLs effizient eingesetzt. Insight 07, 13.11.2007 Klaus Weber UML-DSLs effizient eingesetzt Insight 07, 13.11.2007 Klaus Weber Einladung Domänenspezifische Sprachen (DSLs) sind notwendige Voraussetzung für den Erfolg einer MDA-Strategie. MID favorisiert statt der

Mehr

Orientierungshilfen für SAP PI (Visualisierungen)

Orientierungshilfen für SAP PI (Visualisierungen) EINSATZFELDER FÜR DIE KONFIGURATIONS-SZENARIEN INTERNE KOMMUNIKATION UND PARTNER-KOMMUNIKATION UND DIE SERVICE-TYPEN BUSINESS-SYSTEM, BUSINESS-SERVICE UND INTEGRATIONSPROZESS Betriebswirtschaftliche Anwendungen

Mehr

Language Workbench. Aktuelle Themen der Softwaretechnologie. Vortrag von: Arthur Rehm Steven Cardoso. Betreut von: Prof. Dr.

Language Workbench. Aktuelle Themen der Softwaretechnologie. Vortrag von: Arthur Rehm Steven Cardoso. Betreut von: Prof. Dr. Language Workbench Vortrag von:! Aktuelle Themen der Softwaretechnologie Arthur Rehm Steven Cardoso Betreut von: Prof. Dr. Reichenbach [1] !2 Index Kontext Domain Specific Language (DSL) Language Workbench

Mehr

Systemdenken und Gestaltungsmethodik System-Modellierung

Systemdenken und Gestaltungsmethodik System-Modellierung Systemdenken und Gestaltungsmethodik System-Modellierung Prof. Dr.-Ing. Stefan Brunthaler TFH Wildau 2008ff Master Telematik Ausgangsbasis Es liegt ein kosten-nutzen-optimales Lösungskonzept vor. Die Architektur

Mehr

Softwareentwicklungsprozess im Praktikum. 23. April 2015

Softwareentwicklungsprozess im Praktikum. 23. April 2015 Softwareentwicklungsprozess im Praktikum 23. April 2015 Agile Softwareentwicklung Eine agile Methodik stellt die beteiligten Menschen in den Mittelpunkt und versucht die Kommunikation und Zusammenarbeit

Mehr

Software Factories SS 2016. Prof. Dr. Dirk Müller. 3 Modellgetriebene Softwareentwicklung

Software Factories SS 2016. Prof. Dr. Dirk Müller. 3 Modellgetriebene Softwareentwicklung Software Factories 3 Modellgetriebene Softwareentwicklung Prof. Dr. Dirk Müller Übersicht Einordnung im Lebenszyklus Ziele Hebung des Abstraktionsniveaus Model Driven Architecture (MDA) Domänenspezifische

Mehr

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche etutor Benutzerhandbuch Benutzerhandbuch XQuery Georg Nitsche Version 1.0 Stand März 2006 Versionsverlauf: Version Autor Datum Änderungen 1.0 gn 06.03.2006 Fertigstellung der ersten Version Inhaltsverzeichnis:

Mehr

Use Cases. Use Cases

Use Cases. Use Cases Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben

Mehr

Vorgetragen von. Sanaz Mostowfi Anna Polovets Mandy Neumann

Vorgetragen von. Sanaz Mostowfi Anna Polovets Mandy Neumann Vorgetragen von Sanaz Mostowfi Anna Polovets Mandy Neumann Gliederung Was ist DSL? Welche Arten von DSL gibt es? Vor und Nachteile Werkzeuge zur Erstellung von DSLs XText Definition: DSL (Domain Specific

Mehr

Software Engineering. Zur Architektur der Applikation Data Repository. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering. Zur Architektur der Applikation Data Repository. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering Zur Architektur der Applikation Data Repository Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering: Mit acht bewährten Praktiken zu gutem Code 2 Schichtarchitektur

Mehr

Grundlagen Software Engineering

Grundlagen Software Engineering Grundlagen Software Engineering Rational Unified Process () GSE: Prof. Dr. Liggesmeyer, 1 Rational Unified Process () Software Entwicklungsprozess Anpassbares und erweiterbares Grundgerüst Sprache der

Mehr

Workflow Systeme mit der Windows Workflow Foundation

Workflow Systeme mit der Windows Workflow Foundation Studiengang Electronic Business (EB) Diplomarbeit (280000) Workflow Systeme mit der Windows Workflow Foundation externe Betreuung durch Christoph Müller vorgelegt bei Prof. Dr. Michael Gröschel von Hans-Martin

Mehr

1 Mathematische Grundlagen

1 Mathematische Grundlagen Mathematische Grundlagen - 1-1 Mathematische Grundlagen Der Begriff der Menge ist einer der grundlegenden Begriffe in der Mathematik. Mengen dienen dazu, Dinge oder Objekte zu einer Einheit zusammenzufassen.

Mehr

DSL Entwicklung und Modellierung

DSL Entwicklung und Modellierung DSL Entwicklung und Modellierung Dipl. Inform. Rolf Hänisch Übersicht DSL, was bedeutet das für uns? Eine Anwendung aus der Automatisierungstechnik Sprachen und Werkzeuge Ergebnisse und Erfahrungen GI

Mehr

Arbeiten mit UMLed und Delphi

Arbeiten mit UMLed und Delphi Arbeiten mit UMLed und Delphi Diese Anleitung soll zeigen, wie man Klassen mit dem UML ( Unified Modeling Language ) Editor UMLed erstellt, in Delphi exportiert und dort so einbindet, dass diese (bis auf

Mehr

Objektorientierte Programmierung

Objektorientierte Programmierung Objektorientierte Programmierung 1 Geschichte Dahl, Nygaard: Simula 67 (Algol 60 + Objektorientierung) Kay et al.: Smalltalk (erste rein-objektorientierte Sprache) Object Pascal, Objective C, C++ (wiederum

Mehr

SUB-ID- VERWALTUNG MIT GPP SETUP-GUIDE FÜR PUBLISHER

SUB-ID- VERWALTUNG MIT GPP SETUP-GUIDE FÜR PUBLISHER SUB-ID- VERWALTUNG MIT GPP SETUP-GUIDE FÜR PUBLISHER INHALTSVERZEICHNIS Inhaltsverzeichnis... 2 Symbolverzeichnis... 3 Was ist GPP?... 4 Parameternamen... 4 Parameterformat und -größe... 4 Unterstützte

Mehr

INNOVATOR im Entwicklungsprozess

INNOVATOR im Entwicklungsprozess Erfahrungsbericht INNOVATOR im Entwicklungsprozess Basis für Host- und Java-Anwendungen Dr. Carl-Werner Oehlrich, Principal Consultant MID GmbH Das Modellierungswerkzeug INNOVATOR Geschäftsprozess-Modellierung

Mehr

Requirements Engineering I

Requirements Engineering I Norbert Seyff Requirements Engineering I UML Unified Modeling Language! 2006-2012 Martin Glinz und Norbert Seyff. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen

Mehr

Ein mobiler Electronic Program Guide

Ein mobiler Electronic Program Guide Whitepaper Telekommunikation Ein mobiler Electronic Program Guide Ein iphone Prototyp auf Basis von Web-Technologien 2011 SYRACOM AG 1 Einleitung Apps Anwendungen für mobile Geräte sind derzeit in aller

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 9 17. Dezember 2002 www4.in.tum.de/~rumpe/se

Mehr

Dieses Tutorial gibt eine Übersicht der Form Klassen von Struts, welche Besonderheiten und Unterschiede diese aufweisen.

Dieses Tutorial gibt eine Übersicht der Form Klassen von Struts, welche Besonderheiten und Unterschiede diese aufweisen. Übersicht Struts Forms Dieses Tutorial gibt eine Übersicht der Form Klassen von Struts, welche Besonderheiten und Unterschiede diese aufweisen. Allgemeines Autor: Sascha Wolski http://www.laliluna.de/tutorials.html

Mehr

Ein subjektiver Vergleich zwischen SSIS und Kettle mit Ausblick auf die Generierung von BI-Lösungen

Ein subjektiver Vergleich zwischen SSIS und Kettle mit Ausblick auf die Generierung von BI-Lösungen Ein subjektiver Vergleich zwischen SSIS und Kettle mit Ausblick auf die Generierung von BI-Lösungen vorgestellt am 29.09.2008 in der PASS Regionalgruppe Karlsruhe Michael Riedmüller inovex GmbH Project

Mehr

BEISPIELKLAUSUR Softwareentwicklung:

BEISPIELKLAUSUR Softwareentwicklung: Prof. Dr. Andreas Fink Institut für Informatik Fakultät für Wirtschafts- und Sozialwissenschaften Helmut-Schmidt-Universität / Universität der Bundeswehr Hamburg BEISPIELKLAUSUR Softwareentwicklung: Objektorientierte

Mehr

... MathML XHTML RDF

... MathML XHTML RDF RDF in wissenschaftlichen Bibliotheken (LQI KUXQJLQ;0/ Die extensible Markup Language [XML] ist eine Metasprache für die Definition von Markup Sprachen. Sie unterscheidet sich durch ihre Fähigkeit, Markup

Mehr

Semantic Web Technologies I! Lehrveranstaltung im WS10/11! Dr. Andreas Harth! Dr. Sebastian Rudolph!

Semantic Web Technologies I! Lehrveranstaltung im WS10/11! Dr. Andreas Harth! Dr. Sebastian Rudolph! Semantic Web Technologies I! Lehrveranstaltung im WS10/11! Dr. Andreas Harth! Dr. Sebastian Rudolph! www.semantic-web-grundlagen.de Ontology Engineering! Dr. Sebastian Rudolph! Semantic Web Architecture

Mehr

Java und XML 2. Java und XML

Java und XML 2. Java und XML Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik Java und XML Hauptseminar Telematik WS 2002/2003

Mehr

IBM Software Demos Rational Software Delivery Platform - Anforderungsanalyse

IBM Software Demos Rational Software Delivery Platform - Anforderungsanalyse In dieser Demo führt unser Analyst Alex eine Anforderungsanalyse für die Integration einer Sofort kaufen-option durch. Dadurch werden alle von der Änderung betroffenen Elemente der Auktionsanwendung, auch

Mehr

MIT NEUEN FACHTHEMEN

MIT NEUEN FACHTHEMEN ZUM UMGANG MIT Version: 1.0 Datum: 15.10.2012 INHALTSVERZEICHNIS 1 EINLEITUNG... 3 1.1 Ziel und Zweck... 3 1.2 Anwendungsbereich... 3 1.3 Entwicklung und Fortführung... 3 2 DOKUMENTE... 4 2.1 Formular

Mehr

Model Driven Architecture

Model Driven Architecture Model Driven Architecture Wilhelm Stephan Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Julian Kunkel SommerSemester

Mehr

Entwicklung einer formalen Sprache zur Modelltransformation auf Basis von UML & XMI

Entwicklung einer formalen Sprache zur Modelltransformation auf Basis von UML & XMI Entwicklung einer formalen Sprache zur Modelltransformation auf Basis von UML & XMI Swisstopo-Kolloquium 11.04.2008 TU München, 13. März 2007 Inhalt 1. Anforderungen, Voraussetzungen, Grundlagen 2. Instrumente

Mehr

Aufgabenheft. Fakultät für Wirtschaftswissenschaft. Modul 32701 - Business/IT-Alignment. 26.09.2014, 09:00 11:00 Uhr. Univ.-Prof. Dr. U.

Aufgabenheft. Fakultät für Wirtschaftswissenschaft. Modul 32701 - Business/IT-Alignment. 26.09.2014, 09:00 11:00 Uhr. Univ.-Prof. Dr. U. Fakultät für Wirtschaftswissenschaft Aufgabenheft : Termin: Prüfer: Modul 32701 - Business/IT-Alignment 26.09.2014, 09:00 11:00 Uhr Univ.-Prof. Dr. U. Baumöl Aufbau und Bewertung der Aufgabe 1 2 3 4 Summe

Mehr

Usecase Meta Model Comparison and Model Migration. Dawid Kostrzycki Entwicklung verteilter eingebetteter Systeme

Usecase Meta Model Comparison and Model Migration. Dawid Kostrzycki Entwicklung verteilter eingebetteter Systeme Usecase Meta Model Comparison and Model Migration Dawid Kostrzycki Entwicklung verteilter eingebetteter Systeme Einführung in den Atlas Model Weaver (AMW) theoretisch und praktisch Anwendungsgebiete Wo

Mehr

Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter

Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter Johannes Michler PROMATIS software GmbH Ettlingen Schlüsselworte Geschäftsprozess, Horus, SOA, BPMN, ADF, WebCenter Einleitung Die Umsetzung

Mehr

XML-Austauschformat für Sicherheitsdatenblätter

XML-Austauschformat für Sicherheitsdatenblätter XML-Austauschformat für Sicherheitsdatenblätter Version 2.0 / 15. Dezember 2008 www.edas.org 1 XML-Austauschformat für Sicherheitsdatenblätter Der Austausch der Sicherheitsdatenblätter erfolgt als XML-Datei.

Mehr

Anwendung der DIN EN ISO 9241 bei der Erstellung und Bewertung von Software

Anwendung der DIN EN ISO 9241 bei der Erstellung und Bewertung von Software Anwendung der DIN EN ISO 9241 bei der Erstellung und Bewertung von Software Abstract Die Norm DIN EN ISO 9241 "Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten" ist von zentraler Bedeutung

Mehr

Einführung in die Modellierung

Einführung in die Modellierung Einführung in die Modellierung Christian Huemer Business Informatics Group Institute of Software Technology and Interactive Systems Vienna University of Technology Favoritenstraße 9-11/188-3, 1040 Vienna,

Mehr

Implementation of a Framework Component for Processing Tasks within Threads on the Application Level

Implementation of a Framework Component for Processing Tasks within Threads on the Application Level Implementation of a Framework Component for Processing Tasks within Threads on the Application Level Deutsches Krebsforschungszentrum, for Processing Task within Threads on the Application Level Motivation

Mehr

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 374

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 374 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 374 Eignung von Verfahren der Mustererkennung im Process Mining Sabrina Kohne

Mehr

Planung für Organisation und Technik

Planung für Organisation und Technik Planung für Organisation und Technik MOA-VV Algorithmen-Beschreibung Version 0.0.2 Inhaltsverzeichnis 1. Die Vollmachtsprüfung... 3 1.1 Eingangsdaten... 3 1.2 einfache Vollmacht und Online-Vollmacht...

Mehr

MORE Profile. Pass- und Lizenzverwaltungssystem. Stand: 19.02.2014 MORE Projects GmbH

MORE Profile. Pass- und Lizenzverwaltungssystem. Stand: 19.02.2014 MORE Projects GmbH MORE Profile Pass- und Lizenzverwaltungssystem erstellt von: Thorsten Schumann erreichbar unter: thorsten.schumann@more-projects.de Stand: MORE Projects GmbH Einführung Die in More Profile integrierte

Mehr

Generative Prozessmodelle Patrick Otto MDD Konferenz 22.03.2009

Generative Prozessmodelle Patrick Otto MDD Konferenz 22.03.2009 Generative Prozessmodelle Patrick Otto MDD Konferenz 22.03.2009 Gliederung 1. Generative Programmierung 2. Möglichkeiten und Einsatzgebiet 3. Prozess / Tools 4. Zusammenfassung 19.03.2009 GENERATIVE PROGRAMMIERUNG

Mehr

Synchronisations- Assistent

Synchronisations- Assistent TimePunch Synchronisations- Assistent Benutzerhandbuch Gerhard Stephan Softwareentwicklung -und Vertrieb 25.08.2011 Dokumenten Information: Dokumenten-Name Benutzerhandbuch, Synchronisations-Assistent

Mehr

Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers

Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers Ist Excel das richtige Tool für FMEA? Einleitung Wenn in einem Unternehmen FMEA eingeführt wird, fangen die meisten sofort damit an,

Mehr

WhiteStarUML Tutorial

WhiteStarUML Tutorial WhiteStarUML Tutorial Autor: Simon Balázs, BME IIT, 2015. Übersetzung: Kovács Márton, 2015. Installation Herunterladen und installieren Sie das WhiteStarUML: http://sourceforge.net/projects/whitestaruml/

Mehr

Hochschule Wismar. Fakultät für Wirtschaftswissenschaften. Arbeitskonzept zur Projektarbeit Softwarequalität und Softwarealterung

Hochschule Wismar. Fakultät für Wirtschaftswissenschaften. Arbeitskonzept zur Projektarbeit Softwarequalität und Softwarealterung Hochschule Wismar Fakultät für Wirtschaftswissenschaften Arbeitskonzept zur Projektarbeit Softwarequalität und Softwarealterung Verfasst von: Anne Moormann, Benedikt Scholz, Michael Herbener - 1 - Einleitung

Mehr

Modellgetriebene Service-Entwicklung

Modellgetriebene Service-Entwicklung Modellgetriebene Service-Entwicklung Service-orientierte Architekturen (SOA), Prof. Dr. M. Jäger Johannes Tietje 24. Juni 2010 1 / 13 Motivation konkrete Teile eines Dienstes Rahmenimplementierung der

Mehr

Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.

Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch. Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.pdf 2 Nach derbefragung aller Stakeholder und der Dokumentation

Mehr

Wo sind meine Anforderungen?

Wo sind meine Anforderungen? Whitepaper Telekommunikation Wo sind meine Anforderungen? Eine effektive Lösung auf Basis von Confluence und JIRA 2011 SYRACOM AG 1 Einleitung Erfahrene Projektmitarbeiter sehen sich oftmals im Projektalltag

Mehr

Ein Blick voraus. des Autors von C++: Bjarne Stroustrup. 04.06.2005 Conrad Kobsch

Ein Blick voraus. des Autors von C++: Bjarne Stroustrup. 04.06.2005 Conrad Kobsch Ein Blick voraus des Autors von C++: Bjarne Stroustrup 04.06.2005 Conrad Kobsch Inhalt Einleitung Rückblick Nur eine Übergangslösung? Was würde C++ effektiver machen? Quelle 2 Einleitung Wo steht C++,

Mehr

Übung: Verwendung von Java-Threads

Übung: Verwendung von Java-Threads Übung: Verwendung von Java-Threads Ziel der Übung: Diese Übung dient dazu, den Umgang mit Threads in der Programmiersprache Java kennenzulernen. Ein einfaches Java-Programm, das Threads nutzt, soll zum

Mehr

XINDICE. The Apache XML Project 3.12.09. Name: J acqueline Langhorst E-Mail: blackyuriko@hotmail.de

XINDICE. The Apache XML Project 3.12.09. Name: J acqueline Langhorst E-Mail: blackyuriko@hotmail.de Name: J acqueline Langhorst E-Mail: blackyuriko@hotmail.de 3.12.09 HKInformationsverarbeitung Kurs: Datenbanken vs. MarkUp WS 09/10 Dozent: Prof. Dr. M. Thaller XINDICE The Apache XML Project Inhalt Native

Mehr

10 Erweiterung und Portierung

10 Erweiterung und Portierung 10.1 Überblick In vielen Fällen werden Compiler nicht vollständig neu geschrieben, sondern von einem Rechnersystem auf ein anderes portiert. Das spart viel Arbeit, ist aber immer noch eine sehr anspruchsvolle

Mehr

Visuelle DSLs Trends in der Softwaretechnik: Domänenspezifische Sprachen (Seminar WS 2010/11) Thorsten Arendt

Visuelle DSLs Trends in der Softwaretechnik: Domänenspezifische Sprachen (Seminar WS 2010/11) Thorsten Arendt Visuelle DSLs Trends in der Softwaretechnik: Domänenspezifische Sprachen (Seminar WS 2010/11) Thorsten Arendt Problemlösung = Abstrahierung Entwicklung der Programmiersprachen Maschinencode/Binärcode:

Mehr

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e Metamodellbasierte Codegenerierung in Java

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e Metamodellbasierte Codegenerierung in Java Metamodellbasierte Codegenerierung in Java Codegenerierung Markus Völter, voelter@acm.org, www.voelter.de Codegenerierung bezeichnet die automatische Erstellung von Quelltext aus üblicherweise abstraktereren,

Mehr

Guido de Melo 5.2.2007 Fachvortrag, Uni Ulm UML 2.0. Für den Einsatz in der Praxis

Guido de Melo 5.2.2007 Fachvortrag, Uni Ulm UML 2.0. Für den Einsatz in der Praxis Guido de Melo 5.2.2007 Fachvortrag, Uni Ulm UML 2.0 Für den Einsatz in der Praxis Seite 2 Überblick 1. Ziele 2. Warum das alles? 3. Was ist UML 4. Diagrammarten 5. Umfeld Seite 3 1. Ziele 1. Ziele dieses

Mehr

Variabilität in Produktlinien und das orthogonale Variabilitätsmodell

Variabilität in Produktlinien und das orthogonale Variabilitätsmodell Variabilität in Produktlinien und das orthogonale Variabilitätsmodell Vortrag im Rahmen des Proseminars Softwarequalität und -sicherheit von Marion Weber SS 2010 1 Einführung & Motivation Variabilität

Mehr

Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante

Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante ISO 9001:2015 Die vorliegende Arbeitshilfe befasst sich mit den Anforderungen an qualitätsrelevante Prozesse. Die ISO 9001 wurde grundlegend überarbeitet und modernisiert. Die neue Fassung ist seit dem

Mehr

Umfrage. Didaktischer Kommentar. Lernplattform

Umfrage. Didaktischer Kommentar. Lernplattform Lernplattform Umfrage Didaktischer Kommentar Die Aktivität Umfrage ist ein nützliches Tool, um Einstellungen der Kursteilnehmer zu Beginn und zum Ende des Kurses abzufragen und zu vergleichen. Die Umfrage

Mehr

Informationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse:

Informationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse: Informationssystemanalyse Problemstellung 2 1 Problemstellung Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse: große Software-Systeme werden im Schnitt ein Jahr zu spät

Mehr

Integration mit. Wie AristaFlow Sie in Ihrem Unternehmen unterstützen kann, zeigen wir Ihnen am nachfolgenden Beispiel einer Support-Anfrage.

Integration mit. Wie AristaFlow Sie in Ihrem Unternehmen unterstützen kann, zeigen wir Ihnen am nachfolgenden Beispiel einer Support-Anfrage. Integration mit Die Integration der AristaFlow Business Process Management Suite (BPM) mit dem Enterprise Information Management System FILERO (EIMS) bildet die optimale Basis für flexible Optimierung

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

4. BEZIEHUNGEN ZWISCHEN TABELLEN

4. BEZIEHUNGEN ZWISCHEN TABELLEN 4. BEZIEHUNGEN ZWISCHEN TABELLEN Zwischen Tabellen können in MS Access Beziehungen bestehen. Durch das Verwenden von Tabellen, die zueinander in Beziehung stehen, können Sie Folgendes erreichen: Die Größe

Mehr

Qualitätsmanagement an beruflichen Schulen in Deutschland: Stand der Implementierung. Diplomarbeit

Qualitätsmanagement an beruflichen Schulen in Deutschland: Stand der Implementierung. Diplomarbeit Qualitätsmanagement an beruflichen Schulen in Deutschland: Stand der Implementierung Diplomarbeit vorgelegt an der Universität Mannheim Lehrstuhl für Wirtschaftspädagogik Prof. Dr. Hermann G. Ebner von

Mehr

Die MID ModellierungsMethodik M³ ein Baukasten für Produktlinien. Andreas Ditze, MDD & PL 2009, Leipzig, 23.03.2009

Die MID ModellierungsMethodik M³ ein Baukasten für Produktlinien. Andreas Ditze, MDD & PL 2009, Leipzig, 23.03.2009 Die MID ModellierungsMethodik M³ ein Baukasten für Produktlinien Andreas Ditze, MDD & PL 2009, Leipzig, 23.03.2009 I N H A L T 1. Vorstellung 2. Was macht einen guten Baukasten aus? 3. Ziele der MID ModellierungsMethodik

Mehr

Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements. von Stephanie Wilke am 14.08.08

Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements. von Stephanie Wilke am 14.08.08 Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements von Stephanie Wilke am 14.08.08 Überblick Einleitung Was ist ITIL? Gegenüberstellung der Prozesse Neuer

Mehr

SEW Übung EMFText. 1 Aufgabe. 2 Domänenbeschreibung. 3 Installation von Eclipse/EMFText. 4 Schritt-für-Schritt Anleitung. 4.

SEW Übung EMFText. 1 Aufgabe. 2 Domänenbeschreibung. 3 Installation von Eclipse/EMFText. 4 Schritt-für-Schritt Anleitung. 4. SEW Übung EMFText 1 Aufgabe Erstellen Sie eine textuelle Domänenspezifische Sprache Domain-specific Language (DSL) mit dem Werkzeug EMFText. Die Sprache soll dazu dienen Formulare (Fragen, Antworttypen

Mehr

Abschnitt 12: Strukturierung von Java-Programmen: Packages

Abschnitt 12: Strukturierung von Java-Programmen: Packages Abschnitt 12: Strukturierung von Java-Programmen: Packages 12. Strukturierung von Java-Programmen: Packages 12.1 Strukturierung durch Packages 12.2 Zugriffsspezifikationen 12.3 Zusammenfassung 12 Strukturierung

Mehr

Dokumentation. Black- und Whitelists. Absenderadressen auf eine Blacklist oder eine Whitelist setzen. Zugriff per Webbrowser

Dokumentation. Black- und Whitelists. Absenderadressen auf eine Blacklist oder eine Whitelist setzen. Zugriff per Webbrowser Dokumentation Black- und Whitelists Absenderadressen auf eine Blacklist oder eine Whitelist setzen. Zugriff per Webbrowser Inhalt INHALT 1 Kategorie Black- und Whitelists... 2 1.1 Was sind Black- und Whitelists?...

Mehr

Vorlesung vom 18.04.2005 - Einführung in die geschäftsprozessorientierte Unternehmensführung

Vorlesung vom 18.04.2005 - Einführung in die geschäftsprozessorientierte Unternehmensführung Vorlesung vom 18.04.2005 - Einführung in die geschäftsprozessorientierte Unternehmensführung 08.30 Begrüßung durch Dipl.-Kfm. Björn Simon organisatorische Grundlagen der Veranstaltung (Hinweis auf obligatorische

Mehr

AGROPLUS Buchhaltung. Daten-Server und Sicherheitskopie. Version vom 21.10.2013b

AGROPLUS Buchhaltung. Daten-Server und Sicherheitskopie. Version vom 21.10.2013b AGROPLUS Buchhaltung Daten-Server und Sicherheitskopie Version vom 21.10.2013b 3a) Der Daten-Server Modus und der Tresor Der Daten-Server ist eine Betriebsart welche dem Nutzer eine grosse Flexibilität

Mehr