Upload
dangngoc
View
217
Download
0
Embed Size (px)
Citation preview
Service-Oriented Modeling of CoCoME
with FOCUS and AutoFOCUS
Florian Hölzl
CoCoME Seminar Dagstuhl 02.08.2007
Department of Informatics
Chair IV: Software & Systems Engineering1
Florian Hölzl
Chair IV: Software and Systems Engineering
Department of Informatics
Technische Universität München
Our Team
Dr. Bernhard Schätz Model-Based Software Development
Michael Meisinger Service-Based Software Development
Sabine Rittmann Service-Oriented Software Engineering
Doris Wild Automotive Software and System Design
Maria Spichkova Verification of Embedded Systems
Department of Informatics
Chair IV: Software & Systems Engineering2
Jorge Fox Aspect Oriented Software Development
Dagmar Koss Compatibility
Birgit Penzenstadler Requirements Engineering for Subsystems
Marco Kuhrmann Process Models
Florian Hölzl Tool Support in Model-Based Development
Responsibilities / Contributions
Theory
Service Architecture Level
Department of Informatics
Chair IV: Software & Systems Engineering3
Logical Architecture Level
Deployment Level
Modeling Approach
Functional/
Service Arch.
Level
Formal
Specification
Level
Informal
Requirements
Level
Use Cases
Formal Specification
Service Model
Formalization
Design Step:
Operationalization
Validation
System (invariant) (error-cond)
‾ (progress) ‾ scenario1
Semantical
Interpretation
C4
C1 C2
C3
cdd SYSTEM cmd SYSTEMR2R1
request
msc service1
Functional
Design
Department of Informatics
Chair IV: Software & Systems Engineering4
Technical Architecture Model
Logical Architecture Model
Level
Logical
Architecture
Level
Deployment
Level
Implementation Step:
Transformation
Refinement
Implementation Step:
Infrastructure Mapping
Replication
C4
C1 C2
C3
Implementation
Level
Implementation
ECU
CPU1 DB
CPU2
Implementation Step:
Source Code Gen
Manual Impl.
2:C
1:C1:D
x
y
Part I: The FOCUS Component Model
Department of Informatics
Chair IV: Software & Systems Engineering5
System Model
Streams
Strong Causality
Composition
System Model
lc
clLM Control RM
cr
rc
kc
Component
Component Name
Department of Informatics
Chair IV: Software & Systems Engineering6
Channel
System consists of
• named Components (with encapsulated States / State Machine)
• named Channel (possibly typed)
with a model of DISCRETE GLOBAL TIME
Channel Name
Modelling Channels: Streams
Terminology
• Channels connect two Subsystems or a System and
its Environment (Input or Output Channels)
• Streams model Communication History of Channels
Department of Informatics
Chair IV: Software & Systems Engineering7
• Streams model Communication History of Channels
• Composed Systems are defined by Recursive
Equations over Streams
Streams
Let M be the set of messages
M* Set of finite sequences over M
⟨⟩ empty sequence
M∞ Set of infinite sequences over M IN \ {0} → M
Department of Informatics
Chair IV: Software & Systems Engineering8
Mω Set of streams: Mω = M* ∪ M∞
(M*)∞ Set of timed streams over M -
a sequence of messages for each time interval
Timed Streams
E
eq
qeQ
Semantic Model for Interface Behavior
Infinite Channel Set of messages:
Department of Informatics
Chair IV: Software & Systems Engineering9
t t+1 t+2 t+3
<a,d,a,b> <>
Messages in time interval t
Infinite Channel History M = {a, b, c, ...}
Interface Model
I = { x1, x2, …} set of input channels
O = {y1, y2, …} set of output channels
Interface Behavior: map input histories to output histories
Department of Informatics
Chair IV: Software & Systems Engineering10
x 1 : S 1 x n : S n
y1 : T 1
ym : T m F
M M
Strong Causality
Interface Behavior
Strong Causality
Department of Informatics
Chair IV: Software & Systems Engineering11
I O
F
A causal component F is total,e.g. F.x ≠ ∅ for all x,OR F.x = ∅ für alle x
Composition of Specifications
in x1: M1 , x2: M2 , ...
out y1: N1 , y2: N2 , ...
∃ c1, c2 , ... : P1 ∧ ... ∧ Pn
y1: N
1x
1: M
1
Composed
Componen t P
Department of Informatics
Chair IV: Software & Systems Engineering12
x2 : M
2
Componen t
P3
y2 : N
2
P4
P1
P2
c1 : T
1
Part II: The CoCoME Model
Department of Informatics
Chair IV: Software & Systems Engineering13
Functional / Service Architecture
Logical Components Architecture
Deployment
Implementation
Functional / Service Architecture Level
• Identify abstract components
• Identify communication dependencies
• Identify modes of operation of components
• Specify the services of each component as MSC
• Compose services using higher-level MSCs
Department of Informatics
Chair IV: Software & Systems Engineering14
• Compose services using higher-level MSCs
• Refactor components, modes and services as needed
• Semantical Interpretation into Behavior Automata
Functional System Decomposition
• System decomposes into communicating entities
Department of Informatics
Chair IV: Software & Systems Engineering15
Component Mode Diagram
Department of Informatics
Chair IV: Software & Systems Engineering16
High-Level Message Sequence Chart
Department of Informatics
Chair IV: Software & Systems Engineering17
Hierarchical HMSC Decomposition
Department of Informatics
Chair IV: Software & Systems Engineering18
Service Message Sequence Chart
Department of Informatics
Chair IV: Software & Systems Engineering19
Subservice Message Sequence Chart
Department of Informatics
Chair IV: Software & Systems Engineering20
Semantical Interpretation
• Behavior Automata
Department of Informatics
Chair IV: Software & Systems Engineering21
Functional Architecture Properties
• Consistency
– Service specification comply with mode switches
– Interaction with externals comply with interface specification
• Completeness
– Internal and external services have a service specifications
Department of Informatics
Chair IV: Software & Systems Engineering22
– Internal and external services have a service specifications
– Service specification exist for each mode and mode transition
• Closed World Assumption
– Complete consistent set of services form the exact
specification of the components‘ behavior
Functional Architecture Level Results
Department of Informatics
Chair IV: Software & Systems Engineering23
Logical Architecture Level
• Map Services to Logical Components
• Map Messages to Data Types
• Specify System Structure
• Transform Behavior Automata to FOCUS Timed
State Transition Automata
Department of Informatics
Chair IV: Software & Systems Engineering24
State Transition Automata
• Complete the FOCUS specification
Mapping Services to Logical Components
Department of Informatics
Chair IV: Software & Systems Engineering25
Mapping Messages to Data Structures
Department of Informatics
Chair IV: Software & Systems Engineering26
CashDesk System Structure Specification
Department of Informatics
Chair IV: Software & Systems Engineering27
CashDesk Node Structure Specification
CashBox(i)
kindb: PaymentKind
pd: ProductAck
ackb: PaymentAck
express: Bool
BarCodeScanner(i)cs: ProductBarcode cash: N
cbi: CashBoxInfo
cb: ProductBarcode
start: Event
stop: Event
mcode: ProductBarcode
mcard: PaymentKind
mcash: N
mchange: N
expOff: EventexpEnabled: Event
expDisabled Event
abort: Event
Department of Informatics
Chair IV: Software & Systems Engineering28
info: SaleInfo
c: ProductBarcode
bdata: BankData
CardReader(i)pinr: CardPIN
numr: CardNumber
ackcd: PaymentAck
Printer(i)
print: Bool
pdata: ProductData
CashDeskGUI(i)
sum: N
given: N
change: N
kind: PaymentKind
CashDeskControl
(i)
amount: N
expDisabled: Event
printHeader: Event
activate: Event
eModeViol: Event
cleanOut: Event
Transformation of Behavior Automata
• Merge parallel output actions
• Remove epsilon transitions
• Merge local variable transformations
• Remove internal communication
• Merge general computation
Department of Informatics
Chair IV: Software & Systems Engineering29
• Merge general computation
• Transform messages into FOCUS syntax
• RESULT: FOCUS time state transition diagrams
Merge Parallel Output Actions
Department of Informatics
Chair IV: Software & Systems Engineering30
Remove Epsilon Transitions
Department of Informatics
Chair IV: Software & Systems Engineering31
Merge Local Variable & Internal Comm.
• Local Variables are updated
• Intra-component communication is removed
Department of Informatics
Chair IV: Software & Systems Engineering32
Merge General Computation
Department of Informatics
Chair IV: Software & Systems Engineering33
Transform to FOCUS Syntax
Department of Informatics
Chair IV: Software & Systems Engineering34
CashDeskControl Behavior Specification
Department of Informatics
Chair IV: Software & Systems Engineering35
Complete FOCUS Specification (I)
Department of Informatics
Chair IV: Software & Systems Engineering36
Complete FOCUS Specification (II)
Department of Informatics
Chair IV: Software & Systems Engineering37
Logical Architecture Level Results
Store
info[i]: SaleInfo
pd[i]: ProductAck
bdata[i]: BankData
ackb[i]: PaymentAck
Node(i)
c[i]: ProductBarcode
CashDeskCoord
infoc:
ProductBarcode
i [1..n]
ord: N
allpr: ProductDescr
receive:
InventoryData
Bank
start[i]: Event
stop[i]: Event
mcode[i]:
ProductBarcode
mcard[i]:
PaymentKind
mcash[i]: N
mchange[i]: NexpEnabled[i]: Event
expOff[i]:Event
ackinv:
Event
ExpressDisplay(i)
express[i]: Bool
changeprice:
ChPrice
ackrcv: Event
Department of Informatics
Chair IV: Software & Systems Engineering38
deficiency: ProductDescrchanged: Bool
CashBox(i)
kindb: PaymentKind
info: SaleInfo
c: ProductBarcode
pd: ProductAck
bdata: BankData
ackb: PaymentAck
express: Bool
BarCodeScanner(i)cs: ProductBarcode
CardReader(i)pinr: CardPIN
numr: CardNumber
ackcd: PaymentAck
Printer(i)
print: Bool
pdata: ProductData
CashDeskGUI(i)
sum: N
given: N
cash: N
change: N
cbi: CashBoxInfo
kind: PaymentKind
CashDeskControl
(i)
cb: ProductBarcode
amount: N
start: Event
stop: Event
mcode: ProductBarcode
mcard: PaymentKind
mcash: N
mchange: N
expOff: EventexpEnabled: Event
expDisabled: Event
abort: Event
printHeader: Event
activate: Event
eModeViol: Event
cleanOut: Event
Deployment Level
• Technical Architecture
– Components are arbitrarily clustered into Tasks
– Tasks form executable objects implementing the behavior
• Operational Architecture
– Deployment Infrastructure
Department of Informatics
Chair IV: Software & Systems Engineering39
– Deployment Infrastructure
• Thread
• Remote Method Invocation Facility
– Execution Environment / Target Platform
• Java Virtual Machines
• TA + OA + External IFC = Executable System
Deployment Methodology
• Embed every logical
component in a Task
• Embed entities of the
technical architecture into
Task
LogicalComponent
communicate
*
Logical Architecture
Technical Architecture
Department of Informatics
Chair IV: Software & Systems Engineering40
technical architecture into
entities of the operational
architecture
• Most code is generated
• External interfaces
connected manually
1
VirtualMachine
runs_on Operational Architecture
Deployment Example
Department of Informatics
Chair IV: Software & Systems Engineering41
• RMI calls synchronized by Producer / Consumer
• Strong Causality ensures Dead-lock freedom
• Synchronous Message Exchange + NoVal Messages
= Asynchronous Communication
AutoFOCUS 2 Model: Mock-up Prototype
Department of Informatics
Chair IV: Software & Systems Engineering42
Handwritten Implementation: Mock-up PT
• Manual part override dummy automata
Department of Informatics
Chair IV: Software & Systems Engineering43
Part III: Conclusion and Experiences
Department of Informatics
Chair IV: Software & Systems Engineering44
Summary
Lessons Learned
Summary
Logical Architecture Model
Functional/
Service Arch.
Level
Logical
Architecture
Level
Service Model
Implementation Step:
Transformation
Refinement
C4
C1 C2
C3
Semantical
Interpretation
C4
C1 C2
C3
cdd SYSTEM cmd SYSTEMR2R1
request
msc service1
x
y
Department of Informatics
Chair IV: Software & Systems Engineering45
Technical Architecture Model
Deployment
Level
Implementation Step:
Infrastructure Mapping
Replication
Implementation
Level
Implementation
ECU
CPU1 DB
CPU2
Implementation Step:
Source Code Gen
Manual Impl.
2:C
1:C1:D
Lessons Learned
• Instantiation changes system structure in Deployment
– Connecting N cashdesks with the inventory changes the
inventory behavior
– Using a merger / bus component changes delay in the
communication from cashdesk to inventory
• Our methodology works for distributed teams
Department of Informatics
Chair IV: Software & Systems Engineering46
• Our methodology works for distributed teams
– Service Level Team analyzed requirements
– Logical Level Team used service architecture specification
– Deployment Team used logical architecture specification
Part IV: Demonstration
Department of Informatics
Chair IV: Software & Systems Engineering47
AutoFOCUS 2 Model
System in Action
Backup
Department of Informatics
Chair IV: Software & Systems Engineering48
Detailed Service Specification I
Department of Informatics
Chair IV: Software & Systems Engineering49
Detailed Service Specification II
Department of Informatics
Chair IV: Software & Systems Engineering50
Detailed Service Specification III
Department of Informatics
Chair IV: Software & Systems Engineering51
Detailed Service Specification IV
Department of Informatics
Chair IV: Software & Systems Engineering52
Parallel reaction problem
Department of Informatics
Chair IV: Software & Systems Engineering53