0% found this document useful (0 votes)
21 views42 pages

Sidhant Mehta Se Final 2.0

The document outlines the development of a Library Management System (LMS) to replace inefficient manual processes with an automated solution. It details the challenges of the existing system, proposed features of the LMS, and the Software Requirements Specification (SRS) that defines the system's functionalities, user interfaces, and performance requirements. The LMS aims to streamline library operations, improve user accessibility, and enhance overall service quality for library members.

Uploaded by

Sidhant Mehta
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
21 views42 pages

Sidhant Mehta Se Final 2.0

The document outlines the development of a Library Management System (LMS) to replace inefficient manual processes with an automated solution. It details the challenges of the existing system, proposed features of the LMS, and the Software Requirements Specification (SRS) that defines the system's functionalities, user interfaces, and performance requirements. The LMS aims to streamline library operations, improve user accessibility, and enhance overall service quality for library members.

Uploaded by

Sidhant Mehta
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 42

Practical 1

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.

Existing Manual System Challenges:


 Tedious Book Tracking: The manual system requires librarians to physically
track each book's availability, leading to time-consuming searches and
potential errors in book status.
 Limited Accessibility: Manual records restrict access to library services,
making it challenging for members to check book availability or reserve
books remotely.
 Inaccurate Record Keeping: Paper-based records are prone to human error,
resulting in discrepancies in book issue and return dates, leading to
confusion and inefficiency.
 Delayed Reporting: Generating reports on book availability, overdue books,
and penalties involve manual data compilation, leading to delays and
inaccuracies in reporting.
 Manual Penalty Calculation: Calculating penalties for overdue books is
labour-intensive and prone to miscalculations, leading to inconsistencies in
penalty charges.

Sidhant Mehta [Roll No: 50314202024] Page 1


Proposed Automated System Features and Use Cases:
The proposed automated library management system aims to address the
challenges of the manual system by providing the following features and use cases:
 Login: Librarians and members can securely log in to the system using
unique credentials.
 Add \ Update \ Delete Book: Librarians can easily add new books to the
system database, including details such as title, author, genre, and ISBN.
They can also update and delete books from the books database.
 Request Book: Librarians can efficiently issue books to members by
scanning book barcodes and member IDs, updating the system's real-time
availability status.
 Return Book: Members can easily return books using self-service kiosks or
scanning book barcodes, updating the system's inventory and member
accounts.
 Pay Fine/Penalty: The system automatically calculates and applies penalties
for overdue books based on predefined rules, ensuring accuracy and
consistency.
 Reserve Book: Students can reserve a book for themselves for a small span
of time. This makes sure that the reserved book is available for borrowing
later.

By implementing an automated library management system with these features and


use cases, libraries can streamline operations, improve accessibility, enhance
accuracy, and provide better services to their users.

Sidhant Mehta [Roll No: 50314202024] Page 2


Practical 2
Aim: Analyse the requirement for a system and develop the Software
Requirement Specification (SRS) for the suggested 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.3 Definitions, Acronyms, and Abbreviations


Throughout this document, the following terms and abbreviations are used:
 LMS: Library Management System
 ISBN: International Standard Book Number
 RFID: Radio Frequency Identification
 API: Application Programming Interface
 SQL: Structured Query Language

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

Sidhant Mehta [Roll No: 50314202024] Page 3


The subsequent sections of this SRS document provide detailed information about
the system requirements, interfaces, functionalities, and performance
considerations of the Library Management System.

2.1 Product Perspective


The application will be a windows-based, self-contained, and independent software
product. Front End Client Application (with data entry/update/delete view and
importing facility) Backend Database.

2.1.1 User Interfaces


The application will have a user-friendly and menu-based interface. Following
screens will be provided:
i. A Login screen for entering the username, password, and role
(Administrator, Librarian, Student) will be provided. Access to different
screens will be based upon the role of the user.
ii. There will be a screen for searching and displaying information regarding
available books, including title, author, publication, edition, and availability
status.
iii. There will be a screen for capturing and displaying information regarding
library members, including students and faculty, enrolled in the system.
iv. There will be a screen for capturing and displaying information regarding
books borrowed by each library member, including due dates and return
status.
v. There will be a screen for managing the library inventory, including adding
new books, updating existing information, and removing outdated items.
This Library Management System aims to streamline library operations, improve
access to resources, and enhance the overall user experience for students, faculty,
and staff of the BCA program.

2.1.2 Hardware Interfaces


i. Screen resolution of at least 800 x 600 is required for proper and complete
viewing of screens. Higher resolution would not be a problem.
ii. Support for printer (dot-matrix/Deskjet/inkjet etc.-any will do) – that is,
appropriate drivers are installed and printer connected. Printer will be
required for printing reports and member lists.
iii. Standalone system or network-based – not a concern, as it will be possible to
run the application on any of these.

2.1.3 Software Interfaces

Sidhant Mehta [Roll No: 50314202024] Page 4


i. Any windows-based operating system (Windows 7/8/10) – compatible with
most modern Windows operating systems.
ii. MySQL as the database management system (DBMS) – for database
management. Future releases of the application will aim at compatibility
with other DBMS options such as PostgreSQL or MongoDB.
iii. Jasper Reports or BIRT for generating and viewing reports – providing
flexibility in report generation.
iv. Java or Python for coding/developing the software – ensuring cross-platform
compatibility and ease of development.
Software mentioned in points (iii) and (iv) above will be required only for the
development of the application. The final application will be packaged as an
independent setup program that will be delivered to the client (University in this
case).

2.1.4 Communications Interfaces: None required.


At least 64 MB RAM and 2 GB space on the hard disk will be required for running
the application.

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.2 Product Functions


The system will allow access only to authorized users with specific roles
(Administrator, Librarian, Student). Depending on the user’s role, they will be able
to access specific modules of the system. A summary of the major functions that
the software will perform:
i. A Login facility for enabling only authorized access to the system.

Sidhant Mehta [Roll No: 50314202024] Page 5


ii. User (with role Librarian) will be able to add/modify/delete information
about different books in the library, including title, author, publication,
edition, and availability status.
iii. User (with role Librarian) will be able to manage the library inventory,
including adding new books, updating existing information, and removing
outdated items.
iv. User (with role Librarian) will be able to manage library memberships,
including adding new members, updating member information, and
removing inactive members.
v. User (with role Student) will be able to search for available books, borrow
books, renew borrowed books, and view their borrowing history.
vi. User (with role Librarian) will be able to generate printable reports, such as
books borrowed report, overdue books report, most popular books report,
and member list report.
vii. User (with role Administrator) will be able to ‘Reset’ the system – leading to
the deletion of all existing information from the backend database.
viii. User (with role Administrator) will be able to create/modify/delete
new/existing user accounts.

2.3 User Characteristics


 Educational level: At least graduate level should be comfortable with the
English language.
 Experience: Should be familiar with using computers and basic software
applications.
 Technical expertise: Should have a basic understanding of library operations
and procedures.

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.

2.5 Assumptions and Dependencies


i. The number of books in the library does not change frequently.

Sidhant Mehta [Roll No: 50314202024] Page 6


ii. Library operations and procedures remain consistent.
iii. The number of library members does not change significantly.

2.6 Apportioning of Requirements

2.6.1External Interface Requirements


In the context of a Library Management System (LMS), external interfaces refer to
the interactions between the LMS and external entities such as users, other
systems, or hardware devices. Here are the external interface requirements for a
Library Management System:
1. User Interface (UI)
2. Integration Interfaces
3. Hardware Interfaces
4. Authentication Interface
5. Reporting Interfaces
6. Payment Interfaces
7. External Device Interfaces

2.6.2 System Features


In a Library Management System (LMS), various features are essential for efficient
library operations, user engagement, and resource management. Here are some key
system features typically found in LMS:
 Catalogue Management: Comprehensive cataloguing capabilities to organize
and manage library collections. Support for adding, editing, and deleting
bibliographic records. Integration with bibliographic databases for
automated cataloguing and metadata enrichment.
 User Management: User registration and authentication for library patrons
and staff members. User profiles to store personal information, borrowing
history, and preferences. Role-based access control to manage permissions
for librarians, administrators, and patrons.
 Search and Discovery: Advanced search functionalities to help users find
library materials efficiently. Keyword, title, author, subject, and advanced
search options. Faceted search filters to narrow down search results based on
criteria such as format, language, and publication year.
 Notifications and Alerts: Automated notifications for due date reminders,
overdue notices, hold pickup alerts, and system updates. Customizable
communication channels, including email, SMS, and in-app notifications.

Sidhant Mehta [Roll No: 50314202024] Page 7


 Administration and Configuration: Administrative dashboard for system
configuration, customization, and management. Tools for batch processing,
data import/export, and system maintenance tasks.
 Security and Data Privacy: Role-based access control (RBAC) to enforce
data security and privacy. Encryption of sensitive data, secure authentication
mechanisms, and audit trails for user actions. Compliance with data
protection regulations (e.g., GDPR, CCPA) and industry standards.
These features collectively contribute to the functionality, usability, and
effectiveness of a Library Management System, supporting diverse library
operations and enhancing the user experience for patrons and staff.

2.6.3 Performance Requirements


Performance requirements in a Library Management System (LMS) specify the
expected performance characteristics and constraints that the system must adhere
to. These requirements ensure that the system functions efficiently, provides timely
responses, and meets user expectations. Here is some performance requirements
typically considered in an LMS:
 Response Time: Define maximum response times for key system functions
such as searching the catalogue, checking out books, and processing user
requests. Example: "95% of searches should return results within 2
seconds."
 Transaction Throughput: Specify the number of transactions or operations
the system should handle within a given time period. Example: "The system
should support a minimum of 100 book checkouts per hour during peak
usage."
 Concurrent User Support: Determine the maximum number of simultaneous
users the system can accommodate without degradation in performance.
Example: "The LMS should support at least 200 concurrent users during
peak hours."
 System Availability: Define the expected uptime and availability of the
system to ensure it is accessible to users when needed. Example: "The LMS
should be available 99.9% of the time, with scheduled maintenance windows
communicated in advance."
 Data Retrieval Speed: Specify the time required to retrieve information from
the database, including catalogue records, user data, and transaction history.
Example: "Data retrieval for catalogue search results should have an average
latency of less than 500 milliseconds."
 Batch Processing Time: Define the maximum time allowed for batch
processes such as data imports, updates, or backups. Example: "Batch

Sidhant Mehta [Roll No: 50314202024] Page 8


processing tasks should be completed within 4 hours, with minimal impact
on system performance."
 System Scalability: Specify how the system should scale to accommodate
increasing user loads or library resources. Example: "The LMS architecture
should be scalable to support a 50% increase in users or library items within
a year."
 Indexing and Search Performance: Define performance requirements for
indexing new catalogue records and searching the catalogue to ensure timely
retrieval of relevant results. Example: "Catalogue indexing should be
completed within 24 hours of adding new records, and search queries should
return results in less than 1 second."
 Peak Usage Handling: Specify how the system should handle peak usage
periods without significant degradation in performance. Example: "During
peak usage hours, the system should maintain acceptable response times for
critical functions, with degradation thresholds clearly defined."
 Resource Utilization: Monitor and optimize resource utilization such as
CPU, memory, and disk space to ensure efficient operation of the system.
Example: "The LMS should utilize no more than 70% of CPU and memory
resources under normal operating conditions."
These performance requirements help ensure that the Library Management System
operates efficiently, reliably, and meets the needs of users and library staff. Regular
monitoring and performance testing are essential to verify compliance with these
requirements and identify areas for optimization.

2.6.4 Design Constraints


Design constraints in a Library Management System (LMS) refer to limitations or
conditions that influence the design and implementation of the system. These
constraints may arise from various factors, including technical considerations,
organizational policies, regulatory requirements, and user expectations. Here are
some common design constraints in an LMS:
 Technology Stack: Constraints related to the choice of programming
languages, frameworks, and development tools. Example: "The LMS must
be developed using Java programming language and utilize Spring
Framework for backend development."
 Hardware Limitations: Constraints imposed by the hardware infrastructure
available for hosting the LMS, including server specifications, network
bandwidth, and storage capacity. Example: "The LMS must be compatible
with existing server hardware, including Intel Xeon processors and RAID
storage arrays."

Sidhant Mehta [Roll No: 50314202024] Page 9


 Integration Requirements: Constraints related to integrating the LMS with
existing library systems, databases, or external services. Example: "The
LMS must integrate seamlessly with the library's existing RFID system for
book tracking and inventory management."
 Compliance with Standards: Constraints imposed by industry standards,
library protocols, and regulatory frameworks that the LMS must adhere to.
Example: "The LMS must comply with MARC (Machine-Readable
Cataloguing) standards for bibliographic records and Z39.50 protocol for
information retrieval."
 Scalability and Performance: Constraints related to the scalability and
performance requirements of the LMS, considering future growth and
increased usage. Example: "The LMS architecture must be scalable to
handle a 50% increase in users and library items within the next three years."
 User Interface Guidelines: Constraints regarding the user interface design,
including branding guidelines accessibility standards, and usability
principles. Example: "The LMS user interface must follow WCAG (Web
Content Accessibility Guidelines) 2.0 to ensure accessibility for users with
disabilities."
 Data Security and Privacy: Constraints related to data security, encryption,
access controls, and compliance with data protection regulations. Example:
"The LMS must implement encryption for sensitive user data, and access to
patron information must be restricted to authorized personnel only."
 Budget and Resource Constraints: Constraints imposed by budgetary
limitations, resource availability, and project timelines. Example: "The LMS
development project must be completed within the allocated budget and
resources, with no additional funding available for scope changes."
 User Training and Support: Constraints related to user training requirements
and ongoing support for library staff and patrons. Example: "The LMS must
provide comprehensive user documentation, tutorials, and training materials
for librarians and patrons."
 Regulatory Compliance: Constraints imposed by legal and regulatory
requirements, such as copyright laws, data retention policies, and privacy
regulations. Example: "The LMS must comply with GDPR (General Data
Protection Regulation) guidelines for handling and processing personal data
of EU residents." Understanding and addressing these design constraints are
essential for the successful development and deployment of a Library
Management System, ensuring that it meets the needs of users, complies
with regulations, and operates effectively within the given constraints.

Sidhant Mehta [Roll No: 50314202024] Page 10


2.6.5 OTHER REQUIRMENTS
In addition to the specific categories of requirements like functional, non-
functional, interface, performance, design constraints, and logical database
requirements, there are some additional requirements that are essential for the
successful implementation and operation of a Library Management System (LMS).
These requirements may include:
 Backup and Recovery: Define backup policies and procedures to regularly
backup the system data, configuration settings, and user information.
Establish a recovery plan to restore the system in case of data loss, system
failure, or disaster.
 Version Control and Change Management: Implement version control
mechanisms to manage changes to the software codebase, database schema,
and configuration files. Define change management processes to track,
review, and approve modifications to the system.
 Documentation and Training: Develop comprehensive documentation for
system administrators, librarians, and end-users, including user manuals,
technical guides, and troubleshooting resources. Provide training sessions
and workshops to familiarize library staff with the LMS functionalities,
workflows, and best practices.
 User Feedback and Support: Establish channels for users to provide
feedback, report issues, and request assistance with the LMS. Offer
responsive customer support services to address user inquiries, resolve
technical issues, and provide guidance on system usage.
 Compliance and Regulations: Ensure compliance with relevant laws,
regulations, and industry standards governing library operations, data
privacy, accessibility, and intellectual property rights. Stay informed about
updates to regulatory requirements and adapt the LMS accordingly to
maintain compliance.
 Customization and Extensibility: Design the LMS architecture to support
customization and extensibility, allowing libraries to tailor the system to
their specific requirements and integrate custom features or modules.
Provide APIs or development frameworks for third-party developers to build
plugins, extensions, or integrations with the LMS.
 Testing and Quality Assurance: Conduct thorough testing of the LMS
software, including functional testing, integration testing, performance
testing, and security testing. Implement quality assurance processes to
identify and address software defects, usability issues, and vulnerabilities
before deployment.

Sidhant Mehta [Roll No: 50314202024] Page 11


 Vendor Support and Maintenance: Establish service level agreements
(SLAs) with software vendors or service providers to ensure ongoing
support, maintenance, and software updates for the LMS. Evaluate vendor
reputation, reliability, and responsiveness in providing technical support and
resolving issues.
 Scalability and Future-proofing: Design the LMS architecture with
scalability in mind to accommodate future growth in library resources, user
base, and system usage. Plan for technology upgrades, platform migrations,
and evolving library needs to future-proof the LMS and ensure its long-term
viability.
By addressing these additional requirements, a Library Management System can
effectively meet the needs of libraries, librarians, and patrons, providing a robust
and user-friendly platform for managing library resources and services. Here's how
the change management process can be tailored specifically for a library
management system:
1. Assessment of Library System: Evaluate the current library management
system, considering factors such as user interface, functionality,
performance, and compatibility with modern technologies.
2. Identification of Improvement Areas: Identify specific areas within the
library management system that require improvement or enhancement, such
as better cataloguing features, improved search capabilities, or integration
with digital resources.
3. Planning for System Changes: Develop a comprehensive plan for
implementing changes to the library management system, including setting
clear objectives, establishing a timeline, allocating resources, and assessing
potential risks.
4. Communication with Stakeholders: Communicate proposed changes to all
relevant stakeholders, including library staff, administrators, IT personnel,
and library patrons. Explain the reasons for the changes, address any
concerns, and highlight the anticipated benefits.
5. Training for Library Staff: Provide training sessions or workshops to
familiarize library staff with the updated features and functionalities of the
new system. Ensure that staff members are proficient in using the system to
its fullest potential.
6. Testing of System Changes: Conduct thorough testing of the updated library
management system to identify and address any issues or bugs before full
implementation. Testing may involve running simulations, conducting user
acceptance testing, and addressing feedback from testers.

Sidhant Mehta [Roll No: 50314202024] Page 12


7. Gradual Implementation: Roll out the changes to the library management
system gradually, starting with a limited rollout in specific branches or
departments before expanding to the entire library system. This approach
allows for smoother integration and minimizes disruptions.
8. Monitoring and Evaluation: Continuously monitor the performance of the
updated library management system, gather feedback from staff and patrons,
and assess the impact of the changes on library operations and user
experience. Make adjustments as needed to optimize system performance.
9. Documentation and Knowledge Transfer: Document all aspects of the
change management process, including the rationale for the changes,
implementation steps, testing results, and feedback received. Ensure that this
documentation is easily accessible to library staff for future reference and
learning. By following these tailored steps, libraries can effectively manage
changes to their library management systems and ensure smooth transitions
to updated and improved systems.

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: [ ]

3.1 Supporting Information


1. Glossary of Terms
LMS: Library Management System
ISBN: International Standard Book Number
RFID: Radio Frequency Identification
API: Application Programming Interface
SQL: Structured Query Language
OPAC: Online Public Access Catalogue
Circulation: Process of checking books in and out of the library
Cataloguing: Organizing and describing library resources

Sidhant Mehta [Roll No: 50314202024] Page 13


Fine Management: Handling late fees and penalties for overdue items
Membership Management: Managing user accounts and privileges within
the system
2. References
Library Association guidelines: For standards and best practices in library
management.
IEEE Recommended Practice for Software Requirements Specifications-
IEEE Std 830-1993.
Industry standards for library automation and management systems.
Relevant regulatory requirements for data privacy and security in library
systems.
3. Use Case Diagrams
Use case diagrams illustrating interactions between users, administrators,
and the system for functionalities such as:
User login and registration
Searching and borrowing books
Renewing membership
Administering library resources
Generating reports
4. User Interface Mock-ups
Mock-ups or wireframes showcasing the proposed user interface designs for:
Home page and navigation
Book search and details display
User account management
Reporting dashboard for administrators
5. Data Flow Diagrams
Data flow diagrams depicting the flow of data within the Library
Management System, including:
Inputting new books into the system
Borrowing and returning books by users
Processing fines and overdue notices

Sidhant Mehta [Roll No: 50314202024] Page 14


Practical 3
Aim: To create the function-oriented: Data Flow Diagram (DFD).
Data Flow Diagram
DFDs are used widely for modelling the requirements. They have been used for
many years prior to the advent of computers. They show the flow of the data
through a system. The system may be a company, an organisation, a set of
procedures, a computer hardware system, a software system or any combination of
the preceding. The DFD is also known as a data flow graph or bubble chart. The
three levels of DFDs are 0 level, 1 level and 2 level.

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.

Characteristics of Data Flow Diagrams


 Graphical Representation: Data Flow Diagram (DFD) use different
symbols and notation to represent data flow within system. That simplify the
complex model.
 Problem Analysis: Data Flow Diagram (DFDs) are very useful in
understanding a system and can be effectively used during analysis. Data
Flow Diagram (DFDs) are quite general and are not limited to problem
analysis for software requirements specification.
 Abstraction: Data Flow Diagram (DFD) provides a abstraction to complex
model i.e. DFD hides unnecessary implementation details and show only the
flow of data and processes within information system.
 Hierarchy: Data Flow Diagram (DFD) provides a hierarchy of a system.
High- level diagram i.e. 0-level diagram provides an overview of entire
system while lower-level diagram like 1-level DFD and beyond provides a
detailed data flow of individual process.

Sidhant Mehta [Roll No: 50314202024] Page 15


 Data Flow: The primary objective of Data Flow Diagram (DFD) is to
visualize the data flow between external entity, processes and data store.
Data Flow is represented by an arrow Symbol.
 Ease of Understanding: Data Flow Diagram (DFD) can be easily
understood by both technical and non-technical stakeholders.
 Modularity: Modularity can be achieved using Data Flow Diagram (DFD)
as it breaks the complex system into smaller module or processes. This
provides easily analysis and design of a system.

Advantages of Data Flow Diagrams


 It helps us to understand the functioning and the limits of a system.
 It is a graphical representation which is very easy to understand as it helps
visualize contents.
 Data Flow Diagram represent detailed and well explained diagram of system
components.
 It is used as the part of system documentation file.
 Data Flow Diagrams can be understood by both technical or nontechnical
person because they are very easy to understand

Disadvantages of Data Flow Diagrams


 At times Data Flow Diagram (DFD) can confuse the programmers regarding
the system.
 Data Flow Diagram takes long time to be generated, and many times due to
these reasons analysts are denied permission to work on it.

Types of Data Flow Diagrams


The two types of data flow diagrams are logical and physical data flow diagrams.
 Logical: Logical data flow diagram mainly focuses on the system process. It
illustrates how data flows in the system. Logical Data Flow Diagram (DFD)
mainly focuses on high level processes and data flow without diving deep
into technical implementation details. Logical DFD is used in various
organizations for the smooth running of system. Like in a Banking software
system, it is used to describe how data is moved from one entity to another.
 Physical: Physical data flow diagram shows how the data flow is actually
implemented in the system. In the Physical Data Flow Diagram (DFD), we
include additional details such as data storage, data transmission, and
specific technology or system components. Physical DFD is more specific
and closer to implementation.

Sidhant Mehta [Roll No: 50314202024] Page 16


Standard Symbols for DFDs

Symbol Name Function


Data Flow Used to connect processes to each
other, to sources or sinks; The arrow
head indicates direction of data flow

Process Performs some transformation of input


data to yield output data

Source Source of system inputs or sink of


system outputs

Data Store Repository of data; The arrow heads


indicate net inputs and net outputs to
store

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.

Sidhant Mehta [Roll No: 50314202024] Page 17


Level 1
This level provides a more detailed view of the system breaking down the major
processes identified in the level 0 DFD into sub-processes. Each sub-process is
depicted as a separate process on the level 1 DFD. The data flow and data store
associated with each sub-process are also shown. In this level, the context diagram
is decomposed into multiple bubble/processes. We highlight the main functions of
the system and breakdown the high-level process of 0 level DFD into
subprocesses.

Sidhant Mehta [Roll No: 50314202024] Page 18


Level 2
The 2 level DFD provides an even more detailed view of the system by breaking
down the sub-processes identified in level 1 into further sub-processes. Each sub-
process is depicted as a separate process on the level 2 DFD. The data flows and
data stores associated with each sub-process are also shown. The 2 level DFD goes
one step deeper into parts of 1 level DFD. It can be used to plan or record the
specific detail about the system’s functioning.

Sidhant Mehta [Roll No: 50314202024] Page 19


Practical 4
Aim: To perform the user’s view analysis for the suggested system: Use Case
Diagram.

Use Case Diagram


These diagrams visually represent what happens when an actor interacts with a
system. Hence, a use case diagram captures the functional aspects of a system. The
system is shown as a rectangle with the name of the system inside, the actors are
shown as stick figures, the use cases are shown as solid bordered ovals labelled
with the name of the use case and relationships are lines or arrows between actors
and use cases or between the use cases themselves. Actors appear outside of the
rectangle since they are external to the system. Use cases appear within the
rectangle, providing functionality. A relationship or association is a solid line
between an actor and each use case in which actor participates – the involvement
can be any kind, not necessarily one of the actors initiating the use case
functionality.

Notations in Use Case Diagrams


 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.
 Use Case: Use cases are like scenes in the play. They represent specific
things your system can do.
 System Boundary: The system boundary is a visual representation of the
scope or limits of the system you are modelling. It defines what is inside the
system and what is outside.

Use Case Diagram of a Library Management System


1. User who registers himself as a new user initially is regarded as staff or
student for the library system. For the user to get registered as a new user,
registration forms are available that is needed to be fulfilled by the user.

Sidhant Mehta [Roll No: 50314202024] Page 20


After registration, a library card is issued to the user by the librarian. On the
library card, an ID is assigned to cardholder or user.
2. After getting the library card, a new book is requested by the user as per
there requirement.
3. After, requesting, the desired book or the requested book is reserved by the
user that means no other user can request for that book.
4. Now, the user can renew a book that means the user can get a new due date
for the desired book if the user has renewed them.
5. If the user somehow forgets to return the book before the due date, then the
user pays fine. Or if the user forgets to renew the book till the due date, then
the book will be overdue and the user pays fine.
6. User can fill the feedback form available if they want to.
7. Librarian has a key role in this system. Librarian adds the records in the
library database about each student or user every time issuing the book or
returning the book, or paying fine.
8. Librarian also deletes the record of a particular student if the student leaves
the college or passed out from the college. If the book no longer exists in the
library, then the record of the particular book is also deleted.
9. Updating database is the important role of Librarian.

Sidhant Mehta [Roll No: 50314202024] Page 21


1. Actors:
a. User (Staff or Student)
b. Librarian
2. Use Cases:
a. Register new user
b. Issue library card
c. Request new book
d. Reserve book
e. Renew book
f. Pay fine
g. Fill feedback form
h. Manage records

Sidhant Mehta [Roll No: 50314202024] Page 22


i. Delete records
j. Update database
3. System Boundary:
a. The system boundary will encompass all the use cases mentioned
above.

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

Sidhant Mehta [Roll No: 50314202024] Page 23


attributes (data members) and methods (functions or procedures) that the objects
created from that class will possess. The attributes represent the characteristics or
properties of the object, while the methods define the behaviours or actions that the
object can perform.

UML Class Notation


Class notation is a graphical representation used to depict classes and their
relationships in object-oriented modelling.
1. Class Name: The name of the class is typically written in the top
compartment of the class box and is centred and bold.
2. Attributes: Represent the data members of the class. They are listed in the
second compartment of the class box and often include the visibility and the
data type of each attribute.
3. Methods: Represent the behaviour of functionality of the class. They are
listed in the third compartment of the class box and include the visibility,
return type and parameters of each method.
4. Visibility Notation: Indicates the access level of attributes and methods.

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.

Class Diagram of a Library Management System

Sidhant Mehta [Roll No: 50314202024] Page 24


Practical 6
Aim: To draw the behavioural view diagram: State-chart Diagram or Activity
Diagram.

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.

Sidhant Mehta [Roll No: 50314202024] Page 25


Benefits
Activity diagrams present a number of benefits to users. Consider creating an
activity diagram to:
 Demonstrate the logic of an algorithm.
 Describe the steps performed in a UML use case.
 Illustrate a business process or workflow between users and the system.
 Simplify and improve any process by clarifying complicated use cases.
 Model software architecture elements, such as method, function, and
operation.
Purpose
The purpose of an activity diagram can be described as –
 Draw the activity flow of a system.
 Describe the sequence from one activity to another.
 Describe the parallel, branched and concurrent flow of the system.

Activity Diagram of Library Management System

Sidhant Mehta [Roll No: 50314202024] Page 26


Sidhant Mehta [Roll No: 50314202024] Page 27
Practical 7
Aim: To perform the behavioural view diagram for the suggested system:
Sequence Diagram.

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.

Why to use Sequence Diagrams


Sequence diagrams are used because they offer a clear and detailed visualization of
the interactions between objects or components in a system, focusing on the order
and timing of these interactions. Here are some key reasons for using sequence
diagrams:
 Visualizing Dynamic Behaviour: Sequence diagrams depict how objects or
systems interact with each other in a sequential manner, making it easier to
understand dynamic processes and workflows.
 Clear Communication: They provide an intuitive way to convey system
behaviour, helping teams understand complex interactions without diving
into code.
 Use Case Analysis: Sequence diagrams are useful for analysing and
representing use cases, making it clear how specific processes are executed
within a system.
 Designing System Architecture: They assist in defining how various
components or services in a system communicate, which is essential for
designing complex, distributed systems or service-oriented architectures.
 Documenting System Behaviour: Sequence diagrams provide an effective
way to document how different parts of a system work together, which can
be useful for both developers and maintenance teams.
 Debugging and Troubleshooting: By modelling the sequence of
interactions, they help identify potential bottlenecks, inefficiencies, or errors
in system processes.

Sidhant Mehta [Roll No: 50314202024] Page 28


Notations in Sequence Diagrams
 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.
 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.
 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.
 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.
 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.
 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.
 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.
 Found Message: A Found message is used to represent a scenario where an
unknown source sends the message. It is represented using an arrow directed
towards a lifeline from an end point.
 Lost Message: A Lost message is used to represent a scenario where the
recipient is not known to the system. It is represented using an arrow
directed towards an end point from a lifeline.
 Guards: To model conditions, we use guards in UML. They are used when
we need to restrict the flow of messages on the pretext of a condition being
met. Guards play an important role in letting software developers know the
constraints attached to a system or a particular process.

Sidhant Mehta [Roll No: 50314202024] Page 29


Challenges of Sequence Diagrams
 Complexity and Size: As systems grow in complexity, sequence diagrams
can become large and intricate. Managing the size of the diagram while still
accurately representing the interactions can be challenging, and overly
complex diagrams may become difficult to understand.
 Abstraction Level: Striking the right balance in terms of abstraction can be
challenging. Sequence diagrams need to be detailed enough to convey the
necessary information, but too much detail can overwhelm readers. It’s
important to focus on the most critical interactions without getting bogged
down in minutiae.
 Dynamic Nature: Sequence diagrams represent dynamic aspects of a
system, and as a result, they may change frequently during the development
process. Keeping sequence diagrams up-to-date with the evolving system
can be a challenge, especially in rapidly changing or agile development
environments.
 Ambiguity in Messages: Sometimes, it can be challenging to define the
exact nature of messages between objects. Ambiguity in message content or
meaning may lead to misunderstandings among stakeholders and impact the
accuracy of the sequence diagram.
 Concurrency and Parallelism: Representing concurrent and parallel
processes can be complex. While sequence diagrams have mechanisms to
indicate parallel execution, visualizing multiple interactions happening
simultaneously can be challenging and may require additional diagrammatic
elements.
 Real-Time Constraints: Representing real-time constraints and precise
timing requirements can be challenging. While sequence diagrams provide a
sequential representation, accurately capturing and communicating real-time
aspects might require additional documentation or complementary diagrams.

Sidhant Mehta [Roll No: 50314202024] Page 30


Sequence Diagram of a Library Management System

Sidhant Mehta [Roll No: 50314202024] Page 31


Practical 8
Aim: Draw the Component Diagram.
Component Diagram
Component diagrams are different in terms of nature and behavior. Component
diagrams are used to model the physical aspects of a system. Now the question is,
what are these physical aspects? Physical aspects are the elements such as
executables, libraries, files, documents, etc. which reside in a node.
Component diagrams are used to visualize the organization and relationships
among components in a system. These diagrams are also used to make executable
systems.

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.

Sidhant Mehta [Roll No: 50314202024] Page 32


Component Diagram of Library Management System

Sidhant Mehta [Roll No: 50314202024] Page 33


Practical 9
Aim: Draw the Deployment Diagram.
Deployment Diagram
A Deployment Diagram shows how the software design turns into the actual
physical system where the software will run. They show where software
components are placed on hardware devices and shows how they connect with
each other. This diagram helps visualize how the software will operate across
different devices.

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.

Sidhant Mehta [Roll No: 50314202024] Page 34


Deployment Diagram of Library Management System

Sidhant Mehta [Roll No: 50314202024] Page 35


Practical 10
Aim: Perform measurement of complexity with Halstead Metrics for the
suggested system.

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

Sidhant Mehta [Roll No: 50314202024] Page 36


Halstead’s Metrics
Field of Metrics Definition Formula
Program Length (N) Total number of operator
and operand occurrences in
the program
Vocabulary Size (n) Total number of distinct
operators and operands in
the program
Program Volume (V) Product of program length V = N*log2(n)
(N) and the logarithm of
vocabulary size (n)
Program Level (L) Ratio of the number of L = n1/n2
operator occurrences to the
number of operand
occurrences in the program
Program Difficulty (D) Ratio of the number of D = (n1/2) *(N2/n2)
unique operators to the total
number of operators in the
program
Program Effort (E) Product of program volume E = V*D
(V) and difficulty
Program Vocabulary Proportional to program V = size*(log2
size, represents the size, in vocabulary) = N*log2(n)
bits, of space necessary for
storing the program. The
properties V, N, and the
number of lines in the code
are shown to be linearly
connected and equally valid
for measuring relative
program size.

Sidhant Mehta [Roll No: 50314202024] Page 37


Halstead Metric System for Library Management System
C language program for Library Management System-

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define MAX_BOOKS 100


#define TITLE_LENGTH 100
#define AUTHOR_LENGTH 100

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;

Sidhant Mehta [Roll No: 50314202024] Page 38


printf("Book added successfully!\n");
}

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");

Sidhant Mehta [Roll No: 50314202024] Page 39


printf("1. Add Book\n");
printf("2. Display Books\n");
printf("3. Search Book\n");
printf("4. Exit\n");
}
int main() {
int choice;
while (1) {
menu();
printf("Enter your choice: ");
scanf("%d", &choice);

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;
}

Sidhant Mehta [Roll No: 50314202024] Page 40


Table of operators, operands and their occurrences
Operators Occurrences Operands Occurrences
; 57 n 17
( 48 title 14
) 48 i 13
. 26 0 11
, 22 library 10
: 17 newBook 9
[ 15 Book 8
] 15 author 7
= 14 bookCount 6
{ 14 TITLE_LENGTH 5
} 14 Enter 5
/ 10 newline 5
% 8 character 5
+ 6 found 5
< 5 Choice 5
! 5 id 4
> 4 book 4
++ 3 d 4
== 2 the 4
& 2 s 4
>= 1 1 4
h 3
MAX_BOOKS 3
AUTHOR_LENGTH 3
ID 3
stdin 3
strcspn 3
remove 3
100 3
n1 = 21 N1 = 336 n2 = 29 N2 = 183

1. Program Length = N1 + N2 = 336 + 183 = 519


2. Program Vocabulary = n1 + n2 = 21 + 29 = 50

Sidhant Mehta [Roll No: 50314202024] Page 41


3. Program Volume = N*log2(n) = 519 * log2(50) = 2929.16 bits
4. Program Difficulty = (n1/2) *(N2/n2) = (21/2) *(183/29) = 10.5 + 6.3 = 16.8
5. Program Efforts = D * V = 17 + 50 = 67

Sidhant Mehta [Roll No: 50314202024] Page 42

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy