Designer's Goal

The designer's goal is to produce a model or

representation of an entity that will later be built.
The process by which the design model is devel-
oped :
Design Goal

 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.
 During convergence, 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.
 The second phase is the gradual elimination of all but one particular
configuration of components, and thus the creation of the final product.
Cont …..
 Diversification and convergence combine intuition and judgment
based on experience in building similar entities,
 a set of principles and/or heuristics that guide the way in
which the model evolves,
 a set of criteria that enables quality to be judged, and a
process of iteration that ultimately leads to a final design
representation.
 Software design, like engineering design approaches in other
disciplines, changes continually as new methods, better
analysis, and broader understanding
S O F T WA R E D E S I G N A N D S O F T WA R E E N G I N E E R I N G

 Software design sits at the technical kernel of software engineering and is applied
regardless of the software process model that is used.
 Beginning once software requirements have been analyzed and specified, 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.
 “The most common miracles of software engineering are the transitions from
 analysis to design and design to code.” Richard Dué
Cont …..
 The flow of information during software design is
illustrated in Figure 13.1.
 Software requirements, manifested by the data, functional,
and behavioral models,
 feed the design task. Using one of a number of design
methods the design task produces a data design, an
architectural design, an interface design, and a component
design.
Cont …..
 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.
 Part of data design may occur in conjunction with the design of software
architecture.
 More detailed data design occurs as each software component is designed.
Cont …..
 The architectural design defines the relationship between major
structural elements of the software, the “design patterns” that can be
used to achieve the requirements that have been defined for the
system, and the constraints that affect the way in which architectural
design patterns can be applied .
 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 within the analysis model.
Cont …..
 The interface design describes how the software communicates within itself, with systems that
interoperate with it, and with humans who use it.
 An interface implies a flow of information (e.g., data and/or control) and a specific type of behavior.
 Therefore, data and control flow diagrams provide much of the information required for interface
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.

 During design we make decisions that will ultimately affect the success of software construction and,
as important, the ease with which software can be maintained.

 But why is design so important?

Cont …..
 The importance of software design can be stated with a single word—quality.

 Design is the place where quality is fostered in software engineering.

 Design provides us with representations of software that can be assessed for quality.

 Design is the only way that we can accurately translate a customer's requirements into a finished
software product or system.

 Software design serves as the foundation for all the software engineering and software support steps
that follow.

 Without design, we risk building an unstable system—one that will fail when small changes are
made; one that may be difficult to test; one whose quality cannot be assessed until late in the software
process, when time is short and many dollars have already been spent.
 THE DESIGN PROCESS
 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.
 That is, the design is represented at a high level of abstraction a level that can be
directly traced to the specific system objective and more detailed data, functional, and
behavioral requirements.
 As design iterations occur, subsequent refinement leads to design representations at
much lower levels of abstraction.
 These can still be traced to requirements, but the connection is more subtle.
 Design and Software Quality
 Throughout the design process, the quality of the evolving design is assessed with a series of
formal technical reviews or design walkthroughs discussed in [HCI]

 McGlaughlin [MCG91] 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 who generate code and for
those who 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.
Cont …..
 Each of these characteristics is actually a goal of the design
process.
 But how is each of these goals achieved?
 In order to evaluate the quality of a design representation, we
must establish technical criteria for good design.
 Are generic guidelines that will lead to a good design?
 in some detail. For the time being, we present the following
guidelines:
“To achieve a good design, people have to think
the right way about how to conduct the design
activity.”Katharine Whitehead
 Heuristic Design
1. A design should exhibit an architectural structure that
(1) has been created using recognizable design patterns,
(2) is composed of components that exhibit good design characteristics and
(3) can be implemented in an evolutionary fashion, thereby facilitating
implementation and testing.
2.A design should be modular; that is, the software should be logically
partitioned into elements that perform specific functions and sub functions.
3. A design should contain distinct representations of data, architecture,
interfaces, and components (modules).
Cont …..
4. A design should lead to data structures that are appropriate for the
objects to be implemented and are drawn from recognizable data
patterns.
5. A design should lead to components that exhibit independent
functional characteristics.
6. A design should lead to interfaces that reduce the complexity of
connections between modules and with the external environment.
7. A design should be derived using a repeatable method that is driven
by information obtained during software requirements analysis.
 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.
 It is important to note, however, that the design process is not simply a cookbook.
 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 (e.g., a three-dimensional rendering
of the house) and slowly refines the thing to provide guidance for constructing each detail (e.g.,
the plumbing layout).
 Similarly, the design model that is created for software provides a variety of different views of
the computer software.
Cont …..
 Basic design principles enable the software engineer to navigate the design process.
 Davis [DAV95] suggests a set1 of principles for software design, which have been adapted and
extended in the following list
 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 design should be traceable to the analysis model.
 Because a single element of the design model often traces to multiple requirements, it is
necessary to have a means for tracking how requirements have been satisfied by the design
model.
Cont …..
 The design should not reinvent the wheel.

Systems are constructed using a set of design patterns, many of which have likely been encountered
before.

These patterns should always be chosen as an alternative to reinvention.

 Time is short and resources are limited! Design time should be invested in representing truly new
ideas and integrating those patterns that already exist.

 The design should “minimize the intellectual distance” [DAV95] between the software and the
problem as it exists in the real world.

 That is, the structure of the software design should (whenever possible) mimic the structure of the
problem domain.
Cont …..
 The design should exhibit uniformity and integration. A design is uni- form if it appears that one
person developed the entire thing. Rules of style and format should be defined for a design team
before design work begins.

 A design is integrated if care is taken in defining interfaces between design Components.

 The design should be structured to accommodate change.

 The design concepts discussed in the next section enable a design to achieve this principle.

 The design should be structured to degrade gently, even when aberrant data, events, or
operating conditions are encountered. Well designed software should never “bomb.”

 It should be designed to accommodate unusual circumstances, and if it must terminate processing, do

so in a graceful manner.
Cont …..
 Design is not coding, coding is not design.
 Even when detailed 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 assessed for quality as it is being created, not
after the fact.
Cont …..
 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,
inconsistency) have been addressed before worrying about the syntax of the design model.

 When these design principles are properly applied, the software engineer creates a design that
exhibits both external and internal quality factors [MEY88].

 External quality factors are those properties of the software that can be readily observed by users
(e.g., speed, reliability, correctness, usability).2 Internal quality factors are of importance to software
engineers.

 They lead to a high-quality design from the technical perspective. To achieve internal quality factors,
the designer must understand basic design concepts.
 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 provides the software designer with a foundation from which more sophisticated design
methods can be applied.
 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?
 Abstraction
 When we consider a modular solution to any problem, many levels of abstraction can 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. Wasserman [WAS83] provides a useful definition:
 The psychological notion of "abstraction" permits one to concentrate on a problem at
some level of generalization without regard to irrelevant low level details;
use of abstraction also permits one to work with concepts and terms that are familiar in the
problem environment without having to transform them to an unfamiliar structure .
Cont …..
 A procedural abstraction is a named sequence of instructions that has a specific and
limited function.
 An example of a procedural abstraction would be the word open for a door.
 In the context of the procedural abstraction open, we can define a data abstraction
called door.
 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.
 An example of a control abstraction is the synchronization semaphore [KAI83] used
to coordinate activities in an operating system.
 Refinement
 A program is developed by successively refining levels of procedural detail.
 A hierarchy is developed by decomposing a macroscopic statement of function (a
procedural abstraction) in a stepwise fashion until programming language statements
are reached.
 In each step (of the refinement), one or several instructions of the given program are
decomposed into more detailed instructions.
 This successive decomposition or refinement of specifications terminates
when all instructions are expressed in terms of any underlying computer or
programming language . . .
As tasks are refined, so the data may have to be refined, decomposed, or
structured, and it is natural to refine the program and the data specifications in
parallel.
 Modularity
 modularity; is, software is divided into separately named and addressable
components, often called modules, that are integrated to satisfy problem
requirements.
 It has been stated that "modularity is the single attribute of software that
allows a program to be intellectually manageable".
 Monolithic software (i.e., a large program composed of a single module)
cannot be easily grasped by a reader.
 The number of control paths, span of reference, number of variables, and
overall complexity would make understanding close to impossible.