Overview of OOSD - PowerPoint PPT Presentation

1 / 150
About This Presentation
Title:

Overview of OOSD

Description:

Two orthogonal view of software. Overview of Unified Approach ... Concept of usecase and OOSE Ivar Jacobson. 5/28/09. REC/MCA/MC173. 19. Rumbaugh's OMT ... – PowerPoint PPT presentation

Number of Views:701
Avg rating:3.0/5.0
Slides: 151
Provided by: automo7
Category:
Tags: oosd | oose | overview

less

Transcript and Presenter's Notes

Title: 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.
Write a Comment
User Comments (0)
About PowerShow.com