ACTIVITY DIAGRAM FOR AUDITORIUM MANAGEMENT
Request for hall?
Yes
Available ?
Yes Register the customer No Waiting list Generate bill Customer comes in Cancellation? Yes Approval of registration? Cancel the allotment No Done? Yes No Service are needed ? Yes Allotment of services No
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 Registering customer Checking availability Hall available Customer <<uses>> <<extends>> <<extends>>
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 Services provided by hall <<uses>> <<extends>> Customer
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 Registered customer Cancellation of allotment <<uses>> <<extends>> Re allotment to waiting list <<extends>> 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: Approval of registration Bill generation Calculating amount <<extends>> Allotted services Clerk <<uses>> <<uses>> Customer present <<extends>>
Sequence diagram: Registering the customer
Sequence diagram: Allotment of services
customer clerk services | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Request for hall
Gives date
Checks availability Hall vacant or not vacant
Customer registered Gives his details
customer | | | | | | | | | | | | clerk | | | | | | | | | | | | services | | | | | | | | | | | | Request for services
Services are shown
Books some services Request to pay
advance
Sequence diagram: Cancellation of allotment
Sequence diagram: Bill generation customer | | | | | | | | | | | | clerk | | | | | | | | | | | | services | | | | | | | | | | | | Request for cancellation
Approval of registration Valid or invalid Gives restration no Allotment cancelled customer | | | | | | | | | | | | clerk | | | | | | | | | | | | services | | | | | | | | | | | | Gives restration no Calculates bill Ask for payment
UML STATIC CLASS DIAGRAM Customer +Registration ( ) Services | | | | | | | | C_no C_name C_addr Purpose Pays Total service cost
Balance Amount to pay Pay date +Payment ( ) Cancellation Reg_no Service Type +Cancellation ( ) | | | Books Book Date Start Date End Date Service type +Booking ( ) S_no S_name S_type Cost/day * *
customer clerk services | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Request for hall
Hall vacant or not vacant Customer registered
Checks availability
Request services
Allotment of services
Calculates bill Ask for payment
USE CASE FOR AUDITORIUM MANAGEMENT customer Clerk Registration & allotment Payment
3.1 REFINED CLASS DIAGRAM
Customer Services | | | | | #C_no :number #C_name :string #C_addr :string #Purpose :string +registration() Pays#Total Amt: number #Balance: number #Pay date: date
-Bill calculation () Cancellation #Reg_no: number #Ser_booked: string +cancellation () | | Books #Booked date: date #Start date: date #End date: date #Days: number #Adv: number +allotment() #S_no: number #S_name: string #S_type: string #Cost/day: number
*
*
Business Layer
*
*
ACTIVITY DIAGRAM FOR CUSTOMER FOR ALLOTMENT
request = retrieve status (date) #checkavailability (date): customer: allot allot :: + checkavailability(date)
Not vacant
Display
Register the customer Vacant
Customer = retrieve status (date) #checkregistration (date): customer: cancellation Cancellation :: + approve registration(rno,date)
Invlaid
Display
Cancel the allotment Valid
Update allotment
ACTIVITY DIAGRAM FOR BILL GENERATION
Total service cost = sum (booked services) Payment class: advance
Balance = total service cost - advance
Access classes Auditorium DB +retrieve customer ( ) +update customer ( ) +retrieve service ( ) +update service ( ) Customer #C_no ::number #C_name: string #C_addr :string #Purpose :string +registration() Books #Booked date: date #Start date: date #End date: date #Days: number #Adv: number +allotment() services #S_no :number #S_name: string #S_type: string #Cost/day : number | | | Pays #Totalamount:num #Balance: number #Pay date: date
-Bill calculation() Cancellation #Reg_no: number #Ser_booked: string +cancellation() | | | | | | | | | Business Classes
3.2
ACCESS LAYER3.3
VIEW LAYERRequest Access UI #Start Date: date #End Date: date #main UI: Main UI
+showReq_AccessUI( ) Main UI #Register UI #Booking UI #Cancellation UI #Payment UI +showMainUI( ) Booking UI #Booked date: date #Start date: date #End date: date #Advance: number
Payment #Pay date: date #Totalamt: number #Balance: number Cancellation #reg_no: number #service type: String Register UI #reg_no: number #CustName: String #CustAddr: String #Purpose: String View Classes
CONTENTES PAGE NO
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
Clerk Access UI #User Name: String #Password: string #main UI: Main UI
+showClerkAccessUI( )
Main UI #Reg_no: number #Start Date: date #End Date: date
+showMainUI( )
Booking UI #Booked date: date #Start date: date #End date: date #Advance: number
Payment #Pay date: date #Totalamt: number #Balance: number Cancellation #reg_no: number #service type: String Register UI #reg_no: number #CustName: String #CustAddr: String #Purpose: String View Classes
The CLERK ACCESS UI interface
The RegistrationTransactionUI Interface
Activity diagram for the Main UI
Request
Booking Cancellation Payment Registration Display BookingUI Display CancellationUI Display PaymentUI Display RegistrationUI
Login button pressed
