SE Lab Manual NEW

1 IT6413 SOFTWARE ENGINEERING LAB MS.M.ABINAYA, LECT/IT

1. COURSE REGISTRATION SYSTEM

OBJECTIVE:

To analyze, design and develop a System for Course Registration using Rational Rose software.

1. Problem analysis and project planning

1.1 Introduction

This software is des igned in such a way that it receives the name and other particulars

from the student. Based on marks the student has scored the list of poss ible branches that

will accommodate for the student will be displayed. Only work for the student is he has to fill

the form and submit it.

1.2 Objectives

The ult imate objective of this software is to eliminate hass les that the student overcomes

while register ing him. This software will reduce the paper work. This also reduces the time

de lay.

1.3 Scope

The student is firs t requested to fill the form. This form will conta in important particulars

of the student like his name, DOB, preferred b ranch, his marks. Once the student fills it, a

unique id number be provided. An important thing w i t h i n this is to dec ide made to

payment to opt by the student. It may be either the demand draft or credit card information.

As soon as student registered then the number of seats available displayed.

1.4 Problem Statement

As project developers we deve loped a new course registrat ion sys tem to replace the

exist ing manua l registrat ion since manua l system are prone to errors and take more t ime.

The system made by user friendly and reduce the burden of users. Our system can

be made ava ilable even in the webs ite of our college.

Students can easily register the course in our system without any difficulty and can

easily understand and also time taken for registrat ion is less when compared to manua l

registrat ion. Options are given to the student to select the ir elective and a lso it shows the number of papers ava ilable a long with the number of student who have registered and a lso the number of

days for part icular e lect ive per semester also displayed at the s ide. This makes your work easier

for you than when you register manua lly s ince you need to make a copy of HOD, staff separately

that even if one is missed the who le process is to be redone.


Your information will be stored as soon as you registered. As you can see registrat ion

form aga in separate id and password to see the registrat ion form and also number of forms

updated this is to prevent from unauthorized access.

They can see the number of students registered for the particular paper. So that if the

registrat ion does not satisfy the number then part icular course is a bonded.

Fees structure for the course too is provided on the part icular paper so that the student

may get the proper information about the fees too. Here database administrator keeps record

of every database and he updates the database whenever regis trat ion takes place. Administrator

provides id for students and staff to access the system. Billing information if necessary is also

updated.

This is fast when compared to manua l intervent ion s ince separate form should be

provided to HOD, staff, administrator which takes more time for register ing and even if

student wants to view the record it takes more time where as the system des igned does not need

any manua l intervention.

2. Problem statement(Use case) analysis

2.1 Indentified use cases

i. Login

ii. Registration

iii. Course details

2.2 Identified Actors

i. Students

ii. Staff

iii. Database

iv. Database Administrator


2.3 Use Case Diagram

2.4 Design of Course Registration System

3.1 Des ign Docume ntation

1. Login

1.1 Brie f description:

This use case describes how the user logs into the system.

1.2 Flow of events:

1.2.1 Basic flow:

1. The system requests the actor to enter the name and the password.

2. The actor enters the name and the password.

3. The system va lidates the entered name and the password and logs the actor in to the

sys tem.

1.2.2 Alternative flow:

1. If in the basic flow the actor enters the inva lid name or password the display an

error message.


2. The actor can choose either to return to the beginning of the bas ic flow or cancel the

login at which point use ends.

1.3 Pre condit ions:

None

1.4 Post condit ions:

The use case was successful and the actor is now logged into the system. If not the

system state is unchanged.

2. Registrat ion


The student uses this use case for registrat ion.

2.2 Flow of events:

2.2.1 Basic f low:

1. The actor asks for the registrat ion form.

2. The registrat ion form asks for the students details.

3. The actor enters the details .

4. The form control checks for the validat ion. It will check for the elect ive details( i.e.

whenever the e lective preferred by the student is available)

5. If the contents are valid then the details will be stored in the database and confirmation

message will be displayed.


1. If the e lect ive preferred by the student is not available the appropriate message will be

displayed.

2. If the registrat ion form ids complete then the appropriate message is displayed.

3. The student will have now registered the form aga in.

2.3 Pre Condit ion:

The adminis trator must be logged on to the system.

2.4 Post Condit ion:

If the use case was successful the student he/she can come out of the use case of if

the registrat ion was not successful then the student can apply for the registrat ion aga in.


3. Course Details:


This use case is starts when the user wished to see about the elective.

3.2 Flow of events:

3.2.1 Basic f low:

This use case starts when the user wishes to see about the elective deta ils of the course.

The user will, se lect the course.

1. The course will va lidate the request.

2. After va lidat ion the form control will display the request deta ils.


If the user starts for the deta ils of the elective that is not offered then the error

message will be displayed.

3.3 P re Condit ion:

The actor will need to have successfully logged in.


If the actor has successfully seen the course details then he/she come out of use case

else try.

SEQUENCE DIAGRAM

1. LOGIN


2. REGISTRATION


3. COURSE DETAILS

COLLABORATION DIAGRAM

1. LOGIN


2. REGISTRATION

3. COURSE DETAILS


STATE CHART DIAGRAM

CLASS DIAGRAM

1. LOGIN

2. REGISTRATION


3. COURSE DETAILS

COMPONENT DIAGRAM


SOURCE CODE

1. Login

Option Explicit

Public NewProperty As welcome_window

Public NewProperty2 As welcome_window

2. Registratio n

Option Explicit

Public NewProperty As control_form

Public _ _ As error_message

3. Course deta ils

Option Explicit

Public NewProperty As course_form_control

RESULT:

This project was carried out in a sequential manner to design and implement the

COURSE REGISTRATION SYSTEM. Thus the outcome of the project is efficient. The

COURSE REGISTRATION SYSTEM caters the varied requirements of the user to perform

various options.


2. STUDENT MARK ANALYZING SYSTEM

OBJECTIVE:

To analyze, design and develop code for Student Mark Analysis system using Rational

Rose software.

Problem analysis and project planning

1.1 Introduction

Student mark ana lyzing sys tem has been des igned to carry out the mark analysis process

i n a n ed uc a t io na l inst itut ion. The results of respective departments can be efficient ly

computed without much of manua l involvement.

1.2 Objectives

The purpose of this document is to define the requirements of mark ana lyze is system.

This system reduces manua l work to great extent. The mark ana lysis is carried out by the

system in an effic ient manner.

1.3 Scope

This system is very essentia l for every educat iona l institut ion as it reduces man power.

This system can be used for all kinds of educationa l institut ions to evaluate and ana lyze the

marks and generate reports o f spec ified criter ia.


For analyzing the marks obtained by students in an educat iona l institut ion. We are tasked

to build up student mark ana lyzing system.

This is done to replace the manua l entering and processing of marks which are error

prone and tedious. This sys tem also ma inta ins information about student.

The system will have a Windows based desktop interface to a llow the faculty to enter

marks obtained by the students, update them and generate var ious reports.

For security reasons, the adminis trator and faculty only can update the marks and

other information. First the user needs to login to the system for accessing it. The system

will retain information on a ll the students and the institut ion. The system ana lyses the marks

and generate the result repor ts. The marks and info rmation about the students are stored

in a database and the sys tem works with the database.

The faculty can enter the marks and student information through a visua l environment.

The updated details are stored in the database. The system generates the overa ll result by

ana lyzing the marks. Mark ana lyzer monitors this process. The applicat ions r un by the mark

ana lyzer.

The tr ia l for illega l updating would render the system to be locked. One of the most

important features of the sys tem is creating reports based on the given criteria.


The user can create the following reports :

Overa ll C lass, Department result, Individua l student result, Toppers list, Arrears list and

Improvement rate for the academic year report has to be generated by enter ing the register

number of the student. These reports can also be viewed by the management and placement

officers. The administrator is respons ible for adding, delet ing student deta ils form the system

and updating the marks to the system with the externa l quer ies. So, the system design will

generate reports automatically and there will be no need for manua l intervention.

2. Problem statement (Use case) analysis

2.1 Ident if ied use cases

i Login:

This use case describes how a user logs in to the mark ana lyzing system.

ii Marks entry:

This use case allows faculty to enter the marks into the student table.

iii Mark analys is :

This use case describes how the system generates the overa ll result by

ana lyzing the marks.

iv Maintain s tudent information:

This use case allows the administrator to ma inta in the student information and

it a lso inc ludes adding, changing and delet ion of information about the students from

the sys tem.

v Create result report:

This use case allows the system to generate var ious reports based on the criter ia

specified by the user.

2.2 Ident if ied Actors

i Faculty:

The person is respons ible for enter ing and updating the marks obtained by the

students.

ii Adminis trator:

The person i s respons ible for ma intaining student information in the sys tem.

iii Database :

The database that contains a ll the information about the student and the ir marks.

iv Mark analyzer:

The person is respons ible for monitor ing the mark ana lyzing process.


v Stude nt:

Details about the students are entered into the system so that the student can

view the results and reports.

vi Placement Officer:

The placement officers can also view the reports based on the criter ia spec ified.

2.3 USE CASE DIAGRAM


3. Design of Students Mark analy zing System

3.1 Design Documentation

1. Login

1.1 Brie f descript ion:

This use case describes how the user logs into the Marks Ana lyzing System (MAS).

1.2 Flow of events:

1.2.1 Basic flow:

This use case starts with the actor wishes to log in to the MAS.

1. The system requests the actor to enter the ir name and password.

2. The actor enters their name and password.

3. The system va lidates the ent ire name and password and logs the actor into the

sys tem.


1. Inva lid name and password.

2. If in Basic flow the actor enters and inva lid name and password, the system

displays an error message. The actor can choose to either return to the beginning

of bas ic flow or cancel the login at which point the use case ends.

1.3 Pre conditions:

None.


If the use case was successful, the actor is now logged into the system, if not, the

system status unchanged.

2. Marks Entry


This use case allows the faculty to enter the marks into the student table.

2.2 Flow of events:

2.2.1 Basic f low:

This use case starts when the faculty wishes to enter the marks obtained by the student in

different subjects.

1. The system retrieves and displays the student table. If a student table does not exist, it

creates a new one. The names of the student and reg. no cant be changed by the faculty.

2. Once the faculty has entered marks, the sys tem saves the table and adds it to the

database.


2.2.2 Alternat ive f low:

i. Invalid Marks:

In Bas ic flow, if inva lid marks are entered, the system displays an error

message and prompts for a va lid mark. The faculty must enter a va lid mark or

cancel the operat ion in which case, the use case ends.

ii. Marks already entered:

If in basic flow, the student mark has already been entered, the sys tem displays the

read only copy of marks and informs the faculty tha t the mark has a lready been entered.

So, no changes can be made to it. The faculty acknowledges the message and the use case

ends.

iii. Fields le ft empty:

If in basic flow, the fie ld is left empty, the system prompts the faculty to correct the

error. The faculty can enter the mark or mark the student as absent.

2.3 P re Condition:

The faculty must be logged on to the system before the use case begins.


If the use case was successful, the student mark is saved to sys tem otherwise the system

status is unchanged.

3. Ma rk Ana lys is

3.1 B rie f desc ript io n:

This use case describes how the system generates overa ll results by ana lyzing the marks,

Marks Ana lyzer monitors this process.

3.2 Flow of events:

3.2.1 Basic f low:

This use case begins when the mark ana lyzer wishes to calculate the tota l percentage

of marks obtained by the students.

1. The system retrieves and displays the current student marks information from the

database.

2. The system calculates the total marks and percentage obtained by all the students.

3. The results are stored in the database.

4. The use case ends when a ll the students marks have been processed.


3.2.2 Alternat ive flow:

i. Marks unavailable :

If in bas ic flow, the information about student marks could not be located, the

system displays error message and use case ends.

ii. Results already calculated:

If in basic flow, the result has already been calculated, the system displays the

copy of the information and informs mark ana lyzer that marks have a lready been processed. The mark ana lyzer acknowledges the message and the use case ends.

3.3 Pre Condit ion:

The mark ana lyzer must be logged on to the system before this use case begins.


If the use case was successful, the processed mark information is saved to the system

otherwise the system status is unchanged.

4. Maintain Student Information

4.1 Brief descript ion:

This use case allows the administrator to mainta in the student information. This

inc ludes add ing, changing and deleting information from the system.

4.2 Flow of events:

4.2.1 Basic flow:

This use case starts when the administrator wishes to change, add or delete student

information from the system.

1. The s ys te m reques ts t he admin is tra to r t o spec i fy t he funct ion that the

adminis trator would like to perform.

2. Once the administrator provides the requested information, one of the

sub flows is executed. If adminis trator s e le c t s a d d a student, t he n the add a s tudent sub

flow is executed. If administrator selects update student information, then the update student

information sub flow is executed. If the administrator selects delete a student, then the

delete a student sub flow is executed.

Add a Student:

1. The System requests the adminis trator to enter the student information. This

inc ludes name, department, year, semester, age and sex.

2. Once the administrator provides the requested information, the

system generates and ass igns a unique regis ter number to the student. Now the


student is added to the system database.

3. The system provides the adminis trator to write the new regis ter number.

Update Student Information (USI):

1. The system requests the administrator to enter the register number.

2. Administrator enters the register number and then the system retrieves and

displays the student mark information.

3. Administrator can make changes to the marks

4. The system updates the student information to the database.

Dele te a Stude nt:

1. The system requests the administrator to enter the register number.

2. Administrator enters the register number and then system retrieves and

displays the information.

3. The system prompts administrator to confirm deletion of the student.

4. Administrator verifies the deletion.

5. The system deletes the student from the database.


i. Student not found:

If the Update Student Information (USI) or delete a s tudent sub flow student with

specific with spec ific register number does not exist, then the System displays a error

message. The System administrator can reenter or cancel at which point the use case ends.

ii. Irrelevant data:

If in the add a student sub flow inva lid information is entered, the system display

an error message so that the administrator can reenter or cancel.

iii. Dele te Cance lled:

If in the de lete a student sub flow, the administrator dec ides not to delete the

student, the delete is cancelled and the Bas ic flow is restarted.

iv. P re Condition:

The adminis trator must be logged on to the system before this use case begins.

v. Post Co ndition:

If the use case was successful, the student information is added, updated or

deleted.


5. Create re sult/report

5.1 Brief description:

This use case allows the user to create an overa ll c lass or department result. The

individua l student result, toppers list, arrears lis t and improvement rate for the academic year

report is discussed.

5.2 Flow of events:

5.2.1 Basic flow:

This use case starts with the actor user wishes to create a report.

1. The system requests the user to specify the following report criter ia :

Report type (either Overall c lass/Department result, Individua l

Student Result, Toppers List, Arrears List and Improvement

Rate for the academic year).

Criter ia for the respective report.

2. If the user selects the Overall c lass/department result report, the system retrieves and

displays the ent ire Students mark information form the database.

3. The system then requests the user to enter information he/she requires(criter ia).

4. If the user selects Individua l Student Result report, the system requests the

student to enter the regis ter number.

5. The system va lidates the register number and if it is va lid, the displays the report.

6. Similar ly, for the Toppers list, Arrears lis t, Improvement Rate reports, the

criter ia are spec ified.

7. Once the user provides the requested information the System provides the report

satis fying the report criter ia.

8. The user may require saving the report.

5.2.2 Alte rnative flow:

Requested Info rmatio n Un availa ble :

If in the bas ic flow, the requested information is unava ilab le, the system will display an error

message. The user can choose return to begin to bas ic flow or cancel it at which the use case

ends.

Invalid fo rmat o r Insuff icient Info rmation:

If in the bas ic flow, the user has not specified suffic ient information to create the report, the

system will prompt the user for miss ing information. The user can re-enter or cancel, at which

point the use case ends.

Invalid regis ter numbe r:

If the user enters inva lid regis ter number, the system will display an error message. The user

can re-enter or cancel the operation.


5.3 Pre condit ion:

The user must be logged on to the system before the use case begins.

5.4 Post condit ion:

The System state is unchanged by the use case.

SEQUENCE DIAGRAM

1. LOGIN


2. MARKS ENTRY


MARK ANALYSIS

3. MAINTAIN STUDENT INFORMATION


3.1 ADD A STUDENT

4.2 UPDATE STUDENT INFORMATION


4.3 DELETE A STUDENT

4. CREATE A RESULT



1.1 LOGIN

2. MARKS ENTRY


3. MARK ANALYSIS


4.1 ADD A STUDENT


4.2 UPDATE STUDENT

4.3 DELETE STUDENT


5. CREATE RESULT/REPORTS

STATE CHART DIAGRAM

1. LOGIN


2. MARKS ENTRY

ACTIVITY DIAGRAM

1. UPDATING THE DATABASE


2. ADDING A STUDENT


3. DELETING A STUDENT


CLASS DIAGRAM

1. LOGIN

2. MARKS ENTRY


3. MARK ANALYSIS

4. CREATE STUDENT REPORT



COMPONENT DIAGRAM


SOURCE CODE

1) Login : Option Explicit

Public NewProperty As login_form

Public Sub refer_to_database() End

Sub

Public Sub validate_user_name_and_pass_word() End

Sub

2) Ma rk entry: Option Explicit

Implements main_form

Public Sub display_mark_entry_form() End

Sub

Public Sub faculty_enters_mark() End

Sub

Public Sub refer_from_data_base() End

Sub

3) Ma rk ana lysis: Option Explicit

Public Sub process_the_marks() End


Sub

Public Sub calculatation_of_total_average() End

Sub

4) Student repo rt:

Option Explicit

Public NewProperty As student Public

NewProperty2 As student Public Sub

enter_opreation()

End Sub

5) Ma intain student info rmatio n: Option Explicit

Public Sub add_option() End

Sub

Public Sub update_option() End

Sub

Public Sub delete_option() End

Sub

RESULT:


STUDENT MARK ANALYSIS SYSTEM. Thus the outcome of the project is efficient. The

STUDENT MARK ANALYSIS SYSTEM caters the varied requirements of the user to perform

various options.


3. ONLINE RESERVATION SYSTEM

AIM:

To analyze, design and develop a System for Online Reservation using Rational Rose

software.


1.1 Introduct ion

This document deals with online t icket reservat ion for air lines. This document is des igned

in such a way that reader understands it. The use case description and other documents are

described in such a way that the system reaches the people easily.

1.2 Objectives

The purpose of the document is to know about the availability of seats, air lines etc.

According to the requirements passenger reserves his/her tickets.

1.3 Scope

This document for online t icket reservat ion for a ir line makes the work easy for the

passenger to book these tickets. This is t ime consuming process and easy to book the tickets.


Computers play an integra l part in day today life. It makes the work easy and faster.

Every job is computerized now. So is the ticket reservat ion, we can book our tickets online.

Dur ing the reservat ion of tickets the passenger has to select the origin, date of journey,

passport number, etc

The reservat ion counter keeps track of the passengers information. The system will

have a ll the details about the a ir lines and the facilit ies provided by them. There are var ious

air lines provided according to the convenience of the passenger. A database is mainta ins by

the database administrator.

There are many var iet ies of air lines. The passenger can select according to the ir

convenience. Each air line has its own arriva l and departure t ime. The journey can be within the

country or across the country. So, the a ir lines are divided into nat iona l and internat iona l. For

internat iona l passengers, the t ickets are booked only after checking the ir visa and passport.

Each a ir line has three types of c lasses according to the convenience of passengers. The

types are economy, bus iness and first c lass. The vacancy of each air line can be viewed online.



2.1 Ident ified use cases

i View Status:

It he lps to find the ava ilability of seats, time of flight.

ii Booking ticke ts :

Passengers enter his /her personal deta ils & book the tickets.

iii Payme nt mode:

The payment is done either by cash or credit card.

iv Login:

The c lerk logs into the system.

v Cance llation:

Passenger cancels his/her t ickets with the he lp of c lerk.

vi Report:

Administrator report is generated by the c lerk.

2.2 Ide nt if ied Actors

i Passenger:

The person who wishes to book his / her ticket for the trave l.

ii Clerk:

He is the center person who books and cancels the tickets.

iii Bank system:

If the passenger selects the mode of payment as credit card, then its actor comes in.


3. Design of Expert Medical System


1. View status


This use case will a llow the passenger to enter the a ir line & t iming to his /her des ire.

Accordingly a ll the seats ava ilable, t iming of will be displayed. These details are taken from the

database.

1.2 Flow of events:

1.2.1 Bas ic flow:

1. The passenger will choose the view status option.

2. Actor enters the air line and timing.

3. The lis t of seats available in part icular air line is displayed.

4. Actor chooses des ired option.


1. If the t ime of a ir line is not occurred(or)

2. If the seat is not available in particular a ir line the error message is displayed.

1.3 Pre conditions:

None


If the use case is successful the actor books the tickets in the des ired air line.

2. Book Ticket


After viewing the status the passenger plans to book the ticket. He enters his persona l

details. The a ir line he has chosen and the seat he required. From the database given by the

passenger are checked and saved. If there is no contradiction the t ickets is booked for the

passenger.

2.2 Flow of events:

2.2.1 Bas ic flow:

1. The passenger enters his personal details, type of a ir line and seat allocation.

2. From the database there criter ia are checked and allotted.

3. The t icket is booked and the mode of payment is requested.


If any of cr iter ia like a ir line t iming or deta ils about passenger is incorrect the error

message is given to the passenger.


2.3 Pre Condit ion:

Before booking the t icket the status of the a ir line s eat ava ilability are checked.

2.4 Post Condition:

Then the payment mode is selected and payment is made accordingly.

3. Payment Mo de

Brie f descript ion:

For the tickets booked online two ways of payment is ava ilable. It can either be cash

or by credit card. If credit card is chosen then the bank is involved to debit money from the

account.

3.2 Flow of events:

3.2.1 Basic flow:

1. The payment mode is selected from the option.

2. If credit card is chosen the account number and bank deta ils are given.

3. The receipt or acknowledgment is given back to the passenger.


If the bank details are incorrect an error message is given to the passenger.

3.3 Pre Condit ion:

None

3.4 Post Condition:

The acknowledgement for the payment is received by the passenger

4. Login

4.1Brie f descript ion:

This use case describes hoe the c lerk logs into the sys tem. We give the required details,

if the deta ils are correct then the clerk enters the system else he has to re-enter the deta ils.

4.2 Flow of events:

4.2.1 Bas ic flow:

1. The system request for the username and password.

2. The clerk enters the deta ils.

3. The system validates the deta ils and logs into the system.


1. If the deta ils entered by the actor are incorrect an error message is displayed.

2. The actor can either re-enter the deta ils or cancel the login use case.


4.3 Pre Condit ion:

None


If the use case is successful, the actor logs into the system.

5. Cance llation


When the passenger wishes to cancel his bookings he can do so with the he lp of c lerk.

The c lerk will cancel from the database and refund the money to the passenger.

5.2Flow of events:

5.2.2 Bas ic flow:

1. The passenger enters his details.

2. The clerk cancels the booking of the passenger.

3. The database is updated.

4. The refund money is calculated and given to the passenger.


If the details entered by the passenger are incorrect an error message is displayed.

5.3 Pre Condit ion:

The ticket has to be booked for which we can do cancellat ion.

5.4Post Condition:

The money to refund is calculated and given to the passenger.

6. Report


The per iodic report is generated by the clerk. The deta ils about the passenger, a ir line,

cancellat ion, etc are ma inta ined in the database. The report is generated.

6.2 Flow of events:

6.2.1 Bas ic flow:

The c lerk extracts the required information from the database. report is generated.


None

6.3 Pre Condit ions:

None

6.4 Post Conditions:

A report is generated.


SEQUENCE DIAGRAM

1. VIEW STATUS


2. BOOKING TICKETS


3. PAYMENT MODE


4. LOGIN


5. CANCELLATION

6. REPRTS



1. VIEW STATUS

2. BOOKING TICKETS


3. PAYMENT MODDE

4. LOGIN


5. CANCELLATION

5. REPORT


CLASS DIAGRAM

1. VIEW STATUS

2. BOOKING TICKETS


3. PAYMENT MODE

4. LOGIN


5. CANCELLATION

6. REPORT


ACTIVITY DIAGRAM


COMPONENT DIAGRAM


SOURCE CODE

1. View Status:

Option Explic it

Public NewProperty As error_form Public

NewProperty2 As passenger Public Sub

enter_dataild()

End Sub

2. Booking Tickets :

Option Explic it

Private va lidate As Var iant

Public NewProperty As Database

Public NewProperty2 As Database

Public NewProperty3 As data_enter_form

Public Sub refer() End Sub

3. Payme nt Mode:

Option Explic it

Public NewProperty As passenger Public

NewProperty2 As bank sys tem Public Sub valid()

End Sub

Public Sub enter_mode() End Sub


4. Login:

Option Explic it

Public NewProperty As data_enter_form

Public Sub inva lid() End Sub

5. Cance llation:

Option Explic it

Public NewProperty As db_controlle r

Public Sub if_confirmed() End Sub

6. Repo rt:

Option Explic it

Public NewProperty As error_form Public

NewProperty2 As passenger Public Sub

enter_dataild()

End Sub

RESULT:


ONLINE RESERVATION SYSTEM. Thus the outcome of the project is efficient. The

ONLINE RESERVATION SYSTEM caters the varied requirements of the user to perform

various options.


4. EXPERT SYSTEM

AIM:

To analyze, design and develop a project for Expert System using Rational Rose

software.


1.1 Introduct ion

The expert medica l system is deve loped to an automated means for providing medica l

guidance to the users. This system is user fr iendly and the required information, the

corresponding medicines jus t by providing the symptoms from which the patient is suffer ing.

1.2 Objectives

The ma in objective is to provide the users with an easy way to ga in information

about the medicines that can effective ly cure the disease of the patients. The system is very

befr iending when the doctors are not ava ilable for the patients.

1.3 Scope

The scope of the expert medica l sys tem is to provide an e ffic ient service to the

patients especia lly the outpat ients in a hospita l. This proves to be very he lpful when the doctor

may not ava ilable and also for reference to know the latest medicines ava ilable to cure the

disease more quickly without any s ide effects. The pharmacis t can also view the lis t of

medic ines in the system and order for the medic ines that is not available in the s tock.


The user can make use of the expert medica l system by se lecting the symptoms that is

noticed in the pat ients body from the check box given in the form. This is the only input

given to sys tem. The sys tem later ana lys is the input and gives the medicines and the amount of

dosage according to the sever ity of the disease and the age of the pat ient.

In order to access the system the user should login to the sys tem. This is to avoid the

trespassers from accessing the system data and thus enhance the security of the system. The

adminis trator is the only author ized person to change the data in the system. The administrator

ma inta ins the details of the doctors or consultants, the disease name, the medicines to be

taken for treatment for those diseases, etc. The administrator also mainta ins the details of

the user who have created the ir accounts to access the sys tem.

As the system requires huge amount of information to be stored these data are

ma inta ined by the administrator in the database. Thus the sys tem ga ins the flexib ility that is

obvious while us ing a database. The administrator is the only person to access and modify the

data in the database.

The user first needs to get his acc ount created to ava il themselves of the fac ilit ies of

the system. Thus the user gives all the required details to the system like the name, age, the

desired user name and password etc. The system then counter checks this information with the


database. If it is va lid then the record is created for the user in the database along with the

user name and password. Then during subsequent login to the system the corresponding domain

form or the ma in form is displayed. For example, if the user is a pharmac ist then his ma in form

is the lis t of medicines. If it is the administrator has logged in the ma in form is the lis t operation

he needs to perform through a controller in the database.

The system is open to the users at any time. The data in the database is checked every

week on Saturday and the required operat ions like adding, deleting or updating of the data.


2.1 Ident ified use cases

i Users:

The users are the actors who can only view the medicines by select ing the symptoms.

ii Pharmacis t:

The pharmacist can only view the lis t of medic ines ava ilable in the database.

iii Doctors:

The doctors are actors who can view the medicines directly without enter ing the

symptoms.

iv Adminis trator:

The adminis trator is the only author ized person to change the data in the database. The

adminis trator ma inta ins the information in the database.

2.2 Identified Actors

i Login:

The use case is used by the doctors, users, pharmacis t and administrators to enter the

system.

ii View Medicines:

The view medic ine use case is used to view a ll the medic ines ava ilable by the

doctors and pharmacis t and only the prescribed medicines for the symptoms given by the

user.

iii Maintain Information:

This use case is accessible only to the administrator that a llows him to add, update and

delete the required information directly from the database.



3. Design of Expert Medical System


1. Login


The login use case works the same name for any type of user. The common users,

doctors, pharmac ist and the administrator can login to the system.

1.2 Flow of events:

1.2.1 Bas ic flow:

1. The user or doctor or pharmac is t or the adminis trator is requesting to enter the user

name and password into login domain form.

2. The login controller va lidates this user name and password by comparing the

informa tion from the database.

3. If the user name and the password are va lid then their corresponding domain

form is displayed.


1. If the user name and password is inva lid the control shifts back to login domain

form.

2. The user re-enters the user name and password or exists.


1.3 Pre conditions:

None


The use case was successful and the actor is now logged into the sys tem. If not the


2. View Medicines


The view medic ines use case is where the ma in output of the system is obtained. The

user, the pharmac ist and the doctors can view the medicine.

2.2 Flow of events:

2.2.1 Bas ic flow:

1. The domain form of the user request the user to select the symptoms displayed in

the domain form.

2. The user selects the symptoms from the domain form.

3. The domain controller us ing the information from the database validates the symptoms

selected.

4. If the corresponding medic ine is found the system displays the medicines along

with the dosage according to the age and severity of the disease.


If the medicines are not prescribed properly then it is better to approach the consultant.

2.3 Pre Condit ion:

The user must have logged into the system.

2.4 Post Condition:

The user gets information of the medicines and the ir dosage.

3. Maintain Information


This maintain information use case mainta ins various kinds of information needed for

the system in the database. The administrator performs this work only. The important

operations or funct ions performed are add, deleted and update.

3.2 Flow of events:

3.2.1 Basic flow:

1. The adminis trators domain form or the ma in form is first displayed when the

adminis trator has successfully logged into the sys tem.

2. The domain form reques t the administrator to select any of the operations listed on

the domain form.


3. The administrator selects the required operation from the domain form.

4. Based on the operat ions selected the control is shifted to that operation.

3.2.1.1 Add

3.2.1.1.1 Bas ic flow:

1. The system reques t the information to be added into the database, for example, the

name, age, address, etc. of the doctors.

2. The administrator also provides the requested information to the system.

3. The sys tem va lidates this information with the database and forms a record in the

corresponding tab le.

3.2.1.1.2 Alternative flow:

1. An error message occurs when the user information given is not matching the format as

per the database.

2. The administrator gives the correct format or exists the system.

3.2.1.2 De le te


1. The system requests the id of the doctor whose record is to be deleted.

2. The administrator a lso provides the information.

3. The system va lidates this information with the database and deletes the record in the



1. The error message is shown to the administrator if inva lid ID number is entered.

2. The administrator re-enters the information or exis ts the sys tem.

3.2.1.3 Update


1. The system requires the information to be updated into the database, for example, the

name, age, address, etc. of the doctors.

2. The administrator a lso provides the requested information.

3. The system va lidates this information with the database and updates the record in the



1. An error message occurs if an inva lid fie ld name is entered into the system.

2. The administrator re-enters the information or exis ts the sys tem.


1. An error message occurs when the information given is not sufficient.

2. The administrator re-enters the information or exis ts the system.


3.3 Pre Condit ion:

None

3.4 Post Condition:

The adminis trator must have logged into the system.

SEQUENCE DIAGRAM


2. VIEW OF MEDICINES BY THE USER

3. ADMINISTRATOR DOMAIN FORM


3.1 ADDING OF INFORMATION TO THE DATABASE

3.2 DELETING OF INFORMATION FROM DATABASE


3.3 UPDATINF OF INFORMATION FROM DATABASE



1. LOGIN

2. VIEW OF MEDICINES BY THE USER



3.1. ADDING OF INFORMATION BY THE USER


3.2 DELETING INFORMATION FROM THE DATABASE

3.3 UPDATINF INFORMATION FROM THE DATABASE


CLASS DIAGRAM

1. LOGIN

2. VIEWING MEDICINES BY THE USER


3. 3. ADMINISTRATOR DOMAIN FORM

3.1. ADDING OF INFORMATION BY THE USER


3.2 DELETING INFORMATION FROM THE DATABASE

3.3 UPDATINF INFORMATION FROM THE DATABASE


STATE CHART DIAGRAM

1. LOGIN


2. VIEWING MEDICINES BY THE USER


3.1 ADDING OF INFORMATION TO THE DATABASE


3.2 DELETINF OF INFORMATION FROM DATABASE


COMPONENT DIAGRAM


SOURCE CODE

1.Login Option Explic it

Public NewProperty As login_controller

2.Viewing medic ine by the Use r

Option Explic it

Public NewProperty As symptom_controller_from_add_form_controller_

3.Administrato r Do main Form

Option Explic it

Public NewProperty As admin_domain_controller

3.1 Adding of info rmation to the data base

Option Explic it

Public _ As error_msg

Public NewProperty As add_form_controlle r 3.2 De le ting of info rmation fro m Database

Option Explic it

Public NewProperty As delete_from_controller

3.3 Updating of Info rmation fro m Data base

Option Explic it

Public NewProperty As update_controller

RESULT:


EXPERT SYSTEM. Thus the outcome of the project is efficient. The EXPERT SYSTEM

caters the varied requirements of the user to perform various options.


5. REMOTE SYSTEM

AIM:

To analyze, design and develop a project for Remote System using Rational Rose

software.


1.1 Introduct ion

Remote Computer monitor ing system is designed to monitor the c lients in the network

with the he lp of databases. This system works on the bas is of c lient-server interaction. For

security reasons c lients only areas perta ined to them.

1.2 Objectives

To build a remote computer monitoring sys tem. This system reta ins information about all

the c lients in the sys tem network.

1.3 Scope

The inst itut ion needs a c lient server system where the server controls the data needed to do

the required work.


You are tasked to build a new remote computer monitor ing sys tem. The inst itut ion needs

a client-server system where the server controls the data ( information, files and computer

programs) needed to do the required work.

The client server system computing is important since it centra lizes the control of data.

This new system will have a windows based desktop inter face where the server monitors

the c lients connected by network. For reasons of security, c lients can only access areas

pertained to them.

The server will reta in information of a ll clients in the sys tem network. The exist ing

database supports the necessities of the c lients. The server will access, but not update

information stored in the c lient database.

The system administrator ma inta ins client information. He performs the key role

of adding/ removing/ updat ing c lients as we ll as running the administrat ive reports. Students

only do the work pertained to them.

Professor does his work and a lso checks the activit ies of the students over the

network. The HOD monitors the c lients through the network.

Fina lly, the management checks the activit ies of students, professor and HODs.


2. Problem statement (Use case)analysis


i Login

ii Students work with lab exe rc ise

iii Monitor students

iv Ma inta in c lient information


i Student

ii Professor/HOD

iii Adminis trator

iv ManagementDatabase1(current working environment)

v Database2(student deta ils )

vi Login Controller



3. Design of Students Mark analy zing System


1. Login


This use case describes how a c lient logs into the sys tem.

1.2 Flow of events:

1.2.1 Basic flow:

This use case starts with the actor wishes to log in to the MAS.

1. The system requests the actor to enter the user name and password.

2. The actor enters the ir name and password.

3. The system va lidates he entered user name and password.

4. Logs the actor into the system.


1. If the actor enters a wrong username and password, the system displays an error

Message.

2. The actor can choose to either reenter the deta ils or cancel the login.

1.3 Pre conditions:

None


1. If the use case was successful, the user has now logged into the system, if not the

system is unchanged.

2. Student work with lab exerc ise


Student starts working with lab exercise. He is restr icted to work with his area.

2.2 Flow of events:

2.2.1 Basic flow:

1. Students start working with lab exerc ise.

2. Saves his work.

3. Quits.


If user opens those applicat ions which he is not permitted to error message is displayed.

2.3 Pre Condit ion:

None

2.4 Post Condition:

None


3. Monitoring Stude nts


Professor/HOD can monitor students by choos ing the students by referr ing to database2.

3.2 Flow of events:

3.2.1 Basic flow:

1. Select the student to monitor.

2. System gets details from database2.

3. Compares it with already stored details in database1.

4. Quits.


If the database2 does not match with database1 an error message is displayed.

3.3 Pre Condit ion:

Login

3.4 Post Condition:

Professor/HOD selects next operation.

4. Maintain Client Information


Database adminis trator can add/delete/update any c lient in database.

4.2 Flow of events:

4.2.1 Basic flow:

This use case starts when the administrator wants to add/delete/update the

database.

1. Display a selection form.

2. Reques t user to select any of the three operat ions (add/delete/update).

3. User enters his select ion.

4.2.1.1 Add

4.2.1.1.1 Basic flow:

This use case starts when the administrator wants to add a new client to the database.

1. Display the add form.

2. Reques t the administrator to enter the name, phone number, address and other details.

3. Administrator enters the deta ils.

4. System generates the user id.

5. Returns it to the administrator.


4.2.1.1.2 Alternat ive flow:

1. If any of the required details is not entered display an error message.

2. If the deta ils are a lready present in the database display an error message.

3. User enters the rema ining deta ils.

4.2.1.2 De le te


This use case starts when the administrator wants to delete a new c lient to the database.

1. Display the de lete form.

2. Reques t the administrator to enter the id of the c lient to be deleted.

3. Administrator enters the id.

4. Display confirmation message.


1. If the id entered by the user is not available in the database error is displayed.

2. The administrator to either return to the beginning of the bas ic flow or cancel the delete

option.

4.2.1.3 Updating an existing Customer account


1. Display the update form.

2. Reques t the administrator to enter the id of the c lient to be updated.

3. Administrator enters the id.

4. Display the record.

5. User can change the required details.


1. If the id entered by the user is not available in the database error is displayed.

2. The administrator to either return to the beginning of the bas ic flow or cancel the delete

option.


None

4.3 Pre Condit ion:

Login

4.4 Post Condition:

Report Generat ion.


SEQUENCE DIAGRAM

1. LOGIN


2. STUDENTS WORKING WITH LAB EXERCISE

3. MONITOR SYSTEM


4. MONITOR CLIENT SYSTEM


4.1 ADD


4.2 DELETE


4.3 UPDATE



1. LOGIN

2. STUDENTS WORKING WITH LAB EXERCISE

3. MONITOR STUDENTS


4. MAINTAIN CLIENT INFORMATION

4.1 ADD

4.2 DELETE


4.3 UPDATE

STATE CHART DIAGRAM


CLASS DIAGRAM

1. LOGIN

2. STUDENTS WORKING WITH DATABASE


3. MONITOR STUDENTS

4. MAINTAIN CLIENT INFORMATION


4.1 ADD

4.2 DELETE

4.3 UPDATE


COMPONENT DIAGRAM


SOURCE CODE

1.Login

Option Explicit

Private name As Variant

Private password As Variant

Public Sub enter_name_and_password() End

Sub

2.Students wo rking with lab exe rcise

Option Explicit

Private programs As Variant Public

Sub execute_programs() End Sub

Public Sub opname() End

Sub

3.Mo nito r Students Option Explicit

Public Sub login() End

Sub

4.Ma intain client info rmatio n

Option Explicit

Public NewProperty As report

Public Sub validate() End

Sub


4.1 Add

Option Explicit

Private details_to_be_updated As Variant

Public Sub get() End

Sub

4.2 Delete

Option Explicit Public Sub

validate() End Sub

4.3 Update

Option Explicit

Public NewProperty As Main_form

Public Sub display() End

Sub

RESULT:


REMOTE PROCEDURE CALL. Thus the outcome of the project is efficient. The REMOTE

PROCEDURE CALL caters the varied requirements of the user to perform various options.


6. ATM SYSTEM

AIM:

To analyze, design and develop project for Automated Teller Machine system using

Rational Rose software.


1.1 Introduction

Banking is one of the common and day to day attr ibute of life. Nowadays it is tota lly

different from that existed a few years ago banking has become completely computer ized new

facilit ies such as credit cards, debit cards & ATM has been introduced. ATM is automatic te ller

machine which is basically used to withdraw money from an account.

1.2 Objectives

The objective of this software is similar to ATM software insta lled in ATM center. It

should first va lidate the pin in the ATM card. Then the type of transaction is enquired and the

information from the customer is va lidated. If it is a withdrawa l the amount is asked. After the

money is delivered the transaction jus t made is updated in the database where the customers

information is stored.

1.3 Scope

The scope of the project is to design an ATM sys tem that will he lp in complete ly

automatic banking this software is go ing to be designed for withdrawa l and depos it of money

and register the transact ion in the database where the customers information is stored.


ATM is another type of banking where the most frequently type of transaction made is

withdrawal. A user may withdraw as much as many amount as he wants unt il his account holds a

sum greater than his withdrawa l amount. ATM is complete ly automated and there is no necessity

of the ATM center being placed at the bank itse lf. It can be placed in the shopping ma lls,

airports, railway stations etc.

This ATM system can use any kind of interface. But it should be user fr iendly and not

confus ing. He lp manua ls should be provided in case any customer has problem working with the

software.

The system will retain information on the ent ire customer who has necessity r ights to

access the service. It will conta in the ba lance amount in the account, rate of interest, any

specia l a llowance for tha t cus tomer and most of all pin number of the customer. The ATM

system should be compatible with any kind of database such as MS-ACCESS, DB2, ORACLE,

SQL, SERVER etc. the emphas is here is on cons istency.

Some customer could have ava iled some specia l offers on his ATM cards. So this must

be taken care of and the appropriate data should be dealt with.


The ATM should provide easy access to the data for the customer. It should also have a

highly secure interface so that one can take money one behalf of others. So the security is one

of the main aspects in ATM.

2. Problem statement (Use case)analysis


i. Login:

Here the user enters the card and the inputs his password to enter into the ma in form. If the

password is incorrect, the systems will display an error message.

ii. Transaction:

This is the important part of the ATM system, where there are two types of transaction-

withdrawa l and depos it. While withdrawing the user specifies the amount and may request for the

printed output also.

iii. Maintaining Customer Information:

Here the administrator plays an important role, whose work is to add customer, delete

customer account, update customer account, etc.


i Administrator:

Administrator plays an important role. He is the system des igner. All the updating works is

done by him only like adding, dele t ing cus tomer accounts.

ii Database :

All the transaction works-withdrawa l and depos it are updated in the database.

iii Customer:

He is the externa l user the ATM system for taking money and depos iting money a lso.

2.3 Use Case Diagram


3. Design of ATM system


1. Login


This use case describes how the user logs into the System.

1.2 Flow of events:

1.2.1 Basic flow:

This use case starts with the actor wishes to log in to the ATM System.

1. The system requests the user to enter the name and PIN.

2. The actor enters the name and PIN.

3. The system va lidates the name and the PIN and logs the user into the system.


1. If the user enters the wrong name and the PIN then the sys tem displays an error

message.

2. The actor can either return to the bas ic flow or cancel login at which point use case

ends.

1.3 Pre conditions:

None.


User will perform corresponding transaction.

2. Transaction


This describes the transaction that the user is doing.

2.2 Flow of events:

2.2.1 Basic flow:

This use case starts after the user has logged on to the sys tem.

1. The system requests the user to enter the type of transaction of either withdrawa l or

depos it and asks for customer information.

2. The actor enters the type of transaction and the customer information.

3. The system displays the corresponding transaction screen.


If the cus tomer enters any wrong information then the system displays an error message.

2.3 Pre Condit ion:

The user logs on to the system.

2.4 Post Condition:

Based on the transaction he gets the transaction screen.


3. Maintain Information about Customer


This describes how administrator takes care of customer information.

3.2 Flow of events:

3.2.1 Basic flow:

This use case starts after the administrator has logged into the system.

1. The system asks the administrator whether he wants to add or delete customer

information.

2. The administrator then enters the type of maintenance.


None

3.3 Pre Condit ion:

The adminis trator logs on to the system before this use case begin.

3.4 Post Condition:

Administrator gets the corresponding ma intenance screen according to his choice.

3.2.1.1 Adding Customer


1. This use case starts when the administrator has chosen to add customers information.

2. The system asks the administrator to enter customer information.

3. The administrator enters the customer information.

4. The system displays the updated information.


If the administrator enters any wrong information the system displays an error message.

3.2.1.2 De le ting Customer


1. This use case starts when the administrator has chosen to delete an exist ing customer

from the sys tem.

2. The system asks the administrator to enter the cus tomer information.

3. Administrator enters the corresponding user information.

4. The system then displays updated results.


If the adminis trator has entered any wrong information then the system displays

adminis trator error message.


3.2.1.3 Updating an existing Customer ac count


1. This use case starts when the adminis trator has chosen to update the customers

information.

2. The system asks the administrator to enter the cus tomer information.

3. The administrator enters the customer information.

4. The sys tem displays the updated information.


If the adminis trator has entered any wrong information then the system displays

adminis trator error message.

SEQUENCE DIAGRAM

1. LOGIN


2. MAINTENANCE


3. ADDING A CUSTOMER


4. DELETING CUSTOMER

5. UPDATING CUSTOMER


6. TRANSACTION



1. LOGIN

2. MAINTENANCE


3. ADDING CUSTOMER

4. DELETING CUSTOMER


5. UPDATING CUSTOMER

6. TRANSACTION


STATE CHART DIAGRAM

CLASS DIAGRAM

1. LOGIN


2. TRANSACTION

COMPONENT DIAGRAM


SOURCE CODE

1. Login

Option Explicit

Public NewProperty As login_window Public

NewProperty2 As welcome_mes sage Public

NewProperty3 As customer

Public NewProperty4 As error_message

2. Tra nsactio n

Option Explicit

Public As error_message

Public NewProperty As customer Public

Sub init iate_transaction() End Sub

Public Sub provide_information()

End Sub

RESULT:

This project was carried out in a sequential manner to design and implement the ATM

SYSTEM. Thus the outcome of the project is efficient. The ATM system caters the varied

requirements of the user to perform various options.


7. STOCK MAINTENANCE SYSTEM

AIM:

To analyze, design and develop project for Stock Maintenance System using Rational

Rose software.


1.1 Introduct ion

The stock ma intenance system is basica lly for the customers who access the

information about the stock (here it is books in the book store) and retr ieves the information.

1.2 Objectives

The purpose of the document is to define the requirements of the s tock ma intenance

system. This supplementary specificat ion lis ts the requirements that are not readily captured in

the use cases of the use case model. The supplementary specificat ion & the use case model

together capture a complete set of requirement on the system.

1.3 Scope

This supplementary spec ificat ion applies to the stock ma intenance sys tem. This

specificat ion defines the non-funct iona l requirements of the system, such as reliability, usability,

performance and supportability as we ll as functiona l requirements that are common across a

number of use cases.


A new stock maintenance sys tem for a book store is to replace the exis ting ma intenance

system which is in effic ient. The new stock ma intenance system will a llow the

employee to record information of the nooks available in the book store and generate report

based on the tota l amount of sales.

The new sys tem will has a windows based desktop inter face to allow employee to enter

the information of sale, purchase orders, change employee preferences and create reports.

Employee can only access the information and purchase orders for security purpose.

The system reta ins information on a ll the books in the shop. The system reta ins the

records of the cost, edit ion, author, publicat ion of the books. The employee ma intains the

information of the sale of books. He can add the books at right t ime and update the database.

The customer can view the ava ilability of the required books and the price of the books.

The customer can jus t view them but cannot make any changes.




i Login:

It is a transaction performed by the user when he wishes to the stock ma intenance

sys tem.

ii Maintain Books:

It is a transaction performed by the employee when he wishes to add, change and/or

delete books information from the system.

iii Purchase orders:

It is a transaction performed by the manager when he wishes to create, change or delete

purchase orders.

iv View Stock:

It is a transaction performed by the manager when he wishes to view the books available

in the stock maintenance sys tem.

v View report:

It is a transaction performed by the administrator when he wishes to view the report

generated after a ll the s tock update.


i Employee :

The employee can add, change and/or delete the information from the system.

ii Customer:

The customer can jus t view the books available in the system.

iii Manager:

The manager can create, change or delete purchase orders.

iv Adminis trator:

The administrator ma inta ins all the database and reports. He is respons ible for changing

the information of database and takes care of the payment and administrat ive reports.

v Database

The database is the collect ion of data where the data is stored and form where the

data can be retr ieved.


3. Design of Stock Maintenance System


1. Login


This use case describes how a user logs into the stock ma intenance sys tem.

1.2 Flow of events:

1.2.1 Bas ic flow:

This use case starts when the actor wishes to login to the stock ma intenance

sys tem.

1. The system requests that the actor enter the name and password.

2. The actor enters their name and password.

3. The system validates the ent ire name and password and logs the actor into the sys tem.


1. If in the bas ic flow, the actor enters an inva lid name and password the system

display an error message.

2. The actor can choose to either return to the beginning of the basic flow or cancel

the login at which point the use case ends.

1.3 Pre Condit ions:

None

1.4 Post Conditions:

If the use case successful the actor is now logged in the system, if not the system state is

unchanged.

2. Maintain Books


The use case describes how employees ma inta ins book in the sys tem.

2.2 Flow of events:

2.2.1 Bas ic flow:

1. The system requests tha t the employee specify the funct ion he/she would like to

perform (add, update or delete). Once the employee provides requested information, one of the

sub -flow is executed.

2. If the employee se lected add book then add book sub -flow is executed.

3. If the employee se lected update book then update book sub- flow is executed.

4. If the employee selected delete book then delete book sub- flow is executed.

2.2.1.1 Add Books

1. The system requests the employee to enter the books information. This inc lude its

edit ion, author name, publicat ion.

2. Once the information is provided the system generates and assigns a unique book-id

number.


2.2.1.2 Update Books

1. The system requires enter ing id.

2. The employee enters the id, the system retr ieves and displays book information.

3. The employee makes des ired changes to the book information.

4. Once the employee updates information the system updates the book information.

2.2.1.3 De le te Books

1. The system specifies to enter id of the book.

2. The employee enters the id, the system retr ieves and displays book information.

3. The system provides employee to confirm de let ion of the books.

4. The employee ver ifies delet ion.

5. The system deletes the books spec ified.


i. Book not found:

1. If in update books or delete books sub flow the books with spec ified id number

does not exist, the system displays an error message.

2. The employee can then enter different id number or cancel the operation at which


ii De le te Cance lled:

If information the delete books sub -flow the employee dec ides not to delete the book,

the delete is cancelled and the basic flow is restarted at the beginning.

2.3 Pre Condit ion:

The employee logs in to the system.

2.4 Post Condition:

If the use case is successful, the employee ma inta ins books successfully e lse the system is

unchanged.

3. Purchase Orders


This use case describes how the manager provides orders for new stock in the stock in

the stock maintenance sys tem.


3.2 Flow of events:

3.2.1 Bas ic flow:

This use case starts when the manager wishes to record and mainta in purchase orders.

This inc ludes adding, changing, and deleting purchase orders.

1. The system requests that the manager spec ify the funct ion he/she would like to perform

(add, change or delete).

2. Once the manager provides the required information; one of the sub flows is executed.

3. If the manager selected creates purchase order, it is executed.

4. If the manager selected change p urchase order, the sub flow is executed.

5. If the manager selected delete purchase order then that sub flow is executed.

3.2.1.1 Create Purchase Orders

1. The system requests the manager to enter the purchase order information; this

includes the name of the book, quantity, and edit ion.

2. Once the information is provided, the system generates and assigns an order number.

3.2.1.2 Change Purchase Orders

1. The system requests to enter the order number.

2. The manager enters the id number; the system retr ieves and disp lays the information.

3. The manager makes the des ired changes to the orders.

4. The system updates the information.

3.2.1.3 De le te Purchase Orders

1. The system requests the manager to enter the id number.

2. The manager enters the number; the system retr ieves and displays information.

3. The system provides manage r to confirm delet ion of orders.

4. The manager ver ifies delet ion.

5. The system deletes the orders specified.


i. Purchase Order not found:

If in the change order or delete purchase order sub-flows, the purchase order with

specified id number does not exist, the system displays an error message the manager can then

enter a different number or cance l the operation at which point the use case ends.

ii. Cance l De le ted:

If in the delete purchase order sub-flow the manager decides not to delete the purchase

order, the delete is cancelled and basic flow is s tarted at the beginning.

3.3 Pre Condit ion:

The manager logs on the sys tem.

3.4 Post Condition:

If the use case is successful the manager makes the purchase orders else the system is

unchanged.


4. View stock


This use case describes how the cus tomer views the stock ma intenance

sys tem.

4.2 Flow of events:

4.2.1 Bas ic flow:

This use case starts when the customer wishes to view the books ava ilable in the

sys tem.

1. The system requests to customer to enter the details (author, name, publicat ion, and

edit ion) of the book required.

2. Once the information is provided the system displays the book information.


1. If in the bas ic flow the book specified is not found the system displays an error

message.

2. The cus tomer can enter the different book detail or cancel the operation at which


4.3 Pre Condit ion:

None

4.4 Post Condition:

If the use case was successful the customer is provided with the information if not the


5. View Report


This use case describes how the administrator views the reports in the stock maintenance

sys tem.

5.2 Flow of events:

5.2.1 Bas ic flow:

This use case starts when the administrator wishes to view the report generated after ta ll

the stock update.

1. The system specifies the adminis trator to enter his id.

2. Once the administrator is provided, the system retrieves and displays the report.

3. The administrator is provided; the system retr ieves and displays the report.



1. If the id is incorrect the system displays an error message.

2. The administrator can e ither re-enter the correct id or e lse he can cancel the

operation at which point the use case ends.

5.3 Pre condition:

The adminis trator logs on the system.

5.4 Post condit ion:

If the use case is successful, the administrator views the report, if not, the system report

is unchanged.

SEQUENCE DIAGRAM

1. LOGIN


2. VIEW REPORTS


3. VIEW STOCK

4. MAINTAIN STOCK


4.1 ADD

4.2 MODIFY


4.3 DELETE

5. PURCHASE ORDER


5.1 CREATE ORDER

5.2 CHANGE ORDER


5.3 DELETE ORDER


1. LOGIN


2. VIEW REPORTS

3. VIEW STOCK


4. MAINTAIN STOCK

4.1 ADD

4.2 MODIFY


4.3 DELETE

5. PURCHASE ORDER

5.1 CREATE ORDERS


5.2 CHANGE ORDER

5.3 DELETE ORDER


CLASS DIAGRAM

1. LOGIN

2. MAINTAIN BLOCKS


3. PURCHASE ORDER

4. VIEW STOCK & REPORT


COMPONENT DIAGRAM


SOURCE CODE

1.Login

Option Explic it

Public NewProperty As Welcome screen Public

NewProperty2 As Error message Public Sub login()

End Sub 2.Ma intain Books

Option Explic it

Private book_information As Var iant Public

NewProperty As Update books Public

NewProperty2 As Delete books Public Sub

edition()

End Sub Public Sub author_name() End Sub

Public Sub publication() End Sub

3.Purc hase Orde rs

Option Explic it Private assign_order As Variant

Public NewProperty As Change purchase order

Public Sub name_of_the_book() End Sub

Public Sub quantit ies() End Sub

Public Sub edition() End Sub

4.View stock


Option Explic it Private books_availab le As Var iant Public

NewProperty As view stock Public

NewProperty2 As report Public Sub

book_required()

End Sub Public Sub book_spec ificat ion() End Sub

Public Sub displays()

SE Lab Manual NEW

Documents

Transcript of SE Lab Manual NEW