Gym Club Management System For Bahir Dar

Bahir Dar University
Bahir Dar Institute of Technology

Faculty of Computing
Industrial project on
Gym club management System for Bahir Dar Gym
Submitted to the faculty of computing in partial fulfilment of
the requirements for the degree of Bachelor of Science in
computer science
Group members
Name ID No
1. Getaneh Alehegn 0602049
2. Minichil Assefa 0602111
3. Selam Ayalew 0602142
Advisor ፡ Derejaw Lake
January 29, 2009

Bahir Dar, Ethiopia
BAHIR DAR GYM club management February 5, 2017
system
Declaration
The Project is our own and has not been presented for a degree in any other university and all
the sources of material used for the project have been duly acknowledged.
Name Signature
Getaneh Alehegn -----------------------------------------------
Minichil Assefa -----------------------------------------------
Selam Ayalew ------------------------------------------------
Faculty: Computing
Program: degree of Bachelor of Science in computer science program
Project Title: Gym club management System for Bahir Dar Gym
This is to certify that I have read this project and that in my opinion it is fully adequate, in
scope and quality, as a project for the degree of Bachelor of Science.
Name of Advisor Signature
Examining committee members signature Date
1. Examiner 1
2. Examiner 2
It is approved that this project has been written in compliance with the formatting rules laid
down by the faculty.
PROJE I
system
Acknowledgment
We wish to express our sincere gratitude to project advisor, Mr. Derejaw Lake. For his
guidance, continuous support and encouragement throughout the completion of this
final year project. We would also like to convey my heartfelt appreciation to Mr.
Derejaw Lake. For contributing his ideas and in-depth knowledge in the field.
A warm thank is extended to BDU lecturers for sharing their resources, opinions,
knowledge, experience and skills in programming and development methodology, so
generously. We would also like to thank our family, friends in BDU and our fellow
class- mates who have one way or another extended their assistance in completing this
project.
Lastly, we wish to acknowledge the good support shown by all lectures who teach before.
PROJE I
system
Table of Contents
Declaration............................................................................................................................................ii
Acknowledgment..................................................................................................................................iii
List of figures.........................................................................................................................................vi
List of Tables........................................................................................................................................vii
List of acronyms.................................................................................................................................viii
Abstract.................................................................................................................................................ix
Chapter one: system planning................................................................................................................1
1. Introduction.......................................................................................................................................1
1.1 Background of the organization...................................................................................................1
1.1.1 Mission..................................................................................................................................1
1.1.2........................................................................................... Vision 1
1.2 Existing System...........................................................................................................................2
1.2.1 Statement of the problem.......................................................................................................2
1.3 Proposed System..........................................................................................................................3
1.4 Objectives of the Project..............................................................................................................3
1.4.1 General Objectives.................................................................................................................3
1.4.2............................................................................. Specific Objectives 3

1.5 Scope of the project.....................................................................................................................4
1.6 Methodology of the project..........................................................................................................5
1.6.1......................................................................... Data collection method 5
1.6.2.................................................................................. Approach used 6
1.6.3.................................................................... System Development Tools 6

1.7 Significance of the Project...........................................................................................................7
1.8 Organization of the Project..........................................................................................................8
Chapter Two: System features...........................................................................................................9
2. Introduction.......................................................................................................................................9
2.1 Existing System Description........................................................................................................9
2.2 Proposed System Description....................................................................................................11
2.3 Functional Requirements...........................................................................................................13
2.4 Non Functional Requirements...................................................................................................15
2.5 Analysis Models........................................................................................................................16
2.5.1............................................................................... Use case diagram 16
PROJE I
system
2.5.2 Sequence Diagram..............................................................................................................54
2.5.3............................................................................... Activity Diagram 58
2.5.4...........................................................................Analysis Class Model 65

Chapter Three: System Design............................................................................................................66
3. Introduction.....................................................................................................................................66
3.1 Component diagram...................................................................................................................66
3.2 Deployment Diagram.................................................................................................................67
3.3 Design class model....................................................................................................................68
3.4 Persistent model.........................................................................................................................69
3.5 User Interface Design................................................................................................................70
3.5 Algorithm Design......................................................................................................................74
References...........................................................................................................................................80
Appendices..........................................................................................................................................81
PROJE V
system
List of figures
Figure 2.1 use case diagram for BDR Gym club management system.................................................18
Figure 2.2 Sequence Diagram for login................................................................................................54
Figure 2.3 Sequence Diagram for create account................................................................................55
Figure 2.4 Sequence Diagram for search trainer.................................................................................56
Figure 2.5 Sequence Diagram for Update Trainer...............................................................................57
Figure 2.6 Activity Diagram for login...................................................................................................58
Figure 2.7 Activity Diagram for change password...............................................................................59
Figure 2.8 Activity Diagram for add trainer.........................................................................................60
Figure 2.9 Activity Diagram for edit trainer.........................................................................................61
Figure 2.10 Activity Diagram for view trainer......................................................................................62
Figure 2.11 Activity Diagram for delete trainer...................................................................................63
Figure 2.12 Activity Diagram for generate report................................................................................64
Figure 2.13 Analysis level class diagram..............................................................................................65
Figure 3. 1 Component Diagram.........................................................................................................66

Figure 3. 2 deployment diagram.........................................................................................................67
Figure 3. 3 design class Modelling......................................................................................................68
Figure 3. 4 Persistent Model...............................................................................................................69
Figure 3. 5 User interface for create account.....................................................................................70
Figure 3. 6 User interface for home page...........................................................................................71
Figure 3. 7 User interface for login.....................................................................................................71
Figure 3. 8 User interface for add payment........................................................................................72
Figure 3. 9 User interface for view trainer..........................................................................................73
PROJE V
system
List of Tables
Table 1.1 Interview Information............................................................................................................5
Table 1.2 Tools used for the project......................................................................................................6
Table 2.1 use case description for create account...............................................................................19

Table 2.2 use case description for login...............................................................................................20
Table 2.3 use case description for change password...........................................................................21
Table 2.4 use case description for add trainer.....................................................................................22
Table 2.5 use case description for edit trainer.....................................................................................23
Table 2.6 use case description for delete trainer.................................................................................24
Table 2.7 use case description for view trainer...................................................................................25
Table 2.8 use case description for add plan.........................................................................................26
Table 2.9 use case description for view plan.......................................................................................27
Table 2.10 use case description for edit plan......................................................................................28
Table 2.11 use case description for delete plan...................................................................................29
Table 2.12 use case description for add payment...............................................................................30
Table 2.13 use case description for view payment..............................................................................31
Table 2.14 use case description for edit payment...............................................................................32
Table 2.15 use case description for delete payment...........................................................................33
Table 2.16 use case description for membership overview.................................................................34
Table 2.17 use case description for view notification..........................................................................35
Table 2.18 use case description for view report..................................................................................36
Table 2.19 use case description for add equipment............................................................................37
Table 2.20 use case description for view equipment...........................................................................38
Table 2.21 use case description for edit equipment............................................................................39
Table 2.22 use case description for delete equipment........................................................................40
Table 2.23 use case description for print invoice.................................................................................41
Table 2.24 use case description for add health...................................................................................42
Table 2.25 use case description for view health..................................................................................43
Table 2.26 use case description for edit health...................................................................................44
Table 2.27 use case description for delete health...............................................................................45
Table 2.28 use case description for log details....................................................................................46
Table 2.29 use case description for view comment.............................................................................47
Table 2.30 use case description for generate report...........................................................................48
Table 2.31 use case description for add schedule...............................................................................49
Table 2.32 use case description for view schedule..............................................................................50
Table 2.33 use case description for edit schedule...............................................................................51
Table 2.34 use case description for delete schedule...........................................................................52
Table 2.35 use case description for prepare resource.........................................................................53
PROJE V
system
List of acronyms
Admin: System Administrator
BDR: BAHIR DAR
BDU: Bahir Dar University
GYM: Gymnasium
GCMS: Gym Club Management System
UC: use case
SQL: Structured query language
MYSQL: MY Structured language
UML: Unified modelling language
BR: Business rule
PHP: Hypertext Preprocessor
CSS: Cascading style sheet
HTML: Hyper Text Markup Language
HTTP:Hyper Text transfer protocol
ODBC: Open Database Connectivity
AJAX: Asynchronous JavaScript and XML
PROJE V
system
Abstract
The main purpose to develop this project is in partial fulfillment of the requirement for
Bachelor of Science. Besides that, is to help the BDR GYM club Center to reduce their overload
paperwork. BDR GYM club management System mainly consists of the following modules
which are login Module, Trainer Module, notification Module, Payment Module, schedule
Module, Report Module, and Logout Module. We were using the Object Oriented Approach
to design our system. We was draw out some the diagram such as class diagram, deployment
diagram, activity diagram and sequence diagram in order to help us have the better idea when
develop the system. The tools we are using to develop our system are umlet, Rapid php
editor 2016 and MS word 2013.During the system development, Mr. Derejaw give us some
suggestion in the designing system. First of all, we come out a proposal with the propose
system that we want to develop. Then we find the advisor that who accepts our proposal and
guide us for the final year project. After that, we come out the project specification. Which
include the company background, business rules, organization structure, project objective,
project scopes and project schedules. After we done all the initial plan and analysis, then we
start to design the UML diagram such as class diagram, deployment diagram, activity
diagram and sequence diagram. The project overall is consider fulfill the requirement and
can deliver the system on time. The strength of the system is the interface is standardize,
minimizes the user input and validation checking for the user input. Through the project, we
have learned that time management is important. If do not have the good time management,
it will affect the quality of the project. Besides that, team work and communication also
consider as important. Two person works is better than one person work.
PROJE I
BAHIR DAR GYM club management February 5,
Chapter one: system planning

1. Introduction
Bahir Dar Gym Club Management System is to provide a system which handles the
information of the people coming into the gym and maintaining their health care. It takes care
of all their health information. Data will be stored in the database. It also maintains the
people’s health information, gym records. The System to be produced is on Gym Club
Management System. Here there are 6 users. They are The Admin, Manager, Trainer, and the
cashier, gym instructor, and store clerk. Cashier can add the details of a person who wish to
join the gym. Their personal information including weight, height and phone number are
collected. The instructor also provides timings for that person, when he can come to the gym.
The store clerk can note down the gym equipment he wishes to join. Admin has more
authority than the other users. He provides unique username and password for the users. He
also has the right to delete or modify the users account and log details.
1.1 Background of the organization

BDR GYM is one of the GYM Club in BahirDar which was established in the year 1998 E.C.
BDR GYM is located inside Dagim Yohaness Garden, in BahirDar town which is 100m far
from Addis Amba Hotel. BDR GYM is private organization and owned by Miss.Worku.it
contains permanently 9 employees and on average 35-40 trainers in the GYM. Besides, BDR
GYM will also provide some special services, such as aerobics sport service, shower and
dressing room services.
1.1.1 Mission
BDR GYM is with a mission to improve the health and well-being of its trainers and the
community by providing health and fitness services through assessment, education, and
exercise in a supportive situation.
1.1.2 Vision
Our vision is to be the premier medically-based health and wellness facility providing
advanced, collaborative programming centered on the whole-health and well-being of our
community and our region. We will be known for an exceptional trainer experience, with the
highest quality fitness services.
PROJE 1
1.2 Existing System
The current system that the BDR GYM uses is mostly manual system. They don’t use
Database to keep track the trainer record. The staff was feeling stress by the constantly
growing workload. Furthermore, the manual system waste a lot of paperwork cost and
it also waste the storage space problem because they need to have a space to store all
the record.
1.2.1 Statement of the problem
The problem occurred in the current system are of the following:
 File lost: When computerized system is not implemented file is always lost because of
human environment. Sometimes due to some human error there may be a loss of
records.
 File damaged: When a computerized system is not there file is always lost due to
some accident like spilling of water by some trainer file accidentally. Besides some
natural disaster like floods or fires may also damage the files.
 Difficult to search record: When there is no computerized system there is always a
difficulty in searching of records if the records are large in number.
 Space consuming: After the number of records becomes large the space for physical
storage of file and records also increases if no computerized system is implemented.
 Cost consuming: As there is no computerized system to add each record paper will be
needed which will increase the cost for the management of GYM Club.
 Error during payments
 Data redundancy
 No direct role for higher officials
PROJE 2
1.3 Proposed System

The proposed GYM club management system helps us to:
 To help the organization to reduce the overload paperwork
 To reduce the storage space problem of keeping the trainer records.
 To update record quick and easily because all the system are computerized
 Minimize the human mistake and error because do not need the manual record
 Speed out the joining and leaving process for trainer
 Reduce the administrative costs because we no need to hire more staffs.
 Can maintain the trainer history easily.
 Can save the printing and distributing paper based manuals.
 Can avoid redundancy of data.
 Administrator controls the entire system.
1.4 Objectives of the Project

The general and specific objectives of the project are described below.
1.4.1 General Objectives

General objective of the project is to develop the web based GCMS for BDR GYM.
1.4.2 Specific Objectives

In order to reach the general objective, the following list of specific objectives is set:
 Gather requirements continuously for the system
 Study the existing system and find out the problem.
 Find the solution for the problem found in existing system.
 Identify functional and non-functional requirements for the new system
 Analyse and design the system documentation with detailed UML specifications
 Implement and test the system.
 deploying the system
PROJE 3
1.5 Scope of the project

The proposed system is designed only for Bahir Dar Gym and it didn’t cover the whole Gym
club management system because of time constraint. BDR Gym Club Management System is
an easy-to-use gym club management system. It allows the user to store the wellness,
schedule, the details person who is in the gym, gym equipment details etc. BDR Gym Club
Management System allows storing all the details related to gym and managing payment,
schedule, trainer information, log details, and equipment’s. The accomplishment of the
system in the organization will considerably reduce details entry, time and also offer readily
measured reports.
Modules included in our project:

 Plan Module
 Account module
 Trainer Module
 Payment Module
 Log module
 Equipment Module
 Schedule Module
 Notification Module
 Health status Module
 Report Module
Modules excluded in our project:

 Trainer attendance module
 Shopping cart Module
 Staff module
PROJE 4
1.6 Methodology of the project

In this section we shall include data collection methods, approaches and system development
tools.
1.6.1 Data collection method

A fact gathering study was under taken to study the activities involved in the various aspect of
the existing system. We had visited various stakeholders of the company.
The existing system was studied by means of:
i. Background Reading
It’s a process to gain more understanding about our system such as organization
background, objective, and soon. By gaining the understanding of their organization such as
organization policy and organization rules, it eases develop to building up the business rules
when designing the database and coding. Through reading, we understanding all their
business need and also find out that they are actually using manual work for management
currently.
ii. Questionnaire
Since Cashier as well as higher officials of Gym have work load they cannot able to
answer/give information what we ask. So we prepare some sample questions to get précised
information.
iii. Interview
After back ground reading, we also interviewed Mr. Muhabaw Getahun the managers of BDR
GYM. Through the interview we gather all problems that facing by their current management
in order to gain more understanding about the need of the system, we agreed us to
collect information from GYM staff by using questionnaire technique.
Interviewer Getaneh Alehegn

Minichil Assefa
Selam Ayalew
Interviewee: Manager of BDR GYM Mr. Muhabaw Getahun
Time: 07 November 2016 at 10:00 am
Venue: BDR GYM
Table 1.1 Interview Information
PROJE 5
1.6.2 Approach used

The methodology that we used in this project is object oriented approach (OO approach). This
approach combines the data and process together into an entity which is known as objects.
Each of the objects represents some entity in the system being modelled, and it is
characterized by its class, its state (attribute), and its operation (behaviour).OO approach has
cut down the complexity of the system by subdividing the system into smaller pieces of
components like an object and established a well-refined relationship between those objects in
the system. Besides that objects that created before can be reused for another part which will
make the project progress faster. OO approach provides us with a lot of advantages such as
scalable, reusable, and real world modelling.
1.6.3 System Development Tools

We are using many software tools used for analysis, design and implementation. The software
tools used for developing the system are listed below in the table.
Activities Tools
Documentation MS word 2013
Presentation MS PowerPoint 2013
Design Microsoft Visio 2007,Visual paradigm for
UML standard design, and umlet
Editing Paint, Macromedia flash 8,Adobe.Photoshop ,
adobe flash
Script languages PHP, JavaScript, CSS, HTML,ajax, jQuery
Web server Apache Xampp server
Database Server Mysql database
Code editor Rapid PHP 2016
Table 1.2 Tools used for the project
PROJE 6
1.7 Significance of the Project

After this project is finished and properly used it gives great benefit. Some of the significant
that the team has identified are listed out as follows:
 Cost and time saving: Staff can enjoy savings in term of times and costs with
regard to save the administrative cost because the entire document can easily
maintain and the organization not need to employ more people to keep track the
data.
 Reduced redundancy: Data used across several different purposes can lead to
repetition of information and leading to inconsistency and duplicated data. After
develop the system, each data is only be stored once. It can minimize the human
mistake and error because do not need the manual record. So it will reduce the data
redundancy.
 Up-to-date data: After develop this system, it can update record quick and easily
because all the system are computerized. The staffs no need to find out the data
manually and correct it with pen. Staff can directly go to the search button in the
system to find out the particular data and correct it quick.
 Security: In this system, all the data can only be accessible to those authorized to
see it. Only the authorized person have the capability to make changes on the data
under controlled conditions. For example, only the cashier has the authorized to
make changes of the trainer information. And the other staff cannot have the
authorized to view or make changes on other trainer or staff information.
 Improve customer service: The system saves times and help organization to
provide the best way to serve the customer.
The beneficiaries of the system are:

Trainers: the trainers can view their history and membership information, view
schedule, make payment by just scanning QR code, view equipment , download
resources easily and timely.
Cashier and other administrative officials: they can access System and related
information easily.
BDR GYM: the GYM gets better audience and saves costs and time
PROJE 7
1.8 Organization of the Project

The project document is divided into three chapters for better understanding. Chapter one
focuses on introductory part as we have seen above. Chapter two of the document is all about
the features of the system including description of existing and proposed system, the analysis
models like sequence diagram, analysis level class diagram and activity diagram,
requirements like functional and non-functional requirements and use cases diagrams. In
chapter three, on this chapter we discussed what the system should look the deployment,
Component, User interface, Design level class diagram, and algorithm design.
PROJE 8
Chapter Two: System features

2. Introduction
In this chapter we will see about the features of the system like, existing system
description, proposed system description, functional requirement, no-functional
requirement and analysis model.
2.1 Existing System Description
An Existing system refers to the system that is being followed now. Presently all the
Functionalities are done manually. This is making the person very difficult to keep
track of the user and the trainers. In the existing BAHIR DAR club GYM
management system the following services are given to the users and In order to get
this services the Cashier, Manager, trainer, or administrative Staff should do the
following activities.
User of the system
 User comes to the gym and obtain the gym rules and procedures including the time
and days open and closed
 After the user knows about the rules and provided payments the user pays the payment
 The user is a trainer of the gym until his membership expiration date is reached.
 The user searches the free equipment’s in the gym and use that gym equipment in his
need until the gym closing time
 User of the system obtain membership card after pays the payment
 The membership card is expires based on the membership type
 There are 4 types of the membership types the one is for one days and the amounts
to be payed is 35 birr, the second is for 12 days and the amounts to be payed is 260
birr, the third is for 45 days and the amount to be payed is 600 birr, the last is for 90
days the amounts to be payed is 900 birr.
 The user is not be able to use the system if his membership expires.
Cashier of the system
 The cashier of the gym registers the new coming trainer by give explanation about
some rules and procedures.
 Make payments by take the amounts payed by users
PROJE 9
 The cashier record the starting date and ending date of trainer while make the
payment
 The cashier opens the gym in opening time and closes in closing time and also tells
to trainer the opening and closing time.
 The cashier give membership card to trainer after make the payment
 The Cashier Can register, and view trainer information
 The cashier of the gym describe to trainers the gym equipment’s available in the gym
and his procedures to use
Manager of the system
 The manager of the gym manages the whole system

 The manager of the gym manages(add,edit,delete,view ) the gym equipment’s
 Make manage plan (the plan is the description of the membership type and amounts
to be payed for each membership type ) by communicating with owner
Business Rules in the existing system

A business rule is effectively an operating principle or polices that must be fulfilled and
obligated in order the system will function properly and effectively. It often pertain to access
control issues, business calculations, or operating polices and principles of the organization.
 BR1: Only 20 minutes is allowed to use walking truck machines.
 BR2: payments are not transferred to others.
 BR3: Only payed trainers are be able to enter to the gym and use the system services.
 BR4: Each payment can only make one payment for the membership and each
membership payment can only be making by one trainer.
 BR5: Each trainer has their own locker. One locker is belong to one trainer
 BR6: The Trainers needs to register before join our gym club.
 BR7: One trainer only can have one record.
PROJE 1
2.2 Proposed System Description

Bahir Dar Gym club management system is user-friendly application and very simple to
use. In the proposed system it is considers there should be an administrator who controls
and manage the overall activities of the system and there are users who are going to use the
proposed system so that, the following are description of the proposed system.
The proposed system enables the following to be done by the administrator.
 First of all the administrator must Login in to the system with his / her own username
and password.
 Manage account of the system (which includes create account, delete account, edit
account, view account information).
 Manage user and activity log which includes whose user is logged in, when the user
is logged in, when user logged out and what activities are performed by user when
logged in.
The proposed system enables the following tasks to be done by the Manager.
 First of all the Manager must Login in to the system with his / her own username and
password.
 View trainer overview information
 Manage membership plans
 View Trainer plan expiry and records position.
 View notification or alerts
The proposed system enables the following tasks to be done by the Cashier.
 First of all the Cashier must Login in to the system with his / her own username and
password.
 Make Payment and Due Collection and generate invoice
 Get users profile by Photo catch
 Manage payment details
 Manage trainer information
 Manage trainer health status
The proposed system enables the following tasks to be done by the Trainer.
PROJE 1
 First of all the trainer must Login in to the system with his / her own username and
password.
 Make Payment
 View Trainer plan expiry and records position.
 View schedule and their own payment details
The proposed system enables the following tasks to be done by the Store clerk.
 Manage equipment information it includes add new equipment, delete inappropriate

equipment, edit equipment, and view equipment.
The proposed system enables the following tasks to be done by the gym instructor.
 Manage schedule it includes add exercise details of trainer, date, and time.
 Prepare the required resources
 Guiding trainers
Merits of Proposed System

 Security of data
 Ensure data accuracy
 Avoid data redundancy
 Avoid human mistakes or error
 Administrator controls the entire system
 Reduce the wastage of the resources
 Minimize manual data entry
 Greater efficiency
 User friendly and interactive user interface
 Saves lot of time
 Retrieval and Updating tasks can be performed much faster and easier
PROJE 1
2.3 Functional Requirements
1. Trainer module
1.1 The system will allow the cashier to view the particular trainer detail by
using the search criteria that are provided which is trainer ID, or trainer name
in the trainer detail form.
1.2 The system will allow the cashier to view all the trainer details.
1.3 The system will allow the cashier to add trainer detail
1.4 The system will allow the cashier to edit the trainer information.
1.5 The system will allow the cashier to cancel trainer information when the
trainer resign or expired.
2. Report module
2.1 The system will allow the manager to view the monthly, weekly, and daily report.
 Manager need to select the month that he or she wants to view report.
For trainer report, manager needs to select the month and trainer type
when he or she wants to view the report.
2.2 The system will allow the cashier to generate report.
3. Login module
3.1 The system will allow the Users to log into the system with their own account.
 After login in the system, the system will access relevant data to user
based on their username and password.
 The login module also allows the user to change to password for the
security purpose.
4. Account module
4.1 The system will allow the Administrators to create account for users
4.2 The system will allow the administrator to delete account of users
4.3 The system will allow the administrator to activate users account
4.4 The system will allow the administrator to deactivate user account
5. Equipment module
PROJE 1
5.1 The system will allow the store clerk to add equipment details.
5.2 The system will allow the store clerk to edit equipment details.
5.3 The system will allow the store clerk to delete equipment details.
5.4 The system will allow the store clerk to view equipment details.
5.5 The system will allow the trainer to view equipment details.
5.6 The system will allow the cashier to view equipment details.
5.7 The system will allow the gym Instructor to view equipment details.
6. Health_status module
6.1 The system will allow the cashier to add Health_status of trainer
6.2 The system will allow the cashier to edit Health_status of trainer
6.3 The system will allow the cashier to delete Health_status of trainer
6.4 The system will allow the cashier to view Health_status of trainer
7. Schedule module
7.1 The system will allow the gym Instructor to add schedule or detail exercises of the
trainer
7.2 The system will allow the gym Instructor to edit schedule or detail exercises of
the trainer
7.3 The system will allow the gym Instructor to delete schedule or detail exercises of
the trainer
7.4 The system will allow the gym Instructor to view schedule or detail exercises of
the trainer
8. Plan/membership type module
8.1 The system will allow the Manager to add new plan details the plan details
consists membership ID, membership name , days , and Rates .
8.2 The system will allow the Manager to edit plan details.
8.3 The system will allow the Manager to delete plan details.
8.4 The system will allow the Manager to view plan details.
9. Payment module
9.1 The system will allow the Cashier to add trainer payment
9.2 The system will allow the cashier to edit trainer payment
9.3 The system will allow the Cashier to delete trainer payment
9.4 The system will allow the Cashier to view trainer payment
9.5 The system will allow the Trainer to make their own payment by scanning QR code
9.6 The system will allow the Trainer to view their own balance
PROJE 1
10. Notification module

10.1 The system will allow the Manager to view ending membership details
10.2 The system will allow the manager to view unpaid trainer details
11. Log module
11.1 The system will allow the Administrator to manage user log
11.2 The system will allow the Administrator to manage activity log
12. Logout module
10.1 The system will allow the User of the system to logged out of the system
2.4 Non Functional Requirements

Non-Functional requirements are often associated with the quality of the system and not with
the functionality that the system has to offer. The overall qualities of the system such as
usability, maintainability, modifiability, portability, reusability, and security.
Security: In this system, all the data can only be accessible to those authorized to see it.
Only the authorized people have the capability to make changes on the data under
controlled conditions. The system provides username and password to prevent the system
from unauthorized access. The system shall authenticate server side users. Passwords should
be stored in encrypted form.
Reliability: The system should be reliable in providing expected output and able to perform
its required functions under stated conditions for a specified period of time.
Availability: The system should always be available for access with connected network and
power source.
Portability: The system should run in every Windows, Mac and Linux operating system. The
system should run on every version of web browsers. The system should run in every server
and client computer.
Usability: The system provides a help and support menu in all interfaces for the user to
interact with the system.
PROJE 1
2.5 Analysis Models

Different kinds of UML diagrams are used to model the functionality, structure and sequence
of activities of the system. Here are the sets of system modelling.
 Functionality description of the system by using use case diagram

 Sequence of activities of the system by using sequence diagrams
 The flow of activities between different tasks are modeled using activity diagram
 Relationship between class are modeled using class diagram
2.5.1 Use case diagram

A use case diagram describes how a system interacts with outside actors. It is a graphical
representation of the interaction among the elements and system. Each use case representation
a piece of functionality that a system provides to its user. Use case identifies the functionality
of a system.
Use case components:
 Actor: is a person, or external system that plays a role in one or more interaction with
the system. And represented with:
 Use case: describes a sequence of actions that provides something of measurable value
to an actor and is drawn as a horizontal ellipse.
 System boundary: indicates the scope of the system project. Anything within the box
represent functionalities in side in scope.
Actor identification
In the use cases an actor interact with the system to perform a piece of meaningful work that
helps them to achieve a goal and has access to define their overall role in the system and the
scope of their action. Depending on the above explanation actors in this system are the
following:
 Administrator: The administrator manages the overall system.
PROJE 1
 Trainer: The trainer view payment, expiry, schedule, and equipment information
online and make payment.
 Manager: The manager view notification, trainer overview, expiry, and report and also
manages plan and schedule.
 Cashier: manage health status, trainer, and payment details of trainers.
 Store clerk: The store clerk manages the equipment of system.
 Gym instructor: manage schedule, prepare/upload resources, and instructing trainers.
Use case identification
Each Use Case describes the functionality to be built in the proposed system, which can
include another Use Case's functionality or extend another Use Case with its own behavior.
The most important and basic use cases of this system are the following:-
 Login
 Manage log details
 Manage account
 View notification or alerts
 View comment
 Generate report
 Manage plan
 Manage payment
 Manage trainer
 Manage schedule
 Mange equipment
 View report
 Prepare resources
 Download resources
 Instructing trainers
 Logout
PROJE 1
Use case diagram of BDR gym club management system
Figure 2.1 use case diagram for BDR Gym club management system
PROJE 1
2.5.1.1 Use Case Description
Use Case Description for create account
Use case name Create Account

Use case ID UC-01
Description Used to create account for users of the system to login to the
system.
Actor Admin
Pre- condition: Admin should be fill the required form details Users
1) The admin selects create account link.
Basic course of action 2) The system displays create account page.
3) The admin fills the required information and submits it.
4) The system validates the information.
5) The system registers the users into the database and display
a message successfully register thank you.
6) The use case ends.
Post- condition The account is successfully created.
Alternative course of action If the information admin fill is invalid information. The system
displays the particular error message. The go to step2
Table 2.1 use case description for create account
PROJE 1
Use Case Description for login
Use case name Login

Use case ID UC-02
Description User need to login to the system in order to perform the tasks.
Actor Admin,Manager,Cashier,trainer, store clerk ,and gym_instructor
Pre- condition: User should have an account to log in to the system
1. The user click login link

Basic course of action 2. System display Login screen
3. User enter username and password
4. System verify username and password
5. System display main menu
6. Use case ends
Post- condition The User is successfully Log in into the system.
Alternative course of action

A1 step S3: If the Username and Password that entered by
user are not match with the database, system will display
invalid username and password message and require the user
to key in again.
Table 2.2 use case description for login
PROJE 2
Use Case Description for change password
Use case name Change Password
Use case ID UC-03
Description This use case is to allow the User to change the password.
Actor Admin, Manager , Cashier ,trainer ,store clerk , and gym instructor
Pre- condition: User should have an existing account to change password

1. System display login screen
Basic course of action 2. User click change password link
3. System display change password form
4. User enter username and existing password
5. User enter new password
6. System verify username and password
7. System change password successfully
8. Use case ends
Post- condition The User’s password is successfully changed.
Alternative course of
A1 step S6: If the Username and Password that entered by user are
action
not match with the database, system will display invalid username
and password message and require the user to key in again.
A2 step S6: If the Username and Password that entered by user are
match with the database, but the new password is invalid, ask user
re-enter the new password.
Table 2.3 use case description for change password
PROJE 2
Use Case Description for add trainer
Use case name Add Trainer

Use case ID UC-04
Description This use case is to allow the User to add trainer or new user.
Actor Cashier
Pre- condition: User should be login in to the system to add trainer
1. User selects add trainer link

Basic course of action 2. System display add new trainer form
3. The user enters the details of the trainer
4. The user click add trainer button
5. System will verify the data that the actor enters
6. System add trainer successfully and updates the database
7. Use case ends
Post- condition The new Trainer of the system is added successfully
A1 step S3: If one of the data entered by User is invalid data,
action
system will display invalid data message.
Table 2.4 use case description for add trainer
PROJE 2
Use Case Description for edit trainer
Use case name Edit Trainer
Use case ID UC-05
Description This use case is to allow the User to edit trainer information.
Actor Cashier
Pre- condition: User should be login in to the system to edit trainer
1. User selects edit trainer link

Basic course of action 2. System display edit trainer form with a particular trainer detail
3. The user edit some details of the trainer
4. The user click edit trainer button
5. System will verify the data that the User enters
6. System edit trainer successfully and updates the database
7. Use case ends
Post- condition The Trainer information is edited successfully
action
Table 2.5 use case description for edit trainer
PROJE 2
Use Case Description for delete trainer
Use case name Delete Trainer
Use case ID UC-06

Description This use case is to allow the User to delete trainer information.
Actor Cashier
Pre- condition: User should be login in to the system to delete trainer
1. User selects delete trainer link

Basic course of action 2. System display delete trainer form with a particular trainer detail
3. The user click delete trainer button
4. System will ask the confirmation from user to delete
5. User click on conformation to delete trainer
6. System delete trainer successfully and updates the database
7. Use case ends
Post- condition The Trainer information is deleted successfully
A1 step S5: If the user will click No on confirmation the trainer
action
details or information is not deleted.
Table 2.6 use case description for delete trainer
PROJE 2
Use Case Description for view trainer
Use case name View Trainer

Use case ID UC-07
Description This use case is to allow the User to View trainer information.
Actor Trainer, cashier
Pre- condition: User should be login in to the system to view trainer
1. User selects view trainer link

Basic course of action 2. System display view trainer form to user for viewing particular
trainer detail or all the trainer
3. The user enter trainer ID, or Name or select view all
4. System will verify the ID, or Name that the user enters
5. System display trainer details
6. Use case ends
Post- condition The Trainer information is displayed in the screen
A1 step S3: If the user enter invalid ID, or Name the system
action
prompt out message for invalid ID, or Name.
Table 2.7 use case description for view trainer
PROJE 2
Use Case Description for add new plan details
Use case name Add Plan
Use case ID UC-08
Description This use case is to allow the Manager to add new plan.
Actor Manager
Pre- condition: Manager should be login in to the system to add new plan (plan
includes membership type ,amounts to pay, number of days to attain and
so on)
1. Manager selects add trainer link
Basic course of action 2. System display add new plan form for Manager
3. The Manager enters the details of the plan
4. The Manager click add new plan button
5. System will verify the data that the Manager enters
6. System add plan successfully and updates the database
7. Use case ends
Post- condition The new plan is added successfully
A1 step S3: If one of the data entered by Manager is invalid data,
action
Table 2.8 use case description for add plan
PROJE 2
Use Case Description for view plan
Use case name View Plan
Use case ID UC-09
Description This use case is to allow the User to view plan details.
Actor Manager
Pre- condition: Manager should be login in to the system to view plan details(plan
so on)
1. Manager selects view plan link
Basic course of action 2. System display view plan form
3. The Manager enters the Plan ID, Name or select view all.
4. The Manager click view plan button
5. System will verify the ID or Name that the Manager enters
6. System Displays the plan details
7. Use case ends
Post- condition The plan detail is displayed successfully
A1 step S3: If one of the ID or Name entered by Manager is
action
invalid data, system will display invalid data message.
Table 2.9 use case description for view plan
PROJE 2
Use Case Description for edit plan
Use case name Edit Plan
Use case ID UC-10
Description This use case is to allow the Manager to edit plan details.
Actor Manager
Pre- condition: Manager should be login in to the system to edit plan details(plan
so on)
1. Manager selects edit plan link
Basic course of action 2. System display edit plan form with a particular plan detail
3. The Manager edit some details of the plan
4. The Manager click edit plan button
5. System will verify the data that the Manager enters
6. System edit plan successfully and updates the database
7. Use case ends
Post- condition The plan detail is edited successfully
A1 step S3: If one of the data entered by Manager is invalid data,
action
Table 2.10 use case description for edit plan
PROJE 2
Use Case Description for delete plan
Use case name Delete Plan

Use case ID UC-11
Description This use case is to allow the Manager to delete plan details.
Actor Manager
Pre- condition: Manager should be login in to the system to delete plan details(plan
so on)
1. Manager selects delete plan link
Basic course of action 2. System display delete plan form with a particular plan detail
3. The Manager click delete plan button in plan detail form
4. System will ask for confirmation from manager
5. Manager will click on confirmation for delete the plan details
6. System delete plan successfully and updates the database
7. Use case ends
Post- condition The plan detail is deleted successfully
A1 step S5: If the manager click No on confirmation for delete
action
the plan details is not deleted.
Table 2.11 use case description for delete plan
PROJE 2
Use Case Description for add payment
Use case name Add payment
Use case ID UC-12

Description This use case is to allow the User to add payment.
Actor Cashier, trainer
Pre- condition: User should be login in to the system to add payment details
1. User selects add payment link

Basic course of action 2. System display add payment form to User
3. The User enters the details of the payment
4. The User click add payment button
6. System payment successfully and updates the database
7. Use case ends
Post- condition The payment is added successfully
action
Table 2.12 use case description for add payment
PROJE 3
Use Case Description for view payment
Use case name View Payment
Use case ID UC-13
Description This use case is to allow the User to view payment details.
Actor Cashier, trainer ,manager
Pre- condition: User should be login in to the system to view payment details
1. Cashier selects view payment link

Basic course of action 2. System display view payment form
3. The User enters the payment ID, Name or select view all.
4. The User click view payment button
5. System will verify the ID or Name that the User enters
6. System Displays the payment details
7. Use case ends
Post- condition The payment detail is displayed successfully
A1stepS3: If one of the ID or Name entered by User is invalid
action
data, system will display invalid data message.
Table 2.13 use case description for view payment
PROJE 3
Use Case Description for edit payment details
Use case name Edit payment

Use case ID UC-14
Description This use case is to allow the Cashier to edit payment details.
Actor Cashier
Pre- condition: Manager should be login in to the system to edit payment details
1. Cashier selects edit payment link

Basic course of action 2. System display edit payment form with a particular payment detail
3. The Cashier edit some details of the payment
4. The Cashier click edit payment button
5. System will verify the data that the Cashier enters
6. System edit payment successfully and updates the database
7. Use case ends
Post- condition The payment detail is edited successfully
A1 step S3: If one of the data entered by Cashier is invalid data,
action
Table 2.14 use case description for edit payment
PROJE 3
Use Case Description for delete payment
Use case name Delete payment

Use case ID UC-15
Description This use case is to allow the Cashier to delete payment details.
Actor Cashier
Pre- condition: Cashier should be login in to the system to delete payment details
1. Cashier selects delete payment link

Basic course of action 2. System display delete payment form with a particular payment detail
3. The Cashier click delete payment button in payment detail form
4. System will ask for confirmation from Cashier
5. Cashier will click on confirmation for delete the payment details
6. System delete payment successfully and updates the database
7. Use case ends
Post- condition The payment detail is deleted successfully
A1 step S5: If the Cashier click No on confirmation for delete the
action
payment details is not deleted.
Table 2.15 use case description for delete payment
PROJE 3
Use Case Description for membership overview
Use case name Membership overview
Use case ID UC-16
Description This use case is to allow the Manager to view overview of

membership details.
Actor Manager
Pre- condition: Manager should be login in to the system to view overview of

membership details.
1. Manager selects membership overview link
Basic course of action 2. System display membership overview form
3. The Manager enter the ranges of dates or months that need to
overview details
4. System will display number of trainers, amounts of incomes payed
from trainers in that ranges that the manager enters
5. Use case ends
Post- condition The membership overview is displayed successfully
A1 step S3: If the manager enters invalid date ranges the system
action
prompt out invalid date range.
Table 2.16 use case description for membership overview
PROJE 3
Use Case Description for view alerts or notifications
Use case name View notification /alerts

Use case ID UC-17
Description This use case is to allow the Manager to manage notifications or

alerts of the trainer
Actor Manager
Pre- condition: Manager should be login in to the system to manage notifications or

alerts.
1. Manager selects notification or alert link
Basic course of action 2. System display notification detail menu form
3. The Manager selects notification or alerts that we need
4. System will display unpaid membership details or ending membership
details based on users choice
5. Use case ends
Post- condition The notification or alerts is displayed successfully
A1 step S3: If there is no notification or alert is present nothing is
action
displayed.
Table 2.17 use case description for view notification
PROJE 3
Use Case Description for view Report
Use case name View Report
Use case ID UC-18
Description This use case is to allow the User to view the Report in graphical
representation
Actor Manager
Pre- condition: User should be login in to the system to view report
1. User selects View report link

Basic course of action 2. System display View report form
3. The User select the particular report type
4. System Prompt to enter required fields
5. Manager fill the field and click view
6. System displayed report in pie chart
7. Use case ends
Post- condition The report detail is displayed successfully
A1 step S3: If the manager not select the report type and click
action
view the system prompt to manager please select message
Table 2.18 use case description for view report
PROJE 3
Use Case Description for add equipment
Use case name Add equipment

Use case ID UC-19
Description This use case is to allow the User to add equipment.
Actor Store clerk

Pre- condition: User should be login in to the system to add equipment details
1. User selects add equipment link
Basic course of action 2. System display add equipment form to User
3. The User enters the details of the equipment
4. The User click add new equipment button
6. System add equipment successfully and updates the database
7. Use case ends
Post- condition The new equipment is added successfully
action
Table 2.19 use case description for add equipment
PROJE 3
Use Case Description for view equipment
Use case name View equipment
Use case ID UC-20
Description This use case is to allow the User to view equipment details.
Actor Store clerk, cashier, trainer
Pre- condition: User should be login in to the system to view equipment details
1. Store clerk selects view equipment link

Basic course of action 2. System display view equipment form
3. The User enters the equipment ID, Name or select view all.
4. The User click view equipment button
6. System Displays the equipment details
7. Use case ends
Post- condition The equipment detail is displayed successfully
A1 step S3: If one of the ID or Name entered by User is invalid
action
Table 2.20 use case description for view equipment
PROJE 3
Use Case Description for edit equipment
Use case name Edit equipment

Use case ID UC-21
Description This use case is to allow the Store clerk to edit equipment details.
Actor Store clerk
Pre- condition: Store clerk should be login in to the system to edit equipment details
1. Store clerk selects edit equipment link

Basic course of action 2. System display edit equipment form with a particular
equipment detail
3. The Store clerk edit some details of the equipment
4. The Store clerk click edit equipment button
5. System will verify the data that the Store clerk enters
6. System edit equipment successfully and updates the database
7. Use case ends
Post- condition The equipment detail is edited successfully
A1 step S3: If one of the data entered by Store clerk is
action
Table 2.21 use case description for edit equipment
PROJE 3
Use Case Description for delete equipment
Use case name Delete equipment
Use case ID UC-22
Description This use case is to allow the Store clerk to delete equipment details.
Actor Store clerk

Pre- condition: Store clerk should be login in to the system to delete equipment details
1. Store clerk selects delete equipment link

Basic course of action 2. System display delete equipment form with a particular equipment
detail
3. The Store clerk click delete equipment button in equipment detail
4. System will ask for confirmation from Store clerk
5. Store clerk will click on confirmation for delete the equipment
details
6. System delete equipment successfully and updates the database
7. Use case ends
Post- condition The equipment detail is deleted successfully
A1 step S5: If the Store clerk click No on confirmation for delete
action
the equipment details is not deleted.
Table 2.22 use case description for delete equipment
PROJE 4
Use Case Description for print invoice
Use case name Print invoice

Use case ID UC-23
Description This use case is to allow the User to print subscription details.
Actor Cashier, trainer
Pre- condition: User should be login in to the system to print subscription details
1. User selects make payment link

Basic course of action 2. System display make payment form with a particular
payment detail
3. User enter the payment details
4. The User click make payment button
5. System validate the data that the User enters while make payment
6. System display payment overview based on user input
7. User click print button
8. System print he invoice successfully
Post- condition The payment detail printed successfully

A1 step S3: If the entered data is not valid while make payment the
action
system prompt out the invalid data message.
Table 2.23 use case description for print invoice
PROJE 4
Use Case Description for add health
Use case name Add health
Use case ID UC-24

Description This use case is to allow the User to add health details.
Actor Cashier
Pre- condition: User should be login in to the system to add health details
1. User selects add health link

Basic course of action 2. System display add health form for User
3. The User enters the details of the users health information
4. The User click add health button
6. System add health details successfully and updates the database
7. Use case ends
Post- condition The new health detail is added successfully
action
Table 2.24 use case description for add health
PROJE 4
Use Case Description for view health
Use case name View health

Use case ID UC-25
Description This use case is to allow the User to view health details.
Actor Cashier
Pre- condition: User should be login in to the system to view health details
1. Manager selects view health link

Basic course of action 2. System display view health form
3. The User enters the health ID, Name or select view all.
4. The User click view health button
6. System Displays the health details
7. Use case ends
Post- condition The health detail is displayed successfully
action
Table 2.25 use case description for view health
PROJE 4
Use Case Description for edit health
Use case name Edit health
Use case ID UC-26
Description This use case is to allow the Manager to edit health details.
Actor Cashier
Pre- condition: Cashier should be login in to the system to edit health details
1. Cashier selects edit health link

Basic course of action 2. System display edit health form with a particular health detail
3. The Cashier edit some details of the health
4. The Cashier click edit health button
5. System will verify the data that the Cashier enters
6. System edit health successfully and updates the database
7. Use case ends
Post- condition The health detail is edited successfully
A1 step S3: If one of the data entered by Cashier is invalid data,
action
Table 2.26 use case description for edit health
PROJE 4
Use Case Description for delete health
Use case name Delete health
Use case ID UC-27
Description This use case is to allow the Cashier to delete health details.
Actor Cashier
Pre- condition: Cashier should be login in to the system to delete health details
1. Cashier selects delete health link

Basic course of action 2. System display delete health form with a particular health detail
3. The Cashier click delete health button in health detail form
4. System will ask for confirmation from Cashier
5. Cashier will click on confirmation for delete the health details
6. System delete health successfully and updates the database
7. Use case ends
Post- condition The equipment detail is deleted successfully
A1stepS5: If the Cashier click No on confirmation for delete
action
the health details is not deleted.
Table 2.27 use case description for delete health
PROJE 4
Use Case Description for log details
Use case name Log details
Use case ID UC-28
Description This use case is to allow the Admin to manage user log details.
Actor Admin
Pre- condition: Admin should be login in to the system to manage user log details
1. Admin selects user log link

Basic course of action 2. System display log details menu
3. The Admin click either user log or activity log
4. System process based on the user choice
5. System display user log details or user activity details
6. Use case ends
Post- condition The log detail is managed successfully
A1 step S3: If the Admin is not select their choice to manage
action
log details system prompt out please select your choice
message.
Table 2.28 use case description for log details
PROJE 4
Use case description for View comment
Use case name View comment
Use case ID UC-29
Description This use case is to allow the Admin to view comments or feedback
sent by the visitors of the system
Actor Admin
Pre- condition: Admin should be login in to the system to view comment
1. Admin log to his/her page.

Basic course of action 2. Admin click on click on view comment link.
3. The system reorders the comments according to the time of
delivery.
4. The Admin starts to view the comments.
5. Use case ends
Post- condition The Admin views the submitted comments.
A1 step S1:If the Admin is try to view comments the session
action
is go back to login page and not be able to view comments
Table 2.29 use case description for view comment
PROJE 4
Use case description for generate report
Use case name Generate report
Use case ID UC-30
Description This use case is to allow the Cashier generate timely report.
Actor Cashier
Pre- condition: Cashier should be login in to the system to generate report
1. The cashier must log to his/her page

Basic course of action 2. The cashier select generate report link
3. the system displays the options (criteria)
4. The user selects the criteria from the given options and
clicks On Display button.
5. The system displays the information to the user
6. Use case ends
Post- condition The report will be generated.
Alternative course of A1 step S4:The system displays error message as invalid selection , then Go
action to step1 and continues the next step
Table 2.30 use case description for generate report
PROJE 4
Use case description for add new schedule
Use case name Add schedule
Use case ID UC-31
Description This use case is to allow the gym instructor to add new schedule to
store trainer’s exercises details.
Actor Gym instructor
Pre- condition: User should be login in to the system to add schedule details
1. User selects add schedule link

Basic course of action 2. System display add schedule form for User
3. The User enters the details of the users schedule information
4. The User click add schedule button
6. System add schedule details successfully and updates the database
7. Use case ends
Post- condition The new schedule detail is added successfully
action
Table 2.31 use case description for add schedule
PROJE 4
Use Case Description for view schedule
Use case name View schedule
Use case ID UC-32

Description This use case is to allow the User to view schedule details.
Pre- condition: User should be login in to the system to view schedule details
1. Gym instructor selects view schedule link
Basic course of action 2. System display view schedule form
3. The User enters the schedule ID, Name or select view all.
4. The User click view schedule button
6. System Displays the schedule details
7. Use case ends
Post- condition The schedule detail is displayed successfully
action
Table 2.32 use case description for view schedule
PROJE 5
Use Case Description for edit schedule
Use case name Edit schedule
Use case ID UC-33
Description This use case is to allow the Gym instructor to edit schedule details.
Pre- condition: Gym instructor should be login in to the system to edit schedule details
1. Gym instructor selects edit schedule link

Basic course of action 2. System display edit schedule form with a particular schedule
detail
3. The Gym instructor edit some details of the schedule
4. The Gym instructor click edit schedule button
5. System will verify the data that the Gym instructor enters
6. System edit schedule successfully and updates the database
7. Use case ends
Post- condition The schedule detail is edited successfully
A1 step S3: If one of the data entered by Gym instructor is
action
Table 2.33 use case description for edit schedule
PROJE 5
Use Case Description for delete schedule
Use case name Delete schedule
Use case ID UC-34
Description This use case is to allow the Gym instructor to delete schedule details.
Pre- condition: Gym instructor should be login in to the system to delete schedule details
1. Gym instructor selects delete schedule link

Basic course of action 2. System display delete schedule form with a particular schedule
detail
3. The Gym instructor click delete health button in schedule detail
form
4. System will ask for confirmation from Gym instructor
5. Gym instructor will click on confirmation for delete the schedule
details
6. System delete schedule successfully and updates the database
7. Use case ends
Post- condition The schedule detail is deleted successfully
A1 step S5: If the Gym instructor click No on confirmation
action
for delete the schedule details is not deleted.
Table 2.34 use case description for delete schedule
PROJE 5
Use Case Description for prepare resources

Use case name Prepare resources
Use case ID UC-35
Description This use case is to allow the Gym instructor to prepare and upload
resources such as exercises music instruction guidelines, video
tutorials.
Pre- condition: Gym instructor should be login in to the system to prepare resources to
trainers
1. Gym instructor log into the system
Basic course of action 2. Gym instructor selects prepare resources link
3. System display the resource form detail
4. The Gym instructor select the resources that he/she wants to
prepare.
5. Gym instructor will click on prepare link to prepare and upload
resources.
6. Systems display the prepared resources.
7. Use case ends
Post- condition The resources detail is prepared successfully
A1 step S3: If the Gym instructor not selects the resources
action
prompt the message to select the resources.
Table 2.35 use case description for prepare resource
PROJE 5
2.5.2 Sequence Diagram

Sequence diagrams model the dynamic aspects of a software system. The emphasis is on the
sequence of messages rather than relationship between objects. Sequence diagrams provide
more detail and show the message exchanged among a set of objects over time. Sequence
diagrams are good for showing the behaviour sequences seen by users of a diagram shows
only the sequence of messages not their exact timing. Sequence diagrams can show
concurrent signals. A sequence diagram shows object interactions arranged in time sequence.
Login sequence diagram
Figure 2.2 Sequence Diagram for login
PROJE 5
Create account sequence diagram
Figure 2.3 Sequence Diagram for create account
PROJE 5
Search trainer sequence diagram
Figure 2.4 Sequence Diagram for search trainer
PROJE 5
Update trainer sequence diagram
Figure 2.5 Sequence Diagram for Update Trainer
PROJE 5
2.5.3 Activity Diagram

Activity diagram is basically a flow chart to represent the flow from one activity to another
activity .The activity can be described as an operation of the system. The control flow is
drawn from one operation to another. This flow can be sequential, branched or concurrent.
This distinction is important for a distributed system. Activity diagrams allow you to think
functionally. This diagram is used to model the activities which are nothing but business
requirements. So the diagram has more impact on business understanding rather
implementation details.
Login activity diagram
Figure 2.6 Activity Diagram for login
PROJE 5
Change password activity diagram
Figure 2.7 Activity Diagram for change password
PROJE 5
Add trainer Activity diagram
Figure 2.8 Activity Diagram for add trainer
PROJE 6
Edit trainer Activity diagram
Figure 2.9 Activity Diagram for edit trainer
PROJE 6
View trainer Activity diagram
Figure 2.10 Activity Diagram for view trainer
PROJE 6
Delete trainer Activity diagram
Figure 2.11 Activity Diagram for delete trainer
PROJE 6
Generate report Activity diagram
Figure 2.12 Activity Diagram for generate report
PROJE 6
2.5.4 Analysis Class Model

Class diagram is static model that shows the classes and the relationships among classes that
remain constant over the time. Class is the main building block of class diagram, which stores
and manages information in the system. In the phase of analysis class modelling we just
create classes with their attributes, methods, relationship, multiplicity and Role.
Figure 2.13 Analysis level class diagram
PROJE 6
Chapter Three: System Design

3. Introduction
In this phase the overall procedures, activities and means of carrying out during the Design
phase of the project are included. The following subtopics are discussed in this phase. These
are component diagram, deployment diagram, class diagram, persistence diagram, user
interface design, and algorithm design of the project.
3.1 Component diagram
Component diagram is a special kind of diagram in UML. It does not describe the
functionality of the system but it describes the components used to make those functionalities.
Component diagrams can also be described as a static implementation view of a system.
Static implementation represents the organization of the components at a particular moment.
Figure 3. 1 Component Diagram
PROJE 6
3.2 Deployment Diagram
One of the major tasks in system design deals with hardware/software mapping which deals
with which components would be part in which hardware and so on. The web based part is run
on a networked environment on different Operating System platforms. The client/server
architecture of the system enables different clients to connect to the server remotely through
Internet connection. Server side there is web server that is always connected with the internet
for listening HTTP requests and accepts connection request and uses Apache HTTP server
manipulates data from the database using PHP programs and answers user’s request. There is
a database server that has MYSQL program which enable to communicate with the web server
using PHP.
Figure 3. 2 deployment diagram
PROJE 6
3.3 Design class model

Class models show the classes of the system, their inter-relationships, and the
operations and attributes of the classes. Class diagram provide a graphical notation for
modelling, classes with their attribute data types, methods with their return types and
arguments and their data types, relationships, Access visibility, multiplicity.
Class diagram of BAHIR DAR GYM club management system
Figure 3. 3 design class Modelling
PROJE 6
3.4 Persistent model

Persistence modelling is used to communicate the design of the database, usually the data
base to both the users and the developers. It is also used to describe the persistence data
aspect of the system. The following diagram indicates the persistence diagram of the system.
Figure 3. 4 Persistent Model
PROJE 6
3.5 User Interface Design

User Interface (UI) Design focuses on anticipating what users might need to do and ensuring
that the interface has elements that are easy to access, understand, and use to facilitate those
actions. We have designed basic user interfaces for the system and we try to describe the
pages and summarize some of the links and buttons after the interfaces using table format. In
this system users will communicate with it through the following user interfaces.
I. Create Account
Figure 3. 5 User interface for create account
PROJE 7
II. Home Page
Figure 3. 6 User interface for home page
III. Log In form
Figure 3. 7 User interface for login
PROJE 7
IV. Add payment form
Figure 3. 8 User interface for add payment
PROJE 7
V. View trainers form
Figure 3. 9 User interface for view trainer
PROJE 7
3.5 Algorithm Design

An algorithm is an ordered set of unambiguous, executable steps, defining a terminating
process (Malik, 2011) may be described abstractly using human language (pseudo
code).Using a programming language of your choice. Problem Analysis to Program Design,
Fifth Edition, and
D.S. Malik) we also write algorithm for some method in the following way:
Method name= login ();
Inputs:-
 Username
 Password
Begin
Prompt to enter username;
Prompt to enter password;
Retrieve username from
database; Retrieve password from
database; Retrieve user type from
database; Retrieve status from
database;
If (entered username and password don’t match to retrieved username and password)
Display error message “incorrect username or password”
Prompt to enter username and password again
The required page is come based on user level.
End
Method name create account ();
PROJE 7
Input: -
 Username
PROJE 7
 Password;
 Conformation password
 Email
 Level
 Status
 Sex
 Name
Begin
Prompt to enter username
Prompt to enter password
Prompt to enter conformation password
Prompt to enter email
Prompt to enter level
Prompt to enter status
Prompt to select sex
Prompt to enter name
If (fields are not filled)

{
Display error message “all fields are not field”
Prompt the user the unfilled fields
}
All entered fields stored in database;
Account is successfully created:
End
Method name=change password ();
Input
 Username
 old password
PROJE 7
 new password
 conformation password
Begin
Prompt to enter username
Prompt to enter old password
Prompt to enter new password
Prompt to enter Confirmation of new password
Retrieve username from database
If (username do not match entered username)

{
Display error message “username doesn’t exist”
Prompt username again
}
Retrieve old password from database
Else If (old password do not match entered old password)

{
Display error message “old password do not match”
Prompt old password again
}
Else If (new entered password is not valid) {
Prompt user to enter valid password
}
Els
e
The password is successfully changed and database is updated:

End
Method add trainer
(); Inputs:-
 First name
PROJE 7
 Last name
 Age
 Sex
 photos
 E-mail
 Phone number
 height
 weight
 membership type
Begin
Prompt user to enter first name
Prompt user to enter last name
Prompt user to enter age
Prompt user to enter sex
Prompt user to capture trainer photo
Prompt user to enter E-mail
Prompt user to enter phone number
Prompt user to enter height

Prompt user to enter weight
Prompt user to enter membership type
If (fields are not filled)
{
Display error message “all fields are not field”
Prompt user to enter the unfilled fields
}
If (entered first name is numeric)
{
Display error message “name cannot be numeric value”
Prompt the user to enter first name again
PROJE 7
}
If (entered last name is numeric)
{
Display error message “name cannot be numeric value”
Prompt the user to enter last name again
}
If (entered age is not numeric)
{
Display error message “age must be numeric value”
Prompt the user to enter age again
}
If (E-mail format is not correct)
{
Display error message “E-mail format not correct”
Prompt the user to enter E-mail again
}
If (Phone format is not correct)
{
Display error message “Phone format not correct”
Prompt the user to enter phone number again
}
Insert all fields into the database
Trainer information is registered successfully
End
Method name Search trainer record
(); Input:-
 trainer id
 trainer name
Begin
Prompt to enter trainer id
Prompt to enter trainer name
PROJE 7
Retrieve trainer id from database
Retrieve trainer name from database
Retrieve photos from database
Retrieve email from database
Retrieve phone number from database
Retrieve age from database
Retrieve height from database
Retrieve weight from database
If (the selected trainer id or name doesn’t exist in the table list) {
Display error message “the selected item is doesn’t exist”
Select trainer id or name again
Else
Display the searched information on client browser;
End
PROJE 8
References
[1] Ambler. S, (2001).The Object Primer Second Edition. New York.
[2] BOOCH.G (1998).Object-oriented analysis and design.Welseley.Addison: USA.

[3] Malik. D.S, (2011) From Problem Analysis to Program Design, Fifth Edition,)
[4] Ribu .K (2001).Estimating object-Oriented Software Projects with Use

case: Oslo
[5] Sons&Jhon (2005). System analysis and design to version 2, Sons&Jhon

Wiley).USA
PROJE 8
Appendices
A. Interview questions
We prepare the following questions and get answers from staff members and stakeholders in
order to get more information about the system.
1. Is the organization private or government?

2. Who is the owner of the organization?
3. What type of system you are use till now manual, semi-automated, or automated?
4. Do your company using any existing system to control the trainer and
payment Process?
5. Who are the main characters of using the system?
6. How many trainers and employees participate in your system?
7. Do you facing any difficulty or inaccuracy during payment with your trainer?
8. Do you wish to expand your business through Internet?
9. Do you think the current system is secure enough to protect your company data?
10. What type of the reports that you use currently for the company?
11. What is your role to improve wellness of the trainer?
12. How many membership type that your system have?
13. Do you provide any extra services to your trainer?
PROJE 8
B. Existing System Form
PROJE 8

Gym Club Management System For Bahir Dar

Uploaded by

Copyright:

Available Formats

Gym Club Management System For Bahir Dar

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Gym Club Management System For Bahir Dar

Uploaded by

Copyright:

Available Formats

Bahir Dar University

Bahir Dar Institute of Technology

Advisor ፡ Derejaw Lake

January 29, 2009

Getaneh Alehegn -----------------------------------------------

Minichil Assefa -----------------------------------------------

Selam Ayalew ------------------------------------------------

Program: degree of Bachelor of Science in computer science program

Name of Advisor Signature

Examining committee members signature Date

1.4.2............................................................................. Specific Objectives 3

1.6.1......................................................................... Data collection method 5

1.6.2.................................................................................. Approach used 6

1.6.3.................................................................... System Development Tools 6

2.5.1............................................................................... Use case diagram 16

2.5.3............................................................................... Activity Diagram 58

2.5.4...........................................................................Analysis Class Model 65

Figure 3. 1 Component Diagram.........................................................................................................66

Table 2.1 use case description for create account...............................................................................19

Admin: System Administrator

BDR: BAHIR DAR

BDU: Bahir Dar University

GCMS: Gym Club Management System

UC: use case

SQL: Structured query language

MYSQL: MY Structured language

UML: Unified modelling language

BR: Business rule

PHP: Hypertext Preprocessor

CSS: Cascading style sheet

HTML: Hyper Text Markup Language

HTTP:Hyper Text transfer protocol

ODBC: Open Database Connectivity

AJAX: Asynchronous JavaScript and XML

Chapter one: system planning

1.1 Background of the organization

1.2 Existing System

1.3 Proposed System

 To help the organization to reduce the overload paperwork

 To reduce the storage space problem of keeping the trainer records.

 Speed out the joining and leaving process for trainer

 Reduce the administrative costs because we no need to hire more staffs.

 Can maintain the trainer history easily.

 Can save the printing and distributing paper based manuals.

 Can avoid redundancy of data.

 Administrator controls the entire system.

1.4 Objectives of the Project

1.4.1 General Objectives

1.4.2 Specific Objectives

 Gather requirements continuously for the system

 Study the existing system and find out the problem.

 Find the solution for the problem found in existing system.

 Identify functional and non-functional requirements for the new system

 Implement and test the system.

 deploying the system

1.5 Scope of the project

Modules included in our project:

Modules excluded in our project: