FSB project uml documentation,unified modeing language

CS-322 Submitted By:

Name Roll No

Gul Sher Ali (Section “A”) 09606019-023

Ghulam Mustafa( Scetion”B”)

09606019-032

Hafiz Zubair latif (Section”B”)

09606019-033

Hafiz Moh. Umair(Section”B”) 09606019-035

Project : “First Student Bank” UML documentation

Submitted To:

Mam Saliha Zahoor Project : “First Student Bank” UML documentation

BS(CS)-6th Semester

Faculty Of Computing & IT

University Of Gujrat

Dated:

13-06-2012

P a g e | 1

Preface:

UML Diagrams

Sr no. Topic Page no

1 Case Study 2 2 Fully Dressed Use Case 3-8 3 Use Case Diagram 9 4 Domain Model 10 5 Design Model 11 6 Sequence Diagram 12-15 7 Communication Diagram 16-19

P a g e | 2

Case Study:

First Student Bank

There is a bank named as “First Student Bank”, in which the user can perform transactions in

three different ways; by ATM, through online service or by personal visit to the bank. When he

has to perform transaction through ATM, he has four options; either he can transfer money to

some other account or he can withdraw money or can transfer amount or he can just check the

account balance. The user is authenticated through a pin code here.

In case of online transaction, the user can transfer money to some other account, have balance

inquiry and may also generate balance inquiry receipt. The user is logged on to the system after

authentication based on a username, password and pin. If the user visits the bank personally,

he has to interact with the cashier who performs different operations according to the user’s

request. These operations are executed by the cashier through a desktop application installed

on his computer. The operations include deposit, transfer, withdrawal, balance inquiry and

transfer of money.

All the data for application form will be taken from official form / cheque. If user wants to

deposit, employee have to enter amount, account. If the transaction is withdrawn, employee

has to enter amount, account no, cheque. If transaction is transfer, employee will enter account

no, amount, receiver account no. if transaction is balance inquiry, employee will enter account

no of client.

P a g e | 3

Fully Dressed Use Case:

1. Online Transaction - use case specifications

1.1 Brief Description

Account transaction begins when student is successfully logged in to the site. Several menus

where displayed related to profile of student and the recent transactions and the current

account balance.

The main purpose of using online account transactions is to transfer cash from one account to

another for this purpose the student is provided fields to specify the accounts to which he is

transferring amount. After every transaction a confirmation is displayed to student.

The student is also provided the possibility to change the account login password, but not the

user id, every transaction is added to the bank database.

Flow of Events

1.2 Basic flow

1. User enters username and password.

2. Bank Database validates the user.

3. On success user can transfer money, change his password and view his profile.

1.3 Alternate Flow

If in the basic flow, the details specified by user are invalid then he is informed

login is failed .Then the user may quit the system or he may create a new account.

1.4 Pre Conditions

The user should have a valid account in the bank.

1.5 Post Conditions

The account database is modified after transaction.

2. Client Desktop transaction- Use case specifications 2.1 Brief Description Client desktop is given to each of bank employees and they are provided with account

logins with a user id and a password. Every employee switches on his desktop and login to his

account through which he can communicate with bank database.

An employee can have operations like withdrawal of money, furnishing the DD/ cheque

and students may want to deposit money.

Bank employee is allowed to modify the database accordingly. And the intended services are

provided to the students.

P a g e | 4

Flow of Events

2.2 Basic flow

1. Employee enters his username and password.

2. Bank Database validates the employee.

3. On success employee can withdraw or deposit money and

DD/cheque of the students.

2.3 Alternate Flow

If in the basic flow, the details specified by employee are invalid the he is informed that

his login is failed .Then the person is not employee of the bank and he is not having authority to

perform those actions.

2.4 Pre Conditions

The employee must possess a account login and password.

2.5 Post Conditions

The account database is modified after transaction. Employee perform transaction on

dd/cheque from user.

3. Login- Use case specifications 3.1 Brief Description

The online student or a bank employee has to login to access their accounts from bank

database. A vendor is provided for communication with bank’s database and this vendor

provides safety and atomicity. A user may be an invalid user so the system has to prompt the

person appropriately.

Flow of Events

3.2 Basic flow

1. User enters username and password.

2. Bank Database validates the user.

3. On success user can precede the transaction.

3.3 Alternate Flow

If in the basic flow, the details specified by user are invalid the he is informed that his login is

failed.

3.4 Pre Conditions

The user must possess a login id and password

3.5 Post Conditions

None.

P a g e | 5

4. Logout- Use case specifications 4.1 Brief Description The person who ever logged in to the system or bank database has to logout after all

the work is over. The vendor provided for communication is now closed from database. Flow of Events

4.2 Basic flow

1. User clicks the logout menu

2. All the transactions he performed are reflected in the bank database.

4.3 Alternate Flow

If in the basic flow, if the internet connection is lost user must refresh the page again.

4.4 Pre Conditions

The user should have been logged in already.

4.5 Post Conditions

None.

5. Invalid Login- Use case specifications 5.1 Brief Description

If a person with a invalid user id or password details want login to the system, the

system has to prompt the person about failure and should not open the vendor of

communication until he furnishes valid user id & password.

Flow of Events

5.2 Basic flow

1. User enters username and password.

2. Bank Database validates that the login is invalid.

3. Further he may not be allowed to proceed until enters a valid login.

5.3 Alternate Flow

1. If the user enters a valid login he must be allowed to proceed further.

5.4 Pre Conditions

None.

5.5 Post Conditions

None.

6. Pin change - Use case specifications 6.1 Brief Description

The student is going to change the pin code for his card. The system will first ask for

P a g e | 6

present pin and then new pin and confirms the new pin. On completion the system will update

the new pin on bank database.

Flow of Events

6.2 Basic flow

1. Student chooses option for changing pin

2. ATM ask for current pin

3. Student enters current pin

4. ATM asks for new pin and to confirm ask for reenter new pin

5. ATM update new pin in bank database

6.3 Alternate Flow

If new pin not match with reentered pin. ATM machine gives error

6.4 Pre Conditions

The student must be login to change pin.

6.5 Post Conditions

The user should not enter the pin number more than the number of trials.

7. ATM transaction- Use case specifications 7.1 Brief Description

If a student approaches an ATM, the person is requested to insert card. After inserting

the card it is checked for validity if the card is valid transaction continues. And then pin

validation is done; if the pin is invalid the transaction is doesn’t allowed. The student may have

transactions like checking balance, draw amount , transfer amount and change pin code of

card. If there are less funds the transaction is sustained.

Flow of Events

7.2 Basic flow 1. User inserts card in ATM.

2. Bank Database validates the card.

3. On success employee must enter pin and select from his list of services

appeared on the screen.

7.3 Alternate Flow If in the basic flow, the card or pin is invalid a receipt ejects out from ATM in response to

error.

7.4 Pre Conditions The User must possess an ATM card

7.5 Post Conditions The user must take the receipt.

P a g e | 7

8. Insert card - Use case specifications 8.1 Brief Description

The student is requested to insert (swipe) card and the card is taken in and kept inside

for the whole transaction time. Once the transaction is over card is spelled out

Flow of Events

8.2 Basic flow

1. Student inserts card in ATM or Card reader

2. ATM or Card reader validates the card.

3. On success user can precede the transaction

8.3 Alternate Flow

If the card is invalid, ATM ejects the card or then it may be taken back from Card

reader and gives a receipt indicating the error number.

8.4 Pre Conditions

The User must possess an ATM card or else a debit/credit card.

8.5 Post Conditions

None.

9. Invalid card - Use case specifications 9.1 Brief Description

The card inserted will be checked for validation. The card may not be inserted properly

or it may be out of date or it can be an invalid for specific bank. In those situations it is

requested for re-insert.

Flow of Events

9.2 Basic flow

1. Student inserts card in ATM or swipes in Card reader

2. ATM (Card reader) validates the card is invalid.

3. Student must re-insert (swipe) the card again.

9.3 Alternate Flow

Even after reinserting the card, if the card is invalid ATM (Card reader) gives a receipt

indicating that the card is invalid.

9.4 Pre Conditions

The User must possess an ATM card or a credit/debit card.

9.5 Post Conditions

None.

P a g e | 8

10. Pin validation - Use case specifications 10.1 Brief Description

After inserting the card and if it is checked for validation, the user is requested for pin.

The pin is itself present on magnetic strip on back of card and it is checked with the entered

one.

Flow of Events

10.2 Basic flow

1. Student inserts card in ATM and enter his pin number.

2. ATM validates the pin.

3. On success user can precede the transaction

10.3 Alternate Flow

If the pin is invalid, ATM ejects the card and gives a receipt indicating the error number

10.4 Pre Conditions

The User must possess an ATM card.

10.5 Post Conditions

None.

11. Invalid Pin - Use case specifications 11.1 Brief Description

The pin entered may be wrong in that case transaction is cancelled. The student is

requested for re-inserting of card and re-entry of pin. The number of wrong trials may be

limited according to bank’s specifications. Flow of Events

11.2 Basic flow

1. Student inserts card in ATM and enter his pin number.

2. ATM founds that pin is invalid.

3. The student requested to reinsert card or reenter the pin.

4. In case the number of trials exceeded, ATM blocks the card temporarily.

11.3 Alternate Flow

If student enters a correct pin transaction proceeds further.

11.4 Pre Conditions

The User must possess an ATM card.

11.5 Post Conditions

The user should not enter the pin number more than the number of trials.

P a g e | 9

Use Case Diagram:

P a g e | 10

Domain Model:

P a g e | 11

Design Model:

P a g e | 12

Sequence Diagrams:

P a g e | 13

P a g e | 14

P a g e | 15

P a g e | 16

Communication Diagrams:

P a g e | 17

P a g e | 18

P a g e | 19