Technical Design:Application design

9.5 Application design

The business logic layer of our theatre application will be implemented using business objects developed in ColdFusion. ColdFusion is produced by Macromedia (www.macromedia.com) and consists of an Application Server and a Markup Language (CFML). The ColdFusion server takes files containing CFML and HTML and converts them into pure HTML web pages for delivery to the user's browser. The ColdFusion Server is an extension to the web server, which could be Microsoft's Internet Information Server (IIS) on a Windows NT platform, or an Apache server on a Unix platform. The ColdFusion Markup Language (CFML) is similar in style to HTML, being tagbased, but has all the facilities and power of a programming language such as Visual Basic as well as database connectivity and many web-specific tags, such as email and file upload. We will look at how ColdFusion works in more detail in chapter 10, software system construction.

Web pages do not fit comfortably with an object-oriented approach to design. In converting the sequence diagram to web pages a rather functional feel to the design is introduced. To preserve an OO approach to the design we will use ColdFusion components to handle the business logic layer of the three-tier architecture. A component is a package of ColdFusion code that will implement the operations of one or more classes. For example, a component called production.cfc will be used to implement the operations of the Production class. This component will implement functions to add, change, delete, and list productions in the database. Components are new to ColdFusion MX (note that they are not available in ColdFusion version 5) and are stored with the file suffix ''.cfc".

As long as components are used throughout the application for all types of access to the database then the three-tier architecture can be preserved and the OO analysis of chapter 8 can be carried through to the design of the business logic. By preserving the three-tier architecture we could change the database vendor, e.g., from Microsoft's SQL Server to Oracle, by modifying the components in the business logic layer - the presentation layer would not be

affected. This approach also makes it easier and safer to change the business logic. For example, changes to the seat allocation algorithm need only be made in the performance.cfc component since this is the only way that seats can be allocated to bookings (using the method 'findSeats'). The complexity of the seat allocation logic is hidden from the presentation layer - we don't care how it works, just as long as it returns a set of available seats.

9.5.1 Sequence diagrams

In figure 9.11 the UML sequence diagram from chapter 8 is mapped directly into web pages (figure 9.11). Each web page will interact with the business data via the business logic that has been encapsulated in the ColdFusion components.

The sequence diagram shows the web pages across the page and the interactions between the user and the pages running down the page. The icon on the web pages is the Allaire logo and indicates that these pages will be ColdFusion templates (different symbols should be used for standard HTML pages, active server pages, etc.). The dashed lines on the diagram show the return values from an interaction.

User regostration

Cookies are a useful way of tracking customers, but they do not work in all situations, as is the case if a user refuses to allow cookies to be placed in their browser. Furthermore, the cookie is specific to a computer, not to a person, so if a user accesses the web site from another machine (e.g., at work or from a cyber cafè) then the cookie will not be on that computer and the web site will not be able to match the person with a customer record. One way round this is to encourage customers to register with the ticket booking site (figure 9.12) so that when a user logs in with a user id and password it will be possible to build a profile of their activity and preferences. Why should users register with the theatre booking system? There may need to be an incentive, such as discounted ticket prices, 'theatre miles', special offers such as member-only ticket auctions, or just a sense of a vibrant theatre-going community.

Payments

The credit card processing is shown as being handled by a third party, GlobalPay (figure 9.11). The benefit of this approach is that credit card details need never be held by the Theatre. GlobalPay will authorize payment and return processing to the page nominated by the Theatre, i.e., confirmation.cfm. This page then commits the seat transaction and confirms the booking to the  user. If the theatre booking takes details of credit cards then there must be encryption of the communication while in transit between user browser and server as well as secure (encrypted) storage of the credit card details on the server. By displaying prominently on its site that a large and trusted third party will process credit card transactions the Theatre can mitigate concerns of customers about transacting via the Internet.

9.5.2 Seat reservations - locking strategy

With physical products many web sites will simply carry on taking orders for products as they arrive and worry about fulfilment off-line in back office systems. Of course, this can lead to situations where the product ordered is out of stock and result in dissatisfied customers, so more sophisticated operations link their Internet sales systems to their back office inventory systems. With a product like theatre tickets we are selling this seat, not just any seat for a performance.

The conceptual modeling of the classes and interactions was not concerned with the details of seat reservations. As part of the technical design we need to consider how specific seats will be held in the time between an Internet customer being allocated seats at a performance and the customer making a payment. Clearly, we do not want a customer to be allocated four seats for a performance of Hamlet only to find that by the time their payment has been processed the seats have been sold or reserved by somebody else. Therefore, the system must have a mechanism for reserving seats pending payment. From the theatre's perspective we do not want seats to be reserved indefinitely because a customer could be allocated seats but never follow through to payment. Therefore, there must be a mechanism for releasing seats that have been allocated but never committed by a ticket transaction.

A simple strategy for seat reservations will be implemented. Seats will be held for 10 minutes. The time limit of 10 minutes is arbitrary and would be established as an application-wide variable that can be changed as appropriate to balance customer convenience and theatre occupancy. After the hold period of 10 minutes is up, reserved seats can be reallocated to other customers. In simplified form the algorithm for seat bookings is, for a given part of the theatre and a given performance, start at the first seat and:

DO UNTIL sufficient seats at performance are found IF the seat at performance is not connected to a transaction (i.e., seat is unsold) THEN IF the seat at performance is not reserved OR (time now - reserved time) is more than hold_period THEN reserve the current seat ENDIF ENDIF NEXT seat  This is a very simple seat allocation and reservation algorithm. Seats are allocated in blocks starting with the first seat in the part of the theatre requested. If sufficient seats are found then setting the attribute reserve time to the current time reserves them for the customer. A customer is guaranteed a minimum period, such as 10 minutes, between being allocated seats and paying for them. During this period no other booking transaction will attempt to allocate these seats. After 10 minutes it is possible for another customer to place a hold on the seats. Once the customer pays for the seats then a connection is made with a transaction and the seats will be ignored in future seat allocations.

A weakness of the algorithm is that seats are filled starting at seat A1 and filled in sequence. This might not be ideal since singletons might be left at the end of each row and performances with low occupancy levels would end up with all the theatre-goers bundled together at the front of the theatre! In practice the seat allocation and reservation algorithm is likely to be considerably more sophisticated, but at least all of the complexity of the seat allocation algorithm can be hidden within the business logic of the performance component.

9.5.3 State transition diagrams

A seat at performance must be in one of the following states: available, reserved, or booked. In the database we can tell the state of a seat at performance as follows:

• Available: there is no row in the table for this combination of performance and part of theatre. If we try to find a seat and the set returned has zero rows then we can add the seat to the database and reserve it

• Booked: if the seat at performance exists and has a value in the transactionID field then it has been paid for and cannot be rebooked

• On hold: if the seat at performance exists but the transactionID is null then it has been reserved. This is why the transactionID field in the SeatAtPerformance table is marked as optional - in the early life of a seat at performance there will not be an associated transaction. If the reservation has timed out, i.e., older than 10 minutes, then it can be reserved by another customer.

It must be possible to distinguish the different states of each of the classes in the database, using a combination of attribute values and relationships. Although it is often done, it is not always necessary to add an attribute such as seatStatus since the seat status can be derived from other data in the database. To add a redundant attribute represents an unnecessary denormalization of the database design.

The table SeatAtPerformance needs to be modified to allow a seat to be held pending the completion of a ticket transaction. This means that the attribute ticketTransactionID needs to be optional and a new attribute, seatHoldTime added to record when the seat was put on hold:

SeatAtPerformance seatAtPerformanceID performanceID seatID (o) ticketTransactionID priceAchieved seatHoldTime Unique: seatID, performanceID Foreign: ticketTransactionID →TicketTransaction Foreign: seatID →Seat Foreign: performanceID →Performance

This design is simple but has the benefit of ensuring that any locked seats can be reclaimed as soon as the lock times out, avoiding the business damage of the application reporting seats as reserved when they are in fact available.