Design engineering encompasses the set of principles, concepts, and practices that lead to the

development of a high- quality system or product.

Design principles establish an overriding philosophy that guides the designer in the work that is
performed. Design concepts must be understood before the mechanics of design practice are
applied and Design practice itself leads to the creation of various representations of the software
that serve as a guide for the construction activity that follows.

What is design?
a) Design is what virtually every engineer wants to do. It is the place where creativity rules
customer‘s requirements, business needs, and technical considerations all come together in the
formulation of a product or a system.
b) Design creates a representation or model of the software, but unlike the analysis model,
the design model provides detail about software data structures, architecture, interfaces, and
components that are necessary to implement the system.

Why is it important:

Design allows a software engineer to model the system or product that Is to be built. This model
can be assessed for quality and improved before code is generated, tests are conducted, and end –
users become involved in large numbers. Design is the place where software quality is
established.

 The goal of design engineering is to produce a model or representation that exhibits

firmness, commodity, and delight. To accomplish this, a designer must practice diversification
and then convergence. Another goal of software design is to derive an architectural rendering of
a system. The rendering serves as a framework from which more detailed design activities are
conducted.

1) DESIGN PROCESS AND DESIGN QUALITY: Software design is an iterative process

through which requirements are translated into a ―blueprint for constructing the software.

Goals of design:
 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 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. Quality
guidelines: In order to evaluate the quality of a design representation we must establish
technical criteria for good design.

These are the following guidelines:

A design should exhibit an architecture that has been created using recognizable architectural
styles or patterns is composed of components that exhibit good design characteristics and can
be implemented in an evolutionary fashion, thereby facilitating implementation and testing.

a) A design should be modular; that is, the software should be logically partitioned into
elements or subsystems.
b) A design should contain distinct representation of data, architecture, interfaces and
components.
c) 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.
d) A design should lead to interface that reduce the complexity of connections between
components and with the external environment.
e) A design should be derived using a repeatable method that is driven by information
obtained during software requirements analysis
f) A design should be represented using a notation that effectively communication its
meaning.
g) These design guidelines are not achieved by chance. Design engineering encourages good
design through the application of fundamental design principles, systematic
methodology, and thorough review.

Quality attributes:
The FURPS quality attributes represent a target for all software design:
a) Functionality is assessed by evaluating the feature set and capabilities of the program, the
generality of the functions that are delivered, and the security of the overall system.
b)Usability is assessed by considering human factors, overall aesthetics, consistency and
documentation
c) Reliability is evaluated by measuring the frequency and severity of failure, the accuracy of
output results, and the mean – time –to- failure (MTTF), the ability to recover from failure, and
the predictability of the program.
d) Performance is measured by processing speed, response time, resource consumption,
throughput, and efficiency 
e) Supportability combines the ability to extend the program (extensibility), adaptability,
serviceability- these three attributes represent a more common term maintainability.
Note: Not every software quality attribute is weighted equally as the software design is
developed. One application may stress functionality with a special emphasis on security. Another
may demand performance with particular emphasis on processing speed.
A third might focus on reliability
2) DESIGN CONCEPTS:
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.

I. Abstraction:

Many levels of abstraction are there. 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 detailed description of the solution is provided.

A procedural abstraction refers to a sequence of instructions that have a specific and limited
function. The name of procedural abstraction implies these functions, but specific details are
suppressed.

A data abstraction is a named 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 (e.g., door type, swing operation, 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.

II. Architecture:

Software architecture alludes to ―the overall structure of the software and the ways in which
that structure provides conceptual integrity for a system‖. In its simplest form, architecture is the
structure or organization of program components (modules), the manner in which these
components interact, and the structure of data that are used by the components.
 One goal of software design is to derive an architectural rendering of a system. The
rendering serves as a framework from which more detailed design activities are conducted.
The architectural design can be represented using one or more of a number of different models.
a) Structured models represent architecture as an organized collection of program components
b) Framework models increase the level of design abstraction by attempting to identify
repeatable architectural design frameworks that are encountered in similar types of applications.
c) Dynamic models address the behavioral aspects of the program architecture, indicating how
the structure or system configuration may change as a function external events.
d) Process models focus on the design of the business or technical process that the system must
accommodate.
e) Functional models can be used to represent the functional hierarchy of a system.
III.Patterns:

Brad Appleton defines a design pattern in the following manner: ―a pattern is a named nugget
of inside which conveys that essence of a proven solution to a recurring problem within a certain
context amidst competing concerns.

The intent of each design pattern is to provide a description that enables a designer to determine

 Whether the pattern is capable to the current work,

 Whether the pattern can be reused,
 Whether the pattern can serve as a guide for developing a similar, but functionally
or structurally different pattern.

IV.Modularity:

Software architecture and design patterns embody modularity; software is divided into separately
named and addressable components, sometimes called modules that are integrated to satisfy
problem requirements.

 The divide and conquer‖ strategy- it‘s easier to solve a complex problem when you
break it into manageable pieces. This has important implications with regard to modularity and
software. If we subdivide software indefinitely, the effort required to develop it will become
negligibly small.
 Under modularity or over modularity should be avoided. We modularize a design
so that development can be more easily planned; software increment can be defined and
delivered and changes can be more easily accommodated; testing and debugging can be
conducted more efficiently, and long-term maintenance can be conducted without serious side
effects.

V. Information Hiding:

The principle of information hiding suggests that modules be ―characterized by design decision
that hides from all others.
 Modules should be specified and designed so that information contained within a module
is inaccessible to other modules that have no need for such information
 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. Because most data and procedure are hidden from other parts of the software,
inadvertent errors introduced during modification are less likely to propagate to other locations
within software.
VI. 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
 Software with effective modularity, that is, independent modules, is easier to develop
because function may be compartmentalized and interfaces are simplified. Independent sign or
code modifications are limited, error propagation is reduced, and reusable modules are possible.
To summarize, functional independence is a key to good design, and design is the key to
software quality.
 Independence is assessed using two qualitative criteria: cohesion and coupling
 Cohesion is an indication of the relative functional strength of a module.
 Coupling is an indication of the relative interdependence among modules.
 A cohesion module performs a single task, requiring little interaction with other
components in other parts of a program. Stated simply, a cohesive module should do just one
thing.Cohesion is a natural extension of the information hiding.
 Coupling is an indication of interconnection among modules in a software structure.
Coupling depends on the interface complexity between modules, the point at which entry or
reference is made to a module, and what data pass across the interface. In software design, we
strive for lowest possible coupling. Simple connectivity among modules results in software that
is easier to understand and less prone to a ―ripple effect‖, caused when errors occur at one
location and propagates throughout a system.

VII. Refinement:

 Stepwise refinement is a top- down design strategy originally proposed by Niklauswirth.

A program is development by successively refining levels of procedural detail. A hierarchy is
development by decomposing a macroscopic statement of function in a step wise fashion until
programming language statements are reached.
 Refinement is actually a process of elaboration. We begin with a statement of function
that is defined at a high level of abstraction. That is, the statement describes function or
information conceptually but provides no information about the internal workings of the function
or the internal structure of the data. Refinement causes the designer to elaborate on the original
statement, providing more and more detail as each successive refinement 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

VIII. Refactoring :

Refactoring is a reorganization technique that simplifies the design of a component without

changing its function or behavior. Fowler defines refactoring in the following manner:
―refactoring is the process of changing a software system in such a way that it does not alter the
external behavior of the code yet improves its internal structure.‖
IX. Design classes:

The software team must define a set of design classes that Refine the analysis classes by
providing design detail that will enable the classes to be implemented.

Five different types of design classes, each representing a different layer of the design
architecture are suggested.

 User interface classes: define all abstractions that are necessary for human computer
interaction. In many cases, HCL occurs within the context of a metaphor and the design classes
for the interface may be visual representations of the elements of the metaphor
 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. Process classes implement lower – level business abstractions required to
fully manage the business domain classes.
 Persistent classes represent data stores that will persist beyond the execution of the
software. 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.

Data design elements:

process dimension Data design sometimes referred to as data architecting creates a model of data
and/or information that is represented at a high level of abstraction.
 This data model is then refined into progressively more implementation-specific
representations that can be processed by the computer-based system. The structure of data has
always been an important part of software design.
 At the program component level, the design of data structures and the associated
algorithms required to manipulate them is essential to the criterion of high-quality applications.
 At the application level, the translation of a data model into a database is pivotal to
achieving the business objectives of a system.
 At the business level, the collection of information stored in disparate databases and
reorganized into a ―data warehouse‖ enables data mining or knowledge discovery that can have
an impact on the success of the business itself.

3) Design Model

 Design elements allow the software to communicated externally and enable internal
communication and collaboration among the components that populate the software architecture.
 Architectural design elements:
 The architectural design for software is the equivalent to the floor plan of a house.
 The architectural model is derived from three sources. Information about the application
domain for the software to be built. Specific analysis model elements such as data flow
diagrams or analysis classes, their relationships and collaborations for the problem at
hand, and The availability of architectural patterns.
 .

Data design elements:

 Data design sometimes referred to as data architecting creates a model of data and/or
information that is represented at a high level of abstraction. This data model is then refined into
progressively more implementation-specific representations that can be processed by the
computer-based system.
The structure of data has always been an important part of software design.

At the program component level, the design of data structures and the associated algorithms
required to manipulate them is essential to the criterion of high-quality applications.
At the application level, the translation of a data model into a database is pivotal to achieving
the business objectives of a system.
At the business level, the collection of information stored in disparate databases and reorganized
into a data warehouse‖ enables data mining or knowledge discovery that can have an impact on
the success of the business itself.

Interface design elements:

The interface design for software is the equivalent to a set of detailed drawings for the doors,
windows, and external utilities of a house.
 The interface design elements for software tell how information flows into and out of the
system and how it is communicated among the components defined as part of the architecture.
There are 3 important elements of interface design: The user interface(UI);
External interfaces to other systems, devices, networks, or other produces or consumers of
information; and Internal interfaces between various design components.
Component level Design Elements

The component-level design for software is equivalent to a set of detailed drawings.

The component-level design for software fully describes the internal detail of each software
component. To accomplish this, the component-level design defines data structures for all local
data objects and algorithmic detail for all processing that occurs within a component and an
interface that allows access to all component operations

Deployment Design Elements

Deployment-level design elements indicated how software functionality and subsystems

will be allocated within the physical computing environment that will support the
software
SOFTWARE ARCHITECTURE:

What Is Architecture?
 Architectural design represents the structure of data and program components that are
required to build a computer-based system.
 It considers the architectural style that the system will take, the structure and properties
of the components that constitute the system, and the interrelationships that occur among all
architectural components of a system.
The design of software architecture considers two levels of the design pyramid
a) data design
b) architectural design

Data design at the Architectural Level:

The challenge for a business has been to extract useful information from this data environment,
particularly when the information desired is cross functional.
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.

Data design at the Component Level:

Data design at the component level focuses on the representation of data structures that
are directly accessed by one or more software components. The following set of principles for
data specification:
 The systematic analysis principles applied to function and behavior should also be
applied to data. All data structures and the operations to be performed on each should be
identified. A data dictionary should be established and used to define both data and program
design. Low-level data design decisions should be deferred until late in the design process.
 The representation of data structure should be known only to those modules that must
make direct use of the data contained within the structure. A library of useful data structures and
the operations that may be applied to them should be developed. A software design and
programming language should support the specification and realization of abstract data types.

ARCHITECTURAL STYLES AND PATTERNS:

The builder has used an architectural style as a descriptive mechanism to differentiate the house
from other styles (e.g., A-frame, raised ranch, Cape Cod)

 The software that is built for computer-based systems also exhibits one of many
architectural styles. Each style describes a system category that encompasses A set of
components (e.g., a database, computational modules) that perform a function required by a
system.
 A set of connectors that enable ―communication, coordination’s and cooperation‖
among components; Constraints that define how components can be integrated to form the
system; and Semantic models that enable a designer to understand the overall properties of a
system by analyzing the known properties of its constituent parts.

An architectural pattern, like an architectural style, imposes a transformation the design of

architecture. However, a pattern differs from a style in a number of fundamental ways:

 The scope of a pattern is less broad, focusing on one aspect of the architecture rather than
the architecture in its entirety. A pattern imposes a rule on the architecture, describing how the
software will handle some aspect of its functionality at the infrastructure level.
 Architectural patterns tend to address specific behavioral issues within the context of the
architectural.

A Brief Taxonomy of Styles and Patterns Data-centered architectures:

A data store (e.g., a file or database) resides at the center of this architecture and is accessed
frequently by other components that update, add, delete, or otherwise modify data within the
store. A variation on this approach transforms the repository into a ―blackboard‖ that sends
notification to client software when data of interest to the client changes Data-centered
architectures promote integrability.
Data-flow architectures.
This architecture is applied when input data are to be transformed through a series of
computational or manipulative components into output data. A pipe and filter pattern has a set of
components, called filters, connected by pipes that transmit data from one component to the next.
Each filter works independently of those components upstream and downstream, is designed to
expect data input of a certain form, and produces data output of a specified form.

Object-oriented architectures.
The components of a system encapsulate data and the operations that must be applied to
manipulate the data. Communication and coordination between components is accomplished via
message passing.

Layered architectures.
The basic structure of a layered architecture is number of different layers are defined, each
accomplishing operations that progressively become closer to the machine instruction set. At the
outer layer, components service user interface operations. At the inner layer, components
perform operating system interfacing. Intermediate layers provide utility services and application
software functions.

Architectural Patterns:
An architectural pattern, like an architectural style, imposes a transformation the design of
architecture. However, a pattern differs from a style in a number of fundamental ways: The
scope of a pattern is less broad, focusing on one aspect of the architecture rather than the
architecture in its entirety.
The architectural patterns for software define a specific approach for handling some behavioral
characteristics of the system .

a) Concurrency—applications must handle multiple tasks in a manner that simulates parallelism

o operating system process management pattern o task scheduler pattern.

b) Persistence—Data persists if it survives past the execution of the process that created it. Two
patterns are common: a database management system pattern that applies the storage and
retrieval capability of a DBMS to the application architecture an application level persistence
pattern that builds persistence features into the application architecture.

c) Distribution— the manner in which systems or components within systems communicate

with one another in a distributed environment A broker acts as a ‗middle-man‘ between the
client component and a server component.

d) Organization and Refinement: The design process often leaves a software engineer with a
number of architectural alternatives, it is important to establish a set of design criteria that can be
used to assess an architectural design that is derived.

ARCHITECTURAL DESIGN:

At the architectural design level, a software architect uses an architectural context diagram
(ACD) to model the manner in which software interacts with entities external to its boundaries.
Superordinate systems – those systems that use the target system as part of some higher level
processing scheme.
Subordinate systems - those systems that are used by the target system and provide data or
processing that are necessary to complete target system functionality.
Peer-level systems - those systems that interact on a peer-to-peer basis .
Actors -those entities that interact with the target system by producing or consuming information
that is necessary for requisite processing.

Defining Archetypes:
An archetype is a class or pattern that represents a core abstraction that is critical to the design of
architecture for the target system. In general, a relative small set of archetypes is required to
design even relatively complex systems.
In many cases, archetypes can be derived by examining the analysis classes defined as part of the
analysis model. In safe home security function, the following are the archetypes:
Node: Represent a cohesive collection of input and output elements of the home security
function. For example a node might be comprised of (1) various sensors, and (2) a variety of
alarm indicators.

Detector: An abstraction that encompasses all sensing equipment that feeds information into the
target system
Indicator: An abstraction that represents all mechanisms for indication that an alarm condition
is occurring.
Controller: An abstraction that depicts the mechanism that allows the arming or disarming of a
node. If controllers reside on a network, they have the ability to communicate with one another.
Object And Object Classes Object :
An object is an entity that has a state and a defined set of operations that operate on that state. An
object class definition is both a type specification and a template for creating objects. It includes
declaration of all the attributes and operations that are associated with object of that class

Object Oriented Design Process:

There are five stages of object oriented design process
1)Understand and define the context and the modes of use of the system.
2)Design the system architecture
3)Identify the principle objects in the system.
4)Develop a design models
5) Specify the object interfaces Systems context and modes of use It specify the context of the
system.it also specify the relationships between the software that is being designed and its
external environment.

If the system context is a static model it describe the other system in that environment. If the
system context is a dynamic model then it describe how the system actually interact with the
environment.
The main advantage OOD approach is to simplify the problem of making changes to the design.
Changing the internal details of an object is unlikely to affect any other system object.

ARCHITECTURAL MAPPING USING DATA FLOW

There is no practical mapping for some architectural styles, and the designer must approach the
translation of requirements to design for these styles in using the techniques. To illustrate one
approach to architectural mapping, consider the call and return architecture—an extremely
common structure for many types of systems.

 The call and return architecture can reside within other more sophisticated architectures. For
example, the architecture of one or more components of a client-server architecture might be
call and return.
 A mapping technique, called structured design, is often characterized as a data flow-oriented
design method because it provides a convenient transition from a data flow diagram to
software architecture.
 The transition from information flow (represented as a DFD) to program structure is
accomplished as part of a six step process:
(1) the type of information flow is established,
(2) flow boundaries are indicated,
(3) the DFD is mapped into the program structure,
(4) control hierarchy is defined,
(5) the resultant structure is refined using design measures and heuristics, and
(6) the architectural description is refined and elaborated.

Transform Mapping: Transform mapping is a set of design steps that allows a DFD with
transform flow characteristics to be mapped into a specific architectural style.

 Step 1. Review the fundamental system model. The fundamental system model or context
diagram depicts the security function as a single transformation, representing the external
producers and consumers of data that flow into and out of the function. Figure depicts a level
0 context model, a shows refined data flow for the security function.
 Step 2. Review and refine data flow diagrams for the software.
Information obtained from the requirements model is refined to
produce greater detail. For example, the level 2 DFD for monitor
sensors is examined, and a level 3 data flow diagram is derived as shown
in figure . The data flow diagram exhibits relatively high cohesion.

 Step 3. Determine whether the DFD has transform or transaction flow

characteristics. Evaluating the DFD in the Figure , we see data
entering the software along one incoming path and exiting along
three outgoing paths. Therefore, an overall transform characteristic
will be assumed for information flow.

 Step 4. Isolate the transform center by specifying incoming and

outgoing flow boundaries. Incoming data flows along a path in which
information is converted from external to internal form; outgoing flow
converts internalized data to external form. Incoming and outgoing
flow boundaries are open to interpretation. That is, different designers
may select slightly different points in the flow as boundary locations.
Flow boundaries for the example are illustrated as shaded curves
running vertically through the flow in Figure 9.13. The transforms
(bubbles) that constitute the transform center lie within the two shaded
boundaries that run from top to bottom in the figure. An argument can
be made to readjust a boundary. The emphasis in this design step
should be on selecting reasonable boundaries, rather than lengthy
iteration on placement of divisions.

 Step 5. Perform “first-level factoring.” The program architecture

derived using this mapping results in a top-down distribution of
control. Factoring leads to a program structure in which toplevel
components perform decision making and low level components
perform most input, computation, and output work. Middle-level
components perform some control and do moderate amounts of work.
 Step 6. Perform “second-level factoring.” Second-level factoring is
accomplished by mapping individual transforms (bubbles) of a DFD
into appropriate modules within the architecture.