modeling web application design with uml

8/7/2019 Modeling Web Application Design With UML

1/18

Modeling Web Application Design with UML

Re-publish by : [email protected]

Source/ Writer : Jim Conallen, Principal Consultant Conallen, Inc.

Title : Modeling Web Application Design with UML

Introduction

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

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

Most of my experience with web applications comes from my use of MicrosoftsActive Server Page technology. I have made a very strong attempt to make thediscussions in this paper as generic as possible, so that other technologies such as

Allaires Cold Fusion could also be used. In addition web applications based on CGIscripts 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 ofweb sites and applications have been omitted. The focus is on the ability of a webapplication to function as a software application, and the details of display andformatting are only of interest in those special cases where they directly effect thebusiness logic. Also not addressed is use of external applications and MIME types.

Discussions in this paper assume working knowledge of UML, and some knowledgeof 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 webapplication development environments.

Web Application Architecture

Web Sites


2/18

There is a subtle distinction between a web application and a web site. For thepurpose of this paper a web application is a web site where user input (navigationthrough the site and data entry) effects the state of the business (beyond of courseaccess logs and hit counters). In essence a web application uses a web site as thefront end to a more typical application.

The architecture for a web site is rather straight forward. It contains three principalcomponents; 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. Figure1 shows this relationship. Some web sites require clients to logon, and some allowanonymous access.

Figure 1 Basic Web Application Architecture

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 pathinformation with the request. These files are termed pages, and represent thecontent of a web site.

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


3/18

Figure 2 Dynamic Web Site Architecture

Dynamic web sites offer certain advantages to web site designers. They make iteasy to keep the content fresh and synchronized with data in a database. Theoverall look and feel of the web site is defined by a set of pages that contain codeexecuted 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 acompiled binary file that is executed by the web server. In either case the code inthe "page" references and utilizes server resources which include databases, emailservices, file services, etc.

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

Web Applications

The distinction between web sites and web applications is subtle, and relies on theability of a user to effect the state of the business logic on the server. Certainly if nobusiness logic exists on a server, the system should not be termed a webapplication. For those systems where the web server (or an application server thatuses a web server for user input) allows business logic to be effected via webbrowsers, the system is considered a web application. For all but the simplest webapplications the user needs to impart more than just navigational request

information, typically web application users enter a varied range of input data. Thisdata 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, whereusers do enter in relatively sophisticated search criteria. Search engines that areweb sites, simply accept this information, use it in some form of database SELECTstatement and return the results. When the user finishes using the system there isno noticeable change in the state of the search engine (except of course in theusage logs and hit counters). This is contrasted with web applications that, forexample accept on-line registration information. A web site that accepts courseregistration information from a user has a different state when the user finishesusing the application.

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


4/18

Pages

By far the most fundamental component of a web application is the page. Browsersrequest pages (or conceptual pages) from servers. Web servers distribute pages ofinformation to browsers. The makeup and organization of a web pages in essencemake up the user interface for the application. In web applications the browser acts

as a generalized user interface container with specific user interfaces being definedby each pages content.

In web application development environments like Microsofts Active Server Pagesor Allaires Cold Fusion, the pages are a combination of static HTML formattedpages, and dynamic scripted pages. The scripted pages contain code that isexecuted by the web server (actually it is more likely to be delegated to a scriptingengine or page filter) that accesses server resources to ultimately build an HTMLformatted page. The newly formatted page is sent back to the browser thatrequested it.

Server Scripting

It is important to note that the connection between the client and server only existsduring a page request. Once the request is fulfilled the connection is broken. Allactivity on the server (as effected by the user) occurs during the page request. Thisrepresents a very significant distinction between traditional client serverapplications. Business logic on the server is only activated by the execution ofscripts inside the pages requested by the browser.

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

The ultimate result of this server processing is to;

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

An important and subtle part of web application design is understand andaccommodating of this paradigm of client and server interaction. Business objectsare not always accessible when handling individual user interface requests. Forexample a common user interface (and business feature) in many client serverapplications is the automatic population of city and state fields in a US postaladdress 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 pagerequest to happen immediately after the zip code was entered. For most webapplications this carries with it an unacceptable performance burden. For most webapplications page requests are fulfilled in an order of seconds instead ofmilliseconds.

Client Scripting


5/18

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

Scripts on the client are appropriate for immediate data validation, or in assistingnavigation. Often client scripts simply "jazz" up the user interface and provide littleif any business logic behavior. This is changing however, as client side scriptingbecomes more powerful, and client side resource become more a part of the overallapplication.

Client scripts should not be confused with client side components such as JavaApplets or ActiveX controls. These components are a separate category ofcomponent in the overall web application architecture and are discussed in moredetail later. The client scripts discussed here are JavaScript (or VBScript) codeembedded in the HTML formatted page. The code is executed in response tobrowser generated events (document loaded, button pressed, etc.). With theacceptance of the new Dynamic HTML specification, client scripts can access andcontrol nearly every aspect of the pages content. Additionally it further opens upaccess to the browser object model itself, enabling client side scripts to interactwith other browser resources.

When an HTML web page is rendered in a browser it is first parsed and divided upinto elements. When dynamic HTML is employed each of the elements can benamed or assigned an ID, which could be referenced by client side scripts. Somecommon element types include anchors (links to other pages), tables, fontspecifications, etc. The elements making up the content of the page have an objectinterface defined by the Document Object Model (http://www.w3.org/DOM/). The

browser also has an accessible interface, yet differing brands of browsers may havesubtle differences.

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

Forms

Any serious web application accepts more than navigation input from its users. Webapplications 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. Thebasic input elements are; a textbox, text area, checkbox, radio button group, andselection list.

All the input elements on a form are identified by name or ID. Each form isassociated with an action page. This action page represents the name (and location)
http://www.w3.org/DOM/http://www.w3.org/DOM/


6/18

of the page that is to receive and process the information contained in thecompleted form. The action page is almost always a dynamic page, containingserver side scripts (or compiled code).

When a form is completed by a user the user submits the form back to the serverwith a page request for the action page. The web server finds the page and

interprets (or executes) the pages code. The code in the page has the ability toaccess any information in the form that was submitted with the request. This is themajor mechanism for obtaining user input in a web application.

Components

Server

All business logic neednt be interpreted from scripts in web pages. Larger and moreenterprise 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. Theapplication server may execute on the same machine as the web server but doesnot necessarily have to. One of the advantages of an explicit third tier running on aserver is the ability to share implementations of business functions acrossapplications, web or not. Another is an encapsulation layer, for all business logic. Afull description of the merits of three tiered architecture is beyond the scope of thispaper.

When a compiled middle tier of business objects is present in the architecture theserver scripts in the web pages, primarily act as the glue between the user interfaceand the business layer. Scripts executed on behalf of the web server havereferences 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 theuser during page requests. The processing of a page request may result in aprocess or two to get executed on the server, and remain executing long after theclient browser has shut down, but the process would be running in isolation fromthe client. Even when compiled business object components are used, theconnection between the client and the server is closed once the requested page hasbeen received by the browser.

The correct decision to use a third tier or not is dependent upon the specificapplication. Some points to consider include improved performance time withcompiled 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 enhancecode, without taking down the application. Changes can be made to server scriptedpages (within reason) without stopping the application. If the amount of businesslogic is relatively small, the absence of a full middle can be very appropriate.

Client


7/18

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

Components on the client raise significant security concerns which are betteraddressed outside this paper. It should be sufficient to say that compiledcomponents executing in the browser and on the client can make up a significantpart of a web applications architecture.

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

Frames

The user interface capabilities on the client can be enhanced with the use offrames. Frames and the ability to target browsers, enable the user interfacedesigner to have multiple web pages active and open at the same time. Thebrowser 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 itis possible for a framesetto 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 targetwith each frame in abrowser window. A proper discussion of the use of frames in user interface design isbeyond the scope of these discussions, however the point must be made that theuse of frames does constitute a major design decision in a web application, as itindicates 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 wereinfluenced by Microsofts implementation of Active Server Pages and offer aconvenient mechanism to manage client side state on the server.


8/18

Figure 3 Model of a generalized web application architecture

Other Components

A very effective and complex web application can be developed with thecomponents mentioned previously. But nothing is good enough when technology isconcerned. Some of the latest developments in the web application area still impactthe architecture. Included in this are scriptlets and XML. Scriptlets are presently aMicrosoft browser exclusive and therefore only an option when it can be guaranteedthat all clients are using Internet Explorer 4.0 or later. The other, XML is also pushedby 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 GeneralizedMarkup Language) and defines how related data can be transmitted across the webin a standardized way. Much like how HTML uses tags to describe the formatting ina web page, XML enables user defined tags to describe the meta-structure of datawith the actual instance data as it is transmitted between server and client. Againthis is not the proper place to discuss in detail XML, the most recent draft of the


9/18

XML standard can be found on: http://www.w3.org/pub/WWW/TR/WD-xml.html. Forthe purposes of this paper XML defines a portable way to encode hierarchical data.

Modeling

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

With these goals in mind the task of modeling web application design becomes notso clear. Given the assumption that the primary artifact of a web application is theweb page, it should be obvious that the page should be modeled. But how? UsingUML we can express a page as an object. This then brings up the question; what arethe 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 apage object?

The answer should come from the question; what is the model being used for, andwho is the audience? In the case of a design model, the user interface formatting isirrelevant, and typically doesnt effect the business logic in the system. Scripts,especially server side scripts, do effect the business behavior of the system (and insome systems represent the entirety of the systems business logic!). Additionally itis not hard to visualize variables in a scripted page (those with page scope) as beingattributes of a page object and the function in the page as being its methods. Theseare appropriate for a design model and for a web application designer.

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

Modeling Extension

The designers of UML recognized that the language is not always perfect for everysituation. There are times when the development process would be better served ifadditional information we captured, or different semantics were applied to certainmodeling elements. UML has defined a mechanism to allow certain domains toextend the semantics of specific model elements. The extension mechanism allows

the inclusion of new attributes, different semantics and additional constraints. Whencollected together as Tagged Values, Stereotypes and Constraints they form anExtension to UML. This paper presents an extension of UML for web applicationdesigns.

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


10/18

The problem of a web page having different scripts and variables executed on theserver or on the client can be solved in one of two ways. The first would be to definethe stereotypes; server method and client method. In a page object a method thatexecutes on the server will be stereotyped as server method and functions thatrun on the client client method. This solves the problem of distinguishingattributes and methods of a page object, however it is still confusing. A further

complication arises later when associations are made to other components in themodel. It is not clear that some of these relationships are valid only in the context ofthe server methods and attributes or on the client.

Page Stereotypes

A better way to model a page is with two separately stereotyped classes; serverpage and client page. Any given web page in a web application that hasfunctionality on the server as well as client can be represented in the model as twoseparate classes, even though their implementation is in the same file (orcomponent). In this situation a web pages server methods and page scopedvariables are all contained in a class in the model stereotyped server page. Thisclasss methods represent the pages server side scripts; sub routines andfunctions. Variables declared in the scripts that have page scope represents theclasss attributes. Client side scripts or user interface formatting are not part of aserver pages scope. A server page can have relationships to components that existon the server. These might include the business objects in three tiered systems ordata access components. Components relative to the applications design andoperation on the server are represented side by side with the server pages that usethem.

Client pages are similarly represented on the diagram with classes stereotyped:client page. Client pages attributes are page scoped variables and functions that

execute in the client browser. Client pages are associated with components thatexecute on the client, including Java Applets, ActiveX controls, and elements of theDocument Object Model itself.

There is a fundamental relationship between the server and client stereotypes of aweb page. A server page ultimately builds the resulting client page. This is aunidirectional relationship, since a completed HTML page has little access to theobject interface of the building server page. The stereotype builds is applied toassociations and is always drawn in the model as a unidirectional association from aserver page to a client page (Figure 4.). It indicates which server page is responsiblefor building a given client page.


11/18

Figure 4 Server pages build client pages

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

Another facility of some web application development technologies is the ability toredirectthe processing requests to another server page. This relationship can beexpressed in the model with the redirects association stereotype. A design mightidentify 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 webapplications. Figure 5 shows this relationship.

Figure 5 Server pages can delegate

A fundamental and yet subtle relationship between client pages and server pages isin the implementation diagram. Components in the implementation diagramrepresent distributable pieces of the system. For these stereotypes it is the webpage. A component in an implementation diagram (component view in RationalRose) represents an actual file that is request-able by the web server, and which


12/18

realizes at least one server page or client page. Figure 6. conceptually shows thisrelationship.

Figure 6 A web page components realizes both server and client pages

An additional relationship that may be of importance in web application design isthe 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 isthe component that is requested by the client browser. If the requested componentrealizes a server page (at most one) then the server page is processed in order toget a resulting client page to fulfill the browsers request. If not the web serversimply retrieves the requested component (file) and sends it back to the browser.

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


13/18

Figure 7 Client pages can like to each other

Figure 8 Linking with parameters

Components

Components in the sense of interfaces available to objects in the web applicationlike ActiveX controls and DLLs, Java Applets or executables are also given astereotype in the web extension. Just with pages components are identified as beingexecuted on the server machine or on the client machine. The stereotypes servercomponent and client component can be applied to classes in the design modelto distinguish availability. Certainty a database access component on the server isnot directly accessible by client scripts running in a browser. Stereotypingcomponents (interfaces) in the design model helps to clarify the model.

Forms

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

A form class has as attributes is field elements. Methods however do not apply toforms, 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 apage. 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 pagestereotype) to accept and process data submitted with the form. A submitsassociation stereotype represents the relationship between a form and the webpage that processes it, see Figure 9. The association is bi-directional since the


14/18

processing page has access to the forms attributes, which are submitted when theassociation is realized during runtime.

Figure 9 Forms submit to server pages

Framesets

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

Frames are implemented in HTML by defining a frameset. A frameset specifies andoptionally names separate frames in which web pages can be rendered. The

implementation of a frameset is in an HTML page. To maintain compatibility witholder non-frames capable browsers, a frameset web page usually containsformatting and informational content that is only seen on the older browsers. Thisleads us to model framesets as a client page, but a specialized one, and hence anew stereotype: frameset. In a design model classes stereotyped frameset mayhave all the associations that a client page can have, with the understanding thatthese are only appropriate for older browsers.


15/18

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

Coordinating activity between pages in frames (or other windows) requires theability 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 verydifferent element from a frameset, and considering web pages can also referencetargets that are in other opened browsers, another class stereotype is defined;target. A target has no properties or attributes, it is merely a reference-ablecontainer for a client page. A frameset class can contain a target, or a target canexist 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 sharedand referenced by many client pages. Additionally since it has no meaningfulattributes or methods its semantics are different from normal classes.

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


16/18

Figure 10 Using framesets and targets

Other Stereotypes

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

scriplet A scriplet is a cached client page, that typicallycontains references to components and controlsthat are re-used by subsequent client pages. Itsprimary significance in the design model is that itis an available source of re-use for client pages.

xml An XML stereotyped class represents ahierarchical data object that can be passed to andfrom a web server and client browser. XML is astandard way to represent hierarchical data in an

application independent way.Uses and tools for XML are just now emerging,and it expected that XML will play a larger role inweb applications.

One user interface feature of a web application not addressed yet is the ability of aclient page to pop up a modal dialog box, to gather user input. Client scripts invokethis operation, and this is modeled with a directional association from a callingclient page to another web page (server or client). The association is stereotypeddialog, indicating that the client page calling the dialog is temporarily suspendeduntil the called "dialog" page closes. Typically a client page calls a dialog page to

get small amounts of user input that either dont fit on the original client page or isso infrequently used that it isnt worth the screen real estate to put there.

The last stereotype under consideration is event and is the only methodstereotype of the extension. It applies to methods in a client page object that arehandlers to browser generated events. These help the designer to visualize whichbehaviors in a client page can happen asynchronously.

Process Considerations

Knowing the semantics of design models is certainly only part of the process ofdelivering quality software. Before concluding our discussions on modeling web

application design I would like to offer a few words of advice regarding the steps totake when developing web application designs.

A web application is a specialized version of a client/server application. Many of thedevelopment activities appropriate for client/server application development alsoapply to web applications. The importance of requirements modeling can not beemphasized enough. Use Cases provide an excellent way to capture and model asystems requirements. Although not all requirements are present in use cases, they


17/18

do provide an excellent mechanism for organizing specific functionality andespecially user interaction.

A use case is a textual description of the interaction of the system and the user, inthe language of the domain. How tightly coupled use cases are with user interfacesis yet another matter of great debate. It should be sufficient to say that an

examination of a systems use cases provides an excellent starting point to identifyclient pages in the application. For the first iteration of design it is a good idea tostart off with one client page for each use case involving interaction between ahuman actor and the system.

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

Like any realistic project there will be several rounds of iteration and possiblysignificant changes in the design. Using the extension presented earlier will helppresent to the designer and implementer a clearer picture of the actual webapplication design.

Conclusion

The major purpose of this paper is to present a mechanism to assist web applicationdesigners. With the assumptions that modeling is important, and we shouldmodeling the artifacts of a system, it becomes obvious that web applicationdesigners 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 theirhidden object oriented aspects.

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

Comments and suggestions are very welcome and can be sent to

[email protected].

Appendix A. Stereotype Icons

ClassStereotype

Icon


18/18

Server Page

Client Page

Form

Frameset

Target

Copyright 1998 Conallen, [email protected]

Used by Permission.

Link to http://www.conallen.com/

http://www.itmweb.com/spotlite.htm
http://www.conallen.com/mailto:[email protected]://www.conallen.com/http://www.conallen.com/mailto:[email protected]://www.conallen.com/

modeling web application design with uml

Documents