UNIT 4-SOFTWARE ENGINEERING

Unified Modeling Language (UML) Diagrams

Unified Modeling Language (UML) is a general-purpose modeling
language. The main aim of UML is to define a standard way to visualize
the way a system has been designed. It is quite similar to blueprints used
in other fields of engineering. UML is not a programming language, it is
rather a visual language.

. What is UML?
Unified Modeling Language (UML) is a standardized visual modeling language
that is a versatile, flexible, and user-friendly method for visualizing a system’s
design. Software system artifacts can be specified, visualized, built, and
documented with the use of UML.
 We use UML diagrams to show the behavior and structure of a system.
 UML helps software engineers, businessmen, and system architects with
modeling, design, and analysis.
The International Organization for Standardization (ISO) published UML as an
approved standard in 2005. UML has been revised over the years and is reviewed
periodically.
2. Why do we need UML?
We need UML (Unified Modeling Language) to visually represent and
communicate complex system designs, facilitating better understanding and
collaboration among stakeholders. Below is why we need UML:
 Complex applications need collaboration and planning from multiple teams
and hence require a clear and concise way to communicate amongst them.
 Businessmen do not understand code. So UML becomes essential to
communicate with non-programmers about essential requirements,
functionalities, and processes of the system.
 A lot of time is saved down the line when teams can visualize processes, user
interactions, and the static structure of the system.
3. Types of UML Diagrams
UML is linked with object-oriented design and analysis. UML makes use of
elements and forms associations between them to form diagrams. Diagrams in
UML can be broadly classified as:
4. Structural UML Diagrams
Structural UML diagrams are visual representations that depict the static aspects of
a system, including its classes, objects, components, and their relationships,
providing a clear view of the system’s architecture. Structural UML diagrams
include the following types:
4.1. Class Diagram
The most widely use UML diagram is the class diagram. It is the building block of
all object oriented software systems. We use class diagrams to depict the static
structure of a system by showing system’s classes, their methods and attributes.
Class diagrams also help us identify relationship between different classes or
objects.
 Class Diagram

4.2. Composite Structure Diagram

We use composite structure diagrams to represent the internal structure of a class
and its interaction points with other parts of the system.
 A composite structure diagram represents relationship between parts and
their configuration which determine how the classifier (class, a component, or
a deployment node) behaves.
 They represent internal structure of a structured classifier making the use of
parts, ports, and connectors.
 We can also model collaborations using composite structure diagrams.
 They are similar to class diagrams except they represent individual parts in
detail as compared to the entire class.
4.3. Object Diagram
An Object Diagram can be referred to as a screenshot of the instances in a system
and the relationship that exists between them. Since object diagrams depict
behaviour when objects have been instantiated, we are able to study the behaviour
of the system at a particular instant.
 An object diagram is similar to a class diagram except it shows the instances of
classes in the system.
 We depict actual classifiers and their relationships making the use of class
diagrams.
 On the other hand, an Object Diagram represents specific instances of classes
and relationships between them at a point of time.

Object Diagram
4.4. Component Diagram
Component diagrams are used to represent how the physical components in a
system have been organized. We use them for modelling implementation details.
 Component Diagrams depict the structural relationship between software
system elements and help us in understanding if functional requirements have
been covered by planned development.
 Component Diagrams become essential to use when we design and build
complex systems.
 Interfaces are used by components of the system to communicate with each
other.

Component Diagram

4.5. Deployment Diagram

Deployment Diagrams are used to represent system hardware and its software. It
tells us what hardware components exist and what software components run on
them.
 We illustrate system architecture as distribution of software artifacts over
distributed targets.
 An artifact is the information that is generated by system software.
 They are primarily used when a software is being used, distributed or deployed
over multiple machines with different configurations.
 Deployement Diagram

4.6. Package Diagram

We use Package Diagrams to depict how packages and their elements have been
organized. A package diagram simply shows us the dependencies between
different packages and internal composition of packages.
 Packages help us to organise UML diagrams into meaningful groups and make
the diagram easy to understand.
 They are primarily used to organise class and use case diagrams.

Package Diagram
5. Behavioral UML Diagrams
Behavioral UML diagrams are visual representations that depict the dynamic
aspects of a system, illustrating how objects interact and behave over time in
response to events.
5.1. State Machine Diagrams
A state diagram is used to represent the condition of the system or part of the
system at finite instances of time. It’s a behavioral diagram and it represents the
behavior using finite state transitions.
 State diagrams are also referred to as State machines and State-chart
Diagrams
 These terms are often used interchangeably. So simply, a state diagram is used
to model the dynamic behavior of a class in response to time and changing
external stimuli.

State Machine Diagram

5.2. Activity Diagrams

We use Activity Diagrams to illustrate the flow of control in a system. We can also
use an activity diagram to refer to the steps involved in the execution of a use case.
 We model sequential and concurrent activities using activity diagrams. So, we
basically depict workflows visually using an activity diagram.
 An activity diagram focuses on condition of flow and the sequence in which it
happens.
 We describe or depict what causes a particular event using an activity diagram.
 Activity Diagram

5.3. Use Case Diagrams

Use Case Diagrams are used to depict the functionality of a system or a part of a
system. They are widely used to illustrate the functional requirements of the
system and its interaction with external agents(actors).
 A use case is basically a diagram representing different scenarios where the
system can be used.
 A use case diagram gives us a high level view of what the system or a part of

the system does with out going into implementation details. ‘

5.4. Sequence Diagram
A sequence diagram simply depicts interaction between objects in a sequential
order i.e. the order in which these interactions take place.
 We can also use the terms event diagrams or event scenarios to refer to a
sequence diagram.
 Sequence diagrams describe how and in what order the objects in a system
function.
 These diagrams are widely used by businessmen and software developers to
document and understand requirements for new and existing systems.

Sequence Diagram

5.5. Communication Diagram

A Communication Diagram (known as Collaboration Diagram in UML 1.x) is used
to show sequenced messages exchanged between objects.
 A communication diagram focuses primarily on objects and their relationships.
 We can represent similar information using Sequence diagrams, however
communication
 diagrams represent objects and links in a free form.

Communication Diagram

5.6. Timing Diagram

Timing Diagram are a special form of Sequence diagrams which are used to depict
the behavior of objects over a time frame. We use them to show time and duration
constraints which govern changes in states and behavior of objects.
5.7. Interaction Overview Diagram
An Interaction Overview Diagram (IOD) is a type of UML (Unified Modeling
Language) diagram that illustrates the flow of interactions between various
elements in a system or process. It provides a high-level overview of how
interactions occur, including the sequence of actions, decisions, and interactions
between different components or objects.
 Interaction Overview Diagram

6. Object-Oriented Concepts Used in UML Diagrams

Examples of object-oriented concepts in UML diagrams include classes, objects,
inheritance, abstraction, encapsulation, and polymorphism. These concepts
improve modularity and clarity by offering an orderly way to show complex
systems.
 Class: An object’s structure and behavior are defined by its class, which serves
as a blueprint.
 Objects: We may divide complex systems into smaller, more manageable
components by using objects. Because of its modularity, we can concentrate
on easily understood components and develop the system gradually.
 Inheritance: Child classes can inherit the characteristics and functions of their
parent classes.
 Abstraction: The main characteristics of a system or object are highlighted in
UML abstraction, while extraneous details are ignored. Stakeholder
communication and understanding are improved by this simplification.
 Encapsulation: Encapsulation is the process of integrating data and restricting
external access in order to maintain the integrity of the data.
 Polymorphism: Flexibility in their use is made possible by polymorphism, the
capacity of functions or entities to take on multiple forms.
6.1. Additions in UML 2.0
 Software development methodologies like agile have been incorporated and
scope of original UML specification has been broadened.
 Originally UML specified 9 diagrams. UML 2.x has increased the number of
diagrams from 9 to 13. The four diagrams that were added are : timing
diagram, communication diagram, interaction overview diagram and
composite structure diagram. UML 2.x renamed statechart diagrams to state
machine diagrams.
 UML 2.x added the ability to decompose software system into components
and sub-components.
7. Tools for creating UML Diagrams
There are several tools available for creating Unified Modeling Language (UML)
diagrams, which are commonly used in software development to visually represent
system architecture, design, and implementation. Here are some popular UML
diagram creating tools:
 Lucidchart: Lucidchart is a web-based diagramming tool that supports UML
diagrams. It’s user-friendly and collaborative, allowing multiple users to work
on diagrams in real-time.
 Draw.io: Draw.io is a free, web-based diagramming tool that supports various
diagram types, including UML. It integrates with various cloud storage services
and can be used offline.
 Visual Paradigm: Visual Paradigm provides a comprehensive suite of tools for
software development, including UML diagramming. It offers both online and
desktop versions and supports a wide range of UML diagrams.
 StarUML: StarUML is an open-source UML modeling tool with a user-friendly
interface. It supports the standard UML 2.x diagrams and allows users to
customize and extend its functionality through plugins.
8. Steps to create UML Diagrams

Creating Unified Modeling Language (UML) diagrams involves a systematic

process that typically includes the following steps:

 Step 1: Identify the Purpose:

o Decide on the objective for which the UML diagram is being made.
Among the many applications for the many types of UML diagrams
are requirements collection, system architecture development, and
class relationship documentation.

 Step 2: Identify Elements and Relationships:

o Choose which crucial elements—classes, objects, use cases, etc.—
should be included in the diagram, along with their relationships.

 Step 3: Select the Appropriate UML Diagram Type:

o Select the type of UML diagram that best suits your modeling
requirements. Class diagrams, use case diagrams, sequence
diagrams, activity diagrams, and more are examples of common
forms.

 Step 4: Create a Rough Sketch:

o A basic sketch on paper or a whiteboard can be useful before
utilizing a UML modeling tool. This can assist you in seeing how the
elements are arranged and related to one another.
 Step 5: Choose a UML Modeling Tool:
o Choose a UML modeling tool based on your needs. Numerous offline
and online applications are available with features for making and
modifying UML diagrams.
 Step 6: Create the Diagram:
 o Create a new project or diagram using the UML modeling tool of
your choice. Start by adding components to the diagram, such as
actors, classes, and use cases, and then link them together with the
proper relationships, such as dependencies and associations.
 Step 7: Define Element Properties:
o Give each diagram element the appropriate qualities and attributes.
Use case specifics, class characteristics and methods, and any other
information unique to the diagram type may be included.
 Step 8: Add Annotations and Comments:
o By using annotations, remarks, and clarifying notes, you can improve
the diagram’s readability.
 Step 9: Validate and Review:
o Check the diagram for completeness and accuracy. Make that the
elements, limitations, and linkages appropriately depict the system
or process that is intended.
 Step 10: Refine and Iterate:
o Refine the diagram based on feedback and additional insights. UML
diagrams are often created iteratively as the understanding of the
system evolves.
Note: Remember that the specific steps may vary based on the UML diagram type
and the tool you are using.
9. UML Diagrams Best Practices
System design can be visually represented and documented with the help of the
Unified Modeling Language (UML). Best practices must be followed in order to
produce UML diagrams that are both useful and significant. UML best practices
include the following:
 Understand the Audience: Consider who will view your UML diagrams as you
create them. Whether your audience consists of developers, architects, or
stakeholders, make sure the type and degree of detail of the diagram meet
their needs.
 Keep Diagrams Simple and Focused: Make sure your diagrams are as simple
as possible. Each one need to draw attention to a certain aspect of the system
or illustrate a particular link.
 Use Consistent Naming Conventions: Use clear and consistent names for
classes, objects, attributes, and methods. Good naming helps everyone
understand the diagrams better.
 Follow Standard UML Notations: Stick to standard UML symbols and
notations. This consistency makes it easier for anyone familiar with UML to
understand your diagrams.
 Keep Relationships Explicit: Clearly define and label how different elements
are connected. Use the right arrows and notations to show the nature of
relationships between classes, objects, or use cases.
10. When to Use UML Diagrams
Use UML Diagrams:
 When a system’s general structure needs to be represented, UML diagrams
can help make it clearer how various parts work together, which facilitates
idea sharing between stakeholders.
 When collecting and recording system requirements, UML diagrams, such as
use case diagrams, can help you clearly grasp user demands by showing how
users will interact with the system.
 If you’re involved in database design, class diagrams are great for illustrating
the relationships among various data entities, ensuring your data model is
well-organized.
 When working with team members or clients, UML diagrams act as a shared
language that connects technical and non-technical stakeholders, improving
overall understanding and alignment.
11. UML and Agile Development
Although Agile development and UML (Unified Modeling Language) are two
distinct approaches to software development, they can work well together. This is
how they are related:
11.1. UML in Agile Development
 Visual Communication: System behavior and design are demonstrated with
the help of UML diagrams. Agile emphasizes the need of clear communication,
and these diagrams help all parties involved—team members, stakeholders,
and even non-technical individuals—understand what is happening.
 Capturing User Stories: Use case diagrams in UML can help capture user
stories, showing how users will interact with the system. This helps everyone
understand the user’s perspective better.
 Building in Steps: Agile development is all about working in small steps, and
UML can adapt to this by allowing models to be created and updated as the
project evolves.
 Simplifying Requirements: Techniques like user story mapping can go hand-in-
hand with UML, making it easier to visualize what needs to be done without
overwhelming documentation.
11.2. Balancing Modeling with Agility
 Smart Modeling: Use UML as much as needed to help with communication,
focusing on delivering useful software rather than getting bogged down in
paperwork.
 Empowering the Team: Give the team the freedom to decide how much
modeling is necessary. They should feel comfortable using UML without
feeling pressured to create too many diagrams
12. Common Challenges in UML Modeling
Below are the common challenges in UML Modeling:
 Accurately representing complex system requirements can be difficult, leading
to either oversimplification or overwhelming detail.
 Team members may interpret the model differently, resulting in
inconsistencies and misunderstandings about its purpose.
 Keeping UML diagrams current as the system evolves can be time-consuming,
risking outdated representations if not managed effectively.
 Agile promotes teamwork, but sometimes UML diagrams are complicated and
only a few people understand them. It can be hard to make sure everyone can
contribute to and use the diagrams effectively.
13. Benefits of Using UML Diagrams
Below are the benefits of using UML Diagrams:
 Developers and stakeholders may communicate using a single visual language
thanks to UML’s standardized approach to system model representation.
 Developers, designers, testers, and business users are just a few of the
stakeholders with whom UML diagrams may effectively communicate.
 UML diagrams make it easier to see the linkages, processes, and parts of a
system.
 One useful tool for documentation is a UML diagram. They offer an ordered
and systematic method for recording a system’s behavior, architecture, and
design, among other elements.
UML – OO-Overview
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

Explore our latest online courses and learn new skills at your own pace. Enroll and
become a certified expert to boost your career.

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.

OO Analysis and Design

OO can be defined as an investigation and to be more specific, it is the investigation of

objects. Design means collaboration of identified objects.

Thus, it is important to understand the OO analysis and design concepts. The most important
purpose of OO analysis is to identify objects of a system to be designed. This analysis is also
done for an existing system. Now an efficient analysis is only possible when we are able to
start thinking in a way where objects can be identified. After identifying the objects, their
relationships are identified and finally the design is produced.

The purpose of OO analysis and design can described as −

 Identifying the objects of a system.

 Identifying their relationships.
 Making a design, which can be converted to executables using OO languages.

There are three basic steps where the OO concepts are applied and implemented. The steps
can be defined as

OO Analysis → OO Design → OO implementation using OO languages

The above three points can be described in detail as −

 During OO analysis, the most important purpose is to identify objects and describe
them in a proper way. If these objects are identified efficiently, then the next job of
design is easy. The objects should be identified with responsibilities. Responsibilities
 are the functions performed by the object. Each and every object has some type of
responsibilities to be performed. When these responsibilities are collaborated, the
purpose of the system is fulfilled.
 The second phase is OO design. During this phase, emphasis is placed on the
requirements and their fulfilment. In this stage, the objects are collaborated according
to their intended association. After the association is complete, the design is also
complete.
 The third phase is OO implementation. In this phase, the design is implemented using
OO languages such as Java, C++, etc.

Role of UML in OO Design

UML is a modeling language used to model software and non-software systems. Although
UML is used for non-software systems, the emphasis is on modeling OO software
applications. Most of the UML diagrams discussed so far are used to model different aspects
such as static, dynamic, etc. Now whatever be the aspect, the artifacts are nothing but objects.

If we look into class diagram, object diagram, collaboration diagram, interaction diagrams all
would basically be designed based on the objects.

Hence, the relation between OO design and UML is very important to understand. The OO
design is transformed into UML diagrams according to the requirement. Before
understanding the UML in detail, the OO concept should be learned properly. Once the OO
analysis and design is done, the next step is very easy. The input from OO analysis and
design is the input to UML diagrams.

Unified Modeling Language (UML) Diagrams

Print Page UML-Diagrams

The UML diagrams are categorized into structural diagrams, behavioral
diagrams, and also interaction overview diagrams. The diagrams are hierarchically
classified in the following figure:
1. Structural Diagrams
Structural diagrams depict a static view or structure of a system. It is widely used in the
documentation of software architecture. It embraces class diagrams, composite structure
diagrams, component diagrams, deployment diagrams, object diagrams, and package
diagrams. It presents an outline for the system. It stresses the elements to be present
that are to be modeled.

o Class Diagram: Class diagrams are one of the most widely used diagrams. It is the
backbone of all the object-oriented software systems. It depicts the static structure of
the system. It displays the system's class, attributes, and methods. It is helpful in
recognizing the relation between different objects as well as classes.
o Composite Structure Diagram: The composite structure diagrams show parts
within the class. It displays the relationship between the parts and their configuration
that ascertain the behavior of the class. It makes full use of ports, parts, and
connectors to portray the internal structure of a structured classifier. It is similar to
class diagrams, just the fact it represents individual parts in a detailed manner when
compared with class diagrams.
o Object Diagram: It describes the static structure of a system at a particular point in
time. It can be used to test the accuracy of class diagrams. It represents distinct
instances of classes and the relationship between them at a time.
o Component Diagram: It portrays the organization of the physical components within
the system. It is used for modeling execution details. It determines whether the
 desired functional requirements have been considered by the planned development
or not, as it depicts the structural relationships between the elements of a software
system.
o Deployment Diagram: It presents the system's software and its hardware by telling
what the existing physical components are and what software components are
running on them. It produces information about system software. It is incorporated
whenever software is used, distributed, or deployed across multiple machines with
dissimilar configurations.
o Package Diagram: It is used to illustrate how the packages and their elements are
organized. It shows the dependencies between distinct packages. It manages UML
diagrams by making it easily understandable. It is used for organizing the class and
use case diagrams.

2. Behavioral Diagrams:
Behavioral diagrams portray a dynamic view of a system or the behavior of a system,
which describes the functioning of the system. It includes use case diagrams, state
diagrams, and activity diagrams. It defines the interaction within the system.

o State Machine Diagram: It is a behavioral diagram. it portrays the system's behavior

utilizing finite state transitions. It is also known as the State-charts diagram. It
models the dynamic behavior of a class in response to external stimuli.
o Activity Diagram: It models the flow of control from one activity to the other. With
the help of an activity diagram, we can model sequential and concurrent activities. It
visually depicts the workflow as well as what causes an event to occur.
o Use Case Diagram: It represents the functionality of a system by utilizing actors and
use cases. It encapsulates the functional requirement of a system and its association
with actors. It portrays the use case view of a system.

3. Interaction Diagrams
Interaction diagrams are a subclass of behavioral diagrams that give emphasis to object
interactions and also depicts the flow between various use case elements of a system.
In simple words, it shows how objects interact with each other and how the data flows
within them. It consists of communication, interaction overview, sequence, and timing
diagrams.

o Sequence Diagram: It shows the interactions between the objects in terms of

messages exchanged over time. It delineates in what order and how the object
functions are in a system.
o Communication Diagram: It shows the interchange of sequence messages
between the objects. It focuses on objects and their relations. It describes the static
and dynamic behavior of a system.
o Timing Diagram: It is a special kind of sequence diagram used to depict the object's
behavior over a specific period of time. It governs the change in state and object
behavior by showing the time and duration constraints.
o Interaction Overview diagram: It is a mixture of activity and sequence diagram that
depicts a sequence of actions to simplify the complex interactions into simple
interactions.

Use Case Diagram – Unified Modeling

Language (UML)
A Use Case Diagram in Unified Modeling Language (UML) is a visual
representation that illustrates the interactions between users (actors) and
a system. It captures the functional requirements of a system, showing
how different users engage with various use cases, or specific
functionalities, within the system. Use case diagrams provide a high-level
overview of a system’s behavior, making them useful for stakeholders,
developers, and analysts to understand how a system is intended to
operate from the user’s perspective, and how different processes relate to
one another. They are crucial for defining system scope and
requirements.

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.
For more insights on how to create effective Use Case Diagrams, the
System Design Course covers the basics and provides practical
applications in system design.
When to apply Use Case Diagram?
Use case diagrams are useful in several situations. Here’s when you
should consider using them:
 When you need to gather and clarify user requirements, use case
diagrams help visualize how different users interact with the system.
 If you’re working with diverse groups, including non-technical
stakeholders, these diagrams provide a clear and simple way to
convey system functionality.
 During the system design phase, use case diagrams help outline user
interactions and plan features, ensuring that the design aligns with user
needs.
 When defining what is included in the system versus what is external,
use case diagrams help clarify these boundaries.
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. 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.
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.

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.
The purpose of system boundary is to clearly outlines the boundaries of
the system, indicating which components are internal to the system and
which are exte rnal actor
 s
or entities interacting with the system.

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

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.”
 Generalization Relationship

How to draw a Use Case diagram in UML?

Below are the main steps to draw 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.
Use Case Diagram example(Online Shopping System)
Let’s understand how to draw a Use Case diagram with the help of an
Online Shopping System:
 Actors:
o Customer
 oAdmin
 Use Cases:
o Browse Products
o Add to Cart
o Checkout
o Manage Inventory (Admin)
 Relations:
o The Customer can browse products, add to the cart, and
complete the checkout.
o The Admin can manage the inventory.
Below is the use case diagram of an Online Shopping System:

What are common Use Case Diagram Tools and Platforms?

Several tools and platforms are available to create and design Use Case
Diagrams. These tools offer features that simplify the diagram creation
process, facilitate collaboration among team members, and enhance
overall efficiency. Here are some popular Use Case Diagram tools and
platforms:

 Lucidchart:
o Cloud-based collaborative platform.

o Real-time collaboration and commenting.
o Templates for various diagram types.
 draw.io:
oFree, open-source diagramming tool.
oWorks offline and can be integrated with Google Drive,
Dropbox, and others.
o Offers a wide range of diagram types, including Use Case
Diagrams.
 Microsoft Visio:
o Part of the Microsoft Office suite.
o Supports various diagram types, including Use Case
Diagrams.

oExtensive shape libraries and templates.
 SmartDraw:
o User-friendly diagramming tool.
o Templates for different types of diagrams, including Use Case
Diagrams.
o Integration with Microsoft Office and Google Workspace.
 PlantUML:
o Open-source tool for creating UML diagrams.
o Text-based syntax for diagram specification.
 o Supports collaborative work using version control systems.
What are Common Mistakes while making Use Case Diagram?
Avoiding common mistakes ensures the accuracy and effectiveness of the
Use Case Diagram. Here are key points for each mistake:
 Adding too much detail can confuse people.
 Unclear connections lead to misunderstandings about system
interactions.
 Different names for the same elements create confusion.
 Incorrectly using generalization can misrepresent relationships.
 Failing to define the system’s limits makes its scope unclear.
 Treating the diagram as static can make it outdated and inaccurate.
Best Practices for Use Case Diagram
Crafting clear and effective Use Case Diagrams is essential for conveying
system functionality and interactions. Here are some best practices to
consider:
 Use Case Diagram focus on capturing the core functions of the system,
avoiding extraneous details.
 They uses a uniform naming scheme for use cases and actors
throughout the diagram to enhance clarity and prevent
misunderstandings.
 They ensure uniformity in the appearance of elements such as ovals
(for use cases), stick figures (for actors), and connecting lines to create
a polished presentation.
 They help in organizing use cases into coherent groups that represent
distinct modules or subsystems within the overall system.
 Use Case Diagrams adopt an iterative method, updating the diagram
as the system changes or as new information emerges.

What is 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:
 Use Case Diagrams offer a clear visual representation of a system’s
functions and its interactions with external users. This representation
helps stakeholders, including those without technical expertise, in
grasping the system’s overall behavior.
 They establish a shared language for articulating system requirements,
ensuring that all team members have a common understanding.
 Use Case Diagram illustrate the different ways users engage with the
system, contributing to a thorough comprehension of its functionalities.
 In the design phase, Use Case Diagrams help outline how users
(actors) will interact with the system. They support the planning of user
interfaces and aid in structuring system functionalities.
 UML - Interaction Diagrams
From the term Interaction, it is clear that the diagram is used to describe
some type of interactions among the different elements in the model. This
interaction is a part of dynamic behavior of the system.

This interactive behavior is represented in UML by two diagrams known

as Sequence diagram and Collaboration diagram. The basic purpose of
both the diagrams are similar.

Sequence diagram emphasizes on time sequence of messages and

collaboration diagram emphasizes on the structural organization of the
objects that send and receive messages.

Purpose of Interaction Diagrams

The purpose of interaction diagrams is to visualize the interactive behavior of

the system. Visualizing the interaction is a difficult task. Hence, the solution
is to use different types of models to capture the different aspects of the
interaction.

Sequence and collaboration diagrams are used to capture the dynamic

nature but from a different angle.

The purpose of interaction diagram is −

 To capture the dynamic behaviour of a system.

 To describe the message flow in the system.
 To describe the structural organization of the objects.
 To describe the interaction among objects.

How to Draw an Interaction Diagram?

As we have already discussed, the purpose of interaction diagrams is to

capture the dynamic aspect of a system. So to capture the dynamic aspect,
we need to understand what a dynamic aspect is and how it is visualized.
Dynamic aspect can be defined as the snapshot of the running system at a
particular moment

We have two types of interaction diagrams in UML. One is the sequence

diagram and the other is the collaboration diagram. The sequence diagram
captures the time sequence of the message flow from one object to another
and the collaboration diagram describes the organization of objects in a
system taking part in the message flow.

Following things are to be identified clearly before drawing the interaction

diagram
  Objects taking part in the interaction.
 Message flows among the objects.
 The sequence in which the messages are flowing.
 Object organization.

Following are two interaction diagrams modeling the order management

system. The first diagram is a sequence diagram and the second is a
collaboration diagram

The Sequence Diagram

The sequence diagram has four objects (Customer, Order, SpecialOrder and
NormalOrder).

The following diagram shows the message sequence for SpecialOrder object
and the same can be used in case of NormalOrder object. It is important to
understand the time sequence of message flows. The message flow is
nothing but a method call of an object.
The first call is sendOrder () which is a method of Order object. The next call
is confirm () which is a method of SpecialOrder object and the last call
is Dispatch () which is a method of SpecialOrder object. The following
diagram mainly describes the method calls from one object to another, and
this is also the actual scenario when the system is running.

The Collaboration Diagram

The second interaction diagram is the collaboration diagram. It shows the
object organization as seen in the following diagram. In the collaboration
diagram, the method call sequence is indicated by some numbering
technique. The number indicates how the methods are called one after
another. We have taken the same order management system to describe the
collaboration diagram.

Method calls are similar to that of a sequence diagram. However, difference

being the sequence diagram does not describe the object organization,
whereas the collaboration diagram shows the object organization.

To choose between these two diagrams, emphasis is placed on the type of

requirement. If the time sequence is important, then the sequence diagram is
used. If organization is required, then collaboration diagram is used.

Explore our latest online courses and learn new skills at your own pace.
Enroll and become a certified expert to boost your career.

Where to Use Interaction Diagrams?

We have already discussed that interaction diagrams are used to describe

the dynamic nature of a system. Now, we will look into the practical scenarios
where these diagrams are used. To understand the practical application, we
need to understand the basic nature of sequence and collaboration diagram.

The main purpose of both the diagrams are similar as they are used to
capture the dynamic behavior of a system. However, the specific purpose is
more important to clarify and understand.

Sequence diagrams are used to capture the order of messages flowing from
one object to another. Collaboration diagrams are used to describe the
structural organization of the objects taking part in the interaction. A single
diagram is not sufficient to describe the dynamic aspect of an entire system,
so a set of diagrams are used to capture it as a whole.
Interaction diagrams are used when we want to understand the message flow
and the structural organization. Message flow means the sequence of control
flow from one object to another. Structural organization means the visual
organization of the elements in a system.

Interaction diagrams can be used −

 To model the flow of control by time sequence.

 To model the flow of control by structural organizations.
 For forward engineering.
 For reverse engineering.

UML - Statechart Diagrams

The name of the diagram itself clarifies the purpose of the diagram and other
details. It describes different states of a component in a system. The states
are specific to a component/object of a system.

A Statechart diagram describes a state machine. State machine can be

defined as a machine which defines different states of an object and these
states are controlled by external or internal events.

Activity diagram explained in the next chapter, is a special kind of a

Statechart diagram. As Statechart diagram defines the states, it is used to
model the lifetime of an object.

Purpose of Statechart Diagrams

Statechart diagram is one of the five UML diagrams used to model the
dynamic nature of a system. They define different states of an object during
its lifetime and these states are changed by events. Statechart diagrams are
useful to model the reactive systems. Reactive systems can be defined as a
system that responds to external or internal events.

Statechart diagram describes the flow of control from one state to another
state. States are defined as a condition in which an object exists and it
changes when some event is triggered. The most important purpose of
Statechart diagram is to model lifetime of an object from creation to
termination.

Statechart diagrams are also used for forward and reverse engineering of a
system. However, the main purpose is to model the reactive system.

Following are the main purposes of using Statechart diagrams −

 To model the dynamic aspect of a system.

 To model the life time of a reactive system.
 To describe different states of an object during its life time.
 Define a state machine to model the states of an object.
How to Draw a Statechart Diagram?

Statechart diagram is used to describe the states of different objects in its life
cycle. Emphasis is placed on the state changes upon some internal or
external events. These states of objects are important to analyze and
implement them accurately.

Statechart diagrams are very important for describing the states. States can
be identified as the condition of objects when a particular event occurs.

Before drawing a Statechart diagram we should clarify the following points −

 Identify the important objects to be analyzed.

 Identify the states.
 Identify the events.

Following is an example of a Statechart diagram where the state of Order

object is analyzed

The first state is an idle state from where the process starts. The next states
are arrived for events like send request, confirm request, and dispatch order.
These events are responsible for the state changes of order object.

During the life cycle of an object (here order object) it goes through the
following states and there may be some abnormal exits. This abnormal exit
may occur due to some problem in the system. When the entire life cycle is
complete, it is considered as a complete transaction as shown in the
following figure. The initial and final state of an object is also shown in the
following figure.
Explore our latest online courses and learn new skills at your own pace.
Enroll and become a certified expert to boost your career.

Where to Use Statechart Diagrams?

From the above discussion, we can define the practical applications of a

Statechart diagram. Statechart diagrams are used to model the dynamic
aspect of a system like other four diagrams discussed in this tutorial.
However, it has some distinguishing characteristics for modeling the dynamic
nature.

Statechart diagram defines the states of a component and these state

changes are dynamic in nature. Its specific purpose is to define the state
changes triggered by events. Events are internal or external factors
influencing the system.

Statechart diagrams are used to model the states and also the events
operating on the system. When implementing a system, it is very important
to clarify different states of an object during its life time and Statechart
diagrams are used for this purpose. When these states and events are
identified, they are used to model it and these models are used during the
implementation of the system.

If we look into the practical implementation of Statechart diagram, then it is

mainly used to analyze the object states influenced by events. This analysis
is helpful to understand the system behavior during its execution.

The main usage can be described as −

  To model the object states of a system.
 To model the reactive system. Reactive system consists of reactive
objects.
 To identify the events responsible for state changes.
 Forward and reverse engineering.

UML - Activity Diagrams

Activity diagram is another important diagram in UML to describe the
dynamic aspects of the system.

Activity diagram is basically a flowchart to represent the flow from one

activity to another activity. The activity can be described as an operation of
the system.

The control flow is drawn from one operation to another. This flow can be
sequential, branched, or concurrent. Activity diagrams deal with all type of
flow control by using different elements such as fork, join, etc

Purpose of Activity Diagrams

The basic purposes of activity diagrams is similar to other four diagrams. It

captures the dynamic behavior of the system. Other four diagrams are used
to show the message flow from one object to another but activity diagram is
used to show message flow from one activity to another.

Activity is a particular operation of the system. Activity diagrams are not only
used for visualizing the dynamic nature of a system, but they are also used to
construct the executable system by using forward and reverse engineering
techniques. The only missing thing in the activity diagram is the message
part.

It does not show any message flow from one activity to another. Activity
diagram is sometimes considered as the flowchart. Although the diagrams
look like a flowchart, they are not. It shows different flows such as parallel,
branched, concurrent, and single.

The purpose of an activity diagram can be described as −

 Draw the activity flow of a system.

 Describe the sequence from one activity to another.
 Describe the parallel, branched and concurrent flow of the system.
How to Draw an Activity Diagram?

Activity diagrams are mainly used as a flowchart that consists of activities

performed by the system. Activity diagrams are not exactly flowcharts as
they have some additional capabilities. These additional capabilities include
branching, parallel flow, swimlane, etc.

Before drawing an activity diagram, we must have a clear understanding

about the elements used in activity diagram. The main element of an activity
diagram is the activity itself. An activity is a function performed by the
system. After identifying the activities, we need to understand how they are
associated with constraints and conditions.

Before drawing an activity diagram, we should identify the following elements

−

 Activities
 Association
 Conditions
 Constraints

Once the above-mentioned parameters are identified, we need to make a

mental layout of the entire flow. This mental layout is then transformed into
an activity diagram.

Following is an example of an activity diagram for order management

system. In the diagram, four activities are identified which are associated
with conditions. One important point should be clearly understood that an
activity diagram cannot be exactly matched with the code. The activity
diagram is made to understand the flow of activities and is mainly used by
the business users

Following diagram is drawn with the four main activities −

 Send order by the customer

 Receipt of the order
 Confirm the order
 Dispatch the order

After receiving the order request, condition checks are performed to check if
it is normal or special order. After the type of order is identified, dispatch
activity is performed and that is marked as the termination of the process.
Explore our latest online courses and learn new skills at your own pace.
Enroll and become a certified expert to boost your career.

Where to Use Activity Diagrams?

The basic usage of activity diagram is similar to other four UML diagrams.
The specific usage is to model the control flow from one activity to another.
This control flow does not include messages.

Activity diagram is suitable for modeling the activity flow of the system. An
application can have multiple systems. Activity diagram also captures these
systems and describes the flow from one system to another. This specific
usage is not available in other diagrams. These systems can be database,
external queues, or any other system.

We will now look into the practical applications of the activity diagram. From
the above discussion, it is clear that an activity diagram is drawn from a very
high level. So it gives high level view of a system. This high level view is
mainly for business users or any other person who is not a technical person.

This diagram is used to model the activities which are nothing but business
requirements. The diagram has more impact on business understanding
rather than on implementation details.

Activity diagram can be used for −

 Modeling work flow by using activities.

 Modeling business requirements.
 High level understanding of the system's functionalities.
  Investigating business requirements at a later stage.

PS Full Form
Last Updated : 24 Apr, 2023





PS stands for PostScript. The printing and publishing business

uses PostScript primarily as a page description language and
programming language. It was created by Adobe Systems in 1982
and quickly rose to become the norm for printing graphics and
text of the highest quality.It is used to describe how text,
graphics, and fonts are arranged in a document. A PostScript
interpreter processes the files and transforms the content into a
printer-friendly format.
PostScript can manage complicated page layouts, support vector
graphics, and generate fonts at high resolutions, among other
qualities that make it particularly useful for printing. A range of
programming tools are also included, including the ability to
define variables, functions, and conditional expressions.
Features or Characteristics of PostScript
1. PostScript is a vector-based language, allowing it to accurately
express visuals as a set of mathematical equations rather than
as individual pixels. This makes it perfect for printing graphics
and photos of the highest quality.
2. Device independence: PostScript can be printed on any printer
that has a PostScript interpreter since it is device-independent.
This enables sharing files between several platforms and
printers simpler.
3. PostScript Interpreter: A PostScript interpreter processes
PostScript files and transforms the data into a printer-friendly
format. Text, graphics, and fonts on complicated page layouts
can all be handled by the interpreter.
4. Font handling: PostScript can produce fonts at high resolutions,
giving printed text a sharp, clear appearance.
5. Programming features: A number of programming features,
such as variables, functions, and conditional expressions, are
included in PostScript. This makes it easy to customise the
output of PostScript documents and automate complicated
printing procedures.
6. The PostScript Language Reference Manual is a thorough
reference for the language that offers in-depth information on
its syntax, instructions, and programming capabilities.
History of PostScript
Adobe Systems created PostScript for the first time in 1982. The
goal of the language was to establish a common page description
language that could be applied to various printing equipment of
any brand or model.
John Warnock, one of the co-founders of Adobe Systems, oversaw
the development of PostScript. He envisioned a language that,
rather than relying on pixel-based graphics, could express the
structure of a printed page using mathematical equations. This
method made it possible to print text, graphics, and photographs
in excellent resolution.
PostScript’s initial iteration was published in 1984 and soon
became well-liked in the printing sector. Many printer makers
chose PostScript as the industry standard for printing text and
images in high-quality.
PostScript Level 2, a new version of PostScript published by Adobe
in 1992, added a number of new capabilities such improved font
management, richer colour support, and quicker processing
times. The new printing standard was extensively embraced and
is now known as PostScript Level 2.
Advantages of PostScript
 PostScript is device-independent, any printer that supports
PostScript can print PostScript files, regardless of the printer’s
brand or model. Because of this, it is a common format for
sharing documents between various platforms.
 Effective representation of pictures and text as mathematical
equations: PostScript is a vector-based language, allowing for
high-quality output. This enables the creation of high-quality
output with distinct lines and characters.
 Processing rapidly and effectively is possible with PostScript
files, even for complicated page layouts with numerous fonts
and graphics.
 A number of programming capabilities, including variables,
functions, and conditional expressions, are included in
PostScript. As a result, complicated printing activities can be
automated, and PostScript document output can be
customised.
 PostScript can produce fonts at high resolutions, giving printed
text a sharp, clear appearance.
 PostScript has strong support for colour, and it can handle spot
colours as well as the CMYK and RGB colour spaces.