Blood Bank Management System Using Unified Process Methodology

Tanveer Awal (Pratiq), Mohammad Mahbubuzzaman, Sanzad Siddique,

Mehedi Hasan Bhuiyan, Jay Karmachariya and Muhammad Abdul Hakim Newton.
Bangladesh University of Engineering And Technology (BUET)
Department of Computer Science And Engineering (CSE)
newton@cse.buet.ac.bd, light@agnionline.com

ABSTRACT 2. PRELIMINARIES

In this paper, we present a complete blood bank management
information system. The analysis and design of the system has been
done using Unified Modeling Language (UML). Implementation
has been done using Model View Controller (MVC) architecture
and Microsoft Visual Studio .NET framework. And Oracle 8i has
been used as database server. Throughout the whole development
process Unified Process (UP) methodology has been followed.
Keywords: Blood Bank Management, Information System,
Unified Process, Model View Controller, Unified Modeling
Language.
1. INTRODUCTION
Blood Bank is a humanitarian organization for meeting the demand
for blood in various emergency conditions from traumas to major
operations and diseases that necessitate regular insertion of blood.
That is why it is one of the major components of a hospital,
concerned with various related activities including donor
registration, physical examination, blood grouping, blood infectious
tests, component separation, blood requisition and cross match. To
replace the existing manual process of collecting, storing and
managing data for this system with a complete and automated
Management Information System, Blood Bank Management
Information System (BBMIS) has been introduced. The BBMIS
provides ready information about blood reserve/stock, daily cross-
matched details, total daily blood requisitions and information
regarding blood and donor. All through the design and
implementation phases in the process of development we have
adopted the Unified Process (UP) [2, 5] Methodology providing a
comprehensive object-oriented approach which eliminates the
intricacy included in the Structural Analysis and Design by
substituting the need to produce a complete final design and
implementation for an iterative procedure where multi-versioning
makes it possible to restyle the design and implementation meeting
user feed-back leading to a user-adapted, refined-system suiting the
needs for real stake-holders. Also in the implementation, to
segregate the user interface from the core model of the software
Model View Controller [3, 4] architecture is employed.
The rest of this paper is organized as follows. Section 2 presents actions to be performed by the model.
some preliminary ideas, section 3 presents the proposed design,
section 4 presents design issues, section 5 presents some
implemented snapshots.
In this section brief but essential ideas about UML & MVC are
provided:
2.1 UNIFIED MODELING LANGUAGE (UML)
The UML is a language for visualizing, specifying, constructing,
documenting the artifacts of a software intensive system as well as
other non-software systems. It simplifies the complex process of
software design making a blueprint for construction and is now the
standard notation for software architecture. UML provides both the
structural and behavioral views of the system. The UML includes
nine different diagrams – for the sake of grasping the most
representative aspects of the design of BBMIS only the following
diagrams are analyzed in this paper:
Use Case Diagram [1, 2] shows a set of use cases and actors (a
special kind of class) and the relationships addressing the static use
case view and modeling the behaviors of a system. Class Diagram
[1, 2] shows the static design view of a set of classes, interfaces,
collaborations and their relationships .Interaction Diagram [1, 2]
shows an interaction consisting of a set of objects and their
relationships including he messages that may be dispatched among
them. It addresses the dynamic view of a system. A Sequence
Diagram [1, 2] is an interaction diagram emphasizing the time
ordering of messages whereas Collaboration diagram [1, 2] is an
interaction diagram emphasizing the structural organization of
objects that send and receive messages. State Chart Diagram [1,
2] shows a state machine, consisting of states, transitions, events
and activities – especially useful in modeling reactive systems.
Component Diagram [1, 2] shows the static implementation view
of organizations and dependencies among a set of components.
Deployment Diagram [1, 2] shows the static deployment view of
the configuration of run-time processing nodes and the components
that live on them.
2.2 MODEL VIEW CONTROLLER ARCHITECTURE
The model represents enterprise data and the business rules that
govern access to and updates of this data & all the applied
operations. The View object renders the contents of a model &
accesses enterprise data specifying how that data should be
presented. A controller translates interactions with the view into
3. PROPOSED DESIGN OF BBMIS
Here we provide the design of BBMIS with the help of some
diagrams:
 R e c e ive B lo o d
Wo rke r

D e live r B lo o d
S y s te m O p e r a to r

U p d a te D o n o r

G e t D e ta i l s
D e li ve r B l o o d D e live r B lo o d
D e l i ve r B l o o d to D o n o r to M e m b e r s
to O th e r s
<< uses> << use s> >
< < e x te n d s > < <uses> >
< < e x te n ds >

E xc h a n g e B lo o d D e l i ve r B l o o d F r e e

A d d S ta ff

S c re e n in g B lo o d U p d a te S ta ff
W o rk e r( S c r e e n in g ) A d m i n i s tr a to r S ta ff

D e l e t e S ta ff

3.2 Use Case: Process Receive Blood:

Primary Actor: System Operator 3.3 Use Case UC2: Process Deliver Blood to Members
Stake-Holders & Interest: Primary Actor: System Operator.
System Operator: Wants accurate, fast entry & no error. Stake-holders and Interests:
Donor: Wants fast donation along with proof. System operator: Wants accurate, fast search.
Institution: Wants to record blood donation accurately, Client: Wants to get blood fast as the condition for whom
automatic fast update of blood associated records. blood is needed – may be critical.
Humanitarian Organization, hospitals etc: Want to collect Institutions: Wants to record blood delivery accurately &
blood for patients when necessary. automatic, fast update of records.
Preconditions: Operator is identified and authorized. Precondition: Operator is identified & authorized.
Success Guarantee (Post-conditions): Blood input along with Success Guarantee (Post conditions): Blood delivery with
donor’s information is saved. associated information is saved.
Main Success Scenario (Basic Flow): Main Success Scenario:
1. Donor arrives to donate blood. 1. Client arrives for taking blood.
2. Operator starts a new blood donation. 2. Operator verifies his papers and demand of blood.
3. Operator enters donor id. 3. Operator starts a new delivery.
4. Operator enters donor’s instantaneous physical 4. Operator enters Id
information for eligibility testing. 5. Operator uses use case (Uc5): Process Deliver Blood
5. Operator asks a worker to take blood from donor. Free.
6. System generates an id for the new bag 6. Operator repeats step5.
7. Worker takes blood in a bag. 7. System operator takes taka 50 from Client.
8. Donor leaves after being entertained. 8. Operator updates balance.
9. Operator logs out. Extension:
Extension (Alternative Flow): *a At any time system fails:
*a. At any time system fails: To support recovery ensure all transactions can
To support recovery ensure all transactions can be recovered.
be recovered. 1. Operator restarts system, logs in & requests
1. Operator restarts system, logs in & requests recovery of recovery of prior state.
prior state. 2. System reconstructs prior state.
2. System reconstructs prior state. 2a. System detects anomalies
2a. System detects anomalies preventing preventing recovery
recovery 1. System signals error to
1. System signals error, records the operator, records the error and enters a
error and enters a clean state. clean state.
2. Operator starts a new blood input. 2. Operator starts a new blood
3a. Invalid ID: System signals error & rejects entry deliver.
3b. Donor is new: 1a. Invalid Request: Rejects the request.
1. Operator enters personal information about 2a.Demanded blood bags are not available:
the new donor. Operator logs his demanded information if
2. Donor wants to be member. Client wants.
2a.Donor wants to be normal donor. 4a. Invalid Member Id: System rejects the entry, operator
3. System presents a new id. retries with correct Id.
4a. System outputs that donor isn’t eligible for physical 7-8a. Financial inability for payment: Operator takes the
problems: amount which client can pay & updates balance with the given
1. Donor is rejected to donate blood. amount.
 3.3.1 Use Case: Process Deliver Blood Free. 1. Operator restarts system, logs in & requests
Success Guarantee (Post conditions): Blood delivery with recovery of prior state.
associated information is saved. 2. System reconstructs prior state.
Main Success Scenario: 2a. System detects anomalies preventing
1. Operator starts a new free delivery for client. recovery
2. Operator delivers a bag of required group to the client. 1. System signals error, records the
3 Operator enters necessary delivery information. error and enters a clean state.
Extension: 2. Operator starts a new blood deliver.
*a At any time system fails:
To support recovery ensure all transactions can
be recovered.

3.4 CLASS DIAGRAM

1 0 .. * B ag D onor
1 .. *
1 .. *
S TA F F
O th e r s

1 . .*
B a la n c e D em and 1 . .*

Nonm em berD onor

1
F a ile d D e m a n d F u lf ille d D e m a n d

1 . .* 1
1
O n L in e D o n o r N o r m a lD o n o r
F r e e B lo o d E xc h a n g e
1
1 .. *
Mem ber
1
1

3.5 SEQUENCE DIAGRAM

aD o norValidatio nWindo w : aPhys i cal In foW in dow : a D on or : aBag :

Sys tem Ope rato r : aWo rke r : STAFF
Wind ow In te rface Win do w In terface Do no r Bag
STAFF

En te rD ono rId (D o norId)

Valida teD ona r(D on orId )

[Is N ew ]Ad dD o nor(D o nIn fo )

En terPhys icalInfo(PhyInfo)
Is Phys icallyFit(PhyInfo)

Forw a rd To Worker(Bag Id)

Ta keBloo d(ba gId`)

Add Bag(Bag Id ,D o norId)

D o nor provid es info

to o pera tor.

Se que nce D ia gram fo r R e ceive Blood

 aD e live rB lo o d W ind o w : aMe m b e r : aB lo o d F re e : aB ag : aD e m and aB alance :
S ys te m O p e rato r :
W ind o wInte rfac e Me m b e r Fre e B lo o d B ag : D e m and B alance
STAFF

E nte rMe m b e rId (Id )

V alid ate Me m b e r(Me m b e rId )

S e archFo rB lo o d (B lo o d G ro up , B ag No )

A d d D e m and

G e tB lo o d F re e (No O F B ag ) R e m o ve B ag (B ag No )

A d d B alance (A m o unt)

S e q ue nce D iag ram fo r D e live r B lo o d T o Me m b e rs

3.6 COMPONENT DIAGRAMS

L o g in C o n tr o l l e r .v D A O .vb
D o n o r .vb b

H a n d l e E ve n t D AO

E ve n t.vb

F r m In s ta n ta n e o u s
L o g in D o n o r In fo .vb
E xe c u te
F r m M a i n .vb F u n c ti o n ( )

F rm S e le c t F rm D o n o
O ra c le
D o n o r T yp e .vb r In fo .vb D a ta b a s e
S e l e c tD o n o r
Ty pe

C o m p o n e n t D ia g ra m F o r R e c eive B lo o d

Lo gin C o ntro ller.vb D AO.vb

D on or.vb

H a nd leEve nt DAO

Frm Eve nt.vb

Lo gin D o no r D e m and .vb
Execu te
Fu nction ()
Frm Main .vb

Or acle DB

Frm Select
R e ceive rType. vb

S elect
R e ceive rTyp e

C om p on en t D ia gram for D e liver Bloo d

3.7 DEPLOYMENT DIAGRAMS

Fig: Deployment Diagram (Offline)

Fig: Deployment Diagram (Online)

4. DESIGN ISSUE 5. IMPLEMENTATION SNAPSHOTS

The raison d'être behind adopting MVC architecture is the
In this section some of the implementation of the software has
separation of model and view allowing multiple views to use the
been provided:
same enterprise model. At the same time, its efficient
modularity ensures that changes to one aspect of the program
aren't coupled to other aspects, eliminating many nasty
debugging situations.

Fig: Snapshot of ‘Collecting Donor’s Information’ Input Form

Fig: Snapshot of Report on Collection from Registered Person.
Fig: Snapshot of ‘Result for Donor Search’ window.
6. CONCLUSION
In this paper we have tried our best to equip the whole process
of development with state of the art design techniques and latest
software development environment such as .NET and Oracle.
Not only that but also we have implemented the software with
the greatest compatibility and flexibility possible by using MVC
architecture and UP methodology. Due to the bindings on the
number of pages the complete presentation of the analysis and
design couldn’t be accommodated. So, we have focused on
some of the most important features.
REFERENCES
[1] The Unified Modeling Language User Guide ( 7th Indian
Rreprint, Raddy Booch, Grady Booch, James Rumbagh,
Ivar Jacoson)
[2] Applyging UML and Patterns (2nd Edition) – Craig
Larman
[3] www.indiawebdevelpoers.com/technology
[4] www.dmbcllc.com/mvc.apsx
[5] Rational Unified Process – Raddy Booch