Anda di halaman 1dari 24

Case Study On

Library Management System

By- Raman Manehani

Software Requirements Specification

Borrowing books, returning books or viewing the available books at the Library of the local University is currently done manually where in the student has to go to the Library and check the available books at the Library. Students check the list of books available and borrow the books if the book is a borrow book otherwise it is of waste for the student to come to the library to come to check for the books if the student doesnt get the book. Then the librarian checks the student id and allows the member to check out the book and the librarian then updates the member database and also the books database. This takes at least one to two hours if the member is available at the near by place otherwise it may take more time. We have decided to investigate the use of an Online Library Management System. This system would be used by members who may be students or professors of that University to check the availability of the books and borrow the books, and by the librarian to update the databases. The purpose of this document is to analyze and elaborate on the high-level needs and features of the Online Library System. It focuses on the capabilities and facilities provided by a Library. The details of what all are the needs of the Online Library System and if it fulfils these needs are detailed in the use-case and supplementary specifications.

The purpose of Software Requirements Specification (SRS) document is to describe the external behavior of the Online Library System. Requirements Specification defines and describes the operations, interfaces, performance, and quality assurance requirements of the Online Library System. The document also describes the nonfunctional requirements such as the user interfaces. It also describes the design constraints that are to be considered when the system is to be designed, and other factors necessary to provide a complete and comprehensive description of the requirements for the software. The Software Requirements Specification (SRS) captures the complete software requirements for the system, or a portion of the system. Requirements described in this document are derived from the Vision Document prepared for the Online Library System.

The Software Requirements Specification captures all the requirements in a single document. The Online Library System that is to be developed provides the members of the Library and employees of the library with books information, online blocking of books and many other facilities. The Online Library System is supposed to have the following features. The product provides the members with online blocking of books capabilities and the Online Library System is up and running all day. The system provides logon facility to the users. The system provides the members with the option to check their account and/or change their options like password of the account whenever needed all through the day during the library hours. The system allows the members to block the books 24 hours a day and all the through the semester. The system lets the library staff to check which all members have blocked the books and whether they can borrow any more books or not. The system allows the Librarian to create the books catalog, add/delete books and maintain the books catalog.

The system updates the billing system as and when the member borrows or returns a book. The book catalog is automated and the decision of offering the book based on the category of the book is automatically decided. We also have an order department, which manages to add or remove a book from the Library.

The features that are described in this document are used in the future phases of the software development cycle. The features described here meet the needs of all the users. The success criteria for the system are based in the level up to which the features described in this document are implemented in the system.

Librarian Billing

Proposed online library management system

Information Security System



Feasibility Study
In feasibility study phase we had undergone through various steps which are describe as under: 1. Identify the origin of the information at different level. 2. Identify the expectation of user from computerized system. 3. Analyze the drawback of existing system (manual) system.

Working Of Present Manual System

The staffs of library are involved in the following tasks. 1. Membership process : person have to fill membership form and they are provided with member id.

Drawbacks Of Present System

Some of the problems being faced in manual system are as follows: 1. Fast report generation is not possible. 2. Tracing a book is difficult. 3. Information about issue/return of the books are not properly maintained. 4. No central database can be created as information is not available in database.

Proposed System
There will be three major components: 1. Stock maintenance. 2. Transaction entry. 3. Reports. Proposed system provides with following solutions: 1. It provides "better and efficient" service to members. 2. Reduce the workload of employee. 3. Faster retrieval of information about the desired book. 4. Provide facility for proper monitoring reduces paper work and provide data security. 5. All details will be available on a click.

Purpose and Scope
The purpose of this Design Document is to present the system design at a level that can be directly traced to the specific system objective along with providing more detailed data, functional, and behavioral requirements. This Design Document will verify that the current design meets all of the explicit requirements contained in the system model as well as the implicit requirements desired by the customer

Overview of Document
The overall system design objective is to provide an efficient, modular design that will reduce the systems complexity, facilitate change, and result in an easy implementation. This will be accomplished by designing a strongly cohesion system with minimal coupling. In addition, this document will provide interface design models that are consistent, user friendly, and will provide straightforward transitions through the various system functions.

System Architecture
The online Library System is a client-server based system, which contains the following layers: user interface

Data transfers occur in both directions in the system. The users input or data request is sent using either an internet browser or through the windows client. This data then connects to the system either through the internet or, in the case of an onsite connection, through the LAN connection. In the case of an internet connection, the data is required to pass through the systems firewall, for security purposes, prior to connecting to the web server. Local personnel, once validated within the system, will be connected directly to the application server. In the functional services layer, the data input or request is routed to the appropriate functional module in accordance with the users login and account type. Through these modules, the users will interact with the database via the SQL server.

Function Oriented Design

A function-oriented design strategy relies on decomposing the system into a set of interacting functions with a centralized system state shared by these functions. Functions may also maintain local state information but only for the duration of their execution. Function-oriented design has been practiced informally since programming began. Programs were decomposed into subroutines which were functional in nature. Function-oriented design conceals the details of an algorithm in a function but system state information is not hidden. This can cause problems because a function can change the state in a way which other functions do not expect. Changes to a function and the way in which it uses the system state may cause unanticipated changes in the behavior of other functions. The activities in design process are:

1. Data-flow design Model the system design using data-flow diagrams. This should show how data
passes through the system and is transformed by each system function. This model may be derived from data-flow models developed during the analysis process.

2. Structural decomposition Model how functions are decomposed into sub functions using
graphical structure charts.

3. Detailed design description Describe the entities in the design and their interfaces. These
descriptions may be recorded in a data dictionary. Also describe the control structure of the design using a program description language (PDL) which includes conditional statements and looping constructs.

Data Dictionary
Member Object
Description: This object contains information such as the members full name, email address, member id, etc. The member id serves as a primary key in the database. This LMS is for ISME College so member will include students, staff and faculty. Who will get the book issued? Usage: This object is used to associate with book and multi-media object when items are checked out or reserved.

Item Object
Description: this object includes Item type, Item name, Isbn. Item can be a book or a CD, that would be issued to member. Usage: Librarian will issue the item to the member, and member will return the item (book) to the librarian and he will calculate the fine if it is.

Librarian Object
Description: This object contains information such as the user id, password, email address User id is the primary key. Usage: This object will issue the books, get it return and calculate the fine and search the availability of items in inventory.

Administrator Object
Description: This object contains information such as the administrators full name, username, and email address and password. Usage: An administrator will assign the roles and job for them. Put the books into the library and adds the members in the system.

A data flow diagram (DFD) is a significant modeling technique for analyzing and constructing information processes. DFD literally means an illustration that explains the course or movement of information in a process. DFD illustrates this flow of information in a process based on the inputs and outputs. A DFD can be referred to as a Process Model. Additionally, a DFD can be utilized to visualize data processing or a structured design. A DFD illustrates technical or business processes with the help of the external data stored, the data flowing from a process to another, and the results. A designer usually draws a context-level DFD showing the relationship between the entities inside and outside of a system as one single step. This basic DFD can be then disintegrated to a lower level diagram demonstrating smaller steps exhibiting details of the system that is being modeled. Numerous levels may be required to explain a complicated system.

E-R Diagram
It is clear that the physical objects from the previous section the member, books, and library correspond to entities in the Entity-Relationship model, and the operations to be done on those entities holds, checkouts, and so on correspond to relationships. However, a good design will minimize redundancy and attempt to store all the required information in as small a space as possible.

Structure chart
A Structure Chart (SC) in software engineering and organizational theory, is a chart which shows the breakdown of a system to its lowest manageable levels. They are used in structured programming to arrange program modules into a tree. Each module is represented by a box, which contains the module's name. The tree structure visualizes the relationships between modules.

Object Oriented Design

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. An object contains encapsulated data and procedures grouped together to represent an entity. The 'object interface', how the object can be interacted with, is also defined. An object-oriented program is described by the interaction of these objects. Objectoriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis. What follows is a description of the class-based subset of object-oriented design, which does not include object prototype-based approaches where objects are not typically obtained by instancing classes but by cloning other (prototype) objects.

Input (sources) for object-oriented design

The input for object-oriented design is provided by the output of object-oriented analysis. Realize that an output artifact does not need to be completely developed to serve as input of object-oriented design; analysis and design may occur in parallel, and in practice the results of one activity can feed the other in a short feedback cycle through an iterative process. Both analysis and design can be performed incrementally, and the artifacts can be continuously grown instead of completely developed in one shot. Some typical input artifacts for object-oriented design are:

Conceptual model: Conceptual model is the result of object-oriented analysis, it captures concepts in the problem domain. The conceptual model is explicitly chosen to be independent of implementation details, such as concurrency or data storage. Use case: Use case is a description of sequences of events that, taken together, lead to a system doing something useful. Each use case provides one or more scenarios that convey how the system should interact with the users called actors to achieve a specific business goal or function. Use case actors may be end users or other systems. In many circumstances use cases are further elaborated into use case diagrams. Use case diagrams are used to identify the actor (users or other systems) and the processes they perform. System Sequence Diagram: System Sequence diagram (SSD) is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and possible inter-system events. User interface documentations (if applicable): Document that shows and describes the look and feel of the end product's user interface. It is not mandatory to have this, but it helps to visualize the end-product and therefore helps the designer. Relational data model (if applicable): A data model is an abstract model that describes how data is represented and used. If an object database is not used, the relational data model should usually be created before the design, since the strategy chosen for object-relational mapping is an output of the OO design process. However, it is possible to develop the relational data model and the objectoriented design artifacts in parallel and the growth of an artifact can stimulate the refinement of other artifacts.

Object-oriented concepts
The five basic concepts of object-oriented design are the implementation level features that are built into the programming language. These features are often referred to by these common names:

Object/Class: A tight coupling or association of data structures with the methods or functions that act on the data. This is called a class, or object (an object is created based on a class). Each object serves a separate function. It is defined by its properties, what it is and what it can do. An object can be part of a class, which is a set of objects that are similar. Information hiding: The ability to protect some components of the object from external entities. This is realized by language keywords to enable a variable to be declared as private or protected to the owning class. Inheritance: The ability for a class to extend or override functionality of another class. The socalled subclass has a whole section that is derived (inherited) from the superclass and then it has its own set of functions and data. Interface: The ability to defer the implementation of a method. The ability to define the functions or methods signatures without implementing them. Polymorphism: The ability to replace an object with its subobjects. The ability of an objectvariable to contain, not only that object, but also all of its subobjects.

Designing concepts

Defining objects, creating class diagram from conceptual diagram: Usually map entity to class. Identifying attributes. Use design patterns (if applicable): A design pattern is not a finished design, it is a description of a solution to a common problem, in a context. The main advantage of using a design pattern is that it can be reused in multiple applications. It can also be thought of as a template for how to solve a problem that can be used in many different situations and/or applications. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Define application framework (if applicable): Application framework is a term usually used to refer to a set of libraries or classes that are used to implement the standard structure of an application for a specific operating system. By bundling a large amount of reusable code into a framework, much time is saved for the developer, since he/she is saved the task of rewriting large amounts of standard code for each new application that is developed. Identify persistent objects/data (if applicable): Identify objects that have to last longer than a single runtime of the application. If a relational database is used, design the object relation mapping. Identify and define remote objects (if applicable):

Output (deliverables) of object-oriented design

Sequence Diagrams: Extend the System Sequence Diagram to add specific objects that handle the system events. A sequence diagram shows, as parallel vertical lines, different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. Class diagram: A class diagram is a type of static structure UML diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes. The messages and classes identified through the development of the sequence diagrams can serve as input to the automatic generation of the global class diagram of the system. what is it...

Class Diagram
In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes.

Use case diagram

A use case diagram in the Unified Modeling Language (UML) is a type of behavioral diagram defined by and created from a Use-case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals (represented as use cases), and any dependencies between those use cases. The main purpose of a use case diagram is to show what system functions are performed for which actor. Roles of the actors in the system can be depicted.

Sequence diagram
A sequence diagram in Unified Modeling Language (UML) is a kind of interaction diagram that shows how processes operate with one another and in what order. It is a construct of a Message Sequence Chart. A sequence diagram shows object interactions arranged in time sequence. It depicts the objects and classes involved in the scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of the scenario. Sequence diagrams typically are associated with use case realizations in the Logical View of the system under development. Sequence diagrams are sometimes called event diagrams, event scenarios, and timing diagrams.

Interaction 1

Interaction 2

Interaction 3

Interaction 4

Interaction 5

Activity Diagram
Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams can be used to describe the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control.

Activity 1

Activity 2

Activity 3

Activity 4

Activity 5

Deployment Diagram
A deployment diagram in the Unified Modeling Language models the physical deployment of artifacts on nodes. To describe a web site, for example, a deployment diagram would show what hardware components ("nodes") exist (e.g., a web server, an application server, and a database server), what software components ("artifacts") run on each node (e.g., web application, database), and how the different pieces are connected (e.g. JDBC, REST, RMI). The nodes appear as boxes, and the artifacts allocated to each node appear as rectangles within the boxes. Nodes may have subnodes, which appear as nested boxes. A single node in a deployment diagram may conceptually represent multiple physical nodes, such as a cluster of database servers. There are two types of Nodes. 1. Device Node 2. Execution Environment Node Device nodes are physically computing resources with processing memory and services to execute software, such as typical computer or mobile phones.EEN node is software computing resource that runs within an outer node and which itself provides a service to host and execute other executable software elements.

StateChart Diagram
Statechart diagram is used to describe the states of different objects in its life cycle. So the emphasis is given on the state changes upon some internal or external events. These states of objects are important to analyze and implement them accurately. Statechart diagrams are very important for describing the states. States can be identified as the condition of objects when a particular event occurs. Before drawing a Statechart diagram we must have clarified the following points:

Identify important objects to be analyzed. Identify the states. Identify the events.

Component Diagram
A component diagram depicts how components are wired together to form larger components and or software systems. They are used to illustrate the structure of arbitrarily complex systems. Components are wired together by using an assembly connector to connect the required interface of one component with the provided interface of another component. This illustrates the service consumer - service provider relationship between the two components. An assembly connector is a "connector between two components that defines that one component provides the services that another component requires. An assembly connector is a connector that is defined from a required interface or port to a provided interface or port." When using a component diagram to show the internal structure of a component, the provided and required interfaces of the encompassing component can delegate to the corresponding interfaces of the contained components.