_____________________________________
Software Design Document
For
Blood Bank Management System
Prepared by:
Fatima Batool
Hamna Shafique
Sobia Sajid
Tooba Kanwal
Sadia Ahmed
_____________________________________
1. Introduction
1.1 Purpose
The purpose of this study was to develop a blood bank management information system to
assist in the management of blood donor records and ease/or control the distribution of blood
in various parts of the country/city. Without quick and timely access to donor records, creating
market strategies for blood donation, lobbying and sensitization of blood donors becomes very
difficult.
1.2 Scope
The blood management information system offers functionalities to quick access to donor
records collected from various parts of the country. It enables monitoring of the results and
performance of the blood donation activity such that relevant and measurable objectives of the
organization can be checked.
This is not a blood bank, this system stores only the data of the donors. It stores data by donors
name, distance from the city, contact number, blood group etc. So when blood needed the
system search for the perfect donor. This System reduces complexity for find a donor from a
huge database.
1.3 Intended Audience
This document is intended for the following group of people:
Developers for the purpose of maintenance and new releases of the software.
Management of the blood bank.
Documentation writers.
Testers.
1.4 References
www.google.co.in
robotics.ee.uwa.edu
https://www.researchgate.net
Chevy Chase Bank, UMBC Branch
Online
http://robotics.ee.uwa.edu.au/courses/design/examples/example_design.pdf
1.5 Summary
The purpose of this study was to develop a blood management information system to assist
in the management of blood donor records and ease/or control the distribution of blood in
various parts of the country basing on the hospital demands. Without quick and timely
access to donor records, creating market strategies for blood donation, lobbying and
sensitization of blood donors becomes very difficult. It enables monitoring of the results
and performance of the blood donation activity such that relevant and measurable
objectives of the organization can be checked. It provides to management timely,
confidential and secure medical reports that facilitates planning and decision making and
hence improved medical service delivery. The reports generated by the system give
answers to most of the challenges management faces as far as blood donor records are
concerned.
2. System Overview
2.1 Product Perspective
The main objective of the study was to create electronic blood donor management
information system in order to assist in the management of blood donor records, planning
and share information in a more confidential, convenient and secure way using modern
database and information. The Organization will be more dynamic to their activities of
store and contacting with the users and donors.
3. Design Considerations
3.1 Product Functions
Interface
User Interface
Admin Panel
Communication Interface
Functional requirements
Login of admin.
3.2 Assumptions and Dependencies
Hardware never fail
Highly Trained Dataset
System Security
Alert System
3.3 Goals and Guidelines
User friendly interface.
User can easily find and choose a donor accordingly by the blood group.
Find with location or address.
Donors details Information
3.4 DESIGN VIEW POINTS
Design Viewpoints with respect to stake holders are given below:
3.4.1 Context View Point
Context View Points show the functionality provides by the design. The actors of the system such
as users and other stakeholders are used as reference to describe the context and these actors
interact with the design objects. Black box view of the design is demonstrated by this view point.
Services are related with actors which are using information flows.
3.4.1.1 Design Concerns
The one major service category to which our system is concerned is user. Users are those who will
use the system. The main objective of context view point is to describe scope of use and
functionality of design subjects. It also categorizes actors and services of system and also draws
system boundaries. So major design concern is to identify all services of system and flow of data
between design subject and its environment.
3.4.1.2 Design Elements
External Entities: End Users (donor), Developers, Admin, Verification System, Patient, Blood
Bank.
Services: Signup, Login, View information, Update information, delete information, Search
blood, Donate blood, Receive blood, Store blood, Transact blood.
3.4.1.3 Use case Diagram
Use case diagram represent the connection between different actors and elements of the System.
It describes and simplifies the requirements of the system. All the actors within the system have
different designated roles.
Admin
Figure 1 Use Case Diagram Admin
Blood Bank
Figure 2 Use Case Diagram Blood Bank
Donor
Figure 3 Use Case Diagram Donor
Patient
Figure 4 Use Case Diagram Patient
Actors:
Primary Actors: Donor, Patient
Secondary Actors: Admin, Blood Bank.
Use Cases:
Register
Manage Blood Bank
Manage Donor
Manage Patient request
Add new Blood Bank
Manage stock
Donate Blood
Request Blood
3.4.2 Interaction Viewpoint
This view point describes the collaboration procedure between the system objects, it describes the
level and how activities arise at a particular level.
3.4.2.1 Design Concerns
Evaluate the responsibilities to be allocated in the collaboration procedure. Detect the connections
to be made for the necessary activities in the form of messages between the existing entities of the
system. It identifies the logic for different state transitions, communication within the system.
3.4.2.2 Design Elements
Objects: User, System, Database.
3.4.2.3 System Sequence Diagram
System Sequence diagram is used to show the interaction between the entities of the system
under particular circumstances and at a particular time.
Figure 5 Admin Sequence Diagram
Figure 6 Blood Bank Sequence Diagram
Figure 7 Donor Sequence Diagram
Figure 8 Patient Sequence Diagram
3.4.3 Structure Viewpoint
The structure viewpoint is used to document the internal division and organization of the design
subject in terms of like element (recursively).
3.4.3.1 Design Concerns
Compositional structure of coarse-grained components and reuse of fine-grained components.
3.4.3.2 Design Elements
Design entities:
User, Admin, Blood Bank, State, City, Location, Donor Request, Patient request.
Design attributes:
User: CNIC, Fist Name, Last Name, Gender, Contact, Date of Birth, Email, Password
Admin: ID, Email, Password
Blood Bank: ID, Name
City: ID, Name, State ID, State Name.
Location: ID, Name, City ID.
Donor Request: Donor ID, Blood ID, Donor Name, Location ID.
Patient Request: ID, Blood ID, Location ID.
Design constraint:
User: Login, Sign Up, Make Request, View Service, Feedback.
Admin: Login, Manage Donor, Manage Patient, Manage Blood Bank.
Blood Bank: Login, Manage Request, Manage Donor.
New Donor Request: Check Donor, Add new donor.
Patient request Location: Check service, Request service.
State: Provide state, Provide state wise city, provide city wise location.
Figure 9 Blood Bank Management System Class Diagram
3.4.4 Logical Viewpoint
The goal of the logical viewpoint is to intricate prevailing and intended types and the static
association with classes and interfaces of their application.
3.4.3.3 Design Concerns
Design Concerns includes static structure represented by classes, interfaces, and their
relationships, reuse of types and its implementations (classes, data types).
3.4.3.4 Design Elements
Design entities:
Donor, Hospital, Patient, Admin, Database, Donate Blood, Request Blood.
Design attributes:
Donor: ID, Name, Location
Hospital: ID, Name, Address
Admin: ID, Name
Donate Blood: ID, Type.
Request Blood: Blood Type.
Database: DB Name.
Objects:
Donor
Patient
Hospital
Admin
Database
Donate blood
Request blood
3.4.3.5 UML Object Diagram
An object diagram shows a whole or factional view of the structure of a modeled system at a
particular period of time. Object diagrams are a derivative of class diagrams therefore are
dependent on them. Object diagrams basically demonstrate an instance of a class diagram. The
object diagram also depicts the static view of system but this view is a snapshot of the system at a
specific instant.
Figure 10 Blood Bank Management System Object Diagram
State Transition Diagram:
Figure 11 State Transition Diagram of Blood Bank Management System
Activity Diagram:
Figure 12 Activity Diagram for Admin
Figure 13 Activity Diagram for Blood bank
Figure 14 Activity Diagram For Donor
