UNIT _3

What is Software Design Process?

The Design Phase of software development deals with transforming the customer requirements as described in the
SRS(Software Requirement Specification) documents into a form implementable using a programming language.

Software Design Process is the phase where developers plan how to turn a set of requirements into a working
system. Like a blueprint for the software. Instead of going straight into writing code, developers break down complex
requirements into smaller,

manageable pieces, design the system architecture, and decide how everything will fit together and work.

The software design process can be divided into the following three levels or phases of design:

1. 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 [Link] 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.

Q. What are the Key Principles for Designing User Interfaces

1. 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.
2. Consistency: Consistency is important in user
3. 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.
3. 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.
4. Feedback: Feedback is
5. 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.
5. 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.
6. Flexibility: User interfaces should be designed to be flexible and customizable, allowing users to
tailor the interface to their own preferences and needs.
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.

Coupling and Cohesion

Coupling and Cohesion are two key concepts in software engineering that are used to measure the quality of a software
system's design.

What is Coupling and Cohesion?

Coupling refers to the degree of interdependence between software modules i.e dependency of one
module to other modules. High coupling means that modules are closely connected and changes in one
module may affect other modules. Low coupling means that modules are independent, and changes in one
module have little impact on other modules.
Cohesion refers to the degree to which elements within a module work together to fulfill a single, well-defined
purpose. High cohesion means that elements are closely related and focused on a single purpose, while low cohesion
means that elements are loosely related and serve multiple purposes.

Both coupling and cohesion are important factors in determining the maintainability, scalability, and reliability of a
software system. High coupling and low cohesion can make a system difficult to change and test, while low coupling and
high cohesion make a system easier to maintain and improve.

Basically, design is a two-part iterative process. The first part is Conceptual Design which tells the customer what the
system will do. Second is Technical Design which allows the system builders to understand the actual hardware and
software needed to solve a customer's problem.

Conceptual design of the system:

 Written in simple language i.e. customer understandable language.
 Detailed explanation about system characteristics.
 Describes the functionality of the system.
 It is independent of implementation.
 Linked with requirement document.

Technical Design of the System:

 Hardware component and design.
 Functionality and hierarchy of software components.
 Software architecture
 Network architecture
 Data structure and flow of data.
 I/O component of the system.
 Shows interface.
Modularization is the process of dividing a software system into multiple independent modules where each module
works independently. There are many advantages of Modularization in software engineering. Some of these are given
below:
 Easy to understand the system.
 System maintenance is easy.
 A module can be used many times as their requirements. No need to write it again and again.

Types of Coupling
Coupling is the measure of the degree of interdependence between the modules. A good software will
have low coupling.

T
Types of Coupling
Following are the types of Coupling:
 Data Coupling: If the dependency between the modules is based on the fact that they communicate by passing only
data, then the modules are said to be data coupled. In data coupling, the components are independent of each other
and communicate through data. Module communications don't contain tramp data. Example-customer billing system.
 Stamp Coupling In stamp coupling, the complete data structure is passed from one module to another module.
Therefore, it involves tramp data. It may be necessary due to efficiency factors- this choice was made by the
insightful designer, not a lazy programmer.
 Control Coupling: If the modules communicate by passing control information, then they are said to be control
coupled. It can be bad if parameters indicate completely different behavior and good if parameters allow factoring and
reuse of functionality. Example- sort function that takes comparison function as an argument.
 External Coupling: In external coupling, the modules depend on other modules, external to the software being
developed or to a particular type of hardware. Ex- protocol, external file, device format, etc.
 Common Coupling: The modules have shared data such as global data structures. The changes in global data mean
tracing back to all modules which access that data to evaluate the effect of the change. So it has got disadvantages like
difficulty in reusing modules, reduced ability to control data accesses, and reduced maintainability.
 Content Coupling: In a content coupling, one module can modify the data of another module, or control flow is
passed from one module to the other module. This is the worst form of coupling and should be avoided.
 Temporal Coupling: Temporal coupling occurs when two modules depend on the timing or order of events, such as
one module needing to execute before another. This type of coupling can result in design issues and difficulties in
testing and maintenance.
 Sequential Coupling: Sequential coupling occurs when the output of one module is used as the input of another
module, creating a chain or sequence of dependencies. This type of coupling can be difficult to maintain and modify.
 Communicational Coupling: Communicational coupling occurs when two or more modules share a common
communication mechanism, such as a shared message queue or database. This type of coupling can lead to
performance issues and difficulty in debugging.
 Functional Coupling: Functional coupling occurs when two modules depend on each other's functionality, such as
one module calling a function from another module. This type of coupling can result in tightly-coupled code that is
difficult to modify and maintain.
 Data-Structured Coupling: Data-structured coupling occurs when two or more modules share a common data
structure, such as a database table or data file. This type of coupling can lead to difficulty in maintaining the integrity
of the data structure and can result in performance issues.
 Interaction Coupling: Interaction coupling occurs due to the methods of a class invoking methods of other classes.
Like with functions, the worst form of coupling here is if methods directly access internal parts of other methods.
Coupling is lowest if methods communicate directly through parameters.
 Component Coupling: Component coupling refers to the interaction between two classes where a class has variables
of the other class. Three clear situations exist as to how this can happen. A class C can be component coupled with
another class C1, if C has an instance variable of type C1, or C has a method whose parameter is of type C1,or if C
has a method which has a local variable of type C1. It should be clear that whenever there is component coupling,
there is likely to be interaction coupling.

Types of Cohesion
Cohesion is a measure of the degree to which the elements of the module are functionally related. It is the
degree to which all elements directed towards performing a single task are contained in the component.
Basically, cohesion is the internal glue that keeps the module together. A good software design will have
high cohesion.

Following are the Types of Cohesion:

 Functional Cohesion: Every essential element for a single computation is contained in the component. A functional
cohesion performs the task and functions. It is an ideal situation.
 Sequential Cohesion: An element outputs some data that becomes the input for other element, i.e., data flow between
the parts. It occurs naturally in functional programming languages.
 Communicational Cohesion: Two elements operate on the same input data or contribute towards the same output
data. Example- update record in the database and send it to the printer.
 Procedural Cohesion: Elements of procedural cohesion ensure the order of execution. Actions are still weakly
connected and unlikely to be reusable. Ex- calculate student GPA, print student record, calculate cumulative GPA,
print cumulative GPA.
 Temporal Cohesion: The elements are related by their timing involved. A module connected with temporal cohesion
all the tasks must be executed in the same time span. This cohesion contains the code for initializing all the parts of
the system. Lots of different activities occur, all at unit time.
 Logical Cohesion: The elements are logically related and not functionally. Ex- A component reads inputs from tape,
disk, and network. All the code for these functions is in the same component. Operations are related, but the functions
are significantly different.
 Coincidental Cohesion: The elements are not related(unrelated). The elements have no conceptual relationship other than
location in source code. It is accidental and the worst form of cohesion. Ex- print next line and reverse the characters of a
string in a single component.
 Procedural Cohesion: This type of cohesion occurs when elements or tasks are grouped together in a module
based on their sequence of execution, such as a module that performs a set of related procedures in a specific
order. Procedural cohesion can be found in structured programming languages.
 Communicational Cohesion: Communicational cohesion occurs when elements or tasks are grouped together in a
module based on their interactions with each other, such as a module that handles all interactions with a specific
external system or module. This type of cohesion can be found in object-oriented programming languages.
 Temporal Cohesion: Temporal cohesion occurs when elements or tasks are grouped together in a module based on
their timing or frequency of execution, such as a module that handles all periodic or scheduled tasks in a system.
Temporal cohesion is commonly used in real-time and embedded systems.
 Informational Cohesion: Informational cohesion occurs when elements or tasks are grouped together in a module
based on their relationship to a specific data structure or object, such as a module that operates on a specific data type
or object. Informational cohesion is commonly used in object-oriented programming.
 Functional Cohesion: This type of cohesion occurs when all elements or tasks in a module contribute to a single
well-defined function or purpose, and there is little or no coupling between the elements. Functional cohesion is
considered the most desirable type of cohesion as it leads to more maintainable and reusable code.
 Layer Cohesion: Layer cohesion occurs when elements or tasks in a module are grouped together based on their
level of abstraction or responsibility, such as a module that handles only low-level hardware interactions or a module
that handles only high-level business logic. Layer cohesion is commonly used in large-scale software systems to
organize code into manageable layers.

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

APPROACHES FOR SOFTWARE DESIGN

THERE ARE TWO APPROACHES FOR SOFTWARE DESIGN:

[Link]-Oriented Design in Software Engineering

2. TRADITIONAL APPROACH

[Link]-Oriented Design in Software Engineering

In the object-oriented design method, the system is viewed as a collection of objects (i.e., entities). The state is
distributed among the objects, and each object handles its state data. For example, in a Library Automation Software,
each library representative may be a separate object with its data and functions to operate on these data. The tasks
defined for one purpose cannot refer or change data of other objects. Objects have their internal data which represent
their state. Similar objects create a class. In other words, each object is a member of some class. Classes may inherit
features from the superclass.

The different terms related to object design are:

1. CLASS BASED COMPONENTS:

 1. Objects: All entities involved in the solution design are known as objects. For example, person, banks,
company, and users are considered as objects. Every entity has some attributes associated with it and has
some methods to perform on the attributes.
2. Classes: A class is a generalized description of an object. An object is an instance of a class. A class defines all
the attributes, which an object can have and methods, which represents the functionality of the object.
3. Messages: Objects communicate by message passing. Messages consist of the integrity of the target object,
the name of the requested operation, and any other action needed to perform the function. Messages are
often implemented as procedure or function calls.
4. Abstraction In object-oriented design, complexity is handled using abstraction. Abstraction is the removal of
5. the irrelevant and the amplification of the essentials.
6. Encapsulation: Encapsulation is also called an information hiding concept. The data and operations are linked
to a single unit. Encapsulation not only bundles essential information of an object together but also restricts
access to the data and methods from the outside world.
7. Inheritance: OOD allows similar classes to stack up in a hierarchical manner where the lower or sub-classes
can import, implement, and re-use allowed variables and functions from their immediate [Link]
property of OOD is called an inheritance. This makes it easier to define a specific class and to create
generalized classes from specific ones.
8. Polymorphism: OOD languages provide a mechanism where methods performing similar tasks but vary in
arguments, can be assigned the same name. This is known as polymorphism, which allows a single interface is
performing functions for different types. Depending upon how the service is invoked, the respective portion of
the code gets executed.

2. TRADITIONAL COMPONENT BASED DESIGN:

Function Oriented Design

Last Updated : 17 Mar 2025

Function Oriented design is a method to software design where the model is decomposed into a set of interacting
units or modules where each unit or module has a clearly defined function. Thus, the system is designed from a
functional viewpoint.

Design Notations
Design Notations are primarily meant to be used during the process of design and are used to represent design or
design decisions. For a function-oriented design, the design can be represented graphically or mathematically by the
following:
Data Flow Diagram
Data-flow design is concerned with designing a series of functional transformations that convert system inputs into
the required outputs. The design is described as data-flow diagrams. These diagrams show how data flows through a
system and how the output is derived from the input through a series of functional transformations.

Data-flow diagrams are a useful and intuitive way of describing a system. They are generally understandable without
specialized training, notably if control information is excluded. They show end-to-end processing. That is the flow of
processing from when data enters the system to where it leaves the system can be traced.

Data-flow design is an integral part of several design methods, and most CASE tools support data-flow diagram
creation. Different ways may use different icons to represent data-flow diagram entities, but their meanings are similar.

The notation which is used is based on the following

The report generator produces a report which describes all of the named entities in a data-flow diagram. The user
inputs the name of the design represented by the diagram. The report generator then finds all the names used in the
data-flow diagram. It looks up a data dictionary and retrieves information about each name. This is then collated into a
report which is output by the system.

Data Dictionaries
A data dictionary lists all data elements appearing in the DFD model of a system. The data items listed contain all data
flows and the contents of all data stores looking on the DFDs in the DFD model of a system.

A data dictionary lists the objective of all data items and the definition of all composite data elements in terms of their
component data items. For example, a data dictionary entry may contain that the data grossPay consists of the
parts regularPay and overtimePay.

grossPay = regularPay + overtimePay

For the smallest units of data elements, the data dictionary lists their name and their type.

A data dictionary plays a significant role in any software development process because of the following reasons:

o A Data dictionary provides a standard language for all relevant information for use by engineers working in a project.
A consistent vocabulary for data items is essential since, in large projects, different engineers of the project tend to
use different terms to refer to the same data, which unnecessarily causes confusion.
o The data dictionary provides the analyst with a means to determine the definition of various data structures in terms
of their component elements.
Structured Charts
It partitions a system into block boxes. A Black box system that functionality is known to the user without the
knowledge of internal design.

Structured Chart is a graphical representation which shows:

o System partitions into modules

o Hierarchy of component modules
o The relation between processing modules
o Interaction between modules
o Information passed between modules
The following notations are used in structured chart:
Pseudo-code
Pseudo-code notations can be used in both the preliminary and detailed design phases. Using pseudo-code, the
designer describes system characteristics using short, concise, English Language phases that are structured by
keywords such as If-Then-Else, While-Do, and End.

Software Design Principles

To make sure software is easy to manage, maintain, and update, there are a few important
principles that should guide the design process:
1. Modularity: Think of modularity as breaking down the software into smaller,
independent sections or "modules". Each module handles a specific task, which
makes it much easier to test, maintain, and update without affecting the entire
system.
2. Coupling: Coupling refers to how much one part of the software depends on others.
The goal is to keep the connections between modules to a minimum, so that
changing one module won’t impact others. This makes the software more flexible and
easier to update in the future.
3. Abstraction: Abstraction is about simplifying the software by hiding its complexity. It
only shows users the essential features they need, making the software easier to use
and understand, without overwhelming them with unnecessary details.
4. Anticipation of Change: It's important to design software with future changes in mind.
This means building it in a way that allows for easy updates or adjustments, whether
it's adding new features or adapting to new technologies.
5. Simplicity: Simple designs are the best. Keeping things simple means less room for
errors, and it’s easier to maintain and improve over time. The goal is to avoid
overcomplicating things, keeping the design clean and efficient.
6. Sufficiency & Completeness: The design should make sure the software meets all the
required functions without unnecessary extras. It’s about striking a balance making
sure everything needed is there, but avoiding unnecessary features that can slow
things down or create confusion.
Software Design Phases
The Actual Software Design process travel through the one end to another end of making
and Software well with completion of requirements and the phases which included in the
same that are bellow:

Software Design Phases

1. Understanding Project Requirements

Before jumping into the design, the first step is to make sure the team understands what
the users need, what the business goals are, and any potential challenges. This
understanding sets the foundation for creating a design that meets both user and business
needs.
2. Research, Analysis, and Planning
During this phase, the team gathers data through methods like interviews, surveys, and
focus groups. This helps get a clearer picture of what the users want and allows the team to
design with the user in mind, ensuring the software will truly meet their needs.
3. Designing the Software
In the design phase, the team starts creating visual elements like wireframes, user stories,
and flow diagrams to map out how the system will work. Based on the feedback, prototypes
are created and fine-tuned to make sure the design is moving in the right direction.
4. Technical Design
After gathering feedback, the team gets into more details with the technical design. This
phase involves creating a thorough technical document that outlines exactly how the
software will be implemented, including specific components and how they will work
together.
5. User Interface Design
The focus here is on making sure the software is easy to use. UI designers work on the visual
elements, navigation, and overall user experience to ensure the interface is intuitive and
friendly.
6. Prototyping
Prototypes are created to visualize the design and functionality before the full development
process begins. These can range from simple wireframes (low fidelity) to fully interactive
models (high fidelity) depending on the stage of development.
Elements of Software Design
Good software design is built on several core element that work together to create effective
system.

Software Design Process

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.
A solid architecture verify the system is flexible, stable, and easy to maintain over time.
2. Modules: Modules as the building blocks of the system. Each one handles a specific task
or feature. Breaking a system into smaller modules makes it easier to develop, test, and
maintain the system.
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. Organising the system into components helps keep the code clean and
makes the system more adaptable.
4. Interfaces: These are smaller units within modules that focus on specific functions. This is
the shared boundary across which the components of a system exchange information and
relate.
5. Data: Data is at the heart of any system. It’s all about how information is stored, accessed,
and shared. This is the management of the information and data flow.
Q. What are the Key Principles for Designing User Interfaces
7. 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.
8. 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.
9. 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.
[Link]: 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.
[Link]: 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.
[Link]: User interfaces should be designed to be flexible and customizable,
allowing users to tailor the interface to their own preferences and needs.