Sds

AN ANDROID BLOOD BANK SYSTEM
SOFTWARE DESIGN DOCUMENT
MUGERWA BRIAN MARK
14/UG/176/BSSE-S
(APRIL, 2018)

i
Table of Contents
1.0 INTRODUCTION ..........................................................................................1
1.1 Purpose.........................................................................................................1
1.2 Scope.............................................................................................................1
1.2.1 Goals of the project...............................................................................2
1.2.2 Objectives of the project.......................................................................2
1.3 Over view......................................................................................................4
1.4 References...........................................................................................................5
1.5 Definitions and Acronyms ..........................................................................5
2.0 SYSTEM OVERVIEW .....................................................................................6
3.0 System Architecture .......................................................................................7
3.1 Architectural Design.......................................................................................7
3.2 Decomposition Description ............................................................................7
3.2 Use Case Diagram of the proposed system ...............................................9
3.2.1 User.........................................................................................................9
3.2.2 Admin.......................................................................................................10
3.2.3 Blood Bank ..............................................................................................11
3.3 Sequence diagrams....................................................................................12
3.3.1 The sequence diagram for the Admin...............................................12
3.3.2 sequence diagram for registration ........................................................14
3.3.2 Sequence diagram for request blood.................................................16
4.0 DATA DESIGN.............................................................................................18
4.1 Data Description........................................................................................18
4.1.1 Structured design....................................................................................18
4.1.2 System Processing Transformation...................................................18
4.1.3 Input transformation ..........................................................................18
4.1.4 System Design......................................................................................18

ii
4.2 Data Dictionary..........................................................................................18
4.2.1 Structure for Admin..........................................................................18
4.2.2 Structure of the bloodbank ................................................................19
4.2.3 Bloodrequest........................................................................................19
4.2.4 user .......................................................................................................19
5.0 COMPONENT DESIGN .............................................................................21
5.1 Components of the system............................................................................21
5.1.1 Log component........................................................................................21
5.1.2 UI Component .....................................................................................21
5.1.3 GPS module .........................................................................................21
5.1.4 Search component...............................................................................21
5.2 Algorithms of the system function...........................................................21
5.2.2 Registration..........................................................................................21
5.2.3 Login.....................................................................................................24
5.2.4 Locatehospitalonmap..........................................................................24
5.2.5 Request blood ......................................................................................24
6.0 HUMAN INTERFACE DESIGN................................................................26
6.1 Overview of User Interface..........................................................................26
6.2 Screen Images ............................................................................................26
7 REQUIREMENTS MATRIX.........................................................................29

1
1.0INTRODUCTION
1.1 Purpose
This design document describes the architecture and system design of the android
blood bank system. This software design document is intended to be used by blood
banks, the hospitals and the end users of the system who do include the blood
donors and the blood receivers. so as to understand properly how the blood bank
system will be used.
1.2 Scope
The android Blood Bank system is a GPS mobile based Application which helps
users find the nearest blood bank available on the current user’s current position
and other specification like Donor, Blood type among others. This application
should be free to download either from a mobile application store or from other
services.
Blood Donors can provide their information such as name, address, and other
personal information along with their details of blood group and their other
medical information. This information will act as the bases for the search results
displayed to the user. The Admin is the only one who can have access to the
database where the blood banks and hospitals are stored. The Administrator for
instance is the only one who can view the private and confidential data of the
users.
Furthermore, the system(software) needs both internet and GPS connection to fetch
and display the results. All donor information is maintained in the database which
is located on the web server. The system also interacts with the GPS-Navigator
software which requires to be already installed on the user’s phone. By using the

2
GPS-Navigator, the user can get the exact path from his/her location to blood bank
or hospital.
1.2.1 Goals of the project
I. To reduce the time to a great extent that is spent in searching for the right
donor and the availability of blood required.
II. To interconnect all the blood banks, hospitals, donors into a single network,
validation, store various data and information of blood and health of each
individual.
1.2.2 Objectives of the project
1.2.2.1 Main Objective
To develop a mobile based blood bank system that supports patients in emergency
cases to locate blood in blood banks
1.2.2.2 Specific Objectives
I. To study the current system of locating blood and blood banks in Uganda
and identify the requirements of a mobile-based blood bank system
II. To design a mobile based blood bank system
III. To implement the designed mobile-based blood bank system
IV. To test and validate the implemented system.
1.2.2.3 Benefits of the project
I. This system is used to view all the donor details and accordingly select the
right donor
II. This system also eases the process of getting blood by those in emergency
cases in that one can search for the blood bank/donor having the blood type
he/she wants thus helping to solve the problem of blood deficiency thus
helping to save life.

3
III. This system can also help the users to keep track of all the latest updates
relevant to the people who donate blood and those who had donated blood in
case of emergency cases.
IV. This mobile application therefore helps the people in emergency cases
search for the blood banks/ blood donors who are nearer to them thus this
helps to save time in that one doesn’t have to go looking for blood in the
hospitals thus saving life.

4
1.3 Over view
This document therefore contains an overview of the system which shows a
general description of the functionality of this mobile based blood banks system.
This section contains an over view of the Software Design Document for the
proper understanding of the Users of this document. The designs which are in this
document do include the system architectural, the data design, the component
design and the human interface design.
With the system which enables the readers of this document understand the
architecture of this system who are the system users and the administrators. The
system architecture comprises of the architectural design which therefore show a
system’s module structure and shows the relationship between these modules,
therefore helping the users to understand the complete functionality of the system.
Also, the system architecture contains the decomposition description of the
subsystems in the architectural design, in the decomposition description, which
shows the top-level dataflow diagram (DFD) and the structural decomposition
diagrams.
This section has the data design which involves data description that shows how
the data/information is transformed into the data structures, and also explains how
the system entities are being stored, processed and organized and also lists the
databases being used. This also has the data dictionary which lists the major data
along with their types and descriptions
With the component design, this looks at the functionality of each component in a
more systematic way and also provides an algorithm for each function listed in the
component decomposition in the procedural description language.

5
With the human interface design, this describes the functionality of this system
from the user’s perspective in that this shows how the users of this mobile blood
bank system will easily be able to interact with it. It includes the screen shots
showing the interface from the user’s perspective and also discusses the screen
objects and the actions that are associated with the objects.
This document also includes the requirements matrix which shows how the system
components satisfy each of the functional requirements being described in the
Software Requirements Specification.
1.4 References
B. Brugge, A. D. (2000). Object Oriented Software engineering. conquering
complex and changing systems. Prentice Hall, Upper Saddle River, NJ.
Joan, P. A. (2004). Web Publishing System, Software Requirements Specification.
M. Bauer, A. M. (2000). Requirements Analysis Document.
1.5 Definitions and Acronyms
GPS: Global Positioning Satellite, this therefore enables to the location of the
specific
OO: Object Oriented.
Admin: Administrator, this is an individual who manages the system
DFD: Data Flow Diagram, this document describes the architecture of the system
and also shows how data flows in the system.
SRS: Software Requirements Specification, this document lays out functional and
nonfunctional requirements.
UI: User Interface, this is the means by which the user interacts with the system

6
2.0 SYSTEM OVERVIEW
This project extends the functionality of the android blood bank system. This
project therefore shows how this system which is the Android Blood Bank system
will provide functions to its users in that how the donation process is to take place
within the system. This system was designed and developed keeping in mind that it
should be user friendly. Searching for blood by the blood receivers within the
system is easy and this system has a good and easy display for the user thus this
enables the user to ease his use of this system. The interface therefore of this
system is user friendly, that is, it is easily understood by the users of this system.
The system is mobile/android based and the user can have access to the system
using his/her mobile phone and when there is an internet connection. The interface
of this system is flexible enough such that it can adjust itself according to the size
of the mobile gadget.
The system therefore helps users who are in emergency need of blood to get it in a
very short time, so, this system has a module where a user can request for blood
from any blood bank.
u

7
3.0 System Architecture
3.1 Architectural Design
This architectural design defines the structure and the behavior of this mobile
based blood bank system. this design defines the system components and provides
a framework for which the subcomponents are integrated together to implement the
overall system.
user
Network/internet
conection
Mobile blood
bank system
Figure 1 architecture design of mobile blood bank system
3.2 Decomposition Description
Level 0 DFD: Mobile Blood Bank System

8
Blood
Update system
registration
Admin
Donor
Blood
Bank
recepient
Figure 2 Level 0 DFD of the mobile blood bank system
The figure above shows the flow of information in the android blood bank system
which shows three people who interact with the system and these are the blood
coordinators who is the Administrator, the donors and the receivers who are the
system users in general. The receiver interacts with the system by asking for blood
and also finding the donors and even the nearest blood bank

9
3.2 Use Case Diagram of the proposed system
3.2.1 User
User
Registration
Edit personal profile
Login
search blood bank
view blood stock
request blood
Figure 3 system user use case diagram of the mobile blood bank system
Primary Actor: user
Description

10
The user can register into the system and edits all his/her profile
The user logs into the system for which he is authenticated and he can search for
blood bank in which he can view blood in a blood bank and even he/she can make
a request for the blood in a blood bank.
3.2.2 Admin
Admin
Registration
Login
manage blood bank
manage donor
manage blood requester
Figure 4 Admin use case diagram of the mobile blood bank system
Actor: Admin

11
Description
The Admin registers into the system for which if he is to access the system, he first
logs in. the Admin after accessing the system he can manage the blood banks in
which he can add, edit and also delete a blood bank. He can also manage the users
of the system who are the blood donors and the blood requesters.
3.2.3 Blood Bank
bloodbank
register
Store blood
Manage stock
Figure 5 Blood bank use case diagram
Actor: Blood Bank
Description
A blood bank can be registered where the blood bank is used to store the blood.
Also, the blood bank manages the blood stock of the blood being stored.

12
3.3 Sequence diagrams
3.3.1 The sequence diagram for the Admin
Admin Login
Add
blood
bank
view
blood
bank
Edit/
delete
blood
bank
Donor
details
Blood
required Logout
1 Success
2. Failure
3. Add Blood
4. View Blood
5. Edit/Delete
6. Donor
7. Blood Required
8. Logout
Figure 6 Admin sequence diagram
This sequence diagram shows the interaction between the Admin with the
proposed system.
1. Success, this means that once the Admin has logged into the system, then the
success information will appear telling the Admin that he has successfully
logged in
2. Failure: this means that the Admin in case he hasn’t provided the correct
credentials, let me say the password, then he will fail to log into the system
3. Add blood bank, this means that once the Admin is logged into the system,
then he can be able to log into the system

13
4. View blood, this means that once the Admin has accessed the system, then
he is able to view the blood banks which are available within the system.
5. Edit/delete, this means that the Admin is able to add and delete the blood
banks.
6. Donor details, the Admin therefore is able to view the details of the users,
that is the donors within the system

14
3.3.2 sequence diagram for registration
User client:registration class:register Database
1. enter reg info
2. validate() validation failed
5. check email
availability
6. [is available]:Email available
3. show validation
error message
. 7. show email
existing message
8. No email exists
4. register
9. insert querry
10. status
Figure 7 Registration sequence diagram

15
1. The user enters registration information: this means that the user will first
enter their details/information before clicking the registration button so as to
register into the system
2. validate () validation failed, this means that the user has to input each and
every information which is required in the system. once they fail to put each
and every information they are required of for them to register into the
system, then the validation fails
3. show validation error message, here, this means that once the validation of
the user has failed at the time of registration.
4. Register, this means that once the user has input all the information required
of him in the system, then they will be able to successfully register.
5. [is available]: email available, this means that once they are registered into
the system, then the users’ credentials including the email should be stored
in the database.
6. Show email existing message, this means that if the user’s email exists
within the database, then it will bring the email exist message.
7. No email exists, this means that if there is no email stored in the database,
then a message of no email exists will pop up.

16
3.3.2 Sequence diagram for request blood
user
client:request
blood
class: request
blood
database
1. enter blood request
information
2. validate():validation failed
3. show validation
error message
4. request blood
5. insert query
6. status
Figure 8 Request blood sequence diagram of the system

17
Enter blood request information, here, the person requesting for blood must input
the request information which must include the blood type they want, among
others.
1. Validation (): validation failed, here, the proper blood type must be input by
the requester who is going to request for blood
2. Show validation error message: the validation error message is brought if at
all the requester hasn’t requested for the proper blood type which is stored in
the system.
3. Request blood, this means that if the requester has input a valid blood type,
then they can be able to make a request for the blood.

18
4.0 DATA DESIGN
4.1 Data Description
4.1.1 Structured design
structured design is a design process by which a program is partitioned into
independent modules, each with a unique task, that is, functional decomposition, in
order to make the program easier to implement and maintain. A structured design
is obtained by transforming the data flow diagrams into structured chart. Each
process on the data flow diagram is to be transformed into a single module.
4.1.2 System Processing Transformation
This type of transformation is responsible for processing functions within this
proposed system. It is not concerned with any input, or output function like reading
and writing data or data validation among others.
4.1.3 Input transformation
This transformation is concerned with reading data, checking data among others.
4.1.4 System Design
The system design reflects how the proposed system, which is the mobile blood
bank system, does look like. All the users of this system are supposed to logon to
the system, with their phone number as their username and their password. Once
they are logged in, they (users) are able to access and interact with the system.
4.2 Data Dictionary
4.2.1 Structure for Admin
Sno Columnname Datatype Constraint
1 AutoId int(100) Primary key
2 Fullname Varchar(100) Not null
3 Phone Varchar(100) Not null
4 Username Varchar(100) Not null
5 Password Varchar(100) Not null

19
4.2.2 Structure of the bloodbank
Sno Column name Data type Constraint
1 Autoid int(100) Primary key
2 Fullname varchar(100) Not null
3 Email varchar(100) Not null
4 Contact varchar(100) Not null
5 location_address varchar(100) Not null
6 Since varchar(10) Not null
7 Profileimage varchar(100) Not null
8 gps_cordinates varchar(150) Not null
4.2.3 Bloodrequest
1 autoId int(100) Primary key
2 userId varchar(100) Foreign key
3 bloodType varchar(100) Not null
4 Description varchar(100) Not null
5 Status varchar(100) Not null
6 bloodbankId int(100) Foreign key
4.2.4 user
1 autoId int(100) Primary key
2 Fullname Varchar(100) Not null
3 Sex Varchar(100) Not null
4 Email Varchar(100) Not null
5 Contact Varchar(100) Foreign key
6 Address Varchar(100) Not null
7 City Varchar(100) Not null
8 Bloodgroup Varchar(100) Not null
9 Username Varchar(100) Not null
10 Password Varchar(100) Not null
11 Profileimage Varchar(100) Not null
12 Points Varchar(100) Not null

20
13 joinDate Varchar(100) Not null
14 donateDate Date Not null

21
5.0 COMPONENT DESIGN
5.1 Components of the system
5.1.1 Log component
The log component is only used for logging. Different individuals can log into the
system with different mobile phones thus there is multiple logging into the system.
The log component helps the users access the system by entering their unique
phone numbers which do act as their usernames and their passwords.
5.1.2 UI Component
This is the component which enables the users interact with the system. users
therefore use this component to interact with the system. the component is simple
thus making it possible for the user to interact with this mobile blood bank system
easily.
5.1.3 GPS module
This the component which enables the users of the system to search the location of
the available blood banks with in the system. this component therefore helps the
individuals do the locate the blood banks having the blood type that particular user
needs thus making it easy to get to that particular blood bank.
5.1.4 Search component
This component therefore enables a user search for a particular blood bank
available within the system. therefore, with this module, a user is able to search for
the blood bank which has the blood type that particular user, in this case, the user
is the patient.
5.2 Algorithms of the system function
5.2.2 Registration
Pseudocode for user registration
If (first time entry)

22
{
Load user registration form
}
Else
{
email==check whether input email is valid
name==check whether input provision of name is not empty
password==check whether the input provision of password is not empty
phone==check whether a valid phone number is fed in the form
sex==check whether the provision of sex input is not empty
dateofbirth==check whether the input provision of the dateofbirth
age==check whether the input provision of the age is not empty
blood group==check whether the input provision of the blood group is not empty
if(results==true) {
connect to the database
} else
{
submit
} else
{
Load registration form
If (email ==empty) {
display this is a required field
endif
}

23
If (name==empty) {
endif
}
If(password==empty) {
endif
}
If (bloodgroup==empty) {
endif
}
If(address==empty) {
endif
}
If(phone==empty) {
Display this field is required
endif
}
If(sex==empty) {
display this field is required
endif
}
If(dateofbirth==empty) {

24
endif
}
If(age==empty) {
endif
}
5.2.3 Login
Pseudocode for login
Initialize parameters to access data (phone number and password)
If parameters are equal to empty {
Alert box, please enter phone and password
}
Else {
Go to user page.
}
5.2.4 Locatehospitalonmap
Pseudocode for Locatehospitalonmap
Input map codes for a particular hospital
If map codes are true {
Alert, map has been found
}
5.2.5 Request blood
Pseudocode for requesting for blood
Search for a blood bank
If the blood bank has blood required {

25
Request for blood
} else {
Continue searching
}

26
6.0 HUMAN INTERFACE DESIGN
6.1 Overview of User Interface
With the user interface, on the side of the users, he/she can login to the system or if
he is not registered into the system, then there is a provision of an option of signing
up/registering into the system. For the users, when they are signed into the system,
they are then directed to the page having the user’s profile, the available blood
banks and even the location of the user and the blood banks which are available in
the system, the user can request for blood from a particular blood bank.
With the admin, he/she after logging into the system, then they can manage the
blood banks in a way that they can edit, delete, view the details of the users of the
system, the admin therefore can do all this with his/her mobile phone.
6.2 Screen Images
The user Login page
Blood Life
Only 3 minutes can save 2 Lives
username
password
Remember me
Login
The user therefore has an option of either signing up or logging into the system.
The user can login with his/her phone number which is being used as the user
name and even there is a provision of the
Login
signup

27
So, with this module, a user after logging in is able to access the home page of the
system which has the blood banks, the location of the user in respect to the blood
bank and even the profile of the user. With the profile of the user, there is a
provision of his blood group, his age, the user’s phone number, the user’s location
and his/her sex.
The user registration page
Register here
Choose blood group
Your full name
Choose sex
Year of birth e.g. 1995
Email address
Phone number
Address
Phone number is user name
Password
Forgot your password?
signup
Login

28
The user blood request page
This page shows the user requesting for blood, it has the choices of the blood
group from which the user can get the type of blood he/she wants and the
description of the.
Admin login page
Admin username
password
The admin can log into the system and after logging in, he/she is taken to a page
which he can view, update, modify and notify the users.
Request blood
Choose blood Group
Your description here!
Log in
send request

29
7 REQUIREMENTS MATRIX
ID Functional
requirement
description
Use case System
module
System
component
FR1 A user can download
the mobile application
through either an
application store on
the mobile phone
Download Downloading The mobile
application
FR2 A user can be notified
of the new release so
that they can be able to
download them
Download Notification
and
Downloading
The mobile
application
FR3 A user registers into
the system and must
provide a user name,
phone number which
acts as the user name,
the email address, the
password, their blood
type among others
Register User User’s
profile/data
FR4 A user use their unique
phone numbers and
passwords as their
login details to access
the system
Log in User Login
component
FR5 The user can retrieve
the password incase
he/she has forgotten
their passwords
Retrieve
password
User Forgot the
password
component
FR6,
FR7,
FR8,
FR12,
FR13,
FR14,
Given that the user is
logged into the system,
they can be able to
search for a particular
blood bank according
to the blood type, to
the destination among
others
Search for
blood bank
Searching Search
component

30
FR9 A user is able to
navigate to the blood
bank which has the
blood type that
particular user wants
Navigate to
the blood bank
Navigation GPS
component
FR10 A user provided he
accesses the system,
he is able to switch
between a map view
and a list view while
searching for the blood
banks
Search for the
blood bank
Searching Search
component
ID Functional
requirement
description
Use case System
module
System
component
FR16 A user has a profile
page on the system
where he can edit
his/her information
which includes the
email, phone number
among others
Edit, update
data
User user
data/profile
FR17 The admin logs into
the system using his
username and the
password
Registers Registration The admin
details
FR18 The Admin can add
new blood bank, edit
an existing blood bank
and deleting a blood
bank
View blood
banks
Admin Blood bank
FR19 The Admin can add a
new donor, edit
existing blood donor
and delete a blood
donor
View blood
donors
Admin Blood donor
records

31
List of figures
Figure 1 architecture design of mobile blood bank system .......................................7
Figure 2 Level 0 DFD of the mobile blood bank system ..........................................8
Figure 3 system user use case diagram of the mobile blood bank system ...............9
Figure 4 Admin use case diagram of the mobile blood bank system......................10
Figure 5 Blood bank use case diagram ....................................................................11
Figure 6 Admin sequence diagram ..........................................................................12
Figure 7 Registration sequence diagram..................................................................14
Figure 8 Request blood sequence diagram of the system........................................16

Sds

Recommended

Recommended

More Related Content

Similar to Sds

Similar to Sds (20)

Recently uploaded

Recently uploaded (20)

Sds