Chapter #5

Software Design

Software

design is a process of defining the

architecture, components, interfaces, and other
characteristics of a system or component and
planning for a software solution.
Software design is a process to transform user
requirements into some suitable form, which helps
the
programmer
in
software
coding
and
implementation.

Software design yields three levels of results:

Architectural Design - The architectural design is the highest

abstract version of the system. It identifies the software as a

system with many components interacting with each other. At this
level, the designers get the idea of proposed solution domain.
High-level Design- The high-level design breaks the single
entity-multiple component concept of architectural design into
less-abstracted view of sub-systems and modules and depicts their
interaction with each other. High-level design focuses on how the
system along with all of its components can be implemented in
forms of modules. It recognizes modular structure of each subsystem and their relation and interaction among each other.
Detailed Design- Detailed design deals with the implementation
part of what is seen as a system and its sub-systems in the
previous two designs. It is more detailed towards modules and
their implementations. It defines logical structure of each module
and their interfaces to communicate with other modules.

Characteristics of a good software design

Correctness: A good design should correctly

implement all the functionalities identified in the

SRS document.
Understandability: A good design is easily
understandable.
Efficiency: It should be efficient.
Maintainability: It should be easily amenable to
change.

Design Principles
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.

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 satised by
the design model.

The design should "minimize the intellectual

distance" 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.
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 dened for a design
team before design work begins. A design is
integrated if care is taken in dening interfaces
between design components.

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. 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.

Coupling and Cohesion

When a software program is modularized, its tasks

are divided into several modules based on some

characteristics.
As we know, modules are set of instructions put
together in order to achieve some tasks. They are
though, considered as single entity but may refer to
each other to work together.
There are measures by which the quality of a
design of modules and their interaction among
them can be measured.
These measures are called coupling and cohesion.

Cohesion is a measure that defines the degree of

intra-dependability within elements of a module.

The greater the cohesion, the better is the program
design.

Coupling is a measure that defines the level of

inter-dependability among modules of a program. It

tells at what level the modules interfere and interact
with each other. The lower the coupling, the better
the program.

"Coupling"

describes the relationships between

modules, and "cohesion" describes the relationships
within them.

Structure Chart
A Structure Chart (SC) in software engineering and

organizational theory, is a chart which shows the

breakdown of a system to its lowest manageable levels.
They are used in structured programming to arrange
program modules into a tree. Each module is
represented by a box, which contains the module's
name. The tree structure visualizes the relationships
between modules.
SC Describe functions and sub-functions of each part of
system (in more detail than a DFD)
Show relationships between common and unique
modules of a computer program

Structure Chart - Module

Rectangle represents a module (program or subroutine)
Control Modules (mainline) branch to sub-modules
Library modules are reusable and can be invoked from

more than one Control Module elsewhere in the system

Data flow / Data Couple

Arrow with an empty circle
Shows the data one module passes to another
Control flow / Control Couple:

Arrow with filled circle

Shows a message (flag) which one
module sends to another
Module uses a flag to signal a specific
condition or action to
another module

Structure Chart - Selection

A line with a diamond
Indicates that a control module determines which

subordinate module will be invoked

Structure Chart - Loop

A curved arrow representing a loop One or

more modules are repeated

Structure Chart for

Calculate Pay Amount Routine..

User Interface Design

User interface is the front-end application view to

which user interacts in order to use the software.

User can manipulate and control the software as
well as hardware by means of user interface.
Today, user interface is found at almost every
place where digital technology exists, right from
computers, mobile phones, cars, music players,
airplanes, ships etc.
User interface is part of software and is designed
such a way that it is expected to provide the user
insight of the software.

The software becomes more popular if its user interface is:

Attractive

Simple to use
Responsive in short time
Clear to understand
Consistent on all interfacing screens

UI is broadly divided into two categories:

Command Line Interface
Graphical User Interface

Command Line Interface (CLI)

CLI provides a command prompt, the place where

the user types the command and feeds to the

system. The user needs to remember the syntax of
command and its use.
A command is a text-based reference to set of
instructions, which are expected to be executed by
the system. There are methods like macros, scripts
that make it easy for the user to operate.
CLI uses less amount of computer resource as
compared to GUI.
A text-based command line interface can have the
following elements: Command Prompt, Cursor
and Command

Graphical

User Interface provides the user

graphical means to interact with the system.
Using GUI, user interprets the software.
Typically, GUI is more resource consuming than
that of CLI. With advancing technology, the
programmers and designers create complex GUI
designs that work with more efficiency, accuracy
and speed.
A GUI system has following elements such as:
Window, Menu, Icon, Tab.

Software testing
Testing is the process of evaluating a system or its

component(s) with the intent to find whether it

satisfies the specified requirements or not.
Testing is executing a system in order to identify
any gaps, errors, or missing requirements in
contrary to the actual requirements.

Test Strategies for conventional Software

A strategy for software testing may also be viewed in

the context of the spiral.

Unit testing begins at the vertex of the spiral and
concentrates on each unit (i.e., component) of the
software as implemented in source code.
Testing progresses by moving outward along the
spiral, following unit testing is integration testing,
where the focus is on design and the construction of
the software architecture.

UNIT TESTING
Unit Testing is a level of software testing where

individual units/ components of a software are tested.

The purpose is to validate that each unit of the software
performs as designed.
It aims at testing each component or unit of software to
check its functionality, independently.
A unit is the smallest testable part of software. It usually

has one or a few inputs and usually a single output.

In procedural programming a unit may be an individual
program, function, procedure, etc.
In object-oriented programming, the smallest unit is a
method, which may belong to a base/ super class,
abstract class or derived/ child class.

BENEFITS of Unit Testing

The cost of fixing a defect detected during unit testing is
lesser in comparison to that of defects detected at higher
levels.
Debugging is easy.
Codes are more reusable. In order to make unit testing
possible, codes need to be modular. This means that codes
are easier to reuse.
Unit testing increases confidence in changing/ maintaining
code. If good unit tests are written and if they are run
every time any code is changed, we will be able
to promptly catch any defects introduced due to the
change.
Problems are discovered early.
Integration testing is easier.
Acts as documentation of the system.

Integration Testing
Integration Testing is a level of software testing

where individual units are combined and tested as a

group.
The purpose of this level of testing is to expose faults in
the interaction between integrated units.
Integration Testing is performed after Unit Testing and
before System Testing.
APPROACHES to Integration Testing
Big Bang
Top Down
Bottom Up
Hybrid

Big Bang is an approach to Integration Testing

where all or most of the units are combined

together and tested at one go. This approach is
taken when the testing team receives the entire
software in a bundle.
So what is the difference between Big Bang
Integration Testing and System Testing? Well, the
former tests only the interactions between the units
while the latter tests the entire system.

Top Down is an approach to Integration Testing where

top level units are tested first and lower level units are
tested step by step after that. This approach is taken
when top down development approach is followed.
Bottom Up is an approach to Integration Testing where
bottom level units are tested first and upper level units
step by step after that. This approach is taken when
bottom up development approach is followed.

SYSTEM TESTING
System testing is the type of testing to check the

behavior of a complete and fully integrated software

product based on the software requirements
specification (SRS) document.

The purpose of this test is to evaluate the systems

compliance with the specified requirements.

It may include tests based on risks and/or requirement
specifications, business process, use cases, or other high
level descriptions of system behavior, interactions with
the operating systems, and system resources.
System testing should investigate both functional

and non-functional requirements of the testing.

Types of Testing

1. Black box Testing:

Black-box testing is a method of software testing that

examines the functionality of an application based on

the specifications. It is also known as Specifications
based testing. Independent Testing Team usually
performs this type of testing during the software testing
life cycle.
This method is named so because the software
program, in the eyes of the tester, is like a black box;
inside which one cannot see.

This method attempts to find errors in the following

categories:
Incorrect or missing functions
Interface errors
Errors in data structures or external database
access
Behavior or performance errors
Initialization and termination errors

BLACK BOX TESTING TECHNIQUES

Equivalence partitioning: It is a software test design
technique that involves dividing input values into valid
and invalid partitions and selecting representative values
from each partition as test data.
Boundary Value Analysis: It is a software test design
technique that involves determination of boundaries for
input values and selecting values that are at the
boundaries and just inside/ outside of the boundaries as
test data.
Cause Effect Graphing: It is a software test design

technique that involves identifying the cases (input

conditions) and effects (output conditions), producing a
Cause-Effect Graph, and generating test cases
accordingly.

BLACK BOX TESTING ADVANTAGES

Tests are done from a users point of view and will help in

exposing discrepancies in the specifications.

Tester need not know programming languages or how the
software has been implemented.
Tests can be conducted by a body independent from the
developers, allowing for an objective perspective and the
avoidance of developer-bias.
Test cases can be designed as soon as the specifications are
complete.
DISADVANTAGES
Only a small number of possible inputs can be tested and
many program paths will be left untested.
Without clear specifications, which is the situation in many
projects, test cases will be difficult to design.
Tests can be redundant if the software designer/ developer
has already run a test case.

2. WHITE BOX TESTING

White Box Testing (also known as Clear Box Testing,

Open Box Testing, Glass Box Testing, Transparent Box Testing,

Code-Based Testing or Structural Testing) is a software

testing method in which the internal structure/

design/ implementation of the item being tested is
known to the tester.
The tester chooses inputs to exercise paths through
the code and determines the appropriate outputs.
Programming and the implementation knowledge is
essential.

White Box Testing Techniques

Statement Coverage - This technique is aimed at
exercising all programming statements with
minimal tests.
Branch Coverage - This technique is running a

series of tests to ensure that all branches are

tested at least once.

Path Coverage - This technique corresponds to

testing all possible paths which means that each

statement and branch is covered.