Object Life Cycles FSMs Architecture and Modelling of

Object Life Cycles: FSMs Architecture and Modelling of Information Systems (D 0 I 71 A) Prof. dr. Monique Snoeck (c) Monique Snoeck

2 Overview of MERODE § Enterprise Modelling Phase § identification of enterprise object types and business event types § identification of enterprise object types § identification of business event types § construction of EDG § Construction of OET § Specification of sequence constraints § specification of attributes and methods § identification of attributes § identification of object-event methods § identification of additional constraints 01: 10

3 Object Behaviour Modelling § Single object type behaviour: § Every object type has some particular life cycle that defines the sequences in which business events can occur 01: 10

4 Object Behaviour Modelling § Object Interaction § Business events can appear in the life cycle of more than one object type. § This means two or more object types impose a constraint on such business events. § When such business events is accepted, all the involved object types will move to a next state. 01: 10

5 Object Behaviour Modelling § Global system behaviour § The behaviour of the global system is the (complex) composition of all the object's individual behaviour along the principles of object interaction 01: 10

Modelling the behaviour of a single Object Type § Definition of one FSM per object type § State Machines (UML) can be messy/ unstructured § Enhance the structure of FSMs § by stratification § by using parallelism (Harel Statecharts) § by using parallelism (ROLES) 01: 10 6

7 Specification of sequence constraints Natural Language Finite State Machine (UML) B a sequence of first B, then C and then D a choice between B, C and D a repetition of B (0, 1 or many times B) 01: 11 B C C Regular Expr. D B, C, D OR B. C. D B+C+D D B B*

Comparison of behaviour modelling techniques § Regular expressions §easy to write down §hard to read § State Machines (UML) §UML compliant §allow to specify complex life-cycles §unstructured § (JSD diagrams) §well-structured §hard for complex life-cycles 01: 11 8

9 UML State charts § (quite complex) § State § Transition § Simplification § event [guard] / action eventname [precondition] / methodname § [precondition] /methodname (assuming eventname = methodname) § methodname (when no method precondition present) 01: 11

10 Sequence Constraints for the Library: FSMs TITLE start state create_title state acquire end_title acquire, classify, borrow, renew, final return, state lose, dispose COPY lose, dispose classify borrow, return, renew 01: 11 MEMBER register_member stop_membership Methods (not event types!) borrow, return, lose renew LOAN borrow return, lose renew

11 Sequence Constraints for the Library: RE TITLE = cr_title. (acquire + classify + borrow + renew + return + dispose + lose)*. end_title COPY = acquire. classify. (borrow + renew + return)*. (dispose + lose) MEMBER = enter. (change_member_info + borrow + renew + return + lose)*. leave LOAN = borrow. (renew)*. (return + lose) 01: 11

12 Drawing FSM's § Identify the states an object type can be in § E. g. Book is on loan, on shelf, in repair, . . . § Methods cause the transitions from one state to another § E. g. “borrow” causes transition from on shelf to on loan § Quality Check § Single FSM § All states should be accessible § FSM should be stratified § Use Roles for parallelism § Check consistency with OET § Check correctness of Object Life Cycle § Do not model Business Process ! 01: 11 § Check global behaviour !

13 Quality Check: Single FSM Backward inaccessible state Forward inaccessible state 01: 11

14 Quality Check: Single FSM Non-determinism: What is the next state for these methods? 01: 11

15 Resolving non-determinism using guards (in UML – not possible in JMERMAID-tool) 01: 11

16 01: 11

17 Stratification of FSMs § Organise the states and transitions along two axes: § axis 1 = progress towards the end state § axis 2 = loops 01: 11

18 Stratification renew acquire 1 classify 22 borrow return 3 lose 5 end_of copy 4 declassify 5 end_of 4 declassify renew 3 return borrow acquire 1 classify lose 2 declassify 01: 11 copy

19 Stratification 01: 11

Partly Stratified FSM for movie star end_star marry 3 4 divorce hire end_star fire end_star 1 cr_star marry 2 divorce end_star 01: 12 20

Parallelism in UML: Fork & Join 01: 12 21

Parallelism in UML: Fork & Join marry married single divorce cr_Moviestar hire with. Job no. Job fire 01: 12 end_Movie. Star 22

Parallelism in UML: orthogonal state with regions 01: 12 23

Parallelism in JMermaid: many FSMs per Object Type (Roles) marry cr_star 3 divorce 4 end_star cr_star 1 hire fire 01: 12 2 end_star 24

25 Calculated FSM in JMermaid : end_star marry 3 4 divorce hire end_star fire end_star 1 cr_star marry 2 divorce end_star 01: 12

26 01: 12

27 01: 12

28 01: 12

29 Use of Roles: assumptions § Base class has the default life-cycle unless otherwise specified (default role) § Each role has a life-cycle definition (defined through FSM) § Roles are executed in parallel with each other and with the base class § Roles are NOT independent object classes: they only exist in the context of the base class § not visible in EDG § only exist as multiple FSMs for one class § calculated FSM shows global behaviour of base class 01: 12

30 FSM Roles § § 01: 12 Default User-specified Calculated select one for code-generation !

31 FSM roles: DEFAULT § 2 states (exists, ended) § methods and transitions § § § Single create method -> transition to state “exists” Modify methods in state “exists” End method(s) – transitions to state “ended” INVOICE : default role PROPOSAL : default role 01: 12

32 FSM roles: User-specified § Contains user-specified states, method – transitions from/to specified states (specifies more behavior constraints) INVOICE : user – specified role PROPOSAL : user- specified role 01: 12

33 Calculated FSMs § Non-used events can appear anywhere in FSM 01: 12

34 01: 12

35 01: 12

36 Code Generation § One FSM should be marked as "selected" for code generation § Can be a calculated FSM § e. g. a role combined with default FSM right button click 01: 12

37 Object Behaviour Modelling § Object Interaction § Business events can appear in the life cycle of more than one object type. § This means two or more object types impose a constraint on such business events. § When such business events is accepted, all the involved object types will move to a next state. 01: 12

38 Quality Check: Consistency FSM -OET § When an Object Type is involved in an event type, the corresponding cell is marked in the OET § A marked cell in OET means that the object type has a method to react to events of that type § ALL the methods indicated in the OET should appear in your FSM (= alphabet rule) § Explicitly because they cause a transition to another state § Implicitly (= absent method in FSM) § means method is allowed in each state § Calculated FSM allows to calculate “complete” FSM § Use "Check" feature in JMermaid 01: 12

39 01: 12

Modelling interaction with FSM § 40 States constrain interaction sequence, i. e. behavior § can accept or reject events § Business Events are basis of interaction § events lead one or more objects to different states 01: 12

Quality Check: Consistency FSM -OET § Transition should respect the type of the method: § If a method appears as an ‘C‘-method in the OET it should be a creating method in your FSM as well (= default life cycle rule) § If a method appears as an ‘M‘-method in the OET it should be a modifying method in your FSM as well (= default life cycle rule) § If a method appears as an 'E‘-method in the OET it should be an ending method in your FSM as well (= default life cycle rule) 01: 12 § managed by JMermaid. . . 41

42 Quality Check: BP instead of OLC = bad practice !! 01: 12

43 BP versus Object Life Cycles § BP: group behaviour according to aspects of work organisation § FSM: group behaviour per business object type X Y X Z Y Object Type A 01: 12 Z X Y Object Type B Z X Object Type C Y Y Z Object Type D

44 BP versus OLC: example § "Customer pays invoice" § BP Perspective § Customer performs payment § TASK pay in BP of customer (subject of verb) § OLC perspective § invoice is paid § business event "Pay" in LC of invoice (object of verb) 01: 13

45 BP versus OLC: example 01: 13

46 Quality Check: Global behaviour 01: 13

47 Global Behaviour: defining FSMs for entire EDG § When creating FSMs § start with the "bottom" object types and climb up the EDG § model normal scenarios first, then exceptions § first include owned methods, then see where acquired methods fit in § master manages dependents ! § don’t repeat sequence constraints included in life cycle of dependent in the life cycle of the master 01: 13

48 Building and blocks A building can but need not belong to a block of buildings. A building belonging to a block can be removed from it at any time. BLOCK OF BUILDINGS BUILDING TO BLOCK ASSIGNMENT 01: 13

BLOCK OF BUILDINGS BUILDING 49 BUILDING TO BLOCK ASSIGNMENT Buildings and Blocks BUILDING TO BLOCK ASSIGNMENT BLOCK remove B put from Block B in Block exists cr_block exists end_block put B in Block remove B from Block Acquired Methods BUILDING 1 st possibility BUILDING 2 nd possibility destroy build exists put B in Block remove B from Block Acquired Methods 01: 13 build destroy unattributed remove B from Block Acquired Methods attributed put B in Block

Master class manages dependent classes § Choose/Alternate between dependents § (see previous example) § Manages sequence constraints across dependents § e. g. Book manages constraints across Loan and Reservation 01: 13 50

51 Master manages dependents § constraints across LOAN and RESERVATION Renew not possible when reserved 01: 13

52 FSM Exercise: Commercial Cy 01: 14

Master manages dependents: Example 53 § State change in dependent changes state of master Order. Line Delivery Line 01: 14

54 Object Behaviour Modelling § Global system behaviour § The behaviour of the global system is the (complex) composition of all the object's individual behaviour along the principles of object interaction 01: 14

55 Global behaviour § All objects need to agree Ri rn tu ft Le rn 01: 14 tu gh t turn. Right

56 Global behaviour § Behaviour of system is parallel composition of behaviour of individual objects § Global behaviour takes into account § Behaviour of single object according to FSM of object TYPE § Synchronisation by means of joint participation to events § Additional constraints: § Cardinality § Referential Integrity § Preconditions 01: 14

Global behaviour of Simplified Library COPY 1 classify acquire 1 2 borrow, return, renew 0. . 1 LOAN return, lose borrow 1 renew 01: 14 lose, dispose 57

58 Scenario execution Event Evaluation Final Outcome and effect Acquire (Harry. Potter) o validated only by copy (Harry. Potter): accepted accept; copy (Harry. Potter) is in state 1 Borrow (L 1, o validated by copy (Harry. Potter): rejected reject Harry. Potter) because copy (Harry. Potter) is in state 1 and in that state, a borrow event is not allowed o validated by loan (accepted) Classify o validated by copy (Harry. Potter) only and (Harry. Potter accepted)) ) Borrow (L 1, 01: 14 o validated by copy (Harry. Potter) and accepted; copy (Harry. Potter) is put in state 2 accepted;

59 Scenario execution (ctd) Event Evaluation Dispose o validated by copy (Harry. Potter) only. Request (Harry. Potter is refused because of referential integrity ) constraint: master object cannot be ended as long as it has living dependents Borrow (L 2, o validated by copy (Harry. Potter) and rejected Harry. Potter) because of cardinality constraint: a copy can have at most one loan. o validated by loan (accept) Return (L 1, o validated by copy (Harry. Potter) and accepted Harry. Potter) o validated by loan (L 1) and accepted Dispose o validated by copy (Harry. Potter) only and (Harry. Potter accepted ) 01: 14 Final Outcome and effect reject accepted; Loan(L 1) is put in state 2. accepted; copy (Harry. Potter) is

60 acquire FSM for COPY lose classify sell borrow, return, renew FSM for LOAN* FSM for LOAN return, lose borrow 1 1 renew FSM for COPY || LOAN* acquire classify borrow return, lose sell return, lose renew 01: 15 renew