Overview

1. Automatic Evaluation of Modelling Rules and Design GuidelinesTibor Farkas, Christian Hein, Tom Rittertibor.farkas@fokus.fraunhofer.dechristian.hein@fokus.fraunhofer.detom.ritter@fokus.fraunhofer.de

2. Overview • quality of software • our definitions • how to evaluate • experiences in automotive domain • summary

3. 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. 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 Not Acceptable int x; // code that modifies x if( !x ) { // do something } Acceptable int x; // code that modifies x if( x==0 ) { // do something }

5. 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. 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. 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. Evaluation of Modelling Rulesand Design Guidelines modeller chief softwarearchitect designs models and corresponding metamodel guidelines input parameter input parameter evaluates result guidelines broken guidelinesobeyed

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

10. 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. Idea: OCL Rule-Checkingbased on a Meta-Model OCL Guidelines MOF Meta-Model OCL Engine Development Tool Simulink Model Analyses

12. Sample: Engine timing model with constraint violation

13. Constraint violations foundin 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) violatingthe 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. Constraint violations definedin 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. Constraint violations definedin 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. oclIsUndefined() then true else i.name.size() <= 31 endif )

16. comfortable graphical user interface for model analyses Automated evaluation of automotive specific development models

17. 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. 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. References • NASA Flight Software Branch: C++ Coding Standard, 2003 • OSLO – Open Source Library for OCL. http://oslo-project.berlios.de • OCL – Object Constraint Language 2.0 Specification. http://www.omg.org/docs/ptc/05-06-06.pdf • The MathWorks Inc. MATLAB/Simulink/Stateflow URL: www.mathworks.com