Service-Oriented Modeling of CoCoME with FOCUS and AutoFOCUS

Transcription

1 CoCoME Seminar Dagstuhl Service-Oriented Modeling of CoCoME with FOCUS and AutoFOCUS Florian Hölzl Chair IV: Software and Systems Engineering Technische Universität München 1

2 Our Team Dr. Bernhard Schätz Michael Meisinger Sabine Rittmann Doris Wild Maria Spichkova Jorge Fox Dagmar Koss Birgit Penzenstadler Marco Kuhrmann Florian Hölzl Model-Based Software Development Service-Based Software Development Service-Oriented Software Engineering Automotive Software and System Design Verification of Embedded Systems Aspect Oriented Software Development Compatibility Requirements Engineering for Subsystems Process Models Tool Support in Model-Based Development 2

3 Responsibilities / Contributions Theory Service Architecture Level Logical Architecture Level Deployment Level 3

4 Modeling Approach Informal Requirements Level Use Cases Formalization Validation Formal Specification Level Formal Specification System (invariant) (error-cond) (progress) scenario1 Functional Design Design Step: Operationalization Functional/ Service Arch. Level cdd SYSTEM C1 C2 C3 C4 Service Model cmd SYSTEM msc service1 R1 R2 request Semantical Interpretation Implementation Step: Transformation Refinement Logical Architecture Level Logical Architecture Model C1 C2 x C3 C4 y Deployment Level Implementation Step: Infrastructure Mapping Replication Technical Architecture Model 2:C 1:C 1:D Implementation Step: Source Code Gen Manual Impl. 4 Implementation Level Implementation CPU1 Chair IV: Software & Systems ECU Engineering CPU2 DB

5 Part I: The FOCUS Component Model System Model Streams Strong Causality Composition 5

6 System Model Component kc LM lc cl Control cr rc RM Component Name Channel System consists of named Components (with encapsulated States / State Machine) named Channel (possibly typed) with a model of DISCRETE GLOBAL TIME Channel Name 6

7 Modelling Channels: Streams Terminology Channels connect two Subsystems or a System and its Environment (Input or Output Channels) Streams model Communication History of Channels Composed Systems are defined by Recursive Equations over Streams 7

8 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 M ω Set of streams: M ω = M * M (M * ) Set of timed streams over M - a sequence of messages for each time interval 8

9 Timed Streams Semantic Model for Interface Behavior eq E qe Q Set of messages: M = {a, b, c,...} t t+1 t+2 t+3 Infinite Channel History <a,d,a,b> <> Messages in time interval t 9

10 Interface Model I = { x1, x2, } O = {y1, y2, } set of input channels set of output channels Interface Behavior: map input histories to output histories x 1 : S 1 x n : S n M F M y 1 : T 1 y m : T m 10

11 Strong Causality Interface Behavior Strong Causality A causal component F is total, e.g. F.x for all x, OR F.x = für alle x I F O 11

12 Composition of Specifications in x 1 : M 1, x 2 : M 2,... out y 1 : N 1, y 2 : N 2,... c 1, c 2,... : P 1... P n x 1 : M 1 y 1 : N 1 Composed Componen t P 1 c 1 : T 1 P 3 P 2 P 4 y 2 : N 2 x 2 : M 2 12

13 Part II: The CoCoME Model Functional / Service Architecture Logical Components Architecture Deployment Implementation 13

14 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 Refactor components, modes and services as needed Semantical Interpretation into Behavior Automata 14

15 Functional System Decomposition System decomposes into communicating entities 15

16 Component Mode Diagram 16

17 High-Level Message Sequence Chart 17

18 Hierarchical HMSC Decomposition 18

19 Service Message Sequence Chart 19

20 Subservice Message Sequence Chart 20

21 Semantical Interpretation Behavior Automata 21

22 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 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 22

23 Functional Architecture Level Results 23

24 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 Complete the FOCUS specification 24

25 Mapping Services to Logical Components 25

26 Mapping Messages to Data Structures 26

27 CashDesk System Structure Specification 27

28 CashDesk Node Structure Specification mcode: ProductBarcode abort: Event mcard: PaymentKind mcash: N start: Event expenabled: Event pd: ProductAck ackb: PaymentAck express: Bool expoff: Event stop: Event mchange: N cbi: CashBoxInfo kindb: PaymentKind BarCodeScanner(i) cs: ProductBarcode cash: N cb: ProductBarcode CashBox(i) activate: Event expdisabled: Event CardReader(i) numr: CardNumber pinr: CardPIN CashDeskControl (i) change: N ackcd: PaymentAck c: ProductBarcode info: SaleInfo bdata: BankData printheader: Event print: Bool given: N pdata: ProductData kind: PaymentKind amount: N Printer(i) sum: N cleanout: Event emodeviol: Event CashDeskGUI(i) 28

29 Transformation of Behavior Automata Merge parallel output actions Remove epsilon transitions Merge local variable transformations Remove internal communication Merge general computation Transform messages into FOCUS syntax RESULT: FOCUS time state transition diagrams 29

30 Merge Parallel Output Actions 30

31 Remove Epsilon Transitions 31

32 Merge Local Variable & Internal Comm. Local Variables are updated Intra-component communication is removed 32

33 Merge General Computation 33

34 Transform to FOCUS Syntax 34

35 CashDeskControl Behavior Specification 35

36 Complete FOCUS Specification (I) 36

37 Complete FOCUS Specification (II) 37

38 Logical Architecture Level Results bdata[i]: BankData start[i]: Event Bank ackb[i]: PaymentAck mcode[i]: ProductBarcode mcard[i]: PaymentKind ExpressDisplay(i) express[i]: Bool Node(i) mcash[i]: N stop[i]: Event expoff[i]:event CashDeskCoord info[i]: SaleInfo expenabled[i]: Event mchange[i]: N infoc: ProductBarcode ackinv: Event c[i]: ProductBarcode Store pd[i]: ProductAck receive: InventoryData i [1..n] changeprice: ChPrice ackrcv: Event changed: Bool ord: N allpr: ProductDescr deficiency: ProductDescr abort: Event mcode: ProductBarcode mcard: PaymentKind mcash: N expenabled: Event pd: ProductAck ackb: PaymentAck express: Bool cs: ProductBarcode BarCodeScanner(i) activate: Event start: Event expoff: Event stop: Event mchange: N cbi: CashBoxInfo kindb: PaymentKind cash: N cb: ProductBarcode expdisabled: Event CashBox(i) CardReader(i) numr: CardNumber pinr: CardPIN CashDeskControl (i) change: N ackcd: PaymentAck printheader: Event c: ProductBarcode info: SaleInfo bdata: BankData print: Bool given: N pdata: ProductData kind: PaymentKind Printer(i) amount: N sum: N cleanout: Event emodeviol: Event CashDeskGUI(i) 38

39 Deployment Level Technical Architecture Components are arbitrarily clustered into Tasks Tasks form executable objects implementing the behavior Operational Architecture Deployment Infrastructure Thread Remote Method Invocation Facility Execution Environment / Target Platform Java Virtual Machines TA + OA + External IFC = Executable System 39

40 Deployment Methodology Logical Architecture Embed every logical LogicalComponent component in a Task Embed entities of the technical architecture into communicate * Task Technical Architecture entities of the operational architecture 1 runs_on Operational Architecture VirtualMachine Most code is generated External interfaces connected manually 40

41 Deployment Example RMI calls synchronized by Producer / Consumer Strong Causality ensures Dead-lock freedom Synchronous Message Exchange + NoVal Messages = Asynchronous Communication 41

42 AutoFOCUS 2 Model: Mock-up Prototype 42

43 Handwritten Implementation: Mock-up PT Manual part override dummy automata 43

44 Part III: Conclusion and Experiences Summary Lessons Learned 44

45 Summary Functional/ Service Arch. Level cdd SYSTEM C1 C2 C3 C4 Service Model cmd SYSTEM msc service1 R1 R2 request Semantical Interpretation Implementation Step: Transformation Refinement Logical Architecture Level Logical Architecture Model C1 C2 x C3 C4 y Deployment Level Technical Architecture Model 2:C 1:C 1:D Implementation Step: Infrastructure Mapping Replication Implementation Step: Source Code Gen Manual Impl. Implementation Level Implementation CPU1 DB ECU CPU2 45

46 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 Service Level Team analyzed requirements Logical Level Team used service architecture specification Deployment Team used logical architecture specification 46

47 Part IV: Demonstration AutoFOCUS 2 Model System in Action 47

48 Backup 48

49 Detailed Service Specification I 49

50 Detailed Service Specification II 50

51 Detailed Service Specification III 51

52 Detailed Service Specification IV 52

53 Parallel reaction problem 53