A Tooling Environment for Quality-Driven Domain-Specific Modelling

1. A Tooling Environment for Quality-Driven Domain-Specific Modelling Janne Merilinna

2. The Problem • There is a gab between requirements engineering and software engineering • This has caused separate processes, methods and tools • Requirements engineers produce ambiguous requirements, especially quality requirements, that software engineers don’t know how to implement 3. Requirements engineers might not be aware of what design alternatives are utilized thus preventing them to do impact analysis => The requirements and the software design and implementation start living separate lives 2. Designers don’t know the big picture when they choose between different design alternatives => Impact of different design alternatives to the overall system is not known if even recognized

3. The Goal There is a need to bridge the gab between requirements engineering (RE) and software engineering (SE) Considering SE, the following is required: Quality requirements have to be explicitly expressed and connected to corresponding design entities Promotes designers to understand the quality requirements Promotes traceability of quality requirements Quality attributes have to be observable Evaluation and measurement methods and mechanisms have to be available Quantitatively (execution-time quality attributes) Qualitatively (execution- and evolution-time quality attributes) Quality attributes have to be modifiable Mechanisms and patterns must be available to affect the quality

4. The Context • Model-Driven Development (MDD) • Domain-Specific Modelling (DSM) • The DSM basic architecture • In-house metamodels, i.e. modelling languages • In-house code generators • In-house software framework • Full code generation! • The modelling language and code generator specific to very restricted domain enable complete code generation • Quality-driven DSM (QDSM) • In single model there would be: • Quality requirements that are connected to corresponding entities in the models • Information on what has been done to satisfy the quality requirements • Means available to alter the quality • Evaluation/test results • MDD/DSM/QDSM is heavily dependent on provided tool support! • I have not seen demonstrations on QDSM • Lets build one and see if it is useful and what are the pitfalls • MetaCase MetaEdit+ as a QDSM tool

5. The Context- M-Net Modelling Language • Domain-Specific Modelling Language for M-Net • M-Net modelling language for stream-oriented computing systems (lab example) • Filters • Data streams • Displays • Controllers (switches, comparators) • Python code generator • Complete code generation

6. Functional Requirements According to functional requirements, an application is modelled Functional requirements: R1: Sepia conversion R2: Saving sepia converted stream of bitmap images as JPG images R3: Tilt video stream 90 degrees right for display R4: Show sepia converted and tilted stream

7. Functional Requirements According to functional requirements, an application is modelled Functional requirements: R1: Sepia conversion R2: Saving sepia converted stream of bitmap images as JPG images R3: Tilt video stream 90 degrees right for display R4: Show sepia converted and tilted stream • What about quality requirements?

8. Quality requirements Display framerate 25fps Application throughput more than 10fps Quality Requirements

9. Quality requirements Display framerate 25fps Application throughput more than 10fps Measurable quality requirements are connected to corresponding parts in the application model Easier to see what parts of the application model are responsible for the requirements Quality Requirements

10. What quality attributes the application model promotes? Reporting mechanism Code generation -> execution -> run-time reporting back to model via MetaEdit+ SOAP API Testing and measuring the application reveal how the application performs but does not reveal the design rationale Testing

11. Three techniques to express the impact to quality Quality per model entity Model entities provide configuration mechanisms to affect the quality Pattern-based Quality discernible by scrutinizing interaction of model entities Combination on the preceding Affecting and Evaluating the Quality

12. Design alternatives for increasing performance of IO Quality per model entity There is a set of alternative configuration mechanisms for model entities Code generation is affected There has to be configuration mechanisms for affecting the quality Affecting and Evaluating the Quality

13. Affecting and Evaluating the Quality Design alternatives for increasing performance of IO Pattern-based technique The metamodel includes automated modelling-time pattern recognition that tags corresponding model entities Code generation not affected The quality is affected by model entity interaction, not by configuration

14. Affecting the Quality Optimization of quality with optimization assistant Evaluates the model and generates guidance to modeller how to optimize the model according to required properties Patterns and design example catalogues and their linkage to promoted qualities Tool support with NFR+ Framework (current work!)

15. Tool support for Quality-Driven Domain-Specific Modelling is feasible to implement Quality requirements explicitly expressed in application models Measurable qualities (execution-time qualities) easy to define but what about evolution-time qualities? Are templates domain-specific? Affecting the quality Mechanisms embedded to the metamodel and their impact on quality expressed in models Optimization assistant More experience is required! Evaluating the quality Measuring mechanisms Great aid! Pattern recognition Probably not a great idea but possible to implement Current work NFR+ Framework Seems to be a better solution Conclusion

16. Questions?