Overview of OOSD

1
Overview of OOSD OO Methodologies
2
Objective

• To learn Unified Approach
• To know UML model elements
• To understand basis of Object Oriented
  Methodologies

3
Agenda

• Two orthogonal view of software
• Overview of Unified Approach
• Modeling and model elements
• Software development process
• OOSDLC
• Rumbaugh, Booch and Jacobson methodologies

4
Introduction

• Systems development
• - refers to all activities that go into
  producing an information systems solution
• Software development methodology
• - is a series of processes that lead to the
  development of an application

5
Two orthogonal views of software

• Traditional development
• Object oriented development
• - is a way to develop software by building
  self - contained modules or objects that can be
  easily replaced, modified and reused.

6
Unified Approach - Overview

• is a methodology for software development
• based on Rumbaugh, Booch and Jacobson
  methodologies
• combines best practices, processes and guidelines
  of 3 methodologies along with OMGs UML

7
Unified Approach - Overview

• UML
• - is a set of notations and conventions used
  to describe and model an application
• Layered architecture
• - allows us to create objects that represent
  tangible elements of the business independent of
  how they are represented to the user thro an i/f
  or physically stored in db

8
Different parts of UML

• Views
• - show different aspects of the system that are
  modeled
• - is not a graph
• - an abstraction consisting of number of
  abstractions

9
Different parts of UML

• Usecase view shows the functionality of the
  system as perceived by external actors
• Logical view shows how the functionality is
  designed inside the system, in terms of static
  structure and dynamic behavior
• Component view - showing the organization of
  code components
• Deployment view showing the deployment of the
  system into the physical architecture with
  computers and devices called nodes

10
Different parts of UML

• Diagrams
• - are the graphs that describe the contents in
  a view
• -usecase -activity
• -class -sequence
• -object -collaboration
• -statechart -component
• - deployment

11
Different parts of UML

• Model elements
• - concepts used in the diagrams

12
Software Development Process
What are the uses of the system?
Transformation 1
Problem Statement Analysis
Transformation 2
Design Implementation
Detail
Transformation 3
Software Product
13
Quality measures
validation
verification
Needs
Requirements
Design
Software
Correctness
Correspondence
14
Object oriented systems development usecase
driven approach
Analysis
Iteration and refine
Implementation
Design
15
OO Analysis

• Building usecases model
• Object analysis
• Validate / test

16
OO Design

• Design classes, define attributes and methods
• Build object and dynamic model
• Build user interface and prototype
• User satisfaction test, usability test and QA test

17
OO implementation

• Using TOOLS CASE / OO programming languages
• User satisfaction test, usability test and QA
  test

18
OO methodologies

• OO design method - Booch
• Concept of recursive design approach Sally
  Shlaer
• CRC cards Beck and Cunningham
• OMT Rumbaugh
• Concept of usecase and OOSE Ivar Jacobson

19
Rumbaughs OMT

• describes a method for analysis, design and
  implementation
• is a fast, intuitive approach for identifying and
  modeling all the objects that makes the system
• Class attributes, method, inheritance and
  association can be expressed
• dynamic model describes the dynamic behavior of
  objects

20
Rumbaughs OMT

• Analysis results are objects, dynamic and
  functional models
• System design produces a basic architecture of
  the system
• Object design produces a design document,
  consisting of detailed objects static, dynamic
  and functional models
• Implementation produces reusable, extendible
  code

21
Rumbaughs OMT

• Object model presented by object diagram
• Dynamic model state diagrams and event flow
  diagrams
• Functional model data flow and constraints

22
Booch methodology

• Macro development process
• - conceptualization
• - analysis and development of the model
• - design or create the system architecture
• - evolution or implementation
• - maintenance

23
Booch methodology

• Micro development process
• - identify classes and objects
• - identify class and object semantics
• - identify class and object relationships
• - identify class and object interfaces and
  implementation

24
Jacobson methodology

• Concept of usecase
• - scenarios for understanding the system
  requirements
• - is an interaction between user and system
• - captures the goal of the user and
  responsibility of the system to its users

25
Extending UML

• Stereotypes
• - defines a new kind of model element based on
  an existing model element
• - is just-like an existing element, plus
  some extra semantics that are not present in the
  former
• - are based on all types of elements
  classes, nodes, components and notes as well as
  relationships
• - described as ltltstereotypenamegtgt

26
Extending UML

• Tagged values
• - elements can have properties that contain
  name-value pairs of information about them
• - described as name value

27
Extending UML

• Constraints
• - is a restriction on an element that limit
  the usage of the element or the semantics of the
  element
• - defined and applied as needed in a diagram

Senior citizen
person.age gt 60
Person
28
Goals of UML

• Provide users a ready-to-use, expressive visual
  modeling language so they can develop and
  exchange meaningful models
• Provide extensibility and specialization
  mechanisms to extend the core concepts
• Be independent of particular programming
  languages and development processes
• Provide a formal basis for understanding the
  modeling language
• Integrate best practices and methodologies

29
UML Diagram Classification

• Static The static characteristic of a system is
  essentially the structural aspect of the system.
  The static characteristics define what parts the
  system is made up of.
• Dynamic The behavioral features of a system for
  example, the way a system behaves in response to
  certain events or actions are the dynamic
  characteristics of a system.
• Implementation The implementation characteristic
  of a system is an entirely new feature that
  describes the different elements required for
  deploying a system.

30
Use Case Diagram

• The use case diagram is used to identify the
  primary elements and processes that form the
  system.
• The primary elements are termed as "actors" and
  the processes are called "use cases".
• The use case diagram shows which actors interact
  with each use case.

31
Class Diagram

• Class diagram gives an overview of a system by
  showing its classes and the relationships among
  them.
• It is used to refine the use case diagram and
  define a detailed design of the system.
• It classifies the actors defined in the use case
  diagram into a set of interrelated classes.
• The relationship or association between the
  classes can be either an "is-a or "has-a"
  relationship.

32
Class Diagram

• Each class in the class diagram may be capable of
  providing certain functionalities.
• Functionalities provided by the class are termed
  "methods" of the class.
• Each class may have certain "attributes" that
  uniquely identify the class.

33
Class Diagram

• Class diagram is a type of static structure
  diagram that describes the structure of a system
  by showing the system's classes, their
  attributes, and the relationships between the
  classes.

34
Categories the UML Diagrams

• Dynamic
• Object diagram
• State diagram
• Activity diagram
• Sequence diagram
• Collaboration diagram

• Static
• Use case diagram
• Class diagram
• Implementation
• Component diagram
• Deployment diagram

35
UML Diagram Classification
36
41 Architectural view of UML diagrams

• The 41 view describes how a system can be
  viewed from a software life cycle perspective.
  Each of these views represents how a system can
  be modeled.
• This will enable us to understand where exactly
  the UML diagrams fit in their applicability.

37
Architectural view
38
Relationships

• Instance Level Relationships
• Link
• Association
• Aggregation
• Composition
• Class Level Relationships
• Generalization
• Realization
• General Relationship
• Dependency
• Multiplicity

39
class diagram model- for a customer order from a
retail catalog
Abstract classes, such as Payment, are in
italics. Relationships between classes are the
connecting links.
40

• A relationship is a term which specifies the
  type of logical connections found on class and
  object diagrams.
• UML shows the following relationships

41
UML Class Diagram Notation
Class
42
Class Diagram has three kinds of relationships.

• Association -- a relationship between instances
  of the two classes. There is an association
  between two classes if an instance of one class
  must know about the other in order to perform its
  work.
• In a diagram, an association is a link connecting
  two classes.

43
Aggregation

• An association in which one class belongs to a
  collection.
• It is a variant of the "has a" or association
  relationship.
• It is more specific than association.
• It has a clear diamond end pointing to the part
  containing the whole.
• In diagram, Order has a collection of
  OrderDetails.
• However, an aggregation may not involve more than
  two classes.

44
Aggregation

• Aggregation can occur when a class is a
  collection or container of other classes, but
  where the contained classes do not have a strong
  life cycle dependency on the container--essentiall
  y, if the container is destroyed, its contents
  are not.

45
Generalization

• An inheritance link indicating one class is a
  super class of the other.
• A generalization has a triangle pointing to the
  super class. Person is a superclass of student,
  and professor

• The generalisation relationship is also known as
  the inheritance or "is a" relationship.

46
Realization

• In UML, a realization is a relationship between
  two model elements, in which one model element
  (the client) realizes the behavior that the other
  model element (the supplier).
• A realization is represented in the diagram as a
  dashed line with an unfilled arrowhead towards
  the supplier.
• Realizations can only be shown on class diagrams.
• A realization is a relationship between classes,
  interfaces, components, and packages that
  connects a client element with a supplier
  element.

47
Generalization

• The Generalization relationship indicates that
  one of the two related classes (the subtype) is
  considered to be a specialized form of the other
  (the super type) and super type is considered as
  Generalization of subtype.
• In practice, the super type in the generalisation
  relationship is also known as the "parent",
  superclass, base class, or base type.
• The subtype in the generalisation relationship is
  also known as the "child", subclass, derived
  class, derived type, inheriting class, or
  inheriting type.

48
Composition
It is a stronger variant of the "has a" or
association relationship. composition is more
specific than aggregation. It is represented
with a filled diamond shape. Composition has a
strong life cycle dependency between instances of
the container class and instances of the
contained classes. If the container is
destroyed, every instance that it contains is
destroyed as well.
49
Composition and Aggregation

• The whole of a composition must have a
  multiplicity of 0..1 or 1, indicating that a part
  must be for only one whole.
• The part of an aggregation may have any
  multiplicity.

50
The class diagram model- a customer order from a
retail catalog
Abstract classes, such as Payment, are in
italics. Relationships between classes are the
connecting links.
51

• Most common multiplicity used in Class Diagram

52
Packages and object diagrams

• To simplify complex class diagrams, you can group
  classes into package.
• A package is a collection of logically related
  UML elements.
• In which the classes are grouped into packages.

53
Package Diagram
Packages appear as rectangles with small tabs at
the top. The package name is on the tab or inside
the rectangle. The dotted arrows are
dependencies. One package depends on another if
changes in the other could possibly force changes
in the first.
54
References

• UML Web Resources
• http//www.objectsbydesign.com
• UML and OO links, forums, and resources
• http//www.devx.com/uml/
• Magazine with many UML related articles
• http//www.omg.org
• http//www.rational.com
• UML Books
• UML Bible by Tom Pender
• UML Distilled by Martin Fowler Kendal
  Scott
• Applying UML Patterns by Craig Larman

55
Definition of State Diagram

• A State diagram is a visual representation of an
  application's state machines. It shows the life
  of an object from birth to death.

56
State Machine

• A state machine is a behavior which specifies the
  sequence of states an object visits during its
  lifetime in response to events, together with its
  responses to those events.

57
Elements of State Diagram

• Initial State
• States
• Transitions
• History States
• Event and Action
• Signal
• Final State

58
State

• A state is a condition during the life of an
  object during which it satisfies some condition,
  performs some activity, or waits for some
  external event.
• Initial State State History State

59
Complete State Figure
60
Event

• An event is the specification of a significant
  occurrence.
• For a state machine, an event is the occurrence
  of a stimulus that can trigger a state transition

61
Action

• An action is an executable, atomic (with
  reference to the state machine) computation.

• An event is something done to the object
• such as it being sent a message
• An action is something that the object does
• such as it sending a message

62
Transition

• A transition is a relationship between two states
  indicating that an object in the first state
  will, when a specified set of events and
  conditions are satisfied, perform certain actions
  and enter the second state.

63
Transition Components

• a source state
• an event trigger
• an action
• a target state

64
Conditional State
65
Self-Transition

• A self-transition is a transition whose source
  and target states are the same.

66
Signal

• When an event causes a message/trigger to be sent
  to a state, that causes the transition then,
  that message sent by the event is called a
  signal.

67
Final State

• The end of the state diagram is shown by a bull's
  eye symbol, also called a final state.

68
A Simple State Machine Diagram

69
State Diagrams

• Let us start with a very simple example
• in which an object receives a message and what it
  does depends on the values of its attributes and
  links.
• In a Library system, consider an object of class
  Copy
• which is intended to record whether the object
  describes a copy of a book
• which is currently in the library,
• or one which is currently on loan.

70
State diagram of class Copy

• We can name two significantly different states of
  
• a Copy object
• on the shelf and on loan

71
Unexpected messages

• In previous figure, we have not shown arrows to
  represent
• the receipt of message borrow() in state on
  loan or
• the message return() in state on shelf
• Under normal circumstances, such messages should
  not arrive if they do its a bug.

72
State diagram of class Copy with action

• Analysing the notation
• The slash (/) shows that what follows is an
  action
• book followed by a dot identifies the object to
  which a message is being sent
• returned(self) is an example of a message
  including a parameter, where self is reference to
  itself

73
State diagram of class Copy with - entry
action - exit action

• We can show our intention directly, by writing
  the action inside the state, as a reaction to the
  special event (e.g entry or exit)

74
Guards

• Sometimes the occurrence of the same event in the
  same
• state may or may not cause a change of state,
• depending on the exact values of the objects
• attributes
• We can show this using the same conditional
  notation
• that is used in generic interaction diagrams

Several actions in one diagram.
75
State diagram for class Book

• The borrowed() message cause a state change out
  of state borrowable
• only if this is the last copy on the shelf
• otherwise, the book object remains
• borrowable.

76
State Diagram before Events and Transitions
77
State Diagram With Unlabeled Events and
Transitions
78
Completed State Diagram
79
(No Transcript)
80
(No Transcript)
81
(No Transcript)
82
(No Transcript)
83
(No Transcript)
84
Advanced States

• Entry and Exit Actions

85
Substates

• A substate is a state that is nested in another
  state.
• A state that has substates is called a composite
  state.
• A state that has no substates is called a simple
  state.
• Substates may be nested to any level.

86
Advanced Transition

• Transitions to a composite state
• If a transition is to a composite state, the
  nested state machine must have an initial state.
• If a transition is to a substate, the substate is
  entered after any entry action for the enclosing
  composite state is executed followed by any entry
  action for the substate.

87
Advanced Transition

• Transitions from a composite state
• If a transition is from a substate within the
  composite state, any exit action for the substate
  is executed followed by any exit action for the
  enclosing composite state.
• A transition from the composite state may occur
  from any of the substates and takes precedence
  over any of the transitions for the current
  substate.

88
Advanced State Machine
89
Problems with UML Notations

• When more than one transition from a state is
  enabled there is no method for specifying
  precedence.
• For nested states there is no method for
  specifying precedence of the enclosing or
  enclosed state.

90
Assignment-A seminar during registration
91
Complete Seminar Life Cycle
92
Complete Seminar Life Cycle
93
Sample Activity Diagram
94
What is activity diagram?

• An Activity diagram is a visual representation of
  any system's activities and flows of data or
  decisions between activities.
• Activity diagrams provide a very broad view of a
  business process.
• Emphasis the input/output dependencies,
  sequencing, and conditions for coordinating other
  behaviors
• Uses secondary constructs to show which
  classifiers are responsible for those behaviors
• Focus is on what tasks need to be done, with what
  inputs, in what order, rather than who/what
  performs each task.

95
Usage

• Describe activities and flows of data or
  decisions between activities
• Describe the activities that occur within a use
  case
• Show many different activities using different
  discrete symbols
• Show parallel threads

96
Elements in Activity Diagram

• Basic
• Activity/Invocation - The rounded rectangles
  represent activities that occur. An activity may
  be physical, such as Inspect Forms, or
  electronic, such as Display Create Student
  Screen.
• Activity Flow/edge - An abstract class for
  directed connections between two Activity nodes.
  
• Activity Group - Sets of invocation nodes and
  activity edges in an Activity. A generic grouping
  construct for nodes and edges.
• Initial node the first node in an Activity.
• Activity final node - The final node that stops
  all flows in an Activity.
• Flow Final - The final node that terminates a
  flow and destroys all tokens that arrive at it.

97
Elements in Activity Diagram

• Control
• Decision - A diamond with one flow entering and
  several leaving.  The flows leaving include
  conditions although some modelers will not
  indicate the conditions if it is obvious. 
• Fork - A black bar with one flow going into it
  and several leaving it.  This denotes the
  beginning of parallel activity.
• Vertical Fork
• Horizontal Fork
• Join - A black bar with several flows entering it
  and one leaving it.  All flows going into the
  join must reach it before processing may
  continue.  This denotes the end of parallel
  processing.
• Condition - defining a guard which must evaluate
  to true in order to traverse the node.

98
Elements in Activity Diagram

• Data
• Parameter Usage - An object node for inputs and
  outputs to invocations. Parameter usage nodes
  flow directly to or from invocations.
• Data Store - A central buffer node for
  non-transient information. Object node for
  mapping flows from multiple sources and
  destinations.
• Signal - indicates that the activity receives an
  event from an outside process. This indicates
  that the activity constantly listens for those
  signals, and the diagram defines how the activity
  reacts.
• Partition - A special kind of grouping of
  invocations and activity edges. Partitions divide
  the nodes and edges to constrain and show a view
  of the contained nodes. Partitions often
  correspond to organizational units in a business
  model.

99
Elements in Activity Diagram

• Dependencies
• Dependency - The relationship between two
  elements whose definitions depend on one another
  in such a way that changes to one can result in
  changes to the other. For example, when one class
  mentions another as an operation parameter, or as
  part of its data, the two classes exhibit
  dependency.
• Realize - A semantic relationship between
  classifier. One classifier specifies a contract
  that another classifier guarantees to carry out.
  These relationships are used in two places
  between interfaces and the classes that realize
  them, and between Use Cases and the
  Collaborations that realize them.
• Usage - A dependency in which one element (the
  client) requires the presence of another element
  (the supplier) for its correct functioning or
  implementation.

100
Elements in Activity Diagram

• Dependencies
• Permission - A dependency that signifies granting
  of access rights from the supplier model element
  to a client model element, in which the client
  requires access to some or all of the constituent
  elements of the supplier.
• Abstraction - A boundary relative to the
  perspective of the viewer. The essential
  characteristics of an entity that distinguish it
  from all other kinds of entities.
• Comment
• Comment - A Notepad notation. Use Comments to
  record information for a element or link in a
  diagram. This information is not included in
  generated code but is for information only. Each
  Comment can contain unlimited text, and can be
  numbered. You can also define a stereotype, and
  enter a noted element.
• Link Comment - The connection between the comment
  element and the associated element.

101
Case Study

• Bank Transaction by Customer
• Order Processing
• Order Processing with Partition

102
Bank Transaction
103
Order Processing
104
Order Processing with Partition
105
Sample Activity Diagram
106
What is activity diagram?

• An Activity diagram is a visual representation of
  any system's activities and flows of data or
  decisions between activities.
• Activity diagrams provide a very broad view of a
  business process.
• Emphasis the input/output dependencies,
  sequencing, and conditions for coordinating other
  behaviors
• Uses secondary constructs to show which
  classifiers are responsible for those behaviors
• Focus is on what tasks need to be done, with what
  inputs, in what order, rather than who/what
  performs each task.

107
Usage

• Describe activities and flows of data or
  decisions between activities
• Describe the activities that occur within a use
  case
• Show many different activities using different
  discrete symbols
• Show parallel threads

108
Elements in Activity Diagram

• Basic
• Activity/Invocation - The rounded rectangles
  represent activities that occur. An activity may
  be physical, such as Inspect Forms, or
  electronic, such as Display Create Student
  Screen.
• Activity Flow/edge - An abstract class for
  directed connections between two Activity nodes.
  
• Activity Group - Sets of invocation nodes and
  activity edges in an Activity. A generic grouping
  construct for nodes and edges.
• Initial node the first node in an Activity.
• Activity final node - The final node that stops
  all flows in an Activity.
• Flow Final - The final node that terminates a
  flow and destroys all tokens that arrive at it.

109
Elements in Activity Diagram

• Control
• Decision - A diamond with one flow entering and
  several leaving.  The flows leaving include
  conditions although some modelers will not
  indicate the conditions if it is obvious. 
• Fork - A black bar with one flow going into it
  and several leaving it.  This denotes the
  beginning of parallel activity.
• Vertical Fork
• Horizontal Fork
• Join - A black bar with several flows entering it
  and one leaving it.  All flows going into the
  join must reach it before processing may
  continue.  This denotes the end of parallel
  processing.
• Condition - defining a guard which must evaluate
  to true in order to traverse the node.

110
Elements in Activity Diagram

• Data
• Parameter Usage - An object node for inputs and
  outputs to invocations. Parameter usage nodes
  flow directly to or from invocations.
• Data Store - A central buffer node for
  non-transient information. Object node for
  mapping flows from multiple sources and
  destinations.
• Signal - indicates that the activity receives an
  event from an outside process. This indicates
  that the activity constantly listens for those
  signals, and the diagram defines how the activity
  reacts.
• Partition - A special kind of grouping of
  invocations and activity edges. Partitions divide
  the nodes and edges to constrain and show a view
  of the contained nodes. Partitions often
  correspond to organizational units in a business
  model.

111
Elements in Activity Diagram

• Dependencies
• Dependency - The relationship between two
  elements whose definitions depend on one another
  in such a way that changes to one can result in
  changes to the other. For example, when one class
  mentions another as an operation parameter, or as
  part of its data, the two classes exhibit
  dependency.
• Realize - A semantic relationship between
  classifier. One classifier specifies a contract
  that another classifier guarantees to carry out.
  These relationships are used in two places
  between interfaces and the classes that realize
  them, and between Use Cases and the
  Collaborations that realize them.
• Usage - A dependency in which one element (the
  client) requires the presence of another element
  (the supplier) for its correct functioning or
  implementation.

112
Elements in Activity Diagram

• Dependencies
• Permission - A dependency that signifies granting
  of access rights from the supplier model element
  to a client model element, in which the client
  requires access to some or all of the constituent
  elements of the supplier.
• Abstraction - A boundary relative to the
  perspective of the viewer. The essential
  characteristics of an entity that distinguish it
  from all other kinds of entities.
• Comment
• Comment - A Notepad notation. Use Comments to
  record information for a element or link in a
  diagram. This information is not included in
  generated code but is for information only. Each
  Comment can contain unlimited text, and can be
  numbered. You can also define a stereotype, and
  enter a noted element.
• Link Comment - The connection between the comment
  element and the associated element.

113
Case Study

• Bank Transaction by Customer
• Order Processing
• Order Processing with Partition

114
Bank Transaction
115
Order Processing
116
Order Processing with Partition
117
Collaboration (or Communication) Diagram
UML v2 will call them communication diagrams,
but collaboration is still used in Visio and
the current UML standard
118
Collaborations

• The objects which interact to perform some
  task, together with the links between them, are
  known as a collaboration
• Objects
• Each object is shown as rectangle, which is
  labelled objectName className
• Links
• Links between objects are shown like associations
  in the class model.
• Actors
• Actors can be shown as on a use case diagram

119
A simple collaboration, showing no interaction

• A collaboration, without any interaction shown,
  is rather like an instance of part of the class
  model. It shows objects, links and actors

120
Interaction on collaboration diagrams

• Each labelled arrow represents a message sent
  from the object at the tail of the arrow to the
  object at the point of the arrow.
• Furthermore, the target object must understand
  the message
• That is, the class of the object at the point of
  the arrow must provide the appropriate operation

121
Collaboration Diagram

• A Collaboration Diagram looks like a class
  diagram, since it has boxes (with class or object
  names) connected by lines
• But here, the lines correspond to message paths,
  not associations
• It shows what messages are passed between objects

122
Collaboration Diagram

• To show the chronological order of messages, a
  collaboration diagram MUST NUMBER MESSAGES
• The first object dictates the start of each
  numbering series
• Its first message is number 1., the second
  2., etc.
• Messages which follow as a result of the first
  message get 0.1 added for each message, i.e. 1.1,
  1.2, 1.3, etc.

123
Collaboration Diagram

• Then the messages which follow message 2. do
  likewise, 2.1, 2.2, 2.3, etc.
• This establishes threads of messages
• Some people just number the messages sequentially
  (1, 2, 3, ), but this is not compliant with any
  UML standard

124
Collaboration Diagram

• The other critical thing is to determine where
  messages live (what object is responsible for
  implementing them)
• The object to which a message points (its target)
  is responsible for implementing that message
• This also applies for sequence diagrams

125
(No Transcript)
126
Collaboration diagram
127
A Cellular Phone

• Problem Definition
• Consider the software that controls a very simple
  cellular telephone. Such a phone has buttons for
  dialing digits, and a send button for
  initiating a call. It has dialer hardware and
  software that gathers the digits to be dialed and
  emits the appropriate tones. It has a cellular
  radio that deals with the connection to the
  cellular network. It has a microphone, a speaker,
  and a display.

128
Static model of a Cellular Phone
129
Collaboration Diagram of Make Phone Call use
case.
130
CASE STUDY
131
(No Transcript)
132
(No Transcript)
133
(No Transcript)
134
(No Transcript)
135
(No Transcript)
136
(No Transcript)
137
(No Transcript)
138
(No Transcript)
139
(No Transcript)
140
(No Transcript)
141
(No Transcript)
142
(No Transcript)
143
(No Transcript)
144
(No Transcript)
145
(No Transcript)
146
Interaction diagrams

• Both describe the flow of messages between
  objects.
• However, sequence diagrams focus on the order in
  which the messages are sent.
• They are very useful for describing the
  procedural flow through many objects.
• They are also quite useful for finding race
  conditions in concurrent systems.
• Collaboration diagram, on the other hand, focus
  upon the relationships between the objects.
• They are very useful for visualizing the way
  several objects collaborate to get a job done and
  for comparing a dynamic model with a static model
• Collaboration and sequence diagrams describe the
  same information, and can be transformed into one
  another without difficulty. The choice between
  the two depends upon what the designer wants to
  make visually apparent.

147
Collaboration versus Sequence Diagrams

• Use collaboration diagrams when you want to make
  use of a two-dimensional layout of interacting
  objects
• Ok when there arent that many objects
• Use sequence diagrams when layout doesnt help in
  presentation and when you want to clarify calling
  sequence

148
Interaction Diagram Strengths

• Communication Diagram
• Space Economical - flexibility to add new objects
  in two dimensions
• Better to illustrate complex branching,
  iteration, and concurrent behavior
• Sequence Diagram
• Clearly shows sequence or time ordering of
  messages
• Simple notation

149
Interaction Diagram Weaknesses

• Communication Diagram
• Difficult to see sequence of messages
• More complex notation
• Sequence Diagram
• Forced to extend to the right when adding new
  objects consumes horizontal space

150
Conclusions

• Beginners in UML often emphasize Class Diagrams.
  Interaction Diagrams usually deserve more
  attention.
• There is no rule about which diagram to use.
  Both are often used to emphasize the flexibility
  in choice and to reinforce the logic of the
  operation. Some tools can convert one to the
  other automatically.