CP5154 ADVANCED SOFTWARE ENGINEERING L T P C 3 0 0 3

OBJECTIVES:

To understand Software Engineering Lifecycle Models

To do project management and cost estimation

To gain knowledge of the System Analysis and Design concepts.

To understand software testing approaches

To be familiar with DevOps practices
UNIT I INTRODUCTION 9
Software engineering concepts – Development activities – Software lifecycle models -
Classical waterfall - Iterative waterfall – Prototyping – Evolutionary - Spiral – Software
project management – Project planning – Estimation – Scheduling – Risk management –
Software configuration management.
UNIT II SOFTWARE REQUIREMENT SPECIFICATION 9
Requirement analysis and specification – Requirements gathering and analysis – Software
Requirement Specification – Formal system specification – Finite State Machines – Petrinets
– Object modelling using UML – Use case Model – Class diagrams – Interaction diagrams –
Activity diagrams – State chart diagrams – Functional modelling – Data Flow Diagram.
UNIT III ARCHITECTURE AND DESIGN 9
Software design – Design process – Design concepts – Coupling – Cohesion – Functional
independence – Design patterns – Model-view-controller – Publish-subscribe – Adapter –
Command – Strategy – Observer – Proxy – Facade – Architectural styles – Layered - Client-
server - Tiered - Pipe and filter.- User interface design
UNIT IV TESTING 9
Testing – Unit testing – Black box testing– White box testing – Integration and System
testing– Regression testing – Debugging - Program analysis – Symbolic execution – Model
Checking
UNIT V DEVOPS 9
DevOps:Motivation-Cloud as a platform-Operations- Deployment Pipeline:Overall
Architecture-Building and Testing-Deployment- Case study: Migrating to Microservices.
TOTAL: 45 PERIODS
OUTCOMES:
At the end of this course, the students will be able to:

Understand the advantages of various Software Development Lifecycle Models

Gain knowledge on project management approaches as well as cost and schedule
estimation strategies

Perform formal analysis on specifications

Use UML diagrams for analysis and design

Architect and design using architectural styles and design patterns

Understand software testing approaches

Understand the advantages of DevOps practices
REFERENCES:
1. Bernd Bruegge, Alan H Dutoit, Object-Oriented Software Engineering, 2nd edition, Pearso
Education, 2004.
2. Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli, Fundamentals of Software Engineering,
2nd edition, PHI Learning Pvt. Ltd., 2010.
3. Craig Larman, Applying UML and Patterns, 3rd ed, Pearson Education, 2005.
4. Len Bass, Ingo Weber and Liming Zhu, ―DevOps: A Software Architect‘s Perspectiveǁ,
Pearson Education, 2016
5. Rajib Mall, Fundamentals of Software Engineering, 3rd edition, PHI Learning Pvt. Ltd.,
2009.
6. Stephen Schach, Software Engineering 7th ed, McGraw-Hill, 2007.
 CP5154 ADVANCED SOFTWARE ENGINEERING LESSON PLAN

CHRISTIAN COLLEGE OF ENGNEERNG AND TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE AND ENGNEERING

NAME : DHARANI.B
DESIGNATION : ASSISTANT PROFESSOR
DEPARTMENT : COMPUTER SCIENCE AND ENGINEERING
SUBJECT CODE & TITLE : CP5154 ADVANCED SOFTWARE ENGINEERING
CLASS : I ME CSE
SEMESTER : 01

R1. Bernd Bruegge, Alan H Dutoit, Object-Oriented Software Engineering, 2nd edition, Pearson
Education, 2004.
R2. Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli, Fundamentals of Software Engineering, 2nd
edition, PHI Learning Pvt. Ltd., 2010.
R3. Craig Larman, Applying UML and Patterns, 3rd ed, Pearson Education, 2005.
R4. Len Bass, Ingo Weber and Liming Zhu, ―DevOps: A Software Architect‘s Perspectiveǁ,
Pearson Education, 2016.
R5. Rajib Mall, Fundamentals of Software Engineering, 3rd edition, PHI Learning Pvt. Ltd., 2009.
R6. Stephen Schach, Software Engineering 7th ed, McGraw-Hill, 2007.

Reference
S.
No Topic Name / Text Page No.
book

UNIT I INTRODUCTION
1 Software engineering concepts R1 10-16
2 Development activities R1 16-20
3 Software lifecycle models - Classical waterfall 38-46
4 Iterative waterfall 46-50
5 Prototyping 52-55
6 Evolutionary 57-59
7 Spiral 69-73
R5
8 Software project management 86-88
9 Project planning 89-91
10 Estimation 92-109
11 Scheduling 119-128
12 Risk management 136-139
13 Software configuration management 140-143
UNIT II SOFTWARE REQUIREMENT SPECIFICATION
14 Requirement analysis and specification R5 154-155
15 Requirements gathering and analysis 155-160

CCET DEPARTMENT OF CSE

 CP5154 ADVANCED SOFTWARE ENGINEERING LESSON PLAN
16 Software Requirement Specification R5 161-181
17 Formal system specification R5 182-186
18 Finite State Machines R2 179-185
19 Petrinets R2 185-210
20 Object modelling using UML – Use case Model 276-310
21 Class diagrams 311-318
22 Interaction diagrams R5 318-320
23 Activity diagrams 320-322
24 State chart diagrams 322-323
25 Functional modelling R1 35-43
26 Data Flow Diagram R2 171-177
UNIT III ARCHITECTURE AND DESIGN
27 Software design– Design process
28 Design concepts
29 Coupling , Cohesion , Functional independence
30 Design patterns – Model-view-controller
31 Publish-subscribe , Adapter –,Command Notes 3.1 – 3.56
32 Strategy ,Observer , Proxy , Facade
33 Architectural styles – Layered
34 Client-server - Tiered - Pipe and filter
35 User interface design
UNIT IV TESTING
36 Testing, Unit testing 405-413
37 Black box testing 413-417
38 White box testing 417-427
R5 430-436
39 Integration and System testing
40 Regression testing 439-440
41 Debugging 427-428
42 Program analysis 317-337
43 Symbolic execution R2 337-347
44 Model Checking 347-349
UNIT V DEVOPS
45 DevOps:Motivation Ch.1.1-1.7
46 Cloud as a platform Ch.2.1-2.3
47 Operations, Deployment Ch.3.1-3.5
48 Pipeline:Overall Architecture R4 Ch.4.1-1.3
49 Building and Testing Ch.5.1-5.8
50 Deployment Ch.6.1-6.8
51 Case study: Migrating to Microservices Ch.13.1-13.5

STAFF IN-CHARGE HOD

CCET DEPARTMENT OF CSE

 Software Engineering

CS6403 Software Engineering Lecture Notes

UNIT I

SOFTWARE PROCESS AND PROJECT MANAGEMENT

Software engineering paradigm:

• The framework activit ies will always be applied on every pro ject ... BUT the tasks (and
degree of rigor) for each activity will vary based on:
– the type of project
– characteristics of the project
– common sense judgment; concurrence of the project team
The software process:
• A structured set of activities required to develop a software system
– Specification;
– Design;
– Validation;
– Evolution.
• A software process model is an abstract representation of a process. It presents a
description of a process from some particular perspective.
Waterfall model/Linear Sequential Model/classic life cycle :

• Systems Engineering
– Software as part of larger system, determine requirem ents for all system
elements, allocate requirements to software.
• Software Requirements Analysis
– Develop understanding of problem domain, user needs, function, performance,
interfaces, ...
– Software Design
– Multi-step process to determine architecture, interfaces, data structures,
functional detail. Produces (high-level) form that can be checked for quality,
conformance before coding.
• Coding
– Produce machine readable and executable form, match HW, OS and design needs.
• Testing
 Software Engineering

– Confirm that components, subsystems and complete products meet requirements,

specifications and quality, find and fix defects.
• Maintenance
– Incrementally, evolve software to fix defects, add features, adapt to new
condition. Often 80% of effort spent here!
Waterfall model phases:
• Requirements analysis and definition
• System and software design
• Implementation and unit testing
• Integration and system testing
• Operation and maintenance
• The main drawback of the waterfall model is the difficulty of acco mmodat ing change
after the process is underway. One phase has to be complete before moving onto the next
phase.
• Each phase terminates only when the documents are complete and approved by the SQA
group.
• Maintenance begins when the client reports an error after having accepted the product. It
could also begin due to a change in requirements after the client has accepted the product
Waterfall model: Advantages:
• Disciplined approach
• Careful checking by the Software Quality Assurance Group at the end of each phase.
• Testing in each phase.
• Documentation available at the end of each phase.
Waterfall model problems:
• It is difficult to respond to changing customer requirements.
• Therefore, this model is only appropriate when the requirements are well-understood and
changes will be fairly limited during the design process.
• Few business systems have stable requirements.
• The waterfall model is mostly used for large systems engineering projects where a s ystem
is developed at several sites.
• The customer must have patience. A working version of the program will not be available
until late in the project time-span
• Feedback from one phase to another might be too late and hence expensive.
The Prototyping Models:
• Often, a customer defines a set of general object ives for software but does not identif y
detailed input, processing, or output requirements.
• In other cases, the developer may be unsure of the efficiency of an algorithm, the
adaptability of an operating s ystem, or the form t hat human –machine interaction should
take
• In this case prototyping paradigm may offer the best approach
• Requirements gathering
• Quick design
• Prototype building
• Prototype evaluation by customers
• Prototype may be refined
 Software Engineering

• Protot ype thrown away and software developed using formal process{ it is used to define
the requirement} Prototyping
Strengths:
• Requirements can be set earlier and more reliably
• Customer sees results very quickly.
• Customer is educated in what is possible helping to refine requirements.
• Requirements can be communicated more clearly and completely
• Between developers and clients Requirements and design options can be
investigated quickly and Cheaply
Weaknesses:
– Requires a rapid prototyping tool and expertise in using it–a cost for the
development organisation
– Smoke and mirrors - looks like a working version, but it is not.
The RAD Model:
• Rapid Application Development is a linear sequential software development process
model that emphasizes an extremely short development cycle
• Rapid application achieved by using a component based construction approach
• If requirements are well understood and project scope is constrained the RAD process
enables a development team to create a ―fully functional systemǁ
Team # n
M o d e lin g
busin es s m
o d e lin g d a t a m
ode ling
proc es s m o d eli ng

C o n s t ru c t io n
Team # 2 c om ponent r eus

Co m m unicat ion e a u t o m a t ic
od e
c

gener a t io n
M o d el i n g t e s t in g
b u si n e ss m o d e li n
g d a t a m o d eli n g
p ro ce ss m o d e li n g

Plan n ing
C o ns t r uc t i o n De p lo ym e nt
Team # 1 co m p o n e n t re u
int egrat ion
se a u t o m a t i c co d
e de liv ery
Mo de ling g e n e ra t i o f ee d b ack
n t e st i n g
b u si ne ss mo d e lin g
d at a mo d elin g
p ro ce ss mo d e l i ng

Co n st r uct io n
co mp o n e n t
reu se aut omat ic
co d e
g e n e r at i o n
t e st ing

6 0 - 9 0 d ays

RAD phases :
• Business modeling
• Data modeling
• Process modeling
 Software Engineering

• Application generation
• Testing and turnover
Business modeling:
• What information drives the business process?
• What information is generated?
• Who generates it?
Data Modeling:
• The information flow defined as part of the business modeling phase is refined into a set
of data objects that are needed to support the business.
• The characteristics ( called attributes) of each object are ident ified and the relationships
between these objects are defined
Process modeling:
• The data modeling phase are transformed to achieve the inf ormation flow necessary to
implement a business function.
• Processing descriptions are created for adding , modifying, deleting, or retrieving a data
object
Application generation:
• RAD assumes the use of 4 generation techniques.
• Rather than creating software using conventional 3 generation programming languages,
the RAD process works to reuse existing program components (when possible) or created
reusable components (when necessary)
Testing and Turnover:
• Since the RAD process emphasizes reuse, many of the program components have already
been testing.
• This reduces over all testing time.
• However, new components must be tested and all interfaces must be fully exercised
Advantages &Disadvantages of RAD:
Advantages
• Extremely short development time.
• Uses component-based construction and emphasises reuse and code generation
Disadvantages
• Large hum an resource requirem ents (to create all of the team s).
• Requires strong commitment between developers and customers for “rapid-fire”
activities.
• High perform ance requirem ents m aybe can’t be m et (requires tuning the com ponents).
The Incremental Model

i nc r em ent # n

C o m m u n i c a t i o n

P l a n n i n g

M o d e l i n g

a n a l y s i s
C o n s t r u c t

i o n
d e s i g n
D e p l o y m e n t
c o d e

d e l i v e r y
t e s t

f e e d b a c k

d e li ve r y of
n t h i n c rem e nt
incr em ent # 2

C o m m u n i c a t i o n

P l a n n i n g

M o d e l i n g

a n a l ys is
C o n s t r u c t i o n

d es i g n
c o d e
D e p l o y m e n t

d e li ve r y of
t e s t

d e l i v e r y

f e e d b a c k

incr em ent # 1 2 nd incr em e nt

C o m m u n i c a t i o n

P l a n n

i n g

M o d e l i n g

a n a l y s i s C o n s t r u c t i o n

d e li ve r y of
d es i g n
c o d e D e p l o y m e n t

t e s t d e l i v e r y

f e e d b a c k

1 st i ncre me nt

pr o j ect c alend ar t ime :

 Software Engineering

The Incremental development

• Combination of linear + prototype
• Rather than deliver the system as a single delivery, the development and delivery is
broken down into increments with each increment delivering part of the required
functionality
• User requirements are prioritised and the highest priority requirements are included in
early increments
• Once the development of an increment is started, the requirements are frozen though
requirements for later increments can continue to evolve
Incremental development advantages:
• The customer is able to do some useful work after release
• Lower risk of overall project failure
• The highest priority system services tend to receive the most testing
Spiral Model:

Spiral model sectors:

• Customer communication
Tasks required to establish effect ive co mmunication between developer and
customer
• Planning
The tasks required to define recourses, timelines, and project is reviewed and the
next phase of the spiral is planned
• Risk analysis
– Risks are assessed and activities put in place to reduce the key
• Risks engineering
– Tasks required to build one or more representations of the application
 Software Engineering

• Construction & release

– Tasks required to construct, test, install and provide user support (e.g
documentation and training)
• Customer evaluation
– Customer feedback collected every stage
Spiral Model Advantages:
• Focuses attention on reuse options.
• Focuses attention on early error elimination.
• Puts quality objectives up front.
• Integrates development and maintenance.
• Provides a framework for hardware/software Development.

System Engineering
• Software engineering occurs as a consequence of a process called system engineering.
• Instead of concentrating so lely on software, s ystem engineering focuses on a variety of
elements, analyzing, designing, and organizing those elements into a s ystem that can be a
product, a service, or a technology for the transformation of information or control.
 Software Engineering

• The system engineering process usually begins with a ―world view.ǁ That is, the ent ire
business or product domain is examined to ensure that the proper business or technolog y
context can be established.
• The world view is refined to focus more fully on specific domain of interest. Within a
specific domain, the need for targeted s ystem elements (e.g., data, software, hardware,
people) is analyzed. Finally, the analysis, design, and construction of a targeted system
element is initiated.
• At the top of the hierarchy, a very broad context is established and, at the bottom, detailed
technical activities, performed by the relevant engineering discipline (e.g., hardware or
software engineering), are conducted.
• Stated in a slight ly more formal manner, the world view (WV) is co mposed of a set of
domains (Di), which can each be a system or system of systems in its own right.
WV = {D1, D2, D3, . . . , Dn}
• Each domain is co mposed of specific elements (Ej) each of which serves some role in
accomplishing the objective and goals of the domain or component:
Di = {E1, E2, E3, . . . , Em}
• Finally, each element is implemented by specifying the technical components (Ck) that
achieve the necessary function for an element:
Ej = {C1, C2, C3, . . . , Ck}

Computer Based System

• computer-based system as A set or arrangement of elements that are organized to accomplish
some predefined goal by processing information.
• The goal may be to support some business function or to develop a product that can be sold
to generate business revenue.
• To accomplish the goal, a computer-based system makes use of a variety of system elements:
1. Software. Computer programs, data structures, and related documentation that serve to
effect the logical method, procedure, or control that is required.
2. Hardware. Electronic devices that provide computing capabilit y, the interconnect ivit y
devices (e.g., network switches, teleco mmunicatio ns devices) that enable the flow o f
data, and electromechanical devices (e.g., sensors, motors, pumps) that provide external
world function.
3. People. Users and operators of hardware and software.
4. Database. A large, organized collection of information that is accessed via software.
5. Documentation. Descriptive information (e.g., hardcopy manuals, on-line help files,
Web sites) that portrays the use and/or operation of the system.
6. Procedures. The steps that define the specific use of each s ystem element or the
procedural context in which the system resides.
• The elements combine in a variety of ways to transform information. For example, a
marketing department transforms raw sales data into a profile of the typical purchaser of a
product; a robot transforms a co mmand file containing specific instructions into a set of
control signals that cause some specific physical action.
• Creating an information system to assist the marketing department and control software to
support the robot both require system engineering.
 Software Engineering

• One complicating characterist ic of computer-based systems is that the elements constituting

one system may also represent one macro element of a still larger system. The macro element
is a computer-based system that is one part of a larger computer-based system.
• As an example, we consider a "factory automation system" that is essentially a hierarchy o f
systems. At the lowest level of the hierarchy we have a numerical control machine, robots,
and data entry devices.
• Each is a co mputerbased system in its own right. The elements of the numerical control
machine include electronic and electromechanical hardware (e.g., processor and memor y,
motors, sensors), software (for communications, machine control, interpo lation), people (the
machine operator), a database (the stored NC program), documentation, and procedures.
• A similar decomposition could be applied to the robot and data entry device. Each is a
computer-based system.
• At the next level in the hierarchy, a manufacturing cell is defined. The manufacturing cell is a
computer-based system that may have elements of its own (e.g., computers, mechanical
fixtures) and also integrates the macro elements that we have called numerical control
machine, robot, and data entry device.

Business Process Engineering Overview

• The goal of business process engineering (BPE) is to define architectures that will enable a
business to use information effectively.
• When taking a world view of a company‘s information technology needs, there is little doubt
that system engineering is required. Not only is the specification of the appropriate
computing architecture required, but the software architecture that populates the ―unique
configuration of heterogeneous computing resourcesǁ must be developed.
• Business process engineering is one approach for creating an overall plan for implement ing
the computing architecture .
• Three different architectures must be anal yzed and designed wit hin the context of business
objectives and goals:
• data architecture
• applications architecture
• technology infrastructure
• The data architecture provides a framework for the information needs of a business or
business function. The individual building blocks of the architecture are the data objects that
are used by the business. A data object contains a set of attributes that define so me aspect,
quality, characteristic, or descriptor of the data that are being described.
• The application architecture enco mpasses those elements of a s ystem that transform objects
within the data architecture for so me business purpose. In the context of this book, we
consider the application architecture to be the s ystem of programs (software) that performs
this transformation. However, in a broader context, the application architecture might
incorporate the role of people (who are information transformers and users) and business
procedures that have not been automated.
• The technology infrastructure provides the foundation for the data and applicatio n
architectures. The infrastructure encompasses the hardware and software that are used to
support the application and data. This includes computers, operating systems, networks,
telecommunication links, storage technologies, and the architecture (e.g., client/server) that
has been designed to implement these technologies.
 Software Engineering

• The final BPE step—construction and integrati on focuses on implementation detail. The
architecture and infrastructure are implemented by constructing an appropriate database and
internal data structures, by building applications using software components, and by selecting
appropriate elements of a technology infrastructure to support the design created during
BSD. Each of these system co mponents must then be integrated to form a complete
information system or application.
• The integration activity also places the new information system into the business area
context, performing all user training and logistics support to achieve a smooth transition.

Product Engineering Overview

• The goal of product engineering is to translate the customer‘s desire for a set of defined
capabilities into a working product. To achieve this goal, product engineering—like business
process engineering—must derive architecture and infrastructure.
• The architecture encompasses four distinct system co mponents: software, hardware, data
(and databases), and people. A support infrastructure is established and includes the
technology required to tie the components together and the information (e.g., documents,CD-
ROM, video) that is used to support the components.
• The world view is achieved through requirements engineering. The overall requirements of
the product are elicited from the customer. These requirements enco mpass information and
control needs, product function and behavior, overall product performance, design and
interfacing constraints, and other special needs.
• Once these requirements are known, the job of requirements engineering is to allocate
funct ion and behavior to each of the four components noted earlier. Once allocat ion has
occurred, system component engineering commences.
 Software Engineering

• S ystem component engineering is actually a set of concurrent activit ies that address each of
the system components separately: software engineering, hardware engineering, human
engineering, and database engineering.

• Each of these engineering disciplines takes a do main-specific view, but it is important to note
that the engineering disciplines must establish and maintain active co mmunication with one
another. Part of the ro le of requirements engineering is to establish the interfacing
mechanisms that will enable this to happen.
• The element view for product engineering is the engineering discipline itself applied to the
allocated component. For software engineering, this means analysis and design modeling
activities (covered in detail in later chapters) and construction and integration act ivit ies that
encompass code generation, testing, and support steps.
• The analysis step models allocated requirements into representations of data, function, and
behavior. Design maps the analysis model into data, architectural, interface, and soft ware
component-level designs.
 Software Engineering

UNIT II SOFTWARE

REQUIREMENTS

• The process of establishing the services that the customer requires from a s ystem and the
constraints under which it operates and is developed
• Requirements may be functional or non-functional
• Functional requirements describe system services or functions
• Non-functional requirements is a constraint on the s ystem or on the development
process

Types of requirements
• User requirements
• Statements in natural language (NL) plus diagrams of the services the system
provides and its operational constraints. Written for customers
• System requirements
• A structured document setting out detailed descriptions of the system services.
Written as a contract between client and contractor
• Software specification
• A detailed software description which can serve as a basis for a design or
implementation. Written for developers

Functional and Non-Functional

Functional requirements
• Functionality or services that the system is expected to provide.
• Functional requirements may also explicitly state what the system shouldn‘t do.
• Functional requirements specification should be:
• Complete: All services required by the user should be defined
• Consistent: should not have contradictory definition (also avo id ambiguity
don‘t leave room for different interpretations)

Examples of functional requirements

• The LIBSYS system
• A library s ystem that provides a single interface to a number of databases of articles in
different libraries.
• Users can search for, download and print these articles for personal study.
• The user shall be able to search eit her all o f the initial set of databases or select a subset fro m
it.
• The system shall provide appropriate viewers for the user to read documents in the document
store.
• Every order shall be allocated a unique ident ifier (ORDER_ID) which the user shall be able
to copy to the account‘s permanent storage area.

Non-Functional requirements
 Software Engineering

• Requirements that are not direct ly concerned with the specific functions delivered by the
system
• Typically relate to the system as a whole rather than the individual system features
• Often could be deciding factor on the survival of the system (e.g. reliability, cost, response
time)

Non-Functional requirements classifications:

Non-functional
requir ements

Product Organisation External

r equir ements al requir emen r equir ements
ts

Efficien cy Reliability Porta b ility In ter o p er a b ility Ethical

requir ements r equir ements requir ements requir ements r equir ements

Usa b ility Deli very Implementa tion Stan d ar ds Leg islative

r equir ements requir ements requir ements requir ements requir ements

Performance Space Pri vacy Safety

requir ements r equir ements r equir ements requir ements

Domain requirements
• Domain requirements are derived from the application domain of the system rather than fro m
the specific needs of the system users.
• May be new functional requirements, constrain exist ing requirements or set out how
particular computation must take place.
• Example: tolerance level of landing gear on an aircraft (different on dirt, asphalt, water), or
what happens to fiber optics line in case of sever weather during winter Olympics (Onl y
domain-area experts know)

Product requirements
• Specify the desired characteristics that a system or subsystem must possess.
• Most NFRs are concerned with specifying constraints on the behaviour of the execut ing
system.
Specifying product requirements
• Some product requirements can be formulated precisely, and thus easily quantified
• Performance
• Capacity
 Software Engineering

• Others are more difficult to quantify and, consequently, are often stated informally
• Usability

Process requirements
• Process requirements are constraints placed upon the development process of the system
• Process requirements include:
• Requirements on development standards and methods which must be followed
• CASE tools which should be used
• The management reports which must be provided

Examples of process requirements

• The development process to be used must be explicit ly defined and must be conformant with
ISO 9000 standards
• The system must be developed using the XYZ suite of CASE tools
• Management reports setting out the effort expended on each ident ified system co mponent
must be produced every two weeks
• A disaster recovery plan for the system development must be specified

External requirements
• May be placed on both the product and the process
• Derived from the environment in which the system is developed
• External requirements are based on:
• application domain information
• organisational considerations
• the need for the system to work with other systems
• health and safety or data protection regulations
• or even basic natural laws such as the laws of physics

Examples of external requirements

• Medical data s ystem The organisation‘s data protection officer must certify t hat all data is
maintained according to data protection legislation before the system is put into operation.
• Train protection s ystem The t ime required to bring the train to a complete halt is co mputed
using the following function:
• The deceleration of the train shall be taken as:
gtrain = gcontrol + ggradient
where:
ggradient = 9.81 ms-2 * compensated gradient / alpha and where the values of 9.81 ms-2/
alpha are known for the different types of train.
gcontrol is initialised at 0.8 ms-2 - this value being parameterised in order to remain
adjustable. The illustrates an example of the train‘s deceleration by using the parabolas derived
from the above formula where there is a change in gradient before the (predicted) stopping po int
of the train.

Software Document
• Should provide for communication among team members
 Software Engineering

• Should act as an information repository to be used by maintenance engineers

• Should provide enough information to management to allow them to perform all pro gram
management related activities
• Should describe to users how to operate and administer the system
• Specify external system behaviour
• Specify implementation constraints
• Easy to change
• Serve as reference tool for maintenance
• Record forethought about the life cycle of the system i.e. predict changes
• Characterise responses to unexpected events

Users of a requirements document

Speci fy t he req uiremen ts and
read th em to ch eck t hat t hey meet
Sy st em cus to mers th eir n eeds . Th ey
s pecify ch ang es t o th e
requ iremen ts

Us e t he req ui rement s
Manag ers d ocumen t to pl an a bi d for t
he s ys tem an d to pl an th e
sy st em dev elo pmen t p roces s

Us e t he req ui rement s to
Sy st em eng in eers un ders tan d wh at s ys tem i s to
b e dev elo ped

Sy st em tes t Us e t he req ui rement s to

eng in eers d ev elo p val id ati on tes ts fo r
t he s ys tem

Sy st em main Us e t he req ui rement s to hel p

ten ance eng u nd ers tan d th e sy st em an d
in eers t he rel ati on sh ip s b etw een it s
p art s

Process Documentation
• Used to record and track the development process
• Planning documentation
• Cost, Schedule, Funding tracking
• Schedules
• Standards
 Software Engineering

• This documentation is created to allow for successful management of a software product

• Has a relatively short lifespan
• Only important to internal development process
• Except in cases where the customer requires a view into this data
• Some items, such as papers that describe design decisio ns should be extracted and mo ved
into the product documentation category when they become implemented
• Product Documentation
• Describes the delivered product
• Must evolve with the development of the software product
• Two main categories:
• System Documentation
• User Documentation

Product Documentation
• System Documentation
• Describes how the system works, but not how to operate it
• Examples:
• Requirements Spec
• Architectural Design
• Detailed Design
• Commented Source Code
 Including output such as JavaDoc
• Test Plans
 Including test cases
• V&V plan and results
• List of Known Bugs
• User Documentation has two main types
• End User
• System Administrator
 In some cases these are the same people
• The target audience must be well understood!
• There are five important areas that should be documented for a formal release of a software
application
• These do not necessarily each have to have their own document, but the topics should
be covered thoroughly
• Functional Description of the Software
• Installation Instructions
• Introductory Manual
• Reference Manual
• System Administrator‘s Guide

Document Quality
• Providing thorough and pro fessional documentation is important for any size product
development team
 Software Engineering

• The problem is that many software professionals lack the writ ing skills to create
professional level documents

Document Structure
• All documents for a given product should have a similar structure
• A good reason for product standards
• The IEEE Standard for User Documentation lists such a structure
• It is a superset of what most documents need
• The authors ―best practicesǁ are:
• Put a cover page on all documents
• Divide documents into chapters with sections and subsections
• Add an index if there is lots of reference information
• Add a glossary to define ambiguous terms

Standards
• Standards play an important role in the development, maintenance and usefulness of
documentation
• Standards can act as a basis for quality documentation
• But are not good enough on their own
 Usually define high level content and organization
• There are three types of documentation standards

[Link] Standards
• Define the approach that is to be used when creating the documentation
• Don‘t actually define any of the content of the documents

2. Product Standards
• Goal is to have all documents created for a specific product attain a consistent structure and
appearance
• Can be based on organizational or contractually required standards
• Four main types:
• Documentation Identification Standards
• Document Structure Standards
• Document Presentation Standards
• Document Update Standards

• One caveat:
• Documentation that will be viewed by end users should be created in a way that is
best consumed and is most attractive to them
• Internal development documentation generally does not meet this need

3. Interchange Standards
• Deals with the creation of documents in a format that allows others to effectively use
• PDF may be good for end users who don‘t need to edit
• Word may be good for text editing
 Software Engineering

• Specialized CASE tools need to be considered

• This is usually not a problem wit hin a single organization, but when sharing data between
organizations it can occur
• This same problem is faced all the time during software integration

Other Standards
• IEEE
• Has a published standard for user documentation
• Provides a structure and superset of content areas
• Many organizations probably won‘t create documents that completely match the
standard
• Writing Style
• Ten ―best practicesǁ when writing are provided
• Author proposes that group edits of important documents should occur in a similar
fashion to software walkthroughs

Requirement Engineering Process

• The requirements engineering process includes a feasibility stud y, requirements elicitatio n
and analysis, requirements specification and requirements management

Feasi bi li ty Requ irement s

s tu dy eli cit ati on an d
analy si s
Requ ir ement s
s pecifi cati on
Feasi bi li ty Requ irement s
repo rt v al id ati on
Sy st em
mo dels
Us er an d s ys tem
requ iremen ts

Requ irement s
d ocumen t

Feasibility Studies
• A feasibility study decides whether or not the proposed system is worthwhile
• A short focused study that checks
• If the system contributes to organisational objectives
• If the system can be engineered using current technology and within budget
• If the system can be integrated with other systems that are used
• Based on information assessment (what is required), information collection and report
writing
• Questions for people in the organisation
• What if the system wasn‘t implemented?
• What are current process problems?
• How will the proposed system help?
 Software Engineering

• What will be the integration problems?

• Is new technology needed? What skills?
• What facilities must be supported by the proposed system?

Elicitation and analysis

• Sometimes called requirements elicitation or requirements discovery
• Involves technical staff working with customers to find out about
• the application domain
• the services that the system should provide
• the system‘s operational constraints
• May involve end-users, managers, engineers involved in maintenance, domain experts, trade
unions, etc.
• These are called stakeholders

Problems of requirements analysis

• Stakeholders don‘t know what they really want
• Stakeholders express requirements in their own terms
• Different stakeholders may have conflicting requirements
• Organisational and political factors may influence the system requirements
• The requirements change during the analysis process
• New stakeholders may emerge and the business environment change

System models
• Different models may be produced during the requirements analysis activity
• Requirements analysis may involve three structuring activit ies which result in these different
models
• Partitioning – Identifies the structural (part-of) relationships between entities
• Abstraction – Identifies generalities among entities
• Projection – Identifies different ways of looking at a problem
• System models will be covered on January 30

Scenarios
• Scenarios are descriptions of how a system is used in practice
• They are helpful in requirements elicitation as people can relate to these more readily than
abstract statement of what they require from a system
• Scenarios are particularly useful for adding detail to an outline requirements description

Ethnography
• A social scient ists spends a considerable t ime observing and analysing how people actuall y
work
• People do not have to explain or articulate their work
• Social and organisational factors of importance may be observed
• Ethnographic studies have shown that work is usually richer and more complex than
suggested by simple system models
 Software Engineering

Requirements validation
• Concerned with demonstrating that the requirements define the system that the customer
really wants
• Requirements error costs are high so validation is very important
• Fixing a requirements error after delivery may cost up to 100 times the cost of fix ing
an implementation error
• Requirements checking
• Validity
• Consistency
• Completeness
• Realism
• Verifiability

Requirements validation techniques

• Reviews
• Systematic manual analysis of the requirements
• Prototyping
• Using an executable model of the system to check requirements.
• Test-case generation
• Developing tests for requirements to check testability
• Automated consistency analysis
• Checking the consistency of a structured requirements description

Requirements management
• Requirements management is the process of managing changing requirements during the
requirements engineering process and system development
• Requirements are inevitably incomplete and inconsistent
• New requirements emerge during the process as business needs change and a better
understanding of the system is developed
• Different viewpoints have different requirements and these are often contradictory

Software prototyping
Incomplete versions of the software program being developed. Protot yping can also be
used by end users to describe and prove requirements that developers have not considered

Benefits:
The software designer and implementer can obtain feedback from the users early in the
project. The client and the contractor can compare if the software made matches the software
specification, according to which the software program is built.
It also allows the software engineer some insight into the accuracy of initial pro ject
estimates and whether the deadlines and milestones proposed can be successfully met.

Process of prototyping
1. Identify basic requirements
Determine basic requirements including the input and output information desired. Details,
such as security, can typically be ignored.
 Software Engineering

2. Develop Initial Prototype

The initial protot ype is developed that includes only user interfaces. (See Horizontal
Prototype, below)
3. Review
The customers, including end-users, examine the protot ype and provide feedback on
additions or changes.
4. Revise and Enhance the Prototype
Using the feedback both the specifications and the protot ype can be improved. Negotiation
about what is wit hin the scope of the contract/product may be necessar y. If changes are
introduced then a repeat of steps #3 and #4 may be needed.

Dimensions of prototypes
1. Horizontal Prototype
It provides a broad view of an ent ire s ystem or subsystem, focusing on user interaction more
than low-level system functionalit y, such as database access. Horizontal protot ypes are usefu l
for:
• Confirmation of user interface requirements and system scope
• Develop preliminary estimates of development time, cost and effort.

2 Vertical Prototypes
A vertical prototype is a more complete elaboration of a single subsystem or function. It is
useful for obtaining detailed requirements for a given function, with the following benefits:
• Refinement database design
• Obtain information on data volumes and system interface needs, for network sizing and
performance engineering

Types of prototyping
Software protot yping has many variants. However, all the methods are in so me wa y
based on two major types of prototyping: Throwaway Prototyping and Evolutionary Prototyping.
1. Throwaway prototyping
Also called close ended protot yping. Throwaway refers to the creation of a model that
will eventually be discarded rather than becoming part of the final delivered software. After
preliminary requirements gathering is accomplished, a simple working model of the s ystem is
constructed to visually show the users what their requirements may look like when they are
implemented into a finished system.
The most obvious reason for using Throwaway Protot yping is that it can be done quickly.
If the users can get quick feedback on their requirements, they may be able to refine them early
in the development of the software. Making changes early in the development lifecycle is
extremely cost effect ive since there is nothing at that point to redo. If a project is changed after a
considerable work has been done then small changes could require large efforts to implement
since software systems have many dependencies. Speed is crucial in implement ing a throwaway
protot ype, since with a limited budget of time and money litt le can be expended on a protot ype
that will be discarded.
Strength of Throwaway Protot yping is its ability to construct interfaces that the users can
test. The user interface is what the user sees as the syst em, and by seeing it in front of them, it is
much easier to grasp how the system will work.
 Software Engineering

2. Evolutionary prototyping
Evolutionary Prototyping (also known as breadboard prototyping) is quite different from
Throwaway Prototyping. The main goal when using Evo lutionary Prototyping is to build a ver y
robust protot ype in a structured manner and constant ly refine it. "The reason for this is that the
Evolut ionary protot ype, when built, forms the heart of the new s ystem, and the improvements
and further requirements will be built.
Evolutionary Protot ypes have an advantage over Throwaway Protot ypes in that they are
functional systems. Although they may not have all t he features the users have planned, the y
may be used on a temporary basis until the final system is delivered.
In Evolutionary Prototyping, developers can focus themselves to develop parts of the
system that they understand instead of working on developing a who le s yst em. To minimize risk,
the developer does not implement poorly understood features. The partial s ystem is sent to
customer sites. As users work with the system, they detect opportunities for new features and
give requests for these features to developers. Developers then take these enhancement requests
along wit h their own and use sound configuration-management practices to change the software-
requirements specification, update the design, recode and retest.

3. Incremental prototyping
The final product is built as separate protot ypes. At the end the separate protot ypes are
merged in an overall design.

4. Extreme prototyping
Extreme Prototyping as a development process is used especially for developing web
applications. Basically, it breaks down web development into three phases, each one based on
the preceding one. The first phase is a static protot ype that consists mainly of HTML pages. In
the second phase, the screens are programmed and fully functional using a simulated services
layer. In the third phase the services are implemented. The process is called Extreme Prototyping
to draw attention to the second phase of the pro cess, where a fully-functional UI is developed
with very little regard to the services other than their contract.

Advantages of prototyping

1. Reduced time and costs: Prototyping can improve the quality of requirements and
specifications provided to developers. Because changes cost exponentially more to implement as
they are detected later in development, the early determination of what the user really wants can
result in faster and less expensive software.

2. Improved and increased user involvement: Prototyping requires user involvement and
allows them to see and interact with a prototype allowing them to provide better and more
complete feedback and specifications. The presence of the protot ype being examined by the user
prevents many misunderstandings and misco mmunications that occur when each side believe the
other understands what they said. Since users know the problem domain better than anyo ne on
the development team does, increased interaction can result in final product that has greater
tangible and intangible qualit y. The final product is more likely to satisfy the users‘ desire for
look, feel and performance.
 Software Engineering

Disadvantages of prototyping
1. Insufficient analysis: The focus on a limited protot ype can distract developers from properl y
analyzing the complete project. This can lead to overlooking better solutions, preparation o f
incomplete specifications or the conversion of limited protot ypes into poorly engineered final
projects that are hard to maintain. Further, since a protot ype is limited in functionality it may not
scale well if the protot ype is used as the basis of a final deliverable, which may not be noticed if
developers are too focused on building a prototype as a model.
2. User confusion of p rototype and finished system: Users can begin to think that a protot ype,
intended to be thrown away, is actually a final system that merely needs to be finished or
polished. (They are, for example, often unaware of the effort needed to add error -checking and
securit y features which a protot ype may not have.) This can lead them to expect the protot ype to
accurately model the performance of the final system when this is not the intent of the
developers. Users can also beco me attached to features that were included in a protot ype for
consideration and then removed from the specification for a final s ystem. If users are able to
require all proposed features be included in the final system this can lead to conflict.
3. Developer misunderstanding of user objectives: Developers may assume that users share
their objectives (e.g. to deliver core functionality on t ime and within budget), without
understanding wider commercial issues. For example, user representatives attending Enterprise
software (e.g. PeopleSoft) events may have seen demonstrations of "transaction audit ing" (where
changes are logged and displayed in a difference grid view) without being told that this feature
demands additio nal coding and often requires more hardware to handle extra database accesses.
Users might believe they can demand audit ing on every field, whereas developers might think
this is feature creep because they have made assu mptions about the extent of user requirements.
If the developer has co mmitted delivery before the user requirements were reviewed, developers
are between a rock and a hard place, part icularly if user management derives so me advantage
from their failure to implement requirements.
4. Developer attachment to prototype: Developers can also become attached to protot ypes the y
have spent a great deal of effort producing; this can lead to problems like attempting to convert a
limited protot ype into a final system when it does not have an appropriate underlying
architecture. (This may suggest that throwaway protot yping, rather th an evolutionary
prototyping, should be used.)
5. Excessive develop ment time of the prototype: A key propert y to prototyping is the fact that
it is supposed to be done quickly. If the developers lose sight of this fact, they very well may try
to develop a prototype that is too complex. When the protot ype is thrown away the precisel y
developed requirements that it provides may not yield a sufficient increase in productivity to
make up for the time spent developing the prototype. Users can become stuck in debates over
details of the prototype, holding up the development team and delaying the final product.
6. Expense of implementing prototyping: the start up costs for building a development team
focused on prototyping may be high. Many companies have development methodologies in
place, and changing them can mean retraining, retooling, or both. Many companies tend to just
jump into the prototyping without bothering to retrain their workers as much as they should.
A common problem with adopting prototyping technology is high expectations for productivit y
with insufficient effort behind the learning curve. In addition to training for the use of a
protot yping technique, there is an often overlooked need for developing corporate and project
 Software Engineering

specific underlying structure to support the technology. When this underlying structure is
omitted, lower productivity can often result.

Best projects to use prototyping

It has been found that prototyping is very effect ive in the analysis and design of on-line
systems, especially for transaction processing, where the use of screen dialogs is much more in
evidence. The greater the interaction between the computer and the user, the greater the benefit is
that can be obtained from building a quick system and letting the user play with it.
S ystems with little user interact ion, such as batch processing or systems that mostly do
calculations, benefit little from prototyping. Sometimes, the coding needed to perform the system
functions may be too intensive and the potential gains that prototyping could provide are too
small.
Protot yping is especially good for designing good human-co mputer interfaces. "One o f
the most productive uses of rapid prototyping to date has been as a tool for iterative user
requirements engineering and human-computer interface design.

Methods
There are few formal prototyping methodologies even though most Agile Methods rel y
heavily upon prototyping techniques.
1. Dynamic systems development method
Dynamic S ystems Development Method (DSDM) is a framework for delivering business
solutions that relies heavily upon prototyping as a core technique, and is itself ISO 9001
approved. It expands upon most understood definitions of a protot ype. According to DSDM the
protot ype ma y be a diagram, a business process, or even a system placed into production. DSDM
protot ypes are intended to be incremental, evolving from simple forms into more comprehensive
ones.
DSDM protot ypes may be throwaway or evolutionar y. Evolutionary protot ypes may be evo lved
horizontally (breadth then depth) or vertically (each section is built in detail with additional
iterations detailing subsequent sections). Evolutionary protot ypes can eventually evolve into
final systems.

The four categories of prototypes as recommended by DSDM are:

• Business prototypes – used to design and demonstrate the business processes being
automated.
• Usability p rototypes – used to define, refine, and demo nstrate user interface design
usability, accessibility, look and feel.
• Performance and capacity prototypes - used to define, demonstrate, and predict how
systems will perform under peak loads as well as to demonstrate and evaluate other non-
functional aspects of the system (transaction rates, data storage volume, response time)
• Capability/technique prototypes – used to develop, demonstrate, and evaluate a design
approach or concept.
The DSDM lifecycle of a prototype is to:
1. Identify prototype
2. Agree to a plan
3. Create the prototype
4. Review the prototype
 Software Engineering

2. Operational prototyping
Operational Prototyping was proposed by Alan Davis as a way to integrate throwaway and
evolutionary protot yping with conventional s ystem development. "[It] offers the best of both the
quick-and-dirty and conventional-development worlds in a sensible manner. Designers develop
only well-understood features in building the evo lutionary baseline, while using throwawa y
prototyping to experiment with the poorly understood features."
Davis' belief is that to try to "retrofit quality onto a rapid protot ype" is not the correct approach
when trying to combine the two approaches. His idea is to engage in an evolutionar y prototyping
methodology and rapidly prototype the features of the system after each evolution.
The specific methodology follows these steps:
• An evolutionary protot ype is constructed and made into a baseline using conventional
development strategies, specifying and implementing only the requirements that are well
understood.
• Copies of the baseline are sent to multiple customer sites along with a trained prototyper.
• At each site, the prototyper watches the user at the system.
• Whenever the user encounters a problem or thinks of a new feature or requirement, the
prototyper logs it. This frees the user from having to record the problem, and allows them
to continue working.
• After the user session is over, the protot yper constructs a throwaway prototype on top of
the baseline system.
• The user now uses the new s ystem and evaluates. If the new changes aren't effective, the
prototyper removes them.
• If the user likes the changes, the protot yper writes feature-enhancement requests and
forwards them to the development team.
• The development team, with the change requests in hand from all the sites, then produce
a new evolutionary prototype using conventional methods.
Obviously, a key to this method is to have well trained protot ypers available to go to the user
sites. The Operational Prototyping methodology has many benefits in systems that are complex
and have few known requirements in advance.

3. Evolutionary systems development

Evolut ionary S ystems Development is a class of methodologies that attempt to formally
implement Evolutionary Prototyping. One particular t ype, called S ystems craft is described b y
John Crinnion in his book: Evolutionary Systems Development.
S ystemscraft was designed as a 'protot ype' methodology that should be modified and
adapted to fit the specific environment in which it was implemented.
S ystemscraft was not designed as a rigid 'cookbook' approach to the development
process. It is now generally recognised[sic] that a good methodology shou ld be flexible enough
to be adjustable to suit all kinds of environment and situation…
The basis of S ystemscraft, not unlike Evolutionary Prototyping, is to create a working s ystem
from the init ial requirements and build upon it in a series o f revisio ns. S ystemscraft places heav y
emphasis on traditional analysis being used throughout the development of the system.

4. Evolutionary rapid development

 Software Engineering

Evolut ionary Rapid Development (ERD) was developed by the Software Productivit y
Consortium, a technology development and integration agent for the Information Technolog y
Office of the Defense Advanced Research Projects Agency (DARPA).
Fundamental to ERD is the concept of co mposing software systems based on the reuse o f
components, the use of software templates and on an architectural template. Continuous
evolution of system capabilities in rapid response to changing user needs and technology is
highlighted by the evolvable architecture, represent ing a class of so lutions. The process focuses
on the use o f small artisan-based teams integrating software and s ystems engineering disciplines
working multiple, often parallel short-duration timeboxes with frequent customer interaction.
Key to the success of the ERD-based projects is parallel exploratory analysis and development of
features, infrastructures, and components with and adoption of leading edge technologies
enabling the quick reaction to changes in technologies, the marketplace, or customer
requirements.
To elicit customer/user input, frequent scheduled and ad hoc/impromptu meetings with the
stakeholders are held. Demonstrations of system capabilit ies are held to solicit feedback before
design/implementation decisions are solidified. Frequent releases (e.g., betas) are made availa ble
for use to provide insight into how the system could better support user and customer needs. This
assures that the system evolves to satisfy existing user needs.
The design framework for the s ystem is based on using exist ing published or de facto
standards. The s ystem is organized to allow for evo lving a set of capabilities that includes
considerations for performance, capacities, and functionalit y. The architecture is defined in terms
of abstract interfaces that encapsulate the services and their implementation (e.g., COTS
applications). The architecture serves as a template to be used for guiding development of more
than a single instance of the system. It allows for multiple application components to be used to
implement the services. A core set of fu nctionality not likely to change is also identified and
established.
The ERD process is structured to use demonstrated functionality rather than paper
products as a way for stakeholders to communicate their needs and expectations. Central to this
goal of rapid delivery is the use of the "time box" method. Timeboxes are fixed periods of time
in which specific tasks (e.g., developing a set of functionalit y) must be performed. Rather than
allowing t ime to expand to satisfy so me vague set of goals, the time is fixed (both in terms o f
calendar weeks and person-hours) and a set of goals is defined that realistically can be achieved
within these constraints. To keep development from degenerating into a "random walk," long-
range plans are defined to guide the iterations. These plans provide a vision for the overall
system and set boundaries (e.g., constraints) for the project. Each iteration within the process is
conducted in the context of these long-range plans.
Once architecture is established, software is integrated and tested on a daily basis. This
allows the team to assess progress objectively and identify potential problems quickly. Since
small amounts of the s ystem are integrated at one time, diagnosing and removing the defect is
rapid. User demonstrations can be held at short notice since the s ystem is generally ready to
exercise at all times.

5. Scrum
Scrum is an agile method for project management. The approach was first described b y
Takeuchi and Nonaka in "The New New Product Development Game" (Harvard Bus iness
Review, Jan-Feb 1986).
 Software Engineering

Tools
Efficient ly using prototyping requires that an organization have proper tools and a staff
trained to use those tools. Tools used in prototyping can vary from individual tools like 4th
generation programming languages used for rapid prototyping to complex integrated CASE
tools. 4th generation programming languages like Visual Basic and ColdFusion are frequently
used since they are cheap, well known and relat ively easy and fast to use. CASE tools are often
developed or selected by the military or large organizations. Users may protot ype elements of an
application themselves in a spreadsheet.

1. Screen generators, design tools & Software Factories

Commonly used screen generat ing programs that enable protot ypers to show users
systems that don't funct ion, but show what the screens may look like. Developing Human
Computer Interfaces can sometimes be the crit ical part of the development effort, since to the
users the interface essentially is the system.
Software Factories are Code Generators that allow you to model the domain model and
then drag and drop the UI. Also they enable you to run the protot ype and use basic database
functionality. This approach allows you to explore the domain model and make sure it is in sync
with the GUI prototype.

2. Application definition or simulation software

It enables users to rapidly build lightweight, animated simulations of another computer
program, without writing code. Application simulation software allows both technical and non-
technical users to experience, test, collaborate and validate the simulated program, and provides
reports such as annotations, screenshot and schematics. To simulate applications one can also use
software which simulate real-world software programs for computer based training,
demonstration, and customer support, such as scr een cast ing software as those areas are closel y
related.

3. Sketchflow
Sketch Flow, a feature of Microsoft Expression Studio Ult imate, gives the ability to quickl y
and effectively map out and iterate the flow of an application UI, the layout of individual screens
and transition from one application state to another.
• Interactive Visual Tool
• Easy to learn
• Dynamic
• Provides enviroment to collect feedback

4. Visual Basic
One of the most popular tools for Rapid Prototyping is Visual Basic (VB). Microsoft Access,
which includes a Visual Basic extensibility module, is also a widely accepted prototyping tool
that is used by many non-technical business analysts. Although VB is a programming language it
has many features that facilitate using it to create prototypes, including:
• An interactive/visual user interface design tool.
• Easy connection of user interface components to underlying functional behavior.
• Modifications to the resulting software are easy to perform.
 Software Engineering

5. Requirements Engineering Environment

It provides an integrated toolset for rapidly represent ing, building, and execut ing models
of critical aspects of complex systems.
It is currently used by the Air Force to develop systems. It is: an integrat ed set of tools
that allows systems analysts to rapidly build functional, user interface, and performance
protot ype models of system co mponents. These modeling activities are performed to gain a
greater understanding of complex systems and lessen the impact that inaccurate requirement
specifications have on cost and scheduling during the system development process.
REE is co mposed of three parts. The first, called proto is a CASE tool specifically
designed to support rapid protot yping. The second part is called the Rapid Interface Prototyping
S ystem or RIP, which is a co llection of tools that facilitate the creation of user interfaces. The
third part of REE is a user interface to RIP and proto that is graphical and intended to be easy to
use.
Rome Laboratory, the developer of REE, intended that to support their internal requirements
gathering methodology. Their method has three main parts:
• Elicitation from various sources which means u lo ose (users, interfaces to other s ystems),
specification, and consistency checking
• Analysis that the needs of diverse users taken together do not conflict and are technicall y
and economically feasible
• Validation that requirements so derived are an accurate reflection of user needs.

6. LYMB
LYMB is an object-oriented development environment aimed at developing applications
that require combining graphics-based user interfaces, visualization, and rapid prototyping.

7. Non-relational environments
Non-relational definition of data (e.g. using Cache or associat ive models can help make
end-user protot yping more productive by dela ying or avoiding the need to normalize data at
every iteration of a simulation. This may yield earlier/greater clarity of business requirements,
though it does not specifically confirm that requirements are technically and econo mically
feasible in the target production system.

8. PSDL
PSDL is a prototype description language to describe real-time software.

Prototyping in the Software Process

System prototyping
• Protot yping is the rapid development of a s ystem
• In the past, the developed system was normally thought of as inferior in some way to the
required system so further development was required
• Now, the boundary between protot yping and normal system development is blurred and
many systems are developed using an evolutionary approach
 Software Engineering

Uses of system prototypes

• The principal use is to help customers and developers understand the requirements for the
system
• Requirements elicitation. Users can experiment with a protot ype to see how the
system supports their work
• Requirements validation. The protot ype can reveal errors and omissio ns in the
requirements
• Prototyping can be considered as a risk reduction activity which reduces requirements risks
Prototyping benefits
• Misunderstandings between software users and developers are exposed
• Missing services may be detected and confusing services may be identified
• A working system is available early in the process
• The prototype may serve as a basis for deriving a system specification
• The system can support user training and system testing

Prototyping process

Establish D e fi n e
Develop Ev aluate
prototype prototype
prototype prototype
objectives functionality

P r ot ot y pi n g Outli ne Executable Evaluation

pl a n definition prototype report

Prototyping in the software process

• Evolutionary prototyping
• An approach to system development where an initial protot ype is produced and
refined through a number of stages to the final system
• Throw-away prototyping
• A protot ype which is usually a practical implementation of the system is produced to
help discover requirements problems and then discarded. The s ystem is then
developed using some other development process

Data Model
• Used to describe the logical structure of data processed by the system
• Entity-relation-attribute model sets out the entit ies in the system, the relationships between
these entities and the entity attributes
• Widely used in database design. Can readily be implemented using relational databases
• No specific notation provided in the UML but objects and associations can be used
 Software Engineering

Behavioural Model
• Behavioural models are used to describe the overall behaviour of a system
• Two types of behavioural model are shown here
• Data processing models that show how data is processed as it moves through the system
• State machine models that show the systems response to events
• Both of these models are required for a description of the system‘s behaviour

1. Data-processing models
• Data flow diagrams are used to model the system‘s data processing
• These show the processing steps as data flows through a system
• Intrinsic part of many analysis methods
• Simple and intuitive notation that customers can understand
• Show end-to-end processing of data

Data flow diagrams

• DFDs model the system from a functional perspective
• Tracking and documenting how the data associated with a process is helpful to develop an
overall understanding of the system
• Data flow diagrams may also be used in showing the data exchange between a s ystem and
other systems in its environment
 Software Engineering

Order processing DFD

2. State machine models

• These model the behaviour of the system in response to external and internal events
• They show the s ystem‘s responses to stimuli so are often used for modelling real-t ime
systems
• State machine models show system states as nodes and events as arcs between these nodes.
• When an event occurs, the system moves from one state to another
• Statecharts are an integral part of the UML

Microwave oven model

 Software Engineering

Statecharts
• Allow the decomposition of a model into submodels
• A brief description of the actions is included following the ‗do‘ in each state
• Can be complemented by tables describing the states and the stimuli

Structured Analysis
• The data-flow approach is typified by the Structured Analysis method (SA)
• Two major strategies dominate structured analysis
• ‗Old‘ method popularised by DeMarco
• ‗Modern‘ approach by Yourdon

DeMarco
• A top-down approach
• The analyst maps the current physical system onto the current logical data-flo w
model
• The approach can be summarised in four steps:
• Analysis of current physical system
• Derivation of logical model
• Derivation of proposed logical model
• Implementation of new physical system

Modern structured analysis

• Dist inguishes between user‘s real needs and those requirements that represent the external
behaviour satisfying those needs
• Includes real-time extensions
• Other structured analysis approaches include:
• Structured Analysis and Design Technique (SADT)
• Structured Systems Analysis and Design Methodology (SSADM)

Method weaknesses
• They do not model non-functional system requirements.
• They do not usually include information about whether a method is appropriate for a given
problem.
• The may produce too much documentation.
• The system models are sometimes too detailed and difficult for users to understand.

CASE workbenches
• A coherent set of tools that is designed to support related software process activities such as
analysis, design or testing.
• Analysis and design workbenches support system modelling during both requirements
engineering and system design.
• These workbenches may support a specific design method or may provide support for a
creating several different types of system model.
 Software Engineering

An analysis and design workbench

Struc tur ed R e po r t
dia g ram m ing gener a tion
tools fac ilities

Ce ntr a l Quer y
i n f o r m a ti o n la ngua ge
re pository facilities

De sign, anal y sis

a nd chec king
tools

• Diagram editors
• Model analysis and checking tools
• Repository and associated query language
• Data dictionary
• Report definition and generation tools
• Forms definition tools
• Import/export translators
• Code generation tools

Data Dictionary
• Data dictionaries are lists of all of the names used in the system models. Descriptions of the
entities, relationships and attributes are also included
• Advantages
• Support name management and avoid duplication
• Store of organisational knowledge linking analysis, design and implementation
• Many CASE workbenches support data dictionaries

Data dictionary entries

 Software Engineering

UNIT III

ANALYSIS, DESIGN CONCEPTS AND PRINCIPLES

Design Concepts and Principles:

• Map the information from the analysis model to the design representations - data design,
architectural design, interface design, procedural design
Analysis to Design:

Design Models – 1:
 Software Engineering

• Data Design
– created by transforming the data dictionary and ERD into implementation data
structures
– requires as much attention as algorithm design
• Architectural Design
– derived from the analysis model and the subsyst em interactions defined in the
DFD
• Interface Design
– derived from DFD and CFD
– describes software elements communication with
• other software elements
• other systems
• human users
Design Models – 2 :
• Procedure-level design
– created by transforming the structural elements defined by the software
architecture into procedural descriptions of software components
– Derived from information in the PSPEC, CSPEC, and STD
Design Principles – 1:
• Process should not suffer from tunnel vision – consider alternative approaches
• Design should be traceable to analysis model
• Do not try to reinvent the wheel
- use design patterns ie reusable components
• Design should exhibit both uniformity and integration
• Should be structured to accommodate changes
Design Principles – 2 :
• Design is not coding and coding is not design
• Should be structured to degrade gently, when bad data, events, or operating conditions
are encountered
• Needs to be assessed for quality as it is being created
• Needs to be reviewed to minimize conceptual (semantic) errors
Design Concepts -1 :
• Abstraction
– allows designers to focus on solving a problem without being concerned about
irrelevant lower level details
Procedural abstraction is a named sequence of instructions that has a specific and limited
function
e.g open a door
Open implies a long sequence of procedural steps
data abstraction is collection of data that describes a data object
e.g door type, opening mech, weight,dimen
Design Concepts -2 :
• Design Patterns
– description of a design structure that solves a particular design problem wit hin a
specific context and its impact when applied
Design Concepts -3 :
 Software Engineering

• Software Architecture
– overall structure of the software components and the ways in which that structure
– provides conceptual integrity for a system
Design Concepts -4 :
• Information Hiding
– information (data and procedure) contained within a module is inaccessible to
modules that have no need for such information
• Functional Independence
– achieved by developing modules with single-minded purpose and an aversion to
excessive interaction with other models
Refactoring – Design concepts :
• Fowler [FOW99] defines refactoring in the following manner:
– "Refactoring is the process of changing a software s ystem in such a way that it
does not alter the external behavior of the code [design] yet improves its internal
structure.ǁ
• When software is refectories, the existing design is examined for
– redundancy
– unused design elements
– inefficient or unnecessary algorithms
– poorly constructed or inappropriate data structures
– or any other design failure that can be corrected to yield a better design.
Design Concepts – 4 :
• Objects
– encapsulate both data and data manipulation procedures needed to describe the
content and behavior of a real world entity
• Class
– generalized descript ion (template or pattern) that describes a collection of similar
objects
• Inheritance
– provides a means for allowing subclasses to reuse exist ing superclass data and
procedures; also provides mechanism for propagating changes
Design Concepts – 5:
• Messages
– the means by which objects exchange information with one another
• Polymorphism
– a mechanism t hat allows several objects in an class hierarchy to have different
methods with the same name
– instances of each subclass will be free to respond to messages by calling their own
version of the method

Modular Design Methodology Evaluation – 1:

Modularit y
– the degree to which software can be understood by examining its co mponents
independently of one another
• Modular decomposability
– provides systematic means for breaking problem into sub problems
 Software Engineering

• Modular compos ability

– supports reuse of existing modules in new systems
• Modular understandability
– module can be understood as a stand-alone unit
Modular Design Methodology Evaluation – 2:
• Modular continuity
– module change side-effects minimized
• Modular protection
– processing error side-effects minimized
Effective Modular Design:
• Functional independence
– modules have high cohesion and low coupling
• Cohesion
– qualitative indication of the degree to which a module focuses on just one thing
• Coupling
– qualitative indication of the degree to which a module is connected to other
modules and to the outside world
Architectural Design:
Why Architecture?
The architecture is not the operational software. Rather, it is a representation that enables a
software engineer to:
(1) analyze the effectiveness of the design in meeting its stated requirements,
(2) consider architectural alternat ives at a stage when making design changes is still relat ivel y
easy, and
(3) reduce the risks associated with the construction of the software.
Importance :
• Software architecture representations enable communications among stakeholders
• Architecture highlights early design decisions that will have a profound impact on the
ultimate success of the system as an operational entity
• The architecture constitutes an intellectually graspable model of how the system is
structured and how its components work together
Architectural Styles – 1:
• Data centered
– file or database lies at the center of this architecture and is accessed frequent ly b y
other components that modify data
Architectural Styles – 2:
• Data flow
– input data is transformed by a series of co mputational co mponents into output
data
– Pipe and filter pattern has a set of components called filters, connected by pipes
that transmit data from one component to the next.
– If the data flow degenerates into a single line of transforms, it is termed batch
sequential
• Object-oriented
– components of system encapsulate data and operations, co mmunication between
components is by message passing
 Software Engineering

• Layered
– several layers are defined
– each layer performs operations that beco me closer to the machine instruction set
in the lower layers
Architectural Styles – 3:
Call and return
– program structure decomposes function into control hierarch y with main program
invoking several subprograms
Software Architecture Design – 1:
• Software to be developed must be put into context
– model external entities and define interfaces
• Identify architectural archetypes
– collection of abstractions that must be modeled if the system is to be constructed
Object oriented Architecture :
• The co mponents 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
Software Architecture Design – 2:
• Specify structure of the system
– define and refine the software components needed to implement each archet ype
• Continue the process iteratively until a complete architectural structure has been derived

Layered Architecture:
• Number of different layers are defined, each accomplishing operations that progressivel y
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 function
Architecture Tradeoff Analysis – 1:
1. Collect scenarios
2. Elicit requirements, constraints, and environmental description
3. Describe architectural styles/patterns chosen to address scenarios and requirements
• module view
• process view
• data flow view
Architecture Tradeoff Analysis – 2:
4. Evaluate quality attributes independently (e.g. reliability, performance, security,
maintainability, flexibility, testability, portability, reusability, interoperability)
5. Identify sensitivity points for architecture
• any attributes significantly affected by changing in the architecture
Refining Architectural Design:
• Processing narrative developed for each module
• Interface description provided for each module
• Local and global data structures are defined
• Design restrictions/limitations noted
• Design reviews conducted
 Software Engineering

• Refinement considered if required and justified

Architectural Design
• An early stage of the system design process.
• Represents the link between specification and design processes.
• Often carried out in parallel with some specification activities.
• It involves identifying major system components and their communications.
Advantages of explicit architecture
• Stakeholder communication
- Architecture may be used as a focus of discussion by system stakeholders.
• System analysis
- Means that analysis of whether the system can meet its non-functional requirements is
possible.
• Large-scale reuse
- The architecture may be reusable across a range of systems.

Architecture and system characteristics

• Performance
- Localise critical operations and minimise communications. Use large rather than fine-
grain components.
• Security
- Use a layered architecture with critical assets in the inner layers.
• Safet y
- Localise safety-critical features in a small number of sub-systems.
• Availability
- Include redundant components and mechanisms for fault tolerance.
• Maintainability
- Use fine-grain, replaceable components.
Architectural conflicts
• Using large-grain components improves performance but reduces maintainability.
• Introducing redundant data improves availability but makes security more difficult.
• Localising safety-related features usually means more communication so degraded
performance.
System structuring
• Concerned with decomposing the system into interacting sub-systems.
• The architectural design is normally expressed as a block diagram present ing an overview o f
the system structure.
• More specific models showing how sub-systems share data, are distributed and interface wit h
each other may also be developed.

Packing robot control system

 Software Engineering

Box and line diagrams

• Very abstract - they do not show the nature of component relationships nor the externall y
visible properties of the sub-systems.
• However, useful for communication with stakeholders and for project planning.
Architectural design decisions
• Architectural design is a creat ive process so the process differs depending on the t ype o f
system being developed.
• However, a number of common decisions span all design processes.
• Is there a generic application architecture that can be used?
• How will the system be distributed?
• What architectural styles are appropriate?
• What approach will be used to structure the system?
• How will the system be decomposed into modules?
• What control strategy should be used?
• How will the architectural design be evaluated?
• How should the architecture be documented?
Architecture reuse
• Systems in the same domain often have similar architectures that reflect domain concepts.
• Application product lines are built around a core architecture with variants that sat isf y
particular customer requirements.
Architectural styles
• The architectural model of a system may conform to a generic architectural model or style.
• An awareness of these styles can simplify the problem of defining system architectures.
• However, most large systems are hetero geneous and do not follow a single architectural
style.
Architectural models
• Used to document an architectural design.
 Software Engineering

• Static structural model that shows the major system components.

• Dynamic process model that shows the process structure of the system.
• Interface model that defines sub-system interfaces.
• Relationships model such as a data-flow model that shows sub-system relationships.
• Distribution model that shows how sub-systems are distributed across computers.
System organisation
• Reflects the basic strategy that is used to structure a system.
• Three organisational styles are widely used:
• A shared data repository style;
• A shared services and servers style;
• An abstract machine or layered style.
The repository model
• Sub-systems must exchange data. This may be done in two ways:
• Shared data is held in a central database or repository and may be accessed by all sub-
systems;
• Each sub-system maintains its own database and passes data explicit ly to other sub-
systems.
• When large amounts of data are to be shared, the repository model of shari ng is most
commonly used.

CASE toolset architecture

Repository model characteristics

Advantages
• Efficient way to share large amounts of data;
• Sub-systems need not be concerned with how data is produced Centralised management
e.g. backup, security, etc.
• Sharing model is published as the repository schema.
Disadvantages
 Software Engineering

• Sub-systems must agree on a repository data model. Inevitably a compromise;

• Data evolution is difficult and expensive;
• No scope for specific management policies;
• Difficult to distribute efficiently.
Client-server model
• Distributed system model which shows how data and processing is distributed across a range
of components.
• Set of stand-alone servers which provide specific services such as printing, data management,
etc.
• Set of clients which call on these services.
• Network which allows clients to access servers.
Client-server characteristics
Advantages
• Distribution of data is straightforward;
• Makes effective use of networked systems. May require cheaper hardware;
• Easy to add new servers or upgrade existing servers.
Disadvantages
• No shared data model so sub-systems use different data organisation. Data
interchange may be inefficient;
• Redundant management in each server;
• No central register of names and services - it may be hard to find out what servers
and services are available.
Abstract machine (layered) model
• Used to model the interfacing of sub-systems.
• Organises the system into a set of la yers (or abstract machines) each of which provide a set
of services.
• Supports the incremental development of sub-systems in different la yers. When a layer
interface changes, only the adjacent layer is affected.
• However, often artificial to structure systems in this way.
Modular decomposition styles
• Styles of decomposing sub-systems into modules.
• No rigid distinction between system organisation and modular decomposition.
Sub-systems and modules
• A sub-s ystem is a s ystem in its own right whose operation is independent of the services
provided by other sub-systems.
• A module is a system co mponent that provides services to other components but would not
normally be considered as a separate system.
• Modular decomposition
• Another structural level where sub-systems are decomposed into modules.
• Two modular decomposition models covered
• An object model where the system is decomposed into interacting object;
• A pipeline or data-flow model where the system is deco mposed into functional
modules which transform inputs to outputs.
• If possible, decisions about concurrency should be delayed until modules are implemented.
Object models
 Software Engineering

• Structure the system into a set of loosely coupled objects with well-defined interfaces.
• Object-oriented decomposition is concerned with identifying object classes, their attributes
and operations.
• When implemented, objects are created from these classes and so me control model used to
coordinate object operations.

Invoice processing system

Object model advantages

• Objects are loosely coupled so their implementation can be modified without affect ing other
objects.
• The objects may reflect real-world entities.
• OO implementation languages are widely used.
• However, object interface changes ma y cause problems and complex entities may be hard to
represent as objects.
Function-oriented pipelining
• Functional transformations process their inputs to produce outputs.
• May be referred to as a pipe and filter model (as in UNIX shell).
• Variants of this approach are very co mmo n. When transformations are sequent ial, this is a
batch sequential model which is extensively used in data processing systems.
• Not really suitable for interactive systems.
User interface design
• Designing effective interfaces for software systems
• System users often judge a system by its interface rather than its functionality
• A poorly designed interface can cause a user to make catastrophic errors
• Poor user interface design is the reason why so many software systems are never used
• Most users of business systems interact with these s ystems through graphical user interfaces
(GUIs)
• In some cases, legacy text-based interfaces are still used
User interface design process
 Software Engineering

Analyse and Produce paper- Evaluate design

und ers tand us er based des ign wi th end-users
activities prototype

Produce
Design Eval uate design
dynamic design
prototype with end-users
prototype

Executable Implement
prototype fin al us er
int erface

UI design principles
• User familiarity
• The interface should be based on user-oriented terms and concepts rather than
computer concepts
• E.g., an office system should use concepts such as letters, documents, folders etc.
rather than directories, file identifiers, etc.
• Consistency
• The system should display an appropriate level of consistency
• Commands and menus should have the same format, command punctuation should be
similar, etc.
• Minimal surprise
• If a co mmand operates in a known wa y, the user should be able to predict the
operation of comparable commands
• Recoverability
• The system should provide some interface to user errors and allow the user to recover
from errors
• User guidance
• Some user guidance such as help systems, on-line manuals, etc. should be supplied
• User diversity
• Interaction facilities for different types of user should be supported
• E.g., some users have seeing difficulties and so larger text should be available
User-system interaction
• Two problems must be addressed in interactive systems design
• How should information from the user be provided to the computer system?
• How should information from the computer system be presented to the user?

Interaction styles
• Direct manipulation
• Easiest to grasp with immediate feedback
• Difficult to program
• Menu selection
• User effort and errors minimized
• Large numbers and combinations of choices a problem
 Software Engineering

• Form fill-in
• Ease of use, simple data entry
• Tedious, takes a lot of screen space
• Natural language
• Great for casual users
• Tedious for expert users
Information presentation
• Information presentation is concerned with presenting system information to system users
• The information may be presented direct ly or may be transformed in so me way for
presentation
• The Model-View-Controller approach is a way of supporting multiple presentations of data
Information display

1
0 10 20
4 2

Dial with needle Pie chart Thermometer Horizontal bar

Displaying relative values

Press ure Temper atu re
0 100 200 300 400 0 25 50 75 100

Textual highlighting

!
The fi lena me y o u have cho sen h as been
us ed. P lea se cho os e an other na me

Ch . 1 6 U ser i nt erface d esi gn

OK Ca ncel

Data visualisation
• Concerned with techniques for displaying large amounts of information
 Software Engineering

• Visualisation can reveal relationships between entities and trends in the data
• Possible data visualisations are:
• Weather information
• State of a telephone network
• Chemical plant pressures and temperatures
• A model of a molecule
Colour displays
• Colour adds an extra dimension to an interface and can help the user understand complex
information structures
• Can be used to highlight exceptional events
• The use of colour to communicate meaning
Error messages
• Error message design is critically important. Poor error messages can mean that a user
rejects rather than accepts a system
• Messages should be polite, concise, consistent and constructive
• The background and experience of users should be the determining factor in message
design
User interface evaluation
• Some evaluation of a user interface design should be carried out to assess its suitability
• Full scale evaluation is very expensive and impractical for most systems
• Ideally, an interface should be evaluated against req
• However, it is rare for such specifications to be produced

Real Time Software Design

• Systems which monitor and control their environment
• Inevitably associated with hardware devices
• Sensors: Collect data from the system environment
• Actuators: Change (in some way) the system's environment
• Time is critical. Real-time systems MUST respond within specified times
• A real-time system is a software system where the correct functioning o f the system depends
on the results produced by the system and the time at which these results are produced
• A ‗soft‘ real-t ime system is a system whose operation is degraded if results are not produced
according to the specified timing requirements
• A ‗hard‘ real-t ime system is a system whose operation is incorrect if results are not produced
according to the timing specification
Stimulus/Response Systems
• Given a stimulus, the system must produce a response within a specified time
• 2 classes
• Periodic stimuli. Stimuli which occur at predictable time intervals
• For example, a temperature sensor may be polled 10 times per second
• Aperiodic stimuli. Stimuli which occur at unpredictable times
• For example, a system power failure may trigger an interrupt which must be
processed by the system
Architectural considerations
 Software Engineering

• Because o f the need to respond to timing demands made by different stimuli / responses, the
system architecture must allow for fast switching between stimulus handlers
• Timing demands of different st imuli are different so a simple sequential loop is not usually
adequate
Real –Time Software Design:
• Designing embedded software systems whose behaviour is subject to timing constraints
• To explain the concept of a real-time system and why these systems are usuall y
implemented as concurrent processes
• To describe a design process for real-time systems
• To explain the role of a real-time executive
• To introduce generic architectures for monitoring and control and data acquisitio n
systems

Real-time systems:
• Systems which monitor and control their environment
• Inevitably associated with hardware devices
– Sensors: Collect data from the system environment
– Actuators: Change (in some way) the system's
environment
• Time is critical. Real-time systems MUST respond within specified times
Definition:
• A real-time system is a software system where the correct functioning of the system
depends on the results produced by the system and the time at which these results are
produced
• A ‗soft‘ real-time system is a system whose operation is degraded if results are not
produced according to the specified timing requirements
• A ‗hard‘ real-time system is a system whose operation is incorrect if results are not
produced according to the timing specification
Stimulus/Response Systems:
• Given a stimulus, the system must produce a esponse within a specified time
• Periodic stimuli. Stimuli which occur at predictable time intervals
– For example, a temperature sensor may be polled 10 times per second
• Aperiodic stimuli. Stimuli which occur at unpredictable times
– For example, a system power failure may trigger an interrupt which must be
processed by the system
Architectural considerations:
• Because of the need to respond to timing demands made by different stimuli/responses,
the system architecture must allow for fast switching between stimulus handlers
• Timing demands of different stimuli are different so a simple sequential loop is not
usually adequate
• Real-time systems are usually designed as cooperating processes with a real-t ime
executive controlling these processes
A real-time system model:
 Software Engineering

Sen so r Sen so r Sen so r Sen so r Sen so r Sen so r

Real-time con
tro l sys tem

Act uat or Act uat or Act uat or Act uat or

System elements:
• Sensors control processes
– Collect information from sensors. May buffer information collected in response to
a sensor stimulus
• Data processor
– Carries out processing of collected information and computes the system response
• Actuator control
– Generates control signals for the actuator
R-T systems design process:
• Identify the stimuli to be processed and the required responses to these stimuli
• For each stimulus and response, identify the timing constraints
• Aggregate the stimulus and response processing into concurrent processes. A process
may be associated with each class of stimulus and response
• Design algorithms to process each class of st imulus and response. These must meet the
given timing requirements
• Design a scheduling s ystem which will ensure that processes are started in t ime to meet
their deadlines
• Integrate using a real-time executive or operating system

Timing constraints:
• May require extensive simulation and experiment to ensure that these are met by the
system
• May mean that certain design strategies such as object-oriented design cannot be used
because of the additional overhead involved
• May mean that low-level programming language features have to be used for
performance reasons
Real-time programming:
• Hard-real time systems may have to programmed in assembly language to ensure that
deadlines are met
• Languages such as C allow efficient pro grams to be written but do not have constructs to
support concurrency or shared resource management
• Ada as a language designed to support real-time systems design so includes a general
purpose concurrency mechanism
Non-stop system components:
 Software Engineering

• Configuration manager
– Responsible for the dynamic reconfiguration of the system
software and hardware. Hardware modules may be replaced and software
upgraded without stopping the systems
• Fault manager
– Responsible for detecting software a nd hardware faults and
taking appropriate actions (e.g. switching to backup disks) to ensure that the
system continues in operation
Burglar alarm system e.g
• A s ystem is required to monitor sensors on doo rs and windows to detect the presence o f
intruders in a building
• When a sensor indicates a break-in, the s ystem switches on lights around the area and
calls police automatically
• The system should include provision for operation without a mains power supply
• Sensors
• Movement detectors, window sensors, door sensors.
• 50 window sensors, 30 door sensors and 200 movement detectors
• Voltage drop sensor
• Actions
• When an intruder is detected, police are called automatically.
• Lights are switched on in rooms with active sensors.
• An audible alarm is switched on.
• The system switches automatically to backup power when a voltage drop is
detected.
The R-T system design process:
• Identify stimuli and associated responses
• Define the timing constraints associated with each stimulus and response
• Allocate system functions to concurrent processes
• Design algorithms for stimulus processing and response generation
• Design a scheduling system which ensures that processes will always be scheduled to
meet their deadlines
Control systems:
• A burglar alarm system is primarily a monitoring system. It collects data from sensors but
no real-time actuator control
• Control systems are similar but, in response to sensor values, the system sends control
signals to actuators
• An example of a mo nitoring and control s ystem is a s ystem which mo nitors temperature
and switches heaters on and off
Data acquisition systems:
• Collect data from sensors for subsequent processing and analysis.
• Data collection processes and processing processes may have different periods and
deadlines.
• Data collection may be faster than processing e.g. collecting information about an
explosion.
• Circular or ring buffers are a mechanism for smoothing speed differences.
 Software Engineering

A temperature control system:

500Hz

Sensor
proces
s

Senso
500Hz r
values

Thermostat
process

Switch
500Hz command Thermostat process
Room number

Heater Furnace
control control
process process

Reactor data collection:

• A system collects data from a set of sensors monitoring the neutron flux from a nuclear
reactor.
• Flux data is placed in a ring buffer for later processing.
• The ring buffer is itself implemented as a concurrent process so that the collection and
processing processes may be synchronized.

Reactor flux monitoring:

Sensors (each data flow is a sensor value)
Sensor
Processed
identifier and
flux level
value
Sensor Sensor data Process Display
process buffer data

Mutual exclusion:
• Producer processes collect data and add it to the buffer. Consumer processes take data
from the buffer and make elements available
 Software Engineering

• Producer and consumer processes must be mutually excluded from accessing the same
element.
The buffer must stop producer processes adding information to a full buffer and consumer
processes trying to take information from an empty buffer

System Design

• Design both the hardware and the software associated with system. Partit ion functions to
either hardware or software
• Design decisions should be made on the basis on non-functional system requirements
• Hardware delivers better performance but potentially lo nger development and less scope for
change

System elements
• Sensors control processes
• Collect information from sensors. May buffer information collected in response t o a
sensor stimulus
• Data processor
• Carries out processing of collected information and computes the system response
• Actuator control
• Generates control signals for the actuator

Sensor/actuator processes
Sen so r Act uat or

St imulus Response

Sensor Dat a Act uat or

con trol p ro ces so r contro l

Hardware and software design

 Software Engineering

Es t ab l is h s ys tem
requ irement s

Parti ti on requ
irement s

So ftware Hardw are

requ ir ement s requ irement s

So ftware Hardw are

d es ig n d es ig n

R-T systems design process

• Identify the stimuli to be processed and the required responses to these stimuli
• For each stimulus and response, identify the timing constraints
• Aggregate the stimulus and response processing into concurrent processes. A process may be
associated with each class of stimulus and response
• Design algorithms to process each class o f stimulus and response. These must meet the given
timing requirements
• Design a scheduling s ystem which will ensure that processes are started in t ime to meet their
deadlines
• Integrate using a real-time executive or operating system

Timing constraints
• For aperiodic stimuli, designers make assumptions about probability of occurrence of stimuli.
• May mean that certain design strategies such as object-oriented design cannot be used
because of the additional overhead involved

State machine modelling

• The effect of a stimulus in a real-t ime s ystem may trigger a transition from one state to
another.
• Finite state machines can be used for modelling real-time systems.
• However, FSM models lack structure. Even simple systems can have a complex model.
• The UML includes notations for defining state machine models

Microwave oven state machine

 Software Engineering

Fu l l
p owe r F u ll p o w e r
d o : se t p o w e r
= 6 00

Ti mer
Wait in g
Nu mb er
d o: di sp lay Op erati on
Fu ll Set ti me
ti me
p ow er d o: get nu mber d o: op erate
e xi t: s e t t im e o ven
H al f
Hal f p ow er
Do or
p ow er Ca ncel
Ti mer clo se d
Do or St art
o pen S y st e m
Hal f p ower faul t Wait in g
E n a bl e d
d o : se t p o w e r Do or d o: di sp lay d o : d i sp l a y
= 3 00 clo sed ' Re ady' ti me

Di s ab l ed
d o: di s p la y
'Wait in g'

Real-time programming
• Hard-real time systems may have to programmed in assembly language to ensure that
deadlines are met
• Languages such as C allow efficient programs to be written but do not have constructs to
support concurrency or shared resource management
• Ada as a language designed to support real-t ime s ystems design so includes a general
purpose concurrency mechanism

Java as a real-time language

• Java supports lightweight concurrency (threads and synchonized methods) and can be used
for some soft real-time systems
• Java 2.0 is not suitable for hard RT pro gramming or programming where prec ise control o f
timing is required
• Not possible to specify thread execution time
• Uncontrollable garbage collection
• Not possible to discover queue sizes for shared resources
• Variable virtual machine implementation
• Not possible to do space or timing analysis

Real Time Executives

• Real-time executives are specialised operating systems which manage processes in the RTS
• Responsible for process management and resource (processor and memory) allocation
• Storage management, fault management.
• Components depend on complexity of system

Executive components
• Real-time clock
• Provides information for process scheduling.
• Interrupt handler
 Software Engineering

• Manages aperiodic requests for service.

• Scheduler
• Chooses the next process to be run.
• Resource manager
• Allocates memory and processor resources.
• Dispatchers
• Starts process execution.

Non-stop system components

• Configuration manager
• Responsible for the d ynamic reconfiguration of the s ystem software and hardware.
Hardware modules may be replaced and software upgraded without stopping the
systems
• Fault manager
• Responsible for detecting software and hardware faults and taking appropriate actions
(e.g. switching to backup disks) to ensure that the system continues in operation
Real-time executive components
Sch edul in g
i nfo rmat io n

Real-t ime Int errup t

Sch edul er
clo ck h an dl er

Pro ces s reso urce

requ irement s

Pro ces ses Avail able

await in g Reso ur ce
r e so u r c e l
reso urces manag er
is t
Ready Releas ed
p ro ces ses reso urces
Ready Pro ces so r
Des pat ch er
l is t l is t

Ex ecut in g
p ro ces s

Process priority
• The processing of some types of stimuli must sometimes take priority
• Interrupt level priority. Highest priority which is allocated to processes requiring a very fast
response
• Clock level priority. Allocated to periodic processes
• Within these, further levels of priority may be assigned

Interrupt servicing
• Control is transferred automatically to a pre-determined memory location
• This location contains an instruction to jump to an interrupt service routine
• Further interrupts are disabled, the interrupt serviced and control returned to the interrupted
process
 Software Engineering

• Interrupt service routines MUST be short, simple and fast

Periodic process servicing

• In most real-time systems, there will be several classes of periodic process, each with
different periods (the time between executions), execution times and deadlines (the time by
which processing must be completed)
• The real-time clock ticks periodically and each tick causes an interrupt which schedules the
process manager for periodic processes
• The process manager selects a process which is ready for execution

Process management
• Concerned with managing the set of concurrent processes
• Periodic processes are executed at pre-specified time intervals
• The executive uses the real-time clock to determine when to execute a process
• Process period - time between executions
• Process deadline - the time by which processing must be complete

RTE process management

Scheduler Resource manager Despatcher
Choo se pro ces s Allocat e memory Start execution on an
for execution and processo r available processor

Process switching
• The scheduler chooses the next process to be executed by the processor. This depends on a
scheduling strategy which may take the process priority into account
• The resource manager allocates memory and a processor for the process to be executed
• The despatcher takes the process from ready list, loads it onto a processor and starts
execution

Scheduling strategies
• Non pre-emptive scheduling
• Once a process has been scheduled for execution, it runs to completion or until it is
blocked for some reason (e.g. waiting for I/O)
• Pre-emptive scheduling
• The execution of an executing processes may be stopped if a higher prio rity process
requires service
• Scheduling algorithms
• Round-robin
• Shortest deadline first

Data Acquisition System

• Collect data from sensors for subsequent processing and analysis.
• Data collection processes and processing processes may have different periods and
deadlines.
 Software Engineering

• Data collection may be faster than processing

e.g. collecting information about an explosion, scientific experiments
• Circular or ring buffers are a mechanism for smoothing speed differences.

Reactor data collection

• A system collects data from a set of sensors monitoring the neutron flux from a nuclear
reactor.
• Flux data is placed in a ring buffer for later processing.
• The ring buffer is itself implemented as a concurrent process so that the collection and
processing processes may be synchronized.

Reactor flux monitoring

Sensors (each data flow is a sensor
v a lu e )
Sensor Processed
identifier flux level
an d valu e
Sensor Sensor data Process
Display
process buffer data

A ring buffer
Producer
proces s

Cons umer
process

Mutual exclusion
• Producer processes collect data and add it to the buffer. Consumer processes take data from
the buffer and make elements available.
• Producer and consumer processes must be mutually excluded from accessing the same
element.
• The buffer must stop producer processes adding information to a full buffer and consumer
processes trying to take information from an empty buffer.

Java implementation of a ring buffer

class CircularBuffer
{
int bufsize ;
SensorRecord [] store ;
 Software Engineering

int numberOfEntries = 0 ;
int front = 0, back = 0 ;

CircularBuffer (int n) {
bufsize = n ;
store = new SensorRecord [bufsize] ;
} // CircularBuffer

synchronized void put (SensorRecord rec ) throws InterruptedException

{
if ( numberOfEntries == bufsize)
wait () ;
store [back] = new SensorRecord ([Link], [Link]) ;
back = back + 1 ;
if (back == bufsize)
back = 0 ;
numberOfEntries = numberOfEntries + 1 ;
notify () ;
} // put

synchronized SensorRecord get () throws InterruptedException

{
SensorRecord result = new SensorRecord (-1, -1) ;
if (numberOfEntries == 0)
wait () ;
result = store [front] ;
front = front + 1 ;
if (front == bufsize)
front = 0 ;
numberOfEntries = numberOfEntries - 1 ;
notify () ;
return result ;
} // get
} // CircularBuffer

Monitoring and Control System

• Important class of real-time systems

• Continuously check sensors and take actions depending on sensor values
• Monitoring systems examine sensors and report their results
• Control systems take sensor values and control hardware actuators
• Burglar alarm system e.g
• A system is required to monitor sensors on doors and windows to detect the presence o f
intruders in a building
• When a sensor indicates a break-in, the s ystem switches on lights around the area and calls
police automatically
 Software Engineering

• The system should include provision for operation without a mains power supply

Burglar alarm system

• Sensors
• Movement detectors, window sensors, door sensors.
• 50 window sensors, 30 door sensors and 200 movement detectors
• Voltage drop sensor
• Actions
• When an intruder is detected, police are called automatically.
• Lights are switched on in rooms with active sensors.
• An audible alarm is switched on.
• The system switches automatically to backup power when a voltage drop is detected.

The R-T system design process

• Identify stimuli and associated responses
• Define the timing constraints associated with each stimulus and response
• Allocate system functions to concurrent processes
• Design algorithms for stimulus processing and response generation
• Design a scheduling system which ensures that processes will always be scheduled to meet
their deadlines
• Stimuli to be processed
• Power failure
• Generated by a circuit monitor. When received, the system must switch to backup
power within 50 ms
• Intruder alarm
• Stimulus generated by system sensors. Response is to call the po lice, switch on
building lights and the audible alarm

Timing requirements

Stimulus/Response Timing requirements

Power fail interrupt The switch to backup power must be completed
within a deadline of 50 ms.
Door alarm Each door alarm should be polled twice per second.
Window alarm Each window alarm should be po lled twice per
second.
Movement detector Each movement detector should be polled twice per
second.
Audible alarm The audible alarm should be switched on wit hin 1/2
second of an alarm being raised by a sensor.
Lights switch The lights should be switched on within 1/2 second
of an alarm being raised by a sensor.
Communications The call to the police should be started within 2
seconds of an alarm being raised by a sensor.
Voice synthesiser A synthesised message should be available wit hin 4
seconds of an alarm being raised by a sensor.
 Software Engineering

Process architecture
4 00 Hz 6 0Hz 1 00 Hz

Movement Door sen so r W i nd ow sen so r

d et ecto r p ro ces s p ro ces s p ro ces s

Det ecto r s tat us Sen so r st at us Sen so r st at us

5 60 Hz Al ar m s ys tem

Bu il di ng mon it or Co mmu ni cat io n

p ro ces s p ro ces s

Power fai lu re
i nt erru pt Bu il di ng mon it or Roo m n umb er

Pow er swi t ch Al arm s ys tem

p ro ces s p ro ces s Al ert mess ag e

Ro om nu mber
Al arm Al arm Al arm s ys tem
s ys tem s ys tem Ro om nu mber
Au di bl e alarm Li ghti ng co nt ro l Vo ice s yn th esi zer p
p ro ces s p ro ces s ro ces s

Building monitor process

class BuildingMonitor extends Thread {

BuildingSensor win, door, move ;

Siren siren = new Siren () ;

Lights lights = new Lights () ;
Synthesizer synthesizer = new Synthesizer () ;
DoorSensors doors = new DoorSensors (30) ; WindowSensors
windows = new WindowSensors (50) ;
MovementSensors movements = new MovementSensors (200) ;
PowerMonitor pm = new PowerMonitor () ;

BuildingMonitor()
{
// initialise all the sensors and start the processes
[Link] () ; [Link] () ;
[Link] () ; [Link] () ;
[Link] () ; [Link] () ; [Link] () ;
}
 Software Engineering

public void run ()

{
int room = 0 ;
while (true)
{
// poll the movement sensors at least twice per second (400 Hz)
move = [Link] () ;
// poll the window sensors at least twice/second (100 Hz)
win = [Link] () ;
// poll the door sensors at least twice per second (60 Hz)
door = [Link] () ;
if ([Link] == 1 | [Link] == 1 | [Link] == 1)
{
// a sensor has indicated an intruder
if ([Link] == 1) room = [Link] ;
if ([Link] == 1) room = [Link] ;
if ([Link] == 1 ) room = [Link] ;

[Link] (room) ; [Link] () ; [Link] (room) ;

break ;
}
}
[Link] () ; [Link] () ; [Link] () ;
[Link] () ; [Link] () ; [Link] () ;

} // run
} //BuildingMonitor

A temperature control system

5 00 Hz

Sen so r
p ro ces s

Sen so r
5 00 Hz valu es

Th ermo st at
p ro ces s

Sw it ch co mmand
5 00 Hz Ro om n u mber Th ermo st at pro ces s

Heat er con tro l Fu rnace

p ro ces s con tro l p ro ces s

Control systems
 Software Engineering

• A burglar alarm system is primarily a monitoring system. It collects data from sensors but no
real-time actuator control
• Control systems are similar but, in response to sensor values, the system sends contro l
signals to actuators
• An example o f a monitoring and control s ystem is a system which mo nitors temperature and
switches heaters on and off

UNIT IV

TESTING
Taxonomy of Software Testing

• Classified by purpose, software testing can be divided into: correctness testing, performance
testing, and reliability testing and security testing.
• Classified by life-cycle phase, software testing can be classified into the fo llowing
categories: requirements phase test ing, design phase testing, program phase testing,
evaluating test results, installation phase testing, acceptance testing and maintenance testing.
• By scope, software testing can be categorized as follows: unit testing, component testing,
integration testing, and system testing.

Correctness testing
Correctness is the minimum requirement of so ftware, the essential purpose of testing. It is
used to tell the right behavior from the wrong one. The tester may or may not know the inside
details of the software module under test, e.g. control flo w, data flow, etc. Therefore, either a
white-box po int of view or black-box point of view can be taken in testing software. We must
note that the black-box and white-box ideas are not limited in correctness testing only.
• Black-box testing
• White-box testing

Performance testing
Not all software systems have specifications on performance explicit ly. But ever y system
will have implicit performance requirements. The software should not take infinite time or
infinite resource to execute. "Performance bugs" sometimes are used to refer to those design
problems in software that cause the system performance to degrade.
Performance has always been a great concern and a driving force of co mputer evo lution.
Performance evaluation of a software s ystem usually includes: resource usage, throughput,
stimulus-response time and queue lengths detailing the average or maximum number of tasks
wait ing to be serviced by selected resources. Typical resources that need to be considered
include network bandwidth requirements, CPU cycles, disk space, disk access operations, and
memory usage. The goal of performance testing can be performance bottleneck ident ification,
performance comparison and evaluation, etc.

Reliability testing
 Software Engineering

Software reliability refers to the probability of failure-free operation of a s ystem. It is

related to many aspects of software, including the testing process. Directly estimating so ftware
reliability by quant ifying its related factors can be difficult. Testing is an effective sampling
method to measure software reliabilit y. Guided by the operational profile, software testing
(usually black-box testing) can be used to obtain failure data, and an estimation model can be
further used to analyze the data to estimate the present reliability and predict future reliability.
Therefore, based on the estimation, the developers can decide whether to release the software,
and the users can decide whether to adopt and use the software. Risk of using software can also
be assessed based on reliability information.

Security testing
Software qualit y, reliability and security are tight ly coupled. Flaws in software can be
exploited by intruders to open security ho les. With the development of the Internet, software
security problems are becoming even more severe.
Many critical software applications and services have integrated security measures against
malicious attacks. The purpose of security testing of these s ystems include identifying and
removing software flaws that may potentially lead to security vio lations, and validat ing the
effectiveness of security measures. Simulated security attacks can be performed to find
vulnerabilities.

Types of S/W Test

Acceptance testing
Testing to verify a product meets customer specified requirements. A customer usuall y
does this type of testing on a product that is developed externally.

Compatibility testing
This is used to ensure compatibilit y of an application or Web site with different browsers,
OSs, and hardware platforms. Compatibilit y testing can be performed manually or can be driven
by an automated functional or regression test suite.

Conformance testing
This is used to verify implementation conformance to industry standards. Producing tests
for the behavior of an implementation to be sure it provides the portabilit y, interoperabilit y,
and/or compatibility a standard defines.

Integration testing
Modules are t ypically code modules, individual applications, client and server
applicat ions on a network, etc. Integration Testing follows unit testing and precedes system
testing.

Load testing
Load testing is a generic term covering Performance Testing and Stress Testing.

Performance testing
 Software Engineering

Performance testing can be applied to understand your application or WWW site's

scalabilit y, or to benchmark the performance in an environment of third party products s uch as
servers and middleware for potential purchase. This sort of testing is particularly useful to
identify performance bottlenecks in high use applications. Performance testing generall y
invo lves an automated test suite as this allows easy simulation of a variety of normal, peak, and
exceptional load conditions.

Regression testing
Similar in scope to a functional test, a regression test allows a consistent, repeatable
validation of each new release of a product or Web site. Such testing ensures reported product
defects have been corrected for each new release and that no new quality problems were
introduced in the maintenance process. Though regression testing can be performed manually an
automated test suite is often used to reduce the time and resources needed to perfo rm the
required testing.

System testing
Entire s ystem is tested as per the requirements. Black-box t ype testing that is based on
overall requirements specifications, covers all combined parts of a system.

End-to-end testing
Similar to system testing, invo lves testing of a complete application environment in a
situation that mimics real-world use, such as interact ing with a database, using network
communications, or interacting with other hardware, applications, or systems if appropriate.

Sanity testing
Testing is to determine if a new software version is performing well enough to accept it
for a major testing effo rt. If application is crashing for initial use then system is not stable
enough for further testing and build or application is assigned to fix.

Alpha testing
In house virtual user environment can be created for this type of testing. Testing is done
at the end of development. Still minor design changes may be made as a result of such testing.

Beta testing
Testing is typically done by end-users or others. This is the final testing before releasing
the application to commercial purpose.

Software Testing Techniques

Software Testing:
Testing is the process of exercising a pro gram with the specific intent of finding errors prior to
delivery to the end user.
Testing Objectives:
• Testing is the process of executing a program with the intent of finding errors.
• A good test case is one with a high probability of finding an as-yet undiscovered error.
• A successful test is one that discovers an as-yet-undiscovered error.
 Software Engineering

Testing Principles:
• All tests should be traceable to customer requirements.
• Tests should be planned before testing begins.
• 80% of all errors are in 20% of the code.
• Testing should begin in the small and progress to the large.
• Exhaustive testing is not possible.
Testing should be conducted by an independent third party if possible.
Software Defect Causes:
• Specification may be wrong.
• Specification may be a physical impossibility.
• Faulty program design.
• Program may be incorrect.

Types of Errors:
• Algorithmic error.
• Computation & precision error.
• Documentation error.
• Capacity error or boundary error.
• Timing and coordination error.
• Throughput or performance error.
• Recovery error.
• Hardware & system software error.
• Standards & procedure errors.
Software Testability Checklist – 1:
• Operability
– if it works better it can be tested more efficiently
• Observability
– what you see is what you test
• Controllability
– if software can be controlled better the it is more that testing can be automated
and optimized
Software Testability Checklist – 2:
• Decomposabilit y
– controlling the scope of testing allows problems to be iso lated quickly and
retested intelligently
• Stability
– the fewer the changes, the fewer the disruptions to testing
• Understandability
– the more information that is known, the smarter the testing can be done
Good Test Attributes:
• A good test has a high probability of finding an error.
• A good test is not redundant.
• A good test should be best of breed.
• A good test should not be too simple or too complex.
Test Strategies:
• Black-box or behavioral testing
 Software Engineering

– knowing the specified function a product is to perform and demo nstrating correct
operation based solely on its specification without regard for its internal logic
• White-box or glass-box testing
– knowing the internal workings of a product, tests are performed to check the
workings of all possible logic paths
White-Box Testing:
Basis Path Testing:
• White-box technique usually based on the program flow graph
• The cyclo matic co mplexity of the pro gram computed from its flow graph using the
formula V(G) = E – N + 2 or by counting the conditional statements in the PDL
representation and adding 1
• Determine the basis set of linearly independent paths (the cardinality of this set is the
program cyclomatic complexity)
• Prepare test cases that will force the execution of each path in the basis set.

Cyclomatic Complexity:
A number of industry studies have indicated that the higher V(G), the higher the probability or
errors.
Control Structure Testing – 1:
• White-box techniques focusing on control structures present in the software
• Condition testing (e.g. branch testing)
– focuses on testing each decision statement in a software module
– it is important to ensure coverage of all logical combinations of data that may be
processed by the module (a truth table may be helpful)
Control Structure Testing – 2:
• Data flow testing
– selects test paths based according to the locations of variable definitio ns and uses
in the program (e.g. definition use chains)
• Loop testing
– focuses on the validity of the program loop constructs (i.e. while, for, go to)
– involves checking to ensure loops start and stop when they are supposed to
(unstructured loops should be redesigned whenever possible)
Loop Testing: Simple Loops:
Minimum conditions—Simple Loops
1. skip the loop entirely
2. only one pass through the loop
3. two passes through the loop
4. m passes through the loop m < n
5. (n-1), n, and (n+1) passes through the loop
where n is the maximum number of allowable passes
Loop Testing: Nested Loops:
Nested Loops
Start at the innermost loop. Set all outer loops to their minimum iteration parameter values.
Test the min+1, t ypical, max-1 and max for the innermost loop, while holding the outer loops at
their minimum values.
 Software Engineering

Move out one loop and set it up as in step 2, holding all other loops at typical values. Continue
this step until the outermost loop has been tested.
Concatenated Loops
If the loops are independent of one another
then treat each as a simple loop
else* treat as nested loops
end if*
for example, the final loop counter value of loop 1 is
used to initialize loop 2.

Black-Box Testing:
Graph-Based Testing – 1:
• Black-box methods based on the nature of the relationships (links) among the pro gram
objects (nodes), test cases are designed to traverse the entire graph
• Transaction flow testing
– nodes represent steps in some transact ion and links represent logical connections
between steps that need to be validated
• Finite state modeling
– nodes represent user observable states of the software and links represent state
transitions
Graph-Based Testing – 2:
• Data flow modeling
– nodes are data objects and links are transformations of one data object to another
data object
• Timing modeling
– nodes are program objects and links are sequential connections bet ween these
objects
– link weights are required execution times
Equivalence Partitioning:
• Black-box technique that divides the input domain into classes of data from which test
cases can be derived
• An ideal test case uncovers a class of errors that might require many arbit rary test cases
to be executed before a general error is observed
Equivalence Class Guidelines:
• If input condition specifies a range, one valid and two invalid equivalence classes are
defined
• If an input condition requires a specific value, one valid and two invalid equivalence
classes are defined
• If an input condition specifies a member of a set, one valid and one invalid equivale nce
class is defined
• If an input condition is Boolean, one valid and one invalid equivalence class is defined
• Boundary Value Analysis - 1
• Black-box technique
– focuses on the boundaries of the input domain rather than its center
• Guidelines:
 Software Engineering

– If input condit ion 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
– If an input condition specifies and number of values, test cases should be exercise
the minimum and maximum numbers, as well as values just above and just below
the minimum and maximum values
Boundary Value Analysis – 2
1. Apply guidelines 1 and 2 to output conditions, test cases should be designed to
produce the minimum and maximum output reports
2. If internal program data structures have bo undaries (e.g. size limitations), be
certain to test the boundaries
Comparison Testing:
• Black-box testing for safety critical s ystems in which independent ly developed
implementations of redundant systems are tested for conformance to specificatio ns
• Often equivalence class partitioning is used to develop a co mmon set of test cases for
each implementation
Orthogonal Array Testing – 1:
• Black-box technique that enables the design of a reasonably small set of test cases that
provide maximum test coverage
• Focus is on categories of faulty logic likely to be present in the software component
(without examining the code)
Orthogonal Array Testing – 2:
• Priorities for assessing tests using an orthogonal array
– Detect and isolate all single mode faults
– Detect all double mode faults
– Multimode faults
Software Testing Strategies:
Strategic Approach to Testing – 1:
• Testing begins at the co mponent level and works outward toward the integration of the
entire computer-based system.
• Different testing techniques are appropriate at different points in time.
• The developer of the software conducts testing and may be assisted by independent test
groups for large projects.
• The ro le of the independent tester is to remove the conflict of interest inherent when the
builder is testing his or her own product.
Strategic Approach to Testing – 2:
• Testing and debugging are different activities.
• Debugging must be accommodated in any testing strategy.
• Need to consider verification issues
– are we building the product right?
• Need to Consider validation issuesare we building the right product?
Verification vs validation:
• Verification:
"Are we building the product right" The software should conform to its specification
Validation:
"Are we building the right product" The software should do what the user really requires
The V & V process:
 Software Engineering

• As a whole life-c ycle process - V & V must be applied at each stage in the software
process.
• Has two principal objectives
– The discovery of defects in a system
– The assessment of whether or not the system is usable in an operational situation.
• Strategic Testing Issues - 1 Specify product requirements in a quant ifiable manner before
testing starts.
• Specify testing objectives explicitly.
• Identify the user classes of the software and develop a profile for each.
• Develop a test plan that emphasizes rapid cycle testing.
Strategic Testing Issues – 2:
• Build robust software that is designed to test itself (e.g. use anti-bugging).
• Use effective formal reviews as a filter prior to testing.
• Conduct formal technical reviews to assess the test strategy and test cases.
Testing Strategy:

Unit Testing:
 Software Engineering

• Program reviews.
• Formal verification.
• Testing the program itself.
– black box and white box testing.
Black Box or White Box?:
• Maximum # of logic paths - determine if white box testing is possible.
• Nature of input data.
• Amount of computation involved.
• Complexity of algorithms.
Unit Testing Details:
• Interfaces tested for proper information flow.
• Local data are examined to ensure that integrity is maintained.
• Boundary conditions are tested.
• Basis path testing should be used.
• All error handling paths should be tested.
• Drivers and/or stubs need to be developed to test incomplete software.

Unit Testing:

Unit Test Environment:

 Software Engineering

Integration Testing:
• Bottom - up testing (test harness).
• Top - down testing (stubs).
• Regression Testing.
• Smoke Testing

Top Down Integration:

Top-Down Integration Testing:

• Main program used as a test driver and stubs are substitutes for components direct ly
subordinate to it.
• Subordinate stubs are replaced one at a t ime with real components (fo llowing the depth-
first or breadth-first approach).
• Tests are conducted as each component is integrated.
• On completion of each set of tests and other stub is replaced with a real component.
 Software Engineering

• Regression testing may be used to ensure that new errors not introduced.
Bottom-Up Integration:

Bottom-Up Integration Testing:

• Low level components are combined in clusters that perform a specific software function.
• A driver (control program) is written to coordinate test case input and output.
• The cluster is tested.
• Drivers are removed and clusters are combined moving upward in the program structure.
Regression Testing:
• The selective retesting of a software s ystem that has been modified to ensure that an y
bugs have been fixed and that no other previously working functions have failed as a
result of the reparations and that newly added features have not created problems wit h
previous versions of the software. Also referred to as verification testing, regression
testing is initiated after a programmer has attempted to fix a recognized problem or has
added source code to a program that may have inadvertent ly introduced errors. It is a
quality control measure to ensure that the newly modified code st ill complies with its
specified requirements and that unmodified code has not been affected by the
maintenance activity.

Regression Testing:
• Regression test suit contains 3 different classes of test cases
– Representative sample of existing test cases is used to exercise all software
functions.
– Additional test cases focusing software functions likely to be affected by the
change.
– Tests cases that focus on the changed software components.
Smoke Testing:
• Software components already translated into code are integrated into a build.
• A series of tests designed to expose errors that will keep the build from performing its
functions are created.
• The build is integrated with the other builds and the ent ire product is smoke tested daily
using either top-down or bottom integration.
Validation Testing:
 Software Engineering

• Ensure that each function or performance characteristic conforms to its specification.

• Deviat ions (deficiencies) must be negotiated with the customer to establish a means for
resolving the errors.
• Configuration review or audit is used to ensure that all elements of the software
configuration have been properly developed, cataloged, and documented to allow its
support during its maintenance phase.
Acceptance Testing:
• Making sure the software works correctly for intended user in his or her normal work
environment.
• Alpha test
– version of the complete software is tested by customer under the supervision of
the developer at the developer‘s site
• Beta test
– version of the complete software is tested by customer at his or her o wn site
without the developer being present
System Testing:
• Recovery testing
– checks system‘s ability to recover from failures
• Security testing
– verifies that s ystem protection mechanism prevents improper penetration or data
alteration
• Stress testing
– program is checked to see how well it deals with abnormal resource demands
• Performance testing
– tests the run-time performance of software
Performance Testing:
• Stress test.
• Volume test.
• Configuration test (hardware & software).
• Compatibility.
• Regression tests.
• Security tests.
• Timing tests.
• Environmental tests.
• Quality tests.
• Recovery tests.
• Maintenance tests.
• Documentation tests.
• Human factors tests.
Testing Life Cycle:
• Establish test objectives.
• Design criteria (review criteria).
– Correct.
– Feasible.
– Coverage.
– Demonstrate functionality.
 Software Engineering

• Writing test cases.

• Testing test cases.
• Execute test cases.
• Evaluate test results.
Testing Tools:
• Simulators.
• Monitors.
• Analyzers.
• Test data generators.
Document Each Test Case:
• Requirement tested.
• Facet / feature / path tested.
• Person & date.
• Tools & code needed.
• Test data & instructions.
• Expected results.
• Actual test results & analysis
• Correction, schedule, and signoff.
Debugging:
• Debugging (removal of a defect) occurs as a consequence of successful testing.
• Some people better at debugging than others.
• Is the cause of the bug reproduced in another part of the program?
• What ―next bugǁ might be introduced by the fix that is being proposed?
• What could have been done to prevent this bug in the first place?

Software Implementation techniques

• Implementation techniques include imperative languages (object-oriented or procedural),
functional languages, and logic languages.
• Software Implementation Techniques include process and thread scheduling, synchronization
and concurrency primitives, file management, memory management, performance,
networking facilities, and user interfaces. Software Implementation Techniques is designed
to facilitate determining what is required to implement a specific operating system function.

Procedural programming
Procedural programming can so metimes be used as a synonym for imperative
programming (specifying the steps the program must take to reach the desired state), but can also
refer (as in this article) to a programming paradigm, derived from structured programming, based
upon the concept of the procedure call. Procedures, also known as routines, subroutines,
methods, or functions (not to be confused with mathemat ical functions, but similar to those used
in funct ional programming) simply contain a series of co mputational steps to be carried out. Any
given procedure might be called at any point during a program's execut ion, including by other
procedures or itself. Some good examples of procedural pro grams are t he Linux Kernel, GIT,
Apache Server, and Quake III Arena.

Object-oriented programming
 Software Engineering

Object-oriented programming (OOP) is a programming paradigm that uses "objects" –

data structures consist ing of data fields and methods together with their interactions – to design
applications and computer programs. Programming techniques may include features such as data
abstraction, encapsulation, modularity, polymorphism, and inheritance. Many modern
programming languages now support OOP.
An object-oriented program may thus be viewed as a co llection of interact ing objects, as
opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to
perform. In OOP, each object is capable o f receiving messages, processing data, and sending
messages to other objects. Each object can be viewed as an independent 'machine' with a dist inct
role or responsibilit y. The actions (or "methods") on these objects are closely associated with the
object. For example, OOP data structures tend to 'carry their own operators around with them' (or
at least "inherit" them from a similar object or class). In the convent ional model, the data and
operations on the data don't have a tight, formal association.

functional p rogramming is a programming paradigm that treats computation as the evaluation

of mathematical functions and avoids state and mutable data. It emphasizes the application of
funct ions, in contrast to the imperative pro gramming st yle, which emphasizes changes in state.
Functional programming has its roots in lambda calculus, a formal s ystem developed in the
1930s to investigate function definition, function application, and recursion. Many functional
programming languages can be viewed as elaborations on the lambda calculus.
In practice, the difference between a mathemat ical function and the notion of a "function"
used in imperative programming is that imperative functions can have side effects, changing the
value of already calculated computations. Because of this they lack referential transparenc y, i.e.
the same language expression can result in different values at different times depending on the
state of the execut ing program. Conversely, in functional code, the output value of a function
depends only on the arguments that are input to the function, so calling a function f twice wit h
the same value for an argument x will produce the same result f (x) both times. Eliminating side
effects can make it much easier to understand and predict the behavior of a pro gram, which is
one of the ke y motivations for the development of functional [Link], one of the
most widely employed languages today, incorporates functional programming capabilities.

Logic programming is, in its broadest sense, the use of mathematical logic for computer
programming. In this view of logic pro grammin g, which can be t raced at least as far back as
John McCarthy's [1958] advice-taker proposal, logic is used as a purely declarative
representation language, and a theorem-prover or model-generator is used as the problem-so lver.
The problem-solving task is split between the programmer, who is respo nsible only for ensuring
the truth of programs expressed in logical form, and the theorem-prover or model-generator,
which is responsible for solving problems efficiently.

Oracle’s Application Implementation Method

AIM provides with an integrated set of templates, procedures, PowerPo int presentations,
spreadsheets, and project plans for implementing the applications. AIM was such a success,
Oracle created a subset of the templates, called it AIM Advantage, and made it available as a
product to customers and other consulting firms. Since its init ial release, AIM has been revised
and improved several times with new templates and methods.
 Software Engineering

AIM Is a Six-Phase Method

Because the Oracle ERP Applicat ions are software modules buy from a vendor, different
implementation methods are used than the techniques used for custom developed s ystems. AIM
has six major phases:
• Definition phase: During this phase, you plan the project, determine business objectives,
and verify the feasibility of the project for given time, resource, and budget limits.
• Operations Analysis phase: Includes documents business requirements, gaps in the
software (which can lead to customizations), and system architecture requirements. Results o f
the analysis should provide a proposal for future business processes, a technical architecture
model, an application architecture model, workarounds for application gaps, performance testing
models, and a transition strategy to migrate to the new systems. Another task that can begin in
this phase is mapping of legacy data to Oracle Application APIs or open interfaces—data
conversion.
• Solution Design phase—Used to create designs for solutions that meet future
business requirements and processes. The design of your future organization co mes alive during
this phase as customizations and module configurations are finalized.
• Build phase—During this phase of AIM, coding and testing of customizations,
enhancements, interfaces, and data conversio ns happens. In addition, one or more conference
room pilots test the integrated enterprise s ystem. The results of the build phase should be a
working, tested business system solution.
• Transition phase—During this phase, the project team delivers the finished
solution to the enterprise. End-user training and support, management of change, and data
conversions are major activities of this phase.
• Production phase—Starts when the system goes live. Technical people work to
stabilize and maintain the system under full transaction loads. Users and the implementation
team begin a series of refinements to minimize unfavorable impacts and realize the business
objectives identified in the definition phase.

Rapid Implementations
In the late 1990s as Y2K approached, customers demanded and consult ing firms discovered
faster ways to implement packaged software applicat ions. The rapid implementation became
possible for certain t ypes of customers. The events that converged in the late 1990s to provide
faster implementations include the following:
• Many smaller companies couldn‘t afford the big ERP project. If the software vendors and
consulting firms were go ing to sell to the ―middle marketǁ companies, they had to
develop more efficient methods.
• Many dotcoms needed a financial infrastructure; ERP applications filled the need, and rapid
implementation methods provided the way.
• The functionality of the software improved a lo t, many gaps were eliminated, and more
companies could implement with fewer customizations.
• After the big, complex companies implemented their ERP systems, the typical
implementation became less difficult.
• The number of skilled consultants and project managers increased significantly.
• Other software vendors started packaging preprogrammed integration po ints to the Oracle
ERP modules.
 Software Engineering

Rapid implementations focus on delivering a predefined set of functionalit y. A key set of

business processes is installed in a standard way to accelerate the implementation schedule.
These projects benefit from the use o f preconfigured modules and predefined business processes.
You get to reuse the analysis and integration testing from other implementations, and you agree
to ignore all gaps by modifying your business to fit the software. Typically, the enterprise will be
allowed some control o ver key decisio ns such as the structure of the chart of accounts. Fixed
budgets are set for training, production support, and data conversions (a limited amount of data).

Phased Implementations
Phased implementations seek to break up the work of an ERP implementation project.
This technique can make the system more manageable and reduce risks, and costs in so me cases,
to the enterprise. In the mid-1990s, 4 or 5 was about the maximum number of applicatio n
modules that could be launched into production at one time. If you bought 12 or 13 applications,
there would be a financial phase that would be followed by phases for the distribution and
manufacturing applications. As implementation techniques improved and Y2K pressures grew in
the late 1990s, more and more companies started launching most of their applications at the same
time. This method became known as the big-bang approach. Now, each co mpany selects a
phased or big-bang approach based on its individual requirements.
Another approach to phasing can be emplo yed by co mpanies with business units at
multiple sites. With this technique, one business unit is used as a template, and all applications
are completely implemented in an initial phase last ing 10–14 months. Then, other sites
implement the applicat ions in cookie-cutter fashion. The cookie-cutter phases are focused on
end-user training and the differences that a site has from the protot ype site. The cookie-cutter
phase can be as short as 9–12 weeks, and these phases can be conducted at several sites
simultaneously. For your reference, we participated in an efficient project where 13 app lications
were implemented big bang–st yle in July at the Chicago site after about 8 months work. A site in
Malaysia went live in October. The Ireland site started up in November. After a holiday break,
the Atlanta business unit went live in Februar y, and t he final site in China started using the
applications in April. Implement ing thirteen application modules at five sites in four countries in
sixteen months was pretty impressive.
Case Studies Illustrating Implementation Techniques
Some pract ical examples from the real world might help to illustrate some of the principles and
techniques of various software implementation methods. These case studies are composites fro m
about 60 implementation projects we have observed during the past 9 years.

Big companies often have a horrible t ime resolving issues and deciding on configuration
parameters because there is so much money involved and each of many sites might want to
control decisions about what it considers its crit ical success factors. For example, we once s aw a
large company argue for over two months about the chart of accounts structure, while eight
consultants from two consult ing firms tried to referee amo ng the feuding operating units.
Another large company labored for more than six months to unify a mast er customer list for a
centralized receivables and decentralized order entry system.
Transition activit ies at large companies need special attention. Training end users can be
a logist ical challenge and can require considerable planning. For example, if you have 800 users
to train and each user needs an average of three classes of two hours each and you have one
month, how many classrooms and instructors do you need? Another example is that loading data
 Software Engineering

from a legacy s ystem can be a problem. If you have one million customers to load into Oracle
receivables at the rate of 5,000/hour and the database administrator allows you to load 20 hours
per day, you have a 10-day task.
Because they spend huge amounts of money on their ERP systems, many big co mpanies
try to optimize the systems and capture specific returns on the investment. However, sometimes
companies can be incredibly insensitive and unco ordinated as they tr y to make money fro m their
ERP software. For example, one business announced at the beginning of a pro ject that the
accounts payable depart ment would be cut from 50–17 emplo yees as soon as the system went
live. Another company decided to centralize about 30 accounting sites into one shared service
center and advised about 60 accountants that they would lo se their jo bs in about a year. Several
of the 60 employees were offered positions on the ERP implementation team.

Small companies have other problems when creating an implementation team. Occasionally, the
small co mpany tries to put clerical emplo yees on the team and they have problems with issue
resolution or some of the ERP concepts. In another case, one small co mpany didn‘t create the
position of project manager. Each department worked on its own modules and ignored the
integration points, testing, and requirements of other users. When Y2K deadlines forced the
system startup, results were disastrous with a cost impact that doubled the cost of the ent ire
project.
Project team members at small companies sometimes have a hard time relating to the cost
of the implementation. We once worked with a company where the pro ject manager (who was
also the database administrator) advised me within the first hour of our meet ing that he thought
consulting charges of $3/minute were outrageo us, and he couldn‘t rationalize how we could
possibly make such a contribution. We agreed a consultant could not contribute $3 in value each
and every minute to his project. However, when I told him we would be able to save him
$10,000/week and make the difference between success and failure, he realized we should get to
work.
Because the small co mpany might be relat ively simple to implement and the technical
staff might be inexperienced with the database and software, it is possible that the technical staff
will be on the crit ical path o f the pro ject. If the database administrator can‘t learn how to handle
the production database by the time the users are ready to go live, you might need to hire so me
temporary help to enable the users to keep to the schedule. In addition, we often s ee small
companies with just a single database administrator who might be working 60 or mo re hours per
week. They feel they can afford to have more DBAs as employees, but they don‘t know how to
establish the right ratio of support staff to user requirements. These companies can burn out a
DBA quickly and then have to deal with the problem of replacing an important skill.
 Software Engineering

UNIT V

SOFTWARE PROJECT MANAGEMENT

Measures and Measurements

• Software measurement is concerned with deriving a numeric value for an attribute of a
software product or process.
• This allows for objective comparisons between techniques and processes.
• Although some companies have introduced measurement programmes, most organisations
still don‘t make systematic use of software measurement.
• There are few established standards in this area.

Software metric
• Any type of measurement which relates to a software system, process or related
documentation
• Lines of code in a program, the Fog index, number of person-days required to
develop a component.
• Allow the software and the software process to be quantified.
• May be used to predict product attributes or to control the software process.
• Product metrics can be used for general predictions or to identify anomalous components.

Predictor and control metrics

Metrics assumptions
• A software property can be measured.
• The relationship exists between what we can measure and what we want to know. We can
only measure internal attributes but are often more interested in external software attributes.
• This relationship has been formalised and validated.
• It may be difficult to relate what can be measured to desirable external quality attributes.

Internal and external attributes

 Software Engineering

The measurement process

• A software measurement process may be part of a quality control process.
• Data collected during this process should be maintained as an organisational resource.
• Once a measurement database has been established, comparisons across projects become
possible.

Product measurement process

Data collection
• A metrics programme should be based on a set of product and process data.
• Data should be collected immediately (not in retrospect) and, if possible, automatically.
• Three types of automatic data collection
• Static product analysis;
• Dynamic product analysis;
• Process data collation.

Data accuracy
• Don‘t collect unnecessary data
• The questions to be answered should be decided in advance and the required data
identified.
• Tell people why the data is being collected.
• It should not be part of personnel evaluation.
• Don‘t rely on memory
• Collect data when it is generated not after a project has finished.
 Software Engineering

Product metrics
• A quality metric should be a predictor of product quality.
• Classes of product metric
• D ynamic metrics which are collected by meas urements made of a program in
execution;
• Static metrics which are collected by measurements made of the system
representations;
• Dynamic metrics help assess efficiency and reliabilit y; static metrics help assess
complexity, understand ability and maintainability.

Dynamic and static metrics

• Dynamic metrics are closely related to software quality attributes
• It is relat ively easy to measure the response time of a system (performance attribute)
or the number of failures (reliability attribute).
• Static metrics have an indirect relationship with quality attributes
• You need to try and derive a relationship between these metrics and properties such
as complexity, understandability and maintainability.

Software product metrics

Software metric Description

Fan in/Fan-out Fan-in is a measure of the number of functions or methods that
call some other function or method (say X). Fan-out is the
number of functions that are called by function X. A high value
for fan-in means that X is t ightly coupled to the rest of the design
and changes to X will have extensive knock-on effects. A high
value for fan-out suggests that the overall complexity of X ma y
be high because of the complexity of the control logic needed to
coordinate the called components.
Length of code This is a measure of the size of a pro gram. Generally, the larger
the size of the code of a co mponent, the more complex and error-
prone that component is likely to be. Length of code has been
shown to be one of the most reliable metrics for predict ing error-
proneness in components.
Cyclomatic complexity This is a measure of the control complexity of a pro gram. This
control complexit y may be related to program understandabilit y. I
discuss how to compute cyclomatic complexity in Chapter 22.
Length of identifiers This is a measure of the average length of dist inct ident ifiers in a
program. The longer the identifiers, the more likely the y are to be
meaningful and hence the more understandable the program.
Depth of conditional This is a measure of the depth of nesting of if-statements in a
nesting program. Deeply nested if statements are hard to understand and
are potentially error-prone.
Fog index This is a measure of the average length of words and sentences in
documents. The higher the value for the Fog index, the more
difficult the document is to understand.
 Software Engineering

Object-oriented metrics

Object-oriented metric Description

Depth of inheritance tree This represents the number of discrete levels in the inheritance
tree where sub-classes inherit attributes and operations
(methods) from super-classes. The deeper the inheritance tree,
the more complex the design. Many different object classes may
have to be understood to understand the object classes at the
leaves of the tree.
Method fan-in/fan-out This is directly related to fan-in and fan-out as described above
and means essentially the same thing. However, it may be
appropriate to make a distinction between calls from other
methods within the object and calls from external methods.
Weighted methods per This is the number of methods that are included in a class
class weighted by the complexity of each method. Therefore, a simple
method may have a complexity of 1 and a large and complex
method a much higher value. The larger the value for this
metric, the more complex the object class. Complex objects are
more likely to be more difficult to understand. They may not be
logically cohesive so cannot be reused effectively as super-
classes in an inheritance tree.
Number of overriding This is the number of operations in a super-class that are over-
operations ridden in a sub-class. A high value for this metric indicates that
the super-class used may not be an appropriate parent for the
sub-class.

Measurement analysis
• It is not always obvious what data means
• Analysing collected data is very difficult.
• Professional statisticians should be consulted if available.
• Data analysis must take local circumstances into account.

Measurement surprises
• Reducing the number of faults in a program leads to an increased number of help desk calls
• The pro gram is now thought of as more reliable and so has a wider more diverse
market. The percentage of users who call the help desk may have decreased but the
total may increase;
• A more reliable system is used in a different way from a s ystem where users work
around the faults. This leads to more help desk calls.

ZIPF’s Law
• Zipf's Law as "the observation that frequency of occurrence of so me event (P), as a function
of the rank (i) when the rank is determined by the above frequenc y o f occurrence, is a power-
law function Pi ~ 1/ia with the exponent a close to unity (1)."
 Software Engineering

• Let P (a random variable) represented the frequency of occurrence of a ke yword in a

program listing.
• It applies to computer programs written in any modern computer language.
• Without empirical proof because it's an obvious finding, that any co mputer program written
in any programming language has a power law distribution, i.e., some keywords are used
more than others.
• Frequency of occurrence of events is inversely proportional to the rank in this frequency o f
occurrence.
• When both are plotted on a log scale, the graph is a straight line.
• we create entities that don't exist except in computer memory at run time; we create lo gic
nodes that will never be tested because it 's impossible to test every lo gic branch; we create
information flows in quantities that are humanly impossible to analyze with a glance;
• Software application is the co mbination of keywords within the context of a solution and not
their quantity used in a program; context is not a trivial task because the context of an
application is attached to the problem being solved and every problem to solve is different
and must have a specific program to solve it.
• Although a program could be syntactically correct, it doesn't mean that t he algorithms
implemented so lve the problem at hand. What's more, a correct program can so lve the wrong
problem. Let's say we have the simple requirement of print ing "Hello, World!" A
syntactically correct solution in Java looks as follows:
• Public class SayHello {
public static void main(String[] args) {
[Link]("John Sena!");
}
}
• This solution is obviously wrong because it doesn't solve the original requirement. This
means that the context of the solution wit hin the pro blem being so lved needs to be
determined to ensure its qualit y. In other words, we need to verify that the output matches the
original requirement.
• Zip's Law can't even say too much about larger systems.

Software Cost Estimation

Software cost components
• Hardware and software costs.
• Travel and training costs.
• Effort costs (the dominant factor in most projects)
• The salaries of engineers involved in the project;
• Social and insurance costs.
• Effort costs must take overheads into account
• Costs of building, heating, lighting.
• Costs of networking and communications.
• Costs of shared facilities (e.g library, staff restaurant, etc.).

Costing and pricing

• Estimates are made to discover the cost, to the developer, of producing a software system.
 Software Engineering

• There is not a simple relationship between the development cost and the price charged to the
customer.
• Broader organisational, economic, political and business considerations influence the price
charged.

Software productivity
• A measure of the rate at which individual engineers involved in software development
produce software and associated documentation.
• Not quality-oriented although quality assurance is a factor in productivity assessment.
• Essentially, we want to measure useful functionality produced per time unit.

Productivity measures
• Size related measures based on some output from the software process. This may be lines o f
delivered source code, object code instructions, etc.
• Function-related measures based on an est imate of the functionality of the delivered
software. Function-points are the best known of this type of measure.

Measurement problems
• Estimating the size of the measure (e.g. how many function points).
• Estimating the total number of programmer months that have elapsed.
• Estimating contractor productivity (e.g. documentation team) and incorporating this
estimate in overall estimate.

Lines of code
• The measure was first proposed when programs were typed on cards with one line per card;
• How does this correspond to statements as in Java which can span several lines or where
there can be several statements on one line.

Productivity comparisons
• The lower level the language, the more productive the programmer
• The same functionality takes more code to implement in a lower-level language than
in a high-level language.
• The more verbose the programmer, the higher the productivity
• Measures o f productivity based on lines o f code suggest that pro grammers who write
verbose code are more productive than programmers who write compact code.

Function Point model

Function points
• Based on a combination of program characteristics
• external inputs and outputs;
• user interactions;
• external interfaces;
• files used by the system.
• A weight is associated with each of these and the function po int count is co mputed b y
multiplying each raw count by the weight and summing all values.
 Software Engineering

• The function point count is modified by complexity of the project

• FPs can be used to estimate LOC depend ing on the average number of LOC per FP for a
given language
• LOC = AVC * number of function points;
• AVC is a language-dependent factor var ying from 200-300 for assemble language to
2-40 for a 4GL;
• FPs are very subjective. They depend on the estimator
• Automatic function-point counting is impossible.

COCOMO model
• An empirical model based on project experience.
• Well-documented, ‗independent‘ model which is not tied to a specific software vendor.
• Long history from init ial version published in 1981 (COCOMO-81) through various
instantiations to COCOMO 2.
• COCOMO 2 takes into account different approaches to software development, reuse, etc.

COCOMO 81

Project Formula Description

complexity
Simple PM = 2.4 (KDSI)
1.05
×M Well-un der stood applications developed b y
s ma l l t e a ms .
Moder ate PM = 3.0 (KDSI)
1.12
×M Mo re co mplex projects where team
members may have limited experien ce of
related systems.
E mb e d d e d PM = 3.6 (KDSI)
1.20
×M Complex projects where the soft ware is part
of a strongly coupled comp lex of hard war e,
software, regulations an d operational
procedures.

COCOMO 2
• COCOMO 81 was developed with the assumption that a waterfall process would be used and
that all software would be developed from scratch.
• Since its formulation, there have been many changes in software engineering pract ice and
COCOMO 2 is designed to accommodate different approaches to software development.

COCOMO 2 models
• COCOMO 2 incorporates a range of sub-models that produce increasingly detailed software
estimates.
• The sub-models in COCOMO 2 are:
• Application composition model. Used when software is composed from exist ing
parts.
• Early design model. Used when requirements are available but design has not yet
started.
• Reuse model. Used to compute the effort of integrating reusable components.
 Software Engineering

• Post-architecture model. Used once the system architecture has been designed and
more information about the system is available.

Use of COCOMO 2 models

Application composition model

• Supports prototyping projects and projects where there is extensive reuse.
• Based on standard estimates of developer productivity in application (object) points/month.
• Takes CASE tool use into account.
• Formula is
o PM = ( NAP (1 - %reuse/100 ) ) / PROD
o PM is the effort in person-months, NAP is the number of application po ints and
PROD is the productivity.

Early design model

• Estimates can be made after the requirements have been agreed.
• Based on a standard formula for algorithmic models
• PM = A ´ SizeB ´ M where
• M = PERS ´ RCPX ´ RUSE ´ PDIF ´ PREX ´ FCIL ´ SCED;
• A = 2.94 in init ial calibration, Size in KLOC, B varies fro m 1.1 to 1.24 depending on
novelty of the project, development flexibilit y, risk management approaches and the
process maturity.

Multipliers
• Multipliers reflect the capability of the developers, the non-functional requirements, the
familiarity with the development platform, etc.
• RCPX - product reliability and complexity;
 Software Engineering

• RUSE - the reuse required;

• PDIF - platform difficulty;
• PREX - personnel experience;
• PERS - personnel capability;
• SCED - required schedule;
• FCIL - the team support facilities.

The reuse model

• Takes into account black-box code that is reused without change and code that has to be
adapted to integrate it with new code.
• There are two versions:
• Black-box reuse where code is not modified. An effort estimate (PM) is computed.
• White-box reuse where code is modified. A size estimate equivalent to the number of
lines of new source code is co mputed. This then adjusts the size est imate for new
code.

Reuse model estimates

• For generated code:
• PM = (ASLOC * AT/100)/ATPROD
• ASLOC is the number of lines of generated code
• AT is the percentage of code automatically generated.
• ATPROD is the productivity of engineers in integrating this code.
• When code has to be understood and integrated:
• ESLOC = ASLOC * (1-AT/100) * AAM.
• ASLOC and AT as before.
• AAM is the adaptation adjustment multiplier computed from the costs of changing
the reused code, the costs of understanding how to integrate the code and the costs of
reuse decision making.

Post-architecture level
• Uses the same formula as the early design model but with 17 rather than 7 associated
multipliers.
• The code size is estimated as:
• Number of lines of new code to be developed;
• Estimate of equivalent number of lines of new code computed using the reuse model;
• An estimate of the number of lines of code that have to be modified according to
requirements changes.
The exponent term
• This depends on 5 scale factors (see next slide). Their sum/100 is added to 1.01
• A co mpany takes on a project in a new domain. The client has not defined the process to be
used and has not allowed time for risk analysis. The company has a CMM level 2 rating.
• Precedenteness - new project (4)
• Development flexibility - no client involvement - Very high (1)
• Architecture/risk resolution - No risk analysis - V. Low .(5)
• Team cohesion - new team - nominal (3)
• Process maturity - some control - nominal (3)
 Software Engineering

• Scale factor is therefore 1.17.

Multipliers
• Product attributes
• Concerned with required characteristics of the software product being developed.
• Computer attributes
• Constraints imposed on the software by the hardware platform.
• Personnel attributes
• Multipliers that take the experience and capabilities of the people working on the
project into account.
• Project attributes
• Concerned with the particular characteristics of the software development project.

Delphi method
The Delphi method is a systematic, interactive forecasting method which relies on a panel
of experts. The experts answer questionnaires in two or more rounds. After each round, a
facilitator provides an anonymous summar y of the experts‘ forecasts fro m the previous round as
well as the reasons they provided for their judgments. Thus, experts are encouraged to revise
their earlier answers in light of the replies of other members of their panel. It is believed that
during this process the range of the answers will decrease and the group will converge towards
the "correct" answer. Finally, the process is stopped after a pre-defined stop criterion (e.g.
number of rounds, achievement of consensus, stabilit y of results) and the mean or median scores
of the final rounds determine the results.
 Software Engineering

The Delphi Technique is an essent ial project management technique that refers to an
information gathering technique in which the opinio ns of those whose opinio ns are most
valuable, traditionally industry experts, is solicited, with the ultimate hope and go al of attaining a
consensus. Typically, the po lling of these industry experts is done on an anonymous basis, in
hopes of attaining opinions that are unfettered by fears or ident ifiabilit y. The experts are
presented with a series of questions in regards to the pro ject, which is typically, but not alwa ys,
presented to the expert by a third-party facilitator, in hopes of elicit ing new ideas regarding
specific project points. The responses from all experts are typically co mbined in the form of an
overall summar y, which is then provided to the experts for a review and for the opportunity to
make further comments. This process t ypically results in consensus within a number of rounds,
and this technique t ypically helps minimize bias, and minimizes the possibility t hat any o ne
person can have too much influence on the outcomes.

Key characteristics
The following key characteristics of the Delphi method help the participants to focus on
the issues at hand and separate Delphi from other methodologies:
• Structuring of information flow
The initial contributions from the experts are collected in the form of answers to
questionnaires and their comments to these answers. The panel director controls the interactions
among the participants by processing the information and filt ering out irrelevant content. This
avoids the negat ive effects of face-to-face panel discussio ns and solves the usual problems o f
group dynamics.
• Regular feedback
Participants co mment on their own forecasts, the responses of others and on the pro gress
of the panel as a who le. At any moment they can revise their earlier statements. While in regular
group meet ings part icipants tend to stick to previously stated opinio ns and often conform too
much to group leader, the Delphi method prevents it.
• Anonymity of the participants
Usually all participants maintain anonymit y. Their identity is not revealed even after the
completion of the final report. This stops them from do minat ing others in the process using their
authority or personalit y, frees them to some extent from their personal biases, minimizes the
"bandwagon effect" or "halo effect", allows them to freely express their opinions, and
encourages open critique and admitting errors by revising earlier judgments.

The first step is to found a steering co mmittee (if you need one) and a management team
with sufficient capacit ies for the process. Then expert panels to prepare and formulate the
statements are helpful unless it is decided to let that be done by the management team. The
whole procedure has to be fixed in advance: Do you need panel meetings or do the teams work
virtually. Is the questionnaire an electronic or a paper one? This means, that logistics (fro m
Internet programming to typing the results from the paper versio ns) have to be organised. Will
there be follow-up work-shops,interviews, presentations? If yes, these also have to be organised
and pre-pared. Printing o f brochures, leaflets, questionnaire, reports have also be considered. The
last organisational point is the interface with the financing organisation if this is different fro m
the management team.
 Software Engineering

Scheduling
Scheduling Principles
• compartmentalization—define distinct tasks
• interdependency—indicate task interrelationship
• effort validation—be sure resources are available
• defined responsibilities—people must be assigned
• defined outcomes—each task must have an output
• defined milestones—review for quality

Effort and Delivery Time

Effo rt
4 4
Ea = m ( t d /t a )

Im possi bl e Ea = effort i n person-m onths

regi on t d = nom i nal del i very ti m e for schedul e
t o = opti m al devel opm ent ti m e (i n term s of cost)
t a = actual del i very ti m e desi red
Ed

Eo

t d t o devel opm ent ti m e

T m i n = 0. 75T d

Empirical Relationship: P vs E
Given Putnam‘s Software Equation (5-3),
E = L3 / (P3t4)
 Software Engineering

Consider a pro ject est imated at 33 KLOC, 12 person- years of effort, with a P of 10K, the
completion time would be 1.3 years
If deadline can be extended to 1.75 years,
E = L3 / (P3t4) ≈ 3.8 p-years vs 12 p-years

Timeline Charts

Effort Allocation
• ―front endǁ activities
• customer communication
• analysis
• design
• review and modification
• construction activities
• coding or code generation
• testing and installation
• unit, integration
• white-box, black box
• regression

Defining Task Sets

 determine type of project
 concept development, new application development, application enhancement,
application maintenance, and reengineering projects
 Software Engineering

 assess the degree of rigor required

 identify adaptation criteria
 select appropriate software engineering tasks

Earned Value Analysis

• Earned value
• is a measure of progress
• enables us to assess the ―percent of completenessǁ of a project using quantitative
analysis rather than rely on a gut feeling
• ―provides accurate and reliable readings of performance from as early as 15 percent
into the project.ǁ

Computing Earned Value

Budgeted cost of work scheduled (BCWS)
• The budgeted cost of work scheduled (BCWS) is determined for each work task represented
in the schedule.
• BCWSi is the effort planned for work task i.
• To determine progress at a given point along the project schedule, the value of BCWS
is the sum of the BCWS i values for all work tasks that should have been completed
by that point in time on the project schedule.
• The BCWS values for all work tasks are su mmed to derive the budget at completion, BAC.
Hence,
• BAC = ∑ (BCWSk) for all tasks k

Budgeted cost of work performed (BCWP)

• Next, the value for budgeted cost of work performed (BCWP) is computed.
• The value for BCWP is the sum of the BCWS values for all work tasks that have
actually been completed by a point in time on the project schedule.
• ―the dist inct ion between the BCWS and the BCWP is that the former represents the budget of
the activities that were planned to be completed and the latter represents the budget of the
activities that actually were completed.ǁ
• Given values for BCWS, BAC, and BCWP, important progress indicators can be computed:
 Schedule performance index, SPI = BCWP/BCWS
 Schedule variance, SV = BCWP – BCWS
 SPI is an indicat ion of the efficiency with which the project is ut ilizing
scheduled resources.

Actual cost of work performed, ACWP

• Percent scheduled for completion = BCWS/BAC
• provides an indication of the percentage of work that should have been completed by
time t.
• Percent complete = BCWP/BAC
• provides a quantitative indication of the percent of completeness of the project at a
given point in time, t.
 Software Engineering

• Actual cost of work performed, ACWP, is the sum of the effort actually expended on work
tasks that have been completed by a po int in time on the project schedule. It is then possible
to compute
 Cost performance index, CPI = BCWP/ACWP
 Cost variance, CV = BCWP – ACWP

Problem
• Assume you are a software project manager and that you‘ve been asked to computer earned
value statistics for a small software project. The project has 56 planned work tasks that are
estimated to require 582 person-da ys to complete. At the time that you‘ve been asked to do
the earned value analysis, 12 tasks have been completed. However, the project schedu le
indicates that 15 tasks should have been completed. The following scheduling data (in
person-days) are available:
• T ask Planned Effort Actual Effort
• 1 12 12.5
• 2 15 11
• 3 13 17
• 4 8 9.5
• 5 9.5 9.0
• 6 18 19
• 7 10 10
• 8 4 4.5
• 9 1 2 1 0
• 10 6 6.5
• 11 5 4
• 12 14 14.5
• 13 16
• 14 6
• 15 8

Error Tracking
• Schedule Tracking
• conduct periodic project status meetings in which each team member reports progress
and problems.
• evaluate the results of all reviews conducted throughout the software engineering
process.
• determine whether formal project milestones (diamo nds in previous slide) have been
accomplished by the scheduled date.
• compare actual start-date to planned start-date for each project task listed in the
resource table
• meet informally with practitioners to obtain their subjective assessment of progress to
date and problems on the horizon.
• use earned value analysis to assess progress quantitatively.
• Progress on an OO Project-I
 Software Engineering

• Technical milestone: OO analysis completed

• All classes and the class hierarchy have been defined and reviewed.
• Class attributes and operations associated with a class have been defined and
reviewed.
• Class relationships (Chapter 8) have been established and reviewed.
• A behavioral model (Chapter 8) has been created and reviewed.
• Reusable classes have been noted.
• Technical milestone: OO design completed
• The set of subsystems (Chapter 9) has been defined and reviewed.
• Classes are allocated to subsystems and reviewed.
• Task allocation has been established and reviewed.
• Responsibilities and collaborations (Chapter 9) have been identified.
• Attributes and operations have been designed and reviewed.
• The communication model has been created and reviewed.
• Progress on an OO Project-II
• Technical milestone: OO programming completed
• Each new class has been implemented in code from the design model.
• Extracted classes (from a reuse library) have been implemented.
• Prototype or increment has been built.
• Technical milestone: OO testing
• The correctness and completeness of OO analysis and design models has been
reviewed.
• A class-responsibility-collaboration network (Chapter 8) has been developed and
reviewed.
• Test cases are designed and class-level tests (Chapter 14) have been conducted for
each class.
• Test cases are designed and cluster testing (Chapter 14) is completed and the classes
are integrated.
• System level tests have been completed.

Software Configuration Management

• Configuration management is all about change control.
• Every software engineer has to be concerned with how changes made to work products are
tracked and propagated throughout a project.
• To ensure quality is maintained the change process must be audited.
 Software Engineering

Software Configuration categories

• Computer programs
– source
– executable
• Documentation
– Technical / user
• Data
– contained within the program
– external data (e.g. files and databases)

Elements of SCM
• Component element
- Tools coupled with file management
• Process element
-Procedures define change management
• Construction element
-Automate construction of software
• Human elements
-Give guidance for activities and process features

Baselines
• A work product becomes a baseline only after it is reviewed and approved.
• Before baseline – changes informal
• Once a baseline is established each change request must be evaluated and verified before it is
processed.
 Software Engineering

Software Configuration Items

• SC I
• Document
• Test cases
• Program component
• Editors, compilers, browsers
– Used to produce documentation.

Configuration Management process

• Identification
• tracking changes to multiple SCI versions
• Version control
• controlling changes before and after customer release
• Change control
• authority to approve and prioritize changes
• Configuration auditing
• ensure changes are made properly
• Reporting
• tell others about changes made

Program evolution dynamics

• Program evolution dynamics is the study of the processes of system change.
• After major empirical studies, Lehman and Belad y proposed that there were a number of
‗laws‘ which applied to all systems as they evolved.
• There are sensible observations rather than laws. They are applicable to large systems
developed by large organisations. Perhaps less applicable in other cases.

Importance of evolution
• Organizations have huge invest ments in their software s ystems - they are crit ical business
assets.
• To maintain the value of these assets to the business, they must be changed and updated.
• The majority of the software budget in large co mpanies is devoted to evo lving exist ing
software rather than developing new software.
 Software Engineering

Software change
• Software change is inevitable
• New requirements emerge when the software is used;
• The business environment changes;
• Errors must be repaired;
• New computers and equipment is added to the system;
• The performance or reliability of the system may have to be improved.
• A key problem for organisations is implement ing and managing change to their exist ing
software systems.

Lehman’s laws

Law Description
Continuing change A program that is used in a real-world environment
necessarily must change or beco me progressively less
useful in that environment.
Increasing complexity As an evo lving program changes, its structure tends to
become more complex. Extra resources must be devoted to
preserving and simplifying the structure.
Large program Program evo lution is a self-regulat ing process. System
evolution attributes such as size, t ime between releases and the
number of reported errors is approximately invariant for
each system release.
Organisational stability Over a program‘s lifetime, its rate of development is
approximately constant and independent of the resources
devoted to system development.
Conservation of Over the lifetime of a system, the incremental change in
familiarity each release is approximately constant.
Continuing growth The functionality offered by systems has to continuall y
increase to maintain user satisfaction.
Declining quality The quality of systems will appear to be declining unless
they are adapted to changes in their operational
environment.
Feedback system Evolution processes incorporate multi-agent, multi-loop
feedback systems and you have to treat them as feedback
systems to achieve significant product improvement.

Applicability of Lehman’s laws

• Lehman‘s laws seem to be generally applicable to large, tailored systems developed by large
organisations.
• Confirmed in more recent work by Lehman on the FEAST project (see further
reading on book website).

• It is not clear how they should be modified for

• Shrink-wrapped software products;
• Systems that incorporate a significant number of COTS components;
 Software Engineering

• Small organisations;
• Medium sized systems.

Software maintenance
• Modifying a program after it has been put into use or delivered.
• Maintenance does not normally involve major changes to the system‘s architecture.
• Changes are implemented by modifying existing components and adding new components to
the system.
• Maintenance is inevitable
• The system requirements are likely to change while the system is being developed because
the environment is changing. Therefore a delivered system won't meet its requirements!
• Systems are tightly coupled with their environment. When a system is installed in an
environment it changes that environment and therefore changes the system requirements.
• Systems MUST be maintained therefore if they
are to remain useful in an environment.

Types of maintenance
• Maintenance to repair software faults
• Code ,design and requirement errors
• Code & design cheap. Requirements most expensive.
• Maintenance to adapt software to a different operating environment
• Changing a system‘s hardware and other support so that it operates in a different
environment (computer, OS, etc.) from its initial implementation.
• Maintenance to add to or modify the system‘s functionality
• Modifying the system to satisfy new requirements for org or business change.

Distribution of maintenance effort

Maintenance costs
• Usually greater than development costs (2* to 100* depending on the application).
 Software Engineering

• Affected by both technical and non-technical factors.

• Increases as software is maintained. Maintenance corrupts the software structure so makes
further maintenance more difficult.
• Ageing software can have high support costs
(e.g. old languages, compilers etc.).

Development/maintenance costs

Maintenance cost factors

• Team stability
• Maintenance costs are reduced if the same staff are invo lved with them for so me
time.
• Contractual responsibility
• The developers of a system may have no contractual responsibility for
maintenance so there is no incentive to design for future change.
• Staff skills
• Maintenance staff are often inexperienced and have limited domain knowledge.
• Program age and structure
• As programs age, their structure is degraded and they b eco me harder to
understand and change.

Maintenance prediction
• Maintenance prediction is concerned with assessing which parts of the system may cause
problems and have high maintenance costs
• Change acceptance depends on the maintainabilit y of the components affected by
the change;
• Implementing changes degrades the system structure and reduces its
maintainability;
• Maintenance costs depend on the number of changes and costs of change depend
on maintainability.

Change prediction
• Predicting the number of changes requires and understanding of the relationships between a
system and its environment.
• Tightly coupled systems require changes whenever the environment is changed.
 Software Engineering

• Factors influencing this relationship are

• Number and complexity of system interfaces;
• Number of inherently volatile system requirements;
• The business processes where the system is used.

Complexity metrics
• Predictions of maintainability can be made by assessing the complexity of system
components.
• Studies have shown that most maintenance effort is spent on a relat ively small number o f
system components of complex system.
• Reduce maintenance cost – replace complex components with simple alternatives.
• Complexity depends on
• Complexity of control structures;
• Complexity of data structures;
• Object, method (procedure) and module size.

Process metrics
• Process measurements may be used to assess maintainability
• Number of requests for corrective maintenance;
• Average time required for impact analysis;
• Average time taken to implement a change request;
• Number of outstanding change requests.
• If any or all of these is increasing, this may indicate a decline in maintainability.
• COCOMO2 model maintenance = understand existing code + develop new code.

Project management
Objectives
• To explain the main tasks undertaken by project managers
• To introduce software project management and to describe its distinctive characteristics
• To discuss project planning and the planning process
 Software Engineering

• To show how graphical schedule representations are used by project management

• To discuss the notion of risks and the risk management process Software project
management
• Concerned with activities invo lved in ensuring that software is delivered on time and o n
schedule and in accordance with the requirements of the organisations develo ing
and procuring the software.
• Project management is needed because software development is always subject to budget
and schedule constraints that are set by the organisation developing the software.

Project planning
• Probably the most time-consuming project management activity.
• Continuous activity from initial concept through to system delivery. Plans must be
regularly revised as new information becomes available.
• Various different t ypes of plan may be developed to support the main software project
plan that is concerned with schedule and budget.

Types of project plan

Plan Description
Quality plan Describes the quality procedures and standards that
will be used in a project.
Validation plan Describes the approach, resources and schedule used
for system validation.
Configuration management Describes the configuration management procedures
Plan and structures to be used.
Maintenance plan Predicts the maintenance requirements of the system,
maintenance costs and effort required.
Development plan. Describes how the skills and experience of the project
team members will be developed.

Project planning process

Establish the project constraints(delivery date, staff, budget)
Make initial assessments of the project parameters (structure, size)
Define project milestones and deliverables
while project has not been completed or cancelled loop
Draw up project schedule
Initiate activities according to schedule
Wait ( for a while )
Review project progress
Revise estimates of project parameters
Update the project schedule
Re-negotiate project constraints and deliverables
if ( problems arise ) then
Initiate technical review and possible revision
end if
end loop
 Software Engineering

project plan
The project plan sets out:
• resources available to the project
• work breakdown
• schedule for the work.

Project plan structure

• Introduction – objective, budget, time
• Project organisation. – roles of people
• Risk analysis. – arising, reduction
• Hardware and software resource requirements.
• Work breakdown. – break project to activity, milestone
• Project schedule. – time, allocation of people
• Monitoring and reporting mechanisms.

Milestones and deliverables

• Milestones are the end-point of a process activity.- report presented to management
• Deliverables are project results delivered to customers.
- milestones need not be deliverables. May be used by project managers. –
not to customers
• The waterfall process allows for the straight forward definition of progress milestones.

Milestones in requirement process

Project scheduling
• Split project into tasks and estimate time and resources required to complete each task.
• Organize tasks concurrently to make optimal
use of workforce.
• Minimize task dependencies to avoid delays
caused by one task waiting for another to complete.
• Dependent on project managers intuition and experience.
 Software Engineering

The project scheduling process

Scheduling problems
• Estimating the difficulty of problems and hence the cost of developing a solution is hard.
• Productivity is not proportional to the number of people working on a task.
• Adding people to a late project makes it later because of communication overheads.
• The unexpected always happens. Always allow contingency in planning.

Bar charts and activity networks

• Graphical notations used to illustrate the project schedule.
• Show project breakdown into tasks. Tasks should not be too small. They should take
about a week or two.
• Activity charts show task dependencies and the critical path.
• Bar charts show schedule against calendar time.

Task durations and dependencies

Activity Duration (days) Dependencies

T1 8
T2 15
T3 15 T1 (M1)
T4 10
T5 10 T2, T4 (M2)
T6 5 T1, T2 (M3)
T7 20 T1 (M1)
T8 25 T4 (M5)
T9 15 T3, T6 (M4)
T10 15 T5, T7 (M7)
T11 7 T9 (M6)
T12 10 T11 (M8)
 Software Engineering

Activity network
1 4/7 /03 15 da y s
15 da y s
M1 T3
8 da ys
T9
T1 5 da y s 4/8/03 2 5/8/03
2 5/7 /03
4/7 /03 T6 M4 M6
M3
star t 2 0 da y s 7 da y s
15 da y s
T7 T11
T2
25/7 /03 11/8/03 5/9/03
10 da y s 10 da y s
M2 M7 M8
T4 T5 15 da y s

T10 10da ys
1 8/7 /03
T12
M5

2 5 da y s
T8 Finish
19/9/03

Activity timeline

4/7 11/7 18/7 2 5 /7 1/8 8/8 1 5 /8 22/8 2 9/8 5/9 12/9 1 9/9

Sta r t
T4
T1
T2
M1

T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T11
M8

T12
Finish
 Software Engineering

Staff allocation

4/7 1 1/7 18/7 2 5/7 1/8 8/8 15/8 2 2/8 2 9/8 5/9 1 2/9 19/9

Fred T4
T8 T11
T12
Ja ne T1
T3
T9
A nne T2
T6 T10

Jim T7

Ma ry T5

Risk management
• Risk management - identifying risks and drawing up plans to minimise their effect on a
project.
• A risk is a probability that some adverse circumstance will occur
• Project risks : affect schedule or resources. eg: loss of experienced designer.
• Product risks: affect the quality or performance of the software being developed.
eg: failure of purchased component.
• Business risks : affect organisation developing software. Eg: competitor
introducing new product.

Software risks

Risk Affects Description

Staff turnover Project Experienced staff will leave the project before it
is finished.
Management change Project There will be a change of organisational
management with different priorities.
Hardware unavailability Project Hardware that is essential for the project will not
be delivered on schedule.
Requirements change Project and product There will be a larger number of changes to the
requirements than anticipated.
Specification delays Project and product Specifications of essential interfaces are not
available on schedule
Size underestimate Project and product The size of the system has been underestimated.
CASE tool under- Product CASE tools which support the project do not
performance perform as anticipated
Technology change Business The underlying technology on which the system
is built is superseded by new technology.
Product competition Business A competitive product is marketed before the
system is completed.
 Software Engineering

Risk management process

• Risk identification
• Identify project, product and business risks;
• Risk analysis
• Assess the likelihood and consequences of these risks;
• Risk planning
• Draw up plans to avoid or minimise the effects of the risk;
• Risk monitoring
• Constantly monitor risks & plans for risk mitigation.

Risk management process

Risk identification
• Discovering possible risk
• Technology risks.
• People risks.
• Organisational risks.
• Tool risk.
• Requirements risks.
• Estimation risks.

Risks and risk types

Risk type Possible risks
Technology The database used in the system cannot process as many transactions per
second as expected.
Software components that should be reused contain defects that limit their
functionality.
People It is impossible to recruit staff with the skills required.
Key staff are ill and unavailable at critical times.
Required training for staff is not available.
Organisational The organisation is restructured so that different management are
responsible for the project.
Organisational financial problems force reductions in the project budget.
Tools The code generated by CASE tools is inefficient.
CASE tools cannot be integrated.
 Software Engineering

Requirements Changes to requirements that require major design rework are proposed.
Customers fail to understand the impact of requirements changes.
Estimation The time required to develop the software is underestimated.
The rate of defect repair is underestimated.
The size of the software is underestimated.

Risk analysis
• Make judgement about probability and seriousness of each identified risk.
• Made by experienced project managers
• Probability may be very low(<10%), low(10-25%), moderate(25-50%), high(50-75%) or
very high(>75%). not precise value. Only range.
• Risk effects might be catastrophic, serious, tolerable or insignificant.

Risk Probability Effects

Organisational financial problems force Low Catastrophic
reductions in the project budget.
It is impossible to recruit staff with the High Catastrophic
skills required for the project.
Key staff are ill at critical times in the Moderate Serious
project.
Software components that should be reused Moderate Serious
contain defects which limit their
functionality.
Changes to requirements that require major Moderate Serious
design rework are proposed.
The organisation is restructured so that High Serious
different management are responsible for
the project.
The database used in the system cannot Moderate Serious
process as many transactions per second as
expected.
The time required to develop the software High S e r i ous
is underestimated.
CASE tools cannot be integrated. High Tolerable
Customers fail to understand the impact of Moderate Tolerable
requirements changes.
Required training for staff is not available. Moderate Tolerable
The rate of defect repair is underestimated. Moderate Tolerable
The size of the software is underestimated. High Tolerable
The code generated by CASE tools is Moderate Insignificant
inefficient.

Risk planning
• Consider each identified risk and develop a strategy to manage that risk.
• categories
 Software Engineering

• Avoidance strategies
• The probability that the risk will arise is reduced;
• Minimisation strategies
• The impact of the risk on the project will be reduced;
• Contingency plans
• If the risk arises, contingency plans are plans to deal with that risk. eg: financial
problems

Risk management strategies

Risk Strategy
Organisational financial Prepare a briefing document for senior management
problems showing how the project is making a very important
contribution to the goals of the business.
Recruitment problems Alert customer of potential difficulties and the
possibility of delays, investigate buying-in
components.
Staff illness Reorganise team so that there is more overlap of work
and people therefore understand each other‘s jobs.
Defective components Replace potentially defective components with
bought-in components of known reliability.
Requirements changes Derive traceability information to assess requirements
change impact, maximise information hiding in the
design.
Organisational restructuring Prepare a briefing document for senior management
showing how the project is making a very important
contribution to the goals of the business.
Database performance Investigate the possibility of buying a higher-
performance database.
Underestimated development Investigate buying in components, investigate use of a
time program generator

Risk monitoring
• Assess each identified risks regularly to decide whether or not it is becoming less or more
probable.
• Also assess whether the effects of the risk have changed.
• Cannot be observed directly. Factors affecting will give clues.
• Each key risk should be discussed at management progress meetings & review.

Risk indicators

Risk type Potential indicators

Technology Late delivery of hardware or support software, many
reported technology problems
People Poor staff morale, poor relationships amongst team member,
job availability
 Software Engineering

Organisational Organisational gossip, lack of action by senior management

Tools Reluctance by team members to use tools, complaints about
CASE tools, demands for higher-powered workstations
Requirements Many requirements change requests, customer complaints
Estimation Failure to meet agreed schedule, failure to clear reported
defects
 LECTURE NOTES ON
SOFTWARE ENGINEERING & OOAD
CODE: MCA -201

By
Asst. Prof. Mrs. Mrs Etuari Oram
Asst. Prof. Mr Sanjib Kumar Nayak
Asst. Prof. Mr Bighnaraj Naik

SYLLABUS
Module I (10 Lectures)

Introductory concepts: Introduction, definition, objectives, Life cycle – Requirements analysis

and specification.

Design and Analysis: Cohesion and coupling, Data flow oriented Design: Transform centered
design, Transaction centered design. Analysis of specific systems likes Inventory control,
Reservation system.
Module II (10 Lectures)

Object-oriented Design: Object modeling using UML, use case diagram, class diagram,
interaction diagrams: activity diagram, unified development process.

Module III (10 Lectures)

Implementing and Testing: Programming language characteristics, fundamentals, languages,

classes, coding style efficiency. Testing: Objectives, black box and white box testing, various
testing strategies, Art of debugging. Maintenance, Reliability and Availability: Maintenance:
Characteristics, controlling factors, maintenance tasks, side effects, preventive maintenance – Re
Engineering – Reverse Engineering – configuration management – Maintenance tools and
techniques. Reliability: Concepts, Errors, Faults, Repair and availability, reliability and
availability models, Recent trends and developments.

Module IV (10 Lectures)

Software quality: SEI CMM and ISO-9001. Software reliability and fault-tolerance, software
project planning, monitoring, and control. Computer-aided software engineering (CASE),
Component model of software development, Software reuse.

Book:

1. Rajib Mall, Fundamentals of Software Engineering, PHI.

2. R.S. Pressman, Software Engineering Practitioner’s Approach, TMH.
3. S.L. Pfleeger, Software Engineering – Theory and Practice, 2nd Edition, Pearson
Education.
4. M.L. Shooman, Software Engineering – Design, Reliability and Management,
McGraw Hill.

Contents

Module: I
Lecture 1: Introduction to Software Engineering

Lecture 2: Definition & Principles of Sofware Engg., Software Characteristics

Lecture 3: Causes & Solution of Software Crisis, Software Application and

2 *Under revision
 processes.

Lecture 4: Software Life Cycles Methods and Description of Classical Water

fall Model.

Lecture 5: Iterative water fall life cycle Model, Prototyping/Rapid

Prototyping Model and Spiral Model

Lecture 6: Software requirement & Specification

Lecture 7: Complex Logic: Decision tree & Decision Table, Specification of

Complex Logic.

Lecture 8: Cohesion and Coupling

Lecture 9: Data Flow Oriented Design

Lecture 10: Transaction Analysis, Inventory Control System

Module II

Module III

Module IV

MODULE-I

Lecture Note: 1

Software:

Software is defined as a collection of programs, procedures, rules, data and associated

documentation. The s/w is developed keeping in mind certain h/w and operating
system consideration commonly known as platform. And engineering means
systematic procedure to develop software. Some of the software characteristics are, it

3 *Under revision
can be engineer or developed and second thing is software is complex in nature.
Important of software are due to much reason as it is used in:
i)Business decision making
Ex- accounting s/w, billing s/w
ii)For scientific research & engineering problem solving.
Ex-weather forecasting system, space research s/w

iii)It is embedded in multifunctional systems such as medical,

telecom entertainment etc.

Ex-s/w for medical patient automation, s/w of GSM/CDMA service provides.

Software Quality

Several quality factors associated with software quality are as following:

• Portability: A software product is said to be portable, if it can be easily made to
work in different operating system environments, in different machines, with
other software products, etc.
• Usability: A software product has good usability, if different categories of users
(i.e. both expert and novice users) can easily invoke the functions of the product.
• Reusability: A software product has good reusability, if different modules of the
product can easily be reused to develop new products.
• Correctness: A software product is correct, if different requirements as specified
in the SRS document have been correctly implemented.
• Maintainability: A software product is maintainable, if errors can be easily
corrected, new functions can be easily added to the product, and the
functionalities of the product can be easily modified, etc.

Types of software:-
Computer s/w is mainly divided into two types.

a)system s/w
Application s/w consists of programs to perform user oriented tasks. System s/w
includes the operating system & all the utilities to enable the computer to run. Ex-
window operating system
b)application s/w

4 *Under revision
Application s/w consists of programs to perform user oriented tasks. Ex-word processor,
database management. Application s/w sits about the system s/w because it needs help of the
system s/w to run.

Program vs Software product

PROGRAMS PRODUCTS
Set of instruction related each other Collection of program designed for specific
task.
Programs are defined by individuals for A sum product is usually developed by a
their personal use. group of engineers working as a team.
Usually small size. Usually large size.
Single user. Large no of users.
Single developer. Team of developer.
Lack proper documentation. Good documentation support.
ADHOC development. Systematic development.
Lack of UI. Good UI.
Have limited functionality. Exhibit more functionality.

programs
Source
Object
code
code documenta
Operating tion
procedure

Types of software products:

-Generic products: [This type of software product are developed by a

organization and sold on open market to any customer], (System software,,
application software )

5 *Under revision
 -Customized (or bespoke) products: This type of software products are
developed by a software contractor and especially for a customer.

-Embedded Product: Combination of both hardware and software

Software Engineering

Application of engineering for development of software is known as software

engineering. It is the systematic, innovative technique and cost effective approach to
develop software. And person involved in developing product is called software
engineer. S/w engineer is a licensed professional engineer who is skilled in engineering
discipline.

Qualities / Skills possessed by a good software engineer:

1. General Skill (Analytical skill, Problem solving skill, Group work skill)
2. Programming Skill (Programming language , Data structure , Algorithm , Tools(
Compiler, Debugger))
3. Communication skill (Verbal , Written, Presentation)
4. Design Skill (s/w engineer must be familiar with several application domain)

Lecture Note : 2

IEEE definition of Software engineering: A systematic, disciplined and quantifiable

approach to the development, operation, maintenance and refinement of software.

Factor in emergence of software engineering:

6 *Under revision
 1. People who are developing software were consistently wrong in their estimation
of time, effort and cost.
2. Reliability and maintainability was difficult of achieved
3. Fixing bug in a delivered software was difficult
4. Delivered software frequently didn’t work
5. Changes in ration of hw to s/w cost
6. Increased cost of software maintenance
7. Increased demand of software
8. Increased demand for large and more complex software system
9. Increasing size of software

S/W ENGINEERING PRINCIPLES:-

Software engineering is a layered technology. The bedrock that supports software

engineering is a quality focus. The foundation for software engineering is the process
layer. Software engineering process is the glue that holds the technology layers together
and enables rational and timely development of computer software. Process defines a
framework for a set of key process areas that must be established for effective delivery of
software engineering technology. The key process areas form the basis for management
control of software projects and establish the context in which technical methods are
applied, work product (models, documents, data, reports, forms, etc.) are produced,
milestones are established, quality is ensured, and change is properly managed.

Software engineering methods provide the technical how-to's for building software. That
encompass requirements analysis, design, program construction, testing, and support.

7 *Under revision
Software engineering methods rely on a set of basic principles that govern each area of
the technology and include modeling activities and other descriptive techniques.

Software engineering tools provide automated or semi-automated support for the

process and the methods. When tools are integrated so that information created by one
tool can be used by another, a system for the support of software development, called
computer-aided software engineering(CASE), is established. CASE combines software,
hardware, and a software engineering database (a repository containing important
information about analysis, design, program construction, and testing) to create a
software engineering environment analogous to CAD/CAE (computer-aided
design/engineering) for hardware.

S/W CHARACTERISICS:-
Characteristics of a s/w can be easily distinguished as of from the h/w.

8 *Under revision
 The change of failure rate over the product lifetime for a typical hardware and a
software product are sketched in above fig.
For hardware products, it can be observed that failure rate is initially high but
decreases as the faulty components are identified and removed. The system then enters
its useful life.
After some time (called product life time) the components wear out, and the failure rate
increases. This gives the plot of hardware reliability over time its characteristics is like
“bath tub” shape.

On the other hand, for software the failure rate is at its highest during integration and
test. As the system is tested, more and more errors are identified and removed resulting
in reduced failure rate. This error removal continues at a slower pace during the useful
life of the product. As the software becomes obsolete no error corrections occurs and the
failure rate remains unchanged.
Therefore after analyzing the facts we can write the key characteristics as follows:-
a)Most s/w s are custom built rather than assembled from existing
components.
b)s/w is developed or engineered not manufactured.
c)s/w is flexible.
d)s/w does not wear out.

9 *Under revision
 Lecture Note : 3

CAUSES AND SOLUTION FOR S/W CRISIS:-

Software engineering appears to be among the few options available to tackle

the present software crisis.
Let us explain the present software crisis in simple words, by considering the
following.
The expenses that organizations all around the world are incurring on software
purchases compared to those on hardware purchases have been showing a worrying
trend over the years (as shown in fig. 1.6)

Organizations are spending larger and larger portions of their budget on software not
only are the software products turning out to be more expensive than hardware, but
also presented lotst of other problems to the customers such as: software products are
difficult to alter, debug, and enhance; use resources non optimally; often fail to meet the
user requirements; are far from being reliable; frequently crash; and are often delivered
late.
Due to ineffective development of the product characterized by inefficient resource
usage and time and cost over-runs.
Other factors are larger problem sizes, lack of adequate training in software
engineering, increasing skill shortage, and low productivity Improvements.

10 *Under revision
S/W crisis from programmer point of view:-

i)Problem of compatibility.
ii)Problem of Portability.
iii)Proclaiming documentation.
iv)Problem of pirated s/w.
v)Problem in co-ordination of work of different people.
vi)Problem of proper maintenance.

S/W crisis from user point of view:-

i)s/w cost is very high.

ii)Price of h/w grows down.
iii)Lack of development specification.
iv)Problem of different s/w versions.
v)Problem of bugs or errors.

S/W Application:-

S/W applications can be grouped into 8 different area as given below.

i)System s/w
ii)Real-time s/w
iii)Embeded s/w
iv)Business s/w
v)PC s/w
vi)AI s/w
vii)Web-based s/w
viii)Engineering & scientific s/w

S/W engineering processes:-

Process: The process is a series of states that involves activities, constraints, resources
that produce an intended output of some kind. Or it is a state that takes some input and
produced output
Software process: A s/w process is a related set of activities & sub processes that are
involved in developing & involving a s/w system. There are four fundamental process
activities carried out by s/w engineering while executing the s/w process are .
i) s/w specification
The functionality of s/w & constraints on its operation must be defined.
ii)s/w development

11 *Under revision
 The s/w that mixes the specification must be produced.
iii)s/w validation
The s/w must be validated to ensure that it performs desired customer activities.
iv)s/w evolution:-
The s/w must evolve to meet changing customer needs with time.
The scenario of s/w process & its sub process are shown below:-

The s/w industry considers the entire s/w development task as a process according to
Booch & Rumbaugh. According to them a process defines who is doing what, when &
how to reach a certain goal.

Generic attributes in a software process:

1. Understandability
2. Visibility
3. Reliability
4. Robustness
5. Adaptability
6. Rapidity
7. Maintainability
8. Supportability

Characteristic of a software process:

1. Understandability
2. Visibility
3. Reliability
4. Robustness
5. Adaptability
6. Rapidity
7. Maintainability
8. Supportability

Software Project:
1. A project is a temporary endeavor undertaken to create a unique product.
2. Temporary means every project has a definite beginning and a definite end.
3. Unique means the product must be different in some ways from all similar
product

12 *Under revision
Software Product:
Outcome of software project is known as software product.

Software process vs software project vs software product

Software Process

Software Project-1 Software Project-2 Software Project-n

Software Product-1 Software Product-2 Software Product-n

13 *Under revision
 Lecture Note : 4

S/W LIFE CYCLE METHOD:-

Introduction:-
A software life cycle model (also called process model) is a descriptive and
diagrammatic representation of the software life cycle. A 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.

In other words, a life cycle model maps the different activities performed to develop
software product from its inception to retirement. Different life cycle models may map
the basic development activities to phases in different ways.

The need for s/w 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 chaos and project failure.

-A software life cycle model defines entry and exit criteria for every phase. A phase can start
only if its phase-entry criteria have been satisfied. So without software life cycle model the entry
and exit criteria for a phase cannot be recognized. Without software life cycle models (such as
classical waterfall model, iterative waterfall model, prototyping model, evolutionary model,
spiral model etc.) it becomes difficult for software project managers to monitor the progress of
the project.

Different s/w life cycle model:-

Many life cycle models have been proposed so far. Each of them has some advantages
as well as some disadvantages. A few important and commonly used life cycle models
are as follows:

[Link] Waterfall Model

b. Iterative Waterfall Model
c. Prototyping Model
d. Evolutionary Model
[Link] Model

14 *Under revision
a. Classical Waterfall Model:
Different phases of the classic waterfall model:-

The classical waterfall model is intuitively the most obvious way to develop software. Though
the classical waterfall model is elegant and intuitively obvious, it is not a practical model in the
sense that it cannot be used in actual software development projects. Thus, this model can be
considered to be a theoretical way of developing software.

Classical waterfall model divides the life cycle into the following phases as shown in
fig.2.1:

-Feasibility Study
-Requirements Analysis and Specification
-Design
-Coding and Unit Testing
-Integration and System Testing
-Maintenance

15 *Under revision
Activities in each phase of the life cycle:

• Activities undertaken during feasibility study: -

The main aim of feasibility study is to determine whether it would be financially and
technically feasible to develop the product. Rough understanding between the team
members about estimate based on the client side requirement. After over all discussion
they search for variety of solution on the basis of kind of resources and time
requirement etc.

Activities undertaken during 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

16 *Under revision
 The goal of the requirements gathering activity is to collect all relevant information
from the customer regarding the product to be developed. This 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.

Activities undertaken during 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. During the design phase the software architecture is derived from the SRS
document. Two distinctly different approaches are available:
-the traditional design approach and
- the object-oriented design approach.

Activities undertaken during coding and unit testing:-

The purpose of the coding and unit testing phase (sometimes called the
implementation phase) of software development 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. During this phase, each module is unit tested to
determine the correct working of all the individual modules. It involves testing each
module in isolation way as this is the most efficient way to debug the errors identified
at this stage.

Activities undertaken during integration and system testing: -

Integration of different modules is undertaken once they have been coded and unit
tested. 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. System testing usually consists of three different kinds of testing
activities:

α – testing: It is the system testing performed by the development team.

β – testing: It is the system testing performed by a friendly set of customers.

17 *Under revision
 acceptance testing: It is the system testing performed by the customer himself after
the product delivery to decide whether to accept or reject the delivered product.

Activities undertaken during maintenance: -

Maintenance of a typical software product requires much more effort than the effort
necessary to develop the product itself. Maintenance involves performing any one or
more of the
following three kinds of activities:

-Correcting errors that were not discovered during the product development phase.
This is
called corrective maintenance.
- Improving the implementation of the system, and enhancing the functionalities of the
system according to the customer’s requirements. It is called perfective 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. It is called adaptive maintenance.

Disadvantages of waterfall model:-

i)It can not handle satisfactorily different types of risks associated with real time s/w
project, because, the requirements have to be pre decided by the client.
ii)Most real life project can’t follow the exact frame sequence of the waterfall model.

18 *Under revision
 Lecture Note : 5

b. ITERATIVE WATERFALL LIFE CYCLE MODEL:-

This waterfall model allows us to correct the error committed during the
developmental phase.
The principle of detecting errors as close to their point of introduction as possible is
known as phase containment of errors. These errors are not possible to be always
detected at their point of occurrence. But, they must be detected as they are possible,
because finding the errors at higher stage causes entire system testing hence cost is
increased/high.

c. PROTYPING/RAPID PROTOTYPING MODEL:-

Development
Requirements Gathering
Maintenance

Initial design

Revised customer Build prototype

requirements
19 *Under revision
 Customer evolution of
prototype
Customer approved

Design
Implementation

Testing

Maintainance

[Fig: Prototyping life cycle model]

This model specify that before the actual system is being built the working model or the
prototype system should be built in. Prototype means dummy, it is a modern and
advance implementation system with limited functional capabilities & is comparatively
inefficient with the actual system.

Need for a prototype in software development

There are several uses of a prototype. An important purpose is to illustrate the input
data formats, messages, reports, and the interactive dialogues to the customer. This is a
valuable mechanism for gaining better understanding of the customer’s needs. The
possibilities may be:
• how the screens might look like
• how the user interface would behave
• how the system would produce outputs

This is something similar to what the architectural designers of a building do;

they show a prototype of the building to their customer. The customer can evaluate
whether he likes it or not and the changes that he would need in the actual product. A
similar thing happens in the case of a software product and its prototyping model.
Another reason for developing a prototype is that it is impossible to get the perfect
product in the first attempt. Many researchers and engineers advocate that if you want
to develop a good product you must plan to throw away the first version. The
experience gained in developing the prototype can be used to develop the final product.
A prototyping model can be used when technical solutions are unclear to the
development team. A developed prototype can help engineers to critically examine the

20 *Under revision
technical issues associated with the product development. Often, major design
decisions depend on issues like the response time of a hardware controller, or the
efficiency of a sorting algorithm, etc. In such circumstances, a prototype may be the best
or the only way to resolve the technical issues.

Examples for prototype model

A prototype of the actual product is preferred in situations such as:

• user requirements are not complete
• technical issues are not clear

ADVANTAGES:-
i)The prototype which is developed is generally discarded after the system is being built
but the experience gain during the development of prototype helps the design issue as
expected from the customer.

ii)Developing a prototype in place of actual system & putting it for customer reference
resolves different technical & design issue as expected from the customer.

d. EVOLUTIONARY/INCREMENTAL LIFE CYCLE MODEL:-

Evolutionary model is based upon principle of incremented developments of the

functional unit & then integrating it for visible. Each incremental version of the product
is a fully functional s/w product providing more features than its previous version.
Each incremental version is tested individually before being integrated into the system.
Development of incremental module do not need large amount of resources for project
development as in the later case. This incremental model, they are developed in
different phases can be useful to the customers as they can be used as standalone units
when they are treated independently.

This evolutionary model can be described as follows:-

C
B
A B
A
A

[A, B, C: Incremental modules developed & developed together]

21 *Under revision
This life cycle model can be defined as follows:

Rough requirements specific

Identification of modules to be developed incrementally

Develop the incremental by iterative waterfall model

Here customer feedback & modify requirements

Develop the modified model

Maintenance

ADVANTAGES:-

i)Exact destination of customer requirements can be known.

ii)It is also reduces the maintenance tasks duration because before delivery of a module,
the customers are consulted.

iii)As the individual module takes place, so final product will contain limited amount of
errors.

iii)It can be built upon object oriented platform which promotes modular s/w
development.

DISADVANTAGES:-

i)It is only helpful for large s/w products because we can find individual modules for
incremental implementation.

ii)It is also used when the customer is ready to receive the product.

22 *Under revision
e. SPIRAL MODEL/RISK MANAGEMENT MODEL:-

This model of s/w development can be described as follows:

RA

Rapid prototype RA

RA Changed requirements

Specification

RA

Design

RA

Implementation

RA

Post delivery maintenance

Retirement

[ RA-Risk analysis ]

------------>maintenance

Development

This model contains the elements from all the other life cycle model along with the
necessary risks involves in each of the developmental phase. So it is called as meta
model.

The Spiral model of software development is shown in below fig. 2.2. The
diagrammatic representation of this model appears like a spiral with many loops. The
exact number of loops in the spiral is not fixed. Each loop of the spiral represents a
phase of the software process. For example, the innermost loop might be concerned
with feasibility study. The next loop with be requirements specification, the next one
with design, and so on. Each phase in this model is split into four sectors (or quadrants)

23 *Under revision
as shown in fig. The activities are carried out during each phase of a spiral model are
described below.
The radial dimension of the full spiral model provided by Bohem in 1988 to represent
the cumulating cost along with the triangular dimension.

-First quadrant (Objective Setting)

• During the first quadrant, it is needed to identify the objectives of the phase.
• Examine the risks associated with these objectives.
- Second Quadrant (Risk Assessment and Reduction)

• A detailed analysis is carried out for each identified project risk.

• Steps are taken to reduce the risks. For example, if there is a risk that the
requirements are inappropriate, a prototype system may be developed.

-Third Quadrant (Development and Validation)

• Develop and validate the next level of the product after resolving the identified
risks.

- Fourth Quadrant (Review and Planning)

• Review the results achieved so far with the customer and plan the next iteration

24 *Under revision
 around the spiral.
• Progressively more complete version of the software gets built with each iteration
around the spiral.

Comparison of different life-cycle models:

The classical waterfall model can be considered as the basic model and all other life
cycle models as embellishments of this model. However, the classical waterfall model
cannot be used in practical development projects, since this model supports no
mechanism to handle the errors committed during any of the phases. This problem may
be overcome in the iterative waterfall model. The iterative waterfall model is probably
the most widely used software development model evolved so far. This model is simple
to understand and use. However, this model is suitable only for well-understood
problems; it is not suitable for very large projects and for projects that are subject to
many risks.

The prototyping model is suitable for projects for which either the user requirements or
the underlying technical aspects are not well understood. It is especially popular for
development of the user-interface part of the projects.

The evolutionary approach is suitable for large problems which can be decomposed
into a set of different modules for incremental development and delivery of the
product. This model is also widely used for object-oriented development projects. Of
course, this model can only be used if the incremental delivery of the system is
acceptable to the customer.

The spiral model is called a meta model since it encompasses all other life cycle models.
Risk handling is inherently built into this model. The spiral model is suitable for
development of technically challenging software products that are prone to several
kinds of risks. However, this model is much more complex than the other models

Another important advantage of the incremental model is that it reduces the

customer’s trauma of getting used to an entirely new system. The gradual introduction
of the product via incremental phases provides time to the customer to adjust to the
new product. Also, from the customer’s financial viewpoint, incremental development
does not require a large upfront capital outlay. The customer can order the incremental
versions as and when he can afford them.

25 *Under revision
 Lecture Note : 6

S/W REQUIREMENT 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

a)Requirements gathering and analysis:-

The goal of the requirements gathering activity is to collect all relevant information
from the customer regarding the product to be developed and analyzed.
This phase is done to clearly understand the customer requirements so that
incompleteness and inconsistencies are removed. This activity begins by collecting all
relevant data regarding the product to be developed from the user and from the
customer through interviews and discussions.

For example, to perform the requirements analysis of a business accounting software

required by an organization, the analyst might interview all the accountants of the
organization to ascertain their requirements. The data collected from such a group of
users usually contain several contradictions and ambiguities, since each user typically
has only a partial and incomplete view of the system. Therefore it is necessary to
identify all ambiguities and contradictions in the requirements phase and resolve them
through further discussions with the customer.

b) Requirements specification:-

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.
The customer requirements identified during the requirements gathering and analysis
activity are organized into a SRS document.
The important components of this document are:
-functional requirements of the system
-nonfunctional requirements of the system
-goal of implementation.

Functional requirements:-

26 *Under revision
 The functional requirements part discusses the functionalities required from the
system. The system is considered to perform a set of high level functions {fi}. The
functional view of the system is shown in fig.3.1. Each function fi of the system can be
considered as a transformation of a set of input data (ii) to the corresponding set of
output data (oi). The user can get some meaningful piece of work done using a high-
level function.

Nonfunctional requirements:-

Nonfunctional requirements deal with the characteristics of the system which cannot
be expressed as functions - such as the maintainability of the system, portability of the
system, usability of the system, etc. It may include:

# reliability issues,
# accuracy of results,
# human - computer interface issues,
# constraints on the system implementation, etc.

Goals of implementation:-

The goals of implementation part documents, some general suggestions regarding

development such as guide trade-off among design goals, document issues as revision
to system functionalities that may required in future, new devices to be supported in
the future, reusability etc.
These are the issues which the developers might keep in their mind during
development so that the developed system may meet some aspects that are not required
immediately.

27 *Under revision
Properties of a good SRS document
• Some of the important properties of a good SRS document are the following:

a)Concise:
The SRS document should be concise and at the same time unambiguous,
consistent, and complete. Verbose and irrelevant descriptions reduce readability
and also increase error possibilities.

b)Structured:
It should be well-structured. A well-structured document is easy to
understand and modify. In practice, the SRS document undergoes several revisions
to cope up with the customer requirements. Often, the customer requirements evolve
over a period of time. Therefore, in order to make the modifications to the SRS
document easy, it is important to make the document well-structured.

c)Black-box view:
It should only specify what the system should do and refrain from
stating how to do these. This means that the SRS document should specify the
external behavior of the system and not discuss the implementation issues. The SRS
document should view the system to be developed as black box, and should specify
the externally visible behavior of the system. For this reason, the SRS document is
also called the black-box specification of a system.

d)Conceptual integrity:
It should show conceptual integrity so that the reader can easily understand it.

e)Response to undesired events:

It should characterize acceptable responses to undesired events. These are
called system response to exceptional conditions.

f)Verifiable:
All requirements of the system as documented in the SRS document should be
verifiable. This means that it should be possible to determine whether or not
requirements have been met in an implementation.

Problems without a SRS document

• The important problems that an organization would face if it does not develop an SRS
document are as follows:
-Without developing the SRS document, the system would not be implemented
according to customer needs.
-Software developers would not know whether what they are

28 *Under revision
 developing is what exactly required by the customer.
-Without SRS document, it will be very much difficult for the maintenance engineers to
understand the functionality of the system.
-It would be very much difficult for user document writers to write the users’ manuals
properly without understanding the SRS document.

Problems with an unstructured specification

• It would be very much difficult to understand that document.
• It would be very much difficult to modify that document.
• Conceptual integrity in that document would not be shown.
• The SRS document might be unambiguous and inconsistent.

29 *Under revision
 Lecture Note : 7

TECHNIQUES FOR REPRESENTING COMPLEX LOGIC:-

Good SRS documents sometimes may have the conditions which are complex & which
may have overlapping interactions & processing sequences. There are two main
techniques available to analyze & represent complex processes logic are.

A) Decision tree
B) Decision table
After these two techniques are finalizing the decision making logic is captured in form
of tree or table. We can automatically find out the test cases to validate the decision
from the decision making logic. These two techniques are widely used in applications of
information theory & switching theory.

Decision tree:
A decision tree gives a graphic view of the processing logic involved in decision
making and the corresponding actions taken. The edges of a decision tree represent
conditions and the leaf nodes represent the actions to be performed depending on the
outcome of testing the condition.
Example: -
Consider Library Membership Automation Software (LMS) where it should support the
following three options:
-New member to join
-Renewal books
-Cancel membership
-New member option-

Decision:
When the 'new member' option is selected, the software asks details about the
member like the member's name, address, phone number, id etc.
Action: If proper information is entered then a membership record for the member is
created and a bill is printed for the annual membership charge plus the security deposit
payable.

Renewal option-
Decision: If the 'renewal' option is chosen, the LMS asks for the member's name and
membership number to check whether he is a valid member or not.

30 *Under revision
Action: If the membership is valid then membership expiry date is updated and the
annual membership bill is printed, otherwise an error message is displayed.

Cancel membership option-

Decision: If the 'cancel membership' option is selected, then the software asks for
member's name and his membership number.
Action: The membership is cancelled, a cheque for the balance amount due to the
member is printed and finally the membership record is deleted from the database.

Decision tree representation of the above example -

The following tree (fig. 3.4) shows the graphical representation of the above example.
After getting information from the user, the system makes a decision and then performs
the corresponding actions. Ask for member’s name, address, etc.
Create membership details Print cheque.

Fig. 3.4: Decision tree for LMS

Decision table
A decision table is used to represent the complex processing logic in a tabular or a
matrix form. The upper rows of the table specify the variables or conditions to be
evaluated. The lower rows specify the actions to be taken when the corresponding
conditions are satisfied. A column in a table is called a rule. A rule implies that if a
condition is true, then the corresponding action is to be executed.

31 *Under revision
Example: -
Consider the previously discussed LMS example. The following decision table (fig. 3.5)
shows how to represent the LMS problem in a tabular form. Here the table is divided
into two parts, the upper part shows the conditions and the lower part shows what
actions are taken. Each column of the table is a rule.

From the above table we can easily understand that, if the valid selection condition is
false then the action taken for this condition is 'display error message'. Similarly, the
actions taken for other conditions can be inferred from the table.

CHARACTERISTICS OF BAD SRS:-

If SRS document is written by novice then it is said to be bad SRS. It might be the
problem of contradiction, incompleteness and ambiguity, other problem that is chances
to occur are:

(a)Over specification:-
Over specification occurs when the SRS document includes how to issue. Ex:- In
case of library automation system we must not record the fact whether the
membership records are sorted in descending order by considering members first
name.
b) Forward Reference:-
This aspect specifies that, we must not include details of the requirements in the
initial stage which will be discussed later in the SRS documents. For example in case of
faster processing, the books may be kept separately by indexing with respect to their
ISBN(International standard book number). These details are irrelevant in the initial
stages 1 & 2 etc.

32 *Under revision
(c)Whish-full Thinking:-
This aspect specifies that requirements those will be difficult to implement need
not be describe/mention in the SRS.

(d)Noise:-
Noise means irrelevant materials associated to software development which might
rarely or not used at all.

Different categories of user of SRS documents & their expectations:-

1. user, customer & marketing personnel
2. s/w developers
3. test engineers
4. user documentation writers
[Link] managers
6. maintenance engineer

SPECIFICATION OF COMPLEX LOGIC:-

There are two type complex logics such as follows:

a)Axiomatic specification
b)Algebraic specification

Axiomatic specification

In axiomatic specification of a system, first-order logic is used to write the pre and post-
conditions to specify the operations of the system in the form of axioms.
The pre-conditions basically capture the conditions that must be satisfied before an
operation. In essence, the pre-conditions capture the requirements on the input
parameters of a function. The post-conditions are the conditions that must be satisfied
when a function completes execution. Thus, the post conditions are essentially
constraints on the results produced for the function execution to be considered
successful.

The following are the sequence of steps that can be followed to systematically develop
the axiomatic specifications of a function:
• It establishes the range of input values over which the function should behave
correctly. And also it finds out other constraints on the input parameters and writes it in
the form of a predicate.
• It specifies a predicate defining the conditions which must hold on the output of the
function.

33 *Under revision
• It establishs the changes made to the function’s input parameters after execution of
the function. Pure mathematical functions do not change their input and therefore this
type of assertion is not necessary for pure functions.
•Now on combining all of the above into pre and post conditions of the function as in
below example
Example1: -
Specify the pre- and post-conditions of a function that takes a real number as argument
and returns half the input value if the input is less than or equal to 100, or else returns
double the value.
f (x : real) : real
pre: x ∈ R
post: {(x≤100) ∈ (f(x) = x/2)} ∈ {(x>100) ∈ (f(x) = 2∈x)}

Algebraic specification

In the algebraic specification technique an object class or type is specified in terms of

relationships existing between the operations defined on that type.

Representation of algebraic specification

Algebraic specifications define a system as a heterogeneous algebra. A heterogeneous
algebra is a collection of different sets on which several operations are defined.
homogeneous algebras are traditional.
A homogeneous algebra consists of a single set and several operations; {I, +, -, *, /}. In
contrast, alphabetic strings together with operations of concatenation and length {A, I,
con, len}, is not a homogeneous algebra, since the range of the length operation is the set
of integers.
Each set of symbols in the algebra, is called a sort of the algebra. To define a
heterogeneous algebra, we first need to specify its signature, the involved operations,
and their domains and ranges. Using algebraic specification, we define the meaning of a
set of interface procedure by using equations. An algebraic specification is usually
presented in four sections.

Types section:-
In this section, the sorts (or the data types) being used is specified.
Exceptions section:-
This section gives the names of the exceptional conditions that might occur when
different operations are carried out. These exception conditions are used in the later
sections of an algebraic specification.
For example, in a queue, possible exceptions are no value (empty queue),
underflow (removal from an empty queue), overflow etc.

34 *Under revision
Syntax section:-
This section defines the signatures of the interface procedures. The collection of sets that
form input domain of an operator and the sort where the output is produced are called
the signature of the operator.
For example, the append operation takes a queue and an element and returns
a new queue. It is represented as:
append: queue x element → queue

Equations section:-

This section gives a set of rewrite rules (or equations) defining the meaning of
the interface procedures in terms of each other. In general, this section is allowed to
contain conditional expressions.
For example, a rewrite rule to identify an empty queue may be written as:
isempty(create()) = true
Example:-
Let us specify a FIFO queue supporting the operations create, append, remove, first, and
isempty where the operations have their usual meaning.
Types:
defines queue uses boolean, integer

Exceptions:
underflow, no value
Syntax:
1. create : φ → queue
2. append : queue x element → queue
3. remove : queue → queue + {underflow}
4. first : queue → element + {no value}
5. isempty : queue → Boolean

Equations:
1. isempty(create()) = true
2. isempty((append(q,e)) = false
3. first(create()) = no value
4. first(append(q,e)) = is isempty(q) then e else first(q)
5. remove(create()) = underflow
6. remove(append(q,e)) = if isempty(q) then create() else
append(remove(q),e)

35 *Under revision
In this example, there are two basic constructors (create and append), one extra
construction operator (remove) and two basic inspectors (first and empty). Therefore,
there are 2 x (1+2) + 0 = 6 equations.
Example:-
Let us specify a data type point supporting the operations create, xcoord, ycoord,
isequal; where the operations have their usual meaning.
Types:
defines point, uses boolean, integer
Syntax:
1. create : integer × integer → point
2. xcoord : point → integer
3. ycoord : point → integer
4. isequal : point × point → Boolean

Equations:
1. xcoord(create(x, y)) = x
2. ycoord(create(x, y)) = y
3. isequal(create(x1, y1), create(x2, y2)) = ((x1 = x2) and (y1 = y2))
In this example, there is only one basic constructor (create), and three basic inspectors
(xcoord, ycoord, and isequal). Therefore, there are only 3 equations.

ORGANISATION OF AN SRS DOCUMENTS:-

1. INTRODUCTION
1.1 purposes
1.2 scopes
1.3 definition acronyms & abbreviation
1.4 references
1.5 overview

2. THE OVERALL DESCRIPTION

2.1 Product Perspective
2.1.1 system interfaces
2.1.2 interfaces
2.1.3 h/w interfaces
2.1.4 s/w interfaces
2.1.5 communications requirements
2.1.6 memory constraints
2.1.7 operation
2.1.8 site adaptation requirements
2.2 product function
2.3 user characteristics
2.4 constraints
2.5 operating environments

36 *Under revision
 2.6 user environments
2.7 assumptions & dependencies
2.8 apportioning of requirements

3. SPECIFIC REQUIREMENTS

3.1 external interfaces

i) user interfaces
ii) h/w interfaces
iii) s/w interfaces
iv) communication interfaces
3.2 functions
3.3 performance requirements
3.4 logical database requirements
3.5 design constraints
3.5.1 standard compliance
3.6 s/w system attribute
3.6.1 reliability
3.6.2 availability
3.6.3 security
3.6.4 maintainability
3.6.5 portability
3.7 organizing the specific requirements
3.7.1 system mode
3.7.2 user class
3.7.3 objects
3.7.4 feature
3.7.5 stimulus
3.7.6 response
3.7.7 functional hierarchy
3.8 additional comments

4. SUPPORTING INFORMATION
4.1 table of content & index
4.2 appendixes

37 *Under revision
 Lecture Note : 8

Cohesion
When function of one module cooperates with another to perform single objective
then module is said to be good cohesion. The primary characteristics of neat module
decomposition are high cohesion and low coupling. Cohesion is a measure of functional
strength of a module. A module having high cohesion and low coupling is said to be
functionally independent of other modules. By the term functional independence, we
mean that a cohesive module performs a single task or function. A functionally
independent module has minimal interaction with other modules. High cohesion has
features of reliability, robustness and reusability where as low cohesion has difficult to
test, reuse even difficult to understand and maintenance.

Classification of cohesion

The different classes of cohesion that a module may possess are described as follows
from lower cohesion to higher where coincidental cohesion worst type and functional is
best type.

Coincidental Logical Temporal Procedural Communicational Sequential Functional

Low High

Coincidental cohesion: A module is said to have coincidental cohesion, if it performs a

set of tasks that relate to each other very loosely. In this case, the module contains a
random collection of functions. It is likely that the functions have been put in the
module out of pure coincidence without any thought or design or parts of the module
grouped arbitrarily. Different functions in module carry out different activities. For
example, in a transaction processing system (TPS), the get-input, print-error, and
summarize-members functions are grouped into one module. The grouping does not
have any relevance to the structure of the problem.

Logical cohesion: A module is said to be logically cohesive, if all elements of the

module perform similar operations, e.g. error handling, data input, data output, etc. An
example of logical cohesion is the case where a set of print functions generating
different output reports are arranged into a single module, such as module contain set
of print functions to generate various type of output report such as salary, grade sheet,
manual report etc. Here parts of the modules are logically categorized to do same thing

38 *Under revision
even if they are different by nature (e.g grouping all mouse and keyboards input
handling routines).

Temporal cohesion: When a module contains functions that are related with each other
and all the functions must be executed in the same time span, then module is said to
exhibit temporal cohesion. For example when computer booted several functions need
to be performed at the same time one by one such as initialization of memory, devices,
loading OS etc. and The set of functions in a single module responsible for initialization,
start-up, shutdown of some process, etc. exhibit temporal cohesion.

Another example we can consider as a functions which called after catching an

exception which closes opened files, give notification to user, create error log etc.

Procedural cohesion: A module is said to possess procedural cohesion, if the set of

functions of the module are all part of a procedure (algorithm)in which certain sequence
of steps have to be carried out for achieving an objective, e.g. the algorithm for
decoding a message. As in the above, the parts/functions of the modules always follow
certain sequence of execution. Another example is function check file permission and
then opened. Plus we can consider the activities included in the trading house can
contain functions login (), place-order (), print-bill (),…log-out() etc which are operate
on different data but flow sequentially.

Communicational cohesion: Communicational cohesion is also called informational

cohesion. Parts/functions of the modules grouped together to operate on same data. A
module is said to have communicational cohesion, if all functions of the module refer to
or update the same data structure, e.g. the set of functions defined on an array or a
stack.

Another example of informational cohesion is let us consider a module name student

which contain various functions like admit student, enter marks, print grade sheet etc
and all the data stored in an array name student record that is defined with in a module.

Sequential cohesion: A module is said to possess sequential cohesion, if the elements of

a module form the parts of sequence, where the output of one function is input to the
next. For example, in a Transaction Processing System, the get-input (), validate-input
(), sort-input () functions are grouped into one module.

Another example in an online store system when customer request for some item
then functions involved are follow as sequence of: create-order(), check-avail() and then
order ().

Functional cohesion: Functional cohesion is said to exist, if different

elements/parts/functions of a module cooperate to achieve a single task. For example,

39 *Under revision
a module containing all the functions required to manage employees’ pay-roll exhibits
functional cohesion such as compute-overtime(), compute-workhr(), compute-
deduction() etc . It is considered one of the most superior cohesion in the module but in
certain cases not achievable and instead communicational cohesion overcome the
solution.

Coupling
Coupling between two modules/classes/components is a measure of the degree of
interdependence or interaction between the two modules or mutual interdependence
between modules. A module having high cohesion and low coupling is said to be
functionally independent of other modules.

Two modules are said to be highly coupled when:

-function calls between two modules involve & shared large chunk of data.
-interaction occurs through shared data.
If two modules interchange large amounts of data, then they are highly
interdependent. The degree of coupling between two modules depends on their
interface complexity. The interface complexity is determined based on the parameter,
no. of parameter etc. Module with low coupling is better.

Classification of Coupling
Classification of the different types of coupling will help to quantitatively estimate the
degree of coupling between two modules. Five types of coupling can occur between any
two modules. These are shown below according to flow of lower coupling to higher,
indicated by an arrow.

Data Stamp Control Common Content

Low High

Data coupling: Two modules are data coupled, if they communicate by using an
elementary data item e.g. an integer, a float, a character, etc such as passing any float
value through function that computes square root. This data item should be problem
related and not used for the control purpose.

Stamp coupling: Two modules are stamp coupled, if they communicate using a
composite data item such as a record in PASCAL or a structure in C and used part of
these data.

Control coupling: Control coupling exists between two modules, if data from one
module is used in another module to direct the order of instructions execution. An
example of control coupling is a flag set in one module and tested in another module.

40 *Under revision
Common coupling: Two modules are common coupled, if they share data through
some global data items. It is also known as global coupling. Example, sharing global
variable. Changing global variable leads changes in all modules.

Content coupling: Also known as pathological coupling. Content coupling exists

between two modules, if they share code, e.g. a branch from one module into another
module or if one module changes on internal working of another module (e.g accessing
local data of another module).

No coupling exists when modules do not communicate with each other.

From the above degree of coupling increases from the data coupling (that has less
interdependency, coordination and data flow) to content coupling(that has high
interdependency, coordination and information flow). Other coupling may be there but
not given in the book.

High coupling among modules makes design solution difficult to understand and
maintenance, increase development effort, harder to reuse and test particular module,
assembling of module may required more effort, change in one module usually leads a
ripple effect and difficult to develop modules in independent way, these are the
disadvantages. High cohesion is contrasted with high coupling and somehow it
correlates with loose coupling and vice versa.

41 *Under revision
 Lecture Note : 9

Data flow oriented design:

Data flow-oriented design technique identifies:-
• Different processing stations (functions) in a system
• The data items that flows between processing stations

In the late 1970s Data flow oriented design was developed. Experienced programmers
stated that to have a good program structure, one has to study how the data flows from
input to the output of the program. Every program reads data and then processes that
data to produce some output. Once the data flow structure is identified, then from there
one can derive the program structure.

Object-oriented design (1980s) is the latest and very widely used technique. Design
approach in which natural objects (such as employees, pay-roll register, etc.) occurring
in a problem are first identified. Relationships among objects (such as composition,
reference and inheritance) are determined. Each object essentially acts as a data hiding
entity.

Transform centered design:

Transform analysis consists of five broad steps:

1. To start with, a level-2 or a level-3 data flow diagram of the problem is considered so
that the processes represent elementary functions.
2. The data flow diagram is divided into three parts:
(a) The input part (the afferent branch) that includes processes that transform input
data from physical (e.g., character from terminal) to logical form (e.g., internal
table).
(b) The logical (internal) processing part (central transform) that converts input data
in the logical form to output data in the logical form.
(c) The output part (the efferent branch) that transforms output data in logical form
(e.g., internal error code) to physical form (e.g., error report)
3. A high-level structure chart is developed for the complete system with the main
module calling the inflow controller (the afferent) module, the transform flow controller
module, and the outflow controller (the efferent) module. This is called the first-level factoring.
Figure13.15 shows the high-level structure chart for this scheme.

42 *Under revision
 MAIN

A B C

(Fig. [Link]-level factoring)

Here on activated, the main module carries out the entire task of the system by calling
upon its subordinate modules. A is the input controller module when it activated, will
enable the subordinate afferent modules to send the input data streams to flow towards
the main module. C is the output controller module which, when activated, will
likewise enable its subordinate modules to receive output data streams from the main
module and output them as desired. B is the transform flow controller which, when
activated, will receive the input streams from the main module, pass them down to its
subordinate modules, receive their output data streams, and pass them up to the main
module for subsequent processing and outputting by the efferent modules.

4. The high-level structure chart is now factored again (the second level factoring) to
obtain the first-cut design. The second-level factoring is done by mapping individual
transforms (bubbles) in the data flow diagram into appropriate modules within the
program structure. A rule that is helpful during the second-level factoring process is to
ensure that, the processes appearing in the afferent flow in the data flow diagram form
themselves into modules that form the lowest-level in the structure chart and sending
data upwards to the main module. The processes appearing in the efferent flow in the
data flow diagram form themselves into modules that also appear at the lowest-level of
the structure chart and receive data from the main module downwards. Figure 13.16
shows the first-cut design.

43 *Under revision
The first-cut design is important as it helps the designer to write a brief processing
narrative that forms the first-generation design specification. The specification should
include
(a) The data in and out of every module (the interface design),
(b) The data stored in the module (the local data structure),
(c) A procedural narrative (major tasks and decisions), and
(d) Special restrictions and features.

5. The first-cut design is now refined by using design heuristics for improved software
quality. The design heuristics are the following:
(a) Apply the concepts of module independence that is, the modules should be
designed so as to be highly cohesive and loosely coupled.
(b) Minimize high fan-out, and strive for fan-in as depth increases, so that the
overall shape of the structure chart is dome-like.
(c) Avoid pathological connections by avoiding flow of control and by having
only single-entry, single-exit modules.
(d) Keep scope of effect of a module within the scope of control of that module.
We take a hypothetical data flow diagram (Figure 13.17) to illustrate the transform
analysis strategy for program design. It is a data flow diagram with elementary
functions. It contains 11 processes, two data stores, and 21 data flows. The two vertical
lines divide the data flow diagram into three parts, the afferent part, the central
transform, and the efferent part.

Figure 13.18 is the structure chart showing the first-level structuring of the data flow
diagram. Here module A represents the functions to be done by processes P1 through

44 *Under revision
P4. Module B does the functions P5 through P7, and module C does the functions P8
though P9.

We now carry out a second-order factoring and define subordinate modules for A, B,
and C. To do this, we look at the functions of various processes of the data flow
diagram which each of these modules is supposed to carry out.

Notice: in the above figure flow of data from and to the modules, the data flows are
consistent with the data flow diagrams also that we have chosen the bottom-level
modules in such a way that they have either functional or sequential or
communicational cohesion. The module P1+ P2 + P3 contains too many functional
components and perhaps can be broken down into its subordinate modules. A
modification of the first-cut design is given in Fig. 13.20 which may be accepted as the
final design of architecture of the problem depicted in the data flow diagram (Figure
13.17).

45 *Under revision
 Lecture Note : 10

Transaction Analysis:
Transform analysis is the dominant approach in structured design; often special
structures of the data flow diagram can be utilized to adopt alternative approaches.
Transaction analysis is recommended in situations where a transform splits the input
data stream into several discrete output sub streams.
For example, a transaction may be a receipt of goods from a vendor or shipment of
goods to a customer. Thus once the type of transaction is identified, the series of actions
is fixed. The process in the data flow diagram that splits the input data into different
transactions is called the transaction center. In the below figure 13.20 gives a data flow
diagram in which the process P1 splits the input data streams into three different
transactions, each following its own series of actions. P1 is the transaction center here.

46 *Under revision
And an appropriate structure chart for a situation depicted in Fig. 13.21 is the one that
first identifies the type of transaction read and then invokes the appropriate
subordinate module to process the actions required for this type of transaction. Figure
13.22 is one such high-level structure chart.

47 *Under revision
Transaction analysis consists of five steps:

1. The problem specifications are examined and transaction sources are identified.
2. The data flow diagram (level 2 or level 3) is examined to locate the transaction
center that produces different types of transactions and locate and group various
functions for each type of transaction.
3. A high-level structure chart is created, where the top level is occupied by the
transaction center module that calls various transaction modules, each module for a
specific type of transaction.
4. The transaction modules are factored to build the complete structure chart.
5. Then ‘first-cut’ program structure refined using the design heuristics for improved
software quality. In practice, often a combination strategy is used. This strategy
combines the features of transform analysis and transaction analysis. For example,
when transform analysis alone cannot identify a reasonable central transform then,
transaction analysis is used to break the system (or program) into subsystems. Similarly,
during a transaction analysis, if defining the root module as at transaction center makes
it too complex, several transaction centers can be identified.

Inventory control system:

An inventory control system is required for a major supplier of auto parts. The analyst
finds that problems with the current manual system include
(1) Inability to obtain the status of a component rapidly
(2) two- or three-day turnaround to update a card file
(3) Multiple reorders to the same vendor
Because there is no way to associate vendors with components, and so forth.
Once problems have been identified, the analyst determines what information is to be
produced by the new system and what data will be provided to the system. For
instance, the customer desires a daily report that indicates what parts have been taken
from inventory and how many similar parts remain. The customer indicates that
inventory clerks will log the identification number of each part as it leaves the inventory
area.
Upon evaluating current problems and desired information (input and output),
the analyst begins to synthesize one or more solutions. To begin, the data objects,
processing functions, and behavior of the system are defined in detail. Once this
information has been established, basic architectures for implementation are
considered. A client/server approach would seem to be appropriate, but does the
software to support this architecture fall within the scope outlined in the Software Plan?
A database management system would seem to be required, but is the user/customer's
need for associatively justified? The process of evaluation and synthesis continues until
both analyst and customer feel confident that software can be adequately specified for
subsequent development steps.

48 *Under revision
Reservation system:
Reservation system used the concept of Reuse domain, consider the airline
reservation system, the reusable objects can be seats, flights, airports, crew, meal orders,
etc. The reusable operations can be scheduling a flight, reserving a seat, assigning crew
to flights, etc. The domain analysis generalizes the application domain. A domain
model transcends specific applications. The common characteristics or the similarities
between systems are generalized.
Similarly the reservation system also used the concept of host-slave, consider the
Railway-reservation system here the master at any time directs the slaves what to do. A
slave can only make requests and master takes over and tells what to do.

49 *Under revision
 MODULE-II

Lecture Note: 11
Object Modeling using UML

Basic Ideas on UML

Model:
A model is the graphical, textual, mathematical, or program code-based
representation. A model captures important aspect for some application while omitting
(or abstracting) the rest. Models are very useful in documenting the design and analysis
results.

Need for a model

An important reason behind constructing a model is that it helps manage complexity.
Once models of a system have been constructed, these can be used for a variety of
purposes during software development, including the following:
• Analysis
• Specification
• Code generation
• Design
• Visualize and understand the problem and the working of a system
• Testing, etc

Unified Modeling Language (UML)

UML, as the name implies, is a modeling language. It may be used to visualize,
specify, construct, and document the artifacts of a software system. It provides a set of
notations (e.g. rectangles, lines, ellipses, arrow etc.) to create a visual model of the
system. UML was developed to standardize the large number of object-oriented
modeling notations that existed and were used extensively in the early 1990s. Some of
the principles that ones in use were:
• Object Management Technology [Rumbaugh 1991]
• Booch’s methodology [Booch 1991]
• Object-Oriented Software Engineering [Jacobson 1992]
• Odell’s methodology [Odell 1992]

50 *Under revision
• Shaler and Mellor methodology [Shaler 1992]
UML was adopted by Object Management Group (OMG) as a de facto standard in
1997. OMG is an association of industries which tries to facilitate early formation of
standards.

UML diagrams
UML can be used to construct several different types of diagrams to capture five
different views of a system. Just as a building can be modeled from several views (or
perspectives) such as ventilation perspective, electrical perspective, lighting
perspective, heating perspective, etc.
.
The UML diagrams can capture the following five views of a system:
• User’s view
• Structural view
• Behavioral view
• Implementation view
• Environmental view

Fig. 1: Different types of diagrams and views supported in UML

User’s view:
This view defines the functionalities (facilities) made available by the system to its
users. The users’ view captures the external users’ view of the system in terms of the
functionalities offered by the system. The users’ view is a black-box view of the system

51 *Under revision
where the internal structure, the dynamic behavior of different system components, the
implementation etc. are not visible. It is very different from all other that it is a
functional model compared to the object model of all other views. The users’ view can
be considered as the central view and all others are expected to conform to this view.

Structural view:
The structural view defines the kinds of objects (classes) important to the
understanding of the working of a system and to its implementation. It also captures
the relationships among the classes (objects). The structural model is also called the
static model, since the structure of a system does not change with time.

Behavioral view:
The behavioral view captures how objects interact with each other to realize the
system behavior. The system behavior captures the time-dependent (dynamic) behavior
of the system.

Implementation view:
This view captures the important components of the system and their
dependencies.

Environmental view:
This view models how the different components are implemented on different
pieces of hardware platform

Use Case Model

The use case model for any system consists of a set of “use cases”, users and
relationship among them within the system. Use case describes the action that user
takes on a system. Use case diagram model the process flow of a system. It is the way to
communicate with the user. Intuitively, use cases represent the different ways in which
a system can be used by the users. A simple way to find all the use cases of a system is
to ask the question: “What the users can do using the system?”. Four basic components
to construct use case diagram are:
a) System: Something that performs a function or system is a piece/multiple piece of
software that perform some function for its user.
b)actor: actor is something that uses our system. It is named based on their job title.
An actor can be a person or another external system like developer, student, clerk, teacher, officer
etc.
c)use cases: are the actions that a user takes on a system. According to above example

52 *Under revision
 developer creates s/w, teacher record grade, officer create command etc.
d)relationship: connection between the actor to the use cases. Actor can relates to
multiple use cases and a use cases relate to multiple actors.

Thus for the Library Information System (LIS), the use cases could be:
• issue-book
• query-book
• return-book
• create-member
• add-book, etc

Similarly the use case model for the Supermarket Prize Scheme is shown in fig. 2. As
discussed earlier, the use cases correspond to the high level functional requirements.
From the problem description and the context diagram. In fig.2 we can identify three
use cases: “register-customer”, “register-sales”, and “select-winners”. As a sample, the
text description for the use case “register-customer” is shown below.

Fig. 2 Use case model for Supermarket Prize Scheme

Text description

U1: register-customer: Using this use case, the customer can register
himself by providing the necessary details.

Scenario 1: Mainline sequence

53 *Under revision
1. Customer: select register customer option.
2. System: display prompt to enter name, address,
and telephone number.
3. Customer: enter the necessary values.
4. System: display the generated id and the message
that the customer has been successfully
registered.

Scenario 2: at step 4 of mainline sequence

1. System: displays the message that the customer

has already registered.

Scenario 2: at step 4 of mainline sequence

1. System: displays the message that some input information has not been entered.
The system displays a prompt to enter the missing value.

Utility of use case diagrams

Use cases are represented by ellipses. They along with the accompanying text
description serve as a type of requirements specification of the system and form the
core model to which all other models must conform. UML offers three mechanisms for
factoring of use cases as follows:

Generalization
Generalization is a technique that used to inherit an item in UML. It can be applied to
both actor and use cases to indicate that their child item inherit functionality from
parent. It can be used when one use case is similar to another. The child use case
inherits the behavior and meaning of the parent use case. But the base and the derived
use cases are separate use cases and should have separate text descriptions.

54 *Under revision
Fig. 3: Representation of use case generalization

Includes
The includes relationship in the older versions of UML (prior to UML 1.1) was known
as the use cases relationship. Include relationship indicate that use case will include
functionality from an additional use cases. The relationship involves one use case
including the behavior of another use case in its sequence of events and actions. The
includes relationship occurs when a chunk of behavior that is similar across a number
of use cases. Its advantage is to make helpful to decompose large and complex use cases
into more manageable part. It is pointed to represented as line and open arrow and
inside pre defines sterio type such as <<include> as in below.

Fig. 4: Example use case inclusion

Extends
Extended relationship indicates that use case may be extended by another use case.
The main idea behind the extends relationship among the use cases is that it allows us
to show optional system behavior. And an optional system behavior is extended only
under certain conditions. This relationship among use cases is also predefined as a
stereotype as shown below and as in the include relationship. The extend relationship is
similar to generalization. But unlike generalization, the extending use case can add
additional behavior only at an extension point only when certain conditions are
satisfied.

<<>extended>

55 *Under revision
Organization of use cases
Use cases are can be organized hierarchically. The high level use cases are refined into a
set of smaller and more refined use cases as shown below. Only the complex use cases
should be decomposed and organized in a hierarchy. It is not necessary to decompose
simple use cases. The functionality of the super-ordinate use cases is traceable to their
sub-ordinate use cases. Thus, the functionality provided by the super-ordinate use cases
is composite of the functionality of the sub-ordinate use cases.

Fig. 5: Hierarchical organization of use cases

Class and Interaction Diagrams

Class diagrams
A class diagram describes the static structure of a system. It shows how a system is
structured rather than how it behaves. The static structure of a system comprises of a
number of class diagrams and their dependencies. The main constituents of a class
diagram are classes and their relationships: generalization, aggregation, association,
and various kinds of dependencies.

56 *Under revision
Classes
The classes represent entities with common features, i.e. attributes and operations.
Classes are represented as solid outline rectangles with compartments. It has a
mandatory name compartment where the name is written centered in boldface. The
class name is usually written using mixed case convention and begins with an
uppercase. The class names are usually chosen to be singular nouns.

Attributes
An attribute is a property of a class written in left justified. It represents the kind of data
that an object might contain. Attributes are listed with their names, and may be contain
specification of their type, an initial value, and constraints. The type of the attribute is
written by appending a colon and the type name after the attribute name as

book Name : String

Operation
Operation is the implementation of a service/activity that supported by class and
invoked by other class object. It can be requested from any object of the class to affect
behavior. An object’s data or state can be changed by invoking an operation of the
object. A class may have any number of operations or no operation at all. Generally the
first letter of an operation name is a small letter. Its return type is Boolean as E.g

issueBook(in bookName):Boolean

Association
When two classes associated with each other, their exists association relation. It is
represented by straight line between concerned classes. Associations enable objects to
communicate with each other. An association describes a connection between classes.
The association relation between two objects is called object connection or link. Links
are instances of associations. Mathematically, a link can be considered to be a tuple, i.e.
an ordered list of object instances. An association describes a group of links with a
common structure and common semantics. Each side of association relation multiplicity
is noted as an individual number or value range. Multiplicity (*) indicate how many
instance of one class are associated with the other. Range of multiplicity are noted by
specifying range of minimum to maximum by giving two dots i.e 1..5. An asterisk is
used as a wild card (last entry), zero or more.

Let us consider the statement that below illustrates the graphical representation of
the association relation. The name of the association is written alongside the association
line. An arrowhead is placed on the association line to indicate the reading direction of
the association. The arrowhead should not be misunderstood to be indicating the

57 *Under revision
direction of a pointer implementing an association. The multiplicity indicates how
many instances of one class are associated with each other.

Fig. 6: Association between two classes

Aggregation
Aggregation is a special type of association relation, where classes are not only
associated but also whole part relation exist between them. Here involved classes that
takes the responsibility of forwarding messages to the appropriate parts. Thus, it takes
the responsibility of delegation and leadership. When an instance of one object contains
instances of some other objects, then aggregation relationship exists between the
composite object and the component object. Aggregation is represented by the diamond
symbol at the composite end of a relationship. For example boo register is an
aggregation of book objects similarly document can be consider as an aggregation of
paragraph and aggregation of line. Here 1 and * means one document can have many
paragraph and many lines constitute a paragraph. This relation cannot be reflexive
means an object cannot have the object of same class as itself nor symmetric (i.e two
classes cannot contain instance of each other). However aggregation relationship is
transitive and it can consist of arbitrary number of levels.

Composition
Composition is a stricter form of aggregation, in which the parts are existence-
dependent on the whole. Means that the life of the parts closely ties to the life of the
whole. The composition relationship is represented as a filled diamond drawn at the
composite-end. An example of the composition relationship is

58 *Under revision
 Polygon

Aggregation Composition

Vertices Properties
Color Area

Fig. 7: Diagram representing aggregation and composition.

Dependency
It represented by dotted arrow from dependent class to independent class. It provides
pre and post condition for operation to define ordering of an item.

Association vs. Aggregation vs. Composition

• Association is the most general (m:n) relationship. Aggregation is a stronger
relationship where one is a part of the other. Composition is even stronger than
aggregation.

• Association relationship can be reflexive (objects can have relation toitself), but
aggregation cannot be reflexive. Aggregation is anti-symmetric (If B is a part of A, A
cannot be a part of B).

• Composition has the property of exclusive aggregation i.e. an object can be a part of
only one composite at a time. For example, a Frame belongs to exactly one Window
whereas in simple aggregation, a part may be shared by several objects. For example, a
Wall may be a part of one or more Room objects.

• In composition, the whole has the responsibility for the decomposition of all its parts,
i.e. for their creation and destruction. For example, when a Frame is created, it has to be
attached to an enclosing Window. Similarly, when the Window is destroyed, it must in
turn destroy its Frame parts.

59 *Under revision
Inheritance vs. Aggregation/Composition
• Inheritance describes ‘is a’ / ‘is a kind of’ relationship between classes (base class -
derived class) whereas aggregation describes ‘has a’ relationship between classes.
Inheritance means that the object of the derived class inherits the properties of the base
class; aggregation means that the object of the whole has objects of the part.

• Inheritance means the objects of the subclass can be used anywhere the super class
may appear, but not the reverse; i.e. wherever we could use instances of ‘payment’ in
the system, we could substitute it with instances of ‘cash payment’, but the reverse
cannot be done.

• Inheritance is defined statically. It cannot be changed at run-time. Aggregation is

defined dynamically and can be changed at run-time. Aggregation is used when the
type of the object can change over time.

For example, consider this situation in a business system. A Business Partner might be
a Customer or a Supplier or both. During its lifetime, a business partner might become
a customer as well as a supplier, or it might change from one to the other. In such cases,
we prefer aggregation instead. Here, a business partner is a Customer if it has an
aggregated Customer object, a Supplier if it has an aggregated Supplier object and a
"Customer Supplier" if it has both. Here, we can have only two types. Hence, we are
able to model it as inheritance.

60 *Under revision
• The advantage of aggregation is the integrity of encapsulation. The operations of an
object are the interfaces of other objects which imply low implementation dependencies.
The disadvantage of aggregation is the increase in the number of objects and their
relationships. On the other hand, inheritance allows for an easy way to modify
implementation for reusability.
.
Interaction Diagrams
Interaction diagram describe the interaction among group of objects through message
passing. Interaction diagrams are models that describe how group of objects
collaborate to realize some behavior. Each interaction diagram realizes the behavior of a
single use case. An interaction diagram shows a number of example objects and the
messages that are passed between the objects. There are two kinds of interaction
diagrams: sequence diagrams and collaboration diagrams.

Sequence Diagram:
A sequence diagram shows interaction among objects as a two dimensional chart. The
chart is read from top to bottom. The objects participating in the interaction are shown
at the top of the chart as boxes attached to a vertical dashed line. Vertical dashed line is
called object life line. Any point on life line implies that object exist at that point. If
object is destroyed, lifeline of object is crossed at that point and lifeline of that object is
not drowned at that point. Control rectangle is used as activation symbol drown from
lifeline of an object that the point at which object is active. Object is active as long as
control rectangle is exist in lifeline of object. Each message is labeled with message
name. Inside the box the name of the object is written with a colon separating it from
the name of the class and both the name of the object and the class is underlined. The
objects appearing at the top signify that the object already existed when the use case
execution was initiated. Note: single use case represent single sequence diagram.

61 *Under revision
Object1 Object2c Object3

message
[invalid]

• A condition (e.g. [invalid]) indicates that a message is sent, only if the

condition is true.
• An iteration marker shows the message is sent many times to multiple
receiver objects. As it happened elements of an array are being iterated.
The basis of the iteration can also be indicated e.g. [for every book object].

62 *Under revision
 Fig. 8: Sequence diagram for the renew book use case

Collaboration Diagram

Collaboration diagram is a cross between the class diagram and sequence

iagram. It model the objects and sequenced communication between each other.
Collaboration diagram shows both structural and behavioral aspects explicitly.
Structural aspect consists of objects and links among the objects which indicate the
association. Object in collaboration diagram is called collaborator. But in sequence
diagram it shows only the behavioral aspects. The link between objects is shown as a
solid line and can be used to send messages between two objects. The message is shown
as a labeled arrow placed near the link. The use of the collaboration diagrams in our
development process is to help us to determine which classes are associated with which
other classes. This model used to represent interaction between objects and role. Link
between object is shown in solid line and can be used to send messages between two
objects. Collaboration diagram derived from sequence diagram which realize for single
use case. It helps us to, which class associated with the other class. For example
collaboration diagram for renew book use case

63 *Under revision
 Fig. 9: Collaboration diagram for the renew book use case

Activity diagrams
Activity diagram represent the various activity or chunk of process and their sequence
of activation. It shows the system execution and changes of direction based on different
condition. It model workflow for use case. It is possibly based on the event diagram of
Odell [1992] through the notation is very different from that used by Odell. An
interesting feature of the activity diagrams is the swim lanes. Swim lanes enable us to
group activities based on who is performing them, e.g. academic department vs. hostel
office. This is carried out during the initial stages of requirements analysis and
specification. Activity diagram gives start and end state and can show the path within
the use case as well as between the use cases. It explains what condition needs to meet
for use cases for use case to be valid condition state etc.
Components of activity diagram are:
a)Activities or action state: notation used for activity/action is rectangle with
rounded corner and it indicate action.
b)State: activity diagram can have only one start state but can have several
end/stop state. UML may describe two special state called start state and
stop state represented as: black dot and black dot with round circle.

64 *Under revision
 c)Transition: used to show control flow from one state to another state. It shows
flow from state to an activity, between activity or between states.

Guard is noted on transition between two activity or states. And diamond is used as
decision point for condition. An activity is a state with an internal action and one or
more outgoing transition which automatically follow the internal activity termination.

Activity diagram is similar to procedural flow chart, difference is that activity diagram
support description of parallel activity and synchronization exist between activity and
parallel activities are represented by swim lane.

Fig. 9: Activity diagram for student admission procedure at IIT

65 *Under revision
Unified Development Process

Qualified process for every project is most important which is to be follow thoroughly.
Many parts of the process are iterative, especially during the design and planning
phases. This flexibility in procedure allows for constant review and improvement, even
during the course of rapid development. Some of the approaches are

• A Modular Process
• A Strategic Focus
• A User Centered Approach

A Modular Process

Key competitive advantages of any project is the modularity of overall procedure. All
of products and services can be delivered as part of a full development schedule, or
individually when needed. In some cases, it leads the strategic planning section of a
project where others complete the graphic design or programming tasks.
In some cases, it is provided usability and information architecture services upon
which others build functional systems.
In some cases, it is designed the presentation for a campaign that others execute,
or we create a graphical interface for software that others programmed.

A Strategic Focus
Every aspect of a project must be driven be a clearly defined, relevant digital strategy.
We strongly focuses in the strategy in setting clear, measurable goals, and actively
analyzing the achievement of those goals to identify a project's rate of success.

A User Centered Approach

This approach focus on the product's users and potential users and uses from the very
beginning. The design process developer generally follow is based on the principles
of User Centered Design (UCD). UCD has a broader scope than purely "usability"; and
continually throughout the planning, conceptualization, design and development
process.

Programming Languages
A programming language is a formal constructed language designed to
communicate instructions to a machine, particularly a computer. Programming

66 *Under revision
languages can be used to create programs to control the behaviour of a machine or to
express algorithms.

Three levels of computer programming languages may be distinguished:

– machine languages;

– assembly languages;

– high-level languages.

A program written in a high-level language is called a source program or source text.

Rules that prescribe the structure and “grammar” of the source text are called syntactic
rules. Rules of content, interpretation and meaning are called semantic rules.

A high-level programming language is determined by its syntactic and semantic rules,

i.e. its syntax and semantics.

Every processor has its own language and can execute only those programs that are
written in that language. For the processor to understand the program written in the
high-level language (i.e. the source text), some method of translation must be in place.
There are two techniques to achieve this aim:

(1) the compiler, and

(2) the interpreter.

The compiler is a special program which creates an object program in machine code
from the source program written in high-level language. The compiler treats the source
program as a single unit, and executes the following steps:

– Lexical analysis;

– Syntactic analysis;

– Semantic analysis;

– Code generation.

Classification
I. Imperative (algorithmic) languages

When the programmer writes a program text in these languages, he or she codes an
algorithm, and this algorithm makes the processor work. The program is a sequence of
statements and instruction. The most important programming feature is the variable,
which provides direct access to the memory, and makes it possible to directly
manipulate the values stored within. The algorithm changes the values of variables, so

67 *Under revision
the program takes effect on the memory. Imperative languages are closely connected to
the von Neumann architecture.

Imperative languages fall into one of the following sub-groups:

- Procedural languages

- Object-oriented languages

II. Declarative (non-algorithmic) languages

These languages are not connected as closely to the von Neumann architecture as
imperative languages. The programmer has to present only the problem, as the mode of
the solution is included in language implementations. The programmer cannot perform
memory operations, or just in a limited way.

Declarative languages fall into one of the following sub-groups:

- Functional (applicative) languages

- Logic languages

- Other languages

Characteristics
The following are the characteristics of a programming language

1. Readability: A good high-level language will allow programs to be written in some

ways that like quite-English description of the algorithms. The coding may be done in a
way that is essentially self-documenting.

2. Portability: High-level languages, being essentially machine independent, should be

able to develop portable software.

3. Generality: Most high-level languages allow the writing of a wide variety of

programs, language should have the ability to implement the algorithm with less
amount of code. Programs expressed in high-level languages are often considerably
shorter than their low-level equivalents.

4. Error checking: Being human, a programmer is likely to make many mistakes in the
development of a computer program. Many high-level languages enforce a great deal of
error checking both at compile-time and at run-time.

68 *Under revision
5. Efficiency: It should permit the generation of efficient object code.

Classes
The classes represent entities with common features, i.e. attributes and operations.
Classes have optional attributes and operations compartments.

Attributes
An attribute is a named property of a class. It represents the kind of data that an object
might contain. An example for an attribute is given.
Book-Name : String

Operation
Operation is the implementation of a service that can be requested from any object of
the class to affect behaviour. An example for an operation is given.
Issue-Book (in book-Name): Boolean

Association
Associations are needed to enable objects to communicate with each other. An
association describes a connection between classes.

Coding
Any organizations normally require their programmers to adhere to some well-defined
and standard style of coding called coding standards. Most software development
organizations formulate their own coding standards that suit them most, and require
their engineers to follow these standards rigorously. The purpose of requiring all
engineers of an organization to adhere to a standard style of coding is the following:
• A coding standard gives a uniform appearance to the codes written by different
engineers.
• It enhances code understanding.
• It encourages good programming practices.
A coding standard lists several rules to be followed during coding, such as the way
variables are to be named, the way the code is to be laid out, error return conventions,
etc.

Coding standards and guidelines

Good software development organizations usually develop their own coding standards
and guidelines depending on what best suits their organization and the type of
products they are going to develop. The following are some representative coding
standards.

Rules for limiting the use of global:

These rules list what types of data can be declared global and what local and what
not.

69 *Under revision
Contents of the headers preceding codes for different modules:
The information contained in the headers of different modules should be standard for
an organization. The exact format in which the header information is organized in the
header can also be specified. The following are some standard header data:
• Name of the module.
• Date on which the module was created.
• Author’s name.
• Modification history.
• Synopsis of the module.
• Different functions supported, along with their input/output parameters.
• Global variables accessed/modified by the module.

Naming conventions for global variables, local variables, and constant identifiers: A
possible naming convention can be that global variable names always start with a
capital letter, local variable names are made of small letters, and constant names are
always capital letters.

Error return conventions and exception handling mechanisms:

The way error conditions are reported by different functions in a program are
handled should be standard within an organization. For example, different functions
while encountering an error condition should either return a 0 or 1 consistently. The
following are some representative coding guidelines recommended by many software
development organizations.

Do not use a coding style that is too clever or too difficult to understand:
Code should be easy to understand. Clever coding can obscure meaning of the
code and hamper understanding. It also makes maintenance difficult.

Avoid obscure side effects:

The side effects of a function call include modification of parameters passed by
reference, modification of global variables, and I/O operations. Obscure side effects
make it difficult to understand a piece of code. For example, if a global variable is
changed obscurely in a called module or some file I/O is performed which is difficult to
infer from the function’s name and header information, it becomes difficult for anybody
trying to understand the code.

Do not use an identifier for multiple purposes:

Programmers often use the same identifier to denote several temporary entities. For
example, some programmers use a temporary loop variable for computing and a
storing the final result. For such multiple uses of variables is memory efficiency, e.g.
three variables use up three memory locations, whereas the same variable used in three
different ways uses just one memory location. However, there are several things wrong

70 *Under revision
with this approach and hence should be avoided. Some of the problems caused by use
of variables for multiple purposes as follows:

• Each variable should be given a descriptive name indicating its purpose. This is not
possible if an identifier is used for multiple purposes. Use of a variable for multiple
purposes can lead to confusion and make it difficult for somebody trying to read and
understand the code.

• Use of variables for multiple purposes usually makes future enhancements more
difficult.

The code should be well-documented:

As a rule of thumb, there must be at least one comment line on the average for every
three-source line.

The length of any function should not exceed 10 source lines:

A function that is very lengthy is usually very difficult to understand as it
probably carries out many different functions. For the same reason, lengthy functions
are likely to have disproportionately larger number of bugs.

Do not use goto statements:

Use of goto statements makes a program unstructured and makes it very difficult to
understand.

Code review
Code review for a model is carried out after the module is successfully compiled and
the all the syntax errors have been eliminated. Code reviews are extremely cost-effective
strategies for reduction in coding errors and to produce high quality code. Normally,
two types of reviews are carried out on the code of a module. These two types code
review techniques are code inspection and code walk through.

Code Walk Throughs

1. Code walk through is an informal code analysis technique.

2. In this technique, after a module has been coded, successfully compiled and all
syntax errors eliminated. A few members of the development team are given the
code few days before the walk through meeting to read and understand code.
3. Each member selects some test cases and simulates execution of the code by hand
(i.e. trace execution through each statement and function execution).
4. The main objectives of the walk through are to discover the algorithmic and
logical errors in the code.
5. The members note down their findings to discuss these in a walk through
meeting where the coder of the module is present. Even though a code walks

71 *Under revision
 through is an informal analysis technique, several guidelines have evolved over
the years for making this naïve but useful analysis technique more effective.
6. Therefore, these guidelines should be considered as examples rather than
accepted as rules to be applied dogmatically. Some of these guidelines are the
following.
• The team performing code walk through should not be either too big or too small.
Ideally, it should consist of between three to seven members.
• Discussion should focus on discovery of errors and not on how to fix the
discovered errors.
• In order to foster cooperation and to avoid the feeling among engineers that they
are being evaluated in the code walk through meeting. Managers should not
attend the walk through meetings.

Code Inspection
1. In contrast to code walk through, the aim of code inspection is to discover some
common types of errors caused due to oversight and improper programming.
2. During code inspection the code is examined for the presence of certain kinds of
errors, in contrast to the hand simulation of code execution done in code walk
through.
3. In addition to the commonly made errors, adherence to coding standards is also
checked during code inspection. Good software development companies collect
statistics regarding different types of errors commonly committed by their
engineers and identify the type of errors most frequently committed. Such a list
of commonly committed errors can be used during code inspection to look out
for possible errors.
Following is a list of some classical programming errors which can be checked during
code inspection:

• Use of uninitialized variables.

• Jumps into loops.
• Non-terminating loops.
• Incompatible assignments.
• Array indices out of bounds.
• Improper storage allocation and de allocation.
• Mismatches between actual and formal parameter in procedure calls.
• Use of incorrect logical operators or incorrect precedence among operators.
• Improper modification of loop variables.
• Comparison of equally of floating point variables, etc.

Software documentation

When various kinds of software products are developed then not only the executable
files and the source code are developed but also various kinds of documents such as

72 *Under revision
users’ manual, software requirements specification (SRS) documents, design
documents, test documents, installation manual, etc are also developed as part of any
software engineering process. All these documents are a vital part of good software
development practice. Good documents are very useful and server the following
purposes:
• Good documents enhance understand ability and maintainability of a software
product. They reduce the effort and time required for maintenance.

• Use documents help the users in effectively using the system.

• Good documents help in effectively handling the manpower turnover problem. Even
when an engineer leaves the organization, and a new engineer comes in, he can build
up the required knowledge easily.

• Production of good documents helps the manager in effectively tracking the progress
of the project. The project manager knows that measurable progress is achieved if a
piece of work is done and the required documents have been produced and reviewed.
Different types of software documents can broadly be classified into the following:
• Internal documentation
• External documentation

Internal documentation:
It is the code comprehension features provided as part of the source code
itself. Internal documentation is provided through appropriate module headers and
comments embedded in the source code. Internal documentation is also provided
through the useful variable names, module and function headers, code indentation,
code structuring, use of enumerated types and constant identifiers, use of user-defined
data types, etc. Careful experiments suggest that out of all types of internal
documentation meaningful variable names is most useful in understanding the code.

External documentation:
It is provided through various types of supporting documents such as users’
manual, software requirements specification document, design document, test
documents etc. A systematic software development style ensures that all these
documents are produced in an orderly fashion.

Program Testing
Testing a program consists of providing the program with a set of test inputs (or test
cases) and observing if the program behaves as expected. If the program fails to behave
as expected, then the conditions under which failure occurs are noted for later
debugging and correction. Some commonly used terms associated with testing are:
• Failure: This is a manifestation of an error (or defect or bug). But, the mere
presence of an error may not necessarily lead to a failure.

73 *Under revision
• Test case: This is the triplet [I,S,O], where I is the data input to the system, S is the
state of the system at which the data is input, and O is the expected output of the
system.

• Test suite: This is the set of all test cases with which a given software product is to be
tested.

Aim of testing
The aim of the testing process is to identify all defects existing in a software product.
However for most practical systems, even after thoroughly carrying out the testing
phase, it is not possible to guarantee that the software is error free. Because of the fact
that the input data domain of most software products is very large. It is not practical to
test the software exhaustively with respect to each value that the input data may
assume. Testing provides a practical way of reducing defects in a system and increasing
the users’ confidence in a developed system.

Testing
After design phase is over software products are normally tested first at the individual
component (or unit) level. This is referred to as testing in the small. After testing all the
components individually, the components are slowly integrated and tested at each level
of integration (integration testing). Finally, the fully integrated system is tested (called
system testing). Integration and system testing are known as testing in the large.

Unit testing
Unit testing is undertaken after a module has been coded and successfully reviewed.
Unit testing (or module testing) is the testing of different units (or modules) of a system
in isolation. In order to test a single module, a complete environment is needed to
provide all that is necessary for execution of the module. That is, besides the module
under test itself, the following steps are needed in order to be able to test the module:
• The procedures belonging to other modules that the module under test calls.
• Non-local data structures that the module accesses.
• A procedure to call the functions of the module under test with appropriate
parameters.

Modules required to provide the necessary environment (which either call or are called
by the module under test) is usually not available until they too have been unit tested,
stubs and drivers are designed to provide the complete environment for a module. The
role of stub and driver modules is pictorially shown below. A stub procedure is a
dummy procedure that has the same I/O parameters as the given procedure but has a
highly simplified behaviour. For example, a stub procedure may produce the expected
behaviour using a simple table lookup mechanism and it may use global data. A driver

74 *Under revision
module contains the nonlocal data structures accessed by the module under test, and
would also have the code to call the different functions of the module with appropriate
parameter values.

Black box testing

In black box testing test cases are designed using only functional specification of s/w.
Test cases designed are based on the input/output behaviour(i.e functional behaviour)
and does not required any knowledge of internal structure. For this reason black box
testing is also known as functional testing.
The following are the two main approaches to designing black box test cases.

• Equivalence class portioning

• Boundary value analysis

Equivalence Class Partitioning

In this approach, the domain of input values to a program is partitioned into a set of
equivalence classes. This partitioning is done such that the behaviour of the program is
similar for every input data belonging to the same equivalence class. The main idea
behind defining the equivalence classes is that testing the code with any one value
belonging to an equivalence class is as good as testing the software with any other value
belonging to that equivalence class. Equivalence classes for a software can be designed
by examining the input data and output data. The following are some general
guidelines for designing the equivalence classes:

1. If the input data values to a system can be specified by a range of values, then one
valid and two invalid equivalence classes should be defined.
2. If the input data assumes values from a set of discrete members of some domain, then
one equivalence class for valid input values and another equivalence class for invalid
input values should be defined.

75 *Under revision
Example#1: For a software that computes the square root of an input integer which can
assume values in the range of 0 to 5000, there are three equivalence classes: The set of
negative integers, the set of integers in the range of 0 and 5000, and the integers larger
than 5000. Therefore, the test cases must include representatives for each of the three
equivalence classes and a possible test set can be: {-5,500,6000}.
Example#2: Design the black-box test suite for the following program. The program
computes the intersection point of two straight lines and displays the result. It reads
two integer pairs (m1, c1) and (m2, c2) defining the two straight lines of the form y=mx
+ c.
The equivalence classes are the following:
• Parallel lines (m1=m2, c1≠c2)
• Intersecting lines (m1≠m2)
• Coincident lines (m1=m2, c1=c2)
Now, selecting one representative value from each equivalence class, the test suit (2, 2)
(2, 5), (5, 5) (7, 7), (10, 10) (10, 10) are obtained.

Boundary Value Analysis

Boundary value analysis based test suit design involves designing test cases using the
values at the boundaries of the different equivalent classes. A type of programming
error frequently occurs at the boundaries of different equivalence classes of inputs. The
reason behind such errors might purely be due to psychological factors. So in order to
design boundary value test cases, it is required to examine the equivalent class to check
, if any of equivalence class contain a range of values. Programmers often fail to see the
special processing required by the input values that lie at the boundary of the different
equivalence classes.
For example, programmers may improperly use < instead of <=, or conversely <=
for <. Boundary value analysis leads to selection of test cases at the boundaries of the
different equivalence classes.

Example: For a function that computes the square root of integer values in the range of
0 and 5000, the test cases must include the following values: {0, - 1, 5000, 5001}

White box testing

White box testing is also known as structure testing or glass testing. One white-box
testing strategy is said to be stronger than another strategy, if all types of errors detected
by the first testing strategy is also detected by the second testing strategy, and the
second testing strategy additionally detects some more types of errors. When two
testing strategies detect errors that are different at least with respect to some types of
errors, then they are called complementary. The concepts of stronger and complementary
testing are schematically illustrated .

76 *Under revision
Basic concepts associated with the white box testing are testing strategy that can be
either:
-coverage based testing
-statement coverage
-branch coverage
-condition coverage
-path coverage

-fault based testing

Coverage based testing:

In this strategy certain program are executed to discover the error. And the specific
elements required by the strategy are called testing criteria of the strategy.

Statement coverage

The statement coverage strategy aims to design test cases so that every statement in a
program is executed at least once. The principal idea governing the statement coverage
strategy is that unless a statement is executed, it is very hard to determine if an error
exists in that statement. Unless a statement is executed, it is very difficult to observe
whether it causes failure due to some illegal memory access, wrong result computation,
etc. However, executing some statement once and observing that it behaves properly
for that, input value is no guarantee that it will behave correctly for all input values. In
the following, designing of test cases using the statement coverage strategy have been
shown.
Example: Consider the Euclid’s GCD computation algorithm:
int compute_gcd(x, y)
int x, y;
{
1 while (x! = y){
2 if (x>y) then

77 *Under revision
3 x= x – y;
4 else y= y – x;
5}
6 return x;
}
By choosing the test set {(x=3, y=3), (x=4, y=3), (x=3, y=4)}, we can exercise the program
such that all statements are executed at least once.

Branch coverage
In the branch coverage-based testing strategy, test cases are designed to make each
branch condition to assume true and false values in turn. Branch testing is also known
as edge testing as in this testing scheme, each edge of a program’s control flow graph is
traversed at least once.
Branch testing guarantees statement coverage and thus is a stronger testing strategy
compared to the statement coverage-based testing. For Euclid’s GCD computation
algorithm , the test cases for branch coverage can be {(x=3, y=3), (x=3, y=2), (x=4, y=3),
(x=3, y=4)}.

Condition coverage
In this structural testing, test cases are designed to make each component of a
composite conditional expression to assume both true and false values. For example, in
the conditional expression (([Link].c2).or.c3), the components c1, c2 and c3 are each
made to assume both true and false values. Branch testing is probably the simplest
condition testing strategy where only the compound conditions appearing in the
different branch statements are made to assume the true and false values. Thus,
condition testing is a stronger testing strategy than branch testing and branch testing is
stronger testing strategy than the statement coverage-based testing. For a composite
conditional expression of n components, for condition coverage, 2ⁿ test cases are
required. Thus, for condition coverage, the number of test cases increases exponentially
with the number of component conditions. Therefore, a condition coverage-based
testing technique is practical only if n (the number of conditions) is small.

Path coverage
The path coverage-based testing strategy requires to design test cases such that all
linearly independent paths in the program are executed at least once. A linearly
independent path can be defined in terms of the control flow graph (CFG) of a program.

Control Flow Graph (CFG)

A control flow graph describes the sequence in which the different instructions of a
program get executed. In other words, a control flow graph describes how the control
flows through the program. In order to draw the control flow graph of a program, all
the statements of a program must be numbered first. The different

78 *Under revision
numbered statements serve as nodes of the control flow graph as shown below. An
edge from one node to another node exists if the execution of the statement
representing the first node can result in the transfer of control to the other node.

The CFG for any program can be easily drawn by knowing how to represent the
sequence, selection, and iteration type of statements in the CFG. After all, a program is
made up from these types of statements, how the CFG for these three types of
statements can be drawn. We have to note that for the iteration type of constructs such
as the while construct, the loop condition is tested only at the beginning of the loop and
therefore the control flow from the last statement of the loop is always to the top of the
loop. Using these basic ideas, the CFG of Euclid’s GCD computation algorithm can be
drawn as shown below.

79 *Under revision
Path
A path through a program is a node and edge sequence from the starting node to a
terminal node of the control flow graph of a program. There can be more than one
terminal node in a program. Writing test cases to cover all the paths of a typical
program is impractical. For this reason, the path-coverage testing does not require
coverage of all paths but only coverage of linearly independent paths.
Linearly independent path
A linearly independent path is any path through the program that introduces at least
one new edge that is not included in any other linearly independent paths. If a path has
one new node compared to all other linearly independent paths, then the path is also
linearly independent. This is because; any path having a new node automatically
implies that it has a new edge. But, a path that is sub path of another path is not
considered to be a linearly independent path.

Control flow graph

In order to understand the path coverage-based testing strategy, it is very necessary to
understand the control flow graph (CFG) of a program. Control flow graph (CFG) of a
program has been discussed earlier.

Linearly independent path

80 *Under revision
The path-coverage testing does not require coverage of all paths but only coverage of
linearly independent paths. Linearly independent paths have been discussed earlier.

Cyclomatic complexity
For more complicated programs it is not easy to determine the number of independent
paths of the program. McCabe’s cyclomatic complexity defines an upper bound for the
number of linearly independent paths through a program. Also, it is very simple to
compute. Thus, the McCabe’s cyclomatic complexity metric provides a practical way of
determining the maximum number of linearly independent paths in a program. Though
the McCabe’s metric does not directly identify the linearly independent paths, but it
informs approximately how many paths to look for. There are three different ways to
compute the cyclomatic complexity.

Method 1:
Given a control flow graph G of a program, the cyclomatic complexity V(G) can be
computed as:
V(G) = E – N + 2
where N is the number of nodes of the control flow graph and E is the number of edges
in the control flow graph.
For the CFG of example shown in fig. 10.4, E=7 and N=6. Therefore, the cyclomatic
complexity = 7-6+2 = 3.

Method 2:
An alternative way of computing the cyclomatic complexity of a program from an
inspection of its control flow graph is as follows: V(G) = Total number of bounded
areas + 1
In the program’s control flow graph G, any region enclosed by nodes and edges can be
called as a bounded area. It is an easy way to determine the McCabe’s cyclomatic
complexity, But, what if the graph G is not planar, i.e. however you draw the graph,
two or more edges intersect? Actually, it can be shown that structured programs always
yield planar graphs. But, presence of GOTO’s statement can easily add intersecting
edges.
Therefore, for non-structured programs, this way of computing the McCabe’s
cyclomatic complexity cannot be used. The number of bounded areas increases with the
number of decision paths and loops. Therefore, the McCabe’s metric provides a
quantitative measure of testing difficulty and the ultimate reliability. For the CFG
example shown above, from a visual examination of the CFG the number of bounded
areas is 2. Therefore the cyclomatic complexity, computing with this method is also 2+1
= 3. This method provides a very easy way of computing the cyclomatic complexity of
CFGs, just from a visual examination of the CFG.

81 *Under revision
On the other hand, the other method of computing CFGs is more amenable to
automation, i.e. it can be easily coded into a program which can be used to determine
the cyclomatic complexities of arbitrary CFGs.

Method 3:
The cyclomatic complexity of a program can also be easily computed by computing the
number of decision statements of the program. If N is the number of decision statement
of a program, then the McCabe’s metric is
equal to N+1. From above example 2 decision statements ie if a and while so 2+1=3

Data flow-based testing

Data flow-based testing method selects test paths of a program according to the
locations of the definitions and uses of different variables in a program. For a statement
numbered S, let

DEF(S) = {X/statement S contains a definition of X}, and

USES(S) = {X/statement S contains a use of X}
For the statement S: a=b+c; DEF(S) = {a}. USES(S) = {b,c}. The definition of variable X at
statement S is said to be live at statement S1, if there exists a path from statement S to
statement S1 which does not contain any definition of X. The definition-use chain (or
DU chain) of a variable X is of form [X, S, S1], where S and S1 are statement numbers,
such that X Є DEF(S) and X Є USES(S1), and the definition of X in the statement S is live
at statement S1. One simple data flow testing strategy is to require that every DU chain
be covered at least once. Data flow testing strategies are useful for selecting test paths of
a program containing nested if and loop statements.

Fault based testing

Example of fault base testing the mutaion testing.
Mutation testing
In mutation testing, test cases are designed to detect specific type of fault in a program.
In mutation testing s/w first tested by initial test suit that is designed by other white
box testing strategies. After the initial testing is complete, mutation testing is taken up.
The main idea behind mutation testing is to make few arbitrary changes to a program at
a time. Each time the program is changed, it is called as a mutated program and the
change effected is called as a mutant. A mutated program is tested against the full test
suite of the program. If there exists at least one test case in the test suite for which a
mutant gives an incorrect result, then the mutant is said to be dead. If a mutant remains
alive even after all the test cases have been exhausted, the test data is enhanced to kill
the mutant.

The process of generation and killing of mutants can be automated by predefining a set
of primitive changes that can be applied to the program. These primitive changes can be

82 *Under revision
alterations such as changing an arithmetic operator, changing the value of a constant,
changing a data type, etc. A major disadvantage of the mutation-based testing approach
is that:
-it is computationally very expensive, since a large number of possible mutants
can be generated.
-Since mutation testing generates a large number of mutants and requires us to
check each mutant with the full test suite, it is not suitable for manual testing.
Mutation testing should be used in conjunction of some testing tool
which would run all the test cases automatically.

Strategic Issues in Testing

Testing is a very important phase in software development life cycle. But the testing
may not be very effective if proper strategy is not used. For the implementation of
successful software testing strategy, the following issues must be taken care of: -

Before the start of the testing process, all the requirements must be
specified in a quantifiable manner.

Testing objectives must be clarified and stated explicitly.

A proper testing plan must be developed.

Build "robust" software that is designed to test itself.

Use effective formal technical reviews as a filter prior to testing. Formal
technical reviews can be as effective as testing in uncovering errors. For
this reason, reviews can reduce the amount of testing effort that is
required to produce high-quality software.

—Conduct formal technical reviews to assess the test strategy and the cases
themselves. Formal technical reviews can uncover inconsistencies,
omissions, and outright errors in the testing approach. This saves time and
also improves product quality.

—Develop a continuous improvement approach for the testing process. The test
strategy should be measured. The metrics collected during testing should be
used as part of a statistical process control approach for software testing.

Unit Testing

Unit testing compromises the set of tests performed by an individual programmer prior
to integration of the unit into a larger system. The situation is illustrated as follows:

Coding and debugging ------>Unit Testing ------>Integration Testing

83 *Under revision
A program unit is usually small part that can test it in great detail, and certainly in
greater detail there will be possible when the unit is integrated into an evolving
software product. There are four categories of tests that a programmer will typically
perform on a program unit:

• Function Tests
• Performance Test
• Stress Tests
• Structure Tests

Function test:
Functional test cases involve exercising the code with nominal input values for which
the expected results are known, as well as boundary values (minimum values,
maximum values, and values on and just outside the functional boundaries) and special
values such as logically related inputs, 1x1 matrices, the identity matrix, files of
identical elements, and empty files.

Performance testing:

Performances testing determines the amount of execution time spend in various parts
of the unit, program throughout, response time, and device utilization by the program
unit. A certain amount of performance tuning may be done during unit testing.
However, caution must be exercised to avoid expending too much effort on fine-tuning
of a program unit that contributes little to the overall performance of the entire system.
Performance testing is most productive at the subsystem and system levels.

Stress Tests:

Stress tests are those tests designed to intentionally break the unit. Through
this testing we can learn about the strengths and limitations of a program by
examining the manner in which a program unit breaks.

Structure Tests:

Structure tests are concerned with exercising the internal logic part of a program and
traversing particular execution paths. Some authors refer collectively to functional,
performance, and stress testing as "black box" testing, while structure testing is referred
to as "white box" or "glass box". The major activities in structural attesting are deciding
which path to exercise, deriving test data to exercise those and measuring the test
coverage achieved when the test case are exercised.

84 *Under revision
Figure 6.7

Even if it were possible to successfully test all paths through a program, correctness
would not be guaranteed by path testing or by this testing. Because there would be the
possible of program of missing the paths and computational errors that were not
discovered by the particular test cases chosen. A missing path error occurs when a
branching statement and the associated computations are accidentally omitted. Missing
path errors can only be detected by functional test cases derived from the requirements
specifications. Thus, tests based solely on the program structure cannot detect all the
potential errors in a source program. Coincidental correctness occurs when a test case
fails to detect a computation error. For instance, the expressions (A + A) and (A*A) have
identical values when A has the value 2.

Program errors can be again classified as

-missing path errors previously discussed,

-computational errors and

-domain errors.

Tai has observed that N + m1 linearly independent test cases are required to establish
computational correctness of a program that performs only linear calculations on N
input variables. By linear calculations, we can conclude that all computations are linear
functions of the input variables when symbolic execution techniques)

A domain error occurs when a program traverses the wrong path because of an
incorrect predicate in a branching statement. White and Cohen have shown that, for
very simple programs, domain errors can be detected by the test cases that are either on
or near the borders of the path domains.

The borders of a path domain are determined by the inequalities in the test cases.

85 *Under revision
 1. Coincidental correctness does not occur for any test case. If a test traverses an
incorrect path, the output values are different from the values that would be
computed on the correct path.

2. There are no missing paths associated with the path being tested.

3. Each border is produced by a predicate having only one relational operator.

4. Each adjacent path domain computes a function different from the function
computed by the path being tested.

5. The border being tested is a linear function of the input variables. If the border
is in correct border is linear.

6. The input space is continuous rather than discrete.

7. Each test case of the border (each off point) is a small distance, epsilon, from
the border.

Integration Testing

After tested each module individually, integrated testing phase is proceeded. Testing
approach can be either top-up or bottom-up. Bottom-up integration is the traditional
strategy to integrate the components of a software system into a functioning whole.
Bottom-up integration consists of unit testing, which is followed by subsystem testing,
followed by testing of the entire system. Unit testing has the goal of discovering errors
in the individual modules of the system. Modules are tested in isolation from one
another in an artificial environment known as a "test harness," which consists of the
driver programs and data necessary to exercise the modules. Unit testing is eased by a
system structure that is composed of small, loosely coupled modules.

A subsystem consists of several modules that communicate with each other through
interfaces. Subsystem implements a major segment operation of the interfaces between
modules in the subsystem. Both control and of subsystem testing: lower level
subsystems are successively combined to form higher-level subsystems. In most
software systems, sometimes testing subsystem is not possible due to the complexity of
module interface. Therefore test cases must be chosen carefully to exercise the manner.

System testing is concerned with subtleties in the interfaces, decision logic, control flow,
recovery procedures, throughput, capacity, and timing characteristics of the entire
system. Careful test planning is required to determine the extent and nature of system
testing to be performed and to establish criteria by which the results will be evaluated.

86 *Under revision
Disadvantages of bottom-up testing include the necessity to write and debug test
harness for the modules and subsystems, and the level of complexity that results from
combining modules and subsystems into larger and larger units.

The extreme case of complexity occurs when each module is unit tested in isolation and
"big bang" approach to integration testing. The main problem with big-bang integration
is the difficulty of isolating the sources of error.

Top-down integration starts with the main routine and one or two immediately
subordinate routines in the system structure. After this top-level, when "skeleton" has
been thoroughly tested, it becomes the test harness for its immediately subordinate
routines. Top-down integration requires the use of program stubs to simulate the effect
of lower-level routines that are called by those being tested.

Regression Testing

When some errors occur in a program then these are rectified. For rectification of these
errors, changes are made to the program. Due to these changes some other errors may
be incorporated in the program. Therefore, all the previous test cases are tested again.
This type of testing is called regression testing.

In a broader context, successful tests (of any kind) result in the discovery of errors, and
errors must be corrected. Whenever software is corrected, some aspect of the software
configuration (the program, its documentation, or the data that supports it) is changed.
Regression testing is the activity that helps to ensure that changes (due to testing or for
other reasons) do not introduce unintended behavior or additional errors.

Regression testing may be conducted manually, by re-executing a subset of all test cases
or using automated capture/playback tools. Capture/playback tools enable the
software engineer to capture test cases and results for subsequent playback and
comparison.

The regression test suite (the subset of tests to be executed) contains three different
classes of test cases:

-A representative sample of tests that will exercise all software functions.

-Additional tests that focus on software functions that are likely to be affected by
the change.

-Tests that focus on the software components that have been changed.

87 *Under revision
 -As integration testing proceeds, the number of regression tests can grow quite
large.

Therefore, the regression test suite should be designed to include only those tests that
address one or more classes of errors in each of the major program functions. It is
impractical and inefficient to re-execute every test for every program function once a
change has occurred.

Levels of Testing

When we go through the testing process faults can occur during any phase in the
software development cycle. Verification is performed on the output of each phase, but
some faults are likely to remain undetected by these methods. These faults will be
eventually reflected in the further code. Testing is usually relied on to detect these
faults, in addition to the faults introduced during the coding phase itself. Due to this,
different levels of testing are used in the testing process; each level of testing aims to
test different aspects of the system.

Figure 6.8

The basic levels are unit testing, integration testing, testing system and acceptance
testing. These different levels of testing attempt to detect different types of faults. The
relation of the faults introduced in different phases, and the different levels of testing as
shown in figure 6.8.

ART OF DEBUGGING

Debugging means fixing the error. It is carried by the development team with
intentionally removed of the error. Debugging is a necessary process in almost any
new software or hardware development process, whether a commercial product or an
enterprise or personal application program. For complex products, debugging is done

88 *Under revision
as the result of the unit test for the smallest unit of a system, again at component test
when parts are brought together, again at system test when the product is used with
other existing products, and again during customer beta test, when users try the
product out in a real world situation. Program that has lots of bugs is referred to as
"buggy."

Debugging tools (called debuggers) help identify coding errors at various development
stages. Some programming language packages include a facility for checking the code
for errors as it is being written.

Need for debugging

Once errors are identified in a program code, it is necessary to first identify the precise
program statements responsible for the errors and then to fix them. Identifying errors in
a program code and then fix those up are known as debugging.

Debugging approaches
The following are some of the approaches popularly adopted by programmers for
Debugging.

Brute Force Method:

This is the most common method of debugging but is the least efficient method. In this
approach, the program is loaded with print statements to print the intermediate values
with the hope that some of the printed values will help to identify the statement in
error. This approach becomes more systematic with the use of a symbolic debugger
(also called a source code debugger), because values of different variables can be easily
checked and break points and watch points can be easily set to test the values of
variables effortlessly.

Backtracking:
This is also a fairly common approach. In this approach, beginning from the statement
at which an error symptom has been observed, the source code is traced backwards
until the error is discovered. Unfortunately, as the number of source lines to be traced
back increases, the number of potential backward paths increases and may become
unmanageably large thus limiting the use of this
approach.

Cause Elimination Method:

In this approach, a list of causes which could possibly have contributed to the error
symptom is developed and tests are conducted to eliminate each. A related technique of
identification of the error from the error symptom is the software fault tree analysis.

89 *Under revision
Program Slicing:
This technique is similar to back tracking. Here the search space is reduced by defining
slices. A slice of a program for a particular variable at a particular statement is the set of
source lines preceding this statement that can influence the value of that variable.

Debugging guidelines
Debugging is often carried out by programmers based on their ingenuity. The following
are some general guidelines for effective debugging:

• Many times debugging requires a thorough understanding of the program design.

Trying to debug based on a partial understanding of the system design and
implementation may require an inordinate amount of effort to be put into debugging
even simple problems.
• Debugging may sometimes even require full redesign of the system. In such cases, a
common mistakes that novice programmers often make is attempting not to fix the
error but its symptoms.
• One must be beware of the possibility that an error correction may introduce new
errors. Therefore after every round of error-fixing, regression testing must be carried
out.

Software Maintenance
Software maintenance is the modification of a software product after delivery to correct faults,
to improve performance or other attributes .A common perception of maintenance is that it
merely involves fixing defects. However, one study indicated that the majority, over 80%, of the
maintenance effort is used for non-corrective actions. This perception is perpetuated by users
submitting problem reports that in reality are functionality enhancements to the system.
Software maintenance is needed to correct error enhance feature, portability to new platform.

Necessity of software maintenance

• Software maintenance is becoming an important activity of a large number of software

organizations.
• This is no surprise, given the rate of hardware obsolescence, the immortality of a
software product per se, and the demand of the user community to see the existing
software products run on newer platforms, run in newer environments, and/or with
enhanced features.
• When the hardware platform is changed, and a software product performs some low-
level functions, maintenance is necessary.
• Whenever the support environment of a software product changes, the software
product requires rework to cope up with the newer interface.
• For instance, a software product may need to be maintained when the operating system
changes.

90 *Under revision
 Thus, every software product continues to evolve after its development through
maintenance efforts. Therefore it can be stated that software maintenance is needed to
correct errors, enhance features, port the software to new platforms, etc.

Software maintenance task:

There are basically three types of software maintenance. These are:

• Corrective:
Corrective maintenance of a software product is necessary to rectify the bugs observed while
the system is in use.

• Adaptive:
A software product might need maintenance when the customers need the product to run on
new platforms, on new operating systems, or when they need the product to interface with new
hardware or software.

• Perfective:
A software product needs maintenance to support the new features that users want it to
support, to change different functionalities of the system according to customer demands, or to
enhance the performance of the system.

Problems associated with software maintenance

1. Software maintenance work typically is much more expensive than what it should be
and takes more time than required.
2. In software organizations, maintenance work is mostly carried out using adhoc
techniques.
3. There are no systematic and planned activities for maintaining software.
4. Software maintenance has a very poor image in industry. Therefore, an organization
often cannot employ bright engineers to carry out maintenance work.
5. Even though maintenance suffers from a poor image, the work involved is often more
challenging than development work.
6. During maintenance it is necessary to thoroughly understand someone else’s work and
then carry out the required modifications and extensions.
7. Another problem associated with maintenance work is that the majority of software
products needing maintenance are legacy products.

Legacy software products

A legacy system is hard to maintain. The typical problems associated with legacy systems are
poor documentation, unstructured (spaghetti code with ugly control structure), and lack of
personnel knowledgeable in the product. Many of the legacy systems were developed long time
back. But, it is possible that a recently developed system having poor design and
documentation can be considered to be a legacy system.

91 *Under revision
Factors on which software maintenance activities depend
The activities involved in a software maintenance project are depends on several factors such as:
1. The extent of modification to the product required
2. The resources available to the maintenance team
3. The conditions of the existing product (e.g., how structured it is, how well documented it is,
etc.)
4. The expected project risks, etc.

When the changes needed to a software product are minor and straightforward, the code can be
directly modified and the changes appropriately reflected in all the documents. But more
elaborate activities are required when the required changes are not so trivial. Usually, for
complex maintenance projects for legacy systems, the software process can be represented by a
reverse engineering cycle followed by a forward engineering cycle with an emphasis on as
much reuse as possible from the existing code and other documents.

Software reverse engineering:

Software reverse engineering is the process of recovering the design and the
requirements specification of a product from an analysis of its code. The purpose of
reverse engineering is to facilitate maintenance work by improving the understand
ability of a system and to produce the necessary documents for a legacy system.
Reverse engineering is becoming important, since legacy software products lack proper
documentation, and are highly unstructured. Even well-designed products become
legacy software as their structure degrades through a series of maintenance efforts.

The first stage of reverse engineering usually focuses on carrying out cosmetic
changes to the code to improve its readability, structure, and understand ability,
without changing of its functionalities. A process model for reverse engineering has
been shown in below fig. A program can be reformatted using any of the several
available pretty printer programs which layout the program neatly. Many legacy
software products with complex control structure and unthoughtful variable names are
difficult to comprehend. Assigning meaningful variable names is important because
meaningful variable names are the most helpful thing in code documentation. All
variables, data structures, and functions should be assigned meaningful names
wherever possible. Complex nested conditionals in the program can be replaced by
simpler conditional statements or whenever appropriate by case statements.

REQUIRMENTS
SPECIFICATION

92 *Under revision
 DESIGN

MODULE
SPECIFICATION

CODE

[A process model for reverse engineering]

After the cosmetic changes have been carried out on a legacy software,
the process of extracting the code, design, and the requirements specification can begin.
These activities are schematically shown in fig. In order to extract the design, a full
understanding of the code is needed. Some automatic tools can be used to derive the
data flow and control flow diagram from the code. The structure chart (module
invocation sequence and data interchange among modules) should also be extracted.
The SRS document can be written once the full code has been thoroughly understood
and the design extracted.

Reformat Assign meaningful Simplify

Program Names. Conditions

Simplify Remove
Processing GOTOs
93 *Under revision
[Cosmetic changes carried out before reverse engineering]

Legacy software products:

It is prudent to define a legacy system as any software system that is hard to

maintain. The typical problems associated with legacy systems are poor documentation,
unstructured (spaghetti code with ugly control structure), and lack of personnel
knowledgeable in the product. Many of the legacy systems were developed long time
back. But, it is possible that a recently developed system having poor design and
documentation can be considered to be a legacy system.

Factors on which software maintenance activities depend:

The activities involved in a software maintenance project are not unique and
depend on several factors such as:

• The extent of modification to the product required

• The resources available to the maintenance team

• The conditions of the existing product (e.g., how structured it is, how well
documented it is, etc.)

• The expected project risks, etc.

When the changes needed to a software product are minor and

straightforward, the code can be directly modified and the changes appropriately
reflected in all the documents. But more elaborate activities are required when the
required changes are not so trivial. Usually, for complex maintenance projects for
legacy systems, the software process can be represented by a reverse engineering cycle
followed by a forward engineering cycle with an emphasis on as much reuse as possible
from the existing code and other documents.

94 *Under revision
Software maintenance process models:

Two broad categories of process models for software maintenance can be

proposed. The first model is preferred for projects involving small reworks where the
code is changed directly and the changes are reflected in the relevant documents later.
This maintenance process is graphically presented in fig. In this approach, the project
starts by gathering the requirements for changes. The requirements are next analysed to
formulate the strategies to be adopted for code change. At this stage, the association of
at least a few members of the original development team goes a long way in reducing
the cycle team, especially for projects involving unstructured and inadequately
documented code.

Gather Changed Requirements

Analyse Changed Requirements

Device Code Change Strategies

Apply Code Change Strategies to the Old Codes

Update Documents Integrate & Test

[Maintenance process model 1]

The second process model for software maintenance is preferred for projects
where the amount of rework required is significant. This approach can be represented
by a reverse engineering cycle followed by a forward engineering cycle. Such an

95 *Under revision
approach is also known as software reengineering. This process model is depicted in
the below fig. The reverse engineering cycle is required for legacy products. During the
reverse engineering, the old code is analysed (abstracted) to extract the module
specifications. The module specifications are then analysed to produce the design. The
design is analysed to produce the original requirements specification. The change
requests are then applied to this requirements specification to arrive at the new
requirements specification. At the design, module specification, and coding a
substantial reuse is made from the reverse engineered products. An important
advantage of this approach is that it produces a more structured design compared to
what the original product had, produces good documentation, and very often results in
increased efficiency.

• Reengineering might be preferable for products which exhibit a high failure rate.

• Reengineering might also be preferable for legacy products having poor design and
code structure.

Changed Requirements

Requirements Requirements
Specification Specification

Design Design

Module Module
Specifications Specifications

Code Code

[Maintenance process model 2]

Software reengineering:

96 *Under revision
 Software reengineering is a combination of two consecutive processes i.e.
software reverse engineering and software forward engineering as shown in the fig.

Estimation of approximate maintenance cost:

It is well known that maintenance efforts require about 60% of the total life
cycle cost for a typical software product. However, maintenance costs vary widely from
one application domain to another. For embedded systems, the maintenance cost can be
as much as 2 to 4 times the development cost. Boehm [1981] proposed a formula for
estimating maintenance costs as part of his COCOMO cost estimation model. Boehm’s
maintenance cost estimation is made in terms of a quantity called the Annual Change
Traffic (ACT). Boehm defined ACT as the fraction of a software product’s source
instructions which undergo change during a typical year either through addition or
deletion.

ACT = (KLOC added + KLOC deleted) / KLOC total

Where, KLOC added is the total kilo lines of source code added during
maintenance. KLOC deleted is the total KLOC deleted during maintenance. Thus, the
code that is changed, should be counted in both the code added and the code deleted.
The annual change traffic (ACT) is multiplied with the total development cost to arrive
at the maintenance cost:

Maintenance cost = ACT × development cost

Most maintenance cost estimation models, however, yield only approximate
results because they do not take into account several factors such as experience level of
the engineers, and familiarity of the engineers with the product, hardware
requirements, software complexity, etc.

Software configuration management

The results (also called as the deliverables) of a large software development effort
typically consist of a large number of objects, e.g. source code, design document, SRS
document, test document, user’s manual, etc. These objects are usually referred to and
modified by a number of software engineers throughout the life cycle of the software.
The state of all these objects at any point of time is called the configuration of the

97 *Under revision
software product. The state of each deliverable object changes as development
progresses and also as bugs is detected and fixed.
 Configuration management determines clearly about the items that make up the
software or system. These items include source code, test scripts, third-party
software, hardware, data and both development and test documentation.
 Configuration management is also about making sure that these items are
managed carefully, thoroughly and attentively during the entire project and
product life cycle.
 Configuration management has a number of important implications for testing.
Like configuration management allows the testers to manage their testware and
test results using the same configuration management mechanisms.
 Configuration management also supports the build process, which is important
for delivery of a test release into the test environment. Simply sending Zip archives
by e-mail will not be sufficient, because there are too many opportunities for such
archives to become polluted with undesirable contents or to harbor left-over
previous versions of items. Especially in later phases of testing, it is critical to have
a solid, reliable way of delivering test items that work and are the proper version.

Configuration management is a topic that is very complex. So, advanced planning is

very important to make this work. During the project planning stage – and perhaps as
part of your own test plan – make sure that configuration management procedures and
tools are selected. As the project proceeds, the configuration process and mechanisms
must be implemented, and the key interfaces to the rest of the development process
should be documented.

98 *Under revision
Techniques of SCM Process

SCM is closely related to the software quality assurance (SQA) activity. The goals of
SQA can be characterized as monitoring the software and its development process,
ensuring compliance with standards and procedures, and ensuring that product,
process, and standards defects are visible to management. SCM activities help in
accomplishing these SQA goals.

99 *Under revision
Tool Selection and Implementation
Different types of tool capabilities, and procedures for their use, support the SCM
activities. Depending on the situation, these tool capabilities can be made available
with some combination of manual tools, automated tools providing a single SCM
capability, automated tools integrating a range of SCM capabilities, or integrated tool
environments that serve the needs of multiple participants in the software
development process .

Automated tool support becomes increasingly important, and increasingly difficult to

establish, as projects grow in size and as project environments get more complex. These
tool capabilities provide support for: the SCM Library, the software change request
(SCR) and approval procedures, code (and related work products) and change
management tasks, reporting software configuration status and collecting SCM
measurements, software auditing, managing and tracking software documentation,
performing software builds, and managing and tracking software releases and their
distribution. The use of tools in these areas increases the potential for obtaining product
and process measurements to be used for project management and process
improvement purposes.

In this example, code management systems support the operation of software libraries
by controlling access to library elements, coordinating the activities of multiple users,
and helping to enforce operating procedures. Other tools support the process of
building software and release documentation from the software elements contained in

100 *Under revision

the libraries. Tools for managing software change requests support the change control
procedures applied to controlled software items. Other tools can provide database
management and reporting capabilities for management, development, and quality
assurance activities. As mentioned above, the capabilities of several tool types might be
integrated into SCM systems, which, in turn, are closely coupled to various other
software activities. The planning activity assesses the SCM tool needs for a given project
within the context of the software engineering environment to be used and selects the
tools to be used for SCM. The planning considers issues that might arise in the
implementation of these tools, particularly if some form of culture change is necessary.

Concept of Software Reliability

Most important and dynamic characteristic of software is its reliability. Informally, the
reliability of a software system is a measure of how well it provides the services
expected of it by its users but a useful formal definition of reliability is much harder to
express. Software reliability metrics such as ‘mean time between failures’ may be used
but they do not take into account the subjective nature appropriate and useful.

Users do not consider all services to be of equal importance and a system might be
viewed as unreliable if it ever fails to provide some critical service. For example, say a
system was used to control braking on an aircraft but failed to work a single set of very
rare conditions. If the aircraft crashed because these failure conditions occurred, pilots
of similar aircraft would (reasonably) regard the software as unreliable.

On the other hand, say a comparable software system provided some visual indication
of its actions to the pilot. Assume this failed once per month in a predictable way
without the main system function being affected and other indicators showed that the
control system was working normally. In spite of frequent failure, pilots would not
consider that software as unreliable as the system, which caused the catastrophic
failure.

Reliability is a dynamic system characteristic, which is a function of the number of

software failures. A software failure is an execution event where the software behaves
in an unexpected way. This is not the same as a software fault, which is a static program
characteristic. Software faults cause software failures when the faulty code is executed
with a particular set of inputs. Faults do not always manifest themselves as failures so
the reliability depends on how the software is used. It is not possible to produce a
single, universal statement of the software reliability.

Software faults are not just program defects. Unexpected behaviour can occur in
circumstances where the software conforms to its requirements themselves are
complete. Omissions in software documentations can also lead to unexpected
behaviour, although the software may not contain defects.

101 *Under revision

Reliability depends on how the software is used, so it cannot be specified absolutely.
Each user uses a program in different ways so faults, which affect the reliability of the
system for one user, may never manifest themselves under a different mode of working.
Reliability can only be accurately specified if the normal software operational profile is
also specified.

As reliability is related to the probability of an error occurring in operational use, a

program may contain known faults but may still never be seen select an erroneous
input; the program always appears to be reliable. Furthermore, experienced users may
‘work around’ known software faults and deliberately avoid using features, which they
know to be faulty. Repairing the faults in these features may make no practical
difference to the reliability as perceived by these users.

For example, the word processor used to write this book has an automatic hyphenation
capability. This facility is used when text columns are short and any faults might
manifest themselves when users produce multi-column documents. I never use
hyphenation so, from my viewpoint, faults in the hyphenation code do not affect the
reliability of the word

Error, Fault and Failure

So far, we have used the intuitive meaning of the term error to refer to problems in
requirements, design, or code. Sometimes error, fault, and failure are used inter-
changeably, and sometimes they refer to different concepts. Let us start by defining
these concepts clearly. We follow the IEEE definitions for these terms.

The term error is used in two different ways. It refers to the discrepancy between a
computed, observed, or measured value and the true, specified, or theoretically correct
value. That is, error refers to the difference between the actual output of a software and
the correct output. In this interpretation, error is essentially a measure of the difference
between the actual and the ideal. Error is also used to refer to human action those
results in software containing a defect or fault. This definition is quite general and
encompasses all the phases.

Fault is a condition that causes a system to fail in performing its required function. A
fault is the basic reason for software malfunction and is synonymous with the
commonly used term bug. The term error is also often used to refer to defects (taking a
variation of the second definition of error). In this book, we will continue to use the
terms in the manner commonly used, and no explicit distinction will be made between
errors and faults, unless necessary. It should be noted that the only " faults that a
software has are "design faults"; there is no wear and tear in software.

102 *Under revision

Failure is the inability of a system or component to perform a required function,
according to its specifications. A software failure occurs if the behaviour of the software
is different from the specified behaviour. Failures may be caused due to functional or
performance reasons. A failure is produced only when there is a fault in the system.
However, presence of a fault does not guarantee a failure. In other words, faults have
the potential to cause failures and their presence is a necessary but not a sufficient
condition for failure to occur. Definition does not imply that a failure must
be observed. It is possible that a failure may occur but not be detected.

There are some implications of these definitions. Presence of an error (in the state)
implies that a failure must have occurred, and the observance of a failure implies that a
fault must be present in the system. However, the presence of a fault does not imply
that a failure must occur. The presence of a fault in a system only implies that the fault
has a potential to cause a failure to occur. Whether a fault actually manifests itself in
certain time duration depends on many factors. This means that if we observe the
behaviour of a system for some time and we do not observe any errors, we cannot say
anything about the presence or absence of faults in the system. If, on the other hand, we
observe some failure in this duration, we can say that there are some faults in the
system.

Hardware reliability vs. software reliability

Reliability behaviour for hardware and software are very different. For example, hardware
failures are inherently different from software failures. Most hardware failures are due to
component wear and tear. A logic gate may be stuck at 1 or 0,or a resistor might short circuit. To
fix hardware faults, one has to either replace or repair the failed part. On the other hand, a
software product would continue to fail until the error is tracked down and either the design or
the code is changed. For this reason, when a hardware is repaired its reliability is maintained at
the level that existed before the failure occurred; whereas when a software failure is repaired,
the reliability may either increase or decrease (reliability may decrease if a bug introduces new
errors). To put this fact in a different perspective, hardware reliability study is concerned with
stability (for example, inter-failure times remain constant). On the other hand, software
reliability study aims at reliability growth (i.e. inter-failure times increase). The change of failure
rate over the product lifetime for a typical hardware and a software product are sketched
below. For hardware products, it can be observed that failure rate is high initially but decreases
as the faulty components are identified and removed.

Reliability metrics

The reliability requirements for different categories of software products may be

different. For this reason, it is necessary that the level of reliability required for a
software product should be specified in the SRS (software requirements specification)
document. In order to be able to do this, some metrics are needed to quantitatively
express the reliability of a software product. A good reliability measure should be
103 *Under revision
observer-dependent, so that different people can agree on the degree of reliability a
system has. For example, there are precise techniques
for measuring performance, which would result in obtaining the same performance
value irrespective of who is carrying out the performance measurement. However, in
practice, it is very difficult to formulate a precise reliability measurement technique. The
next base case is to have measures that correlate with reliability. There are six reliability
metrics which can be used to quantify the reliability of software products.

Rate of occurrence of failure (ROCOF).

• ROCOF measures the frequency of occurrence of unexpected behavior (i.e.
failures).
• ROCOF measure of a software product can be obtained by observing the
behavior of a software product in operation over a specified time interval and
then recording the total number of failures occurring during the interval.
• It
Mean Time To Failure (MTTF).
• MTTF is the average time between two successive failures, observed over a large
number of failures.
• To measure MTTF, we can record the failure data for n [Link] MTTF of 500
means that one failure can be expected in every 500 time unit.
• MTTF is relevant for system with long transaction i.e when processing takes long
time
Mean Time To Repair (MTTR).
• Once failure occurs, some time is required to fix the error.
• MTTR measures the average time it takes to track the errors causing the failure
and to fix them.
Mean Time Between Failure (MTBF).
• MTTF and MTTR can be combined to get the MTBF metric: MTBF = MTTF +
MTTR.
• MTBF of 300 hours indicates that once a failure occurs, the next failure is
expected after 300 hours. In this case, time measurements are real time and not
the execution time as in MTTF.
Probability of Failure on Demand (POFOD).
• This metric does not explicitly involve time measurements.
• POFOD measures the likelihood of the system failing when a service request is
made.
• For example, a POFOD of 0.001would mean that 1 out of every 1000 service
requests would result in a failure.
Availability.
• Availability of a system is a measure of how likely shall the system be available
for use over a given period of time.

104 *Under revision

 • This metric not only considers the number of failures occurring during a time
interval, but also takes into account the repair time (down time) of a system
when a failure occurs.
• This metric is important for systems such as telecommunication systems, and
operating systems, which are supposed to be never down and where repair and
restart time are significant and loss of service during that time is important.

AVAILABILITY =

Reliability growth models

A reliability growth model is a mathematical model of how software reliability

improves as errors are detected and repaired. A reliability growth model can be used to
predict when (or if at all) a particular level of reliability is likely to be attained. Thus,
reliability growth modelling can be used to determine when to stop testing to attain a
given reliability level. Although several different reliability growth models have been
proposed, in this text we will discuss only two very simple reliability growth models.

Jelinski and Moranda Model

The simplest reliability growth model is a step function model where it is assumed that
the reliability increases by a constant increment each time an error is detected and
repaired. However, this simple model of reliability which implicitly assumes that all
errors contribute equally to reliability growth, is highly unrealistic since it is already
known that correction of different types of errors contribute differently to reliability
growth.

105 *Under revision

Littlewood and Verall’s Model

This model allows for negative reliability growth to reflect the fact that when a repair is
carried out, it may introduce additional errors. It also models the fact that as errors are
repaired, the average improvement in reliability per repair decreases .It treat’s an
error’s contribution to reliability improvement to be an independent random variable
having Gamma distribution. This distribution models the fact that error corrections
with large contributions to reliability growth are removed first. This represents
diminishing return as test continues.

106 *Under revision

Software quality, SEI CMM and ISO-9001

Software quality:

A quality product is defined in terms of its fitness of purpose robustness. That is,
a quality product does exactly what the users want it to do. For software products,
fitness of purpose is usually interpreted in terms of satisfaction of the requirements laid
down in the SRS document.
The modern view of a quality associates with a software product several quality
factors such as the following:

Portability: A software product is said to be portable, if it can be easily made to
work in different operating system environments, in different machines, with
other software products, etc. It should platform independent.

Usability: A software product has good usability, if different categories of users
(i.e. both expert and novice users) can easily invoke the functions of the product
easy to handle.

Reusability: A software product has good reusability, if different modules of the
product can easily be reused to develop new products.

Correctness: A software product is correct, if different requirements as specified
in the SRS document have been correctly implemented.

Maintainability: A software product is maintainable, if errors can be easily
corrected as and when they show up, new functions can be easily added to the
product, and the functionalities of the product can be easily modified, etc.

107 *Under revision

SEI Capability Maturity Model:

 SEI Capability Maturity Model (SEI CMM) helped organizations to improve the
quality of the software they develop and therefore adoption of SEI CMM model
has significant business benefits.
 SEI CMM can be used two ways: capability evaluation and software process
assessment.

Capability evaluation:
Capability evaluation provides a way to assess the software process
capability of an organization.
Software process assessment:
Software process assessment is used by an organization with the objective to
improve its process capability.

 SEI CMM classifies software development industries into the following five
maturity levels.
Level 1: Initial.
A software development organization at this level is characterized by ad
hoc activities. Very few or no processes are defined and followed.

Level 2: Repeatable.
At this level, the basic project management practices such as tracking cost
and schedule are established.

Level 3: Defined.
At this level the processes for both management and development
activities are defined and documented.

Level 4: Managed.
At this level, the focus is on software metrics.

Level 5: Optimizing.
At this stage, process and product metrics are collected.

Personal software process:

o Personal Software Process (PSP) is a scaled down version of the industrial
software process.
o PSP is suitable for individual use. SEI CMM does not tell software developers
how to analyze, design, code, test, or document software products, but assumes
that engineers use effective personal practices.
o PSP recognizes that the process for individual use is different from that for a
team.

108 *Under revision

Six sigma:
o The purpose of Six Sigma is to improve processes to do things better, faster, and
at lower cost.
o It can be used to improve every facet of business, from production, to human
resources, to order entry, to technical support.
o Six Sigma can be used for any activity that is concerned with cost, timeliness, and
quality of results.
Sub-methodologies: DMAIC and DMADV.
The Six Sigma DMAIC process (defines, measure, analyze, improve,
control) is an improvement system for existing processes failing below
specification and looking for incremental improvement.
The Six Sigma DMADV process (define, measure, analyze, design, verify)
is an improvement system used to develop new processes or products at Six
Sigma quality levels.

ISO 9000 certification:

 ISO certification serves as a reference for contract between independent parties.

 The ISO 9000 standard specifies the guidelines for maintaining a quality system.
 ISO 9000 specifies a set of guidelines for repeatable and high quality product
development.

Types of ISO 9000 quality standards:

ISO 9000 is a series of three standards: ISO 9001, ISO 9002, and ISO 9003.
ISO 9001:
ISO 9001 applies to the organizations that engaged in design, development,
production, and servicing of goods. This is the standard that is applicable to most
software development organizations.
ISO 9002:
ISO 9002 applies to those organizations which do not design products but are
only involved in production.
ISO 9003:
ISO 9003 applies to organizations that are involved only in installation and
testing of the products.

109 *Under revision

Salient features of ISO 9001 certification:
The salient features of ISO 9001 are as follows:

All documents concerned with the development of a software product should be
properly managed, authorized, and controlled.

Important documents should be independently checked and reviewed for
effectiveness and correctness.

The product should be tested against specification.

Several organizational aspects should be addressed e.g., management reporting
of the quality team

Software Reliability

 Reliability of software product can be defined as the probability of the product

working correctly over a given period of time.

 Software reliability is defined in statistical terms as "the probability of failure-free

operation of a computer program in a specified environment for a specified time"

 It is obvious that a software product having a large number of defects is

unreliable. It is also clear that the reliability of a system improves, if the number
of defects in it is reduced.

 Reliability of a product depends not only on the number of latent errors but also
on the exact location of the errors.

 The reliability figure of a software product is observer-dependent, and it is very

difficult to absolutely quantify the reliability of the product.

Hardware vs Software Reliability:

Reliability behaviour for hardware and software are very different. For example,
hardware failures are inherently different from software failures. Most hardware
failures are due to component wear and tear. A logic gate may be stuck at 1 or 0, or a
resistor might short circuit. To fix hardware faults, one has to either replace or repair
the failed part.

On the other hand, a software product would continue to fail until the error is
tracked down and either the design or the code is changed. For this reason, when a
hardware is repaired its reliability is maintained at the level that existed before the
failure occurred.

110 *Under revision

 Burn
Wear
in
out
Useful life
Failure
rate

time

(a) Hardware product

Failure Useful life

rate
obsolete
testing

time

(b) Software product

Reliability Metrices:

The reliability requirements for different categories of software products may be

different. For this reason, it is necessary that the level of reliability required for a
software product should be specified in the SRS (software requirements specification)
document. In order to be able to do this, some metrics are needed to quantitatively
express the reliability of a software product.

There are six reliability metrics which can be used to quantify the reliability of
software products.

111 *Under revision

 1. Rate of occurrence of failure (ROCOF) :
ROCOF measures the frequency of occurrence of unexpected behaviour
(i.e. failures).
ROCOF measure of a software product can be obtained by observing the
behaviour of a software product in operation over a specified time interval and
then recording the total number of failures occurring during the interval.
2. Mean Time To Failure (MTTF)
MTTF is the average time between two successive failures, observed over
a large number of failures. To measure MTTF, it is recorded the failure data for n
failures. Let the failures occur at the time instants t1, t2, …, tn. Then, MTTF can
be calculated as calculated as:

3. Mean Time To Repair (MTTR)

Once failure occurs, some time is required to fix the error. MTTR measures
the average time it takes to track the errors causing the failure and to fix them.
4. Mean Time Between Failure (MTBR)
MTTF and MTTR can be combined to get the MTBR metric: MTBF =
MTTF + MTTR. Thus, MTBF of 300 hours indicates that once a failure occurs, the
next failure is expected after 300 hours. In this case, time measurements are real
time and not the execution time as in MTTF.
5. Probability of Failure on Demand (POFOD)
POFOD measures the likelihood of the system failing when a service
request is made. For example, a POFOD of 0.001 would mean that 1 out of every
1000 service requests would result in a failure.

6. Availability
It considers the time interval up to which the product remains unaffected.
Availability of a system is a measure of how likely shall the system be available
for use over a given period of time. This metric not only considers the number of
failures occurring during a time interval, but also takes into account the repair
time (down time) of a system when a failure occurs.

Reliability Growth Modelling:

A reliability growth model is a mathematical model of how software reliability

improves as errors are detected and repaired. A reliability growth model can be used to
predict when (or if at all) a particular level of reliability is likely to be attained.

Jelinski and Moranda Model:

112 *Under revision
o The simplest reliability growth model is a step function model where it is
assumed that the reliability increases by a constant increment each time an error
is detected and repaired.

o This simple model of reliability which implicitly assumes that all errors
contribute equally to reliability growth, is highly unrealistic since it is already
known that correction of different types of errors contribute differently to
reliability growth.

ROCOF

Time

[Step function model of reliability growth]

Littlewood and Verall’s Model:

o This model allows for negative reliability growth to reflect the fact that when a
repair is carried out, it may introduce additional errors.
o It also models the fact that as errors are repaired, the average improvement in
reliability per repair decreases

113 *Under revision

 Different reliability movements

Fault repair adds new fault and

decreases reliability (increases ROCOF)

ROCOF

Time
[Random-step function model of reliability growth]

Fault Tolerance

 Fault tolerance is defined as how to provide reliabiliy, by redundancy, service

complying with the specification in spite of faults having occurred or occurring.
 Other important concepts according to Laprie is that fault tolerance is
accomplished using redundancy. This argument is good for errors which are not
caused by design faults, however, replicating a design fault in multiple places will
not aide in complying with a specification.

Software Fault Tolerance:

o Software fault tolerance is the ability for software to detect and recover from a
fault that is happening or has already happened in either the software or
hardware in the system in which the software is running in order to provide
service in accordance with the specification.
o Software fault tolerance is a necessary component in order to construct the next
generation of highly available and reliable computing systems from embedded
systems to data warehouse systems.

Tools, Techniques, and Metrics

Metrics:

Metrics in the area of software fault tolerance, (or software faults,) are generally
pretty poor.

114 *Under revision


The data sets that have been analyzed in the past are surely not indicative of
today's large and complex software systems.

Tools:

Software fault tolerance has an extreme lack of tools in order to aid the
programmer in making reliable system.

This lack of adequate tools is not very different from the general lack of
functional tools in software development that go beyond an editor and a
compiler.

Techniques:

Recovery Blocks:

The recovery block method is a simple method developed by Randell

from what was observed as somewhat current practice at the time. The recovery
block operates with an adjudicator which confirms the results of various
implementations of the same algorithm.

N-version Software:

The N-version software concept attempts to parallel the traditional

hardware fault tolerance concept of N-way redundant hardware. In an N-version
software system, each module is made with up to N different implementations.

Self-Checking Software:

Self checking software is not a rigorously described method in the

literature, but rather a more ad hoc method used in some important systems.
Self-checking software has been implemented in some extremely reliable and
safety-critical systems already deployed in our society, including the Lucent ESS-
5 phone switch and the Airbus A-340 airplane

Hardware Fault Tolerance:

o Current software fault tolerance is based on traditional hardware fault tolerance,

(for better or worse.) Both hardware and software fault tolerance are beginning
to face the new class of problems of dealing with design faults.
o Hardware designers will soon face how to create a microprocessor that
effectively uses one billion transistors; as part of that daunting task, making the
microprocessor correct becomes more challenging. In the future, hardware and

115 *Under revision

 software may cooperate more in achieving fault tolerance for the system as a
whole.

Software Project Planning, Monitoring, and Control

Project planning:

Once a project is found to be feasible, software project managers undertake project

planning. Project planning is undertaken and completed even before any development
activity starts. Project planning consists of the following essential activities:
o Estimating the following attributes of the project:
Project size: What will be size of the project and problem complexity in terms
of the effort and time required to develop the product?
Cost: How much is it going to cost to develop the project?
Duration: How long is it going to take to complete development?
Effort: How much effort would be required?
o Scheduling manpower and other resources
o Staff organization and staffing plans
o Risk identification, analysis, and abatement planning
o Miscellaneous plans such as quality assurance plan, configuration management
plan, etc

Project Monitoring and Control:

The project monitoring and control activities are undertaken once the
development activities start with the aim of ensuring that the development proceeds as
per plan and changing the plan whenever required to cope up with the situation.

Computer Aided Software Engineering(CASE)

 CASE is a tool that helps a software engineer to maintain the level of the
software.
 This CASE tool is an integrated part of workshop of software engineering, which
is called integrated project support environment (IPSE).
 CASE provides automated support to following software engineering processes.

Examples:

• Translation of user need into software requirements.

116 *Under revision

 • Translation of software requirements into design specifications.
• Implementation of design into code.
• Testing of the code written by the programmers.
• Documentation of the project.

It also provides automation for various process activities such as:

• Development of graphical system model as a part of the requirement

specifications for software engineering.
• Understanding a design using data dictionary.
• Generation of user interface (GUI) from graphical interface designed by
users.
• Automated translation of program from old to most recent language.
i.e. COBOL to Java

SYSTEM ANALYSIS PRINTER

CASE REPOSITORY

• Case repository- case repository usually stores into that they may be shared by
multiple projects and participants..

Lavel of Case:

There are three different level of the CASE technology which are as follows.

117 *Under revision

 • Production process support technology:
This includes the support for process activity such as specification, design,
implementation, testing, etc.
• Process management and technology:
This includes tools to support process modelling and management.
• Meta case technology:
These tools are generator to create production process management
support tools.

Case Environment Architecture:

Diagram:

Important component of a modern CASE environment are

1. User interface
2. Tool set
3. Object management system
4. CASE repository

1. User interface:
User interface provides a common framework for accessing different tools by
simplifying and reducing the time of learning of the tools.
2. Tool set:

118 *Under revision

 It control the behaviour of the tool within the environment by performing
multitask synchronisation and composition. Co-ordinating the flow of
information repository to OMS into the tools.
It provides security function, collect feedbacks on tool usage.
3. Object management system:
It performs the mapping of logical entities such as specification data, design data,
project planning data, etc into the storage management system. i.e. repository.
It also has object management language (OML) module to provide support for
version control, change control, status control and security control.
4. CASE repository:
This is the case data base containing access control function to enable the OMS
to interact with the data base.
* Provided by case environment externally supported.

Objectives of Case:

The various objectives are

• Improvement in productivity: by reducing the time of design and development.

• Improvement in information system quality: by providing automation.
• Improvement of effectiveness: performing the right task with minimal effort.

Disadvantages Of Case:

1. High cost of purchase and use.

2. High cost of training the user.
3. It s not easy to share information between tools.
4. Software people often see CASE as a theft to their job security.

CHARACTERISTICS OF THE CASE TOOLS:

1. Graphical interface to draw diagram, models, etc.

2. An information repository, data dictionary for official information management,
selection, usage, application, storage.
3. Common GUI for integrated multiple tools.
4. Automatic code generator.
5. Automatic testing tools.

119 *Under revision

 Sl. Application CASE tools Purpose of the tools
No.
1 Planning Excel, Spreadsheet, MS- Functional application
project, PERT/CPM, planning in scheduling
Network, Estimation control
tools
2 Editing Diagram editors, Text Speed and effective
editors, word processors
3 Testing Test data generators, Speed and efficiency
FILE comparators
4 Prototyping High level modelling Confirmation and
language,UI- generators certification of RDD and SRS
5 Documentation Report generator, Faster structural
Publishing, Imaging, ppt documentation with quality
presentation of presentation.
6 Programming Program generator Programming of high
language Code generator quality with no errors
processing and Compiler system integration
integration Interpreter
Interface connectivity
7 Templates --------- Guided systemic
development
8 Re engineering Cross reference system Reverse engineering to fixed
tools Restructuring system structure design and
destination information
9 Program Cross interface generator Analyses risk functions and
analysis tools Static analyzers features.
Dynamic analyzers

Component Model of Software Development

Components:
o Components provide a service without regard to where the component is
executing or its programming language.
o A component is an independent executable entity that can be made up of one or
more executable objects.
o The component interface is published and all interactions are through the
published interface.
Definitions:

120 *Under revision

 A software component is a software element that conforms to a component
model and can be independently deployed and composed without modification
according to a composition standard.

Component model:
o A component model is a definition of standards for component implementation,
documentation and deployment.
o Examples of component models

EJB model (Enterprise Java Beans)

COM+ model (.NET model)

Corba Component Model
o The component model specifies how interfaces should be defined and the
elements that should be included in an interface definition.

Component-based development:
It is the enabler of the client-server technology. Component-based development
is radically different from traditional software development. In component-based
development, a developer essentially integrates pre-built components purchased off-the
shelf. This is akin to the way hardware developers integrate ICs on a Printed Circuit
Board (PCB). Components might reside on different computers which act as servers and
clients.

Definition of Component Based Software Engineering:

Component-based software engineering (CBSE) is a process that emphasizes the design

and construction of computer-based systems using reusable

Component-based software engineering (CBSE) is a branch of software engineering

which emphasizes the separation of concerns in respect of the wide-ranging
functionality available throughout a given software system. This practice aims to bring
about an equally wide-ranging degree of benefits in both the short-term and the long-
term for the software itself and for organizations that sponsor such software.

Objectives of Component Based Software Engineering:

The main objectives of component based software engineering are given below.

a) Reduction of cost and time for building large and complicated systems: main
objective of Component based approach is to build complicated software systems using
off the shelf component so that the time to build the software diminish drastically.

121 *Under revision

b) Improving the quality of the software: The quality of the software can be improved
by improving the quality of the component. Sometimes quality of the assembled
systems may not be directly related to quality of the component in sense that improving
the quality of the component does not necessarily imply the improvement of the
systems.

c) Detection of defect within the systems: Component approach helps the system to find
its defect readily by testing the components. But the source of defects is difficult to find
in case of component development approach.

few basic definition regarding software components:-

Component—It is a nontrivial, nearly independent, and replaceable part of a system

that fulfils a clear function in the context of a well-defined architecture.

Run-time software component—It is a dynamic bindable package of one or more

programs managed as a unit and accessed through documented interfaces that can be
discovered in run time.

Software component—It is a unit of composition with contractually specified and

explicit context dependencies only.

Business component—It is the software implementation of an “autonomous” business

concept or business process.

In addition to these descriptions, software components can also be characterized based

on their use in the CBSE process

Qualified components—assessed by software engineers to ensure that not only

functionality, but performance, reliability, usability, and other quality factors conform
to the requirements of the system or product to be built.

Adapted components—adapted to modify (also called mask or wrap) unwanted or

undesirable characteristics.

Assembled components—integrated into an architectural style and interconnected with

an appropriate infrastructure that allows the components to be coordinated and
managed effectively.

Updated components—replacing existing software as new versions of components

become available.

122 *Under revision

Component Based Software Engineering Processes:

Disadvantages of Component Based Development:

The main disadvantages of CBD are given below:
1. it is very difficult to build the environment that is fitted to component
2. Concept of reuse: Standards are needed regarding middleware in which the
component is supposed to work. (Middleware: A communication layer which enables
components to interact with higher level component in a network). But among the three
standards available, only CORBA is language independent. Hence the comparison is
not viable among the standards.

Advantages of Component Based Development:

1. Flexibility: runtime components can work independently if properly designed and
they are less dependent on the environment
2. Reuse: Once developed, it can be used everywhere regarding the programming
language and OS. But domain engineering should be kept in mind
123 *Under revision
3. Easy to maintain because ideally the functionality is implemented once
4. Development cost is much lower
5. Lesser time required to build the software

Software Reuse

Software reuse makes repeated use of component from the previously developed
software in order to reduce the software cost by providing high quality and reliability.

The components which can be re-used are:-

a. Requirement specification
b. Design
c. Coding
d. Test cases
e. Knowledge and Experience

The entire component can be re effectively re use by providing with proper

documentation.

Reason for limited reuse:

1. It is very difficult to credit the component they can be reused across different
application.
2. Developers are not consulting about providing necessary attention toward
the component which can be reuse from the previously developed system.

Basic issues in program reuse:

The issues are:-

a. Component Creation.
b. Component Index and Testing.
c. Component Search.
d. Component Understanding.
e. Component Adoption
f. Repository Maintenance

Reuse Approach:

124 *Under revision

The reuse approach is critically end toward identifying reusable component by domain
analysis i.e. analyzing a problem domain.

125 *Under revision

Domain Analysis:

 It provides a reuse domain which is technically related set of application area.

For example: Account Software Domain, Banking Software Domain,
Business Software Domain, Telecommunication Software Domain etc.
 A part of problem domain is considered for reuse. If it is shared by
understanding some community, characterized by concept/ techniques and
coherence in the terminologies.
 During domain analysis a community of software developer analysis application
domain to identify the reusable component. The detailed list of reusable
component for a particular component is called domain engineering.

As a domain developer we can classify it in different stages:-

Stage-1: No reusable components are available.

No clear and consistency methodology is available.

Stage-2: Knowledge re-use is made in the new development method.

Stage-3: Domain is made suitable for reuse by providing standard solution to the
problem. We can make knowledge in component reuse.

Stage-4: Complete domain development can be done by reuse and the program are
written using application generator.

Component Classification:

Component can be classified by their level of ambiguity for effective storage structure.
For this a classification is used called as Prito-Diaz’s Classification scheme.

Each component is best described using number of characteristics or facts:

Ex: Object can be classified using following.

• Action they embody.

• Object thy Manipulate
• Data Structure Used
• System they are part of end so forth.

126 *Under revision

This classification scheme makes us search for required component which is best suited
for a system this is very difficult.

Component Search:

Component searching for reuse can be easily written through a web based domain
repository contains thousands of items. However inside the repository there must be
classification between component / design /models / requirement / knowledge to
make searching easier.

Repository Maintenance:

It involves adding of new reused artifacts, deleting those items which are no use,
modifying the search criteria to improve effectiveness of search.

Reuse without Modification:

Reuse without modification is reused once standard solution for program models are
available.

Reuse of Organization level:

Three cases involved in the reorder.

1. Assessment of a product for reuse.

2. Replacement of a product for improvement for reusability.
3. Handling portability problem of reuse problems.

Current Stage of reuse Methodology:

Factor effective reuses of software product are mostly non-technically these are as
follows:

• Limited commitment from the top management.

• No ad acute documentation for support reuse.
• No ad acute record reward to those who reuse.
• Providing information and access to reuse Component.
•

127 *Under revision

128 *Under revision
 3.1

UNIT III ARCHITECTURE AND DESIGN

Software design – Design process – Design concepts – Coupling – Cohesion – Functional
independence – Design patterns – Model-view-controller – Publish-subscribe – Adapter –
Command – Strategy – Observer – Proxy – Facade – Architectural styles – Layered - Client-
server - Tiered - Pipe and filter.- User interface design

SOFTWARE ARCHITECTURE & DESIGN INTRODUCTION

The architecture of a system describes its major components, their relationships (structures),
and how they interact with each other. Software architecture and design includes several
contributory factors such as Business strategy, quality attributes, human dynamics, design,
and IT environment.

We can segregate Software Architecture and Design into two distinct phases: Software
Architecture and Software Design. In Architecture, nonfunctional decisions are cast and
separated by the functional requirements. In Design, functional requirements are
accomplished.

Software Architecture

Architecture serves as a blueprint for a system. It provides an abstraction to manage the

system complexity and establish a communication and coordination mechanism among
components. It defines a structured solution to meet all the technical and operational
requirements, while optimizing the common quality attributes like performance and security.

Further, it involves a set of significant decisions about the organization related to software
development and each of these decisions can have a considerable impact on quality,
maintainability, performance, and the overall success of the final product. These decisions
comprise of −

 Selection of structural elements and their interfaces by which the system is composed.
 Behavior as specified in collaborations among those elements.
 Composition of these structural and behavioral elements into large subsystem.
 Architectural decisions align with business objectives.
 Architectural styles guide the organization.

Software Design
 3.2

Software design provides a design plan that describes the elements of a system, how they fit,
and work together to fulfill the requirement of the system. The objectives of having a design
plan are as follows −

 To negotiate system requirements, and to set expectations with customers, marketing,

and management personnel.
 Act as a blueprint during the development process.
 Guide the implementation tasks, including detailed design, coding, integration, and
testing.

Domain analysis, requirements analysis, and risk analysis comes before architecture design
phase, whereas the detailed design, coding, integration, and testing phases come after it.

Goals of Architecture

The primary goal of the architecture is to identify requirements that affect the structure of the
application. A well-laid architecture reduces the business risks associated with building a
technical solution and builds a bridge between business and technical requirements.

Some of the other goals are as follows −

 Expose the structure of the system, but hide its implementation details.
 Realize all the use-cases and scenarios.
 Try to address the requirements of various stakeholders.
 Handle both functional and quality requirements.
 Reduce the goal of ownership and improve the organization’s market position.
 Improve quality and functionality offered by the system.
 Improve external confidence in either the organization or system.

Limitations

Software architecture is still an emerging discipline within software engineering. It has the
following limitations −

 Lack of tools and standardized ways to represent architecture.

 3.3

 Lack of analysis methods to predict whether architecture will result in an

implementation that meets the requirements.
 Lack of awareness of the importance of architectural design to software development.
 Lack of understanding of the role of software architect and poor communication
among stakeholders.
 Lack of understanding of the design process, design experience and evaluation of
design.

Role of Software Architect

A Software Architect provides a solution that the technical team can create and design for the
entire application. A software architect should have expertise in the following areas −

Design Expertise

 Expert in software design, including diverse methods and approaches such as object-
oriented design, event-driven design, etc.
 Lead the development team and coordinate the development efforts for the integrity of
the design.
 Should be able to review design proposals and tradeoff among themselves.

Domain Expertise

 Expert on the system being developed and plan for software evolution.
 Assist in the requirement investigation process, assuring completeness and
consistency.
 Coordinate the definition of domain model for the system being developed.

Technology Expertise

 Expert on available technologies that helps in the implementation of the system.

 Coordinate the selection of programming language, framework, platforms, databases,
etc.

Methodological Expertise

 Expert on software development methodologies that may be adopted during SDLC

(Software Development Life Cycle).
 Choose the appropriate approaches for development that helps the entire team.

Deliverables of the Architect

An architect is expected to deliver clear, complete, consistent, and achievable set of

functional goals to the organization. Besides, he is also responsible to provide −

 A simplified concept of the system

 A design in the form of the system, with at least two layers of decomposition.
 A functional description of the system, with at least two layers of decomposition.
 A notion of the timing, operator attributes, and the implementation and operation
plans
 3.4

 A document or process which ensures functional decomposition is followed, and the

form of interfaces is controlled

Hidden Role of Software Architect

Besides, facilitating the technical work among team members, it has also some subtle roles
such as reinforce the trust relationship among team members and protect team members from
the external forces that could distract them and bring less value to the project.

SOFTWARE DESIGN

Software design is a process to transform user requirements into some suitable form,
which helps the programmer in software coding and implementation.

For assessing user requirements, an SRS (Software Requirement Specification)

document is created whereas for coding and implementation, there is a need of more specific
and detailed requirements in software terms. The output of this process can directly be used
into implementation in programming languages.

Software design is the first step in SDLC (Software Design Life Cycle), which moves
the concentration from problem domain to solution domain. It tries to specify how to fulfill
the requirements mentioned in SRS.

Software Design Levels

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

Modularization

Modularization is a technique to divide a software system into multiple discrete and

independent modules, which are expected to be capable of carrying out task(s) independently.
These modules may work as basic constructs for the entire software. Designers tend to design
modules such that they can be executed and/or compiled separately and independently.
 3.5

Modular design unintentionally follows the rules of ‘divide and conquer’ problem-solving
strategy this is because there are many other benefits attached with the modular design of a
software.

Advantage of modularization:

 Smaller components are easier to maintain

 Program can be divided based on functional aspects
 Desired level of abstraction can be brought in the program
 Components with high cohesion can be re-used again
 Concurrent execution can be made possible
 Desired from security aspect

Concurrency

Back in time, all software are meant to be executed sequentially. By sequential execution we
mean that the coded instruction will be executed one after another implying only one portion
of program being activated at any given time. Say, a software has multiple modules, then
only one of all the modules can be found active at any time of execution.

In software design, concurrency is implemented by splitting the software into multiple

independent units of execution, like modules and executing them in parallel. In other words,
concurrency provides capability to the software to execute more than one part of code in
parallel to each other.

It is necessary for the programmers and designers to recognize those modules, which can be
made parallel execution.

Example

The spell check feature in word processor is a module of software, which runs along side the
word processor itself.

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

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.

There are seven types of cohesion, namely –

 3.6

 Co-incidental cohesion - It is unplanned and random cohesion, which might be the

result of breaking the program into smaller modules for the sake of modularization.
Because it is unplanned, it may serve confusion to the programmers and is generally
not-accepted.
 Logical cohesion - When logically categorized elements are put together into a
module, it is called logical cohesion.
 Temporal Cohesion - When elements of module are organized such that they are
processed at a similar point in time, it is called temporal cohesion.
 Procedural cohesion - When elements of module are grouped together, which are
executed sequentially in order to perform a task, it is called procedural cohesion.
 Communicational cohesion - When elements of module are grouped together, which
are executed sequentially and work on same data (information), it is called
communicational cohesion.
 Sequential cohesion - When elements of module are grouped because the output of
one element serves as input to another and so on, it is called sequential cohesion.
 Functional cohesion - It is considered to be the highest degree of cohesion, and it is
highly expected. Elements of module in functional cohesion are grouped because they
all contribute to a single well-defined function. It can also be reused.

Coupling

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.

There are five levels of coupling, namely -

 Content coupling - When a module can directly access or modify or refer to the
content of another module, it is called content level coupling.
 Common coupling- When multiple modules have read and write access to some
global data, it is called common or global coupling.
 Control coupling- Two modules are called control-coupled if one of them decides the
function of the other module or changes its flow of execution.
 Stamp coupling- When multiple modules share common data structure and work on
different part of it, it is called stamp coupling.
 Data coupling- Data coupling is when two modules interact with each other by
means of passing data (as parameter). If a module passes data structure as parameter,
then the receiving module should use all its components.

Ideally, no coupling is considered to be the best.

Design Verification

The output of software design process is design documentation, pseudo codes, detailed logic
diagrams, process diagrams, and detailed description of all functional or non-functional
requirements.

The next phase, which is the implementation of software, depends on all outputs mentioned
above.
 3.7

It is then becomes necessary to verify the output before proceeding to the next phase. The
early any mistake is detected, the better it is or it might not be detected until testing of the
product. If the outputs of design phase are in formal notation form, then their associated tools
for verification should be used otherwise a thorough design review can be used for
verification and validation.

By structured verification approach, reviewers can detect defects that might be caused by
overlooking some conditions. A good design review is important for good software design,
accuracy and quality.

Software process designing concepts

Introduction to design process

 The main aim of design engineering is to generate a model which shows firmness,
delight and commodity.
 Software design is an iterative process through which requirements are translated into
the blueprint for building the software.

Software quality guidelines

 A design is generated using the recognizable architectural styles and compose a good
design characteristic of components and it is implemented in evolutionary manner for
testing.
 A design of the software must be modular i.e the software must be logically
partitioned into elements.
 In design, the representation of data , architecture, interface and components should
be distinct.
 A design must carry appropriate data structure and recognizable data patterns.
 Design components must show the independent functional characteristic.
 A design creates an interface that reduce the complexity of connections between the
components.
 A design must be derived using the repeatable method.
 The notations should be use in design which can effectively communicates its
meaning.

Quality attributes

The attributes of design name as 'FURPS' are as follows:

Functionality:
It evaluates the feature set and capabilities of the program.

Usability:
It is accessed by considering the factors such as human factor, overall aesthetics, consistency
and documentation.

Reliability:
It is evaluated by measuring parameters like frequency and security of failure, output result
accuracy, the mean-time-to-failure(MTTF), recovery from failure and the the program
 3.8

predictability.

Performance:
It is measured by considering processing speed, response time, resource consumption,
throughput and efficiency.

Supportability:

 It combines the ability to extend the program, adaptability, serviceability. These three
term defines the maintainability.
 Testability, compatibility and configurability are the terms using which a system can
be easily installed and found the problem easily.
 Supportability also consists of more attributes such as compatibility, extensibility,
fault tolerance, modularity, reusability, robustness, security, portability, scalability.

Design concepts

The set of fundamental software design concepts are as follows:

1. Abstraction

 A solution is stated in large terms using the language of the problem environment at
the highest level abstraction.
 The lower level of abstraction provides a more detail description of the solution.
 A sequence of instruction that contain a specific and limited function refers in a
procedural abstraction.
 A collection of data that describes a data object is a data abstraction.

2. Architecture

 The complete structure of the software is known as software architecture.

 Structure provides conceptual integrity for a system in a number of ways.
 The architecture is the structure of program modules where they interact with each
other in a specialized way.
 The components use the structure of data.
 The aim of the software design is to obtain an architectural framework of a system.
 The more detailed design activities are conducted from the framework.

[Link]
A design pattern describes a design structure and that structure solves a particular design
problem in a specified content.

4. Modularity

 A software is separately divided into name and addressable components. Sometime

they are called as modules which integrate to satisfy the problem requirements.
 Modularity is the single attribute of a software that permits a program to be managed
easily.

5. Information hiding
 3.9

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.

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

Cohesion

 Cohesion is an extension of the information hiding concept.

 A cohesive module performs a single task and it requires a small interaction with the
other components in other parts of the program.

Coupling
Coupling is an indication of interconnection between modules in a structure of software.

7. Refinement

 Refinement is a top-down design approach.

 It is a process of elaboration.
 A program is established for refining levels of procedural details.
 A hierarchy is established by decomposing a statement of function in a stepwise
manner till the programming language statement are reached.

8. Refactoring

 It is a reorganization technique which simplifies the design of components without

changing its function behaviour.
 Refactoring is the process of changing the software system in a way that it does not
change the external behaviour of the code still improves its internal structure.

9. Design classes

 The model of software is defined as a set of design classes.

 Every class describes the elements of problem domain and that focus on features of
the problem which are user visible.

DESIGN CONCEPTS

Overview

A software design creates meaningful engineering representation (or model) of some

software product that is to be built. Designers must strive to acquire a repertoire of alternative
design information and learn to choose the elements that best match the analysis model. A
design model can be traced to the customer's requirements and can be assessed for quality
against predefined criteria. During the design process the software requirements model (data,
function, behavior) is transformed into design models that describe the details of the data
structures, system architecture, interfaces, and components necessary to implement the
 3.10

system. Each design product is reviewed for quality (i.e. identify and correct errors,
inconsistencies, or omissions, whether better alternatives exist, and whether the design model
can be implemented within the project constraints) before moving to the next phase of
software development.

Software Design

 Encompasses the set of principles, concepts, and practices that lead to the development of
a high quality system or product
 Design principles establish and overriding philosophy that guides the designer as the
work is performed
 Design concepts must be understood before the mechanics of design practice are applied
 Goal of design engineering is to produce a model or representation that is bug free
(firmness), suitable for its intended uses (commodity), and pleasurable to use (delight)
 Software design practices change continuously as new methods, better analysis, and
broader understanding evolve

Software Engineering Design

 Data/Class design - created by transforming the analysis model class-based elements

(class diagrams, analysis packages, CRC models, collaboration diagrams) into classes and
data structures required to implement the software
 Architectural design - defines the relationships among the major structural elements of the
software, it is derived from the class-based elements and flow-oriented elements (data
flow diagrams, control flow diagrams, processing narratives) of the analysis model
 Interface design - describes how the software elements, hardware elements, and end-users
communicate with one another, it is derived from the analysis model scenario-based
elements (use-case text, use-case diagrams, activity diagrams, swim lane diagrams), flow-
oriented elements, and behavioral elements (state diagrams, sequence diagrams)
 Component-level design - created by transforming the structural elements defined by the
software architecture into a procedural description of the software components using
information obtained from the analysis model class-based elements, flow-oriented
elements, and behavioral elements

Software Quality Attributes

A good design must

 implement all explicit requirements from the analysis model and accommodate all
implicit requirements desired by the user
 be readable and understandable guide for those who generate code, test components, or
support the system
 provide a complete picture (data, function, behavior) if the software from an
implementation perspective

Design Quality Guidelines

A design should
 exhibit an architecture that
 3.11

o has been created using recognizable architectural styles or patterns

o is composed of components that exhibit good design characteristics
o can be implemented in an evolutionary manner
 be modular
 contain distinct representations of data, architecture, interfaces, and components
(modules)
 lead to data structures that are appropriate for the objects to be implemented and be drawn
from recognizable design patterns
 lead to components that exhibit independent functional characteristics
 lead to interfaces that reduce the complexity of connections between modules and with
the external environment
 be derived using a repeatable method that is driven by information obtained during
software requirements analysis
 be represented using a notation that effectively communicates its meaning

FURPS Quality Factors

 Functionality – feature set and program capabilities
 Usability – human factors (aesthetics, consistency, documentation)
 Reliability – frequency and severity opf failure
 Performance – processing speed, response time, throughput, efficiency
 Supportability – maintainability (extensibility, adaptability, serviceability), testability,
compatibility, configurability

Generic Design Task Set

1. Examine information domain model and design appropriate data structures for data
objects and their attributes
2. Select an architectural pattern appropriate to the software based on the analysis model
3. Partition the analysis model into design subsystems and allocate these subsystems within
the architecture
o Be certain each subsystem is functionally cohesive
o Design subsystem interfaces
o Allocate analysis class or functions to subsystems
4. Create a set of design classes
o Translate analysis class into design class
o Check each class against design criteria and consider inheritance issues
o Define methods and messages for each design class
o Evaluate and select design patterns for each design class or subsystem after
considering alternatives
o Revise design classes and revise as needed
5. Design any interface required with external systems or devices
6. Design user interface
o Review task analyses
o Specify action sequences based on user scenarios
o Define interface objects and control mechanisms
o Review interface design and revise as needed
7. Conduct component level design
o Specify algorithms at low level of detail
o Refine interface of each component
o Define component level data structures
 3.12

o Review components and correct all errors uncovered

8. Develop deployment model

Important Design Questions

 What criteria can be used to partition software into individual components?

 How is function or data structure detail separated from conceptual representation of the
software?
 What uniform criteria define the technical quality of a software design?

Design Concepts

 Abstraction – allows designers to focus on solving a problem without being concerned

about irrelevant lower level details (procedural abstraction - named sequence of events
and data abstraction – named collection of data objects)
 Software Architecture – overall structure of the software components and the ways in
which that structure provides conceptual integrity for a system
o Structural models – architecture as organized collection of components
o Framework models – attempt to identify repeatable architectural patterns
o Dynamic models – indicate how program structure changes as a function of external
events
o Process models – focus on the design of the business or technical process that system
must accommodate
o Functional models – used to represent system functional hierarchy
 Design Patterns – description of a design structure that solves a particular design problem
within a specific context and its impact when applied
 Separation of concerns – any complex problem is solvable by subdividing it into pieces
that can be solved independently
 Modularity - the degree to which software can be understood by examining its
components independently of one another
 Information Hiding – information (data and procedure) contained within a module is
inaccessible to modules that have no need for such information
 Functional Independence – achieved by developing modules with single-minded purpose
and an aversion to excessive interaction with other models
o Cohesion - qualitative indication of the degree to which a module focuses on just one
thing
o Coupling - qualitative indication of the degree to which a module is connected to
other modules and to the outside world
 Refinement – process of elaboration where the designer provides successively more detail
for each design component
 Aspects – a representation of a cross-cutting concern that must be accommodated as
refinement and modularization occur
 Refactoring – process of changing a software system in such a way internal structure is
improved without altering the external behavior or code design

Design Classes
 3.13

 Refine analysis classes by providing detail needed to implement the classes and
implement a software infrastructure the support the business solution
 Five types of design classes can be developed to support the design architecture
o user interface classes – abstractions needed for human-computer interaction (HCI)
o business domain classes – refinements of earlier analysis classes
o process classes – implement lower level business abstractions
o persistent classes – data stores that persist beyond software execution
o System classes – implement software management and control functions

Design Class Characteristics

 Complete (includes all necessary attributes and methods) and sufficient (contains only
those methods needed to achieve class intent)
 Primitiveness – each class method focuses on providing one service
 High cohesion – small, focused, single-minded classes
 Low coupling – class collaboration kept to minimum

Design Model

 Process dimension – indicates design model evolution as design tasks are executed during
software process
o Architecture elements
o Interface elements
o Component-level elements
o Deployment-level elements
 Abstraction dimension – represents level of detail as each analysis model element is
transformed into a design equivalent and refined
o High level (analysis model elements)
o Low level (design model elements)
 Many UML diagrams used in the design model are refinements of diagrams created in the
analysis model (more implementation specific detail is provided)
 Design patterns may be applied at any point in the design process

Data Design

 High level model depicting user’s view of the data or information

 Design of data structures and operators is essential to creation of high-quality applications
 Translation of data model into database is critical to achieving system business objectives
 Reorganizing databases into a data warehouse enables data mining or knowledge
discovery that can impact success of business itself

Architectural Design

 Provides an overall view of the software product

 Derived from
o Information about the application domain relevant to software
o Relationships and collaborations among specific analysis model elements
o Availability of architectural patterns and styles
 3.14

 Usually depicted as a set of interconnected systems that are often derived from the
analysis packages with in the requirements model

Interface Design

 Interface is a set of operations that describes the externally observable behavior of a class
and provides access to its public operations
 Important elements
o User interface (UI)
o External interfaces to other systems
o Internal interfaces between various design components
 Modeled using UML communication diagrams (called collaboration diagrams in UML
1.x)

Component-Level Design

 Describes the internal detail of each software component

 Defines
o Data structures for all local data objects
o Algorithmic detail for all component processing functions
o Interface that allows access to all component operations
 Modeled using UML component diagrams, UML activity diagrams, pseudocode (PDL),
and sometimes flowcharts

Deployment-Level Design

 Indicates how software functionality and subsystems will be allocated within the physical
computing environment
 Modeled using UML deployment diagrams
 Descriptor form deployment diagrams show the computing environment but does not
indicate configuration details
 Instance form deployment diagrams identifying specific named hardware configurations
are developed during the latter stages of design

COUPLING

 The degree of interdependence between two modules”

 We aim to minimise coupling - to make modules as independent as possible
Low coupling can be achieve by:
o eliminating unnecessary relationships
o reducing the number of necessary relationships
o easeing the ‘tightness’ of necessary relationships

Types of Coupling

1. Data coupling (Most Required)

2. Stamp coupling
3. Control coupling
4. Hybrid coupling
 3.15

5. Common coupling
6. Content coupling (Least Required)

Data Coupling

 Modules communicate by parameters

 Each parameter is an elementary piece of data
 Each parameter is necessary to the communication
 Nothing extra is needed

Data coupling problems

 Too many parameters - makes the interface difficult to understand and possible error
to occur
 Tramp data - data ‘traveling’ across modules before being used

Stamp coupling

 A composite data is passed between modules

 Internal structure contains data not used
 Bundling - grouping of unrelated data into an artificial structure

Control coupling
 A module controls the logic of another module through the parameter
 Controlling module needs to know how the other module works - not flexible!

Hybrid coupling

 A subset of data used as control

 Example: account numbers 00001 to 99999
 If 90000 - 90999, send mail to area code of last 3 digit (000 - 999)

Common coupling

 Use of global data as communication between modules

 Dangers of
o ripple effect
o inflexibility
o difficult to understand the use of data

Content coupling

 A module refers to the inside of another module

 Branch into another module
 Refers to data within another module
 Changes the internal workings of another module
 Mostly by low-level languages
 3.16

COHESION

 “The measure of the strength of functional relatedness of elements within a

module”

 Elements: instructions, groups of instructions, data definition, call of

another module

 We aim for strongly cohesive modules

 Everything in module should be related to one another - focus on the task
 Strong cohesion will reduce relations between modules - minimise coupling

Types of Cohesion

 Functional cohesion (Most Required)

 Sequential cohesion
 Communicational cohesion
 Procedural cohesion
 Temporal cohesion
 Logical cohesion
 Coincidental cohesion (Least Required)

Functional cohesion
 All elements contribute to the execution of one and only one problem-related task
 Focussed - strong, single-minded purpose
 No elements doing unrelated activities
 Examples of functional cohesive modules:
 Compute cosine of angle
 Read transaction record
 Assign seat to airline passenger

Sequential cohesion
 Elements are involved in activities such that output data from one activity becomes
input data to the next
 Usually has good coupling and is easily maintained
 Not so readily reusable because activities that will not in general be useful together

Example of Sequential Cohesion

module format and cross-validate record

use raw record
format raw record
cross-validate fields in raw record
return formatted cross-validated record
end module

Communicational Cohesion
 Elements contribute to activities that use the same input or output data
 Not flexible, for example, if we need to focus on some activities and not the others
 Possible links that cause activities to affect each other
 3.17

 Better to split to functional cohesive ones

Example of Communicational Cohesion

module determine customer details

use customer account no
find customer name
find customer loan balance
return customer name, loan balance
end module

Procedural cohesion

 Elements are related only by sequence, otherwise the activities are unrelated
 Similar to sequential cohesion, except for the fact that elements are unrelated
 Commonly found at the top of hierarchy, such as the main program module
Example of Procedural Cohesion
module write read and edit something
use out record
write out record
read in record
pad numeric fields with zeros
return in record
end module

Temporal cohesion

 Elements are involved in activities that are related in time

 Commonly found in initialisation and termination modules
 Elements are basically unrelated, so the module will be difficult to reuse
 Good practice is to initialise as late as possible and terminate as early as possible

Example of Temporal Cohesion

module initialise
set counter to 0
open student file
clear error message variable
initialise array
end module

Logical cohesion
 Elements contribute to activities of the same general category (type)
 For example, a report module, display module or I/O module
 Usually have control coupling, since one of the activities will be selected
Example of Logical Cohesion
module display record
use record-type, record
if record-type is student then
 3.18

display student record

else if record-type
type is staff then
display staff record
end module

Coincidental cohesion

 Elements contribute to activities with no meaningful

meaningful relationship to one another
 Similar to logical cohesion, except the activities may not even be the same type
 Mixture of activities - like ‘rojak’!
 Difficult to understand and maintain, with strong possibilities of causing ‘side effects’
every time the module is modified
Example of Coincidental Cohesion
module miscellaneous functions
use customer record
display customer record
calculate total sales
read transaction record
return transaction record
end module

Determining Module Cohesion

Other Design Factors to Consider

 Factoring: reduce module size, clarifying system,minimise duplication of code,

separating work from management, creating useful modules, simplifying

 System Shape (Structure)

 3.19

 Redundancy
 Fan-in/Fan-out
 Restrictivity/Generality

FUNCTIONAL INDEPENDENCE

A module having high cohesion and low coupling is said to be functionally independent of
other modules. By the term functional independence, we mean that a cohesive module
performs a single task or function. A functionally independent module has minimal
interaction with other modules.

Need for functional independence

Functional independence is a key to any good design due to the following reasons:

• Error isolation: Functional independence reduces error propagation. The reason behind
this is that if a module is functionally independent, its degree of interaction with the other
modules is less. Therefore, any error existing in a module would not directly effect the other
modules.

• Scope of reuse: Reuse of a module becomes possible. Because each module does some
well-defined and precise function, and the interaction of the module with the other modules is
simple and minimal. Therefore, a cohesive module can be easily taken out and reused in a
different program.

• Understandability: Complexity of the design is reduced, because different modules can be

understood in isolation as modules are more or less independent of each other.

DESIGN PATTERN - OVERVIEW

Design patterns represent the best practices used by experienced object-oriented software
developers. Design patterns are solutions to general problems that software developers faced
during software development. These solutions were obtained by trial and error by numerous
software developers over quite a substantial period of time.

What is Gang of Four (GOF)?

In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides
published a book titled Design Patterns - Elements of Reusable Object-Oriented Software
which initiated the concept of Design Pattern in Software development.

These authors are collectively known as Gang of Four (GOF). According to these authors
design patterns are primarily based on the following principles of object orientated design.

 Program to an interface not an implementation

 Favor object composition over inheritance

Usage of Design Pattern

Design Patterns have two main usages in software development.

 3.20

Common platform for developers

Design patterns provide a standard terminology and are specific to particular scenario. For
example, a singleton design pattern signifies use of single object so all developers familiar
with single design pattern will make use of single object and they can tell each other that
program is following a singleton pattern.

Best Practices

Design patterns have been evolved over a long period of time and they provide best solutions
to certain problems faced during software development. Learning these patterns helps
unexperienced developers to learn software design in an easy and faster way.

Types of Design Patterns

As per the design pattern reference book Design Patterns - Elements of Reusable Object-
Oriented Software , there are 23 design patterns which can be classified in three categories:
Creational, Structural and Behavioral patterns. We'll also discuss another category of design
pattern: J2EE design patterns.

S.N. Pattern & Description

Creational Patterns
These design patterns provide a way to create objects while hiding the creation logic,
1
rather than instantiating objects directly using new operator. This gives program more
flexibility in deciding which objects need to be created for a given use case.
Structural Patterns
These design patterns concern class and object composition. Concept of inheritance is
2
used to compose interfaces and define ways to compose objects to obtain new
functionalities.
Behavioral Patterns
3
These design patterns are specifically concerned with communication between objects.
J2EE Patterns
4 These design patterns are specifically concerned with the presentation tier. These
patterns are identified by Sun Java Center.

DESIGN PATTERNS - MVC PATTERN

MVC Pattern stands for Model-View-Controller Pattern. This pattern is used to separate
application's concerns.

 Model - Model represents an object or JAVA POJO carrying data. It can also have
logic to update controller if its data changes.
 View - View represents the visualization of the data that model contains.
 3.21

 Controller - Controller acts on both model and view. It controls the data flow into
model object and updates the view whenever data changes. It keeps view and model
separate.

Implementation

We are going to create a Student object acting as a [Link] will be a view class
which can print student details on console and StudentController is the controller class
responsible to store data in Student object and update view StudentView accordingly.

MVCPatternDemo, our demo class, will use StudentController to demonstrate use of MVC
pattern.

Step 1 - Create Model.

[Link]

public class Student {

private String rollNo;
private String name;
public String getRollNo() {
return rollNo;
}
public void setRollNo(String rollNo) {
[Link] = rollNo;
}
public String getName() {
return name;
 3.22

}
public void setName(String name) {
[Link] = name;
}
}

Step 2 - Create View.

[Link]

public class StudentView {

public void printStudentDetails(String studentName, String studentRollNo){
[Link]("Student: ");
[Link]("Name: " + studentName);
[Link]("Roll No: " + studentRollNo);
}
}

Step 3 - Create Controller.

[Link]

public class StudentController {

private Student model;
private StudentView view;
public StudentController(Student model, StudentView view){
[Link] = model;
[Link] = view;
}
public void setStudentName(String name){
[Link](name);
}
public String getStudentName(){
return [Link]();
}
public void setStudentRollNo(String rollNo){
[Link](rollNo);
}
public String getStudentRollNo(){
return [Link]();
}
public void updateView(){
[Link]([Link](), [Link]());
}
}

Step 4 - Use the StudentController methods to demonstrate MVC design pattern usage.

[Link]
 3.23

public class MVCPatternDemo {

public static void main(String[] args) {
//fetch student record based on his roll no from the database
Student model = retriveStudentFromDatabase();
//Create a view : to write student details on console
StudentView view = new StudentView();

StudentController controller = new StudentController(model, view);

[Link]();
//update model data
[Link]("John");
[Link]();
}
private static Student retriveStudentFromDatabase(){
Student student = new Student();
[Link]("Robert");
[Link]("10");
return student;
}
}

Step 5 - Verify the output.

Student:
Name: Robert
Roll No: 10
Student:
Name: John
Roll No: 10

PUBLISH–SUBSCRIBE
In software architecture, publish–subscribe is a messaging pattern where senders
of messages, called publishers, do not program the messages to be sent directly to specific
receivers, called subscribers, but instead categorize published messages into classes without
knowledge of which subscribers, if any, there may be. Similarly, subscribers express interest
in one or more classes and only receive messages that are of interest, without knowledge of
which publishers, if any, there are.
Publish–subscribe is a sibling of the message queue paradigm, and is typically one part of a
larger message-oriented middleware system. Most messaging systems support both the
pub/sub and message queue models in their API, e.g. Java Message Service (JMS).
This pattern provides greater network scalability and a more dynamic network topology, with
a resulting decreased flexibility to modify the publisher and the structure of the published
data.

The three variations of the Publish/Subscribe pattern you can use to create a mechanism that
sends messages to all interested subscribers are List-Based Publish/Subscribe, Broadcast-
Based Publish/Subscribe, and Content-Based Publish/Subscribe.
 3.24

List-Based Publish/Subscribe
A List-Based Publish/Subscribe pattern advises you to identify a subject and to
maintain a list of subscribers for that subject. When events occur, you have the subject notify
each subscriber on the subscription list. A classic way to implement this design is described
in the Observer [Gamma95] pattern. When you use this pattern, you identify two classes:
subjects and observers. Assuming you use a push model update, you add three methods to the
subject: Attach(),Detach(), and Notify().You add one method to the observer—Update().
To use an observer, all interested observers register with the subject by using
the Attach()method. As changes occur to the subject, the subject then calls each registered
observer by using the Notify()method. An observer works fine if you have created instances
of objects that reify all your observers and subjects. An observer is especially well suited to
situations where you have one-to-many relationships between your subjects and your
observers. However, in the context of integration, you often have many observers that are
linked to many subjects, which complicates the basic Observer pattern. One way to
implement this many-to-many relationship is to create many subjects and to have each
subject contain a list of observers.
If you use this object structure to implement Publish/Subscribe, you must write these
relationships to persistent storage between process executions. To do so within a relational
database, you must add an associative table to resolve the many-to-many dependencies
between subject and observer. After you write this information to persistent storage in a set of
tables, you can directly query the database for the list of subscribers for a topic.
Maintaining lists of published topics (subjects) and subscribers (observers) and then
notifying each one individually as events occur is the essence of List-Based
Publish/Subscribe implementations. A very different means of achieving the same result is
a Broadcast-Based Publish/Subscribeimplementation.

Broadcast-Based Publish/Subscribe
When you use a Broadcast-Based Publish/Subscribe approach [Tannebaum01,
Oki93], an event publisher creates a message and broadcasts it to the local area network
(LAN). A service on each listening node inspects the subject line. If the listening node
matches the subject line to a subject that it subscribes to, the listening node processes the
message. If the subject does not match, the listening node ignores the message.
Subject lines are hierarchical and may contain multiple fields that are separated by
periods. Listening nodes that are interested in a particular subject can subscribe to these fields
by using wildcards, if required.
Although this Broadcast-Based Publish/Subscribe implementation is an effective
method for decoupling producers from consumers, it is sometimes useful to identify
particular topic subscribers. To identify topic subscribers, a coordinating process sends a
message that asks listening nodes to reply if they subscribe to a particular topic. Responses
are then returned by each listening node to the provider to identify the subscribers.
Because all messages are sent to all listening nodes, and because each node is
responsible for filtering unwanted messages, some authors refer to this as a publish/subscribe
channel with reactive filtering [Hohpe04].

Content-Based Publish/Subscribe
Both Broadcast-Based Publish/Subscribe implementations and List-Based
Publish/Subscribe implementations can be broadly categorized as topic-based because they
both use predefined subjects as many-to-many channels. Publish/Subscribe implementations
have recently evolved to include a new form—Content-Based Publish/Subscribe. The
difference between topic-based and content-based approaches is as follows:
 3.25

In a topic-based system, processes exchange information through a set of predefined

subjects (topics) which represent many-to-many distinct (and fixed) logical channels.
Content-based systems are more flexible as subscriptions are related to specific information
content and, therefore, each combination of information items can actually be seen as a single
dynamic logical channel. This exponential enlargement of potential logical channels has
changed the way to implement a pub/sub system. [Baldoni03]
The practical implication of this approach is that messages are intelligently routed to
their final destination based on the content of the message. This approach overcomes the
limitation of a broadcast-based system, where distribution is coupled to a multicast tree that is
based on Transmission Control Protocol (TCP). It also gives the integration architect a great
deal of flexibility when deciding on content-based routing logic.

Applying Publish/Subscribe
Figure 1 shows an integration solution that consists of four applications. The sender
(also called a publisher) uses a topic-based approach to publish messages to topic A and to
topic B. Three receivers (also called subscribers) subscribe to these topics; one receiver
subscribes to topic A, one receiver subscribes to topic B, and one receiver subscribes to both
topic A and to topic B. The arrows show messages flowing from the publisher to each
subscriber according to these subscriptions.

Figure 1. Subscription to topics controls the message types that reach each subscriber

Implementing Publish/Subscribe usually affects the messages, the integrated applications,

and the communication infrastructure.
First, you must identify the topics or the content of interest to the receiving
applications. This translates into partitioning the set of message types into different subsets.
For example, consider the types of messages that are sent by a trading system. Some trading
applications track buy transactions, some track sell transactions, and other applications track
both types of transaction. Separating the message by creating a buy topic and a sell topic
partitions the trading system messages into subsets aimed at these applications.
Next, you must add information to the messages that indicates the topic or that
identifies specific content information. Sometimes you can store the topic-related information
in an unused message field. Alternatively, you may be able to add a new field for the topic.
For example, you may be able to insert a new element in a SOAP header. If you can neither
use an existing field nor add a new one, you must find other ways to encode the topic into the
message, or you must use a content-based approach instead.
You must then extend the communication infrastructure so that it delivers messages
according to each subscriber's subscription. The approach that you use depends on the
topology of the integration solution. For example, consider the three common topologies. For
bus integration, you can implement the subscription mechanism in the bus interface. For
 3.26

broker integration, you can implement the mechanism through subscription lists to the broker.
For point-to-point integration, you can implement the mechanism through subscription lists in
the publisher.
Finally, you must modify the integrated applications. The publisher must add the
topic-related information to each message that it publishes. For example, if the topic is
encoded as a header element, the publisher must insert the topic-related information into the
appropriate element. Likewise, the subscriber must specify the topics of interest.
Subscriptions can be either fixed or dynamic. With fixed subscriptions, the integration
architect sets the topics that an application subscribes to. Applications have no control over
their subscriptions. Usually, the subscriptions are specified when each application is added to
the integration solution. Figure 2 shows a fixed subscription to Topic A.

Figure 2. Publish/Subscribe with fixed subscription

In contrast, dynamic subscriptions enable applications to control their own

subscriptions through a set of control messages. Applications can remove existing
subscriptions by sending messages to the communication infrastructure that remove the
application from the subscription list. Applications can add new subscriptions by sending
messages to the communication infrastructure that add the application to a subscription list.
Most communication infrastructures that have Publish/Subscribe capabilities provide this
feature. However, supporting dynamic subscriptions is not a requirement.

Figure 3. Publish/Subscribe with dynamic subscriptions

 3.27

Figure 3 shows how dynamic subscriptions function. The top part of Figure 3 shows the
initial subscription to topic A. The application then sends a message that removes it from the
subscription list for topic A. The application then sends two messages that subscribe the
application to topic B and topic C. The bottom part of Figure 3 shows the final subscription
after these control messages are sent.

Related Decisions
After you decide to use Publish/Subscribe, you must make the following decisions:

 Initial subscription. You must decide how subscribers communicate their

subscriptions to the communication infrastructure when they are first added to the
solution.
 Wildcard subscriptions. You must decide if your publish/subscribe mechanism
needs to support wildcard subscriptions. Wildcard subscriptions enable subscribers to
subscribe to multiple topics through one subscription.
 Static or dynamic subscriptions. You must decide if the applications in your
integration solution need to change their subscriptions dynamically.
 Topic discovery. You must decide how subscribers discover the available topics if
the solution supports dynamic subscriptions.

Responsibilities and Collaborations

Table 1 summarizes the responsibilities and collaborations of the parties involved
in Publish/Subscribe.

Table 1: Responsibilities and Collaborations Among Publish/Subscribe Components

Components Responsibilities Collaborations

–The publisher publishes

Communication –Maintains the subscribers' messages.
infrastructure subscriptions. –The subscriber subscribes to
topics and receives messages.
–Inspects the topic-related
information or the content
information that is included in each
published message.
–Transports the message to the
subscribed applications.

Publisher –Inserts topic-related information or –The communication

content information in each message. infrastructure transports
–Publishes the message to the messages to subscribers.
communication infrastructure.

Subscriber –Subscribes to one or more topics or –The communication

message content types. infrastructure transports
–Consumes messages published to the published messages from the
subscribed topics. publisher.
 3.28

DESIGN PATTERNS - ADAPTER PATTERN

Adapter pattern works as a bridge between two incompatible interfaces. This type of
design pattern comes under structural pattern as this pattern combines the capability of two
independent interfaces.

This pattern involves a single class which is responsible to join functionalities of

independent or incompatible interfaces. A real life example could be a case of card reader
which acts as an adapter between memory card and a laptop. You plugin the memory card
into card reader and card reader into the laptop so that memory card can be read via laptop.

We are demonstrating use of Adapter pattern via following example in which an

audio player device can play mp3 files only and wants to use an advanced audio player
capable of playing vlc and mp4 files.

Implementation

We have a MediaPlayer interface and a concrete class AudioPlayer implementing the

MediaPlayer interface. AudioPlayer can play mp3 format audio files by default.
We are having another interface AdvancedMediaPlayer and concrete classes
implementing the AdvancedMediaPlayer interface. These classes can play vlc and mp4
format files.
We want to make AudioPlayer to play other formats as well. To attain this, we have
created an adapter class MediaAdapter which implements the MediaPlayer interface and uses
AdvancedMediaPlayer objects to play the required format.
AudioPlayer uses the adapter class MediaAdapter passing it the desired audio type
without knowing the actual class which can play the desired format. AdapterPatternDemo,
our demo class will use AudioPlayer class to play various formats.
 3.29

Step 1 - Create interfaces for Media Player and Advanced Media Player.

[Link]

public interface MediaPlayer {

public void play(String audioType, String fileName);
}

[Link]

public interface AdvancedMediaPlayer {

public void playVlc(String fileName);
public void playMp4(String fileName);
}

Step 2 - Create concrete classes implementing the AdvancedMediaPlayer interface.

[Link]

public class VlcPlayer implements AdvancedMediaPlayer{

@Override
public void playVlc(String fileName) {
[Link]("Playing vlc file. Name: "+ fileName);
}
@Override
public void playMp4(String fileName) {
//do nothing
}
}

[Link]

public class Mp4Player implements AdvancedMediaPlayer{

@Override
public void playVlc(String fileName) {
//do nothing
}
@Override
public void playMp4(String fileName) {
[Link]("Playing mp4 file. Name: "+ fileName);
}
}

Step 3 - Create adapter class implementing the MediaPlayer interface.

[Link]
 3.30

public class MediaAdapter implements MediaPlayer {

AdvancedMediaPlayer advancedMusicPlayer;
public MediaAdapter(String audioType){
if([Link]("vlc") ){
advancedMusicPlayer = new VlcPlayer();
}else if ([Link]("mp4")){
advancedMusicPlayer = new Mp4Player();
}
}

@Override
public void play(String audioType, String fileName) {
if([Link]("vlc")){
[Link](fileName);
}
else if([Link]("mp4")){
advancedMusicPlayer.playMp4(fileName);
}
}
}

Step 4 - Create concrete class implementing the MediaPlayer interface.

[Link]

public class AudioPlayer implements MediaPlayer {

MediaAdapter mediaAdapter;
@Override
public void play(String audioType, String fileName) {
//inbuilt support to play mp3 music files
if([Link]("mp3")){
[Link]("Playing mp3 file. Name: " + fileName);
}
//mediaAdapter is providing support to play other file formats
else if([Link]("vlc") || [Link]("mp4")){
mediaAdapter = new MediaAdapter(audioType);
[Link](audioType, fileName);
}
else{
[Link]("Invalid media. " + audioType + " format not supported");
}
}
}

Step 5 - Use the AudioPlayer to play different types of audio formats.

[Link]

public class AdapterPatternDemo {

public static void main(String[] args) {
 3.31

AudioPlayer audioPlayer = new AudioPlayer();

[Link]("mp3", "beyond the horizon.mp3");
[Link]("mp4", "alone.mp4");
[Link]("vlc", "far far [Link]");
[Link]("avi", "mind [Link]");
}
}

Step 6 - Verify the output.

Playing mp3 file. Name: beyond the horizon.mp3

Playing mp4 file. Name: alone.mp4
Playing vlc file. Name: far far [Link]
Invalid media. avi format not supported

DESIGN PATTERNS - STRATEGY PATTERN

In Strategy pattern, a class behavior or its algorithm can be changed at run time. This
type of design pattern comes under behavior pattern.
In Strategy pattern, we create objects which represent various strategies and a context
object whose behavior varies as per its strategy object. The strategy object changes the
executing algorithm of the context object.

Implementation

We are going to create a Strategy interface defining an action and concrete strategy
classes implementing the Strategy interface. Context is a class which uses a Strategy.
StrategyPatternDemo, our demo class, will use Context and strategy objects to
demonstrate change in Context behaviour based on strategy it deploys or uses.

Step 1 - Create an interface.

[Link]

public interface Strategy {

 3.32

public int doOperation(int num1, int num2);

}

Step 2 - Create concrete classes implementing the same interface.

[Link]

public class OperationAdd implements Strategy{

@Override
public int doOperation(int num1, int num2) {
return num1 + num2;
}
}

[Link]

public class OperationSubstract implements Strategy{

@Override
public int doOperation(int num1, int num2) {
return num1 - num2;
}
}

[Link]

public class OperationMultiply implements Strategy{

@Override
public int doOperation(int num1, int num2) {
return num1 * num2;
}
}

Step 3 - Create Context Class.

[Link]

public class Context {

private Strategy strategy;
public Context(Strategy strategy){
[Link] = strategy;
}
public int executeStrategy(int num1, int num2){
return [Link](num1, num2);
}
}

Step 4 - Use the Context to see change in behaviour when it changes its Strategy.

[Link]
 3.33

public class StrategyPatternDemo {

public static void main(String[] args) {
Context context = new Context(new OperationAdd());
[Link]("10 + 5 = " + [Link](10, 5));

context = new Context(new OperationSubstract());

[Link]("10 - 5 = " + [Link](10, 5));
context = new Context(new OperationMultiply());
[Link]("10 * 5 = " + [Link](10, 5));
}
}

Step 5 - Verify the output.

10 + 5 = 15
10 - 5 = 5
10 * 5 = 50

DESIGN PATTERNS - COMMAND PATTERN

Command pattern is a data driven design pattern and falls under behavioral pattern
category. A request is wrapped under an object as command and passed to invoker object.
Invoker object looks for the appropriate object which can handle this command and passes
the command to the corresponding object which executes the command.

Implementation

We have created an interface Order which is acting as a command. We have created a

Stock class which acts as a request. We have concrete command classes BuyStock and
SellStock implementing Order interface which will do actual command processing. A class
Broker is created which acts as an invoker object. It can take and place orders.
Broker object uses command pattern to identify which object will execute which
command based on the type of command. CommandPatternDemo, our demo class, will use
Broker class to demonstrate command pattern.
 3.34

Step 1 - Create a command interface.

[Link]

public interface Order {

void execute();
}

Step 2 - Create a request class.

[Link]

public class Stock {

private String name = "ABC";
private int quantity = 10;
public void buy(){
[Link]("Stock [ Name: "+name+",
Quantity: " + quantity +" ] bought");
}
public void sell(){
[Link]("Stock [ Name: "+name+",
Quantity: " + quantity +" ] sold");
}
}

Step 3 - Create concrete classes implementing the Order interface.

[Link]

public class BuyStock implements Order {

private Stock abcStock;
public BuyStock(Stock abcStock){
[Link] = abcStock;
}
public void execute() {
[Link]();
}
}

[Link]

public class SellStock implements Order {

private Stock abcStock;
public SellStock(Stock abcStock){
[Link] = abcStock;
}
public void execute() {
[Link]();
}
}
 3.35

Step 4 - Create command invoker class.

[Link]

import [Link];
import [Link];
public class Broker {
private List<Order> orderList = new ArrayList<Order>();
public void takeOrder(Order order){
[Link](order);
}
public void placeOrders(){
for (Order order : orderList) {
[Link]();
}
[Link]();
}
}

Step 5 - Use the Broker class to take and execute commands.

[Link]

public class CommandPatternDemo {

public static void main(String[] args) {
Stock abcStock = new Stock();
BuyStock buyStockOrder = new BuyStock(abcStock);
SellStock sellStockOrder = new SellStock(abcStock);
Broker broker = new Broker();
[Link](buyStockOrder);
[Link](sellStockOrder);
[Link]();
}
}

Step 6 - Verify the output.

Stock [ Name: ABC, Quantity: 10 ] bought

Stock [ Name: ABC, Quantity: 10 ] sold

DESIGN PATTERNS - OBSERVER PATTERN

Observer pattern is used when there is one-to-many relationship between objects such
as if one object is modified, its dependent objects are to be notified automatically. Observer
pattern falls under behavioral pattern category.

Implementation
 3.36

Observer pattern uses three actor classes. Subject, Observer and Client. Subject is an
object having methods to attach and detach observers to a client object. We have created an
abstract class Observer and a concrete class Subject that is extending class Observer.
ObserverPatternDemo, our demo class, will use Subject and concrete class object to
show observer pattern in action.

Step 1 - Create Subject class.

[Link]

import [Link];
import [Link];
public class Subject {
private List<Observer> observers = new ArrayList<Observer>();
private int state;
public int getState() {
return state;
}
public void setState(int state) {
[Link] = state;
notifyAllObservers();
}
public void attach(Observer observer){
[Link](observer);
}
public void notifyAllObservers(){
for (Observer observer : observers) {
[Link]();
}
}
}

Step 2 - Create Observer class.

 3.37

[Link]

public abstract class Observer {

protected Subject subject;
public abstract void update();
}

Step 3 - Create concrete observer classes

[Link]

public class BinaryObserver extends Observer{

public BinaryObserver(Subject subject){
[Link] = subject;
[Link](this);
}
@Override
public void update() {
[Link]( "Binary String: " + [Link]( [Link]() ) );
}
}

[Link]

public class OctalObserver extends Observer{

public OctalObserver(Subject subject){
[Link] = subject;
[Link](this);
}
@Override
public void update() {
[Link]( "Octal String: " + [Link]( [Link]() ) );
}
}

[Link]

public class HexaObserver extends Observer{

public HexaObserver(Subject subject){
[Link] = subject;
[Link](this);
}
@Override
public void update() {
[Link]( "Hex String: " + [Link]( [Link]()
).toUpperCase() );
}
}

Step 4 - Use Subject and concrete observer objects.

 3.38

[Link]

public class ObserverPatternDemo {

public static void main(String[] args) {
Subject subject = new Subject();
new HexaObserver(subject);
new OctalObserver(subject);
new BinaryObserver(subject);
[Link]("First state change: 15");
[Link](15);
[Link]("Second state change: 10");
[Link](10);
}
}

Step 5 - Verify the output.

First state change: 15

Hex String: F
Octal String: 17
Binary String: 1111
Second state change: 10
Hex String: A
Octal String: 12
Binary String: 1010

DESIGN PATTERNS - PROXY PATTERN

In proxy pattern, a class represents functionality of another class. This type of design
pattern comes under structural pattern.
In proxy pattern, we create object having original object to interface its functionality
to outer world.

Implementation
We are going to create an Image interface and concrete classes implementing the
Image interface. ProxyImage is a a proxy class to reduce memory footprint of RealImage
object loading.
ProxyPatternDemo, our demo class, will use ProxyImage to get an Image object to
load and display as it needs.
 3.39

Step 1 - Create an interface.

[Link]

public interface Image {

void display();
}

Step 2 - Create concrete classes implementing the same interface.

[Link]

public class RealImage implements Image {

private String fileName;
public RealImage(String fileName){
[Link] = fileName;
loadFromDisk(fileName);
}
@Override
public void display() {
[Link]("Displaying " + fileName);
}
private void loadFromDisk(String fileName){
[Link]("Loading " + fileName);
}
}

[Link]

public class ProxyImage implements Image{

private RealImage realImage;
private String fileName;
public ProxyImage(String fileName){
[Link] = fileName;
}
@Override
public void display() {
if(realImage == null){
realImage = new RealImage(fileName);
}
[Link]();
}
}

Step 3 - Use the ProxyImage to get object of RealImage class when required.

ProxyPatter [Link]
 3.40

public class ProxyPatternDemo {

public static void main(String[] args) {
Image image = new ProxyImage("test_10mb.jpg");
//image will be loaded from disk
[Link]();
[Link]("");
//image will not be loaded from disk
[Link]();
}
}

Step 4 - Verify the output.

Loading test_10mb.jpg
Displaying test_10mb.jpg
Displaying test_10mb.jpg

DESIGN PATTERNS - FACADE PATTERN

Facade pattern hides the complexities of the system and provides an interface to the
client using which the client can access the system. This type of design pattern comes under
structural pattern as this pattern adds an interface to existing system to hide its complexities.
This pattern involves a single class which provides simplified methods required by
client and delegates calls to methods of existing system classes.

Implementation

We are going to create a Shape interface and concrete classes implementing the Shape
interface. A facade class ShapeMaker is defined as a next step.
ShapeMaker class uses the concrete classes to delegate user calls to these classes.
FacadePatternDemo, our demo class, will use ShapeMaker class to show the results.

Step 1 - Create an interface.

[Link]
 3.41

public interface Shape {

void draw();
}

Step 2 - Create concrete classes implementing the same interface.

[Link]

public class Rectangle implements Shape {

@Override
public void draw() {
[Link]("Rectangle::draw()");
}
}

[Link]

public class Square implements Shape {

@Override
public void draw() {
[Link]("Square::draw()");
}
}

[Link]

public class Circle implements Shape {

@Override
public void draw() {
[Link]("Circle::draw()");
}
}

Step 3 - Create a facade class.

[Link]

public class ShapeMaker {

private Shape circle;
private Shape rectangle;
private Shape square;
public ShapeMaker() {
circle = new Circle();
rectangle = new Rectangle();
square = new Square();
}
public void drawCircle(){
[Link]();
}
public void drawRectangle(){
 3.42

[Link]();
}
public void drawSquare(){
[Link]();
}
}

Step 4 - Use the facade to draw various types of shapes.

[Link]

public class FacadePatternDemo {

public static void main(String[] args) {
ShapeMaker shapeMaker = new ShapeMaker();
[Link]();
[Link]();
[Link]();
}
}

Step 5 - Verify the output.

Circle::draw()
Rectangle::draw()
Square::draw()

ARCHITECTURAL STYLE

The architectural style, also called as architectural pattern, is a set of principles which
shapes an application. It defines an abstract framework for a family of system in terms of the
pattern of structural organization.

The architectural style is responsible to −

 Provide a lexicon of components and connectors with rules on how they can be
combined.
 Improve partitioning and allow the reuse of design by giving solutions to frequently
occurring problems.
 Describe a particular way to configure a collection of components (a module with
well-defined interfaces, reusable, and replaceable) and connectors (communication
link between modules).

The software that is built for computer-based systems exhibit one of many architectural
styles. Each style describes a system category that encompasses −

 A set of component types which perform a required function by the system.

 A set of connectors (subroutine call, remote procedure call, data stream, and socket)
that enable communication, coordination, and cooperation among different
components.
 3.43

 Semantic constraints which define how components can be integrated to form the
system.
 A topological layout of the components indicating their runtime interrelationships.

Architectural Design

Architectural design is a process for identifying the sub-systems making up a system and
the framework for sub-system control and communication. The output of this design process
is a description of the software architecture. Architectural design is an early stage of the
system design process. It represents the link between specification and design processes and
is often carried out in parallel with some specification activities. It involves identifying major
system components and their communications.

Software architectures can be designed at two levels of abstraction:

 Architecture in the small is concerned with the architecture of individual programs.

At this level, we are concerned with the way that an individual program is
decomposed into components.
 Architecture in the large is concerned with the architecture of complex enterprise
systems that include other systems, programs, and program components. These
enterprise systems are distributed over different computers, which may be owned and
managed by different companies.

Three advantages of explicitly designing and documenting software architecture:

 Stakeholder communication: Architecture may be used as a focus of discussion by

system stakeholders.
 System analysis: Well-documented architecture enables the analysis of whether the
system can meet its non-functional requirements.
 Large-scale reuse: The architecture may be reusable across a range of systems or
entire lines of products.

Software architecture is most often represented using simple, informal block diagrams
showing entities and relationships. Pros: simple, useful for communication with stakeholders,
great for project planning. Cons: lack of semantics, types of relationships between entities,
visible properties of entities in the architecture.

Uses of architectural models:

As a way of facilitating discussion about the system design

A high-level architectural view of a system is useful for communication with system
stakeholders and project planning because it is not cluttered with detail. Stakeholders
can relate to it and understand an abstract view of the system. They can then discuss
the system as a whole without being confused by detail.
As a way of documenting an architecture that has been designed
The aim here is to produce a complete system model that shows the different
components in a system, their interfaces and their connections.
 3.44

Architectural design decisions

Architectural design is a creative process so the process differs depending on the type of
system being developed. However, a number of common decisions span all design processes
and these decisions affect the non-functional characteristics of the system:

 Is there a generic application architecture that can be used?

 How will the system be distributed?
 What architectural styles are appropriate?
 What approach will be used to structure the system?
 How will the system be decomposed into modules?
 What control strategy should be used?
 How will the architectural design be evaluated?
 How should the architecture be documented?

Systems in the same domain often have similar architectures that reflect domain concepts.
Application product lines are built around a core architecture with variants that satisfy
particular customer requirements. The architecture of a system may be designed around one
of more architectural patterns/styles, which capture the essence of an architecture and can
be instantiated in different ways.

The particular architectural style should depend on the non-functional system

requirements:

 Performance: localize critical operations and minimize communications. Use large

rather than fine-grain components.
 Security: use a layered architecture with critical assets in the inner layers.
 Safety: localize safety-critical features in a small number of sub-systems.
 Availability: include redundant components and mechanisms for fault tolerance.
 Maintainability: use fine-grain, replaceable components.

Architectural views

Each architectural model only shows one view or perspective of the system. It might show
how a system is decomposed into modules, how the run-time processes interact or the
different ways in which system components are distributed across a network. For both design
and documentation, you usually need to present multiple views of the software architecture.

4+1 view model of software architecture:

 A logical view, which shows the key abstractions in the system as objects or object
classes.
 A process view, which shows how, at run-time, the system is composed of interacting
processes.
 A development view, which shows how the software is decomposed for
development.
 A physical view, which shows the system hardware and how software components
are distributed across the processors in the system.
 3.45

 Related using use cases or scenarios (+1).

Architectural patterns

Patterns are a means of representing, sharing and reusing knowledge. An architectural pattern
is a stylized description of a good design practice, which has been tried and tested in
different environments. Patterns should include information about when they are and when
the are not useful. Patterns may be represented using tabular and graphical descriptions.

LAYERED ARCHITECTURE

 Used to model the interfacing of sub-systems.

 Organizes the system into a set of layers (or abstract machines) each of which provide
a set of services.
 Supports the incremental development of sub-systems in different layers. When a
layer interface changes, only the adjacent layer is affected.
 However, often artificial to structure systems in this way.

Name Layered architecture

Organizes the system into layers with related functionality associated with
Description each layer. A layer provides services to the layer above it so the lowest-level
layers represent core services that are likely to be used throughout the system.
Used when building new facilities on top of existing systems; when the
When used development is spread across several teams with each team responsibility for a
layer of functionality; when there is a requirement for multi-level security.
Allows replacement of entire layers so long as the interface is maintained.
Advantages Redundant facilities (e.g., authentication) can be provided in each layer to
increase the dependability of the system.
In practice, providing a clean separation between layers is often difficult and a
high-level layer may have to interact directly with lower-level layers rather
Disadvantages than through the layer immediately below it. Performance can be a problem
because of multiple levels of interpretation of a service request as it is
processed at each layer.
 3.46

Repository architecture

 Sub-systems must exchange data. This may be done in two ways:

o Shared data is held in a central database or repository and may be accessed by
all sub-systems;
o Each sub-system maintains its own database and passes data explicitly to other
sub-systems.
 When large amounts of data are to be shared, the repository model of sharing is most
commonly used a this is an efficient data sharing mechanism.

Name Repository
All data in a system is managed in a central repository that is accessible to all
Description system components. Components do not interact directly, only through the
repository.
You should use this pattern when you have a system in which large volumes
of information are generated that has to be stored for a long time. You may
When used
also use it in data-driven systems where the inclusion of data in the repository
triggers an action or tool.
Components can be independent--they do not need to know of the existence of
other components. Changes made by one component can be propagated to all
Advantages
components. All data can be managed consistently (e.g., backups done at the
same time) as it is all in one place.
The repository is a single point of failure so problems in the repository affect
the whole system. May be inefficiencies in organizing all communication
Disadvantages
through the repository. Distributing the repository across several computers
may be difficult.

CLIENT-SERVER ARCHITECTURE

 Distributed system model which shows how data and processing is distributed across
a range of components, but can also be implemented on a single computer.
 Set of stand-alone servers which provide specific services such as printing, data
management, etc.
 Set of clients which call on these services.
 Network which allows clients to access servers.
 3.47

Name Client-server
In a client-server
server architecture, the functionality of the system is organized into
Description services, with each service delivered from a separate server. Clients are users
of these services and access servers to make use of them.
Used when data in a shared database has to be accessed from a range of
When used locations. Because servers can be replicated, may also be used when the load
on a system is variable.
The principal advantage of this model is that servers can be distributed across
Advantages a network. General functionality (e.g., a printing service) can be available to
all clients and does not need to be implemented by all services.
Each service is a single point of failure so susceptible
susceptible to denial of service
attacks or server failure. Performance may be unpredictable because it
Disadvantages
depends on the network as well as the system. May be management problems
if servers are owned by different organizations.

PIPE AND FILTER ARCHITECTURE

 Functional transformations process their inputs to produce outputs.

 May be referred to as a pipe and filter model (as in UNIX shell).
 Variants of this approach are very common. When transformations are sequential, this
is a batch sequential model which is extensively used in data processing systems.
 Not really suitable for interactive systems.
 3.48

Name Pipe and filter

The processing of the data in a system is organized so that each processing
Description component (filter) is discrete and carries out one type of data transformation.
The data flows (as in a pipe) from one component to another for processing.
Commonly used in data processing applications (both batch- and transaction-
When used based) where inputs are processed in separate stages to generate related
outputs.
Easy to understand and supports transformation reuse. Workflow style
matches the structure of many business processes. Evolution by adding
Advantages
transformations is straightforward. Can be implemented as either a sequential
or concurrent system.
The format for data transfer has to be agreed upon between communicating
transformations. Each transformation must parse its input and unparse its
Disadvantages output to the agreed form. This increases system overhead and may mean that
it is impossible to reuse functional transformations that use incompatible data
structures.

Application architectures

Application systems are designed to meet an organizational need. As businesses have much
in common, their application systems also tend to have a common architecture that reflects
the application requirements. A generic application architecture is an architecture for a
type of software system that may be configured and adapted to create a system that meets
specific requirements. application architectures can be used as a:

 Starting point for architectural design.

 Design checklist.
 Way of organizing the work of the development team.
 Means of assessing components for reuse.
 Vocabulary for talking about application types.

Examples of application types:

Data processing applications

Data driven applications that process data in batches without explicit user intervention
during the processing.
Transaction processing applications
Data-centred applications that process user requests and update information in a
system database.
Event processing systems
Applications where system actions depend on interpreting events from the system's
environment.
Language processing systems
Applications where the users' intentions are specified in a formal language that is
processed and interpreted by the system.
 3.49

N-TIER / 3-TIER ARCHITECTURAL STYLE

N-tier and 3-tier are architectural deployment styles that describe the separation of
functionality into segments in much the same way as the layered style, but with each segment
being a tier that can be located on a physically separate computer. They evolved through the
component-oriented approach, generally using platform specific methods for communication
instead of a message-based approach.

N-tier application architecture is characterized by the functional decomposition of

applications, service components, and their distributed deployment, providing improved
scalability, availability, manageability, and resource utilization. Each tier is completely
independent from all other tiers, except for those immediately above and below it. The nth
tier only has to know how to handle a request from the n+1th tier, how to forward that request
on to the n-1th tier (if there is one), and how to handle the results of the request.
Communication between tiers is typically asynchronous in order to support better scalability.

N-tier architectures usually have at least three separate logical parts, each located on a
separate physical server. Each part is responsible for specific functionality. When using a
layered design approach, a layer is deployed on a tier if more than one service or application
is dependent on the functionality exposed by the layer.

An example of the N-tier/3-tier architectural style is a typical financial Web

application where security is important. The business layer must be deployed behind a
firewall, which forces the deployment of the presentation layer on a separate tier in the
perimeter network. Another example is a typical rich client connected application, where the
presentation layer is deployed on client machines and the business layer and data access layer
are deployed on one or more server tiers.

The main benefits of the N-tier/3-tier architectural style are:

 Maintainability. Because each tier is independent of the other tiers, updates or

changes can be carried out without affecting the application as a whole.
 Scalability. Because tiers are based on the deployment of layers, scaling out an
application is reasonably straightforward.
 Flexibility. Because each tier can be managed or scaled independently, flexibility is
increased.
 Availability. Applications can exploit the modular architecture of enabling systems
using easily scalable components, which increases availability.

Consider either the N-tier or the 3-tier architectural style if the processing
requirements of the layers in the application differ such that processing in one layer could
absorb sufficient resources to slow the processing in other layers, or if the security
requirements of the layers in the application differ. For example, the presentation layer
should not store sensitive data, while this may be stored in the business and data layers. The
N-tier or the 3-tier architectural style is also appropriate if you want to be able to share
business logic between applications, and you have sufficient hardware to allocate the required
number of servers to each tier.

Consider using just three tiers if you are developing an intranet application where all
servers are located within the private network; or an Internet application where security
 3.50

requirements do not restrict the deployment of business logic on the public facing Web or
application server. Consider using more than three tiers if security requirements dictate that
business logic cannot be deployed to the perimeter network, or the application makes heavy
use of resources and you want to offload that functionality to another server

SOFTWARE 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. UI provides fundamental platform for human-
computer interaction.
UI can be graphical, text-based, audio-video based, depending upon the underlying
hardware and software combination. UI can be hardware or software or a combination of
both.

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 has been a great tool of interaction with computers until the video display
monitors came into existence. CLI is first choice of many technical users and programmers.
CLI is minimum interface a software can provide to its users.
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. Earlier
CLI were not programmed to handle the user errors effectively.
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.

CLI Elements

A text-based command line interface can have the following elements:

 Command Prompt - It is text-based notifier that is mostly shows the context in

which the user is working. It is generated by the software system.
 3.51

 Cursor - It is a small horizontal line or a vertical bar of the height of line, to represent
position of character while typing. Cursor is mostly found in blinking state. It moves
as the user writes or deletes something.
 Command - A command is an executable instruction. It may have one or more
parameters. Output on command execution is shown inline on the screen. When
output is produced, command prompt is displayed on the next line.
 Graphical User Interface
 Graphical User Interface provides the user graphical means to interact with the
system. GUI can be combination of both hardware and software. 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.
 GUI Elements
 GUI provides a set of components to interact with software or hardware.
 Every graphical component provides a way to work with the system. A GUI system
has following elements such as:

 Window - An area where contents of application are displayed. Contents in a window

can be displayed in the form of icons or lists, if the window represents file structure. It
is easier for a user to navigate in the file system in an exploring window. Windows
can be minimized, resized or maximized to the size of screen. They can be moved
anywhere on the screen. A window may contain another window of the same
application, called child window.
 Tabs - If an application allows executing multiple instances of itself, they appear on
the screen as separate windows. Tabbed Document Interface has come up to open
multiple documents in the same window. This interface also helps in viewing
preference panel in application. All modern web-browsers use this feature.
 Menu - Menu is an array of standard commands, grouped together and placed at a
visible place (usually top) inside the application window. The menu can be
programmed to appear or hide on mouse clicks.
 Icon - An icon is small picture representing an associated application. When these
icons are clicked or double clicked, the application window is opened. Icon displays
application and programs installed on a system in the form of small pictures.
 Cursor - Interacting devices such as mouse, touch pad, digital pen are represented in
GUI as cursors. On screen cursor follows the instructions from hardware in almost
real-time. Cursors are also named pointers in GUI systems. They are used to select
menus, windows and other application features.

Application specific GUI components

A GUI of an application contains one or more of the listed GUI elements:

 Application Window - Most application windows uses the constructs supplied by

operating systems but many use their own customer created windows to contain the
contents of application.
 Dialogue Box - It is a child window that contains message for the user and request for
some action to be taken. For Example: Application generate a dialogue to get
confirmation from user to delete a file.

Text-Box - Provides an area for user to type and enter text-based data.
 3.52


Buttons - They imitate real life buttons and are used to submit inputs to the
software.

Radio-button - Displays available options for selection. Only one can be selected
among all offered.

Check-box - Functions similar
sim to list-box.
box. When an option is selected, the box is
marked as checked. Multiple options represented by check boxes can be selected.

List-box - Provides list of available items for selection. More than one item can be
selected.

Other impressive GUI components are:

 Sliders
 Combo-box
 Data-grid
 Drop-down list

User Interface Design Activities

There are a number of activities performed for designing user interface. The process of GUI
design and implementation is alike SDLC. Any model can be used for GUI implementation
among Waterfall, Iterative or Spiral Model.

A model used for GUI design and development should fulfill these GUI specific steps.

 GUI Requirement Gathering - The designers may like to have list of all functional
and non-functional
functional requirements of GUI. This can be taken from user and their
existing software solution.
 User Analysis - The designer studies who is going to use the software GUI. The
target audiencee matters as the design details change according to the knowledge and
competency level of the user. If user is technical savvy, advanced and complex GUI
can be incorporated. For a novice user, more information is included on how
how-to of
software.
 Task Analysis - Designers have to analyze what task is to be done by the software
solution. Here in GUI, it does not matter how it will be done. Tasks can be
 3.53

represented in hierarchical manner taking one major task and dividing it further into
smaller sub-tasks. Tasks provide goals for GUI presentation. Flow of information
among sub-tasks determines the flow of GUI contents in the software.
 GUI Design & implementation - Designers after having information about
requirements, tasks and user environment, design the GUI and implements into code
and embed the GUI with working or dummy software in the background. It is then
self-tested by the developers.
 Testing - GUI testing can be done in various ways. Organization can have in-house
inspection, direct involvement of users and release of beta version are few of them.
Testing may include usability, compatibility, user acceptance etc.

GUI Implementation Tools

There are several tools available using which the designers can create entire GUI on a
mouse click. Some tools can be embedded into the software environment (IDE).GUI
implementation tools provide powerful array of GUI controls. For software customization,
designers can change the code [Link] are different segments of GUI tools
according to their different use and platform.

Example

Mobile GUI, Computer GUI, Touch-Screen GUI etc. Here is a list of few tools which come
handy to build GUI:

 FLUID
 AppInventor (Android)
 LucidChart
 Wavemaker
 Visual Studio

User Interface Golden rules

The following rules are mentioned to be the golden rules for GUI design, described by
Shneiderman and Plaisant in their book (Designing the User Interface).

 Strive for consistency - Consistent sequences of actions should be required in similar

situations. Identical terminology should be used in prompts, menus, and help screens.
Consistent commands should be employed throughout.
 Enable frequent users to use short-cuts - The user’s desire to reduce the number of
interactions increases with the frequency of use. Abbreviations, function keys, hidden
commands, and macro facilities are very helpful to an expert user.
 Offer informative feedback - For every operator action, there should be some
system feedback. For frequent and minor actions, the response must be modest, while
for infrequent and major actions, the response must be more substantial.
 Design dialog to yield closure - Sequences of actions should be organized into
groups with a beginning, middle, and end. The informative feedback at the
completion of a group of actions gives the operators the satisfaction of
accomplishment, a sense of relief, the signal to drop contingency plans and options
from their minds, and this indicates that the way ahead is clear to prepare for the next
group of actions.
 3.54

 Offer simple error handling - As much as possible, le, design the system so the user
will not make a serious error. If an error is made, the system should be able to detect it
and offer simple, comprehensible mechanisms for handling the error.
 Permit easy reversal of actions - This feature relieves anxiety,, since the user knows
that errors can be undone. Easy reversal of actions encourages exploration of
unfamiliar options. The units of reversibility may be a single action, a data entry, or a
complete group of actions.
 Support internal locus of control - Experienced
perienced operators strongly desire the sense
that they are in charge of the system and that the system responds to their actions.
Design the system to make users the initiators of actions rather than the responders.
 Reduce short-term
term memory load - The limitation
itation of human information processing
in short-term
term memory requires the displays to be kept simple, multiple page displays
be consolidated, window--motion
motion frequency be reduced, and sufficient training time be
allotted for codes, mnemonics, and sequences oof actions.

Other impressive GUI components are:

 Sliders
 Combo-box
 Data-grid
 Drop-down list

User Interface Design Activities

There are a number of activities performed for designing user interface. The process of GUI
design and implementation is alike SDLC.
SDLC. Any model can be used for GUI implementation
among Waterfall, Iterative or Spiral Model.

A model used for GUI design and development should fulfill these GUI specific steps.

 GUI Requirement Gathering - The designers may like to have list of all functional
and non-functional
functional requirements of GUI. This can be taken from user and their
existing software solution.
 User Analysis - The designer studies who is going to use the software GUI. The
target audiencee matters as the design details change according to the knowledge and
 3.55

competency level of the user. If user is technical savvy, advanced and complex GUI
can be incorporated. For a novice user, more information is included on how-to of
software.
 Task Analysis - Designers have to analyze what task is to be done by the software
solution. Here in GUI, it does not matter how it will be done. Tasks can be
represented in hierarchical manner taking one major task and dividing it further into
smaller sub-tasks. Tasks provide goals for GUI presentation. Flow of information
among sub-tasks determines the flow of GUI contents in the software.
 GUI Design & implementation - Designers after having information about
requirements, tasks and user environment, design the GUI and implements into code
and embed the GUI with working or dummy software in the background. It is then
self-tested by the developers.
 Testing - GUI testing can be done in various ways. Organization can have in-house
inspection, direct involvement of users and release of beta version are few of them.
Testing may include usability, compatibility, user acceptance etc.

GUI Implementation Tools

There are several tools available using which the designers can create entire GUI on a mouse
click. Some tools can be embedded into the software environment (IDE).GUI implementation
tools provide powerful array of GUI controls. For software customization, designers can
change the code accordingly. There are different segments of GUI tools according to their
different use and platform.

Example

Mobile GUI, Computer GUI, Touch-Screen GUI etc. Here is a list of few tools which come
handy to build GUI:

 FLUID
 AppInventor (Android)
 LucidChart
 Wavemaker
 Visual Studio

User Interface Golden rules

The following rules are mentioned to be the golden rules for GUI design, described by
Shneiderman and Plaisant in their book (Designing the User Interface).

 Strive for consistency - Consistent sequences of actions should be required in similar

situations. Identical terminology should be used in prompts, menus, and help screens.
Consistent commands should be employed throughout.
 Enable frequent users to use short-cuts - The user’s desire to reduce the number of
interactions increases with the frequency of use. Abbreviations, function keys, hidden
commands, and macro facilities are very helpful to an expert user.
 Offer informative feedback - For every operator action, there should be some
system feedback. For frequent and minor actions, the response must be modest, while
for infrequent and major actions, the response must be more substantial.
 3.56

 Design dialog to yield closure - Sequences of actions should be organized into

groups with a beginning, middle, and end. The informative feedback at the
completion of a group of actions gives the operators the satisfaction of
accomplishment, a sense of relief, the signal to drop contingency plans and options
from their minds, and this indicates that the way ahead is clear to prepare for the next
group of actions.
 Offer simple error handling - As much as possible, design the system so the user
will not make a serious error. If an error is made, the system should be able to detect it
and offer simple, comprehensible mechanisms for handling the error.
 Permit easy reversal of actions - This feature relieves anxiety, since the user knows
that errors can be undone. Easy reversal of actions encourages exploration of
unfamiliar options. The units of reversibility may be a single action, a data entry, or a
complete group of actions.
 Support internal locus of control - Experienced operators strongly desire the sense
that they are in charge of the system and that the system responds to their actions.
Design the system to make users the initiators of actions rather than the responders.
 Reduce short-term memory load - The limitation of human information processing
in short-term memory requires the displays to be kept simple, multiple page displays
be consolidated, window-motion frequency be reduced, and sufficient training time be
allotted for codes, mnemonics, and sequences of actions.
IV UNIT - TESTING 4.1

UNIT IV TESTING
Testing – Unit testing – Black box testing– White box testing – Integration and System
testing– Regression testing – Debugging - Program analysis – Symbolic execution – Model
Checking

CODING AND TESTING

Aim of Testing
The aim of the testing process is to identify all defects existing in a software product.
However for most practical systems, even after satisfactorily carrying out the testing phase, it
is not possible to guarantee that the software is error free. This is because of the fact that the
input data domain of most software products is very large. It is not practical to test the
software exhaustively with respect to each value that the input data may assume. Even with
this practical limitation of the testing process, the importance of testing should not be
underestimated. It must be remembered that testing does expose many defects existing in a
software product. Thus testing provides a practical way of reducing defects in a
system and increasing the users’ confidence in a developed system.
What Exactly is Testing
Testing a program consists of providing the program with a set of test inputs (or test
cases) and observing if the program behaves as expected. If the program fails to behave as
expected, then the conditions under which failure occurs are noted for later debugging and
correction. Some commonly used terms associated with testing are:
• Failure: This is a manifestation of an error (or defect or bug). But, the mere presence of an
error may not necessarily lead to a failure.
• Test case: This is the triplet [I,S,O], where
I is the data input to the system,
S is the state of the system at which the data is input, and
O is the expected output of the system.
• Test suite: This is the set of all test cases with which a given software product is to be
tested.
Approaches to Testing
There are essentially two main approaches to systematically designing test cases. They are

Black-box Testing

White-box Testing

In the black-box testing approach, test cases are designed using only the functional
specification of the software, i.e. without any knowledge of the internal structure of the
software. For this reason, black-box testing is known as functional testing.

On the other hand, in the white-box testing approach, designing test cases requires thorough
knowledge about the internal structure of software, and therefore the white-box testing is
called structural testing.

UNIT TESTING

What is Unit Testing?

Unit testing, a testing technique using which individual modules are tested to determine if
there are any issues by the developer himself. It is concerned with functional correctness of
IV UNIT - TESTING 4.2

the standalone [Link] main aim is to isolate each unit of the system to identify, analyze
and fix the defects.

Unit Testing - Advantages

 Reduces Defects in the Newly developed features or reduces bugs when changing the
existing functionality.
 Reduces Cost of Testing as defects are captured in very early phase.
 Improves design and allows better refactoring of code.
 Unit Tests, when integrated with build gives the quality of the build as well.

Unit Testing LifeCyle

Unit Testing Techniques

 Black Box Testing - Using which the user interface, input and output are tested.
 White Box Testing - used to test each one of those functions behavior is tested.
 Gray Box Testing - Used to execute tests, risks and assessment methods.

Unit testing

Unit testing is the process of testing individual components in isolation. It is a defect

testing process. Units may be:

 Individual functions or methods within an object;

 Object classes with several attributes and methods;
 Composite components with defined interfaces used to access their functionality.
IV UNIT - TESTING 4.3

When testing object classes, tests should be designed to provide coverage of all of the
features of the object:

 Test all operations associated with the object;

 Set and check the value of all attributes associated with the object;
 Put the object into all possible states, i.e. simulate all events that cause a state
change.

Whenever possible, unit testing should be automated so that tests are run and checked
without manual intervention. In automated unit testing, you make use of a test automation
framework (such as JUnit) to write and run your program tests. Unit testing frameworks
provide generic test classes that you extend to create specific test cases. They can then run all
of the tests that you have implemented and report, often through some GUI, on the success of
otherwise of the tests. An automated test has three parts:

 A setup part, where you initialize the system with the test case, namely the inputs and
expected outputs.
 A call part, where you call the object or method to be tested.
 An assertion part where you compare the result of the call with the expected result. If
the assertion evaluates to true, the test has been successful if false, then it has failed.

The test cases should show that, when used as expected, the component that you are testing
does what it is supposed to do. If there are defects in the component, these should be revealed
by test cases. This leads to two types of unit test cases:

 The first of these should reflect normal operation of a program and should show that
the component works as expected.
 The other kind of test case should be based on testing experience of where common
problems arise. It should use abnormal inputs to check that these are properly
processed and do not crash the component.

BLACK-BOX TESTING

Testing in the large vs. testing in the small

Software products are normally tested first at the individual component (or unit) level.
This is referred to as testing in the small. After testing all the components individually, the
components are slowly integrated and tested at each level of integration (integration testing).
Finally, the fully integrated system is tested (called system testing). Integration and system
testing are known as testing in the large.

Unit testing
Unit testing is undertaken after a module has been coded and successfully reviewed.
Unit testing (or module testing) is the testing of different units (or modules) of a system in
isolation.
In order to test a single module, a complete environment is needed to provide all that
is necessary for execution of the module. That is, besides the module under test itself, the
following steps are needed in order to be able to test the module:
• The procedures belonging to other modules that the module under test calls.
• Nonlocal data structures that the module accesses.
IV UNIT - TESTING 4.4

• A procedure to call the functions of the module under test with appropriate
parameters.

Modules required to provide the necessary environment (which either call or are
called by the module under test) is usually not available until they too have been unit tested,
stubs and drivers are designed to provide the complete environment for a module. The role of
stub and driver modules is pictorially shown in fig. 10.1. A stub procedure is a dummy
procedure that has the same I/O parameters as the given procedure but has a highly simplified
behavior. For example, a stub procedure may produce the expected behavior using a simple
table lookup mechanism. A driver module contain the nonlocal data structures accessed by
the module under test, and would also have the code to call the different functions of the
module with appropriate parameter values.

Black box testing

In the black-box testing, test cases are designed from an examination of the
input/output values only and no knowledge of design, or code is required. The following are
the two main approaches to designing black box test cases.
• Equivalence class portioning
• Boundary value analysis

Equivalence Class Partitioning

In this approach, the domain of input values to a program is partitioned into a set of
equivalence classes. This partitioning is done such that the behavior of the program is similar
for every input data belonging to the same equivalence class. The main idea behind defining
the equivalence classes is that testing the code with any one value belonging to an
equivalence class is as good as testing the software with any other value belonging to that
equivalence class. Equivalence classes for a software can be designed by examining the input
data and output data. The following are some general guidelines for designing the
equivalence classes:
1. If the input data values to a system can be specified by a range of values, then one
valid and two invalid equivalence classes should be defined.
2. If the input data assumes values from a set of discrete members of some domain,
then one equivalence class for valid input values and another equivalence class
for invalid input values should be defined.

Example#1: For a software that computes the square root of an input integer which can
assume values in the range of 0 to 5000, there are three equivalence classes: The set of
negative integers, the set of integers in the range of 0 and 5000, and the integers larger than
5000. Therefore, the test cases must include representatives for each of the three equivalence
classes and a possible test set can be: {-5,500,6000}.
Example#2: Design the black-box test suite for the following program. The program
computes the intersection point of two straight lines and displays the result. It reads two
integer pairs (m1, c1) and (m2, c2) defining the two straight lines of the form y=mx + c.
The equivalence classes are the following:
• Parallel lines (m1=m2, c1≠c2)
• Intersecting lines (m1≠m2)
• Coincident lines (m1=m2, c1=c2)
IV UNIT - TESTING 4.5

Now, selecting one representative value from each equivalence class, the test suit (2, 2) (2, 5),
(5, 5) (7, 7), (10, 10) (10, 10) are obtained.

Boundary Value Analysis

A type of programming error frequently occurs at the boundaries of different equivalence
classes of inputs. The reason behind such errors might purely be due to psychological factors.
Programmers often fail to see the special processing required by the input values that lie at
the boundary of the different equivalence classes. For example, programmers may improperly
use < instead of <=, or conversely <= for <. Boundary value analysis leads to selection of test
cases at the boundaries of the different equivalence classes.
Example: For a function that computes the square root of integer values in the range of 0 and
5000, the test cases must include the following values: {0, -1,5000,5001}.

White box testing

One white-box testing strategy is said to be stronger than another strategy, if all types
of errors detected by the first testing strategy is also detected by the second testing strategy,
and the second testing strategy additionally detects some more types of errors. When two
testing strategies detect errors that are different at least with respect to some types of errors,
then they are called complementary. The concepts of stronger and complementary testing are
schematically illustrated in fig. 10.2.

Fig. 10.2: Stronger and complementary testing strategies

Statement coverage
The statement coverage strategy aims to design test cases so that every statement in a
program is executed at least once. The principal idea governing the statement coverage
strategy is that unless a statement is executed, it is very hard to determine if an error exists in
that statement. Unless a statement is executed, it is very difficult to observe whether it causes
failure due to some illegal memory access, wrong result computation, etc. However,
executing some statement once and observing that it behaves properly for that input value is
no guarantee that it will behave correctly for all input values. In the following, designing of
test cases using the statement coverage strategy have been shown.
Example: Consider the Euclid’s GCD computation algorithm:
int compute_gcd(x, y)
int x, y;
{
1 while (x! = y){
IV UNIT - TESTING 4.6

2 if (x>y) then
3 x= x – y;
4 else y= y – x;
5}
6 return x;
}
By choosing the test set {(x=3, y=3), (x=4, y=3), (x=3, y=4)}, we can exercise the
program such that all statements are executed at least once.
Branch coverage
In the branch coverage-based testing strategy, test cases are designed to make each
branch condition to assume true and false values in turn. Branch testing is also known as edge
testing as in this testing scheme, each edge of a program’s control flow graph is traversed at
least once.
It is obvious that branch testing guarantees statement coverage and thus is a stronger
testing strategy compared to the statement coverage-based testing. For Euclid’s GCD
computation algorithm , the test cases for branch coverage can be {(x=3, y=3), (x=3, y=2),
(x=4, y=3), (x=3, y=4)}.

Condition coverage
In this structural testing, test cases are designed to make each component of a
composite conditional expression to assume both true and false values. For example, in the
conditional expression (([Link].c2).or.c3), the components c1, c2 and c3 are each made to
assume both true and false values. Branch testing is probably the simplest condition testing
strategy where only the compound conditions appearing in the different branch statements are
made to assume the true and false values. Thus, condition testing is a stronger testing strategy
than branch testing and branch testing is stronger testing strategy than the statement
coverage-based testing. For a composite conditional expression of n components, for
condition coverage, 2ⁿ test cases are required. Thus, for condition coverage, the number of
test cases increases exponentially with the number of component conditions. Therefore, a
condition coverage-based testing technique is practical only if n (the number of conditions) is
small.

Path coverage
The path coverage-based testing strategy requires us to design test cases such that all
linearly independent paths in the program are executed at least once. A linearly independent
path can be defined in terms of the control flow graph (CFG) of a program.

Control Flow Graph (CFG)

A control flow graph describes the sequence in which the different instructions of a
program get executed. In other words, a control flow graph describes how the control flows
through the program. In order to draw the control flow graph of a program, all the statements
of a program must be numbered first. The different numbered statements serve as nodes of
the control flow graph (as shown in fig. 10.3). An edge from one node to another node exists
if the execution of the statement representing the first node can result in the transfer of
control to the other node.
The CFG for any program can be easily drawn by knowing how to represent the
sequence, selection, and iteration type of statements in the CFG. After all, a program is made
up from these types of statements. Fig. 10.3 summarizes how the CFG for these three types of
statements can be drawn. It is important to note that for the iteration type of constructs such
as the while construct, the loop condition is tested only at the beginning of the loop and
IV UNIT - TESTING 4.7

therefore the control flow from the last statement of the loop is always to the top of the loop.
Using these basic ideas, the CFG of Euclid’s GCD computation algorithm can be drawn as
shown in fig. 10.4

Fig. 10.3: CFG for (a) sequence, (b) selection, and (c) iteration type of constructs

Fig. 10.4: Control flow diagram

Path
A path through a program is a node and edge sequence from the starting node to a
terminal node of the control flow graph of a program. There can be more than one terminal
node in a program. Writing test cases to cover all the paths of a typical program is
impractical. For this reason, the path-coverage testing does not require coverage of all paths
but only coverage of linearly independent paths.
Linearly independent path
A linearly independent path is any path through the program that introduces at least
one new edge that is not included in any other linearly independent paths. If a path has one
IV UNIT - TESTING 4.8

new node compared to all other linearly independent paths, then the path is also linearly
independent. This is because, any path having a new node automatically implies that it has a
new edge. Thus, a path that is subpath of another path is not considered to be a linearly
independent path.
IV UNIT - TESTING 4.9

Control flow graph

In order to understand the path coverage-based testing strategy, it is very much
necessary to understand the control flow graph (CFG) of a program. Control flow graph
(CFG) of a program has been discussed earlier.
Linearly independent path
The path-coverage testing does not require coverage of all paths but only coverage of
linearly independent paths. Linearly independent paths have been discussed earlier.
Cyclomatic complexity
For more complicated programs it is not easy to determine the number of independent
paths of the program. McCabe’s cyclomatic complexity defines an upper bound for the
number of linearly independent paths through a program. Also, the McCabe’s cyclomatic
complexity is very simple to compute. Thus, the McCabe’s cyclomatic complexity metric
provides a practical way of determining the maximum number of linearly independent paths
in a program. Though the McCabe’s metric does not directly identify the linearly independent
paths, but it informs approximately how many paths to look for.
There are three different ways to compute the cyclomatic complexity. The answers
computed by the three methods are guaranteed to agree.

Method 1: Given a control flow graph G of a program, the cyclomatic complexity V(G) can
be computed as:
V(G) = E – N + 2 where N is the number of nodes of the control flow graph and E is
the number of edges in the control flow graph. For the CFG of example shown in fig. 10.4,
E=7 and N=6. Therefore, the cyclomatic complexity = 7-6+2 = 3.

Method 2:An alternative way of computing the cyclomatic complexity of a program from an
inspection of its control flow graph is as follows:
V(G) = Total number of bounded areas + 1
In the program’s control flow graph G, any region enclosed by nodes and edges can be called
as a bounded area. This is an easy way to determine the McCabe’s cyclomatic complexity.
But, what if the graph G is not planar, i.e. however you draw the graph, two or more edges
intersect? Actually, it can be shown that structured programs always yield planar graphs. But,
presence of GOTO’s can easily add intersecting edges. Therefore, for non-structured
programs, this way of computing the McCabe’s cyclomatic complexity cannot be used.
The number of bounded areas increases with the number of decision paths and loops.
Therefore, the McCabe’s metric provides a quantitative measure of testing difficulty and the
ultimate reliability. For the CFG example shown in fig. 10.4, from a visual examination of
the CFG the number of bounded areas is 2. Therefore the cyclomatic complexity, computing
with this method is also 2+1 = 3. This method provides a very easy way of computing the
cyclomatic complexity of CFGs, just from a visual examination of the CFG. On the other
hand, the other method of computing CFGs is more amenable to automation, i.e. it can be
easily coded into a program which can be used to determine the cyclomatic complexities of
arbitrary CFGs.

Method 3: The cyclomatic complexity of a program can also be easily computed by

computing the number of decision statements of the program. If N is the number of
decision statement of a program, then the McCabe’s metric is equal to N+1.
IV UNIT - TESTING 4.10

Data flow-based testing

Data flow-based testing method selects test paths of a program according to the
locations of the definitions and uses of different variables in a program.
For a statement numbered S, let
DEF(S) = {X/statement S contains a definition of X}, and
USES(S) = {X/statement S contains a use of X}
For the statement S:a=b+c;, DEF(S) = {a}. USES(S) = {b,c}. The definition of variable X at
statement S is said to be live at statement S1, if there exists a path from statement S to
statement S1 which does not contain any definition of X.
The definition-use chain (or DU chain) of a variable X is of form [X, S, S1], where S
and S1 are statement numbers, such that X Є DEF(S) and X Є USES(S1), and the definition
of X in the statement S is live at statement S1. One simple data flow testing strategy is to
require that every DU chain be covered at least once. Data flow testing strategies are useful
for selecting test paths of a program containing nested if and loop statements.

Mutation testing
In mutation testing, the software is first tested by using an initial test suite built up
from the different white box testing strategies. After the initial testing is complete, mutation
testing is taken up. The idea behind mutation testing is to make few arbitrary changes to a
program at a time. Each time the program is changed, it is called as a mutated program and
the change effected is called as a mutant. A mutated program is tested against the full test
suite of the program. If there exists at least one test case in the test suite for which a mutant
gives an incorrect result, then the mutant is said to be dead. If a mutant remains alive even
after all the test cases have been exhausted, the test data is enhanced to kill the mutant. The
process of generation and killing of mutants can be automated by predefining a set of
primitive changes that can be applied to the program. These primitive changes can be
alterations such as changing an arithmetic operator, changing the value of a constant,
changing a data type, etc. A major disadvantage of the mutation-based testing approach is
that it is computationally very expensive, since a large number of possible mutants can be
generated.
Since mutation testing generates a large number of mutants and requires us to check
each mutant with the full test suite, it is not suitable for manual testing. Mutation testing
should be used in conjunction of some testing tool which would run all the test cases
automatically.
Test cases for equivalence class testing and boundary value analysis for a problem.
Let’s consider a function that computes the square root of integer values in the range of 0 and
5000. For this particular problem, test cases corresponding to equivalence class testing and
boundary value analysis have been found out earlier.

Debugging
Need for debugging
Once errors are identified in a program code, it is necessary to first identify the
precise program statements responsible for the errors and then to fix them. Identifying errors
in a program code and then fix them up are known as debugging.
Debugging approaches
The following are some of the approaches popularly adopted by programmers for debugging.
Brute Force Method:
This is the most common method of debugging but is the least efficient method. In
this approach, the program is loaded with print statements to print the intermediate values
with the hope that some of the printed values will help to identify the statement in error. This
IV UNIT - TESTING 4.11

approach becomes more systematic with the use of a symbolic debugger (also called a source
code debugger), because values of different variables can be easily checked and break points
and watch points can be easily set to test the values of variables effortlessly.
Backtracking:
This is also a fairly common approach. In this approach, beginning from the statement
at which an error symptom has been observed, the source code is traced backwards until the
error is discovered. Unfortunately, as the number of source lines to be traced back increases,
the number of potential backward paths increases and may become unmanageably large thus
limiting the use of this approach.
Cause Elimination Method:
In this approach, a list of causes which could possibly have contributed to the error
symptom is developed and tests are conducted to eliminate each. A related technique of
identification of the error from the error symptom is the software fault tree analysis.
Program Slicing:
This technique is similar to back tracking. Here the search space is reduced by
defining slices. A slice of a program for a particular variable at a particular statement is the
set of source lines preceding this statement that can influence the value of that variable.

Debugging guidelines
Debugging is often carried out by programmers based on their ingenuity. The following are
some general guidelines for effective debugging:
• Many times debugging requires a thorough understanding of the program design. Trying to
debug based on a partial understanding of the system design and implementation may
require an inordinate amount of effort to be put into debugging even simple problems.
• Debugging may sometimes even require full redesign of the system. In such cases, a
common mistakes that novice programmers often make is attempting not to fix the error
but its symptoms.
• One must be beware of the possibility that an error correction may introduce new errors.
Therefore after every round of error-fixing, regression testing must be carried out.

Program analysis tools

A program analysis tool means an automated tool that takes the source code or the executable
code of a program as input and produces reports regarding several important characteristics
of the program, such as its size, complexity, adequacy of commenting, adherence to
programming standards, etc. We can classify these into two broad categories of program
analysis tools:
• Static Analysis tools
• Dynamic Analysis tools

Static program analysis tools

Static analysis tool is also a program analysis tool. It assesses and computes various
characteristics of a software product without executing it. Typically, static analysis tools
analyze some structural representation of a program to arrive at certain analytical
conclusions, e.g. that some structural properties hold. The structural properties that are
usually analyzed are:
• Whether the coding standards have been adhered to?
• Certain programming errors such as uninitialized variables and mismatch between actual
and formal parameters, variables that are declared but never used are also checked.
IV UNIT - TESTING 4.12

Code walk throughs and code inspections might be considered as static analysis methods.
But, the term static program analysis is used to denote automated analysis tools. So, a
compiler can be considered to be a static program analysis tool.

Dynamic program analysis tools

Dynamic program analysis techniques require the program to be executed and its
actual behavior recorded. A dynamic analyzer usually instruments the code (i.e. adds
additional statements in the source code to collect program execution traces). The
instrumented code when executed allows us to record the behavior of the software for
different test cases. After the software has been tested with its full test suite and its behavior
recorded, the dynamic analysis tool caries out a post execution analysis and produces reports
which describe the structural coverage that has been achieved by the complete test suite for
the program. For example, the post execution dynamic analysis report might provide data on
extent statement, branch and path coverage achieved.
Normally the dynamic analysis results are reported in the form of a histogram or a pie
chart to describe the structural coverage achieved for different modules of the program. The
output of a dynamic analysis tool can be stored and printed easily and provides evidence that
thorough testing has been done. The dynamic analysis results the extent of testing performed
in white-box mode. If the testing coverage is not satisfactory more test cases can be designed
and added to the test suite. Further, dynamic analysis results can help to eliminate redundant
test cases from the test suite.

Integration testing
The primary objective of integration testing is to test the module interfaces, i.e. there
are no errors in the parameter passing, when one module invokes another module. During
integration testing, different modules of a system are integrated in a planned manner using an
integration plan. The integration plan specifies the steps and the order in which modules are
combined to realize the full system. After each integration step, the partially integrated
system is tested. An important factor that guides the integration plan is the module
dependency graph. The structure chart (or module dependency graph) denotes the order in
which different modules call each other. By examining the structure chart the integration plan
can be developed.
Integration test approaches
There are four types of integration testing approaches. Any one (or a mixture) of the
following approaches can be used to develop the integration test plan. Those approaches are
the following:
• Big bang approach
• Top-down approach
• Bottom-up approach
• Mixed-approach
Big-Bang Integration Testing
It is the simplest integration testing approach, where all the modules making up a system are
integrated in a single step. In simple words, all the modules of the system are simply put
together and tested. However, this technique is practicable only for very small systems. The
main problem with this approach is that once an error is found during the integration testing,
it is very difficult to localize the error as the error may potentially belong to any of the
modules being integrated. Therefore, debugging errors reported during big bang integration
testing are very expensive to fix.
IV UNIT - TESTING 4.13

Bottom-Up Integration Testing

In bottom-up testing, each subsystem is tested separately and then the full system is tested. A
subsystem might consist of many modules which communicate among each other through
well-defined interfaces. The primary purpose of testing each subsystem is to test the
interfaces among various modules making up the subsystem. Both control and data interfaces
are tested. The test cases must be carefully chosen to exercise the interfaces in all possible
manners.
Large software systems normally require several levels of subsystem testing; lower-
level subsystems are successively combined to form higher-level subsystems. A principal
advantage of bottom-up integration testing is that several disjoint subsystems can be tested
simultaneously. In a pure bottom-up testing no stubs are required, only test-drivers are
required. A disadvantage of bottom-up testing is the complexity that occurs when the system
is made up of a large number of small subsystems. The extreme case corresponds to the big-
bang approach.
Top-Down Integration Testing
Top-down integration testing starts with the main routine and one or two subordinate
routines in the system. After the top-level ‘skeleton’ has been tested, the immediately
subroutines of the ‘skeleton’ are combined with it and tested. Top-down integration testing
approach requires the use of program stubs to simulate the effect of lower-level routines that
are called by the routines under test. A pure top-down integration does not require any driver
routines. A disadvantage of the top-down integration testing approach is that in the absence
of lower-level routines, many times it may become difficult to exercise the top-level routines
in the desired manner since the lower-level routines perform several low-level functions such
as I/O.
Mixed Integration Testing
A mixed (also called sandwiched) integration testing follows a combination of top-
down and bottom-up testing approaches. In top-down approach, testing can start only after
the top-level modules have been coded and unit tested. Similarly, bottom-up testing can start
only after the bottom level modules are ready. The mixed approach overcomes this
shortcoming of the top-down and bottom-up approaches. In the mixed testing approaches,
testing can start as and when modules become available. Therefore, this is one of the most
commonly used integration testing approaches.

Phased vs. incremental testing

The different integration testing strategies are either phased or incremental. A comparison of
these two strategies is as follows:
• In incremental integration testing, only one new module is added to the partial
system each time.
• In phased integration, a group of related modules are added to the partial system
each time.
Phased integration requires less number of integration steps compared to the incremental
integration approach. However, when failures are detected, it is easier to debug the system in
the incremental testing approach since it is known that the error is caused by addition of a
single module. In fact, big bang testing is a degenerate case of the phased integration testing
approach.

System testing
System tests are designed to validate a fully developed system to assure that it meets
its requirements. There are essentially three main kinds of system testing:
IV UNIT - TESTING 4.14

• Alpha Testing. Alpha testing refers to the system testing carried out by the test team
within the developing organization.
• Beta testing. Beta testing is the system testing performed by a select group of
friendly customers.
• Acceptance Testing. Acceptance testing is the system testing performed by the
customer to determine whether he should accept the delivery of the system.
In each of the above types of tests, various kinds of test cases are designed by
referring to the SRS document. Broadly, these tests can be classified into functionality and
performance tests. The functionality tests test the functionality of the software to check
whether it satisfies the functional requirements as documented in the SRS document. The
performance tests test the conformance of the system with the nonfunctional requirements of
the system.

Performance testing
Performance testing is carried out to check whether the system needs the non-
functional requirements identified in the SRS document. There are several types of
performance testing. Among of them nine types are discussed below. The types of
performance testing to be carried out on a system depend on the different non-functional
requirements of the system documented in the SRS document. All performance tests can be
considered as black-box tests.
• Stress testing
• Volume testing
• Configuration testing
• Compatibility testing
• Regression testing
• Recovery testing
• Maintenance testing
• Documentation testing
• Usability testing

Stress Testing
Stress testing is also known as endurance testing. Stress testing evaluates system
performance when it is stressed for short periods of time. Stress tests are black box tests
which are designed to impose a range of abnormal and even illegal input conditions so as to
stress the capabilities of the software. Input data volume, input data rate, processing time,
utilization of memory, etc. are tested beyond the designed capacity. For example, suppose an
operating system is supposed to support 15 multiprogrammed jobs, the system is stressed by
attempting to run 15 or more jobs simultaneously. A real-time system might be tested to
determine the effect of simultaneous arrival of several high-priority interrupts.
Stress testing is especially important for systems that usually operate below the
maximum capacity but are severely stressed at some peak demand hours. For example, if the
non-functional requirement specification states that the response time should not be more
than 20 secs per transaction when 60 concurrent users are working, then during the stress
testing the response time is checked with 60 users working simultaneously.
Volume Testing
It is especially important to check whether the data structures (arrays, queues, stacks,
etc.) have been designed to successfully extraordinary situations. For example, a compiler
might be tested to check whether the symbol table overflows when a very large program is
compiled.
IV UNIT - TESTING 4.15

Configuration Testing
This is used to analyze system behavior in various hardware and software
configurations specified in the requirements. Sometimes systems are built in variable
configurations for different users. For instance, we might define a minimal system to serve a
single user, and other extension configurations to serve additional users. The system is
configured in each of the required configurations and it is checked if the system behaves
correctly in all required configurations.
Compatibility Testing
This type of testing is required when the system interfaces with other types of
systems. Compatibility aims to check whether the interface functions perform as required.
For instance, if the system needs to communicate with a large database system to retrieve
information, compatibility testing is required to test the speed and accuracy of data retrieval.
Regression Testing
This type of testing is required when the system being tested is an upgradation of an
already existing system to fix some bugs or enhance functionality, performance, etc.
Regression testing is the practice of running an old test suite after each change to the system
or after each bug fix to ensure that no new bug has been introduced due to the change or the
bug fix. However, if only a few statements are changed, then the entire test suite need not be
run - only those test cases that test the functions that are likely to be affected by the change
need to be run.
Recovery Testing
Recovery testing tests the response of the system to the presence of faults, or loss of
power, devices, services, data, etc. The system is subjected to the loss of the mentioned
resources (as applicable and discussed in the SRS document) and it is checked if the system
recovers satisfactorily. For example, the printer can be disconnected to check if the system
hangs. Or, the power may be shut down to check the extent of data loss and corruption.
Maintenance Testing
This testing addresses the diagnostic programs, and other procedures that are required
to be developed to help maintenance of the system. It is verified that the artifacts exist and
they perform properly.
Documentation Testing
It is checked that the required user manual, maintenance manuals, and technical
manuals exist and are consistent. If the requirements specify the types of audience for which
a specific manual should be designed, then the manual is checked for compliance.
Usability Testing
Usability testing concerns checking the user interface to see if it meets all user
requirements concerning the user interface. During usability testing, the display screens,
report formats, and other aspects relating to the user interface requirements are tested.
Error seeding
Sometimes the customer might specify the maximum number of allowable errors that
may be present in the delivered system. These are often expressed in terms of maximum
number of allowable errors per line of source code. Error seed can be used to estimate the
number of residual errors in a system.
Error seeding, as the name implies, seeds the code with some known errors. In other
words, some artificial errors are introduced into the program artificially. The number of these
seeded errors detected in the course of the standard testing procedure is determined. These
values in conjunction with the number of unseeded errors detected can be used to predict:
• The number of errors remaining in the product.
• The effectiveness of the testing strategy.
IV UNIT - TESTING 4.16

Let N be the total number of defects in the system and let n of these defects be found by
testing.
Let S be the total number of seeded defects, and let s of these defects be found during testing.
n/N = s/S
or
N = S × n/s
Defects still remaining after testing = N–n = n×(S – s)/s

Error seeding works satisfactorily only if the kind of seeded errors matches closely
with the kind of defects that actually exist. However, it is difficult to predict the types of
errors that exist in a software. To some extent, the different categories of errors that remain
can be estimated to a first approximation by analyzing historical data of similar projects. Due
to the shortcoming that the types of seeded errors should match closely with the types of
errors actually existing in the code, error seeding is useful only to a moderate extent.

Regression testing
Regression testing does not belong to either unit test, integration test, or system
testing. Instead, it is a separate dimension to these three forms of testing. The functionality of
regression testing has been discussed earlier. Regression Testing is defined as a type of
software testing to confirm that a recent program or code change has not adversely affected
existing features. Regression Testing is nothing but full or partial selection of already
executed test cases which are re-executed to ensure existing functionalities work fine. This
testing is done to make sure that new code changes should not have side effects on the
existing functionalities. It ensures that old code still works once the new code changes are
done.

Need of Regression Testing

Regression Testing is required when there is a

 Change in requirements and code is modified according to the requirement

 New feature is added to the software
 Defect fixing
 Performance issue fix

Regression Testing Techniques

Software maintenance is an activity which includes enhancements, error corrections,

optimization and deletion of existing features. These modifications may cause the system to
work incorrectly. Therefore, Regression Testing becomes necessary. Regression Testing can
be carried out using following techniques:
IV UNIT - TESTING 4.17

Retest All

 This is one of the methods for Regression Testing in which all the tests in the existing
test bucket or suite should be re-executed. This is very expensive as it requires huge
time and resources.

Regression Test Selection

 Instead of re-executing the entire test suite, it is better to select part of test suite to be
run
 Test cases selected can be categorized as 1) Reusable Test Cases 2) Obsolete Test
Cases.
 Re-usable Test cases can be used in succeeding regression cycles.
 Obsolete Test Cases can't be used in succeeding cycles.

Prioritization of Test Cases

 Prioritize the test cases depending on business impact, critical & frequently used
functionalities. Selection of test cases based on priority will greatly reduce the
regression test suite.

Selecting test cases for regression testing

It was found from industry data that good number of the defects reported by
customers were due to last minute bug fixes creating side effects and hence selecting the Test
Case for regression testing is an art and not that easy. Effective Regression Tests can be done
by selecting following test cases -

 Test cases which have frequent defects

 Functionalities which are more visible to the users
 Test cases which verify core features of the product
 Test cases of Functionalities which has undergone more and recent changes
 All Integration Test Cases
 All Complex Test Cases
 Boundary value test cases
 Sample of Successful test cases
 Sample of Failure test cases
IV UNIT - TESTING 4.18

Regression Testing Tools

If your software undergoes frequent changes, regression testing costs will escalate. In
such cases, Manual execution of test cases increases test execution time as well as costs.
Automation of regression test cases is the smart choice in such cases. Extent of automation
depends on the number of test cases that remain re-usable for successive regression cycles.
Following are most important tools used for both functional and regression testing:

Selenium: This is an open source tool used for automating web applications. Selenium can be
used for browser based regression testing.

Quick Test Professional (QTP): HP Quick Test Professional is automated software

designed to automate functional and regression test cases. It uses VBScript language for
automation. It is a Data driven, Keyword based tool.

Rational Functional Tester (RFT): IBM's rational functional tester is a Java tool used to
automate the test cases of software applications. This is primarily used for automating
regression test cases and it also integrates with Rational Test Manager.

Regression Testing and Configuration Management

Configuration Management during Regression Testing becomes imperative in Agile

Environments where code is being continuously modified. To ensure effective regression
tests, observe the following:

 Code being regression tested should be under a configuration management tool

 No changes must be allowed to code, during the regression test phase. Regression test
code must be kept immune to developer changes.
 The database used for regression testing must be isolated. No database changes must
be allowed.

Difference between Re-Testing and Regression Testing:

Retesting means testing the functionality or bug again to ensure the code is fixed. If it is not
fixed, Defect needs to be re-opened. If fixed, Defect is closed. Regression testing means
testing your software application when it undergoes a code change to ensure that the new
code has not affected other parts of the software. Also, check out the complete list of
differences over here .

Challenges in Regression Testing:

IV UNIT - TESTING 4.19

Following are the major testing problems for doing regression testing:

 With successive regression runs, test suites become fairly large. Due to time and
budget constraints, the entire regression test suite cannot be executed
 Minimizing test suite while achieving maximum Test coverage remains a challenge
 Determination of frequency of Regression Tests, i.e., after every modification or
every build update or after a bunch of bug fixes, is a challenge.

Symbolic execution

In computer science, symbolic execution (also symbolic evaluation) is a means of

analyzing a program to determine what inputs cause each part of a program to execute. An
interpreter follows the program, assuming symbolic values for inputs rather than obtaining
actual inputs as normal execution of the program would, a case of abstract interpretation. It
thus arrives at expressions in terms of those symbols for expressions and variables in the
program, and constraints in terms of those symbols for the possible outcomes of each
conditional branch. The field of symbolic simulation applies the same concept to hardware.
Symbolic computation applies the concept to the analysis of mathematical expressions.

Example

Consider the program below, which reads in a value and fails if the input is 6.

int f() {
...
y = read();
z = y * 2;
if (z == 12) {
fail();
} else {
printf("OK");
}
}

During a normal execution ("concrete" execution), the program would read a concrete
input value (e.g., 5) and assign it to y. Execution would then proceed with the multiplication
and the conditional branch, which would evaluate to false and print OK.

During symbolic execution, the program reads a symbolic value (e.g., λ) and assigns
it to y. The program would then proceed with the multiplication and assign λ * 2 to z. When
reaching the if statement, it would evaluate λ * 2 == 12. At this point of the program, λ could
take any value, and symbolic execution can therefore proceed along both branches, by
"forking" two paths. Each path gets assigned a copy of the program state at the branch
instruction as well as a path constraint. In this example, the path constraint is λ * 2 == 12 for
the then branch and λ * 2 != 12 for the else branch. Both paths can be symbolically executed
independently. When paths terminate (e.g., as a result of executing fail() or simply exiting),
symbolic execution computes a concrete value for λ by solving the accumulated path
constraints on each path. These concrete values can be thought of as concrete test cases that
IV UNIT - TESTING 4.20

can, e.g., help developers reproduce bugs. In this example, the constraint solver would
determine that in order to reach the fail() statement, λ would need to equal 6.

Limitations

Path Explosion

Symbolically executing all feasible program paths does not scale to large programs. The
number of feasible paths in a program grows exponentially with an increase in program size
and can even be infinite in the case of programs with unbounded loop iterations.[1] Solutions
to the path explosion problem generally use either heuristics for path-finding to increase code
coverage,[2] reduce execution time by parallelizing independent paths,[3] or by merging
similar paths.[4]

Program-Dependent Efficacy

Symbolic execution is used to reason about a program path-by-path which is an advantage

over reasoning about a program input-by-input as other testing paradigms use (e.g. Dynamic
program analysis). However, if few inputs take the same path through the program, there is
little savings over testing each of the inputs separately.

Environment Interactions

Programs interact with their environment by performing system calls, receiving signals, etc.
Consistency problems may arise when execution reaches components that are not under
control of the symbolic execution tool (e.g., kernel or libraries). Consider the following
example:

int main()
{
FILE *fp = fopen("[Link]");
...
if (condition) {
fputs("some data", fp);
} else {
fputs("some other data", fp);
}
...
data = fgets(..., fp);
}

This program opens a file and, based on some condition, writes different kind of data to the
file. It then later reads back the written data. In theory, symbolic execution would fork two
paths at line 5 and each path from there on would have its own copy of the file. The statement
at line 11 would therefore return data that is consistent with the value of "condition" at line 5.
In practice, file operations are implemented as system calls in the kernel, and are outside the
control of the symbolic execution tool. The main approaches to address this challenge are:

Executing calls to the environment directly. The advantage of this approach is that it is
simple to implement. The disadvantage is that the side effects of such calls will clobber all
IV UNIT - TESTING 4.21

states managed by the symbolic execution engine. In the example above, the instruction at
line 11 would return "some datasome other data" or "some other datasomedata" depending on
the sequential ordering of the states.

Modeling the environment. In this case, the engine instruments the system calls with a
model that simulates their effects and that keeps all the side effects in per-state storage. The
advantage is that one would get correct results when symbolically executing programs that
interact with the environment. The disadvantage is that one needs to implement and maintain
many potentially complex models of system calls. Tools such as KLEE,[5] Cloud9, and
Otter[6] take this approach by implementing models for file system operations, sockets, IPC,
etc.

Forking the entire system state. Symbolic execution tools based on virtual machines solve
the environment problem by forking the entire VM state. For example, in S2E[7] each state is
an independent VM snapshot that can be executed separately. This approach alleviates the
need for writing and maintaining complex models and allows virtually any program binary to
be executed symbolically. However, it has higher memory usage overheads (VM snapshots
may be large).

Model checking

Model checking or property checking refers to the following problem: Given a model of a
system, exhaustively and automatically check whether this model meets a given specification.
Typically, one has hardware or software systems in mind, whereas the specification contains
safety requirements such as the absence of deadlocks and similar critical states that can cause
the system to crash. Model checking is a technique for automatically verifying correctness
properties of finite-state systems.
IV UNIT - TESTING 4.22

Safety and Liveness

• Safety properties
– Invariants, deadlocks, reachability, etc.
– Can be checked on finite traces
– “something bad never happens”
• Liveness Properties
– Fairness, response, etc.
– Infinite traces
– “something good will eventually happen”
IV UNIT - TESTING 4.23

Model Checking
• Given a Kripke structure M = (S,R,L) that represents a finite-state
concurrent system and a temporal logic formula f expressing some
desired specification, find the set of states in S that satisfy f:

{ s  S | M,s ╞ f }
IV UNIT - TESTING 4.24

• Normally, some states of the concurrent system are designated as

initial states. The system satisfies the specification provided all the
initial states are in the set. We often write: M ╞ f
DevOps
Definition:
DevOps is a set of practices intended to reduce the time between committing a change to a
system and the change being placed into normal production, while ensuring high quality.

1.1 DevOps Practices:

We have identified five different categories of DevOps practices below
 Treat Ops as first-class citizens from the point of view of requirements. These
practices fit in the high-quality aspect of the definition. Operations have a set of
requirements that pertain to logging and monitoring. For example, logging messages
should be understandable and usable by an operator. Involving operations in the
development of requirements will ensure that these types of requirements are
considered.
 Make Dev more responsible for relevant incident handling. These practices are
intended toshorten the time between the observation of an error and the repair of that
error. Organizations that utilize these practices typically have a period of time in
which Dev has primary responsibility for a new deployment; later on, Ops has
primary responsibility.
 Enforce the deployment process used by all, including Dev and Ops personnel. These
practicesare intended to ensure a higher quality of deployments. This avoids errors
caused by ad hoc deployments and the resulting misconfiguration. The practices also
refer to the time that it takes to diagnose and repair an error. The normal deployment
process should make it easy to trace the history of a particular deployment artifact and
understand the components that were included in that artifact.
 Use continuous deployment. Practices associated with continuous deployment are
intended to shorten the time between a developer committing code to a repository and
the code being deployed. Continuous deployment also emphasizes automated tests to
increase the quality of code making its way into production.
 Develop infrastructure code, such as deployment scripts, with the same set of
practices as application code. Practices that apply to the development of infrastructure
code are intended to ensure both high quality in the deployed applications and that
deployments proceed as [Link] in deployment scripts such as
misconfigurations can cause errors in the application, the environment, or the
deployment process. Applying quality control practices used in normalsoftware
development when developing operations scripts and processes will help control the
quality of these specifications.

1.2DevOps processes:
 Figure 1.1 gives an overview of DevOps processes. At its most basic, DevOps
advocates treating Operations personnel as first-class stakeholders. Preparing a release
can be a very serious and onerous process. (We describe that in the section “Release
Process.”)
 As such, operations personnelmay need to be trained in the types of runtime errors
that can occur in a system under development;they may have suggestions as to the
type and structure of log files, and they may provide other types of input into the
requirements process.
 At its most extreme, DevOps practices make developers
responsible for monitoring the progress and errors that occur during deployment and
execution, so theirs would be the voices suggesting requirements.
 In between are practices that cover team practices, build processes, testing processes,
and deployment processes.
 FIGURE 1.1 DevOps life cycle processes

1.3 DevOps Perspective:

Automation
 Figure 1.1 shows the various life cycle processes. The steps from build and testing
through executioncan all be automated to some degree.
 Tools can perform the actions required in each step of the process, check the validity
of actions against the production environment or against some external specification,
inform appropriate personnel of errors occurring in the process, and maintain a history
of actions for quality control,reporting, and auditing purposes.
 Tools and scripts also can enforce organization-wide policies. Once tools become
central to a set of processes, then the use of these tools must also be managed.
 Tools are invoked, for example, from scripts, configuration changes, or the operator’s
[Link] scripts, configuration files, andspecification files must be subject to the
same quality control as the application code itself.
 The scripts and files should also be under version control and subject to examination
for corrections. This is often termed “infrastructure-as-code.”
Development Team Responsibilities
 If the development team accepts DevOps responsibilities, that is, it delivers, supports,
and maintains the service, then there is less need to transfer knowledge to the
operations and support staff since all of the necessary knowledge is resident in the
development team.
 Not having to transfer knowledge removes a significant coordination step from the
deployment process.

1.4 DevOps and Agile

Disciplined Agile Delivery:
As shown in Figure 1.2,Disciplined Agile Delivery has three phases—inception, construction,
and transition. In the DevOps context, weinterpret transition as deployment.

FIGURE 1.2 Disciplined Agile Delivery phases for each release.

DevOps practices impact all three phases.
1. Inception phase. During the inception phase, release planning and initial requirements
specification are done.
a. Considerations of Ops will add some requirements for the developers. Maintaining
backward compatibility between releases and having features be software switchable are two
of these requirements. The form and content of operational log messages impacts the ability
of Ops to troubleshoot a problem.
b. Release planning includes feature prioritization but it also includes coordination with
operations personnel about the scheduling of the release and determining what training the
operations personnel require to support the new release. Release planning also includes
ensuring compatibility with other packages in the environment and a recovery plan if the
release fails.
2. Construction phase. During the construction phase, key elements of the DevOps practices
are the management of the code branches, the use of continuous integration and continuous
deployment, and incorporation of test cases for automated testing. These are also agile
practices but form an important portion of the ability to automate the deployment pipeline. A
new element is the integrated and automated connection between construction and transition
activities.
3. Transition phase. In the transition phase, the solution is deployed and the development
team is responsible for the deployment, monitoring the process of the deployment, deciding
whether to roll back and when, and monitoring the execution after deployment. The
development team has a role of “reliability engineer,” who is responsible for monitoring and
troubleshooting problems during deployment and subsequent execution.

1.5 Team Structure

In this section, the usual size of and roles within a development team with DevOps
responsibilities are discussed.
Team Size
Although the exact team size recommendation differs from one methodology to another, all
agree that the size of the team should be relatively small.
The advantages of small teams are:
 They can make decisions quickly. In every meeting, attendees wish to express their
opinions. The smaller the number of attendees at the meeting, the fewer the number of
opinions expressed and the less time spent hearing differing opinions. Consequently,
the opinions can be expressed and a consensus arrived at faster than with a large team.
 It is easier to fashion a small number of people into a coherent unit than a large
number. A coherent unit is one in which everyone understands and subscribes to a
common set of goals for the team.
 It is easier for individuals to express an opinion or idea in front of a small group than
in front of a large one.
The disadvantage of a small team is that some tasks are larger than can be
accomplished by a small number of individuals.
In this case the task has to be broken up into smaller pieces, each given to a different
team, and the different pieces need to work together sufficiently well to accomplish the larger
task. To achieve this, the teams need to coordinate.
Team Roles
 Team lead. This role, called “Scrum Master” in Scrum or team coach or project lead
in other methods, is responsible for facilitating the team, obtaining resources for it,
and protecting it from problems. This role encompasses the soft skills of project
management but not the technical ones such as planning and scheduling, activities
which are better left to the team as a whole.
 Team member. This role, sometimes referred to as developer or programmer, is
responsible for the creation and delivery of a system. This includes modeling,
programming, testing, and release activities, as well as others.
Service Owner
 The service owner is the role on the team responsible for outside coordination.
 The service owner maintains and communicates the vision for the service.
  The ability to communicate both with other stakeholders and with other members of
the team is a key requirement for the service owner.
Reliability Engineer
 The reliability engineer has several responsibilities. First, the reliability engineer
monitors the service in the time period immediately subsequent to the deployment.
This may involve the use of canaries (live testing of a small number of nodes) and a
wide variety of metrics taken from the service.
 Second, the reliability engineer is the point of contact for problems with the service
during its execution. This means being on call for services that require high
availability. Google calls this role “Site Reliability Engineer.”
 Once a problem occurs, the reliability engineer performs short-term analysis to
diagnose, mitigate, and repair the problem, usually with the assistance of automated
tools.
Gatekeeper
Netflix uses the steps given in Figure 1.3 from local development to deployment.

FIGURE 1.3 Netflix path to production.

DevOps Engineer
Examine Figure 1.2 again with an eye toward the use of tools in this process. Some of the
tools used are code testing tools, configuration management tools, continuous integration
tools, deployment tools, or post-deployment testing tools.

1.6 Coordination
One goal of DevOps is to minimize coordination in order to reduce the time to market.
Two of the reasons to coordinate are, first, so that the pieces developed by the various teams
will work together and, second, to avoid duplication of effort.
Forms of Coordination
Coordination mechanisms have different attributes.
 Direct—the individuals coordinating know each other (e.g., team members).
 Indirect—the coordination mechanism is aimed at an audience known only by its
characterization (e.g., system administrators).
 Persistent—the coordination artifacts are available after the moment of the
coordination (e.g.,documents, e-mail, bulletin boards).
 Ephemeral—the coordination, per se, produces no artifacts (e.g., face to face
meetings,conversations, telephone/video conferencing). Ephemeral coordination can
be made persistent through the use of human or mechanical recorders.
 Synchronous—individuals are coordinating in real time, (e.g., face to face).
 Asynchronous—individuals are not coordinating in real time (e.g., documents, e-
mail).
Team Coordination
Team coordination mechanisms are of two types—human processes and automated
processes.
Cross-team Coordination
Examining the release process activities again makes it clear that cross-team
coordination is the most time-consuming factor. The role of the service owner is to perform
upstream coordination. Downstream coordination is accomplished by moving many
operations responsibilities to the development team. It is cross-team coordination that we
focus on now.
1. Making the code pieces work together. Architecture for the system being developed will
help make the pieces work together. Architecture specifies a number of the design decisions
to create an overall system. Six of these design decisions are:
a. Allocation of responsibilities.
b. Coordination model.
c. Data model.
d. Management of resources.
e. Mapping among architectural elements.
f. Binding time decisions.
2. Avoiding duplication of effort.
DevOps practices essentially argue that duplication of effort is a necessary cost for
shorter time to market. There are two portions to this argument.
First, since the task each team has to accomplish is small, any duplication is small.
Large potential areas of duplication, such as each team creating their own data store, are
handled by the architecture.
Second, since each team is responsible for its own service, troubleshooting problems
after deployment is faster with code written by the team, and it avoids escalating a problem to
a different team.

1.7 Barriers
Culture and Type of Organization
Culture depends not only on your role but also on the type of organization to which
you belong. For some organizations the risks of problems occurring outweigh a time-to-
market advantage.
 Organizations that operate in regulated domains—financial, health care, or utility
services— have regulations to which they must adhere and face penalties, potentially
severe, if they violate the regulations under which they operate. Even organizations in
regulated domains may have products that are unregulated. So a financial organization
may use DevOps processes for some products. For products that require more oversight,
the practices may be adaptable, for example, by introducing additional gatekeepers.
 Organizations that operate in mature and slow-moving domains—automotive or building
construction—have long lead times, and, although their deadlines are real, they are also
foreseeable far in advance.
 Organizations whose customers have a high cost of switching to another supplier, such
as Enterprise Resource Planning systems, are reluctant to risk the stability of their
operations. The cost of downtime for some systems will far outweigh the competitive
advantage of introducing a new feature somewhat more quickly.
For other organizations, nimbleness and fast response are more important than the occasional
error caused by moving too fast.
 Organizations that rely on business analytics to shape their products want to have shorter
and shorter times between the gathering of the data and actions inspired by the data. Any
errors that result can be quickly corrected since the next cycle will happen quickly.
 Organizations that face severe competitive pressure want to have their products and new
features in the marketplace before their competitors.
Type of Department
  One method for determining the culture of an organization is to look at what kinds of
results are incentivized. Salespeople who work on commission work very hard to get
sales. CEOs who are rewarded based on quarterly profits are focused on the results of
the next quarter. This is human nature. Developers are incentivized to produce and
release code.
 Operations personnel, on the other hand, are incentivized to minimize downtime.
Minimizing downtime means examining and removing causes of downtime. Examining
anything in detail takes time. Furthermore, avoiding change removes one of the causes
of downtime.
 Basically, developers are incentivized to change something (release new code), and
operations personnel are incentivized to resist change. These two different sets of
incentives breed different attitudes and can be the cause of culture clashes.
Silo Mentality
 It is easy to say that two departments in an organization have a common goal—ensuring
the Organization’s success. It is much more difficult to make this happen in practice.
An individuals’ loyalty tends to be first to her or his team and secondarily to the overall
organization.
 If the development team is responsible for defining the release plan that will include
what features get implemented in what priority, other portions of the organization will
see some of their power being usurped and, potentially, their customers become
unhappy. If activities formerly performed by operations personnel are now going to be
performed by developers, what happens to the operations personnel who now have less
to do?
 These are the normal ebbs and flows of organizational politics but that does not make
them less meaningful and less real.
Tool Support
 We described the advantages of automating processes previously, and these advantages
are real. They do not come without a cost, however.
 There must be expertise in the installation, configuration, and use of each tool. Tools
have new releases, inputs, and idiosyncrasies. Tool expertise has to be integrated into
the organization.
 If the organization uses common processes across a wide variety of development teams,
then there must be a means of defining these common processes and ensuring that all of
the development teams obey them. Use of a tool means subscribing to the process
implicit in that tool.

Personnel Issues
 According to the Datamation 2012 IT salary guide, a software engineer earns about
50% more than a systems administrator. So by moving a task from a system
administrator (Ops) to a software engineer (Dev), the personnel performing the task cost
50% more. Thus, the time spent performing the task must be cut by a third just to make
the performance of the task cost the same amount.
 A bigger cut is necessary to actually gain time, with automation being the prevalent
method to achieve these time savings. This is the type of cost/benefit analysis that an
organization must go through in order to determine which DevOps processes to adopt
and how to adopt them.
 Developers with a modern skill set are in high demand and short supply, and they also
have a heavy workload. Adding more tasks to their workload may exacerbate the
shortage of developers.
 CS6403 - SOFTWARE ENGINEERING
QUESTION BANK
UNIT I- SOFTWARE PRODUCT AND PROCESS
Part - A (2 M ARKS)
1. What is the prime objective of software engineering?
2. Define software engineering paradigm.
3. What do you mean by spiral model?
4. Write a brief note on waterfall model.
5. Distinguish between process and methods.
6. Give the importance of software engineering.
7. Define software process. State the important features of a process.
8. Write any two characteristics of software as a product.
9. List the process maturity levels in SEI' s CMM.
10. Distinguish clearly between verification & validation.
11. What are the functions of data architecture?
12. Define System Modeling.
13. State the System Engineering Hierarchy.
14. Mention some of the factors to be considered during System Modeling.
15. What are the different architectures developed during BPE?
16. Define Verification &Validation.

PART – B
1. Explain iterative waterfall and spiral model for software life cycle and discuss various
activities in each phase. (16)
2. List several software process paradigms. Explain how both waterfall model and prototyping
model can be accommodated in the spiral process model. (16)
3. Explain in detail Boehm's spiral model for softwre life cycle and discuss various activities in
each phase. (16)
4. a) Which is more important-the product or process? Justify your answer. (4)
b) Identify the umbrella activities in software engineering process. (4)
c) With suitable illustration explain SPIRAL model evolutionary software development . (8)

UNIT II - SOFTWARE REQUIREMENTS

PART A (2 M ARKS)
1. Mention any two non-functional requirements on software to be developed
2. What is known as SRS review? How is it conducted?
3. Distinguish between expected requirements and excited requirements
4. What is meant by software prototyping?
5. What are the non-functional requirements of software?
6. What is data dictionary? How is it used in software engineering?
7. Write the distinct steps in requirements engineering process?
8. Compare evolutionary and throw away prototyping?
9. What is the role of data dictionary?
10. Write a brief note on data modeling activity?
11. What is meant by Information flow Continuity?
12. Draw a DFD & CFD of a test monitoring system for Gas Turbine
13. Define Behavioral Modeling.
14. Draw the Context level DFD for the Safe home Software.
15. What is meant by Data dictionary?
16. Define Process Specification.
17. What does data dictionary contains?
18. Write down the Data dictionary for the data item “Telephone
19. What is meant by Throw away Prototyping?

PART B
1) Explain the ways and means for collecting the software requirements and how are they
organized and represented? (16)
2) Describe various prototyping techniques and discuss on analysis sand modeling.(16)
3) a) Discuss in detail the data modeling activity (8)
b) Write briefly about the utility of state transition diagram in analysis modeling activity (8)
4) a) Compare functional and behavioral models. (4)
b) With a suitable diagram explain the elements of the analysis model (8)
c) With an example explain about DFD. (4)
5) a) Explain the extensions of DFD for real time systems. (8)
b) Discuss the features of state transition diagram and its application. (8)
6) a) Explain the feasibility studies. What are the outcomes? Does it have either implicit or
explicit effects on software requirement collection? (8)
b) What is the prototyping technique? How prototype models are prepared for a software
process? Discuss. (8)
7) a) Describe how software requirements are documented? State the importance of
documentation. (8)
b) Explain the software requirement analysis and modeling. (8)
8) Explain the state oriented approaches for representing behavioral specifications of software.
(16)
9) Narrate the importance of software specification of requirements.
Explain a typical SRS structure and its parts. (16)
10) Discuss in detail the FAST method of
a. Requirement elicitation with an example. (8)
b. What is software specification? (8)
11) Write short notes on data modeling? (6)
a. Discuss in detail the basic structure of analysis model. (10)
12) How is SRS for a development project arrived at? (6)
a. What minimum features are required to be present in a good SRS?(10)

UNIT III- AN ALYSIS, DESIGN CONCEPTS AND PRINCIPLES

PART A (2 MARKS)
1) What do you mean by horizontal and vertical partitioning?
2) How do you evaluate user interface?
3) Why software architecture is important in a software process?
4) Distinguish between horizontal and vertical partitioning?
5) How reliability is related to quality assurance?
6) Distinguish between horizontal and vertical partitioning?
7) What is the software architecture?
8) Compare data flow oriented design and data structured oriented design
9) What is the role of verification during a software exercise?
10) Distinguish between hard and soft real time systems.
11) Distinguish between product and process metrics.
12) What do you mean by reuse of design and update of a design as per technology
changes and customer psychology?
13) What is the work product of software design process and who does this?
14) Enumerate different data flow architectures
15) How do you describe software interface?
16) How the requirements are collected for user interface of software?
17) What is transaction mapping? How it is used in software design?
18) What are the various models produce by the software design process?
19) What is the quality parameters considered for effective modular design?

PART B
1. What is transform mapping? Explain the process with an illustration. What is its strength and
weakness? (16)
2. a) Explain about the various design concepts considered during design? (12)
b) Write short notes on user interface design process? (4)
3. a) Explain data architectural and procedural design for a software? (8)
b) Describe the design procedure for data acquisition system (8)
4. Explain the importance of user interface design in sale of software. (16)
5. Describe decomposition levels of abstraction and modularity concepts in software design?
(16)
6. What are the characteristics of a good design? Describe different types of coupling and
cohesion. How design evaluation is performed? (16)
7. Draw the basic structure of analysis model and explain each entity in detail.(16)
8. a) discuss in detail about the design process in software development process (8)
b) Justify “Design is not coding and coding is not design”. (8)
9. a) Explain in detail about the characteristics and criteria for a good design. (10)
b) Describe the golden rules for interface design. (6)
10. a) What is the design document?
b) How is it organized?
11. What are the various software architectures available for the developer according to you?
Which is the best and why? (8)
12. What do you mean by modularity in software development? Why is it needed? What is its
strength? (8)
13. a) What are the various model of abstraction? Discuss any two in detail? (8)
b) How does a real time system design differ comparing distributed system design? (8)
14. a) Explain the set of principles for software engineering design? (10)
b) Describe the concept of information hiding. (6)
15. a) What is data flow oriented design. (3)
 b) Draw a detailed dataflow diagram for library management. (10)
c) What are the components dataflow oriented design. (3)
16. a) What is SCM? (4)
b) How are SCM tasks practiced over the operational life of software? (6)
c) What is the impact of requirement changes during development of a software product? (6)

UNIT IV- TESTING

PART-A( 2 MARKS)
1. What is stress testing?
2. State the objectives and guidelines for debugging.
3. Distinguish between verification and validation:
4. What are the roles of testing tools?
5. What do you mean by test case management?
6. Distinguish between alpha and beta testing?
7. What are the approaches of debugging?
8. What are the roles of cyclomatic complexity value in software resting?
9. What is the need for cyclomatic complexity?
10. Distinguish between black and white box testing:
11. What is white box testing and what is the difficulty while exercising it?
12. Why testing is important with respect to software?
13. Define black box testing strategy?
14. What is static and dynamic testing?
15. How regression and stress tests are are performed?
16. Write short notes on equivalence partitioning?
17. Write the types of system tests?

PART B
1. Discuss the differences between black box and white box testing [Link] how these
testing models may be used together to test a program schedule. (16)
2. a) What do you mean by system testing? Explain in detail (12)
b) Explain boundary value analysis. (4)
3. a) Justify the importance of testing process(8)
b) Discuss in detail about alpha and beta testing. (8)
4. What do you mean by integration testing? Explain their outcomes: (16)
5. What is black box testing? Is it necessary to perform this? Explain various test activities: (16)
6. Explain the integration testing process and system testing process and discuss their outcomes:
(16)
7. a) What do you mean by system testing? Give a case study of a system testing for operating
system? (8)
b) What do you mean by boundary value analysis? Give two examples of boundary value
testing.(8)
8. Explain black box testing methods and its advantages and disadvantages. (16)
9. Write short notes on
a) Data flow testing. (8)
b) Integration testing. (8)
10. a) Explain the testing procedures for boundary conditions.(8)
 b) Describe verification and validation criteria for a software. (8)
11. a) Describe unit testing and integration testing. How test plans are generated? (8)
b) Suggest software testing sequence for a 100% bug free software. Explain. (8)
12. Discuss software failures and faults? What are test coverage criteria? Discuss testing issues:
(16)
13. Explain automated testing tools. How test cases are generated? Discuss when to stop testing?
What is performance testing? Describe.(16)
14. What are the various testing strategies to software testing? Discuss them briefly:(16)

UNIT V- SOFTWARE PROJECT MANAGEMENT

Part A (2 MARKS)
1. List out the importance of cost estimation in software development.
2. Mention the advantages of CASE tools.
3. How do you estimate time required for a software development project?
4. Draw the structure of CASE REPOSITORY and explain.
5. What is meant by software change?
6. Write short notes on empirical estimation models.
7. Why the software needs maintenance?
8. Define software re-engineering.
9. List any 4 categories of CASE tools.
10. What is Delphi cost estimation technique?
11. What is CASE?
Part B
1. Explain the need for software measures and describe various metrics. (16)
2. Discuss briefly on software maintenance activities and how do you estimate the cost involved.
(16)
3. a) Explain in detail about the maintenance process.(8)
b) Discuss in detail about software evolution. (8)
4. Describe two metrics which are used to measure the software in detail. Discuss clearly the
advantages and disadvantages of these metrics. (16)
5. a) What is Halsted’s software science metric. Define. (8)
b) Explain about function point metric in detail. (8)
6. Write short notes on
a) Software maintenance (8)
b) Task scheduling with an example. (8)
7. Explain various cost estimation models and compare. (16)
8. Write briefly on
a) CASE (8)
b) Software complexity measure. (8)
9. Explain the maintenance activities and maintenance problems. How the cost of maintenance is
estimated? (16)
10. Write short notes on
a) COCOMO estimation criteria. (8)
b) Software metrics (8)
11. a) Justify the statement “Software maintenance is costlier”. (8)
b) Discuss the concept of software maintenance process. (8)