Modeling Web Application Architectures with UML
1
Abstract
Web applications are becoming increasingly complex and mission critical. To help manage this complexity, they need to be
modeled. Unified Modeling Language (UML) is the standard language for modeling software intensive systems. When
attempting to model web applications with UML, it becomes apparent that some of its components don’t fit nicely into
standard UML modeling elements. In order to stick with one modeling notation for the entire system (web components and
traditional middle tier components), UML must be extended. This paper presents an extension to the UML, using its formal
extension mechanism. The extension is designed so that web-specific components can be integrated with the rest of the
system’s model, and to exhibit the proper level of abstraction and detail suitable for designers, implementers, and architects of
web applications.
Overview
A new term has entered the IT vocabulary in the past few years: Web Application. It seems like everyone involved with
business software systems has plans for building web applications, with many non-business related software efforts interested
as well. For many early adopters of this architecture the term web application, like the systems themselves, have evolved from
small successful web sites add-ons to robust n-tiered applications. It’s not uncommon for a web application to service tens of
thousands of simultaneous users, distributed all over the entire world. Architecting web applications is serious business.
When put to the test, the term web application has slightly different meanings to different people. Some believe a web
application is anything that uses Java; others consider web applications anything that uses a web server. The general
consensus is somewhere in between. For our purposes in this paper, we’ll loosely define a web application to be a web system
(web server, network, HTTP, browser) where user input (navigation and data input) affects the state of the business. This
definition attempts to establish that a web application is a software system with business state, and that its "front end" is in
large part delivered via a web system.
The general architecture of a web application is that of a client server system, with a few notable distinctions. One of the most
significant advantages of a web application is its deployment. Deploying a web application is usually a matter of setting up the
server side components on a network. No special software or configuration is required on the part of the client. Another
significant difference is the nature of client and server communication. A web application’s principal communication protocol
is HTTP, which is a connectionless protocol that was designed for robustness and fault tolerance instead of maximum
communication throughput. Communication between a client and server in a web application typically revolves around the
navigation of web pages, not direct communications between server side and client side objects. At one level of abstraction,
all messaging in a web application can be described as the request and reception of web page entities. Generally speaking, the
architecture of a web application is not that much different from that of a dynamic web site.
The differences between a web application and a web site, even from a dynamic one, involve its usage. Web applications
implement business logic, and its use changes the state of the business (as captured by system). This is important because it
defines the focus of the modeling effort. Web applications execute business logic and so the most important models of the
system focus on the business logic and business state, not on the presentation details. Presentation is important (otherwise the
system wouldn’t do anyone any good), however, you should strive for a clear separation between business and presentation
concerns. If presentation issues are important, or even complicated, then they too should be modeled, but not necessarily as an
integral part of the business logic model. Additionally the resources that work on presentation tend to be more artistic and less
concerned with the implementation of business rules.
One methodology/notation associated with the development of Web Systems is the Relationship Management Methodology
(RMM). RMM is a methodology for the design, construction, and maintenance of intranet and Internet web systems. Its
principal goal is to reduce the maintenance costs of dynamic, database-driven web sites. It advocates a visual representation of
the system to facilitate design discussions. It is an iterative process that includes the decomposition of the visual elements in
the web pages, and their association with database entities. RMM is a “soup to nuts” approach to the creation and
maintenance of dynamic web sites.
RMM falls short when building web applications. Web applications, being business logic centric, include a number of
technological mechanisms for implementing business logic that are not adequately covered by RMM notation. Such
technologies as client side scripting, applets, and ActiveX controls often make significant contributions to the execution of the
system’s business rules. Additionally web applications can be used as a delivery mechanism for a distributed object system.
Applets and ActiveX controls can contain components that asynchronously interact with server side components via RMI or