OODP - Unit - I - UML Diagram

SRM INSTITUTE OF SCIENCE AND TECHNOLOGY,
RAMAPURAM CAMPUS
Unit I
UML DIAGRAMS
Dr.S.Veena,Associate Professor/CSE 1
Introduction to OOAD with OO Basics
Definition of OOP Concepts in Java
• Object-oriented Programming (OOP) is a programming paradigm
based upon objects (having both data and methods) that aims to
incorporate the advantages of modularity and reusability.
• The important features of object–oriented programming are:

– Bottom–up approach in program design
– Programs organized around objects, grouped in classes
– Focus on data with methods to operate upon object’s data
– Interaction between objects through function
– Reusability of design through creation of new classes by adding features
to existing classes
– Some examples of object-oriented programming languages are C++, Java,
Smalltalk, Delphi, C#, Perl, Python, Ruby, and PHP.
Basic Terminologies of Object Oriented Systems
Object
• An object is a real-world element in an object–oriented
environment that may have a physical or a conceptual existence.
• Each object has:
– Identity that distinguishes it from other objects in the system.
– State that determines the characteristic properties of an object as well as
the values of the properties that the object holds.
– Behavior that represents externally visible activities performed by an
object in terms of changes in its state.
• Objects can be modelled according to the needs of the
application.
• An object may have a physical existence, like a customer, a car, etc.; or
an intangible conceptual existence, like a project, a process, etc.
Class
• A class represents a collection of objects having same characteristic properties that exhibit
common behaviour.
• It gives the blueprint or description of the objects that can be created from it.
• Creation of an object as a member of a class is called instantiation. Thus, object is an instance of a
class.
• The constituents of a class are:
– A set of attributes for the objects that are to be instantiated from the class. Generally, different objects of a class have
some difference in the values of the attributes. Attributes are often referred as class data.
– A set of operations that portray the behaviour of the objects of the class. Operations are also referred as functions or
methods.
Example
• Let us consider a simple class Circle, that represents the geometrical figure circle in a two–dimensional
space. The attributes of this class can be identified as follows:
– x–coord, to denote x–coordinate of the center
– y–coord, to denote y–coordinate of the center
– a, to denote the radius of the circle
• Some of its operations can be defined as follows:
– findArea(), method to calculate area
– findCircumference(), method to calculate circumference
– scale(), method to increase or decrease the radius
Encapsulation
• Encapsulation is the process of binding both attributes and
methods together within a class.
• Through encapsulation, the internal details of a class can be
hidden from outside.
• It permits the elements of the class to be accessed from outside
only through the interface provided by the class.
Data Hiding
• Typically, a class is designed such that its data (attributes) can
be accessed only by its class methods and insulated from
direct outside access.
• This process of insulating an object’s data is called data hiding
or information hiding.
Message Passing
• Objects in a system may communicate with each
other using message passing.
• Suppose a system has two objects: obj1 and obj2. The object
obj1 sends a message to object obj2, if obj1 wants obj2 to
execute one of its methods.
• The features of message passing are:
– Message passing between two objects is generally unidirectional.
– Message passing enables all interactions between objects.
– Message passing essentially involves invoking class methods.
– Objects in different processes can be involved in message
passing.
Inheritance
•Inheritance is the mechanism that permits new classes to be created out of existing
classes by extending and refining its capabilities.
•The existing classes are called the base classes/parent classes/super-classes, and
the new classes are called the derived classes/child classes/subclasses.
•The subclass can inherit or derive the attributes and methods of the super-
class(es) provided that the super-class allows so.
•Besides, the subclass may add its own attributes and methods and may modify any
of the super-class methods. Inheritance defines an “is – a” relationship.
Types of Inheritance
•Single Inheritance : A subclass derives from a single super-class.
•Multiple Inheritance : A subclass derives from more than one super-classes.
•Multilevel Inheritance : A subclass derives from a super-class which in turn is derived
from another class and so on.
•Hierarchical Inheritance : A class has a number of subclasses each of which may have
subsequent subclasses, continuing for a number of levels, so as to form a tree structure.
•Hybrid Inheritance : A combination of multiple and multilevel inheritance so as to form a
lattice structure.

Polymorphism
• Polymorphism is originally a Greek word that means the ability to take
multiple forms.
• In object-oriented paradigm, polymorphism implies using operations in
different ways, depending upon the instance they are operating upon.
• Polymorphism allows objects with different internal structures to
have a common external interface.
• Polymorphism is particularly effective while implementing inheritance.
Example
• Let us consider two classes, Circle and Square, each with a method
findArea(). Though the name and purpose of the methods in the classes
are same, the internal implementation, i.e., the procedure of calculating
area is different for each class. When an object of class Circle invokes its
findArea() method, the operation finds the area of the circle without any
conflict with the findArea() method of the Square class.
Generalization and Specialization

• Generalization and specialization represent a hierarchy of relationships
between classes, where subclasses inherit from super-classes.
Generalization
• In the generalization process, the common characteristics of classes are
combined to form a class in a higher level of hierarchy, i.e., subclasses are
combined to form a generalized super-class. It represents an “is – a – kind – of”
relationship. For example, “car is a kind of land vehicle”, or “ship is a kind of water
vehicle”.
Specialization
• Specialization is the reverse process of generalization. Here, the distinguishing
features of groups of objects are used to form specialized classes from
existing classes. It can be said that the subclasses are the specialized versions of
the super-class.
Links and Association

Link
• A link represents a connection through which an object collaborates with
other objects.
• Rumbaugh has defined it as “a physical or conceptual connection between
objects”. Through a link, one object may invoke the methods or navigate
through another object.
• A link depicts the relationship between two or more objects.
Association
• Association is a group of links having common structure and common
behavior.
• Association depicts the relationship between objects of one or more classes.
• A link can be defined as an instance of an association.
Degree of an Association
• Degree of an association denotes the number of classes involved in a
connection. Degree may be unary, binary, or ternary.
• A unary relationship connects objects of the same class.
• A binary relationship connects objects of two classes.
• A ternary relationship connects objects of three or more classes.
Cardinality Ratios of Associations

• Cardinality of a binary association denotes the number of
instances participating in an association. There are
three types of cardinality ratios, namely:
• One–to–One : A single object of class A is associated with
a single object of class B.
• One–to–Many : A single object of class A is associated
with many objects of class B
• Many–to–Many : An object of class A may be associated
with many objects of class B and conversely an object of
class B may be associated with many objects of class A.
Aggregation or Composition
• Aggregation or composition is a relationship among classes by which a
class can be made up of any combination of objects of other classes.
• It allows objects to be placed directly within the body of other classes.
• Aggregation is referred as a “part–of” or “has–a” relationship, with the
ability to navigate from the whole to its parts.
• An aggregate object is an object that is composed of one or more other
objects.
Example
• In the relationship, “a car has–a motor”, car is the whole object or the
aggregate, and the motor is a “part–of” the car. Aggregation may denote:
• Physical containment : Example, a computer is composed of monitor, CPU,
mouse, keyboard, and so on.
• Conceptual containment : Example, shareholder has–a share.
Benefits of Object Model
The benefits of using the object model are:
• It helps in faster development of software.
• It is easy to maintain. Suppose a module develops an
error, then a programmer can fix that particular module,
while the other parts of the software are still up and
running.
• It supports relatively hassle-free upgrades.
• It enables reuse of objects, designs, and functions.
• It reduces development risks, particularly in
integration of complex systems
Introduction to OOAD with OO Basics
Object-Oriented Analysis And Design
• Object-oriented analysis and design (OOAD) is a
software engineering approach that models a system as
a group of interacting objects.
• Each object represents some entity of interest in the system being
modeled, and is characterized by its class, its state (data
elements), and its behavior.
• Various models can be created to show the static structure,
dynamic behavior, and run-time deployment of these
collaborating objects.
• There are a number of different notations for representing
these models, such as the Unified Modeling Language
(UML).
Definition of Analysis and Design
• Analysis emphasizes an investigation of the problem and requirements, rather

than a solution. For example, if a new computerized library information system
is desired, how will it be used?
• Analysis: “build the right thing”
– Analysis focuses on user requirements (functional or non-functional)
– In other words, we want to decide exactly what system the customer wants to
have
• Design emphasizes a conceptual solution that fulfills the requirements, rather
than its implementation. For example, a description of a database schema and
software objects. Ultimately, designs can be implemented.
• Design: “build the thing right”
– Design focuses on how to provide the required functionality
– In other words, we want to decide how to structure the software that provides
the (functional and non-functional) requirements determined during analysis
Definition of Object-Oriented Analysis and Design
• During object-oriented analysis, there is an

emphasis on finding and describing the objects—
or concepts—in the problem domain. For
example, in the case of the library information system,
some of the concepts include Book, Library, and
Patron.
• During object-oriented design, there is an
emphasis on defining software objects and how
they collaborate to fulfill the requirements. For
example, in the library system, a Book software object
may have a title attribute and a get Chap-ter method
What is UML?
• A standardized, graphical “modeling language”

for communicating software design.
• Allows implementation-independent specification of:
– user/system interactions (required behaviors)
– partitioning of responsibility (OO)
– integration with larger or existing systems
– data flow and dependency
– operation orderings (algorithms)
– concurrent operations
• UML is not “process”. (That is, it doesn’t tell you how to
do things, only what you should do.)
Motivations for UML
• We need a modeling language to:

– help develop an efficient, effective and
correct designs, particularly Object
Oriented designs.
– communicate clearly with project
stakeholders (concerned parties:
developers, customer, etc).
– give us the “big picture” view of the
project.
Types of UML diagrams
• There are different types of UML diagram,

each with slightly different syntax rules:
– Use Cases
– Class Diagrams.
– Sequence Diagrams.
– Package Diagrams.
– State Diagrams
– Activity Diagrams
– Deployment Diagrams.
UML syntax
• Actors: a UML actor indicates an interface
(point of interaction) with the system.
– We use actors to group and name sets of system
interactions.
– Actors may be people, or other systems.
– An actor is NOT part of the system you are modeling.
– An actor is something external that your system has
to deal with.
• Boxes: It is used variously throughout UML to
indicate discrete elements, groupings and
containment.
UML syntax
• Arrows: arrows indicate all manner of things, depending on
which particular type of UML diagram they’re in. Usually,
arrows indicate flow, dependency, association or
generalization.
• Cardinality: applied to arrows, cardinalities show relative
numerical relationships between elements in a model:
1 to 1, 1 to many, etc.
• Constraints: allow notation of arbitrary constraints on model
elements. Used, for example, to constrain the value of a
class attribute (a piece of data).
• Stereotypes: allow us to extend the semantics of UML
with English. A stereotype is usually a word or short
phrase that describes what a diagram element does.
UML diagrams
• A single diagram is not enough to cover
all aspects of the system.
• So UML defines various kinds of
diagrams to cover most of the aspects of
a system.
• There are two broad categories of diagrams and
then are again divided into sub-categories:
– Structural Diagrams
– Behavioral Diagrams
Structural Diagrams
• The structural diagrams represent the
static aspect of the system.
• These static parts are represents by
classes, interfaces, objects, components
and nodes. The four structural diagrams are:
– Class diagram
– Object diagram
– Component diagram
– Deployment diagram
Class Diagram
• Class diagrams are the most common
diagrams used in UML.
• Class diagram consists of classes, interfaces,
associations and collaboration.
• Class diagrams basically represent the object
oriented view of a system which is static
in nature.
• Active class is used in a class diagram to
represent the concurrency of the system.
Class Diagram
Object Diagram
• Object diagrams can be described as an
instance of class diagram.
• Object diagrams are a set of objects and
their relationships just like class diagrams
and also represent the static view of the
system.
• The usage of object diagrams is similar to class
diagrams but they are used to build
prototype of a system from practical
perspective.
Object Diagram
Component Diagram
• Component diagrams represent a set of components
and their relationships.
• These components consist of classes, interfaces or
collaborations.
• Component diagrams represent the implementation view
of a system.
• During design phase software artifacts (classes,
interfaces etc) of a system are arranged in different
groups depending upon their relationship. Now these
groups are known as components.
• Finally, component diagrams are used to visualize the
implementation.
Component Diagram
Deployment Diagram
• Deployment diagrams are a set of
nodes and their relationships.
• These nodes are physical entities where
the components are deployed.
• Deployment diagrams are used for
visualizing deployment view of a
system.
• This is generally used by the deployment
team.
Deployment Diagram
Behavioral Diagrams
• Any system can have two aspects, static and dynamic. So a model
is considered as complete when both the aspects are covered fully.
• Behavioral diagrams basically capture the dynamic
aspect of a system.
• Dynamic aspect can be further described as the
changing/moving parts of a system.
• UML has the following five types of behavioral diagrams:

– Use case diagram
– Sequence diagram
– Collaboration diagram
– Statechart diagram
– Activity diagram
Behavioral Diagrams-Use case
• Use case diagrams are a set of use
cases, actors and their relationships.
• They represent the use case view of a system.
• A use case represents a particular
functionality of a system.
• So use case diagram is used to describe the
relationships among the functionalities
and their internal/external controllers.
These controllers are known as actors.
Use case Diagram
Objects of Use Case

• Actor – any entity that performs a role
• Use Case - represents a function or an
action within the system.
• System - define the scope of the use
case
• Package - used to group together use
cases.
Use Case Diagram
Use Case Diagram
Behavioral Diagrams –Sequence Diagram
• A sequence diagram is an interaction diagram.

• The sequence diagram deals with some sequences,
which are the sequence of messages flowing
from one object to another.
• Interaction among the components of a system
is very important from implementation
and execution perspective.
• Sequence diagram is used to visualize the
sequence of calls in a system to perform a
specific functionality
Sequence Diagram
Behavioral Diagrams –Collaboration Diagram
• Collaboration diagram is another form of interaction

diagram.
• It represents the structural organization of a
system and the messages sent/received.
• Structural organization consists of objects and
links.
• The purpose of collaboration diagram is similar to
sequence diagram.
• But the specific purpose of collaboration
diagram is to visualize the organization of
objects and their interaction.
Collaboration Diagram
Behavioral Diagram – State chart Diagram
• Any real time system is expected to be

reacted by some kind of internal/external
events.
• State chart diagram is used to represent
the event driven state change of a system.
• It basically describes the state change of a
class, interface etc.
• State chart diagram is used to visualize the
reaction of a system by internal/external
factors
State chart Diagram
Behavioral Diagram – Activity Diagram
• A UML activity diagram shows

sequential and parallel activities in a
process.
• They are useful for modeling
business processes, workflows, data
flows, and complex algorithms.
Activity Diagram
Use Case Modelling in OOAD
A use-case model is a model of how different types of
users interact with the system to solve a problem.
As such, it describes the goals of the users, the

interactions between the users and the system, and the
required behavior of the system in satisfying these goals.
A use-case model consists of a number of model elements.

The most important model elements are:
a. use cases,
b. Actors
c. the relationships between them
Actor
•model element representing each actor. Properties include the
actors name and brief description.
Use Case
•A model element representing each use case. Properties include
the use case name and use case specification.
Associations
•Associations are used to describe the relationships between
actors and the use cases they participate in. This relationship
is commonly known as a “communicates- association”.
Advanced model elements
The use-case model may also contain the following
advanced model elements.
Subject Or System Boundary
•A model element that represents the boundary of the
system of interest.
Use-Case Package
•A model element used to structure the use case
model to simplify analysis, communications,
navigation, and planning. If there are many use
cases or actors, you can use use-case packages to
further structure the use-case model in much the
same manner you use folders or directories to
structure the information on your hard-disk.
Dependencies
•A number of dependency types between use cases are defined
in UML. In particular, <<extend>> and <<include>>.
•<<extend>> is used to include optional behavior from an
extending use case in an extended use case.
•<<include>> is used to include common behavior from an
included use case into a base use case in order to support
re-use of common behavior.
• The system boundary is defined by who or what uses the system
(i.e. the actors), and what specific benefits the system
offers to those actors (i.e. the use cases).
• The system boundary is drawn as a box, labeled with the name of the
system, with the actors drawn outside the boundary and the use
cases inside.
• Actor Generalization - create an abstract actor called Purchaser that
interacts with the use cases ListProducts, OrderProducts, and
AcceptPayment. Customer and SalesAgent are known as concrete
actors because real people (or other systems) could fulfill those
roles. In addition, SalesAgent has another interaction with the use
case CalculateCommission that is not inherited
Relating Use Cases Include, Extend and Generalization
• In UML, a relationship is a
connection between model
elements.
• A UML relationship is a type of model
element that adds semantics to a
model by defining the structure
and behavior between the model
elements
• UML relationships are grouped into

the following categories:
Category Function
Activity edges Represent the flow between activities
Associations Indicate that instances of one model element are
connected to instances of another model element
Dependencies Indicate that a change to one model element can affect

another model element
Generalizations Indicate that one model element is a specialization of

another model element
Realizations Indicate that one model element provides a specification

that another model element implements
Transitions Represent changes in state

•in
The followingdiagrams:
use-case describe the relationships that you can use
Association relationships
•In UML models, an association is a relationship
between two classifiers, such as classes or use cases,
that describes the reasons for the relationship and the
rules that governrelationships
Generalization the relationship.
•relationship
In based
UML modeling, a generalization
in which one model relationship
element (the is a
child)
is
•component, on
Generalization another model
relationships element
areall
used (the parent).
in attributes,
class,
indicate that
operations, deployment,
the
and child and
receives
relationships use-case
that of
arethe diagrams
defined in theto
parent.
Include relationships
•In UML modeling, an include relationship is a
relationship in which one use case (the base use
case) includes the functionality of another use case
(the inclusion use case). The include relationship
supportsrelationships
Extend the reuse of functionality in a use-case model.
•specify
In UML that
behavior modeling,
of one
anotheryouuse
use cancase
case use an extend
(extension)
(base). relationship
extends
This type ofthe to
relationship reveals
that are typically details
hidden inabout
a use acase.
system or application
There can be 5 relationship types in a use case

diagram.
Association between actor and use case
Generalization of an actor
Extend between two use cases
Include between two use cases
Generalization of a use case
•Association Between Actor and Use Case

This one is straightforward and present in every use case
diagram. Few things to note.
An actor must be associated with at least one use case.
An actor can be associated with multiple use cases.
Multiple actors can be associated with a single use case.
Generalization of an Actor
•Generalization of an actor means that one actor can inherit the
role of the other actor. The descendant inherits all the use
cases of the ancestor. The descendant has one or more use
cases that are specific to that role.
Extend Relationship Between Two Use Cases

•Many people confuse the extend relationship in use cases. As the name
implies it extends the base use case and adds more functionality to the
system. Here are a few things to consider when using the <<extend>>
relationship.
The extending use case is dependent on the extended (base) use case.
In the below diagram the “Calculate Bonus” use case doesn’t make much
sense without the “Deposit Funds” use case.
The extending use case is usually optional and can be triggered
conditionally. In the diagram, you can see that the extending use case is
triggered only for deposits over 10,000 or when the age is over 55.
The extended (base) use case must be meaningful on its own. This
means it should be independent and must not rely on the behavior of the
extending use case.
• Extend Relationship Between Two

Use Cases
Extend relationship in use case diagrams

•Although extending use case is optional most of the time
it is not a must.
•An extending use case can have non-optional behavior as
well. This mostly happens when your modeling complex
behaviors.
•For example, in an accounting system, one use case
might be “Add Account Ledger Entry”. This might have
extending use cases “Add Tax Ledger Entry” and “Add
Payment Ledger Entry”. These are not optional but
depend on the account ledger entry. Also, they have their
own specific behavior to be modeled as a separate use
case.
Include Relationship Between Two Use Cases

•Include relationship show that the behavior of the included
use case is part of the including (base) use case.
The main reason for this is to reuse common actions across

multiple use cases.
In some situations, this is done to simplify complex behaviors.
Few things to consider when using the <<include>>
relationship.
The base use case is incomplete without the included use

case.
The included use case is mandatory and not optional.
• Include Relationship Between Two

Use Cases
Generalization of a Use Case

•This is similar to the generalization of an actor. The
behavior of the ancestor is inherited by the
descendant.
•This is used when there is common behavior between
two use cases and also specialized behavior specific to
each use case.
•For example, in the previous banking example, there
might be a use case called “Pay Bills”. This can be
generalized to “Pay by Credit Card”, “Pay by Bank
Balance” etc.
• Generalization of Use cases
When to use Use-Cases in OOAD
Purpose of Use Case Diagrams
•Use case diagrams are used to gather the requirements of a
system including internal and external influences. These
requirements are mostly design requirements.
•Hence, when a system is analyzed to gather its functionalities, use
cases are prepared and actors are identified.
•When the initial task is complete, use case diagrams are
modelled to present the outside view.
•In brief, the purposes of use case diagrams can be said to be as follows −
– Used to gather the requirements of a system.
– Used to get an outside view of a system.
– Identify the external and internal factors influencing the
system.
– Show the interaction among the requirements through actors.


OODP - Unit - I - UML Diagram

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OODP - Unit - I - UML Diagram

Uploaded by

Copyright:

Available Formats

SRM INSTITUTE OF SCIENCE AND TECHNOLOGY,

• The important features of object–oriented programming are:

Generalization and Specialization

Links and Association

Cardinality Ratios of Associations

• Analysis emphasizes an investigation of the problem and requirements, rather

• During object-oriented analysis, there is an

• A standardized, graphical “modeling language”

• We need a modeling language to:

• There are different types of UML diagram,

• UML has the following five types of behavioral diagrams:

Objects of Use Case

• A sequence diagram is an interaction diagram.

• Collaboration diagram is another form of interaction

• Any real time system is expected to be

• A UML activity diagram shows

As such, it describes the goals of the users, the

A use-case model consists of a number of model elements.

•A number of dependency types between use cases are defined

in UML. In particular, <<extend>> and <<include>>.

•<<extend>> is used to include optional behavior from an

extending use case in an extended use case.

•<<include>> is used to include common behavior from an

included use case into a base use case in order to support

re-use of common behavior.

• UML relationships are grouped into

Dependencies Indicate that a change to one model element can affect

Generalizations Indicate that one model element is a specialization of

Realizations Indicate that one model element provides a specification

Transitions Represent changes in state

There can be 5 relationship types in a use case

•Association Between Actor and Use Case

Extend Relationship Between Two Use Cases

• Extend Relationship Between Two

Extend relationship in use case diagrams

Include Relationship Between Two Use Cases

The main reason for this is to reuse common actions across

The base use case is incomplete without the included use

• Include Relationship Between Two

Generalization of a Use Case

• Generalization of Use cases

You might also like