Oom Document at Ions Final

8/3/2019 Oom Document at Ions Final

1/29

OBJECT ORIENTED

METHODOLOGY[Year]

OBJECT ORIENTED METHODOLOGY

TUITION PAYMENT

STATEMENT

GENERATOR

MOHAMMAD SALMAN HAMID (TP021171)

MOHAMMAD ABDUL QADAR (TP020913)

INTAKE CODE UC2F1010BIT

MODULE CODE - CE52602-2-OOM

LECTURE'S NAME HOSSEIN TOHIDI

HAND OUT DATE

HAND IN DATE 29TH JULY 2011

OOM Page 1


2/29


TABLE OF CONTENTS

Actor Identifications..............................................................4 Tuition Manager..................................................................4

Student...............................................................................4

Database System................................................................4

System Use Case Identification..........................................5

Login Use case........................................................................6

Real System.....................................................................7

Use Case Specifications......................................................7Main Success Scenario........................................................8

Alternative sequence..........................................................8

Tution manager Sequence Diagram..................................9

Start Chart Diagram (LOGIN)..............................................9

Class Diagram (Tution Manager)......................................10

Student registration Use case..........................................10

Real System...................................................................11Use Case Specification......................................................11

Sequence Diagram...........................................................12

State Chart Diagram.........................................................13

Class Diagram..................................................................13

Subject registration Use case...........................................13

Real System...................................................................14

Use Case Specification......................................................14


State Chart Diagram.........................................................15

Tuition payment statement generation Use case........16

Real System...................................................................18

OOM Page 2


3/29


Manage Tution Record Real System................................18


Add Tuition Record Use case.............................................20

Main Success Scenario......................................................20Sequence Diagram...........................................................22

Sequence Diagram

OOM Page 3


4/29


ACTOR IDENTIFICATIONS

TUITION MANAGER

Tuition Manager is an Actor which boundary of the system and

interacts with the system and even benefits from the system as well.

Thats the reason the Tuition manager is an actor.

STUDENT

Student is another actor which benefits from the system but does not

interact with the system. Student has been identified as an actor

because without the student the system is unable to work.

DATABASE SYSTEM

Database system is a secondary actor because it is not human and it

does interact with the system but not does not benefits from the

system.

OOM Page 4


5/29


SYSTEM USE CASE IDENTIFICATION

Primarily, the simplest of solutions are identified by displaying the

whole use case of the system which contains the whole standard

procedures which is involved in using the Tuition payment system.

As there are number of differences in the use cases it is an

appropriate step to split the above use case sequentially to make

understandings of the developers. The following above figure

illustrates the sequential division of the use cases. In the following

diagram the login use case is included because it is handled by the

primary actor Tuition manager, and the registering the Student and

subject are part of the system use case because they are having a

main success scenario respectively.

OOM Page 5


6/29


Once we are able to have identified the system use cases there is a

need to describe each use case with the use case specifications.

Following are the use case specifications and the sequence diagrams

for each use case identified.

LOGIN USE CASE

USE CASE DIAGRAM

OOM Page 6


7/29


This use case above is able to define the Tuition manager logging in to

the system using his/her login credentials. As this use case is not

concerning the Student who is the secondary actor in the system use

case the student is not mentioned in this use case.

REAL SYSTEM

USE CASE SPECIFICATIONS

Title: Login Type: Detailed Real case

Summary: This Use case starts when the Tuition Manager switches on

the system and tries to access the tuition Payment Statement

generator system

Actors: Tuition manager(Primary), Database System(Secondary)

Creation Date: May 15, 2011

Update Date: May 15, 2011

Version: 1.0

Persons In charge: salman, qadar

OOM Page 7


8/29


Flow of Events

Predictions: Assuming that System is ready to be accessed

MAIN SUCCESS SCENARIO

1. The Tuition Manager keys in

user name in the text box

2. The Tuition Manager keys

his password in the text

box

3. The tuition manager click

submit,

4. Tuition payment statement

generator requests for

verification from the

database system.

5. If the user name and

password which tuition

manager keyed-in is valid

the database system will

validate it and the tuition

manager will login

successfully

6. At last when everything

settled down and the

username and password

validated then the tuition

manager can access thesystem.

ALTERNATIVE SEQUENCE

A1: Invalid Login

OOM Page 8


9/29


The A1 starts at point 5 of the main success scenario

5. The system informs the user that the login credentials are not valid

therefor the system cannot login

The scenario goes back to point 3

Error Sequences: E1: Invalid login for the 3rd time

The E1 sequence starts at point 5 of the main success scenario

7. The user has entered wrong username or password for the third

time

8. System exits the application and the use case fails

TUTION MANAGER SEQUENCE DIAGRAM

START CHART DIAGRAM (LOGIN)

OOM Page 9


10/29


Initially the system stays idle in standby state when the

application is started then the Tuition Manager enters the

username and password in the text boxes provided the system

will be waiting for the user to click the submit button. Then thesystem sends the details to the database system to verify the

login credentials, if the login credentials are invalid then the

system sends the user a message that the login failed and try

again. Then the user enters the login credentials again for the

second time, again the system if the login credentials are valid

the system sends the user a message Login Successful if not

system asks the user to login again. If the login fails for the third

time then the system sends the user that Login failed and exits

the application.

CLASS DIAGRAM (TUTION MANAGER)

The each indivisual Tuition Manager has one indivisual login details

and the login entity depends on the Tuition Manager entity. If the

OOM Page 10


11/29


tution manager entity is deleted automatically the login entity will be

deleted as well.

STUDENT REGISTRATION USE CASE

USE CASE DIAGRAM

This use case defines that the Tuition manager is registering a new

student for a subject

REAL SYSTEM

OOM Page 11


12/29


USE CASE SPECIFICATION

Title: Register Student Type: Detailed Real case

Summary: This use case starts when a student approaches the Tuition

manager to register for a course

Actors: Tuition manager(Primary), Student(Secondary)



Version: 1.0


Flow of Events

Predictions: Assuming that student is registering for the first time

OOM Page 12


13/29


Main Success Scenario

1. Tuition manager enters the

name of the student for

registration.

2. Tuition manager click the

submit button.

3. All data will be save on

database system.

4. Database system will reply

to system that the data

saved.

5. System will display the

message to the tuition

manager that the entry

saved.

As the tuition manager is registering a new student and is not

saved in the database whatever the name the tuition manager gives

the system accepts. This is the reason there are no alternative

sequences or error sequences.

SEQUENCE DIAGRAM

OOM Page 13


14/29


STATE CHART DIAGRAM

The above diagram shows that when a student comes to the

tuition manager to register the Tuition manager starts the process by

selecting the Register student option in the system then enters the

student name and clicks submit button then the system sends the data

to the database and the database replies the system that the data has

been saved the system sends a message to the tuition manager that

the Entry has been saved.

CLASS DIAGRAM

OOM Page 14


15/29


SUBJECT REGISTRATION USE CASE

USE CASE DIAGRAM

REAL SYSTEM

OOM Page 15


16/29


USE CASE SPECIFICATION

Title: Register Subject Type: Detailed Real case

Summary: This use case starts when Tuition Manager registers a new

subject in to the system




Version: 1.0


Flow of Events

Predictions: Assuming that this is the new subject

Main Success Scenario

OOM Page 16


17/29



name of the subject in the

text box

2. Tuition manager will click

the submit

3. All data will save in

database system.

4. Database system will reply

to system that the data

saved.

5. System will display the



saved.

As the subject entered to register is a new subject and there is

no subject with similar name to verify in the database there can be no

errors. In this case there are no alternative scenarios or error

sequences

SEQUENCE DIAGRAM

STATE CHART DIAGRAM

OOM Page 17


18/29


TUITION PAYMENT STATEMENT GENERATION USE CASE

Title: Generate Payment Statement Type: Detailed

Real case

Summary:


Creation Date:

Update Date:

Version: 1.0


Flow of Events

OOM Page 18


19/29


Predictions: Assuming that Student Is registered

1. Tuition manager will enter

the student name.


the submit


generator will verify the

student from the database

4. Database replies to the

system that student is

invalid

5. System will show the

message that the student

didnt register


the student name.


the submit


generator will verify the


9. System will validate the


and will reply the student

details.

10.Tuition payment statement

generator will generate

payment statement.

OOM Page 19


20/29


REAL SYSTEM

MANAGE TUTION RECORD REAL SYSTEM

OOM Page 20


21/29


SEQUENCE DIAGRAM

OOM Page 21


22/29


OOM Page 22


23/29


ADD TUITION RECORD USE CASE

USE CASE DIAGRAM

Title: Generate Payment Statement Type: Detailed

Real case

Summary: This Use case starts when the Tuition manager to registers

a student to a subject, the he has to add a record to the database.


Creation Date:

Update Date:

Version: 1.0

Persons In charge: Salman, qadar.

Flow of Events

Predictions: Assuming that Student Is registered

MAIN SUCCESS SCENARIO


subject name in the text box


student name in the text

OOM Page 23


24/29


box

3. System sends message to

database to verify whether

the student name is

registered or not.

4. Database replies to the

system that student is

invalid

5. System will show the

message that the student

didnt register


the student name

7. System sends message to

database to verify whether

the student name is

registered or not.

8. Data base will send themessage that student is

valid.


the student taught date

10.The system will verify

format of the date

11.System will sends the

message to tuition manager

that the date format is

invalid

12.Tuition manager will enter

OOM Page 24


25/29


the student taught date.

13.The system will verify

format of the date. And

replace that it is ok

14.Tuition manager will enter

the duration

15.Tuition manager will submit

the entered data

16.All the submitted data will

save in the database.

17.Database system will reply

to the system that the data

saved.18.System will display the



saved.

SEQUENCE DIAGRAM

OOM Page 25


26/29


27/29


The above documentation is related to receipt generator system which will generate a

receipt for a tuition master. Which includes register new subject ,register new student

generate payment statement, manage tuition records, add new tuition record, delete

tuition record,& exit application. All the actions are supported by use case diagram and

sequence diagram respectively with a proper login and logout system.

Work breakdown

Salaman hamid (50%)tp021171

OOM Page 27


28/29


Actor Identifications..............................................................4

Tuition Manager..................................................................4

Student...............................................................................4

Database System................................................................4System Use Case Identification..........................................5

Login Use case........................................................................6

Real System.....................................................................7

Use Case Specifications......................................................7

Main Success Scenario........................................................8

Alternative sequence..........................................................8

Tution manager Sequence Diagram..................................9Start Chart Diagram (LOGIN)..............................................9

Class Diagram (Tution Manager)......................................10

Student registration Use case..........................................10

Real System...................................................................11



State Chart Diagram.........................................................13Class Diagram..................................................................13

Mohammed abdul qadar tp020913 (50%)

Subject registration Use case...........................................13

Real System...................................................................14



State Chart Diagram.........................................................15Tuition payment statement generation Use case........16

Real System...................................................................18

Manage Tution Record Real System................................18


OOM Page 28


29/29


Add Tuition Record Use case.............................................20

Main Success Scenario......................................................20


Documents

Oom Document at Ions Final