Modellgetriebene Softwareentwicklung bei der IBYKUS AG

Transkript

1 Modellgetriebene Softwareentwicklung bei der IBYKUS AG Theorie Teil 1: Einführung in die MDSD Dr. Steffen Skatulla IBYKUS AG 1

2 Inhalt Teil 1: Einführung in die MDSD Was ist MDSD? Was verspricht man sich von MDSD? Einführendes Beispiel Fazit 2

3 Softwareentwicklung mit Modellen Modelle in der Softwareentwicklung schon lange benutzt Analysemodelle, Entwurfsmodelle, Verhaltensmodelle, Prozessmodelle, Structure Charts, State Machines, Flow Charts, E/R-Modelle, Architekturmodelle, Interaktionsmodelle, Zunehmende Verbreitung von Modellen seit UML (Unified Modelling Language) Unterscheidung Modellbasierte Softwareentwicklung Modellgetriebene Softwareentwicklung 3

4 Modellbasierte Softwareentwicklung Modell Dabei geht es in der Regel um Entwurf und Dokumentation von Softwaresystemen Umsetzung des Modells ist ein kreativer Akt der Überwindung von Abstraktionsstufen Lediglich gedankliche Verbindung zwischen Modell und Implementierung Es müssen konkrete (technische) Ausprägungen für ein abstraktes Modell gefunden werden (z.b. technische Klassen ) Nachteile modellbasierter Entwicklung Interpretation Anreicherung Code Da Softwaresysteme sich dynamisch entwickeln, müssen die Modelle mit großem Aufwand aktuell gehalten werden I.d.R. sind Softwaresystem und Modelle inkonsistent, spätestens nach einiger Zeit Modelle spezifizieren Softwaresysteme nur teilweise und müssen durch kreative Interpretation von Programmierern in Code umgesetzt werden Werden von Entwicklern deshalb oft nur als Zwischenergebnis gesehen (nicht ganz zu unrecht), wenn nicht gar als Overhead 4

5 Modellgetriebene Softwareentwicklung (MDSD Model Driven Software Development) Modelle sind gleichzusetzen mit Programmcode Modell Aus den Modellen wird automatisch Code generiert Modelle und Generatoren müssen also alle notwendigen Details enthalten Trennung zwischen Modelle die fachlichen Entscheidungen Generatoren die technische Umsetzung Modelle beziehen sich also immer auf einen bestimmten Fachbereich Domäne Automatische Generierung Code Domänenspezifische Sprache (DSL) Domänenspezifische Abstraktion des fachlichen Bereiches finden Fachbereich so der formalen Modellierung zugänglich machen 5

6 Modellgetriebene Softwareentwicklung (MDSD Model Driven Software Development) Davon verspricht man sich Hohes Automatisierungspotential bei der Softwareentwicklung Automatische Codegenerierung Produktivitätssteigerung Modelländerungen werden schnell (automatisch) in Code umgesetzt Hohe Qualität in der Softwareentwicklung Keine Fehler in handgeschriebenem Code Fehler in Generatoren müssen nur einmal gefixt werden Bessere Wartbarkeit Modelle immer synchron mit Code Trennung von fachlichen und technischen Aspekten Effektivere Entwicklung/Modellierung auf abstrahiertem Niveau Domänespezifische Modelle für Fachexperten besser verständlich, da befreit von technischem Ballast Einführung von MDSD ist ein bedeutender Evolutionsschritt ähnlich dem Übergang von Assembler-Programmierung zu Hochsprachen 6

7 Modellgetriebene Softwareentwicklung (MDSD Model Driven Software Development) Für MDSD werden 3 wesentliche Dinge benötigt Domänenspezifische Sprachen (DSL), zur Formulierung von Modellen Textuell Graphisch Beliebige andere für Fachmodellierer geeignete Formate (z.b. bis hin zu Excel) Transformationssprachen, zur Definition der Abbildung von Modell auf Programmcode Auch Modell Modell Code (schrittweises Absteigen der Abstraktionsebenen) Generatoren/Transformatoren, die durch Anwendung der Transformationsdefinition die Abbildung Modell Modell Code ausführen Auch plattformspezifische Generatoren zur Unterstützung unterschiedlicher Laufzeitumgebungen möglich Meist Erzeugung von Quellcode in einer Programmiersprache der dann compiliert wird 7

8 Rückblick CASE Computer Aided Software Engineering Softwareerstellung mit Hilfe von integrierten Tools, mächtigen Wizards & Vorlagen Integrierte Entwicklungsumgebungen Unterstützung des Entwicklungsprozesses / Life-Cycles Weitgehend vorgegebene Werkzeugkette und Abläufe 4GL 4th Generation Languages Programmiersprachen mit mächtigen Konstrukten Reduzierung der Code-Menge Ausrichtung auf speziellen Anwendungsbereich Table-driven (codeless) Programming: z.b. GUI-Developer mit Property-Tables Report-/Formular-Generatoren Haben sich nicht durchgesetzt Proprietäre, teure Werkzeuge Wurden von standardisierter OO-Modellierung mit UML verdrängt 8

9 UML und IDEs UML Standardisierte Modellierungssprache(n) Unterstützung von Analyse, Design bis Inplementierung Integration in IDEs (Integrated Development Environments) Automatisierung durch Round-Trip-Fähigkeiten Modell Code Konsistenz zwischen Modellen und Code Aber Modell und Code liegen auf gleicher Abstraktionsebene Damit ist das Modell nur eine Darstellung des Codes hübschere graphisch übersichtlichere bei kleinen Modellen (Achtung: Tapeten mit Auto-Layout!!!) Nett zur technischen Dokumentation, nicht für Fach-Dokumentation 9

10 Definition MDSD Modellgetriebene Softwareentwicklung ist ein Oberbegriff für Techniken, die aus formalen Modellen automatisiert lauffähige Software erzeugen. [Stahl, Völter, Efftinge und Haase: Modellgetriebene Softwareentwicklung, dpunkt, 2007] Formale Modelle Beschränkung auf relevante Aspekte der zu erstellenden Software Vollständige Beschreibung, so daß die Informationen zur Erstellung der Anwendung ausreichen Verschiedene Formalismen möglich UML, textuelle DSLs, graphische DSLs, Excel, Erzeugung lauffähiger Software Nicht nur Dokumentationsmodelle, keine manuelle Implementation der Modelle Generieren von lauffähigem Code in einer Programmiersprache Interpretation von Modellen und Ausführen entsprechender Aktionen 10

11 Definition MDSD Modellgetriebene Softwareentwicklung ist ein Oberbegriff für Techniken, die aus formalen Modellen automatisiert lauffähige Software erzeugen. [Stahl, Völter, Efftinge und Haase: Modellgetriebene Softwareentwicklung, dpunkt, 2007] Automatisierung Maschinelle Transformation kein manueller Eingriff, keine menschliche Interpretation kein intelligentes, kreatives Ausfüllen von Lücken Wiederholbarkeit der Transformation Keine Wizards, die einmalig ausgeführt werden Keine nachträglichen Änderungen/Weiterentwicklungen am produzierten Code (Konsistenz von Modell und Code) Modelle sind der neue Programmcode! I.d.R. wird es Programmteile geben, die weiterhin programmiert werden Z.B. nicht verallgemeinerbare, spezielle Berechnungsalgorithmen Nicht sinnvoll abstrahierbar, nicht effizient modellierbar Kommentierter Programmcode ist beste Formalisierung Diese Teile isolieren und als Black-Box in das Modell integrieren Weiterhin automatische Erzeugung lauffähiger Software aus Modellen möglich 11

12 Gründe für MDSD Allgemein Verbesserung der Softwarequalität Wiederverwendbarkeit Steigerung der Entwicklungseffizienz Initiale Entwicklung Wartung, Weiterentwicklung Befreiung der Entwickler von lästiger, fehleranfälliger Routinearbeit Beherrschung komplexer Infrastrukturen (Datenbanken, Application-Server, GUI-Frameworks, Protokolle, Schnittstellentechnologien, ) Erzeugung performanter, robuster und wartbarer Anwendungen Speziell Entwickeln auf höherem Abstraktionsniveau Einheitliche Architektur Entwicklungsgeschwindigkeit Wiederverwendung Interoperabilität und Plattformunabhängigkeit Softwarequalität 12

13 Entwickeln auf höherem Abstraktionsniveau Programmieren auf einer höheren Abstraktionsebene Beschreibung mit reichhaltigeren, fachorientierten Konstrukten Formular und Feld statt Window, Widget, Klasse, Tabelle, Spalte Aufteilung der Gesamtkomplexität Komplexität im Modell Durch Modellierungselemente und ihre Zusammenhänge es gibt Formulare und Felder mit bestimmten Eigenschaften ein Formular kann Felder haben Komplexität in der Generierung Durch Abbildung der Modellierungselemente auf ihre Implemetierung Formulare und Felder werden abgebildet auf» Oberflächen-Elemente: Windows, Widgets» Verarbeitungs-Elemente: Klassen, Attribute, Methoden» Speicherungs-Elemente: Tabellen, Spalten 13

14 Entwickeln auf höherem Abstraktionsniveau Programmieren auf einer höheren Abstraktionsebene Beschreibung mit reichhaltigeren, fachorientierten Konstrukten Formular und Feld statt Window, Widget, Klasse, Tabelle, Spalte Aufteilung der Gesamtkomplexität Komplexität im Modell Durch Modellierungselemente und ihre Zusammenhänge Formular 1 n Feld Komplexität in der Generierung Durch Abbildung der Modellierungselemente auf ihre Implementierung Window 1 n Widget Klasse Tabelle 1 n 1 n 1 n Attribut Attribut Spalte 14

15 Entwickeln auf höherem Abstraktionsniveau Abstraktion muß nicht immer technisch sein Abstraktion muß nicht immer einstufig sein Modell auf Abstraktionsebene Förderverwaltung Förderantrag Fachliche Abstraktion Fachliche Abbildung Modell auf Abstraktionsebene Formularverarbeitung Formular Standard- Felder Standardprüfungen... Technische Abstraktion Technische Abbildung Programmcode Klasse Attribut Methode 15

16 Einheitliche Architektur Umsetzung des Modellinhalts erfolgt über Generatoren immer einheitlich in der selben Art und Weise Z.B. auf EJBs, POJOs oder WebServices Keine Verwässerung der Architektur durch Differenzen in manuellen Umsetzungen Architektur wird bestimmt durch Elemente, die das Modell erlaubt (Fachliche Architekur) Generierung, die diese Elemente auf technische Konstrukte umsetzt (Technische Architektur) Architektur ist nicht abhängig von Modellinhalt Wird also immer eingehalten Maximal vorgegebene Architekturvarianten durch Auswahl im Modell Technische Architektur durch Änderung der Generierung veränderbar einheitliche Änderung für alle Anwendungsteile Änderung an einer Stelle konzentriert: Generator/Generierungsdefinition 16

17 Entwicklungsgeschwindigkeit Zeitersparnis beim Eintippen von Quelltexten? Nein Zeit für die Eingabe des Programmcodes ist ohne hin bei nicht-trivialen Projekten verschwindend gering! Nachnutzung existierender Generatoren Nicht bei Individualentwicklungen, da müssen diese ebenfalls entwickelt werden Aber bei Produktfamilien reicht i.d.r. Beschränkung auf Fachmodellierung Selbe Domäne, selbe Architektur, gleiche Zielplattform Entwicklung auf fachlicher Ebene mit höherem Abstraktionsniveau Trennung von fachlicher Modellierung und technischer DSL- und Generatorentwicklung Einbeziehung von Fachexperten in Modellierung, wiederverwendbares formalisiertes Expertenwissen Wartung und Weiterentwicklung von Systemen Konsistenz von Modell und Code, eingehaltene Architektur Änderungen im besten Fall sehr lokal fachlich: Modell technisch: Generierung Beides: DSL + Modell + Generierung 17

18 Wiederverwendung Technische Wiederverwendung Bei Produktfamilien Selbe Domäne Selbe Architektur Gleiche Zielplattform Nachnutzung der DLS Nachnutzung der Generierung (Transformationsdefinition + Generator) Fachliche Wiederverwendung Selbes Modell Änderung der Generierung auf eine andere Zielplattform Analog zur Wiederverwendung von Programmcode natürlich auch Verwendung existierender Modelle per Cut-and-Paste Aufteilung von Modellen in wiederverwendbare Komponentenmodelle Bildung von Produktvarianten mit gemeinsamen Komponenten 18

19 Interoperabilität und Plattformunabhängigkeit Interoperabilität und Plattformunabhängigkeit sind Hauptziele der Model Driven Architecture (MDA), definiert von der Object Management Group (OMG) Aus selbem Modell Codegenerierung für unterschiedliche Zielumgebungen, z.b. JavaEE und.net Per Standardisierung von Modellen UML-Fokusierung Modelhierarchien/Transformationsstufen: PIM (Platform Independent Model) PSM (Platform Specific Model) PDM (Platform Definition Model) Insofern ist MDA eine spezielle Ausprägung von MDSD Oft ist ein 100% automatisches Umschalten auf eine neue Plattform nicht möglich, da Auswirkungen auf das Modell bestehen Aber der Umstieg wird unterstützt, durch Trennung von fachlichen und technischen Aspekten Und gleichzeitige Unterstützung bekannter Plattformen bei Berücksichtigung in Modell und Generierungen ist möglich 19

20 Softwarequalität Einheitliche Architektur kann garantiert werden Durch Generierung ist die Qualität der technischen Funktionalität garantierbar können Fehler in Routine-Code vermieden werden treten Fehler im Generator nach Beseitigung an keiner weiteren Stelle mehr auf Können Fehler auf unterstem technischen Niveau (Segementation Fault) vermieden werden Es ist vermeidbar, daß die Anwendung unhaltbar abstützt, einfriert etc. Fehler können sinnvoll zum Nutzer durchgereicht werden Es kann gesichert werden, daß der Nutzer mit der Fehlfunktion etwas anfangen kann und daß ein Fachbezug des Fehlers besteht Fachliche Fehler, fachliches Chaos lassen sich natürlich nicht ausschließen 20

21 MDSD-Beispiel Hörsaalverwaltung Es ist eine Anwendung zur Hörsaalverwaltung zu entwickeln Es gibt Hörsääle, die durch den Gebäudenamen, die Gebäudeanschrift und die Raumnummer gekennzeichnet sind. Es gibt weiterhin Lehrveranstaltungen, die einen Titel haben und aus (potentiell) mehreren wöchentlichen Terminen bestehen. Jeder Termin belegt zu in einem gewissen Zeitraum einen Hörsaal. Die Anwendung soll Formularmasken zur Erfassung, Bearbeitung und Anzeige, sowie Suchmasken und Ergebnislisten besitzen. Vorgehen Entwickeln eines Meta Modells und einer DSL zur Beschreibung einfacher Formulare, Suchen und Ergebnislisten Modellierung der Anwendung Entwicklung der Generierung 21

22 MDSD-Beispiel Hörsaalverwaltung Textuelle DSL Wir schreiben einfach mal drauf los Formular Hoersaal { }; dann Felder für die Eigenschaften 22

23 MDSD-Beispiel Hörsaalverwaltung Textuelle DSL Wir schreiben einfach mal drauf los Formular Hoersaal { }; Feld Gebaeudename(string); Feld Gebaeudeanschrift(string); Feld Raumnummer(string); noch ein Formular für die Lehrveranstaltungen 23

24 MDSD-Beispiel Hörsaalverwaltung Textuelle DSL Wir schreiben einfach mal drauf los Formular Hoersaal { }; Feld Gebaeudename(string); Feld Gebaeudeanschrift(string); Feld Raumnummer(string); Formular Lehrveranstaltung { Feld Titel(string); }; und ein Unter- Formular für die Termine 24

25 MDSD-Beispiel Hörsaalverwaltung Textuelle DSL Wir schreiben einfach mal drauf los Formular Hoersaal { }; Feld Gebaeudename(string); Feld Gebaeudeanschrift(string); Feld Raumnummer(string); Formular Lehrveranstaltung { Feld Titel(string); Formular Termin { }; }; mit Feldern für die Eigenschaften 25

26 MDSD-Beispiel Hörsaalverwaltung Textuelle DSL Wir schreiben einfach mal drauf los 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); }; }; zum Schluß noch eine Referenz auf den belegten Hörsaal 26

27 MDSD-Beispiel Hörsaalverwaltung Textuelle DSL Wir schreiben einfach mal drauf los 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); Zu jedem Formular soll es Zu jedem Formular soll es eine identisch aufgebaute eine identisch aufgebaute Suchmaske und eine Suchmaske und eine Ergebnisliste mit allen Ergebnisliste mit allen Feldern geben. Feldern geben. Generierung 27

28 MDSD-Beispiel Hörsaalverwaltung Graphische DSL Wir hätten auch drauf los malen können 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 28

29 MDSD-Beispiel Hörsaalverwaltung Meta Modell Wir haben also eine textuelle und eine graphische DSL Jeweils mit dem selben Meta Modell: Formular Parent Name Feld Name Datentyp Referenz Name Target 29

30 MDSD-Beispiel Hörsaalverwaltung Generierung Für die Elemente des Meta Modells muß definiert werden wie auf ihrer Basis eine Anwendung mit entsprechenden Teilen zu generieren ist. Oberflächen-Infrastruktur Menue Window Widget Formular Name Parent Gen Datenfluß Verarbeitungs-Infrastruktur Kontrollfluß Gen Class Atturibute Method Feld Name Datentyp Referenz Name Target Gen Datenbank-Infrastruktur Datenfluß Table Column 30

31 MDSD-Beispiel Hörsaalverwaltung Generierung Z.B. Generierung der Klassen (hier Java-POJOs) per Template Template Notation nach OAW Xpand & Xtend «DEFINE FormTemplate FOR Formular» «FILE name + ".java"» package my.generated.application; class «name» { } «ENDFILE» «ENDDEFINE» «EXPAND AttrTemplate FOREACH feld» «EXPAND RefTemplate FOREACH referenz» «DEFINE AttrTemplate FOR Feld» «datatype» «name».tolower(); «ENDDEFINE» package my.generated.application; class Hoersaal { String gebaeudename; String gebaeudeanschrift; String raumnummer; } 31

32 MDSD-Beispiel Hörsaalverwaltung Generierung mit IBYKUS AP IBYKUS AP ist eine Plattform zur modellgetriebenen Erstellung von Anwendungen im Bereich Vorgangsbearbeitung? Domäne Vorgangsbearbeitung Alles was sich auf Verwaltungsvorgänge mit Formularen abbilden läßt D.h. es gibt als Fachobjekte sog. Sachverhalte (SVH) und Sachverhaltsarten (TY) Ein TY definiert Eine Menge von Feldern für Formular, Suche, Ergebnisliste Eine Menge von Kommandos und Methoden zur Verarbeitung Einen Verarbeitungsablauf Rechte, Ein TY gehört zu einem SVH (bzw. ein TY erbt von einem SVH) Erbt Standardfelder, Standardkommandos, Formular Suche Vordefinierte SVH für typische Klassen von Fachobjekten P (Process): Vorgang mit Statusfeld, Fußabdruck, Weitergeben-Kommando, PP (Process Participant): Vorgangsbeteiligter mit Adresse, Bankverbindung, B (Booking): Buchung mit Betragsfeld, Buchungstext, O (Object): Objekte für Sachdaten noch ein Dutzend mehr TYs können Verbindungen haben Liste Prozedur 32

33 MDSD-Beispiel Hörsaalverwaltung Generierung mit IBYKUS AP IBYKUS AP definiert Eine textuelle DSL TY O veranst 'Lehrveranstaltung PAD titel 'Titel' str Eine formularbasierte DSL Formulare für Sachverhalte, Arten, Felder, Kommandos, Abläufe, Ein Modell-Repository Eine Laufzeitumgebung Oracle als DB-Server und App-Server (Verarbeitung in PL/SQL in der DB) Einen Client für die Anzeige- und Bedienoberfläche Generierungen: aus dem Modell werden vollständige Anwendungen generiert Oberflächenstrukturen: Menüs, Formulare, Suchen, Ergebnislisten, Kommandos im Client Verarbeitungsstrukturen: Suchen, Lesen, Ändern von Datensätzen, Methoden für Berechungen etc., Unterstützung für Zugriffsrechte, Verarbeitungsabläufe mit Schritten und Übergängen, Speicherstrukturen: Abbildung in eine dynamische Tabellenstruktur 33

34 MDSD-Beispiel Hörsaalverwaltung Generierung mit IBYKUS AP D.h. mit einer simplen 1:1-Transformation Formular TY Feld PAD... kann unsere entworfene DSL auf die AP-DSL transformiert werden (M2M Modell-to-Modell-Transformation) Daraus kann mit IBYKUS AP eine vollständige Anwendung generiert werden 34

35 35

36 MDSD-Beispiel Hörsaalverwaltung Beobachtungen Kapselung, Seperation of Concerns, Rollen Fachmodellentwickler Modellieren die zu erstellende Anwendung Konzentrieren sich auf fachliche Problemstellungen Benötigen keine tiefergehenden Kenntnisse der Generierung und der Laufzeitumgebung (Wir konnten die Anwendung modellieren ohne genauer auf die Generierung einzugehen bzw. ohne die Interna von IBYKUS AP zu kennen) Generatorentwickler Erstellen DSL und Generatoren Konzentrieren sich auf die Laufzeitumgebung und technische Parameter Benötigen keine tiefergehenden Kenntnisse der Details der Fachanwendung und der fachlichen Problemstellungen Schnittstelle ist die DSL Welche Fachkonstrukte gibt es Wie spielen die zusammen Welche Eigenschaften/Garantien sind dafür festgelegt (Transaktionsverhalten, Persistenz, Oberfläche, ), die dann technisch garantiert werden müssen (Wir haben festgelegt das es Formulare, Felder und Referenzen gibt und was wir davon erwarten) 36

37 MDSD-Beispiel Hörsaalverwaltung Beobachtungen Build-Prozess Erweiterung des normalen Build-Prozesses durch einen Generierungsschritt am Anfang Änderung der Anwendung erfolgt am Modell Wenn z.b. die Ausstattung der Räume mit technischen Geräten berücksichtigt werden soll Dann muß Modell um das Formular Ausstattung unter Hörsaal mit den entsprechenden Feldern erweitert werden Durch den nächsten Build-Lauf mit Generierung entsteht die geänderte Anwendung D.h. Modelle müssen genau wie Source-Code einer Versionierung unterliegen Einchecken in Sourceverwaltungssysteme Einchecken in Modellrepository 37

38 MDSD-Beispiel Hörsaalverwaltung Beobachtungen Erweiterung der DSL Z.B. Kommandos für Berechnungen fehlen in unserer DSL Da es sich um die Schnittstelle zwischen Fachentwicklung und Generatorentwicklung handelt sollten solche tiefgreifenden Änderungen in kleinen Projekten in einer informalen Projektteambesprechung, in mittleren Projekten von einem Architektur-Gremium und in großen Projekten in einem formalen Prozess besprochen und festgelegt werden Danach in dieser Reihenfolge (idealerweise) Erweiterung der DSL und der Generatoren Testen ob neue Konstrukte funktionieren Testen ob alte Modelle noch funktionieren Erst nach der Freigabe Nutzung der neunen Konstrukte zur Modellierung 38

39 MDSD-Beispiel Hörsaalverwaltung Beobachtungen Nicht generierte Anwendungsteile Für die eben erwähnten Berechnungskommandos werden Methoden in den Klassen der Verarbeitungs-Infrastruktur generiert Wie wird der Berechungsalgorithmus definiert/realisiert? Möglichkeit 1: Entwicklung einer ausdrucksmächtigen Berechungs-DSL Das macht nur Sinn, wenn ausreichendes Abstraktionspotential existiert (wesentlich vereinfachte, verkürzte Ausdrucksweise) Erfinden einer alternativen Notation zur Programmiersprache auf gleichen Abstraktionsniveau macht keinen Sinn (Eine Ausnahme wäre, wenn in mehrere Programmiersprachen generiert werden muß und wenn das über Realisierung und Wartung effektiver erscheint, als die parallele Implementierung in verschiedenen Programmiersprachen.) Möglichkeit 2: i.d.r. werden solche Algorithmen direkt in der Ziel-Sprache entwickelt Neben dem generierten Quelltext existiert somit i.d.r. handgeschriebener Quelltext 39

40 MDSD-Beispiel Hörsaalverwaltung Beobachtungen Umgang mit handgeschriebenen Anwendungsteilen Möglichkeit 1: Integration im Build-Prozess nach der Generierung Dazu müssen zur Compilierung der generierte und der handgeschriebene Source-Code zusammengeführt werden Das funktioniert i.d.r. durch zwei Source-Verzeichnisse src und src-gen auf die der Compiler parallel zugreift (z.b. bei Eclipse), so daß z.b. eine handgeschriebene Klasse in src von einer generierte Basisklasse aus src-gen erben kann 40

41 MDSD-Beispiel Hörsaalverwaltung Beobachtungen Umgang mit handgeschriebenen Anwendungsteilen Möglichkeit 2: heraufziehen des handgeschriebenen Codes als Black-Box in das Modell Source-Cut-Technik Integer berechne(int a, int b) { } int ret; try { // SOURCE-CUT BEGIN ret = a / b; // SOURCE-CUT END } catch Exception e { return null; } return ret; Auch nicht einzeln übersetzbare Codeteile möglich Bessere Möglichkeiten der Steuerung z.b. bei alternativen oder optionalen Code- Stücken 41

42 Fazit Unterschiede und Vorteile von MDSD im Vergleich zum klassischen Vorgehen Einheitliche Architektur durch Gnerierung Fachliche Modellierung in einer DSL mit erhöhtem Abstraktionsgrad Trennung von fachlichen und technischen Aspekten, Kapselung der technischen Plattform-Details in der Generierung Wichtige Teile für MDSD DSL zur Formalisierung der grundlegenden Fachkonstrukte und konkreten Fachinhalte Generator zur Abbildung auf technische Laufzeitplattform Als nächstes Wichtige MDSD-Konzepte 42