software design documentksuweb.kennesaw.edu/~snorth/hololens/project_documents... · web viewin...

Software Design Document

Project Title

XXXX

XXXX

XXXX

April 16, 2013

Submitted as part of course requirements for CS 3610.

Contents

1 Introduction..............................................................................................................................................4

1.1 Purpose..............................................................................................................................................4

1.2 Scope.................................................................................................................................................4

1.3 Overview of Document......................................................................................................................4

1.4 Motivation for Implementation.........................................................................................................4

1.5 Software Functionality.......................................................................................................................4

1.6 Literature Review and Suggested Innovations...................................................................................5

1.7 Hardware Requirements....................................................................................................................5

1.7.1 Minimum Requirements.............................................................................................................5

1.7.2 Additional Requirements for Recommended Technologies........................................................5

1.8 Definitions and Acronyms..................................................................................................................5

2 Object Descriptions..................................................................................................................................6

2.1 Use Case Modeling............................................................................................................................6

2.1.1 Use Case: Complete......................................................................Error! Bookmark not defined.

2.1.2 Use Case: Sessions......................................................................................................................8

2.1.3 Use Case: Patron Actions............................................................................................................9

2.1.4 Use Case: Administrator Actions...............................................................................................11

2.1.5 Use Case: Printer Options.........................................................................................................13

2.2 UML Diagrams and Tables...............................................................................................................15

2.2.1 UML Diagram............................................................................................................................15

2.2.2 UML Tables...............................................................................................................................16

2.3 UML Sequence Diagram..................................................................................................................23

2.4 UML Collaboration Diagrams...........................................................................................................24

2.4.1 Patron.......................................................................................................................................24

2.4.2 Admin.......................................................................................................................................25

2.5 Object Behavior Diagrams...............................................................................................................26

2.5.1 Activity Diagram........................................................................................................................26

2.5.2 Control Event Flow Diagram.....................................................................................................27

2.6 Component Design..........................................................................................................................28

3 Description and Implementation............................................................................................................29

3.1 Overview of Implementation...........................................................................................................29

3.1.1 Launching Procedures...............................................................................................................29

3.1.2 Email Reminders.......................................................................................................................29

3.2 Graphical User Interfaces................................................................................................................29

3.2.1 Patron Graphical User Interface...............................................................................................29

3.2.2 Administrator Graphical User Interface....................................................................................34

3.2.3 Mobile Graphical User Interface...............................................................................................34

4 Conclusion..............................................................................................................................................35

4.1 Discussion and Results.....................................................................................................................35

4.2 References.......................................................................................................................................36

Figure 1: Complete Use Case Diagram.........................................................................................................6Figure 2: Complete Use Case Tables............................................................................................................7Figure 3: Sessions Use Case Diagram...........................................................................................................8Figure 4: Sessions Use Case Tables..............................................................................................................9Figure 5: Patron Actions Use Case Diagram.................................................................................................9Figure 6: Patron Actions Use Case Tables..................................................................................................10Figure 7: Administrator Actions Use Case Diagram...................................................................................11Figure 8: Administrator Actions Use Case Tables......................................................................................12Figure 9: Printer Options Use Case Diagram..............................................................................................13Figure 10: Printer Options Use Case Tables...............................................................................................14Figure 11: UML Diagram............................................................................................................................15Figure 12: Catalog Item UML Table...........................................................................................................16Figure 13: User UML Table........................................................................................................................17Figure 14: Main UML Table........................................................................................................................17Figure 15: LoginUI UML Table....................................................................................................................18Figure 16: AdminUI UML Table..................................................................................................................18Figure 17: CheckoutItemUI UML Table......................................................................................................19Figure 18: UpdateItemUI UML Table.........................................................................................................19Figure 19: UpdateUserInfoUI UML Table...................................................................................................20Figure 20: GenerateReportUI UML Table..................................................................................................20Figure 21: ItemsCheckedOutReport UML Table........................................................................................21Figure 22: OverdueItemsReport UML Table..............................................................................................21Figure 23: AvailableItemsReport UML Table.............................................................................................22Figure 24: HourlyItemsCheckOutReport UML Table..................................................................................22Figure 25: ItemCheckOutInformationReport UML Table...........................................................................22Figure 26: Enumeration UML Tables.........................................................................................................22Figure 27: UML Sequence Diagram...........................................................................................................23Figure 28: Patron Collaboration Diagram..................................................................................................24Figure 29: Admin Collaboration Diagram...................................................................................................25

Figure 29: Activity Diagram........................................................................................................................26Figure 30: Control Event Flow Diagram.....................................................................................................27Figure 31: Component Diagram.................................................................................................................28Figure 32: User login touchscreen GUI......................................................................................................30Figure 33: User status GUI.........................................................................................................................31Figure 34: Error message – too many books..............................................................................................32Figure 35: Email confirmation……………………………………………………………………………………………………………..…37Figure 36: Printed receipt..........................................................................................................................33Figure 37: Administrator GUI.....................................................................................................................34Figure 38: Mobile GUI................................................................................................................................35

1 Introduction

1.1 Purpose

< Clearly state the purpose of this document and its intended audience. >

1.2 Scope

< State the dominant design methodology. Overview the architecture of the product briefly.

Describe the external systems with which this system must interface. >

1.3 Overview of Document

In Chapter 2 of this document, a detailed description of the design of the software will be

provided, including UML diagrams and use case scenarios. Chapter 3 will document the system

implementation in detail and provide specification of the user-interface utilization.

1.4 Motivation for Implementation

< Define the Motivation for Implementation used in this document. Do not assume the

experience.>

1.5 Software Functionality

< Define the Software Functionality used in this document. Do not assume the experience.>

1.6 Literature Review and Suggested Innovations

<Recent research has shown here, Could be several paragraphs etc…>

1.7 Hardware Requirements

<Description goes here>

1.7.1 Minimum Requirements


1.7.2 Additional Requirements for Recommended Technologies


1.8 Definitions and Acronyms

Table or description goes here

< Define the technical terms used in this document. Do not assume the experience

2 Object Descriptions

2.1 Use Case Modeling

Diagram (use Visio)

Figure 1: Complete Use Case Diagram

Use case name:Library Do-It-Yourself

ID:UserID

Priority:Moderate

Primary actor:Administrator and Patron

Source:Library Do-It-Yourself Self checkout System

Use case type:Technical type

Interested Stakeholders:Kennesaw State University Library Staff

Brief description:The purpose of this use case is to show the action of the patron and the administration. This usecase diagram outlines all the possible basic scenarios that can occor.

Precondition:A Patron or administratior must have a KSUID and password.Tthe user must also be in the database.Trigger:Swipes there KSU card or they input their username and password in the textbox provided

Relationships:Include:Extend:

Typical flow of events:The Patron swipes their Kennesaw State University KSUIDo The system determines that they are patrons or administrators.o If Patron, they proceed to the next screen where they see what books that they have currently checked out and the books that they have scanned. It updates the database.The user proceeds to checkout and a recipt is printed when the transaction is complete.If Administrator , then they can check out a book as specified before, they can look at several different reports like put a book on reserve, checkout a book, update book inventory, generate a report or update a usero

AssumptionsWe are assuming that the patron or administrator has a KSUID. We are assuming that the patron agrees upon the number of books checked out the database says is checked out.We are assuming that the administrator has a status of an administrator in the database.

Implementation Constraints and Specifications:The patron will have to be able to login either by swiping their card or by inputting their username and password. The user will need to be able to scan books.

Figure 2: Complete Use Case Tables

< Description goes here >This use case scenario is a general guideline for demonstrating

the most common actions used by either the patron or the administrator. First it is important to

know which actor is using the system. By swiping a KSUID card, and entering a password, the

system will recognize whether the actor is a patron or an administrator.

2.1.2 Use Case: Sessions

Figure 3: Sessions Use Case Diagram

Use case name:Patron Sessions

ID:UserID

Priority:Moderate or High

Primary actor:Patron and Administrator




Brief description:The purpose of this use case is to show the point at which the user and the administrator split apart.

Precondition:A Patron must have a KSUID and password.Tthe user must also be in the database.Trigger:Swipes there KSU card or they input their username and password in the textbox provided

Relationships:Include:Extend: Library-Do-It-Yourself

Typical flow of events:The Patron or administrator swipes their Kennesaw State University KSUIDo the database either returns a value of having a status of an administrator, or it comes back not having a status of being an administrator. The next action is based upon the status.

AssumptionsWe are assuming that the patron and administrator has a KSUID.

Implementation Constraints and Specifications:The patron or administrator will have to be able to login either by swiping their card or by inputting their username and password. The user will need to be able to scan books.

Figure 4: Sessions Use Case Tables

This use case diagram demonstrates how the actor influences the session. If the actor is a

patron, it will go to the patron route. By swiping the ID card or inputting the ID and password,

the session will decide what actor is interacting with the system.

2.1.3 Use Case: Patron Actions

Figure 5: Patron Actions Use Case Diagram

Use case name:Patron Actions

ID:UserID

Priority:Moderate

Primary actor:Patron




Brief description:The purpose of this use case is to show the action of the patron. When the patron performs a self checkout, there it directly effects the database behind the scenes. It is important to note that patrons can only checkout books in this system which is desired the the Kennesaw State University Library Staff.


Relationships:Include:Extend: Admin Actions

Typical flow of events:The Patron swipes their Kennesaw State University KSUIDo The system determines that they are patrons and not administrators.o They proceed to the next screen where they see what books that they have currently checked out and the books that they have scanned. It updates the database.o The user proceeds to checkout and a recipt is printed when the transaction is complete.

AssumptionsWe are assuming that the patron has a KSUID. We are assuming that the patron agrees upon the number of books checked out the database says is checked out.


Figure 6: Patron Actions Use Case Tables

Assuming that the session is started by a patron, there are a limited number of actions that

can be performed. The patron can check out a book by scanning their book, or they can simply

log off. Once they scan a book it will be shown in a datagridview, and if the user has other books

checked out, then it will display what the user has.

2.1.4 Use Case: Administrator Actions

Figure 7: Administrator Actions Use Case Diagram

Use case name:Administrator Actions

ID:AdminID

Priority:High

Primary actor:Administrator




Brief description:The purpose of this use case is to show the actions of the administrator. The administrator has many more functions than a patron. An administrator can put a book on reserve, checkout a book, update book inventory, generate a report or update a user.

Precondition:An administrator must have a KSUID and password. They must also have a status of being an administrator in the database.Trigger:Swipes there KSU card or they input their username and password in the textbox provide. The database will then determine that they are an adminstrator and the program will guide them to the next screen.

Relationships:Include: Patron actionsExtend:

Typical flow of events:The administrator swipes their Kennesaw State University KSUIDo There is a menu with different options that the patron can do.This includes put a book on reserve, checkout a book, update book inventory, generate a report or update a user.o All of the the options provided use the database ‘s records. Because they are administrators, they can even update certain records in the database.o If the administrator decideds to print a report or checkout a book, then a receipt will be printed

AssumptionsWe are assuming that the administrator has a KSUID or KSUID and password. We are assuming that all of the administrators have the same access to all of the various functions. We are also assuming that the printer is working properly and that the library has the necessary equipment like inc paper, etc...

Implementation Constraints and Specifications:The administrator must have an administrator status in the database. Every time that the administrator logs in to the system, they will always be treated as an administrator and not as a patron.

Figure 8: Administrator Actions Use Case Tables

If the Administrator starts a sessions, then they can check out a book, which is the same

as the patrons check out system, or they can do other actions like put a book on reserve, update

user, update book inventory, or generate a report. The reports provide details such as the hourly

number of books checked out, available books, and any additional information.

2.1.5 Use Case: Printer Options

Figure 9: Printer Options Use Case Diagram

Use case name:Printer Options

ID:UserID

Priority:Moderate to High

Primary actor:Patron and Administrator




Brief description:

The purpose of this use case is to show what documents can be printed by who.


Relationships:Include:Extend: Admin Actions and library-do-it- yourself

Typical flow of events:The patron or administrator gets either a recipt for the checkout, or they get a report.

AssumptionsWe are assuming that the patron has a KSUID. We are assuming that the patron agrees upon the number of books checked out the database says is checked out.


Figure 10: Printer Options Use Case Tables

The patron can only receive a receipt from a checked out book. On the other hand, an

administrator can print several different reports like an overdue book report, availability book

report and others.

2.2 UML Diagrams and Tables

2.2.1 UML Diagram

Figure 11: UML Diagram

In this diagram, classes are represented using boxes with three parts:

The upper part holds the name of the class

The middle part contains the attributes of the class

The bottom part gives the methods or operations the class can take or undertake

These classes are connected by arrows to help show the flow of the program.

The program begins with the Main class which creates an instance of the LoginUI. From

this LoginUI, which is an interface that can be interacted with by the user, other UIs can be

created as necessary. Also connected to Main is the User class which represents any user logged

into the system. This user may have multiple CatalogItems associated with it. See the attached

tables for more specific information about individual classes:

2.2.2 UML Tables

Class Name: CatalogItemBrief Description: An object representing a cataloged item from the library which is populated by information from the database.

Attributes Attributes DescriptionID Integer, Represents location in databaseTitle String, Title of the itemAuthor String, Author of the itemYearOfPublication Date, When the item was publishedLibraryAquisitionDate Date, When the library obtained the itemItemType ItemType, See the enumerated type for detailsCondition String, Represents if the item is damagedCallNumber Integer, Identifies addional information about

the itemStatus ItemStatus, See the enumerated type for

detailsMethods Method Description

CatalogItem() Constructor, pulls information from the database to populate the atrributes of the item.

ItemInfo() Getter, returns a string which contains all information about the item.

Figure 12: Catalog Item UML Table

Class Name: UserBrief Description: An object representing a user of the library(patron or administrator) which is populated by information from the database.

Attributes Attributes DescriptionUserID Integer, The OUL Identifiaction number of the

user which is used to loginFirstName String, User’s first nameLastName String, User’s last nameCollectionStatus Boolean, Determines if the user is on the

collection list for overdue itemsCollectionCounter Integer, A count of how many time the user

has been added to the collection list for overdue items

Admin Boolean, Determines if the user has administrator status or not

CheckedOutItemsArray Array of type CatalogItem, An array of all items the user has checked out as of logging in to the

systemTempItemsArray Array of type CatalogItem, An array of all items

scanned by the user that once the checkout process is finished will be added to the CheckedOutItemsArray

Methods Method DescriptionUser() Constructor, pulls information from the

database to populate the atrributes of the user if the UserID and Password match what is in the database.

ScanItem() Method, Adds scanned items to the user’s TempItemsArray if there are less than 5 items total in the CheckedOutItemsArray and TempItemsArray.

FinalizeTransaction() Method, Merges the TempItemsArray and the CheckedOutItemsArray, prints a reciept for the user, uploads the new array into the database, and finally runs the LogOff method in Main.

UserInfo() Getter, returns a string which contains all information about the user.

Figure 13: User UML Table

Class Name: MainBrief Description: The initial method of the software which a user object and the UI is launched from.

Attributes Attributes DescriptionUser User, A user logged into the systemUI LoginUI, the initial UI used for loggin in to the

systemMethods Method Description

Main() Constructor, the first method to be run when the software inistializes, creates a LoginUI.

LogIn() Method, Creates a User with information from the LoginUI assuming the information proided by the user matches what is in the database.

LogOff() Method, Ends the software.

Figure 14: Main UML Table

Class Name: LoginUIBrief Description: The first page users will see, contains 2 text fields and 2 buttons as well as a prompt for the user to either manually enter a userID and password or to swipe their card.

Attributes Attributes DescriptionUserIDTextBox TextField, Where the user will enter a UserIDPasswordTextBox TextField, Where the user will enter a

passwordMethods Method Description

LoginButton() Method, Run when the confirm log in button is clicked that calls the LogIn method in Main.

DisplayAdminUI() Method, Creates an AdminUI object and closes the LoginUI, run when an admin logs into the system.

DisplayCheckOutItemUI() Method, Creates a CheckOutItemUI object and closes the LoginUI, run when a patron logs into the system.

Figure 15: LoginUI UML Table

Class Name: AdminUIBrief Description: The UI displayed after an admin logs in with a valid ID and password. Contains buttons to get to various administrator Uis

Attributes Attributes Description

Methods Method DescriptionCheckOutItemButton() Method, Runs the releated display method in

the LoginUI.DisplayUpdateItemUI() Method, Creates a UpdateItemUI object and

closes the AdminUIDisplayUpdateUserInfoUI() Method, Creates a UpdateUserInfoUI object

and closes the AdminUIDisplayGenerateReportUI() Method, Creates a GenerateReportUI object

and closes the AdminUIDisplayReserveItemUI() Method, Creates a UpdateItemUI object but

only displays the Status OptionPane and closes the AdminUI

Figure 16: AdminUI UML Table

Class Name: CheckOutItemUIBrief Description: The UI displayed when a patron logs in or when an admin chooses the option to check out an item. Displays both arrays belonging to the user as well as buttons to confirm and cancel the transaction.

Attributes Attributes DescriptionScannedItemID Integer, the ID of an item scanned by the user

Methods Method DescriptionConfirmButton() Method, Run when the user clicks the confirm

button. Runs the FinalizeTransaction method in the user object and the DisplayRecieptConformation method

CancelButton() Method, Run when the user clicks the cancel button. Runs the LogOut method in Main after confirming with the user.

DisplayRecieptConfirmation() Method, Asks if the user would like the print a reciept and if yes, prints a recipt of items checked out.

Figure 17: CheckoutItemUI UML Table

Class Name: UpdateItemUIBrief Description: The UI displayed when an admin selects the update item or reserve item option from the admin UI. Contains fields for ever attribute of a CatalogItem as well as buttons to create a new item, display all info about an item, update information about an item, and to exit the UI.

Attributes Attributes DescriptionIDTextBox TextField, Where the CatalogItem’s relevant

attribute is displayed and can be edittedTitleTextBoxAuthorTextBoxYearOfPublicationTextBoxLibraryAquisitionDateTextBoxItemTypeOptionPaneConditionTextBoxCallNumberTextBoxStatusOptionPane

Methods Method Description NewItemButton() Method, Creates a new item in the database

with the field filled in from the UI’s attributes.DisplayInfoButton() Method, Pulls info from the attributes and fills

in the rest with information pulled from the database.

UpdateItemButton() Method, Finds the item ID in the database and replaces any entered information after confirming the action with the user.

ExitUI() Method, Closes the UI and returns to the AdminUI.

Figure 18: UpdateItemUI UML Table

Class Name: UpdateUserInfoUIBrief Description: The UI displayed when an admin selects the update user information option from the admin UI. Contains fields for ever attribute of a User as well as buttons to create a new user, display all info about a user, update information about a user, and to exit the UI.

Attributes Attributes DescriptionUserIDTextBox TextField, Where the User’s relevant attribute

is displayed and can be edittedFirstNameTextBoxLastNameTextBoxCollectionStatusTextBoxCollectionCounterTextBoxAdminCheckBoxCheckedOutItemsStatusTable StatusTable, A table that displays all items the

user currently has checked outMethods Method Description

NewUserButton() Method, Creates a new user in the database with the field filled in from the UI’s attributes.

DisplayInfoButton() Method, Pulls info from the attributes and fills in the rest with information pulled from the database.

UpdateUserButton() Method, Finds the user ID in the database and replaces any entered information after confirming the action with the user.

ExitUI() Method, Closes the UI and returns to the AdminUI.

Figure 19: UpdateUserInfoUI UML Table

Class Name: GenerateReportUIBrief Description: The UI that contains a tab controller to open various types of reports.


Methods Method DescriptionPrintReport() Method, Prints the report currently displayed,

available to all child reportUIs.DisplayItemsCheckedOutReport() Method, Displays the revent report UI.DisplayOverdueItemsReport()DisplayAvailableItemsReport()DisplayHourlyItemsCheckedOutReport()DisplayItemPopularityReport()

Figure 20: GenerateReportUI UML Table

Class Name: ItemsCheckedOutReportBrief Description: Using a from date and to date or preset dates as parameters the report runs a stored procedure to retrieve all the books checked out in a given time interval.

Attributes Attributes DescriptionFromDateField Date, sets the starting point of the time

intervalToDateField Date, sets the ending point of the time interval

Methods Method DescriptionYearToDate() Method, Displays a report of all items checked

out in the last year.Quarterly() Method, Displays a report of all items checked

out in the quarter.Monthly() Method, Displays a report of all items checked

out in the last month.FromTo() Method, Displays a report of all items checked

out between the dates set by the user.

Figure 21: ItemsCheckedOutReport UML Table

Class Name: OverdueItemsReportBrief Description: Using a from date and to date or preset dates as parameters the report runs a stored procedure to retrieve all the books that were overdue over a given time interval.

Attributes Attributes DescriptionFromDateField Date, sets the starting point of the time

intervalToDateField Date, sets the ending point of the time interval

Methods Method DescriptionYearToDate() Method, Displays a report of all overdue items

in the last year.Quarterly() Method, Displays a report of all overdue items

in the quarter.Monthly() Method, Displays a report of all overdue items

in the last month.FromTo() Method, Displays a report of all overdue items

between the dates set by the user.

Figure 22: OverdueItemsReport UML Table

Class Name: AvailableItemsReportBrief Description: Runs a stored procedure to retrieve all the books that are currently available.


Methods Method DescriptionGenerateReport() Method, Displays a report of all items which

are currently available.

Figure 23: AvailableItemsReport UML Table

Class Name: HourlyItemsCheckOutReportBrief Description: Runs a stored procedure to retrieve how many items have been checked out each hour over the last day.


Methods Method DescriptionGenerateReport() Method, Displays a graph of how many items

have been checked out each hour over the last day.

Figure 24: HourlyItemsCheckOutReport UML Table

Class Name: ItemCheckOutInformationReportBrief Description: Using the ID of an item the report runs a stored procedure to retrieve how often it has been checked out.

Attributes Attributes DescriptionItemIDTextField Integer, The ID of the item to be queried

Methods Method DescriptionGenerateReport() Method, Displays a report of how often an

item has been checked out.

Figure 25: ItemCheckOutInformationReport UML Table

Enumeration Name: ItemTypeValues: Book, Journal, Magazine, TextField

Enumeration Name: ItemStatusValues: InStock, CheckedOut, Reserved, Missing, OutOfCirculation

Figure 26: Enumeration UML Tables

2.3 UML Sequence Diagram

Figure 27: UML Sequence Diagram

The above diagram describes how each entity interacts with the others in particular

sequences through the program execution. An admin has the most options, in particular in

regards to report generation. Each action shown in the diagram has a direct or indirect connection

with the database in order to complete its execution.

2.4 UML Collaboration Diagrams

2.4.1 Patron

Figure 28: Patron Collaboration Diagram

The Patron UML Collaboration Diagram gets into more detail about where certain

actions can take the user throughout the system. For example, when the user decides go click log

off, it will take them back to the original screen and it will not continue. There are different

scenarios that can play throughout the process also.

2.4.2 Admin

Figure 29: Admin Collaboration Diagram

For the sake of simplicity, the numbers next to each of the actions are not displayed. This

diagram should clarify how each action interacts with each main object. For example, by

updating the userinfo, it has to interact with the database.

2.5 Object Behavior Diagrams

2.5.1 Activity Diagram

Figure 29: Activity Diagram

In the activity diagram, it demonstrates all of the options that users have. A diamond

represents a choice to be made. The diagram show that the only options that a Patron has is to

check out a book or to log out of the system. On the other hand, an Administrator has many other

privileges including generating and printing out reports.

2.5.2 Control Event Flow Diagram

Figure 30: Control Event Flow Diagram

The Control/Event Flow Diagram shows when particular controllers are needed. For

example, the printer only prints when an administrator wants to print a report, or when a book is

checked out. The database is used either to update information or to gather information. When an

administrator or a patron signs into the system, it selects a value in the database that is either true

or false. Depending on what value the database selects determines the privileges of the user.

2.6 Component Design

Figure 31: Component Diagram

This diagram shows the key components of the Library Do-It-Yourself Checkout

Software and how they interact. The components are represented by the boxes while the

interfaces that the user will interact with are represented by the nodes extending from them. The

dashed arrows show the relation of the components and their dependencies. For example, the

item checkout system uses catalog items and the receipt generator and is used by the user. A

patron or admin may interact with this component through the CheckOut UI.

3 Description and Implementation

3.1 Overview of Implementation

3.1.1 Launching Procedures

The application will be launched via an application launcher placed on the desktop of

designated self-checkout computers. Starting or terminating the application will require

administrator login. If login is successful, a dialog box will be displayed asking the user to

confirm close. If login is unsuccessful, the application will resume running.

3.1.2 Email Reminders


3.2 Graphical User Interfaces

3.2.1 Patron Graphical User Interface

Touchscreen implementation is allowed by the provided patron GUI, as it is in the

context of patron usage that a touchscreen GUI is most practical.


Figure 32: User login touchscreen GUI

Additional screens provide the patron information including books already checked out

and currently scanned books. At any point, the patron can press the “Cancel” button and the

table of scanned books will be emptied (and no database update queries will be generated). When

a patron is finished, the patron will press the “Done” button, which will cause database update

queries to be generated and the contents of the table of scanned books will be updated to reflect

their checked-out status.

Figure 33: User status GUI

Several conditions will cause error messages to be shown: when a patron tries to

checkout more than five books, when a patron has an overdue book, when a patron is trying to

check out a reserved book, and when a patron scans the same book twice.

Figure 34: Error message – too many books

When the patron has completed the checkout process, an email is sent to the email

address on record for the patron displaying a table of currently checked out books. Additionally,

a message is shown asking the patron whether or not a paper receipt is desired. If the patron

selects no, a thank you message is shown and the application restarts, ready for the next patron.

If the patron selects yes, a receipt is printed before restarting the application. The contents of the

receipt include the name and due date of all currently checked out books.

Figure 35: Email confirmations

Figure 36: Printed receipt

3.2.2 Administrator Graphical User Interface


Figure 37: Administrator GUI

3.2.3 Mobile Graphical User Interface

Research shows that the incorporation of visual design with high quality audio and tactile

feedback results in a better user experience (Hoggan, Kaaresoja, Laitinen, & Brewster, 2008).

Accordingly, the mobile GUI will use standard phone vibrotactile actuators in addition to helpful

auditive responses that mimic interaction with a physical keyboard.

The mobile GUI will closely resemble the traditional patron GUI, with obvious

adjustments to adjust for the size of a mobile device’s screen, including limiting displayed

information and providing slightly fewer options for interactions.

Figure 38: Mobile GUI

4 Conclusion

4.1 Discussion and Results

With the emergence of new technologies, procedures, and approaches to data and

information management, use of innovation and increased effectiveness of regularly used

systems, such as library resource centers, can be optimized and reinitialized for utility in this and

the next generation. The system we have proposed for implementation offers sufficient features

and functionality to meet the needs of users and administrations, while providing for a balance of

cost, time, and quality.

4.2 References

DeJoice, M. J., & Sennyey, P. Some issues in implementing library self-checkout systems: A

management perspective. Retrieved From: http://www.lib.niu.edu/2000/il000105.html

Dempsey, B. State of self-service 2010: Do-it-yourself libraries. Retrieved from:

http://www.libraryjournal.com/lj/home/885275-264/state_of_self-service_2010_do-it-

yourself.html.csp

Hoggan, E., Kaaresoja, T., Laitinen, P., & Brewster, S. (2008). Crossmodal congruence: the

look, feel and sound of touchscreen widgets. Proceedings of the 10th international conference

on Multimodal interfaces, ICMI '08, 157-164. doi:10.1145/1452392.1452423

Mackenzie, C., & Aulich, M. (2002). Self-service -- the revolution is here. Retrieved from

http://www.vala.org.au/vala2002/2002pdf/44MacAul.pdf

Mudte, M. Teton County library budget savings from open source software for self check-out.

Retrieved From: https://docs.google.com/viewer?url=http%3A%2F%2Fwww.mpla.us

%2Fstories%2Ftetoncounty.pdf

Shahid, S. (2005). Use of RFID technology in libraries: a new approach to circulation, tracking,

inventorying, and security of library materials . Library Philosophy and Practice, 8(1). doi:

ISSN 1522-0222

Stuerzlinger, W., Chapuis, O., Phillips, D., & Roussel, N. (2006). User interface façades:

towards fully adaptable user interfaces. Proceedings of the 19th annual ACM symposium on

User interface software and technology, UIST ’06, 309-318. doi:10.1145/1166253.1166301

Tech Logic. CircIT Software. Retrieved From https://docs.google.com/viewer?url=

http%3A%2F%2Fwww.tech-logic.com%2Fpdf%2FCircIT_DataSheet.pdf

Zhou, Y., Broussard, R., & Lease, M. (2011). Mobile options for online public access catalogs.

Proceedings of the 2011 iConference, iConference '11, 598-605.

doi:10.1145/1940761.1940842

3M Library Systems. 3M™ integrated disk media unlocker. Retrieved from:

http://solutions.3m.com/wps/portal/3M/en_US/library-systems-NA/library-

technologies/library-system-products/RFID-reader/SelfCheck-RFID-systems/integrated-disk-

media-unlocker/

software design documentksuweb.kennesaw.edu/~snorth/hololens/project_documents... · web viewin...

Documents