La méthodologie MORSE F. Kordon, LIP6-SRC (UMR 7606)

Présentation au sujet: "La méthodologie MORSE F. Kordon, LIP6-SRC (UMR 7606)"— Transcription de la présentation:

1 La méthodologie MORSE F. Kordon, LIP6-SRC (UMR 7606)
Université P. & M. Curie

2 Is there a future for applications out 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) Control aspects External components Development using domain approaches Our methodology is based upon the distinction between the control aspect and the computational aspect of the application. The computational aspect handle the domain specific operations performed by the application. The control aspect handles the communication mechanisms between the components of the application. Its purpose is to keep every the application in a coherent state. This aspect is extremely important for distributed systems. Our methodology focuses on the control aspect of the application. The components that implement the domain specific operations can be developed using any existing engineering process. We consider them as “external components”. Their interactions with the control part must be well defined. Our work focuses on the development of the control aspect of the application. -> We start from a high level specification highlighting the distinction beetween the control aspect and the computational aspect of the application, and model very precisely their interactions. -> the control part is then translated into an lfp specification. Specific lfp instructions handle the interface with the external components. -> At this stage, it is possible to apply formal verification on the lfp model. This allows to check several functional properties such as the classical absence of deadlock. -> Once the lfp specification reaches its goals, it is translated into a programming language by a code generator. The generator uses the instructions inserted in the lfp specification to generated the code required for communication with external components, therefore re-inserting the external components into the generated application. Computational aspects Model Based Develoment Spec. of controls Formal verif. Prog. gen. Distributed Application

4 MORSE: development Methodology centered on models
UML (profile) Formal verif. (Petri nets, DDD) «Formal debug» LfP Reformulate/ enrich LfP = pivot language Formal spec. generation Comme UML est incontournable, et qu’il est une bonne base pour les premières étapes du développement, nous partons d’une spécification UML de haut niveau qui définit une première « conception » pour l’application. Nous appliquons ensuite un ensemble de règles de traduction pour obtenir une représentation LfP partielle du système. Cette spécification doit ensuite être complétée pour définir précisément le comportement des composants. Ce modèle va servir de base à la vérification formelle de la spécification d’une part, et à la génération de code d’autre part. Il est possible de définir des propriétés sur le modèle qui doivent être vérifiées sur le réseau généré. Lorsque le modèle est conforme à ce qui est attendu, il est possible de générer le code de contrôle de l’application, ce qui permet de d’obtenir rapidement un prototype exécutable. Comme le code a été généré à partir de la spécification qui a été vérifiée, il est conforme à la spécification, et respecte donc les propriétés vérifiées sur le modèle. Si le code généré ne donne pas satisfaction, il est toujours possible de modifier le modèle pour optimisation, de revérifier les propriétés, et de regénérer le code. L’intérêt de la génération de code est qu’elle permet de reproduire ce cycle très rapidement. Interet d’un pivot entre verif et code : La verif a partir de code difficile car niveau de détail trop élevé => nécessite de faire des abstractions pas toujours très adaptées La génération de code a partir de modèle servant a la verif donne du code peu efficace Grâce aux vues de LfP on permet un bon niveau d’abstraction (pour la verif) sans perte des détails nécessaires a la gen de code Tests & «tuning» Reffinements Programs Program Generation

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 Spec. formelle LfP programes UML (profile) Problem, mastering the complexity

7 An example, specific techniques using 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 < 2)) then Processing_1 (Data); else Processing_2 (Data); end if; -- Notifying the client Who.ga; end loop; Hypothesis: process comute only at yellow points

8 Specification (Petri nets)
Client c1 <C.all> c2 sm ga <c> <c,s,m> Server s1 <S.all> s2 gr1 [m < 2] gr2 [m >= 2] sa <c> <s> <c,s> <c,s,m> rq ack 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 (C=2, S=1, M=2)
Same configuration, only one path (client identity can be exchanged) 14 nodes, 27 arcs 24 nodes, 54 arcs A client sends M < 2 to server Two paths (C1 ≠ C2)

11 State space does not grow anymore!
Performances State space does not grow anymore! It is useless to have S > 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 Spec. formelle LfP programes UML (profile) 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 LfP Specification LfP element (thread?) Patterns & architectures Projection of the model into implementation components Partitioned view Application node Programs N1 N2 N3 Environment LfP Capsule (runtime) What needs for the 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 formelle de Systèmes interopérables Embarqués critiques RNTL project (June 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 There is still some interesting work to come;-)
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;-)