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 ofBachelor 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 attributes4.0 High Level Design Overview4.1 Application overview4.2 Operational Concepts and Scenario5.0 Detailed Design5.1 Sequence Diagram5.2 Class Diagram5.3 Use Case Diagram5.4 Activity Diagram5.5 Database Diagram6.0 Assumptions6.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 DesignIt 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.

user

+user id+user password+user E Id+user contact no+user age+user address

+login()+search healthclub centers()+view health club info()+view FAQ()+log out()+reminding password()+view user info()+update user info()

admin

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

+search healthclub centers()+view/update healthclub info()+login()+view/update FAQ()+logout()+add/remove/update events()+update tarif plan()+update user info()

external user

+view healthclub info()+view FAQ()+sign up()

club_details

+club_name+club_phone+other_club_details+address_details

+update_club_info()+remove_club_info()

database

+connection

+check_connection()+start_connection()+end_connection()+database_update()

card_validation

+card_no+card_issue_date+card_validation_date+membership_type_details

+update_club_info()+remove_club_info()

user_plan

+membership_type_details+annual_subscription+monthly_subscription+terms and conditions+fair

+update_user_plan_info()+remove_user_plan_info()

registration info

+member_details+card_issue+card_validation+membership_type_plan+payment+club_details+member_id_issue

performs to:

performs to:

+performs to:

performs to:performs to:

performs to:

+performs to:

Class Diagram

System

user

admin

signup

login

view profile

view healthclub info

change password

update user info

check validation

view FAQ

paymenat

<<include>>

pay through card pay through cash

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

<<include>>

logout

add/ remove/ modify club info

add/ remove/ modify member records

update validation

modify the membership plan

login by admin

<<include>>

<<include>>

<<include>>

<<include>>

<<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()

6

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

Sequence Diagram

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

sign up

receive fee

card issuedlogin

check customer record and validation

visit date

visitor in time visitor out time

Activity Diagram

[club]

payment

date

time

[members]visit

issued

region

id

email

phone

mem_type

[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 Strategy1. 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.