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

1.

with the OET

2.

with the EDG

4. Practical Modelling tips

Chapter 6: Object Behaviour Modelling

• Position in the global modelling process
• UML notation for Statecharts
• MERODE simplifications
• Basic Quality checks
• Parallellism

2

• 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

Overview of MERODE

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

4

Picture from https://www.maxpixel.net/Art-Colourful-Gears-Creativity-Cogs-Colorful-1866468 (CC0 license)

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.

5

picture from https://www.maxpixel.net/Machine-Machinery-Close-up-Gears-Cogs-Mechanical-1853057 (CC0 license)

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

6

Photo by carnifex82, Clockwork in the belltower St. Dionysius church, Duisburg - Walsum, Germany (CC License)

Chapter 6: Object Behaviour Modelling

• Position in the global modelling process
• UML notation for Statecharts
• MERODE simplifications
• Basic Quality checks
• Parallellism

1

UML statecharts

• UML notation for statecharts
• 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).

2

trigger* [guard condition] / operation

UML Statecharts

• State : simple, composite, submachine
• Rather complex semantics for entry, internal transitions, exit

3

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

4

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)

5

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

1

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

2

MERODE statecharts

• MERODE notation for statecharts
• 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

[Name]

trigger* [guard condition] / operation

[Name]

MERODE statecharts

• Transitions
• 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

4

trigger* [guard condition] / operation

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)

5

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
• e.g. EV_borrow/ME_borrow

→ ME_borrow

•  [precondition] : see specification in OET

(cannot (yet) be pictured & processed by current MERODE-tools)

6

MEMBER register_member stop_membership borrow, return, lose renew TITLE create_title end_title acquire, classify, borrow, renew, return, lose, dispose LOAN borrow return, lose renew COPY acquire lose, dispose borrow, return, renew classify initial state final state state Methods (Invoked

• peration, activity)

Sequence Constraints for the Library: FSMs

7

Regular expressions

• Origin: compiler theory
• Alternative way of

specifying sequence constraints

(perfect mathematical equivalence)

8

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

Sequence Constraints for the Library: RE

TITLE = cr_title . (acquire + classify + borrow + renew + return + dispose + lose)* . end_title MEMBER = register_member . ( borrow + renew + return + lose)* . stop_membership LOAN = borrow . (renew)* . (return + lose) COPY = acquire . classify . (borrow + renew + return)* . (dispose + lose)

9

TITLE create_title end_title acquire, classify, borrow, renew, return, dispose, lose MEMBER register_member stop_membership borrow, renew, return, lose LOAN borrow return, lose renew COPY acquire lose, dispose borrow, renew, return classify

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

10

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”

11

INVOICE : default FSM PROPOSAL : default FSM

FSMs: default versus user specified

• Contains user-specified states and transitions from/to specified states

(specifies more behaviour constraints)

12

INVOICE : user – specified FSM PROPOSAL : user- specified FSM

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

1

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

2

Quality Check: Single FSM

3

Backward inaccessible state Forward inaccessible state

Quality Check: Single FSM

• Non-determinism:
• in a specific state, a single event may trigger transitions to two or more different states

4

Resolving non-determinism using guards

• The MERODE-tools can not yet handle guards
• Workaround is to use two different events

5

Stratification of FSMs

• Organise the states and

transitions along two axes:

• axis 1 = progress towards the

end state

• axis 2 = loops

6

Stratification of FSMs

7

Chapter 6: Object Behaviour Modelling

• Position in the global modelling process
• UML notation for Statecharts
• MERODE adaptations
• Defining 1 FSM per object type
• Default assumptions for transitions
• Quality checks
• Unreachable states (syntactic quality)
• non-determinism (semantic quality)
• Structure (pragmatic quality)
• Stratification
• Parallellism

1

Parallelism in UML

• Fork & Join transitions

2

Parallelism in UML

• orthogonal state with regions

3

Parallelism in UML

• Useful to capture indepent sets of behaviour
• e.g. a movie star's private life and work life

4

single married marry divorce cr_Moviestar end_MovieStar unemployed employed hire fire

Parallelism with multiple FSMs

• Multiple FSMs will synchronise on

transitions triggered by the same events

5

Parallellism with a default FSM

• Calculating the parallel composition

between a default and a user-specfied FSM, will result in adding all non-used events as self-transitions in each state

6

Parallellism in MERODE

• You can define as many FSMs per object type as needed.
• You need to calculate one final FSM as the parallel combination of these FSMs

to define the final behaviour of the object type (and select it for code generation)

• E.g for the Movie Star:
• Define an FSM for "Private Life"
• Define an FSM for "Work Life"
• Calculate the parallel composition

& select it for code generation

7