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 pageJSP, PHP, ASPwhich 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 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