Ervaringen met het opzetten van een MDD omgeving
Introductie
(1/3)
Eric Jan Malotaux
Johan Vogelzang
Software architect Mod4j Software architect Ordina
Developer Mod4j Projectleider Java ontwikkelstraat Ordina
Introductie
(2/3)
Doel van deze sessie Inzicht geven in aspecten die een rol spelen bij de ontwikkeling van een Model Driven Development omgeving. • Ervaringen met de ontwikkeling van Mod4j • Succes factoren • Welke belangrijke keuzes zijn er te maken?
Introductie
(3/3)
Wat is Mod4j? • Mod4j = Modeling for Java
• Focus: administratieve Java applicaties • DSL gebaseerde Modeling Environment voor Eclipse (model editors, codegeneratoren) • Set horizontaal georiënteerde DSL's → referentie architectuur • Opensource, http://mod4j.org
1. Bepaal doelstellingen Wat is de businesscase voor het ontwikkelen van een MDD omgeving? • Kosten / baten – Herhaalbaarheid – Kwaliteit – Productiviteit – Time to market Mod4j: Productiviteit, kwaliteit
Onderbouwing go / nogo beslissing
2. Bepaal doeldomein Voor welk domein wil je de te ontwikkelen MDD omgeving inzetten? Mod4j: Administratieve Java applicaties.
Zorgt voor afbakening en focus Leidend voor architectuur Keuze van tools, frameworks
3. Bepaal de doelgroep Wie zijn de toekomstige gebruikers? Mod4j: Java developers Dus niet business experts
Aansluiting op bestaande best practices Keuze van ontwikkeltools en ontwikkelomgeving De te ontwikkelen model syntax Acceptatie Feedback
4. Toolkeuze Selecteer de ontwikkelomgeving en tools • Waar is de doelgroep mee bekend? • Welke eisen worden gesteld aan de DSL's? • Opensource / closedsource? Mod4j: Java developers => Eclipse platform Java developers => Maven – buildframework Eclipse => Eclipse Modeling Framework (EMF) – meta modeling Eclipse => OpenArchitectureWare (OAW) – DSL ontwikkel platform OAW => Xtext – syntax modeling OAW => Xpand, Xtend – code generators, model transformaties OAW => Check – validaties
5. Best practices Zorg er voor dat bestaande best practices blijvend kunnen worden toegepast Mod4j: Versiebeheer, diffing, merging => Textuele DSL's Code completion, syntax coloring Continuous integration => Mavenized Mod4j artifacts Unit testing Iteratief ontwikkelen Gaat niet ten koste van eerder behaalde verbeteringen Verhoogt kans van slagen Verhoogt acceptatie
6. Bepaal de doelarchitectuur Definiëer de doelarchitectuur en bouw een referentieapplicatie • In de praktijk bewezen Mod4j: Softwarearchitectuur ontwikkeld door team van ervaren Java architecten Bijbehorende referentie-applicatie intern ontwikkeld – minimale functionaliteit – maximale technische dekking Te genereren code wordt direct afgeleid uit referentieapplicatie
Mod4j Referentie Architectuur
7. Bepaal welke DSL's Welke DSL's moeten er ontwikkeld worden? • Houd DSL's klein • Beter meerdere kleine DSL's dan één grote • Zorg voor loose coupling tussen DSL's • Niet alles hoeft in een DSL Mod4j: Vier horizontale DSL's afgeleid uit de referentie-architectuur Loose coupling: Mod4j CrossX zelf ontwikkeld (wordt onderdeel van Eclipse Modeling Project) Extension points voor handmatige code
Schaalbaarheid en flexibiliteit
De vier Mod4j DSL's
8. Samenstelling ontwikkelteam Welke expertises moeten in het team aanwezig zijn? Mod4j DSL ontwikkeling: Language engineer (EMF Ecore, OAW Xtext, Xtend, Check) Codegenerator developer (OAW Xpand, Xtend) Java developer (Eclipse plug-ins, Java, Maven)
Mod4j doelarchitectuur en code: Software architect
Moeilijk om alle expertises in één persoon te vinden
9. Acceptatie Werk aan acceptatie Mod4j: Architecture board Gebruiksgemak door IDE integratie Klankbordgroep Intern opensource Pilot projecten Documentatie Demo projecten
Betrokkenheid van alle stakeholders
Vragen?
