Mapping-basierte Modellierung von Softwareproduktlinien

Universit¨ at Bayreuth Fakult¨ at f¨ ur Mathematik, Physik und Informatik Institut f¨ ur Informatik Lehrstuhl Angewandte Informatik I Software Engineering Master-Thesis Mapping-basierte Modellierung von Softwareproduktlinien Felix Schw¨ agerl 30. Mai 2012 Pr¨ ufer: Prof. Dr. Bernhard Westfechtel Prof. Dr.-Ing. Stefan Jablonski Zusammenfassung Die modellgetriebene Softwareentwicklung erlaubt die Beschreibung von Softwaresystemen auf h¨ oherem Abstraktionsgrad. Neben der Dokumentation dienen Modelle der automatisierten Generierung von Quelltext in einer h¨ oheren Programmiersprache. Auf ProgrammiersprachenEbene erlauben Konstrukte wie Vererbung oder Typparametrisierung die Wiederverwendung im Kleinen. Ad¨ aquate Konstrukte stehen auf Modell-Ebene zur Verf¨ ugung. Softwareproduktlinien beschreiben Gemeinsamkeiten und Unterschiede verwandter Software. Durch sie kann Wiederverwendung im Großen betrieben werden, um aus einer gemeinsamen Basis ¨ ahnliche Produkte zu erzeugen. Einzelne Produkte unterscheiden sich in der Implementierung spezifischer Softwaremerkmale, die in einem Featuremodell festgehalten werden. Featurekonfigurationen beschreiben hingegen deren Auspr¨ agung je Produkt. Die Kombination des Softwareproduktlinien-Ansatzes mit der modellgetriebenen Entwicklung ist keine neue Idee. Produkte werden hierbei durch Modelle repr¨ asentiert. In dieser Arbeit wird der Sonderfall der negativen Variabilit¨ at betrachtet: Ein Multivarianten-Dom¨ anenmodell beinhaltet s¨ amtliche Artefakte, die in Mitgliedern der Produktfamilie obligatorisch oder optional enthalten sein k¨ onnen. Ein Produkt entsteht durch das L¨ oschen derjenigen Modell-Elemente, die nicht in seiner Konfiguration enthaltenen Features zugeordnet sind. In der vorliegenden Master-Thesis wird ein Ansatz zur Abbildung von Elementen eines Multivarianten-Dom¨ anenmodells auf ein Featuremodell vorgestellt. Die Abbildung selbst wird vom Modellierer in einem sog. Mapping-Modell erzeugt. Es erlaubt die Annotation von Dom¨ anenmodell-Artefakten mit sog. Feature-Ausdr¨ ucken, welche sich wiederum auf das Featuremodell beziehen. Die Auswertung von Feature-Ausdr¨ ucken weist einem Mapping einen Selektionszustand zu. Die Arbeit liefert Beitr¨ age in den folgenden vier Bereichen: Konsistenz Selektionszust¨ ande voneinander abh¨ angiger Mappings widersprechen sich unter bestimmten Voraussetzungen. Die hierbei entstehenden Inkonsistenzen werden nicht nur erkannt; in dieser Thesis ausgearbeitete Strategien wie die Propagation oder Surrogate erlauben die automatische Reparatur derselben. F¨ ur die Formulierung dom¨ anenspezifischer Abh¨ angigkeitsbedingungen ist eine eigene Sprache vorgesehen. Synchronit¨ at Featureund Dom¨ anenmodell unterliegen einer kontinuierlichen Evolution. Durch sie k¨ onnen existierende Mappings ung¨ ultig werden. Gegenstand eines ausgearbeiteten Konzepts ist die weitestgehend automatische Synchronisation der Modelle, wobei ein m¨ oglicher Informationsverlust minimiert wird. Agilit¨ at Die modellgetriebene Entwicklung von Softwareproduktlinien erfolgt nicht ausschließlich plangetrieben. Man will etwa produktspezifische ¨ Anderungen an einem existierenden Mapping-Modell vornehmen. Die eingef¨ uhrten Alternativen-Mappings erm¨ oglichen dar¨ uber hinaus eine konzeptionelle Erweiterung durch positive Variabilit¨ at. Manifestation der Variabilit¨ at In dieser Thesis wird untersucht, inwieweit sich in Featuremodellen festgehaltene Variabilit¨ at auf Produkte niederschlagen kann. Hierbei wird die starre m:n-Beziehung zwischen Features und Dom¨ anenmodell-Artefakten aufgel¨ ost, um neue Expressionsmittel wie Attribut-Constraints zur Verf¨ ugung zu stellen. In einem vorbereitenden Abschnitt werden die erw¨ ahnten Aspekte zun¨ achst theoretisch untersucht. Anschließend wird mit F2DMM eine Modellierungsumgebung f¨ ur Softwareproduktlinien vorgestellt. Schließlich erfolgt eine Evaluierung anhand eines konstruierten Beispiels sowie eine Abgrenzung zu verwandten Ans¨ atzen. Abstract Model driven software engineering allows for the description of software systems at a higher level of abstraction. Models are not only suitable for documentation, but also for an automated generation of source code in a modern programming language. At language level, constructs such as inheritance or type parametrization enable reuse in the small. Adequate constructs exist at modeling level. Software product lines describe commonalities and differences of related software. They enable reuse in the large to derive similar products from a common software basis. Distinct products differ in the implementation of specific software features which can be recorded in afeature model. Contrastingly, a feature configuration describes a product’s characteristics. The combination of both the software product line approach and model driven software engineering is not a novel idea. Products are represented by models in this discipline. This thesis considers the special case of negative variability: a multi-variant domain model contains the complete set of optional or mandatory software artifacts which can occur in some or all of the members of a software family. Deriving a product means deleting model artifacts which are not assigned to any feature that is included in the feature configuration describing it. The present Master thesis introduces an approach for mapping elements of a multi-variant domain model onto elements of a feature model. The mapping itself is created by the user in a so called mapping model. It allows for the annotation of domain model artifacts with feature expressions that refer to the feature model of the product line. Evaluating its feature expression, a distinct selection state is determined for each mapping. The thesis makes contributions in four areas: Consistency Selection states of mutually depending mappings may be contradicting for some conditions, resulting in inconsistencies. Strategies elaborated in this thesis, e.g. propagation and surrogates, do not only identify them, but also allow for an automatic repair. A dedicated language has been developed to enable the phrasing of domain specific consistency conditions. Synchronicity Feature and domain model are affected by continuous evolution, which can turn mappings into an invalid state. Another concept elaborated in this thesis is a mostly automatic synchronization of involved models, minimizing the potential loss of information. Agility Model driven software product line engineering is not supposed to be purely plandriven. Considering mapping models, product specific changes may be intended to occur lately. This requirement is covered by the concept of alternative mappings introduced to even support positive variability. Manifestation of variability The thesis includes an investigation of how variability captured in feature models can influence products. Generally, features are supposed to be related to domain model artifacts by a m:nrelationship only. New concepts try to enhance this by introducing flexible constructs such as attribute constraints. A preparatory section covers the concepts described above in theory. Next, the software product line modeling environment F2DMM is introduced that implements these concepts. Finally, the approach is evaluated using an artificial case study with limited extent. The thesis is concluded by presenting related work. Inhaltsverzeichnis Inhaltsverzeichnis 1 Einleitung 8 1.1 Modelle als Abstraktion von Softwaresystemen . . . . . . . . . . . . . . . . . 8 1.2 Konzepte der Wiederverwendung von Software . . . . . . . . . . . . . . . . . 8 1.2.1 Wiederverwendung im Kleinen: Spezialisierung und Typparametrisierung 8 1.2.2 Wiederverwendung im Großen: Modularisierung und Komponenten . . 10 1.2.3 Organisierte Wiederverwendung: Produktlinien und Softwarefamilien . 11 1.3 Beitrag der Arbeit unter bestimmten Aspekten . . . . . . . . . . . . . . . . . 12 1.3.1 Konsistenz ................................. 12 1.3.2 Synchronit¨ at ................................ 12 1.3.3 Agilit¨ at ................................... 12 1.3.4 Manifestation der Variabilit¨ at....................... 13 1.4 AufbauderArbeit ................................. 13 1.5 Begleitende Ressourcen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2 Modellgetriebene Softwareentwicklung im Eclipse-Kontext 15 2.1 Grundlagen der modellgetriebenen Softwareentwicklung . . . . . . . . . . . . 15 2.1.1 Ziele..................................... 15 2.1.2 Modellierungsebenen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.1.3 Abstrakte und konkrete Syntax . . . . . . . . . . . . . . . . . . . . . . 16 2.2 Das Eclipse Modeling Framework . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2.1 Das Ecore-Metamodell . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2.2 Generierung von Java-Quellcode . . . . . . . . . . . . . . . . . . . . . 21 2.3 EMF-Baumeditoren ................................ 22 2.3.1 Der UI-unabh¨ angige Teil: Item-Provider . . . . . . . . . . . . . . . . . 23 2.3.2 Der Editor als Benutzerschnittstelle . . . . . . . . . . . . . . . . . . . 23 2.3.3 Anpassungsm¨ oglichkeiten ......................... 24 2.4 Das EMF Validation Framework . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.4.1 Definition von Constraints und Invarianten . . . . . . . . . . . . . . . 25 2.4.2 Batchund Live-Validierung . . . . . . . . . . . . . . . . . . . . . . . . 26 2.5 Textuelle Syntax mit Xtext . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.5.1 Aufbau einer Xtext-Grammatik . . . . . . . . . . . . . . . . . . . . . . 27 2.5.2 Generierung von Laufzeitmodulen . . . . . . . . . . . . . . . . . . . . 29 2.5.3 Neuerzeugung oder Wiederverwendung eines Ecore-Modells . . . . . . 30 2.6 OCL - Object Constraint Language . . . . . . . . . . . . . . . . . . . . . . . . 30 2.6.1 EssentialOCL ............................... 31 2.6.2 CompleteOCL............................... 32 2.7 Modell-zu-Modell-Transformationen . . . . . . . . . . . . . . . . . . . . . . . 33 2.7.1 Imperative Ans¨ atze: Java, ATL und QVT Operational . . . . . . . . . 33 2.7.2 Deklarative Ans¨ atze: QVT Relations und Tripel-Graph-Grammatiken 34 3 Vor¨ uberlegungen und Formalisierung der Problemstellung 38 3.1 Modellierung von Softwaremerkmalen . . . . . . . . . . . . . . . . . . . . . . 38 3.1.1 Identifikation von Merkmalen der Variabilit¨ at.............. 38 3.1.2 Merkmale der Variabilit¨ at......................... 38 4 Inhaltsverzeichnis 3.1.3 Softwaremerkmale und Abh¨ angigkeiten: Das Featuremodell von Kang 39 3.1.4 Gruppierung und Kardinalit¨ at von Features . . . . . . . . . . . . . . . 40 3.1.5 Feature-Konfigurationen: Elimination der Variabilit¨ at ......... 41 3.1.6 Zus¨ atzliche Parametrisierung durch Attribute . . . . . . . . . . . . . . 41 3.2 Manifestation der Variabilit¨ at im Dom¨ anenmodell . . . . . . . . . . . . . . . 42 3.2.1 Der Kernel: Die Menge aller gemeinsamen Elemente . . . . . . . . . . 42 3.2.2 Optionale Elemente in Abh¨ angigkeit von der Featurekonfiguration . . 42 3.2.3 Variationspunkte durch sich gegenseitig ausschließende Alternativen . 43 3.2.4 Manifestation der Multiplizit¨ at von Features . . . . . . . . . . . . . . 43 3.2.5 Manifestation von Feature-Attributen . . . . . . . . . . . . . . . . . . 44 3.3 Konsistenz und strukturelle Abh¨ angigkeiten................... 45 3.3.1 Annahmen ................................. 46 3.3.2 Strukturelle Abh¨ angigkeit von Dom¨ anenmodell-Elementen . . . . . . . 46 3.3.3 Abh¨ angigkeitskonflikte und m¨ ogliche L¨ osungen . . . . . . . . . . . . . 48 3.3.4 Surrogate: Wiederherstellung der Konsistenz ohne Informationsverlust 49 3.4 MDPLE als Softwareentwicklungsprozess . . . . . . . . . . . . . . . . . . . . . 49 3.4.1 Das Doppelspiralmodell von Gomaa . . . . . . . . . . . . . . . . . . . 50 3.4.2 Model Driven Architecture . . . . . . . . . . . . . . . . . . . . . . . . 50 3.4.3 Referenzprozess der Softwareproduktlinienentwicklung . . . . . . . . . 51 3.4.4 Vorgeschlagener MDPLE-Prozess . . . . . . . . . . . . . . . . . . . . . 52 3.4.5 Die mathematisch-formelle Sicht: Problemund L¨ osungsraum . . . . . 53 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien 54 4.1 ¨ Ubersicht: Modelle und Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . 54 4.2 Featuremodellierung ................................ 56 4.2.1 Das Feature-Metamodell . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.2.2 Validierung in Featuremodell und -konfiguration . . . . . . . . . . . . 57 4.2.3 Werkzeugunterst¨ utzung .......................... 59 4.2.4 Synchronisation von Featuremodell und -konfiguration . . . . . . . . . 59 4.3 DasF2DMM-Metamodell ............................. 63 4.3.1 Referenzierte Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.3.2 Der Mapping-Baum: Strukturelle Rekonstruktion des Dom¨ anenmodells 64 4.3.3 Kernund Alternativen-Mappings . . . . . . . . . . . . . . . . . . . . 66 4.3.4 Selektionszust¨ ande............................. 66 4.4 FEL: Feature-Ausdr¨ ucke und deren Auswertung . . . . . . . . . . . . . . . . . 68 4.4.1 Elementare Feature-Ausdr¨ ucke: Qualifizierende Namen, Index-Bezug und boolesche Verkn¨ upfungen....................... 68 4.4.2 Feature-Ausdr¨ ucke mit Constraints auf Attributwerten . . . . . . . . . 72 4.4.3 Attribut-Ausdr¨ ucke: Abfrage von Attributwerten der aktuellen Featurekonfiguration ................................ 74 4.4.4 Serialisierung von Feature-Ausdr¨ ucken.................. 77 4.5 SIDRL: Eine Sprache zur Formulierung modellspezifischer Abh¨ angigkeitsbedingungen...................................... 77 4.5.1 Aufbau und Semantik eines SDIRL-Dokuments . . . . . . . . . . . . . 77 4.5.2 Xtext-Grammatik f¨ urSDIRL....................... 78 4.5.3 Editor-Unterst¨ utzung ........................... 81 4.5.4 Auswertung der eingebetteten OCL-Ausdr¨ ucke ............. 82 5 Inhaltsverzeichnis 4.5.5 Auswertung von Surrogat-Ausdr¨ ucken .................. 83 4.6 Mapping-Beschreibungen und Alternativen-Mappings . . . . . . . . . . . . . . 83 4.6.1 Die Konzeptsicht: Mapping-Beschreibungen als Verkn¨ upfung zum Dom¨ anenmodell ................................ 84 4.6.2 Die Anwendersicht: Erzeugung von Alternativen-Mappings . . . . . . 86 4.7 Konflikterkennung, Propagation und Invalidierung . . . . . . . . . . . . . . . 90 4.7.1 Phasen bei der Ermittlung von Selektionszust¨ anden . . . . . . . . . . 91 4.7.2 Beziehungen zwischen Mappings: Die abstrakte Klasse Annotatable . 92 4.7.3 Phase 0: Vorberechnung von Abh¨ angigkeitsund Ausschlussbeziehungen 93 4.7.4 Die Propagationsstrategien ”Vorw¨ arts“ und ”R¨ uckw¨ arts“ . . . . . . . 97 4.7.5 Phasen 1 bis 5: Identifikation und Aufl¨ osung von Konflikten . . . . . . 99 4.7.6 Invalidierungszyklen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 4.8 Ableitung von Produkten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 4.8.1 Notwendige Voraussetzungen f¨ ur die Ableitung von wohlgeformten Produkten.................................... 104 4.8.2 Anpassung des EMF-Copiers f¨ ur die Basistransformation . . . . . . . 105 4.8.3 Behandlung von Alternativen . . . . . . . . . . . . . . . . . . . . . . . 106 4.8.4 Auswahl von Surrogat-Mappings . . . . . . . . . . . . . . . . . . . . . 106 4.8.5 Durchf¨ uhrung von Reparaturaktionen . . . . . . . . . . . . . . . . . . 107 4.9 Synchronisationsund Validierungsmechanismen . . . . . . . . . . . . . . . . 108 4.9.1 Synchronisation von Kern-Dom¨ anenund Mapping-Modell . . . . . . 108 4.9.2 Einbettung der Synchronisation von Featuremodell und -konfiguration 111 4.9.3 Zus¨ atzliche Konsistenzpr¨ ufung mittels EMF-Validierung . . . . . . . . 112 4.10 Weitere Bedienkonzepte des Mapping-Editors . . . . . . . . . . . . . . . . . . 115 4.10.1 Die F2DMM-Perspektive . . . . . . . . . . . . . . . . . . . . . . . . . 115 4.10.2 Annotation von Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 116 4.10.3 Das Property-Sheet als Diagnose-Ansicht . . . . . . . . . . . . . . . . 118 4.10.4 Anzeigeoptionen auf der F2DMM-Preference-Page . . . . . . . . . . . 118 4.10.5 Der F2DMM-Wizard und das FAMILE-Dashboard . . . . . . . . . . . 121 5 Beispiel zur Evaluierung des Ansatzes 123 5.1 BeteiligteModelle ................................. 123 5.1.1 Featuremodell................................ 123 5.1.2 Featurekonfigurationen . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 5.1.3 Multivarianten-Dom¨ anenmodell...................... 125 5.2 Strukturelle Abh¨ angigkeiten f¨ ur UML2-Klassenund Zustandsdiagramme . . 130 5.3 Aufl¨ osung von Inkonsistenzen im Mapping-Modell . . . . . . . . . . . . . . . 131 5.3.1 Unvollst¨ andig annotierte Pakethierarchie . . . . . . . . . . . . . . . . . 132 5.3.2 Abbildung mehrwertiger Features . . . . . . . . . . . . . . . . . . . . . 132 5.3.3 Abh¨ angigkeiten von Zust¨ anden und Transitionen . . . . . . . . . . . . 133 5.3.4 Attribut-abh¨ angige Kardinalit¨ at einer Assoziation . . . . . . . . . . . 134 5.3.5 Unterbrechung einer mehrstufigen Vererbungshierarchie . . . . . . . . 136 5.3.6 Surrogate und Ausschlusskonflikte . . . . . . . . . . . . . . . . . . . . 136 5.4 AbgeleiteteProdukte................................ 138 5.4.1 Auswahl von Surrogat-Kandidaten . . . . . . . . . . . . . . . . . . . . 138 5.4.2 Wiederherstellung der Vererbungshierarchie . . . . . . . . . . . . . . . 139 5.4.3 Zustandsdiagramme in unterschiedlichen Produkten . . . . . . . . . . 139 6 Inhaltsverzeichnis 5.4.4 Abbildung von Attributen: Kardinalit¨ aten und Klassennamen . . . . . 140 5.5 Ausblick: Evaluierung in einer Fallstudie mit der MOD2-SCM-Produktlinie . 141 6 Abgrenzung zu verwandten MDPLE-Ans¨ atzen 142 6.1 Vom bedingten ¨ Ubersetzen zu programmiersprachenzentrierten Ans¨ atzen . . 142 6.1.1 Pr¨ aprozessor-Makros............................ 142 6.1.2 CIDE .................................... 143 6.2 Ans¨ atze ohne Trennung der Featurevon der Dom¨ anenmodellierung . . . . . 144 6.2.1 PLUS: UML-basierte SPL-Entwicklung . . . . . . . . . . . . . . . . . 145 6.2.2 Der Ansatz von Ziadi und J´ez´equel f¨ ur die statische Modellierung . . . 146 6.2.3 Der PLiBS-Ansatz f¨ ur die dynamische Modellierung . . . . . . . . . . 147 6.3 Implizite Abbildung von Features . . . . . . . . . . . . . . . . . . . . . . . . . 148 6.3.1 MODPL................................... 148 6.4 Explizite Abbildung von Features: Mapping-Modelle . . . . . . . . . . . . . . 149 6.4.1 FeatureMapper .............................. 149 6.5 Modellierung auf Basis positiver Variabilit¨ at................... 152 6.5.1 MATA.................................... 152 6.5.2 VML*.................................... 154 7 Abschließende Bemerkungen 155 7.1 Zusammenfassung ................................. 155 7.2 R¨ uckbezug auf die identifizierten Aspekte . . . . . . . . . . . . . . . . . . . . 155 7.2.1 Konsistenz ................................. 156 7.2.2 Synchronit¨ at ................................ 156 7.2.3 Agilit¨ at ................................... 156 7.2.4 Manifestation der Variabilit¨ at....................... 157 7.3 Diskussion...................................... 157 7.3.1 Produktlinien – pro-aktiv oder reaktiv? . . . . . . . . . . . . . . . . . 157 7.3.2 Generizit¨ at bez¨ uglich des Dom¨ anen-Metamodells . . . . . . . . . . . . 157 7.3.3 Positive vs. negative Variabilit¨ at ..................... 158 7.4 M¨ ogliche zuk¨ unftigeArbeit ............................ 158 7.4.1 Beschreibung von Teiltransformationen auf h¨ oherer Abstraktionsebene 158 7.4.2 Tiefere Integration in die Werkzeuge der Dom¨ anenmodellierung . . . . 159 7.4.3 Untersuchung von Produktlinien zur Modellierung von Verhalten . . . 159 7.5 Schlusswort ..................................... 160 Abbildungsverzeichnis 161 Tabellenverzeichnis 163 Quelltextverzeichnis 163 Abk¨ urzungsverzeichnis 164 Literatur 166 7 1 Einleitung 1 Einleitung 1.1 Modelle als Abstraktion von Softwaresystemen Das Abstraktionsniveau bei der Entwicklung von Softwaresystemen steigt seit jeher an: In den 1960er Jahren wurden Assemblersprachen als vermeintlich menschenlesbare Metaphern f¨ ur Maschinenbefehle entworfen. Die steigende Komplexit¨ at von zu entwickelnder Software erforderte jedoch schnell die Einf¨ uhrung einer weiteren Abstraktionsebene: H¨ ohere Programmiersprachen lassen sich wiederum mit Hilfe von Compilern in Assemblerprogramme ¨ ubersetzen. Seit den 1980er Jahren vollzog sich bei der Entwicklung neuer Sprachen ein st¨ andiger Paradigmenwechsel: Angefangen bei der strukturierten Programmierung, bis hin zu den heute g¨ angigen Konzepten der objektorientierten oder funktionalen Programmierung. Eine Gemeinsamkeit aller in h¨ oheren Programmiersprachen formulierten Programme ist der zus¨ atzliche Bedarf an technischer Dokumentation, welche den Sprung von der Konzeptauf die Implementierungsebene erleichtern soll. Zur abstrakten Beschreibung von Anwendungssystemen haben sich im Bereich des Software Engineering verschiedene Diagrammarten etabliert. Die Sprache UML (Unified Modeling Language, vgl. Hitz und Kappel [32] im Literaturverzeichnis) vereint alle zur Dokumentation von Software notwendigen Diagrammarten in einer Diagrammfamilie. Standardisierte Diagramme dienen der Kommunikation von Ideen vor, bzw. der Beschreibung von erzeugter Software nach der Implementierung. Als Hauptvorteil von UML wird der gesteigerte Abstraktionsgrad gesehen. W¨ ahrend UML einen generellen Modellierungsansatz f¨ ur Softwaresyteme darstellt, existieren zus¨ atzlich eine Vielzahl dom¨ anenspezifischer Sprachen, die es erlauben, auf bestimmte Anwendungszwecke zugeschnittene Modelle zu entwerfen. Die modellgetriebene Softwareentwicklung (MDSE) hat zum Ziel, Diagramme bzw. Modelle nicht weiterhin begleitend zur Programmierung eines Systems als zus¨ atzliches, nur der Dokumentation dienendes Artefakt zu erzeugen, sondern sie pr¨ askriptiv einzusetzen, um Quelltext aus ihnen abzuleiten. Modelle werden hierbei als Abstraktion der Software auf h¨ oherer Ebene verstanden — sie verhalten sich also zum Quelltext wie der Quelltext zu einem entsprechenden Assemblerprogramm. 1.2 Konzepte der Wiederverwendung von Software Software wird in den seltensten F¨ allen von Grund auf neu entwickelt: In gr¨ oßeren Projekten wird h¨ aufig von gemeinsamen Bibliotheken Gebrauch gemacht, die wiederverwendbare Softwareartefakte bereitstellen. Die objektorientierte Programmierung (OOP) in einer Sprache wie Java (s. Ullenboom [51]) bietet die Voraussetzungen hierf¨ ur in Form geeigneter Sprachkonstrukte. 1.2.1 Wiederverwendung im Kleinen: Spezialisierung und Typparametrisierung Das zentrale Konzept der objektorientierten Programmierung sind Klassen (vgl. [51, Abschnitt 3]): Sie fassen Attribute und Operationen zusammen, um Eigenschaften und Verhaltensweisen einer Menge von Objekten zu beschreiben. Objekte wiederum lassen sich aus eine Klasse erzeugen (instanziieren); ihr Zustand wird durch die Werte ihrer Attribute bestimmt. Eine Klasse l¨ asst sich folglich als Bauplan f¨ ur Objekte desselben Typs betrachten. OOP erlaubt zus¨ atzlich, Klassen miteinander in Beziehung zu setzen und sieht hierf¨ ur die Konstrukte Spezialisierung und Typparametrisierung vor, die im Folgenden erl¨ autert werden: 8 1 Einleitung Spezialisierung (auch Vererbung, vgl. [51, Abschnitt 5.8]): Klassen k¨ onnen bei ihrer Definition die Attribute und Operationen einer vorhandenen Klasse (Oberklasse) erweitern oder neu definieren. Vorhandener Quellcode kann auf diese Weise wiederverwendet werden. Instanzen der spezialisierten Klasse sind immer kompatibel mit ihrer Oberklasse. In Java wird die Spezialisierung durch das Schl¨ usselwort extends notiert (s. Quelltext 1.1). Auch UML-Klassendiagramme sehen f¨ ur die Darstellung von Vererbungsbeziehungen spezielle Diagrammelemente vor (vgl. Abbildung 1.1). 1public class Vehicle { 2public double speed; 3} 4 5public class Car extends Vehicle { 6public int doors; 7} Quelltext 1.1: Notation der Vererbung in Java. Vehicle + speed : double Car + doors : int Abbildung 1.1: Darstellung von Vererbung in UML-Klassendiagrammen. Ein Pfeil mit fl¨ achiger Spitze stellt eine Generalisierung (Gegenrichtung der Spezialisierung) dar. Typparametrisierung (auch Generizit¨ at, vgl. [51, Abschnitt 9]): Eine Klasse enth¨ alt optional einen oder mehrere Typparameter, die als Platzhalter f¨ ur konkrete Typen fungieren. Bei der Instanziierung einer typparametrisierten Klasse in Java muss je ein konkreter Typ angegeben werden, der f¨ ur das erzeugte Objekt den Platz eines Typparameters einnimmt (s. Quelltext 1.2). In der UML erfolgt hingegen das Binden von Typparametern an konkrete Typen zun¨ achst auf Diagrammebene, bevor Instanzen erzeugt werden k¨ onnen (vgl. Abbildung 1.2). 1public class List<T> { 2protected T[] elements; 3public T get(int i){/*..*/ } 4public void add(int i, T element) { /*..*/ } 5} 6 7public class ListTest { 8public static void main(String[] args) { 9List<Vehicle> vehicleList = new List<Vehicle>(); 10 Carc=new Car(); 11 c.speed = 180.0; 9 2 Modellgetriebene Softwareentwicklung im Eclipse-Kontext 2.1.2 Modellierungsebenen Voraussetzung f¨ ur die Erzeugung wohlgeformter Modelle ist eine Modellierungssprache, die verwendbare Modell-Elemente definiert. In Analogie zu den formalen Sprachen [1, 52] kann eine solche durch die Menge verwendbarer Modell-Elemente in einer Grammatik definiert werden. Die Definition einer Grammatik kann wiederum durch ein Modell erfolgen: Ein konkretes, auf der zuvor definierten Modellsprache basierendes Modell wird somit zur Instanz eines Metamodells [7]. Abbildung 2.1 veranschaulicht diesen Zusammenhang: Auf Ebene M1 werden konkrete Modelle beschrieben, beispielsweise UML-Klassendiagramme. Im (UML-)Metamodell (M2) werden verf¨ ugbare Modellierungskonstrukte beschrieben. Typischerweise werden in einem Metamodell verwendbare Elemente (Klassen), deren Eigenschaften (Attribute) und ihr Wertebereich, sowie m¨ ogliche Beziehungen zwischen Klassen (Referenzen) definiert. Metametamodell (M3) Metamodell (M2) Modelle (M1) Modellinstanzen (M0) Abbildung 2.1: Modellierungsebenen: Ein Modell kann jeweils als Instanz eines Modells aus der n¨ achsth¨ oheren Ebene dargestellt werden. Modelle auf der M3-Ebene sind in der Lage, sich selbst zu beschreiben. Die h¨ ochste Modellierungsebene, M3, erlaubt die Beschreibung eines Metametamodells, welches wiederum Elemente des Metamodells definiert. Es ist meist so formuliert, dass es in der Lage ist, sich selbst zu definieren; in der Theorie w¨ aren jedoch beliebig viele Meta-Ebenen erlaubt. Die Object Management Group (OMG) schl¨ agt als M3-Modell den Standard MOF (Meta Object Facility, [42]) vor, in dem die kleinstm¨ ogliche Elementmenge f¨ ur Metamodelle identifiziert wird. Der MOF-Standard wird vom Ecore-Metamodell (s. Abschnitt 2.2.1) implementiert. ¨ Uber die Bedeutung der Ebene M0 existieren in der Modelltheorie unterschiedliche Annahmen [8]: Sie beinhaltet entweder die ”Objekte der Realit¨ at“, welche durch das Modell repr¨ asentiert werden, oder im Falle eines ausf¨ uhrbaren Modells die Gesamtheit aller vorhandenen Laufzeitobjekte, welche durch das Modell erzeugt wurden. 2.1.3 Abstrakte und konkrete Syntax Bisher wurden die Begriffe ”Modell“ und ”Diagramm“ als Synonyme betrachtet. Tats¨ achlich stehen beide Begriffe in einer anderen Beziehung zueinander: Ein Diagramm ist eine m¨ ogliche, grafische Repr¨ asentation eines Modells. Eine weitere Form der Repr¨ asentation eines Modells ist beispielsweise die textuelle Syntax. Letztere hilft auch bei der Herstellung der Analogie zu 16 2 Modellgetriebene Softwareentwicklung im Eclipse-Kontext den erw¨ ahnten formalen Sprachen, bei denen man ebenfalls zwischen abstrakter und konkreter Syntax unterscheidet. Im Folgenden werden die Zusammenh¨ ange anhand eines Beispiels erl¨ autert. Es basiert auf einem Teil des UML2-Metamodells, der in Abbildung 2.2 eingef¨ uhrt wird. NamedElement name: EString TypedElement Type Parameter Direction: ParameterDirectionKind Attribute Class PrimitiveType Operation <<enum>> ParameterDirectionKind RETURN IN OUT INOUT ownedParameters 0..* 0..* 0..* 0..* ownedOperations ownedAttributes type Abbildung 2.2: Ein auf die f¨ ur die nachfolgenden Ausf¨ uhrungen relevanten Elemente reduzierter Auszug aus dem UML2-Metamodell. Es definiert eine Untermenge der in UML2Klassendiagrammen verwendbaren Elemente: Klassen setzen sich aus Attributen und Operationen zusammen, letztere wiederum beinhalten Parameter. Die Metaklassen Attribute und Parameter erben die Referenz auf Type von der abstrakten Klasse TypedElement. Die Instanziierung erm¨ oglicht, aus einer Modellsprache, etwa einem Metamodell, ein Modell zu erzeugen. Sie beschreibt also den ¨ Ubergang von einer Modellierungsebene auf die n¨ achstniedrigere. In der objektorientierten Programmierung findet eine Instanziierung beispielsweise durch Aufruf eines Konstruktors statt: Aus einer Klasse wird ein Objekt als Instanz der Klasse abgeleitet. Analog dazu stellt das MOF-Objektdiagramm in Abbildung 2.3 eine Instanz des Klassendiagramms aus Abbildung 2.2 dar. Das Objektdiagramm repr¨ asentiert ein UML-Klassendiagramm2in abstrakter Syntax. Diese Art der Repr¨ asentation entzieht sich jedoch h¨ aufig der Interpretierbarkeit innerhalb der Zieldom¨ ane: Die grafische Repr¨ asentation von Modellen soll, im Gegensatz zur logischen Repr¨ asentation, vom Metamodell abh¨ angen. Die Repr¨ asentation eines Modells durch Diagramme bzw. Text wird durch die Definition einer konkreten Syntax (s. Abbildung 2.4 und Quellcode 2.1) erzielt. W¨ ahrend Referenzen, also Beziehungen zwischen Modell-Elementen, in grafischer Notation durch entsprechende Verbindungslinien dargestellt werden k¨ onnen, ist das mehrfache Auftreten desselben Elements als Ziel mehrerer Referenzen in textueller Notation schwieriger darzustellen. Meist erfolgt der R¨ uckbezug ¨ uber einen eindeutigen Bezeichner. Unabh¨ angig von der konkreten Repr¨ asentation m¨ ussen folgende Arten des Auftretens von Objekten unterschieden werden: 2korrekterweise m¨ usste man hier von einem Klassenmodell sprechen. Im Kontext von UML-Modellen hat sich jedoch der Begriff Klassendiagramm auch f¨ ur die abstrakte Repr¨ asentation etabliert. 17 2 Modellgetriebene Softwareentwicklung im Eclipse-Kontext : Class name = „Keypad“ : Attribute name = „algorithm“ : Operation name = „identify“ : Parameter direction = ParameterDirectionKind.RETURN : Parameter name = input direction = ParameterDirectionKind.IN : PrimitiveType name = „boolean“ : PrimitiveType name = „String“ type type type ownedAttributes ownedParameters ownedOperations Abbildung 2.3: Beispiel f¨ ur ein UML2-Modell als Instanz des UML2-Metamodells aus Abbildung 2.2, dargestellt als MOF-Objektdiagramm. Es stellt in abstrakter Syntax eine UML-Klasse Keypad dar, welche ein Attribut algorithm vom Typ String sowie eine Operation namens identify beinhaltet. Die ¨ uber ownedParameters enthaltenen Operationsparameter definieren den R¨ uckgabetyp (boolean) sowie den Formalparameter input vom Typ String. Keypad + algorithm: String + identify (input : String): boolean Abbildung 2.4: Darstellung des UML2-Modells aus Abbildung 2.3 in konkreter grafischer Syntax, definiert durch den UML2-Standard [44]. Das Symbol ”+“ definiert eine Sichtbarkeit (public), welche aus Gr¨ unden der ¨ Ubersichtlichkeit nicht im vorliegenden Ausschnitt des Metamodells ber¨ ucksichtigt wurde. 18 2 Modellgetriebene Softwareentwicklung im Eclipse-Kontext Deklarierendes Auftreten Hierdurch wird ein Objekt in seiner Struktur definiert und innerhalb eines bestimmten Sichtbarkeitsbereiches als Ziel einer Referenz (in textueller Notation ¨ uber einen eindeutigen Bezeichner) verf¨ ugbar gemacht. Angewandtes Auftreten Es erfolgt R¨ uckbezug auf ein durch ein deklarierendes Auftreten erzeugtes Objekt (in textueller Notation ¨ uber dessen Bezeichner). So wird sein mehrfaches Auftreten als Referenzziel in unterschiedlichen Bereichen des Modells erm¨ oglicht. 1primitive String 2primitive boolean 3 4class Keypad { 5property public algorithm : String 6operation public identify (input : String) : boolean 7} Quelltext 2.1: Darstellung des UML2-Modells aus Abbildung 2.3 in einer konkreten, textuellen Notation. Der Text enth¨ alt dieselbe Information wie das Diagramm in Abbildung 2.4. In Quelltext 2.1 findet das deklarierende Auftreten der Elemente String bzw. boolean innerhalb entsprechender primitive-Anweisungen statt. Im Sichtbarkeitsbereich des deklarierenden Auftretens sind diese beiden Elemente als Referenzziel verf¨ ugbar (s. Ende der Zeilen 6 und 7). 2.2 Das Eclipse Modeling Framework 2.2.1 Das Ecore-Metamodell Das von der Eclipse Community3hervorgebrachte Modellierungsrahmenwerk Eclipse Modeling Framework (EMF) [48] stellt eine Java-basierte Plattform und Werkzeuge f¨ ur die modellgetriebene Softwareentwicklung zur Verf¨ ugung. Das Ecore-Metamodell implementiert den von der OMG vorgeschlagenen MOF-Standard und unterst¨ utzt das XML-basierte Austauschformat XMI (XML Metadata Interchange) f¨ ur Modellinstanzen. Ecore kann entweder auf M2-Ebene zur Modellierung von Klassendiagrammen, oder auf M3-Ebene zur Definition eines eigenen Metamodells f¨ ur eine dom¨ anenspezifische Sprache verwendet werden. Im Rahmen des Eclipse Modeling Project (EMP) wird etwa ein Ecore-basiertes UML-Metamodell gepflegt. Im Folgenden wird auf Spezifika des Ecore-Metamodells eingegangen. Hierarchisierung von Datentypen Abbildung 2.5 zeigt einen f¨ ur die weiteren Ausf¨ uhrungen relevanten Auszug aus dem Ecore-Metamodell: Ineinander verschachtelte Pakete (repr¨ asentiert durch EPackage) beinhalten wiederum Datentypen (EClassifier). Pakete werden global durch eine eindeutige Package-URI qualifiziert. Beispiele f¨ ur Datentypen sind Klassen (EClass), die strukturelle Eigenschaften (EStructuralFeature) und Operationen (EOperation) beinhalten. Instanzen von EDataType bilden in Ecore primitive JavaDatentypen wie Integer oder String ab. 3http://www.eclipse.org 19 2 Modellgetriebene Softwareentwicklung im Eclipse-Kontext EClass eSuperTypes 0 .. * EStructuralFeature lowerBound : EInt upperBound : EInt EAttribute EReference containment : EBoolean eStructuralFeatures 0 .. * EDataType EClassifier eReferenceType eAttributeType 1 1 ENamedElement name : EString eOpposite 0 .. 1 EOperation eType 0 .. 1 eOperations 0 .. * EPackage 0 .. * eClassifiers ETypedElement EParameter 0 .. * eParameters 0 .. * eSubPackages Abbildung 2.5: Das Ecore-Metamodell in Klassendiagramm-Notation (vereinfachte Darstellung) [48]. Strukturelle Eigenschaften Die konkreten Metaklassen EAttribute und EReference repr¨ asentieren strukturelle Eigenschaften. Durch deren Attribute lowerBound und upperBound wird die Wertigkeit von Attributen bzw. Referenzen angegeben: Ist die Obergrenze gr¨ oßer eins, so bezeichnet man eine strukturelle Eigenschaft als mehrwertig. W¨ ahrend Attribute primitive Datentypen abbilden, sind die Typen von Referenzen immer Klassen. Ist das boolesche Attribut containment gesetzt, so handelt es sich um eine sog. Containment-Referenz: Referenzziele sind in diesem Fall existenzabh¨ angig von ihrem eContainer. Unabh¨ angig davon k¨ onnen bidirektionale Referenzen durch gegenseitiges Setzen von eOpposite eines Referenzpaars erzeugt werden. Modellierung von Verhalten Analog zu den strukturellen Eigenschaften stellen Instanzen von EOperation die sog. verhaltensbezogenen Eigenschaften einer Klasse dar. Operationen beinhalten eine Menge von Parametern (EParameter), welche genauso wie die Operation selbst einen Typ haben (im Falle einer Operation der R¨ uckgabetyp). Das Verhalten einer Methode selbst – deren Ausf¨ uhrungssemantik – kann nicht mit Hilfe des Ecore-Metamodells ausgedr¨ uckt werden. Stattdessen werden in generiertem Java-Quellcode (s. Abschnitt 2.2.2) leere Methodenr¨ umpfe erzeugt, die manuell implementiert werden m¨ ussen, um dem Modell dynamisches Verhalten hinzuzuf¨ ugen. 20 2 Modellgetriebene Softwareentwicklung im Eclipse-Kontext 2.2.2 Generierung von Java-Quellcode In der Einleitung wurde bereits erw¨ ahnt, dass die Modellierung auf einer h¨ oheren Abstraktionsebene wie die Programmierung in einer modernen Programmiersprache wie Java anzusiedeln ist. Steinberg u. a. [48, Abschnitt 2.2] behaupten jedoch: ”To model or to program, that is not the question.“ (”Modellieren oder Programmieren, das ist nicht die Frage.“, ¨ Ubers. d. Autors). Sie st¨ utzen diese Behauptung auf das Argument, EMF biete f¨ ur jeden Zweck den geeigneten Abstraktionsgrad: Paketund Klassenstrukturen eines Metamodells lassen sich leicht durch Ecore beschreiben. Das dynamische Verhalten hingegen sei durch Modelle weniger einfach zu spezifizieren als auf Quelltext-Ebene. Die EMF-Codegenerierung schl¨ agt die Br¨ ucke zwischen Modellierung und Programmierung, indem sie die ¨ Ubersetzung eines Ecore-Modells in JavaQuelltext erm¨ oglicht. In diesem Abschnitt liegt der Fokus auf der Codegenerierung f¨ ur durch ein Ecore-Modelle beschriebene Klassendiagramme. Der nachfolgende Abschnitt 2.3 befasst sich dar¨ uber hinaus mit der Generierung von Editoren. Das Interface EObject Zur Laufzeit werden alle Objekte, die durch ein auf Ecore basierendes Metamodell erzeugt wurden, als Instanzen des Interface EObject repr¨ asentiert. Die EMF-Codegenerierung sorgt bei der Abbildung von Ecoreauf Java-Klassen daf¨ ur, dass alle Klassen direkt oder indirekt von EObject erben. Diese erlaubt den generischen Zugriff auf jede Ecore-basierte Modellinstanz: Strukturelle Eigenschaften k¨ onnen etwa auch dann abgefragt oder gesetzt werden, wenn generierte Java-Klassen nicht bekannt sind4.EObject bietet auf Java-Ebene u.A. folgende Methoden an, die durch die EMF-Codegenerierung automatisch implementiert werden: •eClass(): Liefert die das Objekt definierende EClass zur¨ uck und erlaubt so den reflexiven Zugriff auf das Metamodell. •eResource(): Gibt die EMF-Ressource an, die das vorliegende Objekt beinhaltet. Ressourcen k¨ onnen beispielsweise in XMI serialisiert werden. •eContainer(): Gibt dasjenige EObject an, von welchem das vorliegende Objekt unmittelbar existentiell abh¨ angt5. •eContents(): Gibt diejenigen Instanzen von EObject zur¨ uck, die durch eine Containment-Referenz vom vorliegenden Objekt abgebildet werden. •eGet(EStructuralFeature): Liefert alle Objekte zur¨ uck, welche vom vorliegenden Objekt ¨ uber eine gegebene strukturelle Eigenschaft abh¨ angen. Diese k¨ onnen einoder mehrwertig, sowie durch primitive Datentypen oder Klassen definiert sein. •eSet(EStructuralFeature, Object): Setzt den durch die ¨ ubergebene strukturelle Eigenschaft abgebildeten Wert neu. 4In der generischen Variante Dynamic EMF wird vollst¨ andig auf Codegenerierung verzichtet; alle Zugriffe geschehen ¨ uber die generische Schnittstelle. Dadurch verbietet sich zun¨ achst die Angabe von Ausf¨ uhrungssemantik, da keine ausf¨ ullbaren Methodenr¨ umpfe existieren. 5Die MOF-Spezifikation verlangt, dass dieses Objekt, falls vorhanden, eindeutig sein muss. Ansonsten ist es das Wurzelelement einer Ressource. 21 2 Modellgetriebene Softwareentwicklung im Eclipse-Kontext Klassen, Attribute und Referenzen Wie bereits erw¨ ahnt, werden Ecore-Klasen w¨ ahrend der Codegenerierung auf Java-Klassen abgebildet. Genau genommen erfolgt die Abbildung auf ein Paar von Klasse und Interface, wobei die (Implementierungs-) Klasse jeweils das Suffix Impl erh¨ alt. Attribute werden durch private Objektfelder mit dem entsprechenden Java-Datentyp repr¨ asentiert; außerdem werden entsprechende Zugriffsmethoden (get/set) erzeugt. Mehrwertige Attribute werden in speziellen Datenstrukturen, jeweils von java.util.Collection erbend, abgelegt. Referenzen werden ebenfalls durch private Felder mit entsprechenden Zugriffsmethoden repr¨ asentiert. Einen Sonderfall stellen ¨ uber das Setzen von eOpposite definierte bidirektionale Referenzen dar: Hier sorgt der generierte Quellcode f¨ ur den Erhalt der Konsistenz beim Setzen der Referenzziele. Operationen und gesch¨ utzte Bereiche Wie bereits erw¨ ahnt, erzeugt die EMFCodegenerierung f¨ ur EOperations lediglich leere Methodenr¨ umpfe; lediglich Formalund R¨ uckgabeparameter werden aus dem Ecore-Modell ¨ ubernommen. Die Implementierung des durch eine Operation beschriebenen Verhaltens nach der Codegenerierung ist Aufgabe des Modellierers, bzw. des Programmierers. Die Generierung von Quellcode erfolgt nicht inkrementell, sondern vollst¨ andig f¨ ur jeweils ein Ecore-Modell. Um manuell hinzugef¨ ugten Quellcode vor einem erneuten ¨ Uberschreiben durch die Codegenerierung zu sch¨ utzen, muss die Javadoc-Annotation @generated NOT vor dem entsprechenden Quelltextfragment eingef¨ ugt werden. 2.3 EMF-Baumeditoren Die EMF-Codegenerierung unterst¨ utzt nicht nur die ¨ Ubersetzung eines Ecore-Modells in Java-Quellcode, welcher das Modell repr¨ asentiert, sondern auch die Erzeugung eines prototypischen Baumeditors, in dem Modellinstanzen in deren abstrakter Syntax eingesehen und manipuliert werden k¨ onnen. Die Generierung von Quellcode wird prinzipiell ¨ uber ein sog. EMF-Generatormodell gesteuert, in dem die Codegenerierung zus¨ atzlich angepasst werden kann (vgl. auch Abschnitt 2.3.3). Das Generatormodell erlaubt die Erzeugung von vier unterschiedlichen Eclipse-Plugins [48, Kapitel 2.4]: Model Erzeugt das Datenmodell in seiner Java-Repr¨ asentation, wie im vorhergehenden Unterabschnitt beschrieben. Edit Generiert wiederverwendbaren, von der Benutzerschnittstelle unabh¨ angigen Code, der Darstellung und Manipulation des von Modellen beschreibt (vgl. Abschnitt 2.3.1). Editor Erzeugt einen prototypischen Baumeditor auf Basis der GUI-Bibliothek JFace6, der den Edit-Quellcode wiederverwendet (vgl. Abschnitt 2.3.2). Test Stellt einen Rahmen zur Implementierung von Testf¨ allen zur Verf¨ ugung. Dieses Plugin ist f¨ ur die weiteren Ausf¨ uhrungen nicht relevant. 6http://wiki.eclipse.org/index.php/JFace 22 2 Modellgetriebene Softwareentwicklung im Eclipse-Kontext 2.3.1 Der UI-unabh¨ angige Teil: Item-Provider Das generierte Edit-Plugin stellt pro nicht-abstrakter Modellklasse einen sog. ItemProvider zur Verf¨ ugung. Dieser beschreibt die Darstellung und Manipulation von ModellElementen, ohne auf die Spezifika von Benutzeroberfl¨ achen Bezug zu nehmen. Die generierten ItemProvider-Klassen ¨ ubernehmen f¨ ur ihre entsprechenden Modellinstanzen mehrere Rollen, was sich jeweils durch Implementierung eines oder mehrerer Interfaces ausdr¨ uckt: •ItemProviderAdapter: Erlaubt die Registrierung des Item-Providers an jeweils ein oder mehrere Instanzen einer Modellklasse ¨ uber den Ecore-internen Adapter-Mechanismus7. •Structuredbzw. TreeItemContentProvider: Definiert die Methoden getElements() bzw. getChildren() und getParents(), die jeweils Kindoder Eltern-Elemente der durch den Item-Provider beschriebenen Modellinstanz bestimmen. Diese Mechanismen werden beispielsweise von hierarchischen Baumeditoren genutzt. •IItemLabelProvider: Verlangt die Implementierung von getText() und getImage(), die einen beschreibenden Text bzw. ein repr¨ asentatives Symbol zur¨ uckgeben. •IItemPropertySource: Stellt den Bezug zum sog. Property Sheet her, in dem Eigenschaften selektierter Objekte angezeigt bzw. manipuliert werden k¨ onnen. Der implementierende Item-Provider registriert sich hierf¨ ur beim Eclipse-weiten Selection Service. •IEditingDomainItemProvider: Definiert Kind-Objekte, welche unter einem vom jeweiligen Item-Provider abgebildeten Element erstellt werden k¨ onnen und integriert den Item-Provider in das EMF Command Framework, welches die Durchf¨ uhrung elementarer Manipulations-Operationen steuert. Zus¨ atzlich wird pro Ecore-Modell eine Klasse mit dem Suffix ItemProviderAdapterFactory generiert, die die Erzeugung eines geeigneten Item-Providers f¨ ur eine Modellklasse delegiert. Dieser Mechanismus erlaubt die Wiederverwendung des Edit-Codes auch wenn die konkrete Item-Provider-Klasse nicht bekannt ist. 2.3.2 Der Editor als Benutzerschnittstelle Der Baumeditor, der im Generator-Modell erzeugt werden kann, ist nicht als vollwertige Anwenderschnittstelle, sondern vielmehr als Prototyp zu betrachten, der demonstrieren soll, wie der generierte Edit-Code zur manuellen Implementierung eines – grafischen oder textuellen – Editors verwendet werden kann, etwa um die Unterst¨ utzung f¨ ur konkrete Syntax zu implementieren. Abbildung 2.6 zeigt einen generierten Baumeditor ohne weitere Anpassungen8. Im Hauptfenster wird das Modell in seiner durch die Containment-Hierarchie definierten Baumstruktur angezeigt. Wird ein Eintrag ausgew¨ ahlt, so werden dessen strukturelle Eigenschaften in der Properties-Ansicht angezeigt. Dort wird auch Unterst¨ utzung bei der Manipulation von Werten von Attributen und Zielen von Nicht-Containment-Referenzen gegeben. Die durch IEditingDomainItemProvider gesteuerte Erzeugung von Kind-Elementen wird ¨ uber einen Rechtsklick auf das entsprechende Element im Baum erzielt. Auch das L¨ oschen 7Das Entwurfsmuster Adapter ist in [21, Abschnitt 4.1] beschrieben. 8Der hier dargestellte generierte Editor entstammt einem fr¨ uhen Prototypen des in Abschnitt 4 vorgestellten F2DMM-Editors. 23 2 Modellgetriebene Softwareentwicklung im Eclipse-Kontext Abbildung 2.6: Beispiel f¨ ur einen generierten EMF-Baumeditor. von Elementen oder das R¨ uckg¨ angigmachen bzw. Wiederholen von Aktionen ist per Kontextmen¨ u-Eintrag m¨ oglich. 2.3.3 Anpassungsm¨ oglichkeiten Im praktischen Teil der vorliegenden Masterarbeit wurde die Generierung von EMFBaumeditoren genutzt, um diese im Nachhinein manuell anzupassen. EMF bietet an vielen Stellen die M¨ oglichkeit, entweder in die Codegenerierung einzugreifen oder den generierten Quelltext zu manipulieren, um benutzerdefiniertes Editor-Verhalten zu erzielen. Im Folgenden sollen einige Anpassungsm¨ oglichkeiten vorgestellt werden, die bei der Generierung und Implementierung der in Abschnitt 4 vorgestellten Baumeditoren Anwendung gefunden haben. Anpassungen im Generatormodell Das EMF-Generatormodell (auch Genmodel) stellt Einstellungen zur Anpassung des zu generierenden Quelltextes zur Verf¨ ugung. Diese betreffen sowohl den Modellals auch den Edit-Code. W¨ ahrend auf Modellebene etwa die Namen erzeugter Java-Pakete oder die Basisklasse (standardm¨ aßig EObject) gew¨ ahlt werden k¨ onnen, k¨ onnen f¨ ur den UI-unabh¨ angigen Teil folgende Einstellungen f¨ ur die Darstellung jeder strukturellen Eigenschaft des definierten Metamodells getroffen werden: •Children: Anzeige von Referenzzielen als Kind-Elemente im Baum. •Create Child: M¨ oglichkeit zur Erzeugung von Kind-Elementen per Kontextmen¨ u-Eintrag. 24 2 Modellgetriebene Softwareentwicklung im Eclipse-Kontext •Property Category und Property Description: Kategorie bzw. Beschreibung der Eigenschaft im generierten Property-Sheet. •Property Type: Die strukturelle Eigenschaft soll editierbar (Editable), lesbar (Readonly) oder ausgeblendet (None) sein. Label und Icon Nach der Generierung k¨ onnen die von den entsprechenden ItemProviderKlassen definierten Methoden getText() und getImage() ¨ uberschrieben werden, um die Darstellung von Elementen im Baum zu beeinflussen. Command-Framework Die von IEditingDomainItemProvider geerbten Methoden createSetCommand,createCopyCommand und createRemoveCommand k¨ onnen ¨ uberschrieben werden, um beispielsweise benutzerdefinierte Konsistenzpr¨ ufungen vorzunehmen. Nicht ausf¨ uhrbare Commands werden durch die Klasse UnexecutableCommand repr¨ asentiert, um beispielsweise das L¨ oschen oder Kopieren von Elementen zu verhindern. Plugin-Erweiterungspunkte Eclipse stellt einen Plugin-Mechanismus zur Verf¨ ugung, der die Implementierung spezifischer Plugin-Schnittstellen, sog. Extension Points, erlaubt. Auf diese Weise k¨ onnen etwa Aktionen f¨ ur das Kontext-Men¨ u, weitere Modell-Wizards, benutzerdefinierte Ansichten (Views) oder sog. Preference Pages, Workspace-weite Einstellungsmasken, deklarativ innerhalb der Datei plugin.xml definiert werden. 2.4 Das EMF Validation Framework Das EMF Validation Framework [48, Kapitel 18] ist Teil des Eclipse Modeling Framework. Es stellt einen Rahmen zur Validierung von Instanzen Ecore-basierter Modelle zur Verf¨ ugung, die ¨ uber die durch die Struktur des Metamodells definierten Bedingungen wie Typkonformit¨ at oder Multiplizit¨ at hinausgeht. Das Validation Framework unterscheidet zwei Arten von Bedingungen auf EObject-Instanzen: Constraints Bedingungen, die zu einem bestimmten Zeitpunkt zutreffen m¨ ussen, etwa vor oder nach dem Setzen des Wertes eines Attributs. Invarianten Bedingungen, die zu jedem Zeitpunkt zutreffen m¨ ussen. 2.4.1 Definition von Constraints und Invarianten Das Plugin des Validation Framework sieht den Extension Point org.eclipse.emf.validation.constraintProviders zur Definition von Constraints und Invarianten vor. Ein Constraint Provider bezieht sich auf jeweils ein Ecore-Paket, das das Metamodell der zu validierenden Modelle beinhaltet. Die Definition von Constraints und Invarianten erfolgt zun¨ achst in der Datei plugin.xml des Plugins, welches die Modellvalidierung enth¨ alt. Pro Constraint bzw. Invariante sind unter anderem folgende Eigenschaften anzugeben: •Name Ein eindeutiger Bezeichner des Constraints bzw. der Invariante. •Message Eine Fehlermeldung, die dem Benutzer bei Verletzung des Constraints angezeigt werden soll. 25 2 Modellgetriebene Softwareentwicklung im Eclipse-Kontext abgebildeten – unter Umst¨ anden auch mehrwertigen – Wert, im Beispiel d1. Auch die Schreibweise self.dept w¨ are hier m¨ oglich gewesen. 3. Referenzen lassen sich ¨ uber Punkte zu Pfaden konkatenieren. In diesem Fall werden die Kanten dept und employees durchlaufen, um das mehrwertige Referenzziel, die Menge {e1, e3}, zu bestimmen. 4. Werte von Attributen lassen sich auf gleiche Weise wie Referenzziele bestimmen. salary wertet sich in diesem Fall zu dem Wert 3200 aus. 5. Auch zur Berechnung von Attributen k¨ onnen Pfade gebildet werden. Das Einkommen des Abteilungsleiters b1 ist in diesem Beispiel 4200. 6. Der Mengenoperator collect bindet Elemente (in diesem Fall e) einer Menge sequenziell an einen auszuwertenden Ausdruck (e.name) und liefert dessen Ergebnisse wiederum in einer Menge zur¨ uck. Das Ergebnis lautet hier {Mr. Green, Mrs. White}. 7. Der Mengenoperator select bindet wiederum Elemente einer Menge an einen OCLAusdruck, um diejenigen Elemente zu bestimmen, welche dem Ausdruck gen¨ ugen. Werden in einem Pfad mehrere mehrwertige Referenzen durchlaufen, werden diese w¨ ahrend der Auswertung zu einer Menge zusammengefasst (implizite Iteration). Xtext-Unterst¨ utzung f¨ ur OCL Essential OCL eignet sich zur Einbettung von OCL als Anfragesprache f¨ ur dom¨ anenspezifische Sprachen. Hierf¨ ur wird vom Eclipse-OCL-Projekt15 eine Xtext-Grammatik zur Verf¨ ugung gestellt, welche eine Wiederverwendung der QueryKonstrukte und deren Interpretation durch die Eclipse-OCL-Ausf¨ uhrungsumgebung erlaubt. Dieser Ansatz wurde – unter gewissen Einschr¨ ankungen – in der vorliegenden Arbeit verfolgt, um dom¨ anenspezifische Constraints auf Basis von OCL zu formulieren (s. Abschnitt 4.5.2). 2.6.2 Complete OCL Der urspr¨ ungliche Anwendungsbereich von OCL – die Definition von Constraints – wird von der Sprache Complete OCL, die Essential OCL erweitert, abgedeckt. Sie verwendet die von Essential OCL bereitgestellten Konstrukte zur Abfrage des Modellzustands, um die Formulierung von Constraints auf UMLoder Ecore-basierten Modellen zu erlauben. Das in Abschnitt 2.4 vorgestellte EMF Validation Framework bietet beispielsweise eine CompleteOCL-Schnittstelle zur deklarativen Formulierung von Validierungs-Constraints bzw. Invarianten an. Complete OCL erweitert den Sprachumfang von Essential OCL an einigen Stellen. Queries k¨ onnen auf verschiedene Weisen mit einem Kontext-Objekt in Zusammenhang stehen: F¨ ur Operationen k¨ onnen etwa Voroder Nachbedingungen angegeben werden, f¨ ur Klassen k¨ onnen Invarianten definiert werden. Die Werte von abgeleiteten Attributen oder Operationen k¨ onnen ¨ uber OCL-Ausdr¨ ucke – unter der Annahme der Seiteneffektfreiheit – ermittelt werden. Die Syntax von Essential OCL ist f¨ ur die weitere Arbeit nicht relevant. 15http://www.eclipse.org/projects/project.php?id=modeling.mdt.ocl 32 2 Modellgetriebene Softwareentwicklung im Eclipse-Kontext 2.7 Modell-zu-Modell-Transformationen Ein weiterer Bestandteil des Eclipse Modeling Project sind Modell-zu-ModellTransformationen (M2M). Im Eclipse-Umfeld existieren viele M2M-Ans¨ atze, die den gemeinsamen Zweck haben, ein Quellmodell nach einer bestimmten Vorschrift in ein Zielmodell ¨ ubersetzen. In-Place-Transformationen Einen Spezialfall stellen sog. In-Place-Transformationen dar: Anstatt ein neues Modell zu erzeugen, manipulieren sie ein vorhandenes. Anwendungsgebiet ist unter anderem die Modellierung von dynamischem Verhalten — etwa der modellbasierten Beschreibung der Semantik von in Ecore-Klassendiagrammen spezifizierten Operationen. Hierzu kommen h¨ aufig Graphtransformationsregeln bzw. Graphersetzungsregeln zum Einsatz (vgl. ModGraph [13] und EMF Henshin [4]). Diese Art der Modell-zu-Modell-Transformation ist jedoch f¨ ur die weitere Arbeit nicht von Belang. Out-Place-Transformationen Einen allgemeineren Fall stellen Out-PlaceModelltransformationen dar: Hierbei bleibt das Quellmodell w¨ ahrend der Ausf¨ uhrung unver¨ andert, stattdessen wird entsprechend einer Transformationsvorschrift ein Zielmodell neu erzeugt. Exogene Modell-zu-Modell-Transformationen kommen h¨ aufig zur Dokumentenkonvertierung zum Einsatz [37]. Verschiedene M2M-Ans¨ atze stellen dem Anweder beim Formulieren der Transformationsvorschrift ein unterschiedlich hohes Abstraktionsniveau zur Verf¨ ugung. Weiterhin lassen sie sich in imperative und deklarative Ans¨ atze einteilen. 2.7.1 Imperative Ans¨ atze: Java, ATL und QVT Operational Imperative M2M-Ans¨ atze fassen eine Transformationsvorschrift als eine Sequenz von Seiteneffekten zum Aufbau eines Zielmodells auf. Dem Anwender werden hierf¨ ur Konstrukte wie die Erzeugung einer Modellklasse oder die Manipulation von Attributen oder Referenzzielen zur Verf¨ ugung gestellt. Zuweisungen, welche sich auf zwei korrespondierende Elementpaare beziehen, werden meist zu Regeln zusammengefasst, die sich gegenseitig aufrufen k¨ onnen. F¨ ur die Aufrufreihenfolge von Regeln ist der Modellierer selbst verantwortlich. Java-basierte Transformationen Auf niedrigem Abstraktionsniveau befindet sich eine Transformationsbeschreibung in einer g¨ angigen Programmiersprache wie Java: Eine m¨ ogliche Darstellung w¨ are eine Funktion mit der Signatur public Zielmodell transformiere(Quellmodell). Steinberg u. a. [48, Abschnitt 16.4] beschreiben das bedingte Kopieren eines Modells als Sonderfall einer M2M-Transformation: Durch Spezialisierung der Klasse EcoreUtil.Copier kann der Kopiervorgang von Objekten, Attributen und Referenzen selektiv an Bedingungen gekn¨ upft werden. Dieser Ansatz wird in Abschnitt 4.8 zur Ableitung von Produkten aus der Softwareproduktlinie verfolgt. ATL Die von der AtlanMod Group16 entwickelte Modelltransformationssprache ATL [2] ist derzeit der im Eclipse-Umfeld am weitesten verbreitete M2M-Ansatz. Die textuelle Sprache stellt sowohl imperative als auch deklarative Mittel zur Verf¨ ugung. ATL-Transformationen 16http://www.emn.fr/z-info/atlanmod/index.php/Main_Page 33 2 Modellgetriebene Softwareentwicklung im Eclipse-Kontext bestehen aus einer Menge von Regeln, die die Erzeugung von Zielmodell-Elementen aus korrespondierenden Elementen des Quellmodells beschreiben. Zus¨ atzlich k¨ onnen f¨ ur eine Transformation OCL-Hilfsfunktionen definiert werden, um Werte von Attributen oder Referenzen zu ermitteln. Quellcodeausschnitt 2.5 zeigt den Aufbau einer ATL-Transformationsregel. 1lazy rule Class2Class { 2from 3featList : FEATURELIST!FeatureList, 4pimClass : DOMAINMODEL!Class ( 5pimClass.isRequiredBy(featList) 6) 7to 8psmClass : DOMAINMODEL!Class ( 9name <- pimClass.name, 10 attributes <- pimClass.transformedAttributes(featList) 11 ) 12 } Quelltext 2.5: Eine in ATL formulierte Transformationsregel. Quellund Zielmodell werden direkt in der Transformationsvorschrift ausgezeichnet: Der from-Teil definiert den Kontext des Quellmodells. Im to-Teil werden Elemente des Zielmodells erzeugt und deren Attribute mit Hilfe des Zuweisungsoperators (”<-“) initialisiert. Auf der rechten Seite k¨ onnen OCL-Ausdr¨ ucke zur Ermittlung von Attributwerten oder Referenzzielen verwendet werden. QVT Operational Die QVT-Spezifikation (Query View Transformation) [41] wurde im Jahr 2005 als offener Standard zur Beschreibung von Modell-zu-Modell-Transformationen von der OMG verabschiedet. Sie umfasst mit QVT Operational [18] einen imperativen und mit QVT Relations [24] einen deklarativen Dialekt. QVT Operational sieht Sprachkonstrukte f¨ ur die Erzeugung und Manipulation eines Zielmodells aus einer Menge von Quellmodellen vor. Einstiegspunkt einer Transformation ist die Funktion main(). Meist wird in dieser Funktion genau ein Mapping aufgerufen, welches jeweils eine Menge von Manipulationsoperationen zusammenfasst. Mappings k¨ onnen einander referenzieren und OCL-Ausdr¨ ucke enthalten. Obwohl es sich um einen OMG-Standard handelt, findet QVT Operational in der EclipseCommunity derzeit weniger Zuspruch als ATL17. 2.7.2 Deklarative Ans¨ atze: QVT Relations und Tripel-Graph-Grammatiken Deklarative M2M-Ans¨ atze basieren auf der Beschreibung der Korrespondenz von Elementen aus beteiligten Metamodellen [24]. Ebendiese abstrakte Beschreibung erlaubt die Ableitung der eigentlichen Transformation in beliebige Richtungen (Stichwort Bidirektionalit¨ at, [25]) aus einer Korrespondenzbeschreibung. Eine Gemeinsamkeit deklarativer M2M-Ans¨ atze ist die Unterst¨ utzung verschiedener Ausf¨ uhrungsmodi beteiligter Modelldom¨ anen18: 17Von den ersten 50 Beitr¨ agen des Eclipse-Modeling-Forums beziehen sich 19 auf ATL und 9 auf QVT Operational. Stand: 21. Mai 2012, http://www.eclipse.org/forums/index.php/f/23/. 18Als Dom¨ anen werden im M2M-Kontext die jeweiligen Metamodelle von Quellund Zielmodell bezeichnet. 34 2 Modellgetriebene Softwareentwicklung im Eclipse-Kontext Check-Only Ein Modell, das sich in diesem Modus befindet, wird w¨ ahrend der Transformation nicht ver¨ andert. Es wird lediglich gepr¨ uft, ob bestimmte Muster auf Teile des Modells anwendbar sind. Ist dies der Fall, werden Korrespondenzen festgehalten und auf etwaige Entsprechungen in Modellen der anderen Dom¨ ane gepr¨ uft. Enforce Dieser Modus erlaubt die Manipulation eines Modells, um die Korrespondenz mit anderen Modellen sicherzustellen. Eine g¨ angige Strategie ist ”check before enforce“: Zun¨ achst wird wie beim Enforce-Modus auf Anwendbarkeit von Mustern gepr¨ uft. Treffen bestimmte Entsprechungen nicht zu, werden sie erzwungen (vgl. engl. f¨ ur to enforce). QVT Relations Der OMG-Standard QVT Relations [41] nimmt sich der deklarativen Beschreibung von Modell-zu-Modell-Transformationen an und definiert hierf¨ ur eine konkrete textuelle Syntax. Bei einem QVT-Relations-Dokument handelt es sich um eine Beschreibung von Beziehungen zwischen Modell-Elementen beliebig vieler Dom¨ anen. Den Hauptbestandteil stellen sog. Relationen dar, die miteinander korrespondierende Klassen auszeichnen. Innerhalb einer Relation k¨ onnen eine Reihe von Relationsvariablen definiert werden, um korrespondierende strukturelle Eigenschaften verschiedener Dom¨ anen zu identifizieren. Ebenfalls innerhalb einer Relation findet sich ein Domain-Pattern pro beteiligtem Metamodell, gekennzeichnet durch das Schl¨ usselwort domain. Einem Domain-Pattern geht eines der Schl¨ usselw¨ orter checkonly oder enforce voraus, wodurch der Ausf¨ uhrungsmodus pro Modell innerhalb der Relation explizit bestimmt wird. Ein Domain-Pattern kann – m¨ oglicherweise verschachtelte – Pattern-Ausdr¨ ucke enthalten, die Attribute oder Referenzen einer Dom¨ anenklasse mittels OCL-Ausdr¨ ucken mit Relationsvariablen vergleichen. Eine Relation ist f¨ ur eine Menge von Dom¨ anenmodell-Elementen g¨ ultig, wenn alle Pattern-Ausdr¨ ucke von im Check-Only-Modus befindlichen Dom¨ anen als wahr evaluieren sowie die Werte beteiliger Relationsvariablen ¨ ubereinstimmen. Ist dies der Fall, ist die Relation g¨ ultig und die Elemente von Enforce-Dom¨ anen werden entsprechend erzeugt. Innerhalb einer Relation d¨ urfen zus¨ atzlich zwei Arten von Bedingungen formuliert werden: W¨ ahrend der when-Teil in OCL definierte Ausdr¨ ucke lediglich auswertet, und die Relation nicht zustande kommen l¨ asst, sobald einer dieser Ausdr¨ ucke als falsch evaluiert, ist die Semantik des where-Teils restriktiver: Falls dessen Bedingungen nicht gelten, wird die Transformation abgebrochen. Ein Beispiel f¨ ur eine QVT-Relations-Regel findet sich in Quelltext 2.6. 1relation FeatureToFeature { 2 3featureName : String; 4 5checkonly domain absFM af : featuremodel::Feature { 6name = featureName, 7parent = afParent : featuremodel::FeatureGroup{} 8}; 9 10 checkonly domain confFM cf : featuremodel::Feature { 11 name = featureName, 12 parent = cfParent : featuremodel::FeatureGroup{} 13 }; 14 15 enforce domain list fl : featurelist::FeatureList { 16 names = fn : featurelist::FeatureName { 17 name = featureName 35 2 Modellgetriebene Softwareentwicklung im Eclipse-Kontext 18 } 19 }; 20 21 when { 22 cf.state = FeatureState::active; 23 (TopFeatureGroupToTopFeatureGroup(afParent, cfParent, fl) or FeatureGroupToFeatureGroup(afParent, cfParent, fl)); 24 } 25 26 where { 27 af.state->oclIsUndefined() or af.state = FeatureState::incomplete; 28 cf.state = FeatureState::active or cf.state = FeatureState::inactive; 29 } 30 } Quelltext 2.6: Eine Relation aus einer in QVT Relations formulierte Transformationsvorschrift, welche Instanzen einer Modellklasse Feature auf Korrespondenz ¨ uberpr¨ uft. Im when-Teil wird vorausgesetzt, dass ¨ ubergeordnete FeatureGroup-Elemente bereits korrespondieren. Der where-Teil definiert eine notwendige Bedingung f¨ ur Teile des Modells. Tripel-Graph-Grammatiken Tripel-Graph-Grammatiken (TGGs) wurden 1994 von Sch¨ urr [47] als Ansatz zur deklarativen Beschreibung von Modell-zu-Modell-Transformationen vorgestellt. Sie beschreiben den Aufbau von Tripel-Graphen mit Hilfe einer Menge von Produktionsregeln.TGGs operieren grunds¨ atzlich auf drei Dom¨ anen: Neben einem Quellund einem Zielgraphen spielt der Aufbau des Korrespondenzgraphen die Rolle der Anwendung von Relationen in QVT Relations: Er referenziert korrespondierende Elemente. Abbildung 2.10: Produktionsregeln von TGGs erlauben die Beschreibung korrespondierender Elemente zweier Graphen in einer grafischen Notation. 36 2 Modellgetriebene Softwareentwicklung im Eclipse-Kontext Eine Produktionsregel beschreibt, wie Teilgraphen aller drei Dom¨ anen simultan erweitert werden k¨ onnen. Abbildung 2.10 beschreibt exemplarisch den Aufbau einer solchen: Die Notation unterscheidet zwischen Kontextknoten und -kanten, welche in weiß dargestellt werden, und produzierten Konten bzw. Kanten in gr¨ un und mit zus¨ atzlicher Beschriftung ”++“. Kontextelemente definieren ein sog. Pattern: Kommt diese Teilgraphenkonstellation w¨ ahrend der Transformation auf bereits produzierten Elementen zustande, wird die Regel angewendet, wodurch alle produzierten Knoten wiederum gebunden (Check-Only-Modus) oder erzeugt (Enforce-Modus) werden. Aufgrund ihres deklarativen Charakters eignen sich TGGs besonders f¨ ur sog. Synchronisationstransformationen: Hierbei gilt die Annahme, dass bereits eine Basistransformation durch die Anwendung der TGG auf einen Graphen in eine bestimmte Transformationsrichtung stattgefunden hat. Die TGG bleibt auch dann anwendbar, wenn beide beteiligten Modelle seit der Basistransformation manipuliert wurden: Durch die erneute Ausf¨ uhrung werden Teilgraphen gebunden, wenn dies m¨ oglich ist, bzw. neu erzeugt, falls dies n¨ otig ist. Spezielle Algorithmen befassen sich mit der Aufl¨ osung von Konflikten, falls bereits korrespondierende Elemente konkurrierenden ¨ Anderungen unterliegen [22, 26]. Modelltransformationen durch TGGs werden von verschiedenen Werkzeugen unterst¨ utzt, wie etwa Fujaba19 oder dem EMF-basierten TGG Interpreter20. Bei letzterem Ansatz kann kann der Benutzer zur Formulierung von Korrespondenzbedingungen von OCL Gebrauch machen [24]. Außerdem existiert f¨ ur Produktionsregeln ein Vererbungskonzept. Das Werkzeug kam in einem fr¨ uhen Prototypen des Werkzeugs F2DMM zur L¨ osung des Abbildungsproblems zwischen Features und Artefakten eines Multivarianten-Dom¨ anenmodells zum Einsatz (vgl. Abschnitt 7.4.1). 19http://www.fujaba.de 20http://www.cs.uni-paderborn.de/fachgebiete/fachgebiet-softwaretechnik/forschung/projekte/ tgg-interpreter.html 37 3 Vor¨ uberlegungen und Formalisierung der Problemstellung 3 Vor¨ uberlegungen und Formalisierung der Problemstellung Die Disziplin modellgetriebene Entwicklung von Softwareproduktlinien (MDPLE, vgl. engl. Model Driven Product Line Engineering) vereint die in der Einleitung beschriebenen Konzepte der Abstraktion von Softwaresystemen durch Modelle und der organisierten Wiederverwendung durch Softwareproduktlinien (vgl. Abschnitte 1.1 und 1.2). Ein Beitrag der vorliegenden Arbeit liegt in der Ausarbeitung eines neuen, Mapping-basierten Modellierungsansatzes f¨ ur diese Disziplin, um ein entsprechendes Werkzeug zu entwickeln, welches in Abschnitt 4 vorgestellt wird. Zuvor sollen einige Vor¨ uberlegungen angestellt werden, welche zu Entwurfsentscheidungen hinsichtlich des erstellten Werkzeugs beigetragen haben. Außerdem soll in diesem Abschnitt eine Formalisierung der Problemstellung erfolgen, um den vorgestellten Ansatz mit verwandten Ans¨ atzen vergleichen zu k¨ onnen (s. Abschnitt 6). 3.1 Modellierung von Softwaremerkmalen 3.1.1 Identifikation von Merkmalen der Variabilit¨ at Im Alltag begegnen uns an vielen Stellen Ph¨ anomene, die sich unter dem Begriff Variabilit¨ at zusammen fassen lassen. Ein anschauliches Beispiel hierf¨ ur liefert die Automobilindustrie: Jeder PKW aus einer bestimmten Serie besitzt beispielsweise ein Schaltgetriebe. Er kann mit Sommeroder Winterreifen, als Dreioder F¨ unft¨ urer ausgeliefert werden. Zur Sonderausstattung der Serie z¨ ahlen optional elektrische Fensterheber, ein integriertes Navigationssystem oder eine Einparkhilfe. Der Bordcomputer kann je nach Verkaufsregion in unterschiedlichen Sprachen installiert sein. Variabilit¨ at ist immer dann gegeben, wenn sich zwischen ¨ ahnlichen Objekten Gemeinsamkeiten oder Unterschiede erkennen lassen. Pohl u. a. [45, Abschnitt 4.2] unterscheiden im Rahmen der Formalisierung des Variabilit¨ atsbegriffs zwischen •dem Subjekt der Variabilit¨ at:”Ein variierbarer Gegenstand der realen Welt oder eine variierbare Eigenschaft eines Gegenstands“ [45, Definition 4-1], sowie •dem Objekt der Variabilit¨ at:”Eine bestimmte Auspr¨ agung eines Subjekts der Realit¨ at“ [45, Definition 4-2]. Das Subjekt der Realit¨ at ist gem¨ aß dieser Definition als Antwort auf die Frage: ”Was variiert?“ zu identifizieren; verschiedene Objekte der Variabilit¨ at k¨ onnen durch Beantwortung der Frage ”Wie variiert es?“ ermittelt werden. Die Autoren empfehlen zudem zur Identifikation von Softwaremerkmalen die Frage ”Warum variiert etwas?“, um etwaige Dimensionen der Variabilit¨ at eines Softwaremerkmals zu identifizieren: Diese k¨ onnen beispielsweise Gr¨ oße, Farbe, Sprache, oder voneinander abweichende technische Voraussetzungen sein. 3.1.2 Merkmale der Variabilit¨ at Vor der formellen Definition von Variabilit¨ at im Bezug auf Softwareproduktlinien bedarf es der Unterscheidung verschiedener Merkmale der Variabilit¨ at, die sich in der Art und Weise, wie sie sich in Produkten niederschlagen, unterscheiden k¨ onnen [56]: Gemeinsamkeit Ein identifiziertes Softwaremerkmal ist obligatorischer Bestandteil eines jeden Produkts aus der Softwareproduktlinie. 38 3 Vor¨ uberlegungen und Formalisierung der Problemstellung Optionalit¨ at Das Softwaremerkmal kommt in einigen Produkten aus der Produktlinie vor, ist aber nicht obligatorisch. Alternativit¨ at Ein Softwaremerkmal, das ein Subjekt der Realit¨ at beschreibt, kann durch verschiedene, sich gegenseitig ausschließende, Objekte der Realit¨ at repr¨ asentiert werden. In jedem Produkt aus der Produktlinie muss genau eine Alternative aus einer vorgegebenen Menge ausgew¨ ahlt werden. Das Subjekt der Realit¨ at wird auf Modellebene h¨ aufig als Variationspunkt bezeichnet21. Multiplizit¨ at Ein Softwaremerkmal kann sich in einem Produkt in mehreren Instanzen ausdr¨ ucken. In diesem Fall bildet ein Subjekt der Realit¨ at mehrere gleichartige Objekte der Realit¨ at ab. Bezieht man sich zur¨ uck auf das oben genannte Beispiel aus der Automobilindustrie, stellt beispielsweise das Schaltgetriebe ein gemeinsames Merkmal dar. Das integrierte Navigationssystem ist optional, da es nur Bestandteil der Sonderausstattung ist. Die Merkmale Dreibzw. F¨ unft¨ urer stellen verschiedene Alternativen f¨ ur den Variationspunkt ”Anzahl der T¨ uren“ dar und schließen sich gegenseitig aus; eine der beiden Alternativen muss jedoch gew¨ ahlt werden, um ein vollst¨ andiges Produkt zu definieren. Als ein Beispiel f¨ ur Multiplizit¨ at seien die vier jeweils gleichartigen R¨ ader eines PKW zu nennen. 3.1.3 Softwaremerkmale und Abh¨ angigkeiten: Das Featuremodell von Kang Featuremodelle (FM, auch Feature-B¨ aume) sind ein Formalismus zur Erfassung identifizierter Softwaremerkmale und wurden von Kang u. a. [35] im Kontext der Feature-orientierten Dom¨ anenanalyse (FODA) begr¨ undet. Sie dienen der Beschreibung von Softwaremerkmalen (vgl. engl. software features) einer Produktfamilie und deren Variabilit¨ at. Featuremodelle sind baumartig strukturiert. Features stehen in einer der folgenden beiden Beziehungen mit ihrem unmittelbar beinhaltenden Eltern-Feature: UND-Dekomposition Ist das Eltern-Feature in einem Produkt realisiert, so muss auch das Kind-Feature enthalten sein. ODER-Dekomposition H¨ ochstens ein Kind-Feature aus der Menge der mit dem ElternFeature in ODER-Beziehung stehenden Features darf in einem Produkt enthalten sein, in welchem das Eltern-Feature realisiert ist. Entsprechend der obigen Definition l¨ asst sich die Gemeinsamkeit von Softwaremerkmalen durch verschachtelte, UND-dekomponierte Teilb¨ aume realisieren, w¨ ahrend die Alternativit¨ at sowie die Optionalit¨ at mittels ODER-Dekomposition realisiert werden k¨ onnen. Abbildung 3.1 stellt ein Featuremodell dar, welches das PKW-Beispiel in grafischer Notation im Sinne des von Kang u. a. [35] definierten FODA-Modells formalisiert. Die UNDDekomposition wird hier durch eine durchgezogene, die ODER-Dekomposition durch eine gestrichelte Linie dargestellt. 21In [56] und weiterer Literatur wird anstatt Alternativit¨ at h¨ aufig der Terminus Variation verwendet. 39 3 Vor¨ uberlegungen und Formalisierung der Problemstellung PKW Schaltgetriebe Navigation Türen Drei Fünf Abbildung 3.1: Beispiel-Featuremodell in der Notation von Kang u. a. [35]. 3.1.4 Gruppierung und Kardinalit¨ at von Features Das Featuremodell von Kang ist jedoch in seiner Ausdrucksm¨ achtigkeit eingeschr¨ ankt: Festgehaltene Variablit¨ at kann nicht mit einer eindeutigen Semantik verkn¨ upft werden. Pohl u. a. [45] merken an, dass der Unterschied zwischen Alternativit¨ at und Optionalit¨ at im Featuremodell aufgrund der Implikation ”mindestens“ nicht explizit darstellbar ist. Außerdem wird das Merkmal der Multiplizit¨ at nicht ber¨ ucksichtigt. Weiterf¨ uhrende Ans¨ atze versuchen diese Uneindeutigkeiten durch explizite Modellierung von Feature-Gruppen im Featuremodell zu l¨ osen: Wie bereits in Abbildung 3.1 durch einen Verbindungsbogen dargestellt, k¨ onnen ODER-dekomponierte Features zus¨ atzlich gruppiert werden. Aus dieser Gruppe muss genau ein (und nicht mindestens ein) Feature von einem konkreten Produkt realisiert werden (Alternativit¨ at im Sinne des gegenseitigen Ausschlusses). Nicht gruppierte, ODER-dekomponierte Features modellieren entsprechend die Optionalit¨ at und k¨ onnen je nach Produkt entweder realisiert oder nicht realisiert werden. Eine weitere Generalisierung ist die von Czarnecki und Kim [16] hervorgebrachte Kardinalit¨ atsbasierte Featuremodellierung (CBFM, vgl. engl. Cardinality Based Feature Modeling). Sie ber¨ ucksichtigt das zuvor formulierte Variabilit¨ atsmerkmal der Multiplizit¨ at. Ein Feature wird zus¨ atzlich mit einem Kardinalit¨ ats-Intervall versehen, welches die zugelassene Multiplizit¨ at eines Merkmals in einem Produkt definiert. Ist kein Intervall angegeben, so gilt [0,1] f¨ ur optionale, [1,1] f¨ ur obligatorische Features. Abbildung 3.2 bildet das Merkmal ”T¨ uren“ durch ein mehrfach instanziierbares Feature ”T¨ ur“ ab. PKW [1] Schaltgetriebe [1] Navigation [0, 1] Türen [1] Tür [3, 5] Abbildung 3.2: Das Featuremodell aus Abbildung 3.1 unter Ber¨ ucksichtigung der CBFM. 40 3 Vor¨ uberlegungen und Formalisierung der Problemstellung Der von Antkiewicz und Czarnecki [3] ausgearbeitete Ansatz zur Featuremodellierung verallgemeinert die Konzepte der UNDbzw. ODER-Dekomposition durch die M¨ oglichkeit der Angabe eines Selektions-Intervalls, welches die Anzahl der Unterfeatures einer FeatureGruppe einschr¨ ankt, die in konkreten Produkten realisiert werden k¨ onnen22. Die UNDDekomposition l¨ asst sich folglich durch das Selektions-Intervall [g, g] verallgemeinern, wobei gdie Anzahl vorhandener Features einer Gruppe darstellt. Die ODER-Dekomposition einer Gruppe hingegen repr¨ asentiert das Selektions-Intervall [1,1]. 3.1.5 Feature-Konfigurationen: Elimination der Variabilit¨ at W¨ ahrend Featuremodelle die Variabilit¨ at von Softwaremerkmalen der gesamten Produktlinie erfassen, beziehen sich Featurekonfigurationen (FK) auf die Auspr¨ agung der erfassten Merkmale f¨ ur ein spezielles Produkt. Der Prozess des ¨ Ubergangs von einem Featuremodell zur beschreibenden Featurekonfiguration eines Produkts wird ebenfalls als Konfiguration bezeichnet. Eine Featurekonfiguration umfasst die Menge der Entscheidungen, welche zur vollst¨ andigen Elimination der durch das entsprechende Featuremodell definierten Variabilit¨ at f¨ uhren. Diese Elimination findet, bezogen auf die zuvor definierten Arten der Variablit¨ at, wie folgt statt: Gemeinsamkeit Das Merkmal wird in die Featurekonfiguration des zu beschreibenden Produkts aufgenommen. Optionalit¨ at Das Merkmal kann entweder in der FK enthalten sein oder nicht. Alternativit¨ at Die das Produkt beschreibende FK muss genau eines der sich gegenseitig ausschließenden Merkmale enthalten. Multiplizit¨ at Das Merkmal muss in einer festgelegten Anzahl von Instanzen, welche innerhalb des Kardinalit¨ ats-Intervalls liegt, vorkommen. Zus¨ atzlich m¨ ussen alle SelektionsIntervalle eingehalten werden. 3.1.6 Zus¨ atzliche Parametrisierung durch Attribute Zur Modellierung der Alternativit¨ at von Merkmalen eines Produkts existiert in vielen Ans¨ atzen zus¨ atzlich die M¨ oglichkeit, Features mit sog. Feature-Attributen zu parametrisieren. Im Gegensatz zur Alternativen-Darstellung ¨ uber eine ODER-Dekomposition ist der Wertebereich von Attributen nicht beschr¨ ankt, sondern auf endlichen oder nicht-endlichen Mengen definiert (z.B. die Menge aller nat¨ urlichen Zahlen N). Ein Beispiel w¨ are die Modellierung eines Attributs ”H¨ ochstgeschwindigkeit“ des Features ”PKW“ als reelle Zahl. Bei der Erfassung der Variabilit¨ at im Featuremodell wird zun¨ achst nur der Name des Attributs und dessen Wertebereich aufgenommen. Zur Elimination der Variabilit¨ at muss dem definierten Attribut in jeder Featurekonfiguration schließlich ein dem Wertebereich entsprechender Wert zugewiesen werden. 22Die Bezeichnungen beruhen auf der Arbeit von Lukas [39], die wiederum auf dem von Antkiewicz und Czarnecki [3] vorgestellten FeaturePlugin aufbaut. Die Autoren unterscheiden zwischen dem Kenngr¨ oßen feature cardinality und group cardinality, welche den hier verwendeten Begriffen Kardinalit¨ atsbzw. SelektionsIntervall entsprechen. 41 3 Vor¨ uberlegungen und Formalisierung der Problemstellung •Jede gerichtete Beziehung (DirectedRelationship) ist abh¨ angig von deren Referenzziel. An dieser Stelle wird noch keine Annahme dar¨ uber gemacht, in welcher Sprache diese Abh¨ angigkeitsbedingungen formuliert werden. Im Rahmen des praktischen Teils dieser Arbeit wurde die Sprache SDIRL eingef¨ uhrt, welche die Formulierung solcher Bedingungen auf Basis von OCL-Ausdr¨ ucken zul¨ asst (s. Abschnitt 4.5). 3.3.3 Abh¨ angigkeitskonflikte und m¨ ogliche L¨ osungen Der Formalismus der strukturellen Abh¨ angigkeiten wurde eingef¨ uhrt, um die Konsistenz von abgeleiteten Produkten unter den zugrundeliegenden Annahmen sicherzustellen. Wie bereits erw¨ ahnt, kann die Konsistenz von Produkten nicht mehr sichergestellt werden, sobald die aus der Featurekonfiguration abgleiteten Selektionszust¨ ande von Elementen des DM deren strukturellen Abh¨ angigkeiten widersprechen. Ein solcher Widerspruch wird im Folgenden als Abh¨ angigkeitskonflikt bezeichnet. Er tritt genau dann auf, wenn folgende Bedingungen erf¨ ullt sind: 1. Ein DM-Element diist strukturell abh¨ angig von dj. 2. Der Selektionszustand s(di) ist positiv (>). 3. Der Selektionszustand s(dj) ist negativ (⊥). Im Falle einer Containment-Abh¨ angkeit erschließt sich dieser Zusammenhang intuitiv: Ein Nicht-Wurzel-Element kann nur dann existieren, wenn sein ¨ ubergeordneter Container existiert. Zieht man das oben genannte Beispiel der strukturellen Nicht-ContainmentAbh¨ angigkeit bei einer Vererbung in Betracht, kann eine spezialisierte Klasse nur dann vorhanden sein, wenn deren Oberklasse im Produkt existiert. In beiden Fallen k¨ onnte die Wohlgeformtheit eines abgeleiteten Produktes verletzt werden. Um die Wohlgeformtheit hingegen zu garantieren, m¨ ussen Abh¨ angigkeitskonflikte eliminiert werden. Ein in dieser Arbeit ausgearbeitetes Verfahren zur Aufl¨ osung von Konflikten ist die Propagation des Selektionszustandes: Dabei wird der eigentliche, durch die Featurekonfiguration bestimmte, Zustand von betroffenen DM-Elementen k¨ unstlich ¨ uberschrieben, so dass der Konflikt nicht mehr auftritt. Die Propagation kann entweder in die Richtung der Abh¨ angigkeit (in Pfeilrichtung) oder in die Gegenrichtung stattfinden. Entsprechend werden folgende Propagationsstrategien (PS) unterschieden: Vorw¨ arts-Propagation (VP) Der Selektionszustand des positiven, strukturell abh¨ angigen DM-Elements diwird negativiert. R¨ uckw¨ arts-Propagation (RP) Der Selektionszustand des negativen, strukturell ¨ ubergeordneten Elements djwird positiviert. In Abschnitt 4.7.4 wird die Anwendung von Propagationsstrategien zur Aufl¨ osung von Abh¨ angigkeitskonflikten im Kontext des F2DMM-Projekts aus Entwurfssicht behandelt. 48 3 Vor¨ uberlegungen und Formalisierung der Problemstellung 3.3.4 Surrogate: Wiederherstellung der Konsistenz ohne Informationsverlust Die Auswahl der Propagationsstrategie bringt einige Nebeneffekte mit sich: Entscheidet man sich f¨ ur die R¨ uckw¨ artspropagation, werden unter Umst¨ anden DM-Artefakte in Produkte integriert, in denen sie aufgrund bestimmter Restriktionen23 gar nicht integriert werden d¨ urften. Die Vorw¨ arts-Propagation garantiert hingegen, dass nur Elemente, die aufgrund der Abbildung einen positiven Selektionszustand haben, Teil von abgeleiteten Produkten sein k¨ onnen. Hierbei kommt es zwar nicht zur Verletzung von Restriktionen, jedoch ist ein Informationsverlust m¨ oglich: DM-Elemente, die eigentlich in bestimmten Produkten integriert sein sollten, k¨ onnen durch Anwendung der Vorw¨ artspropagation entfallen. Um dem entgegenzuwirken ohne dabei die Wohlgeformtheit von Produkten zu verletzen, k¨ onnen weiterf¨ uhrende Strategien, etwa die in Abschnitt 4.5 vorgestellten Surrogate angewendet werden. Ein durch Anwendung einer Propagationsstrategie nachtr¨ aglich negativ selektiertes DM-Element k¨ onnte in einem bestimmten Kontext durch einen ad¨ aquaten Stellvertreter ersetzt werden. Auch dies sei anhand einiger UML2-bezogener Beispiele erl¨ autert: •Fehlt der R¨ uckgabetyp einer Operation, kann er durch einen kompatiblen Typ, etwa einer Oberklasse, ersetzt werden. •Fehlt in einer mehrstufigen Vererbungshierarchie eine Klasse, kann sie durch die n¨ achsth¨ oher gelegene generalisierte Klasse ersetzt werden. •In Zustandsdiagrammen kann beim Fehlen eines Transitionsendes auf den entsprechenden Endzustand verwiesen werden. Um geeignete Surrogate zu finden, ist Kontextwissen ¨ uber das Modell, in dem der Informationsverlust aufgetreten ist, notwendig. Surrogat-Kandidaten wie in der obigen Auflistung k¨ onnen beispielsweise wiederum mit Hilfe der Anfragesprache OCL ermittelt werden. Dieser Ansatz wird in F2DMM verfolgt: Das Konzept der Surrogate ist hier in die Sprache SDIRL integriert (vgl. Abschnitt 4.5.5). Surrogat-Ausdr¨ ucke sind hierbei fest an Abh¨ angigkeitsbedingungen gekn¨ upft; falls eine Negativierung stattfindet, werden verf¨ ugbare Surrogat-Kandidaten durch Auswertung beigef¨ ugter OCL-Ausdr¨ ucke ermittelt. 3.4 MDPLE als Softwareentwicklungsprozess Wie bei der Herstellung gew¨ ohnlicher Software sind auch am Entwicklungsprozess von Softwareproduktlinien verschiedene Personen mit zugewiesenen Rollen beteiligt, die in aufeinanderfolgenden Phasen definierte Funktionen durchf¨ uhren. Softwareentwicklungsprozesse [6] beinhalten die Definition von Arbeitspaketen, die Rollen, Phasen und Funktionen einander zuordnen. W¨ ahrend in der Softwareentwicklung Prozesse wie der Rational Unified Process (RUP) [38] oder das V-Modell [46] sehr konkrete Arbeitsschritte definieren, setzen Ans¨ atze, welche auf die Entwicklung von Softwareproduktlinien oder die modellgetriebene Softwareentwicklung zugeschnitten sind, h¨ aufig auf einfacheren Prizipien wie dem Wasserfalloder Spiralmodell auf. Nach der Vorstellung einiger aus der Literatur bekannten Prozessmodelle f¨ ur MDPLE wird in diesem Abschnitt ein auf den beschriebenen SPL-Modellierungsansatz zugeschnittener Prozess identifiziert. 23Diese Restriktionen k¨ onnen ¨ okonomischer, rechtlicher oder unternehmenspolitischer Natur sein: Man will beim Maßschneidern eines Produkts nur die n¨ otigen Elemente preisgeben. 49 3 Vor¨ uberlegungen und Formalisierung der Problemstellung 3.4.1 Das Doppelspiralmodell von Gomaa Gomaa [23] setzt sich mit der UML-gest¨ utzten Entwicklung von Softwareproduktlinien (SPL) auseinander und definiert in einem ¨ Uberblickskapitel verschiedene Prozesse zur kontinuierlichen Entwicklung derselben, unter anderem das Doppelspiralmodell (s. Abbildung 3.12). Beide Spiralen stellen je einen unabh¨ angigen, iterativen Prozess dar, der jeweils die aus dem Wasserfallmodell bekannten Phasen (Planung, Analyse, Entwurf und Implementierung) umfasst. Die Ausf¨ uhrung der beiden Spiralen kann alternierend erfolgen: Nach der initialen Definition einer Softwareproduktlinie werden die ersten Produkte abgeleitet, analysiert und die Ergebnisse wiederum zur Weiterentwicklung der gesamten Produktlinie verwertet. Domänenentwicklung Anwendungsentwicklung 1.1 Definition von PL-Zielen, Alternativen und Constraints 1.2 Analyse der Risiken Der Produktlinie 1.3 Entwicklung der Softwareproduktlinie 1.4 Planung des nächsten PL-Zyklus 1.1 Definition von individuellen Produktzielen, Alternativen und Constraints 2.2 Risikoanalyse Produkt 2.3 Entwicklung des Produkts 2.4 Planung des nächsten ProduktZyklus Abbildung 3.12: Das Doppelspiralmodell von Gomaa [23, Abschnitt 3.4.2] beschreibt die Entwicklung von Softwareproduktlinien durch zwei alternierende, inkrementelle Entwicklungsprozesse. 3.4.2 Model Driven Architecture Frankel [20] beschreibt mit Model Driven Architecture (MDA) einen Ansatz, der die in der Einleitung dieser Arbeit beschriebene ansteigende Abstraktion bei der Spezifikation und Implementierung von Softwaresystemen ber¨ ucksichtigt, um die Architektur eines Systems ebenfalls modellgetrieben zu spezifizieren. Ziel ist die vollautomatische Generierung aller Artefakte eines Softwaresystems, inklusive des ausf¨ uhrbaren Quellcodes, aus einer modellbasierten Beschreibung. Durch die schrittweise ¨ Ubersetzung eines abstrakten Modells wird jeweils ein auf der n¨ achstniedrigeren Abstraktionsebene gelegenes Artefakt erzeugt. Dadurch soll zum einen die Produktivit¨ at gesteigert, zum anderen der Wartungsaufwand nach der Auslieferung gesenkt werden. 50 3 Vor¨ uberlegungen und Formalisierung der Problemstellung Plattformunabhängiges Modell (PIM) Plattformspezifisches Modell (PSM) Ausführbares Programm Dokumentationsartefakte Wiederverwendbare Komponenten Domänenentwicklung Anwendungsentwicklung Abbildung 3.13: Der MDA-Ansatz von Frankel [20, Abschnitt 1] beschreibt die modellgetriebene Softwareentwicklung als idealerweise vollautomatisierten Prozess. MDA beschreibt die Transformation vom beschreibenden Architekturmodell zum ausf¨ uhrbaren Programm in zwei Schritten: Zun¨ achst erfolgt die Transformation eines plattformunabh¨ angigen Modells (PIM), welches von den Spezifika von Zielsprache und -Plattform abstrahiert, in ein plattformspezifisches Modell (PSM), welches ebendiese Aspekte ber¨ ucksichtigt. Das PIM wird h¨ aufig zur Generierung von Dokumentationsartefakten, etwa der Architekturbeschreibung eines Systems, herangezogen. Der Schritt vom PSM zum ausf¨ uhrbaren Programm erfolgt zun¨ achst durch eine Transformation in die Zielsprache. Im nicht-idealisierten Prozess wird der generierte Quelltext manuell mit plattformspezifischen Fragmenten angereichert, um die Funktionalit¨ at des Zielsystems zu komplettieren. 3.4.3 Referenzprozess der Softwareproduktlinienentwicklung Der im Rahmen des Vorg¨ angerprojektes MODPL [10] definierte MDPLE-Prozess verfeinert den erstmals von Pohl u. a. [45] formalisierten Referenzprozess zur Softwareproduktlinienentwicklung hinsichtlich der Integration des modellgetriebenen Aspekts. Pohl unterscheidet zwischen der Dom¨ anenentwicklung, welche sich auf die komplette Produktfamilie bezieht, und der Anwendungsentwicklung, die die Implementierung einzelner Produkte beschreibt. Jedem der beiden – wiederum separat zu betrachtenden – Entwicklungsprozesse liegen die Prozessschritte Analyse und Entwurf, zugrunde (s. Abbildung 3.14). Ergebnis der Dom¨ anenanalyse ist das Featuremodell (FM), in dem die Merkmale, welche innerhalb der Dom¨ ane identifiziert wurden, festgehalten werden (vgl. Abschnitt 3.1). Das Pendant auf der Seite der Anwendungsentwicklung sind die Featurekonfigurationen (FKs), die die Merkmale je Produkt aus der Softwarefamilie beschreiben. Die Erzeugung dieser beiden Artefakte wird im Folgenden unter dem Aspekt Featuremodellierung zusammengefasst. Auf der darunterliegenden Ebene werden jeweils Artefakte der Entwicklung beschrieben: Das Multivarianten-Dom¨ anenmodell beschreibt Software, welche in allen Produkten vorkommt, w¨ ahrend das konfigurierte Dom¨ anenmodell ein Produkt der Softwarefamilie repr¨ asentiert. Die Abbildung verdeutlicht das Hauptziel von MDPLE: Die automatisierte Erzeugung des konfigurierten Dom¨ anenmodells durch einen Ableitungsschritt, dem das MultivariantenDom¨ anenmodell und die das Produkt beschreibende Featurekonfiguration zugrunde liegen. 51 3 Vor¨ uberlegungen und Formalisierung der Problemstellung Domänenentwicklung Anwendungsentwicklung Domäne Featuremodell MultivariantenDomänenmodell Analyse Entwicklung Anforderungen Konfigurierung Featurekonfiguration Ableitung Konfiguriertes Domänenmodell Abbildung 3.14: Von Buchmann [10] vorgeschlagener Prozess zur Entwicklung von modellgetriebenen Softwareproduktlinien. 3.4.4 Vorgeschlagener MDPLE-Prozess Diese Arbeit befasst sich zum Großteil mit der Abbildung (vgl. engl. mapping) von Features auf ihre entsprechenden Elemente des Multivarianten-Dom¨ anenmodells. In den folgenden Abschnitten wird zu diesem Zweck das Mapping-Modell als zentrale Abbildungsstruktur eingef¨ uhrt. Das Mapping-Modell stellt die Korrektheit der Abbildung bez¨ uglich Abh¨ angigkeitsbedingungen (vgl. Abschnitt 3.3) mit Hilfe eines sog. Konsistenzmodells sicher, welches sich wiederum auf die Sprache der Dom¨ ane bezieht: Verwandte MDPLE-Ans¨ atze setzen hierbei h¨ aufig UML als Modellierungssprache voraus, sodass dieser Schritt entf¨ allt (s. Domänenentwicklung Anwendungsentwicklung Domäne Featuremodell Analyse Entwicklung Anforderungen Konfigurierung Featurekonfiguration Ableitung Konfiguriertes Domänenmodell MultivariantenDomänenmodell MappingModell KonsistenzModell DomänenSprache Analyse Ableitung Abbildung 3.15: Ein im Kontext dieser Arbeit vorgeschlagenes Prozessmodell zur Entwicklung von modellgetriebenen Softwareproduktlinien. 52 3 Vor¨ uberlegungen und Formalisierung der Problemstellung Abschnitt 6). Das Konsistenzmodell entsteht durch Analyse dieser Modellsprache durch einen DSL-Experten (vgl. Abbildung 3.15). Die Schritte Analyse der Dom¨ anensprache,Konsistenzmodell und Mapping-Modell werden der Dom¨ anenentwicklung zugeschrieben, da sie sich ebenfalls durch ihre Allgemeing¨ ultigkeit bez¨ uglich der Softwarefamilie auszeichnen und nicht f¨ ur jede FK neu erfolgen m¨ ussen. Die Ableitung von Produkten erfolgt schließlich im Rahmen der Anwendungsentwicklung. 3.4.5 Die mathematisch-formelle Sicht: Problemund L¨ osungsraum Unter den Begriff Featuremodellierung f¨ allt, wie oben beschrieben, die Erzeugung von Featuremodell und -konfigurationen. Betrachtet man die Ableitung von Produkten als mathematisches Abbildungsproblem, definiert die Featuremodellierung einen Problemraum [15]: Hier werden lediglich abzubildende Softwaremerkmale definiert. Eine Featurekonfiguration FC k ist genau dann konform zu einem Featuremodell FM k, wenn sie jedem in ihm definierten Softwaremerkmal fieinen Selektionszustand s(fi)∈ {>,⊥} zuweisen kann: ∀fi∈FCk⇒s(fi)∈ {>,⊥} ∧ fi∈FM k Die L¨ osung des definierten Abbildungsproblems ergibt sich – um in der mathematischformellen Sichtweise zu bleiben – durch Ableitung des konfigurierten Dom¨ anenmodells aus der Featurekonfiguration. Das Multivariantensowie das konfigurierte Dom¨ anenmodell sind demnach Elemente des L¨ osungsraums. Im vorgeschlagenen MDPLE-Prozessmodell hat das Mapping-Modell die Rolle einer Abbildungsvorschrift: MM (FM ) : FCk⇒Pk,FCkkonform zu FM Eine durch ein Mapping-Modell definierte Abbildungsvorschrift MM (FM ) kann folglich jede Featurekonfiguration FCk, die konform zum mit dem Mapping-Modell verkn¨ upften Featuremodell ist, auf ein Produkt Pkabbilden. Die Abbildung selbst beschreibt den ¨ Ubergang zwischen Problemund L¨ osungsraum [30] und ist Gegenstand des nachfolgenden Abschnitts. 53 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Dieser Abschnitt baut auf den zuvor vermittelten Grundlagen der modellgetriebenen Softwareentwicklung mit Eclipse (vgl. Abschnitt 2) sowie den Vor¨ uberlegungen aus Abschnitt 3 auf und stellt mit F2DMM einen Editor zur modellgetriebenen Entwicklung von Softwareproduktlinien auf Basis eines Mapping-Modells vor. Die Beschreibung erfolgt alternierend aus Konzeptund aus Anwendersicht. Der nachfolgende Abschnitt 5 besch¨ aftigt sich schließlich mit der Anwendung des Werkzeugs auf konstruierte Problemstellungen. 4.1 ¨ Ubersicht: Modelle und Werkzeuge Wie bereits erw¨ ahnt, liegt der praktische Beitrag dieser Arbeit in der Erstellung eines Werkzeuges, welches die Abbildung von Features auf Elemente eines MultivariantenDom¨ anenmodells unterst¨ utzt. Grundlage f¨ ur den Editor ist ein Mapping-Metamodell, welches erlaubt, ein beliebiges Ecore-basiertes Dom¨ anenmodell mit zus¨ atzlichen Mapping-spezifischen Informationen wie Feature-Ausdr¨ ucken, zu versehen. Die folgenden Ausf¨ uhrungen beziehen sich auf die in Abbildung 4.1 beschriebene Modellund Werkzeuglandschaft. Das entwickelte Rahmenwerk F2DMM (Feature To Domain Mapping Model) ist Bestandteil des lehrstuhlweiten Projekts FAMILE (Features And Mappings In Lucid Evolution). In den nachfolgenden Abschnitten wird zun¨ achst auf die Modelle und Werkzeuge zur Featuremodellierung eingegangen (s. Abschnitt 4.2), die im Rahmen eines kleinen Master-Projekts implementiert wurden und ausdr¨ ucklich kein Beitrag dieser Arbeit sind. Softwaremerkmale und deren Auspr¨ agung werden in einem Featuremodell und mehreren Featurekonfigurationen definiert, die jeweils Instanz desselben Metamodells sind. Gegenstand der vorliegenden Arbeit war jedoch die Ausarbeitung von Mechanismen zum Erhalt der Synchronit¨ at von FM und FK in einem entsprechenden Modul. Im darauffolgenden Abschnitt 4.3 werden die dem F2DMM-Metamodell zugrundeliegenden Entwurfsentscheidungen erl¨ autert. Die wesentliche Komponente stellen Mappings dar, die Elemente des referenzierten Dom¨ anenmodells mit Feature-Ausdr¨ ucken (s. Abschnitt 4.4) versehen, welche in ihrer textuellen Repr¨ asentation von der FEL-Grammatik (Feature Expression Language) definiert werden. Durch sie wird die Manifestation von Variabilit¨ at im Dom¨ anenmodell durch geeignete Sprachkonstrukte ber¨ ucksichtigt. Mappings k¨ onnen sich auch auf Elemente außerhalb der Dom¨ anenmodell-Ressource beziehen. In diesem Fall spricht man von Alternativen-Mappings (s. Abschnitt 4.6). Sie tragen zur Unterst¨ utzung der Agilit¨ at bei und erlauben die Definition von Variationspunkten. Optional kann ein SDIRL-Dokument (Structural Dependency Identification and Repair Language, s. Abschnitt 4.5) das Dom¨ anen-Metamodell um strukturelle Abh¨ angigkeitsbedingungen (vgl. Abschnitt 3.3.2) erg¨ anzen. F¨ ur das Bearbeiten dieser Dokumente ist ein eigener textueller Editor vorgesehen, der Teile des vom Eclipse Modeling Projekt bereitgestellten OCL-Texteditors und des entsprechenden Metamodells wiederverwendet. Aus einem konsistenten Mapping-Modell k¨ onnen unter Angabe jeweiliger Featurekonfigurationen Produkte (auch konfigurierte Dom¨ anenmodelle) abgeleitet werden (s. Abschnitt 4.8). Voraussetzung hierf¨ ur ist die Synchronit¨ at des Mappings mit dem zugrundeliegenden Multivarianten-DM, welche ebenfalls durch ein entsprechendes Modul sichergestellt wird (vgl. Abschnitt 4.9). Schließlich beleuchtet Abschnitt 4.10 einige zus¨ atzliche Funktionen des F2DMM-Editors aus Anwendersicht. 54 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien SDIRLTexteditor Instanz von Alternatives DomänenModell EcoreMetamodell FeatureMetamodell Featuremodell Featurekonfiguration „Featuremodel“- Editor „Featureconf“- Editor FM/FKSynchronisationsModul Instanz von Wird abgeleitet aus bearbeitet DomänenMetamodell KernDomänenModell F2DMMMetamodell Instanz von FELMetamodell SDIRLMetamodell Feature Attribut Feature Feature Attribut Feature Feature beobachtet Änderungen F2D-Mapping-Modell Element Element Element Element Mapping Mapping Mapping Mapping FeatureAusdruck bearbeitet korrespondiert korrespondiert korrespondiert Strukturelle Abhängigkeiten und Reparaturoperationen OCLMetamodell F2D-MappingEditor FeatureAusdruck bearbeitet bearbeitet OCLTexteditor bearbeitet FELTexteditor OCLAusdrücke FeatureAusdruck Feature korrespondiert Produkt leitet ab beobachtet Änderungen F2DMM/DMSynchronisationsModul bringt Änderungen ein bringt Änderungen ein Abbildung 4.1: ¨ Uberblick ¨ uber die Modelle und Werkzeuge im Kontext des FAMILE-Projekts. 55 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien 4.2 Featuremodellierung Wie bereits in Abschnitt 3.1 erw¨ ahnt, haben sich Featuremodelle und -konfigurationen [35] zur formellen Beschreibung von Softwaremerkmalen etabliert. Im Kontext des FAMILE-Projekts wurde in einem kleinen Master-Projekt [39] ein Feature-Metamodell sowie Editoren f¨ ur Featuremodell und Featurekonfiguration entwickelt. Im Rahmen der vorliegenden Masterarbeit wurden keine weiteren ¨ Anderungen am Metamodell und an den Editoren vorgenommen. Eine Ausnahme stellt die Integration des Synchronisationsmoduls in den FeaturekonfigurationsEditor dar, welche in Abschnitt 4.2.4 behandelt wird. Aus Gr¨ unden der Dokumentation und zur besseren Nachvollziehbarkeit der nachfolgenden Ausf¨ uhrungen werden zun¨ achst das Feature-Metamodell, die Editoren sowie der Validierungsmechanismus vorgestellt. 4.2.1 Das Feature-Metamodell Featuremodelle und -konfigurationen sind Instanzen eines gemeinsamen, EMF-basierten Metamodells (vgl. Ecore-Klassendiagramm in Abbildung 4.2). Die Verkn¨ upfung zwischen FK und FM entsteht durch das Setzen der Referenz definingFeatureModel in der Konfiguration. Abbildung 4.2: Das Feature-Metamodell unterscheidet zwischen atomaren Features (repr¨ asentiert durch die Modellklasse AtomicFeature) und Feature-Gruppen (FeatureGroup), welche eine baumartige Verschachtelung nach dem Entwurfsmuster Composite [21, Kapitel 4.3] erlauben. Die Wurzel eines Featuremodells bzw. einer -konfiguration sind durch die Ableitung Root gekennzeichnet. Features k¨ onnen durch Feature-Attribute parametrisiert werden. Jedes Feature bekommt vom Modellierer einen Selektionszustand (SZ) zugewiesen, repr¨ asentiert durch den Enumerationstyp State. W¨ ahrend im Featuremodell noch keine Auswahl erfolgt (alle Features haben den SZ pending), muss im Sinne der in Abschnitt 3.1.5 geforderten Elimination der Variabilit¨ at innerhalb einer g¨ ultigen Featurekonfiguration jedes Feature entweder selected oder unselected sein. 56 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Identit¨ at von Features Bei der Erzeugung eines Features wird eine eindeutige ID generiert und diesem zugewiesen. W¨ ahrend im Featuremodell eine ID genau einmal existieren darf, bekommen im Falle eines mehrfach instanziierbaren Features in einer entsprechenden Featurekonfiguration alle Instanzen dieselbe ID zugewiesen. Die Attribute minCardinality und maxCardinality legen Unterbzw. Obergrenzen f¨ ur die Anzahl der erlaubten Instanzen eines Features in einer Konfiguration fest. Im Gegensatz zu den IDs m¨ ussen die Namen von Features (Attribut name) nicht global eindeutig sein. Lokale und globale Optionalit¨ at Das boolesche Attribut kernel gibt an, ob ein modelliertes Feature Bestandteil des Kernels, also der Menge der Gemeinsamkeiten aller Produkte der Produktlinie ist. In einer g¨ ultigen Featurekonfiguration m¨ ussen folglich alle Instanzen von Features, f¨ ur die die Bedingung kernel == true gilt, selektiert sein. Das Attribut required hingegen bezieht sich auf die lokale Abh¨ angigkeit eines Features von seiner enthaltenden Feature-Gruppe (Variabilit¨ atsmerkmal Optionalit¨ at, vgl. Abschnitt 3.1.2). Das abgeleitete Attribut optional verh¨ alt sich invers zu required. Feature-Gruppen, Kardinalit¨ at und Selektion Der im vorliegenden Feature-Metamodell gew¨ ahlte Ansatz unterst¨ utzt Cardinality-Based Feature Modeling (CBFM, Abschnitt 3.1.3): Die Attribute minSelect und maxSelect geben eine Unterbzw. Obergrenze f¨ ur die erlaubte Anzahl selektierter Unterfeatures einer Gruppe an, bezogen auf alle Instanzen innerhalb einer Featurekonfiguration. Als Obergrenze ist außerdem die Konstante GROUP SIZE zul¨ assig, welche die aktuelle Anzahl der Unterfeatures je Konfiguration repr¨ asentiert. Die tats¨ achliche Kardinalit¨ at einer Feature-Gruppe ergibt sich in einer Featurekonfiguration jeweils lokal durch die Anzahl der Instanzen pro Unterfeature. Eine Konfiguration ist g¨ ultig, solange sich diese Gr¨ oße im durch minCardinality und maxCardinality definierten Intervall befindet. Beziehungen zwischen Features: requires und excludes Bisher wurden Featuremodell und -konfiguration als verschachtelte, baumartige Struktur verstanden: Features stehen ¨ uber die parentbzw. children-Referenz miteinander in Beziehung. Das vorliegende FeatureMetamodell erlaubt die Angabe weiterer, nicht existenzabh¨ angiger Beziehungen: Features k¨ onnen sich entweder gegenseitig bedingen (modelliert ¨ uber die requires-Kante) oder ausschließen (excludes) [28]. Die umgekehrte Beziehungsrichtung (eOpposite) wird durch die Referenzen requiredBy bzw. excludedBy ausgedr¨ uckt. 4.2.2 Validierung in Featuremodell und -konfiguration Um die Wohlgeformtheit von Featuremodell und -konfiguration sicherzustellen, wurde, ebenfalls im Vorfeld des FAMILE-Projekts, das EMF Validation Framework (s. Abschnitt 2.4) unter Zuhilfenahme geeigneter Constraints in die Editoren eingebunden. Auch Heidenreich [28] beschreibt im Kontext des FeatureMapper-Projekts Bedingungen f¨ ur die Wohlgeformtheit verschiedener Komponenten von Softwareproduktlinien (s. Abschnitt 6.4.1), u.a. Featuremodellen und -konfigurationen. Tabelle 4.1 ordnet die Constraint-Klassen f¨ ur das vorliegende Metamodell den von Heidenreich definierten Bedingungen zu. Letztere sind den Bereichen Featuremodell (FM) und Featurekonfiguration (VM, vgl. engl. variant model) zugeordnet. 57 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien gen. 4.3.2 Der Mapping-Baum: Strukturelle Rekonstruktion des Dom¨ anenmodells Die vereinfachte Illustration in Abbildung 4.6 definiert bereits die grundlegende Struktur eines Mapping-Modells: Der Containment-Baum des Dom¨ anenmodells wird rekonstruiert. W¨ ahrend ein Containment-Mapping sich stets auf eine Instanz von EObject, n¨ amlich das abgebildete Dom¨ anenmodell-Element, bezieht (s. Referenz mappedObject), wird bei AttributMappings die String-Serialisierung des entsprechenden elementaren Datentypen hinterlegt. Die gestrichelten, von Attribut-Mappings ausgehenden Kanten in Abbildung 4.8 stellen also keine tats¨ achliche Referenz dar. ¨ Ahnlich verhalten sich Referenz-Mappings, welche sich auf Nicht-Containment-Referenzen aus dem Dom¨ anenmodell beziehen und somit das angewandte Auftreten von an anderer Stelle deklarierten Objekten realisieren. Anstatt auf das referenzierte Dom¨ anenmodell-Element zu verweisen, bezieht sich ein Referenz-Mapping auf ein Containment-Mapping, welches das deklarierte Objekt abbildet (referencedMapping). Im Beispiel in Abbildung 4.8 ist nicht etwa das Referenzziel c1 der Referenz type mit dem Referenz-Mapping rm1 assoziiert, sondern das Containment-Mapping cm2, welches sich auf c1 bezieht. Diese zus¨ atzliche Abstraktion ist zur Vorberechnung m¨ oglicher Konsistenzverletzungen (s. Abschnitt 4.7.1) vonn¨ oten. p1 : uml.Package c1 : uml.Class name = „Class1" cm1 : ContainmentMapping cm2 : ContainmentMapping am1 : AttributeMapping cm3 : ContainmentMapping cm4: ContainmentMapping rm1 : ReferenceMapping c2 : uml.Class p1 : uml.Property name = „prop1" am1 : AttributeMapping type „Class1" „prop1" Abbildung 4.7: Beispiel-Mapping (rechts) f¨ ur ein vorhandenes Dom¨ anenmodell (links). Die Struktur des Mapping-Modells ist durch den aufspannenden Containment-Baum des Dom¨ anenmodells definiert. Im Gegensatz zu Attributund Referenz-Mappings erlauben Containment-Mappings eine beliebige Verschachtelung (s. Referenz containedMappings in Abbildung 4.6). 64 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Abbildung 4.8: Ausschnitt des tats¨ achlichen F2DMM-Metamodells, der dem in der vereinfachten Darstellung in Abbildung 4.6 angedeuteten, nach dem Composite-Muster [21, Kapitel 4.3] entworfenen Teilmodell entspricht. 65 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien 4.3.3 Kernund Alternativen-Mappings Das tats¨ achliche F2DMM-Metamodell unterscheidet neben der strukturellen Dimension (Containment-, Attributbzw. Referenz-Mappings) zus¨ atzlich nach Kernund Alternativen-Mappings. Kern-Mappings beziehen sich auf das referenzierte MultivariantenDom¨ anenmodell, indem dessen Struktur wie in Abbildung 4.7 angedeutet nachgebildet wird. Die Wahrung der strukturellen Synchronit¨ at mit dem Dom¨ anenmodell ist Aufgabe des DM/MM-Synchronisationsmoduls, welches in Abschnitt 4.9.1 vorgestellt wird. Alternativen-Mappings erlauben die Erweiterung des Dom¨ anenmodells, etwa um Abbildungen zu realisieren, die nicht durch Kern-Mappings dargestellt werden k¨ onnen (s. Abschnitt 4.6.2). Im Gegensatz zu Kern-Mappings unterliegen Alternativen-Mappings keiner automatischen Synchronisierung und werden stattdessen vom Modellierer manuell gepflegt. Durch Kombination der beiden genannten Dimensionen ergeben sich schließlich sechs konkrete Mapping-Klassen: •Kern-Containment-Mapping, implementiert durch CoreContainmentMapping, •Kern-Attribut-Mapping (CoreAttributeMapping), •Kern-Referenz-Mapping (CoreReferenceMapping), •Alternativen-Containment-Mapping (AlternativeContainmentMapping), •Alternativen-Attribut-Mapping (AlternativeAttributeMapping), •Alternativen-Referenz-Mapping (AlternativeReferenceMapping). Abbildung 4.8 stellt einen Ausschnitt des tats¨ achlichen F2DMM-Metamodells dar. Mappings sind in dieser Darstellung tabellarisch nach den Dimensionen Struktur (Containment, Referenz, Attribut; in gr¨ un) bzw. Zugeh¨ origkeit (Kern, Alternative; in rot) angeordnet. Zus¨ atzlich existiert f¨ ur jede der sechs Mapping-Arten ein Container-Interface (in grau dargestellt) als weiterer Abstraktionsschritt. Die abstrakte Klasse ContainmentMapping implementiert alle sechs Container-Interfaces, um eine rekursive Verschachtelung zu erm¨ oglichen. Das Mapping-Modell selbst (F2DMappingModel) ist von CoreContainmentMappingContainer abgeleitet und repr¨ asentiert die Wurzel des Mapping-Baumes. Alle Mapping-Klassen erben indirekt von der abstrakten Basisklasse Annotatable, die Gemeinsamkeiten von Mappings, welche mit Feature-Ausdr¨ ucken versehen werden k¨ onnen, ber¨ ucksichtigt. Sie wird in Abschnitt 4.7.2 detailliert behandelt. Es sei jedoch vorweggenommen, dass sich jede Instanz von Annotatable zu jedem Zeitpunkt in einem von acht m¨ oglichen Selektionszust¨ anden (SZ) befindet, welche Gegenstand des n¨ achsten Unterabschnitts sind. 4.3.4 Selektionszust¨ ande Instanzen von Annotatable wird nach Auswertung annotierter Feature-Ausdr¨ ucke (s. Abschnitt 4.4) ein SZ zugewiesen, welcher jeweils als Literal des Aufz¨ ahlungstypen SelectionState (vgl. Abbildung 4.9) modelliert ist. Nach der Auswertung von Feature-Ausdr¨ ucken steht der initialSelectionState fest. Er kann lediglich die Werte active,inactive,incomplete oder corrupted annehmen (nicht annotierte Elemente erhalten zun¨ achst den SZ incomplete; fehlerhafte Ausdr¨ ucke werden als corrupted markiert). Um die Konsistenz der Annotationen sicherzustellen, wird im Mapping-Modell 66 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Abbildung 4.9: Darstellung der relevanten Elemente der Metaklasse Annotatable sowie des Enumerationstypen SelectionState als Ecore-Klassendiagramm. das Konzept der Propagation von Selektionszust¨ anden implementiert (vgl. Abschnitt 3.3.3). Hierdurch k¨ onnen die propagatedSelectionStates weitere Werte, n¨ amlich suppressed oder enforced, annehmen. Durch Ausschlusskonflikte bzw. Surrogate k¨ onnen diese erneut revidiert werden und die endg¨ ultigen Zust¨ ande surrogated bzw. overruled annehmen. Die Mechanismen zur Bestimmung dieser Zust¨ ande werden in Abschnitt 4.7.5 erl¨ autert. Abbildung 4.10 fasst m¨ ogliche SZ und deren grafische Notation, die auch im F2DMM-Editor verwendet wird, zusammen. inactive: Mit einem FELAusdruck versehen, der in der aktuellen FK negativ ist active: Mit einem FELAusdruck versehen, der in der aktuellen FK positiv ist incomplete: Mapping-Element, welches weder annotiert, noch von einer Propagation betroffen ist suppressed: Durch Propagation künstlich negativiert enforced: Durch Propagation künstlich positiviert surrogated: Aufgrund der Existenz von Surrogaten künstlich positiviert corrupted: Mit einem fehlerhaften FEL-Ausdruck versehen overruled: Aufgrund eines Ausschlusskonfliktes künstlich negativiert Abbildung 4.10: M¨ ogliche Selektionszust¨ ande eines Mappings im F2DMM-Metamodell und deren Bedeutung. 67 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien 4.4 FEL: Feature-Ausdr¨ ucke und deren Auswertung Die textuelle Anfragesprache Feature Expression Language (FEL) dient innerhalb des F2DMM-Werkzeugs der Formulierung von Feature-Ausdr¨ ucken, welche als Annotationen von Mappings die Verbindung zum Featuremodell sowie zu einer eventuell geladenen Featurekonfiguration herstellen. Neben Feature-Ausdr¨ ucken definiert die Sprache auch AttributAusdr¨ ucke, die Anfragen auf die Werte von Feature-Attributen einer Featurekonfiguration erlauben. 4.4.1 Elementare Feature-Ausdr¨ ucke: Qualifizierende Namen, Index-Bezug und boolesche Verkn¨ upfungen Feature-Ausdr¨ ucke beziehen sich auf die Selektionszust¨ ande von Features unter Ber¨ ucksichtigung der aktuellen Featurekonfiguration und bekommen nach ihrer Auswertung selbst einen SZ zugewiesen. M¨ ogliche Selektionszust¨ ande f¨ ur Feature-Ausdr¨ ucke sind incomplete,inactive,active und corrupted (vgl. Abbildung 4.10). Syntaktisch ung¨ ultige FeatureAusdr¨ ucke haben stets den Selektionszustand corrupted. In den folgenden Abs¨ atzen wird die Syntax von Feature-Ausdr¨ ucken anhand von Beispielen beschrieben. Feature-Referenzen Eine M¨ oglichkeit, Bezug zu Selektionszust¨ anden von Features herzustellen, ist das Referenzieren des Features selbst. Eine Feature-Referenz ist ein FeatureAusdruck, der den Selektionszustand des durch ihn referenzierten Features in der aktuell geladenen FK annimmt. Ist keine FK geladen, hat der Ausdruck den Wert incomplete. Eine Feature-Referenz besteht in ihrer konkreten textuellen Syntax aus dem FeatureNamen selbst. Enth¨ alt der Feature-Name Sonderoder Leerzeichen, muss er in doppelte Hochkommata (") eingeschlossen werden. Nachfolgendes Quelltextfragment enth¨ alt drei FeatureReferenzen, die sich auf das Modell aus Abbildung 4.3 auf Seite 59 beziehen: 1VPN 2"Rolling Shutters Control" 3Cloud In der geladenen Feature-Konfiguration w¨ urde der erste Ausdruck den Selektionszustand active zur¨ uckgeben, da das gleichnamige Feature selektiert ist. Der zweite Ausdruck evauliert dagegen zu inactive. Da im Featuremodell kein Merkmal mit dem Namen ”Cloud“ vorhanden ist, w¨ are der dritte Ausdruck ung¨ ultig (corrupted). Qualifizierende Namen In Abschnitt 4.2.1 wurde bereits erw¨ ahnt, dass Feature-Namen nicht global eindeutig sind. Falls ein Feature mit demselben Namen in einem Modell mehrfach vorkommen w¨ urde, k¨ onnte die Referenz nicht mehr eindeutig aufgel¨ ost werden. Features ¨ uber deren eindeutig vergebene IDs zu referenzieren, k¨ onnte das Problem l¨ osen, ist aber aus Anwendersicht wenig praktikabel. Stattdessen erlaubt FEL das Aufl¨ osen von Mehrdeutigkeiten bei Feature-Namen ¨ uber den aus Programmiersprachen bekannten Mechanismus des qualifizierenden Namens [51, Kapitel 3.6.1]: Einem Feature wird der Name der beinhaltenden Feature-Gruppe vorangestellt, getrennt durch einen Punkt. Dies l¨ asst sich bis zur Wurzel des Featuremodells fortsetzen. Beispiele f¨ ur qualifizierende Feature-Namen sind: 1"Secure Connection".VPN 2Peripherals."Air Condition Control" 3"Home Automation System"."Identification Mechanism" 68 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Indexund Wildcard-Zugriff Features mit Multiplizit¨ at gr¨ oßer eins k¨ onnen in einer Featurekonfiguration in mehreren Instanzen vorkommen. ¨ Ahnlich wie beim vorhergehenden Problem kann es dadurch zu Mehrdeutigkeiten kommen: Der Ausdruck "Add-on Package"."Mobile App" k¨ onnte sich im Beispiel auf eine der maximal drei Instanzen des entsprechenden Features beziehen24. Um diesem Problem zuvorzukommen, verlangt FEL nach einer Referenz auf ein mehrwertiges Feature die Angabe eines Index in eckigen Klammern. Der Index bezieht sich auf die Position des Features innerhalb seiner beinhaltenden Feature-Gruppe in der FK; die Z¨ ahlung wird bei null begonnen. Die Anzahl der Instanzen eines Features ist m¨ oglicherweise je nach Featurekonfiguration unterschiedlich. Außerdem mag eine boolesche Verkn¨ upfung unterschiedlicher Instanzen, die sich auf dasselbe Feature aus dem Featuremodell beziehen, umst¨ andlich sein. Aus diesen Gr¨ unden ist zur Angabe eines Index zus¨ atzlich die Wildcard (*) erlaubt: Sie verkn¨ upft alle in der Featurekonfiguration vorkommenden Instanzen des referenzierten Features ¨ uber eine ODERKonjunktion und bezieht sich somit auf das Subjekt der Variabilit¨ at (vgl. Abschnitt 3.1.2). Folgende Feature-Ausdr¨ ucke stellen Beispiele f¨ ur einen Indexoder Wildcardzugriff dar: 1Keypad[3] 2"Add-on Package"[0]."Mobile App" 3"Add-on Package"[*]."Weather Monitor" 4"Magnetic Card"[*] In der vorliegenden Featurekonfiguration existiert nur eine Instanz des Features ”Keypad“. F¨ ur den Ausdruck in der ersten Zeile w¨ urde sich demnach der Selektionszustand unselected ergeben: Zugriffe ¨ uber die durch die tats¨ achliche Kardinalit¨ at definierte Indexgrenze hinaus sind (unter Ber¨ ucksichtigung der maxCardinality) erlaubt. In diesen F¨ allen verhalten sich nicht vorhandene Instanzen wie deselektierte Features. Boolesche Konstanten Weitere erlaubte Feature-Ausdr¨ ucke sind die Konstanten true und false, welche jeweils die Selektionszust¨ ande selected bzw. unselected haben. Sie erlauben das Mapping von Dom¨ anenmodell-Elementen ohne Bezug zu FM oder FK. Boolesche Verkn¨ upfungen: And, Or, Xor, Not Feature-Referenzen und boolesche Konstanten k¨ onnen ¨ uber boolesche Operatoren miteinander verkn¨ upft werden. FEL stellt hierzu die bin¨ aren Operatoren and,or und xor sowie das un¨ are not zur Verf¨ ugung. F¨ ur die bin¨ aren Operatoren ist keine Pr¨ azedenzregel definiert; sie verhalten sich linksassoziativ. Ist eine abweichende Assoziativit¨ at gew¨ unscht, k¨ onnen beliebig verschachtelte runde Klammern gesetzt werden. Die Semantik der Operatoren wird im folgenden erl¨ autert: not Der Selektionszustand des folgenden Ausdrucks wird invertiert (selected wird zu unselected, und umgekehrt). and Gibt den Selektionszustand selected zur¨ uck, falls beide verkn¨ upften Feature-Ausdr¨ ucke selected sind. or selected, falls mindestens einer der Operanden selected ist. xor selected, wenn genau einer der Operanden selected ist, sonst unselected. 24oder aber auch auf die Gesamtheit aller Instanzen (vgl. Abschnitt 3.2.4, Stichworte Subjektbzw. Objektbezogene Manifestation der Multplizit¨ at). 69 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Folgende Auflistung enth¨ alt einige g¨ ultige Feature-Ausdr¨ ucke, die boolesche Verkn¨ upfungen enthalten und sich wiederum auf das Featuremodell und die Featurekonfiguration aus Abbildung 4.3 (s. S. 59) beziehen: 1not Keypad[*] 2true and not false 3"Add-on Package"[0]."Mobile App" or "Add-on Package"[0]."IPad App" 4"Secure Connection" and (VPN xor SSH) Zugrundeliegende Xtext-Grammatik Quellcode 4.1 enth¨ alt den f¨ ur Feature-Ausdr¨ ucke relevanten Auszug aus der der Xtext-Grammatik (vgl. Abschnitt 2.5), die die Sprache FEL definiert. Die Regeln in den Zeilen 9 bis 13 sind rekursiv formuliert, um eine beliebige Klammerung der Ausdr¨ ucke zu erm¨ oglichen. Die Regeln FeatureReference,FeaturePath und FeaturePathSegment beschreiben den Aufbau einer Feature-Referenz und werden unter dem nachfolgenden Absatz als Ecore-Modellklassen n¨ aher betrachtet. 1import "http://www.eclipse.org/emf/2002/Ecore" as ecore 2 3generate fel "http://fel.f2dmm.ai1.ubt.de/1.0" 4 5FELExpr : FeatureExpr | AttrExpr ; 6 7FeatureExpr : OrExpr ; 8 9OrExpr returns FeatureExpr : XorExpr ({OrExpr.left=current}’or’ right=FeatureExpr)* ; 10 11 XorExpr returns FeatureExpr : AndExpr ({XorExpr.left=current}’xor’ right=FeatureExpr)* ; 12 13 AndExpr returns FeatureExpr : PrimaryExpr ({AndExpr.left=current}’and’ right=FeatureExpr)* ; 14 15 PrimaryExpr returns FeatureExpr : NegativeExpr | BooleanExpr | FeatureReference | ’(’ OrExpr ’)’ ; 16 17 NegativeExpr : ’not’ expr=FeatureExpr ; 18 19 BooleanExpr : value=Boolean ; 20 21 FeatureReference : featurePath=FeaturePath (’(’ attributeConstraint=AttributeConstraint ’)’)? ; 22 23 FeaturePath : (segments+=FeaturePathSegment) (’.’ segments+=FeaturePathSegment)* ; 24 25 FeaturePathSegment : featureName=(ID|STRING) (’[’ (index=INT | wildcard?=’*’)’]’)? ; 26 Boolean returns ecore::EBoolean : ’true’ |’false’ ; Quelltext 4.1: Xtext-Grammatik f¨ ur Feature-Ausdr¨ ucke. Die Regel AttributeConstraint wird im n¨ achsten Unterabschnitt erl¨ autert, AttrExpr in Abschnitt 4.4.3. Terminalsymbole wurden außer Acht gelassen. 70 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Ecore-Modell Abbildung 4.11 zeigt ein Ecore-Klassendiagramm des Ausschnitts des FELMetamodells, welches aus der obigen Xtext-Grammatik generiert wurde. Die XtextLaufzeitumgebung erzeugt beim Parsen eines FEL-Dokuments jeweils eine Instanz von FELExpr, deren Subtyp FeatureExpr Feature-Ausdr¨ ucke repr¨ asentiert. Jede Unterklasse von FeatureExpr muss das abgeleitete Attribut state vom Typ FELState implementieren, welches den Selektionszustand des jeweiligen Ausdrucks bestimmt. Die Unterklassen von CompositeExpr verschachteln weitere Feature-Ausdr¨ ucke paarweise rekursiv ¨ uber die Containment-Beziehungen left bzw. right; auf entsprechende Weise verweist NegativeExpr ¨ uber expr auf den zu negierenden Ausdruck. Eine Feature-Referenz setzt sich aus einem qualifizierenden Pfad (FeaturePath) und einem optionalen Attribut-Constraint (s. n¨ achster Abschnitt) zusammen. Jedes Segment des Pfades enth¨ alt neben dem Namen des Features einen eventuellen Index. Ist kein Index notiert, wird der Standardwert −1 angenommen. Das boolesche Attribut wildcard hat den Wert true, falls anstatt eines Index die Wildcard gesetzt wurde. Abbildung 4.11: Von Xtext generiertes und manuell erg¨ anztes Ecore-Modell, das der oben beschriebenen Grammatik zugrunde liegt. Die Vorgehensweise von der Grammatik zum anpassbaren Metamodell wurde in Abschnitt 2.5.3 beschrieben. 71 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Verbindung zu Featuremodell und -konfiguration Die Verbindung zwischen FeatureAusdruck und entsprechendem FM bzw. FK wird tempor¨ ar nach dem Parsen eines FeatureAusdrucks hergestellt: Die nachtr¨ aglich hinzugef¨ ugten Methoden applyFeatureModel(Root) bzw. applyFeatureConfiguration(Root) der Schnittstelle FELExpr bewirken in allen nicht-abstrakten Unterklassen das Setzen der Referenzen featureModel bzw. featureConfiguration auf das ¨ ubergebene Element. Bei verschachtelten Ausdr¨ ucken erfolgt der Funktionsaufruf rekursiv, so dass jedes Element eines geparsten Feature-Ausdrucks, insbesondere die Feature-Referenzen, auf das FM sowie die aktuelle FK zugreifen k¨ onnen. Sobald ein Feature-Ausdruck mit einem Featuremodell sowie einer -konfiguration assoziiert wurde, wird in Instanzen von FeatureReference nach Features gesucht, die diesem Ausdruck entsprechen. W¨ ahrend eine Feature-Referenz nach Aufl¨ osung eventueller Mehrdeutigkeiten durch die Verwendung von qualifizierenden Namen genau ein Feature aus dem Featuremodell repr¨ asentiert, k¨ onnen beim Gebrauch von Wildcards mehrere Features aus der geladenen Featurekonfiguration assoziiert sein. Dies spiegelt sich in den Wertigkeiten der abgeleiteten, nicht-fl¨ uchtigen Referenzen modeledFeature (0..1) und configuredFeatures (0..*) wider, die auf die entsprechenden Elemente aus FM und FK verweisen. Die Methode invalidate() aus dem Interface FELExpr wird immer dann aufgerufen, wenn sich ¨ Anderungen im Featuremodell oder der -konfiguration ergeben haben, sowie nach dem erstmaligen Setzen letzterer. Sie implementiert das Zur¨ ucksetzen der abgeleiteten Attribute sowie des Selektionszustands bei Bedarf (vgl. auch Abschnitt 4.7.6). 4.4.2 Feature-Ausdr¨ ucke mit Constraints auf Attributwerten In Abschnitt 3.2.5 wurde diskutiert, inwiefern sich das Variabilit¨ atsmerkmal Optionalit¨ at in Feature-Attributen ¨ außern kann. Eine M¨ oglichkeit bestand in der Abh¨ angigkeit einer Abbildung von sog. Attribut-Constraints: Ein Dom¨ anenmodell-Element realisiert ein Feature nur dann, wenn bestimmte Bedingungen auf dem Wert eines Attributs des Features gelten. In FEL integrierte Attribut-Constraints erlauben den Vergleich eines tats¨ achlichen AttributWerts mit einem Soll-Wert und weisen einem Feature-Ausdruck nur dann den Selektionszustand selected zu, falls die Bedingung zus¨ atzlich von der aktuell geladenen FK erf¨ ullt wird. Elementare Constraints: Arten des Vergleichs Die Notation eines Attribut-Constraints erfolgt nach einer einzuschr¨ ankenden Feature-Referenz in runden Klammern. Sog. elementare Constraints vergleichen den Wert eines Attributs mit einem Soll-Wert unter Verwendung eines Vergleichs-Operators. Die Bedingungen werden nur ausgewertet, wenn die Feature-Referenz f¨ ur die aktuelle Featurekonfiguration den Selektionszustand active hat. Trifft ein Constraint nicht zu, so wird der Selektionszustand zu inactive. In FEL sind folgende sechs VergleichsOperatoren definiert: =(Gleichheit) Bezieht sich auf die lexikalische Gleichheit des aktuellen mit dem Soll-Wert. <> (Ungleichheit) Ebenfalls bezogen auf lexikalische Gleichheit, jedoch mit umgekehrtem Wahrheitswert. <(Kleiner) Stellen tats¨ achlicher Wert und Soll-Wert Zahlen dar, so wird der numerische Kleiner-Vergleich herangezogen, ansonsten der lexikalische. <=(Kleiner oder gleich) Trifft zu im Falle einer lexikalischen Gleichheit oder eines numerischen Kleiner-Vergleichs. 72 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien >(Gr¨ oßer) Stellen tats¨ achlicher Wert und Soll-Wert Zahlen dar, so wird der numerische Gr¨ oßer-Vergleich herangezogen, ansonsten der lexikalische. >=(Gr¨ oßer oder gleich) Trifft zu im Falle einer lexikalischen Gleichheit oder eines numerischen Gr¨ oßer-Vergleichs. Attribute, die zum Vergleich herangezogen werden sollen, werden ebenfalls ¨ uber ihren Namen referenziert. Wie auch bei Feature-Referenzen werden doppelte Hochkommata verlangt, sobald diese Leeroder Sonderzeichen enthalten. Folgende Auflistung enth¨ alt einige Beispiele f¨ ur Attribut-Constraints, wiederum bezogen auf Featuremodell und -konfiguration aus Abbildung 4.3 (s. S. 59): 1not "Air Condition Control"("Min Temperature" >= 20) 2"Secore Connection".VPN("Vendor Protocol" ="Cisco") 3"Add-on-Package"[0]."Mobile App"(Platform = "Android") Ohne Attribut-Constraint w¨ urde der Feature-Ausdruck aus Zeile 3 den Selektionszustand active ergeben. Jedoch trifft der Vergleich Platform = "Android" in der geladenen Featurekonfiguration nicht zu und der gesamte Ausdruck evaluiert zu inactive. Boolesche Verkn¨ upfungen von Constraints Wie auch Feature-Ausdr¨ ucke k¨ onnen AttributConstraints ¨ uber boolesche Verkn¨ upfungen in beliebiger Schachtelungstiefe miteinander kombiniert werden. Die Syntax und die Semantik der Operatoren sind identisch mit der f¨ ur Feature-Ausdr¨ ucke. F¨ ur die Auswertung der Ausdr¨ ucke gilt das selbe wie f¨ ur elementare Attribut-Constraints: Sie werden nur in Betracht gezogen, falls der ¨ ubergeordnete FeatureAusdruck active ergibt. Falls dann der Attribut-Constraint inactive ergibt, wird dieser Selektionszustand an den Feature-Ausdruck weiterpropagiert. Folgende Auflistung enth¨ alt einen weiteren, komplexen Feature-Ausdruck mit verschachteltem Attribut-Constraint: 1"Add-on-Package"[0]."Mobile App"(Platform = "Android 3" or Platform = "Android 4") and not "Add-on-Package[0]."IPad App" Zugrundeliegende Xtext-Grammatik Die Xtext-Grammatik in Quellcode 4.2 ist erg¨ anzend zur Basisgrammatik (s. Quellcode 4.1) zu betrachten. Die Verschachtelung boolescher Ausdr¨ ucke wurde analog realisiert; pro Vergleichsoperator existiert jeweils eine eigene Regel. 1AttributeConstraint : OrAttributeConstraint ; 2 3OrAttributeConstraint returns AttributeConstraint : XorAttributeConstraint({OrAttributeConstraint.left=current}’or’ right=AttributeConstraint)* ; 4 5XorAttributeConstraint returns AttributeConstraint : AndAttributeConstraint({XorAttributeConstraint.left=current}’xor’ right=AttributeConstraint)* ; 6 7AndAttributeConstraint returns AttributeConstraint : PrimaryAttributeConstraint({AndAttributeConstraint.left=current}’and’ right=AttributeConstraint)* ; 8 9PrimaryAttributeConstraint returns AttributeConstraint : ElementaryAttributeConstraint 73 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Abbildung 4.14: Metamodell f¨ ur die abstrakte Repr¨ asentation von SDIRL-Dokumenten. Die Klasse ContextCS repr¨ asentiert die Regel OCLModel aus der Grammatik. Deren Unterklassen sind ebenfalls aus Gr¨ unden der ¨ Ubersichtlichkeit nicht dargestellt. •Zum einen handelt es sich bei der Xtext-Grammatik f¨ ur Essential OCL um ein Projekt mit experimentellem Status: Der Build-Prozess ist nicht dokumentiert und der ¨ Ubergang von der konkreten zur abstrakten Syntax noch nicht vollst¨ andig formal spezifiziert. •Zum anderen h¨ atte die Integration der Xtext-Grammatik im Sinne einer Vererbung die Notwendigkeit der Anpassung einiger OCL-Laufzeitmodule nach sich gezogen25. Aus den genannten Gr¨ unden wurde bei der Integration von OCL-Ausdr¨ ucken in whenbzw. surrogate-Bl¨ ocke der SDIRL-Grammatik auf den von Xtext bereitgestellten Vererbungsmechanismus verzichtet. Stattdessen wurden die Produktionsregeln der Essential-OCLGrammatik in die SDIRL-Grammatik ¨ ubernommen und die Referenzen auf das OCLMetamodell eliminiert, um die Ecore-Klassen von Xtext in das SDIRL-Paket generieren zu lassen. Die syntaktische Korrektheit von OCL-Ausdr¨ ucken wird auf diese Weise im Texteditor sichergestellt. Jedoch entf¨ allt beim gew¨ ahlten Ansatz mangels wiederverwender OCLEssential-Laufzeitmodule die M¨ oglichkeit f¨ ur die Erkennung semantischer Fehler und Editierunterst¨ utzung wie automatische Quelltextvervollst¨ andigung (Code Completion) in OCLBl¨ ocken. Die gew¨ ahlte Vorgehensweise erfordert außerdem ein zweimaliges Parsen der enthaltenen OCL-Bl¨ ocke: Zun¨ achst erzeugt der Xtext-generierte SDIRL-Parser die konkrete Syntax – also die Modellrepr¨ asentation – des Ausdrucks. Da diese aus den oben beschriebenen Gr¨ unden nicht mit dem Essential-OCL-Modell kompatibel ist, werden innerhalb des SDIRL-Editors die OCL-Ausdr¨ ucke ein weiteres mal vom entsprechenden Essential-OCL-Laufzeitmodul geparst: Dies geschieht im SDIRL-Validierungsmodul, um die semantische Korrektheit sowie die Kompatibilit¨ at der R¨ uckgabewerte der eingebetteten Ausdr¨ ucke26 sicherzustellen. Dem Anwender werden im angepassten SDIRL-Editor entsprechende Fehler angezeigt (s. Unterabschnitt 4.5.3). 25Etwa, um das durch das Linking-Modul beschriebene angewandte Auftreten von Ecore-Klassen hinsichtlich importierter Metamodelle anzupassen. 26Typ Boolean im when-Teil, kompatibel mit der requires angegebenen Klasse in surrogate-Bl¨ ocken. 80 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Referenzieren von Ecore-Klassen Innerhalb der elementbzw. requires-Teile einer SDIRLRegel k¨ onnen Ecore-Datentypen aus importierten Namensr¨ aumen angegeben werden. Das Referenzieren von Ecore-Klassen durch deren qualifizierenden Namen wird durch die Einbindung der im Rahmen des Xtext-Ecore-Projekts27 entwickelten Ecore-Schnittstelle erm¨ oglicht. Die Produktionsregel FQN definiert lediglich ein Symbol f¨ ur qualifizierende Namen. Das Binden an ein angewandtes Auftreten erfolgt durch das Konstrukt ecore::EClass|FQN. Die entsprechende Linking-API (vgl. Abschnitt 2.5.2) wird durch referenzieren des EcoreMetamodells und des Generator-Modells sowie das Registrieren der MWE-Komponente org.eclipse.ecore.xtext.EcoreSupport eingebunden: 1bean = StandaloneSetup { 2(...) 3registerGeneratedEPackage = "de.ubt.ai1.f2dmm.sdirl.SdirlPackage" 4registerGeneratedEPackage = "org.eclipse.emf.ecore.EcorePackage" 5registerGenModelFile = "platform:/resource/org.eclipse.emf.ecore/model/Ecore.genmodel" 6} 7 8component = org.eclipse.xtext.ecore.EcoreSupport {} Um den Import von Ecore-Namensr¨ aumen zu erm¨ oglichen, gen¨ ugt es, die von Xtext definierten Konventionen f¨ ur explizite Importe zu beachten [19, Abschnitt 5]: Lautet ein Attribut vom Datentyp EString auf den Bezeichner importURI, sucht die Xtext-Laufzeitumgebung bei der Anwendung der definierten Produktionsregel nach dem im entsprechenden Dokument spezifizierten Namensraum. Folgende Anpassung im generierten Laufzeitmodul sorgt daf¨ ur, dass auch Importe, die nicht auf ”.ecore“ enden, mit dem Ecore-Linking-Laufzeitmodul assoziiert werden: 1public class SdirlRuntimeModule extends de.ubt.ai1.f2dmm.sdirl.AbstractSdirlRuntimeModule { 2 3@Override 4public Registry bindIResourceServiceProvider$Registry() { 5Registry registry = super.bindIResourceServiceProvider$Registry(); 6registry.getExtensionToFactoryMap().put("*", registry.getExtensionToFactoryMap().get("ecore")); 7return registry; 8} 9} 4.5.3 Editor-Unterst¨ utzung Der von Xtext generierte Editor wurde bis auf die im vorhergehenden Unterabschnitten dargestellten ¨ Anderungen bez¨ uglich der Auswertung von OCL-Ausdr¨ ucken und der Referenzierung von Ecore-Klassen nicht weiter manuell angepasst. Wie bereits beschrieben, wurde die kontextsensitive Validierung von SDIRL-Modellen um die ¨ Uberpr¨ ufung der eingebetteten OCL-Ausdr¨ ucke erg¨ anzt. Der Screenshot in Abbildung 4.15 zeigt die Validierung aus Anwendersicht. 27http://download.eclipse.org/modeling/tmf/xtext/javadoc/2.0.1/org/eclipse/xtext/ecore/ EcoreSupport.html 81 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Abbildung 4.15: Bildschirm-Ausschnitt, der die Benutzung des textuellen SDIRL-Editors demonstriert: Der Anwender wird darauf hingewiesen, dass ein OCL-Ausdruck im whenBlock keinen Wahrheitswert zur¨ uckliefert. 4.5.4 Auswertung der eingebetteten OCL-Ausdr¨ ucke W¨ ahrend im SDIRL-Editor noch keine Objekte an die in element und requires deklarierten Variablen gebunden werden, findet innerhalb der F2DMM-Laufzeitumgebung eine solches Binden f¨ ur jedes Paar von gemappten DM-Elementen – kompatible Datentypen vorausgesetzt – statt. Die Auswertung der Ausdr¨ ucke erfolgt wiederum durch einen zus¨ atzlichen ParseSchritt, der von dem vom Eclipse-OCL-Projekt28 bereitgestellten Essential-OCL-Interpreter durchgef¨ uhrt wird. Auch das Binden der Variablen erfolgt mit Hilfe der bereitgestellten API. Quelltext 4.6 dokumentiert den Aufruf der Eclipse-OCL-API zur Auswertung von OCLAusdr¨ ucken zur Laufzeit. 1public boolean isWhenConditionTrue(String elementName, EClass elementType, EObject elementValue, String requiredName, EClass requiredType, EObject requiredValue, String whenConditionExpr) throws ParserException { 2 3OCL ocl = OCL.newInstance(EcoreEnvironmentFactory.INSTANCE); 4OCLHelper<EClassifier, EOperation, EStructuralFeature, Constraint> helper = ocl.createOCLHelper(); 5 6Variable<EClassifier, EParameter> elementVar = ExpressionsFactory.eINSTANCE.createVariable(); 7elementVar.setName(elementName); 8elementVar.setType(elementType); 9ocl.getEnvironment().addElement(elementName, elementVar, true); 10 11 Variable<EClassifier, EParameter> requiredVar = ExpressionsFactory.eINSTANCE.createVariable(); 12 requiredVar.setName(requiredName); 13 requiredVar.setType(requiredType); 14 ocl.getEnvironment().addElement(requiredName, requiredVar, true); 15 16 OCLExpression<EClassifier> oclExpression = helper.createQuery(whenConditionExpr); 17 Query query = ocl.createQuery(oclExpression); 18 19 oclQuery.getQuery().getEvaluationEnvironment().add(elementName, elementValue); 28http://www.eclipse.org/modeling/mdt/?project=ocl 82 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien 20 oclQuery.getQuery().getEvaluationEnvironment().add(requiredName, requiredValue); 21 22 return oclQuery.getQuery().check((EObject) null); 23 } Quelltext 4.6: Java-Methode, die die ¨ Uberpr¨ ufung des when-Teils einer SDIRL-Abh¨ angigkeitsdefinition zur Laufzeit implementiert (vereinfachte Darstellung). Zun¨ achst wird eine OCL-Ausf¨ uhrungsumgebung initialisiert (Zeilen 3 und 4) und freie Variablen f¨ ur element bzw. requires definiert (Z. 6 bis 14). Anschließend wird der OCL-Ausdruck geparst (Z. 16 und 17) und die zur Laufzeit bekannten Werte an die Variablen gebunden (Z. 19 und 20). Schließlich wird der Ausdruck ausgewertet und der dabei ermittelte Wert zur¨ uckgegeben (Z. 22). In der Implementierung des SDIRL-Moduls wurde die Instanziierung und Ausf¨ uhrung von OCL-Anfragen dieser Art verallgemeinert und hinsichtlich Wiederverwendbarkeit optimiert. Die Klasse SdirlOCLEvaluator kapselt alle Anfragen an die Eclipse-OCL-API und stellt Mechanismen wie Ausnahmebehandlung zur Verf¨ ugung. Auf die bereitgestellte Funktionalit¨ at wird vom SDIRL-Editor sowie von der F2DMM-Werkzeugumgebung zugegriffen (s. Abschnitt 4.7.3). 4.5.5 Auswertung von Surrogat-Ausdr¨ ucken Die Auswertung von in surrogate-Bl¨ ocken definierten OCL-Anfragen erfolgt ¨ ahnlich wie bei den im vorhergehenden Unterabschnitt beschriebenen when-Bedingungen. Die Verbindung zur Eclipse-OCL-API wird ¨ uber eine Instanz von SdirlOCLEvaluator hergestellt. Innerhalb des F2DMM-Editors geschieht dies im Rahmen des großen Invalidierungszyklus (vgl. Abschnitt 4.7.6) zur Surrogat-Vorbzw. Neuberechnung. Bei erfolgreicher Auswertung eines Surrogat-Ausdrucks wird eine Instanz von EObject zur¨ uckgegeben, welche ein Element aus dem Kern-Dom¨ anenmodell repr¨ asentiert. Das Mapping-Modell ist wiederum in der Lage, das Mapping, welches das Element abbildet, zu ermitteln, um Reparaturaktionen abzuleiten, welche Gegenstand von Abschnitt 4.8.5 sind. Bei mengenwertigen R¨ uckgabewerten wird iterativ vorgegangen. 4.6 Mapping-Beschreibungen und Alternativen-Mappings In den vorhergehenden Abschnitten wurde darauf eingegangen, wie die Verkn¨ upfung eines Mappings zum Featuremodell und der Featurekonfiguration erfolgt. Dieser Abschnitt legt den Fokus auf die Verkn¨ upfung zum Dom¨ anenmodell. Abbildung 4.6 stellt diese Verkn¨ upfung vereinfacht als strukturelle Eigenschaften der Mapping-Unterklassen dar, n¨ amlich ¨ uber die Referenzen mappedObject bzw. referencedMapping und das Attribut attrValue. Zus¨ atzlich wird auf das abgebildete Attribut bzw. die abgebildete Referenz aus dem Metamodell verwiesen. In der tats¨ achlichen Implementierung des F2DMM-Metamodells ist an dieser Stelle ein weiterer Abstraktionsschritt vorgesehen, die sog. Mapping-Beschreibungen. Zun¨ achst werden deren zugrundeliegende Konzepte erl¨ autert, bevor auf die Benutzersicht, die Erzeugung von Alternativen-Mappings, eingegangen wird. 83 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien 4.6.1 Die Konzeptsicht: Mapping-Beschreibungen als Verkn¨ upfung zum Dom¨ anenmodell Mappings beschreiben nicht selbst abgebildete Artefakte des Dom¨ anenmodells; vielmehr ¨ ubernehmen Mapping-Beschreibungen als Unterklassen von der F2DMM-Modellklasse MappingDescription diese Aufgabe. Ziel dieser weiteren Abstraktion ist die Unterst¨ utzung verschiedener Arten der Abbildung: Es wurde bereits darauf eingegangen, dass AttributMappings beispielsweise sog. Patterns enthalten k¨ onnen, ¨ uber die mit Hilfe von AttributAusdr¨ ucken (s. Abschnitt 4.4.3) Bezug zu Attributwerten der aktuellen Featurekonfiguration Bezug genommen werden kann. ¨ Ahnliche Mechanismen greifen bei Containmentoder Referenz-Mappings. In den nachfolgenden Unterabschnitten werden die Entwurfsentscheidungen f¨ ur die unterschiedlichen Arten von Mapping-Beschreibungen erl¨ autert. Containment-Mapping-Beschreibungen Containment-Mappings beinhalten als Implementierungsklasse von ContainmentMappingDescriptionContainer jeweils eine ContainmentMappingDescription (vgl. Abbildung 4.16). Die Schnittstelle verweist auf eine EReference: Eine Containment-Referenz aus dem Dom¨ anen-Metamodell, welche die Beziehung des abgebildeten DM-Elements zu seinem eContainer modelliert. Sie deklariert außerdem die abgeleitete Referenz mappedObject vom Typ EObject, welche von den Unterklassen implementiert wird, um das abgebildete Objekt zu repr¨ asentieren. Es existieren zwei Arten von MappingBeschreibungen f¨ ur Containment-Mappings, f¨ ur die folgendes Verhalten definiert ist: Abbildung 4.16: Beschreibungen f¨ ur Containment-Mappings werden durch Instanzen von ContainmentMappingDescription repr¨ asentiert. Die Referenz mappedObject ist abgeleitet (derived). •WrappingContainmentMappingDescription: Bezieht sich auf ein vorhandenes DMElement als Instanz von EObject. Dieses muss sich innerhalb einer existierenden EMFRessource, aber nicht notwendigerweise in der Ressource des Multivarianten-DM, befinden. Die abgeleitete Referenz mappedObject der implementierten Schnittstelle wird durch den Wert von wrappedObject definiert. Weiterhin wird zwischen prim¨ aren und sekund¨ aren Mapping-Beschreibungen unterschieden: Sekund¨ are Mapping-Beschreibungen entstehen durch Kopie einer prim¨ aren Beschreibung. Sie werden ausschließlich von Alternativen-Mappings verwendet. 84 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien •InPlaceContainmentMappingDescription: Mapping-Beschreibungen dieser Art entstehen ausschließlich benutzergesteuert als Beschreibungen f¨ ur Alternativen-Mappings. Anstatt auf eine konkrete Instanz zu verweisen, wird hierbei auf eine Klasse aus dem Dom¨ anen-Metamodell verwiesen (instanceClass), die erst zum Zeitpunkt der Produktableitung als Referenzziel von mappedObject instanziiert wird. Verschachtelte Objekte und Attribute k¨ onnen rekursiv unter dem entsprechenden Mapping eingef¨ ugt werden. Attribut-Mapping-Beschreibungen Attribut-Mappings implementieren das Interface AttributeMappingDescriptionContainer, welches eine Containment-Referenz zu AttributeMappingDescription definiert (vgl. Abbildung 4.17). Dieses Interface implementierende Klassen enthalten eine Referenz mappingAttribute vom Typ EAttribute, die auf dasjenige Attribut aus dem Dom¨ anen-Metamodell verweist, welches die Beziehung des unmittelbar ¨ ubergeordneten Containment-Mappings zu dem Attributwert beschreibt, der in seiner String-serialisierten Form vom abgeleiteten Attribut finalMappedValue bestimmt wird. F¨ ur Attribut-Mappings existieren die folgenden zwei konkreten Arten von Mapping-Beschreibungen: Abbildung 4.17: Das Interface AttributeMappingDescription definiert ein abgeleitetes Attribut finalMappedValue, welches die String-Repr¨ asentation des abgebildeten Attributwerts enth¨ alt. •SimpleAttributeMappingDescription: Beinhaltet direkt den String-serialisierten Wert mappedValue, der unver¨ andert an finalMappedValue weitergegeben wird. •PatternAttributeMappingDescription: Definiert ein mappingPattern, das eine beliebige Anzahl von Attribut-Ausdr¨ ucken (vgl. Abschnitt 4.4.3) beinhalten kann. Diese werden aus dem String extrahiert und zur Laufzeit vom FEL-Parser in ihre abstrakte Syntax ¨ uberf¨ uhrt und ausgewertet. Der resultierende Attributwert, ebenfalls ein String, tritt an Stelle des definierenden Patterns. Diese Art des Mappings ist nur f¨ ur AlternativenMappings relevant und erm¨ oglicht dem Anwender, Attribute des abgeleiteten Produkts in Abh¨ angigkeit von der geladenen Featurekonfiguration zu festzulegen. 85 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Referenz-Mapping-Beschreibungen Das vereinfachte F2DMM-Metamodell in Abbildung Abbildung 4.6 deutet bereits an, dass sich Referenz-Mappings nicht direkt auf das Ziel einer Nicht-Containment-Referenz des Dom¨ anenmodells, sondern vielmehr auf dessen abbildendes Containment-Mapping beziehen. Dies ist jedoch nur dann m¨ oglich, wenn das referenzierte Objekt bereits durch ein Containment-Mapping repr¨ asentiert wird. Deshalb existieren auch f¨ ur Referenz-Mapping-Beschreibungen zwei M¨ oglichkeiten der Abbildungen, um den Wert der abgeleiteten Referenz referencedObject zu bestimmen: Abbildung 4.18: Ecore-Klassendiagramm f¨ ur Referenz-Mapping-Beschreibungen. •InternalReferenceMappingDescription: Wird verwendet, wenn das abzubildende Referenzziel von einem prim¨ aren Containment-Mapping abgebildet wird. Der Wert f¨ ur referencedObject ergibt sich als das von letzterem abgebildete Element. •ExternalReferenceMappingDescription: Befindet sich das Referenzziel in keinem Containment-Mapping, sondern in einer externen EMF-Ressource, bestimmt es direkt als externalObject den Wert von referencedObject. Ein auf diese Weise abgebildetes Referenzziel verh¨ alt sich w¨ ahrend der Produkt-Ableitung so, als bef¨ ande es sich innerhalb eines Containment-Mappings mit dem annotierten Feature-Ausdruck true. 4.6.2 Die Anwendersicht: Erzeugung von Alternativen-Mappings In Abschnitt 3.2.3 wurde diskutiert, inwieweit die Notwendigkeit zur Definition von Variationspunkten auf Anwenderseite besteht: Einwertige strukturelle Eigenschaften wie etwa der Name einer UML-Klasse d¨ urfen in einem Multivarianten-Dom¨ anenmodell nur einmal vorkommen. Bestandteil der Vor¨ uberlegungen war auch, inwieweit Attribute des Featuremodells die Werte von Attributen abgeleiteter Produkte beeinflussen k¨ onnen (vgl. Abschnitt 3.2.5). Bei der Beschreibung des F2DMM-Metamodells in Abschnitt 4.3 wurden AlternativenMappings bereits als benutzerdefinierte Erg¨ anzungen f¨ ur Kern-Mappings, welche mit dem Dom¨ anenmodell synchron gehalten werden, erw¨ ahnt. Sie enthalten jeweils eine MappingBeschreibung, durch die die Verbindung zum Kernoder zu einem alternativen Teildom¨ anenmodell hergestellt wird. In diesem Abschnitt wird die Erweiterung des durch KernDom¨ anenmodell-Elemente definierten Mapping-Modells um Alternativen-Mappings aus Anwendersicht erl¨ autert. 86 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Der Alternativen-Wizard Das Anlegen von Alternativen-Mappings in einem ge¨ offneten Mapping-Modell erfolgt im Editor durch Auswahl des entsprechenden Kontextmen¨ u-Eintrags New Alternative unter einem existierenden Containment-Mapping. Es erscheint der in Abbildung 4.19 gezeigte Wizard, der den Anwender die strukturelle Eigenschaft – also eine kompatible Referenz bzw. ein kompatibles Attribut aus dem Dom¨ anen-Metamodell – w¨ ahlen l¨ asst, f¨ ur die ein Alternativen-Mapping erzeugt werden soll. Abh¨ angig davon, ob eine Containment-, eine Nicht-Containment-Referenz oder ein Attribut gew¨ ahlt wurde, stehen anschließend die in den folgenden Abs¨ atzen beschriebenen Auswahlm¨ oglichkeiten zur Verf¨ ugung. Abbildung 4.19: Die erste Seite des Wizards zur Erstellung von Alternativen Mappings verlangt nach der Auswahl eines Attributs oder einer Referenz aus dem Dom¨ anen-Metamodell. Alternativen f¨ ur Containment-Mappings In Abschnitt 4.6.1 wurden die beiden Containment-Mapping-Beschreibungen Wrapping bzw. In-Place vorgestellt. Ersterer referenziert ein tats¨ achlich vorhandenes Element als Instanz von EObject, w¨ ahrend die In-PlaceVariante die Angabe einer zu instanziierenden Klasse verlangt. Abbildung 4.20 zeigt einen Screenshot der Wizard-Seite, die den Anwender eine der folgenden drei M¨ oglichkeiten zur Erzeugung eines Alternativen-Mappings inklusive einer entsprechenden Mapping-Beschreibung w¨ ahlen l¨ asst: •Prim¨ ares Wrapping-Containment-Mapping durch Angabe eines Dom¨ anenmodellElements aus einer externen Ressource: Dem Anwender wird im Anschluss ein Auswahldialog angezeigt, in dem er ein Objekt, dessen Typ mit der in der ersten Wizard-Seite gew¨ ahlten Containment-Referenz ¨ ubereinstimmen muss, aus einer externen Ressource w¨ ahlen soll. Mappings f¨ ur in dem Objekt verschachtelte Elemente werden entsprechend seines aufspannenden Containment-Baums rekursiv erzeugt. 87 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Abbildung 4.20: F¨ ur die Erstellung von Alternativen-Containment-Mappings stehen drei M¨ oglichkeiten zur Auswahl. •Sekund¨ ares Wrapping-Containment-Mapping als Kopie eines vorhandenen, prim¨ aren Kern-Mappings. Das gew¨ ahlte Mapping und sein beinhalteter Teilbaum werden kopiert und als sekund¨ ar (primary = false) markiert. Die Kopie wird nach ihrer Erzeugung nicht durch ¨ Anderungen im Original-Dom¨ anenmodell beeinflusst. •In-Place-Definition eines Containment-Mappings durch Angabe einer nicht-abstrakten, dem Typ der Containment-Referenz entsprechenden Ecore-Klasse aus dem Dom¨ anenMetamodell. Es wird eine InPlaceContainmentMappingDescription mit Referenz auf die gew¨ ahlte Klasse erzeugt. Enthaltene Mappings m¨ ussen manuell vom Anwender angelegt werden. Alternativen f¨ ur Attribut-Mappings Abbildung 4.21 zeigt einen Bildschirm-Ausschnitt der zweiten Wizard-Seite unter der Voraussetzung, dass die zuvor gew¨ ahlte strukturelle Eigenschaft ein Attribut ist. Sie stellt dem Anwender zwei verschiedene M¨ oglichkeiten zur Verf¨ ugung, um den Wert des gew¨ ahlten Attributs zu spezifizieren: •Direkte Angabe der String-Repr¨ asentation des Attributwerts ¨ uber ein Eingabefeld. Es wird eine entsprechende SimpleAttributeMappingDescription erzeugt. Wurde ein Aufz¨ ahlungstyp ausgew¨ ahlt, wird auf der folgenden Seite anstatt einer Eingabemaske ein Auswahlfeld mit allen verf¨ ugbaren Literalen angezeigt. 88 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien •Pattern-basierte Erzeugung eines Mappings auf Basis einer PatternAttributeMappingDescription, die einen in einem Eingabefeld anzugebenden Text nach Attribut-Ausdr¨ ucken (vgl. Abschnitt 4.4.3) durchsucht. Diese werden unter Ber¨ ucksichtigung der aktuell geladenen Featurekonfiguration ausgewertet und durch ihr Ergebnis ersetzt. Der Wert des Attributs ¨ andert sich entsprechend, wenn die geladene Featurekonfiguration manipuliert oder eine andere geladen wird. Abbildung 4.21: Die auf Alternativen-Attribut-Mappings bezogene Wizard-Seite erlaubt die Auswahl eines direkten oder eines Pattern-basierten Modus zur Angabe von Attributwerten. Beide Modi verlangen die Angabe der String-Repr¨ asentation eines Attributwerts f¨ ur einen primitiven Datentypen. Dieser wird durch den Ecore-Adapter-Factory-Mechanismus (vgl. Abschnitt 2.3.1) interpretiert und zur Laufzeit in den entsprechenden Datentyp umgewandelt. Hierbei auftretende Fehler, wie etwa die Angabe eines vom Attribut-Datentyp nicht interpretierbaren Strings werden von der Modellvalidierung (s. Abschnitt 4.9.3) behandelt. Alternativen f¨ ur Referenz-Mappings Auch bei der Angabe von alternativen Referenzzielen f¨ ur Nicht-Containment-Referenzen wird vom Anwender die Wahl eines von zwei MappingModi verlangt (vgl. Abbildung 4.22): •Angabe eines externen Referenzziels zur Erzeugung einer neuen Mapping-Beschreibung auf Basis der Klasse ExternalReferenceMappingDescription. Auf der folgenden Wizard-Seite wird in diesem Fall die Angabe einer externen Ressource und anschließend eines kompatiblen Referenzziels aus dieser Ressource verlangt. Das erzeugte AlternativeReferenceMapping referenziert das angegebene Objekt in seiner MappingBeschreibung. 89 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien 8EList<EObject> depSurrogates = getMappingModel().getOCLEvaluator().getSurrogates( 9getDependency().getName(), 10 getDependency().getElementName(), sourceElement, 11 getDependency().getRequiredName(), targetElement, 12 surrogateExpr); 13 surrogates.addAll(depSurrogates); 14 } 15 } 16 return getSurrogatesGen(); 17 } Quelltext 4.10: Berechnung von Surrogat-Objekten durch Auswertung entsprechender OCLAusdr¨ ucke in der Methode getSurrogates() der Klasse MappingRequirementImpl. Die Auswertung von Surrogat-Ausdr¨ ucken findet bei erstmaligem Aufruf der abgeleiteten, transienten Referenz surrogates statt (falls die surrogates-Liste noch nicht initialisiert ist, vgl. Quelltext 4.10, Z. 2). Auch hier wird von der Abstraktionsklasse OCLEvaluator Gebrauch gemacht, in der die tats¨ achliche Auswertung aller Surrogat-Ausdr¨ ucke erfolgt. Die R¨ uckgabewerte der OCL-Anfragen werden entsprechend in surrogates aufgenommen. Sich gegenseitig ausschließende Mappings Zus¨ atzlich zu der ¨ uber die Assoziationsklasse MappingRequirement abgebildete Beziehung requires existiert die Referenz excludes zwischen Instanzen von Annotatable, welche in Phase 0 populiert wird. Vom Anwender erzeugte Alternativen-Mappings konkurrieren m¨ oglicherweise mit vom Synchronisierungsmodul automatisch erzeugten Kern-Mappings oder mit weiteren Alternativen-Mappings. Dies ist der Fall, sobald unterhalb eines Containment-Mappings mehrere Alternativen-Mappings existieren, die sich auf dieselbe einwertige strukturelle Eigenschaft (isMany() == false) beziehen. Zur L¨ osung solcher durch konkurrierende Mappings entstehender Ausschlusskonflikte (s. Phase 4) wird a priori eine Rangfolge definiert, die festlegt, welches positiv annotierte Mapping den Wert eines einwertigen Attributs oder einer einwertigen Referenz bestimmen wird: 1. Kern-Mappings entstehen durch Abbildung eines wohlgeformten MultivariantenDom¨ anenmodells. Folglich kann es nur je ein Kern-Mapping unterhalb eines Containment-Mappings geben, welches sich auf eine einwertige strukturelle Eigenschaft bezieht. Ein solches Kern-Mapping hat prinzipiell den Vorrang vor konkurrierenden Alternativen-Mappings. 2. Alternativen-Mappings k¨ onnen auch f¨ ur einwertige strukturelle Eigenschaften in beliebiger Anzahl vom Anwender erzeugt werden. Eventuell konkurrierende AlternativenMappings bekommen in der Rangfolge den Stellenwert ihrer Position im MappingModell zugewiesen: Ausschlusskonflikte werden anhand der Einf¨ ugereihenfolge aufgel¨ ost. Innerhalb der prepare()-Methode eines Annotatable wird in Phase 0 f¨ ur jedes Paar (E, F) die Methode E.doesExclude(F)aufgerufen, welche nach den oben definierten Priorit¨ atsregeln pr¨ uft, ob die Annotation von Emit einem positiven Feature-Ausdruck das Vorhandensein von Fausschließt. Ist dies der Fall, wird Fin die excludes-Menge von Eaufgenommen und die inverse Referenz excludedBy entsprechend gesetzt. 96 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien 4.7.4 Die Propagationsstrategien ”Vorw¨ arts“ und ”R¨ uckw¨ arts“ In den obigen Ausf¨ uhrungen wurden bereits die in Abschnitt 3.3.3 vorgestellten Propagationsstrategien (PS) aufgegriffen. Werden sie zur Aufl¨ osung von Abh¨ angigkeitskonflikten verwendet, spricht man von prim¨ aren PS. Sie finden zus¨ atzlich Anwendung in der Berechnung von Selektionszust¨ anden nicht annotierter Mappings als sekund¨ are PS. In den Phasen 2 und 3 (s. Abschnitt 4.7.1) der SZ-Berechnung werden prim¨ are und sekund¨ are PS eingesetzt, um die Konsistenz eines Mapping-Modells wiederherzustellen. Aufl¨ osung von Abh¨ angigkeitskonflikten Ein Abh¨ angigkeitskonflikt tritt auf, wenn ein Mapping Amit positivem Selektionszustand von einem Mapping mit negativem Selektionszustand Babh¨ angt (A⇐Bin der in Abschnitt 3.3 vereinbarten Notation). Um diese Konsistenzverletzung aufzul¨ osen, wurden die folgenden zwei prim¨ aren Propagationsstrategien (PS) f¨ ur Phase 2 ausgearbeitet (vgl. auch Abschnitt 3.3.3 und Abbildung 4.25): •Vorw¨ artspropagation: Die Konsistenz wird wiederhergestellt, indem das positiv annotierte Mapping A, welches von Babh¨ angt, mit einem k¨ unstlichen, negativen Selektionszustand (suppressed) versehen wird. Die Propagation des Selektionszustands erfolgt also in Richtung der Abh¨ angigkeit und l¨ ost Abh¨ angigkeitskonflikte ausschließlich durch Negativierung von Selektionszust¨ anden. •R¨ uckw¨ artspropagation: Der positive Selektionszustand des Mappings Awird entgegen der Richtung der Abh¨ angigkeit zum Mapping Bpropagiert. Bwird also mit einem k¨ unstlichen, positiven Selektionszustand (enforced) versehen. Die Anwendung dieser Strategie hat die ausschließliche Positivierung betroffener Selektionszust¨ ande zur Folge. A B Abhängigkeitskonflikt: Ein Mapping A mit Zustand active hängt von einem Mapping B mit Zustand inactive ab. Vorwärtspropagation: Mapping B ändert den Zustand von Mapping A zu suppressed. Rückwärtspropagation: Mapping A ändert den Zustand von Mapping B zu enforced. ABB A Abbildung 4.25: Prim¨ are Propagationstrategien werden angewendet, um Abh¨ angigkeitskonflikte innerhalb des Mapping-Modells aufzul¨ osen. Selektionszustand nicht annotierter Mappings Sekund¨ are PS kommen in Phase 3 zum Einsatz: Zur Wahrung der Konsistenz sowie zur Vermeidung redundanter Annotationen sollen die Selektionszust¨ ande nicht annotierter Mappings bestimmt werden, ohne die formulierten Konsistenzbedingungen zu verletzen. Abbildung 4.26 zeigt, dass wiederum die VP und RP, diesmal als sekund¨ are Propagationsstrategien, angewendet werden k¨ onnen: •Vorw¨ artspropagation: Der Selektionszustand eines nicht annotierten Elements B kann durch den Selektionszustand eines Mappings Cbestimmt werden, falls B⇐C gilt. Bbekommt den Selektionszustand suppressed oder enforced, je nach dem ob Csich in einem negativen oder positiven Selektionszustand befindet, zugewiesen. Es kann also sowohl eine Positivierung, als auch eine Negativierung erfolgen; ist beides m¨ oglich, wird die Negativierung bevorzugt. 97 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien •R¨ uckw¨ artspropagation: Wiederum sei Bein nicht annotiertes Mapping. Falls es ein Mapping Agibt, welches von Babh¨ angt (A⇐B), so wird Azur Bestimmung des Selektionszustands von Bherangezogen, was wiederum sowohl zu einer Positivierung als auch einer Negativierung von Selektionszust¨ anden f¨ uhren kann. Bwird suppressed, falls Anegativ, bzw. enforced, falls Apositiv annotiert ist. Die Positivierung von Zust¨ anden wird gegen¨ uber der Negativierung bevorzugt. Die sekund¨ are PS kann unabh¨ angig von der prim¨ aren PS festgelegt werden. Desweiteren ist bei nicht annotierten Elementen eine Kombination durch Priorisierung der beiden Strategien denkbar: Beispielsweise kann zun¨ achst die Vorw¨ artspropagation angewendet werden; ist kein Element verf¨ ugbar, von dem das nicht annotierte Mapping abh¨ angt, kann schließlich die R¨ uckw¨ artspropagation herangezogen werden. A B Nicht annotierte Elemente: Der Selektionszustand von B kann entweder von einem abhängigen (C) oder einem Element, das selbst von B abhängt (A), abgeleitet werden. Vorwärtspropagation: Der Selektionszustand von C bestimmt den Selektionszustand von B. Rückwärtspropagation: Der Selektionszustand von A bestimmt den Selektionszustand von B. C C A C C A A B B B B Abbildung 4.26: Anwendung sekund¨ arer Propagationsstrategien, um die Selektionszust¨ ande nicht annotierter Mappings unter Wahrung der Konsistenz abzuleiten. Implementierung im F2DMM-Metamodell Die Unabh¨ angigkeit von prim¨ arer und sekund¨ arer Propagationsstrategie begr¨ undet die Trennung dieser beiden Konzepte im F2DMM-Metamodell. F¨ ur jede der beiden Strategien ist ein Ecore-Aufz¨ ahlungstyp definiert: W¨ ahrend DependencyConflictStrategy die prim¨ aren Strategien forward und reverse, sowie die Option ignore enth¨ alt, beinhaltet MissingAnnotationStrategy die kombinierten Strategien forwardThenReverse bzw. reverseThenForward f¨ ur sekund¨ are PS (s. obige Ausf¨ uhrungen). Jedem Mapping-Modell ist eine Instanz von PropagationStrategy zugeordnet, die jeweils einen der beiden Enumerationstypen als Attribut enth¨ alt (s. Abbildung 4.27). Zus¨ atzliche Attribute und Operationen PropagationStrategy enth¨ alt zudem zwei boolesche Attribute, die wie folgt definiert sind, um das Verhalten der PS zu beeinflussen: •transitiveConflictResolution: Ist der Wahrheitswert true angegeben, so verhalten sich bei der Anwendung von Propagationsstrategien die Selektionszust¨ ande suppressed und enforced wie inactive bzw. active. Insbesondere gilt f¨ ur die Voraussetzungen A⇐B und B⇐Cder Schluss A⇐C. •includeIncomplete: Gibt an, ob Mappings, die sich im finalen Selektionszustand incomplete befinden, in Produkten enthalten sein sollen oder nicht. Zus¨ atzlich enth¨ alt die Klasse PropagationStrategy drei Methoden, die zur Identifikation und Elimination von Abh¨ angigkeitsbzw. Ausschlusskonflikten verwendet werden: 98 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Abbildung 4.27: Ecore-Klassendiagramm, das den Zusammenhang zwischen den Propagationsstrategien auf Metamodell-Ebene darstellt. •isIncluded(SelectionState) entscheidet, ob ein Mapping mit ¨ ubergebenem Selektionszustand in einem abgeleiteten Produkt enthalten w¨ are. Der R¨ uckgabewert ist true f¨ ur die Selektionszust¨ ande active,enforced und surrogated und negativ f¨ ur inactive,suppressed und corrupted. F¨ ur den SZ incomplete entspricht der R¨ uckgabewert der Option includeIncomplete. •canSuppress(SelectionState) bestimmt, ob ein Mapping mit ¨ ubergebenem Selektionszustand bei einem anderen Mapping den Selektionszustand suppressed bewirken kann. Dies ist der Fall, wenn der gegebene SZ entweder inactive ist, bzw. suppressed oder overruled, falls die Option transitiveConflictResolution gesetzt ist. •canEnforce(SelectionState) pr¨ uft hingegen, ob ein gegebener Selektionszustand die Negativierung eines anderen bewirken kann. Der R¨ uckgabewert ist true, wenn der Selektionszustand active, bei gesetzter Option transitiveConflictResolution auch enforced oder surrogated, ist. 4.7.5 Phasen 1 bis 5: Identifikation und Aufl¨ osung von Konflikten In Phase 0 werden Abh¨ angigkeitsund Ausschlussbeziehungen zwischen Mappings vorberechnet. Diese dienen der Identifikation von Abh¨ angigkeitsbzw. Ausschlusskonflikten, um diese anschließend durch Anwendung einer Propagationsstrategie aufl¨ osen zu k¨ onnen. Im kleinen Invalidierungszyklus (s. Abschnitt 4.7.6) wird innerhalb f¨ ur jedes Mapping ein konsistenter Selektionszustand in mehreren Phasen berechnet. Abbildung 4.28 zeigt m¨ ogliche Selektionszust¨ ande eines Annotatable und weist den m¨ oglichen ¨ Uberg¨ angen zwischen ihnen Phasen zu, die im Folgenden genauer beschrieben werden. Phase 1: Bestimmung des initialen Selektionszustands Der initiale Selektionszustand (initialSelectionState) eines durch Annotatable repr¨ asentierten Mappings (vgl. Abbildung 4.24) ergibt sich unmittelbar durch Auswertung seines assoziierten Feature-Ausdrucks. 99 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien inactive active incomplete suppressed enforced surrogated corrupted overruled (1) (1) (2) (2) (4) (5) (4) (5) (3) (3) (0) (0) Abbildung 4.28: M¨ ogliche ¨ Uberg¨ ange zwischen Selektionszust¨ anden eines Mappings, den jeweiligen Phasen zugeordnet. Selbst¨ uberg¨ ange werden nicht dargestellt. Phase 2: Aufl¨ osung von Abh¨ angigkeitskonflikten Befindet sich ein Mapping (im Folgenden Kontext-Mapping) in einem der initialen Selektionszust¨ ande active oder inactive, muss auf Verst¨ oße gegen vorberechnete Abh¨ angigkeiten gepr¨ uft werden. Hierbei wird je nach Selektionszustand (SZ) und prim¨ arer Propagationsstrategie (PS) unterschiedlich vorgegangen: •SZ active und prim¨ are PS forward: Die Selektionszust¨ ande der ¨ uber requires assoziierten Mappings werden ermittelt. Ist eines dieser Mappings in der Lage, das KontextMapping zu negativieren (canSuppress()), so wird der Selektionszustand des KontextElements zu suppressed ge¨ andert. Zus¨ atzlich wird das referenzierte Mapping in die Menge suppressedBy aufgenommen (vgl. auch Quelltext 4.11). 1if (state == SelectionState.ACTIVE 2&& dcs == DependencyConflictStrategy.FORWARD) { 3for (MappingRequirement required : getRequires()) { 4Annotatable target = required.getTarget(); 5if (ps.canSuppress(target.getSelectionState())) { 6state = SelectionState.SUPPRESSED; 7getSuppressedBy().add(target); 8} 9} 10 } Quelltext 4.11: Auszug aus der Methode updateSelectionState() der abstrakten Klasse AnnotatableImpl, in dem die prim¨ are Propagationsstrategie forward durchgesetzt wird. •SZ inactive und prim¨ are PS reverse: Iteriert wird ¨ uber die von requiredBy erreichten Mappings. Ist ein referenziertes Mapping in der Lage, das Kontext-Mapping zu positivieren (canEnforce()), wird der Selektionszustand des Kontext-Mappings auf enforced gesetzt und das referenzierte Mapping in enforcedBy aufgenommen. 100 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Phase 3: Nicht annotierte Mappings Befindet sich ein Mapping im initialen Selektionszustand incomplete, ist die sekund¨ are PS von Bedeutung: •forward: Es wird ¨ uber alle ¨ uber requires assoziierten Mappings iteriert. Befindet sich eines der referenzierten Mappings nicht im Zustand incomplete, wird dieser je nach Selektionszustand suppressedBy bzw. enforcedBy angef¨ ugt. Ist die Menge suppressedBy nach der letzten Iteration nicht leer, so wird der Selektionszustand des KontextMappings entsprechend auf suppressed ge¨ andert. Ansonsten kann die Positivierung im Falle einer nicht leeren enforcedBy-Menge erfolgen. •reverse: Wie forward, mit dem Unterschied, dass ¨ uber die ¨ uber requiredBy referenzierten Mappings iteriert wird. Außerdem wird die Menge enforcedBy gegen¨ uber suppressedBy bevorzugt. •forwardThenReverse: Zun¨ achst wie forward. Befindet sich das Kontext-Mapping danach immer noch im Selektionszustand incomplete, so wird wie bei reverse fortgefahren. •reverseThenForward: Nur wenn sich das Kontext-Mapping nach Anwendung der reverse-Strategie immer noch im Zustand incomplete befindet, wird forward angewendet. Phase 4: Ausschlusskonflikte Sich gegenseitig ausschließende Mappings wurden bei der Vorberechnung m¨ oglicher Konflikte in Phase 0 ¨ uber die Referenzen excludes bzw. excludedBy vorgemerkt. Befindet sich das Kontext-Mapping nach Anwendung der PS in einem positiven Selektionszustand, muss noch gepr¨ uft werden, ob dieser nicht durch ein eventuell ebenfalls positiv annotiertes, in excludedBy enthaltenes Mapping, negativiert werden muss. Ist dies der Fall, wird der SZ des Kontext-Mappings auf overruled gesetzt sowie das ausschließende Mapping in overruledBy aufgenommen (vgl. Quelltext 4.12). 1if (ps.isIncluded(state)) { 2for (Annotatable excluding : getExcludedBy()) { 3if (ps.isIncluded(excluding.getSelectionState())) { 4state = SelectionState.OVERRULED; 5getOverruledBy().add(excluding); 6} 7} 8} Quelltext 4.12: Auszug aus der Methode updateSelectionState() von AnnotatableImpl, wodurch Ausschlusskonflikte ber¨ ucksichtigt werden. Phase 5: Surrogate W¨ ahrend f¨ ur Attributund Containment-Mappings der finale Selektionszustand an dieser Stelle feststeht, muss bei Referenz-Mappings noch gepr¨ uft werden, inwiefern bei der Vorberechnung ermittelte Surrogate den Zustand des Kontext-Mappings weiter beeinflussen k¨ onnen: Der Selektionszustand surrogated ist f¨ ur Mappings reserviert, die durch Anwendung von Propagationsstrategien negativiert wurden (sich also im SZ suppressed befinden), jedoch nach der Auswertung ihrer Surrogat-Ausdr¨ ucke mindestens ein Mapping mit positiven Selektionszustand vorweisen k¨ onnen, welches das abh¨ angige Element als Referenzziel ersetzen kann. Quelltext 4.13 zeigt den entsprechenden Quelltextausschnitt. 101 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien 1if (state == SelectionState.SUPPRESSED && getReferenceMappingDescription() instanceof InternalReferenceMappingDescription) { 2InternalReferenceMappingDescription internalRmd = (InternalReferenceMappingDescription) getReferenceMappingDescription(); 3for (MappingRequirement required : internalRmd.getReferencedMapping().getRequires()) { 4for (EObject surrObj : required.getSurrogates()) { 5ContainmentMapping cm = getMappingModel().getContainmentMapping(surrObj); 6if (cm != null && ps.isIncluded(cm.getSelectionState())) { 7getSurrogateCandidates().add(cm); 8state = SelectionState.SURROGATED; 9} 10 } 11 } 12 } Quelltext 4.13: Auszug aus der ¨ uberschriebenen Methode updateSelectionState() der Klasse ReferenceMappingImpl, in dem auf verf¨ ugbare Surrogate gepr¨ uft wird. Zur Identifikation von Surrogaten erfolgt eine Iteration ¨ uber die vom untergeordneten MappingRequirement bereitgestellten surrogates, welche auf je ein DM-Element verweisen. Kann im Mapping-Modell ein Containment-Mapping identifiziert werden, welches dieses abbildet und einen positiven SZ hat (Z. 5 und 6), wird es als Surrogat-Kandidat aufgenommen und der Selektionszustand des Kontext-Mappings auf surrogated gesetzt (Z. 7 und 8). Besonderheit: Surrogate und Ausschlusskonflikte Die beiden zuletzt erw¨ ahnten Konzepte Ausschlusskonflikte und Surrogate erg¨ anzen sich in der bisher vorgestellten Implementierung noch nicht gewinnbringend: An einigen Stellen ist es erforderlich, dass AlternativenMappings, die die Rolle eines aufgrund wechselseitigen Ausschlusses als overruled gekennzeichneten Kern-Mappings ¨ ubernehmen, als Surrogat-Kandidaten vorgeschlagen werden k¨ onnen. Um dies zu realisieren, wurden in der tats¨ achlichen Implementierung von ReferenceMapping.updateSelectionState() folgende Erz¨ anzungen durchgef¨ uhrt: 1. Iteriere ¨ uber alle ¨ uber excludes erreichbaren, konkurrierenden Referenz-Mappings. 2. Pr¨ ufe, ob es sich um ein implizites Referenz-Mapping handelt, und bestimme in diesem Fall dessen referenziertes Containment-Mapping. Ansonsten breche ab. Der Selektionszustand des konkurrierenden Mappings spielt hierbei keine Rolle. 3. F¨ uge das referenzierte Containment-Mapping der Menge surrogateCandidates des Kontext-Mappings hinzu, falls sein Selektionszustand positiv ist. Ein Beispiel, in dem das verbesserte Zusammenspiel zwischen Surrogaten und Ausschlusskonflikten greift, wird in Abschnitt 5.3.6 gegeben. 4.7.6 Invalidierungszyklen Ein Mapping-Modell ist st¨ andigen Manipulationen unterworfen: Feature-Ausdr¨ ucke k¨ onnen vom Anwender erzeugt, ge¨ andert oder gel¨ oscht werden, was eine ¨ Anderung von SZ einzelner Mappings zur Folge haben kann. Die Struktur des Mapping-Modells kann sich ¨ andern, sei es durch ¨ Anderungen am Kern-DM oder durch das Hinzuf¨ ugen von Alternativen-Mappings. 102 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Weitere m¨ ogliche ¨ Anderungen betreffen Featuremodell und -konfiguration. All diese Manipulationen haben Auswirkungen auf den globalen Zustand des Mapping-Modells, dessen Mappings sich wechselseitig beeinflussen. Erforderlich ist also ein Konzept zur effektiven Neuberechnung des Modellzustands, insbesondere der nicht-persistenten Referenzen zwischen Mappings sowie deren Selektionszust¨ ande. Im F2DMM-Editor wird hierzu zwischen einem großen und einem kleinen Invalidierungszyklus unterschieden: Großer Invalidierungszyklus Tritt bei ¨ Anderungen innerhalb der referenzierten Modelle (SDIRL,DM,FM oder FK), beim Einf¨ ugen von Alternativen, sowie beim erstmaligen Laden eines Mappings ein. Er beinhaltet folgende Aktionen: •Aufruf der dismiss()-Methode auf dem Mapping-Modell, welche die Ergebnisse aller Vorberechnungen verwirft. Dies betrifft neben den transienten Referenzen auch s¨ amtliche vorberechnete Surrogate. •Synchronisation von FM und FK (vgl. Abschnitt 4.2.4). •Synchronisation von MM und DM, um die strukturelle Nachbildung des ersteren durch das letztere sicherzustellen (s. Abschnitt 4.9.1). •Aufruf der prepare()-Methode auf dem Mapping-Modell, welche zur rekursiven Vorberechnung von Abh¨ angkeiten und Surrogaten (Phase 0) f¨ uhrt. Der große Invalidierungszyklus unterst¨ utzt neben seiner globalen Anwendung auch die Invalidierung einzelner Teilb¨ aume des Mapping-Modells, wodurch der Vorgang merkbar beschleunigt werden kann. Die inkrementelle Invalidierung wird etwa beim Einf¨ ugen von AlternativenMappings eingesetzt: Der große Invalidierungszyklus wird dabei nicht auf dem gesamten Mapping-Modell, sondern auf dem Teilbaum, der das eingef¨ ugte Alternativen-Mapping unmittelbar beinhaltet, durchgef¨ uhrt. Zus¨ atzlich erfolgt ein Aufruf von inversePrepare: Abh¨ angigkeiten werden hierbei partiell in entgegengesetzte Richtung neu berechnet. Effektiv entfallen hier s¨ amtliche Neuberechnungen von Abh¨ angigkeiten zwischen Elementen, die bereits vor dem Einf¨ ugen der Alternative im Mapping-Modell vorhanden waren. Kleiner Invalidierungszyklus Tritt ein, wenn sich ein Feature-Ausdruck ¨ andert, eine neue Featurekonfiguration geladen oder die Propagationsstrategie angepasst wird, sowie beim erstmaligen oder erneuten Laden nach dem großen Invalidierungszyklus. •Aufruf von invalidate() auf dem Mapping-Modell, was zum rekursiven Aufruf derselben Methode auf allen Mappings f¨ uhrt. Hierbei werden zun¨ achst die Mengen enforces,suppresses und overrules geleert. •Neuberechnung der Selektionszust¨ ande aller Mappings. Hierzu implementiert die Klasse F2DMappingModel die Methode updateAll(), die wiederum f¨ ur jedes Mapping updateSelectionState() aufruft, in der die in Phase 1 bis 5 beschriebenen Berechnungen durchgef¨ uhrt werden. Aufgrund transitiver Abh¨ angigkeiten erfolgt die Neuberechnung iterativ, bis sich keine ¨ Anderungen der SZ mehr ergeben30. •Update der Baum-Ansicht des Editors, um die ¨ Anderungen sichtbar zu machen. 30Zyklische Abh¨ angigkeiten k¨ onnten sich an dieser Stelle in einer Endlosschleife niederschlagen. In der aktuellen Implementierung werden Zyklen weder erkannt noch vermieden; stattdessen ist in updateAll eine Abbruchbedingung formuliert, die zutrifft, sobald sich die Menge derjenigen Mappings, deren Selektionszustand in einer Iteration ge¨ andert wurde, mehrmals nicht verkleinert. 103 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien 4.8 Ableitung von Produkten Der in Abschnitt 3.4.4 vorgeschlagene MDPLE-Prozess sieht die Ableitung eines konfigurierten Dom¨ anenmodells bzw. eines Produkts aus einer gew¨ ahlten Featurekonfiguration vor. Zieht man ausschließlich negative Variabilit¨ at in Betracht, besteht das Ableiten eines Produkts im Entfernen aller Artefakte aus dem Multivarianten-DM, deren annotierte Feature-Ausdr¨ ucke als negativ evaluieren. Im F2DMM-Editor ist die Produktableitung als Modelltransformation auf Java-Basis (vgl. Abschnitt 2.7.1) realisiert. In diesem Abschnitt werden außerdem die Konzepte der Alternativen,Surrogate und abgeleiteter Reparaturaktionen w¨ ahrend der Produktgenerierung ber¨ ucksichtigt. 4.8.1 Notwendige Voraussetzungen f¨ ur die Ableitung von wohlgeformten Produkten Bevor auf die eigentliche Transformation eingegangen wird, soll diskutiert werden, welche Mindestvoraussetzungen erf¨ ullt sein m¨ ussen, damit ein wohlgeformtes Produkt entsteht. Die Annahme hierbei ist, dass alle beteiligten Dom¨ anenmodelle, das Kern- (bzw. Multivarianten- )DM, sowie die f¨ ur externe Alternativen-Mappings herangezogenen Teildom¨ anenmodelle, selbst syntaktisch wie semantisch wohlgeformt sind31. •Es muss eine Featurekonfiguration (FK) geladen sein, die konform zum Featuremodell ist, das die Produktlinie beschreibt. •Die geladene FK muss valide sein (vgl. Abschnitt 4.2.2) und darf insbesondere keine Features beinhalten, die sich im Selektionszustand pending befinden. •Die prim¨ are PS darf nicht ignore sein, und die Option transitiveConflictResolution muss gew¨ ahlt sein. Dies stellt die konsistente Anwendung der Propagationsstrategien bei der Produktableitung sicher. •Feature-Ausdr¨ ucke d¨ urfen keine Feature-Referenzen enthalten, welche sich auf nicht existierende Features beziehen. Ansonsten kann der Selektionszustand von betroffenen Features nicht ermittelt werden. Heidenreich [28] definiert eine entsprechende Wohlgeformtheitsbedingung MM-Existing-Feature. •Das Mapping-Modell muss in seinen Kern-Mappings strukturell synchron mit dem KernDom¨ anenmodell sein. •Alternativen-Mappings, die sich auf externe Ressourcen beziehen, m¨ ussen auf vorhandene Modell-Elemente verweisen. Diese und die vorhergehende Voraussetzung entsprechen der Wohlgeformtheitsbedingung MM-Existing-ModelElement von Heidenreich [28]. Die Pr¨ ufung dieser Voraussetzungen ist zun¨ achst die Aufgabe der F2DMMModellvalidierung, welche auf dem EMF Validation Framework aufbaut (vgl. Abschnitt 4.9.3). Die Erf¨ ullung von Voraussetzungen, welche nicht von dieser abgedeckt werden, wird vor dem Ableiten des Produkts im Editor gepr¨ uft. Die strukturelle Synchronit¨ at von Kern-Mappings mit dem Kern-Dom¨ anenmodell wird durch das DM/MMSynchronisationsmodul (s. Abschnitt 4.9.1) sichergestellt. 31Heidenreich [28] formuliert auch hierf¨ ur Wohlgeformtheitsbedingungen (SM-Multiplicity,SM-Typing,SMSemantics). Hierauf wird im vorliegenden Ansatz verzichtet, da stattdessen die Annahme eines wohlgeformten, Ecore-basierten solution space model zur Voraussetzung erhoben wird. 104 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Im F2DMM-Editor ist f¨ ur die Ableitung eines konfigurierten Dom¨ anenmodells der Kontextmen¨ u-Eintrag Derive Product vorgesehen. Wird dieser ausgew¨ ahlt, erfolgt zun¨ achst ein großer und ein kleiner Invalidierungsschritt (vgl. vorhergehender Abschnitt) sowie die Pr¨ ufung der eben definierten Voraussetzungen. Sind diese erf¨ ullt, wird vom Anwender die Auswahl einer Ressource f¨ ur das abgeleitete Produkt gefordert und die Transformation durchgef¨ uhrt. 4.8.2 Anpassung des EMF-Copiers f¨ ur die Basistransformation Die Modelltransformation vom allgemeinen zum konfigurierten Dom¨ anenmodell soll in diesem Unterabschnitt rein destruktiv verstanden werden: Es erfolgt eine Kopie des MultivariantenDom¨ anenmodells, wobei alle DM-Elemente, f¨ ur die ein Mapping mit negativem Selektionszustand vorliegt, entfallen. Die Transformation ist als Ableitung von der Klasse EcoreUtil.Copier implementiert, die ¨ uber die Methode EObject copy(EObject) die Erzeugung einer exakten Kopie eines EObject unter Ber¨ ucksichtigung der referenziellen Integrit¨ at32 realisiert. Copier erbt zus¨ atzlich von HashMap<EObject, EObject>: Nach dem Kopieren eines Elements wird ein Eintrag <Original, Kopie>in die Map eingef¨ ugt. + copy(EObject): EObject + copyAll(EObject): EObject + copyReferences() : EObject # createCopy(EObject): EObject # copyContainment(EReference, EObject, EObject) # copyAttribute(EAttribute, EObject, EObject) # copyReference(EReference, EObject, EObject) org.eclipse.emf.ecore.util EcoreUtil.Copier java.util HashMap KV HashMap<EObject, EObject> <<bind>> K::EObject <<bind>> V::EObject + ConditionalCopier(F2DMappingModel, PropagationStrategy, SurrogateResolutionStrategy) - copyAlternativeContainments(EObject, EObject) - copyAlternativeAttributes(EObject, EObject) - copyAlternativeReferences() - isIncluded(EObject): boolean - resolveReferenceMapping(ReferenceMapping): EObject de.ubt.ai1.f2dmm.copier ConditionalCopier de.ubt.ai1.f2dmm F2DMappingModel PropagationStrategy <<interface>> SurrogateResolutionStrategy + resolve(ReferenceMapping): ContainmentMapping mappingModel ps srs 0..1 0..1 0..1 TakeFirstSurrogateResolutionStrategy IgnoreSurrogateResolutionStrategy InteractiveSurrogateResolutionStrategy Abbildung 4.29: UML-Klassendiagramm, welches den von EcoreUtil.Copier erbenden ConditionalCopier als Transformationsklasse darstellt. Alle von Copier definierten Objektmethoden werden von ConditionalCopier ¨ uberschrieben (nicht abgebildet). Das Mapping-Modell, die entsprechende Propagationsstrategie, sowie eine Stategie zur Aufl¨ osung von Surrogat-Mappings (SurrogateResolutionStrategy, s. Abschnitt 4.8.4) werden von ihm referenziert. Abbildung 4.29 f¨ uhrt die Klasse ConditionalCopier als Spezialisierung des EMF-Copiers ein. Sie beinhaltet die Methode isIncluded(EObject), welche pr¨ uft, ob ein beliebiges 32Alle Referenzen der Kopie verweisen nicht auf das Original, sondern auf das entsprechende Element der Kopie [48, Kapitel 16.4]. 105 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien An dieser Stelle sei darauf hingewiesen, dass die Konsistenzpr¨ ufung nicht immer vollst¨ andig ist: Beispielsweise wird die Kardinalit¨ at von Features in der vorliegenden Implementierung nicht ¨ uberpr¨ uft: Eine Feature-Referenz k¨ onnte sich ¨ uber einen Index auf ein Feature beziehen, das im aktualisierten FM aufgrund neuer Einschr¨ ankungen bez¨ uglich der Kardinalit¨ at nicht mehr existieren darf. Die Wiederherstellung der Synchronit¨ at ist in solchen F¨ allen dem Anwender selbst ¨ uberlassen; er wird jedoch bei der Identifikation von Konsistenzverletzungen von der Modellvalidierung unterst¨ utzt. 4.9.3 Zus¨ atzliche Konsistenzpr¨ ufung mittels EMF-Validierung Aus den zuvor genannten Gr¨ unden, sowie um bei der Ableitung von Produkten einen konsistenten Zustand zu garantieren, wurde in den F2DMM-Editor eine auf dem EMF Validation Framework (vgl. Abschnitt 2.4) basierende Validierung integriert. Der Anwender kann optional die Live-Validierung aktivieren, welche die Laufzeit unter Umst¨ anden verschlechtert. Die Batch-Validierung findet beim Laden eines Mapping-Modells, durch Auswahl des entsprechenden Kontextmen¨ u-Eintrags, sowie vor der Produkt-Ableitung statt. Zun¨ achst werden exemplarisch drei Modell-Constraints erl¨ autert, bevor eine vollst¨ andige Auflistung aller mit Hilfe des Frameworks formulierten Konsistenzbedingungen erfolgt. Validit¨ at von Feature-Referenzen Feature-Referenzen wurden im Abschnitt ¨ uber FEL (4.4) als die Verkn¨ upfung vom Mappingzum Featuremodell und evtl. einer geladenen Featurekonfiguration ausgemacht. Um g¨ ultig zu sein, muss sich eine Feature-Referenz auf ein existierendes Feature aus dem FM beziehen. Ist zus¨ atzlich eine FK geladen, darf die Menge configuredFeatures einer FeatureReference ebenfalls nicht leer sein. Aus diesen beiden Bedingungen l¨ asst sich ein Constraint formulieren. ExistingFeatureRefConstraint bezieht sich auf Instanzen von Annotatable und pr¨ uft rekursiv die G¨ ultigkeit von Feature-Ausdr¨ ucken: •Eine Feature-Referenz ist konsistent, wenn die Referenz modeledFeature auf ein existierendes Feature aus dem Featuremodell zeigt. Ist eine Featurekonfiguration geladen, darf configuredFeatures zus¨ atzlich nicht die leere Menge ergeben. •Boolesche Konstanten sind immer valide gegen¨ uber dieser Bedingung. •Boolesche Verkn¨ upfungen sind nur dann valide, wenn ihre Operanden valide sind. Der Constraint hat die Fehlerstufe Error. Wie bei allen auf Feature-Ausdr¨ ucken bezogenen Constraints besteht die M¨ oglichkeit der erneuten Annotation des entsprechenden Mappings durch einen Doppelklick auf den vom EMF Validation Framework in der Problems-Ansicht generierten Marker. Validit¨ at von Attribut-Ausdr¨ ucken Die Constraints IllegalAttributePatternConstraint und IncompatibleAttributeValueConstraint, beide mit der Fehlerstufe Error, beziehen sich auf Attribut-Ausdr¨ ucke. Letztere kommen im Mapping-Modell innerhalb von PatternAttributeMappingDescriptions zum Einsatz, um den Wert von Attributen abgeleiteter Produkte als abh¨ angig von der Auspr¨ agung eines Attributs der Featurekonfiguration zu definieren. Unter folgenden Bedingungen wird bei der Validierung durch die genannten Constraints ein Fehler ausgegeben: 112 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien •Nicht wohlgeformtes Attribut-Pattern: Der innerhalb eines durch ”#{“ und ”}“ begrenzten Attribut-Constraints stehende Ausdruck enth¨ alt entweder Syntaxfehler oder verweist auf ein nicht vorhandenes Feature oder Attribut. •Nichtkompatibler Attributwert: Der nach dem Auswerten einer Pattern-basierten Attribut-Mapping-Beschreibung entstehende String l¨ asst sich nicht ¨ uber den EcoreAdapter-Factory-Mechanismus35 in eine Instanz des dem Attribut entsprechenden Datentyps konvertieren. Die beiden auf Attribut-Ausdr¨ ucke bezogenen Constraints unterscheiden sich von allen anderen Validierungsconstraints dahingehend, dass durch einen Doppelklick auf diese sich nicht das Eingabefenster f¨ ur Feature-Ausdr¨ ucke (s. n¨ achster Abschnitt), sondern die entsprechende Seite des Alternativen-Wizards ¨ offnet (vgl. Abschnitt 4.6.2), in der das betroffene MappingPattern zur Korrektur eingegeben werden kann. Erf¨ ullbarkeit von Feature-Ausdr¨ ucken Ebenfalls von der Modellvalidierung ¨ uberpr¨ uft wird die Erf¨ ullbarkeit von Feature-Ausdr¨ ucken. Ein Feature-Ausdruck gilt genau dann als erf¨ ullbar, wenn mindestens eine m¨ ogliche Featurekonfiguration existiert, f¨ ur den dieser den Wert active annimmt36. Der Modellconstraint SatisfiableExprConstraint setzt diese Idee folgendermaßen f¨ ur jeden Feature-Ausdruck um (Fehlerstufe Error, vgl. auch Quelltext 4.14): 1. Zun¨ achst werden freie Variablen identifiziert: Dies sind alle durch den gesamten Ausdruck referenzierten Features der aktuellen FK. Jede freie Variable bekommt einen Index zugewiesen. 2. Zum Test auf Erf¨ ullbarkeit wird eine Kopie der aktuellen Featurekonfiguration angelegt und dem Feature-Ausdruck als Konfiguration mitgeteilt. 3. Ein Bitvektor mit einer L¨ ange n, die sich durch die Anzahl freier Variablen ergibt, wird erzeugt und jeder Eintrag mit 0 initialisiert. 4. F¨ ur jede der 2nm¨ oglichen Permutationen des Bitvektors erfolgt nun die Auswertung: a) Zun¨ achst wird die Variablenbelegung der kopierten FK entsprechend deren Indices im Bitvektor angepasst (selected, falls indiziertes Bit 1, sonst unselected). b) Es wird gepr¨ uft, ob die aktuelle Belegung g¨ ultig ist: Als kernel markierte Features m¨ ussen selected sein, requiresund excludes-Kanten d¨ urfen sich nicht widersprechen. c) Ist die Belegung g¨ ultig, wird der Feature-Ausdruck ausgewertet und der resultierende Selektionszustand festgehalten. 5. Ergibt die Auswertung des gesamten Feature-Ausdrucks zumindest f¨ ur eine Belegung den Wert active, so ist der Ausdruck erf¨ ullbar. 35Der Aufruf EcoreUtil.createFromString() schl¨ agt nach ¨ Ubergabe der String-Repr¨ asentation und des Attribut-Datentypen fehl. 36In verwandten Ans¨ atzen werden kommen hierf¨ ur h¨ aufig sog. SAT-Solver zum Einsatz, die die Erf¨ ullbarkeit (vgl. engl. satsifiability) boolescher Ausdr¨ ucke auf Basis eines Logik-Kalk¨ uls unterst¨ utzen [40]. 113 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien 1private boolean isSatisfiable(Annotatable annotatable) { 2FeatureExpr expr = EcoreUtil.copy(annotatable.getFeatureExpr()); 3Root featureConf = EcoreUtil.copy(annotatable.getMappingModel() .getCurrentFeatureConfiguration()); 4expr.applyFeatureModel(annotatable.getMappingModel().getFeatureModel()); 5expr.applyFeatureConfiguration(featureConf); 6 7List<Feature> freeVariables = new ArrayList<Feature>(getFreeVariables(expr)); 8long nFree = freeVariables.size(); 9long permSize = 1L << nFree; 10 boolean satisfiable = false; 11 12 for (long permutation = 0; permutation < permSize; permutation++) { 13 applyValues(freeVariables, permutation); 14 expr.invalidate(); 15 if (isConfigurationValid(freeVariables)) { 16 if (expr.getState() == FELState.ACTIVE) { 17 satisfiable = true; 18 break; 19 } 20 } 21 } 22 23 return satisfiable; 24 } Quelltext 4.14: Die Methode isSatisfiable von SatisfiableExprConstraint pr¨ uft die Erf¨ ullbarkeit von Feature-Ausdr¨ ucken durch Permutation freier Variablen. Folgende weitere Constraints, jeweils auf der Kontextklasse Annotatable definiert, stellen die Wohlgeformtheit des Mapping-Modells sicher, indem sie die beschriebenen Konsistenzverletzungen identifizieren: ExistingAttributeRefConstraint Bezieht sich auf Attribut-Constraints innerhalb von Feature-Referenzen und stellt sicher, dass diese sich auf im Featuremodell existierende Attribute beziehen (Error). DiscouragedWildcardConstraint Das Wildcard-Symbol (*) wird als Index f¨ ur ein Feature verwendet, welches nur in einer Instanz vorkommen darf (Warning). EncouragedWildcardConstraint Kein Index wird an einer Stelle verwendet, wo die Benutzung ein Wildcard-Symbol m¨ oglich w¨ are (Warning). NonTautologicalExprConstraint Ein Feature-Ausdruck ist eine Tautologie: Er liefert f¨ ur jede m¨ ogliche Variablenbelegung den Selektionszustand active (Info). NoSyntaxErrorsConstraint Aufgrund eines Syntaxfehlers in einem annotierten FeatureAusdruck eines Mappings existiert die String-serialisierte Form featureExprStr, jedoch nicht die deserialisierte featureExpr (Error). Zus¨ atzlich wird dies durch den Selektionszustand corrupted hervorgehoben. 114 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien 4.10 Weitere Bedienkonzepte des Mapping-Editors Zum Abschluss des Implementierungsabschnitts werden einige typische Vorg¨ ange w¨ ahrend des Editierens von Mapping-Modellen aus Benutzersicht beleuchtet. Erweiterte Einstellungen betreffen zumeist die grafische Repr¨ asentation des Mappings. 4.10.1 Die F2DMM-Perspektive Der F2DMM-Editor definiert eine eigene Eclipse-Perspektive, die die f¨ ur das Bearbeiten eines Mapping-Modells ben¨ otigten visuellen Elemente anordnet. Abbildung 4.31 zeigt einen Screenshot und markiert die nachfolgend beschriebenen UI-Elemente: Abbildung 4.31: Die F2DMM-Perspektive bei ge¨ offnetem Mapping-Modell. 1. Der Project Explorer stellt wie in der Java-Perspektive die Projektstruktur des Workspace dar. Im Beispiel befindet sich das ge¨ offnete Mapping-Modell zusammen mit einem SDIRL-Dokument im Verzeichnis mappingmodel. 2. Die manuell hinzugef¨ ugte Features-Ansicht stellt das Featuremodell und eine eventuell geladene Featurekonfiguration in zwei Reitern dar. Die Darstellung erfolgt jeweils wie im FMbzw. FK-Editor als Baum. Die Ansicht dient zur ¨ Uberpr¨ ufung des Selektionszustands von Features. Außerdem bietet sie Drag-and-Drop-Unterst¨ utzung zur Annotation von Mappings (s. n¨ achster Abschnitt). 115 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien 3. Die Editor-Ansicht stellt die Hierarchie der Containment-Mappings als Baum dar. Die Symbole eines Mappings entsprechen denen des gemappten Elements, versehen mit einem Overlay, welches den aktuellen Selektionszustand (vgl. Abbildung 4.10) abbildet. Die Beschriftung ergibt sich ebenfalls durch die des gemappten Elements und wird erg¨ anzt durch die textuelle Repr¨ asentation des annotierten Feature-Ausdrucks, falls vorhanden. Die Wiederverwendung des Symbols und der Beschriftung des gemappten Elements wird durch Verwendung des Ecore-Adapter-Factory-Mechanismus [48, Abschnitt 5.6] realisiert (vgl. auch Abschnitt 2.3.1). Ein weiterer Reiter erlaubt die direkte Manipulation des Dom¨ anenmodells, ebenfalls in dessen Baumrepr¨ asentation. 4. Die ebenfalls manuell implementierte Ansicht Mapping Properties stellt Attributund Referenz-Mappings dar, welche dem im Editor selektierten Containment-Mapping untergeordnet sind. Die Darstellung erfolgt tabellarisch: In der ersten Spalte ist der Name der gemappten Referenz bzw. des gemappten Attributs sowie sein Symbol – ebenfalls mit einem durch den Selektionszustand bestimmten Overlay – abgebildet. Die Value-Spalte beinhaltet die String-Repr¨ asentation des jeweiligen Attributwerts oder die Beschriftung des abgebildeten Referenzziels. Die letzte Spalte ist dem annotierenden Feature-Ausdruck vorbehalten. 5. Die Properties-Ansicht wurde von der EMF-Codegenerierung als Teil des Editors erzeugt. Sie stellt Eigenschaften von Elementen dar, die in der Editor-, der Featuresoder der Mapping-Properties-Sicht ausgew¨ ahlt wurden37. Unterabschnitt 4.10.3 besch¨ aftigt sich mit dargestellten Eigenschaften von Mappings. Ebenfalls im unteren Bereich befindet sich der Reiter Problems, der von der Modellvalidierung identifizierte Fehler darstellt. Das FAMILE Dashboard ist Gegenstand von Unterabschnitt 4.10.5. 4.10.2 Annotation von Mappings Bisher wurde die Annotation von Mappings aus Anwendersicht noch nicht genauer beschrieben. Hierf¨ ur stehen drei Mechanismen zur Verf¨ ugung, die zun¨ achst die textuelle Repr¨ asentation eines Feature-Ausdrucks erzeugen, um diesen anschließend vom generierten Parser in seine Modellrepr¨ asentation ¨ ubersetzen zu lassen. Nach dem Erzeugen oder ¨ Andern einer Annotation wird grunds¨ atzlich der kleine Invalidierungszyklus durchgef¨ uhrt (vgl. Abschnitt 4.7.6). Kommt es zu Syntaxfehlern, werden diese dem Anwender sofort mitgeteilt und von der Modellvalidierung als Marker in der Problems-Ansicht eingef¨ ugt. Textuelle Eingabe Durch einen Doppelklick auf ein Mapping in der Editoroder MappingProperties-Ansicht, sowie durch Auswahl des Kontextmen¨ u-Eintrags Annotate Mapping ¨ offnet sich ein Eingabefeld (s. Abbildung 4.32). Ist das Mapping bereits mit einem Feature-Ausdruck versehen, wird dessen bisherige textuelle Repr¨ asentation in den Dialog aufgenommen. Drag-and-Drop Elemente aus der Features-Ansicht k¨ onnen per Drag-and-Drop (DnD) auf ein in der Editoroder Mapping-Properties-Ansicht dargestelltes Mapping gezogen werden. Dabei wird automatisch eine Feature-Referenz erzeugt, die das gew¨ ahlte Feature eindeutig qualifiziert. Im Falle eines mehrfach instanziierbaren Features wird der Index aus der FK, bzw. 37Zur Darstellung der Eigenschaften der beiden manuell definierten Ansichten bedurfte es einer Integration in den von der Eclipse-Plattform bereitgestellten Selection Service [48]. 116 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Abbildung 4.32: Textuelle Eingabe eines Feature-Ausdrucks. das Wildcard-Symbol beim Ziehen aus dem Feature-Model-Reiter, eingef¨ ugt. In der F2DMMPreference-Page (s. Abschnitt 4.10.4) kann eine der folgenden Optionen f¨ ur das Verhalten bei einer bereits vorhandenen Annotation gew¨ ahlt werden: Replace Ein vorhandener Ausdruck wird von der erzeugten Feature-Referenz ersetzt. And Der bisherige wird mit dem erzeugten Ausdruck and-verkn¨ upft. Or Es erfolgt eine or-Verkn¨ upfung. Xor Es erfolgt eine xor-Verkn¨ upfung. Kopieren per Zwischenablage ¨ Ahnlich wie das Erzeugen einer Feature-Referenz per DnD funktionert der integrierte Copy-And-Paste-Mechanismus f¨ ur Features. Durch einen Rechtsklick auf das gew¨ ahlte Element in der Features-Ansicht und Auswahl des Eintrags Copy FEL Expression to Clipboard (Schritt 1 in Abbildung 4.33) wird eine eindeutig qualifizierende Feature-Referenz erzeugt und in der Zwischenablage des Editors gespeichert. Sie kann durch Auswahl eines entsprechenden Kontextmen¨ u-Eintrags als Annotation eines Mappings eingef¨ ugt werden (Schritt 2). Hierbei steht dem Anwender die direkte Auswahl einer der vier im vorhergehenden Absatz definierten Einf¨ ugeoptionen zur Verf¨ ugung. Der Copy-And-PasteAnsatz unterst¨ utzt die Auswahl mehrerer Features in der Features-Ansicht. Abbildung 4.33: Eingabe eines Feature-Ausdrucks per Copy-And-Paste. 117 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien 4.10.3 Das Property-Sheet als Diagnose-Ansicht In Abbildung 4.31 ist die Properties-Ansicht bei einem ge¨ offnetem Mapping-Modell zu sehen: Bei der Generierung des Editors wurde das Generator-Modell [48, Abschnitt 2.4] so angepasst, dass sie ausschließlich nicht-editierbare Felder enth¨ alt. Sie dient also nicht, wie h¨ aufig bei generierten EMF-Baumeditoren, zur Manipulation, sondern vielmehr zur Analyse von ModellEigenschaften. Nach Auswahl eines Mappings ist etwa dessen String-repr¨ asentierte Annotation sowie der aktuelle Selektionszustand dargestellt. Zus¨ atzlich ist unter Original Selection State der initiale Zustand eines Mappings vor der Anwendung von Propagationsstrategien zu sehen. Alle weiteren Eigenschaften sind als Diagnostic Properties zusammengefasst und bieten Hilfestellung, um die Auswirkungen von Propagationsund Surrogat-Mechanismen nachzuvollziehen. Sie stellen die Beziehungen zwischen Annotatable dar (vgl. Abbildung 4.24): •Requires bzw. Required By: Vorberechnete, einund ausgehende Abh¨ angigkeiten des gew¨ ahlten Mappings: Entspricht den jeweils ¨ uber Instanzen der Assoziationsklasse MappingRequirement abgebildeten Referenzzielen. •Excludes bzw. Excluded By: Andere Mappings, die aufgrund vorberechneter Ausschlusskonflikte vom gew¨ ahlten Mapping ausgeschlossen werden, bzw. dieses ausschließen. •Enforces bzw. Enforced By: Andere Mappings, die aufgrund des Selektionszustands des gew¨ ahlten Mappings den Zustand enforced zugewiesen bekommen, bzw. diejenigen Mappings die den Zustand enforced des gew¨ ahlten Mappings bedingen. •Suppresses bzw Suppressed By: Mappings, die aufgrund des gew¨ ahlten Mappings in den Zustand suppressed fallen, bzw. Mappings, die den Zustand suppressed des gew¨ ahlten Mappings bedingen. •Overrules bzw Overruled By: Mappings, die aufgrund des gew¨ ahlten Mappings in den SZ overruled fallen, bzw. Mappings, die diesen SZ f¨ ur das gew¨ ahlte Mapping bedingen. 4.10.4 Anzeigeoptionen auf der F2DMM-Preference-Page Die Eclipse-Plattform [14] stellt f¨ ur Plugins die M¨ oglichkeit der Definition von Workspaceweiten Benutzereinstellungen (Preferences) zur Verf¨ ugung. Die Persistierung der Einstellungen findet in einem sog. Preference Store statt; In einer Preference Page k¨ onnen Anwender diese Einstellungen nach eigenen Bed¨ urfnissen anpassen. Auch der F2DMM-Editor bietet ¨ uber diesen Mechanismus Einstellungsm¨ oglichkeiten an, die ¨ uberwiegend die Darstellung des Mapping-Baums betreffen. Zus¨ atzlich zum Eclipse-eigenen Men¨ ueintrag Preferences ist die entsprechende Preference Page direkt ¨ uber das Kontextmen¨ u erreichbar. Abbildung 4.34 bildet die verf¨ ugbaren Einstellungen ab. Die beiden unteren Optionsgruppen sowie die unmittelbar dar¨ uberliegende Option wurden bereits im Vorfeld diskutiert: Sie erlauben die Auswahl einer Strategie f¨ ur Surrogat-Aufl¨ osung (vgl. Abschnitt 4.8.4) sowie einer Drag-and-Drop-Operation (vgl. vorhergehenden Unterabschnitt 4.10.2). Außerdem kann an dieser Stelle die Live-Validierung (vgl. Abschnitt 4.9.3) aktiviert werden. Die weiteren – die Baumansicht des Editors beeinflussenden – Einstellungen werden im Folgenden diskutiert. 118 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Abbildung 4.34: Preference Page f¨ ur den F2DMM-Editor. Abstrakter Syntaxbaum von FEL-Ausdr¨ ucken Die Option Show Feature Expressions’ ASTs aktiviert die Darstellung abstrakter Syntaxb¨ aume (ASTs) unterhalb mit Feature-Ausdr¨ ucken versehener Mappings. Abbildung 4.35 stellt die EMF-Baumrepr¨ asentation f¨ ur einen komplexen Feature-Ausdruck dar: Teilausdr¨ ucke werden zus¨ atzlich in ihrer textuellen Repr¨ asentation angezeigt. Feature-Referenzen und boolesche Verkn¨ upfungen sowie Attribut-Constraints sind mit einem Overlay versehen, welches den Selektionszustand f¨ ur den entsprechenden Teilausdruck visualisiert. Dies erleichtert dem Anwender die Diagnose von Feature-Ausdr¨ ucken anhand einer geladenen Featurekonfiguation. Abbildung 4.35: Darstellung des abstrakten Syntaxbaums eines komplexeren Feature-Ausdrucks. 119 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Mapping-Beschreibungen Mapping-Beschreibungen wurden in Abschnitt 4.6.1 als Verkn¨ upfung zwischen Mapping-Modell und Kern-Dom¨ anenmodell eingef¨ uhrt. Sie dienen nicht nur der logischen Abstraktion, sondern auch zur optionalen Darstellung von Eigenschaften, die sich auf die Abbildung von Dom¨ anenmodell-Elementen beziehen. Abbildung 4.36 stellt die Eigenschaften einer selektierten Mapping-Beschreibung f¨ ur ein Attribut-Mapping in der Properties-Ansicht dar: Neben dem String-serialisierten Attributwert ist das gemappte Attribut aus dem Dom¨ anen-Metamodell aufgef¨ uhrt. Die Darstellung wird ¨ uber die Option Show Mapped By aktiviert, welche sich auch auf die Mapping-Properties-Ansicht auswirkt. Abbildung 4.36: Mapping-Beschreibung eines Attribut-Mappings im Property Sheet. Visualisierung von Abh¨ angigkeiten Bei der Vorberechnung von m¨ oglichen Konflikten (vgl. Abschnitt 4.7.3) werden identifizierte Abh¨ angigkeiten als Instanzen von MappingRequirement im Modell festgehalten. Auch diese werden nach Setzen entsprechender Optionen in der Preference Page angezeigt: Die Optionen Show Containment Dependencies und Show Other Dependencies aktivieren unabh¨ angig voneinander die Darstellung von Containmentbzw. SDIRL-definierten Abh¨ angigkeiten im Mapping-Baum sowie in der Mapping-PropertiesAnsicht (vgl. Abbildung 4.37). Die Darstellung umfasst Quelle und Ziel (Source bzw. Target) der unter Dependency festgehaltenen, zutreffenden Abh¨ angigkeit. Als Surrogate vorberechnete Dom¨ anenmodell-Elemente werden unter Surrogates aufgef¨ uhrt. 120 4 F2DMM: Ein Mapping-basierter Editor f¨ ur modellgetriebene Softwareproduktlinien Abbildung 4.37: Repr¨ asentation einer Abh¨ angigkeit zwischen Mappings (MappingRequirement) im Property Sheet. 4.10.5 Der F2DMM-Wizard und das FAMILE-Dashboard Die Initialisierung eines F2DMM-basierten Mapping-Modells verlangt die Angabe der beteiligten Modelle. Hierf¨ ur ist ein entsprechender Wizard (vgl. Abbildung 4.38) vorgesehen. Er wurde in seiner urspr¨ unglichen Form als Teil des Editor-Plugins generiert (vgl. Abschnitt 2.3.2) und nachtr¨ aglich manuell erg¨ anzt. Bei der Erzeugung eines Mapping-Modells wird initial die Angabe eines Bezeichners sowie eines Multivarianten-Dom¨ anenmodells und eines Featuremodells verlangt. Optional k¨ onnen eine Featurekonfiguration sowie ein SDIRLDokument referenziert werden. Nicht als Gegenstand dieser Masterarbeit, sondern im Rahmen des Lehrstuhlprojekts FAMILE wurde ein sog. Dashboard integriert, welches den Anwender bei der Erzeugung des Mapping-Modells und referenzierter Modelle begleitet. In der vorliegenden Version fehlt die Unterst¨ utzung f¨ ur das automatische Ableiten des konfigurierten Dom¨ anenmodells aus dem Mapping-Modell (vgl. auch Abbildung 4.39). 121 5 Beispiel zur Evaluierung des Ansatzes Abbildung 5.3: Paketdiagramm des Multivarianten-Dom¨ anenmodells. 128 5 Beispiel zur Evaluierung des Ansatzes Abbildung 5.4: Klassendiagramm f¨ ur das wifi-Paket des Beispiel-Dom¨ anenmodells. Abbildung 5.5: Klassendiagramm f¨ ur das Paket addOnPackage. Abbildung 5.6: Zustandsdiagramm f¨ ur die Klasse MicrowaveOven des Multivarianten-DM. 129 5 Beispiel zur Evaluierung des Ansatzes 5.2 Strukturelle Abh¨ angigkeiten f¨ ur UML2-Klassenund Zustandsdiagramme Der im Rahmen dieser Arbeit vorgeschlagene Prozess f¨ ur die modellgetriebene Entwicklung von Softwareproduktlinien (vgl. Abschnitt 3.4) definiert die Entwicklung eines Konsistenzmodells durch Analyse der Dom¨ anensprache als Voraussetzung f¨ ur die Erzeugung eines MappingModells. F2DMM sieht hierf¨ ur die textuelle Sprache SDIRL vor (vgl. Abschnitt 4.5). F¨ ur dieses Beispiel wurden SDIRL-basierte Abh¨ angigkeitsbedingungen f¨ ur UML2-Klassenund Zustandsdiagramme formuliert (vgl. Quelltext 5.1). Diese Bedingungen werden im Folgenden erl¨ autert, um die aus ihnen abgeleiteten Reparaturaktionen (s. Abschnitt 5.4) nachvollziehen zu k¨ onnen. 1import "http://www.eclipse.org/uml2/3.0.0/UML" 2 3/* CLASS DIAGRAMS */ 4 5dependency RelationshipTarget { 6element rel : uml.DirectedRelationship 7requires trg : uml.Element 8when { 9rel.target->includes(trg) 10 } 11 } 12 13 dependency MemberEndAssociation { 14 element ass : uml.Association 15 requires prop : uml.Property 16 when { 17 (ass.memberEnd->includes(prop)) or (ass.ownedEnd->includes(prop)) 18 } 19 } 20 21 dependency PropertyType { 22 element prop : uml.Property 23 requires tp : uml.Type 24 when { 25 prop.type = tp 26 } 27 } 28 29 dependency SuperClassifier { 30 element spec : uml.Classifier 31 requires gen : uml.Classifier 32 when { 33 spec.general->includes(gen) 34 } 35 surrogate { 36 gen.general.allParents() 37 } 38 } 39 40 /* STATE CHARTS */ 41 42 dependency TransitionState { 130 5 Beispiel zur Evaluierung des Ansatzes 43 element trans : uml.Transition 44 requires state : uml.State 45 when { 46 trans.source = state or trans.target = state 47 } 48 } Quelltext 5.1: SDIRL-Dokument, in dem einige Abh¨ angigkeitsbedingungen f¨ ur das UML2Metamodell (Klassenund Zustandsdiagramme) formuliert werden. •RelationshipTarget Die Abh¨ angigkeit einer durch DirectedRelationship repr¨ asentierten gerichteten Beziehung von ihrem Quellelement ist bereits durch die Containment-Beziehung abgedeckt. Zus¨ atzlich muss das Ziel der Beziehung vorhanden sein, was durch diese benutzerdefinierte Abh¨ angigkeit sichergestellt wird. •MemberEndAssociation Eine ungerichtete Assoziation, dargestellt durch die UML2Klasse Association, ist auf die Existenz beider Assoziationsenden angewiesen. Diese k¨ onnen ¨ uber die Referenzen memberEnd oder ownedEnd von der Assoziation selbst abh¨ angen. •PropertyType Eine Property, die strukturelle Eigenschaften in UML2Klassendiagrammen modelliert, h¨ angt von ihrem Typ ab, falls ein solcher existiert38. •SuperClassifier Eine UML2-Klasse h¨ angt von ihren eventuell vorhandenen Oberklassen ab. An dieser Stelle wird ein Surrogat definiert, um Informationsverlust zu vermeiden: Wird eine Oberklasse aus dem Produkt aufgrund eines negativen FeatureAusdrucks ihres Mappings entfernt, kann sie wiederum durch eine derer Oberklassen, m¨ oglicherweise auch transitiv, ersetzt werden. In einer mehrstufigen Vererbungshierarchie kann auf diese Weise eine mittlere Klasse entfallen (s. unten). •TransitionState UML2-Zustandsdiagramme enthalten Zust¨ ande (repr¨ asentiert durch die Klasse State) und ¨ Uberg¨ ange (Transition). Ein ¨ Ubergang kann nur dann existieren, wenn sowohl sein Quell- (source) als auch sein Zielzustand (target) Bestandteil eines jeweiligen Produkts sind. 5.3 Aufl¨ osung von Inkonsistenzen im Mapping-Modell Nachdem in den vorhergehenden Abschnitten die referenzierten Modelle sowie eine Menge von SDIRL-Abh¨ angigkeitsdefinitionen vorgestellt wurden, kann die Erzeugung eines MappingModells in Angriff genommen werden. Die Initialisierung erfolgt ¨ uber den entsprechenden Wizard (vgl. Abschnitt 4.10.5). Der Vorgang der Annotation einzelner Mappings wird an dieser Stelle nicht weiter aus Anwendersicht betrachtet. Stattdessen werden im Folgenden repr¨ asentative Konstellationen innerhalb des MM diskutiert, die zun¨ achst eine Konsistenzverletzung oder Informationsverlust implizieren. Diese Teile des Mapping-Modells werden schließlich aufgegriffen, um die Anwendung der erarbeiteten Konzepte zur Wiederherstellung der Konsistenz – etwa der Propagationsstrategien – zu untersuchen. 38Nicht existierende Typen sind in UML erlaubt und entsprechen dem Java-Datentyp void. 131 5 Beispiel zur Evaluierung des Ansatzes 5.3.1 Unvollst¨ andig annotierte Pakethierarchie In diesem Teil des Beispiels soll zun¨ achst davon ausgegangen werden, dass keine Propagationsstrategie zum Einsatz kommt (prim¨ are und sekund¨ are PS sind im Editor auf ignore gesetzt). HAS1 sei die geladene Featurekonfiguration. Abbildung 5.7 zeigt eine Konsistenzverletzung durch einen Verstoß gegen die in Abschnitt 3.3.2 definierte Containment-Abh¨ angigkeit. Eine Ableitung von wohlgeformten Produkten aus dem vorliegenden Mapping w¨ are nicht m¨ oglich, da der eContainer des Pakets remote nicht vorhanden ist. Abbildung 5.7: Konsistenzverletzung: Die unvollst¨ andige Annotation der Pakethierarchie f¨ uhrt zur Abh¨ angigkeit des selektierten Pakets remote von dessen nicht selektierten ElternPaket has. Ein Einsatz einer der in Abschnitt 4.7.4 vorgestellten sekund¨ aren Propagationsstrategien bewirkt die Wiederherstellung der Konsistenz, wie sie in Abbildung 5.8 dargestellt ist: Die Ermittlung des Selektionszustands des nicht annotierten Pakets has erfolgt im Fall der Vorw¨ artspropagation durch das ¨ ubergeordnete, positiv annotierte Element HASModel, von dem has abh¨ angt. Im Falle der R¨ uckw¨ artspropagation wird der Zustand von has durch Elemente, die wiederum von ihm abh¨ angen, bestimmt: Das unmittelbar untergeordnete Paket remote, ebenfalls positiv annotiert, f¨ uhrt zu einer k¨ unstlichen Positivierung des nicht annotierten Elements durch den Selektionszustand enforced. In beiden F¨ allen zeigt der dargestellte Ausschnitt nun eine konsistente Pakethierarchie. Abbildung 5.8: Wiederherstellung der Konsistenz durch die Anwendung der Propagationsstrategien forward (links) bzw. reverse (rechts). 5.3.2 Abbildung mehrwertiger Features Feature-Ausdr¨ ucke erlauben das Referenzieren mehrfach instanziierbarer Features durch Angabe eines Index bzw. einer Wildcard, die einer ODER-Verkn¨ upfung s¨ amtlicher Instanzen des Features entspricht (vgl. Abschnitt 4.4.1). Abbildung 5.9 zeigt eine von der Modellvalidierung identifizierte Konsistenzverletzung, die durch das Nichtvorhandensein eines Index bei mehrfach instanziierbaren Features entsteht. 132 5 Beispiel zur Evaluierung des Ansatzes Abbildung 5.9: Konsistenzverletzung: Die mehrfach instanziierbaren Features Keypad,Magnetic Card und Fingerprint Scanner kommen jeweils als Feature-Referenz ohne Index auf entsprechenden DM-Elementen zum Einsatz. Die Validierung empfiehlt den Einsatz eines Wildcard-Symbols. Die Aufl¨ osung dieses Konflikts obliegt dem Anwender: Der Feature-Ausdruck soll so berichtigt werden, dass er sich entweder im Sinne der subjektoder der objektbezogenen Manifestation des Variabilit¨ atsmerkmals Multiplizit¨ at an das Featuremodell bzw. die geladene Featurekonfiguration richtet. Abbildung 5.10 beschreibt die Herstellung der Beziehung zum Subjekt – also dem im FM identifizierten variierbaren Merkmal – durch den Einsatz des Wildcard-Symbols. Abbildung 5.10: Wiederherstellung der Konsistenz: Durch Verwendung des vorgeschlagenen Wildcard-Symbols beziehen sich die betroffenen Feature-Ausdr¨ ucke nun auf alle Instanzen eines mehrwertigen Features. Der linke Ausschnitt bezieht sich auf die Featurekonfiguration HAS1, der rechte auf HAS2. 5.3.3 Abh¨ angigkeiten von Zust¨ anden und Transitionen Bei der Einf¨ uhrung des Featuremodells (vgl. Abschnitt 5.1.1) sowie des MultivariantenDom¨ anenmodells (5.1.3) wurde bereits das Zustandsdiagramm f¨ ur die Klasse MicrowaveOven sowie dessen zugeh¨ orige Features Microwave Oven Control bzw. Cooldown Mode hervorgehoben. Nun soll gezeigt werden, wie sich durch lediglich zwei Annotationen eine entsprechende Abbildung im Mapping-Modell unter Ber¨ ucksichtigung der Forderung des Konsistenzerhalts realisieren lassen. F¨ ur die FK HAS1 entf¨ allt das Feature Cooldown Mode, w¨ ahrend es in HAS2 realisiert werden soll. Abbildung 5.11 zeigt die Baumrepr¨ asentation des Zustandsdiagramms im Mapping-Modell, zun¨ achst ohne Anwendung einer Propagationsstrategie: Der zus¨ atzliche Zustand On Cooldown ist mit dem entsprechenden Feature annotiert. Die direkte Transition stopOven zwischen den Zust¨ anden On Heating und Off Closed soll bei der Integration dieses Features entfallen und ist entsprechend mit not "Cooldown Mode" annotiert. Die im referenzierten SDIRL-Dokument (vgl. Abschnitt 5.2) formulierte Abh¨ angigkeitsbedingung TransitionState bewirkt das Entfallen einer Kante, die einen nicht existierenden Zustand referenziert, sobald eine Propagationsstrategie im Mapping-Modell 133 5 Beispiel zur Evaluierung des Ansatzes Abbildung 5.11: Konsistenzverletzung: Einbzw. ausgehende Transitionen des Zustands On Cooldown h¨ atten in einem durch HAS1 (links) beschriebenen Produkt keinen Quellbzw. Zielzustand. Die Annotation HAS2 (rechts) w¨ are in diesem Fall auch ohne Anwendung einer Propagationsstrategie konsistent. eingesetzt wird. Entsprechend wird beim Wiederherstellen der Konsistenz durch den Einsatz der Propagationsstrategie forward (s. Abbildung 5.12) der identifizierte Abh¨ angigkeitskonflikt in HAS1 durch automatische Negativierung des Selektionszustands der einbzw. ausgehenden Transitionen startCooldown und finishCooldown aufgel¨ ost. Abbildung 5.12: Wiederherstellung der Konsistenz: Die prim¨ are Propagationsstrategie forward erzwingt jeweils den Selektionszustand suppressed f¨ ur die Transitionen startCooldown und finishCooldown in HAS1 (links). Als sekund¨ are Strategie wurde ebenfalls die Vorw¨ artspropagation eingesetzt, um nicht annotierte Elemente, die existenziell von ihrer ¨ ubergeordneten Region abh¨ angen, zu positivieren (enforced). 5.3.4 Attribut-abh¨ angige Kardinalit¨ at einer Assoziation Eine weitere f¨ ur die Evaluierung des Ansatzes interessante, repr¨ asentative Konstellation im Beispiel-Mapping-Modell ist die Klasse addOnPackage. In Abbildung 5.5 wurde die Kompositions-Assoziation addOns zwischen AddOnRegistry und AddOn eingef¨ uhrt und bereits darauf hingewiesen, dass die Kardinalit¨ at des von AddOnRegistry ausgehenden Assoziationsendes abh¨ angig von der Multiplizit¨ at des Features Add-on Package sein soll. 134 5 Beispiel zur Evaluierung des Ansatzes Um dies zu realisieren, wird im Beispiel das implizite abgeleitete Attribut cardinality in einen Attribut-Ausdruck (vgl. Abschnitt 4.4.3) eines Alternativen-Mappings (vgl. Abschnitt 4.6.2) f¨ ur das Attribut value der die Obergrenze der Assoziation definierenden ValueSpecification eingebettet. Der Zusammenhang mit den um einwertige strukturelle Eigenschaften konkurrierenden Mappings (vgl. Abschnitt 4.7.5) wird in Abbildung 5.13 deutlich: Das Kern-Mapping f¨ ur das Attribut value (s. Mapping-Properties-Ansicht) wurde negativ annotiert (false), um einem manuell erzeugten, mit dem entsprechenden Pattern-Ausdruck #{"Add-on Package"::cardinality}versehenen Alternativen-Mapping den Vorrang zu geben. F¨ ur die Konfiguration HAS1 wertet der Attribut-Ausdruck zu 2 aus, da f¨ ur sie zwei Instanzen des Merkmals Add-on Package existieren. Abbildung 5.13: Einbettung des Attribut-Ausdrucks "Add-on Package"::cardinality in ein alternatives Attribut-Mapping, um die Kardinalit¨ at eines Assoziationsendes abh¨ angig von der Featurekonfiguration HAS1 zu bestimmen. Ein Wechsel zur Featurekonfiguration HAS2 bewirkt eine sofortige Neuauswertung des den Attributwert bestimmenden Pattern-Ausdrucks. Abbildung 5.14 zeigt das Ergebnis der entsprechenden Auswertung, wiederum in der Mapping-Properties-Ansicht: Da in HAS2 drei Instanzen von Add-on Package existieren, evaluiert das Pattern zu 3. Abbildung 5.14: Abbildung des Feature-Attributs "Add-on Package"::cardinality in HAS2. Auf ¨ ahnliche Weise wird in abgeleiteten Produkten auch der Name der Klasse VendorVPNConnectionProvider (s. Paketdiagramm in Abbildung 5.3) in Abh¨ angigkeit von einem Feature-Attribut gesetzt: Das Pr¨ afix Vendor wird hierbei durch den im Feature-Attribut Vendor Protocol der jeweiligen FK gesetzten Wert ersetzt. Der hierf¨ ur vorgesehene, explizite Attribut-Ausdruck lautet: 1#{VPN:"Vendor Protocol"}VPNConnectionProvider 135 5 Beispiel zur Evaluierung des Ansatzes 5.3.5 Unterbrechung einer mehrstufigen Vererbungshierarchie Das UML2-Klassendiagramm in Abbildung 5.4 stellt eine dreistufige Vererbungshierarchie innerhalb des Pakets has.remote.wifi des Multivarianten-DM dar. Diese soll nun im vorliegenden konstruierten Beispiel ihre Anwendung in aus Surrogat-Ausdr¨ ucken abgleiteten Reparaturaktionen finden (vgl. Abschnitte 4.5.5 und 4.7.1). Hierbei wird gepr¨ uft, inwiefern AbstractWifiConnector deren Subklasse AbstractIEEE802Connector als Oberklasse der auf untester Ebene angesiedelten konkreten Klassen als Stellvertreter ersetzen kann. Die Evaluierung soll in diesem Fall unabh¨ angig von der geladenen FK (in diesem Beispiel HAS2) erfolgen; hierzu wird die mittlere Klasse mit der Konstanten false annotiert (vgl. Abbildung 5.15). Der der Abh¨ angigkeitsdefinition SuperClassifier zugeh¨ orige Surrogat-Ausdruck wird zun¨ achst aus der SDIRL-Deklaration entfernt, um die Auswirkungen seines Fehlens zu demonstrieren: Ohne ihn k¨ onnten die konkreten Klassen aufgrund der Abh¨ angigkeitsbedingung SuperClassifier nicht existieren — es kommt zum Informationsverlust in abgeleiteten Produkten. Abbildung 5.15: Informationsverlust durch Unterbrechung einer mehrstufigen Vererbungshierarchie ohne den Einsatz von Surrogaten. Die konkreten Klassen IEEE802 11XConnector, X∈ {a, b, g}, werden aufgrund ihrer Abh¨ angigkeit von der negativ annotierten Oberklasse als suppressed markiert. Das gegebene Mapping verletzt zwar keine Konsistenzbedingungen, jedoch kann durch die Anwendung des im SDIRL-Dokument (vgl. Abschnitt 5.2) definierten Surrogat-Ausdrucks f¨ ur die Abh¨ angigkeit SuperClassifier die in der Vererbungshierarchie auf oberster Ebene befindliche Klasse AbstractWifiConnector als Surrogat fungieren. Abbildung 5.16 zeigt in der Mapping-Properties-Ansicht, dass die Mappings der zuvor aufgrund des identifizierten Abh¨ angigkeitskonflikts negativierten konkreten Klassen in ihren urspr¨ unglichen Selektionszustand active zur¨ uckversetzt wurden. Zus¨ atzlich weist die Mapping-Properties-Ansicht, die sich auf die selektierte Generalization-Beziehung einer konkreten Klasse bezieht, auf die Verf¨ ugbarkeit von Surrogaten hin, die die entfallene Klasse AbstractIEEE802Connector als Oberklasse (general) ersetzen k¨ onnen (vgl. n¨ achster Abschnitt). 5.3.6 Surrogate und Ausschlusskonflikte Im letzten Absatz von Abschnitt 4.7.5 wurde darauf eingegangen, wie im F2DMMEditor Surrogate und Ausschlusskonflikte erg¨ anzend zusammenspielen k¨ onnen. Der in Abbildung 5.17 abgebildete Screenshot zeigt, wie die Klasse FingerprintIdentificator 136 5 Beispiel zur Evaluierung des Ansatzes Abbildung 5.16: Reparatur der unterbrochenen Vererbungshierarchie durch die Definition geeigneter Surrogate im SDIRL-Dokument. durch explizite Negativierung deren Referenz zur Oberklasse AbstractIdentificator (s. Annotation false in der Mapping-Properties-Ansicht) ebenfalls von einer Negativierung Vorw¨ artspropagation betroffen ist: Sie befindet sich zun¨ achst im Selektionszustand suppressed. Abbildung 5.17: Informationsverlust: Surrogate und Ausschlusskonflikte im Zusammenspiel. Um die vollst¨ andige Negativierung der Klasse FingerprintIdentificator zu verhindern, kann das erw¨ ahnte Zusammenspiel zwischen Surrogaten und Ausschlusskonflikten ausgenutzt werden: Abbildung 5.18 bildet das als Alternativen-Mapping manuell eingef¨ ugte ReferenzMapping ¨ uber general zu MagneticCardIdentificator ab. Ohne dass ein manuelles Eingreifen n¨ otig w¨ are, ¨ andert sich der Selektionszustand des urspr¨ unglichen Referenzziels zu surrogated: In der Properties-Ansicht wird das durch das eingef¨ ugte Alternativen-ReferenzMapping abgebildete Element MagneticCardIdentificator als Surrogat vorgeschlagen. Die excludesund overrules-Beziehungen zu MagneticCardIdentificator haben sich zuvor durch die Erkennung und Aufl¨ osung von Ausschlusskonflikten in Phase 0 (vgl. Abschnitt 4.7.3) ergeben. 137 6 Abgrenzung zu verwandten MDPLE-Ans¨ atzen Abbildung 6.1: Beispiel f¨ ur die Abbildung von Features in der programmiersprachenzentrierten Produktlinien-Entwicklungsumgebung CIDE. Obige Abbildung zeigt den Nachbau eines Teils des im vorhergehenden Abschnitt vorgestellten HAS-Beispiels in CIDE. Die syntaktische Korrektheit aller ableitbaren Produkte ist sichergestellt. Ein Vergleich zum in dieser Arbeit vorgestellten Werkzeug ist aufgrund des konzeptionellen Unterschieds zwischen den beiden Ans¨ atzen nur bedingt m¨ oglich. ¨ Ahnlich wie bei F2DMM lassen sich innerhalb einer Grammatik metamodellspezifische Konsistenzbedingungen formulieren, die sich jedoch auf optionale Elemente innerhalb des abstrakten Syntaxbaums beschr¨ anken. CIDE fehlt dar¨ uber hinaus ein Mechanismus zur automatischen Ableitung von Reparaturaktionen; stattdessen wird die Aufl¨ osung von Konflikten dem Benutzer ¨ uberlassen, der R¨ uckmeldung vom Compiler oder Interpreter der jeweiligen Zielsprache erh¨ alt. Inwieweit sich F2DMM hingegen f¨ ur die Produktlinien-Modellierung in textuellen Sprachen eignet, wird in Abschnitt 7.4.2 diskutiert. 6.2 Ans¨ atze ohne Trennung der Featurevon der Dom¨ anenmodellierung Alle im Folgenden vorgestellten Methoden und Werkzeuge beziehen sich wieder auf die modellgetriebene Entwicklung von Softwareproduktlinien (MDPLE). In der Modellierung von Softwaresystemen hat sich die Modellsprache UML bzw. UML2 etabliert, so dass viele Ans¨ atze die Verwendung des entsprechenden Metamodells zur Voraussetzung erheben. Go144 6 Abgrenzung zu verwandten MDPLE-Ans¨ atzen maa [23] und Ziadi und J´ez´equel [56] stellen zwei Ans¨ atze vor, um Produktlinien direkt in UML, ohne Verwendung eines beschreibenden Featuremodells, zu modellieren. 6.2.1 PLUS: UML-basierte SPL-Entwicklung PLUS (Product Line UML based Software engineering) erweitert die aus der UML bekannten Modellierungsmethoden f¨ ur Einzel-Softwaresysteme um Konzepte und Techniken zur Beschreibung von Softwareproduktlinien (SPL). Gemeinsamkeiten und Unterschiede werden hierbei im Dom¨ anenmodell selbst beschrieben [23, Kapitel 1.8]. Ein Produkt wird demnach durch eine definierte Sicht auf die Produktfamilie – repr¨ asentiert durch ein MultivariantenDom¨ anenmodell – beschrieben. Zur Definition von Sichten werden aus dem objektorientierten Entwurf bekannte Methoden erweitert. Identifizierte Features spiegeln sich in unterschiedlicher Granularit¨ at im Dom¨ anenmodell wider: Der Schwerpunkt wird auf die komponentenbasierte Entwicklung gelegt. MicrowaveOven <<kernel>> Clock <<kernel>> HeatingElement <<kernel>> Display <<optional>> Lamp <<optional>> Beeper 11 0..1 0..11 <<default>> OneLevel HeatingElement <<variant>> MultiLeven HeatingElement <<default>> OneLineDisplay <<variant>> MultiLineDisplay {mutually exclusive} {mutually exclusive} Abbildung 6.2: Beispiel f¨ ur die Verwendung zus¨ atzlicher, von PLUS definierter, Modellierungskonstrukte in einem UML-Klassendiagramm [23, Abbildung 6.3]. Abbildung 6.2 zeigt ein Beispiel eines durch PLUS-Modellierungskonstrukte angereicherten Klassendiagramms [23, Kapitel 6.3]. F¨ ur die Annotation von Modell-Elementen einer PLUSbasierten Produktlinie sind folgende Stereotypen43 reserviert: •<<kernel>>: Das Element muss in jedem Produkt vorkommen. •<<optional>>: Das Element ist optional und kommt in manchen Produkten vor. •<<default>>: Das Element stellt den Standard-Repr¨ asentanten eines Variationspunkts dar. •<<variant>>: Das Element stellt einen alternativen konkreten Repr¨ asentanten eines Variationspunkts dar. Dem PLUS-Ansatz fehlt die Trennung von Featureund Dom¨ anenmodellierung: Konzepte wie Featuremodell oder Featurekonfigurationen sind nicht vorgesehen. Die Beschreibung eines Produkts ergibt sich stattdessen aus einer Menge von Entscheidungen zur Aufl¨ osung der 43Stereotypen sind ”sprachinh¨ arente Erweiterungsmechanismen“, die vorhandene UML-Sprachelemente durch Spezialisierung mit zus¨ atzlicher Funktionalit¨ at anreichern [32, Kapitel 5.3]. 145 6 Abgrenzung zu verwandten MDPLE-Ans¨ atzen o.g. Stereotypen. Gomaa [23] beschreibt keine Werkzeugunterst¨ utzung zum Festhalten dieser Entscheidungen bzw. zur Ableitung von Produkten aus diesen. Vielmehr stellt PLUS eine formelle Beschreibung dieses Prozesses dar: F¨ ur optionale Elemente muss bestimmt werden, ob sie in einem Produkt enthalten sind oder nicht; Variationspunkte m¨ ussen durch Angabe des Standardoder eines der alternativen Repr¨ asentanten eliminiert werden, um Subjekt und Objekt der Variabilit¨ at (vgl. Abschnitt 3.1) aneinander zu binden. Ein g¨ angiges Modell ist die Darstellung des Variationspunktes als abstrakte Klasse und die sich gegenseitig ausschließenden Varianten bzw. Repr¨ asentanten als konkrete Unterklassen. Eine Gemeinsamkeit mit dem in dieser Arbeit vorgestellten Werkzeug F2DMM ist die Art und Weise der Darstellung von Variationspunkten: Diese beinhalten jeweils einen Standardrepr¨ asentanten, der in F2DMM durch ein entsprechendes Kern-Mapping repr¨ asentiert w¨ are. Alternativen-Mappings haben ihre Entsprechung im PLUS-Stereotypen <<variant>>. 6.2.2 Der Ansatz von Ziadi und J´ez´equel f¨ ur die statische Modellierung Ziadi und J´ez´equel [56] beschreiben einen Modellierungsansatz, der dem oben beschriebenen PLUS-Ansatz in weiten Teilen ¨ ahnelt: In einem UML2-Profil sind wiederum Stereotypen definiert, die Multivarianten-Modelle um Informationen zu deren Variabilit¨ at erg¨ anzen. Die Autoren beschreiben die werkzeuggest¨ utzte Ableitung von Produkten aus UML2-Modellen, n¨ amlich Klassendiagrammen (statischer Aspekt) und Sequenzdiagrammen (verhaltensbezogener Aspekt). Eine weitere Gemeinsamkeit zu PLUS ist das Fehlen einer Trennung zwischen Featureund Dom¨ anenmodellierung. ¨ Ahnlich wie F2DMM unterst¨ utzt der Ansatz von Ziadi und J´ez´equel eine Menge von generischen oder modellspezifischen Constraints [56, Abschnitt 15.2.3], die den Prozess der Produktableitung hinsichtlich des Konsistenzerhalts beeinflussen. ¨ Ahnlich wie in Abschnitt 4.7 beschrieben erfolgt zun¨ achst die Identifikation von Abh¨ angigkeitskonflikten. Jedoch werden keine automatischen Mechanismen zur Aufl¨ osung solcher Inkonsistenzen vorgestellt: Die Produktableitung schl¨ agt im Falle eines oder mehrerer Konflikte fehl. Wie beim PLUS-Ansatz muss die im Multivarianten-Dom¨ anenmodell festgehaltene Variabilit¨ at durch eine Menge von Entscheidungen eliminiert werden. Im Ansatz von Ziadi und J´ez´equel [56, Abschnitt 15.2.4] kommt hierzu ein sog. Entscheidungsmodell (vgl. engl. decision model) zum Einsatz. Es stellt das Pendant zu den in Abschnitt 3.1 eingef¨ uhrten Featurekonfigurationen dar, ist jedoch ebenfalls als UML-Klassendiagramm realisiert. Das Entscheidungsmodell implementiert das Abstract-Factory-Entwurfsmuster [21, Abschnitt 3.1], indem die als Variationspunkt markierten abstrakten Klassen durch die jeweiligen konkreten Klassen, die die gew¨ unschte Variante implementieren, instanziiert werden. Die Ableitung konfigurierter Dom¨ anenmodelle erfolgt als Modelltransformation in der M2M-Sprache ATL44 (vgl. Abschnitt 2.7.1). Die formulierten Constraints kommen hierbei als Vorbzw. Nachbedingung zum Einsatz und haben lediglich validierenden Charakter. 44In [56] wird in diesem Kontext noch die ehemalige Bezeichnung MTL (Model Transformation Language) verwendet. 146 6 Abgrenzung zu verwandten MDPLE-Ans¨ atzen 6.2.3 Der PLiBS-Ansatz f¨ ur die dynamische Modellierung Ziadi und J´ez´equel [56, Abschnitt 15.3] beschreiben zus¨ atzlich die Modellierung verhaltensbezogener Aspekte einer Produktfamilie in UML2-Sequenzdiagrammen sowie das Werkzeug PLiBS (Product Line Behavior Synthesis) [57] in einem weiteren Artikel. Neben der Optionalit¨ at und der Alternativit¨ at wird im Kontext der dynamischen Modellierung mit der Virtualit¨ at ein zus¨ atzliches Variabilit¨ atsmerkmal eingef¨ uhrt. Mit dem Stereotyp <<virtual>> markierte Elemente fungieren als Platzhalter und k¨ onnen nach der eigentlichen Transformation durch produktspezifische Artefakte ersetzt werden. Dieses Konzept ist dadurch begr¨ undet, dass sich Softwaremerkmale in Sequenzdiagrammen auf wesentlich feinerer Granularit¨ at als beispielsweise in Klassendiagrammen niederschlagen k¨ onnen. Das Entscheidungsmodell muss um die entsprechenden konkreten Realisierungen von als virtuell gekennzeichneten Regionen erg¨ anzt werden (vgl. Abbildung 6.3). W¨ ahrend der Transformation erfolgt schließlich die Synthese der durch die Modelltransformation gewonnenen Produkte mit den die Virtualit¨ at eliminierenden Artefakten. Abbildung 6.3: Die Variabilit¨ atsmerkmale Optionalit¨ at,Variation und Virtualit¨ at in PLiBS [56, Abbildung 15.8]. Das Konzept der Virtualit¨ at bzw. der Synthese ¨ ahnelt in gewisser Weise den in SDIRL formulierbaren Alternativen (vgl. Abschnitt 4.6.2): Eine negative Annotation eines KernMappings entspricht der Deklaration <<virtual>>. Durch Angabe eines auf die selbe Referenz oder das selbe Attribut passenden, positiv annotierten Alternativen-Mappings kann eine konkrete Realisierung eingebunden und die Virtualit¨ at schließlich aufgel¨ ost werden. W¨ ahrend der Transformation erfolgt schließlich die Synthese. 147 6 Abgrenzung zu verwandten MDPLE-Ans¨ atzen 6.3 Implizite Abbildung von Features Die in diesem und im nachfolgenden Abschnitt vorgestellten Ans¨ atze sehen im Gegensatz zu den soeben beschriebenen Methoden und Werkzeugen nicht nur eine konzeptionelle, sondern dar¨ uber hinaus eine physische Trennung zwischen Featureund Dom¨ anenmodellierung gem¨ aß der von Pohl u. a. [45] postulierten orthogonalen Variabilit¨ at vor: Die Variabilit¨ at einer Produktlinie wird in einem Featuremodell (FM) festgehalten; Die Auspr¨ agung identifizierter Merkmale in einzelnen Produkten ist Inhalt jeweils einer Featurekonfiguration (FK). 6.3.1 MODPL Buchmann [10, Kapitel 6] beschreibt das am Lehrstuhl im Rahmen des Projekts MODPL entwickelte Werkzeug MODPLFeaturePlugin. Es erlaubt die Abbildung von Elementen eines Dom¨ anenmodells auf durch FeaturePlugin [3] beschriebene Merkmalsmodelle. Im Unterschied zum in dieser Arbeit beschriebenen F2DMM-Ansatz erfolgt keine Trennung zwischen Dom¨ anenund Mapping-Modell: S¨ amtliche zur Abbildung n¨ otige Information ist in der Ressource des Dom¨ anenmodells enthalten. Die Modellierungsumgebung Fujaba wurde zu diesem Zweck modifiziert: Das zugrundeliegende UML-Metamodell wurde durch den bereits im vorherigen Abschnitt erw¨ ahnten Profil-Mechanismus erweitert, um einen eigenen Stereotypen VariableElement zu unterst¨ utzen. Dieser erbt von der Basisklasse Element, die die Wurzel der Typhierarchie des Fujaba-UMLMetamodells darstellt. Der Stereotyp enth¨ alt ein mehrwertiges Attribut (auch: Tagged Value) id vom Typ String (vgl. Abbildung 6.4). Es referenziert die Bezeichner von Features, die auf das entsprechende DM-Element gemappt werden. << metaclass >> Element << stereotype >> VariableElement id[1..*]: String Abbildung 6.4: UML-Profil zur Abbildung von Features in MODPL (vgl. [10, Abbildung 6.6]). Im Folgenden wird auf Gemeinsamkeiten und Unterschiede zwischen den Modellierungsans¨ atzen und Bedienkonzepten von MODPLFeaturePlugin und F2DMM eingegangen: Verkn¨ upfungen von Features F2DMM stellt mit der Sprache FEL die M¨ oglichkeit der Verkn¨ upfung von Features mit beliebigen booleschen Operatoren zur Verf¨ ugung. In MODPL werden mit mehreren Features annotierte Elemente implizit mit einer UND-Konjunktion verkn¨ upft. FEL erlaubt außerdem die Formulierung von AttributConstraints. Die Eindeutigkeit von Feature-Bezeichnern wird in beiden Ans¨ atzen sichergestellt. Identifikation von Konsistenzverletzungen Im F2DMM-Ansatz werden Konsistenzverletzungen als Verst¨ oße gegen Abh¨ angigkeitsbedingungen identifiziert. Metamodellspezifische Abh¨ angigkeiten werden in der textuellen Sprache SDIRL formuliert. MODPL verlangt hingegen, dass die annotierten Features abh¨ angiger Elemente eine echte Teilmenge des Kontext-Elements sind. Die Bedingungen hierzu werden als Propagationsregeln in OCL formuliert. In beiden Ans¨ atzen werden Konsistenzverletzungen zun¨ achst registriert; die Aufl¨ osung erfolgt in einem weiteren Schritt. 148 6 Abgrenzung zu verwandten MDPLE-Ans¨ atzen Aufl¨ osung von Konsistenzverletzungen F2DMM unterst¨ utzt die Propagationsstrategien Vorw¨ arts bzw. R¨ uckw¨ arts, um je einen der Selektionszust¨ ande des von einem Konflikt betroffenen DM-Element-Paars zu ¨ uberschreiben. In MODPL werden nicht Selektionszust¨ ande, sondern annotierte Features propagiert, um der o.g. Teilmengenforderung gerecht zu werden. Die Propagation selbst ist wiederum als Teil der jeweiligen Propagationsregel in Java formuliert. Die Strategie selbst ¨ ahnelt der F2DMMPropagationsstrategie Vorw¨ arts. Anstelle von Surrogaten treten im MODPL-Plugin Benutzernotifikationen, etwa um eine unvollst¨ andige Vererbungshierarchie wiederherzustellen. Darstellung von abgeleiteten Produkten Beide Ans¨ atze unterst¨ utzen das Ableiten von konfigurierten Dom¨ anenmodellen bzw. Produkten aus einer Featurekonfiguration und einer validen Abbildung. MODPL erlaubt dar¨ uber hinaus die Generierung von Quelltext aus UML-basierten Produkten. Außerdem k¨ onnen in Produkten vorhandene Elemente in konkreter Syntax im Multivarianten-DM hervorgehoben werden. Annahmen f¨ ur das Dom¨ anen-Metamodell F2DMM erlegt keinerlei Annahmen ¨ uber das verwendete Dom¨ anen-Metamodell auf, außer dass es auf Ecore basieren muss. Dom¨ anenspezifische Konsistenzbedingungen werden in SDIRL formuliert. Die MODPL-Werkzeugunterst¨ utzung ist f¨ ur UML2-Paketsowie Klassendiagramme, basierend auf dem Fujaba-UML-Metamodell, vorgesehen. Zudem werden FujabaStorydiagramme [33] unterst¨ utzt, die das Verhalten von UML-Operationen spezifizieren k¨ onnen. Integration in die Werkzeuge der Dom¨ anenmodellierung MODPL zeichnet sich durch enge Verzahnung der Werkzeuge aus: Die Dom¨ anenmodellierung selbst sowie die Annotation mit Features erfolgt in einem modifizierten Fujaba-Editor. F2DMM trennt hingegen strikt die Dom¨ anenmodellierung von der Abbildung; hierdurch verbietet sich letztendlich die Darstellung von Produktlinien in der konkreten Syntax des Dom¨ anenmodells. Derzeit wird lediglich eine Baumansicht unterst¨ utzt (vgl. auch Abschnitt 7.4.2). 6.4 Explizite Abbildung von Features: Mapping-Modelle F2DMM serialisiert die zur Abbildung von Featureauf Dom¨ anenmodell-Elemente notwendige Information innerhalb einer eigenen Ressource, dem Mapping-Modell. Dieses Prinzip des expliziten Mappings wird auch von anderen MDPLE-Ans¨ atzen verfolgt, von denen im Folgenden Feature Mapper als konkreter Repr¨ asentant untersucht werden soll. 6.4.1 Feature Mapper Das von Heidenreich u. a. [30] beschriebene Eclipse-basierte Werkzeug FeatureMapper45 implementiert einen visuellen und interaktiven Ansatz zur Abbildung von Softwaremerkmalen auf Artefakte des Dom¨ anenmodells. Es unterst¨ utzt die Abbildung von Features auf DMElemente in deren konkreter (grafischer oder textueller) Syntax. Der visuelle Charakter des Ansatzes wird in [29] unter dem Schlagwort ”Controlled Visualization“ hervorgehoben. Sog. Mapping Views erlauben die Repr¨ asentation von FeatureAusdr¨ ucken durch je eine benutzerdefinierte Farbe. Die farblichen Hervorhebungen von DM45http://featuremapper.org 149 6 Abgrenzung zu verwandten MDPLE-Ans¨ atzen Elementen sollen Unterst¨ utzung bei der Analyse der Abbildung bieten. Sie integrieren sich in jeden GMF-basierten Editor: In Abbildung 6.5 werden Features aus dem Beispiel-Modell aus Abschnitt 5 auf ein Klassendiagramm abgebildet, welches wiederum mit Valkyrie [11] modelliert wurde. Abbildung 6.5: Farbliche Visualisierung einer Abbildung auf das Beispiel-Dom¨ anenmodell mit dem Werkzeug FeatureMapper. Die Abbildung selbst erfolgt in zwei Schritten: Zun¨ achst muss in der MappingView-Ansicht (s. Abbildung 6.6) ein Feature-Ausdruck erzeugt werden, der auf die anschließend ausgew¨ ahlten Elemente des DM abgebildet wird. Die Auswahl der DM-Elemente kann durch Selektion dieser in ihrer grafischen oder textuellen Editor-Repr¨ asentation geschehen (manueller Modus). Dar¨ uber hinaus erlaubt ein automatischer Modus das Mitschneiden von Manipulationen auf dem DM nach Bet¨ atigung der Record-Schaltfl¨ ache (rot ausgef¨ ullter Kreis). Nach Beendigung der ”Aufnahme“ werden alle neu erzeugten Elemente mit dem gew¨ ahlten Feature-Ausdruck annotiert. Hier spiegelt sich der interaktive Charakter des Werkzeugs wider. Im Folgenden sollen einige Aspekte untersucht werden, um das Werkzeug FeatureMapper von dem in dieser Arbeit vorgestellten F2DMM-Mapping-Editor abzugrenzen: Featuremodellierung FeatureMapper definiert wie F2DMM ein eigenes Metamodell f¨ ur FMbzw. FK-Instanzen, welches jedoch nicht die in Abschnitt 3.1 eingef¨ uhrte kardinalit¨ atsbasierte Featuremodellierung (CBFM) unterst¨ utzt. Ein Import von mit pure::variants erstellten Merkmalsbeschreibungen wird jedoch unterst¨ utzt. Dom¨ anenmodellierung Wie auch F2DMM unterst¨ utzt FeatureMapper s¨ amtliche Ecorebasierten Dom¨ anenmodelle, mit der Einschr¨ ankung, dass diese XMI-serialisiert vorliegen m¨ ussen. Durch konkrete textuelle Syntax repr¨ asentierte Modelle werden durch EMFText46 unterst¨ utzt. F2DMM unterst¨ utzt das Mapping textuell repr¨ asentierter Modelle bisher nur in deren abstrakter Syntax. 46Ein Rahmenwerk zur Entwicklung von konkreter Syntax f¨ ur Ecore-basierte Modelle, ¨ ahnlich Xtext (vgl. Abschnitt 2.5). Projekt-Website: http://www.emftext.org/index.php/EMFText. 150 6 Abgrenzung zu verwandten MDPLE-Ans¨ atzen Abbildung 6.6: Die MappingView des Werkzeugs FeatureMapper erlaubt die Annotation von DMElementen mit Feature-Ausdr¨ ucken bereits bei deren Erzeugung in einem automatischen sowie nachtr¨ aglich einem manuellen Modus. Format und Serialisierung W¨ ahrend F2DMM auf den vom EMF-Rahmenwerk bereitgestellten Deserialisierungsmechanismus zur¨ uckgreift und lediglich auf der abstrakten Syntax von Dom¨ anenmodellen operiert, unterst¨ utzt FeatureMapper verschiedene Composer, die die Spezifika der Modellpersistenz ber¨ ucksichtigen. Derzeit werden GMF-Editoren sowie EMFText-Editoren f¨ ur EMF-Modelle von je einem Composer unterst¨ utzt. Abbildung ¨ Ahnlich wie F2DMM erlaubt FeatureMapper die Abbildung durch beliebig verschachtelbare Feature-Ausdr¨ ucke. Deren abstrakte Repr¨ asentation wird jeweils in der MappingView angezeigt; es existiert keine textuelle Syntax. Auch Konzepte wie AttributConstraints oder Attribut-Mappings fehlen, wodurch die M¨ oglichkeiten der Manifestation der Variabilit¨ at (vgl. Abschnitt 3.2) im Gegensatz zu F2DMM eingeschr¨ ankt sind. Konsistenzpr¨ ufung FeatureMapper pr¨ uft zwar die bereits erw¨ ahnten, von Heidenreich [28] formulierten Wohlgeformtheitsbedingungen; diese haben jedoch lediglich validierenden Charakter: Ein wie in dieser Arbeit beschriebenes Konzept zur Ableitung von Reparaturaktionen, etwa durch Propagationsstrategien oder Surrogate, ist nicht vorhanden. Synchronisation Die Synchronit¨ at von Dom¨ anenund Mappingmodell wird in FeatureMapper nur sichergestellt, solange der automatische Annotationsmodus Manipulationen des Anwenders am DM mitschneidet. Ist dies nicht der Fall, werden durch eventuelle Manipulationen ung¨ ultig gewordene Mappings erst beim erneuten Laden des Modells von der Modellvalidierung erkannt und dem Anwender als Verletzung der entsprechenden Wohlgeformtheitsbedingung47 mitgeteilt. Die Aufl¨ osung dieser Inkonsistenzen obliegt dem Anwender. 47MM-Existing-ModelElement: Von einem Mapping repr¨ asentierte Artefakte des L¨ osungsraummodells (hier: Dom¨ anenmodells) m¨ ussen existieren [28, Abschnitt 3.2]. 151 6 Abgrenzung zu verwandten MDPLE-Ans¨ atzen 6.5 Modellierung auf Basis positiver Variabilit¨ at Alle bisher erw¨ ahnten Ans¨ atze verfolgen die Modellierung von Produktlinien auf Basis negativer Variabilit¨ at: Es existiert stets eine gemeinsame Basis — sei es ein Quelltextdokument im Falle von programmiersprachenzentrierten Ans¨ atzen (vgl. Abschnitt 6.1) oder ein Multivarianten-Dom¨ anenmodell im Falle modellgetriebener Produktlinien-Ans¨ atze. Sie stellt die Vereinigungsmenge aller ableitbaren Produkte dar, welche sich durch die Menge deselektierter Dom¨ anenmodell-Elemente bzw. Textfragmente unterscheiden. Folglich enth¨ alt kein Produkt ein Artefakt, welches nicht auch Bestandteil der gemeinsamen Basis ist (vgl. Abbildung 6.7). gemeinsame Basis Produkt 1 Produkt 2 Produkt 3 Produkt 1 Produkt 2 Produkt 3 gemeinsame Basis Abbildung 6.7: Negative (links) und positive Variabilit¨ at (rechts). Eine weitere Klasse von Ans¨ atzen setzt im Gegensatz dazu auf die positive Variabilit¨ at zur Beschreibung von Softwareproduktlinien [27]. Die gemeinsame Basis ist hierbei die kleinstm¨ ogliche Schnittmenge von in allen Mitgliedern der Produktfamilie vorkommenden Artefakten. Folglich enth¨ alt jedes Produkt mindestens die gemeinsame Basis und erweitert sie um spezifische Artefakte. Zur Beschreibung modellgetriebener SPL auf Basis positiver Variabilit¨ at eignen sich vor allem die in Abschnitt 2.7 vorgestellten Modell-zu-ModellTransformationen: Die Erzeugung eines Produkts erfolgt durch Anwendung einer Menge von erweiternden Operationen auf der gemeinsamen Basis. Erweiternde Artefakte werden hierzu h¨ aufig in separaten Ressourcen, sog. Slices (vgl. engl. f¨ ur ”Scheibe“) persistiert und w¨ ahrend der Transformation an die Basis gebunden. 6.5.1 MATA Positive Variabilit¨ at wird h¨ aufig zur aspektorientierten Modellierung (AOM) herangezogen: ¨ Ahnlich wie in Abschnitt 6.1 beschrieben, werden in Produkten verschiedene Belange (vgl. engl. concerns) identifiziert. Der von Whittle u. a. [54] vorgestellte SPL-Ansatz MATA (Modeling Aspects using a Transformational Approach) sieht die L¨ osung des Problems der Produktableitung in der Modellkomposition bzw. Modellfusion: Verschiedene Aspekte k¨ onnen mittels Transformationen an ein Referenzmodell, welches die gemeinsame Basis repr¨ asentiert, gekn¨ upft werden. Die aus der aspektorientierten Programmierung (AOP) [55] bekannten Ans¨ atze der Joinpoints und Advices kommen auch bei der AOM zum Einsatz, um die Trennung von Belangen zu realisieren. W¨ ahrend ein Joinpoint in der AOP eine Region im Kontrollfluss eines Programms definiert, an welche zur Laufzeit Advices gebunden werden, die jeweils aspektspezifisches Verhalten (z.B. Logging, Debugging) implementieren, werden in AOM spezielle Modell-Elemente als Joinpoints ausgezeichnet. Bereits bei der Komposition von Modellen werden diese mit in einbezogenen Aspekten modellierten Advices angereichert. 152 6 Abgrenzung zu verwandten MDPLE-Ans¨ atzen Die Beschreibung der Advices – also der dem Referenzmodell hinzuzuf¨ ugenden Artefakte – erfolgt im MATA-Ansatz deklarativ im Stile sog. attribuierter Graph-Grammatiken (AGG). Die zur Produktgenerierung verwendete gleichnamige Ausf¨ uhrungsumgebung wird von Taentzer [49] beschrieben. ¨ Ahnlich wie die in Abschnitt 2.7.2 vorgestellten Tripel-GraphGrammatiken beschreiben AGGs die Manipulation von Modellen — jedoch als In-PlaceTransformation: Letztere wird auf dem Referenzmodell selbst durchgef¨ uhrt, folglich existiert nur eine einzige Modelldom¨ ane. ¨ Ahnlich wie TGGs beinhalten AGGs eine Menge von Produktionsregeln. Auf der linken Seite wird ein Pattern definiert. Kann dies auf eine Region des zu manipulierenden Modells angewendet werden, tritt die sog. Kompositionsspezifikation in Kraft, welche die Manipulation des Modells selbst beschreibt. Diese kann im MATA-Ansatz in der konkreten Syntax des Dom¨ anenmodells definiert werden: Die Modell-Stereotypen <<create>> bzw. <<delete>> geben zu erzeugende bzw. zu entfernende Modellartefakte an; die Menge mit <<context>> annotierter Elemente einer Regel definieren hingegen deren Pattern. Abbildung 6.8 zeigt die Anwendung einer MATA-Regel auf das in der Mitte abgebildete UML-Sequenzdiagramm. Sie beschreibt die Einf¨ uhrung eines neuen Fragments par sowie zwei neuer Nachrichten qund b, sobald eine mit dem Pattern ¨ ubereinstimmende Nachricht pgefunden wird. Abbildung 6.8: Eine MATA-Regel f¨ ur UML-Zustandsdiagramme [54, Abbildung 11]. MATA-Regeln werden vor ihrer Anwendung in ausf¨ uhrbare AGG-Regeln ¨ ubersetzt, die die beschriebene Manipulation letztlich durchf¨ uhren. Auf positiver Variabilit¨ at basierende Ans¨ atze kennen jedoch ein Problem: Die Reihenfolge, in der die beschriebenen Transformationen durchgef¨ uhrt werden, ist entscheidend. Sobald zu einem Zeitpunkt mehrere Regeln anwendbar sind, verl¨ auft die Produktableitung nicht mehr deterministisch. Als L¨ osung schlagen Jayaraman u. a. [34] die Identifikation von Abh¨ angigkeiten und Konflikten zwischen AGG-Regeln durch Analyse kritischer Paare (CPA, vgl. engl. critical pair analysis) vor. Die Bestimmung der endg¨ ultigen Reihenfolge paarweise konfligierender Regeln bleibt jedoch dem Anwender ¨ uberlassen und kann bei entsprechender Gr¨ oße des Referenzmodells und Anzahl von Advices beliebig komplex werden. MATA bietet bei der Formulierung von Advices bzw. Kompositionsspezifikationen Unterst¨ utzung f¨ ur UML-Klassen-, Zustandsund Sequenzdiagramme. Die zugrundeliegende Ausf¨ uhrungsumgebumg erlaubt jedoch die Erweiterung auf s¨ amtliche Ecore-basierten Metamodelle; die grafische Notation von Regeln muss jeweils entsprechend der konkreten Syntax neu definiert werden. 153