La m

1
La méthodologie MORSE

• F. Kordon, LIP6-SRC (UMR 7606)
• Université P. M. Curie
• Fabrice.Kordon_at_lip6.fr

2
Is there a future for applicationsout of
distribution?

• Some examples
• Automatic freeway
• Satellite constellations
• Drone fleets
• Domotic applications
• Etc.
• Increasing complexity
• and need for reliability
• Main problem how to handle such applications
• Interactions between components (p2p approaches)
• Spécification, Analysis techniques, Relation to
  program, Deployment
• How to capture know-how (usability for engineers)
• Need for a vertical approach (no way to solve the
  problem locally only)

3
Separation of concerns

• Control aspects (the difficult part-)
• Computational aspects (related to an application
  domain)

Distributed Application
4
MORSE development Methodology centered on models
5
LfP Language overview

• LfP (language for prototyping)
• Architectural views c ensure traceability
• Deduced from UML identification of
  communications elements
• Behavioral views c describe behavioral contracts
• Partially deduced from sequence diagrams
  connection to state diagrams
• Property views c expected properties (guide for
  verification)
• Properties must be embedded into the
  specification
• Deployment view c for program synthesis
  (directives for code gen.)
• Link to the target architecture, detailed code
  generation directives
• Now strongly linked to a UML-profile (UML-M)

6
Focus 1 using formal methods

• Testing techniques fail
• Exhaustivity is not ensured
• Require formal methods
• premise and problems
• Need for push-button tools
• Approaches
• Theorem proving
• Parameterizable
• Difficult to automate
• Model checking
• Easy to automate
• Combinatorial explosion

Problem,mastering the complexity
7
An example, specific techniquesusing symbolic
approaches

• Client code
• -- Get a reference to the current client task
• Client  Get_My_Id
• -- Do the main loop
• loop
• -- computing data server call
• Message  Get_This_message
• Server  Get_This_server
• Server.gr(client, message)
• -- Waiting for results
• accept ga
• end loop 

• Server code
• loop
• -- Waiting for an incoming service
• accept gr (The_Client,
• The_Message) do
• Who  The_Client
• Data  The_Message
• end gr
• -- Processing (according to Data)
• if (Evaluate (Data lt 2)) then
• Processing_1 (Data)
• else
• Processing_2 (Data)
• end if
• -- Notifying the client
• Who.ga
• end loop

Hypothesis process comute only atyellow points
8
Specification (Petri nets)
Parameterization according to C, S et M
9
Where does complexity comes from?
Problem
This part generates distinct but permutable
values Too many concreted states (the system is
symmetric, clients are permutable)
10
State space Symbolic state space(C2, S1, M2)
24 nodes, 54 arcs
11
Performances
It is useless tohave S gt C -)
12
Why this technique is applicable?

• Yes, Well formed Petri Nets allow such an
  analysis
• Use of structural information on the
  specification
• Identification of static subclasses
• All elements share the same behavior
• Detection of total system symmetries
• Extensions for partial symmetries too
• Is this operational?
• Automatic detection of static subclasses is
  implemented in CPN-AMI
• Symbolic model checking as well (cooperation with
  the GreatSPN kernel)
• Coming in the next release
• Larger experimentations?

13
Other performances (PolyORB)(P4 2.4GHz 512Mo)

• Manual specification but same strategy
• 89 places, 72 transitions, 289 arcs
• Strongly symmetric specification

100 millions states
Almost a hard limit for numerous tools due to
RAM size (then model checkers do swap)
14
Focus 2 relation to programs

• Requires a generic prototype architecture
• Integrates a communication pattern with external
  copnents
• Requires a set of services (runtime)
• Similar to programing languages-)
• Provides support functions to operate LfP
  specifications
• LfP runtime and middleware?
• Similar objectives
• Require facilities for deployment
• Discussed later

Problem,liaison with the world
15
From the model to the program

• LfP contains a deployment view
• Yet experimental in its syntax (XML data
  associated to the specification)
• Generation approach

What needs forthe runtime?
Runtime
16
conclusion

• Distributed applications are a difficult task
• Handling complexity of interactions
• Handling deployment onto machines
• Handling configuration (on a node)
• Certification, real-time, etc.
• Integrated methodology can help!!!
• Modeling and formal methods
• Experimentation on LfP
• Why not UML? goes somewhat in the good
  direction
• Architecture languages
• Software or hardware (need both?)
• AADL, UML/ROOM, both?
• Middleware manufacturing
• Middleware à la carte

17
Advertising-)the MORSE project

• Méthodes et Outils pour la Réalisation et la
  vérification formellede Systèmes interopérables
  Embarqués critiques
• RNTL project (June 2003- June 2006)
• Sagem SA (project leader)
• Aonix
• LIP6-SRC
• LaBRI
• Objectives a methodology with its (prototype-)
  tools
• Prototyping approach
• Use of formal methods for verifying the system
• Use of a pivot language
• Integration of legacy code

18
Many perspectives

• Need for dynamic adaptation (at execution time)
• Some techniques are available
• Virtual Virtual machines (for the runtime)
• Need to control the development of transformation
  tools
• Model engineering techniques are available
• Metamodeling techniques?
• Transformation languages?
• Need for more formal techniques
• Management of time? Probabilistic analysis?
• Etc
• There is still some interesting work to come-)