A COMPREHENSIVE APPROACH TO SOFTWARE ENGINEERING

CHAPTER ONE
Description of Software

1.1 Software:
Software is defined as a collection of programs, procedures, rules, data and associated
documentation. The Software is developed keeping in mind certain Hardware and operating system
consideration commonly known as platform. Engineering means systematic procedure to develop
software. Some of the software characteristics are, it can be engineered or developed.
1.1.1 Importance of software are due to much reason as it is used :
i)Business decision making
Example accounting software, billing software
ii)For scientific research & engineering purposes
Example is weather forecasting system, space research software
iii)It is embedded in multifunctional systems such as medical, telecom entertainment etc.

1.2 Types of software:-

Computer software is mainly divided into two types.
a)system software
System software includes the operating system & all the utilities to enable the computer to run.
Example is window operating system
b)application software
Application software consists of programs to perform user oriented tasks. Example is word
processor, database management, spreadsheet packages. Application software sits on the system
software because it needs help of the system software to run.
1.3 Software 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.

1
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.
1.4 Program vs Software product

PROGRAMS PRODUCTS
Set of instruction related each other Programs are defined by individuals
for
their personal use.
Collection of program designed for A sum product is usually developed
by a
Specific Task. 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 User Interface. Good User Interface.
Have limited functionality. Exhibit more functionality

Source code, object code programs, operating procedures

documentation

1.4.1 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)
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

CHAPTER TWO

Software Engineering Principles

2.1 Software Engineering: This is the application of engineering for
development. It is the systematic, innovative technique and cost effective

2
approach to develop software. Any person involved in developing product is called
software engineer. S/w engineer is a licensed professional engineer who is skilled
in engineering discipline.
IEEE definition of Software engineering: A systematic, disciplined and
quantifiable
approach to the development, operation, maintenance and refinement of software.

2.2 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)

2.3 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.
Software engineering methods rely on a set of basic principles that govern each
area of the technology and include modeling activities and other descriptive

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

2.4 S/W CRISIS

There were many difficulties in the development of large software system during
the 1960s and 1070. The term “Software Crisis” dates from that time. The
problems stemmed from an inability to apply the techniques used to build small
software systems to the development of large and more complex systems. The
typical way to develop small system can be described as “code and fix”.

2.4.1 The code-and-fix approach to software development

The “code-and-fix” approach to software development is not a proper life cycle (see later this unit).
Code-and-fix development occurs when software engineers come together with a vague set of
requirements and start producing software, fixing it, and changing it until the correct product
appears.

4
Figure 2.1. The code-and-fix approach

This is the simplest way to produce software and is invariably how every programmer learns to
program. But for anything other than small software projects, code-and-fix is a disaster for a
number of reasons:

 There is no way to estimate time-scales or budgets.

There is no assessment of possible risks and design flaws: you may come close to a finished
product only to find an insurmountable technical problem which sets the whole Many project
failures resulted from the inability to scale the techniques employed when developing small
software systems to handle larger, more complex systems. This failure leads to:

 never completed systems

 missed deadlines

 exceeded budgets

 a system that does not do all that is required of it

5
  a system that works but is difficult to use

 a system difficult to modify to meet changes in organizational needs and practices

 a loss of trust from users, who may experience many problems with using the software.

These problems were largely due to the lack of any framework for the planning and organization of
software development projects. Although some software projects were organized, and these were
often the more successful ones, it was the luck of the draw whether a project manager had good
intuitions for software development, and whether or not problems arose due to misunderstandings
between the customers and the developers of the system. Likewise, there were no clear methods to
monitor whether a system was soon to go over budget or miss deadlines.

From some of these problems we can see that at some stage the system developers attempted (not
always successfully) to understand the requirements for the new system. We can now include in our
diagram of the process these specified requirements for the new system:

Figure 2.2. The process with requirements

Software crisis from programmer point of view:-

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

6
Software 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

2.5 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 software 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 software engineering while executing the software process are .
i) software specification
The functionality of software & constraints on its operation must be defined.
ii)software development

7
CHAPTER THREE

3.1 SOFTWARE 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.
3.2 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:
a. Classical Waterfall Model
b. Iterative Waterfall Model
c. Prototyping Model
d. Evolutionary Model
e. Spiral Model

3.2a. Classical Waterfall Model:

8
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

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

9
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
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: -

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

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

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

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

13
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:

e. SPIRAL MODEL/RISK MANAGEMENT MODEL:-

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

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

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

4.1a)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.

4.1b) 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.
4.2 Functional requirements:-

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

4.3 Properties of a good SRS document

• Some of the important properties of a good SRS document are the following:
a)Concise:

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

4.5 CHARACTERISTICS OF BAD SRS:-

18
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.
Example:- 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.
(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. Software developers
3. Test engineers
4. User documentation writers
5. Project managers
6. Maintenance Engineer
4.6 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. Moreso, 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.

19
• It establishes 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
Example below:
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.

pre: x ∈ R
f (x : real) : real

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

20
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)
36 *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

21
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 is equal). Therefore, there are only 3 equations

22
CHAPTER FIVE
Agile Software development
Agile is a time – bound, iterative approach to software delivery that builds software
incrementally from the start of the project, instead of trying to deliver all at once.
Why Agile?
Technology in this current era is progressing faster that ever, enforcing the global
software companies to work in a fast- paced changing environment. Because these
businesses are operating in an ever changing environment, it is impossible to
gather a complete and exhaustive set of software requirements. Without theses
requirements, it becomes practically hard for any conventional software to work.
The conventional software models such as Waterfall Model that depends on completely
specifying the requirements, designing, and testing the system are not geared towards
rapid software development. As a consequence, a conventional software development
model fails to deliver the required product. This is where the agile software development
comes to the rescue. It was specially designed to create the needs of the rapidly changing
environment by embracing the idea of incremental development and develop the actual
final product.

Principles:
1.Highest priority is to satisfy the customer through early and continuous delivery of
valuable
software.
2. It welcomes changing requirements, even late in development.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with
a
preference to the shortest timescale.
4. Build projects around motivated individuals. Give them the environment and the
support they need, and trust them to get the job done.
5. Working software is the primary measure of progress.
6. Simplicity the art of maximizing the amount of work not done is essential.
7. The most efficient and effective method of conveying information to and within a
development
team is face-to-face conversation.

Development in Agile: Let’s see a brief overview of how development occurs in Agile
philosophy.
In Agile development, Design and Implementation are considered to be the central
activities in the
software process.
Design and Implementation phase also incorporate other activities such as requirements
elicitation
and testing into it. In an agile approach, iteration occurs across activities. Therefore, the
requirements and the design are developed together, rather than separately.
The allocation of requirements and the design planning and development as executed in a
series of
increments. In contrast with the conventional model, where requirements gathering needs
to be

23
completed in order to proceed to the design and development phase, it gives Agile
development an
extra level of flexibility.
An agile process focuses more on code development rather than documentation.
Example: Let’s go through an example to understand clearly about how agile actually
works.
A Software company named ABC wants to make a new web browser for the latest release
of its
operating system. The deadline for the task is 10 months. The company’s head assigned
two teams
named Team A and Team B for this task. In order to motivate the teams, the company
head says that the first team to develop the browser would be given a salary hike and a
one week full sponsored travel plan. With the dreams of their wild travel fantasies, the two
teams set out on the journey of the web browser. The team A decided to play by the book
and decided to choose the Waterfall model for the development. Team B after a heavy
discussion decided to take a leap of faith and choose Agile as their development model.
The Development plan of the Team A is as follows:
Requirement analysis and Gathering – 1.5 Months
Design of System – 2 Months
Coding phase – 4 Months
System Integration and Testing – 2 Months
User Acceptance Testing – 5 Weeks
The Development plan for the Team B is as follows:
Since this was an Agile, the project was broken up into several iterations.
The iterations are all of the same time duration.
At the end of each iteration, a working product with a new feature has to be delivered.
Instead of Spending 1.5 months on requirements gathering, They will decide the core
features that
are required in the product and decide which of these features can be developed in the
first iteration.
Any remaining features that cannot be delivered in the first iteration will be delivered in
the next
subsequent iteration, based in the priority. At the end of the first iterations, the team will
deliver a working software with the core basic features.
Both the team have put their best efforts to get the product to a complete stage. But then
out of blue due to the rapidly changing environment, the company’s head come up with an
entirely new set of features and want to be implemented as quickly as possible and
wanted to push out a working model in 2 days. Team A was now in a fix, they were still in
their design phase and did not yet started coding and they had no working model to
display. And moreover, it was practically impossible for them to implement new features
since waterfall model there is not reverting back to the old phase once you proceed to the
next stage, that means they would have to start from the square one again. That would
incur them heavy cost and a lot of overtime. Team B was ahead of Team A in a lot of
aspects, all thanks to Agile Development.
They also had the working product with most of the core requirement since the first
increment. And it
was a piece of cake for them to add the new requirements. All they had to do is schedule
these
requirements for the next increment and then implement them.
Advantages:
1.Deployment of software is quicker and thus helps in increasing the trust of the customer.
2.Can better adapt to rapidly changing requirements and respond faster.

24
3.Helps in getting immediate feedback which can be used to improve the software in the
next
increment.
4.People – Not Process. People and interactions are given a higher priority rather than
process and
tools.
5.Continuous attention to technical excellence and good design.
Disadvantages:
1.In case of large software projects, it is difficult to assess the effort required at the initial
stages of
2.the software development life cycle.
3.The Agile Development is more code focused and produces less documentation.
4.Agile development is heavily depended on the inputs of the customer. If the customer
has ambiguity in his vision of the final outcome, it is highly likely for the project to get off
track.
5.Face to Face communication is harder in large-scale organizations.
6.Only senior programmers are capable of taking the kind of decisions required during the
development process. Hence it’s a difficult situation for new programmers to adapt to the
environment.
7.Agile is a framework which defines how the software development needs to be carried
on. Agile is not a single method, it represents the various collection of methods and
practices that follow the value statements provided in the manifesto. Agile methods and
practices do not promise to solve every problem present in the software industry (No
Software model ever can). But they sure help to establish a culture and environment
where solutions emerge.

CHAPTER SIX
SOFTWARE ENGINEERING ETHICS
OVERVIEW
Software engineering ethics can be approached from three directions. First, it can
describe the activity of software engineers making practical choices that affect other
people in significant ways. Second, it can be used to describe a collection of principles,
guidelines, or ethical imperatives that guide or legislative action, and third, it can be used
to name a discipline that studies the relationship between the other two senses of ethics.
Software engineering ethics is clearly both an activity and a body of principles. The
discipline of software engineering ethics that studies this activity and formalizes these
principles, however, is in its infancy.
Software Engineering Ethical Activity
To avoid confusion, “ethics”, as understood here, addresses any intentional action that
impacts negatively or positively the lives and values of others. Software engineering
conceives of itself primarily as a technical discipline that develops software. There are a
variety of names, such as information systems analyst, for those who engage in
professional software development. Regardless of the title used, the focus of software
engineering activity is primarily on the technical adequacy of the products developed. But

25
the fact that roughly one billion people depend on software systems to effectively conduct
their daily lives (Reed, 2000) has led many in computing to give more attention to the nontechnical
aspects and to wrestle with the ethical impact of their daily decisions and the
values imbedded therein. The relationship between computers and ethics can be
described as occurring when humans make decisions about computers, and those
decisions affect people's lives. Human values are linked to technical decisions in this way.
The activity of Professional Software Engineering Ethics takes place when any decision
made by computing professionals during the design, development, construction and
maintenance of computing artifacts affect other people. These decisions may be made by
individuals, teams, management, or the profession. The software engineering decision
how to design the release of an airbag will affect the lives of others. This technical
decision is also guided by an ethical decision about human values. Barry Boehm (1981)
begins his work on software engineering economics with an anecdote about how the
failure to consider human values affected the development of software for a high school
attendance system. His work on this project led him to see that software engineers have
"… an opportunity to make a significant positive impact on society, simply by becoming
more sensitive to the long-term human relations implications of our work and incorporating
this sensitivity into our software designs and products." (Boehm, 1981)
Software Engineering Ethical Principles
The ethical activity involved in technical decisions should be based on an understanding
of the impact of those decisions. Often decisions are made while only looking at the
technical issues, but those decisions impact others in negative and positive ways. A good
software engineering decision requires an awareness of and a careful consideration of

both the technical and the ethical dimensions The technical decisions should be
consciously guided by values. An absence of the awareness of this relationship between
technology and values means that the values related to the technology are haphazard.
Professions describe these values in Codes of Ethics, Codes of Conduct and Codes of
Practice. These codes serve many functions related to a profession including providing
guidance for practitioner’s ethical choices and educating practitioners and the public about
the ethical standard of the profession.
Codes of ethics are statements about the interaction of technology and values. They are
also intended to insure that this interaction is not haphazard. Some codes, such as the
Australian Computer Society Code of Ethics carries legal weight to insure structured
interaction, while other codes, such as the Software Engineering Code of Ethics and
Professional Practice, rely on normative pressures. The goal of all of these codes is to
make sure that the activity of practicing professionals as individual, teams, management,
or professional organizations, advance and protect human values rather than do damage
to them.
The Discipline of Software Engineering Ethics
The discipline of software engineering ethics studies the interaction of the ethical
principles and technology to examine the ways in this which this interaction affects
society, its citizens, and software engineering products. As a discipline, software
engineering ethics illustrates, refines and further explores the relationship between these
principles and the developing technical practice.
Development of Software Engineering Ethics
Software engineering is an emerging profession, which is self-conscious of its impact on
26
society and its resulting obligations. The fact that computing has a significant daily impact
on the lives of billions of people has led many in computing to wrestle with their ethical
obligations. In the 1990s many organizations have revisited their codes of conduct or
codes of ethics and revised them in a way that more clearly states an ethical obligation to
the public at large. For example, the Association for Computing Machinery (ACM), the
Australian Computer Society, the British Computer Society (BCS) , the IEEE Computer
Society (IEEE-CS) , and the New Zealand Computer Society have all refined their Codes
of Ethics. A broad based effort to professionalize software engineering was started by the
IEEE Computer Society, and later joined by the ACM (Gotterbarn a, 1996). The initial
goals of this organization were to:
1. Adopt Standard Definitions
2. Define Required Body of Knowledge and Recommended Practices (in electrical
engineering, for example, electromagnetic theory is part of the body of knowledge
while the National Electrical Safety Code is a recommended practice.)
3. Define Ethical Standards
4. Define Educational Curricula for (a) undergraduate, (b) graduate (MS), and (c)
continuing education (for retraining and migration). (Gotterbarn b, 1996)

These goals are consistent with the goals of other professions. One of the key elements
in any profession is the recognition of its ethical and moral responsibilities to its clients, to
society, and to the profession itself. Many professions, such as engineering and
medicine, declare these responsibilities publicly in a code of ethics and then later require
training in professional ethics in order to enter the profession. For example, the IEEE-CS
Certification as a Software Engineering Professional requires adherence to the Software
Engineering Code of Ethics and Professional Practice.
However, this interest in ethics was not always a major element of software engineering.
Software engineering had defined itself as "the establishment and use of sound
engineering principles [methods] in order to obtain economically software that is reliable
and works on real machines."(Bauer, 1972) does not explicitly point to the existence of
ethical issues. The IEEE Standard 610.12 definition also has the same lacuna.

These responsibilities formulated in the Software Engineering Code of Ethics and

Professional Conduct (SECODE 1999) were summarized as:
Software engineers shall commit themselves to making the analysis, specification,
design, development, testing and maintenance of software a beneficial and
respected profession. In accordance with their commitment to the health, safety
and welfare of the public, software engineers shall adhere to the following Eight
Principles:
1 PUBLIC - Software engineers shall act consistently with the public interest.

2 CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in

the best interests of their client or employer and that is consistent with the public
interest.
3 PRODUCT - Software engineers shall ensure that their products and related
modifications meet the highest professional standards possible.
4 JUDGMENT - Software engineers shall maintain integrity and independence in
their professional judgment.

27
5 MANAGEMENT - Software engineering managers and leaders shall subscribe to
and promote an ethical approach to the management of software development and
maintenance.
6 PROFESSION - Software engineers shall advance the integrity and reputation of
the profession consistent with the public interest.
7 COLLEAGUES - Software engineers shall be fair to and supportive of their
colleagues.
8 SELF - Software engineers shall participate in lifelong learning regarding the
practice of their profession and promote an ethical approach to the practice of the
profession.
This set of principles, developed and reviewed by software engineers from every continent
expresses the software engineers commitment to a level of professional care. The
professionalization of any discipline involves the realization that being a professional
involves more than the rigid application of the most recent technology to the artifacts of
that discipline (Ford, 1996). The practice of medicine is more than the application of drugs
to the human body. Physicians are concerned with the well-being of their patients. The
professional architect does not merely apply principles of structural stress when designing
a building but is concerned with the effect of the design on the people who will be using
the building. In the professionalization of a discipline there is: 1) a realization of the
impact on society of the application of the special skills, 2) knowledge by the practitioner
of that profession’s standards and, 3) a realization of the responsibility that comes with the
privilege of being allowed to apply those skills.
This kind of realization in software engineering is seen in the definition offered by the
Software Engineering Institute. It defines software engineering as a "form of engineering
that applies the principles of computer science and mathematics to achieving costeffective
solutions to software problems(Ford, 1990)." But software engineering, as a
subset of engineering, is the creating and building of "cost-effective solutions to practical
problems in the service of mankind"(Ford, 1990). Ford goes on to point out explicitly that
cost-effective does not mean making something of marginal quality to minimize time and
resources, rather, "cost-effective ...implies getting good value for the resources invested;
this value includes quality (Ford, 1990).

SOFTWARE ENGINEERING ETHICS

Software engineering has been described as "The disciplined application of engineering,
scientific, and mathematical principles, methods, and tools to the economical production of
quality software” .(Humphrey, 1989). As a software engineer applies these principles,
human values become intertwined with technical decisions. Software engineering ethics
studies the interactions of human values and technical decisions involving computing.
Software engineering as an engineering-like discipline has a direct connection to ethics.

A MODEL FOR SOFTWARE ENGINEERING ETHICS

A consistent and manageable view of software engineering ethics is derived from a
concept of ethics as "a public system applying to all rational persons governing behavior
which affects others and which has the minimization of evil as its end..."(Gert, 1998). The
behavior of professional software engineers, in so far as it affects others, is guided by a
set of principles which are designed to minimize evil and encourage good. This definition
ties software engineering ethics to the individual rather than to machines. Furthermore,

28
using some elements of professional ethics as a model has the advantage of bringing
software engineering ethics within the horizon of action of the practice of the individual
moral software engineer. Software engineering ethics is a type of professional ethics.
Software engineering is often a profession practiced by teams in managed situations, so
as we shall see a complete concept of software engineering ethics includes ethical activity
and principles related to the action of teams and the actions of management.

ETHICS AND PROFESSIONAL ETHICS

General Ethics
In the first category, software engineering ethics participates in a very general sense of
ethics, which includes most human interaction. This is the concept of ethics as a means
to facilitate the interactions of people living in a society by placing obligations of action and
avoidance of action on them. In any given society ethics regulates individual behavior in
those circumstances where it cannot be or as yet has not been regulated by law. Ethics
depends entirely on voluntary acceptance of established rules and is not enforced by the
state. In this category, ethics has human well-being as one of its primary goals. Some
principles in this category include hurt no one, be honest, be fair, and keep your promises.
These are the moral foundations for our obligation to complete a contract and our
obligation to be concerned with the user of our artifacts. It also justifies management’s
obligation to “5.02. Ensure that software engineers are informed of standards before
being held to them.” (SE Code 1999)
Professional Ethics and General Ethics
The second category of professional ethics has elements in common with the first
category of general ethics. Some occupations, which have a significant impact on human
well being, require a high degree of special knowledge to produce a product or service.
People in these occupations are called professionals.
Professional ethics is a category of ethics that is required of all professionals, regardless
of their particular profession. Architects, doctors, engineers, and lawyers are all bound by
professional ethics. This broad sense of professional ethics is derived from the concept of
a profession. There are several marks of a professional. They generally include a special
skill or knowledge to produce a product or service, a commitment to public service, a
commitment to cause no harm, membership in a representative organization, adherence
to a code of ethics, being licensed by a representative organization, and autonomous
judgement based on this specialized knowledge (Ford, 1996). A profession is permitted
by society to lay exclusive claim to a body of knowledge because through the utilization of
the knowledge, society as a whole gains. This claim to exclusive knowledge is only
justified if indeed society does gain. In exchange for this exclusive claim, a profession
assumes an obligation to serve society (Bayles, 1981). These obligations are generally
articulated in professional codes of ethics.

The codes of ethics for civil engineers, the IEEE and the various computing societies
emphasize "the dignity and worth of other people, personal integrity and honesty,
responsibility for work...public safety health and welfare" (Martin, 1989).
Although software engineering does not meet all of these marks of a profession
mentioned above (Pour, 2000), it does meet those marks that are significant for
understanding how ethics is related to software engineering. There is a special skill and
training used to develop products which directly affect many lives and affects the way

29
software artifacts are used in society, and by virtue of that training one gains the power to
have a significant effect on society. The responsible application of software engineering
principles has a direct effect upon the public's well-being. These two fundamental facts
identify software engineering ethics as a professional ethics. Like medical professionals,
software engineers are privy to knowledge that is generally inaccessible to people outside
the profession. Like lawyers, software engineers have special obligations to clients,
obligations that may conflict with obligations to society at large. The difference here is the
software engineers owe their primary obligation to society rather than to the client. ” In all
these judgments concern for the health, safety and welfare of the public is primary; that
is, the “Public Interest” is central …” (SE Code, 1999) Software engineering ethics,
though uniquely tied to the technical details of computing, shares common ground with
other professional ethics.

Technical and Professional Ethics

The third category in this taxonomy of ethics -- technical ethics -- is different in each of the
professions. Although medical ethics and engineering ethics are examples of
"Professional Ethics", these two professions are quite different in the way that they
implement professional ethics. Each profession operates in a different context with
different tools and addresses different problems. Although there are some principles such
as "cause no harm" which are true across the professions, in this taxonomy category
different professions employ different ethical principles and give these principles different
priorities. The physician has a significant obligation to patient confidentiality, but this has
little relevance for the mechanical engineer. These technical standard and values are determined by
consensus within a profession
(Gotterbarn,1991;Collins,1994). Society trusts that the educated professionals are best
equipped to determine these principles because of their special knowledge. This is the
basis for self-regulation of the professions.
Software professionals have a set of standards they can follow and recent work has
shown that there is significant agreement about these technical and ethical standards
among software professionals. Within the realm of professional ethics there is a
surprising degree of agreement (Leventhal et. al., 1992).

30
CHAPTER SEVEN

Object Modeling using UML

The Unified Modeling language (UML) is a standard language for specifying,

visualizing, constructing and documenting the artifacts of software systems, as well
as for business modeling and other non software systems. The UML represents a
collection of best engineering practices that have proven successful in the modeling
of large and complex systems. The UML is a very important part of developing
object oriented software and the software development process. The UML uses
mostly graphical notations to express the design of software projects. Using the UML
help project teams, communicate, explore potential design and validate the
architectural design of the software.

Goals of UML

31
 1. It provide users with a ready to use, expressive visual modeling
language so they can develop and exchange meaningful models.
2. It provides extensibility and specialization mechanism to extend core
concepts.
3. Be independent of particular programming languages and development
processes.
4. Provide a formal basics for understanding the modeling language.
5. Encourage the growth of Object Oriented Tools market.
6. Support high level development concepts such as collaboration
framework, pattern and concepts.
7. Integrate best practices.
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:

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

33
c)use cases: are the actions that a user takes on a system. According to above
example
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.

34
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
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.
35
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.
Fig. 3: Representation of use case generalization
<<<Include>>>
This 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

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

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

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

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

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

40
Fig. 8: Sequence diagram for the renew book use case

Collaboration Diagram
Collaboration diagram is a cross between the class diagram and
sequence diagram. 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.

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

42
CHAPTER EIGHT
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.

43
The concepts of stronger and complementary testing are schematically illustrated
.

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

44
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
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 ((c1.and.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
45
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

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.

46
 Data abstraction is the reduction of a particular body of data to a simplified representation
of the whole. Abstraction, in general, is the process of taking away or removing
characteristics from something in order to reduce it to a set of essential characteristics.

polymorphism

47
In programming languages and type theory, polymorphism is the provision of a single
interface to entities of different types or the use of a single symbol to represent multiple
different types

The most commonly recognized major classes of polymorphism are:

 Ad hoc polymorphism: defines a common interface for an arbitrary set of individually

specified types.
 Parametric polymorphism: when one or more types are not specified by name but by
abstract symbols that can represent any type.
 Subtyping (also called subtype polymorphism or inclusion polymorphism): when a
name denotes instances of many different classes related by some common
superclass

Encapsulation

In object-oriented programming (OOP), encapsulation refers to the bundling of data with

the methods that operate on that data, or the restricting of direct access to some of an
object's components.

Inheritance in OOP

Inheritance is one of the most important aspects of Object Oriented Programming (OOP).
The key to understanding Inheritance is that it provides code re-usability. In place of writing
the same code, again and again, we can simply inherit the properties of one class into the
other. Inheritance is the procedure in which one class inherits the attributes and methods of
another class. The class whose properties and methods are inherited is known as the Parent
class. And the class that inherits the properties from the parent class is the Child class.

This, as you can imagine, saves a ton of time. And time is money in data science!

OOP is all about real-world objects and inheritance is a way of representing real-world
relationships. Here’s an example – car, bus, bike – all of these come under a broader
category called Vehicle. That means they’ve inherited the properties of class vehicles i.e all
are used for transportation.

We can represent this relationship in code with the help of inheritance.

48
Another intriguing thing about inheritance is that it is transitive in nature.

Encapsulation is used to hide the values or state of a structured data object inside a class,
preventing direct access to them by clients in a way that could expose hidden
implementation details or violate state invariance maintained by the methods.

Publicly accessible methods are generally provided in the class to access or modify the state
more abstractly. In practice sometimes methods (so-called "getters" and "setters") are
provided to access the values indirectly, but, although not necessarily a violation of abstract
encapsulation, they are often considered a sign-post of potentially poor object-oriented
programming (OOP) design practice (an Anti-pattern).

This mechanism is not unique to OOP. Implementations of abstract data types, e.g.,
modules, offer a similar form of encapsulation. The similarity has been explained by
programming language theorists in terms of existential types.

Aggregation in OOP
Aggregation in object oriented programming Aggregation is a specialized form of
association between two or more objects in which each object has its own life cycle but
there exists an ownership as well. Aggregation is a typical whole/part or parent/child
relationship but it may or may not denote physical containment.

49