OBJECT-ORIENTED MODELLING

AND DESIGN

CHAPTER- 2
DYNAMIC & FUNCTIONAL MODELING
DYNAMIC MODEL

 Describes the aspects of a system that change over time.

 It specifies and implement control aspects of a system.
 Contains state diagram.
 State diagram is a graph whose nodes are states and whose arcs are state
transitions.

2
DYNAMIC MODELING

 First examine the system at a single moment of time.

 Then examine changes to objects and their relationships
over time.
 Those aspects of a system that are concerned with time and
changes are dynamic model, in contrast with static or object
model.
 Control is the aspect of a system that describes the
sequences of operations that occur in response to external
stimuli without considering what the operation do, what
they operate on, and how they are implemented.
3
CONCEPTS

 Events – represent external stimuli

 States – values of objects
 State diagram

4
EVENTS AND STATES

 The attribute values and links held by an object are called its state.
 An individual stimulus from one object to another is an event.
 Response to an event depends on the state of the object receiving it.
 Response can include a change of state or the sending of another event
to the original sender or to a third object.
 The pattern of events , states and state transitions for a given class can
be abstracted and represented as a state diagram.
 The dynamic model consists of multiple state diagrams , one state
diagram for each class with important dynamic behavior, and shows
pattern of activity for an entire system.
5
EVENTS

 It is something that happens at a point in time

 One event may logically precede or follow another or
the two events may be unrelated.
 The two events are casually related.
 The two events are casually unrelated are said to be
concurrent i.e. they have no effect on each other.
 In modeling a system we do not establish an ordering
between concurrent events because they can occur at
any order.
6
 An event is a one-way transmission of information
from one object to another.
 In real world, all objects exist concurrently.
 An object sending an event to another object may
expect a reply but the reply is a separate event
under the control of the second object which may
or may not choose to send it.

7
 Every event is a unique occurrence, but we group them into
event classes and give each event class a name to indicate
common structure and behavior.
 This structure is hierarchical as class structure.
 E.g. flight 123 departs from Delhi and flight 321 departs from
Rome are instances of event class airplane flight departs
having attributes airline,flight no, city.
 The time at which an event occurs is an implicit attribute of
all events.
8
 An event conveys information from one object to
another.
 Some classes of events may be simply signals that
something has occurred while other convey data values
i.e. attributes.
 Showing attributes is optional.
 Events include error conditions as well as normal
occurrences.

9
Fig.1 Event classes and attributes
10
SCENARIOS AND EVENT TRACES

 A scenario is a sequence of events that occurs

during one particular execution of a system.
 The scope of a scenario can vary; it may include all
events in the system or it may include only those
events generated by certain objects in the system.
 It can be the historical record of executing a system
or a thought experiment of executing a proposed
system.
11
 12

Fig. Scenario for phone call

 Each event transmits information from one object to another.
 The next step after writing scenario is to identify the sender and
receiver objects of each event.
 The sequence of events and the objects exchanging events are
shown in event trace diagram.
 This diagram shows each object as a vertical line and each event
as a horizontal arrow from the sender to receiver objects.
 Time increases from top to bottom.
 Sequences of events are shown, not their exact timing.
13
EVENT TRACE FOR PHONE CALL
STATES

 It is an abstraction of the attribute values and links of an object.

 Set of values are grouped together into a state according to
properties that affect the gross behavior of the object e.g. the
state of bank is either solvent or insolvent whether its assets are
greater than liabilities.
 A state specifies the response of the object to input events.
 Response is same for all values within the same state and may be
different for values in different states.
 Response of an object to an event may include an action or
change of states by the object.

15
 A state has duration; it occupies interval of time.
 A state is often associated with either continuous activity or activity that
takes time to complete.
 An event separates two states and a state separates two events.
 In defining states we ignore those attributes that do not affect the behavior
of the objects.e.g balance is only attribute that causes state change. So we
can ignore the acc_ID and acc_type attributes of Account object.
 Both events and states depends on the level of abstraction used. E.g for bank
customer credit or debit is single event; but for bank system it is sequence
of many operations.
16
STATE DIAGRAM

 It relates events and states.

 When an event is received, the next state depends on the current state
as well as the event; a change of state caused by an event is called a
transition.
 State diagram is a graph whose nodes are states and whose directed arcs
are transitions labeled by event names.
 The state diagram specifies the state sequence caused by an event
sequence.
 Two categories of events: one that cause state transitions and second
that doesn’t cause state transitions.

17
 State diagrams can represent one-shot life cycles or
continuous loops.
 Continuous state diagrams do not have any initial states
and final states. E.g. state diagram for phone line.
 One-shot state diagrams represent objects with finite lives
and have initial and final states. The initial state is entered
on creation of an object; entering the final state implies the
destruction of object.

19
ONE-SHOT STATE DIAGRAM
 The dynamic model is collection of state diagrams
that interact with each other via shared events.

21
CONDITIONS

 A condition is a Boolean function of object values.

E.g.“the temperature is below freezing”
 A condition is valid over an interval of time. E.g.
“the temperature was below freezing from 15
oct.,2013 to 15 nov.,2013”
 A state can be defined in terms of a condition;
conversely being in state is a condition.
22
 Conditions can be used as guards on transitions.
 A guarded transition fires when its event occurs ,
but only if guard condition is true.
 When Ram goes out in morning( event), if the
temperature is below freezing( condition), then he
puts on his gloves (next state).
 Notation is [condition]

23
OPERATIONS

 Operations attached to states or transitions are performed in response

to the corresponding states or events.
 An activity is an operation that takes time to complete.
 An activity is associated with a state.
 Activities include continuous operations such as displaying picture on
TV screen as well as sequential operations that terminate by themselves
after an interval of time, such as closing a valve or performing a
computation.
 A state can control a continuous activity as well as sequential activity.
 Notation “do:A” within a state box indicates that activity A starts on
entry to the state and stops on exit.

25
 An action is an instantaneous operation.
 An action is associated with an event.
 An action represents an operation whose duration is insignificant
compared to the state diagram e.g. disconnect phone line might be an
action in response to an on_hook event for phone line.
 Actions can also represent internal control operations such as setting
attributes or generating other events.
 The notation for an action is (“/”) and the name of action, following the
name of the event that causes it.

26
ACTION FOR POP-UP MENU
SUMMARY OF NOTATION FOR
UNSTRUCTURED STATE DIAGRAM

28
NESTED STATE DIAGRAM

 State diagram can be structured to permit concise description of

complex systems.
 Generalization
 To expand nested activity
 Describe the activity at high level
 Expand the activity at a lower level by adding details.
 Aggregation
 Allows us to break the state into many orthogonal components having
limited interaction among them
 Aggregation is equivalent to concurrency of states.

30
PROBLEMS WITH FLAT STATE DIAGRAMS

 Problems of state diagrams

 Lack expressive power
 Impractical for large problems
 These problems are particularly for flat, unstructured state diagrams
 Consider an object with n independent Boolean attributes that affect control.
 Single flat diagram requires 2n states.
 If we partition state into n independent state machines , state diagram requires only
2n states.
 All complex systems contain a large amount of redundancy that can be used to
simplify state diagram , provided appropriate structuring mechanisms are available.

31
NESTING STATE DIAGRAMS

 An activity in state can be expanded as a lower level

state diagrams , each state represent one step of
the activity.
 Nested activities are one –shot state diagrams with
input and output transitions, similar to subroutines.

32
STATE GENERALIZATION

 A nested state diagram is a form of generalization on states.

 Generalization is “or-relation”.
 States may have sub states that inherit the transitions of their super states just as
classes have subclasses that inherit the attributes and operations of their super
classes.
 An object in a state in the high level diagram must be in exactly one state in the
nested diagram
 The transitions of superstate are inherited by each of its substates

36
EVENT GENERALIZATION

 Events can be organized into a generalization hierarchy with inheritance

of event attribute
 Providing an event hierarchy permits different level of abstraction to be
used at different places in a model
EVENT GENERALIZATION
CONCURRENCY: AGGREGATION
CONCURRENCY

 A state diagram for assembly is collection of state diagrams , one for each
component
 Aggregation implies concurrency
 The aggregate state corresponds to the combined state of all the component
diagrams
 Aggregation is the “ and-relationship”
AGGREGATION AND ITS CONCURRENT
STATE DIAGRAM
AGGREGATION AND ITS CONCURRENT
STATE DIAGRAM
CONCURRENCY WITHIN AN OBJECT

 It arises when the object can be partitioned into subsets of attributes or links,
each of which has its own subdiagram
 The state of the object comprises the one state from each subdiagram
 The subdiagrams need not be independent; same event can cause transition in
more than one subdiagram
 Notation
o Composite state is partitioned into subdiagrams with dotted line
o Name of the overall composite state is written in separate region of the box,
separated by solid line from concurrent state diagrams
CONCURRENCY WITHIN AN OBJECT
ADVANCED DYNAMIC MODELLING
CONCEPTS

 Entry and Exit actions

 Internal actions
 Automatic transitions
 Sending events
 Synchronization of concurrent activities
ENTRY AND EXIT ACTIONS

 Actions can be associated with entering or exiting a state

 The entry actions are executed from outside in and the exit actions from inside out.
 An entry action is shown inside the state box following the keyword entry and a
“/”character.
 An exit action is shown inside the state box following the keyword exit and a
“/”character.
 If multiple operations are specified on a state , they are performed in the following
order
1. Actions on incoming transition
2. Entry actions
3. do activities
4. Exit actions
5. Actions on outgoing transition
 if do activity is interrupted , the exit action is nevertheless performed.
ENTRY AND EXIT ACTIONS
ENTRY AND EXIT ACTIONS
INTERNAL ACTIONS

 An event can cause an action to be performed without causing a state change

 The event name is written inside state box followed by “/” and name of action
 When such event occurs, its action is executed but not the entry or exit actions
for the state.
AUTOMATIC TRANSITION

 A state performs a sequential activity.

 When it is over, the transition to another fires.
 An arrow without an event name indicates an automatic transition that fires
when the activity associates with the source state is completed.
 If there is no activity, the unlabeled transitions fires as soon as the state is
entered. Such transitions are called as “lambda‟ transitions.
 If state has one or more automatic transitions, but none of the guard conditions
are satisfied then the state remains active until one of the conditions is satisfied
or until an event causes another transition to fire.
SENDING EVENTS

 An object can perform action of sending an event to another object. A system of

objects interacts by events.
 The action “send E(attributes)” sends event E with the given attributes to the
object or objects that receive it.
 An event can be directed to a single or a group of objects. Any and all objects
can accept it concurrently.
 If a state can accept events from more than one object, the order in which
concurrent events are received may affect final state. This is called a race
condition. Unwanted race conditions should be avoided.
 When an object interacts with an external object, such as person or device,
sending an event is often indistinguishable from an action.
SYNCHRONIZATION OF CONCURRENT
ACTIVITIES

 Sometimes an object must perform two or more activities concurrently.

 The internal steps of the activities are not synchronized , but both activities must
be completed before the object can progress to its next state.
 The target state occurs after both events happen in any order.