NATIONAL ENGINEERING COLLEGE, KOVILPATTI ANNA UNIVERSITY: CHENNAI 600 025 APRIL 2013 BOOK BANK MANAGEMENT SYSTEM A MINI PROJECT REPORT Submitted by N.Mano Princess(96210205029) in partial fulfillment for the award of the degree of BACHELOR OF TECHNOLOGY IN INFORMATION TECHNOLOGY
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
NATIONAL ENGINEERING COLLEGE, KOVILPATTI
ANNA UNIVERSITY: CHENNAI 600 025
APRIL 2013
BOOK BANK MANAGEMENT SYSTEM
A MINI PROJECT REPORT
Submitted by
N.Mano Princess(96210205029)
in partial fulfillment for the award of the degree
of
BACHELOR OF TECHNOLOGY
IN
INFORMATION TECHNOLOGY
NATIONAL ENGINEERING COLLEGE K.R.NAGAR, KOVILPATTI-628503
Bonafide record of work done in the CS66 Object
Oriented Analysis and Design Laboratory of the
NATIONAL ENGINEERING COLLEGE,
K.R. Nagar, during the year 2012-2013 by N.Mano
Princess
Register No: 96210205029
Staff in charge
Submitted to the practical examination held at NATIONAL
ENGINEERING COLLEGE, K.R.Nagar on
INTERNAL EXAMINER EXTERNAL EXAMINER
DATE:
S.NO EX.NO NAME OF THE EXPERIMENT
1 1 Foundation of Rational Rose
2 2 Problem Analysis and Project Planning
3 3 Software Requirement Specification
4 4 Use-Case Diagram
5 5 Activity diagram
6 6 Class Diagram
7 7 Sequence diagram
8 8 Collaboration diagram
9 9 State chart Diagram
10 10 Component and Deployment Diagrams
11 11 Implementation Of Book Bank Management System
1. FUNDAMENTALS OF RATIONAL ROSE SOFTWARE – A Study
AIM
To study about the fundamentals of Rational Rose Software.
INTRODUCTION
Models are constructed using views to depict different perspectives and diagrams to
depict a system’s building blocks. A model is a simplification of reality or the blue print of the
system. An Architectural view can be defined as a simplified description of a system from a
particular perspective or vantage point, covering particular concerns and omitting that are not
relevant to this perspective. Diagrams are the means by which we can visualize collections of
these abstractions.
VISUAL MODELING:
In the world today, we have business processes and computer systems. As software
professionals our challenge lies in mapping the two. That is where modeling comes in. Modeling
involves capturing the important real world things and mapping these things to computer
systems.
UNIFIED MODELING LANGUAGE:
The Language of visual modeling is the UML. It can be used to visualize, specify,
construct and document the artifacts of software system. It is a standard language that may be
understood by everyone dealing with the project, - customers, domain experts, analyst, designers,
implementers, testers, trainers and so on.
VIEWS:
A View is a perspective of the model that is meaningful to specific stakeholders. When you
construct models, you can choose to create only those views significant for that iteration of development
and of value to the project stakeholders. In Rose, you can create the following views:
Use-case View
Logical View
Process View
Component View
Deployment View
Figure 1.1 Rational Rose Environment
USE-CASE VIEW:
The Use-Case View is the heart of the other views because it specifies what the
system should do.
Includes the use-case model, which represents the system’s intended functions and
environment as seen by its users.
Serves as a contract between customer and developer.
Is essential to analysis and design and test activities.
Includes use-case diagram, use-case flow of events, and supplemental documentation. It
can also include activity diagrams.
Is the heart of other views because it represents the required behavior of the system.
LOGICAL VIEW:
The Logical View supports the functional requirements of the system.
Supports the functional requirements of the system, meaning the services the system
should provide its users.
Includes use-case realizations, class and interaction diagrams. It can also include state
chart and activity diagrams.
PROCESS VIEW:
The Process View addresses the performance, scalability and throughput of the
system.
Includes the threads and processes that form the system’s concurrency and synchronization
mechanisms.
Addresses the performance, scalability, and throughput of the system.
Is not necessary for a single processing environment.
COMPONENT VIEW (IMPLEMENTATION VIEW):
The Component View addresses ease of development, management of software
assets, reuse, and sub-contracting off-the-shelf components.
Describes the organization of static software modules(source code, data files,
components, executables and so on) in terms of packaging ad layering and configuration
management.
DEPLOYMENT VIEW:
The Deployment View addresses issues like deployment, installation and
performance.
Is used for distributed systems only and shows one deployment diagram.
Shows how the various executables and other runtime components are mapped to the
underlying platforms or computing nodes.
Addresses issues like deployment, installation and performance.
DIAGRAMS:
A Diagram is a graphical means to view a system’s parts including classes, interfaces,
collaborations, generalizations, and associations.
Using Rational Rose the following diagrams can be drawn to facilitate the development process.
Use-case diagrams
Activity diagrams
Interaction diagrams (collaboration and sequence)
Class diagrams
State chart diagrams
Component diagrams
Deployment diagrams
STAKEHOLDERS:
Software architect – Responsible for development of the entire project and needs to
understand all aspects of the system.
System Analyst – Identifies functionality (Actors and use cases) of the system based on
the user requirements.
Designer – Builds the system to meet the specification identified by the analyst,
generates the software.
End-User – ensures that the design of the system meets his/her requirements.
RATIONAL ROSE INTERFACE:
The Rational rose interface includes the following:
Browser
Diagram window
Diagram tool bar
Documentation window
Log window
Options window
BROWSER:
The browser allows textually viewing and navigating the views and diagrams in Rational
Rose. It displays the elements that are modeled.
DIAGRAM WINDOW:
The diagram window allows creating and updating graphical views of the current model.
DIAGRAM TOOL BAR:
The diagram toolbar includes the elements to build a diagram. Each diagram’s toolbar is
unique to that diagram. It is active only when the diagram is displayed.
DOCUMENTATION WINDOW:
The documentation window is used to create, view or modify text that explains a selected
item within a diagram.
LOG WINDOW:
The Log window reports progress, results, and errors. For E.g. Code generation commands
post progress and error messages to this window.
OPTIONS WINDOW:
The Options window is used to set all of the faults for modeling. It applies new settings to
future additions made to a diagram.
RESULT
Hence the fundamentals of Rational Rose Software were studied.
2. PROBLEM ANALYSIS AND PROJECT PLANNING
AIM
The basic aim of planning is to look into future, identify the activities that need to be done
to complete the project successfully and plan the scheduling and resource allocation for these
activities.
DESCRIPTION
Planning is the most important management activity. The input to the planning activity is
the requirements specification, the output of this space is the project plan, which is a document
describing the different aspects of the plan. The project plan is the instrument in driving
development process to remaining phases.
ISSUES OF PROJECT PLAN
The major issues the project plan addresses are:
1. Cost Estimation
2. Schedule and milestones
3. Personnel Plan
4. Software Quality Assurance Plans
5. Configuration Management Plans
6. Project Monitoring Plans
7. Risk Management
8.
DOCUMENTS
1. Cost Estimation
2. Schedule
3. Personnel Plan
RESULT
Thus the project-planning phase of software development was studied
3. SOFTWARE REQUIREMENT SPECIFICATION
1. INTRODUCTION
Book bank system mainly deals with issuing and returning the book. During the time of
issuing the book students details can be collected and also membership can be provided. The
book should be returned with in the due date.
1.1 Purpose
The purpose of this document is to present a detailed description of the book bank system.
The system will explain the purpose and features of the system the interfaces of the system what
the system will do under constraints which it must operate and how the system will react to
external stimuli.
1.2 Document convention
Director: The ultimate authority in the staff hierarchy of the book bank.
Member: Any person can register with the book bank.
HTML: Used to create web page.
1.3 Intended audience and Reading suggestion
The document can be intended by different form of reader such as manager who can
monitoring about the status of book and the user can access a book and can use such a book
within the due date. The authority for concern books will put a fine for a book if a book will not
return within the due date.
1.4 Project scope
All kind of transaction details can be maintained on online interface. Each member is
provided with the unique user id at the time of registration as a members.
2. OVERALL DESCRIPTION
2.1 Product perspective
This project is a self contained one for enabling a book bank organization to be connected
with its student, the students can check for availability of books etc.,
2.2 Product Features
This system functions with a database at a back end, a keeping track of its members dues
and payments and also its available resources. Every students who is a member only need a web
browser to connect to this system.
2.3 User classes and characteristics
Marketing staff: One who keeping track of the books.
Accessors: One who access and retrieving books.
2.4 Tools to be used
Visual basic and Microsoft access.
3. SYSTEM FEATURES
3.1 System description and priority
Allow a students who become a member to login using a unique id issued at a time of
registering as a member and after logging in the member can browse through available books
and make request accordingly.
3.2 Stimuli or response sequence
Whenever a user wishes to get books he/she check availability by logging in.When the
request is made the director of the book bank divides on granting.The request of book after
checking the member details of due in returning previous books.
4. NON-FUNCTIONAL REQUIREMENTS
4.1 Performance requirements.
The web interface should be able to support multiple users trying to log in
simultaneously.
4.2 Safety requirements.
The student details should made available in the database and must be updated
Every time a book is issued or returned or some kind of payment takes places to prevent errors
4.3 Security requirements.
The member can only access certain details from the database. He/she should
Not modify the database nor has any of its information corrupted.
MODULES
1. User registration module
2. Book details module
3. Transaction module
4. Membership module
USER REGISTRATION MODULE
This module includes the registration and login. The new user can easy to register to
become a member and the regular user can easily transact books. Admin can able to view all
such transaction.
BOOK DETAILS
This module includes details about book name, author name, number of books issued and
number of books available in book bank and number of books remaining. The user can easy to
search about status of book.
TRANSACTION DETAILS
Transaction detail module includes detail about issuing, returning and renewal of books.
During issuing process the due time should be given to the customer. If the returning date is
exceeds the member should pay a fine.
MEMBERSHIP DETAILS
It includes the detail about the membership including name, course, year, rollno. It
contain separate details for students and staff.
4. USE CASE DIAGRAM
AIM
To identify use cases and to develop the use case model using UML use case diagrams.
DESCRIPTION
A Use Case is functionality provided by the system, typically described as verb + object
(e.g. Register Car, Delete User). Use Cases are depicted with an ellipse. The name of the use
case is written within the ellipse.
Use-case diagram is used to indicate the existence of use-cases, actors and their
relationships and the courses of actions that can be performed. It is used to illustrate the static
use case view of a system. Use-case diagram is a visual representation of what the customer
wants the system to do. It shows a sequence of actions a system performs that yields an
observable result and is of value to a particular actor.
USE-CASE:
A use-case is a relatively end-to-end process description that typically includes many
steps or transactions; it is not normally an individual step or activity in a process. Use-cases are
scenarios for understanding system requirements. Use-cases are described textually in a
document called a flow of events.
ACTOR:
An actor is a user playing a role with respect to the system. The actor is the key to
finding the correct use-cases. A single actor may perform many use-cases. An actor can be
external system that interacts with the system either by giving or receiving information or both.