1. page 1 Automatic Evaluation of Modelling Rules and Design Guidelines, July 2006 Automatic Evaluation of Modelling Rules and Design Guidelines Tibor Farkas, Christian Hein, Tom Ritter tibor.farkas@fokus.fraunhofer.de christian.hein@fokus.fraunhofer.de tom.ritter@fokus.fraunhofer.de tibor.farkas@fokus.fraunhofer.de christian.hein@fokus.fraunhofer.de tom.ritter@fokus.fraunhofer.de

2. page 2 Automatic Evaluation of Modelling Rules and Design Guidelines, July 2006 Overview quality of software our definitions how to evaluate experiences in automotive domain summary

3. page 3 Automatic Evaluation of Modelling Rules and Design Guidelines, July 2006 Quality of Software quality of software was and is still a big topic in scientific world and as well in industry in traditional development processes program code like C++ has to follow specific coding rules and style guidelines aims of such rules and guidelines - make the code readable - make the language easier to use

4. page 4 Automatic Evaluation of Modelling Rules and Design Guidelines, July 2006 Quality of Software example of a coding style guideline for C++ taken from NASA Flight Software Branch: C++ Coding Standard Logical operators shall not be used on non-Boolean values Acceptable int x; // code that modifies x if( x==0 ) { // do something } Not Acceptable int x; // code that modifies x if( !x ) { // do something }

5. page 5 Automatic Evaluation of Modelling Rules and Design Guidelines, July 2006 Quality of Models in order to get high-quality software systems high-quality models are needed techniques like model transformation and code generation are used to produce automatically or semi-automatically software systems from design models the modeller, who designs a system, has a difficult task and takes high responsibility - likewise to coding rules and style guidelines in traditional development process, the modeller could obey modelling rules and design guidelines for models - examples for UML2 modelling: don’t use association classes every actor must refer to an use case each operation must be commented each parameters must have a name

6. page 6 Automatic Evaluation of Modelling Rules and Design Guidelines, July 2006 Definitions Quality of Models - a set of properties of a model which are of interest in a specific situation or scenario. - each of the properties has a value space (dimension) in which an ordering relationship is defined Modelling Rules - are strict - do constrain the concept space that is defined by a metamodel, which is typically described by a using metamodel language like MOF - for example: a UML2 model is incorrect when it contains an actor which has no name. Design Guidelines - guidelines influence the system in an indirect way - design guidelines must not be strict - for example: all class names have to start with a capital letter

7. page 7 Automatic Evaluation of Modelling Rules and Design Guidelines, July 2006 Evaluation of Modelling Rules and Design Guidelines There are some conditions for an automatic evaluation of modelling rules and design guidelines - have to specified with a formal specification language (precise, unambiguous) - have to formulated at meta-model level to condition all models which are instances of the meta-model for our case study we have taken OSLO - implementation of OCL 2.0 - independent from modelling framework - allows constraints evaluation against meta-models

8. page 8 Automatic Evaluation of Modelling Rules and Design Guidelines, July 2006 Evaluation of Modelling Rules and Design Guidelines models and corresponding metamodel guidelines result chief software architect modeller designs input parameter evaluates guidelines broken guidelines obeyed

9. page 9 Automatic Evaluation of Modelling Rules and Design Guidelines, July 2006 Experiences in automotive domain: Development of Automotive Software in MATLAB/Simulink/Stateflow virtually design embedded controllers directly in various block diagrams Abstraction, Modelling & Simulation customizable set of block libraries System behaivior modelled through Statecharts

10. page 10 Automatic Evaluation of Modelling Rules and Design Guidelines, July 2006 Experiences in an automotive domain How to automate the evaluation of complex design guidelines for the development of automotive control systems ? Guideline: Prohibited Elements

11. page 11 Automatic Evaluation of Modelling Rules and Design Guidelines, July 2006 Idea: OCL Rule-Checking based on a Meta-Model OCL Guidelines Analyses Development Tool OCL Engine Simulink Model MOF Meta-Model

12. page 12 Automatic Evaluation of Modelling Rules and Design Guidelines, July 2006 Sample: Engine timing model with constraint violation

13. page 13 Automatic Evaluation of Modelling Rules and Design Guidelines, July 2006 Constraint violations found in the Simulink Modell Violation 1: - The Throttle and Mainfold (type of Subsystem) violating the default background color setting: white. Violation 2: - The Compression Block (type of Subsystem) violating the specified font-size of 10. Violation 3: - The usage of the block Engine Speed (type of Scope) is prohibited. Violation 4: - The designation of Throttle Deg (type of Scope) exceeds the allowed length.

14. page 14 Automatic Evaluation of Modelling Rules and Design Guidelines, July 2006 Constraint violations defined in the Object Constraint Language OCL evaluation on violation 1: All elements must have the same common background colour: white. context Diagram inv: theContainedElements->select(b | b.oclIsKindOf(SLBlock) and b.oclAsType(SLBlock).colorBackground<>'white') OCL evaluation on violation 2: All elements (blocks, signals, labels...) must have the same common font style and font size. The specified font-size is 10. context Diagram inv: theContainedElements-> select(b | b.oclIsKindOf(SLBlock) and b.oclAsType(SLBlock).fontSize<>10)

15. page 15 Automatic Evaluation of Modelling Rules and Design Guidelines, July 2006 Constraint violations defined in the Object Constraint Language OCL evaluation on violation 3: The usage of the block Scope is prohibited. context Diagram inv: theContainedElements->select(b | b.oclIsTypeOf(Scope)) OCL evaluation on violation 4: The name of all elements should not exceed the maximum length of 31 characters. context Diagram inv: ASDElement.allInstances()->forAll(i | if i.name. oclIs Undefined() then true else i.name.size() <= 31 endif )

16. page 16 Automatic Evaluation of Modelling Rules and Design Guidelines, July 2006 comfortable graphical user interface for model analyses Automated evaluation of automotive specific development models

17. page 17 Automatic Evaluation of Modelling Rules and Design Guidelines, July 2006 Summary automatic evaluation is possible OCL is hard to learn, therefore the acceptance in industry world is similar to traditional formal languages like Z guidelines in natural language are sometimes ambiguous or not precise: - example: “All model components should have a meaningful identifier given”

18. page 18 Automatic Evaluation of Modelling Rules and Design Guidelines, July 2006 Outlook OCL is hard to learn and not much acceptance - collect constraints into packages to hide OCL - how to reuse such packages for different meta-models parameter ? metrics are another interesting topic for quality of models - compute metrics with OCL, also with metric packages - generic metrics for different models ? - how to evaluate complex metrics ? (not only the number of classes etc)

19. page 19 Automatic Evaluation of Modelling Rules and Design Guidelines, July 2006 References NASA Flight Software Branch: C++ Coding Standard, 2003 OSLO – Open Source Library for OCL. http://oslo-project.berlios.dehttp://oslo-project.berlios.de OCL – Object Constraint Language 2.0 Specification. http://www.omg.org/docs/ptc/05-06-06.pdf http://www.omg.org/docs/ptc/05-06-06.pdf The MathWorks Inc. MATLAB/Simulink/Stateflow URL: www.mathworks.com