Introduction

1. Modular Specification and Structural Validation of a Distributed ArchitecturePatrice Cros & Pierre MichelONERA-CERT-DTIM / CVSI

2. Introduction • Context : • needs of modularity for the conception of complex systems (critical, embedded) • at the early stages of the conception : modular specification • formal validation at the specification stage : •  structural validation • Plan : • A module calculus : Moka • A case study: Corba • A modeling approach • Conclusions

3. A Module Calculus : Moka • A formal framework : • an existing modulecalculus (Ehrig et Mahr) • enriched by a temporal logic to express behaviours • supported by a tool • to support modular system descriptions : • description of each component and of interconnections between components • structural validation : validation of interconnections • 4 main notions : • Module • Specification • Specification morphism • Interconnection operations

4. Export  Import Interface : visible part e Param Export i v Import Body s Interface with called modules Implementation part Module Calculus : Moduledefinition • A module is composed of 4 parts (or specifications) linked by 4 morphisms

5. Module Calculus : Specification • A Mokaspecification  extension of an ADT • equationallogic replaced by a temporal logic  to express behaviours. • Example : Specification User = Sorts : mess Variables : message : mess; ready Actions : req (mess) emit (mess) Formulae : Vars: m:mess Axioms: init : (~ready); def_req : all m Alw (req(m) <-> (~ready & AlwF (ready & (message=m)))); def_emit: all m Alw (emit(m) <-> (ready & (message=m) & AlwF (~ready))); endSpecification 1st version of Moka : a logic of actions (closed to TLA) 2nd version of Moka : TRIO (with quantified time) Vocabulary part Behavioral part

6. source target Module Calculus : Specification Morphism • A morphism sets a correspondence between 2specifications • Example : Sorts : int; bool Constants : T: bool eq : int,int -> bool morphism m Sorts : nat; formula Constants : V, F : formule compare : nat, nat -> formula addition : nat, nat -> nat int  nat bool formula T V eq compare

7. Module Calculus : Interconnection of modules • Composition operation : Param Export module1 Import Body Resulting module Param Export module2 Import Body Body • Others operations : • partial composition(a module can call several modules) • product(a module can be called by several modules) • union(union of 2 modules with a non empty intersection)

8. Module Calculus : Structural Validation • Structural Validation = Validation of all the morphisms • inside a module : morphisms (e, i, v, s) between parts • between modules : morphisms in interconnection operations. • Morphism validity : • Each vocabulary element (type, constant, variable, action) of the source specification • must have a correspondant in the target specification. • For behaviours : Source-Theory  Target-Theory • i.e. each formulae of the Source-Theory must be valid (i.e. a theorem ) in the Target-Theory (after renaming induced by vocabulary correspondances). • The Moka tool is not a theorem-prover nor a model-checker : • Generation of proof obligations for others tools

9. Client Server Skeletons Transaction level Stubs Object Adapter Communication level A case study: CORBA

10. Client Server Dynamic ORB Skeletons Invocation Interface Implementation Stubs Interface Object Adapter Repository Interface Repository (IDL) Object Adapter ORB Core CORBA

11. Modeling approach • Enrichment of the model following 2 directions : Execution Model L2 L0 L1 Client/Server model Transaction Distribution Connection Mode L1+ L2+ L0+ Implementation Repository Interface Repository ORB Core

12. L0 L1 L2 L0+ L1+ L2+ Modeling approach: Level L0 • A simple application: • 2 clients, 3 servers (IDL like interfaces)

13. Transaction Modeling approach: Level L1 • Transaction level L0 L1 L2 L0+ L1+ L2+

14. Transaction Distribution &Communication L0 L1 L2 L0+ L1+ L2+ Modeling approach: Level L2 • Distribution & Communication level

15. Conclusions on Corba modeling • Enrichment • on the first « line » (L0-L1-L2) : enrichment  addition of new modules without modifying the old ones. • on the second « line » (L0+-L1+-L2+): enrichment of some modules was necessary (but marginal) • Result : a library of specification modules for the Corba architecture. • about 100 different specification modules were defined. • Reuse of the model • for a more important and realistic application: an electronic marketplace for secondhand vehicule. • without changing any specification module in the library.

16. General Conclusions on Moka • Moka can support modular specifications for: large (more than 100 modules) and realistic applications. • limitation is more on proof tools(e.g. : TRIO model checker) • Strutural Validation vs Structured Validation : • Moka allows to check the validity of the structure of a specification  Strutural Validation • A structured specification allows a Structured Validation • validation of specification : by proofs (theorem prover or model checker) • local validation : validation of local properties inside each component • system validation : validation of global properties • test case generation for a modular implementation(local and global test) • studied in theFormaproject.