Inhalt. Vorwort... XI

Inhalt Vorwort... XI 1 Grundlagen und zentrale Begriffe...1 1.1 Kernphilosophie: Automatisierung... 2 1.1.1 Standardisierung als Voraussetzung... 2 1.1.2 Trennung von Domänen- und Applikations-Entwicklung... 3 1.1.3 Domänenspezifische Erstellung... 4 1.1.4 100% Automatisierung?... 7 1.1.5 Queraspekte... 8 1.1.6 Flexibilität: generativ oder interpretativ... 10 1.1.7 Konsequenzen für das Management... 10 1.1.8 Fazit... 12 1.2 Die Rolle des Modells... 12 1.3 Generatoren... 14 1.3.1 CASE-Tools... 14 1.3.2 Schablonen in Programmiersprachen... 14 1.3.3 Generatorsysteme... 15 2 Applikations- und Domänen-Entwicklung...19 2.1 Kurzeinführung in HuGo... 20 2.2 Fazit und Ausblick... 29 2.3 Übungen... 30 2.3.1 Als Applikations-Entwickler spezifizieren... 31 2.3.2 Als Domänen-Entwickler Anpassungen vornehmen... 31 2.3.3 Anpassung der DSL... 33 3 Gleichförmigkeiten...35 3.1 Schema in Schnittstellenbeschreibung der DSL... 36 3.2 Architektur für verteiltes System... 38 3.3 Referenzimplementierung... 39 3.4 Generator zur Transformation... 41 3.5 Fazit und Ausblick... 45 3.5.1 Ein erstes Prozessmodell... 45 3.5.2 Finden der richtigen DSL... 47 3.5.3 Die Rolle des Modellierers... 48 3.5.4 Validierung des Modells... 49 3.5.5 Vorteile von Generieren... 50 3.5.6 Potenzielle Erweiterungen des Beispiels... 51

VI Inhalt 4 Queraspekte und DRY-Prinzip...53 4.1 Vorbemerkung... 54 4.2 Schritt 1: Basisentwurf Formulareditor... 55 4.2.1 Der Kernaspekt... 56 4.2.2 Die Basiskomponenten... 56 4.2.3 Die Modelldatei... 58 4.2.4 Die Architektur... 60 4.2.5 Referenzimplementierungen & Frames... 63 4.2.6 Fazit und Ausblick... 76 4.2.7 Übungen... 77 4.3 Schritt 2: Vereinfachung des DSL-Modells... 82 4.3.1 Trennung zwischen Applikation und Basiskomponenten... 82 4.3.2 Eine vereinfachte DSL... 85 4.3.3 Umwandeln der vereinfachten DSL in die formular.model... 86 4.3.4 Validierung des DSL-Modells... 90 4.3.5 Fazit und Ausblick... 91 4.4 Schritt 3: Nachträglicher Queraspekt: Tooltipps für Items... 91 4.4.1 Änderungen in der DSL... 92 4.4.2 Änderungen in den Frames... 92 4.4.3 Fazit und Ausblick... 94 4.5 Schritt 4: JUnit-Testfälle für Constraints... 96 4.5.1 Constraint-Mechanismus im Formulareditor... 96 4.5.2 Schematisierung von Testfällen... 97 4.5.3 Kurzeinführung in JUnit... 98 4.5.4 Generierung der JUnit Klasse... 101 4.5.5 Fazit und Ausblick... 104 4.6 Schritt 5: Dokumentation generieren... 105 4.6.1 Schematisierung von Dokumentation... 105 4.6.2 Format der Dokumentation (HTML)... 109 4.6.3 Generierung der Dokumentation... 110 4.6.4 Fazit und Ausblick... 115 4.6.5 Übung: Eigenes Doku-Schema... 118 5 Applikationsnah generieren...119 5.1 Eine DSL für Gebäudelichtsteuerung... 120 5.2 Die Architektur... 122 5.3 Die Referenzimplementierung... 124 5.4 Generator-Frames... 128 5.4.1 Generierung der Steuerungsklassen... 129 5.4.2 Übung: Generierung des Test-Clients... 134 5.5 Fazit und Ausblick... 137 5.5.1 Applikationsnahe DSL... 137

Inhalt VII 5.5.2 Schematisierung und Codeversatzstücke... 137 5.5.3 Ausbau um weitere elektrische Komponenten... 138 5.5.4 UML-Zustandsdiagramme als alternative DSL?... 138 5.5.5 Trennung von Steuerung und Test-Client... 139 5.5.6 Portabilität des Zielcodes... 139 5.5.7 Generativ versus interpretativ... 140 6 Fachwelt rund ums Generieren...141 6.1 Systemfamilien und Produktlinien... 142 6.2 Aspektorientierte Programmierung (AOP)... 145 6.3 Generische Programmierung... 146 6.4 Generative Programmierung (GP)... 147 6.5 Model Driven Architecture (MDA)... 147 6.6 Model Driven Software Developement (MDSD)... 151 6.7 Fazit und Ausblick... 151 6.7.1 UML als Basis für eine DSL?... 151 6.7.2 Modell, Metamodell und Metametamodell: Sinnvolle Abstraktionen... 152 7 Generierungstechniken...155 7.1 Templates für beliebige Zielsprachen... 156 7.1.1 Templates und Filtering... 156 7.1.2 Templates und Metamodell... 158 7.2 Frame-Prozessoren... 160 7.3 API-basierte Generatoren... 161 7.4 Code-Attribute... 162 7.5 Inline-Generierung... 165 7.6 Code-Weaving... 168 7.7 Fazit und Ausblick... 170 8 Engineering...177 8.1 Das Prozessmodell... 178 8.1.1 Trennung von Applikations- und Domänen-Entwicklung... 178 8.1.2 Iterative Entwicklung... 182 8.1.3 Erstellung von Referenzimplementierung und Prototyp... 183 8.1.4 Erstellung von Basiskomponenten... 185 8.2 Dokumentation... 187 8.2.1 Allgemeines zur Dokumentation... 187 8.2.2 Dokumentation der DSL... 188 8.2.3 Dokumentation des Programmiermodells... 189 8.2.4 Dokumentation der Varianten... 189 8.3 Testen... 189

VIII Inhalt 8.3.1 Automatische Tests für Varianten... 190 8.3.2 Test der Transformationsanweisungen des Generators... 191 8.3.3 Akzeptanztest der DSL... 191 8.3.4 Review-Fragen... 192 8.4 Infrastruktur (Make, Debug, Versionierung)... 199 8.4.1 Code-Generierung und Make-Prozess... 199 8.4.2 Debuggen von generiertem Code... 200 8.4.3 Coding-Blöcke und Refaktorisieren... 200 8.4.4 Versionierung der Artefakte... 201 8.5 Generatoren erzeugen Generatoren... 202 9 Management...203 9.1 Das Team... 204 9.1.1 Rollen... 204 9.1.2 Wissen und Fähigkeiten... 207 9.1.3 Psychologische Effekte... 208 9.2 Betriebswirtschaftliche Aspekte... 211 9.2.1 Flexibilität: interpretativ oder generativ... 212 9.2.2 Prinzipielle Einsparungspunkte... 214 9.2.3 Kosten-/Nutzen-Verhältnis erhöhen... 215 9.2.4 Outsourcing und Offshoring... 215 9.3 Risiken und Risikomanagement... 216 9.3.1 Keine saubere Trennung zwischen AE und DE... 216 9.3.2 Falscher Ehrgeiz einer 100%-Generierung... 217 9.3.3 Kein konsequentes, iteratives Vorgehen... 218 9.3.4 Zu wenig Feedback... 219 9.3.5 Überlastete Domänen-Entwickler... 219 9.3.6 Unpassende Architektur... 220 9.3.7 Tool-Zentriertheit... 220 9.3.8 Zu wenig Ausrichtung auf die Domäne... 221 9.3.9 Zu wenig DRY... 221 10 FAQs...223 10.1 Generieren ist doch nicht wirklich neu, oder?... 224 10.2 Wozu generieren, wenn ich Konfigurationsdateien habe?... 224 10.3 Wie zuverlässig ist generierter Code?... 225 10.4 Lohnt sich Generieren auch bei bestehenden Projekten?... 225 10.5 Sollte man anteilige Generierung vermeiden?... 225 10.6 Wo ist der Haken beim Generieren?... 226 10.7 Warum verwenden Sie kein MDA-Tool?... 226 10.8 Welche Tools können Sie empfehlen?... 226 10.9 Warum wird bislang noch so wenig generiert?... 227

Inhalt IX A Theorie und Praxis...229 A.1 Zuordnung Grundprinzipien Kapitel 2 5... 230 A.2 Weitere Beispiele aus dem Web-Umfeld... 232 A.3 Und Ihr Projekt... 234 Literatur...235 Register...237

2 1 Grundlagen und zentrale Begriffe 1 Grundlagen und zentrale Begriffe 1.1 Kernphilosophie: Automatisierung Generieren bedeutet, Software automatisch zu erstellen. Andere Branchen zeigen uns die Prinzipien von Automatisierung seit Jahren. Daher verdeutlichen wir die Prinzipien von Software-Generierung, indem wir sie mit Industrie-Automatisierung vergleichen. Sehr eindrücklich ist hier die Automobilbranche, die wir im Folgenden als Referenz nehmen. Wir führen dabei Begriffe ein, die im Laufe des Buches ständig wiederkehren und auch im Umfeld von Software Generierung in der Literatur verwendet werden (siehe Kapitel 6 ). 1.1.1 Standardisierung als Voraussetzung Bauplan Muster und Varianten Glue-Code Voraussetzung für Automatisierung ist Standardisierung. Das erste Auto wurde in viel Handarbeit erstellt. Zunächst gab es (einen) Prototypen. Der nächste Schritt bestand darin, das Auto in standardisierte Komponenten einzuteilen. Pro Komponente sind unterschiedliche Varianten möglich (z.b. breite Reifen/schmale Reifen). Es gibt einen Bauplan, welche Komponenten mit welchen kompatibel sind. Nach diesem Muster werden anschließend unterschiedlichste Varianten erstellt. Funktioniert dies manuell und muss die Arbeit öfter durchgeführt werden, so denkt man über eine Maschine nach, die diese Arbeiten übernimmt. Ist das Muster schlecht, wird auch das produzierte Produkt schlecht sein. Ist das Muster gut, kann durch Maschinenproduktion die Qualität erhöht werden. Denn Automatisierung eliminiert Flüchtigkeitsfehler, die in manueller Produktion nur zu menschlich sind. (Mal ehrlich: Ist Ihnen noch nie passiert: Copy-Paste... ups... das Replace wurde leider vergessen!?) Auch in der Software-Entwicklung verfügen wir heutzutage über viele Standardisierungen, sei es auf Methodenebene (Objektorientierung und Entwurfsmuster) oder auf Framework-Ebene (J2EE,.NET,...). Was Softwareentwicklung teuer macht, ist der hohe Anteil an manuellem Glue-Code. Glue-Code ist der Anteil, der manuell geschrieben werden muss, um die vorhandenen Komponenten so zusammenzukleben, dass daraus die gewünschte Applikation entsteht. Spätestens, wenn Sie ähnliche Aufgaben genervt zum x-ten Mal erledigen, sollten Sie ernsthaft über einen Generator nachdenken. Ein typisches Anzeichen hierfür sind die bereits erwähnten Copy-Paste-Replace-Aktionen.

1.1 Kernphilosophie: Automatisierung 3 manuell ODER automatisch Abbildung 1.1 Manuell oder automatisches Zusammenfügen von standardisierten Komponenten Bevor Sie aber einen Generator in Angriff nehmen, sollten Sie sich sicher sein, dass Ihr Verfahren/Ihre Architektur/Ihre Standardisierung stimmen. Denn das GIGO-Prinzip 1 wird durch einen Generator nur multipliziert. 1.1.2 Trennung von Domänen- und Applikations- Entwicklung Ein Aspekt der Automatisierung ist die Spezialisierung des Personals. Autobauingenieure und Konstrukteure entwickeln Verfahren und konstruieren dazu passende Maschinen, Fachpersonal setzt die konstruierten Maschinen fachgerecht ein, sodass das individuelle Produkt mit einem Höchstmaß an Qualität entsteht. Auf die Softwarebranche übertragen, bedeutet dies, dass Software-Architekten die Generatoren entwerfen und umsetzen. Die Generatoren werden dann von Applikateuren eingesetzt, um damit das Softwareprodukt mit einem Höchstmaß an Qualität zu erstellen. In der Literatur zu Generativer Programmierung finden Sie hier die Begriffe Domain Engineering und Application Engineering. Der Begriff Engineering deutet bereits darauf hin, dass es hier nicht um einen schnellen Hack eines Wizards geht, sondern dass Generatoren- und Applikationsentwicklung einem gewissen Prozess unterliegen (dazu später mehr). Wir werden diese beiden Rollen im weiteren Verlauf des Buches als Domänen- und Applikations-Entwickler bezeichnen. Domain und Application Engineering' 1 GIGO steht für Garbage In Garbage Qut; Es drückt auf sehr drastische Weise aus, dass ein System immer so gut ist wie sein Programmierer. Denn wenn Sie ein System mit (Daten-/Code-)Müll füttern, wird es sich entsprechend verhalten.

4 1 Grundlagen und zentrale Begriffe Abbildung 1.2 visualisiert die beiden Rollen in einer ersten, sehr vereinfachten Skizze. erstellt auf Basis von Standardisierungen Domänen- Entwickler parametrisiert passend zur Applikation Generator generiert Quellcode Applikations- Entwickler Abbildung 1.2 Die Rollen Domänen- und Applikations-Entwickler im Groben In kleinen Projekten können die Rollen Domänen-Entwickler und Applikations-Entwickler durchaus auch in einer Person vereint sein. 1.1.3 Domänenspezifische Erstellung Domäne Merkmale DSL Eine Autofabrik produziert Autos und keine Joghurts. Alles ist auf die Produktion von Autos abgestimmt, eventuell sogar auf eine spezifische Automarke. Auch Generatoren werden auf einen bestimmten Einsatzbereich hin entwickelt. Der Bereich, auf den der Generatoreinsatz zugeschnitten ist, wird auch als Domäne bezeichnet; daher auch Domain Engineering. Nehmen wir z.b. die Domäne Web-Applikation. Ein Web-Applikations-Generator weiß, wie eine Web-Applikation im Allgemeinen erstellt wird. Durch Parametervorgaben können dann ganz spezielle Varianten von Web-Applikationen generiert werden. Anders ausgedrückt: Die Parameter sind die Merkmale, worin sich eine Web-Applikation von einer anderen unterscheidet. Die Parameter richten sich zwangsläufig nach der Domäne. Ein Handy-Generator wird sicherlich ganz andere Parameter besitzen als ein Web-Applikationsgenerator. Da die Parametersprache die Sprache, in der die Parameter vorgegeben werden können domänenspezifisch ist, wird sie auch als DSL (domain specific language) bezeichnet.

1.1 Kernphilosophie: Automatisierung 5 Damit stellt sich das Grundprinzip von Software-Generatoren dar wie in Abbildung 1.3 gezeigt. erstellt auf Basis von Standardisierungen Domänen- Entwickler schreibt Spezifikation in DSL parametrisiert Generator generiert Quellcode Applikations- Entwickler Abbildung 1.3 Grundprinzip Software-Generatoren Die DSL legt ausschließlich die Semantik fest, das heißt, es geht um die Frage, welche Parameter es gibt und welche Bedeutung sie haben. Über die Syntax sagt die DSL nichts aus. Als Syntax für die DSL wird häufig XML verwendet. Dies hat zwei Hauptgründe: XML ist eine Sprache, um Informationen zu strukturieren. Sie ist auf der semantischen Ebene völlig frei und damit ideal als DSL geeignet. XML ist als Datenformat sehr verbreitet. Zur komfortableren Editierung der DSL-Dateien wird oft ein Editor verwendet. Auch die meisten UML-Generatoren verwenden ein spezielles XML-Format (XMI), um ihre Informationen mit anderen Applikationen auszutauschen. Der DSL kommt eine entscheidende Rolle zu. Sie ist letztlich die Schnittstelle zwischen Domänen- und Applikations-Entwicklung. Je besser die DSL die Welt der Applikations-Entwickler abbildet, umso eher wird der Generator akzeptiert. Auch in der Industrie wird eine Maschine mit einem auf die Zielgruppe passenden Bedienungskonzept besser akzeptiert als eine Eierlegende Wollmilchsau. Wie spezifisch eine DSL ist, hängt auch damit zusammen, wie eng oder weit eine Domäne gesteckt wird. Generatoren können sehr allgemeingültig oder sehr spezifisch sein. Beides hat seinen Charme. Ein allgemeiner Generator hat XML als Syntax Spezifisch oder Wollmilchsau

6 1 Grundlagen und zentrale Begriffe Schrittweise Transformation sicherlich einen größeren Anwendungsbereich, allerdings müssen dann sehr viele Parameter gesetzt werden, um damit eine konkrete Lösung zu erstellen; d.h. die Arbeit für den Applikateur ist dann aufwändiger. Ein speziell konzipierter Generator hat hingegen eine kleinere, oft aussagekräftigere DSL. Vergleichen Sie einen aus UML-Quellcode-Klassen generierten Generator mit einem.net-generator, der Ihnen ein Gerüst für eine.net Applikation erstellt. UML als DSL ist im Umfeld von Software-Architekten sicherlich sinnvoll. Handelt es sich aber um Entwickler, die weniger auf der architektonischen, sondern mehr auf der applikativen Ebene zu Hause sind und sehr schnell eine.net-vb-anwendung haben möchten, so ist ein.net Wizzard mit einer formulargestützten DSL sicherlich effektiver. Beide müssen aber noch ihre spezifische Applikation erstellen. Nun gleichen sich aber häufig auch die Applikationen auf der Business-Logik-Ebene. Z.B. ein Hersteller, der sich auf Bankensoftware spezialisiert hat, wird gewisse Software-Komponenten in ähnlicher Kombination immer wieder benötigen. Oftmals gibt es innerhalb des domänenspezifischen Umfeldes auch bereits einen Fachjargon beziehungsweise definierte Termini. Wenn sich darüber die unterschiedlichen Banksoftware-Varianten formalisiert spezifizieren lassen, so eignet sich dies ideal als DSL. Heißt das nun, dass hier ein Bankensoftware-Generator statt eines Klassen- Generators eingesetzt werden sollte? Ja und nein: Ein Bankensoftware-Generator ist sinnvoll, könnte aber ebenso mit einem Klassen-Generator kombiniert werden. Die Automobilindustrie hat auch keine monolithische Automaschine, sondern setzt viele spezifische Maschinen ein, um damit eine Autofabrik zu realisieren. Genauso ist es sinnvoll, im Projekt über mehrere Generatoren nachzudenken. Abbildung 1.4 skizziert z.b. eine Verarbeitungskette, bei der die Applikateurnahe DSL zunächst durch einen ersten Generatorschritt in eine Quellcodenähere DSL transformiert wird, bevor daraus im zweiten Schritt Quellcode generiert wird. verwendet Editor Applikations- Entwickler speichert <DSL> Gen. <DSL> Gen. Quellcode Abbildung 1.4 Beispiel schrittweise Transformierung

Register @ @#coding 44 @#compose 87 @#constructor 90 @#frame 87 @#gen 87 @#if 94 @#slot 130 @#slot_list 133 @#stream 101, 112 @#system_id 172 A agil 12, 104 Akzeptanztest DSL 191 Analogie 38 ANGIE 161 AOP 145 API 161 Application Engineering 3, 147 Artefakt 45, 187, 192, 201 AspectJ 146 Aspektorientierte Programmierung 145 siehe auch AOP Aspektorientierung 147 AST 162, 164 automatische Tests 96 siehe auch Testautomatisierung B Basiskomponenten 56, 60, 185 Baukasten 56 Binärformat 109 Browser 109 C C++ Templates 146 casts 199 CLS 162 Code-Attribute 164 Codemenge 214 Code-Passagen 7 Code-Schablonen 39 Code-Schnipsel 89 Code-Snippet 68 siehe auch Snippet Codeversatzstück 137 Coding-Block 44, 70, 73 Coding Guidelines 14, 30 Common Language Specification 162 siehe auch CLS Constraints 96, 144 Copy-Paste-Replace 208 CORBA 147 cross cutting concerns 145 D Debuggen 200 DocBook 117 Domain Engineering 3, 147 Domänen-Wissen 181 doxygen 116 DRY-Prinzip 9 E Eclipse 20 Elfenbeinturm-Entwicklung 219 Embedded 51 Entwurfsmuster 77, 146, 198 Extreme Testing 104 F Fassade 85 Feature-Diagramm 143 Feature-Modellierung 143 Feature-Oriented Domain Analysis 143 siehe auch FODA

238 Register Feedback 207, 210 Fertigungsparadigma 147 Filter 156 Filter-Datei 129 Filtering 156 FODA 143 Formalisierung 151 Frame 160 Frame (Basisklasse) 25 Frame-Instanz 160 Frame-Klasse 160 Frame-Package 128 Frame-Prozessor 160 Frame-Syntax 23 Framework 60 G Generative Programmierung 147 generic programming 146 siehe auch generische Programmierung Generics 146 generischer Programmierung 146 Gleichförmigkeit 36, 60, 137 Glue-Code 2 H Handler 40 HTML 109, 117 HuGo 15, 161 I IDL 147 Individual-Software 7 Interceptor 146 Interoperabilität 147 iterativ, inkrementell 182, 202 J JavaDoc 116, 162 javahelp 117 Join Points 146 JUnit 98, 104 K Klassen, parametrisiert 55 siehe auch TemplateClass Kombinatorik 191 Kommentar 198 Konfiguration 147 M Make 199 Makro 165 Management 204 MDA 12, 147, 148, 152 MDSD 12, 151 Mehrsprachigkeit 116 Merge 201 Meta Object Facility siehe MOF 150 Metametasprache 150 Metamodell 149, 160 Metamodell-Instanz 158 Metamodellsprache 159 Metaprogramm 16 Metasprache 149 Metatags 23 Model Driven Architecture 147 siehe auch MDA Model Driven Software Developement 151 siehe auch MDSD Modell 12 Modelldatei 59 Modellgetriebene Softwareentwicklung 151 siehe auch MDSD Modellierungssprache 149 Modell-Transformation 148 Model-View-Controller 60 siehe auch MVC MOF 148, 150, 152 Muster 2, 38 MVC 60, 76 N.NET 164

Register 239 O Offshoring 215 OMG 147 openarchitectureware 158 Outsourcing 215 P Package 128 PDF 117 Performance 51, 191, 214 PIM 148, 175 Platform Independent Model 148 siehe auch PIM Plattformunabhängigkeit 51 Plausibilitätsprüfung 50 Pointcuts 146 Portabilität 15, 139, 147 Präprozessor 165 Product Line Engineering 142 Produktionsplan 59 Produktlinie 142 Produktvarianten 147 Programmiermodell 189 Projektleiter 204, 207 Proxy 38, 146 Prozesskette 199 PSM 148, 175 Q Queraspekt 62, 145 R Refactoring 95 siehe auch Refaktorisieren Refaktorisieren 95, 200 Referenzimplementierung 183 Referenzmodell 183 Reflection 199 Reflection-Mechanismus 164 Regeln 89 regular expression 169 regulärer Ausdruck 169 Review 192 Risikomanagement 216 ROI 211 Rollenbedarf 206 RPC 36 S Scalable Vector Graphics 152 siehe auch SVG Schema 38, 97 Schema-F 208 Schichtenmodell 38 Schnittstelle 62 Single Source Publishing 117 Slot 130 Slot-Liste 133 Snippet 68, 137 Snippets 25 Standardisierung 2 Stereotyp 55, 151 STL 146 Stream 101 Stub 38 SVG 152 Syntaxbaum, abstrakt 162 siehe auch AST Syntax-Highlighting 26 Systemfamilie 142 T Team 204 Technische Redakteure 116 Telegramm 36 Template 156 TemplateClass 55 Testautomatisierung 96, 104, 134 Testgetriebene Entwicklung 104, 190 Testspezifikationen 97 Textbaustein 26, 114 Tooltipp 91 Transformation 86, 183 Modell-zu-Modell 172 Typsicherheit 51 Typumwandlung 199

240 Register U UIDs 200 UML 147 domänenspezifisch 149, 151 UML-Profil 151 Unittest 97 V Validierung 90 Variante 2, 142 verteiltes System 36 Vorgehensmodell 178 X XHTML 117 XMI 148, 150 XML-Baum 89 XML Metadata Interchange 150 siehe auch XMI XML-Schema 49 XPAND 158 XSLT 156 Z Zustandsdiagramm 138 W Word 109 WYSIWYG 116