This case study is based on the understanding of the Object Oriented Analysis And Design and its core concepts. Here I am giving a brief introduction of the case study and some of the important aspect of the system need to design.
The BCUC Centre for the Performing Arts (BCPA), an entertainment venue, wants to allow customers to order tickets through the Internet. This new Online Ticketing System (OTS) must allow the customer to view a list of upcoming events, or view scheduled shows by date, select seat(s) from a seating chart, hold the seat(s) while they complete their selection, and purchase the selected seats.
The BCPA has contracts with several ticket agents at various ticket outlets. These contracts define the agent commissions and the terms and conditions for the sale of tickets. The contract is the agent's authorisation to use the OTS. Associated with the contract is a sales agreement that defines the seats that are assigned to the agent to sell. One agent may not sell seats from another agent's assigned seats. The seat assignments apply to a set of seats for the specified date range, not for specific shows.
The venue manager is responsible for managing promotions for each show. A promotion defines the pricing structure for seats in a show. A pricing structure must accommodate differences for adult, student, child, and senior citizen seating. Discounts are defined per show. A promotion can be unique to each showing of an event. For example, the promotion for a Saturday matinee may be different than the promotion for the Saturday evening show. A promotion can be specific to seats within a show. A promotion may also be reused for many shows for numerous events. The system must be capable of displaying the price for each seat on the seating chart Assigning seats to promotions must be dynamic; that is, seats may be redefined into different promotions if a show sells either better or worse than anticipated.
The system must allow the venue manager to cancel, reschedule, or add events and shows, and to allow changes to the maximum‑seats per‑customer value for each show.
A consumer will access the OTS via the World Wide Web. The user interface will be implemented with Java applications; that is, without browsers and hypertext mark-up language (HTML).
Consumers must provide a valid sign‑on and password. Then they must provide or verify their customer profile information. The customer profile includes address information for mailing the tickets. This information is also used to target customers for special promotions. The system must keep this customer information on file so that returning consumers can use their existing sign‑on and password, and avoid re‑entering the information.
Consumers are then presented with the choice between selecting a show using a list of upcoming events or a list of shows for a given date range. Once Consumers select a show, they are offered the choice of interactively selecting a seat(s) or having the system select the best available seat(s) for a price range.
When users select interactive seat selection, they are presented with a floor chart of the Concert Hall. The seating chart is coloured according to the status of the seats for each show; for example, available, held, or sold. Selecting a seat places it on hold so that no one else can select it while the users complete their transactions.
Deselecting a seat removes the hold and makes the seat available again for other users. Users can select up to the maximum allowed seats per customer set for the show by the venue manager.
When users select automatic seat selection, they must provide a price range and the number of seats desired. The system will then attempt to select the "best" seats available. Once the attempt is completed, the system will either display the resulting seating chart with the selected seats highlighted, or an appropriate message. Users can then either accept the selection and change the criteria, or switch to interactive seat selection.
When consumers select a seat, the system will "hold" the seat so that it will appear unavailable to subsequent customers. After the consumers pay for the seats, the system will mark the seat(s) reserved and generate a ticket(s). If consumers choose not to purchase the seat(s), then the system will remove the hold, thus making the seat(s) available again.
In a transaction, consumers can purchase a single ticket or multiple tickets at varied prices. For some shows, volume discounts are available. For example, ticket purchases of £100 or more might receive a 10 % discount, or buying 6 or more tickets might qualify the consumer for a 15 % discount. In all cases, each ticket must be tracked separately, with its associated price and applied discount and seat assignment.
Credit card will be the only form of currency accepted, so the system must have the ability to validate a card number and accept or reject the purchase. For this case study, assume that all credit card purchases are approved.
Ticket agents interact with the OTS using the World Wide Web. After signing onto the application as an agent, the agent interacts with the system on behalf of the customer. Once agents provide the customer profile information, the same initial choices of event selection by upcoming events or date range are displayed, Agents use the same features for seat selection as the consumer, with one additional feature; agents are able to see only the seats assigned to them. Agents can also see the total number of tickets sold for the currently displayed show or all shows for a date range.
Once the seats are placed in a hold state, an internal clock will sound an alarm after five minutes and prompts users about continuing the transaction. The alarm then sounds every minute for three minutes, after which time all "held" seats are released if the transaction is not completed. This same feature applies to the consumer.
Detailed Requirements:
Identify the major Actors involved with the system, along with reasoned justifications, and develop a Use Case Model for each Actor.
Consolidate the models into one, reconciling the names if required.
Identifying Classes:
Create a Class Diagram, identify Associations between the Classes;
Model Generalisations, Aggregations and Compositions if applicable;
Assign Multiplicities;
Suggest suitable important attributes and operations for the major Classes;
Produce a final, 'for this stage' Class Model
Produce Sequence Models for all users in all cases for:
'user entry to the system'
'customer successfully book two tickets for one performance of a show'
Produce a Data dictionary to support the models produced (this can be included within the report)
Submit a brief report on the analysis and design of your system models which needs to include the process used to produce the above models stating any constraints and assumptions along with any difficulties encountered accompanied by the course of action taken to overcome them.
Major Actors involved with the system:
From the case study I have identified three major Actors in BCUC Centre of performing Arts (BCPA) Online Ticketing System (OTS). These actors are mentioned below along with reasonable justification.
Customer
Ticket Agent
Venue Manager
Justification:
Customer:
The first actor customer is the core user of the system. A customer will interact with the system via World Wide Web (WWW). The customer will interact with the BCPA OTS in following ways.
Customer registration
Provide profile information
Customer provides the valid username and password to sign on the system.
View upcoming the list of events
Views schedules
Select a show using a list to upcoming events Or
List of show from a given date range
Select seat from seating chart
Purchased the seat
Purchased a single or multiple tickets
Pay for the ticket using credit cards
Ticket Agent:
Ticketing Agent is the second major actor interacts with the system. BCPA has contracts with several ticket agents at various ticket outlets. A ticket agent interacts with the system on behalf of the customer to purchase/reserve a show ticket.
Ticket agent uses the system in the following ways.
Sign on the system
Agents provide the customer profile information provided by same choices select by event/show or select by date range.
Agents are able to see the seats assign to them.
Agent is also able to see the total number of seats sold for the show or for a specific date range.
Venue Manager:
Venue manager is a user of the system as an administrator to.
Manage promotion for each show (this define pricing structure of each show e.g. Adult, Students, Child, Senior citizen).
Venue manager can cancel Events.
Venue manager can reschedule events.
Venue manager can add events.
Venue manager can make changes to the maximum seat per customer.
Use Case Diagram for customer:
Following use Case represent overall all view of our system. In this diagram we just show the basic functionality of our system with out any detail.
This diagram show customer registration, customer logon the system, customer select the show and seat for the available seating chart and pay for the seat.
Use Case Diagram:
Use Case Diagram for ticket agent:
Follow is the user case diagram for the ticket agent at various ticketing outlets. A ticket agent performs the same course of action as customer along with some more privileges. Here is the normal Use Case Diagram for the ticket agent.
Use Case Diagram
Use Case Diagram for Venue Manager:
The third actor named as a Venue manager act as an administrator for the system. A Venue Manager is responsible for adding events, deleting events, defining promotions, rescheduling events etc. and other administrative duties. Here is the simple use case diagram of the venue manger.
Use Case Diagram
Class Diagram:
Here is the class diagram for the BCUC Centre of performing Arts (BCPA) Online Ticketing System (OTS). I have identified all the possible classes that make up the system. In the following diagram I have completed the following tasks.
Identify the association between classes.
Generalization, Aggregation and composition.
I assigned the multiplicities.
I also suggested some suitable attributes and operations.
So by having all the above tasks in my class diagram it is final and complete class diagram for BCUC Centre of performing Arts (BCPA) Online Ticketing System (OTS).
Some of the major classes are given bellow….
User
Customer
Agent
Venue manager
Ticket
Contract
Promotion
Show
Seat
Seating Chart
Pricing Structure
On the following page I build up the class diagram for the BCUC Centre of performing Arts (BCPA) Online Ticketing System (OTS).
Class Diagram for the BCUC Centre of performing Arts Online Ticketing System:
SEQUANCE DIAGRAME FOR CUSTOMER
SEQUANCE DIAGRAME FOR VENUUE MANAGER:
