Object Life Cycles: FSMs Architecture and Modelling of Information Systems (D0I71A) Prof. dr. Monique Snoeck

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

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

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. 22:44

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

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) 22:44

Specification of sequence constraints B.C.D B + C + D 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) OR C D B B,C,D Natural Language Finite State Machine (UML) Regular Expr. 22:44

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

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) 22:44

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

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) 22:44

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 ! Check global behaviour ! 22:44

Quality Check: Single FSM Backward inaccessible state Forward inaccessible state 22:44

Quality Check: Single FSM Non-determinism: What is the next state for these methods? 22:44

Resolving non-determinism using guards (in UML – not possible in JMERMAID-tool) 22:44

22:44

Stratification of FSMs Organise the states and transitions along two axes: axis 1 = progress towards the end state axis 2 = loops 22:44

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

Stratification 22:44

Partly Stratified FSM for movie star end _star marry 3 4 divorce end _star hire hire fire fire end _star marry 1 2 cr _star divorce end _star 22:44

Parallelism in UML: Fork & Join 22:44

Parallelism in UML: Fork & Join marry single married divorce end_MovieStar cr_Moviestar hire noJob withJob fire 22:44

Parallelism in UML: orthogonal state with regions 22:44

Parallelism in JMermaid: many FSMs per Object Type (Roles) marry end _star cr _star 3 4 divorce end _star end _star cr _star hire 2 1 fire end _star 22:44

Calculated FSM in JMermaid : end _star marry 3 4 divorce end _star hire hire fire fire end _star marry 1 2 cr _star divorce end _star 22:44

22:44

22:44

22:44

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

FSM Roles Default User-specified Calculated  select one for code-generation ! 22:44

FSM roles: DEFAULT methods and transitions 2 states (exists, ended) 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 22:44

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

Calculated FSMs Non-used events can appear anywhere in FSM 22:44

22:44

22:44

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

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. 22:44

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

22:44

Modelling interaction with FSM 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 22:44

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) managed by JMermaid ... 22:44

Quality Check: BP instead of OLC = bad practice !! 22:44

BP versus Object Life Cycles BP: group behaviour according to aspects of work organisation FSM: group behaviour per business object type Object Type A Object Type B Object Type C Object Type D X Y Z 22: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) 22:44

BP versus OLC: example 22:44

Quality Check: Global behaviour 22:44

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

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 BUILDING 22:44

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

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

Master manages dependents constraints across LOAN and RESERVATION Renew not possible when reserved 22:44

FSM Exercise: Commercial Cy 22:44

Master manages dependents: Example State change in dependent changes state of master OrderLine Delivery Line 22:44

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

Global behaviour All objects need to agree turnRight turnRight turnLeft 22:44

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

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

Scenario execution Event Evaluation Final Outcome and effect Acquire (Harry-Potter) validated only by copy (HarryPotter): accepted accept; copy (HarryPotter) is in state 1 Borrow (L1, HarryPotter) validated by copy (HarryPotter): rejected because copy (HarryPotter) is in state 1 and in that state, a borrow event is not allowed validated by loan (accepted) reject Classify (HarryPotter) validated by copy (HarryPotter) only and accepted)) accepted; copy (HarryPotter) is put in state 2 validated by copy (HarryPotter) and accepted validated by loan and accepted accepted; loan(L1) is created 22:44

Scenario execution (ctd) Event Evaluation Final Outcome and effect Dispose (HarryPotter) validated by copy (HarryPotter) only. Request is refused because of referential integrity constraint: master object cannot be ended as long as it has living dependents reject Borrow (L2, HarryPotter) validated by copy (HarryPotter) and rejected because of cardinality constraint: a copy can have at most one loan. validated by loan (accept) Return (L1, HarryPotter) validated by copy (HarryPotter) and accepted validated by loan (L1) and accepted accepted; Loan(L1) is put in state 2. validated by copy (HarryPotter) only and accepted accepted; copy (HarryPotter) is put in the final state 22:44

borrow, return, renew acquire lose classify sell FSM for COPY FSM for LOAN FSM for LOAN* renew borrow return, lose 1 borrow renew 1 return, lose FSM for COPY || LOAN* acquire sell classify lose renew borrow return, lose 22:44