This document provides an overview of object-oriented analysis and design (OAD) and describes its application to analyzing and designing a quiz tool system. OAD involves using object-modeling techniques like the Unified Modeling Language (UML) to model a problem domain and design an object-oriented solution. The document outlines the object-oriented analysis, design, and software engineering processes and explains how they were applied to develop a computerized quiz tool system that allows exam instructors and students to efficiently generate, take, and evaluate online quizzes. Key aspects like requirements analysis, system design, and implementation planning are summarized to showcase how OAD principles were leveraged to modernize an existing manual quiz administration system.

1. QUIZ TOOL

2. INDEX
S.NO CONTENTS
1. Introduction………………………………
2 System Analysis………………………….
2.1 Existing System………………
2.2 Proposed System……………..
2.3 Requirement Analysis……….
2.4 Requirement Specification…..
2.5 Feasibility Study……………..
3. System Design……………………………
3.1 Project Modules………….
3.2 Data Flow Diagrams……..
3.3 UML Diagrams…………..
3.4 Hardware & Software …...
4 System Implementation……………….….
5. Testing…………………………………….
6. Screen Shots………………………………
7. Conclusion…………………………………
8. Bibliography. ..............................................

3. INTRODUCTION
This program allows exam instructor to easily upload Question bank (FAT) files from existing
file or pasting questions to text edit application. It is highly recommended that you first paste the
questions into the text edit application. Instead of using the time-consuming question creation
interface, you can copy your question & answer text directly from programs such as plain text or
xml format, perform some slight reformatting and simple markup addition, and then quickly
import your questions & answers into a text editing application. While the student will get
random questions generated by the application from all the chapters will be directly proportional
to the time.
The following formatting may be done to your quiz/exam text before or after it is pasted into the
main text box of the generator. Question text should begin with an identifier, typically a number
or letter, followed by a period or right-parenthesis and one space.
i.e.: 1. Text for the question
Or: B) Another question
All possible answers should immediately follow the question, with each answer separated on a
new line (using a return character—see examples below). Do not use return characters except
when you are proceeding to the next answer. This is especially important if you are copying
questions from another program like plain text.
Answers may start with a single identifier (a number or letter), followed by a period or
parenthesis. i.e. 1. 9) a. B) Do not use more than one number or letter for an answer identifier. If
you want to remove the answer identifiers in your final question bank (for instance, to later add
them directly).
Separate your new questions from the previous answers with a blank line. (See the Multiple
Choice example below.)
Multiple Choices
• Enter your question on a single line. (Auto word-wrapping is ok, just don’t use the return/enter key until
the end of the question text.)
• Answers immediately follow the question, each on a new line.
• Place an asterisk (*) in front of the correct answer choice.
• If you want to include credit for partially correct answers, place a plus sign (+) in front of each partially
correct answer choice. You will need to set a weight value for the scoring of all partially correct answer
choices; see “Setting the default scoring weight value (percentage) for partially correct answers” section
on page 5.

4. Multiple choice examples:
1. Which of the following is a planet?
a) The sun
*b) Earth
c) Proxima Centauri
2. At pH 7, arginine side chains would be…
*a) virtually all positively charged
+b) 50% positively charged
c) Not charged
d) 50% negatively charged
e) Virtually all negatively charged
Multi-select Answer
• Follow the same format as a multiple choice question (described on the previous page). The question
and answer choices are each on a separate line.
• Place an asterisk (*) in front of all correct choices. Do not use a plus sign (+) for partially correct.
B) Which of the following is a planet?
1. The sun
*2. Earth
3. Proximal Centauri
*4. Mars
*5. Saturn
True/False
• Enter your question on a single line. (Again, auto word-wrapping is ok; use the enter/return key only at
the end of the question text)
• Enter the answer on the next line. This can be any of the following: T, t, True, TRUE, true, F, f, False,
FALSE, false
• Do not use an identifier or enumerator in the answer line.
True/False example:
3. Water consists of hydrogen and oxygen. True
Long answer (essay)
• This is simply a question with no answer provided. Be sure to leave a blank line in-between this
question and the next question text following it.
Long answer examples:
1. Tell me about yourself.
2. Now tell me more about yourself.

5. OBJECT ORIENTED ANALYSIS AND DESIGN
Object-oriented analysis and design (OAD) is often part of the development of large scale
systems and programs often using the Unified Modeling Language (UML). OAD applies object-
modeling techniques to analyze the requirements for a context — for example, a system, a set of
system modules, an organization, or a business unit — and to design a solution. Most modern
object-oriented analysis and design methodologies are use case driven across requirements,
design, implementation, testing, and deployment.
Use cases were invented with object oriented programming, but they're also very well suited for
systems that will be implemented in the procedural paradigm.
The Unified Modeling Language (UML) has become the standard modeling language used in
object-oriented analysis and design to graphically illustrate system concepts.
Part of the reason for OAD is its use in developing programs that will have an extended lifetime.
Object Oriented Systems
An object-oriented system is composed of objects. The behavior of the system is achieved
through collaboration between these objects, and the state of the system is the combined state of
all the objects in it. Collaboration between objects involves those sending messages to each
other. The exact semantics of message sending between objects varies depending on what kind
of system is being modeled. In some systems, "sending a message" is the same as "invoking a
method". In other systems, "sending a message" might involve sending data via a socket.

6. Object Oriented Analysis
Object-Oriented Analysis (OOA) aims to model the problem domain, the problem we want to
solve by developing an object-oriented (OO) system.
The source of the analysis is a written requirement statements, and/or written use cases, UML
diagrams can be used to illustrate the statements.
An analysis model will not take into account implementation constraints, such as concurrency,
distribution, persistence, or inheritance, nor how the system will be built.
The model of a system can be divided into multiple domains each of which are separately
analyzed, and represent separate business, technological, or conceptual areas of interest.
The result of object-oriented analysis is a description of what is to be built, using concepts and
relationships between concepts, often expressed as a conceptual model. Any other
documentation that is needed to describe what is to be built, is also included in the result of the
analysis. That can include a detailed user interface mock-up document.
The implementation constraints are decided during the object-oriented design (OOD) process.
Object Oriented Design
Object-Oriented Design (OOD) is an activity where the designers are looking for logical
solutions to solve a problem, using objects.
Object-oriented design takes the conceptual model that is the result of object-oriented analysis,
and adds implementation constraints imposed by the environment, the programming language
and the chosen tools, as well as architectural assumptions chosen as basis of design.
The concepts in the conceptual model are mapped to concrete classes, to abstract interfaces in
APIs and to roles that the objects take in various situations. The interfaces and their
implementations for stable concepts can be made available as reusable services. Concepts

7. identified as unstable in object-oriented analysis will form basis for policy classes that make
decisions, implement environment-specific or situation specific logic or algorithms.
The result of the object-oriented design is a detail description how the system can be built, using
objects.
Object-oriented software engineering (OOSE) is an object modeling language and methodology
OOSE was developed by Ivar Jacobson in 1992 while at Objectory AB. It is the first object-
oriented design methodology to employ use cases to drive software design. It also uses other
design products similar to those used by OMT.
The tool Objectory was created by the team at Objectory AB to implement the OOSE
methodology. After success in the marketplace, other tool vendors also supported OOSE.
After Rational bought Objectory AB, the OOSE notation, methodology, and tools became
superseded.
 As one of the primary sources of the Unified Modeling Language (UML), concepts
and notation from OOSE have been incorporated into UML.
 The methodology part of OOSE has since evolved into the Rational Unified
Process (RUP).
 The OOSE tools have been replaced by tools supporting UML and RUP.
OOSE has been largely replaced by the UML notation and by the RUP methodology.

8. 2 SYSTEM ANALYSIS
System Analysis is first stage according to System Development Life Cycle model. This System
Analysis is a process that starts with the analyst.
Analysis is a detailed study of the various operations performed by a system and their
relationships within and outside the system. One aspect of analysis is defining the boundaries of
the system and determining whether or not a candidate should consider other related systems.
During analysis, data is collected from the available files, decision points, and transactions
handled by the present system.
Logical system models and tools are used in analysis. Training, experience, and
common sense are required for collection of the information needed to do the analysis.
2.1 EXISTING SYSTEM
 The earlier system is not computerized. Its time taking task to pick random questions
from different chapters, evaluate it manually and store the result information in records
which is not safe and secure. To make this laborious job simple the company has to
computerize the system.
 The process of picking questions from the different champers is very difficult when done
manually. It is also difficult to categorize the questions manually, evaluating and
forwarding it to the next level.
 The management of the company carrying out this job by using exam instructor to
maintain the activity procedure manually which make the job more complicated and
tedious most of the times. So, the best way is computerization of the current environment.

9. DRAWBACK OF EXISTING SYSTEM :
 Difficulty in evaluating the results manually.
 Difficulty in generating the reports based on quiz.
 Doesn’t provide effective mechanism in forwarding the user from
one level to another level.
 Lot of man power required for maintaining the Quiz.
2.2 PROBLEM DEFINITION
 No data security is ensured.
 Any query requires time consuming in searching records.
 Information cannot be given in time.
 Difficult to keep track of records.
2.3 PROPOSED SYSTEM
The proposed system is fully computerized, which removes all the drawbacks of
existing system. In the proposed system, the company can conduct the quiz for the
student at different levels.
It allows respective users to perform their tasks such as exam Instructor can login an
upload the question bank to the quiz tool. Ease for the instructor the assign quiz to the
students.
Students need to login to access their profile and take the exam accordingly.

10. 2.4 REQUIREMENT ANALYSIS
HARDWARE SPECIFICATIONS
 Processor : Pentium III or advanced.
 RAM : 512 min MB.
 Hard Disk : 20 GB.
SOFTWARE SPECIFICATIONS
 Operating System : Win 2000 & Above
 Language : Core Java, Swings, XML
 Technology : Java

11. FEASIBILITY STUDY:
Feasibility study is an important phase in the software development process. It enables the
developer to have an assessment of the product being developed It refers to the feasibility study
of the product in terms of outcomes of the product, operational use and technical support
required for implementing it.
Feasibility study should be performed on the basis of various criteria and parameters. The
various feasibility studies are:
 Economic Feasibility
 Operational Feasibility
 Technical Feasibility
Economic Feasibility: It refers to the benefits or outcomes we are deriving from the product
compared to the total cost we are spending for developing the product. If the benefits are more or
less the same as the older system, then it is not feasible to develop the product.
In the present system, the development of the new product greatly enhances the accuracy
of the system and cuts short the delay in the processing of application.
The errors can be greatly reduced and at the same time providing a great level of security. Here
we don’t need any additional equipment except memory of required capacity. No need for
spending money on client for maintenance because the database used is web enabled database.

12. Operational Feasibility: It refers to the feasibility of the product to be operational. Some
products may work very well at design and implementation but may fail in the real time
environment. It includes the study of additional human resource required and their technical
expertise.
In the present system, all the operations can be performed easily compared to existing
system and supports for the backlog data. Hence there is need for additional analysis. It was
found that the additional modules added are isolated modules as far as the operational is
concerned, so the Developed system is operationally feasible.
Technical Feasibility: It refers to whether the software that is available in the market fully
supports the present application. It studies the pros and cons of using particular software for the
development and its feasibility. It also studies the additional training needed to be given to the
people to make the application work.
In the present system, the user interface is user friendly and does not require much
expertise and training. It just needs a mouse click to do any sort of application. The software that
is used for developing is server pages fully is highly suitable for the present application since the
users require fast access to the web pages and with a high degree of security. This is achieved
through integration of web server and database server in the same environment.

13. Implementation plan:
The main plan for the system developed is to upgrading existing system to the proposed
system. There are mainly 4 methods of upgrading the existing system to proposed
 Parallel Run System
 Direct Cut-Over System
 Pilot System
 Phase-in Method
Parallel Run System: It is the most secure method of converting from an existing to new
system. In this approach both the systems run in parallel for a specific period of time. During that
period if any serious problems were identified while using the new system, the new system is
dropped and the older system is taken at the start point again.
Direct Cut -Over Method: In this approach a working version of the system is implemented in
one part of the organization such as single work area or department. When the system is deemed
complete it is installed through out the organization either all at once (direct cut-over) or
gradually (phase-in).
Phase-in Method: In this method a part of the system is first implemented and over time other
remaining parts are implemented.
Implementation planed used: The workflow Management system is developed on the basis of
“Parallel Run Method” because we upgraded the system, which is already in use to fulfill the
requirements of the client. The system already in use is treated as the old system and the new
system is developed on the basis of the old system and maintained the standards processed by the

14. older system. The upgraded system is working well and is implemented on the client
successfully.
Business Requirements Analysis
The system is a standalone quiz tool that enables a university to setup a quiz process through
which the organization can find out the efficient student as per the standards schedule. The
system is modeled to be used by an organization, whose main activity is academics the students
for internal quiz test and for qualifying the student.
To start with, the levels of test prepared by the exam instructor and their sequence in the
questions are stored inside a XML. The details that are stored include the Type of Test,
Sequence no are related to test levels.
Once the test levels are decided by the instructor then he can manage the list of questions in
each test level category which involves creation deletion and updating of questions in a test
level category. He can set the test mode to negative or non-negative also. He can view the status
of a student; test result .He can generate a report which shows the list of students based on cut
off in the result. He can communicate with the student through messaging facility. He can
specify the ranks based on marks which will be automatically set to the candidates based ion
their test marks.
The system incorporates intelligent test generating processing System which generates the
questions randomly from test level categories so that the candidates will not get the same
question list for all the times. It has the capability to check and evaluate the test result and store
to XML formats.
This system should a provide a facility for the candidates to register their information and for
writing the test. Using this userID and password the candidate can login into the system, select
a test level category and test writing the test. He can view his result and result details after test
completion. Once he completes a level then he will allow taking the test in the nest level. He can
post the feedback test.

15. Thus the cycle is repeated for every day. Currently all the above activities are done manually.
The process is a tedious one. To arrive at the examination process the candidate needs to come
across different phases to become our qualified. Because of this errors are occurring in the
process, which is leading to delayed deliveries to clients.
Automating such a process will not only eliminate the errors in the process, but also bring
down the process times & make the organization more competitive. So it was decided that an
automated system should be developed to make the whole process simpler & easier.
The following is the system developed for the above stated needs. An initial feasibility study
was performed & a conclusion was arrived at that automating such a system will not only
achieve all the things mentioned above, but will also provide additional Reports which will
enable the Management to look at the statistical side of the students.
Project Plan
It was decided to use good Software engineering principals in the development of the system
since the company had quite a big client network & was aiming to provide staffing for the
clients or to develop the internal projects of the companies & expand their operations in the
near future. So the following Project Plan was drawn up:
1. The Analysts will interact with the current manual system users to get the Requirements. As a
part of this the Requirements Specification Document will be created.
2. The requirements Specifications document will contain the Analysis & Design of the system
& UML will be used as the modeling language to express the Analysis & Design of the System.
According to Grady Booch et al, in The Unified Modeling Language User Guide [UML-1998],
“The Unified Modeling Language (UML) is a graphical language for visualizing, specifying,
constructing, and documenting the artifacts of a software-intensive system. The UML gives you
a standard way to write a system's blueprints, covering conceptual things, such as business

16. processes and system functions, as well as concrete things, such as classes written in a specific
programming language, database schemas, and reusable software components”.
3. The Analysis, Design, Implementation & testing of the System itself will be broadly based on
the Rational Unified Software Development process. According to Ivar Jacobson et al, in The
Unified Software Development Process (The Addison-Wesley Object Technology Series)
[USDP-2000], the Unified Software Development Process contains Inception, Elaboration,
Construction & Transition as the main Phases, which contain further cycles & iterations. This
process will be followed to produce an incremental cycle, which will deliver milestones like the
Requirements Specification Document etc., at the end of each of the iterations, Phases or cycles.
4. The Architecture & Technologies will be decided as a part of the Analysis of the
requirements.
5. Once the Design is ready the Implementation & Testing strategy of the system will
commence. Each will be independent of the other. The implementation of the system itself will
be broken down into sub-systems following the Software Engineering principles for the
development of robust software.
6. Once the implementation is ready, the System testing will take place. If the system is judged
to be stable then Acceptance testing by the Users will take place & once the Users are satisfied
the System will be rolled out to the Users & they will be trained on how to use it for an initial
period.
The following chapters contain an account of how the Technology & architecture for the system
were chosen.

17. Requirements Specification Document
2 Introduction
According to Roger Pressman in Software Engineering: A Practitioner's Approach (McGraw-
Hill Publications) [SEPA–1997], the requirement specification document is produced at the end
of Analysis of the system. This document is a very comprehensive document & contains all the
User requirements & Analysis diagrams. The Requirements are broadly divided into two
groups:
1. Functional requirements
2. Non-functional requirements
2.2 Functional Requirements
The main purpose of functional requirements within the requirement specification document is
to define all the activities or operations that take place in the system. These are derived through
interactions with the users of the system. Since the Requirements Specification is a
comprehensive document & contains a lot of data, it has been broken down into different
Chapters in this report. The depiction of the Design of the System in UML is presented in a
separate chapter. The Data Dictionary is presented in the Appendix of the system.
1. The System should allows the administrator to manage different levels of tests
And their sequence.
2. It allows the administrator to manage the questions in each category.
3. It allows the administrator to set the test mode to negative or non-negative.

18. 4. It allows the administrator to manage the list of questions in each category.
5. Candidate can register himself for writing the test.
6. The system then takes the candidate the first level after logging in.
7. The system generates the test by generating questions randomly pickup the
questions from the list
8. It allows the candidate to select answers of questions
9. This system finally evaluates the test, display the result and store it.
10. This system can then takes the candidate to the next level.
11. It allows the administrator to generate the report bases on some cut off
marks.
12. It allows the administrator to communicate with the candidate through
messaging.
13. It allows the candidate the feedback
14. It allows the administrator to set the ranks for the candidates.

19. 15. It doesn’t allow the candidate to take up the same test with in 6 months of
time.
2.3 Non-Functional Requirements
The non-functional requirements consist of
1. Analysis, Design & Data requirements (Use-case diagrams, textual analysis, sequence
diagrams, data dictionary etc.)
2. Constraints.
3. Guidelines.
4. Validation Criteria.

20. Analysis, Design & Data requirements
The use case diagrams, textual analysis and sequence diagrams & data dictionary fall into this
category. Since each category above is of considerable importance, they have been dealt in
separate chapters. An outline is only included here.
The Analysis & Design phases of the system yield Use Case diagrams, textual analysis,
Sequence Diagrams, Class diagrams & Data Dictionary. Data dictionary consists of process
statements showing how data is flowing from starting point to end point.
2.3.2 Constraints
These are the requirements that are not directly related to the functionality of the system. These
should be considered as mandatory when the system is developed. The following Constraints
were arrived at for the system:
1. The system should be available over the intranet so that the Users like the candidates can use
the system from their system which was assigned to him.
2. For gaining entry into the system the users should be registered and should be able use login
& passwords for gaining access to the system.
3. The users should be able to change their passwords for increased security.
4. The system should conform to the requirement specified and final deliverables of the project
before some date.
5. The system should be easy to understand and organized in a structured way. The users
should also receive feedback about any errors that occur.

21. 6. There should be no limitation about the hardware platform that is to be used to run the
system.
7. Data integrity should be maintained if an error occurs or the whole system comes down.
8. A user should to be registered in the system once in 6 months only.
9. A user can take-up the next level test once he clears previous level.

22. 2.3.3 Guidelines
We have discussed mandatory requirements in the previous section. The requirements in this
section should be taken as suggestions & they should be thought of as recommendations to
further enhance the usability of the system.
1. The system should display a menu for users to choose from.
2. The system should display users’ requests in a reasonable time.
3. Services of the system should be available 24 hours a day.
4. The system should be designed in such a way that it is easy to enhance it with more
functionality. It should be scalable & easily maintainable.
2.3.4 Validation Criteria
The Validation Criteria are dealt separately in the Chapter dealing with the Test Strategy & Test
cases.

23. Chapter 3
Software Specification

24. Architecture & Technologies used
3.1 Introduction
After analyzing the Requirements, the Architecture chosen for the System to be implemented is decided
as the Multi-tier Architecture. This architecture is chosen because it separates the Development of the
System into independent modules or tiers. Generally complex projects use this, as the work in each tier
can be taken up by specialists in each field. Thus the team can be structured & integrated by making the
best possible use of the resources available.
The most important Technologies that have been developed for this architecture are mainly categorized
into Java based technologies or the Microsoft technologies, which use Active Server Pages. The
Microsoft technologies have 3 important drawbacks. Firstly they tie us down to use only the Microsoft
Products & secondly they are not Platform independent. So both hardware wise & software wise our
hands will be tied down. The other major problem using Microsoft Technologies is that they are not
scalable & the platforms will not stand up to simultaneous large number of hits. Since the above
mentioned factors go against the Constraints listed under the Non-functional Requirements in the
Requirements Specification, we cannot choose the Microsoft Technologies.
Since the Java based technologies (J2EE – Java 2 Enterprise Edition) overcome all the drawbacks
mentioned above, J2EE is chosen as the Technology in which the Project is to be implemented. Java has
the added advantage of being a fully Object Oriented Language & for projects of considerable
complexity this is the best possible choice.
3.2 UML & its usage for Modeling the System
UML or Unified Modeling Language was developed by the Unification of the earlier modeling languages
developed by Grady Booch, James Rumbaugh, & Ivar Jacobson. All three came together with the
encouragement of Rational Software Corporation & devised UML by taking the best parts from each
individual’s own modeling language. The industry’s recommendations were also taken into
consideration. In a sense we can say that UML has the best features incorporated into it from all the
major modeling languages. So UML was chosen as the modeling language in which to express the
analysis & design of the system.

25. The basic flow followed was to get the user requirements & perform a Textual Analysis of the
requirements to come up with Use Cases & Actors. Then the relationships between the Actors & Use
cases were depicted in a Use case Diagram.
Each Use case was then analyzed independently & all the Nouns from it were picked up for possible
identification of classes or their attributes. Then the verbs or actions were picked up to arrive at the
associations or messages being passed between different classes.
All these were depicted in a class-association diagram. Then further design of the system was done, by
using sequence diagrams, to show the different sequences of actions in each use case.
The deployment diagrams show the different configurations in which this application could be deployed.
All three tiers could be deployed on different machines or they could be deployed on the same one, or
various combinations of hardware & software can be used for the deployment.
3.4 Client / Presentation tier
3.5 Business Logic Tier
The Business logic tier comprises a whole set of Java classes.

26. Instructor Tier | Web Tier | Business Logic Tier | XML Tier
Personal Info Personal Info Processes the Instructor instructions
Upload Questions Select Subj generate XML format
Conduct Exam Take Exam generate results after Quiz
Quiz Tool Web
Container
XML-
base
Java Classes,
Swings

27. Chapter 4
System Designing

28. 4.1 DATA FLOW DIAGRAMS:
Data flow diagram is a structure analysis tool that is used for graphical
representation of Data processes through any organization. The data flow
approach emphasis on the logic underlying the system, by using
combination of only 4 symbols. It follows a top down approach. A full
description of a system actually consists of set of DFD s, which comprises of
various levels. And initial over view model is exploded lower level diagrams
that show additional feature of the system. Further each process can be
broken down into a more detailed DFD. This occurs repeatedly until
sufficient details are described.
DFD symbols
Square
It defines a source (originator) or destination of system data.
Arrow

29. It indicates data flow-data in motion. It is a pipeline through which information
flows.
Circle or Bubble
It represents a process that transforms incoming data flow(s) to outgoing data
flow(s).
Open Rectangle
It is a data store-data at rest, or a temporary repository of data.

30. DFD (Data Flow Diagrams):-

32. QUIZ TOOL

33. 4.2 UML Diagrams:
4.2.1 Use Case

35. Use Case diagram for Normal/Student user:
Login
user profile
Search
Result
Change password
Normal user
View Inventory

38. Use Case diagram for Admin user/ Exam Instructor:
View inventory
Results
Add/del pdt
Add/del user
Modify inventory
Admin
Caterorize Inventory

39. 4.2.2 Class Diagram
Class Diagram

40. 4.2.3 E – R Diagram (ENTITY RELATION)

42. Chapter 5
Project Testing

43. PROJECT TESTING
5.1 INTRODUCTION:
Testing is generally done at two levels, testing of individual modules and testing of
entire system (system testing).
Testing is very tedious and time-consuming job. For the test to be successful the tester
should try and make the program fail. The tester may be analyst, programmer, or a
specialist trained in software testing. One should try and find areas in which the
program can fail. Each test case is design with intent of finding errors in system.
Through testing of the programs does not guarantee the reliability of the system. It is
done to assure that the system runs error free.
Software testing is a critical element of software quality assurance and
Represents the ultimate review of specification, design and coding. The increasing
visibility of software as a system element and the attendant costs associated with a
software failure are motivating forces for we planned through testing.
There are basically two types of test approaches. White box and Black box testing
methods have been used to test this package. All the loop constructs have been tested
for their boundary and intermediate conditions. The test data was designed with a
view to check for all

44. Conditions and logical decisions. Error handling has been taken care of by use of
exception handlers.
A strategy for software testing integrates software test case design techniques into a
well planned series of steps that result in the successful construction of software.
5.2 LEVEL OF TESTING
There are various types of testing.
 Unit Testing
 System Testing
 Acceptance Testing
 Integration testing
Unit Testing:
In unit testing the analyst‘s tests the programs making up a system. The software
units in the system are the modules and routines that are assembled and integrated to
perform a specific function. In large system, many modules at different levels are
needed.
Unit Testing individually focuses on the modules. This enables the tester to detect
errors in coding and logic that are contained within the module alone. The errors
resulting from the interaction between the modules are initially ignored.

45. Unit testing can be performed in bottom-up approach, starting with smallest/lowest
module and processing one at a time. For each module in bottom-up testing, a short
program executes the module and provides the needed data, so that the module is
asked to perform the way it will be embedded within the larger system. When bottom
level modules are tested, attention turns to those on next level that uses these lower
level ones. They are tested individually and then linked with the previously examined
lower level modules.
Top-down testing, as the name implies, begins with the upper-level modules. However,
since the detailed activities are usually performed in lower-level routines, that are not
provided, studs are written. A stud is module shell that can be called by the upper-
level module and that, when reach properly, will return a message to calling module,
indicating the correctness of lower-level module.
Often top-down testing are combined with bottom-up testing, that is, some lower-level
module are unit tested and integrated into top-down testing program.
System Testing:
Systems testing do not test the software per se but rather the integration of each
module in the system. It also tests to find discrepancies between the system and its
original objectives, current sections and system documentation. The primary concern
is the compatibility of individual modules. Analysts are trying to find areas where
modules have been designed with different specifications for data length, type and
data element name.
Acceptance Testing:
The software has been tested with the realistic data given by the client
and produced fruitful results. The client satisfying all the requirements specified by them has
also developed the software within the time
Limitation specified. A demonstration has been given to the client and the end-user giving all the
operational features.

46. Integration Testing:
Integration testing is a systematic technique for constructing the program structure
while conducting tests to uncover errors associated with interfacing. The objective is to
take unit tested modules and build a program structure that has been dictated by
design.

47. Chapter 7
Project Coding

48. Sample Code :
package com.org.quizTool;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import javax.swing.JButton;
import javax.swing.JComboBox;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JList;
import javax.swing.SwingUtilities;
public class QuizTool extends JFrame {
public QuizTool() {
initUI();
}
private void initUI() {
JPanel panel = new JPanel();
getContentPane().add(panel);
panel.setLayout(null);
JButton quitButton = new JButton("Quit");
quitButton.setBounds(50, 60, 80, 30);
quitButton.addActionListener(new ActionListener() {
@Override
public void actionPerformed(ActionEvent event) {
System.exit(0);
}
});
panel.add(quitButton);
setTitle("Quit button");
setSize(300, 200);
setLocationRelativeTo(null);

49. setDefaultCloseOperation(EXIT_ON_CLOSE);
}
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
@Override
public void run() {
QuizTool ex = new QuizTool();
ex.setVisible(true);
}
});
}
}
6. SCREEN SHOTS:-

51. 7. CONCLUSION
This system is implemented fulfilling all the client requirements. The interfaces designed for the
system is very user friendly and attractive. It has successfully implemented the banking
transactions like new accounts, money transfers, paying bills successfully as per the client
requirement.
The documentation and the project report is finally prepared to be referred as user manual for
further effective results of this software solution. Now the project is completed and ready to
submit to the head of the department of the college for further process.
We request HOD to kindly receive and acknowledge the same.
8. FUTURE SCOPE OF THE PROJECT
This project is having a broad future scope as it can be extended to
provide Quiz services on line. This system can be implemented for online
examination without the intervention of the Authority. In other words the
future scope is to provide the service through the Internet.
9. BIBLIOGRAPHY
 Systems Analysis and Design - Elias M. Awad.
 Software Engineering - Roger S. Pressman