Software is a program or set of programs containing instructions that provide

desired functionality. And Engineering is the process of designing and

building something that serves a particular purpose and finds a cost-effective
solution to problems. 
Software engineering is the process of designing, developing, testing, and
maintaining software. It is a systematic and disciplined approach to software
development that aims to create high-quality, reliable, and maintainable
software. Software engineering includes a variety of techniques, tools, and
methodologies, including requirements analysis, design, testing, and
maintenance.

Some key principles of software engineering include:

1. Modularity: Breaking the software into smaller, reusable

components that can be developed and tested independently.
2. Abstraction: Hiding the implementation details of a component and
exposing only the necessary functionality to other parts of the
software.
3. Encapsulation: Wrapping up the data and functions of an object
into a single unit, and protecting the internal state of an object from
external modifications.
4. Reusability: Creating components that can be used in multiple
projects, which can save time and resources.
5. Maintenance: Regularly updating and improving the software to fix
bugs, add new features, and address security vulnerabilities.
6. Testing: Verifying that the software meets its requirements and is
free of bugs.
7. Design Patterns: Solving recurring problems in software design by
providing templates for solving them.
8. Agile methodologies: Using iterative and incremental
development processes that focus on customer satisfaction, rapid
delivery, and flexibility.
9. Continuous Integration & Deployment: Continuously integrating
the code changes and deploying them into the production
environment.

Need of Software Engineering:

 Handling Big Projects: A corporation must use a software
engineering methodology in order to handle large projects without
any issues.
 To manage the cost: Software engineering programmers plan
everything and reduce all those things that are not required.
 To decrease time: It will save a lot of time if you are developing
software using a software engineering technique.
 Reliable software: It is the company’s responsibility to deliver
software products on schedule and to address any defects that may
exist.
 Effectiveness: Effectiveness results from things being created in
accordance with the standards.

 Reduces complexity: Large challenges are broken down into
smaller ones and solved one at a time in software engineering.
Individual solutions are found for each of these issues.
 Productivity: Because it contains testing systems at every level,
proper care is done to maintain software productivity
Software engineering is the process of designing, developing, testing, and
maintaining software. It is needed because software is a complex and
constantly evolving field that requires a structured approach to ensure that
the end product is of high quality, reliable, and meets the needs of the users.
Additionally, software engineering helps to manage the costs, risks and
schedule of the software development process. It also provides a way to
improve the software development process over time through testing and
feedback.

+
+
++, Difference between Program and Product

S.No. Program Product

Program contains a set of

instructions designed to Product is the final manufacture and
1. complete a specific task. production of the project.

It is a passive entity as it It is an active entity as it is made again

resides in the secondary and again for the purpose of distribution
2. memory. to users.

A product can exist for a long period of

time as long as it is tested for better
It exists at a single place performance and durability. A specific
and continues to exist until software product would stop existing if it
3. it is deleted. is destroyed or uninstalled.

It needs a lot of time to be made. There

are several stages (design, coding,
It can be made in relatively testing, maintenance etc.) to form a
4. shorter period of time. product.

It is handled by the
5. program managers. It is handled by product managers.
S.No. Program Product

It does not have any

resource requirement, it
only requires memory
space for storing the It needs human, technology and time
6. instructions. resources to be functional.

The main focus of the

program is whether it is The main focus of a product is its
giving a specific desired capability to solve the problem that it was
7. output or not. made for.

There are no concrete

guidelines in writing a In case of product, the firm guidelines are
8. program. followed.

It needs to worry about the cost and

efficiency as it would affect the
It may or may not focus on profitability of the enterprise launching
9. efficiency and cost. the product.
Prototyping is defined as the process of developing a working replication of a
product or system that has to be engineered. It offers a small scale facsimile
of the end product and is used for obtaining customer feedback as described
below

The Prototyping Model is one of the most popularly used Software

Development Life Cycle Models (SDLC models). This model is used when
the customers do not know the exact project requirements beforehand. In
this model, a prototype of the end product is first developed, tested and
refined as per customer feedback repeatedly till a final acceptable prototype
is achieved which forms the basis for developing the final product. 
Waterfall Model:-
The Waterfall Model was the first Process Model to be introduced. It is also referred to as
a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall
model, each phase must be completed before the next phase can begin and there is no
overlapping in the phases.
The Waterfall model is the earliest SDLC approach that was used for software development.
The waterfall Model illustrates the software development process in a linear sequential flow.
This means that any phase in the development process begins only if the previous phase is
complete. In this waterfall model, the phases do not overlap.

V Model :-

The V-model is a type of SDLC model where process executes in a

sequential manner in V-shape. It is also known as Verification and Validation
model. It is based on the association of a testing phase for each
corresponding development stage. Development of each step directly
associated with the testing phase. The next phase starts only after
completion of the previous phase i.e. for each development activity, there is a
testing activity corresponding to it. 

Agile SDLC model is a combination of iterative and incremental process models with focus
on process adaptability and customer satisfaction by rapid delivery of working software
product. Agile Methods break the product into small incremental builds. These builds are
provided in iterations. Each iteration typically lasts from about one to three weeks. Every
iteration involves cross functional teams working simultaneously on various areas like −

 Planning
 Requirements Analysis
 Design
 Coding
 Unit Testing and
 Acceptance Testing.
]

]
V-Model - Verification Phases
There are several Verification phases in the V-Model, each of these are explained in detail
below.
Business Requirement Analysis
This is the first phase in the development cycle where the product requirements are
understood from the customer’s perspective. This phase involves detailed communication
with the customer to understand his expectations and exact requirement. This is a very
important activity and needs to be managed well, as most of the customers are not sure about
what exactly they need. The acceptance test design planning is done at this stage as
business requirements can be used as an input for acceptance testing.

System Design
Once you have the clear and detailed product requirements, it is time to design the complete
system. The system design will have the understanding and detailing the complete hardware
and communication setup for the product under development. The system test plan is
developed based on the system design. Doing this at an earlier stage leaves more time for the
actual test execution later.
Architectural Design
Architectural specifications are understood and designed in this phase. Usually more than one
technical approach is proposed and based on the technical and financial feasibility the final
decision is taken. The system design is broken down further into modules taking up different
functionality. This is also referred to as High Level Design (HLD).
The data transfer and communication between the internal modules and with the outside
world (other systems) is clearly understood and defined in this stage. With this information,
integration tests can be designed and documented during this stage.
Module Design
In this phase, the detailed internal design for all the system modules is specified, referred to
as Low Level Design (LLD). It is important that the design is compatible with the other
modules in the system architecture and the other external systems. The unit tests are an
essential part of any development process and helps eliminate the maximum faults and errors
at a very early stage. These unit tests can be designed at this stage based on the internal
module designs.

Coding Phase
The actual coding of the system modules designed in the design phase is taken up in the
Coding phase. The best suitable programming language is decided based on the system and
architectural requirements.
The coding is performed based on the coding guidelines and standards. The code goes
through numerous code reviews and is optimized for best performance before the final build
is checked into the repository.

Validation Phases
The different Validation Phases in a V-Model are explained in detail below.
Unit Testing
Unit tests designed in the module design phase are executed on the code during this
validation phase. Unit testing is the testing at code level and helps eliminate bugs at an early
stage, though all defects cannot be uncovered by unit testing.
Integration Testing
Integration testing is associated with the architectural design phase. Integration tests are
performed to test the coexistence and communication of the internal modules within the
system.
System Testing
System testing is directly associated with the system design phase. System tests check the
entire system functionality and the communication of the system under development with
external systems. Most of the software and hardware compatibility issues can be uncovered
during this system test execution.
Acceptance Testing
Acceptance testing is associated with the business requirement analysis phase and involves
testing the product in user environment. Acceptance tests uncover the compatibility issues
with the other systems available in the user environment. It also discovers the non-functional
issues such as load and performance defects in the actual user environment.

V- Model ─ Application
V- Model application is almost the same as the waterfall model, as both the models are of
sequential type. Requirements have to be very clear before the project starts, because it is
usually expensive to go back and make changes. This model is used in the medical
development field, as it is strictly a disciplined domain.
]

]
V Model :-
The V-model is a type of SDLC model where process executes in a
sequential manner in V-shape. It is also known as Verification and Validation
model. It is based on the association of a testing phase for each
corresponding development stage. Development of each step directly
associated with the testing phase. The next phase starts only after
completion of the previous phase i.e. for each development activity, there is a
testing activity corresponding to it. 
 
Verification: It involves static analysis technique (review) done without
executing code. It is the process of evaluation of the product development
phase to find whether specified requirements meet. 
Validation: It involves dynamic analysis technique (functional, non-
functional), testing done by executing code. Validation is the process to
evaluate the software after the completion of the development phase to
determine whether software meets the customer expectations and
requirements. 
 Requirement Analysis: This phase contains detailed
communication with the customer to understand their requirements
and expectations. This stage is known as Requirement Gathering.
 System Design: This phase contains the system design and the
complete hardware and communication setup for developing
product.
 Architectural Design: System design is broken down further into
modules taking up different functionalities. The data transfer and
communication between the internal modules and with the outside
world (other systems) is clearly understood.
 Module Design: In this phase the system breaks down into small
modules. The detailed design of modules is specified, also known
as Low-Level Design (LLD).

Test Phases:-
 Unit Testing: Unit Test Plans are developed during module
design phase. These Unit Test Plans are executed to eliminate
bugs at code or unit level.
 Integration testing: After completion of unit testing Integration
testing is performed. In integration testing, the modules are
integrated and the system is tested. Integration testing is performed
 on the Architecture design phase. This test verifies the
communication of modules among themselves.
 System Testing: System testing test the complete application with
its functionality, inter dependency, and communication.It tests the
functional and non-functional requirements of the developed
application.
 User Acceptance Testing (UAT): UAT is performed in a user
environment that resembles the production environment. UAT
verifies that the delivered system meets user’s requirement and
system is ready for use in real world.

Principles of V-Model: 
 
 Large to Small: In V-Model, testing is done in a hierarchical
perspective, For example, requirements identified by the project
team, create High-Level Design, and Detailed Design phases of the
project. As each of these phases is completed the requirements,
they are defining become more and more refined and detailed.
 Data/Process Integrity: This principle states that the successful
design of any project requires the incorporation and cohesion of
both data and processes. Process elements must be identified at
each and every requirements.
 Scalability: This principle states that the V-Model concept has the
flexibility to accommodate any IT project irrespective of its size,
complexity or duration.
 Cross Referencing: Direct correlation between requirements and
corresponding testing activity is known as cross-referencing.
 Tangible Documentation: This principle states that every project
needs to create a document. This documentation is required and
applied by both the project development team and the
The spiral model is a systems development lifecycle (SDLC) method used
for risk management that combines the iterative development process
model with elements of the Waterfall model. The spiral model is used by
software engineers and is favored for large, expensive and complicated
projects.

When viewed as a diagram, the spiral model looks like a coil with many
loops. The number of loops varies based on each project and is often
designated by the project manager. Each loop of the spiral is a phase in the
software development process.

Other benefits of the spiral model include:

 Flexibility - Changes made to the requirements after development

has started can be easily adopted and incorporated.
  Risk handling - The spiral model involves risk analysis and
handling in every phase, improving security and the chances of
avoiding attacks and breakages. The iterative development
process also facilitates risk management.

 Customer satisfaction - The spiral model facilitates customer

feedback. If the software is being designed for a customer, then
the customer will be able to see and evaluate their product in
every phase. This allows them to voice dissatisfactions or make
changes before the product is fully built, saving the development
team time and money.

In order to form a good SRS, here you will see some points which can be
used and should be considered to form a structure of good SRS. These are
as follows : 1. Introduction
 (i) Purpose of this document
 (ii) Scope of this document
 (iii) Overview
2. General description 3. Functional Requirements 4. Interface Requirements
5. Performance Requirements 6. Design Constraints 7. Non-Functional
Attributes 8. Preliminary Schedule and Budget 9. Appendices Software
Requirement Specification (SRS) Format as name suggests, is complete
specification and description of requirements of software that needs to be
fulfilled for successful development of software system. These requirements
can be functional as well as non-functional depending upon type of
requirement. The interaction between different customers and contractor is
done because its necessary to fully understand needs of

customers.   Depending upon

information gathered after interaction, SRS is developed which describes
requirements of software that may include changes and modifications that is
needed to be done to increase quality of product and to satisfy customer’s
demand.
1. Introduction :
 (i) Purpose of this Document – At first, main aim of why
this document is necessary and what’s purpose of
document is explained and described.
 (ii) Scope of this document – In this, overall working and
main objective of document and what value it will provide
to customer is described and explained. It also includes a
description of development cost and time required.
 (iii) Overview – In this, description of product is
explained. It’s simply summary or overall review of
product.
2. General description : In this, general functions of product which
includes objective of user, a user characteristic, features, benefits,
about why its importance is mentioned. It also describes features of
user community.
3. Functional Requirements : In this, possible outcome of software
system which includes effects due to operation of program is fully
explained. All functional requirements which may include
calculations, data processing, etc. are placed in a ranked order.
4. Interface Requirements : In this, software interfaces which mean
how software program communicates with each other or users
either in form of any language, code, or message are fully
described and explained. Examples can be shared memory, data
streams, etc.
5. Performance Requirements : In this, how a software system
performs desired functions under specific condition is explained. It
also explains required time, required memory, maximum error rate,
etc.
6. Design Constraints : In this, constraints which simply means
limitation or restriction are specified and explained for design team.
Examples may include use of a particular algorithm, hardware and
software limitations, etc.
7. Non-Functional Attributes : In this, non-functional attributes are
explained that are required by software system for better
performance. An example may include Security, Portability,
Reliability, Reusability, Application compatibility, Data integrity,
Scalability capacity, etc.
8. Preliminary Schedule and Budget : In this, initial version and
budget of project plan are explained which include overall time
duration required and overall cost required for development of
project.
9. Appendices : In this, additional information like references from
where information is gathered, definitions of some specific terms,
acronyms, abbreviations, etc. are given and explained.
Uses of SRS document:
1. Devlopment team require it for developing product according to the
need.
2. Test plans are generated by testing group based on the describe
external behavior.
3. Maintenance and support staff need it to understand what the
software product is supposed to do.
4. Project manager base their plans and estimates of schedule, effort
and resources on it.
5. customer rely on it to know that product they can expect.
6. As a contract between developer and customer.
7. in documentation purpose.
 

What is SRS?
A software requirements specification (SRS) is a description of a software
system to be developed. It lays out functional and non-functional
requirements and may include a set of use cases that describe user
interactions that the software must provide.
The output of requirement engineering is the requirement specification
document (SRD). it can be considered as a contract between the
development team and the customer which can be also used to resolve any
disagreement that may arise in future.
it is the specification for the particular software product , program or set of
programs that perform certain function. it serves a number of purposes
depending upon who is writing it. the srs document must be written in two
phase:

SRS’s characteristics include:

 Correct
 Unambiguous
 Complete
 Consistent
 Ranked for importance and/or stability
 Verifiable
 Modifiable
 Traceable
DFD is the abbreviation for Data Flow Diagram. The flow of data of a
system or a process is represented by DFD. It also gives insight into the
inputs and outputs of each entity and the process itself. DFD does not have
control flow and no loops or decision rules are present. Specific operations
depending on the type of data can be explained by a flowchart.
It is a graphical tool, useful for communicating with users ,managers and
other personnel. it is useful for analysing existing as well as proposed
system.
It provides an overview of 
 What data is system processes.
 What transformation are performed.
 What data are stored.
 What results are produced , etc.
Data Flow Diagram can be represented in several ways. The DFD belongs to
structured-analysis modeling tools. Data Flow diagrams are very popular
because they help us to visualize the major steps and data involved in
software-system processes.

Components of DFD
The Data Flow Diagram has 4 components:
 Process Input to output transformation in a system takes place
because of process function. The symbols of a process are
rectangular with rounded corners, oval, rectangle or a circle. The
process is named a short sentence, in one word or a phrase to
express its essence
 Data Flow Data flow describes the information transferring between
different parts of the systems. The arrow symbol is the symbol of
data flow. A relatable name should be given to the flow to determine
the information which is being moved. Data flow also represents
material along with information that is being moved. Material shifts
are modeled in systems that are not merely informative. A given
flow should only transfer a single type of information. The direction
of flow is represented by the arrow which can also be bi-directional.
 Warehouse The data is stored in the warehouse for later use. Two
horizontal lines represent the symbol of the store. The warehouse is
simply not restricted to being a data file rather it can be anything
like a folder with documents, an optical disc, a filing cabinet. The
data warehouse can be viewed independent of its implementation.
When the data flow from the warehouse it is considered as data
reading and when data flows to the warehouse it is called data
entry or data updation.
  Terminator The Terminator is an external entity that stands outside of
the system and communicates with the system. It can be, for
example, organizations like banks, groups of people like customers
or different departments of the same organization, which is not a
part of the model system and is an external entity. Modeled systems
also communicate with terminator.

Symbols Used in DFD

 Square Box: A square box defines source or destination of the
system. It is also called entity. It is represented by rectangle.
 Arrow or Line: An arrow identifies the data flow i.e. it gives
information to the data that is in motion.
 Circle or bubble chart: It represents as a process that gives us
information. It is also called processing box.
 Open Rectangle: An open rectangle is a data store. In this data is
store either temporary or permanently. 
UML is a standard language for specifying, visualizing, constructing, and documenting the
artifacts of software systems.
UML was created by the Object Management Group (OMG) and UML 1.0 specification draft
was proposed to the OMG in January 1997.
OMG is continuously making efforts to create a truly industry standard.
 UML stands for Unified Modeling Language.
 UML is different from the other common programming languages such as C+
+, Java, COBOL, etc.
 UML is a pictorial language used to make software blueprints.
 UML can be described as a general purpose visual modeling language to
visualize, specify, construct, and document software system.
 Although UML is generally used to model software systems, it is not limited
within this boundary. It is also used to model non-software systems as well.
For example, the process flow in a manufacturing unit, etc.
UML is not a programming language but tools can be used to generate code in various
languages using UML diagrams. UML has a direct relation with object oriented analysis and
design. After some standardization, UML has become an OMG standard.

Goals of UML
A picture is worth a thousand words, this idiom absolutely fits describing UML. Object-
oriented concepts were introduced much earlier than UML. At that point of time, there were
no standard methodologies to organize and consolidate the object-oriented development. It
was then that UML came into picture.
There are a number of goals for developing UML but the most important is to define some
general purpose modeling language, which all modelers can use and it also needs to be made
simple to understand and use.
UML diagrams are not only made for developers but also for business users, common people,
and anybody interested to understand the system. The system can be a software or non-
software system. Thus it must be clear that UML is not a development method rather it
accompanies with processes to make it a successful system.
In conclusion, the goal of UML can be defined as a simple modeling mechanism to model all
possible practical systems in today’s complex environment.

A Conceptual Model of UML

To understand the conceptual model of UML, first we need to clarify what is a conceptual
model? and why a conceptual model is required?
 A conceptual model can be defined as a model which is made of concepts and
their relationships.
 A conceptual model is the first step before drawing a UML diagram. It helps to
understand the entities in the real world and how they interact with each other.
As UML describes the real-time systems, it is very important to make a conceptual model and
then proceed gradually. The conceptual model of UML can be mastered by learning the
following three major elements −

 UML building blocks

 Rules to connect the building blocks
 Common mechanisms of UML
Object-Oriented Concepts
UML can be described as the successor of object-oriented (OO) analysis and design.
An object contains both data and methods that control the data. The data represents the state
of the object. A class describes an object and they also form a hierarchy to model the real-
world system. The hierarchy is represented as inheritance and the classes can also be
associated in different ways as per the requirement.
Objects are the real-world entities that exist around us and the basic concepts such as
abstraction, encapsulation, inheritance, and polymorphism all can be represented using UML.
UML is powerful enough to represent all the concepts that exist in object-oriented analysis
and design. UML diagrams are representation of object-oriented concepts only. Thus, before
learning UML, it becomes important to understand OO concept in detail.
Following are some fundamental concepts of the object-oriented world −
 Objects − Objects represent an entity and the basic building block.
 Class − Class is the blue print of an object.
 Abstraction − Abstraction represents the behavior of an real world entity.
 Encapsulation − Encapsulation is the mechanism of binding the data together
and hiding them from the outside world.
 Inheritance − Inheritance is the mechanism of making new classes from
existing ones.
 Polymorphism − It defines the mechanism to exists in different forms.

Things
Things are the most important building blocks of UML. Things can be −

 Structural
 Behavioral
 Grouping
 Annotational
Structural Things
Structural things define the static part of the model. They represent the physical and
conceptual elements. Following are the brief descriptions of the structural things.
Class − Class represents a set of objects having similar responsibilities.

Interface − Interface defines a set of operations, which specify the responsibility of a class.

Collaboration −Collaboration defines an interaction between elements.

Use case −Use case represents a set of actions performed by a system for a specific goal.

Component −Component describes the physical part of a system.

Node − A node can be defined as a physical element that exists at run time.

Behavioral Things
A behavioral thing consists of the dynamic parts of UML models. Following are the
behavioral things −
Interaction − Interaction is defined as a behavior that consists of a group of messages
exchanged among elements to accomplish a specific task.

State machine − State machine is useful when the state of an object in its life cycle is
important. It defines the sequence of states an object goes through in response to events.
Events are external factors responsible for state change

Grouping Things
Grouping things can be defined as a mechanism to group elements of a UML model
together. There is only one grouping thing available −
Package − Package is the only one grouping thing available for gathering structural and
behavioral things.

Annotational Things
Annotational things can be defined as a mechanism to capture remarks, descriptions, and
comments of UML model elements. Note - It is the only one Annotational thing available. A
note is used to render comments, constraints, etc. of an UML element.

Relationship
Relationship is another most important building block of UML. It shows how the elements
are associated with each other and this association describes the functionality of an
application.
There are four kinds of relationships available.
Dependency
Dependency is a relationship between two things in which change in one element also affects
the other.

Association
Association is basically a set of links that connects the elements of a UML model. It also
describes how many objects are taking part in that relationship.

Generalization
Generalization can be defined as a relationship which connects a specialized element with a
generalized element. It basically describes the inheritance relationship in the world of objects.

Realization
Realization can be defined as a relationship in which two elements are connected. One
element describes some responsibility, which is not implemented and the other one
implements them. This relationship exists in case of interfaces.

What is object-oriented programming?

Object-oriented programming (OOP) is a computer programming model
that organizes software design around data, or objects, rather than
functions and logic. An object can be defined as a data field that has
unique attributes and behavior.

What is the structure of object-oriented programming?

The structure, or building blocks, of object-oriented programming include
the following:
  Classes are user-defined data types that act as the blueprint for
individual objects, attributes and methods.

 Objects are instances of a class created with specifically defined

data. Objects can correspond to real-world objects or an abstract
entity. When class is defined initially, the description is the only
object that is defined.

 Methods are functions that are defined inside a class that

describe the behaviors of an object. Each method contained in
class definitions starts with a reference to an instance object.
Additionally, the subroutines contained in an object are called
instance methods. Programmers use methods for reusability or
keeping functionality encapsulated inside one object at a time.

 Attributes are defined in the class template and represent the

state of an object. Objects will have data stored in the attributes
field. Class attributes belong to the class itself.
Before we start working on any project, it is very important that we are very
clear on what we want to do and how do we want to do. In my last Blog, I
discussed on how to write a good SRS for your project and what is the
advantage we get out of that. In this Blog, I’ll discuss Use Cases and their
advantage in our projects.
What are Use Cases?
In software and systems engineering, a use case is a list of actions or event
steps, typically defining the interactions between a role (known in the Unified
Modeling Language as an actor) and a system, to achieve a goal. The actor
can be a human, an external system, or time. In systems engineering, use
cases are used at a higher level than within software engineering, often
representing missions or stakeholder goals. Another way to look at it is a use
case describes a way in which a real-world actor interacts with the system. In
a system use case you include high-level implementation decisions. System
use cases can be written in both an informal manner and a formal manner.
(Wiki)
What is the importance of Use Cases?
Class diagram is a static diagram. It represents the static view of an application. Class
diagram is not only used for visualizing, describing, and documenting different aspects of a
system but also for constructing executable code of the software application.
Class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. The class diagrams are widely used in the modeling of objectoriented
systems because they are the only UML diagrams, which can be mapped directly with object-
oriented languages.
Class diagram shows a collection of classes, interfaces, associations, collaborations, and
constraints. It is also known as a structural diagram.

Purpose of Class Diagrams

The purpose of class diagram is to model the static view of an application. Class diagrams are
the only diagrams which can be directly mapped with object-oriented languages and thus
widely used at the time of construction.
UML diagrams like activity diagram, sequence diagram can only give the sequence flow of
the application, however class diagram is a bit different. It is the most popular UML diagram
in the coder community.
The purpose of the class diagram can be summarized as −
 Analysis and design of the static view of an application.
 Describe responsibilities of a system.
 Base for component and deployment diagrams.
 Forward and reverse engineering.
How to Draw a Class Diagram?
Class diagrams are the most popular UML diagrams used for construction of software
applications. It is very important to learn the drawing procedure of class diagram.
Class diagrams have a lot of properties to consider while drawing but here the diagram will
be considered from a top level view.
Class diagram is basically a graphical representation of the static view of the system and
represents different aspects of the application. A collection of class diagrams represent the
whole system.
The following points should be remembered while drawing a class diagram −
 The name of the class diagram should be meaningful to describe the aspect of
the system.
 Each element and their relationships should be identified in advance.
 Responsibility (attributes and methods) of each class should be clearly
identified
 For each class, minimum number of properties should be specified, as
unnecessary properties will make the diagram complicated.
 Use notes whenever required to describe some aspect of the diagram. At the
end of the drawing it should be understandable to the developer/coder.
 Finally, before making the final version, the diagram should be drawn on plain
paper and reworked as many times as possible to make it correct.
The following diagram is an example of an Order System of an application. It describes a
particular aspect of the entire application.
 First of all, Order and Customer are identified as the two elements of the
system. They have a one-to-many relationship because a customer can have
multiple orders.
 Order class is an abstract class and it has two concrete classes (inheritance
relationship) SpecialOrder and NormalOrder.
 The two inherited classes have all the properties as the Order class. In addition,
they have additional functions like dispatch () and receive ().
The following class diagram has been drawn considering all the points mentioned above.

Where to Use Class Diagrams?

Class diagram is a static diagram and it is used to model the static view of a system. The
static view describes the vocabulary of the system.
Class diagram is also considered as the foundation for component and deployment diagrams.
Class diagrams are not only used to visualize the static view of the system but they are also
used to construct the executable code for forward and reverse engineering of any system.
Generally, UML diagrams are not directly mapped with any object-oriented programming
languages but the class diagram is an exception.
Class diagram clearly shows the mapping with object-oriented languages such as Java, C++,
etc. From practical experience, class diagram is generally used for construction purpose.
In a nutshell it can be said, class diagrams are used for −
 Describing the static view of the system.
 Showing the collaboration among the elements of the static view.
  Describing the functionalities performed by the system.
 Construction of software applications using object oriented languages.

We use Activity Diagrams to illustrate the flow of control in a system and

refer to the steps involved in the execution of a use case. We model
sequential and concurrent activities using activity diagrams. So, we basically
depict workflows visually using an activity diagram. An activity diagram
focuses on condition of flow and the sequence in which it happens. We
describe or depict what causes a particular event using an activity diagram.
UML models basically three types of diagrams, namely, structure diagrams,
interaction diagrams, and behavior diagrams. An activity diagram is
a behavioral diagram i.e. it depicts the behavior of a system. 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. We
can depict both sequential processing and concurrent processing of activities
using an activity diagram. They are used in business and process modelling
where their primary use is to depict the dynamic aspects of a system
UML State Machine Diagram
The state machine diagram is also called the Statechart or State Transition diagram,
which shows the order of states underwent by an object within the system. It
captures the software system's behavior. It models the behavior of a class, a
subsystem, a package, and a complete system.

It tends out to be an efficient way of modeling the interactions and collaborations in

the external entities and the system. It models event-based systems to handle the
state of an object. It also defines several distinct states of a component within the
system. Each object/component has a specific state.

Following are the types of a state machine diagram that are given below:

1. Behavioral state machine

The behavioral state machine diagram records the behavior of an object within the
system. It depicts an implementation of a particular entity. It models the behavior of
the system.
2. Protocol state machine
It captures the behavior of the protocol. The protocol state machine depicts the
change in the state of the protocol and parallel changes within the system. But it
does not portray the implementation of a particular component.

Why State Machine Diagram?

Since it records the dynamic view of a system, it portrays the behavior of a software
application. During a lifespan, an object underwent several states, such that the
lifespan exist until the program is executing. Each state depicts some useful
information about the object.

It blueprints an interactive system that response back to either the internal events or
the external ones. The execution flow from one state to another is represented by a
state machine diagram. It visualizes an object state from its creation to its
termination.

The main purpose is to depict each state of an individual object. It represents an

interactive system and the entities inside the system. It records the dynamic behavior
of the system.

Notation of a State Machine Diagram

Following are the notations of a state machine diagram enlisted below:
 a. Initial state: It defines the initial state (beginning) of a system, and it is represented
by a black filled circle.

b. Final state: It represents the final state (end) of a system. It is denoted by a filled
circle present within a circle.

c. Decision box: It is of diamond shape that represents the decisions to be made on

the basis of an evaluated guard.

d. Transition: A change of control from one state to another due to the occurrence of
some event is termed as a transition. It is represented by an arrow labeled with an
event due to which the change has ensued.

e. State box: It depicts the conditions or circumstances of a particular object of a class

at a specific point of time. A rectangle with round corners is used to represent the
state box.

Types of State
The UML consist of three states:

1. Simple state: It does not constitute any substructure.

2. Composite state: It consists of nested states (substates), such that it does not
contain more than one initial state and one final state. It can be nested to any level.
 3. Submachine state: The submachine state is semantically identical to the composite
state, but it can be reused.

AD

How to Draw a State Machine Diagram?

The state machine diagram is used to portray various states underwent by an object.
The change in one state to another is due to the occurrence of some event. All of the
possible states of a particular component must be identified before drawing a state
machine diagram.

The primary focus of the state machine diagram is to depict the states of a system.
These states are essential while drawing a state transition diagram. The objects,
states, and events due to which the state transition occurs must be acknowledged
before the implementation of a state machine diagram.

Following are the steps that are to be incorporated while drawing a state machine
diagram:

1. A unique and understandable name should be assigned to the state transition that
describes the behavior of the system.
2. Out of multiple objects, only the essential objects are implemented.
3. A proper name should be given to the events and the transitions.

When to use a State Machine Diagram?

The state machine diagram implements the real-world models as well as the object-
oriented systems. It records the dynamic behavior of the system, which is used to
differentiate between the dynamic and static behavior of a system.

It portrays the changes underwent by an object from the start to the end. It basically
envisions how triggering an event can cause a change within the system.

State machine diagram is used for:

1. For modeling the object states of a system.

2. For modeling the reactive system as it consists of reactive objects.
3. For pinpointing the events responsible for state transitions.
4. For implementing forward and reverse engineering.
Example of a State Machine Diagram
An example of a top-level state machine diagram showing Bank Automated Teller
Machine (ATM) is given below.

Initially, the ATM is turned off. After the power supply is turned on, the ATM starts
performing the startup action and enters into the Self Test state. If the test fails, the
ATM will enter into the Out Of Service state, or it will undergo a triggerless
transition to the Idle state. This is the state where the customer waits for the
interaction. 

Whenever the customer inserts the bank or credit card in the ATM's card reader, the
ATM state changes from Idle to Serving Customer, the entry action readCard is
performed after entering into Serving Customer state. Since the customer can
cancel the transaction at any instant, so the transition from Serving Customer state
back to the Idle state could be triggered by cancel event.
Sequence Diagram Notations –

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

– notation symbol for actorWe 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. 
 Figure – an actor interacting with a seat reservation system
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  Figure

– lifelineWe 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: 

Figure – a sequence diagram

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 : 
Figure – a sequence diagram with different types of messages
 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. 
 Figure – a sequence diagram using 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. 

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

Figure – a situation where create message is used

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

Figur
e – a scenario where delete message is used
 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.  Figure – self
messageFor example – Consider a scenario where the
device wants to access its webcam. Such a scenario is
represented using a self
message. 

Figure
– a scenario where a self message is used
 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
arrowhead with a dotted line. The interaction moves
forward only when a reply message is sent by the

receiver.  Figure
 – reply messageFor 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. 

Figure
– a scenario where a reply message is used
 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.  Figure

 – found messageIt can be due to multiple reasons and we
are not certain as to what caused the hardware
failure. 

Fig
ure – a scenario where found message is used
 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.  Figure – lost

messageThe 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. 
 Fig
ure – a scenario where lost message is used
4. 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. 
 Figure – sequence diagram using a guard
A sequence diagram for an emotion based music player
– 

Figure – a sequence diagram for an emotion based music playerThe 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.

Uses of sequence diagrams –

 Used to model and visualise the logic behind a sophisticated

function, operation or procedure.
 They are also used to show details of UML use case diagrams.
 Used to understand the detailed functionality of current or future
systems.
 Visualise how messages and tasks move between objects or
components in a system.
References – The sequence diagram – IBM Sequence Diagram –
sparxsystems  This article is contributed by Ankit Jain . If you like
GeeksforGeeks and would like to contribute, you can also write an article
using write.geeksforgeeks.org  or mail your article to review-
team@geeksforgeeks.org. See your article appearing on the GeeksforGeeks
main page and help other Geeks. Please write comments if you find anything
incorrect, or you want to share more information about the topic discussed
above.