Professional Documents
Culture Documents
Object Oriented Analysis and Design UNIT-4 Learning Material
Object Oriented Analysis and Design UNIT-4 Learning Material
UNIT-4
Learning Material
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
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.
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
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
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.
INTERACTION DIAGRAMS
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.
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
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.
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.
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.
Branching
➢ Branches are a notational convenience, semantically equivalent to multiple transitions with
guards
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
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.
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.
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.
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.
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.
6. Discriminate action state Vs. activity state. Illustrate How forking and
joining used in activity diagram.