“ONLINE EVENT MANAGEMENT SYSTEM”

SYNOPSIS
 SYNOPSIS

The project entitled “ONLINE EVENT MANAGEMENT SYSTEM” is a

software application, developed for the boutique shops to stay connect with the customers.
This software allow the to organize the customer, product details in digital form. The main work
of this application is to reduce the manual work. Manual work can leas to loss data, as they miss
the details.
Wholesale and retail registration are maintained for the sales and billing
purpose of the clothes. By this application, as it is a system work, there won’t be loss of data
and risk for owner to maintain customer.
CONTENTS
 CONTENTS

TITLE PAGE NO
1. INTRODUCTION
2. SYSTEM SPECIFICATION
2.1. HARDWARE SPECIFICATION
2.2. SOFTWARE SPECIFICATION
2.3. SOFTWARE FEATURES
3. SYSTEM ANALYSIS
3.1. EXISTING SYSTEM
3.2. LIMITATION OF EXISTING SYSTEM
3.3. PROPOSED SYSTEM
3.4. FEATURES OF PROPOSED SYSTEM
4. PROJECT DESCRIPTION
5. SYSTEM DESIGN
5.1. INPUT DESIGN
5.2. OUTPUT DESIGN
5.3. DATABASE DESIGN
5.4. DATA FLOW DIAGRAM
6. SYSTEM TESTING AND IMPLEMENTATION
6.1. TESTING
6.2. SYSTEM IMPLEMENTATION
7. CONCLUSION AND FUTURE ENHANCEMENT
7.1. CONCLUSION
7.2. FUTURE ENHANCEMENT
BIBLIOGRAPHY
APPENDIX
SCREEN DESIGN
REPORTS
 ONLINE EVENT MANAGEMENY SYSYEM

ABSTRACT

Our project emphasis on making the task user friendly and easy
for students and faculties to register for various events organized by
the college through the common server and also see the ongoing
events at a particular time .As a result of solving problem, reducing the
paper work and manual processes with online registration .It allows you
provide to the students and faculties with a comprehensive set of
online self service functionality. With event management system,
there’s no more need for paper trails or time consuming manual
processes.

EXISTING SYSTEM:

1. In existing system there are lot of paper work and manual

processing.

2. While writing a paper records the management have to keep the

records very carefully as the entire data is written in those books.

3. Everything is paper based hence it is very time consuming.

4. More than one person cannot access the data at same time.
PROPOSED SYSTEM:

1. Improve management productivity ,satisfaction and retention by

Eliminate paper trails and manual process with complete online
management for handling management for registration of events.
2. Manage all students information easily in comprehensive students
record that includes students information.
3. Simply Event Management System with easy record management.
4. Faculty can easily manage the attendance of the students who are
participating in certain events.

CHAPTER-1 INTRODUCTION
1.1 OBJECTIVE OF THE PROJECT:

This project performs the task of developing a web application that

enables the students and faculty to retrieve the data very easily. The
main purpose of event management system is to provide a platform for
the users to view the information about the events that took place in the
past and the ones which are about to take place in the near future. The
users can be faulty, students and administrator. They can first login into
the website and see through the information such as details about the
events like the venue, theme of the event , participants, chief guests ,etc.
The faculty can keep the record of the attendance also .The administrator
can login and update the information ,delete any unwanted data ,arrange
the information accordingly so that the user can go through an user
friendly and know all the whereabouts of their college.

1.2 SCOPE OF THE PROJECT:

The scope of the project is just limited to a laptop or a pc with an

internet connection. Firstly the user, whoever it may be (student of
faculty) need to register to the website. After the registration process is
completed each one of them gets a password and have their own user
ids. With these two they can access their account and for any query they
can contact the administrator by sending him a mail.

 Facility to schedule a meeting.

 Facility to see participants engagement's dairy
 Facility to invite participants over mail
 Facility to cancel the Events
 Participants option for denying the invitation
 User registration
 Administrator privilege to edit user's profile

1.2.1 FEASIBILITY REPORT:

Preliminary investigation examine 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 system is feasible if they
are unlimited resources and infinite time.
There are aspects in the feasibility study portion of the preliminary
investigation:

 TECHNICAL FEASIBILITY
 OPERATIONAL FEASIBILITY
 ECONOMICAL FEASIBILITY

1.2.1.1 TECHNICAL FEASIBILITY:

Evaluating the technical feasibility is the trickiest part of a feasibility

study. This is because, at this point in time, not too many detailed design
of the system, making it difficult to access issues like performance, costs
on (on account of the kind of technology to be deployed) etc. A number
of issues have to be considered while doing a technical analysis.

 Understand the different technologies involved in the proposed system:

Before commencing the project, we have to be very clear about what are the
technologies that are to be required for the development of the new system.

 Find out whether the organization currently possesses the required

technologies:

 Is the required technology available with the organization?

 If so is the capacity sufficient?

1.2.1.2 OPERATIONAL FEASIBILITY:

Proposed project is beneficial only if it can be turned into

information systems that will meet the organizations operating
requirements. Simply stated, this test of feasibility asks if the
system will work when it is developed and installed. Are there
major barriers to Implementation? Here are questions that will
help test the operational feasibility of a project:

Is there sufficient support for the project from management

from users? If the current system is well liked and used to the
extent that persons will not be able to see reasons for change,
there may be resistance.

 Are the current business methods acceptable to the user? If they

are not, Users may welcome a change that will bring about a more
operational and useful systems.

 Have the user been involved in the planning and development of

the project?

 Early involvement reduces the chances of resistance to the system

and in general and increases the likelihood of successful project.

 Since the proposed system was to help reduce the hardships

encountered. In the existing manual system, the new system was
 considered to be operational feasible.

1.2.1.3 ECONOMICAL FEASIBILITY:

Economic feasibility attempts 2 weigh the costs of

developing and implementing a new system, against the benefits
that would accrue from having the new system in place. This
feasibility study gives the top management the economic
justification for the new system.

A simple economic analysis which gives the actual

comparison of costs and benefits are much more meaningful in
this case. In addition, this proves to be a useful point of
reference to compare actual costs as the project progresses.
There could be various types of intangible benefits on account of
automation. These could include increased customer
satisfaction, improvement in product quality better decision
making timeliness of information, expediting activities,
improved accuracy of operations, better documentation and
record keeping, faster retrieval of information, better employee
morale.

1.3 EXISTING SYSTEM:

  In existing system there are lot of paper work and manual
processing.
 While writing a paper records the management have to keep the
records very carefully as the entire data is written in those books.
 Everything is paper based hence it is very time consuming.
 More than one person cannot access the data at same time.

DISADVANTAGES:
 Lot of paper work required.
 Man power was more.
 Time consuming process.

CHAPTER-2 LITERATURE SURVEY

Literature survey is the documentation of a comprehensive review of

the published and unpublished work from secondary sources data in the
areas of specific interest to the researcher. The library is a rich storage
base for secondary data and researchers used to spend several weeks and
sometimes months going through books, journals, newspapers,
magazines, conference proceedings, doctoral dissertations, master's
theses, government publications and financial reports to find information
on their research topic. With computerized databases now readily
available and accessible the literature search is much speedier and easier
and can be done without entering the portals of a library building.
2.1 PAPER BASED SYSTEM:

Initially the documentation was started based on the paper to

record any information or details of events everything should be
manually written by human in to the paper, it very problematic to
retrieve the records. We do have fallowing problems in paper based
system.

2.1.1 HIGH COST

The following calculation gives you an idea of the labor cost

associated with a paper-based filing system. It is assumed that an event
creates or receives 100 important new paper documents that are filed
daily and that there is an efficient paper-based filing system in place. If
on an average it takes 6 minutes to retrieve and file a document, total
time taken to handle 100 documents equals 6 x 100 minutes = 10 hours
per day.

If the hourly rate is $14 including social security and benefits, total
labor cost per year equals ($14 x 10) x (226 work days) = $31, 640.

The above analysis does not include overhead cost for retrieving
and filing old documents. If included, the cost of retrieving and filing
paper documents will be a lot more than you realize
2.1.2 LOST AND MISSING DOCUMENTS:

According to a study by Cooper and Lybrand, "7.5% of all

documents get lost and 3% of the remainder is misfiled." This suggests
that out of every one hundred documents, ten documents are in the
wrong hands, being removed from the right place, etc. Some documents
cannot be reproduced if lost. This dramatically increases the risks and
costs associated with paper filing systems.

2.1.3 HARD TO SHARE:

Paper-based filing systems allow paper documents to reside in only

one place at a time. To share information the users can request for
regular updates.

2.1.4 SECURITY ISSUE:

It is hard to keep track of who has used or copied which

paper documents. Paper documents are often maintained with very
low security control.

CHAPTER-3 PROPOSED SYSTEM

 Proposed online student registration system will eliminate all the
manual intervention and increase the speed of whole process. System
will allow student to fill the form online, system has inbuilt validation
system to validate the entered data. After successful submission, system
will give unique registration ID for each student. Student can login into
system by using this registration ID and can give online feedback.
System will generate the result instantly and store the results for further
use.

Improve management productivity, satisfaction and retention by

Eliminate paper trails and manual process with complete online
management for handling management for registration of events.

Manage all students’ information easily in comprehensive students

record that includes students information. Simply Event Management
System with easy record management. Faculty can easily manage the
attendance of the students who are participating in certain events.

3.1 PROBLEM DEFINITION:

In the existing system lot of paper work was required and it was time
consuming process. As it was manual process retrieving data was very
difficult. More than one person cannot access the data.

 Lot of paper work required.

 Man power was more.
 Time consuming process.
 Event Management System (EMS) is a web based application
that supports online registration and feedback evaluation for event
training programs such as games, seminars and workshops. It helps
program attendees, organizers, the authors and the reviewers in their
respective activities.

Development of Event management system is an attempt to

address the problems of managing registration forms, feedback forms and
evaluating feedback. The main goal of this software is to give working
solution to store, manage and consolidate the registration data and the
feedback data.

EMS is web-based system for collecting registration forms and

evaluating the feedback automatically. It increases the scope of the report
generation even by generating report over a period of time.

Typical functions supported by TMIS are:

 Registering students participants,

 Getting attendance from faculty,
 Collecting feedback from students,
 Generating feedback reports.

The EMS is easy to use, full-featured and flexible participant registration and
feedback assessment web application.

3.2 SYSTEM ARCHITECTURE:

 Fig.3.2 EVENT MANAGEMENT SYSTEM ARCHITECTURE

 The EMS is proposed to use the following open technologies i.e. centos
Linux 5.5, Apache/Tomcat Application server and MySQL as database
server.

 The PHP Pages/Servlets will be used for implementing the program logic at
server end.

 The efforts will be focused on the graphical user interface (GUI), which
shall not be restricted to static pages; rather the user can experience a
dynamic environment, in which he or she can navigate in a natural way.

3.3 MODULES IN THE PROJECT:

 Students
  Faculty
 Administrator

3.3.1 ADMINISTRATOR does login, upload events, and verify events registration
form, logout.

Use cases:

 Login
 Upload events
 Delete events
 Verify events registration
 Logout

3.3.2 A STUDENT does login, registration, view events, events registration, event
status, logout.

Use cases:

 Login
 Registration
 View events
 Event Registration
 Event status
 Logout

3.3.3 FACULTY does login, register, and view events, view register students,
logout.
 Use cases:

 Login
 Register
 View events
 View register students
 Logout

CHAPTER-4

SOFTWARE REQUIREMENTS SPECIFICATION

4.1 PURPOSE OF THE DOCUMENT:

This project perform the task of developing a web application that

enables the students and faculties to retrieve the data very easily. The
faculty can keep the record of the attendance.

4.2 USE CASE MODEL SURVEY:

Use case Report: use cases are used during requirements elicitation
and analysis to represent the functionality of the system. Use cases focus
on behavior of the system from an external point of view.
4.2.1 PRINCIPLE ACTORS:
There are three main actors of this system they are administrator,
user, and faculty. Administrator does login, upload events, and verify
events registration form, logout.

Administrator: The admin responsibilities are managing the system performing

some special operations on records of database.

User: does login, registration, view events, events registration, event status, logout.

Faculty: does login, register, view events, view register students, logout.

4.2.2 USE-CASE REPORTS:

The purpose this document is to provide a brief description of the

project and to describe known actors and their interaction with the
system. This document presents a high level view. For more detailed
information, the reader will need to see the individual use case reports.

4.2.3 ASSUMPTIONS AND DEPENDENCIES:

This application can run in any environment. The product is

developed using platform-independent language. Hence the product is
portable and is platform independent. The resources of the project will
be available, when required.
 4.3 SPECIFIC REQUIREMENTS:

4.3.1FUNCTIONAL REQUIREMENTS:-

Functional requirements include administrator, user and faculty.

4.3.1.1 ADMINISTRATOR MODULE: This module is the one who organizes

all the users data, allow the various users to create the id function.

 Stimulus/Response Sequences:
 Stimulus: Administrator logins with his/her user id and
password.
 Response: If it is validate user then it get accessed or
accessed denied.
 Stimulus: Administrator provides user id and password
to all the users.
 Response: Administrator updates, modify the data if
required.

4.3.1.2 USER MODULE:

A user is the one that create an id and then login with the
help of it and performs various activities like view events, register
for the events, checks the events status.
Stimulus/Response Sequences:
  Stimulus: User logins with id and passwords.
 Response: if it is validate then it get accessed or denied.

4.3.1.3 FACULTY MODULE:

A faculty is the one who register and checks for the registered students for
attendance and view the events.
Stimulus/Response:
 Stimulus: faculty login with id and password.
 Response: if it is validate faculty then it get accessed or denied.

4.3.2 NON FUNCTIONAL REQUIREMENTS:

PERFORMANCE REQUIREMENTS

The system should be fast, despite many users accessing the database at once.

SECURITY REQUIREMENTS

To ensure security from unauthorized access, use, modification, destruction, or

disclosure from other persons, authentication should be performed by establishing login
procedure.

ERROR CONDITIONS
Upon detection of an error condition, the system should generate a suitable error
message that should be displayed to the user. Make sure that system is still reliable with
large number of users.

USER FRIENDLINESS
 The system should be designed to have a user-friendly interface so that user can be
guided easily. The system must be designed efficiently so that a user can operate easily
without any formal training or delay.

EASE OF USE
Make user interaction easy and obvious so that non computer-proficient user can use
the system.

4.4.2.1: HARDWARE INTERFACES:

Hard disk:

The database connectivity requires a hardware configuration that is on-line. This makes it
necessary to have a fast database system running on high rpm hard disk permitting
complete data redundancy and back-up systems to support the primary goal of reliability.

The system must interface with the standard output device, keyboard and mouse to
interact with this software.

4.4.2.2: SOFTWARE INTERFACES:

FRONT END: PHP

FRONT END DESCRIPTION:

The Event management system is automated system which consists of,

 Registration form: where the users can register for various programs by specifying
his/her details such as name, id, password etc...
 Programs details: where the users can view details about the entire program such
as title of the program, code for the program, numbers of students participating etc.
 Feedback form: where the users can indicate their satisfaction level by rating the
program on various parameters held.
 Faculty form: To participate in different events and for students attendance.
 Students form: To participate in events held with valid password and id.

BACK END: MYSQL.

BACK END DESCRIPTION:

The Training MIS consists of tables.

1. Registration table: It consists of all applicants details.

2. Participant table: It consists of participant details such as their login id, password,
program code, date of registration and fee details.

3. Feedback table: It consists of participant id, program code, and feedback evaluation
parameters.

MEMORY CONSTRAINTS: No specific constraints on memory.

4.4.2.3 HARDWARE REQUIREMENTS:-

 Micro processor I3
 Hard Disk Drive:250
 RAM: 4GB
 Keyboard
 Mouse

4.4.2.4 SOFTWARE REQUIREMENTS:-

 Technology: PHP
  Database: My SQL.
 Web Server: Tomcat Apache5.0.
 Operating system: Windows XP & above
 Browser: Internet Explorer7.0.

CHAPTER -5 SOFTWARE ENVIRONMENT

SPECIFICATIONS
5.1TECHNOLOGIES AND TOOLS USED:

5.1.1 Description

PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-

purpose scripting language that is especially suited for web development and can be embedded

into HTML PHP is a server-side scripting language designed for web development but also used

as a general-purpose programming language. Originally created by Rasmus Lerdorf in 1994, the

PHP reference implementation is now produced by The PHP Group. PHP originally stood

for Personal Home Page, but it now stands for the recursive backronym PHP: Hypertext

Preprocessor. PHP code may be embedded into HTML code, or it can be used in combination

with various web template systems, web content management system and web frameworks. PHP

code is usually processed by a PHP interpreter implemented as a module in the web server or as

a Common Gateway Interface (CGI) executable. The web server combines the results of the

interpreted and executed PHP code, which may be any type of data, including images, with the

generated web page. PHP code may also be executed with a command-line interface (CLI) and

can be used to implement standalone graphical applications.

The standard PHP interpreter, powered by the Zend Engine, is free software released under

the PHP License. PHP has been widely ported and can be deployed on most web servers on

almost every operating system and platform, free of charge.

What distinguishes PHP from something like client-side JavaScript is that the code is executed

on the server, generating HTML which is then sent to the client. The client would receive the

results of running that script, but would not know what the underlying code was. You can even

configure your web server to process all your HTML files with PHP, and then there's really no

way that users can tell what you have up your sleeve.

The best things in using PHP are that it is extremely simple for a newcomer, but offers many

advanced features for a professional programmer. Don't be afraid reading the long list of PHP's

features. You can jump in, in a short time, and start writing simple scripts in a few hours.

MySQL:

MySQL is a flexible and capable RDBMS that has a rich feature set, performs well on the

majority of queries, and has a large support base for access from many different languages.

MySQL released its 5.0 database which added such enterprise features as triggers, stored

procedures and constraints to its Open Source database engines. MySQL has a unique capability

among database vendors - it fits the underlying database storage engines to the nature and use of

each specific database instance. Now all database vendors claim that they do the same; but

MySQL is the only vendor with pluggable engines like MyISAM for queries and BI, Innodb and

the new Falcon engines for high speed transaction processing, or the Cluster engine for large

scale cluster processing. And because MySQL is Open Source users can and do write their own
special storage engines for changing routines called depending on whether a database instance is

clustered or not, partitioned or not, used for BI with dimensional organization or not, etc.

MySQL supports GUI Toolkits for DB Administration, Designs, Migration, and Query.

The Main Features of MySQL:

PORTABILITY:

MySQL runs on almost every flavor of UNIX, as well as Windows and MacOS X. You can

obtain binaries or source code for the MySQL server as well as the tools that access it. More

ports of the software become available every day. It is almost a given that MySQL will run on

whatever operating system you have available.

SPEED:

Using techniques such as efficient indexing mechanisms, in memory temporary tables, and

highly optimized join algorithms, MySQL executes most queries much faster than most other

database systems.

SCALABILITY:

Because of its modularity and its flexibility in configuration, MySQL can run in

systems varying in size from embedded systems to large multiprocessor UNIX servers hosting

databases with tens of millions of records. This scalability also allows you to run a copy of

MySQL on a developer-class machine, and later use the same database system on a larger

machine in production. Because it is multithreaded, MySQL efficiently utilizes resources for

multiple users, compared to other database servers that start full-fledged processes for each user.

It is not uncommon to hear of MySQL installations supporting thousands of concurrent users.

FLEXIBILITY:

MySQL lets you choose the table types you need to meet your software’s requirements, ranging

from in-memory heap tables, fast on-disk MyISAM tables, merge tables that group together

other sets of tables to form larger “virtual” tables, and transaction-safe tables such as InnoDB.

MySQL is also very tunable and includes many parameters that can be changed to increase

performance for a given solution. However, MySQL comes with sensible defaults for these

parameters, and many users never have to tune MySQL to reach a performance they are happy

with.

EASE OF USE:

MySQL is easy to install and administer. While other database systems require

special knowledge and training, not to mention special operating system configurations, MySQL

can be installed in less than 10 minutes if you’ve done it before. Even if you are a newcomer,

you should be able to install MySQL in under an hour. Once it’s installed, MySQL requires little

maintenance and administration other than adding or changing user permissions and creating or

removing databases.

FINE-GRAINED SECURITY MODEL:

You can restrict users’ rights from an entire database down to the column level based on login

name, password, and the hostname that users are connecting from. This allows you to create

secure systems by partitioning responsibilities and capabilities of different users and applications

to prevent unauthorized modification or retrieval of data.

ACCESS FROM OTHER LANGUAGES/SYSTEMS:

There are libraries and APIs for connecting to MySQL from Java (the focus of this book),

C/C++, Perl, PHP, ODBC (Microsoft Windows applications), TCL, Eiffel, and Lisp. Because of

this, a whole set of tools has appeared surrounding the use of MySQL from these languages and

systems.

CHAPTER -6 SYSTEM DESIGN

6.1 SOFTWARE DEVELOPMENT LIFECYCLE MODEL:

6.1.1 WATERFALL MODEL:-

Requirement
Definition

System & Software

Design

Implementation & Unit

Testing

Integration & System

Testing

Operation &
Maintenance
 Fig.6.1 Process model

The classic software life cycle also known as Waterfall Model models usually
include following activities.

During this phase feasibility study is conducted to identify whether the system
under development meets the organizational objectives. Identifies and analyzes the
requirements of the software system under development with respect to its
operational capabilities, its desired performance, keeping the technology, resource
and budgetary constraints in mind.

Defines the interconnection and resource interfaces between system

subsystems, components, and modules Detailed Component Design Specification:
defines the procedural methods through which the data resources within the
modules of a component are transformed from required inputs into provided
outputs.

6.2 DESIGN OVERVIEW:

Software design is a process of problem solving and planning for

a software solution. After the purpose and specifications of software are
determined, software developers will design or employ designers to
develop a plan for a solution. It includes low-level component and
algorithm implementation issues as well as the architectural view

A software design may be platform-independent or platform-specific,

depending on the availability of the technology called for by the design.

Software design can be considered as putting solution to the problem(s) in

hand using the available capabilities. Hence the main difference between Software
analysis and design is that the output of the analysis of a software problem will be
smaller problems to solve and it should not deviate so much even if it is conducted
by different team members or even by entirely different groups. But since design
depends on the capabilities, we can have different designs for the same problem
depending on the capabilities of the environment that will host the solution
(whether it is some OS, web, mobile or even the new cloud computing paradigm).
The solution will depend also on the used development environment (Whether you
build a solution from scratch or using reliable frameworks or at least implement
some suitable design patterns).

6.2.1 DESIGN CONCEPTS:

The design concepts provide the software designer with a foundation from
which more sophisticated methods can be applied. A set of fundamental design
concepts has evolved. They are:

 Abstraction - Abstraction is the process or result of generalization by

reducing the information content of a concept or an observable phenomenon,
typically in order to retain only information which is relevant for a particular
purpose.
 Refinement - It is the process of elaboration. A hierarchy is developed by
decomposing a macroscopic statement of function in a stepwise fashion until
programming language statements are reached. In each step, one or several
instructions of a given program are decomposed into more detailed
instructions. Abstraction and Refinement are complementary c.
  Modularity - Software architecture is divided into components called
modules.
 Software Architecture - It refers to the overall structure of the software and
the ways in which that structure provides conceptual integrity for a system.

Good software architecture will yield a good return on investment with

respect to the desired outcome of the project, e.g. in terms of performance,
quality, schedule and cost.

 Control Hierarchy - A program structure that represents the organization of

a program component and implies a hierarchy of control.
 Structural Partitioning - The program structure can be divided both
horizontally and vertically. Horizontal partitions define separate branches of
modular hierarchy for each major program function. Vertical partitioning
suggests that control and work should be distributed top down in the
program structure.
 Data Structure - It is a representation of the logical relationship among
individual elements of data.
 Software Procedure - It focuses on the processing of each modules
individually
 Information Hiding - Modules should be specified and designed so that
information contained within a module is inaccessible to other modules that
have no need for such information.

6.2.2 DESIGN CONSIDERATIONS:

 There are many aspects to consider in the design of a piece of software. The
importance of each should reflect the goals the software is trying to achieve. Some
of these aspects are:

 Compatibility - The software is able to operate with other products that are
designed for interoperability with another product. For example, a piece of
software may be backward-compatible with an older version of itself.
 Extensibility - New capabilities can be added to the software without major
changes to the underlying architecture.
 Fault-tolerance - The software is resistant to and able to recover from
component failure.
 Maintainability - The software can be restored to a specified condition within
a specified period of time. For example, antivirus software may include the
ability to periodically receive virus definition updates in order to maintain the
software's effectiveness.
 Modularity - the resulting software comprises well defined, independent
components. That leads to better maintainability. The components could be
then implemented and tested in isolation before being integrated to form a
desired software system. This allows division of work in a software
development project.
 Packaging - Printed material such as the box and manuals should match the
style designated for the target market and should enhance usability. All
compatibility information should be visible on the outside of the package. All
components required for use should be included in the package or specified as a
requirement on the outside of the package.
 Reliability - The software is able to perform a required function under stated
conditions for a specified period of time.
 Reusability - the software is able to add further features and modification with
slight or no modification.
 Robustness - The software is able to operate under stress or tolerate
unpredictable or invalid input. For example, it can be designed with resilience
to low memory conditions.
 Security - The software is able to withstand hostile acts and influences.
 Usability - The software user interface must be usable for its target
user/audience. Default values for the parameters must be chosen so that they
are a good choice for the majority of the users.
6.2.3 DESIGN PATTERNS:

A software designer or architect may identify a design problem which has

been solved by others before. A template or pattern describing a solution to a
common problem is known as a design pattern. The reuse of such patterns can
speed up the software development process, having been tested and proven in the
past.

6.2.4 USAGE:

Software design documentation may be reviewed or presented to allow

constraints, specifications and even requirements to be adjusted prior
to programming. Redesign may occur after review of a programmed
simulation or prototype. It is possible to design software in the process of
programming, without a plan or requirement analysis, but for more complex
projects this would not be considered a professional approach. A separate design
prior to programming allows for multidisciplinary designers and Subject Matter
Experts (SMEs) to collaborate with highly-skilled programmers for software that is
both useful and technically sound.

6.3 UML DIAGRAMS

6.3.1. USE-CASE DIAGRAM:-

The use case diagram is used to identify the primary elements and processes
that form the system. The primary elements are termed as "actors" and the
processes are called "use cases." The use case diagram shows which actors interact
with each use case.

Use case diagrams model the functionality of a system using actors and use cases. Use
cases are services or functions provided by the system to its users.

registration

login

view event
student

event registration

event status
logout

Fig.6.3.1 Use Case diagram for student.

This Use Case Diagram describes how Student interacts with the system. First
student has to register to login to the system. After logging in he can view events,
students has to know about event status then logout.

register

login

faculty
view events

view registered students

logout

Fig.6.3.1.1 Use Case diagram for faculty

In use case diagram of faculty first faculty has to register with login id,then view
events then after view registered students and logout.

login

upload event

adminstrator delete event

verify registered events

logout

Fig.6.3.1.2 Use Case diagram for administrator

Use case of administrator first login then upload event if any wrong it delete event
then goes to verify registered events add logout.
6.3.2 CLASS DIAGRAM:

The class diagram is used to refine the use case diagram and define a
detailed design of the system. The class diagram classifies the actors defined in the use
case diagram into a set of interrelated classes. Each class in the class diagram may be
capable of providing certain functionalities. These functionalities provided by the class
are termed "methods" of the class. Apart from this, each class may have certain
"attributes" that uniquely identify the class
 Fig: 6.3.2 Class Diagram

6.3.3 INTERACTION DIAGRAMS:

6.3.3.1 SEQUENCE DIAGRAM:-

A sequence diagram in a Unified Modeling Language (UML) is a kind

of interaction diagram that shows how processes operate with one another and in
what order. It is a construct of a Message Sequence Chart. A sequence diagram
shows object interactions arranged in time sequence. It depicts the objects and
classes involved in the scenario and the sequence of messages exchanged between
the objects needed to carry out the functionality of the scenario. Sequence
diagrams typically are associated with use case realizations in the Logical View of
the system under development.

Sequence diagrams are sometimes called event diagrams, event scenarios,

and timing diagrams.

UML sequence diagrams model the flow of logic within a system in a visual
manner, enabling both to document and validate logic, and are commonly used for
both analysis and design purposes. Sequence diagrams are the most popular UML
artifact for dynamic modeling, which focuses on identifying the behavior within a
system.

Interaction Diagrams

Interaction diagrams model the behavior of use cases by describing the

way groups of objects interact to complete the task. The two kinds of interaction
diagrams are sequence and collaboration diagrams.
admin valid database

1: login

2: retrieve login details

3: login details validation

4: home page

5: upload events

6: stores events

7: delete events

8: verify registration list

9: retrieve data

10: registration data

11: list registration details

12: logout

Fig: 6.3.3.1 sequence diagram of administrator

student event management database
system

1: register

2: retrieve login data

3: login data

4: validate

5: home page

6: view events

7: register events

8: response

9: display status

10: logout

Fig: 6.3.3.1.2 sequence diagram of student

faculty event management database
system
1: register

2: retrieve login data

3: login data

4: validate

5: homepage

6: view events

7: view registration list

8: retrieve registration list

9: registration data

10: display registration data

11: logout

Fig: 6.3.3.1.3 sequence diagram of Faculty.

6.3.3.2 COLLOBORATION DIAGRAM:

A collaboration diagram, also called a communication diagram or interaction

diagram, is an illustration of the relationships and interactions
among software objects in the Unified Modeling Language (UML). A
collaboration diagram resembles a flowchart that portrays the roles, functionality
and behavior of individual objects as well as the overall operation of the system
in real time.
 12: logout
1: login
5: upload events
7: delete events
8: verify registration list
admin
valid
4: home page
11: list registration details

3: login details validation

10: registration data

2: retrieve login details

6: stores events
9: retrieve data

databas
e

Fig: 6.3.3.1.4 Collaboration diagram of admin.

Collaboration diagram:

A collaboration diagram groups together the interactions between different

objects. The interactions are listed as numbered interactions that help to trace the
sequence of the interactions. The collaboration diagram helps to identify all the
possible interactions that each object has with other objects.
 4: validate
1: register
6: view events
10: logout
student
event management
system
5: home page
9: display status

3: login data
8: response

2: retrieve login data

7: register events

databas
e

Fig 6.3.3.2 collaboration diagram of students

 4: validate
1: register
6: view events
7: view registration list
11: logout
event management
faculty
system
5: homepage
10: display registration data

3: login data
9: registration data

2: retrieve login data

8: retrieve registration list

databas
e

Fig: 6.3.3.2.1 collaboration diagram of faculty.

6.3.3.3 ACTIVITY DIAGRAM:

 Activity diagrams are graphical representations of workflows of stepwise
activities and actions with support for choice, iteration and concurrency. [1] In
the Unified Modeling Language, activity dia grams can be used to describe the
business and operational step-by-step workflows of components in a system. An
activity diagram shows the overall flow of control.

student

login

valid

yes

home
page

perform
activity

view event event

event registration status

logout

Fig 6.3.3.3.1 activity diagram of student

 Faculty

login

valid

yes

home
page

student's
attendance

perform
activity

event
status
view event
event registration

logout

Fig 6.3.3.3.2 activity diagram of faculty

 Admin

login

valid

yes

home
page

Upload
events

Delete
events

event
status
view event
event registration

logout

Fig: 6.3.3.3.3 activity diagram of Admin.

6.3.4 PHYSICAL DIAGRAMS:

6.3.4.1 COMPONENT DIAGRAM:-

The component diagram helps to model the physical aspect of an object-

oriented software system. It illustrates the architecture of the software component
and the dependencies between them. Those software components include run-time
executable components also the source code components.

web web server

browser

database

Fig: 6.3.4.1 Component Diagram

6.3.4.2 DEPLOYMENT DIAGRAM:-

Deployment diagrams are used to represent the physical architecture of a

system. They present the distribution of the software components on the set of
execution units (nodes). Nodes and artefacts are the main concepts in a deployment
diagram.

Deployment diagrams (an example is shown in the screenshot below) are

created in packages, classes, interfaces, components, artefacts or nodes.

web browser web server

database

Fig: 6.3.4.2 Deployment Diagram

CHAPTER-7 SYSTEM IMPLEMENTATION

7.1 MODULE DESCRIPTION:

7.1.1 ADMINISTRATOR MODULE:

 This module is the one who organizes all the users data, allow the various
users to create the id function.

 Stimulus/Response Sequences:
 Stimulus: Administrator logins with his/her user id and
password.
 Response: If it is validate user then it get accessed or accessed
denied.
 Stimulus: Administrator provides user id and password to all
the users.
 Response: Administrator updates modify the data if required.

Administrator: the admin responsibilities are managing the system performing

some special operations on records of database

7.1.2 USER MODULE:

A user is the one that create an id and then login with the help of it
and performs various activities like view events, register for the events,
checks the events status.
Stimulus/Response Sequences:
 Stimulus: User logins with id and passwords.
 Response: if it is validate then it get accessed or denied.

User: does login, registration, view events, events registration, event status, logout
7.1.3 FACULTY MODULE:

A faculty is the one who register and checks for the registered
students for attendance and view the events.
Stimulus/Response:
 Stimulus: faculty login with id and password.
 Response: if it is validating faculty then it get accessed or denied.

Faculty: does login, register, and view events, view register students, logout.