Guidelines Use Case Analysis

INTERACTION DIAGRAMS

BY
SYED FEROZ ZAINVI

WRITING FROM:
HTTP://WWW.COMPUTER-SCIENCE-NOTES.BLOGSPOT.COM
 Recap

 Create the Use-Case Realization

 Supplement the Use-Case Description
 Find Analysis Classes – Boundary, Control, Entity
 Distribute Behavior to Analysis Classes
 Describe Responsibilities
 Describe Attributes and Associations
 INTERACTION DIAGRAMS

Object Interaction Diagrams (OID) model scenario

 Scenario  An instance of a use-case
 Primary  Represents normal flow
 Secondary  Represents alternate flow

OID Types:
 Collaboration Diagram: Message oriented dynamic behavior
 OBJECT ROLES
 Sequence Diagram: Time oriented dynamic behavior
 WHAT MESSAGE & WHEN
Collaboration Diagram
Contents
 Actors: Invoke interaction-Keep at
periphery
 Objects: Objectname:Classname
(classname unspecified, object
named/unnamed, only classname)
 Links: Relationship, instance of
association-may be unspecified- veh
for messages
 Messages: Communication-arrow
points towards target object-shown
with name, parmaters, sequence-
temporary: later mapped to operation
 Sequence Diagram

Contents
Objects with lifeline
Actors
Messages with duration
No links
*
[condn]
Scripts: Textual
description for lifelines or
messages
Rules same as for
Collaborations Diagrams
Control Flow in Sequence Diagrams
Centralized Control Flow
 Few objects steer the flow by
sending messages to, and
receiving messages from other
objects
 These controlling objects decide
the order in which other objects
will be activated in the use case
 Interaction among the rest of
the objects is very minor or does
not exist
FORK SHAPED
Control Flow in Sequence Diagrams

Decentralized Control Flow

Participating objects
communicate directly
with one another, not
through one or more
controlling objects

STAIR-WAY SHAPED
 Centralized Vs Decentralized Control Flow
A decentralized structure is appropriate:
 If the sub-event phases are tightly coupled. This
A centralized structure is
will be the case if the participating objects:
 Form a part-of or consists-of hierarchy, such
appropriate:
as Country - State - City; If the order in which the
 Form an information hierarchy, such as CEO -
Division Manager - Section Manager; sub-event phases will be
 Represent a fixed chronological progression
(the sequence of sub-event phases will always performed is likely to
be performed in the same order), such as
Advertisement - Order - Invoice -Delivery -
change.
Payment; or
 Form a conceptual inheritance hierarchy, such
If you expect to insert new
as Animal - Mammal - Cat.
 If you want to encapsulate, and thereby make
sub-event phases.
abstractions of, functionality. This is good for If you want to keep parts
someone who always wants to use the whole
functionality, because the functionality can of the functionality
become unnecessarily hard to grasp if the
behavior structure is centralized. reusable as separate
pieces.
 Similarities between Collaboration & Sequence Diagram

Both determine class responsibilities & interfaces

Both express similar information but in different
ways
Make either or both of them for:
 a use case
 part of use case
 each flow of events
 each sub-flow of events
 Collaboration Diagram

Unlike sequence diagram, shows relationship among objects

Provides understanding of all the effects on a given object and for
procedural design
Better suited for analysis activities
Good for depicting simpler interactions of smaller numbers of
objects
- Hard to read when number of objects or messages increase
- Timing, decision points, unstructured information can be added
as easily as in sequence diagram
 Sequence Diagram

Unlike a collaboration diagram, includes

chronological sequences
But does not include object relationships
Suited when the explicit sequence of messages has to
be shown
 when it is important to visualize the time ordering of messages
But for structural relationships among the instances
in an interaction, use a collaboration diagram
 Further Guidelines

 Choices can be shown on OIDs (demonstrating slightly different

scenarios)
 Keep OIDs simple – so limit
 No limit on no. of scenarios that can be produced  produce more
OIDs rather than make more complex
 Sequence Or Collaboration: No definitive rule—Easier to understand &
should be used for communicating with customers
 When used:
 Identification of use case  Implementation
 Details may vary: In analysis, no message signatures and no design objects
 Inspect behavior of several objects within a single use-case
For more notes, keep visiting:
http://www.computer-science-notes.blogspot.com

ALSO LINKED THROUGH:

HTTP://WWW.CROSSROADSBYZAINVI.BLOGSPOT.COM