CASE- STUDY
CASE STUDY: BANK ATM SYSTEM
Problem statement
Each bank provides its own computer to maintain its own accounts and process transactions against them. With this system, a client must first open account before he can use ATM. The opening account involves the client providing his Personal information, and SSI. A client may open one or more accounts for deposit ,withdraw, transfer money between checking and saving account. The client can check the account status 24 hours a day.
When the client deposit/withdraw money. The client must specify which account and the amount. Then ATMs communicate with a central computer which clears transactions with the appropriate banks. An ATM accepts a cash card, interacts with the user, communicates with the central system to carry out the transaction, dispenses cash, and prints receipts. The system requires appropriate recordkeeping and security provisions. The system must handle
concurrent accesses to the same account correctly. The banks will provide their own software for their own computers.
Functional Requirements
The functional requirements are organized in two sections; First requirements of the ATM and second requirements of the bank computer.
* Requirements of the ATM - authorization process
- transaction (withdrawal process)
* Requirements of the bank computer
- authorization process (bank code and password) - transaction
Non-functional Requirement
The non-functional requirement is bellowed.
* The ATM network has to be available 24 hours a day.
Usecase Diagram For Bank ATM System
Customer
System startup
System shutdown Operator
Withdrawl Deposit Transfer Enquiry
Session
Invalid Pin
Transaction Bank
<<include>>
<<extend>>
Class Diagram For Bank ATM System
customers
: User : User
Atm InterfaceAtm
Interface DatabaseDatabase
Insert Card Enter Pin
Validate Pin Validate Ok Show Options
Choose Option Select Withdrawl
Enter Amount
Check Balance Validate Ok Receive Cash
Remaining balance Balance Slip
: U se r
A tm In te rfa ce
D a ta b ase 1 : In se rt C a rd
2 : E n te r P in 3 : V alid a te P in
4 : V a lid ate O k 5 : S h o w O p tio n s
6 : C h o o se O p tio n
7 : S e lec t W ith d raw l 8 : E n ter A m o u n t
9 : C h e ck B a la n c e 1 0 : V a lid a te O k
1 1 : R ec e iv e C a sh
1 2 : R em a in in g b a la n ce 1 3 : B a lan ce S lip
Activity Diagram For Bank ATM System
enter pin
perform transaction
collect card select transaction
insert card
invalid
valid
no more transactions more trasactions
A tm d a ta b a se
h e a d e r file s
A tm e xe c u ta b le file s
a tm _ file s
w ith d r a w a l b a la n c e m in i sta te m e n t a tm _ m a in
c h a n ge p in
Deployment Diagram For Bank ATM System
Bank
Client Desktop providing services at desks
Each bank employee given a desktop and provided with id,pwd to login into database
Webpage providing services of online transaction Card Reader providing
services of credit,debit transaction providing services of ATM transaction
Bank Database keeping the details of each and every account
smooth operation of the network, for example in handling call handovers from one cell to another. These frequencies are assigned according to a frequency plan, which is updated from time to time, in response to evolving network requirements. The migration from one frequency plan to a new one proceeds in stages, governed by the network’s base station controllers. Existing methods result in periods of reduced network availability or performance during the reassignment process. The Study Group was asked to develop an algorithm for implementing a new frequency plan that maintains service quality during the transition.
A cellular network usage application is to be developed to assist cellular companies in capacity planning. This application will report on cell tower site usage in two ways: 1) immediate notification if a cell tower site's call capacity is being exceeded, and 2) a formatted report on demand, showing calls in progress for a given cell tower site, or for all cell tower sites. This application is not meant to be a simulation or real-time monitoring system of a cellular network, but more of a simple "play back" application, for usage projections.
The application monitors cell tower site usage by tracking cell phones as they move around, are turned on and off, originate or receive calls and run out of battery power. Note that calls are tracked in two directions - both originating from the cell phone and received by the cell phone. Calls may be made to or received from a cell phone being tracked in the application, or from an outside number. Assume that the cell phone data comes from previous field monitoring and testing procedures (although randomly generated data or keyed input are other possible data capture sources).
Functional Requirements:
Cellular Network: A cellular network is a network distributed over land areas called cells, each served by at least one fixed-location known as a or . When joined together these cells provide radio coverage over a wide geographic area.
Place Phone call:User places a phone call to the receiver and the cellular network identifies this phone call.
Receive phone call: User recieves a phone call from the sender and the cellular network identifies this phone call.
Place Conference Call: User places a Conference call if he need and the cellular network identifies it.
Receive additional Call: when reciever is on call and gets an additional call then he holds the present call and receive the additional call.
Non Functional Requirements:
a) System should be designed simple enough to enable User to operate the phone without any formal training or delay.
b)System must handle Network and power failure.
c)System must be efficient to use and provide quick recover from the fault.
d) Software must validate and cancel operation in case of incorrect member details,incomplete transaction, and time delay and return failure.
e)User interface screen must be designed to operate easily. It should have visual appealing.
P la c e c o n fe re n c e c a ll
U s e s c h e d u le r P la c e P h o n e c a ll
< < e xte n d > >
C e llu la r n e tw o rk
U s e r
R e c e iv e p h o n e c a ll R e c e iv e a d d itio n a l c a ll
< < e xte n d > >
Class Diagram For Cellular Phone Network
Dialler Digit() Send()
Dialler Display DisplayDigit()
Display Speaker
Emit tone()
Button
CRDisplay Cellular Radio
Connect()
:D i a le r :D i a le r S e n d :B u tto n
S e n d :B u tto n :S e n d B u tto n A a d a p te r :S e n d B u tto n
A a d a p te r :C e llu la r
R a d io :C e llu la r
R a d io D is p a y C R D i s p la y
D is p a y C R D i s p la y
1 : B u tto n p r e s s e d ( )
2 : S e n d ( )
3 : C o n n e c ti o n ( p n o )
4 : In u s e ( )
Collaboration Diagram For Cellular Phone Network
S e n d :B u t to n : S e n d B u tt o n A a d a p te r
: D ia le r
: C e llu la r
R a d io D is p a y C R
D is p la y 1 : B u tt o n p re s s e d ()
2 : S e n d ()
3 : C o n n e c tio n (p n o )
4 : In u s e ()
Indicate no balance
Process the dial
Give busy indication
Busy Ringingtone
No response till t sec
Increment the usage time Add Update the balance
Response
Cut the service
Balance out
Have balance Balance Out
Before 1 min
After Completion
State Chart Diagram For Cellular Phone Network
idle
Ready to dial
Off-hook
Connecting Destination
A lerted Ringing
Talk
Bus y Busy
Dial
On-hook On-hook
Tim e-out
U s e r
C e llu la r E x e c u ta b le N e tw o rk D a ta b a s e
C e llu la r N e tw o rk M a i n
N e tw o rk
M a k e C a ll R e c e ive C a llU s e S c he d ule rR e c e ive p h o n e C a llP la c e P h o n e C a ll
Deployment Diagram For Cellular Phone Network
Cell
Phone Window Mobile
Phone
Central Server Control
console{0...*}
GPS Controller
T ablet PC{0...*}
Fixed Installation
GPS Locator {0...*}
CASE STUDY: STUDENT COURSE REGISTRATION SYSTEM
At the beginning of each semester students may request a course catalogue containing a list of course offerings for the semester. Information about each course, such as professor, department, and prerequisites will be included to help students make informed decisions.
The new on-line registration system will allow students to select four course offerings for the coming semester. In addition, each student will indicate two alternative choices in case a course offering becomes filled or canceled. No course offering will have more than ten students. No course offering will have fewer than three students. A course offering with fewer than three students will be canceled. Once the registration process is completed for a student, the registration system sends information to the billing system, so the student can be billed for the semester.
Professors must be able to access the on-line system to indicate which courses they will be teaching. They will also need to see which students signed up for their course offering.
For each semester, there is a period of time that students can change their schedules. Students must be able to access the on-line system during this time to add or drop courses. The billing system will credit all students for courses dropped during this period of time.
Functional Requirements:
Maintain curriculum: This use case is started by the registrar. It provides the capability to create, review, modify, and delete a list of course offerings for a given semester.
Maintain Student Information: This use case is started by the registrar. It provides the capability to create, review, modify, and delete student information.
Maintain Staff Information: This use case is started by the registrar. It provides the capability to create, review, modify, and delete staff information.
Register for programmer: The use case is started by the student. It provides the capability to create, review, modify, and delete a course schedule for a specified semester.
Write exam: This usecase is started by the student. It provides the capability to write exam.
Pay Fee: This usecase is started by the student. It provides the capability to pay fee.
NonFunctional Requirements:
• System should be designed simple enough to enable staff to operate enqiry screen without any formal training or delay.
• System must be secured and protected from the staff and other unauthorized users.A student is allowed only to view and restricted to access/insert/update the other part of the system.
• Student is not necessary to maintain the staff information,student information and curriculum.
• Registrar is not necessary to pay fee and write exam.
UseCase Diagram for Student Course Registration System
maintain staff inforamation maintain currirculum
maintain student information registrar
student
register for a programmer
write examination
pay fee
Class diagram For Student Course Registration System
student
sttudent name : char[20]
studentid : int
student
student applicationapplication inteviewinteview admissionadmission
1: send
2: attend
3: [pass]admit
Collaboration diagram For Student Course Registration System
student application
inteview admission
1: send
2: attend
3: [pass]admit
canceled
do/ notify registerd students
intialization
do/ intialize batch
open
entry/ register student exit/ increment student
close
do/ finalize batch
cancel
cancel
cancel add student/ set c=0
addstudent[c<n]
[c=n]
start
end
Component diagram For Student Course Registration System
re g is tra tio n e xe c uta b le
d a ta b a s e
re g is tra tio n m a in
s tud e nt
a p p lic a tio n inte rvie w a d m is s io n c o urs e s