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

Client Page

HTML Form

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

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="…">Dynamic Page</a>

<a href="…">Physical Root</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>