Roles in Software Development using Domain Specific Modelling Languages Holger Krahn, Bernhard Rumpe, Steven Völkel Software Systems Engineering Technische Universität Braunschweig

cvs://mc/doc/praesentationen Holger Krahn Software Systems Engineering TU Braunschweig Seite 2 Roles in Software Development using Domain Specific Modelling Languages An agile development process involving DSMLs1.HMI example2.MontiCore3.Conclusion4.

cvs://mc/doc/praesentationen Holger Krahn Software Systems Engineering TU Braunschweig Seite 3 Problem setting: Using off-the-shelf generators  Off-the-shelf generators DSMLs cannot be changed on demand → Notations are not domain-specific as possible Generator using templates can be changed → But: General structure of generation is not changeable  Modification of generated code is often needed → Round-Trip is often not possible Desired modification of code cannot be expressed in DSML DSML instance developer generated code Handwritten code product developer

cvs://mc/doc/praesentationen Holger Krahn Software Systems Engineering TU Braunschweig Seite 4 Tool development inside the project: Roles in Process using DSMLs  Language developer defines or enhances an existing DSML  Tool developer writes code generators for DSML comprises tools  Product developer uses tools developed in the project to influence outcome  Library developer develops software libraries Thereby simplifies the code generator DSML code generator language developer product developer DSML instance library developer generated code SW-Library tool developer

cvs://mc/doc/praesentationen Holger Krahn Software Systems Engineering TU Braunschweig Seite 5 Principle: The generated code is never changed  Generated code is never changed manually not part of the source code shared between developers (Only DSMLs and hand-written code are shared)  Pros round-trip engineering is not needed no inconsistencies between generated code and DSML build process is clear to understand and can be automated DSMLs and hand-written source code are the primary artifacts that determine the behavior of the resulting system  Cons/Additional requirements this approach Generated code needs interfaces to interact with manual code DSMLs need gaps where exceptions of the standard generation can be specified

cvs://mc/doc/praesentationen Holger Krahn Software Systems Engineering TU Braunschweig Seite 6 Human-Machine-Interfaces  Human-Machine-Interfaces (HMIs) in cars provide user interface have different functionality depending on the configuration of the car  Main reasons for using DSMLs and code generation Separate menu structure (which might change rapidly during development) from look&feel (that is fixed for a manufacturer) Ensure by design that the HMI software can handle multiple configurations correctly status bar central panel buttons

cvs://mc/doc/praesentationen Holger Krahn Software Systems Engineering TU Braunschweig Seite 7 Roles in the HMI example generates input uses DSLTool framework (Part of MontiCore) HMI Software Feature DSL processor Menu DSL processor Manually defined generator Manually written HMI-Library Feature Diagram Menu Structure Diagram DSML Menu Diagrams DSML Feature Diagrams MontiCore code generator MontiCore code generator defines language developer product developer defines library developer tool developer designs programs assembles programs

cvs://mc/doc/praesentationen Holger Krahn Software Systems Engineering TU Braunschweig Seite 8 Agile Values & Methods  Communication DSMLs allow to communicate in domain specific notations  Simplicity As generated code is strictly not modified: models and handwritten code are used at same level of abstraction (they are the primary development artifacts) Language-based approach: For domain experts possibly easier to understand than (meta)metamodels  Feedback On-site customer: Might be a product developer (who directly influences the resulting software)

cvs://mc/doc/praesentationen Holger Krahn Software Systems Engineering TU Braunschweig Seite 9 Agile Values & Methods  Courage Courage is needed to change DSML or generator  Humility Different stakeholders have different expertise: Directly reflected in the different roles  Continuous Integration text-based approach allows to use standard versioning systems no release plan for internal tool in project is needed, because it can be automatically build on demand  Refactoring Refactoring should work on interacting source code and models  Testing models can be used for production code and testing

cvs://mc/doc/praesentationen Holger Krahn Software Systems Engineering TU Braunschweig Seite 10 Features of MontiCore supporting an agile development process  Generation of reusable language components for different tools and use inside other languages  Generation of Java source code that can be easily integrated in other applications  Standardized solution for implementing a generator model traversal file and error handling processing of DSML separated in transform and workflow layer template engine partially supporting generator refactoring  Reusable ant scripts to compile a project whenever an artifact is changed DSML definition DSML instance code generator hand-written source code

cvs://mc/doc/praesentationen Holger Krahn Software Systems Engineering TU Braunschweig Seite 11 Conclusion  Transfered agile values & methods for code-based development to a process where DSML are used  Explained the different roles developers play in such an process  Agility is improved by Making the on-site customer a first class developer DSMLs support the communication  Principle of not modifying generated code ensures that models and code are used at the same level of abstraction  MontiCore simplifies the development of tools inside an agile project  Open issues How do Refactorings look like that are applied to interacting DSMLs and source code? Which predefined DSMLs are frequently required?