UNIT III

Software Design
 Software Design

Software design is a mechanism to transform user requirements into some

suitable form, which helps the programmer in software coding and
implementation.

It deals with representing the client's requirement, as described in SRS (Software

Requirement Specification) document, into a form, i.e., easily implementable
using programming language.

The software design phase is the first step in SDLC (Software Design Life
Cycle), which moves the concentration from the problem domain to the solution
domain.

In software design, we consider the system to be a set of components or modules

with clearly defined behaviors & boundaries.
 The design phase of software development deals with transforming the
customer requirements as described in the SRS documents into a form implementable
using a programming language. The software design process can be divided into the
following three levels or phases of design:

1. Interface Design

2. Architectural Design

3. Detailed Design
Elements of a System

1. Architecture: This is the conceptual model that defines the structure,

behavior, and views of a system. We can use flowcharts to represent and
illustrate the architecture.

2. Modules: These are components that handle one specific task in a

system. A combination of the modules makes up the system.

3. Components: This provides a particular function or group of related

functions. They are made up of modules.

4. Interfaces: This is the shared boundary across which the components of a

system exchange information and relate.

5. Data: This is the management of the information and data flow.

 1. Interface Design
Interface Design
Interface design is the specification of the interaction between
a system and its environment. This phase proceeds at a high level of
abstraction with respect to the inner workings of the system i.e, during
interface design, the internal of the systems are completely ignored,
and the system is treated as a black box. Attention is focused on the
dialogue between the target system and the users, devices, and other
systems with which it interacts.

The design problem statement produced during the problem

analysis step should identify the people, other systems, and devices
which are collectively called agents.
 The user interface is the front-end application view to which the user
interacts to use the software. The software becomes more popular if its
user interface is:
• Attractive
• Simple to use
• Responsive in a short time
• Clear to understand
• Consistent on all interface screens

Types of User Interface

• Command Line Interface: The Command Line Interface provides a command
prompt, where the user types the command and feeds it to the system. The
user needs to remember the syntax of the command and its use.
• Graphical User Interface: Graphical User Interface provides a simple
interactive interface to interact with the system. GUI can be a combination
of both hardware and software. Using GUI, the user interprets the software.
 User Interface Design Process
The analysis and design process of a user interface is
iterative and can be represented by a spiral model. The analysis
and design process of user interface consists of four framework
activities.
1. User, Task, Environmental Analysis, and Modeling
Initially, the focus is based on the profile of users
who will interact with the system, i.e., understanding, skill and
knowledge, type of user, etc., based on the user’s profile users are
made into categories. From each category requirements are
gathered. Based on the requirement’s developer understand how to
develop the interface. Once all the requirements are gathered a
detailed analysis is conducted. In the analysis part, the tasks that
the user performs to establish the goals of the system are
identified, described and elaborated.
2. Interface Design
The goal of this phase is to define the set of interface
objects and actions i.e., control mechanisms that enable the user to
perform desired tasks. Indicate how these control mechanisms
affect the system. Specify the action sequence of tasks and
subtasks, also called a user scenario. Indicate the state of the
system when the user performs a particular task.
3. Interface Construction and Implementation
The implementation activity begins with the creation of a
prototype (model) that enables usage scenarios to be evaluated. As
iterative design process continues a User Interface toolkit that
allows the creation of windows, menus, device interaction, error
messages, commands, and many other elements of an interactive
environment can be used for completing the construction of an
interface.
4. Interface Validation
This phase focuses on testing the interface. The interface
should be in such a way that it should be able to perform tasks
correctly, and it should be able to handle a variety of tasks. It should
achieve all the user’s requirements. It should be easy to use and
easy to learn. Users should accept the interface as a useful one in
their work.
User Interface Design Golden Rules
The following are the golden rules stated by Theo Mandel that must be followed
during the design of the interface. Place the user in control:
• Define the interaction modes in such a way that does not force the user into
unnecessary or undesired actions: The user should be able to easily enter and exit
the mode with little or no effort.
• Provide for flexible interaction: Different people will use different interaction
mechanisms, some might use keyboard commands, some might use mouse, some
might use touch screen, etc., Hence all interaction mechanisms should be provided.
• Allow user interaction to be interruptible and undoable: When a user is doing a
sequence of actions the user must be able to interrupt the sequence to do some
other work without losing the work that had been done. The user should also be
able to do undo operation.
• Streamline interaction as skill level advances and allow the interaction to be
customized: Advanced or highly skilled user should be provided a chance to
customize the interface as user wants which allows different interaction mechanisms
so that user doesn’t feel bored while using the same interaction mechanism.
• Hide technical internals from casual users: The user should not be aware of the
internal technical details of the system. He should interact with the interface just to
do his work.
• Design for direct interaction with objects that appear on-screen: The user should
be able to use the objects and manipulate the objects that are present on the screen
to perform a necessary task. By this, the user feels easy to control over the screen.
Key Principles for Designing User Interfaces
• User-centered design: User interface design should be focused on the needs and
preferences of the user. This involves understanding the user’s goals, tasks, and
context of use, and designing interfaces that meet their needs and expectations.
• Consistency: Consistency is important in user interface design, as it helps users to
understand and learn how to use an application. Consistent design elements such
as icons, color schemes, and navigation menus should be used throughout the
application.
• Simplicity: User interfaces should be designed to be simple and easy to use, with
clear and concise language and intuitive navigation. Users should be able to
accomplish their tasks without being overwhelmed by unnecessary complexity.
• Feedback: Feedback is significant in user interface design, as it helps users to
understand the results of their actions and confirms that they are making progress
towards their goals. Feedback can take the form of visual cues, messages, or
sounds.
• Accessibility: User interfaces should be designed to be accessible to all users,
regardless of their abilities. This involves considering factors such as color
contrast, font size, and assistive technologies such as screen readers.
• Flexibility: User interfaces should be designed to be flexible and customizable,
allowing users to tailor the interface to their own preferences and needs.
Interface design should include the following details:

1. Precise description of events in the environment, or messages from agents

to which the system must respond.

2. Precise description of the events or messages that the system must

produce.

3. Specification of the data, and the formats of the data coming into and
going out of the system.

4. Specification of the ordering and timing relationships between incoming

events or messages, and outgoing events or outputs.
 2. Architectural design
Architectural design is the specification of the major components of a system,
their responsibilities, properties, interfaces, and the relationships and interactions between
them. In architectural design, the overall structure of the system is chosen, but the internal
details of major components are ignored. Issues in architectural design includes:

1. Gross decomposition of the systems into major components.

2. Allocation of functional responsibilities to components.

3. Component Interfaces.

4. Component scaling and performance properties, resource consumption properties,

reliability properties, and so forth.

5. Communication and interaction between components.

The architectural design adds important details ignored during the interface
design. Design of the internals of the major components is ignored until the last phase of
the design.
 Architectural Style
The software needs an architectural design to represent the design
of the software. IEEE defines architectural design as “the process
of defining a collection of hardware and software components and
their interfaces to establish the framework for the development of
a computer system.”

System Category Consists of

• A set of components(eg: a database, computational modules) that

will perform a function required by the system.
• The set of connectors will help in coordination, communication,
and cooperation between the components.
• Conditions that defines how components can be integrated to
form the system.
• Semantic models that help the designer to understand the overall
properties of the system.
1] Data centered architectures:

• A data store will reside at the center of this architecture and is

accessed frequently by the other components that update, add,
delete, or modify the data present within the store.
• The figure illustrates a typical data-centered style. The client
software accesses a central repository. Variations of this approach
are used to transform the repository into a blackboard when data
related to the client or data of interest for the client change the
notifications to client software.
• This data-centered architecture will promote integrability. This
means that the existing components can be changed and new
client components can be added to the architecture without the
permission or concern of other clients.
• Data can be passed among clients using the blackboard
mechanism.
Advantages of Data centered architecture:
• Repository of data is independent of clients.
• Client work independent of each other
• It may be simple to add additional clients.
• Modification can be very easy
2] Data flow architectures:
• This kind of architecture is used when input data is transformed
into output data through a series of computational manipulative
components.
• The figure represents pipe-and-filter architecture since it uses
both pipe and filter and it has a set of components called filters
connected by lines.
• Pipes are used to transmitting data from one component to the
next.
• Each filter will work independently and is designed to take data
input of a certain form and produces data output to the next filter
of a specified form. The filters don’t require any knowledge of the
working of neighboring filters.
• If the data flow degenerates into a single line of transforms, then
it is termed as batch sequential. This structure accepts the batch
of data and then applies a series of sequential components to
transform it.
Advantages of Data Flow architecture:
• It encourages upkeep, repurposing, and modification.
• With this design, concurrent execution is supported.
3] Call and Return architectures
It is used to create a program that is easy to scale and
modify. Many sub-styles exist within this category. Two of them
are explained below.
• Remote procedure call architecture: This components is used to
present in a main program or sub program architecture
distributed among multiple computers on a network.
• Main program or Subprogram architectures: The main program
structure decomposes into number of subprograms or function
into a control hierarchy. Main program contains number of
subprograms that can invoke other components.
4] Object Oriented architecture
The components of a system encapsulate data and the
operations that must be applied to manipulate the data. The
coordination and communication between the components
are established via the message passing.
Characteristics of Object Oriented architecture:
• Object protect the system’s integrity.
• An object is unaware of the depiction of other items.
Advantage of Object Oriented architecture:
• It enables the designer to separate a challenge into a
collection of autonomous objects.
• Other objects are aware of the implementation details of the
object, allowing changes to be made without having an
impact on other objects
5] Layered architecture
• A number of different layers are defined with each layer performing a well-defined set
of operations. Each layer will do some operations that becomes closer to machine
instruction set progressively.
• At the outer layer, components will receive the user interface operations and at the
inner layers, components will perform the operating system
interfacing(communication and coordination with OS)
• Intermediate layers to utility services and application software functions.
• One common example of this architectural style is OSI-ISO (Open Systems
Interconnection-International Organisation for Standardisation) communication
system.
 Detailed Design
Detailed design is the phase where the high-level system architecture is transformed into a
detailed blueprint, including the internal workings of each component, their interactions, data
structures, and algorithms. It's essentially a deep dive into the implementation, ensuring that the
design is not only feasible but also practical for coding.

Key aspects of detailed design:

• Decomposition of components: Breaking down major system components into smaller,
manageable units.
• Functional responsibilities: Assigning specific tasks to each unit.
• User interface design: Defining how users will interact with the software.
• State management: Specifying how units will change states and their interactions.
• Data and control flow: Detailing how data and control flow between units.
• Data structures and algorithms: Defining the specific data structures and algorithms used by each
component.
• Implementation details: Addressing issues like scope, visibility of program elements, and data
packaging.

Relationship to other design phases:

• High-level design: Detailed design builds upon the high-level architecture, providing the specifics
needed for implementation.
• Design for construction: Detailed design should be mindful of how it will be translated into code,
ensuring practicality and avoid unnecessary complexity.
• System design: Detailed design is often referred to as system design because it focuses on creating
a detailed blueprint of the software.
 Detailed Design
Detailed design is the specification of the internal elements of all major
system components, their properties, relationships, processing, and often their
algorithms and the data structures. The detailed design may include:

1. Decomposition of major system components into program units.

2. Allocation of functional responsibilities to units.

3. User interfaces.

4. Unit states and state changes.

5. Data and control interaction between units.

6. Data packaging and implementation, including issues of scope and visibility of

program elements.

7. Algorithms and data structures.

Software Design Levels
 Objectives of Software Design

1) Correctness: Software design should

be correct as per requirement.
2) Completeness: The design should
have all components like data
structures, modules, and external
interfaces, etc.
3) Efficiency: Resources should be used
efficiently by the program.
4) Flexibility: Able to modify on
changing needs.
5) Consistency: There should not be any
inconsistency in the design.
6) Maintainability: The design should be
so simple so that it can be easily
maintainable by other designers.
 Software Design Principles

Software design principles are concerned with providing means to handle the
complexity of the design process effectively.

Effectively managing the complexity will not only reduce the effort needed for design
but can also reduce the scope of introducing errors during design.

Following are the principles of Software Design :---

 Problem Partitioning
For small problem, we can handle the entire problem at once but for
the significant problem, divide the problems and conquer the problem it means
to divide the problem into smaller pieces so that each piece can be captured
separately.
For software design, the goal is to divide the problem into manageable pieces.

Benefits of Problem Partitioning

1.Software is easy to understand
2.Software becomes simple
3.Software is easy to test
4.Software is easy to modify
5.Software is easy to maintain
6.Software is easy to expand
 Abstraction
An abstraction is a tool that enables a designer to consider a
component at an abstract level without bothering about the internal details of
the implementation. Abstraction can be used for existing element as well as the
component being designed.

Here, there are two common abstraction mechanisms

1.Functional Abstraction
2.Data Abstraction

Functional Abstraction
i. A module is specified by the method it performs.
ii. The details of the algorithm to accomplish the functions are not visible to the
user of the function.
Functional abstraction forms the basis for Function oriented design
approaches.

Data Abstraction
Details of the data elements are not visible to the users of data. Data Abstraction
forms the basis for Object Oriented design approaches.
 Modularity
Modularity specifies to the division of software into separate modules
which are differently named and addressed and are integrated later on in to obtain
the completely functional software. It is the only property that allows a program to
be intellectually manageable. Single large programs are difficult to understand and
read due to a large number of reference variables, control paths, global variables,
etc.

The desirable properties of a modular system are:

•Each module is a well-defined system that can be used with other applications.
•Each module has single specified objectives.
•Modules can be separately compiled and saved in the library.
•Modules should be easier to use than to build.
•Modules are simpler from outside than inside.
 Advantages and Disadvantages of Modularity
Advantages of Modularity :-

1) It allows large programs to be written by several or different people

2) It encourages the creation of commonly used routines to be placed in the library and
used by other programs.
3) It simplifies the overlay procedure of loading a large program into main storage.
4) It provides more checkpoints to measure progress.
5) It provides a framework for complete testing, more accessible to test
6) It produced the well designed and more readable program.

Disadvantages of Modularity :-

7) Execution time maybe, but not certainly, longer

8) Storage size perhaps, but is not certainly, increased
9) Compilation and loading time may be longer
10) Inter-module communication problems may be increased
11) More linkage required, run-time may be longer, more source lines must be written, and
more documentation has to be done
 Modular Design
Modular design reduces the design complexity and results in easier and faster
implementation by allowing parallel development of various parts of a system. We discuss a
different section of modular design in detail in this section:
1. Functional Independence: Functional independence is achieved by developing
functions that perform only one kind of task and do not excessively interact with other
modules. Independence is important because it makes implementation more accessible
and faster. The independent modules are easier to maintain, test, and reduce error
propagation and can be reused in other programs as well. Thus, functional independence
is a good design feature which ensures software quality.
It is measured using two criteria:
Cohesion: It measures the relative function strength of a module.
Coupling: It measures the relative inter dependence among modules.

2. Information hiding: The fundamental of Information hiding suggests that modules can
be characterized by the design decisions that protect from the others, i.e., In other words,
modules should be specified that data include within a module is inaccessible to other
modules that do not need for such information.
The use of information hiding as design criteria for modular system provides the
most significant benefits when modifications are required during testing's and later during
software maintenance. This is because as most data and procedures are hidden from other
parts of the software, inadvertent errors introduced during modifications are less likely to
propagate to different locations within the software.
 Strategy of Design
A good system design strategy is to organize the program modules in such a method that are
easy to develop and latter too, change. Structured design methods help developers to deal
with the size and complexity of programs. Analysts generate instructions for the developers
about how code should be composed and how pieces of code should fit together to form a
program.
To design a system, there are two possible approaches:
1.Top-down Approach
2.Bottom-up Approach

1. Top-down Approach: This approach starts

with the identification of the main components
and then decomposing them into their more detailed
sub-components.

2. Bottom-up Approach: A bottom-up approach

begins with the lower details and moves towards
up the hierarchy.
Basically, design is a two-part iterative process. First part is Conceptual Design that tells
the customer what the system will do. Second is Technical Design that allows the system
builders to understand the actual hardware and software needed to solve customer’s
problem.
 Function Oriented Design
The design process for software systems often has two levels. At the
first level, the focus is on deciding which modules are needed for the system
based on SRS (Software Requirement Specification) and how the modules should
be interconnected.

Function Oriented Design is an approach to software design where the

design is decomposed into a set of interacting units where each unit has a clearly
defined function.
Generic Procedure
Start with a high-level description of what the software/program does.
Refine each part of the description by specifying in greater detail the functionality of
each part. These points lead to a Top-Down Structure.
Problem in Top-Down Design Method
Mostly each module is used by at most one other module and that module is called
its Parent module.

Solution to the Problem

Designing of reusable module. It means modules use several modules to do their
required functions.
Function Oriented Design Strategies
Function Oriented Design Strategies are as follows:
1.Data Flow Diagram (DFD): A data flow diagram (DFD) maps out the flow of
information for any process or system. It uses defined symbols like rectangles, circles
and arrows, plus short text labels, to show data inputs, outputs, storage points and the
routes between each destination.
2.Data Dictionaries: Data dictionaries are simply repositories to store information
about all data items defined in DFDs. At the requirement stage, data dictionaries
contains data items. Data dictionaries include Name of the item, Aliases (Other names
for items), Description / purpose, Related data items, Range of values, Data structure
definition / form.
3.Structure Charts: Structure chart is the hierarchical representation of system which
partitions the system into black boxes (functionality is known to users, but inner details
are unknown). Components are read from top to bottom and left to right. When a
module calls another, it views the called module as a black box, passing required
parameters and receiving results.
4.Pseudo Code: Pseudo Code is system description in short English like phrases
describing the function. It uses keyword and indentation. Pseudocodes are used as
replacement for flow charts. It decreases the amount of documentation required.
 Structured Analysis and Structured Design (SA/SD)
Structured Analysis and Structured Design (SA/SD) is a diagrammatic
notation that is designed to help people understand the system. The basic goal
of SA/SD is to improve quality and reduce the risk of system failure. It
establishes concrete management specifications and documentation. It focuses
on the solidity, pliability, and maintainability of the system.
Structured Analysis and Structured Design (SA/SD) is a software
development method that was popular in the 1970s and 1980s. The method is based
on the principle of structured programming, which emphasizes the importance of
breaking down a software system into smaller, more manageable components.
In SA/SD, the software development process is divided into two phases:
(a) Structured Analysis and
(b) Structured Design.
During the Structured Analysis phase, the problem to be solved is analyzed
and the requirements are gathered. The Structured Design phase involves designing
the system to meet the requirements that were gathered in the Structured Analysis
phase.
Here are some key concepts of SA/SD :
1. Functional Decomposition: SA/SD uses functional decomposition to break down a
complex system into smaller, more manageable subsystems. This technique involves
identifying the main functions of the system and breaking them down into smaller
functions that can be implemented independently.

2. Data Flow Diagrams (DFDs): SA/SD uses DFDs to model the flow of data through the
system. DFDs are graphical representations of the system that show how data moves
between the system’s various components.

3. Data Dictionary: A data dictionary is a central repository that contains descriptions of all
the data elements used in the system. It provides a clear and consistent definition of
data elements, making it easier to understand how the system works.

4. Structured Design: SA/SD uses structured design techniques to develop the system’s
architecture and components. It involves identifying the major components of the
system, designing the interfaces between them, and specifying the data structures and
algorithms that will be used to implement the system.

5. Modular Programming: SA/SD uses modular programming techniques to break down

the system’s code into smaller, more manageable modules. This makes it easier to
develop, test, and maintain the system.
SA/SD is combined known as SAD and it mainly focuses on the following 3
points:
1. System
2. Process
3. Technology

SA/SD involves 2 phases:

4. Analysis Phase: It uses Data Flow Diagram, Data Dictionary, State
Transition diagram and ER diagram.
5. Design Phase: It uses Structure Chart and Pseudo Code.
 Design Metrics
Metrics measures quantitative assessment that focuses on
countable values most commonly used for comparing and tracking the
performance of a system. Metrics are used in different scenarios like
analyzing models, designing models, source code, testing, and maintenance.

What are Metrics?

Metrics for the design model of the product focus on evaluating
various aspects of the design process and the resulting model.
• These are essential for evaluating the design model’s quality, efficiency,
maintainability, and overall effectiveness.
• Metrics for design modeling allow developers or software engineers to
evaluate or estimate the design quality and include various architecture and
component-level designs.
 Metrics by Glass and Card
In designing a product, it is very important to have efficient
management of complexity. Complexity itself means very difficult to
understand. We know that systems are generally complex as they
have many interconnected components that make them difficult to
understand. Glass and Card are two scientists who have suggested
three design complexity measures. These are given below :

1. Structural Complexity
Structural complexity depends upon fan-out for modules. It can
be defined as :
S(k) = f2out(k)
Where,
fout represents fanout for module k (fan-out means several
modules that are subordinating module k).
2. Data Complexity
Data complexity is complexity within the interface of the
internal module. It is the size and intricacy of data. For some
module k, it can be defined as :
D(k) = tot_var(k) / [fout(k)+1]
Where tot_var is the total number of input and output
variables going to and coming out of the module.

3. System Complexity
System complexity is a combination of structural and data
complexity. It can be denoted as:
Sy(k) = S(k)+D(k)
When structural, data, and system complexity
increased, overall architectural complexity also increased.
 Complexity Metrics
Complexity metrics are used to measure the complexity of overall
software. These aim to quantify the intricacy and potential difficulties in
understanding, maintaining, and evolving the software design.

1. Cyclomatic Complexity
Cyclomatic complexity measures the number of independent
paths through a program’s source code. The Cyclomatic complexity is a
useful metric to indicate the complexity of a software system. Without
the use of complexity metrics, it is very difficult and time-consuming to
determine complexity in designing products where risk cost emanates.
Even continuous complexity analysis makes it difficult for the project
team and management to solve problems. Measuring Software
complexity leads to improved code quality, increased productivity,
meeting architectural standards, reduced overall cost, increased
robustness, etc.
Formula:
Cyclomatic complexity = E – N + 2
Where E is the total number of edges and N is the total number of nodes.
Example:
In the diagram given below, you can see several edges and several nodes.

So, the Cyclomatic complexity can be calculated as –

Given,
E = 10,
N=8
So,
Cyclomatic complexity
=E–N+2
= 10 – 8 + 2
=4
2. Depth of Inheritance Tree (DIT)
It measures the levels in the inheritance hierarchy for a class or module. A
DIT can indicate increased complexity as changes to the base classes can impact
multiple levels of derived classes.
3. Coupling
This quantifies the number of classes that are coupled to a particular class.
It suggests strong dependencies, which can increase the complexity and reduce
the flexibility of the product.
4. Weighted Methods per Class (WMC)
This calculates the sum of complexities of methods within a class. It
provides an estimate of the overall complexity of the class based on the size and
the complexity of its methods.
5. Component Dependency Metrics
These are used to analyze the dependencies between different
components within the design. Metrics such as fan-in and fan-out can indicate
the complexity due to tight coupling.
6. Architectural Complexity
This evaluates the overall complexity of the architecture itself. High
architectural complexity implies increased development and maintenance
efforts.
 Quality Metrics
Quality metrics for the design model focus on evaluating aspects that contribute to the
overall quality, maintainability, and effectiveness of the design. They help to ensure that the
design meets requirements, easy to understand, and is maintainable. Here are some commonly
used quality metrics:

• Modularity: This measures how well the design can be divided into cohesive and loosely coupled
modules,
• Complexity: Evaluate the complexity of the design model using metrics like cyclomatic complexity
or the number of classes/interfaces per package/ module.
• Abstraction: Assess the level of abstraction in the design, indicating how well the design captures
the essential aspects while hiding the unnecessary details.
• Coupling: Measures the degree of interdependence between the modules.
• Cohesion: This evaluates how well elements within a module belong together. High cohesion
means that the elements within the module are closely related.
• Maintainability: Assesses how easily design can be understood, modified, and extended over
time. This includes ease of making changes and code readability.
• Compatibility: Measures the compatibility of the design with the existing systems. This involves
assessing the adherence to the standards and design patterns.
• Reusability: Measures how easily the components within the design can be reused in other parts
of the system. This may include the number of reusable components.
• Testability: Measures how easily the design can be tested to ensure correctness and reliability.
This includes the ease of writing the unit tests and integration tests.
• Scalability: Measures how well the design can accommodate growing amounts of data, users, or
 Performance Metrics
` Performance metrics focus on evaluating how well the design supports the
expected performance characteristics of the software system. These help in assessing the
efficiency, scalability, responsiveness, and resource utilization of the design. Here are some
commonly used performance metrics:
• Scalability: It measures how well the design model accommodates the increase in
workload. This includes evaluating the ability to handle large datasets, higher user loads, or
increased complexity without significant degradation in performance.
• Response Time: The time taken by the design model to respond to a user request. This
metric is important for assessing the responsiveness of the product.
• Throughput: Measure of the rate at which the design model can process tasks within a
given time frame. This metric is important for systems handling large volumes of
transactions.
• Resource Utilization: Evaluation of the resources such as CPU, memory, and network
bandwidth consumed by the design model during the operation. Efficient resource
utilization ensures optimal performance.
• Latency: The time taken for a request to travel from the source to the destination and back.
Low latency is critical for real-time applications where timely responses are important.
• Memory Usage: Involves the memory assessment of the design model as efficient memory
management ensures optimal performance and minimizes resource contention.
• Energy Efficiency: This involves energy assessment of the design model. This is important
for mobile devices.
• Maintainability: This relates to how easy is to maintain and modify the design model over
 Usability Metrics
Usability metrics for the design model of the product focus on evaluating how user-
friendly and effective is the design in meeting user expectations. It helps to ensure that the
design model supports efficient navigation and overall user satisfaction. Here are some key
usability metrics for the design model of the product:
• Efficiency: Evaluates how quickly a user can complete the tasks once they are familiar with the
design model. This includes metrics like task completion time and number of steps required to
complete common actions.
• Effectiveness: Evaluate the accuracy with which the users can achieve their goals using the design
model. It includes metrics like error rates and task success rates.
• Learnability: This measures how easy it is for first-time users to understand and navigate the
design model. This can be assessed through the time taken to complete basic tasks and ease of
understanding navigation pathways.
• Satisfaction: Measures user satisfaction of the design model. This can be assessed through user
feedback, user surveys, and qualitative assessment of user experiences.
• Visual Design Clarity: Evaluate the clarity of visual elements within the design model. This
involves assessing the layout, iconography, and color scheme.
• Accessibility: Measures the extent to which the design model is accessible to users with special
needs. This involves assessing compliance with accessibility standards (e.g., Web Content
Accessibility Guidelines (WCAG)), support for assistive technologies, and ease of use for users
with impairments.
• Navigation: Evaluate the clarity and organization of the design model’s navigation structure. This
includes assessing the ease of finding information and consistency in navigation.
• Task Complexity: Measures the complexity of tasks performed using the design model.
 Reliability Metrics
Reliability metrics of the design model assess the ability to consistently
perform as expected under various conditions over time. These metrics help
stakeholders assess the robustness and dependability of the design model.
Here are some common reliability metrics:
• Fault Tolerance: Measures the design model’s ability to continue operating
properly in the presence of faults and failures. This includes assessing how well
the design model handles unexpected inputs, errors in data, or component
failures.
• Failure Rate: Measures the frequency of failures encountered during operation.
This involves evaluating the number of failures per unit of time.
• Mean Time Between Failure (MTBF): Calculates the average time interval
between consecutive failures of the design model. A higher MTBF indicates
better reliability.
• Mean Time To Failure (MTTF): Measures the average time until the design
model experiences its first failure during operation.
• Robustness: Evaluate the ability of the design model to function accurately
even with unexpected inputs or variations in workload.
• Resilience: Measures the ability of the design model to recover quickly from
failures, thus minimizing the downtime and impact on users.
 Security Metrics
Security metrics focus on evaluating the effectiveness of the design model in
addressing security threats and vulnerabilities. These help in assessing the
robustness of the design model’s security mechanism. They help
organizations identify weaknesses and prioritize security improvements. Here
are some common security metrics for the design model of the product:
• Threat Modelling Coverage: Measures the extent to which the potential
threats and vulnerabilities are identified and addressed in the design model.
• Vulnerability Density: Measures the density of the security vulnerabilities
identified within the design model. This metric can be derived from code
reviews, vulnerability scanning tools, and security assessments.
• Security Testing Coverage: Measures the extent to which the security testing
has been conducted on the design model.
• Resilience to Known Attacks: Evaluate how well the design model withstands
the known security threats. This includes assessing resilience to common
threats such as SQL injection, cross-site scripting (XSS), etc.
• Completeness of Security Documentation: Assess the completeness of the
security-related documentation for the design model. This includes evaluating
the security architecture diagrams, threat models, and security requirements.
 Scalability Metrics
Scalability metrics for the design model of the product assess the
ability to handle the increasing workload while maintaining performance and
functionality. It is important that the product can adapt to the changing needs
without significant redesign. Here are some common scalability metrics:
• Response Time Under Load: Evaluate the response time of the design model
when exposed to different levels of concurrent users.
• Concurrency Handling: Assess the ability of the design model to manage
multiple concurrent users without significant degradation in performance.
This includes throughput and resource utilization under varying concurrent
levels.
• Scaling Efficiency: Measures how effectively the design model scales out by
adding more nodes. This assesses the increase in workload capacity achieved
by adding nodes.
• Database Scalability: Assess the scalability of the database components
within the design model. This includes database response times and
transaction throughput.
• Network Scalability: Measures the scalability of the network components
used within the design model. These metrics include network latency,
bandwidth utilization, and the ability to handle increased data traffic.
 Cost Metrics
Cost metrics for the design model of the product are important for
evaluating the financial implications associated with developing and
maintaining the product. This helps stakeholders understand and manage
costs effectively throughout the product lifecycle. Here are key cost metrics
relevant to the design model:
• Development Cost: Measures the total expenses incurred during the design
phase. This includes salaries of designers, software tools and licenses, and
other development expenses.
• Equipment Costs: This includes the costs associated with specialized tools,
equipment, and software used in the design process.
• Testing Costs: Measures the expenses related to building prototypes,
conducting testing, and validating the design model. This includes material
costs and labor costs for testing.
• Maintenance Costs: Measures the ongoing costs to maintain and support
the design model. This includes costs for updates, bug fixes, and user
support.
• Training Costs: Measures the expenses related to training personnel on
effectively using the design model. This includes training sessions and
external training services.
 Software Metrics

A software metric is a measure of software characteristics which are measurable or

countable. Software metrics are valuable for many reasons, including measuring software
performance, planning work items, measuring productivity, and many other uses.

Within the software development process, many metrics are that are all connected.
Software metrics are like the four functions of management: Planning, Organization, Control,
or Improvement.

Characteristics of software Metrics

1. Quantitative: Metrics must possess a quantitative nature. It means metrics can be
expressed in numerical values.
2. Understandable: Metric computation should be easily understood, and the method of
computing metrics should be clearly defined.
3. Applicability: Metrics should be applicable in the initial phases of the development of
the software.
4. Repeatable: When measured repeatedly, the metric values should be the same and
consistent.
5. Economical: The computation of metrics should be economical.
6. Language Independent: Metrics should not depend on any programming language.
Classification of Software Metrics
Software metrics can be classified into two types as
follows:
1. Product Metrics: These are the measures of various characteristics
of the software product. The two important software characteristics are:

1. Size and complexity of software.

2. Quality and reliability of software.
These metrics can be computed for different stages of SDLC.
2. Process Metrics: These are the measures of various characteristics
of the software development process. For example, the efficiency of
fault detection. They are used to measure the characteristics of
methods, techniques, and tools that are used for developing software.
 Types of Metrics
• Internal metrics: Internal metrics are the metrics used for measuring properties
that are viewed to be of greater importance to a software developer. For example,
Lines of Code (LOC) measure.
• External metrics: External metrics are the metrics used for measuring properties
that are viewed to be of greater importance to the user, e.g., portability, reliability,
functionality, usability, etc.
• Hybrid metrics: Hybrid metrics are the metrics that combine product, process,
and resource metrics. For example, cost per FP where FP stands for Function Point
Metric.
Project metrics: Project metrics are the metrics used by the project manager
to check the project's progress. Data from the past projects are used to collect
various metrics, like time and cost; these estimates are used as a base of new
software. Note that as the project proceeds, the project manager will check its
progress from time-to-time and will compare the effort, cost, and time with the
original effort, cost and time. Also understand that these metrics are used to
decrease the development costs, time efforts and risks. The project quality can
also be improved. As quality improves, the number of errors and time, as well as
cost required, is also reduced.
Advantages of Software Metrics
1.Reduction in cost or budget.
2.It helps to identify the particular area for improvising.
3.It helps to increase the product quality.
4.Managing the work loads and teams.
5.Reduction in overall time to produce the product,.
6.It helps to determine the complexity of the code and to test the code with resources.
7.It helps in providing effective planning, controlling and managing of the entire product.

Disadvantages of Software Metrics

8.It is expensive and difficult to implement the metrics in some cases.
2.Performance of the entire team or an individual from the team can’t be determined. Only
the performance of the product is determined.
3.Sometimes the quality of the product is not met with the expectation.
4.It leads to measure the unwanted data which is wastage of time.
5.Measuring the incorrect data leads to make wrong decision making.
 Requirements of Software metrics
Software metrics can be used to track productivity plan, future tasks,
monitor performance, and better control the production process during
project management. Together with management functions software
metrics can also help you streamline your projects by establishing more
effective processes, planning software maintenance, and informing
production teams of problems that need to be fixed. Among the many
reasons why software metrics are necessary are the following:
• It is possible to save money by avoiding errors.
• Contributes to better project planning overall.
• Contributes to the development of project planning in general.
• This stimulates a desire to enhance procedures.
• Facilitates a more in-depth examination of the risks.
• Contributes to the analysis of indicators at every testing phase to improve
the effectiveness of problem eradication.
• Over time test automations return on investment rises.
• Strengthens the link between system complexity risks and testing coverage.
 Introduction to UML
Overview
• What is UML?
• A brief history of UML
• Understanding the basics of UML
• UML diagrams
• UML Modeling tools
 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 UML uses mostly graphical notations to express the OO
analysis and design of software projects.
• Simplifies the complex process of software design
 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.
Why UML for Modeling?

• Use graphical notation to communicate more clearly than

natural language (imprecise) and code(too detailed).

• Help acquire an overall view of a system.

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

• UML moves us from fragmentation to standardization.

 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:
Object-Oriented Concepts Used in UML Diagrams
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.
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.
• Enterprise Architect : Enterprise Architect is a comprehensive design and
modeling software tool that helps organizations model various aspects of their
business, systems, and software
Steps to create UML Diagrams
Step 1: Identify the Purpose:
– 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:
– 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:
– 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:
– 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:
– 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:
– 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:
– 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:
– By using annotations, remarks, and clarifying notes, you can improve the
diagram's readability.
Step 9: Validate and Review:
– 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:
– Refine the diagram based on feedback and additional insights. UML diagrams
are often created iteratively as the understanding of the system evolves.
 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:
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.
• Used for describing structure and behavior in the use cases
• Provide a conceptual model of the system in terms of entities and
their relationships
• Used for requirement capture, end-user interaction
• Detailed class diagrams are used for developers
 Class representation
• Each class is represented by a rectangle subdivided into three compartments
– Name
– Attributes
– Operations
• Modifiers are used to indicate visibility of attributes and operations.
– ‘+’ is used to denote Public visibility (everyone)
– ‘#’ is used to denote Protected visibility (friends and derived)
– ‘-’ is used to denote Private visibility (no one)
• By default, attributes are hidden and operations are visible.

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

Supertype Example: Customer

Regular Loyalty
Customer Customer

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

• Represent relationship between instances of

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

student
1 *

University Person

0..1 *
employer teacher

Role
Multiplicity
Symbol Meaning
1 One and only one Role
0..1 Zero or one “A given university groups many people;
M..N From M to N (natural some act as students, others as teachers.
language) A given student belongs to a single
* From zero to any positive university; a given teacher may or may not
integer be working for the university at a particular
0..* From zero to any positive time.”
integer
1..* From one to any positive
integer
 Class Diagram
Name Order class
-dateReceived
Multiplicity: mandatory
Attributes -isPrepaid Customer
-number :String
-price : Money
* 1 -name
-address
+dispatch() Association +creditRating() : String()
Operations +close()

1
{if Order.customer.creditRating is Generalization
"poor", then Order.isPrepaid must
be true }

Corporate Customer Personal Customer

-contactName -creditCard#
Constraint -creditRating
-creditLimit
Multiplicity: (inside braces{}}
+remind()
+billForMonth(Integer)
Many value
0..1
Multiplicity:
optional *
Employee
*
OrderLine
-quantity: Integer 1
-price: Money * Product
-isSatisfied: Boolean
 Association: Model to Implementation
* 4
Student Course
has enrolls

Class Student {
Course enrolls[4];
}

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

It expresses a relationship where an instance of the

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

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

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

Composition should also be used to express relationship where

Example instances of the Whole-class have exclusive access to and
control of instances of the Part-classes.
Automobile
Composition should be used to express a relationship where
the behavior of Part instances is undefined without being
related to an instance of the Whole. And, conversely, the
behavior of the Whole is ill-defined or incomplete if one or
more of the Part instances are undefined.
Engine Transmission
 OO Relationships: Aggregation
Container Class Aggregation: expresses a relationship among
instances of related classes. It is a specific kind of
Class C
Container-Containee relationship.
AGGREGATION
It expresses a relationship where an instance of the
Container-class has the responsibility to hold and
maintain instances of each Containee-class that have
Class E1 Class E2
been created outside the auspices of the Container
class.

Containee Classes Aggregation should be used to express a more

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

Apples Milk
 Aggregation vs. Composition

Composition is really a strong form of aggregation

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

• Aggregations may form "part of" the aggregate, but may not
be essential to it. They may also exist independent of the
aggregate.
e.g. Apples may exist independent of the bag.
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.
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.
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.
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.
 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.
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 Diagrams
(Traffic light example)

Traffic Light Start

State
Transition Red

Yellow

Green

Event
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.
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 without going into
implementation details.
• Used for describing a set of user scenarios
• Mainly used for capturing user requirements
• Work like a contract between end user and software
developers.
 Use Case Diagram (core components)
Actors: A role that a user plays with respect to the system,including
human users and other systems. e.g.,inanimate physical objects (e.g. robot);
an external system that needs some information from the current system.
Use case: A set of scenarios that describing an interaction between a user
and a system, including alternatives.

System boundary: rectangle diagram representing the boundary

between the actors and the system.
 Use Case Diagram(core relationship)
Association: communication between an actor and a use case; Represented by
a solid line.

Generalization: relationship between one general use case and a special use
case (used for defining special alternatives)
Represented by a line with a triangular arrow head toward the parent use case.

Include: a dotted line labeled <<include>> beginning at base use case and
ending with an arrows pointing to the include use case. The include
relationship occurs when a chunk of behavior is similar across more than one
use case. Use “include” in stead of copying the description of that behavior.
<<include>>
Extend: a dotted line labeled <<extend>> with an arrow toward the base case.
The extending use case may add behavior to the base use case. The base class
declares “extension points”.
<<extend>>
 Use Case Diagrams

Boundary Use Case

Actor
Library System

Borrow Employee
Client

Order Title

Fine Remittance

Supervisor

• A generalized description of how a system will be used.

• Provides an overview of the intended functionality of the system
Use Case Diagrams(cont.)

(TogetherSoft, Inc)
 Use Case Diagrams(cont.)
•Pay Bill is a parent use case and Bill Insurance is the
child use case. (generalization)

•Both Make Appointment and Request Medication

include Check Patient Record as a subtask.(include)

•The extension point is written inside the base case

Pay bill; the extending class Defer payment adds the
behavior of this extension point. (extend)
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(make a phone call)

Caller Phone Recipient

Picks up

Dial tone

Dial

Ring notification Ring

Picks up

Hello
Sequence Diagram:Object interaction

A B

Self-Call: A message that an Synchronous

Object sends to itself.
Asynchronous
Condition: indicates when a
message is sent. The message is Transmission
delayed
sent only if the condition is true.

[condition] remove()
Condition
*[for each] remove()
Iteration
Self-Call
 Sequence Diagrams – Object Life Spans

• Creation
A
– Create message
– Object life starts at that point
• Activation Create
B
– Symbolized by rectangular stripes
– Place on the lifeline where object is
activated.
– Rectangle also denotes when object
is deactivated.
• Deletion Activation bar
X
Return
– Placing an ‘X’ on lifeline Deletion
– Object’s life ends at that point Lifeline
 Sequence Diagram

Us er Message Catalog Res ervations

1: look up ()

2: title data ()

3: [not available] res erve title ()

4 : title returned ()

5: hold title ()

5 : title available ()

6 : borrow title ()

6 : rem ove res ervation ()

•Sequence diagrams demonstrate the behavior of objects in a use case

by describing the objects and the messages they pass.
•The horizontal dimension shows the objects participating in the interaction.
•The vertical arrangement of messages indicates their order.
•The labels may contain the seq. # to indicate concurrency.
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.
6. 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.
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.
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.

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.