Specifications For Phases 1 - 4 of the Library Application

  Skip Navigation Links

Library Phase 1– Windows Front-End Application

Objective

A database has been created to support the principal functions of a lending library’s day-to-day operations: adding new members (adult and juvenile) and checking books in and out. An assembly has been created that contains classes and interfaces that provide access to the database for these functions. What is needed is a Windows Forms-based front-end application that will provide a librarian with a visual interface through which he or she may perform the desired functions. Creating that application will be your task.

Requirements

• Design and develop a front end application that satisfies the four basic functionalities: Add Adult, Add Juvenile, Check In a book, Check Out a book.

• Develop code that is easily maintainable.

• Provide validation for all required fields (see details below).

• Provide adequate error handling.

• Produce a user interface that is intuitive, requiring minimal training for users while minimizing resource utilization.

Provisions

• Database scripts are provided in order to create the Library database (see APPENDIX A).

• An interface that specifies the methods supported by the Data Access tier used for all database access and a class that implements the interface are provided. Classes that represent various “business entities” (e.g., an AdultMember class) are also provided. Detailed information appears in Appendix B.

• A reference implementation that illustrates one possible solution for this project is provided. The reference implementation is not intended as a model to be emulated in your solution; rather, it serves only to illustrate how you might implement your solution, rather than how you must implement your solution. If you wish to use the reference implementation as a basis for how your implementation will appear and function, you are free to do so, but you are not obligated to replicate the appearance of the reference implementation.

Validation

• First name, Last name must be non-empty strings consisting of alphabetic characters only, with a leading uppercase character and all others in lowercase, at most fifteen characters in length.

• Middle initial is optional, but if entered it must be one uppercase alphabetic character.

• Street address and city must be non-empty strings, no more than fifteen characters in length each.

• State must be two uppercase alphabetic characters.

• Zip must be a non-empty string in the format: ##### or #####-####, where # is a digit (0-9).

• Phone is optional, but if entered it must be in the format: (###)###-####.

• For a juvenile member, birth date must be a valid date (MM/DD/YYYY format), and the birth date must fall within the eighteen-year period ending on the current date.

• ISBN, Copy number, and Member ID must be positive integer values (>0). ISBN must be a 32-bit integer value. Copy number and Member ID must be 16-bit integer values.

Overview of Library Operations

Before a database to support library operations was implemented, an interview was conducted with the librarians who would be performing these operations using the new application. The following sections describe the considerations that influenced the design and implementation of the database.

Uniquely Identifying Books

Some books may have the same title; therefore, titles cannot be used as the sole means of identification. Librarians call books items. Items are identified by the International Standard Book Number (ISBN). Books with the same title can have different ISBN numbers if they are in different languages and have different bindings (hard cover or soft cover). Multiple copies of a given item may be held in the library’s collection. Copies of a given item are numbered with copy numbers from 1 through n, where n is the number of copies of that item. A physical item is thus uniquely identified by the pairing of its ISBN and its copy number.

Enrolling Members

To become a library member, an individual must provide his or her mailing address and, optionally, his or her phone number. A librarian then issues the individual a numbered, machine-readable card. This card is good for one year from the date of issue.

Juveniles are considered to be individuals under the age of eighteen. A juvenile can be a member of the library, but must have an adult member sign for them when they join. The juvenile’s address and phone number information is that of the sponsoring adult member, and the juvenile’s card is valid only until the sponsoring adult member's card expires. The only information that the library keeps on a juvenile member is his or her name, sponsoring adult member card number, and his or her date of birth.

Checking Out Books

Books are checked out for 14 days. Members are allowed to have at most four books checked out at a time. Members bring books to the front desk after they locate the ones that they want to check out. A librarian then enters the card number from the member's card. A screen displays information about the member's account, such as name, address, phone number, and the card's expiration date. Ideally, cards that have expired will be highlighted. The screen also displays information about a member's outstanding loans, including title, checkout date, and due date.

If a member's account is in order (i.e., the card is not expired and fewer than four books are on loan to the member currently), a librarian checks out the books. Librarians check out books by entering the ISBN and copy number of the item, both of which appear in a label on the book’s spine. The ISBN, copy number, title, and author information then appear on the computer screen so that the librarian may verify that the database entry corresponds to the item being checked out. The librarian then can elect to check the book out or to cancel the check-out operation.

Occasionally, books are accidentally re-shelved before librarians check them in. If a librarian tries to check out a book that the database lists as already checked out, the librarian should be alerted and be given the opportunity to check the book in before proceeding with the check-out operation.

Checking In Books

When a book is returned to the library, a librarian checks it in by entering the ISBN and copy number that appears on the book’s spine. The ISBN, copy number, title, and author information then appear on the computer screen, as well as the card number and name of the member to whom the book is checked out, and the book's due date. The librarian can then elect to check the book in or to cancel the check-in operation.

Data Validation

To enroll an adult member, the required fields are:

• First name

• Last name

• Street

• City

• State

• Zipcode

Middle initial and phone number are optional fields.

To enroll a juvenile member, the required fields are:

• First name

• Last name

• Adult member ID

• Birthday

Middle initial is an optional field.

First name and last name fields must be validated to ensure that the values contained in these fields are alphabetic only and that the first character of each of these fields is uppercase.

The Zipcode field must be validated to ensure that only a five-digit (XXXXX) or a nine-digit (XXXXX-XXXX) value is entered.

If a value is entered into the middle initial field, that field must be validated to ensure that the value entered is a single alphabetic character.

If a value is entered into the phone number field, that field must be validated to ensure that the value conforms to the format (XXX)XXX-XXXX, where X is a digit from 0 through 9. Note there is no space after the right parenthesis; the field in the database for the phone number is thirteen characters long, so including a space at this point would cause the phone number to be truncated.

The adult member ID field must be validated to ensure that it contains only a numeric value in the range 1 through 32767 inclusive.

The birthday field must be validated to ensure that it contains a value in the format MM/DD/YYYY and that the value parses to a date that is no more than eighteen years prior to the current date.

When a member ID is entered to perform a member lookup, that field must be validated according to the same rule specified for the adult member ID field above.

For the ISBN and copy number fields used in the check-in and check-out operations, these fields must be validated to ensure that only numeric values are entered. For the copy number field, the value must be in the range 1 through 32767 inclusive.

Suggested Project Techniques

• Use menus instead of buttons to free screen space, when appropriate.

• Use combo boxes (drop-down lists) and list boxes instead of free-form textboxes for data entry whenever possible.

• Avoid overuse of message boxes and other modal communications to the user. Use other display techniques such as a status bar or a label.

• Use standard naming conventions to provide code readability.

• Make use of collections to produce concise code.

• While calls into the data access class’s methods by the presentation tier (i.e., by the code in your Form’s event handlers) are permitted, you might want to consider creating a middle tier for mediating between your presentation tier and the data access tier. Using a middle tier can simplify the code in your presentation tier considerably.


Library Phase 2– Windows Business & Data Access tiers

Requirements

• Design the Business and Data Access tiers

• Develop code that is easily maintainable.

• Provide adequate error handling.

• Use database-programming techniques that provide maximum programming flexibility and control while minimizing resource utilization.

• Work with your instructor who will act as the project DBA for any required SQL help.

Library Database Design

Based on the information that librarians presented, the project database designer decided to implement the entities from the scenario presented in Phase 1 of the Library Project in three groups of tables: tables that contain member information; tables that contain item (book) information; and tables that contain loan information.

Member Information

The member table is the master table, while adult and juvenile are subtables. All three tables use the member_no column as a primary key. The member_no column in the member table is also an autoincrementing column; i.e., it is an identity column. Since a member is identified uniquely by his or her member number, the member_no column is a good choice for a primary key.

These entities could have been modeled alternatively in a couple of different ways: as a single table; or as member and juvenile tables. If a single table had been used for all members, many addresses would have been duplicated because juveniles in this model have the same address as their parents. Since birth dates must be stored only for juveniles, splitting the membership information into several tables eliminates the null column values that would have resulted for the birth dates of adults. Dividing the tables in this fashion also models the scenario in a way that reflects the membership of the library: member-to-adult is a one-to-one relationship, while adult-to-juvenile is a one-to-many relationship.

Item Information

The title, item, and copy tables form a second logical group. The master table of this group is the title table. For each listing in the title table, one or more entries exist in the item table because a book may be available in several languages, in paperback or hardback, and may be loanable or not loanable. Title-to-item is a one-to-many relationship. Furthermore, for each listing in the item table, one or more copies of that item can exist. Therefore, item-to-copy is a one-to-many relationship.

The item table contains the loanable column. Rather than including information from this column in the copy table, the database designer has assumed that all copies of a particular item are either loanable or not loanable.

The copy table has a composite primary key made up of two columns: the isbn column and the copy_no column. The combination of isbn and copy_no identifies each row in the table uniquely. The copy table contains a duplicate title_no column. This group of tables has been de-normalized to reduce the number of joins that are needed to retrieve information.

The on_loan column in the copy table is derived data - data that could be generated with a query each time that the information is needed. The loan table could be used as the sole source of information on whether an item is on loan. Because the loan table changes frequently, locks could prevent a user from obtaining this information in a timely manner. The copy table is more likely to be used in a read-only fashion.

Loan Information

The reservation, loan, and loanhist tables contain the library's loan information. The reservation table tracks current reservations for each book; the loan table tracks information on books that are currently on loan: and the loanhist table stores information on books that have been loaned and returned. It is possible to combine the loan and loanhist tables to reduce redundancy, but this may create other problems.

The loanhist table is essentially a history of all loans and could become unwieldy. Over time, librarians may want to back up information from this table, so it makes sense to keep all of this information in its own table. In addition, this business model requires that several queries be made against the loanhist table. These queries would be easier to implement and faster to run if the history information were kept separate from the loan information.

The loan and loanhist tables also represent different functions of the application. When a member checks out a book, an entry is made to the loan table. When a member returns a book, an entry is made to the loanhist table, and the corresponding entry is deleted from the loan table. By maintaining separate tables for each function and denormalizing the tables, users can access the information more quickly. However, because the tables are denormalized they require more maintenance. For example, when item.title_no is updated, the title_no column must be updated in the loan, loanhist, and copy tables as well. Because updates to the title_no column may be infrequent, denormalization may speed queries.

Required Functionality

In Phase 1 of this ongoing project, you were provided with an assembly that encapsulated all the data access logic for your application. The assembly in Phase 1 employed ADO.NET to provide access to the library database. It did not, however, use any stored procedures, which could have made database operations more efficient. In Phase 2, you are to design and implement your own business and data access tiers. Use stored procedures which must be commented thoroughly and your code should not contain any SQL statements.

You were also provided an assembly that contained business entity classes needed for the project (e.g., Item, ItemCollection, etc.). You must not use either of the assemblies that were provided to you in your Phase 2 project. You must implement the business entity classes yourself.

You are not obligated to use the same interface that the data access object in the assembly provided in Phase 1 employed. If you wish to redesign this interface, you may do so, provided that all required functionality is supported.

In Phase 1 of this ongoing project, verification that an item presented for checkout is loanable was not a requirement. In this phase, you must perform that verification and prevent an item that is not loanable from being checked out.

Focus your efforts on the following:

• Add Adult: Rows are added to both the member table and the adult table

• Add Juvenile: Verification that the sponsoring adult member’s record exists must be performed. Rows are added to both the member table and the juvenile table.

• Checkout item: Verification that item is not already on loan must be performed. Verification that item is loanable must be performed. Row is added to loan table. Update copy table’s on_loan field to ‘Y’.

• Checkin item: Delete row from loan table. Add row to loanhist table. Update copy table’s on_loan field to ‘N’.

• The data access tier has to be stateless.

Remember to treat operations that involve multiple tables as transactions.

Extra functionality (if you have time)

You may choose to add one or more of the following extra functionalities to your application, if time permits.

Convert juvenile membership to adult membership: When any operation is performed that involves a member lookup, if the membership record found is that of a juvenile and the member has reached or passed his or her eighteenth birthday, notify librarian that juvenile’s information is being converted to an adult membership record, complete the conversion, and display the adult record.

Add a new book to the library: If ISBN exists, add row to the copy table with a copy_no entry that is one more than the number of copies for that ISBN already in the database. If ISBN does not exist, add appropriate data to the item, title, and copy tables; use “1” for the copy_no field.

Highlight overdue item: Whenever a checked-out item is displayed whose due date has passed, highlight that item.

Suggested Project Techniques

• Encapsulate business logic wherever possible.

• Use business entities to encapsulate discrete items of information that are related logically; e.g., an Item class to encapsulate information about a single book; an ItemCollection class to encapsulate a collection of Items; etc.

• Use programmatic ADO.NET code to get the most flexibility with minimal overhead.

• Centralize error handling when possible for easier maintenance.

• Use standard naming conventions to provide code readability.

• Use Windows Integrated Security to connect to the library database.

• Use the SQL Server .NET Data Provider.


Library Phase3– Web Application

Requirements: Create a web application that supports all the functionality required for Phase I and II of the Library project.

Additional requirements:

• When displaying an adult’s information, the application should detect if the card is expired and give the librarian a chance to renew the card. Librarian must be able to choose whether or not to renew the card. The renewal date is today plus one year. Members can not check out books if the card is expired.

• When dealing with juveniles, the application should detect if the juvenile is 18 years old or older and convert the member to an adult (row deleted in the juvenile table, row added to the adult table). This operation is not at the discretion of the librarian; i.e. the upgrade must take place automatically and the librarian must be notified that the updgrade has taken place.

• Overdue books, shown in any display, must be highlighted.

• The librarian must be able to enter a new book into the database. If the ISBN already exists in the database, all that is needed is to add a record for a new copy number. If the ISBN does not yet exist in the database, you must add all necessary records for the new ISBN and a new copy number 1 for that ISBN.

• Use of hyperlinks to navigate between pages.

Project locations and requirements:

• Create your web application project as a File System project. Your solution folder must contain all your project folders so that when you submit the solution folder all necessary parts of your application are present. Your solution must include the source for all your projects; i.e. not just the DLLs for your business tier and data access tier projects.

• The web application project must use Forms-based authentication and authorization. Only members of the Librarian role must be able to access the web application. (Use the membership and role management features of ASP.NET 2.0. Create a Librarian role and at least two Librarian users.)

When submitting your project, all of the folders that relate to the application must be included in the submission. You will be instructed at a later time how to submit your project.


Library Phase 4 - Web Services

Scenario

Our library system roll-out has been very successful. As the potential to acquire libraries and creating partnerships with others increases, we see the need to take the library system to the next level – allow interoperability with other systems.

With your success on the library system thus far, we are tasking you to provide a proof of concept implementation that utilizes Web services.

To provide the proof of concept system, you must implement a system that uses Web services to offer access to either the data layer or business layer. Due to the possibility of utilizing the service between our own systems and those of our partners, security must be employed.

Either Windows or Web-based (ASP.NET) clients can be used in demonstrating the system utilizing Web services.

Requirements

Create a Web service that calls into either the business or data layer. Do not re-write either layer. Simply have the service call into the appropriate layer.

Update the layers in the system to use the service as deemed appropriate. For example, if the service calls into the business layer, then the user interface (i.e. the client) will need to change to use the Web service instead.

• Make sure the Web service supports the Basic Profile. The service also should use Document/Literal formatting of the Soap messages.

Customize formatting of XML for some of the business types. It is up to you on what to customize, but one option would be to treat MemberID and MemberNumber properties as attributes.

Employ WSE 3.0 security using Certificates. Signing, encryption and secure session are required.

Support previous project functionality.

Areas of Concern

You may need to address some or all of the following issues in migrating to the use of Web services in the library system. There may be other concerns that will come up during the implementation. Address those areas as the need arises.

AddMember is an overloaded method. Basic Profile Web services do not natively support overloaded operations.

GetMember is also overloaded. Basic Profile Web services do not natively support overloaded operations.

Pass by reference behavior is not available natively with Web services. This may effect the design of the AddMember methods.

Exceptions like LibraryException will be converted into SoapExceptions. To get cleaner error handling, you will want to throw your own SoapExceptions or use a SoapExtension to control the formatting of the exception.

If your business entity (ex. Member) checks values, you may have to use the DefaultValue attribute on the property to assist in the serialization/deserialization of the class.

GetMember returns the base class Member. To tell the client and web service to handle the sub-classes correctly, use the XmlInclude attribute.

Milestones

Implement all the basic Web service functionality. Do not move on to security until the Web service works correctly. This should include interoperability with the client application.

Add security to the Web service implementation.

Test thoroughly.

Submit your final solution for evaluation.

Submission Requirements

As per Phase 3, all parts of the solution should reside under a common parent folder.

Use Integrated Security for access to the database.

Ensure that all files are included in the submission.

Detailed submission instructions will be provided to you at a later time prior to the project due date.


APPENDIX A

SETFOCUS LIBRARY PROJECT INSTALLATION

1. Copy the LIBSQL folder to your C Drive.

2. Open a Command Prompt window.

3. Change to the C Drive by typing C: and pressing enter.

4. Change directory to the LibSql folder by typing “cd libsql” then press enter.

5. Now enter the command “bldlib” and press enter.

A series of actions will be performed that result in the library database being installed in your SQL Server. At the end of this series of actions, a window will pop up that displays a log of the output of each of the actions. Close the log file window, then close the Command Prompt window.

You may examine the library database by viewing it in the SQL Server Enterprise Manager, if you wish.

APPENDIX B

A file named RTFLibraryDocumentation.chm has been provided to you. If you double-click on this file, it will open a help window with MSDN-like documentation for the three assemblies that are provided for your use in this project: LibraryDataAccessInterface.dll, LibraryDataAccess.dll, and LibraryEntities.dll.

These assemblies are strong-named. The first assembly contains an interface specification IDataAccess, which defines the data access methods that are implemented by the DataAccess class. The second assembly contains the DataAccess class. The third assembly contains definitions of the member objects that are used by the data access tier, of a LibraryException class, and of an enumeration that provides error codes that are encapsulated in instances of the LibraryException class.

The Member class is a base class from which the AdultMember and JuvenileMember classes are derived.

The Item class contains information about a single item (a book) in the library.

The ItemsDataSet class is a typed DataSet that contains a single table (Items). This table contains zero or more rows, where each row contains information about one of the items (books) that a given member has on loan.

back                                      
© SetFocus, LLC