UNIT 4

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

Functional Abstraction
Data Abstraction

Functional Abstraction

A module is specified by the method it performs.

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

Functional abstraction forms the basis for Function oriented design approaches.
Data Abstraction

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

Modularity

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

The desirable properties of a modular system are:

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

Advantages of Modularity

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

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

Disadvantages of Modularity

Execution time maybe, but not certainly, longer

Storage size perhaps, but is not certainly, increased
Compilation and loading time may be longer
Inter-module communication problems may be increased
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.
It is measured using two criteria:
Cohesion: It measures the relative function strength of a module.
Coupling: It measures the relative interdependence among modules.

2. Information hiding: The fundamental of Information hiding suggests that modules

can be characterized by the design decisions that protect from the others, i.e., In other
words, modules should be specified that data include within a module is inaccessible
to other modules that do not need for such information.
The use of information hiding as design criteria for modular system provides the most
significant benefits when modifications are required during testing's and later during
software maintenance. This is because as most data and procedures are hidden from
other parts of the software, inadvertent errors introduced during modifications are less
likely to propagate to different locations within the software.

Strategy of Design
A good system design strategy is to organize the program modules in such a method
that are easy to develop and latter too, change. Structured design methods help
developers to deal with the size and complexity of programs. Analysts generate
instructions for the developers about how code should be composed and how pieces
of code should fit together to form a program.

To design a system, there are two possible approaches:

1. Top-down Approach
2. Bottom-up Approach
 1. Top-down Approach: This approach starts with the identification of the main
components and then decomposing them into their more detailed sub-components.

2. Bottom-up Approach: A bottom-up approach begins with the lower details and
moves towards up the hierarchy, 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.
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.
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.
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 Cohesion is also called Intra-Module Binding.
Binding.
Coupling shows the relationships Cohesion shows the relationship within the module.
between modules.
Coupling shows the Cohesion shows the module's
relative independence between the relative functional strength.
modules.
While creating, you should aim for low While creating you should aim for high cohesion,
coupling, i.e., dependency among i.e., a cohesive component/ module focuses on a
modules should be less. single function (i.e., single-mindedness) with little
interaction with other modules of the system.
In coupling, modules are linked to the In cohesion, the module focuses on a single thing.
other modules.
Architectural Design:-
Requirements of the software should be transformed into an architecture that describes the
-level structure and identifies its components. This is accomplished through
architectural design (also called system design), which acts as a prelimin

defining a collection of hardware and software components and their interfaces to establish
This framework is established by
examining the software requirements document and designing a model for providing
implementation details. These details are used to specify the components of the system along
with their inputs, outputs, functions, and the interaction between them.

1. It defines an abstraction level at which the designers can specify the functional and
performance behaviour of the system.

2. It acts as a guideline for enhancing the system (when ever required) by describing those
features of the system that can be modified easily without affecting the system integrity.

3. It evaluates all top-level designs.

4. It develops and documents top-level design for the external and internal interfaces.

5. It develops preliminary versions of user documentation.

6. It defines and documents preliminary test requirements and the schedule for software
integration.

7. The sources of architectural design are listed below.

8. Information regarding the application domain for the software to be developed

9. Using data-flow diagrams

10. Availability of architectural patterns and architectural styles.

Architectural design is of crucial importance in software engineering during which the

essential requirements like reliability, cost, and performance are dealt with. This task is
cumbersome as the software engineering paradigm is shifting from monolithic, stand-alone,
built-from-scratch systems to componentized, evolvable, standards-based, and product line-
oriented systems. Also, a key challenge for designers is to know precisely how to proceed
from requirements to architectural design. To avoid these problems, designers adopt strategies
such as reusability, componentization, platform-based, standards-based, and so on.

Though the architectural design is the responsibility of developers, some other people like
user representatives, systems engineers, hardware engineers, and operations personnel are
also involved.

Architectural Design Representation:-

Architectural design can be represented using the following models.

Structural model: Illustrates architecture as an ordered collection of program components

Dynamic model: Specifies the behavioral aspect of the software architecture and indicates
how the structure or system configuration changes as the function changes due to change in
the external environment

Process model: Focuses on the design of the business or technical process, which must be
implemented in the system

Functional model: Represents the functional hierarchy of a system

Framework model: Attempts to identify repeatable architectural design patterns encountered

in similar types of application. This leads to an increase in the level of abstraction.

Architectural Design Output:-

The architectural design process results in an Architectural Design Document (ADD). This
document consists of a number of graphical representations thatcomprises software models
along with associated descriptive text. The softwaremodels include static model, interface
model, relationship model, and dynamic processmodel. They show how the system is
organized into a process at run-time.

Architectural design document gives the developers a solution to the problem stated in the
Software Requirements Specification (SRS). Note that it considers only those requirements in
detail that affect the program structure. In addition to ADD, other outputs of the architectural
design are listed below.
 Various reports including audit report, progress report, and configuration status
accounts report
Various plans for detailed design phase, which include the following
Software verification and validation plan
Software configuration management plan
Software quality assurance plan
Software project management plan.

Architectural Styles:-

Architectural styles define a group of interlinked systems that share structural and semantic
properties. In short, the objective of using architectural styles is to establish a structure for all
the components present in a system. If an existing architecture is to be re-engineered, then
imposition of an architectural style results in fundamental changes in the structure of the
system.

By applying certain constraints on the design space, we can make different style-specific
analysis from an architectural style. In addition, if conventional structures are used for an
architectural style, the other stakeholders can easily understand the organization of the
system.

A computer-based system (software is part of this system) exhibits one of the many available
architectural styles. Every architectural style describes a system category that includes the
following.

Computational components such as clients, server, filter, and database to execute the
desired system function
A set of connectors such as procedure call, events broadcast, database protocols, and
pipes to provide communication among the computational components
Constraints to define integration of components to form a system
A semantic model, which enable the software designer to identify the characteristics
of the system as a whole by studying the characteristics of its components.
Advantages of Architectural Design in Software Engineering:-

Architectural design works as a tool for stakeholder communication. It is used as a

support or roadmap in the discussion with system stakeholders
It is used for system analysis. Architectural design is used to analyze whether the
system will be able to meet its non-functional requirements or not.
It facilitates large-scale re-use. The software architecture that is the output of the
architectural design process can be reused across a range of the system.

Disadvantages of Architectural Design in Software Engineering:-

Architectural design re-use the components, the use of redundant components

improves the availability but makes the security of the system difficult to handle.
Use of large components may improve the performance as large components include
all the related properties and function into one component but it reduces the
maintainability as it becomes difficult to modify and replace the large component. It
involves a very tiresome task.
Avoiding critical features inside the small components leads to more communication
among the components which in turn degrades the performance.

Architectural design decisions:-

Architectural design is a creative process so the process differs depending on the type of
system being developed. However, a number of common decisions span all design processes
and these decisions affect the non-functional characteristics of the system:

Is there a generic application architecture that can be used?

How will the system be distributed?
What architectural styles are appropriate?
What approach will be used to structure the system?
How will the system be decomposed into modules?
What control strategy should be used?
How will the architectural design be evaluated?
How should the architecture be documented?

Systems in the same domain often have similar architectures that reflect domain concepts.
Application product lines are built around a core architecture with variants that satisfy
particular customer requirements. The architecture of a system may be designed around one
of more architectural patterns/styles, which capture the essence of an architecture and can be
instantiated in different ways.

The particular architectural style should depend on the non-functional system requirements:

Performance: localize critical operations and minimize communications. Use large

rather than fine-grain components.
Security: use a layered architecture with critical assets in the inner layers.
Safety: localize safety-critical features in a small number of sub-systems.
Availability: include redundant components and mechanisms for fault tolerance.
Maintainability: use fine-grain, replaceable components.

Procedural Design:-

Procedural design is used to model programs that have an obvious flow of data from
input to output.
It represents the architecture of a program as a set of interacting processes that pass
data from one to another.
Procedural design is also called component design. It is completely based on process
and control specifications.

component design.
Component design is usually done after user interface design.
The component-level design depicts the software at a level of abstraction that is very
close to the code.
At the component level, the software engineer must represent data structures,
interfaces, and algorithms in sufficient detail to guide the generation of programming
language source code.

The step occurs after the data and program structures have been established, i.e. after
architectural design. Procedural details can be represented in different ways:

1. Graphical Design Notation: The most widely used notation is the flowchart. Some
notation used in flowcharts are

(i) Boxes to indicate processing steps.

(ii) Diamond to indicate logical condition.

(iii) Arrows to indicate flow of control.

(iv) Two boxes connected by a line of control will indicate a Sequence.

2. Tabular Design Notation: (i) Decision tables provide a notation that translates actions and
conditions (described a processing narrative) into a tabular form.

(ii) The upper left-hard section contains a list of all conditions. The lower left-hand section
lists all actions that are possible based on the conditions. The right-hand sections form a
matrix that indicates condition combinations and the corresponding actions that will occur for
a specific combination.
3. Program Design Language: It is a method designing and documenting methods and
procedures in software. It is related to pseudocode, but unlike pseudocode, it is written in
plain language without any terms that could suggest the use of any programming language or
library.
Design Documentation :-
The design phase of software development deals with transforming the customer
requirements as described in the SRS documents into a form implementable using a
programming language. The software design process can be divided into the following three
levels of phases design:

Interface Design
Architectural Design
Detailed Design

Software Design Document:

Software Design Document is a written document that provides a description of a software
product in terms of architecture of software with various components with specified
functionality.
The design specification addresses different aspects of the design model and is completed as
the designer refines his representation of the software.

S.No Software Design Document Module, Subpart

01. Reference Documents 1. Existing software documentation
2. System Documentation
3. Vendor(hardware or software) documents
4. Technical reference
02. Modules for each module 1. Processing narrative
2. Interface description
3. Design language(or other) description
4. Modules used
03. Scope 1. System objective
2. Hardware, software and human interfaces
3. Major software functions
4. Externally defined database
5. Major design constraints, limitations
04. Design Description 1. Data description
2. Derived program structure
3. Interface within structure
05. Test Provisions 1. Test guidelines
2. Integration strategy
3. Special considerations
06. Packaging 1. Special program overlay provisions
2. Transfer consideration
07. File Structure and global data 1. External Files structure
2. Global data
3. File and data cross reference
08. Requirement cross-reference 1. cross-reference

Importance of Design Documentation:

1. Requirements are well understood: With proper documentation, we can remove
inconsistencies and conflicts about the requirements. Requirements are well understood by
every team member.
2. Architecture/Design of product: Architecture/Design documents give us a complete
overview of how the product look like and better insight to the customer/user about their
product.
3. New Person can also work on the project: New person to the project can very easily
understand the project through documentations and start working on it. So, developers need
to maintain the documentation and keep upgrading it according to the changes made in the
product/software.
4. Everything is well Stated: This documentation is helpful to understand each and every
working of the product. It explains each and every feature of the product/software.
5. Proper Communication: Through documentation, we have good communication with
every member who is part of the project/software. Helpful in understanding role and
contribution of each and every member.