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.

RELATIONSHIPS:

There are 4 types of relationships.

Communication

Uses

Extends

Generalization

ELEMENTS OF A USE CASE DIAGRAM:

Actor Use Case

Relationship Extends

Generalization

 

Use Case Diagram Elements

 

 

Use Case Diagram Connectors

 

 

 

 

Use Case Diagram for Book Bank Management System

List of Actors:

Users

List of Use cases:

Login

Registration

Add Book Details

Book Search

Issue Book

Return Books

Renewal Books

Membership

The following UML use-case diagram is the diagram drawn with the help of IBM Rational

Rose Software that visualizes the use-case scenario of our

Login

Book Search

Issue Books

Return Books

Renewal Books

Membership

Registration

Add Book Details

Users

Fig : Use-Case Diagram depicting all the components involved in the Book Bank system Project

RESULT:

Thus the Use Cases were identified and the Use Case model was developed using UML

Use Case diagram.

5. ACTIVITY DIAGRAM

AIM:

To identify the business activities and to develop an UML activity diagram.

DESCRIPTION:

An Activity diagram in the use-case model can be used to capture the activities in a use-

case. It is essentially a flowchart, showing flow of control from activity to activity. It represents

the dynamics of the system.

The workflow of a use-case describes that which needs to be done by the system to

provide the value the served actor is looking for. It consists of a sequence of activities that

together produce something for the actor. The workflow often consists of a basic flow and one

or several alternative flows.

Activity diagrams can also be used in business modeling and to model the workings of an

operation, an object, or anything that involves modeling the sequential steps in a computational

process.

ELEMENTS OF AN ACTIVITY DIAGRAM:

State Activity

if user is new user

LoginRegister

Return Books

Search BookView Details

Is return date exceeds

Pay the fine Return the Books

Is book available

Search for new book

Receive Books

Update Details

Dispatch Login

NOYES

NO YES

YES NO

Start State Final state

State Transition Swim lane

SYNCHRONIZATION BAR

TOOLBOX ELEMENTS AND CONNECTORS:

  

Activity Diagram Elements

 

 

Activity Diagram Connectors

 

Fig : Activity diagram depicting all the activities involved in the Book Bank system project

RESULT

Thus the business activities were identified and an UML activity diagram was developed.

6. CLASS DIAGRAM

AIM

To identify the conceptual classes and to develop a domain model with UML class diagram.

DESCRIPTION

The Class diagram captures the logical structure of the system - the classes and things

that make up the model. Class diagram shows the static view of the system and are modeled in

the Logical view under the appropriate use-case realization. It shows a set of classes, interfaces

and their relationships.

A Class diagram is made up of following basic elements

Classes

Relationships

Associations

Aggregations

Generalizations

A Class is a set of objects that share the same attributes, operations, relationships, and

semantics. In the UML, a class is represented by a compartmentalized rectangle.

A relationship is a semantic connection among elements. A class diagram has above mentioned

three types of relationships.

An association is the most general relationship and indicates communication only. In

the UML, a solid line with or without an arrow represents an association.

An aggregate association is a type of association where a whole is related to its part(s).

In the UML, an aggregation is represented by a solid line with or without an arrow on one end

and hollow diamond at the end of the aggregate (Whole).

Associations in a class diagram can be further defined by

Association Name

Role Names

Multiplicity

ASSOCIATION NAMES:

An association name is a label that clarifies the meaning of the association. This name is

placed along the middle of the association line. These names are usually verb phrases.

ROLE NAMES:

A role name is a label that specifies the “face” the class plays in an association. This

name is placed along the association line nearest the class it modifies. These names are usually

noun.

Multiplicity is the number of instances a class relates to an instance of another class.

Multiplicity is defined at both ends of the association line.

A generalization is a parent/child relationship where one class shares the structure and

behavior of one or more classes. In the UML, a solid line with a hollow arrow represents a

generalization relationship.

TOOLBOX ELEMENTS AND CONNECTORS:

 Class Diagram Elements  Class Diagram Connectors

 

 

Example- Class Diagram for Book Bank Management System

List of Classes:

Login

Member

Book

Database

List of Attributes:

Username

Password

Rollno

Course

Branch

Year

Book Id

Book Name

Date Of Issue

Date Of Return

List of Methods:

Search

Add

Issue

Renewal

Return

View member details

membername-stringid-numberdepartment-textyear-number

return()renewal()search()

Loginusername-stringpassword-string

search()issue()return()renewal()view member details()

n

1

n

1

Databaseissue detailsmemeber detailsbook details

add()delete()

n

1

n

1

n

1

n

1

Bookbook id-numberbook name-texxtauthor-textedition-numberpublication-textNumber of books

search()

n

1

n

1

1

n

1

n

Fig : Class diagram depicting all the activities involved in the Book Bank System project

RESULT

Thus the conceptual classes were identified and a domain model with UML class diagram

was developed.

7. SEQUENCE DIAGRAM

AIM

To find the interaction between objects and represent them using UML Sequence

diagrams.

DESCRIPTION

Sequence diagram is a structured representation of behavior as a series of sequential steps

over time. It is used to depict work flow, message passing and how elements in general cooperate

over time to achieve a result.

It shows the objects participating in the interaction by their “lifelines “and the messages

that they send to each other.

A Sequence diagram made up of basic elements

Actors

Objects

Messages

Lifelines

Activation Bar/Focus of Control

In a Sequence diagram, classes and actors are listed as columns, with vertical lifelines

indicating the lifetime of the object over time.

TOOLBOX ELEMENTS AND CONNECTORS :

Sequence Diagram Elements Sequence Diagram Connectors 

 

EXAMPLE-SEQUENCE DIAGRAM FOR BOOK BANK MANAGEMENT SYSTEM

Administrator Member Book Database

Member database

Server

1: Login password

3: Login accepted

4: Insert student Details

5: Insert book details

6: Enter book details7: Search book

8: Return

9: Issue book

10: Update details

11: Details updated

12: Book issued

13: Return book

14: Update details

15: Details updated

16: fine collected

17: Search book

18: Book searched

19: Available or not

20: Update book details

21: Book details updated

22: Logout Request

23: Logout

2: Validate

Fig : Sequence diagram depicting all the activities involved in the Book Bank System project

RESULT:

Thus the interactions between objects were identified and UML collaboration

diagrams were developed

8. COLLABORATION DIAGRAM

AIM:

To identify the interaction between the objects and draw them using UML collaboration

diagram.

DESRIPTION:

A Collaboration diagram shows the interactions between elements at run-time in much

the same manner as a Sequence diagram. However, Collaboration diagrams are used to visualize

inter-object relationships, while Sequence diagrams are more effective at visualizing processing

over time.

A Collaboration diagram is made up of following basic elements.

Actors

Objects

Links

Messages

A link is the pathway of communication between objects on a collaboration diagram. In

the UML, a solid line between two objects represents an object link.

A message is the communication between two object that triggers an event. In the UML,

a labeled arrow above the link in a collaboration diagram represents an object message.

Steps to generate Collaboration Diagram:

1. Press F5 to auto generate the collaboration diagram and arrange the diagram

elements.

Note:

Since collaboration and sequence diagrams are semantically equivalent, we can

automatically generate one diagram from the other by pressing F5.

TOOLBOX ELEMENTS AND CONNECTORS:

Collaboration Diagram Elements Collaboration Diagram Connectors

 

 

EXAMPLE-COLLABORATION DIAGRAM FOR BOOK BANK MANAGEMENT SYSTEM

Administrator

Book Database

Member

Member database

Server

2: Validate

1: Login password22: Logout Request

3: Login accepted23: Logout

5: Insert book details10: Update details14: Update details18: Book searched

11: Details updated15: Details updated

16: fine collected19: Available or not

21: Book details updated

6: Enter book details

9: Issue book13: Return book17: Search book

12: Book issued

7: Search book

8: Return

Fig : Collaboration diagram depicting all the activities involved in theBook Bank System project

RESULT

Thus the interactions between objects were identified and UML collaboration diagrams

were developed.

9. STATE CHART DIAGRAM

AIM

To study and draw the State chart Diagram.

DESCRIPTION

A State chart diagram is a view of a state machine that models the changing behavior of

a state. State chart diagrams show the various states that an object goes through, as well as the

events that cause a transition from one state to another.

STATECHART DIAGRAM MODEL ELEMENTS:

The common model elements that Statechart diagrams contain are:

States

Start and end states

Transitions

Entry, do, and exit actions

STATE

A state represents a condition during the life of an object during which it satisfies some

condition or waits for some event.

START AND END STATES

Start and end states represent the beginning or ending of a process.

Start State End State

TRANSITIONS

A state transition is a relationship between two states that indicates when an object can

move the focus of control on to another state once certain conditions are met. In a state chart

diagram, a transition to self element is similar to a state transition. However, it does not move

the focus of control. A state transition contains the same source and target state.

Transition to self

Transitions between the states

ACTIONS IN A STATECHART DIAGRAM:

Each state on a statechart diagram can contain multiple internal actions. An action is best

described as a task that takes place within a state. There are four possible actions within a state:

On entry

On exit

Do

On event

STEPS TO CREATE THE STATE CHART DIAGRAM:

A state chart diagram is usually placed under the Logical View package. Right-click on

the Logical View package and select New>Statechart Diagram to create a Statechart Diagram.

Name your diagram and then double-click on the name to open the diagram work area.

TOOLBOX ELEMENTS AND CONNECTORS:

EXAMPLE-SEQUENCE DIAGRAM FOR BOOK BANK MANAGEMENT SYSTEM

 

State Machine Diagram Elements

 

 

State Machine Diagram Connectors

 

 

 

RESULT:

Thus the State chart Diagram was studied and drawn.

10. COMPONENT AND DEPLOYMENT DIAGRAMS

AIM

To study and draw the Component and Deployment Diagrams.

COMPONENT DIAGRAM:

A Component is a code module. Component diagrams are physical analogs of class

diagram. A Component diagram illustrates the pieces of software, embedded controllers, etc.

that will make up a system. A Component diagram has a higher level of abstraction than a Class

diagram - usually a component is implemented by one or more classes (or objects) at runtime.

They are building blocks, such that eventually a component can encompass a large portion of a

system.

Component diagrams fall under the category of an implementation diagram, a kind of

diagram that models the implementation and deployment of the system. A Component

Diagram, in particular, is used to describe the dependencies between various software

components such as the dependency between executable files and source files. This

information is similar to that within make files, which describe source code dependencies and

can be used to properly compile an application.

ELEMENTS OF COMPONENT DIAGRAM:

COMPONENT

A component represents a software entity in a system. Examples include source code

files, programs, documents, and resource files. A component is represented using a rectangular

box, with two rectangles protruding from the left side, as seen in the image to the right.

DEPENDENCY

A Dependency is used to model the relationship between two components. The

notation for a dependency relationship is a dotted arrow, pointing from a component to the

component it depends on.

EXAMPLE DIAGRAM:

The diagram below demonstrates some components and their inter-relationships.

Assembly connectors 'link' the provided interfaces supplied by Product and Customer to the

required interfaces specified by Order. A dependency relationship maps a customer's associated

account details to the required interface, 'Payment', indicated by Order.

DEPLOYMENT DIAGRAM:

Deployment diagrams show the physical configurations of software and hardware. A

Deployment diagram shows how and where the system will be deployed. Physical machines

and processors are reflected as nodes, and the internal construction can be depicted by

embedding nodes or artifacts. As artifacts are allocated to nodes to model the system's

deployment, the allocation is guided by the use of deployment specifications.

EXAMPLE DIAGRAM:

The following deployment diagram shows the relationships among software and

hardware components involved in real estate transactions

The physical hardware is made up of nodes. Each component belongs on a node.

Components are shown as rectangles with two tabs at the upper left.

LOGICAL ARCHITECTURE AND UML PACKAGE DIAGRAMS:

The software architecture is a fairly large topic: we will only introduce one possible

solution (the most common) here.

As we have finished the requirement analysis part of the first iteration and are ready to

move on to design we can look at a larger scale.

The design of a typical OO system is based on several architectural layers, such as a UI

layer, an application logic (or "domain") layer, and so forth.

LOGICAL ARCHITECTURE USING A UML PACKAGE DIAGRAM:

A UML package diagram provides a way to group elements. A UML package can group

anything: classes, other packages, use cases, and so on. Nesting packages is very

common.

It is common to want to show dependency (a coupling) between packages so that

developers can see the large-scale coupling in the system.

A UML package represents a namespace so that, for example, a Date class may be

defined in two packages. If you need to provide fully-qualified names, the UML notation

is, for example, java::util::Date in the case that there was an outer package named "java"

with a nested package named "util" with a Date class.

Guidelines

The responsibilities of the objects in a layer should be strongly related to each

other and should not be mixed with responsibilities of other layers. For example,

objects in the UI layer should focus on UI work, such as creating windows and

widgets, capturing mouse and keyboard events, and so forth. Objects in the

application logic or "domain" layer should focus on application logic, such as

calculating a sales total or taxes, or moving a piece on a game board.

UI objects should not do application logic. For example, a Java Swing JFrame

(window) object should not contain logic to calculate taxes or move a game piece.

And on the other hand, application logic classes should not trap UI mouse or

keyboard events. That would violate a clear separation of concerns and

maintaining high cohesion : basic architectural principles

THE MODEL-VIEW SEPARATION PRINCIPLE

The Model-View Separation principle states that model (domain) objects should not have

direct knowledge of view (UI) objects. So, for example, a Register or Sale object should not

directly send a message to a GUI window object Process Sale Frame, asking it to display

something, change color, close, and so forth.

RESULT:

Thus the component and deployment diagrams are studied and drawn.

11. IMPLEMENTATION OF BOOK BANK MANAGEMENT SYSTEM

AIM

To develop an application to implement the technical services, domain objects and user

interface layer for book bank system.

PROBLEM STATEMENT

Book bank system is where the books can be collected every semester and must be

returned at the end of semester. The system must have options for new member to enroll for

membership by paying deposit. A provision for getting three books per semester. Membership

can be renewed by using the register number. The deposit must be refunded on termination of

membership .A database is maintained to guide the issuer to track the details of students. Search

option must be provided so that the member can for the availability of particular books.

Form 1

FORM 2

FORM 3

FORM 4

FORM 5

FORM 6

FORM 7

FORM 8:

FORM 9:

Form1

Private Sub Command1_Click()

Form3.Show

End Sub

Private Sub Command2_Click()

Form2.Show

End Sub

Form2

DB As Database

Dim S As Recordset

Private Sub Command1_Click()

S.AddNew

S(0) = Text1.Text

S(1) = Text2.Text

S(2) = Text3.Text

S(3) = Text4.Text

S(4) = Text5.Text

S(5) = Text6.Text

S.Update

MsgBox "SUCCESSFULLY REGISTERED"

End Sub

Private Sub Command2_Click()

Text1 = " "

Text2 = " "

Text3 = " "

Text4 = " "

Text5 = " "

Text6 = " "

End Sub

Private Sub Command3_Click()

Form1.Show

End Sub

Private Sub Form_Load()

Set DB =

OpenDatabase("G:/OOAD/REGISTER.MDB")

Set S = DB.OpenRecordset("REG")

End Sub

Form3

Dim DB As Database

Dim S As Recordset

Private Sub Command1_Click()

S.MoveFirst

While Not S.EOF

If S(0) = Text1.Text And S(5) = Text2.Text

Then

Form4.Show

Exit Sub

End If

S.MoveNext

Wend

MsgBox ("INVALID USER")

End Sub

Private Sub Command2_Click()

Form1.Show

End Sub

Private Sub Form_Load()

Set DB =

OpenDatabase("G:/OOAD/REGISTER.MD

B")

Set S = DB.OpenRecordset("REG")

End Sub

Form4

Private Sub Command1_Click()

Form5.Show

End Sub

Private Sub Command2_Click()

Form7.Show

End Sub

Private Sub Command3_Click()

Form9.Show

End Sub

Private Sub Command4_Click()

Form8.Show

End Sub

Private Sub Command5_Click()

Form10.Show

End Sub

Private Sub Command6_Click()

Form6.Show

End Sub

Form5

Private Sub Command1_Click()

S.AddNew

S(0) = Text1.Text

S(1) = Text2.Text

S(2) = Text3.Text

S(3) = Text4.Text

S(4) = Text5.Text

S(5) = Text6.Text

S.Update

MsgBox "ADDED SUCCESSFULLY"

End Sub

Private Sub Command2_Click()

Text1 = " "

Text2 = " "

Text3 = " "

Text4 = " "

Text5 = " "

Text6 = " "

End Sub

Private Sub Command3_Click()

Form4.Show

End Sub

Private Sub Form_Load()

Set DB =

OpenDatabase("G:/OOAD/BOOK.MDB")

Set S = DB.OpenRecordset("BKDETAIL")

End Sub

Form6

Private Sub Command1_Click()

S.MoveFirst

While Not S.EOF

If S(1) = Text1.Text And S(2) = Text2.Text

And S(3) = Text3.Text Then

MsgBox "BOOK IS AVAILABLE"

Exit Sub

End If

S.MoveNext

Wend

MsgBox "BOOK NOT AVAILABLE"

End Sub

Private Sub Command2_Click()

Form4.Show

End Sub

Private Sub Form_Load()

Set DB =

OpenDatabase("G:/OOAD/BOOK.MDB")

Set S = DB.OpenRecordset("BKDETAIL")

End Sub

Form7

Private Sub Command1_Click()

S.AddNew

S(0) = Text1.Text

S(1) = Text2.Text

S(2) = Text3.Text

S(3) = Text4.Text

S(4) = Text5.Text

S(5) = Text6.Text

S.Update

MsgBox "BOOK ISSUED"

End Sub

Private Sub Command2_Click()

Form4.Show

End Sub

Private Sub Form_Load()

Set DB =

OpenDatabase("G:/OOAD/ISSUE.MDB")

Set S =

DB.OpenRecordset("ISSUEDETAIL")

End Sub

Form8:

Private Sub Command1_Click()

S.MoveFirst

While Not S.EOF

If Val(Text1) = S(0) Then

Text2 = S(1)

Text3 = S(2)

Text4 = S(3)

Text5 = S(4)

Text6 = S(5)

Exit Sub

End If

S.MoveNext

Wend

MsgBox "BOOK RETURNED'"

End Sub

Private Sub Command2_Click()

Form4.Show

End Sub

Private Sub Form_Load()

Set DB =

OpenDatabase("U:/OOAD/ISSUE.MDB")

Set S =

DB.OpenRecordset("ISSUEDETAIL")

End Sub

Private Sub Text8_Change()

Text8 = Val(Text7.Text) - Val(Text6.Text)

End Sub

Form9:

Private Sub Command1_Click()

S.MoveFirst

While Not S.EOF

If Val(Text1) = S(0) Then

Text2 = S(1)

Text3 = S(2)

Text4 = S(3)

Text5 = S(4)

Text6 = S(5)

Exit Sub

End If

S.MoveNext

Wend

End Sub

Private Sub Command2_Click()

Form4.Show

End Sub

Private Sub Form_Load()

Set DB =

OpenDatabase("U:/OOAD/ISSUE.MDB")

Set S =

DB.OpenRecordset("ISSUEDETAIL")

End Sub