Web Application Extension for UML

The Web Application Extension (WAE) to UML enables us to represent Web pages and other architecturally significant elements in the model alongside the "normal" classes of the model. Only by doing this can we accurately express the entirety of the system in a model and maintain its traceability and integrity.

An extension to UML is expressed in terms of stereotypes, tagged values, and constraints. Combined, these mechanisms enable us to extend the notation of UML, enabling us to create new types of building blocks that we can use in the model.

• Stereotype, an extension to the vocabulary of the language, allows us to attach a new semantic meaning to a model element. Stereotypes can be applied to nearly every model element and are usually represented as a string between a pair of guillemets: « ». However, they can also be rendered by a new icon.
• Tagged value, an extension to a property of a model element, is the definition of a new property that can be associated with a model element. Most model elements have properties associated with them. Classes, for instance, have names, visibility, persistence, and other attributes associated with them. A tagged value is rendered on a diagram as a string enclosed by brackets.
• Constraint, an extension to the semantics of the language, specifies the conditions under which the model can be considered well formed. A constraint is a rule that defines how the model can be put together. Constraints are rendered as strings between a pair of braces: { }.

A UML extension begins with a brief description, then lists and describes all the stereotypes, tagged values, and constraints of the extension. In addition to these elements, an extension contains a set of well-formedness rules. These rules are used to determine whether a mode is semantically consistent with itself. Appendix A contains the full specification for the extension. It also defines association types (Table 11-1).

Logical View

The logical view of a UML model consists mostly of classes, their relationships, and their collaborations. Some stereotyped classes define multiple icons. For practical reasons, the decoration icon is more manageable for modeling tools like Rose. The hand-drawn version simply shows that it is practical for hand drawings on whiteboards, cocktail napkins, and so on. The WAE defines three core class stereotypes and various association stereotypes.

Server Page

Metamodel class	Class.
Description	A server page represents a dynamic Web page that contains content assembled on the server each time it is requested. Typically, a server page contains scripts that are executed by the server that interacts with server-side resources: databases, business logic components, external systems, and so on. The object's operations represent the functions in the script, and its attributes represent the variables that are visible in the page's scope, accessible by all functions in the page.
Icon(s)
Constraints	Server pages can have only normal relationships with objects on the server.
Tagged values	None.

Client Page

Metamodel class	Class.
Description	A client page instance is an HTML-formatted Web page with a mix of data, presentation, and even logic. Client pages are rendered by client browsers and may contain scripts that are interpreted by the browser. Client page functions map to functions in tags in the page. Client page attributes map to variables declared in the page's script tags that are accessible by any function in the page, or page scoped. Client pages can have associations with other client or server pages.
Icon(s)
Constraints	None.
Tagged values	TitleTag, the title of the page as displayed by the browser. BaseTag, the base URL for dereferencing relative URLs. BodyTag, the set of attributes for the tag, which sets background and default text attributes.

HTML Form

Metamodel class	Class.
Description	A class stereotyped as a «form» is a collection of input fields that are part of a client page. This class maps directly to the HTML tag. Its attributes represent the HTML form's input fields: input boxes, text areas, radio buttons, check boxes, and hidden fields. A «form» has no operations, as they can't be encapsulated in a form. Any operations that interact with the form would be the property of the page that contains the form.
Icon(s)
Constraints	None.
Tagged values	Either GET or POST: the method used to submit data to the action URL.

With these stereotypes in the logical view, we can model the basic architecture of page-based Web applications. In Figure 11-3, we see the fundamental relationships among the stereotyped classes. All the classes in this figure are implemented with a single component: an ASP or a JSP file. The «server page» class models the page's structure on the server. When the page component is requested, the Web server loads the file for the page and executes its server-side functions. This process produces an output stream, usually encoded in HTML,[3] which is then accepted by the client Web browser, which renders it. If the HTML includes client-side scriptingJavaScriptand the browser is configured to run scripts, the functions defined in the client page are invoked. Usually, the functions in an HTML page are event handlers and are fired in response to user gestures. However, some events, such as page loading, supply the necessary events to execute them.

[3] Server pages can stream output in any format: XML, WML (Wireless Markup Language), image, audio, and so on.

Figure 11-3. Basic relationships among WAE stereotyped elements

Table 11-1. Association Stereotypes

Stereotype	Description
«link»	A relationship between a client page and a server-side resource, or Web page. The target may be a client page class or a server page class. A «link» association is an abstraction of the HTML anchor element, when the href attribute is defined in it. One important tagged value is defined for this stereotyped association: parameters. This value contains parameters passed along with the HTTP request. This tag value is formatted as a string and may contain implementation-specific encodings.
«build»	A directional relationship between a server page and a client page. This relationship identifies the HTML output of a server page's execution.
«submit»	A directional relationship between an «HTML form» and a server page. Similar to a «link» relationship, it references a server-side resource. However, when the resource is requested from the server, all the form's field attributes are submitted, along with the request where they are processed.
«redirect»	A directional relationship between a client page or a server page and another page. This association indicates a command to the client to request another resource.
«forward»	A directional relationship between one server page and another server page or a client page. This association represents the delegation of processing a client's request for a resource to another server-side page.
«object»	A containment relationship drawn from a client page to another logical class, typically one that represents an applet, ActiveX control, or other embeddable component. This association abstracts the HTML and elements.
«include»	A directional association from a «server page» to another «server page» or «client page» class. During page assembly at runtime, this association indicates that the included page gets processed, if dynamic, and that its contents or by-products are used by the parent.

One point to note, however, is that it is entirely legal to include scripting statements in line with the HTML, outside a function definition. Although many consider this bad form, it is legal and sometimes useful. These statements are not captured in the model. In fact, discrete statements are normally not captured in a structural class diagram, anyway. If they are architecturally important, the best way to model in-line scripts is with a behavioral diagram associated with class.

When modeling server pages, the goal of the abstraction is to reify the server-side scripts in the page. In most scripted Web page environments, when a page is processed, any code contained in it is immediately executed, and the page is more of a single function call than an object. So when designing server page classes, it needs to be understood that the attributes are simply variables that are accessible anywhere in the scope of the page, just like class member variables. Operations of the page should be thought of as strictly private helper functions; since they are almost all architectural, they are never called directly by objects outside of the page.

The «HTML form» stereotyped class is modeled as a contained class of the client page. The reason is that an HTML form cannot exist outside the context of an HTML page. It is an abstraction for just the HTML tag, not for an entire page. Because it is legal for an HTML-formatted page to contain multiple forms, it is also allowed in the model (see Figure 11-4). Each form could submit its data to a different server page class.

Figure 11-4. Multiple forms in client pages

In Figure 11-5, two client page classes are associated with a «link» stereotyped association. This association maps directly to the HTML anchor tag (<a href="…">) when the href attribute is supplied.[4] An important tag value on «link» associations is the parameters tag, which contains the extra information supplied with the hyperlink request, HTTP parameters. This value is formatted in a way that is often implementation specific. For example in Figure 11-6, the link to the server page FeaturedProduct specifies a single parameter: productId. The value of this parameter is <%=id%>, which in ASP and JSP notation, indicates a replaceable data value. When the page is executed, its real value will be substituted; if you were to look at the anchor tag href parameter, you would see a real value in its place.</a>

<a href="…">[4] Anchor tags do not require href attributes and when not specified are used primarily as an internal bookmark, or identifier.</a>

<a href="…">Figure 11-5. Simple client page «link» associations</a>

<a href="…"></a>

<a href="…">Figure 11-6. Stereotyped «link» associations originating from client pages</a>

<a href="…"></a>

<a href="…">Link stereotyped associations must originate from a client page and may point to either a server page or a client page class. The convention is that if a client page is dynamicbuilt by a server pagethe «link» association should point toward the server page, not the client page. If the client page does not have dynamic contentis a static file, not processed by the serverthe link should and can only point to the client page class.</a>

<a href="…">When multiple server page components implement a single screen, as would be the case for UX models that define compartments, the «link» association may, optionally, go to a «screen» stereotyped class. This «screen» class can be the UX screen element defined in the UX model, or a fresh proxy for the screen can be created in the design model. Figure 11-7 shows a class diagram with «link» associations pointing to «screen» elements in the model.</a>

<a href="…">Figure 11-7. The «link» associations pointing to «screen» elements when screens are compartmentalized</a>

<a href="…"></a>

<a href="…">Component View</a>

<a href="…">The component view of a UML model is concerned with distributable files that make up the runtime system. The WAE defines two component stereotypes. These stereotypes are essentially abstract, since it is expected that they would be replaced with language-dependent stereotyped components (e.g., «JSP», «ASPX», «ASCX», «XML», etc.). These language-specific components would have additional constraints particular to their language and environment. Since they are closely related to round-trip engineering, these stereotypes are best defined by the tool vendors. The two stereotypes «static page» and «dynamic page» are sufficient to capture the level of abstraction necessary to understand the major architecturally significant properties of page components.</a>

<a href="…">Static Page</a>

<a href="…">Metamodel class</a>	<a href="…">Component.</a>
<a href="…">Description</a>	<a href="…">A resource that can be directly requested by a client browser. A static page performs no server-side execute and is delivered directly from the file system to the client intact.</a>
<a href="…">Icon</a>	<a href="…"></a>
<a href="…">Constraints</a>	<a href="…">Cannot realize logical components that execute on the server, that is, server pages. Static pages can realize only client pages.</a>
<a href="…">Tagged values</a>	<a href="…">None</a>

<a href="…">Dynamic Page</a>

<a href="…">Metamodel class</a>	<a href="…">Component.</a>
<a href="…">Description</a>	<a href="…">A resource that can be requested by a client browser. When requested or delegated to via a «forward» relationship, server-side processing takes place. The results of this processing can change the state of the server and be used to construct some of the HTML that is streamed out to the requesting client. Dynamic pages can accept user input submitted by forms.</a>
<a href="…">Icon</a>	<a href="…"></a>
<a href="…">Constraints</a>	<a href="…">Must realize a single server page.</a>
<a href="…">Tagged values</a>	<a href="…">None.</a>

<a href="…">Physical Root</a>

<a href="…">Metamodel class</a>	<a href="…">Component package.</a>
<a href="…">Description</a>	<a href="…">An abstraction of a file hierarchy that contains requestable resources. Clients request static or dynamic files directly from this hierarchy. A «physical root» package maps directly to a Web server file system directory. Tag values in this element identify the host name and the application context, which are necessary for resolving a component under this directory into a valid URL.</a>
<a href="…">Icon</a>	<a href="…"></a>
<a href="…">Constraints</a>	<a href="…">None.</a>
<a href="…">Tagged values</a>	<a href="…">Host name, the name of the host of the Web server, such as www.mycompany.com.</a> <a href="…">Context, the application context. The context appears as a top-level directory, such as www.myco.com/appcontext.</a>

<a href="…">In the component view, the main responsibility of the model is to provide mappings between the physical files of the runtime system and the logical representations in the logical view. Figure 11-8 shows the Page.jsp component realizing logical-view classes. A single JSP is responsible for the server-side processing associated with the «server page» class and its expected HTML output: client page and form. Although technically, all three classes in this diagram are realized by the Page.jsp component, it is usually sufficient for the component to realize the server page class, since the «build» and containment relationships in the logical model are sufficient to indicate that all three realizations can be found in the component.</a>

<a href="…">Figure 11-8. Logical-view classes realized by dynamic page component</a>

<a href="…"></a>

<a href="…">In Figure 11-9, the «static page» component realizes a client page. Static components cannot realize server pages or any logical components that are processed on the server. Static components are delivered to the client without server-side processing.</a>

<a href="…">Figure 11-9. Client pages realized by static page components</a>

<a href="…"></a>

<a href="…"> </a>

<a href="…">Designing Web Applications</a>