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) [email protected], [email protected]

ABSTRACT 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 crossmatched 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.

2. PRELIMINARIES 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 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 3. PROPOSED DESIGN OF BBMIS implemented snapshots. 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

S y s te m O p e r a to r U p d a te D o n o r

D e live r B lo o d

G e t D e ta i l s D e l i ve r B l o o d to O th e r s D e li ve r B l o o d to D o n o r D e live r B lo o d to M e m b e r s

<< uses>

< < e x te n d s >

< < e x te n ds >

<< use s> > < <uses> >

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 W o rk e r( S c r e e n in g ) S c re e n in g B lo o d A d m i n i s tr a to r D e l e t e S ta ff S ta ff U p d a te S ta ff

3.2 Use Case: Process Receive Blood: Primary Actor: System Operator Stake-Holders & Interest: System Operator: Wants accurate, fast entry & no error. Donor: Wants fast donation along with proof. Institution: Wants to record blood donation accurately, automatic fast update of blood associated records. Humanitarian Organization, hospitals etc: Want to collect blood for patients when necessary. is identified and authorized. Preconditions: Operator Success Guarantee (Post-conditions): Blood input along with donors information is saved. Main Success Scenario (Basic Flow): 1. Donor arrives to donate blood. 2. Operator starts a new blood donation. 3. Operator enters donor id. 4. Operator enters donors instantaneous physical information for eligibility testing. 5. Operator asks a worker to take blood from donor. 6. System generates an id for the new bag 7. Worker takes blood in a bag. 8. Donor leaves after being entertained. 9. Operator logs out. Extension (Alternative Flow): *a. At any time system fails: To support recovery ensure all transactions can be recovered. 1. Operator restarts system, logs in & requests recovery of prior state. 2. System reconstructs prior state. 2a. System detects anomalies preventing recovery 1. System signals error, records the error and enters a clean state. 2. Operator starts a new blood input. 3a. Invalid ID: System signals error & rejects entry 3b. Donor is new: 1. Operator enters personal information about the new donor. 2. Donor wants to be member. 2a.Donor wants to be normal donor. 3. System presents a new id. 4a. System outputs that donor isnt eligible for physical problems: 1. Donor is rejected to donate blood.

3.3 Use Case UC2: Process Deliver Blood to Members Primary Actor: System Operator. Stake-holders and Interests: System operator: Wants accurate, fast search. Client: Wants to get blood fast as the condition for whom blood is needed may be critical. Institutions: Wants to record blood delivery accurately & automatic, fast update of records. Precondition: Operator is identified & authorized. Success Guarantee (Post conditions): Blood delivery with associated information is saved. Main Success Scenario: 1. Client arrives for taking blood. 2. Operator verifies his papers and demand of blood. 3. Operator starts a new delivery. 4. Operator enters Id 5. Operator uses use case (Uc5): Process Deliver Blood Free. 6. Operator repeats step5. 7. System operator takes taka 50 from Client. 8. Operator updates balance. Extension: *a At any time system fails: To support recovery ensure all transactions can be recovered. 1. Operator restarts system, logs in & requests recovery of prior state. 2. System reconstructs prior state. 2a. System detects anomalies preventing recovery 1. System signals error to operator, records the error and enters a clean state. 2. Operator starts a new blood deliver. 1a. Invalid Request: Rejects the request. 2a.Demanded blood bags are not available: Operator logs his demanded information if Client wants. 4a. Invalid Member Id: System rejects the entry, operator retries with correct Id. 7-8a. Financial inability for payment: Operator takes the amount which client can pay & updates balance with the given amount.

3.3.1 Use Case: Process Deliver Blood Free. Success Guarantee (Post conditions): Blood delivery with associated information is saved. Main Success Scenario: 1. Operator starts a new free delivery for client. 2. Operator delivers a bag of required group to the client. 3 Operator enters necessary delivery information. Extension: *a At any time system fails: To support recovery ensure all transactions can be recovered.

1. Operator restarts system, logs in & requests recovery of prior state. 2. System reconstructs prior state. 2a. System detects anomalies preventing recovery 1. System signals error, records the error and enters a clean state. 2. Operator starts a new blood deliver.

3.4 CLASS DIAGRAM

0 .. *

B ag 1 .. * 1 .. *

D onor

S TA F F O th e r s 1 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 1 . .* O n L in e D o n o r F r e e B lo o d 1 .. * 1 E xc h a n g e 1 Mem ber 1 F u lf ille d D e m a n d 1 1 N o r m a lD o n o r

3.5 SEQUENCE DIAGRAM

Sys tem Ope rato r : STAFF

aD o norValidatio nWindo w : Wind ow In te rface

aPhys i cal In foW in dow : Win do w In terface

aWo rke r : STAFF

a D on or : Do no r

aBag : Bag

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

S ys te m O p e rato r : STAFF

aD e live rB lo o d W ind o w : W ind o wInte rfac e

aMe m b e r : Me m b e r

aB lo o d F re e : Fre e B lo o d

aB ag : B ag

aD e m and : D e m and

aB alance : B alance

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 D o n o r .vb H a n d l e E ve n t

C o n tr o l l e r .v b D AO

D A O .vb

E ve n t.vb

L o g in D o n o r F r m M a i n .vb

F r m In s ta n ta n e o u s In fo .vb E xe c u te F u n c ti o n ( )

F rm S e le c t D o n o r T yp e .vb S e l e c tD o n o r Ty pe

F rm D o n o r In fo .vb

O ra c le D a ta b a s e

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 D on or.vb H a nd leEve nt

C o ntro ller.vb

D AO.vb

DAO

Lo gin D o no r

Frm D e m and .vb

Eve nt.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 The raison d'tre behind adopting MVC architecture is the separation of model and view allowing multiple views to use the 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. 5. IMPLEMENTATION SNAPSHOTS In this section some of the implementation of the software has been provided:

Fig: Snapshot of Collecting Donors 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 couldnt 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