1 / 37

Jeff Kramer

Modelling for mere Mortals: mixing architecture with analysis & animation. Jeff Kramer. Distributed Software Engineering Department of Computing Imperial College London. the formal methods GODS.

lavadag
Download Presentation

Jeff Kramer

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Modelling for mere Mortals: mixing architecture with analysis & animation Jeff Kramer Distributed Software Engineering Department of Computing Imperial College London UCI 2000

  2. the formal methods GODS • In the past, attempts to convince practising software engineers to adopt formal methods of software development were generally unsuccessful. • The methods were • too difficult to learn and use, • provided inadequate tool support, • did not integrate well into the software development process. • They could only be used effectively by the “gods”who created them! UCI 2000

  3. The challenge is to make modelling and analysis accessible to mere software engineering mortals. software engineering MORTALS Recent advances in and experience with specification techniques and automated model checking have demonstrated the utility of these techniques. * * • Clarke, E.M., Wing, J.M., et al. Formal Methods: State of the Art and Future Directions. • Cleaveland, R., Smolka, S.A., et al. Strategic Directions in Concurrency Research. ACM 50th Anniversary Computing Surveys, Vol. 28 No. 4 (1996) UCI 2000

  4. How? our approach is …. Model Based Design integrate modelling into the software lifecycle: Software Architectures of components Easy to learn and use: State Machines in form of LTS (Labelled Transition Systems) Lightweight Tool support: Model Checking in form of CRA (Compositional Reachability Analysis) with animation UCI 2000

  5. Chapter 1. Context and experience Software Architectures UCI 2000

  6. structural view - Darwin ADL Components have one or more interfaces. An interface is simply a set of names referring to actions in a specification or services in an implementation, provided or required by the component. Component interfaces Composite Component Systems / composite components are composed hierarchically by component instantiation and interface binding. UCI 2000

  7. construction view - Koala ADL (based on Darwin, in use by Philips) Resource constrained product families Interfaces are sets of C functions Structural diversity = internal diversity at next higher level UCI 2000

  8. Koala experience • “It turns out to be very simple to make different configurations. We haven't made different products yet, but we are already profiting from the composability in that it is very easy to create small environments in which to test parts of the software.” • The individual processes are really quite simple state machines. What we really need is a way to compose these state machines, and perform some sort of analysis on the composition...” Rob van Ommering Philips Research Eindhoven UCI 2000

  9. Behavioural View Construction View Implementation Modelling and Analysis Architectural description - multiple views Structural View UCI 2000

  10. Chapter 2. Modelling Primitive components UCI 2000

  11. USER = ( lock-> critical -> release-> USER) @{lock,release}. -> action prefix recursion @ interface Actions {lock,release} are exposed, criticalis hidden. component USER - behaviour Component: component USER { requires lock; release; } USER lock release Process specification in FSP: UCI 2000

  12. component USER - behaviour Labelled transition system LTS: LTS Animation can be used to step through the actions to test specific scenarios. USER can be minimised with respect to Milner’s observational equivalence. UCI 2000

  13. const Max = 3 range Int = 0..Max SEMAPHORE(N=0) = SEMA[N], SEMA[v:Int] = ( when(v<Max) up -> SEMA[v+1] | when(v>0) down -> SEMA[v-1] ). | choice when guarded choice process parameter and labelling component SEMAPHORE - behaviour Component: SEMAPHORE component SEMAPHORE (N=0) { provides up;down; } up down Process specification in FSP: UCI 2000

  14. Primitive Components - summary • Component behaviour is modelled using Labelled Transition Systems (LTS). • Primitive components are described as finite state processes (FSP) using: • action prefix -> • (guarded) choice | • recursion • interface @ • interface represents an action (or set of actions) in which the component can engage. UCI 2000

  15. Chapter 3. Modelling Composite components UCI 2000

  16. Composite component behaviour Three processes p[1..3] use a shared semaphore mutex to ensure mutually exclusive access to some resource. SEMADEMO For mutual exclusion, the initial semaphore value must be 1. p[1] : USER p[2] : USER p[3] : USER mutex : SEMAPHORE(1) UCI 2000

  17. ||SEMADEMO = (p[1..3]:USER || mutex:SEMAPHORE(1) ) /{p[1..3].lock/mutex.down, p[1..3].release/mutex.up}. : instantiation || composition / relabelling Composite component behaviour component SEMADEMO {inst p[1..3] : USER; mutex : SEMAPHORE(1); bind p[1..3].lock -- mutex.down; bind p[1..3].release -- mutex.up; } UCI 2000

  18. Composite Component - summary • Component composition is modelled as parallel composition ||. (Interleaving of all the actions) • Binding is modelled by relabelling /. (Processes synchronise on shared actions) • Composition expressions are direct translations from architecture descriptions. UCI 2000

  19. Chapter 4. Behaviour analysis UCI 2000

  20. -1 0 1 2 3 Reachability analysis for checking models Searches the system state space for deadlock states and ERROR states arising from property violations. ERROR state Deadlock state Deadlock - state with no outgoing transitions. ERROR () state -1 is a trap state. Undefined transitions are automatically mapped to the ERROR state. …and if the initial value of the semaphore is 0 ? UCI 2000

  21. Safety - property automata Safety properties are specified by deterministic finite state processes called property automata. These generate an image automata which is transparent for valid behaviour, but transitions to an ERROR state otherwise. property EXCLUSION = (p[i:1..3].lock -> p[i].release -> EXCLUSION ). ||CHECK = (SEMADEMO || EXCLUSION). Safety properties are composed with the (sub)systems to which they apply, then check if ERRORis reachable in the composed system. …and if the initial value of the semaphore is 2 ? UCI 2000

  22. Liveness - progress properties To avoid the need for mortal engineers to know LTL, we support a limited class of liveness properties, called progress, which can be checked efficiently :[]a []a []b i.e. Progress properties check that, in an infinite execution, particular actions occur infinitely often. For example: progress AQUIRE[i:1..3] = {p[i].lock} …and if the initial value of the semaphore is 0 ? UCI 2000

  23. LTS a a b b x Chapter 5. Other examples .… with animation FMC NATS Chan Puzzle e-commerce …. UCI 2000

  24. Flexible Manufacturing Cell UCI 2000

  25. Model-Animation Structure actions commands LTS model Animation mapping conditions controls LTS + annotations Timed Automata model UCI 2000

  26. A simpler example - CHAN CHAN = (in -> out -> CHAN |in -> fail -> CHAN ). UCI 2000

  27. Models & Annotated models Safety Properties The annotated model cannot exhibit behavior that is not contained in the base model: Any safety property that holds for the base model also holds for the animated model. Progress properties Useful approximation of the annotation is: P>>Controlled -- make actions in Controlled low priority Check progressNOZENO = { Controlled } asserts animation is free of Zeno executions. UCI 2000

  28. NATS – short term conflict alert For each pair of aircraft determine potential conflict. We can construct hybrid models that combine the discrete behavioural model with a real valued data stream. UCI 2000

  29. A simple e-commerce system… Client requests service from server which is paid for by a transfer from client’s wallet to server’s wallet. CLIENT SERVER request reply confirm, default invoice authorise transfer,null WALLET WALLET UCI 2000

  30. Scalability The problem with reachability analysis is that the state space “explodes” exponentially with increasing problem size. How do we hope to alleviate this problem? Compositional Reachability Analysis: We construct the system incrementally from subcomponents, based on the software architecture. State reduction is achieved by hiding actions not in their interfaces and minimising. Property checks remain in the minimised subcomponents. UCI 2000

  31. Chapter 6. In conclusion... Model Based Design UCI 2000

  32. Software tools for mere mortals Automated software tools are essential to support software engineers in the design process. Techniques which are not amenable to automation are unlikely to survive in practice. Experience in teaching the approach to both undergraduates and postgraduates in courses on Concurrency. Initial experience with R&D teams in industry (BT, Philips, NATS) UCI 2000

  33. Software Tools - Lightweight vs. Heavyweight Short learning curve. Immediate benefits. Supports incremental model construction. Facilitates interactive experimentation. vs. Traditional verification and analysis tools tend to require considerable expertise and have as their goal the ability to target large problems rather than ease of use. UCI 2000

  34. Animation mapping Separate graphic animation model which preserves the behaviour of the model and has sound semantics based on Timed Automata. Model analysis & animation LTS model LTS Model checking • safety properties • progress properties • compositional reachability • abstraction & minimisation UCI 2000

  35. Related Work – architecture/analysis • ADL Wright + FDR toolset • LOTOS + Caesar/Aldebaran • Promela + SPIN • Our approach is distinguished by: • direct use of ADL to generate both analysis model & implementation, • emphasis on compositionality, • animation for model interpretation, domain constraints and error trace explanation. UCI 2000

  36. Related Work - animation • Verification / Modelling Tools • SCR – instrument panel animation • SPIN, Concurrency Factory, UPPAAL – animation w.r.t. model source • StateMate – Widget Set • Z +graphic animation - SVRC, Australia • Program Animation • Tango/XTango – smooth animation of sequential programs • Pavane – data parallel program animation via state/visual mapping UCI 2000

  37. Future work • Model construction using animation composition • Model synthesis from scenarios • Hybrid models Emphasis on lightweight, accessible and interactive toolstailored for mere mortals! LTSA available from: http://www-dse.doc.ic.ac.uk/concurrency/ UCI 2000

More Related