Here you will get ebooks

1. EDUCATION HOLEPRESENTS
2014
OBJECT ORIENTED SYSTEMS
Unit-II
W W W . E D H O L E . C O M

2. Dynamic Modeling .................................................................................................................. 2
Events and states..................................................................................................................................................2
State Transition Diagrams ................................................................................................................4
Operations .............................................................................................................................. 5
Controlling Operations .....................................................................................................................................5
Nested state diagrams ............................................................................................................ 6
Use Nested State Diagram................................................................................................................................6
a) Aggregation Concurrency .................................................................................................................................7
b) Concurrency within an object...........................................................................................................................7
Advanced dynamic modeling concepts.............................................................................................8
(i) Preparing a Scenario.........................................................................................................................................8
(ii) Interface Formats ............................................................................................................................................9
Identifying Events ............................................................................................................................9
(iv) Building a State Diagram...............................................................................................................................10
Dynamic model sample ......................................................................................................... 10
Dynamic Modeling
Events and states
An event is something which happens outside the thing which is being considered, possibly
requiring some action to be taken. Events may be caused by the arrival of some data, or some
simple stimulus which may be due to human activity or some other part of the system. Event
names normally contain verbs, as in `Bus arrives’ or `Sun goes in’, or `Punch lands on jaw’.
Events may also be caused by the passage of time (e.g. "it's 25ms since the reactor temperature
was checked, so it’s time to do it again"). Events are atomic or instantaneous (at the chosen level
of abstraction; for example, the Battle of Waterloo might be regarded as an event in European
history). That is, an event just happens - there is no beginning or end associated with it. Some
events may convey data as input. This could be shown as a list in brackets after the event name
Actions are what is done by the thing being modeled in response to an event. Imagine yourself as
a boxer in the ring. The other boxer’s punches are events as far as you are concerned, but actions
as far as they are concerned. Your punches are actions from your point of view, but events from

3. your opponent’s viewpoint. So the distinction between the two partly depends on what it is that
is being modeled. Actions are usually summarized by short active verb phrases like `Throw a left
hook’, `Duck’, or `Buy a ticket’. Like events, actions are assumed to be instantaneous.
States
A state is a condition in which the thing being modeled stays for some period of time, during
which it behaves in the same way. Names of states are usually adjectives like `Idle’, `Busy’ or
phrases like `Shopping’ or `Out for the count’. In a state transition diagram, states are
represented by boxes, usually rectangular with rounded corners. A transition is a change of state,
usually caused by some particular event. Thus normally a state corresponds to the period of time
between two significant events. Transitions are shown in state transition diagrams by lines with
arrowheads, leading from the old state to the new. Each transition is labeled with one or more
events, separated by commas, and some actions. Event and action are separated by a or the action
is written under the event. An activity is something which is done by the thing being modeled,
while it is in a particular state. Usually an activity continues as long as the thing is in this state
(which is what makes an activity different from an action). A guard on a transition is some
condition which must be true for the event to cause a transition. The condition may be as
complex as is needed, but might typically be a check that some value is above or below some
limit, or that some data are valid. Guards should be written in square brackets after the event
name. A state diagram is a type of diagram used in computer science and related fields to
describe the behavior of systems. State diagrams require that the system described is composed
of a finite number of states; sometimes, this is indeed the case, while at other times this is a
reasonable abstraction. Many forms of state diagrams exist, which differ slightly and have
different semantics.

4. State Transition Diagrams
These are the most widely used notations for dynamic modeling. As usual, there are several
varieties. In our version, the most general annotation for a transition is:
Any of these may be absent for a particular transition.
Here is a simple example, a STD for a digital watch. There are two buttons on the watch called
the Mode Button and the IncButton; pressing either of these generates an event, which may cause
a transition between two states. There are three states called Display, Set Hours and Set Minutes.
Display is the start state, indicated by the arrow from the black dot. In the Set Hours state, event
Mode Button causes a transition to the Set Minutes state, whereas event IncButton causes the
action Increase Hours to occur (with no state change).

5. State Transition Diagram for a Digital Watch
Each state has an activity, below the horizontal line, after the keyword do. A more complicated
example is given below. Here we use a STD to model the 'life history' of a BOOKING in the
Willow bank case study. The black circle denotes the start state for the diagram. In this case,
there is a Create event which creates an occurrence and leaves it in state New.
Operations
The state diagrams describe the pattern of events and states for a single object class.
Controlling Operations
State diagrams could be of little use if they just described the patterns of the events. A behavior
description of an object must specify what the object does in response to events .Operations
attached to states / transitions are performed in response to corresponding states or events.
“An activity is an operation that takes time to complete.”
• An activity is associated with a state.
• Activities include continuous as well as sequential events.
• A state may control a continuous activity that persists until an event terminates it by
calling a transition from the state.
• Activity within state box indicates that activity starts an entry to the state and stops
on exit.
• In the case of sequential events also it is the same thing.

6. • If an event causes a transition from the state before the activity is complete, it
terminates prematurely.
“An action is an instantaneous operation.”
• it is associated with an event
• Actions can also represent internal control operations, such as setting attributes or
generating other events.
• Notation (‘/’ on transition) for action and the name (or description of the action
following the name of the event that causes it.
Nested state diagrams
Sometimes, we need to model an entity at different levels of abstraction (details) so that an entity
with complex dynamic behaviors can be modeled more appropriately. For example, it is often
difficult to model and analyze an object with many states using a single state chart diagram.
Alternatively, we may draw a high level state chart diagram consisting of composite states and
other diagrams to further elaborate the internal states inside individual composite states. For
each composite state, we can draw its nested states (internal states or substrates) and their
transitions between them. In Figure 4, a composite state (Super state) may hold a state chart
diagram.
Figure 4 – A Generic Nested State Diagram
Use Nested State Diagram

7. State diagrams can also show a super-state for the object. A super-state is used when many
transitions lead to a certain state. Instead of showing all of the transitions from each state to the
redundant state a super-state can be used to show that all of the states inside of the super-state
can transition to the redundant state. This helps make the state diagram easier to read. The
diagram below shows a super-state. Both the Checking and Dispatching states can transition into
the Canceled state, so a transition is shown from a super-state named Active to the state Cancel.
By contrast, the state Dispatching can only transition to the Delivered state, so we show an
arrow only from the Dispatching state to the Delivered state.
Figure 5 – Nested State Diagram for Order Dispatching
Concurrency
a) Aggregation Concurrency
A dynamic model describes a set of concurrent objects. A state of an entire system can’t be
represented by a single state in a single object. It is the product of the states of all objects in it. A
state diagram for an assembly is a collection of state diagram, one for each component. By using
aggregation we can represent concurrency. Aggregate state corresponds to combined state of all
component diagrams.
b) Concurrency within an object
Concurrency within a single composite state of an object is shown by partitioning the composite
state into sub diagrams with dotted lines. Sometimes, it is necessary to model several
independent abstractions of attribute values. For example, an undergraduate student is required
to complete both the final year project and the core subjects before he can graduate. This can be
represented by concurrent states as shown in Figure 6.

8. Figure 6- Concurrent States
Advanced dynamic modeling concepts
Dynamic Modeling shows the time-dependent behavior of the system and the objects in it. Begin
dynamic analysis by looking for events-externally visible stimuli and responses. Summarize
permissible event sequences for each object with a state diagram. Dynamic model is insignificant
for a purely static data repository. It is important in the case of interactive systems. For most
problems, logical correctness depends on the sequences of interactions, not the exact time of
interactions. Real time systems do have specific timing requirements on interactions that must be
considered during analysis.
The following steps are performed in constructing a dynamic model:
(i) Preparing a Scenario
Prepare one or more typical dialogs between user and system to get a feel for expected system
behavior. These scenarios show the major interactions, external display format and information
exchanges. Approach the dynamic model by scenarios, to ensure that important steps are not
overlooked and that the overall flow of the interaction is smooth and correct. Sometimes the
problem statement describes the full interaction sequence, but most of the time you will have to
invent the interaction format.
• The problem statement may specify needed information but leaves open the manner in which
it is obtained.
• In many applications gathering information is a major task or sometimes the only major task.
The dynamic model is critical in such applications.
• First prepare scenarios for “normal “ cases , interactions without any unusual inputs or error
conditions
• Then consider “special “cases, such as omitted input sequences, maximum and minimum
values, and repeated values.
• Then consider user error cases, including invalid values and failures to respond. For many
interactive applications, error handling is the most different part of the implementation. If
possible, allow the user to abort an operation or roll back to a well defined starting point at each
step.

9. • Finally consider various other kinds of interactions that can be overlaid on basic interactions,
such as help requests and status queries.
• A scenario is a sequence of events .An event occurs when information is exchanged between
an object in the system and an outside agent, such as user. The values exchanged are parameters
of the event. The events with no parameters are meaningful and even common. The information
in such event is the fact that it has occurred a pure signal. Anytime information is input to the
system or output from the system.
• For each event identify the actor (system, user or other external agent) that caused the event
and the parameters of the event.
• The screen layout or output format generally doesn’t affect the logic of the interaction or the
values exchanged.
• Doesn’t worry about output formats for the initial dynamic model; describe output formats
during refinement of the model.
(ii) Interface Formats
Most interactions can be separated into two parts:
• application logic
• user interface
Analysis should concentrate first on the information flow and control, rather than the
presentation format. Same program logic can accept input from command lines, files, mouse
buttons, touch panels, physical push buttons, or carefully isolated. Dynamic model captures the
control logic of the application. It is hard to evaluate a user interface without actually testing it
.Often the interface can be mocked up so that users can try it. Application logic can often be
simulated with dummy procedures. Decoupling application logic from user interface allows
“look and feel” of the user interface to be evaluated while the application is under development.
Identifying Events
Examine the scenario to identify all external events. Events include all signals, inputs, decisions,
interrupts, transitions, and actions to or from users or external devices. Internal computation
steps are not events, except for decision points that interact with the external world .Use
scenarios to find normal events, but don’t forget error conditions and unusual events. An action
by an object that transmits information is an event. Most object to object interaction and
operations correspond to events. Some information flows are implicit. You must decide when
differences in quantitative values are important enough to distinguish. The distinction depends
on the application. You may have to construct the state diagram before you can classify all
events; some distinctions between events may have no effect on behavior and can be ignored.
Allocate each type of event to the object classes that send it and receive it. The event is an output
event for the sender and an input event for the receiver. Sometimes an object sends an event to
itself, in which case the event is both an output and input for the same class. Show each scenario
as an event trace – an ordered list of events between different objects assigned to columns in a

10. table. If more than one object of the same class participates in the scenario, assign a separate
column to each object. By scanning a particular column in the trace, you can see the events that
directly affect a particular object. Only these events can appear in the state diagram for the
object. Show the events between groups of classes (such as a module) on an event flow diagram.
This diagram summarizes events between classes, without regard for sequence. Include events
from all scenarios, including error events. The event flow diagram is a dynamic counterpart to an
object diagram. Paths in the object diagram show possible information flows; paths in the event
flow diagram show possible control flows.
(iv) Building a State Diagram
Prepare a state diagram for each object class with non trivial dynamic behavior , showing the
events the object receives and sends .Every scenario or event trace corresponds to path through
the state diagram .Each branch in a control flow is represented by a state with more than one exit
transition. The hardest thing is deciding at which state an alternative path rejoins the existing
diagram. Two paths join at a state if the object “forgets” which the one was taken. In many cases,
it is obvious from your knowledge of the application that two states are identical. Beware of two
paths that appear identical but which can be distinguished under some circumstances. The
judicious use of parameters and conditional transitions can simplify state diagrams considerably
but at the cost of mixing together state information and data. State diagrams with too much data
dependency can be confusing and counterintuitive. Another alternative is to partition a state
diagram into two concurrent sub diagrams, using one sub diagram for the main line and the other
for the distinguishing information. After normal events have been considered, add boundary
cases and special cases. Handling user errors needs more thought and code than normal case.
You are finished with the state diagram of a class when the diagram handles all events that can
affect an object of the class in each of its states. If there are complex interactions with
independent inputs, we use nested state diagrams. Repeat the above process of building state
diagrams for each class of objects. Concentrate on classes with important interactions. Not all
classes need state diagrams. Many objects respond to input events independent of their past
history, or capture all important history as parameters that do not affect control. Such objects
may receive and send events. List the input events for each object and output event sent in
response to each input event, but there will be no further state structure. Eventually you may be
able to write down state diagram directly without preparing event traces.
Dynamic model sample
The dynamic model reflects the changes to objects and their relationships over time,
demonstrating possible control flows through the system. Rumbaing (1991) verifies this:
“The dynamic model shows the time independent behaviour of the system and the objects in it”.
The dynamic model is important for interactive and real time systems. It is vital for applications

11. that depend on collecting information from the user. The current project will not be directly
involved with interactions with the end user, thus the dynamic model is not very important, but it
is important to consider the dynamic model for the simple database application, as this will
indicate the types of control flows expected from the object-relational framework. An event
trace diagram was not constructed as the same information can be derived from an event flow
diagram and the size of the system did not necessitate one. Fig 4.3 illustrates an event flow
diagram for a simple database application. As can seen the user interface tasks and the database
related tasks can be performed in a linear order for this application, but this might not be the case
for another application with different needs. Also the user must wait for the database to return
information before the flow of control returns to the user interface.
This scenario is not acceptable if the database must search large volumes of information, or when
operating across the Internet. Thus it would be beneficial to implement the database related
framework on a separate thread of control. By doing so all databases related tasks would run
independently from the graphical user interface, allowing the user to perform several tasks at
once.