BDMS 1

Government College University Faisalabad.
BLOOD DONATION MANAGEMENT SYSTEM

By
Mariam Murtaza 2017-GCUF-060119

Amna Naseer 2017-GCUF-060227
Mohsin Raza 2017-GCUF-060131
BACHELOR OF SCIENCE
IN
COMPUTER SCIENCE
DEPARTMENT OF COMPUTER SCIENCE

2021
1
ACKNOWLEDGEMENTS
All the praise to Allah, who has blessed us with the courage and knowledge to achieve our
goal. We can never thank Him enough for His countless blessings upon me. Salam to
Prophet Mohammad (S.A.W), who is and will always be a source of guidance and knowledge
for humanity.
For us, a milestone of this nature would never have been possible to achieve without the
support of galaxy of some truly loving and kind people in my life. No words can fully
describe my feelings of respect and gratitude for my affectionate parents, whose love. Their
concern, love and support can never be paid back.
We owe a lot of sincere gratitude to my respected supervisor Mr. Saadullah, whose true
guidance, positive criticism and sincere encouragement made me to get to my destination.
He became a source of inspiration for me and kept me moving in the right direction towards
my goal.
Mohsin Raza
Maryam Murtaza
Amna Naseer
2
DEDICATION
Dedicated to
Beloved Parents,
Respected Teachers
&
Lovely Friends.
3
Contents
ACKNOWLEDGEMENTS ......................................................................................................... 2
DEDICATION............................................................................................................................... 3
CHAPTER 1....................................................................................................................................... 9
1.1 INTRODUCTION ........................................................................................................... 10
1.2 Background ...................................................................................................................... 10
1.3 Purpose ............................................................................................................................ 11
1.4 Scope ............................................................................................................................... 11
1.5 Objective .......................................................................................................................... 12
1.6 Intended Audience and Reading Suggestion ................................................................... 13
1.7 Document Convention ..................................................................................................... 13
CHAPTER 2..................................................................................................................................... 14
2.1 OVERALL DESCRIPTION ......................................................................................................... 15
2.1.1 Product Perspective ...................................................................................................... 15
2.1.2 Product Features ........................................................................................................... 15
2.1.3 Design and Implementation Constraints..................................................................... 15
2.1.4 Assumption and Dependencies ..................................................................................... 15
2.2 SYSTEM FEATURES ................................................................................................................. 15
2.2.1 System Features 1 ......................................................................................................... 16
2.2.2 System Features 2 ......................................................................................................... 17
2.3 EXTERNAL INTERFACE REQUIREMENT ................................................................................. 17
2.3.1 User Interfaces .............................................................................................................. 17
2.3.2 Hardware Interfaces ...................................................................................................... 17
2.3.3 Software Interfaces ....................................................................................................... 17
2.3.4 Communication Interface ............................................................................................. 17
2.4 OTHER NONFUNCTIONAL REQUIREMENT ............................................................................. 18
2.4.1 Performance Requirements........................................................................................... 18
2.4.2 Safety Requirements ..................................................................................................... 18
2.4.3 Security requirements ................................................................................................... 18
CHAPTER 3..................................................................................................................................... 19
3.1 IDENTIFYING ACTORS AND USE CASES USING TEXTUAL ANALYSIS ..................................... 20
3.2 FORMING USE CAS DIAGRAM WITH CANDIDATE AND USE CASES ....................................... 21
3.3 DESCRIBE THE EVENTS FLOW FOR USE CASE ....................................................................... 23
CHAPTER 4..................................................................................................................................... 29
WBS (Work Breakdown Structure) ....................................................................................... 30
4.1 Architecture Diagram ...................................................................................................... 31
4.2 ERD ................................................................................................................................. 32
4.3 Block Diagram ................................................................................................................. 32
4.4 Data Flow Diagram ......................................................................................................... 35
4.5 Class Diagram.................................................................................................................. 32
4.6 Object Diagram................................................................................................................ 32
4.7 Sequence Diagram ........................................................................................................... 32
4.8 Activity Diagram ............................................................................................................. 40
4.9 Collaboration Diagram .................................................................................................... 42
4.10 State Diagram ................................................................................................................ 46
CHAPTER 5..................................................................................................................................... 47
5.1 Component Diagram........................................................................................................ 48
5.2 Deployment Diagram ...................................................................................................... 49
5.3 Database Architecture...................................................................................................... 50
4
CHAPTER 6..................................................................................................................................... 51
6.1 Test Cases Specification .................................................................................................. 54
6.2 Black Box Testing ........................................................................................................... 57
6.2.1 BVA or Boundary Value Analysis .......................................................................... 57
6.2.2 Equivalence Class Partitioning ................................................................................ 58
6.2.3 State Transition Testing ........................................................................................... 60
6.2.4 Decision Table Testing ............................................................................................ 61
6.2.5 Graph Base Testing .................................................................................................. 63
6.3 White Box Testing ........................................................................................................... 65
WHITE BOX TESTING TECHNIQUES ..................................................................................................... 66
6.3.1 Statement Coverage ...................................................................................................... 67
6.3.2 Branch Coverage .......................................................................................................... 69
6.3.3 Path Coverage ............................................................................................................... 72
CHAPTER 7..................................................................................................................................... 76
7.1 PROGRAMMING LANGUAGES ................................................................................................. 77
7.2 OPERATING ENVIRONMENT ................................................................................................... 78
UI(USER INTERFACE) ................................................................................................................... 79
UI(USER INTERFACE) ADMIN PANEL............................................................................................ 86
REFERENCES ............................................................................................................................... 102
5
LIST OF TABLES
Table 1: Use Case Summary .................................................................................................................. 23
Table 2: Use Case Description for Login ................................................................................................ 24
Table 3: Use Case Description for Logout ............................................................................................. 24
Table 4: Use Case Description for a Donor ............................................................................................ 25
Table 5: Use Case Description for Search Blood.................................................................................... 26
Table 6: Use Case Description for Add Donor Record ........................................................................... 27
Table 7: Use Case Description for Update record ................................................................................. 27
Table 8: Use Case Description for Delete records ................................................................................. 28
Table 9: Use Case Description for Search Record .................................................................................. 28
Table 10: Data Dictionary for BDMS Class ............................................................................................ 33
6
LIST OF FIGURES
Figure 1: Use Case Diagram ........................................................................................................ 22
Figure 2 : WBS (Work Breakdown Structure) .............................................................................. 30
Figure 3: Architecture Diagram ................................................................................................... 31
Figure 4: Entity Relationship Diagram ........................................................................................ 32
Figure 5: Block Diagram .............................................................................................................. 34
Figure 6: LEVEL 0 DFD .............................................................................................................. 35
Figure 7: LEVEL 1 DFD .............................................................................................................. 36
Figure 8: Class Diagram .............................................................................................................. 37
Figure 9: Object Diagram ............................................................................................................ 38
Figure 10: Sequence Diagram ...................................................................................................... 39
Figure 11: Activity Diagram for System ....................................................................................... 40
Figure 12: Activity Diagram for Login......................................................................................... 41
Figure 13: Collaboration Diagram for Blood Seeker .................................................................. 43
Figure 14: Collaboration Diagram for Donor ............................................................................. 44
Figure 15: Collaboration Diagram for Admin ............................................................................. 45
Figure: 16: State Diagram............................................................................................................ 46
Figure: 17: Component Diagram ................................................................................................. 48
Figure: 18: Deployment Diagram ................................................................................................ 49
Figure: 19: Database Architecture ............................................................................................... 50
Figure: 20: Black Box Testing ...................................................................................................... 57
Figure: 21: Boundary Value Analysis .......................................................................................... 58
Figure: 22: Equivalence Class Partitioning ................................................................................. 58
Figure: 23: State Transition Graph .............................................................................................. 60
Figure: 24: State Transition Table ............................................................................................... 61
Figure: 25: Graph Base Testing ................................................................................................... 64
Figure: 26: Branch Coverage ....................................................................................................... 69
Figure: 27: Control Flow Graph .................................................................................................. 71
Figure: 28: Path Coverage ........................................................................................................... 72
Figure: 29: Homepage .................................................................................................................. 79
Figure: 30: Homepage .................................................................................................................. 80
Figure: 31: Become a Donor Page ............................................................................................... 81
Figure: 32: Search Blood Page .................................................................................................... 82
Figure: 33: Why Become Donor Page.......................................................................................... 83
Figure: 34: About Page ................................................................................................................ 84
Figure: 35: Contact Page ............................................................................................................. 85
Figure: 36: Admin LOGIN Page .................................................................................................. 86
Figure: 37: Change Page ............................................................................................................. 87
Figure: 38: Admin Dashboard Page ............................................................................................ 88
Figure: 39: Add Blood Group Page ............................................................................................. 89
Figure: 40: Manage Blood Group Page ....................................................................................... 90
Figure: 41: Add Donor Page ........................................................................................................ 91
Figure: 42: Donor List Page ........................................................................................................ 92
Figure: 43: Donor List (Make Hidden) Page ............................................................................... 93
Figure: 44: Donor List (Delete) Page .......................................................................................... 93
Figure: 45: Donor List (Sorting) Page ......................................................................................... 94
Figure: 46: Donor List (Search) Page.......................................................................................... 94
Figure: 47: Donor List (Pagination) Page ................................................................................... 95
Figure: 48: Download Donor List ................................................................................................ 95
7
Figure: 49: Excel File ................................................................................................................... 96

Figure: 50: Manage Contact Queries........................................................................................... 97
Figure: 51: Manage Contact Queries(Read & Pending) ............................................................. 97
Figure: 52: Manage Contact Queries(Sorting) ............................................................................ 98
Figure: 53: Manage Contact Queries(Search) ............................................................................. 98
Figure: 54: Manage Contact Queries(Pagination) ...................................................................... 99
Figure: 55: Manage Pages ......................................................................................................... 100
Figure: 56: Manage Pages(About us & Why Become Donor) ................................................... 100
Figure: 57: Manage Contact Information .................................................................................. 101
8
Chapter 1
Introduction to Problem
9
1.1 INTRODUCTION
Blood is universally recognized as the most precious element that sustains life. It saves
innumerable lives across the world in a variety of conditions. BDMS is a place designed
especially for the people who need blood in emergency situation area wise. The blood
donor information system offers functionalities to quick access to register the donor, and
collected donor details from various parts of the provinces. It enables monitoring of the
results and performance of the blood donation activity such that relevant and measurable
objectives of the organization can be checked. In my system I’m providing the efficient
search who needs the blood in their own city, name, and blood groups as fast as possible.
1.2 Background
Some existing system of blood donation system are manual which cannot upload and
download the latest update and there is no use of web services and remoting. There is no
proper coordination between different systems and users. It consumes lot of manpower for
better results. Retrieval of data takes lot of time and percentage of accuracy is less. It takes
time to produce reports. To debug the existing system, remove procedures those cause data
redundancy, make navigational sequence proper.
The Blood Donor information system is fully computerized system it makes easy to manage
the system by the administrator. And the beginning of this project is research. I mean
researching new things and identify the fact and knowledge about that, focus on the
following areas of study,
Project Documentation
Project Documentation or the Report will give the brief idea about the system which has
been developed by the developers. In the project documentation contain many facts, such
as software development life cycle and each stages, I mean explanation of each stages or
phase and etc.
Software Engineering Principles

• Separation of Concerns
• Modularity
• Abstraction
• Anticipation of Change
• Generality
• Incremental Development
• Consistency
• Information Metrics
10
1.3 Purpose
‘’ Blood Donation Management System” is Web based application project and its purpose is
to simplify and automate the process of searching for blood and maintain the records of
blood donors, recipients, blood donation program and blood stocks in the save life system.
There are lots of communication gap among patients (accepting blood), donors (who donate
bold), blood banks and hospitals in our country. Medical facility is not available equally in
every part of the country. If someone needs blood, first of all he searches it within his family
members, then nearest hospitals and blood banks. If they cannot manage blood in these
ways, it is really hard for them to contact other people to collect blood in a short time. That
is the problem we want to solve through our application, Blood Donation Management
System in which electronic information about the donors and organizations related to
donating the blood is created. Through this application, any person interested in donating
blood can register himself as donor. Moreover if any general consumer wants to make
request to have blood online, he can also take the help of this system.
1.4 Scope
Anyone who has ever done a project will have tales of how scope changes caused grief.
Scope is bound to change, and this is to be expected. As the detail becomes clearer, more
complications creep in. These are not foreseeable at the start and hopefully I build in a
contingency for what we cannot see. The scope changes that usually cause problems are
those where the perception of what was in and out of scope was different between various
parties.
The Scope of the project mean normally expecting the result of something. Scope is same
like the motivation and objectives. But there some more special in this case. Scope is really
expecting, as we take our system, we have to think why we are using computerized system
rather other paper base, and we have to think what purpose of that system.
Why we need computerized system, actually today’s world we can’t maintain or manage the
things without proper system or computer. Now computers are merge with our life. So, the
computer-based systems are very popular, and that’s very secure rather than paper base
system. If we tell one example there were happened a flood disaster, and all the paper-
based records can be Drench to the water. Then we cannot recover the important
information. This kind of situation we can recover the information by using computerized
system. Just remove the hard disk and recover the file easily
11
And security is high, because using computerized system is not allow to use any peoples
without their accounts or authorized permission. So, the paper base is not like that, anyone
can see the information and they can do for that information whatever they want.
As my project also a computerized system called Blood Donor Information System. This
system can be used in the hospitals, blood donor camps, or any other important public
places, and etc.
Blood Donor Information System will be more use full for the important medical places,
because if someone need blood immediately, the system will help to identify the blood
donor, and it will be sending a SMS to that donor. So, it will be making a quick
communication with donors. As I told earlier the purpose of this system is send SMS to the
donors in the critical situation.
My initial thought is that this scope statement completely lacks any of the SMART goal
features. SMART stands for
• Specific
• Measurable
• Agreed Upon
• Realistic
• Time Bound
1.5 Objective
Goals and objectives are statements that describe what the project will accomplish.
Objectives are lower-level statements that describe the specific, tangible products and
deliverables that the project will deliver. Objectives are concrete statements describing
what the project is trying to achieve. The objective should be written at a lower level, so
that it can be evaluated at the conclusion of a project to see whether it was achieved or not.
Goal statements are designed to be vague. Objectives should not be vague. A well-worded
objective will be Specific, Measurable, Attainable/Achievable, Realistic and Time-bound.
Nowadays hackers and intruders are very disturbance for any kind of system, such as
Standalone or Web based Systems. So this system is very secures rather than other systems.
And the earlier day’s hospitals and blood camps were used paper base recording system.
Even though today also they all using Paper recording system. What I’m trying to say is
paper records are not secures, because any one can see the donors personal details without
authorized permission, if any natural disaster happened I mean flood or something
happened then we can’t sure papers are safe in that place. And there are more and more
disadvantages using paper records.
12
If we are using Computerized or Database record will be more secured. Anyone cannot see
or update the records without authorized permission. It will be more useful, and the blood
camp authorized people can handle these problems just simply. Because they all are the
people really going to be use this system. Some main objectives of this project,
• To computerize all details regarding blood donor details & events details.
• To maintain records effectively.
• To manage current blood group of the donors and maintaining new events.
• The project has information regarding the fresh blood donors, already registered
blood donor details, events, creating new events details and sending SMS to already
registered blood donors in the system.
• Creating New Admin for the System, only from admin privilege.
• The valuable data can be kept as secure.
• Creating new events to display about when next blood camp? , and where?
1.6 Intended Audience and Reading Suggestion
This application is made for patients. The stakeholder for this application is admin or a
company an organization that hold the information of patients and donors. The end user for
this application are patients that need the blood.
• Public
• Hospitals
• Blood Banks
1.7 Document Convention
This document will use IEEE format. For clarity, acronyms and technical jargon, deemed
uncommon by the author, will be annotated and included in glossary. The format for
heading is as followed: major headings are in bold 14px font, and concurrent headings are in
bold 12px font.
13
Chapter 2
Software Requirement Specification
14
2.1 Overall Description

2.1.1 Product Perspective
This project has proposed a system which not only maintains the information of blood
banks, but also maintains information of blood camps which makes blood transfusion
process easier. This blood donation management system maintains the list of blood donors
and also helps the recipients to track and search the right donor easily. To provide pure
blood with no wastage blood is been collected in different types of packs. They provide
synchronized and centralized donor and blood stock database. To provide immediate
storage and retrieval of data and information.
2.1.2 Product Features

Through this application, any person interested in donating blood can fill his information
himself as donor. Moreover, if any general consumer wants to make request to have blood
online, he can also take the help of this system. This application would be used by patients.
It is a kind of new capability that users can get blood and information of donor easily.
2.1.3 Design and Implementation Constraints

Software development crew provides their best effort in developing the system. In order to
maintain reliability and durability of system, some design and implementation constraints
are applied. Availability of an android app for Online Blood Donation System could make the
system portable but due to time constraints it is not possible.
2.1.4 Assumption and Dependencies

The System shall take initial load time depending on internet connection strength, which
also depends on the media from which the product is run. The performance shall depend
upon hardware components of the client/applicant. Database connection is required. User
and admin should have a proper user name and password for login. There should be at least
one existing user with active status who can add the all-necessary record. The existing
admin has successfully logged in to the ad panel.
2.2 System Features

The main system features are:
• Login
• Donate
• Request
• Logout
• Contact
15
2.2.1 System Features 1

Login
Admin login and get his respective panels. For login give the name and password.
Search donor
User can search the donor
Add Donor
User and Admin can add donor.
2.2.1.1 Description and Priority

• Information of all blood banks donor details, donate blood with their interest and
others will do in future..
• Interested in donating the blood can register.
• General users want to contact blood donors by checking interested to donate blood,
he can also take they help of this site.
• Rapid response of urgent request for blood components.
• Accessing of immunological compatibility between donor and patient.
2.2.1.2 Stimulus/Response Sequence

• Go to BDMS
• Welcome Screen appears
• Click on “Donate Blood”
• Another Webpage open where a form appears
• Fill all the Personal Information like Name, Father Name, Age, Blood Group, City and
Contact Details.
• Submit the form.
• A message prompt “ You have successfully registered”
2.2.1.3 Functional Requirements

• Login of Admin.
• Blood Donate.
• Change the login password of admin.
• Add the donor by himself.
• Add the donor by system Admin.
• Chane personal, contact details by the system admin.
• Withdraw reg. details by the donor.
• Withdraw reg. details by the admin.
• Send blood donation details to the relevant donors.
• Send blood testing details.
16
2.2.2 System Features 2

There are some features of blood donation management system are:
• Donor database area wise and group wise.

• Maintain and update unique donor identification.
• Improved the Effectiveness and Efficiency of Blood Donation management System
faster response time and better control.
• Accurate database/Record management.
• Blood cross match and result storage facility.
• Rejected donor database for donor control and identifications.
• Comprehensive donor database with search facility.
• Unique donor ID and patient record ID for managing future list.
• Improved processes by providing efficient and continuous software.
2.3 External Interface Requirement

2.3.1 User Interfaces
User interface of my system will be English based. This will allow majority of people to
understand and interact with the system easily. Graphical user interface should be quite
interactive and should be very simple. No special methods and devices should be required
for input and output for the web.
2.3.2 Hardware Interfaces
Monitor screen the software shall display information to the user via the monitor screen,
Mouse the software shall interact with the movement of the mouse and the mouse buttons,
Keyboard-the system shall interact with the keyboard and get data through keyboard.
Tech-pad can be used for data insertion.
2.3.3 Software Interfaces

Blood Donation Management system shall interact with the database in order to get the
information about the system or applicant. It requires internet connection for user.
• Server Side: Apache Server, Windows XP/Vista/2000 and above
• Database Server: MYSQL
• Sublime Text
• Xampp
• XML
• Php
• Html5
2.3.4 Communication Interface

This system provides communication between the Blood Donors and Patients compatibly.
Web based matcher draws up acceptable Blood Donors information for patient by using
17
Knowledge based Rules. Moreover, the Web-based system provides more suitable
application for health care and life saving processes. This system can be extended to other
welfare societies and health organizations. The system would implement a database
interface in the form of queries that would interact with the back-end (database) for
transactions. An OS which is capable of running a modern web browser which supports Php
and HTML5
2.4 Other Nonfunctional Requirement

2.4.1 Performance Requirements
The System shall take initial load time depending on internet connection strength, which
also depends on the media from which the product is run. The performance shall depend
upon hardware components of the client/applicant.
2.4.2 Safety Requirements

Usage of the system should not be harmful for users. System cannot injury to health of the
user.
2.4.3 Security requirements

The system shall be secure for unauthorized user. Every user will be required registration
and correct user name and password to use the system. The purposed system will be design
persistently to avoid any misuse of the application.
18
Chapter 3
Analysis
(Use Case Model)
19
3.1 Identifying Actors and Use Cases using Textual Analysis
Use Case
A use case analysis is the primary form for gathering usage requirements
for a new software program or task to be completed.
Use case plays a significant role in the distinct phases of the Software Development Life
Cycle. Use Case depends on ‘User Actions’ and ‘Response of System’ to the User Actions. It
is the documentation of the ‘Actions’ performed by the Actor/User and the corresponding
‘Behavior’ of the System to the User ‘Actions’. Use Cases may or may not result in achieving
a goal by the ‘Actor/User’ on interactions with the system. In Use Case, we will describe
‘How a System will respond to a given Scenario?’ It is ‘user-oriented’ not ‘system-oriented’.
It is ‘user-oriented’: We will specify ‘what are the actions done by the user?’ and ‘What the
Actors see in a system?’
It is not ‘system-oriented’: We will not specify ‘What are the input given to the system?’
and ‘What are the output produced by the system?’
Benefits of Use Cases

Use cases add value because they help explain how the system should behave and, in the
process, they also help brainstorm what could go wrong. They provide a list of goals and this
list can be used to establish the cost and complexity of the system. Project teams can then
negotiate which functions become requirement and are built.
• Actors
• Admin
Preconditions
• There is an active network connection.
• Application graphical Interface must be available.
Post-conditions
• Successful Completion
Failure Condition
• The logs have been updated accordingly
20
3.2 Forming Use Cas Diagram with Candidate and Use cases
Use Case Model
Use case model consists of three things: actors, use cases, use case diagram.
Actors
An actor is a direct external user of a system, an object or set of objects that communicates
directly with system but that is not part of the system. Each actor represents those objects
that behave way towards the system.
Use Cases
A use case is a coherent piece of functionality that a system can provide by interacting with
various actors. Each use case involves one or more actors as well as the system itself. The
actor needs not all be the persons.
A use case involves a sequence of messages among the system and its actors. Some use
cases have a fixed sequence of messages. More often, however, the message sequence may
have some variations.
Use Case Diagrams
A system involves a set of use cases and a set of actors. Each use case represents a slice of
the functionality the system provides. The set of use cases shows the complete functionality
of the system at some level of detail. Similarly, each actor represents one kind of object for
which the system can perform behavior. The set of actors represents the complete set of
objects that the system can serve. Objects accumulate behavior from all the systems with
which they interact as actors.
The system involves a set of use cases like add record, search record, update record, delete
record and some other mention in use diagram with actors like Administrator and User.
Simply use cases define; in how many ways a system can be used or in how many ways a
system can act. Use cases show the complete functionality of the system that it provides.
Use case diagram is used to capture the dynamic nature of a system. It consists of use cases,
actors and their relationships. It is used at a high-level design to capture the requirements of
a system.
21
Login <<include>> Authentication
Become Donor
Search Blood
Add Blood Group
Manage Blood Group
Add Donor
Manage Contact us
Queties
Manage Pages
Update Contact Info.
Change Password
About Us
Why Become Donor
Contact Us
Logout
Figure 1: Use Case Diagram
22
3.3 Describe the Events Flow for Use case
Use Case Summaries
Login: Admin will be able to login to their respective panel.

Logout: Admin will be able to logout to their respective panel side by pressing the logout button.
Become a donor: User will be able to become a donor.
Search blood: Admin and user will able to search the blood.
Update record: Admin will be able to update data.
Search record: Admin and User will be able to search the record.
Delete record: Admin will be able to delete the record.
Add record: Admin and user will able to add the record.
Contact us: User will be able to contact the admin.
Table 1: Use Case Summary
23
Use Case for Login
Use Case Login

Summery Admin will be able to login to their respective panel side by using his
username and Password.
Actor Admin
Pre-Condition Admin will be able to login to their respective panel to use the website
Description Admin login to their required page in order to perform their task
Exception Wrong username or Password: if the Admin enter the wrong user name or
password the system ask for valid username and password.
Canceled: If Admin press the cancel button instead of login button then login
program will canceled.
Exit: If the Admin press the button exit or ALT+F4 from keyboard during
insertion process without pressing the “login” button system will be closed
and user or admin will not enter to his perspective panel.
Post Condition After successfully login to the system Admin enter into their respective
panels.
Table 2: Use Case Description for Login
Use case for log-out
Use Case Logout

Summery Admin will be able to logout for their respective panel.
Actor Admin
Pre-Condition Admin must be login for their respective panels.
Description Admin logout from their required page in order to close their task.
Exception Exit: If the Register admin press the button exit or ALT+F4 from keyboard
during insertion process without pressing the “sign-out” button. May-be
somebody get access and will damage system.
Post Condition After successfully logout program the system prompted a successfully
message.
Table 3: Use Case Description for Logout
24
Become a donor
Use Case Donor

Summery User will be able to make a donor
Actor User
Pre-Condition The user press Donate Blood.
Description The user will a donor.
Exception Canceled: If the user press the cancel button instead of save button the ad
Generate program will canceled.
Missing filed: If any text box field is empty the system will ask to enter the data
in all mandatory fields.
Exit: If the Register user press the button exit or ALT+F4 from keyboard during
insertion process without pressing the button system will be closed and record
will not be inserted.
Post Condition After successfully become the donor the system prompted a successfully
message.
Table 4: Use Case Description for a Donor
25
Search Blood
Use Case Search blood

Summery User will search the blood.
Actor User
Pre-Condition The user must pressed Search Blood button .
Description The user and admin will search the blood for patients.
Exception Wrong username or Password: If the admin enter the wrong user name or
password the system, ask for valid username and password.
Canceled: If the user presses, the cancel button instead of save button the ad
Generate program will cancel.
Sign out: If the registrar admin press the sign out button the ad generate will
be canceled and the system return to the login page.
Missing filed if any text box field is empty the system will ask to enter the data
in all mandatory fields.
Exit: If the Register admin press the button exit or ALT+ F4, from keyboard
during insertion, process without pressing the “Generate Ad” button system
will be closed and record will not be inserted.
Post Condition After successfully Generate the add system prompted a successfully message.
Table 5: Use Case Description for Search Blood
26
Add Donor
Use Case Add Donor Detail.

Summery Admin will add the record .
Actor Admin
Pre-Condition The admin must be login for add the record .
Description The admin will add the record.
Exception N/A
Post Condition After successfully add the record the system will prompt the successfully
message.
Table 6: Use Case Description for Add Donor Record
Update record
Use Case Update record

Summery Admin will be able to update data.
Actor Admin
Pre-Condition System has some data in system that will be updated if needed.
Description The admin will be able to update data.
Exception N/A
Post After successfully update data the system will prompt the successfully
Condition message.
Table 7: Use Case Description for Update record
27
Delete record
Use Case Delete record

Summery Admin will able to delete the record.
Actor Admin
Pre-Condition The admin must login for delete the record.
Description Admin will delete the record.
Exception Wrong username or Password: If the admin enter the wrong user name or
password the system, ask for valid username and password. And admin will not
enter in his respective panel to view feedback.
Post Condition Admin check user’s experience about his system by their feedback and will be
able to make innovation in his system or to be able to change the things
needed to fulfill user’s requirements.
Table 8: Use Case Description for Delete records
Search Record
Use Case Name: Search record

Summary: User and admin will be able to search the record.
Actor: User and admin

Precondition: System has some record
Description: Users will be able to search the record
Exceptions: If system has no record so admin and user cannot find the record.
Post condition User and admin will easily search the record.
Table 9: Use Case Description for Search Record
28
Chapter 4
Design
29
WBS (Work Breakdown Structure)
1.
BLOOD DONATION MANAGEMENT SYSTEM
1.1 1.2 1.3

ADMINISTRATOR BLOOD DONOR BLOOD SEEKER
1.2.1
1.1.3
1.1.1 1.1.2 1.1.4 Personal Details 1.3.1
MANAGE
AUTHENTICATION MANAGE DONOR MANAGE PAGES SEARCH BLOOD
QUERIES
1.2.2
Contact Detail 1.3.2
1.1.2.1 1.1.3.1 1.1.4.1
1.1.1.1 ADD DONOR READ Edit Blood Group
Login
1.2.3
Blood Group 1.3.3
1.1.2.2 1.1.3.2
1.1.1.2 DELETE DONOR DELETE Location
Logout
1.2.4
Contact 1.3.4
1.1.2.3 Contact with
1.1.1.3 HIDE & PUBLIC Donor
Change Password
1.3.5
Contact with
Admin
Figure 2 : WBS (Work Breakdown Structure)
30
4.1 Architecture Diagram
Figure 3: Architecture Diagram
31
4.2 ERD
Figure 4: Entity Relationship Diagram
32
4.2.1 Data Dictionary
Data dictionary for all modeling elements help designers to understand the meaning and
purpose of all modeling elements. Figure below presents a data dictionary for OBDS classes:
Table 10: Data Dictionary for BDMS Class

Description
Class: A class defines the methods and variables in an object, which is a specific entity in a
program or the unit of code representing that entity.
Notations
Class Name: The name of the class appears in the first partition. For example, Person,
college registers feedback etc.
Class Attributes:
Attributes are shown in the second partition.
The attribute type is can be shown after the colon. But we didn’t show the attribute type.
Attributes map onto member variables (data members) in code.
Class operations or Methods:
Operations are shown in the third partition. For example, College Register () and Send
feedback () etc.
Class Relationships: A class may be involved in one or more relationships with other
classes. A relationship can be one of the following types:
Inheritance (or Generalization):
Represents an "is-a" relationship.
An abstract class (Person) name is shown in italics.
Admin and User are specializations of Person Class.
A solid line with a hollow arrowhead that point from the child to the parent class.
Simple Association:
We used simple association to link the Admin class with the inheritance line to represent
that Admin class are also inheriting the Person Class.
Visibility of Class attributes and Operations
+ denotes public attributes and operation.
- denotes private attributes and operation.
# denotes protected attributes and operation.
~ denotes package attributes and operation.
33
4.3 Block Diagram
ADMIN USER
Donor Requestor
Cloud Server
Blood Donation Management System
Figure 5: Block Diagram
34
4.4 Data Flow Diagram
A data-flow diagram is a way of representing a flow of data through a process or a system.

The DFD also provides information about the outputs and inputs of each entity and the
process itself.
Level 0 DFD
Level 0 DFDs, also known as context diagrams, are the most basic data flow diagrams. They provide a
broad view that is easily digestible but offers little detail. Level 0 data flow diagrams show a single
process node and its connections to external entities.
PERSONAL INFORMATION
DONOR
BLOOD BLOOD INFORMATION
DONATION
ADMIN
RECEIVE REQUEST
MANAGEMENT BLOOD REQUEST

SYSTEM
ADD DONOR
RECEIPT
DONOR INFORATION
Figure 6: LEVEL 0 DFD
35
Level 1 DFD
Level 1 DFDs are still a general overview, but they go into more detail than a context diagram. In a
level 1 data flow diagram, the single process node from the context diagram is broken down into
subprocesses. As these processes are added, the diagram will need additional data flows and data
stores to link them together.
Figure 7: LEVEL 1 DFD
36
4.5 Class Diagram

Class diagrams provide a graphic notation for modeling classes and their relationships
thereby describing possible objects. Class diagrams are useful both abstract modeling and
for designing actual programs. They are concise, easy to understand, and work well in
practice. We will use class diagrams throughout this book to represent the structure of
applications.
Manages
+1....M
ADMIN INVENTORY
DONOR
-adminname: varchar -blood_ID: varchar
-adminpassword: varchar -admin_ID: varchar -name: varchar
-fathername: varchar add to -blood_qty: varchar -email: date
+1...M Donate
-accountdate: date -date: date -age: date
-cnic: varchar +store() -phoneno: varchar
Manages -phoneno: varchar -gender: varchar
-email: varchar -address: varchar
+Login() -bloodgroup: varchar
+Logout() +donate()
+Search()
M...M
+addRecord()
+deleteRecord() 1...1
+managepages()
+update()
+addDonor()
+1...M TESTER
-blood_ID: varchar
BLOOD
-blood_group:varchar
REQUESTOR +test() -bloodquantity: varchar
-bloodgroup: varchar
-bloodgroup: varchar +inventory ()
-address: varchar
+Search()
+requestforblood()
+contact()
M....M
Need
Figure 8: Class Diagram
37
4.6 Object Diagram

We will also occasionally use object diagrams. An object diagram shows individual objects
and their relationships. Object diagrams are helpful for documenting test cases and
discussing examples. A class diagram corresponds to an infinite set of object diagrams.
+1....M
Manages
MOHSIN: ADMIN
INVENTORY
d1: DONOR
-adminname: admin
-adminpassword: 123456 -blood_ID: 001
-fathername: ahmad -admin_ID: A1 -name: Ali
add to -email: abc@gmail.com
-accountdate: 12-oct-2021 -blood_qty: 1 Pack Donate
-cnic: 3530252698987 -date: 12-oct-2021 -age: 21
-phoneno: 03002323323 -phoneno: 03002565656
Manages +store()
-email: admin@gmail.com -gender: male
-address: okara
+Login()
-bloodgroup: O+
+Logout()
+donate()
M...M
+Search()
+addRecord() 1...1
+deleteRecord()
+managepages()
+update() LAB: TESTER
+addDonor()
+1...M
-blood_ID: 001 BLOOD
PERSON: REQUESTOR -blood_group:O+
+test() -bloodquantity: 1 Pack
-bloodgroup: O+ -bloodgroup: O+
-address: Depalpur +inventory ()
+Search()
+requestforblood()
+contact()
M....M
Need
Figure 9: Object Diagram
38
4.7 Sequence Diagram

A sequence diagram shows the interaction of a system with its actors to perform all or part
of use case.
DONOR REQUESTER BDMS ADMIN
Donor userid
Login
Requester userid
Check status Accept / Reject
Request Blood
Status
View Requests
Receipt
View Request
Request Blood Accept / Reject
Check Status
Check Donor Availability
Check Blood Availability
Status
Figure 10: Sequence Diagram
39
4.8 Activity Diagram
Activity Diagram describes the dynamic aspects of the system. Activity diagram is a
flowchart to represent the flow from one activity to another activity. The activity can be
described as an operation of the system. Activity diagrams deal with all type of flow control
by using different elements such as fork, join, etc.
4.8.1 Activity Diagram for system
Figure 11: Activity Diagram for System
40
4.8.2 Activity Diagram for Login
Figure 12: Activity Diagram for Login
41
4.9 Collaboration Diagram
Introduction
A collaboration diagram is an interaction diagram that emphasizes the structural

organization of objects that send and receive messages. It shows a set of objects, links
among those objects, and messages sent and received by those objects. Collaboration
diagram are used to illustrate dynamic view of a system.
➢ Collaboration is described as something that defines a set of participants and

relationships that are meaningful for a given set of purposes.
➢ The collaboration diagram can model interaction at the system, subsystem, and
usecase or operation level.
➢ The stage in the development of the project and the task being undertaken will
determine which is to be modeled
Two levels of Collaboration Diagrams
Collaborations can be modeled at two levels
Specification level
It shows the generic case of collaboration. The diagram shows classifier (class) roles,
association roles and messages.
Instance level
It shows a specific instance of an interaction taking place and involving specific object
instances. The diagram shows objects, links and stimuli.
42
Blood Seeker
Figure 13: Collaboration Diagram for Blood Seeker
43
Blood Donor
Figure 14: Collaboration Diagram for Donor
44
Super Admin
Figure 15: Collaboration Diagram for Admin
45
4.10 State Diagram
A state diagram is a type of diagram used in computer science and related fields to describe
the behavior of systems. State diagrams require that the system described is composed of a
finite number of states; sometimes, this is indeed the case, while at other times this is a
reasonable abstraction. Many forms of state diagrams exist, which differ slightly and have
different semantics.
Figure: 16: State Diagram
46
Chapter 5
Implementation
47
5.1 Component Diagram

Component diagrams are used to visualize the organization of system components and
the dependency relationships between them. They provide a high-level view of the
components within a system.
Figure: 17: Component Diagram
48
5.2 Deployment Diagram

A deployment diagram shows a set of nodes and their relationships. Deployment diagrams
illustrate the static deployment view of architecture. The deployment Diagram describes
how an application is deployed across an infrastructure. It is used to show the distribution of
components, typically across a multi-tier system or the deployment of components around a
heterogeneous environment. In other words, The Deployment diagram shows the physical
configuration of run-time processing components of a distributed system. The intention of
the deployment model is not to describe the infrastructure, but rather the way in which
specific components belonging to an application is deployed across it. Thus, deployment
diagrams act as the link and reference point between how the system is built and where
system components are deployed. For example, a three-tier web application has three
distinct nodes: a frontend web server, an application server, and a database server. There is
also the browser running on an end-user client node.
Figure: 18: Deployment Diagram
49
5.3 Database Architecture
Figure: 19: Database Architecture

In Figure 1, FYP Online Management System architecture is ordered into three tiers: the
user interface in the client browser, the Web server, and the database server [25]. The
functional description of each tier in the system is as follows:
• First Tier: The Interface As viewed from the client’s web browser, the interface is
build by HTML pages with Java Script support.
• Second Tier: Web Server For this system, an Apache web server is used with the PHP
module to support the back ends in third tier. The PHP scripts will process the user
input, generate SQL queries to access the database and then the Apache will compile
and execute the output in dynamically generated HTML pages.
• Third Tier: Database Server In the third tier, the MySQL database server will receives
requests from the second tier to execute SQL statements. The server accesses the
database files to retrieve the stored data and then sends the queried data back.
50
Chapter 6
Testing
(Software Quality Attributes)
51
Testing
Testing is intended to show that a program does what it is intended to do and to discover
program defects before it is put into use. When you test software, you execute a program
using artificial data. You check the results of the test run for errors, anomalies, or
information about the programs non-functional attributes.
The testing process has two distinct goals:
• To demonstrate the developer and the customer that the software meets its
requirements. For custom software, this means that there should be at least one test for
every requirement in the requirements document. For generic software products, it
means that there should be tests for all the system features, plus combination of these
features, that will be incorporated in the product release.
• To discover situation in which the behavior of the software is incorrect, undesirable, or
does not conform to its specification. There are consequences of software defects.
Defects testing is concerned with rooting out undesirable system behavior such as
system crashes, unwanted interactions with other systems, incorrect computations and
data corruption.
Development Testing
Development testing includes all testing activities that are carried out by the team
developing the system. The tester of the software is usually the programmer who developed
that software, although this is not always the case. Some development processes use
programmer/tester pairs (Casamino and Selby, 1998) where each programmer has an
associated tester who develops tests and assists with the testing process. For critical
systems, a more formal process may be used, with a separate testing group within the
development team. They are responsible for developing tests and maintaining detailed
records of test results.
During development, testing may be carried out at three levels of granularity:
• Unit testing
where individual program units or object classes are tested. Unit testing should focus on
testing the functionality of objects or methods.
• Component testing,
where several individual units are integrated to create composite components.

Component testing should focus on testing component interfaces.
52
Unit Testing
Unit testing is the process of testing program components, such as methods or object
classes. Individual functions or methods are the simplest type of component. Your tests
should be calls to these routines with different input parameters.
When you are testing object classes, you should design your tests to provide coverage of all
the features of the object. This means that you should:
• Test all operations associated with the object
• Test and check the value of all attributes associated with the object
• Put the object into all possible states.
This means that you should simulate all events that cause a state change.
Components Testing
Software components are often composite components that are made up of several
interacting objects. For example, in the weather station system, the reconfiguration
component includes objects that deal with each aspect of the reconfiguration. You access
the functionality of these objects through the defined component interface. Testing
composite components should therefore focus on showing that the component interface
behaves according to its specification. You can assume that unit tests on the individual
objects within the component have been completed.
System Testing
System testing during development involves integrating components to create a version of

the system and then testing the integrated system. System testing checks that components
are compatible interact correctly and transfer the right data at the right time across their
interfaces. It obviously overlaps with component testing but there are two important
differences:
During system testing, reusable components that have been separately developed and off-
the-shelf systems may be integrated with newly developed components. The complete
system is then tested.
User Testing
User or customer testing is a stage in the testing process in which users or customers
provide input and advice on system testing. This may involve formally testing a system that
has been commissioned from an external supplier, or could be an informal process where
users experiment with a new software product to see if they like it and that it does what
they need. User testing is essential, even when comprehensive system and release testing
have been carried out. The reason for this is that influences from the user’s working
environment have a major effect on the reliability, performance, usability, and robustness of
a system.
53
6.1 Test Cases Specification
Testing is expensive and time consuming, so it is important that you choose effective unit
test cases. Effectiveness, in this case, means two things:
The test cases should show that, when used as expected, the component that you are
testing does what it is supposed to do. If there are defects in the component, these should
be revealed by test cases. You should therefore write two kinds of test case. The first of
these should reflect normal operation of a program and should show that the component
works. For example, if you are testing a component that creates and initializes a new patient
record, then your test case should show that the record exists in a database and that its
fields have been set as specified. The other kind of test case should be based on testing
experience of where common problems arise. It should use abnormal inputs to check that
these are properly processed and do not crash the component.
6.1.1 Test Case 1: Log In

Test Case ID: 01
Test Case Name: Log in
Test Case Description: This test case will examine login process of admin.
Dependency or Database connection is required.
Prerequisite: Admin should have a proper user name and password for
login.
Expected Input: Valid Username and Password.
Expected flow of Events: Admin enter information. click on “Log In” button.
Alternate flow of Events: System is shut down, leaves some mandatory details missing
or quits the system.
Actual Results: Admin successfully log in and can use system functions
accordingly.
Expected Results: Log in is carried successfully.
Actor: Admin.
Bugs, Errors: None
Estimated time: Less than 1 second.
Table 11: Test Case for Log in
54
6.1.2 Test Case 2: Become a Donor

Test Case ID: 02
Test Case Name: Become a donor
Test Case Description: This case examines the process of register new college.
Dependency or Database connection is required
Prerequisite: There should be at least one existing user with active status who
can add the all-necessary record.
The existing admin has successfully logged in to the ad panel.
Expected Input: Name, Age, Blood Group, Contact, Email, Location, Message
Actual Results: Successfully become a donor.
Expected Results: Successfully become a donor.
Actor: User
Bugs, Errors: None
Table 12: Test Case for Become a Donor
6.1.3 Test Case 3: Search blood

Test Case ID: 03
Test Case Name: Search blood
Description: This case examines the process of searching the blood.
Prerequisite:
Expected Input: Correct detail about blood group.
Expected flow of System is shut down, leaves some mandatory details missing or
Events: quits the system.
Actual Results: Success search the blood
Expected Results: Successfully search the blood.
Actor: User
Bugs, Errors: None
Table 13: Test Case for search blood
55
6.1.4 Test Case 4: Contact us

Test Case ID: 04
Test Case Name: Contact us
Test Case Description: This case can examine the process of contact us.
Prerequisite: The user must be login to administrative panel.
Expected Input: Correct detail.
Expected flow of User check the detail of organization.
Events:
Alternate flow of If the user cannot find the detail. The user cannot contact.
Events:
Actual Results: The user will see the successfully sent message.
Expected Results: Admin enter correct detail.
Actor: User
Bugs, Errors: None
Table 14 :Test Case for Contact us
6.1.5 Test Case 5: Update data

Test Case ID: 05
Test Case Name: Update data
Test Case Description: Admin will update data
Prerequisite: Admin must be log in.
Expected Input: Must enter correct data.
Alternate flow of Admin will close system without pressing save button. Data will
Events: not be updated on dashboard.
Actual Results: The data will be updated successfully.
Expected Results: Update data is correct and updated successfully
Actor: User
Bugs, Errors: None
Table 15: Test Case for update data
56
6.2 Black Box Testing
Black Box Testing is a software testing method in which the functionalities of software
applications are tested without having knowledge of internal code structure,
implementation details and internal paths. Black Box Testing mainly focuses on input and
output of software applications and it is entirely based on software requirements and
specifications. It is also known as Behavioural Testing.
Figure: 20: Black Box Testing

The above Black-Box can be any software system you want to test. For Example, an
operating system like Windows, a website like Google, a database like Oracle or even your
own custom application. Under Black Box Testing, you can test these applications by just
focusing on the inputs and outputs without knowing their internal code implementation.
Consider the following video tutorial-
6.2.1 BVA or Boundary Value Analysis

Boundary Value Analysis (BVA) is a Black-Box testing technique used to check the errors at
the boundaries of an input domain.
The name comes from the Boundary, which means the limits of an area. So, BVA mainly
focuses on testing both valid and invalid input parameters for a given range of a software
component.
If (Min,MAX) is the range given for a field validation, then the boundary values come as
follows:
Invalid Boundary Check { Min-1 ; Max+1 }
Valid Boundary Check {Min; Min+1 ;Max-1;Max }
57
Figure: 21: Boundary Value Analysis

6.2.2 Equivalence Class Partitioning
Equivalence partitioning is also known as “Equivalence Class Partitioning”. In this method,

the input domain data is divided into different equivalence data classes – which are
generally termed as ‘Valid’ and ‘Invalid’. The inputs to the software or system are divided
into groups that are expected to exhibit similar behaviour. Thus, it reduces the number of
test cases to a finite list of testable test cases covering maximum possibilities.
Example: Suppose the application you are testing accept values in the character limit of 1 – 100
only. Here, there would be three partitions: one valid partition and two invalid partitions.
✓ The valid partition: Between 1 & 100 characters.

✓ The expectation is that the text field would handle all inputs with 1-100 characters,
the same way.
✓ The first invalid partition: 0 characters.
✓ When no characters are entered, we’d expect the text field to reject the value.
✓ The second invalid partition: ≥ 101
✓ We’d expect the text field to reject all values greater than or equal to 101 characters
Figure: 22: Equivalence Class Partitioning
EQUIVALENCE PARTITIONING has been categorized into two parts:

1. Pressman Rule.
2. Practice Method.
1.Pressman Rule:
Rule 1: If input is a range of values, then design test cases for one valid and two invalid
values.
58
For example
2.Practice Method:
If the input is a range of values, then divide the range into equivalent parts. Then test for all
the valid values and ensure that 2 invalid values are being tested for.
For example:
Note:
• If there is deviation in between the range of values, then use Practice Method.
• If there is no deviation between the range of values, then use Pressman Rule.
59
6.2.3 State Transition Testing

State Transition Testing is a black box testing technique in which changes made in input
conditions cause state changes or output changes in the Application under Test (AUT). State
transition testing helps to analyse behaviour of an application for different input conditions.
Testers can provide positive and negative input test values and record the system
behaviour.
It is the model on which the system and the tests are based. Any system where you get a
different output for the same input, depending on what has happened before, is a finite
state system.
Example 2:
In the flight reservation login screen, consider you have to enter correct agent name and
password to access the flight reservation application.
Figure: 23: State Transition Graph

It gives you the access to the application with correct password and login name, but what if
you entered the wrong password.
The application allows three attempts, and if users enter the wrong password at 4th
attempt, the system closes the application automatically.
The State Graphs helps you determine valid transitions to be tested. In this case, testing
with the correct password and with an incorrect password is compulsory. For the test
scenarios, log-in on 2nd, 3rd and 4th attempt anyone could be tested.
You can use State Table to determine invalid system transitions.
60
Figure: 24: State Transition Table
In a State Table, all the valid states are listed on the left side of the table, and the
events that cause them on the top.
Each cell represents the state system will move to when the corresponding event
occurs.
For example, while in S1 state you enter a correct password you are taken to state
S6 (Access Granted). Suppose if you have entered the wrong password at first
attempt you will be taken to state S3 or 2nd Try.
Likewise, you can determine all other states.
Two invalid states are highlighted using this method. Suppose you are in state S6
that is you are already logged into the application, and you open another instance
of flight reservation and enter valid or invalid passwords for the same agent.
System response for such a scenario needs to be tested.
6.2.4 Decision Table Testing
Decision Table Testing is a software testing methodology used to test system behavior for
various input combinations. In this systematic approach, the several input combinations and
their corresponding system behavior are represented in tabular form. The decision table is
also called a Cause-Effect table, as the causes and effects for comprehensive test coverage
are captured in this table. Decision Table testing is a commonly used black-box testing
technique and is ideal for testing two or more inputs that have a logical relationship.
61
What is a Decision Table?

A decision table is the tabular representation of several input values, cases, rules, and test
conditions. The Decision table is a highly effective tool utilized for both requirements
management and complex software testing. Through this table, we can check and verify all
possible combinations of testing conditions. The testers can quickly identify any skipped
needs by reviewing the True(T) and False(F) values assigned for these conditions.
A decision table is a tabular representation of inputs vs cases, rules and test conditions.
Example 1:
In this example, we see how to create the decision table for a login screen that asks for
UserId and Password.
The condition here is that the user will be redirected to the homepage if he enters the
correct user name and password, and an error message will be displayed if the input is
wrong.
Conditions Rule 1 Rule 2 Rule 3 Rule 4
Username (T/F) F T F T
Password (T/F) F F T T
Output (E/H) E E E H
Legend:
T- Correct username or password
F- Wrong username or password
E- Error message is displayed.
H – Home screen is displayed.
Decision Table Interpretation:

Case 1: Username and Password both are wrong, and the user is shown an error message.
Case 2: Username is correct, but the password is wrong, and the user is shown an error
message,
Case 3: The username is wrong, but the password is correct, and the user is shown an error
message.
Case 4: Username and password both are correct, and the user is taken to the homepage.
Test Scenarios Possible For This Decision Table:

• Enter correct username, correct password, and click on login. The expected result is that
the user should navigate to the homepage.
• Enter correct username, wrong password, and click on login. The expected result is that
the user should get an error message.
• Enter the wrong username, correct password, and click on login. The expected result is
that the user should get an error message.
62
• Enter the wrong username, wrong password, and click on login. The expected result is
that the user should get an error message.
6.2.5 Graph Base Testing

Graph is one of the most widely used structures for supposition. It is a well-defined
structure which makes the testing or case studies easier. It is considered as an effective way
to determine the systematic test selection of a system. This model is used to represent the
desired information to be captured or collected. Next, the information to be shared is also
presented and easily understood by the testers.
For graph based testing firstly, the tester is asked to collect the data for graph model and
then cover all the elements for a particular graph. In this process of testing, the tester is first
assigned by the responsibility of creating a graph followed by other steps. These are
discussed next.
STEPS FOR GRAPH BASED TESTING INCLUDE :

1. Build the graph model
2. Identify the test/major requirements
3. Select the path to cover those requirements
4. Select the data to be entered
As we know software application is made up of some objects. These objects are identified
and graph is prepared.
It was earlier used for hardware testing but now it is introduced to the software testing.
Various testing methods in the software testing includes: static vs. dynamic testing and the
box approach includes white box testing, black box testing, specification based testing,
visual testing and grey box testing. Cause and effect testing comes under the graph based
testing that forms a part of black box testing. In this type of testing, one can choose the test
case that relates to cause and effect.
Here, cause represents the input condition that gives information about the internal change
in the system whereas effect refers to the output conditions or the transformation of the
system.
THIS GRAPH IS HELPFUL IN CERTAIN CIRCUMSTANCES:

• To determine the present problem so that decision can be taken fast.
• To correlate the factors affecting the system.
• To recognise the main cause of a problem.
Advantages of using cause effect graph are as follows:
63
• It highlights the area from which the data is taken and can be taken for additional
studies.
• It helps in motivating the team.
• The data is arranged in such manner that even a non-technical person can also read it.
• It helps in detecting the reason of differences occurred in a process.
• It helps the team to decide the root reason of a problem.
• It is very appropriate for large systems.
Disadvantages of using cause effect graph are as follows:
• Difficult to design.
• It is difficult to choose the important input in limited time.
• There can be chances where path of drawing the graphs is not clear.
• There are chances of repetition of data already entered in the graph.
It comes under the category of black box testing in software testing. Mostly cause effect
graphs are helpful in testing as they are easy to understand and displays the parameters of
the advantages and disadvantages of a programme. This graph usually shows the nodes
which represent causes on the left side and the nodes representing effects on the right side.
The intermediate nodes present between the effect and cause combines input using the
commonly used logical operators AND/ OR. Constrains can also be added to the causes and
effect sides. These are represented by edges tagged with the constrain symbol using a
dotted line.
Figure: 25: Graph Base Testing
64
6.3 White Box Testing
White Box Testing is software testing technique in which internal structure, design and
coding of software are tested to verify flow of input-output and to improve design, usability
and security. In white box testing, code is visible to testers so it is also called Clear box
testing, Open box testing, Transparent box testing, Code-based testing and Glass box
testing.
It is one of two parts of the Box Testing approach to software testing. Its counterpart,
Blackbox testing, involves testing from an external or end-user type perspective. On the
other hand, White box testing in software engineering is based on the inner workings of an
application and revolves around internal testing.
The term “WhiteBox” was used because of the see-through box concept. The clear box or
WhiteBox name symbolizes the ability to see through the software’s outer shell (or “box”)
into its inner workings. Likewise, the “black box” in “Black Box Testing” symbolizes not
being able to see the inner workings of the software so that only the end-user experience
can be tested.
What do you verify in White Box Testing?

White box testing involves the testing of the software code for the following:
• Internal security holes
• Broken or poorly structured paths in the coding processes
• The flow of specific inputs through the code
• Expected output
• The functionality of conditional loops
• Testing of each statement, object, and function on an individual basis
The testing can be done at system, integration and unit levels of software development.
One of the basic goals of Whitebox testing is to verify a working flow for an application. It
involves testing a series of predefined inputs against expected or desired outputs so that
when a specific input does not result in the expected output, you have encountered a bug.
How do you perform White Box Testing?

To give you a simplified explanation of white box testing, we have divided it into two basic
steps. This is what testers do when testing an application using the white box testing
technique:
STEP 1) UNDERSTAND THE SOURCE CODE

The first thing a tester will often do is learn and understand the source code of the
application. Since white box testing involves the testing of the inner workings of an
65
application, the tester must be very knowledgeable in the programming languages used in
the applications they are testing. Also, the testing person must be highly aware of secure
coding practices. Security is often one of the primary objectives of testing software. The
tester should be able to find security issues and prevent attacks from hackers and naive
users who might inject malicious code into the application either knowingly or unknowingly.
Step 2) CREATE TEST CASES AND EXECUTE

The second basic step to white box testing involves testing the application’s source code for
proper flow and structure. One way is by writing more code to test the application’s source
code. The tester will develop little tests for each process or series of processes in the
application. This method requires that the tester must have intimate knowledge of the code
and is often done by the developer. Other methods include Manual Testing, trial, and error
testing and the use of testing tools as we will explain further on in this article.
White Box Testing Techniques

A major White box testing technique is Code Coverage analysis. Code Coverage analysis
eliminates gaps in a Test Case suite. It identifies areas of a program that are not exercised
by a set of test cases. Once gaps are identified, you create test cases to verify untested
parts of the code, thereby increasing the quality of the software product
There are automated tools available to perform Code coverage analysis. Below are a few
coverage analysis techniques a box tester can use:
Statement Coverage:- This technique requires every possible statement in the code to be
tested at least once during the testing process of software engineering.
Branch Coverage – This technique checks every possible path (if-else and other
conditional loops) of a software application.
66
Apart from above, there are numerous coverage types such as Condition Coverage,
Multiple Condition Coverage, Path Coverage, Function Coverage etc. Each technique has
its own merits and attempts to test (cover) all parts of software code. Using Statement
and Branch coverage you generally attain 80-90% code coverage which is sufficient.
Following are important WhiteBox Testing Techniques:
• Statement Coverage
• Decision Coverage
• Branch Coverage
• Condition Coverage
• Multiple Condition Coverage
• Finite State Machine Coverage
• Path Coverage
• Control flow testing
• Data flow testing
6.3.1 Statement Coverage

Statement coverage is a white box testing technique, which involves the execution of all the
statements at least once in the source code. It is a metric, which is used to calculate and
measure the number of statements in the source code which have been executed. Using
this technique we can check what the source code is expected to do and what it should not.
It can also be used to check the quality of the code and the flow of different paths in the
program. The main drawback of this technique is that we cannot test the false condition in
it.
Source Code Structure:

• Take input of two values like a=0 and b=1.
• Find the sum of these two values.
• If the sum is greater than 0, then print "This is the positive result."
• If the sum is less than 0, then print "This is the negative result."
1. input (int a, int b)

2. {
3. Function to print sum of these integer values (sum = a+b)
4. If (sum>0)
5. {
67
6. Print (This is positive result)

7. } else
8. {
9. Print (This is negative result)
10. }
11. }
So, this is the basic structure of the program, and that is the task it is going to do.
Now, let's see the two different scenarios and calculation of the percentage of
Statement Coverage for given source code.
Scenario 1:
If a = 5, b = 4
1. print (int a, int b) {

2. int sum = a+b;
3. if (sum>0)
4. print ("This is a positive result")
5. else
6. print ("This is negative result")
7. }
In scenario 1, we can see the value of sum will be 9 that is greater than 0 and as per
the condition result will be "This is a positive result." The statements highlighted in
yellow color are executed statements of this scenario.
To calculate statement coverage of the first scenario, take the total number of
statements that is 7 and the number of used statements that is 5.
1. Total number of statements = 7

2. Number of executed statements = 5
68
Statement coverage = 5/7*100

= 500/7
= 71%
6.3.2 Branch Coverage
Branch coverage technique is used to cover all branches of the control flow graph. It covers
all the possible outcomes (true and false) of each condition of decision point at least once.
Branch coverage technique is a whitebox testing technique that ensures that every branch
of each decision point must be executed.
However, branch coverage technique and decision coverage technique are very similar, but
there is a key difference between the two. Decision coverage technique covers all branches
of each decision point whereas branch testing covers all branches of every decision point of
the code.
In other words, branch coverage follows decision point and branch coverage edges. Many
different metrics can be used to find branch coverage and decision coverage, but some of
the most basic metrics are: finding the percentage of program and paths of execution during
the execution of the program.
Like decision coverage, it also uses a control flow graph to calculate the number of
branches. find Nth Highest Salary in SQL
Figure: 26: Branch Coverage
69
How to calculate Branch coverage?
There are several methods to calculate Branch coverage, but pathfinding is the most
common method.
In this method, the number of paths of executed branches is used to calculate Branch
coverage. Branch coverage technique can be used as the alternative of decision coverage.
Somewhere, it is not defined as an individual technique, but it is distinct from decision
coverage and essential to test all branches of the control flow graph.
Let's understand it with an example:
1. Read X
2. Read Y
3. IF X+Y > 100 THEN
4. Print "Large"
5. ENDIF
6. If X + Y<100 THEN
7. Print "Small"
8. ENDIF
This is the basic code structure where we took two variables X and Y and two
conditions. If the first condition is true, then print "Large" and if it is false, then go to
the next condition. If the second condition is true, then print "Small."
70
Control flow graph of code structure
Figure: 27: Control Flow Graph
In the above diagram, control flow graph of code is depicted. In the first case traversing
through "Yes "decision, the path is A1-B2-C4-D6-E8, and the number of covered edges is 1,
2, 4, 5, 6 and 8 but edges 3 and 7 are not covered in this path. To cover these edges, we
have to traverse through "No" decision. In the case of "No" decision the path is A1-B3-5-D7,
and the number of covered edges is 3 and 7. So by traveling through these two paths, all
branches have covered.
Path 1 - A1-B2-C4-D6-E8
Path 2 - A1-B3-5-D7
Branch Coverage (BC) = Number of paths
=2
71
Case Covered Branches Path Branch coverage
Yes 1, 2, 4, 5, 6, 8 A1-B2-C4-D6-E8 2
No 3,7 A1-B3-5-D7
6.3.3 Path Coverage

Path coverage tests all the paths of the program. This is a comprehensive technique which
ensures that all the paths of the program are traversed at least once. Path Coverage is even
more powerful than Branch coverage. This technique is useful for testing the complex
programs.
Path coverage is concerned with linearly independent paths through the code. Testers draw
a control flow diagram of the code, such as the example below.
Figure: 28: Path Coverage

Control flow diagram used to design tests in a path coverage approach
72
In this example, there are several possible paths through the code:
• 1, 2
• 1, 3, 4, 5, 6, 8
• 1, 3, 4, 7, 6, 8
• etc.
In a path coverage approach, the tester writers unit tests to execute as many as possible of
the paths through the program’s control flow. The objective is to identify paths that are
broken, redundant, or inefficient.
Scenario 1:
As said earlier, Path coverage is used to test the complex code snippets, which basically
involve loop statements or combination of loops and decision statements.
Consider this pseudocode:

INPUT A & B
C=A+B
IF C>100
PRINT “ITS DONE”
END IF
IF A>50
PRINT “ITS PENDING”
END IF
Now to ensure maximum coverage, we would require 4 test cases.
How? Simply – there are 2 decision statements, so for each decision statement, we would
need two branches to test. One for true and the other for the false condition. So for 2
decision statements, we would require 2 test cases to test the true side and 2 test cases to
test the false side, which makes a total of 4 test cases.
To simplify these let’s consider below flowchart of the pseudo code we have:
73
In order to have the full coverage, we would need following test cases:
TestCase_01: A=50, B=60

So the path covered will be:
74
Red Line – TestCase_01 = (A=50, B=60)
Blue Line = TestCase_02 = (A=55, B=40)
Orange Line = TestCase_03 = (A=40, B=65)
Green Line = TestCase_04 = (A=30, B=30)
75
Chapter 7
Tools and Technologies
76
7.1 Programming Languages
Front-End:
✓ HTML
✓ CSS
✓ Bootstrap
✓ JQuery
✓ JS
Back-End:
✓ PHP
Database
✓ MYSQL
77
7.2 Operating Environment
Visual Studio Code

Introduced by Microsoft Corporation.
Help to Develop Software and Systems according to the requirements.
Microsoft Word 2019

- Introduced by Microsoft Corporation.
- Help to create reports and documents
Microsoft Visio
- Help to draw the software related diagrams.
Microsoft SQL Server

- Used to manage the data called database management system (DBMS).
Adobe Photoshop
- Introduced by Adobe.
- Help to create nice artistic, and editing works.
Web Browser (Google Chrome, Opera Mini)

- I have used Google Chrome and Opera Mini to browse the facts in the internet
78
Appendix A: User Documentation
BDMS Site Structure
First, when a user types the URL of BDMS, the landing page would be the home of BDMS. In
this page, there is header, slider, and some other details which will be updated.
UI(User Interface)
❖ Home / Landing Page:
Figure show the home or landing page of BDMS. However there will be some modification
later. There will be Navbar and multiple menus like: Search Blood, Donate Blood, About,
Contact which are set by Administrator. The latest announcement will be accessible by
committee of BDMS for them to put anything up.
Figure: 29: Homepage
79
❖ Home / Landing Page:
Figure show the home or landing page of BDMS. After scroll down Donors list will shown on
home screen also, which only include name and Blood Group. Further details can be access
from search blood page.
Figure: 30: Homepage
80
❖ Become a Donor Page:
Figure show the page where a user can donate his blood. Donor should have to fill form in
which following fields are required:
• Full Name
• Mobile No
• Email ID
• AGE
• Gander
• Blood Group
• Address
• Message
Figure: 31: Become a Donor Page
81
❖ Search Blood Page:
Figure show the page where a user who need blood can contact to donor. Donor details of
same blood group persons will be shown on screen. Requestor need to input:
• Blood Group
• Location
Figure: 32: Search Blood Page
82
❖ Why Become Donor Page:
Figure show the page where a user can see motivational lines about “Why Donate Blood”.
So the access to show the page is owned by Administrator. It only can be edited by Admin.
Figure: 33: Why Become Donor Page
83
❖ About Page:
Figure show the page where the data about organization and all the staff shown. So the
access to show the page is owned by Administrator. It only can be edited by Admin.
Figure: 34: About Page
84
❖ Contact Page:
Figure show the page where the form appears. From this page user can send queries /
message to admin, which will respond back by Admin. This form required fields:
• Full Name
• Phone No
• Email
• Message
Figure: 35: Contact Page
85
UI(User Interface) Admin Panel
BDMS Admin Side Interface
First, when a Admin types the URL of BDMS, the landing page would be the home of BDMS.
❖ Login Form:
It is authenticated by username and password as shown in Figure. Administrator will

determine the access level of user with their respective ID in the database. User credentials
are kept in database in secured manner.
Form Validation is also applied on this Form.
Figure: 36: Admin LOGIN Page
86
❖ Change Password:
After login, authenticated admin will be redirected to change password page as Figure 6.
From there you can change your password or you can also skip it. This function is enabled
for the user to change the password if needed.
Figure: 37: Change Page
87
❖ Admin’s Dashboard:
After login, authenticated user will be redirected to dashboard page as Figure which acts as
admin’s main navigation page. There would be several interfaces for different user
depending on the access level. This interface have many functionalities in the sidebar.
▪ Dashboard
▪ Blood Group
▪ Add Donor
▪ Donor List
▪ Manage Contact Queries
▪ Manage Pages
▪ Update Contact Info.
Figure: 38: Admin Dashboard Page
Dashboard have three functionalities on screen.
➢ Listed Blood Groups

When we click it will redirect to Fig
➢ Registered Blood Group
➢ Total Queries
88
❖ Blood Group:
Under the Dashboard menu, there is Blood Group menu shown. Click on this, two options
appears:
▪ Add Blood Group

▪ Manage Blood Groups
1) Add Blood Group
When admin click on Add Blood Group, a form field appear. In input field we insert
Blood Group. This page is linked with Manage Blood Group page.
Figure: 39: Add Blood Group Page
89
2) Manage Blood Group
When admin click on Manage Blood Group, all Listed Blood Groups list appear which
was inserted by Add Blood Group function in Fig
Any Entity also can be removed from the Action column.
Figure: 40: Manage Blood Group Page
Functionalities:
➢ Sorting
➢ Searching
➢ Pagination
90
❖ Add Donor:
We have seen that a Donor enter his/her detail himself. But Admin also can input details
of Donor by clicking “Add Donor” function.
A form appears where all basic information will be insert like:
• Full Name
• Mobile no
• Email ID
• Age
• Gender
• Blood Group
• Address
• Message
Figure: 41: Add Donor Page
After submission it all the information will stored in Donor List Fig .
91
❖ Donor List:
All the Donor’s data will be shown in the form of table. (Rows & Columns)
A table include:
• Serial no
• Name
• Mobile no
• Email
• Age
• Gender
• Blood Group
• Address
• Message
• Action
Figure: 42: Donor List Page
Functionalities:
➢ Make Hidden
Admin can hide the details from user by simply click “Make Hidden” and then he
details of that donor will hide from user side. And a message appears “Booking
successfully canceled”.
After that when admin want, he can make “public again”.
92
Figure: 43: Donor List (Make Hidden) Page
➢ Delete
Admin can permanently delete the details from user by simply click “Delete” and
then the data of that donor will delete permanently. And a message appears “Record
Deleted Successfully”
Figure: 44: Donor List (Delete) Page
93
➢ Sorting
Admin can sort the details of donors by every entity individually by clicking double
arrow icon.
Figure: 45: Donor List (Sorting) Page
➢ Search
Admin can search the donor from search box. Admin can:
• Search by Serial No.
• Search by Name
• Search by Email
• Search by Mobile no
• Search by age
• Search by gender
• Search by blood group
• Search by address
• Search by message
Figure: 46: Donor List (Search) Page
94
➢ Pagination
All the data of donor data shown in a sequence of pages which are connected and
have similar content.
Figure: 47: Donor List (Pagination) Page
➢ Donor List Report

Admin can also download the totals no. of Donors in the form of Excel File by simply
clicking “Download Donor List”.
Figure: 48: Download Donor List
95
✓ After clicking “Download Donor List”, file will start download Excel File.
✓ Open this file with MS Excel.
Figure: 49: Excel File
❖ Manage Contacts Queries:
All the queries which are performed by users will show here in the form of table (rows &
columns).
A table include:
• Serial no
• Name
• Mobile no
• Email
• Message
• Posting Date
• Action
96
Figure: 50: Manage Contact Queries
Functionalities:
➢ Read, Pending and Delete

In action column there is option of Pending and Read. If the response of query given
the click on pending it will show Read. But if Admin want to delete the query
permanently then there is a option to delete the query permanently.
Figure: 51: Manage Contact Queries(Read & Pending)
97
➢ Sorting
Admin can sort the details of queries by every entity individually by clicking double
arrow icon.
Figure: 52: Manage Contact Queries(Sorting)
➢ Search
Admin can search the queries from search box. Admin can:
• Search by Serial No.
• Search by Name
• Search by Email
• Search by Mobile no
• Search by message
• Search by date
Figure: 53: Manage Contact Queries(Search)
98
➢ Pagination
All the data of user queries data shown in a sequence of pages which are connected
and have similar content.
Figure: 54: Manage Contact Queries(Pagination)
❖ Manage Pages:
Admin can edit or delete the content of pages which are displayed on user side:
• About
• Why Become Donor
99
Figure: 55: Manage Pages
Figure: 56: Manage Pages(About us & Why Become Donor)
100
❖ Manage Contact Info:
Admin can edit the contact information, which include:
• Address
• Email ID
• Contact Number
Figure: 57: Manage Contact Information
101
References
102

BDMS 1

Uploaded by

Document Information

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

BDMS 1

Uploaded by

Copyright:

Available Formats

Government College University Faisalabad.

BLOOD DONATION MANAGEMENT SYSTEM

Mariam Murtaza 2017-GCUF-060119

DEPARTMENT OF COMPUTER SCIENCE

Figure: 49: Excel File ................................................................................................................... 96

Software Engineering Principles

1.6 Intended Audience and Reading Suggestion

1.7 Document Convention

Software Requirement Specification

2.1 Overall Description

2.1.2 Product Features

2.1.3 Design and Implementation Constraints

2.1.4 Assumption and Dependencies

2.2 System Features

2.2.1 System Features 1

User can search the donor

User and Admin can add donor.

2.2.1.1 Description and Priority

2.2.1.2 Stimulus/Response Sequence

2.2.1.3 Functional Requirements

2.2.2 System Features 2

• Donor database area wise and group wise.

2.3 External Interface Requirement

2.3.3 Software Interfaces

2.3.4 Communication Interface

2.4 Other Nonfunctional Requirement

2.4.2 Safety Requirements

2.4.3 Security requirements

3.1 Identifying Actors and Use Cases using Textual Analysis

Benefits of Use Cases

Use Case Model

Use Case Diagrams

Login <<include>> Authentication

Add Blood Group

Manage Blood Group

Update Contact Info.

Why Become Donor

Figure 1: Use Case Diagram

3.3 Describe the Events Flow for Use case

Use Case Summaries

Login: Admin will be able to login to their respective panel.

Table 1: Use Case Summary

Use Case for Login

Use Case Login

Table 2: Use Case Description for Login

Use case for log-out

Use Case Logout

Table 3: Use Case Description for Logout

Use Case Donor

Description The user will a donor.

Table 4: Use Case Description for a Donor

Use Case Search blood

Table 5: Use Case Description for Search Blood

Use Case Add Donor Detail.

Table 6: Use Case Description for Add Donor Record

Use Case Update record

Table 7: Use Case Description for Update record

Use Case Delete record

Table 8: Use Case Description for Delete records

Use Case Name: Search record

Actor: User and admin

Description: Users will be able to search the record

Table 9: Use Case Description for Search Record