LIBRARY MANAGEMENT SYSTEM

Operations in Library Management System:

check out a book;

return a book;
add a book to library;
remove book from library;
get list of books by author or subjectarea;
get list of books checked out byparticular borrower;

All books must either be checked out or available for check out.
No book may be simultaneously checked out and available.
There is an upper limit to number of books that may be checked out.
The aims and objectives are as follows:
Online book issue
Request column for librarian for providing new books
A separate column for digital library
Student login page where student can find books issued by him/her and date of return.
A search column to search availability of books
A teacher login page where teacher can add any events being organized in the college
and important suggestions regarding books.
Online notice board about the workshop

Use a CRUD Diagram to:

group data entities into subject databases,

group business functions or processes into business areas,

identify areas that should be examined for problems, such as:

data entities not created or used by any business function or process,

business functions or processes not accessing any data entities,


data entities that are created by more than one business function or
process.

Method

STEPS TO CONSTRUCT A CRUD DIAGRAM

Construct a two-dimensional table, with one row for each data entity and
one column for each business function or process.

Use data entities identified on an Entity-Relationship Diagram and business

functions or processes identified on a Function Chart.

At the intersection of each data entity and process, indicate the

relationship using the following codes:

C - Creates,

R - Reads,

U - Updates,

D - Deletes.

Using the CRUD Matrix

A CRUD matrix is developed by listing the classes from the class diagram (or the
entities if entity relationship modelling is being used) along the side of the matrix,
and the use cases from the use case diagram along the top. Then for each use case
we establish which classes will be affected and in what way, completing the
relevant intersections between use cases and classes with a combination of
C(reate), R(ead), U(pdate) and D(elete), depending on whether the use case needs
to create, read, update or delete one or more instances of the class.
An example of a CRUD matrix for a simple library system is shown below:

The CRUD matrix can be used for a wide range of purposes, including the following.

Case Study1:-Library Management System

3

Problem Statement:
The case study titled Library Management System is library management software for the
purpose of monitoring and controlling the transactions in a library. This case study on the library
management system gives us the complete information about the library and the daily
transactions done in a Library. We need to maintain the record of new s and retrieve the details of
books available in the library which mainly focuses on basic operations in a library like adding
new member, new books, and up new information, searching books and members and facility to
borrow and return books. It features a familiar and well thought-out, an attractive user interface,
combined with strong searching, insertion and reporting capabilities. The report generation
facility of library system helps to get a good idea of which are ths borrowed by the members,
makes users possible to generate hard copy.
The following are the brief description on the functions achieved through this case study:
End-Users:
Librarian: To maintain and update the records and also to cater the needs of the users.
Reader: Need books to read and also places various requests to the librarian.
Vendor: To provide and meet the requirement of the prescribed books.

Class Diagram
Classes are the "blueprints" for objects. A class wraps attributes (data) and behaviors
(methods or functions) into a single distinct entity.
A Class diagram gives an overview of a system by showing its classes and the relationships
among them. Class diagrams are static -- they display what interacts but not what happens when they
do interact.
Modeling steps for Class Diagrams
1. Identity the things that are interacting with class diagram.
2. Set the attributes and operations.
3. Set the responsibilities.
4. Identify the generalization and specification classes.
5. Set the relationship among all the things.
6. Adorn with tagged values, constraints and notes.

Classes identified:
Library
Librarian
Books Database
User

Vendor

(OR)

Object Diagrams
Objects are instances of classes.
Object diagrams show instances instead of classes. They are useful for explaining small
pieces with complicated relationships, especially recursive relationships.
Modeling steps for Object Diagrams
1. Identify the mechanisms which you would like to model.
2. Identify the classes, use cases, interface, subsystem which are collaborated with
mechanisms.
3. Identify the relationship among all objects.
4. Walk through the scenario until to reach the certain point and identify the objects at that
point.
5. Render all these classes as objects in diagram.
6. Specify the links among all these objects.
7. Set the values of attributes and states of objects.
6

Use-case Diagram
Use case diagrams describe what a system does from the standpoint of an external observer.
The emphasis is on what a system does rather than how.
Actors are stick figures. Use cases are ovals. Communications are lines that link
actors to use cases.
A use case diagram is a collection of actors, use cases, and their
communications. We've put Make Appointment as part of a diagram with four
actors and four use cases. Notice that a single use case can have multiple
actors.
Modeling steps for Use case Diagram:
1. Draw the lines around the system and actors lie outside the system.
2. Identify the actors which are interacting with the system.
3. Separate the generalized and specialized actors.
4. Identify the functionality the way of interacting actors with system and specify
the behavior of actor.
5. Functionality or behavior of actors is considered as use cases.
6. Specify the generalized and specialized use cases.
7. Se the relationship among the use cases and in between actor and use cases.
8. Adorn with constraints and notes.
9. If necessary, use collaborations to realize use cases.

Use Case Specification:

The next step after finalizing use case diagrams is to document the business functionality into clear-cut
and detailed use case specification. Because use cases are used as input to the other project phases
such as design, development, and testing, we need to ensure that the visual depiction of the business
requirements is translated into clear and well-defined requirements in the form of use case specifications.
Elaborate use case specifications are used as input for design and development and for writing test cases
(unit, system, and regression tests, as the case may be).
A use case specification document should enable us to easily document the business flow. The UML
semantics state that A use case can be described in plain text, using operations, in activity diagrams, by
a state-machine, or by other behavior description techniques, such as pre- and post conditions. The
interaction between the use case and the actors can also be presented in collaboration diagrams.
Use Case Template
The template shown in table 3.1 has twelve fields. The left-hand column shows the fields and whether
they are optional. The right hand column briefly describes the purpose of the field.
Table 3.1 Use Case Template

Use Case ID

This should be coded to identify the owning team and the level of the use case.

Use Case Type

Essential, Concrete, Abstract

Use Case Name

Short descriptive phrase

Basic Course

This is a complete description of the use. It consists of following subsections:

Actors: Which actor from the actor model initiates this course of the use case?
Preconditions: Requirements on the state of the the system prior to this use being
valid.
Description: Numbered flow of events: 1. The user initiates an action by .... 2. The
system responds by ..... 3. ........, so on.
Relevant requirements: Reference to other relevant requirements documents.
Post-conditions: This describes the state of the system following the successful
completion of this use. Affects on other systems and actors may also be described.

Alternative
Courses
(Optional)

Structured like the basic course.

Rationale
(Optional)

Explanation of why this requirement is present in the system. This field is typically
only used for essential use cases

Extensions
(Optional)

This section presents variations on this use case that specializes it. It presents
those use cases that have an extends relation with the current use case.

Exceptions
(Optional)

This section describes all error conditions that can arise in the use case.

Concurrent Uses
(Optional)

This use can occur concurrently with the uses listed in this section.

Related Use
Cases

Frequency: How often will this use of the system occur? This field is combined with
the criticality field to determine the number of tests that will be used to test the
functionality. It may also be used in certain design decisions.
Criticality: How necessary is this use to the successful functioning of the program
from user's perspective. This field is used to assist in determining the extent to which
the use will be tested.
Risk: The project risk associated with providing this use. This is used in project
planning. Often riskier uses will be implemented early to provide sufficient recovery
time.

Modification
History

Owner:
Initiation Date:
Date last modified:

Actors vs Use Cases:

Librarian
Issue a book
8

Update and maintain records

Request the vendor for a book
Track complaints
User
Register
Login
Search a book
Request for isse
View history
Request to the Librarian
Unregister
Books Database
Update records
Show books status
Vendors
Provide books to the library
Payment acknowledgement

Sequence Diagram
A sequence diagram is an interaction diagram that details how operations are carried out -what messages are sent and when. Sequence diagrams are organized according to time. The time
9

progresses as you go down the page. The objects involved in the operation are listed from left to right
according to when they take part in the message sequence.
Each vertical dotted line is a lifeline, representing the time that an object
exists. Each arrow is a message call. An arrow goes from the sender to the top of
the activation bar of the message on the receiver's lifeline. The activation bar
represents the duration of execution of the message.
Moddeling steps for Sequence Diagrams:
1. Set the context for the interactions, system, subsystem, classes, object or use cases.
2. Set the stages for the interactions by identifying objects which are placed as actions in
interaction diagrams.
3. Lay them out along the X-axis by placing the important object at the left side and others in
the next subsequent.
4. Set the lifelines for each and every object by sending create and destroy messages.
5. Start the message which is initiating interactions and place all other messages in the
increasing order of items.
6. Specify the time and space constraints.
7. Set the pre and post conditioned.

Sequence diagram for searching a book and issuing it as per the request by the user from the
librarian:

Sequence diagram for returning a book

10

Sequence diagram for returning a book

11

Collaboration
Diagram
Collaboration diagrams are also interaction diagrams. They convey the same information as
sequence diagrams, but they focus on object roles instead of the times that messages are sent. In a
sequence diagram, object roles are the vertices and messages are the connecting links.
The object-role rectangles are labeled with either class or object names (or both). Class
names are preceded by colons ( : ).
Each message in a collaboration diagram has a sequence number. The toplevel message is numbered 1. Messages at the same level (sent during the same
call) have the same decimal prefix but suffixes of 1, 2, etc. according to when
they occur.
Modeling steps for Collaboration Diagrams:
1. Set the context for interaction, whether it is system, subsystem, operation or class or one
scenario of use case or collaboration.
2. Identify the objects that play a role in the interaction. Lay them as vertices in graph,
placing important objects in centre and neighboring objects to outside.
3. Set the initial properties of each of these objects. If the attributes or tagged values of an
object changes in significant ways over the interaction, place a duplicate object, update.
with these new values and connect them by a message stereotyped as become or copy.
4. Specify the links among these objects. Lay the association links first represent structural
connection. Lay out other links and adorn with stereotypes.
5. Starting with the message that initiates this interaction, attach each subsequent message to
appropriate link, setting sequence number as appropriate.
6. Adorn each message with time and space constraints if needed.
12

7. Attach pre & post conditions to specify flow of control formally.

Collaboration Diagram for searching a book and issuing it as per the request by the user from the
librarian:

13

Collaboration Diagram for issuing a Book

Collaboration Diagram for Returning a Book

14

Activity Diagram
An activity diagram is essentially a fancy flowchart. Activity diagrams and statechart
diagrams are related. While a statechart diagram focuses attention on an object undergoing a process
(or on a process as an object), an activity diagram focuses on the flow of activities involved in a
single process. The activity diagram shows the how those activities depend on one another.
Activity diagrams can be divided into object swimlanes that determine which object is
responsible for which activity. A single transition comes out of each activity, connecting it to the
next activity.
A transition may branch into two or more mutually exclusive transitions. Guard
expressions (inside [ ]) label the transitions coming out of a branch. A branch and its subsequent
merge marking the end of the branch appear in the diagram as hollow diamonds.
A transition may fork into two or more parallel activities. The fork and the
subsequent join of the threads coming out of the fork appear in the diagram as
solid bars.
Modeling steps for Activity Diagrams
1. Select the object that have high level responsibilities.
2. These objects may be real or abstract. In either case, create a swim lane for each important
object.
3. Identify the precondition of initial state and post conditions of final state.
4. Beginning at initial state, specify the activities and actions and render them as activity
states or action states.
5. For complicated actions, or for a set of actions that appear multiple times, collapse these
states and provide separate activity diagram.
6. Render the transitions that connect these activities and action states.
7. Start with sequential flows, consider branching, fork and joining.
8. Adorn with notes tagged values and so on.

Activities:
User Login and Authentication
Search book operation for Reader
Acknowledge and Issue books to the users by the Librarian
Provide books requested by the Librarian from the Vendor
Bill payment from the Librarian to the Vendor
Status of the books updated in the Books Database

15

Activity Diagram for Issue Book in Library

Activity Diagram for Issue Book in Library

16

Activity diagram for return a book in linrary :17

State Chart Diagram

Objects have behaviors and state. The state of an object depends on its current activity or
condition. A statechart diagram shows the possible states of the object and the transitions that cause
a change in state.
States are rounded rectangles. Transitions are arrows from one state to another. Events or
conditions that trigger transitions are written beside the arrows.
The initial state (black circle) is a dummy to start the action. Final states are also
dummy states that terminate the action.
Modeling steps for State chart Diagram:

18

1. Choose the context for state machine, whether it is a class, a use case, or the system as a
whole.
2. Choose the initial & final states of the objects.
3. Decide on the stable states of the object by considering the conditions in which the object
may exist for some identifiable period of time. Start with the high level states of the
objects & only then consider its possible sub states.
4. Decide on the meaningful partial ordering of stable states over the lifetime of the object.
5. Decide on the events that may trigger a transition from state to state. Model these events as
triggers to transitions that move from one legal ordering of states to another.
6. Attach actions to these transitions and/or to these states.
7. Consider ways to simplify your machine by using substates, branches, forks, joins and
history states.
8. Check that all states are reachable under some combination of events.
9. Check that no state is a dead from which no combination of events will transition the
object out of that state.
10. Trace through the state machine, either manually

States:
Authentication
Successfully logged on or re-login
Search for a book (user) / request the vendor (librarian) / provide the requested book (vendor)
Receive acknowledgement
Logged off / re-search / new function
Transitions:
Authenticate ---> Logged in
Logged in ---> Search <---> Acknowledgement
Logged in ---> Request Vendor <---> Provide Book <---> Acknowledgement
Logged in ---> Provide Book <---> Acknowledgement
Acknowledgement ---> Logged off

19

State Diagram for Book

State diagram for Librarian

Component Diagram
A component is a code module. Component diagrams are physical analogs of class diagram.
Each component
Modeling steps for Component Diagrams
1. Identify the component libraries and executable files which are interacting with the system.
20

2. Represent this executables and libraries as components.

3. Show the relationships among all the components.
4. Identify the files, tables, documents which are interacting with the system.
5. Represent files, tables, documents as components.
6. Show the existing relationships among them generally dependency.
7. Identify the seams in the model.
8. Identify the interfaces which are interacting with the system.
9. Set attributes and operation signatures for interfaces.
10. Use either import or export relationship in b/w interfaces & components.
11. Identify the source code which is interacting with the system.
12. Set the version of the source code as a constraint to each source code.
13. Represent source code as components.
14. Show the relationships among components.
15. Adorn with nodes, constraints and tag values.

Components:
Register Page (visitor / vendor)
Login Page (user / librarian / vendor)
Search Page (user / librarian / vendor)
Request Vendor Page (librarian)
Request Book Issue Page (user / vendor)
Issue Status Page (librarian)
Make Payment Page (librarian / vendor)
Provide Books Page (librarian)
Logout Page (user / librarian / vendor)

21

Deployment Diagram
Deployment diagrams show the physical configurations of software and hardware.
The physical hardware is made up of nodes.
Modeling steps for Deployment Diagram
1. Identify the processors which represent client & server.
2. Provide the visual cue via stereotype classes.
3. Group all the similar clients into one package.
4. Provide the links among clients & servers.
5. Provide the attributes & operations.
6. Specify the components which are living on nodes.
7. Adorn with nodes & constraints & draw the deployment diagram.

Systems Used:
Local Consoles / Computers for login and search purposes by users, librarian and vendors.
Library LAN Server interconnecting all the systems to the Database.
Internet to provide access to Venodors to supply the requested books by the Librarian
Vendor Server to maintain the records of the requests made by the librarian and books provided
to the library.

22

23