Expert one-on-one J2EE Design and Development phần 3 docx

User Populations The application must support three groups of users: public Internet users customers; box office users employees of the X Center who assist customers who have chosen not

❑

❑

❑

❑

❑

❑

❑

❑

❑ http://g.oswego.edu/dl/html/javaCodingStd.html

❑ http://www.chimu.com/publications/javaStandards/part0003.html#E11E4

❑ http://www.ambysoft.com/javaCodingStandards.html

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

Error in com.foo.bar.MagicServlet: Cannot load class com.foo.bar.Magic

Error in com.foo.bar.MagicServlet: Cannot load class 'com.foo.bar.Magic '

what where

❑

❑

❑

Logger.getLogger(String name)

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

❑

Requirements for the Sample

Application

In this chapter, we will specify an application realistic enough to provide the basis for worthwhile discussion

of J2EE architectural decisions and a meaningful implementation exercise This application has been designed from the business perspective (with generous input from a business analyst friend) rather than aJ2EE technology perspective Although it is simpler than a real application to avoid introducing irrelevant detail, it is more than an excuse to demonstrate a preconceived set of J2EE technologies

We will refer back to this chapter throughout the rest of this book to underpin technical decisions, the development of a testing strategy and as we approach implementation

Note: Real application requirements will be more formal than those presented in this chapter For

example, I haven't used any particular methodology (such as the Rational Unified Process) for

presenting requirements The aim here is not to provide an example of how to formulate business

requirements, but to convey clear, concise requirements that will provide a basis for discussing the J2EE solution that we'll build throughout the rest of the book.

179

Brought to you by ownSky

The requirement is for an online seat reservation system for the X Center, an arts and entertainment complex that presents shows in a range of genres such as opera, concert, theater, and comedy The X Center currently has three performance halls Each has a default seating plan, used for most performances, but occasionally a particular show may vary this slightly The seating plan for Mahler's Eighth Symphony might need to remove 20% of seats from sale to accommodate the choir When Zanetti's circus performs,

6 seats from each row between the stage and the rear of the hall must be withdrawn from sale to make room for the caged walkway through which the lions move This also affects which seats are considered adjacent

The X Center is owned by the Z Group, an international entertainment company that owns many other theaters and entertainment venues The Z Group views the online booking system for the X Center as a i pilot, and hopes to use it as a basis for systems for its other venues Hence from the initial release, this system must allow for rebranding It must be possible to change the presentation of the site without changing the basic functionality, so that another theatre in the group could allow its customers to book tickets with presentation following that theatre's own branding

Some of the X Group's other venues are in non-English speaking countries, so although there is no immediate requirement for internationalization, it will be necessary if the system is successful Some venues are in multi-lingual countries such as Switzerland, so if the system is adopted in these venues it must allow users to choose their own language

The X Center presently has no online ticketing system Its 5 to 10 box office employees (more casual staff are employed during peak times) presently use a client-server system based around an Oracle database

No part of this system, except perhaps parts of the database schema, is likely to be reusable for the web interface

The following business requirements do not attempt to describe every functional aspect of a 'real

world' ticket reservation system.

User Populations

The application must support three groups of users: public Internet users (customers); box office users (employees of the X Center who assist customers who have chosen not to purchase online); and administrators (employees of the X Center responsible for posting and updating data)

Public Internet Users

These users are customers, members of the public, accessing the service through a web browser Most connect using a modem at speeds of up to 56K, and it is important that the system has acceptable response times over a modem connection Customers wish:

o To find out what shows are on offer and access information about shows and performances

o To find out what performance dates still offer seating availability

o To book seats online, using a credit card

180

Brought to you by ownSky

Requirements for the Sample Application

It is possible that premium services, such as the ability to book a larger number of seats in a single transaction, might be offered to a distinct "registered user" community in the future However, in the initial system, registration is offered only as a convenience to save users re-entering their billing address

The priority is to ensure that the path to purchasing tickets is as straightforward as possible, hence users

will not be forced to register, which may risk alienating them

In order to fulfill these requirements, the system should offer a simple, usable, and fast web interface It is important that this interface works on as many browsers as possible Browser-specific functionality should

be avoided, and the required browser level should be as low as possible without sacrificing functionality Applets, Flash animations and the like are considered likely to deter users, and should not be used

Box Office Users

These are employees of the X Center, who work within the X Center itself, and are on the local network Some employees may work from home, in which case they will have access to a broadband Internet connection Box office users perform the following activities:

o Respond to phone and over-the-counter enquiries by members of the public, principally on the availability of seating To support this task, box office users must be given powerful query

functionality unavailable to public Internet users, to enable them quickly to respond to questions such

as, "What is the first date on which I can have 25 adjacent B Reserve seats to Carmen?"

o Sell tickets to members of the public who wish to see a show

o Supply tickets to customers who booked online but chose to collect the tickets from the box office instead of having them delivered by post This is also necessary for late bookings, when there isn't time to post out tickets

o Occasionally, cancel reservations on phone request

These users are primarily concerned with service reliability and usability They receive a constant flow of enquiries from customers who expect to be serviced when they call Thus it is essential that the public Internet interface should not reduce the reliability or performance of the box office interface

As box office users can be given training on how to use the system, the priority should be functionality, rather than ease of use Box office users must be given a powerful system that offers a quick way of performing common tasks As the box office interface is for internal use only, there should be less emphasis on its branding and cosmetics

The X Center management team wishes to maximize their IT investment and so believe that the same online ticket reservation system should service public Internet users and box office staff Box office users, like customers, will use a web interface This interface will be protected from Internet users via role-based security, and will have a separate entry point from the public Internet application The system will automatically grant the appropriate privileges, based on username and password

181

Brought to you by ownSky

These are employees of the X Center in which the ticketing system will be in operation Admin users must be located within the X Center itself, accessing the local network They fulfill a variety of clerical, marketing and management functions:

o Add new shows and performances

o Run management information and financial reports

o Configure settings of the ticketing system; such as the maximum number of tickets that can be purchased in one transaction, and the period of time tickets can be reserved before payment is made.The Center's management wish to use a consistent technology set within their system to minimize the number of skills their IT department requires, hence they would prefer that the same web technology was used for the Admin interface as for the customer and box office interfaces, rather than another technology such as Swing or VB Management is also keen that the Admin interface should require no installation; authorized staff should be able to access it on any machine within the X Center building, and

it should require no rollout process and ongoing updates

The Admin interface will offer the additional security of running on a port accessible only within the X

Center's firewall This means that the Admin must run in a different web application (although possibly still

on the same physical server) The Admin interface will be centered on the Oracle database, which will be its main means of communication with the other interfaces As the X Center already has some Oracle skills in-house, the development of the Admin interface can be deferred until Phase 2

Assumptions

Let's now consider the following assumptions:

o Internet users will not be required to accept cookies, although it is expected that most will

o Seats for each show will be divided into one or more seat types, such as Premium Reserve Seating

plan and the division of seats into types will be associated with shows, not individual performances

o All seats within the same class for the same performance will be the same price However, different performances of the same show may have different price structures For example, matinees may be cheaper than evening performances, to attract families

o Users will request a given number of seats of a chosen type for a specified performance, and will not be allowed to request specific seats Users will not be allowed to provide "hints" for seat allocation such as "towards the front of A Reserve and on the right rather than the left

o Users requesting seats will be assumed to want adjacent seats, although they will be offered whatever is available if sufficient adjacent seats cannot be allocated Seats are not considered to be adjacent if they are separated by an aisle

o Internet customers will not be able to cancel a booking once payment has been processed They must call the box office, which will apply the X Center's policies regarding cancellation and refunds, and use the box office interface to cancel bookings when this is allowed

182

Brought to you by ownSky

Requirements for the Sample Application

o No allowance will be made for special seating requirements such as wheelchair access,

although this is an important consideration in most ticketing systems

Delivery Schedule

The X Center's management has determined that having a true online ticketing solution is a business priority Thus they have determined a delivery schedule to ensure that the public system comes online as soon as possible This schedule calls for the application to be delivered in three phases:

o Phase 1: Core Internet user interface, as described in the next section, and the box office interface

o Phase 2: Admin interface In Phase 1, no GUI will be available to Admin users; they will need to work with the database using Oracle tools Development resources will be available to support Admin users in these tasks during Phase 2 development

o Phase 3: More sophisticated Internet interface This will offer registered users premium services and add internationalization support

The sample application will extend only to Phase 1 The whole of the core Internet user interface will be implemented, and part of the box office interface (which won't be fully defined in this chapter) However, the sample application must define an architecture that will provide a basis for the later phases, so their requirements must be considered in the meantime

Internet User Interface

Let's look in detail at the public Internet user interface This illustrates many common issues in building J2EE web applications

183

Brought to you by ownSky

Basic Workflow

Although I've used UML state diagram graphics, each box represents a screen presented to a user successfully choosing a performance and purchasing a number of tickets, rather than a state The following diagram shows an Internet user successfully booking seats:

Users are initially presented with the welcome screen, a list of all genres (such as Opera) and shows

(such as Wagner's Tristan und Isolde) playing at the X Center (see Application Screens below for

screenshots) Users can then proceed to the display Show screen, which shows all performance dates for a given show, along with the types and prices of seat on sale and the availability of each type of seat This screen should indicate only whether each type of seat is available or sold out, not the

number of seats remaining This meets the needs of most users while avoiding disclosure of sensitive business information - for example, those tickets to a particular show might be selling poorly Users can request a number of seats of a given type for a particular performance, in which case these seats are reserved to allow time for online credit card payment

The system distinguishes between the concepts of reservation and confirmation/purchase in the booking

process The user can reserve seats for a performance for a period of time (typically 5 minutes), which will

be held in system configuration Reservation protects these seats from being shown as available to other users Confirmation occurs when the user provides a valid credit card number, at which point a reservation becomes an actual purchase Reservations are held in the database and in the user's session state Reservations must either:

o Progress to bookings as a result of confirmation

o Expire, if the user fails to proceed to purchase in the given time These seats will then be available to other users However, the user who made the reservation may still purchase the seats without seeing

an error message if they are still free when (s)he submits the payment form

184

Brought to you by ownSky

Requirements for the Sample Application

o Be cleared, as the result of user activity other than continuing on to purchase For example, if a user makes a reservation but then navigates back to the display show screen, it is assumed that (s)he does not want to proceed to purchase these seats, and that they should be returned to fully available status

Error Handling

I the event of a system error (such as the J2EE server failing to connect to the database), the user should

be shown an internal error screen consistent with the current branding This should advise the ser to try again later Support staff should be notified by e-mail and through the log file record in the event of serious problems The user must never see a screen containing a stack trace, "500 Internal Error" or other technology or server-specific error message A user requesting an invalid URL should see a screen consistent with the current branding advising that the requested page was not found and containing a link

to the welcome page

Application Screens

Let's now take a closer look at workflow in the public Internet interface The following diagram is a more detailed version of the previous diagram, and shows all screens available to the Internet user, and the transitions between them:

185

Brought to you by ownSky