SIM UNIVERSITY

braintreesmileSoftware and s/w Development

Aug 15, 2012 (5 years and 2 months ago)

757 views


SIM UNIVERSITY

SCHOOL OF SCIENCE AND TECHNOLOGY









LIBRARY DELIVERY SYSTEM

(Fulfillment)














STUDENT


:
NG KOO
N

LENG

(
E0706790
)

SUPERVISOR

:
MR. KOH

KIM BOON

PROJECT CODE

: JUL2009/
ICT
/013




A project report submitted to SIM Universi
ty

in partial fulfi
l
lment of the requirements for the
BSC (HON)

in Information & Communications Technology


May 2010


ABSTRACT


This project aims to develop a

Library Delivery System
comprises of a
comprehensive suite of library services and an effective

backend management
capability, allowing patrons to loan or reserve materials through the Internet,
eliminating the effort of physical catalogue browsing, loaning and collection.


This system will also aid corporations that would like to have their in
-
hou
se
library outsourced and managed by a centralized resource repository centre.


The comprehensive search function
of this web
-
based system
allows patrons to
browse and identify the materials they wanted within a shorter time span, which
followed by a
serie
s of
quick
-
and
-
easy steps for loaning or placing reservation for
the selected material(s).

This information
is immediately

forwarded to the library’
s
backend
crews

as well as the engaged 3
rd

Party Courier Delivery Service, which
will work collaboratively t
o ensure that the materials reached the patron(s) within
the time stated.


The system also allows Library staff to define the layout of the physical Library so
as to allow customi
zation of the picking sequence
according to the Library Staff’s
preference
, a

similar approach to Warehouse Management process
.


Getting the 3
rd

Party Courier Delivery Service involved in the system
revolutionized the conventional library work
flow, as
they now p
lay important role
in digitalizing the entire workflow into paperless
transaction(s)

and ensure
effective/efficient delivery of the loaned materials to the hands of the patrons
.




ACKNOWLEDGEMENT





I am heartily thankful to my Project Supervisor, Mr. Koh KIM BOON, whose
encouragement, guidance and support from the initia
l to the final stage of the
project had enabled me to develop an understanding of my project topic which
contributes greatly to the development of the LDS system.


I would like to thank the administrative committee for this Final Year Project for
their gu
idance and assistance.


Lastly, I would like to thank my manager, Ms Sharon Lim, (ST Electronics LIS
O&S), for her understanding and support.




TABLE OF CONTENT


INTRODUCTION

................................
................................
................................
..

1

1.1 BACKGROUND

................................
................................
...........................

1

1.2 OBJECTIVES

................................
................................
..............................

4

1.3 PROJECT SCOPE

................................
................................
......................

5

1.4 PROPOSED APPROACH AND METHODS
................................
................

6

PROJECT PLANNING

................................
................................
..........................

7

2.1 PROJECT MANAGEMENT METHODOLOGY

................................
............

7

2.1.1 ROJECT INITIATION

................................
................................
............

8

2.1.2 PROJET PLANNING

................................
................................
............

9

2.1.3 PROJECT EX
ECUTION

................................
................................
.....

10

2.1.4 PROJET CLOSURE

................................
................................
...........

10

2.2 IDENTIFYING SOFTWARE DEVELOPMENT LIFECYCLE

......................

11

2.3 REQUIREMENT ELICITATION

................................
................................
.

13

2.3.1 IDENTIFYING ACTOR(S)

................................
................................
...

13

2.3.2 FUNCTIONAL REQUIREMENTS

................................
.......................

14

2.3.3 NON
-
FUNCTIONAL REQUIREMENTS

................................
..............

16

2.4 SYSTEM ANALYSIS

................................
................................
.................

17

2.4.1 DYNAMIC MOD
ELLING

................................
................................
.....

17

2.5 SYSTEM DESIGN

................................
................................
.....................

24

2.5.1 SYSTEM ARCHITECTURE

................................
................................

24

2.5.
2 DATABASE MIDDLEWARE COMPONENT

................................
.......

25

2.5.3 DATABASE MANAGEMENT SYSTEM

................................
..............

25


2.5.4 CORE SYSTEM FLOW

................................
................................
......

26

2.5.5 SYSTEM POLICY/ASSUMPTION(S)
................................
..................

27

2.7 IMPLEMENTATION

................................
................................
..................

30

2.7.1 DATABASE IMPLEMENTATION

................................
........................

30

2.7.2 JAVA ENTITY CLASS CREATION


HIBERNATE REVERSE
ENGINEERING METHOD

................................
................................
...........

33

2.7.3 SYSTEM INTERFACE DESIGN

................................
.........................

34

2.7.4 MODULE DEVELOPMENT SEQUENCE

................................
...........

35

2.8 TESTING

................................
................................
................................
...

38

UNIT TESTING

................................
................................
............................

39

FUNCTIONAL TESTING

................................
................................
.............

43

DATABASE PERFORMANCE MONITORING

................................
.............

45

CONCLUSION

................................
................................
................................
....

46

CRITICAL REVIEW

................................
................................
.........................

46

EXPERIENCES AND LESSONS LEARNT

................................
.....................

47

FUTURE IMPROVEMENT

................................
................................
..................

49

REFERENCES

................................
................................
................................
...

52

APPENDIX

................................
................................
................................
..........

54

APPENDIX A


Koha© ILS (Patron GUI)

................................
........................

54

APPENDIX B


Koha© ILS (Administrator GUI)

................................
..............

56

APPENDIX C


PROJECT GANTT CHART

................................
...................

58

APPENDIX D


Use Case Diagrams

................................
...............................

59

APPENDIX E


Sequence Diagrams

................................
..............................

69


APPENDIX F


Illustration of Sequence Diag
ram through Activity Diagrams

.

79

APPENDIX G


Identifying Associations

................................
.........................

91

APPENDIX H


Modeling State
-
Dependent Behavior of Indi
vidual Objects

..

103

APPENDIX I


SQL Triggers

................................
................................
.........

105

APPENDIX J


System Codes

................................
................................
......

108







Page
1


INTRODUCTIO
N


1.1 BACKGROUND


The practice of contracting for the provision of specific services by parties outside
of an organization, a term called Outsourcing, has been around in the business
world since the last decade. The idea, the concept, that has evolved to
become
part of reengineering revolution, allows organizations to focus on their core
functions and mission
-
critical activities, and also reduce operational costs. More
importantly, it allows the company to gain access to world class capabilities,
having op
erational expertise to handle their outsource process to push the
corporate overall efficiency to a greater height.


This has marked the main objective of the LDS, zooming our focus onto
providing a whole suite of quality library services to companies, to
omit the
necessity of establishing in
-
house libraries and pooling of additional resources
(space, manpower and funds to purchase updated materials etc).


The conventional transaction flow in the libraries that includes manual searching
of items through th
e shelves or through the information counter, to the queuing
up for loan behind the kiosk counters, will entirely be replaced with just a series
of mouse
-
clicks and the items will be delivered right to their doorsteps in short
moments.


E
-
Cataloguing with

advanced search options will be incorporated to allow patrons
to search for their items at ease. Selected items will be placed under temporary
reservation in the form of a shopping cart. The physical queuing for loan process
is replaced with simple identi
fication verification and confirmation. Through
contributing a small subscription amount, the patrons will also enjoy the luxury of
receiving and returning the loaned items at the designated date and timing of
their choice, through the 3
rd

party courier se
rvice provided by the library.


Page
2



The LDS project is divided into 2 portions, the Patron Interface and the Delivery
Fulfillment. The Patron Interface is handled by another project team, which is to
develop the frontend application for patrons to browse throu
gh the catalogue,
selecting and loaning items and the option for delivery. The Fulfillment part will
be the backend processing of confirmed delivery requests, through an interface
that forwards all the request data captured at the Patron Interface part.


The Fulfillment process involves packaging of requested items into bundle/kit
(both physically by librarian and logically grouping by the system), followed by
forwarding this request information in the form of alerts to the 3
rd

Party Courier
Company via a

common dashboard within LDS. The Courier Company then will
collect the bundle(s) and delivery according to the stated addresses. The reverse
process applies, where patrons may request for return delivery service. And after
the items are physically deliver
ed back to the library, the librarians will sort, shelf
and update the status of the item in the system accordingly.


Deriving a new loan policy is necessary; to incorporate the new service we are
developing. This will be done by researching on available p
olicies of current
operating libraries, compile and analyze, and finally structure the new policy. This
new policy is crucial, as it provides the baseline for the system design and
development phase, ensuring that the interfaces and processing are develope
d
in align with the rules defined within.


Research and experimentations will be carried out on Koha© (
see screenshots in
Appendix A

& B
), an open source ILS that has been in use by several countries’
state libraries. Through exploring this system, it will

allow us to understand
clearer of the library operational process. At the same time, assessment will be
carried out to determine the feasibility of reusing certain features of Koha© (more
time can be focused on development of the newly introduced delivery

service).



Page
3


In review with the project budget and hardware availability, freeware like MYSQL
(open source database system) and Apache Web Server will be ideal for the
development. The two freeware are selected based on their stability and ease
-
of
-
use compa
rison with other similar freeware. Java has been selected as the main
programming language for this project and Netbean™ IDE will be the tool used.



Page
4


1.
2

OBJECTIVES


This project aims to incorporate a comprehensive delivery service capability

in
to

an
Inter
net

Library System

(ILS)
, to allow patrons to borrow
and receive
library
material
(s)

without visiting the library. This
facility

is also targeting to aid
corporations who want to outsource their existing in
-
house library services.


The project will includ
e the following backend fulfillment processes:


a.

Designing of a dashboard to allow backend library staff and 3
rd

party
Courier service provider to manage loan/delivery requests.


b.

Designing of an alerting functionality to the Dashboard to inform the 3
rd

part
y Courier
S
ervice
P
rovider of new/outstanding delivery requests. An
example will be email notification.


c.

Design
and Develop a methodology to categorize/bundle the requests for
the 3
rd

Party Courier Company to perform the physical distribution


d.

Incorporate
the capa
bility of system to capture and arrange for return item
process and setting of item status when it’s returned.


e.

Develop and interface for the 3
rd

party Courier Service Provider to
manage the job requests.


f.

Design and develop a report generation cap
ab
ility for the system, to allow
both

the
Library Staff and Courier Staff to view historical transactions for
auditing or trend analysis purposes.




Page
5


1.3 PROJECT SCOPE


To
develop

a One
-
Stop Library Portal that provides a comprehensive
suite of
library ser
vices, with enhanced delivery facility through the provision of efficiency
backend management and coordination with 3
rd

Party Courier Service Provider.




To develop a One
-
Stop Internet Web Portal that provides a comprehensive suite
of conventional catalog
uing and loan functionalities, and an efficient and
organized backend logistical and delivery management facility that collaborates
closely with 3
rd

Party Courier Service Providers.



Page
6


1.4 P
ROPOSED APPROACH AND METHOD
S


The main approach will first be to re
search and understand the existing library
workflow. This can be achieved by researching on existing open source Library
Systems (i.e. Koha©), and studying the possibility of enhancing it. Detailed
analysis of the open source system(s) play an important ro
le to determine if it is
feasible to enhance on existing system or developing a new one from scratch.


Obtaining examples of current loan policies is also a necessity as we will need to
revise and incorporate the delivery service’s terms and conditions. Th
is revised
policy will be the key to defining the development of the system work flow.


The research on open source systems will also include interface designs (form
structure, naming conventions) and process flow (transaction flow, shopping cart
concept e
tc). Similar concepts will be employed to retain and enhance user
experience and reduce users’ learning curve.


The project will involve hardware and software components, both of which will be
self
-
provided. Virtualization will be employed during the devel
opment of the
system. Apache Web Server will be used to host the website and MYSQL will be
the backend database for the system. Java will be the programming language for
the system.


A systematic procedure of tests, measurements and evaluations will be pl
anned
and carried out to ensure accuracy of the test results and alignment to the project
requirement.


Assistance and guidance will also be provided by the Project Supervisor.


Page
7


PROJECT PLANNING


2.1 PROJECT MANAGEMENT
METHODOLOGY



Figure 2.1
A



Chosen

Project Management Process

[Reference From: MPMM Project Management Guidebook]


The selected project management technique to be used is as shown above, as

referenced from MPMM™, which comprises of stages namely, Project Initiation,
Project Planning, Project Execution and Project Closure.

The comprehensive and
structured processes of this methodology allows for clear establishment of
project objectives, plan
s and the necessary processes required to monitor and
control the project development progress. Furthermore, it is also aligned to the
content set out by the worldwide Project Management Institute (PMI
®
), as defined
within “A Guide to Project Management Bo
dy of Knowledge” (PMBOK
®

Guide).

The adoption a project management plan

(PMP)

serves as a top level guidance
L
L
D
D
S
S


P
P
r
r
o
o
j
j
e
e
c
c
t
t


L
L
i
i
f
f
e
e
c
c
y
y
c
c
l
l
e
e



Page
8


towards the Capstone project. The main development process that will be shown
in this project report will be the software development lifecycle (ne
xt section
following PMP explanation.



2.1.1
ROJECT INITIATION




Figure 2.1
B



Project Initiation Phase

[Reference From: MPMM Project Management Guidebook]


Project Init
ialization basically describes the start of the project, defini
tion of its
scope and

objectives.
The above diagram illustrates one type of steps to be
adopted during project planning stage, where developers will go through studies
to understand the values of providing solution through a new system
development, establishing project scope,
vision and objectives, and physical
structures like establishment of the project team and engaging its members
through skill assessment matrix and setting up of the Project Office. The
information related to this phase in regards to our Project LDS can be
found at
the introductory section of this report.









Page
9


2.1.2 P
ROJET PLANNING



Figure 2.1
C



Project Planning Phase

[Reference From: MPMM Project Management Guidebook]


The next phase of a Project involves detailed planning and coming up with a
suite of

planning documentations (as seen above) to help guide the team
throughout the project. The discussion and common agreement with the Project
Supervisor before the actual commencement of the planning stage of Project
LDS is that this portion has already bee
n structured and the customer has
already signed the Project User Agreement based on the proposal/plan
presented to the customer previously.


Attached in A
ppendix C

is the agreed project timeline (Gantt
c
hart) for Proje
ct
LDS (Fulfillment).













Page
10


2.1
.3 P
ROJECT EXECUTION


Project Execution refers to the actual development stage involving the building of
deliverables and maintaining constant monitoring and controlling on the project.
Time and Risk Management are two such monitoring that will be watched
cautiously in order to ensure that development has been on the correct track and
sticking to the timeline drafted.


During this phase, the selected SDLC model (in the next section) will comes into
play, assisting the development of the system through as se
ries of analysis,
static and dynamic modeling, and system design.




2.1.4 P
ROJET CLOSURE


Commercial project closure process involves releasing of the finalized project
deliveries to the customer, handing over project documentation to the business

and rel
easing project resources. Post project completion review will also be
conducted a couple of months after the deployment.


The entire scope of this Capstone Project ends in its submission to the school for
grading at a fixed timeline stated in the Project
Handbook. A note should be
taken that the Project documentation and handing over will still take place as it is
but post project completion review will be unable to proceed in review of the
project submission.




Page
11


2.2
IDENTIFYING
SOFTWARE DEVELOPMENT LIFEC
YCLE


Apart from adopting a
project management methodology, we will also be
employing a software development process, a knowledge in which I’d learnt in
one of the UniSIM modules, ICT 333/334 (Object
-
Oriented Software Engineering).

Adopting a project manag
ement methodology allows me to understand the
overall requirement of the Capstone Project, from the project initialization stage
to the Closure stage,
monitoring timelines and
enabling me to foresee how the
coding methodology should be in order to cater fo
r Risk and Change
Management etc.
With an SDLC model implemented, the system to be
developed will have a clearer documentation of development, structure and even
coding.

It works hand
-
in
-
hand with a project management plan to achieve a
clearer business vie
w of the system and its expectations, leading to the success
of the system development.


V
-
Model has been chosen as the selected software development process. It is a
model, or rather a set of standards that facilitates the developers on
understanding t
he complexities associated with the development of information
systems.













Figure 2.
2A



SDLC V
-
Model

V
V
A
A
L
L
I
I
D
D
A
A
T
T
I
I
O
O
N
N


V
V
A
A
L
L
I
I
D
D
A
A
T
T
I
I
O
O
N
N


V
V
A
A
L
L
I
I
D
D
A
A
T
T
I
I
O
O
N
N


A
A
N
N
A
A
L
L
Y
Y
S
S
I
I
S
S


&
&


D
D
E
E
S
S
I
I
G
G
N
N


S
S
Y
Y
S
S
T
T
E
E
M
M


I
I
N
N
T
T
E
E
G
G
R
R
A
A
T
T
I
I
O
O
N
N



Page
12


The V
-
model deploys a well
-
structured method in which each phase can be
implemented by the detailed documentation of the previous phase. Testin
g
activities like test designing start at the beginning of the project well before
coding and therefore potentially saves a huge amount of the project time.


In view of the requirements of this Capstone Project and understanding from the
Project scope that

we are more focused towards the software development
process and output, we will be more focused on the SDLC elaborations in this
report, displaying in details the analysis and development processes that went
through.




Page
13


2.3 REQUIREMENT
ELICITATION


2.3.1

IDENTIFYING ACTOR(S)


o

Patrons



Individual



Normal Patron functionality (browse/ reserve/ loan/ delivery/
cancellation)



Transaction log printing



Feedback



Corporate Account



Normal Patron functionality (browse/ reserve/ loan/ delivery/
cancellation)



Transactio
n log printing



Feedback


o

Library Staff



Manage patron accounts



Manage library assets (new/update/delete/transfer)



Generate reports


o

3
rd

Party Courier Company



Check on status of delivery sessions



Receive alerts on updates to delivery session



Update status of

delivery (patron verification, date/time o
f bundle
collection and receive

by patron)



Generate reports for company usage


o

System Administrator



Able to perform all functions of a Library Staff



Account management capabilities




Page
14


2.3.2 FUNCTIONAL REQUIREMENTS


o

Use Case Diagram


The diagram below is the top
-
level view of the LDS system which comprises of both
the Interface and the Delivery Fulfillment portion. The use cases highlighted in
yellow are the ones relevant to the Delivery Fulfillment development.

Patron
ManageAccount
CheckDeliveryStatus
SearchCatalogue
LoanSelectedItems
CancelLoan
ViewTransactLog
LibraryStaff
AddCatalogueItem
GenerateReports
CourierStaff
GenerateDeliveryReport
UpdateAccountParticulars
Administrator
UpdateDeliveryStatus
UpdateCatalogueItem
DeleteCatalogueItem
ManageShelfItems
AddShelf
GeneratePickList
ReserveItem
CancelReservation
ReceiveDelivery
CancelPickItem
PickItem
AcknowledgePickList
AcknowledgeReturnRe
quest
CollectPickList
DispatchPickList
DeliveredPickList
ReceiveReturnReques
t
HandoverReturnReque
st

Figure 2.3A


Project Use Case Diagram


Page
15


o

Detailed Use Case Description


The overall system’s Use Case Diagram will be elaborated into details in this section.


Each Use Case Description is in the form of a table and below
is

the li
st of items
within the table:




Name of Use Case




Participating Actor(s)

o

can be either a user or system




Flow of Event(s)

o

Describes the generic scenario of how the use case took place, how it is
being triggered, the user action(s) involved and the system re
sponse(s)




Entry Condition(s)

o

The pre
-
requisite(s) in order for the use case to be triggered, for instance,
user login requirement, existence of loan records etc.




Exit Condition(s)

o

The expected results at the end of executing the use case. Generally
stati
ng a positive and a negative system response.




Quality Requirement

o

The expected efficiency of both user and system, which can be
either

functional or non
-
functional requirement.


The entire Use Case Descriptions can be found in Appendix D.







Page
16


2.3.3 NON
-
FUNCTIONAL REQUIREMENTS


Category

Nonfunctional Requirement

Usability



Patrons should be able to navigate and perform loan requests easily even
without prior knowledge of the operation of an online shopping cart or any
other online purchase system.



The GUI

of the LDS will be designed to be as much similar to that of the
current Internet Library Systems (ILS) in Singapore. This is to retain user
experience and also to reduce the learning curves for the patrons.


Reliability



Crashes due to Patron’s internet
connection termination should interrupt the
Patron’s current transaction only. Other activities should proceed normally.



Loan Request terminated unexpectedly due to computation error should
interrupt only that particular loan transaction. Other simultaneou
s loan
requests should proceed normally.


Performance



The system must be able to support up to at least 50 concurrent sessions to
the LDS.



All functionalities that require querying to the system database should not
take more than 30 seconds to load.


Sup
portability



The LibraryStaff will be able to add new Catalogue Category or amend the
loan quota. Such addition or amendment does not require any temporary
shutdown of the server or perform any system modification.


Implementation



All users should be able
to access LDS with a web browser supporting
cookies, JavaScript and Java Applets. Server Administrative functions used
by the System Administrator are not available through the web.



LDS should preferably be running on Windows Platform


Operation



A Patron
should not be able to loan more than the fixed quote defined by the
LibraryStaff or System Administrator.



A LibraryStaff should not be able to use the administrative functions to
manage his/her personal Patron account’s loan transaction(s).




Page
17


2.4 SYSTEM
ANALYSIS


2.4.1
DYNAMIC MODELLING


a)

Identification of Objects


Entity Object

Name

Description

Patron

Registered members of the library who are authorized to perform
online catalogue browsing, loan of library materials and requesting
for delivery service.
Patrons are identified by their NRIC number.


LibraryStaff

Employees of the Library, a normal librarian or management staff,
identified by NRIC number. All library staff has rights to manage
loan/delivery issues or generating of reports.


CourierStaff

Em
ployees of the selected 3
rd

Party Courier Company, identified by
NRIC number. They are in
-
charge of the collection and physical
delivery of the loaned items to patrons. They are able to browse
bundle information as well as update delivery status.


Adminis
trator

Person
-
in
-
charge for the system. Handles account management.


Biblio

Registered material in the library (i.e. books, magazines, media
videos, software). It may be added, updated or removed by a
LibraryStaff. It consists of components like
its uniqu
e
identifier, the

title, universal title, notes and copyrights date.


BiblioItem

Referencing the Biblio
entity
, BiblioItem stores extended information
of the same Biblio item, i.e. classification, isbn number, iccn
number, volume number and ownership refe
rence.


Biblio
ItemCopy

Registered Copy of a specific registered material.

It stores
information like the copy ID, pricing, reserve status and loan status.


LoanCart

A temporary storage location for Patrons to reserve library materials
online before confi
rmation of loan.


LoanedItem

The record for the specific item that the Patron has submitted for
loan and delivery. It consists of components like Loan ID, Patron ID,
Item ID, Item Copy ID, Loan Start and Expired Date, Delivery
Status and Transaction Times
tamp.


Reservation

The record of the item in which the Patron has placed his/her
reservation. It consists of components like Reservation ID, Patron

Page
18


ID, Item ID, Item Copy ID, Date of Reservation and the earliest date
of collection.


PickList

The record t
hat is created by the LibraryStaff for the purpose of
sorting the outstanding loaned item records so as to enhance the
efficiency of picking up the items from the physical shelves within
the library itself. One PickList contains at least one PickListItem.


PickListItem

The record that documented down the details of how a particular
loaned item record is being sorted for picking. One PickListItem
belongs to one PickList.


CourierCompany

The entity for storing Courier Company’s information. It is declared
a
s an entity because of the possibility of engaging more than just a
single Courier Company for delivery services.


LayoutMaster

Entity for storing the warehouse/storage space structure of the
physical Library. It stores information like the layout type, i
ts
description, the type priority and precedence type information.


ShelfContent

Entity for storing the location of all the biblio items in reference to
the LayoutMaster entity.


TransactionLog

Entity for capturing all the transactions done by users or s
ystem.
Example of logs are loan records and
picking status update






Boundary Object

Name

Description

CatalogueSearchForm

The search form that allows Patrons to submit their search request
to locate the material(s) they want.


CatalogueItemDetailFor
m

The form that displays the details of the material selected by the
Patron. Some of the items listed include the various copies of that
particular material, loan status, reservation status etc.



LoanCartForm

The form that displays the information of the

materials in which the
Patron has placed under temporary reservation for loan later on.
The form also has function buttons that allows Patron to remove
items from the cart or to commit for loan.


ReservedItemForm

The form that displays all the materials
in which the Patron has
placed reservation on. The form displays information like the
material’s description, current status, earliest date of return by
current loan part and it also has functionality that allows the Patron
to cancel his/her reservation.


Page
19



PickList
_Main
Form

The form that allows LibraryStaff to sort the outstanding loan item
records (yet to hand over to Courier Service) for the ease of
physical picking process in the library.


PickList_Overview

The form that displays all the past and existi
ng picklists.


PickList_DetailedView

The form that displays detailed loan item records of the selected
picklist obtained from PickList_Overview Form.


GeneratePickListButton

The button on the main screen that allows LibraryStaff to generate
a picklist jo
b after all the outstanding loaned items has been
physically picked by the Library Staff. This w
ill then automatically
generate

an email sending to the Courier Service Provider to notify
them that the picklist is ready for collection.



Courier_MainForm

T
he main form presented to Courier Staff after login. It basically
displays a summary of the picklist jobs which includes new jobs
that requires acknowledgement and collections, existing collected
jobs that requires dispatching and past completed jobs.


Co
urier_PLView_Form

The form that displays details of the selected picklist job from the
Courier_MainForm. It displays all the loan item details under the
selected picklist, including information like that delivery location and
corporate name.


AcknowledgeB
utton

A button within the Courier_MainForm that allows Courier Staff to
update to the system that he/she has acknowledged of the creation
of a new picklist job and will be going down to the Library for
collection within the timing stated in the policy agre
ement.


MarkCollected_Button

A button within the Courier_MainForm that allows Courier Staff to
update the status of the picklist after he/she has physically
collected the bundle from the Library.


SetDispatch_Button

A button within the Courier_MainForm t
hat allows Courier Staff to
update the status of existing collected picklist as he/she is about to
commenced the dispatch delivery.


PrintHandoverForm_Button

A button that tags along with SetDispatch_Button, it allows the
Courier Staff to prints a handing
-
taking over form which is for the
receiving patrons to sign on it as a physical tracking/evidence that
the patron has received the loaned item on time.


ViewDetailsButton

A button within the Courier_MainForm that allows Courier Staff to
view the details
of any past completed picklist jobs.


Courier_ReturnRequest_F
orm

A form that displays all the pending return requests raised by

Page
20


patrons. This function is to activate the Courier Service to collect
the loan items from the patrons at their respective corpor
ate and
return to the library
.


Courier_ReturnRequest_C
oyUpdate_Form

Form that displays all the outstanding return requests raised by the
selected corporate. It allows Courier Staff to update the status of
the return requests upon collection.


CollectSel
ectedItems_

Button

This button resides in the Courier_ReturnRequest_CoyUpdate
_Form, which allows Courier Staff to submit after selection, the jobs
in which he/she has physically collected from the patron(s).


UndoItemCollection_

Button

This button resid
es in the Courier_ReturnRequest_CoyUpdate
_Form, which allows Courier Staff to undo the submission he/she
previously did to confirm on the collection of the returning loan
items


ReturnToLibrary_Button

This button resides in the Courier_ReturnRequest_CoyU
pdate
_Form, which allows Courier Staff to update to the system on which
return request items have been physically handed over to the
Library.


Courier_ReturnRequest_

CJS_Form

This form allows Courier Staff to view the past return requests
received and co
mpleted.


MobApp_Courier_Login_

Form

Form for Courier Staff to login while dispatching on site.



MobApp_Courier_Main_

Form

Main Page of the mobile website for Courier Staff while dispatching
on site. It displays all the current dispatching jobs.


MobAd
d_Courier_ListCoy_

Form

Form that displays the list of corporations in which are involved in
the dispatching job. Courier Staff will select one of the corporations
listed to view the details of all the loan items under this corporate.


MobAdd_Courier_List
Coy

Jobs_Form

Form that follows after the selection of a corporate from the
MobAdd_Courier_ListCoy_Form. This form fetches all the
outstanding loan records under the selected corporate, listing the
loan item details including the name of the material and t
he
borrower’s details.

After loading, Courier Staff will select the job
(
s
)

which is/are going to be handed over to the Patron(s) and submits
to the system for updating of the status.


Report_Main_Form

Form for the Library Staff that displays all the possi
ble report
formats allowed to be generated for the Library Staff to analyze
loan trends (peaks and droughts), item popularity and delivery
status etc.




Page
21


GenerateReport_Button

The button in the Report_Main_form that allows Library Staff to
submit to the sy
stem to generate the selected report type and
present the report to the user.






Control Object

Name

Description

PickListController

The controller object that handles the processing of any picklist
-
related functions executed by either the Courier Sta
ff or the Library
Staff.


PickListController

The controller object that handles the processing of individual
picklist item relate
d functions executed by either
the Courier Staff or
the Library Staff, i.e. picking/unpicking etc.


CourierController

The con
troller object that handles all the processing requests
initiated by a Courier Staff account


CMailer

A controller object that handles the emailing capability of any
functions that require email acknowledgement etc.


Controller_CouierManager

A controller

object for Courier Manager account that handles the
administrative functionalities like add/update/delete of Courier Staff
accounts.


LayoutController

A controller object used by Library Staff that handles the processes
of any functions related to the Li
brary’s shelving layout.







Page
22


b)

Mapping Use Cases to Sequence Diagrams


Deriving Sequence Diagrams is to tie the use cases with the identified objects stated in
the previous sections. Most importantly, it allows developers to discover missing objects
an
d refine the requirement specifications as we progress.


Every single use case (in yellow) in relevance to Project LDS
is

translated into their
corresponding sequence diagrams and can be found in Appendix
E
.



c)

Illustration of Sequence Diagram through Activ
ity Diagrams


The Activity Diagrams are translated from the Sequence Diagrams as shown in
Appendix E
, to allow developers to obtain a clearer view on the interaction and process
flow between the user and the system. This enhanced the understanding of the
d
eveloper on the design of the system.


Appendix F has displayed the full list of Activity diagrams of LDS, derived from the
Sequence diagrams shown in Appendix
F
.


d)

Identifying Associations


Identifying associations involves consolidating all the diagram
s drawn in the previous
sections and attempts to create mappings among all the identified classes.


These are shown in A
ppendix

G, where the first 2 diagrams indicates the class
association mapping, followed by detailed descriptions of attributes inside ea
ch class.




Page
23


e)

Modeling State
-
Dependent Behavior of Individual Objects


A statechart diagram (STD) is a type of computer science
-
related diagram for describing
behaviors of the systems. It describes the possible states of a single class and the
events th
at caused the state transitions. They are essential for the developers to
understand the life cycle of a particular class.














Figure 2.4A


Loan_Item StateChart Diagram


An example

on the interpretation of StateChart

Diagram

is as illustrated above on the
Loan_Item Object. The object is created once a loan is confirmed and the initial status is
allocated as
[UnPicked]. The status changes as it went through physically picking by the
Librarian, collection by the Courier
Staff and later, dispatched to the Patron.


As the diagram has shown, the life cycle of a lo
aned item does not end after it i
s being
delivered. The object life cycle continues until the Patron raised a return request for the
Courier Service Provider to col
lect the loaned item, and subsequently returned to the
Library itself which then comes to an end of the object life cycle.


Object StateChart Diagrams that are of relevance to Project LDS (Fulfillment) are shown
in Appendix H.

Loan_Item

addLoan
()

Picked

Dispatched

LibraryStaff has located
the item and set aside for
Courier Collection

CourierStaff
commence on
delivery

Collected

Delivery request was cancelled

Bundle was
handled over to
the CourierStaff
for delivery

UnPicked

Cancelled

Delivered

Items are
delivered to the
Patron

ReturnRequested

Patron raised request for
return delivery

Ret
urnCollected

CourierStaff collected
returning material from
Patron


Page
24


2.5 SYSTEM DESIGN


2.5.1 SYS
TEM ARCHITECTURE


The LDS System’s basic requirement and evolution brought about a
layered/composite architectural scheme (as shown below).



Internet
HTTP
/
CGI
(
Apache Web
Server
)
Application
(
Java
)
Database
(
MySQL
)
Database
LDS SERVER
Corporate Patrons
Web
browser
Web
browser
Library Staff
Web
browser
Courier Staff

Figure 2.5A

-

General LDS Architecture Layout


The Apache
Tomcat

Server is the defaul
t tool supporting the heart of the LDS
system, hosting the java web application that interfaces between the users
(corporate patrons) and the database.


Page
25


2.5.2 DATABASE MIDDLEWARE COMPONENT


One of the main system development features of LDS is to ensure tha
t our
system database structure is to be robust and non product
-
reliant. In another
words, the migration of the Database from one management platform to another
(i.e. MS SQL Server 2000 to Oracle DB or MySQL) should not require any
changes to be done to th
e programming codes.


To implement this capability, we will be using Hibernate (Java), an object
-
relational mapping (ORM) library for Java, which provides a framework for
mapping object
-
oriented domain model to a traditional relational database. It
generat
es SQL calls and relieves the developer from manual result set handling
and object conversion, keeping the LDS system portable to all supported SQL
databases, with database portability delivered at very little performance overhead.



Figure 2.5B


Hiberna
te Logo


2.5.3 DATABASE

MANAGEMENT SYSTEM


LDS’s data will be managed by MYSQL Server,
an open
-
sourced relational
database management system (RDBMS)

that runs as a server providing multi
-
user access to a number of databases.



Figure 2.5C


MySQL Logo




Page
26


2.5.4 CORE SYSTEM FLOW


Below is the core system flow that drives the Project LDS (Fulfillment), which we
had identified after the requirement and system analysis.




Loan Confirmed



The
CatalogueItem
(s) that are listed in the
LoanCart

will

be updated from a
“Reserved” status to “Loaned”.




A
LoanRecord and PickList Item

will be created.



LibraryStaff

will be updated of new loan.

Bundling



The
LibraryStaff
will physically locate the loaned materials and set aside for collection
by Courier Service,




After gathering all the materials, the
LibraryStaff

will
update the status of the involved
LoanRecord
(s) to “Bundled”.




Concurrently at the
CourierStaff’s

screen, user will be able to see the status update of
outstanding delivery requests.

Colle
ction



The
CourierStaff
will come to the library to collect the loaned items from the
LibraryStaff
.




Upon verifying the prepared bundles with the outstanding delivery records in the
database, the
CourierStaff

will acknowledge the receival but logging into t
he system,
select all records and update their
DeliveryStatus

to “Collected”.

Dispatch



The
CourierStaff
will arrange the materials according to their own SOP for delivery.




CourierStaff will update their dispatch details into the LoanRecord(s) before
commencing on the delivery.

Deliver



啰Un hand汩ngve爠r映瑨e mate物a氠瑯⁴he⁰a瑲tnⰠt
桥h
CourierStaff
will login to
the system to update the
DeliveryStatus

and logging the date/time of job
completed.




L楢牡特S瑡晦
w楬氠le⁡ble⁴o⁶楥i⁴he⁣ ange猠sn⁲ al
-
瑩te⸮


Page
27


2.5.5

SYSTEM POLICY/ASSUMPTION(S)


System Design Assumptions


Below
is

a list
of assumptions that I had discussed and agreed upon with my
Project Supervisor in consideration of the Project scope, before the
commencement of the system design and implementation phases.


No.

Pre
-
Development Assumptions

1.

Due to the limitation in reso
urce and scope of the project,
the system shall not
incorporate any online payment functionalities for overdue loan fines,
lost/damaged items and delivery services.


Payment mode will remain the same as current practice: patrons will either use
the e
-
Kios
k, approach the information counter at the library for payment or
payment through corporate finance mode.


2.

Service Agreement Contract with 3
rd

Party Courier Service Company


The terms and conditions of the contract tied down between the private library

and the selected 3
rd

Party Courier Company will not be discussed/determined as
part of the project scope.


It will be assumed that the basic conditions stated below have been discussed
and agreed upon:


-

The number of vehicles/manpower to be activated for
each delivery
session for each zone will be planned by the Courier Service based on
their process workflow, in assessment on the number of jobs for that
particular session, weather and other unforeseen circumstances.


-

Courier Service is responsible to repo
rt to the Library if there should be
any delay in the delivery process and concurrently be directly answerable
to the patrons for delay.


3.

Bundling of Loan Items (Physical process)


-

With the introduction of the delivery service, the workload for librari
ans will
naturally increased:



Searching for the loaned items



Categorize/bundle the items according to the zone



Printing of delivery details for Courier Service (this portion is not
handled by the Courier Service as the library is the frontline that

Page
28


receive
s the latest updates like cancellation or change of delivery
addresses)



Sorting/updating of items when returned



With this significant change in work process, we assumed that the private

library will do the necessary manpower adjustment to align with the

new

service as it is time critical.


4.

Once a patron has confirmed his/her loan of a particular item through the online
service, the item will be assured of its reservation under the patron’s identity.


There will not be any case of a double
-
loan entry

as there will be no walk
-
in
patrons accessing the private library, nor will there be a concurrent reservation of
item by another online patron as that particular item will be placed under
reservation status immediately after the first patron added it into

his/her online
shopping cart
.


However, the reservation will be removed if the patron did not commit the loan
transaction within the specified session timing (i.e. 10 minutes). The transaction
session timing will be defined during the Interface developmen
t stage of the
Library Delivery Service project.


5.

Dependency on Project LDS (Interface)


Below are the discussed and agreed dependencies that Project LDS (Interface)
should provide to Project LDS (Fulfillment).


Login function for the users (i.e. Libra
ry Staff, Courier Staff and Patrons) and the
account management functionalities for Library Staff and Patron
,

is to be covered
by the development team of Project LDS (Interface).


Session creation, storing of identity and session timeout
capability is tagg
ed to
the Login Function.

Thus, presentation of module development in the later section
of this Project Report will be skipping such details.













Page
29


Loan Policy


The LDS Project will use the NLB’s existing loan policy as the baseline for
development.
The main focus will be to refine the policy to incorporate the rules
and regulations of delivery service.


NLB’s lo
an policy will remain unchanged:

Examples:

-

Max quantity of loan materials/media: 6

-

Loan Duration: 21 days

-

Duration Extension allowed: 2 times


LDS Delivery Session

There will be two sessions of loan c
onsolidation and picking daily. Below are the
session cut
-
off timing and the corresponding estimated time of delivery:


Session 1:

-

Start Time

:

1000hrs (Day 01)

-

End Time

:

1659hrs (Day 01)

-

Courier
Collection Time (estimated)

:

1900hrs

-

Estimated Time of Receive by Patron

:

Day 02 1000hrs
-
1700hrs


Session 2:

-

Start Time

:

1700hrs (Day 01)

-

End Time

:

0959hrs (Day 02)

-

Courier Collection Time (estimated)

:

1200hrs

-

Estimated Time of Receive by Patron

:

D
ay 03 Before 1000hrs





Page
30


2.7 IMPLEMENTATION


Below is the list of software tools required to be installed in the developing
terminal for the implementation of LDS System:
-



MySQL Server Version 5.1 (command
-
line)



MySQL GUI Component Tool



Apache Tomcat Serve
r



NetBeans IDE 6.7.1 (with Hibernate Framework
plug
-
in
)



Internet Explorer 6 and above (alternative browsers like
Mozilla

Firefox or
Google Chrome Browser
etc
are acceptable)



Microsoft Office suite (particularly Microsoft Excel, for report generation)


2.7
.1
D
ATABASE IMPLEMENTATION

The database table structures which I’d defined during the previous section will
be created into the MySQL Server through its GUI tool.

Sample data has also
been entered for some of the tables for the ease of development and tes
ting.














Figure 2.7A


Database creation


Page
31


Regular backups will be performed via the MySQL Administrator Toolkit to
ensure minimize data losses during the course of development.


Project LDS (Fulfillment) is greatly dependent on the data generated

from the
LDS (Interface) portion, i.e. loan record creations/updates, reservation status etc.
But due to the constraint that both projects commenced the same time and on
parallel development, I have to develop database triggers and self
-
written record
ins
ertion scripts to simulate/generate the required data so that I can proceed to
develop my modules. Examples of scripts I created are as shown below:
-












Figure 2.7B


Loan Record Query



Figure 2.7C


Return Request Query



Page
32


SQL Triggers are used
d
uring the development to automate some of the modules.


For instance, when patron commits his/her loan requests, the web form will
process the request and query to create loan records into the database.

After
successful record creation, the system will n
eed to update the item availability as
well as creating the corresponding picklist item.


Instead of handling the system control back to the controller webpage to continue
processing the item availability update and picklist item creation,
we retained the

control over at MySQL to process the two jobs through the use of SQL AfterInsert
Trigger.



















Figure 2.7
D



LoanItem Post
-
Insertion Trigger script

Appendix I displayed the list of triggers designed for Project LDS.

DELIMITER $$


DROP TRIGGER IF EXISTS `lds`.`NewLoan_PickTrigger01` $$

CREATE TRIGG
ER `lds`.`NewLoan_PickTrigger01`


AFTER INSERT ON loan_item


FOR EACH ROW


BEGIN


INSERT INTO picklistitem


VALUES(CONCAT((CURRENT_DATE+'
-
'),'
-
',(SELECT COUNT(*) FROM picklistitem t WHERE
DATE(t.createdDate)=CURRENT_DATE)+1)


,'
-
'
,

N
EW.biblioItemCopyID


,'Unpick'
,

CURRENT_TIMESTAMP


,'SYSTEM_AUTO'
,

CURRENT_TIMESTAMP


,'SYSTEM_AUTO'
,

NEW.loanedItemID


);



INSERT INTO transaction_log (transAct, transFunction, userID, modifiedDate,
modifiedBy, create
dDate, createdBy)


VALUES ('INSERT','LOAN
ITEM','S7722242E',CURRENT_TIMESTAMP,'S7722242E',CURRENT_TIMESTAMP,'S7722242E'


);



INSERT INTO transaction_log (transAct, transFunction, userID, modifiedDate,
modifiedBy, createdDate, createdBy)



VALUES ('INSERT','PICKLIST
ITEM','S8218009E',CURRENT_TIMESTAMP,'S8218009E',CURRENT_TIMESTAMP,'S8218009E'


);



UPDATE biblio_item_copy SET datelastborrowed=CURRENT_DATE,
modifiedDate=CURRENT_TIMESTAMP, modifiedBy='SYSTEM_AUTO'


WHERE bibl
ioItemCopyID=NEW.biblioItemCopyID;


END $$


DELIMITER ;



Page
33


2.7.2
J
AVA ENTITY CLASS C
REATION



HIBERNATE REVERSE
ENGINEERING METHOD


The creation of the standard java classes for LDS

is made much easier via
NetBeans

IDE with the Hibernate Reverse Engineering functionality.


The Hibernate frame work allows developers to import the datab
ase tables that
they have created and convert into the corresponding java classes and xml files,
and saved under the project. This can be easily achieved through the creation of
a Hibernate Mapping file and following through the reverse engineering wizard.







Figure 2.7
E



NetBeans

IDE (Hibernate Reverse Engineering)


The auto
-
generated Hibernate XML file allows developers to
handle the database
entities in an object
-
oriented manner, while it handles the translation/mapping of
the java codes to XML for
mat, which is then used to communicate to the
database.


Page
34


2.7.3
S
YSTEM INTERFACE DESIGN


I’d decided to use a web site template that is available online, to be used for
Project LDS in review of the project timeline and the task priorities. Adopting an
availa
ble template will allow me to focus more on the core functionality
development. Below are some screenshots of LDS’s design template:
-





















Figure 2.7
F



NetBeans

IDE (Hibernate Reverse Engineering)







Page
35


2.7.4
M
ODULE DEVELOPMENT SEQUENCE


Below is the sequence of development for Project LDS (Fulfillment):
-



Library Layout Manager



PickList
Module

o

SQL Trigger for auto
-
insertion into PickListItem table after
loan
transaction

o

Updating of picking status (P
ick/Unpick/Remove)

o

Submission of Complete
d PickList (Email Acknowledgement)

o

Search Function

o

PickList Export Function

(to MS Excel)

o

SQL Trigger for auto
-
insertion into Transaction Log table



Courier Staff Module

o

Acknowledge PickList Function

o

Collection of PickList Function

o

Dispatching of PickList I
tems Function

o

Handing Over of Items Function

o

Receive Return Request Function

o

Collection of Return Request Items Function

o

Handing Over of RR Items Function

(Report Export)



Return Request

o

Script for auto
-
creation of request from Patrons



Report Generation

o

Tr
ansaction Log Viewing

o

Delivery Frequency Report


The following section
describes one of the core module
s

of Project LDS
(Fulfillment)
.


The programming codes of the main core modules/functions can be found in
Appendix J (
System Codes
).


Page
36


Pick/Unpick/Remove L
oaned Item

This func
tion is enabled
for Library
Staff once a loan transaction is confirmed by a
Patron.


Once a new loan item record is created in the database, the [After Insert] trigger
that is tagged to the Loan_Item table will be triggered to insert the

equivalent
PickListItem record into the database

(
see page 32 Figure 2.7D
)
.


At the Picklistitem view function (PLI_fulllisting.jsp) of the LibraryStaff’s function
list, he/she will be able to see the
full list of
new
loan
items to be picked for this
curr
ent session
, together with details of the location of these
library materials
through a multi
-
table query.


The flow of processing is as illustrated below, followed by the screenshots:


















index.jsp

PLI_FullListing.jsp

PicklistController.java

LDS Database

Exported Picklist

Loan_Item.ja
va

Picklistitem.java

Picklist.java

ExcelExport_PickItem

.java

access

Retrieve/

update

data

List
records

create

createExcel

PL_Update_Status.jsp

access

export

Pick/

unpick

create

CMailer.java

create

Email to
Courier
Service
Provider


Page
37


































Page
38


2.8 TESTING


Testing for Project LDS

(Fulfillment)

has been divided into two portions, namely
Unit Testing and
Functional

Testing.

During the conducting of these tests,
database performance/efficiency is also being monitored thr
ough the MySQL’s
performance monitoring application to ensure proper handling of database
sessions to minimize overheads and improve overall system
efficient/performance.


Integration
Testing
between Project LDS (Interface) and Project LDS (Fulfillment)
ha
s been unable to be perform
ed

during the course
of this project timeline due to
unforeseen circumstances faced at the Project LDS (Interface) development.


Nevertheless, the testing for LDS (Fulfillment) modules shall still proceed as per
norm, as much as

possible, with a slight change as stated below:


-

The [New Loan] module under LDS (Interface), which LDS (Fulfillment)
very much depends on for the triggering of its subsequent processing
(picking/collection etc) will be replaced by manual SQL scripts so a
s to
simulate incoming loan requests, in order to trigger LDS (Fulfillment)’s
continuous processing


-

LDS (Fulfillment) rely on LDS (Interface) for the user information as it
handles login as well as storing the user details onto web sessions.
Due to
the ab
sence of the login and session creation process, modules that
require user information (Library Staff/Courier Staff/Patron) shall be pre
-
inserted into the SQL queries resided in the JSP pages.
This static
insertion of user information will
not
be affect
ing

future system integration,
s
hould LDS (Interface) be
merged
o
n a later stage. T
he codes can be
easily amended by replacing the static user information into session object
variables.


Page
39


U
NIT TESTING


The primary goal of Unit Testing is to take the smallest pi
eces of testable
component
.
The concept of performing unit testing on LDS generally involves
creating of java main() function in all the Controller classes created in LDS. The
main function will then proceed to test every data processing functions (less
ac
cessor methods) through passing in different sets of values, and observe if the
data validation/acceptance is programmed correctly.


The examples listed below are
some of the
tests performed on
both
the java
classes

and the database triggers

defined durin
g the development phase. While
verifying the correctness of the classes written, entity integrity is also being
checked against, to verify that the database tables are defined correctly with
unique row identities.




New Loan Item

Objective :

Ensure that
the SQL Trigger for creating picklist item is working according to



requirement


Test carried out :


1.

Write
and execute
a SQL script to create new loan records




Pre
-
requisite(s) :


The AFTER
-
INSERT SQL Trigger must be loaded into the database befor
e executing the
test



Page
40






Expected Result(s) :


1.

There should be a new record created into the picklistitem table

2.

There should be a new transaction log added into the transaction table as a record for
the INSERT query


Actual Result(s):


Test 1:

Upon suc
cessful execution of the loan item script, MySQL Query Browser will display the
below system message.




Correspondingly,
a new picklistitem record and a transaction log will be added into the
respective table









Page
41


Pick/Unpick Item Test

Objective :

To
ensure the correctness of the function that handles the picking and



unpicking of picklistitem.


Test carried out :


1.

Write a main() function onto PicklistitemController.java which will call upon the
updatePLItem() function several times with differe
nt input parameter values.


Below is the function to be tested:
-

updatePLItem()




Below is the main() function performing and generating the test results:





Pre
-
requisite(s) :


1.

There must be existing picklistitem records the database.

In this tes
t case, we will be
using the picklistitem record ID [
20100515
-
12
].




Page
42


Expected Result(s) :


1.

The first two function call should return a boolean value [true] as they are valid updating
status values

2.

The third function call should trigger an alert status tha
t the updating status description
is invalid and will not proceed.


Actual Result(s):


The result fetched matched the responses stated in the [Expected Result] column.



(
The messages in red are system response to closing of Hibernate session, which is n
ot related to the scope of
this test
)




















Page
43


F
UNCTIONAL TESTING


Functional Test

basically
involves piecing up of all the related modules to
compl
ete and test the logical processing flow.


One of the important function
tests

will be for Picklis
t Submission
, which is as
explained below:

Objective:


To conduct a test to ensure on the correctness of the logical flow on



picklist submission and courier email acknowledgement


WebPages
/Modules involved:

1.

PLI_Update_Status.jsp

2.

Picklist_UpdateControll
er.jsp

3.

Picklist_CompletionController.jsp

4.

PicklistitemController.java

5.

PicklistController.java

6.

NewPickList_Post_INSERT.sql (Trigger)


Test carried out:


1.

Create 6 loan records using the pre
-
defined sql script

2.

[Pick] them through the LibraryStaff’s page (PLI
.Update_Status.jsp)

3.

Submit the form for picklist creation and email acknowledgement


Expected Result:


1.

The 6 loan records should generate 6 picklistitem records

2.

Updating of the items’ [Pick]

status should be successful

3.

Once all outstanding items are picke
d, a form button should appear on screen to
allow user to submit for PickList creation and send email acknowledgement to
Courier Service Provider

4.

An Email should be sent to the Courier Service Provider to complete the picklist
creation and completion proce
ss.


Actual Result:


The picklistitem records are successfully created and updated of their picking status








Page
44



Once all the outstanding picklistitems are picked, the submit button will appear on
screen



Upon submission, a new picklist record will be

created, along with the corresponding
transaction log record (created through post
-
insert trigger).


Picklist record



Transaction Log



The acknowledgment email sent to the Courier Service Provider to notify for job pickup
is also being successfully re
ceived by the Courier Staff.



Page
45


DATABASE PERFORMANCE MONITORING


Last but not least, another major effort spent during testing phase is to observe
the database
utilization

rate and connections during the execution of the unit
tests and functional
testing
.


Server connection status is monitored to ensure that each user role should only
maintain an active database session with the SQL Server.
Should multiple
session creation is detected during the unit/functional testing, we will trace back
to the specific
action that we have previously ended and revisit the codings to
spot the error in coding method.


The memory health at this moment should not be posing much implication as we
foresee the majority of traffic/usage rate should come from the Patron side, wh
ich
is the LDS (Interface).


Page
46


CONCLUSION


CRITICAL REVIEW


The outcome of the project after near 11 monthly of development has been
satisfying as we are able to meet the Project Objectives defined during the initial
planning stage.


The Library Delivery S
ervice (Fulfillment) system is able to deliver services to the
Library Staff
, handling

incoming loan jobs and process them at the backend more
efficient
ly

and
in a more
organized manner.


The provision of this online Loan
-
and
-
Delivery service will
definit
ely
assist the
corporate clients to offload their resources spent on managing and maintaining
an in
-
house library. This has brought about cost
-
saving

(finance planning)

and
better manpower management in the long run.


Structuring of the library into a mor
e organized, warehouse concept has also
improved the overall efficient of the workers.

The availability of the sorting
mechanism within LDS allows Library Staff to perform search or picking of the
items in a more organized and time
-
saving manner.











Page
47


E
XPERIENCES AND LESSONS LEARNT


The Capstone Project has been a great opportunity for me to experience the
software development lifecycle and put the knowledge that I had gained from the
past UniSIM modules

into practice
, i.e.
MZS250 (Intro to Java), MZS25
2 (System
Analysis and Design)
, ICT321 and ICT
322 (Database Desig
n and Management),
ICT333 and ICT334 (Object
-
Oriented System Engineering).


The knowledge gained from ICT333 and ICT334 ha
d

already gave me an
advantage over understanding the pro
ject scope a
nd requirements, which later
led me to an easier choice over the type of project management methodologies
and SDLC convention to deploy for this project. As the project progresses, it has
also strengthened my knowledge and understanding on overall project
management as I am seated on both as a project manager and a developer’s
role. Most importantly, it is applicable to my current job too.


Time management
is

one of the most valuable assets gained as I learnt to plan
my schedule between the project, my ong
oing UniSIM core modules, my job and
personal life. The drafting of a project schedule is critical to the success of my
project, as it allows me to check on my progress, checking back on the important
milestones and from there prioritize my work
load,

while

striking a balance
with
my UniSIM modules and job
tasking
.


Contingency planning is
something I’ve picked up during the course of the project,
where I faced situations of timeline not met or there is a sudden change of
development path.
For instance, shou
ld the development of LDS (Interface) be
delayed and impacted on the integration between the two projects, alternatives
have to take place in order for LDS (Fulfillment) to continue to develop.
This has

led
me
to the development of simulated data through s
cripts/triggers etc means
to simulate the functionalities of the LDS (Interface) so that LDS (Fulfillment) can

Page
48


continue to develop or perform a suite testing with the generated results
,
independently
.


The choice of using
Java Server

Page (JSP) as the main

development language
platform
was ideal
as it strengthens both my java and web knowledge and
collaboratively, gaining more understanding on enterprise solution development
as my past
programming
exposure
s

had mostly evolved around standalone
application d
evelopment.


Developing enterprise solution has also led me to develop a more in
-
depth
understanding on the importance of coding and database efficiency, which
contributes great
ly to the success of the system
.
System
Efficiency is the value
-
add t
hat people

are looking into, for
solutions

nowadays
. Engaging towards this,
I’d spent a relative amount of time
testing

the efficiency of the system, in terms of
code reusing (obj
ect
-
oriented) and coding style for database session connectivity.
Constant monitoring w
as done during the development stage to ensure minimal
overheads.

This is an aspect of project development which I did not practice, or
rather, did not expect

to do
, in the past.



Last but not least, I would like to express my sincere gratitude to my Proj
ect
Supervisor, Mr. Koh, once again, for his guidance throughout the project and
more importantly, the valuable experiences and knowledge that he had shared
regarding Library work processes and the expected system structures.




Page
49


FUTURE IMPROVEMENT


During
the entire project period, we often came across ideas which could be
possibly developed to enhance on services provided by the system. Below are
descriptions of some possible improvements

in which we hope could be
incorporated, should Project LDS be offici
ally deployed
:


1.

RFID
Management

System

Adopting concepts similar to the operations of a warehouse asset tracking
system, RFID tagging could be introduced to LDS too, implementing on items
like the library materials (books/media) and even the shelves. This
enhances
the location tracking for a particular media/book, for example, when a Library
Staff wanted to shelf back a returned book, he/she just need to scan the
RFID tag of the shelf once, followed by the book. The information will be sent
to the LDS asset

tracking, where it will update the location of the book as well
as the availability status online for patrons to be able to start loaning this item.



Figure
4
-
A
: LibBest RFID Management System



Page
50


Check
-
in/Checkout of the loaned item will be more efficient

now as Library
Staff just need to scan the item instead of having to search for the item and
selects the option for picking etc. And if LDS is to be implemented even for
walk
-
in patrons, this RF
ID Management System will be able to provide anti
-
theft detec
tion through the deployment of RFID sensors at entrances (
as
illustrated in the picture above
).


2.

SMS Gateway

The notification method that LDS uses currently is mainly using email. A
possible enhancement over conventional emailing method will be through
SM
S (Short Message Service), which is very commonly employed nowadays.

This can be achieved by implementation of an SMS Gateway Server (private
or through local
Telco
) and add the corresponding codes to forward the
messages from the LDS Server to the Gateway

Server, which will then
forward to the designated recipients.



Figure
4
-
B
:
Sample SMS Gateway Infrastructure







Page
51


3.

Microsoft SQL Server

The current database implementation is using MySQL, an open source
freeware, which has its limitation in terms of scal
ability

of data and access
.

Should LDS be rolled out officially as an enterprise solution, migrating to the
use of Microsoft SQL Server will be a better recommendation in comparison
to the stability of implementation and scalability. Database Traffic
optim
ization will be easier to govern through the use of SQL Server too, as
compared to MySQL.


4.

System Security: VPN

Apart from disciplined coding practices, like the usages of sessions and
proper user authentications, enhanced security can be achieved with the

implementation of a VPN within the system architecture. With
VPN
secure
d

tunneling to govern th
e remote access from legitimate
users (Patrons/Courier
Staff), we can ensure that transactions between the various parties are not
easily intercepted, thus
impr
oving the trust level of using LDS
.

It may also be
possible to have the payments of fines or even corporate account payment to
be transacted through the internet with such secure implementation.




Figure
4
-
C
:
Sample VPN Setup


Page
52


REFERENCES


[1]

Outsourcing: Cor
porates look out for saving. Lawrence Neville. 07 Jan 2009.

http://www.euromoney.com/Article/2078658/Outsourcing
-
Corporates
-
look
-
out
-
for
-
savings.html


[2]

Outsourcing in Law Firm Libraries. Rachel Pergament. 1 April 1999.

http://www.llrx.com/authors/284


[3]

Determine Whether to Outsource. Michael Stein and Marc Osten. 5 Feb 2005.

http://www.techsoup.org/learningcenter/techplan/archives/page9739.cfm


[4]

NIE Library and Information Services Centre.

http:
//www.acis.nie.edu.sg/nie
-
acis/libris/services/circulation.do


[5]

NUS Library Services

http://www.lib.nus.edu.sg/guides/index.html


[6]

National Library Board