Library Circulation System

(LCS)

Software Design Specification

Version 1

July 22, 2004

 

 

 

 

 

Mohamed Ali

Richard Allen

BuYunG J. Tarianto

Susrutha Narla

Wayne Salhany

Thara Soman

Revisions

Version

Primary Author(s)

Description of Version

Date Completed

Draft 1

Richard Allen

First rough draft.

06/22/2004

Draft 2

Susrutha Narla

Added Data design section, Component Design section, UML design section and Use Case design section

07/17/2004

Draft 3

Susrutha Narla

Modified Component design Section and added more Class diagrams in UML design section. Added Screens definitions and figures.

07/21/2004

Version 1

Richard Allen

Final cleanup for version 1.

07/22/2004

 

Table of Contents

Table of Figures. v

1. Introduction. 1

1.1 Purpose. 1

1.2 Intended Audience. 1

1.3 Overview.. 2

1.4 Project Scope. 2

1.5 Constraints. 3

1.6 References. 4

2. System Architecture. 5

2.1 Architectural Description. 5

2.2 Design Rationale. 8

3. Human Interface Design. 9

3.1 Overview of the User Interface. 9

3.1.1 JSP Best Practices. 9

3.2 Page Components. 10

3.2.1 Menu System.. 11

3.2.2 Look and Feel 12

3.2.2.1 Colors. 12

3.2.2.2 Fonts. 13

3.2.2.3 Icons. 13

3.2.2.4 Errors and Messages. 14

3.3 System Screens. 16

3.3.1 Login Screen. 16

3.3.2 Basic Search Screen. 17

3.3.3 Advanced Search Screen. 18

3.3.4 Check Out Items Screen. 19

3.3.5 Check In Items Screen. 20

3.3.6 Reports Screen. 21

4. Data Design. 22

4.1 Database Description. 22

4.2 Physical Entity-Relationship Diagram.. 22

4.3 Logical Entity-Relationship Diagram.. 23

4.4 Data Dictionary. 24

4.4.1 Role Table. 24

4.4.2 User Table. 24

4.4.3 Config Table. 25

4.4.4 Author Table. 25

4.4.5 Subject Table. 25

4.4.6 Resource Table. 26

4.4.7 ResourceAuthor Table. 26

4.4.8 ResourceSubject Table. 27

4.4.9 Fine Table. 27

4.4.10 Item Table. 27

5. Component Design. 28

5.1 Security. 28

5.1.1 Passwords. 28

5.1.2 User Names. 28

5.2 Domain Objects Components. 29

5.2.1 Purpose. 29

5.2.2 Subordinates. 29

5.2.3 Dependencies. 29

5.2.4 Data. 29

5.2.5 Interfaces. 29

5.3 Business Services Components. 30

5.3.1 Purpose. 30

5.3.2 Subordinates. 30

5.3.3 Dependencies. 30

5.3.4 Data. 30

5.3.5 Interfaces. 30

5.4 Model Component 31

5.4.1 Purpose. 31

5.4.2 Subordinates. 31

5.4.3 Dependencies. 31

5.4.4 Data. 31

5.4.5 Interfaces. 31

5.5 Data Access Component 32

5.5.1 Purpose. 32

5.5.2 Subordinates. 32

5.5.3 Dependencies. 32

5.5.4 Data. 32

5.5.5 Interfaces. 32

5.6 Controlling Logic. 33

6. UML Class Design Diagrams. 34

6.1 Class diagram for Domain Classes. 35

6.2 Model Classes. 36

6.3 DAO Classes. 37

7. UML Sequence Diagrams. 38

7.1 User LogIn Sequence Diagram.. 38

7.2 Add Item Sequence Diagram.. 39

7.3 CheckIn Item Sequence Diagram.. 40

7.4 CheckOut Item Sequence Diagram.. 41

7.5 Renew Item Sequence Diagram.. 42

7.6 Reserve Item Sequence Diagram.. 43

7.7 Search Item Sequence Diagram.. 44

Appendix A: Requirements Traceability Matrix. 45

Appendix B: Use Case Diagram and Detailed Use Cases. 50

 

Table of Figures

Figure 2.1  LCS Architecture. 7

Figure 3.1  Page Layout 10

Figure 3.2  Login Menu. 11

Figure 3.3  Menu After Login. 11

Figure 3.4  JavaScript Generated Error Message. 15

Figure 3.5  Server Generated Error Message. 15

Figure 3.6  Login Screen. 16

Figure 3.7  Basic Search Screen. 17

Figure 3.8  Advanced Search Screen. 18

Figure 3.9  Check Out Item Screen. 19

Figure 3.10  Check In Item Screen. 20

Figure 3.11  Reports Screen. 21

Figure 4.1  Physical ER Diagram.. 22

Figure 4.2  Logical ER Diagram.. 23

Figure B.1 Use Case Diagram.. 50

1. Introduction

1.1 Purpose

This document is the Software Design Specification (SDS) for the Library Circulation System (LCS).  The SDS is used as the primary medium for communicating software design information.  The SDS shows how the software system will be structured to satisfy the requirements identified in the Software Requirements Specification (SRS).  It is a translation of requirements into a description of the software structure, software components, interfaces, and data necessary for the implementation phase.  The components of the system are fully described in their structure and function, as well as their relationship with other components.  The method in which the system operates, and how the SRS is satisfied (traceability) are also described.  The intent in producing this SDS is that an independent developer can use it to produce a system that meets the requirements.

 

1.2 Intended Audience

The SDS is intended for the project managers and/or leads, designers, developers, and testers of the system.

·        The testers will use this SDS to help derive test plans and test cases for each component of the system, as well as to determine what special test software and test platforms (if any) will be necessary to fully and accurately test the system.

1.3 Overview

The SDS is mostly composed of five major sections:

·        Introduction:  Describes the project, the scope of the project, and the constraints of the project.

·        System Architecture:  Describes how the system is decomposed into separate components and which components communicate.

·        Human Interface Design:  Describes the user interface to the system and includes screen images, conventions and standards used for designing the user interface, and pre-existing GUI components that will be used to implement the system.

·        Data Design:  Describes the database that will be used and the tables that will store all of the data related to the system, including their referential integrity.

·        Component Design:  Describes software components of the system that were identified in the System Architecture.

 

1.4 Project Scope

The primary intent of this project is to reduce the workload involved in managing the circulation of books at a university.  Another intent of this project is to provide a convenient method to search for books that the library has in circulation and generate reports on the status of books.  Following is the high-level functionality that the Library Circulation System (LCS) will provide.

The team members have agreed that LCS will be developed as a web-based application.  A web-based solution will provide many benefits including the following:

·        Future releases of the application can provide web-based interfaces (e.g., Web Services) for other library systems, so that other libraries can search the inventory or even reserve a book.

 

1.5 Constraints

The SRS and SPMP for LCS describe the following constraints.

1.      The system shall execute on the Microsoft Windows 2000 operating system or later version.

2.      The system shall be usable via a web browser and the Internet.

3.      The system shall require users to login before having access to all but the search functionality provided by the system.

4.      The system shall restrict the user’s access to functionality by user role.

5.      The user interface of the system shall be easy to use with minimal clutter and shall make use of drop-down boxes, radio buttons, and other selectable fields wherever possible instead of fields that require the user to type in data.

6.      All system responses to user actions shall take no longer than 10 seconds.

In addition to the above-mentioned constraints, the project team has decided that the system will be implemented in the Java programming language using Java 2 Enterprise Edition (J2EE) technologies, as well as run a MySQL database server.

 

1.6 References

This SDS is based on the IEEE recommended practice for Software Design Descriptions.  This SDS satisfies the requirements documented in the Software Requirements Specification (SRS) and is defined as a deliverable in the Software Project Management Plan (SPMP).

Allen, Richard, Mohamed Ali, BuYunG J. Tarianto, Susrutha Narla, Wayne Salhany, and Thara Soman. “Library Circulation System (LCS), Software Project Management Plan, Version 2.” 22 Jun. 2004.

Soman, Thara, Richard Allen, Mohamed Ali, BuYunG J. Tarianto, Susrutha Narla, Wayne Salhany. “Library Circulation System (LCS), Software Requirements Specification, Version 1” 24 Jun. 2004.

IEEE Std 1016-1998, IEEE Recommended Practice for Software Design Descriptions

The language in this document assumes that the reader has some knowledge of Java technologies for enterprise web development (J2EE) including Java Servlets, JavaServer Pages (JSP), Java Beans, and Java Database Connectivity (JDBC).  If the reader does not have knowledge of these technologies, the reader may want to start by reading several of the many introductions and tutorials to this technology available on the Internet.  One of the most comprehensive and freely available tutorials on this technology at the time of this writing is the Sun Microsystems J2EE tutorial.  The newest version of this tutorial is available at http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html.

 

2. System Architecture

2.1 Architectural Description

The architecture of the system is based on a three-tier client-server model where clients (web browsers) communicate with a web server (through the Internet), which in turn communicates with a database server.  Each tier (client, web server, and database server) resides on separate computers.

In addition, the architecture of the system code running on the web server is based on the Model-View-Controller (MVC) architecture popularized by applications written for the Java 2 Enterprise Edition (J2EE).  A description of the MVC architecture follows.

  1. Model: A model represents an application’s data and contains the logic for accessing and manipulating that data.  A model groups related data and operations for providing a specific service; these groups of operations wrap and abstract the functionality of the business process being modeled.  A model’s interface exposes methods for accessing and updating the state of the model.
  2. View: The view is responsible for rendering the model data and for accepting user input.  The presentation semantics are encapsulated within the view; therefore, model data can be adapted for several different kinds of clients (in our case, web browsers).
  3. Controller: The controller is responsible for intercepting and translating user actions into commands that invoke methods on the model’s public API.  The controller is responsible for selecting the next view based on user actions and the outcome of model operations.

In a J2EE-based application, the MVC architecture is used for separating the business logic layer from the presentation layer.  The presentation layer is written using Java Beans, JavaServer Pages (JSP), JSP custom tags, HTML, and JavaScript (for the browser).  The business logic layer is written using Java Beans, Enterprise Java Beans, and regular Java objects.  The controllers are written using Java Servlets.

The LCS system will handle incoming HTTP requests by routing them to a central controller, which in turn will interpret and delegate the request to the appropriate request handlers.  This is also referred to as MVC Type-II (Model 2) Architecture.  The difference between Model 2 MVC and the traditional MVC is that Model 2 incorporates a central controller, which intercepts all requests.

Request handlers are hooks into the framework provided to the developers for implementing request-specific logic that interacts with the model.  Depending on the outcome of this interaction, the controller can determine the next view for generating the correct response.

An event generated by the user’s mouse or keyboard will be processed by the web browser (client), then sent over the Internet to the web server as a request for some action.  On the web server a front controller will handle the request by invoking business logic to satisfy the request, and then select a view to send back to the user as a response to the request.  If data is required from the database when executing the business logic, then the Model on the web server will send a request over the Intranet to the database server.  The database server will process the request and send a response back to the web server.

The software layers of the LCS system are briefly described below.

  1. Browsers (Internet Explorer, Netscape, or Mozilla)                   (presentation layer)
  2. View (Java Beans, JSP, JSP custom tags)                                (presentation layer)
  3. Controller (Java Servlets, Java Beans, Java objects)                  (presentation layer)
  4. Model (Java objects, Java Beans)                                            (business layer)
  5. Database Access (Java objects)                                               (data access layer)
  6. JDBC                                                                                       (data access layer)
  7. MySQL Database                                                                    (data storage layer)

The Database Access component will contain all of the SQL INSERT, UPDATE, DELETE, and SELECT statements that are necessary to persist and retrieve all of the data related to the system.  The Database Access component will utilize Java Database Connectivity (JDBC) (http://java.sun.com/products/jdbc) libraries to connect to and communicate with the database.

To speed the development of the system, the following open-source Java libraries will be used.

  1. Struts 1.1 (http://struts.apache.org/):  Struts provides a framework for the MVC Model 2 architecture based on Java Servlets, JSP, JSP custom tags, Java ResourceBundles, and XML.  Struts provides functionality for validating user input, a front controller for routing incoming requests to the appropriate business logic and selecting the appropriate views as responses, and components for building views with JSP.
  2. JavaServer Pages Standard Tag Library (JSTL) 1.1 (http://java.sun.com/products/jsp/jstl/index.html):  JSTL provides core functionality common to many JSP applications as simple JSP custom tags.
  3. Log4j, version 1.2.8 (http://logging.apache.org/log4j/docs):  Log4j is a library written in Java that provides logging functionality for Java applications.

A graphical depiction of this architecture can be found in Figure 2.1.1.

 

Figure 2.1  LCS Architecture

2.2 Design Rationale

The architecture described in section 2.1 was chosen for the following reasons.

1.      A web-based application provides a convenient way for many users to use an application.  The users do not need to install any software other that what is typically already on their computer (i.e., a web browser).

2.      A web-based application provides a convenient way for administrators to upgrade the system to a new release.  The users do not have to upgrade software on their computers; only the server’s application software has to be upgraded.

3.      The MVC architecture separates design concerns (data persistence and behavior, presentation, and control), decreasing code duplication, centralizing control, and making the application more easily modifiable (i.e., maintainable).  MVC also helps developers with different skill sets to focus on their core skills and collaborate through clearly defined interfaces.  An MVC design can centralize control of such application facilities as security, logging, and screen flow.  New data sources are easy to add to an MVC application by creating code that adapts the new data source to the view API.  Similarly, new client types are easy to add by adapting the new client type to operate as an MVC view.  MVC clearly defines the responsibilities of participating classes, making bugs easier to track down and eliminate.

4.      J2EE, Tomcat, Struts, JSTL, and Log4j are well used, well designed, free, and provide documentation that is readily available on the Internet.

The only drawback to choosing this architecture is complexity.  A three-tier architecture, J2EE, and a web-based GUI add significant complexity.  However, the benefits far outweigh the complexity of the system.

3. Human Interface Design

3.1 Overview of the User Interface

The user interface of the system will be created using JavaServer Pages (http://java.sun.com/products/jsp/), JavaBeans, and Java custom tag libraries.  Struts (http://struts.apache.org/) and JSTL (http://java.sun.com/products/jsp/jstl/) both provide custom tag libraries that will be used.  The JSTL will be used for iteration and conditionals in JSPs as well as formatting data such as dates for display.  The Struts tags will be used for generating HTML form elements such as text fields, collecting form data that is submitted to the server, redisplaying the form data to the user, displaying error messages, and componentizing JSP pages into reusable parts.

3.1.1 JSP Best Practices

JSP allows developers to mix Java logic with HTML to produce dynamic web content.  Sections of Java logic embedded in JSP pages are called scriptlets.  When scriptlets are overused, the JSP pages can become difficult to read, understand, and maintain.  Industry standards for JSP best practices recommend separating the Java logic from HTML by using Java custom tag libraries.  The JSP best practices found in the following articles will be used when developing the user interface for LCS, as necessary to improve the design of the system.

·        Servlets and JSP Best Practices (http://java.sun.com/developer/technicalArticles/javaserverpages/servlets_jsp/)

·        JSP Best Practices (http://www.javaworld.com/javaworld/jw-11-2001/jw-1130-jsp.html)

·        More JSP Best Practices (http://www.javaworld.com/javaworld/jw-07-2003/jw-0725-morejsp.html)

In particular, the following best practices from the articles mentioned above shall be used.

  1. Separate HTML from Java
  2. Place business logic in JavaBeans
  3. Factor general behavior out of custom tag handler classes
  4. Favor HTML in Java handler classes over Java in JSPs
  5. Use an appropriate inclusion mechanism
  6. Use a JSP template mechanism
  7. Use style sheets
  8. Use the MVC pattern
  9. Use available custom tag libraries
  10. Use JSP comments in most cases
  11. Follow HTML best practices
  12. Utilize the JSP exception mechanism
  13. Precompile JSP pages

In reference to number 11 above, the XHTML standard shall be used, such that the final HTML that is produced conforms to this standard.  Following the XHTML standard leads to HTML that is easier to read, understand, and maintain.  In addition, the XHTML standard provides the opportunity to mix XML with HTML and utilize XML tools to produce web content.  This design does not make use of XML tools to produce web content, but future maintenance may require this.  Refer to the following document for detailed information on the XHTML standard.

·        http://www.w3.org/TR/xhtml1/

3.2 Page Components

Struts contains a JSP template mechanism called Tiles (see http://struts.apache.org/userGuide/dev_tiles.html) for breaking up JSP pages into components called tiles (e.g. header, footer, menu, body) so that those components only need to be written once but can be included on multiple pages.  This reduces the amount of markup that needs to be maintained and makes it easier to change the look and feel of a website.  Tiles consists of JSP custom tags for doing the inclusion of page components (page tiles), an XML configuration file for defining what components are included on each page, and controllers for gluing it all together.

A layout will be defined for the web pages of LCS using tiles that will allow the menu component to be included on every page except for the login page, without the use of frames.  The layout that this will provide is illustrated below.

Figure 3.1  Page Layout

The header and footer in the layout will not be used but are provided for maintainability (i.e., the customer decides they want a footer on every page).  The body is where the content of the page will be included and itself may be a layout.  The detail of how the body is created is left to the developer.

3.2.1 Menu System

The menu for all user types prior to login is shown to the left in figure 3.2.2.  From this menu users will have the ability to log in or perform searches.

A logo will appear at the top and clicking on the logo prior to login will bring the user back to the home page.  The body of the home page will show an input form for performing a basic search.  Below the logo will be links to perform a basic or advanced search.

 

 

 

 

Figure 3.2  Login Menu

 

After login, the menu will be dynamically created based on the user’s privileges.  A screen shot of how the menu will look when a librarian is logged in is shown to the left in figure 3.2.3.  A logo will appear at the top and clicking on the logo will bring the user to their inbox.  Below the logo will be links to other functionality.  Different user types will have different links displayed.  All users will have the Inbox, Change Password, Logout, Basic Search, and Advanced Search links.  The links displayed for each user type will be according to the requirements specified in the SRS.

 

When the user clicks on a link the body of the page will display information appropriate to that link.  Any time the user clicks on a link in the menu, whatever actions they were currently performing (i.e., searching for items) will be cancelled.  Therefore, if the user wants to cancel an action, the user only needs to click a different link in the menu.

 

 

Figure 3.3  Menu After Login

 

3.2.2 Look and Feel

All system-wide styles will be maintained in a Cascading Style Sheet including font types, font sizes, and colors.  The system will be delivered with the colors of Southern Polytechnic State University as detailed in the following sections.

 

3.2.2.1 Colors

The colors for the system are shown below in hexadecimal format.

·        #006A00:  This is a green color that will be used as borders and the background color of buttons.

·        #FFCC00:  This is a yellow color that will be used as the background color of the menu and as the text color of buttons that a mouse is hovering over.

·        #0000FF:  This is a blue color that will be used for links in the menu, and links in the body.

·        #FFF5EE:  This is a light pinkish color that will be used as the background color for messages and errors that are displayed to the user.

·        #000000:  This is a black color that will be used as the border of the box that contains the message or error that is displayed to the user.

·        #8B0000:  This is red color that will be used as the text color of errors displayed to the user.

·        #0000BB:  This is a blue color that will be used as the text color of messages that are displayed to the user.

The buttons of the system will have a green background and white text.  The white text will change to yellow when hovered by a mouse.  An example of the button without the mouse hovering is shown below.

The developers are free to use other colors as necessary as long as the team agrees upon them.

 

3.2.2.2 Fonts

The following fonts will be used.

·        Verdana:  This will be the default text of the system.  If another font isn’t specified, this will be the font that is used.

·        monospace:  Input fields will use this font.

·        Helvetica:  Input field labels will use this font.  Text links in the menu will also use this font.

·        Arial:  This font can be used as appropriate for creating a different look.

The developers are free to user other sans-serif fonts as necessary as long as the team agrees upon them.

 

3.2.2.3 Icons

The following icons will be used on multiple pages of the system.

·         Information:  This icon represents information.  Throughout the system additional helpful information will be displayed next to this icon.  This icon does not react to being clicked on.

 

3.2.2.4 Errors and Messages

Errors and messages for the system will be displayed in two formats.  JavaScript on the browser will be used to display alert boxes and confirm boxes with errors and messages that are generated on the client.  Typically, the JavaScript generated messages will be displayed due to validation on the client alerting the user that incorrect information has been entered, or information that is required has not been entered.  Other errors and messages will be generated on the server and inserted into the HTML of the page that is displayed.  These messages will be generated due to validation on the server of the same type that is done on the client with the addition of checks that can’t be done on the client.  The messages generated by the server will as just be informational at times.  The messages generated on the server with the use of the following Struts classes.

·        org.apache.struts.action.ActionMessage: An encapsulation of an individual message.

·        org.apache.struts.action.ActionError: An encapsulation of an individual error message.

·        org.apache.struts.action.ActionMessages: A container for ActionMessage objects.

·        org.apache.struts.action.ActionErrors: A container for ActionError objects.

These messages will then be inserted into JSP pages using the following Struts custom tags, which are part of the Struts HTML tag library.

·        org.apache.struts.taglib.html.ErrorsTag: Renders error messages.

·        org.apache.struts.taglib.html.MessagesTag: Renders messages.

Errors will be displayed in red, and informational messages will be displayed in blue.  The detail of the colors was described above.  Below is an example of both a JavaScript message and a message generated by the server.

 

 

Figure 3.4  JavaScript Generated Error Message

 

Figure 3.5  Server Generated Error Message

3.3 System Screens

3.3.1 Login Screen

Any user of the LCS that has a user ID and password may log in and perform functions that are secured from general use.  The basic steps for logging in are as follows.

·        Click the Log In button.

Figure 3.6  Login Screen

3.3.2 Basic Search Screen

Any user of the LCS may search the library’s holdings without providing personal information or logging in.  The basic steps in performing a search are as follows.

Figure 3.7  Basic Search Screen

3.3.3 Advanced Search Screen

Any user of the LCS may search the library’s holdings without providing personal information or logging in.  The basic steps in performing a advanced search are as follows.

Figure 3.8  Advanced Search Screen

3.3.4 Check Out Items Screen

Any user of the LCS that is a librarian or administrator may log in with their user ID and password and check items out to a user.  The system performs basic checks to validate the action.  For example, it checks to see if the user has already checked out the maximum number of items permitted for the user.  Also, it prevents an item from being checked out to two different users at the same time.  The basic steps for checking an item out to a user are as follows.

 

Figure 3.9  Check Out Item Screen

3.3.5 Check In Items Screen

Any user of the LCS that is a librarian or administrator may log in with their user ID and password and check in items returned by a user.  The basic steps for checking in an item are as follows.

 

Figure 3.10  Check In Item Screen

3.3.6 Reports Screen

Any user of the LCS that is a librarian or administrator may log in with their user ID and password and generate reports.  The basic steps for generating a report are as follows.

Figure 3.11  Reports Screen

4. Data Design

4.1 Database Description

MySQL Version: 4.0.18 will be the database used in this system.

4.2 Physical Entity-Relationship Diagram

 

Figure 4.1  Physical ER Diagram

4.3 Logical Entity-Relationship Diagram

Figure 4.2  Logical ER Diagram

4.4 Data Dictionary

4.4.1 Role Table

DATA

DESCRIPTION

TYPE

SIZE

FORMAT

PRIMARY KEY

FOREIGN KEY

RoleID

ID number assigned to each role

INTEGER

1

1

·

 

RoleName

Name of the role

VARCHAR

10

Admin

 

 

 

4.4.2 User Table

DATA

DESCRIPTION

TYPE

SIZE

FORMAT

PRIMARY KEY

FOREIGN KEY

User ID

ID of user

BIGINT

20

1234567890

·

 

UserLoginID

Login Id of the User

CHAR

8

Kmullen

 

 

First Name

User’s first name

CHAR

48

Kendra

 

 

Middle Name

User’s middle name

CHAR

48

Bill

 

 

Last Name

User’s last name

CHAR

48

Mullen

 

 

Password

User’s password

VARCHAR

8

1qaz2wsx

 

 

Password

Expiry date

Date User’s password expires

DATETIME

 

2004-02-26 23:01:01

 

 

Email

User’s email address

CHAR

40

Kmullen@yahoo.com

 

 

RoleID

ID number assigned to each role

INTEGER

1

1

 

·

Status

Type of the User

INT

1

3

 

 

MaxNumOfItems

Maximum number of items user can checkout

INT

3

5

 

 

 

4.4.3 Config Table

DATA

DESCRIPTION

TYPE

SIZE

FORMAT

PRIMARY KEY

FOREIGN KEY

ID

Unique ID of configuration

BIGINT

20

123123

·

 

FinePerDay

Maximum amount of Fine Per Day

BIGINT

20

0.50

 

 

DurationCheckOut

Maximum number of days an Item can be checkout

BIGINT

20

14

 

 

DurationRenew

Maximum number of days an Item is renewed

BIGINT

20

14

 

 

MaxFine

Maximum fine for an Item

BIGINT

20

20

 

 

 

4.4.4 Author Table

DATA

DESCRIPTION

TYPE

SIZE

FORMAT

PRIMARY KEY

FOREIGN KEY

AuthorID

Unique ID of Author

INT

6

123123

·

 

Author

Name of the Author

VARCHAR

100

Ivan Jacobson

 

 

 

4.4.5 Subject Table

DATA

DESCRIPTION

TYPE

SIZE

FORMAT

PRIMARY KEY

FOREIGN KEY

SubjectID

Unique ID of Subject

INT

6

123123

·

 

Subject

Subject of the Resource

VARCHAR

100

Computer Programming

 

 

 

4.4.6 Resource Table

DATA

DESCRIPTION

TYPE

SIZE

FORMAT

PRIMARY KEY

FOREIGN KEY

ResourceID

Unique ID of Resource

BIGINT

20

123123

·

 

AuthorList

List of Authors

VARCHAR

100

Ivan Jacobson

 

 

SubjectList

List of Subjects

VARCHAR

100

Computer Programming

 

 

Title

Title for the Resource

VARCHAR

100

Java Programming

 

 

ISBN

ISBN for the Resource

VARCHAR

30

0-201-57167-2

 

 

CallNumber

CallNumber for the Resource

VARCHAR

30

QA76.76.D47J35

 

 

Publisher

Publisher name for the Resource

VARCHAR

30

Addison Wesley

 

 

Type

Type of the Resource

VARCHAR

30

Book

 

 

 

4.4.7 ResourceAuthor Table

DATA

DESCRIPTION

TYPE

SIZE

FORMAT

PRIMARY KEY

FOREIGN KEY

ReosurceAuthorID

Unique ID of ResourceAuthor

INT

8

123123

·

 

ResourceID

ID number for a Resource

BIGINT

20

56782309

 

·

AuthorID

ID number for a Author

INT

6

456473

 

·

 

4.4.8 ResourceSubject Table

DATA

DESCRIPTION

TYPE

SIZE

FORMAT

PRIMARY KEY

FOREIGN KEY

ResourceSubjectID

Unique ID of Subject

INT

8

123123

·

 

ResourceID

ID number for a Resource

BIGINT

20

67843498

 

·

SubjectID

ID number for a Subject

INT

6

45778

 

·

4.4.9 Fine Table

DATA

DESCRIPTION

TYPE

SIZE

FORMAT

PRIMARY KEY

FOREIGN KEY

FineID

Unique ID of Fine

INT

8

123123

·

 

UserID

ID number for a User

BIGINT

20

4589454

 

·

ItemID

ID number for an Item

INT

8

4892389

 

·

Amount

Amount of fine

INT

9

2.00

 

 

DateReturned

Date when an item was returned

DATE

10

06/12/2004

 

 

4.4.10 Item Table

DATA

DESCRIPTION

TYPE

SIZE

FORMAT

PRIMARY KEY

FOREIGN KEY

ItemID

ID number for a Item

INT

8

1234567890

·

 

UserID

ID number for a User

BIGINT

20

384983240

 

·

ResourceID

ID number for a Resource

BIGINT

20

5425905

 

·

Copy

Copy number of an Item

INT

9

2

 

 

Location

Location of an Item

VARCHAR

30

Second Floor

 

 

Status

Status of an Item

VARCHAR

30

In Library

 

 

DueDate

DueDate for an Item

DATE

10

07/10/2004

 

 

5. Component Design

5.1 Security

The security of the system will be implemented by using the HTTPS protocol (Secure Socket Layer - SSL).  The login screen will not be accessed with SSL, but the submission of the user’s credentials from the login screen and every page thereafter will use SSL.

The certificate and configuration required by Tomcat for SSL will be accomplished as described in the Tomcat documentation described here: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/ssl-howto.html.

5.1.1 Passwords

Passwords for users will be verified to meet the requirements set out in the SRS before being committed to the database.  This validation will occur every time a password is created even if it is created by the system.

Passwords will be hashed on the server using the SHA-256 hash algorithm before they are committed to the database.  This will prevent clear text passwords from being stored in the database and will ensure that the only person that knows the password is the user that created it.  The java.security.MessageDigest class will be used to hash the password.

5.1.2 User Names

User names of the system will be created by combining the first initial of their first name with the first 7 characters of their last name.  If a user name already exists with the calculated user name because someone else in the system has the same first and last name, then an integer (starting at 2 and incremented as necessary) will be added to the end of the calculated user name until a unique user name is created.

 

5.2 Domain Objects Components

5.2.1 Purpose

Domain object is a logical container of purely domain information, usually represents a logical entity in the problem domain space.

5.2.2 Subordinates

The Domain Objects Component is used by the all Components of the system.

5.2.3 Dependencies

Depend on all Components. Domain classes are created by DAO’s.

5.2.4 Data

Domain Objects will contain Get/Set methods. These methods will be used to retrieve and update the information required.

5.2.5 Interfaces

The Domain Layer is made up of the following Domain Objects: Resource, Item, Fine, User, Config, Author, Subject, ResourceAuthor, ResourceSubject, and Role.

·        Resource: Contains information like ResourceID, Author, Subject, Title, ISBN, CallNumber, Publisher, and Type.

·        Fine: Contains information like Fine ID, Amount, and DateReturned. And also has references to ItemID and ResourceID.

·        User: Will be abstract and represent a user of the system. Contains information like UserID, UserLoginID, Password, PasswordExpiryDate, FirstName, MiddleName, LastName, Email, Type, and MaxNumOfItems. And also has reference to RoleID.

·        Config: Contains information like ID, FinePerDay, DurationCheckOut, DurationRenew, and MaxFine. And also has a reference to ItemID and ResourceID.

·        Role: Contains information like RoleID and RoleName.

 

5.3 Business Services Components

5.3.1 Purpose

The business logic updates the state of the model and helps control the flow and the logic of the application. With Struts this is done with an Action class as a thin wrapper to the actual business logic. Action classes (part of the Controller role, as described below) translate all required information from the HTTP request being processed into property setter calls on your business logic beans, after which a call to an execute method can be made.

5.3.2 Subordinates

The Business Service Component is used by the Action Classes.

5.3.3 Dependencies

Depend on the Model Component.

5.3.4 Data

5.3.5 Interfaces

The Business Logic Layer is made up of the following Business Logic Objects: ItemBS and UserBS

·        UserBS: Contain all the required business logic for User.

 

5.4 Model Component

5.4.1 Purpose

There will be Model objects that act as Proxies to the DAOs and provide validation logic and caching of data from the database that will not change unless the system is brought down for maintenance.  All requests by the rest of the system to obtain data from the database will be made to the Model objects.

5.4.2 Subordinates

The Model Component is used by the Business Service Component.

5.4.3 Dependencies

Depend on the DAO Component.

5.4.4 Data

5.4.5 Interfaces

The Model Layer is made up of the following Model Objects: ItemModel, FineModel, and User Model.


5.5 Data Access Component

5.5.1 Purpose

The purpose of the Data Access component is to store and retrieve data from the database. The Data Access Component uses Java Data Base Connectivity (JDBC) to communicate with the database.

5.5.2 Subordinates

The Data Access Component is used by the Model Component.

5.5.3 Dependencies

Depend on the database.

5.5.4 Data

DAO’s will contain all of the SQL logic that is used to create the domain objects by pulling information from the database.  There will be a separate DAO for each domain object.  The DAO objects methods will be assigned package scope so that they will be hidden behind the Model, thereby forcing the system to use the Model objects instead of directly using the DAO’s.

5.5.5 Interfaces

The Data Access Layer is made up of the following Data Access Objects (DAOs): ResourceDAO, ItemDAO, FineDAO, UserDAO, ConfigDAO, AuthorDAO, SubjectDAO, ResourceAuthorDAO, ResourceSubjectDAO, and RoleDAO.

·        ItemDAO: This class has all the functionality needed to connect to database and retrieve or update information about the Item.

·        FineDAO: This class has all the functionality needed to connect to database and retrieve or update information about the Fine.

·        UserDAO: This class has all the functionality needed to connect to database and retrieve or update information about the User.

·        ConfigDAO: This class has all the functionality needed to connect to database and retrieve or update information like FinePerDay, DurationCheckOut, DurationRenew, and MaxFine.

·        RoleDAO: This class has all the functionality needed to connect to database and retrieve or update information about the Role

5.6 Controlling Logic

The Struts request processor that acts as a Front Controller and handles all requests to the system will be extended to provide functionality that checks if the user is logged in on every request.

In addition, an object called PathInfoDispatchAction will be created that extends the Struts org.apache.struts.actions.DispatchAction class and provides the capability to define an action in the Struts configuration that will be executed when a path with the name of a method in the PathInfoDispatchAction is requested.  For example, the path http://lcs/app/login will execute the login method in the SecurityDispatchAction class.

The SecurityDispatchAction class will extend the PathInfoDispatchAction class and handle all security related requests including log in, log out, and change password.

All action classes will use the Model objects (which in turn use the DAO objects) when requesting or modifying information in the database.

A context listener of the application context will kick off two threads at application startup.  One will check for a file to exist to upload new student users to the system, and the other will dump data from the database to a comma delimited flat file for all approved time at the end of each pay period.

 

6. UML Class Design Diagrams

The following sections contain UML diagrams that describe the most significant classes of the system.

The Domain objects are used throughout the system.  Business Service objects will contain most of the business logic and will make calls to the Model objects to retrieve Domain objects populated with data from the database.  The Model objects will contain logic for caching database data and validating data to be committed to the database.  The Data Access Objects (DAO) will contain all of the JDBC SQL logic.

This model involving Domain objects, Business Service objects, Model objects, and DAOs was chosen because it provides a clean separation of responsibilities.  Separating the responsibilities in this fashion reduces the amount of effort required to add/modify/remove functionality from the system, migrate the system to a different database, or migrate the system to a different user interface.

6.1 Class diagram for Domain Classes

 

6.2 Model Classes

 

6.3 DAO Classes

 

7. UML Sequence Diagrams

The following sections contain sequence diagrams that describe the interaction of the classes in the system.  The “Client” in the diagrams is the web browser.  The “Front Controller” is the Struts ActionServlet/RequestProcessor combination, which intercepts all requests made to the system and dispatches those requests to the appropriate Action classes.

7.1 User LogIn Sequence Diagram

7.2 Add Item Sequence Diagram

7.3 CheckIn Item Sequence Diagram

7.4 CheckOut Item Sequence Diagram

7.5 Renew Item Sequence Diagram

7.6 Reserve Item Sequence Diagram

7.7 Search Item Sequence Diagram

 

Appendix A: Requirements Traceability Matrix

Functional Requirement ID

Requirements Description

Use Case Number

FR1

The system shall enable any Librarian to give Librarian rights to other users. A Librarian shall be able to change user type to “Librarian” or “Student” or “Faculty”

UC02

FR2

The system shall enable the Librarian to change the number of items each user can check-out

UC07

FR3

The system shall enable the Administrator to change a user’s type to any user type

UC02

FR4

The system shall enable the Administrator to change user passwords

UC01

FR5

The system shall allow the user to log in based upon an assigned login id and password

UC20

FR6

The system shall enable users (Students and Faculty) to change their passwords

UC19

FR7

The system shall provide the user with a status of their checked out items with the following information:

o       Person Status

o       Call Number

o       Title

o       Author

o       Check-out Date

o       Due Date

o       Item Status (Checked Out, Renewed, Overdue etc)

o       Fines and Fees

UC20

FR8

The system shall provide the Librarian/Administrator with at least the following features:

o       Administration

o       Inventory

o       Reports

UC20

FR9

The system shall allow users to logout of the system

UC20

FR10

The system shall enable the Administrator to configure the due date calculation for an item, currently 14 days

UC03

FR11

The system shall enable the Administrator to configure the fine/item/day for an overdue item, currently 50 cents/day

UC04

FR12

The system shall enable the Administrator to configure the maximum fine per item, currently $10 per item

UC05

FR13

The system shall automatically set the user status to “ABLE TO CHECK-OUT” if the user has no books overdue and if the user hasn’t reached the checkout limit

UC12

FR14

The system shall automatically set the user status to “NOT ABLE TO CHECK-OUT” if the user has books overdue or if the user has reached the checkout limit

UC12

FR15

The system shall automatically compute the due date for every item checked out, which is currently 14 days from the date an item is checked out

UC12

FR16

The system shall automatically send e-mail to the user when an item is overdue

LOW

FR17

The system shall compute fines automatically for overdue items.  The fine is currently 50 cents/day.  The fine should not exceed the maximum fine per item (the maximum fine is currently $10 per item)

UC11

FR18

The system shall automatically set the Item Status to IN LIBRARY when a new item is added and when the Librarian checks in item

UC11

FR19

The system shall automatically set the Item Status to CHECKED OUT when an item is checked out

UC12

FR20

The system shall automatically set the Item Status to RENEWED when an item is renewed

UC17

FR21

The system shall automatically set the Item Status to OVERDUE when an item is overdue

UC

FR22

The system shall automatically set the Item Status to LOST when an item is overdue for more than 60 days

UC

FR23

The system shall automatically compute the due date for every item renewed, which is currently 14 days from the date an item is renewed

UC

FR24

The system shall allow the Librarian to add items

UC08

FR25

The system shall store the item information. [And shall set the Status to IN LIBRARY] See FR18.

UC08

FR26

The System shall display a confirmation message confirming the addition of a new item

UC08

FR27

The system shall allow the Librarian to edit item information

UC09

FR28

The system shall allow the Librarian to correct the status (MISSING or REFERENCE) of an item

UC09

FR29

The system shall allow the Librarian to delete items

UC10

FR30

The System shall display a confirmation message confirming the removal of an item

UC10

FR31

The system shall allow the Librarian to check-out items

UC12

FR32

The system shall allow only valid users to checkout an item. A user is considered to be a valid user if the user currently exists in the system and the status of the user is set to “ABLE TO CHECK-OUT” by the system.

The following is the list of the possible statuses for a user:

o       ABLE TO CHECK-OUT - This user status is set automatically by the system if the user has no books overdue and if the user hasn’t reached the checkout limit. See FR13.

o       NOT ABLE TO CHECK-OUT – This user status is set automatically by the system if the user has books overdue or if the user has reached the checkout limit. See FR14

UC12

FR33

The system shall limit the number of items a user can check-out (5 is the default)

UC12

FR34

The system shall update the user’s checkout information with the Call Numbers, date checked out, and due dates. See FR6

UC12

FR35

The system shall allow the Librarian to check-in items

UC11

FR36

The system shall update the user’s checkout information showing the item is no longer checked out

UC11

FR37

Allow Librarians to see what items a particular user has checked out

UC12

FR38

If there are no items checked out, the system shall display an appropriate message

UC12

FR39

The system shall enable any user to perform advanced search for an item without logging into the system. The following are the Advanced Search capabilities the system provides:

o       Search based on authors/co-authors

o       Search based on item title

o       Search based on Call Number

o       Search based on ISBN

o       Search based on Subject

UC16

FR40

The system shall enable any user to perform a simple search on items

UC15

FR41

The search results shall display a list of items, which match the search parameters with the following details:

o       Title

o       Author

o       Library Location

o       Call Number

o       Status (Checked Out, IN Library etc)

UC15

UC16

FR42

The system shall display a detailed view of an item when the user selects an item from the search results. The details to be displayed are:

o       Author

o       Title

o       Publisher

o       Subject(s)

o       Location

o       Call Number

o       Number of Items

o       Status

UC15

UC16

FR43

If no matching items are found, the user will be notified

UC15

UC16

FR44

The system shall enable users to renew items online by logging into the system. Once a user logs in and sees a list of items they have checked out, they may renew items

UC17

FR45

The system shall allow the user to select the items to be renewed

UC17

FR46

The system will update the display accordingly with the new due date

UC17

FR47

If the user has already renewed the item once, the system will inform the user that the maximum number of renewals has already been made and the item cannot be renewed

UC17

FR48

The system shall allow the Librarian to override the default item due date when renewing an item

UC06

FR49

The system shall enable users to reserve items online by logging into the system

UC18

FR50

The system shall enable users to cancel items on reserve

UC18

FR51

The system shall enable the Librarian to execute the report of overdue items

UC13

FR52

The Librarian shall specify the field on which the report is to be sorted.  The options are:

o       First Name

o       Last Name

o       Person ID

o       Item Name

o       Call Number

o       Due Date

UC13

FR53

The report shall consist of the following fields:

o       User Name (First Name, Last Name)

o       Person ID

o       Item Name

o       Item ID

o       Item Author

o       Call Number

o       Due Date

o       Fines and Fees

 

UC13

FR54

Once the report is displayed on the screen the system shall provide the option to print the report

UC13

FR55

If there are no overdue items, no report is generated

UC13

FR56

The system shall enable the Librarian to execute report of missing items

UC14

FR57

The Librarian shall specify the field on which the report is to be sorted.  The options are:

o       Item ID

o       Item Name

o       Call Number

o       ISBN

UC14

FR58

The report shall consist of the following fields:

o       Item ID

o       Item Name

o       Item Author

o       Call Number

o       ISBN

o       Missing Date

UC14

FR59

Once the report is displayed on the screen the system shall provide the option to print the report

UC14

FR60

If there are no missing items, no report is generated

UC14

Appendix B: Use Case Diagram and Detailed Use Cases

 

Use Case Diagram: LCS System

Figure B.1 Use Case Diagram