Object Oriented Analysis and Design UNIT-4 Learning Material

Object oriented Analysis And Design UNIT-Ⅳ
OBJECT ORIENTED ANALYSIS AND DESIGN
UNIT-4
Learning Material
Department of Information Technology GEC III Year – ⅡSEM Page 1

Sem
Unit – 4
Objectives:
➢ To gain the knowledge of identifying different interactions, use cases and activities in the
application.
➢ To design different use case, activity and interaction diagrams
Syllabus: Behavioral Modeling

Interactions, Interaction Diagrams, Use Cases, Use Case Diagrams, Activity Diagrams
Outcomes:
Students will be able to
➢ Identify interactions and use cases in the application.
➢ Illustrate interaction diagrams and use case diagrams for different cases.
➢ Illustrate activity diagrams for different cases.

Sem
LEARNING MATERIAL
INTERACTIONS:
An interaction is a behavior that comprises a set of messages exchanged among a set of objects
within a context to accomplish a purpose.
A message is a specification of a communication between objects that conveys information with the
expectation that activity will ensue
➢ We use interactions to model the flow of control within an operation, a class, a component,
a use case, or the system as a whole.
➢ Using interaction diagrams, we can reason about these flows in two ways.
o First, we can focus on how messages are dispatched across time.
o Second, we can focus on the structural relationships among the objects in an
interaction and then consider how messages are passed within the context of that
structure.
The UML provides a graphical representation of messages, as shown below.
Figure: Messages, Links, and Sequencing We find

an interactions
➢ Wherever objects are linked to one another.
➢ In the collaboration of objects that exist in the context of the system or subsystem.
➢ In the context of an operation.
➢ In the context of a class. (We use interactions to visualize, specify, construct, and document
the semantics of a class)
An interaction may also be found in the representation of a component, node, or use case, each of
which, in the UML, is really a kind of classifier.
In the context of a use case, an interaction represents a scenario that, in turn, represents one thread
through the action of the use case.
Objects and Roles

The objects that participate in an interaction are either concrete things or prototypical things.

Sem
As a concrete thing, an object represents something in the real world. For example, p, an instance of
the class Person, might denote a particular human. Alternately, as a prototypical thing, p might
represent any instance of Person.
Links and Connectors

A link is a semantic connection among objects. A link is
an instance of an association.
The following figure shows
➢ wherever a class has an association to another class, there may be a link between the
instances of the two classes;
➢ Wherever there is a link between two objects, one object can send a message to the other
object.
Figure: Links, Associations and Connectors

We can adorn the appropriate end of the link with any of the following standard stereotypes:
association Specifies that the corresponding object is visible by association
Specifies that the corresponding object is visible because it is
self
the dispatcher of the operation

Sem
Specifies that the corresponding object is visible because it is in

global
an enclosing scope
Specifies that the corresponding object is visible because it is in
local
a local scope
Specifies that the corresponding object is visible because it is a
parameter
parameter
MESSAGES
➢ A message is the specification of a communication among objects that conveys
information with the expectation that activity will ensue.
➢ The receipt of a message instance may be considered an instance of an event.
➢ In the UML, we can model several kinds of actions.
Invokes an operation on an object;
Call an object may send a message to itself, resulting in the local invocation of
an operation
Return Returns a value to the caller
Send Sends a signal to an object
Create Creates an object
Destroys an object;
Destroy
an object may commit suicide by destroying itself
The UML provides a visual distinction among these kinds of messages, as shown below
Fig: Messages

Sem
➢ Messages can also correspond to the sending of signals
➢ A signal is an object value communicated to a target object asynchronously
SEQUENCING
When an object passes a message to another object, the receiving object might in turn send a
message to another object, which might send a message to yet a different object, and so on. This
stream of messages forms a sequence.
➢ Each process and thread within a system defines a distinct flow of control, and within each
flow, messages are ordered in sequence by time.
➢ A communication diagram shows message flow between roles within a collaboration
➢ Messages flow along connections of the collaborations as shown below
Fig: Procedural Sequence

➢ The following figure specify a flat flow of control, rendered using a stick arrowhead, to
model the nonprocedural progression of control from step to step.
Fig: Flat Sequence

Creation, Modification, and Destruction
➢ The relationships among objects may come and go.
➢ To specify if an object or link enters and/or leaves during an interaction, we can attach one
of the following constraints to the element

Sem
Specifies that the instance or link is created during execution

new
of the enclosing interaction
Specifies that the instance or link is destroyed prior to
destroyed
completion of execution of the enclosing interaction
Specifies that the instance or link is created during execution of the
transient enclosing interaction but is destroyed before completion
of execution
Note: The modification of an object in a sequence diagram is represented by showing the state or
values on the lifeline
Representation
➢ When we model an interaction, we typically include both objects (each one playing a
specific role) and messages (each one representing the communication between objects,
with some resulting action).
➢ We can visualize those objects and messages involved in an interaction in two ways:
o by emphasizing the time ordering of its messages (sequence diagram)
o by emphasizing the structural organization of the objects that send and receive
messages (collaboration diagram)
Note: Sequence diagrams and collaboration diagrams are largely isomorphic.
Common Modeling Techniques:

Modeling a Flow of Control
The most common purpose for which we use interactions is to model the flow of control that
characterizes the behavior of a system as a whole, including use cases, patterns, mechanisms, and
frameworks, or the behavior of a class or an individual operation.
To model a flow of control:
➢ Set the context for the interaction, whether it is the system as a whole, a class, or an
individual operation.
➢ Set the stage for the interaction by identifying which objects play a role;
➢ Set their initial properties, including their attribute values, state, and role.
➢ If our model emphasizes the structural organization of these objects, identify the links that
connect them, relevant to the paths of communication that take place in this interaction.
➢ In time order, specify the messages that pass from object to object.
➢ To convey the necessary detail of this interaction, adorn each object at very moment in time
with its state and role.

Sem
➢ The following figure shows a set of objects that interact in the context of publish and
subscribe mechanism.
Fig: Flow of control by time

➢ The following figure is semantically equivalent to the previous one, but it is drawn as a
collaboration diagram, which emphasizes the structural organization of the objects.
Fig: Flow of Control by Organization
INTERACTION DIAGRAMS
➢ An interaction diagram shows an interaction, consisting of a set of objects and their

relationships, including the messages that may be dispatched among them.
➢ We use interaction diagrams to model the dynamic aspects of a system.
➢ Sequence diagrams and collaboration diagrams are collectively called Interaction Diagrams.

Sem
o A sequence diagram is an interaction diagram that emphasizes the time ordering of
messages
o A collaboration diagram is an interaction diagram that emphasizes the structural
organization of the objects that send and receive messages.
➢ They are also used for constructing executable systems through forward and reverse
engineering.
➢ Sequence diagrams and collaboration diagrams are semantically equivalent
➢ We can convert one to the other without loss of information.
Fig: Interaction Diagrams

COMMON PROPERTIES
➢ It shares the same common properties as do all other diagrams - a name and graphical
contents that are a projection into a model

Sem
CONTENTS
➢ Interaction diagrams commonly contain
o Objects
o Links
o Messages
SEQUENCE DIAGRAMS
➢ A sequence diagram emphasizes the time ordering of messages
➢ Typically, we place the object that initiates the interaction at the left, and increasingly more
subordinate objects to the right.
➢ Next, we place the messages that these objects send and receive along the Y axis, in order of
increasing time from top to bottom.
Fig: Sequence Diagram
Structured Control in Sequence Diagrams

➢ A sequence of messages is fine for showing a single, linear sequence, but often we need
to show conditionals and loops.
➢ This kind of high-level control can be shown using structured control operators in
sequence diagrams.
➢ A control operator is shown as a rectangular region within the sequence diagram.
➢ It has a tag a text label inside a small pentagon in the upper left corner to tell what kind of a
control operator it is

Sem
Optional execution
➢ The tag is opt.
➢ The body of the control operator is executed if a guard condition is true when the operator is
entered.
➢ The guard condition is a Boolean expression that may appear in square brackets at the top of
any one lifeline within the body and may reference attributes of that object.
Conditional execution
➢ The tag is alt.
➢ The body of the control operator is divided into multiple subregions by horizontal dashed
lines.
➢ Each subregion represents one branch of a conditional. Each subregion has a guard
condition.
➢ If the guard condition for a subregion is true, the subregion is executed.
Parallel execution
➢ The tag is par.
➢ The body of the control operator is divided into multiple subregions by horizontal dashed
lines.
➢ Each subregion represents a parallel (concurrent) computation.
➢ When the control operator is entered, all of the subregions execute concurrently.
➢ The execution of the messages in each subregion is sequential, but the relative order of
messages in parallel subregions is completely arbitrary.
Loop (iterative) execution
➢ The tag is loop.
➢ A guard condition appears at the top of one lifeline within the body.
➢ The body of the loop is executed repeatedly as long as the guard condition is true before
each iteration.
➢ When the guard condition is false at the top of the body, control passes out of the control
operator.
The following figure shows a simplified example that illustrates some control operators.
➢ The user initiates the sequence.
➢ The first operator is a loop operator.
o The numbers in parentheses (1,3) indicate the minimum and
maximum number of times the loop body must be executed
o The loop continues as long as the password is incorrect.
o After three tries, the loop terminates in any case
➢ The next operator is an optional operator.

Sem
o The optional body is executed if the password is valid;
o Otherwise the rest of the sequence diagram is skipped.
➢ The optional body contains a parallel operator.
o The parallel operator has two subregions:
▪ one allows the user to enter an account
▪ The other allows the user to enter an amount.
o Because they are parallel, there is no required order for making the two entries, they
can occur in either order.
Fig: Structured Control Operators

Sem
Nested Activity Diagrams
➢ Activity diagrams that are too large can be difficult to understand.
➢ Structured sections of an activity can be organized into a subordinate activity, especially if
the subordinate activity is used more than once within the main activity
➢ The main activity and the subordinate activities are shown on separate diagrams.
➢ Within the main activity diagram:
o a use of a subordinate activity is shown by a rectangle with the tag ref in its upper
left corner
o the name of the subordinate behavior is shown in the box.
Fig: Nested activity diagram
Collaboration Diagrams (or Communication Diagram)

➢ collaboration diagram emphasizes the organization of the objects that participate in an
interaction
➢ We form a collaboration diagram by first placing the objects that participate in the
interaction as the vertices in a graph.
➢ Next, we render the links that connect these objects as the arcs of this graph.
➢ Finally, we adorn these links with the messages that objects send and receive

Sem
Fig: Collaboration Diagram

➢ Collaboration diagrams have two features that distinguish them from sequence
diagrams:
o First, there is the path. To indicate how one object is linked to another, we can attach
a path stereotype to the far end of a link (such as «local», indicating that the
designated object is local to the sender).
o Second, there is the sequence number. To indicate the time order of a message, we
prefix the message with a number (starting with the message numbered 1 ),
increasing monotonically for each new message in the flow of control
Semantic Equivalence
➢ sequence diagrams and collaboration diagrams are semantically equivalent.
➢ As a result, we can take a diagram in one form and convert it to the other without any loss
of information
Common Uses
➢ We use interaction diagrams to model the dynamic aspects of a system
➢ When we model the dynamic aspects of a system, we typically use interaction diagrams in
two ways.
➢ To model flows of control by time ordering
o Modeling a flow of control by time ordering emphasizes the passing of messages as
they unfold over time,
o This is particularly useful way to visualize dynamic behavior in the context of a use
case scenario

Sem
➢ To model flows of control by organization
o Modeling a flow of control by organization emphasizes the structural relationships
among the instances in the interaction, along which messages may be passed.
Common Modeling Techniques
1. Modeling Flows of Control by Time Ordering
To model a flow of control by time ordering,
➢ Set the context for the interaction, whether it is a system, subsystem, operation, or class, or
one scenario of a use case or collaboration.
➢ Set the stage for the interaction by identifying which objects play a role in the interaction.
➢ Set the lifeline for each object. In most cases, objects will persist through the entire
interaction.
➢ Starting with the message that initiates this interaction, lay out each subsequent message
from top to bottom between the lifelines, showing each message's properties (such as its
parameters), as necessary to explain the semantics of the interaction.
➢ If we need to visualize the nesting of messages or the points in time when actual
computation is taking place, adorn each object's lifeline with its focus of control.
➢ If we need to specify time or space constraints, adorn each message with a timing mark and
attach suitable time or space constraints.
➢ If we need to specify this flow of control more formally, attach pre- and post-conditions to
each message.
Fig: Modeling Flows of Control by Time Ordering

Sem
2. Modeling Flows of Control by Organization
To model a flow of control by organization
➢ Set the context for the interaction, whether it is a system, subsystem, operation, or class, or
one scenario of a use case or collaboration.
➢ Set the stage for the interaction by identifying which objects play a role in the interaction.
➢ Set the initial properties of each of these objects
➢ Specify the links among these objects, along which messages may pass.
o Lay out the association links first; these are the most important ones, because they
represent structural connections.
o Lay out other links next, and adorn them with suitable path stereotypes (such as
global and local) to explicitly specify how these objects are related to one another.
➢ Starting with the message that initiates this interaction, attach each subsequent message to
the appropriate link, setting its sequence number, as appropriate.
➢ If we need to specify time or space constraints, adorn each message with a timing mark and
attach suitable time or space constraints.
➢ If we need to specify this flow of control more formally, attach pre- and post-conditions to
each message.
Fig: Modeling Flows of Control by Organization

3. Forward and Reverse Engineering
➢ Forward engineering (the creation of code from a model) is possible for both sequence and
collaboration diagrams, especially if the context of the diagram is an operation

Sem
➢ Reverse engineering (the creation of a model from code) is also possible for both sequence
and collaboration diagrams, especially if the context of the code is the body of an operation.
USE CASES
➢ A use case represents a functional requirement of our system as a whole
➢ A use case describes a set of sequences, in which each sequence represents the interaction of
the things outside the system (its actors) with the system itself (and its key abstractions)
➢ A use case involves the interaction of actors and the system.
➢ An actor represents a coherent set of roles that users of use cases play when interacting with
these use cases.
➢ Actors can be human or they can be automated systems.
Fig: Actors and Use Cases

➢ A use case is a description of a set of sequences of actions, including variants that a system
performs to yield an observable result of value to an actor.
➢ Graphically, a use case is rendered as an ellipse
➢ Every use case must have a name that distinguishes it from other use cases. A name is a
textual string.
➢ That name alone is known as a simple name; a path name is the use case name prefixed by
the name of the package in which that use case lives.
Fig: Simple and Path Names

➢ An actor represents a coherent set of roles that users of use cases play when interacting with
these use cases.
➢ Typically, an actor represents a role that a human, a hardware device, or even another
system plays with a system
➢ actors are rendered as stick figures.

Sem
➢ We can define general kinds of actors (such as Customer ) and specialize them (such as
CommercialCustomer ) using generalization relationships.
Use Cases and Flow of Events

➢ A use case describes what a system (or a subsystem, class, or interface) does but it does not
specify how it does it.
➢ When we model, it's important that we keep clear the separation of concerns between this
outside and inside view.
➢ We can specify the behavior of a use case by describing a flow of events in text clearly
enough for an outsider to understand it easily.
➢ For example, in the context of an ATM system, we might describe the use case ValidateUser
in the following way:
o Main flow of events:
▪ The use case starts when the system prompts the Customer for a PIN number.
▪ The Customer can now enter a PIN number via the keypad.
▪ The Customer commits the entry by pressing the Enter button.
▪ The system then checks this PIN number to see if it is valid.
▪ If the PIN number is valid, the system acknowledges the entry, thus ending
the use case.
o Exceptional flow of events:
▪ The Customer can cancel a transaction at any time by pressing the Cancel
button, thus restarting the use case.
▪ No changes are made to the Customer's account.
▪ The Customer can clear a PIN number anytime before
committing it and reenter a new PIN number.
▪ If the Customer enters an invalid PIN number, the use case restarts.
▪ If this happens three times in a row, the system cancels the entire transaction,
preventing the Customer from interacting with the ATM for 60 seconds.
Use Cases and Scenarios

Sem
➢ we use one sequence diagram to specify a use case's main flow, and variations of that
diagram to specify a use case's exceptional flows.
Use Cases and Collaborations
➢ A use case captures the intended behavior of the system (or subsystem, class, or interface)
we are developing, without having to specify how that behavior is implemented.
➢ We can explicitly specify the realization of a use case by a collaboration.
Organizing Use Cases

➢ We can organize use cases by grouping them in packages in the same manner in which we
can organize classes.
➢ We can also organize use cases by specifying generalization, include, and extend
relationships among them
➢ Generalization among use cases is just like generalization among classes.
➢ This means child use case inherits the behavior and meaning of the parent use case
➢ An include relationship between use cases means that the base use case explicitly
incorporates the behavior of another use case at a location specified in the base
➢ An extend relationship between use cases means that the base use case implicitly
incorporates the behavior of another use case at a location specified indirectly by the
extending use case.
Fig: Generalization, Include, and Extend

1. Modeling the Behavior of an Element

Sem
To model the behavior of an element:
➢ Identify the actors that interact with the element. Candidate actors include groups that
require certain behavior to perform their tasks or that are needed directly or indirectly to
perform the element's functions.
➢ Organize actors by identifying general and more specialized roles.
➢ For each actor, consider the primary ways in which that actor interacts with the element.
Consider also interactions that change the state of the element or its environment or that
involve a response to some event.
➢ Consider also the exceptional ways in which each actor interacts with the element.
➢ Organize these behaviors as use cases, applying include and extend relationships to factor
common behavior and distinguish exceptional behavior.
Fig: Modeling the Behaviour of an Element
USE CASE DIAGRAMS

➢ Use case diagrams are one of the five diagrams in the UML for modeling the dynamic
aspects of systems

Sem
➢ We apply use case diagrams to model the use case view of a system
➢ We apply use case diagrams to visualize the behavior of a system, subsystem, or class so
that users can comprehend how to use that element, and so that developers can implement
that element.
Fig: A Use Case Diagram
Common Properties
➢ It has common properties as do all other diagrams: a name and graphical contents that are a
projection into a model
Contents
➢ Use case diagrams commonly contain
o Use cases
o Actors
o Dependency, generalization, and association relationships
Common Uses
➢ When we model the static use case view of a system, we'll typically apply use case diagrams
in one of two ways.
➢ To model the context of a system.
o It involves drawing a line around the whole system and asserting which actors lie
outside the system and interact with it
➢ To model the requirements of a system
o It involves specifying what that system should do (from a point of view of outside
the system), independent of how that system should do it.

1.Modeling the Context of a System To
model the context of a system:

Sem
➢ Identify the actors that surround the system by considering
o which groups require help from the system to perform their tasks
o which groups are needed to execute the system's functions
o which groups interact with external hardware or other software systems
o which groups perform secondary functions for administration and maintenance.
➢ Organize actors that are similar to one another in a
generalization/specialization hierarchy.
➢ Where it aids understandability, provide a stereotype for each such actor.
➢ Populate a use case diagram with these actors and specify the paths of communication from
each actor to the system's use cases.
Fig: Modeling the Context of a System

2.Modeling the Requirements of a System
To model the requirements of a system,
➢ Establish the context of the system by identifying the actors that surround it.
➢ For each actor, consider the behavior that each expects or requires the system to provide.
➢ Name these common behaviors as use cases.
➢ Factor common behavior into new use cases that are used by others; factor variant behavior
into new use cases that extend more main line flows.
➢ Model these use cases, actors, and their relationships in a use case diagram.
➢ Adorn these use cases with notes that assert nonfunctional requirements; we may have to
attach some of these to the whole system.

Sem
Fig: Modeling the Requirements of a System

3.Forward and Reverse Engineering
To forward engineer a use case diagram:
➢ For each use case in the diagram, identify its flow of events and its exceptional flow of
events.
➢ Depending on how deeply we choose to test, generate a test script for each flow, using the
flow's preconditions as the test's initial state and its postconditions as its success criteria.
➢ As necessary, generate test scaffolding to represent each actor that interacts with the use
case.
➢ Actors that push information to the element or are acted on by the element may either be
simulated or substituted by its real-world equivalent.
➢ Use tools to run these tests each time we release the element to which the use case diagram
applies.
To reverse engineer a use case diagram,

➢ Identify each actor that interacts with the system.
➢ For each actor, consider the manner in which that actor interacts with the system, changes
the state of the system or its environment, or responds to some event.
➢ Trace the flow of events in the executable system relative to each actor. Start with primary
flows and only later consider alternative paths.
➢ Cluster related flows by declaring a corresponding use case. Consider modeling variants
using extend relationships, and consider modeling common flows by applying include
relationships.

Sem
➢ Render these actors and use cases in a use case diagram, and establish their relationships.
ACTIVITY DIAGRAMS
➢ Activity diagrams model the dynamic aspects of systems
➢ An activity diagram is essentially a flowchart, showing flow of control from activity to
activity.
➢ Activity diagrams are not only important for modeling the dynamic aspects of a system, but
also for constructing executable systems through forward and reverse engineering.
Fig: Activity Diagrams

Common Properties
➢ It has common properties as do all other diagrams: a name and graphical contents that are a
projection into a model
Contents
Activity diagrams commonly contain
➢ Activity states and action states
➢ Transitions
➢ Objects
Action States and Activity States
➢ action states are states of the system, each representing the execution of an action.
➢ Action states can't be decomposed.

Sem
➢ Action states are atomic, meaning that events may occur, but the work of the action state
is not interrupted.
Fig: Action States

➢ an activity state as a composite, whose flow of control is made up of other activity states
and action states
➢ activity states can be further decomposed, their activity being represented by other activity
diagrams
➢ An action state is an activity state that cannot be further decomposed.
Fig: Activity States

Transitions
➢ Triggerless transitions may have guard conditions, meaning that such a transition will
fire only if that condition is met
Fig: Triggerless Transitions
Branching
➢ Branches are a notational convenience, semantically equivalent to multiple transitions with
guards

Sem
➢ A branch may have one incoming transition and two or more outgoing ones.
Fig: Branching
Forking and Joining
➢ We use a synchronization bar to specify the forking and joining of these parallel flows of
control.
➢ A synchronization bar is rendered as a thick horizontal or vertical line fork represents the
splitting of a single flow of control into two or more concurrent flows of control.
➢ a fork represents the splitting of a single flow of control into two or more concurrent flows
of control.
➢ A fork may have one incoming transition and two or more outgoing transitions, each of
which represents an independent flow of control.
➢ a join represents the synchronization of two or more concurrent flows of control.
➢ A join may have two or more incoming transitions and one outgoing transition.
➢ Above the join, the activities associated with each of these paths continues in parallel
Fig: Forking and Joining

Swimlanes:
Each swimlane has a name unique within its diagram. A swimlane really has no deep semantics,
except that it may represent some real-world entity.

Sem
➢ Each swimlane represents a high-level responsibility for part of the overall activity of an
activity diagram, and each swimlane may eventually be implemented by one or more
classes.
➢ In an activity diagram partitioned into swimlanes, every activity belongs to exactly one
swimlane, but transitions may cross lanes.
Object Flow
➢ Objects may be involved in the flow of control associated with an activity diagram.
➢ We can specify the things that are involved in an activity diagram by placing these objects
in the diagram, connected using a dependency to the activity or transition that creates,
destroys, or modifies them.
➢ This use of dependency relationships and objects is called an object flow because it
represents the participation of an object in a flow of control.

Sem
Fig: Object Flow

Common Uses
When we model the dynamic aspects of a system, we typically use activity diagrams in two ways.
➢ To model a workflow
o Workflows often lie on the fringe of software-intensive systems and are used to
visualize, specify, construct, and document business processes that involve the
system we are developing
➢ To model an operation
o we use activity diagrams as flowcharts, to model the details of a computation.
o In this use of activity diagrams, the modeling of branch, fork, and join states is
particularly important

1. Modeling a Workflow
To model a workflow,
➢ Establish a focus for the workflow. For nontrivial systems, it's impossible to show all
interesting workflows in one diagram.
➢ Select the business objects (real things from vocabulary of the system) that have the high-
level responsibilities for parts of the overall workflow. .
➢ Identify the preconditions of the workflow's initial state and the
postconditions of the workflow's final state.

Sem
➢ Beginning at the workflow's initial state, specify the activities and actions that take place
over time and render them in the activity diagram as either activity states or action states.
➢ For complicated actions, or for sets of actions that appear multiple times, collapse these into
activity states, and provide a separate activity diagram that expands on each.
➢ Render the transitions that connect these activity and action states.
➢ If there are important objects that are involved in the workflow, render them in the activity
diagram, as well.
Fig: Modeling a Workflow

2. Modeling an Operation To
model an operation,
➢ Collect the abstractions that are involved in this operation. This includes the operation's
parameters (including its return type, if any), the attributes of the enclosing class, and
certain neighboring classes.
➢ Identify the preconditions at the operation's initial state and the postconditions at the
operation's final state
➢ Beginning at the operation's initial state, specify the activities and actions that take place
over time and render them in the activity diagram as either activity states or action states.
➢ Use branching as necessary to specify conditional paths and iteration.
➢ Only if this operation is owned by an active class, use forking and joining as necessary to
specify parallel flows of control.

Sem
Fig: Modeling an Operation

3. Forward and Reverse Engineering
➢ Forward engineering (the creation of code from a model) is possible for activity diagrams,
especially if the context of the diagram is an operation
➢ Reverse engineering (the creation of a model from code) is also possible for activity
diagrams, especially if the context of the code is the body of an
operation.

Sem
OBJECT ORIENTED ANALYSIS & DESIGN UNIT
III
BEHAVIORAL MODELING
Assignment-Cum-Tutorial Questions
A. Questions testing the understanding / remembering level of students
I) Objective Questions
1. Which of the two diagrams are isomorphic…..
a) Class diagram and Object diagram
b) Sequence and Collaboration diagram
c) Statechart and Activity diagram
d) Component and Deployment diagrams
2. An interaction is a behavior that exchange messages among……………
3.diagram emphasizes time ordering of messages.
4. ……………….diagram emphasizes the organization of the objects that
participates in an interaction.
5. Modeling the flow of control by organization…..
a) Sequence Diagrams b) Collaboration Diagrams
c) Use Case Diagrams d) Activity Diagrams
6. Branching can be represented in an Activity diagram with…
a) Ellipse b) Diamond c) Circle d) Rounded Rectangle
7. In activity diagram Action states can’t be decomposed [True/False]
8. ……………… is a one incoming transitions with one or more outgoing
transitions.
9.the synchronization of two or more concurrent flow of control.
10.In use case diagram can have packages and notes [True/False]
II) Descriptive questions
1. Describe the features of sequence and collaboration diagrams and their

properties and common uses
2. Identify common properties of interaction diagrams? Express semantic

equivalence between two kinds of interaction diagrams.
3. Enumerate contents, common properties and common uses of use case

diagrams?
4. Draw relevant use case diagrams by considering any two modeling issues.
5. Enumerate the steps involved in forward engineering on class diagram and
also apply reverse engineering on derived code.
Department Of Information Technology GEC III Year – I Sem Page 1

III
6. State and Explain different relationships that can be defined among use
cases.
7. Define event? Paraphrase how to model events in UML with an example
8. How we can apply swim lines to the activity diagram.
B. Question testing the ability of students in applying the concepts.

I) Multiple Choice Questions:
1. Is a specific alternative taken based on some Boolean condition

a) Branching b) Swim lane c) Forking d)Transition
2. Actors may connected to the use cases only by…….
a) Dependency b) Association c) Generalization d) Realization
3. The relationship between use case and collaboration……
4. To model the behavior of an element we will use……..
a) Activity b) Use case c) State chart d) Interactions
5. The relationship between actors in use case diagrams……
6. To model the context of the system……….
a) Activity diagram b) Use case diagram
c) State chart diagram d) Interactions diagram
7. …………specifies that the instance or link is created during execution of
the enclosing interaction
a) Create b) new c) start d) transient
8. is a stereotype an object may commit suicide by destroying itself
a) Kill b) Destroy c) Finish d) Stop
II) Problems
1. Sketch the use case diagram for modeling a hospital information system
aimed at collecting and storing complete information pertaining to the
patients treatment history and disease behavior where actors could be
doctor, lab technician, patient, duty nurse, receptionist, visitors etc.
2. Construct collaboration diagram that specifies the flow of control involved

in registering a new student at a school. Explain.

III
3. Develop an automated soda machine that gives cool drinks by using use
case model Draw an extended use case diagram for the soda machine
example depicting the ‘extend’, ‘include’ and generalization relationships.
4. Establish a model for a retail system that interacts with customers who
place and track orders. In turn, the system will ship orders and bill the
customers. Analyze the behavior of the system will ship orders and bill the
customers by declaring the behaviors as use cases.
5. Organize railway reservation system by using sequence and collaboration

diagrams.
6. Discriminate action state Vs. activity state. Illustrate How forking and
joining used in activity diagram.
C. Questions testing the analyzing / evaluating ability of student
1. Compose a model to identify the behavior of Student Registration

Model by using activity ,interaction diagram and use case diagram.
2. Design an activity diagram for computation of percentage of marks

and report card generation in an assessment system .
3. Illustrate interaction,use case and activity diagram for Airlines

Reservation System model by using behavioural model.
4. Design a Content Management System by using interaction and use

case model.

Object Oriented Analysis and Design UNIT-4 Learning Material

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Object Oriented Analysis and Design UNIT-4 Learning Material

Uploaded by

Copyright:

Available Formats

Object oriented Analysis And Design UNIT-Ⅳ

OBJECT ORIENTED ANALYSIS AND DESIGN

Department of Information Technology GEC III Year – ⅡSEM Page 1

Syllabus: Behavioral Modeling

Department of Information Technology GEC III Year – ⅡSEM Page 2

Figure: Messages, Links, and Sequencing We find

Objects and Roles

Department of Information Technology GEC III Year – ⅡSEM Page 3

Links and Connectors

Figure: Links, Associations and Connectors

Department of Information Technology GEC III Year – ⅡSEM Page 4

Specifies that the corresponding object is visible because it is in

Department of Information Technology GEC III Year – ⅡSEM Page 5

Fig: Procedural Sequence

Fig: Flat Sequence

Department of Information Technology GEC III Year – ⅡSEM Page 6

Specifies that the instance or link is created during execution

Common Modeling Techniques:

Department of Information Technology GEC III Year – ⅡSEM Page 7

Fig: Flow of control by time

Fig: Flow of Control by Organization

➢ An interaction diagram shows an interaction, consisting of a set of objects and their

Department of Information Technology GEC III Year – ⅡSEM Page 8

Fig: Interaction Diagrams

Department of Information Technology GEC III Year – ⅡSEM Page 9

Fig: Sequence Diagram

Structured Control in Sequence Diagrams

Department of Information Technology GEC III Year – ⅡSEM Page 10

Department of Information Technology GEC III Year – ⅡSEM Page 11

Fig: Structured Control Operators

Department of Information Technology GEC III Year – ⅡSEM Page 12

Fig: Nested activity diagram

Collaboration Diagrams (or Communication Diagram)

Department of Information Technology GEC III Year – ⅡSEM Page 13

Fig: Collaboration Diagram

Department of Information Technology GEC III Year – ⅡSEM Page 14

Fig: Modeling Flows of Control by Time Ordering

Department of Information Technology GEC III Year – ⅡSEM Page 15

Fig: Modeling Flows of Control by Organization

Department of Information Technology GEC III Year – ⅡSEM Page 16

Fig: Actors and Use Cases

Fig: Simple and Path Names

Department of Information Technology GEC III Year – ⅡSEM Page 17

Use Cases and Flow of Events

Use Cases and Scenarios

Department of Information Technology GEC III Year – ⅡSEM Page 18

Organizing Use Cases

Fig: Generalization, Include, and Extend

Department of Information Technology GEC III Year – ⅡSEM Page 19

Fig: Modeling the Behaviour of an Element

USE CASE DIAGRAMS

Department of Information Technology GEC III Year – ⅡSEM Page 20

Fig: A Use Case Diagram

Common Modeling Techniques

Department of Information Technology GEC III Year – ⅡSEM Page 21

Fig: Modeling the Context of a System

Department of Information Technology GEC III Year – ⅡSEM Page 22

Fig: Modeling the Requirements of a System

To reverse engineer a use case diagram,

Department of Information Technology GEC III Year – ⅡSEM Page 23

Fig: Activity Diagrams

Department of Information Technology GEC III Year – ⅡSEM Page 24