0% found this document useful (0 votes)
13 views

gymupdated-converted

Uploaded by

princeccc555
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
13 views

gymupdated-converted

Uploaded by

princeccc555
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 44

Abstract / Synopsis

This Gym Management Software is a gym and health club membership management
system. You can keep records on your members their memberships, and have quick
and easy communication between you and your members. Gym Management also
includes a booking system, point of sale and has a range of reports that help in the
management of your club. Our Gym Management System provides lots of function
such data entry of customer, keeping record of all the things about customers fees,
plan, physical fitness which help to provide good quality of services to customer from
Gym managers . In this proposed system also provide the total information about
machinery and data of coaches is also stored in it. Services provided by Gym also
handled by this system. This system structure has become very simple to understand
because of data flow diagram provided by us.

The proposed software facilitates the data storage, data maintenance and its retrieval
for the gym in an igneous way. To store the record of the customers, the staff that has
the privileges to access, modify and delete any record and finally the service, gym
provides to its customers. Only the staff has the privilege to access any database and
make the required changes, if necessary. It is an Easy to use software which handles
the customer-staff relationship in an effective manner. It is a user friendly system that
requires minimal user training. Most of features and function are similar to those on
any windows platform.

This system can be used in gyms in order to have a easily accessible software which is
easy to use and which handles the customer-staff relationship in an effective manner.
TABLE OF CONTENTS

CHAPTER 1: INTRODUCTION
1.1 Background
1.2 Objectives
1.3 Purpose, Scope, and Applicability
1.3.1 Purpose
1.3.2 Scope 1.3.3 Applicability
1.4 Achievements
1.5 Organisation of Report

CHAPTER 2: SURVEY OF TECHNOLOGIES


2.1 Introduction / Background / Context
2.2 Existing System
2.3 Existing Solutions in the Market
2.4 Proposed System
2.5 Justification of Proposed System
TABLE OF CONTENTS

CHAPTER 3: REQUIREMENTS AND ANALYSIS


3.1 Problem Definition
3.2 Requirements Specification
3.3 Planning and Scheduling
3.3.1 GANTT Chart
3.3.2 WBS Chart
3.4 Software and Hardware Requirements
3.5 Preliminary Product Description
3.6 Conceptual Models
3.6.1 Data Flow Diagrams / Class Diagrams 3.6.2 ER Diagrams 3.6.3
System Flowcharts / Activity Diagrams

CHAPTER 4: SYSTEM DESIGN


4.1 Basic Modules
4.2 Data Design
4.2.1 Schema Design / Sample Schema & Databases
4.2.2 Data Integrity and Constraints / Validation Rules
4.3 Procedural Design
4.3.1 Logic Diagrams / Use Case Diagrams
4.3.2 Data Structures / Sample Tables
4.3.3 Any Other Diagram (Project Specific)
4.4 User interface design
4.5 Security Issues
4.6 Test Cases Design
Software and Broad Areas of Application

Front End HTML


Interaction CSS

Back End PHP

Database MYSQL

HTML
Languages used PHP
SQL
Apache
Tools & Adobe Dreamweaver
Technologies used Adobe Photoshop
Xamp Server

Gym
Areas of Application Fitness Centres
CHAPTER 1: INTRODUCTION

GYM Management System is the process whereby records of members are


directly stored and can be accessed by the admin interactively in real-time without an
intermediary service.

Gym Management System is the process of storing member’s details including health
status, payment records, exercise routines etc. who have taken admission to the gym.
Since the emergence of the World Wide Web, owners have sought to stored their user
details in a digital system for easy access and find out every detail when needed.

1.1 Background

Gym Management System allows us to browse through endless possibilities, and


access their customer’s details.

Say 'goodbye' to the days when you use to maintain a register, log book and
bill. This system can store the payment history, generate bill, and store the details of
the customers who have taken admission into the gym and also the exercise routine the
respective member is following from his/her joining date. Payment records can be
added and stored. Various plans of payments can be added with respective validity.
The member enroll to the specific plan are displayed and their respective date of
ending of their plan is also accessible which is fully controlled by the gym owner or
the administrator.
1.2 Objectives
My objective is to design such an application using which one can say 'goodbye' to the
days when you store and maintain records of the users who have taken admission into
the gym. Each and every records of the users are stored in the digital system which is
accessible to the administrator and view the needed contents which saves time and
convenient to use the system.

1.3 Purpose, Scope and Applicability


1.3.1 Purpose
GYM Management system would have the following goals.

• Provide a web admin interface to add, view, delete records of all


the customers.

• Provide an admin interface to view the total members of the gym.

• Provide an admin interface to change details of all the members


when required.

• Provide an admin interface to view the total income from the


members who have taken admission.

1.3.2 Scope

The main scope and deliverables of the project would be to:

• Understand and prepare detailed requirement and specifications

• Prepare high level and detailed design specifications of the system

• Prepare Test Plan and Test cases

• Develop the system and coding

• Perform unit testing, integration and system testing

• Demonstrate a bug free application after suitable modification if needed.


1.3.3 Applicability

Our application project on Gym Management and database management


and transactions. This system is proposed to be an automate database management &
transactions. This stores member, receipt and other gym related information. It also
provides the facility of search & advanced search for searching the records efficiently &
immediately. This system provides data storing & report generation.

1.4 Achievements
By successfully implementing the project, a substantial knowledge has been acquired
on the implementation of a database system using .net technologies. This knowledge
will be useful in the future in creating any type of desktop application or online
database systems.

1.5. Organization of Report

• For Management
Gym Management System is primarily designed for providing information
from the data after processing them. This system is designed for supplying
information to the strategic level of management from the operational
control. It includes almost all the functional areas needed like keeping
Member Record and payment Record.

• For User
With this electronic data processing system, the operators will able
to maintain the following task:

• Information regarding Members.


• Records profile detail and payment detail.
•Regular Transaction Details
• For data processing department
• In maintenance, the data processing department needs to
create backup of the database file from time to time.
CHAPTER 2: SURVEY OF TECHNOLOGIES

2.1 Introduction
In a desktop application like Gym Management System, there is a scope for a large
number of platforms, languages and frameworks to choose from. Before selecting
from this large array of technologies, the following aspects, which are characteristic to
windows based application like this one, have been kept in mind:

• Data validation

• Performance

• Reliability

• Scalability

• Security

• Portability

• Performance

• Time constraint

• Cost constraint

2.2 Existing System

The existing system and its problems are:

• Existing system is manual.


• Time consuming as data entry which include calculations took lot of time.
• Searching was very complex as there could be 100’s of entry every year.
• The proposed system is expected to be faster than the existing system.
• The Project was made in order to effectively and efficiently cater to requirements
of the fitness center. Very frequently the person who generally holds the tasks to
manage the center needs to keep records of all the transactions as well as data
manually. Generally, in order to structure these tasks Separate Registers are
maintained. This whole process thus becomes quite cumbersome for them to
control manually. Moreover, any wrong data entered mistakenly can brings
serious results.
• This Manually Managed system of the store was also heavily prone to data loss
due to certain causes Misplacement of Registers, Destruction of Registers,
Unauthorized access to registers etc. which can bring in disastrous
Consequences.
• The cost of maintenance of data and records of occurrence of transactions is
very high.
• Searching a particular data specific to particular requirements is also very
tedious in such system. In order to retrieve records, The responsible person
needs to manually locate the appropriate register and locate the appropriate
placement of that particular record which may be very time consuming.
• Data Redundancy is also a great issue in such kind of system.” Redundancy”
means repetition; Thus data modified or updated at a particular place may not
be data modified or updated at the other related place which may create
inconsistencies in data handling, Destroys Data Integrity and creates confusion
for the owner.
2.3 Existing Solutions in the market
• The software which are now available in the market are capable enough to allow the
concerned person to store and retrieve any type of record with just a single click of
mouse. The software allows Interactive, Self-describing Graphic User Interface
environment where even standalone users can work very comfortably and easily.

• All the data pertaining to transactions or other important entities is kept at central
database from where its attributes can be easily controlled. But, such kind of technical
details are hidden from the standalone User. He just needs to type in correct
details of the given entity and then click the save button with the help of mouse.
However, that central repository of data can be easily accessed if required.

• Data Redundancy is no more the problem now. The data modified from one
particular data entry form will reflect the modifications at the other related forms
too. This has thus reduced the chances of data inconsistency in our data storage.

• There is no need to manage bulky registers now as data stored in the backend
database can be readily retrieved either from the frontend form itself or directly
from the database.

• Requires one-time investment of setting up required Hardware and Software after


which no more headache is required by the Managers. Moreover, It also reduces
dependence on Man Power.

• Effective Search measures are present at each and every data transactional forms
from where by just entering a Unique keyword for that data its whole records can
be readily seen within microseconds. Moreover, Facility of Updating and Deletion
of data through search is also available.

2.4 Proposed System


The proposed system will be designed to support the following features: -

• The proposed system has a user friendly Interface for porting of data to server.
• The proposed system provides the facility to pull the data from the server using
a key (such as id) and get the desired report.
• The proposed system provides the no replication of data.
The various technologies available for consideration in the proposed system for proper
functionality are as follows:

Operating System: Windows 7


Client Side Scripting:

• HTML
• CSS
• JavaScript

Server Side Scripting: PHP


Database Tool: My SQL

Testing Server: Apache

Other Software Used:

• Adobe Dreamweaver
• Adobe Photoshop
• XampServer
2.5 Justification of proposed system

HTML

HTML or Hypertext Markup Language is the standard markup language used to


create web pages.

HTML is written in the form of HTML elements consisting of tags enclosed in angle
brackets (like <html>). HTML tags most commonly come in pairs like <h1> and
</h1>, although some tags represent empty elements and so are unpaired, for example
<img>. The first tag in a pair is the start tag, and the second tag is the end tag (they
are also called opening tags and closing tags).

The purpose of a web browser is to read HTML documents and compose them into
visible or audible web pages. The browser does not display the HTML tags, but uses
the tags to interpret the content of the page. HTML describes the structure of a
website semantically along with cues for presentation, making it a markup language
rather than a programming language.

HTML elements form the building blocks of all websites. HTML allows images and
objects to be embedded and can be used to create interactive forms. It provides a
means to create structured documents by denoting structural semantics for text such as
headings, paragraphs, lists, links, quotes and other items. It can embed scripts written
in languages such as JavaScript which affect the behavior of HTML web pages.

CSS

CSS was first developed in 1997, as a way for Web developers to define the look and
feel of their Web pages. It was intended to allow developers to separate content from
design so that HTML could perform more of the function that it was originally based
on the markup of content, without worry about the design and layout.

CSS didn't gain in popularity until around 2000, when Web browsers began using
more than the basic font and color aspects of CSS.

Web Designers that don't use CSS for their design and development of Web sites are
rapidly becoming a thing of the past. And it is arguably as important to understand CSS
as it is to know HTML - and some would say it was more important to know CSS.

Style sheet refers to the document itself. Style sheets have been used for document
design for years. They are the technical specifications for a layout, whether print or
online. Print designers use style sheets to insure that their designs are printed exactly
to specifications. A style sheet for a Web page serves the same purpose, but with the
added functionality of also telling the viewing engine (the Web browser) how to
render the document being viewed.

PHP:

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


source general-purpose scripting language that is especially suited for web
development and can be embedded into HTML.

Instead of lots of commands to output HTML (as seen in C or Perl), PHP pages
contain HTML with embedded code that does "something" (in this case, output "Hi,
I'm a PHP script!"). The PHP code is enclosed in special start and end processing
instructions <?php and ?> that allow you to jump into and out of "PHP mode."

What distinguishes PHP from something like client-side JavaScript is that the code is
executed on the server, generating HTML which is then sent to the client. The client
would receive the results of running that script, but would not know what the underlying
code was. You can even configure your web server to process all your HTML files with
PHP, and then there's really no way that users can tell what you have up your sleeve.

The best things in using PHP are that it is extremely simple for a newcomer, but offers
many advanced features for a professional programmer. Don't be afraid reading the
long list of PHP's features. You can jump in, in a short time, and start writing simple
scripts in a few hours.

MYSQL:

MySQL, the most popular Open Source SQL database management system, is
developed, distributed, and supported by Oracle Corporation.

The MySQL Web site (http://www.mysql.com/) provides the latest information about
MySQL software.

• MySQL is a database management system.

A database is a structured collection of data. It may be anything from a simple


shopping list to a picture gallery or the vast amounts of information in a
corporate network. To add, access, and process data stored in a computer
database, you need a database management system such as MySQL Server.
Since computers are very good at handling large amounts of data, database
management systems play a central role in computing, as standalone utilities, or
as parts of other applications.

• MySQL databases are relational.

A relational database stores data in separate tables rather than putting all the data
in one big storeroom. The database structures are organized into physical files
optimized for speed. The logical model, with objects such as databases, tables,
views, rows, and columns, offers a flexible programming environment. You set up
rules governing the relationships between different data fields, such as one-to-one,
one-to-many, unique, required or optional, and “pointers” between
different tables. The database enforces these rules, so that with a well-designed
database, your application never sees inconsistent, duplicate, orphan, out-of-
date, or missing data.

The SQL part of “MySQL” stands for “Structured Query Language”. SQL is
the most common standardized language used to access databases. Depending
on your programming environment, you might enter SQL directly (for
example, to generate reports), embed SQL statements into code written in
another language, or use a language-specific API that hides the SQL syntax.

SQL is defined by the ANSI/ISO SQL Standard. The SQL standard has been
evolving since 1986 and several versions exist. In this manual, “SQL-92” refers
to the standard released in 1992, “SQL:1999” refers to the standard released in
1999, and “SQL:2003” refers to the current version of the standard. We use the
phrase “the SQL standard” to mean the current version of the SQL Standard at
any time.

• MySQL software is Open Source.

Open Source means that it is possible for anyone to use and modify the software.
Anybody can download the MySQL software from the Internet and use it without
paying anything. If you wish, you may study the source code and change it to suit
your needs. The MySQL software uses the GPL (GNU General Public License),
http://www.fsf.org/licenses/, to define what you may and may not do with the software
in different situations. If you feel uncomfortable with the GPL or need to embed
MySQL code into a commercial application, you can buy a commercially licensed
version from us. See the MySQL Licensing Overview for more information
(http://www.mysql.com/company/legal/licensing/).
CHAPTER 3: REQUIREMENTS & ANALYSIS

3.1 Problem Definition


Problem Definition and Need for the New System

• Gym management System is a specific requirement of the client that


integrates the storing and accessing services specifically for their members.
• Reports can be generated at any time within few seconds, so that manual labor
is not required, and also analysis can be performed much more frequently
which helps in taking decision.
• The details regarding all users, can also be maintained as their information
is very helpful and sometimes becomes a critical requirement.
• To overcome these problems we develop “GYM Management System”.

3.2 SYSTEM REQUIREMENTS SPECIFICATIONS


System requirements are expressed in a software requirement document. The
Software requirement specification (SRS) is the official statement of what is required of
the system developers. This requirement document includes the requirements definition
and the requirement specification. The software requirement document is not a design
document. It should set out what the system should do without specifying how it should
be done. The requirement set out in this document is complete and consistent.

The software specification document satisfies the following:-

• It specifies the external system behaviours.


• It specifies constraints on the implementation.
• It is easy to change.
• It serves as reference tool for system maintainers.
• It record forethought about the life cycle of the system.
• It characterizes acceptable response to undesired events.
User Class and Characteristics:

• Administrators can add, edit & delete member, plan, schedule and
make payment update of the respective member.
• Administrator can view the monthly income of the member.
• Administrator can update the health status of the members.
• Administrator will have a overview of the total plan available total
member join per year and month.
• Administrator can change admin password admin user profile and the
secure key when the changes are required.
• Administrator can view the expire date of a specific member enrolled to
the particular plan.

Functional Requirements:
• The System must provide following functionalities—
• Keeping records of registration of members.
• Keeping the records of payments.
• Keeping the monthly income.
• Storing the health status of the customer.

Non Functional Requirements:


Following Non-functional requirements will be there in the online shopping portal.

• Secure access of confidential data (customer’s details).


• 24 X 7 availability.
• Better component design to get better performance at peak time.

Flexible service based architecture will be highly desirable for future extension
Nonfunctional requirements define system properties and constraints It arise through
user needs, because of budget constraints or organizational policies, or due to the
external factors such as safety regulations, privacy registration and so on.
Various other Non-functional requirements are:

1. Security

2. Reliability

3. Maintainability

4. Portability

5. Extensibility

6. Reusability

7. Application Affinity/Compatibility

8. Resource Utilization

3.3 Planning and Scheduling


3.3.1 Gantt Chart

Fig 3.3.1(a). Gantt Chart


3.3.2 WBS Chart

Fig 3.3.2(a). WBS Chart

3.4 Software and Hardware Requirements


User Interface:

User of the system will be provided with the Graphical user interface, there is no
command line interface for any functions of the product.

Hardware Interface:
Hardware requirements for running this project are as follows:

Processor: - Pentium I or above.

RAM: - 128 MB or above.

HD: - 20 GB or above.
Software Interface: -
Software required to make working of product is:-

Front end- HTML/PHP

Back end- My SQL

3.5 Preliminary Product Description


This application comprises of these major modules:
Module 1: Admin Login:
- The admin can login using an appropriate username and password.
Module 2:
• This module consists of the dashboard of the Gym.
• The details like the total paid income of the month, total members, members
who joined this month and the plans available in the gym are displayed.
Module 3: This module consists of the registration of the new
member:

- This contains the required details of the member to be added so that the
member can be registered in the system.

- The required fields to be filled would be the Membership ID, Name,


Address, Gender, Date of Birth, Phone Number, Email ID, Joining Date
and most important field which will be the Membership Plan.
Module 4:
• This module consists of the details of the members whose payments are yet to
be paid and this list can be updated if the member has paid the appropriate
amount.
Module 5:

• This module consists of all the Member details who have registered in
the Gym:
- All the details of all the members are display in a tabular format.
- Each member data can be accessed separately which would contain the
member details as well as their payment history which can also
be updated or deleted.
Module 6:

• This module contains the Health Status which would show the current status of
the member:

- The calorie count, height and weight are taken into count and the
system displays the BMI of the member.
- The user can add remarks to the member’s status in order to keep that in
record.
Module 7:
• This module consists of the monthly overview of the Gym’s monthly income:
- We can also view the older monthly incomes with the detailed
information of the payments received from the members.

- This can be used in order to compare the previous month’s income from
the income of this month.
Module 8:

• This contains the detailed information about the exercise routine of the
member. These are categorized into each days’ workout routine in detail and
this can be printed.
Module 9:

• This would display the monthly plans which are available for the user to
select from the member’s requirement basis.

- All the plan related details will be displayed and these


details can also be updated as well as deleted.
Module 10:

• This module consists of the user profile in which the user can reset or
update all user details
3.6 Conceptual Models
3.6.1 Data Flow Diagram
What it is?

The Data Flow Diagram shows the flow of data or information. It can be
partitioned into single processes or functions. Data Flow Diagrams can be grouped
together or decomposed into multiple processes. There can be physical DFD's that
represent the physical files and transactions, or they can be business DFD's (logical, or
conceptual).

When it's used?

The DFD is an excellent communication tool for analysts to model processes


and functional requirements. One of the primary tools of the structured analysis efforts
of the 1970's it was developed and enhanced by the likes of Yourdon, McMenamin,
Palmer, Gane and Sarsen. It is still considered one of the best modeling techniques for
eliciting and representing the processing requirements of a system.

Used effectively, it is a useful and easy to understand modeling tool. It has


broad application and usability across most software development projects. It is easily
integrated with data modeling, workflow modeling tools, and textual specs. Together
with these, it provides analysts and developers with solid models and specs. Alone,
however, it has limited usability. It is simple and easy to understand by users and can
be easily extended and refined with further specification into a physical version for the
design and development teams.

The different versions are Context Diagrams (Level 0), Partitioned Diagrams
(single process only -- one level), functionally decomposed, leveled sets of Data Flow
Diagrams.

Data Store

It is a repository of information. In the physical model, this represents a file,


table, etc. In the logical model, a data store is an object or entity.
Dataflow
DFDs show the flow of data from external entities into the system, showed
how the data moved from one process to another, as well as its logical storage. There
are only four symbols:

• Squares representing external entities, which are sources or destinations of data.

• Rounded rectangles representing processes, which take data as input, do


something to it, and output it.

• Arrows representing the data flows, which can either, be electronic data or
physical items.

• Open-ended rectangles representing data stores, including electronic stores


such as databases or XML files and physical stores such as or filing cabinets or
stacks of paper.

There are several common modeling rules for creating DFDs:

• All processes must have at least one data flow in and one data flow out.

• All processes should modify the incoming data, producing new forms of
outgoing data.

• Each data store must be involved with at least one data flow.

• Each external entity must be involved with at least one data flow.

• A data flow must be attached to at least one process.

DFDs are nothing more than a network of related system functions and indicate
from where information is received and to where it is sent. It is the starting point in the
system that decomposes the requirement specifications down to the lowest level detail.

The four symbols in DFD, each of which has its meaning. They are given below:

• External entities are outside to system but they either supply input data in the
system or use the system output. These are represented by square of rectangle.
External entities that supply data into a system are sometimes called Sources.
External entities that use system data are sometimes called sinks.
• Dataflow models that passages of data in the system and are represented by line
by joining system components. An arrow indicates the direction of the flow and
the line is labeled by the name of the dataflow.
• Process show that the systems do. Each process has one or more data inputs
and one or data outputs. Circles in DFD represent them. Each high level
process may be consisting of more than one lower level processes. Process will
be expanded in sequent level DFD. A circle or a bubble represents a process
that transforms incoming data flow into outgoing dataflow.

The high level processes in a system are:

• Receivable process.
• Verifiable process.
• Disposal process.

• File or data store is a repository of data. They contain data that is retained in
the system. Process can enter data into data store or retrieved data from the data
store. An open rectangle is a data store, data at rest.
0-Level DFD:

Fig 3.6.1(a).DFD
1st level DFD for Admin Processes

Fig 3.6.1(b). DFD

DFD For User Registration and Profile Update

Fig 3.6.1(c). DFD


DFD for Manage Timetable/Plan

Fig 3.6.1(d). DFD

3.6.2 Entity-Relationship Model


Simply stated the ER model is a conceptual data model that views the real world
as entities and relationships. A basic component of the model is the Entity-Relationship
diagram which is used to visually represent data objects. Since Chen wrote his paper the
model has been extended and today it is commonly used for database.

Basic Constructs of E-R Modeling


The ER model views the real world as a construct of entities and association
between entities.

Entities
Entities are the principal data object about which information is to be collected.
Entities are classified as independent or dependent (in some methodologies, the terms
used are strong and weak, respectively). An independent entity is one that does not rely
on another for identification. A dependent entity is one that relies on another for
identification. .

Relationships
A Relationship represents an association between two or more entities.
Relationships are classified in terms of degree, connectivity, cardinality, and existence.

Attributes
Attributes describe the entity of which they are associated. A particular instance
of an attribute is a value. The domain of an attribute is the collection of all possible
values an attribute can have. The domain of Name is a character string.

Classifying Relationships
Relationships are classified by their degree, connectivity, cardinality, direction,
type, and existence. Not all modeling methodologies use all these classifications.

Degree of a Relationship
The degree of a relationship is the number of entities associated with the
relationship. The n-ary relationship is the general form for degree n. Special cases are
the binary, and ternary, where the degree is 2 and 3 respectively.

Connectivity and Cardinality

The connectivity of a relationship describes the mapping of associated entity


instances in the relationship. The values of connectivity are "one" or "many". The
cardinality of a relationship is the actual number of related occurrences for each of the
two entities. The basic types of connectivity for relations are: one-to-one, one-to-
many, and many-to-many.

Direction
The direction of a relationship indicates the originating entity of a binary
relationship. The entity from which a relationship originates is the parent entity; the
entity where the relationship terminates is the child entity.
The direction of a relationship is determined by its connectivity type .An
identifying relationship is one in which one of the child entities is also a dependent
entity. A non-identifying relationship is one in which both entities are independent.

Existence
Existence denotes whether the existence of an entity instance is dependent
upon the existence of another, related, entity instance. The existence of an entity in a
relationship is defined as either mandatory or optional.

Generalization Hierarchies
A generalization hierarchy is a form of abstraction that specifies that two or
more entities that share common attributes can be generalized into a higher level
entity type called a super type or generic entity. The lower-level of entities become the
subtype, or categories, to the super type. Subtypes are dependent entities.

ER Notation

The symbols used for the basic ER constructs are:


• Entities are represented by labeled rectangles. The label is the name of the entity.

• Relationships are represented by a solid line connecting two entities. The name of
the relationship is written above the line. Relationship names should be verbs.

• Attributes, when included, are listed inside the entity rectangle. Attributes
which are identifiers are underlined. Attribute names should be singular nouns.

• Cardinality of many is represented by a line ending in a crow's foot. If the


crow's foot is omitted, the cardinality is one.

• Existence is represented by placing a circle or a perpendicular bar on the line.


Mandatory existence is shown by the bar (looks like a 1) next to the entity for
an instance is required. Optional existence is shown by placing a circle next to
the entity that is optional.

• Existence is represented by placing a circle or a perpendicular bar on the line.


Mandatory existence is shown by the bar (looks like a 1) next to the entity for an
instance is required. Optional existence is shown by placing a circle next to the
entity that is optional.

Fig. 3.6.2(a) ER Diagram


CHAPTER 4: SYSTEM DESIGN

System design is the solution of a “how to approach to the creation of the new system.
It is composed of several steps. It facilitates the understanding and provides the
procedural details necessary for implementation of the system recommended in the
feasibility study. Emphasis is given on translating the performance requirements into
design specification. Design goes through logical and physical stages of development.

Logical design reviews the present physical system; prepares input and output
specification; make editing; security and control specification; details the
implementation plan, and prepare logical design walk through. The physical design
maps out the details of the physical system; plans the system implementation plan and
specifies hardware and software. System design translates the system requirement into
the ways of the system as recommended in the feasibility study. Thus the system
design is the translation from user-oriented document to a programmer or a database
personal oriented document. System design is a highly creative process that can be
greatly facilitated by the following:-

• Strong Problem Definition


• Pictorial description of the Existing System
• Set of Requirements of the new system
4.1 BASIC DESIGN
Modules Description:
• Registration: Customer can register their account here to continue shopping.
• Admin: Admin can add books, check orders and make sure the orders are
delivered on time and can confirm payments by the customers.
• Shopping Cart: Customers after login can browse through the different
books and choose one or more products and can add them to cart.
• Payment: Cash on Delivery facility is available.
4.2 DATA DESIGN

Very careful attention had to be given to input design, which is a major part of
the overall system design. In order to make the data entry as easy, logical and error
free as possible, specific standards had been followed. Validation checks, provided in
the system prevented the user in entering incorrect, erroneous data. This made sure
that, only valid data had been available for data processing. If valid data was entered,
then meaningful error messages had been prompted to enter correct data. The
interactive screen formats facilitate the entry of valid data.

4.2.1 DATA INTEGRITY & CONSTRAINTS/ VALIDATION


RULES:
Some fields are having only number, as an I/P. For this key ASCII is checked.
If they entered characters, it would display the message to enter number only.
Exchange rates field will be validated for number and dot symbols.

4.2.2 INPUT DESIGN OBJECTIVES:


The numbers of clear objectives of input design are,
• To produce a cost effective method of input
• To achieve the highest possible level of accuracy
• To ensure that the input is acceptable to and understand by the user staff
4.3 OUTPUT DESIGN:

Output, as you probably know, generally refers to the results and information
that are generated by the system. For many end-users, output is the main reason for
developing the system and the basis on which they will evaluate the usefulness of the
application. Most end users will not actually operate the information system or enter
data through workstations, but they will use the output from the system.
When designing output, systems analysts must accomplish the following.
• Determine what information to present
• Decide whether to display, print, or “speak” the information and select the
output medium.
• Arrange the presentation of information in an acceptable format.
• Decide how to distribute the output to intended recipients.
That alignment of information on a display or printed document is termed as layout.
Accomplishing the general activities listed above will require specific decisions, such
as whether to use preprinted forms when preparing reports and documents, how many
lines to plan on a printed page, or whether to use graphics and color.
The output design is specified on layout performs, sheets that describe the
location characteristics, and format of the column headings and pagination. As we
indicated at the beginning of this discussion, these elements are analogous to an
architect’s blue print that shows the location of each component.

4.3 Procedural Design


4.3.1 Use Case Diagram

Fig. 4.3.1(a). Use Case Diagram


4.3.2 Data Structure/ Relational Model

Relational Model was proposed by E.F. Codd to model data in the form of relations or
tables. After designing the conceptual model of Database using ER diagram, we need
to convert the conceptual model in the relational model which can be implemented
using any RDMBS languages like Oracle SQL, MySQL etc.

Fig.4.3.2(a). Relational Diagram


4.4 USER INTERFACE
<!DOCTYPE html>
<html lang="en">
<?php session_start(); ?>
<head>
<meta charset="utf-8">
<meta content="width=device-width, initial-scale=1.0" name="viewport">
<title>Gym Management System</title>

<?php
if(!isset($_SESSION['login_id']))
header('location:login.php');
include('./header.php');
// include('./auth.php');
?>
</head>
<style>
body{
background: #80808045;
}
.modal-dialog.large {
width: 80% !important;
max-width: unset;
}
.modal-dialog.mid-large {
width: 50% !important;
max-width: unset;
}
#viewer_modal .btn-close {
position: absolute;
z-index: 999999;
/*right: -4.5em;*/
background: unset;
color: white;
border: unset;
font-size: 27px;
top: 0;
}
#viewer_modal .modal-dialog {
width: 80%;
max-width: unset;
height: calc(90%);
max-height: unset;
}
#viewer_modal .modal-content {
background: black;
border: unset;
height: calc(100%);
display: flex;
align-items: center;
justify-content: center;
}
#viewer_modal img,#viewer_modal video{
max-height: calc(100%);
max-width: calc(100%);
}
</style>
<body>
<?php include 'topbar.php' ?>
<?php include 'navbar.php' ?>
<div class="toast" id="alert_toast" role="alert" aria-live="assertive" aria-atomic="true">
<div class="toast-body text-white">
</div>
</div>
<main id="view-panel" >
<?php $page = isset($_GET['page']) ? $_GET['page'] :'home'; ?>
<?php include $page.'.php' ?>

</main>
<div id="preloader"></div>
<a href="#" class="back-to-top"><i class="icofont-simple-up"></i></a>

<div class="modal fade" id="uni_modal" role='dialog'>


<div class="modal-dialog modal-md" role="document">
<div class="modal-content">
<div class="modal-header">
<h5 class="modal-title"></h5>
</div>
<div class="modal-body">
</div>
<div class="modal-footer">
<button type="button" class="btn btn-primary" id='submit' onclick="$('#uni_modal
form').submit()">Save</button>
<button type="button" class="btn btn-secondary" data-dismiss="modal">Cancel</button>
</div>
</div>
</div>
</div>
<div class="modal fade" id="confirm_modal" role='dialog'>
<div class="modal-dialog modal-md" role="document">
<div class="modal-content">
<div class="modal-header">
<h5 class="modal-title">Confirmation</h5>
</div>
<div class="modal-body">
<div id="delete_content"></div>
</div>
<div class="modal-footer">
<button type="button" class="btn btn-primary" id='confirm' onclick="">Continue</button>
<button type="button" class="btn btn-secondary" data-dismiss="modal">Close</button>
</div>
</div>
</div>
</div>
<div class="modal fade" id="viewer_modal" role='dialog'>
<div class="modal-dialog modal-md" role="document">
<div class="modal-content">
<button type="button" class="btn-close" data-dismiss="modal"><span class="fa fa-
times"></span></button>
<img src="" alt="">
</div>
</div>
</div>
</body>
<script>
window.start_load = function(){
$('body').prepend('<di id="preloader2"></di>')
}
window.end_load = function(){
$('#preloader2').fadeOut('fast', function() {
$(this).remove();
})
}
window.viewer_modal = function($src = ''){
start_load()
var t = $src.split('.')
t = t[1]
if(t =='mp4'){
var view = $("<video src='"+$src+"' controls autoplay></video>")
}else{
var view = $("<img src='"+$src+"' />")
}
$('#viewer_modal .modal-content video,#viewer_modal .modal-content img').remove()
$('#viewer_modal .modal-content').append(view)
$('#viewer_modal').modal({
show:true,
backdrop:'static',
keyboard:false,
focus:true
})
end_load()
}
window.uni_modal = function($title = '' , $url='',$size=""){
start_load()
$.ajax({
url:$url,
error:err=>{
console.log()
alert("An error occured")
},
success:function(resp){
if(resp){
$('#uni_modal .modal-title').html($title)
$('#uni_modal .modal-body').html(resp)
if($size != ''){
$('#uni_modal .modal-dialog').addClass($size)
}else{
$('#uni_modal .modal-dialog').removeAttr("class").addClass("modal-dialog modal-md")
}
$('#uni_modal').modal({
show:true,
backdrop:'static',
keyboard:false,
focus:true
})
end_load()
}
}
})
}
window._conf = function($msg='',$func='',$params = []){
$('#confirm_modal #confirm').attr('onclick',$func+"("+$params.join(',')+")")
$('#confirm_modal .modal-body').html($msg)
$('#confirm_modal').modal('show')
}
window.alert_toast= function($msg = 'TEST',$bg = 'success'){
$('#alert_toast').removeClass('bg-success')
$('#alert_toast').removeClass('bg-danger')
$('#alert_toast').removeClass('bg-info')
$('#alert_toast').removeClass('bg-warning')
if($bg == 'success')
$('#alert_toast').addClass('bg-success')
if($bg == 'danger')
$('#alert_toast').addClass('bg-danger')
if($bg == 'info')
$('#alert_toast').addClass('bg-info')
if($bg == 'warning')
$('#alert_toast').addClass('bg-warning')
$('#alert_toast .toast-body').html($msg)
$('#alert_toast').toast({delay:3000}).toast('show');
}
$(document).ready(function(){
$('#preloader').fadeOut('fast', function() {
$(this).remove();
})
})
$('.datetimepicker').datetimepicker({
format:'Y/m/d H:i',
startDate: '+3d'
})
$('.select2').select2({
placeholder:"Please select here",
width: "100%"
})
</script>
</html>
Code efficiency

Code efficiency has been achieved through proper validation using various methods
in PHP coding. Fist no data can be added, viewed, edited and d e l e t e d t o database
w i t h o u t l o g i n o r s e s s i o n . For t h i s w e h a v e implanted session tracking
techniques through PHP. Codlings have been used to validate various f o r ms to
ensure correct data should enter in database.

4.5 Security Issues

The war between data defenders and data thieves has been described as a cat-and-
mouse game. As soon as the white hats counter one form of black-hat malicious
behaviour, another malevolent form rears its ugly head. "There's been a lot of security
spending over the last several years, and yet the number of records breached in 2015
went up considerably over the prior year," noted 451's Crawford. "That's contributing
to the surge in interest in encryption."
5 emerging security technologies set to level the battlefield
• Hardware authentication.
• User-behavior analytics.
• Data loss prevention.
• Deep learning.
• The cloud.

4.6 Testing Approach

TESTING PROCEDURES

• Unit Testing: A Unit corresponds to a form/class in the package. Unit testing


focuses on verification of the corresponding form or class. In this level we have
tested all our forms/classes individually. This testing includes testing of control
paths, interfaces, local data structures, logical decisions, boundary conditions,
and error handling. From this testing we were able to save, retrieve, update,
delete and the search records on a table.

• Integration Testing: Integration testing is used to verify the combination of the


software modules. In this level, we have tested by combining all unit tested forms
into a subsystem. Here we found that the subsystems are performing well.

• System Testing: System testing is used to verify, whether the developed


system meets the requirements.

• Acceptance Testing: Acceptance is the part of the project by which the


customer accepts the product. The system under consideration is tested for user
acceptance by constantly keeping in touch with the system users at time of
developing and making changes whenever required.

We hope that after the acceptance testing the system will perform the best result for
the organization. When modification will be made, we will use regression testing
during the maintenance of the system.

The Software System delivered to the customer may undergo changes. Changes may
be due to addition of new functional modules or performance enhancement .For this
purpose proper maintenance of the system is must.

5.3.1 Unit Testing

Test case Ref No TCT-001

Functionality : Log in to the System

Expected outcome : The user should not login to unspecified area


and some error message follow

Step No. Data Used Actual Outcome


1. Click on the log in An alert message came to
button enter
without entering username username
or password
2. Click on the log in An alert message came to
button enter
after entering some password
username leaving password
field blank
3. Click on the log in An alert message came to
button enter
after entering some username
password but leaving
username field blank
4. Click on the log in A message displayed on Log
button in
after entering some page about this
wrong username but
correct password

Test case Ref No TCT-002

Functionality : Enter valid Data for member registration

Expected outcome : The user should not get register any record
without filling all necessary fields and some error
message follow
The user should not get registered again with
same member id

Step No. Data Used Actual Outcome


1. Click on the submit An alert message came to
button each
without entering valid details details and focused on
the respective fields
2. Click on the reset button All the field that are manually
entered will become blank.
After entering member
detail.

Test case Ref No TCT-003

Functionality : Add Payment of particular member

Expected outcome : The user should not add payment of any one
member’s
payment in another’s payment record. Without
filling all necessary fields and some error message
will be followed.

Step No. Data Used Actual Outcome


1. Click on that plan available All the detail of the plan student
from the list that is chosen will be displayed and get focused
by the member for the on the respective fields
payment.
2. Click on the cancel All the field that are manually
button entered will become blank and
will return to the member detail
After entering member
page.
detail.
FUTURE APPLICATION

Software development is never –ending process and continues the life of the
software as per the changing needs of the user from time to time. The project is no
doubt has been developed keeping in mind easy modification and enhancement that
may be required from time to time.

However, there are many scopes to modify this software. As because due to
shortage of time, I here become unable to include many things. I am trying to cover all
their existing system for keeping records of the members enrolls but due to shortage
of time we become unable to include many things. Due to lack of time I here include
none of them and a future scope one can develop these returns which are so much
essential. Only with a little more doing it is possible to design the formats for those
returns. Moreover, an on-line system will be more helpful to the organization. With
almost the same data with only a little modification an on-line system can be designed
to fulfill their demands. All these can be considered to be future scope for this project.
CONCLUSION

After implementing the application it will contain the advantages were


incomparable to the present contemporary systems used by company. The most
admirable feature founded was its simplicity in terms of application to the user but its
highly beneficial outputs can’t be ignored. The users will be highly benefited after
using the system.

It is hoped that this project will help the future developers to modify and
implement the system. After modifying some techniques of the programs, it will give
us the best performance as our requirements. The project will be very useful for the
users.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy