Unit - 4

Design Engineering
4.1 Concept of Design
• Definition:
Software design is model of software which translates the
requirements into finished software product in which the details about
the software data structure, architecture, interfaces and components
that are necessary to implement the system are given.

• Software design is an iterative process using which the user

requirement can be translated into the s/w product.
Characteristics of Good design

• The good design should implement all the requirements specified by

the customer.
• The design should be simple so that the s/w can be understood easily
by the developer, testers and customers.
• The design should be comprehensive. That means it should provide
complete picture of the s/w.
4.1.1 Design with the context of
s/w engineering
• S/w design is at the core of s/w engineering, and it is applied
irrespective of any process model.
• After analyzing and modeling the requirements, s/w design is done
with serves as the basis for code generation and testing.
• s/w designing is a process of translating analysis model into the
design model.
Elements of the Requirement Model
• Following are the elements of analysis model –
1. Scenario Based element
2. Class based elements
3. Behavioral elements
4. Flow Model

Figure illustrates the elements of analysis model.

Translating analysis model to design model

Fig: Translating analysis model to design model

• Architectural design : it defines the relationship between major
structural elements of the s/w.
• Interface design: it describes how s/w communicates with systems.
These systems are interfacing with each other as well as with the
human who operate them.
• Thus interface design represents the flow of information and specific
type of behavior.
• Component level design: This design transforms structural elements
of s/w architecture into procedural description of s/w module.
• The information used by the component design is obtained from class
based model, flow based model and behavioral model.
• Class diagrams represents how to put various object together.
• These objects are categorized into classes.
• A class diagram give overview of a system, in which various classes
and relationship among these classes is represented.

• Software design is important to assess the quality of s/w. because

design is only way that we can accurately translate the user
requirements into the finished s/w product.
4.2 The design process
• Software design is an iterative process in which the requirements are
translated into the blueprint of the s/w.
• Initially s/w is represented at high level of abstraction , but during the
subsequent iterations data, functional and behavioral requirements
are traced in more detail.
• Thus refinement made during each iteration leads to design
representations at much lower level of abstraction.
• Throughout the s/w design process the quality of the s/w is assessed
by considering certain characteristics of the s/w design.
4.3 Software quality guidelines
and attributes
• The goal of any s/w design is to produce high quality s/w.
• The quality guidelines are as follows-
1. The design architecture should be created using following issues-
The design should be created using architectural styles and patterns.
Each component of design should process good design
characteristics.
The implementation of design should be evolutionary, so that testing
can be performed at each phase of implementation.
2. In the design the data, architecture, interfaces and components
should be clearly represented.
3. The design should be modular . That means the subsystems in the
design should be logically partitioned.
4. The data structure should be appropriately chosen for the design of
specific problem.
5. The components should be used in the design so that functional
independency can be achieved in the design.
6. Using information obtained in s/w requirement analysis the design
should be created.
7. The interfaces in the design should be such that the complexity
between the connected components of the system gets reduced.
similarly interface of the system with external interface should be
simplified one.
8. Every design of the software system should convey its meaning
approximately and effectively.

• Quality attributes:
• The design quality attributes popularly known as FURPS(Functionality,
Usability, Reliability, Performance and Supportability) is a set of
criteria developed by Hewlett and Packard.
• Table represent meaning of each quality attribute.
4.4 Design concept
• Software design concept provides a framework for implementing the right
software.
• Following are certain issues that are considering while designing the software-
 Abstraction
Architecture
Pattern
Modularity
Refinement
Information hiding
Functional independence
Refactoring
Design classes
4.4.1 Abstraction

• Abstraction means ability to cope up with the complexity.

• Software design occurs at different levels of abstractions. At each
stage of s/w design process level of abstraction should be applied to
refine the s/w solution.
• At the highest level of abstraction , the solution must be stated in
broad terms and in the lower level more detailed description of the
solution is given.
4.4.2 Architecture

• Architecture means representation of overall structure of an integreted system.

• In architecture varios component interact and the data structure is used by various
component.
• Architecture provides the basic framework for the sytem so that important activites
can be conducted in systematic manner.

• In architectural design various system model can be used ,Some of the Architecture
models are described below-

 Structural models – overall architecture of the system can be represented using this
model.
Framework models – shows architecture framework and corresponding applicability.
Dynamic models – indicate how program structure changes as a
function of external events .
Process models – focus on the design of the business or technical
process that system must accommodate .
 Functional models – used to represent system functional hierarchy.
4.4.3 Patterns

• General reusable solution which can be used again and again.

• Software engineer can use the design pattern during the entire
software design process.
• Each pattern is to provide an insight to a designer who can determine
the following-
Whether the pattern can be reused
Whether the pattern is applicable to the current project.
Whether the pattern can be used to develop a similar but functionally
or structurally different design pattern.
4.4.4 Modularity

• Software is divided into separately named and addressable

components, often called modules, that are integrated to satisfy
problem requirements.
• This leads to a "divide and conquer“’ it's easier to solve a complex
problem when you break it into manageable pieces.
• It has been stated that "modularity is the single attribute of software
that allows a program to be intellectually manageable“.
• Modular decomposability: A design method provides a systematic
mechanism for decomposing the problem into sub-problems --
>reduce the complexity and achieve the modularity.
• Modular composability: A design method enables existing design
components to be assembled into a new system.

• Modular understandability: A module can be understood as a

standalone unit it will be easier to build and easier to change.

• Modular continuity: A small changes to the system requirements

result in changes to individual modules, rather than systemwide
changes.

• Modular protection: An aberrant condition occurs within a module

and its effects are constrained within the module.
• Figure provides useful guidlines for the modularity -
• Overmodularity and undermodurality while developing the software
product must be avoided.
• We should modulized the software but the modularity must remain
near the region denoted by M.

Fig. Modularity and s/w cost

4.4.5 Information Hiding
• The way of hiding the unnecessary details
• Information (data and procedure) contained within a module should
be inaccessible to other modules that have no need for such
information.
• Hiding defines and enforces access constraints to both procedural
detail within a module and any local data structure used by the
module
• Due to information hiding data and procedure of one module can be
hidden from another module. This ultimately avoids introduction of
errors module one module to another.
4.4.6 Functional Independence

• Achieved by developing modules with “single minded” approach and

low coupling.
• Functional independence is achieved by developing a module to
perform given set of functions without interacting with other parts of
the system.
• It can be measured using two criteria:
-Cohesion
-Coupling
• Design modules based on independent functional features.
4.4.6.1 Cohesion:
• With the help of cohesion the information hiding can be done.
• Cohesive module can perform only “one task” in s/w procedure with little
interaction with other modules. In other word cohesion module can perform
only one thing.

• Types of cohesion:

Communication cohesion : Processing elements of module share a data

Procedural cohesion: Processing elements of module are related with one
another and must be executed in specific order.
Temporal cohesion: task need to be executed in specific time.
Logical cohesion: task thar are logically related to one another.
Coincidental cohesion: set of task are related with each other loosly
4.4.6.1 Coupling:
coupling effectively represents how the modules can be “connected”
with other module or with outside world.

• A measure of interconnection/interdependence among modules in a

program structure.
• Coupling depends on the interface complexity between modules.

• Types of coupling:

Data coupling : passing parameter or data interaction.

Control coupling : the moduled share related control logical data
(control flag).

Common coupling : data or global is shared amongthe modules.

 content coupling : module makes the use of data or control

information maintained in another module.
4.4.7 Refinement

• Refinement is a process of elaboration.

• Stepwise refinement is a top-down design strategy.
• It begin with a statement of function (or description of information)
that is defined at a high level of abstraction and reach at the lower
level of abstraction.
• Terminates when all instructions are expressed in terms of any
underlying computer or programming language.
• Abstraction and refinement are complementary concepts.
4.4.8 Refactoring
• changing the structure of a program so that the functionality is not
changed”.
• Refactoring is a reorganization technique that simplifies the design (or
internal code structure) of a component without changing its function
or external behaviour.
• It removes redundancy, unused design elements, inefficient or
unnecessary algorithms, poorly constructed or inappropriate data
structures, or any other design failures.
4.5 Object Oriented Design
concepts
• Object is an important element of an Object Oriented Design(OOD).
• Various objects and their interaction with each other objects is
graphically represented in object oriented design.
• “Design system using self-contained objects and object classes”.
• Objects are abstractions of real world or system entities and manage
themselves.
• Objects are independent and encapsulate state and represent
information.
• System functionality is expressed in terms of object services.
Advantages of object oriented system:
• Reusability of objects reduces programming efforts.
• The system design is more manageable if it is done using object
oriented approach.
• Error detection and handling is easy.
• Changes can be incorporated very easily in the s/w system.

Disadvantages of object oriented system:

• These system are very slow.
• These system require more memory.
4.6 Design classes
• Design classes are defined as the classes that describe some elements
of problem domain, focus on various aspects problems from users
point of view.
• The requirements model defines a set of analysis classes.
• Set of design classes that refine the analysis classes by providing
design detail. So that further implantation can be done easily.
• To create new set of classes for implementing the infrastructure of
the software .
• There are five different types of design classes.
1. User interface class:
• It defines all the abstraction that are necessary for human computer
interface(HCI).this class is basically visual representation of the HCI.

2. Business domain class:

• These classes are refinement of analysis classes.
• These classes identify the attributes and services that are needed to
implement some elements of business domain

3. Process class:
• It implement lower level business abstraction used by the business
domain.
4. Persistent class:
• These classes represents the data such as databases which will be
retained as it is even after the execution of the s/w.

5. System class:
• These classes are responsible for s/w management and control
functions that are used for system operation.
4.7 Design model and Elements
• The process dimensions denotes that the design model evolutes due
to various software tasks that get executed as the part of s/w process.
• The abstract dimensions represents level of details as each element of
analysis model is transformed into design equivalent.
• In fig. dimensions of design model the dashed line shows boundary
between analysis and design model.
• In both the analysis and design model the same UML diagrams are
used but in analysis model the UML diagrams are abstract and in
design model these diagrams are refined and elaborated.
• In design model the implementation specific details are provided.
Dimensions of design model
• Design Model Elements

Data Design Elements

Architectural Design Elements
Interface Design Elements
Component-Level Design Elements
Deployment-Level Design Elements
4.7.1 Data design elements
• The data design represents the high level of abstraction.
• This data represented as data design level is refined gradually for
implementing the computer based system.
• The data has great impact on architecture of s/w system. Hence
structure of data is very important factor in s/w design.
• Data appears in the form of data structure and algorithm at the
program component level.
• At the application level it appears as the database and at the business
level it appears as data warehouse and data mining. thus data plays
an important role in s/w engineering.
4.7.2 Architectural Design
Elements
• The architectural model is derived from three sources:

Information about the application domain for the software to be built

Specific requirements model elements such as data flow diagrams of
analysis classes, their relationship and collaborations for the problems
at hand.
The availability of architectural patterns and styles.
4.7.3 Interface Design Elements
• Interface design represents the detailed design of the s/w system.
• In interface design how information flows from one component to
other component of the system is depicted.
• There are three important elements of interface design:
User interface (UI): user interacts with system(GUI).
External interfaces to other systems, devices, networks, or other
producers or consumers of information
Internal interfaces between various design components
4.7.4 Component-level Design
Element
• The component-level design for software fully describes the internal
detail of each software component.
• 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.
• Fig represents that component order makes use of another component
form.
• The order is dependent upon the component form.
• These two objects can be interfaced with each other.
4.7.5 Deployment level design elements

• Deployment-level design elements indicate how software

functionality and subsystems will be allocated within the physical
computing environment that will support the software.
Fig: Deployment diagram
4.8 Component level design for
web Apps
• Following are some tasks of modern web application-
1.Carry out various processing activities for generating the web
contents.
2.Improve navigation capability in dynamic order.
3.Establish data interfaces with external corporate system.
4.Provide computation or data processing capabilities.
5.Provide the mechanism for database query processing and handling.
• These tasks can be accomplished by designing and constructing the
program components that are identical in the form to s/w component
for conventional s/w.
4.8.1 Content design at the component level

• During the content design at the component level , the focus is on

two things- 1. content object ,2. the way content objects are
packaged for presentation to the end user.
• At the component level content design need to focus on the
characteristics of the WebApps.
• It is necessary to organize the contents in such a way that the design
manipulation and reference could be easier.
• If the contents are highly dynamic , it becomes important to establish
a clear structural model that incorporates content components.
4.8.2 functional design at the component level

• Modern web applications provide various useful functionalities such

as-
1.Processing of contents and navigation in dynamic fashion.
2.Performing computation or data operations dynamically.
3.Efficient query processing and access to database.
4.Establishing data interfaces with external corporate systems.
• To achieve this functionalities, it is necessary to design and construct
the functional components of web applications.
• The web contents and above mentioned functionalities are combined
to create functional architecture.
• A functional architecture is a representation of the functional domain
of the web applications and describes the key functional components
in the web application and how these components interact with each
other.
4.9 Architecture Design
• The architectural design process for identifying the subsystem making
up the system and framework for subsystem control and
communication.
• The goal of architectural design is to establish the overall structure of
s/w system.
• Architectural design represents the link between design specifications
and actual design process.
• S/w architecture is a structure of systems which consists of various
components , externally visible properties of these components and
the inter-relationship among these components.
4.9.2 why is architecture
important?
• There are three reasons why the s/w architecture is important?
S/w architecture gives the representation of the computer-based
system that is to be built. Using this system model even the
stakeholders can take active part in the s/w development process.
This helps in clear specification /understanding of requirements.
Some early design decisions cab be taken using s/w architecture and
hence system performance and operations remain under control.
The s/w architecture gives a clear-cut idea about the computer-based
system which is to be built.
4.9.3 structural partitioning
• The program structure can be partitioned horizontally or vertically.
• Horizontal partitioning:
• It defines separate branches of the modular hierarchy for each major
program function.
• Horizontal partitioning can be done by partitioning system into :Input,
data transformation(processing) and output.
• In horizontal partitioning the design making modules are at the top of
the architecture.
Horizontal partitioning

Fig: Horizontal partitioning

• Advantages of horizontal partition
These are easy to test , maintain and extend.
They have fewer side effects in change propagation or error
propagation.

• Disadvantages of horizontal partition

More data has to be passed across module interfaces which
complicate the overall control of program flow.
Vertical partitioning:

• Vertical partitioning suggest the control and work should be

distributed top-down in program structure.
• In vertical partitioning
Define separate branches of the module hierarchy for each major
function.
Use control modules to coordinate communication between function.
Fig: Vertical partitioning
• Advantages of vertical partitioning:

These are easy to maintain changes

They reduce the change impact and error propagation
4.10 Architectural Styles
Architectural styles:
• Architectural model or style is a pattern for creating the system architecture
for given problem.
• However most of the large systems are heterogeneous and do not follow
single architectural style.
• System categories defines the architectural style
1. components: they performs a function.
Eg. database , simple computational modules, clients, servers and filters.
2. Connectors: enables communications. They define how the components
communicate , coordinate and cooperate.
Eg.call , event broadcasting , pipes
3. constraints: defines how the system can be integrated.

4. Semantic model: specify how to determine a system’s overall

properties from the properties of its parts.

• Commonly used architectural styles are-

Data centered architecture
Data flow architecture
Call and return architecture
Object oriented architecture
Layered architecture
Data centered architecture:

• In this architecture data store lies at the center of the architecture

and other components frequently access it by performing add, delete
and modify operations.
• The client s/w requests for the data to central repository.
• Sometime the client s/w accesses the data from the central repository
without any change in data or actions of s/w action.
• Data centered architecture posses the property of interchangeability.
• It means any component from the architecture can be replaced by a
new component without affecting the working of other components.
Fig: data centered architecture
• In data centered architecture –

Components are -database elements such as tables, queries

Communications are- by relationship.
Constraints are- client s/w has to request central data store for
information.
Data flow architecture
• In this architecture series of transformations are applied to produce
output data.
• The set of components called filters are connected by pipes to
transform the data from one component to another
• These filters works independently without a bothering about working
of neighboring filters.
• Pipes are used to transmitting data from one component to the next.
Fig: pipes and filters
• If data flow degenerates into a single line of transforms, it is termed
as batch sequential.

Fig: batch sequential

Call and return architecture:

• In this architecture the hierarchical control for call and return is

represented.
• It is used to create a program that is easy to scale and modify.
• This form of architecture improves scalability by allowing us to design
scalable and easy-to-modify program structures.
• The program is broken down into smaller components and organized
in a hierarchical fashion.
• The main program, which is separated into subprograms in the
hierarchy, invokes several software components.
Fig: Call and return architecture:
Object oriented architecture
• In this architecture system is decomposed into number of interacting
objects.
• These objects encapsulates data and the corresponding operations
that must be applied to manipulate the data.
• The object-oriented decomposition is concerned with identifying
objects classes, their attributes and the corresponding operations.
• There is some control models used to coordinate the object
operations.
• The coordination and communication between the components are
established via the message passing.
Fig: object-oriented architecture
Layered architecture
• The layered architecture is composed of different layers.
• Each layer is intended to perform specific operations so machine
instruction set can be generated.
• Various components on each layer perform specific operations
• The outer layer is responsible for performing the user interface
operations while the components in the inner layer perform operating
system interfaces.
• The component in intermediate layer performs utility services and
application s/w functions.