Case Tools Lab Syllabus

Prepare the following documents for each experiment and develop the software using software engineering methodology. 1. ". (. ,. -. Problem Analysis and Project Planning Thorough study of the problem Identify project scope !bjectives infrastructure #oftware $e%uirement Analysis &escribe the individual Phases' modules of the project Identify deliverables. &ata )odelling *se wor+ products data dictionary use case diagrams and activity diagrams build and test class diagrams se%uence diagrams and add interface to class diagrams. #oftware &evelopment and &ebugging. #oftware Testing Prepare test plan perform validation testing coverage analysis memory lea+s develop test case hierarchy #ite chec+ and site monitor.

List of Experiments: 1. .ourse $egistration #ystem ". /ui0 #ystem (. !nline tic+et reservation system ,. $emote computer monitoring -. #tudent mar+s analysing system 1. 2xpert system to prescribe the medicines for the given symptoms 3. AT) system 4. Platform assignment system for the trains in a railway station 5. #toc+ maintenance 16. 27mail .lient system. Software Required: .ase Tools8 $ational #uite 9in runner 2mpirix :anguages8 .'.;;'<&= 1.( <#&= I>T2$>2T 2?P:!$2$ *): @ront 2nd8 AB A.;; &eveloper "666 Bac+ 2nd8 !racle )#7Access #/:

CONTENTS
Sl. No.
1. ". (. ,. -. 1.

Name of the Experiment

.ourse $egistration #ystem !nline /ui0 #ystem !nline Tic+et $eservation #ystem #tudent )ar+s Analy0ing #ystem AT) #ystem APP2>&I? . CO!RSE RE"#STR$T#ON S%STE&

'roblem Statement As the Cead of Information Technology for $ajala+shmi 2ngineering .ollege you are tas+ed with developing a new students registration system. The college would li+e a new client7server system to replace its much older system. The new system will allow students to register for courses and view report cards from personal computers attached to the campus :A>. Professors will be able to access the system. To sign up to teach courses as well as record grades. At the beginning of each semester students may re%uest a course catalogue containing list course offerings for the semester. Information about each course such as professor department and prere%uisites will be included to help students ma+e information decisions. The new system will allow students to select four course offerings for the coming semester. .ourse offerings will have a maximum of ten students and minimum of three students. A course offering with fewer than ( students will be cancelled. If a course is cancelled the students will be intimated and they will be re%uested to change their course choices. At the end of the semester the students will be able to access the system to view an electronic report card. #ince student grades are sensitive information the system must employ extra security measures to prevent unauthori0ed access. Professors must able to access the online system to indicate which courses will be teaching. They will need to see which students signed up for their course offerings. In addition the professors will be able to record the Drades for the students in each class. (. LO"#N

(. )rief *es+ription The use case describes how a user logs into the .ourse $egistration #ystem. (.( ,low of E-ents (.(. )asi+ ,low This use case starts when the user wishes to :ogin to the .ourse $egistration #ystem 1. The #ystem re%uests that the user enter his'her name and password ". The user enters his'her name and password (. The #ystem validates the entered name and password and logs the user into the #ystem (.(.($lternati-e ,lows Invalid >ame'Password If in the Basic flow the user enters an invalid name and'or password the system displays an error message. The user chooses to either return to the beginning of the Basic flow or cancel the login at which point the use case ends. (..Spe+ial Requirements >one (./'re0Conditions >one (.1'ost0Conditions If the use case was successful the user is now logged into the system. If not the #ystem #tate is unchanged. (.2Extension 'oints >one .. &aintain 'rofessor #nformation .. )rief *es+ription This use case allows the $egistrar to maintain professor information in the registration system. This includes adding modifying and deleting professors from the system. ..( ,low of E-ents

..(. )asi+ ,low This use case starts when the $egistrar wishes to add change and 'or delete professor information in the system. 1. The system re%uests that the $egistrar specify the function he'she would li+e to perform Eeither Add a Professor *pdate a Professor !r &elete a ProfessorF ". !nce the $egistrar provides the re%uested information one of the sub flows is executed. If the $egistrar selected GAdd a professor G the Add a Professor sub flow is executed. If the $egistrar selected G*pdate a professor G the *pdate a Professor sub flow is executed. If the $egistrar selected G&elete a professor G the &elete a Professor sub flow is executed. ..(. . $dd a 'rofessor The system re%uests that the $egistrar enter the professor information. This includes8 7 name 7 &epartment 1. !nce the $egistrar provides the re%uested information the system generates and assigns a uni%ue id number to the professor. The professor is added to the system. ". The system provides the $egistrar with the new professor id ..(. .( !pdate a 'rofessor 1. The system re%uests that the $egistrar enter the professor id ". The $egistrar enters the professor id. The system retrieves and displays the professor information. (. The $egistrar ma+es the desired changes to the professor information. This includes any of the information specified in the Add a Professor sub7flow ,. !nce the $egistrar updates the necessary information the system updates the professor record. ..(. .. *elete a 'rofessor 1. The system re%uires that the $egistrar enter the professor id ". The $egistrar enters the professor id. The system retrieves and displays the professor information. (. The system prompts the $egistrar to confirm the deletion of the professor. ,. The $egistrar verifies the deletion. -. The system deletes the professor from the system.

..(.( $lternati-e ,lows ..(.(. 'rofessor Not ,ound If in the *pdate a Professor or &elete Professor sub7flows a professor with the specified id number does not exist the system displays an error message. The $egistrar can then enter a different id number or cancel the operation at which point the use case ends. ..(.(.( *elete Can+elled If in the &elete A Professor sub7flow the $egistrar decides not to delete the professor the delete is cancelled and the Basic @low is re7started at the beginning. ... Spe+ial Requirements >one. ../ 're0+onditions The $egistrar must be logged onto the system before this use case begins. ..1 'ost0+onditions If the use case was successful the professor information is added updated or deleted from the system. !therwise the system state is unchanged. ..2 Extension 'oints >one /. &aintain Student #nformation /. )rief *es+ription This use case allows the $egistrar to maintain student information in the registration system. This includes adding modifying and deleting students from the system. /.( ,low of E-ents /.(. )asi+ ,low This use case starts when the $egistrar wishes to add change and 'or delete student information in the system.

1. The system re%uests that the $egistrar specify the function he'she would li+e to perform Eeither Add a #tudent *pdate a #tudent !r &elete a #tudentF ". !nce the $egistrar provides the re%uested information one of the sub flows is executed. If the $egistrar selected GAdd a student G the Add a #tudent sub flow is executed. If the $egistrar selected G*pdate a student G the *pdate a #tudent sub flow is executed. If the $egistrar selected G&elete a student G the &elete a #tudent sub flow is executed. /.(. . $dd a Student 1. The system re%uests that the $egistrar enter the student information. This includes8 7 name 7 &epartment ". !nce the $egistrar provides the re%uested information the system generates and assigns a uni%ue id number to the student. The student is added to the system. (. The system provides the $egistrar with the new student id /.(. .( !pdate a Student 1. The system re%uests that the $egistrar enter the student id ". The $egistrar enters the student id. The system retrieves and displays the student information. (. The $egistrar ma+es the desired changes to the student information. This includes any of the information specified in the Add a #tudent sub7flow ,. !nce the $egistrar updates the necessary information the system updates the student record. /.(. .. *elete a Student 1. The system re%uires that the $egistrar enter the student id ". The $egistrar enters the student id. The system retrieves and displays the student information. (. The system prompts the $egistrar to confirm the deletion of the student. ,. The $egistrar verifies the deletion. -. The system deletes the student from the system. /.(.( $lternati-e ,lows /.(.(. Student Not ,ound If in the *pdate a #tudent or &elete a #tudent sub7flows a student with the specified id number does not exist the system displays an error message. The $egistrar

can then enter a different id number or cancel the operation at which point the use case ends. /.(.(.( *elete Can+elled If in the &elete A #tudent sub7flow the $egistrar decides not to delete the student the delete is cancelled and the Basic @low is re7started at the beginning. /.. Spe+ial Requirements >one. /./ 're0+onditions The $egistrar must be logged onto the system before this use case begins. /.1 'ost0+onditions If the use case was successful the student information is added updated or deleted from the system. !therwise the system state is unchanged. /.2 Extension 'oints >one 1. Re3ister ,or Courses 1. )rief *es+ription This use case allows a student to register for course offering in the current semester. The #tudent can also update or delete course selection if changes are made within the add'drop period at the beginning of the semester. The .ourse .atalog #ystem provides a list of all the .ourse offerings for the current semester. 1.( ,low of E-ents. 1.(. )asi+ ,low This use case starts when a #tudents wishes to register for course offerings or to change his'her existing course list. 1. The system re%uests that the students specify the function he'she would li+e to perform Eeither add a .ourse )odify the .ourse listF. !nce the #tudents provide the re%uested information one of the sub flows is executed. If the #tudent #elected GAdd a .ourseH. The Add a .ourse sub flow is executed. If the #tudent #elected G)odify the .ourse :istH. The )odify the .ourse :ist sub flow is executed

1.(. . $ddin3 a Course 1. The system retrieves a list of available course offering from the .ourse .atalog #ystem and displays the list to the #tudent. ". The #tudent selects , primary course offering and " alternate course offerings from the list of available offerings (. !nce the student has made his'her selections the system creates a list for the #tudent containing the selected course offerings. ,. The submit @orm sub flow is executed 1.(. .( &odify the Course List 1. The system retrieves and displays the studentIs current .ourse listE e.g. the course list for the current semesterF ". The system retrieves a list of available course offering from the .ourse .atalog #ystem and displays the list to the students (. The #tudent may update the course selection on the current selection by deleting and adding new course offerings. The students select the course offerings to add from the list of available course offering. The students also selects any course offerings to delete from the existing schedule ,. !nce the student has made his'her selection the system modify the schedule for the students using the selected course offerings -. The #ubmit list sub flow is executed 1.(. .( Submit List @or each selected course offering on the list not already mar+ed as Genrolled I J the system verifies that the #tudent has the necessary prere%uisites that the course offering is open and that there are no schedule conflicts. The system then adds the student to the selected course offering. The course offering the schedule is saved in the system. 1.(.( $lternati-e ,lows. 1.(.(. No S+hedule ,ound If in the )odify the .ourse list sub flow the system is unable to retrieve the studentIs schedule an error message is displayed. The #tudents ac+nowledges the error and the Basic @low is restated at the beginning. 1.(.(.( Course Catalo3 System !na-ailable If the system is unable to communicate with the .ourse .atalog #ystem the system will display an error message to the student. The #tudent ac+nowledges the error message and the case terminates.

1.(.(.. Course Re3istration Closed 9hen the use case starts if it is determined that registration for the current semester has been closed a message is displayed to the #tudent and the use case terminates. #tudents cannot register for course offerings after registration for the current semester has been closed. 1.. Spe+ial Requirements. >one 1./ 're0Conditions The #tudent must be logged onto the system before this use case begins. 2. Sele+t Courses to Tea+h 2. )rief *es+ription This use case allows selecting the course offerings from the course catalog for the courses that he'she is eligible for and wishes to teach in the upcoming semester. 2.( ,low of E-ents 2.(. )asi+ ,low This use case starts when a professor wishes to sign up to teach some course offerings for the upcoming semester. 1. The system retrieves and displays the list of course offerings to the professor. The system also retrieves and displays the list of courses the professor has previously selected to teach. ". The professor selects and'or deselects the course offerings that he'she wishes to teach for the upcoming semester. 2.(.( $lternati-e ,lows 2.(.(. No Course Offerin3s $-ailable If in the basic flow the professor is not eligible to teach any course offerings in the upcoming semester the system will display an error message. The professor ac+nowledges the message band the use case ends. 2.(.(.( Course Catalo3 System !na-ailable

If the system is unable to communicate with the .ourse .atalog #ystem the system will display an error message to the student. The student ac+nowledges the error message and the use case terminates. 2.. Spe+ial Requirements >one 2./ 're0Conditions The professor must be logged on to the system before this use case begins. 2.1 'ost0Condition If the use case was successful the course offerings a professor is scheduled to teach should have been updated. 2.2 Extension 'oints >one 4. Submit "rades 4. )rief *es+ription This use case allows a professor to submit student grades for one or more classes completed in the previous semester. 4.( ,low of E-ents 4.(. )asi+ ,low This use case starts when a professor wishes to submit grades for one or more classes completed in the previous semester. . The system displays a list of course offerings the professor taught in the previous semester. (. The professor selects a course offering .. The system retrieves a list of all the students who were registered the course offering. The system displays each student and any grade that was previously assigned for the offering. /. @or each student on the list the professor enters the grade8 A B . & @ I. The system records the studentIs grade for the course offering. If the professor wishes to s+ip a particular student the grade information can be left blan+ and filled in at later time. The professor may also change grades for a student by entering a new grade.

4.(.( $lternati-e ,lows 4.(.(. No +ourse offerin3s thou3ht If in the basic flow the professor did not teach any course offerings in the previous semester the system will display an error message. The professor ac+nowledges the use case and the use case ends. 4.. Spe+ial Requirements >one 4./ 're0+onditions The professor must be logged on to the system before this use case begins 4.1 'ost0Conditions If the use case was successful student grades for a course offering are updated. !therwise the system remains unchanged. 4.2 Extension 'oints >one 5. 6iew Report Card 5. )rief *es+ription

This use case allows a student to view his'her report card for the previously completed semester. 5.( ,low of E-ents 5.(. )asi+ ,low

This use case starts when a student wishes to view his'her report card for the previous semester. 1.The system retrieves and displays the grade information for each of the course offerings the student completed during the previous semester. ". 9hen the student indicates that he'she is done viewing the grades the use case terminates. 5.(.( $lternati-e ,lows

5.(.(. No 3rade information a-ailable If in the basic flow the system cannot find the any grade information from the previous semester for the student a message is displayed. !nce the student ac+nowledges the message the use case terminates. 5.. 're0+onditions The student must be logged on to the system before this use case begins 5./ 'ost0Conditions The system state is unchanged by this use case. 5.1 Extension 'oints >one Course Re3istration System "lossary .#ntrdou+tion This document is used to define terminology specific to the problem domain explaining terms which may be unfamiliar to the reader of the use case description or !ther project documents. !ften this document can be used as an informal data directory .apturing data definitions so that use case descriptions and other project documents can @ocus on what the system must do with the information. (.*efinitions The glossary contains the wor+ing definition for the +ey concepts in the course registration system. (. .Course A class offered by the university (.( Course Offerin3 A specific delivery of the course for a specific semester you could run the same course in parallel sessions in the semester. Includes the days of the wee+ and times it offered. (.. Course Catalo3 The unabridged catalog of all courses offered by the university.

(./ ,a+ulty All the professors teaching at the university (.1 ,inan+e System The system used for processing billing information. (.2 "rade The evaluation of a particular student for a particular course offering. (.4 'rofessor A person teaching class at the university. (.5 Report Card All the grades for all courses ta+en by a student in a given semester. (.7 Roster All the students enrolled in a particular course offering. (. 8 Student A person enrolled in a class at the university. Course Re3istration System Supplementary Spe+ifi+ation . Ob9e+ti-es The purpose of this document is to define re%uirements of the .ourse $egistration #ystem. This #upplementary #pecification lists the re%uirements that are not readily captured in the use cases of the use case model. The #upplementary #pecifications and the use7case model together capture a complete set of re%uirements on the system. (. S+ope This #upplementary #pecification applies to .ourse $egistration #ystem which will be developed by the !!A& students. This #pecification defines the non7functional re%uirements of the systemK such as reliability usability performance and supportability as well as functional re%uirements that are common across a number of use cases. .. Referen+es

>one /. ,un+tionality )ultiple users must be able to perform their wor+ concurrently If a course offering becomes full while a student is building a schedule include that offering the student must be notified. 1. !sability The des+top user7interface shall be 9indows 5-'54'"666'xp compliant. 2. Reliability The #ystem shall be available ", hours a day 3 days a wee+ with no more than 16L down time. 4. 'erforman+e 1. The #ystem shall support up to 1666 simultaneous users against the central database at any given time and up to -66 simultaneous users against the local servers at any one time. ". The #ystem must be able to complete 46L of all transactions within " minutes. 5. Supportability >one. 7. Se+urity 1.The #ystem should prevent students from changing any schedules other than their own and professors from modifying assigned course offerings for other professors. ". !nly Professors can enter grades for students. (. !nly the $egistrar is allowed to change any student information. 8. *esi3n Constraints. The system shall integrate with an existing legacy system the .ourse catalog system which is an $&B)# database. The system shall provide a window7based des+top interface. *se case diagram for Course Re3istration System:

student

View Report Card Course Catalog Login Register for Courses

Professor Select Courses to teach

Submit Grades

$egistrar Maintain Professor Information

Maintain Student Information

(. :!#; S%STE& 'roblem Statement !nline /ui0 #ystem has to be developed for conducting a %ui0 as part of &epartment Technical symposium RECC$. The #ystem developed should contain following features 1. The number of participants should be of (6. ". The duration for %ui0 is (6 minutes so a timer has to +ept which should show time duration. (. The number of %uestions should be ,6 chosen randomly from the database in ( different areas namely iF Information Technology iiF logical reasoning and iiiF Deneral =nowledge.

,. The %uestions should be of objective type with multiple options. @or each correct answer the participant will receive 1Point and wrong answer ."-Point will be deducted for each wrong answer. -. At the end of the %ui0 the user score will be displayed. 1. !nce a #tudent answered for %uestion he canIt changes his answer later. (. LO"#N (. )rief *es+ription The use case describes how a Participant logs into the /ui0 #ystem (.( ,low of E-ents (.(. )asi+ ,low This use case starts when the Participant wishes to :ogin to the /ui0 #ystem 1. The #ystem re%uests that the participant enter his'her name and password ". The participant enters his'her name and password (. The #ystem validates the entered name and password and logs the participant into the #ystem (.(.( $lternati-e ,lows Invalid >ame'Password If in the Basic flow the participant enters an invalid name and'or password the system displays an error message. The participant chooses to either return to the beginning of the Basic flow or cancel the login at which point the use case ends. (.. Spe+ial Requirements The >umber of participants should be (6 (./ 're0Conditions >one (.1 'ost0Conditions If the use case was successful the participant is now logged into the system. If not the system #tate is unchanged. (.2 Extension 'oints >one .. Sele+t Options to $nswer

.. )rief *es+ription This use case allows the Participant to select appropriate answer to the %uestion. ..( ,low of E-ents ..(. )asi+ flow This use case starts when the participant logs into the system. The Participant will be given a set of %uestions with answers in multiple options. The participant selects the answer from the set of options. !nce the participant answered for a %uestion next %uestion will be displayed. ..(. $lternate ,low !nce the time slot allotted for the participant is over scorecard will be displayed. ... Spe+ial Requirements >one ../ 're0Conditions The Participant must login into the #ystem for answering the %uestion ..1 'ost0Conditions If the use case was successful the participant will be able to view the next %uestion. ..2 Extension 'oints >one /. *isplay S+ore Card /. )rief *es+ription The use case gives the scorecard along with >o of .orrect and wrong answers /.( ,low of E-ents /.(. )asi+ ,low !nce the participant had completed answering to the %uestions within the stipulated time he'she will be given a scorecard with final score.

/.( $lternati-e ,low >one /.. Spe+ial Requirements >one /./ 're0Conditions The participant should have completed the %uestions within stipulated time. /.1 'ost0Conditions If the use case was successful the participants can logout from the system /.2 Extension 'oints >one 1. <inner List 1. )rief *es+ription This use case gives winner list based on the scores obtained by the participant 1.( ,low of E-ents 1.(. )asi+ ,low This use case gives the coordinator the winner list based on the scored obtained 1.(.2 $lternati-e ,low If the coordinator logged into the system even before the %ui0 was over he will empty :ist. 1.. Spe+ial Requirements >one 1./'re0Conditions If all the participants had answered for the %uestions then the winner list has to be generated.

1.1'ost0Conditions >one 1.2Extension 'oints >one :!#; S%STE& "LOSS$R% . #ntrodu+tion This document is used to define terminology specific to the problem domain explaining terms which may be unfamiliar to the reader of the use7case description or other project documents. !ften this document can be used as an informal data dictionary capturing &ata definitions so that use7case descriptions and other project documents can focus on what the system must to with the information. (. *efinitions The glossary contains the wor+ing definitions for the +ey concepts in the /ui0 system. (. 'arti+ipant A Person he or she who participates in the /ui0 .ompetition. (.( Lo3in ,orm .hec+s for Participant >ame and password of the participant. (.. :uestions for the :ui= /uestions for the %ui0 to selected from ( different tables namely I.T. :ogic and D= (./ Coordinator Person who conducts the %ui0 (.1 S+ore Card 9hich displays the scores obtained by the participant. (.2 Timer *isplay Timer &isplay which displays the time left for answering.

(.4 S+hedule Time allotted for a Participant. :ui= System Supplementary Spe+ifi+ation . Ob9e+ti-es The purpose of this document is to define re%uirements of the /ui0 #ystem. This #upplementary #pecification lists the re%uirements that are not readily captured in the use cases of the use case model. The #upplementary #pecifications and the use7case model together capture a complete set of re%uirements on the system. (. S+ope This #upplementary #pecification applies to /ui0 system which will be developed by the !!A& students. This #pecification defines the non7functional re%uirements of the systemK such as reliability usability performance and supportability as well as functional re%uirements that are common across a number of use cases. .. Referen+es >one /. ,un+tionality )ultiple users must be able to perform their wor+ concurrently If the Participant completes (6)ins allotted for him'her he or she should notified with message your time slot is over. 1. !sability The des+top user7interface shall be 9indows 5-'54'"666'xp compliant. 2. Reliability The #ystem should function properly for allotted time slot and produces score card with no more than 16L down time. 4. 'erforman+e 1. The #ystem shall support up to -66 simultaneous users against the central database At any given time and up to -66 simultaneous users against the local servers at any one time. ". The #ystem must be able to complete 46L of all transactions within " minutes.

5. Supportability >one. 7. Se+urity 1.The #ystem should secure so that only registered participant can ta+e part in /ui0. ".!nce the participant had answered for a %uestion he'she canIt change the answer later. 8. *esi3n Constraints. The system shall provide a window7based des+top interface. *se case diagram for Online :ui= System:

Login Participant "ui# Database

Select n !ption

Display Score Card

Coordinator $inner%s List

..ONL#NE T#C>ET RESER6$T#ON S%STE& 'roblem Statement

!nline tic+et reservation system for railway department has to be developed. The #ystem developed should contain following features 1. The #ystem should provided information about arrival and departure trains along with information about stations through which it passes. ". #earch about train passing through stations can be obtained either by means of train no train name or specifying the source and destination stations. (. 9hile displaying information about train it has provide following informationIs aF #tations through which train passes along with arrival and departure time. bF Availability of seats in different classes along with waiting list. ,. 9hile reserving tic+et online the system obtain following informationIs from the user aF Passenger name #ex Age Address bF bF .redit .ard >o Ban+ >ame cF .lass through passenger is going to travel i.e @irst class or #econd class or A. dF Train no and Train name &ate of <ourney and number of tic+ets to be boo+ed. -. Based on the availability of tic+ets the tic+et has to be issued. The tic+ed issued should contain the following informationIs P>$ >! Train >o &ate =.). no of adults and children Tic+et >o .lass Tic+et >o .oach #eat'Berth #ex Age $eservation fee Total .ash Train >ame &eparture time. 1. .ancellation of boo+ed tic+ets should be available. (.LO"#N (. )rief *es+ription The use case describes how Passenger logs into the !nline Tic+et $eservation system (.( ,low of E-ents (.(. )asi+ ,low This use case starts when the passenger wishes to :ogin to the !nline Tic+et $eservation system 1. The #ystem re%uests that the passenger enter his'her name and password ". The passenger enters his'her name and password (. The #ystem validates the entered name and password and logs the passenger into the #ystem (.(.2 $lternati-e ,lows ".".".1Invalid >ame'Password If in the Basic flow the passenger enters an invalid name and'or password the system displays an error message. The passenger chooses to either return to the beginning of the Basic flow or cancel the login at which point the use case ends. (..Spe+ial Requirements

>one (./'re0Conditions >one (.1'ost0Conditions If the use case was successful the passenger is now logged into the system. If not the system #tate is unchanged. (.2Extension 'oints >one .. *isplay Train List .. )rief *es+ription This use case gives passenger the list of trains along with information about the train name #tations passes Arrival and &eparture time etc ..( ,low of E-ents ..(. )asi+ ,low This use case gives passenger information about each train namely train no train name #tations passes Arrival Time &eparture Time etc ..(.( $lternati-e ,lows >one ...Spe+ial Requirements >one ../'re0Conditions >one ..1'ost0Conditions If the use case was successful the passenger information about each train namely train no train name #tations passes Arrival Time &eparture Time etc

..2Extension 'oints >one /. Sear+h for Train /. )rief *es+ription This use case helps the passenger to search for information about a Train /.(. )asi+ flow The passenger can obtain train information either by entering train no or #ource and &estination #tation 1. If the passenger train no gives the information about train ". If the passenger enter #ource and &estination #tation from list gives information about list of trains passing through station. @rom the list lin+ will be provided to each train which contains the information /.(.( $lternate flow If the passenger enters an invalid train no then it gives error message invalid train no and as+s the passenger to enter a valid train no. /..Spe+ial Requirements >one /./'re0Conditions >one /.1'ost0Conditions If the use case was successful the passenger can able to view the list of trains. /.2Extension 'oints >one 1.Reser-ation 1. )rief *es+ription This use case helps the passenger to reserve for tic+ets in a train

1.(. )asi+ flow 1. The user reserves the tic+et by giving following aF Passenger name #ex Age Address bF .redit .ard >o Ban+ >ame cF .lass through passenger is going to travel i.e @irst class or #econd class or A. dF Train no and Train name &ate of <ourney and number of tic+ets to be boo+ed. ". If the tic+et is available in a train then the tic+et will be issued with P>$ >o.else the tic+et will be issued with a waiting list number. 1.(.( $lternati-e flow If the passenger gives an invalid credit card no or specified a ban+ where does have any account. 2rror message will be displayed. 1..Spe+ial Requirements >one 1./'re0Conditions The passenger has to decide about the train he is going to travel. 1.1'ost0Conditions If the use case was successful the passenger will get the tic+et. 1.2Extension 'oints >one 2. Can+ellation 2. )rief *es+ription This use case helps the passenger to cancel the tic+et which he'she had boo+ed earlier 2.(. )asi+ flow This use case used by passenger to cancel the tic+et which he'she boo+ed earlier by 2ntering P>$ >o. The cancellation has been done reallocating the tic+ets allotted to the Passenger. 2.(.( $lternate flow If the Passenger had entered invalid P>$ >o then has been as+ed to enter valid P>$ >o.

2..Spe+ial Requirements >one 2./'re0Conditions The Passenger had reserved tic+ets in a train. 2.1'ost0Conditions If the use case was successful the passenger can cancel the tic+et. 2.2Extension 'oints >one 4 Ti+?et Status 4. )rief *es+ription The passenger to +now status of tic+et has used this usecase by entering P>$ >o. 4.(. )asi+ flow 1. The passenger should give P>$ >o to +now the status of tic+et which he'she boo+ed earlier. ". If the P>$ >o is valid the status of the tic+et will be displayed. 4.(.( $lternate flow If passenger had entered an invalid no or P>$ >! which does not exists then error )essage will be displayed. 4.. Spe+ial Requirements >one 4./ 're0Conditions The Passenger had reserved tic+ets in a train. 4.1 'ost0Conditions If the use case was successful the passenger can view status of the tic+et.

4.2 Extension 'oints >one ONL#NE T#C>ET RESER6$T#ON S%STE& "LOSS$R% *efinitions The glossary contains the wor+ing definitions for the +ey concepts in online tic+et $eservation #ystem Ti+?et Tic+et issued to the Passenger. Train List :ist of trains passing through #tations along with arrival and departure time Train Status #tatus of availability of tic+ets on a particular train on dates specified Ti+?et )oo?in3 System The #ystem which ta+es care of tic+et reservation 'assen3er Information about the Passenger reserved the tic+et. Online Ti+?et Reser-ation System Supplementary Spe+ifi+ation . Ob9e+ti-es The purpose of this document is to define re%uirements of the !nline Tic+et $eservation #ystem This #upplementary #pecification lists the re%uirements that are not readily captured in the use cases of the use case model. The #upplementary #pecifications and the use7case model together capture a complete set of re%uirements on the system. (. S+ope This #upplementary #pecification applies to the which !nline Tic+et $eservation #ystem will be developed by the !!A& students. This #pecification defines the non7 functional re%uirements of the systemK such as

reliability usability performance and supportability an as well as functional re%uirement that is common across a number of use cases. .. Referen+es >one /. ,un+tionality )ultiple users must be able to perform their wor+ concurrently If the no of tic+ets available in a train is reserved the then tic+et issued to passenger should be notified. 1. !sability The des+top user7interface shall be 9indows 5-'54'"666'xp compliant. 2. Reliability The #ystem shall be available ", hours a day 3 days a wee+ with no more than 16L down time. 4. 'erforman+e aF The #ystem shall support up to n number of simultaneous users against the central database at any given time and up to 1666 simultaneous users against the local #ervers at any one time. bF The #ystem must be able to complete 46L of all transactions within " minutes. 5. Supportability >one.

7.Se+urity 1.The #ystem should secure so that intruders or hac+ers canIt cancel tic+et issued to one passenger. ".!nce the participant had answered for a %uestion he'she canIt change the answer later. 8. *esi3n Constraints. The system shall provide a window7based des+top interface. *se case diagram for Online Ti+?et Reser-ation :

&rain List Passenger

&rain Database Search (or &rain

Reser)ation &ic'et Status Cancellation *an'

/. ST!*ENT &$R>S $N$L%;#N" S%STE& .'roblem Statement #tudent mar+s analy0ing system has to be developed for analy0ing obtained by the students who scored in #emester 2xamination The #ystem should provide following functionalities 1. The #ystem obtains following informationIs from the faculty generates report $oll >o >ame &epartment #emester )ar+s obtained in each subject. ". The total for each student should be calculated and ran+ed based on total and pass in all the subject appeared.

(. The @inal report should display ran+ percentage .lass Pass'@ail #tatus for each student. ,. The report should also contain information about no of students passed failed list of students who got more than 16L in each subject overall list of students who got MN16L (. Lo3in (. )rief *es+ription The use case describes how @aculty logs into the #tudent )ar+s Analy0ing #ystem. (.( ,low of E-ents (.(. Basic Flow This use case starts when the @aculty wishes to :ogin to the #tudent )ar+s Analy0ing #ystem. 1. The #ystem re%uests that the @aculty enter his'her name and password ". The @aculty enters his'her name and password (. The #ystem validates the entered name and password and logs the @aculty into the #ystem ".".2 Alternative Flows Invalid >ame'Password If in the Basic flow the @aculty enters an invalid name and'or password the system displays an error message. The @aculty chooses to either return to the beginning of the Basic flow or cancel the login at which point the use case ends. (..Spe+ial Requirements >one (./'re0Conditions >one (.1'ost0Conditions If the use case was successful the @aculty is now logged into the system. If not the system #tate is unchanged. (.2Extension 'oints >one .. Enter &ar?s for ea+h Student

.. )rief *es+ription The @aculty uses this usecase to enter mar+s for each student. ..( ,low of E-ents ..(. Basic flow The @aculty uses this usecase to enter mar+s for each student. The faculty enters the following details namely $oll >o #tudent >ame &epartment )ar+s for each student. (."." Alternative Flows If faculty not entered any details or invalid mar+s then gives error )essage ... Spe+ial Requirements >one ../'re0Conditions The @aculty must logged into the system ..1'ost0Conditions If this *se case was successful #tudent )ar+ Analysis $eport will be generated for the #tudent. ..2Extension 'oints >one /.6iew Report /. )rief *es+ription The @aculty or #tudent uses this usecase to #tudent )ar+ Analy0ing $eport. /.( ,low of E-ents /.(. Basic flow The Actor uses this usecase view the $eport .The report contains the following details >amely $oll >o #tudent >ame )ar+s in each subject total class Pass'@ail #tatus >o of subjects failed $an+.

Apart from this there is a separate report !verall Pass percentage of class >o of students cleared in @irst class !verall Top ( persons of the class. /.(.(. Alternative Flows If the )ar+s is not entered for all the students the use case will as+ the faculty to the enter the mar+s. /..Spe+ial Requirements >one /./'re0Conditions The @aculty must entered mar+s for all the students in a class. /.1'ost0Conditions >one /.2Extension 'oints >one ST!*ENT &$R>S $N$L%;#N" S%STE& "LOSS$R% *efinitions The glossary contains the wor+ing definitions for the +ey concepts in the student mar+s analy0ing. ,a+ulty@Class Counselor Person who enter the mar+s for generating report &ar? list :ist contains the set of mar+s obtained by each student. Result analysis Report The report should contain analysis of student mar+s obtained in the semester exam. Student #tudent who mar+ to be analy0ed

Student &ar?s analysis System Supplementary Spe+ifi+ation . Ob9e+ti-es The purpose of this document is to define re%uirements of the #tudent )ar+ analysis system. This #upplementary #pecification lists the re%uirements that are not readily captured in the use cases of the use case model. The #upplementary #pecifications and the use7case model together captures a complete set of re%uirements on the system. (. S+ope This #upplementary #pecification applies to the #tudent )ar+ analysis #ystem which will be developed by the !!A& students. This #pecification defines the non7functional re%uirements of the systemK such as reliability usability performance and supportability as well as functional re%uirements that are common across a number of use cases. .. Referen+es >one /. ,un+tionality @aculty can enter mar+ only for the registered students 1. !sability The des+top user7interface shall be 9indows 5-'54'"666'xp compliant. 2. Reliability The #ystem should function properly for allotted time slot and produces report with no more than 16L down time. 4. 'erforman+e The #ystem must be able to complete 46L of all transactions within " minutes. 5. Supportability >one. 7. Se+urity 1.The #ystem should secure so that only faculty can enter mar+s and obtain reports.

". )ar+s should be modifies only by the faculty. 8. *esi3n Constraints. The system shall provide a window7based des+top interface.

*se case diagram for Student &ar?s $naly=in3 System:

Student

View Report

Login (aculty student Database

+nter the mar's for each Student

1. $T& S%STE& .'roblem Statement To develop an AT) #ystem for I.I.I Ban+ The #ystem developed should contain the following features 1.The .ustomer login into the system using .redit .ard >o or &ebit .ard no and Pin >umber. The system chec+s for validation. ".The #ystem %ueries the customer for the type of account either #.B Account or .redit. After getting the type of account the system shows the amount left. (.The #ystem then %ueries the customer for re%uired amount. The user enters the amount and gets the money. (. LO"#N (. )rief *es+ription The use case describes how a *ser logs into the AT) #ystem

(.( ,low of E-ents (.(. )asi+ ,low This use case starts when the actor wishes to :ogin to the AT) #ystem. 1.The #ystem re%uests that the actor enter his'her name and password ".The actor enters his'her name and password (.The #ystem validates the entered name and password and logs the actor into the #ystem ".".2 $lternati-e ,lows Invalid >ame'Password If in the Basic flow the actor enters an invalid name and'or password the system displays an error message. The actor choose to either return to the beginning of the Basic flow or cancel the login at which point the use case ends. (..Spe+ial Requirements >one (./'re0Conditions >one (.1'ost0Conditions If the use case was successful the actor is now logged into the system. If not the system #tate is unchanged. (.2Extension 'oints >one ..&aintain Customer #nformation .. )rief *es+ription This use case starts when administrator wants to add delete or modify .ustomer Information ..( ,low of E-ents ..(. )asi+ ,low

This use case starts when the Administrator wishes to add change and'or delete .ustomer information in the system. 1. The system re%uests that the Administrator specify the function he'she would li+e to perform. ". !nce the Administrator provides the re%uested information one of the sub flows is executed. If the Administrator selected GAdd a .ustomerH the $dd a Customer sub flow is executed. If the Administrator selected G*pdate a .ustomerH the !pdate a Customer sub flow is executed. If the Administrator selected G&elete a AdministratorH the *elete a Customer sub flow is executed. ..(. . $dd a Customer The #ystem re%uests that the Administrator enter the .ustomer information. This includes 7name 7.redit .ard >umber 7 Pin >umber 7Account Type 7Amount 7 Address ..(. .( !pdate a Customer 1.The #ystem re%uest that the Administrator enter the .redit .ard >umber. ".The Administrator enters the .redit .ard >umber. The #ystem retrieves and displays the .ustomer information. (.The Administrator ma+es the desired changes to the .ustomer information. This includes any of the information specified in the $dd a Customer sub flow. ,.!nce the Administrator updates the necessary information the system updates the .ustomer record. ..(. .. *elete a Customer 1.The #ystem re%uest that the Administrator enter the .redit .ard >umber ".The Administrator enters the .redit .ard >umber. The #ystem retrieves and displays the .ustomer information. (.The #ystem prompts the Administrator to confirm the deletion of the customer. ,.The Administrator verifies the deletion -.The #ystem deletes the .ustomer from the system. ... $lternati-e ,low

If administrator gives invalid information i.e.trying to search for a person who does not have account then error occurs. ../ Spe+ial Requirements >one ..1 're Condition The Administrator must logged into the system ..2 'ost Condition If the use case was successful the administrator can do modification ..4 Extension 'oint >one /.Transa+tion /. )rief *es+ription This use case starts when the customer wants withdraw amount from Account. /.( ,low of E-ents /.(. )asi+ ,low 1.The Actor enters into the system by entering .redit card no followed by Pin >umber. The #ystem validates and gives access to the system if credit card no and pin number is valid ".The #ystem shows the customer about the amount left in his account and %ueries the customer the amount he'she needed. (.The .ustomer enters the amount and waits for money. ,.The #ystem chec+s for the minimum balance and returns the money. /..$lternati-e ,low If .ustomer wants to ta+e amount more than minimum amount left in his Account error message will be displayed. /./Spe+ial Requirements >one

/.1 're0Condition The Actor must logged into the #ystem /.2 'ost0Condition If the use case was successful the customer will receive the amount. $T& System "lossary .#ntrodu+tion This document is used to define terminology specific to the problem domain explaining terms which may be unfamiliar to the reader of the use7case description or other project &ocuments. !ften this document can be used as an informal data dictionary capturing &ata definitions so that use7case descriptions and other project documents can focus on what the system must to with the information. (.*efinitions The glossary contains the wor+ing definitions for the +ey concepts in the AT) #ystem. (. Customer The Person who is having account in the Ban+. (.( Customer #nformation :ist of .ustomers having account in the Ban+. (.. )an? *atabase .ontains information about accounts and customer. (./ $dministrator The person responsible for administrating AT) #ystem. $T& System Supplementary Spe+ifi+ation .Ob9e+ti-es The purpose of this document is to define re%uirements of the $T& System #upplementary #pecification. This #upplementary #pecification lists the re%uirements

that are not readily .aptured in the use cases of the use case model. The #upplementary #pecifications And the use7case model together capture a complete set of re%uirements on the system. (.S+ope This #upplementary #pecification applies to the $T& System #upplementary #pecification which will be developed by the !!A& students. This #pecification defines the non7functional re%uirements of the systemK such as reliability usability performance and supportability as well as functional re%uirements that are common across a number of use cases. ..Referen+es >one /.,un+tionality #ystem must help the .ustomer to do Transaction 1.!sability The #ystem should wor+ in windows des+top interface 2.Reliability >one 4.'erforman+e 1.The #ystem shall support up re%uest from 1 user at a time. ".The #ystem must be able to complete 46L of all transactions within " minutes. 5.Supportability >one. 7.Se+urity The #ystem should secure so that only customer can to transaction 8. *esi3n Constraints. The system shall provide a window7based des+top interface.

*se .ase diagram for $T& System8

Customer

Login

&ransaction

*an' ccount

&M System dministrator Maintain Customer Information

$ppendix 0 $ Steps to Create !se Case Spe+ifi+ation *o+ument usin3 Requisite 'ro 1. .reate a new project in $e%uisite Pro. Dive it a name .2g8 Project1.If the user name dialog box appears give any user name. (. $ight clic+ the project name go to properties. .. .hoose the tab do+ument types. ,. .lic+ the Add button. The do+ument types dialog box will appear. -. Dive the name of the document. E2g 8 use case document F 1. Type the file extension.Eit can be anythingF 3. Do to the requirements type dialog box. 4. Dive the name of the re%uirement Efor eg8 use case re%uirementsF 5. Type the re%uirements type prefix E2g8 *.F 16. .lic+ !=. 11. .hoose $*P *se .ase #pecification in the document type. 1". .lic+ !=. 1(. $ight clic+ Project name and go to properties /. .hoose new do+ument 1-. The use case specification template will appear.

Steps to draw the !se Case *ia3ram: 1. .lic+ main under the use +ase -iew. The use case window will appear. ". .lic+ the actor icon from the toolbox. &rag the mouse and clic+ it in the use case window. The actor will be drawn. (. #imilarly use cases and the association arrows can be drawn. ,. If a given diagram is not available in the toolbox right clic+ the toolbox. A menu will appear. Do to +ustomi=e. A dialog box will appear which will allow you to add any other tool to the existing toolbox. Steps to draw the !se Case Reali=ation. . $ight clic+ the lo3i+al -iew. Do to new and select a new pac+age. >ame the pac+age as use +ase reali=ation. (. $ight clic+ the pac+age use +ase reali=ation go to new and create another new pac+age which should have the name of the use case being reali0ed.E2g8loginF. .. *nder the pac+age lo3in create a new class diagram. >ame the class diagram as tra+eability. /. &ouble clic+ the class diagram tra+eability. 1. &raw a use case in the class diagram 2. Do to Open Spe+ifi+ation. Do to stereotype. .hoose use +ase reali=ation.. 4. &rag the particular use case having the same name E 2g8lo3inFfrom the use case view. 5. &raw the reali0ation arrow. 7. $ight clic+ the use case reali0ation E2.g.8lo3inF and create a new se%uence diagram. 8. $ight clic+ the pac+age lo3in and create the classes which will be used in the se%uence diagram . &raw the se%uence diagram using the tool given in the toolbox. (. .lic+ @- to generate the collaboration diagram .. $ight clic+ each message in the se%uence diagram a menu will appear. .lic+ new operation to convert the messages into operations. /. $ight clic+ the pac+age lo3in and create a new class diagram. >ame it as A!P.. 1. &rag all the classes that were used in the se%uence diagram to the A!P.. 2. &raw the associations and other relations between the different classes between the different classes. 4. Include the attributes and parameters of the operations in the classes. Steps to 3enerate the S?eleton Code . ". .. ,. -. 1. #elect all the classes in the 6O'. Do to Tools in the tas+bar. Do to 6isual )asi+ choose Component $ssi3nment Tool. The Component $ssi3nment Tool dialog box appears. &rag the unassigned classes to Aisual Basic. .lic+ !=.

3. Do to Tools in the Tas+bar again. 4. Do to Aisual Basic. .hoose the Code !pdate Tool. 5. Proceed according to instructions. 16. The s+eleton code will get generated.