18   Fundamentals of Software Engineering Introduction  19

into many small parts. However, it is very important to understand that any arbitrary 1.4.1  Early Computer Programming
decomposition of a problem into small parts would not help. The different parts after
Early commercial computers were very slow and too elementary as compared to today’s
decomposition should be more or less independent of each other. That is, to solve one
standards. Even simple processing tasks took considerable computation time on those
part you should not have to refer and understand other parts. If to solve one part you
computers. No wonder that programs at that time were very small in size and lacked
would have to understand other parts, then this would boil down to understanding all the
sophistication. Those programs were usually written in assembly languages. Program
parts together. This would effectively reduce the problem to the original problem before
lengths were typically limited to about a few hundreds of lines of monolithic assembly
decomposition (the case when all the sticks tied together). Therefore, it is not sufficient to
code. Every programmer developed his own individualistic style of writing programs
just decompose the problem in any way, but the decomposition should be such that the
according to his intuition and used this style ad hoc while writing different programs. In
different decomposed parts must be more or less independent of each other.
simple words, programmers wrote programs without formulating any proper solution
As an example of a use of the principle of decomposition, consider the following.
strategy, plan, or design a jump to the terminal and start coding immediately on hearing
You would understand a book better when the contents are decomposed (organised)
out the problem. They then went on fixing any problems that they observed until they
into more or less independent chapters. That is, each chapter focuses on a separate
had a program that worked reasonably well. We have already designated this style of
topic, rather than when the book mixes up all topics together throughout all the pages.
programming as the build and fix (or the exploratory programming) style.
Similarly, each chapter should be decomposed into sections such that each section
discusses a different issue. Each section should be decomposed into subsections and so
on. If various subsections are nearly independent of each other, the subsections can be 1.4.2  High-level Language Programming
understood one by one rather than keeping on cross referencing to various subsections Computers became faster with the introduction of the semiconductor technology in the
across the book to understand one. early 1960s. Faster semiconductor transistors replaced the prevalent vacuum tube-based
circuits in a computer. With the availability of more powerful computers, it became
Why study software engineering? possible to solve larger and more complex problems. At this time, high-level languages
Let us examine the skills that you could acquire from a study of the software such as FORTRAN, ALGOL, and COBOL were introduced. This considerably reduced
engineering principles. The following two are possibly the most important skill you the effort required to develop software and helped programmers to write larger programs
could be acquiring after completing a study of software engineering: (why?). Writing each high-level programming construct in effect enables the programmer
to write several machine instructions. Also, the machine details (registers, flags, etc.) are
„„ The skill to participate in development of large software. You can meaningfully
abstracted from the programmer. However, programmers were still using the exploratory
participate in a team effort to develop a large software only after learning the
style of software development. Typical programs were limited to sizes of around a few
systematic techniques that are being used in the industry.
thousands of lines of source code.
„„ You would learn how to effectively handle complexity in a software development
problem. In particular, you would learn how to apply the principles of abstraction
and decomposition to handle complexity during various stages in software 1.4.3  Control Flow-based Design
development such as specification, design, construction, and testing. As the size and complexity of programs kept on increasing, the exploratory programming
Besides the above two important skills, you would also be learning the techniques of style proved to be insufficient. Programmers found it increasingly difficult not only to
software requirements specification user interface development, quality assurance, testing, write cost-effective and correct programs, but also to understand and maintain programs
project management, maintenance, etc. written by others. To cope up with this problem, experienced programmers advised other
As we had already mentioned, small programs can also be written without using programmers to pay particular attention to the design of a program’s control flow structure.
software engineering principles. However even if you intend to write small programs, the In order to help develop programs having good
software engineering principles could help you to achieve higher productivity and at control flow structures, the flow charting technique was A program’s control flow
the same time enable you to produce better quality programs. developed. Even today, the flow charting technique is structure indicates the sequence
being used to represent and design algorithms; though in which the program’s
the popularity of the flow charting technique to represent instructions are executed.
1.4  EMERGENCE OF SOFTWARE ENGINEERING and design programs has diminished due to the emergence
We have already pointed out that software engineering techniques have evolved over many of more advanced techniques.
years in the past. This evolution is the result of a series of innovations and accumulation of Figure 1.9 illustrates two alternate ways of writing program code for the same
experience about writing good quality programs. Since these innovations and programming problem. The flow chart representations for the two program segments of Figure 1.9 are
experiences are too numerous, let us briefly examine only a few of these innovations drawn in Figure 1.10. Observe that the control flow structure of the program segment in
and programming experiences which have contributed to the development of the software Figure 1.10(b) is much simpler than that of Figure 1.10(a). By examining the code, it can be
engineering discipline. seen that Figure 1.10(a) is much harder to understand as compared to Figure 1.10(b).
20   Fundamentals of Software Engineering Introduction  21

understand the execution of the program along the paths 1-2-3-7-8-10, 1-4-5-6-9-10, and
1-4-5-2-3-7-8-10. A program having a messy control flow (i.e. flow chart) structure, would
have a large number of execution paths (see Figure 1.11). Consequently, it would become
extremely difficult to determine all the execution paths,
and tracing the execution sequence along all the paths A programmer trying to
trying to understand them can be nightmarish. It is understand a program would
therefore evident that a program having a messy flow have to mentally trace and
chart representation would indeed be difficult to understand understand the processing that
and debug. take place along all the paths of
the program making program
Are GO TO statements the culprits? understanding and debugging
In a landmark paper, Dijkstra [1968] published his (now extremely complicated.
FIGURE 1.9  An example of (a) Unstructured program (b) Corresponding structured program. famous) article “GO TO Statements Considered Harmful”.
This example corroborates the fact that if the flow chart representation is simple, then He pointed out that unbridled use of GO TO statements is the main culprit in making
the corresponding code should be simple. You can draw the flow chart representations of the control structure of a program messy. To understand his argument, examine Figure
several other problems to convince yourself that a program with complex flow chart 1.11 which shows the flow chart representation of a program in which the programmer
representation is indeed more difficult to understand and maintain. has used rather too many GO TO statements. GO TO statements alter the flow of
control arbitrarily, resulting in too many paths. But, then why does use of too many GO
TO statements makes a program hard to understand?

FIGURE 1.10  Control flow graphs of the programs of Figures 1.9(a) and (b).

Let us now try to understand why a program having good control flow structure would
be easier to develop and understand. In other words, let us understand why a program
with a complex flow chart representation is difficult to understand? The main reason behind
this situation is that normally one understands a program by mentally tracing its execution
sequence (i.e. statement sequences) to understand how the output is produced from the
input values. That is, we can start from a statement producing an output, and trace back
the statements in the program and understand how they produce the output by transforming
the input data. Alternatively, we may start with the input data and check by running FIGURE 1.11  CFG of a program having too many GO TO statements.
through the program how each statement processes (transforms) the input data until the
output is produced. For example, for the program of Figure 1.10(a) you would have to Soon it became widely accepted that good programs should have very simple control
structures. It is possible to distinguish good programs from bad programs by just visually
22   Fundamentals of Software Engineering Introduction  23

examining their flow chart representations. The use of flow charts to design good control Very soon several languages such as PASCAL, MODULA, C, etc., became available
flow structures of programs became wide spread. which were specifically designed to support structured programming. These programming
languages facilitated writing modular programs and programs having good control
Structured programming—a logical extension structures. Therefore, messy control structure was no longer a big problem. So, the focus
The need to restrict the use of GO TO statements was recognised by everybody. However, shifted from designing good control structures to designing good data structures for
many programmers were still using assembly languages. JUMP instructions are frequently programs.
used for program branching in assembly languages. Therefore, programmers with assembly
language programming background considered the use of GO TO statements in programs 1.4.4  Data Structure-oriented Design
inevitable. However, it was conclusively proved by Bohm and Jacopini [1966] that only three
Computers became even more powerful with the advent of integrated circuits (ICs) in the
programming constructs—sequence, selection, and iteration—were sufficient to express any
early seventies. These could now be used to solve more complex problems. Software
programming logic. This was an important result—it is considered important even today.
developers were tasked to develop larger and more complicated software. This often
An example of a sequence statement is an assignment statement of the form a=b;. Examples
required writing in excess of several tens of thousands of lines of source code. The control
of selection and iteration statements are the if-then-else and the do-while statements
flow-based program development techniques could not be used satisfactorily any more to
respectively. Gradually, everyone accepted that it is indeed possible to solve any programming
write those programs, and more effective program development techniques were needed.
problem without using GO TO statements and that indiscriminate use of GO TO statements
It was soon discovered that while developing a
should be avoided. This formed the basis of the structured programming methodology. Using data structure-oriented
program, it is much more important to pay attention to the
Structured programs avoid unstructured control flows design techniques, first a
design of the important data structures of the program than
by restricting the use of GO TO statements. Structured A program is called structured program’s data structures are
to the design of its control structure. Design techniques
programming is facilitated, if the programming language when it uses only the sequence, designed. The code structure
based on this principle are called data structure-oriented
being used supports single-entry, single-exit program selection, and iteration types of is designed based on the data
design techniques.
constructs such as if-then-else, do-while, etc. Thus, constructs and is modular. structure.
In the next step, the program design is derived from
an important feature of structured programs is the design
the data structure. An example of a data structure-oriented
of good control structures. An example illustrating this key difference between structured
design technique is the Jackson’s Structured Programming (JSP) technique developed by
and unstructured programs is shown in Figure 1.9. The program in Figure 1.9(a) makes use
Michael Jackson [1975]. In JSP methodology, a program’s data structure is first designed
of too many GO TO statements, whereas the program in Figure 1.9(b) makes use of none.
using the notations for sequence, selection, and iteration. The JSP methodology provides
The control flow diagram of the program making use of GO TO statements is obviously
an interesting technique to derive the program structure from its data structure
much more complex as can be seen in Figure 1.10.
representation. Several other data structure-based design techniques were also developed.
Besides the control structure aspects, the term structured program is being used to denote
Some of these techniques became very popular and were extensively used. Another
a couple of other program features as well. A structured program should be modular. A
technique that needs special mention is the Warnier-Orr Methodology [1977, 1981].
modular program is one which is decomposed into a set of modules1 such that the modules
However, we will not discuss these techniques in this text because now-a-days these
should have low interdependency among each other. We discuss the concept of modular
techniques are rarely used in the industry and have been replaced by the data flow-based
programs in Chapter 5.
and the object-oriented techniques.
But, what are the main advantages of writing structured programs compared to the
unstructured ones? Research experiences have shown that programmers commit less
number of errors while using structured if-then-else and do-while statements than 1.4.5  Data Flow-oriented Design The data flow-oriented
when using test-and-branch code constructs. Besides being less error-prone, structured As computers became still faster and more powerful techniques advocate that the
programs are normally more readable, easier to maintain, and require less effort to develop with the introduction of very large scale integrated (VLSI) major data items handled by a
compared to unstructured programs. The virtues of structured programming became Circuits and some new architectural concepts, more system must be identified and
widely accepted and the structured programming concepts are being used even today. complex and sophisticated software were needed to the processing required on
However, violations to the structured programming feature is usually permitted in certain solve further challenging problems. Therefore, software these data items to produce
specific programming situations, such as exception handling, etc. developers looked out for more effective techniques for the desired outputs should be
designing software and soon data flow-oriented techniques determined.
1
In this text, we shall use the terms module and module structure to loosely mean the following—A were proposed.
module is a collection of procedures and data structures. The data structures in a module The functions (also called as processes) and the data items that are exchanged between
are accessible only to the procedures defined inside the module. A module forms an the different functions are represented in a diagram known as a data flow diagram (DFD).
independently compilable unit and may be linked to other modules to form a complete
application. The term module structure will be used to denote the way in which different
The program structure can be designed from the DFD representation of the problem.
modules invoke each other’s procedures.
24   Fundamentals of Software Engineering Introduction  25

DFDs: A crucial program representation for procedural program design lower development cost, more robust code, and easier maintenance. OOD techniques are
discussed in Chapters 7 and 8.
DFD has proven to be a generic technique which is being used to model all types of
systems, and not just software systems. For example, Figure 1.12 shows the data-flow
representation of an automated car assembly plant. If you have never visited an automated 1.4.7  What Next?
car assembly plant, a brief description of an automated car assembly plant would be In this section, we have so far discussed how software design techniques have evolved since
necessary. In an automated car assembly plant, there are several processing stations (also the early days of programming. We pictorially summarise this evolution of the software
called workstations) which are located along side of a conveyor belt (also called an assembly design techniques in Figure 1.13. It can be observed that in almost every passing decade,
line). Each workstation is specialised to do jobs such as fitting of wheels, fitting the engine, revolutionary ideas were put forward to design larger and more sophisticated programs,
spray painting the car, etc. As the partially assembled program moves along the assembly and at the same time the quality of the design solutions improved. But, what would the
line, different workstations perform their respective jobs on the partially assembled next improvement to the design techniques be? It is very difficult to speculate about the
software. Each circle in the DFD model of Figure 1.12 represents a workstation (called developments that may occur in the future. However, we have already seen that in the past,
a process or bubble). Each workstation consumes certain input items and produces certain the design technique have evolved each time to meet the challenges faced in developing
output items. As a car under assembly arrives at a workstation, it fetches the necessary contemporary software. Therefore, the next development would most probably occur to
items to be fitted from the corresponding stores (represented by two parallel horizontal help meet the challenges being faced by the modern software designers.
lines), and as soon as the fitting work is complete passes on to the next workstation. It
is easy to understand the DFD model of the car assembly plant shown in Figure 1.12
even without knowing anything regarding DFDs. In this regard, we can say that a major
advantage of the DFDs is their simplicity. In Chapter 6, we shall study how to construct
the DFD model of a software system. Once you develop the DFD model of a problem,
data flow-oriented design techniques provide a rather straight forward methodology to
transform the DFD representation of a problem into an appropriate software design. We
shall study the data flow-based design techniques in Chapter 6.

FIGURE 1.12  Data flow model of a car assembly plant.

1.4.6  Object-oriented Design

Data flow-oriented techniques evolved into object-oriented design (OOD) techniques in the
late seventies. Object-oriented design technique is an intuitively appealing approach, where
the natural objects (such as employees, pay-roll-register, etc.) relevant to a problem are first
identified and then the relationships among the objects such as composition, reference, and
inheritance are determined. Each object essentially acts as a data hiding (also known as data
abstraction) entity. Object-oriented techniques have gained wide spread acceptance because
of their simplicity, the scope for code and design reuse, promise of lower development time, FIGURE 1.13  Evolution of software design techniques.
26   Fundamentals of Software Engineering

To get an indication of the techniques that are likely to emerge, let us first examine what
are the current challenges in designing software. First, program sizes are further increasing
as compared to what was being developed a decade back. Second, many of the present day
software are required to work in a client-server environment through a web browser-based
access (called web-based software). At the same time, embedded devices are experiencing
an unprecedented growth and rapid customer acceptance in the last decade. It is there
for necessary for developing applications for small hand held devices and embedded
processors. We examine later in this text how aspect-oriented programming, client-server
based design, and embedded software design techniques have emerged rapidly. In the
current decade, service-orientation has emerged as a recent direction of software engineering
due to the popularity of web-based applications and public clouds.

1.4.8  Other Developments

It can be seen that remarkable improvements to the prevalent software design technique
occurred almost every passing decade. The improvements to the software design
methodologies over the last five decades have indeed been remarkable. In addition to the
advancements made to the software design techniques, several other new concepts and
techniques for effective software development were also introduced. These new techniques
include life cycle models, specification techniques, project management techniques, testing
techniques, debugging techniques, quality assurance techniques, software measurement
techniques, computer aided software engineering (CASE) tools, etc. The development of these
techniques accelerated the growth of software engineering as a discipline. We shall discuss
these techniques in the later chapters.

1.5  NOTABLE CHANGES IN SOFTWARE DEVELOPMENT PRACTICES

Before we discuss the details of various software engineering principles, it is worthwhile
to examine the glaring differences that you would notice when you observe an exploratory
style of software development and another development effort based on modern software
engineering practices. The following noteworthy differences between these two software
development approaches would be immediately observable.
„„ An important difference is that the exploratory software development style is based
on error correction (build and fix) while the software engineering techniques are based
on the principles of error prevention. Inherent in the software engineering principles
is the realisation that it is much more cost-effective to prevent errors from occurring
than to correct them as and when they are detected. Even when mistakes are
committed during development, software engineering principles emphasize detection
of errors as close to the point where the errors are committed as possible (this topic
is discussed in more detail in Section 2.3 of the next chapter). In the exploratory style,
errors are detected only during the final product testing. In contrast, the modern
practice of software development is to develop the software through several well-
defined stages such as requirements specification, design, coding, testing, etc., and
attempts are made to detect and fix as many errors as possible in the same phase
in which they are made.
„„ In the exploratory style, coding was considered synonymous with software
development. For instance, this naive way of developing a software believed in