6 th Framework Programme (IST-FP ) A Domain-Specific Metamodel for Reusable Object-Oriented High-Integrity Components Matteo Bordin and Tullio Vardanega University of Padua, Italy The 7 th OOPSLA Workshop on Domain-Specific Modeling Montreal, October 21-22, 2007

OOPSLA DSM Workshop / 16 - Contents 1.The domain 2.Model-driven engineering 3.Constrained object-oriented modeling 4.Implementation technologies 5.Conclusions

OOPSLA DSM Workshop / 16 - High-Integrity Systems The domain DO-178B MIL-STD 882B Def-Stan 0055 DO-178B MISRA IEC 880 IEC Up to 2/3 of development costs on V&V

OOPSLA DSM Workshop / 16 - High-integrity systems: a SW perspective The domain Pros: Abstraction, Automation (correctness by construction) Cons: Model-to-executable distance (difficult analysis) Pros: Adaptive reuse (and encapsulation, information hiding, …) Cons: Predictability, costly/complex run-time Object orientation Model-driven engineering (MDE) Object orientation MDE SCADE Common practice Our goal AADL (+ tools) Source-based approaches

OOPSLA DSM Workshop / 16 - MDE: a key question Model-Driven Engineering What determines the design semantics? Where is it fixed?  The generated software product must be statically analyzable  Its run-time behavior must be predictable and conform with the analysis  Static analysis of the software product should be anticipated by model-based analysis  What “reference universe” informs the metamodel?  The target programming language?  The target execution platform?  An underlying analysis theory?  The blue sky above?  Toward model-based analysis

OOPSLA DSM Workshop / 16 - Closing the gap between model and run-time (I)  Models as blueprints  To permit model-based analysis (timing, safety, security)  Bottom-up construction Model-Driven Engineering Ravenscar Profile Run-time kernel for High-integrity Real-Time Systems Warrants static analyzability Prescribes run-time semantics Identifies run-time metrics Ravenscar Computational Model To render language-neutral the semantics of the Ravenscar profile RCM Metamodel A high-level language to design systems compliant with Ravenscar restrictions by construction Ada Kernel, JVM Graphical/declarative language Higher-level abstraction same run-time semantics

OOPSLA DSM Workshop / 16 - Closing the gap between model and run-time (II) Model-Driven Engineering  Enable sound/complete model-based analysis  Models for V&V, not just for design/implementation Ravenscar Profile Ravenscar Computational Model RCM Metamodel PSM (not visible) Analysis Tool PIM Platform specification conformance Source Code traceability

OOPSLA DSM Workshop / 16 - Constrained Object-Oriented Modeling  Why object-orientation?  Adaptive reuse through inheritance and overriding  Reuse  decrease verification costs  Dispensed with by current industrial practice  Implementation issues  Dead inherited code  Larger-sized executables  More complex traceability  Requires dynamic binding  No static analysis  Far too costly path coverage Object orientation Advanced compilers address some of these problems (e.g., via ROM-able virtual tables) Main focus of the talk!

OOPSLA DSM Workshop / 16 - Dynamic binding: state-of-the-art? Object orientation void m(){ // a dynamically bound invocation this.ptr.p(); } void m(){ if(this.ptr instaceof Impl1){ // issue a statically bound invocation (not possible in Java) } // now evaluate all types... } Code transformation (compiler tool)  use code analysis tools Full code coverage: O (#dispatching_calls ∙ #types) ptr …

OOPSLA DSM Workshop / 16 - The RCM approach: models for V&V Object orientation … o2 : Impl3 o1 : MyClass  Core idea: links fixed at model level  Common in the high-integrity domain (HOOD, HRT-HOOD, AADL, etc.)  Use the dynamic binding mechanism but permit static analysis  Execution paths are statically determined  Model-based analysis instead of code-based analysis ptr

OOPSLA DSM Workshop / 16 - Object-oriented modeling with RCM RCM metamodel Enforce design-by-contract m1 invokes ptr.p2() m2 invokes ptr.p1() and ptr.p2() Class view Component view m1 m2 m3 p1 p2 Determine possible intra-component paths MyClass ptr

OOPSLA DSM Workshop / 16 - Object-oriented modeling with RCM (II) m1 invokes ptr.p2() m2 invokes ptr.p1() and ptr.p2() Class view ptr Object view RCM metamodel m : MyClass i : Impl1 Dynamic binding! Statically determine possible inter-components paths Enforce constant links functional dependencies on properties only call setters just once

OOPSLA DSM Workshop / 16 - Node N2 PIM to PSM in RCM RCM metamodel PIM Object view (with deployment) m : MyClassi : Impl1 Node N1 PSM Object view (not visible) client task (m) stub Middleware skeleton task server (i) Middleware Dynamic binding with statically-fixed execution path(s)

OOPSLA DSM Workshop / 16 - Implementation technologies  Eclipse plug-in  Metamodeling: EMF  Model transformations: ATL, MOFscript  GUI: GMF Implementation Class/Object diagram Deployment diagram

OOPSLA DSM Workshop / 16 - Results & Conclusions (I)  Industrial pilot projects by and  Due for completion and demonstration by December 2007  Targeting real space-qualified hardware  With real-life system ambitions and demands!  Model-based analysis  Needs a suitable underlying computational model  The same philosophy as adopted by SCADE  Fundamental to formally reason on system properties  Before implementation  Easier and more solid what-if analysis  Needs full and accurate modeling of the system  Difficult to map the middleware in the PIM-to-PSM transformation  Difficult to evaluate sizing requirements  Permits to exploit a restricted form of dynamic binding Results

OOPSLA DSM Workshop / 16 - Release client when timeout expires Timing event (released by the invocation of the RI) Results & Conclusions (II)  MDE-enabled object orientation: a première in space software!  Adaptive reuse: software frameworks are a major advantage  Predictability: constrained dynamic binding is acceptable  Certifiable implementation: requires compiler support  Work in progress  To increase PIM expressive power while preserving RCM compliance i : Impl1 Client Sporadic Task (waiting for server reply) Server Evaluate the release event (timeout / server reply) Discard undesired release events Timed-out RI (declarative spec.) Results

OOPSLA DSM Workshop 2007 Questions? Thank you! Matteo Bordin,

OOPSLA DSM Workshop 2007 : POS Overall Modeling Process RCM Modeling POS + Write + Read Protected Read Write POS_Component P : Pos IComputer Compute ??????? GNC + Compute + GNC_Op : IComputer Passive Compute GNC_Component G : GNC : GNC Passive Sporadic GNC_Op Compute ??????? : POS Write Read : IComputer Compute Functional specNon-functional spec