10.1 Application Functionality

The sample application models a typical e-commerce application, an online pet store. E-commerce sites like this are among the most common Web applications. The application interface is presented to its customers through a Web site and a customer interacts with the application using a Web browser. Other potential users of the application include administrators responsible for maintaining inventory and performing other managerial tasks, and associated businesses such as suppliers. Each class of users would have access to specific categories of functionality, and each would interact with it through a specific user interface mechanism.

Like a typical e-commerce site, the pet store presents the customer with a catalog of products. The customer selects items of interest and places them in a shopping cart. When the customer has selected the desired items and indicates readiness to buy what is in the shopping cart, the sample application displays a bill of sale: a list of all selected items, a quantity for each item, the price of each item, and the total cost. The customer can revise or cancel the order. When the customer is ready to accept the order, the customer provides a credit card number to cover the costs and supplies a shipping address.

10.1.1 Scenarios

The following scenarios demonstrate a few key ways the pet store application could be used by describing a user's view of interactions with the system. By walking through these scenarios, you'll gain a better understanding of the requirements as well as the interactions that happen within the system.

The sample application could support three very different kind of scenarios. First, there is the shopping interface described earlier, that allows shoppers to buy items online. Second, there is an administration interface for carrying out store administration activities. Finally, there is a business-to-business interface through which the store can interact with suppliers. The scenarios in this section demonstrate all three types of interaction, while the remainder of this chapter focuses mainly on the shopping interactions.

10.1.1.1 Shopping Scenario

The primary function of the sample application is to provide an interface where customers can browse through and purchase items. This shopping interaction typically starts with the customer's visit to the application home page and ends when the customer orders from the site:

1. A customer connects to the application, by pointing the browser to the URL for the application's home page. This allows the customer to browse through the catalog or search for products through some search interface.
2. At any point during the whole interaction, the customer can sign into the application by providing an account identifier and a password. When the customer signs in, the application can recall information about the customer such as a preferred shipping address and billing information, buying preferences, and so on. Customers who don't have an account can create one at any time by providing an account identifier, customer name, password and some other personal details.
3. The customer browses through the catalog. The customer can select a category to see a list of all the products in that category. For example, the customer can select the category Cats to view all cats that the pet store sells. Alternatively, the customer can search for products using one or more keywords describing the product. For example searching with keywords Persian and mammal might bring a list of Persian dogs and cats.
4. The customer selects a particular product in the list. Now, the application displays detailed information about the selected product. The description and image of the product is shown along with pricing information. When there are several variants of the same product, each variant is shown as a separate item. For example, when showing details about an African parakeet, the items could be large male African parakeet, small female African parakeet, and so on.
5. The customer decides to purchase a particular item and clicks a button to add the item to the shopping cart. The customer may continue shopping, adding more items to the shopping cart. As the customer browses through the catalog, the application remembers all the items placed in the cart. The customer can recall the shopping cart at any time during the interaction to review or revise the contents of the cart.
6. The customer can choose to order the items in the shopping cart at any time. This is called checking out. A checkout button is presented along with the shopping cart. If the customer is not signed in, the application brings up a signin/signup screen. Here the customer can sign in, or set up a new account, if they don't have one. After the customer is signed in, order processing continues as before.
7. When the customer asks to check out, the application presents a summary of all items that would be ordered along with their costs. At this point the customer must confirm the order.
8. When the customer confirms the order, the application begins to gather shipping and billing information for the order. First it presents a form, where the customer can enter shipping information. If the customer is signed into the application at this time, the form comes up filled in with the customer's preferred shipping address.
9. When the customer enters the shipping address, the customer is asked to enter billing information, including credit card details and a billing address. If the customer is signed in, the application recalls these details and the forms are returned filled in.
10. Finally the customer confirms the order and the application accepts the order for delivery. A receipt including a unique order number and other order details is presented to the customer. The application validates credit card and other information, updates its inventory database, and optionally sends a confirmation message via email.

This is a fairly typical shopping scenario. Some variations are possible, especially in the way the catalog is presented to the customer. For instance, the application could provide specialized lists of items such as best-sellers, or discounts on certain items. There may also be variations in order processing, such as reducing the steps for making an order when the customer is already signed in. The application developer needs to design the application to support these variations, as well as others that might arise as the application evolves.

Although this scenario presents the application from a single customer's point of view, the pet store application needs to simultaneously support a large number of shoppers.

10.1.1.2 Administration Scenario

The pet store application does most of the administrative work of managing orders, creating new accounts, and other details without manual intervention. However, there are some tasks where manual intervention is desirable or required. These are often administration tasks, such as managing the inventory, reestablishing forgotten customer passwords, rolling back orders, handling returned merchandise, and processing and shipping of orders.

The administration interface of the pet store application could use a Visual Basic client running in a Microsoft desktop application such as Microsoft Excel. The application must be designed to support more than one administrator simultaneously using the administration interface.

The administration scenario models inventory management, where an administrator updates inventory when new shipments come in:

1. The administrator starts up the shopping client application. When the client starts, it asks the administrator to sign on to the system using a user name and password. The administrator enters information for one of the accounts that has administration privileges.
2. The client application then presents a list of products in the catalog, perhaps in order by category, with the product details such as description and name also shown.
3. The administrator clicks a product to see the items as well as their inventory status. For any item displayed, the administrator can modify the inventory status.
4. The administrator clicks an update button, causing the changes to inventory status to be committed to the inventory database.

10.1.1.3 Business-to-Business Scenario

Businesses often have a need to interact with other businesses through their custom applications. For example, a retailer needs to work with suppliers to procure inventory, with shipping agencies for managing shipments, and with billing agencies for handling its billing needs. In fact, significant pieces of the application such as inventory control could themselves be off-loaded to a separate business.

It would be desirable to have some of these interactions be automated. When businesses are tightly coordinated, perhaps under the same ownership or administration, these interactions could be closely-coupled. In such interactions, businesses expose their entities and data to each other. However, most of the time it is desirable to keep the businesses loosely-coupled. Here businesses interact by passing asynchronous messages to each other. This messaging approach also models the real world more closely, where businesses work together by sending faxes and packages, and so on, to each other.

An interaction between the pet store and one of its suppliers would illustrate a loosely-coupled business interaction. A typical scenario might be:

1. A customer places an order. This causes the inventory to fall below a pre-established low water mark, triggering the application to initiate an order to obtain more items from the supplier. This process happens asynchronously and does not interfere with the transaction being performed by the customer.
2. The application sends a purchase request message to the supplier. A typical purchase request message could say, "Send 100 male African parakeets."
3. At some later time, the supplier sends a message in response to the request. If the supplier does not have enough parakeets to fill the order, the message might say, "Can't fulfill request. Have 20 parakeets available."
4. The application, upon receipt of the message, might send another request for a smaller quantity. The message might say, "Send 20 male African parakeets."
5. The supplier initiates delivery of the shipment, and sends a message back to the application. This message might say, "Request completed. 20 parakeets shipped. Shipment number is 1234."

The interaction between the store and supplier is depicted in a timing diagram in Figure 10.1.

Figure 10.1 A Store-Supplier Business-to-Business Interaction

One thing to observe about this scenario that it is asynchronous. The action is initiated when a customer places an order. However, it proceeds without blocking the customer's interaction. Also note that neither the store nor the supplier is blocked waiting for the other to respond. While the procurement is in progress, the store's application and the supplier's system carry on with their activities as usual.

10.1.2 Functional Specification

With a clear understanding of the kind of scenarios in which the application would be used, let's create an initial specification of the user interface of the application. This section presents a sketch of the main user interface of an application that supports the shopping interactions. It is possible to create a similar sketch for a user interface for administration interactions. Business interactions typically do not require a user interface. As mentioned earlier, the remainder of this chapter focuses on the shopping functionality of the application.

Upon arriving at the main page of the online pet store, a customer would expect some of the following features:

• A set of links or navigation bars on each page that provide quick access to common navigational tasks.
• An organized view of the site's contents through a categorized catalog.
• A search mechanism to provide a way to locate items based on keyword descriptions. Other types of quick access could be in terms of popular items or new additions.
• A master view of the catalog that lists items of interest. This could be the result of the customer navigating through a catalog category or the outcome of a keyword search.
• A detail view that describes the details of a particular item. Shoppers click on an item in the master view to zoom in on details, including a description, a picture, the price, a link to the supplier's URL, and so on.
• A shopping cart view that lets customers review the contents of their shopping cart. The cart allows the customer to modify quantities of items in the cart, including removing items from the cart altogether.
• A checkout or bill-of-sales view that displays the total order cost and allows the customer to enter billing and shipping information. The customer will want assurance that order details including shipping and credit card information are transferred securely and accountably. The interaction must be authenticated to positively identify the customer for the purposes of accountability and encrypted through HTTPS to protect the privacy of the information the customer provides.
• A receipt view to provide confirmation of the purchase through a unique order identifier or other mechanism to track the newly placed order and review details of the order.

In addition to these user interface requirements, the application must also support some security requirements. We address these in Section 10.11.