Sad Assginment

Web based blood bank management system for Bale
Robe
UNIVERSITY OF MADDA
WALABU
DEPARTEMENT OF INFORMATION TECHNOLOGY

WEB BASED BLOOD BANK MANAGEMENT
SYSTEM FOR BALE ROBE BLOOD BANK
INDUSTRIAL PROJECT BY
NAME ID NUMBER
ASHENAFI ABERA UGR/21237/13
YESHANEBAL GEBRE UGR/3864/08
AHMED MOHAMED UGR/1511/07

Web based blood bank management system for Bale
Robe
SHANKORE SHODE UGR/22527/13
MESAFINT DESELAGN UGR/22182/13
PROJECT ADVISOER:MIS.CHALA
DATE 30/06/2015
1
Web based blood bank management system for Bale Robe
Declaration
This is to declare that the project work which is done under the advisor of MIS
SAMIRAWIT DEGU and having the title of Bale Robe Blood Bank Management System is
developed under the sole contribution of:
NAME ID
ASHENAFI ABERA UGR/21237/13
YESHANBEL GEBRIE UGR/22783/13
AHMED MOHAMED UGR/21108/13
SHANKORE SHODE UGR/22527/13
MESAFINT DESELAGN UGR/22182/13
No part of the project work has been reproduced illegally (copy and paste) which can be
considered as Plagiarism. All referenced parts have been used to argue the idea and cited
properly. We will be responsible and liable for any consequence if violation of this declaration is
proven. Date:30/06/2015
i
Certificate
I certify that this BSc industrial project entitled web based blood bank management system for
Bale Robe blood bank written by:
Yeshanbal Gebre
Hawa Gesit
Gebremichael Birhanie
Besufikad Girema
Adem Mekonnen
Fentaw Kassie
Beletech Ambachew
is approved by me for submission. I certify further that, to the best of my knowledge, the project
represents work carried out by the students.
Date Name and Signature Of Supervisor
ACKNOWLEDGMENT
First and for most and above all our biggest thanks goes to “GOD” because
nothing could be possible without his free will , keep our safe, Give power and energy and help
us to finish this project successfully. Secondly we would like to express our deepest appreciation
and Thanks to our adviser M.S Samrawit Degu for her advice and constrictive commit in our
project what we have to do timely and efficiently. And thirdly we would like to thank Computer
science academic staff for their guide line preparation which help us as framework to develop
our project and lastly our thanks goes to Mr.Demeke Tilahun North Gondar blood bank manager
who provide the necessary information, encouragement and comments .
ii
iii
Web based blood bank management system for north 2019
Gondar
Table of Contents
Declaration...................................................................................................................................................
Certificate....................................................................................................................................................
ACKNOWLEDGMENT............................................................................................................................
ACRONYMS.................................................................................................................................................
CHAPTER ONE.........................................................................................................................................
1. INTRODUCTION..................................................................................................................................
1.1. Background......................................................................................................................................
1.2. Statement of the problem.................................................................................................................
1.3. Objective of the project....................................................................................................................
1.3.1. General objectives.....................................................................................................................
1.3.2. Specific objective......................................................................................................................
1.4. Scope of the project..........................................................................................................................
1.5. Limitation of the project...................................................................................................................
1.6. Methodology....................................................................................................................................
1.6.1. System development methodology............................................................................................
1.6.2. Investigation (fact-finding) methods.........................................................................................
1.6.2.1. Observation............................................................................................................................
1.6.2.2 Interview:................................................................................................................................
1.6.2.3. Document analysis:................................................................................................................
1.6.3. Tools used to develop the system..............................................................................................
1.7. Significance of the project................................................................................................................
1.8. The Beneficiaries of the system.......................................................................................................
1.8.1. Blood donors.............................................................................................................................
1.8.2. Blood seeker (seekers and clinic)..............................................................................................
1.8.3. Blood bank organization...........................................................................................................
1.8.4. Project team members...............................................................................................................
1.9. Feasibility study...............................................................................................................................
1.10. Technical Feasibility..................................................................................................................
1.11. Operational Feasibility...............................................................................................................
1.12. Economic Feasibility......................................................................................................................
v
Gondar
1.13. Legal feasibility.............................................................................................................................

1.14 Time schedule................................................................................................................................
2 REQUIREMENT ANALYSIS..............................................................................................................
2.1 Introduction.....................................................................................................................................
2.2. Current system...............................................................................................................................
2.2.1. Major function of the current system.......................................................................................
2.2.2. Problem of the current (existing) system.................................................................................
2.3. Requirement gathering...................................................................................................................
2.3.1. Requirement Gathering Methodologies...................................................................................
2.3.1.3. Document analysis:..............................................................................................................
2.3.2. Result found............................................................................................................................
2.4. Business rule..............................................................................................................................
2.5. Proposed system.............................................................................................................................
2.5.1. Overview.................................................................................................................................
2.5.2. Functional requirements..........................................................................................................
2.5.3. Non functional requirement.....................................................................................................
2.6. System model.................................................................................................................................
2.6.2 Use Case Modeling..................................................................................................................
2.6.3. Activity Diagram.....................................................................................................................
2.6.4. Object model...........................................................................................................................
2.6.5. Dynamic modeling..................................................................................................................
2.7 User Interface..................................................................................................................................
CHAPTER THREE..................................................................................................................................
3. SYSTEM DESIGN...............................................................................................................................
3.1 Introduction.....................................................................................................................................
3.2 Design goal.....................................................................................................................................
3.3 Current software architecture..........................................................................................................
3.4. Proposed software architecture......................................................................................................
3.4.1. Overview.....................................................................................................................................
3.4.2. Subsystem decomposition.......................................................................................................
3.4.3 Hardware and Software Mapping.............................................................................................
vi
Gondar
3.4.4 Persistent Data Management....................................................................................................

3.4.5 Access control and security......................................................................................................
3.4.7 Detailed Class Diagram............................................................................................................
3.4.8 Package Diagram.....................................................................................................................
CHAPTER FOUR.....................................................................................................................................
IMPLEMENTATION...............................................................................................................................
4.1 MAPPING MODELS TO CODE...................................................................................................
4.1.1.Bidirectional One-to-One Associations....................................................................................
4.1.2.One-to-Many Associations.......................................................................................................
4.1.3 Many-to-Many Associations....................................................................................................
4.2.Mapping the Class Model to a Storage Schema Is Performed......................................................
4.3.SOURCE CODES FOR MAJOR CLASSES, PACKAGES OR INTERFACES.............................
Conclusion and Recommendation............................................................................................................
GLOSSARY.............................................................................................................................................
REFERENCE...........................................................................................................................................
List of Table
Table 2-1 Table for Login description ...................................................................................................... 24
Table 2-2 Table for post information description .................................................................................... 25
Table 2- 3 Table for view report description ........................................................................................... 25
Table 2-4 Table for approve description ................................................................................................. 26
Table 2-5 for view Feedback description ................................................................................................ 27
Table 2-6 for Blood seeker registration description ................................................................................. 28
Table 2-7 Table for manage account ....................................................................................................... 29
Table 2-8.Table for generate report description ....................................................................................... 30
Table2-9 Table for give feedback description ......................................................................................... 31
Table 2-10 Table for blood request description ....................................................................................... 32
Table 2-11 Table for donor registration description ................................................................................ 33
Table 2-12 Table for donation request description .................................................................................. 34
Table 2-13 Activity diagram description ................................................................................................. 35
Table 2-14 Attribute description for admin ............................................................................................. 42
Table 2-15 Attribute description for Nurse.............................................................................................. 42
Table 2-16 Attribute description for Blood donor ................................................................................... 42
vii
Gondar
Table2- 17.Attribute description for Lab technician ................................................................................ 43

Table 2-18. Attribute description for Blood information ......................................................................... 43
Table 2-19 Attribute description for Seeker ............................................................................................ 43
Table 2-20 Attribute description for report.............................................................................................. 43
Table 2-21 Attribute description for Request .......................................................................................... 44
Table 2-22 Access control and security........................................................ Error! Bookmark not defined.
Table 2-23 Table of Glossary ................................................................................................................. 85
List of figure
Figure 1. 1 Time Schedule ........................................................................................................... 9
Figure 2- 1 Use case diagram for north Gondar blood bank management system........................ 22
Figure 2- 2 Activity diagram for login ....................................................................................... 36
Figure 2- 3 Activity diagram for generate report ....................................................................... 37
Figure 2- 4 Activity diagram for register.................................................................................... 38
Figure 2- 5 Activity diagram for create account ......................................................................... 38
Figure 2- 6 Activity diagram for post information ...................................................................... 39
Figure 2- 7 Activity diagram for send blood request .................................................................. 39
Figure 2- 8 Activity diagram for view report.............................................................................. 40
Figure 2- 9 Activity diagram for register blood .......................................................................... 40
Figure 2- 10 Activity diagram for donation request .................................................................... 41
Figure 2- 11 Class diagram ....................................................................................................... 44
Figure 2- 12 Sequence diagram for login .................................................................................. 45
Figure 2- 13 Sequence diagram for View blood ........................................................................ 46
Figure 2- 14 Sequence diagram for request blood ..................................................................... 47
Figure 2- 15 Sequence diagram for Create account .................................................................... 48
Figure 2- 16 Sequence diagram for give Donor registration ...................................................... 49
Figure 2- 17 Sequence diagram for view report......................................................................... 50
Figure 2- 18 State chart diagram for Login ................................................................................ 51
Figure 2- 19 State chart diagram for Seeker registration ............................................................ 52
Figure 2- 20 State chart diagram for Seeker registration ............................................................. 52
Figure 2- 21 State chart diagram for Seeker registration ............................................................. 53
Figure 2- 22 User interface for login .......................................................................................... 54
Figure 2- 23 User interface for Home page ............................................................................... 55
Figure 2- 24 User interface for Donor registration..................................................................... 56
Figure 3- 1 System architecture model for proposed system ...................................................... 59

Figure 3- 2 Component Diagram for blood bank management subsystem ................................... 61
Figure 3- 3 Deployment diagram ................................................................................................ 62
Figure 3- 4 Object diagram for North Gondar blood bank management system ..........................
63 Figure 3- 5 Component diagram for subsystem service ...............................................................
viii
Gondar
65 Figure 3- 6 Detailed class diagram .............................................................................................

66 Figure 3- 7 Package diagram .....................................................................................................
67
ACRONYMS
BBMS:Blood bank management system
BG: Blood Group
BR: Business Rule
CPU: Central Processing Unit
CSS: Cascading Style Sheet
DB: Database
EXP_DATE: Expired date
HTML: Hypertext markup Language
HW: Hardware
INFO: Information
MS: Microsoft
NBBS:National blood bank service
NGBB: North Gondar Blood Bank
OOSD: Object Oriented System Analysis and Design
OS: Operating System
PHP: Hypertext Preprocessor
RAM: Random Access Memory
ix
Gondar
REQ: Requirement
SDD: System Design Document
SPMP: Software Project Management Plan
SQL: Structured Query Language
SRS: Software Requirement Specification
STD: Software Test Documentation
SW: Software
UI: User Interface
x
Gondar
ABSTRACT
The main objective of this project is developing a web based blood bank management system to
North Gondar Blood bank.A blood bank information management system holds information
about blood groups, blood donors and keeps samples of blood gathered as a result of blood
donation. However, the current system is limited on manual work. This has limitation on
controlling the work securely, for declaring the result on time, and has high consumption on
resources.Web based Blood Bank management System is an online portal to facilitate the co-
ordination between supply and demand of blood. The whole purpose of the project is bringing
an online edge for blood donors, blood Seekers and also to create an interactive way of bringing
the Blood donors and Blood Seeker. The system gives a lot of information about Blood groups,
donation methods, frequency of blood donation and the details of the coming blood donation
camps. Besides, extra features in the system such as security protection by using password,
Generating reports, reminders of blood stock shortage and workflow tracking can even enhance
the efficiency of the management in the blood banks. The methodology that we use to develop
the system is object oriented specifically iterative technique.
Key words: blood, stock,blood donation,Donor,Seeker
xi
Gondar
CHAPTER ONE
1. INTRODUCTION
1.1. Background
Blood is a specialized body fluid in humans that delivers necessary
substance such as nutrients and oxygen to the cell and transport metabolic
waste product away from cells. Human blood is an element of human life
[1]. The national blood bank service of
Ethiopia’s (NBBS) was established in1969 by Ethiopian Red Cross society but
since 2004 has been known by the federal ministry of health Ethiopia [2]. Its
main center is located in Addis Ababa and it has also the responsibility to
oversee, support and monitor the activities of regional blood bank in the
country which are administratively under their respective regional health
bureaus. The national blood bank service of Ethiopia (NBBS) mission is to
ensure the availability of safe and adequate supply of blood and blood
products to all transfusion health facility in Ethiopia. The NBBS office is non-
profit governmental organization established with core community
mobilization and education on voluntary blood donation, blood collection
laboratory processing, testing and production of blood.
Blood bank is one of the important departments. It plays an important role

with blood collection and issue of blood components. Its activities include
blood donation, blood grouping, antibody screening, antibody identification,
blood infectious test, issuing compatible blood and blood component etc
[8].
North Gondar blood bank is one of these and it was established by the Red
Cross association this organization provide blood for 10 seekers and 3 clinic.
These clinic and seekers received blood by fulfilling certain forms and
getting permission from Lab technician. The organization passed several
12
Gondar
obstacle in case of creating awareness and also during the starting stage
there is lack of blood and impossible to give the required service. This
organization was begun by giving small capacity of blood service. The aim of
the organization is to provide efficient service to user increase the capacity
of providing blood to the recipient, to increase the number of blood donor
by creating awareness about blood donation to the society.
1.2. Statement of the problem

In the current system the activities such as documenting, finding and
searching of specific information is done manually. Employee cannot
perform their activity like, donor registration. Because of the absence of
permanent storage or central DB that each process or workflow cannot
traced from database, it is hard to give Feedback about blood bank service,
it is tedious for blood seeker to search the required blood type in case of
emergency, lack of smooth interaction between donor and blood bank,lack
of security, Difficult to know amount of blood in stock,Error handling is not
efficient, Difficult to know fit blood during blood transfusion service, difficult
to prepare organized report, difficult to prepare organized report and it is
difficult to see the availability blood in the stock. This type of system leads
to the documenting of erroneous and redundant information. The current
system consumed the time and cost of user even to complete specific task.
The medium used to inform the staff about the schedule of the month using
whiteboard and written whiteboard marker, these leads the written
schedule become unclear. So, because of these and other problem we are
initiated to do this project.
1.3. Objective of the project
In this section we discuss about the objective that we went to accomplish at

the end of this project.
13
Gondar
1.3.1. General objectives
The main objective of this project is to change the manual system of North
Gondar blood bank into computerized system.
1.3.2. Specific objective

To achieve the general objective mentioned above we should consider the
following specific objectives:
 Analyzing the current manual system.
 Implementing the proposed new system
 Design interactive user interfaces for the North Gondar blood bank
management system to users.
 Testing the new system and make the required modification.
1.4. Scope of the project

The scope of this project only lies within the time frame given to us at the
current moment. So our project scope is limited on:
 Create account for users.

 Post and retrieve general report.
 The administrator sends message to donor when the time they
donate blood is reached.
 Advertizing the organization service.
 Show available blood online with their type.
 Provide secured and authorized feature to the system where private
and confidential data can only be viewed and updated by authorized
user.
 Facilitate or improve the information shared between the user and
the organization.
 User can provide Feedback to the organization about the service
they provide.
 Avoiding redundant and erroneous data.
 Record blood details and blood donation.
14
Gondar
 Manage the collected blood data.
 Record blood details with their expired date.
1.5. Limitation of the project

 Our project is limited on the allocated time
1.6. Methodology
In this section we are going to discuss about system development
methodology that we follow to develop our system and the method we
used to collect data.
1.6.1. System development methodology

In this project the team members decide to use object oriented system
analysis and design to develop our system because of the following reason:
 It can be easily maintained

 It support the design and representation of the system using UML
diagram like, use case, sequence and activities.
 It allows to break down complicated system into smaller, clear and
more manageable part;
 Increase extensibility: means make modification on some part of

the code will not affect the other.
 It facilitate change in the system at low cost
 Increase reuse of component: - the object oriented provides
opportunities for reuse of code or component through the concepts
of inheritance, polymorphism, and encapsulation.
 Fastest development
 Increase quality
 It makes our system more usable and more productive
One of the approaches in object oriented technique that we used to

develop our system is iterative. Because it used as fast development and
15
Gondar
delivery of high quality system at relatively low cost. We improve the sub
system until the complete version is reached.
1.6.2. Investigation (fact-finding) methods

The method we employed in the data collection are observation, interview,
analysis of document that is directly related with this blood bank
organization also we have used Google search.
1.6.2.1. Observation:
Is one of the data collection method and all the team members are tried to
observe and understand the actual workflow or event performed in the
current system. During observation we saw many paper and document that
store the information and also we saw that different notification posted on
the notice board in the blood bank.
1.6.2.2 Interview:
This is one of the methods used for collecting data through direct
communication. So, the team member collects important information by
raising different questions for the staff member of this blood bank
organization in order to know how the existing system works.
1.6.2.3. Document analysis:

Another way that we used to collect data is document analysis. We read
written documents which are the existing system currently uses, to know
rules, regulation and constraints in the existing system that can be used to
design the new system..
1.6.3. Tools used to develop the system

To develop our system we are going to use different tools.
Hardware tools:
 Personal computer (PC):- For every activity of the project.

 Flash disc: - to store files.
 Digital camera: - to capture pictures which are necessary for
developing the website.
16
Gondar
 Printer:- to print the document
Software tools:
We will use the following tools to develop the web based system:
 Adobe Photoshop cs6:- to edit pictures.

 Microsoft office word 2007 and Microsoft power point 2010 to edit
the document and to prepare the presentation.
 Edraw-max: - to draw Gantt chart and other software diagrams in
design phase.
 PHPMyadmin: - to view data’s for a website that store in the

database server.
 Mysql :used to manage database
 Web browser: - to search reference and to execute the
implementation.
 Snipping tool: - to cut and save some required parts of a web page
and diagrams.
 CSS:-used to styling layout
 HTML and java script:-used front end or client side coding
 PHP:-for server side scripting
1.7. Significance of the project

The existing system is not computerized rather it is manual. So, the web
based system is playing an important role by simplifying the complicated
work.
The main benefits of this system as it is computerized web based system:
 It saves the user’s time to search the required blood.

 The Blood donors can register using the system without going to the
blood bank
 It decreases employee effort required to do their task properly.
17
Gondar
 It attracts blood donors to join and register under the system.
 Introduces the blood bank to technology and also facilitates
technology throughout the coverage area, as it is web based system.
 Since it is interactive system many users join into the system. 
Generates more secured information and reduce redundancy.
 It makes smooth relation between the blood bank and their user.
 Generates and improves socio economic change to the society.
 Faster decision making by searching records from database.
 Increase security by providing authorized user can only access the
organizational service.
1.8. The Beneficiaries of the system

In this section we have discussed about user that uses our system to
accomplish their works.
1.8.1. Blood donors
 It provides the unique identification number easily at the time of

blood donation which helps the user for future correspondence.
 Donors can view the blood donation place organizing at different
time.
 Donor can make registration online.
 Donor can check the status of particular blood group.
1.8.2. Blood seeker (seekers and clinic)

 Blood seeker can get the information of the desired blood group.
 Blood seeker can see available blood on the database.
 Seeker can save money, time and effort.
1.8.3. Blood bank organization

 It helps to rid the manual system.
 The occurrence of error should be decreased.
 Information retrieval should be precise and effective.
18
Gondar
 Report about donor and seeker can be generated easily.
1.8.4. Project team members

While developing the system
 Developer team will be increase their knowledge skill and can have
good awareness for developing web based system
 The developer’s team has a potential to solve problem.
1.9. Feasibility study

Preliminary investigation examine project feasibility, the likelihood the
system will be useful to the organization. The main objective of the
feasibility study is that analyzing the project in terms of Economical,
Technical, Operational and Legal aspects and show that the acceptability of
the project in terms of these criteria.
The feasibility our project can be examined based on different categories:
 Technical Feasibility
 Operational Feasibility
 Economic Feasibility
 Legal feasibility
1.10. Technical Feasibility

The proposed system can be easily maintained and repaired. Technically,
the system will be Powerful to be applied by low skilled users as much as
possible. There is no need for the developer involvement in almost all
implementation of the entire system. It is easily accessible by the people
who have basic computer knowledge.
1.11. Operational Feasibility

The proposed system will provide best services for user and it will be highly
secure. The system will also be on behalf of origination’s goal and user
19
Gondar
satisfaction, because the system will have good user interface and easily
interact with it. Our system will be compatible with the requirement of the
organizations. The user is serviced at their place of work. So, operationally
feasible or it will be operationally acceptable by users.
1.12. Economic Feasibility

As cost/benefit analysis, show the new system is developed using minimum
cost and it give a lot of benefits such as advancing the services of the
system, decreasing the work load of the users. The organization does not
use any media advertises because it makes information online and every
one can get the information from the site.
The proposed web based blood bank management system is economically

feasible because:
 The system requires very less human power.

 The system will provide fast and efficient automated environment.
The system will have excellent and easily understand user interface and very
less usertraining is required to learn it. The cost of the proposed system is
almost negligible when compared to the benefits gained.
1.13. Legal feasibility

The proposed system has no any conflict with any government directives,
because it gives Services for the people effectively and efficiently and the
system is politically feasible.
20
Gondar
1.14 Time schedule
Figure 1. 1 Time Schedule
21
Gondar
CHAPTER TWO
2 REQUIREMENT ANALYSIS
2.1 Introduction
In this chapter analysis phase, the current and the new system’s details are
discussed clearly. During Requirements Analysis, the framework for the
application is developed and also provides the foundation for all future
design and development efforts [3]. From many problems exhibited in
North Gondar blood bank, as mentioned in chapter one of this projects, the
new system dedicated to overcome this problem and create efficient work
environment. The new system is fast and easy to use, moreover it is secured
and there will be an easy way to communicate between the users and blood
bank.
2.2. Current system

In this section we are going to discuss the major functionality and problem
of the current system.
2.2.1. Major function of the current system

Based on the data collected through interview, observation, and document
analysis the team member can understand the overall activity of the current
system. In the existing system the donor goes to the place where donation
is takes place and reach to the receptionist nurse then nurse ask some
question about his/her willingness and motivate to fulfill some questioners,
then the donor goes to nurse and the nurse check if he/she has fulfill the
donation criteria (like weight, blood pressure, etc).If the donor is healthy
the nurse receive blood and the donor get some advice about how much
his/here blood save other’s life and also encourage them for further
donation. The nurse transfer blood to the laboratory class to check by the
lab technician about blood type(A,B,AB,O,etc),blood
22
Gondar
healthiness(HIV,hepatitis A etc).If the blood is pure from disease store in
stock(blood bag) otherwise discarded. When the clinic or seekers needs
blood they can get blood from lab technician. The data is stored on the
papers without any recovery mechanism. Since there is no data security, it
leads to lose of file. As we have observed from the current system every
activity is done manually so it is tedious and inefficient.
2.2.2. Problem of the current (existing) system

Based on the analysis investigated so far, the team member extracts the
following problems:
 It uses more professional human power to create awareness on the

community and collecting blood.
 Editing of data became tedious job.
 It is time consuming and tedious to maintain record.
 There is high data redundancy and data inconsistency.
 There is not smooth interaction between the user and the blood
bank organization.
 When in the case of crash all data and stored blood will be destroy.
 If there is no blood in the stock blood seeker cannot get access, i.e.
there is no a system that communicate seeker with donor.
 Because of absence of electronic data storing mechanism it requires
huge storage space.
2.3. Requirement gathering

This section describes the data collection methods that we use to analysis
the existing system and its problem, it uses as input to develop our system
that solve this problem.
2.3.1. Requirement Gathering Methodologies

In this section we discuss about the methodology that we used to gather
user and organizational requirement.
2.3.1.1 Interview
23
Gondar
The team members interviewed Mr.Demeke Tilahun the manager
of the North Gondar blood bank for necessary information. This
information helps us to identify the blood bank problems and also
to understand the current system. So, the team members analyzed
the information of the blood bank and obtained some basic
concepts on how the blood bank is managed in the current system.
2.3.1.2 Observation
In observation to find the facts the team members observed all the activities
and whole transaction of the system. Observation helped us in finding out
the actual way of functioning apart from the ideal. This method is most
useful when the team members need to actually observe how documents
are handled, how processes are carried out and whether specified steps are
actually followed. While the team members have observed the existing
system, there have been improper handling of files that are too difficult to
access it, and these make the decisions invalid. The team members know
the way donating blood to collectors, at that time the team understands
how much the donor and collector challenged to get service from blood
bank. During the observation we saw a lot of paper that store donor and
seeker details and also saw that the collected blood is stored in bag
according to their type all these activity manages manually.
2.3.1.3. Document analysis:

Another way that we used to collect data is document analysis. We read
written documents which are the existing system currently uses, to know
rules, regulation and constraints in the existing system that can be used to
design the new system.
2.3.2. Result found

From the requirement gathering process performed so far we can get the
information how the current system works, the problem of the current
system, the requirement of the organization and the requirement of the
24
Gondar
user. The information gathered here also helps us to specify our system
requirement and used as an input for the development of our project.
Generally the following results are found while gathering requirements

regarding the problem of the current system:
 The lab technician said that searching information, storing donors

and seekers file is very difficult because the file is stored on paper.
 The Nurse said that collecting blood, register donation, telling the
place of donation to donor is very difficult.
 The Admin said that generating report is difficult because of lack of
organized data.
 The donor said that knowing the place where donation takes place is
difficult.
2.4. Business rule

A business rule is effectively an operating principle or polices that
must be fulfilled and Obligated in order the system will function properly
and effectively. It often related to access Control issues, business
calculations, or operating polices and principles of the organization. The
rules are included below:
BR1.Donors must be at least 18 years old or at most 65 years old.
BR2.If donor has the desired to give blood for the next time she/he must
give after 3 months.
BR3.The blood in the blood stock cannot distribute after 35 days because it
is already expired.
BR4.If donor had hepatitis; donors are not eligible to donate blood.
BR5.If the weight of the donor is between (45-50) kg can donate blood up to
350ml and if greater than 50kg can give 450ml at a time.
25
Gondar
2.5. Proposed system
To avoid all problems existing in the blood bank and make the operations
and activities more accurate, the system needs to be computerized and
should perform some of the activities online. The aim of this project is to
develop improved system that can overcome all the problems of the
existing system. The system provides proper security and reduces a wide
range of manual work. Our proposed system is focus on user satisfaction
and increase the efficiency of works in the organization.
2.5.1. Overview
In north Gondar blood bank there is no any computerized system used
before. All activities is performed manually and no any central database so,
user information is stored on paper. After analyzing all the current system
we are proposed to do a system that simplify the activities performed in the
current system. Using our system donor can register within their home. The
blood seeker can see available blood in stock without going to the blood
bank. If there is blood compatible to their need they can go and get blood if
the required blood cannot available in the blood stock using this system
they can see possible donor and contact with them and get blood. The
admin register blood seeker, delete user account, generates report, post
information etc. In general our proposed system have the properties like
better utilization of resources, good performance, high security, reliability,
accuracy and give better service .The new system is aimed to perform basic
and crucial tasks of the blood bank. It contains a well-organized database
which makes data to retrieve, update easily.
2.5.2. Functional requirements

These are the statement of service that the system should provide. It
explains how the system should react to particular input and how the
system should behave in a particular situation. Functional requirement
captures the intended behavior of the system. The proposed system is
design to do the following functionalities:
26
Gondar
RQ1: The system should allow the users or donor to create account.
RQ2: The system should allow the user to send request for blood.
RQ3: The system should allow the user to give Feedback and view
information.
RQ4: The system should allow to the Lab technician to register blood
RQ5: The system should allow the administrator to generate report and
advertisement.
RQ6: The system should allow the administrator to view Feedback.
RQ7: The system should allow the administrators to register blood seeker.
RQ8: The system should allow the Nurse to register donation.
RQ9: The system should allow the seeker to search the required blood
online.
RQ10: The system should allow the user to update and change their profile.
RQ11: Register and Keep record of donors and seeker in the database is
possible.
2.5.3. Non functional requirement

Non-functional requirements, as the name suggests, are requirements that
are not directly concerned with the specific functions delivered by the
system. Non-functional requirements are not just concerned with the
software system to be developed. Some nonfunctional requirements may
constrain the process that should be used to develop the system. Non-
functional requirements arise through user needs, because of budget
constraints, because of organizational policies, because of the need for
interoperability with other software or hardware systems, or because of
external factors such as safety regulations or privacy legislation.Non
functional requirement of the system deals with how well the system
provides service to the user [4].
27
Gondar
2.5.3.1. User interface and human factor
The user interface for the proposed system is very interactive, easily
understandable. The user interface of the proposed system is directly
related with the system functionality.So,the user need not have extra
knowledge to use the system.
2.5.3.2. Documentation
Documentation will help the project team to have basic knowledge and also
used for users to guide how to operate the system. Therefore it is a
necessary requirement and it helps for maintenance purpose. This
documentation includes proposal, project report, and final document.
2.5.3.3. Hardware consideration

The system may use different operating systems like window 7 and window
8 and window 10. The hard ware required to run the system are network
cable, laptop and desktop computer or tablet with capability of connecting
to the internet and provide connection to the system.
2.5.3.4. Performance characteristics

 Response Time: The output should be generated within a maximum
of 3 seconds depending on the performance of the computer device.
 The proposed system should provide all service that is essential for
the user.
 Many users can use the system concurrently.
2.5.3.5. Error handling and extreme condition

Incorrect input: the system handles many exceptions like inserting empty
string to the database and inserting alphabetic value in integer text field and
displays an appropriate message for each error.
Login error: the system shall handle an attempt to login with incorrect
username and password and display appropriate message.
2.5.3.6. Quality Issue

Since the system to be developed is web based and used different latest
software when it will develop, the system should give a fast and efficient
28
Gondar
service to all users. Adaptability, availability, flexibility, and reliability are the
key issues of this requirement. Use suitable software and hardware to
develop system, will able to achieve this requirement.
 Availability:-the system shall be available at any time for those who

want to use it but it may be out of use when the power is turn off
and if there is no connection.
 Usability:-By training users to become familiar with the system and
by designing user friendly interface, the end users are able to place
an order within few response times.
 No Redundancy:-The proposed system can be avoided repetition of
data anywhere in the database.
2.5.3.7. System modification

As technology is capable of change from time to time there will be future
change to the system as new technology is invent. Therefore the system can
be upgrade to the new technology by maintainer or the systems developers.
2.5.3.8. Physical environment

This BBMS is affected by weather condition when the hardware and
software available for our system may be crash. The system is affected by
weather conditions like earthquake and electronic shock.
2.5.3.9. Security issues

We are going to develop a secured database. There are different categories
of users namely Administrator, Nurse, Lab technician, Donor who will be
viewing either all or some specific information from the database.
Depending upon the category of user the access rights are decided. It means
if the user is an administrator then he can be able to modify the data,
Update etc. All other users only have the rights to retrieve the information
about database.
 The system shall provide high level of security by blocking anyone to
view system secured page.
29
Gondar
 The external security should be provided by given the login
authentication.
2.5.3.10. Resource
issue Server
Minimum hardware requirements for Apache server are:
CPU: 32 bit or 64 bit Cores: single (single core 2Hz or higher dual core 2GHz
or higher is recommended).
Display resolution: 1360X768(or higher).
Client:
CPU: 32 or 64 bit
RAM: 512 Mb or higher
Editor
Notepad++ or notepad
Adobe Photoshop (for editing an image)
2.6. System model
Scenario Name: login
Participating actor: Admin, Nurse, Lab technician, Donor, Seeker
Event: User Log-In
User select Log-In and system displays login form. Then user enters
username and password the system checks whether the username and
Password is valid. If it’s valid user log into the system and the system
displays all available operations. If the entered values are incorrect error
message is displayed.
Scenario Name: Manage Account
Participating actor: Admin, Donor
Event 1: Event: Create account
Admin and Donor log in to the system with user name and password. Then
select create account link then the system Prompts account form .The
30
Gondar
Admin and Donor fill the form and submit the form. System validates the
filled form and display account created successfully if it is correct or error
message if it is incorrect.
Event 2: Update account
Admin and Donor log in to the system with username and password and
then select update account link system display select the parameters you
want to update. Admin and Donor select parameter .The system display
enter new value then Admin and Donor enter the value and click on update
button. Then system validates the entry and display the value is updated
successfully if it is correct or error message if it is incorrect.
Scenario Name: View

Participating actor: Seeker, Admin, Nurse, Donor, Lab technician
Event 1: View blood request
Lab technician log into system with password and user name and select
view link then system displays View feedback, View blood request then
select View blood request link after that system displays Donor’s and
seeker’s request.
Event 2: View Feedback
Admin , Nurse and Lab technician log into system with password and user
name and then select view link system displays View Feedback, View
Request link then select View Feedback link system displays donor’s and
seeker’s Feedback.
Event 3: View Report
First the Lab technician and Nurse must login into the system and the
system display Lab technician and Nurse page then Lab technician and
Nurse select view report menu the system display view report form and Lab
31
Gondar
technician and Nurse enters report date and select submit button then the
system displays viewed report message.
Scenario Name: Registration
Participating actor: Admin, Donor
Event1: Seeker registration
First the admin must login into the system and the system displays admin
page then admin select seeker registration menu and the system display
registration form when the admin fill the form and select register button,
then the system display seeker successfully registered message.
Event2: Donor registration
First Donor must login into the system and system display Donor page, the
Donor select donor registration link and the system display registration form
then Donor fill required information, the system check the filled information
and if it is correct it generate successfully registered message.
Scenario Name: request

Participating actor Nurse and Seeker
Event1: Donation request
First Nurse login into the system and the system display donor page, Nurse
select donation request link and the system display donation request form
the Nurse fill the donation request form and select send button then the
system generate successfully send message.
Event2: Blood request
First the seeker must login into the system and system display seeker page,
seeker select blood request link and the system display request form and
seeker fill request form and select send button then the system generate
your request is successfully sent message.
32
Gondar
Scenario Name: Approve
Participating actor: Lab technician, Nurse
Event: Approve
First the Lab technician and Nurse must login into the system and the
system display Lab technician and Nurse Page then Lab technician and
Nurse select approve request menu and the system display requested
information and check the requested information and if it is correct the
system generate successfully approved message.
Scenario name: Give
Participating actor: Donor, Seeker
Event: Give Feedback
The system display user page and the user select Feedback link.
Then the system display the contact us page with feedback form, when the
user or the visitor fill the required field and select submit button, system
display thanks for your Feedback message.
Scenario Name: Send

Participating actor Nurse and seeker or seeker, Admin
Event 1: Send Request
Nurse and seeker log in to the system and click on send menu then system
displays the request and feedback link Nurse and seeker then select request
link and writes the request and then clicks on send. If it is correct system
display your request has been sent message.
Otherwise try again message will be displayed.
Event 2: Send Message
33
Gondar
Admin login to the system and select send message link. Then system
displays send message form. After that admin writes the message and click
on submit button .then system displays message sent correctly. Otherwise
please try again message will be displayed.
Scenario Name: Logout
Participating actor: Admin, Nurse, Donor, Seeker, Lab technician
Event: Logout
User click on logout menu then the system display login form.
2.6.2 Use Case Modeling

In this section we are going to see about use case diagram, description of
use case diagram and activity diagram this helps to know the functional
interaction between user and the system. Use cases are drawn by
examining the actors and defining what the actor will be able to do with the
system.
2.6.2.1. Use case diagram

The use case diagram is concerned with the interaction between the system
and actors (objects outside the system that interact directly with it). It
presents a collection of use cases and their corresponding external actors. A
use case is a generic description of an entire transaction involving several
objects of the system. Use cases are represented as ellipses, and actors are
depicted as icons connected with solid lines to the use cases they interact
with. A use case diagram is helpful in visualizing the context of a system and
the boundaries of the System’s behavior. Each use cases in the use case
diagram can also be described using a narrative form. [5]
A Use Case represents a discrete unit of interaction between a user and the
system. A use case diagram contains four components.
 Boundary:-which defines the system of interest in relation to the

world around it.
34
Gondar
 Actors:-usually individuals involved with the system defined
according to their roles.
 Use cases: -which the specific roles are played by the actors within
and around the system.
 The relationships between the actors and the use cases as depicted
in the following figure.
The actors and their use case are described below.
35
Gondar
Figure 2- 1 Use case diagram for north Gondar blood bank management system
36
Gondar
2.6.2.2. Description of use case model

The following consecutive tables show the use case description for each of
the use cases. Each table contains the use case name, the actor that initiates
and interacts with the use case, description of the use case and typical
course of events that show the interaction between the actor and the use
case which enable the team member to easily depict the functions of the
proposed system.
Use case id UC-01
Use case name Login
Actor
Admin,Donor,Nurse,Seeker,Lab technician
Description
It is authenticating method that allows users to login to the system.
Goal
To be accessed by an authorized and trust system user
Precondition
Any user must have user name and password.
Basic flow of System response
event Actor action
Step1:user activate the system Step2:system show
Step3:user enter user name and password login interface Step4:
the system check the
validity of the user
name and password
Step5:system display
user page
Post condition System transfer control to user main screen to precede actions.
Alternative A. If the username and password is invalid.

action
1. The system displays error message.
2. The system continues at step 2 to fill user name and password again.
37
Gondar
Table 2-1 Table for Login description
Use case id UC-02

Use case name Post information
Actor Admin
Description Post new information about the blood bank that is accessed by the users of this
system
Goal To post new information to the users in order to create awareness and to
initiate donors for donation
Precondition The System admin must login to post new information
Basic course of Actor action System response

action
Step1: admin enter user Step2: the system check the validity of user
name and password Step4: name and password
admin select post Step3:the system display main admin page
information link Step5: System display post information page.
Step6:System admin enter the Step7:system check post information
information to be post Step8:System posted new information
information
Post condition The posted information will be viewed by an authorized users
38
Gondar
Alternative course of If the new information is not post properly:
action
2. Go to Step5 to post again.
Table 2-2 Table for post information description
Use case id
UC-03
Use case name
View report
Actor
Nurse, Lab technician
Description
The Nurse and Lab technician can be view the report generated by the
admin
Goal To view users about the activities the of organization
Basic flow of Actor action System response

action
39
Gondar
Step2: the system
check the validity
Step1: user enter of user name and
user name and password
password
Step4:user select user page
view report link
Step5: system
display report
Post condition The users view report
Table 2- 3 Table for view report description
Use case id UC-04
Use case name Approve request
Actor Lab technician and Donor
Description Approving blood request and donation request send from

blood seeker and blood Donor respectively
Goal Give decision or response for the user request
Precondition The user request must be viewed by the nurse and lab
technical
Basic flow of action Actor action System response
40
Gondar
Step2: the system check the
Step1: Donor and lab validity of user name and
technician enter user name password
and password Step3:system display
Donor or lab technician
Step4: Donor and lab page
technician select approve Step5:the system display
form approve
Step6: Donor and lab Step7:system check
technician search request information
and if the request is valid Step8:system display the
approve request is approved
Post condition Send for donor and seeker notice to donate the blood and
respectively receive blood
The request is may be disapproved
Alternative action
Table 2-4 Table for approve description
Use case id UC-05
Use case name View Feedback
Actor Admin,Nurse,Lab technician
Description Admin can see the Feedbacks that are submitted from the user.
To view user feedback about the organization service.
Goal
Login to the system
Precondition
41
Gondar
Step1: admin,Nurse and Lab Step2: the system check the validity
technician enter user name of user name and password
and password
Step4: admin,Nurse and Lab admin,Nurse and Lab technician
technician select view page
Feedback link
Step5:system display Feedback
Step6: admin,Nurse and Lab records
technician view Feedback
Admin, Nurse and Lab technician views the submitted Feedbacks.
Post condition
Alternative action If there is no Feedback.
2. Go to step4 to view Feedback again.
Table 2-5 for view Feedback description
Use case id UC-06
Use case name Blood Seeker Registration
Actor Admin
Description The seeker must be registration to get access from the blood bank.
Goal To get service from blood bank using this system.
Precondition Go to the site and register
42
Gondar
Step1: admin enter user name Step2: the system check the
and password validity of user name and
password
Step4:Admin select registration
link Step3:system display admin
page
Step6:Admin fill seeker
registration form Step5: the system display
seeker registration form
Step7:system check seeker

registration information
Step8:system Display
successfully registered
Post condition If valid successfully register if not valid Alternate action
Alternative action If not correctly fill to registered
2.Go to step5 to fill again registration information
Table 2-6 for Blood seeker registration description
Use case id UC-07
Use case Name: Manage account
Description: Admin and donor can create, delete, change user name and password
Actors: Admin and donor
Precondition: Admin and donor must be login to the system
43
Gondar
User action System Action
Basic flow of action: 1) Admin and donor must login to 2)System display required page
the system
4)System display account page
3) Ad Admin and donor can click
6) Systems validate the user input
on account
and unfilled input
5) Admin and donor can fill
manage account form.
7) Admin and donor can click on

submit button
Post condition: Send successfully
Alternative: - If the fill form is invalid system display the form again
Table 2-7 Table for manage account
Use case id UC-08
Use case name Use case id Generate report
Actor Admin
Description Generating the report about the activities that have been done
by the organization.
Goal To generate the required report information for users
44
Gondar
Precondition The admin login to the system know the activity that have been
done
Actor action System response
Step1: admin enter user name Step2: the system check the
Basic flow of action and password validity of user name and
password
Step4:Admin select generate
report link Step3:system display admin
page
Step5:system check report
Step6:system display the
result
Post condition Display the generated report
Alternative action If fail to generate

1.the system display error message
2. Go to step6 to check again.
Table 2-8.Table for generate report description
Use case id UC-09
Use case name Give Feedback
Actors Donor, Seeker
Description Feedback the blood bank system about any thing
45
Gondar
Goal To give the weakness and strength of the organization
Precondition User must register and create account system

Step1:User initiate the Step2:system display user page
system Step4:system display feedback
Basic flow of action
Step3:user select form
feedback link Step6:system check Feedback
Step5:user write information
Feedback about Step7:system display Feedback
submitted
organization service
Post condition User send Feedback to the system
Alternative action If not valid Feedback

2. Go to step4 to fill again Feedback.
Table2-9 Table for give feedback description
Use case id UC-10
Use case name blood request
Primary actors Seeker
46
Gondar
Description Sending request for required blood group with the patient name just
for the acceptance of the request.
Goal Asking blood from the blood bank for the patient.
Precondition Seeker must be register and become a member of the organization.
Actor System response
Step1:seeker enter user
Basic flow of action name and password Step2: the system check the validity
Step4:seeker select send of user name and password
blood request link Step3:system display seeker page
Step6:user fill the blood Step5:system display blood
request in the name of request form
patient Step7:system check blood request
information
Step8:system display inserted
request record
Post condition Indirectly accept the required blood thorough patient name
Alternative action If the seeker fails to fill the form correctly.

2. Go to step6 to fill again the request.
Table 2-10 Table for blood request description
Use case id UC-11

Use case name donor registration
Actor Donor
47
Gondar
Description To register new donor and search the possible donor for the blood
collection mechanism
Goal To search the possible blood donor to communicate with seeker.

Precondition Donor should accesses the system
Actor System response
Basic flow of action
Step1: Donor enter user name and Step2: the system check the
password validity of user name and
Step4: Donor select registration link password
Step6: If the new donor come fill the Step3:system display donor page
donor registration form Step5:system display donor
registration form
Step7:the system check donor
registration information
Step8:system display new donor
information
Post condition donor information can be register and store into DB
Alternative action A. If donor is filled invalid new donor registration information

2. Go to step6 to register new donor or search old donor
Table 2-11 Table for donor registration description
Use case id UC-12
48
Gondar
Use case name Use case id Donation request
Actor Nurse
Description The Nurse should be send donation request with the required
details.
Goal To get permission for blood donation.

Precondition Want to login to the system and fill donation form.

Step1: Nurse activate the
Basic flow of action system Step2:system display main
Step3: Nurse select donation page
request link Step5:fill the Step4:system display
donation request form and send donation request menu
Step6:system save the
request in DB
Post condition Nurse request can be approved
Alternative action A. If Nurse do not fill the form correctly to send donation
request
2. Go to step5 to fill again donation request.
Table 2-12 Table for donation request description
49
Gondar
2.6.3. Activity Diagram

Activity diagram is another important behavioral diagram in UML diagram to
describe dynamic aspects of the system. Activity diagram is essentially an
advanced version of flow chart that modeling the flow from one activity to
another activity.
Activity Diagrams describe how activities are coordinated to provide a

service which can be at different levels of abstraction. Typically, an event
needs to be achieved by some operations, particularly where the operation
is intended to achieve a number of different things that require
coordination, or how the events in a single use case relate to one another,
in particular, use cases where activities may overlap and require
coordination. It is "Less technical" in appearance, compared to sequence
diagrams, and business-minded people tend to understand them more
quickly. [6]
No Symbol Name Function
1. Decision activity To make validation.
2. Initial state To start the activity
3. Activity Set of activities that the user and system

Performing.
4. Arrow To show the flow of activity between two

. activity
5. Final state To show the end of the activity.
Table 2-13 Activity diagram description
50
Gondar
Figure 2- 2 Activity diagram for login
51
Gondar
Figure 2- 3 Activity diagram for generate report
52
Gondar
Figure 2- 4 Activity diagram for register
Figure 2- 5 Activity diagram for create account
53
Gondar
Figure 2- 6 Activity diagram for post information
Figure 2- 7 Activity diagram for send blood request
54
Gondar
Figure 2- 8 Activity diagram for view report
Figure 2- 9 Activity diagram for register blood
55
Gondar
Figure 2- 10 Activity diagram for donation request
2.6.4. Object model

In this section we will describe the class diagram depicting the inheritance
relationships and associations that exist between the entities objects.
Classes are depicted as boxes with three sections: the top one indicates the
name of the class, the middle one lists the attributes of the class, and the
third one lists the methods. Class diagrams are used for a wide variety of
purposes, including both conceptual/domain modeling and detailed
structural design modeling.
2.6.4.1 Data Dictionary

In this section we will describe the attribute of an object.
Object Attribute Description Type
Admin First name This describe the first name admin Varchar
Last name This describe the last name of admin Varchar
Id This describe the unique identification number of admin String
56
Gondar
Age This describe the age of admin Int
Phone This describe the phone number of admin Int

number
Address This describe the address of admin String
Salary This describe the monthly income of admin Int
Qualification This describe the academic status of the admin String
Table 2-14 Attribute description for admin
Nurse First name This describe the first name of a nurse Varchar
Last name This describe the last name of a nurse Varchar
Id This describe the identification number of a nurse Varchar
Age This describe the age of a nurse Int

Address This describe the address of a nurse Varchar
Salary This describe the monthly income of a nurse Int
Phone number This describe the phone number of a nurse Int
Table 2-15 Attribute description for Nurse

Blood First name This describe the first name of a blood donor Varchar
donor
Last name This describe the last name of a blood donor Varchar
Id This describe the identification number of a blood Varchar
donor
Age This describe the age of a blood donor Int
Address This describe the address of a blood donor String
Email This describe the email address of a blood donor String
Phone number This describe the phone number of a blood donor Int
Table 2-16 Attribute description for Blood donor
Lab First name This describe the first name of a Lab technician Varchar
technician
Last name This describe the last name of a Lab technician Varchar
Id This describe the identification number of a Lab Varchar
57
Gondar
technician
Age This describe the age of a Lab technician Int
Address This describe the address of a Lab technician Varchar
Salary This describe the monthly income of a Lab technician Int
Phone number This describe the phone number of a Lab technician Int
Table2- 17.Attribute description for Lab technician

Blood Registration This describe the date that donation takes place Date
information date
Blood type This describe the blood type of the donor Varchar
Exp_date This describe the expired date of the blood Date
Donor weight This describe the weight of the donor Float
Bag_no This describe the bag number of the collected Int
blood
Table 2-18. Attribute description for Blood information

Seeker Name This describe the name of the seeker Varchar
Email This describe the email address of the seeker Varchar
Nurse name This describe the name of the nurse that made an Varchar
agreement with the blood bank
Id This is the identification number for nurse Varchar
Password This indicate the password of the nurse Varchar
Address This describe the address of the seeker Varchar
Table 2-19 Attribute description for Seeker

Report Reporter This describe the reporter or generator of the report Varchar
Content This describe the content of the report String
58
Gondar
Table 2-20 Attribute description for report
Request Sender This describe the sender of request Varchar
Receiver This describe the receiver of request Varchar
Content This describe what the request says String
Date This describe the date in which the request is Date
send
Table 2-21 Attribute description for Request
2.6.4.2 Class Modeling

UML class diagrams show the classes of the system, their interrelationships
(including inheritance, aggregation, and association) and the operations and
attributes of the classes. The following shows the class diagram for the
proposed system.
59
Gondar
Figure 2-11 Class diagram
2.6.5. Dynamic modeling

Dynamic modeling is used to visualize the interactive behavior of the
system. It is a way of describe some type of interactions among the different
elements in the model. In this section we will discuss about sequence and
state chart diagram.
2.6.5.1 Sequence diagram
60
Gondar
Sequence diagrams describe interactions among classes in terms of an
exchange of messages over time. It shows object interaction arranged in
time sequence to perform specific task. A sequence diagram is a good way
to visualize and validate various runtime scenarios.
Figure 2- 12 Sequence diagram for login
61
Gondar
Figure 2- 13 Sequence diagram for View blood
62
Gondar
Figure 2- 14 Sequence diagram for request blood
63
Gondar
Figure 2- 15 Sequence diagram for Create account
64
Gondar
65
Gondar
Figure 2- 16 Sequence diagram for give Donor registration
Figure 2- 17 Sequence diagram for view report
2.6.5.2 State chart diagram
66
Gondar
State chart diagram also called state machine diagram is an illustration of
the states an object can attain as well as the transition between those states
in the unified modeling language. It is used to model the dynamic nature of
the system. It defines different state of an object during its life time and
these states are changed by event.
Figure 2- 18 State chart diagram for Login
67
Gondar
Figure 2- 19 State chart diagram for Seeker registration
68
Gondar
Figure 2- 20 State chart diagram for generate report
Figure 2- 21 State chart diagram for Seeker registration
2.7 User Interface

User interface is the front-end application view to which user interacts in
order to use the system. User interface is designed such a way that it is
expected to provide the user insight of the system [7]. The user interface is
the main component that is used as a communication medium between the
user and the system. We do have a user Interface as described below.
69
Gondar
Figure 2- 22 User interface for login
70
Gondar
Figure 2- 23 User interface for Home page
71
Gondar
Figure 2- 24 User interface for Donor registration
72
Gondar
CHAPTER THREE
3. SYSTEM DESIGN
3.1 Introduction
In this chapter we are going to describe the current and proposed system
software architecture and we specify design goals to improve the quality of
the system by reducing response time, increasing the availability and
improving its reliability to function correctly under erroneous conditions.
Software architecture is the process of defining a structured solution that
meets all of the technical and operational requirements, while optimizing
common quality attributes such as performance, security, and
manageability. We describe the Hardware/software mapping with
deployment diagram, persistent data management, subsystem
decomposition, access control and security. Hardware/software mapping is
mapping subsystems to processors and components enable us to identify
potential concurrency among subsystems and to address performance and
reliability goals. We specify the boundary conditions for each subsystem by
mentioning how the subsystems initialized and terminates.
3.2 Design goal

Design goals describe the important system qualities. Design goals also
define the values against which options are evaluated. When designing a
new system, a system designer creates a model of the system from
requirements made. It give enough and clear information that needed to
drive the actual implementation of system. Design goals describe the
qualities of the system that the developers should consider.
Design goals:-
 Response time: taking less time for system to respond for the
request.
73
Gondar
 Simplicity: we develop the new system which have easy and
understandable user interface.
 Reliability: the system must perform its intended functions and

operations in a system's environment. Without experiencing failure
or system crash.
 Security: the system must be protected from an authorized access,

threats, attacks and vulnerabilities.
 Fault tolerance: the system must have the ability to satisfy

requirements despite failures such as hardware, software or network
failures.
 Cost: The system should be developed with minimum cost possible.

 Dependability:-The system is not easily crashed because during
crash the data saved are stored in the database and after maintained
the system is retrieved and stored as the previous.
3.3 Current software architecture

The existing system of the North Gondar blood bank system is manual
system and hence there is no Existing software architecture that will be
considered. As a result, we only describe the software architecture of the
newly proposed system.
3.4. Proposed software architecture

In this section we are going to discuss about overview and software
architecture of proposed system.
3.4.1. Overview
The software architecture used for the proposed system has 3 tiers. The
client tier is the applications user interface containing data entry forms and
client side applications. It displays data to the user. Users interact directly
with the application through user interface. The client tier interacts with the
web/application server to make requests and to retrieve data from the
74
Gondar
database. It displays the retrieved data to the user. A client can use Internet
browsers to access information from the server.
The middle tier (web/application server) implements the business logic,

controller logic and presentation logic to control the interaction between
the application’s clients and database. The controller logic processes client
requests such as requests to view seeker’s request, to record or to retrieve
data from the database. Business rules enforced by the business logic
dictate how clients can and cannot access application data and how
applications process data.
A web server is a program that runs on a network server (computer) to

respond to HTTP requests. The most commonly used web servers is Apache.
The web server used in this system is Apache. HTTP is used to transfer data
across an Intranet or the Internet. It is the standard protocol for moving
data across the internet.
The third tier, called the data tier, maintains the applications data such as
seeker’s data, Donor’s data, blood detail’s data etc.
75
Gondar
Figure 3- 1 System architecture model for proposed system
3.4.2. Subsystem decomposition

To reduce the complexity of the solution domain, the project team
decomposes a system into simpler parts, called subsystems, which are made
of a number of solution domain classes. In the case of complex subsystems,
the team recursively apply this principle and decompose a subsystem into
simpler subsystems. Decomposition results large systems in to a set of
loosely dependent parts which make up the system. The main need of this
portion is to simplify large complex system into smaller manageable parts.
The major sub-system identified includes:-
Registration subsystem: -this sub-system concern with Donor to register

their personal details and allow Admin to register seeker information.
Account management subsystem:-this subsystem allows the Administrator

to create, delete and update the seeker account.
76
Gondar
Feedback subsystem: - in this sub system the user can raise their Feedbacks
as well as suggestions about the service and system allows administrator to
view and delete user’s feedback.
Response subsystem: - in this sub system the Nurse and the Lab technician
give response for Donor’s and Seeker’s request respectively.
Report subsystem: - in this sub system the Nurse and Lab technician can
view report generated by admin and allow admin to generate report about
collected and distributed blood.
View subsystem: this subsystem allows Admin to view Feedback that

comes from user and it allows donor and seeker to view response.
Information subsystem: this subsystem allow to Admin to post important

information about blood and donation process and rules that are apply in
the system.
77
Gondar
Figure 3- 2 Component Diagram for blood bank management subsystem
78
Gondar
3.4.3 Hardware and Software Mapping
Hardware and software mapping is a process that allows a processor to
identify and track the location of each additional piece of hardware or
software. These allows the processor to identify where the new hardware or
software is located so when the computer needs to access those files or
uses the hardware; it knows where to go in order to work as it is expected.
This mapping describes how the subsystem assigned to hardware and
software by using UML deployment diagram, which shows the physical view
of our system and it brings the software into the real world by showing how
software gets physically mapped to hardware.
Figure 3- 3 Deployment diagram
3.4.4 Persistent Data Management

Persistent data management describes the persistent data stored by the
system and the data Management infrastructure required for it. Persistent
data management is a data that exists for a long time. Since we follow
79
Gondar
object oriented approach to develop our system, the persistence data
management is described using object diagram. The reason we select object
oriented approach is it is used to manage the complexity of software
systems. OOP methods make code more maintainable, identifying the
source of errors becomes easier because objects are self-contained
(encapsulation). Object oriented is based on the
concept of “objects”, which are data structures that contain data, in the
form of fields.
Object diagram is a diagram that shows a complete or partial view of the

structure of a modeled system at a specific time. It’s a graph of instances,
including objects and data values. An object diagram is an instance of a class
diagram; it shows a snapshot of the detailed state of a system at a point in
time.
80
Gondar
Figure 3- 4 Object diagram for North Gondar blood bank management system
3.4.5 Access control and security

In the systems, different actors have access to different functionality
and data. Therefore these privileges prevent unauthorized users from
accessing data’s which they don’t have granted to access.
Authentication: This take place by letting users to insert their user name and
password in the displayed login form.
81
Gondar
ACTORS
FUNCTIONS Admin Nurse Donor Blood seeker Lab technician
Give Feedback  
View Feedback   
Send blood request 
Send donation request 
Post information 
Send message 
Register blood seeker 
Register donor 
Delete Feedback 
Approve donation request 
Approve blood request 

Manage account  
View blood request 
Generate report 
View blood 
View donor    
Change password   
View information  
View donation request 
Table 2-22 Access control and security
3.4.6. Subsystem services
In this section we describe the service provided by each subsystem. For

simplicity our system is decomposed into smaller subsystem and each
subsystem have their own function.So, the function of each subsystem is
described below.
82
Gondar
Figure 3- 5 Component diagram for subsystem service
83
Gondar
3.4.7 Detailed Class Diagram
Detailed Class Diagram is class diagram with visibility and signature specified for
each attributes and operations. In this class diagram we define which attributes
and operations are private to that class, which attributes and operations can be
accessed by the class decedents (protected), and which attributes and
operations are publicly accessible by the class user (public). We also define the
return type of each operations as well as the number and type of parameters of
each operations.
84
Gondar
Figure 3- 6 detailed class diagram

3.4.8 Package Diagram
A package diagram in the UML depicts the arrangement, organization and
dependencies between the packages that make up a model.
Package: a general proposed mechanism for organizing model statements

into groups. It provides an encapsulated name space within which all the
85
Gondar
names must be unique. It is used to group semantically related elements.
The subsystems can be divided into three packages.
 Interface package layer is client tier that is user interface.

 Application package layer is middle tier that contain subsystem.
 Database package layer is data tier that is that stores system
information.
Package diagram for the system is illustrated below.
Figure 3- 7 Package diagram
86
Gondar
CHAPTER FOUR
IMPLEMENTATION
4.1 MAPPING MODELS TO CODE
4.1.1.Bidirectional One-to-One Associations
public class Donor { public class Account {
private account account; private donor

doinfo;
public Donor( account account) { public Account

(Donor doinfo)
{ account = new Account (this); this.
doinfo = doinfo;
} }
public Account getAccount() { public Donor getdoinfo() {
return account; return doinfo;
} }
public Account setAccount(Account public donor setdoinfo( donor

account) { doinfo){
this.account=account; this.doinfor=doinfo;
} }}
87
Gondar
4.1.2.One-to-Many Associations
Public class Admin {public class Seeker{
Private Set Seeker;Private Admin admin;
Public Admin () {public void setadmin
Seeker = new HashSet();(Admin newAdmin) {
}if (admin != newAdmin) {
Public void addseeker(Seeker E) { Admin old = admin;
seeker.add(E); admin= newAdmin;
setSeeker(this);if (newAdmin != null)
}addSeeker(this);}
}}
}}
88
Gondar
4.1.3 Many-to-Many Associations
Public class Donor { public class Feedback {
Private List feedback; private List Donor;
Public Donor () {public feedback () { feedback = new

ArrayList(); Donor = new ArrayList();
} }
Public void SendFeedback public void addDonor

(Feedb
ack f)
{Donor
D) { if
(Feedb
ack.con
tains(f))
{ if (!
Donor.
contain
s(D)) {
Feedback.add(R); Donor.add(D);
addDonor(this); sendFeedback (this);

} }
} }
} }
89
Gondar
4.2.Mapping the Class Model to a Storage Schema Is Performed

A schema is a description of the data, that is, a meta-model for data. In
UML, class diagrams are used to describe the set of valid instances that can
be created by the source code. Similarly, in relational databases, the
database schema describes the validity set of data records that can be
stored in the database. Relational databases store both the schema and the
data.
fname lname Bloodgroup Id phone email weight city date status
number username dno Droll message date email
sex fname lname password email date phone
90
Gondar
username password
fname lname password Id phone email bloodgroup city date status
content date id
4.3.SOURCE CODES FOR MAJOR CLASSES, PACKAGES OR

INTERFACES
<?php
include('dbcon.
php');
if(isset($_POST
['Register'])){
//include('seeker register1.php');
//$target="uploads/".basename($_FILES['image']['name']);
91
Gondar
//$pho=$_FILES['image']['name'];
$target="blood/".basename($_FILES['pho']['name']);
$pho=$_FILES['pho']['name'];
//$image=$_POST['image'];
$fname=$_POST['fname'];
$lname=$_POST['lname'];
$password=$_POST['password'];
$weight=$_POST['weight'];
$sex=$_POST['sex'];
$Age=$_POST['Age'];
$mobile=$_POST['mobile'];
$city=$_POST['city'];
$email=$_POST['email'];
$bloodgroup=$_POST['bloodgroup'];
$type=$_POST['type'];
$reg_date=$_POST['reg_date'];
$status="Active";
$state='0';
if($Age<18 ||$Age>65 ||$type!="donor")
{ echo'<script lang,uage="javascript">';
echo 'alert("Your age
value is incorrect")'; echo
'</script>';
else{
92
Gondar
$sql="select *from donor";
$res=mysqli_query($con,$sql)or die(mysqli_error($con));
while($row=mysqli_fetch_array($res)){
$reg=$row['reg_date'];
$ema=$row['email'];
$datest=strtotime($reg);
$now=strtotime(date('Y-m-d'));
//echo $now;
$dd=$now-$datest;
$kk=floor($dd/(60*60*24));
$tim=$kk;
if($ema==$email){
echo "this account is
already created"; }else{
$hop="hospital";
$insert="INSERT INTO
donor(hospital,pho,fname,lname,password,weight,sex,Age,mobile,city,email,blo
odgroup,type,st atus,state,reg_date,tim)
values('$hop','$pho','$fname','$lname','$password','$weight','$sex','$Age','$mo
bile','$city','$em ail','$bloodgroup','$type','$status','$state','$reg_date','$tim')";
$sql=mysqli_query($con ,$insert ) or die(mysqli_error($con));
//check the
insertion
correctlly if($sql)
93
Gondar
echo'<script
lang,uage="javascript">';
echo 'alert("Account Create
successfully")'; echo
'</script>';
$sql="select *from donor";
$res=mysqli_query($con,$sql)or die(mysqli_error($con));
//echo $now;
$dd=$now-$datest;
$kk=floor($dd/(60*60*24));
$sq="update donor set tim='$kk' where reg_date='$reg'";
$df=mysqli_query($con,$sq)or die(mysqli_error($con));
}}}}
?>
<?
php /
$dayl
repor
94
Gondar
t;
if(isse
t($_P
OST['r
eport'
]))
$select=$_POST['rep'];
if($select=='dayly'){
$ll=0;
else if($select=='weekely'){
$ll=7;
else if($select=='monthly'){
$ll=30;
else $ll=365;
//////////////////////////////private report date calculate
$sql="select reg_date from blood";
95
Gondar
$res=mysqli_query($dbhandle,$sql)or die(mysqli_error($con));
$dd=$now-$datest;
$kk=floor($dd/(60*60*24));
$status="0";
$tim=$kk;
$sq="update blood set tim='$kk' where reg_date='$reg'";
$df=mysqli_query($dbhandle,$sq)or die(mysqli_error($con));
//if($df){echo "update successfully";}
//echo $tim;
$sl="donor";
$sql="select reg_date from donor";
$res=mysqli_query($dbhandle,$sql)or die(mysqli_error($con));
$dd=$now-$datest;
$kk=floor($dd/(60*60*24));
$status="0";
$tim=$kk;
96
Gondar
$sq="update donor set tim='$kk' where reg_date='$reg'";
$df=mysqli_query($dbhandle,$sq)or die(mysqli_error($con));
//if($df){echo "update successfully";}
///////////////////////////government report date calculate
$sq="update blood set status=1 where tim>30"; mysqli_query($dbhandle,

$sq)or die(mysqli_error($con));
////////////// total number of private house
$p="A";
//$ll="0";
$d="select count(Bag_number) AS total from dd where bloodgroup='$p'&&

tim<='$ll'";
$res1=mysqli_query($dbhandle,$d)or die(mysqli_error($con));
$values=mysqli_fetch_assoc($res1);
//$sender_id=$row['sender_id'];
$a=$values['total'];
//count AB
//echo '('.$a.')';
$h="AB";
$kl="select count(Bag_number) AS total from dd where bloodgroup='AB' &&

tim<='$ll'";
$res1=mysqli_query($dbhandle,$kl)or die(mysqli_error($con));
$values=mysqli_fetch_array($res1);
$tt=$values['total'];
97
Gondar
//echo '('.$tt.')';
//count B
$m="B";
$ft="select count(Bag number) AS total from dd where bloodgroup='$m' &&

tim<='$ll'";
$res1=mysqli_query($dbhandle,$ft)or die(mysqli_error($con));
$pp=$values['total'];
//count
//echo '('.$c.')';
//count o
$q="O";
$fr="select count(Bag number) AS total from dd where bloodgroup='$q' and

tim<='$ll'";
$res1=mysqli_query($dbhandle,$fr)or die(mysqli_error($con));
$d=$values['total'];
//echo '('.$d.')';
//count B
$sol="A+";
$r="select count(Bag number) AS total from dd where bloodgroup='$sol' &&

tim<='$ll'";
98
Gondar
$res1=mysqli_query($dbhandle,$r)or die(mysqli_error($con));
$e=$values['total'];
// echo '('.$tt.')';
//count o
$w="AB-";
$k="select count(Bag_number) AS total from dd where bloodgroup='$w' &&

tim<='$ll'";
$res1=mysqli_query($dbhandle,$k)or die(mysqli_error($con));
$f=$values['total'];
//echo '('.$f.')';
//count o
$sl="c-";
$kk="select count(Bag_number) AS total from dd where bloodgroup='$sl' &&

tim<='$ll'";
$res1=mysqli_query($dbhandle,$kk)or die(mysqli_error($con));
$g=$values['total'];
99
Gondar
//echo '('.$g.')';
$nk="AB+";
$kk="select count(Bag_number) AS total from dd where bloodgroup='$nk' &&

tim<='$ll'";
$res1=mysqli_query($dbhandle,$kk)or die(mysqli_error($con));
$zz=$values['total'];
$arrData = array(
"chart" => array(
"caption" => "Total Distrbuted Blood Report",
"showValues" => "0",
"theme" => "fusion"
);
$arrData["data"] = array();
// Push the data into the array
array_push($arrData["data"], array(
"label" => "Total A",
"value" => $a
100
Gondar
);
"label" => "Total B",
"value" => $pp
);
"label" => "Total AB",
"value" => $tt
);
"label" => "Total O",
"value" => $d
);
"label" => "Total AB-",
"value" => $e
101
Gondar
);
"label" => "Total B-",
"value" => $f
);
"label" => "Total AB+",
"value" => $zz
);
/*JSON Encode the data to retrieve the string containing the JSON
representation of the data in the array. */
$jsonEncodedData = json_encode($arrData);
102
Gondar
$columnChart = new FusionCharts("column2D", "myFirstChart" ,700, 400,
"chart-1", "json", $jsonEncodedData);
// Render the chart
$columnChart->render();
// Close the database connection
$dbhandle->close()
?>
Conclusion and Recommendation

The final output of this project is developing web based blood bank
management system for NGBB.To do this the team members collect
requirement, identify the current system problem. During the process we
have learned a lot of ideas related with our project. We have learned the
way how manual blood bank management system works .We were also able
to learn a lot of system analysis and design of the project, and all about
object oriented concept with database. We came to know the different
issues that come in the way of the development of the web based blood
bank management system. Security was the main issue in the development
of this project and we conclude that if these issues are taken into
consideration, web based blood bank management system will become and
real life system from just more a project. The main task in this project are
blood registration, send notification to possible donors,generate
report,keep seeker and donor information,generate expired blood
information.
Our project is implement based on the user and organizational requirement.

It meet all the requirement and business rule presented in this project.
103
Gondar
GLOSSARY
Class Diagram: Is a type of static structure diagram that describe the structure
of a system by showing system classes, their attribute,
operation and the relationship among the class.
Component Diagram Is UML diagram depicts how components are wired together to
form larger components and or software system.
Functional requirement Is a requirement that specifies what the system should do or

what the system should perform
Hardware Is computer equipment including all the components use to

make the computer
Non-functional requirement are requirements which specify criteria that can be used to
judge the operation of a system, rather than specific behaviors
Software Computer programs, instructions that make hardware work
Scenario Is an instance of use case explaining concerned major set of

actions
Sequence Diagram Is a type of interaction diagram that show how process operate
with one another and in what order
Software design Is the transformation of an analysis model into a system design
model During system design, developers define the design
goals of the project and decompose the system into smaller
subsystems that can be realized by individual teams
System Any collection of component element that work together to collect task
Use case diagram Graphical Representation of mark full of step wise activity and
action with support for choice, iteration and concurrency
User interface The combination of menus, screen design, keyboard command,
104
Gondar
command language and help, which creates the way a user
interact with computers.
User Any user that uses the system to accomplish their work
Design Goal Describes the quality of the system that should be optimized
Software Architecture Provides a high level view of the system by decomposing it into
smaller and manageable pieces and study the relationship
among this pieces
Hardware/Software Is activity of selecting Hardware and software mapping

configuration for the system
Persistent Data Data that exists from session to session. Persistent data are
stored in a database on disk or tape.
Are data that will be tracked and stored in the system
permanently
Access Control The management of admission to system and network

resources. It grants authenticated users access to specific
resources based on company policies and the permission level
assigned to the user or user group. Access control often
includes authentication, which proves the identity of the user
or client machine attempting to log in.
Control Flow Describes how the system sequences operations and whether
the
System is event driven or procedure driven.
Table2- 23 Table of Glossary
105
Gondar
REFERENCE
[1]. Perception of Blood Donation among Medical and Pharmaceutical
Science Students of NnamdiAzikiwe University, Awka. Open Journal of
Preventive Medicine (2005).
[2]. WHO. National Blood Bank Service. Available

at:HTTP://WWW.MOH.gov.ET/nbbso.com Accessed:25/02/218.
[3].Jeevan blood bank, Feb 27 2017 at 16:45[online] Available at

HTTP://WWW.jeevan.org.
[4]Robert v, stump er .layette C. Te ague, (1974/January 14), objects

oriented system analysis and design with UML, (2nd edition),-[online
available], [October22, 2015].
106
Gondar
[5]. [online] Available at
https://its.ny.gov/sites/default/files/documents/systemreq.pdf.
[6]. Donald Bell, IBM Global Services, UML basics: An introduction to the
Unified Modeling Language, 2003.
[7]Available at
https://www.tutorialspoint.com/software_engineering/
software_user_interface_design.ht m.
[8]National Blood Bank Service Jun 25 2019 at 4:35[online] Available at

HTTP://WWW.MOH.gov.com.
[9] Jeevan blood bank, Feb 20 2017 at 5:34[online] Available at HTTP://WWW.jeevan.org.
107

Sad Assginment

Uploaded by

Document Information

Original Description:

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

Sad Assginment

Uploaded by

Copyright:

Available Formats

Web based blood bank management system for Bale

DEPARTEMENT OF INFORMATION TECHNOLOGY

ASHENAFI ABERA UGR/21237/13

YESHANEBAL GEBRE UGR/3864/08

AHMED MOHAMED UGR/1511/07

SHANKORE SHODE UGR/22527/13

MESAFINT DESELAGN UGR/22182/13

ASHENAFI ABERA UGR/21237/13

YESHANBEL GEBRIE UGR/22783/13

AHMED MOHAMED UGR/21108/13

SHANKORE SHODE UGR/22527/13

MESAFINT DESELAGN UGR/22182/13

Date Name and Signature Of Supervisor

1.13. Legal feasibility.............................................................................................................................

3.4.4 Persistent Data Management....................................................................................................

Table2- 17.Attribute description for Lab technician ................................................................................ 43

Figure 3- 1 System architecture model for proposed system ...................................................... 59

65 Figure 3- 6 Detailed class diagram .............................................................................................

BG: Blood Group

BR: Business Rule

CPU: Central Processing Unit

CSS: Cascading Style Sheet

EXP_DATE: Expired date

HTML: Hypertext markup Language

NBBS:National blood bank service

NGBB: North Gondar Blood Bank

OOSD: Object Oriented System Analysis and Design

OS: Operating System

PHP: Hypertext Preprocessor

RAM: Random Access Memory

SDD: System Design Document

SPMP: Software Project Management Plan

SQL: Structured Query Language

SRS: Software Requirement Specification

STD: Software Test Documentation

UI: User Interface

Key words: blood, stock,blood donation,Donor,Seeker

Blood bank is one of the important departments. It plays an important role

1.2. Statement of the problem

1.3. Objective of the project

In this section we discuss about the objective that we went to accomplish at

1.3.2. Specific objective

 Analyzing the current manual system.

 Implementing the proposed new system

1.4. Scope of the project

 Create account for users.

1.5. Limitation of the project

1.6.1. System development methodology

 It can be easily maintained

 Increase extensibility: means make modification on some part of

One of the approaches in object oriented technique that we used to

1.6.2. Investigation (fact-finding) methods

1.6.2.3. Document analysis:

1.6.3. Tools used to develop the system

 Personal computer (PC):- For every activity of the project.

 Adobe Photoshop cs6:- to edit pictures.

 PHPMyadmin: - to view data’s for a website that store in the

1.7. Significance of the project

The main benefits of this system as it is computerized web based system:

 It saves the user’s time to search the required blood.

 It decreases employee effort required to do their task properly.

1.8. The Beneficiaries of the system

1.8.1. Blood donors