Software Design Description Version Date: 06/02/2010
Software Design Description Version Date: 06/02/2010
Software Design Description Version Date: 06/02/2010
Version <1.0>
Date: 06/02/2010
i
Table of Contents
Contents
Contents............................................................................................................................................................1
1.0. Introduction................................................................................................................................................2
1.1. Purpose and Scope.................................................................................................................................2
1.2. Glossary.................................................................................................................................................2
1.3. References..............................................................................................................................................2
1.4. Overview of Document..........................................................................................................................3
2.0. System Architecture...................................................................................................................................4
3.0. Data Dictionary..........................................................................................................................................5
3.1. Objects...................................................................................................................................................5
3.2. Class Diagram:.......................................................................................................................................6
4.0. Architectural Design..................................................................................................................................6
..........................................................................................................................................................................8
5.0.Data Design..............................................................................................................................................10
6.0. Use Case Realizations..............................................................................................................................14
We talk about return scenario; Member returns the book to librarian, the system will validate the
member and the item that is issued, get return the book calculate the fine and update the database. Return is
connected to member, means member will return the item(book) to librarian. There is a relationship
between issue and return, return and calculate fine. It is an extends relationship. It means member will have
to return the book after issuing, but there is a possibility that he/she does not return the book. That is why
there is an extend relationship. After returning the book librarian calculates the fine if there is a late
submission fine will be added into the account of the member. Here return is specific use case that is
generalized by issue use case. It means return is using some properties of issue operation..........................14
7.0 User Interface Design: NA.......................................................................................................................15
8.0 Help System Design: NA..........................................................................................................................15
1
1.0. Introduction
1.2. Glossary
1.3. References
www.google.com
www.scribd.com
www.docstok.com
www.Wikipedia.org
2
1.4. Overview of Document
The overall system design objective is to provide an efficient, modular design that
will reduce the system’s 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.
3
2.0. System Architecture
The online Library System is a client-server based system, which contains the
following layers:user interface
,
internet communication, functional service, and data storage layers.
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
4
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
system’s 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.
3.1. Objects
Member Object:
Description: This object contains information such as the member’s 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 administrator’s 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.
5
3.2. 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.
This software system will do all the process required in library. This can be
explained by different steps as below:
will the member that it exist in database or not. If member exist then it
show error message and if member does not exist then it will save the
record.
2. Update: When there will be some changes in member detail then update
3. Adding Item: In this case item consist of books, cds, newspaper and
journals. When a new item will arrive, detail of each item will be inserted &
6
if same is present in database then error message will be displayed else
4. Issue of Item: During this operation there are two steps. Firstly, system
will check the desired item with the database, if it exist then it will go to
second step or will display error message. Secondly, system will check
validity of user. If user is valid then item is issued with a issued ID.
newspaper, journals) it will check with the system & calculate fine.
Activity Diagrams
7
8
9
5.0.Data Design
Provide below is a summary of the various data objects that make up the online
library system. Included in each table are the attributes of each object, the data
type for each attribute, the number of characters allowed for each field, the
default value, and any other information that defines the fields.
EER Diagram:
Item Detail
Field Data
Name Type Description
ISBN Int Item library number
Item Name Char(45) Name of Item
Price Int Item price
Date of
Arrival Date Date in which item arrived
Rack ID in which items are
Rack ID Int placed
Item ID Int Item unique ID
Publisher
ID Int Publisher unique ID
10
Author ID Int Author unique ID
Item Type
Field Data Descripti
Name Type on
Item unique
Item Id int ID
Category of
Item Type Char(45) Item
Item Subject
Field Data Descriptio
Name Type n
Subject unique
Subject ID int ID
Subject Name of
Name Char(45) Subject
Author
Field Data Descripti
Name Type on
Author unique
Author ID int ID
Author Name Char(45) Name of Author
Search
Field Data Descriptio
name type n
Item type Char(45) Category of item
Item name Char(45) Name of Item
Member id int Unique id for
member
Recommend
Field Data Descriptio
Name Type n
Member unique
Member ID int ID
Category Char(45)
11
Name Char(45) Item Name
Author Char(45) Name of Author
Member
Field Data
Name Type Description
Member
Type Char(45) Type of Member
Member ID int Member unique ID
Member
Address Char(45) Address of Member
Date of Join Date Joining Date
Member
Name Char(45) Name of Member
Member e-mail
E-mail Char(45) address
Return
Field Data
Name Type Description
Date of Date of returinig of
Return Date item
Issue ID int Issue Unique ID
Return ID int Return Unique ID
Fine
Field Data
Name Type Description
Amount collected
Amount int as fine
Issue ID int Issue Unique ID
Publisher Info
Field Data
Name Type Description
Publisher ID int Publisher unique ID
Punblisher
Name Char(45) Name of Publisher
Publisher Contact no. of
Phone int Publisher
Publisher Address of
Address Char(45) Publisher
Rack Detail
12
Field Data
Name Type Description
Rack ID in which items are
Rack ID int placed
Rack No. int Serial no. of rack
Limit
Field Data Descriptio
Name Type n
Member
Type Char(45) Type of Member
Limit of item
Limit Char(45) issued
Issue
Field Data Descriptio
Name Type n
Member unique
Member ID int ID
Date of Date of issuing
Issue Date item
Issue ID int Issue unique ID
Item Library
ISBN int number
13
6.0. Use Case Realizations
A use case diagram in the 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.
Here the use case of LMS is shown; different actors and their roles are defined:
System
addI tem
addMember
return
createRoles
Admini <<extend>> member
issue
<<extend>> Search
viewReport
accountI nfo
Librarian user
calculateFine
We talk about return scenario; Member returns the book to librarian, the
system will validate the member and the item that is issued, get return the
book calculate the fine and update the database. Return is connected to
member, means member will return the item(book) to librarian. There is a
relationship between issue and return, return and calculate fine. It is an
extends relationship. It means member will have to return the book after
issuing, but there is a possibility that he/she does not return the book. That is
why there is an extend relationship. After returning the book librarian
calculates the fine if there is a late submission fine will be added into the
account of the member. Here return is specific use case that is generalized
by issue use case. It means return is using some properties of issue
operation.
14
7.0 User Interface Design: NA
15