DESIGN PROCESS AND DESIGN QUALITY

It encompasses the set of principles, concepts and practices that lead to the development of high
quality system or product. Design creates a representation or model of the software. Design
model provides details about S/W architecture, interfaces and components that are necessary to
implement the system. Quality is established during Design. Design should exhibit firmness,
commodity and design. Design sits at the kernel of S/W Engineering. Design sets the stage for
construction. Software design is an iterative process through which requirements are translated
into a “blueprint” for constructing the software. Initially, the blueprint depicts a holistic view of
software.

QUALITY GUIDELINES

• Uses recognizable architectural styles or patterns

• Modular; that is logically partitioned into elements or subsystems

• Distinct representation of data, architecture, interfaces and components

• Appropriate data structures for the classes to be implemented

• Independent functional characteristics for components

• Interfaces that reduces complexity of connection

• Repeatable method

QUALITY ATTRIBUTES

• Functionality * Feature set and capabilities of programs * Security of the overall system

• Usability * user-friendliness * Aesthetics * Consistency * Documentation

• Reliability * Evaluated by measuring the frequency and severity of failure * MTBF

• Supportability * Extensibility * Adaptability * Serviceability

DESIGN CONCEPTS

A set of fundamental software design concepts has evolved over the past four decades. Although
the degree of interest in each concept has varied over the years, each has stood the test of time.

Each helps the software engineer to answer the following questions: • What criteria can be used
to partition software into individual components? • How is function or data structure detail
separated from a conceptual representation of the software? • What uniform criteria define the
technical quality of a software design?
1. Abstractions

2. Architecture

3. Patterns

4. Modularity

5. Information Hiding

6. Functional Independence

7. Refinement

8. Re-factoring

9. Design Classes

ABSTRACTION

Many levels of abstraction. Highest level of abstraction: Solution is slated in broad terms using
the language of the problem environment

Lower levels of abstraction: More detailed description of the solution is provided

• Procedural abstraction-- Refers to a sequence of instructions that a specific and limited function

• Data abstraction-- Named collection of data that describe a data object

ARCHITECTURE

--Structure organization of program components (modules) and their interconnection

Architecture Models

(a) Structural Models-- An organised collection of program components

(b) Framework Models-- Represents the design in more abstract way

(c) Dynamic Models-- Represents the behavioral aspects indicating changes as a function of
external events

(d). Process Models-- Focus on the design of the business or technical process
SOFTWARE PROCEDURE

Program structure defines control hierarchy without regard to the sequence of processing and
decisions. 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.

STRUCTURAL PARTITIONING

If the architectural style of 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

On the negative side, horizontal partitioning often causes more data to be passed across module
interfaces and can complicate the overall control of program flow.
Vertical partitioning (Figure 13.4b), 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.
Data structure dictates the organization, methods of access, degree of associativity, and
processing alternatives for information.

A limited number of classic data structures that form the building blocks for more sophisticated
structures. 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.

When the sequential vector is extended to two, three, and ultimately, an arbitrary number of
dimensions, an n-dimensional space is created. Items, vectors, and spaces may be organized in a
variety of formats. A linked list is a data structure that organizes noncontiguous scalar items,
vectors, or spaces in a manner (called nodes) that enables them to be processed as a list. Each
node contains the appropriate data organization (e.g., a vector) and one or more pointers that
indicate the address in storage of the next node in the list. A stack is a conceptual model of a data
structure that can be implemented as a vector or a linked list. Depending on the level of design
detail, the internal workings of a stack may or may not be specified.

PATTERNS

Provides a description to enables a designer to determine the followings :

(a). Whether the pattern is applicable to the current work

(b). Whether the pattern can be reused

(c). Whether the pattern can serve as a guide for developing a similar but functionally or
structurally different pattern

MODULARITY

Divides software into separately named and addressable components, sometimes called modules.
Modules are integrated to satisfy problem requirements. Consider two problems p1 and p2. If the
complexity of p1 is cp1 and of p2 is cp2 then effort to solve p1=cp1 and effort to solve p2=cp2 If
cp1>cp2 then ep1>ep2 The complexity of two problems when they are combined is often greater
than the sum of the perceived complexity when each is taken separately.

• Based on Divide and Conquer strategy : it is easier to solve a complex problem when broken
into sub-modules

Meyer defines five criteria that enable us to evaluate a design method with respect to its ability to
define an effective modular system:

Modular decomposability. If a design method provides a systematic mechanism for

decomposing the problem into subproblems, it will reduce the complexity of the overall problem,
thereby achieving an effective modular solution.

Modular composability. If a design method enables existing (reusable) design components to

be assembled into a new system, it will yield a modular solution that does not reinvent the wheel.

Modular understandability. If a module can be understood as a standalone unit (without

reference to other modules), it will be easier to build and easier to change.

Modular continuity. If small changes to the system requirements result in changes to individual
modules, rather than systemwide changes, the impact of change-induced side effects will be
minimized.

Modular protection. If an aberrant condition occurs within a module and its effects are
constrained within that module, the impact of error-induced side effects will be minimized.

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. Different notations are
used to represent control hierarchy for those architectural styles that are amenable to this
representation. The most common is the treelike diagram.
INFORMATION HIDING

Information contained within a module is inaccessible to other modules who do not need such
information. Achieved by defining a set of Independent modules that communicate with one
another only that information necessary to achieve S/W function. Provides the greatest benefits
when modifications are required during testing and later. Errors introduced during modification
are less likely to propagate to other location within the S/W.

FUNCTIONAL INDEPENDENCE

A direct outgrowth of Modularity, abstraction and information hiding. Achieved by developing a

module with single minded function and an aversion to excessive interaction with other modules.
Easier to develop and have simple interface. Easier to maintain because secondary effects caused
b design or code modification are limited, error propagation is reduced and reusable modules are
possible. Independence is assessed by two quantitative criteria:

(1) Cohesion

(2) Coupling

Cohesion -- Performs a single task requiring little interaction with other components

Coupling--Measure of interconnection among modules. Coupling should be low and cohesion

should be high for good design.

REFINEMENT & REFACTORING REFINEMENT

Stepwise refinement is a top-down design strategy.

-- Process of elaboration from high level abstraction to the lowest level abstraction. High level
abstraction begins with a statement of functions. Refinement causes the designer to elaborate
providing more and more details at successive level of abstractions Abstraction and refinement
are complementary concepts. Refactoring -- Organization technique that simplifies the design of
a component without changing its function or behavior. Examines for redundancy, unused design
elements and inefficient or unnecessary algorithms.

DESIGN CLASSES

Class represents a different layer of design architecture.

Five types of Design Classes

1. User interface class -- Defines all abstractions that are necessary for human computer
interaction
2. Business domain class -- Refinement of the analysis classes that identity attributes and
services to implement some of business domain

3. Process class -- implements lower level business abstractions required to fully manage the
business domain classes

4. Persistent class -- Represent data stores that will persist beyond the execution of the software

5. System class -- Implements management and control functions to operate and communicate
within the computer environment and with the outside world.

SOFTWARE ARCHITECTURE

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 relationship among them. Software Architecture is not the operational
software. It is a representation that enables a software engineer to

• Analyze the effectiveness of the design in meeting its stated requirements.

• consider architectural alternative at a stage when making design changes is still relatively easy .

• Reduces the risk associated with the construction of the software.

DATA DESIGN

The data design action translates data objects defined as part of the analysis model into data
structures at the component level and a database architecture at application level when necessary.

Data Modeling, Data Structures, Databases, and the Data Warehouse

The data design activity translates these elements of the requirements model into data structures
at the software component level and, when necessary, a database architecture at the application
level. In years past, data architecture was generally limited to data structures at the program level
and databases at the application level. But today, businesses large and small are awash in data.

The challenge for a business has been to extract useful information from this data environment,
particularly when the information desired is crossfunctional.

To solve this challenge, the business IT community has developed data mining techniques, also
called knowledge discovery in databases (KDD), that navigate through existing databases in an
attempt to extract appropriate business-level information.
An alternative solution, called a data warehouse, adds an additional layer to the data architecture.

A data warehouse is a large, independent database that encompasses some, but not all, of the data
that are stored in databases that serve the set of applications required by a business. But many
characteristics differentiate a data warehouse from the typical database.

Subject orientation. A data warehouse is organized by major business subjects, rather than by
business process or function. This leads to the exclusion of data that may be necessary for a
particular business function but is generally not necessary for data mining.

Integration. Regardless of the source, the data exhibit consistent naming conventions, units and
measures, encoding structures, and physical attributes, even when inconsistency exists across
different application-oriented databases.

Time variancy. For a transaction-oriented application environment, data are accurate at the
moment of access and for a relatively short time span (typically 60 to 90 days) before access. For
a data warehouse, however, data can be accessed at a specific moment in time (e.g., customers
contacted on the date that a new product was announced to the trade press). The typical time
horizon for a data warehouse is five to ten years.

Nonvolatility. Unlike typical business application databases that undergo a continuing stream of
changes (inserts, deletes, updates), data are loaded into the warehouse, but after the original
transfer, the data do not change. These characteristics present a unique set of design challenges
for a data architect.

DATA DESIGN AT ARCHITECTURE LEVEL

• Data structure at programming level

• Data base at application level

• Data warehouse at business level.

DATA DESIGN AT COMPONENT LEVEL

Principles for data specification:

1. Proper selection of data objects and data and data models

2. Identification of attribute and functions and their encapsulation of these within a class

3. Mechanism for representation of the content of each data object. Class diagrams may be used.

4. Refinement of data design elements from requirement analysis to component level design

5. Information hiding
6. A library of useful data structures and operations be developed

7. Software design and PL should support the specification and realization of abstract data types.