1 / 52

Jeff Magee

Software Architecture: the Darwin Approach. Jeff Magee. Department of Computing Imperial College of Science, Technology and Medicine 180 Queen’s Gate, London SW7 2BZ, UK. Architecture, Analysis, Animation & Application. Software Architecture Behavioural Analysis Graphic Animation

fergus
Télécharger la présentation

Jeff Magee

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. Software Architecture: the Darwin Approach Jeff Magee Department of Computing Imperial College of Science, Technology and Medicine 180 Queen’s Gate, London SW7 2BZ, UK. System Architecture: the Darwin Approach

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

  3. Construction View Behavioural View Implementation Analysis Architecture Description Structural View Darwin ADL System 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 atelevision product family. System Architecture: the Darwin Approach

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

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

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

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

  10. server:SERVER client:CLIENT service server.wallet client.wallet transfer sw:WALLET cw:WALLET System Composition Darwin: Structure described using instantiation and binding. System 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. System Architecture: the Darwin Approach

  12. Analysis • Interactive execution • Safety analysis • Progress analysis System Architecture: the Darwin Approach

  13. 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. System 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). System 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}} System Architecture: the Darwin Approach

  16. 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. System 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. System Architecture: the Darwin Approach

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

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

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

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

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

  23. Model-Animation Structure actions commands LTS model Animation mapping conditions controlledactions LTS + annotations Timed Automata model System 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. System Architecture: the Darwin Approach

  25. Composition - Timed Automata a, x:=0 xTp, e P b, y:=0 yTq, e Q b, y:=0 a, x:=0 xTp  yTq, e P||Q b, y:=0 a, x:=0 Animations can be composed in the same way. System 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 Composition animation M1 = C1, B1, Actions1, Controls1animationM2 = C2, B2, Actions2, Controls2 animation M1 || M1 = C1C2, B1B2, Actions1Actions2, Controls1Controls2 System Architecture: the Darwin Approach

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

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

  29. XML 1<?xml version="1.0"?> 2<!DOCTYPE animation SYSTEM "scenebeans.dtd"> 3<animation width="400" height="136"> 4<behavior id="channel" algorithm="move" 5 event="channel.end"> 6 <param name="from" value="71"/> 7 <param name="to" value="323"/> 8 <param name="duration" value="2"/> 9</behaviour> 10<command name="channel.begin"> 11 <announce event = "~channel.end"/> 12 <start behaviour= "channel"/> 13</command> 14<event object="channel" event="channel.end"> 15 <announce event="channel.end"/> 16</event> 17<draw> 18 <transform type="translate"> 19 <param name="y" value="64"/> 20 <animate param="x" behavior="channel"/> 21 <image src="image/message.gif"/> 22 </transform> 23 <image src="image/channel.gif"/> 24</draw> 25 </animation> System Architecture: the Darwin Approach

  30. Animation.. Facilitates communication between: users & domain experts requirements engineers architects System 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? System Architecture: the Darwin Approach

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

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

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

  37. Koala - example System Architecture: the Darwin Approach

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

  39. A simplified television System Architecture: the Darwin Approach

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

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

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

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

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

  45. WIRE Screen Control Tuner Control Connectors Connector protocol checked by property automata: 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). System Architecture: the Darwin Approach

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

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

  48. Software tools.. Automated software toolsare essential to support software engineers in the design process. Techniques which are not amenable to automation are unlikely to survive in practice. Experience inteachingthe approach to both undergraduates and postgraduates in courses on Concurrency. Initial experience with R&D teams inindustry(BT, Philips) System Architecture: the Darwin Approach

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

More Related