Unit 2

Software Design
Introduction of Unit:
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.

Objectives of Software Design

Following are the purposes 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.

Overview of design process: High-level and detailed

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

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.

Software Design Process

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

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

Architectural Design (High Level):

Architectural design is the specification of the major components of a system, their
responsibilities, properties, interfaces, and the relationships and interactions between them.

Objective: The primary goal of architectural design is to define the system's architecture and the
main components that will be developed. This stage focuses on the overall structure rather than
the specifics of implementation.

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.

Activities:
1. Architectural Design: Identify the major components of the system and their interactions. This
includes defining subsystems, modules, and their relationships.
2. Component Decomposition: Break down the system into smaller, more manageable parts or
components.
3. Data Design: Define the data structures and database design that will be used to store and
manage data.
4. Interface Design: Specify the interfaces between the system components, including how they
will communicate and interact.
5. Technology Selection: Choose the technologies, frameworks, and platforms that will be used
to implement the system.

Outputs:
Architecture Diagrams: Visual representations of the system's structure and components.
Component Specifications: Descriptions of the components, their responsibilities, and
interactions.
Data Models: Diagrams and descriptions of the data structures and databases.
Interface Specifications: Detailed descriptions of the interfaces between components.

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.

Objective: The goal of detailed design is to refine the high-level design into a detailed blueprint
for implementation. This stage focuses on the specifics of how each component will be built.
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.

Activities:
1. Algorithm Design: Develop algorithms and detailed logic for the functions and methods
within each component.
2. Data Structure Design: Specify the exact data structures to be used within the components.
3. Component Design: Define the internal structure of each component, including classes,
methods, and their interactions.
4. Interface Design: Further refine the interfaces, detailing the methods, parameters, and return
values.
5. Error Handling and Exceptions: Define how the system will handle errors and exceptional
conditions.

Outputs:
Detailed Class Diagrams: Diagrams showing the classes, their attributes, methods, and
relationships.
Pseudo Code or Flowcharts: Detailed representations of the algorithms and logic.
Detailed Interface Descriptions: Comprehensive descriptions of the interfaces with method
signatures and protocols.
Error Handling Specifications: Guidelines and mechanisms for handling errors and exceptions.

Relationship Between High-Level and Detailed Design:

The high-level design provides a broad view of the system, focusing on its structure and the
relationships between its major components. The detailed design, on the other hand, zooms in on
each component, specifying exactly how it will be implemented. The detailed design is built
upon the foundation laid by the high-level design, ensuring that the overall system architecture is
adhered to and that all components work together seamlessly.

By dividing the design process into these two stages, software engineers can ensure that the
system is well-structured, maintainable, and scalable. High-level design allows for a clear
understanding of the system's architecture, while detailed design ensures that each component is
thoroughly planned and ready for implementation.

Cohesion and Coupling Design Methodologies

Cohesion and coupling in software engineering are two important concepts that describe the
relationship between the modules or components in a software system.
They are used to assess the quality of the design & to measure how well the system's components
interact with each other.
Coupling represents the relationships between modules, and cohesion defines the relationships
within them.

Cohesion:
Cohesion in software engineering refers to the degree to which the responsibilities of a single
module are related & focussed.
It measures how strongly the internal elements of a module are connected & work together to
achieve a common purpose.
High cohesion in software engineering promotes reusability, maintainability, and
understandability of the code.
The higher the degree of cohesion, better the quality of the software.
Cohesion in software engineering refers to the degree to which the elements inside a
module/components belong together, directed towards performing a single task.
In simple words, it is the degree to which the elements of the module are functionally related.
A module with high cohesion encompasses elements tightly related to each other and united in
their purpose.
But, a module is said to have low cohesion if it contains unrelated elements, and if the module
has all related elements, it is considered to have high cohesion.
A good software design will have high cohesion.
The concept of cohesion is closely related to the Single Responsibility Principle, where a class
should only have one responsibility or should perform a single task.
The modules following the SRP are likely to have high cohesion as they are meant to perform a
single task in the software.

Different types of Cohesion in software engineering:

The types of Cohesion in software engineering are:
1. Functional Cohesion:
One of the types of cohesion in software engineering is functional cohesion that occurs when the
elements within a module perform a single, well-defined task or a function.
All the elements within the module contribute to achieving the same objective.
This type of cohesion is considered the most desirable & strongest.
Examples - reading transaction records, cosine angle computation, seat assignment to an airline
passenger, etc.

2. Sequential Cohesion:
Sequential cohesion occurs when the elements within a module are arranged in a specific
sequence, with the output of one element serves as the input for the next element.
The elements are executed in a step-by-step manner to achieve a particular functionality.
Examples - cross-validated records and formatting of a module, raw records usage, formatting of
raw records, cross-validation of fields in raw records, etc.

3. Communicational Cohesion:
Communicational cohesion is anohter one of the types of cohesion in software engineering
occurs when the elements within a module operate on the same input data or share data through
parameters.
The elements within the module work together by passing data to each other.
It is weaker than sequential cohesion.
Example - usage of a customer account number, finding the name of the customer, the loan
balance of the customer, etc.

4. Procedural Cohesion
Procedural cohesion occurs when the elements within a module are grouped based on a specific
sequence of actions or steps.
This type of cohesion is weaker than the communicational cohesion.
Examples - Read, write, edit of the module, zero padding to the numeric fields, returning records,
etc.

5. Temporal Cohesion
Temporal cohesion occurs when the elements within a module are executed at the same time or
within the same timeframe.
It is considered weaker than the procedural cohesion.
Examples - Setting the counter to zero, opening the student file, clearing the variables of error
messages, initializing the array, etc.

6. Logical Cohesion
Logical cohesion occurs when the elements within a module are logically related, but do not fit
into any other cohesion types.
It is not strong as other cohesion types.
Examples - When a component reads inputs from tape, disk, and network, etc.

7. Coincidental Cohesion
Coincidental cohesion occurs when the elements are not related to each other.
Examples - Module for miscellaneous functions, customer record usage, displaying of customer
records, calculation of total sales, and reading the transaction record, etc.

Coupling
Coupling in software engineering refers to the degree of interdependence between two or more
modules in a system.
It measures how closely the modules are connected & how much they rely on each other.
Low Coupling in software engineering promotes independence, modularity, and flexibility of the
code.
The lower the degree of coupling, better the quality of the software.

Coupling in software engineering refers to the degree of interdependence & connection between
modules or components within a software system.
Two modules are said to have high coupling if they are closely connected.
In simple words, coupling is not just about modules, but the connection between modules and the
degree of interaction or interdependence between the two modules. If two modules contain a
good amount of data, then they are highly interdependent.
If the connection between components is strong, we speak about strongly coupled modules;
when the connection is weak, we speak about the loosely coupled modules.
Different types of Coupling in software engineering?
Here are the 6 types of coupling in software engineering:

1. Data Coupling
Data coupling is a type of coupling in software engineering that occurs when modules share data
through parameters or arguments.
Each module maintains its own data and does not exactly access or modify the data of other
modules.
This type of coupling promotes encapsulation & module interdependence.
2. Stamp Coupling
Stamp coupling is a weaker form of coupling where modules share a composite data structure,
but not all the elements are used by each module.
As the data and elements are pre-organized and well-placed beforehand, no junk or unused data
is shared or passed between the two coupling modules which improves the efficiency of the
modules.
3. Control Coupling
Control coupling is one of the types of coupling in software engineering occurs when one
module controls the behavior of another module.
This type of coupling implies that one module has knowledge of internal workings & decisions
or another module, that makes the code more difficult to maintain.
4. External Coupling
External coupling measures the degree to which the system relies on external entities to fulfill its
functionality or interact with the external environment.
Low external coupling - Changes in the external entities have little impact on internal
implementation of the system.
Medium external coupling - Changes in the external entities require some modifications within
the system to accomodate new interfaces.
High external coupling - Changes in the external entities have a substantial impact on internal
implementation of the system, requiring extensive modifications.
5. Common Coupling
Common coupling occurs when two or more modules in the system share global data.
The modules can access & manipulate the same global variables & the data structures.
6. Content Coupling
Content coupling is another type of coupling in software engineering that occurs when one
module directly accesses or modifies the content of another module.
This type of coupling is strong & undesirable since it tightly couples the modules, making them
highly independent on each other's implementation.

Relationship between Cohesion and Coupling in software engineering

The relationship between coupling and cohesion in software engineering can be determined by
these factors:
Inverse Relationship - When Cohesion is high, Coupling tends to be low. High Cohesion means
that the elements within a module are closely related & work together to achieve a defined
purpose.
Design Objective - High Cohesion & Low Coupling contribute towards improved
maintainability, reusability, & the flexibility of the software system.
Impact on Software Quality - High Cohesion contributes to better understandability,
readability, & maintainability of the codebase. Low Coupling reduces the interdependencies
between the modules.
Trade-Offs - Developers need to strike a balance based on the specific requirements & the
constraints of the system.

Function–Oriented software design:

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

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

Advantages of Function-Oriented Design

Simplicity: Easier to understand and manage due to its focus on specific tasks.
Modularity: Functions can be developed, tested, and maintained independently.
Reusability: Common functions can be reused across different parts of the system or in different
projects.

Disadvantages of Function-Oriented Design

Scalability: May become complex and difficult to manage as the system grows larger.
Data-Centric: Less emphasis on the relationships between data and the functions that operate on
them.
Maintainability: Changes in requirements can lead to significant redesign of the function
structure.

Structured Analysis using DFD Structured Design

using Structure Char
Structured Analysis Tools are techniques and graphical representations used in structured
analysis methodologies to understand, analyze, and design complex systems. These tools help in
visualizing system requirements, processes, and data flow. Some common structured analysis
tools include:
1. Data Flow Diagrams (DFDs): Graphical representations showing how data moves
through a system, depicting processes, data stores, and data flows.
2. Entity-Relationship Diagrams (ERDs): Illustrate the relationships between different
entities in a system, emphasizing data storage and retrieval.
3. Data Dictionary: Provides a comprehensive list of data elements used in the system,
along with their definitions, attributes, and relationships.
4. Structured English: A textual representation of processes and logic using structured
programming constructs, enhancing readability and comprehension.
5. Decision Trees: Diagrams representing decision points and outcomes, aiding in
understanding complex decision-making processes.
6. State Transition Diagrams: Illustrate the various states of a system and the transitions
between these states, useful for modeling system behavior.
7. Process Specifications: Detailed descriptions of individual system processes, including
inputs, outputs, and processing logic.

Data Flow Diagrams or Bubble Chart

Data Flow Diagrams (DFDs) are graphical representations used in structured analysis to depict
the flow of data within a system. They illustrate how data moves from external sources through
processes and eventually to output destinations or data stores. DFDs consist of various
components such as processes, data stores, data flows, and external entities, all interconnected to
represent the flow of information within the system.
On the other hand, a bubble chart is a type of chart that displays data points as bubbles or circles
on a two-dimensional grid. Each bubble represents a data point, and its size typically correlates
with a numerical value associated with that data point. Bubble charts are useful for visualizing
and comparing relationships between multiple variables, as the position and size of each bubble
convey information about the data it represents. They are often used in data visualization to
depict complex datasets and identify patterns or trends.
Also see, Install Homebrew

Importance of SA/AD
If you are trying to build a system or upgrade a system then system Analysis and Design is kind
of the backbone of it. This is a kind of layout of the whole system.let’s list of some of them.
 To improve the quality of the system and thus reducing the occurrences of error in the
system. By analysing the problem definitely errors can be reduced.
 To manage and to make the flow of the system it is really helpful.
 Software development is a process that involves architecture, database and backend
development etc, this is what we call analysis which is required to design good software.
 Works in the longer run. The analysis helps in keeping in mind to build such a system

that may face future challenges too.

  It is the analysis and design of the software which makes it different from a cowboy
system. Because of this only we get a decent and a system with a future point of view too.

Steps involved in the SA/SD process

Structured Analysis and Structured Design, sometimes known as the SA/SD process, is a
well-known software development technique that includes the following steps:
Structured Analysis
 Collecting requirements
 Modelling of data flow
 Modelling of entity-relationships
 Modelling of state machines
 Using case studies
 Detailed Design

System architecture design

 Module layout
 Interface style
 Development of pseudocode

Phases of Structured Analysis and Structured Design (SA/SD)

Structured Analysis and Structured Design (SA/SD) is a diagrammatic notation system design
technique designed to help people better understand it. One of Structured Analysis and
Structured Design (SA/SD) is to improve quality and reduce the risk of system failure. It
establishes concrete management specifications and documentation. It focuses on the reliability,
flexibility, and maintainability of the system.

Structured Analysis and Structured Design (SA/SD) comprises the following 2 phases:
1. Analysis Phase
2. Design Phase

Analysis Phase
The phase uses diagrammatic system representations using Data Flow Diagram(DFDs), Data
Dictionary, State Transition, and ER diagrams. The analysis phase enables the analyst to
logically comprehend the system and its operations. Here, the system development process
makes use of a variety of tools and methods. It makes use of graphical tools to examine and
improve the goals of an existing system and create a new system definition that the user can
readily comprehend.
1. Data Flow Diagram: In a DFD model, describe how the data flows through the system. It is a
hierarchical graphical model that mainly shows the system’s different functions (or processes)
and the data interchange among the methods.
It is helpful to consider each function as a processing station such that each function consumes
some input data and produces some output data.

The Data Flow diagram Symbols used here, hold the following meaning ->
A directed arc or line here represents data flow in the direction of the arrow where data flow
symbols are annotated with names of the data that they carry.

The Data Store Symbol here represents a logical file that can either be a Data Structure or a
physical file on a disk. Each data store is connected to a process with the help of a data flow
symbol.
The direction of the data flow arrow shows whether data is being read from
or written into it. An arrow into or out of a data store implicitly represents the entire data
whereas the arrows connecting to a data store need not be annotated with any data name.

2. Data Dictionary: A DFD is always accompanied by a data dictionary. A data dictionary lists
all data items appearing in a DFD defining data stores and their relevant meaning.
3. State Transition Diagram: The State Transition Diagram is similar to the Dynamic model. It
specifies how much time the function will take to execute and data access triggered by the
various events involved.

The State Transition diagram Symbols used here, hold the following meaning:

4. ER Diagram: This is a graphical representation of the data layout of a system at a high level
of abstraction that defines data elements and their inter-relationships in the design and the
relationship between data stores.
Design Phase
Involves the use of a Structure Chart and Pseudo Code to model a system. The high level design
or software architecture for the specified problem is another name for this design phase. The goal
of phase design is to specify the solution's structure so that it may be put into practise.

1. Structure Chart: It is created and defined by the DFD. The structure Chart specifies how a
DFD’s processes are grouped into tasks and allocated to CPU’s or other such relative systems.

2. Pseudo Code: It is the actual implementation of the system showing the process specifications
and implied details but not shown in a DFD.
The origins of using a Structured Analysis and Structured Design (SA/SD) approach
Structured Analysis and Structured Design (SA/SD) has a history from way back in the late
1970s modeled by DeMarco, Yourdon, and Constantine after the emergence of the well-known
paradigm of modern structured programming. IBM was the first to incorporate Structured
Analysis and Structured Design (SA/SD) into its development cycle in the late 1970s and early
1980s.
In contrast, people modified the classical Structured Analysis and Structured Design (SA/SD)
due to their inability to represent real-time systems. In 1989, Yourdon came up with another
published version of the methodology with a graphical approach known as “Modern Structured
Analysis”.
The availability of CASE tools in the 1990s enabled many analysts to develop and modify the
graphical Structured Analysis and Structured Design (SA/SD) models. Using this model,
analysts attempted to divide a significant, complex problem into smaller, more easily handled
ones using a “Divide and Conquer”, “Top-Down approach” (Classical SA), or “Middle-Out”
(Modern SA).
Analysts used leverage graphics to illustrate their ideas whenever possible to depict a functional
view of the problem and maintain relevant written records.

Structured Analysis and Structured Design (SA/SD) is a top-down decomposition

technique system design methodology. In Software Engineering, SA/SD are methods used for
analyzing business requirements while developing specifications for converting practices into
computer programs, hardware configurations, and related manual procedures.
Structured Analysis is a set of techniques and graphical tools that allow the analyst to develop a
new system specification that is easily understandable to the user and a functional, high-quality
information system that meets their needs.
Structured Analysis and Structured Design (SA/SD) methodology consist of two significant
chunks of different activities, viz. :
 1. Structured Analysis (SA)
During which a functional decomposition takes place.
2. Structured Design (SD)
During which module structure is formalized.
Here, Functional decomposition is where each function is analyzed, hierarchically decomposed
into more detailed processes, and simultaneously decomposed from high-level data into more
complex data.
Structured Analysis is based on principles of the “Top-down decomposition” approach and the
“Divide and Conquer” principle, where each function is considered individually (i.e. isolated
from other parts). Here, too relatively, a decomposition of different functions occurs,
disregarding what happens in other processes (reducing their cohesiveness and increasing
independence).

Advantages of Structured Analysis and Structured Design (SA/SD)

Advantages of Structured Analysis and Structured Design (SA/SD):
1. Clarity and Understandability: SA/SD techniques offer clear and understandable
representations of system requirements and designs, aiding in communication among
stakeholders.
2. Modularity: SA/SD promotes modular design, which facilitates easier maintenance,
debugging, and enhancement of the system.
3. Ease of Testing: The structured approach enables systematic testing of individual
modules, improving the overall quality and reliability of the system.
4. Predictability: SA/SD provides a systematic way to analyze requirements and design
solutions, leading to predictable outcomes in terms of system behavior and performance.
5. Reuse: Modular design encourages reusable components, reducing development time and
effort for future projects.

Disadvantages of Structured Analysis and Structured Design (SA/SD)

Disadvantages of Structured Analysis and Structured Design (SA/SD):
1. Rigidity: SA/SD can become rigid and may not accommodate changes well, especially
when requirements evolve or new features need to be added.
2. Complexity Management: Large systems designed using SA/SD may become complex
and difficult to manage, leading to increased development time and cost.
3. Overhead: SA/SD requires significant upfront planning and documentation, which may
lead to increased project overhead, especially for small-scale projects.
4. Limited Scalability: SA/SD may not scale well for extremely large or complex systems,
as the modular approach may introduce performance bottlenecks or architectural
constraints.
5. Dependency Management: Dependencies between modules can create challenges
during integration and maintenance phases, requiring careful coordination and management.

Architectural Design
For the program to represent software design, architectural design is required. "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" is how the IEEE defines architectural
design. The following tasks are carried out by an architectural design. One of these numerous
architectural styles can be seen in software designed for computer-based systems.

Every style shall outline a system category made up of the following:

o A collection of parts (such as computing modules and databases) that together will carry
out a task that the system needs.
o The connector set will facilitate the parts' cooperation, coordination, and communication.
o Requirements that specify how parts can be combined to create a system.
o Semantic models aid in the designer's comprehension of the system's general
characteristics.
Software requirements should be converted into an architecture that specifies the components
and top-level organization of the program. This is achieved through architectural design, also
known as system design, which serves as a "blueprint" for software development. Architectural
design is "the process of defining a collection of hardware and software components and their
interfaces to establish the framework for developing a computer system," according to the IEEE
definition. The software requirements document is examined to create this framework, and a
methodology for supplying implementation details is designed. The system's constituent parts
and their inputs, outputs, functions, and interplay are described using these specifics.
1. It establishes an abstraction level where the designers can specify the system's functional
and performance behavior.
2. By outlining the aspects of the system that are easily modifiable without compromising
its integrity, it serves as a guide for improving the system as necessary.
3. It assesses every top-tier design.
4. It creates and records the high-level interface designs, both internal and external.
5. It creates draft copies of the documentation for users.
6. It outlines and records the software integration timetable and the initial test requirements.
7. The following is a list of the sources for architectural design.
8. Information on the software development project's application domain
9. Making use of data flow charts
10. The accessibility of architectural patterns and styles.

Architectural design is paramount in software engineering, where fundamental requirements like

dependability, cost, and performance are addressed. As the paradigm for software engineering
shifts away from monolithic, standalone, built-from-scratch systems and toward componentized,
evolvable, standards-based, and product line-oriented systems, this task is challenging. Knowing
precisely how to move from requirements to architectural design is another significant challenge
for designers. Designers use reusability, componentization, platform-based, standards-based, and
more to avoid these issues.
Even though developers are in charge of the architectural design, others like user representatives,
systems engineers, hardware engineers, and operations staff are also involved. All stakeholders
must be consulted when reviewing the architectural design to reduce risks and errors.

Components of Architectural Design

High-level organizational structures and connections between system components are established
during architectural design's crucial software engineering phase. It is the framework for the entire
software project and greatly impacts the system's effectiveness, maintainability, and quality. The
following are some essential components of software engineering's architectural design:
System Organization: The architectural design defines how the system will be organized into
various components or modules. This includes identifying the major subsystems, their
responsibilities, and how they interact.
Abstraction and Decomposition: Architectural design involves breaking down the system into
smaller, manageable parts. This decomposition simplifies the development process and makes
understanding and maintaining the system easier.
Design Patterns: Using design patterns, such as Singleton, Factory, or Model-View-Controller
(MVC), can help standardize and optimize the design process by providing proven solutions to
common architectural problems.
Architectural Styles: There are various architectural styles, such as layered architecture,
client-server architecture, microservices architecture, and more. Choosing the right style depends
on the specific requirements of the software project.
Data Management: Architectural design also addresses how data will be stored, retrieved, and
managed within the system. This includes selecting the appropriate database systems and
defining data access patterns.
Interaction and Communication: It is essential to plan how various parts or modules will talk
to and interact with one another. This includes specifying message formats, protocols, and APIs.
Scalability: The architectural plan should consider the system's capacity for expansion and
scalability. Without extensive reengineering, it ought to be able to handle increased workloads or
user demands.
Security: The architectural design should consider security factors like access control, data
encryption, and authentication mechanisms.
Optimization and performance: The architecture should be created to satisfy performance
specifications. This could entail choosing the appropriate technologies, optimizing algorithms,
and effectively using resources.
Concerns with Cross-Cutting: To ensure consistency throughout the system, cross-cutting
issues like logging, error handling, and auditing should be addressed as part of the architectural
design.
Extensibility and Flexibility: A good architectural plan should be adaptable and extensible to
make future changes and additions without seriously disrupting the existing structure.
Communication and Documentation: The development team and other stakeholders must have
access to clear documentation of the architectural design to comprehend the system's structure
and design choices.
Validation and Testing: Plans for how to test and validate the system's components and
interactions should be included in the architectural design.
Maintainability: Long-term maintenance of the design requires considering factors like code
organization, naming conventions, and modularity.
Cost factors to consider: The project budget and resource limitations should be considered
when designing the architecture.
The architectural design phase is crucial in software development because it establishes the
system's overall structure and impacts decisions made throughout the development lifecycle. A
software system that meets the needs of users and stakeholders can be more efficient, scalable,
and maintainable thanks to a well-thought-out architectural design. It also gives programmers a
foundation to build the system's code.
Properties of Architectural Design
Several significant traits and qualities of architectural design in software engineering are used to
direct the creation of efficient and maintainable software systems. A robust and scalable
architecture must have these characteristics. Some of the essential characteristics of architectural
design in software engineering are as follows:
Modularity: Architectural design encourages modularity by dividing the software system into
smaller, self-contained modules or components. Because each module has a clear purpose and
interface, modularity makes the system simpler to comprehend, develop, test, and maintain.
Scalability: Scalability should be supported by a well-designed architecture, enabling the system
to handle increased workloads and growth without extensive redesign. Techniques like load
balancing, distributed systems, and component replication can be used to achieve scalability.
Maintainability: A software system's architectural design aims to make it maintainable over
time. This entails structuring the system to support quick updates, improvements, and bug fixes.
Maintainability is facilitated by clear documentation and adherence to coding standards.
Flexibility: The flexibility of architectural design should allow for easy adaptation to shifting
needs. It should enable the addition or modification of features without impairing the
functionality of the current features. Design patterns and clearly defined interfaces are frequently
used to accomplish this.
Reliability: A strong architectural plan improves the software system's dependability. It should
reduce the likelihood of data loss, crashes, and system failures. Redundancy and error-handling
procedures can improve reliability.
Performance: A crucial aspect of architectural design is performance. It entails fine-tuning the
system to meet performance standards, including throughput, response time, and resource
utilization. Design choices like data storage methods and algorithm selection greatly influence
performance.
Security: Architectural design must take security seriously. The architecture should include
security measures such as access controls, encryption, authentication, and authorization to
safeguard the system from potential threats and vulnerabilities.
Distinguishing Concerns: By enforcing a clear separation of concerns, architectural design
ensures that various system components-such as the user interface, business logic, and data
storage-are arranged and managed independently. The separation makes maintenance, testing,
and development easier.
Interoperability: The system's ability to communicate with other systems or components should
be considered when designing the architecture. Interoperable software can be integrated with
other platforms or services, facilitating communication and teamwork.
Usability: The system's usability and user experience should be considered when making
architectural decisions. User interfaces and workflows must be designed to ensure users can
interact with the software effectively and efficiently.
Documentation: Architectural design that works is extensively documented. Developers and
other stakeholders can refer to the documentation, which explains the design choices,
components, and reasoning behind them. It improves understanding and communication.
Price-Performance: The architectural plan should take the project's resources and budget into
consideration. It entails choosing technologies, resources, and development initiatives wisely and
economically.
Validation and Testing: The architectural design should include plans for evaluating and
verifying the interactions and parts of the system. This guarantees that the system meets the
requirements and operates as intended.
Adherence to Standards: Consistency and interoperability with other systems and tools are
ensured in architectural design by adhering to industry and organizational standards and best
practices.
Evolutionary Support: The system's architecture should allow for future system evolution. This
entails adjusting for evolving business requirements, laws, and technology.
Together, these characteristics result in a software architecture that is reliable, maintainable, and
able to satisfy both functional and non-functional needs. Since it establishes the framework for
the entire software system, effective architectural design is an essential phase in the software
development process.

Advantages of Architectural Design

Structure and Clarity: The organization of the software system is represented in a clear and
organized manner by architectural design. It outlines the elements, their connections, and their
duties. This clarity makes it easier for developers to comprehend how various system
components work together and contribute to their functionality. Comprehending this concept is
essential for effective development and troubleshooting.
Modularity: In architectural design, modularity divides a system into more manageable,
independent modules or components. Because each module serves a distinct purpose, managing,
testing, and maintaining it is made simpler. Developers can work on individual modules
independently, improving teamwork and lessening the possibility of unexpected consequences
from changes.
Scalability: A system's scalability refers to its capacity to accommodate growing workloads and
expand over time. Thanks to an architectural design that supports scalability, the system can
accommodate more users, data, and transactions without requiring a major redesign. Systems
that must adjust to shifting user needs and business requirements must have this.
Maintenance and Expandability: The extensibility and maintenance of software are enhanced
by architectural design. Upgrades, feature additions, and bug fixes can be completed quickly and
effectively with an organized architecture. It lowers the possibility of introducing new problems
during maintenance, which can greatly benefit software systems that last a long time.
Performance Optimization: Performance optimization ensures the system meets parameters
like response times and resource usage. Architectural design allows choosing effective
algorithms, data storage plans, and other performance-boosting measures to create a responsive
and effective system.
Security: An essential component of architectural design is security. Access controls,
encryption, and authentication are a few security features that can be incorporated into the
architecture to protect sensitive data and fend off attacks and vulnerabilities. A secure system
starts with a well-designed architecture.
Reliability: When a system is reliable, it operates as planned and experiences no unplanned
malfunctions. By structuring the system to handle errors and recover gracefully from faults,
architectural design helps minimize failures. Moreover, it makes it possible to employ
fault-tolerant and redundancy techniques to raise system reliability.
Interoperability: The system's capacity to communicate with other systems or services is
known as interoperability. The ability of the system's components to communicate with other
systems via accepted protocols and data formats is guaranteed by a well-designed architecture.
This makes sharing data, integrating with other tools, and working with outside services easier.
Economic Efficiency: Making cost-effective decisions is aided by an architectural design that is
in line with the project's budget and resource limitations. It lowers the risk of budget overruns
and resource waste by ensuring that resources are used effectively and that the project is
financially viable.

Disadvantages of Architectural Design

Initial Time Investment: Developing a thorough architectural design can take a while,
particularly for complicated projects. The project may appear to be delayed during this phase as
developers and architects devote time to planning and making decisions. However, by offering a
clear roadmap, this initial investment can save time in later stages of development.
Over-Engineering: When features or complexity in the architectural design are redundant or
unnecessary for the project's objectives, it's known as over-engineering. When developers work
on components that add little value to the final product, this can result in longer development
times and higher development costs.
Rigidity: It can be difficult to adjust an architecture that is too rigid to new requirements or
technological advancements. The architecture may make it more difficult for the system to adapt
and change to meet changing business needs if it is overly rigid and does not permit changes.
Complexity: Comprehending and maintaining complex architectural designs can be challenging,
particularly for developers not part of the original design process. Because it is more difficult to
manage and troubleshoot, an excessively complex architecture may lead to inefficiencies and
increased maintenance costs.
Misalignment with Requirements: Occasionally, there may be a discrepancy between the
architectural plan and the actual project specifications, leading to needless complications or
inefficiencies. This misalignment may require additional labour and modifications to guarantee
the system achieves its objectives.
Resistance to Change: Even when required, significant changes may encounter resistance once
an architectural design is established. This might result from the money spent on the current
architecture or worries about possible project delays.
Resource Intensive: A complex architectural design may require specialized resources to
develop and maintain, such as architects, documentation efforts, and quality assurance. Project
costs and management overhead may arise due to these increased resource demands.
Communication Challenges: Interpreting architectural design documents can be difficult,
especially if they are unclear or not efficiently shared with all team members and stakeholders.
Deviations from the intended design may result from misunderstandings or misinterpretations.
Risk of Overlooked Issues: There's a chance that, in extremely complex architectural designs,
possible problems or challenges will be missed, resulting in unforeseen issues during
implementation. Later in the development process, these problems might appear, delaying things
and requiring more work.
Resource Intensive: A complex architectural design may require specialized resources to
develop and maintain, such as architects, documentation efforts, and quality assurance. Project
costs and management overhead may arise due to these increased resource demands.
Communication Challenges: Interpreting architectural design documents can be difficult,
especially if they are unclear or not efficiently shared with all team members and stakeholders.
Deviations from the intended design may result from misunderstandings or misinterpretations.
Risk of Overlooked Issues: There's a chance that, in extremely complex architectural designs,
possible problems or challenges will be missed, resulting in unforeseen issues during
implementation. Later in the development process, these problems might appear, delaying things
and requiring more work.
These drawbacks can be lessened with cautious planning, clear communication, and harmony
between the demands of the project and design rigour. The aim is to create an architectural
design that fulfills the project's needs without adding needless rigidity or complexity.

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

UI Design Stages
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. The
analysis of the user environment focuses on the physical work environment. Among the
questions to be asked are:
Where will the interface be located physically?
Will the user be sitting, standing, or performing other tasks unrelated to the interface?
Does the interface hardware accommodate space, light, or noise constraints?
Are there special human factors considerations driven by environmental factors?

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. Always
follow the three golden rules stated by Theo Mandel. Design issues such as response time,
command and action structure, error handling, and help facilities are considered as the design
model is refined. This phase serves as the foundation for the implementation phase.

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.

Reduce the User’s Memory Load

Reduce demand on short-term memory: When users are involved in some complex tasks the
demand on short-term memory is significant. So the interface should be designed in such a way
to reduce the remembering of previously done actions, given inputs and results.
Establish meaningful defaults: Always an initial set of defaults should be provided to the
average user, if a user needs to add some new features then he should be able to add the
required features.
Define shortcuts that are intuitive: Mnemonics should be used by the user. Mnemonics
means the keyboard shortcuts to do some action on the screen.
The visual layout of the interface should be based on a real-world metaphor: Anything
you represent on a screen if it is a metaphor for a real-world entity then users would easily
understand.
Disclose information in a progressive fashion: The interface should be organized
hierarchically i.e., on the main screen the information about the task, an object or some
behavior should be presented first at a high level of abstraction. More detail should be
presented after the user indicates interest with a mouse pick.

Make the Interface Consistent

Allow the user to put the current task into a meaningful context: Many interfaces have
dozens of screens. So it is important to provide indicators consistently so that the user know
about the doing work. The user should also know from which page has navigated to the current
page and from the current page where it can navigate.
Maintain consistency across a family of applications: in The development of some set of
applications all should follow and implement the same design, rules so that consistency is
maintained among applications.
If past interactive models have created user expectations do not make changes unless there is a
compelling reason.
User interface design is a crucial aspect of software engineering, as it is the means by which
users interact with software applications. A well-designed user interface can improve the
usability and user experience of an application, making it easier to use and more effective.

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.

Component Level design

Component-level design is a critical phase in software engineering where individual components
of the system are defined and designed. These components are the building blocks of a software
system, each responsible for a specific functionality.

Component-Level Design

1. Component Identification: Identify the components needed for the system based on the
architectural design. Components can be classes, objects, functions, or a combination of these.

2. Interface Design: Define the interfaces for each component, specifying how they interact
with other components. This includes method signatures, input/output parameters, and any
events or messages exchanged.

3. Detailed Design: Provide detailed descriptions of the internal workings of each component.
Include algorithms, data structures, and any internal processing details.

4. Design for Reusability: Design components to be reusable across different parts of the
application or in future projects. Use design patterns and principles such as modularity, low
coupling, and high cohesion.

5. Design for Maintainability: Ensure the design facilitates easy maintenance and updates. Use
clear, consistent naming conventions and comprehensive documentation.

6. Error Handling and Security: Incorporate error handling mechanisms and security measures
within components. Ensure components are robust and can handle unexpected inputs gracefully.
Steps in Component-Level Design
1. Decompose the System: Break down the system into smaller, manageable components based
on the system's requirements and architecture.

2. Define Component Interfaces: Specify the interfaces for each component, including public
methods, properties, and events.

3. Design Component Logic: Detail the internal logic of each component, including control
flow and data manipulation.

4. Document the Design: Create comprehensive documentation for each component, detailing
its purpose, interfaces, and internal logic.

5. Review and Refine: Conduct design reviews to identify potential issues and areas for
improvement. Refine the design based on feedback and testing results.

Component-Level Design Principles

Single Responsibility Principle (SRP): Each component should have a single responsibility or
function.
Open/Closed Principle (OCP): Components should be open for extension but closed for
modification.
Liskov Substitution Principle (LSP): Derived classes should be substitutable for their base
classes.
Interface Segregation Principle (ISP): Components should not be forced to depend on
interfaces they do not use.
Dependency Inversion Principle (DIP): Depend on abstractions, not on concrete
implementations.

Benefits of Component-Level Design

Improved Modularity: Components can be developed, tested, and maintained independently.

Enhanced Reusability: Well-designed components can be reused in different projects, reducing
development time and effort.
Ease of Maintenance: Isolated components are easier to update and debug.
Better Collaboration: Clear component boundaries facilitate parallel development by different
team members.

Software Reuse and Software Maintenance issues

Software Reuse
Software reuse is the process of using existing software assets in the development of new
software. These assets can include code, designs, architectures, documentation, and other
artifacts. The main goal of software reuse is to increase productivity, improve quality, and reduce
costs by leveraging existing resources.
Types of Software Reuse
1. Code Reuse: Reusing existing code libraries, modules, or components. Commonly facilitated
through repositories and package managers.

2. Design Reuse: Reusing design patterns, templates, and frameworks. Helps maintain
consistency and standardization across projects.

3. Architecture Reuse: Reusing software architectures and frameworks. Provides a solid

foundation for new projects, ensuring reliability and performance.

4. Documentation Reuse: Reusing user manuals, API documentation, and other forms of
documentation. Saves time and ensures consistency in how information is communicated.

Benefits of Software Reuse

Increased Productivity: Developers can focus on new features and improvements rather than
reinventing the wheel.

Improved Quality: Reused components are often well-tested and proven in previous projects,
reducing the likelihood of defects.

Reduced Costs: Saves development time and resources, leading to lower overall project costs.

Faster Time-to-Market: Accelerates development cycles by reusing existing solutions.

Challenges of Software Reuse

Finding Reusable Components: Identifying suitable and reliable components for reuse can be
difficult.

Integration Issues: Integrating reused components with new systems can present compatibility
and dependency challenges.

Maintenance of Reused Components: Ensuring that reused components are updated and
maintained properly can be resource-intensive.

Intellectual Property Concerns: Ensuring legal compliance and respecting intellectual property
rights when reusing software assets.

Software Maintenance
Software maintenance involves modifying and updating software after its initial deployment.
This is necessary to correct faults, improve performance, or adapt the software to a changed
environment.

Types of Software Maintenance

1. Corrective Maintenance: Fixing bugs and errors that are discovered after the software is
released. Essential for maintaining software reliability and user satisfaction.
2. Adaptive Maintenance: Modifying software to work in a new or changed environment (e.g.,
hardware upgrades, OS changes). Ensures the software remains functional as the environment
evolves.

3. Perfective Maintenance: Enhancing software to improve performance or add new features

based on user feedback. Helps keep the software competitive and relevant.

4. Preventive Maintenance: Making changes to prevent future problems or to improve

maintainability. Prolongs the software’s life and reduces the need for more extensive corrective
maintenance later.

Issues in Software Maintenance

Complexity: Understanding and modifying existing code can be challenging, especially if it is
poorly documented or designed.

Regression Testing: Ensuring that changes do not introduce new bugs requires extensive
testing, which can be time-consuming and costly.

Documentation: Maintaining up-to-date documentation is essential but often neglected, leading

to difficulties in future maintenance efforts.

Cost: Maintenance can be costly, often consuming more resources than initial development.
Balancing maintenance costs with the need for new development is a common challenge.

Dependency Management: Managing dependencies between software components and external

libraries can be complex, especially as software evolves.

Technical Debt: Accumulating quick fixes and shortcuts can lead to technical debt, making
future maintenance harder and more expensive.
Skill Requirements: Maintenance requires a deep understanding of the existing system, which
means that skilled and experienced developers are essential.

Best Practices for Effective Software Maintenance

Modular Design: Designing software in a modular way makes it easier to isolate and fix issues.

Comprehensive Documentation: Keeping documentation up to date helps new developers

understand and maintain the software.

Automated Testing: Implementing automated regression tests ensures that changes do not
introduce new issues.

Version Control: Using version control systems to manage changes helps track modifications
and collaborate effectively.

Refactoring: Regularly refactoring code to improve its structure and readability reduces
maintenance complexity.
Code Reviews: Conducting code reviews helps catch potential issues early and ensures
adherence to coding standards.

Conclusion of the Unit

Software design is a critical phase in software development, focusing on defining the
architecture, components, interfaces, and other characteristics of a system. It transforms
requirements into a blueprint for construction, ensuring functionality, performance, and
maintainability. Effective software design considers both high-level architecture and detailed
component specifications. It balances trade-offs between different design aspects such as
modularity, scalability, and usability. Ultimately, a well-crafted software design serves as a
foundation for successful implementation and future evolution of the system, facilitating clear
communication among stakeholders and guiding developers through systematic and coherent
construction processes.