UML & Object

modelling
Object Modelling using UML
• In UML models, objects are model elements that represent instances
of a class or of classes.
• One can add objects to your model to represent concrete and
prototypical instances.
• A concrete instance represents an actual person or thing in the real
world.
OO Concepts
• In the object-oriented design method, the system is viewed as a collection of
objects (i.e., entities).
• The state is distributed among the objects, and each object handles its state
data.
• For example, in a Library Automation Software, each library representative may
be a separate object with its data and functions to operate on these data.
• The tasks defined for one purpose cannot refer or change data of other objects.
• Objects have their internal data which represent their state. Similar objects
create a class.
• In other words, each object is a member of some class.
• Classes may inherit features from the superclass.
• Objects: All entities involved in the solution design are known as objects. For example, person, banks,
company, and users are considered as objects. Every entity has some attributes associated with it and has
some methods to perform on the attributes.
• Classes: A class is a generalized description of an object. An object is an instance of a class. A class defines all
the attributes, which an object can have and methods, which represents the functionality of the object.
• Messages: Objects communicate by message passing. Messages consist of the integrity of the target object,
the name of the requested operation, and any other action needed to perform the function. Messages are
often implemented as procedure or function calls.
• Abstraction In object-oriented design, complexity is handled using abstraction. Abstraction is the removal of
the irrelevant and the amplification of the essentials.
• Encapsulation: Encapsulation is also called an information hiding concept. The data and operations are
linked to a single unit. Encapsulation not only bundles essential information of an object together but also
restricts access to the data and methods from the outside world.
• Inheritance: OOD allows similar classes to stack up in a hierarchical manner where the lower or sub-classes
can import, implement, and re-use allowed variables and functions from their immediate superclasses.This
property of OOD is called an inheritance. This makes it easier to define a specific class and to create
generalized classes from specific ones.
• Polymorphism: OOD languages provide a mechanism where methods performing similar tasks but vary in
arguments, can be assigned the same name. This is known as polymorphism, which allows a single interface
is performing functions for different types. Depending upon how the service is invoked, the respective
portion of the code gets executed.
What is UML

• UML stands for Unified modeling language, is a standardized general-

purpose visual modeling language in the field of Software
Engineering.
• It is used for specifying, visualizing, constructing, and documenting
the primary artifacts of the software system.
• It helps in designing and characterizing, especially those software
systems that incorporate the concept of Object orientation.
• It describes the working of both the software and hardware systems.
• Goals of UML
• Since it is a general-purpose modeling language, it can be utilized by all the modelers.
• UML came into existence after the introduction of object-oriented concepts to systemize
and consolidate the object-oriented development, due to the absence of standard methods
at that time.
• The UML diagrams are made for business users, developers, ordinary people, or anyone
who is looking forward to understand the system, such that the system can be software or
non-software.
• Thus it can be concluded that the UML is a simple modeling approach that is used to model
all the practical systems.
• Characteristics of UML
• The UML has the following features:
• It is a generalized modeling language.
• It is distinct from other programming languages like C++, Python, etc.
• It is interrelated to object-oriented analysis and design.
• It is used to visualize the workflow of the system.
• It is a pictorial language, used to generate powerful modeling artifacts.
OO Analysis and Design

• OO is an analysis of objects, and design means combining those identified

objects. So, the main purpose of OO analysis is identifying the objects for
designing a system. The analysis can also be done for an existing system.
The analysis can be more efficient if we can identify the objects. Once we
have identified the objects, their relationships are then identified, and the
design is also produced.
• The purpose of OO is given below:
• To identify the objects of a system.
• To identify their relationships.
• To make a design that is executable when the concepts of OO are
employed.
• Step 1: OO Analysis
• The main purpose of OO analysis is identifying the objects and describing
them correctly. After the objects are identified, the designing step is easily
carried out. It is a must to identify the objects with responsibilities. Here the
responsibility refers to the functions performed by the objects. Each individual
object has its own functions to perform. The purpose of the system is fulfilled
by collaborating these responsibilities.
• Step 2: OO Design
• This phase mainly emphasizes on meeting the requirements. In this phase, the
objects are joined together as per the intended associations. After the
association is completed, the designing phase also gets complete.
• Step 3: OO Implementation
• This is the last phase that comes after the designing is done. It implements the
design using any OO languages like C++, Java, etc.
UML-Diagrams

• The UML diagrams are categorized into structural diagrams,

behavioral diagrams, and also interaction overview diagrams. The
diagrams are hierarchically classified in the following figure:
• 1. Structural Diagrams
• Structural diagrams depict a static view or structure of a system. It is widely used in the documentation of software
architecture. It embraces class diagrams, composite structure diagrams, component diagrams, deployment diagrams,
object diagrams, and package diagrams. It presents an outline for the system. It stresses the elements to be present that
are to be modeled.
• Class Diagram: Class diagrams are one of the most widely used diagrams. It is the backbone of all the object-oriented
software systems. It depicts the static structure of the system. It displays the system's class, attributes, and methods. It
is helpful in recognizing the relation between different objects as well as classes.
• Composite Structure Diagram: The composite structure diagrams show parts within the class. It displays the
relationship between the parts and their configuration that ascertain the behavior of the class. It makes full use of ports,
parts, and connectors to portray the internal structure of a structured classifier. It is similar to class diagrams, just the
fact it represents individual parts in a detailed manner when compared with class diagrams.
• Object Diagram: It describes the static structure of a system at a particular point in time. It can be used to test the
accuracy of class diagrams. It represents distinct instances of classes and the relationship between them at a time.
• Component Diagram: It portrays the organization of the physical components within the system. It is used for modeling
execution details. It determines whether the desired functional requirements have been considered by the planned
development or not, as it depicts the structural relationships between the elements of a software system.
• Deployment Diagram: It presents the system's software and its hardware by telling what the existing physical
components are and what software components are running on them. It produces information about system software.
It is incorporated whenever software is used, distributed, or deployed across multiple machines with dissimilar
configurations.
• Package Diagram: It is used to illustrate how the packages and their elements are organized. It shows the dependencies
between distinct packages. It manages UML diagrams by making it easily understandable. It is used for organizing the
class and use case diagrams.
• 2. Behavioral Diagrams:
• Behavioral diagrams portray a dynamic view of a system or the behavior of a
system, which describes the functioning of the system. It includes use case
diagrams, state diagrams, and activity diagrams. It defines the interaction
within the system.
• State Machine Diagram: It is a behavioral diagram. it portrays the system's
behavior utilizing finite state transitions. It is also known as the State-
charts diagram. It models the dynamic behavior of a class in response to
external stimuli.
• Activity Diagram: It models the flow of control from one activity to the other.
With the help of an activity diagram, we can model sequential and concurrent
activities. It visually depicts the workflow as well as what causes an event to
occur.
• Use Case Diagram: It represents the functionality of a system by utilizing
actors and use cases. It encapsulates the functional requirement of a system
and its association with actors. It portrays the use case view of a system.
• 3. Interaction Diagrams
• Interaction diagrams are a subclass of behavioral diagrams that give emphasis to object
interactions and also depicts the flow between various use case elements of a system. In
simple words, it shows how objects interact with each other and how the data flows within
them. It consists of communication, interaction overview, sequence, and timing diagrams.
• Sequence Diagram: It shows the interactions between the objects in terms of messages
exchanged over time. It delineates in what order and how the object functions are in a
system.
• Communication Diagram: It shows the interchange of sequence messages between the
objects. It focuses on objects and their relations. It describes the static and dynamic
behavior of a system.
• Timing Diagram: It is a special kind of sequence diagram used to depict the object's
behavior over a specific period of time. It governs the change in state and object behavior
by showing the time and duration constraints.
• Interaction Overview diagram: It is a mixture of activity and sequence diagram that
depicts a sequence of actions to simplify the complex interactions into simple interactions.
UML Class Diagram

• The class diagram depicts a static view of an application. It represents

the types of objects residing in the system and the relationships
between them. A class consists of its objects, and also it may inherit
from other classes. A class diagram is used to visualize, describe,
document various different aspects of the system, and also construct
executable software code.
• It shows the attributes, classes, functions, and relationships to give an
overview of the software system. It constitutes class names, attributes,
and functions in a separate compartment that helps in software
development. Since it is a collection of classes, interfaces, associations,
collaborations, and constraints, it is termed as a structural diagram.
 Vital components of a Class
Diagram
• Upper Section: The upper section encompasses the name of the class. A class is a
representation of similar objects that shares the same relationships, attributes, operations, and
semantics. Some of the following rules that should be taken into account while representing a
class are given below:
• Capitalize the initial letter of the class name.
• Place the class name in the center of the upper section.
• A class name must be written in bold format.
• The name of the abstract class should be written in italics format.
• Middle Section: The middle section constitutes the attributes, which describe the quality of the
class. The attributes have the following characteristics:
• The attributes are written along with its visibility factors, which are public (+), private (-), protected (#),
and package (~).
• The accessibility of an attribute class is illustrated by the visibility factors.
• A meaningful name should be assigned to the attribute, which will explain its usage inside the class.
• Lower Section: The lower section contain methods or operations. The methods are
represented in the form of a list, where each method is written in a single line. It demonstrates
how a class interacts with data.
• Relationships
• In UML, relationships are of three types:
• Dependency: A dependency is a semantic relationship between two or more
classes where a change in one class cause changes in another class. It forms a
weaker relationship.
In the following example, Student_Name is dependent on the Student_Id.

• Generalization: A generalization is a relationship between a parent class

(superclass) and a child class (subclass). In this, the child class is inherited from the
parent class.
For example, The Current Account, Saving Account, and Credit Account are the
generalized form of Bank Account.
• Association: It describes a static or physical connection between two or more
objects. It depicts how many objects are there in the relationship.
For example, a department is associated with the college.
• Multiplicity: It defines a specific range of allowable instances of attributes. In case if a
range is not specified, one is considered as a default multiplicity.
• For example, multiple patients are admitted to one hospital.

• Aggregation: An aggregation is a subset of association, which represents has a

relationship. It is more specific then association. It defines a part-whole or part-of
relationship. In this kind of relationship, the child class can exist independently of its
parent class.
• The company encompasses a number of employees, and even if one employee resigns,
the company still exists.
• Composition: The composition is a subset of aggregation. It portrays the
dependency between the parent and its child, which means if one part is
deleted, then the other part also gets discarded. It represents a whole-part
relationship.
• A contact book consists of multiple contacts, and if you delete the contact
book, all the contacts will be lost.
• Abstract Classes
• In the abstract class, no objects can be a direct entity of the abstract class. The
abstract class can neither be declared nor be instantiated. It is used to find the
functionalities across the classes. The notation of the abstract class is similar
to that of class; the only difference is that the name of the class is written in
italics. Since it does not involve any implementation for a given function, it is
best to use the abstract class with multiple objects.
 How to draw a Class Diagram?
• The class diagram is used most widely to construct software applications. It not only represents
a static view of the system but also all the major aspects of an application. A collection of class
diagrams as a whole represents a system.
• Some key points that are needed to keep in mind while drawing a class diagram are given
below:
• To describe a complete aspect of the system, it is suggested to give a meaningful name to the
class diagram.
• The objects and their relationships should be acknowledged in advance.
• The attributes and methods (responsibilities) of each class must be known.
• A minimum number of desired properties should be specified as more number of the unwanted
property will lead to a complex diagram.
• Notes can be used as and when required by the developer to describe the aspects of a diagram.
• The diagrams should be redrawn and reworked as many times to make it correct before
producing its final version.
• Class Diagram Example
• A class diagram describing the sales order system is given below.
 UML Use Case Diagram
• A use case diagram is used to represent the dynamic behavior of a system. It encapsulates the
system's functionality by incorporating use cases, actors, and their relationships. It models the
tasks, services, and functions required by a system/subsystem of an application. It depicts the
high-level functionality of a system and also tells how the user handles a system.
• Purpose of Use Case Diagrams
• The main purpose of a use case diagram is to portray the dynamic aspect of a system. It
accumulates the system's requirement, which includes both internal as well as external influences.
It invokes persons, use cases, and several things that invoke the actors and elements accountable
for the implementation of use case diagrams. It represents how an entity from the external
environment can interact with a part of the system.
• Following are the purposes of a use case diagram given below:
• It gathers the system's needs.
• It depicts the external view of the system.
• It recognizes the internal as well as external factors that influence the system.
• It represents the interaction between the actors.
• How to draw a Use Case diagram?
• It is essential to analyze the whole system before starting with drawing a use case diagram, and
then the system's functionalities are found. And once every single functionality is identified,
they are then transformed into the use cases to be used in the use case diagram.
• After that, we will enlist the actors that will interact with the system. The actors are the person
or a thing that invokes the functionality of a system. It may be a system or a private entity, such
that it requires an entity to be pertinent to the functionalities of the system to which it is going
to interact.
• Once both the actors and use cases are enlisted, the relation between the actor and use case/
system is inspected. It identifies the no of times an actor communicates with the system.
Basically, an actor can interact multiple times with a use case or system at a particular instance
of time.
• Following are some rules that must be followed while drawing a use case diagram:
• A pertinent and meaningful name should be assigned to the actor or a use case of a system.
• The communication of an actor with a use case must be defined in an understandable way.
• Specified notations to be used as and when required.
• The most significant interactions should be represented among the multiple no of interactions
between the use case and actors.
• Example of a Use Case Diagram
• A use case diagram depicting the Online Shopping website is given below.
• Here the Web Customer actor makes use of any online shopping website to purchase online. The top-level
uses are as follows; View Items, Make Purchase, Checkout, Client Register. The View Items use case is utilized
by the customer who searches and view products. The Client Register use case allows the customer to
register itself with the website for availing gift vouchers, coupons, or getting a private sale invitation. It is to
be noted that the Checkout is an included use case, which is part of Making Purchase, and it is not available
by itself.
• The View Items is further extended by several use cases such as; Search Items, Browse Items, View
Recommended Items, Add to Shopping Cart, Add to Wish list. All of these extended use cases provide some
functions to customers, which allows them to search for an item. The View Items is further extended by
several use cases such as; Search Items, Browse Items, View Recommended Items, Add to Shopping Cart, Add
to Wish list. All of these extended use cases provide some functions to customers, which allows them to
search for an item.
• Both View Recommended Item and Add to Wish List include the Customer Authentication use case, as they
necessitate authenticated customers, and simultaneously item can be added to the shopping cart without any
user authentication.
• Similarly, the Checkout use case also includes the following use cases, as shown below. It
requires an authenticated Web Customer, which can be done by login page, user
authentication cookie ("Remember me"), or Single Sign-On (SSO). SSO needs an external
identity provider's participation, while Web site authentication service is u
• The Checkout use case involves Payment use case that can be done either by the credit card
and external credit payment services or with PayPal.tilized in all these use cases.
• Important tips for drawing a Use Case diagram
• Following are some important tips that are to be kept in mind while drawing a
use case diagram:
• A simple and complete use case diagram should be articulated.
• A use case diagram should represent the most significant interaction among
the multiple interactions.
• At least one module of a system should be represented by the use case
diagram.
• If the use case diagram is large and more complex, then it should be drawn
more generalized.
UML Activity Diagram

• In UML, the activity diagram is used to demonstrate the flow of control

within the system rather than the implementation. It models the
concurrent and sequential activities.
• The activity diagram helps in envisioning the workflow from one activity
to another. It put emphasis on the condition of flow and the order in
which it occurs. The flow can be sequential, branched, or concurrent,
and to deal with such kinds of flows, the activity diagram has come up
with a fork, join, etc.
• It is also termed as an object-oriented flowchart. It encompasses
activities composed of a set of actions or operations that are applied to
model the behavioral diagram.
• Components of an Activity Diagram
• Activities
• The categorization of behavior into one or more actions is termed as an
activity. In other words, it can be said that an activity is a network of nodes
that are connected by edges. The edges depict the flow of execution. It may
contain action nodes, control nodes, or object nodes.
• The control flow of activity is represented by control nodes and object nodes
that illustrates the objects used within an activity. The activities are initiated at
the initial node and are terminated at the final node.
• Activity partition /swimlane
• The swimlane is used to cluster all the related activities in one column or one
row. It can be either vertical or horizontal. It used to add modularity to the
activity diagram. It is not necessary to incorporate swimlane in the activity
diagram. But it is used to add more transparency to the activity diagram.
• Forks
• Forks and join nodes generate the concurrent flow inside the activity. A fork
node consists of one inward edge and several outward edges. It is the same as
that of various decision parameters. Whenever a data is received at an inward
edge, it gets copied and split crossways various outward edges. It split a single
inward flow into multiple parallel flows.
• Join Nodes
• Join nodes are the opposite of fork nodes. A Logical AND operation is performed on all of the
inward edges as it synchronizes the flow of input across one single output (outward) edge.

• Pins
• It is a small rectangle, which is attached to the action rectangle. It clears out all the messy
and complicated thing to manage the execution flow of activities. It is an object node that
precisely represents one input to or output from the action.
• Notation of an Activity diagram
• Activity diagram constitutes following notations:
• Initial State: It depicts the initial stage or beginning of the set of actions.
• Final State: It is the stage where all the control flows and object flows end.
• Decision Box: It makes sure that the control flow or object flow will follow
only one path.
• Action Box: It represents the set of actions that are to be performed.
• Why use Activity Diagram?
• An event is created as an activity diagram encompassing a group of nodes associated with edges. To model the behavior
of activities, they can be attached to any modeling element. It can model use cases, classes, interfaces, components,
and collaborations.
• It mainly models processes and workflows. It envisions the dynamic behavior of the system as well as constructs a
runnable system that incorporates forward and reverse engineering. It does not include the message part, which means
message flow is not represented in an activity diagram.
• It is the same as that of a flowchart but not exactly a flowchart itself. It is used to depict the flow between several
activities.
• How to draw an Activity Diagram?
• An activity diagram is a flowchart of activities, as it represents the workflow among various activities. They are identical
to the flowcharts, but they themself are not exactly the flowchart. In other words, it can be said that an activity diagram
is an enhancement of the flowchart, which encompasses several unique skills.
• Since it incorporates swimlanes, branching, parallel flows, join nodes, control nodes, and forks, it supports exception
handling. A system must be explored as a whole before drawing an activity diagram to provide a clearer view of the
user. All of the activities are explored after they are properly analyzed for finding out the constraints applied to the
activities. Each and every activity, condition, and association must be recognized.
• After gathering all the essential information, an abstract or a prototype is built, which is then transformed into the
actual diagram.
• Following are the rules that are to be followed for drawing an activity diagram:
• A meaningful name should be given to each and every activity.
• Identify all of the constraints.
• Acknowledge the activity associations.
• Example of an Activity Diagram
• An example of an activity diagram showing the business flow activity of order
processing is given below.
• Here the input parameter is the Requested order, and once the order is
accepted, all of the required information is then filled, payment is also
accepted, and then the order is shipped. It permits order shipment before an
invoice is sent or payment is completed.
• When to use an Activity Diagram?
• An activity diagram can be used to portray business processes and workflows.
Also, it used for modeling business as well as the software. An activity
diagram is utilized for the followings:
• To graphically model the workflow in an easier and understandable way.
• To model the execution flow among several activities.
• To model comprehensive information of a function or an algorithm employed
within the system.
• To model the business process and its workflow.
• To envision the dynamic aspect of a system.
• To generate the top-level flowcharts for representing the workflow of an
application.
• To represent a high-level view of a distributed or an object-oriented system.