The Jordanian Blood Bank System (JBBS)

"Hayat.com"

Presented by

Mohammed A.Zalloum: 31301001048

Ahmad R.Alshatti: 31301001098

Muath Z.Albasheer: 31301001061

Supervisor: Dr. Magdy Bseiso

Submitted in Partial Fulfillment of the Requirements for Bachelor Degree in

Computer Science

Prince Abdullah Bin Ghazi Faculty of Information technology

Al-Balqa' Applied University

Salt- Jordan
01/05/2017
Acknowledgment

First, we want to thank the Dean of the College of Prince Abdullah bin Ghazi Dr. Nejad

Najdawi, Deputy Dean Dr. Khalaf Khtattenh and teaching staff there.

Second, our thanks and appreciation to Dr. Magdy Bseiso, project supervisor,

who gave us a hand to build our project systematically, until it finished.

Finally, we do not forget to thank the Jordanian Blood Bank

at Al Bashir Hospital, for the information they have provided us

with the ability to complete the annotated successfully.

DECLARATION

I hereby certify that this material, which I now submit for assessment on the programme
of study leading to the award of Bachelor of Science in (insert title of degree for which
registered) is entirely my own work, that I have exercised reasonable care to ensure that the
work is original, and does not to the best of my knowledge breach any law of copyright,
and has not been taken from the work of others save and to the extent that such work has
been cited and acknowledged within the text of my work.

Signed: Mohammed A.Zalloum, Ahmad R. Alshatti, Muath Z.Albasheer.

Student No.: 31301001048, 31301001098, 31301001061.

Date: 01-05-2017.

ABSTRACT
All sectors of life develop, including the medical sector.
The medical sector is so important that it receives the attention of all governments and the
private sector for two reasons.
The first one the society that enjoys good health is a productive one.
The second reason is that a healthy society saves both wealth and effort which will be
dedicated for the benefit of the society.
In this project we have developed web portal for the Blood Bank of Jordan to improve the
current process.
 TABLE OF CONTENTS

LIST OF FIGURES.........................................................................................................IV

LIST OF TABLES...........................................................................................................VI

LIST OF ACRONYMS/ABBREVIATIONS...............................................................VII

1.CHAPTER.1 INTRODUCTION......................................................................1

1.1 Inroduction.......................................................................................................2

2.CHAPTER.2 PLANNIONG PHASE...............................................................4

2.1 Inroduction to planning phase.......................................................................5

2.2 Business profile.................................................................................................7
2.2.1 JBBS Mission.............................................................................................7
2.2.2 JBBS Vision...............................................................................................7
2.2.3 JBBS Core Values.....................................................................................7
2.2.4 JBBS Services............................................................................................8
2.3 Current system description 8
2.4 Problems definition 9
2.5 Scope of the system 9
2.6 System's Requirement 10
2.6.1 Functional Requirements.......................................................................11
2.6.2 Non-Functional Requirements...............................................................13
2.7 Techinical limitation 14
2.8 Economic constraints 14
2.9 Shortage of time 14
2.10 Pert diagtam 15
2.11 Feasibility study 16
 2.11.1 Economic feasibility study......................................................................16
2.11.2 Techinical feasibilty.................................................................................16
2.11.3 Operation feasibility...............................................................................17
2.11.4 Schedule feasibility..................................................................................17
2.12 S.W.O.T Analysis 18
2.12.1 Strength....................................................................................................18
2.12.2 Opportnuity.............................................................................................18
2.12.3 Threats.....................................................................................................18

3. CHAPTER.3 ANALYSIS PHASE 19

3.1 Introduction to analysis phase 20

3.2 Analysis Methodology..................................................................................22
3.3 Conseptual Data Modeling..........................................................................23

4. CHAPTER.4 DESIGN PHASE 25

4.1 UML and Description 26

4.2 Modeling with Enterprise Architect...........................................................26
4.2.1 Class Diagram.........................................................................................27
4.2.2 Use Case Diagram...................................................................................28
4.2.3 Sequence Diagram..................................................................................29
4.2.3.1 Admin Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
4.2.3.2 Admin Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.3.3 Hospital Signup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.3.4 Hospital Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.3.5 Hospital Request Blood. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.3.6 Donors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 34
4.2.4 Collaboration (State Diagram)..............................................................35
4.2.4.1 Admin Activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
4.2.4.2 Hospital Signup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.4.3 Hospital Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.4.4 Hospital Request Blood. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . 38
4.2.4.5 Donor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
 5. CHAPTER.5 USER MANUAL 40

5.1 Introduction 41
5.2 Hardware Requirements.............................................................................41
5.3 Software Requirements................................................................................41
5.4 Figures of the project 42

6. CHAPTER.6 REFERENCES 50

6.1 References 51
 LIST OF FIGURES

Figure 11: SDLC Phases 2

Figure 12: Pert Diagram For The Project 15
Figure 13: Gannt Chart For The Project 17
Figure 14: Conceptual Data Modeling ERD 23
Figure 15: Blood Bank System (Hayat) Class Diagram 27
Figure 16: Blood Bank System (Hayat) UseCase Diagram 28

Sequence Diagrams :
Figure 17: Blood Bank System (Admin Login) 29
Figure 18: Blood Bank System (Admin Screens) 30
Figure 19: Blood Bank System (Hospital Signup) 31
Figure 110: Blood Bank System (Hospital Login) 32
Figure 111: Blood Bank System (Hospital Request Blood) 33
Figure 112: Blood Bank System (Donors "Donation blood") 34

Collaboration (State) Diagrams :

Figure 113: Blood Bank System (Admin Activity) 35
Figure 114: Blood Bank System (Hospital Signup) 36
Figure 115: Blood Bank System (Hospital Login) 37
Figure 116: Blood Bank System (Hospital Request Blood) 38
Figure 117: Blood Bank System (Donors "Donation Blood") 39

Figures of the Project:

Figure 118: Login Screen (Hospital, Admin) 42

Figure 119: Login Validation 42
Figure 120: Signup (Hospital) 43
Figure 121: Signup Validation 43
Figure 122: Request Blood Screen 44
Figure 123: Request Blood Validation 44
Figure 124: Blood Donation Screen 45
Figure 125: Blood Donation Validation 45
Figure 126: Blood Transaction Screen 46
Figure 127: Blood Quantity Chart 46
Figure 128: Report Screen 47
Figure 129: Report Requests Screen (Hospital) 47
Figure 130: Report Requests Screen (Donors) 48
Figure 131: Conditions for blood donation 48
Figure 132: Contact Us 49
Figure 133: About Us 49
 LIST OF TABLES

Table 11: Time Schedule for the project 15

Table 12: Tasks of the project 17
Table 13: Describing table of Admin Login 29
Table 14: Describing table of Admin Screens 30
Table 15: Describing table of Hospital Signup 31
Table 16: Describing table of hospital Login 32
Table 17: Describing table of Hospital Request Blood 33
Table 18: Describing table of Donors (Donation Blood Order) 34
 LIST OF ABBREVIATIONS

ABBREVIATION Definition of Abbreviation

JBBS Jordanian Blood Bank System

SDLC System Development Life cycle

ASP.NET Active Server Pages

IT_tools Information Technology Tools

OOA Methodology Object Oriented Analysis Methodology

S.W.O.T Strength, Weaknesses, Opportunity and Threats

UML Unified Modeling Language

ERD Entity and Relationship Diagram

DFD Data Flow Diagram

Chapter 1: Introduction

Introduction
The Jordanian Blood Bank system "Hayat" or shorted by (JBBS), is a system that mainly
oriented to Jordanian hospitals in sending blood requests that are needed by patients in all
cases, donation by people, received by the Jordanian Blood Bank System and response to these
requests. Working on the existing system places the main and most common problems faced by
the current system, and introduces a new model of the system itself to try to solve these
problems in computerized work rather than manual labor. We analyzed each problem after
determining its technical scope and nature, with a new structure for the current system.

Figure 11 : SDLC Phases

Work began on the system with the Planning Phase, and the purpose of their study is to
establish a clear vision of the nature and extent of system problems in blood applications by
hospitals, donation by persons and response by the blood bank. We started asking for
important information that helped us identify the system specifications (system's
requirements), and found out the system's mechanism. Preparation of the feasibility study,
implementation plan, and evaluation of this study is carried out through the planning phase to
know how to send requests, receive and respond to each phase of the project.
All system requirements and specifications are prepared in Analysis Phase, the next phase of
system development life cycle (SDLC). We preferred using analysis methodology called "object
oriented analysis methodology" (OOA methodology), which mainly used class diagram, use case
diagram, and other types of diagrams that used in this methodology.
The new version of system presented in Design Phase, in which team members working in a
special framework called "ASP.NET", that consists of set of different capabilities, which mainly
build the design phase. We took under consideration the major steps and activities that used to
build design phase; such as input design, output design, control design, and access layer design,
which the blood bank system requires when sending and receiving orders.
The final phase of building our project was Implementation Phase, in which all system
specifications, needs, and requirements are mixed together to build the final system. This phase
is made up from seven different activities started by coding and ended by systems maintenance.
During this phase, the system built and evaluated its performance in other activities in this
phase, enhanced by IT-tools that made the system interfaces more flexible, and user's friendly
of users.
"After Blood Bank System goes through main phases in SDLC, the new model of the system
becomes more efficient, reliable, user's friendly, and the developers can maintain it in easy way."
Chapter 2: Planning Phase

Introduction to Planning Phase

System's Development Life Cycle (SDLC), is one of the most common and important concepts
that are used in Business Environment. This concept can present as closed cycle that presents
set of different phases that use to build your own system.

SDLC built mainly from the following phases:

• Planning phase.

• Analysis phase.

• Design phase.

• Implementation phase.

• Operation, support, and security phase.

Each of these phases has its own activities that are very important to complete the final and
functional phase, aims to build your system successfully. You have to note that the first phase is
planning phase, in this case, the system's analysts start to evaluate the proposed project and
determine its feasibility.

The main activities that will cover in this phase:

• Business profile: consists of mission, vision, and core values, services, and organization's
structure chart.

• Current business description: includes the history of the current system, current system
description, and its difficulties.

• Problems definitions: includes the major problems that face the current system, nature and
discussion of each problem.

• System's scope: talks in summary about the essential services that provided by the current
system.

• System's requirements: presents the major requirement of the current system, either
functional or non-functional requirements.

• Strategic planning and SWOT analysis: provides the main factors that affect the system on
one hand, and the strategies to develop the system on the other hand.

• Feasibility study: evaluates the system's feasibility: technical, operation, and economic
feasibility.

• Implementation plan: short plan that presents the major phases, that uses to build project
infrastructure, with estimated time and cost.

"Some of the previous activities will present in more details in the next phases of this project,
mainly, the project built from the following phases: planning, analysis, design, implementation,
and testing."
Business Profile

JBBS Mission:

With distinguished management, with using an optimal way to use our resources, we work to:

• Develop blood donation resources by hospitals and donate blood by people in Jordan
blood bank System (JBBS) by region.

• Seeking satisfaction of people, hospitals in donating and obtaining blood from the blood
bank.

• Provide stable services to donors and needy people in Jordan, and use technology to
deploy them on the basis of reliable international standards.

• Accomplish the local objectives by increasing the level of blood requests, donations and
response in Jordan.

JBBS Vision:

We seek to establish a culture of excellence and creativity locally and regionally, to improve
blood transfusion services to keep up with scientific progress, with the participation of the
local community to create a voluntary system that is complete, regular and simple, that will
ensure the safety of blood and enough to reach a healthy society.

JBBS Core Values:

Because of importance of Jordanian Blood Bank in Jordan (JBBS), and to trust its work, the
ministry of health set different of core values that depends on local, legal, and ethical
principles, our core values is as follows:

• Provide adequate safe blood.

• Excellence in blood transfusion services locally and internationally.

• Work as one team.

• Precision, organization and quality.

• Equality, transparency and respect for human rights.

• Promote partnership with all.

• Maintain national health and environment security.

JBBS Services:

The Jordanian Blood Bank System (JBBS) in Jordan presents different services for stakeholders,
these services as follows:

• A new donor :

Added to the system through the screen to apply for blood donation by entering personal
and health information.

• Hospitals :

Providing the possibility for each Jordanian hospital to have an electronic account to
communicate with the blood bank and blood donation requests.

• Reports screen:
 Allows admin to view hospital information.

• Report Requests Screen :

Works to review blood requests and donate to the admin.

• Blood Transaction Screen:

The review of blood stock movement information:

• Review of blood quantities from deficiency and increase of each blood type.

• Allows the user to increase blood quantities by type when donation and reduce it in
the exchange of applications.

• Provides the advantage of reviewing blood stock information in the form of Chart.

Current System Description:

The current system lacks a wide range of electronic services (electronic means, blood donation
applications, applications for blood units). Most of these services are manual, so it takes a lot
of time, effort and human resources.

Problems Definition:

A group of different problems that direct end users (donors and hospitals) in their contact with
the Jordanian Blood Bank when donating and requesting blood, the most common problems
that we can find in current system are as follows:

• Taking information about the donors through the blood donation process.

• Taking information about hospitals that want to obtain certain amounts of blood units for
patients according to the situation they have (urgent situation, on demand).

• The time required to provide reports to the nurses in the blood bank for the processing of
blood units in quantities required.
 • Responding to all requests may take a long time.

Scope of the System:

The new system (JBBS) offers a variety of computerized services, which solve most of the
problems of the current system, as follows:

• A new donor:

Added to the system through the screen to apply for blood donation by entering personal
and health information.

• A new hospital:

Providing the possibility for each Jordanian hospital to have an electronic account to
communicate with the blood bank and blood donation requests.

• Taking information about the donors:

Through the blood donation process, where this information is stored in the user
database.

• Taking information about hospitals:

Through create of an electronic account of its own, which it is saved in the database of
hospitals.

• The system provides a Three Admin Screens:

• Report Screen

Allows admin to view hospital information.

• Report Requests Screen :

Works to review blood requests and donate to the admin.

• Blood Transaction Screen:

The review of blood stock movement information:

 • Review of blood quantities from deficiency and increase of each blood type.

• Allows the user to increase blood quantities by type when donation and reduce it in
the exchange of applications.

• Provides the advantage of reviewing blood stock information in the form of Chart.

"These reports, where they become read and dealt with electronically, rather than
manual"

• Respond:

Response to all requests electronically by the Jordanian Blood Bank system (JBBS).

System's Requirements:

Requirement can be a description of what a system must do. This type of requirement
specifies something that the delivered system must be able to do. Another type of
requirement specifies something about the system itself; how well it performs its functions.

Such requirements called 'non-functional requirement's; Examples of such requirements

include availability, testability, maintainability, and ease-of-use.

A collection of requirements defines the characteristics or features of the desired system. A

'good' list of requirements generally avoids saying how the system should implement the
requirements, leaving such decisions to the system designer. Describing how the system
should implement known as implementation bias. In software engineering, the same meaning
of requirements applies, except that the focus of interest is the software itself. Requirements
classified into the following types:

1. Functional requirements.

2. Non-functional requirements.
Functional requirements:

Functional requirements define the internal workings of the software that is, the calculations,
technical details, data manipulation and processing and other specific functionality that show
how the use cases are to be satisfied. They are supported by non-functional requirements,
which impose constraints on the design or implementation such as performance requirements,
security, quality standards, or design constraints.

As defined in requirements engineering, functional requirements specify specific behaviors of a

system. This should contrast with non-functional requirements, which specify overall
characteristics such as cost and reliability. Software requirements must be clear, correct,
unambiguous, specific, and verifiable.

The major requirements that JBBS includes the following:

• When a user requests blood donation, he/she must enter his personal and health
information:

• Go to the blood donation screen.

• First and Family names.

• The ID Number, User ID.

• Age.

• Blood Type.

• City.

• Donate Date.

• Job.

• Sex.

• Phone Number.

• When the hospital asks for a quantity of blood units for patients, it must do the
following:
• If the hospital does not have an electronic account with the Jordanian Blood Bank
system (JBBS), you must create an account of its own, as follows:

• Username of hospital.

• Password.

• Confirm Password.

• Section.

• Directorate of blood bank.

• If you have an account with the Jordanian Blood Bank system (JBBS), you must log in
to the system through its electronic account (user name, password) and then:

• Go to the blood request screen.

• First name of the patient

• Last name of the patient

• Age

• Sex

• Address

• Blood Container

• Blood Quantity

• Blood Type

• Hospital ID

• Hospital Name

• Phone Number
 • Request Date

• Request ID

• State

• Admin:

• Admin work only limited to:

• Login:

•User Name

•Password

• After Login can:

•Monitor stock movement by going to the stock movement screen.

• Receive blood requests and donate blood through the reports screen of
applications.

• Watch hospital information by going to the reports screen.

Non-Functional requirements:

In systems engineering and requirements engineering, non-functional requirements, are

requirements, which specify criteria that used to judge the operation of a system, rather than
specific behaviors. This should contrast with functional requirements that specify specific
behavior this should contrast with functional requirement that specify specific behavior or
function. Typical non-functional requirements are reliability, scalability, and cost.

Non-functional requirements called "constraints", "quality attributes" and "quality of service

requirements". JBBS includes the following non-functional requirements:

a. Full-automated system.
 b. Increase system reliability.

c. Increase system performance.

d. Build user friendly interface.

These requirements either functional or non-functional will discussed in details when talking
about requirements structuring in the second and third phase (Analysis and Design).

Technical limitations:
This type of restriction depends on how hospitals, donors or stakeholders can work and
interact with information technology, to measure their ability to adapt to the computer and its
trends. In this case, the Jordanian Blood Bank should increase the capacity of employees to
work with IT tools, by enabling staff to be able to use the new system (how to receive and
respond to reports from hospital and donor requests).
 Economic constraints:
Economic constraints are directly related to the main operations used by the Jordanian Blood
Bank to enhance system performance, as each of these operations has its own cost to be
accomplished.

These include:
1. System maintenance.
2. Re-engineering the system.
3. System development.
4. Support system.
5. Installation system.

Shortage of time:
This limitation relates directly to the time required to complete this process in the system.
You can go back and see the main services provided by the system, each one of them needs a
period to be completed, for example, the electronic reporting screen service, we can also see
time or schedule constraints in many system situations, such as when receiving a special
report Each request.

Pert Diagram:
Activity ID Activity Duration Start Predecessors
A Select Work Team days 2 Sun 19/02/2017 None
B Select The Project idea days 8 Tue 21/02/2017 A
C Write a proposal of the project days 7 Wed 01/03/2017 B
D Feasibility study days 2 Tue 07/03/2017 B
E Write the functional requirement days 7 Thu 09/03/2017 C
and none functional requirement
F Architectural design define the days 4 Wed 15/03/2017 E
subsystem, block diagram
G start phase analysis the system days 2 Sat 18/03/2017 F
H write a data dictionary days 5 Mon 20/03/2017 G
 I start design phase use ER and days 8 Fri 24/03/2017 H
DFD
J implement the system using days 20 Tue 01/04/2017 I
Asp.net 2015 & SQL server 2014
K write a final document of the days 2 Fri 28/04/2017 J
project
L present the project with day 1 Sun 30/05/2017 K
Complement Documentation
Table 1- 1: Time schedule for the project

A, 2 B, 8 c, 7 E, 7 E, 7

D, 2 F, 4
L, 1
K, 2 J, 20 I, 8 H, 5 G, 2

Figure 12: Pert diagram for the project.

The number of activities is: 12

Event: from I To XIII

Critical Path: I -II -III -IV -VI -VII -VIII -IX -X -XI -XII -XIII (65 Days).

Critical Activity: A, B, C, E, F, G, H, I, J, K

Feasibility study:

Feasibility study is a preliminary study undertaken before the real work of a project starts to
ascertain the likelihood of the project's success. It is an analysis of possible alternative solutions to
a problem and a recommendation on the best alternative. It, for example, can decide whether an
order processing be carried out by a new system more efficiently than the previous one. A
feasibility study could used to test a new working system, which could use because:

• The current system may no longer suit its purpose.

• Technological advancement may have rendered the current system redundant.

 • The business is expanding, allowing it to deal with extra work load.

• Customers are complaining about the speed and quality of work the business provides.

• Competitors are now winning a big enough market share due to an effective integration of a
computerized system.

Economic feasibility study:

This involves questions such as whether the firm can afford to build the system, whether
its benefits should substantially exceed its costs, and whether the project has higher
priority and Profits than other projects that might use the same resources. This also
includes that whether project is in the condition to fulfill all the eligibility criteria and the
responsibility of both sides in case there are two parties involved in performing any
project.

1. The system Economically Feasibility.

2. Hardware, Software and Others.

Technical Feasibility:

1. Accuracy.

2. Reliability.

3. Security.

Operation Feasibility:

1. Sufficient support for the Donors and Hospitals.

2. Work property if it is being developed and implemented.

3. Easy to maintain.

Schedule Feasibility:

Our system can be accomplished in time.

Activity Duration Start
Task A 2 12-Feb
 Task B 8 21-Feb
Task C 7 01-Mar
Task E 7 09-Mar
Task F 4 15-Mar
Task G 2 18-Mar
Task H 5 20-Mar
Task I 8 24-Mar
Task J 20 01-Apr
Task K 2 28-Apr
Table 1- 2: Tasks of the project

Figure 1- 3: Gantt chart for the project

S.W.O.T. Analysis:

Strength:

• Easy to interact with the system.

• Ability to take the report in short time.

• Ability to give the reports quickly.

• Automate the saving into the data to the database.

Opportunity:

• It’s adapting to be used in the Jordanian Hospitalists and any Jordanian Blood Bank.

• The web page of Jordanian blood banks can be used from phones, computers, and anywhere
connected to the Internet.

Threats:

a system can be a threat factor if it doesn't has any security or maintenance techniques or if it
doesn't gain compliance of its users because of any reason.
Chapter 3: Analysis Phase
Introduction to Analysis Phase

The second important phase that our project used is analysis phase, in which the overall
objectives of the system in this phase is to understand the proposed project, to ensure that it
will support the business requirements. The analysis phase involves end users and IT
specialists working together to gather, understand, and document the business requirements
for the proposed system. The main activities that this phase include:

• Requirements modeling: involves fact-finding to describe the current system, and to

identify the major requirements of the new system such as outputs, inputs, processes,
performance, and security techniques.

• Data and Process modeling: describes how to represent graphically system data and
processes using object -oriented analysis methodology.

• Development Strategies: the operation of selecting the best development path is an

important decision that requires companies to consider three key topics: the impact of the
internet, software outsourcing options, and in-house software development alternatives.

• When talking about analysis phase, we have to know that we have set of different analysis
techniques, the major techniques can classified into the following types:

• Structured analysis methodology: this technique mainly based on using something called
data flow diagram to describe the major activities and data flow through the system
processes.

• Object oriented methodology: this type of analysis based on using objects that may
presents person, machine or something else.

• Other concept that we have to know in this important phase is team-oriented methods
that describe the way that used to develop and analysis the system. There are two main
methods are:
• Joint Application Development (JAD): a popular fact-finding method that brings users into
the development process as active participation.

• Rapid Application Development (RAD): team-based technique that speeds up information

system development and produces a functioning information system.

"Analysis phase needs strong analytical and interpersonal skills to build an accurate model
of the new system. Analytical skills mean the ability to identify the problem, evaluate
elements, and develop a useful solution. The interpersonal skills mean the ability
communicate effectively with your team members on one hand, and the end users on the
other hand."
Analysis Methodology

In this project, we chose object-oriented methodology to analyze the system, whole system

Object oriented analysis considers as one of the most common techniques to analyze the
system requirements, this process or method based on using objects, O-O analysis commonly
used in the real world business application. The main result of using this method is a set of
software objects that represent actual system users, things, transaction and event which
allocate in the current system.

The most common language that used in object oriented analysis is UML that stands for
Unified Modeling Language. It uses a set of different concepts that come from object oriented
programming language there are set of different examples about them such as:

• Classes.

• Inheritance.
 • Objects.

• Messages.

• Methods.

• Abstraction.

• Encapsulation.

• Polymorphism.

The fundamental idea behind an object-oriented (OO) language is object decomposition,

breaking the complex software system down into its various objects, combining the data and
the functions that operate on the data into a single unit, the object. Objects are discussed and
built by modeling real-world instances. A typical OO system consists of a number of
cooperating objects, each of which may or may not collaborate with other objects in order to
achieve some task for the user. Real-world objects display the characteristic of high cohesion;
they maintain a single theme or focus, in true, and software objects modeling real world
objects.

Because of using this technique for analyzing our system requirements we have to use the
following parts of UML diagrams:

• Use case diagrams.

• Class Diagram.

• Sequence diagrams and Machine state diagrams.

Conceptual Data Modeling

System's analysts perform data modeling during the systems analysis phase. It typically done
at the same time as other requirements structuring steps. The conceptual data modeling is a
representation of the organizational data. The major purpose of using conceptual modeling is
to show as many rules about the meaning and interrelation among data as possible .The most
common tool that used to model the database is Entity Relationship Diagram or shorted by
ERD, which shows how the data organized in an information system. In this project, we present
a virtual diagram for suggested system, you have to note that this diagram will be modify in
the next phase of the project based on the system's requirements and specifications, the
 frication of this diagram will be presenting in the design phase.

Figure 1- 4: Conceptual data model ERD

The previous diagram includes the following major tables:

• request_table: foreign key (hosp_id) with one primary key (hospital_id).

• user_types_table: primary Key (user_type_id).

• hospital_table: foreign key (user_type_id) with one primary key (user_type_id).

• admin_table: foreign key (user_type_id) with one primary key (user_type_id).

• user_table: foreign key (user_type_id) with one primary key (user_type_id).

• blood_trans table: foreign key (blood_type_id) with one primary key (blood_type_id).

• blood_type_table: primary key (blood_type_id).

The previous points will be presenting in more details in the design phase, when
talking about database design, we have to talk about the main tables in the
system, with the main design and description for each of them.

Chapter 4: Design Phase

UML and Description

Visual modeling has one communication standard: the Unified Modeling Language (UML). The
UML provides a smooth transition between the business domain and the computer domain.
Using the UML, all members of a design team can work with a common vocabulary, minimizing
miscommunication and increasing efficiency.

Visual modeling captures business processes by defining the software system requirements
from the user’s perspective. This streamlines the design and development process. Visual
modeling also defines architecture by providing the capability to capture the logical software
architecture independent of the software Language. This method provides flexibility to your
system design since the logical Architecture can always be mapped to a different software
language. Finally, with Visual modeling, you can reuse parts of a system or an application by
creating Components of your design. These components can then be shared and reused by
different members of a team allowing changes to be easily incorporated into already existing
development software.

Modeling with Enterprise Architect

Enterprise Architect is the visual modeling software solution that lets you create, analyze,
design, view, modify, and manipulate components. You can graphically depict an overview of
the behavior of your system with a use-case diagram. Enterprise Architect provides the
collaboration diagram as an alternative to a use-case diagram. It shows object interactions
organized around objects and their links to one another. The state chart diagram provides
additional analysis techniques for classes with significant dynamic behavior. A state chart
diagram shows the life history of a given class, the events that because a transition from one
state to another and the actions that result from a state change. Activity diagrams provide a way
to model a class operation or the workflow of a business process.

Enterprise Architect provides the notation needed to specify and document the system
architecture. The logical architecture is captured in class diagrams that contain the classes and
relationships that represent the key abstractions of the system under development. The
component architecture is captured in component diagrams that focus on the actual software
module organization within the development environment. The deployment architecture is
captured in deployment diagrams that map software to processing nodes—showing the
configuration of run-time processing elements and their software processes.

There are set of concepts that used in UML as following:

• Use Cases: represent the major functional requirements of your system.

• Class Diagrams: show the static structure of data and the operations that act on the data.

• State Diagrams: represent dynamic models of how objects change their states in response to
events.

• Sequence Diagrams: represent dynamic models of interaction that happen between objects.

• Class Diagram:

Figure 1-5: Blood Bank System (Hayat) Class Diagram

• Use case diagram:

Figure 1- 6: Blood Bank System (Hayat.com) Use Case Diagram

• Sequence diagrams:

• Admin Login:

Figure 1- 7: Blood Bank System (Admin Login)

Sequence diagram Number: 1

Sequence diagram Name: Login
Brief Description: Enable the admin to login to the program
Actors: Admin
Frequency of Execution: This process is executed whenever the admin enter his password and
username correctly
Scalability: Multi data can be added at once
:Primary Path
The admin enters the password and username.1
The control verify the password and username and send it to the database .2
The database verify the password and open the account and send a verify message to the .3
interface
Table 1- 3: Describing Table of Admin Login

• Admin Screens:
Figure 1- 8: Blood Bank System (Admin Screens)

Sequence diagram Number: 2

Sequence diagram Name: Admin Screens
Brief Description: Enable the admin to visit any Admin Screen
Actors: Admin
Frequency of Execution: This process is executed whenever the admin enter his password and
username correctly and go to any Admin Screen
Scalability: Multi data can be added at once
:Primary Path
The admin enters the password and username.1
The control verify the password and username and send it to the database .2
The database verify the password and open the account and send a verify message to the .3
interface, and enable admin go to Admin Screen
Table 1- 4: Describing Table of Admin Screens

• Hospital Signup

Figure 1- 9: Blood Bank System (Hospital Signup)

Sequence diagram Number: 3

Sequence diagram Name: Signup
Brief Description: Enable the hospitals to Sign up in BBS(Hayat.com)
Actors: Hospital
Frequency of Execution: This process is executed whenever the Hospital enter new account
details
Scalability: Multi data can be added at once
:Primary Path
The Hospital enter new account details.1
Validat the details of account and send to the database .2
update web page go to Login Page.3
Table 1- 5: Describing Table of Hospital Signup

• Hospital Login
Figure 1- 10: Blood Bank System (Hospital Login)

Sequence diagram Number: 4

Sequence diagram Name: Login
Brief Description: Enable the hospitals to Login to the system
Actors: Hospital
Frequency of Execution: This process is executed whenever the Hospital enter user name and
password
Scalability: Multi data can be added at once
:Primary Path
The Hospital enter user name and password .1
The control verify the password and username and send it to the database .2
update web page go to Request Blood screen .3
Table 1- 6: Describing Table of Hospital Login

• Hospital Request Blood

Figure 1- 11: Blood Bank System (Hospital Request Blood)

Sequence diagram Number: 5

Sequence diagram Name: Request Blood
Brief Description: Enable the hospitals to Login to the system and Request Blood
Actors: Hospital
Frequency of Execution: This process is executed whenever the Hospital enter user name and
.password and go to Request Blood screen to request
Scalability: Multi data can be added at once
:Primary Path
The Hospital enter user name and password and go to Request Blood Screen .1
The control verify the password and username and send it to the database .2
when user name and password correct, then will be enable the hospital to Request blood .3
and send to Blood Bank System (Hayat.com) and display on Report Screen
Table 1- 7: Describing Table of Hospital Request Blood

• Donors
Figure 1- 12: Blood Bank System (Donors "Donation Blood")

Sequence diagram Number: 6

Sequence diagram Name: Donation Blood
Brief Description: Enable donor to apply donation blood order
Actors: Donor
Frequency of Execution: This process is executed whenever the donor enter details of blood
donation order
Scalability: Multi data can be added at once
:Primary Path
The donor enter details of blood donation order and submit .1
Validate form and when form has error then will be return [try again], insert into data base .2
Display the blood donation order on report screen .3
Table 1- 8: Describing Table of Donor (Donation Blood Order)

• Collaboration (State Diagram):

• Admin Activity

Figure 1- 13: Blood Bank System (Admin Activity)

• Hospital Signup
Figure 1- 14: Blood Bank System (Hospital Signup)

• Hospital Login

Figure 1- 15: Blood Bank System (Hospital Login)

• Hospital Request Blood

Figure 1- 16: Blood Bank System (Hospital Request Blood)

 • Donor

Figure 1- 17: Blood Bank System (Donor "Donation Blood")

Chapter 5: User Manual

Introduction

The Jordanian Blood Bank system (JBBS) "Hayat" is a web application. This system is
characterized by its user-friendly interfaces. It is divided into screens according to the user
who will deal with it. Some of them are addicted to the blood bank, including hospitals and
donors.

Web Application is a computer application or program that can be accessed and used by a
web browser or via a network such as the Internet or Intranet. Web applications are
programmed by descriptive programming languages supported by most modern web
browsers.

Some software uses these languages to build our own applications.

Other software we need to build databases is also used in our applications, so we need
software for building databases.

Hardware Requirements

• A device capable of connecting to the Internet.

• Internet access provider to access the browser.

Software Requirements:
 • Visual Studio 2015 as the lowest version.

• SQL Server 2014 as the lowest version.

Figures of the project:

Figure 1- 18: Login Screen (Hospital, Admin)

Figure 1- 19: Login Validation

Figure 1-20: Signup (Hospital)

Figure 1-21: Signup Validation

Figure 1- 22: Request Blood Screen

Figure 1- 23: Request Blood Validation

Figure 1- 24: Blood Donation Screen

Figure 1- 25: Blood Donation Validation

Figure 1- 26: Blood Transaction Screen

Figure 1- 27: Blood Quantity Chart

Figure 1- 28: Report Screen

Figure 1- 29: Report Requests Screen (Hospital)

Figure 1- 30: Report Requests Screen (Donors)

Figure 1- 31: Conditions for blood donation

Figure 1- 32: Contact Us

Figure 1- 33: About Us

Chapter 6: References

References
Gather information
Jordanian Blood Bank
Al-Sawary Street - Al-Bashir Hospital
Amman, Ashrafieh
+962 6 4779217

Support
Dr. Magdy Bseiso
Project supervisor

SDLC "System Development Life Cycle"

Tutorialspoint
https://www.tutorialspoint.com/sdlc/

Pert Diagram & Gantt Chart

Wikipedia.org
https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique

UML Diagrams
Tutoralspoint
https://www.tutorialspoint.com/uml/uml_standard_diagrams.htm

Derek Banas
https://www.youtube.com/watch?v=OkC7HKtiZC0 HYPERLINK
"https://www.youtube.com/watch?v=OkC7HKtiZC0&list=PLGLfVvz_LVvQ5G-LdJ8RLqe-
ndo7QITYc"& HYPERLINK "https://www.youtube.com/watch?
v=OkC7HKtiZC0&list=PLGLfVvz_LVvQ5G-LdJ8RLqe-ndo7QITYc"list=PLGLfVvz_LVvQ5G-
LdJ8RLqe-ndo7QITYc