Introduction

SOFTWARE DESIGN & ARCHITECTURE

Outline
Software Development Phases
Software Process Models
Introduction to Software Design
Process of Design
Design Fundamental Concepts
Design Principles

2
Software Development
◦ Software lifecycle
◦ Defines all the software development phases, starting
from the requirements specification of the client, to
the final stages of software creation
◦ A software life cycle model (also called process
model)
◦ life cycle model represents all the activities required to
make a software product transit through its life cycle
phases
◦ It also captures the order in which these activities are
to be undertaken

3
Software Development
◦ The need for software life cycle model:-
◦ The development team must identify a suitable life cycle
model for the particular project and then adhere to it
◦ Without using of a particular life cycle model the
development of a software product would not be in a
systematic and disciplined manner
◦ So when a software product is being developed by a
team there must be a clear understanding among team
members about
◦ when and what to do, Otherwise it would lead to project
failure

4
Software Development Phases
◦ Phase of the software development:
◦ Requirements Analysis and Specification
◦ Design
◦ Coding
◦ Unit Testing, integration and System Testing
◦ Maintenance

5
Software Development Phases
◦ Activities in each phase of the life cycle:
◦ Requirements Analysis and Specification
◦ The aim of the requirements analysis and
specification phase is to understand the exact
requirements of the customer and to document
them properly
◦ This phase consists of two distinct activities,
namely
◦ Requirements gathering and analysis, and
◦ Requirements specification

6
Software Development Phases
◦ Requirement gathering is done to clearly
understand the customer requirements so that
incompleteness and inconsistencies are removed.
◦ After all ambiguities, inconsistencies, and
incompleteness have been resolved and all
◦ the requirements properly understood, the
requirements specification activity can start
◦ During this activity, the user requirements are
systematically organized into a Software
Requirements Specification (SRS) document

7
Software Development Phases
◦ Design
◦ The goal of the design phase is to transform the requirements
specified in the SRS
◦ document into a structure that is suitable for implementation in
some programming language
◦ Coding
◦ sometimes called the implementation phase
◦ The purpose of the coding is to translate the software design
into source code
◦ Each component of the design is implemented as a program
module
◦ The end-product of this phase is a set of program modules that
have been individually tested then proceeds for next stage

8
Software Development Phases
◦ Testing
◦ Unit testing During this phase, each module is unit tested to
determine the correct working of all the individual modules
◦ During the integration and system testing phase, the modules
are integrated in a planned manner
◦ Integration is normally carried out incrementally over a number
of steps
◦ During each integration step, the partially integrated system is
tested and a set of previously planned modules are added to it
◦ Finally, when all the modules have been successfully integrated
and tested, system testing is carried out
◦ The goal of system testing is to ensure that the developed
system conforms to its requirements laid out in the SRS
document
9
Software Development Phases
◦ Maintenance
◦ Maintenance involves performing any one or more of the
following three kinds of activities:
◦ Corrective maintenance
◦ Correcting errors that were not discovered during the product
development phase.
◦ Perfective maintenance
◦ Improving the implementation of the system, and enhancing the
functionalities of the system according to the customer’s
requirements
◦ Adaptive maintenance
◦ Porting the software to work in a new environment. For example,
porting may be required to get the software to work on a new
computer platform or with a new operating system

10
Software Process Models
◦ Waterfall
◦ Prototyping
◦ V-Model
◦ Spiral
◦ RAD
◦ Agile

11
Software Design
◦ Design is a meaningful representation of
something that is to be built
◦ It can be traced to a customer’s requirements
and at the same time assessed for quality
against a set of predefined criteria for “good”
design
◦ In the software engineering context, design
focuses on four major areas of concern: data,
architecture, interfaces, and components

12
Software Design: Why?
◦ You wouldn’t attempt to build a house
without a blueprint, would you?
◦ You’d risk confusion, errors, a floor plan that
didn’t make sense, windows and doors in the
wrong place . .. a mess
◦ Computer software is considerably more
◦ complex than a house; hence, we need a
blueprint—the design

13
Software Design: Steps?
◦ Design begins with the requirements model
We work to transform this model into four
levels of design detail: the data structure,
◦ the system architecture, the interface
representation, and the component level
detail
◦ During each design activity, we apply basic
concepts and principles that lead to high
quality

14
Software Design: work product?
◦ Ultimately, a Design Specification is produced
◦ The specification is composed of the design
models that describe data, architecture,
interfaces, and components
◦ Each is a work product of the design process
◦ At each stage, software design work
products are reviewed for clarity,
correctness, completeness, and consistency
with the requirements

15
Software Design
◦ 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 of the elements of the analysis model provides
information that
◦ is necessary to create the four design models required
for a complete specification of
◦ design

16
Software Design
◦ 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

17
Software Design
◦ 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

18
Software Design
◦ The interface design describes how the
software communicates within itself
◦ With systems that interoperate with it, and
with humans who use it
◦ Therefore, data and control flow diagrams
provide much of the information required for
◦ interface design

19
Software Design
◦ The component-level design transforms structural elements of
the software architecture into a procedural description of software
components
◦ During design we make decisions that will ultimately affect the
success of software construction
◦ and the ease with which software can be maintained
◦ why is design so important?
◦ 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

20
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
◦ 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
21
The Design Process
◦ Design and Software Quality
◦ The 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
22
Design Principles
◦ Developing design is a cumbersome process as most expansive
errors are often introduced in this phase
◦ Moreover, if these errors get unnoticed till later phases, it
becomes more difficult to correct them
◦ a number of principles are followed while designing the software
◦ These principles act as a framework for the designers to follow
a good design practice.
◦ Some of the commonly followed design principles are as
following
◦ Software design should correspond to the analysis
model:
◦ Often a design element corresponds to many requirements,
therefore, we must know how the design model satisfies all the
requirements represented by the analysis model

23
Design Principles
◦ Software design should represent
correspondence to real-world problem: The
software design should be structured in such away
that it always relates with the real-world problem
◦ The design should exhibit uniformity and
integration
◦ A design is uniform 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
24
Design Principles
◦ Software design should be structured to degrade
gently:
◦ Software should be designed to handle unusual changes and
circumstances, and if the need arises for termination, it must
do so in a proper manner so that functionality of the software is
not affected
◦ Software design should be flexible: Software design should
be flexible enough to adapt changes easily.
◦ 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
25
Design Principles
◦ The design should be assessed for quality
as it is being created,
◦ A variety of design concepts and design
measures are available to assist the designer in
assessing quality
◦ The design should be reviewed to minimize
conceptual (semantic) errors
◦ 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
26
Design Fundamental Concepts
◦ Abstraction
◦ Allows designers to focus on solving a problem without
being concerned about irrelevant lower level details
◦ Procedural Abstraction: named sequence of events
◦ Data Abstraction: named collection of data objects
◦ Architecture
◦ Software architecture refers to the structure of the
system, which is composed of various components of a
program/ system, the attributes (properties) of those
components and the relationship amongst them

27
Design Fundamental Concepts
◦ Patterns
◦ A pattern provides a description of the solution to a recurring
design problem of some specific domain in such a way that the
solution can be used again and again.
◦ A design pattern describes a design structure and that structure
solves a particular design problem in a specified content.
◦ Modularity
◦ Modularity is achieved by dividing the software into uniquely
named and addressable components, which are also known as
modules.
◦ Note that larger the number of modules a system is divided into,
greater will be the effort required to integrate the modules.

28
Design Fundamental Concepts
◦ Information Hiding
◦ Modules must be specified and designed so that the
information like algorithm and data presented in a module is
not accessible for other modules not requiring that information
◦ the way of hiding unnecessary details is referred to as
information hiding.
◦ Functional independence
◦ The functional independence is the concept of separation and
related to the concept of modularity, abstraction and
information hiding.
◦ The functional independence is accessed using two criteria i.e.
Cohesion and coupling.

29
Design Fundamental Concepts
◦ Cohesion
◦ Degree to which a module performs one and only one function
◦ All elements of component are directed toward performing the same
task
◦ Coupling
◦ Degree to which a module is connected to other modules in the
system
◦ In software design, stive for lowest possible coupling and
High cohesion
◦ 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 propagate
throughout the system

30
Design Fundamental Concepts
◦ Stepwise Refinement
◦ Stepwise refinement is a top-down design strategy used for
decomposing a system from a high level of abstraction into a more
detailed level (lower level) of abstraction.
◦ As we proceed towards the lower levels of abstraction, more and
more details are available.
◦ Refactoring
◦ Refactoring can be defined as a process of modifying a software
system to improve the internal structure of design without changing
its external behavior.
◦ Software designers may decide to refactor the component into four
different components, each exhibiting high cohesion. This leads to
easier integration, testing, and maintenance of the software
components.

31