Making Models Matter

Making models matter Experiences with Model Driven Software Development Karsten Thoms Software Architect 2009-02-04 Advanced Topics in Software Construction 2008, b-it 2008 © itemis AG 2009 – All rights reserved 1

Karsten Thoms • Software Architect at itemis • Main interests • Java Enterprise Systems • Model Driven Software Development • Team Member on the openArchitectureWare project since 2004 • Current activities • Integration concept for AUTOSAR into the ECU development platform at Robert Bosch GmbH, Stuttgart • Consulting for MDSD and openArchitectureWare at Deutsche Börse Systems AG, Frankfurt © itemis AG 2009 – All rights reserved 2

Before we start... • Following we will point out some critical issues, misconceptions and wrong promises about model driven software development. • Anyway, producing software with the use of models is the right way to go and helps to create better software efficiently! © itemis AG 2009 – All rights reserved 4

„MDA is revolutionary“ • Producing software from models is common practice for ages • Most approaches have severe limits and were heterogeneous (e.g. CASE) • MDA has helped to create a new awareness for automated software production • The principles of MDA are good, but mostly not new © itemis AG 2009 – All rights reserved 6

„MDA is a standard“ • What exactly does MDA standardize? • Where is a specification document that standardizes • ... how transformation marks look like ? • ... what the requirements for a tools and processes are to be „MDA compliant“ ? • The MDA Guide is the only official specification alike document about MDA itself • it has 62 pages (the UML2 spec has 1,000!) • current (!) state is release 1.0.1 from June 2003 © itemis AG 2009 – All rights reserved 7

„MDA models are defined in UML“ • The MDA Guide does not require anywhere that models are expressed in UML • MDA just requires that models are MOF compliant • Why are so many books and articles confusing this ? • MOF compliant models even not require to have a visual concrete syntax © itemis AG 2009 – All rights reserved 8

„XMI is a standardized exchange format“ • XMI standardizes how data is exchanged with XML, not which data • Even UML tools using the same UML version and same XMI version are likely to use incompatible formats • Eclipse EMF UML2 is an example that things change to good • Some UML tools export even invalid XML © itemis AG 2009 – All rights reserved 9

„MDA compliant standard tools are available on the market“ • Where is defined what a tool requires to be „MDA compliant“ ? • If platform independency is a key aspect of MDA, how should „MDA compliant“ tools ever be interoperable ? • Why do „MDA compliant“ tools only have bindings to specific platforms (e.g. JavaEE) if one key concept is platform independence ? • What is the differentiation between a „standard MDA tool“ and an ordinary CASE tool ? • MDA = CASE 2.0 ? © itemis AG 2009 – All rights reserved 10

MDA vs. Model Driven Software Development (MDSD) • We use MDSD, not MDA ! (Although we follow the main principles of MDA) • MDSD • pragmatic approach • avoiding redundancies (DRY: Don‘t Repeat Yourself) • choosing the most suitable modeling language to describe the problem domain • Domain centric and tool oriented © itemis AG 2009 – All rights reserved 11

„80 - 100% of code can be generated“ • Degree is highly dependend on the platform • „Good“ generic platforms require less code generation (e.g. Grails, Spring) • Only schematic code can be generated © itemis AG 2009 – All rights reserved 12

UML2 • Standardized modeling language • Availability of education, books, trainings • Simple concepts well known (Classes, State machines, Activities) • Necessary details not known, documented, educated • Many weaknesses in the metamodel • Not defined how to model specific situations • Important aspects of software systems cannot be expressed in the UML notation • GUIs, Transformations, Business Rules • Tool problems: Teamwork, diffing, merging, fast editing, details, profile evolution, refactoring © itemis AG 2009 – All rights reserved 15

Textual Domain Specific Languages • Textual language that can express domain knowledge compact • May be hosted in a GPL (internal DSL) or on its own (external DSL) • Textual artefacts have good support by development tools © itemis AG 2009 – All rights reserved 18

Choosing the right modeling language and tools • How often do you with your model / code ... • edit • view • navigate through • compare • merge • Can your problem domain be described adequate with the modeling language ? • Who will create the models ? © itemis AG 2009 – All rights reserved 22

Up-front approach • Project decides to use a model-driven approach from the start and in most possible extend • Chances • Wide coverage of target architecture • Complete product described with models from the early beginning • Highest benefits in long-term • Challenges • Must be decided by management • High experience about modeling and code generation necessary • Resistence from developers © itemis AG 2009 – All rights reserved 24

Bottom-up approach • Introduce modeling and code generation step by step for defined parts of the system • Chances • Cover first the parts with the highest benefits, extend whenever further parts are identified • Enables introduction of model-driven approach in conventional implementation or legacy systems • Smaller steps can be handled more easily • Challenges • Might lead to heterogenous tooling • Continuous refactoring of modeling languages and tools necessary © itemis AG 2009 – All rights reserved 25

Clearer seperation of project roles • Architects define the overall structure of the system, provide framework and the reference implementation, and define the modeling language • MDSD experts create and maintain code generator and surrounding tool chain • Domain developers use the modeling language to define the system and generate glue code • Developers implement the business logic and all artefacts that are not covered by modeling © itemis AG 2009 – All rights reserved 26

Implications for implementation • Chances • Software developers can focus on the real business logic • Less knowledge about technical details necessary • Specialization necessary, less generalism needed • Challenges • Software developers might not know enough details to locate and fix bugs • Real experts about technical domain needed to create reliable generated and generic code © itemis AG 2009 – All rights reserved 27

Role of the reference implementation and reference model • The reference implementation • is a minimal implementation that uses all elements of the target architecture • is more than a prototype • must be maintained • The reference model • describes the reference implementation as a software model • must also be maintained • documents modeling patterns by example © itemis AG 2009 – All rights reserved 28

Being agile with MDSD ? • MDSD can be used in any development process • RUP, V-Modell, Scrum, XP, ... • Model transformations must be flexible for extenions and requirement changes • Problematic: Metamodel evolution, model migration © itemis AG 2009 – All rights reserved 29

Case Study: Insurance Suite • Environment • Propiarity frameworks based on standard frameworks and platforms (Persistence with bidimensional historization, Java/CICS bridge for DB/2 on Mainframe, long-running business transactions, ...) • ~20 team members, 1.5 years development = 30 man years • 1st product implemented with conventional development • Prototyping, Framework development, Design patterns, only seniors • Typical problems • Pattern and framework evolution not propagated to already implemented modules • Increasing code entropy © itemis AG 2009 – All rights reserved 31

Case Study: Software Vendor, Staff Management • First product version early 80‘s; Pascal, AS/400, Terminal • Product established over 25 years • Using software models to generate code from for 15 years • Team: • ~8 core technology • ~40 domain developers • ~40 consultants • Platform changes only possible through code generation • Other competitors failed with re-implementations © itemis AG 2009 – All rights reserved 32

Case Study: Banking • UML2 only used for domain model • All other software parts defined with textual DSLs (Xtext based) • Seamless integration of different models into one process • Company has experience with code generation over 10 years • Problem domain is highly critical in functionality and scalability • ~ 150 Business entities • > 1000 data message structures • 200.000 - 400.000 transactions / second required in peek • target platform Java and C++ © itemis AG 2009 – All rights reserved 33

Case Study: Health Insurance • Software developed for all german governamental health insurances • About 100 developers • Most developers develop models and implement business logic and do not care about technical details • Over 500 man years development • Code base would not be handlable without model-driven development © itemis AG 2009 – All rights reserved 34

Case Study: Automotive • Software for electronic control units is specified highly by models • Complexity not handleble without tools • Commonly textual models are used • Generated code is highly specialized and optimized • UML not used at all, alternative not MOF based standards commonly used • AUTOSAR, Manufacturer Supplier Relationship (MSR) © itemis AG 2009 – All rights reserved 35

Conclusions • There is no need to be „MDA compliant“ to be successful with model driven development • Don‘t rely on standards if they are not appropriate to solve the problem • Use a pragmatic approach • Let the architecture drive the tools and processes, not vice versa • Create and maintain a reference implementation and a reference model • Choose modeling languages appropriate to describe the domain • Development of model transformers are projects in parallel to the application development • Models are only useful if they can raise the level of abstraction © itemis AG 2009 – All rights reserved 37

Conclusions • Model driven software development help to handle complexity and counteract software entropy • Requires rethinking for project managers and developers • MDSD does not require a „big bang“ introduction • May also help to handle legacy systems • Enables better role seperation • Enables technology evolution with less risk • Ensures consistent documentation of the developed systems • Adapted by a growing number of companies and projects of all scale © itemis AG 2009 – All rights reserved 38

Making Models Matter

0 comments

Notes on slide 1

1 Favorite