The document discusses object-oriented analysis and design (OOAD) and the Unified Modeling Language (UML). It describes the key concepts in OOAD like analysis, design, domain modeling, use cases, interaction diagrams, and class diagrams. It then explains the basic building blocks of UML including things (classes, interfaces etc.), relationships (generalization, association etc.), and diagrams (class, sequence etc.). The rest of the document provides details on modeling classes in UML including attributes, operations, responsibilities and visibility.
2. OOP/OOAD/UML/najit/2
Analysis & Design
• Analysis emphasizes an investigation of the
problem and requirements
• i.e. requirement analysis is an investigation of
the requirements and object analysis is an
investigation of domain objects
• Design emphasizes a conceptual solution that
fulfills requirements, ultimately the design
may be implemented.
3. OOP/OOAD/UML/najit/3
OO analysis & Design
• During object oriented analysis emphasizes on
finding and describing the objects in the problem
domain
• Examples: in case of library information system,
some of the objects include Book, Library etc.
• During Object Oriented Design emphasizes on
defining software objects and how they collaborate to
fulfill the requirements
• Example: in the library system, a Book software
object may have a title attribute and a getChapter ()
method
• Finally, during implementation the objects are
implemented, such as a Book class in C++
5. OOP/OOAD/UML/najit/5
OOAD
• The steps for object oriented analysis and
design may be as follows
– Define Usecases
– Define domain model
– Define interaction diagram
– Define design class diagram
6. OOP/OOAD/UML/najit/6
Example
• A “Dice Game” : A player rolls two die
• Usecase: description of related domain
process
– Play a Dice Game: A player picks up and rolls the
dice. If the dice face value total seven, they win;
otherwise, they lose
• Define domain model: Decomposition of the
domain involves identification of objects,
attributes and associations.
– Represented in a diagram
8. OOP/OOAD/UML/najit/8
Define Interaction diagram
• Defining software objects and their collaborations.
• This diagram shows the flow of message between
software objects and thus invocation of methods
:DiceGame die2:Diedie1:Die
play()
roll()
fv1:=getFaceValue()
roll()
fv2:=getFaceValue()
9. OOP/OOAD/UML/najit/9
Define design class
diagrams
• To create a static view of the class definition with a
design class diagram.
• This illustrates the attributes and methods of the
classes.
DiceGame
Die1:Die
Die2:Die
Play()
Die
faceValue: int
getfaceValue():int
roll()
1 2
10. OOP/OOAD/UML/najit/10
• To represent the analysis and design of
object oriented software systems, we use a
language called Unified Modeling
Language.
11. OOP/OOAD/UML/najit/11
UML
• The Unified Modeling Language™ (UML) is the
industry-standard language for specifying,
visualizing, constructing, and documenting the
artifacts of software systems
• It simplifies the complex process of software
design, making a "blueprint" for construction.
• The Unified Modeling Language, UML, and the
UML logos are trademarks of the Object
Management Group.
• www.omg.org
12. OOP/OOAD/UML/najit/12
Purpose of Modeling?
• Developing a model for an industrial-strength
software system prior to its construction or
renovation is as essential as having a blueprint
for large building.
• Good models are essential for communication
among project teams and to assure
architectural soundness.
• As the complexity of systems increase, so
does the importance of good modeling
techniques. There are many additional factors
of a project's success, but having a rigorous
modeling language standard is one essential
factor.
13. OOP/OOAD/UML/najit/13
References
• Books
– The Unified Modeling Language, User Guide
• Booch, Rumbaugh. Jacobson ( TEXT )
– The Unified Modeling Language, Reference Manual
• Booch, Rumbaugh. Jacobson
– The Unified Software Development Process
• Booch, Rumbaugh. Jacobson
– Using UML
• Rob Pooley et al.
– UML Distilled
• Martin Fowler, Kendall Scott
– Instant UML
• Pierre-Alain Muller
16. OOP/OOAD/UML/najit/16
A. Structural Things
• These are nouns of UML model
• These things represents elements that are
either conceptual or physical.
• There are seven kinds of structural things
– Class
– Interface
– Collaboration
– Use Case
– Active Class
– Component
– Node
18. OOP/OOAD/UML/najit/18
Interface
• Is a collection of operations that
specify a service of a class
• An interface might represent the
complete behaviour of a class or only a
part of that behaviour
• It is represented by a circle, with its
name
ISpelling
Interface spelling
19. OOP/OOAD/UML/najit/19
Collaboration
• Defines an interaction and is a society
of roles and other elements that work
together to provide some cooperative
behaviour
• It is represented by an dashed ellipse
with its name
Chain of
Responsibilities
20. OOP/OOAD/UML/najit/20
Use Case
• It is a description of sequence of
actions that a system performs that
yields an observable result of a value
to a particular actor
• It is represented by a solid ellipse
with its name
Place Order
Use case
Actor
21. OOP/OOAD/UML/najit/21
Active Class
• It is a class, whose objects own one or
more processes or threads and
therefore can initiate control activity
• It is represented by a heavy lined box
EventManager
suspend()
flush()
22. OOP/OOAD/UML/najit/22
Component
• It is a physical and replaceable part of
a system that confirms to and
realization of a set of interfaces.
• i.e. physical packaging of classes,
interfaces and collaborations
Orderform.cpp
23. OOP/OOAD/UML/najit/23
Node
7. It is a physical element that exists in
run time and represents a
computational resource, generally
having some memory and processing
capability
8. A set of components may reside as a
node and may also migrate from node
to node
9. It is represented as a cube
Server
24. OOP/OOAD/UML/najit/24
B. Behavioural Things
• These are dynamic parts of UML model
• These are verbs of a model,
representing behaviour over time and
space
• There are two types of Behavioural
things
– Interaction
– State Machine
25. OOP/OOAD/UML/najit/25
Interaction
1. It is a behaviour that comprises a set
of messages exchanged among a set of
objects to accomplish a specific
purpose.
2. An interaction involves messages,
action sequences and links. (connection
between objects)
3. It is represented by a solid arrow
Display
26. OOP/OOAD/UML/najit/26
State Machine
• It is a behaviour that specifies the
sequence of states of an object or an
interaction goes through during its life time
in response to events, to gether with its
responses to these events.
• A state machine involves
• States
• Transitions (flow from one state to another)
• Events (things that trigger a transition)
• Activities (response to transitions)
• It is represented with a rectangular box having
rounded corners
Waiting
27. OOP/OOAD/UML/najit/27
C.Grouping Things
• These are organizational part of UML
models
• There is one primary kind of grouping
thing called packages
• Package
– It is a general purpose mechanism for
organizing elements in to groups
– It is rendered as a tabbed folder
Business rules
28. OOP/OOAD/UML/najit/28
D. Annotational Things
• These are explanation parts of UML
• Note is a annotational thing called
• Note
– It is simply a symbol for rendering
constraints and comments attached to an
element or a collection of elements.
Return copy
Some
explanatory text
31. OOP/OOAD/UML/najit/31
A. Dependency
• It is a semantic relationship between two
things in which a change to independent
thing may affect the semantic of the other
thing
• It is rendered as a directed dashed line
FormSystem
dispForm(..)
•The form the system displays obviously
depends on which form the user selects
32. OOP/OOAD/UML/najit/32
B. Association
• It describes a set of links
– Aggregation is a special kind of
association, representing a structural
relationship between a whole and its parts
– It is rendered as a solid line, occasionally
including a label and other specifications
Employer Employee
0..1 *
33. OOP/OOAD/UML/najit/33
C. Generalization/Specialization
• Child shares the structure and
behaviour of the parent
Objects of specialized elements are
substitutable for the objects of
generalized elements
It is rendered as a solid line with a hollow
arrow head pointing to the parent
ShapeCircle
34. OOP/OOAD/UML/najit/34
D. Realization
• It is a relationship between
classifiers. (polymorphism)
One classifier specifies a contract that
another classifier guarantees to carry out
It is rendered as a dashed line with a
hollow arrow head.
The base class provides an interface for
which the derived class writes an
interface
36. OOP/OOAD/UML/najit/36
Diagrams
• There are 9 types of Diagrams
– Class Diagram
• Shows a set of classes, interfaces, and
collaborations and their relationships.
– Object Diagram
• Shows a set of objects and their relationships
– Use Case Diagram
• Shows a set of use cases and actors
– Sequence Diagram & Collaboration
Diagram
• These two are interaction kind of diagram.
They show a set of objects and their
relationships
37. OOP/OOAD/UML/najit/37
Diagrams
– Statechart Diagram
• Shows a state machine, consisting of states,
transitions, events and activities
– Activity Diagram
• It is a kind of statechart diagram that shows
the flow from activity to activity with a system
– Component Diagram
• Shows the organisation and dependencies among
a set of componets. It addresses the static
implementation views of a system
– Deployment Diagram
• Shows the configuration of run-time processing
nodes and the components that live on them.
38. OOP/OOAD/UML/najit/38
Classes
• A class is a descriptions of a set of
objects, that share attributes,
relationships and semantics.
• Graphically a class is rendered as a
rectangle
• Name of a class
– In practice class names are short nouns or
noun phrases drawn from the vocabulary of
the system to be modeled
– Every class has a name that distinguishes it
from other classes
39. OOP/OOAD/UML/najit/39
Name of a class
– Name is a textual string, with first letter
of every word capitalized
• Examples
Customer WashingMachine
Class name
HouseholdAppliances : : WashingMachine
•A path name is the class name prefixed
by the name of the package in which that
class lives
40. OOP/OOAD/UML/najit/40
Attributes of a Class
• An attribute is an abstraction of the
kind of data or state an object of the
class might encompass
• An attribute is a named property of a
class
• A class may have any
number of attributes or
no attributes at all
Customer
name
address
phone
birthDate
attributes
41. OOP/OOAD/UML/najit/41
Attributes of a Class
• Attributes are listed in a compartment
just below the class name
• First letter of every word is capital in an
attribute name expect the first word
• An attribute may be specified by stating
its class and possibly default initial value
• In practice an attribute name is a short noun
or noun Phrase that represents some property
of its enclosing class
43. OOP/OOAD/UML/najit/43
Operations in a Class
• An operation is an abstraction of
something, one can do to at an object
and that is shared by all objects of that
class
• A class may have any no. of operations
or no operations at all
• Operation are listed in a Compartment
just below The class attribute
44. OOP/OOAD/UML/najit/44
Operations in a Class
• The first letter of every word in an
operations name is capital, except the
first letter of first word
• An operations can be specified By
stating its signature, covering the
name, type and default values of all
parameters and a return type
• In practice, an operation name is a short
verb or verb phrase that represents
some behavior of its enclosing class
46. OOP/OOAD/UML/najit/46
Organising Attributes and
Operations
• It may not be possible to list all attributes
and operations at once
• Therefore, a class can be elided, I.e. it is
possible to show only some or none of
attributes and operations
• An empty compartment does not necessarily
mean that there are no attributes or
operations
• It can be explicitly specified that there are
more attributes or operations than shown, by
ending each list with an ellipsis.
47. OOP/OOAD/UML/najit/47
Attributes & Operations
• To better organise long lists of attributes and
operations, those can be grouped.
• Each group is prefixed with a descriptive
category by using stereotypes
WashingMachine
brandName
. . .
addClothes()
. . .
Ellipsis shows
there are some
more attributes
and operations
49. OOP/OOAD/UML/najit/49
Responsibilities
• It is a contract or an obligation of a
class. i.e it is a description of what the
class has to do
• Responsibilities can be drawn in a
separate compartment at the bottom of
the class icon
• A single responsibility is written as a
phrase, a sentence, or (at most) a short
paragraph (free-form text)
51. OOP/OOAD/UML/najit/51
Visibility of a feature
• It allows to specify the visibility for a
classifier’s features.
• Three levels of visibility can be
specified using UML
– Public : any outside classifier with visibility
to the given classifier can use the feature;
specified by prepending the symbol +
– Protected : Any descendant of the
classifier can use the feature; specified by
prepending the symbol #
– Private : only the classifier itself can use
the feature; specified by prepending the
symbol -
53. OOP/OOAD/UML/najit/53
Scope of a feature
• The owner scope of a feature specifies
whether the feature appears in each
instance of the classifier or whether
there is just a single instance for all
instances of the classifier
• UML provides two kinds of scope
– Instances : Each instance of the classifier
holds its own value for the feature
– Classifier : There is just one value of the
feature for all instances of the classifier.
54. OOP/OOAD/UML/najit/54
Scope (Contd.)
• Classifier scope is rendered by
underlining the feature
• In C++ we call the class scoped as
static members of a class
Frame
header:frameHeader
uniqueID:Long
Instance scope
Class scope
55. OOP/OOAD/UML/najit/55
Polymorphic Elements
• Abstarct Class
– Class having no direct instances (italics)
• Concrete Class
– Class that may have direct instances
• Root Class
– Class having no parent but may have
children {root}
• Leaf Class
– Class having parent but no children {leaf}
56. OOP/OOAD/UML/najit/56
Polymorphic Elements
• Polymorphic Operations
– An operation is polymorphic, if it can be specified
with the same signature at different points of
hierarchy
– When a message is dispatched at run time, the
operation in the hierarchy that is invoked is chosen
polymorphycally. i.e. a match is determined at run
time according to the type of the object
• Abstract Operation
– This operation is incomplete and requires a child to
supply an implementation. In UML it is specified by
writing its name in italics.
• Leaf operation
– Operation is not polymorphic and may not be
overridden
58. OOP/OOAD/UML/najit/58
Multiplicity
• It is a specification of the range of allowable
cardinalities an entity may assume
• Multiplicity of a class
– It is used to restrict the no of instances of
a class
– i.e. It tells the no of instances a class may
have
• Multiplicity of an attribute
– It is used to represent a set of elements for
an attribute
– i.e. It maps to representing an array variable
in C++
60. OOP/OOAD/UML/najit/60
Attributes
• In its full form, the syntax of an
attribute in UML is
[visibility] name [multiplicity] [: type]
[ = initial-value] [{property-string}]
Examples :
origin
+origin
origin : Point
head : *Item
name [0..1] : String
Name Only
Visibility and name
Name and type
Name and complex type
Name, multiplycity, and type
61. OOP/OOAD/UML/najit/61
Attributes
• There are three defined properties,
that can be used with attributes
– changeable
• There are no restrictions on modifying the
attribute value
– addonly
• For attributes with a multiplicity greater than
one, but once created, a value may not be
removed or altered
– frozen
• The attribute’s value may not be changed after
the object is initialized(constants)
62. OOP/OOAD/UML/najit/62
Operations
• In its full form, the syntax of an
operation in UML is
[visibility] name [(parameter-list)] [: return-type]
[{property-string}]
Examples
display
+display
set (n : Name, s : String)
getID ( ) : Integer
restart () {guarded}
Name Only
Visibility and name
Name and parameters
Name and return type
Nameand property
63. OOP/OOAD/UML/najit/63
Operation Parameters
• An operation again can be provided with
zero or more parameters with following
syntax
[direction] name : type [= default-value]
• Direction may be any of the following
– in : An input parameter, may not be
modified
– out : An output parameter, may be modified
to communicate information to the caller
– inout : An input parameter, may be modified
64. OOP/OOAD/UML/najit/64
Operation Properties
• In addition to leaf property described earlier
there are four other properties defined as
follows
– isQuery : It is a pure function that has no side
effects (states unchanged)
– sequential : callers must coordinate outside the
object so that only one flow is in the object at a
time
– guarded : integrity of the object is guaranteed in
the multiple flow of control by sequentializing all
calls
– concurrent : integrity of the object is guaranteed
in the presence of multiple flows of control by
treating the operation as atomic
65. OOP/OOAD/UML/najit/65
Template Classes
• Template is a parameterized element
• Template class define a family of classes
• A Template includes slots for classes, objects
and values, and these slots serve as the
template parameter
• Instance of a template class is a concrete
class that can be used just like any ordinary
class
• The most use of template class is to specify
containers that can be instantiated for
specific elements.
66. OOP/OOAD/UML/najit/66
Template Classes
Map
+bind(in i : Item, in v : Value) : Boolean
+isBound(in i: Item):Boolean {isQuery}
Item
Value
Buckets : int
Map<Customer, Order, 3>
Implicit binding
<<bind>>(Customer, Order,3)
Explicit binding
OrderMap
template class
template parameters
67. OOP/OOAD/UML/najit/67
Stereotypes for Class
• The UML defines four standard
sterotypes that apply to classes
– Metaclass : specifies a classifier whose
objects are all classes
– Powertype : specifies a classifier whose
objects are the children of a given parent
– Stereotype : classifier is a stereotype that
may be applied to other elements
– Utility : specifies a class whose attributes
and operations are all class scoped
68. OOP/OOAD/UML/najit/68
Relationships
• A relationship is a connection among
things
• A relationship is rendered as a path,
with different kinds lines
• Dependency
– It is a using relationship that states that a
change in specification of one thing may
affect another thing that uses it; but not
necessarily the reverse
– It is rendered as a dashed directed line
70. OOP/OOAD/UML/najit/70
Dependency
• There are 8 stereotypes that apply to
dependency relationship
– 1. Bind : specifies that the source
instantiates the target template using the
given actual parameters
Set
insert(T)
remove(T)
T
EmployeeSet
<<bind>><Employee>
T is a placeholder for
type parameter
71. OOP/OOAD/UML/najit/71
Dependency
– 2. Derive : specifies that source may be
computed from target
Account
/balance : money
Entry
amount : money
/entries
{balance = sum of amount of entries}
derived attribute Derived association
72. OOP/OOAD/UML/najit/72
Dependency
– 3. friend : specifies that source is given
special visibility into the target
CourseSchedule
Add(c:Course)
Remove(c: Course)
Iterator
Iterator can visualize CourseSchedule
But the reverse may not be true
<<friend>>
73. OOP/OOAD/UML/najit/73
Dependency
– 4. instanceOf : specifies that source object
is an instance of target classifier
– 5. Instantiate : specifies that the source
creates instances of the target
Student jack:Student<<instanceOf >>
Stack
T
IntStack
<<instantiate>>
74. OOP/OOAD/UML/najit/74
Dependency
– 6. powertype : specifies that target is a powertype
of the source;
• A powertype is a classifier whose objects are all the
children of a given parent
– 7. Refine : specifies that source at a finer degree
of abstraction than the target
– 8. Use : specifies that the semantics of the source
element depends on the public part of the target
complex
Complex
real : double
img : double
<<refine >>
75. OOP/OOAD/UML/najit/75
Dependency
• There are two stereotypes that apply to
dependency relationship among packages
– 1. Access : specifies that the source
package is granted the right to reference
the elements of the target package
– 2. Import : it is a kind of access that
specifies that the public contents of the
target package enter the flat namespace of
the source, as if they had been declared in
the source
76. OOP/OOAD/UML/najit/76
Dependency
• There are two stereotypes that apply to
dependency relationship among use cases
– 1. external : specifies that the target use
case extends the behaviour of the source
– 2. include : specifies that the source use
case explicitly incorporates the behaviour
of another use case of a location specified
by the source
77. OOP/OOAD/UML/najit/77
Dependency
• There are three stereotypes that apply
to objects
– 1. become : specifies that the target is the
same object as the source but at a later
point in time and with possibly different
values, sate or roles
– 2. call : specifies that the source operation
invokes the target operation
– 3. Copy : specifies that the target object is
an exact, but independent copy of the
source
78. OOP/OOAD/UML/najit/78
Dependency
• There is one stereotype that apply to
state machines
– Send : specifies that the source operation
sends the target event
• There is one stereotype that apply to
subsystems
– trace : specifies that the target is an
historical ancestor of the source
SalesManagement
{version=7.1}
SalesManagement
{version=7.2}
<<trace>>
79. OOP/OOAD/UML/najit/79
Generalization
• It is a relationship between a general
thing (super type) and a more specific
kind of that thing (sub type)
• Objects of the child is substitutable
for the parent, but not the reverse
• An operation of a child that has the
same signature as an operation in a
parent overrides the operation of the
parent
• It is rendered as a solid directed line
with a large open arrow head
81. OOP/OOAD/UML/najit/81
Generalization
• There is one stereotype that apply to
generalization
– implementation : specifies that the child
inherits the implementation of the parent,
but does not make public nor support its
interface, thereby violating substitutability
– It maps to private inheritance in C++
• Four standard constraints that apply to
generalization
– 1. complete : specifies that all children in
the generalization have been specified and
no additional children are permitted
82. OOP/OOAD/UML/najit/82
Generalization
– incomplete : specifies that not all children
in the generalization have been specified
and additional children are permitted
Person
Male Female
Employee
Manager Engineer
{complete} {incomplete}
83. OOP/OOAD/UML/najit/83
Generalization
• Rest two applies for multiple inheritance
– 3. disjoint : specifies that objects of
parent may have no more than one of the
children as a type
– 4. Overlapping : specifies that objects of
parent may have more than one of the
children as a type
– More than one subtype can be a type for an
instance
84. OOP/OOAD/UML/najit/84
Association
• It is a structural relationship that
specifies that objects of one thing are
connected to objects of another thing
• An association has name, role and
multiplicity
– Name : used to describe the relationship
– Role : Each class plays a role in an
association
– Multiplicity : it tells how many objects may
be connected across an instance of an
association
86. OOP/OOAD/UML/najit/86
Association
• Properties of Association
– Navigation : Given an association between
two classes, it is possible to navigate from
object of one kind to object of other
– i.e. Given a book you can find out the library
and vice-versa
– If not specified, then an association is bi-
directional
Book Library
User Password
87. OOP/OOAD/UML/najit/87
Association
– Visibility : Given an association between two
classes, objects of one class can see and
navigate to objects of the other.
UserGroup PasswordUser
-key
+user +owner
Association visibility
– Given a user group, it is possible to find out a
user but not the password
–This visibility can be limited across
association by giving a visibility symbol to a
role name
88. OOP/OOAD/UML/najit/88
Association
– Qualification : It is required to choose the
object at the other end in case of a one-
many relation
1 *
Clerk ReservationConfirmation#
finds
– I.e. the first class has to rely on a specific
attribute to find the target object
– The ID information is called the qualifier
89. OOP/OOAD/UML/najit/89
Association
– Interface specifier : In the context of
association, as source class may choose to
present only one part of its face to the
world
Person
1
*
supervisor:IManager
worker : IEmployee
Interface specifier
– A person may realize many interfaces like
Imanager, Iemployee, and so on …
– Person in the role of supervisor presents only
Imanager face to the worker.
90. OOP/OOAD/UML/najit/90
Aggregation
• It is a whole/part relationship
• one class represents a larger thing and
it consists of smaller things (has a )
• It is a special kind of association and is
specified by plane association with an
open diamond at the whole end
CompanyDepartment
* 1
92. OOP/OOAD/UML/najit/92
Composition
• Composition is a special form of
aggregation
• Composite must manage the creation
and destruction of its parts
Window
Frame
whole
part
• When an window object is destroyed,
the frame objects is also destroyed
93. OOP/OOAD/UML/najit/93
Association classes
• In an association between two classes,
the association itself might have some
properties
Company Person
Job
desc.
date
salary
* 1..*
Employer Employee
Association class
94. OOP/OOAD/UML/najit/94
Association
• There are five constraints that apply to
association
– Implicit : specifies that the relationship is not
manifest but, rather, is only conceptual
A B
X Yabc
abc
{implicit}
• Association between two base classes specify
that same association between children of
these classes
95. OOP/OOAD/UML/najit/95
Association constraints
– Ordered : specifies that the set of objects
at one end of an association are in an
explicit order
User Password
Owner key
{ordered}
– Passwords associated with the user might
be kept in a least-recently user order
– Changeable : links between objects may be
added, removed and changed freely