Object Oriented Modeling

What is UML?

 UML stands for “Unified Modeling Language”

 It is a industry-standard graphical language .

 UML is a pictorial language used to make software blue prints

 It is used for specifying, visualizing, constructing, and documenting the

artifacts of software systems

 UML is different from the other common programming languages

 It uses mostly graphical notations.

 Simplifies the complex process of software design

 Why UML for Modeling
 Use graphical notation to communicate more clearly than natural language
(imprecise) and code(too detailed).

 Help acquire an overall view of a system.

 Tools can be used to generate code in various languages using UML diagrams

 UML is not dependent on any one language or technology.

 A picture is worth than thousand words

 UML can be defined as a simple modeling mechanism to model all possible

practical systems in today’s complex environment.
History of UML
 Structural UML Diagrams
 Class Diagram
The most widely use UML diagram is the class
diagram. It is the building block of all object oriented
software systems. Class diagrams also help us
identify relationship between different classes or
objects.
 Composite Structure Diagram
We use composite structure diagrams to represent
the internal structure of a class and its interaction
points with other parts of the system.
• A composite structure diagram represents
relationship between parts and their configuration
which determine how the classifier (class, a
component, or a deployment node) behaves.
Object Diagram
An Object Diagram can be referred to as a
screenshot of the instances in a system and the
relationship that exists between them. Since object
diagrams depict behaviour when objects have been
instantiated, we are able to study the behaviour of
the system at a particular instant.
Component Diagram
Component diagrams are used to represent how
the physical components in a system have been
organized. We use them for modelling
implementation details.
• Component Diagrams depict the structural
relationship between software system elements and
help us in understanding if functional requirements
have been covered by planned development.
Deployment Diagram
Deployment Diagrams are used to represent system
hardware and its software.It tells us what hardware
components exist and what software components run
on them.
• We illustrate system architecture as distribution of
software artifacts over distributed targets.
 Package Diagram
We use Package Diagrams to depict how packages
and their elements have been organized. A package
diagram simply shows us the dependencies between
different packages and internal composition of
packages.
• Packages help us to organise UML diagrams into
meaningful groups and make the diagram easy to
understand.They are primarily used to organise class
 Behavioral UML Diagrams
State Machine Diagrams
A state diagram is used to represent the condition of
the system or part of the system at finite instances of
time. It’s a behavioral diagram and it represents the
behavior using finite state transitions.
. Activity Diagrams
We use Activity Diagrams to illustrate the flow of
control in a system. We can also use an activity
diagram to refer to the steps involved in the execution
of a use case.
• We model sequential and concurrent activities using
activity diagrams. So, we basically depict workflows
visually using an activity diagram.
• An activity diagram focuses on condition of flow and
Use Case Diagrams
Use Case Diagrams are used to depict the
functionality of a system or a part of a system. They
are widely used to illustrate the functional
requirements of the system and its interaction with
external agents(actors).
• A use case is basically a diagram representing
different scenarios where the system can be used.
 Sequence Diagram
A sequence diagram simply depicts interaction
between objects in a sequential order i.e. the order
in which these interactions take place.
• We can also use the terms event diagrams or event
scenarios to refer to a sequence diagram.
• Sequence diagrams describe how and in what order
the objects in a system function.
 Communication Diagram
A Communication Diagram (known as Collaboration
Diagram in UML 1.x) is used to show sequenced
messages exchanged between objects.
• A communication diagram focuses primarily on
objects and their relationships.

 Timing Diagram
Timing Diagram are a special form of Sequence
diagrams which are used to depict the behavior of
objects over a time frame.
Object-Oriented Concepts Used in UML
Diagrams
1.Class
1. A class defines the blue print i.e. structure and
functions of an object.
2.Objects
2. Objects help us to decompose large systems and
help us to modularize our system. Modularity helps
to divide our system into understandable
components so that we can build our system piece
by piece. An object is the fundamental unit (building
block) of a system which is used to depict an entity.
3.Inheritance
3. Inheritance is a mechanism by which child classes
inherit the properties of their parent classes.
4.Abstraction
4. Abstraction in UML refers to the process of
emphasizing the essential aspects of a system or
object while disregarding irrelevant details. By
abstracting away unnecessary complexities,
abstraction facilitates a clearer understanding and
communication among stakeholders.
5.Encapsulation
5. Binding data together and protecting it from the
outer world is referred to as encapsulation.
6.Polymorphism
6. Mechanism by which functions or entities are able to
exist in different forms.
conceptual model of UML
 It is a model which is made of concepts and their relationships.

 It is the first step before drawing a UML diagram.

 It helps to understand the entities in the real world and how they
interact with each other

 It can be mastered by learning the following three major elements:

UML building blocks
Rules to connect the building blocks
Common mechanisms of UML
Object oriented concepts
object contains both data and methods that control the
data.

The data represent the state of the object

Data can also describe the relationships between this

object and other objects

 objects are the real world entities

Object oriented concepts
Every object belongs to (is an instance of) a class
An object may have fields, or variables
The class describes those fields
An object may have methods
The class describes those methods
A class is like a template, or cookie cutter
You use the class’s constructor to make objects
Example: A “Rabbit” object
You could (in a game, for example) create an object
representing a rabbit
It would have data:
How hungry it is
How frightened it is
Where it is
And methods:
eat, hide, run, dig
 Concept: Classes form a hierarchy

Classes are arranged in a tree like structure called a

hierarchy
The class at the root is named Object
Every class, except Object, has a super class
A class may have several ancestors, up to Object
When you define a class, you specify its super class
Every class may have one or more subclasses
 Fundamental concepts of object oriented world
 Objects: Objects represent an entity and are the basic building block.

 Class: Class is the blue print of an object.

 Abstraction: Abstraction represents the behavior of an real world entity.

 Encapsulation: Encapsulation is the mechanism of binding the data together and

hiding them from outside world.

 Inheritance: Inheritance is the mechanism of making new classes from existing one.

 Polymorphism: It defines the mechanism to exists in different forms.

Kinds of access
Java provides four levels of access:

public: available everywhere

protected: available within the package (in the same

subdirectory) and to all subclasses

[default]: available within the package

private: only available within the class itself

The default is called package visibility
OO Analysis and Design
 it is the investigation of objects. Design means collaboration of
identified objects.

 identifying the objects their relationships are identified and finally the
design is produced

 Identifying the objects of a system.

 Identify their relationships.

 OO Analysis --> OO Design --> OO implementation using OO languages

Building blocks of UML
The building blocks of UML can be defined as:
Things
Relationships
Diagrams
Things
Things are the most important building blocks of UML.
Things can be:
Structural
Behavioral
Grouping
Annotational
Structural things
The Structural things define the static part of the model.
They represent physical and conceptual elements.
Class:
Class represents set of objects having similar responsibilities.

Interface:
Interface defines a set of operations which specify the
responsibility of a class

Collaboration:
Collaboration defines interaction between elements.
Structural things
Use case:
Use case represents a set of actions performed by a system
for a specific goal.
Component:
Component describes physical part of a system.
Node:
A node can be defined as a physical element that exists at
run time.
Behavioral things
It consists of the dynamic parts of UML models.
Interaction:
It is defined as a behavior that consists of a group of
messages exchanged among elements to accomplish a
specific task.
State machine:
It is useful when the state of an object in its life cycle is
important. It defines the sequence of states an object goes
through in response to events.
Grouping things
Grouping things can be defined as a mechanism to group
elements of a UML model together. There is only one
grouping thing available:

Package:
Package is the only one grouping thing available for
gathering structural and behavioral things.
Annotational things
Annotational things can be defined as a mechanism to
capture remarks, descriptions, and comments of UML
model elements.

Note
It is the only one Annotational thing available.
A note is used to render comments, constraints etc of an
UML element.
Relationships
It shows how elements are associated with each other and
this association describes the functionality of an
application.
There are four kinds of relationships available.
Dependency:
Dependency is a relationship between two things in which
change in one element also affects the other one.
Association:
Association is basically a set of links that connects elements
of an UML model. It also describes how many objects are
taking part in that relationship.
Relationships
Generalization:
Generalization can be defined as a relationship which
connects a specialized element with a generalized element.
It basically describes inheritance relationship in the world
of objects.
Realization:
Realization can be defined as a relationship in which two
elements are connected. One element describes some
responsibility which is not implemented and the other one
implements them. This relationship exists in case of
interfaces.
• owners feed pets, pets please owners
(association)
• a tail is a part of both dogs and cats
(aggregation / composition)
• a cat is a kind of pet
(inheritance / generalization)
Aggregation and Composition are subsets of
association meaning they are specific cases of
association. In both aggregation and composition
object of one class "owns" object of another class.
But there is a subtle difference:
• Aggregation implies a relationship where the
child can exist independently of the parent.
Example: Class (parent) and Student (child).
Delete the Class and the Students still exist.
• Composition implies a relationship where the
child cannot exist independent of the parent.
Example: House (parent) and Room (child). Rooms
don't exist separate to a House.


Composition Example:
We should be more specific and use the
composition link in cases where in addition to the
part-of relationship between Class A and Class B -
there's a strong lifecycle dependency between
the two, meaning that when Class A is deleted
then Class B is also deleted as a result
 Aggregation Example:
It's important to note that the aggregation link
doesn't state in any way that Class A owns
Class B nor that there's a parent-child
relationship (when parent deleted all its child's are
being deleted as a result) between the two. Actually,
quite the opposite! The aggregation link is usually
used to stress the point that Class A instance is not
the exclusive container of Class B instance, as in fact
the same Class B instance has another container/s.
 Specialization
Generalization is a mechanism for combining similar
classes of objects into a single, more general class.
Generalization identifies commonalities among a set
of entities. The commonality may be of attributes,
behavior, or both. In other words, a superclass has the
most general attributes, operations, and relationships
that may be shared with subclasses. A subclass may
have more specialized attributes and operations.
Specialization is the reverse process of
Generalization means creating new sub-classes from
an existing class.
For Example, a Bank Account is of two types - Savings
Account and Credit Card Account. Savings Account
and Credit Card Account inherit the common/
Specialization
Notations
Types of UML Diagrams
UML includes the following nine diagrams
Class diagram
Object diagram
Use case diagram
Sequence diagram
Collaboration diagram
Activity diagram
Statechart diagram
Deployment diagram
Component diagram
 Structural Diagrams
They represent the static aspect of the system. These static
aspects represent those parts of a diagram which forms the
main structure and therefore stable

The four structural diagrams are:

Class diagram
Object diagram
Component diagram
Deployment diagram
Behavioral diagrams
Any system can have two aspects, static and dynamic.
A model is considered as complete when both the aspects are
covered fully.
It 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
Classes

Each class is represented by a rectangle subdivided into three

compartments
 Name
 Attributes
 Operations
Modifiers are used to indicate visibility of attributes and
operations.
 ‘+’ is used to denote Public visibility (everyone)
 ‘#’ is used to denote Protected visibility (friends and derived)
 ‘-’ is used to denote Private visibility (no one)
By default, attributes are hidden and operations are visible.
An example of Class

Name
Account_Name
- Customer_Name
Attributes
- Balance
+addFunds( ) Operations
+withDraw( )
+transfer( )
OO Relationships
There are two kinds of Relationships
Generalization (parent-child relationship)
Association (student enrolls in course)
Associations can be further classified as
Aggregation
Composition
 OO Relationships: Generalization

Supertype Example: Customer

Regular Loyalty
Customer Customer

Subtype1 Subtype2
or: Customer
- Generalization expresses a
parent/child relationship among related
classes.
- Used for abstracting details in several Regular Loyalty
layers Customer Customer
OO Relationships: Association

Represent relationship between instances of classes

Student enrolls in a course
Courses have students
Courses have exams
Etc.
Association has two ends
Role names (e.g. enrolls)
Multiplicity (e.g. One course can have many students)
Navigability (unidirectional, bidirectional)
Association: Multiplicity and Roles
student
1 *

University Person

0..1 *
employer teacher

Role
Multiplicity
Symbol Meaning
1 One and only one
Role
0..1 Zero or one “A given university groups many people;
some act as students, others as teachers.
M..N From M to N (natural
language) A given student belongs to a single
university; a given teacher may or may not
* From zero to any positive
be working for the university at a particular
integer
time.”
0..* From zero to any positive
integer
1..* From one to any positive
Association: Model to Implementation
* 4
Student Course
has enrolls

Class Student {
Course enrolls[4];
}

Class Course {
Student have[];
}
 OO Relationships: Composition
Composition: expresses a relationship among instances
Whole Class of related classes. It is a specific kind of Whole-Part
Class W relationship.

It expresses a relationship where an instance of the

Whole-class has the responsibility to create and initialize
instances of each Part-class.

Class P1 Class P2 It may also be used to express a relationship where instances

of the Part-classes have privileged access or visibility to
certain attributes and/or behaviors defined by the
Part Classes Whole-class.

Composition should also be used to express relationship where

Example instances of the Whole-class have exclusive access to and
control of instances of the Part-classes.
Automobile
Composition should be used to express a relationship where
the behavior of Part instances is undefined without being
related to an instance of the Whole. And, conversely, the
behavior of the Whole is ill-defined or incomplete if one or
more of the Part instances are undefined.
Engine Transmission

[From Dr.David A. Workman]

OO Relationships: Aggregation
Container Class
Class C Aggregation: expresses a relationship among instances
of related classes. It is a specific kind of Container-
AGGREGATION Containee
relationship.

It expresses a relationship where an instance of the

Class E1 Class E2 Container-class has the responsibility to hold and
maintain
instances of each Containee-class that have been created
Containee Classes outside the auspices of the Container-class.

Aggregation should be used to express a more informal

relationship than composition expresses. That is, it is an
appropriate relationship where the Container and its
Example Containees can be manipulated independently.
Bag
Aggregation is appropriate when Container and
Containees have no special access privileges to each other.

Apples Milk

[From Dr.David A. Workman]

Aggregation vs. Composition

Composition is really a strong form of aggregation

•components have only one owner
•components cannot exist independent of their owner
•components live or die with their owner
e.g. Each car has an engine that can not be shared with
other cars.

•Aggregations may form "part of" the aggregate, but may not
be essential to it. They may also exist independent of the
aggregate.
e.g. Apples may exist independent of the bag.