UNIT-II

DESIGN CONCEPTS AND PRINCIPLES

There are two major phases to any design process: Diversification and Convergence.
Diversification is the acquisition of a repertoire of alternatives, the raw material of
design: components, component solutions, and knowledge, all contained in catalogs,
textbooks, and the mind.
Convergence is the designer chooses and combines appropriate elements from this
repertoire to meet the design objectives, as stated in the requirements document and as
agreed to by the customer.

SOFTWARE DESIGN AND SOFTWARE ENGINEERING

Software design is the first of three technical activities
➢ Design,
➢ Code generation, and
➢ Test
that are required to build and verify the software. Each activity transforms information
in a manner that ultimately results in validated computer software.

Data Design
➢ The data design transforms the information domain model created during
analysis into the data structures that will be required to implement the software.
 ➢ The data objects and relationships defined in the entity relationship diagram and
the detailed data content depicted in the data dictionary provide the basis for the
data design activity.
Architectural Design
➢ The architectural design representation the framework of a computer-based
system can be derived from the system specification, the analysis model, and the
interaction of subsystems defined with in the analysis model.
Interface Design
➢ The interface design describes the software communicates within itself, with
systems that interoperate with it, and with humans use it.
➢ An interface implies a flow of information (e.g., data and/or control) and a specific
type of behavior.

Component-level Design
The component-level design transforms structural elements of the software architecture
into a procedural description of software components. Information obtained from the
PSPEC, CSPEC, and STD serve as the basis for component design.

THE DESIGN PROCESS

Software design is iterative processes through requirements are translated into a

“blueprint” for constructing the software. Initially, the blueprint depicts a holistic view
of software. As design iterations occur, subsequent refinement leads to design
representations at much lower levels of abstraction.
Design and Software Quality
McGlaughlin suggests three characteristics that serve as a guide for the evaluation of
a good design:
➢ The design must implement all of the explicit requirements contained in the
analysis model, and it must accommodate all of the implicit requirements desired
by the customer.
➢ The design must be a readable, understandable guide for those generate code
and for those test and subsequently support the software.
➢ The design should provide a complete picture of the software, addressing the
data, functional, and behavioral domains from an implementation perspective.
We present the following guidelines:
➢ A design should be modular; that is, the software should be logically partitioned
into elements that perform specific functions and sub functions.
➢ A design should contain distinct representations of data, architecture, interfaces,
and components (modules).
➢ A design should lead to data structures that are appropriate for the objects to be
implemented and are drawn from recognizable data patterns.
➢ A design should lead to components that exhibit independent functional
characteristics.
➢ A design should lead to interfaces that reduce the complexity of connections
between modules and with the external environment.
The Evolution of Software Design
➢ Each software design method introduces unique heuristics and notation, as
well as a some
➢ parochial view of what characterizes design quality.
➢ All of these methods have a number of common characteristics:
(1) A mechanism for the translation of analysis model into a design representation,
(2) A notation for representing functional components and their interfaces,
(3) Heuristics for refinement and partitioning, and
(4) guidelines for quality assessment.

DESIGN PRINCIPLES

Software design is both a process and a model. The design process is a sequence of
steps that enable the designer to describe all aspects of the software to be built.
• Creative skill, past experience, a sense of what makes “good” software and an
overall commitment to quality are critical success factors for a competent
design.
• The design model is the equivalent of an architect’s plans for a house. It
begins by representing the totality of the thing to be built.
Basic design principles enable the software engineer to navigate the design process.
We suggests a set of principles for software design
➢ The design process should not suffer from “tunnel vision.”
 A good designer should consider alternative approaches, judging each based
on the requirements of the problem, the resources available to do the job.
➢ The design should be traceable to the analysis model.
A single element of the design model often traces to multiple requirements, it
is necessary to have a means for tracking requirements have been satisfied
by the design model.
➢ The design should be structured to accommodate change.
The enable a design to achieve this principle.
➢ Design is not coding, coding is not design.
Even procedural designs are created for program components, the level of
abstraction of the design model is higher than source code. The only design
decisions made at the coding level address the small implementation details
that enable the procedural design to be coded.
➢ The design should be reviewed to minimize conceptual (semantic) errors.
There is sometimes a tendency to focus on minutiae when the design is
reviewed, missing the forest for the trees.
A design team should ensure that major conceptual elements of the design
(omissions, ambiguity, and inconsistency) have been addressed before worrying about
the syntax of the design model.

DESIGN CONCEPTS

A set of fundamental software design concepts has evolved over the past four decades.
Each provides the software designer with a foundation from more sophisticated design
methods can be applied.
M. A. Jackson once said:
"The beginning of wisdom for a [software engineer] is to recognize the difference between
getting a program to work, and getting it right". Fundamental software design concepts
provide the necessary framework for "getting it right."
ABSTRACTION
We consider a modular solution to any problem; many levels of abstraction can be
posed.
At the highest level of abstraction, a solution is stated in broad terms using the
language of the problem environment.
At lower levels of abstraction, a more procedural orientation is taken. Problem-
oriented terminology is coupled with implementation-oriented terminology in an effort
to state a solution. Finally, At the lowest level of abstraction, the solution is stated in
a manner that can be directly implemented.
PROCEDURAL ABSTRACTION
➢ A procedural abstraction is a named sequence of instructions that has a specific
and limited function.
Example of a procedural abstraction would be the word open for a door.
Open implies a long sequence of procedural steps
(e.g., walk to the door, reach out and grasp knob, turn knob and pull door, step
away from moving door, etc.).
DATA ABSTRACTION
➢ A data abstraction is a collection of data that describes a data object. In the
context of the procedural abstraction open, we can define a data abstraction
called door.
➢ Like any data object, the data abstraction for door would encompass a set of
attributes that describe the door.
Example door type, swing direction, opening mechanism, weight, dimensions).
It follows that the procedural abstraction open would make use of information
contained in the attributes of the data abstraction door.
CONTROL ABSTRACTION
➢ A Control abstraction is the third form of abstraction used in software design.
➢ Like procedural and data abstraction, control abstraction implies a program
control mechanism without specifying internal details.
Example of a control abstraction is the
Synchronization semaphore used to coordinate activities in an operating system.
REFINEMENT
➢ Refinement is actually a process of elaboration. We begin with a statement of
function (or description of information) that is defined at a high level of
abstraction.
➢ Refinement causes the designer to elaborate on the original statement, providing
more and more detail as each successive refinement (elaboration) occurs.
➢ Abstraction and refinement are complementary concepts. Abstraction enables a
 designer to specify procedure and data and yet suppress low-level details.
Refinement helps the designer to reveal low-level details as design progresses. Both
concepts aid the designer in creating a complete design model as the design evolves.
CONTROL HIERARCHY
➢ Control hierarchy, also called program structure, represents the organization of
program components (modules) and implies a hierarchy of control.
➢ It does not represent procedural aspects of software such as sequence of
processes, occurrence or order of decisions, or repetition of operations; nor is it
necessarily applicable to all architectural styles.

The control hierarchy also represents two subtly different characteristics of the
software architecture: visibility and connectivity.
➢ Visibility indicates the set of program components that may be invoked or used
as data by a given component, even this is accomplished indirectly.
➢ Connectivity indicates the set of components that are directly invoked or used
as data by a given component. For example, a module that directly causes
another module to begin execution is connected to it
STRUCTURAL PARTITIONING
➢ A system is hierarchical; the program structure can be partitioned both
horizontally and vertically.
➢ Horizontal partitioning defines separate branches of the modular hierarchy for
each major program function. Control modules, represented in a darker shade
are used to coordinate communication between and execution of the functions.
➢ The simplest approach to horizontal partitioning defines three partitions—input,
data transformation (often called processing) and output.
➢ Partitioning the architecture horizontally provides a number of distinct benefits:
 • software that is easier to test
• software that is easier to maintain
• propagation of fewer side effects
• software that is easier to extend

➢ Vertical partitioning often called factoring, suggests that control (decision

making) and work should be distributed top-down in the program structure.
➢ Top level modules should perform control functions and do little actual
processing work.
➢ Modules that reside low in the structure should be the workers, performing all
input, computation, and output tasks

DATA STRUCTURE
➢ Data structure is a representation of the logical relationship among individual
elements of data.
 ➢ Because the structure of information will invariably affect the final procedural
design, data structure is as important as program structure to the representation
of software architecture.
➢ Data structure dictates the organization, methods of access, degree of
associativity, and processing alternatives for information.
➢ A scalar item is the simplest of all data structures.
➢ As its name implies, a scalar item represents a single element of information that
may be addressed by an identifier; that is, access may be achieved by specifying
a single address in memory.
➢ The size and format of a scalar item may vary within bounds that are dictated by
a programming language.
➢ For example, a scalar item may be a logical entity one bit long, an integer or
floating point number that is 8 to 64 bits long, or a character string that is
hundreds or thousands of bytes long.

SOFTWARE PROCEDURE

➢ Software procedure focuses on the processing details of each module individually.

➢ Procedure must provide a precise specification of processing, including sequence
of events, exact decision points, repetitive operations, and even data organization
and structure.
➢ There is, of course, a relationship between structure and procedure. The
processing indicated for each module must include a reference to all modules
subordinate to the module being described. That is, a procedural representation
of software.
INFORMATION HIDING
➢ Hiding implies that effective modularity can be achieved by defining a set of
independent modules that communicate with one another only that information
necessary to achieve software function.
➢ Hiding defines and enforces access constraints to both procedural detail within
a module and any local data structure used by the module.
➢ The use of information hiding as a design criterion for modular systems provides
the greatest benefits when modifications are required during testing and later,
during software maintenance.

EFFECTIVE MODULAR DESIGN

➢ All the fundamental design concepts described in the preceding section serve to
precipitate modular designs. In fact, modularity has become an accepted
approach in all engineering disciplines.
Functional Independence
➢ The concept of functional independence is a direct outgrowth of modularity and
the concepts of abstraction and information hiding.
➢ Functional independence is achieved by developing modules with "single-minded"
function and an "aversion" to excessive interaction with other modules.
➢ Stated another way, we want to design software so that each module addresses
a specific sub function of requirements and has a simple interface viewed from
other parts of the program structure.
➢ Independence is measured using two qualitative criteria: cohesion and coupling.
➢ Cohesion is a measure of the relative functional strength of a module.
➢ Coupling is a measure of the relative interdependence among modules.

COHESION
A cohesive module performs a single task within a software procedure, requiring little
interaction with procedures being performed in other parts of a program.

Logically cohesive
A module that performs tasks that are related logically (e.g., a module that produces all
output regardless of type) is logically cohesive.
Temporal cohesion
A module contains tasks that are related by the fact that all must be executed with the
same span of time, the module exhibits temporal cohesion.
It performs the following tasks:
(1) Computes supplementary data based on original computed data,
(2) Produces an error report (with graphical content) on the user's workstation,
(3) Performs follow-up calculations requested by the user,
(4) Updates a database, and
(5) Enables menu selection for subsequent processing.
Procedural cohesion
Processing elements of a module are related and must be executed in a specific order,
procedural cohesion exists.
Communicational cohesion
All processing elements concentrate on one area of a data structure, communicational
cohesion is present.
High cohesion is characterized by a module that performs one distinct procedural task.
COUPLING
➢ Coupling is a measure of interconnection among modules in a software structure.

➢ Coupling depends on the interface complexity between modules, the point at

entry or reference is made to a module, and what data pass across the interface.
Examples of different types of module coupling
Data coupling
➢ Modules a and d are subordinate to different modules.
➢ Each is unrelated and therefore no direct coupling occurs. Module c is
subordinate to module a and is accessed via a conventional argument list,
through which data are passed.
➢ As long as a simple argument list is present (i.e., simple data are passed; a one-
to-one correspondence of items exists), low coupling (called data coupling) is
exhibited in this portion of structure.
Control coupling
➢ Control coupling is very common in most software designs and is shown in a
“control flag” (a variable that controls decisions in a subordinate or super
ordinate module) is passed between modules d and e.
➢ Relatively high levels of coupling occur when modules are tied to an environment
external to software. For example, I/O couples a module to specific devices,
formats, and communication protocols.
External coupling
➢ External coupling is essential, but should be limited to a small number of
modules with a structure. High coupling also occurs a number of modules
reference a global data area
Content coupling
➢ The highest degree of coupling, content coupling, occurs when one module makes
use of data or control information maintained within the boundary of another
module.
➢ Content coupling occurs when branches are made into the middle of a module.
This mode of coupling can and should be avoided.

SOFTWARE ARCHITECTURE

What is Architecture?

When you consider the architecture of a building, many different attributes come
to mind. At the most simplistic level, you think about the overall shape of the physical
structure. But in reality, architecture is much more. It is the manner in which the
various components of the building are integrated to form a cohesive whole. It is the way
in which the building fits into its environment and meshes with other buildings in its
vicinity. It is the degree to which the building meets its stated purpose and satisfies the
needs of its owner. It is the aesthetic feel of the structure—the visual impact of the
building—and the way textures, colors, and materials are combined to create the
external facade and the internal “living environment.” It is small details. the design of
lighting fixtures, the type of flooring, the placement of wall hangings, the list is almost
endless. And finally, it is art.
But architecture is also something else. It is “thousands of decisions, both big
and small” The software architecture of a program or computing system is the structure
or structures of the system, which comprise software components, the externally visible
properties of those components, and the relationships among them.
the architecture is not the operational software. Rather, it is a representation that
enables a software engineer to
(1) analyze the effectiveness of the design in meeting its stated requirements,
(2) consider architectural alternatives at a stage when making design changes is
still relatively easy, and
(3) reducing the risks associated with the construction of the software.
Why is Architecture Important?
In a book dedicated to software architecture, Bass and his colleagues identify
three key reasons that software architecture is important:
• Representations of software architecture are an enabler for communication between
all parties (stakeholders) interested in the development of a computer- based system.
• The architecture highlights early design decisions that will have a profound impact on
all software engineering work that follows and, as important, on the ultimate success of
the system as an operational entity.
• Architecture “constitutes a relatively small, intellectually graspable model of how the
system is structured and how its components work together”.
The architectural design model and the architectural patterns contained within
it are transferrable. That is, architecture styles and patterns can be applied to the design
of other systems and represent a set of abstractions that enable software engineers to
describe architecture in predictable ways.