Software Design

Software design is a mechanism to transform user requirements into some suitable form, which helps the
programmer in software coding and implementation. It deals with representing the client's requirement, as
described in SRS (Software Requirement Specification) document, into a form, i.e., easily implementable
using programming language.

The software design phase is the first step in SDLC (Software Design Life Cycle), which moves the
concentration from the problem domain to the solution domain. In software design, we consider the
system to be a set of components or modules with clearly defined behaviors & boundaries.

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.

Software Design Principles

Software design principles are concerned with providing means to handle the complexity of the
design process effectively. Effectively managing the complexity will not only reduce the effort
needed for design but can also reduce the scope of introducing errors during design.

Following are the principles of Software Design

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

For software design, the goal is to divide the problem into manageable pieces.
Benefits of Problem Partitioning

1. Software is easy to understand

2. Software becomes simple

3. Software is easy to test

4. Software is easy to modify

5. Software is easy to maintain

6. Software is easy to expand

These pieces cannot be entirely independent of each other as they together form the system. They have to
cooperate and communicate to solve the problem. This communication adds complexity.

Abstraction

An abstraction is a tool that enables a designer to consider a component at an abstract level without
bothering about the internal details of the implementation. Abstraction can be used for existing element as
well as the component being designed.

Here, there are two common abstraction mechanisms

1. Functional Abstraction

2. Data Abstraction

Functional Abstraction

i. A module is specified by the method it performs.

ii. The details of the algorithm to accomplish the functions are not visible to the user of the function.

Functional abstraction forms the basis for Function oriented design approaches.

Data Abstraction

Details of the data elements are not visible to the users of data. Data Abstraction forms the basis
for Object Oriented design approaches.

Modularity
Modularity specifies to the division of software into separate modules which are differently named and
addressed and are integrated later on in to obtain the completely functional software. It is the only
property that allows a program to be intellectually manageable. Single large programs are difficult to
understand and read due to a large number of reference variables, control paths, global variables, etc.

The desirable properties of a modular system are:

o Each module is a well-defined system that can be used with other applications.

o Each module has single specified objectives.

o Modules can be separately compiled and saved in the library.

o Modules should be easier to use than to build.

o Modules are simpler from outside than inside.

Advantages and Disadvantages of Modularity

In this topic, we will discuss various advantage and disadvantage of Modularity.

Advantages of Modularity

There are several advantages of Modularity

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

o It encourages the creation of commonly used routines to be placed in the library and used by other
programs.

o It simplifies the overlay procedure of loading a large program into main storage.

o It provides more checkpoints to measure progress.

o It provides a framework for complete testing, more accessible to test

o It produced the well designed and more readable program.

Disadvantages of Modularity

There are several disadvantages of Modularity

o Execution time maybe, but not certainly, longer

o Storage size perhaps, but is not certainly, increased

o Compilation and loading time may be longer

 o Inter-module communication problems may be increased

o More linkage required, run-time may be longer, more source lines must be written, and more
documentation has to be done

Modular Design

Modular design reduces the design complexity and results in easier and faster implementation by allowing
parallel development of various parts of a system. We discuss a different section of modular design in
detail in this section:

1. Functional Independence: Functional independence is achieved by developing functions that perform

only one kind of task and do not excessively interact with other modules. Independence is important
because it makes implementation more accessible and faster. The independent modules are easier to
maintain, test, and reduce error propagation and can be reused in other programs as well. Thus, functional
independence is a good design feature which ensures software quality.

It is measured using two criteria:

o Cohesion: It measures the relative function strength of a module.

o Coupling: It measures the relative interdependence among modules.

3. Information hiding: The fundamental of Information hiding suggests that modules can be
characterized by the design decisions that protect from the others, i.e., In other words, modules
should be specified that data include within a module is inaccessible to other modules that do not
need for such information.

The use of information hiding as design criteria for modular system provides the most significant
benefits when modifications are required during testing's and later during software maintenance.
This is because as most data and procedures are hidden from other parts of the software,
inadvertent errors introduced during modifications are less likely to propagate to different
locations within the software.

Strategy of Design
A good system design strategy is to organize the program modules in such a method that are easy
to develop and latter too, change. Structured design methods help developers to deal with the size
and complexity of programs. Analysts generate instructions for the developers about how code
should be composed and how pieces of code should fit together to form a program.
To design a system, there are two possible approaches:
1. Top-down Approach
2. Bottom-up Approach
 1. Top-down Approach: This approach starts with the identification of the main components and
then decomposing them into their more detailed sub-components.

2. Bottom-up Approach: A bottom-up approach begins with the lower details and moves towards
up the hierarchy, as shown in fig. This approach is suitable in case of an existing system.

Coupling and Cohesion

Module Coupling

In software engineering, the coupling is the degree of interdependence between software modules. Two modules
that are tightly coupled are strongly dependent on each other. However, two modules that are loosely coupled
are not dependent on each other. Uncoupled modules have no interdependence at all within them.

The various types of coupling techniques are shown in fig:

A good design is the one that has low coupling. Coupling is measured by the number of relations between the
modules. That is, the coupling increases as the number of calls between modules increase or the amount of
shared data is large. Thus, it can be said that a design with high coupling will have more errors.

Types of Module Coupling

1. No Direct Coupling: There is no direct coupling between M1 and M2.

In this case, modules are subordinates to different modules. Therefore, no direct coupling.

2. Data Coupling: When data of one module is passed to another module, this is called data coupling.

3. Stamp Coupling: Two modules are stamp coupled if they communicate using composite data items such as
structure, objects, etc. When the module passes non-global data structure or entire structure to another module,
they are said to be stamp coupled. For example, passing structure variable in C or object in C++ language to a
module.

4. Control Coupling: Control Coupling exists among two modules if data from one module is used to direct the
structure of instruction execution in another.

5. External Coupling: External Coupling arises when two modules share an externally imposed data format,
communication protocols, or device interface. This is related to communication to external tools and devices.

6. Common Coupling: Two modules are common coupled if they share information through some global data
items.
7. Content Coupling: Content Coupling exists among two modules if they share code, e.g., a branch from one
module into another module.

Module Cohesion

In computer programming, cohesion defines to the degree to which the elements of a module belong together.
Thus, cohesion measures the strength of relationships between pieces of functionality within a given module. For
example, in highly cohesive systems, functionality is strongly related.

Cohesion is an ordinal type of measurement and is generally described as "high cohesion" or "low cohesion."
Types of Modules Cohesion

1. Functional Cohesion: Functional Cohesion is said to exist if the different elements of a module, cooperate
to achieve a single function.

2. Sequential Cohesion: A module is said to possess sequential cohesion if the element of a module form the
components of the sequence, where the output from one component of the sequence is input to the
next.
0
00

3. Communicational Cohesion: A module is said to have communicational cohesion, if all tasks of the
module refer to or update the same data structure, e.g., the set of functions defined on an array or a
stack.

4. Procedural Cohesion: A module is said to be procedural cohesion if the set of purpose of the module are
all parts of a procedure in which particular sequence of steps has to be carried out for achieving a goal,
e.g., the algorithm for decoding a message.
 5. Temporal Cohesion: When a module includes functions that are associated by the fact that all the
methods must be executed in the same time, the module is said to exhibit temporal cohesion.

6. Logical Cohesion: A module is said to be logically cohesive if all the elements of the module perform a
similar operation. For example Error handling, data input and data output, etc.

7. Coincidental Cohesion: A module is said to have coincidental cohesion if it performs a set of tasks that are
associated with each other very loosely, if at all.

Differentiate between Coupling and Cohesion

Coupling Cohesion

Coupling is also called Inter-Module Binding. Cohesion is also called Intra-Module Binding.

Coupling shows the relationships between modules. Cohesion shows the relationship within the
module.

Coupling shows the relative independence between Cohesion shows the module's
the modules. relative functional strength.

While creating, you should aim for low coupling, While creating you should aim for high
i.e., dependency among modules should be less. cohesion, i.e., a cohesive component/ module
focuses on a single function (i.e., single-
mindedness) with little interaction with other
modules of the system.

In coupling, modules are linked to the other In cohesion, the module focuses on a single
modules. thing.

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

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 Engineering | Architectural Design

Introduction: The software needs the architectural design to represents the design of
software. IEEE defines architectural design as “the process of defining a collection of
hardware and software components and their interfaces to establish the framework for the
development of a computer system.” The software that is built for computer-based systems
can exhibit one of these many architectural styles.
Each style will describe a system category that consists of :

 A set of components(eg: a database, computational modules) that will perform a

function required by the system.

 The set of connectors will help in coordination, communication, and cooperation

between the components.
  Conditions that how components can be integrated to form the system.

 Semantic models that help the designer to understand the overall properties of the
system.

The use of architectural styles is to establish a structure for all the components of the
system.

Taxonomy of Architectural styles:

1] Data centered architectures:

 A data store will reside at the center of this architecture and is accessed frequently
by the other components that update, add, delete or modify the data present within
the store.

 The figure illustrates a typical data centered style. The client software access a
central repository. Variation of this approach are used to transform the repository
into a blackboard when data related to client or data of interest for the client change
the notifications to client software.

 This data-centered architecture will promote integrability. This means that the
existing components can be changed and new client components can be added to the
architecture without the permission or concern of other clients.

 Data can be passed among clients using blackboard mechanism.

Advantage of Data centered architecture

 Repository of data is independent of clients

 Client work independent of each other

 It may be simple to add additional clients.

 Modification can be very easy

Data centered architecture

2] Data flow architectures:

 This kind of architecture is used when input data is transformed into output data
through a series of computational manipulative components.

 The figure represents pipe-and-filter architecture since it uses both pipe and filter
and it has a set of components called filters connected by lines.

 Pipes are used to transmitting data from one component to the next.

 Each filter will work independently and is designed to take data input of a certain
form and produces data output to the next filter of a specified form. The filters don’t
require any knowledge of the working of neighboring filters.

 If the data flow degenerates into a single line of transforms, then it is termed as
batch sequential. This structure accepts the batch of data and then applies a series of
sequential components to transform it.

Advantages of Data Flow architecture

 It encourages upkeep, repurposing, and modification.

 With this design, concurrent execution is supported.

The disadvantage of Data Flow architecture

 It frequently degenerates to batch sequential system

 Data flow architecture does not allow applications that require greater user
engagement.
  It is not easy to coordinate two different but related streams

Data Flow architecture

3] Call and Return architectures: It is used to create a program that is easy to scale
and modify. Many sub-styles exist within this category. Two of them are explained below.

 Remote procedure call architecture: This components is used to present in a main

program or sub program architecture distributed among multiple computers on a
network.

 Main program or Subprogram architectures: The main program structure

decomposes into number of subprograms or function into a control hierarchy. Main
program contains number of subprograms that can invoke other components.
 4] Object Oriented architecture: The components of a system encapsulate data and
the operations that must be applied to manipulate the data. The coordination and
communication between the components are established via the message passing.

Characteristics of Object Oriented architecture

 Object protect the system’s integrity.

 An object is unaware of the depiction of other items.

Advantage of Object Oriented architecture

 It enables the designer to separate a challenge into a collection of autonomous

objects.

 Other objects are aware of the implementation details of the object, allowing
changes to be made without having an impact on other objects.

5] Layered architecture:

 A number of different layers are defined with each layer performing a well-defined
set of operations. Each layer will do some operations that becomes closer to
machine instruction set progressively.

 At the outer layer, components will receive the user interface operations and at the
inner layers, components will perform the operating system
interfacing(communication and coordination with OS)

 Intermediate layers to utility services and application software functions.

 One common example of this architectural style is OSI-ISO (Open Systems

Interconnection-International Organisation for Standardisation) communication
system.
Layered architecture:

Structured Analysis and Structured Design

Structured Analysis and Structured Design (SA/SD) is a diagrammatic notation that is

designed to help people understand the system. The basic goal of SA/SD is to improve
quality and reduce the risk of system failure. It establishes concrete management
specifications and documentation. It focuses on the solidity, pliability, and maintainability
of the system.

Structured Analysis and Structured Design (SA/SD) is a software development method

that was popular in the 1970s and 1980s. The method is based on the principle of
structured programming, which emphasizes the importance of breaking down a software
system into smaller, more manageable components.

In SA/SD, the software development process is divided into two phases: Structured
Analysis and Structured Design. During the Structured Analysis phase, the problem to be
solved is analyzed and the requirements are gathered. The Structured Design phase
involves designing the system to meet the requirements that were gathered in the
Structured Analysis phase.

Structured Analysis and Structured Design (SA/SD) is a traditional software development

methodology that was popular in the 1980s and 1990s. It involves a series of techniques
for designing and developing software systems in a structured and systematic way. Here
are some key concepts of SA/SD:

1. Functional Decomposition: SA/SD uses functional decomposition to break down a

complex system into smaller, more manageable subsystems. This technique involves
identifying the main functions of the system and breaking them down into smaller
functions that can be implemented independently.

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

3. Data Dictionary: A data dictionary is a central repository that contains descriptions

of all the data elements used in the system. It provides a clear and consistent
definition of data elements, making it easier to understand how the system works.

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

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

down the system’s code into smaller, more manageable modules. This makes it
easier to develop, test, and maintain the system.

Some advantages of SA/SD include its emphasis on structured design and documentation,
which can help improve the clarity and maintainability of the system. However, SA/SD
has some disadvantages, including its rigidity and inflexibility, which can make it difficult
to adapt to changing business requirements or technological trends. Additionally, SA/SD
may not be well-suited for complex, dynamic systems, which may require more agile
development methodologies.

The following are the steps involved in the SA/SD process:

1. Requirements gathering: The first step in the SA/SD process is to gather

requirements from stakeholders, including users, customers, and business partners.
 2. Structured Analysis: During the Structured Analysis phase, the requirements are
analyzed to identify the major components of the system, the relationships between
those components, and the data flows within the system.

3. Data Modeling: During this phase, a data model is created to represent the data used
in the system and the relationships between data elements.

4. Process Modeling: During this phase, the processes within the system are modeled
using flowcharts and data flow diagrams.

5. Input/Output Design: During this phase, the inputs and outputs of the system are
designed, including the user interface and reports.

6. Structured Design: During the Structured Design phase, the system is designed to
meet the requirements gathered in the Structured Analysis phase. This may include
selecting appropriate hardware and software platforms, designing databases, and
defining data structures.

7. Implementation and Testing: Once the design is complete, the system is

implemented and tested.

SA/SD has been largely replaced by more modern software development methodologies,
but its principles of structured analysis and design continue to influence current software
development practices. The method is known for its focus on breaking down complex
systems into smaller components, which makes it easier to understand and manage the
system as a whole.

Basically, the approach of SA/SD is based on the Data Flow Diagram. It is easy to
understand SA/SD but it focuses on well-defined system boundary whereas the JSD
approach is too complex and does not have any graphical representation.

SA/SD is combined known as SAD and it mainly focuses on the following 3 points:

1. System

2. Process

3. Technology

SA/SD involves 2 phases:

 1. Analysis Phase: It uses Data Flow Diagram, Data Dictionary, State Transition
diagram and ER diagram.

2. Design Phase: It uses Structure Chart and Pseudo Code.

1. Analysis Phase:

Analysis Phase involves data flow diagram, data dictionary, state transition diagram, and
entity-relationship diagram.

1. Data Flow Diagram:

In the data flow diagram, the model describes how the data flows through the
system. We can incorporate the Boolean operators and & or link data flow when
more than one data flow may be input or output from a process.

For example, if we have to choose between two paths of a process we can add an operator
or and if two data flows are necessary for a process we can add an operator. The input of
the process “check-order” needs the credit information and order information whereas the
output of the process would be a cash-order or a good-credit-order.

2. Data Dictionary:
The content that is not described in the DFD is described in the data dictionary. It
defines the data store and relevant meaning. A physical data dictionary for data
elements that flow between processes, between entities, and between processes and
entities may be included. This would also include descriptions of data elements that
flow external to the data stores.

A logical data dictionary may also be included for each such data element. All system
names, whether they are names of entities, types, relations, attributes, or services, should
be entered in the dictionary.

3. State Transition Diagram:

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 events. It also
describes all of the states that an object can have, the events under which an object
 changes state, the conditions that must be fulfilled before the transition will occur
and the activities were undertaken during the life of an object.

4. ER Diagram:
ER diagram specifies the relationship between data store. It is basically used in
database design. It basically describes the relationship between different entities.

2. Design Phase:

Design Phase involves structure chart and pseudocode.

1. Structure Chart:
It is created by the data flow diagram. Structure Chart specifies how DFS’s
processes are grouped into tasks and allocated to the CPU. The structured chart does
not show the working and internal structure of the processes or modules and does
not show the relationship between data or data flows. Similar to other SASD tools, it
is time and cost-independent and there is no error-checking technique associated
with this tool. The modules of a structured chart are arranged arbitrarily and any
process from a DFD can be chosen as the central transform depending on the
analysts’ own perception. The structured chart is difficult to amend, verify,
maintain, and check for completeness and consistency.

2. Pseudo Code: It is the actual implementation of the system. It is an informal way of

programming that doesn’t require any specific programming language or
technology.

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

1. Clarity and Simplicity: The SA/SD method emphasizes breaking down complex
systems into smaller, more manageable components, which makes the system easier
to understand and manage.

2. Better Communication: The SA/SD method provides a common language and

framework for communicating the design of a system, which can improve
communication between stakeholders and help ensure that the system meets their
needs and expectations.
 3. Improved maintainability: The SA/SD method provides a clear, organized structure
for a system, which can make it easier to maintain and update the system over time.

4. Better Testability: The SA/SD method provides a clear definition of the inputs and
outputs of a system, which makes it easier to test the system and ensure that it meets
its requirements.

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

1. Time-Consuming: The SA/SD method can be time-consuming, especially for large

and complex systems, as it requires a significant amount of documentation and
analysis.

2. Inflexibility: Once a system has been designed using the SA/SD method, it can be
difficult to make changes to the design, as the process is highly structured and
documentation-intensive.

3. Limited Iteration: The SA/SD method is not well-suited for iterative development,
as it is designed to be completed in a single pass.