A SUMMER TRAINING REPORT

ON

COLLEGE STUDENT & EVENT MANAGEMENT SYSTEM

(E-ALUMINI)

Submitted for partial fulfillment of award of

BACHELOR OF TECHNOLOGY

In
COMPUTER SCIENCE & ENGINEERING

By
ABC
(ROLL NO: 1034949464)

Guide

Mr. T. Naveen
Team Leader
TechWorld Solution Pvt. Ltd.
Hyderabad

DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING

G.L BAJAJ GROUP OF INSTITUTIONS

(Affiliated to Mahamaya Technical University,Noida)

Ghaziabad, UP

NOV 2013

1
 CERTIFICATE

This is to certify that the project titled “College Student & Event Management System” is
a bonafide work carried out by ABC bearing the registration number 1946983487568 in
partial fulfillment for the award of degree ”Bachelor of Technology in Computer Science”
by the Mahamaya Technical University, Noida during the year 2013. The project report had
been approved as it satisfies the academic requirements in respect of project work prescribed
for the Bachelor of Technology in Computer Science Degree.

2
 ACKNOWLEDGEMENT

I would like to thank the almighty god and my parents for sustaining and guiding me to
carry out my project work successfully.
“Task successful…” this phrase makes everyone happy. But the happiness is gold
without glitter if the persons who supported us to make it a success aren’t acknowledged.
Success will be crowned to people who made it a reality but the people whose constant
guidance and encouragement made it possible will be crowned first on the eve of success.
This acknowledgement transcends the reality of formality when I would like to
express my deep gratitude and respect to all those people behind the scene who guided,
inspired and helped me for the completion of my project work. I consider myself lucky
enough working on such a good project. This project would be an added asset to my
academic profile.

I express my gratitude to Mr. T Naveen, Team Leader – TechWorld Solutions,

HYDERABAD for his constant supervision, guidance and co-operation throughout the
project. I also extend my thanks to my Team Members, my Tech leads for their co-operation
during my course.

Finally I would like to thank my friends for their co-operation to complete this project.

ABC

3
 CONTENTS

TITLE Pg. No

1. INTRODUCTION 6-7

1.1. INTRODUCTION TO PROJECT

1.2. EXISTING SYSTEM & ITS DISADVANTAGES
1.3. PROPOSED SYSTEM & ITS ADVANTAGES

2. SYSTEM ANALYSIS 8-19

2.1. STUDY OF THE SYSTEM

2.2. INPUT & OUTPUT REPRESENTATION
2.3. PROCESS MODELS USED WITH JUSTIFICATION
2.4. SYSTEM ARCHITECTURE

3. FEASIBILITY STUDY 19-21

3.1. TECHNICAL FEASIBILITY

3.2. OPERATIONAL FEASIBILITY
3.3. ECONOMIC FEASIBILITY

4. REQUIREMENT SPECIFICATIONS 22-23

4.1. FUNCIONAL REQUIREMENTS

4.2. PERFORMANCE REQUIREMENTS
4.3. SOFTWARE REQUIREMENTS
4.4. HARDWARE REQUIREMENTS

5. SYSTEM DESIGN 24-35

5.1 . INTRODUCTION
5.2 DATA FLOW DIAGRAMS
5.3 UML DIAGRAMS
5.4 E-R DIAGRAM

6. OUTPUT SCREENS 36-45

4
7. SYSTEM TESTING 46-47

7.1 INTRODUCTION TO TESTING

7.2 TESTING STRATEGIES

8. SYSTEM SECURITY 48

8.1 INTRODUCTION
8.2 SECURITY IN SOFTWARE

9. REFRENCES 49

5
 1. INTRODUCTION

1.1 OBJECTIVE:
The objective of this application is to allow old and new students of a university or
college to communicate with each other. This allows students to know about each other and
their current activities.

1.2 EXISTING SYSTEM:

Many institutions, colleges and universities maintain the information manually about
present and past students. This does not allow efficient data management and retrieval
process. A student wiling to get information about others has to approach the college and
obtain the details. Often the information may not be available and misleading.

DISADVANTAGES OF EXISTING SYSTEM:

 Inefficient Data Management.

 Difficult in access of Data.
 Sometime Information is wrong.
 Difficult to know about existing & old Students
.

1.3PROPOSED SYSTEM:
The application allows students to register and then search the data based on different
criteria. Also it has the benefit of having a centralized database and up to date information. A
user can easily obtain information about other registered users.
 ADVANTAGES OF PROPOSED SYSTEM:

 Very Efficient Data Management.

 Very huge student database.
 Can be accessed at any time.
 Up to Date Information.
 Information of various events of college. ..etc.

 MODULES IN PROPOSED SYSTEM:

The System is proposed to have the following modules:

 Administrator module
 Event manager module
 Alumni and
 Student module

6
  ADMINISTRATOR MODULE:
The administrator is responsible for maintaining information of students. When a
student submits the registration form, administrator will complete the verification process
and, if successful, the student details are added into the database. The administrator maintains
the passwords of Event Manager and that of himself.

 EVENT MANAGER MODULE:

This module maintains the information about various events that are conducted by
various colleges and universities. Details of notifications are also maintained. The manager
can add, delete, edit and view event details.

 ALUMNI & STUDENT MODULE:

The Alumni/Students can register themselves and after the approval from the
administrator, they can logon into their account and can send mails, post queries, update their
profiles and even search for other student details. One can view the event details and search
for specific information. The module provides mail and query functionalities.

 SOFTWARE REQUIREMENTS:-
o Web Presentation : HTML, CSS
o Client – side Scripting : JavaScript
o Programming Language ; Java
o Web based Technologies : Servlets, JSP
o Database Connectivity : JDBC
o Java Version : JDK1.6
o Backend Database : Oracle 10g XE
o Web Server : Apache Tomcat 6.0
o Operating System : Windows XP
o Browser : IE/Mozilla

 HARDWARE REQUIREMENTS (MINIMUM):-

o Pentium processor : 512 MHZ

o RAM Capacity : 1GB
o Hard Disk : 40GB
o CD-ROM Drive : 32 HZ
o Keyboard : 108 Standard
o Mouse : Optical
o Monitor : 15’’ Color Monitor

7
 2. SYSTEM ANALYSIS

2.1 STUDY OF THE SYSTEM

To provide flexibility to the users, the interfaces have been developed that are accessible
through a browser. The GUI’S at the top level have been categorized as
1. Administrative user interface
2. The operational or generic user interface

The ‘administrative user interface’ concentrates on the consistent information that is

practically, part of the organizational activities and which needs proper authentication for the
data collection. These interfaces help the administrators with all the transactional states like
Data insertion, Data deletion and Date updation along with the extensive data search
capabilities.

The ‘operational or generic user interface’ helps the end users of the system in transactions
through the existing data and required services. The operational user interface also helps the
ordinary users in managing their own information in a customized manner as per the included
flexibilities

2.2 INPUT & OUTPOUT REPRESENTETION

Input design is a part of overall system design. The main objective during the input design is
as given below:

 To produce a cost-effective method of input.

 To achieve the highest possible level of accuracy.
 To ensure that the input is acceptable and understood by the user.

 INPUT STAGES:

The main input stages can be listed as below:

 Data recording
 Data transcription
 Data conversion
 Data verification
 Data control
 Data transmission
 Data validation
 Data correction

8
 INPUT TYPES:

It is necessary to determine the various types of inputs. Inputs can be categorized as

follows:

 External inputs, which are prime inputs for the system.

 Internal inputs, which are user communications with the system.
 Operational, which are computer department’s communications to the system?
 Interactive, which are inputs entered during a dialogue.

 INPUT MEDIA:
At this stage choice has to be made about the input media. To conclude about the input
media consideration has to be given to;

 Type of input
 Flexibility of format
 Speed
 Accuracy
 Verification methods
 Rejection rates
 Ease of correction
 Storage and handling requirements
 Security
 Easy to use
 Portability

Keeping in view the above description of the input types and input media, it can be said that
most of the inputs are of the form of internal and interactive. As
Input data is to be the directly keyed in by the user, the keyboard can be considered to be the
most suitable input device.

 OUTPUT DESIGN:
In general are:

 External Outputs whose destination is outside the organization.

 Internal Outputs whose destination is with in organization and they are the User’s
main interface with the computer. Outputs from computer systems are required
primarily to communicate the results of processing to users. They are also used to
provide a permanent copy of the results for later consultation. The various types of
outputs
 Operational outputs whose use is purely within the computer department.
 Interface outputs, which involve the user in communicating directly with the system.

9
 OUTPUT DEFINITION

The outputs should be defined in terms of the following points:

 Type of the output
 Content of the output
 Format of the output
 Location of the output
 Frequency of the output
 Volume of the output
 Sequence of the output

It is not always desirable to print or display data as it is held on a computer. It should be

decided as which form of the output is the most suitable.
For Example

 Will decimal points need to be inserted

 Should leading zeros be suppressed.

 OUTPUT MEDIA:
In the next stage it is to be decided that which medium is the most appropriate for the
output. The main considerations when deciding about the output media are:

 The suitability for the device to the particular application.

 The need for a hard copy.
 The response time required.
 The location of the users
 The software and hardware available.

Keeping in view the above description the project is to have outputs mainly coming
under the category of internal outputs. The main outputs desired according to the requirement
specification are:
The outputs were needed to be generated as a hard copy and as well as queries to be viewed
on the screen. Keeping in view these outputs, the format for the output is taken from the
outputs, which are currently being obtained after manual processing. The standard printer is
to be used as output media for hard copies.

10
2.3 PROCESS MODEL USED WITH JUSTIFICATION
SDLC (Spiral Model):
This document play a vital role in the development of life cycle (SDLC) as it describes
the complete requirement of the system. It means for use by developers and will be the basic
during testing phase. Any changes made to the requirements in the future will have to go
through formal change approval process.

SPIRAL MODEL was defined by Barry Boehm in his 1988 article, “A spiral Model of
Software Development and Enhancement. This model was not the first model to discuss
iterative development, but it was the first model to explain why the iteration models.

As originally envisioned, the iterations were typically 6 months to 2 years long. Each
phase starts with a design goal and ends with a client reviewing the progress thus far.
Analysis and engineering efforts are applied at each phase of the project, with an eye toward
the end goal of the project.

The steps for Spiral Model can be generalized as follows:

 The new system requirements are defined in as much details as possible. This usually
involves interviewing a number of users representing all the external or internal users
and other aspects of the existing system.
 A preliminary design is created for the new system.
 A first prototype of the new system is constructed from the preliminary design. This
is usually a scaled-down system, and represents an approximation of the
characteristics of the final product.
1) A second prototype is evolved by a fourfold procedure:
2) Evaluating the first prototype in terms of its strengths, weakness, and risks.
3) Defining the requirements of the second prototype.
4) Planning an designing the second prototype.
5) Constructing and testing the second prototype.
 At the customer option, the entire project can be aborted if the risk is deemed too
great. Risk factors might involve development cost overruns, operating-cost
miscalculation, or any other factor that could, in the customer’s judgment, result in a
less-than-satisfactory final product.
 The existing prototype is evaluated in the same manner as was the previous prototype,
and if necessary, another prototype is developed from it according to the fourfold
procedure outlined above.
 The preceding steps are iterated until the customer is satisfied that the refined
prototype represents the final product desired.
 The final system is constructed, based on the refined prototype.
 The final system is thoroughly evaluated and tested. Routine maintenance is carried
on a continuing basis to prevent large scale failures and to minimize down time.

11
The following diagram shows how a spiral model acts like:

Fig. : 2.1

12
SDLC is nothing but Software Development Life Cycle. It is a standard which is used by
software industry to develop good software.

Stages in SDLC:
 Requirement Gathering
 Analysis
 Designing
 Coding
 Testing
 Maintenance

 Requirements Gathering Stage:

The requirements gathering process takes as its input the goals identified in the high-
level requirements section of the project plan. Each goal will be refined into a set of one or
more requirements. These requirements define the major functions of the intended
application, define
Operational data areas and reference data areas, and define the initial data entities. Major
functions include critical processes to be managed, as well as mission critical inputs, outputs
and reports. A user class hierarchy is developed and associated with these major functions,
data areas, and data entities. Each of these definitions is termed a Requirement. Requirements
are identified by unique requirement identifiers and, at minimum, contain a requirement title
and textual description.

Fig. : 2.2
These requirements are fully described in the primary deliverables for this stage: the
Requirements Document and the Requirements Traceability Matrix (RTM). The requirements
document contains complete descriptions of each requirement, including diagrams and
13
references to external documents as necessary. Note that detailed listings of database tables
and fields are not included in the requirements document.
The title of each requirement is also placed into the first version of the RTM, along with
the title of each goal from the project plan. The purpose of the RTM is to show that the
product components developed during each stage of the software development lifecycle are
formally connected to the components developed in prior stages.
In the requirements stage, the RTM consists of a list of high-level requirements, or
goals, by title, with a listing of associated requirements for each goal, listed by requirement
title. In this hierarchical listing, the RTM shows that each requirement developed during this
stage is formally linked to a specific product goal. In this format, each requirement can be
traced to a specific product goal, hence the term requirements traceability.
The outputs of the requirements definition stage include the requirements document, the
RTM, and an updated project plan.

 Feasibility study is all about identification of problems in a project.

 No. of staff required to handle a project is represented as Team Formation, in this case
only modules are individual tasks will be assigned to employees who are working for that
project.
 Project Specifications are all about representing of various possible inputs submitting to
the server and corresponding outputs along with reports maintained by administrator

 Analysis Stage:
The planning stage establishes a bird's eye view of the intended software product, and
uses this to establish the basic project structure, evaluate feasibility and risks associated with
the project, and describe appropriate management and technical approaches.

Fig. : 2.3
The most critical section of the project plan is a listing of high-level product requirements,
also referred to as goals. All of the software product requirements to be developed during the

14
requirements definition stage flow from one or more of these goals. The minimum
information for each goal consists of a title and textual description, although additional
information and references to external documents may be included. The outputs of the project
planning stage are the configuration management plan, the quality assurance plan, and the
project plan and schedule, with a detailed listing of scheduled activities for the upcoming
Requirements stage, and high level estimates of effort for the out stages.

 Designing Stage:
The design stage takes as its initial input the requirements identified in the approved
requirements document. For each requirement, a set of one or more design elements will be
produced as a result of interviews, workshops, and/or prototype efforts. Design elements
describe the desired software features in detail, and generally include functional hierarchy
diagrams, screen layout diagrams, tables of business rules, business process diagrams, pseudo
code, and a complete entity-relationship diagram with a full data dictionary. These design
elements are intended to describe the software in sufficient detail that skilled programmers
may develop the software with minimal additional input.

Fig. : 2.4
When the design document is finalized and accepted, the RTM is updated to show that each
design element is formally associated with a specific requirement. The outputs of the design
stage are the design document, an updated RTM, and an updated project plan.

 Development (Coding) Stage:

The development stage takes as its primary input the design elements described in the
approved design document. For each design element, a set of one or more software artifacts
will be produced. Software artifacts include but are not limited to menus, dialogs, data
management forms, data reporting formats, and specialized procedures and functions.
Appropriate test cases will be developed for each set of functionally related software artifacts,

15
and an online help system will be developed to guide users in their interactions with the
software.

Fig. : 2.5
The RTM will be updated to show that each developed artifact is linked to a specific
design element, and that each developed artifact has one or more corresponding test case
items. At this point, the RTM is in its final configuration. The outputs of the development
stage include a fully functional set of software that satisfies the requirements and design
elements previously documented, an online help system that describes the operation of the
software, an implementation map that identifies the primary code entry points for all major
system functions, a test plan that describes the test cases to be used to validate the correctness
and completeness of the software, an updated RTM, and an updated project plan.

 Integration & Test Stage:

During the integration and test stage, the software artifacts, online help, and test data are
migrated from the development environment to a separate test environment. At this point, all
test cases are run to verify the correctness and completeness of the software. Successful
execution of the test suite confirms a robust and complete migration capability. During this
stage, reference data is finalized for production use and production users are identified and

16
linked to their appropriate roles. The final reference data (or links to reference data source
files) and production user list are compiled into the Production Initiation Plan.

Fig. : 2.6
The outputs of the integration and test stage include an integrated set of software, an
online help system, an implementation map, a production initiation plan that describes
reference data and production users, an acceptance plan which contains the final suite of test
cases, and an updated project plan.

 Installation & Acceptance Test:

During the installation and acceptance stage, the software artifacts, online help, and
initial production data are loaded onto the production server. At this point, all test cases are

17
run to verify the correctness and completeness of the software. Successful execution of the
test suite is a prerequisite to acceptance of the software by the customer.
After customer personnel have verified that the initial production data load is correct
and the test suite has been executed with satisfactory results, the customer formally accepts
the delivery of the software.

Fig. : 2.7
The primary outputs of the installation and acceptance stage include a production
application, a completed acceptance test suite, and a memorandum of customer acceptance of
the software. Finally, the PDR enters the last of the actual labor data into the project schedule
and locks the project as a permanent project record. At this point the PDR "locks" the project
by archiving all software items, the implementation map, the source code, and the
documentation for future reference.

 Maintenance:

Outer rectangle represents maintenance of a project, Maintenance team will start with
requirement study, understanding of documentation later employees will be assigned work
and they will undergo training on that particular assigned category.

18
For this life cycle there is no end, it will be continued so on like an umbrella (no ending point
to umbrella sticks).

2.4 SYSTEM ARCHITECTURE

Architecture flow:

Below architecture diagram represents mainly flow of requests from users to database
through servers. In this scenario overall system is designed in three tires separately using
three layers called presentation layer, business logic layer and data link layer. This project
was developed using 3-tier architecture.

Presentation Layer

Request Response
Business Logic
Layer

Data Link

Layer

Data Base

Fig. : 2.8

19
 3. FEASIBILITY STUDY

Preliminary investigation examines project feasibility; the likelihood the system will
be useful to the organization. The main objective of the feasibility study is to test the
Technical, Operational and Economical feasibility for adding new modules and debugging
old running system. All systems are feasible if they are given unlimited resources and infinite
time. There are aspects in the feasibility study portion of the preliminary investigation:

 Technical Feasibility
 Operation Feasibility
 Economic Feasibility

3.1 TECHNICAL FEASIBILITY

The technical issue usually raised during the feasibility stage of the investigation includes the
following:

 Does the necessary technology exist to do what is suggested?

 Do the proposed equipment’s have the technical capacity to hold the data required to
use the new system?
 Will the proposed system provide adequate response to inquiries, regardless of the
number or location of users?
 Can the system be upgraded if developed?
Are there technical guarantees of accuracy, reliability, ease of access and data security?

3.2 OPERATIONAL FEASIBILITY

 OPERATIONAL FEASIBILITY

 User-friendly
Customer will use the forms for their various transactions i.e. for adding new routes,
viewing the routes details. Also the Customer wants the reports to view the various
transactions based on the constraints. These forms and reports are generated as user-
friendly to the Client.
 Reliability
The package wills pick-up current transactions on line. Regarding the old transactions,
User will enter them in to the system.
 Security
The web server and database server should be protected from hacking, virus etc
 Portability
The application will be developed using standard open source software (Except Oracle)
like Java, tomcat web server, Internet Explorer Browser etc these software will work both
on Windows and Linux o/s. Hence portability problems will not arise.

20
  Availability
This software will be available always. You may access the data at any moment in day or
night & anywhere in the world.

 Maintainability
The system called the ewheelz uses the 2-tier architecture. The 1st tier is the GUI, which
is said to be front-end and the 2nd tier is the database, which uses MySQL which is the
back-end.
The front-end can be run on different systems (clients). The database will be running at
the server. Users access these forms by using the user-ids and the passwords.

3.3 ECONOMIC FEASILITY

The computerized system takes care of the present existing system’s data flow and
procedures completely and should generate all the reports of the manual system besides a
host of other management reports.

It should be built as a web based application with separate web server and database
server. This is required as the activities are spread throughout the organization customer
wants a centralized database. Further some of the linked transactions take place in
different locations.

Open source software like TOMCAT, JAVA, MySQL and Linux is used to minimize
the cost for the Customer.

21
 4. REQUIREMENT SPECIFICATIONS

4.1 FUNCTIONAL REQUIREMENTS SPECIFICATION

This application consists following modules.

 Administrator module
 Event manager module
 Alumni and student module

 Administrator Module:
The administrator is responsible for maintaining information of students. When a student
submits the registration form, administrator will complete the verification process and, if
successful, the student details are added into the database. The administrator maintains the
passwords of Event Manager and that of himself.

 Event Manager Module:

This module maintains the information about various events that are conducted by various
colleges and universities. Details of notifications are also maintained. The manager can add,
delete, edit and view event details.

 Alumni & Student Module:

The Alumni/Students can register themselves and after the approval from the administrator,
they can logon into their account and can send mails, post queries, update their profiles and
even search for other student details. one can view the event details and search for specific
information. The module provides mail and query functionalities
.

4.2 PERFORMANCEREQUIREMENTS
Performance is measured in terms of the output provided by the application. Requirement
specification plays an important part in the analysis of a system. Only when the requirement
specifications are properly given, it is possible to design a system, which will fit into required
environment. It rests largely with the users of the existing system to give the requirement
specifications because they are the people who finally use the system. This is because the
requirements have to be known during the initial stages so that the system can be designed
according to those requirements. It is very difficult to change the system once it has been
designed and on the other hand designing a system, which does not cater to the requirements
of the user, is of no use.
The requirement specification for any system can be broadly stated as given below:

 The system should be able to interface with the existing system

 The system should be accurate
 The system should be better than the existing system

22
The existing system is completely dependent on the user to perform all the duties.

4.3 SOFTWARE REQUIREMENTS:

Operating System : Windows
Technology : Java and J2EE
Web Technologies : Html, JavaScript, CSS
IDE : My Eclipse
Web Server : Tomcat
Database : Oracle9i
Java Version : J2SDK1.5, Tomcat 5.5, Oracle 9i

4.4HARDWARE REQUIREMENTS:
Hardware : Pentium
RAM : 1GB

Additional Tools:
HTML Designing : Dream weaver Tool
Development Tool kit : My Eclipse

23
 5. SYSTEM DESIGN
5.1 INTRODUCTION
Systems design

Systems design is the process or art of defining the architecture, components,

modules, interfaces, and data for a system to satisfy specified requirements. Onecould see it
as the application of systems theory to product development. There is some overlap and
synergy with the disciplines of systems analysis, systems architecture and systems
engineering.

5.2 DATA FLOW DIAGRAMS

 CONTEXT DIAGRAM

User

Career Assistance Personal Profile Events Jobs

Legend

Repository search engine Application Layer

Interface
Database

Data Base Administrator

Fig. : 5.1

24
5.3 DATAFLOWDIAGRAM’s:-

 LEVEL 0 DFD:
 For Administrator

Repository
and Search
Administrator Student
Access Engine Access

Fig. : 5.2
 (Level 0 DFD):

Administrator Invalid Login

Services
Id
Password
Authorized
User
Login ID Login
Passwor
d

Fig. : 5.3
 (Level 1 DFD):

Accept
Requested
Login
Administrator Services
college

Send reply
For queries

Fig. : 5.4

25
 For USER

 Level 0 DFD:

Invalid Login Id
Password Authorized
Student Login User Services
Login ID
Password

Fig. : 5.5
 Level 1 DFD:

Career
Assistance
Check
Profile

Login Update
Student Services
Profile

Mailing

Events

Fig. : 5.6

26
 Level 2- Admin Module:

Reply
for Goes to
Sends
queries
Administrator Users

Mail Box
User

Verifies

Fig. : 5.7

 Level 2- USER Module:

Update
profile
Updates in
User

Data base
Post
Jobs
Stores in

events

Fig. : 5.8

27
Unified Modeling Language:
The Unified Modeling Language allows the software engineer to express an analysis model
using the modeling notation that is governed by a set of syntactic semantic and pragmatic
rules.

A UML system is represented using five different views that describe the system from
distinctly different perspective. Each view is defined by a set of diagram, which is as follows:

 User Model View

1. This view represents the system from the users perspective.
2. The analysis representation describes a usage scenario from the end-users perspective.

 Structural model view

1. In this model the data and functionality are arrived from inside the system.
2. This model view models the static structures.

 Behavioral Model View

1. It represents the dynamic of behavioral as parts of the system, depicting the
interactions of collection between various structural elements described in the user
model and structural model view.

 Implementation Model View

1. In this the structural and behavioral as parts of the system are represented as they are
to be built.

 Environmental Model View

1. In this the structural and behavioral aspects of the environment in which the system is
to be implemented are represented.

UML is specifically constructed through two different domains they are:

 UML Analysis modeling, this focuses on the user model and structural model views of
the system.
 UML design modeling, which focuses on the behavioral modeling, implementation
modeling and environmental model views.

Use case Diagrams represent the functionality of the system from a user’s point of view. Use
cases are used during requirements elicitation and analysis to represent the functionality of
the system. Use cases focus on the behavior of the system from external point of view.

Actors are external entities that interact with the system. Examples of actors include users
like administrator, bank customer …etc., or another system like central database.

28
5.3 UML DIAGRAMS:

Use Case Diagrams:

1. Administrator:

Pas s word Managem ent

Adminis trator

Reques t Managem ent

Fig. :5.9

2. Event Manager:

Scheduling of Events

Event Manager
Updation of Events

Fig. : 5.10

29
3. Alumni/Student:

Registration

Mails

Alumni/Student

Queries

Search

Fig. : 5.11

Sequence Diagrams:

1. Administrator:

Adminis trator Sys tem Student/Alumini

Login

Succes s ful

Regis tration Reques t

Verifies pers on details from databas e

pos ting new entry into database

regis tration s uccess ful

Fig. : 12

30
2. Event Manager:

Event Manager Sys tem

Login

Succes s ful

Events Scheduling

Events Updation

Succes s ful

Fig. : 13

3. Alumni/Student:

s tudent/Alumini Sys tem Adminis trator

1 Student/Alumini
2

Regis tration

Regis tration Reques t

Verifies details

Succes s ful

Succes s ful

Login

Send Mails ,Queries

Replys

Search

Res ults

Fig. : 14

31
Activity Diagram:

Login

Administrator Event Manager Student/Alumini

Accepts Registration Changes Manages Searching Sends/Receive Sends/Replies Updates

Requests Passwords Events s Mails to Queries profiles

Fig. : 15

32
Class Diagram:

Fig. : 16

33
State Diagram:

State Diagram for Administrator/Event Manager:

Fig. : 17

State Diagram for Student/Alumni:

Fig. : 18

34
5.4 ER-Modeling:

Fig. : 19

35
 6. OUTPUT SCREENS

1. Home Screen:

Fig. : 6.1

This is the first screen of the given system; from here any of the Administrator, Event
Manager, Student or Alumni may log in the system.

Fig. : 6.2

36
In the above screen any Admin log in the system using a user name & password

Admin Module:

Fig.: 6.3

It is the Admin Section from where it manages requests & manages passwords of user &
Event manager.

Fig. : 6.4

37
Event Manager Module:

Fig. : 6.5

Using this module Event Manager log in to the system.

Fig. : 6.6

38
An event manager adds new events.

Fig. : 6.7

Previously added events can also be rescheduled.

Fig. : 6.8

39
Student Module:
From here an student alumini/may register on system

Fig. : 6.9
It is the account of Alumini/Student

Fig. : 6.10

40
It is the message Inbox

Fig. :6.11

From here you can compose mails

Fig. : 6.12

41
Fig. : 6.13

Fig. : 6.14

42
Fig. : 6.15

Fig. : 6.16

43
From here you can search anyone in the college i.e. allumini or student

Fig : 6.17

Fig. :6.18

44
From here you can also visit photo gallery of college.

Fig. : 6.19

45
 7. SYSTEM TESTING

7.1 INTRODUCTION TO TESTING:

Testing is a process, which reveals errors in the program. It is the major quality measure
employed during software development. During testing, the program is executed with a set of
test cases and the output of the program for the test cases is evaluated to determine if the
program is performing as it is expected to perform.

7.2 TESTING IN STRATEGIES

In order to make sure that the system does not have errors, the different levels of testing
strategies that are applied at differing phases of software development are:

UNIT TESTING:
Unit Testing is done on individual modules as they are completed and become executable. It
is confined only to the designer's requirements.

Each module can be tested using the following two Strategies:

BLACK BOX TESTING:

In this strategy some test cases are generated as input conditions that fully execute all
functional requirements for the program. This testing has been uses to find errors in the
following categories:
 Incorrect or missing functions
 Interface errors
 Errors in data structure or external database access
 Performance errors
 Initialization and termination errors.
 In this testing only the output is checked for correctness.

WHITE BOX TESTING:

In this the test cases are generated on the logic of each module by drawing flow graphs of that
module and logical decisions are tested on all the cases. It has been uses to generate the test
cases in the following cases:

 Guarantee that all independent paths have been executed.

 Execute all logical decisions on their true and false Sides.
 Execute all loops at their boundaries and within their operational bounds
 Execute internal data structures to ensure their validity.

INTEGRATING TESTING
Integration testing ensures that software and subsystems work together a whole. It tests the
interface of all the modules to make sure that the modules behave properly when integrated
together.

46
SYSTEM TESTING

Involves in-house testing of the entire system before delivery to the user. Its aim is to satisfy
the user the system meets all requirements of the client's specifications.

ACCEPTANCE TESTING

It is a pre-delivery testing in which entire system is tested at client's site on real world data to
find errors.

TEST APPROACH:
Testing can be done in two ways:

o Bottom up approach
o Top down approach

 BOTTOM UP APPROACH :

Testing can be performed starting from smallest and lowest level modules and proceeding
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 when
embedded within the larger system. When bottom level modules are tested attention turns to
those on the next level that use the lower level ones they are tested individually and then
linked with the previously examined lower level modules.

 TOP DOWN APPROACH:

This type of testing starts from upper level modules. Since the detailed activities usually
performed in the lower level routines are not provided stubs are written. A stub is a module
shell called by upper level module and that when reached properly will return a message to
the calling module indicating that proper interaction occurred. No attempt is made to verify
the correctness of the lower level module.

VAIDATION
The system has been tested and implemented successfully and thus ensured that all the
requirements as listed in the software requirements specification are completely fulfilled. In
case of erroneous input corresponding error messages are displayed

47
 8. SYSTEM SECURITY

8.1 INTRODUCTION:-

 SYSTEM SECURITY

SETTING UP AUTHENTICATIO FOR WEB APPLICATIONS:

INTRODUCTION:

To configure authentication for a Web Application, use the <login-config> element of the
web.xml deployment descriptor. In this element you define the security realm containing the
user credentials, the method of authentication, and the location of resources for
authentication.

8.2 SECURITY IN SOFTWARE

To set up authentication for Web Applications:

Open the web.xml deployment descriptor in a text editor or use the Administration Console.
Specify the authentication method using the <auth-method> element. The available options
are:

BASIC
Basic authentication uses the Web Browser to display a username/password dialog box. This
username and password is authenticated against the realm.

FORM

Form-based authentication requires that you return an HTML form containing the username
and password. The fields returned from the form elements must be: j_username and
j_password, and the action attribute must be j_security_check. Here is an example of the
HTML coding for using FORM authentication:

<form method="POST" action="j_security_check">

<input type="text" name="j_username">
<input type="password" name="j_password">
</form>

The resource used to generate the HTML form may be an HTML page, a JSP, or a servlet.
You define this resource with the <form-login-page> element.

The HTTP session object is created when the login page is served. Therefore, the
session.isNew() method returns FALSE when called from pages served after successful
authentication.

48
 9. REFRENCES

JAVA Technologies

 “Yehuda Shiran”- Java Script Programming.

 “Pistoria” - JAVA2 Networking.
 “Scotl Oaks” -JAVA Security.
 ‘Sierra Bates”- Head First EJB.
 “Shadab Siddiqui” J2EE Professional.
 “Larne Pekowsley” - JAVA Server Pages.
 “Nick Todd” - JAVA Server Pages.
 Mastering JAVA Security.
 Java Complete Reference.
HTML
 “Holzner” - HTML Black Book.
 “W3schools.com”
JDBC
 “Patel Moss” - Java Database Programming with JDBC.
 “Roger Pressman” - Software Engineering.

49