Ch. 1: Introduction:: 1.1project Detail

KORAT ABHAY M.
Ch. 1: Introduction:
1.1Project detail:
1.1.1Definition:
 The definition of the project is College Technical Event Scheduling and
Organization. This application leads for the handling and formation of the event and
its schedule.
1.1.2 Project Profile:
College Technical Festival Event organization application.

Name of Project:
The Application generally relates to a system and method to
schedule events, and more particularly, to a system and
Object Description: method for scheduling technical events among entities such
as organization.
OS: Android
Front End: Android version 4.2
Back End: SQLite Database
Methodology: Object Oriented Development
Eclipse Indigo
Android Virtual Device(AVD)
Support Tools Used: Microsoft Office 2003/2007
Microsoft Visio,
Time Duration: 1 year
1.2 Purpose:
The purpose of making this application is to provide a easiness of finding the event
schedule at one place. The user will find the technical event schedule in one application
rather to visit different web pages. The invention satisfies the foregoing needs and avoids
the drawbacks and limitations and frustrations of the prior art, and provides a better, more
timely and effective process of communication to schedule and coordinate events by
utilizing Internet-based application. The people may get fail to answer the call or would be
Computer Science And Engineering 1 abhaykorat89@gmail.com

KORAT ABHAY M.
unable to check the email so this Application will lead a better communication of the
people about the event.
1.3Project Scope:
The scope of the project includes creating a user interface to Android system as well as
a backend that will emulate some of its behaviour, specifically for testing. Event
management is the application of management to the creation and development of
Technical festivals, events and conference.
The Application generally relates to a system and method to schedule events, and more
particularly, to a system and method for scheduling technical events among entities such
as organization that may have limitations for scheduling, such as geographical
requirements, constraints by timing, conflicts, availability, or other factors.
This Application leads to provide the user especially the student the reliability in
finding the schedule of events at one place rather to go for each of the college websites.
The college will just have to post the event in .pdf file and that will be downloaded by
students. By this Application the matter of time which go in informing each other for the
event will also be solved out.
1.4Objectives:
The people sending mail or message of technical event to other is wasting of time and
memory. To overcome this problem our invention provides a medium where one can get
the schedule of an event by just opening our application with the internet connection and
refreshing it.Another thing our Application provides is all in one characteristic. i.e. all
technical event schedule in just one application.
Ch. 2: About the System:

2.1 Software Requirement Specification
 Introduction:
This Software Requirements Specification (SRS) document is intended to give a
complete overview of College’s Event Management Organization Project (working
title), including the user interface and Event organization. The SRS document details
all features upon which CTFEOA have currently decided with reference to the manner
and importance of their implementation.
 Product Perspective
This product and application is newer which provides the user a new utility in their
role as a student. We give this application to the college so they can post their

KORAT ABHAY M.
upcoming events in the database. The other person who will use this application will
be student they will get the details of the upcoming technical events by just logging to
the application and downloading the desired event details.
 Product Features
Functionality
The invention satisfies the foregoing needs and avoids the drawbacks and
limitations and frustrations of the prior art, and provides a better, more timely and
effective process of communication to schedule and coordinate events by utilizing
Internet-based application.
This product contains three major Users. First the admin will allow the user for
accessing this application by giving the permission rights and access control.
Second The college login will have a right to see the events listing and they can
post their new schedule of a technical event as well. And third The End User i.e.
Student, they can see the list of the events and schedule of event.
 User Classes and Characteristics
Admin
The Admin will have all the access to this product. The Admin will provide the
access permission to the users which are students and Colleges. The admin can also
delete or discard the unwanted events reported as spam. They also manage the
database like deleting the past events.
College
The college admin will be the second admin to this product, but with less access
control. The college admin will be provided the access the database like to add
event in .pdf format and to delete event. The college admin will be logged in using
their id and password provided.
Student
The student are the end-user entity, they will be having the access rights to see
the event schedule by pdf format. And register their new account providing their
basic details.
 Other Non-Functional Requirements
Performance Requirements

KORAT ABHAY M.
Better performance will lead to better operating environment. For better

environment the user needs a high speed internet so that the upload and download
will be done better.
Security Requirements
The login details must be kept confidential so that other user may not login
using other's id and password. Especially the college login details must be kept
confidential so that other user may not post a fake event schedule.
2.2Feasibility Study
 Feasibility Analysis:
 A feasibility study is a short focused, which aims to answer a number of questions:
 Does the system contribute to the overall objective of the organization?
 Can the system be implemented using the current technology and within given cost
and schedule constraints?
 Can the system be integrated with system which is already in place?
 Economic Feasibility:
 The project is economically feasible as it only requires a mobile phone with
Android operating system.
 The application is free to download once released for student and payable for
college into Android market.
 The users should be able to connect to internet through mobile phone and this
would be the only cost incurred on the project.
 Technical Feasibility:
 To develop this application, an internet connection, a database server, a web server
and software are required. The current project is technically feasible as the
application was successfully deployed on Android Emulator.
 Behavioral Feasibility:
 The application is behaviorally feasible since it requires no technical guidance, all
the modules are user friendly and execute in a manner they were designed to.
2.3 Project Plan
At the beginning of the project, we scheduled meeting time for the group to discuss on
the design and implementation of the software and what language to use in writing the
software. We had severalmeetings to this effect. When then developed a time-line for the
project–when we would be releasing the first version for scrutiny and the estimated time

KORAT ABHAY M.
we thought we would use for refactoring. We alsopondered on a suitable name to give the
project.
The group was then divided that would work on parts of the code. We kept in
touchwith each other and whenever we had difficulties, we asked each other questions. On
someoccasions, we had to pretend we were the customer so as to try to figure out some of
the things thatuser would desire, such as the friendliness of the user interface and ease of
navigation through thesoftware.
Figure 1 GanttChart
Ch. 3: Analysis:
3.1 Technology And Analysis
The technology used here is ANDROID. Android is basically an operating system for
smartphones. But we find now integrated into PDAs, touch pads or televisions, even cars
(trip computer) or netbooks. The OS was created by the start-up of the same name, which
is owned by Google since 2005. Now a day’s people using android as an operating system
in their mobile phones have been increased. So people using android are, much more and
they are familiar with it. Students increase their craze about android phones. The operating
system is based on Linux. Android allows multitasking in the sense that multiple
applications can run simultaneously. The database here used is SQLite. The lighter version
of SQL.
Software and Hardware Requirements
 Software Requirements:
 Android version 2.3 or above.
 Hardware Requirements:
 Minimum 128MB RAM

KORAT ABHAY M.
 Minimum 20MB space.

 Hardware Constraints/Limitations
 Require Android supporting devices.
 Would work better in android 4.1 or above.
 Internet access needed.
Ch. 4: Design:
4.1E-R Diagram
Entity-Relationship diagram is a detail & logical representation of entities and data
elements for an organization. This technique is used in database that helps in an enterprise
are related to each other. There are 3 types of E-R diagram:
1. one to one :
It is a one to one relationship is an association between 2 entities.
2. one to many:
One-to-many relationship exists when one entity related to one or more entity.
3. Many to many:
It describes entities that may have many relationships among each other.
The basic symbols for E-R diagram are as described below:

This rectangle represents entity set.
This arrow is known as flow line. It links attributes to entity set &
entity set to relationship.
This diamond represents relationship among entity set. The

association among several entities in E-R diagram is known as
Relationship.
This oval represents various types of data items that describes an

entity are known as its attributes.

KORAT ABHAY M.
Figure 2 E-R Diagram
4.2Data Flow Diagram

The data flow diagrams are pictorial or graphical representation of the outline of the
system study. The data flow diagram covers all the processes and data storage area which
takes place during any transaction in the system. The data flow diagrams are functionally
divided into context level, Zero level, First level and Second level data flow diagrams.
Following are the Symbols used in DFD:

Process: Here flow of data is transformed. E.g. Purchase
of items, update inventory file, etc.
External Entity: A source or destination of data which is
external to the system. E.g. Customer, Supplier etc.

KORAT ABHAY M.
A data flow: It is packet of data. It may be in the form of

document, letter etc.
Data store: Any store data but with no reference to the

physical method of storing.
Context Diagram:
College Information
(0.0)
College
Student Registration Information Event Organize
College Technical Festival Event Admin
Organization Application
Event Schedule Give Fnctionality
User Acess
Services
Admin
Figure 3 Context Diagram

1 Level DFD:

KORAT ABHAY M.
Send Message Send Message

(3.0)
Request Password Request Password
Forget
Password
Admin
Fetch Password Database
Person Check Data

Database
Request data Admin Access
College Information
Get Data
(1.0)
Student Registration Information Event Organize College
Registration
Event Schedule Give Fnctionality
Login Information Login Information

Get Schedules Add Event
User Access
Services
(2.0) (2.0)
Login Sucess Login Sucess
Admin
Figure 4Level1 DFD

Level-2 DFD for Sign In/Sign Up:
(1.1)
Student Register Insert Person_data
Registration
Fetch data
User information
(1.2)
Login
College Information
College
Figure 5Level-2 DFD for Sign In/Sign Up

 Level-2 DFD for College:

KORAT ABHAY M.
(2.2)
Update Person_data
Update
Details
Give Details
(2.1)
College Details Get Data
Login
Event Title
(2.3)
Create Event
Upload pdf schedule
(2.4)
Event_pdf
Post Event
Figure 6 Level-2 DFD for College

Level-2 DFD for Admin:
Update Users
(2.3)
List of User
Fetch
view
(2.2)
Admin details Fetch Details Person_data
login
Accept
Enter details
Insert
(2.1)
Give Login Details Request
(2.4)
College
Registration registration
College
Figure 7 Level-2 DFD for Admin

 Level-2 DFD for Forget Password:

KORAT ABHAY M.
Receive
(3.1)
(3.2)
Student/
Provide Username Access Person_data Send password
College Forget
Message
password
Figure 8 Level-2 DFD for Forget Password
4.3Use Case Diagram

Use Case for System:
SYSTEM BOUNDARY
Login
*
*
*
List Of User
*
*
* **
Update Details
*
Top Package::College *
Post Event Name

*
Upload Event pdf

*
*
*
*
Payment
* *
**
Top Package::Admin
Check Event
*
*
*
Get Schedule
* *
*
*
Top Package::Student
Registration
Delete User
Register College
Figure 9 Use Case Diagram for System

Use Case for Admin:

KORAT ABHAY M.
ADMIN BOUNDARY
Login
Register College
Get Payment
*
*
**
**
Delete User
Top Package::Admin *
View Users
*
Figure 10 Use Case for Admin
Use Case for College:

COLLEGE BOUNDARY
Login
Update Details
Post Event Name

*
**
*
**
Upload Event pdf

Top Package::College *
Payment
*
Figure 11 Use Case for College

Use Case for Student:

KORAT ABHAY M.
STUDENT BOUNDARY
Login
Update Details
Check Schedule
*
**
*
**
Get Event pdf

Top Package::Student *
Registration
*
Figure 12 Use Case for Student

4.4Activity Diagram
Student Registration:
Strat Application
/ NO / YES
Reenter Add student information
/ NO
Incorrect VALID?
/ YES
Save Data
Registration Sucessful
Figure 13 Student Registration Activity Diagram

KORAT ABHAY M.
College Registration:
Strat Application
Request for Regestration to Admin
/ NO
Incorrect VALID?
/ YES
Payment
Get ID and Password
Figure 14 College Registration Activity Diagram

Student Activity:
Enter Details
Login
/ NO
Incorrect VALID?
/ YES
Check Schedule
Download pdf File
Figure 15 Student Activity Diagram
College Activity:

KORAT ABHAY M.
Enter Details
Login
/ NO
Incorrect VALID?
/ YES
Choose Option See Events
Create Event
Enter Details
Upload pdf File
Post Event
Figure 16 College Activity Diagram

KORAT ABHAY M.
Admin Activity:
Strat Applicatin
Re-enter admin login
/ NO
valid
/ YES
/ NO
check college request for registration
/ YES
response for permision
logout
Figure 17 Admin Activity Diagram

KORAT ABHAY M.
4.5Class Diagram
Figure 18 Class Diagram

KORAT ABHAY M.
4.6Sequence Diagram
Student Login Activity College Admin Activity Event Activity Payment Activity Admin Activity
Registration Request For Registration
Response ( ) Acknowlegement Verify Request ( )

Register ( )
Confirm Password Payment ( ) Get Payment ( )
Response ( ) Get Response Response ( )

Confirmation ( )
Login Do Login ( )
X X
Generate Event ( )
Notification Event ( )
Event Schedule ( )
Get Schedule ( )
Update Schedule ( )
Get New Schedule ( )
Logout
Response ( ) Logout ( )
X X X X
Figure 19 Sequence Diagram

KORAT ABHAY M.
4.7System Flow Diagram
Figure 20 System Flow Diagram

4.8 Data Dictionary
1. Admin_login:
Table 1Admin_Login
Field Name Data Type Size Null
Username Varchar 30 Not Null
Password Varchar 30 Not Null
2. College _login:

KORAT ABHAY M.
Table 2College_login
College_name Varchar 50 Not Null
College_no Number 15 Not Null
E-Mail ID Varchar 30 Not Null
3. Student_login:
Table 3Student_login
First Name Varchar 30 Not Null
Last name Varchar 30 Not Null
Gender Boolean 2 Not Null
Contact No. Number 12 Not Null
Reg_Type Varchar 10 Not Null
4. Event_pdf:
Table 4Event_pdf
Event_id Number 30 Not Null
Event_name Varchar 30 Not Null
Pdf_no Number 30 Not Null
Pdf_size Number 30 Not Null
Pdf_date/time Date/time 8 Not null
5. Event_registerd_information:
Table 5Event_registerd_information
Event_name Varchar 30 Not Null
Event_id Number 30 Not Null

KORAT ABHAY M.
Event_date/time Date/time 30 Not Null

Student_name Varchar 30 Not Null
Student_id Number 15 Not Null
Student_add Varchar 50 Not Null
Student_contact Number 15 Not Null
4.9User Interface
Loading Page: This page is shown at the starting of the application.
Figure 21 Starting Page

KORAT ABHAY M.
Login Page: The below figure shows the login screen/activity of an application.
Figure 22 Login Page

Student Registration Page: This below given figure shows the user interface of the
registration activity of student.
Figure 23 Student Registration

KORAT ABHAY M.
Student Registration Success: The given figure shows the activity strike to the student
user when the login is successfully done.
Figure 24 Student Login Success

KORAT ABHAY M.
College Registration Success: The given figure shows the activity strike to the
College user when the login is successfully done.
Figure 25 College Login Success

Admin Login: The figure shows the activity when Admin is successfully login.
Figure 26 Admin Login Success

List Of User(Admin Login): The figure given below shows the list of user in an activity.
This can be seen by only admin of the application.

KORAT ABHAY M.
Figure 27 List Of User(Admin Login)

College Registration Activity: The given figure shows the activity of college registration.
This can be done by admin only.
Figure 28 College Registration

Forget Password: Thebelow figure shows the activity for forget password when the user
forget the password they will get it by entering the username.

KORAT ABHAY M.
Figure 29 Forget Password Activity

Receive Password: The password is received by the user to their registered mobile
number.
Figure 30 Password Received by Message

KORAT ABHAY M.
Ch.5: Testing:
5.1 Testing Plan
5.1.1 The Testing Process:
We have tested the software process activities such as design, implementation and
requirement engineering because design errors are very costly to repair once system has
been started to operate. Therefore, it is quite obvious to repair them at early stage of the
system. So analysis is the most important process of any project.
5.1.2 Requirement Traceability:
As the most interested portion is whether the system is meeting its requirements or not,
for that testing should be planned so that all requirements are individually tested. We have
to check out that output of certain combinations of inputs gives the desirable results or not.
Your requirement specification gives us the path to get the desirable result.
5.1.3 Tested Modules:
 Administrator
 Users
 Visitors
5.1.4 Testing Schedule:
We have tested each procedure back to back so that errors and omissions can be found
as early as possible. Once the system has been developed fully we tested it on another
machines, which differs in combinations.
5.2 Testing Strategy
A strategy for the software testing integrates software test case design methods into
awell-planned series of steps that result in the successful construction of software. The
strategy provides a road map that describes the steps to be conducted as part of testing.
When these steps are planned and then undertaken, very much efforts, time and resources
are required.
A software testing strategy should be flexible enough to promote a customized testing
approach. At that same time it must be rigid enough to promote reasonable planning and
management tracking as the project progresses.
A software testing strategy has following characteristics

KORAT ABHAY M.
 Testing begins at the component level and works outward towards the
integration of the entire computer based system.
 Different testing techniques are appropriate at different points in time.
 Testing & Debugging are different activities but debugging must be
accommodated in any testing strategy.
We checked entire project thoroughly so not even a single mistake would be there.
5.3 Test Methods
Testing presents an interesting anomaly for the software engineering activities, the
engineer attempts to build software from an abstract concept to a tangible product. Now
comes testing. The engineer creates a series of test case that are initiated to "demolish" the
software that has been build. Infect, testing is the one step in the software process that
could be viewed (psychologically, at least) as destructive rather than constructive.
Models of Testing:-
There are different Models of testing. On the basis of testing methods there are two
types of testing:
1. Black-box testing.
2. White-box testing
Black-box tests are used to demonstrate that software functions are operational, that
input is properly accepted and output is correctly produced, and that integrity of external
information is maintained.
White-box tests are used to examine the procedural details. It checks the logical paths
by test case. It can also checks the conditions, loops used in the software coding. It checks
that loops are working correctly on defined boundary value.
5.3.1 White-Box Testing:
White-box testing sometimes called glass-box testing, is a test case design method that
users the control structure of the procedural design to drive the test case. Always we are
thinking that there is no necessary to execute or checks the loops and conditions. And so
large number of errors is uncovered. With using white-box testing methods, we have
checked that; all independent paths within a function have been executed at least once, All
logical decisions on their true and false side, A11 loops working correctly at their boundary
values and within their specified conditions.
In our coding we test that all the loops works truly in each module. The one technique
of white-box testing is basis path testing. It contains two parts, one is flow graph notation

KORAT ABHAY M.
and the second is cyclometer complexity. In flow graph notation we are checking logical
control of flow. By using cyclometer complexity we find complexity of our project
structure.
5.3.2 Black-Box Testing:
Black-box testing focuses on the functional requirements of the software. That is black-
box testing enables the software engineer to drive sets of input conditions that will fully
exercise all functional Requirements for the program. Black-box testing is not an
alternative to white-box testing techniques. Rather, it is a complementary approach that is
likely to uncover a different class of errors than white-box methods.
We use in our coding to find errors in the following categories:
 Incorrect or missing functions
 Interface errors
 Errors in database
 Performance errors
 Initialization and termination errors.
Unlike white-box testing, which is performed earlier in the testing process, black-box
testing tends to be applied during later stages of testing. Because black-box testing
purposely disregards control structure, attention is focused on the information domain.
By applying black-box techniques, we derive a set of test cases that satisfy following
criteria test cases that reduce, by a count that is greater than one, the number of additional
test cases must be designed to achieve reasonable testing.
Level 1 - Build Acceptance Tests
Other related test cases ensure that adopters received the proper Development
Release Document plus other build related information (drop point, etc.). The objective
is to determine if further testing is possible. If any Level 1 test case fails, the build is
returned to developers un-tested.
Level 2 - Smoke Tests

The objective is to determine if further testing is possible. These test cases should
emphasize breadth more than depth. All components should be touched, and every
major feature should be tested briefly by the Smoke Test. If any Level 2 test case fails,
the build is returned to developers un-tested.

KORAT ABHAY M.
Level 2a - Bug Regression Testing

Every bug that was “Open” during the previous build, but marked as “Fixed,
Needs Re-Testing” for the current build under test, will need to be regressed, or re-
tested. Once the smoke test is completed, all resolved bugs need to be regressed. It
should take between 5 minutes to 1 hour to regress most bugs.
Level 3 - Critical Path Tests
Critical Path test cases must pass by the end of every 2-3 Build Test Cycles. They
do not need to be tested every drop, but must be tested at least once per milestone.
Thus, the Critical Path test cases must all be executed at least once during the Iteration
cycle, and once during the Final Release cycle.
Level 4 - Standard Tests
Test Cases that need to be run at least once during the entire test cycle for this
release. These cases are run once, not repeated as are the test cases in previous levels.
Functional Testing and Detailed Design Testing (Functional Spec and Design Spec
Test Cases, respectively). These can be tested multiple times for each Milestone Test
Cycle (Iteration, Final Release, etc.).Standard test cases usually include Installation,
Data, GUI, and other test areas.
Level 5 - Suggested Test
These are Test Cases that would be nice to execute, but may be omitted due to
time constraints
Bug Regression:
Bug Regression will be a central tenant throughout all testing phases. When a
Severity 1 bug fails regression, adopters testing team should also put out an immediate
email to development. The Test Lead will be responsible for tracking and reporting to
development and product management the status of regression testing.
5.4Test Cases
Table 6 Testing New Student Entries
Sr. Test Case Validation or Test Data Expected Actual Modification
No Requirement Result Result done
1 New User ID auto Adding a New entry Successful No
Student generation new User should be modification
Entry done
successfully

KORAT ABHAY M.
2 New All Data must All details Successful Successful No

Student be required entry Modification
Entry
3 New All Data All Details Shows Showing No
Student Inserted Error error Modification
Entry as
admin or
existing
username
Table 7Testing For Forget Password
Sr.No Test Case Validation Test Expected Actual Modification
or Data Result Result done
Requirement
1 Provide Username Send Successfully successful No
username must required Password Send Modification
correctly To their Done.
number
Table 8Testing Login for Administrator/Student/College
Sr. Test Case Validation or Test Expected Actual Modification
No Requirement Data Result Result done
1 Right Authentication User Login Done Successful No
Login Name, Successfully modification
Password
and type
entered
2 Wrong Authentication User Login Unsuccessful No
Login Name & Won’t be modification
Password Successful
entered
Table 9Testing New College Entries
Sr. Test Case Validation Test Data Expected Actual Modification

KORAT ABHAY M.
No or Result Result done

Requirement
1 New User ID auto Adding a New entry Successful No
College generation new User should be modification
Entry done
successfully
2 New All Data must All details Successful Successful No
College be required entry Modification
Entry
3 New All Data All Details Shows Showing No
College Inserted Error error Modification
Entry as
admin or
existing
username
Ch. 6: Conclusion And Future Work:

Conclusion:
This Application leads to the new product for student and college which provide
effective intercommunication of technical event. The wastage of time in sending mail,
calling each other and checking each other site is reduced here. The student will get a better
medium for getting Event Schedules.
Future Enhancement:
 Registration Services:
The future needs of providing registration for the specific event will be provided. This
provides students not to interact with the college for registration, but they can directly
register their names in any event.
 Email Services:
When the user is registered they will get the confirmation mail to their registered mail.
This service will make sure to the Student that they are successfully registered to the event.

Ch. 1: Introduction:: 1.1project Detail

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Ch. 1: Introduction:: 1.1project Detail

Încărcat de

Drepturi de autor:

Formate disponibile

KORAT ABHAY M.

College Technical Festival Event organization application.

Time Duration: 1 year

Computer Science And Engineering 1 abhaykorat89@gmail.com

Ch. 2: About the System:

Computer Science And Engineering 2 abhaykorat89@gmail.com

Computer Science And Engineering 3 abhaykorat89@gmail.com

Better performance will lead to better operating environment. For better

Computer Science And Engineering 4 abhaykorat89@gmail.com

Computer Science And Engineering 5 abhaykorat89@gmail.com

 Minimum 20MB space.

The basic symbols for E-R diagram are as described below:

This diamond represents relationship among entity set. The

This oval represents various types of data items that describes an

Computer Science And Engineering 6 abhaykorat89@gmail.com

Figure 2 E-R Diagram

4.2Data Flow Diagram

Following are the Symbols used in DFD:

Computer Science And Engineering 7 abhaykorat89@gmail.com

A data flow: It is packet of data. It may be in the form of

Data store: Any store data but with no reference to the

Event Schedule Give Fnctionality

Figure 3 Context Diagram

Computer Science And Engineering 8 abhaykorat89@gmail.com

Send Message Send Message

Person Check Data

Event Schedule Give Fnctionality

Login Information Login Information

Login Sucess Login Sucess

Figure 4Level1 DFD

Figure 5Level-2 DFD for Sign In/Sign Up

Computer Science And Engineering 9 abhaykorat89@gmail.com

Upload pdf schedule

Figure 6 Level-2 DFD for College

Give Login Details Request

Figure 7 Level-2 DFD for Admin

Computer Science And Engineering 10 abhaykorat89@gmail.com

Figure 8 Level-2 DFD for Forget Password

4.3Use Case Diagram

Post Event Name

Upload Event pdf

Figure 9 Use Case Diagram for System

Computer Science And Engineering 11 abhaykorat89@gmail.com

Figure 10 Use Case for Admin

Use Case for College:

Post Event Name

Upload Event pdf

Figure 11 Use Case for College

Computer Science And Engineering 12 abhaykorat89@gmail.com

Get Event pdf

Figure 12 Use Case for Student

Figure 13 Student Registration Activity Diagram

Computer Science And Engineering 13 abhaykorat89@gmail.com

Request for Regestration to Admin

Get ID and Password

Figure 14 College Registration Activity Diagram

Download pdf File

Figure 15 Student Activity Diagram

Computer Science And Engineering 14 abhaykorat89@gmail.com

Choose Option See Events

Upload pdf File

Figure 16 College Activity Diagram

Computer Science And Engineering 15 abhaykorat89@gmail.com