UNIT II SOFTWARE DESIGN

Design Concepts – Design Model – Software Architecture – Architectural Styles –

Architectural Design – Component-Level Design – User Experience Design – Design for
Mobility – Pattern-Based Design

1. Design Concepts:
Software Design is the process to transform the user requirements into some suitable form,
which helps the programmer in software coding and implementation. During the software
design phase, the design document is produced, based on the customer requirements as
documented in the SRS document. Hence the aim of this phase is to transform the SRS
document into the design document.

The following items are designed and documented during the design phase:
• Different modules required.
• Control relationships among modules.
• Interface among different modules.
• Data structure among the different modules.
• Algorithms required to implement among the individual modules.

Objectives of Software Design:

1. Correctness
2. Efficiency
3. Flexibility
4. Understandability
5. Completeness
6. Maintainability

Software Design Concepts:

Concepts are defined as a principal idea or invention that comes into our mind or in thought
to understand something. The software design concept simply means the idea or principle
behind the design. It describes how you plan to solve the problem of designing software, the
logic, or thinking behind how you will design software. It allows the software engineer to
create the model of the system or software or product that is to be developed or built. The
software design concept provides a supporting and essential structure or model for
developing the right software.
The following points should be considered while designing Software:

1. Abstraction- hide Irrelevant data

Abstraction simply means to hide the details to reduce complexity and increases
efficiency or quality. Different levels of Abstraction are necessary and must be
applied at each stage of the design process so that any error that is present can be
removed to increase the efficiency of the software solution and to refine the
software solution.

2. Modularity- subdivide the system

Modularity simply means dividing the system or project into smaller parts to
reduce the complexity of the system or project. In the same way, modularity in
design means subdividing a system into smaller parts so that these parts can be
created independently and then use these parts in different systems to perform
different functions.

3. Architecture- design a structure of something

Architecture simply means a technique to design a structure of something.

Architecture in designing software is a concept that focuses on various elements
and the data of the structure. These components interact with each other and use
the data of the structure in architecture.

4. Refinement- removes impurities

Refinement simply means to refine something to remove any impurities if present

and increase the quality. The refinement concept of software design is actually a
process of developing or presenting the software or system in a detailed manner
that means to elaborate a system or software.

5. Pattern- a repeated form

The pattern simply means a repeated form or design in which the same shape is
repeated several times to form a pattern. The pattern in the design process means
the repetition of a solution to a common recurring problem within a certain
context.

6. Information Hiding- hide the information

Information hiding simply means to hide the information so that it cannot be

accessed by an unwanted party. In software design, information hiding is achieved
by designing the modules in a manner that the information gathered or contained
in one module is hidden and can’t be accessed by any other modules.

7. Refactoring- reconstruct something

Refactoring simply means reconstructing something in such a way that it does not
affect the behaviour of any other features. Refactoring in software design means
 reconstructing the design to reduce complexity and simplify it without affecting
the behaviour or its functions. Fowler has defined refactoring as “the process of
changing a software system in a way that it won’t affect the behaviour of the
design and improves the internal structure”.

Different levels of Software Design:

There are three different levels of software design. They are:

1. Architectural Design:

The architecture of a system can be viewed as the overall structure of the system &
the way in which structure provides conceptual integrity of the system. The
architectural design identifies the software as a system with many components
interacting with each other. At this level, the designers get the idea of the proposed
solution domain.

2. Preliminary or high-level design:

Here the problem is decomposed into a set of modules, the control relationship
among various modules identified, and also the interfaces among various modules
are identified. The outcome of this stage is called the program architecture. Design
representation techniques used in this stage are structure chart and UML.

3. Detailed design:

Once the high-level design is complete, a detailed design is undertaken. In detailed

design, each module is examined carefully to design the data structure and
algorithms. The stage outcome is documented in the form of a module
specification document.

2. Design Model:
Following are the types of design elements:

1. Data design elements

• The data design element produced a model of data that represent a high level of
abstraction.
• The structure of data is the most important part of the software design.

2. Architectural design elements

• The architecture design elements provide us overall view of the system.
• The architectural design element is generally represented as a set of interconnected
subsystems that are derived from analysis packages in the requirement model.

3. Interface design elements

 • The interface design elements for software represents the information flow within it
and out of the system.
• They communicate between the components defined as part of architecture.

4. Component level diagram elements

• The component level design for the software completely describes the internal details
of each software component.
• The processing of data structure occurs in a component and an interface which allows
all the component operations.
• In a context of object-oriented software engineering, a component shown in a UML
diagram.

5. Deployment level design elements

• The deployment level design element shows the software functionality and subsystem
that allocated in the physical computing environment which support the software.

3. Software Architecture:
Architecture serves as a blueprint for a system. It provides an abstraction to manage the
system complexity and establish a communication and coordination mechanism among
components.
• It defines a structured solution to meet all the technical and operational
requirements, while optimizing the common quality attributes like performance
and security.
 • Further, it involves a set of significant decisions about the organization related
to software development and each of these decisions can have a considerable
impact on quality, maintainability, performance, and the overall success of the
final product. These decisions comprise of −
o Selection of structural elements and their interfaces by which the
system is composed.
o Behavior as specified in collaborations among those elements.
o Composition of these structural and behavioral elements into
large subsystem.
o Architectural decisions align with business objectives.
o Architectural styles guide the organization.

Goals of Architecture
The primary goal of the architecture is to identify requirements that affect the structure of the
application. A well-laid architecture reduces the business risks associated with building a
technical solution and builds a bridge between business and technical requirements.
Limitations
• Lack of tools
• Lack of analysis methods
• Lack of awareness
• Lack of understanding

Role of Software Architect

Design Expertise
• Expert in software design, including diverse methods and approaches such as
object-oriented design, event-driven design, etc.
Domain Expertise
• Expert on the system being developed and plan for software evolution.
Technology Expertise
• Expert on available technologies that helps in the implementation of the system.
Methodological Expertise
• Expert on software development methodologies that may be adopted during
SDLC (Software Development Life Cycle).
Hidden Role of Software Architect
• Facilitates the technical work among team members and reinforcing the trust
relationship in the team.
Deliverables of the Architect
• A clear, complete, consistent, and achievable set of functional goals
• A functional description of the system, with at least two layers of decomposition

Quality Attributes
Quality is a measure of excellence or the state of being free from deficiencies or defects.
Quality attributes are the system properties that are separate from the functionality of
the system.
They can be classified as −
Static Quality Attributes
Reflect the structure of a system and organization, directly related to architecture, design, and
source code. They are invisible to end-user, but affect the development and maintenance cost,
e.g.: modularity, testability, maintainability, etc.
Dynamic Quality Attributes
Reflect the behavior of the system during its execution. They are directly related to system’s
architecture, design, source code, configuration, deployment parameters, environment, and
platform.
They are visible to the end-user and exist at runtime, e.g. throughput, robustness, scalability,
etc.

4. Architectural Styles:
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.
5. Component-Level Design:
The component-level design can be represented by using different approaches. One approach
is to use a programming language while other is to use some intermediate design notation such
as graphical (DFD, flowchart, or structure chart), tabular (decision table), or text-based
(program design language) whichever is easier to be translated into source code.
The component-level design provides a way to determine whether the defined algorithms, data
structures, and interfaces will work properly. The modular design of the software should
exhibit the following sets of properties.

▪ Provide simple interface: Simple interfaces decrease the number of

interactions. Note that the number of interactions is taken into account while
determining whether the software performs the desired function. Simple
interfaces also provide support for reusability of components which reduces the
cost to a greater extent. It not only decreases the time involved in design, coding,
and testing but the overall software development cost is also liquidated gradually
with several projects. A number of studies so far have proven that the reusability
of software design is the most valuable way of reducing the cost involved in
software development.

▪ Ensure information hiding: The benefits of modularity cannot be achieved

merely by decomposing a program into several modules; rather each module
should be designed and developed in such a way that the information hiding is
ensured. It implies that the implementation details of one module should not be
visible to other modules of the program. The concept of information hiding helps
in reducing the cost of subsequent design changes.

Modularity has become an accepted approach in every engineering discipline. With the
introduction of modular design, complexity of software design has considerably reduced;
change in the program is facilitated that has encouraged parallel development of systems. To
achieve effective modularity, design concepts like functional independence are considered to
be very important.
Functional Independence

Functional independence is the refined form of the design concepts of modularity, abstraction,
and information hiding. Functional independence is achieved by developing a module in such
a way that it uniquely performs given sets of function without interacting with other parts of
the system. The software that uses the property of functional independence is easier to develop
because its functions can be categorized in a systematic manner. Moreover, independent
modules require less maintenance and testing activity, as secondary effects caused by design
modification are limited with less propagation of errors. In short, it can be said that functional
independence is the key to a good software design and a good design result in high-quality
software. There exist two qualitative criteria for measuring functional independence,
namely, coupling and cohesion.
Coupling

Coupling measures the degree of interdependence among the modules. Several factors like
interface complexity, type of data that pass across the interface, type of communication,
number of interfaces per module, etc. influence the strength of coupling between two modules.
For better interface and well-structured system, the modules should be loosely coupled in
order to minimize the ‘ripple effect’ in which modifications in one module results in errors in
other modules. Module coupling is categorized into the following types.

▪ No direct coupling: Two modules are said to be ‘no direct coupled’ if they are
independent of each other.
 ▪ Data coupling: Two modules are said to be ‘data coupled’ if they use parameter
list to pass data items for communication.
▪ Stamp coupling: Two modules are said to be ‘stamp coupled’ if they
communicate by passing a data structure that stores additional information than
what is required to perform their functions.
▪ Control coupling: Two modules are said to be ‘control coupled’ if they
communicate (pass a piece of information intended to control the internal logic)
using at least one ‘control flag’. The control flag is a variable whose value is used
by the dependent modules to make decisions.

▪ Content coupling: Two modules are said to be ‘content coupled’ if one module
modifies data of some other module or one module is under the control of another
module or one module branches into the middle of another module.

▪ Common coupling: Two modules are said to be ‘common coupled’ if they both
reference a common data block.

Cohesion

Cohesion measures the relative functional strength of a module. It represents the strength of
bond between the internal elements of the modules. The tighter the elements are bound to each
other, the higher will be the cohesion of a module. In practice, designers should avoid a low
level of cohesion when designing a module. Generally, low coupling results in high cohesion
and vice versa.
Various types of cohesion are listed below.

▪ Functional cohesion: In this, the elements within the modules are concerned
with the execution of a single function.
▪ Sequential cohesion: In this, the elements within the modules are involved in
activities in such a way that the output from one activity becomes the input for
the next activity.
▪ Communicational cohesion: In this, the elements within the modules perform
different functions, yet each function references the same input or output
information.
▪ Procedural cohesion: In this, the elements within the modules are involved in
different and possibly unrelated activities.
▪ Temporal cohesion: In this, the elements within the modules contain unrelated
activities that can be carried out at the same time.
▪ Logical cohesion: In this, the elements within the modules perform similar
activities, which are executed from outside the module.
▪ Coincidental cohesion: In this, the elements within the modules perform
activities with no meaningful relationship to one another.