modelling the cocome with the java/a component model contest common component... · modelling the...
TRANSCRIPT
Modelling the CoCoME withthe Java/A Component Model
Rolf Hennicker, Alexander KnappLudwig-Maximilians-Universitat Munchen
August 2007
The Java/A TeamI Ludwig-Maximilians-Universitat Munchen
I UML modelling, qualitative analysis
I Florian HacklingerI Rolf HennickerI Stephan JanischI Alexander KnappI Martin Wirsing
I University of EdinburghI quantitative analysis
I Allan ClarkI Stephen Gilmore
I Danmarks Tekniske Universitet, LyngbyI UML modelling, qualitative analysis
I Hubert Baumeister
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 2/43
Overview
I Java/A component modelI Modelling the CoCoMEI Analysis of our model for the CoCoMEI ToolsI Open issues
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 3/43
The Java/A Component Model (1)
Feature
0..1
required
0..1
providedInterface
Port
Behavior
Operation
Property
operationsoperations
*
properties
*
behavior
1
*
*
operations
PortProperty
type
1 properties}
behavior
1
Operation
Behavior
Property
Port
SimpleComponent
properties
*
ports
{subsets
*
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 4/43
Simple Components: Example
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 5/43
The Java/A Component Model (2)
Component
ComponentSimple
PropertyComponent
PropertyProperty
Port
PropertyConnector
*
connectors
Connector Port
type
1
ComponentComposite components
*
relayPorts
*
ports2
type1
2
ports
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 6/43
Composite Components: Example
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 7/43
Modelling the CoCoME — Procedure (1)
1. Primary scenarios from CoCoME descriptionI static structure of simple componentsI port and component behaviourI analysis of behaviour (embedded system part)I integration of simple components into composite components
2. Alternative and exceptional scenarios from CoCoMEdescription
3. Iteration
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 8/43
Modelling the CoCoME — Procedure (2)I Deriving state machines from interactions
: CashDeskApplication
ref payment mode card
expressModeEnabledopt
: Coordinator
saleStarted
saleFinished
paymentMode(CASH)
cashAmountEntered
changeAmountCalculated
cashBoxClosed
saleRegistered
alt
Process salesd
: CashBox
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 9/43
Modelling the CoCoME — Procedure (3)
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 10/43
Modelling the CoCoME — OverviewCashDeskLine Store::CashDeskLine
CashDesk CashDeskCardReaderController CardReaderCashBoxController CashBoxCashDeskApplication CashDeskApplicationCashDeskGUI CashDeskGUILightDisplayController LightDisplayPrinterController PrinterScannerController Scanner
Coordinator CoordinatorEventBus Not modelled
Inventory Not explicitly; distinguished Enterprise/StoreApplication Ditto due to distinct Enterprise/Store
Reporting Enterprise::ReportingStore Store::Inventory
Data DataEnterprise Data instantiated in EnterpriseStore Data instantiated in StorePersistence integrated in ports of Data
GUI modelled as operator portsReporting ports of Enterprise::ReportingStore ports of Store::Inventory
DataBase DataBase
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 11/43
TradingSystem — Static Structure
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 12/43
Store — Static Structure
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 13/43
CashDeskLine — Static Structure
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 14/43
Coordinator — Static Structure
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 15/43
Coordinator — Port Behaviour
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 16/43
Coordinator — Component Behaviour
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 17/43
CashDesk — Static Structure
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 18/43
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:I Deadlock-freeness of port and component behavioursI Correctness of components w.r.t. their ports
Focus of our analysis: Embedded system part
Analysis process:I Starts with the analysis of simple components and their portsI Derives results for composite components
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 19/43
Composite Component CashDeskLine (revisited)
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 20/43
Behaviour Specifications and their Formalisation
State machines 7→ 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
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
Behaviour of Port Coordinator–CashDesk
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 23/43
Analysis of Simple Components
Steps:I Check the deadlock-freeness of ports and simple componentsI Check the compliance of component and port behaviours
Definition (Component correctness)
Observable behaviour of a component C at port p : P
obsp(beh(C)) ≈ beh(P)
Example: obscd(beh(Coordinator)) ≈ beh(C-CD)
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 24/43
Analysis of Composite Components
Assume given: Correct and deadlock-free subcomponents
Analysis steps:I Examine (pairwise) the interaction behaviour of connected
portsI Check the deadlock-freeness of the composite componentI 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
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
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
Important Observation
c : Cb : B
«component»
CC
a : A
Behavioural compatibility of the connected ports+ deadlock-freeness of all subcomponents
6⇒deadlock-freeness of the composite component
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 28/43
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 portsreflects 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
Deadlock-freeness of Composite Components
Assume:I Deadlock-freeness and correctness of all subcomponentsI Behavioural compatibility of all connected portsI 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
Deadlock-freeness of the CashDesk Component
I All subcomponents are deadlock-free and correctI All connected ports are behaviourally compatibleI 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
Deadlock-freeness of the CashDeskLine
I The subcomponents Coordinator and CashDesk aredeadlock-free and correct
I The connected ports are behaviourally compatible (and evenbehaviour reflecting)
Hence the CashDeskLine component is deadlock free.R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 32/43
Implementation Model with Event Bus (1)
ClaimI If the event bus works in FIFO manner, communication order is
preserved.I Deadlock-freeness is preserved.
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 33/43
Implementation Model with Event Bus (2)
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 34/43
Non-Functional Analysis
I Assessment of Service-Level AgreementsI currently to be done manually (PEPA)I only exemplified for express checkout
I Assessment of advantage of using express checkoutI customers with eight items or fewer may also use normal
checkout
0
0.01
0.02
0.03
0.04
0.05
0.06
0.07
0.08
0 1 2 3 4 5 6 7 8 9 10
Pro
babi
lity
Time
Differences between the express checkout and a normal checkout
express checkoutnormal checkout
0
0.1
0.2
0.3
0.4
0.5
0.6
0 5 10 15 20 25 30 35 40 45 50
Pro
babi
lity
Time
Differences between the express checkout and a normal checkout
express checkoutnormal checkout
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 35/43
Tools
I MagicDrawI UML modelling
I Labelled Transition System Analyser (LTSA)I based on process algebra FSPI used for analysis of deadlock and observational equivalence
I Hugo/RTI UML model translator for model checking (SPIN, UPPAAL),
theorem proving (KIV), and code generation (Java, SystemC)I used for code generation for Java/A
I Imperial PEPA Compiler (IPC)I based on Performance Evaluation Process Algebra (PEPA)I used for quantitative analysis with Continuous-Time Markov
Chains
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 36/43
Java/A: Architectural Programming
I Architectural programming languageI integration of architectural notions into JavaI 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
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
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
Open Issues
I Extension of functional analysisI integration of pre- and post-conditions for synchronous
operationsI n-ary connectors
I Integration of non-functional analysisI annotation of state machines and sequence diagrams by
performance properties
I Runtime reconfigurationI e.g., opening and closing cash desks
I Deployment view
R. Hennicker, A. Knapp: Modelling the CoCoME with the Java/A Component Model 43/43