Sidhant Mehta Se Final 2.0
Sidhant Mehta Se Final 2.0
Aim: Select and write the problem statement for a real time system of relevance.
Problem Statement – Library Management System
In today's digital era, manual library management systems are proving to be
inefficient and error-prone. Traditional paper-based processes lead to numerous
challenges for both librarians and library members. With the increasing demands
for faster and more accurate services, it's imperative to transition to an automated
library management system.
1. Introduction
This Software Requirements Specification (SRS) document outlines the
requirements and specifications for the Library Management System (LMS). The
purpose of this document is to define the functionalities and features of the LMS in
detail, ensuring a clear understanding of the system's capabilities and constraints.
1.1 Purpose
The Library Management System is designed to automate and streamline library
operations, including cataloguing, circulation, member management, and reporting.
This document serves as a guide for the development, testing, and implementation
of the LMS, catering to the needs of library staff and users.
1.2 Scope
The scope of the Library Management System encompasses features such as book
cataloguing, member registration, book circulation management, fine calculation,
reporting, and administrative functions. The system will provide an intuitive
interface for users to search and access library resources efficiently.
1.4 References
(i) Library Association guidelines: For standards and best practices in library
management.
(ii) IEEE Recommended Practice for Software Requirements Specifications-IEEE
Std 830-1993.
1.5 Overview
2.1.5 Memory Constraints: Ensure the system has at least 64 MB RAM available
for optimal performance.
2.1.6 Operations: This product release will not cover automated housekeeping
aspects of the database. The DBA at the client site (University) will be responsible
for manually deleting old/non-required data and handling database backup and
recovery. However, the system will provide a ‘RESET SYSTEM’ function that,
upon confirmation from the Administrator, will delete all existing information from
the database.
2.1.7 Site Adaptation Requirements: Terminals at the client site should support the
specified hardware and software interfaces mentioned in the previous sections for
seamless operation of the system.
2.4 Constraints
i. Since the DBMS being used is MySQL, which may have limitations in
handling a very large number of records.
ii. Performance tuning features may not be applied to queries due to limitations
of the DBMS, potentially causing the system to become slow with an
increase in the number of records being stored.
iii. Database auditing may not be provided due to limitations of the DBMS.
iv. Users may need to implement a security policy to safeguard library
information from being modified by unauthorized users.
3. Document Approvals
Document approvals in an SRS (Software Requirements Specification) ensure that
the document has been reviewed and endorsed by key stakeholders before
proceeding with the development process.
Project Sponsor: [ ]
Project Manager: [ ]
System Architect: [ ]
Lead Developer: [ ]
Quality Assurance Manager: [ ]
Business Analyst: [ ]
Approval Date: [ ]
The document was approved on: [ ]
Important Observations
All names should be unique making it easier to refer to the items of the
DFD.
Arrows of a flow chart represent the order of events whereas arrows of a
DFD represent flowing data.
No use of different shapes in DFDs.
Defer error conditions and error handling until the end of the analysis.
Level 0
Level 0 is the highest level of DFDs providing an overview of the entire system. It
shows the major processes of data flows and data stores in the system without
providing any details about the internal workings of these processes. It is also
known as a context diagram. It is designed to be an abstraction view, showing the
system as a single bubble with input and output data indicated by
incoming/outgoing arrows.
Practical 5
Aim: To draw the structural view diagram for the system: Class Diagram.
Class Diagram
Class diagrams are a type of UML (Unified Modelling Language) diagram used in
software engineering to visually represent the structure and relationships of classes
within a system i.e. used to construct and visualize object-oriented systems. Class
diagrams provide a high-level overview of a system’s design, helping to
communicate and document the structure of the software. They are a fundamental
tool in object-oriented design and play a crucial role in the software development
lifecycle.
What is a Class
In object-oriented programming (OOP), a class is a blueprint or template for
creating objects. Objects are instances of classes, and each class defines a set of
Purpose
This is the only UML that can appropriately depict various aspects of the
OOPs concept.
Proper design and analysis of applications can be faster and efficient.
It is the base for deployment and component diagram. It incorporates
forward and reverse engineering.
Benefits
Class diagrams represent the system’s classes, attributes, methods, and
relationships, providing a clear view of its architecture.
They show various relationships between classes, such as associations and
inheritance, helping stakeholders understand component connectivity.
Class diagrams serve as a visual tool for communication among team
members and stakeholders, bridging gaps between technical and non-
technical audiences.
They guide developers in coding by illustrating the design, ensuring
consistency between the design and actual implementation.
Many development tools allow for code generation from class diagrams,
reducing manual errors and saving time.
Activity Diagram
Activity diagram is another important diagram in UML to describe the dynamic
aspects of the system. Activity diagram is basically a flowchart to represent the
flow from one activity to another activity. The activity can be described as an
operation of the system. The control flow is drawn from one operation to another.
This flow can be sequential, branched, or concurrent. Activity diagrams deal with
all type of flow control by using different elements such as fork, join, etc.
Sequence Diagram
A Sequence Diagram is a key component of Unified Modelling 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 modelling dynamic behaviour 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.
Purpose
Component diagram is a special kind of diagram in UML. The purpose is also
different from all other diagrams discussed so far. It does not describe the
functionality of the system but it describes the components used to make those
functionalities. Thus, from that point of view, component diagrams are used to
visualize the physical components in a system. These components are libraries,
packages, files, etc. Component diagrams can also be described as a static
implementation view of a system. Static implementation represents the
organization of the components at a particular moment. A single component
diagram cannot represent the entire system but a collection of diagrams is used to
represent the whole. This can be summarized as:
Visualize the components of a system.
Construct executables by using forward and reverse engineering.
Describe the organization and relationships of the components.
Benefits
Though component diagrams may seem complex at first glance, they are
invaluable when it comes to building your system. Component diagrams can help
your team:
Imagine the system’s physical structure.
Pay attention to the system’s components and how they relate.
Emphasize the service behavior as it relates to the interface.
Benefits
Deployment diagrams provide a clear picture of how software parts are
placed on hardware, making it easy to understand.
They help teams talk about how to set up the system, making it easier to
discuss and decide on deployment strategies.
Deployment diagrams assist in planning and managing the deployment
process, ensuring resources are used efficiently and system requirements are
met.
They serve as useful documentation for understanding how the system is set
up, helping with maintenance and future changes.
Challenges
Deployment diagrams can get complicated and especially in big systems
with lots of parts. Managing this complexity is tough.
Making and understanding deployment diagrams needs knowledge of UML
symbols, which not everyone might have.
Updating deployment diagrams when the system changes take time and
effort.
Deployment diagrams might not show how things change over time or in
real-life use.
Making deployment diagrams often needs lots of people to work together,
which can be tricky.
Halstead Metrics
Halstead’s Software Metrics, developed by Maurice Halstead in 1977, are a set of
measures used to quantify various aspects of software programs. According to
Halstead’s, “A computer program is an implementation of an algorithm considered
to be a collection of tokens which can be classified as either operators or operand”.
This means that the program consists of various symbols and data elements that are
either performing actions (operators) or upon which actions are performed
(operands). This distinction helps in understanding and analysing the structure and
behaviour of the program.
Token Count
In Halstead’s Software metrics, a computer program is defined as a collection of
tokens that can be described as operators or operands. These tokens are used to
analyse the complexity and volume of a program. Operators are symbols that
represent actions, while operands are the entities on which the operators act. All
software science metrics can be specified using these basic symbols. These
symbols are referred to as tokens. By counting and analysing these tokens,
Halstead’s metrics provide insights into the complexity, effort, and quality of
software code. In Halstead’s Software Metrics:
n1 = number of distinct operators
n2 = number of distinct operands
N1 = Total number of occurrences of operators
N2 = Total number of occurrences of operands
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
typedef struct {
char title[TITLE_LENGTH];
char author[AUTHOR_LENGTH];
int id;
} Book;
Book library[MAX_BOOKS];
int bookCount = 0;
void addBook() {
if (bookCount >= MAX_BOOKS) {
printf("Library is full! Cannot add more books.\n");
return;
}
Book newBook;
printf("Enter book ID: ");
scanf("%d", &newBook.id);
getchar(); // Consume newline character
printf("Enter book title: ");
fgets(newBook.title, TITLE_LENGTH, stdin);
newBook.title[strcspn(newBook.title, "\n")] = 0; // Remove newline character
printf("Enter book author: ");
fgets(newBook.author, AUTHOR_LENGTH, stdin);
newBook.author[strcspn(newBook.author, "\n")] = 0; // Remove newline
character
library[bookCount++] = newBook;
void displayBooks() {
if (bookCount == 0) {
printf("No books in the library.\n");
return;
}
printf("\nLibrary Books:\n");
for (int i = 0; i < bookCount; i++) {
printf("ID: %d, Title: %s, Author: %s\n", library[i].id, library[i].title,
library[i].author);
}
}
void searchBook() {
char title[TITLE_LENGTH];
printf("Enter the title of the book to search: ");
getchar(); // Consume newline character
fgets(title, TITLE_LENGTH, stdin);
title[strcspn(title, "\n")] = 0; // Remove newline character
int found = 0;
for (int i = 0; i < bookCount; i++) {
if (strcasecmp(library[i].title, title) == 0) {
printf("Book found! ID: %d, Title: %s, Author: %s\n", library[i].id,
library[i].title, library[i].author);
found = 1;
break;
}
}
if (!found) {
printf("Book not found.\n");
}
}
void menu() {
printf("\nLibrary Management System\n");
switch (choice) {
case 1:
addBook();
break;
case 2:
displayBooks();
break;
case 3:
searchBook();
break;
case 4:
printf("Exiting the program.\n");
exit(0);
default:
printf("Invalid choice! Please try again.\n");
}
}
return 0;
}