Conallen.pdf

Pages, hyperlinks, and dynamic content on theclient and server are what need to be modeled.. Any page scopedvariables in the scripts would map to class attributes.A problem arises when o

When put to the test, the term Web applicationhas slightly different meanings to different people.Some believe a Web application is anything thatuses Java, others consider a Web application any-thing that uses a Web server The general consensusis somewhere in between In this article, a Webapplication will be loosely defined as a Web system

(Web server, network, HTTP, browser) in whichuser input (navigation and data input) effects thestate of the business This definition attempts toestablish that a Web application is a software sys-tem with business state, and that its front end is inlarge part delivered via a Web system

The general architecture of a Web application is

A new term has entered

the IT vocabulary in the past few years: Webapplication It seems like everyone involved withbusiness software systems has plans for buildingWeb applications, with many nonbusiness soft-ware efforts as well For many early adopters ofthis architecture the term Web application, like the systems themselves, have evolved fromsmall successful Web site add-ons to robust n-tiered applications It’s not uncommon for aWeb application to service tens of thousands of simultaneous users, distributed all over theworld Designing Web applications is serious business.

that of a client/server system, with a few notable tinctions One of the most significant advantages of aWeb application is its deployment Deploying a Webapplication is usually a matter of setting up the serverside components on a network No special software orconfiguration is required on the part of the client.1

dis-Another significant difference between a Web cation and a client/server system is the nature of clientand server communication A Web application’s prin-cipal communication protocol is HTTP, which is aconnectionless protocol designed for robustness andfault tolerance instead of maximum communicationthroughput Communication between a client andserver in a Web application typically revolves aroundthe navigation of Web pages, not direct communica-tions between server side and client side objects Atone level of abstraction, all messaging in a Web appli-cation can be described as the request and receptionof Web page entities Generally speaking, the archi-tecture of a Web application is not much differentfrom that of a dynamic Web site

appli-The differences between a Web application and aWeb site involve its usage Web applications imple-ment business logic, and its use changes the state of thebusiness (as captured by the system) This is importantbecause it defines the focus of the modeling effort Webapplications execute business logic and so the mostimportant models of the system focus on the businesslogic and business state, not on presentation details.Presentation is important (otherwise the system would-n’t do anyone any good), however, a clear separationbetween business and presentation concerns should bestrived for If presentation issues are important, or evencomplicated, then they too should be modeled, but notnecessarily as an integral part of the business logicmodel Additionally the resources that work on presen-tation tend to be more artistic, and less concerned withthe implementation of business rules

One methodology or notation associated with thedevelopment of Web Systems is the RelationshipManagement Methodology (RMM) [2] RMM is amethodology for the design, construction and main-tenance of intranet and Internet Web systems Itsprincipal goal is to reduce the maintenance costs ofdynamic database-driven Web sites It advocates avisual representation of the system to facilitate designdiscussions It is an iterative process that includes thedecomposition of the visual elements in the Webpages, and their association with database entities.RMM is a “soup to nuts” approach to the creationand maintenance of dynamic Web sites

RMM falls short when building Web applications.Web applications, being business logic centric,include a number of technological mechanisms forimplementing business logic that are not adequatelycovered by RMM notation Such technologies asclient side scripting, applets, and ActiveX controlsoften make significant contributions to the executionof the system’s business rules Additionally, Webapplications can be used as a delivery mechanism fora distributed object system Applets and ActiveX con-trols can contain components that asynchronouslyinteract with server side components via RMI orDCOM, independent of the Web server Sophisti-cated applications also make use of multiple browserinstances, and frames on the client, which establishand maintain their own communication mechanisms

Since all of these mechanisms contribute to thebusiness logic of the system, they need to be modeledas such Additionally, since they only represent part ofthe business logic, they need to be integrated with therest of the system’s models In many situations thebulk of business logic is executed behind the Webserver in one of the server side tiers The choice ofmodeling language and notation is typically decidedby the needs of this side the application With theacceptance of the UML by the OMG2 as an officialobject modeling language, more and more systems arebeing expressed with UML notation For many,UML is the language of choice for modeling soft-ware-intensive systems The main issue in modelingWeb applications then becomes: “How do I expressthe business logic being executed in my Web-specificcomponents alongside the rest of my application?”The answer lies in the ability to express the executionof the system’s business logic in those Web-specificelements and technologies with UML

This article is intended as an introduction to theissues and possible solutions for modeling Web appli-cations It focuses on the architecturally significantcomponents particular to Web applications, and howto model them with UML It is assumed that thereader is familiar with UML [1], object-oriented prin-ciples and Web application development The workdescribed in this article is based on some fairlyinnocuous assumptions:

• Web applications are software-intensive systemsthat are becoming more complex, and are insert-ing themselves in more mission-critical roles; • One way to manage complexity in software sys-

tems is to abstract and model them;

1This, of course, is the general goal of a Web application There are plentyof situations where clients of the system may be required to possess a cer-tain computing power, operating system, or security certificate.

2The Object Modeling Group is a consortium of industry vendors thatdefines specifications for the computing industry: www.omg.org.

• A software system typically has multiple models,each representing a different viewpoint, level ofabstraction and detail;

• The proper level of abstraction and detail dependson the artifacts and worker activities in the devel-opment process; and

• UML is the standard modeling language for ware-intensive systems

soft-Modeling

Models help us understand the system by ing some of the details The choice of what to modelhas an enormous effect on the understanding of theproblem and the shape of the solution [1, p 8] Webapplications, like other software-intensive systems,are typically represented by a set of models: use casemodel, implementation model, deployment model,security model, and so forth An additional modelused exclusively by Web systems is the site map, anabstraction of the Web pages and navigation routesthroughout the system

simplify-Most modeling techniques practiced today are wellsuited to development of the various models of a Webapplication, and do not need further discussion Onevery important model, however, the Analysis/DesignModel (ADM)3 does present some difficulties whenan attempt is made to include Web pages, and the exe-cutable code associated with them, alongside the otherelements in the model

When deciding how to model something, mining the correct level of abstraction and detail iscritical to providing something that will be of benefitto the users of the model Generally speaking, it is bestto model the artifacts of the system—those “real life”entities that will be constructed and manipulated toproduce the final product Modeling the internals ofthe Web server, or the details of the Web browser isnot going to help the designers and architects of aWeb application Modeling the pages, their links to

deter-each other, all the dynamic content that went into ating the pages, and the dynamic content of the pagesonce on the client is very important It is these arti-facts that designers design, and implementers imple-ment Pages, hyperlinks, and dynamic content on theclient and server are what need to be modeled

cre-The next step is mapping these artifacts to ing elements Hyperlinks, for example, naturally mapto association elements in the model A hyperlink rep-resents a navigational path from one page to another.Extending this thought, pages4 might map to classesin the logical view of the model If a Web page is aclass in the model, then the page’s scripts would mapnaturally to operations of the class Any page scopedvariables in the scripts would map to class attributes.A problem arises when one considers that a Web pagemay contain a set of scripts that execute on the server(preparing the dynamic content of the page) and acompletely different set of scripts that only execute onthe client (JavaScript) In this scenario, when we lookat a Web page class in the model there is confusionover what operations, attributes and even relation-ships are active on the server (while the page is beingprepared) and which ones are active when the user isinteracting with the page on the client Additionally, aWeb page as delivered in a Web application is reallybetter modeled as a component of the system Simplymapping a Web page to a UML class does not help usunderstand the system better

model-The creators of the UML realized that there wouldalways be situations in which the UML, out of thebox, would not be sufficient to capture the relevantsemantics of a particular domain or architecture Toaddress this purpose, a formal extension mechanismwas defined to allow practitioners to extend thesemantics of the UML The mechanism allows us todefine stereotypes, tagged values and constraints thatcan be applied to model elements

A stereotype is an adornment that allows us to define

3In the Rational Unified Process the Analysis and Design model are ered the same model, that over time evolves from something that describesthe realization of use cases in an architecture neutral way to something thatis an abstraction of the implementation model and source code.

consid-4Depending upon the specific Web application architecture, a Web pagemay be a CGI module, Active Server Page, Java Server Page, Servlet, orWeb server extension (ISAPI, NSAPI), or basically anything that can berequested with HTTP by a browser.

A formal extension mechanism was defined to allow practitioners to extend the

semantics of the UML.

a new semantic meaning for a modeling element.

Tagged values are key value pairs that can be associated

with a modeling element that allow us to “tag” any

value onto a modeling element Constraints are rules

that define the well-formedness of a model They canbe expressed as free-form text or with the more formalObject Constraint Language (OCL)

The work discussed in this article introduces anextension to the UML for Web applications Thisextension, in its entirety, is beyond the scope of thisarticle; however, most of the concepts and explana-tions are discussed here

One final point on modeling: a very clear tion needs to be made between business logic and pre-sentation logic For the typical business application,only the business logic should be part of the ADM.Presentation details such as animated buttons, fly-over help and other UI enhancements do not nor-mally belong in the ADM If a separate UI model isconstructed for the application, then this is the placefor such things The ADM needs to remain focusedon the expression of the business problem and solu-tion space In this era of Web artists, the look and feelof a Web page is better designed and implemented bya specialist (technical graphic artist) and not by a tra-ditional developer

distinc-Web Application Architecture

The basic architecture of a Web application includesbrowsers, a network, and a Web server Browsersrequest Web pages from the server Each page is amix of content and formatting instructionsexpressed with HTML Some pages include clientside scripts that are interpreted by the browser.These scripts define additional dynamic behavior forthe display page and often interact with the browser,page content and additional controls (Applets,

ActiveX controls and plug-ins) contained in thepage The user views and interacts with the contentin the page Sometimes the user enters informationin field elements in the page and submits them tothe server for processing The user can also interactwith system by navigating to different pages in thesystem via hyperlinks In either case, the user is sup-plying input to the system which may alter the“business state” of the system

From the client’s perspective, the Web page isalways an HTML formatted document.5 On theserver, however, a Web page may manifest itself in anumber of different ways In the earliest Web appli-cations, dynamic Web pages were built with theCommon Gateway Interface (CGI) CGI defines aninterface for scripts and compiled modules to givethem access to the information passed along with apage request In a CGI-based system a special direc-tory is typically configured on the Web server to exe-cute scripts in response to page requests When a CGIscript is requested, the server, instead of just returningthe contents of the file (as it would for any HTML-formatted file), processes or executes the file with theappropriate interpreter (usually a PERL shell) andstreams the output back to the requesting client Theultimate result of this processing is an HTML-for-matted stream that is sent back to the requestingclient Business logic is executed in the system whileprocessing the file During that time it has the poten-tial to interact with server side resources such as data-bases and middle tier components

Today’s Web servers have improved upon this basicdesign Current Web servers are much more securityaware, and include features like management of clientstate on the server, transaction processing integration,remote administration, and resource pooling to namejust a few Collectively the latest generation of Webservers is addressing those issues important to architectsof mission-critical, scalable, and robust applications

When looking at the role of CGI scripts, today’sWeb servers can be divided into three major cate-gories: scripted pages, compiled pages, and a hybridof the two In the first category, each Web page that aclient browser can request is represented on the Webserver’s file system as a scripted file This file is typi-cally a mix of HTML and some other scripting lan-guage When the page is requested the Web serverdelegates the processing of this page to an engine that

Figure 1 Associations between stereotyped classes.

«build»«link»

0 *

home page

«link»{productId}

ProductDetailGetProduct

5It is expected that native XML browsers will be on the market soon XMLcombined with XSL will provide many of the same features as HTML withthe significant advantage of increased separation of content and presenta-tion Although the ideas expressed in this article mostly revolve aroundHTML, it is expected they can be extended to handle XML-based systems,once their usage patterns have been defined.

recognizes it, with the ultimate result being anHTML formatted stream that is sent back to therequesting client Examples of this are Microsoft’sActive Server Pages and Cold Fusion.

In the second category, compiled pages, the Webserver loads and executes a binary component Thiscomponent, as with scripted pages, has access to allthe information that came with the page request (val-ues of form fields and parameters) The compiledcode uses the request details, and typically accessesserver side resources to produce the HTML streamthat is returned to the client Although not a rule,compiled pages tend to encompass a larger function-ality than scripted pages By passing parameters to thecompiled page request different functionality can beobtained Any one compiled component may actuallyinclude all the functionality of an entire directory ofscripted pages The technologies that represent thistype of architecture are Microsoft’s ISAPI andNetscape’s NSAPI

The third category represents scripted pages that

once requested are compiled, and this compiled sion is then used thereafter by all subsequent requests.Only when the original page’s contents change willthe page undergo another compile This category is acompromise between the flexibility of scripted pagesand the efficiency of compiled pages; Java ServerPages is an example in this category

ver-Modeling Web Pages

Web pages, either scripted or compiled, map one to components in UML A component is a“physical” and replaceable part of the system TheImplementation View (Component View) of themodel describes the system’s components and theirrelationships In a Web application, this viewdescribes all the Web pages of the system, and theirrelationships with each other (hyperlinks) At onelevel, a component diagram of a Web system is likea site map

one-to-Since components only represent the physicalpackaging of interfaces, they are not suitable for mod-

eling the collaborations inside the pages This level ofabstraction, which is extremely important to thedesigner and implementer, still needs to be part of themodel To start, we could say that each Web page is aUML class in the model’s Design View (LogicalView), and that its relationships to other pages (asso-ciations) represent hyperlinks But this abstractionbreaks down when you consider that any given Webpage can potentially represent a set of functions andcollaborations that exist only on the server and a com-pletely different set that exist only on the client Anyserver-scripted Web page that employs DynamicHTML (client side scripting) as part of its output isan example of such a page The knee-jerk reaction tothis problem might be to stereotype each attribute oroperation in the class to indicate whether or not it wasvalid on the server or client side At this point ourmodel, originally intended to help simplify things, isbecoming quite complex

A better approach to the problem is to consider theprinciple of “separation of concerns.” Logically speak-

ing, the behavior of a Web page on the server is pletely different than it is on the client Whileexecuting on the server it has access to (that is, rela-tionships with) server side resources (middle tier com-ponents, databases, file system) That same page (orthe streamed HTML output of that page) on theclient has a completely different behavior and set ofrelationships On the client, a scripted page has rela-tionships with the browser itself (via the DocumentObject Model or DOM6) and with any Java Applets,ActiveX controls or plug-ins the page specifies Forthe serious designer there can be additional relation-ships with other active pages on the client that appearin another HTML frame or browser instance

com-The server side aspect of a Web page can be eled with one class and the client side aspect withanother, distinguishing the two by using UML’s

mod-6Document Object Model The DOM is a W3C standard that mostbrowser vendors have implemented to provide an object interface to thebrowser and its content.

The server side aspect of a Web page can be modeled with one class and the client side aspect with

another, distinguishing the two by using

UML’s extension mechanism.

extension mechanism to define stereotypes and iconsfor each: «server page» and «client page» Stereotypesin the UML allow us to define new semantics for amodeling element Stereotyped classes can be ren-dered in a UML diagram with either a custom icon,or simply adorned with the stereotype name betweenguillemets (« ») The icons are useful for overview dia-grams; using the simple tags is best when class attrib-utes and operations are exposed.

For Web pages the stereotypes indicate that the classis an abstraction of the logical behavior of a Web page

on either the client or the server The twoabstractions are related to each otherwith a directional relationship betweenthe two This association is stereotyped:«build», since it can be said that a serverpage builds a client page Every dynamicWeb page (pages whose content is deter-mined at runtime) is constructed with aserver page Every client page is built by(at most) a single server page, however, itis possible for a server page to build mul-tiple client pages.7

A common relationship betweenWeb pages is the hyperlink A hyperlinkin a Web application represents a navi-gational path through the system Thisrelationship is expressed in the modelwith a «link» stereotyped association.This association always originates from aclient page and points to either a clientor server page Hyperlinks are imple-mented in the system as a request for aWeb page, which are modeled as com-ponents in the Implementation View Alink association to a client page is essen-tially equivalent to a link association tothe server page that builds the clientpage.8This is because a link is actually arequest for a page, not either of the classabstractions Since a Web page compo-nent realizes both the page abstractions,a link to any of the classes realized by thepage component is equivalent

Tagged values are used to define theparameters that are passed along with alink request The «link» associationtagged value “Parameters” is a list of para-meter names (and optional values) thatare expected and used by the server pagethat processes the request In Figure 1, theSearchResults page contains a variablenumber of hyperlinks (0 *) to the Get-Product server page, where each link hasa different value for the productId parameter The Get-Product page builds the ProductDetail page of theproduct specified by the productId parameter

Using these stereotypes makes it easier to model a

Figure 2 Client collaborations.

cal«Client Page»

RoomScheduleCurrentDay: StringRoom: StringOnBodyLoad()UpdateActivities()AddEvent()RemoveEvent()

«Applet»CalendarDay: intMonth: intYear: intDOW: intValue()Refresh()Today()

«JavaScript»MeetingEventSubject: StringStartDate: DateStopDate: DateStartTime: TimeStopTime: TimeSummary()Conflicts()AddParticipant()RemoveParticipant()

«JavaScript»ParticipantName: StringTitle: StringEmail: StringOffice: StringPhone: StringSummary()

«Form»EventDetailDatePicker«ActiveX»

Day: intMonth: intYear: intValue()Today()

<<Text>> Subject: String<<Select>> Participants: String<<Checkbox>> AllDay: Boolean<<Submit>> Update<<Submit>> Remove<<Button>> New

Figure 3 Server collaborations.

Employee«Server Page»

UpdateMeeting

MeetingDate: DateRequester: EmployeeNewMeeting()RemoveMeeting()UpdateMeeting()FilterParticipants()CheckForConflict()

MeetingFactory

FindMeeting()GetMeeting()CreateMeeting()RemoveMeeting()

MeetingEvent

Subject: StringStartDate: DateStopDate: DateStartTime: TimeStopTime: TimeSummary()Conflict()AddParticipant()RemoveParticipant()

Participant

Name: StringTitle:StringEmail: StringOffice: StringPhone: StringSummary()

Session

7This is typically the case when the server page is a compiled page, and a atively sophisticated component In this situation one server page might beused to define all the behaviors of a shopping cart, or even an entire Webapplication.

rel-8The concept does get a little confusing when a server page builds multipleclient pages In this situation, parameters must be specified with the pagerequest to identify which client page to build.

page’s scripts and relationships The«server page» class’s operations becomefunctions in the page’s server side scripts,and its attributes become page scopedvariables (globally accessible by the page’sfunctions) The «client page» class’s oper-ations and attributes likewise becomefunctions and variables visible on theclient The key advantage of separatingthe server and client side aspects of a pageinto different classes is in the relation-ships between pages and other classes ofthe system Client pages are modeledwith relationships to client side resources:DOM, Java Applets, ActiveX controls,and plug-ins (see Figure 2) Server pagesare modeled with relationships to serverside resources, middle tier components,database access components,server operating system, and soforth (see Figure 3)

Using class stereotypes tomodel the logical behaviors ofWeb pages means their collabo-rations with the server side com-ponents can be expressed inmuch the same way as any otherserver side collaborations The«server page» is simply anotherclass that participates in the busi-ness logic of the system At amore conceptual level, serverpages typically take on the role ofcontrollers, orchestrating thenecessary business object activityto accomplish the business goalsinitiated by the browser’s pagerequest

On the client side, tions can get a little complicated,due in part to the variety of technologies that can beemployed A client page at its simplest is an HTMLdocument that contains both content and presenta-tion information Browsers render HTML pagesusing the formatting instructions in the page, andsometimes with separate style sheets In the logicalmodel this relationship can be expressed with a depen-dency from a client page to a «Style Sheet» stereotypedclass Style sheets, however, are principally a presenta-tion issue, and are often left out of the ADM

Figure 4 Forms submit to server pages.

«submit»items

0 *

«Client Page»OnLineCart

itemCount: integersubTotal: currencytax: currencyshippingCost: currencytaxRate: currencyUpdateItems()recalculateTotals()updateForm()asCurrency()bodyOnLoad()

«Server Page»UpdateCart

CartStatus()CreateNewCart()ValidateCart()AddItem()Removeitem()UpdateItem()UpdateCart()

«Form»CartForm

<<Text>> Qty[0 *]: integer<<Checkbox>> AllowSubs [0 *]: Boolean<<Text>> Total: currency

<<Submit>> Checkout<<Button>> Recalculate<<Submit>> ShopForMore

«Java Script»Item

productID: longproductNumber: stringproductName: stringdescription: stringallowSubs: Booleanquality: integerUnitPrice: currencyweight: floatcost: currencycomputeTota()totalWeight()

Figure 5 Frames example.

«targeted link»{target=content}

«targeted link»{target=content}«targeted link»{target=content}

{row=1col=2}

{row=1col=1}Book

TOC

Chapter1Preface

Chapter2Content

that act as input controls Each form also has a tionship with a server page that processes the form’ssubmission This relationship is stereotyped «sub-mit» Since forms are completely contained in aHTML document, they are expressed in a UMLdiagram with an a strong form of aggregation Fig-ure 4 shows a simple shopping cart page that definesa form, and shows the submit relationship to theprocessing server page

rela-In Figure 4, the «JavaScript» stereotyped class is anobject that represents the items in the shopping cart.Array syntax is used in the description of the form’sproperties for those fields that have a variable num-ber of instances In the case of this shopping cart itmeans that the cart can have from zero to manyitems, each with a Qty, AllowSubs, Cost, and Total<input> element

Since all the activity in the client page is executedwith JavaScript, and JavaScript is a type-less language,the data types specified for any of these attributes areused only for implementer clarification When imple-mented in JavaScript or as HTML input tags, thetype is ignored This also applies to function parame-ters, which, although not fully displayed in this fig-ure, are part of the model

Frames

The use of HTML frames in a Web site or tion has been a subject of polarized debate since itsintroduction Frames allow multiple pages to beactive and visible to the user at any given time Thelatest feature set of the most common browserstoday also allow multiple browser instances to beactive on the user’s machine Using DynamicHTML scripts and components in these pages caninteract with each other The potential for complexinteractions on the client is significant, and the needfor modeling this even greater

applica-Whether to employ frames or multiple browserinstances in an application is a decision for the archi-tect If so, then for the same reasons as previously men-tioned, the model of this client side behavior needs tobe represented in the ADM To model frame usage wedefine two more class stereotypes: «frameset» and «tar-get», and an association stereotype «targeted link» Aframeset class represents a container object, and mapsdirectly to the HTML <frameset> tag It containsclient pages and targets A target class is a named frameor browser instance that is referenced by other clientpages A targeted link association is a hyperlink toanother page, but one that gets rendered in a specifictarget In the example of Figure 5, a common outlineview is presented in a browser using two frames Oneframe is named with a target (Content), the other

frame simply contains a client page This client pageframe is the book’s table of contents (TOC) Hyper-links in this page are targeted, so that they render inthe Content frame The effect is a static table of con-tents on the left-hand side and the book’s contents,chapter by chapter, on the right-hand page

Many of the actual presentation specifics are tured by tagged values in the frameset and the associ-ations Two tagged values on the aggregationrelationship between a frameset and a target or clientpage specify the frameset row and column in whichthe target or page belongs The tagged value “Target”on the targeted link association identifies the «tar-get» where the page should be rendered

cap-When a target is not aggregated with a frameset itmeans that a separate browser instance is used to ren-der the pages It is important to keep in mind that thisnotation is expressing a single instance of a clientmachine Multiple independent targets are allassumed to be running on the same machine, and thediagram expresses the client side behavior of oneclient instance Any other deployment configurationwould need to be heavily documented in the modelfor better understanding

Conclusion

The ideas and concepts discussed in this article arean introduction to issues and solutions for modelingWeb application specific elements with UML Thegoal of this work is to present a coherent and com-plete way integrate the modeling of Web-specificelements with the rest of the application such thatthe level of detail and abstraction is appropriate fordesigners, implementers, and architects of Webapplications A first version of a formal extension tothe UML for Web applications is near completion.This extension will provide a common way forarchitects and designers to express the entirety oftheir Web applications design with UML The mostrecent information on this extension can be foundon the Internet in the Rose and UML sections ofRational Software’s Web site: www.rational.com

References

1 Booch, G., Jacobson, I., Rumbaugh, J The Unified Modeling Language

Users Guide Addison Wesley, Reading, MA, 1998.

2 Isakowitz, T., Stohr, A., and Balasubramanian, E RMM: A

methodol-ogy for structured hypermedia design Commun ACM 38, 8 (Aug.