A Ticket Booking System For Theatre

4878 words (20 pages) Essay

12th May 2017 Information Technology Reference this

Disclaimer: This work has been submitted by a university student. This is not an example of the work produced by our Essay Writing Service. You can view samples of our professional work here.

Any opinions, findings, conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of UKEssays.com.

The purpose of the online ticket booking system is to provide another way for purchasing cinema tickets in advance. It is an automatic system. This paper presents a formal use of the Object Oriented analysis and Design, we will illustrate our system by providing Use Case Diagrams with Specifications, Activity Diagrams, Class Diagrams, Sequence Diagrams, State Machines and Communication Diagrams on the functionalities of the system, also we will provide some process description and data dictionary.

The goals of our system are:

Record performance details

Record customer details

Record tickets sold

Print tickets

Print address labels for telephone booking

Task 1: Functional Modelling

Identification of Actors & Use Cases

Analyzing the existing system we figured out that, there are two main scopes to be covered in the system. The scopes are Performance Planning and Ticket Booking. We used the below table to identify the Actors and the Use Cases for the system.

User

Role

Use Case

Theatre Manager

Performance planning

Define the type of the performance and name it.

Performance scheduling

Define date and time of the performance.

Artist booking

Book an artist for the performance.

Ticket pricing

Determine a price for the ticket.

Clerk

Check schedule

Check the performance schedule for a particular show on a date.

Check seat availability

Checks for available seats

Capture customer information

Record customer details

Check ticket price

Check for ticket price for particular show.

Sell ticket

Record tickets sold.

Print ticket

Print ticket for the customer.

Print address label

Print address label for telephone booking.

Use Case Diagram

Following diagram shows the overall view of the Ticket Booking System for Theatre.

Figure 1: Use Case Diagram (Performance Planning & Ticket Booking)

Use Case Specification

Table 1: Use Case of Performance Planning

Number:

UC01

Req. Doc Ref:

Name:

Performance Planning

Status:

Actors:

Theatre Manager

Pre-requisites:

User should be logged in the system.

Goal:

Defining the performance type and naming it.

Use Case Relationships:

Extend:UC02, UC03

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User enters the name of the performance.

2

User enters the type of the performance.

3

System checks for all required data entry.

4

System connects to the database.

5

System writes data into the database.

6

System shows a confirmation message after successful database writes.

Alternatives:

Index

Actor Event

A 3.1

Enter required information.

A 4.1

Check network connectivity

A 4.2

Check database connectivity

A 4.3

Check database user role

A 5.1

Theatre manager gets notification of unsuccessful operation.

Table 2: Use Case of Performance Scheduling

Number:

UC02

Req. Doc Ref:

Name:

Performance Scheduling

Status:

Actors:

Theatre Manager

Pre-requisites:

User should be logged in the system.

Performance planning (UC01) should be inserted into the system.

Goal:

Define date and time of the performance.

Use Case Relationships:

Extend:

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User selects the desired performance from the system.

2

User enters the date of the performance.

3

User enters the time of the performance.

4

System checks for all required data entry.

5

System connects to the database.

6

System writes data into the database.

7

System shows a confirmation message after successful database writes.

Alternatives:

Index

Actor Event

A 3.1

Enter required information.

A 5.1

Check network connectivity

A 5.2

Check database connectivity

A 5.3

Check database user role

A 6.1

Theatre manager gets notification of unsuccessful operation.

Table 3: Use Case of Artist Booking

Number:

UC03

Req. Doc Ref:

Name:

Artist Booking

Status:

Actors:

Theatre Manager

Pre-requisites:

User should be logged in the system.

Performance planning (UC01) should be inserted into the system.

Goal:

Book an artist for the performance.

Use Case Relationships:

Extend:

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User selects the desired performance from the system.

2

User enters the name of the desired artist.

3

System checks for all required data entry.

4

System connects to the database.

5

System writes data into the database.

6

System shows a confirmation message after successful database writes.

Alternatives:

Index

Actor Event

A 3.1

Enter required information.

A 4.1

Check network connectivity

A 4.2

Check database connectivity

A 4.3

Check database user role

A 5.1

Theatre manager gets notification of unsuccessful operation.

Table 5: Use Case of Schedule Checking

Number:

UC04

Req. Doc Ref:

Name:

Schedule Checking

Status:

Actors:

Clerk

Pre-requisites:

User should be logged in the system.

Performance scheduling (UC02) should be inserted into the system.

Goal:

Check the performance schedule for a particular show on a date.

Use Case Relationships:

Extend: UC01

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User selects a desired performance and a date.

2

System shows a confirmation message for the availability of the performance.

3

System allows the user to perform the next event (UC06).

Alternatives:

Index

Actor Event

A 1.1

System notifies the user that the performance is unavailable on the desired date.

Table 6: Use Case of Check Seat Availability

Number:

UC05

Req. Doc Ref:

Name:

Check Seat Availability

Status:

Actors:

Clerk

Pre-requisites:

User should be logged in the system.

Schedule checking (UC05) should be performed by the user.

Goal:

Checks for available seats.

Use Case Relationships:

Extend:

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User selects a desired performance and a date.

2

System shows a confirmation message for the availability of the seat.

3

System allows the user to perform the next event (UC07).

Alternatives:

Index

Actor Event

A 1.1

System notifies the user that the seat is unavailable for the desired performance.

Table 7: Use Case of Capturing Customer Information

Number:

UC06

Req. Doc Ref:

Name:

Capture Customer Information

Status:

Actors:

Clerk

Pre-requisites:

User should be logged in the system.

Seat checking (UC06) should be performed by the user.

Goal:

Record customer details.

Use Case Relationships:

Extend:

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User enters the name, address and telephone number of the customer.

2

System checks for all required data entry.

3

System connects to the database.

4

System writes data into the database.

5

System shows a confirmation message after successful database writes.

Alternatives:

Index

Actor Event

A 2.1

Enter required information.

A 3.1

Check network connectivity

A 3.2

Check database connectivity

A 3.3

Check database user role

A 4.1

User gets notification of unsuccessful operation.

Table 8: Use Case of Checking Ticket Price

Number:

UC07

Req. Doc Ref:

Name:

Check Ticket Price

Status:

Actors:

Clerk

Pre-requisites:

User should be logged in the system.

Ticket pricing information (UC04) should be entered into the system.

Goal:

Check for ticket price for particular show

Use Case Relationships:

Extend: UC01

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User selects a desired performance form the system.

2

System shows the defined pricing for the ticket.

Alternatives:

Index

Actor Event

A 2.1

Price not found is notified to the user.

Table 9: Use Case of Selling Ticket

Number:

UC08

Req. Doc Ref:

Name:

Selling Ticket

Status:

Actors:

Clerk

Pre-requisites:

User should be logged in the system.

Check ticket price (UC08) should be performed by the user.

Goal:

Record tickets sold.

Use Case Relationships:

Extend:

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User selects the desired performance from the system.

2

User enters ticket selling date and the ticket price for the desired performance.

3

System checks for all required data entry.

4

System connects to the database.

5

System writes data into the database.

6

System shows a confirmation message after successful database writes.

Alternatives:

Index

Actor Event

A 3.1

Enter required information.

A 4.1

Check network connectivity

A 4.2

Check database connectivity

A 4.3

Check database user role

A 5.1

Theatre manager gets notification of unsuccessful operation.

Table 10: Use Case of Printing Ticket

Number:

UC09

Req. Doc Ref:

Name:

Printing Ticket

Status:

Actors:

Clerk

Pre-requisites:

User should be logged in the system.

Check ticket price (UC08) should be performed by the user.

Goal:

Print ticket for the customer

Use Case Relationships:

Extend:

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User triggers the print command for the sold ticket.

Alternatives:

Index

Actor Event

A 1.1

Printer not found notification will be given to the user.

Table 11: Use Case of Checking Ticket Booking Type

Number:

UC10

Req. Doc Ref:

Name:

Check Ticket Booking Type

Status:

Actors:

Clerk

Pre-requisites:

User should be logged in the system.

Print ticket (UC10) should be performed by the user.

Goal:

Determine the ticket booking type.

Use Case Relationships:

Extend:

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User selects the booking type to identify whether the ticket was booked over phone.

Alternatives:

Index

Actor Event

Table 12: Use Case of Printing Address Label

Number:

UC11

Req. Doc Ref:

Name:

Print Address Label

Status:

Actors:

Clerk

Pre-requisites:

User should be logged in the system.

Ticket booking type (UC11) should be performed by the user.

Goal:

Print address label for telephone booking

Use Case Relationships:

Extend: UC11

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User triggers the print command to print the address label.

Alternatives:

Index

Actor Event

Activity Diagram

Based on the system observation, a high level activity diagram is drawn modelling the process of ticket booking for theatre. The activity diagram will bring everybody on a common ground for understanding the system functionalities.

Figure 2: Activity Diagram (Performance Planning & Ticket Booking)

Task 2: Structural Modelling

Class Diagram (attributes & operations)

The following diagram depicts the relationships between the classes for Ticket Booking System along with the attributes and the operations.

Figure 3: Class Diagram (Performance Planning & Ticket Booking)

Task 3: Behavioural Modelling

Sequence Diagram

The following diagram is a sequence diagram for buying ticket. There are few things I want to state, that this is just one of the sequences of buying ticket. There could be more alternative sequence for buying ticket. For example, we can choice a performance before buying ticket. But the overall structures of all buying ticket sequence are similar, so, others sequence will not be shown.

Figure 4: Sequence Diagram (Performance Planning & Ticket Booking)

State Machine Diagram

Below diagram is used to give an abstract description of the behaviour of the ticket booking system. This behaviour is analyzed and represented in series of events that could occur in one or more possible states. Hereby “each diagram usually represents objects of a single class and tracks the different states of its objects through the system.

Figure 5: State Machine Diagram (Performance Planning & Ticket Booking)

Communication Diagram

Communication diagram is similar to sequence diagrams, but it provides an overview of the relationships between objects, rather than focusing on the order of messages between objects, as the software executes.

Figure 6: Communication Diagram (Performance Planning & Ticket Booking)

Task 4: Data Protection Law

Introduction

In Bangladesh Cyber Acts are in a process to be implemented. The Government of Bangladesh has formed National Council for Science and Technology (NCST). The Executive Committee for NCST has also been formed to implement policies formulated by the Council. Currently NCST is working with the general boundaries to protect the ICT industry and specific laws are yet to be decided. For our application we can follow the acts and regulations from UK.

Laws, Regulations and Best Practices

The Data Protection Act gives individuals the right to know what information is held about them. It provides a framework to ensure that personal information is handled properly. The Act works in two ways. Firstly, it states that anyone who processes personal information must comply with eight principles, which make sure that personal information is:

Fairly and lawfully processed

Processed for limited purposes

Adequate, relevant and not excessive

Accurate and up to date

Not kept for longer than is necessary

Processed in line with your rights

Secure

Not transferred to other countries without adequate protection

The second area covered by the Act provides individuals with important rights, including the right to find out what personal information is held on computer and most paper records.

Data protection laws should be adequate enough to maintain the below options at a minimum-

How to access information

This allows one to find out what information is held about him/her on a computer and within some manual records, such as medical records, files held by public bodies and financial information held by credit reference agencies.

Find out how UKEssays.com can help you!

Our academic experts are ready and waiting to assist with any writing project you may have. From simple essay plans, through to full dissertations, you can guarantee we have a service perfectly matched to your needs.

View our services

Correcting information

This allows one to apply to a court to order a data controller to correct, block, remove or destroy personal details if they are inaccurate or contain expressions of opinion based on inaccurate information.

Preventing processing of information

This means one can ask a data controller not to process information about him/her that causes substantial unwarranted damage or distress. The data controller is not always bound to act on the request.

Preventing unsolicited marketing

This means a data controller is required not to process information about one for direct marketing purposes if he/she asks them not to.

Preventing automated decision making

This means one can object to decisions made only by automatic means. For example, where there is no human involvement.

Claiming compensation

This allows one to claim compensation through the courts from a data controller for damage, and in some cases distress, caused by any breach of the act.

Exempt information

This allows one to ask the information commissioner to investigate and assess whether the data controller has breached the act.

There should be a committee (in our case NCTS could be the choice) that will have legal powers to ensure that organizations comply with the requirements of the data protection laws. It is notable here that these powers are focused on ensuring that organizations meet the obligations of the act.

To promote best practices the regulation-

The committee should carry out consensual audits with data controllers to assess their processing of personal information.

The committee should see auditing as a constructive process with real benefits for data controllers.

The committee should adopt, wherever possible, a participative approach including working closely with the data controller to agree the timing and scope of the audit.

Comply with Data Protection Law

A short checklist can help us to comply with the data protection laws in our system. Maintaining all the items in the checklist does guarantee compliance but it should mean that we are heading in the right direction.

We should store only the related information about the customer and the personnel’s involved with the system. And we need to make sure that we know what we are going to do with the information.

The person should know, what are the information we are holding. He/she should understand what it will be used for.

Information should be held securely whether it’s on the paper or on computer.

The system should prevent any unwanted access of its resources.

The information should be deleted as soon as there is no need for it.

Access control list should be created with a strict need to know to prevent data access from all kind of users of the system.

We should train the stuff in their duties and responsibilities under the act that we are putting them in to practice.

Recommendations

Being a strategic regulator means that, in so far as we have a choice, we have to be selective with our interventions. We will therefore apply our limited resources in ways that deliver the maximum return in terms of a sustained reduction in data protection risk. That is the risk of harm through improper use of personal information.

There are priorities we have to set. We need to focus most attention on situations where there is a real likelihood of serious harm. We also need to focus on situations where our intervention is most likely to make a long term as well as a short term difference. When we intervene we must do so in a way that gives us the best possible return and remember that we will often be at our most effective when working closely with others. We are entitled to have legitimate expectations of those who are in a position to influence data protection risk. Our effectiveness depends on them seeking and welcoming our reasonable interventions. Furthermore we have an important international role. Data protection risk in the Bangladesh is increasingly influenced by events worldwide.

Our risk-based approach is in line with good regulatory practice. It does not mean that we seek to remove all data protection risk. We do what we can to moderate the most serious risks and protect those who are most vulnerable to improper use of their information. But we will not try to take away freedom of choice and will remember that individuals themselves ought to be best placed to make decisions about their own interests. Part of our job is to equip individuals with the knowledge and tools to enable them to make their own well-informed decisions about the use and disclosure of their personal information.

Being a strategic regulator also means extending our approach beyond simply improving (through guidance, persuasion and regulatory action) the behaviour of organisations that handle personal information. We also have a legitimate role in informing and influencing the market or political environment in which they operate. Thus we will seek to have long term influence over government and the legislature at Westminster and in the devolved administrations as well as over representative bodies and other stakeholders, to ensure privacy friendly outcomes.

We will also seek to influence the legal framework that governs our own work to ensure that data protection requirements are simple, meaningful and proportionate and that we have the flexibility and tools to regulate effectively.

Building public confidence in data protection is the key in our approach. We protect people, not just information. This means we need to engage with the public and explain what we do in a way that they can easily understand and relate to.

This commitment is at the heart of how we approach our job as data protection regulator and will inform all our data protection tasks including complaints handling and the provision of advice.

Task 5: Ticket Printing

Produce Tickets

To protect the tickets from being forged or copied we can use a barcode on each ticket. We’ll print a unique 10-digit number as a barcode on the tickets, which will be checked at the entrance with the software and a simple barcode scanner. As each barcode can only be used once to enter, copied or forged tickets are rejected and the revenues are protected. By default, the tickets will be labeled with random numbers with 10 digits, which will serve as copy protection.

Figure 7: Sample barcode to print on tickets

Seat Allocation

Tickets will be printed with seat numbers, with serial numbers. Section names can be in different colours to facilitate orientation. For sections with an aisle a seat description can be added to the seat number (e.g. “left”, “right”), which helps the visitor to find the seat.

Figure 8: Sample barcode to print on ticket with seat no.

Hardware for printing tickets

There are numerous tickets available in the market but I found D-Link printers suitable for our system. Below are the details of the hardware-

Description: With the DSA-3100 and the DSA-3100P Ticket Printer, businesses and organizations can provide free or fee-based broadband Internet access to their customers or members. No complex billing system is required, guaranteeing a quick and convenient Internet experience for operators and their hot spot users. The DSA-3100P is hassle-free hot spot ticket printer that communicates with the DSA-3100 Public/Private Gateway to generate and print log-in usernames and passwords for the hot spot customers. Patented for easy loading, the DSA-3100P is connected to the DSA-3100 gateway via its RS-232 serial communication. With the DSA-3100P, the DSA-3100 gateway can manage and store up to 2,000 user accounts in its internal database and support up to 50 logged-in users at any time.

Features:

Printing Method: Thermal Dot Line Printing

Print Speed: 80 mm/Second

Connectivity: RS-232 Serial

Compatibility: D-Link DSA-3100 Public/Private Gateway

Specification:

Manufacturer

D-Link

Manufacturer Part #

DSA-3100P

Device Type

Thermal Line Label Printer

Media Handling

Media Type

Receipt Paper

Max Media Size

2.2″

Max Printing Width

1.9″

Roll Maximum Outer Diameter

3.3″

Total Capacity

1 Roll

Connectivity

Interfaces

1 x RS-232 Serial

Included Cables

1 x Serial Cable

Power Requirements

Power Supply

External, 3.5 V DC

Dimensions(H X W X D)

Unit

4.6″ x 3.8″ x 6.3″

Weight

Unit

0.9 lbs

Price: $375

Figure 9: D-Link DSA-3100P Ticket Printer

Task 6: Database Design

Database Design

Figure 10: Database Design (Performance Planning & Ticket Booking)

Data Dictionary

Table: Artist

Attribute

Data Type

Length

Primary Key

Ref. Table

ArtistID

Integer

Yes

ArtistName

Varchar

100

Table: Performance

Attribute

Data Type

Length

Primary Key

Ref. Table

PerformanceID

Integer

Yes

PerformanceName

Varchar

100

TicketPriceID

Integer

TicketPrice

ArtistID

Integer

Artist

Table: TicketPrice

Attribute

Data Type

Length

Primary Key

Ref. Table

TicketPriceID

Integer

Yes

PerformanceID

Integer

Performance

TicketPrice

Numeric

(18,2)

Table: PerformanceSchedule

Attribute

Data Type

Length

Primary Key

Ref. Table

ScheduleID

Integer

Yes

PerformanceID

Integer

Performance

PerformanceDate

Date

Table: Customer

Attribute

Data Type

Length

Primary Key

Ref. Table

CustomerID

Integer

Yes

Name

Varchar

100

Address

Varchar

250

Telephone

Varchar

20

Table: Sales

Attribute

Data Type

Length

Primary Key

Ref. Table

SalesID

Integer

Yes

PerformanceID

Integer

Performance

ScheduleID

Integer

PerformanceSchedule

TicketPriceID

Integer

TicketPrice

CustomerID

Integer

Customer

BookingType

Boolean

Table: SeatAllocation

Attribute

Data Type

Length

Primary Key

Ref. Table

SeatID

Integer

Yes

SalesID

Integer

Sales

SeatNoFrom

Integer

SeatNoTo

Integer

Task 7: Object-Orient Approaches vs. Standard Approaches

Standard Approaches

Standard approach includes many variations based on techniques used to develop information system with structured and modular programming. Standard analysis and design techniques are a software engineering methodology for describing systems as a hierarchy of functions. Below are the characteristics of Standard Approaches.

Approach for structured analysis consists of the following objects:

Data Flow Diagrams (DFD)

Shows processes and flow of data in and out of these processes.

Does not show control structures (loops)

Contains 5 graphic symbols (shown later)

Uses layers to decompose complex systems

Can be used to show logical and physical

Is a quantum leap forward to other techniques at the time, I.e. monolithic descriptions with globs of text.

The purpose of the online ticket booking system is to provide another way for purchasing cinema tickets in advance. It is an automatic system. This paper presents a formal use of the Object Oriented analysis and Design, we will illustrate our system by providing Use Case Diagrams with Specifications, Activity Diagrams, Class Diagrams, Sequence Diagrams, State Machines and Communication Diagrams on the functionalities of the system, also we will provide some process description and data dictionary.

The goals of our system are:

Record performance details

Record customer details

Record tickets sold

Print tickets

Print address labels for telephone booking

Task 1: Functional Modelling

Identification of Actors & Use Cases

Analyzing the existing system we figured out that, there are two main scopes to be covered in the system. The scopes are Performance Planning and Ticket Booking. We used the below table to identify the Actors and the Use Cases for the system.

User

Role

Use Case

Theatre Manager

Performance planning

Define the type of the performance and name it.

Performance scheduling

Define date and time of the performance.

Artist booking

Book an artist for the performance.

Ticket pricing

Determine a price for the ticket.

Clerk

Check schedule

Check the performance schedule for a particular show on a date.

Check seat availability

Checks for available seats

Capture customer information

Record customer details

Check ticket price

Check for ticket price for particular show.

Sell ticket

Record tickets sold.

Print ticket

Print ticket for the customer.

Print address label

Print address label for telephone booking.

Use Case Diagram

Following diagram shows the overall view of the Ticket Booking System for Theatre.

Figure 1: Use Case Diagram (Performance Planning & Ticket Booking)

Use Case Specification

Table 1: Use Case of Performance Planning

Number:

UC01

Req. Doc Ref:

Name:

Performance Planning

Status:

Actors:

Theatre Manager

Pre-requisites:

User should be logged in the system.

Goal:

Defining the performance type and naming it.

Use Case Relationships:

Extend:UC02, UC03

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User enters the name of the performance.

2

User enters the type of the performance.

3

System checks for all required data entry.

4

System connects to the database.

5

System writes data into the database.

6

System shows a confirmation message after successful database writes.

Alternatives:

Index

Actor Event

A 3.1

Enter required information.

A 4.1

Check network connectivity

A 4.2

Check database connectivity

A 4.3

Check database user role

A 5.1

Theatre manager gets notification of unsuccessful operation.

Table 2: Use Case of Performance Scheduling

Number:

UC02

Req. Doc Ref:

Name:

Performance Scheduling

Status:

Actors:

Theatre Manager

Pre-requisites:

User should be logged in the system.

Performance planning (UC01) should be inserted into the system.

Goal:

Define date and time of the performance.

Use Case Relationships:

Extend:

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User selects the desired performance from the system.

2

User enters the date of the performance.

3

User enters the time of the performance.

4

System checks for all required data entry.

5

System connects to the database.

6

System writes data into the database.

7

System shows a confirmation message after successful database writes.

Alternatives:

Index

Actor Event

A 3.1

Enter required information.

A 5.1

Check network connectivity

A 5.2

Check database connectivity

A 5.3

Check database user role

A 6.1

Theatre manager gets notification of unsuccessful operation.

Table 3: Use Case of Artist Booking

Number:

UC03

Req. Doc Ref:

Name:

Artist Booking

Status:

Actors:

Theatre Manager

Pre-requisites:

User should be logged in the system.

Performance planning (UC01) should be inserted into the system.

Goal:

Book an artist for the performance.

Use Case Relationships:

Extend:

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User selects the desired performance from the system.

2

User enters the name of the desired artist.

3

System checks for all required data entry.

4

System connects to the database.

5

System writes data into the database.

6

System shows a confirmation message after successful database writes.

Alternatives:

Index

Actor Event

A 3.1

Enter required information.

A 4.1

Check network connectivity

A 4.2

Check database connectivity

A 4.3

Check database user role

A 5.1

Theatre manager gets notification of unsuccessful operation.

Table 5: Use Case of Schedule Checking

Number:

UC04

Req. Doc Ref:

Name:

Schedule Checking

Status:

Actors:

Clerk

Pre-requisites:

User should be logged in the system.

Performance scheduling (UC02) should be inserted into the system.

Goal:

Check the performance schedule for a particular show on a date.

Use Case Relationships:

Extend: UC01

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User selects a desired performance and a date.

2

System shows a confirmation message for the availability of the performance.

3

System allows the user to perform the next event (UC06).

Alternatives:

Index

Actor Event

A 1.1

System notifies the user that the performance is unavailable on the desired date.

Table 6: Use Case of Check Seat Availability

Number:

UC05

Req. Doc Ref:

Name:

Check Seat Availability

Status:

Actors:

Clerk

Pre-requisites:

User should be logged in the system.

Schedule checking (UC05) should be performed by the user.

Goal:

Checks for available seats.

Use Case Relationships:

Extend:

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User selects a desired performance and a date.

2

System shows a confirmation message for the availability of the seat.

3

System allows the user to perform the next event (UC07).

Alternatives:

Index

Actor Event

A 1.1

System notifies the user that the seat is unavailable for the desired performance.

Table 7: Use Case of Capturing Customer Information

Number:

UC06

Req. Doc Ref:

Name:

Capture Customer Information

Status:

Actors:

Clerk

Pre-requisites:

User should be logged in the system.

Seat checking (UC06) should be performed by the user.

Goal:

Record customer details.

Use Case Relationships:

Extend:

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User enters the name, address and telephone number of the customer.

2

System checks for all required data entry.

3

System connects to the database.

4

System writes data into the database.

5

System shows a confirmation message after successful database writes.

Alternatives:

Index

Actor Event

A 2.1

Enter required information.

A 3.1

Check network connectivity

A 3.2

Check database connectivity

A 3.3

Check database user role

A 4.1

User gets notification of unsuccessful operation.

Table 8: Use Case of Checking Ticket Price

Number:

UC07

Req. Doc Ref:

Name:

Check Ticket Price

Status:

Actors:

Clerk

Pre-requisites:

User should be logged in the system.

Ticket pricing information (UC04) should be entered into the system.

Goal:

Check for ticket price for particular show

Use Case Relationships:

Extend: UC01

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User selects a desired performance form the system.

2

System shows the defined pricing for the ticket.

Alternatives:

Index

Actor Event

A 2.1

Price not found is notified to the user.

Table 9: Use Case of Selling Ticket

Number:

UC08

Req. Doc Ref:

Name:

Selling Ticket

Status:

Actors:

Clerk

Pre-requisites:

User should be logged in the system.

Check ticket price (UC08) should be performed by the user.

Goal:

Record tickets sold.

Use Case Relationships:

Extend:

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User selects the desired performance from the system.

2

User enters ticket selling date and the ticket price for the desired performance.

3

System checks for all required data entry.

4

System connects to the database.

5

System writes data into the database.

6

System shows a confirmation message after successful database writes.

Alternatives:

Index

Actor Event

A 3.1

Enter required information.

A 4.1

Check network connectivity

A 4.2

Check database connectivity

A 4.3

Check database user role

A 5.1

Theatre manager gets notification of unsuccessful operation.

Table 10: Use Case of Printing Ticket

Number:

UC09

Req. Doc Ref:

Name:

Printing Ticket

Status:

Actors:

Clerk

Pre-requisites:

User should be logged in the system.

Check ticket price (UC08) should be performed by the user.

Goal:

Print ticket for the customer

Use Case Relationships:

Extend:

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User triggers the print command for the sold ticket.

Alternatives:

Index

Actor Event

A 1.1

Printer not found notification will be given to the user.

Table 11: Use Case of Checking Ticket Booking Type

Number:

UC10

Req. Doc Ref:

Name:

Check Ticket Booking Type

Status:

Actors:

Clerk

Pre-requisites:

User should be logged in the system.

Print ticket (UC10) should be performed by the user.

Goal:

Determine the ticket booking type.

Use Case Relationships:

Extend:

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User selects the booking type to identify whether the ticket was booked over phone.

Alternatives:

Index

Actor Event

Table 12: Use Case of Printing Address Label

Number:

UC11

Req. Doc Ref:

Name:

Print Address Label

Status:

Actors:

Clerk

Pre-requisites:

User should be logged in the system.

Ticket booking type (UC11) should be performed by the user.

Goal:

Print address label for telephone booking

Use Case Relationships:

Extend: UC11

Include:

Association:

Generalization:

Description:

Index

Actor Event

1

User triggers the print command to print the address label.

Alternatives:

Index

Actor Event

Activity Diagram

Based on the system observation, a high level activity diagram is drawn modelling the process of ticket booking for theatre. The activity diagram will bring everybody on a common ground for understanding the system functionalities.

Figure 2: Activity Diagram (Performance Planning & Ticket Booking)

Task 2: Structural Modelling

Class Diagram (attributes & operations)

The following diagram depicts the relationships between the classes for Ticket Booking System along with the attributes and the operations.

Figure 3: Class Diagram (Performance Planning & Ticket Booking)

Task 3: Behavioural Modelling

Sequence Diagram

The following diagram is a sequence diagram for buying ticket. There are few things I want to state, that this is just one of the sequences of buying ticket. There could be more alternative sequence for buying ticket. For example, we can choice a performance before buying ticket. But the overall structures of all buying ticket sequence are similar, so, others sequence will not be shown.

Figure 4: Sequence Diagram (Performance Planning & Ticket Booking)

State Machine Diagram

Below diagram is used to give an abstract description of the behaviour of the ticket booking system. This behaviour is analyzed and represented in series of events that could occur in one or more possible states. Hereby “each diagram usually represents objects of a single class and tracks the different states of its objects through the system.

Figure 5: State Machine Diagram (Performance Planning & Ticket Booking)

Communication Diagram

Communication diagram is similar to sequence diagrams, but it provides an overview of the relationships between objects, rather than focusing on the order of messages between objects, as the software executes.

Figure 6: Communication Diagram (Performance Planning & Ticket Booking)

Task 4: Data Protection Law

Introduction

In Bangladesh Cyber Acts are in a process to be implemented. The Government of Bangladesh has formed National Council for Science and Technology (NCST). The Executive Committee for NCST has also been formed to implement policies formulated by the Council. Currently NCST is working with the general boundaries to protect the ICT industry and specific laws are yet to be decided. For our application we can follow the acts and regulations from UK.

Laws, Regulations and Best Practices

The Data Protection Act gives individuals the right to know what information is held about them. It provides a framework to ensure that personal information is handled properly. The Act works in two ways. Firstly, it states that anyone who processes personal information must comply with eight principles, which make sure that personal information is:

Fairly and lawfully processed

Processed for limited purposes

Adequate, relevant and not excessive

Accurate and up to date

Not kept for longer than is necessary

Processed in line with your rights

Secure

Not transferred to other countries without adequate protection

The second area covered by the Act provides individuals with important rights, including the right to find out what personal information is held on computer and most paper records.

Data protection laws should be adequate enough to maintain the below options at a minimum-

How to access information

This allows one to find out what information is held about him/her on a computer and within some manual records, such as medical records, files held by public bodies and financial information held by credit reference agencies.

Correcting information

This allows one to apply to a court to order a data controller to correct, block, remove or destroy personal details if they are inaccurate or contain expressions of opinion based on inaccurate information.

Preventing processing of information

This means one can ask a data controller not to process information about him/her that causes substantial unwarranted damage or distress. The data controller is not always bound to act on the request.

Preventing unsolicited marketing

This means a data controller is required not to process information about one for direct marketing purposes if he/she asks them not to.

Preventing automated decision making

This means one can object to decisions made only by automatic means. For example, where there is no human involvement.

Claiming compensation

This allows one to claim compensation through the courts from a data controller for damage, and in some cases distress, caused by any breach of the act.

Exempt information

This allows one to ask the information commissioner to investigate and assess whether the data controller has breached the act.

There should be a committee (in our case NCTS could be the choice) that will have legal powers to ensure that organizations comply with the requirements of the data protection laws. It is notable here that these powers are focused on ensuring that organizations meet the obligations of the act.

To promote best practices the regulation-

The committee should carry out consensual audits with data controllers to assess their processing of personal information.

The committee should see auditing as a constructive process with real benefits for data controllers.

The committee should adopt, wherever possible, a participative approach including working closely with the data controller to agree the timing and scope of the audit.

Comply with Data Protection Law

A short checklist can help us to comply with the data protection laws in our system. Maintaining all the items in the checklist does guarantee compliance but it should mean that we are heading in the right direction.

We should store only the related information about the customer and the personnel’s involved with the system. And we need to make sure that we know what we are going to do with the information.

The person should know, what are the information we are holding. He/she should understand what it will be used for.

Information should be held securely whether it’s on the paper or on computer.

The system should prevent any unwanted access of its resources.

The information should be deleted as soon as there is no need for it.

Access control list should be created with a strict need to know to prevent data access from all kind of users of the system.

We should train the stuff in their duties and responsibilities under the act that we are putting them in to practice.

Recommendations

Being a strategic regulator means that, in so far as we have a choice, we have to be selective with our interventions. We will therefore apply our limited resources in ways that deliver the maximum return in terms of a sustained reduction in data protection risk. That is the risk of harm through improper use of personal information.

There are priorities we have to set. We need to focus most attention on situations where there is a real likelihood of serious harm. We also need to focus on situations where our intervention is most likely to make a long term as well as a short term difference. When we intervene we must do so in a way that gives us the best possible return and remember that we will often be at our most effective when working closely with others. We are entitled to have legitimate expectations of those who are in a position to influence data protection risk. Our effectiveness depends on them seeking and welcoming our reasonable interventions. Furthermore we have an important international role. Data protection risk in the Bangladesh is increasingly influenced by events worldwide.

Our risk-based approach is in line with good regulatory practice. It does not mean that we seek to remove all data protection risk. We do what we can to moderate the most serious risks and protect those who are most vulnerable to improper use of their information. But we will not try to take away freedom of choice and will remember that individuals themselves ought to be best placed to make decisions about their own interests. Part of our job is to equip individuals with the knowledge and tools to enable them to make their own well-informed decisions about the use and disclosure of their personal information.

Being a strategic regulator also means extending our approach beyond simply improving (through guidance, persuasion and regulatory action) the behaviour of organisations that handle personal information. We also have a legitimate role in informing and influencing the market or political environment in which they operate. Thus we will seek to have long term influence over government and the legislature at Westminster and in the devolved administrations as well as over representative bodies and other stakeholders, to ensure privacy friendly outcomes.

We will also seek to influence the legal framework that governs our own work to ensure that data protection requirements are simple, meaningful and proportionate and that we have the flexibility and tools to regulate effectively.

Building public confidence in data protection is the key in our approach. We protect people, not just information. This means we need to engage with the public and explain what we do in a way that they can easily understand and relate to.

This commitment is at the heart of how we approach our job as data protection regulator and will inform all our data protection tasks including complaints handling and the provision of advice.

Task 5: Ticket Printing

Produce Tickets

To protect the tickets from being forged or copied we can use a barcode on each ticket. We’ll print a unique 10-digit number as a barcode on the tickets, which will be checked at the entrance with the software and a simple barcode scanner. As each barcode can only be used once to enter, copied or forged tickets are rejected and the revenues are protected. By default, the tickets will be labeled with random numbers with 10 digits, which will serve as copy protection.

Figure 7: Sample barcode to print on tickets

Seat Allocation

Tickets will be printed with seat numbers, with serial numbers. Section names can be in different colours to facilitate orientation. For sections with an aisle a seat description can be added to the seat number (e.g. “left”, “right”), which helps the visitor to find the seat.

Figure 8: Sample barcode to print on ticket with seat no.

Hardware for printing tickets

There are numerous tickets available in the market but I found D-Link printers suitable for our system. Below are the details of the hardware-

Description: With the DSA-3100 and the DSA-3100P Ticket Printer, businesses and organizations can provide free or fee-based broadband Internet access to their customers or members. No complex billing system is required, guaranteeing a quick and convenient Internet experience for operators and their hot spot users. The DSA-3100P is hassle-free hot spot ticket printer that communicates with the DSA-3100 Public/Private Gateway to generate and print log-in usernames and passwords for the hot spot customers. Patented for easy loading, the DSA-3100P is connected to the DSA-3100 gateway via its RS-232 serial communication. With the DSA-3100P, the DSA-3100 gateway can manage and store up to 2,000 user accounts in its internal database and support up to 50 logged-in users at any time.

Features:

Printing Method: Thermal Dot Line Printing

Print Speed: 80 mm/Second

Connectivity: RS-232 Serial

Compatibility: D-Link DSA-3100 Public/Private Gateway

Specification:

Manufacturer

D-Link

Manufacturer Part #

DSA-3100P

Device Type

Thermal Line Label Printer

Media Handling

Media Type

Receipt Paper

Max Media Size

2.2″

Max Printing Width

1.9″

Roll Maximum Outer Diameter

3.3″

Total Capacity

1 Roll

Connectivity

Interfaces

1 x RS-232 Serial

Included Cables

1 x Serial Cable

Power Requirements

Power Supply

External, 3.5 V DC

Dimensions(H X W X D)

Unit

4.6″ x 3.8″ x 6.3″

Weight

Unit

0.9 lbs

Price: $375

Figure 9: D-Link DSA-3100P Ticket Printer

Task 6: Database Design

Database Design

Figure 10: Database Design (Performance Planning & Ticket Booking)

Data Dictionary

Table: Artist

Attribute

Data Type

Length

Primary Key

Ref. Table

ArtistID

Integer

Yes

ArtistName

Varchar

100

Table: Performance

Attribute

Data Type

Length

Primary Key

Ref. Table

PerformanceID

Integer

Yes

PerformanceName

Varchar

100

TicketPriceID

Integer

TicketPrice

ArtistID

Integer

Artist

Table: TicketPrice

Attribute

Data Type

Length

Primary Key

Ref. Table

TicketPriceID

Integer

Yes

PerformanceID

Integer

Performance

TicketPrice

Numeric

(18,2)

Table: PerformanceSchedule

Attribute

Data Type

Length

Primary Key

Ref. Table

ScheduleID

Integer

Yes

PerformanceID

Integer

Performance

PerformanceDate

Date

Table: Customer

Attribute

Data Type

Length

Primary Key

Ref. Table

CustomerID

Integer

Yes

Name

Varchar

100

Address

Varchar

250

Telephone

Varchar

20

Table: Sales

Attribute

Data Type

Length

Primary Key

Ref. Table

SalesID

Integer

Yes

PerformanceID

Integer

Performance

ScheduleID

Integer

PerformanceSchedule

TicketPriceID

Integer

TicketPrice

CustomerID

Integer

Customer

BookingType

Boolean

Table: SeatAllocation

Attribute

Data Type

Length

Primary Key

Ref. Table

SeatID

Integer

Yes

SalesID

Integer

Sales

SeatNoFrom

Integer

SeatNoTo

Integer

Task 7: Object-Orient Approaches vs. Standard Approaches

Standard Approaches

Standard approach includes many variations based on techniques used to develop information system with structured and modular programming. Standard analysis and design techniques are a software engineering methodology for describing systems as a hierarchy of functions. Below are the characteristics of Standard Approaches.

Approach for structured analysis consists of the following objects:

Data Flow Diagrams (DFD)

Shows processes and flow of data in and out of these processes.

Does not show control structures (loops)

Contains 5 graphic symbols (shown later)

Uses layers to decompose complex systems

Can be used to show logical and physical

Is a quantum leap forward to other techniques at the time, I.e. monolithic descriptions with globs of text.

Context Diagram

Share this: Facebook Twitter Reddit LinkedIn WhatsApp  

Cite This Work

To export a reference to this article please select a referencing stye below:

Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.
Reference Copied to Clipboard.

Related Services

View all

DMCA / Removal Request

If you are the original writer of this essay and no longer wish to have your work published on the UKDiss.com website then please: