LIBRARY MANEGEMENT

INTRODUCTION
Library management is a sub-discipline of institutional management that focuses on specific
issues faced by libraries and library management professionals. Library management
encompasses normal managerial tasks, as well as intellectual freedom and fundraising
responsibilities. Issues faced in library management frequently overlap with those faced in
managing non-profit organizations.
The basic functions of library management include, but are not limited to: planning and
negotiating the acquisition of materials, Interlibrary Loan (ILL) requests, stacks maintenance,
overseeing fee collection, event planning, fundraising, and human resources.

USECASE DIAGRAM:
A use case diagram in UML helps to show the various ways in which a user could interact with a
system. For a Library Management System, the use case diagram helps visualize the
interactions between users (actors) and the system’s functionalities (use cases). This diagram
provides a clear, simplified way to understand how the system operates and what it offers to its
users

1.Actor:
Actors are external entities that interact with the system. These can include users, other
systems, or hardware devices. In the context of a Use Case Diagram, actors initiate use cases
and receive the outcomes.

2.Use Case
Use cases are like scenes in the play. They represent specific things your system can do.

3.System Boundary
The system boundary is a visual representation of the scope or limits of the system you are
modeling. It defines what is inside the system and what is outside.
.
. CLASS DIAGRAM:
Class diagrams are generally used for conceptual modeling of static view of a software
application, and for modeling translating models into programming code in a detailed manner.
At time of developing or construction software systems, a class diagram is widely used. They
are also used for data modeling. It is used to show classes, relationships among them,
interface, association, etc. Class in a class diagram simply is a blueprint of an object. It simply
describes and explains different type of objects in system, and different types of relationships
that exist between them.

1.Aggregation
Aggregation simply shows a relationship where one thing can exist independently of other
thing. It means to create or compose different abstractions together in defining a class.
Aggregation is represented as a part of relationship in class diagram. In diagram given below,
we can see that aggregation is represented by an edge with a diamond end pointing towards
superclass. The “Library Management System” is superclass that consists of various classes.
These classes are User, Book, and Librarian as shown in diagram. Further, for “Account” class,
“User” is a superclass. All of these, share a relationship and these relationships are known as
aggregate relationships.
2.Multiplicity
Multiplicity means that number of elements of a class is associated with another class. These
relations can be one-to-one, many-to-many, and many-to-one or one-to-many. For denoting one
element we use 1, for zero elements we use 0, and for many elements we use *. We can see in
diagram; many users are associated with many books denoted by * and this represents a many-
to-many type of relationship. One user has only one account that is denoted by 1 and this
represents a one-to-one type of relationship. Many books are associated with one librarian and
this represents many-to-one or one-to-many type of relationship. All these relationships are
shown in diagram.
Classes of Library Management System :
Library Management System class : It manages all operations of Library Management
System. It is central part of organization for which software is being designed.

User Class : It manages all operations of user.

Librarian Class : It manages all operations of Librarian.

Book Class : It manages all operations of books. It is basic building block of system.

Account Class : It manages all operations of account.

Library database Class : It manages all operations of library database.

Staff Class : It manages all operations of staff.

STATE CHART/STATE MACHINE DIAGRAM:

1. Initial state
We use a black filled circle represent the initial state of a System or a Class

2. Transition
We use a solid arrow to represent the transition or change of control from one state to another.
The arrow is labelled with the event which causes the change in state.

3. State
We use a rounded rectangle to represent a state. A state represents the conditions or
circumstances of an object of a class at an instant of time

4. Join
We use a rounded solid rectangular bar to represent a Join notation with incoming arrows from
the joining states and outgoing arrow towards the common goal state. We use the join notation
when two or more states concurrently converge into one on the occurrence of an event or
events

5. Final State
We use a filled circle within a circle notation to represent the final state in a state machine
diagram.

Sequence Diagram:
A Sequence Diagram is a key component of Unified Modeling Language (UML) used to
visualize the interaction between objects in a sequential order. It focuses on how objects
communicate with each other over time, making it an essential tool for modeling dynamic
behavior in a system. Sequence diagrams illustrate object interactions, message flows, and the
sequence of operations, making them valuable for understanding use cases, designing system
architecture, and documenting complex processes.

1. Actors
An actor in a UML diagram represents a type of role where it interacts with the system and its
objects. It is important to note here that an actor is always outside the scope of the system we
aim to model using the UML diagram.
2. Lifelines
A lifeline is a named element which depicts an individual participant in a sequence diagram. So
basically each instance in a sequence diagram is represented by a lifeline. Lifeline elements are
located at the top in a sequence diagram.

3. Messages
Communication between objects is depicted using messages. The messages appear in a
sequential order on the lifeline.We represent messages using arrows.Lifelines and messages
form the core of a sequence diagram.

4.Synchronous messages
A synchronous message waits for a reply before the interaction can move forward. The sender
waits until the receiver has completed the processing of the message. The caller continues only
when it knows that the receiver has processed the previous message i.e. it receives a reply
message.A large number of calls in object oriented programming are synchronous. We use a
solid arrow head to represent a synchronous message.

5.Asynchronous Messages
An asynchronous message does not wait for a reply from the receiver. The interaction moves
forward irrespective of the receiver processing the previous message or not. We use a lined
arrow head to represent an asynchronous message.

6.Create message
We use a Create message to instantiate a new object in the sequence diagram. There are
situations when a particular message call requires the creation of an object. It is represented
with a dotted arrow and create word labelled on it to specify that it is the create Message
symbol.

7.Delete Message
We use a Delete Message to delete an object. When an object is deallocated memory or is
destroyed within the system we use the Delete Message symbol. It destroys the occurrence of
the object in the system.It is represented by an arrow terminating with a x.

8.Self Message
Certain scenarios might arise where the object needs to send a message to itself. Such
messages are called Self Messages and are represented with a U shaped arrow.
9.Reply Message
Reply messages are used to show the message being sent from the receiver to the sender. We
represent a return/reply message using an open arrow head with a dotted line. The interaction
moves forward only when a reply message is sent by the receiver.
Component diagram:
Component-based diagrams are essential tools in software engineering, providing a visual
representation of a system’s structure by showcasing its various components and their
interactions. These diagrams simplify complex systems, making it easier for developers to
design, understand, and communicate the architecture.

1. Component
Represent modular parts of the system that encapsulate functionalities. Components can be
software classes, collections of classes, or subsystems.

2. Interfaces
Specify a set of operations that a component offers or requires, serving as a contract between
the component and its environment.

3. Relationships
Depict the connections and dependencies between components and interfaces.
4.Ports
Represent specific interaction points on the boundary of a component where interfaces are
provided or required.

5. Artifacts
Represent physical files or data that are deployed on nodes.

6. Nodes
Represent physical or virtual execution environments where components are deployed.

Deployment Diagram:
A Deployment Diagram is a type of Structural UML Diagram that shows the physical deployment
of software components on hardware nodes. It illustrates the mapping of software components
onto the physical resources of a system, such as servers, processors, storage devices, and
network infrastructure.

1. Component
A component represents a modular and reusable part of a system, typically implemented as a
software module, class, or package. It encapsulates its behavior and data and can be deployed
independently.

2. Artifact
An artifact represents a physical piece of information or data that is used or produced in the
software development process. It can include source code files, executables, documents,
libraries, configuration files, or any other item.

3. Interface
An interface defines a contract specifying the methods or operations that a component must
implement. It represents a point of interaction between different components or subsystems.

4. Node
A node represents a physical or computational resource, such as a hardware device, server,
workstation, or computing resource, on which software components can be deployed or
executed
5. Communication path
A straight line that represents communication between two device nodes. Dashed lines in
deployment diagrams represents relationships or dependencies between elements, indicating
that one element is related to or dependent on another.
.