Modell Driven Software Development (MDSD)

Transkript

1 Modell Driven Software Development (MDSD) Eine Einführung Uni Jena,

2 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 Unterscheidung Modellbasierte Softwareentwicklung Modellgetriebene Softwareentwicklung Softwareentwicklung mit Modellen Modelle in der Softwareentwicklung 2

3 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 ) Modellbasierte Softwareentwicklung Modell Code Interpretation Anreicherung 3

4 Modellbasierte Softwareentwicklung Nachteile modellbasierter Entwicklung 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 Modell Interpretation Anreicherung Code 4

5 Modellgetriebene Softwareentwicklung (MDSD Model Driven Software Development) Modelle sind gleichzusetzen mit Programmcode 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 Domänenspezifische Sprache (DSL) Domänenspezifische Abstraktion des fachlichen Bereiches finden Fachbereich so der formalen Modellierung zugänglich machen Modell Automatische Generierung Code 5

6 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 Modellgetriebene Softwareentwicklung Vorteile 6

7 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 Modellgetriebene Softwareentwicklung Vorteile 7

8 Domänenspezifische Sprachen (DSL), zur Formulierung von Modellen Textuell Graphisch Beliebige andere für Fachmodellierer geeignete Formate (z.b. bis hin zu Excel) Generatoren zur Abbildung von Modell auf Programmcode Modell Code Auch Modell Modell Code (schrittweises Absteigen der Abstraktionsebenen) Auch plattformspezifische Generatoren zur Unterstützung unterschiedlicher Laufzeitumgebungen möglich Meist Erzeugung von Quellcode in einer Programmiersprache der dann compiliert wird Modellgetriebene Softwareentwicklung Wesentliche Bestandteile 8

9 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 Rückblick 9

10 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 Rückblick 10

11 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 Konsistenz zwischen Modellen und Code Aber Modell und Code liegen auf gleicher Abstraktionsebene Damit ist das Modell nur eine Darstellung des Codes Modell Code hübscher graphisch übersichtlicher bei kleinen Modellen (Achtung: Tapeten mit Auto-Layout!!!) Nett zur technischen Dokumentation, nicht für Fach-Dokumentation 11

12 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 12

13 Definition MDSD Modellgetriebene Softwareentwicklung ist ein Oberbegriff für Techniken, die aus formalen Modellen automatisiert lauffähige Software erzeugen. Automatisierung Maschinelle Transformation [Stahl, Völter, Efftinge und Haase: Modellgetriebene Softwareentwicklung, dpunkt, 2007] 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 Plattformcode (allgemeine, nicht veränderliche Basisfunktionalität) nicht verallgemeinerbare, spezielle Algorithmen (nicht sinnvoll abstrahierbar) Diese Teile isolieren 13

14 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 Gründe für MDSD Allgemein 14

15 Entwickeln auf höherem Abstraktionsniveau Einheitliche Architektur Entwicklungsgeschwindigkeit Wiederverwendung Interoperabilität und Plattformunabhängigkeit Softwarequalität Gründe für MDSD Speziell (siehe folgende Folien im Detail) 15

16 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 16

17 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 Komplexität in der Generierung Durch Abbildung der Modellierungselemente auf ihre Implementierung Formular Window Klasse Tabelle 1 n 1 n 1 n 1 n 1 n Feld Widget Attribut Attribut Spalte 17

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

19 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 Einheitliche Architektur 19

20 Technische Architektur durch Änderung der Generierung veränderbar einheitliche Änderung für alle Anwendungsteile Änderung an einer Stelle konzentriert: Generator Einheitliche Architektur 20

21 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 Entwicklungsgeschwindigkeit 21

22 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 Entwicklungsgeschwindigkeit 22

23 Technische Wiederverwendung Bei Produktfamilien - Selbe Domäne - Selbe Architektur - Gleiche Zielplattform Nachnutzung der DSL Nachnutzung der Generatoren 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 Wiederverwendung 23

24 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 Interoperabilität und Plattformunabhängigkeit 24

25 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 Interoperabilität und Plattformunabhängigkeit 25

26 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 Softwarequalität 26

27 MDSD-Beispiel Modell im DSL-Editor 27

28 MDSD-Beispiel Generierter Code 28

29 MDSD-Beispiel Generierte Anwendung 29

30 MDSD-Beispiel Manuelle Erweiterung 30

31 Unterschiede und Vorteile von MDSD im Vergleich zum klassischen Vorgehen Einheitliche Architektur durch Generierung 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 Fazit 31