6 th Framework Programme (IST-FP6-2004 004033) A Domain-Specific Metamodel for Reusable Object-Oriented High-Integrity Components Matteo Bordin and Tullio

6th Framework Programme

(IST-FP6-2004 004033)

A Domain-Specific Metamodel for Reusable Object-Oriented High-Integrity Components

Matteo Bordin and Tullio VardanegaUniversity of Padua, Italy

The 7th OOPSLA Workshop on Domain-Specific Modeling

Montreal, October 21-22, 2007

- 2 / 16 -OOPSLA DSM Workshop 2007

Contents

1. The domain

2. Model-driven engineering

3. Constrained object-oriented modeling

4. Implementation technologies

5. Conclusions


High-Integrity SystemsThe domain

DO-178B

MIL-STD 882B

Def-Stan 0055

DO-178B

MISRA

IEC 880

IEC 61508

Up to 2/3 of development costs on V&V


High-integrity systems: a SW perspectiveThe 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

MD

E SCADE

Common practice

Our goal

AADL (+ tools)

Source-based approaches


MDE: a key questionModel-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


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

RavenscarProfile

• Run-time kernel for High-integrity Real-Time Systems• Warrants static analyzability• Prescribes run-time semantics • Identifies run-time metrics

RavenscarComputational

Model

• To render language-neutral the semantics of the Ravenscar profile

RCMMetamodel

• 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


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

RavenscarProfile

RavenscarComputational

Model

RCMMetamodel

PSM(not visible)

AnalysisTool

PIM

Platform specification

conformance

SourceCode

traceability


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!


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

…


The RCM approach: models for V&VObject orientation

…

o2 : Impl3o1 : 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

ptr


Object-oriented modeling with RCMRCM 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


Object-oriented modeling with RCM (II)

m1 invokes ptr.p2()

m2 invokes ptr.p1() and ptr.p2()

Class viewptr

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


Node N2

PIM to PSM in RCMRCM metamodel

PIM Object view (with deployment)

m : MyClass i : 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)


Implementation technologies

Eclipse plug-in Metamodeling: EMF Model transformations: ATL, MOFscript GUI: GMF

Implementation

Class/Object diagram

Deployment diagram


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


Release client whentimeout 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, [email protected]

www.math.unipd.it/~mbordin

OOPSLA DSM Workshop 2007

: POS

Overall Modeling Process RCM Modeling

POS+ Write+ Read

Protected

ProtectedRead

WritePOS_Component

P : Pos

IComputer

Compute

???????

???????

GNC+ Compute+ GNC_Op : IComputer

Passive

ComputeGNC_Component

G : GNC: GNC

Passive

SporadicGNC_Op

Compute???????

???????

??????? : POS

Write

Read

: IComputer

Compute

Functional spec Non-functional spec

Documents

6 th Framework Programme (IST-FP6-2004 004033) A Domain-Specific Metamodel for Reusable Object-Oriented High-Integrity Components Matteo Bordin and Tullio