Object Oriented & UML

1
 Module Introduction

2
 Module Objectives
• In this module, the following points will be
covered:
– Understand the basic principles of object
orientation
– Understand the basic concepts and terms of
object orientation and the associated UML
notation
– Understand some basic UML modeling
mechanisms

3
 Lesson 1: Introduction Object
Oriented

4
 Introduction

5
 Student Guide

6
 Objectives
• In this lesson, the following points will be
studied:
– Introduction to object oriented modeling
– Benefits of objects
– Object-oriented modeling levels of abstraction
– Principles of object orientation

7
 Topic 1: Introduction to object
oriented modeling

8
 Introduction
• According to Grady Booch;
– A model
• provides the blueprints of a system.
• may encompass detailed plans, as well as more
general plans that give an over view of the system
under construction.
• A good model includes those elements that are not
relevant to the given level of abstraction.
• Every system may be described from
different aspects using different models, and
each model is therefore a semantically closed
abstraction of the system.

9
 2.3
OBJECT-ORIENTED MODELING
• Why Objects ??
– Objects
• more accurately reflect the real world in a model thereby
reducing the “semantic gap” between reality and a model.
• Objects localize changes to the model!
• Objects allow the software developer to represent real-world
concepts in their software design. These real-world concepts can
represent a physical entity such as a person, truck, or space
shuttle.
• Objects can be concepts like a chemical process or algorithms.
• Objects can even represent software entities like a linked list.

10 We model reality as a number of interacting objects.

 OBJECT-ORIENTED MODELING LEVELS
OF ABSTRACTION
Conceptual Level- We construct a problem domain model.
– We do not consider any aspects of implementation of objects
 Focus on identifying concept(“objects”)
in the problem domain

Design Level - We construct a solution domain model.

– We consider interfaces of objects (but no internal aspects)
 Focus on how objects interact in the solution domain

Implementation Level - We implement the solution domain model.

– We consider all details of objects (external and internal)
 Focus on how to code objects

 Modeling proceeds from the conceptual to implementation

Same OO concepts can be used at all levels to build

11 models
 Topic 2:Principles of Object
Orientation

12
 Principles of Object Orientation

•Encapsulation
•Abstraction
•Modularity

13
 Encapsulation/Hiding
• Encapsulation can be defined as:
– The physical localization of features (e.g., properties, behaviors) into a single blackbox abstraction
that hides their implementation (and associated design decisions) behind a public interface.
According to (Dictionary of Object Technology, Firesmith, Eykholt, 1995)
• Encapsulation:
• is often referred to as “information hiding,” making it possible for the clients to operate
without knowing how the implementation fulfills the interface.
• offers two kinds of protection. It protects an object’s internal state from being corrupted
by its clients and client code from changes in the object’s implementation.
• is preventing more maintenance problems than any other OO principle in history by
localizing the changes required for the behavior of an object to vary.
• helps classes protection from unnecessary changes

• The object encapsulates both data and the logical procedures required to manipulate the
data

14
 Abstraction
• A problem solving tool that allows one to think of a
problem at a higher level without worrying about the
details.
• Allows us to manage complexity by concentrating on
the essential characteristics of an entity that
distinguish it from all other kind of entities.
• Is domain and perspective dependent.
• OO allows us to model our system using abstractions
from the problem domain (for example, classes and
objects).
• OO based on three abstraction mechanisms:
classification, generalization, and aggregation.

15
 TYPES OF ABSTRACTIONS
 Classification forms new objects by suppressing the details of
individual instances and emphasizing properties of the whole.
New object types (classes) are formed by collecting instances.
 ==> describes the ‘instance-of’ relationship
 classification — group similar instances of objects

secretary

IS_MEMBER_OF
relationship

Jane Bob . . .

16  pick out common properties and ignore unique properties

 TYPES OF ABSTRACTIONS
 Generalization merges existing types to form new types. Individual
differences between subtypes are ignored and common traits are
emphasized.
 ==> describes the 'is-a‘ relationship
 generalization — group similar sets of objects
superclass/supertype Employee
IS_A
relationship

Secretary Teacher . . . Staff

subclass/subtype
 note difference between classification and generalization
– classification – applied to individual instances of objects
17
– generalization – applied to sets of objects (classes)
 TYPES OF ABSTRACTIONS
 Aggregation forms an object as a relationship among other
objects. It suppresses the details of the components and
emphasizes the details of the relationship as a whole.
==> describes the 'is-part-of‘ relationship
 aggregation — group dissimilar sets of objects
airplane

IS_PART_OF
relationship

wing landing gear . . . fuselage

18
 ignore differences among the parts and concentrate
on the fact that they form the whole
 Modularity
• Modularity is the breaking up of something
complex into manageable pieces.
• Modularity helps people to understand
complex systems.

19
 Example: Modularity
Billing System

? Course Catalog System

Course Registration
System
Student Management System

20
 Summary

21
 Activity

22
 Quiz

23
 Lesson 2: Unified Modeling Language

24
 Introduction

25
 Student Guide

26
 Objectives
• In this lesson, the following points will be
studied:
– History about UML and its evolution
– Reasons for using UML
– The 4+1 UML view

27
Topic 1:UML history & introduction

28
 History
Booch, Jacobson, Rumbaugh
• In the 90s many people creating OO diagramming languages
• Three different ones Booch Method by Grady Booch, Object-Oriented
Software Engineering (OOSE) by Ivar Jacobson, Object Modeling
Technique (OMT) by James Rumbaugh
• Joined forces with Rational (company) to create Unified Modeling
Langauge (UML)
• In October 1994, Rational Software Company unifying some of the
leading object-oriented modeling methods,
– Booch by Grady Booch,
– OMT (Object Modeling Technique), by Jim Raumbaugh and
– OOSE (Object-Oriented Software Engineering), by Ivar Jacobson.
• in 1997 the Unified Modeling Language submitted to the Object
Management Group (OMG) for standardization.
• The current version of UML is 2.0 (published in Oct 2004).
29
30
 What is the UML?
• UML:
– Unified Modeling Language, UML , is standard notation for Object-
Oriented Analysis and Design (OOAD).
– defined by the Object Management Group (OMG) and become the
standardized specialization language that can be used for Object
Modeling.
– The UML combines the best of the best from:
• Data Modeling concepts (Entity Relationship Diagrams)
• Business Modeling (Work Flow)
• Object Modeling
• Component Modeling
– is a standard language for specifying, visualizing, documenting and
constructing the artifacts of a software- systems. It should be noted that
UML is a standard; it is not a methodology, process or a procedure
– It can be used with all processes, throughout the development life cycle,
and across different implementation technologies
– UML is a semi-formal object-oriented modeling language (UML 2.0
added much more formality)
– UML is a communication tool – for the team, and other stakeholders.
– UML is used for modeling software systems; such modeling includes
analysis and design.
31
 Using UML
• Use graphical notation to communicate more clearly than natural
language (imprecise) and code(too detailed).
• Help acquire an overall view of a system.
• is not dependent on any one language or technology.
• Helps Analysis and Design
• provides a variety of diagrams for different purposes, like dynamic
or static system views .
• established (generally accepted) notational standard in the
software community.
• can be used on a general level, where implementation details are
suppressed.
• The UML is purely process independent, i.e., it is not tied up with
a SDLC (Software development life cycle) process.
32
 Contributions to the UML
Harel
Meyer Gamma, et al
Statecharts
Before and after Frameworks and patterns,
conditions
HP Fusion
Booch
Operation descriptions and
Booch method message numbering

Rumbaugh Embley
Singleton classes and
OMT
high-level view

Jacobson Wirfs-Brock
OOSE
Responsibilities

Shlaer - Mellor Odell

Object lifecycles Classification

33
 Topic 2: The 4+1 UML View

34
 The 4+1 UML View
Logical View Implementation
Class & Object Diagrams View
Interaction Diagrams Component Diagram
State Machine Diagram Interaction Diagrams
Analysts/
Activity Diagram State Machine Diagram
Designers End-user Activity Diagram Programmers
Structure Functionality Software management
Use-Case View

Process View Deployment

View
System Integrators System Engineering
Performance System topology
Scalability Delivery, installation
Throughput communication

35
 The Use Case View

•captures the basic requirements for the system and

provides the basis for the construction of the other views

•describes system behaviors that are seen by a specific

point of view, such as end users, analysts, designers,
and/or testers.

• A use-case describes an actor’s view of partial

functions of a software system. captures the static
structure of a system by use case diagrams, and
describes system dynamic behaviors by interaction,
statechart, and activity diagrams.
•contains a few key scenarios that are used to drive the
architecture and to validate it.

36
 The Logic View

The logical view describes functional requirements of a system that consists

of classes, interfaces, and collaborations. It is an abstraction of the design model,
identifying major design packages, subsystems and classes.

The static behaviors of the logic view are described by class and object
diagrams. The dynamic behaviors of the logic view are described by
interaction, statechart, and activity diagrams.
.

37
 The Process View
•The process view describes the performance, scalability, and throughput of a
system, which consists of tasks, threads, processes, and interactions.
•The static behaviors of the process view are described by class and object
diagrams. The dynamic behaviors of the process view are described by interaction,
statechart, and activity diagrams.
•The process view addresses the concurrent aspect of the system at run-time: tasks,
threads or processes, and their interactions.

38
 The Implementation View

The implementation view describes system

components, files, configuration, and
management.

The static behaviors of the implementation

view are described by UML component
diagrams. The dynamic behaviors of the
implementation view are described by
interaction, statechart, and activity diagrams.

39
 The Deployment View

• The deployment view describes system hardware

platform configuration and topology, such as
distribution, installation, and delivery of system
components.

The static behaviors of the deployment view are

described by deployment diagrams. The dynamic
behaviors of the deployment view are described by
interaction, statechart, and activity diagrams.
The deployment view shows how the various executables
and other run-time components are mapped onto the
underlying platforms or computing nodes.

40
 Summary

41
 Activity

42
 Quiz
1)Which of the following view captured by UML diagrams can be considered as black
box model of a system?
– structural view
– behavioral view
– user’s view
– environmental view
– implementation view
2)Which of the follow are not defined by UML?
– Static–Structure Diagrams.
– Text forms and tables.
– Class Diagrams.
– A Constraint Language
– Behavior Diagrams.
3)UML is a
– a language to model syntax
– an object-oriented development methodology
– an automatic code generation tool
– none of the above

43
 Lesson 3: UML diagrams

44
 Introduction

45
 Student Guide

46
 Objectives
• In this lesson, the following points will be
studied:
– Taxonomy of UML diagrams
– Structure diagrams … definitions, notations, usage
and examples
– Behavior diagrams … definitions, notations, usage
and examples
– Interaction diagrams … definitions, notations,
usage and examples

47
 UML diagrams

48
 Topic 1: Structure Diagrams

49
 UML diagrams: Structure Diagrams
• Structure Diagrams: define the static architecture of a model. They are used to
model the 'things' that make up a model – the classes, objects, interfaces and
physical components. In addition they are used to model the relationships and
dependencies between elements.
1. Class diagram: describe the static structure of a system, or how it is structured
rather than how it behaves. It shows the classes of the system, their inter-
relationships, and the operations and attributes of the classes.
2. Object diagram (dynamic): is a Class Diagram at one point in time. Whereas a class
model describes all possible situations, an object model describes a particular
situation.
3. Composite Structure: Depicts the internal structure of a classifier (such as a class,
component, or collaboration), including the interaction points of the classifier to
other parts of the system.
4. Component diagram: illustrate the organizations and dependencies among
software components.
5. Deployment diagram shows the configuration of run-time processing elements and the
software processes living on them. It visualizes the distribution of components across
the enterprise.
50
6. Package diagram :show how related classes are grouped together, for the benefit
of developers.
 Structure diagrams

51
 Class diagram
UML class diagrams show the classes of the system, their inter-relationships,
and the operations and attributes of the classes.
Class Diagrams describe the static structure of a system, or how it is structured
rather than how it behaves.
Developed by analysts, designers, and implementers

These diagrams contain the following elements.

• Classes, which represent entities with common characteristics or features.
These features include attributes, operations and associations.
• Associations, which represent relationships that relate two or more other
classes where the relationships have common characteristics or features.
These attributes and operations.
Each class is represented by a rectangle subdivided into three
compartments
– Name
– Attributes
– Operations

52
Class Diagram: Example

53
 Object Diagrams
•Object diagram: The object diagram is a special kind of class diagram. An
object is an instance of a class.
•This essentially means that an object represents the state of a class at a
given point of time while the system is running.
•The object diagram captures the state of different classes in the system
and their relationships or associations at a given point of time

•Object Diagrams describe the static structure of a system at a particular time.

•Whereas a class model describes all possible situations, an object model
describes a particular situation.
•Built during analysis and design
•Developed by analysts, designers, and implementers
•Object diagrams contain the following elements:
•Objects, which represent particular entities. These are instances of classes.
•Links, which represent particular relationships between objects. These are
instances of associations.

54
 Object Diagram
• Captures instances and links

55
 Component diagram
• The component diagram
– main purpose: is to show the structural relationships between the components of a system.
– Provides a physical view of the system software
– Component diagrams: show the software components that make up a larger piece of
software, their interfaces, and their interrelationships.
– Component diagrams illustrate the organizations and dependencies among software
components
– Explains the structure of a system
– Shows the dependencies that the software has on the other software components (e.g.,
software libraries) in the system
– Has a higher level of abstraction than a Class diagram - usually implemented by one or more
classes.
– A component is a modular, deployable, and replaceable part of the system
– A component may be
• any large-grain item, such as a common subsystem
• A source code component (java, h, cpp, ...)
• A run time components
• an executable binary component (exe, ...)
• libraries (dll, lib, class, ...)
56
• a commercial off-the-shelf (COTS) system,
 Component Diagram: Symbols and Notations
Components
• Components are shown as rectangles containing names with
rectangles on the side.

Dependencies
• Dashed lines with arrows between components indicate dependencies
• Interface
Circle and solid line indicates an interface to the component
• An interface describes a group of operations used or created by components. It
represents a declaration of a set of coherent public features and obligations,
similar to a contract.

57
 Component Diagram: example

order

customer

account

Order provides a component interface, which is a collection of one or

more methods with or without attributes.

Account and customer components are dependent upon the interface of

the order.
58
 Component Diagram: example

Figure A component diagram for the architectural of a

telecommunications company

59
 Component Diagram: example

60
 Component Diagram: example

61
 Composite structure diagram
• UML 2 Composite structure diagrams used to explore run-
time instances of interconnected instances collaborating
over communications links.
• Composite Structure Diagrams;
– depicts the internal structure of a classifier (such as a class,
component, or use case), including the interaction points of the
classifier to other parts of the system under runtime.
– reflects the internal collaboration of classes, interfaces or
components to describe a functionality.
– are similar to Class diagrams, except that they model a specific
usage of the structure.
– is used to express run-time architectures, usage patterns, and
the participating elements' relationships, which might not be
reflected by static diagrams.

62
 Composite structure diagram

63
 Deployment Diagram

64
 Deployment diagram
Deployment diagrams Captures the topology of a system’s hardware
, the software that is installed on that hardware, and the middleware
used to connect the disparate machines to one another.
• Built as part of architectural specification
• Purpose
– Specify the distribution of components
– Identify performance bottlenecks
• Developed by architects, networking engineers, and
system engineers
• The deployment diagram consists of nodes, which are shown by 3-D
boxes

65
 Deployment Diagram - Example

Desktop PC Desktop PC

<<Campus LAN>> <<Campus LAN>>

Registration
Server

<<Campus LAN>> <<Campus LAN>>

<<legacy>> <<legacy>>
Course Billing
Catalog System

66
 Package Diagram
• One idea is to group the classes together into higher-level units called
"Packages".
• Package diagram:
– Shows packages of classes and the dependencies among them.
– Package diagrams are most useful during the high-level design stages
in large software projects to describe system’s overall structure.
• Two classes are said to be dependent on each other if:
– changes made to one class causes changes to another class.
– A dependency is said to exist between two packages if any two classes
in the packages are dependent.
 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.

• Packages are the basic grouping construct with which you may organize
UML models to increase their readability
 Package Diagram: example

69
 Package Diagram: example
• Example : Package diagram for “Online Banking System”
• In the example, package “Online Banking UI” is said to depend on “GUI Library”
package because changes made to GUI library classes affect application’s user
interface.
• In a given bank system, customers can access their account details by using the
online facility provided by the bank. The user inputs the required authentication
information which is verified before giving access to the account information. The
user can then check the account balance, pay bills online, and transfer money from
the savings account to checking account.
• The above package diagram documents an abstract design of the software by
grouping related classes into packages. For example, the graphical user interface-
classes, which provide user input and output capabilities, are grouped into GUI
Library, while the security related classes are grouped into a Verification Engine
package. Note: The diagram just shows the interdependencies originating at the
Online Banking UI.

70
 Topic 2: Behavior Diagram

71
 Behavior Diagrams

72
 UML Diagrams: Behavior Diagrams

• Behavior Diagrams help to understand system functional requirements,

and Used to visualize, specify, construct, document dynamic aspects of
system
– Use Case Diagram - used by many methodologies (not just OO) during requirements.
It shows a set of use cases, and how actors can use them
– Activity Diagram shows flows among activities; this is a process flow
chart to show how your system functions. It focuses on processes and
organizations that perform them.
– Statechart Diagram shows a sequence of states that an object or an
interaction goes through during its lifetime, in response to events,
and also the responses that the given object or interaction makes to
those events.

73
 Use cases diagram
Use cases diagrams describes the behavior of the target system
from an external point of view. Use cases describe "the meat"
of the actual requirements.
• Use cases. A use case describes a sequence of actions that
provide something of measurable value to an actor and is
drawn as a horizontal ellipse.
• Actors. An actor is a person, organization, or external system
that plays a role in one or more interactions with your system.
Actors are drawn as stick figures.
• Associations. Associations between actors and use cases are
indicated by solid lines. An association exists whenever an
actor is involved with an interaction described by a use case.

74
 Use Case Diagram
• Captures system functionality as seen by users

75
 Example use case diagram
SimpleWatch

ReadTime

SetTime

WatchUser WatchRepairPerson

ChangeBattery

76
 Statechart Diagram
• Statechart (or state) diagrams describe the states and
responses of a class. Statechart diagrams describe the
behavior of a class in response to external stimuli.
• State Diagrams are another model in UML that allows to
actually describe the timing taking place in a software system.

• These diagrams contain the following elements:

• States, which represent the situations during the life of an object in
which it satisfies some condition, performs some activity, or waits
for some occurrence.
• Transitions, which represent relationships between the different
states of an object.

77
 Statechart Diagram
• The initial state is represented by a small black circle,
• intermediate states are represented by rounded
rectangles, and
• the final state is represented by a small black circle
surrounded by a white circle.
• Transitions are the arrows going from one state to
another.

78
 State chart Diagram example

state chart diagram of the class Book.

79
 Activity Diagram

• Activity diagrams are techniques to describe

procedural logic, business processes, and work flows
• Activity diagrams and statechart diagrams are related.
• While a statechart diagram focuses attention on an
object undergoing a process, an activity diagram
focuses on the flow of activities involved in a single
process.
• The activity diagram shows the how those activities
depend on one another.
• is commonly used to show the actions/steps involved in
carrying out a particular use-case.

80
 Activity Diagrams Notations
• Initial node:
– The filled in circle is the starting point of the diagram. An initial node
isn’t required although it does make it significantly easier to read the
diagram.
– Symbol:

• Activity final node:

– The filled circle with a border is the ending point. An activity diagram
can have zero or more activity final nodes.
– Symbol:

81
 Activity Diagrams Notations
• Activity
– 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 Diagrams Notations
• Parallel Activities:
• Fork
– A black bar with one flow going into it and several leaving it. This
denotes the beginning of parallel activity. When the incoming
transition is triggered, all of the outgoing transitions are taken in
parallel.
– Symbol:

• Join
– A black bar with several flows entering it and one leaving it. This
denotes the end of parallel processing.
– Symbol:

83
 Fork example

84
 Join Example

85
 Activity Diagrams Notations
• Branch:
– Also called 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.
• Guard Condition:
– Text such as [Incorrect Form] on a flow, defining a guard
which must evaluate to true in order to traverse the node.
– This node is used to represent the actual test condition that
is used to determine which of the paths exiting the decision
node is to be traversed.
Merge:
– A diamond with several flows entering and one leaving. The
implication is that all incoming flows must reach this point
until processing continues.
86
 Activity Diagrams Notations
• Partition.
– Also called swimlanes, indicating
who/what is performing the activities
– Are used to group actions according
to the organization or class
responsible for those actions.
– Are divided by solid vertical lines.
– Can be used in the context of
concurrency.
– An activity can only belong to one
partition, but transitions between
actions may cross partitions.
 Swimlane example

88
 activity diagram example

89
 Topic 3: Interaction Diagrams

90
 Interaction diagrams

91
 UML diagrams: Interaction diagrams
• Interaction diagrams: These diagrams represent how flow of data and control takes
place in the system that is being modeled. They are a subset of the Behavioral
Diagrams. These include:

– Sequence Diagram focuses on the time-ordering of messages between

objects.
Can have top level System Sequence Diagram, then more specific Sequence
Diagrams
– Communication Diagrams (Collaboration diagrams in UML 1); a way
to show how objects are linked together and how messages are sent between
them
Interaction Overview diagrams; a mix of sequence diagrams and activity
diagrams
Timing diagrams shows the behavior of the objects in a given period of time..

92
 Sequence Diagrams
Sequence Diagrams describe interactions among classes.
These interactions are modeled as exchange of messages.
These diagrams focus on classes and the messages they exchange to
accomplish some desired behavior.
Sequence diagrams are a type of interaction diagrams. Sequence diagrams
contain the following elements:
• Class roles, which represent roles that objects may play within the
interaction.
• Lifelines, which represent the existence of an object over a period of time.
• Activations, which represent the time during which an object is performing an
operation.
• Messages, which represent communication between objects.

93
 Sequence Diagram

94
 Collaboration Diagram
• Collaboration Diagrams :
– a type of interaction diagram
– A collaboration diagram shows both structural and behavioral aspects
explicitly.
– In this diagram, an object is also called a collaborator.
– The structural aspect of a collaboration diagram consists of objects and
the links existing between them.
– unlike a sequence diagram which shows only the behavioral aspects.
– The behavioral aspect is described by the set of messages exchanged
among the different collaborators.
• Collaboration Diagrams are useful for showing how groups of objects work
together to perform a piece of functionality required for one path through
a Use Case.
• The benefit of collaboration diagrams is showing how groups of objects
work together to perform a piece of functionality required for a particular
use case or scenario
95
 Collaboration diagram: notations
• Represents a Collaboration and Interaction
• Collaboration
– set of objects and their interactions in a specific context
• Interaction
– – set of messages exchanged in a collaboration to produce a desired result
Objects
– rectangles containing the object signature
– object signature: object name : object Class
• object name (optional) - starts with lowercase letter
• class name (mandatory) - starts with uppercase letter
– objects connected by lines
– user (stick man) can appear
• Messages
The message is shown as a labeled arrow placed near the link. Messages are prefixed with sequence numbers because they are only way to describe
the relative sequencing of the messages in this diagram

96
 Collaboration Diagram: example

97
 Interaction overview diagram
• UML 2 Interaction overview diagrams
– focuses on the overview of the flow of control of
the interactions.
– It is a variant of the Activity Diagram where the
nodes are the interactions or interaction
occurrences.
– It describes the interactions where messages and
lifelines are hidden.

98
 Interaction overview diagram
• Interaction Overview Diagrams
– Provide overview of use case interactions
– Created to show relationship of interaction diagrams
in a complex use case
• use when:
– more than one interaction diagram per use case
– the overview diagram helps in understanding the
relationship between use cases and interactions
• Combined notation
– Sequence Diagrams
– Activity Diagrams

99
 Interaction overview diagram

100
 Interaction overview diagram

101
 Interaction Overview Diagram
• Careful – this is different from the ‘interaction
diagram’
– An interaction diagram is a sequence or
collaboration diagram
• An Interaction Overview diagram is a blend of
the activity diagram with several interaction
diagrams
– New for UML 2

102
 Interaction Overview Diagram
• Start with an activity diagram
• Replace the activity boxes with really big
boxes which contain an interaction diagram
for each activity
• This is the reason for some of the odder
‘operators for interaction frames’ on page 59
– We used ‘alt’, ‘loop’, and ‘opt’ earlier

103
 Interaction Overview Diagram
• Example is on page 148
• This diagram might be helpful for a process
with several simple options

104
 UML 2.0 Diagram Summary

105
 Summary

106
 Activity

107
 Quiz
1) In the context of use case diagram, the stick person icon is used to represent
– human users
– external systems
– internal systems
– none of the above
2) When should you use an interaction diagram?
– When you want to look at the behavior of several objects within a single use case or several
use cases
– They are good to look at behavior of a single object across many use cases.
– When you need to look at the relationships between objects.
– They are good at showing sequence of messages among objects.
– None of the above.
3)The interaction diagrams can be effectively used to describe how the behavior of an
object changes across several use case. Ans.: - False.
4)A Deployment Diagram may show which of the following?
– The configuration of hardware nodes.
– The allocation of software components to hardware nodes.
– The allocation of objects to software components.
– None of the above

108
 Module Summary

109
 Module Assessment
• Why is UML important for me to learn?
– It’s an official standard of the International Standards Organization (ISO).
– It’s the defacto industry standard language for business modeling, software analysis, and software design.
– It requires me to completely and unambiguously specify my design.
– It is a graphical representation of Object Oriented languages such as C++ and Java
• For any given problem, one should construct all the views using all the diagrams provided by UML. Ans:False.
• The terms method and operation are equivalent concepts and can be used interchangeably. Ans.: - False.
• Normally, you use an interaction diagram to represent how the behavior of an object changes over its life time. Ans.: - False.
• The chronological order of the messages in an interaction diagram cannot be determined from an inspection of the diagram.
Ans.: - False.
• Which of the following are true statements about objects and classes?
– Objects and classes are the same thing.
– A class is a reusable description of objects.
– A class defines the attributes, operations, methods, relations, and semantics of some objects.
– A class is an instance of an object.
– An object is an instance of a class.
• When should you use an interaction diagram?
– When you want to look at the behavior of several objects within a single use case or several use cases
– They are good to look at behavior of a single object across many use cases.
– When you need to look at the relationships between objects.
– They are good at showing sequence of messages among objects.
– None of the above.
• Which of the following are true statements about Sequence Diagram and Collaboration Diagram?
– Sequence Diagram and Collaboration Diagram can both be used to describe the interactions between objects.
– Sequence Diagram and Collaboration Diagram show the same information.
– A Sequence Diagram shows the ordering of messages more clearly.
– A Collaboration Diagram shows the links between objects and a Sequence Diagram does not.
– A Collaboration Diagram always shows messages.
110
 Glossary

111
 References

112