Đề tài Buiding web applications with uml second edition

by the type tag value (type = { tag | directive }). «forward» Association A «forward» association is coded with the tag. «redirect» Association A «redirect» association is implemented by the sendRedirect(String location) operation on the HttpResponse object, which is available in the context of a JSP by the response variable. «JSP Tag» Class A «JSP Tag» in the model corresponds to a JSP custom tag (Figure A-47). The class defines a number of tag attributes and scripting variables. Attributes of the «JSP Tag» that are stereotyped are element attributes that can be specified in the opening tag. These attributes are captured in the tag library descriptor file with the following XML fragment: Entry app.glossary.taglib.EntryTag app.glossary.taglib.EntryTEI JSP Figure A-47. Sample «JSP Tag» class entryid true true convertLineBreaks false true Page 406 Tag values on the attributes indicate whether the attribute is required (required = { yes | no }). Scripting variable stereotyped attributes must be defined in a TagExtraInfo class, which is identified by a «tei» stereotyped dependency from the «JSP Tag». The TagExtraInfo class for the example in Figure A-47 follows. public class EntryTEI extends TagExtraInfo { public EntryTEI() { super(); } public VariableInfo[] getVariableInfo(TagData data) { return new VariableInfo[] { new VariableInfo("id", "String", true, VariableInfo.NESTED), new VariableInfo("term", "String", true, VariableInfo.NESTED), new VariableInfo("acronym", "String", true, VariableInfo.NESTED), new VariableInfo("longTerm", "String", true, VariableInfo.NESTED), new VariableInfo("description", "String", true, VariableInfo.NESTED), new VariableInfo("includesHTML", "String", true, VariableInfo.NESTED), new VariableInfo("lastmodified", "String", true, VariableInfo.NESTED) }; } } The «JSP Tag» implementing class is identified with a «tag» dependency. Its implementation must include certain operations (see the JSP specification for details). The class in this example follows, with operation bodies removed for clarity. Each specified attribute must provide a get and a set operation. Public class EntryTag extends BodyTagSupport { public String getConvertLineBreaks(){ } public void setConvertLineBreaks(String _convertLineBreaks ){} public String getEntryid() {} public void setEntryid(String _id ){} public void doInitBody() throws JspException {} public int doStartTag() throws JspException {} public int doEndTag() throws JspTagException {} public void release() {} } «JSP Tag Library» Package A JSP tag library (Figure A-48) maps to a .tld descriptor file. This file uses the «attribute» stereotyped attributes and the two dependency relationships to the implementing classes («tag» and «tei») to define most of the fields in this descriptor file. <!DOCTYPE taglib PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN" ""> Page 407 1.0 1.1 Entry app.glossary.taglib.EntryTag app.glossary.taglib.EntryTEI JSP entryid true true convertLineBreaks false true Figure A-48. Tag library package I l@ve RuBoard Page 408 I l@ve RuBoard Appendix B. The Number Store Reference Application Vision Background Requirements and Features Software Architecture Document Sample Screen Shots I l@ve RuBoard Page 409 I l@ve RuBoard Vision In most software development efforts, the vision document is created early to obtain funding. In this book, the need for this application was solely to provide a nontrivial example of the Web Application Extension (WAE) profile for UML for this second edition. The publisher and I are in essence the primary stakeholders, and it is to this audience that this document is oriented. Because the publisher and I are the primary stakeholders and are undertaking this vision document solely to produce supplementary material for the book, the vision does not contain much market analysis or cost/value comparisons. Rather, it contains a lot of the mental discussions I've had with myself about what type of application would be a good exemplar of a J2EE application, one that would be good candidate to show the most important aspects of the WAE. I l@ve RuBoard Page 410 I l@ve RuBoard Background Understanding and building sophisticated Web applications is difficult. One of the biggest overall issues facing development teams is managing complexity. With each succeeding generation, our applications are becoming increasingly large and complex. In addition, these applications are taking on more mission-critical roles. All this underscores the need for good tools and processes that will make our teams more efficient and result in a higher quality of work. A primary goal of the book is to demonstrate how teams can effectively leverage UML as a development tool for building Web applications, which in this context are software applications that manage business state and that have adopted a Web-centric presentation tier that relies heavily on standard Web technologies and standards, such as HTTP, HTML, Web browsers, and client-side scripting. The WAE focused primarily on the presentation tier of modern Web applications. As a result, most of the discussions center on the shape and the nature of this tier, leaving detailed discussions of other tiers—business logic, entity, data—to other books. All the UML elements are managed in one Rational Rose 2002 model file. The top-level package diagram is shown in Figure B-1. The full UML model is not included in this appendix but can be downloaded, along with all the source code for the application, from the Addison-Wesley Web site at www.awl.com/cseng. The model is available in Rational Rose 2002 format (.mdl file). Figure B-1. Top-level model and package summary Page 411 I l@ve RuBoard Page 412 I l@ve RuBoard Requirements and Features For this application to be an effective tool for understanding the WAE and Web application architectures in general, the following architecturally significant design elements must be included: l JSP and servlet classes l Client-side scripting l Specializations for certain browser versions l JavaBean use in JSPs To keep the focus on the modeling and architecture, a commonly understood domain, such as e-retail applications, should be used. Having to explain both the domain problem and the architecture would distract from the goal of seeing the modeling technique in action. Well-documented code and simplicity and understandability are favored over efficiency and performance. I l@ve RuBoard Page 413 I l@ve RuBoard Software Architecture Document The Number Store is a J2EE application that allows users to browse a catalog of numbers and select some for purchase. When a customer purchases a number, fictitious payment information is collected and processed. Real users are advised not to submit credit card information because anything that is provided will be accepted. In addition to browsing a catalog of numbers, a user can take a tutorial on adding fractions. The principal goal of the Number Store application is not to give its users functionality of value but rather to provide a J2EE exemplar application for demonstrating the Web Application Extension for UML (WAE). The WAE is a formal Unified Modeling Language (UML) profile that allows Web application development teams to use UML to model design-level abstractions of their Web applications. The vision document for this application outlines the overall goal and context that this application is being developed in and is treated as the originating requirements source. The meat of this application, however, can be found in this document. This abbreviated architecture document describes the underlying architecture of this application and relies on the use of the WAE. The intent is that this document, combined with the entire UML model, will serve as a sufficient example of the use and benefits of UML modeling. The architecture is expressed in terms of multiple views of the system. Each view represents certain aspects of the system under construction. This document contains the most architecturally significant elements across all development artifacts. As a result, the document may appear to be a summary of the entire collection of software development processes' artifacts. Requirements View The requirements for the Number Store application are drawn from the vision document. The vision document, of course, cannot contain all the application's requirements, which are contained in a full-size requirements document/database. In this section of the architecture document, only the significant architectural requirements (SARs) are expressed. These requirements directly lead to design decisions in the architecture. The nonfunctional requirements are not conveniently expressed in terms of dialogue scenarios between the system's users and the system. This simple application has few of these requirements. 1. Fundamental Architectural and Design Elements 1.1. Use both JSP and servlets to accept and build page requests. 1.2. The application will use servlets to accept incoming HTTP requests and JSPs to build outgoing HTML pages. 1.3. The JSPs will include other JSPs, as well as reference and use beans. 1.4. If possible, JSPs will use custom tag libraries. 1.5. The application will have at least one instance in which a targeted link is used. Page 414 1.6. The application will use common Web application design patterns. 1.6.1. Model View Controller pattern: Separate, discrete elements for managing the business state, building and presenting the user interface, and coordinating and controlling their activities. 1.6.2. Controlled Controllers pattern: Allowance for use and definition of multiple concurrent controllers in the application. 1.6.3. Paged List pattern: A way to present large lists of data to the user one page at a time. The user will scroll through pages of data one at a time to examine the list. This keeps the maximum page size and response time to a manageable level. 1.6.4. Shopping Cart pattern: A mechanism for application users to maintain references to items in the application throughout a session or a scenario. The items are selected for further processing, that is, purchase. 2. Domain 2.1. The application should mimic a common e-retail application. Its interface should be simple and not contain many specializations. In effect, the problem domain should almost be commonplace and invisible to the architecture. 2.2. The problem domain shall be a store that sells numbers. The products of this store are therefore numbers: integers, primes, squares, and so on. Using numbers as products should simplify the process of creating a sample inventory. 2.3. The product catalog should be divided into category groups. The initial release will contain categories for integers, primes, perfect squares, and miscellaneous. 2.3.1. The integer category will have products ranging from 1 to 499. 2.3.2. The primes category will contain the first 1,000 prime numbers. 2.3.3. The squares category will contain the first 20 perfect squares. 2.3.4. The special category will contain three values—PI, the natural log root, and the number 42, the ultimate answer to the universal question, whatever that might be. (This is a nod to the Hitchhiker's Guide to the Galaxy trilogy.) 2.4. Each product will be able to produce a value for its name, that is, a numerical value, a brief description, and a price. Page 415 2.5. Shopping 2.5.1. Users should be able to select and to purchase numbers. 2.5.2. The shopping cart should be accessible at all times and exhibit the standard behaviors for shopping carts. 2.5.3. The checkout process shall accept fictitious payment information and appear to process it. 2.5.4. Orders are to be confirmed to the user with an invoice. 2.6. Tutorials 2.6.1. A tutorial controller shall be added to the application, after the shopping and ordering functionality is completed, to demonstrate how controllers can be added without affecting (too much) the rest of the application design. 2.6.2. The tutorial will present a lesson on adding simple fractions. 2.6.3. The tutorial will leverage DHTML and will present a separate user interface to leverage the capabilities of one specific browser version. The browser version will be IE 3.0 or greater. This browser has a straightforward interface for doing dynamic text replacement in a Web page on the client. Other browser versions will see a non- DHTML-enabled page. 3. Runtime Environment 3.1. The application should be capable of running both the client and the server tiers on the same machine to facilitate examination and experimentation. The application can also be deployed on a separate node without design change. 3.2. The use of a formal entity and data tier should be minimized and eliminated, if possible. The focus of the modeling technique is on the presentation tier. The other tiers should be stubbed out when possible. 4. Performance 4.1. Page response times should be under 5 seconds for all pages during normal operation. 5. Security 5.1. There are no special security requirements or policies for this application. Page 416 Use Case View The Number Store has only three use cases, so all three are architecturally significant. Figure B- 2 shows the top-level use case view diagram for the application. Figure B-2. Use case model top-level diagram This application has a single actor: Number Customer. The customer is an anonymous Internet user who will browse the catalog and purchase items. Figures B-3 through B-6 outline the basic flows of the scenarios. Figure B-3. Shop for Numbers: basic flow Page 417 Figure B-6. Add Fraction Tutorial: basic flow Page 418 User Experience View The user experience (UX) model expresses the application from the viewpoint of screens of information and is very much a user interface model. The two class stereotypes for elements in the logical view are screen and form. A screen is a complete user interface presented to the user. A form is a user input element that accompanies requests to the server. In this model, the convention of using a dollar sign ($) indicates that the screen is accessible from most screens in the system: The screen is in a global scope. The plus sign (+) is appended to screen names that implement the paged list mechanism. These screens display a large list of items one "page" at a time. The dollar sign and the plus sign are simply notational conventions used in the context of this application and do not represent a defined modeling convention in the WAE or any other UML profile. Figure B-4. Order Numbers: basic flow Page 419 Figure B-7 shows the top-level UX model expressed as a class diagram and using the WAE stereotypes for screens and forms. In this diagram, the principal navigational routes through the system are expressed as associations between the screens. When form input is used—the user supplies data, not just hyperlink selection—the form is expressed as a stereotyped association class. Figure B-7. Top-level navigation map Page 420 Figure B-8 shows the same navigation map but with its details exposed. In this diagram, all the dynamic content is exposed. Figure B-8. Detailed view of navigation map Page 421 Figure B-5. Invalid Payment Information: alternative flow Page 422 Figure B-9 shows the main compartments defined in this application. Nearly every screen in the application uses these compartments. Figure B-9. Common compartments The UX model has additional elements and diagrams that are not shown here. For the most part, these additional elements do not, from a UX design point of view, represent anything architecturally significant that cannot be understood from the figures shown already. Figure B-10 shows a top-level summary of the storyboards defined in the application. Each storyboard, or UX realization, realizes a use case defined in the use case model. The sequence diagram for the Shop for Numbers storyboard is shown in Figures B-11 and B-12. The remaining storyboards can be found in the UML model. Figure B-10. Storyboards Page 423 Figure B-11. Shop for Numbers storyboard Page 424 Figure B-12. Part 2 of the Shop for Numbers storyboard Page 425 Design The top-level package diagram is shown in Figure B-13. This is a small application, one that is focused almost exclusively on the client and presentation tiers, so the model was not organized along tier boundaries but includes the elements for all tiers in the same packages. [1] [1] This is a departure from the recommended way to partition a design model according to the Rational Unified Process and Rational's general design guidelines. Figure B-13. Top-level design model packages Page 426 The Number Store recognizes four major architectural tiers: client, presentation, entity, and data. Only the client and the presentation tiers are implemented. Client Tier Most of the implementation in the client tier has already been accomplished with the use of standard Web browsers. The only custom client-tier code in this application is the JavaScript scripting in the fraction tutorial practice (Try It) page and the polynomial tutorial applet. Figure B-14 shows the Web page classes that implement the fraction tutorial client scripts. In this diagram, the TryItIE.html page is included only when an Internet Explorer browser is detected, because this particular set of scripting does not work in other browsers. For other Page 427 browsers, no client scripting is used, and the TryItOther.jsp is used to build the page. Figure B-14. Web page elements involved in the fraction tutorial Page 428 Figures B-13 and B-14 show the polynomial tutorial applet and the client page interactions. Presentation Tier The vast majority of the design and code in this application is in the presentation tier. This tier is responsible for responding to client requests and preparing suitable HTML responses. The principal components in this tier are the Web server and the JSP engine. In this implementation, Tomcat 3.2.3 is used. Tomcat is a reference implementation for the Java servlet 2.2 and JavaServer Page technologies. Each page request in this application is a request for a named screen. The screens are defined in the UX model. Figure B-15 shows the mappings from the Home screen and its compartments to the JSPs that are used to build that screen. The suffix .jsp is only a naming convention, used here to help distinguish between client and server pages, which often have similar names. Each screen in this application has mappings to the JSPs, or HTML pages, that are used to build it. The dependency from the screen to the server page uses the name to indicate which template parameter the JSP fulfills. In this figure, the home page is made up of a banner, a footer, and a content page. The JSPs that make up this screen are the dependent classes. Figure B-15. UX and design model mappings A fundamental part of this system's architecture is the mechanism it uses for accepting and processing incoming requests. This mechanism is derived from two common Web application architectural patterns: Controlled Controllers and Master Template, which are described in Appendixes C and D. Page Request Handling Page 429 The overall architecture for handling page requests in this application begins with a mapping in the web.xml file that redirects all incoming requests for pages with the .scr extension to an instance in the RequestProcessor class. The request processor is a servlet and, technically, a «server page» stereotyped class, although in this particular model, it is stereotyped «HttpServlet» as a result of the UML tool's code engineering engine. The request processor accepts all incoming requests and then instructs the appropriate controller to update the state of the business with the request, which contains not only the requested URL but also all incoming parameters and form input. Once the state has been updated, the processor checks to see whether another controller has been requested: a parameter on the URL. If a new controller has been requested, the processor checks with the active controller to see whether it requires exclusive control. If it doesn't, the new controller is made active, given the incoming request to update with, and placed on top of the active controller stack. A UseCaseCoordinator class is responsible for managing this stack. As a last step, the request processor asks the active controller for the next screen ID to redirect to. With this ID, control is passed, via a request dispatcher forward, to the ControlTemplate. The ControlTemplate, a JSP that provides a utility method for defining screen definitions, is responsible for setting in context any scriptlet values useful in the PresentationTemplate. The PresentationTemplate is the JSP that is the main template of the Master Template pattern. This JSP is responsible for formatting all outgoing pages consistently. It accesses the screen definition attributes and uses them as the template's parameters. Most of these parameters point to JSPs that are aggregated to produce one output screen. The PresentationTemplate uses five parameters: a header, a footer, content and menu JSPs, and one string value for the page name, used in the title element of the head element. Figure B- 16 shows principal classes and JSPs involved in processing all page requests. Figure B-16. Overview of page request class Page 430 The design model use case realizations show how each page request updates the active controller and then redirects the output page, building to a set of server page classes. The basic scenario for handling page requests is shown in the sequence diagram in Figure B-17. Figure B-17. Sequence diagram showing the basic page request–handling scenario Page 431 Figure B-18 shows some of the utility classes that participate in the page request scenarios. The RequestProcessor servlet is the main point of entry for all HTTP requests. It uses the UseCaseCoordinator object, held in the user's HttpSession object, to coordinate the controllers. The ScreenDefinition class is a small wrapper around definitions for screens, that is, composition of individual JSP pages. Figure B-18. Utility classes involved in page request handling Page 432 Defining Controllers The Number Store application is heavily dependent on discrete controllers for managing navigational flow and coordinating business logic execution. Figure B-19 shows the page classes that support shopping functionality. Figure B-20 shows the main Java classes that provide access to the business logic in the page, along with the ShopController class. Figure B-19. Main pages supporting shopping functionality Page 433 Figure B-20. Main Java classes supporting shopping functions Page 434 The ShopController is a special controller; it is the default controller for all users of the application and never expires, so it can always be found on the controller stack. All controllers in this application define a state machine. [2] The state machine for the shopping controller is shown in Figure B-21. The state machine can easily be seen reflected in the determineNextScreen() operations in each of the controllers. [2] It was the only way I could keep my sanity when developing the application. Until I started defining state machines for each controller, I found myself continually trying to correct boundary conditions in behavior. Page 435 Figure B-21. State diagram for shopping controller UX Mapping An example of the UX and design model mapping diagrams is shown for the Fraction Tutorial section of the application (Figure B-22). Figure B-22. Design and UX model mappings for Add Fraction tutorial Page 436 Entity Tier In a real Web application, business state is changed. This state usually corresponds to elements in a database. The entity tier is the layer on top of the database, responsible for all the business rules and logic in the system. This tier is in a J2EE application and is implemented with Enterprise JavaBeans (EJB). The EJB container(s) manage all the transactional logic in the system. For this reference application, however, EJBs are not used, since the purpose of this application is to show how to model presentation-tier components. For details on how to model EJBs, refer to the official Java specification for modeling Enterprise JavaBeans with UML (Java Specification Request, or JSR, 26). Instead, this application uses standard Java classes to implement the entity tier. Figure B-23 shows some of the entity classes that make up the catalog. Figure B-23. Entity-tier classes, implemented as standard Java classes Page 437 Data Tier The persistence part of the application is the data tier. In this application, all persistence is mimicked by classes in the presentation tier. The data tier provides persistence services to the entity tier. In some architectures, this tier might implement business logic—stored procedures— whereas in others, only integrity constraints are implemented. In this application, the data tier doesn't exist. Component View To accurately model the component view of this application, two separate but connected hierarchies in the model, identified by the package stereotypes «virtual root» and «physical root». The «virtual root» contains component elements that map directly to valid URLs that the system will respond to. Each component is stereotyped «HttpResource» and realizes the screen elements in the UX model. The «physical root» contains JSP and HTML stereotyped elements that map directly to JSP and HTML files in the development file system and, presumably, the relative runtime file system. Figure B-24 shows the top-level component view. Figure B-24. Top-level component diagram Page 438 Under the «virtual root» package, NumberStore Web, are components stereotyped «HttpResource». Each of these components represents a valid URL in the system that a client browser can request. All the components have a .scr extension, which is identified by the Web server container. All HTTP requests made for resources with this extension are forwarded to the RequestProcessor servlet. Figure B-25 shows the contents of the «virtual root» package in a hierarchy tree. Next to this tree are some contents of the «physical root» package. In this component package are «static page» and «dynamic page» stereotyped components—in this case, the JSP components are stereotyped «JSP». Also under this hierarchy is a component for the web.xml configuration file and some key image files. Figure B-25. Component hierarchies of the packages «virtual root» and «physical root» Page 439 Figure B-26 shows a component diagram in the «virtual root». In this diagram, all the screen definitions are organized by use cases. Figure B-26. Component diagram for the «virtual root» containing «HTTPResource» stereotyped component elements Page 440 Component realizations begin with «HTTPResource» components that realize screens in the UX model. «JSP» components in the «physical root» package realize «server page» and «client page» classes in the design model. The connection between which HTTP resources (URLs) are handled by which «JSP» components can be determined only by the UX and design model mappings. Using the mapping between the UX screen and the «server page» or «client page» logical class and then following the realization to the component will identify which JSP pages are used to respond to which requested URLs (Figure B-27). Figure B-27. Realizing components Page 441 This may seem overly complex—and in my opinion it is. However, this architecture does have advantages for extensibility and maintainability. The architecture imposes certain rules and regulations for expanding the application with new pages and controllers. Adhering to the rules will make application maintenance much easier than what might happen in an application without a formal control-driven architecture. I l@ve RuBoard Page 442 I l@ve RuBoard Sample Screen Shots Figures B-28 through B-33 are screen shots that show the kinds of things the user would view at some point in the Number Store application. Figure B-28. The house page for the Number Store application Figure B-29. The product details screen for the number PI Page 443 Figure B-30. The shopping cart screen Page 444 Figure B-31. The payment information screen Page 445 Figure B-32. The fraction tutorial's try it screen Page 446 Figure B-33. Debug information appears at the bottom of every screen of the application Page 447 I l@ve RuBoard Page 448 I l@ve RuBoard Appendix C. Controlled Controllers Pattern Use Case View Analysis Model Classes Analysis Model Collaborations I l@ve RuBoard Page 449 I l@ve RuBoard Use Case View The controlled controllers mechanism allows the application to be designed around multiple discrete presentation-tier controllers. Related to the Model View Controller (MVC) pattern, the controlled controllers mechanism is a manager of individual MVC controllers. Each controller represents a separate use case and is responsible for managing the dialogue between the user, or actor, and the system for all supported scenarios. The top-level use case model is shown in Figure C-1. The basic flow for accepting and managing a user page request is documented in the sequence diagram of Figure C-2. The sequence diagram for adding controllers to the stack is shown in Figure C-3. Figure C-4 shows how controllers are removed. Figure C-1. Top-level use case model Figure C-2. Basic flow scenario Page 450 Figure C-3. New controller scenario Page 451 Figure C-4. Remove Controller Page 452 I l@ve RuBoard Page 453 I l@ve RuBoard Analysis Model Classes Each controller is a single object—which may have many helper objects, if necessary—but all support a common interface. A key element in this mechanism is that the Web application server is configured to route all incoming requests through a single class: one object instance for each user session. This object is the RequestProcessor. At the heart of this mechanism is the coordinator, an object that manages all the active controller instances for a particular user. When a user begins using the application, the default controller is pressed into service and manages all the user page resource requests. A different controller can be requested to take control of the user session, by specifying it as a parameter in a URL hyperlink. This implies that at least some hyperlinks in the application will have knowledge of the other controllers that can be activated and used by the user. (A good example of this is a common menu HTML component whereby each hyperlink in it specifies the controller that manages that activity.) When it sees a request for a new controller, the coordinator first checks with the active controller to ensure that it doesn't require exclusive control—for example, in the middle of an important scenario that cannot be postponed. If it doesn't, the current controller is placed on a stack, and the new controller is made the current one. All subsequent page resource requests are managed by this controller until it is completed. When a controller is completed, the coordinator removes it from the active stack, and the next controller on the top is made the current active controller. (If there are none on the stack, a new instance of the default controller is created.) Figure C-5 shows an analysis-level diagram of the coordinator and its relations to the individual controllers. Figure C-5. Main analysis-level class diagram for mechanism Page 454 Each controller must be able to accept an incoming HTTP request for a page resource, process any parameters or field data, update the state of the business, and identify the next page resource to send to the requester. In some situations, the requested page resource cannot be returned to the user, and a different one is sent. For example, the user might submit payment information, and normal flow would be to the page that redisplays this information and prompts for confirmation. If the data was invalid, the requested page—payment confirmation—shouldn't be returned; rather, the payment information request page should be, with an informational message indicating the invalid information. The controller is responsible for processing the payment information and determining which of the two response pages should be sent back. Each response page may interact with the state of the business in order to get and to assemble the dynamic content in each page. It is also expected that each "page builder" can easily get a reference to the current active controller, which provides a convenient access point to the business state. Figure C-6 shows an analysis diagram of the controller and its relationship to Page 455 the individual page builders and page user interfaces. Figure C-6. Sample set of controllers I l@ve RuBoard Page 456 I l@ve RuBoard Analysis Model Collaborations The basic dynamic behavior of this mechanism is shown in Figure C-7. In this sequence diagram, the client browser requests a page resource. The RequestProcessor handles this request and delegates the processing of any input data—URL parameters or form data—to the current active controller. If this is the first page request, a new instance of the default controller is created and made currently active. The processor then requests the next page resource to load, execute, and send back to the client browser. Figure C-7. Basic flow use case realization The Figure C-8 sequence diagram shows how the request processor and the coordinator add a controller to the active stack. In this scenario, the request processor examines the incoming request for a parameter that indicates a new controller request. Before invoking the new controller, the request processor makes sure that the current controller doesn't require exclusive control. If it doesn't, the new controller is made current and active and given the input request for processing. The new controller now is the current active controller. Figure C-8. New Controller use case realization Page 457 In Figure C-9, the current controller indicates that it is finished and that the coordinator can remove it from being active. The next controller in the stack is now returned to active and current status and is given the input request, which it most likely will ignore, and asked which page to load and send to the client. The overall flow of this mechanism is shown in Figure C-10. Figure C-9. Remove Controller use case realization Page 458 Figure C-10. Activity diagram summarizing mechanism I l@ve RuBoard Page 459 I l@ve RuBoard Appendix D. Master Template Pattern Overview Use Case View Logical View I l@ve RuBoard Page 460 I l@ve RuBoard Overview The master template mechanism was influenced by the Java Pet Store 1.0.1 example documented in the Java BluePrints. In this mechanism, one page template (JSP) is used for all outgoing pages, thereby helping enforce a consistent user interface look-and-feel and providing a single source for updates. This mechanism is most useful for applications that can benefit from an explicitly controlled user interface template, one in which pages are expected to be added to the application. This mechanism does carry some performance penalties, so it should be examined in detail before being used in applications that are expected to scale quickly. I l@ve RuBoard Page 461 I l@ve RuBoard Use Case View The basic use case for page requests has only one scenario flow. Figure D-1 shows the top-level use case diagram for this mechanism. The basic flow scenario is shown in Figure D-2. Figure D-1. Use case diagram Figure D-2. Basic flow scenario I l@ve RuBoard Page 462 I l@ve RuBoard Logical View The class diagram in Figure D-3 shows the principal participants in this mechanism. The user screen represents any Web page rendered on the client. Each screen could be assembled from the output of many Web server "pages," or JSPs. Each page component may contain dynamic content and so may interact with the application server or middle-tier components of the application. The Web server is the main controller for this mechanism and the single point of entry for page requests. The Web server is most likely a commodity component, such as Tomcat, WebSphere, Web Logic, and IIS. Figure D-3. Main analysis class diagram The screen template is the single template used to assemble and to format all outgoing screens, or pages. Depending on which URL was requested, the template uses the URL as a key to the screen's dictionary. The screen definitions are a dictionary, or map, of possible screens. Each entry has a set of parameter values that are used by the template when assembling the outgoing screen. A screen component is one part of an outgoing page and is implemented by either a static HTML fragment file or a dynamic page—JSP, PHP, ASP—which produces HTML fragments with dynamic content. The parameters of the template are string identifiers of the individual page components. Typically, they point to files to include and contain HTML fragments or, in the case of dynamic components, contain JSP, PHP, or ASP code, which is processed before it returns the HTML fragments. Each parameter is named; this name is used by the template as a key to get the parameter value. For example, a template that defines a header, a footer, and the main body would have three defined parameters. The header and footer values might reference a standard HTML document that is intended to be used in every outgoing page, whereas the main body parameter would most likely reference a dynamic page that assembles the bulk of the application's presentation. For each incoming screen request, the Web server delegates the request to the single "master" template, which examines the request and uses it to determine which screen definition to use for the outgoing page. With the next screen identified, the template gets its parameters and Page 463 uses them to load and to process the page components individually. The result is sent to the requesting client browser. Figure D-4 shows the sequence diagram of this basic flow. Figure D-4. Use case realization for basic flow analysis model I l@ve RuBoard Page 464 I l@ve RuBoard Appendix E. Glossary Application Introduction Requirements and Use Case Model User Experience Model Design Model Component View Sample Screen Shots I l@ve RuBoard Page 465 I l@ve RuBoard Introduction In the first edition of this book, a simple Active Server Page sample application was created to demonstrate the UML artifacts that were created. This is the second, J2EE version of that application. For the most part, the functionality of the application remains the same; however, one new feature was added: versioning. This feature allows users to examine the history of changes to any glossary entry. I l@ve RuBoard Page 466 I l@ve RuBoard Requirements and Use Case Model The overall goal and vision for this application is to demonstrate, in the context of a simple and functional application, a technique for modeling Web applications with UML. Because the WAE is applicable for only client- and presentation-tier elements, most of the effort in this application can be found in these two tiers. The entity and data tiers, although functional, are not the focus of the development efforts and are not very interesting. A new requirement for this second version of the Glossary application is to include an example of a «client script object». An excellent example of a well-engineered JavaScript object is the Menu object designed by Gary Smith of Netscape. This object was included in this application without modification and shows how you can build objects in JavaScript. Another requirement is to allow HTML formatting in entry definitions. The application, however, must not require users to know or to understand HTML, so the use of HTML-encoded descriptions should be optional. This application has only two simple use cases: Browse Entries and Edit Entry. The top-level model is shown in Figure E-1. The Edit Entry use case extends the normal browsing of the Glossary application by allowing an entry to be edited only in context, which, of course, means that it must be browsed to first. Figure E-1. Glossary use cases The basic flow scenarios for the two use cases are shown in Figures E-2 and E-3. Figure E-2. Browse Entries basic flow Page 467 Figure E-3. Edit Entry basic flow Page 468 I l@ve RuBoard Page 469 I l@ve RuBoard User Experience Model The top-level diagram of the UX model for the Glossary application is shown in Figure E-4, which shows definitions for five screens. Two of the screens contain input forms. One complex- content-type class, Entry, is identified in this diagram. Entry is the key entity in the system; indeed, Entry is the only entity of this application. Figure E-4. Top-level navigation map The two storyboards for this application are expressed in the sequence diagrams of Figures E-5 and E-6. Page 470 Figure E-5. Browse Entries storyboard Figure E-6. Edit Entry storyboard I l@ve RuBoard Page 471 I l@ve RuBoard Design Model The design model contains an expression of the logical structure and behavior of the application's main objects. At the highest level, the design model is partitioned into architectural tiers (i.e., client, presentation, business, and data). Client Tier The client tier is limited to the objects and collaborations that execute in the client browser. Each Web page in this application contains a pop-up menu implemented with JavaScript. The menu is modeled by the «client script object» menu. Most pages define two instances of the menu: one main menu (actionMenu) and one submenu (browseMenu). The Menu class contains member variables of type Array, shown in Figure E-7 as associations to the JavaScript Array object. The complete JavaScript 1.3 object model is included in this application's model as a reference. Figure E-7. Use of menu «client script object» Menu class Page 472 Presentation Tier The majority of the work in this application is in the presentation tier. In this application, the navigational control is left to the individual pages; there is no single controller, as might be found in MVC-based applications. This application uses custom JSP tags extensively. The tag library is modeled as a «tag library» stereotyped subsystem and is seen in Figure E-8 modeled by the Entry Tags subsystem. In this diagram, the server pages index.jsp and listing.jsp both use the library. Figure E-8. Web pages involved in Browse use case The Entry Tags library contains three tag definitions: EntryList, EntryLoop, and Entry. Figure E-9 shows the «JSPTag» stereotyped elements with stereotyped dependencies to their implementation classes. Each tag defined here also defines several scripting variables that can be used in the tag body. These variables are modeled as «scripting variable» stereotyped attributes. The other attributes of the «JSPTag» elements are the tag attributes, the legal attributes that can be specified when using a JSP custom tag. For example, in the following code fragment, the Entry tag specifies the entryid and convertLineBreaks tag attributes and uses the term and description scripting variables in the body's tag. A detailed view of the classes that make up the tag implementation classes is shown in Figure E-10. The TEI classes are required for all tags that define scripting variables. Page 473 Figure E-9. JSP tag definitions Page 474 Figure E-10. Entry Tag's implementing classes The JSP interacts with the entity tier through the tag implementation classes. All communication to the entity-tier components is via the custom tags (Figure E-11). This allows the JSP source to have a minimal amount of Java code and instead contain mostly HTML or HTML-like code. Figure E-11. EntryListTag interacting with entity-tier objects Page 475 The EntryList tag is required in every JSP that uses the tags and must be a parent tag to the other two tags: EntryLoop and Entry. The EntryList tag is responsible for connecting to the Glossary entries, which are then made available by the other two tags. The EntryLoop tag is used to get entry values that are part of a list, as would be the case when browsing. The Entry tag is used when only one entry is required, as is the case in the entry view and editing pages. The tags are also responsible for ensuring that the encodings of the entity values are appropriate for HTML. This means that string values in entry attributes should convert less-than and greater-than characters to the appropriate HTML: < and >. Entity Tier The entity tier in this application has only one true entity—Entry—and one entity manager— Page 476 Glossary. An additional class acts as a wrapper for an entry query. This class combines all the search criteria information and makes it easier to cache and to pass along to the Glossary. An instance of this class is cached in the user's session (HttpSession) in the presentation tier. The interfaces for the main entity-tier classes are shown in Figure E-12, and the classes that implement them are shown in Figure E-13. Figure E-12. Key entity-tier interfaces Figure E-13. Main entity classes Page 477 Data Tier The logical data model is very simple and was intended to use only a minimal number of database features, in order to be portable across many relational databases. In this reference application, the mySQL database was used, but this application has also been successfully used with SQL Server, Oracle 8, and even MS Access. The only real requirement is to support standard SQL and to have a JDBC (Java Database Connectivity)-compliant driver. Figure E-14 shows the database diagram, which contains two tables: PK and Entry. The PK table is simple and is used for primary key creation. One column in this table contains the name of another database table—in this case, there is only one row for the Entry table. The other column is an integer-type column that keeps the value of the next primary key for the table. To get a new primary key, the application must lock the row, get its value, increment it by 1, and then unlock the row. Figure E-14. Logical data model diagram Page 478 The Entry table contains all the attributes of the glossary entry. Versions are managed by a self- referential foreign key (FK). When this FK is null, the entry row is considered to be the current version. When this row is updated, the columns in the row are not updated; rather, another row is inserted into the database, and the FK of the original row is set to the new row. This simple mechanism for versioning database rows works well enough for an application like this, with an expected low volume of use. I l@ve RuBoard Page 479 I l@ve RuBoard Component View The top-level package view of the application's component is shown in Figure E-15. In this diagram, the «virtual root»/glossary defines the application's URL hierarchy, and the «physical root» Glossary defines the physical location of all JSP files that are requestable by the browsers. This diagram shows the component package hierarchy for the additional Java classes (app.glossary.taglib) and two reference Java packages that are part of the JDK and J2EE specifications. Figure E-15. Top-level packages in the component view Some of the requestable URLs are implemented with servlets instead of JSPs. Because the Page 480 physical location of servlets is bound to their package hierarchies in the component view, «HTTPResource» elements are created to map these servlets into the URL space under the virtual root (Figure E-16). Figure E-16. «HTTPResources» elements mapped to the system's servlets The components under the physical root (Figure E-17) make up the rest of the requestable HTTP resources. These components are modeled with «JSP» components, with one «static page» and one «script library» component. Figure E-17. «JSP» components in the «physical root» Page 481 I l@ve RuBoard Page 482 I l@ve RuBoard Sample Screen Shots Figures E-18 through E-22 are screen shots the user would view at different points in the Glossary application. Figure E-18. The Glossary home page, showing a message of the most recent user activity and the most recent definition changes Figure E-19. The pop-up menu, available by clicking the top banner Page 483 Figure E-20. The Entry details screen Page 484 Figure E-21. Edit Entry screen Page 485 Figure E-22. An Entry History screen, showing version history Page 486 I l@ve RuBoard Page 487 I l@ve RuBoard [SYMBOL] [O] I l@ve RuBoard Page 488 I l@ve RuBoard [SYMBOL] [O] _Hlt14251805 _Hlt503173336 I l@ve RuBoard Page 489 I l@ve RuBoard [SYMBOL] [O] OLE_LINK3 I l@ve RuBoard Page 490