Escolar Documentos
Profissional Documentos
Cultura Documentos
Customer comes in Request for hall? Yes Available ? No No Waiting list No Yes Register the customer
Generate bill
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 systems 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: <<uses>> Hall Request <<extends>> <<extends>> Registering customer Customer Hall available Checking availability
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
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: <<uses>>
Approval of registration
<<extends>> Cancellation of allotment <<extends>> 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: <<uses>>
Bill generation
Approval of registration
Clerk
customer
clerk
services | | | | | | | | | | | |
| | | | Request for hall | | | | Gives date | Checks availability | Hall vacant |or not vacant | | | Gives his details | | | Customer registered | | | | | | |
customer
clerk
services
| | | | Request for services | | | Services are shown | | | | | | | Books some services | | Request to pay | | | advance | | | | | | | Pays| advance | | | | | | | | |
customer
| | | | | Request for cancellation | | | | Gives restration no | | | | Approval of registration | | | | | | | Valid or invalid | | | | | | | Allotment cancelled | | | | | | | | | Sequence diagram: Bill generation
clerk | | | | | | | | | | | |
services | | | | | | | | | | | |
Calculates bill
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 Services S_no S_name S_type Cost/day
+Cancellation ( ) | | |
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 | | | | |
DESIGN PHASE
Business Layer
Books #Booked date: date #Start date: date #End date: date #Days: number #Adv: number Services #C_no :number #C_name :string #C_addr :string #Purpose :string +registration() +allotment()
Customer
* *
| ||
| Pays | number #Total Amt: #Balance: number #Pay date: date -Bill calculation ()
* *
allot :: + checkavailability(date)
Not vacant
Display
Allotment of services
Invlaid
Display
Update allotment
Business Classes
Books Access classes Auditorium DB #Booked date: date #Start date: date #End date: date #Days: number #Adv: number
Customer
+allotment() | | | | | | | | Pays #Totalamount:num #Balance: number #Pay date: date -Bill calculation()
View Classes
Request Access UI #Start Date: date #End Date: date #main UI: Main UI
+showReq_AccessUI( )
Booking UI #Booked date: date #Start date: date #End date: date #Advance: number
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
View Classes
Clerk Access UI #User Name: String #Password: string #main UI: Main UI
+showClerkAccessUI( )
+showMainUI( )
Booking UI #Booked date: date #Start date: date #End date: date #Advance: number
Registration
Booking
Cancellation
Payment
Display RegistrationUI
Display BookingUI
Display CancellationUI
Display PaymentUI