Basics of Programming

Basics of Programming
The objective of this course is to introduce the concepts of programming, structure and
interpretation of computer programs and algorithms. This course is aimed at participants with
little or no programming experience. By the end of this course the participant should be
justifiably confident of their ability to write small programs that allow them to accomplish useful
goals
1.Introduction to Programming Page No.

1.1. What is programming 3
1.2. Why programming is required 7
2.Introduction to Computer Programs

2.1. Overview of Software Development 11
2.2. Overview of problem solving Techniques 18
2.3. Phases in the Execution of a Computer Program 24
3.Basic Programming Concepts

3.1. Introduction to basic programming concepts 26
3.2. Datatypes 26
3.3. Introduction to variables 27
3.4. Introduction to Operators 31
3.5. Control structures 32
3.6. Introduction to Arrays 34
3.7. Introduction to Functions 37
3.8. Composite Datatypes 41
4.Introduction to Developing a User Interface

4.1. Introduction to Developing a User Interface 44
4.2. What is the need for a good UI 48
4.3. Basic steps to be followed for developing a good UI 49
5.Programming Approaches
5.1. Structured Programming 61
5.2. Modular Programming 62
6.Code optimization techniques

6.1. Introduction to optimization 70
6.2. Code optimization strategy 71
6.3. Standard techniques list 71
6.4. Code optimization summary 77
7.Testing and Debugging

7.1. Introduction to Testing 79
7.2. Who does testing 79
7.3. Test approaches 80
1
ASPIRE 2014 ( Basics of Programming )
7.4. Levels of Testing 81
7.5. Test Techniques 84
7.6. When to start and stop testing 89
7.7. Debugging 91
8.Introduction to the SDLC and UML

8.1. Phases of Software Development Life Cycle 92
8.2. Introduction to the Unified Modeling Language 105
8.3. Developing Use-Case Diagrams 107
8.4. Examining Other UML Diagrams 114
2
1.Introduction to Programming
1.1. What is Programming?
A problem is defined as any question, something involving doubt, uncertainty, difficulty or a

situation whose solution is not immediately obvious. A situation which is a problem for one
person may not be a problem for another person. Figure 1.1 graphically represents the concept of
problem solving.
A Computer is a tool that can be used to solve problems by writing programs. Writing a program
without knowing the problem that we are trying to solve is like swinging a knife without
knowing what it is that we want to cut.
A program is a set of instructions that tells the computer how to do a task. When a computer
follows these instructions, we say it executes the program
Fig 1.1: Problem Solving
A programming language is a computer language that programmers use to develop applications.

An application is a set of instructions for a computer to execute. A set of rules that provides a
way of telling a computer what operations to perform is called a Program.
Programming is the process of designing, developing, testing, debugging and maintaining the
source code of computer programs. It is used to create a set of instructions that computers use to
perform specific operations or to exhibit desired behaviors. Source code can be written using
programming language such as C++, Java, Python, Smalltalk, C#, etc. The process of writing
source code often requires expertise in many different subjects, including knowledge of the
specialized algorithms, application domain and formal logic.
Within software engineering, programming (implementation) is considered as a phase in the

software development process.
The Programming Process
3
Developing a program involves different steps similar to any problem solving task. There are
five main steps in the programming process. They are as follows:
1. Defining the problem
2. Planning the solution
3. Coding the program
4. Testing the program
5. Documenting the program
Let us discuss each of these steps.
1. Defining the problem
As a programmer, you meet with end users from the client organization to analyze the problem,
or you meet with a systems analyst who outlines the project. Specifically, the task of defining the
problem consists of identifying what you know (input-given data), and what you want to obtain
(output-the result). Eventually, you create a document or an agreement that specifies the kind of
input, processing, and output required to complete the task.
2. Planning the solution
There are two ways that are commonly used to plan the solution to a problem. These are to draw
a flowchart and to write pseudo code, or both.
Pseudo code
Pseudo code is an English-like non-standard langauge that permits you to focus on the program
logic without having to be concerned about the precise syntax of a particular programming
language. However, pseudo code is not executable on the computer. It lets you state your
solution with more precision than plain English. However psuedo code has lesser precision than
is required when using a formal programming language. An example is given below: Example :
Read number n and print the integers counting up to n.
Read n
Initialize the variable i to 1
while i 'less than or equal to n' do
Print i
Increment i
4
end while
Stop
In the above example, the program enters the while loop only if the condition (i less than or
equal to n) is true. Two statements Print i and Increment i are executed for each iteration. At the
end of each iteration, the condition is evaluated again and the loop continues as long as the
condition is true.
Flowchart
It is a pictorial representation of a step-by-step solution to a problem. It consists of arrows

representing the direction the program takes and boxes and other symbols representing actions. It
is a map of the steps involved in a program. The American National Standards Institute (ANSI)
has come up with a standard set of flowchart symbols. The following figure shows the flowchart
symbols and how they might be used in a simple flowchart of an everyday action preparing a
letter for mailing.
Figure 1.2: Flowchart
5
3. Coding the program
As a programmer, your next step is to code the program to express the solution in a programming
language. You will translate the logic from the flowchart or pseudo code to a programming
language. As we have already discussed, a programming language is a set of rules that provides a
way of instructing the computer what operations to perform. There are many programming
languages such as BASIC, COBOL, Pascal, FORTRAN, C, etc.
Programming languages are precise like the English language. To get your program to work, you
have to follow the exact syntax (rules) of the language you are using. However, there is no
guarantee that your program will work because the syntax in programming language is correct.
The correctness of the language is the first step that you require. After that, the program must be
keyed, probably using a personal computer, in a form that the computer can understand.
4. Testing the program
Some experts claim that a well designed program can be written correctly the first time and there
are mathematical ways to prove that a program is correct. Most of the programs may have a few
bugs (errors) when executed for the first time. This is a little discouraging at first, since
programmers tend to be careful, precise and detail-oriented people who take pride in their work.
There are many ways in which mistakes or problems may happen in programs. You will
probably have made some of them. Eventually, after coding, we must prepare to test the program
on the computer.
Testing involves three phases:
1. Desk-checking
2. Translating
3. Debugging
Let us discuss each of them.
Desk-checking
This is similar to proofreading. This phase is sometimes avoided by the developer/programmer

who is looking for a shortcut and is eager to run the program on the computer once it is written.
However, with careful desk-checking we can identify several errors and possibly save our time
in the long run. In desk-checking, you simply sit down and mentally check or trace the logic of
the program in an attempt to ensure that it is error-free and is in workable condition. Many
organizations take this phase a step further called walk through, a process in which a group of
programmers review the program and make suggestions or comments in a collegial way.
6
Translating
A translator is a program that
I. Checks the syntax of the program to make sure that the programming language was used
correctly, giving you all the syntax related error messages called diagnostics, and
II. Then translates the program into a form which the computer can understand. A by-product of
the process is that the translator tells us if we have improperly used the programming language.
These mistakes are called syntax errors. The translator gives descriptive error messages.
Programs are most commonly translated using a compiler. A compiler translates the entire
program at one time. The translation involves your original program (Source file) which is
transformed by a compiler into an object module. Pre-written programs from a system library
may be added during the load/link phase, which results in a load module. The load module can
then be executed by the computer.
Debugging
Debugging is used extensively in programming. It means detecting, locating, and correcting bugs
(mistakes) by running the program. These bugs are called as logic errors, which tells the
computer to repeat an operation but not telling it when to stop repeating. In this phase we run the
program using the test data that we devise. We must plan the test data carefully to make sure we
test every part of the program.
5. Documenting the program
Documenting is an ongoing process. It is a detailed description of the programming cycle and

specific facts about the program in the written form.
Typical program documentation include the origin and nature of the problem, a brief description
of the program, logic tools such as pseudo code and flowcharts, program listings, data-record
descriptions and test results. Comments in the program are also considered as an essential part of
documentation. Many programmers document as they code.
A wise programmer continues to document the program throughout its design, development and
testing. Documentation is used to supplement human memory and to help organize program
planning. Documentation is also critical to communicate with others who have an interest in the
program and may be part of a programming team.
1.2. Why programming is required?
We may have already used software, in the form of spreadsheets or word processing, or to solve
problems. Perhaps we are now curious to learn how programmers write software. A program is a
7
set of step-by-step instructions that directs the computer to do the tasks we want it to do and
produce the results we want.
There are three good reasons for learning programming:
1. Programming helps us to understand computers. If we learn how to write simple programs, we

will know better about how a computer works.
2. Writing a few simple programs increases our confidence level. We will find great personal
satisfaction in creating a set of instructions that solvea a problem.
3. Learning programming lets us find out quickly whether we like programming and whether we
have the analytical turn of mind that programmers need. Even if we decide that programming is
not for us, understanding the process certainly will increase our appreciation of what computers
and programmers can do.
What Programmers Do?
The programmer prepares the set of instructions of a computer program and runs those
instructions on the computer, tests the program to see if it is working properly, and then makes
corrections to it. These activities are all done for the purpose of helping a user to fill a need, such
as paying employees, admitting students to college or billing customers.
Programming can be done as a solo activity, but a programmer typically interacts with a variety
of people. For example, if a program is a part of a system of several programs, the programmer
coordinates with the other programmers to make sure that all the programs fit together correctly.
If you are a programmer, you might also have coordination meetings with users, systems
analysts, managers, and with peers who evaluate your work just as you evaluate theirs.
Levels of Language
Programming languages can be "lower" or "higher," depending on how close they are to the
language the computer itself uses (0s and 1s = low) or to the language people use (English like
high). We will consider five levels of language. These are numbered 1 through 5 to correspond to
generations. In terms of ease of use and capabilities, each generation or level is an improvement
over its predecessor.
The five generations of languages are:
1. Machine languages
2. Assembly languages
3. High-level languages
4. Very high-level languages
8
5. Natural languages
Let us look at each of these categories
1. Machine languages
Humans do not like to deal with numbers alone; they prefer letters and words also. Machine
language consists of numbers. Each type of computer has its own machine language. This is the
lowest level of language. It represents data and program instructions as 1s and 0s- the binary
digits corresponding to the on and off electrical states in the computer. During the early days of
computing, programmers used rudimentary systems for combining numbers to represent
instructions such as add or compare. These programs are not convenient for people to read and
use, and the industry quickly moved to develop assembly languages.
2. Assembly languages
Assembly languages are considered to be very low level languages. They are not as convenient
to use as the more recent languages. However, at the time when they were developed, they were
considered as a great leap forward. To replace the 1s and 0s used in machine language, the
assembly languages use mnemonic codes. Mnemonic codes are abbreviations that are easy to
remember: A for add, C for compare, MP for Multiply and so on. Although these codes are not
English words, they were better accepted than numbers (0s and 1s) alone. Just like machine
language, each type of computer has its own assembly language.
The programmer who uses an assembly language requires a translator to convert the assembly
language program into machine language. A translator is required because machine language is
the only language that the computer can actually execute. The translator is an assembler
program, which is also referred to as an assembler. It takes the programs written in assembly
language and converts them into machine language. Programmers need not worry about the
translating aspect, they only need to write programs in assembly language.
Although assembly languages represent a step forward, they still have many disadvantages. A
key disadvantage is that assembly language is detailed to the extreme, making assembly
language programming repetitive, error prone and tedious.
3. High-Level Languages
The widespread use of high-level languages in the early 1960's transformed programming into
something quite different from what it had been. Programs were written in an English-like
manner, thus making them easier and more convenient to use. Using high-level languages, a
programmer can accomplish more with less effort, and programs can now take care of much
more complex tasks.
These so-called third generation languages spurred a great increase in data processing that
characterized the 1960's and 1970's. During that period, the number of mainframes in use
increased from hundreds to tens of thousands.
9
A translator is used to translate the symbolic statements of a high level language into computer
executable machine language. This translator is called a compiler. There are many compilers for
each language and one for each type of computer. For example, it is necessary to have a COBOL
compiler for each type of computer on which COBOL programs are to be run. A program can be
compiled to different machine language versions on different machines. The source program
itself, that is, the COBOL version is essentially identical on each machine.
Some languages are used to serve a specific purpose, such as creating graphics or controlling
industrial robots. Many languages are extraordinarily flexible and are considered to be general-
purpose languages. In the past, the majority of programming applications were written in
BASIC, COBOL or FORTRAN. All of them are general purpose languages.
4. Very High-Level Languages
Very high-level languages are often known by their generation number. They are called fourth-
generation languages or 4GLs. Fourth-generation languages are beneficial because:
I.They are result-oriented; they emphasize "what" instead of "how".
II.They improve productivity because programs are easy to write and modify.
III.They can be used with minimum training by both programmers and non-programmers.
IV.They shield users from needing an awareness of program structure and hardware.
5. Natural Languages
The word "natural" has become very popular in computing circles. Fifth generation languages
are often called natural languages because of their resemblance to the "natural" spoken English
language. Instead of being forced to key correct commands and data names in correct order, a
manager tells the computer what to do by keying in their own words.
Choosing a Language
 In a work environment, the manager may decide that everyone in the project will use a certain
language.
 We may need to use a certain language, particularly in a business environment, based on the need
to interface with other programs. If two programs are to work together, it becomes easy when
they are written in the same language.
 We may choose a language based on its suitability or criteria. For example, COBOL will be the
best option for a business program that handles large files.
 If a program is to be run on different computers, it must be written in a language that is portable
and suitable on each type of computer, so that the program needs to be written only once.
 We may be limited by the availability of languages. Not all languages are available on all
computers and in all installations.
 The language may be limited to the expertise of a programmer. The program may have to be
written in a language that the available programmer knows.
10
2.Introduction to Computer Programs
2.1. Overview of Software Development
Software development is a discipline in the computer science field that focuses on the creation of
programs that control computer hardware. These programs, also referred to as 'software
applications' or in short 'apps', are groups of instructions that tell a computer what is to be done.
The software development field consists of several computer programming languages, each
designed to fulfill various requirements depending on the project at hand.
It is almost unbelievable to think that a few decades back, the programmers did not even have
desktop computers to work on. Instead they punched instructions into paper cards which were
input into a mainframe computer centrally located in a "machine room". In those times, these
instructions were written in assembly language or machine code, the native language used by
hardware of the computer. As software development evolved, 'higher level' languages were
developed patterning natural languages and better reflecting the human problem-solving process.
Even today, assembly language is still used, especially by low-level engineers developing
computer components and embedded systems. But, most of the desktop and web-based
development is done using high-level languages like ASP, C++, C#, Java, Perl, etc.
If hundred programmers were asked, 'What do they think is the best programming language for
beginners?' you might get one hundred and one answers. Each individual has an opinion. The
question is akin to asking what is the best vehicle to drive - there is simply no right or wrong
answer. Fortunately, some general guidelines exist to get the novice programmer off to a good
start. However, those who are completely new to computers and unsure of whether they are up to
the task (or whether software development will be of interest to them) should start with a
language that is designed to teach basic principles with very minimal complexity. The BASIC
and LOGO programming languages were early attempts to bring computer programming to the
masses. Today a language like Microsoft's Visual Basic would be ideal for a beginner. Visual
Basic helps you to make practical applications with a visual interface in a matter of hours
without getting bogged down by the technical details. Unlike BASIC and LOGO, Visual Basic
has practical applications that can be used in both casual and commercial environments.
Those who are technically inclined or already have a fair amount of experience with computers
may be prepared for more advanced programming concepts. For many years, Pascal was
considered the entry language for such people, and was generally used in schools and
universities to teach programming at a professional level. Nowadays more "practical" languages
like C++, C#, and Java are taught for the reason that they provide a more direct approach to
learning how to develop software with tools that are more commercially viable than Pascal.
Life Cycle of a Software Development Project
Software development is a complicated process comprising different stages. Each stage requires
a lot of paperwork and documentation in addition to the process of development and planning.
This is in contrast to the common thinking of newcomers to the software industry who believe
that software development is just writing code.
11
Every software development project has to go through the following stages at least once:
 Requirement gathering
 Writing functional specifications
 Creating architecture and design documents
 Implementation and coding
 Testing and quality assurance
 Software release
 Documentation
 Support and new features
There may be many additional steps and stages depending upon the nature and the type of the
software product. You may have to go through more than one cycle during the testing phase as
software testers to find problems and bugs. The developers need to fix them before a software
product is officially published or released. Let us go into these stages in detail.
Requirement Gathering
Requirement gathering is usually the first stage of any software product. This stage officially
commences when you are thinking about developing software. In this phase, you meet customers
or prospective customers, and do a market analysis of the requirements and features that are in
demand. You might as well find out if there is a real need in the market for the software product
you are trying to develop. In this stage, most of the work is done by the marketing and sales
people, or people who have direct contact with the customers. These people talk to customers
and try to understand what exactly their requirements are.
A comprehensive understanding of the customers‘ needs and writing down features of the
proposed software product are the keys to success in the requirement gathering phase. This phase
is actually a base for the whole development of the software. If the base is not laid appropriately,
the product will not find a place in the market. If a very good software product which is not
required in the market is developed, it does not sell no matter how well you build it. You can
find many instances of software products that failed in the market because the customers did not
require them. The marketing people usually create a Marketing Requirement Document or MRD
that contains formal representation of the market data gathered. You can also consider your
competitors‘ products (if any). This process is called competitive analysis.
Finally, list down the features required by the product. Appropriate consideration must be given
to the economics of software creation at this point. Questions that must be asked are: is there a
market? Can I make some profit? will the revenue justify the cost of development?
Writing Functional Specifications
Functional specifications may consist of one or more documents. These documents show the
behavior or functionality of a software product on an abstract level. Assuming the product is a
black box, these specifications define its input/output behavior. The product requirements
12
documentation put forward by people who have contact with the end user of the product or the
customers, forms the basis of the functional specifications.
In larger products, functional specifications may consist of separate documents for each feature
of the product. For example, if the product is a router, you may have a functional specification
document for RIP (Routing Information Protocol), another for features on security, and so on.
Functional specifications are important because developers use them to create design documents.
The documentation people also use them when they create manuals for end users. If different
groups are working in different physical locations, functional specifications and architecture
documents (discussed next) are also a means to communicate.
Keep in mind that sometimes during the product development phase you may need to amend
functional specifications keeping in view new marketing requirements.
Creating Architecture and Design Documents
When you have all of the requirements collected and arranged, it is the turn of the technical
architects team, which usually consists of highly qualified technical specialists, to create the
architecture of the product. This defines different components of the product and how they
interact with each other. Often, the architecture also defines the technologies used to develop the
product. While creating the architecture documents, the team also needs to consider the timelines
of the project. This is the target date when the product is required to be on the market. Often
excellent products fail because they are either too early or late to market. The marketing and
sales people usually decide a suitable time frame to release the product. Based on this timeline,
the architecture team may drop some features of the product if it is not possible to bring the full-
featured product to market within the required time frame. After deciding the components of the
product and defining their functionalities, interfaces are designed for these components to work
together.
Most often, no component works in isolation; each one has to coordinate with other components
within the project. Interfaces are the rules and regulations that define how these components will
interact with each other. There maybe major problems down the road if these interfaces are not
designed properly and appropriately detailed. Different people will work on different
components of any large software development project and if they don‘t fully understand how a
particular component will communicate with others, major problems arise during integration. For
some products, new hardware is also required to make use of technology advancements. The
architects of the product also need to consider this aspect of the product. Once the architecture,
software components and their interfaces are defined, design documents are created as the next
phase of development. At the architecture level, a component is defined as a black box that
provides certain functionality. At the design documents stage, you have to define what is in that
black box.
The design documents are usually created by the senior software developers and these
documents define individual software components to the level of functions and procedures. This
is the last document completed before development of the software starts. These design
documents are passed on to software developers as they begin coding. Architecture documents
13
and MRDs usually need to stay in sync, as sales and marketing will work from MRDs while
engineering works from engineering documents.
Implementation and Coding
The software developers use the design documents and development tools (editors, compilers,
debuggers etc.) and start writing software. This is often the longest phase in the product life
cycle. Every developer has to write his/her own code and collaborate with other developers to
make sure that the different components can inter-operate with each other. A revision control
system such as CVS (Concurrent Versions System) is needed in this phase. There are many open
source revision control systems as well as commercial ones available these days. The version
control system provides a central repository to store the individual files. A normal software
project may contain anywhere from hundreds to thousands of files. In larger and complex
projects, directory hierarchy must also be decided beforehand so that files are stored in
appropriate locations. During the development cycle, different developers may modify the files.
If the rules are not followed by everybody, this may easily break the whole compilation and
building process. A typical example is duplicate definitions of the same variables causing
problems.
Similarly, if included files are not written properly, loops get created easily. Other problems pop-
up when multiple files are included in a single file with conflicting definitions of variables and
functions. Coding guidelines must also be defined by architects or senior developers. As an
example, if software is intended to be ported to some other platform, it must be written on a
standard like ANSI. During implementation, developers must write enough comments inside the
code so that if anybody starts working on the code in the future, he/she would be able to
understand what has already been written. Writing good comments is extremely important as all
other documents, no matter how good they are, will be lost eventually. Ten years subsequent to
the initial work, it's probable that you may find only that information which is in the form of
comments, present inside the code. Development tools also play an important role in this phase
of the project.
Good development tools save a lot of time for the developers. They also help to save money in
terms of improved productivity. In terms of time saving the most important development tools
are editors and debuggers. An editor helps a developer to write the code quickly.
A good debugger helps to make the code operational in a short period of time. Before the start of
the coding process, considerable time must be spent in choosing good development tools. During
the development phase, review meetings also prove helpful. Through review meetings, potential
problems are identified earlier in the development. Review meetings are also helpful to keep
track of whether the product is on time or if more effort is needed to complete it within the
required time frame. There will be times when you may also need to make changes in the design
of some components because of new requirements from the marketing and sales team. Review
meetings are a great tool to convey these new requirements. Here, architecture documents and
MRDs are kept in sync with any changes/problems encountered during development.
Testing
14
Testing is probably the most important phase for long-term support as well as for the company's
reputation. If you don‘t control the software quality, it will not be able to compete with other
products on the market. If software crashes at the site of the customer, he loses productivity as
well money and you lose credibility. On most occasions these losses are huge. Unhappy
customers will never buy other products from the same vendor and will not refer other potential
customers. You can avoid this situation by doing extensive testing. This testing is often called as
Quality Assurance, or QA, in the software world. Generally testing starts as soon as the initial
software components are available. There are multiple types of testing. Each of these has its own
importance.
1. Unit Testing - Unit testing is testing one part or one component of the product. The developer
generally does this when he/she has completed writing code for that part of the software. This
makes sure that the component is doing what it is intended to do. This also helps the software
testers as well as developers save time by eliminating many cycles of software being passed back
and forth between the developer and the tester. When a developer is ready with a particular part
of the software, he/she can write test cases to test the functionality of this part of the software.
The component is then passed on to the testers who run test cases to make sure that the unit is
working properly.
2. Sanity Testing - Sanity testing is a very basic check to see if all the software components
compile with each other without any problems. This is to ensure that developers have not defined
conflicting or multiple functions or global variable definitions.
3. Regression or Stress Testing - Regression or stress testing is a process done in some projects
to carry out a test for a longer time period. This type of testing is used to determine the behavior
of a product when used continuously over a period of time. It can expose some bugs in software
like the ones related to memory leakage. In some cases, developers allocate memory but forget to
release it. This is usually referred to as memory leakage. When testing goes on for many days or
weeks, it often results in allocation of all of the available memory until no memory is left. This is
the point where your software starts showing abnormal behavior. Another potential problem in
long-term operation is counter overflow. This happens when you increment a counter but forget
to decrement it resulting in an overflow when the product is used for long time. The regression
testing may be started as soon as some components are ready. This type of testing requires, by its
very nature, a very long period of time. The process should be continued as more components of
the product are integrated. The process of integration and communication through interfaces may
create new bugs in the code.
4. Functional or System Testing - Functional testing is carried out to make sure that the
software is doing exactly what it is supposed to do. This must be done before any software is
released to customers. Functional testing is done by testers whose primary job is software testing,
and not the developers themselves. In small software projects where a company can‘t afford
dedicated testers, other developers may also do functional testing. The key point to keep in mind
is that the person who wrote a software component should not be the person who tested it. A
developer will always have a tendency to test the software the way he/she wrote it. He/she may
easily miss any problems in the software. The testers need to prepare a testing plan for each
component of the software. A testing plan would contain test cases that are run on the software.
15
The tester can prepare these test cases using functional specifications documents. The tester may
also get assistance from the developer to create test cases. Each test case must include
methodology used for testing and expected results. Additionally, the tester may also need to
create certain infrastructure or environment to test the functionality of a piece of code. For
instance, you may simulate a network to test the routing algorithms that may be part of a router.
The next important job of the tester is to create a service request if an anomaly is found. The
tester must include as much information in the service request as possible.
Typical information included in reporting bugs includes:
 Test case description

 How the test was carried out
 Expected results
 Results obtained
 A description of that environment, if a particular environment was created for testing
The bug should be forwarded to the developer so that the developer may correct the problem.
Many software packages are available in the market to track bugs and fix problems in software.
Software Releases
Any software product is officially released before you start selling it. This means that you create
a state of the software in your repository, ensure that it has been tested for functionality and the
code is frozen. A version number is assigned to the released software. After releasing,
development may continue but it will not make any change in the released software. The
development is often carried on in a new branch and it may contain new features. The released
software is updated only if a bug fixed version is released. Generally companies assign
incremental version numbers following some scheme when the next release of the software is
sent to market. The version number change depends on whether the new software contains a
major change to the previous version or it contains bug fixes and enhancement to the existing
functionality. Software releases are also important because they are typically compiled versions
of a particular code version, and thus provide a stable set of binaries for testing.
1. Branches - In almost all serious software development projects, a version control system is
used. This system keeps a record of changes in source code files and is usually built in a tree-like
structure. During the release of the software, the state of each file that is part of the release
should be recorded. By creating branches to this state, future developments can be made.
Sometimes special branches may also be created that are solely used for bug fixing.
2. Release Notes - Every software version contains release notes. These are prepared by people
releasing the software version with the help of the developers. Release notes show what
happened in this software version.
Typically the information includes:
 Bug fixes
16
 New functionality
 Details of new features added to the software
 Any bugs that are not yet fixed
 Future enhancements
 If a user needs a change in the configuration process, it is also mentioned
Generally a user must be given enough information to understand the new release enhancements
and decide whether an upgrade is required or not.
Documentation
There are broadly three categories of documentation related to software development processes:
 Technical documentation developed during the development process, such as the

architecture, functional and design documents.
 Technical documentation prepared for technical support staff, including technical
manuals that support staff use to provide customer support.
 End-user manuals and guides. This is the documentation for use of the end user. It assists
the user in getting started with the product and using it.
All three types of documents are necessary for different aspects of the support of the product.
Technical documents are necessary for future development, bug fixes, and adding new features.
Documentation for technical support staff contains information that is too complicated for the
end user to understand and use. The support team needs this information in addition to user
manuals to provide better support to customers. Finally each product should have the user
manuals. Technical writers often develop user manuals which are based on functional
specifications. In the timelines of most software development projects, even before the start of
code development, functional specifications are prepared. So the technical writers can start
writing user manuals while developers write the code. So when the product is ready, the user
manual is almost completed.
Support and New Features
Your customers need support when you sell a product. This is true regardless of the size of the
product, and even for non-software related products.
The most common support requests from customers are related to one of the following:
 Help in installation and getting started

 To release a patch or update to the whole product
 A new feature required by the customer
In addition to these, you may also want to add new features to the product for the next release
because competitor products have other features. Better support will increase your customer
loyalty and will create referral business. You may adopt two strategies to add new features. You
may provide an upgrade to the current release as a patch, or wait till you have developed a list of
17
new features and make a new version. Both these strategies are useful depending how urgent the
requirement for new features is.
2.2. Overview of problem solving Techniques
Good problem solving skills empower managers in their professional and personal lives. Good
problem solving skills seldom come naturally; they are consciously learnt and nurtured. Good
problem solving skills should include:
 developing innovative and creative solutions;

 developing solutions which are practical;
 showing independence and initiative in identifying problems and solving them;
 applying a range of strategies to problem-solving;
 applying problem-solving strategies across a range of areas;
What is a Problem?
A problem can be defined as an opportunity for improvement. ―Every problem has a gift for you
in its hands,‖ says Richard Bach. An optimist looks at challenging or problematic events as
potential opportunities for improvement. He will be always seeking answers for the questions
such as:
 Is there more than one probortunity? "Probortunity‖ – a synonym by combining the

words ―problem‖ and ―opportunity‖.
 Is it my personal probortunity or Is it the probortunity of the organization?
 Is it an annoyance or an actual probortunity?
 Is this the real probortunity, or merely a symptom of a larger one?
A problem can be defined as the difference between the actual state and the desired state. A
problem could also be the result of the knowledge that there is a gap between the actual and
desired or ideal state of objectives. Clarity of the problem is determined by the clarity of the
knowledge which one precisely wants and which one has. Greater clarity of the problem will
help in finding a better and an effective solution.
A problem can also result from the recognition of an imperfect present and the belief in the
possibility of a better future. The belief that one's hopes can be achieved will give one the will to
aim towards a better future.
Key approaches to Problem solving
There are different ways of problem solving – each has its own advantages and disadvantages.
The process an individual adopts as a manager will be influenced by organizational policies,
his/her own personality and communication style, and the kind of information available about the
problem. Broadly, there are two problem solving models available to a manager.
A. Rational Problem-Solving
18
Rational problem solving rests on the following principles (R. K. Wagner - ―Learning to solve
practical problems‖):
 Problems are identified by comparing actual performance with an expected standard

performance
 Problems are deviations in actual performance from the expected standard
 A precise and complete description of the problem is needed to identify a solution
 What is happening?
 Where is it happening?
 When is it happening?
 To what extent is it happening?
 The cause of the problem can be found by comparing the problem and non-problem
situations.
 Recent problems are due to some change in the situation that has caused an unwanted
deviation from expectations.
The Rational Decision-Making model requires the following steps, which if followed, are
assumed to lead to "value-maximising choices." These steps are as follows:
 need to define the problem,

 identify the decision criteria,
 weigh the criteria which can be used to determine rank of importance,
 generate alternative solutions,
 rate each alternative on a different criteria, and
 compute the optimal decision.
B. Lateral or Creative Problem-Solving
Lateral or creative problem solving does not follow any standard set of procedures. It is a
‗subconscious process based on past distilled experiences‘. It is based more on the gut feeling of
the manager than on an objective process of weighing alternatives.
There are a set of conditions and it is accepted that under those conditions intuitive approach is
generally preferred to rational approach. Intuitive method is preferred when:
 there is a high level of uncertainty,

 little precedence to draw on exists,
 variables are not that easily predictable,
 facts are limited or facts are contradictory,
 analytical data is not of much use,
 there are several plausible solutions; and
 decision needs to be made in a short period of time
The creative/lateral problem solving is very flexible. So it can be used to examine real problems
and issues.
19
Problem solving process
There are a variety of problem-solving processes. But each process consists of a series of steps –
which include identifying the problem, searching for possible solutions, selecting the most
optimal solution and implementing a possible solution. It is useful to view problem solving as a
cycle because, sometimes, a problem needs several attempts to solve it or at times the problem
itself changes. The diagram below shows a seven-step problem solving process.
2.1 : Seven-Step Problem Solving Process
1. Identifying the Problem: The first step in the problem solving process is sizing up the
situation to identify the problem. This may sound simple enough, but sometimes managers might
be uncertain about even what the problem is; they might just be feeling anxious or be confused
about what is getting in the way of their objectives. If that is the case, they can ask themselves or
consult with their friends or a professional expert. Other useful techniques for identifying the
problem include-
 Comparison with others

 Monitor for weak signals
 Brainstorming
 Checklists
 Comparison of current performance with objectives or past performance
 Listing complaints & role playing
20
2. Exploring the Problem: Having identified the problem, managers should analyze the problem
to see what is the root cause for it. Often people get caught up in symptoms or effects of a
problem or issue and never drill down to the real cause. They get mad at someone‘s attitude,
anger, or actions, which is not the real cause of the problem. The key here is to focus on
analyzing the problem for the real root cause without being affected by emotional issues.
Seeking answers to questions such as the following will help explore the problem:
Identify the Problem – Ask Who?
 Who says that this is a problem?

 Who caused or is causing the problem?
 Whom does it or will it affect?
 Who has done something about the problem?
Identify the Problem – Ask What?
 What happened or will happen?

 What are the symptoms?
 What are the consequences for others?
 What circumstances surround the occurrence of the problem?
 What is not functioning as desired?
Identify the Problem – Ask When?
 Did it or will it happen?

 Why did it happen?
 When did it first occur?
Identify the Problem – Ask Where?
 Where is the problem occurring?

 Did it or will it have an impact?
 Where did it have an impact?
Identify the Problem – Ask Why?
 Why is this, a problem?

 Did it or will it occur?
 Why did it occur?
 Why was nothing done to prevent the problem from occurring?
 Why did no one recognize and do something about the problem at the earliest?
 Why is a response needed now?
Identify the Problem – Ask How?
 How should the process be working?
21
 How are others dealing with this or similar problems?
 How do you know this is a problem; what supporting information do you have?
Once the root cause is found, plans can be made to fix it. Analyzing implies gathering
information. If there is not enough information, they should find some ways to research and
collect it.
3. Set Goals: Having explored and analyzed the problem, managers should be able to write a
goal statement that focuses on what is the successful end of the process. Once the root cause is
found, plans can be made to fix it. Analyzing implies gathering information. If there is not
enough information, they should find some ways to research and collect it.
Making and writing down a goal statement will:
 help them to clarify the direction to be taken in solving the problem; and
 give them something definite to focus on
That is, what will occur as a result of the solution? This whole process is about fixing or closing
the gap between the problem and the goal. Writing down the problem ensures that they are not
side-tracking from, but addressing the problem.
4. Look at alternatives: Now that the problem has been analyzed, the managers can start
developing possible solutions. This is a creative as well as practical step where every possible
solution needs to be identified. They should identify the various alternative solutions available to
them through techniques such as –
 Analysis of past solutions

 Reading
 Researching & thinking
 Discussing
 Asking Questions
 Viewing the problem with fresh eyes
 Sleeping on it
 Brainstorming
The idea is to collect as many alternative solutions as possible. Mind mapping is another
technique that can be used for finding alternative solutions. Mind mapping uses pictures and/or
word phrases to organize and develop thoughts in a non-linear fashion. It helps people see a
problem and its solution.
Here‘s how to do mind mapping:
 Take a sheet of plain paper and turn it sideways (if using flipchart paper you don‘t need
to turn it sideways - it is large enough); Using colored felt pens, draw a small picture (or
22
write a phrase) in the centre of the paper representing the issue you want to solve; Draw
lines out from the main problem (it helps to use different colors for each line).
 Each line should represent a different aspect of your problem or issue;
 Write down what each line represents either on top of or on the line;
 Add other lines flowing off these main lines;
 Write a word or short phrase on the smaller lines indicating what each new line
represents (you may find that mind mapping works best for you if you write down the
phrases or draw the images first and then connect them with the lines); and
 If you want, add images next to your main line that illustrate what each line means to you
(some people think better with pictures, others with words).
5. Select the best solution: Now that there are a wide variety of possible solutions available, it is
time to select the best solution from among them to fix the problem, given the circumstances,
resources and other considerations. Here the managers are trying to figure out what exactly
would work best given the nature of the problem. There are always a number of things that can
affect a solution, for instance, money, time, resources, procedures, rules, policies, and so on. All
of these factors must be thought about. Managers should prioritize the solutions by their
effectiveness. This is a slow process of elimination. There may be some possible suggestions that
may need to be immediately eliminated. Eventually, managers should narrow down the choices
to one best possible solution which will promise them the best or optimal outcomes.
6. Implementation: Implementation is a crucial part of problem-solving process. In order to

implement the solutions chosen, managers must have an action plan and communicate it to those
people who are directly and indirectly affected. Gemmy Allen (―Problem-Solving & Decision-
Making‖) says that communication is most effective when it precedes action and events. In this
way, events conform to plans and events happen when, and in the way, they should happen.
Managers should answer the below vital questions before they are asked, like –
 What should be communicated?

 What is the possible reason for the decision?
 Whom all will it affect and how?
 What are the benefits expected for the individual, department, and the organization as a
whole?
 What adjustments will be required in terms of how work will be done?
 What is each individual‘s role in implementing the decision?
 What are the results expected from each individual?
 When does the action called for by the decision go into effect?
7. Evaluation: This is the final step in the problem-solving process. Managers should review the
effectiveness of the solution against desired outcomes. Questions like did the solution work? If
not, why? What went right, and what went wrong? What adjustments do they have to make to
ensure that the solution will work better? This stage will require careful analysis that improves
upon the best solution.
23
The review of your progress can help a manager identify any problem. Steps may need to be
revised or new steps need to be added. One may need to consider a different solution, if the
current one, with which he/she has been, is not helping.
Essentials of Effective Problem Solving
 Clear description of the problem

 Description of the negative or limiting factors involved in the problem
 A description of the positive or the constructive factors involved in the problem
 A clear delineation of the ―ownership‖ of the problem - Whose problem is it: mine,
yours, the other guy‘s, my boss‘, my spouse‘s, my child‘s, my parents‘, my teacher‘s?
 Scope of the problem need to be clearly defined: How extensive a problem is it? How
long has this problem existed? How many people are affected by this?
 A clear description of the consequences if the problem were not solved - What is the
possible impact on my family, job, life in this community, etc., if this problem isn‘t
solved? What is the worst possible thing that could happen if this problem isn‘t solved?
 A list of brainstormed solutions to the problem, with each alternative analyzed as to its
reality, its benefits, and the consequences for following each one.
 A system of ranking each solution to finalize the decision-making process - A rating
system for analyzing each solution is developed, e.g., 100% chance of success, 75%
chance of success, 50% chance of success.
 A clear description of myself as a problem-solver - When it comes to this problem, am I
procrastinating? Am I avoiding the problem? Am I denying the problem? Am I shutting
down or blocking my creativity on this problem? Am I ignoring it, hoping it will go
away? Am I using magical and/or fantasy thinking in addressing the problem?
 Determination to follow through on the solution decided upon jointly. This will involve
full motivation to ―take the risk‖ and pursue the solution to its fullest.
2.3. Phases in the Execution of a Computer Program
In computer science, a computer program specifies the behavior that is invoked at some point,
causing that behavior to be exhibited by a running program. That means, a program has a
lifetime that includes distinct phases, starting with editing the code that specifies the behavior,
and extending till the execution of the code, which exhibits the specified behavior. The major
phases of a program's lifecycle are edit time, compile time, distribution time, installation time,
link time, load time, and run time.
It is important to be aware that these phases do not necessarily happen in a linear order. But, they
can be intertwined in various ways. For instance, during development of the program, edit time
and compile time are repeatedly performed, without any link, load, or execution.
Edit time is the phase during which the code of the program is being edited. During this phase,
the code may not be finalised. The editing is usually performed by a human programmer.
Compile time is the phase during which the edited program or the source code is translated into
machine code by a compiler.
24
A compiler is a computer program (or set of programs) that transforms source code written in a
programming language into another computer language (often having a binary form known as
object code). The reason for wanting to transform source code is to create an executable
program. The name "compiler" is primarily used for programs that translate source code from a
high-level programming language to a lower level language (e.g., assembly language or machine
code).
The operations performed at compile time usually include syntax analysis, various kinds of
semantic analysis (e.g., type checks and instantiation of template) and code generation.
Programming language definitions usually specify compile time requirements that source code
must meet to compile successfully. For example, the amount of storage required by types and
variable can be deduced.
Distribution time is the phase during which the program is sent from the entity that created it, to
the one that will invoke it. The format is typically an executable file, but sometimes source code,
especially in the case of a program written in an interpreted language. The distribution method
varies, from physical media such as CD-ROM, to online download via the internet.
Installation time is the phase occurring just after distribution. Here, a program is received into a
system that must perform some form of installation process. The process of installation makes
the program available to be executed within the system. The installation process is able to invoke
different phases of a program's lifecycle. For instance, an executable may be analyzed and re-
compiled during installation in order to improve the execution on the particular hardware of the
system being installed on.
Link time is the phase during which the names of implementations are looked up and connected
together. For instance, a program that invokes libraries does so by stating the name and an
interface of the library. During link time the particular implementation of that interface is
connected to the program that invokes it. This connection can be done inside the compilation
system, or during the installation, as a part of starting execution, or even invoked during the
process of execution.
Load time is the phase in which an executable image is taken from its stored form, and placed
into active memory, as part of starting execution.
Run time is the phase during which the behavior of the program is exhibited. Run time is the
time during which a program is running (executing), in contrast to other phases of a program's
lifecycle such as compile time, link time, load time, etc.
A run-time error is detected after or during the execution of a program, but a compile-time error
is detected by the compiler before the program is ever executed. Storage allocation, type
checking, code generation, and code optimization are typically done at compile time; however it
may be done at run time depending on the particular language and compiler.
25
3.Basic Programming Concepts
3.1. Introduction to basic programming concepts
When a programmer writes a program, he/she needs to write the instructions to store, process
and arrange data. Also, instructions are required to control the flow of the program. A
programmer needs to understand the following concepts to write a program:
 What is a data type and how to use a data type?

 What is a variable and its use?
 How to control the flow of the program?
 How to arrange and use a group of data?
 How to group a set of instructions into a single unit?
 How to create new data types?
A program is a sequence of instructions (written using a programming language) for

machine/computer to accomplish a task. A textual explanation of squence of instructions is
called an algorithm or pseudocode.
3.2. Datatypes
Data and Datatypes
Programs need data in the form of numbers, time, names, date, description etc. Consider a
program to calculate the sum of two numbers.
sum = x+y
Here the two numbers are the data and the type of data (numeric data-integer, decimal etc.) is the
data type. In more elaborate terms, a data type used in a program determines the type of data,
memory needed for storing the data, and the kind of operation that can be performed with the
data (e.g. you can multiply two numbers together, you can concatenate alphabets and make it a
word and multiple words into a sentence.)
26
What can we infer from the figure above? We can see that different types of data like integer,
string, date etc. have been used in the form.
A datatype represents the type of data, memory storage and the operations that can be
performed using the data.
Classifying data types
Data types are divided into primitive and composite types. The primitive data types are the basic
data types that are available in most of the programming languages.
Primitive data types are used to represent single values that include numeric types like integer or
float, boolean, character and string.
The data types that are derived from primary data types are known as non-primitive or composite
data types. These data types are used to store a group of values. Composite type includes Array,
Structure, Class etc.
Basic Data Types
Numeric type is divided into Integer type and Floating-point type. The table below shows the
division and examples for numeric types:
Numeric Types
Datatypes are mainly classified into primitve and composite types.
3.3. Introduction to variables
Variables and Constants
The input data needed for a program and the output data generated by the program are stored in
the computer memory. While writing a program, the programmer needs to specify the memory
required for storing the data needed for the program and generated by the program. The memory
27
location where data is stored is called a variable. The program can change the data in that
memory location any number of times, and hence the name.
A program also needs a memory location where it can store data but cannot alter it later. Such
memory locations are called constant memory locations.
Consider a program that finds the area of a circle. The program takes radius (numeric) as an
input data to calculate the area. When user gives the input data, the program stores it in the
memory for further calculation. The program also stores the result (area of circle) after
calculation. This means that the program uses at least two memory locations (two variables); one
for storing the input (radius of circle) and one for storing the result (area of circle). You know
that Pi is a constant and has a fixed value (3.14). In this program the value of Pi can be stored as
a constant because the program cannot alter the value of Pi.
Program Steps:
 Declare a variable radius to store radius of the circle.

 Declare a variable area to store the area of the circle.
 Declare a constant Pi to store the constant value.
 Calculate the area of circle ( Pi* radius* radius).
 Store the result in variable area.
28
A variable is a memory location whose value can change throughout the operation of a program.
A constant is a memory location whose associated value cannot be altered by the program during
its execution.
Actions using Variables
Following are the actions that a programmer can do using a variable:
 Declaring or creating a variable

 Initializing a variable
 Storing data to a variable
 Retrieving or fetching data from a variable
Declaring or Creating a variable
To declare or create a variable, the programmer needs to select an appropriate data type and a
meaningful name for the variable. The data type must be used only while declaring a variable.
The general format for declaring a variable is :
data-type variable-name;
Eg: int counter; String name;
29
Initializing a variable
Initializing a variable means putting an initial value to the variable(bucket). A variable can be
initialized while creating or declaring it.
Eg: int counter=0; char gender='M';
Storing data to a variable
Once a variable is created, data can be stored in the variable. An assignment operator(=) is used
in the program to store data to a variable. The initial value of the variable can be changed by
assigning a new value using the assignment operator(=).
counter = 10;
gender = „F‟;
Retrieving or fetching data from a variable
To retrieve or fetch data from a variable, use the name of variable.
int x = 10; int y= 20;
int sum = x+y;
30
In the above program statement, the names of the variables (x and y) are used to retrieve the
values stored in the variables.
Always initialize a variable while declaring or after declaring it.
3.4. Introduction to Operators
Operators are special symbols that perform specific operations on one or two operands, and then
return a result.
Consider a program that does mathematical operations like addition, subtraction, multiplication,
division on two numbers. (The program needs two variables to hold the two numeric values.)
int num1 ; // declares a variable num1 of type int to store the first numeric data.
int num2; // declares a variable num2 of type int to store the second numeric data.
int result; // declares a variable result of type int to store the result after operation.
result = num1 + num2; // add num1 and num2 and store the sum in variable result.
In the above program statements, num1 and num2 are the operands and + is the operator. The
sum of num1 and num2 is stored in the variable named result.
Operators can be classified into unary and binary operators. Unary operators are the operators
that deal with only one operand (one variable). Binary operators are the operators that deal with
two operands (variables or constants).
31
3.5. Control structures
Einführung
A program is a set of instructions or commands given to a computer to do a specific activity or

task. The normal execution flow of program statements will be sequential. Sometimes the
sequential flow should be altered because of some conditions which change the flow.
For example, every day a person drives his car from city A to city B through a straight national
highway to reach his office. One day, there is a big traffic jam on the way to city B. If the person
wants to reach city B then the he has to select an alternate route. Here changing route is equal to
changing the flow of program (controlling the flow) and the decision of selectiing an alternate
route will be based on some parameters like distance or condition of the road.
32
Control structures help to control the flow of a program.
Types of control structures
Sequence, Selection and Repetition (Iteration) are the three main control structures used to
control the flow of program in any programming language.
Sequence:
Statements in the program will be executed one-by-one from the first to the last statement.
Selection:
The selection control structure allows one set of statements to be executed if a condition is true
and another set of statements to be executed if a condition is false.
The following are the common selection control structures use in programming languages.
 if
 if-else
 switch
Repetition
Executing one or more steps of an algorithm or program based on some condition. The repetition
control structure is also known as the looping or iteration control structure.
33
The following are the common looping control structures use in programming languages.
 while
 do-while
 for
Sequence, Selection and Repetition (Iteration) are the three main control structures used to
control the flow of program.
3.6. Introduction to Arrays
Most of the programs deal with a group/collection of data. For example, list of bank account
numbers, exam scores, country names etc. Data could be primitive like integer or composite like
Date.
Program needs to arrange and manage these groups of data. All programming languages provide
one basic data structure named array, that helps to store and manage a group of data.
An array helps to store a collection of data (elements). Like the numbering used in the above
diagram, array uses an index to represent the location of each independent data stored in it.
The main ability of an array is to represent a group of data using a single name and accessing
each individual data stored in it using an index. In programming world, starting index of an array
will always be zero.
Arrays can be one dimensional, two dimensional or multi-dimensional. The figure given above
can be looked upon as a single dimensional array having a single row with 11 columns (0 – 10
seats).
34
Consider a program that needs to store the names of all the students participating in a quiz
program. The input data for the program is:
 Number of students participating in the quiz

 Names of the students
We need a variable to store the number of students and an array to store the names of students.
int count; //variable to store number of students
String nameArray[count]; // array to store names of students
An array is used to store a group of data of similar type.
Create and Use an Array
Creating and initializing an array
The general format for creating and initializing an array is given below.
datatype array_name[ ] = {value1 , value 2 , value3};
Eg. int nums_array[ ]={11, 22, 33,44,55} ;
Array Creation
35
Adding elements into an array
After creating an array, data can be added to it. For adding data to an array use the index of the
array. The general format for adding elements to an array is given below.
array_name[index] = value;
Eg. nums_array[0] = 88;
Retrieving data from an array
Use array index to retrieve data from an array.The general format of accessing data from an array
is given below:
variable_name = array_name[index];
Eg. num1 = nums_array[4];
Array creation example
Consider a program that stores the scores of the participants who attended a quiz and calculates
the average score of all participants.
The type of data(quiz score and average score) which we need to use in this program is numeric.
If the selected programming language is Java/C/C++, then we can select int or float as numeric
type. Let‘s select int for individual score and float for average score.
Assume the total number of participants as 100 and declare a constant named SIZE that stores
the total number of participants.
const int SIZE = 100;
Create an array to store the scores of 100 participants.
int quizScores[SIZE ];
Add participant score to the array (index starts from 0).
quizScores[0] = 25; quizScores[1] = 30; ...
For calculating the average score, iterate the array using for loop and calculate the sum and find
the average.
36
int totalScore= 0;
float avgScore =0.0;
/* iterate the array */
for (int i=0 ; i<SIZE ; i++) {
totalScore = totalScore + quizScores[i];
avgScore = totalScore/SIZE;
So we calculated the average score of all participants by storing individual score in an array and
iterating the array using a for loop.
3.7. Introduction to Functions
Einführung
Functions are a named group of program statements that perform a specific task. Functions are
reusable sets of code useful to other programs. Each function is like a black box that takes input,
processes it and gives the result.
Programs or functions can call any function to perform a task. A main function is the function
that has the main control flow of a program. All other functions are called sub functions of a
program. In object oriented programing languages like java, functions are called methods.
37
Functions are a named group of instructions that perform a specific task.
Defining a function
The following questions help to define a function:
 What specific task needs to be performed by the function (body)?

 What are the inputs (arguments/parameters) needed by the function to complete its task?
 Does function return any result? If it returns, what kind of result (data) does it return?
Each function has two parts, header and body. Function header specifies the name of the
function, input parameters and the output type. The function body contains the logic of the
function.
The general format of a function is as follows.
return_type functionName( [datatype parameter1, datatype parameter1, …]){
// function body
Here return_type means the type of data(numeric , String,…) the function will return after
executing the logic in the body part. If the function does not return any data but performs a task,
then the return type will be void (means no return_value).
Example:Function definition
38
Function Examples
Example1: Function that takes an input, performs a task and returns a result.
Example2: Function that takes an input, performs a task and returns no result.
39
Example3: Function that takes no input, performs a task and returns a result.
Example4: Function that takes no input, performs a task and returns no result.
void alert(){
sendAlertMessage(“ Low Resource”);
The function alert takes no input, but performs a task via a function sendAlertMessage() and
does not return any output.
Calling/Invoking a function
The main function should know the name of the sub function and the arguments/inputs needed
by the sub function to invoke/call the sub function.
The common syntax for invoking a sub function is:
functionname([arguments]) ; or
result = function_name([arguments]); //store result in a variable, if function return some data
40
 float result = avg(10,20,30);
 int count= getCount();
 alert();
 store(―Happy B‘day‖);
3.8. Composite Datatypes
Einführung
Programs not only use primitive data types but also composite data types like Date, String,
Employee, Student etc. Composite data types are constructed using primitive data types and
other composite data types. Composite data types can be built-in data types (e.g. String or Date)
or programmer defined data types (e.g. Student, Employee).
Consider a program that stores the details of a group of students. Here each student has data like
Id, name, age, college, stream, and grade.
The program requires:
 A new data type, which represents a student

 An array, which can store the student details
Defining data type
Every programming language provides a way to define and use composite data types.
C programming language provides keywords like typedef and struct to define a composite data
type. Object oriented programming language like Java provides a keyword named Class to create
a composite data type.
C program
typedef struct {
int id;
char name[50]; // C language use character array as string
char college[100];
char stream[25]
char grade;
} Student;
41
Java program
class Student{
int id;
String name;
String college;
String stream;
char grade;
};
Both these programs define a new type Student, where Id, name, college, stream, grade are the
members (data members) or properties of Student type.
Creating a variable of composite type
Composite variables are created like primitive variables. A composite variable consists of a fixed
number of variables "glued together".
The example below shows how to declare and initialize composite variables.
Student stud1 ={ 100, “John” ,”SNC”,”EC”,‟A‟}; //structure in C
Student stud2 = new Student( 101,”Rohit”,”MIT”,”CS”,‟A‟); // object in Java
Accessing data members
A special operator named dot operator (.) is used to access data member of a composite data.
42
Here stud1 and stud2 are variables that store composite data.
char[ ] name = stud1.name;
String college = stud2.college
Composite variable consists of a fixed number of variables glued together.
43
4.Introduction to Developing a User Interface
4.1. Introduction to Developing a User Interface
Einführung
To work with a system, the users have to be able to control and assess the state of the system. For
example, when driving a vehicle, the driver of the vehicle uses the steering to control the
direction, and the accelerator pedal, brake pedal and gears to control the speed of the vehicle.
The driver understands the position of the vehicle by looking through the windshield and the
exact speed of the vehicle by checking the speedometer. The driver's interface of the automobile
is on the whole composed of the instruments that the driver can use to accomplish the tasks of
driving and maintaining the automobile. Interactive entities must constantly be designed to
support the way in which humans interact with the world and information.
In information technology, the user interface is everything designed into an information device
with which a human being may interact -- including the monitor, keyboard, mouse, the
appearance of a desktop, characters in text, help messages, and how an application or a Web site
invites interaction and responds to it. In the previous generations of computers, there was very
little user interface except for a few buttons at an operator's console. The user interface was
mainly in the form of punched card input and report output.
Later, a user was provided with the ability to interact with a computer online and the user
interface was a nearly blank display screen with a command line, a keyboard, and a limited set of
commands and computer responses that were exchanged. This command line led to a new form
of interface in which menus (list of choices written in text) predominated. Eventually, the
graphical user interface (GUI) arrived, originating predominantly in Xerox's Palo Alto Research
Center, adopted and enhanced by Apple Computers, and finally standardized effectively by
Microsoft in its Windows operating systems.
The user interface can, essentially include the total "user experience," which may include the
aesthetic appearance of the device, response time, and the content that is presented to the user
within the context of the user interface.
Different types of User Interface
The three most common types of User Interfaces are:
 Command Line Interface (CLI)

 Graphical User Interface (GUI)
 Web User Interface (WUI)
However, a few other types of User Interfaces also exist
44
 Touch User Interface(CLI)
 Voice User Interface
Command Line User Interface:
In a command line user interface, the user provides the input by typing a command string with
the computer keyboard and the system provides output by printing text on the computer monitor.
This is normally used by programmers and system administrators, and by technically advanced
personal computer users.
A good example of command line user interface is the windows command prompt, as seen in the
image below.
The advantages of using a command line user interface are:
 Consumes low bandwidth – As the command line interface is devoid of any graphics or
extra data, this is especially useful in a networked environment where network traffic is
to be limited.
 Appeals to expert users – as the commands relevant to a particular task give information
about that task only, any other extra data/information that could potentially cause a
distraction to the user are easily avoided.
However this type of user interface poses the following disadvantages too:
 Learn-ability and Retention of commands is generally poor – this is especially

applicable to non-expert users, who would find learning and remembering individual
commands of each task difficult. Hence they won't be comfortable with the command
line interface.
 Not very user friendly and hence error rates are high – especially when a user is
trying to enter data. A mistake made in typing while using command line is often not
forgiven. That is, a user is usually not warned or prompted for confirmation while using
45
direct commands in the command line. Hence chances of wrong data being entered are
very high.
Graphical User Interface (GUI):
Graphical User Interface is a type of user interface that allows users to interact with computers
using images rather than text commands. A GUI presents the user with information and actions
available to a user through graphical icons (like My Computer, Recycle Bin icons in Windows)
and visual indicators such as secondary notation, as against text-based interfaces, typed
command labels or text-based navigation. The actions are generally performed through direct
manipulation of the graphical elements (such as clicking on the icons, double clicking etc).
GUI typically allows user interaction with the system through the use of visual elements, such as
windows, buttons, tables, forms, menus, etc. thus freeing the user from learning complex
command languages. This kind of interface takes advantage of the computer's graphics
capabilities to make the program easier to use.
A typical GUI looks like the one in the image below
Basic Components of a GUI:
Pointer - A symbol that appears on the display screen and that you move to select objects and
commands. Usually, the appearance of the pointer is that of a small angled arrow. Word-
processing applications, use an I-beam pointer instead, that is shaped like a capital I.
Pointing device - A device, such as a mouse or trackball, that enables you to select objects on
the display screen.
46
Icons - Small pictures that represent windows, files or commands. By moving the pointer to the
icon and clicking the mouse button, you can convert the icon into a window or execute a
command. You can also move the icons around the display screen as if they were real objects on
your table.
Windows - You can divide the screen into different areas. In each window, you can display a
different file or run a different program. You can change the size and shape of the windows and
even move them around the display screen at will.
Menus - Most graphical user interfaces let you execute commands by selecting a choice from a
menu.
Toolbars - Represent a group of buttons that perform related functionality and generally have
icons over them instead of text.
Use of GUI over Command line user interface provides us with the following benefits:
Increase in productivity – for normal users, there is no need for any specific training for the
users to start using a well designed GUI. The users do not need to learn or remember any
commands to effectively use a GUI.
Decrease in training cost and support line cost (saving time and money) – A well designed
and consistent GUI does not require any training for the users. Also the users are less likely to
get stuck while trying to find a way around getting used to the application. Hence the training
and support costs are significantly reduced.
Increase in customer satisfaction (aggravation and frustration are reduced) – Most users are
used to Windows and general graphical tools. Hence a simple, consistent and well-designed
interface will enable the users to get used to a new application faster.
Web User Interface (WUI):
WUI is a subset (or a type of) of Graphical User Interface (GUI). WUI accepts inputs and
provides output by generating web pages which are transmitted via the Internet and viewed by
the user using a web browser program.
A typical WUI is depicted in the image below
47
All Benefits and Attributes that apply to GUI also apply to a WUI.
4.2. What is the need for a good UI
What is the need for a good UI?
For most of the end users, User Interface is the System. Hence the look and feel that a User
Interface provides is one of the major factors that decide the User Satisfaction and User
Experience. For example, if cost isn't a factor for the same function (of making calls), which one
out of the two phones below would you prefer??
A remarkably good User Interface Design can act as the difference between product acceptance
and rejection in the marketplace.
A cumbersome, not easy to learn/ use UI in an otherwise excellent product could result in the
failure of that product. Good User Interface can make a product easy to understand and/or easy
48
to use, which results in greater user acceptance. Poor user interface is the reason why many
software systems are never even used.
A badly designed user interface can cause a user to make catastrophic errors.
The best example of this from real world is the "Butterfly Ballot" used in Palm Beach, Florida
during the 2000 U.S. presidential election which was a fiasco primarily due to the design of a
confusing user interface.
If the designers of that ballot understood the basics of user interface design, there may very well
have been a different outcome to the election.
4.3. Basic steps to be followed for developing a good UI
Just like customers form perceptions about the company by looking at its office or retail shop, in
case of the internet world, a good-looking website is the first experience that your customers
have with a brand online. How they perceive the brand is likely to be influenced quite
significantly by the quality of the UI and the overall experience of the online property.
Users do not care much about what is underneath. But they are actually influenced a lot by what
they experience, what they feel, and what they see. In other words, it is the design quality that
essentially affects the business results.
Good design and user interface not only impact the consumers, but also influence the decision of
potential investors.
49
From a non-designer's perspective, well thought-out and executed design is subtle, yet very
powerful. Product User Interface (UI) and User Experience – regardless of the software, mobile,
or web, the Ease of Use is one of the biggest key factors for its popularity.
The below pointers must be taken into consideration when designing a good User Interface:
Consistency - The most important thing you can possibly do is to ensure that your user interface
works consistently. For eg., if you can double-click on items in one list and produce a certain
action, then you should be able to double-click on items in any other list and have the same kind
of action to happen. Place your buttons in consistent places on all the windows, use the same
kind of wording in labels and alert messages, and use a consistent theme of colors throughout.
Consistency in your user interface makes it easier for the user to get used to the interface quicker.
Be prepared to hold the line - When you are developing the user interface for your system you
will discover that your stakeholders often have some unusual ideas as to how the user interface
should be developed. You may, of course, listen to these ideas but you also need to make your
stakeholders aware of your corporate UI standards and the need to conform to them.
Navigation between major pages - If it is difficult to move from one screen to another, then the
users of your website will obviously become frustrated and give up. When the flow across
screens matches the flow of the work the user is trying to accomplish, it becomes easier for the
users. Because different users work in different ways, the system needs to be flexible enough to
support their various approaches.
Wording the messages and labels effectively - The text displayed on the screens is a primary
source of information for the users of the web application. If the text is worded inappropriately,
then the interface will be perceived poorly by the users. Using full words and sentences, as
against codes and abbreviations, makes the text easier to understand. Messages should be worded
positively, implying that the user is in control, and providing insight into how to use the
application properly. For example, considering the two messages ahead which one do you find
more appealing? ―An account number should be eight digits in length‖ or ―You have input the
wrong information.‖ The messages should also be worded consistently and displayed in a
consistent place on the screen. Although the messages ―The person‘s first name must be input‖
and ―An account number should be input‖ are worded well when looked at separately, however,
together they are inconsistent. A better wording of the second message would be ―The account
number must be input‖ to make the two messages consistent.
Use color appropriately - Color should be used sparingly in the webpages and, if used, a
secondary indicator must also be used. The problem is that some of the users may be color blind
and if color is used to highlight something on a screen, then something else must be done to
make it stand out for those users to notice it. Colors must be used consistently, so as to have a
common look and feel throughout.
Follow the contrast rule - If you are going to use color, you need to ensure that your screens are
still readable. The ideal way to do this is to follow the contrast rule: Use dark text on light
backgrounds and light text on dark backgrounds. Reading dark blue text on a white background
50
is easy, but reading blue text on a dark red background is difficult. The problem is that of enough
contrast not existing between blue and red to make it easy to read, whereas there is adequate
contrast between blue and white.
Expect your users to make mistakes - How many times have you accidentally deleted some
text in one of your files or deleted the file itself? Were you able to recover from these mistakes
or were you forced to redo hours, or even days, of work? The reality is that to err is human, so
you should design your user interface to recover from mistakes made by your users.
Don’t create crowded user interfaces Crowded screens are difficult to understand, and, hence
are difficult to use. Users would not be interested in working with a busy/crowded webpage than
one with limited functionalities spread neatly across the page. Just think whether Google.com
would've got all the popularity if it had not started out as a page with a simple search function?
Group things effectively - Items that are logically connected should be grouped together on the
screen to communicate their connection, whereas items that have nothing to do with each other
should be separated. You can use spaces generously between collections of items to group them
and/or you can put boxes around them.
Basic tools (technology) for User Interface development
Many technologies/tools exist today that could be used for making user friendly user interfaces.
Some of the more modern technologies like ASP.NET, Jsp etc are used, that can make the
webpages interesting and interactive to the uses. Here we focus on two simple tools that are used
for making static pages (pages that hold only the information to be read/consumed by the user) –
HTML and CSS.
HTML:
When you look at a web page in a browser, you see words, at the simplest level. These words
usually appears with some style characteristics, such as different colors and font sizes. Generally,
a page also displays images or may be video. Sometimes there is a form where you can enter (or
search) for information, or change the display of the page to your liking. Sometimes a page
contains animated content and content that changes while the rest of the page remains the same.
Several technologies (such as JavaScript, CSS, AJAX, Flash, JSON) can be used to define the
elements of a web page. However, a web page is defined, at the lowest level, using HTML
(HyperText Markup Language). Without HTML, there will be no web page.
A brief history of HTML
In the late 1980s, Tim Berners-Lee was working as a physicist at CERN (the European
Organization for Nuclear Research). He came up with a way for scientists to share documents
over the Internet. Before his invention, communication via the internet was limited to plain text,
using technologies such as email, FTP (File Transfer Protocol), and Usenet-based discussion
boards. The HTML invention made use of a model of content stored on a central server that
51
could be transferred and displayed on a local workstation via a browser. It simplified content
access and enabled the display of "rich" content (such as sophisticated text formatting and the
display of images).
What is HTML?
HTML is a markup language. It tells the web browser how to display content. HTML separates
"content" (words, images, audio, video, and so on) from "presentation" (the definition of the type
of content and the instructions for how that type of content should be displayed). HTML uses a
set of pre-defined elements to identify content types. Elements contain one or more "tags" that
contain or express content. Tags starts and ends with angle brackets, and the "closing" tag (the
one that indicates the end of the content) is prefixed by a forward slash.
For example, the paragraph element consists of the start tag "<p>" and the closing tag "</p>".
The following example show a paragraph contained within the HTML paragraph element
<p>My dog ate all the guacamole.</p>
The browser uses the tags to indicate how to display the content in the tags.
Elements that contain content can usually also contain other elements. For example, the bold
element ("<b>") can be embedded within a paragraph element:
<p>My dog ate <b>all</b> the guacamole.</p>
When displayed, this looks like the figure above.
Some elements do not contain other elements. For example, the image tag ("<img>") simply
specifies the file name of the content (an image) as an attribute: <img src="smileyface.jpg">
Often a forward slash is placed before the final angle bracket to indicate the end of the tag. In
HTML this is optional, but required in XHTML (which is an XML schema that implements
HTML elements).
HTML Elements — the basic building blocks
52
HTML consists of a set of elements. These elements define the semantic meaning of the content.
Elements include everything between two matching element tags, including the tags themselves.
For instance, the "<p>" element indicates a paragraph; the "<img>" element indicates an image.
Some elements have very precise meaning, as in "this is an image," "this is a heading," or "this is
an ordered list." Others are less specific, such as "this is a section on the page" or "this is part of
the data." Whereas some others are used for technical reasons, such as "this is identifying
information for the page that should not be shown." Regardless of the reason, in one way or
another all HTML elements have a semantic value.
Most elements may contain other elements, forming a hierarchic structure. A complete but a very
simple web page looks like this:
<html>
<body>
<p>My dog ate all the guacamole.</p>
</body>
</html>
As you can see, <html> elements surround the rest of the document, and <body> elements
surround the page content. This structure is often thought of as a tree with branches (in this case,
the <body> and <p> elements) growing from the trunk (<html>). This hierarchical structure is
called the DOM: the Document Object Model.
HTML Tags
HTML documents are written in plain text. It can be written in any text editor that allows content
to be saved as plain text (although most HTML authors prefer to use a specialized editor that
highlights syntax and shows the DOM structure). Tag names may be written in either upper or
lower case. However, the W3C (the global consortium that maintains the HTML standard)
recommends using lower case (and XHTML requires lower case).
HTML attaches special meaning to anything that starts with the less-than sign ("<") and ends
with the greater-than sign (">"). Such markup is called a tag. Here is a simple example:
<p>This is text within a paragraph.</p>
In this example there is a start tag and ends with a closing tag. Closing tags looks the same as the
start tag but also contain a forward slash immediately after the leading less-than sign. Almost all
the elements in HTML are written using both start and closing tags. The starting and closing tags
should be appropriately nested, that is closing tags should be written in the opposite order of the
start tags. Proper nesting is the one rule that must be obeyed in order to write valid code.
53
This is an example of valid code:
<em>I <strong>really</strong> mean that</em>
This is an example of invalid code:
Invalid: <em>I <strong>really</em> mean that</strong>
Note that in the first example, the closing tag for the nested element is placed before the closing
tag for the element in which it is nested.
Some elements do not contain any text content or any other elements as such. Empty elements
such as these need no closing tag. Below is an example:
<img src="smileyface.jpg">
Many people mark up such empty elements by using a trailing forward slash (which is
mandatory in XHTML).
<img src="smileyface.jpg" />
In HTML this slash has no technical functional significance and using it is a pure stylistic choice.
Attributes
The start tag may contain additional information, as in the below example. Such information is
called an attribute. Attributes usually contains 2 parts:
 An attribute name.
 An attribute value.
A few attributes can only have a single value. They are Boolean attributes and may be shortened
by only specifying the attribute name or leaving the attribute value empty. Thus, the below 3
examples have the same meaning:
<input required="required">
<input required="">
<input required>
Attribute values that consist of a single word or number may be written as they are, but when
there are two or more strings of characters in the value, it must be enclosed within quotation
marks. Both single and double quotes are allowed. Most web developers prefer to always use
quotes to make the code less ambiguous to the eye and to avoid mistakes. The below code
includes such a mistake:
54
<p class="foo" bar> (Beware, this probably does not mean what you think it means.)
In the above example the value of class was supposed to be "foo bar" but since there were no
quotes the code is interpreted as if it had been written like this:
<p class="foo" bar="">
Named Character References in HTML
Named character references (often casually called entities) are used to print characters that have
a special meaning in HTML. As seen earlier, HTML interprets the less-than and greater-than
symbols as tag delimiters. When you want to show a greater-than symbol in the page, a named
character reference can be used. There are four common named character references one must
know:
> denotes the greater than sign (>)
< denotes the less than sign (<)
& denotes the ampersand (&)
" denotes double quote (")
The above four are the most important, among many more entries, because they represent
characters that have a special meaning in HTML
Doctype and comments
In addition to tags, entities and text content, an HTML document must contain a doctype
declaration as the first line. This is written like this:
<!DOCTYPE html>
The doctype has a long history, but for now all you may need to know is that this doctype tells
the browser to interpret the HTML and CSS code according to W3C standards and not try to
pretend that it is Internet Explorer from the 90's.
HTML has a mechanism for embedding comments that are not displayed when the page is
rendered in a browser. Comments are very useful for explaining a section of markup, or making
notes for other people who might work on the page, or for leaving some kind of reminders for
yourself. Comments in HTML are enclosed in symbols such as shown below:

A complete but small document
55
Putting this together here is a tiny example of an HTML document. The below text can be copied
to a text editor, save it as myfile.html and open it in using browser. It must be ensured that the
document is saved using the character encoding UTF-8. As this document uses no styling it will
look very plain, but it is only a start.
<!DOCTYPE html>
<html lang="en"
<head>
<meta charset="utf-8" />
<title>A tiny document</title>
</head>
<body>
<h1>Main heading in my document</h1>
<!-- Note that it is "h" + "1", not "h" + the letter "one" →
<p>Loook Ma, I am coding <abbr title="Hyper Text Markup

Language">HTML</abbr>.</p>
</body>
</html>
For further learning of basic HTML please refer to the tutorial in the link below:
www.w3schools.com/html/default.asp
CSS
HTML was originally designed as a simple way of presenting information, with far less
importance given to the aesthetics of a web page than the content (and largely being left up to the
web browser). Now that the web has become as popular as it has, the content presentation has
become almost critical to a website‘s success. CSS is a technology which is a key in
presentation, used to design websites.
56
In the late ‗90s, HTML coders noticed that they were retyping the same old tags again and again
on the same page, leading to larger HTML files and above all, more time was consumed in this
unfruitful process, which further led to frustration. You may also have found yourself in the
same situation, adding in mountains of <font> tags, despite wanting them all the same; or using
tricks like invisible gifs for spacing.
Then, someone had a great idea: have one file that defines all the values that those piles of tags
would have done, and then have the pages checking this file and formatting the content pages
accordingly. You can hence leave out most of the formatting tags in HTML and use only nice
structural elements (such as headings, paragraphs and links) — separating structure and
presentation.
In late 1996 CSS (Cascading StyleSheets) became a reality, acting as a partner to your HTML
code; taking care of all the layout, fonts, colors and overall look of your site.
If you ever decide to change the look of your site, you modify that one CSS file (your style
sheet) and all the HTML pages reading from that file will display accordingly. This makes
maintenance of your design much easier.
CSS Syntax
The syntax for CSS is different than that of HTML markup. It mainly consists of only 3 parts.
selector { property: value }
The selector is the HTML element that you want to style. The property is the title of the actual
property, and the value is the style you apply to that property.
Each selector can have multiple properties, and each of those properties within the selector can
have independent values. The value and property are separated with a colon and contained within
curly brackets. Multiple properties have to be separated by a semi colon. But a comma is used to
separate multiple values within a property, and if an individual value contains more than one
word you surround it with quotation marks. A sample of this is shown below
body {
background: #eeeeee;
font-family: ―Times New Roman‖, Calibri;}
As you can see in the above code we have separated the color from the font-family with a semi-
colon, various fonts are separated with commas and contained the ―Times New Roman‖ within
quotation marks. The end result sets the body color to light gray, and sets the font to ones that
most users will have installed on their computer
Different ways to apply CSS on HTML
57
1. Internal Stylesheet
First we will explore the internal method. Here you are simply placing the CSS code within the
<head></head> tags of each HTML file you want to style with the CSS. The syntax for this is
shown in the example below.
<head>
<title><title>
<style type=‖text/css‖>
CSS Content Goes Here
</style>
</head>
<body>
With this method each HTML file contains the CSS code needed to style the page. This means
that any changes you want to make to one page, the same have to be made to all. This method
works best when you need to style only one page, or if you want individual pages to have
varying styles.
2. External Stylesheet
Next we will explore the external method. Using any text or HTML editor such as 'Notepad', an
external CSS file can be created. A CSS file contains no HTML, only CSS. You simply save it
with the .css file extension. You can associate the file externally by placing one of the following
links in the head section of every HTML file you want to style with the CSS file.
<link rel=‖stylesheet‖ type=‖text/css‖ href=―Path To Stylesheet.css‖ />
Or you can also use the @import method as shown below
<style type=‖text/css‖>@import url(PathToStylesheet.css)</style>
Both these methods are achieved by placing one or the other in the head section as shown in
example below.
<head>
<title></title>
<link rel=‖stylesheet‖ type=‖text/css‖ href=‖Path To Stylesheet.css‖ />
58
</head>
<body>
oder
<head>
<title></title>
<style type=‖text/css‖> @import url(Path To Stylesheet.css) </style>
</head>
<body>
By using an external style sheet, all of your HTML files link to one CSS file in order to style the
pages. Meaning, that if you need to alter the design of all your pages, you only need to edit one
.css file to make global changes to your entire website.
Here are a few reasons this is better
 Easier Maintenance
 Reduced File Size
 Reduced Bandwidth
 Improved Flexibility
3. Inline Styles
In a way this method of stylesheets defeat the purpose of using CSS in the first place. Inline
styles are defined right in the HTML file along side the element you want to style. An example is
shown below.
<p style=‖color: #ff0000;‖>Sample red text</p>
Inline styles does NOT allow the user to change styles of elements or text formatted this way
Which is better?
So with all these various ways of inserting CSS into your HTML files, you may now be
wondering which is better, and if more than one method is used, in what order do these different
ways load into the browser?
All the different methods will cascade into a new ―pseudo‖ stylesheet in the following order:
1. Inline Style (inside HTML element)
59
2. Internal Style Sheet (inside the <head> tag)
3. External Style Sheet
As far as which way is better, depends on what you want to do. If only one file need to be styled
then placing it within the <head></head> tags (internal) will work fine. Whereas if you are
planning on styling multiple files then the external file method is the way to go.
Choosing between the <link related=> & the @import methods are completely up to you. I will
mention that the @import method may take a second longer to read the CSS file in Internet
Explorer than the option.
To learn how to implement CSS in HTML pages, refer the link below
www.w3schools.com/css/default.asp
Fazit
With the use of HTML and CSS you'd be able to develop attractive looking webpages. But these
webpages would only contain static information. That is the users can only read/consume the
information that you have on the pages. No user interaction would be possible with static pages.
But the good news is, there are various other technologies using which the webpages can be
made dynamic. Examples of those technologies are asp.net, jsp, javascript etc. The discussion on
specific technologies are out of the scope of this curriculum. However for further reading you
may refer the website below.
JavaScript : www.w3schools.com/js/default.asp
ASP.NET : www.w3schools.com/aspnet/default.asp
JSP : www.tutorialspoint.com/jsp/index.htm
60
5.Programming Approaches
5.1. Structured Programming
Einführung
Organizations and individuals are continually searching for more efficient ways to perform the
software development process. One way of lowering the time and cost of development is to
standardize software programs and the process of programming. The benefits of standardized
programs are that they are easier to code, maintain, debug, and modify. In recent years, many
different techniques have appeared attempting to minimize differences in the way programmers'
design and develop software
Programming Approaches: Structured Vs Non-Structured Approaches
Structured programming is a standardization technique used for software development. The

structured approach works by having all programmers use the same structured design techniques.
Structured programming is used to address the shortcomings of non-structured programming,
which frequently used the GO TO branch points to transfer from one part of the program to
another part. Using GO TO codes, one could transfer backward, forward, or anywhere else
within the program. The problem is that the connections between parts of the program by using
GO TO commands can become quite haphazard.
The haphazard and sometimes convoluted pattern of linkages between parts of the program is
called spaghetti code. This way of programming is difficult to understand and debug. Non-
structured programming is now viewed as an ineffective programming strategy. To develop good
software, developers have to carefully think out and design the programs. In the earliest days of
computing, programmers developed code according to their own whims, with the result that the
software was often confusing and difficult to work with. Software today is expected to follow
recognized design principles. The prevailing design standards are structured programming and
structured design.
Structured Programming
Structured programming makes use of the control structures (sequence, selection and repetition).
Structured programming does not use GO TO commands. The principle of sequences implies
that program instructions should be executed in the order in which they appear. The principle of
selection implies that instructions may be executed selectively using IF-THEN and/or IF-THEN-
ELSE statements. These conditional statements work in the following way. IF a condition is true
or is met, THEN a specific set of instructions will be executed.
If the condition is false, then another set of instructions will be executed. For example, if an
employee works for more than 40 hours a week, THEN calculate his gross pay based on an
overtime rate of 50% more than his normal hourly pay. If the employee work 40 hours or less a
week, THEN calculate gross pay based on the normal hourly rate of pay. IF-THEN-ELSE works
the same way, but in this case the word ELSE is substituted with a false case, a condition not
61
met. IF the employee works more than 40 hours a week, then calculate gross pay based on a time
and a half the rate, ELSE calculate gross pay based on the normal rate. Alternatively when there
are many options, one can employ the CASE statement. The iteration principle indicates that one
part of the program can be repeated or iterated a limited number of times. In most computer
languages, the repetition or iteration may be activated by using REPEAT ---UNTIL or using the
WHILE loop and the FOR loop.
Structured Design
According to structured design principles, a program should be designed from the top-down or
bottom-up as a hierarchical series of modules. A module is a logical way of partitioning or
subdividing a program so that each module performs one or a small number of related tasks.
5.2. Modular Programming
The Modular approach to programming involves breaking a program down into sub-components
called modules. Every module consists of an independent or self-contained set of instructions.
Modules are also called as routines, subroutines, or procedures or subprograms. Each of these
modules is designed to perform a specific task in the overall program, like calculating the gross
pay of an employee in a payroll program. The advantage of modular approach is the ability to
write and test each module independently and in some cases reuse modules in another program.
A program consists of multiple modules. Additionly, there is a main module in the program that
executes the other modules. You can use the following approaches in order to design a program
consisting of modules.
Top-Down Design or Top-Down Decomposition
One programming approach that is proven to be most productive is called top-down

decomposition. This is the process of breaking the overall procedure or task into component
parts (modules) and then subdividing each component module until we reach the lowest level of
detail. It is called top-down design or top-down decomposition since we start "at the top" with a
general problem and design specific solutions to its sub problems. To obtain an effective solution
for the main problem, it is desirable that the sub-problems (subprograms) should be independent
of each other. Then each sub-problem can be solved and tested by itself. The top level of the
decomposition is the level of the overall plan. Unfortunately there is no single formula that will
decompose a complex problem into individual tasks. The strategy involves top-down reduction
of the processing until a level is reached where each of the individual processes consists of one
self-contained task, which is relatively easy to understand and can be programmed in a few
instructions. This stepwise process may create multiple layers or levels of modules beginning
with a main module at the top. The middle level might contain intermediate modules, and minor
modules at the third level. From the top the program is developed in a stepwise fashion. Using
this method, a complex problem is separated into simpler parts, which can be easily
programmed. At every stage, the instructions or steps can be checked for errors in logic,
corrected or modified without any effect on the other subprograms. The result will be a truly
modular program that satisfies the requirement, which says, 'a good program can be easily
modified'. This programming strategy focuses on developing a software program conceptually
62
before coding commences. A programming team will likely create a diagram that looks much
like an organizational chart with the main module at the top and subordinate modules down
below connected by lines with each box representing a program module. The chart shows how
modules relate to each other but does not depict the details of the program instructions in every
module. The structure chart is often referred to as a Hierarchical Program Organization (HIPO).
Example top-down decomposition
The company's payroll system can contain the following modules or tasks
 Master file
 Earnings
 Deductions
 TaxingNet
 earning
 Print reports
The tasks given above can be shown by a hierarchical chart (Hierarchical Program Organization)
as shown below.
Identifying and diagramming the relationship between modules in this fashion allows
programmers to focus on the overall organization and logic of the program without getting
bogged down in the details. After the overall structure of the program is finalized, detailed
coding of individual modules can proceed. It is the set of principles that enable a problem to be
solved by breaking it down into manageable smaller parts, step by step from the overall problem
specification, in stages through to the actual code.
63
Bottom-up Design
Already existing facilities/designs are used/taken into consideration as a model for a new (better)
design. With the use of Bottom-up design strategy, we take an already existing computer
program as a model for our new program. We try to utilize the existing facilities or design in a
way, which gives out program a better performance.
Stepwise Refinement
Stepwise refinement is a top-down design strategy. The program is developed by successively

refining levels of procedural detail. In every refinement step, one or several instructions of the
given program are decomposed into more detailed ones. This successive decomposition or
refinement of specifications terminates when all instructions are expressed in terms of any
underlying computer or programming language. Each step of refinement implies some design
decisions. It is important that the programmer is aware of the underlying criteria.
Sub Programs
In top down design, the problem is broken down into sub-problems. The main problem is solved
by the corresponding main program. The sub-problems solutions are provided by subprograms,
known as subroutine, functions, or procedures depending on the programming language. A
subprogram executes or performs the computer instructions required to solve a given
subproblem.
User defined Sub Programs and Functions
A Sub Program is a part of a program that performs one or more related tasks, has its own name,
is written as a separate part of the program, and is accessed via a call statement. A Function
returns a value to the program and shares many of the same characteristics as a Sub Program
(e.g., has its own name, is written as a separate part of the program).
Pros and Cons of Using Procedures
 Disadvantage -- Procedure calls consume execution time and memory.

 Advantage -- Procedures make the program easier to write, test, debug and maintain.
64
Within a program we can normally identify sub-tasks that are performing a specific function.
Where program features clearly identify sub-tasks it is good practice to implement each sub-task
on its own, stand-alone, sub-program.
There are considerable advantages of a separate sub-program such as:
 A stand-alone sub-program can be developed and tested independently.

 Once programmed, the sub-program can be called a number of times within a program.
 The sub-program is called by a meaningful name chosen by the programmer, which helps greatly
in understanding the code.
 The sub-program can be re-used in subsequent programs.
The ability to reuse a sub-program is obviously useful. We can include an existing subprogram in
another program whenever you need it.
Procedures and Functions
A function or procedure is a sub-program that exists to perform a specific, single task. It has its
own inputs and its own outputs (often called parameters), it can also define its own variables. It
may return the values to the referencing or invoking program or procedure A function is a special
sort of procedure that has a single output.
Procedures
A procedure has a header, followed by declarations of variables used within the procedure
known as local variables (identifiers) and finally statements that are to be performed when the
procedure is invoked. The procedure header is the mechanism used to give a name to the
procedure. The procedure header also may contain the values that can be communicated between
the procedure and its invocation known as parameters.
The common structure for defining a procedure (in C++) is:
void Procedure_Name(parameter)
65
{
. //List of Statements.
Example:
void WelcomeNote ()
Cout<<‖Say Hello to Programming Concepts‖;
Procedures in c++ start with the keyword void.
Functions
The general structure for defining a function (in C++) is:
Data_type Function_Name(parameter)
Return statement;
Example:
float Cube (float x)
float product;
product = x*x*x;
66
return product;
The most important thing to note is that the function must have a result type which dictates what
type of value the function represents.
A function is a special sort of sub-program - it is used when a sub-program is needed which takes
a number of inputs and returns a single output value (as with cube above). This is typical of
many algebraic functions (sine, cosine, exp, log, cube) but is otherwise fairly unusual since the
sub-programs that we want to define quite often have either no output at all or very many outputs
- in these cases we use a procedure.
Parameters
As we've seen, procedures and functions can take a list of quantities called parameters. Initially
you might like to regard the parameters as the inputs to the module (but this is not always true).
For example:
void sumAndDifference( float a, float b)
a = a+b;
b = a-b;
cout<<"The sum is "<<a;
cout<<"The difference is"<<b;
Both total and difference are local variables and only exist within the procedure, as soon as the
procedure finishes they and their values disappear. The following program is an example of the
main program:
void main()
float val1, val2;
67
val1=2;
val2=4;
sum_and_difference(val1,val2);
cout<<val1;
The values of val1 and val2 are simply copied into the variables a and b of the procedure
sumAndDifference. At the end of the procedure the values are not copied back! The value of
val1 that the final output statement displays is therefore 2 (not 0).
Sometimes however, we would like the values to be copied back at the end of the procedure.
This is particularly true if there is more than one output of the procedure, as in the case of
sumAndDifference. The sum and difference cannot be passed back together as the return value
of a function, as a function can return only a single value.
void sumAndDifference( float a, float b, float &s, float &d)
s =a+b;
d =a-b;
void main()
float val1, val2;
float total, difference;
val1=2;
val2=4;
sum_and_difference(val1,val2, total, difference);
cout<<The sum is <<total;
cout<<The difference is<<difference;
68
}
The symbol & in the procedure parameter list instructs the computer to copy back any changes to
the values of a and b once the procedure has completed. In summary, if you want to write a sub-
program that has a number of inputs and a single output, write a function. If you want many
outputs from the sub-programs, use a number of var parameters in a procedure.
Built in functions
While most programming languages enable you to write your own functions (as above), most
also provide a library of common functions ready for you to use (e.g. sine, cosine).
A common example of built-in function is the Printf function in C language. (Or any function
used for printing out values in console in any language; System.Out.Println function in case of
Java). This function is implemented and is available to the programmer to use any time he wants.
Normally, the programmer is not bothered how the function is implemented in the framework or
how the compiler of the language work with this function.
69
6.Code optimization techniques
6.1. Introduction to optimization
Meaning and scope of optimization
In olden days when computers had less memory, developers would some times chose a slower
algorithm in order to ensure that the program would consume less memory. Later when
computers with higher memory became available, developers tried to minimize the amount of
time that a program consumed to perform some task by utilising the additional memory
available. Optimization generally focussed on improving just one or two aspects of performance:
execution time, memory usage, disk space, bandwidth, power consumption or some other
resource.
But in modern days, the goal of optimization is to make programs faster and at the same time, to
ensure that program occupies lesser memory in the computer's memory.
Need for program optimization
Just like software defects, the cost of optimizing a program increases exponentially with every
phase of SDLC, after the development phase, and even more, after the application is deployed
for use in the world.
Code optimization - best approach
The main focus and scope of the best approach tells you the various optimization techniques that
can be applied at the source code level.
High level optimization should be completed before low level optimization.
Choice of the best possible algorithm within the program, within functions, within the class,
should be done first, before applying other optimization principles.
A developer/designer should think about improving algorithms first before doing some code
optimization.
Double check if you use the correct collection types. Then have a look if you accidentally
created more objects than needed (object creation in loops is a typical reason for performance
problems).
High level optimization is to be done in the source code, and low level optimization is done at
the compiled-code level. Low level optimization may be good on some platforms and bad on
other platforms.
70
6.2. Code optimization strategy
Code optimization - when to begin
Optimize the source code, around the time developer completes a preliminary developer version
of the program.
Ideally all developers should have a list of best approaches that result in optimized code, before
starting to code.
Detailed optimization should not be started before developer completes an initial version of the
code. Programmer should not let performance considerations affect the design of a piece of code.
Detailed performance should be considered only after the design of the code is complete.
Code optimization - where to begin
Identify the parts of the application or program executed more frequently or which consume
more execution time. 80 or 90 % of a program's execution time may be spent executing 20% or
10% of the code (Pareto principle).
So we should first optimize that 20% or 10% of the program identified accordingly.
Some classes or functions within classes may be used more frequently than others.
6.3. Standard techniques list
 Common sub-expression/ Code grouping.

 Unrolling loop.
 Functional optimization
 Avoid unused variables and parameters
71
 Finding/Selection of effective algorithms.
Common sub-expression/ Code grouping.
Certain sub expressions may be common in several lines of code. In such a program when each
line of code gets executed, a common sub-expression gets executed and its same value gets
calculated, repetitively. This happens in many lines, even though it has the same value. In this
case, we should compute the common sub-expression only once and that variable, holding the
computed value of the common sub-expression should be used.
Certain parts of an expression may yield a constant value within certain scopes within the
program or function, such as within many blocks of a function, but may change only in few
blocks where re-computation is necessary. In such situations, based on the program context, we
may move the repetitive code into a constant in many scopes where it would be constant, and
substitute the original expression only in the few scopes (blocks etc) where it may be subject to
change. This code-grouping is an advanced form of common sub-expression.
You may also have situations in which certain temporary variables may be declared just once
outside loops and be re-assigned within the loop.
Non optimized common sub expression
function runWithoutIdentifyingCommonSubExpressions() {
j=0;
for( i=36000000;i>0;i--)
j += (i-sqrt(i)-sqrt(sqrt(i)))/sqrt(123456)+(i-sqrt(i)-sqrt(sqrt(i)))/sqrt(654321);
print(j);
Optimized common sub expression
function runWithoutIdentifyingCommonSubExpressions() {
j=0;
commonValueInAllLoopIterations = 1/sqrt(123456)+1/sqrt(654321);
72
//Above expression with same value in all iterations taken outside to make loop faster.
for( i=36000000;i>0;i--)
j += (i-sqrt(i)-sqrt(sqrt(i)));
j=j*commonValueInAllLoopIterations
print(j);
In the above program the common sub expression is evaluated by multiplying the value of the
variable 'commonValueInAllLoopIterations' residing outside the for loop with value that is
stored in the variable 'j'.
Unrolling loops
Sometimes we use nested for-loops while the same task can be done with a single for-loop.
Sometimes we may be sure that a certain loop may get executed even number of times. In such a
situation, we may increment the loop counter by 2, and use an additional line or block of code
based on the next value of the current loop-index. For example, if we know that n= an even
number always, then the following code will reduce the number of loop iterations.
double x = 0;
for(int n=0 ; n <= 10000 ; n += 2)
x+=Math.sqrt(n);
fnXyzAddsModifiedResultToDynamicLiveFile(x);
x+=Math.sqrt(n+1);
fnXyzAddsModifiedResultToDynamicLiveFile(x);
Functional optimization
73
Programmers sometimes write code in a modular fashion which allows for several programmers
to work independently on separate concepts. These can be assembled at a later stage to create the
entire project. This concept forms the foundation of procedures or routines. Well-structured,
modular code is easier to write, debug, understand, and reuse.
When a method is invoked (called), a request is made to perform some action, such as setting a
value, printing statements, returning an answer, etc. The code to invoke the method contains the
name of the method to be executed and any needed data that the receiving method requires. The
required data for a method is specified in the method's parameter list.
Let us consider one example.
We need to calculate the salary of an employee. The salary has got three components- Basic, DA
and HRA. The DA is 10% of basic and HRA and 5% of Basic. The total salary would be the sum
of all three. Lets see one way of implementing this:
Before Modularizing
calculateTotalSalary()
basic=10000; //Assuming basic to be 10000
totalSalary=0;
da=(10000*0.1);
hra=(10000*0.05);
totalSalary=basic+da+hra;
print totalSalary;
This would give us the output, but it is a poor code from a reuse point of view. In case at a later
time da or hra calculation changes, we need to change it at different places.
This is where modularity comes to the picture. The same code can be modularized as follows:
After Modularizing
calculateHRA( basic)
74
hra=(basic*0.05);
return hra;
calculateDA( basic)
da=(basic*0.1);
return da;
calculateTotalSalary()
basic=10000; //Assuming basic to be 10000
totalSalary=0;
totalSalary=basic+calculateHRA(basic)+calculateDA( basic);
print totalSalary;
Now, when da or hra calculation changes, we just have to change it at the correct function. Also,
in case we have some other functionality that requires the da or the hra alone, they can just call
the corresponding function.
Avoid unused parameters and variables
Please consider the function given below. We will identify at least 3 points using which we can
further optimize the code snippet provided below, based on this principle.
calculateTotalSalary(double basicPay,double firstBasicPay)
double salary=100;
double salary=basicPay;
75
double totalSalary=0;
double da=(10000*0.1);
double hra=(10000*0.05);
double totalSalary=basic+da+hra;
print(totalSalary);
Here firstBasicPay is an input parameter to the function. But it is not used anywhere else in the
program. So while calling this function firstBasicPay should be compulsorily passed, even
though it is not required currently. This would lead to unnecessary memory allocation for the
parameter firstBasicPay.
Similarly salary is an unused variable initialized to the value 100.
Again, in the above program, the passed-in basicPay may be directly used without re-assigning
to basic.
So avoiding unused parameters and unused variables in writing a function leads to better
optimization technique in writing the function.
Finding/Selection of effective algorithms
Finding or selecting an effective algorithm for the computational task or the procedure in general
is a must before resorting to any other kind of optimization.
A good optimization is choosing a fast algorithm. A computational task can be performed in

several different ways with varying efficiency. For example, consider the following code snippet
whose intention is to obtain the sum of all integers from 1 to N:
Before Optimization
/**
* This function sumOfIntegers intention is to obtain the sum of all
* integers from 1 to N.
* Below code snippet calculates the sum by simply looping the value of N
76
*
* @parameter n - means the input value
*/
function sumOfIntegers(int n)
int i, sum = 0; // declare the variables i, sum
for (i = 1; i <= n; ++i) { // loop through till satisfies the condition i <= n
sum += i; // sum = sum + i
print ("sum : " + sum);
After Optimization
function sumOfIntegers(int n)
int sum = n * (1 + n) / 2;
print ("sum : " + sum);
In the above program 1/sqrt(123456) and 1/sqrt(654321) are sub expressions which are repeated
for every iteration. This can be modified by defining a common sub expression, in which the
above example can be modified.
6.4. Code optimization summary
Points of care
 The time taken to undertake optimization should be carefully decided.

 Optimizing existing code usually does not add new features.
 Be sure to ensure that no new bugs are added during optimization.
 Readability should not be lost after optimizing the unoptimized code.
77
 Maintainability should not be impacted after optimizing the unoptimized code.
 Be careful when optimizing large programs that already work without bugs.
If programmers follow the above principles, then programs will not be complicated by the
optimization and programmer will not be distracted by optimizing.
Code optimization summary
The optimization of code may begin at two steps in case of individual classes and functions.
While starting to code, certain basic principles of code optimization may be kept in mind, which
are based on common sense. Advanced optimization may begin, once the most frequently
executed areas of the programs and frequently used functions are identified.
78
7.Testing and Debugging
7.1. Introduction to Testing - Correctness of a software, Testing Approaches
What is testing?
Testing is the process of evaluating a system and/or its components with the intent to find out
whether it satisfies the stated requirements or not. This testing activity will give the actual and
expected, and, the difference between actual and expected results. In other words testing means
executing a system in order to identify any gaps, errors or missing requirements when compared
with the actual or desired requirements.
Consider a situation where the client has asked to develop a banking application which should
have functionality like cash withdrawal, funds transfer, account summary, SMS facility etc.
This application was developed and delivered to the client with a few bugs in it. The end users
(customers of bank) will face problems due to bugs which were missed out without proper
testing. The customer will be dissatisfied and sometimes sue the bank. To prevent these kind of
scenarios testing is done.
Software testing can be stated as the process of validating and verifying a computer
program/application/product:
 Meets the requirements which will guide the further design and development.
 To confirm whether the system works as expected.
 To confirm whether it can be implemented with the same characteristics.
 To confirm whether it satisfies the stakeholders needs
Testing is thus part of overall Quality Assurance (QA) from which we will be able to measure
the quality of any software application. The software should meet its specified standards during
its development cycle.
Software testing can be implemented at any time in the development process depending on the
testing method employed. Test designing will start at the beginning of the project well before
coding and thus will help to save a huge amount of the rework effort and resources.
7.2. Who does testing?
It depends on the process and the associated stakeholders of the project(s). Stakeholder can be
referred to all the people who are part of the project being executed. Stakeholders are those
people who are having an interest in the successful completion of the project. The important
thing to remember is that the stakeholders should also have some say in defining the project
objectives, since they are the people who will be affected by the outcome. When defining project
stakeholders, the project manager and members of his/her team should carefully think through
who will be the end users of the product. Project stakeholders usually include Customers/clients,
company, project team including project manager, senior managers etc.
79
In the IT industry, large companies have teams with responsibilities to evaluate the software
developed in the context of the stated requirements. Moreover, developers will also conduct
testing which is called Unit Testing, which is explained later in the document. In most of the
cases, the below professionals are involved in the testing of a system.
 Test analyst / Test Manager.

 Software Tester.
 Software Developer.
 End User.
Test analyst / Test Manager
During Test Planning phase, the activities carried out in Test Strategy (A Test Strategy document
is a high level document normally developed by project manager. This document defines Testing
Approach to clarify the major tasks and challenges of the test project) phase will be detailed and
more application specific data will be collected. The above mentioned details along with the
schedule of the project will be documented in the test plan.
Software Tester
The role of a software tester is mainly to write the test cases and perform integration/system
testing.
End User
The Acceptance testing is done by the end user at the end of the project.
7.3. Test approaches:-Top-down and bottom-up
Bottom-Up Testing is an approach to integrated testing where the lowest level components -
modules, procedures or functions - are tested first, then integrated and this will be used to
80
facilitate the testing of higher level components. After the integration testing of lower level
modules, the next level of modules will be taken and can be used for further integration testing.
The process is repeated until the components at the top of the hierarchy are tested. This type of
approach is helpful only when all or most of the modules of the same development level are
ready. This method also helps to determine the levels of each software module developed and
makes it easier for reporting the testing progress which can be given in percentages.
Top-Down: This type of testing is an approach to integrated testing where the top integrated
modules are tested first and the branch of the module is tested step-by-step until the end of the
related module.
In both method stubs and drivers are used to stand-in for missing components and are replaced as
and when the levels are completed. For eg: If we have Modules x, y, z. 'x' module is ready and
need to test it. But it calls functions from y and z (which are not ready). To test a particular
module we write dummy piece of code which simulates y and z which will return values for x.
These pieces of dummy code are called stubs in a Top Down Integration.
Now consider that modules y and z are ready and module x is not ready, and we need to test y
and z which return values from x. So to get the values from 'x' we write a dummy code for 'x'
which returns values for y and z. These pieces of dummy code are called drivers in Bottom Up
Integration.
7.4. Levels of Testing - Overview, Unit Testing, Integration Testing, System

Testing, Acceptance Testing
Levels of testing include the different methodologies that can be used while conducting Software
Testing. Following are the 2 aspects on which the Software Testing is carried out:
Functional Testing.
Non-Functional Testing.
Functional Testing:
Testing the application taking into consideration the business requirements. Functional testing is
done using the functional specifications provided by the client or by using the design
specifications like use cases provided by the clients.
 Functional Testing covers:

 Unit Testing.
 Integration Testing (Top Down and Bottom up Testing).
 System Testing.
 User Acceptance Testing.
Example
81
Consider the example of the banking ATM which will have different functionalities like cash
withdrawal, deposit, balance inquiry, account summary etc.
Unit testing will include developing programs for each functionality mentioned and testing them.
Integration testing includes combining all the modules so that the information is passed correctly
from one module to another. Say if an account has an initial amount of 1000 INR and if we
deposit an amount of 2000 INR to the account then the balance inquiry should be an amount of
3000 INR.
Comprehensive black box testing of banking system with transactions initiated and validations
performed on databases and reports generated while doing the account balance summary.
Unit Testing
This type of testing is performed by the developers before the product/application is handed over
to the testing team to formally execute the test cases. Unit testing is performed by the software
developers on the individual units of source code assigned to them. The developers use test data
that is separate from the test data of the quality assurance team.
The goal of unit testing is to isolate each part of the program and show that the individual parts
are working correctly in terms of requirements and functionality.
The limitations of Unit Testing are as follows:
Testing cannot catch each and every bug in an application. It is impossible to evaluate every
execution path in a software application. The same is the case with unit testing.
There is a limit to the number of scenarios and test data that the developer can use to verify the
source code. So after the developer has exhausted all options there is no other choice but to stop
unit testing and combine the code segments with other units.
Integration Testing
The testing of combined parts of an application to determine if they function correctly together is
Integration testing. There are two methods of doing Integration Testing; Bottom-up Integration
testing and Top Down Integration testing which were already explained.
Bottom-up integration:
This type of testing begins with unit testing, followed by tests of progressively higher level
combinations of units/programs called modules.
Top-Down integration:
82
In this testing, the highest/top level modules are first tested and then progressively lower-level
modules are tested.
In a comprehensive software development environment, bottom-up testing is usually done first,

followed by top-down testing. The process will finally conclude with multiple tests of the
complete application, preferably in scenarios which are designed to mimic the environment
which will be encountered in customers' computers, systems and network.
System Testing
This is the next level in testing in which we test the whole system. Once all the components are
integrated, the entire application is tested rigorously to see whether it meets the quality standards.
This type of testing is usually performed by a specialized testing team.
System testing is very important because of the following reasons:
1.System Testing is the first step in the Software Development Life Cycle, where the entire
application is tested.
2.The application will be tested thoroughly to verify that it meets the functional and technical
specifications.
3.The application is tested in an test environment which is very close to the production
environment where the application will be deployed later.
4.System Testing enables us to test, verify and validate both the business requirements and the
Applications Architecture.
Acceptance Testing
This is the most important type of testing as it is conducted by the Quality Assurance Team who
will gauge whether the application meets the intended specifications and satisfies the client's
requirements. The QA team (Alpha testing) will have a set of pre written scenarios and Test
Cases that will be used to test the application. Alpha testing is a form of internal acceptance
testing performed mainly by in-house software QA and testing teams. We also have Beta testing
which the is the final testing phase where companies release the software for few external user
groups outside the company test teams or employees.
More ideas will be shared about the application and more tests can be performed on it to
determine its accuracy and the reasons why the project was initiated. Acceptance testing is done
not only to point out simple spelling mistakes, cosmetic errors or Interface gaps, but also to point
out any bugs in the application that will result in system crashes or major errors in the
application at a later stage.
By performing acceptance tests on an application, the testing team will get to know how the
application will perform in production environment. There may also be legal and contractual
83
requirements for acceptance of the system. In such cases the application should satisfy the above
requirements before it is accepted by the client.
Non-Functional Testing:
Testing the application against client's and performance requirement. Non-Functioning testing is
done based on the requirements and test scenarios given by the client.
 Non-Functional Testing covers:

 Load and Performance Testing
 Stress & Volume Testing
 Compatibility & Migration Testing
 Data Conversion Testing
 Operational Readiness Testing
 Security Testing
 Performance testing
You will get to learn more on non functional testing once you are into projects.
7.5. Test Techniques - Black box testing, White box testing
Black box testing
Black box testing takes an external perspective of the test object (the entire application) to derive
test cases. These tests can be functional or non-functional, though usually it is functional. The
test designer selects valid and invalid input and determines the correct output. There is no
knowledge of the test object's internal structure, which means, the tester will not be having any
idea on the application's code but knows how the application behaves in response to a particular
input
Black box testing technique is applicable to all levels of software testing: unit, integration,
functional testing, system and acceptance. The higher the level goes, more complex and bigger
the box becomes, hence one is forced to use black box testing to simplify. However one cannot
be 100 percent sure that all existent paths are tested.
84
Black Box Testing is a testing strategy and not a type of testing; and this does not need any
knowledge of internal design or code. As the name "black box" suggests, the tester doesn't
require any knowledge of internal logic or code structure. These types of testing are totally
focused on the testing for requirements and functionality of the product/software application.
Black box testing is also called as "Opaque Testing", "Functional/Behavioral Testing" or "Closed
Box Testing".
In order to implement the Black Box Testing Strategy, tester should be thorough with the
requirement specifications of the system and as a user should be knowing how the system should
behave in response to a particular action. Some of the black box testing methods are Boundary
value analysis, Equivalence partition etc.
Test Techniques - Black box testing, White box testing
We will illustrate the above 2 methods by an example.
There is a store which has introduced discounts for its customers based on their purchase
amounts. The discounts are as per the table below. We have to do the testing of this system.
To find test cases based on equivalence partitioning,
First, we need to find the variables(inputs and outputs for the system). And then do partitioning
based on the input ranges.
Inputs here are : Purchase amount and Customer type
Output : Discounted bill amount
85
Variable 1
Purchase_Amount (p_amt)
Total range is : all keys in keyboard. But valid range is only numbers. So if we partition them,
the classes are:
 Non numeric (invalid class C1)

 Numeric
negative & zero (<0) (invalid class. As we will not purchase for amount of 0 or less that is an
invalid input) C2
positive (>0)
 [1..499] C3 Valid
 [500..4999] C4 valid
 [5000.. MAX] C5 valid
 [> MAX] C6 invalid
Variable 2
Customer Type (cust_type):
M (member) C1
NM (non member) C2
So test cases are a combination of both the variables
Now for boundary value analysis:
Pick the valid classes, and the boundary values are:
Customer type [M, NM]
86
So test cases can be formed with permutation combination of the two variables here.
Advantages of Black Box Testing
 Tester can be non-technical.

 Used to verify contradictions in actual system and the specifications.
 Test cases can be designed as soon as the functional specifications are complete.
Disadvantages of Black Box Testing
 The test inputs need to be from large sample space. That is, from a huge set of data which
will take time. Also it is difficult to identify all possible inputs in limited testing time. So
writing test cases is slow and difficult.
 Chances are more that there will be unidentified paths during this testing.
White box testing
White box testing is a security testing method that can be used to validate whether the code
which is implemented follows the intended design, to validate necessary security functionality,
and to find other vulnerabilities.
The first step in planning the white box testing is to develop a test strategy which is based on risk
analysis. The purpose of a test strategy is to clarify the major activities involved, key decisions to
be made, and challenges faced in the testing effort. This includes identifying testing scope,
testing techniques, coverage metrics, test environment, and skill of the testing resources.
The test strategy must account for the fact that time and budget constraints will prevent testing
each and every component of a software system and should balance test effectiveness with test
efficiency based on risks to the system. The level of effectiveness necessarily depends on the use
of software and its consequence of failure. The higher the cost of failure for software, then a
87
more rigorous and sophisticated testing approach must be adopted to ensure effectiveness. Risk
analysis provides the right context and information to derive a test strategy.
Advantages of White Box Testing :
 To start the white box testing of the desired application there is no need to wait for
userface (UI) to be completed Covers all possible paths of code which will ensure a
thorough testing.
 It helps in checking coding standards.
 Tester can ask about implementation of each section, so it might be possible to remove
unused/dead lines of codes helps in reducing the number of test cases to be executed
during black box testing.
 As the tester is aware of internal coding structure, then it is helpful to derive which type
of input data is needed to test the software application effectively.
 White box testing allows you to help in code optimization
Disadvantages of White Box Testing :
 To test the software application a highly skilled resource is required to carry out testing
who has good knowledge of internal structure of the code which will increase the cost.
 Updating the test script is required if there is change in requirement too frequently.
 If the application to be tested is large in size, then exhaustive testing is impossible.
 It is not possible for testing each and every path/condition of software program, which
might miss the defects in code.
 White box testing is a very expensive type of testing.
 To test each paths or conditions may require different input conditions, so inorder to test
full application, the tester need to create range of inputs which may be a time consuming.
How do you perform White Box Testing?
Consider the example to find sum of two numbers.
Pseudocode:
Read a.
Read b.
sum = a + b.
print sum.
We check code for two types of errors:
 Syntactic Errors.
 Logical Errors
88
Syntactic Errors:
Every programming language has its own grammar rules. Error in these rules are considered part
of syntactic errors. Like in 'c' language, semicolon is mandatory at the end of each line.
Logical Errors:
It is an error in the logic applied. For Instance, To add two number say a and b, mistakenly the
developer may write it as a - b , instead of a + b, its a logical error Code is verified for both
syntactic error and logical error by passing multiple set of data. From the above example we can
see that for performing white box testing, we have to come up with two basic steps. The
following points explain what testers do in white box testing technique:
Step 1) Understand the source code
The first thing a tester will do is to learn and understand the source code of the application. Since
white box testing involves the testing of the inner workings of an application, the tester must
have good knowledge in the programming languages used in the applications they are testing.
Also, the tester must be highly aware of secure coding practices. Security is often one of the
primary objectives of testing software. The tester should be able to find security issues and
prevent attacks from hackers and inexperienced users who might inject malicious code into the
application either knowingly or unknowingly.
Step 2) Create test cases and execute
The second step in white box testing involves testing the application's source code for proper
flow and structure. One way of achieving this is by writing more code to test the application?s
source code. The tester will develop small tests for each process or series of processes in the
application. This method requires that the tester must have thorough knowledge of the source
code and is often done by the developers. Other methods include manual testing, trial and error
testing, use of testing tools etc.
7.6. When to start and stop testing
When to Start Testing?
An early start to testing can help reduces the cost, time to rework and error free software can be
delivered to the client. However in Software Development Life Cycle (SDLC) testing can be
started from the Requirements Gathering phase and will continue till the deployment of the
software. However it also depends on the development model that is being used. In a Water fall
model, which is one of the commonly used development model, formal testing is conducted in
the testing phase, but in incremental model (another type of model), testing is performed at the
end of every increment/iteration and at the end, the entire application is tested again.
Testing is done in different forms at every phase of SDLC as given below.
89
 During requirement gathering phase, the analysis and verifications of requirements are
also considered as testing.
 In the design phase while reviewing the design with an intent to improve the design is
also considered as testing.
 Testing performed by a developer on completion of the code can also be called as Unit
type of testing.
When to Stop Testing?
It is difficult to determine when to stop testing as compared to start testing, as testing is a never
ending process and no one can demand that any software is 100% fully tested. Testing needs to
be stopped as and when it has met the completion criteria.
Now how can we find out the completion criteria? Completion criteria can be derived from the
test plan and test strategy document and also by rechecking the test coverage.
Completion criteria should usually be based on Risks. Testing should be stopped when :
 Test cases completed with certain percentage passed and test coverage is achieved.
 There are no known critical bugs open after testing.
 Coverage of code, functionality, or requirements reaches a specified point
 Bug rate falls below a certain level. Which means the testers are not getting any priority
1(highest priority), 2, or 3 (low priority) bugs.
As testing is a never ending process we can never assume that 100 % testing has been done, we
can only minimize the risk of delivering the product to the client/customer with testing done. The
risk can be measured by Risk analysis but for small duration / low budget / low resources project,
risk can be deduced by simply by considering the below points:
 Measuring Test Coverage

 Number of test cycles
 Number of bugs with high priority
90
7.7. Debugging
In computers, debugging is the process of finding and fixing/bypassing bugs or errors in a

program source code or it can called as the engineering of a hardware device. To debug a
program or hardware device, the programmer has to start with a problem, need to isolate the
source of that particular problem, and then finally fix it. User of a program who does not know
how to fix the problem must learn enough about the problem so that he can avoid it until the
problem is given a permanent fix. When someone says they've debugged a program or "worked
the bugs out" of a program, they mean that they have fixed the problem and the bugs no longer
exist in the application.
For any new software or hardware development process, debugging is a necessary process
whether it is a commercial product or an enterprise or personal application program. For
complex products, debugging is done as the result of the unit test for the smallest unit of a
system, again at component or module test when parts are brought together, and then at system
test when the product is used with other existing products, and finally during customer beta test
(explained earlier), where users try the product out in a real world situation. As most computer
programs and programmed hardware devices contain thousands of lines of code, almost any new
product is likely to contain a few bugs.
Debugging tools (called debuggers) will help identify coding errors at various development
stages. Some programming language packages will include a facility for checking the errors in
the code the moment it is being written.
Some of the debugging tools available are GDB (For Unix C++), Expeditor (MF) and so on.
Please do a search in Google to get some of the most commonly used debugging tools in the
software industry.
91
8.Introduction to the SDLC and UML
8.1. Phases of Software Development Life Cycle
Einführung
Software is a collection of computer programs and related data that instructs a computer on what
to do and how to do it.
Software should be capable of doing all the functions necessary to perform a task efficiently.
Software must be maintained when it is in use. In this module, we will discuss several processes
or guidelines for software development.
Life Cycle is a manner of looking at processes, in the context of their initial research and
development, expansion, maturing and final stages of evolution and growth.
For example, a butterfly goes through four stages in its life. Each of these stages is different from
the others. The following figure illustrates the life cycle of a butterfly.
Egg - It is the first stage in the life cycle of a butterfly.
Larva - It hatches from the egg. It is also called a caterpillar.
Pupa - When a caterpillar has finished growing, it forms a pupa.
Adult - When the pupa has finished changing, it emerges as an butterfly(adult) or moth.
92
Adult is the stage when butterfly and moth mate and reproduce. Females lay their eggs on plants
or any other surfaces, and the cycle starts again.
Software Life Cycle Model (SDLC)
The term Software Development Life Cycle(SDLC) is the way of describing the planning,
designing, coding, testing and maintaining a software, as well as the method in which these steps
are implemented.
SDLC is a structure imposed on the development of a software product. All these life cycle
models take a project through several primary phases: a requirements-gathering phase, a design
phase, a construction or an implementation phase, a testing phase and a maintenance phase.
Each phase produces feedback that affects the next phase of the SDLC. For instance, the
requirements gathered during the requirement analysis phase influence the design, which is
translated into working software code during the implementation phase. The software code is
verified against the requirements during the testing phase and the software is maintained when it
is in use during maintenance phase.
Requirements Analysis
During this phase, the needs of the company are outlined. Users (and in some cases, clients)
make their wish-lists about what they would like the software to do. Business Analysts(who
analyze the requirements) ask questions about the intended use of the software system, what type
of data will be processed, how the data can be accessed and how the software should handle the
data in the system. At the end of analysis phase, the development team should have a detailed list
93
of functions that the software system will perform. In this phase, emphasis is on the system's
goals rather than the way in which the system will achieve those goals.
Design
In the design phase, the results of the requirements analysis phase are translated into software
design plan. Focus shifts from the system's goals to the way in which those goals will be
achieved and how the goals of the requirements gathering phase are achieved. Designers
consider many different criteria, from the hardware and operating system platform that hosts the
software or the solution, to the way the subsystems will communicate with each other.
During the design phase, the designers convert the dreams of the users and managers into reality.
Emphasis is on making a practical, working design for what has been outlined in the
requirements analysis phase.
Bauwesen
During this phase, the output of the design phase is translated into program code. Software that
does not meet the needs of the user or the company is wasteful. During the construction phase,
the main goal of the programmers should be to fulfill the requirements of the users and to meet
the design outlined in the design phase.
Testing
In the testing phase, the results of the implementation/construction phase are run through a series
of tests to verify that it functions and also meets the goals of the requirements phase. A testing
plan is created to describe the unit and system tests that will be performed. Unit testing is
performed on individual software components. The process of integration brings together all the
individual software components to create the complete software system. System testing is then
performed on the complete software system as a whole component.
Please go through the 'Testing and Debugging' module to learn more about testing.
Maintenance
Once the product has been delivered/deployed to customers, it enters the maintenance phase.
During this stage, specialists from the development and testing teams monitor the product 'in the
wild' to see how it is adapting to regular user/customer usage. If customers encounter any
unforeseen problem, the maintenance team would take corrective action and fix the issue.
Refer the links given below to get more information about SDLC.
http://softwarelifecyclepros.com/wp-content/uploads/2012/05/Tutorial-Software-Development-
LifeCycle-SDLC.pdf
http://www.cpe.ku.ac.th/~plw/oop/e_book/ood_with_java_c++_and_uml/ch4.pdf
94
Types of SDLC Models
There are different life cycle models, each describing approaches to a variety of activities that
take place during the SDLC process. The following section discusses the important SDLC
models given below:
1. Waterfall Model
2. V-Shaped Model
3. Iterative Model
4. Incremental Model
5. Spiral Model
1. Waterfall Model
It is one of the most widely used SDLC models. It is also known as "Classic Life Cycle" or
"Linear Sequential model". This is one of the simplest models to understand and use. This model
is characterized by a series of steps that must be completed in a linear or sequential order. It is
known by the name 'Waterfall' because, we move to the next step after getting input from the
previous step (phase). This is similar to a waterfall where, water flows down to lower steps from
the upper steps. Each phase is completed and verified before the next phase. There is sequential
progression from one phase to another in this model.
The origin of this model is in the construction and manufacturing industry. Since formal software
development processes did not exist at that time, this hardware-oriented process model was
adapted for software development as well.
Waterfall model is not only simple to understand but also very easy to use. The highlight is that,
there are defined phases or steps in the waterfall model life cycle. So also, the preceding phase
must be complete before the next phase starts. After the first phase/step is completed, it is
considered as a stepping stone to the next phase. Though there are a number of life cycle models
that are now used in software development, waterfall model still remains one of the most popular
models.
The waterfall model was originally designed in 1970 by Winston W. Royce. The different phases
in Waterfall model are Requirement analysis, Design, Implementation and Unit Testing,
Integration and System testing, and Maintenance and Operation. The following figure illustrates
the waterfall model.
95
Following each phase, there is a formal review process that results in the decision to proceed to
the next phase. When one phase is complete, the entire development effort shifts to the next
phase. Cascading the flow from one phase to another is the basis of the Waterfall model.
1.Requirements Analysis
Like in any other project, requirements analysis is the first phase in the Waterfall model also.
During this phase, all the needs or functionality which should be implemented are gathered from
the client and a blue print is created. Analysis phase gives a clear picture of what the software
will be able to do in future. The system is thoroughly studied for pitfalls and incompatibilities.
Later a requirement specification document is created and handed over to the Design team.
2. Design
The Design phase needs a new team to design the software. This is most often done by a System
Analyst/ Designer. It results in the physical design of a system which is designed from the set of
requirements gathered during the requirement phase.
Creating a good design is very important because it describes what is going to get developed in
the implementation phase. The risk factor is very high in a project where there is poor design or
no proper design. A better understanding of the software help us to reduce the risk of failing. A
designer designs everything virtually. An analyst then analyzes everything thoroughly from top
to bottom to ensure that there is no incompatibility or functional error in the design.
System Analysts use UML (We will discuss about this in detail later) tools to design software
systems. Pseudo codes are written by system analysts for developers to refer to during
implementation. Pseudo codes are codes written roughly in English or any other language which
can be read/understand by anyone. It shows how the software actually works.
3. Implementation
96
Implementation is a critical phase in any software project. This is the most time consuming phase
of the project. In this phase, developers start writing actual code according to the design obtained
from the previous phase. Later, the project is divided into small tasks according to the
functionality or design. These small tasks are called modules or units. Each module is then
assigned to a team of developers, who focus on that particular module. This helps the developers
to implement the system in parallel. Once the development is complete, the project enters its next
phase; testing.
4. Testing
In this phase the software modules are tested by a team of software testers. This process is
known as Unit Testing. Initially, each module is tested for errors. If an error occurs, it is reported
back to developers to fix. After unit testing is completed, all the modules are combined into the
project and tested as a whole for integration errors. The software is tested thoroughly in different
conditions to ensure its quality. This is done by a team called the Quality and Assurance team(a
set of software testers). Please go through the 'Testing and Debugging' module to learn more
about testing.
5. Deployment and Maintenance
In this phase, the software system is deployed safely into the required condition or environment,
based on the user requirements. The software can either be deployed into a server or on a
computer according to the user requirements. The product is then ready for use by the end user.
Later, the software is maintained by the maintenance team to ensure that it is working fine. If an
error occurs, the maintenance team would fix it and continue to ensure the working of the
software.
Advantages of Waterfall Model
 It is simple and easy to use.

 It is easy to implement and manage because each phase has a specific purpose. Also,
development occurs only in one phase at a time.
 This model is appropriate for small development projects, whose requirements are well
understood.
Disadvantages of Waterfall Model
 Due to the rigidity of the model, all the requirements must be stated explicitly before
development begins. If requirements are changed or added later, then the project must
start over from the beginning.
 If errors are made in requirements-analysis or design, they may not be discovered until
very late in the implementation or testing phase.
Due to these issues, the Waterfall model is inappropriate for complex projects. It should not be
used for developing object-oriented software, for long-term or ongoing projects, or for projects
whose requirements are unknown or are subject to change.
97
V-Shaped Model
Like the Waterfall model, the V-Shaped life cycle model provides a sequential path of individual
phases that must be completed before development proceeds to the next phase. V-shaped model
means Verification and Validation model.
Validation- It is the assurance that a service, product or system meets the needs of the customer.
Verification- The evaluation of whether or not a product, service, or system complies with the
requirements, specification, or an imposed condition. It is an internal process.
The main difference between V-shaped development model and Waterfall development model is
the early test planning. The following figure is a simplified illustration of the V-shaped life cycle
model.
V-shaped model is applicable to projects where:
 Requirements are clearly known and defined in advance.

 Software development tools and the technologies are well known
The test plans(for each phase) are developed during each level of verification. Once coding is
complete, testing will be conducted as a part of validation.
98
Verification phases
Requirements
Requirement analysis (upper left point of the V) is the first step in the verification process. The
requirements are collected by analyzing the needs of the users. User acceptance tests and system
tests are designed as a part of this phase. System and acceptance test design plans focus on
verifying the functionality specified in the requirements definition.
High-level Design
As the V-shaped model moves down the left side, developers will focus on high-level design
architecture and the overall system design. System engineers will analyze and understand the
business of the proposed system or software by studying the user requirements document. Then
they come up with different techniques and possibilities by which the user requirements can be
implemented. If any of the requirements is not feasible, then the user is informed about the issue.
Low-Level Design
Low level design focuses on the design of individual software components or modules. The
high-level design is broken into smaller units or modules and each of them is explained in detail,
so that the developer can start coding directly. Low-level design and unit test design documents
are developed during this stage.
Coding/Development is performed at the bottom of the V-model, during the implementation

phase. Once coding is over, development progresses up the right side of the V-model, moving
through the documents prepared/developed as a part of the verification phase. If any problem
arises during the testing phase, the life cycle reverts to its corresponding development phase.
Validation phases
Unit testing
In computer programming, unit testing is a method by which individual units of source code are
tested to determine if they are fit for use through the documents prepared during Low-level
design. A unit is defined as the smallest testable part of an application or software.
Integration testing
The separate modules will be tested together to find out faults in the interfaces and in the
interaction between integrated components or modules through the documents prepared as a part
of High-level design.
Acceptance and System testing
99
After the integration test is completed, the focus is on the system and acceptance testing. This is
to check whether the integrated product/software meets the specified requirements or not. This
phase is used to determine whether a software system satisfies the requirements specified in the
requirements analysis phase through the documents prepared as a part of the requirement
analysis phase.
Advantages of V-model
 It is very simple and easy to use.

 Preparing test plans early in the process gives the V-model a higher chance for success.
 Appropriate for small development projects in which requirements are well understood
and defined in advance.
Disadvantages of V-model
 Like the Waterfall model, all requirements must be defined at the beginning of the
project. So it is difficult to add or change requirements later in the development process.
 All the software development occurs in a single phase, so there are no early working
versions or prototypes.
 The emphasis in test planning is to reduce the risk, but like the Waterfall life cycle model
the V-model also risks time and energy in the absence of careful planning.
 Similar to Waterfall model, the V-model is inappropriate for complex projects.
3. Iterative Model
The Iterative model addresses many issues associated with the Waterfall model. In the Iterative
model, analysis is done in the same way as it is done in the Waterfall Model .
An Iterative model does not start with a full specification of requirements. Development begins
by specifying and implementing just a part of the software, which can then be reviewed to
identify further requirements. This process is then repeated to produce the new version of the
software for each cycle in this model. An iterative life cycle model consists of repeating the
following four phases in sequence.
100
A Requirements phase in which the requirements are gathered and analyzed for the software
development.
A Design phase in which a software solution to meet the requirements is designed. This can be a
new design, or an extension of an earlier design.
An Implementation and test phase, when the software is developed, integrated and tested.
A Review phase in which the software solution is evaluated, the current requirements are
reviewed, and changes and additions to existing requirements are proposed.
For each cycle, a decision has to be made to check whether the software produced by the cycle
will be discarded, or if we can keep it as a starting point for the next cycle (incremental
prototyping). A point will be reached where the requirements are complete and the software can
be delivered or it becomes impossible to enhance the software system as required, and a fresh
start has to be made.
The key to the successful use of an iterative life cycle model is rigorous validation of
requirements, and the verification (including testing) of each version of the software against the
requirements within each cycle.
The first three phases of the Iterative model are more or less an abbreviated form of a Waterfall
life cycle or a sequential V-model. Each cycle produces software that requires testing at the unit
level, for software integration, system integration and an acceptance from the user. As the
software evolves through successive cycles, testing is repeated and extended to verify each
version of the software against the requirements within each cycle.
Advantages of Iterative model
 Faster coding, testing and design.

 Facilitates the support for changes within the life cycle.
101
Disadvantages of Iterative model
 More time spent in review and analysis phase

 Lot of steps need to be followed.
 Delay in one phase can have an adverse effect on the software as a whole.
4. Incremental Model
It builds an iterative approach into the waterfall model. Development projects are divided into
several smaller(more manageable) iterations. Each iteration passes through a mini waterfall
process model. Requirement analysis, design, implementation and testing phases are completed
for each iteration. In this model, software is designed, implemented, integrated and tested as a
series of incremental builds. Incremental model may be applicable to projects where:
Requirements are known and well defined, but realization may be delayed.
Basic functionality is required early.
This model is evolutionary, means that a working version of the software is created by the end of
the first iteration, and subsequent iterations build upon the work of earlier iterations.
Low level design is performed during each iteration. Unit testing evaluates the functionality
added during the current iteration on a relatively small amount of new code. . System testing
phase evaluates the way in which the new functionality affects the complete functionality of the
entire software system.
Advantages of Incremental Model
 Unlike the waterfall model, the incremental model generates a working prototype early in
the development process.
 The iterative nature makes it more flexible when adding or changing requirements
102
 Easier to test and debug because testing is performed incrementally during each iteration.
 It is an effective tool for risk management.
Disadvantages of Incremental Model
 Like the waterfall process model, the incremental model exhibits some rigidity(the
inability to change) in that phases cannot be overlapped.
 Because requirements analysis and design are performed during each iteration and not
before development begins, projects developed using this model may incur errors in early
iterations.
 It is less risky than the waterfall model, but it may be inappropriate for large and long
term projects.
5. Spiral Model
It is similar to the incremental life cycle model but incorporates risk analysis. It is divided into
four phases
I.Planning
II.Risk analysis
III.Development/Engineering
IV.Evaluation
A project passes through each of these phases in sequence, in a series of iterations called spirals.
At the beginning of the development process, critical requirements are identified for the first
spiral. The subsequent spirals add functionality to this baseline spiral.This model is represented
by a spiral passing through four quadrants/phases of development.
Requirements analysis or gathering is performed in the planning phase.
In the risk analysis phase, a formal process is undertaken to identify alternative courses of action
and their relative risks. A prototype is also developed during the risk analysis phase.
Software is coded and tested during the development/engineering phase.
In the evaluation phase, the customer/user has an opportunity to evaluate the software before
the project proceeds to the next spiral.
Following Figure illustrates the Spiral life cycle model. The angular component in the diagram
represents the progress in the current spiral, and the radius represents the project cost.
103
Advantages of Spiral Model
 Focus on risk avoidance makes this model ideal for large scale and mission critical
products.
 The iterative nature makes it more flexible when adding or changing requirements
 Spiral model is built on earlier software development life cycle models, and it borrows
from both the waterfall and incremental models.
 Working software code is developed early,thus the user/customer is given with many
opportunities to evaluate the software/output and plenty of time to ease into adoption of
the software
Disadvantages of Spiral model
 Cost is considerably more to implement than other software life cycle models.
 Risk analysis phase of this model requires highly specific expertise, and the project's
success depends on the output of this phase.
 It is inappropriate for small and medium scale projects.
Summary
104
All SDLC models share common phases of development:requirements gathering, designing of
the software system, Development of software, and the testing . Waterfall model is one of the
simplest and easiest to use,It consists of five phases that are executed sequentially. The
incremental model applies a series of iterations to the waterfall model. The Spiral model is built
upon the waterfall and incremental models and focuses on risk analysis.
8.2. Introduction to the Unified Modeling Language
Unified Modeling Language (UML) makes it possible to describe systems with pictures and
words. It can be used to model a variety of systems-business systems ,software systems or any
other system.
It is a graphical modeling language that is used to express designs. UML is a standardized

language to specify the components and artifacts of a software system. It describes a notation and
not a process. It does not put forth a single process or method of design, but rather is a
standardized tool that can be used in a design process.
A picture is worth a thousand words, this concept absolutely fits while discussing about UML in
this module. There are a number of goals for developing UML but the most important goal is to
define some general purpose modeling language ,which all modelers can use and also it needs to
be made simple to understand and easy to use.
UML diagrams are not only made for developers but also for common people, business users and
anybody interested to understand the a software or non software. It is clear that UML is not a
development methodology rather than it accompanies with processes to make a successful
system.
UML breaks the complex system into small pieces that can be understood easily. Complex
system can be understood by different developers who are working on different platforms.
Handing over the system or application to new team becomes easier. UML model is not a
platform or system specific. UML unifies all different developers under one roof.
UML Modeling provides following benefits:
 We can use UML with all processes throughout the development life cycle and across
different implementation technologies.
 Software will behave as we expect it to (fewer surprises).
 We will have lower development costs.
 Working with new developers will be easier.
 The right decisions are made to prevent poorly written code. Overall cost would be very
less.
 We can develop memory and processor efficient systems.
 Efficient communication with programmers and outside contractors.
 Less system maintenance cost.
UML Standard Diagrams
105
We prepare UML diagrams to understand a system in simple and better way. A single diagram is
not enough to cover the different aspects of the system. UML defines various kinds of diagrams
to cover all the aspects of a system.
We can also create our own set of diagrams to meet our requirements. UML diagrams are
generally made in an incremental and iterative way.There are two broad categories of UML
diagrams and then are again divided into sub-categories:
Structural Diagrams
Behavioral Diagrams
1. Structural Diagrams
The structural diagram represents the static aspect of the system. These static parts are
represented by classes, interfaces, objects, components and nodes. The four structural diagrams
are,
1.Class diagram
2.Object diagram
3.Component diagram
4.Deployment diagram
2. Behavioral Diagrams
Any system can have two aspects, static and dynamic. A model is considered as complete when
both the system and dynamic aspects are covered fully.
Behavioral diagram basically represents the dynamic aspect of a system. Dynamic aspect can be
further described as the changing or moving parts of a system.UML has the following five types
of behavioral diagrams:
1.Use case diagram
2.Sequence diagram
3.Collaboration diagram
4.State chart diagram
5.Activity diagram
106
8.3. Developing Use-Case Diagrams
A use case diagram is " a diagram that shows the relationships among use cases and actors within
a system ".
A use case model is comprised of one or more use case diagrams and any supporting
documentation such as actor definition and use case specification. The use case specification
tend to be the primary artifact with use case diagrams filling a supporting role as the " glue " that
keeps your requirements model together. Use case models should be developed from the user
point of view and not from the (often technical) point of view of developers
It is used to
I.Provide an overview of all or part of the usage requirements for an organization or system in
the form of a business model or an essential model.
II.To communicate the scope of a development project .
III.Model your analysis of your usage requirements in the form of a system use case model.
We can also create our own set of diagrams to meet our requirements. UML diagrams are
generally made in an incremental and iterative way.There are two broad categories of UML
diagrams and then are again divided into sub-categories:
There are guidelines for:
Use Cases
Actors
Relationships
System Boundary Boxes
1. Use Cases
107
A use case specifies a sequence of actions that provide a measurable value to an actor. A use
case is drawn as a horizontal ellipse on a UML use case diagram, as you see in the figure.
Each use case focuses on describing how to achieve a goal or task. A use case should:
 Describe what the system shall do to assist the actor in achieving a goal
 Not include any details about the screens or user interfaces.
For example, the below use case describes a simple Login.Sequence of steps included in the
Login use case are :
i.System prompts the user to log in.
ii.User enters user name and password in the system.
iii.System verifies the user name and password.
iv.The system logs user on to the system
2. Actors
An actor is an external entity (outside of the system) that interacts with the system by
participating a Use Case. Actors can be in real life people (for example users of the system),
external events and other computer systems.
108
An actor is an external entity (outside of the system) that interacts with the system by
participating a Use Case. Actors can be in real life people (for example users of the system),
external events and other computer systems.
Actors do not represent the physical systems or people , but their role. This means that when a
person interacts with the system in different ways , he will be represented by several actors.
For example a person that gives customer support by the telephone would be represented by an
actor ' Support Staff '. A person who takes orders from the customer is represented by an actor '
Sales Representative '.
3. Relationships
There are several types of relationships appear on a use case diagram:
Association :
An association can be between " a use case and an actor " or between two use cases.
It is the relationship between an actor and a use case. It indicates that an actor can use a certain
functionality of the business system - the business use case: Association can be represented as
below.
Example : A traveler purchases a transport ticket
In the following figure ,Purchase Ticket is the Use case and the Traveler is the actor. A given
ticket purchase can only be made by one traveler,but a traveler can purchase any number of
tickets(represented as 1..*).This is a type of association relationship
109
Include Relationship :
It is a relationship between two business use cases that signifies that the business use case on the
side to which the arrow points is included in the use case on the other side of the arrow. For one
functionality that the business system provides, another business functionality is accessed.
Functionality that are accessed repeatedly can be depicted as individual business use cases,
which can be used in multiple ways. In can be represented as below.
Example :
In the following figure , An include relationship points from the CheckOrderStatus use case to
the LogIn use case.It indicate that the CheckOrderStatus use case always includes the behaviors
in the LogIn use case.
The included use case LogIn cannot stand alone and the original use case CheckOrderStatus is
not complete without the LogIn use case.
110
4. System Boundary Boxes
The rectangle around the use case is called the system boundary box and it indicates the scope of
your system - the use cases inside the rectangle represent the functionality that you intend to
implement.
Sample Use Case Diagrams
Example 1 : Sales Application
There are two actors customer and other is the sales clerk. In this example Sales Clerk checks out
an item is the use case identified.
Use Case Specification: Sales Clerk checks out an item.
i.Customer sets the selected items on counter.
ii.Sales Clerk swipes UPC(Universal Product Code) reader across UPC code on item.
iii.System looks up UPC code in database to retrieve item type ,description and price.
iv.System emits beep sound.
v.System adds price, item type and item description to current invoice.
vi.System calculate price along with the tax details.
Following figure shows what the above use case might look like in UML schematic form. The
use case is drawn as an oval. The actors are represented as stick figures. Actors and use case are
connected using lines.
111
Example 2 : Bank ATM
An Automated Teller Machine (ATM) or the Automatic Banking Machine (ABM) is banking
subsystem that provides customers with access to financial transactions without the need for a
clerk,cashier or bank teller.
Customer (actor) uses bank ATM to check balance of his/her bank accounts, withdraw cash
,transfer funds and deposit funds(use cases). ATM Technician(actor) provides maintenance and
repairs((use cases). All these use cases also involve Bank as an actor, it is related to customer
transactions or to ATM servicing.
Example 3 : Passenger Services
Following figure illustrates a use case diagram with the actors: the Passenger (1) and the Check-
In representative (2), as well as the business use cases Check-In (3) and Express Check-In (4):
112
Starting with the Passenger (1)(actor) , we find association lines to two use cases, Check-In (3)
and Express Check-In (4). This means that people, who appear as passengers, can either go
through Check-In, or Express Check-In(which can be conducted without luggage) use case.
Example 4 : Order Management System
The following is a sample use case diagram representing the order management system. If we
look into the use case diagram, we will find three use cases (Order, Special Order and Normal
Order) and one actor which is customer.
The Special Order and Normal Order use cases are extended from Order use case,it is an
extends(generalization)relationship. Customer(actor) lies outside the system as it is an external
user of the system.
113
Where can Use Case Diagrams be applied?
Use case diagram is used to gather system requirements and actors.
It specify the events of a system and the flow. It never describes how they are implemented. Use
case diagram can be imagined as a black box where we can see only the input, output and the
function of the black box is known.
These diagrams are used at a very high level of design. High level design is refined again and
again to get a complete picture of the system. A well structured use case also describes some
extra elements such as precondition, post condition and exceptions. These extra elements are
used to make test cases during testing phase.
Following are the places where use case diagrams can be used:
 Requirement analysis and high level design phase.

 Model the context of a system.
8.4. Examining Other UML Diagrams
Class diagram
Class diagrams are the most popular UML diagrams used for the implementation of software
application. It is very important to learn the how to draw the class diagram.
It is basically a graphical representation of the static view of the system and represents different
aspects of the system. So a collection of class diagrams represent the complete system.
Following figure represents the class diagram. It is divided into four compartments.
114
I.The top section represents the name the class.
II.The second one show the attributes of the class.
III.The third section describe the operations performed by the class.
IV.The fourth section is optional and it is used to show the extra components
Object Notation:
Object is represented in the same way as the class. The only difference is the name which is
underlined as shown in the figure given below.
An object is the actual implementation of a class .It is also known as the instance of a class.
The following points should be considered while drawing a class diagram:
i.The name of the class should be meaningful.
ii.Each element and their relationships needs to be identified in advance.
iii.Attributes and methods of each class needs to be clearly identified.
115
iv.Unnecessary properties will make the class diagram complicated,So for each class minimum
number of properties should be specified.
v.Use notes wherever required to describe the aspect of the diagram. Because the class diagram it
should be understandable to the developer.
vi.The diagram needs to be drawn on plain paper and rework as many times as possible to make
it correct before making the final version.
The following figure represents the class diagram of an Order System . The class diagram has
been drawn considering all the points mentioned above:
Where to use Class Diagrams?
 Describing the static view of the system.

 To show the collaboration among the elements of the static view.
 Describing the functionality performed by the system.
 Development of software applications using object oriented languages.
Sequence Diagram
It is used to model the life line of an object, the activation and the message passing. Sequence
diagrams are two-dimensional diagrams: one dimension (usually the vertical) is used to display
116
evolution through time, the other to distinguish between different objects. An object is a vertical
line with a thick bar on the line which indicates the life line of an object. Message passing is
modeled by arrows pointing from one object to the next at a certain state transition on the life
lines of both objects. When message passing is instantaneous, the arrows are horizontal.
As mentioned the aim of a sequence diagram is to define event sequences, which would have a
desired outcome. The focus is more on the order in which messages occur than the message.
However, the majority of sequence diagrams will communicate what messages are sent and the
order in which they tend to occur.
Lifelines
When drawing a sequence diagram, remember that lifeline notation elements are placed across
the top of the diagram. Lifelines are representative of roles or object instances that take part in
the sequence being modeled. From a visual perspective, lifelines are shown as a box with a
dashed line descending from the center of the bottom edge. Name of the lifeline is placed inside
the box. Additionally, the lifeline name is underlined. What this means is that the lifeline
represents a specific instance of a class in a sequence diagram.
Nachricht
For the sake of readability, the first message of a sequence diagram always starts at the top and is
located on the left side of the diagram. Subsequent messages are then added to the diagram. To
show an object or lifeline sending a message to another object, you draw a line to the receiving
object with a solid arrowhead (if a synchronous call ) or with a stick arrowhead (if an
asynchronous call). The method /message name is placed above the arrowed line. The message
sent to the receiving object represents an method/operation that the receiving object?s class
implements.
117
Example : Make a call
Below sequence diagram describes the process of making a phone call. The objects involved are
caller, phoneNetwork, the person who is called and an accounting system. Various messages are
passed between the objects.
Activity Diagram
Activity diagrams are related to program flow plans, are used to illustrate activities. It is used for
the description of business processes that describe the functionality of the business system.
In activity diagrams actors can perform use cases together or independently from one another.
118
It allow us to think functionally. It is possible to explicitly describe parallel events, the activity
diagram is suitable for the illustration of business processes, since business processes rarely
occur in a linear manner and often exhibit parallelisms.
Activity diagrams can be developed in various degrees of detail and can be refined step by step.
In the external view, activity diagrams exclusively represent business processes and activities
from the outside perspective. Refining the activity diagrams does not mean describing process
details that are performed within the business system, which often leads to an unnoticed shift to
the internal view.
Activity
An activity diagram illustrates/represents one individual activity. In our context, an activity

represents a business process Fundamental elements of the activity are actions and control
elements (decision, division, merge, initiation, end,etc).
Elements are connected by activity edges to form the control flow, which can also be called as
flow . The execution of an activity may contain parallel flows. A border can surround an
activity(entire activity diagram).
Action
An action is defined as an individual step within an activity.For example, a calculation step that
is not possible to break down any further. It does not mean that the action cannot be subivided ,
but in this diagram will not be refined further.
An action can contain input and output information The output of one action can be the input of a
subsequent action within an activity. Specific actions are sending signals,calling other actions
and receiving an event.
119
Calling an Activity(Action)
With the following symbol an activity can be called from within another activity. Calling in itself
is an action, the outcome of the call is an another activity. Activities can be nested within each
other and can be represented with different levels of details.
Accepting a Time Event(Action)
At a particular point in time, this action starts a flow in the activity diagram.A hourglass symbol
is used to represent the acceptance of a time event.
An example of a time event is triggering reminders after the deadline for payment has passed.
Sending Signals(Action)
It means that a signal is being sent to an accepting activity.
120
The accepting activity accepts the signal with the corresponding action ' accepting an event ' and
can react accordingly(according to the flow that originates from this node in the activity
diagram).
Edge (Control Flow)
Edge is represented by arrows. It connects the individual components of activity diagrams and
illustrate the control flow of an activity.
Within the control flow an incoming arrow starts a single step of an activity, once that step is
completed the flow continues along the outgoing arrow. A name is attached to an edge.
Decision Node
The diamond represents a decision node or a conditional branch point. It has only one input and
two or more outputs.
Each output has a condition attached to it, which can be represented/ written in brackets. If a
condition is met, the flow proceeds along with the appropriate output. An else output can also be
defined.
Merge Node
Merge node has several inputs and only one output. It is used for merging of flows. It is
represented by the diamond given below.
121
Fork
A fork has only one input and two or more outputs. For the branching of flows in two or more
parallel flows we use a synchronization bar, which is represented as a vertical line or thick
horizontal. Branching allows parallel flows within an activity.
Join
For the consolidation of two or more parallel flows we can use a synchronization bar, which is
represented as a thick vertical or horizontal line. It takes two or more inputs and gives only one
output.
Initial Node
122
Initial node is the starting point of any activity. An activity can contain more than one initial
node, in this case several flows will start at the beginning of an activity. It is also possible that an
activity has no initial node, but can be initiated by an event .
Activity Final Node
It indicates that an activity is completed. Activity diagram can contain more than one exit in the
form of activity final nodes.
If several parallel flows are present within an activity, all flows are stopped at the time the final
node is reached.
Flow Final Node
It terminates a flow. It is represented as below. Reaching a flow final node has no effect on other
parallel flows that are processed within the activity at the same point in time.
Activity Partition
123
The individual elements of an activity diagram can be divided into 'partitions' or individual areas.
Various criteria can lead to the creation of these partitions organization entities, locations ,cost
centers, etc.
Individual steps of an activity would be assigned to these partitions. Each partition is set apart
from its neighboring partition by a or vertical horizontal continuous line, from this stems the
term swim lanes. Each partition receives a name. Partitions can be arranged in a two dimensional
manner, in the above diagram the activity diagram is divided into individual cells like a grid.
Example : Passenger Check-in
In the following figure, we can start reading at the initial node or with the acceptance of the
event passenger arrive sat check-in (1), and continue along the arrows of the control flow (2).
The third action Passenger Checks In(3) means that at this point the activity passenger check in
is processed.
124
If we follow the control flow, next we will come to a decision node or conditional branch (4), if
the check-in is OK then the next step along the control flow can continue. Otherwise (5), the
passenger cannot fly and the passenger task service is completed. This is represented by a the
black dot with border(the activity final node).
After successful check-in (7) we come to a black cross bar. All arrows that come from this black
bar (7) symbolize flows that are processed simultaneously( the luggage is being loaded onto the
airplane (9) and the passenger is boarding the airplane (10) ).
Between point (8) and point (11) the flows are independent from each other. Simultaneously
processed Flows (9 and 10) are merged at the second cross bar (11). It means that only when the
passenger is on the plane (10) and the luggage has been loaded onto the plane (9), then the
control flow continue below the cross bar (11).
In this example, one more action (12) and subsequent to that the final state (13) follow, meaning
that after the passenger is on the plane (10) and the luggage has been loaded onto the plane (9),
the airplane can taxi towards the runway (12).
We can see here that the last action airplane taxis toward runway (12) is only defined as a single
action, even though this process is very complex and could be described in many other activity
diagrams.
125
Following figure illustrates the activity diagram with partitions .
The above diagram is divided into two partitions passenger (1) and passenger services (2). The
passenger carries out showing ticket at Check-In counter (3), checking luggage (4) and paying
fee (5). All other actions of passenger services (2) and are carried out by passenger services.
126

Basics of Programming

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Basics of Programming

Uploaded by

Copyright:

Available Formats

Basics of Programming

1.Introduction to Programming Page No.

2.Introduction to Computer Programs

3.Basic Programming Concepts

4.Introduction to Developing a User Interface

6.Code optimization techniques

7.Testing and Debugging

8.Introduction to the SDLC and UML

1.1. What is Programming?

A problem is defined as any question, something involving doubt, uncertainty, difficulty or a

Fig 1.1: Problem Solving

A programming language is a computer language that programmers use to develop applications.

Within software engineering, programming (implementation) is considered as a phase in the

The Programming Process

1. Defining the problem

2. Planning the solution

3. Coding the program

4. Testing the program

5. Documenting the program

Let us discuss each of these steps.

1. Defining the problem

2. Planning the solution

Initialize the variable i to 1

while i 'less than or equal to n' do

It is a pictorial representation of a step-by-step solution to a problem. It consists of arrows

Figure 1.2: Flowchart

4. Testing the program

Testing involves three phases:

Let us discuss each of them.

This is similar to proofreading. This phase is sometimes avoided by the developer/programmer

A translator is a program that

5. Documenting the program

Documenting is an ongoing process. It is a detailed description of the programming cycle and

1.2. Why programming is required?

There are three good reasons for learning programming:

1. Programming helps us to understand computers. If we learn how to write simple programs, we

What Programmers Do?

The five generations of languages are:

4. Very high-level languages

Let us look at each of these categories

4. Very High-Level Languages

I.They are result-oriented; they emphasize "what" instead of "how".

2.1. Overview of Software Development

Life Cycle of a Software Development Project

Writing Functional Specifications

Creating Architecture and Design Documents

Implementation and Coding

Typical information included in reporting bugs includes:

 Test case description

Typically the information includes:

 Technical documentation developed during the development process, such as the

Support and New Features

 Help in installation and getting started

2.2. Overview of problem solving Techniques

 developing innovative and creative solutions;

 Is there more than one probortunity? "Probortunity‖ – a synonym by combining the

Key approaches to Problem solving

 Problems are identified by comparing actual performance with an expected standard

 need to define the problem,

B. Lateral or Creative Problem-Solving

 there is a high level of uncertainty,

2.1 : Seven-Step Problem Solving Process