1. ©MageeSystem Architecture: the Darwin Approach 1 Jeff Magee Department of Computing Imperial College of Science, Technology and Medicine 180 Queen’s Gate, London SW7 2BZ, UK. Software Architecture: the Darwin Approach

2. ©MageeSystem Architecture: the Darwin Approach 2 Architecture, Analysis, Animation & Application  Software Architecture  Behavioural Analysis  Graphic Animation  Application - Koala

3. ©MageeSystem Architecture: the Darwin Approach 3 Architecture Description Structural View Behavioural View Analysis Construction View Implementation Darwin ADL

4. ©MageeSystem Architecture: the Darwin Approach 4 Emphasis in this talk… The use of tool supported incremental, interactive behaviour analysis during architecture development. The use of graphic animation to understand and communicate analysis artefacts. The application of this approach to a television product family.

5. ©MageeSystem Architecture: the Darwin Approach 5 Examples using… Architecture Description using Darwin Animation using SceneBeans Behaviour Modelling & Analysis using Labelled Transition System Analyser (LTSA)

6. ©MageeSystem Architecture: the Darwin Approach 6 A simple e -commerce system… CLIENT SERVER WALLET request transfer, null authorise reply, abort invoice confirm, default Client requests service from server which is paid for by a transfer from client’s wallet to server’s wallet.

7. ©MageeSystem Architecture: the Darwin Approach 7 Components & Services… CLIENT wallet service Service type defined by a set of actions: set Wallet = {authorise, invoice, confirm, default} set Service = {request, reply, abort} SERVER service wallet required provided unspec.

8. ©MageeSystem Architecture: the Darwin Approach 8 CLIENT behaviour Modelled by LTS: Specified in FSP: CLIENT = (wallet.authorise -> service.request -> (service.reply -> CLIENT |service.abort -> CLIENT ) )+{wallet.Wallet,service.Service}.

9. ©MageeSystem Architecture: the Darwin Approach 9 SERVER behaviour SERVER service.requestwallet.invoice wallet.confirm wallet.default service.reply service.abort 01234 LTS: FSP: SERVER = (service.request -> wallet.invoice -> (wallet.confirm -> service.reply ->SERVER |wallet.default -> service.abort ->SERVER ) )+{wallet.Wallet,service.Service}.

10. ©MageeSystem Architecture: the Darwin Approach 10 System Composition client: CLIENT server: SERVER cw: WALLET sw: WALLET service transfer client.wallet server.wallet Darwin: Structure described using instantiation and binding.

11. ©MageeSystem Architecture: the Darwin Approach 11 Behaviour model composition ||SES =( client:CLIENT ||server:SERVER ||cw:WALLET(2) ||sw:WALLET(0) )/{ service/{client,server}.service, client.wallet/cw.wallet, server.wallet/sw.wallet, transfer/{cw,sw}.transfer, null/{cw,sw}.null }. Darwin component instantiation maps directly to parallel composition and binding to relabelling. Parallel composition || generates an LTS that represents all possible interleaving of the actions. Processes synchronise on shared actions.

12. ©MageeSystem Architecture: the Darwin Approach 12 Analysis  Interactive execution  Safety analysis  Progress analysis

13. ©MageeSystem Architecture: the Darwin Approach 13 Reachability analysis for checking models Deadlock - state with no outgoing transitions. ERROR (  ) state -1 is a trap state. Undefined transitions are automatically mapped to the ERROR state. ERROR state Deadlock state Exhaustive state space search for:

14. ©MageeSystem Architecture: the Darwin Approach 14 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. /* If a payment transfer occurs the service should be delivered otherwise if no payment, no service */ property HONEST = (transfer -> service.reply -> HONEST |null -> service.abort -> HONEST ). ||CHECK = (SES || HONEST).

15. ©MageeSystem Architecture: the Darwin Approach 15 Liveness - progress properties LTSA supports 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. /* It should always be the case that the service either eventually replies or aborts */ progress LIVE_SERVICE = {service.{reply,abort}}

16. ©MageeSystem Architecture: the Darwin Approach 16 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. Scalability The problem with reachability analysis is that the state space “explodes” exponentially with increasing problem size. How do we alleviate this problem?

17. ©MageeSystem Architecture: the Darwin Approach 17 Graphic Animation The products of analysis are essentially action traces describing desirable or undesirable behaviours that the model has. The purpose of graphic animation is to provide visualizations of these behaviours. These visualizations can be in the context of the architecture or in the context of the problem domain.

18. ©MageeSystem Architecture: the Darwin Approach 18 Flexible Production Cell – example

19. ©MageeSystem Architecture: the Darwin Approach 19 A simpler example- CHAN LTS CHAN = (in -> out -> CHAN |in -> fail -> CHAN ). FSP

20. ©MageeSystem Architecture: the Darwin Approach 20 Timed Automata Abstract animation activities by local clocks that measure the passage of time. Time passes in a state. local clock variable x

21. ©MageeSystem Architecture: the Darwin Approach 21 Animation Activities commands: channel.begin-- corresponds to x := 0 explode conditions: channel.end-- corresponds to x  Tc channel.fail-- corresponds to x  Tf channel Start of an activity Signal as the activity progresses or ends

22. ©MageeSystem Architecture: the Darwin Approach 22 Annotating LTS with animation animation FAILCHAN = "channel.xml" actions { in / channel.begin, fail / explode } controls { out / channel.end, fail / channel.fail } Mapping Relation label/command (immediate actions) label/condition (controlled actions)

23. ©MageeSystem Architecture: the Darwin Approach 23 Model-Animation Structure LTS model Animation mapping actions conditions commands controlled actions Timed Automata model LTS + annotations

24. ©MageeSystem Architecture: the Darwin Approach 24 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 progress NOZENO = { Controlled } asserts animation is free of Zeno executions.

25. ©MageeSystem Architecture: the Darwin Approach 25 Composition - Timed Automata a, x:=0 x  Tp, e b, y:=0 y  Tq, e P Q P||Q a, x:=0 b, y:=0 a, x:=0 x  Tp  y  Tq, e Animations can be composed in the same way.

26. ©MageeSystem Architecture: the Darwin Approach 26 Animation Composition An animation is defined by; the set of commands C, the set of conditions B the relation Actions -- maps LTS actions to commands the relation Controls -- maps LTS actions to conditions animation M 1 =  C 1, B 1, Actions 1, Controls 1  animation M 2 =  C 2, B 2, Actions 2, Controls 2  animation M 1 || M 1 =  C 1  C 2, B 1  B 2, Actions 1  Actions 2, Controls 1  Controls 2  Animation Composition

27. ©MageeSystem Architecture: the Darwin Approach 27 SceneBeans Scene Graph Behaviours Animation Thread

28. ©MageeSystem Architecture: the Darwin Approach 28 Example Scene Graph behavior “channel” algorithm move transform translate image message draw image channel command channel.begin event channel.end

29. ©MageeSystem Architecture: the Darwin Approach 29 XML 1 2 3 4 <behavior id="channel" algorithm="move" 5 event="channel.end"> 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

30. ©MageeSystem Architecture: the Darwin Approach 30 Animation.. users & domain experts requirements engineers Facilitates communication between: architects

31. ©MageeSystem Architecture: the Darwin Approach 31 Application - Televisions Why is the Darwin ADL, which originated in distributed systems research, applicable to the construction of software for televisions?

32. Product Families Price Features MTV DVD VCR Storage Device HD TVCR TiVo LCTV Video Output Device PTV FTV Broadcasting Standard DTV Region Data Processing Chip Technology Connectivity UTV

33. ©MageeSystem Architecture: the Darwin Approach 33 Role of an ADL…  Uneconomic to design the software for each product from scratch.  Develop a set of software components.  Build the software for each product variant from an architectural description of that product.

34. ©MageeSystem Architecture: the Darwin Approach 34 Darwin applicability…  Darwin enforces a strict separation between architecture and components.  Variation supported by both different Darwin descriptions and parameterisation.  Variants can be constructed at compile-time or later at system start-time.

35. ©MageeSystem Architecture: the Darwin Approach 35 Koala In the ARES project Rob van Ommering saw potential of Darwin in specifying television product architectures and developed Koala, based on Darwin, for Philips. First large-scale industrial application of an ADL.

36. ©MageeSystem Architecture: the Darwin Approach 36 An industrial application of Darwin… Interfaces are sets of C functions Koala (Philips)

37. ©MageeSystem Architecture: the Darwin Approach 37 Koala - example

38. ©MageeSystem Architecture: the Darwin Approach 38 Television Software Architecture Behavioural Analysis Case Study: Control of Signal Path using Horizontal Communication e.g. blanking screen during tuner frequency change

39. ©MageeSystem Architecture: the Darwin Approach 39 A simplified television

40. ©MageeSystem Architecture: the Darwin Approach 40 Traditional Central Control Tuner Screen Control Driver S/W H/W Driver new signal path

41. ©MageeSystem Architecture: the Darwin Approach 41 Distributed Control Tuner Screen Driver S/W H/W signal path Tuner Control Screen Control Driver Control control path

42. ©MageeSystem Architecture: the Darwin Approach 42 HorCom Tuner Control Tuner Driver Screen Control Screen Driver Horizontal Communication Protocol

43. ©MageeSystem Architecture: the Darwin Approach 43 Scenario

44. ©MageeSystem Architecture: the Darwin Approach 44 Behaviour Modelling Model each component as FSP process(es). Tuner Driver TUNERDRIVER = (change[False] -> TUNING |change[True] -> TUNERDRIVER ), TUNING = (chgAck -> TUNERDRIVER |change[False] -> TUNING ). change[0] change[1] change[0] chgAck 01

45. ©MageeSystem Architecture: the Darwin Approach 45 Connectors Connector protocol checked by property automata: Tuner Control Screen Control WIRE property WIRE = GREEN, GREEN = (drop -> (drop[False] -> ORANGE | drop[True] -> RED) ), ORANGE = (dropAck -> (dropAck.ret -> RED |restore -> restore.ret -> dropAck.ret -> GREEN ) ), RED = (restore -> restore.ret -> GREEN).

46. ©MageeSystem Architecture: the Darwin Approach 46 Animation & Analysis Animation to validate model reflects requirements. Model-check to verify properties. Demo…

47. ©MageeSystem Architecture: the Darwin Approach 47 In summary... requirements goals use cases assumptions constraints properties architectures models analysis graphical animation Illustrated a tool supported approach that facilitates early identification of and experimentation with architecture.

48. ©MageeSystem Architecture: the Darwin Approach 48 Software tools.. 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)

49. ©MageeSystem Architecture: the Darwin Approach 49 Software Tools – Lightweight vs. Heavyweight Short learning curve. Immediate benefits. Support incremental construction, and facilitate interactive experimentation. 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. vs.

50. ©MageeSystem Architecture: the Darwin Approach 50 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.

51. ©MageeSystem Architecture: the Darwin Approach 51 Related Work - animation  Verification / Modelling Tools StateMate – Widget Set SCR – instrument panel animation SPIN, Concurrency Factory, UPPAAL – animation w.r.t. model source Z +graphic animation - SVRC, Australia  Program Animation Tango/XTango – smooth animation of sequential programs Pavane – data parallel program animation via state/visual mapping

52. ©MageeSystem Architecture: the Darwin Approach 52 Future directions…  Model construction using animation composition  Model synthesis from scenarios  Hybrid models  Linear Temporal Logic Model Checking  Performance Analysis Emphasis on lightweight, accessible and interactive tools. Tools available from: http://www-dse.doc.ic.ac.uk/concurrency/