La méthodologie MORSE

1. La méthodologie MORSE F. Kordon, LIP6-SRC (UMR 7606) Université P. & M. Curie Fabrice.Kordon@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 Controlaspects External components Computationalaspects Development using domain approaches Prog. gen. Spec. of controls Formal verif. Model Based Develoment • Control aspects (the difficult part;-) • Computational aspects (related to an application domain) Distributed Application

4. MORSE: development Methodology centered on models UML (profile) LfP =pivot language «Formal debug» Reformulate/ enrich Formalspec. LfP Formal spec. generation Formal verif. (Petri nets, DDD) Program Generation Programs Tests & «tuning» Reffinements

5. LfP: Language overview • LfP (language for prototyping) • Architectural views censure traceability • Deduced from UML + identification of communications elements • Behavioral views cdescribe behavioral contracts • Partially deduced from sequence diagrams + connection to state diagrams • Property views cexpected properties (guide for verification) • Properties must be embedded into the specification • Deployment view cfor 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. 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 Focus 1: using formal methods UML (profile) Spec.formelle LfP programes Problem,mastering the complexity

7. 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; endloop 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); endif; -- Notifying the client Who.ga; endloop; An example, specific techniquesusing symbolic approaches Hypothesis: process comute only atyellow points

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

11. Performances State spacedoes notgrow anymore! It is useless tohave 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. 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 Focus 2: relation to programs UML (profile) Spec.formelle LfP programes Problem,liaison with «the world»

15. From the model to the program LfP element (thread?) Projection of the model into implementation components LfP Specification Application node Partitioned view Patterns & architectures N1 Programs N2 N3 Environment LfP Capsule (runtime) • 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;-)