Encapsulation in C++




Encapsulation in C++ is defined as the wrapping up of data and information in a single unit.
In Object Oriented Programming, Encapsulation is defined as binding together the data and
the functions that manipulate them.
Consider a real-life example of encapsulation, in a company, there are different sections like
the accounts section, finance section, sales section, etc. Now,
 The finance section handles all the financial transactions and keeps records of all the data
related to finance.
 Similarly, the sales section handles all the sales-related activities and keeps records of all
the sales.
Now there may arise a situation when for some reason an official from the finance section
needs all the data about sales in a particular month.
In this case, he is not allowed to directly access the data of the sales section. He will first have
to contact some other officer in the sales section and then request him to give the particular
data.
This is what Encapsulation is. Here the data of the sales section and the employees that can
manipulate them are wrapped under a single name “sales section”.
Two Important property of Encapsulation
1. Data Protection: Encapsulation protects the internal state of an object by keeping its data
members private. Access to and modification of these data members is restricted to the
class’s public methods, ensuring controlled and secure data manipulation.
2. Information Hiding: Encapsulation hides the internal implementation details of a class
from external code. Only the public interface of the class is accessible, providing
abstraction and simplifying the usage of the class while allowing the internal
implementation to be modified without impacting external code.
For example if we give input , and output should be half of input
C++

#include <iostream>
using namespace std;
class temp{
int a;
int b;
public:
int solve(int
input){
a=input;
b=a/2;
return b;
}
};

int main() {
int n;
cin>>n;
 temp half;
int
ans=half.solve(n);
cout<<ans<<endl;

Features of Encapsulation
Below are the features of encapsulation:
1. We can not access any function from the class directly. We need an object to
access that function that is using the member variables of that class.
2. The function which we are making inside the class must use only member
variables, only then it is called encapsulation.
3. If we don’t make a function inside the class which is using the member variable of
the class then we don’t call it encapsulation.
4. Encapsulation improves readability, maintainability, and security by grouping data
and methods together.
5. It helps to control the modification of our data members.

Encapsulation also leads to data abstraction. Using encapsulation also hides the
data, as in the above example, the data of the sections like sales, finance, or
accounts are hidden from any other section.
 What is Data hiding?
Data hiding is a technique of hiding internal object details, i.e., data members. It is an object-
oriented programming technique. Data hiding ensures, or we can say guarantees to restrict the
data access to class members. It maintains data integrity.

Data hiding means hiding the internal data within the class to prevent its direct access from
outside the class.

If we talk about data encapsulation so, Data encapsulation hides the private methods and class
data parts, whereas Data hiding only hides class data components. Both data hiding and data
encapsulation are essential concepts of object-oriented programming. Encapsulation wraps up
the complex data to present a simpler view to the user, whereas Data hiding restricts the data use
to assure data security.

Data hiding also helps to reduce the system complexity to increase the robustness by limiting the
interdependencies between software components. Data hiding is achieved by using the private
access specifier.

Example: We can understand data hiding with an example. Suppose we declared an Account class
with a data member balance inside it. Here, the account balance is sensitive information. We may
allow someone to check the account balance but won't allow altering the balance attribute. So, by
declaring the balance attribute private, we can restrict the access to balance from an outside
application.

Now, let's discuss the access specifiers to understand the data hiding. Access specifiers define how
the member's functions and variables can be accessed from outside the class. So, there are three
access specifiers available within a class that are stated as follows:

Private members/methods: Functions and variables declared as private can be accessed only
within the same class, and they cannot be accessed outside the class they are declared.

Public members/methods: Functions and variables declared under public can be accessed from
anywhere.

Protected members/methods: Functions and variables declared as protected cannot be accessed

outside the class except a child class. This specifier is generally used in inheritance.

Now let's see an example of data hiding in C++.

Example

In this example, there is a class with a variable and two functions. Here, the variable "num" is
private so, it can be accessed only by the members of the same class, and it can't be accessed
anywhere else. Hence, it is unable to access this variable outside the class, which is called data
hiding.

1. #include<iostream>
2. using namespace std;
3. class Base{
4.
5. int num; //by default private
6. public:
7.
8. void getData();
9. void showData();
10.
11. };
12. void Base :: getData()
13. {
14. cout<< "Enter any Integer value" <<endl;
15. cin>>num;
16.
17. }
18. void Base :: showData()
19. {
20. cout<< "The value is " << num <<endl;
21. }
22.
23. int main(){
24. Base obj;
25. obj.getData();
26. obj.showData();
27. return 0;
28. }

Output

Enter any Integer value

2
The value is 2

Polymorphism :-

The word “polymorphism” means having many forms. In simple words, we can
define polymorphism as the ability of a message to be displayed in more than one
form. A real-life example of polymorphism is a person who at the same time can
have different characteristics. A man at the same time is a father, a husband, and an
employee. So the same person exhibits different behavior in different situations.
This is called polymorphism. Polymorphism is considered one of the important
features of Object-Oriented Programming.
Types of Polymorphism
 Compile-time Polymorphism
 Runtime Polymorphism
 Types of Polymorphism

1. Compile-Time Polymorphism
This type of polymorphism is achieved by function overloading or operator
overloading.

A. Function Overloading

When there are multiple functions with the same name but different parameters,
then the functions are said to be overloaded, hence this is known as Function
Overloading. Functions can be overloaded by changing the number of
arguments or/and changing the type of arguments. In simple terms, it is a feature
of object-oriented programming providing many functions that have the same name
but distinct parameters when numerous tasks are listed under one function name.
There are certain Rules of Function Overloading that should be followed while
overloading a function.
Below is the C++ program to show function overloading or compile-time
polymorphism:

B. Operator Overloading

C++ has the ability to provide the operators with a special meaning for a data type,
this ability is known as operator overloading. For example, we can make use of the
addition operator (+) for string class to concatenate two strings. We know that the
task of this operator is to add two operands. So a single operator ‘+’, when placed
between integer operands, adds them and when placed between string operands,
concatenates them.
2. Runtime Polymorphism
This type of polymorphism is achieved by Function Overriding. Late binding and
dynamic polymorphism are other names for runtime polymorphism. The function call
is resolved at runtime in runtime polymorphism. In contrast, with compile time
polymorphism, the compiler determines which function call to bind to the object after
deducing it at runtime.

A. Function Overriding

Function Overriding occurs when a derived class has a definition for one of the
member functions of the base class. That base function is said to be overridden.

Runtime Polymorphism with Data Members

Runtime Polymorphism cannot be achieved by data members in C++. Let’s see an
example where we are accessing the field by reference variable of parent class
which refers to the instance of the derived class.

B. Virtual Function

A virtual function is a member function that is declared in the base class using the
keyword virtual and is re-defined (Overridden) in the derived class.
Some Key Points About Virtual Functions:
 Virtual functions are Dynamic in nature.
 They are defined by inserting the keyword “virtual” inside a base class and are
always declared with a base class and overridden in a child class
 A virtual function is called during Runtime

Importance of Modeling
Modeling is a proven & well accepted engineering techniques. In building

architecture, we develop architectural models of houses & high rises to help

visualize the final products. In Unified Modeling Language (UML), a model may be

structural, emphasizing the organization of the system or it may be behavioral,

emphasizing the dynamics of the system. A model is a simplification of reality,

providing blueprints of a system. UML, in specific:

 Permits you to specify the structure or behavior of a system.
 Helps you visualize a system.
 Provides template that guides you in constructing a system.
 Helps to understand complex system part by part.
 Document the decisions that you have made.

We build model so that we can better understand the system we are developing. A model

may encompass an overview of the system under consideration, as well as a detailed

planning for system design, implementation and testing.

Principles of UML Modeling

1. The choice of model is important
 The choice of what models to create has a profound influence on how a problem is

attacked and how a solution is shaped. We need to choose your models well.
 The right models will highlight the most critical development problems.
 Wrong models will mislead you, causing you to focus on irrelevant issues.

For Example: We can use different types of diagrams for different phases in software

development.

2. Every model may be expressed at different levels of

precision
For Example,
 If you are building a high rise, sometimes you need a 30,000-foot view for
instance, to help your investors visualize its look and feel.
 Other times, you need to get down to the level of the studs for instance, when
there's a tricky pipe run or an unusual structural element.

3. The best models are connected to reality

All models simplify reality and a good model reflects important key characteristics.

4. No single model is sufficient

Every non-trivial system is best approached through a small set of nearly independent

models. Create models that can be built and studied separately, but are still

interrelated. In the case of a building:

 You can study electrical plans in isolation
 But you can also see their mapping to the floor plan and perhaps even their
interaction with the routing of pipes in the plumbing plan.
Object Oriented Modeling :-
Object-oriented modeling is a methodology for designing and representing systems based on the
principles of object-oriented programming (OOP). It involves creating models that represent the
structure, behavior, and interactions of the various entities within a system using objects, classes,
inheritance, encapsulation, and other OOP concepts. Object-oriented modeling is widely used in
software engineering for designing and developing complex systems. Here are some key aspects
of object-oriented modeling:

.
 Objects: Objects are the basic building blocks of an object-oriented model. They represent real-
world entities or concepts and encapsulate both data (attributes) and behavior (methods or
functions) related to those entities.
.
.
Classes: Classes serve as blueprints or templates for creating objects. They define the common
attributes and behaviors shared by a group of similar objects. Classes encapsulate the common
properties and behaviors that objects of the same type share.
.
.
Encapsulation: Encapsulation is the bundling of data (attributes) and methods (behaviors) within a
single unit or object. It allows for data hiding, where the internal state of an object is hidden from
external access, and only accessible through well-defined interfaces (methods).
.
.
Inheritance: Inheritance is a mechanism that allows a class (subclass or derived class) to inherit
attributes and behaviors from another class (superclass or base class). It promotes code reusability
and enables the creation of hierarchical relationships between classes.
.
.
Polymorphism: Polymorphism allows objects of different classes to be treated as objects of a
common superclass. It enables the same method to behave differently based on the specific
context or type of object it operates on, promoting flexibility and extensibility in the model.
.
.
Abstraction: Abstraction is the process of simplifying complex systems by focusing on the
essential characteristics while ignoring unnecessary details. In an object-oriented model,
abstraction is achieved through the creation of classes and objects that represent real-world
entities or concepts.
.
.
Modularity: Modularity is the principle of dividing a system into smaller, manageable components
or modules. In object-oriented modeling, classes and objects serve as modular units that can be
independently developed, tested, and maintained, enhancing scalability and maintainability.
.
.
Message Passing: In an object-oriented model, communication between objects occurs through
message passing. Objects interact by sending messages to one another, triggering method
invocations and exchanging data.
.

Object-oriented modeling provides a powerful and flexible framework for designing, analyzing,
and implementing systems by organizing software components into modular, reusable, and
maintainable units that closely mirror real-world entities and relationships. It helps improve
software quality, promotes code reuse, and enhances the overall efficiency of the development
process.

Introduction to UML :-

The 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.

The UML was developed in 1994-95 by Grady Booch, Ivar Jacobson, and James Rumbaugh at the
Rational Software. In 1997, it got adopted as a standard by the Object Management Group (OMG).

The Object Management Group (OMG) is an association of several companies that controls the
open standard UML. The OMG was established to build an open standard that mainly supports the
interoperability of object-oriented systems. It is not restricted within the boundaries, but it can also
be utilized for modeling the non-software systems. The OMG is best recognized for the Common
Object Request Broker Architecture (CORBA) standards.

Goal of UML :-

o Since it is a general-purpose modeling language, it can be utilized by all the modelers.

o 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.
o 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.
o 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:

o It is a generalized modeling language.

o It is distinct from other programming languages like C++, Python, etc.
o It is interrelated to object-oriented analysis and design.
o It is used to visualize the workflow of the system.
o It is a pictorial language, used to generate powerful modeling artifacts.

Conceptual Model of the UML :-

UML is a standard visual language for describing and modelling software blueprints.
The UML is more than just a graphical language. Stated formally, the UML is for:
Visualizing, Specifying, Constructing, and Documenting. The artifacts of a software-
intensive system (particularly systems built using the object-oriented style).
Three Aspects of UML:
Figure –
Three Aspects of UML
Note –
Language, Model, and Unified are the important aspect of UML as described in the
map above.
1. Language:
 It enables us to communicate about a subject which includes the requirements
and the system.
 It is difficult to communicate and collaborate for a team to successfully develop a
system without a language.
2. Model:
 It is a representation of a subject.
 It captures a set of ideas (known as abstractions) about its subject.
3. Unified:
 It is to bring together the information systems and technology industry’s best
engineering practices.
 These practices involve applying techniques that allow us to successfully develop
systems.
A Conceptual Model:
A conceptual model of the language underlines the three major elements:
• The Building Blocks
• The Rules
• Some Common Mechanisms
Once you understand these elements, you will be able to read and recognize the
models as well as create some of them.
Figure –
A Conceptual Model of the UML
Building Blocks:
The vocabulary of the UML encompasses three kinds of building blocks:
1. Things: Things are the abstractions that are first-class citizens in a model;
relationships tie these things together; diagrams group interesting collections of
things. There are 4 kinds of things in the UML:
1. Structural things
2. Behavioral things
3. Grouping things
4. Annotational things

2.
These things are the basic object-oriented building blocks of the UML. You use them
to write well-formed models.
3.
4. Relationships: There are 4 kinds of relationships in the UML:
1. Dependency
2. Association
3. Generalization
4. Realization

5.
These relationships are the basic relational building blocks of the UML.
6.
7. Diagrams: It is the graphical presentation of a set of elements. It is rendered as
a connected graph of vertices (things) and arcs (relationships).
1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. Statechart diagram
7. Activity diagram
8. Component diagram
9. Deployment diagram

8.
Rules:
The UML has a number of rules that specify what a well-formed model should look
like. A well-formed model is one that is semantically self-consistent and in harmony
with all its related models. The UML has semantic rules for:
1.Names – What you can call things, relationships, and diagrams.
2.Scope – The context that gives specific meaning to a name.
3.Visibility – How those names can be seen and used by others.
4.Integrity – How things properly and consistently relate to one another.
5.Execution – What it means to run or simulate a dynamic model.
Common Mechanisms:
The UML is made simpler by the four common mechanisms. They are as follows:
1. Specifications
2. Adornments
3. Common divisions
4. Extensibility mechanisms
Feeling lost in the vast world of System Design? It's time for a transformation! Enroll
in our Mastering System Design From Low-Level to High-Level Solutions - Live
Course and embark on an exhilarating journey to efficiently master system design
concepts and techniques.
What We Offer:
 Comprehensive Course Coverage
 Expert Guidance for Efficient Learning
 Hands-on Experience with Real-world System Design Project
 Proven Track Record with 100,000+ Successful Enthusiasts

UML- Architecture
Software architecture is all about how a software system is built at its highest level. It is needed to
think big from multiple perspectives with quality and design in mind. The software team is tied to
many practical concerns, such as:

o The structure of the development team.

o The needs of the business.
o Development cycle.
o The intent of the structure itself.

Software architecture provides a basic design of a complete software system. It defines the
elements included in the system, the functions each element has, and how each element relates to
one another. In short, it is a big picture or overall structure of the whole system, how everything
works together.

To form an architecture, the software architect will take several factors into consideration:

o What will the system be used for?

o Who will be using the system?
o What quality matters to them?
o Where will the system run?

The architect plans the structure of the system to meet the needs like these. It is essential to have
proper software architecture, mainly for a large software system. Having a clear design of a
complete system as a starting point provides a solid basis for developers to follow.

Each developer will know what needs to be implemented and how things relate to meet the
desired needs efficiently. One of the main advantages of software architecture is that it provides
high productivity to the software team. The software development becomes more effective as it
comes up with an explained structure in place to coordinate work, implement individual features,
or ground discussions on potential issues. With a lucid architecture, it is easier to know where the
key responsibilities are residing in the system and where to make changes to add new
requirements or simply fixing the failures.

In addition, a clear architecture will help to achieve quality in the software with a well-designed
structure using principles like separation of concerns; the system becomes easier to maintain,
reuse, and adapt. The software architecture is useful to people such as software developers, the
project manager, the client, and the end-user. Each one will have different perspectives to view the
system and will bring different agendas to a project. Also, it provides a collection of several views.
It can be best understood as a collection of five views:

1. Use case view

2. Design view
3. Implementation view
4. Process view
5. Development view

Use case view

o It is a view that shows the functionality of the system as perceived by external actors.
o It reveals the requirements of the system.
o With UML, it is easy to capture the static aspects of this view in the use case diagrams,
whereas it?s dynamic aspects are captured in interaction diagrams, state chart diagrams,
and activity diagrams.

Design View

o It is a view that shows how the functionality is designed inside the system in terms of
static structure and dynamic behavior.
 o It captures the vocabulary of the problem space and solution space.
o With UML, it represents the static aspects of this view in class and object diagrams,
whereas its dynamic aspects are captured in interaction diagrams, state chart diagrams,
and activity diagrams.

Implementation View

o It is the view that represents the organization of the core components and files.
o It primarily addresses the configuration management of the system?s releases.
o With UML, its static aspects are expressed in component diagrams, and the dynamic
aspects are captured in interaction diagrams, state chart diagrams, and activity diagrams.

Process View

o It is the view that demonstrates the concurrency of the system.

o It incorporates the threads and processes that make concurrent system and synchronized
mechanisms.
o It primarily addresses the system's scalability, throughput, and performance.
o Its static and dynamic aspects are expressed the same way as the design view but focus
more on the active classes that represent these threads and processes.

Deployment View

o It is the view that shows the deployment of the system in terms of physical architecture.
o It includes the nodes, which form the system hardware topology where the system will be
executed.
o It primarily addresses the distribution, delivery, and installation of the parts that build the
physical system.

1. Classes:-

A class is a description of a set of objects that share the same

attributes, operations, relationships, and semantics. Graphically, a
class is rendered as a rectangle.

Names:-

Every class must have a name that distinguishes it from other

classes. A name is a textual string. That name alone is known as a
simple name; a qualified name is the class name prefixed by the name
of the package in which that class lives. A class may be drawn
showing only its name
Attributes :-
An attribute is a named property of a class that describes a range of
values that instances of the property may hold. A class may have any
number of attributes or no attributes at all. An attribute represents
some property of the thing you are modeling that is shared by all
objects of that class. For example, every wall has a height, width,
and thickness; you might model your customers in such a way that each
has a name, address, phone number, and date of birth.

Operations :-

An operation is the implementation of a service that can be requested

from any object of the class to affect behavior. In other words, an
operation is an abstraction of something you can do to an object that
is shared by all objects of that class. A class may have any number
of operations or no operations at all. For example, in a windowing
library such as the one found in Java's awt package, all objects of
the class Rectangle can be moved, resized, or queried for their
properties. Often (but not always), invoking an operation on an
object changes the object's data or state. Graphically, operations
are listed in a compartment just below the class attributes.
Operations may be drawn showing only their names.
You can specify an operation by stating its signature, which includes
the name, type, and default value of all parameters and (in the case
of functions) a return type.

Organizing Attributes and Operations When drawing a class, you don't

have to show every attribute and every operation at once. In fact, in
most cases, you can't (there are too many of them to put in one
figure) and you probably shouldn't (only a subset of these attributes
and operations are likely to be relevant to a specific view). For
these reasons, you can elide a class, meaning that you can choose to
show only some
or none of a class's attributes and operations. You can indicate that
there are more attributes or properties than shown by ending each
list with an ellipsis ("...").

Responsibilities :-

A responsibility is a contract or an obligation of a class. When you

create a class, you are making a statement that all objects of that
class have the same kind of state and the same kind of behavior. At a
more abstract level, these corresponding attributes and operations
are just the features by which the class's responsibilities are
carried out. A Wall class is responsible for knowing about height,
width, and thickness; a FraudAgent class, as you might find in a
credit card application, is responsible for processing orders and
determining if they are legitimate, suspect, or fraudulent; a
TemperatureSensor class is responsible for measuring temperature and
raising an alarm if the temperature reaches a certain point.
Common Modeling Techniques

Modeling the Vocabulary of a System :-

You'll use classes most commonly to model abstractions that are drawn
from the problem you are trying to solve or from the technology you
are using to implement a solution to that problem. Each of these
abstractions is a part of the vocabulary of your system, meaning
that, together, they represent the things that are important to users
and to implementers.

To model the vocabulary of a system:-

1.Identify those things that users or implementers use to describe

the problem or solution. Use CRC cards and use case-based analysis to
help find these abstractions.
2.For each abstraction, identify a set of responsibilities. Make sure
that each class is crisply defined and that there is a good balance
of responsibilities among all your classes.
3.Provide the attributes and operations that are needed to carry out
these responsibilities for each class.

A set of classes drawn from a retail system, including Customer,

Order, and Product. This figure includes a few other related
abstractions drawn from the vocabulary of the problem, such as
Shipment (used to track orders), Invoice (used to bill orders), and
Warehouse (where products are located prior to shipment). There is
also one solution-related abstraction, TRansaction, which applies to
orders and shipments.
Modeling the Distribution of Responsibilities in a System :-

Once you start modeling more than just a handful of classes, you will
want to be sure that your abstractions provide a balanced set of
responsibilities. To model the distribution of responsibilities in a
system,

1. Identify a set of classes that work together closely to carry out

some behavior.
2. Identify a set of responsibilities for each of these classes.
3. Look at this set of classes as a whole, split classes that have
too many responsibilities into smaller abstractions, collapse tiny
classes that have trivial responsibilities into larger ones, and
reallocate responsibilities so that each abstraction reasonably
stands on its own.
4. Consider the ways in which those classes collaborate with one
another, and redistribute their responsibilities accordingly so that
no class within a collaboration does too much or too little.
Modeling Nonsoftware Things

To model nonsoftware things,

1. Model the thing you are abstracting as a class.

2. If you want to distinguish these things from the UML's defined
building blocks, create a new building block by using stereotypes to
specify these new semantics and to give a distinctive visual cue.
3. If the thing you are modeling is some kind of hardware that itself
contains software, consider modeling it as a kind of node as well, so
that you can further expand on its structure.

Modeling Primitive Types

To model primitive types,

1. Model the thing you are abstracting as a class or an enumeration,

which is rendered using class notation with the appropriate
stereotype.
2. If you need to specify the range of values associated with this
type, use constraints.
3. Relationships:

A relationship is a connection among things. In object-oriented

modeling, the three most important relationships are dependencies,
generalizations, and associations. Graphically, a relationship is
rendered as a path, with different kinds of lines used to distinguish
the kinds of relationships.

Dependencies:-

A dependency is a relationship that states that one thing (for

example, class Window) uses the information and services of another
thing (for example, class Event), but not necessarily the reverse.
Graphically, a dependency is rendered as a dashed directed line,
directed to the thing being depended on. Choose dependencies when you
want to show one thing using another.

Generalizations:-

A generalization is a relationship between a general kind of thing

(called the superclass or parent) and a more specific kind of thing
(called the subclass or child). Generalization is sometimes called an
"is-a-kind-of" relationship: one thing (like the class BayWindow) is-
a-kindof a more general thing (for example, the class Window). An
objects of the child class may be used for a variable or parameter
typed by the parent, but not the reverse
Associations:-

An association is a structural relationship that specifies that

objects of one thing are connected to objects of another. Given an
association connecting two classes, you can relate objects of one
class to objects of the other class. It's quite legal to have both
ends of an association circle back to the same class. This means
that, given an object of the class, you can link to other objects of
the same class. An association that connects exactly two classes is
called a binary association. Although it's not as common, you can
have associations that connect more than two classes; these are
called n-ary associations.

Beyond this basic form, there are four adornments that apply to
associations.

Name :-

An association can have a name, and you use that name to describe the
nature of the relationship. So that there is no ambiguity about its
meaning, you can give a direction to the name by providing a
direction triangle that points in the direction you intend to read
the name.
Role :-

When a class participates in an association, it has a specific role

that it plays in that relationship; a role is just the face the class
at the far end of the association presents to the class at the near
end of the association. You can explicitly name the role a class
plays in an association. The role played by an end of an association
is called an end name (in UML1, it was called a role name). the class
Person playing the role of employee is associated with the class
Company playing the role of employer.

Multiplicity :-

An association represents a structural relationship among objects. In

many modeling situations, it's important for you to state how many
objects may be connected across an instance of an association. This
"how many" is called the multiplicity of an association's role. It
represents a range of integers specifying the possible size of the
set of related objects. The number of objects must be in the given
range. You can show a multiplicity of exactly one (1), zero or one
(0..1), many (0..*), or one or more (1..*). You can give an integer
range (such as 2..5). You can even state an exact number (for
example, 3, which is equivalent to 3..3).

Aggregation :-
A plain association between two classes represents a structural
relationship between peers, meaning that both classes are
conceptually at the same level, no one more important than the other.
Sometimes you will want to model a "whole/part" relationship, in
which one class represents a larger thing (the "whole"), which
consists of smaller things (the "parts"). This kind of relationship
is called aggregation, which represents a "has-a" relationship

Modeling Simple Dependencies:-

A common kind of dependency relationship is the connection between a

class that uses another class as a parameter to an operation. To
model this using relationship,
-> Create a dependency pointing from the class with the operation to
the class used as a parameter in the operation.

a set of classes drawn from a system that manages the assignment of

students and instructors to courses in a university. This figure
shows a dependency from CourseSchedule to Course, because Course is
used in both the add and remove operations of CourseSchedule

Modeling Single Inheritance :-

In modeling the vocabulary of your system, you will often run across
classes that are structurally or behaviorally similar to others. You
could model each of these as distinct and unrelated abstractions. A
better way would be to extract any common structural and behavioral
features and place them in more-general classes from which the
specialized ones inherit. To model inheritance relationships,

-> Given a set of classes, look for responsibilities, attributes, and

operations that are common to two or more classes.
-> Elevate these common responsibilities, attributes, and operations
to a more general class. If necessary, create a new class to which
you can assign these elements (but be careful about introducing too
many levels).
-> Specify that the more-specific classes inherit from the more-
general class by placing a generalization relationship that is drawn
from each specialized class to its more-general parent.
Modeling Structural Relationships :-

When you model with dependencies or generalization relationships, you

may be modeling classes that represent different levels of importance
or different levels of abstraction. Given a dependency between two
classes, one class depends on another but the other class has no
knowledge of the one.

To model structural relationships,

-> For each pair of classes, if you need to navigate from objects of
one to objects of another, specify an association between the two.
This is a data-driven view of associations.
-> For each pair of classes, if objects of one class need to interact
with objects of the other class other than as local variables in a
procedure or parameters to an operation, specify an association
between the two. This is more of a behavior-driven view of
associations.
-> For each of these associations, specify a multiplicity (especially
when the multiplicity is not *, which is the default), as well as
role names (especially if they help to explain the model).
-> If one of the classes in an association is structurally or
organizationally a whole compared with the classes at the other end
that look like parts, mark this as an aggregation by adorning the
association at the end near the whole with a diamond

4. Common Mechanisms:

A note is a graphical symbol for rendering constraints or comments

attached to an element or a collection of elements. Graphically, a
note is rendered as a rectangle with a dog-eared corner, together
with a textual or graphical comment.
A stereotype is an extension of the vocabulary of the UML, allowing
you to create new kinds of building blocks similar to existing ones
but specific to your problem. Graphically, a stereotype is rendered
as a name enclosed by guillemets (French quotation marks of the form
« »), placed above the name of another element.

Optionally the stereotyped element may be rendered by using a new

icon associated with that stereotype.

A tagged value is a property of a stereotype, allowing you to create

new information in an element bearing that stereotype. Graphically, a
tagged value is rendered as a string of the form name = value within
a note attached to the object.

A constraint is a textual specification of the semantics of a UML

element, allowing you to add new rules or to modify existing ones.
Graphically, a constraint is rendered as a string enclosed by
brackets and placed near the associated element or connected to that
element or elements by dependency relationships. As an alternative,
you can render a constraint in a note.

Notes :-

A note that renders a comment has no semantic impact, meaning that

its contents do not alter the meaning of the model to which it is
attached. This is why notes are used to specify things like
requirements, observations, reviews, and explanations, in addition to
rendering constraints. A note may contain any combination of text or
graphics

Other Adornments

Adornments are textual or graphical items that are added to an

element's basic notation and are used to visualize details from the
element's specification
Stereotypes :-

The UML provides a language for structural things, behavioral things,

grouping things, and notational things. These four basic kinds of
things address the overwhelming majority of the systems you'll need
to model.

In its simplest form, a stereotype is rendered as a name enclosed by

guillemets (for example, «name») and placed above the name of another
element.

Tagged Values :-

Every thing in the UML has its own set of properties: classes have
names, attributes, and operations; associations have names and two or
more ends, each with its own properties; and so on. With stereotypes,
you can add new things to the UML; with tagged values, you can add
new properties to a stereotype.

Constraints :-
Everything in the UML has its own semantics. Generalization (usually,
if you know what's good for you) implies the Liskov substitution
principle, and multiple associations connected to one class denote
distinct relationships. With constraints, you can add new semantics
or extend existing rules. A constraint specifies conditions that a
run-time configuration must satisfy to conform to the model.

-> stereotype Specifies that the classifier is a stereotype that may

be applied to other elements

Common Modeling Techniques

Modeling Comments

The most common purpose for which you'll use notes is to write down
free-form observations, reviews, or explanations.

To model a comment,
-> Put your comment as text in a note and place it adjacent to the
element to which it refers. You can show a more explicit relationship
by connecting a note to its elements using a dependency relationship.
-> Remember that you can hide or make visible the elements of your
model as you see fit. This means that you don't have to make your
comments visible everywhere the elements to which it is attached are
visible. Rather, expose your comments in your diagrams only insofar
as you need to communicate that information in that context.
-> If your comment is lengthy or involves something richer than plain
text, consider putting your comment in an external document and
linking or embedding that document in a note attached to your model.
-> As your model evolves, keep those comments that record significant
decisions that cannot be inferred from the model itself, andunless
they are of historic interestdiscard the others.
Modeling New Properties :-

The basic properties of the UML's building blocksattributes and

operations for classes, the contents of packages

To model new properties,

-> First, make sure there's not already a way to express what you
want by using basic UML.
-> If you re convinced there's no other way to express these
semantics, define a stereotype and add the new properties to the
stereotype. The rules of generalization applytagged values defined
for one kind of stereotype apply to its children.

Modeling New Semantics :-

When you create a model using the UML, you work within the rules the
UML lays down. However, if you find yourself needing to express new
semantics about which the UML is silent or that you need to modify
the UML's rules, then you need to write a constraint.

To model new semantics,

-> First, make sure there's not already a way to express what you
want by using basic UML.
-> If you re convinced there's no other way to express these
semantics, write your new semantics in a constraint placed near the
element to which it refers. You can show a more explicit relationship
by connecting a constraint to its elements using a dependency
relationship.
-> If you need to specify your semantics more precisely and formally,
write your new semantics using OCL.

5. Diagrams:-

A system is a collection of subsystems organized to accomplish a

purpose and described by a set of models, possibly from different
viewpoints.

A subsystem is a grouping of elements, some of which constitute a

specification of the behavior offered by the other contained
elements.

A model is a semantically closed abstraction of a system, meaning

that it represents a complete and self-consistent simplification of
reality, created in order to better understand the system. In the
context of architecture,

A view is a projection into the organization and structure of a

system's model, focused on one aspect of that system.

A diagram is the graphical presentation of a set of elements, most

often rendered as a connected graph of vertices (things) and arcs
(relationships).

In modeling real systems, no matter what the problem domain, you'll

find yourself creating the same kinds of diagrams, because they
represent common views into common models. Typically, you'll view the
static parts of a system using one of the following diagrams.
1. Class diagram
2. Component diagram
3. Composite structure diagram
4. Object diagram
5. Deployment diagram
6. Artifact diagram
7.
8. You'll often use five additional diagrams to view the dynamic
parts of a system.

1. Use case diagram

2. Sequence diagram
3. Communication diagram
4. State diagram
5. Activity diagram

Structural Diagrams :-

The UML’s structural diagrams exist to visualize, specify,

construct, and document the static aspects of a system. You can think
of the static aspects of a system as representing its relatively
stable skeleton and scaffolding. Just as the static aspects of a
house encompass the existence and placement of such things as walls,
doors, windows, pipes, wires, and vents, so too do the static aspects
of a software system encompass the existence and placement of such
things as classes, interfaces, collaborations, components, and nodes.

The UML's structural diagrams are roughly organized around the major
groups of things you'll find when modeling a system.

1. Class diagram Classes, interfaces, and collaborations

2.Component diagram Components
2. Object diagram Objects
3. Deployment diagram Nodes

Behavioral Diagrams :-

The UML's behavioral diagrams are used to visualize, specify,

construct, and document the dynamic aspects of a system. You can
think of the dynamic aspects of a system as representing its changing
parts. Just as the dynamic aspects of a house encompass airflow and
traffic through the rooms of a house, so too do the dynamic aspects
of a software system encompass such things as the flow of messages
over time and the physical movement of components across a network.

The UML's behavioral diagrams are roughly organized around the major
ways you can model the dynamics of a system.

1. Use case diagram Organizes the behaviors of the system

2. Sequence diagram Focuses on the time ordering of messages
3.Collaboration diagram Focuses on the structural organization of
objects that send and receive messages
4.State diagram Focuses on the changing state of a system driven by
events
5.Activity diagram Focuses on the flow of control from activity to
activity

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.

Purpose of Class Diagrams

The main purpose of class diagrams is to build a static view of an application. It is the only diagram
that is widely used for construction, and it can be mapped with object-oriented languages. It is one
of the most popular UML diagrams. Following are the purpose of class diagrams given below:

1. It analyses and designs a static view of an application.

2. It describes the major responsibilities of a system.
3. It is a base for component and deployment diagrams.
4. It incorporates forward and reverse engineering.

Benefits of Class Diagrams

1. It can represent the object model for complex systems.

2. It reduces the maintenance time by providing an overview of how an application is
structured before coding.
3. It provides a general schematic of an application for better understanding.
4. It represents a detailed chart by highlighting the desired code, which is to be
programmed.
5. It is helpful for the stakeholders and the developers.

Vital components of a Class Diagram

The class diagram is made up of three sections:

o 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:

1. Capitalize the initial letter of the class name.

2. Place the class name in the center of the upper section.
3. A class name must be written in bold format.
4. The name of the abstract class should be written in italics format.

o Middle Section: The middle section constitutes the attributes, which describe the quality
of the class. The attributes have the following characteristics:
 5. The attributes are written along with its visibility factors, which are public (+),
private (-), protected (#), and package (~).
6. The accessibility of an attribute class is illustrated by the visibility factors.
7. A meaningful name should be assigned to the attribute, which will explain its
usage inside the class.

o 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:

o 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.

o 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.
 o 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.

Let us assume that we have an abstract class named displacement with a method declared inside
it, and that method will be called as a drive (). Now, this abstract class method can be
implemented by any object, for example, car, bike, scooter, cycle, etc.

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:

1. To describe a complete aspect of the system, it is suggested to give a meaningful name to

the class diagram.
 2. The objects and their relationships should be acknowledged in advance.
3. The attributes and methods (responsibilities) of each class must be known.
4. A minimum number of desired properties should be specified as more number of the
unwanted property will lead to a complex diagram.
5. Notes can be used as and when required by the developer to describe the aspects of a
diagram.
6. 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.

Usage of Class diagrams

The class diagram is used to represent a static view of the system. It plays an essential role in the
establishment of the component and deployment diagrams. It helps to construct an executable
code to perform forward and backward engineering for any system, or we can say it is mainly used
for construction. It represents the mapping with object-oriented languages that are C++, Java, etc.
Class diagrams can be used for the following purposes:

1. To describe the static view of a system.

2. To show the collaboration among every instance in the static view.
3. To describe the functionalities performed by the system.
4. To construct the software application using object-oriented languages.

UML Object Diagram

Object diagrams are dependent on the class diagram as they are derived from the class diagram. It
represents an instance of a class diagram. The objects help in portraying a static view of an object-
oriented system at a specific instant.

Both the object and class diagram are similar to some extent; the only difference is that the class
diagram provides an abstract view of a system. It helps in visualizing a particular functionality of a
system.

Notation of an Object Diagram

Purpose of Object Diagram

The object diagram holds the same purpose as that of a class diagram. The class diagram provides
an abstract view which comprises of classes and their relationships, whereas the object diagram
represents an instance at a particular point of time.

The object diagram is actually similar to the concrete (actual) system behavior. The main purpose is
to depict a static view of a system.

Following are the purposes enlisted below:

o It is used to perform forward and reverse engineering.

o It is used to understand object behavior and their relationships practically.
o It is used to get a static view of a system.
o It is used to represent an instance of a system.

Example of Object Diagram

How to draw an Object Diagram?

1. All the objects present in the system should be examined before start drawing the object
diagram.
2. Before creating the object diagram, the relation between the objects must be
acknowledged.
3. The association relationship among the entities must be cleared already.
4. To represent the functionality of an object, a proper meaningful name should be assigned.
5. The objects are to be examined to understand its functionality.

Applications of Object diagrams

The following are the application areas where the object diagrams can be used.

1. To build a prototype of a system.

2. To model complex data structures.
3. To perceive the system from a practical perspective.
4. Reverse engineering.

Class vs. Object diagram

Serial Class Diagram Object Diagram

No.

1. It depicts the static It portrays the real-

view of a system. time behavior of a
system.

2. Dynamic changes are Dynamic changes

not included in the are captured in the
class diagram. object diagram.

3. The data values and It incorporates data

attributes of an values and
instance are not attributes of an
involved here. entity.

4. The object behavior is Objects are the

manipulated in the instances of a class.
 class diagram.

COMMON MODELING TECHNIQUES

1. Modeling Simple Collaborations

To model a collaboration,
• Identify the mechanism you'd like to model. A mechanism represents
some function or behavior of the part of the system you are modeling
that results from the interaction of a society of classes,
interfaces, and other things.
• For each mechanism, identify the classes, interfaces, and other
collaborations that participate in this collaboration. Identify the
relationships among these things as well.
• Use scenarios to walk through these things. Along the way, you'll
discover parts of your model that were missing and parts that were
just plain semantically wrong.
• Be sure to populate these elements with their contents. For
classes, start with getting a good balance of responsibilities. Then,
over time, turn these in to concrete attributes and operations. 2.

Modeling a Logical Database Schema

To model a schema,

• Identify those classes in your model whose state must transcend the
lifetime of their applications.
• Create a class diagram that contains these classes. You can define
your own set of stereotypes and tagged values to address database-
specific details.
• Expand the structural details of these classes. In general, this
means specifying the details of their attributes and focusing on the
associations and their multiplicities that relate these classes.
• Watch for common patterns that complicate physical database design,
such as cyclic associations and one-to-one associations. Where
necessary, create intermediate abstractions to simplify your logical
structure.
• Consider also the behavior of these classes by expanding operations
that are important for data access and data integrity. In general, to
provide a better separation of concerns, business rules concerned
with the manipulation of sets of these objects should be encapsulated
in a layer above these persistent classes.
• Where possible, use tools to help you transform your logical design
into a physical design.

Forward and Reverse Engineering:

 Forward engineering is the process of transforming a model into
code through a mapping to an implementation language. Forward
engineering results in a loss of information, because models written
in the UML are semantically richer than any current object-oriented
programming language. In fact, this is a major reason why you need
models in addition to code. Structural features, such as
collaborations, and behavioral features, such as interactions, can be
visualized clearly in the UML, but not so clearly from raw code.

To forward engineer a class diagram,

• Identify the rules for mapping to your implementation language or

languages of choice. This is something you'll want to do for your
project or your organization as a whole.
• Depending on the semantics of the languages you choose, you may
want to constrain your use of certain UML features. For example, the
UML permits you to model multiple inheritance, but Smalltalk permits
only single inheritance. You can choose to prohibit developers from
modeling with multiple inheritance (which makes your models language-
dependent), or you can develop idioms that transform these richer
features into the implementation language (which makes the mapping
more complex).
• Use tagged values to guide implementation choices in your target
language. You can do this at the level of individual classes if you
need precise control. You can also do so at a higher level, such as
with collaborations or packages.
• Use tools to generate code.

public abstract class EventHandler {

EventHandler successor;
private Integer currentEventID;
private String source; EventHandler() {}
public void handleRequest() {}
}
Reverse engineering is the process of transforming code into a
model through a mapping from a specific implementation language.
Reverse engineering results in a flood of information, some of which
is at a lower level of detail than you'll need to build useful
models. At the same time, reverse engineering is incomplete. There is
a loss of information when forward engineering models into code, and
so you can't completely recreate a model from code unless your tools
encode information in the source comments that goes beyond the
semantics of the implementation language. To reverse engineer a class
diagram, •Identify the rules for mapping from your implementation
language or languages of choice. This is something you'll want to do
for your project or your organization as a whole.
• Using a tool, point to the code you'd like to reverse engineer. Use
your tool to generate a new model or modify an existing one that was
previously forward engineered. It is unreasonable to expect to
reverse engineer a single concise model from a large body of code.
You need to select portion of the code and build the model from the
bottom.
• Using your tool, create a class diagram by querying the model. For
example, you might start with one or more classes, then expand the
diagram by following specific relationships or other neighboring
classes. Expose or hide details of the contents of this class diagram
as necessary to communicate your intent.
• Manually add design information to the model to express the intent
of the design that is missing or hidden in the code.

COMMON MODELING TECHNIQUES

Modeling Object Structures

To model an object structure,
•Identify the mechanism you'd like to model. A mechanism represents
some function or behavior of the part of the system you are modeling
that results from the interaction of a society of classes,
interfaces, and other things.
• Create a collaboration to describe a mechanism.
• For each mechanism, identify the classes, interfaces, and other
elements that participate in this collaboration; identify the
relationships among these things as well.
•Consider one scenario that walks through this mechanism. Freeze that
scenario at a moment in time, and render each object that
participates in the mechanism.
•Expose the state and attribute values of each such object, as
necessary, to understand the scenario.
•Similarly, expose the links among these objects, representing
instances of associations among them.

FORWARD AND REVERSE ENGINEERING

Forward engineering ( the creation of code from a model) an

object diagram is theoretically possible but pragmatically of limited
value. In an object-oriented system, instances are things that are
created and destroyed by the application during run time. Therefore,
you cannot exactly instantiate these objects from the outside.

Reverse engineering (the creation of a model from code) an

object diagram can be useful. In fact, while you are debugging your
system, this is something that you or your tools will do all the
time. For example, if you are chasing down a dangling link, you'll
want to literally or mentally draw an object diagram of the affected
objects to see where, at a given moment in time, an object's state or
its relationship to other objects is broken. To reverse engineer an
object diagram,

•Chose the target you want to reverse engineer. Typically, you'll set
your context inside an operation or relative to an instance of one
particular class.
• Using a tool or simply walking through a scenario, stop execution
at a certain moment in time.
• Identify the set of interesting objects that collaborate in that
context and render them in an object diagram.
• As necessary to understand their semantics, expose these object's
states.
• As necessary to understand their semantics, identify the links that
exist among these objects.

UML Collaboration Diagram

The collaboration diagram is used to show the relationship between the objects in a system. Both
the sequence and the collaboration diagrams represent the same information but differently.
Instead of showing the flow of messages, it depicts the architecture of the object residing in the
system as it is based on object-oriented programming. An object consists of several features.
Multiple objects present in the system are connected to each other. The collaboration diagram,
which is also known as a communication diagram, is used to portray the object's architecture in the
system.

Notations of a Collaboration Diagram

Following are the components of a component diagram that are enlisted below:

1. Objects: The representation of an object is done by an object symbol with its name and
class underlined, separated by a colon.
In the collaboration diagram, objects are utilized in the following ways:
o The object is represented by specifying their name and class.
o It is not mandatory for every class to appear.
o A class may constitute more than one object.
o In the collaboration diagram, firstly, the object is created, and then its class is
specified.
o To differentiate one object from another object, it is necessary to name them.
2. Actors: In the collaboration diagram, the actor plays the main role as it invokes the
interaction. Each actor has its respective role and name. In this, one actor initiates the use
case.
3. Links: The link is an instance of association, which associates the objects and actors. It
portrays a relationship between the objects through which the messages are sent. It is
represented by a solid line. The link helps an object to connect with or navigate to another
object, such that the message flows are attached to links.
4. Messages: It is a communication between objects which carries information and includes
a sequence number, so that the activity may take place. It is represented by a labeled
arrow, which is placed near a link. The messages are sent from the sender to the receiver,
and the direction must be navigable in that particular direction. The receiver must
understand the message.
When to use a Collaboration Diagram?
The collaborations are used when it is essential to depict the relationship between the object. Both
the sequence and collaboration diagrams represent the same information, but the way of
portraying it quite different. The collaboration diagrams are best suited for analyzing use cases.

Following are some of the use cases enlisted below for which the collaboration diagram is
implemented:

1. To model collaboration among the objects or roles that carry the functionalities of use
cases and operations.
2. To model the mechanism inside the architectural design of the system.
3. To capture the interactions that represent the flow of messages between the objects and
the roles inside the collaboration.
4. To model different scenarios within the use case or operation, involving a collaboration of
several objects and interactions.
5. To support the identification of objects participating in the use case.
6. In the collaboration diagram, each message constitutes a sequence number, such that the
top-level message is marked as one and so on. The messages sent during the same call
are denoted with the same decimal prefix, but with different suffixes of 1, 2, etc. as per
their occurrence.

Steps for creating a Collaboration Diagram

1. Determine the behavior for which the realization and implementation are specified.
 2. Discover the structural elements that are class roles, objects, and subsystems for
performing the functionality of collaboration.

o Choose the context of an interaction: system, subsystem, use case, and operation.

3. Think through alternative situations that may be involved.

o Implementation of a collaboration diagram at an instance level, if needed.

o A specification level diagram may be made in the instance level sequence
diagram for summarizing alternative situations.

Example of a Collaboration Diagram

Benefits of a Collaboration Diagram

1. The collaboration diagram is also known as Communication Diagram.

2. It mainly puts emphasis on the structural aspect of an interaction diagram, i.e., how
lifelines are connected.
3. The syntax of a collaboration diagram is similar to the sequence diagram; just the
difference is that the lifeline does not consist of tails.
4. The messages transmitted over sequencing is represented by numbering each individual
message.
5. The collaboration diagram is semantically weak in comparison to the sequence diagram.
6. The special case of a collaboration diagram is the object diagram.
7. It focuses on the elements and not the message flow, like sequence diagrams.
 8. Since the collaboration diagrams are not that expensive, the sequence diagram can be
directly converted to the collaboration diagram.
9. There may be a chance of losing some amount of information while implementing a
collaboration diagram with respect to the sequence diagram.

The drawback of a Collaboration Diagram

1. Multiple objects residing in the system can make a complex collaboration diagram, as it
becomes quite hard to explore the objects.
2. It is a time-consuming diagram.
3. After the program terminates, the object is destroyed.
4. As the object state changes momentarily, it becomes difficult to keep an eye on every
single that has occurred inside the object of a system.

Polymorphism in Collaboration Diagram :-

In collaboration diagrams, also known as communication diagrams, polymorphism can be depicted

to show how objects of different classes can respond to the same message in different ways.
Collaboration diagrams illustrate interactions between objects in a system, emphasizing the flow of
messages and the relationships between objects.

Here's how polymorphism can be represented in a collaboration diagram:

.
Objects of Different Classes: In a collaboration diagram, you may have objects belonging to
different classes participating in the interaction. These objects may have different behaviors
(methods) defined within their respective classes.
.
.
Message Passing: Messages are depicted as arrows between objects, indicating the flow of
communication. When an object sends a message to another object, it invokes a method
associated with that message. Polymorphism allows different objects to respond to the same
message with different implementations of the method.
.
.
Dynamic Binding: Polymorphism involves dynamic binding, where the appropriate method
implementation is determined at runtime based on the type of object receiving the message. In a
collaboration diagram, this dynamic behavior can be illustrated by showing multiple objects
responding to the same message with different behaviors.
.
.
Generalization Relationships: Collaboration diagrams may also include generalization
relationships between classes. In the context of polymorphism, this illustrates how subclasses can
override methods inherited from their superclass, providing specialized implementations of those
methods.
.
 Here's a simple example to illustrate polymorphism in a collaboration diagram:

Consider a scenario where you have two classes: Shape and its subclasses Circle and Square.
Both Circle and Square classes have a method called draw(), but each class implements this
method differently.

In the collaboration diagram:

 You would represent objects of both Circle and Square classes participating in the interaction.
 When a message such as draw() is sent to these objects, each object responds to the message
with its own implementation of the draw() method.
 This demonstrates polymorphism, as objects of different classes respond to the same message
(draw()) with different behaviors.

In summary, collaboration diagrams can effectively illustrate polymorphism by showing how

objects of different classes respond to the same message with different behaviors, highlighting the
dynamic and flexible nature of object-oriented systems.

Sequence Diagram
The sequence diagram represents the flow of messages in the system and is also termed as an
event diagram. It helps in envisioning several dynamic scenarios. It portrays the communication
between any two lifelines as a time-ordered sequence of events, such that these lifelines took part
at the run time. In UML, the lifeline is represented by a vertical bar, whereas the message flow is
represented by a vertical dotted line that extends across the bottom of the page. It incorporates
the iterations as well as branching.

Purpose of a Sequence Diagram

1. To model high-level interaction among active objects within a system.

2. To model interaction among objects inside a collaboration realizing a use case.
3. It either models generic interactions or some certain instances of interaction.

1. Sequence Diagram Notation

1.1. Actors
An actor in a UML diagram represents a type of role where it interacts with the system and
its objects. It is important to note here that an actor is always outside the scope of the
system we aim to model using the UML diagram.
We use actors to depict various roles including human users and other external subjects.
We represent an actor in a UML diagram using a stick person notation. We can have
multiple actors in a sequence diagram.
For example:
Here the user in seat reservation system is shown as an actor where it
exists outside the system and is not a part of the system.
1.2. Lifelines
A lifeline is a named element which depicts an individual participant in a sequence diagram.
So basically each instance in a sequence diagram is represented by a lifeline. Lifeline
elements are located at the top in a sequence diagram. The standard in UML for naming a
lifeline follows the following format:
Instance Name : Class Name
We display a lifeline in a rectangle called head with its name and type. The head is located
on top of a vertical dashed line (referred to as the stem) as shown above.
 If we want to model an unnamed instance, we follow the same pattern except now the
portion of lifeline’s name is left blank.
 Difference between a lifeline and an actor
 A lifeline always portrays an object internal to the system whereas actors are used to
depict objects external to the system.
The following is an example of a sequence diagram:
1.3. Messages
Communication between objects is depicted using messages. The messages appear in a
sequential order on the lifeline.
 We represent messages using arrows.
 Lifelines and messages form the core of a sequence diagram.
Messages can be broadly classified into the following categories:
Synchronous messages
A synchronous message waits for a reply before the interaction can move forward. The
sender waits until the receiver has completed the processing of the message. The caller
continues only when it knows that the receiver has processed the previous message i.e. it
receives a reply message.
 A large number of calls in object oriented programming are synchronous.
 We use a solid arrow head to represent a synchronous message.
Asynchronous Messages
An asynchronous message does not wait for a reply from the receiver. The interaction
moves forward irrespective of the receiver processing the previous message or not. We use
a lined arrow head to represent an asynchronous message.
1.4. Create message
We use a Create message to instantiate a new object in the sequence diagram. There are
situations when a particular message call requires the creation of an object. It is
represented with a dotted arrow and create word labelled on it to specify that it is the create
Message symbol.
For example:
The creation of a new order on a e-commerce website would require a new
object of Order class to be created.
1.5. Delete Message
We use a Delete Message to delete an object. When an object is deallocated memory or is
destroyed within the system we use the Delete Message symbol. It destroys the occurrence
of the object in the system.It is represented by an arrow terminating with a x.
For example:
In the scenario below when the order is received by the user, the object of
order class can be destroyed.
1.6. Self Message
Certain scenarios might arise where the object needs to send a message to itself. Such
messages are called Self Messages and are represented with a U shaped arrow.
Another example:
Consider a scenario where the device wants to access its webcam. Such a
scenario is represented using a self message.
1.7. Reply Message
Reply messages are used to show the message being sent from the receiver to the sender.
We represent a return/reply message using an open arrow head with a dotted line. The
interaction moves forward only when a reply message is sent by the receiver.
For example:
Consider the scenario where the device requests a photo from the user.
Here the message which shows the photo being sent is a reply message.
1.8. Found Message
A Found message is used to represent a scenario where an unknown source sends the
message. It is represented using an arrow directed towards a lifeline from an end point.
For example:
Consider the scenario of a hardware failure.
It can be due to multiple reasons and we are not certain as to what caused the hardware
failure.
1.9. Lost Message
A Lost message is used to represent a scenario where the recipient is not known to the
system. It is represented using an arrow directed towards an end point from a lifeline.
For example:
Consider a scenario where a warning is generated.
The warning might be generated for the user or other software/object that the lifeline is
interacting with. Since the destination is not known before hand, we use the Lost Message
symbol.
1.10. Guards
To model conditions we use guards in UML. They are used when we need to restrict the
flow of messages on the pretext of a condition being met. Guards play an important role in
letting software developers know the constraints attached to a system or a particular
process.
For example:
In order to be able to withdraw cash, having a balance greater than zero is
a condition that must be met as shown below.
The above sequence diagram depicts the sequence diagram for an emotion based music
player:
1. Firstly the application is opened by the user.
2. The device then gets access to the web cam.
3. The webcam captures the image of the user.
4. The device uses algorithms to detect the face and predict the mood.
5. It then requests database for dictionary of possible moods.
6. The mood is retrieved from the database.
7. The mood is displayed to the user.
8. The music is requested from the database.
9. The playlist is generated and finally shown to the user.
2. How to create Sequence Diagrams?
Creating a sequence diagram involves several steps, and it’s typically done during the
design phase of software development to illustrate how different components or objects
interact over time. Here’s a step-by-step guide on how to create sequence diagrams:
1. Identify the Scenario:
 Understand the specific scenario or use case that you want to represent in the sequence
diagram. This could be a specific interaction between objects or the flow of messages in
a particular process.
2. List the Participants:
 Identify the participants (objects or actors) involved in the scenario. Participants can be
users, systems, or external entities.
3. Define Lifelines:
 Draw a vertical dashed line for each participant, representing the lifeline of each object
over time. The lifeline represents the existence of an object during the interaction.
4. Arrange Lifelines:
 Position the lifelines horizontally in the order of their involvement in the interaction. This
helps in visualizing the flow of messages between participants.
5. Add Activation Bars:
 For each message, draw an activation bar on the lifeline of the sending participant. The
activation bar represents the duration of time during which the participant is actively
processing the message.
6. Draw Messages:
 Use arrows to represent messages between participants. Messages flow horizontally
between lifelines, indicating the communication between objects. Different types of
messages include synchronous (solid arrow), asynchronous (dashed arrow), and self-
messages.
7. Include Return Messages:
 If a participant sends a response message, draw a dashed arrow returning to the original
sender to represent the return message.
8. Indicate Timing and Order:
 Use numbers to indicate the order of messages in the sequence. You can also use
vertical dashed lines to represent occurrences of events or the passage of time.
9. Include Conditions and Loops:
 Use combined fragments to represent conditions (like if statements) and loops in the
interaction. This adds complexity to the sequence diagram and helps in detailing the
control flow.
10. Consider Parallel Execution:
 If there are parallel activities happening, represent them by drawing parallel vertical
dashed lines and placing the messages accordingly.
11. Review and Refine:
 Review the sequence diagram for clarity and correctness. Ensure that it accurately
represents the intended interaction. Refine as needed.
12. Add Annotations and Comments:
 Include any additional information, annotations, or comments that provide context or
clarification for elements in the diagram.
13. Document Assumptions and Constraints:
 If there are any assumptions or constraints related to the interaction, document them
alongside the diagram.
14. Tools:
 Use a UML modeling tool or diagramming software to create a neat and professional-
looking sequence diagram. These tools often provide features for easy editing,
collaboration, and documentation.
3. Use cases of Sequence Diagrams
 System Behavior Visualization:
 Sequence diagrams are used to illustrate the dynamic behavior of a system by showing
the interactions among various components, objects, or actors over time.
 They provide a clear and visual representation of the flow of messages and events in a
specific scenario.
 Software Design and Architecture:
 During the design phase of software development, sequence diagrams help developers
and architects plan and understand how different components and objects will interact to
accomplish specific functionalities.
 They provide a blueprint for the system’s behavior.
 Communication and Collaboration:
 Sequence diagrams serve as a communication tool among stakeholders, including
developers, designers, project managers, and clients.
 They help in conveying complex interactions in an easy-to-understand visual format,
fostering collaboration and shared understanding.
 Requirements Clarification:
 When refining system requirements, sequence diagrams can be used to clarify and
specify the expected interactions between system components or between the system
and external entities.
 They help ensure a common understanding of system behavior among all stakeholders.
 Debugging and Troubleshooting:
 Developers use sequence diagrams as a debugging tool to identify and analyze issues
related to the order and timing of messages during system interactions.
 It provides a visual representation of the flow of control and helps in locating and
resolving problems.
4. Challenges of using Sequence Diagrams
 Complexity and Size:
 As systems grow in complexity, sequence diagrams can become large and intricate.
Managing the size of the diagram while still accurately representing the interactions can
be challenging, and overly complex diagrams may become difficult to understand.
 Abstraction Level:
 Striking the right balance in terms of abstraction can be challenging. Sequence diagrams
need to be detailed enough to convey the necessary information, but too much detail
can overwhelm readers. It’s important to focus on the most critical interactions without
getting bogged down in minutiae.
 Dynamic Nature:
 Sequence diagrams represent dynamic aspects of a system, and as a result, they may
change frequently during the development process. Keeping sequence diagrams up-to-
date with the evolving system can be a challenge, especially in rapidly changing or agile
development environments.
 Ambiguity in Messages:
 Sometimes, it can be challenging to define the exact nature of messages between
objects. Ambiguity in message content or meaning may lead to misunderstandings
among stakeholders and impact the accuracy of the sequence diagram.
 Concurrency and Parallelism:
 Representing concurrent and parallel processes can be complex. While sequence
diagrams have mechanisms to indicate parallel execution, visualizing multiple
interactions happening simultaneously can be challenging and may require additional
diagrammatic elements.
 Real-Time Constraints:
 Representing real-time constraints and precise timing requirements can be challenging.
While sequence diagrams provide a sequential representation, accurately capturing and
communicating real-time aspects might require additional documentation or
complementary diagrams.
Behavioral UML diagrams
Behavioral UML diagrams focus on illustrating the dynamic aspects of a software system,
showcasing how it behaves, responds to stimuli, and undergoes state changes during
runtime.

1. What is a Use Case Diagram in UML?

A Use Case Diagram is a type of Unified Modeling Language (UML) diagram that
represents the interaction between actors (users or external systems) and a system under
consideration to accomplish specific goals. It provides a high-level view of the system’s
functionality by illustrating the various ways users can interact with it.
2. Use Case Diagram Notations
UML notations provide a visual language that enables software developers, designers, and
other stakeholders to communicate and document system designs, architectures, and
behaviors in a consistent and understandable manner.

1.1. Actors

Actors are external entities that interact with the system. These can include users, other
systems, or hardware devices. In the context of a Use Case Diagram, actors initiate use
cases and receive the outcomes. Proper identification and understanding of actors are
crucial for accurately modeling system behavior.
1.2. Use Cases

Use cases are like scenes in the play. They represent specific things your system can do. In
the online shopping system, examples of use cases could be “Place Order,” “Track
Delivery,” or “Update Product Information”. Use cases are represented by ovals.
1.3. System Boundary

The system boundary is a visual representation of the scope or limits of the system you are
modeling. It defines what is inside the system and what is outside. The boundary helps to
establish a clear distinction between the elements that are part of the system and those that
are external to it. The system boundary is typically represented by a rectangular box that
surrounds all the use cases of the system.
Purpose of System Boundary:
 Scope Definition: It clearly outlines the boundaries of the system, indicating which
components are internal to the system and which are external actors or entities
interacting with the system.
 Focus on Relevance: By delineating the system’s scope, the diagram can focus on
illustrating the essential functionalities provided by the system without unnecessary
details about external entities.
3. Use Case Diagram Relationships
In a Use Case Diagram, relationships play a crucial role in depicting the interactions
between actors and use cases. These relationships provide a comprehensive view of the
system’s functionality and its various scenarios. Let’s delve into the key types of
relationships and explore examples to illustrate their usage.

3.1. Association Relationship

The Association Relationship represents a communication or interaction between an actor

and a use case. It is depicted by a line connecting the actor to the use case. This
relationship signifies that the actor is involved in the functionality described by the use case.
Example: Online Banking System
 Actor: Customer
 Use Case: Transfer Funds
 Association: A line connecting the “Customer” actor to the “Transfer Funds” use case,
indicating the customer’s involvement in the funds transfer process.
3.2. Include Relationship

The Include Relationship indicates that a use case includes the functionality of another use
case. It is denoted by a dashed arrow pointing from the including use case to the included
use case. This relationship promotes modular and reusable design.
Example: Social Media Posting
 Use Cases: Compose Post, Add Image
 Include Relationship: The “Compose Post” use case includes the functionality of “Add
Image.” Therefore, composing a post includes the action of adding an image.
3.3. Extend Relationship

The Extend Relationship illustrates that a use case can be extended by another use case
under specific conditions. It is represented by a dashed arrow with the keyword “extend.”
This relationship is useful for handling optional or exceptional behavior.
Example: Flight Booking System
 Use Cases: Book Flight, Select Seat
 Extend Relationship: The “Select Seat” use case may extend the “Book Flight” use
case when the user wants to choose a specific seat, but it is an optional step.
3.4. Generalization Relationship

The Generalization Relationship establishes an “is-a” connection between two use cases,
indicating that one use case is a specialized version of another. It is represented by an
arrow pointing from the specialized use case to the general use case.
Example: Vehicle Rental System
 Use Cases: Rent Car, Rent Bike
 Generalization Relationship: Both “Rent Car” and “Rent Bike” are specialized versions
of the general use case “Rent Vehicle.”
4. How to draw a Use Case diagram in UML?
Step 1: Identify Actors

Determine who or what interacts with the system. These are your actors. They can be
users, other systems, or external entities.

Step 2: Identify Use Cases

Identify the main functionalities or actions the system must perform. These are your use
cases. Each use case should represent a specific piece of functionality.

Step 3: Connect Actors and Use Cases

Draw lines (associations) between actors and the use cases they are involved in. This
represents the interactions between actors and the system.

Step 4: Add System Boundary

Draw a box around the actors and use cases to represent the system boundary. This
defines the scope of your system.

Step 5: Define Relationships

If certain use cases are related or if one use case is an extension of another, you can
indicate these relationships with appropriate notations.

Step 6: Review and Refine

Step back and review your diagram. Ensure that it accurately represents the interactions
and relationships in your system. Refine as needed.

Step 7: Validate

Share your use case diagram with stakeholders and gather feedback. Ensure that it aligns
with their understanding of the system’s functionality.

Let’s understand how to draw a Use Case diagram with the help of an Online
Shopping System:

1. Actors:

 Customer
 Admin

2. Use Cases:

1. Browse Products
2. Add to Cart
3. Checkout
4. Manage Inventory (Admin)

3. Relations:

 The Customer can browse products, add to the cart, and complete the checkout.
 The Admin can manage the inventory.
Below is the usecase diagram of an Online Shopping System:
 What are the Purpose and Benefits of Use Case Diagrams?
The Use Case Diagram offers numerous benefits throughout the system development
process. Here are some key advantages of using Use Case Diagrams:
1.Visualization of System Functionality:
-> Use Case Diagrams provide a visual representation of the system’s functionalities and
interactions with external entities.
-> This visualization helps stakeholders, including non-technical ones, to understand the
system’s high-level behavior.
2.Communication:
-> Use Case Diagrams serve as a powerful communication tool, facilitating discussions
between stakeholders, developers, and designers.
-> They provide a common language for discussing system requirements, ensuring a shared
understanding among diverse team members.
3.Requirement Analysis:
-> During the requirements analysis phase, Use Case Diagrams help in identifying,
clarifying, and documenting user requirements.
-> They capture the various ways users interact with the system, aiding in a comprehensive
understanding of system functionality.
4.Focus on User Goals:
-> Use Case Diagrams center around user goals and scenarios, emphasizing the
perspective of external entities (actors).
-> This focus on user interactions ensures that the system is designed to meet user needs
and expectations.
5.System Design:
-> In the system design phase, Use Case Diagrams aid in designing how users (actors) will
interact with the system.
-> They contribute to the planning of the user interface and help in organizing system
functionalities.
6.Testing and Validation:
-> Use Case Diagrams are valuable for deriving test cases and validating system behavior.
-> Testers can use the diagrams to ensure that all possible scenarios, including alternative
and exceptional paths, are considered during testing.

1. What is an Activity Diagram?

Activity Diagrams are used to illustrate the flow of control in a system and refer to the steps
involved in the execution of a use case. We can depict both sequential processing and
concurrent processing of activities using an activity diagram ie an activity diagram focuses
on the condition of flow and the sequence in which it happens.
 We describe what causes a particular event using an activity diagram.
 An activity diagram portrays the control flow from a start point to a finish point showing
the various decision paths that exist while the activity is being executed.
 They are used in business and process modeling where their primary use is to depict the
dynamic aspects of a system.
2. Activity Diagram Notations

In activity diagrams, the notations are like visual symbols that help
represent different elements and actions in a simple way.

2.1. Initial State

The starting state before an activity takes place is depicted using the initial state.
A process can have only one initial state unless we are depicting nested activities. We use
a black filled circle to depict the initial state of a system. For objects, this is the state when
they are instantiated. The Initial State from the UML Activity Diagram marks the entry point
and the initial Activity State.
For example:
Here the initial state of the system before the application is opened.
2.2. Action or Activity State

An activity represents execution of an action on objects or by objects. We represent an

activity using a rectangle with rounded corners. Basically any action or event that takes
place is represented using an activity.
For example:
Consider the previous example of opening an application, opening the
application is an activity state in the activity diagram.
2.3. Action Flow or Control flows

Action flows or Control flows are also referred to as paths and edges. They are used to
show the transition from one activity state to another activity state.
An activity state can have multiple incoming and outgoing action flows. We use a line with
an arrow head to depict a Control Flow. If there is a constraint to be adhered to while
making the transition it is mentioned on the arrow.
For example:
Here both the states transit into one final state using action flow symbols
i.e. arrows.
2.4. Decision node and Branching

When we need to make a decision before deciding the flow of control, we use the decision
node. The outgoing arrows from the decision node can be labelled with conditions or guard
expressions. It always includes two or more output arrows.
For example:
We apply the conditions on input number to display the result :
 If number is odd then display the number.
 If number if even then display the error.
2.5. Guard

A Guard refers to a statement written next to a decision node on an arrow sometimes within
square brackets.
The statement must be true for the control to shift along a particular direction. Guards help
us know the constraints and conditions which determine the flow of a process.

2.6. Fork

Fork nodes are used to support concurrent activities. When we use a fork node when both
the activities get executed concurrently i.e. no decision is made before splitting the activity
into two parts. Both parts need to be executed in case of a fork statement. We use a
rounded solid rectangular bar to represent a Fork notation with incoming arrow from the
parent activity state and outgoing arrows towards the newly created activities.
For example:
In the example below, the activity of making coffee can be split into two
concurrent activities and hence we use the fork notation.
2.7. Join

Join nodes are used to support concurrent activities converging into one. For join notations
we have two or more incoming edges and one outgoing edge.
For example:
When both activities i.e. steaming the milk and adding coffee get
completed, we converge them into one final activity.
2.8. Merge or Merge Event

Scenarios arise when activities which are not being executed concurrently have to be
merged. We use the merge notation for such scenarios. We can merge two or more
activities into one if the control proceeds onto the next activity irrespective of the path
chosen.
For example:
In the diagram below: we can’t have both sides executing concurrently, but
they finally merge into one. A number can’t be both odd and even at the
same time.
2.9. Swimlanes

We use Swimlanes for grouping related activities in one column. Swimlanes group related
activities into one column or one row. Swimlanes can be vertical and horizontal. Swimlanes
are used to add modularity to the activity diagram. It is not mandatory to use swimlanes.
They usually give more clarity to the activity diagram. It’s similar to creating a function in a
program. It’s not mandatory to do so, but, it is a recommended practice.
We use a rectangular column to represent a swimlane as shown in the figure above.
For example:
Here different set of activities are executed based on if the number is odd or
even. These activities are grouped into a swimlane.
2.10. Time Event

This refers to an event that stops the flow for a time; an hourglass depicts it. We can have a
scenario where an event takes some time to completed.
For example:
Let us assume that the processing of an image takes a lot of time. Then it
can be represented as shown below.
2.11. Final State or End State

The state which the system reaches when a particular process or activity ends is known as
a Final State or End State. We use a filled circle within a circle notation to represent the
final state in a state machine diagram. A system or a process can have multiple final states.
3. How to Draw an Activity Diagram in UML?
Below are the steps of how to draw the Activity Diagram in UML:

Step 1. Identify the Initial State and Final States:

 This is like setting the starting point and ending point of a journey.
 Identify where your process begins (initial state) and where it concludes (final states).
 For example, if you are modelling a process for making a cup of tea, the initial state
could be “No tea prepared,” and the final state could be “Tea ready.”

Step 2. Identify the Intermediate Activities Needed:

 Think of the steps or actions required to go from the starting point to the ending point.
 These are the activities or tasks that need to be performed.
 Continuing with the tea-making , intermediate activities could include “Boil water,” “Pour
tea into a cup”.

Step 3. Identify the Conditions or Constraints:

 Consider the conditions or circumstances that might influence the flow of your process.
 These are the factors that determine when you move from one activity to another.
 Using the tea-making scenario, a condition could be “Water is boiled,” which triggers the
transition to the next activity.

Step 4. Draw the Diagram with Appropriate Notations:

 Now, represent the identified states, activities, and conditions visually using the
appropriate symbols and notations in an activity diagram. This diagram serves as a
visual map of your process, showing the flow from one state to another.
4. What are Activity Diagrams used for?
Activity diagrams are used in software development and system design to model and
visualize the dynamic aspects of a system. Here are some common uses of activity
diagrams:
 Dynamic modelling of the system or a process.
 Illustrate the various steps involved in a UML use case.
 Model software elements like methods,operations and functions.
 We can use Activity diagrams to depict concurrent activities easily.
 Show the constraints, conditions and logic behind algorithms.
 During the requirements analysis phase, activity diagrams assist in capturing and
documenting the dynamic aspects of user interactions.
5. What are the Differences between an Activity diagram and
a Flowchart?
An activity diagram is very similar to a flowchart. So let us understand if activity diagrams or
flowcharts are any different.

What is a Flow Chart?

An algorithm is like a set of clear instructions to solve a problem, and a flowchart is a

picture that shows those instructions.
 When we’re writing computer programs, a flowchart helps us map out the steps of the
algorithm to solve the problem.
 Non programmers use Flow charts to model workflows.
 We can call a flowchart a primitive version of an activity diagram.
 Business processes where decision making is involved is expressed using a flow chart.
Example:
A manufacturer uses a flow chart to explain and illustrate how a particular
product is manufactured.

1. What is a State Machine Diagram?

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.
 State Machine diagrams are also referred to as State Machines Diagrams and State-
Chart Diagrams.
 These terms are often used interchangeably. So simply, a state machine diagram is
used to model the dynamic behavior of a class in response to time and changing
external stimuli.
 We can say that each and every class has a state but we don’t model every class using
State Machine diagrams.
 We prefer to model the states with three or more states.
Let’s understand State Machine Diagram with the help of an example:
Example:
 The State Machine Diagram above shows the different states in which the
verification sub-system or class exist for a particular system.

2. Basic components and notations of a State Machine

diagram
2.1. Initial state

We use a black filled circle represent the initial state of a System or a Class.
2.2. Transition

We use a solid arrow to represent the transition or change of control from one state to
another. The arrow is labelled with the event which causes the change in state.
2.3. State

We use a rounded rectangle to represent a state. A state represents the conditions or

circumstances of an object of a class at an instant of time.
2.4. Fork

We use a rounded solid rectangular bar to represent a Fork notation with incoming arrow
from the parent state and outgoing arrows towards the newly created states. We use the
fork notation to represent a state splitting into two or more concurrent states.
2.5. Join

We use a rounded solid rectangular bar to represent a Join notation with incoming arrows
from the joining states and outgoing arrow towards the common goal state. We use the join
notation when two or more states concurrently converge into one on the occurrence of an
event or events.
2.6. Self transition

We use a solid arrow pointing back to the state itself to represent a self transition. There
might be scenarios when the state of the object does not change upon the occurrence of an
event. We use self transitions to represent such cases.
2.7. Composite state

We use a rounded rectangle to represent a composite state also. We represent a state with
internal activities using a composite state.
2.8. Final State

We use a filled circle within a circle notation to represent the final state in a state machine
diagram.
3. How to draw a State Machine diagram in
UML?
Below are the steps of how to draw the State Machine Diagram in UML:

Step1. Identify the System:

 Understand what your diagram is representing.

 Whether it’s a machine, a process, or any object, know what different situations or
conditions it might go through.

Step2. Identify Initial and Final States:

 Figure out where your system starts (initial state) and where it ends (final state).
 These are like the beginning and the end points of your system’s journey.

Step3. Identify Possible States:

 Think about all the different situations your system can be in.
 These are like the various phases or conditions it experiences.
 Use boundary values to guide you in defining these states.

Step4. Label Triggering Events:

 Understand what causes your system to move from one state to another.
 These causes or conditions are the events.
 Label each transition with what makes it happen.
Step5. Draw the Diagram with appropriate notations:

 Now, take all this information and draw it out.

 Use rectangles for states, arrows for transitions, and circles or rounded rectangles for
initial and final states.
 Be sure to connect everything in a way that makes sense.
Let’s understand State Machine diagram with the help of an example, ie for an online
order :

The UML diagrams we draw depend on the system we aim to represent. Here is just an
example of how an online ordering system might look like :
1. On the event of an order being received, we transit from our initial state to Unprocessed
order state.
2. The unprocessed order is then checked.
3. If the order is rejected, we transit to the Rejected Order state.
4. If the order is accepted and we have the items available we transit to the fulfilled order
state.
5. However if the items are not available we transit to the Pending Order state.
6. After the order is fulfilled, we transit to the final state. In this example, we merge the two
states i.e. Fulfilled order and Rejected order into one final state.
Note: Here we could have also treated fulfilled order and rejected order as final states
separately.

4. UseCases of State Machine Diagram

 State Machine Diagrams are particularly useful for modeling and visualizing the dynamic
behavior of a system.
 They showcase how a system responds to events and transitions between different
states.
 We use it to state the events responsible for change in state (we do not show what
processes cause those events).
 Objects go through different states during their existence, and these diagrams help in
illustrating these states and the transitions between them.
 In embedded systems, where hardware interacts with software to perform tasks, State
Machine Diagrams are valuable for representing the control logic and behavior of the
system.

Process and Thread :-

-> A process is a heavywight flow that can execut concurrent with other processes.
-> A thread is a lightweight flow that can execute concurrently flow that can execute
concurrently with other threadds within the same process.
-> An active object is an object that owns a process or thread and can initiate
central active.
-> In the UML,independent flow of control is modeled as an active object.
-> An active class is a class whose instances are active objects.
-> Graphically, an active classs is rendered as a rectangle with thick lines.

Processes and threads are rendered as sterotyped active classes.

Stereotype meaning-a fixed idea bout a particular type of person or thing, which is often not
true in reality.

2 standard stereotypes that apply to active classes are :-

<<process>> specifies a heavyweight flow that can execute concurrently with other process.Heavy
weight means, a thing known to the OS itself and runs in an independent address space.

<<thread>> Specifes a light weight flow that can execute concurrently with other threads within the
same process. Light weight means, known to the OS itself.

Event Class :-

-> Event class indicates a group of events with cojmon structure and behaviour. Ex- we can consider
the events of departure of a flight of an airline, which we can group into the folowing class-
 Flight_Departs(Flight_No, From_City, To-City, Route)

Events

 An event is the specification of a significant occurrence that has a location in time and space.
 Any thing that happens is modeled as an event in UML.
 In the context of state machines, an event is an occurrence of a stimulus that can trigger a state transition
 four kinds of events – signals, calls, the passing of time, and a change in state.
 Figure 1: Events
 Events may be external or internal and asynchronous or synchronous.
asynchronous events are events that can happen at arbitrary times eg:- signal, the passing of time, and a
change of state. synchronous events, represents the invocation of an operation eg:- Calls

External events are those that pass between the system and its actors. Internal events are those that
pass among the objects that live inside the system.

A signal is an event that represents the specification of an asynchronous stimulus communicated between
instances.

Figure 1: Events

kinds of events

Signal Event

 a signal event represents a named object that is dispatched (thrown) asynchronously by one object and
then received (caught) by another. Exceptions are an example of internal signal
 a signal event is an asynchronous event
 signal events may have instances, generalization relationships, attributes and operations. Attributes of a
signal serve as its parameters
 A signal event may be sent as the action of a state transition in a state machine or the sending of a
message in an interaction
 signals are modeled as stereotyped classes and the relationship between an operation and the events by
using a dependency relationship, stereotyped as send
 Figure 2 shows Signal Events



 Figure 2: Signals


Call Event

 a call event represents the dispatch of an operation

 a call event is a synchronous event
 Figure 3 shows Call Events



Figure 3: Call Events


Time and Change Events

 A time event is an event that represents the passage of time.

 modeled by using the keyword ‘after’ followed by some expression that evaluates to a period of time which
can be simple or complex.
 A change event is an event that represents a change in state or the satisfaction of some condition
 modeled by using the keyword ‘when’ followed by some Boolean expression
 Figure 4



Figure 4: Time and Change Events


Sending and Receiving Events

For synchronous events (Sending or Receiving) like call event, the sender and the receiver are in a
rendezvous(the sender dispatches the signal and wait for a response from the receiver) for the duration of
the operation. when an object calls an operation, the sender dispatches the operation and then waits for
the receiver.
For asynchronous events (Sending or Receiving) like signal event, the sender and receiver do not
rendezvous ie,the sender dispatches the signal but does not wait for a response from the receiver. When an
object sends a signal, the sender dispatches the signal and then continues along its flow of control, not
waiting for any return from the receiver.

call events can be modelled as operations on the class of the object.

named signals can be modelled by naming them in an extra compartment of the class as in Figure 5: Signals
and Active Classes

UML Timing Diagram

In UML, the timing diagrams are a part of Interaction diagrams that do not incorporate similar
notations as that of sequence and collaboration diagram. It consists of a graph or waveform that
depicts the state of a lifeline at a specific point of time. It illustrates how conditions are altered
both inside and between lifelines alongside linear time axis.

The timing diagram describes how an object underwent a change from one form to another. A
waveform portrays the flow among the software programs at several instances of time.

Following are some important key points of a timing diagram:

1. It emphasizes at that particular time when the message has been sent among objects.
2. It explains the time processing of an object in detail.
3. It is employed with distributed and embedded systems.
4. It also explains how an object undergoes changes in its form throughout its lifeline.
5. As the lifelines are named on the left side of an edge, the timing diagrams are read from
left to right.
6. It depicts a graphical representation of states of a lifeline per unit time.
7. In UML, the timing diagram has come up with several notations to simplify the transition
state among two lifelines per unit time.
Basic concepts of a Timing Diagram
In UML, the timing diagram constitutes several major elements, which are as follows:

Lifeline

As the name suggests, the lifeline portrays an individual element in the interaction. It represents a
single entity, which is a part of the interaction. It is represented by the classifier's name that it
depicts. A lifeline can be placed within a "swimlane" or a diagram frame.

Lifelines representing instances of a System and Virus

State or Condition Timeline

The timing diagram represents the state of a classifier or attributes that are participating, or some
testable conditions, which is a discrete value of the classifier.

In UML, the state or condition is continuous. It is mainly used to show the temperature and density
where the entities endure a continuous state change.

Timeline showing the change in the state of virus between dormant, Propagation,
Triggering, Execution

Duration Constraint

The duration constraint is a constraint of an interval, which refers to duration interval. It is used to
determine if the constraint is satisfied for a duration or not. The duration constraint semantics
inherits from the constraints.

The negative trace defines the violated constraints, which means the system is failed. A graphical
association between duration interval and the construct, which it constrains, may represent a
duration constraint.
Ice should melt into the water in 1 to 6 mins.

Time Constraint

It is an interval constraint, which refers to the time interval. Since it is a time expression, it depicts if
the constraint is satisfied or not. The constraints dispense its time constraints semantics.

The negative trace defines the violated constraints, which means the system is failed. The time
constraint is represented by a graphical association between the time interval and the construct
which it constrains.

The graphical association is mainly represented by a small line in between a time interval and an
occurrence specification.

A person should wakeup in between 5:40 am, and 6 am

Destruction Occurrence

The destruction occurrence refers to the occurrence of a message that represents the destruction
of an instance is defined by a lifeline. It may subsequently destruct other objects owned by the
composition of this object, such that nothing occurs after the destruction event on a given lifeline.
It is represented by a cross at the end of a timeline.

Virus lifeline is terminated

Example of a Timing Diagram

A timing diagram example of a medical domain that depicts different stages of Alzheimer's disease
(AD) is explained below.
Since Alzheimer's is a very progressive fatal brain disease, it leads to memory loss and intellectual
abilities. The reason behind this disease is yet to be discovered. It cannot be cured as well as one of
the main reasons for rising death rates in the United States.

The doctor may require a diagnostic framework with three to seven-stage, such that its evolution
may last for about 8 to 10 years. Also, in some cases, it lasts up to 20years from the time neuron
starts changing.

The example given below constitutes timing for a seven-stage framework. The given example is
just a UML diagram and should not be considered as a reference to medical research. The medical
details are provided for you to better understand the UML diagram.

Following are the seven-stage Alzheimer disease framework explained below:

o No Impairment, Normal State

It is the stage where the memory and cognitive abilities look normal.
o Normal Aged Forgetfulness
It is mostly seen in people with an age group of 65 who experience subjective complaints
of cognitive and/or functional difficulties, which means they face problems in recalling the
name and past 5 to 10 years of history.
o Early Confusional, Mild Cognitive Impairment
It causes a problem in retrieving words, planning, organizing, objects misplacing as well as
forgetting fresh learning, which in turn affects the surrounding.
o Late Confusional, Mild Alzheimer's
In this, a person forgets the most recent events and conversations. The person remembers
himself and his family, but face problems while carrying out sequential tasks such as
cooking, driving, etc. Its duration is about two years,
o Early Dementia, Moderate Alzheimer's
In this, the person cannot manage independently. He faces difficulty in recalling the past
details and contact information. It lasts for about 1.5 years.
 o Middle Dementia, Moderately Severe Alzheimer's
It leads to insufficient awareness about current events, and the person is unable to recall
the past. It causes an inability in people to take a bath and dress up independently. It lasts
for about 2.5 years approximately.
o Late or Severe Dementia, Failure to Thrive
It is severely limited intellectual ability. In this, a person either communicates through
short words or cries, which leads health to decline as it shut down the body system. Its
duration is 1 to 2.5 years.

Benefits of Timing Diagram

1. It depicts the state of an object at a particular point in time.

2. It implements forward and reverses engineering.
3. It keeps an eye on every single change that happens within the system.

Drawbacks of Timing Diagram

1. It is hard to maintain and understand.

UML Interaction Diagram

As the name suggests, the interaction diagram portrays the interactions between distinct entities
present in the model. It amalgamates both the activity and sequence diagrams. The
communication is nothing but units of the behavior of a classifier that provides context for
interactions.

A set of messages that are interchanged between the entities to achieve certain specified tasks in
the system is termed as interaction. It may incorporate any feature of the classifier of which it has
access. In the interaction diagram, the critical component is the messages and the lifeline.

In UML, the interaction overview diagram initiates the interaction between the objects utilizing
message passing. While drawing an interaction diagram, the entire focus is to represent the
relationship among different objects which are available within the system boundary and the
message exchanged by them to communicate with each other.

The message exchanged among objects is either to pass some information or to request some
information. And based on the information, the interaction diagram is categorized into the
sequence diagram, collaboration diagram, and timing diagram.

The sequence diagram envisions the order of the flow of messages inside the system by depicting
the communication between two lifelines, just like a time-ordered sequence of events.

The collaboration diagram, which is also known as the communication diagram, represents how
lifelines connect within the system, whereas the timing diagram focuses on that instant when a
message is passed from one element to the other.

Notation of an Interaction Diagram

Purpose of an Interaction Diagram
The interaction diagram helps to envision the interactive (dynamic) behavior of any system. It
portrays how objects residing in the system communicates and connects to each other. It also
provides us with a context of communication between the lifelines inside the system.

Following are the purpose of an interaction diagram given below:

1. To visualize the dynamic behavior of the system.

2. To envision the interaction and the message flow in the system.
3. To portray the structural aspects of the entities within the system.
4. To represent the order of the sequenced interaction in the system.
5. To visualize the real-time data and represent the architecture of an object-oriented
system.

How to draw an Interaction Diagram?

Since the main purpose of an interaction diagram is to visualize the dynamic behavior of the
system, it is important to understand what a dynamic aspect really is and how we can visualize it.
The dynamic aspect is nothing but a screenshot of the system at the run time.

Before drawing an interaction diagram, the first step is to discover the scenario for which the
diagram will be made. Next, we will identify various lifelines that will be invoked in the
communication, and then we will classify each lifeline. After that, the connections are investigated
and how the lifelines are interrelated to each other.

Following are some things that are needed:

1. A total no of lifeline which will take part in the communication.

2. The sequence of the message flow among several entities within the system.
3. No operators used to ease out the functionality of the diagram.
4. Several distinct messages that depict the interactions in a precise and clear way.
5. The organization and structure of a system.
6. The order of the sequence of the flow of messages.
7. Total no of time constructs of an object.

Use of an Interaction Diagram

The interaction diagram can be used for:

1. The sequence diagram is employed to investigate a new application.

2. The interaction diagram explores and compares the use of the collaboration diagram
sequence diagram and the timing diagram.
3. The interaction diagram represents the interactive (dynamic) behavior of the system.
4. The sequence diagram portrays the order of control flow from one element to the other
elements inside the system, whereas the collaboration diagrams are employed to get an
overview of the object architecture of the system.
5. The interaction diagram models the system as a time-ordered sequence of a system.
6. The interaction diagram models the system as a time-ordered sequence of a system.
7. The interaction diagram systemizes the structure of the interactive elements.

UML Interaction Diagram

As the name suggests, the interaction diagram portrays the interactions between distinct entities
present in the model. It amalgamates both the activity and sequence diagrams. The
communication is nothing but units of the behavior of a classifier that provides context for
interactions.

A set of messages that are interchanged between the entities to achieve certain specified tasks in
the system is termed as interaction. It may incorporate any feature of the classifier of which it has
access. In the interaction diagram, the critical component is the messages and the lifeline.

In UML, the interaction overview diagram initiates the interaction between the objects utilizing
message passing. While drawing an interaction diagram, the entire focus is to represent the
relationship among different objects which are available within the system boundary and the
message exchanged by them to communicate with each other.

The message exchanged among objects is either to pass some information or to request some
information. And based on the information, the interaction diagram is categorized into the
sequence diagram, collaboration diagram, and timing diagram.
The sequence diagram envisions the order of the flow of messages inside the system by depicting
the communication between two lifelines, just like a time-ordered sequence of events.

The collaboration diagram, which is also known as the communication diagram, represents how
lifelines connect within the system, whereas the timing diagram focuses on that instant when a
message is passed from one element to the other.

Notation of an Interaction Diagram

Purpose of an Interaction Diagram

The interaction diagram helps to envision the interactive (dynamic) behavior of any system. It
portrays how objects residing in the system communicates and connects to each other. It also
provides us with a context of communication between the lifelines inside the system.

Following are the purpose of an interaction diagram given below:

1. To visualize the dynamic behavior of the system.

2. To envision the interaction and the message flow in the system.
3. To portray the structural aspects of the entities within the system.
4. To represent the order of the sequenced interaction in the system.
5. To visualize the real-time data and represent the architecture of an object-oriented
system.
How to draw an Interaction Diagram?
Since the main purpose of an interaction diagram is to visualize the dynamic behavior of the
system, it is important to understand what a dynamic aspect really is and how we can visualize it.
The dynamic aspect is nothing but a screenshot of the system at the run time.

Before drawing an interaction diagram, the first step is to discover the scenario for which the
diagram will be made. Next, we will identify various lifelines that will be invoked in the
communication, and then we will classify each lifeline. After that, the connections are investigated
and how the lifelines are interrelated to each other.

Following are some things that are needed:

1. A total no of lifeline which will take part in the communication.

2. The sequence of the message flow among several entities within the system.
3. No operators used to ease out the functionality of the diagram.
4. Several distinct messages that depict the interactions in a precise and clear way.
5. The organization and structure of a system.
6. The order of the sequence of the flow of messages.
7. Total no of time constructs of an object.

Use of an Interaction Diagram

The interaction diagram can be used for:

1. The sequence diagram is employed to investigate a new application.

2. The interaction diagram explores and compares the use of the collaboration diagram
sequence diagram and the timing diagram.
3. The interaction diagram represents the interactive (dynamic) behavior of the system.
4. The sequence diagram portrays the order of control flow from one element to the other
elements inside the system, whereas the collaboration diagrams are employed to get an
overview of the object architecture of the system.
5. The interaction diagram models the system as a time-ordered sequence of a system.
6. The interaction diagram models the system as a time-ordered sequence of a system.
7. The interaction diagram systemizes the structure of the interactive elements.

What is a package diagram?

Package diagrams are structural diagrams used to show the organization and
arrangement of various model elements in the form of packages. A package is
a grouping of related UML elements, such as diagrams, documents, classes, or
even other packages. Each element is nested within the package, which is
depicted as a file folder within the diagram, then arranged hierarchically within
the diagram. Package diagrams are most commonly used to provide a visual
organization of the layered architecture within any UML classifier, such as a
software system.
Benefits of a package diagram
 A well-designed package diagram provides numerous benefits to those
looking to create a visualization of their UML system or project.

 They provide a clear view of the hierarchical structure of the various UML
elements within a given system.
 These diagrams can simplify complex class diagrams into well-ordered
visuals.
 They offer valuable high-level visibility into large-scale projects and systems.
 Package diagrams can be used to visually clarify a wide variety of projects
and systems.
 These visuals can be easily updated assystems and projects evolve.

Basic components of a package diagram

The makeup of a package diagram is relatively simple. Each diagram includes
only two symbols:

Symbol
Symbol Image Description
Name

Groups common elements based

Package on data, behavior, or user
interaction

Depicts the relationship between

Dependency one element (package, named
element, etc) and another

These symbols can be used in a variety of ways to represent different

iterations of packages, dependencies, and other elements within a system.
Here are the basic components you’ll find within a package diagram:


 Package

 : A namespace used to group together logically related elements within a

system. Each element contained within the package should be a
packageable element and have a unique name.


Packageable element

 : A named element, possibly owned directly by a package. These can

include events, components, use cases, and packages themselves.
Packageable elements can also be rendered as a rectangle within a
package, labeled with the appropriate name.


Dependencies

 : A visual representation of how one element (or set of elements) depends

on or influences another. Dependencies are divided into two groups:
access and import dependencies. (See next section for more info.)


Element import

 : A directed relationship between an importing namespace and an

imported packageable element. This is used to import select individual
elements without resorting to a package import and without making it
public within the namespace.


Package import

 : A directed relationship between and importing namespace and an

imported package. This type of directed relationship adds the names of
the members of the imported package to its own namespace


Package merge

 : A directed relationship in which the contents of one package are

extended by the contents of another. Essentially, the content of two
packages are combined to produce a new package.

Dependency notations in a package diagram

Package diagrams are used, in part, to depict import and access dependencies
between packages, classes, components, and other named elements within
your system. Each dependency is rendered as a connecting line with an arrow
representing the type of relationship between the two or more elements.
There are two main types of dependencies:

Access

: Indicates that one package requires assistance from the functions of another
package.
Example:

Import
: Indicates that functionality has been imported from one package to
another.
Example:

Dependencies can also be broken down further into the following categories:

Usage
 : Occurs when a given named element requires another for its full
definition and deployment. Example: client and supplier.


Abstraction

 : Relates two elements representing the same concept at different levels of

abstraction within the system (usually a relationship between client and
supplier).


Deployment

 : Depicts the deployment of an artifact to a deployment target.

Using packages with other UML diagrams

As we’ve shown earlier in this guide, packages are UML constructs that can be
used to organize the elements within any UML classifier in a variety of UML
diagrams. Package diagrams are most commonly found used in:

Use-case diagrams

 : Each use-case is depicted as an individual package



Class diagrams

 : Classes are organized into into packages

Packages can also be used within other UML model types to organize and
arrange elements such as classes, data entities, and use cases. By fuzing the
package diagram structure with other UML diagrams, you can simplify any
model type, making it easier to understand.

Model diagrams
Package diagrams can also be used in conjunction with model diagrams—a
type of UML auxiliary structure diagram used to depict the logical, behavioral,
or structural aspects of a system. Even simple models can be difficult to
understand without some type of visual organization. The use of packages can
provide users with a high-level view of a model with unambiguous named
references for each of the elements it contains. In addition, clearly labeled
dependencies can clarify the relationships between each element.

Package diagram example

Take a look at the following template to see how a package diagram models
the packages within a basic e-commerce web app. Click on the template to
modify it and explore how you can show the structure of any designed system
at a package level.
UML Component Diagram
A component diagram is used to break down a large object-oriented system into the smaller
components, so as to make them more manageable. It models the physical view of a system such
as executables, files, libraries, etc. that resides within the node.

It visualizes the relationships as well as the organization between the components present in the
system. It helps in forming an executable system. A component is a single unit of the system, which
is replaceable and executable. The implementation details of a component are hidden, and it
necessitates an interface to execute a function. It is like a black box whose behavior is explained by
the provided and required interfaces.

Notation of a Component Diagram

a) A component

b) A node

Purpose of a Component Diagram

Since it is a special kind of a UML diagram, it holds distinct purposes. It describes all the individual
components that are used to make the functionalities, but not the functionalities of the system. It
visualizes the physical components inside the system. The components can be a library, packages,
files, etc.

The component diagram also describes the static view of a system, which includes the organization
of components at a particular instant. The collection of component diagrams represents a whole
system.
The main purpose of the component diagram are enlisted below:

1. It envisions each component of a system.

2. It constructs the executable by incorporating forward and reverse engineering.
3. It depicts the relationships and organization of components.

Why use Component Diagram?

The component diagrams have remarkable importance. It is used to depict the functionality and
behavior of all the components present in the system, unlike other diagrams that are used to
represent the architecture of the system, working of a system, or simply the system itself.

In UML, the component diagram portrays the behavior and organization of components at any
instant of time. The system cannot be visualized by any individual component, but it can be by the
collection of components.

Following are some reasons for the requirement of the component diagram:

1. It portrays the components of a system at the runtime.

2. It is helpful in testing a system.
3. It envisions the links between several connections.

When to use a Component Diagram?

It represents various physical components of a system at runtime. It is helpful in visualizing the
structure and the organization of a system. It describes how individual components can together
form a single system. Following are some reasons, which tells when to use component diagram:

1. To divide a single system into multiple components according to the functionality.

2. To represent the component organization of the system.

How to Draw a Component Diagram?

The component diagram is helpful in representing the physical aspects of a system, which are files,
executables, libraries, etc. The main purpose of a component diagram is different from that of
other diagrams. It is utilized in the implementation phase of any application.

Once the system is designed employing different UML diagrams, and the artifacts are prepared,
the component diagram is used to get an idea of implementation. It plays an essential role in
implementing applications efficiently.

Following are some artifacts that are needed to be identified before drawing a component
diagram:

1. What files are used inside the system?

2. What is the application of relevant libraries and artifacts?
3. What is the relationship between the artifacts?

Following are some points that are needed to be kept in mind after the artifacts are identified:
 1. Using a meaningful name to ascertain the component for which the diagram is about to
be drawn.
2. Before producing the required tools, a mental layout is to be made.
3. To clarify the important points, notes can be incorporated.

Example of a Component Diagram

A component diagram for an online shopping system is given below:

Where to use Component Diagrams?

The component diagram is a special purpose diagram, which is used to visualize the static
implementation view of a system. It represents the physical components of a system, or we can say
it portrays the organization of the components inside a system. The components, such as libraries,
files, executables, etc. are first needed to be organized before the implementation.

The component diagram can be used for the followings:

1. To model the components of the system.

2. To model the schemas of a database.
3. To model the applications of an application.
4. To model the system's source code.
UML Deployment Diagram
The deployment diagram visualizes the physical hardware on which the software will be deployed.
It portrays the static deployment view of a system. It involves the nodes and their relationships.

It ascertains how software is deployed on the hardware. It maps the software architecture created
in design to the physical system architecture, where the software will be executed as a node. Since
it involves many nodes, the relationship is shown by utilizing communication paths.

Purpose of Deployment Diagram

The main purpose of the deployment diagram is to represent how software is installed on the
hardware component. It depicts in what manner a software interacts with hardware to perform its
execution.

Both the deployment diagram and the component diagram are closely interrelated to each other
as they focus on software and hardware components. The component diagram represents the
components of a system, whereas the deployment diagram describes how they are actually
deployed on the hardware.

The deployment diagram does not focus on the logical components of the system, but it put its
attention on the hardware topology.

Following are the purposes of deployment diagram enlisted below:

1. To envision the hardware topology of the system.

2. To represent the hardware components on which the software components are installed.
3. To describe the processing of nodes at the runtime.

Symbol and notation of Deployment diagram

The deployment diagram consist of the following notations:

1. A component
2. An artifact
3. An interface
4. A node
How to draw a Deployment Diagram?
The deployment diagram portrays the deployment view of the system. It helps in visualizing the
topological view of a system. It incorporates nodes, which are physical hardware. The nodes are
used to execute the artifacts. The instances of artifacts can be deployed on the instances of nodes.

Since it plays a critical role during the administrative process, it involves the following parameters:

1. High performance
2. Scalability
3. Maintainability
4. Portability
5. Easily understandable

One of the essential elements of the deployment diagram is the nodes and artifacts. So it is
necessary to identify all of the nodes and the relationship between them. It becomes easier to
develop a deployment diagram if all of the nodes, artifacts, and their relationship is already known.

Example of a Deployment diagram

A deployment diagram for the Apple iTunes application is given below.

The iTunes setup can be downloaded from the iTunes website, and also it can be installed on the
home computer. Once the installation and the registration are done, iTunes application can easily
interconnect with the Apple iTunes store. Users can purchase and download music, video, TV
serials, etc. and cache it in the media library.
Devices like Apple iPod Touch and Apple iPhone can update its own media library from the
computer with iTunes with the help of USB or simply by downloading media directly from the
Apple iTunes store using wireless protocols, for example; Wi-Fi, 3G, or EDGE.

When to use a Deployment Diagram?

The deployment diagram is mostly employed by network engineers, system administrators, etc.
with the purpose of representing the deployment of software on the hardware system. It envisions
the interaction of the software with the hardware to accomplish the execution. The selected
hardware must be of good quality so that the software can work more efficiently at a faster rate by
producing accurate results in no time.

The software applications are quite complex these days, as they are standalone, distributed, web-
based, etc. So, it is very necessary to design efficient software.

Deployment diagrams can be used for the followings:

1. To model the network and hardware topology of a system.

2. To model the distributed networks and systems.
3. Implement forwarding and reverse engineering processes.
4. To model the hardware details for a client/server system.
5. For modeling the embedded system.