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