Software Architecture the Darwin Approach Jeff Magee Department

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

Architecture, Analysis, Animation & Application u Software Architecture u Behavioural Analysis u Graphic Animation u. Application - Koala ©Magee System Architecture: the Darwin Approach 2

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

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

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

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 request SERVER reply, abort invoice authorise confirm, default transfer, null WALLET ©Magee System Architecture: the Darwin Approach 6

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

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

SERVER behaviour LTS: wallet. default service. request wallet. invoice SERVER 0 1 wallet. confirm 2 3 4 service. reply service. abort FSP: SERVER = (service. request -> wallet. invoice -> (wallet. confirm -> service. reply ->SERVER |wallet. default -> service. abort ->SERVER ) )+{wallet. Wallet, service. Service}. ©Magee System Architecture: the Darwin Approach 9

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

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

Analysis u. Interactive execution u. Safety analysis u. Progress analysis ©Magee System Architecture: the Darwin Approach 12

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

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). ©Magee System Architecture: the Darwin Approach 14

Liveness - progress properties LTSA supports a limited class of liveness properties, called progress, which can be checked efficiently : [] 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}} ©Magee System Architecture: the Darwin Approach 15

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

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. ©Magee System Architecture: the Darwin Approach 17

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

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

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

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

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

Model-Animation Structure ac LTS model com ma nds s ion t s ion it con act trolle d ion s LTS Animation mapping ond c + annotations Timed Automata model ©Magee System Architecture: the Darwin Approach 23

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. ©Magee System Architecture: the Darwin Approach 24

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

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 Composition 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 ©Magee System Architecture: the Darwin Approach 26

Scene. Beans Scene Graph ©Magee Behaviours System Architecture: the Darwin Approach Animation Thread 27

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

2 3" src="https://present5.com/presentation/ebf432a08920988f2fc79897b4440d65/image-29.jpg" alt="XML 1 2 3" /> XML 1 2 3 4 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 ©Magee System Architecture: the Darwin Approach 29

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

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

Product Families Features Broadcasting Standard Video Output Device FTV DTV PTV LCTV Region UTV Ti. Vo HD TVCR Chip Technology DVD MTV Data Processing VCR Connectivity ©Magee Price System Architecture: the Darwin Approach Storage Device 32

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

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

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. ©Magee System Architecture: the Darwin Approach 35

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

Koala - example ©Magee System Architecture: the Darwin Approach 37

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

A simplified television ©Magee System Architecture: the Darwin Approach 39

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

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

Hor. Com Horizontal Communication Protocol Tuner Control Tuner Driver ©Magee Screen Control Screen Driver System Architecture: the Darwin Approach 42

Scenario Tuner Driver Tuner Control 1. Tune(f) Screen Control 2. Drop Screen Driver 3. Blank false 5. Drop. Ack 4. Blank. Ack 6. Change(f) 7. Chg. Ack 8. Restore ©Magee System Architecture: the Darwin Approach 9. Unblank 43

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

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

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

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

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) ©Magee System Architecture: the Darwin Approach 48

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

Related Work – architecture/analysis u ADL Wright + FDR toolset u LOTOS + Caesar/Aldebaran u Promela + SPIN Our approach is distinguished by: ¨ direct use of ADL to generate both analysis model & implementation, ¨ emphasis on compositionality. ©Magee System Architecture: the Darwin Approach 50

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

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