125871804-Train-Ticket

ACTIVITY DIAGRAM FOR AUDITORIUM MANAGEMENT Customer comes in Request for hall?

Yes

Yes

Available ?

Register the customer

No No

Waiting list

No

Service are Yes needed ? Allotment of services

Generate bill

Yes Cancellation?



Cancel the allotment

Approval of registration?

No Done?

Yes

USE CASE :A usecase corresponds to sequence of transactions in which each transaction is invoked from outside the system (actors) and engages internal objects to interact with one another and with the system’s surroundings. Different usecases each of which represents a specific flow of events in the system. The description of the usecase defines what happens in the system when the usecase is performed. The usecases enclosed by a system boundary, communication, association between the actors and usecases and generalization among the usecase.

EXTENDS RELATIONSHIP :This relationship is used when you have one usecase that is similar to another usecase but does a bit more in essence it is like a subclass.

USE RELATIONSHIP :Uses relationship between usecases is shown by a generalization arrow from the usecase.

Usecase Name: Registering the customer Process: 1. The client will request hall on the day which he wants the auditorium. 2. The date requested by the client is given to the availability process it in turn checks whether the hall is vacant or not. 3. If the hall is vacant then client is registered. 4. Some advance is collected from the client.

Usecase diagram: Hall Request

Checking availability

Registering customer Customer

Hall available

Usecase Name: Allotment of services Process: 1. After checking the availability, if the hall is vacant then he request for services. 2. He books the services he want from the services provided by the hall. 3. The services booked by the customer are stored in the booking process. Usecase Diagram:

Request services



Allotment of services Customer

Services provided by hall

Usecase Name: Cancellation Process Process: 1. If the customer wants to cancel his allotment, first his registration must be a valid one. 2. Approval of registration. 3. If he is registered customer then by using his registration no his allotment is cancelled. 4. After the cancellation is done if any body in the waiting list wants the hall on that date then re allotment of hall process will be done. Usecase diagram:

Request for cancellation



Approval of registration

Cancellation of allotment Customer

Re allotment to waiting list

Registered customer

Usecase Name: Bill generation Process: 1. After the hall is used the customer has to pay the bill for that the clerk has to calculate the bill. 2. By using the registration no given to the customer the services he had booked are retrieved. 3. For the services the customer had booked rent is calculated and the advance is deducted. 4. Bill is given to the customer. Usecase diagram:

Bill generation



Approval of registration

Calculating amount

Clerk

Allotted services

Customer present

Sequence diagram: Registering the customer

customer

clerk

services

| | | | Request for hall | | | | Gives date | Checks availability | Hall vacant |or not vacant | | | Gives his details | | | Customer registered | | | | | | |

| | | | | | | | | | | |

Sequence diagram: Allotment of services

customer

clerk

services

| | | | Request for services | | | Services are shown | | | | | | | Books some services | | Request to pay | | | advance | | | | | | | Pays| advance | | | | | | | | |

Sequence diagram: Cancellation of allotment

customer

clerk

services

| | | | | Request for cancellation | | | | Gives restration no | | | | Approval of registration | | | | | | | Valid or invalid | | | | | | | Allotment cancelled | | | | | | | | | Sequence diagram: Bill generation

customer | | Gives restration no | | Ask for payment | | | | | | | |

clerk | | | | | | | | | | | |

services

Calculates bill

Pays the bill

| | | | | | | | | | | |

UML STATIC CLASS DIAGRAM

Books Book Date Start Date End Date Service type Customer C_no C_name C_addr Purpose +Registration ( )

*

+Booking ( ) | | | | | | | | Pays Total service cost Balance Amount to pay Pay date +Payment ( ) Cancellation Reg_no Service Type

+Cancellation ( ) | | |

Services

*

S_no S_name S_type Cost/day

customer | | | | | | | | | | | | | | | | | | |

clerk

services

| | Request for hall | Checks availability | Hall vacant or |not vacant | Customer registered | | Request services | Allotment |of services | | Calculates bill | Ask for payment | | Pays the bill | | | | |

| | | | | | | | | | | | | | | | | | |

USE CASE FOR AUDITORIUM MANAGEMENT

Registration & allotment

Payment customer

Clerk

DESIGN PHASE

3.1 REFINED CLASS DIAGRAM

Business Layer Books #Booked date: date #Start date: date #End date: date #Days: number #Adv: number

Customer

Services #C_no :number #C_name :string #C_addr :string #Purpose :string +registration()

+allotment()

* *

| || | Pays | number #Total Amt: #Balance: number #Pay date: date -Bill calculation ()

Cancellation #Reg_no: number #Ser_booked: string +cancellation () | |

* *

#S_no: number #S_name: string #S_type: string #Cost/day: number

ACTIVITY DIAGRAM FOR CUSTOMER FOR ALLOTMENT

allot :: + checkavailability(date)

request = retrieve status (date)

Not vacant

Vacant Register the customer

Allotment of services

#checkavailability (date): customer: allot

Display

ACTIVITY DIAGRAM FOR CANCELLATION OF ALLOTMENT

Cancellation :: + approve registration(rno,date)

Customer = retrieve status (date)

Invlaid

Valid Cancel the allotment

Update allotment

#checkregistration (date): customer: cancellation

Display

ACTIVITY DIAGRAM FOR BILL GENERATION Payment class: advance

Total service cost = sum (booked services)

Balance = total service cost - advance

Insert into payment

3.2 ACCESS LAYER

Business Classes

Books Access classes

#Booked date: date #Start date: date #End date: date #Days: number #Adv: number

Auditorium DB

Customer

+retrieve customer ( ) +update customer ( ) +retrieve service ( ) +update service ( )

#C_no ::number #C_name: string #C_addr :string #Purpose :string +registration()

+allotment() | | | | | | | | Pays #Totalamount:num #Balance: number #Pay date: date -Bill calculation()

Cancellation #Reg_no: number #Ser_booked: string +cancellation() | | | |

services #S_no :number #S_name: string #S_type: string #Cost/day : number

3.3 VIEW LAYER

View Classes

Request Access UI #Start Date: date #End Date: date #main UI: Main UI

Main UI #Register UI #Booking UI #Cancellation UI #Payment UI

+showReq_AccessUI( )

Register UI #reg_no: number #CustName: String #CustAddr: String #Purpose: String

Booking UI #Booked date: date #Start date: date #End date: date #Advance: number

+showMainUI( )

Payment #Pay date: date #Totalamt: number #Balance: number

Cancellation #reg_no: number #service type: String

CONTENTES

1. INTODUCTION Description of project Goal and objectives Environment specification Hardware specification Software specification Three tier architecture 2. STUDY PHASE Data collection Description of present and proposed system Identifying Users and Actors UML Activity Diagram UML Usecase Diagrams Extended Usecase diagrams Interaction diagram Sequence diagram Identifying Classes and their attributes UML Static class diagram 3. DESIGN PHASE Complete UML class diagram (BUSINESS LAYER) Access Layer View Layer

PAGE NO

View Classes

Clerk Access UI

Main UI

#User Name: String #Password: string #main UI: Main UI

#Reg_no: number #Start Date: date #End Date: date

+showClerkAccessUI( )

Register UI #reg_no: number #CustName: String #CustAddr: String #Purpose: String

Booking UI #Booked date: date #Start date: date #End date: date #Advance: number

+showMainUI( )

Payment #Pay date: date #Totalamt: number #Balance: number

Cancellation #reg_no: number #service type: String

The CLERK ACCESS UI interface

The MAIN UI Interface

The RegistrationTransactionUI Interface

The Booking&CancellationTransactionUI Interface

The BillTransactionUI Interface

Activity diagram for the Main UI Login button pressed Request Hall is available

Registration

Booking

Cancellation

Display RegistrationUI

Display BookingUI

Display CancellationUI

Payment

Display PaymentUI

REPORTS YEAR WISE COLLECTION REPORT:

SERVCIE UTILIZATION REPORT

RETRIVALS CUSTOMER BOOKING INFORMATION