The rcos Modeler ICTAC Summer School 2013 ECNU, Shanghai, China Volker Stolz, Zhiming Liu
Benefits of Modeling Given the right models, we get for free: executable program user interfaces test cases (model-based testing) simulation verification
More Traditional Modeling UML class diagrams (boring) Components / Deployment Sequence diagrams / state machines (behaviour - now we are talking!) (Software) Product Lines: models of customization
More Traditional Modeling UML class diagrams (boring) Components / Deployment Sequence diagrams / state machines (behaviour - now we are talking!) (Software) Product Lines: models of customization
More Traditional Modeling UML class diagrams (boring) Components / Deployment Sequence diagrams / state machines (behaviour - now we are talking!) (Software) Product Lines: models of customization
More Traditional Modeling UML class diagrams (boring) Components / Deployment Sequence diagrams / state machines (behaviour - now we are talking!) (Software) Product Lines: models of customization
Level of abstraction Publication Contract Design Implementation Hierarchy of components Multi-view Interaction Diagram State Machine Diagram Class Diagrams Functionality Specification 4
Modeling Levels: OMG Platform independent model PIM-to-PSM: 50-70% automation CORBA, RMI,... Platform specific model PSM-to-code: full automation Java, C++,... Executable code 5
PIM: sub-divisions PIM Component Model Components Comp. sequence diagrams Composition/deployment Design Model Object (sequence) diagrams OO designs (executable) Requirements Model Class model Contracts (relational functionality specification) Dynamic behaviour (state machine, sequence diagram) 6
PIM: sub-divisions PIM Component Model Components Composition/deployment Comp. sequence diagrams Design Model Object (sequence) diagrams OO designs Requirements Model Incremental change Class model Contracts (relational functionality specification) Dynamic behaviour (state machine, sequence diagram) 7
PIM: sub-divisions PIM Component Model Incremental change Design Model Components Composition/deployment Comp. sequence diagrams Object (sequence) diagrams OO designs Requirements Model Class model Contracts (relational functionality specification) Dynamic behaviour (state machine, sequence diagram) 7
PIM: sub-divisions PIM Component Model Incremental change Design Model Components Composition/deployment Comp. sequence diagrams Object (sequence) Revising design diagrams OO designs decisions costly! Requirements Model Class model Contracts (relational functionality specification) Dynamic behaviour (state machine, sequence diagram) 7
Cost of Fixing Defects Relative cost 30 Requirements Architecture Construction System Test Post-Release Phase detected 22.5 15 7.5 0 Phase introduced: Requirements Architecture Construction Source: McConnell, Code Complete, Microsoft Press, 2004 8
Cost of Fixing Defects Relative cost 30 22.5 Requirements Architecture Construction System Test Post-Release Can we reduce the cost of change? Phase detected 15 7.5 0 Phase introduced: Requirements Architecture Construction Source: McConnell, Code Complete, Microsoft Press, 2004 8
Model Transformations In general: not necessarily applied to software engineering mathematical/algebraical different underlying formalisms, e.g.: triple graph grammars (by A.Schürr 94) imperative (Kermeta, 05) hybrid imperative/declarative (ATL 05, smartqvt 07) lowest level: XSLT/XQuery 9
Simple Transformations Model-to-Code: UML class diagrams to Java/C++ skeletons Test-case generation Verification (CSP, SPIN, SAT-solvers) Model-to-Model: Refactorings on UML class diagrams UML sequence diagrams state machines 10
Standards and Tool Support OMG standardised QVT transformation language (relational vs. operational) Software Engineering community standardises on UML Model interchange standardised on XMI Modeling supported by major tools: IBM Rational, Eclipse EMF/UML, MagicDraw 11
Modeling Languages UML (mostly static structure) rcos (OO, specification) Creol/ABS (OO, active objects) VDM/Overture JCSP (CSP for Java) 12
Modeling Languages UML (mostly static structure) rcos (OO, specification) Creol/ABS (OO, active objects) VDM/Overture JCSP (CSP for Java) Only UML and rcos use XMI: Interchange with other UML tools. All others: text files. 12
The Code is the Model(?) Problem: connection model code Generated code may need manual modifications. Solutions: add annotations to code (Frameworks like Spring,...) Round-trip engineering support (difficult/fragile, e.g. NetBeans) 13
Modeling: Static View Model developed once Then, processed for various consumers model T1 T2 T3 code testcases verifier input Very static view of development! 14
Modeling: Static View Model developed once Then, processed for various consumers model SPL Product T1 T2 T3 code test... code testcases verifier input Very static view of development! 14
But where s the Process? Different developers collaborate Different modeling levels/views Intermediate models for back-ends Models evolve over time (also: versioning) 15
Intermediate Models Initial model Refinement r. model testcases... code abs. model verifier input Models need to be refined/abstracted, leading to intermediate models! 16
Intermediate Models Initial model Refinement r. model testcases... code abs. model verifier input Models need to be refined/abstracted, leading to intermediate models! 16
rcos Language/Modeler Making software engineering easier: Multi-view specifications: different views for different roles Refinement of designs: correct-by-construction editing steps Verification/Testing part of the process 17
Use case = Structure + Behaviour Use case-driven Component-based Model-driven (based on UML) Multi-View Specification Verification Testing Code generation 18
Multi-View Specification Different views for different tasks: Sequence diagrams for customer State machine for internal state change Consistency check required 19
Component Model Substitutability Hierarchical composition Design-by-Contract Compatibility check required! (slight differences to UML) 20
Behaviour Functional Correctness Behaviour specification is not enough Also need to be able to specify computation Specification-level: Pre/Post (Hoare), OCL Executable level: sequence of destructive updates (C, Java,...) Tools should support both levels for verification (usually: bolted on, e.g. JML) 21
Refinement Refinement steps......make program more concrete...preserve semantics Simple refinement vs. custom step Former: correct-by-construction Latter: need additional verification create proof obligation (MDD!) 22
rcos: Theoretical Foundation Relational calculus and semantics based on Hoare & He s Unifying Theories of Programming [TCS06] Refinement calculus for both functional refinement and structure refinement [ibid.] Support analysis, design, refactoring and code generation [ICTAC05] rcos methodology for Soft.Eng. [ISoLA06, FCSC12]
Example: Expert Pattern Cashdesk::finishSale() { [ sale null sale.complete' = true]; var double sum; sum 0; for (LineItem l : sale.lines) { [ sum' = sum + l.subtotal] }; [ sale.total' = sum]; end sum } 24 Cashdesk::finishSale() {[ sale null sale.finishsale() ]} Sale::finishSale() { [ complete' = true]; var double sum; sum := 0; for (LineItem l : lines) { [ sum' = sum + l.subtotal] }; [ total' = sum]; end sum }
Model Transformations Design Patterns provide standard solutions to common tasks Transformations......automate patterns...refine the design...reduce manual development Need to be correctnesspreserving, track proof obligations [Morisset, 2011] Increasing detail Func. Spec. OO Model Time Components Increasing views [UML&FM 09/J.ISSE] 25
Model Transformations Design Patterns provide standard solutions to common tasks Transformations......automate patterns...refine the design...reduce manual development Need to be correctnesspreserving, track proof obligations [Morisset, 2011] Increasing detail Refinement Func. Spec. OO Model Time Components Increasing views [UML&FM 09/J.ISSE] 25
Model Transformations Design Patterns provide standard solutions to common tasks Transformations......automate patterns...refine the design...reduce manual development Need to be correctnesspreserving, track proof obligations [Morisset, 2011] Increasing detail Refinement Func. Spec. Transform OO Model Time Components Increasing views [UML&FM 09/J.ISSE] 25
Model Transformations Design Patterns provide standard solutions to common tasks Transformations......automate patterns...refine the design...reduce manual development Need to be correctnesspreserving, track proof obligations [Morisset, 2011] Increasing detail Refinement Func. Spec. OO Model Time Transform Components Increasing views [UML&FM 09/J.ISSE] 25
PIM: sub-divisions PIM Component Model Components Comp. sequence diagrams Composition/deployment Design Model Object (sequence) diagrams OO designs (executable) Requirements Model Class model Contracts (relational functionality specification) Dynamic behaviour (state machine, sequence diagram) 26
OO-to-CSD Design process for object interactions (FACS 11) Instead of writing interaction (a.k.a. method calls ) in OO-code, use sequence diagrams Advantage: objects visible Assign objects to components interactively 27
Summary Models are good for you: formal meaning (contracts) their design clarifies intention automatic processing model transformations reduce costs
Trying out rcos Eclipse Helios rcos Eclipse update site: http://rcos.iist.unu.edu/eclipse/ Download the example models TOPCASED 29