MODELLGETRIEBENE SOFTWAREENTWICKLUNG AM BEISPIEL EINER BAUSTATIK-SOFTWAREPLATTFORM

Transkript

1 MODELLGETRIEBENE SOFTWAREENTWICKLUNG AM BEISPIEL EINER BAUSTATIK-SOFTWAREPLATTFORM Sebastian Fuchs Institut für Bauinformatik, Technische Universität Dresden TragWerk Software Kurzfassung: Modellgetriebene Softwareentwicklung verspricht durch automatisierte Softwareerstellung höhere Entwicklungsgeschwindigkeiten und verbesserte Softwarequalität für Softwareprodukte mit gleichem fachlichen Problemraum. Sie ist damit auch für den Entwicklungsprozess von Baustatik-Softwareplattformen relevant. Am Beispiel einer Fachklassen-Generierung für ein Baustatik-Modul werden die Konzepte dieser Vorgehensweise erläutert. Aus einem fachlichen Modell in XML-Syntax wird mit einem Quellcode-Generator eine Java-Klasse erzeugt. Dazu wird das Modell mit Hilfe einer Domänenspezifischen Sprache formalisiert, wobei ein Metamodell in XSD zum Einsatz kommt. 1 Einführung und Motivation Die Modellgetriebene Softwareentwicklung (engl. Model Driven Software Development, MDSD) ist eine Vorgehensweise zur teilweisen oder vollständigen automatisierten Software-Erstellung. Dabei rücken Modelle in den Mittelpunkt des Entwicklungsprozesses und erhalten den Stellenwert von Quellcode. Die Modelle sind abstrakt und formal [4], sodass Applikationslogik nicht in einer traditionellen Programmiersprache verfasst, sondern in den Modellen spezifiziert wird [5]. Während herkömmliche modellbasierte UML-Werkzeuge auf dem Abstraktionsniveau von Quellcode arbeiten [4], hebt MDSD den Abstraktionsgrad der Modelle auf das Niveau des individuellen fachlichen Problemraumes - der Domäne (engl. Domain). Modellelemente dieses Abstraktionsniveaus können den Problemraum prägnanter repräsentieren als 3GL-Programmiersprachen 1 [5]. 1 Third Generation Languages, die Höheren Programmiersprachen; in diesem Sinn sind vorrangig die General Purpose Languages gemeint, also allgemein anwendbare Programmiersprachen.

2 Für diesen Zweck wird eine Modellierungssprache benötigt, die für diese spezifische Domäne entwickelt wird. Mit Hilfe solcher Domänenspezifischen Sprachen (engl. Domain Specific Language, DSL) werden die Modelle formalisiert. Die Formalisierung ermöglicht eine automatisierte Softwareerzeugung aus den Modellen. So kann entweder Quellcode generiert werden oder eine Interpretation der Modelle zur Laufzeit erfolgen. Modellgetriebene Softwareentwicklung verspricht durch die Konzentration auf die Fachbelange und durch das hohe Automatisierungspotential eine gesteigerte Softwarequalität, verbesserte Wartbarkeit, höhere Entwicklungsgeschwindigkeiten und - unter bestimmten Voraussetzungen - Interoperabilität und Portabilität. Wird die konkrete Syntax der DSL möglichst intuitiv gestaltet, zum Beispiel grafisch, können sich auch Domänenexperten ohne Programmierkenntnisse an der Softwareentwicklung beteiligen. MDSD kann außerdem im Sinne von Software-Produktionsstraßen eingesetzt werden, wenn Software-Systemfamilien oder große Softwaresysteme mit einer konsistenten Fachdomäne erstellt werden sollen. Diese Eigenschaften machen MDSD für die Entwicklung von Baustatik-Softwareplattformen interessant. Die alleinige Anwendung programmiersprachlicher Mittel reicht nicht aus, den Entwicklungsaufwand der dort implementierten Baustatik-Module auf ein Maß zu reduzieren, das einer Konfigurationstätigkeit gleichkommt. Hauptsächlich steht dem die verwendete Programmiersprache mit ihrer konkreten Syntax und statischen Semantik selbst entgegen. Weiterhin ist es wahrscheinlich, dass mit wachsender Anzahl an Baustatik-Modulen Muster im Quellcode entdeckt werden, die sich auf Programmiersprachenebene nicht weiter abstrahieren lassen oder für die sich eine solche Abstraktion nicht lohnt. MDSD bietet Lösungsansätze für solche Problemstellungen und ermöglicht dem Entwickler die Konzentration auf die Baustatik-Belange. Innerhalb dieses Kontextes demonstriert das folgende Beispiel die Grundprinzipien Modellgetriebener Softwareentwicklung. 2 Beispiel Fachklassen-Generierung 2.1 Modellierung der Fachklasse Für eine in Java 6 implementierte Baustatik-Plattform soll ein neues Modul erstellt werden, das die Knicklast einer Stütze bestimmt. Zur Lösung der Aufgabe muss unter anderem eine Fachklasse entwickelt werden, die die relevanten Daten P, E, I, beta und Beschreibung hält.

3 /** * Eine Knicklast-Position. Berechnet die * Knicklast P einer Stütze aus E, I und beta. public class Knicklast extends Position { private double emodul; private String nummer; private double tmoment; private double beta; private double knicklast; public Knicklast(){ /** der E-Modul E in N/mm^2 public double getemodul(){ return emodul; /** emodul der E-Modul E in N/mm^2 public void setemodul(double emodul){ double oldvalue = this.emodul; this.emodul = emodul; firepropertychange("emodul", oldvalue, emodul); /* *... weitere public Object clone(){ Knicklast clone = new Knicklast(); clone.emodul = emodul; clone.nummer = nummer; clone.tmoment = tmoment; clone.beta = beta; clone.knicklast = knicklast; return clone; Listing 1: Knicklast.java Neben den fachlichen Anforderungen gibt es technische und infrastrukturelle Anforderungen an die Klasse. So soll ein PropertyChange-Support integriert werden, um die Arbeitsweise des Model-View-Controller-Prinzips zu gewährleisten. Außerdem muss eine Clone-Methode zur Erstellung von Arbeitskopien implementiert werden und JavaDoc-Kommentare haben die korrekte Anwendung der Klasse sicherzustellen. Die manuelle Implementierung ist auszugsweise in Listing 1 dargestellt. In der abstrakten Klasse Position ist bereits die Basisfunktionalität des PropertyChange-Supports

4 implementiert und die abstrakte Methode clone(): Object definiert, die Knicklast implementieren muss. Insgesamt ist ersichtlich, dass die Implementierung der technischen Anforderungen den größten Anteil am Quellcode-Umfang ausmacht. Offensichtlich unterscheiden sich die fachlichen Bestandteile aller Positionsklassen, während die technischen Bestandteile gleich sind. Dieses erkannte Schema soll nun ausgenutzt werden, um die Klassendefinition möglichst essentiell zu gestalten. Eine Optimierung mit programmiersprachlichen Mitteln ist nicht mehr sinnvoll möglich. Dafür lässt sich aber der Aufbau des Quellcodes algorithmisch beschreiben; er soll daher generiert werden. Für diesen Prozess benötigt man einen Quellcode-Generator und die Generator- Eingabe. Die Eingabe ist der variable, fachliche Anteil der Klasse und soll möglichst prägnant formuliert werden. Es wird daher ein Modell in XML-Syntax erstellt. In dieser Sprache lässt sich das Modell exakt und kompakt darstellen, der Code kann leicht von Menschen gelesen werden und das Format wird von vielen Quellcode-Generatoren als gültige Eingabe akzeptiert. Listing 2 zeigt das vollständige Modell in XML. Die gewählten Tag- und Attributnamen sind leicht verständlich, sodass es auch ohne Programmierkenntnisse möglich ist, das Knicklast-Modell zu ändern. <?xml version="1.0" encoding="utf-8"?> <position name="knicklast" beschreibung="eine Knicklast-Position. Berechnet die Knicklast P einer Stütze aus E, I und beta"> <feld name="nummer" typ="text" beschreibung="die Bezeichnung der Stütze" /> <feld name="emodul" typ="zahl" beschreibung="der E-Modul E in N/mm^2" /> <feld name="tmoment" typ="zahl" beschreibung="das Flächenträgheitsmoment I in cm^4" /> <feld name="beta" typ="zahl" beschreibung="der Knicklängenbeiwert beta, einheitslos" /> <feld name="knicklast" typ="zahl" beschreibung="die Knicklast P in kn" /> </position> Listing 2: Knicklast.xml Als Generator wird in diesem Beispiel JET [1] verwendet. JET wird mit Templates für die jeweilige Übersetzungsaufgabe konfiguriert. Auf diese Weise können für verschiedene Eingaben entsprechende Generate nach dem gleichen Schema erzeugt werden. Das Schema für dieses Beispiel ist das Klassenskelett aller konkreten Modul- Positionen, abgeleitet aus dem Prototyp in Listing 1. Listing 3 zeigt das JET-Template mit seiner XSLT-ähnlichen Syntax. Auf einen Abdruck des von JET generierten Java- Quellcodes wird an dieser Stelle verzichtet. Er entspricht dem angestrebten Klassenschema für Modul-Positionen nach Listing 1.

5 /** 2 * <c:get select="/position/@beschreibung" /> 4public class <c:get select="/position/@name" /> extends Position { 6 public <c:get select="/position/@name" />() { 8 <c:iterate select="//feld" var="field"> <c:setvariable var="javatype"> 10 <c:choose select="$field/@typ"> <c:when test="'text'">string</c:when> 12 <c:when test="'zahl'">double</c:when> </c:choose> 14 </c:setvariable> 16 private <c:get select="$javatype"/> <c:get select="$field/@name" />; 18 /** <c:get select="$field/@beschreibung" /> 20 public <c:get select="$javatype" /> get<c:choose select="camelcase ($field/@name)" >(){ 22 return <c:get select="$field/@name"/>; 24 /** 26 <c:get select="$field/@name" /> <c:get /> 28 public void set<c:get select="camelcase($field/@name)" />(<c:get select="$javatype" /> <c:get select="$field/@name" />){ <c:get select="$javatype" /> oldvalue = this.<c:get select= "$field/@name" />; 30 this.<c:get select="$field/@name" /> = <c:get select= "$field/@name" />; firepropertychange("<c:get select="$field/@name" />", oldvalue, <c:get select="$field/@name" />); 32 </c:iterate > 36 public Object clone(){ <c:get select="/position/@name" /> clone = new <c:get select= "/position/@name" />(); 38 <c:iterate select="//feld" var="field"> clone.<c:get select="$field/@name" /> = <c:get select= "$field/@name" />; 40 </c:iterate> return clone; 42 Listing 3: Position.java.jet Das Modell wurde so entworfen wie es ist, weil daraus Quellcode generiert werden sollte. Das JET-Template als Transformationsvorschrift reichert das Knicklast-Modell

6 semantisch an und beschreibt den Kontext der Abstraktion. So wird beispielsweise in den Zeilen 11 und 12 festgelegt, wie Feldtypen durch Java-Typen repräsentiert werden. 2.2 Vorschrift für alle Positionen - Modell der Modelle In Abschnitt 2.1 wurde gezeigt, wie sich die Knicklast-Position modellieren ließ und wie aus dem abstrakten Modell Quellcode generiert wurde. Die Vorgehensweise ist für diesen konkreten Fall vollständig. Allerdings ist bisher nicht entscheidbar, ob ein beliebiges Positions-Modell gültig ist. Es fehlt noch ein konkretes Vorschriftsmodell das gültige Positions-Modelle beschreibt. Dieses Vorschriftsmodell ist idealer Weise auch in einer Sprache formuliert, die durch einen Automaten ausgewertet werden kann. Zur Definition von XML-Strukturen gibt es die Schemasprache XML-Schema. Die XML-Schema-Definition (XSD) für gültige Positions-Modelle in XML-Notation ist in Listing 4 dargestellt. <?xml version="1.0" encoding="utf-8"?> <schema xmlns=" targetnamespace=" xmlns:tns=" elementformdefault="qualified"> <element name="position"> <complextype> <attribute name="name" type="string" use="required" /> <attribute name="beschreibung" type="string" use="optional" /> <sequence minoccurs="0" maxoccurs="unbounded"> <element ref="tns:feld"/> </sequence> </complextype> </element> <element name="feld"> <complextype> <attribute name="name" type="string" use="required" /> <attribute name="typ" type="string" use="required" /> <attribute name="beschreibung" type="string" use="optional" /> </complextype> </element> </schema> Listing 4: PositionSchema.xsd Mit diesem XML-Schema können nun geänderte oder neu definierte Positions-Modelle automatisiert validiert werden. Außerdem können die Generator-Templates nun auf Basis des Vorschriften-Modells erstellt werden. Insbesondere die XPath-Ausdrücke aus Listing 3 müssen sich nicht mehr implizit an einem Modell orientieren, sondern können die Strukturierung aller Modelle explizit aus dem XSD ableiten.

7 3 Einordnung in MDSD 3.1 Metaschichten-Architektur Ein Kernkonzept der MDSD ist die Metamodellierung. Metamodelle sind Modelle, die Aussagen über Modellierung treffen. Modelle sind Instanzen ihrer Metamodelle. Um Metamodelle definieren zu können, werden wiederum Modelle auf einer höheren Meta-Ebene benötigt - Meta-Metamodelle. Dieses Schema könnte beliebig fortgeführt werden, da sich der Meta-Status immer nur relativ zu einem Modell in Beziehung bringen lässt. Die OMG definiert in [3] eine Architektur aus vier Metaschichten. Abbildung 1 zeigt die vier Schichten und die Zuordnung der Komponenten des Knicklastbeispiels. Abb. 1: Metaschichten im Knicklastbeispiel Das wesentliche Merkmal dieser Architektur ist das Beenden der Meta-Ebenen bei M3 durch den Einsatz reflexiver Sprachen. Solche Sprachen können sich selbst definieren, wodurch keine weitere Meta-Ebene benötigt wird. Meta-Metamodelle (M3) werden verwendet, um Metamodelle zu definieren. Dabei müssen sie in der Lage sein, Metamodelle für sämtliche Domänen formulieren zu können. Im MDSD-Prozess kommen daher in der Regel standardisierte, bereits ausformulierte Modelle zur Anwendung, die nicht neu entwickelt werden müssen.

8 Metamodelle (M2) definieren Modelle. Metamodelle werden im MDSD-Prozess entwickelt um die gesamte Struktur oder den relevanten Teil einer Domäne formal zu beschreiben [4, S. 67]. Modelle (M1) beschreiben konkrete Ausprägungen der in M2 beschriebenen Domänenkonzepte. Sie sind eine "abstrakte Repräsentation von Struktur, Funktion oder Verhalten eines Systems" [4, S. 20]. Instanzen (M0) sind die Laufzeit-Instanzen der in M1 definierten Modellelemente. Die Beziehung der Meta-Ebene M1 zu M0 entspricht derjenigen von Klassen zu ihren Laufzeit-Instanzen in der Objektorientierten Programmierung. 3.2 Abstraktheit und Modelltransformationen Abstrakte Modelle sind ein weiteres Kernkonzept von MDSD. Es ist orthogonal zum Konzept der Meta-Ebenen. Abb. 2: Abstraktionsniveau und Meta-Ebene im Knicklastbeispiel Im Knicklastbeispiel stehen das Knicklast-Modell (Listing 2) und die daraus generierte Java-Klasse auf derselben Meta-Ebene (M1) - das Knicklast-Modell hat aber ein höheres Abstraktionsniveau, nämlich das der Domäne Baustatikmodul. Abbildung 2 zeigt den Unterschied der Konzepte anhand des Beispiels. Um Modelle eines höheren Abstraktionsniveaus auf Modelle eines niedrigeren Abstraktionsniveaus abzubilden, werden Transformationen verwendet. Die Transformationen basieren auf dem Quell-Metamodell, da die zu transformierenden Modelle Instanzen davon sind.

9 Modelle können in mehreren Stufen transformiert werden. Dies erlaubt eine Abstufung der Abstraktionsniveaus und ermöglicht so eine Anpassung des Softwareentwicklungs- Prozess an die Komplexität der Domäne. 3.3 Domain Specific Language (DSL) Ein weiteres Kernkonzept von MDSD sind Domänenspezifische Sprachen (DSL) 2. Eine DSL ermöglicht es, die Schlüsselaspekte einer Domäne formal ausdrückbar zu machen [4, S.68]. Sie ist damit Voraussetzung zur Modellierung. Eine DSL besitzt ein Metamodell, eine dazu korrespondierende konkrete Syntax und eine Semantik. Eine DSL wird im MDSD-Prozess speziell für eine Domäne entwickelt. Die konkrete Syntax der DSL kann generisch sein (zum Beispiel XML oder UML-Profile) und konfiguriert werden oder von Grund auf neu entwickelt werden. Die Syntax kann dabei grafisch oder textuell sein. Im Knicklastbeispiel wird eine textuelle Syntax auf XML-Basis verwendet. Durch die Semantik der DSL erlangen die Konstrukte des Metamodells eine Bedeutung, sodass Programmierer sinnvolle Modelle erzeugen können. Transformationen implementieren die Semantik einer DSL. Die DSL des Knicklastbeispiels setzt sich aus dem Metamodell in Listing 4, der konkreten Syntax XML, exemplarisch dargestellt in Listing 2, und der Semantik, die sich in den gewählten XML-Tags und der Transformation in Listing 3 ausdrückt, zusammen. 4 Fazit Die Kernkomponenten der Modellgetriebenen Softwareentwicklung sind 1. Modelle auf Abstraktionsniveau der Domäne 2. Formalisierung dieser Modelle mittels DSL 3. Automatisierte Softwareerstellung aus diesen Modellen MDSD ist kein fertig einsetzbares Vorgehensmodell. Vielmehr handelt es sich - in der eigenen Terminologie formuliert - um ein Metamodell für Softwarentwicklungs-Prozesse [6]. Die Vorgehensweise für ein bestimmtes Projekt muss in jedem Fall spezifisch erarbeitet werden. MDSD als Konzeptträger macht dabei keinerlei Einschränkungen bei Werkzeugwahl und Modellierungssprachen. Heutige Software-Tools sind in der Lage den kompletten Prozess der Modellgetriebenen Softwareentwicklung zu begleiten; beispielhaft sei hier 2 Ein Synonym ist auch Modellierungssprache.

10 openarchitectureware (oaw) [2] genannt. Dort kann die Prozessautomatisierung mittels einer Workflow genannten XML-Auszeichnung konfiguriert werden. Das Knicklast-Modell birgt noch weiteres Potential zur Verringerung des Softwareerstellungsaufwands. So sind mögliche Transformationen weder auf Java noch in der Anzahl der Zieldateien beschränkt. Aus Listing 2 ließe sich ohne weiteres ein SQL-Script zur Erstellung eines Datenbankschemas und ein HTML-Formular generieren. Soll der Nutzwert Modellgetriebener Softwareentwicklung für die Baustatik- Softwareplattform noch mehr erhöht werden, müssen weitere schematisch auftretende Teile der Module identifiziert und in Metamodellen beschrieben werden. Solche Aspekte sind beispielsweise Persistenz Editoren / Formulare inkl. Eingabevalidierung Grafische und Textuelle Hilfe Print- und Bildschirmausgabe Darüber hinaus müssten sich auch baustatisches Verhalten und Berechnungen modellieren lassen, um eine weitere signifikante Verbesserung des Softwareentwicklungs-Prozesses für Baustatik-Plattformen herbeizuführen. Literatur [1] Eclipse Foundation: JET - Java Emitter Templates. [2] oaw: openarchitectureware. [3] OMG: UML - Unified Modeling Language, Infrastructure. [4] Stahl, Thomas und Markus Völter: Modellgetriebene Softwareentwicklung. dpunkt.verlag, 1. Auflage, [5] Völter, Markus: Modellgetriebene Softwareentwicklung. [6] Völter, Markus: A formal MDSD Domain Model.