What is Design?

Design is the first step in the development phase for any engineered product or system.
Design is about HOW the system will perform its functions.
Software Design:
A software design is a meaningful engineering representation of some software product that
is to be built.
The process of applying various techniques and principles for the purpose of defining a device,
a process or a system in sufficient detail to permit its physical realization”
As one of the most complex man-made artifacts, computer software is very difficult to design.
There are many factors that affect designs and many stakeholders, i.e. people who participate
in the design process, play various different roles in the design processes and influence the
design of software.
Software Design – Simplified:
Requirements specification was about the WHAT the system will do. Design is about the HOW
the system will perform its functions.

 provides the overall decomposition of the system

 allows to split the work among a team of developers
 also lays down the groundwork for achieving non-functional requirements
(performance, maintainability, reusability, etc.)
 takes target technology into account (e.g., kind of middleware, database design, etc.)
Why Design is important?
Without a proper 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, perhaps when
critical deadlines are approaching and much capital has already been invested into the
product.
Purpose of Design:
Design is where customer requirements, business needs, and technical considerations all
come together in the formulation of a product or system.
The design model provides detail about the software data structures, architecture,
interfaces, and components.
The design model can be assessed for quality and be improved before code is generated and
tests are conducted.
Major Design Challenges:

 Design team should not do too much

Detailed design should not become code

 Design team should not do too little

It is essential for the design team to produce a complete detailed design
Software Development Activities:
Requirements Elicitation
Requirements Analysis
(e.g., Structured Analysis, OO Analysis)
analyzing requirements and working towards a conceptual model without taking the target
implementation technology into account
useful if the conceptual gap between requirements and implementation is large
part of requirements engineering (but may produce more than what is going to be part of the
requirement spec)
Design
coming up with solution models taking the target implementation technology into account
Implementation
Testing
Software Design in SDLC
In SDLC (Software Development Life Cycle), Design phase is one of the most important phases.
In the software engineering context, design focuses on four major areas of concern:
Data, Architecture, Interfaces, Components.
Design Process Activities:
Architectural design: Modules, inter-relationships etc
Abstract specification: Services of each sub-system, constraints etc
Interface design: Interface to other sub-system or outside environment
Component design: Services allocated to components and their interfaces designed
Data structure design
Algorithm design
The Software Design Process:

Levels of Software Design:

Architectural design (high-level design)
architecture - the overall structure, main modules and their connections
addresses the main non-functional requirements (e.g., reliability, performance)
hard to change
Detailed design (low-level design)
the inner structure of the main modules
detailed enough to be implemented in the programming language
Design vs. Architecture:

 Architecture is concerned with the selection of architectural elements, their

interaction, and the constraints on those elements and their interactions
 Design is concerned with the modularization and detailed interfaces of the design
elements, their algorithms and procedures, and the data types needed to support the
architecture and to satisfy the requirements.
 Architecture…is specifically not about…details of implementations (e.g., algorithms
and data structures.)
Design:
Design model elements are not always developed in a sequential fashion
Preliminary architectural design sets the stage
It is followed by interface design and component-level design, which often occur in parallel
The design model has the following layered elements
Data/class design, Architectural design, Interface design, Component-level design
A fifth element that follows all of the others is deployment-level design.
Design Elements:
Data/class design: Creates a model of data and objects that is represented at a high level of
abstraction
Architectural design: Depicts the overall layout of the software
Interface design: Tells how information flows into and out of the system and how it is
communicated among the components defined as part of the architecture
Includes the user interface, external interfaces, and internal interfaces.
Component-level design elements: Describes the internal detail of each software component
by way of data structure definitions, algorithms, and interface specifications
Deployment-level design elements: Indicates how software functionality and subsystems will
be allocated within the physical computing environment that will support the software
From Analysis Model to Design Model:
Task Set for Software Design:
1. Examine the information domain model and design appropriate data structures for
data objects and their attributes
2. Using the analysis model, select an architectural style (and design patterns) that are
appropriate for the software
3. Partition the analysis model into design subsystems and allocate these subsystems
within the architecture
a. Design the subsystem interfaces
b. Allocate analysis classes or functions to each subsystem
4. Create a set of design classes or components
a. Translate each analysis class description into a design class
b. Check each design class against design criteria; consider inheritance issues
c. Define methods associated with each design class
d. Evaluate and select design patterns for a design class or subsystem
5. Design any interface required with external systems or devices
6. Design the user interface
7. Conduct component-level design
a. Specify all algorithms at a relatively low level of abstraction
b. Refine the interface of each component
c. Define component-level data structures
d. Review each component and correct all errors uncovered
8. Develop a deployment model
Show a physical layout of the system, revealing which components will be located
where in the physical computing environment.
Design Quality:
The importance of design is quality
Design is the place where quality is fostered

 Provides representations of software that can be assessed for quality

 Accurately translates a customer's requirements into a finished software product or
system
 Serves as the foundation for all software engineering activities that follow.
Without design, we risk building an unstable system that

 Will fail when small changes are made

 May be difficult to test
 Cannot be assessed for quality later in the software process when time is short and
most of the budget has been spent
Goals of a Good Design:
1. The design must implement all of the explicit requirements contained in the analysis
model
It must also accommodate all of the implicit requirements desired by the customer
2. The design must be a readable and understandable guide for those who generate
code, and for those who test and support the software.
3. The design should provide a complete picture of the software, addressing the data,
functional, and behavioral domains from an implementation perspective.

Design Principles:
1- 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 resources available to do the job, and the design concepts.
2- The design should be traceable to the analysis model.
3- The design should not reinvent the wheel.
Systems are constructed using a set of design patterns. 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.
4- The design should “minimize the intellectual distance” between the software and the
problem as it exists in the real world.
5- The design should exhibit uniformity and integration.
6- The design should be reviewed to minimize conceptual (semantic) errors
7- Design is not coding, coding is not design
Even when detailed designs are created for program components, the level of abstraction of
the design model is higher than source code.
8- The design should be structured to accommodate change
9- The design should be assessed for quality as it is being created.
Design Concepts:
Fundamental Concepts:
abstraction—data, procedure, control
refinement—elaboration of detail for all abstractions
modularity—compartmentalization of data and function
architecture—overall structure of the software Structural properties, Extra-structural
properties, Styles and patterns
Procedure—the algorithms that achieve function
Hiding—controlled interfaces.

EFFECTIVE MODULAR DESIGN:

Functional Independence:
Cohesion: The Degree to which a module performs one and only one function.
Coupling: The degree to which a module is connected to other module in the system.
Coupling:
Coupling is a measure of independence of a module or component.
Loose coupling means that different system components have loose or less reliance upon
each other.
Hence, changes in one component would have a limited effect on other components.
Cohesion:
Cohesion is a measure of the degree to which the elements of the module are functionally
related.
It is the degree to which all elements directed towards performing a single task are contained
in the component.
Basically, cohesion is the internal glue that keeps the module together.
A good software design will have high cohesion.
Coupling and Cohesion Example:
A good example of a system with a very high cohesion and very less coupling is the electric
subsystem of a house that is made up of electrical appliances and wires.
A Software should be Lesly coupled and highly cohesive.
Objectives of Software Tester:

 Find bugs as early as possible and make sure they get fixed
 Study the functionality in detail to find where the bugs are likely to occur.
 Study the code to ensure that each and every line of code is tested.
 Create test cases in such a way that testing is done to uncover the hidden bugs and
also ensure that the software is usable and reliable
Objectives of testing:

 Executing a program with the intent of finding an error

 To check if the system meets the requirements and be executed successfully in the
Intended environment
 To check if the system is “ Fit for purpose”
 To check if the system does what it is expected to do
 A good test case is one that has a probability of finding an as yet undiscovered error
Verification & Validation:
Verification:
Does the product meet system specifications?
Have you built the product right?
Validation:
Does the product meet user expectations?
Have you built the right product?
Verification (Are the algorithms coded correctly?)
The set of activities that ensure that software correctly implements a specific function or
algorithm. Involves reviews and meeting to evaluate documents, plans, code, requirements,
and specifications. Usually done with checklists, walkthroughs, and inspection meeting.
Validation (Does it meet user requirements?)
The set of activities that ensure that the software that has been built is traceable to customer
requirements. Involves actual testing and takes place after verifications are completed.
Validation and Verification process continue in a cycle till the software becomes defects free.
Testing levels:
Unit testing, Integration testing, System testing, and Acceptance testing.
Unit testing:
The most ‘micro’ scale of testing.
Tests done on particular functions or code modules.
Requires knowledge of the internal program design and code.
Done by Programmers (not by testers).

Incremental integration testing:

Continuous testing of an application as and when a new functionality is added.
Application’s functionality aspects are required to be independent enough to work separately
before completion of development. Done by programmers or testers.
Integration Testing:
Testing of combined parts of an application to determine their functional correctness.
‘Parts’ can be

 code modules
 individual applications
 client/server applications on a network.
Integration Testing:

System Testing:
Systems Integration Testing:

Acceptance Testing:
TESTING METHODOLOGIES AND TYPES:
Black box testing, White box testing
Black box testing:
No knowledge of internal design or code required.
Tests are based on requirements and functionality.
Not based on any knowledge of internal design or code.
Covers all combined parts of a system.
Tests are data driven.
It uncovers: Incorrect or missing functions, Interface errors, Errors in data structures or
external database access, Performance errors, Initialization and termination errors.
Equivalence Partitioning:
Input data and output results often fall into different classes where all members of a class are
related.
Each of these classes is an equivalence partition or domain where the program behaves in an
equivalent way for each class member.
Test cases should be chosen from each partition.
Black-box technique divides the input domain into classes of data from which test cases can
be derived.
Boundary Value Analysis:
Black-box technique:
Focuses on classes and also on the boundaries of the input domain.
Guidelines:
1. If input condition specifies a range bounded by values a and b, test cases should
include a and b, values just above and just below a and b
2. If an input condition specifies a number of values, test cases should exercise the
minimum and maximum numbers, as well as values just above and just below the
minimum and maximum values.

Types of black box testing: Functional testing, System testing, End-to-end testing, Sanity
testing, Regression testing, Acceptance testing, Load testing, Stress testing, Install/uninstall
testing, Recovery testing, Compatibility testing, Exploratory testing, Comparison testing,
Alpha testing, Beta testing, Mutation testing.
Types of black box testing:
Functional testing
Black box type testing geared to functional requirements of an application.
System testing
Black box type testing that is based on overall requirements specifications; covering all
combined parts of the system.
End-to-end testing
Similar to system testing; involves testing of a complete application environment in a situation
that mimics real-world use.
Sanity testing
Initial effort to determine if a new software version is performing well enough to accept it for
a major testing effort.
Regression testing
Re-testing after fixes or modifications of the software or its environment.
Acceptance testing
Final testing based on specifications of the end-user or customer.
Load testing
Testing an application under heavy loads.
Eg. Testing of a web site under a range of loads to determine, when the system response time
degraded or fails.
Stress Testing
Testing under unusually heavy loads, heavy repetition of certain actions or inputs, input of
large numerical values, large complex queries to a database etc.
Term often used interchangeably with ‘load’ and ‘performance’ testing.
Performance testing
Testing how well an application complies to performance requirements.
Install/uninstall testing
Testing of full, partial or upgrade install/uninstall process.
Recovery testing
Testing how well a system recovers from crashes, HW failures or other problems.
Compatibility testing
Testing how well software performs in a particular HW/SW/OS/NW environment.
Exploratory testing / ad-hoc testing
Informal SW test that is not based on formal test plans or test cases; testers will be learning
the SW in totality as they test it.
Comparison testing
Comparing SW strengths and weakness to competing products.
Alpha testing
Testing done when development is nearing completion; minor design changes may still be
made as a result of such testing.
Beta-testing
Testing when development and testing are essentially completed and final bugs and problems
need to be found before release.
Mutation testing
To determining if a set of test data or test cases is useful, by deliberately introducing various
bugs. Re-testing with the original test data/cases to determine if the bugs are detected.
White box testing / Structural testing:

 Based on knowledge of internal logic of an application's code

 Based on coverage of code statements, branches, paths, conditions.
 Tests are logic driven.
It ensures:

 All independent paths within a module have been exercised at least once
 Exercise all logical decisions on their true and false sides
 Execute all loops at their boundaries and within their operational bounds
 Exercise internal data structures to ensure their validity.
Coverage:
Statement Coverage:
In this scheme, statements of the code are tested for a successful test that checks all the
statements lying on the path of a successful scenario.
Branch Coverage:
In this scheme, all the possible branches of decision structures are tested. Therefore,
sequences of statements following a decision are tested.
Path Coverage:
In path coverage, all possible paths of a program from input instruction to the output
instruction are tested. An exhaustive list of test cases is generated and tested against the
code.
Path testing – Control Flow Graph:
Program flow graph
Basic Control Flow Graphs

Bubble Sort Flow Graph:

Incremental Testing:
A disciplined method of testing the interfaces between unit-tested programs as well as
between system components.
Involves adding unit-testing program module or component one by one, and testing each
result and combination.
Thread testing:
When testers focus on testing individual Logical execution paths in context of entire system
Each Thread has a status associated with it for a particular build.
Types of incremental testing:
Top-down
Testing form the top of the module hierarchy and work down to the bottom. Modules are
added in descending hierarchical order.
Bottom-up
Testing from the bottom of the hierarchy and works up to the top. Modules are added in
ascending hierarchical order.
Testing levels and techniques applied:
“How do we measure the software?”:
To indicate the quality of the product
To assess the productivity of the people who produce the product
To assess the benefits derived from new software engineering methods and tools.
Definitions:
Measure - quantitative indication of the extent, amount, dimension, capacity, or size of
some attribute of a product or process.
Measurement - the act of determining a measure
Metric - a quantitative measure of the degree to which a system, component, or process
possesses a given attribute (IEEE).
Why Metrics?
Definition of measurable criterions to distinguish „good“ from „bad“ design
Goal: good software design low costs
small testing effort
low maintenance costs
Non-OO Metrics:
1-Size Metrics
2-Structure Metrics (Complexity Metrics)
Size Metrics:
1. Lines of Code (LOC)
Advantages

 easy to compute
 applicable to all kinds of programs
Disadvantages

 different possible counting methods

 language and programmer dependent
 no implications about maintainability or complexity
2-Structure Metrics:
McCabe’s Complexity Metric:
McCabe’s cyclomatic number, introduced in 1976, is, after lines of code, one of the most
commonly used metrics in software development.
The cyclomatic complexity of the program is computed from its control flow graph (CFG) using
the formula:
V(G) = Edges – Nodes + 2
or by counting the conditional statements and adding 1
This measure determines the basis set of linearly independent paths and tries to measure the
complexity of a program.
Cyclomatic Complexity:
Cyclomatic Complexity:
Advantages

 easy to compute
 empirical studies: good correlation between cyclomatic complexity and
understandability
Disdvantages

 only control flow

 no data flow
 may be inappropriate for OO programs