Case Study: A Product Support Center in Java

Creating Quick Response Code in Java Case Study: A Product Support Center

Figure 19-1

The quality assurance support person for the product receives the problem report from development and tests the fix This is an integration test, in which the effect of the new code on existing systems is examined If the fix introduces other problems or fails to pass all the established test cases, the problem is rerouted to development Otherwise, the fix is routed to product support, so the customer can be contacted and supplied with the new code At any point, system users can look up the status of a particular problem, add comments to it, and route the problem to its next destination To be most effective, each routing would be accompanied by e-mail sent to the new problem owner That part isn t developed here, deferring the topic to 21, which examines the Java Mail API

To summarize, the system users and their functions are as follows: Call center agent Verifies customer entitlement Enters new problems Can look up status of existing problems Product support Receives incoming problem reports from call center Can view outstanding problems by product Interviews customer Updates problem status Adds comments Routes problem to development Developer Receives problem reports from product support Can view outstanding problems by product Analyzes problem and develops fix Adds comments to problem report Routes problem to quality assurance Quality assurance Receives problem reports and fixes from development Performs integration test Adds comments to problem report Routes fixed problems to product support May route problem back to developer if tests fail In addition, management can view problem status at any time and can access reports showing quality statistics, such as time in queues, bugs reported per product, and outstanding bugs by developer These reports aren t included in this application, but could be developed from the problem database

Table 19-1 describes the database tables that contain all the data necessary to record and track problems

19:

A list of customers who have bought LyricNote products A list of products and their support personnel

customerID customer name phone productID product name product support person lead developer lead tester customerID productID date purchased problemID description severity (1=high, 2=medium, 3=low) date reported date resolved (if closed) customerID productID problemID timestamp eventID comments employeeID name other fields (not used here)

A list of customer/product pairs indicating which customer bought which product The main record of a reported problem

Table 19-1

JSP is a convenient development environment Pages get automatically compiled when necessary and URLs map easily to directory locations Inside a JSP page, you can use any mix of HTML and Java you like, which gives you a great deal of flexibility

Unfortunately, these same advantages mean ordinary JSP applications don t scale well As more Java code is embedded in JSP pages, keeping track of it becomes increasingly more difficult Unlike Java classes that can be compiled and unit tested, JSP scriptlet code cannot easily be separated from its container Being consistent over large stretches of Java-strewn HTML is also difficult You may start out using beans to do most of the work, and then find they don t do quite what you need, leading you to cheat with a little extra Java buried in the HTML These problems are compounded if the application makes free use of the <%@ include %> directive What s needed in larger applications is a better way to separate code into components with clear responsibilities For your product support system, you use the Model-View-Controller (MVC) design

The idea behind MVC is the visual aspects of a system should be isolated from the internal workings, which, in turn, should be separate from the mechanism that starts and controls the internals The MVC architecture was first prominently adopted by Smalltalk and its practitioners, but is now a widely used design pattern Figure 19-2 illustrates how MVC works The model refers to code that manages the abstract internal state and operations of the system It handles database access and most business logic The model has no visual component, providing instead an application programming interface that s accessible to other parts of the system This makes it possible to write a driver program that can test and debug the model from a simple command line interface

Figure 19-2