A Project Report On

Health Club Management System

SUBMITTED BY:

Subhay kumar (BE/5688/07), CSE

Sourav kumar (BE/5706/07), CSE
Sujeet prakash (BE/5725/07), IT
Pooshan (BE/5535/07), CSE

In the Partial Fulfillment of the degree of

Bachelor of Engineering
In the discipline of
Computer Science & Engineering/Information Technology

Under the guidance of

Prof. Niloy Bhattacharya
Dept. of Computer Science & Engineering

Birla Institute of Technology, Mesra, Ranchi-835215

 Certificate

This is to certify that the project titled “Seminar Management System

submitted by

Subhay Kumar (BE/5688/07)

Sourav Kumar(BE/5706/07)
Sujeet Prakash (BE/5725/07)
Pooshan(BE/5535/07)

as a partial fulfillment of their project, VII th semester (Bachelor of

Engineering-Computer Science & Engineering/Information Technology)
is genuine. No part of the project report has been submitted to any other
institute/University for award of any type of degree.

Prof. Niloy Bhattacharya

Dept. of Computer Science & Engineering
Patna
 Acknowledgment

We avail this opportunity to offer our sincere thanks and deep sense of
gratitude to our project coordinator & guide Prof. Niloy Bhattacharya,
Department of Computer Science & Engineering, B.I.T. Mesra (Patna
Campus). His constant inspiration and dynamic guidance has helped us a
lot to complete and materialize our project work.

We would also like to sincerely thank our Director Dr. K.K. Srivastava
who helped us by providing us a platform to pursue our project.
Lastly, we would like to thank all our friends and peers for their
suggestions and kind help.

Subhay Kumar (BE/5688/07)

Sourav Kumar(BE/5706/07)
Sujeet Prakash (BE/5725/07)
Pooshan(BE/5535/07)
Table of Contents :

1.0Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, acronyms, and abbreviations
1.4 References
1.5 Overview
2.0 Overall description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and dependencies
3.0 Specific requirements
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communications interfaces
3.2 Functional requirements
3.3 Non- Functional requirements
3.4 Software system attributes
4.0 High Level Design Overview
4.1 Application overview
4.2 Operational Concepts and Scenario
5.0 Detailed Design
5.1 Sequence Diagram
5.2 Class Diagram
5.3 Use Case Diagram
5.4 Activity Diagram
5.5 Database Diagram
6.0 Assumptions
6.1 Error Handling Strategy
Introduction:
We have decided to investigate the use of a Health Club
Management System. This system would be used by members
who may be customers and administrators of the club to check
all the events, availability of the facilities, and by the
administrators to update the databases.
The purpose of this document is to analyze and elaborate on the
high-level needs and features of the Health Club Management
System. It focuses on the capabilities and facilities provided by
the software. The details of what all are the needs of the Health
Club Management System and if it fulfils these needs are
detailed in the use-case and supplementary Specifications.

Purpose:

The purpose of Software Requirements Specification (SRS)

document is to describe the external behaviour of the Health
Club Management System. Requirements Specification defines
and describes the operations, interfaces, performance, and
quality assurance requirements of the Health Club Management
System. The document also describes the non-functional
requirements such as the user, hardware and software
interfaces. It also describes the design constraints that are to be
considered when the system is to be designed, and other factors
necessary to provide a complete and comprehensive
description of the requirements for the software. Thus the
Software Requirements Specification (SRS) captures the
complete software requirements for the system.
Scope:
we are going to describe the division of entire architecture into two
modules/classes- User and Admin (administration). The operations
to be executed by the user is viewing of profile and dues only. The
operations that can be exercised by an admin are search records,
modify record delete record, add record, generate dues and view
dues. All these have been shown through activity diagram. Apart
from these use case diagram, sequence diagram and database
diagram have also been shown.:

Definitions, Acronyms and Abbreviations :

The following are the list of conventions and acronyms used in
this document and the project as well:

 Administrator: A login id representing a user with user

administration privileges to the software.

 User: A general login id assigned to most users.

 Client: Intended users for the software

 SQL Server: A server used to store data in an organized

format
Overview :

The SRS will provide a detailed description of the Health Club

Management System. This document will provide the outline of
the requirements, overview of the characteristics and
constraints of the system.
The SRS will provide the general factors that affect the product
and its requirements. It provides the background for those
requirements. The items such as product perspective, product
function, user characteristics, constraints, assumptions,
dependencies and requirements subsets are described.
The SRS contains all the software requirements mentioned in
detail sufficient enough to enable designers to design the
system to satisfy the requirements and testers to test if the
system satisfies those requirements.
Assumptions and Dependencies :
The product needs following third party product.
 Microsoft Sql Server 2005 to store the database.

 Microsoft Visual Studio 2008 as a development tool

Hardware interfaces:
Server Side:

 Operating System: Windows XP, Windows VISTA ,

Windows 7

 Processor: Pentium 3.0 GHz or higher

 RAM: 256 Mb or more

 Hard Drive: 10 GB or more

C lient side:

 Operating System: Windows XP, Windows VISTA,

Windows 7

 Processor: Pentium III or 2.0 GHz or higher.

 RAM: 256 Mb or more

Software interfaces :

 Database: SQL Server.

Communications interfaces :

The Customer must connect to the Internet to access the

Website:

 Dialup Modem of 52 kbps

 Broadband Internet

 Or other mode of internet

Functional Requirements

Based upon the kind of user, it classifies the functionalities into two
broad sections -Member Functionalities and Administrative
Functionalities.
User Functionalities:
It underlines the accessing authorities of a Member .As shown in the
class and use case diagram. The operation executable by any member is

1. Login

2. View profile

3. View dues details

Administrator Functionalities:
It specifies the accessing authorities of the administrator. As
demonstrated by the class diagram and use case diagram .The various
operations executable

by the administrator are-

1. Login

2. Add member record.

3. Search member record.

4. Modify member record.

5. Delete member record.

6. Generate Dues.

7. View Pending payments.

Activity diagram describes the step by step process of every operation of

member and administrator.
Non-Functional Requirements

The basic design structure remains to be flexible. Hence, additional

features as enhancements can be added at later stage. It is portable and
can be easily transferred from one platform to another, satisfying the
basic operational criteria. The basic design structure is too secure
enough to allow anyone to interfere with the database.

Software system attributes :

 The Quality of the database is maintained in such a way so

that it can be very user friendly to all the users of the
database.
 The database should have the option of event search by a
variety of fields like event name, event id, details etc.

High level Design Overview:

Application Overview

The entire system has been divided into a number of subsystems

depending upon their specific functionalities. Each has its own specific
input and output. The subsystems are -

1. Member login

a. Ask for Member Username and Password.

b. System verifies them.

c. If correct then Login or else Access denied.

2. Member view profile

a. Ask for selecting View profile.

b. Profile displayed.

3. Member View dues details

a. Ask for selecting dues details.

b. Details displayed.

4. Administrator login

a. Ask for Username and Password.

b. System verifies them.

c. If correct then Login or else Access denied.

5. Add Member record

a. Ask for selecting add Member record.

b. Data entered.

c. Record added.

6. Search Member record

a. Ask for selecting search Member record.

b. Specific data entered (e.g. roll number).

c. Member record accessed.

7. Modify Member record

a. Ask for selecting modify Member record.

b. Select specific Member

c. Modifying Data entered.

d. Record modified.

8. Delete Member record

a. Ask for selecting delete Member record.

b. Select specific Member

c. Record deleted.

9. Generate Dues

a. Ask for selecting generate dues.

b. Select specific Member.

c. Amount generated.

10. View Pending Payments

a. Ask for selecting view pending payments.

b. Select specific Member.

c. Details displayed.

Operational Concepts and Scenarios

The operations executed by different users upon database is

shown by the following diagrams-

1. Use Case diagram - A use case can be viewed as a set of related

scenarios tied together by a common goal. The main line sequence
and each of the variations are called scenarios or instances of the
use case. Each scenario is a single path of user events and system
activity.

Important use is in designing the user interface in the

implementation of the use case targeted for each specific category
of users who would use this use case.

2. Class diagram - A class diagram describes the static structure of

a system .it shows how a system is structure rather than how it
behaves. The main constitutes of a class diagram are classes and
their relationships: - generalizations ,aggregation, association ,and
various kind of dependencies.

The classes represent entries with common features, i.e. attribute

and operations.
 3. Activity diagram - The activity diagram focuses on representing
various activities or chunks of processing and their sequence of
activation.

An activity is a state with an internal action and one or more

outgoing transitions which automatically follow the terminations
of the internal activity.

Activity diagram are similar to the procedural flow charts .the main
difference is that activity diagrams support description of parallel
activities and synchronization aspects involved in different
activities.

The activity fig shows the different processes during registration in

health club .after sign up ,fee received .login validation checking,
visitor info and then logout.

4. Sequence diagram - A sequence diagram shows interaction

among objects as a two-dimensional chart. The chart is read from
top to bottom. The object participating in the interaction are
shown at the top of the chart as boxes attached to vertical dashed
line .an object appearing at the top of sequence diagram signifies
that the object is created even before the time the use case
execution was initiated .the vertical dashed line is called the
object’s lifeline.

Detailed Design
It includes various designs which represent the relationship, interaction
and methodology of various operations involved. The designs are
a. Sequence Diagram

b. Use Case Diagram

c. Class Diagram

d. Activity Diagram

Module description

Here, interaction of two objects- Member and admin with hostel

database has been shown.It is called a Sequence Diagram.The
operations between different objects is explicitly mentioned.The
Sequence wise operations which takes place in the application has been
clearly shown with the help of:

1. Sequence Diagram for Member and Hostel Database

2. Sequence Diagram for Admin and Hostel Database

In the Sequence Diagram,the main menu object represents the state

reached only after successful login of the Member as well as the
Admin.The whole transaction then takes place from the main menu.The
Status object represents the verification part.The state whether the
user has successfully logged in or not.

The Data Register Table in the Admin Sequence diagram is a point

where the admin enters data.If correct data is entered , the Admin can
access the HEALTH CLUB DATABASE.Otherwise, it cannot.
 admin

+admin id
+admin password
+admin email id
+admin ph no.

+search healthclub centers()

user +view/update healthclub info() external user
+user id +login()
+user password +view/update FAQ() +view healthclub info()
+user E Id +logout() +view FAQ()
+user contact no +add/remove/update events() +sign up()
+user age +update tarif plan()
+user address +update user info()

+login()
+search healthclub centers()
+view health club info()
+view FAQ()
+log out() user_plan
+reminding password()
+view user info() +membership_type_details
+update user info() +annual_subscription
performs to: +monthly_subscription
performs to: +terms and conditions
+fair
+update_user_plan_info()
performs to: +remove_user_plan_info()
+performs to:
database
+connection
registration info
club_details
+check_connection()
+performs to: card_validation +member_details
+club_name +start_connection()
performs to: +card_issue
+club_phone +end_connection() performs to: +card_no +card_validation
+other_club_details +database_update() +card_issue_date +membership_type_plan
+address_details +card_validation_date +payment
+membership_type_details +club_details
+update_club_info()
+remove_club_info() +member_id_issue
+update_club_info()
+remove_club_info()

Class Diagram
 System
signup
<<include>>

<<include>>
login
<<include>>
view profile
<<include>>

<<include>>
view healthclub info
<<include>>
user
<<include>>
change password

update user info

<<include>>
check validation

view FAQ

paymenat

pay through card pay through cash

logout

add/remove/modify club info

add/remove/modify member records

<<include>>
admin
update validation <<include>>
login by admin
<<include>>

modify the membership plan <<include>>

Use case Diagram

 adminlogin admin login checking admin record user info logout

1 : login()
2 : match()
3 : update/view user info()
4

5 [duplicate] : show error()

register user boundary register user control user register user record user record

1 : register()
2 : check duplicate()
3 : match()

4 [duplicate] : show error()

5 [duplicate] : show error()

8 : register() 9 : create()
7 : display user info()

Sequence Diagram
 registration section Account Section card issue section registration validity section visiting section last section

sign up

receive fee

card issued
login

check customer record and validation

visit date

visitor in time visitor out time

Activity Diagram
email
id phone

payment time region

mem_type

[club] [members]
visit

date
issued

[card]

valid till date

Database Diagram
Assumptions

The Database diagram is based on the assumption that the Member_id

of the Member must be a unique number and used as PRIMARY KEY for
all Database operations.

Error Handling Strategy

1. In case if wrong username and password is entered, control returns to
the main menu.

2. If data of wrong data type is being entered, system doesn’t accept it

and returns data type error.

3. If data exceeding field length is being entered, system doesn’t accept

it and returns field length error.