SE Lab Manual NEW

1.
COURSE REGISTRATION SYSTEM

OBJECTIVE:
To analyze, design and develop a System for Course Registration using Rational Rose
software.
1. Proble m analysis and project planning
1.1 Int roduction
This software is des igned in s uc h a way that it receives the na me a nd other partic ulars
from the student. Based on marks the student has scored the list of poss ible branc hes that
will accommodate for the student will be dis pla yed. Only work for the student is he has to fill
the form and s ubmit it.
1.2 Obje ctive s
The ultimate 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 Sc ope
The student is firs t requested to fill the form. This form will c onta in important particulars
of the student like his na me, DOB, preferred b ra nc h, 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 State me nt
As project developers we deve loped a new course registration s ys tem to replace the
existing ma nua l re gistration since manua l s ystem are prone to errors and take more time.
The s ystem made b y user friendly and reduce the burden of users. Our s ystem can
be made ava ilable even in the webs ite of our college.
Students can easily re gister the course in our s ystem without any diffic ulty and can
easily understand and also time taken for registration is less when compared to manua l
registration. Options are given to the student to select the ir elective a nd a lso it s hows the number
of papers ava ilable a long with the number of student who have re gistered and a lso the number of
days for partic ular 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.
1
IT6413 SOFTWARE ENGINEERING LAB

M S.M .ABINAYA, LECT/IT
Your information will be stored as soon as you registered. As you can see registration
form a ga in separate id and password to see the registration form and also number of forms
updated this is to prevent from unauthorized access.
They can see the number of students registered for the partic ular paper. So that if the
registration does not satisfy the number then partic ular course is a bonded.
Fees structure for the course too is provided on the partic ular 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 tration takes place. Administrator
provides id for students and staff to access the s ystem. Billing information if necessary is also
updated.
This is fast when compared to manua l interve ntion s ince separate form s hould be
provided to HOD, staff, administrator whic h takes more time for register ing and even if
student wants to vie w the record it takes more time where as the s ystem des igned does not need
any manua l intervention.
2. Problem state ment(Use case) analysis
2.1 Inde ntifie d use cases
i. Login
ii. Registration
iii. Course details
2.2 Ide ntifie d 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 Doc ume ntation
1. Login
1.1 Brie f de scription:
This use case describes how the user logs into the s ystem.
1.2 Flow of e ve nts:
1.2.1 Basic flow:
1. The s ystem requests the actor to enter the name a nd the pass word.
2. The actor enters the name and the password.
3. The s ystem 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 dis play an
error message.
3

2. The actor can c hoose either to return to the beginning of the bas ic flow or cancel the
login at whic h point use ends.
1.3 Pre condit ions:
None
1.4 Post condit ions:
The use case was s uccessful and the actor is now logged into the s ystem. If not the
system state is unc hanged.
2. Registrat ion
The student uses this use case for registration.
2.2.1 Basic f low:
1. The actor asks for the registration form.
2. The registration form asks for the students details.
3. The actor enters the details .
4. The form control c hecks for the validation. It will c heck for the elective details( i.e.
whe never the e lective preferred by the student is available)
5. If the contents are valid the n the details will be stored in the database and confirmation
message will be displayed.
1. If the e lective preferred by the student is not available the appropriate message will be
dis played.
2. If the registration form ids complete the n the appropriate message is dis played.
3. The student will ha ve now registered the form aga in.
2.3 Pre Condit ion:
The adminis trator must be logged on to the s ystem.
2.4 Post Condit ion:
If the use case was s uccessful the student he/s he can come out of the use case of if
the registration was not s uccessful the n the student can apply for the registration aga in.

3. Course Details:
This use case is starts when the user wis hed to see about the elective.
3.2.1 Basic f low:
This use case starts when the user wis hes to see about the elective deta ils of the course.
The user will, se lect the c ourse.
1. The course will va lidate the request.
2. After va lidation the form control will displa y 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 s uccessfully logged in.
3.4
Post Condit ion:

If the actor has s uccessfully seen the course details then he/s he 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
10

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.
11

2. STUDENT MARK ANALYZING SYSTEM

OBJECTIVE:
To analyze, design and develop code for Student Mark Analysis system using Rational
Rose software.
Proble m analysis and project planning
1.1
Int roduc tion

Student mark a na lyzing s ys tem has been des igned to carry out the mark analysis process
i n a n e d u c a t io n a l institution. The res ults of respective departments can be efficiently
computed without muc h of manua l involveme nt.
1.2
Obje ctive s
The purpose of this doc ument is to define the requireme nts of mark ana lyze is s ystem.
This s ystem reduces manua l work to great extent. The mark a na lysis is carried out by the
system in an effic ient manner.
1.3
Scope
This s ystem is very essentia l for ever y educationa l institution as it reduces man power.
This s ystem can be used for all kinds of educationa l institutions to evaluate a nd ana lyze the
mar ks and ge nerate reports o f spec ified criter ia.
1.4
Proble m State me nt
For analyzing the marks obtained by students in an educationa l institution. We are tasked
to build up student mark ana lyzing s ystem.
This is done to replace the ma nua l entering and processing of marks whic h are error
prone and tedious. This s ys tem also ma inta ins information about student.
The s ystem will have a W indows based desktop interface to a llow the fac ulty to enter
marks obtained by the students, update them and generate var ious reports.
For sec urity reasons, the adminis trator and fac ulty only can update the marks and
other information. First the user needs to login to the s ystem for accessing it. The s ystem
will retain information on a ll the students and the institution. The s ystem ana lyses the marks
and generate the result repor ts. The marks a nd info r ma tio n a bo ut the students are stored
in a database and the s ys tem works with the database.
The faculty can e nter the marks and student information through a vis ua l environme nt.
The updated details are stored in the database. The s ystem generates the overa ll res ult by
ana lyzing the marks. Mark ana lyzer monitors this process. The applications r u n by the mark
ana lyzer.
The tr ia l for illega l updating would render the s ystem to be loc ked. One of the most
important features of the s ys tem is creating reports based on the give n criteria.
12

The user can create the following reports :

Overa ll C lass, Department res ult, I ndividua l student res ult, Toppers list, Arrears list and
Improvement rate for the academic year report has to be generated by enter ing the re gister
number of the student. These reports can also be vie wed by the manage ment and placement
officers. The administrator is respons ible for adding, deleting student deta ils form the s ystem
and updating the marks to the s ystem with the externa l quer ies. So, the system design will
generate reports automatically and there will be no need for manua l interve ntion.
2. Proble m statement (Use case) analysis
2.1 Ide nt if ie d use cases
i
Login:
This use case describes how a user logs in to the mark ana lyzing s ystem.
ii Marks e ntry:
This use case allows faculty to enter the marks into the student table.
iii Mark analys is :
This use case describes ho w the s ystem ge nerates the overa ll res ult by
ana lyzing the marks.
iv Maintain s tude nt information:
This use case allows the administrator to ma inta in the student information and
it a lso inc ludes adding, c hanging a nd deletion of information about the students from
the s ys tem.
v Create res ult re port:
This use case allows the s ystem to ge nerate var ious reports based on the criter ia
specified by the user.
2.2 Ide nt if ie d Actors
i
Fac ulty:
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 s ys tem.
iii Database :
The database that contains a ll the information about the student and the ir marks.
iv Mark analyze r:
The person is respons ible for monitor ing the mark ana lyzing process.
13

v Stude nt:
Details about the students are entered into the s ystem so that the student can
vie w the res ults and reports.
vi Place me nt Office r:
The placement officers can also view the reports based on the criter ia spec ified.
2.3 USE CASE DIAGRAM
14

3. Design of Students Mark analy zing System

3.1 Design Doc ume ntation
1. Login
1.1 Brie f de script ion:
This use case describes how the user logs into the Marks Ana lyzing System (MAS).
1.2.1 Basic flow:
This use case starts with the actor wis hes to log in to the MAS.
1. The s ystem requests the actor to enter the ir name a nd pass word.
2. The actor enters their na me and pass word.
3. The s ystem va lidates the entire name and password and logs the actor into the
sys tem.
1. Inva lid na me and password.
2. If in Basic flow the actor enters and inva lid name and password, the s ystem
displays an error message. The actor can c hoose to either return to the beginning
of bas ic flow or cancel the login at whic h point the use case ends.
1.3 Pre conditions:
None.
1.5
Post condit ions:
If the use case was successful, the actor is now logged into the s ystem, if not, the
system status unc hanged.
2. Marks Ent ry
2.1 Brie f descript ion:
This use case allows the faculty to enter the marks into the student table.
2.2.1 Basic f low:
This use case starts when the faculty wis hes to enter the marks obtained by the student in
different s ubjects.
1. The s ystem 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 c hanged by the fac ulty.
2. Once the faculty has entered marks, the s ys tem saves the table a nd adds it to the
database.
15

2.2.2
Alternat ive f low:

i. Invalid Marks:
In Bas ic flow, if inva lid marks are entered, the s ystem dis plays an error
message and prompts for a va lid mark. The fac ulty must enter a va lid mark or
cancel the operation in whic h case, the use case ends.
ii. Marks alre ady e ntere d:
If in basic flow, the student mark has already been entered, the s ys tem dis plays the
read only copy of marks and informs the fac ulty tha t the mark has a lready been entered.
So, no c hanges can be made to it. The fac ulty acknowledges the message and the use case
ends.
iii. Fields le ft empty:
If in basic flow, the fie ld is left empty, the s ystem prompts the faculty to correct the
error. The fac ulty can enter the mark or mark the student as absent.
2.3
P re Condition:
The fac ulty must be logged on to the s ystem before the use case begins.
2.4
Post Condit ion:
If the use case was s uccessful, the student mark is saved to s ys tem otherwise the s ystem
status is unc hanged.
3. Mark Ana lys is
3.1
B rie f de script io n:
This use case describes how the s ystem generates overa ll res ults by ana lyzing the marks,
Marks Ana lyzer monitors this process.
3.2
Flow of e ve nts:
3.2.1 Basic f low:

This use case begins whe n the mark a na lyzer wis hes to calc ulate the tota l percentage
of marks obtained by the students.
1. The s ystem retrieves and dis plays the c urrent student marks information from the
database.
2. The s ystem calc ulates the total marks and percentage obtained by all the students.
3. The res ults are stored in the database.
4. The use case ends when a ll the students marks have been processed.
16

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 alre ady calc ulate d:
If in basic flow, the result has already been calc ulated, the s ystem displays the
copy of the information a nd 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 s ystem before this us e case begins.
If the us e case was s uccessful, the processed mark information is saved to the s ystem
otherwise the s ystem status is unc hanged.
4. Maintain St ude nt Information
4.1 Brief de script ion:
This us e case allows the administrator to mainta in the student information.
inc ludes add ing, c ha nging and deleting information from the s ystem.
This

4.2.1 Basic flow:
This use case starts whe n the administrator wis hes to c hange, add or delete student
information from the s ystem.
1. The s ys te m r e q ue s ts t h e a d min is tr a to r t o s p e c i f y t h e function that the
adminis trator would like to perform.
2. Once the administrator
provides
the requested information, one of the
sub flows is exec uted. If adminis trator s e le c t s a d d a student, t h e n the add a s tudent s ub
flow is exec uted. If administrator selects update student information, then the update student
information sub flow is executed. If the administrator selects delete a student, the n the
delete a student sub flow is exec uted.
Add a St ude nt:
1. The System requests the adminis trator to enter the student information. This
inc ludes na me, department, year, semester, age and sex.
2. Once the administrator
provides the requested information, the
system ge nerates and ass igns a uniq ue regis ter number to the student. Now the
17

student is added to the s ystem database.

3. The s ystem provides the adminis trator to wr ite the new regis ter number.
Update St ude nt 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.
De le 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.
4.2.2 Alte rnative flow:
i. Stude nt not found:
If the Update Student Information ( USI) or delete a s tudent s ub flow student with
specific with spec ific register number does not exist, then the System dis plays a error
message. The System administrator can reenter or cancel at whic h point the use case
ends.
ii. Irrele vant data:
If in the add a student s ub flow inva lid information is entered, the s ystem display
an error message so that the administrator can reenter or cancel.
iii. Dele te Cance lle d:
If in the de lete a student s ub 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 s ystem before this use case begins.
v. Post Co ndition:
If the use case was successful, the student information is added, updated or
deleted.
18

5. Cre ate re s ult/re port

5.1 Brief de scriptio n:
This use case allows the user to create an overa ll c lass or department result. The
individua l student res ult, toppers list, arrears lis t and improvement rate for the academic year
report is disc ussed.
5.2.1 Basic flow:
This use case starts with the actor user wis hes to create a report.
1. The s ystem requests the user to specify the following report criter ia :
Report type (either Overall c lass/Departme nt res ult, Individua l
Student Res ult, Toppers List, Arrears List a nd Improvement
2.
3.
4.
5.
6.
7.
8.
Rate for the academic year).

Criter ia for the respective report.
If the user selects the Overall c lass/department res ult report, the s ystem retrieves and
displays the entire Students mark information form the database.
The s ystem then requests the user to enter information he/s he requires(criter ia).
If the user selects Individua l Student Res ult report, the s ystem requests the
student to enter the regis ter number.
The s ystem va lidates the register number a nd if it is va lid, the dis plays the report.
Similar ly, for the Toppers list, Arrears lis t, Improvement Rate reports, the
criter ia are spec ified.
Once the user provides the requested information the System provides the report
satis fying the report criter ia.
The user may require saving the report.

Re queste d Info rmat io n Un availa ble :
If in the bas ic flow, the requested information is unava ilab le, the s ystem will displa y an error
message. The user can c hoose retur n to begin to bas ic flow or cancel it at whic h the use case
ends.
Invalid fo rmat o r Ins uff icie nt Info rmat ion:
If in the bas ic flow, the user has not specified s uffic ient information to create the report, the
system will prompt the user for miss ing information. The user can re-enter or cancel, at whic h
point the use case ends.
Invalid re gis te r numbe r:
If the user enters inva lid regis ter number, the s ystem will dis play an error message. The user
can re-enter or cancel the operation.
19

5.3 Pre condit ion:

The user must be logged on to the s ystem before the use case begins.
5.4 Post condit ion:
The System state is unc hanged by the use case.
SEQUENCE DIAGRAM
1. LOGIN
20

2. MARKS ENTRY
21

MARK ANALYSIS
3. MAINTAIN STUDENT INFORMATION
22

3.1 ADD A STUDENT
4.2 UPDATE STUDENT INFORMATION
23

4.3 DELETE A STUDENT
4. CREATE A RESULT
24

25

1.1 LOGIN
2. MARKS ENTRY
26

3. MARK ANALYSIS
4.1 ADD A STUDENT
27

4.2 UPDATE STUDENT
4.3 DELETE STUDENT
28

5. CREATE RESULT/REPORTS
STATE CHART DIAGRAM

1. LOGIN
29

2. MARKS ENTRY
ACTIVITY DIAGRAM
1. UPDATING THE DATABASE
30

2. ADDING A STUDENT
31

3. DELETING A STUDENT
32

CLASS DIAGRAM
1. LOGIN
2. MARKS ENTRY
33

3. MARK ANALYSIS
4. CREATE STUDENT REPORT
34

COMPONENT DIAGRAM
35

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
36

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.
37

3. ONLINE RESERVATION SYSTEM

AIM:
To analyze, design and develop a System for Online Reservation using Rational Rose
software.
1.1 Int roduct ion
This doc ument deals with online ticket reservation for air lines. This doc ument is des igned
in s uc h a way that reader understands it. The use case description and other doc uments are
described in s uc h a way that the s ystem reaches the people easily.
1.2 Obje ctive s
The purpose of the doc ument is to know about the availability of seats, air lines etc.
According to the requirements passenger reserves his/her tickets.
1.3 Scope
This doc ument for online ticket reservation for a ir line makes the work easy for the
passenger to book these tickets. This is time cons uming process and eas y to book the tickets.
1.4 Proble m State me nt
Computers play an integra l part in day today life. It ma kes the work easy and faster.
Ever y job is computerized now. So is the ticket reservation, we can book our tickets online.
Dur ing the reservation of tickets the passenger has to select the origin, date of journey,
passport number, etc
The reservation counter keeps track of the passengers information. The s ystem will
ha ve a ll the details about the a ir lines and the facilities provided by them. There are var ious
air lines provided according to the convenie nce of the passenger. A database is mainta ins by
the database administrator.
There are many var ieties of air lines. The passenger can select according to the ir
convenie nce. Eac h air line has its own arriva l and departure time. The jour ney can be within the
country or across the country. So, the a ir lines are divided into nationa l and inter nationa l. For
inter nationa l passengers, the tickets are booked only after c hecking the ir vis a and passport.
Each a ir line has three types of c lasses according to the convenie nce of passengers. The
types are economy, bus iness and first c lass. The vacanc y of each air line can be viewed online.
38


2.1 Ide nt ifie d use cases
i Vie w 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 s ystem.
v Cance llation:
Passenger cancels his/her tic kets with the he lp of c lerk.
vi Re port:
Administrator report is generated by the c lerk.
2.2 Ide nt if ied Actors
i Passe nge r:
The person who wis hes to book his / her tic ket for the tra ve l.
ii Cle rk:
He is the center person who books and cancels the tickets.
iii Bank s ys te m:
If the passenger selects the mode of payment as credit card, then its actor comes in.
39

40

3. Design of Expe rt Medical System

1. Vie w stat us
This use case will a llow the passenger to enter the a ir line & timing to his /her des ire.
Accordingly a ll the seats ava ilable, timing of will be dis played. These details are taken from the
database.
1.2.1 Bas ic flow:
1. The passenger will c hoose the vie w status option.
2. Actor enters the air line and timing.
3. The lis t of seats available in partic ular air line is dis played.
4. Actor chooses des ired option.
1. If the time of a ir line is not occ urred(or)
2. If the seat is not available in partic ular a ir line the error message is dis played.
1.3 Pre conditions:
None
If the use case is s uccessful the actor books the tic kets in the des ired air line.
2. Book Ticke t
After viewing the status the passenger plans to book the ticket. He enters his persona l
details. The a ir line he has c hosen and the seat he required. From the database given by the
passenger are c hecked and saved. If there is no contradiction the tickets is booked for the
passenger.
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 c hecked and allotted.
3. The tic ket is booked and the mode of payment is requested.
If any of cr iter ia like a ir line timing or deta ils about passenger is inc orrect the error
message is given to the passenger.
41

2.3 Pre Condit ion:

Before booking the ticket the status of the a ir line s eat ava ilability are c hec ked.
2.4 Post Condition:
Then the payme nt mode is selected and payment is made accordingly.
3. Payme nt Mo de
Brie f de script 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 c hosen then the bank is involved to debit money from the
account.
3.2.1 Basic flow:
1. The payment mode is selected from the option.
2. If credit card is c hosen 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 inc orrect an error message is give n to the passenger.
3.3 Pre Condit ion:
None
3.4 Post Condition:
The acknowledge ment for the payment is received by the passenger
4. Login
4.1Brie f de script ion:
This use case describes hoe the c lerk logs into the s ys tem. We give the required details,
if the deta ils are correct then the clerk enters the s ystem else he has to re-enter the deta ils.
4.2.1 Bas ic flow:
1. The s ystem request for the username a nd pass word.
2. The clerk enters the deta ils.
3. The s ystem validates the deta ils and logs into the s ystem.
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.
42

4.3 Pre Condit ion:

None
If the use case is s uccessful, the actor logs into the s ystem.
5. Cance llation
5.1 Brie f descript ion:
When the passenger wis hes 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 e ve nts:
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 calc ulated 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 whic h we can do cancellation.
5.4Post Condition:
The money to refund is calc ulated 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,
cancellation, etc are ma inta ined in the database. The report is generated.
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.
43

SEQUENCE DIAGRAM
1. VIEW STATUS
44

2. BOOKING TICKETS
45

3. PAYMENT MODE
46

4. LOGIN
47

5. CANCELLATION
6. REPRTS
48

1. VIEW STATUS
2. BOOKING TICKETS
49

3. PAYMENT MODDE
4. LOGIN
50

5. CANCELLATION
5. REPORT
51

CLASS DIAGRAM
1. VIEW STATUS
2. BOOKING TICKETS
52

3. PAYMENT MODE
4. LOGIN
53

5. CANCELLATION
6. REPORT
54

ACTIVITY DIAGRAM
55

COMPONENT DIAGRAM
56

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 Ticke ts :
Option Explic it
Private va lidate As Var ia nt
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 s ys tem Public Sub valid()
End Sub
Public Sub enter_mode() End Sub
57

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_c ontrolle r
Public Sub if_confirmed() End Sub
6. Re port:
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.
58

4. EXPERT SYSTEM
AIM:
To analyze, design and develop a project for Expert System using Rational Rose
software.
1.1 Int roduct ion
The expert medica l s ystem is deve loped to an a utomated mea ns for providing medica l
guidance to the users. This s ystem is user fr ie ndly and the required information, the
corresponding medicines jus t by providing the s ymptoms from whic h the patient is s uffer ing.
1.2 Obje ctive s
The ma in objective is to provide the users with an easy way to ga in information
about the medicines that can effective ly c ure the disease of the patie nts. The s ystem is very
befr iending when the doctors are not ava ilable for the patie nts.
1.3 Scope
The scope of the expert medica l s ys tem is to provide an e ffic ient service to the
patients especia lly the outpatients in a hospita l. This proves to be very he lpful whe n the doctor
may not ava ilable and also for reference to know the latest medicines ava ilable to c ure the
disease more quickly without any s ide effects. The pharmacis t can also vie w the lis t of
medic ines in the s ystem and order for the medic ines that is not available in the s tock.
The user can make use of the expert medica l s ystem by se lecting the s ymptoms that is
noticed in the patients body from the c heck box give n in the form. This is the only input
given to s ys tem. The s ys 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 patient.
In order to access the s ystem the user s hould login to the s ys tem. This is to a void the
trespassers from accessing the s ystem data a nd thus e nha nce the security of the s ystem. The
adminis trator is the only author ized person to c hange the data in the s ystem. The administrator
ma inta ins the details of the doctors or c ons ulta nts, the disease na me, 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 s ys tem.
As the s ystem requires huge amount of information to be stored these data are
ma inta ined by the administrator in the database. Thus the s ys 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 the mselves of the fac ilities of
the s ystem. Thus the user gives all the required details to the s ystem like the na me, a ge, the
desired user na me a nd password etc. The s ystem then counter c hecks this information with the
59

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 s ubsequent login to the s ystem the corresponding doma in
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 s ystem is open to the users at any time. The data in the database is c hecked every
week on Saturday and the required operations like adding, deleting or updating of the data.
2.1 Ide nt ifie d use cases
i Us e rs :
The users are the actors who can only view the medicines by selecting the s ymptoms.
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 a uthor ized person to c hange the data in the database. The
adminis trator ma inta ins the information in the database.
2.2 Ide ntifie d Ac tors
i Login:
The use case is used by the doctors, users, pharmacis t and administrators to enter the
s ystem.
ii Vie w Me dicines :
The view medic ine use case is used to vie w a ll the medic ines ava ilable by the
doctors and pharmacis t and only the prescribed medicines for the s ymptoms 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.
60

3. Design of Expe rt Medical System

1. Login
The login use case works the same na me for any type of user. The common users,
doctors, pharmac ist and the administrator can login to the s ystem.
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 pass word into login domain form.
2. The login controller va lidates this user name and pass word by comparing the
informa tion from the database.
3. If the user name and the password are va lid the n their corresponding domain
form is dis played.
1. If the user name and password is inva lid the control s hifts back to login domain
form.
2. The user re-enters the user na me and password or exists.
61

1.3 Pre conditions:

None
The use case was successful and the actor is now logged into the s ys tem. If not the
2. Vie w Me dicine s
The view medic ines use case is where the ma in output of the s ystem is obtained. The
user, the pharmac ist and the doctors can vie w the medicine.
2.2.1 Bas ic flow:
1. The domain form of the user request the user to select the s ymptoms displayed in
the domain form.
2. The user selects the s ymptoms from the domain form.
3. The domain controller us ing the information from the database validates the s ymptoms
selected.
4. If the corresponding medic ine is found the s ystem dis plays 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 approac h the cons ultant.
2.3 Pre Condit ion:
The user must have logged into the s ystem.
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 s ystem in the database. The administrator performs this work only. The important
operations or functions performed are add, deleted and update.
3.2.1 Basic flow:
1. The adminis trators domain form or the ma in form is first displayed when the
adminis trator has s uccessfully logged into the s ys tem.
2. The domain form reques t the administrator to select any of the operations listed on
the domain form.
62

3. The administrator selects the required operation from the domain form.
4. Based on the operations selected the control is s hifted to that operation.
3.2.1.1 Add
3.2.1.1.1 Bas ic flow:
1. The s ystem 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 s ystem.
3. The s ys tem va lidates this infor mation with the database and forms a record in the
corresponding tab le.
3.2.1.1.2 Alte rnative flow:
1. An error message occ urs when the user information given is not matc hing the format as
per the database.
2. The administrator gives the correct format or exists the s ystem.
3.2.1.2 De le te
1. The s ystem requests the id of the doctor whose record is to be deleted.
2. The administrator a lso provides the information.
3. The s ystem va lidates this infor mation with the database and deletes the record in the
1. The error message is s hown to the administrator if inva lid ID number is entered.
2. The administrator re- enters the information or exis ts the s ys tem.
3.2.1.3 Update
1. The s ystem requires the information to be up dated into the database, for example, the
name, age, address, etc. of the doctors.
2. The administrator a lso provides the requested information.
3. The s ystem va lidates this infor mation with the database and updates the record in the
1. An error message occ urs if an inva lid fie ld name is entered into the s ystem.
2. The administrator re- enters the information or exis ts the s ys tem.
1. An error message occurs when the information give n is not s ufficient.
2. The administrator re- enters the information or exis ts the s ystem.
63

3.3 Pre Condit ion:

None
3.4 Post Condition:
The adminis trator must have logged into the s ystem.
SEQUENCE DIAGRAM
64

2. VIEW OF MEDICINES BY THE USER
3. ADMINISTRATOR DOMAIN FORM
65

3.1 ADDING OF INFORMATION TO THE DATABASE
3.2 DELETING OF INFORMATION FROM DATABASE
66

3.3 UPDATINF OF INFORMATION FROM DATABASE
67

1. LOGIN
2. VIEW OF MEDICINES BY THE USER
68

3.1. ADDING OF INFORMATION BY THE USER
69

3.2 DELETING INFORMATION FROM THE DATABASE
3.3 UPDATINF INFORMATION FROM THE DATABASE
70

CLASS DIAGRAM
1. LOGIN
2. VIEWING MEDICINES BY THE USER
71

3. 3. ADMINISTRATOR DOMAIN FORM
3.1. ADDING OF INFORMATION BY THE USER
72

3.2 DELETING INFORMATION FROM THE DATABASE
3.3 UPDATINF INFORMATION FROM THE DATABASE
73

STATE CHART DIAGRAM

1. LOGIN
74

2. VIEWING MEDICINES BY THE USER
75

76

3.1 ADDING OF INFORMATION TO THE DATABASE
77

3.2 DELETINF OF INFORMATION FROM DATABASE
78

COMPONENT DIAGRAM
79

SOURCE CODE
1.Login
Option Explic it
Public NewProperty As login_c ontroller
2.Vie wing me dic ine by t he Use r
Option Explic it
Public NewProperty As s ymptom_controller_from_add_form_controller_
3.Administ rato r Do main Form
Option Explic it
Public NewProperty As admin_domain_c ontroller
3.1 Adding of info rmat ion to t he data base
Option Explic it
Public _
As error_ms g
Public NewProperty As add_form_c ontrolle r

3.2 De le ting of info rmation f ro m Database
Option Explic it
Public NewProperty As delete_from_controller
3.3 Updat ing of Info rmation f ro 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.
80

5. REMOTE SYSTEM
AIM:
To analyze, design and develop a project for Remote System using Rational Rose
software.
1.1 Int roduct ion
Remote Computer monitor ing s ystem is designed to monitor the c lients in the network
with the he lp of databases. This s ystem works on the bas is of c lient-server interaction. For
security reasons c lients only areas perta ined to them.
1.2 Obje ctive s
To build a re mote c omputer monitoring s ys tem. This s ystem reta ins information about all
the c lie nts in the s ys tem network.
1.3 Scope
The institution needs a c lient server s ystem where the server controls the data needed to do
the required work.
You are tasked to build a new re mote computer monitor ing s ys tem. The institution needs
a client-server s ystem 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 s ystem will ha ve a windows based desktop inter face where the server monitors
the c lients connected by network. For reasons of security, c lie nts can only access areas
pertained to them.
The server will reta in information of a ll clie nts in the s ys tem network. The existing
database supports the necessities of the c lients. The server will access, but not update
information stored in the c lient database.
The s ystem administrator ma inta ins client information. He performs the key role
of adding/ re moving/ updating c lients as we ll as running the administrative reports. Students
only do the work pertained to them.
Professor does his work and a lso c hecks the activities of the students over the
network. The HOD monitors the c lients through the network.
Fina lly, the mana gement c hecks the activities of students, professor and HODs.
81

2. Proble m statement (Use case)analysis

i Login
ii Students work with lab exe rc ise
iii Monitor students
iv Ma inta in c lie nt information
i Student
ii Professor/HOD
iii Adminis trator
iv Manage mentDatabase1(c urrent working e nvironment)
v Database2(student deta ils )
vi Login Controller
82

3. Design of Students Mark analy zing System

1. Login
This use case describes how a c lient logs into the s ys tem.
1.2.1 Basic flow:
This use case starts with the actor wis hes to log in to the MAS.
1. The s ystem requests the actor to enter the user na me and password.
2. The actor enters the ir na me and password.
3. The s ystem va lidates he entered user name and pass word.
4. Logs the actor into the s ystem.
1. If the actor enters a wrong username a nd password, the s ystem dis plays an error
Message.
2. The actor can c hoose to either reenter the deta ils or cancel the login.
1.3 Pre conditions:
None
1. If the use case was s uccessful, the user has now logged into the s ystem, if not the
system is unc hanged.
2. Student work with lab exerc ise
Student starts working with lab exercise. He is restr icted to work with his area.
2.2.1 Basic flow:
1. Students start working with lab exerc ise.
2. Saves his work.
3. Quits.
If user opens those applications whic h he is not permitted to error message is dis played.
2.3 Pre Condit ion:
None
2.4 Post Condition:
None
83

3. Monitoring St ude nts

Professor/HOD can monitor students by c hoos ing the students by referr ing to database2.
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 matc h with database1 an error message is dis played.
3.3 Pre Condit ion:
Login
3.4 Post Condition:
Professor/HOD selects next operation.
4. Maintain Clie nt Informat ion
Database adminis trator can add/delete/update any c lient
in database.

4.2.1 Basic flow:
This use case starts when the administrator wa nts to add/delete/update the
database.
1. Displa y a selection form.
2. Reques t user to select any of the three operations (add/delete/update).
3. User enters his selection.
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. Displa y 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.
84

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 ne w c lient to the database.
1. Displa y 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. Displa y confir mation message.
1. If the id entered by the user is not available in the database error is displayed.
2. The administrator to either retur n to the beginning of the bas ic flow or cancel the delete
option.
4.2.1.3 Updat ing an e xisting Customer acc ount
1. Displa y 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. Displa y the record.
5. User can c hange 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 retur n 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 Generation.
85

SEQUENCE DIAGRAM
1. LOGIN
86

2. STUDENTS WORKING WITH LAB EXERCISE
3. MONITOR SYSTEM
87

4. MONITOR CLIENT SYSTEM
88

4.1 ADD
89

4.2 DELETE
90

4.3 UPDATE
91

1. LOGIN
2. STUDENTS WORKING WITH LAB EXERCISE
3. MONITOR STUDENTS
92

4. MAINTAIN CLIENT INFORMATION
4.1 ADD
4.2 DELETE
93

4.3 UPDATE
STATE CHART DIAGRAM
94

CLASS DIAGRAM
1. LOGIN
2. STUDENTS WORKING WITH DATABASE
95

3. MONITOR STUDENTS
4. MAINTAIN CLIENT INFORMATION
96

4.1 ADD
4.2 DELETE
4.3 UPDATE
97

COMPONENT DIAGRAM
98

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
99

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.
100

6. ATM SYSTEM
AIM:
To analyze, design and develop project for Automated Teller Machine system using
Rational Rose software.
1.1 Int roduc tion
Banking is one of the common a nd day to day attr ibute of life. Nowadays it is tota lly
different from that existed a fe w years ago banking has become completely computer ized new
facilities s uc h as credit cards, debit cards & ATM has been introduced. ATM is automatic te ller
mac hine whic h is basically used to withdraw mone y from an account.
1.2 Obje ctive s
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 e nquired 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 c ustomers
information is stored.
1.3 Scope
The scope of the project is to design a n ATM s ys tem that will he lp in complete ly
automatic banking this s oftware is go ing to be designed for withdra wa l and depos it of money
and register the transaction in the database where the c ustomers information is stored.
ATM is another type of banking where the most frequently type of transaction made is
withdrawal. A user may withdraw as muc h as many amount as he wa nts until his account holds a
sum greater than his withdra wa l a mount. 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 s hopping ma lls,
airports, railway stations etc.
This ATM s ystem can use any kind of interface. But it s hould be user fr iendly and not
confus ing. He lp manua ls s hould be provided in case any customer has problem working with the
software.
The s ystem will retain information on the entire c ustomer who has necessity r ights to
access the service. It will conta in the ba lance a mount in the account, rate of interest, any
specia l a llowance for tha t c us tomer and most of all pin number of the c ustomer. The ATM
system s hould be compatible with any kind of database s uc h as MS-ACCESS, DB2, ORACLE,
SQL, SERVER etc. the emphas is here is on c ons istenc y.
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 s hould be dealt with.
101

The ATM s hould provide easy access to the data for the c ustomer. It s hould also have a
highly sec ure interface so that one can take money one behalf of others. So the sec urity is one
of the main aspects in ATM.
2. Proble m 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 inc orrect, the s ystems will dis play an error message.
ii. Transaction:
This is the important part of the ATM s ystem, where there are two types of transactionwithdrawa l a nd depos it. While withdrawing the user specifies the amount and may request for the
printed output also.
iii. Maintaining Custome r Informat ion:
Here the administrator plays an important role, whose work is to add c ustomer, delete
customer account, update customer account, etc.
2.2 Ide nt if ied Actors
i Administ rator:
Administrator plays an important role. He is the s ystem des igner. All the updating works is
done by him only like adding, dele ting c us tomer accounts.
ii Database :
All the tra nsaction works-withdra wa l and depos it are updated in the database.
iii Customer:
He is the externa l user the ATM s ystem for taking money and depos iting money a lso.
2.3 Use Case Diagram
102

3. Design of ATM syste m

1. Login
This use case describes how the user logs into the System.
1.2.1 Basic flow:
This use case starts with the actor wis hes to log in to the ATM System.
1. The s ystem requests the user to enter the na me and PIN.
2. The actor enters the name and PIN.
3. The s ystem va lidates the na me and the PIN and logs the user into the s ystem.
1. If the user enters the wrong na me and the PIN the n the s ys tem displays an error
message.
2. The actor can either return to the bas ic flow or cancel login at whic h 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.1 Basic flow:
This use case starts after the user has logged on to the s ys tem.
1. The s ystem requests the user to enter the type of transaction of either withdrawa l or
depos it and asks for c ustomer information.
2. The actor enters the type of transaction and the c ustomer information.
3. The s ystem dis plays the corresponding transaction screen.
If the c us tomer enters any wrong information then the s ystem dis plays an error message.
2.3 Pre Condit ion:
The user logs on to the s ystem.
2.4 Post Condition:
Based on the transaction he gets the transaction screen.
103

3. Maintain Informat ion about Customer

This describes how administrator takes care of c ustomer information.
3.2.1 Basic flow:
This use case starts after the administrator has logged into the s ystem.
1. The s ystem asks the administrator whether he wa nts to add or delete c ustomer
information.
2. The administrator the n enters the type of maintenance.
None
3.3 Pre Condit ion:
The adminis trator logs on to the s ystem before this use case begin.
3.4 Post Condition:
Administrator gets the corresponding ma intenance screen according to his c hoice.
3.2.1.1 Adding Customer
1. This use case starts when the administrator has c hosen to add c ustomers information.
2. The s ystem asks the administrator to enter c ustomer information.
3. The administrator enters the c ustomer information.
4. The s ystem dis plays the updated information.
If the administrator enters any wrong information the s ystem displays an error message.
3.2.1.2 De le ting Custome r
1. This use case starts when the administrator has c hosen to delete an existing c ustomer
from the s ys tem.
2. The s ystem asks the administrator to enter the c us tomer information.
3. Administrator enters the corresponding user information.
4. The s ystem then displa ys updated results.
If the adminis trator has entered any wrong information then the s ystem dis plays
adminis trator error message.
104

3.2.1.3 Updat ing an e xisting Customer account

1. This use case starts when the adminis trator has c hosen to update the c ustomers
information.
2. The s ystem asks the administrator to enter the c us tomer information.
3. The administrator enters the c ustomer information.
4. The s ys tem displays the updated information.
If
the adminis trator has entered any wrong information then the s ystem dis plays
adminis trator error message.
SEQUENCE DIAGRAM
1. LOGIN
105

2. MAINTENANCE
106

3. ADDING A CUSTOMER
107

4. DELETING CUSTOMER
5. UPDATING CUSTOMER
108

6. TRANSACTION
109

1. LOGIN
2. MAINTENANCE
110

3. ADDING CUSTOMER
4. DELETING CUSTOMER
111

5. UPDATING CUSTOMER
6. TRANSACTION
112

STATE CHART DIAGRAM
CLASS DIAGRAM
1. LOGIN
113

2. TRANSACTION
COMPONENT DIAGRAM
114

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 initiate_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.
115

7. STOCK MAINTENANCE SYSTEM

AIM:
To analyze, design and develop project for Stock Maintenance System using Rational
Rose software.
1.1 Int roduct ion
The stock ma intena nce s ystem 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 Obje ctive s
The purpose of the doc ument is to define the requirements of the s tock ma intena nce
system. This s uppleme ntary s pecification lis ts the requireme nts that are not readily captured in
the use cases of the use case model. The s upplementary specification & the use case model
together capture a complete set of requireme nt on the s ystem.
1.3 Scope
This s upplementar y spec ification applies to the stock ma intena nce s ys tem. This
specification defines the non-functiona l require ments of the s ystem, s uch as reliability, usability,
performance and s upportability as we ll as functiona l require me nts that are common across a
number of use cases.
A new stock mainte nance s ys tem for a book store is to replace the exis ting ma intena nce
system whic h is in effic ient. The new stock ma intena nce 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 s ys tem will has a windows based desktop inter face to allow employee to enter
the information of sale, purc hase orders, change e mployee preferences and create reports.
Employee can only access the information and purc hase orders for security purpose.
The s ystem reta ins information on a ll the books in the s hop. The s ystem reta ins the
records of the cost, edition, author, publication of the books. The employee ma intains the
information of the sale of books. He can add the books at right time and update the database.
The c ustomer can vie w the ava ilability of the required books and the price of the books.
The c ustomer can jus t view the m but cannot make any c hanges.
116


i Login:
It is a transaction performed by the user when he wis hes to the stock ma intena nce
sys tem.
ii Maintain Books :
It is a transaction performed by the employee when he wis hes to add, c hange and/or
delete books information from the s ystem.
iii Purc hase orde rs :
It is a tra nsaction performed by the manager whe n he wis hes to create, c hange or delete
purc hase orders.
iv Vie w Stock:
It is a transaction performed by the manager when he wis hes to view the books available
in the stock mainte nance s ys tem.
v Vie w re port:
It is a transaction performed by the administrator whe n he wis hes to view the report
generated after a ll the s tock update.
i Employe e :
The employee can add, c hange a nd/or delete the information from the s ystem.
ii Cus tome r:
The c ustomer can jus t view the books available in the s ystem.
iii Manage r:
The manager can create, c hange or delete purc hase orders.
iv Adminis trator:
The administrator ma inta ins all the database and reports. He is respons ible for c hanging
the information of database and takes care of the payment a nd administrative reports.
v Databas e
The database is the collection of data where the data is stored and form where the
data can be retr ieved.
117

118

3. Design of Stock Maintenance System

1. Login
This use case describes how a user logs into the stock ma intena nce s ys tem.
1.2.1 Bas ic flow:
This use case starts when the actor wis hes to login to the stock ma intena nce
sys tem.
1. The s ystem requests that the actor enter the na me and password.
2. The actor enters their na me a nd password.
3. The s ystem validates the entire name and password and logs the actor into the s ys tem.
1. If in the bas ic flow, the actor enters an inva lid na me and password the s ystem
display an error message.
2. The actor can c hoose to either retur n to the beginning of the basic flow or cancel
the login at whic h 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 s ystem, if not the s ystem state is
unc hanged.
2. Maintain Books
The use case describes how employees ma inta ins book in the sys tem.
2.2.1 Bas ic flow:
1. The s ystem requests tha t the employee specify the function he/s he would like to
perform (add, update or delete). Once the employee provides requested information, one of the
sub -flow is exec uted.
2. If the employee se lected add book then add book s ub -flow is exec uted.
3. If the e mployee se lected update book then update book s ub- flow is exec uted.
4. If the e mployee selected delete book then delete book s ub- flow is exec uted.
2.2.1.1 Add Books
1. The s ystem requests the employee to enter the books information. This inc lude its
edition, author name, publication.
2. Once the information is provided the s ystem generates and assigns a unique book-id
number.
119

2.2.1.2 Update Books

1. The s ystem requires enter ing id.
2. The employee e nters the id, the s ystem retr ieves and displays book information.
3. The employee makes des ired changes to the book information.
4. Once the employee updates infor mation the s ystem updates the book information.
2.2.1.3 De le te Books
1. The s ystem specifies to enter id of the book.
2. The employee e nters the id, the s ystem retr ieves and displays book information.
3. The s ystem provides employee to confir m de letion of the books.
4. The employee ver ifies deletion.
5. The s ystem deletes the books spec ified.
i. Book not found:
1. If in update books or delete books s ub flow the books with spec ified id number
does not exist, the s ystem displays an error message.
2. The employee can then enter different id number or cancel the operation at whic h
ii De le te Cance lle d:
If information the delete books s ub -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 s ystem.
2.4 Post Condition:
If the use case is s uccessful, the employee ma inta ins books s uccessfully e lse the s ystem is
unc hanged.
3. Purc hase Orders
This use case describes how the manager provides orders for new stock in the stock in
the stock mainte nance s ys tem.
120


3.2.1 Bas ic flow:
This use case starts when the mana ger wis hes to record and mainta in purc hase orders.
This inc ludes adding, c hanging, and deleting purc hase orders.
1. The s ystem requests that the manager spec ify the function he/s he would like to perform
(add, c hange or delete).
2. Once the ma nager provides the required information; one of the s ub flows is exec uted.
3. If the ma nager selected creates purc hase order, it is exec uted.
4. If the ma nager selected change p urc hase order, the s ub flow is exec uted.
5. If the manage r selected delete purc hase order then that s ub flow is exec uted.
3.2.1.1 Create Purc hase Orde rs
1. The s ystem requests the manager to enter the purc hase order information; this
includes the na me of the book, quantity, and edition.
2. Once the information is provided, the s ystem generates and assigns an order number.
3.2.1.2 Change Purc has e Orde rs
1. The s ystem requests to enter the order number.
2. The manager enters the id number; the s ystem retr ieves and disp lays the information.
3. The manager makes the des ired changes to the orders.
4. The s ystem updates the information.
3.2.1.3 De le te Purc hase Orde rs
1. The s ystem requests the manager to enter the id number.
2. The ma nager e nters the number; the s ystem retr ieves and dis plays information.
3. The s ystem provides manage r to confir m deletion of orders.
4. The manager ver ifies deletion.
5. The s ystem deletes the orders specified.
i. Purc hase Orde r not found:
If in the c hange order or delete purc hase order s ub-flows, the purc hase order with
specified id number does not exist, the s ystem dis plays a n error message the mana ger can then
enter a different number or cance l the operation at whic h point the use case ends.
ii. Cance l De le te d:
If in the delete purc hase order s ub-flow the manager decides not to delete the purc hase
order, the delete is cancelled and basic flow is s tarted at the beginning.
3.3 Pre Condit ion:
The manager logs on the s ys tem.
3.4 Post Condition:
If the use case is s uccessful the mana ger makes the purc hase orders else the s ystem is
unc hanged.
121

4. Vie w stock
This use case describes how the c us tomer vie ws the stock ma intena nce
sys tem.
4.2.1 Bas ic flow:
This us e case starts when the c ustomer wis hes to view the books ava ilable in the
sys tem.
1. The s ystem requests to customer to enter the details (author, name, publication, and
edition) of the book required.
2. Once the information is provided the s ystem dis pla ys the book information.
1. If in the bas ic flow the book specified is not found the s ystem displays an error
message.
2. The c us tomer can enter the different book detail or cancel the operation at whic h
4.3 Pre Condit ion:
None
4.4 Post Condition:
If the use case was s uccessful the c ustomer is provided with the information if not the
5. Vie w Report
This use case describes how the administrator vie ws the reports in the stock maintenance
sys tem.
5.2.1 Bas ic flow:
This use case starts when the administrator wis hes to view the report generated after ta ll
the stock update.
1. The s ystem specifies the adminis trator to enter his id.
2. Once the administrator is provided, the s ystem retrieves and displays the report.
3. The administrator is provided; the s ystem retr ieves and displays the report.
122


1. If the id is incorrect the s ystem dis plays an error message.
2. The administrator can e ither reenter the correct id or e lse he can cancel the
operation at whic h point the us e case ends.
5.3 Pre condition:
The adminis trator logs on the s ystem.
If the use case is s uccessful, the administrator views the report, if not, the s ystem report
is unc hanged.
SEQUENCE DIAGRAM
1. LOGIN
123

2. VIEW REPORTS
124

3. VIEW STOCK
4. MAINTAIN STOCK
125

4.1 ADD
4.2 MODIFY
126

4.3 DELETE
5. PURCHASE ORDER
127

5.1 CREATE ORDER
5.2 CHANGE ORDER
128

5.3 DELETE ORDER
1. LOGIN
129

2. VIEW REPORTS
3. VIEW STOCK
130

4. MAINTAIN STOCK
4.1 ADD
4.2 MODIFY
131

4.3 DELETE
5. PURCHASE ORDER
5.1 CREATE ORDERS
132

5.2 CHANGE ORDER
5.3 DELETE ORDER
133

CLASS DIAGRAM
1. LOGIN
2. MAINTAIN BLOCKS
134

3. PURCHASE ORDER
4. VIEW STOCK & REPORT
135

COMPONENT DIAGRAM
136

SOURCE CODE
1.Login
Option Explic it
Public NewProperty As Welcome screen Public
NewProperty2 As Error message Public Sub login()
End Sub
2.Maintain 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 purc hase order
Public Sub name_of_the_book() End Sub
Public Sub quantities() End Sub
Public Sub edition() End Sub
4.Vie w stock
137

Option Explic it
Private books _availab le As Var ia nt Public
NewProperty As view stock Public
NewProperty2 As report Public Sub
book_required()
End Sub
Public Sub book_spec ification() End Sub
Public Sub displays()
End Sub
RESULT:
This project was carried out in a sequential manner to design and implement the STOCK
MAINTENANCE SYSTEM. Thus the outcome of the project is efficient. The STOCK
MAINTENANCE SYSTEM caters the varied requirements of the user to perform various
options.
138

8. QUIZ SYSTEM
AIM:
To analyze, design and develop project for online quiz system using Rational Rose
software.
1.1 Int roduc tion
Quizzing s ystems are generally used to test the knowledge of an ind ividua l person. But
persons in technica l arena s hould be well stuffed in both tec hnica l and non-technica l s ides. So
this s ys tem is bas ically used to test the profess ionals.
1.2 Obje ctive s
The ma in objective of this quizzing s ystem is to replace the existing hand wr itten s ystem
with a fully computer ized s ystem that would easily a nd exactly calc ulate the inte llectua l
capabilities of a person.
1.3 Scope
Ear lier hand wr itten test were conducted and it was tedious and time cons uming to correct
the papers. Even it had a greater probability towards errors. So the scope the s ystem is that it will
ease the trend s followed in c urrent quizzing s ystem.
The project requires an efficient quizzing s ys tem to access the students of third year IT
based on the skills in var ious s ubjects. It generates report of all the students who taken up the test
and stores it for future use. Access rights are allocated in following order.
Adminis trator->Professors/H.O.D->Students
The administrator is give n r ights only to add or delete student profiles. But has no rights
to access the quizzing information. Professors and lecturers are give n rights to access the question
ava ilable and if needed, make c hanges to them. They can also access the report database to view
the overa ll and individua l performance of the students and then take the necessary action. All the
reports and queries are at the ir dis posal.
Students are the end users of the s ystem. They attend the quizzing sess ion and the ir marks
are added to the database fina l reporting is done based on their performances. The student cannot
access any of the databases inc luding the questions, report or the profile database. Each student is
given a username a nd password to ens ure the sec urity.
The quizzing s ystem is bas ically objective and a ll the questions are related to the course
subject offered for that year. The sess ion is fixed for each student and the questions carry a time
limit within whic h the students are s upposed to ans wer the questions. Otherwise the question
lapses and no points are awarded for that question. The student has the ability to pass the question
and ans wer the ques tion later within the re ma ining time le ft.
139

The quiz program enables us to save time on assessment. It a lso provides instant res ults to
the users. The assessment provided by the s ystem is accurate and he lps the professors to dec ide
the further course of action. It is also very effic ient as there is no manua l interve ntion.
2. Problem state ment (Use case ) analys is
i Login:
Login describes how the user logs into a quizzing s ystem.
ii Enter e xam:
Enter Exa m describes how a student enters into questioning part of quizzing s ystem.
iii Vie w re s ults:
View Res ult describes how a user views res ults after reporting.
iv Maintain que stions & ans wers:
This use case helps the professors/H.O.D to add, delete or c hange ques tions and answers
present in the database.
v Re porting:
This use case describes how the res ults are taken from questioning session.
i St ude nt :
Student is the user who attends the quizzing session and ans wers them. Report database
are generated based on his performance.
ii Profe ssor (or) HOD:
These users access the questions database and c hange the questions and ans wers if found
necessary. They can also vie w the report database to view the performance of the student.
iii Administ rator:
The Administrator is the only user who has access to the user profile database. He also has
the rights to make c hanges if necessary.
iv Data base :
This actor stores the entire contents of the quizzing s ys tem including databases suc h as
report, questions and user profiles.
v Printer:
This actor prints the report database.
vi Time r:
This actor mainta ins the time dur ing the quizzing the quizzing session and intimates the
database to change the questions when the time e lapses.
140

141

3. Design of Qui z System

1. Login
This use case describes how a user logs into a quizzing s ystem.
1.2.1 Basic flow:
This use case starts when the actor wis hes to login to quizzing s ystem
1. The s ystem request that the actor enter na me and pass word.
2. As he enters, the s ystem validates & user logs into the s ystem.
1. If the actor enters an inva lid user name and password, the s ystem displays an error
message.
2. The actor can either relogin or cancel it.
1.3 Pre conditions:
None
The use case was s uccessful and the actor is now logged into the s ystem.
2. Enter Exam
The use case describes how a student enters into questioning part of quizzing s ys tem.
2.2.1 Basic flow:
1. If the student does not finis h the question in the stipula ted time then the question lapses
and no marks are awarded.
2. After answer ing he has to confirm to move to next.
3. He can keep in pass to answer in future.
If the actor want to quit in between; he can quit and come back to login.
2.3 Pre condition:
The user login s hould be a valid student s username and pass word.
The use case was s uccessful then fina lly he moves to vie w res ults.
142

3. Vie w Res ults

This use case describes how a user views res ults after reporting.
3.2.1 Basic flow:
1. This use case starts after the student finis hes questioning.
2. Now the control moves to reporting after whic h res ults are vie wed.
This can also vie wed by administrator/professors in deta il or as a whole.
3.3 Pre condition:
Reporting is done to prepare and view res ults.
Reports are printed out.
4. Maintaining Que stion and Answe rs
The professor/HOD can add, c hange or delete questions and ans wers in this use case.
4.2.1 Basic flow:
4.2.1.1 Add Form
The professor adds new Q & A when he reac hes addition form.
4.2.1.2 Modify Form
Professor modifies Q & A when he reac hes modification form.
4.2.1.3 De le te Form
The professor deletes Q & A required when he reac hes deletion form.
He can quit to login without making any c hanges.
4.3 Pre Condit ion:
The user enters the use case if he gives only a va lid professor username or password.
4.4 Post Condition:
Thus he modifies or lea ves them as s uc h and moves to login back.
143

5. Maintaining use r profile s

The admin uses this use case for the profile ma intenance.
5.2.1 Basic flow:
The admin can ma ke c hanges to user profiles.
5.2.1.1 Add Use r
The admin adds new user profiles whe n he reaches addition form.
5.2.1.2 Modify Use r
The admin modifies user profiles when he reaches modification form.
5.2.1.3 De le te User
The admin de letes user profiles required when he reaches deletion form.
144


He can quit the s ystem without ma king any c hanges.
5.3 Pre condition:
The user enters the use case if he gives a va lid admin pass word.
After saving or without saving he can comeback to login.
6. Re port ing
The use case describes how res ults are brought from questioning sess ion.
6.2.1 Basic flow:
1. After performing the test, the res ults of individua l performa nce is calc ulated.
2. It also generates overall performance of the c lass.
None
6.3 Pre condition:
The question ans wered by the students.
Reports are being stored into the database.
145

SEQUENCE DIAGRAM
1. LOGIN
146

2. ENTER FORM
147

3. VIEW RESULTS
4. MAINTAIN QUESTION AND ANSWER
148

4.1 ADD QUESTION & ANSWER
149

4.2 MODIFY QUESTION & ANSWER
150

4.3 DELETE QUESTION & ANSWER
151

5. MAINTAIN USER PROFILE
5.1 ADD USER
152

5.2 MODIFY USER DETAIL
153

5.3 DELETE USER
6. REPORTING
154

1. LOGIN
2. ENTER FORM
155

3. VIEW RESULTS
4. MAINTAIN QUESTION & ANSWER
156

4.1 ADD QUESTION & ANSWER
4.2 MODIFY QUESTION & ANSWER
4.3 DELETE QUESTION & ANSWER
157

5. MAINTAIN USER DETAIL
5.1 ADD USER
5.2 MODIFY USER PROFILE
158

5.3 DELETE USER
6. REPORTING
159

STATE CHART DIAGRAM

1. DELETE USER
2. UPDATE USER
160

CLASS DIAGRAM
1. LOGIN
2. ENTER EXAM
161

3. VIEW RESULTS
4. MAINTAIN QUESTION & ANSWER
162

5. MAINTAIN USER PROFILE
163

COMPONENT DIAGRAM
164

SOURCE CODE
1. Login
Option Explic it
Public NewProperty As main_form Pub lic
NewProperty2 As login_c intro ller Public Sub id
_pass word()
End Sub
Public Sub relogin() End
Sub
2. Ente r Exa m
Option Explic it
Public NewProperty As overa ll_performance Public
NewProperty2 As individua l_performanc e Public
NewProperty3 As deletion_form
Public NewProperty4 As add_question_form Public
NewProperty5 As modify_ques tions_form Public
NewProperty6 As new_user_add_form
Public NewProperty7 As delete_form
Public NewProperty8 As modification_form
Public Sub availing_options() End
Sub
165

3. Vie w Res ults

Option Explic it
Public NewProperty As options_form
Public Sub to_see_his _res ult() End
Sub
Public Sub individua l_records()
End Sub
Public Sub to_see_a_partic ular_record() End Sub
4. Mainta in Que stion & Ans we rs
Option Explic it
Public NewProperty As options_form Public
NewProperty2 As options_form Public
NewProperty3 As controller Public Sub
selecting_q
a()
End Sub
Public Sub retriving_q_
a() End
Sub
Public Sub reenter() End
Sub
166

5. Maintain Use r Prof ile

Option Explic it
Public NewProperty As options_form Public
NewProperty2 As options_form Public
NewProperty3 As controller Public Sub
modifying()
End Sub
Public Sub retriving() End
Sub
Public Sub error_message()
End Sub
RESULT:
ONLINE QUIZ SYSTEM. Thus the outcome of the project is efficient. The ONLINE QUIZ
SYSTEM caters the varied requirements of the user to perform various options.
167


SE Lab Manual NEW

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

SE Lab Manual NEW

Diunggah oleh

Hak Cipta:

Format Tersedia

1.

COURSE REGISTRATION SYSTEM

IT6413 SOFTWARE ENGINEERING LAB

IT6413 SOFTWARE ENGINEERING LAB

2.3 Use Case Diagram

2.4 Design of Course Registration System

IT6413 SOFTWARE ENGINEERING LAB

IT6413 SOFTWARE ENGINEERING LAB

Post Condit ion:

IT6413 SOFTWARE ENGINEERING LAB

IT6413 SOFTWARE ENGINEERING LAB

IT6413 SOFTWARE ENGINEERING LAB

IT6413 SOFTWARE ENGINEERING LAB

STATE CHART DIAGRAM

IT6413 SOFTWARE ENGINEERING LAB

IT6413 SOFTWARE ENGINEERING LAB

3. Course deta ils

IT6413 SOFTWARE ENGINEERING LAB

2. STUDENT MARK ANALYZING SYSTEM

Int roduc tion

IT6413 SOFTWARE ENGINEERING LAB

The user can create the following reports :

IT6413 SOFTWARE ENGINEERING LAB

IT6413 SOFTWARE ENGINEERING LAB

3. Design of Students Mark analy zing System

Post condit ions:

IT6413 SOFTWARE ENGINEERING LAB

Alternat ive f low:

Post Condit ion:

3.2.1 Basic f low:

IT6413 SOFTWARE ENGINEERING LAB

3.2.2 Alternat ive flow:

4.2 Flow of e ve nts:

IT6413 SOFTWARE ENGINEERING LAB

student is added to the s ystem database.

IT6413 SOFTWARE ENGINEERING LAB

5. Cre ate re s ult/re port

Rate for the academic year).

5.2.2 Alte rnative flow:

IT6413 SOFTWARE ENGINEERING LAB

5.3 Pre condit ion:

IT6413 SOFTWARE ENGINEERING LAB

IT6413 SOFTWARE ENGINEERING LAB

3. MAINTAIN STUDENT INFORMATION

IT6413 SOFTWARE ENGINEERING LAB

3.1 ADD A STUDENT

4.2 UPDATE STUDENT INFORMATION

IT6413 SOFTWARE ENGINEERING LAB

4.3 DELETE A STUDENT

IT6413 SOFTWARE ENGINEERING LAB

IT6413 SOFTWARE ENGINEERING LAB

IT6413 SOFTWARE ENGINEERING LAB

4. MAINTAIN STUDENT INFORMATION

4.1 ADD A STUDENT

IT6413 SOFTWARE ENGINEERING LAB

4.2 UPDATE STUDENT

4.3 DELETE STUDENT

IT6413 SOFTWARE ENGINEERING LAB

STATE CHART DIAGRAM

IT6413 SOFTWARE ENGINEERING LAB

IT6413 SOFTWARE ENGINEERING LAB

IT6413 SOFTWARE ENGINEERING LAB

IT6413 SOFTWARE ENGINEERING LAB

IT6413 SOFTWARE ENGINEERING LAB