©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

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

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

©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.

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

©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.

©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.

©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}.

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

©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.

©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.

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

©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:

©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).

©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}}

©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?

©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.

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

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

©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

©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

©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)

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

©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.

©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.

©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

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

©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

©MageeSystem Architecture: the Darwin Approach 29 XML <behavior id="channel" algorithm="move" 5 event="channel.end">

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

©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?

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

©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.

©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.

©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.

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

©MageeSystem Architecture: the Darwin Approach 37 Koala - example

©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

©MageeSystem Architecture: the Darwin Approach 39 A simplified television

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

©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

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

©MageeSystem Architecture: the Darwin Approach 43 Scenario

©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

©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).

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

©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.

©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)

©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.

©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.

©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

©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: