Modelling the CoCoME with the Java/A Component Model

Transcription

1 Modelling the CoCoME with the Java/A Component Model Rolf Hennicker, Alexander Knapp Ludwig-Maximilians-Universität München August 2007

2 The Java/A Team Ludwig-Maximilians-Universität München UML modelling, qualitative analysis Florian Hacklinger Rolf Hennicker Stephan Janisch Alexander Knapp Martin Wirsing University of Edinburgh quantitative analysis Allan Clark Stephen Gilmore Danmarks Tekniske Universitet, Lyngby UML modelling, qualitative analysis Hubert Baumeister R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 2/43

3 Overview Java/A component model Modelling the CoCoME Analysis of our model for the CoCoME Tools Open issues R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 3/43

4 The Java/A Component Model (1) Interface provided 0..1 required 0..1 Port operations * properties * behavior 1 * operations Operation Property Behavior Feature Operation operations * Simple Component properties * Property Behavior behavior 1 * ports {subsets properties} Port Property type 1 Port R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 4/43

5 Simple Components: Example R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 5/43

6 The Java/A Component Model (2) Component type 1 Simple Component Composite components Component * Component Property relayports * Port Property 2 ports Property connectors * Connector Property 1 type Connector ports 2 Port R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 6/43

7 Composite Components: Example R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 7/43

8 Modelling the CoCoME Procedure (1) 1. Primary scenarios from CoCoME description static structure of simple components port and component behaviour analysis of behaviour (embedded system part) integration of simple components into composite components 2. Alternative and exceptional scenarios from CoCoME description 3. Iteration R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 8/43

9 Modelling the CoCoME Procedure (2) Deriving state machines from interactions sd Process sale : CashBox salestarted : CashDeskApplication : Coordinator salefinished alt paymentmode(cash) cashamountentered changeamountcalculated cashboxclosed ref payment mode card saleregistered opt expressmodeenabled R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 9/43

10 Modelling the CoCoME Procedure (3) R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 10/43

11 Modelling the CoCoME Overview CashDeskLine Store::CashDeskLine CashDesk CashDesk CardReaderController CardReader CashBoxController CashBox CashDeskApplication CashDeskApplication CashDeskGUI CashDeskGUI LightDisplayController LightDisplay PrinterController Printer ScannerController Scanner Coordinator Coordinator EventBus Not modelled Inventory Not explicitly; distinguished Enterprise/Store Application Ditto due to distinct Enterprise/Store Reporting Enterprise::Reporting Store Store::Inventory Data Data Enterprise Data instantiated in Enterprise Store Data instantiated in Store Persistence integrated in ports of Data GUI modelled as operator ports Reporting ports of Enterprise::Reporting Store ports of Store::Inventory DataBase DataBase R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 11/43

12 TradingSystem Static Structure R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 12/43

13 Store Static Structure R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 13/43

14 CashDeskLine Static Structure R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 14/43

15 Coordinator Static Structure R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 15/43

16 Coordinator Port Behaviour R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 16/43

17 Coordinator Component Behaviour R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 17/43

18 CashDesk Static Structure R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 18/43

19 Functional Analysis Interested in: Behaviour of ports and components (simple and composite) Basis: Given behaviour specifications of ports and simple components Properties to be checked: Deadlock-freeness of port and component behaviours Correctness of components w.r.t. their ports Focus of our analysis: Embedded system part Analysis process: Starts with the analysis of simple components and their ports Derives results for composite components R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 19/43

20 Composite Component CashDeskLine (revisited) R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 20/43

21 Behaviour Specifications and their Formalisation State machines I/O-transition systems with input, output, internal labels + τ-action R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 21/43

22 I/O-transition System for Component Coordinator Notation: beh(coordinator) R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 22/43

23 Behaviour of Port Coordinator CashDesk R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 23/43

24 Analysis of Simple Components Steps: Check the deadlock-freeness of ports and simple components Check the compliance of component and port behaviours Definition (Component correctness) Observable behaviour of a component C at port p : P obs p (beh(c)) beh(p) Example: obs cd (beh(coordinator)) beh(c-cd) R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 24/43

25 Analysis of Composite Components Assume given: Correct and deadlock-free subcomponents Analysis steps: Examine (pairwise) the interaction behaviour of connected ports Check the deadlock-freeness of the composite component Check the correctness of the composite component w.r.t. its ports R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 25/43

26 Interaction Behaviour of Connected Ports Example: Interaction behaviour of the Coordinator and CashDesk ports beh(cda-c) beh(c-cd) R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 26/43

27 Port product beh(cda-c) beh(c-cd) Definition (Behavioural compatibility of ports) beh(p) beh(q) is deadlock-free. R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 27/43

28 Important Observation «component» CC a : A b : B c : C Behavioural compatibility of the connected ports + deadlock-freeness of all subcomponents deadlock-freeness of the composite component R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 28/43

29 Reflection of Port Behaviour Definition (Reflection of port behaviour) The interaction behaviour of P and Q reflects the behaviour of P, if beh(p) beh(p) beh(q) Example: The interaction behaviour of the CashDesk and the Coordinator ports reflects the behaviour of the CashDesk port beh(cda-c) beh(cda-c) beh(c-cd) R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 29/43

30 Deadlock-freeness of Composite Components Assume: Deadlock-freeness and correctness of all subcomponents Behavioural compatibility of all connected ports Behaviour reflection for n 1 connected ports Then the composite component CC is deadlock-free. R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 30/43

31 Deadlock-freeness of the CashDesk Component All subcomponents are deadlock-free and correct All connected ports are behaviourally compatible Only the connection between the CashDeskApplication and the CashBox is not behaviour reflecting Hence the CashDesk component is deadlock free. R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 31/43

32 Deadlock-freeness of the CashDeskLine The subcomponents Coordinator and CashDesk are deadlock-free and correct The connected ports are behaviourally compatible (and even behaviour reflecting) Hence the CashDeskLine component is deadlock free. R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 32/43

33 Implementation Model with Event Bus (1) Claim If the event bus works in FIFO manner, communication order is preserved. Deadlock-freeness is preserved. R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 33/43

34 Implementation Model with Event Bus (2) R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 34/43

35 Non-Functional Analysis Assessment of Service-Level Agreements currently to be done manually (PEPA) only exemplified for express checkout Assessment of advantage of using express checkout customers with eight items or fewer may also use normal checkout Probability Differences between the express checkout and a normal checkout 0.08 express checkout normal checkout Probability Differences between the express checkout and a normal checkout 0.6 express checkout normal checkout Time Time R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 35/43

36 Tools MagicDraw UML modelling Labelled Transition System Analyser (LTSA) based on process algebra FSP used for analysis of deadlock and observational equivalence Hugo/RT UML model translator for model checking (SPIN, UPPAAL), theorem proving (KIV), and code generation (Java, SystemC) used for code generation for Java/A Imperial PEPA Compiler (IPC) based on Performance Evaluation Process Algebra (PEPA) used for quantitative analysis with Continuous-Time Markov Chains R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 36/43

37 Java/A: Architectural Programming Architectural programming language integration of architectural notions into Java avoiding architectural erosion in implementation composite component SimplifiedStore { assembly { components { Inventory, CashDesk } connectors { Inventory.Sale, CashDesk.CDAI; } } constructor SimplifiedStore() { initial configuration { active component Inventory inv = new Inventory(); active component CashDesk cd = new CashDesk(); connector Connector con = new Connector(); con.connect(inv.sale, cd.cdai); } } } R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 38/43

38 Java/A: Components and Ports simple component CashDeskApplication { int itemcounter = 0;... port CDACB { provided { async salestarted(); async productbarcodeentered(int barcode); async salefinished(); async paymentmodecash();... } required { async changeamountcalculated(double amount); async salesuccess(); } protocol <! behaviour { states { initial init; simple a; simple b; simple e;... simple h; } transitions { init -> a; a -> b { trigger salestarted; } b -> b { trigger productbarcodeentered; }... e -> h { effect out.salesuccess(); } h -> b { trigger salestarted; } } }!> }... R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 40/43

39 Java/A: Interface Implementation } void salestarted() implements CDACB.saleStarted() { Event event = Event.signal("send salestarted", new Object[]{}); this.eventqueue.insert(event); }... void processsalestarted() { try { CDAP.saleStarted(); CDACDG.saleStarted(); } catch (ConnectionException e) { e.printstacktrace(); } }... R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 42/43

40 Open Issues Extension of functional analysis integration of pre- and post-conditions for synchronous operations n-ary connectors Integration of non-functional analysis annotation of state machines and sequence diagrams by performance properties Runtime reconfiguration e.g., opening and closing cash desks Deployment view R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 43/43