WOLKITE UNIVERSITY COLLEGE OF COMPUTING

AND INFORMATICS

DEPARTEMENT OF INFORMATION TECHNOLOGY

PROJEC TTITLE: WEB BASED BLOOD BANK MANAGEMENT

SYSTEM FOR WOLISO BLOOD BANK SERVICE

Name ID
Ezu Temam CIR/339/10
Fasika Alemayehu CIR/235/11
Mahlet Gebre CIR/367/11

Advisor Name: Mr. Muluken. W

Approval Wolkite University, Wolkite, Ethiopia

March2,2022
This is to confirm that the project report entitled web based blood bank management
system for woliso blood bank service submitted to Wolkite University, College of
Computing and Informatics Department of information technology by:

Name ID Signature
Ezu Temam CIR/339/10 -----------------------
Fasika Alemayehu CIR/235/11 ------------------------
Mahlet Gebre CIR/367/11 ------------------------

Advisor Name Signature Date

--------------------------------- ------------------------- -----------------------

Department Head Name Signature Date

---------------------------------- ------------------------- -----------------------

Examiner 1 Name Signature Date

----------------------------------- ---------------------------- -----------------------

Examiner 2 Name Signature Date

---------------------------------- -------------------------- ----------------------

Examiner 3 Name Signature Date

--------------------------------- ---------------------------- ----------------------

i
Table of Contents
Approval...........................................................................................................................................i

List of Tables..................................................................................................................................vi

List of Figure.................................................................................................................................vii

List of Abbreviation........................................................................................................................ix

Abstract............................................................................................................................................x

CHAPTER ONE..............................................................................................................................1

1. Introduction..................................................................................................................................1

1.1 Background of the organization.............................................................................................1

1.2. Statement of problem............................................................................................................2

1.3. Objectives of the project.......................................................................................................2

1.3.1. General objective............................................................................................................2

1.3.2. Specific objective of the project.....................................................................................2

1.4. Feasibility analysis................................................................................................................3

1.4.1. Technical feasibility.......................................................................................................3

1.4.2. Operational feasibility....................................................................................................3

1.4.3. Economic feasibility.......................................................................................................3

1.4.4. Political feasibility..........................................................................................................4

1.5. Scope and limitations of the project......................................................................................4

1.5.1. Scope of the project........................................................................................................4

1.5.2. Limitations of the project...............................................................................................5

1.6. Significance of the project....................................................................................................5

1.7. The main beneficiaries of the project....................................................................................6

1.8. Methodology of the project...................................................................................................6

ii
 1.8.1. Data gathering methodology..........................................................................................6

1.8.2. System development methodology................................................................................7

1.9. Tools used to develop the system.........................................................................................7

1.10. Budget and estimation of the project time..........................................................................9

1.10.1. Budget estimation of the project..................................................................................9

1.10.2. Project time schedule....................................................................................................9

1.11. Team composition.............................................................................................................10

1.12. Document organization.....................................................................................................10

CHAPTER TWO...........................................................................................................................11

2. Requirement Analysis................................................................................................................11

2.1. Description of the Existing System.....................................................................................11

2.2 Users of the existing system.................................................................................................11

2.3 Major function of the current system...................................................................................11

2.4 Forms and Other Documents of the Existing Systems........................................................12

2.5 The business rules of the existing system........................................................................17

2.6 Drawbacks of the Existing system.......................................................................................18

CHAPTER THREE.......................................................................................................................19

3. Proposed system........................................................................................................................19

3.1 Overview..............................................................................................................................19

3.2 Functional requirements.......................................................................................................19

3.3 Nonfunctional requirement..................................................................................................20

3.3.1 User interface and human factor...................................................................................20

3.3.2 Documentation..............................................................................................................20

3.3.4 Performance characteristics...........................................................................................21

3.3.5 Error handling and extreme condition Incorrect input:.................................................21

iii
 3.3.6 Quality Issue..................................................................................................................21

3.3.7 System modification......................................................................................................21

3.3.8 Physical environment....................................................................................................21

3.3.9 Security issues...............................................................................................................21

Resource issue........................................................................................................................22

CHAPTER FOUR.........................................................................................................................23

4. System Modeling.......................................................................................................................23

4.1 Actor and use case identification.........................................................................................23

4.1.1 Actor identification........................................................................................................23

4.1.2 Use case identification...................................................................................................23

4.2 Use case diagram...............................................................................................................23

4.3 Use Case Description...........................................................................................................24

4.4 Class diagram.......................................................................................................................36

4.5 Data Dictionary....................................................................................................................37

4.6 Dynamic Model....................................................................................................................39

4.7 Sequence Diagram...............................................................................................................40

4.8 Activity Diagram..................................................................................................................50

4.9 State chart diagram of the proposed system.........................................................................58

CHAPTER FIVE...........................................................................................................................60

5. System design............................................................................................................................60

5.1 Introduction..........................................................................................................................60

5.2 Design Goals........................................................................................................................60

5.3 Current System Architecture................................................................................................60

5.4 Proposed System Architecture.............................................................................................60

5.5 Subsystem Decomposition...................................................................................................61

iv
 5.6 Hardware/Software Mapping...............................................................................................62

5.7 Detailed Class Diagram.......................................................................................................63

5.8 Persistence Data Diagram....................................................................................................63

5.9 Access Control.....................................................................................................................64

5.10 Packages.............................................................................................................................65

5.11 User Interface Modeling....................................................................................................66

Reference.......................................................................................................................................67

Appendix........................................................................................................................................68

v
List of Tables
Table 1 estimated budget of the project...........................................................................................9
Table 2: team composition.............................................................................................................10
Table 3 business rule1...................................................................................................................17
Table 4 business rule2...................................................................................................................17
Table 5 business rule3...................................................................................................................17
Table 6 business rule4...................................................................................................................17
Table 7 business rule5...................................................................................................................18
Table 8 : business rule 6................................................................................................................18
Table 9 : use case description for login.........................................................................................25
Table 10 use case description for manage account........................................................................26
Table 11 : use case description for post information.....................................................................27
Table 12: use case description for view report.............................................................................28
Table 13: use case description for approve...................................................................................28
Table 14 use case descriptions for view comment........................................................................29
Table 15: use case descriptions for hospital registration...............................................................30
Table 16: use case description for donation request......................................................................30
Table 17: use case description for generate report........................................................................31
Table 18: us case description for give comment...........................................................................31
Table 19: use case description for blood request...........................................................................32
Table 20: use case description for collect blood............................................................................33
Table 21: use case description for donor registration....................................................................34
Table 22: use case description for blood destribution...................................................................35
Table 23: use case description for manage stock...........................................................................35
Table 24: attribute description for admin......................................................................................37
Table 25: attribute description for nurse........................................................................................37
Table 26: attribute description for blood donor.............................................................................38
Table 27: attribute description for inventory manager..................................................................38
Table 28: attribute description for blood information...................................................................39
Table 29: attribute description for blood seeker............................................................................39
Table 30: attribute description for blood request...........................................................................39

vi
Table 31: attribute description for report.......................................................................................39
Table 32: access control table........................................................................................................65

List of Figure
Figure 1: time schedule of the project.............................................................................................9
Figure 2: use case diagram of the proposed system......................................................................24
Figure 3: class diagram..................................................................................................................36
Figure 4: sequence diagram for login............................................................................................40
Figure 5: sequence diagram for hospital registration....................................................................41
Figure 6: sequence diagram for donor registration........................................................................42
Figure 7: sequence diagram for blood distribution........................................................................43
Figure 8: sequence diagram for post information..........................................................................44
Figure 9:sequence diagram for view report...................................................................................45
Figure 10: sequence diagram for approve request.........................................................................46
Figure 11: sequence diagram for donation request........................................................................47
Figure 12: sequence diagram for add blood..................................................................................48
Figure 13: sequence diagram for give comment............................................................................49
Figure 14: activity diagram for login.............................................................................................50
Figure 15: activity diagram for manage account...........................................................................51
Figure 16: activity diagram for hospital registration.....................................................................52
Figure 17: activity diagram fort post information.........................................................................53
Figure 18: activity diagram for view report...................................................................................54
Figure 19: activity diagram for approve request............................................................................55
Figure 20: activity diagram for view comment.............................................................................56
Figure 21: activity diagram for donation request..........................................................................56
Figure 22: activity diagram for add blood.....................................................................................57
Figure 23: activity diagram for blod request.................................................................................57
Figure 24: state chart diagram for login........................................................................................58
Figure 25: state chart diagram for generate report.........................................................................58
Figure 26: state chart diagram for hospital registration.................................................................59
Figure 27: the proposed system architecture.................................................................................61

vii
Figure 28: sub system decomposition............................................................................................62
Figure 29: deployment diagram.....................................................................................................62
Figure 30: detailed class diagram..................................................................................................63
Figure 31: object diagram..............................................................................................................64
Figure 32: package diagram...........................................................................................................66
Figure 33: user interface modeling................................................................................................66

viii
List of Abbreviation
BBMS…………………………………………………………...Blood bank management system
BG……………………………………………………………....Blood Group
BR………………………………………………………………Business Rule
CPU……………………………………………………………..Central Processing Unit
CSS……………………………………………………………..Cascading Style Sheet DB:
HTML…………………………………………………………..Hypertext markup Language
HW……………………………………………………………..Hardware
INFO…………………………………………………………....Information
MS……………………………………………………………...Microsoft
WBB…………………………………………………………....Woliso Blood Bank
OS……………………………………………………………....Operating System
PHP……………………………………………………………..Hypertext Preprocessor
RAM…………………………………………………………....Random Access Memory
REQ…………………………………………………………….Requirement
SQL……………………………………………………………..Structured Query Language
SW………………………………………………………….......Software
UI…………………………………………………………….....User Interface
CDC…………………………………………………….............Central disease Control
FMOH……………………………………………………..........Federal Ministry of Health
RCS……………………………………………………………..Ethiopia Red Cross society

ix
Abstract
The main objective of this project is developing a web based blood bank management system to
Woliso Blood bank Service. 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 properly, 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 service for blood donors, blood Seekers and also to create an interactive way of providing
Services to 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. The methodology that we use to develop the system is object
oriented specifically iterative technique.

x
 CHAPTER ONE
1. Introduction
The computer based system consists of all components necessary to capture, process, transfer,
store, display and manage information. The blood bank is a center where blood gathered as a
result of blood donation is stored and preserved for later use in blood transfusion. The project
that is going to develop is blood bank management system for blood bank. The main purpose of
the project is to handle and maintain blood bank management system and also provide efficient
transfusion services. In the current system the activities such as documenting, finding and
searching of specific information are done manually. Employee cannot perform their activity
like, donor registration.
It is tedious for blood seeker to search the required blood type in case of emergency. Our
motivation to do this project is that almost all blood banks are working manually. Due to these it
can be faced by different problems.in order to solve those problem we propose these automate
system. The computer is now available in much of people’s house and they simply register by
using it. Therefore, that is why we are highly motivated to do our project on web application.
1.1 Background of the organization
In Ethiopia, blood bank service introduced in 1969 on yikatet12 hospitals. Ethiopian blood bank
supported by FMOH and CDC separated from ERCS since 2004. Blood bank system in Ethiopia
has one main bank in Addis Ababa and 26 sub branch around all Ethiopia. Woliso blood bank
service is one of 26 blood bank branches which was established by federal government and
oromya regional state since in march 2005 E.C. (1) this organization was begin giving small
capacity of blood service today it provides blood for 17 hospitals.
The aim of the organization is to provide efficient service to user, to increase the capacity to
provide blood for the recipient, to increases the number blood donors by teaching the society and
facilitating blood donating service for the blood donors. From time to time, the capacity of it is
increasing but the organization was working with manual system. Since the organization is using
manual system this makes the employee to fail with data redundancy and erroneous data storing.
Generally, this organization was established to save the life of people who are affected by these
problem like accidents, cancer, sickle cell, premature and surgery.

1
Ethiopian peoples are donating and seeking blood time to time, there has been a good rise in the
number of people who donate blood but the system is very old and paper based, therefore we are
very interested to make computerized the system “blood bank management system”.
1.2. Statement of problem
In the current system, documenting writing and searching of the specific information of the
blood is done manual. The managers cannot manage the bloodstock starting from the blood
collection, to blood screening, processing, storage, distribution and lastly transfusion through this
system. These types of system make the worker to document erroneous and redundancy
information and it consume the time of worker for completing specific task. Therefore, we have
identified the following problem in the existing system.
 Document Mismanagement: Chances for losing the vital information related to hospital,
blood and blood donors.
 Difficult to know amount of blood in stock and identify expired blood.
 Error handling takes more time and resources such as paper, pen.
 The system not efficient, reliable, available and difficult to get data fast from the paper.
 Difficult to prepare organized report.
 Difficult to give pack number to collected blood.
 Difficult for making comment the system user to blood bank services.
 Less awareness among people about blood donation and blood transfusion services.
 Difficult to know how match time have donor-donated blood before.
1.3. Objectives of the project
1.3.1. General objective
The general objective of this project is to develop web based blood bank management system.
1.3.2. Specific objective of the project
 To gather requirements.
 To Identifying and defining of the problem that the existing system have then analyzing the
system.
 Identifying functional, nonfunctional requirements and design interactive user interfaces.
 Create a database to register blood donor, hospital and to store personal profiles for
individual donor and hospital of the blood bank.
 Coding, testing and implementing the new system.

2
 Prepare the documentation and train the users.
1.4. Feasibility analysis
To bring the successful completion of this project goals and objectives the feasibilities issues
listed below has determined the project viability or the discipline of planning, organizing, and
managing resources.
The feasibility of our project can be examined based on different categories:
 Technical Feasibility
 Operational Feasibility
 Economic Feasibility
 Political feasibility
1.4.1. Technical feasibility
The proposed system can be easily maintained and repaired. Technically, the system will be easy
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. The system is self-explanatory and does not need
any extra sophisticated training because the system has been built by concentrating on the
graphical user interface concepts.
1.4.2. Operational feasibility
The system will provide adequate through put at desire time to the user and give the need
information in a timely usefully formatted way. The system also has security to gives access
privilege providing account for an authorize person. This system provides help description to the
user about how to use the system. In addition, the developers do other technical modification on
the system. So the system will be operationally feasible or it will be operationally acceptable to
users. The system give better user interface registration form and storage of user information,
easy updating, deletion and modification etc.
1.4.3. Economic feasibility
As cost/benefit analysis, show the new system will be developed using minimum cost and it give
many benefits such as advancing the services of the system, decreasing the workload of the
users.
The organization does not using any advertising media to announce its services and requirements
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:
3
  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 user
training is required to learn it.
 The cost of the proposed system is almost negligible when compared to the benefits
gained.
Tangible benefits:
The team has identified the following:-
 Increase in flexibility of the modifying blood bank information system.
 Provide higher data backup by designing database for the blood bank.
 Reduce resource requirements or unnecessary wastage of resource in blood bank like
paper, pen and decrease payment for advertises gives for TV, Radio etc.
 Increase the speed of activities during searching information.
 Increase blood bank management system performance
 More timely information for advertising blood transfusion services 24 hour.
Intangible benefits
The intangible benefits of the new system are:
 Increase in accuracy of blood bank detail information.
 Faster decision making by searching records from database.
 Increase security by providing authorized user can access.
 Reduce workload of the organization system user’s.
 Error reduction during filling necessary information about blood donation process.
 Increase efficiency of blood bank management system performance.
1.4.4. Political feasibility
The proposed system has no any conflict with any government directives, because it gives
Services for the people effectively and efficiently so the organization is profitable and the system
is politically feasible.
1.5. Scope and limitations of the project
1.5.1. Scope of the project
Blood bank management system has much functionality. However, this project focus on data
handling activities related to blood donors and blood distribution, managing the collected blood

4
information is as well as how to distribute blood from the blood bank to different clients such as
hospitals.
The scope of proposed system will focus on the following main tasks
 The system used to register, update, view and deactivate users
 Retrieve general report such as reports about collected blood, distributed blood, available
blood.
 Creating account for users.
 Advertising the organization services and requirements such as request for donation.
 Shows accessibilities and availabilities of blood inside the stock by their blood group.
 Recording blood components and blood donation.
 Handling information with related to blood donors, seekers and distribution information.
 Managing the collected blood data and distribute blood from the blood Bank to different
place such as client hospital and other health centers.
 Store screened blood information and discard expired blood
1.5.2. Limitations of the project
 The system does not support languages other than English language.
1.6. Significance of the project
The existing system is not computerized rather it is manual. Therefore, 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.
 It attracts blood donors to join and register under the system.
 Introduces the blood bank to technology and facilitates technology throughout the coverage
area, as it is web-based system.
 Since many users join interactive system into the system.
 Generates more secured information and reduce redundancy.
 It makes smooth relation between the blood bank and their user.
 Generates and improves information exchange with the society.
 Faster decision making by searching records from database.

5
 Increase security by providing authorized user can only access the organizational service.
1.7. The main beneficiaries of the project
In this section, we have discussed about user that uses our system to accomplish their works.
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.
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.
Blood bank organization
 It helps to rid the manual system.
 The occurrence of error should be decreased.
 Information retrieval should be precise and effective.
 Report about donor and seeker can be generated easily.
1.8. Methodology of the project
1.8.1. Data gathering methodology
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.
Observation:
We observed and understand the actual workflow or event performed in the current system.
Which could witness the actual events, which will happen in the organization? In this method, all
team members have observed and note down the events from that observation
During observation, we saw many papers and document that store the information and we saw
that different notification posted on the notice board in the blood bank.
Interview:
This is one of the methods used for the collection of data in which the project designers are
asking different questions to woliso blood bank organization Manager, Ato Dagne, and

6
Employees for obtaining the required data.
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. Not
only that but also we tried to review other relevant documents to develop this project.
1.8.2. System development 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.
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 supports the design and representation of the system using
UML diagram like, use case, sequence and activities.
 It allows breaking 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 facilitates change in the system at low cost: by developing manual documentation of
our system so the object oriented development methods helps us to overcome this
problem.
 Increase reuse of component: - the object oriented provides opportunities for reuse of
code or component through the concepts of inheritance, polymorphism, and
encapsulation.
 Increase quality -blood bank information management system improved quality and
efficiency to blood transfusion services effectively by accept system user feedback and
also easily managing the blood stock
 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 delivery of high quality system at
relatively low cost. We improve the sub system until the complete version is reached.
1.9. Tools used to develop the system
To develop our system we are going to use different tools.

7
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.
 Printer:- to print the document
Software tools:
We will use the following tools to develop the web-based system:
Front-End Technologies
 HTML: to define the content of web pages.
 CSS: to specify the layout of web pages.
 JavaScript: to program the behavior of web pages.
 Bootstrap: to develop responsive website.
Back-end technologies
 Apache Server: - to compile the sever side scripting language.
 MYSQL DBMS: - server to compile SQL queries and store data.
 PHP: - for server-side scripting language.
Other software tools
 Microsoft office word 2016 and Microsoft power point 2016 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.
 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
 Xampp Server: To test the system by running.

8
1.10. Budget and estimation of the project time
1.10.1. Budget estimation of the project

Material Quantity Birr Cent Total

Paper 2 packet 250 - 500
Pen 3 10 - 45
Flash 32GB 1 330 - 330
Laptop 1 25,000 - 25,000
Transportation 2000 - 2000
Print 500 - 500
Mobile card 20 50 - 1000
Total 29,375 TABLE 1
ESTIMATED BUDGET OF THE PROJECT
1.10.2. Project time schedule

FIGURE 1: TIME SCHEDULE OF THE PROJECT

9
1.11. Team composition
Team members Responsibility
Ezu Temam System designer, Manager, implementation
Fasika Alemayehu System analyst, implementation
Mahlet Gebre Requirement gathering, implementation
Mr. Muluken Advisor
TABLE 2: TEAM COMPOSITION
1.12. Document organization
Our project consists of seven chapters. Chapter one give description on the project we are
working on web based blood bank management. The main objective of this chapter is to give an
introduction about the system like its scope, objectives, and methodologies, chapter two focuses
more about the system requirement specification or analysis. These chapter includes Description
of Existing system, business rules, drawbacks of the existing system, third chapter discuss about
functional and non-functional requirements, the fourth chapter includes use case diagram, use
case documentation, state chart diagram ,sequence diagram. Chapter five explains the design
phase of the proposed system is explained, control and security. is about the system design like
conceptual modeling, deployment and employment diagram, database design, access. Chapter six
chapter deals in testing of the system, Hardware software acquisition, and Installation process of
the system. The seventh chapter about in Conclusions and Recommendations of the project.

10
 CHAPTER TWO
2. Requirement Analysis
2.1. Description of the Existing System
Based on the data the team gathered the current blood bank is a manual. 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/her 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 healthiness (HIV, hepatitis A etc.). (2)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 Users of the existing system
Players represent external entities that interact with the system. Due to this we will deal only
with persons involved on those services or persons who have responsible for this work.
The following are listed:
 Donors:-people who are donating their blood to the system to save life.
 Manager:-are office workers who manage different activities. This includes control blood
transfusion, collect report from other workers, and announce new information.
 Nurse:-are persons who collect blood that the donors donate by packed it.
 Inventory manager: -is a person who manages blood stock.
 Hospital:-The organization which send blood request when patients needed blood.
2.3 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.

11
In the existing system documenting, writing and searching of the specific information of the
blood is done manual.
2.4 Forms and Other Documents of the Existing Systems

12
13
14
15
16
2.5 The business rules of the existing system
Business rules are statements about the organization’s way of doing business. The blood bank
have policies in order to satisfy the business objective, satisfy customers, and make good use of
resources, and conform to laws or general business conversions.
Basic business rule of the blood bank are:-
Name Registration

ID BR1

Description The donor and hospital must be registered

TABLE 3 BUSINESS RULE1

Name Multiple time donation

ID BR2

Description .If donor has the desired to give blood for the next time she/he must give
after 3 months.

TABLE 4 BUSINESS RULE2

Name Blood request

ID BR3

Description Hospital that send blood request must be customer of the blood bank.

TABLE 5 BUSINESS RULE3

Name Blood donation

ID BR4

Description The donor must fulfill the required criteria to donate blood means their
health status, age, weight etc.

TABLE 6 BUSINESS RULE4

17
 Name Distribute blood

ID BR5

Description The inventory manager must distribute the collected blood.

TABLE 7 BUSINESS RULE5

Name Collect blood

ID BR7

Description The nurse must collect blood

TABLE 8 : BUSINESS RULE 6

2.6 Drawbacks of the Existing system
Due to the manual means been used by the blood bank, keeping information about donors and
receivers, a lot problems are encountered which includes:
 The processes of donating require that the donors must be come and register at the blood
bank
 Difficult to search, retrieve, update and delete the data about donors and other users of
the system.
 Wastage of resource and consuming storage space and time.
 The absence of electronic data storing mechanism it requires huge storage space
 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.
 The current process requires high human-power.

18
 CHAPTER THREE
3. 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.
3.1 Overview
In woliso blood bank service 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
3.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:
RQ1: The system should allow the admin to create account for users or donor.
RQ2: The system should allow the administrators to register blood seeker.
RQ3: The system should allow the administrator to generate report and advertisement.
RQ4: The system should allow the Nurse to register donation.

19
 RQ5: The system should allow to the Nurse to add blood
RQ6: The system should allow the seeker to search the required blood online.
RQ7: The system should allow the user to send request for blood.
RQ8: The system should allow the user to give Feedback and view information.
RQ9: The system should allow the administrator to view Feedback.
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.
3.3 Nonfunctional 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. Nonfunctional
requirement of the system deals with how well the system provides service to the user
3.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. The system’s
UI is combination consistent of menus, screen design, keyboard command, command language
and help, which creates the way a user, interact with computers. So, the user need not have extra
knowledge to use the system. (3)
3.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
3.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.

20
3.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.
3.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.
(3)Login error: the system shall handle an attempt to login with incorrect username and password
and display appropriate message.
3.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 service to all users. Adaptability, availability,
flexibility, and reliability are the key issues of this requirement. (4)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.
3.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.
3.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.
3.3.9 Security issues
We are going to develop a secured database. 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

21
machine attempting to log in. There are different categories of users namely Administrator,
Nurse, Inventory manager, 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.
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)

22
 CHAPTER FOUR
4. System Modeling
4.1 Actor and use case identification
Based on the findings of existing system assessment, the system process is modeled and use
cases and actors are identified. We relate actors with the corresponding use cases as shown in
figure 2.
4.1.1 Actor identification
The actors that will participate in the system are listed below:
 Donors:-people who are donating their blood to the system to save life.
 Manager:-are office workers who manage different activities. This includes control blood
transfusion, collect report from other workers, and announce new information.
 Nurse:-are persons who collect blood that the donors donate by packed it.
 Inventory manager: -is a person who manages blood stock.
 Hospital:-The organization which send blood request when patients needed blood.
4.1.2 Use case identification
The use cases incorporated in the system are:-Login, manage account, add new information,
Approve request, view report, generate report, register donor, register hospital, donation request,
add new blood, and collect blood, blood request, blood distribution, register employee and
searching process.
4.2 Use case diagram
The second step is to construct the use case model which graphically represents the interaction of
the system with the external environment. The major actors that plays major role out of the
system are:- administrator, nurse, inventory manager, hospital and donor the use cases
incorporated in the system are:-Login, manage account, add new information, approve, view
report, Register donor, register hospital, donation request, add new blood, collect blood, blood
request, blood distribution and searching process. (5)
The following figure specifies the use case model of the system

23
FIGURE 2: USE CASE DIAGRAM OF THE PROPOSED SYSTEM
4.3 Use Case Description
The third step is to document each of the above use case events to determine the requirement use
cases as described in the following section.

Use case id UC#1

Use case name Login

actors Admin, Donor, Hospital, nurse, Inventory manager.

24
Description The authentication for authorized users in the system to interact
with the system web based blood bank
Goal To be accessed by an authorized and trust system user

Precondition Any user must have user name and password

Basic flow of action Actor action System response

Step1:user activate the system Step2:systemshow login
Step3:user enter user name and interface
password Step4: The system check the
authentication of user name and
password
Step5:system display user page
Post condition System transfer control to user main screen to precede actions.

Alternative action A. If the username and password is invalid.

1. The system displays error message.
2. The system continues at step 2 to fill user name and password
again
TABLE9 : USE CASE DESCRIPTION FOR LOGIN
Use case id UC#2
Use case name manage account
Actor Admin
Precondition The System administrator must login to control the account
Description This activity is performed when the admin want to manage the
account
Goal To control the system users activity.
Basic course of action Actor action system response
Step1: admin enter user name Step2: the system check the
and password authentication of user name and
Step4: admin select mange password
account page :- Step3:the system display admin

25
 1.create account
2.update account
3.deactivate account
If create account
Step6:admin enter user
account information If update
account
Step10: admin enter user
account information to be
updated If to delete account
Step13: admin enter user
account information to be
delete
Post condition The system admin successfully create, update and delete the
account!
Alternative course of action A. If invalid entry.
1. The system displays error message.
2. Go to step 6 to fill again.
TABLE 10 USE CASE DESCRIPTION FOR MANAGE ACCOUNT
Use case id UC#3
page
Step5: System display create
account page.
Step7:system check created
user account information
Step8:System creates user
account
Step9: System display update
account page. Step11: system
check updated user account
information Step12: System
display delete account page.
Step14:system check deleted
user account information

Use case name Post information

Actor Admin

Description Post new information to create awareness and use full

information
Goal To post new information to the blood bank users and
customers
Precondition The System admin must login to post new information

Basic course of action Actor action System response

Step1: admin enter user name Step2: the system check the

26
 and password authentication of user name
Step4: admin select post and password
information link Step3:the system display
Step6:System admin enter main admin page
post available information Step5: System display post
information page.
Step7:system check posted
information
Step8:System posted new
information
Post condition The system posted information will be viewed by an
authorized users
Alternative course of action A. If the new submitted information is not valid.
1. The system displays error message.
2. Go toStep5 to post again
TABLE 11 : USE CASE DESCRIPTION FOR POST INFORMATION
Use case id UC#4
Use case name View report
Actor Donor, Hospital, nurse, Inventory manager.
Description View the reported that is generated by admin
Goal To view about all activities that have been done in organization
Precondition The actors must be log in to the system
Basic course of action Actor action System response
Step1: user enter user name and Step2: the system check the
password authentication of user name and
Step4:user select view report password
link Step3:system display user page
Step5: system display report
Post condition The admin view report
Alternative action A. If no new report found to be reported.
1. The system displays error message.

27
 2. Go to step4 to view report again
TABLE 12: USE CASE DESCRIPTION FOR VIEW REPORT
Use case id UC#5
Use case name Approve request
Primary actors Admin
Description For Approving those who send donation request to donate blood.
Goal Give decision for the donor appointment
Precondition Admin must be view the donor donation request to approve
Basic flow of action Actor action System response
Step1:admin enter user name Step2: the system check the
and password authentication of user name and
Step4:admin select approve password
form Step3:system display admin
Step6: admin search request page
and if the request is valid Step5:the system display
approve approve
Step7:systemcheck information
Step8:system display the
request is approved
Post condition Send for donor session date to donate the blood
Alternative action The request is may be disapproved
TABLE 13: USE CASE DESCRIPTION FOR APPROVE
Use case id UC#6

Use case name View comment

actor Admin

Description Users can see the comments that are submitted from the user, customer
and other parties.
Goal To view user feedback about the system

Precondition Login to the system

Basic flow of action Actor action System response

28
 Step1: admin enter user name and
password
Step4:admin select view
comment link
Step6:admin view comment
Post condition Admin views the submitted comments.
Step2: the system check the
authentication of user name and
password
Step3:system display admin page
Step5:system display comment
records

Alternative action A. If there is no comment.

1. The system displays error message.
2. Go to step4 to view comment again
TABLE 14 USE CASE DESCRIPTIONS FOR VIEW COMMENT
Use case id UC#7
Use case name Hospital Registration
actor Admin
Description for registration to get access from the blood bank
Goal To access the system and to be the system member.
Precondition Go to the site and register
Basic flow of action Actor action System response
Step1: admin enter user name Step2: the system check the
and password authentication of user name and
Step4:Admin select registration password
link Step3:system display admin
Step6:Admin fill hospital page
registration form Step5: the system display
hospital registration form
Step7:system check hospital
registration information
Step8:system Display
successfully registered
Post condition If valid successfully register if not valid Alternate action
Alternative action A. If not correctly fill to registered

29
 1. The system displays error message.
2. Go to step5 to fill again registration information
TABLE 15: USE CASE DESCRIPTIONS FOR HOSPITAL REGISTRATION
Use case id UC#8
Use case name Donation request
Actor Donor
Description The donor should be visit the blood bank makes appointment date
for the blood donation purpose
Goal To specify the donation date.
Precondition The donor must volunter to donate blood
Basic flow of action Actor action System response
Step1:Donor activate the system Step2:system display main page
Step3:donor select donation Step4:system display donation
request link request menu
Step5:fill the donation request Step6:system save the request in
form and send DB
Post condition If Get appointment date to donate blood
Alternative action A. If donor do not fill the form correctly to send donation request
1. The system displays error message.
2. Go to step5 to fill again donation request
TABLE 16: USE CASE DESCRIPTION FOR DONATION REQUEST
Use case id UC#9
Use case name Use case id Generate report
Actor Admin
Description Generating the report that of activities have been done.
Goal To generate the required report information for users and customers
Precondition The admin login to the system know the activity that have been
done
Basic flow of action Actor action System response
Step1: admin enter user name Step2: the system check the
and password authentication of user name and

30
 Step4:Admin select generate password
report link Step3:system display admin
page
Step5:system check report
Step6:system display the result
Post condition Display the generated report
Alternative action A. If fail to generate
1.the system display error message
2. Go to step6 to check again.
TABLE 17: USE CASE DESCRIPTION FOR GENERATE REPORT
Use case id UC#10
Use case name Give Comment
Description Comment the blood bank system about any thing
Goal To give the weakness and strength of the system
Precondition User must register and create account system
Basic flow of action Actor action System response
Step1:User initiate the system Step2:system display user page
Step3:user select feedback link Step4:system display feedback
Step5:user write comment about form
the system Step6:system check comment
information
Step7:system display comment
submitted
Post condition User send comment to the system
Alternative action A. When fill to send the comment if not valid
1. The system displays error message.
2. Go to step4 to fill again comment
TABLE 18: US CASE DESCRIPTION FOR GIVE COMMENT

Use case id UC#11

Use case name blood request

31
 Primary actors Hospital
Description Sending request for required blood unit, blood group. with the
patient name just for the identification of blood accepter
Goal Asking blood from the blood bank for the patient.
Precondition Hospital send request to blood bank.
Basic flow of action Actor System response
Step1:hospital enter user name Step2: the system check the
and password authentication of user name and
Step4:hospital select send blood password
request link Step3:system display hospital
Step6:user fill the blood request page
in the name of patient Step5:system display blood
request form
Step7:system check blood
request information
Step8:system display inserted
request record
Post condition Indirectly accept the required blood thorough patient name
Alternative action A. If the hospital fails to fill the form correctly.
1. The system displays error message.
2. Go to step6 to fill again the request.
TABLE 19: USE CASE DESCRIPTION FOR BLOOD REQUEST
Use case id UC#12
Use case name add new blood
Primary actors Nurse
Description To Collect The Blood from voluntary donors by filling full
information,
Goal To Collect The Blood from voluntary donors
Precondition Fill collected blood information
Basic flow of action Actor System response
Step1:nurse enter user name and Step2: the system check the

32
 password authentication of user name and
Step4:nurse select collect blood password
link Step3:system display nurse page
Step6: fill collect blood Step5:system display collect
information blood menu
Step8:nurse print out record then Step7:system check collect
give for donor blood information
Step8:system display collected
blood record
Post condition Submit collected blood information
Alternative action A. If nurse not enter valid entry to fill blood collection form
1. The system displays error message.
2. Go to step6 to fill again the collected blood.
TABLE 20: USE CASE DESCRIPTION FOR COLLECT BLOOD
Use case id UC#13
Use case name donor registration
Actor Nurse
Description To register new donor and search the old donor for the blood
collection mechanism
Goal To search the old blood donor
Precondition Donor should accesses the system
Basic flow of action Actor System response
Step1:nurse enter user name and Step2: the system check the
password authentication of user name and
Step4:nurse select view donor password
registration link Step3:system display nurse page
Step6:the volunteer old donor Step5:system display donor
search() from donor registration registration form
and If the new donor come fill Step7:the system check donor
the donor registration form registration information
Step8:nurse view donor record Step8:system display new donor

33
 information information
Post condition Register detail donor information
Alternative action A. If Nurse is filled invalid new donor registration information
1. The system displays error message.
2. Go to step6 to register new donor or search old donor
TABLE 21: USE CASE DESCRIPTION FOR DONOR REGISTRATION
Use case id UC#14
Use case name Blood distribution
Primary actors Inventory manager
Description For Blood distribution. blood accepter must be come using hospital
blood donation request
Goal To distribute the safe blood to the hospitals
Precondition Searching the blood fit from the stock
Basic flow of action Actor action System responses
Step1: Enter User name & Step2: the system check the
password authentication of user name and
Step4:inventory manger select password
blood distribution link Step3:the system display
Step6:search() from blood stock inventory manager page
that fit with the blood accepted Step5:the system display
distribution form
Step7:system check blood stock
information
Step8:system display fit blood
Post condition Distribute blood for the accepter
Alternative action A. If Filled entry to distribute blood is invalid
1. The system displays error message.
2. Go to step6 to search fit blood from the stock for the distribution
TABLE 22: USE CASE DESCRIPTION FOR BLOOD DESTRIBUTION
Use case id UC#15
Use case name Manage stock

34
Primary actor Inventory manager
Description Manage the amount of blood in stock too knows the amount of
Blood per level and the expired blood. and also to insert new blood
Goal To manage the blood in the blood stock.
Precondition view the Details of the Blood Stock
Basic flow of action Actor System response
Step1:enter user name and Pass Step2: the system check the
word authentication of user name and
Step4:inventory manger select password
blood stock link Step3:the system display
Step6:inventory manger select inventory manger page
1.register blood Steps5:the system display mange
2.discard blood stock form
If select register blood Step8:system display blood
Step7:inventory manager fill registration form
blood registration form If select Step9:system check register
discard blood blood information
Step11:inventory manager check Step10:system display blood
if blood expired successfully registered
Step12:enter expired blood Step13:system display blood
information and click discard successfully discarded
Post condition Add new blood to stock, view the Less amount of Blood per level
and expired blood
Alternative action A. If invalid entry is filled to the inventory manger to add new blood
or discard blood
1. The system displays error message.
2. Go to step6 to fill again the add new blood or discard
TABLE 23: USE CASE DESCRIPTION FOR MANAGE STOCK

35
4.4 Class diagram

FIGURE 3: CLASS DIAGRAM

36
4.5 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 String
number of admin
Age This describe the age of admin Int
Email This describe the email address of a String
Admin
Phone This describe the phone number of admin Int
number
Address This describe the address of admin String
Qualification This describe the academic status of the String
admin
TABLE 24: ATTRIBUTE DESCRIPTION FOR ADMIN
Object Attribute Description Type
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 Varchar
of a nurse
Age This describe the age of a nurse Int
Address This describe the address of a nurse Varchar
Phone This describe the phone number of a Int
number nurse
TABLE 25: ATTRIBUTE DESCRIPTION FOR NURSE
Object Attribute Description Type
Blood donor First name This describe the first name of a blood Varchar
donor
Last name This describe the last name of a blood Varchar
donor

37
 Age This describe the age of a blood donor Int
Address This describe the address of a blood String
donor
Phone This describe the phone number of a Int
number blood donor
Email This describe the email address of a String
blood donor
TABLE 26: ATTRIBUTE DESCRIPTION FOR BLOOD DONOR
Object Attribute Description Type
Inventory First name This describe the first name of a Varchar
manager Inventory manager
Last name This describe the last name of Inventory Varchar
manager
Age This describe the age of Inventory Int
manager
Address This describe the address of a Inventory String
manager
Phone This describe the phone number of a Int
number Inventory manager
Email This describe the email address of a String
Inventory manager
TABLE 27: ATTRIBUTE DESCRIPTION FOR INVENTORY MANAGER
Object Attribute Description Type
Blood Registration This describe the date that donation takes Date
information date place
Blood type This describe the blood type of the donor Varchar
Exp_date This describe the expired date of the Date
blood
Donor weigh This describe the weight of the donor Float
Bag_no This describe the bag number of the Int
collected blood

38
TABLE 28: ATTRIBUTE DESCRIPTION FOR BLOOD INFORMATION
Object Attribute Description Type
Seeker Name This describe the name of the seeker Varchar
Email This describe the email address of the Varchar
seeker
Nurse name This describe the name of the nurse that Varchar
made an agreement with the blood bank
Id This is the identification number for Varchar
nurse
Password This indicate the password of the nurse Varchar
Address This describe the address of the seeker Varchar
TABLE 29: ATTRIBUTE DESCRIPTION FOR BLOOD SEEKER
Object Attribute Description Type
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 Date
request is sent
TABLE 30: ATTRIBUTE DESCRIPTION FOR BLOOD REQUEST
Object Attribute Description Type
Report Reporter This describe the reporter or generator of Varchar
the report
Content This describe the content of the report String
TABLE 31: ATTRIBUTE DESCRIPTION FOR REPORT
4.6 Dynamic Model
In this section we will discuss about sequence and state chart diagram to visualize the interactive
behavior of the system and to describe some type of interactions among the different elements in
the model.

39
4.7 Sequence Diagram

FIGURE 4: SEQUENCE DIAGRAM FOR LOGIN

40
FIGURE 5: SEQUENCE DIAGRAM FOR HOSPITAL REGISTRATION

41
FIGURE 6: SEQUENCE DIAGRAM FOR DONOR REGISTRATION

42
FIGURE 7: SEQUENCE DIAGRAM FOR BLOOD DISTRIBUTION

43
FIGURE 8: SEQUENCE DIAGRAM FOR POST INFORMATION

44
FIGURE 9:SEQUENCE DIAGRAM FOR VIEW REPORT

45
FIGURE 10: SEQUENCE DIAGRAM FOR APPROVE REQUEST

46
FIGURE 11: SEQUENCE DIAGRAM FOR DONATION REQUEST

47
FIGURE 12: SEQUENCE DIAGRAM FOR ADD BLOOD

48
FIGURE 13: SEQUENCE DIAGRAM FOR GIVE COMMENT

49
4.8 Activity Diagram

FIGURE 14: ACTIVITY DIAGRAM FOR LOGIN

50
FIGURE 15: ACTIVITY DIAGRAM FOR MANAGE ACCOUNT

51
FIGURE 16: ACTIVITY DIAGRAM FOR HOSPITAL REGISTRATION

52
FIGURE 17: ACTIVITY DIAGRAM FORT POST INFORMATION

53
FIGURE 18: ACTIVITY DIAGRAM FOR VIEW REPORT

54
FIGURE 19: ACTIVITY DIAGRAM FOR APPROVE REQUEST

55
FIGURE 20: ACTIVITY DIAGRAM FOR VIEW COMMENT

FIGURE 21: ACTIVITY DIAGRAM FOR DONATION REQUEST

56
FIGURE 22: ACTIVITY DIAGRAM FOR ADD BLOOD

FIGURE 23: ACTIVITY DIAGRAM FOR BLOD REQUEST

57
4.9 State chart diagram of the proposed system

FIGURE 24: STATE CHART DIAGRAM FOR LOGIN

FIGURE 25: STATE CHART DIAGRAM FOR GENERATE REPORT

58
FIGURE 26: STATE CHART DIAGRAM FOR HOSPITAL REGISTRATION

59
 CHAPTER FIVE
5. System design
5.1 Introduction
In this phase the overall procedures, activities and methods of execution during the
implementation phase of the project are included. The following subtopics are discussed in this
phase. These are component diagram, deployment diagram, and persistence diagram and user
interface prototype of the project
5.2 Design Goals
The design part is very important so as to make the implementation very easy. The different
types of the system modeling techniques that are used for the implementation of the system such
as deployment and component modeling are show in detail. Not only the system modeling
techniques but also some system design techniques such as system decomposition design are
cover in detail in this phase.
5.3 Current System Architecture
The existing system of the 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
5.4 Proposed System Architecture
In our system we will use three tier architectures these are presentation tier, application tier and
database tier. Presentation Tier: - consists of the user interface. This user interface is often a
graphical one accessible through a web browser or web-based application and which displays
content and information useful to an end user. This tier is often built on web technologies such as
HTML, JavaScript, and CSS and communicates with others layers through API calls.
Application Tier: Also called the middle tier, logic tier, business logic or logic tier, this tier is
pulled from the presentation tier. It controls application functionality by performing detailed
processing.
Data Tier: Houses database servers where information is stored and retrieved.

60
FIGURE 27: THE PROPOSED SYSTEM ARCHITECTURE
5.5 Subsystem Decomposition
The subsystems can be considered as packages holding related classes/objects. These subsystems
are further decomposed into other subsystems. The major subsystems identified are
“Registration”, “Login”, “Screening”, “Donate Blood”, “Blood Distribution”, “Blood
Collection” and “manage stock” subsystems. Users are classified in to roles. The “Login”
subsystem authenticates a user to grant access based on the role of the user.

61
FIGURE 28: SUB SYSTEM DECOMPOSITION
5.6 Hardware/Software Mapping
Deployment diagrams are used for describing the hardware components where software
components are deployed.

FIGURE 29: DEPLOYMENT DIAGRAM

62
5.7 Detailed Class Diagram

FIGURE 30: DETAILED CLASS DIAGRAM

5.8 Persistence Data Diagram
Persistence modeling is used to communicate the design of the database, usually the data base to
both the users and the developers. It is also used to describe the persistence data aspect of the
system. The following tables indicate the persistence data management of the system.

63
FIGURE 31: OBJECT DIAGRAM
5.9 Access Control
When start up the system, the system will display the user a login screen. Then the user will enter
username and password. After the user entered the username and password, the system verifies
whether the username and password entered are valid or not. If it is valid, the system will allow
access to the application based on the privilege to which the user belongs. Accordingly to the
following access control list is given for the system.
Actor Request Post info Registration Distribution Add Stock Comment
blood management
donor Send Give
request comment
Online
for

64
 giving
blood
Admin adding new Register View
information Hospital for comment
being
member
Nurse Register Control Add the View
donor when Distribution collected comment
donate of Blood blood
blood
Inventory Control Manage the View
manager Distribution Stock comment
of Blood
Hospital Send Give
blood comment
request
TABLE 32: ACCESS CONTROL TABLE
5.10 Packages
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 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.

65
FIGURE 32: PACKAGE DIAGRAM
5.11 User Interface Modeling

FIGURE 33: USER INTERFACE MODELING

66
Reference

1. WHO. National Blood Bank Service. [Online] [Cited: February 14, 2022.] Availabl
at:http://www.MOH.gov.et/nbbso.com.
2. Perception of Blood Donation among Medical and Pharmaceutical Science Students . Awka.
s.l. : Open Journal of Preventive Medicine.
3. National Blood Bank Service. [Online] Jun 25, 2019. [Cited: February 2, 2022.] Available at .
4. Jeevan blood bank. [Online] [Cited: December 25, 2021.] Available at http://www.jeevan.org..
5. Robert v, stumper .layette C. Teague. objects oriented system . (1974/January 14).
6. Donald Bell, IBM Global Services. UML basics: An introduction to the Unified . 2003.

67
Appendix
Appendix A: Interview Question
 When the organization was established?
 What is the role of organization?
 What are the organization services?
 How the organization stored record?
 What are the problems on their works?
 Is the Organization currently uses computer system?
 What is the organization plan for the future?
 How the organization educates the blood donor?
 What is the organization structure?
 Who could request a blood?
 What are the criteria to request a blood?
 How the request will be handling in the organization?

68
Appendix B: Forms filled by donor the Organization

69
70