Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
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
<Description goes here>
1.7.2 Additional Requirements for Recommended Technologies
<Description goes here>
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
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 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
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. 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.
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: 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.
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 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
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 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
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 what documents can be printed by who.
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: 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.
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 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.
Attributes Attributes Description
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.
Attributes Attributes Description
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.
Attributes Attributes Description
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
<Description goes here>
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.
<Description goes here>
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
<Description goes here>
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/