Assignment - Library System
Suppose that you are required to document a library system, particularly focusing on the functionality at the back end. The scope the system's back end is defined as follows:
• You should include all system functions and data, such as borrowing items, accessing both physical and electronic items, renewing loans, viewing a borrower's account (including overdue items and fines), searching catalogues for various items, renewing loans, login, and asking a librarian. Note that this list is not exhaustive.
• Some functionality (such as book rooms, access databases, borrow ebooks) is provided by applications integrated with the UNI library system. As such, you will need to show that the functionality is captured, but that no structural data is retained in this system.
• Front-end content, such as ‘getting started in the library', information pages (with static HTML content), the ‘About' section, reference guides, and general information, is out of scope, and thus is not required to be included in your work.
Some specific functionality is not necessarily apparent from public or student views, but should be included:
• An ITS officer uploads a list of lists of active borrowers each year. The list contains staff, student and ‘others'. On this list:
a. staff have a staff ID, barcode, name, DOB, and department
b. students have a student ID, barcode, name, DOB and department
c. others have a borrower ID, name, DOB, address & license number
• The uploaded list is compared to existing borrowers by the system. If a person have left the university, his/her account will be removed if they have no unpaid fines. Otherwise, their borrower status is changed to inactive, and their record is retained. A new borrower account is created for a new person on the list
• Librarians can also add borrowers. They create a borrower account with a name, DOB, and an expiry date.
• If borrowers do not have a card with a barcode (such as those that are just created by the librarian), their borrowing status is pending until they collect a library borrowing card from the library.
• If a borrower is late in returning items, a fine occurs. When a borrower has a fine exceeding $25, they can no longer renew or borrow any items until the fine is paid. Library fines must be paid in person to a librarian, who will then mark the fine as paid in the system and issue a receipt.
• Librarians can view any record in the system - catalogue items, borrower records, etc. They can search for a record or scan a barcode (of an item or borrower) to view the data.
• A borrower's status can either active, inactive, pending, temporary, or suspended.
• Staff may request the library to place items used by their course on ‘reserve' or ‘restricted borrowing'. Staff may also submit past exam papers to the library.
• The head librarian generates reports based on item usage, borrowing rates, and library usage by department type (staff and student).
You are required to play the role as a technical business analyst, analyzing the library system and creating diagrams as requested in the questions that follow. Note you are not modelling a website using storyboards, site-maps etc., but rather the back-end behavioural and structural needs of the system.
Task 1: Project planning
1.1 Draw a Gantt chart showing the project planning across the whole assignment process.
1.2 Create a Trello board for managing your assignment, and maintain the Trello board across the whole assignment process. Submit a set of snapshots for the Trello board showing the updating process.
Task 2: Requirements Documentation
Write a requirement, in plain English, for the scenario "Pay Fine". You may need to make creative assumptions for assignment purposes, and pretend you have conducted requirements elicitation with the client.
Your requirements will be assessed based on whether they:
• are verifiable, non-ambiguous, modifiable, traceable, consistent, and complete
• form a set of conditions, not only a series of operations / process descriptions
• relate to system requirements, not only business process
Hint: This is a potentially large task if you let your imagination run away with you. Try to keep your requirements to the minimum - you are not being assessed on creativity or system knowledge, just your ability to write a requirement!
Task 3: Use case diagram
You should provide one use case diagram that includes all actors and use cases within scope. Your diagram must include a use case named ‘Pay Fine', as documented in Task 2. Your diagram will be assessed based on:
• Consistency with the scope including the specific functionality requested
• Appropriate use of actors, includes/extends, and generalization
• Appropriate use of UML notation
Task 4: Use case textual description
Borrowing a book is the key function of this system. This functionally includes searching, borrowing and returning book to the library. Develop a description of the use case using "Template - Use Case textual description" as per Appendix.
Hint: This is a potentially large task if copious low-level data is included, so ensure you provide the appropriate level of information. For example, in the flow of events a step may be "Log in" or "System validation" instead of "insert student card with bar code facing up for scanning".
Task 5: Sequence diagram
You should create a sequence diagram for the scenario below:
Lee is a current student with active borrowing privileges. At a desk physically located in the library, Lee searches for the book named "UML Distilled". Viewing the results, Lee notes it is currently on loan and places a hold on the item.
Your diagram should highlight how objects interact to achieve the aims of the user and any objects that are created or destroyed. Your diagram will be assessed based on:
• Completeness and consistency with the scenario
• Appropriate identification and use of objects, messages, etc.
• Appropriate use of UML notation
Task 6: Class diagram of the library system
You should create one class diagram that reflects the data and behaviours of the library system.
Your diagram will be assessed based on:
• Consistency with the scope including the specific functionality requested
• Consistency with use case model in Task 3
• Inclusion of key classes, data members, operations and well-specified relationships
• Appropriate use of UML notation
Task 7: Activity diagram
Create an activity diagram to show the activities that are involved in a student searching for a book, and placing it on hold. Your diagram will be assessed based on:
• Completeness and consistency with both the scenario and the sequence diagram in Task 5.
• Appropriate identification and use of activities, transitions, decisions, branches, swim-lanes, etc.
• Appropriate use of UML notation
Task 8: User interface design
Create mock-up interface for administrators of the library. Your interface should have separate pages to perform following tasks (each task may need several pages to accomplish a task):
• Login, logout, forgotten password and registration pages for library admin.
• Library loans' interface: This interface at least should able to show loans, overdue loans, history of past loans and search loans with different criteria.
• Library member's interface: This interface should include different pages for adding removing, suspending members of the library. It should also have the page for searching member's information (registered information and loan history).
• Library borrowable items interface: Library borrowable items fall into different categories including books, audio/videos material, and facility booking (e.g. room, computer). Each borrowable type item should have pages for adding, removing, and searching borrowable items.
Task 9: Test case generation
Design a set of test cases based on the activity diagram that you design in Task 7. Your test cases are aimed at checking validity of user input and common vulnerabilities of your system. Your test casts should follow the format of the below table.
Number Test name Description Scenario Precondition Input Expected output
|
Number
|
Test name
|
Description
|
Scenario
|
Precondition
|
Input
|
Expected output
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Appendix: Template for use case textual description
|
Name
|
This must have an identical name as one of the use cases in the use case diagram.
|
|
|
(it is an expanded description of it)
|
|
Version
|
Identifier to distinguish between versions of one use case.
|
|
Goal
|
A one-sentence summary of the use cases existence.
|
|
Summary
|
A short paragraph describing the process that is followed.
|
|
Actors
|
List the primary actor (the person who initiate the use case) and the secondary actors (anyone else who is involved in the use case). These should be a job title, not individual's name. Be careful to distinguish between data and actors - e.g. in a childcare system, a child's data may be used, but it does not make the child an actor.
|
|
Pre-conditions
|
A condition that must be true before the use case can even start. Write as a predicate; that is a statement that is either true or false. E.g., for Withdraw Cash a precondition is "The person is a customer of the bank." A pre-condition is not something that is checked within a basic course of events (e.g. "there is enough money in the account") - it is a condition that must be true BEFORE the basic course events are event commenced.
|
|
Triggers
|
The event that causes the use case to active. For Withdraw Cash the trigger is "The person enters their car and PIN and selects Withdraw Cash"
|
|
Basic course of
Events
|
A numbered sequence of steps taken to achieve the goal. It should be possible to achieve this goal by only following these steps, without having to follow any of the alternative paths. This list may also refer to other use cases (representing the "includes" relationship discussed earlier), or it may specify extension points (where other use cases can take over).
|
|
Alternative Paths
|
Another way to achieve the same goal. This is also where failure paths are considered (e.g. insufficient cash for a withdrawal).
|
|
Post-Conditions
|
The state of the system after the goal has been achieved. For example, if the customer successfully withdraws cash, their bank balance should be lower by the withdrawn amount. There may be multiple postconditions if multiple outcomes are possible.
|
|
Business Rules
|
Any conditions that should be absorbed/ maintained that is specified by either the business or an external entity. E.g., a childcare system may only enrol children where they have immunized ore over a certain age.
|
|
|
As numerous as the section above are, there may be some extra information that you need to record. This section is the dumping ground for anything you think is relevant to the use case but does not fit into any other categories.
|
|
Notes
|
|
|
Do not go crazy here - do ensure it relates to this particular use case.
|