1. Object Life Cycles: FSMs
Architecture and Modelling of Information Systems (D0I71A)
Prof. dr. 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
22:44

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

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

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

6. 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

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

8. 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

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

10. 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

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

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

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

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

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

16. 22:44

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

18. 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

19. Stratification
22:44

20. 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

21. Parallelism in UML: Fork & Join
22:44

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

23. Parallelism in UML: orthogonal state with regions
22:44

24. 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

25. 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

26. 22:44

27. 22:44

28. 22:44

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

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

31. 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

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

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

34. 22:44

35. 22:44

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

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

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

39. 22:44

40. 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

41. 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

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

43. 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

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

45. BP versus OLC: example
22:44

46. Quality Check: Global behaviour
22:44

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

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

49. 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

50. 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

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

52. FSM Exercise: Commercial Cy
22:44

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

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

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

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

57. 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

58. 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

59. 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

60. 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