|
Last Updated: 9-Mar-1999
The Basics
What is the UML Extension for Web Applications?
Why?
Who owns it? Does it cost anything?
Is there any CASE tool support?
Do I have to use the icons? How can I get a copy of the icon files for my own CASE tool?
How can I submit a FAQ question (and get it answered)?
Can I contribute to the extension?
General Modeling Questions
What is a client page?
What is a server page?
Is is possible for a web page component to realize more than one server page, or more than one client page?
When I create a <<link>> association what should it go to the server page or the client page?
Frames
Does the extension cover the use of frames?
How do I specify the number and size of individual frames?
Do I have to use a <<target>> for every frame in a frameset?
XML
Modeling the Client
What is a JavaScript Object?
How do I model Applets?
How do I model ActiveX controls?
How do I deal with the variances in browser implementations?
Do I have to duplicate the DOM?
How do I model variable number form elements?
Modeling the Server
What relationships are permitted on the server?
How do I model ASP's Application and Server objects? Does every client page have to have a main function?
Modeling RMI/CORBA/DCOM
What is the UML Extension for Web Applications?
The UML Extension for Web Applications is a document that defines how web applications can be modeled using UML. The authors of the UML realized that there would always be situations where UML, out of the box, would not be sufficient to capture the relevant information needed to properly model a system. Web applications are one of those situations.
An extension to UML is defined in a document. The document defines a set of stereotypes, tagged values, and constraints. Stereotypes are new modeling elements. They in sense increase the vocabulary of the UML language. Stereotypes can specify special icons to use in diagrams, to help identify them as "special" elements in model diagrams.
Tagged values are simply extra information that can be tacked onto a model element. Tagged values are defined as key / value pairs. Constrains are new rules that must be followed when assembling the model elements.
A collection of these definitions, packaged together is an extension. The UML extension for web applications is designed to define a mechanism by which elements of web applications, most notably; web pages, client scripts, applets, and ActiveX controls can be incorporated into the UML models of the rest of the system.
My principal reason for creating this extension, was to help me apply my existing modeling skills to my latest contract position, which involved creating a web based health care system (although I actually started it a few months earlier). I searched for some time but couldn't find anything on the web. I tried a lot of different things to get it to work in the existing OMT/UML framework but nothing seemed to hold up when put to the limits. (I recently looked at some of my original notes, and had to laugh at some of the things I tried).
Eventually I came to the conclusion that semantics just weren't there in the UML. So I decided to change some of them to fit. Shortly thereafter, I stumbled upon the concept of stereotypes, and the formal extension mechanism.
The main guiding points of this effort are:
Who owns it? Does it cost anything?
Nobody "owns" the extension, nor does it cost money. It's just a specification. It can be used in an isolated environment, and would probably be helpful. It can really be helpful if used by the general community of web applications designers. In this situation it will enable designers to communicate with each other using a common vocabulary, achieving much the same purpose as the UML does for the larger software development community. For this reason the extension needs to remain free - in a sense it is the property of the web application community.
BTW: if anyone at the W3C is interested in taking over this extension, just say the word.
Are there any CASE tools that support it?
Not presently. But I wouldn't be surprised if at least one major company provided similar capabilities soon.
Do I have to use the icons? How can I get a copy of the icon files for my own CASE tool?
No, the use of the icons are optional in any diagram. The use of icons are great in overview diagrams, and diagrams whose main purpose is to get a feel for the types of objects involved in a particular collaboration. I tend to not use them, when the attributes and operations need to be exposed. When designing classes, and defining operations and detailed collaborations, the icons might be distractive. Of course this is a personal preference, and you may decide to use or not use them when ever you like.
A copy of the icon files that I used for Rational Rose 98 is available on this site. The icon files are available in enhanced meta file format (.emf) and as Visio 5 files (.vsd).
How can I submit a FAQ question (and get it answered)?
Just send me an email - jim@conallen.com, I'll do my best to answer it quickly as possible, and if it is a general enough question will add it to this FAQ.
Can I contribute to the extension?
I am open to any and all ideas. Just email me. As a matter of fact, I almost wish the W3C would take up the task and define it for me. I am more interested in a finished mechanism for modeling web applications, than I am in creating them.
A Client page is a stereotyped class that represents an HTML page as it appears in an HTML browser. This is the web page, after it has been processed by the web server.
Client pages are rendered by the browser, and therefore contain "content" in addition to user interface formatting information. Some client pages also contain scripts that are executed by the browser. Some of the scripts are executed in response to some event that either the browser sends (like finished loading the document) or that the user sends (click on a button, or move the mouse over something).
One of the tricky things to remember about client pages is that depending upon the architecture of the system they can only collaborate with objects on the client. The objects on the client are browser itself (usually via the DOM), Java Applets or ActiveX controls (loaded on the client).
If the architecture involves the use of distributed objects, then asynchronous communications can exist between objects and scripts on the client and the server. In these situations either Java's RMI, a CORBA ORB and IIOP, or DCOM is used to enable communications between client and serer side objects. When this type of architecture is employed, associations between client and server objects can be made, and are stereotyped to indicate which distributed object protocols are being used.
A server page is stereotyped class that conceptually represents a web page that can be requested by a client browser. It can be a file, like an HTML file, or a scripted page like ASP or JSP file, or it can even be a CGI program or ISAPI and NSAPI DLL. Basically it is something that a browser can request, and eventually get back as an HTML page. Most server pages do some processing of business logic using the server's resources (i.e. database) and then format the results as an HTML page to be returned to the requesting client. Some server pages, however just do the processing and then defer the HTML page creation to another server page or sometimes to a preformatted HTML page on the server. The point is, a server page is just something that a client browser can request.
In the web extension, a server page can have relationships with server side resources. It can not have direct relationships with client side resources. Server pages do one of two things;
A web page component maps 1:1 to an actual file on the server. In the case of ASP and JSP applications, its the .asp an .jsp file. In the case of CGI, Servlets, ISAPI, NSAPI, etc., it is the actual executable module.
With this said, it is possible (although I frown from the practice) for a server page to biuld more than one client page. For example a simple conditional at the beginning of processing might determine whether the page will contain dynamic content (i.e. scripts) or just be a plain vanilla page (to support older browsers).
It is not possible, however for a single web component to realize more than one server page. The server page contains the entry point for the processing. There can only be one entry point per component, hence one server page. For those situations where a single monilithic program processes all server requests, then just one server page (and entry point) is created, and a number of other server objects (traditional server classes/components) would be associated with the server page. In this case, only global functions, and variables are the attributes of the server page.
Do <<link>> associations go to the server page or the client page?
Both. When a client page links to another page it is really requesting a web page component, and not a logical client page or server page. But since components and logical classes don't usually exist in the same model express the same information by drawing <<link>> associations to the classes that the component realizes (after all that is what the component is for anyway). Because of this a <<link<> association can be made to either the client page or a server page (assuming that they are realized by the same component, as woudl be the case when the server page builds the client page).
Does the extension cover the use of frames?
Yes. But its not pretty. Frames proved to be the most difficult web features to model. Basically frames present multiple and simultaneous user interfaces to the user. To confuse matters even more, these interfaces can interact with each other. A full discussion of how frames are modeled is too long to fit in this FAQ, but it does involve the use of two another class stereotypes (<<frameset>> and <<target>>), and an association stereotype (<<targeted link>>).
How do I specify the number and size of individual frames?
The position and sizes of frames is captured with tagged values in the each of the target classes. Each target (or client page, in the case when no formal target is specified) has tagged values to specify the row and column they are, as well as values for thier size (in precentage, or pels).
Do I have to use a <<target>> for every frame in a frameset?
No. It is possible to define a frame in s framset without specifying a target name. In this situation a client page is associated directly with the frameset via an aggregation relationship.
Are there any extensions for modeling XML documents?
It was my original goal to include a set of stereotypes and constraints to cover XML in the greater scheme of things. I tried a number ideas but never felt satisified with any of them. I've only had one "professional" experience with XML, and at the time wasn't convienced it was used properly nor for the right reasons. I think this overall confusion with the role XML can play in a web application is at the root of my confusion on how to model it. Until the usage patterns of XML in web applications have stabilized I don't think we can determine the appropriate level of abstraction or detail that needs to be modeled.
This doesn't mean that others aren't doing it. I've run across a number of people talking about modeling XML DTDs and Schemas, and have even seen a few attempts at it with UML. It will happen, and I'm even brave enough to predict that we will soon be incorporating XML DTD/Schema modeling elements into our application models. I am even predicting that we will be using modeling tools to help us generate object interfaces to our XML documents. Unfortunately I don't have the details ready for this first release of the extension.
If *anyone* has any ideas on the topic, or even pointers to existing efforts I would love to hear about them: jim@conallen.com .
A JavaScript object is an object that has state and behavior. It is esentially a JavaScript "Object", that has had custom properties and functions associated with it. Although it can not "inherit" from other custom objects, or do similiar object oriented things, it does provide a godo mechanism for encapsulation of business logic and data.
When a JavaScript stereotyped class gets implemented it gets mapped to the set of functions defined in it, plus a special prototype function (which initializes the objects attributes if they have initial values). This prototype is like the object's constructor.
Modeling an Applet is easy. It is just a sterotyped class (<<Applet>>, or whatever the CASE tool and code generation tools define it to be) that has associations with the client page.
A client page has an aggregation relationship with an applet since the applet is actually contained in the HTML page. Applets are modeled like ActiveX controls.
How do I model ActiveX controls?
Modeling an ActiveX control is easy. ActiveX controls are just components that exist on the client. If the component is specified in the client page with an <object> tag, then an aggregation relationship is drawn between the page and the control (since the page is the object that contains the control, and requests is download from a server).
Any client side ActiceX control can be modeled with the page. If the contol (COM component) is already on the client (by virtue of the browser installation), then simple associations can be used instead of aggregation associations.
How do I deal with the variances in browser implementations?
Unfortunatly the web extension doesn't help one bit here. Making cross browser applications is ironically difficult. There are several strategies for doing so; design separate pages for each browser variant, embed conditional logic in each page or just accept a minimal browser configuration. Irregardless of what method is used, the modeling technique remains the same.
Do I have to duplicate the DOM?
Not unless it help clarify the model.
The Document Object Model (DOM) is an industry standard interface to client resources including the browser, and HTML document itself. It is often easier just to specify in an external document that the DOM is assumed to be available on the client. Designers can then concentrate on designing the client side aspects of the application, without worrying about duplicating DOM elements in the model. Of course this is just personal preference, if having the DOM appear in the model makes it clearer, then by all means use it. Remember the goal of modeling is to make it easier to understand the system being developed.
With this said, the answer to the question is no. You do not have to.
How do I model variable number form elements?
A shopping cart page is a perfect example where there may be a unknown number of form field controls. For example each line item in the cart may allow the user to update the Quantity value, which is represented in the form as a <input type="text"> control.
In the model form elements are attributes of a <<form>> class. Each element is stereotyped with thier HTML type. To represent variable number elements the UML array syntax is used. For example the shopping cart form might look like;
What relationships are permitted on the server?
Smart answer: Any that are appropriate.
The relationships on the server are those bewteen objects the exist on the server. These include databsae middleware, server pages, and even the web server itself (if it contributes to business logic).
Things get a little confusing when RMI/IIOP/DCOM are used. These technologies allow client objects (i.e. objects that exist in the address/process space of the client) to directly communicate with objects on the server. When this architecture is employed, special stereotyped relationships are drawn between objects on the client and server.
How do I model ASP's Application and Server objects?
Model them simply as singleton objects. Since they are essentially general purpose dictionaries or maps, use thier attributes names as keys to primative types and, use qualified associations for complex types.
Does every server page have to have a main function?
In my whitepapers and presentations I've mentioned on several occasions, that good modular design should be made in ASP pages. Most of my web experience has been with Microsoft's ASP technologies, and over the years I've found that ASP code can be very difficult to read. I've managed to make them just a little easier, by declaring variables and functions with very strict responsibilities. To manage the excution flow in the page as a whole I usually define one main function, that is the only in-line ASP executed line of code. I feel this helps make it easier to keep track of what gets executed and when.
How do I model RMI/CORBA/DCOM object interactions?
The web is an excellent way to distribute documents, specifically sets of related (or linked) documents. It should be no surprise that this same platform would be leveraged to distribute actual objects. Remote Method Method Invocation (RMI) is the Java way to allow applets on the client communicate directly with Java objects on the server without going through the web server and HTTP. CORBA is a specification to allow objects written in different languages communicate with each other across different machines. Finally Dstrributed COM (DCOM) is the way components on Microsoft platforms can communicate with each other over a network. Each of these technologies can be leveraged in web applications, and hence it is important that these architecturally significant components also be represented in the application's design model.
One of the keys to modeling is to model at the appropriate level of abstraction and detail, and to model the artifacts of the system. One of the design goals of RMI, CORBA and DCOM is to make distributed communications easy by hiding the messy details of the underlying infrastructure. These two statements imply that they should be modeled simply. Since the details of the communication infrastructure are meant to be hidden from the designer and implementer, then that is houw they shoud be modeled.
Modeling direct client and server object communication is best modeled with simple <<RMI>>, <<IIOP>> and <<DCOM>> association stereotypes. When the relationship is not structural in nature, then the same stereotypes can be applied to dependency relationships. the whole idea here is not to introduce any more complexity into the model than is expected in the ultimate solution.