January 01, 2001
Modeling Web-Tier ComponentsThe Web Application Extension is key to successfully modeling your complex Web-based system.
Many client/server developers, including myself, have recently made the transition to Web application development. We carry with us a respect for the development process, visual modeling, component architectures and iterative development, all of which we have used successfully in the past and want to apply today. When I joined my first Web application project, many of the things I had practiced before were still applicable. Use cases continued to be an excellent way to collect the functional requirements of the system, and the activities of use case analysis an excellent way to begin expressing the system in terms of objects. UML still proved itself a versatile notation for expressing the important parts of the system in the early phases of the project. However, things got a little confusing when it was time to express the detailed design of the system in the UML models. I understood Web architectures and had previously built systems on a much smaller scale, but this was this was first time I was part of a team building a "real" and nontrivial system, and the first time I needed to visually model one. The back end of the system, the transactional components and data tiers, were remarkably similar to other systems I had worked on. The presentation tier, however, was remarkably different. Instead of sophisticated forms running on a client machine, we had dynamically created Web pages. Instead of part of the client's system establishing a connection and managing a dialog with a server, the fundamental paradigm shifted to one where off-the-shelf software running on the client made numerous discrete requests for "resources" on the server. Additionally, it was only during the actual processing of the resource request on the server that any change in the business state was achieved. In the beginning, the resources were strictly HTML-formatted pages, but when XML was introduced, we began using that technology alongside HTML to help separate user interface formatting from the actual content. UML, out of the box, was just not suited to expressing the detailed design of these types of systems at the appropriate level of abstraction and detail for Web application designers. As a Web developer, I knew it was crucial to understand the Web pages and their client and server side scripts, the hyperlinks between them, and any associations to client or server tier objects that may contribute to the processing of the system's business logic. I also believed that the navigational structure (the paths taken through page resources to fulfill a use case scenario) was very important. I just didn't know how these things should best be represented in my UML models. The key to producing effective models is to model the right things. A model, as a simplification of something, is a view without the unnecessary details. Each model of a system expresses one viewpoint. To make a model really useful it needs to include those things that are important. In the case of Web modeling with UML there are really two models (that is, viewpoints) that are significantly influenced by this new architectural paradigm—the business logic design model and the user interface design model. In the business logic model, the viewpoint is focused on execution of the business logic in the system. It includes all of the classes and components that possess and manipulate the business state of the system. These might be the EJB or COM+ components and the scripted Web pages that use them and even the client side scripts that work manipulating the data and the hyperlinks that define the navigational paths in the system. The UI design model focuses on the mechanisms that contribute to just the user interface and the look and feel, not necessarily to the business logic content. This includes the client-side scripts that implement menus, pop-up help and, in general, those things that enhance the user interface without directly affecting the business state of the system. In most Web applications, the line is blurred between the user interface and business logic models. I try to distinguish between these two by examining their relationship to the business state. If an element or mechanism touches the business state in a direct way, then it belongs in the business logic model. If it deals primarily with UI issues, and could very likely be reused in a system in any other business domain, then it belongs in the UI model.
Web Application Extension (WAE) We begin with the concept of a Web page. A Web page is essentially something that a client browser requests, and it's identified in the system with a URL. The URL uniquely identifies a "resource" on a server. The Web server is responsible for delivering that resource back to the requesting client. Usually this resource comes back to the client as an HTML-formatted document that can easily be rendered by the browser (some systems send back XML documents that can be rendered with style sheets). All of these properties of the Web page concept neatly place it in the category of a component. A UML component, like a Web page, is a distributable part of the run-time system. Also, like a component, a Web page has dependences on other components (or Web pages).
The URL that a component represents exists in a namespace. That namespace begins with the server name, and is successively refined with a file system like "subdirectory" structure. The server is modeled in the UML with a <<virtual root>> stereotyped package (see Figure 1). (Stereotyped items in the UML can be rendered with custom icons. The WAE defines a number of stereotyped class, component and package icons.) All the Web page components of the system are in this package. Subpackages in this hierarchy represent the "subdirectories" in the URL pattern. Web pages come in two flavors: static and dynamic. Static pages do not perform any server-side processing before going to the client; however, they may execute some JavaScript, applets or controls on the client that contribute to the execution of the business logic in the system. Dynamic pages do execute logic on the server and are often the principal triggers for server-side business logic processing in the system. These pages often contain content that is dynamically generated and directly reflect the state of the business. In the UML model, these pages are represented with <<HTML page>> and <<Dynamic Page>> stereotyped components. In some situations, the dynamic page can be further refined into <<Active Server Page>>, <<Java Server Page>> or <<Servlet>>. In Figure 2, the static page Index has a dependency on the dynamic page Catalog. The dependency relationships in this view typically indicate hyperlinks or form submissions and represent a possible navigational flow.
Expressing Web page components in the UML is useful; however, it alone doesn't help us understand their business logic processing nature. The logical behavior of Web pages is best represented in another view of the model. In a detailed design model, the logical behaviors of the Web pages are expressed in terms of collaborations of classes. Class diagrams express the structure of the logical elements of the system, and interaction diagrams (activity, sequence, collaboration and state) express their behavior (usually with respect to the use cases defined for the system). The most difficult part of modeling Web pages with UML is representing the various life cycles and behaviors of a single "Web page." A dynamic page begins its life cycle by processing a client's page request. It interacts with server-side resources and eventually becomes an HTML-formatted stream, which is sent back to the client browser. This same conceptual Web page then begins the next phase of its life cycle as it's rendered in the client browser and receives processing cycles for its JavaScript functions and referenced applets and controls.
The answer lies in separating the disparate lives of the Web page into separate stereotyped classes. The WAE defines three fundamental class stereotypes and one association stereotype. A <<server page>> stereotyped class represents the server side aspect of a dynamic page, a <<client page>> stereotyped class represents a Web page as it is seen on the client (as an HTML document). An <<HTML Form>> stereotyped class represents an HTML form definition, which is completely contained within the context of a <<client page>>. Note that it's necessary to represent a form with a separate class, since any given <<client page>> (HTML) may contain multiple forms, each submitting themselves to different server side resources. An association stereotyped <<build>> connects a <<server page>>to the <<client page>> that is its output (see Figure 3). In this fundamental relationship, it is clear where the operations and attributes of server side scripting and component interaction belong and where client side scripting belongs. The strong form of containment is used to express the fact that the HTML form is completely contained within the context of a <<client page>>. In a J2EE application architecture, the attributes and operations of the <<server page>>class correspond to Java Server Page declarations (<%! … %>). In Active Server Page architectures these are the VBScript Subs and Functions, and any page scoped variable declarations (Dim statement) that run on the server. Most other architectural environments have similar concepts of page scoped variables and function definitions within a scripted Web page, and these generally map to the <<server page>>'s attributes and operations. Client-side scripts and variables map to the operations and attributes of a <<client page>>. These are typically JavaScript functions, but any variable or function declaration within a <SCRIPT> HTML element is mapped to the <<client page>>'s attributes and operations. HTML forms are modeled with their own stereotyped class <<HTML Form>>. This stereotype specifies that only the classes UML attribute compartment has meaning, and it may only contain the fields that the form specifies. Each field is specified with a name, and a type that corresponds to the common form field types in HTML (Text, Password, TextArea, Checkbox, Option, Select, Button, Image, FileUpload, Submit or Reset). The example in Listing 1 is a Java Server Page that builds a profile form and allows a user to update name and e-mail information. It contains both client and server side scripting, and the server side script makes use of a Java Bean to get existing profile information. The resulting HTML page contains a form element. The form submission is gated with some validation code to ensure that all the required fields have been filled out.
The class diagram that expresses the structure of this Java Server Page is shown in Figure 4. In this diagram, it's clear where each of the pages functions and associations logically reside. The My Profile class is a <<server page>> that defines three instance variables (lname, fname and email) that are visible anywhere in the page during server side processing. There is one function defined, intializePage() that when called sets the page's instance variables. The <jsp:usebean … > tag establishes an association to the PersonalInfoBean class. This class is a lightweight bean wrapper around an EJB session bean. Calling the load() function on this bean instantiates the session bean and makes the personal information available for the page to request. There are two defined JavaScript functions on the client side, which are used to validate the values of the HTML form before they are submitted to the <<server page>> Update Profile for processing. The class profileForm is the name of the form element in the HTML that contains four fields: lastName, firstName, email and Update. All but the submit button are <INPUT type="text" ... > fields. The Update field represents an input element with a type of "submit." For forms where there are a dynamic number of elements, or where the element names are common, array syntax notation is used. For example, a shopping cart with firm fields to allow the customer to change the quantities of any given line item might be expressed with a form attribute Qty[0..n] : Text.
The URL in the action parameter of the form element represents the server side resource that is expected to process the values in these form elements. The actual URL is derived, not from the class diagram alone, but rather by examining the component that realizes the Update Profile logical class. It is the component that maps to a URL, not the class. In this example, the component <<dynamic page>> updateProfile.jsp is the element in the model that maps to the relative URL updateProfile.jsp (see Figure 5). If relative URLs were not desired then the resulting URL would be www.myco.com/updateProfile.jsp. The server part here comes from a tagged value of the <<virtual root>> component package and the last part coming from the component itself. The page illustrated in Figure 5 redirects itself to a different page when an error results as a result of a missing profile ID. This architecturally significant information is expressed in the component view with a dependency from the myProfile component to the login component. In the logical view of the model, this is expressed with a stereotyped relationship between the My Profile class and the <<server page>> class that builds the login component (Figure 6). Of course the association could be made to either the <<server page>> Login or the <<client page>> Login HTML since both are realized by the same underlying page component. Drawing the association to the building component however makes the relationship clearer. Figure 7 is a class diagram of a simple catalog interface that might be found on an e-retail application. (The corresponding component diagram was shown in Figure 2, and unlike Figure 2, this diagram doesn't show class attributes or operations which would make the relationships easier to understand.) This diagram shows the principal classes involved to support standard browsing and searching functions of an online catalog. The association stereotype <<link>> identifies a hyperlink from a <<client page>> to another page in the system. Hyperlinks in HTML are typically made with the HTML anchor tag <A href="…">. The multiplicity of the role on the association from the Catalog class to the GetCategory class indicates 0..n. This means that the Catalog HTML page many have zero to many hyperlinks to the GetCategory <<server page>> , whose URL is derived from the component that realizes the GetCatalog class. This diagram also indicates a tagged value associated with this role (In Rational Rose, this is actually the role constraint). This tagged value represents the expected parameters that are appended to the URL request. In this case, however, it just specifies the parameter name, not its actual value, which is presumably computed at run time. If the component that realized the GetCategory class was called getcat.jsp and was owned by a package called catalog, which is itself owned by the <<virtual root>> package, then the resulting anchor tag could be generated as: <a href="http://www.mycom.com/catalog/ getcat.jsp?catid=XX">Where XX would be the run-time supplied value of the selected category. It's most likely that this hyperlink would be a result of small scriptlet or VBScript code:
<% for( int i=0; i<cats.length(); i++) {
cat = cats.item(i); %>
<a href="http://www.mycom.com/
catalog/getcat.jsp?catid=
<%=cat.getId()%>">
<%=cat.getName()%></a><br><% } %>
I've just touched the surface of the issues related to modeling the modern Web application and provided an introduction to the concepts and basic principals of Web application modeling. There are plenty of other interesting issues: framesets, JSP tag libraries, applets or controls, XML, storyboarding, scenarios and so on, that will have to be saved for another time.
Managing ComplexityModeling is an important step that architects, designers and implementators of Web applications can use to understand complex systems. For modeling to be effective, it must be done at the appropriate level of abstraction and detail, and most of the current modeling practices are perfectly valid for the early and middle stages of a Web applications development life cycle. Only when you begin to to model detailed designs of the Web tier components, does UML need the help that a formal UML profile like WAE provides.
| |||||||||||||||||||
