Basics of Programming

Course Objective
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.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
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
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
Please refer the links below to learn more about pseudo code and flow chart.
http://ceng.anadolu.edu.tr/emrekacmaz/bil158/flowchart-pseudocode-examples.pdf
http://ozark.hendrix.edu/~burch/csbsju/cs/150/sched/pseudo.pdf
http://www.cosc.canterbury.ac.nz/tim.bell/dt/Tutorial_Pseudocode.pdf
http://users.csc.calpoly.edu/~jdalbey/SWE/pdl_std.html

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.
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.
Related Video/Material Links:
http://www.lynda.com/home/Player.aspx?lpk4=90430&playChapter=False
http://codingintro.com/chapter/en/1/introduction
http://www.cs.bham.ac.uk/~rxb/java/intro/2programming.html

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

Major Programming Languages are FORTRAN (a scientific language), COBOL (a business language), BASIC
(simple language used for education and business), Pascal (education), Ada (military), and C (general
purposed), C, C++, Java, and Javascript.
Please refer the link below to know more about programming.
http://homepage.cs.uri.edu/faculty/wolfe/book/Readings/Reading13.htm

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

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?

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

For further reading you may refer the websites below.

www.cls.utk.edu/pdf/ls/Week3_Lesson21.pdf
www.pitt.edu/~groups/probsolv.html

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.
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.
For further reading you may refer the websites below.
http://my.safaribooksonline.com/book/programming/9789332514836/chapter-6dot-introduction-to-
c/ch06_sec9_xhtml

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

Related Video/Material Links:
http://my.safaribooksonline.com/book/programming/9789332514836/chapter-6dot-introduction-to-
c/ch06_sec9_xhtml
http://r4r.co.in/c/basic_tutorials/05/primitive_data_types.shtml

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

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

Related Video/Material Links:

https://www.khanacademy.org/cs/programming/variables/p/intro-to-variables
http://library.thinkquest.org/15375/b02.htm

3.5. Control structures

Introduction
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.
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.
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.
Links for reference:
http://www.scriptingmaster.com/asp/conditional-logic.asp
http://www.tutorialspoint.com/java/java_loop_control.htm
http://revolution.byu.edu/programmingconcepts/ControlStruct.php
http://www.cplusplus.com/doc/tutorial/control/
http://www.tutorialspoint.com/java/java_decision_making.htm
Related Video Links:
https://www.khanacademy.org/cs/programming/logic-if-statements/p/if-statements
https://www.khanacademy.org/cs/programming/looping/p/intro-to-while-loops

3.6. Introduction to Arrays

Introduction

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

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

Links for reference:

http://docs.oracle.com/javase/tutorial/java/nutsandbolts/arrays.html
https://www-927.ibm.com/ibm/cas/hspc/student/data_structures/ArraysOneDim.html
https://www.khanacademy.org/cs/programming/arrays/p/intro-to-arrays
http://www.willamette.edu/~gorr/classes/cs231/lectures/chapter9/arrays2d.htm
http://www.cplusplus.com/doc/tutorial/arrays/
http://www.cprogramming.com/tutorial/c/lesson8.html

3.7. Introduction to Functions

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

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

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

 float result = avg(10,20,30);

 int count= getCount();
 alert();
 store(“Happy B’day”);

Links for reference:

http://www.c4learn.com/function-definition-in-c-programming-defining-a-function.html
http://www.tenouk.com/Module4.html
Related Video Links:
https://www.khanacademy.org/cs/programming/functions/p/functions

3.8. Composite Datatypes

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

Links for reference
http://en.wikipedia.org/wiki/Composite_data_type
http://212.201.48.1/course/c320102/script/sc2/node17.html

4.1. Introduction to Developing a User Interface

Introduction
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

  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 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.
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
All Benefits and Attributes that apply to GUI also apply to a WUI.
For further reading on this topic kindly refer to the document in the link below:
www.advanced-ict.info/theory/ICT2/2-10%20User%20Interfaces.ppt
Refer the below link to discover more about Touch User Interface:
http://en.wikipedia.org/wiki/Touch_user_interface
www.elsevierdirect.com/companions/9780120884360/casestudies/Chapter_01.pdf

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 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.
For further reading on the importance of good UI, please refer the pdf at the link below :
www.elsevierdirect.com/companions/9780120884360/casestudies/Chapter_01.pdf

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.
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 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 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
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.
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:
<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:
&gt; denotes the greater than sign (>)
&lt; denotes the less than sign (<)
&amp; denotes the ampersand (&)
&quot; 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:
<!-- This is comment text -->
A complete but small document
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.
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
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” />
</head>
<body>
or
<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)
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
Conclusion
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

Related Video/Material Links:

http://www.tutorialspoint.com/html/index.htm
http://html.net/tutorials/html/
http://www.lynda.com/HTML-tutorials/HTML-Essential-Training-2012/99326-2.html

5.Programming Approaches
5.1. Structured Programming
Introduction
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 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 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.
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.
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)
{
. //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;
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;
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;
}
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.
For further reading you may refer the websites below.
http://www.maths.udsm.ac.tz/mujuni/mt512/Programming%20Approaches.pdf
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.

For further reading you may refer the websites below.

http://www.compileroptimizations.com/index.html

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
 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);
//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
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)
{
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;
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
*
* @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.
 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.
For further reading you may refer the websites below.
http://channel9.msdn.com/Shows/Going+Deep/Russell-Hadley-The-Route-to-C-Code-Optimization
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.
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 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
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:
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 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.

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

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

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.

 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

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.
Links :
http://www.worldcolleges.info/College/E-Books/download/software%20testing%20life%20cycle(STLC).pdf
http://www.ipl.com/pdf/p0820.pdf
http://www.cs.swan.ac.uk/~csmarkus/CS339/presentations/20061202_Oladimeji_Levels_of_Testing.pdf

8.Introduction to the SDLC and UML

8.1. Phases of Software Development Life Cycle

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

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.

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

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

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.

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

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

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

For further reading you may refer the websites below.

http://sourcemaking.com/uml/introduction
http://www.cragsystems.co.uk/uml_tutorial/

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

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

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.

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

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.

Please refer the below link for more information.

http://www.uml-diagrams.org/use-case-diagrams-examples.html
http://www.smartdraw.com/resources/tutorials/uml-diagrams/#/resources/tutorials/UML-Use-Case-Diagram
http://www.cragsystems.co.uk/uml_tutorial/

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

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

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

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.

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
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
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.
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.
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.
Please refer the below link for further information about UML Diagrams
http://sourcemaking.com/uml/introduction
http://www.cragsystems.co.uk/uml_tutorial/

Ask a doubt