Modellgetriebene Softwareentwicklung bei der IBYKUS AG

Transkript

1 Modellgetriebene Softwareentwicklung bei der IBYKUS AG Theorie Teil 3: Metamodellierung Dr. Steffen Skatulla IBYKUS AG 1

2 Inhalt Teil 3: Metamodellierung Metamodelldefinition Metamodel, abstrakte und konkrete Syntax Constraints und Modellvalidierung Meta-Ebenen und Metamodellrepräsentation Metamodell-Technologien MOF/UML EMF/Ecore Nodes-Atributes-Relations-Metamodell (IBYKUS) Weitere Ansätze: XML/XSD, einfache Klassen Praktische Metamodellierung Erfassung der Domäne im Metamodell Erweiterung der Domäne und Metamodelländerungen Modulare Metamodelle, Metamodelle für Teilaspekte von Domänen Metamodellierung nach dem Paradigma der Komponenteninfrastruktur Komponenten und Bestandteile, Abhängigkeiten, Varianten, Komposition, Systeme, Querschnittsaspekte Metamodellierung nach dem Paradigma der Systemaspekte (IBYKUS) Kernmodell, Konstructions-Aspekt, Sourcen-Aspekt, Dokumentetions-Aspekt, Deployment- Aspekt, 2

3 Metamodell Beschreibt mögliche Struktur von Modellen Definition einer abstrakten Modellierungssprache (ohne konkrete Syntax) Konstrukte der Modellierungssprache Ihrer Beziehungen Gültigkeitsregeln Abhängig von der Domäne Steht somit am Anfang der modellgetriebener Entwicklungsprojekte Wächst mit dem Projekt mit und wird i.d.r. im Laufe des Projektes nach Bedarf erweitert/umgebaut iterativ-inkrementelles Vorgehen 3

4 Metamodell Definiert abstrakte Sprache Abstrakte Syntax Statische Semantik Metamodell definiert> <hat Abstrakte Formale Sprache Metamodell beschreibt die Struktur von Elementen in Modellen Modelle beschreiben die Struktur von Elementen der wirklichen Welt Klasse-Instanz-Beziehungen Verarbeitung basiert auf dem Metamodell Transformationen und Generierungen definieren, was aus welchen Konzepten entstehen soll Metamodell ist quasi die Schnittstelle zum Modell Metamodell Elemente des Metamodells Modell Elemente des Modells Domäne Elemente der wirklichen Welt beschreibt die Struktur beschreibt die Struktur 4

5 Konkrete Syntax Metamodell definiert jedoch nicht die konkrete Syntax D.h. nicht die Form der konkreten Repräsentation z.b. als Text Zu einem Metamodell existieren oft sogar mehrere konkrete Syntaxen für verschiedene Zwecke Textuell Graphisch Alle repräsentieren die selben Konzepte Formular Hoersaal { Feld Gebaeudename(string); Feld Gebaeudeanschrift(string); Feld Raumnummer(string); }; Formular Lehrveranstaltung { Feld Titel(string); Formular Termin { Feld Wochentag(string); Feld StartZeit(time); Feld EndZeit(time); Referenz Belegung(Hoersaal); }; }; Formular: Hörsaal Text-Feld: Gebaeudename Text-Feld: Gebaeudeanschrift Text-Feld: Raumnummer Formular: Lehrveranstaltung Text-Feld: Titel Formular: Hörsaal Text-Feld: Wochentag Zeit-Feld: StartZeit Zeit-Feld: EndZeit Referenz: Belegung 5

6 Statische Semantik Constraints Bedingungen über den Elementen der abstrakten Syntax Definieren, wann ein Modell als valid anzusehen ist Z.B. Alle Formulare müssen einen eindeutigen n haben. Ein Formular muß mindestens ein Feld haben. Validierung: Prüfung der Constraints Werkzeuge wie Transformator, Generator, Interpreter etc. verlassen sich i.a. darauf, daß ein Input-Modell valid ist, d.h. alle Constriants erfüllen Deshalb Modellvalidierung Auf jeden Fall zwischen Transformationsschritten geprüft werden Besser so früh wie möglich Dadurch Keine inkonsistente, unnötige Weiterverarbeitung Fehlerlokalisierung: Fehlermeldung mit Bezug zur Ursache, nicht erst Folgefehler 6

7 Statische Semantik Validierung in Editoren Sofort bei der Eingabe oder Spätestens beim Speichern Damit möglichst nur valide Modelle weiterverarbeitet werden Damit Fehler leichter auffindbar sind Viele Editoren bieten lokaliserte Anzeige von Fehlern Sowohl bei Verletzung der konkreten Syntax als auch bei Verletzung von Constraints Als textuelles oder graphisches High-Lighting mit Problems-View Validierung im Build-Prozess Sinnvoll vor Transformationen, Generierungen und Interpretation Um keine invaliden Modelle zu verarbeiten und schwer interpretierbare Folgefehler zu vermeiden I.d.R. auch wenn ein Modell bereits vom Editor validiert wurde (zur Vorsicht, es könnte sich ja inzwischen das Metamodell geändert haben) Bei Fehlern sollte die Ursache möglichst genau angegeben/eingegrenzt werden Unerfülltes Constraint, Modell-Datei, Zeilennummer (bei textuellen Modellen), Identifikation des Modellelementes, 7

8 Statische Semantik Checks sollten nur einmal implementiert und von mehreren Werkzeugen aufgerufen werden Editoren, Transformatoren, Generatoren, Interpreter,. Dazu eigene Check-Komponente mit einheitlicher Schnittsstelle für alle Werkzeuge in Build-Prozess Z.B. deklarative Sprache Check mit Validerungskomponente im openarchitecture- Framework OCL (Object Constraint Language der OMG) 8

9 Meta-Metamodelle Definieren abstrakte Syntax und statische Semantik der Metamodelle Prinzipiell würde es reichen, Meta-Metamodelle als Text zu beschreiben Aufzählen der zulässigen Elemente, Beziehungen, Bedingungen usw. Formale Beschreibung von Meta-Metamodellen für Werkzeuge hilfreich Metamodellierungswerkzeuge, mit denen Metamodelle bearbeitet werden Generierung von Modell-Schnittstellen und Repräsentationen für Modellierungswerkzeuge Modell-Editoren, Transformatoren, Generatoren, Interpreter,. Flexible Modell-Repositorys, die Metadaten für zu speichernde Modelle benötigen NodeType NodeType NodeType AttributType NodeType AttributType Type AttributType Type RelationType Type To RelationType NodeType RelationType Type To 9

10 Meta-Metamodelle I.d.R. Beschreibung der Meta-Metamodelle mit sich selbst describes instance of NodeType M3:Meta-Metamodell Typ: NodeType : NodeType describes instance of AttributType Type Formular RelationType Type Parent To M2: Metamodell Typ: NodeType : Formular describes instance of Feld Datentyp Formular: Hörsaal Referenz Target Text-Feld: Gebaeudename M1: Model Typ: Formular : Hörsaal Text-Feld: Gebaeudeanschrift Text-Feld: Raumnummer Formular: Lehrveranstaltung Text-Feld: Titel Formular: Hörsaal describes instance of Text-Feld: Wochentag Zeit-Feld: StartZeit Zeit-Feld: EndZeit Referenz: Belegung M0: Instances Typ: Hörsaal : HS1 10

11 Meta-Ebenen vs. Abstraktheit Meta-Ebenen und Abstraktheit sind orthogonal Z.B. bei MDA Plattform Independent Model ist abstrakter als Plattform Specific Model Aber beide befinden sich auf Meta-Ebene M1 M3 MOF M2 instance of instance of PIM-Metamodell PSM-Metamodell M1 instance of instance of PIM abstraction of PSM abstrakter konkreter 11

12 Metamodell und Modell-Repräsentation Für unterschiedliche Zwecke müssen Modelle unterschiedlich repräsentiert werden Alle Repräsentationen bauen auf dem selben Metamodell auf Z.B. unser Formular-Metamodel als textuelle DSL im textuellen Modell-Editor Formular Hoersaal { Feld Gebaeudename(string); Feld Gebaeudeanschrift(string); Feld Raumnummer(string); }; Formular Lehrveranstaltung { Feld Titel(string); Formular Termin { Feld Wochentag(string); Feld StartZeit(time); Feld EndZeit(time); Referenz Belegung(Hoersaal); }; }; Feld Datentyp Formular Referenz Parent Target als Ecore-Modell im graphischen Modell-Editor als Java-Klassen class Formular { String get(); void set(string name);... } als XML zum Austausch als Tabellen in einer Modell-DB 12

13 Konkrete Technologien: MOF/UML MOF wurde zur Beschreibung des UML-Metamodells (M2) definiert UML ist das eine standardiserte Metamodell das mit MOF definiert wurde Bewußte Ähnlichkeit von MOF mit UML-Klassendiagrammen Eigene Metamodelbildung (M2) mit MOF eine eigene (von UML abweichende) DSL zu bauen Gravierende Nachteile durch fehlende Standardisierung und Toolunterstützung Anpassung der UML an die jeweilige Domäne Erweiterung: Ableitung eigener Modellkonstrukte von UML-Konstrukten Profile: Markierung von UML-Modellelementen mit Stereotypen Überlagerung mit neuer Bedeutung Aber kein Ausblenden: Nicht möglich, nicht benötigte UML-Konstrukte auszublenden Immer zu viele, unnötige Konstrukte Immer die Möglichkeit unsinnige Modelle aufzubauen Workaround: Instanzen mit OCL verbieten 13

14 Konkrete Technologien: MOF/UML Erweiterung M3 M2 instance of UML::Class MOF::Classifier instance of MyMetaClass Durch Ableitung der neuen Meta-Modellelemente können UML-Tools genutzt werden Aber nur, wenn diese auf einem erweiterbaren formalen Metamodell beruhen 14

15 Konkrete Technologien: MOF/UML Profile Markierung von UML-Modellelementen mit Stereotypen Überlagerung mit neuer Bedeutung <<Formular>> Lehrveranstaltung <<parentformular>> <<Formular>> Termin UML 2.0 definiert Stereotyp-Mechanismus formal für Werkzeugunterstützung Bestandteile: Stereotypen, Tagged Values (Attribute von Stereotypen) und Constraints 15

16 Konkrete Technologien: Ecore/EMF Eclipse Modelling Framework Meta-Metamodell Ecore basiert auf EMOF Essential MOF: Beschränkung von MOF auf das Wesentliche Kein vordefiniertes Metamodell (M2) wie bei UML Sondern Modellierung domänenspezifischer Metamodelle Aus domänenspezifischem Metamodell sind Tools erzeugbar XMI-Dateiformat Java-Klassen zur Modellrepräsentation in Tools Einfacher baumartiger Modelleditor Grundlage für Transformationstools, textuelle und graphische Modelleditoren Übrigens: die Eclipse-UML-Tools basieren auf EMF (Domäne = UML) 16

17 Konkrete Technologien: IBYKUS CS IBYKUS Configuration Spaces (Konfigurationsräume) Metamodell (CS): Nodes, Attributes, Relations Meta-Metamodell (CS-Definition): NodeTypes, AttributeTypes, RelationTypes AttributType Type NodeType RelationType Type To <attributedescription name="name" description=" der Komponente valuetype="str(80)"/>... <relationtype name="child" description="untergeordneter Knoten" class="child"> <relationpair from="ibk.nt.src-item" to="ibk.nt.src-item"/> <relationpair from="ibk.nt.src-component" to="ibk.nt.src-subcomponent"/>... </relationtype>... <nodetype name="component" description="komponente"> <attributeassignment name="ibk.ad.src-name" optional="false"/> <attributeassignment name="ibk.ad.src-description" optional="true"/>... <relationfrom relationtype="ibk.rt.src-child" tonodetype="ibk.nt.src-component optional="true"/>... </nodetype>... Generierung von DSLs mit einheitlichem Syntaxprinzip Textuelle Modelleditoren Modellrepository XML-Format nodetype node(attr=value...){ nodetype node(attr=value...){... }; 17

18 Weitere Konkrete Technologien Klassen als Metamodell Bei Parsern die Klassen des Abstrakten Syntaxbaums XML mit XSD Wahl der konkreten Metamodell-Technologie Hängt vom Verwendungszweck bzw. vom jeweiligen Werkzeug ab Muß zur konkreten Syntax passen Sollte effektive Modellverarbeitung unterstützen 18

19 Best Practices zum Entwurf von Metamodellen Lebendiges Metamodell Entwickelt sich mit Gesamtprojekt / Systemfamilie / Produktlinie Meist Erweiterung um neuen Konzepte Von Zeit zu Zeit kann Refactoring nötig werden Metamodel first Metamodell ist Startpunkt für eine MDSD-Projekt Metamodell hat Vorrang gegenüber konkreter Syntax, Transformationen, da es die Konzepte der Domäne beschreibt, unabhängig von der konkreten Ausdrucksform oder Verwendung Modulares Metamodell Trennung verschiedener Aspekte eines Systems in verschiedene Metamodellteile Klar umrissene Bereiche mit jeweils passender konkreter Syntax Klare Schnittstellen Trennung von Zuständigkeiten 19

20 Best Practices zum Entwurf von Metamodellen Modellierung von Extension Points Um Modelle einfach und verständlich zu halten ist oft ein 80/20-Vorgehen nötig Metamodell wird so ausgelegt, daß die häufigsten Fälle modellierbar sind Seltene Fälle werden nicht mehr modelliert, sondern programmiert, aber mit einem speziellen Modellkonstrukt (Extension Point) in Modelle eingebunden Diese Extension Points müssen im Metamodell geeignet definiert werden Beispiel In unseren Formularen besitzen Felder einen Datentyp Datentyp bestimmt Eigenschaften zum Editieren (Stringfeld, Datumsfeld, ) Für Spezialfälle: Extension Point für Datentyp DataTypeExtension image(implementation="imagecontrol.jar"); Hoersaal { Feld GebaeudeBild(image);... }; Angabe einer Java-Implementierung Zum Editieren wird ein neues Fenster geöffnet, Inhalt und Funktion ist implementationsabhängig Bekannt ist nur: Input und Output als BLOB 20

21 Best Practices zum Entwurf von Metamodellen Metamodell als Projektsprache Metamodell liefert das Vokabular zur Kommunikation im Projektteam Wohldefinierte Begriffe Impliziter, fortlaufender Test für Metamodell Wenn sich ein wichtiger Sachverhalt nicht mit den Begriffen des Metamodells ausdrücken läßt, ist das ein Hinweis, dass im Metamodell wohl noch etwas fehlt Wenn es Mehrdeutigkeiten bei der Beschreibung von Sachverhalten gibt, ist das ein Hinweis, dass im Metamodell wohl noch etwas nicht stimmt 21

22 Typische Bestandteile von Metamodellen Bei großen Systemen gibt es i.d.r. Meatmodellteile zur Beschreibung des Systems aus folgenden Blickwinkeln Typ-Blickwinkel Metamodell für Komponenten und ihre Schnittstellen 22

23 Typische Bestandteile von Metamodellen Typ-Blickwinkel Metamodell für Datenstrukturen 23

24 Typische Bestandteile von Metamodellen Kompositions-Blickwinkel Metamodell für Komponenteninstanzen und ihre Verbindungen 24

25 Typische Bestandteile von Metamodellen System-Blickwinkel Metamodell für Systeme und ihre Container 25

26 Typische Bestandteile von Metamodellen Dependency-Blickwinkel Metamodell für Abhängigkeiten zwischen den Blickwinkeln Abhängigkeiten nur in eine Richtung Komponenteninstanzen hängen von Komponenten und Typen ab In Systemen werden Komponenteninstanzen installiert 26

27 Typische Bestandteile von Metamodellen Aspektmodelle Persistenz Paketierung und Deployment Diagnose und Überwachung Quality-of-Service 27

28 Metamodelle (Konfigurationsräume) bei IBYKUS AP Source-Aspekt Struktur in Subkomponenten Sachverhalte, Attribute, Beziehungen, Kommandos, Methoden, Konstruktions-Aspekt Komponenten und Subkomponenten Zusammensetzung von Anwendungen/Anwendungsvarianten aus Subkomponenten Deployment-Aspekt Auslieferung und Installation der Anwendungen/Anwendungsvarianten auf Systemen/System-Containern Konfiguration der installierten Anwendungen/Anwendungsvarianten und Systeme/System-Container Dokumentations-Aspekt Modellierung der Entwurfsdokumentation und der Handbücher, Referenzbücher, Hilfesysteme Fachliche und technische Abstraktionsstufen bis hin zur Runtime- Konfiguration, die von der laufenden Anwendung interpretiert wird 28

29 Zusammenfassung Metamodelldefinition Metamodel, abstrakte und konkrete Syntax Constraints und Modellvalidierung Meta-Ebenen und Metamodellrepräsentation Metamodell-Technologien MOF/UML, EMF/Ecore, Nodes-Atributes-Relations-Metamodell (IBYKUS) Weitere Ansätze: XML/XSD, einfache Klassen Best Practices Lebendiges Metamodell, Metamodel first, Modulare Metamodelle, Modellierung von Extension Points, Metamodell als Projektsprache Typische Bestandteile von Metamodellen Typ-, Komponenten-, System-Blickwinkel Aspektmodelle Konfigurationsräume bei IBYKUS AP Als nächstes DSLs 29