NIT2213 Software Engineering: Library System Diagram & Use Case Report

This document presents a comprehensive analysis of a university library system, detailing its functional requirements through use case descriptions and diagrams. It identifies key actors such as patrons, students (graduate and undergraduate), and administrators, illustrating their interactions within the system. The analysis includes a use case index, a use case diagram, a class diagram, a sequence diagram for the checkout process, and a state machine diagram. Assumptions regarding student categories, patron responsibilities, and book associations are outlined to ensure a well-defined system. The document provides a structured approach to understanding and designing a functional library information system, with a focus on efficient book reservation and checkout processes. Desklib offers a wealth of similar solved assignments and past papers for students seeking academic support.

University Library system
Name
Institution
Professor
Course
Date

Task 1: Use case description for checking out books
Library information system involves interaction of many entities that should
communicate effectively to satisfy systems’ functional requirements. Use cases in library
information system would be used to describe functional requirements to be captured during
system design (Garcia, Carretero, Perez, Carballeira & Filgueira, 2005). Before a use case
description can be deduced, it is important to establish all required entities. According to
Kantorowitz & Lyakas (2005), entities or actors are used to describe working of the entire
system once implemented. The University library case study would be analyzed to be able to
understand all proposed system requirements. Some of the use cases would be able to capture
one entity which can be extended into more than one scenario. In a use case, extension occurs if
one entity performs more than one functions but in different manner. In this case, check out use
case can be deduced from library loans module. From library loans, there are several actors
which should interact in order to make book reserve and check out possible. The entire process
would involve entities such as patrons, library information system, students and administrator. In
order to analyze the entire check out process, use case index would be very important.

Table 1: Use case index description
Case Id Use Case Name Actor
1
Reservation Patron
Faculty
Graduate
Undergraduate
3 Approve Administrator
4
Registration Student Undergraduate
Graduate
Interaction between these entities and the system make it possible to design responsive
and functional library information system. In this case, patron is the main actor which takes
center of the discussion. Check out process is mainly facilitated by patron who keeps all required
books on reserve then takes them to administrator for check out. With three different tiers of
patrons, check out remains to be one of the major process that builds up an entire library system.
The use case loan can be extended in to three possible scenarios which are used to illustrate the
entire functionality of the system. It is important to note that three tier patrons have different
privileges depending on the group of students they serve. In this case, there will be only one
patron case which extends all other three functionalities. All patron details including; Names,
residential address, office address and Telephone number would be captured in information
system database. Patrons’ details would be captured depending on the category of the patron.
Different types of information would be captured in order to facilitate smooth tracking of loaning
out books. Patrons are important entities in the system because all borrowing by students are
done through them. Once they collect requests from students, they present all requests to
administrator with relevant books for reserve and check out. In the design of the system
regarding patrons’ use of the system, some assumptions would be; each student category would

be associated with a patron. Such association would be very important to help administrator have
an exact match of requests from student to reserves made by patrons. The other assumption
would be that faculty patrons’ keeps check of the reserves placed by patrons on behalf of
students.
Students is another group of entities that interacts with system only during registration
processes. Despite it being not a dominant actor in the system, student is a fundamental entity
that initiate the entire process in the system. Student should start by registering with accurate
details into library system. Once all details are captured and validated, student can place a
booking request of the book with all relevant details of the book. Relevant patron would collect
all bookings from students and present them to library administrator for reservations. Once all
reservations are done patrons would keep books for various students to collect at their preferred
time. This entity can be categorized into either graduate student or undergraduate student
depending on the role assigned to each patron. Over a given period of time, one patron would be
associated with many different types of loans. The number of loans would depend on the type of
borrowing as well as frequency of borrowing from students assigned to a particular patron.
Similarly, a single loan can be associated one patron which in turn is linked to many physical
books with different titles. In order to design system that meets required functionalities, use case
student would extend to both graduate and undergraduate. On students’ case, some of the
assumptions are; once reserves are place and check out done, collection should be made within
specific time-frame.
The final group of entity in university library system is the system administrator. The
administrator performs all the functions that require approval in the library. Once patrons receive
requests from students and collections for reservation is made, all reservations must be presented

to library administrator to check the books out. To help administrator keep track of the entire
check out process, the following check out details are maintained; reservation date, priority
associated with reservation and fulfillment date. All these details should be associated with
specific loan and patron. It is at this check out stage where all information all information is
consolidate and linkage done appropriately in order to keep entire process efficient and effective.
Since it would be quite difficult to associate patrons with books without students being part of
the process, assumptions are; each book is also associated with a student. On the same note, all
processes from registration of student to library system, reservation requests and check out are
on the same module. The only difference should be on privileges on how executes which
function. Student places a reservation requests which is sent to patron, patron checks on
availability of the book requested and replies with appropriate recommendations to the student. If
request is approved, reservation is made and approval has to be sent to administrator for check
out. System administrator awaits for physical presentation of books by patron for check out
approval.

Task 2: Use case diagram for the case study
Figure 1: Library use case diagram

Task 3: Class diagram for the whole case study
Figure 2: Library system class diagram

Task 4: Check out sequence diagram
Figure 3: Library system sequence diagram

Task 5: State machine diagram
Figure 4: Library state machine diagram
References
Garcia, J. D., Carretero, J., Perez, J. M., Carballeira, F. G., & Filgueira, R. (2005). Specifying use
case behavior with interaction models. Journal of Object Technology, 4(9), 143-159.
Kantorowitz, E., & Lyakas, A. (2005). Use-case components for interactive information systems.
Science of Computer Programming, 56(1-2), 5-21.