Download - Modelgedreven Ontwikkeling in de Praktijk

Universiteit Leiden

Universiteit Leiden. Universiteit om te ontdekken.

Modelgedreven Ontwikkelingin de Praktijk

Werner Heijstek, Leiden Institute of Adv. Computer Science.


Modelgedreven Ontwikkeling in de PraktijkIntroductie

1 | 21Werner Heijstek

• Sinds 2007 promovendus aan het LIACS obv.Dr. Michel Chaudron (Software Engineering Group)

• Sinds 2006 Verbonden aan het ADC vanCapgemini Nederland & Capgemini India

• Onderzoeksinteresses• global software development• software architectuur en design• software processen en productiviteit

• Collaboraties met verschillende (internationale)industriele partners en universiteiten


Modelgedreven Ontwikkeling in de PraktijkIntroductie

2 | 21Inhoud

Definitie en Terminologie

Tussen Domein en Implementatie

Hoe Zien Modellen Eruit?

Het gebruik van MDD in de Praktijk

Conclusie


Modelgedreven Ontwikkeling in de PraktijkDefinitie en Terminologie

3 | 21Synoniemen

• Model-Driven Development (MDD)Ontwikkelmethode waarin modellen centraal staan

• Model-Driven Software Development (MDSD)• Model-Driven Software Engineering (MDSE)• Model-Driven Engineering (MDE)

• Model-Driven Architecture (MDATM)Specifieke(re) ontwikkelmethode

• ontwikkeld door de Object Media Group (OMG) in 2001• MDD is hiervan een onderdeel• OMG trademarks: Model-Based Application Development

(MBADTM), Model-Based Programming (MBPTM), . . .


Modelgedreven Ontwikkeling in de PraktijkDefinitie en Terminologie

4 | 21Wat is een model?

Een model is een vereenvoudige weergave van de werkelijkheid:

Figuur: Abstractie van Mont Cervin


Modelgedreven Ontwikkeling in de PraktijkTussen Domein en Implementatie

5 | 21Afstand tussen domein en implementatie

OntwerperKlantBusiness Analyst

RequirementsEngineer

SoftwareArchitect

Programmeur( (import java.io.*;import java.util.*

public class Finder {

Ontwerper

graag zouden wij onze klanten directer met ons laten interactieren doormiddel van een portal.

Figuur: Een ‘normaal’ software ontwikkelprocess



6 | 21Modellen als centrale taal

KlantRequirements

Engineer

SoftwareArchitect

Business Analyst

Programmeur

OntwerperOntwerper

Figuur: Een modelgedreven software ontwikkelprocess



7 | 21De rol van modellen

Figuur: Brown’s Modelleer Spectrum

Brown (2004) An introduction to MDA. Part I: MDA and Today’s Systems. The Rational Edge



8 | 21Evolutie van abstractie

periode taal bijzonderheden

jaren 50 Assembler

jaren 60 Common Business Orien-ted Language (COBOL)

abstractie van machinecode

jaren 70 C++ object orientatie

jaren 90 Java ontkoppeling logische en technische

implementatie; veel kant-en-klare

functionaliteit

recent MDATM, Domeinenspe-cifieke Talen (DSL)

abstractie van broncode; “signifi-

cante” generatie van broncode

Tabel: Evolutie van abstractie in programmeeromgevingen


Modelgedreven Ontwikkeling in de PraktijkHoe Zien Modellen Eruit?

9 | 21Modelleertalen

• Generiek• Unified Modeling Language (UML)

◮ grafisch

• Formele talen (e.g. Z-notatie)◮ textueel

• SpecifiekDomain Specific Languages (DSL)

• grafisch (vaak mbv. UML!)• textueel• hybride


Modelgedreven Ontwikkeling in de PraktijkHoe Zien Modellen Eruit?

10 | 21Modelleertalen in de praktijk

UML

DSL

Figuur: DSL “versus” UML

text diagrammen hybride0%

10%

20%

30%

40%

50%

Figuur: DSL mediadistributie

Torchiano, et al. Preliminary findings from a state of the practice survey in MD*. ESEM 2011


Modelgedreven Ontwikkeling in de PraktijkHet gebruik van MDD in de Praktijk

11 | 21Impact van adoptie van MDD

Modelgedreven ontwikkeling biedt voordelen op het gebied van

Kwaliteit

• generatie vangoede code

• nauwereaansluiting vansoftware oprequirements

Productiviteit

• codegeneratie

• afnamecommunicatieproblemen

• hergebruikmodellen

Onderhoud

• eenvoudigerbeheer



12 | 21MDD en kwaliteit

• Broncode kan worden gegenereerd• Voordelig voor ‘standaard’ applicaties

↑ standaardwerk =⇒ ↑ gegenereerde code• code hoeft niet het doel te zijn

• “Volwassen” modellen door hergebruik• dus ook: hergebruik van modellen van hoge kwaliteit

• Betere aansluiting op requirements door domeinkoppeling



13 | 21MDD en onderhoud

model model

code code

transformeerhandmatig

transformeerautomatisch

onderhoud

onderhoud

Figuur: Code- versus model-gebaseerd onderhoud

adapted from H. van Vliet (2008) Software Engineering: Principles and Practice Wiley



14 | 21MDD en productiviteit

• MDD maakt ontwikkelprocessen productiever doordat• veel code kan worden gegenereerd• modellen vergemakkelijken communicatie• hergebruik maakt ‘shortcuts’ mogelijk

• Weinig literatuur mbt. de bottom line• van 27 procent minder productief tot 400 procent productiever

◮ leereffecten (zeker bij zelf modellen en generatoren bouwen)◮ is MDD juist toegepast?

• “Too good to be true effect” maakt proponenten terughoudendin rapportages (Hutchinson 2011)



15 | 21Gevonden voordelen in de praktijk

ActivityProductivity Maintainability

IncreasedNot

UsedIncreased

NotUsed

Use of models for teamcommunication

73 % 7 % 66 % 6 %

Use of models forunderstanding aproblem at an abstractlevel

73 % 4 % 72 % 6 %

Use of models tocapture and documentdesigns

65 % 9 % 59 % 10 %

Use of domain-specificlanguages (DSLs)

47 % 32 % 44 % 33 %

Code generation 67 % 12 % 56 % 12 %

Model simulation/Executable models

41 % 38 % 39 % 35 %

adapted from J. Hutchinson et al. Empirical assessment of MDE in industry. ICSE 2011



16 | 21Praktijkvoorbeeld urenverdeling

0

10

20

30

40

50

60

0 20 40 60 80 100

effo

rt (%

)

time (%)

constr

construction

elaboration

elaboration

tran

incep.

transition

unpublished: Heijstek & Chaudron



17 | 21Potentiele valkuilen

• Design fase duurt langer (“WINCY probleem”)

• Risico op scope creep bij hergebruik modellen

• Late wijzigingen buiten scope hebben een potentieel hogereimpact

• Maintainers meer betrekken bij ontwikkeling

• Ontwerpers moeten zeer gedetailleerd modeleren

• De handgeschreven code vereist ervaren programmeurs

• “Collective Model Owernership”

• MDD is tool-afhankelijk• Ontwikkeling is sterk tool-gebaseerd• Sterke link tussen leverancier en implementatie (“lock-in”)

uit: Heijstek & Chaudron The Impact of MDD on the Software Architecture Process SEAA 2010


Modelgedreven Ontwikkeling in de PraktijkConclusie

18 | 21Conclusie

Modelgedreven ontwikkeling biedt potentieel grote voordelenen is een logische volgende stap in software ontwikkeling

• DSL biedt een specifieke taal voor uw domein

• Bij zelfbouw is een investering nodig• in kennis en tools• meer aandacht moet worden besteed aan de “early phases”• requirements moeten weer iets duidelijker voor implementatie

• Bij gebruik externe oplossing• zorg voor wijdverspreid begrip van DSL• verzeker je van een omgeving die flexibel genoeg is


Modelgedreven Ontwikkeling in de PraktijkConclusie

19 | 21Vragen?

?


Modelgedreven Ontwikkeling in de PraktijkContact Informatie

20 | 21Contact Informatie

Werner Heijstek

[email protected]

http://www.liacs.nl/˜heijstek

Snellius building room 150+31 (0) 71 – 527 7050

Ekiga: sip:[email protected]

Skype: wernerheijstek

[email protected]

http://www.liacs.nl/~heijstek


Modelgedreven Ontwikkeling in de PraktijkMeer informatie

21 | 21Gerelateerde literatuur

• B. Hailpern & P. Tarr (2006) Model-driven development:The good, the bad, and the ugly IBM Systems Journal

• J. Hutchinson, M. Rouncefield, J. Whittle Model-DrivenEngineering Practices in Industry ICSE 2011

• W. Heijstek & M.R.V. Chaudron The Impact of MDD on theSoftware Architecture Process Euromicro SEAA 2010

• International Conference on Model Driven EngineeringLanguages and Systems (MODELS)

• Heeft een omvangrijke “industrial-track”• Proceedings van afgelopen jaren zijn online terug te vinden

• 2011: 16 – 21 oktober, Wellington• 2012: 1 – 5 oktober, Innsbruck