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

1
A Domain-Specific Metamodel for Reusable
Object-Oriented High-Integrity Components
The 7th OOPSLA Workshop on Domain-Specific
Modeling Montreal, October 21-22, 2007

• Matteo Bordin and Tullio Vardanega
• University of Padua, Italy

2
Contents

1. The domain
2. Model-driven engineering
3. Constrained object-oriented modeling
4. Implementation technologies
5. Conclusions

3
High-Integrity Systems
The domain
IEC 880
MIL-STD 882B
Up to 2/3 of development costs on VV
DO-178B
Def-Stan 0055
IEC 61508
MISRA
DO-178B
4
High-integrity systems a SW perspective
The domain
Model-driven engineering (MDE)

• Pros Abstraction, Automation (correctness by
  construction)
• Cons Model-to-executable distance (difficult
  analysis)

Object orientation
Pros Adaptive reuse (and encapsulation,
information hiding, ) Cons Predictability,
costly/complex run-time
5
MDE a key question
Model-Driven Engineering

• Toward model-based analysis

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?

6
Closing the gap between model and run-time (I)
Model-Driven Engineering

• Models as blueprints
• To permit model-based analysis (timing, safety,
  security)
• Bottom-up construction

RCM Metamodel
Graphical/declarative language

• A high-level language to design systems
  compliant with Ravenscar restrictions by
  construction

Ravenscar Computational Model
Higher-level abstraction same run-time semantics

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

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

Ravenscar Profile
Ada Kernel, JVM
7
Closing the gap between model and run-time (II)
Model-Driven Engineering

• Enable sound/complete model-based analysis
• Models for VV, not just for design/implementation

8
Constrained Object-Oriented Modeling
Object orientation

• 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

Advanced compilers address some of these
problems (e.g., via ROM-able virtual tables)
Main focus of the talk!
9
Dynamic binding state-of-the-art?
Object orientation
ptr

void m() // a dynamically bound invocation
this.ptr.p()
Code transformation (compiler tool) ? use code
analysis tools
void m() if(this.ptr instaceof Impl1)
// issue a statically bound invocation (not
possible in Java) // now evaluate all
types...
Full code coverage O(dispatching_calls
types)
10
The RCM approach models for VV
Object orientation

• 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

o2 Impl3
ptr
o1 MyClass
11
Object-oriented modeling with RCM
RCM metamodel
Class view
ptr
m1 invokes ptr.p2() m2 invokes ptr.p1() and
ptr.p2()
Enforce design-by-contract
Component view
MyClass
m1
p1
m2
p2
m3
Determine possible intra-component paths
12
Object-oriented modeling with RCM (II)
RCM metamodel
Class view
ptr
m1 invokes ptr.p2() m2 invokes ptr.p1() and
ptr.p2()

• Enforce constant links
• functional dependencies on properties only
• call setters just once

Object view
Dynamic binding!
i Impl1
m MyClass
Statically determine possible inter-components
paths
13
PIM to PSM in RCM
RCM metamodel
PIM Object view (with deployment)
Node N2
Node N1
m MyClass
i Impl1
PSM Object view (not visible)
Dynamic binding with statically-fixed execution
path(s)
client task (m)
stub
skeleton task
server (i)
Middleware
Middleware
14
Implementation technologies
Implementation

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

Class/Object diagram
Deployment diagram
15
Results Conclusions (I)
Results

• 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

16
Results Conclusions (II)
Results

• 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

Timed-out RI (declarative spec.)
i Impl1
Evaluate the release event (timeout / server
reply) Discard undesired release events
Release client when timeout expires
Timing event (released by the invocation of the
RI)
Server
Client Sporadic Task (waiting for server reply)
17
Questions?
Thank you!
Matteo Bordin, mbordin_at_math.unipd.it www.math.unip
d.it/mbordin
18
Overall Modeling Process
RCM Modeling
Functional spec
Non-functional spec
POS_Component
POS
IComputer
Write
Protected
???????
Compute
P Pos
Protected
???????
Read
IComputer
POS Write Read
Compute
GNC Compute GNC_Op
GNC_Component
IComputer
Compute
POS
Passive
???????
Write
G GNC
Read
GNC
Compute
Passive
???????
Sporadic
???????
GNC_Op