Modeling Web Applications with UML

jim conallen,
Principal Consultant
jim@conallen.com

Last Updated: 9-Mar-1999

Introduction

Web applications are becoming more and more popular. This is in part due to the rapid deployment of the tools and technologies for developing them. But mostly because system designers are recognizing the situations where web applications have very significant advantages over traditional applications.

To date the focus of web application development has been the tools. Little attention has been paid to the development process. Current development environments make it so easy to produce simple web applications that they have the unfortunate side effect of encouraging us to develop and evolve applications in the absence of serious analysis and design. Any system with non-trivial complexity needs to be designed and modeled. A primary goal of this paper is to stress the need for proper modeling. Unfortunately modeling web applications is not obvious.

Most of my experience with web applications comes from my use of Microsoft’s Active Server Page technology. I have made a very strong attempt to make the discussions in this paper as generic as possible, so that other technologies such as Allaire’s Cold Fusion could also be used. In addition web applications based on CGI scripts or ISAPI filters can still benefit from the modeling techniques described here.

This paper begins with a very brief explanation of web architecture. To keep it short, discussions of images, image maps and other primarily user interface features of web sites and applications have been omitted. The focus is on the ability of a web application to function as a software application, and the details of display and formatting are only of interest in those special cases where they directly effect the business logic. Also not addressed is use of external applications and MIME types.

Discussions in this paper assume working knowledge of UML, and some knowledge of web applications. The audience of this paper are developers and designers of web applications, and it is assumed that they are familiar with their own web application development environments.

Web Application Architecture

Web Sites

There is a subtle distinction between a web application and a web site. For the purpose of this paper a web application is a web site where user input (navigation through the site and data entry) effects the state of the business (beyond of course access logs and hit counters). In essence a web application uses a web site as the front end to a more typical application.

The architecture for a web site is rather straight forward. It contains three principal components; a web server, a network connection and one or more client browsers. The web server distributes pages of formatted information to clients that request it. The request is made over a network connection and uses the HTTP protocol. Figure 1 shows this relationship. Some web sites require clients to logon, and some allow anonymous access.

The information made available by a web site is typically stored, already formatted, in files. Clients request files by name, and when necessary provide specific path information with the request. These files are termed pages, and represent the content of a web site.

In some situations the content of a page is not necessarily stored inside the file. It can be assembled at runtime from information stored in a database (or other information repository) and formatting instructions in a file. Alternatively it can come from the output of a load-able module (CGI or ISAPI). The web server uses a page filter to interpret and execute the scripts in the page. Web sites employing this strategy are called dynamic sites.

Dynamic web sites offer certain advantages to web site designers. They make it easy to keep the content fresh and synchronized with data in a database. The overall look and feel of the web site is defined by a set of pages that contain code executed by the web server during a request for this page. In this context the file can either be an plain text file with scripts interpreted by the web server, or a compiled binary file that is executed by the web server. In either case the code in the "page" references and utilizes server resources which include databases, email services, file services, etc.

A user interacts with a web site via a browser. A browser is an application that runs on a client machine, that connects to a server on a network and requests a page of information. Once the page request has been fulfilled the connection terminates. The browser knows how to communicate (via HTTP) to a web server, and how to render formatted information returned by the web server. Most pages of information contain links to other pages (possibly on other servers), which the browser user may easily request. Users navigate the web by clicking on links and requesting pages from web servers.

Web Applications

The distinction between web sites and web applications is subtle, and relies on the ability of a user to effect the state of the business logic on the server. Certainly if no business logic exists on a server, the system should not be termed a web application. For those systems where the web server (or an application server that uses a web server for user input) allows business logic to be effected via web browsers, the system is considered a web application. For all but the simplest web applications the user needs to impart more than just navigational request information, typically web application users enter a varied range of input data. This data might be simple text, check box selections, or even binary and file information.

The distinction becomes even more subtle in the case of search engines, where users do enter in relatively sophisticated search criteria. Search engines that are web sites, simply accept this information, use it in some form of database SELECT statement and return the results. When the user finishes using the system there is no noticeable change in the state of the search engine (except of course in the usage logs and hit counters). This is contrasted with web applications that, for example accept on-line registration information. A web site that accepts course registration information from a user has a different state when the user finishes using the application.

The overall architecture of a web application is identical to that of a web site. It can however, become significantly more elaborate. The rest of this section will attempt to gradually build on the web site architecture to eventually reach that of a fairly complete and complex one. Given the history of this industry, this classification of fairly complete may not even last by the time this paper is completed. Regardless it will contain most of the concepts and components that are expected to be the cornerstones of web applications for the next several years.

Pages

By far the most fundamental component of a web application is the page. Browsers request pages (or conceptual pages) from servers. Web servers distribute pages of information to browsers. The makeup and organization of a web pages in essence make up the user interface for the application. In web applications the browser acts as a generalized user interface container with specific user interfaces being defined by each page’s content.

In web application development environments like Microsoft’s Active Server Pages or Allaire’s Cold Fusion, the pages are a combination of static HTML formatted pages, and dynamic scripted pages. The scripted pages contain code that is executed by the web server (actually it is more likely to be delegated to a scripting engine or page filter) that accesses server resources to ultimately build an HTML formatted page. The newly formatted page is sent back to the browser that requested it.

Server Scripting

It is important to note that the connection between the client and server only exists during a page request. Once the request is fulfilled the connection is broken. All activity on the server (as effected by the user) occurs during the page request. This represents a very significant distinction between traditional client server applications. Business logic on the server is only activated by the execution of scripts inside the pages requested by the browser.

Depending upon the specific scripting engine, scripted pages can contain user defined variables, sub routines and functions. Some scripting engines even permit the definition and interaction of objects.

The ultimate result of this server processing is to;

1. update the business state of the server, and
2. prepare an HTML formatted page (user interface) for the requesting browser.

An important and subtle part of web application design is understand and accommodating of this paradigm of client and server interaction. Business objects are not always accessible when handling individual user interface requests. For example a common user interface (and business feature) in many client server applications is the automatic population of city and state fields in a US postal address when a zip code is entered. Assuming that all three fields are located on the same page in a browser this feature would require an additional server page request to happen immediately after the zip code was entered. For most web applications this carries with it an unacceptable performance burden. For most web applications page requests are fulfilled in an order of seconds instead of milliseconds.

Client Scripting

The server is not the only component in a web application that executes scripts. The browser itself can execute scripted code in a page. When the browser executes a script, however, it does not have direct access to server resources. Typically scripts running on the client augment the user interface as opposed to defining and implementing core business logic.

Scripts on the client are appropriate for immediate data validation, or in assisting navigation. Often client scripts simply "jazz" up the user interface and provide little if any business logic behavior. This is changing however, as client side scripting becomes more powerful, and client side resource become more a part of the overall application.

Client scripts should not be confused with client side components such as Java Applets or ActiveX controls. These components are a separate category of component in the overall web application architecture and are discussed in more detail later. The client scripts discussed here are JavaScript (or VBScript) code embedded in the HTML formatted page. The code is executed in response to browser generated events (document loaded, button pressed, etc.). With the acceptance of the new Dynamic HTML specification, client scripts can access and control nearly every aspect of the page’s content. Additionally it further opens up access to the browser object model itself, enabling client side scripts to interact with other browser resources.

When an HTML web page is rendered in a browser it is first parsed and divided up into elements. When dynamic HTML is employed each of the elements can be named or assigned an ID, which could be referenced by client side scripts. Some common element types include anchors (links to other pages), tables, font specifications, etc. The elements making up the content of the page have an object interface defined by the Document Object Model (http://www.w3.org/DOM/). The browser also has an accessible interface, yet differing brands of browsers may have subtle differences.

Client scripts, like their server side counterparts, may contain variable declarations, sub routines and functions. The only major conceptual difference is server side scripts contained in a page are inherently procedural, while client side scripts are inherently event driven.

Forms

Any serious web application accepts more than navigation input from its users. Web applications often illicit textual, selectable and Boolean information. The most common mechanism for collecting this type of user input is with HTML forms.

An HTML form is a collection of input fields that are rendered in a web page. The basic input elements are; a textbox, text area, checkbox, radio button group, and selection list.

All the input elements on a form are identified by name or ID. Each form is associated with an action page. This action page represents the name (and location) of the page that is to receive and process the information contained in the completed form. The action page is almost always a dynamic page, containing server side scripts (or compiled code).

When a form is completed by a user the user submits the form back to the server with a page request for the action page. The web server finds the page and interprets (or executes) the page’s code. The code in the page has the ability to access any information in the form that was submitted with the request. This is the major mechanism for obtaining user input in a web application.

Components

Server

All business logic needn’t be interpreted from scripts in web pages. Larger and more enterprise savvy web applications make use of a third middle tier of components. This middle tier exist in between the user interface and the persistence system, and is typically a set of compiled components that run on an application server. The application server may execute on the same machine as the web server but does not necessarily have to. One of the advantages of an explicit third tier running on a server is the ability to share implementations of business functions across applications, web or not. Another is an encapsulation layer, for all business logic. A full description of the merits of three tiered architecture is beyond the scope of this paper.

When a compiled middle tier of business objects is present in the architecture the server scripts in the web pages, primarily act as the glue between the user interface and the business layer. Scripts executed on behalf of the web server have references to business objects, creating and invoking methods on them. It should be noted that as before, server side business logic is only executed on behalf of the user during page requests. The processing of a page request may result in a process or two to get executed on the server, and remain executing long after the client browser has shut down, but the process would be running in isolation from the client. Even when compiled business object components are used, the connection between the client and the server is closed once the requested page has been received by the browser.

The correct decision to use a third tier or not is dependent upon the specific application. Some points to consider include improved performance time with compiled business objects. Interpreted scripts execute slower than compiled code, and when performance is important, should be kept to a minimum. An advantage of server scripted business logic, however, is an easier ability to modify or enhance code, without taking down the application. Changes can be made to server scripted pages (within reason) without stopping the application. If the amount of business logic is relatively small, the absence of a full middle can be very appropriate.

Client

HTML formatted web pages may also specify components for execution on the client machine. The most common of these components are Java Applets, and ActiveX controls. Each are self contained compiled components that run at the request of the browser. Depending upon browser and component configuration they have access to browser and/or client machine resources.

Components on the client raise significant security concerns which are better addressed outside this paper. It should be sufficient to say that compiled components executing in the browser and on the client can make up a significant part of a web application’s architecture.

Client components are very useful in providing user interface functionality not readily achievable with standard form or HTML elements. A client component might be a display control that visualizes a three dimensional model. It might also represent a user interface control to specify dates with, one that pops up a miniature calendar from which dates can be clicked on. Some client components have no visual display, and might be used to retrieve client machine configuration information (a very touchy subject with the Internet community).

Frames

The user interface capabilities on the client can be enhanced with the use of frames. Frames and the ability to target browsers, enable the user interface designer to have multiple web pages active and open at the same time. The browser divides up its rectangular client window (where web pages are rendered) into distinct frames (or sub rectangles). Any web page can specify a frameset, and it is possible for a frameset to be embedded inside other framesets.

Scripts and components in any of these pages can interact with scripts and content in others. In HTML this is all managed by associating a target with each frame in a browser window. A proper discussion of the use of frames in user interface design is beyond the scope of these discussions, however the point must be made that the use of frames does constitute a major design decision in a web application, as it indicates that multiple pages are simultaneously available to the user.

Figure 3. shows a summary of the major architectural components discussed here. Two additional components; Application Dictionary and Session Dictionary were influenced by Microsoft’s implementation of Active Server Pages and offer a convenient mechanism to manage client side state on the server.

Other Components

A very effective and complex web application can be developed with the components mentioned previously. But nothing is good enough when technology is concerned. Some of the latest developments in the web application area still impact the architecture. Included in this are scriptlets and XML. Scriptlets are presently a Microsoft browser exclusive and therefore only an option when it can be guaranteed that all clients are using Internet Explorer 4.0 or later. The other, XML is also pushed by Microsoft, but is receiving an unusual amount of independent support.

A scriplet is a cached HTML page (with possible object references) on the client that is used by many pages in a web application. The obvious advantages are re-usability and lowered network traffic.

XML (eXtensible Markup Language) is subset of SGML (Standard Generalized Markup Language) and defines how related data can be transmitted across the web in a standardized way. Much like how HTML uses tags to describe the formatting in a web page, XML enables user defined tags to describe the meta-structure of data with the actual instance data as it is transmitted between server and client. Again this is not the proper place to discuss in detail XML, the most recent draft of the XML standard can be found on: http://www.w3.org/pub/WWW/TR/WD-xml.html. For the purposes of this paper XML defines a portable way to encode hierarchical data.

Modeling is important. It helps us manage complexity. Web applications can get complex rather quickly. A given system can be represented by many different, yet consistent models. Each model has a specific purpose and audience. This paper focuses on design models for web applications, and the audience is primarily the web architect and designer. It is important when modeling to capture the appropriate level of abstraction and to model the artifacts.

With these goals in mind the task of modeling web application design becomes not so clear. Given the assumption that the primary artifact of a web application is the web page, it should be obvious that the page should be modeled. But how? Using UML we can express a page as an object. This then brings up the question; what are the properties of such an object? Is it appropriate to express the layout elements (fonts, tables, text, etc.)? Should the scripts in a page be identified as methods of a page object?

The answer should come from the question; what is the model being used for, and who is the audience? In the case of a design model, the user interface formatting is irrelevant, and typically doesn’t effect the business logic in the system. Scripts, especially server side scripts, do effect the business behavior of the system (and in some systems represent the entirety of the system’s business logic!). Additionally it is not hard to visualize variables in a scripted page (those with page scope) as being attributes of a page object and the function in the page as being its methods. These are appropriate for a design model and for a web application designer.

This however, leads to another problem. Web pages can contain scripts for both the server machine as well as the client. Intermixing attributes and methods for server and client execution can be very confusing. Solving this problem involves using a relatively new feature in the modeling toolbox; extensions.

Modeling Extension

The designer’s of UML recognized that the language is not always perfect for every situation. There are times when the development process would be better served if additional information we captured, or different semantics were applied to certain modeling elements. UML has defined a mechanism to allow certain domains to extend the semantics of specific model elements. The extension mechanism allows the inclusion of new attributes, different semantics and additional constraints. When collected together as Tagged Values, Stereotypes and Constraints they form an Extension to UML. This paper presents an extension of UML for web application designs.

Part of the extension mechanism of UML is the ability to assign different icons to stereotyped classes. A list of prototype icons for the most common class stereotypes can be found as an appendix to this paper.

The problem of a web page having different scripts and variables executed on the server or on the client can be solved in one of two ways. The first would be to define the stereotypes; server method and client method. In a page object a method that executes on the server will be stereotyped as «server method» and functions that run on the client «client method». This solves the problem of distinguishing attributes and methods of a page object, however it is still confusing. A further complication arises later when associations are made to other components in the model. It is not clear that some of these relationships are valid only in the context of the server methods and attributes or on the client.

Page Stereotypes

A better way to model a page is with two separately stereotyped classes; server page and client page. Any given web page in a web application that has functionality on the server as well as client can be represented in the model as two separate classes, even though their implementation is in the same file (or component). In this situation a web page’s server methods and page scoped variables are all contained in a class in the model stereotyped «server page». This class’s methods represent the page’s server side script’s; sub routines and functions. Variables declared in the scripts that have page scope represents the class’s attributes. Client side scripts or user interface formatting are not part of a server page’s scope. A server page can have relationship’s to components that exist on the server. These might include the business objects in three tiered system’s or data access components. Components relative to the application’s design and operation on the server are represented side by side with the server page’s that use them.

Client pages are similarly represented on the diagram with classes stereotyped: «client page». Client page’s attributes are page scoped variables and functions that execute in the client browser. Client pages are associated with components that execute on the client, including Java Applets, ActiveX controls, and elements of the Document Object Model itself.

There is a fundamental relationship between the server and client stereotypes of a web page. A server page ultimately builds the resulting client page. This is a unidirectional relationship, since a completed HTML page has little access to the object interface of the building server page. The stereotype «builds» is applied to associations and is always drawn in the model as a unidirectional association from a server page to a client page (Figure 4.). It indicates which server page is responsible for building a given client page.

It is conceivable that a given server page might build two distinctly different client pages. So different in fact, that it would be better (clearer) to represent the result as two separate client pages in the model. The merits of such design decisions may be debated, however, the extension mechanism doesn’t prevent such constructs.

Another facility of some web application development technologies is the ability to redirect the processing requests to another «server page». This relationship can be expressed in the model with the «redirects» association stereotype. A design might identify a particular server page a gatekeeper page, that given certain input, redirects further processing (and consequently different returning user interfaces). Redirection is a very useful feature for re-use especially in non three tiered web applications. Figure 5 shows this relationship.

A fundamental and yet subtle relationship between client pages and server pages is in the implementation diagram. Components in the implementation diagram represent distributable pieces of the system. For these stereotypes it is the web page. A component in an implementation diagram (component view in Rational Rose) represents an actual file that is request-able by the web server, and which realizes at least one server page or client page. Figure 6. conceptually shows this relationship.

An additional relationship that may be of importance in web application design is the hyper link. Client pages often contain hyper links (anchors) to other web pages. These other web pages can be either server or client pages, since ultimately it is the component that is requested by the client browser. If the requested component realizes a server page (at most one) then the server page is processed in order to get a resulting client page to fulfill the browser’s request. If not the web server simply retrieves the requested component (file) and sends it back to the browser.

The stereotype: «links» is defined for associations between client pages and other pages (server or client). See Figure 7. The decision to model all the hyper links in client pages is really left to the designer, however, a good design should model all relevant hyper links to the functioning of the application. It may not be necessary to model hyperlinks to web pages outside the system, or to company home pages and the like. A «links» association may be a bi-directional association. A «links » relationship from a server page does not make sense. If the hyper link includes parameters, they are be modeled as link attributes off of the association, as shown in Figure 8.

Components

Components in the sense of interfaces available to objects in the web application like ActiveX controls and DLLs, Java Applets or executables are also given a stereotype in the web extension. Just with pages components are identified as being executed on the server machine or on the client machine. The stereotype’s «server component» and «client component» can be applied to classes in the design model to distinguish availability. Certainty a database access component on the server is not directly accessible by client scripts running in a browser. Stereotyping components (interfaces) in the design model helps to clarify the model.

Forms

Additional stereotypes are defined for separating and elaborating HTML Form usage. Forms in an HTML formatted page really represent a distinct part of the client page. Forms contain additional attributes that may not be appropriate in the context of the entire client page. It is also possible to have multiple forms in a single page, each targeting a different action page. This can be modeled by creating a new stereotyped class to represent a single HTML form; «form».

A form class has as attributes is field elements. Methods however do not apply to forms, as a method defines a dynamic behavior within the context of a single form. Methods in a client page have access to all attributes of forms contained within a page. The proper relationship between a client page and a form is containment. Client pages contain forms.

A form identifies a specific web page (almost always one with a server page stereotype) to accept and process data submitted with the form. A «submits» association stereotype represents the relationship between a form and the web page that processes it, see Figure 9. The association is bi-directional since the processing page has access to the form’s attributes, which are submitted when the association is realized during runtime.

Framesets

An additional user interface (and design element) available in web applications is the frame. If used in an application, it represents an ability to present multiple web pages at the same time. Typically these concurrent pages which are related together to represent a single user interface.

Frames are implemented in HTML by defining a frameset. A frameset specifies and optionally names separate frames in which web pages can be rendered. The implementation of a frameset is in an HTML page. To maintain compatibility with older non-frames capable browsers, a frameset web page usually contains formatting and informational content that is only seen on the older browsers. This leads us to model framesets as a client page, but a specialized one, and hence a new stereotype: «frameset». In a design model classes stereotyped frameset may have all the associations that a client page can have, with the understanding that these are only appropriate for older browsers.

More typically, framesets contain multiple client pages. Any client page can be contained by a frameset. Since a frameset is just a specialization of a client page, it too can be contained in a frameset!

Coordinating activity between pages in frames (or other windows) requires the ability to reference pages inside of frames. Target is the term used when a client page references another active web page or frame. Since targets represent a very different element from a frameset, and considering web pages can also reference targets that are in other opened browsers, another class stereotype is defined; «target». A target has no properties or attributes, it is merely a reference-able container for a client page. A frameset class can contain a target, or a target can exist independently (as in the case of a separate browser window).

The main advantage of pulling out target as a stereotype is that it can be shared and referenced by many client pages. Additionally since it has no meaningful attributes or methods its semantics are different from normal classes.

A final stereotype needs to be defined for associations that indicate that one client page is requesting a link to be loaded into a browser window other than itself. A «targeted link» stereotype is applied to associations between client pages and targets that they interact with. Parameters that are passed to the server with the targeted link can be identified with a UML link attribute. See Figure 10.

Other Stereotypes

At the present time the web extensions for UML are just being finalized for their initial release. Under consideration are the following class stereotypes;

One user interface feature of a web application not addressed yet is the ability of a client page to pop up a modal dialog box, to gather user input. Client scripts invoke this operation, and this is modeled with a directional association from a calling client page to another web page (server or client). The association is stereotyped «dialog», indicating that the client page calling the dialog is temporarily suspended until the called "dialog" page closes. Typically a client page calls a dialog page to get small amounts of user input that either don’t fit on the original client page or is so infrequently used that it isn’t worth the screen real estate to put there.

The last stereotype under consideration is «event» and is the only method stereotype of the extension. It applies to methods in a client page object that are handlers to browser generated events. These help the designer to visualize which behaviors in a client page can happen asynchronously.

Knowing the semantics of design models is certainly only part of the process of delivering quality software. Before concluding our discussions on modeling web application design I would like to offer a few words of advice regarding the steps to take when developing web application designs.

A web application is a specialized version of a client/server application. Many of the development activities appropriate for client/server application development also apply to web applications. The importance of requirements modeling can not be emphasized enough. Use Cases provide an excellent way to capture and model a systems requirements. Although not all requirements are present in use cases, they do provide an excellent mechanism for organizing specific functionality and especially user interaction.

A use case is a textual description of the interaction of the system and the user, in the language of the domain. How tightly coupled use cases are with user interfaces is yet another matter of great debate. It should be sufficient to say that an examination of a system’s use cases provides an excellent starting point to identify client pages in the application. For the first iteration of design it is a good idea to start off with one client page for each use case involving interaction between a human actor and the system.

Do not attempt to model server pages yet. Especially in three tiered systems, server pages are only the glue between client pages and server components. The next step is to model the business objects of the system. With the business objects modeled and the client pages identified, begin gluing them together with server pages. Most likely there will be one server page for each client page that contains business object data.

Like any realistic project there will be several rounds of iteration and possibly significant changes in the design. Using the extension presented earlier will help present to the designer and implementer a clearer picture of the actual web application design.

The major purpose of this paper is to present a mechanism to assist web application designers. With the assumptions that modeling is important, and we should modeling the artifacts of a system, it becomes obvious that web application designers must work with pages. Since UML is fundamentally object oriented, and web pages are inherently not a disconnect arises. The solution, as presented here, is to apply some new semantics to special model elements, to help bring out their hidden object oriented aspects.

As a final note, it has to be mentioned that the extensions presented here are still in development. For the most part they have been driven my recent experience developing web applications with the Microsoft set of technologies. Its hoped that the user community will help refine the extension and additional processes such that in the near future it can considered a reliable tool in the creation of web applications.

Comments and suggestions are very welcome and can be sent to jim@conallen.com.

Copyright 1998-1999 jim conallen, Conallen, Inc.
jim@conallen.com