Markus Völter voelter@acm voelter.de Thomas Stahl t.stahl@bmiag.de bmiag.de

1. Model-DrivenSoftware Development www.mdsd-buch.de Best Practices Markus Völtervoelter@acm.orgwww.voelter.de Thomas Stahl t.stahl@bmiag.de www.bmiag.de Note: This is an extract of a tutorial, which is an ongoing project. Updates of the slides can be found regularly at www.mdsd-buch.de Please check the site for updates, if you‘re interested.

2. C O N T E N T S • Domain Architecture • Domains, Metamodeling, Structuring • Code Generation • Architectural Issues • Tools • Features and Structure • Example • Process • Testing Model-DrivenSoftware Development www.mdsd-buch.de Best Practices

3. MDSD Main Terms DSL (e.g. Profile) Applikations- DSL Applikations- Application- Modell Modell Application-Code Model • Domain • Architecture • model driven • generative • domain specific • re-usable • implements a family of software Transfor-- mations Trans- formationen analyse separate Handcrafted Handcrafted Individual Code Code Code Platform Individual Code Gene- Plattform ric Code Repetitive Repetitive Code Code creates uses

4. Structure of Application Projects

5. Technical Subdomains • Structure your system into several technical subdomains such as persistence, GUI, deployment. • Each subdomain should have its own meta model and specifically, its own suitable DSL. • Define a small number of GATEWAY META CLASSES, i.e. meta model elements that occur in several meta models to help you join the different aspects together.

6. Gateway Metaclasses • Using TECHNICAL SUBDOMAINS results in different meta models as well as different concrete syntax for the different subdomains. • Example: workflow/using activity diagrams, Layout/ textual, XML-like language. • If you want to generate a system from these different specifications, your generator needs a mechanism to get from one model to the other: • you need model elements that are present in the meta models of both TECHNICAL SUBDOMAINS. IGNORING CONCRETE SYNTAX in your generator makes this simpler. • The second thing you need is a common meta meta model. For example, Java classes to be used as the meta meta model for all meta models.

7. Partitionen CRM Finanzbuch- haltung Personalwesen GUI SYSTEM Subdomänen Prozesse Persistenz Partitions vs. Subdomains

8. Model-Based Merging

9. Generator-Based Referencing

10. Levels of MDSD • You would typically start with architecture-centric MDSD where the abstractions of the DSL correspond to the core concepts of the technical platform. • This automates many aspects of the technical aspects; • Results in a wide platform/infrastructure • Many projects can be handled with the infrastructure • In later phases, functional MDSD infrastructures will be built on this technical one, resulting in cascaded MDSD: • The output of a higher Domain Architecture (DA) applied to a higher model can be an input model for the next lower DA. • The platform of a higher DA can be build with the aid of the next lower DA.

11. Levels of MDSD II - Cascading

12. Levels of MDSD III – M2M Transformations

13. Levels of MDSD III – M2M Transformations II

14. Levels of MDSD III – M2M Transformations III

15. Levels of MDSD III – M2M Transformations IV

16. C O N T E N T S • Domain Architecture • Domains, Metamodeling, Structuring • Code Generation • Architectural Issues • Tools • Features and Structure • Example • Process • Testing Model-DrivenSoftware Development www.mdsd-buch.de Best Practices

17. Separate Generated and Non-Generated Code • Keep generated and non-generated code in separate files. • Never modify generated code. • Design an architecture that clearly defines which artifacts are generated, and which are not. • Use suitable design approaches to “join” generated and non-generated code. Interfaces as well as design patterns such as factory, strategy, bridge, or template method are good starting points.

18. Separate Generated and Non-Generated Code II • A) Generated code can call non-generated code contained in libraries. • B) A non-generated framework can callgenerated parts. • C) Factories can be used to „plug-in“ the generated building blocks. • D) Generated classes can also subclass non-generated classes. • E) The base class can also contain abstract methods that it calls, they are implemented by the generated subclasses(template method pattern)

19. C O N T E N T S • Domain Architecture • Domains, Metamodeling, Structuring • Code Generation • Architectural Issues • Tools • Features and Structure • Example • Process • Testing Model-DrivenSoftware Development www.mdsd-buch.de Best Practices

20. Rich Domain-Specific Platform • Define a rich domain-specific application platform consisting of • Libraries • Frameworks • Base classes • Interpreters, etc. • The transformations will “generate code” for this domain-specific application platform. • As a consequence, the trans-formations become simpler.

21. Generator-based AOP • Implement the handling of cross-cutting concerns with the help of the generator. • You can either take advantage of the generator’s integral features (e.g. consider that it generates many instances of a meta model element with the help of one transformation/template), or • Weave various “aspect models” in the generator • Use the generator to implement proxies, interceptors and other AOP-addressing design patterns in the generated system. • Consider the cross-cutting concern a TECHNICAL SUBDOMAIN and provide a suitable DSL for it.

22. Descriptive Metaobjects • The generated application often needs information about some model elements at run time to control different aspects of the applicaton platform. • Use the information available at generation time to code-generate meta objects that describe the generated artifacts. • Provide a means to associate a generated artifact with its meta object. • You add a getMetaObject() operation to the generated artifact. • You can also use a central registry that provides a lookup function MetaRegistry.getMetaObjectFor(anArtefact). The implementation for the operations will be generated, too. • Make sure the meta objects have a generic interface that can be accessed by the RICH DOMAIN-SPECIFIC PLATFORM.

23. C O N T E N T S • Domain Architecture • Domains, Metamodeling, Structuring • Code Generation • Architectural Issues • Tools • Features and Structure • Example • Process • Testing Model-DrivenSoftware Development www.mdsd-buch.de Best Practices

24. Tools: Overview • Many kinds of tools can be used in the context of model driven development: • UML modelling tools • Metamodelling environments • (XMI) Repositories • Code Generators • Model verifiers • There is also a large amount of tools that are „MDA certified“. These range from completely integrated environments to simple code generators or technology specific generators (e.g. for J2EE).

25. Tools: The Ideal One • MOF Based Metamodelling, including OCL • Usage of thses metamodels for subsequent modeling of M1 • Metamodel specific repositoriy • GUI adapted to metamodel • Model Validation based on metamodel • Also including OCL • Transformation rules based on user-defined metamodels • Flexible Code Generation • Test support

26. Implement the Metamodel • Implement the meta model in some tool that can read a model and check it against the meta model. • This check needs to include everything including declared constraints. • Make sure the model is only transformed if the model has been validated against the meta model. • The meta model implementation is typically part of the transformation engine or code generator since a valid model is a precondition for successful transformation.

27. Modular Transformations • In order to more easily reuse parts of a transformation, it is a good idea to modularize a transformation. • Note that in contrast to the OMG, we do not recommend looking at, changing or marking the intermediate models. • They are merely a standardized format for exchangingdata among the transformations. • Example: Multi-Step transformation from a banking-specific DSL to Java via J2EE

28. Modular Transformations II • Example cont’d:Now consider a Call-Center application; only the first step needs to be adapted. • If both should be transformed to. NET, only the backend needs to be exchanged.

29. C O N T E N T S • Domain Architecture • Domains, Metamodeling, Structuring • Code Generation • Architectural Issues • Tools • Features and Structure • Example • Process • Testing Model-DrivenSoftware Development www.mdsd-buch.de Best Practices

30. Example Tool: openArchitectureWare Generator • Open Source, quite active projecthttp://www.openarchitectureware.org • Core Features: • Can read any model (XMI from various UML tools, UML, textual, JDBC, Java classes …) –i.e. concrete syntax is irrelevant • Can generate any kind of output • Explicit Domain-Metamodel (implemented in Java) • Semi-Declarative Metamodel Constraints, „Functional Programming“ • Simple, efficient template language • Template Polymorphism and Template overwriting • Multi-Model (Merging-Support)

31. Example Tool: openArchitectureWare Generator • Core Features cont‘d: • Inter-Model References among various model syntaxes (i.e. UML to XML) • Support for Aspects in the metamodel and in the templates • Arbitrary Namespace Models can be supported • Plugin-Based Generator configuration (ant-based) • Additional Features: • Syntax-Highlighting Template Editor for Eclipse • Metamodel can be generated from UML model, incl. DTD, HTML Docs, etc. • Graphical GEF-Based Editors can be generated • Dialog-Based Editors can be generated • Framework for building IDEs based on this Generator • Future Features • EMF Integration, Visio Integration

32. Example Tool: openArchitectureWare Generator • How it works:

33. Example Tool: openArchitectureWare Generator • Usage Examples • Web Development (J2EE, Servlets, Struts) • Banking, Insurances • Mobile Phone Software (C++ + QT, J2ME + Java) • Embedded Software (C, CANbus, Osek) • Automotive Component Middleware • (Interactive) Web sites • Architectural Management, „Entertainment) • Multi-Platform Middleware (XML, C++, Java, …) • Radioastronomy

34. C O N T E N T S • Domain Architecture • Domains, Metamodeling, Structuring • Code Generation • Architectural Issues • Tools • Features and Structure • Example • Process • Testing Model-DrivenSoftware Development www.mdsd-buch.de Best Practices

35. Iterative Dual Track Development • Develop Domain Architecture and at least one application at the same time. • Establish rapid feedback from application developers to Domain Architecture developers. • Develop both aspects iteratively and incrementally. Use strict timeboxing. • Domain Architecture develops iteration n+1 whereas application developers use iteration n. • Introduce new Domain Architecture releases only at the beginning of iterations.

36. MDSD Process • Domain Architecture Development

37. Adopting MDSD

38. C O N T E N T S • Domain Architecture • Domains, Metamodeling, Structuring • Code Generation • Architectural Issues • Tools • Features and Structure • Example • Process • Testing Model-DrivenSoftware Development www.mdsd-buch.de Best Practices

39. The Role of Testing in SW Development • Typically software cannot be verified formally, so it must be tested. • There are different kinds of tests: • Component tests (as JUnit) • Integration tests • Acceptance tests • GUI driven tests (as integration or acceptance tests) • Non functional tests • Performance and load tests • Regression tests • All these tests are relevant in an MDSD-Project. • Some of these tests can be optimized by MDSD or should have a special form in that context. • In MDSD we can separate tests of applications and Domain Architectures.

40. Unit Testing and MDSD • Separate test cases from test data • Generate the test infrastructure • Test cases based on (OCL-)constraints can be generated from the domain models • Generate Code for setup, execution and checking the postcondition, or • Generate Assertions within the application that are executed through integration tests • Eventually use a framework or interpreter to delegate the constraint evaluation/execution • Define testable architectures • Use or generate Mocks • Testware can be modelled (as decoration of the domain model) and generated.

41. Unit Testing Example • Consider the following model: • This could result in the following code: • A similar approach could be taken for the invariant in Person. • In case of the invariant, it is easy to automatically create a set of unit tests that check ages like 0, 16, 78, 120, -1, 3.4 and see if the system behaves accurately. class Vehicle { ... public void setDriver( Person p ) { if (driver.getAge() < 18 ) throw new ConstraintViolated(); }}

42. A new potential: Model Validation • In many cases it is possible to detect design errors already in the models. This step is called model validation. • The most „extreme“ form is to interpret and simulate the whole model; this is however, not simple to achieve, although there are „UML VMs“. • However, it is easily possible to verify design constraints in the model before model transformation or code generation steps are done.

43. Model Validation Example • Validation in the metamodel (Implemented) public class ECInterface extends generatorframework.meta.uml.Class { public String CheckConstraints() { Checks.assertEmpty( this, Attribute(), "must not have attributes." ); } // more … } public class Component extends generatorframework.meta.Class { public String CheckConstraints() { Checks.assertEmpty( this, Operation(), "must not have attributes." ); Checks.assertEmpty( this, Generalization(), "must not have superclasses or subclasses." ); Checks.assertEmpty( this, Realization(), "must not implement any interface." ); Checks.assertUniqueNames( this, Port(), "a component's ports must have unique names." ); } // more … }

44. Testing the Domain Architecture • Use a (generic) generator and assume it‘s correct (like you assume the Java compiler to be correct, when you write test code for your application). • Metamodel implementations, transformations and meta constraints (i.e. part of the Domain Architecture) are software and have to be tested though. • Don‘t write explicit unit tests for the transformations, because it would be an over-specification. • Test them implicitly by testing at application level • Modularity can be achieved by setting up small test „applications“ just covering one or few constructs from the DSL.

45. C O N T E N T S • Domain Architecture • Domains, Metamodeling, Structuring • Code Generation • Architectural Issues • Tools • Features and Structure • Example • Process • Testing Model-DrivenSoftware Development www.mdsd-buch.de THE END. Best Practices

46. Some advertisement  • Thomas Stahl, Markus Völter • Modellgetriebene SoftwareentwicklungTechniken, Engineering, Management • dPunkt.verlag • www.mdsd-buch.de • Out now !