UNIT-IV

DESIGN ENGINEERING

DESIGN PROCESS AND DESIGN QUALITY

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

McGlaughin suggests three characteristics 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 who generate code and for
those who test and subsequently support the software.

The design should provide a complete picture of the software.

Quality Guidelines(What are the Characteristics of a good design?)

In order to evaluate the quality of a design representation, we must establish technical criteria for
good design.
A design should exhibit an architecture that (1) has been created using recognizable
architectural styles or patterns, (2) is composed of components that exhibit good design
characteristics and (3) can be implemented in an evolutionary fashion
A design should be modular; that is, the software should be logically partitioned into
elements or subsystems
 A design should contain distinct representations of data, architecture, interfaces, and
components.
A design should lead to data structures that are appropriate for the classes 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
components and with the external environment.
A design should be derived using a repeatable method that is driven by information
obtained during software requirements analysis.
A design should be represented using a notation that effectively communicates its
meaning.
Quality Attributes
Hewlett-Packard developed a set of software quality attributes that has been given
the acronym FURPS-functionality, usability, reliability, performance and supportability.
Functionality: It is assessed by evaluating the capabilities of the program generality of the
functions that are delivered, and the security of the overall system.
Usability : Assessed by considering human factors, consistency &aesthetics(appearance).
Reliability: Evaluated by frequency &severity of errors,MeanTimeToFailure& ability to recover
from failure.
Performance: Measured by processing speed,response time,resource
consumption,throughput&efficiency
Supportability:Combines ability to extend the program,adaptability&the ease with which the
system can be installed.
Design Concepts:

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 has a specific and
limited function.Ex The word open of a door which implies a long sequence of
procedural steps (e.g., walk to the door, grasp the knob, pull the door& step away
from moving door etc)
Data abstraction: Named collection of data that describe a data object (Ex: door
would encompass a set of attributes like door type,weight,dimensions etc.
Architecture:
Architecture is the structure or organization of program components, the manner in which
these components interact, the structure of the data that are used by components.
Architectural design can be represented using one or more of a no of different models.
Structural Models: An organised collection of program components
Framework Models: Identifies repeatable architectural design frameworks that are
encountered in similar types of applications.
Dynamic Models : Represents the behavioral aspects indicating changes as a function of
external events
Process Models:Focus on the design of the business or technical process
Functional Models:Used to represent functional hierarchy of a system.
Patterns
Design pattern describes design structure that solves a particular problem.
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
Consider two problems p1& p2 if complexity of p1 is greater than complexity of p2 then
the effort required to solve p1 is greater than p2.
Based on Divide and Conquer strategy : it is easier to solve a complex problem when
broken into sub-modules
As the no of modules increases cost/module decreses
As the no of modules increases cost to integrate increases
Because of modularity testing and debugging can be done more efieciently.

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.
Design a software so that each module addresses a specific subfunction of requirements
& has a simple interface when viewed from other parts of program structure.
Functional Independence is assessed using two conditions
Cohesion: Relative functional strength of a module.
Coupling: Indication of relative interdependence among modules.
Refinement
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
Refactoring is a reorganization technique that simplifies design (or code) of a component
without changing its function or behavior.
Fowler defined that refactoring is a process of changing software system in such a way
that it does not alter external behavior of code yet improves its internal structure.
When software is refactored existing design is examined for redundancy, unused design
elements, inefficient algorithms, inappropriate data structures or any other design failures.
Design classes

As the design model evolves, the software team must define a set of design classes that refines
the analysis classes and creates a new set of design classes.

Five different classes types are shown below:

1. User Interface classes: define all abstractions that are necessary for HCI.
2. Business domain classes: are often refinements of the analysis classes defined earlier.
The classes identify the attributes and services that are required to implement some
element of the business domain.
3. Process classes: implement lower-level business abstractions required to fully manage
the business domain classes.
4. Persistent classes: represent data stores that will persist beyond the execution of the
software.
5. System classes: implement software management and control functions that enable the
system to operate and communicate within its computing environment and with the
outside world.

Design Models
DATA DESIGN ELEMENTS:

Data design creates a model of data and/or information that is represented at a high level of
abstraction.

The structure of data has always been an important part of software design
At the architectural (application) level, data design focuses on translation of data model
into a database.
At the program component level, data design focuses on data structures that are required
to implement the local data objects
At the business level ,the collection of information stored in disparate databases and
recognized into a data warehouse which enables data mining.

Architectural Design Elements

The architectural design for software is equivalent to floor plan of a house. Floor plan
gives us an overall view of house.
Architectural design elements give us an overall view of software.
The architectural model is derived form 3 sources:
1) Information about application domain for software to be built.
2) Specific analysis model elements such as Data Flow Diagram or analysis classes.
3) Availability of architectural styles and patterns.

Interface Design Elements

The interface design for software is equivalent to set of detailed drawings for doors,
windows and external utilities of a house..They tell us how information flow into and out
of house and within rooms that are part of house.
The interface design elements for software tell how information flows into and out of the
system and how it is communicated among components defined as part of architecture.
There are three important elements of interface design
 1) The user interface
2) Extrernal interfaces to other systems,devices,networks,or other consumers of
information
3) Internal interfaces between design componens
The design of UI incorporates
o Aesthetic elements(layout,color,graphics,interaction mechanisms)
o Erogonmic elements ( information layout and placement,metaphors)
o Technical elements (UI patterns,reusable components)
The design of external interfaces requires definitive information about the entity to which
information is sent or received.
The design of internal interfaces is closely aligned with component-level design
UML defines an interface in the following manner: An interface is a specifier for the
externally visible [public] operations of a class.
o For ex Safe Home Security function makes use of control panel that allows
homeowner to control certain aspects of security function. Control panel functions
may be implemented via a wireless PDA or mobile phone.

The Control Panel class of fig 9.5 provides behavior associated with a keypad and
therefore it must implement operations read keystroke() and decode key().If these
operations are to be provided to other classes it is useful to define an interface as
shown in fig

The interface named keypad is shown as an <<interface>> stereotype or a small,

labeled circle connected to class with a line. The interface is defined with no
attributes. But represent a set of operations necessary to achieve behavior of
keypad.
The dashed line with an open triangle at its end indicates that control panel class
provides keypad operations as part of its behavior.In UML this is characterized as a
realization.

Component-Level Design Elements:

The component-level design for software is equivalent to set of detailed drawing s for
each room in a house. These drawings depict wiring and plumbing within each room,
 location of switches, showers, drains etc.They also describe flooring to be used and every
other detailed associated with a room.
Component-level design for software fully describes the internal detail of each software
component.
To accomplish this, component-level design describes data structures for all local data
objects and algorithmic detail for all processing that occur within a component and an
interface that allows access to all component operations.
In UML the diagrammatic form as shown in fig 9.6.The component, named sensor
management is represented. A dashed arrow connects the component to a class named
sensor. The sensor management component performs all functions associated with Safe
home sensors.

The design details can be modeled at different levels of abstraction. An activity diagram
can be used to represent processing logic. Detailed procedural flow of a component can
be represented using either pseudo-code or some diagrammatic form.

Deployment-Level Design Elements

They indicate how software functionality and subsystems will be allocated within
computing environment that will support the software.
For Ex the elements of Safe home product are configured to operate with three primary
computing environment.-A home-based PC, Safe home control panel and a server housed
at CPI corp.
 In UML Deployment diagram is developed as shown in fig 9.7 The subsystems housed
within each computing element are indicated
The diagram shown in fig.9.7 is in descriptor form. This means deployment diagram
shows computing environment but does not explicitly indicate configuration details. For
ex PC could be a Macintosh, or a sun workstation or a linux.These details are provided
when deployment diagram is revisited during later stages of design or as construction
begins.

9.5 Pattern-Based Software Design

9.5.1 Describing a Design Pattern

The best designers in any field have an uncanny ability to see patterns that characterize
a problem and corresponding patterns that can be combined to create a solution
A description of a design pattern may also consider a set of design forces.
Design forces describe non-functional requirements (e.g., ease of maintainability,
portability) associated the software for which the pattern is to be applied.
Forces define the constraints that may restrict the manner in which the design is
to be implemented.
Design forces describe the environment and conditions that must exist to make
the design pattern applicable.
The pattern characteristics (classes, responsibilities, and collaborations) indicate the
attributes of the design that may be adjusted to enable the pattern to accommodate a
variety of problems.
These attributes represent characteristics of the design that can be searched (via
database) so that an appropriate pattern can be found.
Finally, guidance associated with the use of a design pattern provides an indication of
the ramification of design decisions.
The name of design patterns should be chosen with care.
One of the key technical problems in software reuse is the inability to find existing
patterns when hundreds or thousands of candidate patterns exist.
The search of the right pattern is aided immeasurably by a meaningful pattern name.

9.5.2 Using Patterns in Design

Design patterns can be used throughout software design.

Once the analysis model has been developed, the designer can examine a detailed
representation of the problem to be solved and the constraints that are imposed by the problem.

The problem description is examined at various levels of abstraction to determine if it is

amenable to one or more of the following design patterns:

Architectural patterns: These patterns define the overall structure of the software, indicate the
relationships among subsystems and software components, and define the rules for specifying
relationships among the elements (classes, packages, components, subsystems) of the
architecture.

Design patterns: These patterns address a specific element of the design such as an
aggregation of components to solve some design problems, relationships among components,
or the mechanisms for effecting component-to-component communication.

Idioms: Sometimes called coding patterns, these language-specific patterns generally

implement an algorithmic element of a component, a specific interface protocol, or a mechanism
for communication among components.

Frameworks

A framework is not an architectural pattern, but rather a skeleton with a collection of

plug points (also called hooks and slots) that enable it to be adapted to a specific
problem domain.
Gamma et al note that:
 Design patterns are more abstract than frameworks.
Design patterns are smaller architectural elements than frameworks
Design patterns are less specialized than frameworks