Chapter 6. Object and System Behaviour 1. Object Behaviour - PowerPoint PPT Presentation

Chapter 6. Object and System Behaviour 1. Object Behaviour Modelling 2. Global System Behaviour 3. Consistency Checking with the OET 1. with the EDG 2. 4. Practical Modelling tips

2 Chapter 6: Object Behaviour Modelling  Position in the global modelling process  UML notation for Statecharts  MERODE simplifications  Basic Quality checks  Parallellism

3 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

4 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 Picture from https://www.maxpixel.net/Art-Colourful-Gears-Creativity-Cogs-Colorful-1866468 (CC0 license)

5 Object Behaviour Modelling  Object Interaction  Business events can appear in the life cycle of more than one object type.  When such business events is accepted, all the involved object types will move to a next state. picture from https://www.maxpixel.net/Machine-Machinery-Close-up-Gears-Cogs-Mechanical-1853057 (CC0 license)

6 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 Photo by carnifex82, Clockwork in the belltower St. Dionysius church, Duisburg - Walsum, Germany (CC License)

1 Chapter 6: Object Behaviour Modelling  Position in the global modelling process  UML notation for Statecharts  MERODE simplifications  Basic Quality checks  Parallellism

2 UML statecharts  UML notation for statecharts trigger* [guard condition] / operation  Behavior StateMachines can be used to specify any of the following:  The Behavior of an active Class.  A stand-alone Behavior, that is, one that does not have a corresponding Class.  A method corresponding to a BehavioralFeature (i.e., an Operation or a Reception).

3 UML Statecharts  State : simple, composite, submachine  Rather complex semantics for entry, internal transitions, exit

4 UML statecharts  Transitions  From a source vertex to a target vertex  May be a compound transition, bringing the state machine from a source configuration to a target configuration  Transition Label: triggers*[guard]/operation  zero to many triggers  zero or one guard expression  zero or one operation

5 UML statecharts  Trigger = event  When an Event occurrence is detected and dispatched, it may result in one or more Transitions being enabled for firing.  complex semantics in case multiple transitions are enabled, in case of conflicting transitions, for setting priorities  What kind of triggers does UML define ?  Message Events  SignalEvent (A SignalEvent represents the receipt of an asynchronous Signal instance)  CallEvent (A CallEvent models the receipt by an object of a message invoking a call of an Operation.)  AnyReceiveEvent (=ALL events)  Change Event (denoted by “when” followed by a Boolean ValueSpecification)  relative TimeEvent (denoted with “after” followed by a TimeExpression)

1 Chapter 6: Object Behaviour Modelling  Position in the global modelling process  UML notation for Statecharts  MERODE adaptations  Define 1 FSM per object type  Simplified transition labels  Quality checks  Unreachable states (syntactic quality)  Structure (pragmatic quality)  Stratification  Parallellism

2 MERODE Statecharts  Called Finite State Machines  because fully compliant with the mathematical definition of Finite State Machines as found in any book on compiler theory  (simpler, but compliant to UML statecharts).  called "finite" because of having a finite number of states

3 MERODE statecharts  MERODE notation for statecharts trigger* [guard condition] / operation [Name] [Name]  Behavior StateMachines can be used to specify any of the following:  The Behavior of an active Class.  A stand-alone Behavior, that is, one that does not have a corresponding Class.  A method corresponding to a BehavioralFeature (i.e., an Operation or a Reception).

4 MERODE statecharts  Transitions trigger* [guard condition] / operation  Trigger: Business Event  When an object is involved in a business event, the corresponding operation will be invoked  e.g. in class COPY borrow["state=available"]/borrow()  a Business Event's semantics are those of the CallEvent, whereby the call-event and the activity have identical names

5 MERODE statecharts  What kind of triggers does MERODE use ?  Message Events  SignalEvent (A SignalEvent represents the receipt of an asynchronous Signal instance)  CallEvent (A CallEvent models the receipt by an object of a message invoking a call of an Operation.)  AnyReceiveEvent (=ALL events)  Change Event (denoted by “when” followed by a Boolean ValueSpecification)  relative TimeEvent (denoted with “after” followed by a TimeExpression)

6 MERODE statecharts  Transition Label Simplification  BusinessEvent [guard] / operation   operation: methodname (= behavioural operation to invoke)   BusinessEvent : documented in OET, assumed to have the same name as the method → ME_borrow  e.g. EV_borrow/ME_borrow   [precondition] : see specification in OET (cannot (yet) be pictured & processed by current MERODE-tools)

7 Sequence Constraints for the Library: FSMs TITLE MEMBER create_title end_title register_member stop_membership acquire, classify, state borrow, initial borrow, return, renew, lose final state return, Methods (Invoked renew state lose, operation, activity) dispose COPY LOAN borrow lose, dispose return, lose acquire classify borrow, return, renew renew

8 Regular expressions Natural Language Finite State Machine (UML) Regular Expr.  Origin: compiler theory B C D a sequence of B.C.D first B, then C and  Alternative way of then D specifying sequence constraints a choice between B B,C,D B, C and D C OR B + C + D (perfect mathematical D equivalence) B a repetition of B (0, 1 or many B* times B)

9 Sequence Constraints for the Library: RE TITLE end_title create_title TITLE = cr_title . (acquire + classify + borrow + renew + return + dispose + lose)* . end_title acquire, classify, MEMBER borrow, MEMBER = register_member renew, register_member stop_membership return, . ( borrow + renew + return + lose)* dispose, . stop_membership lose borrow, LOAN renew, borrow return, lose LOAN = borrow . (renew)* . (return + lose) return, lose COPY COPY = acquire . classify lose, dispose acquire classify renew . (borrow + renew + return)* . (dispose + lose) borrow, renew, return

10 Modelling guidelines  Each class diagram has an assumed default lifecycle  Can be derived from the OET  Needs not to be drawn  drawn automaticall by MERODE-tools (autocomplete functionality)  In case of a non-default life cycle, draw a single finite state machine  Identify the states an object type can be in  E.g. Book is on loan , on shelf , in repair , ...  Identify business events and corresponding methods that cause the transitions from one state to another  E.g. “borrow” causes transition from on shelf to on loan

11 FSMs: default versus user specified  Default FSMs  initial state, default state "exists", 1 final state "ended"  Create method(s) -> transition from initial state to state “exists”  Modify methods -> self-transition in state “exists”  End method(s) -> transitions from state "exists" to state “ended” INVOICE : default FSM PROPOSAL : default FSM

12 FSMs: default versus user specified  Contains user-specified states and transitions from/to specified states (specifies more behaviour constraints) INVOICE : user – specified FSM PROPOSAL : user- specified FSM

1 Chapter 6: Object Behaviour Modelling  Position in the global modelling process  UML notation for Statecharts  MERODE adaptations  Define 1 FSM per object type  Simplified transition labels  Quality checks  Unreachable states (syntactic quality)  Non-determinism (semantic quality)  Structure (pragmatic quality)  Stratification  Parallellism

2 Quality Checks: full set  Basic Checks  All states should be accessible  No non-determinism  FSM should be stratified  Check consistency with OET & EDG  Check correctness of Object Life Cycle vs. BP Layer  Check global behaviour

3 Quality Check: Single FSM Backward inaccessible state Forward inaccessible state

4 Quality Check: Single FSM  Non-determinism:  in a specific state, a single event may trigger transitions to two or more different states

5 Resolving non-determinism using guards  The MERODE-tools can not yet handle guards  Workaround is to use two different events