Chapter 19: Web Modeling

In this world of e−business, e−commerce, and e−government, no discussion of UML would be complete without a discussion of web modeling. Although similar to traditional client/server applications, web applications have their own unique benefits and challenges, which naturally affect their design.

Rose 2001, 2001A, and 2002 include an add−in that supports the code generation and reverse engineering of web applications. You can model and generate HTML pages, ASP pages, JSP pages, and other types of web classes using Rose.

Modeling a Web Application

Whether you are creating a new web application from scratch, or reverse engineering and modifying an existing application (see "Reverse Engineering a Web Application" later in this chapter), it is necessary to first gain an understanding of the different web stereotypes and relationships. Before we look at these, however, let's take a look at web architecture in general.

In many ways, a web application is similar to a traditional distributed application. The logic is divided into two or more areas, or tiers. At a minimum, the presentation logic is separated into the presentation layer, and the business logic is separated into a server logic layer. The presentation layer runs on the client, while the business logic runs on the server. In many cases, the business logic is separated into two or more layers of its own. For example, the logic dealing with the connection to the database may be separated from the rest of the business logic.

One of the primary differences between a web application and a traditional distributed system is in the persistency of the connection between the two (or more) layers. In a distributed system, once objects have been instantiated on the client and the server, they can communicate with each other only when needed. A web application, on the other hand, is stateless—once the communication between the client and the server ends, the server loses all information about the client. It no longer knows who was logged in or what they were doing. One way to manage this challenge is through the use of cookies. A cookie is a file that resides on the client and can store state information about the client so that the next time a connection is established with the server, the contents of the cookie can be used to give the server state information.

Another difference lies in the deployment environment. An advantage of the Web, of course, is the ability to reach thousands of users without needing to worry about setting up each machine. The disadvantage is the ability to reach thousands of machines, many of which may have slightly different configurations. Different browsers, operating systems, connection speed, processor, memory configuration, and other factors can complicate web deployment. Not all components will run with all browsers, so the designer has extra work to do if the application must run on several different types of browsers.

There are two primary patterns to a web architecture: thin client and thick client. In a thin client architecture, very little logic is placed on the client side. Few, if any, ActiveX controls, applets, or other components are downloaded to the client browser and run on the client machine. Two of the advantages of this approach are speed and portability. Downloading components to the client can be very slow, so minimizing the number of downloads helps to increase the speed of the application. A thin client architecture can also be more portable, because not every component will work on every type of browser. Minimizing the number of different component technologies needed for your application can help ensure that the application will work in different browsers. The disadvantage to the thin client approach is that the user interface can't necessarily have a lot of bells and whistles; client−side components may be needed to provide an enhanced user interface.

657

Chapter 19: Web Modeling

The second approach to a web application is to use a thick client architecture. In a thick client, more logic is run on the client. When a component is needed on the client, it will be automatically downloaded from the server. This approach gives the team the option of including more sophisticated controls on the user interface. The team can also build applets or other components to run some logic on the client. The advantage of this approach is the ability to create more robust user interfaces. The disadvantages are speed and portability. The downloads take time, and there is no guarantee that the different browsers will support the application if too many different types of components are downloaded.

The process of modeling a web application begins just like the process of modeling a client/server application—with analysis. The team defines the use cases, gathers and documents the requirements, and

writes the flow of events for the use cases. We won't discuss this in detail here; see Chapter 4, "Use Cases and Actors," for information about use cases and actors.

Once the flow of events has been written for a use case and its requirements have been documented, the design process can begin for that use case. This involves the creation of Sequence diagrams, Collaboration diagrams, Class diagrams, Statechart diagrams, Component diagrams, and Deployment diagrams.

As in a client/server application, Sequence and Collaboration diagrams show the objects that participate in a use case scenario. As the designers are building and reviewing the Sequence diagrams, however, they must keep the web architecture in mind. There are a few primary considerations. First, because the application is stateless, the designers cannot assume that once an object is instantiated, it can be accessed indefinitely by the other objects. As soon as the connection between the client and server is broken, objects on one layer cannot access objects on the other, and the server loses all information about the state of the client. The designers can, however, use cookies and session objects to store state information. A cookie is a small file on the client machine that can be used to store state information, while a session object is created on the server and holds information about a particular client through the life of the client's session. After a period of time, say 30 minutes, the server assumes that the client has timed out, and the session object will be released.

If the team uses session objects, they will appear in the Sequence and Collaboration diagrams, just as any other objects. One very useful tool in Rose 2001A and 2002 is the ability to place destruction marks on the Sequence diagrams. This notation can make it easier for the team to remember which objects are available in memory at which point in time.

A second consideration in web modeling is that client pages should not have access to server resources. The designers should ensure that none of the pages, applets, or other client−side components can directly access the server. Instead, they should access a server page, which can then access the server−side components. If the application is a thin client, the designers should minimize the number of components downloaded to the client machine. As they are building the Sequence and Collaboration diagrams, therefore, the team should not use many client−side components.

Before you begin modeling, you will need an area in Rose to create your classes. You will work in the Logical view, but you must first set up a virtual directory. A virtual directory is a stereotyped package in Rose that represents a physical directory on your network. Any classes in the virtual directory will be generated into the physical directory.

658

Chapter 19: Web Modeling

To create the virtual directory:

1.

Right−click the Logical view in the browser.

2.

Select Web Modeler → New → Virtual Directory.

3.

Right−click the new virtual directory. The specification window will appear:

4.

Select the platform (ASP or JSP) you will use for this application.

5.

Enter the URL of your web application. Rose requires the URL to generate code or to reverse engineer web classes into the model.

6.

Enter the virtual directory name. This is the name of the virtual directory package that will appear in the Logical view in Rose. All of the classes for this web application will be placed in this package.

7.

Enter the physical location. All classes in this web application will be generated into this location and reverse engineered from this location.

Once you have created the virtual directory, you can create web objects inside it.

Web Class Stereotypes

To model your web application, you will need to create classes to represent your client pages, server pages, and HTML pages. To complete the picture, you can then add relationships between these model elements. When Rose generates code, it will examine both the classes and the relationships.

There are three different types of class stereotypes that can be generated or reverse engineered in Rose: client pages, server pages, and HTML pages.

659

Chapter 19: Web Modeling

Client Pages

Client pages are HTML−formatted pages that run on the client. These contain some functionality, but typically do not include intensive business logic. Logic on the client pages is usually related to presentation of the data. Client pages do not directly access business objects on the server; this is the role of a server page. In Rose, a client page has the following notation:

The functionality in a client page can be programmed in either VBScript or JavaScript. Any scripting here is strictly client−side. For example, the client page may format some text on the screen.

Client pages do have access to any resources available on the client. These resources could include:

∙

ActiveX controls, which are components based on the Microsoft COM model, that are downloaded to the client machine.

∙

JavaScript objects, which could be objects provided by the document object model, such as window, frame, document, image, etc. These could also be custom objects defined by the programmer. These custom objects can be assigned their own attributes and operations, but are not reverse engineered into Rose.

∙

Java applets, which are components that, like ActiveX controls, are downloaded to the client machine and run on the client.

Typically, you use these three types of components to add complex functionality to the client. HTML will give you some flexibility, but it is frequently not sophisticated enough to program complex client−side behavior.

ActiveX controls and applets can be modeled in Rose as classes or components with the stereotype of <<ActiveX>> or <<Applet>>. Because a component may consist of several classes, you can simply model an ActiveX control or applet in the Component view. If you want to model the classes within a component or show the relationships between your classes and the component, you can model the control or applet as a class in the Logical view as well.

To add a client page:

1.

Right−click the virtual directory in the Logical view.

2.

Select Web Modeler → New → Client Page.

3.

Enter the name of the new page.

660

Chapter 19: Web Modeling

OR

Create a server page using the method described in the following section, "Server Pages." A client page will automatically be created for each server page you create using this method.

In the specification for the client page, you can set detailed attributes for the client page. Table 19.1 lists the attributes and their meanings:

Table 19.1: Client Page Attributes

Attribute	Specification Window	Meaning
	Tab
Alink	General	Link color
Background	General	URI to background image
BgColor	General	Background color
BottomMargin	General	Bottom margin in pixels
Class	General	Class name for element
Dir	General	Text direction for element
ID	General	Element name
Lang	General	Language of element's content
LeftMargin	General	Left margin in pixels
Link	General	Text color of links
MarginHeight	General	Frame margin height in pixels
MarginWidth	General	Frame margin width in pixels
RightMargin	General	Right margin in pixels
Style	General	Style information for element
Text	General	Text color
Title	General	Additional element information
TopMargin	General	Top margin in pixels
Vlink	General	Link color for visited links
OnLoad	Events	Process to run on loading the page
OnUnload	Events	Process to run when unloading the page
FileName	RTE Options	Name of physical file for page (ASP, JSP, HTML)
RTESynchronization	RTE Options	Whether or not to generate code for this page
Server Pages

Server pages are objects that have access to the resources available on the server. For example, if some security processing needs to take place, a server page would communicate with various components on the server to perform that processing. Separating the application into client pages and server pages helps to separate the presentation logic from the business logic, which aids in both maintenance and reuse. In Rose, a server page has the following notation:

661

Chapter 19: Web Modeling

Unlike a client page, a server page has full access to the server's resources. It can communicate with the objects on the server to carry out business functionality, and then build client pages to show the results of the processing to the end user. One server page can also redirect control to another, allowing the second server page to take over processing.

To create a server page:

1.

Right−click the virtual directory in the Logical view.

2.

Select Web Modeler → New → Server Page.

3.

Enter the name of the new page.

Rose will create the server page, and will also automatically create a client page for you. The client page handles the client−side functionality, such as display logic. The server page handles the business processing and builds the client page. Rose will also automatically add a build relationship between the server page and the client page. We will discuss relationships shortly.

In the specification window for the server page, you can set the following two values:

∙

File Name is the physical name of the page (ASP, JSP, or HTML).

∙

RTE Synchronization controls whether the page will be generated or not.

Forms

Forms are simple HTML pages that contain text boxes, list boxes, and other data input controls. The purpose of a form is simply to receive information from the end user and to display information to the end user. Business logic is not included on a form.

A client page may contain one or more forms. Each form on a client page is associated with that page using an aggregation relationship. Fields on the form are modeled as attributes of the form, and are given the stereotype HTML Input. In Rose, the following symbol is used to represent a form:

To create an HTML form:

1.

662

Chapter 19: Web Modeling

Right−click the client page on which the form is to be located.

2.

Select Web Modeler → New → HTML Form.

3.

Enter the name of the new form.

Like client pages and server pages, forms have detailed specifications that will be used during the code−generation process. Any values that you set on the General tab will appear in the generated HTML. Table 19.2 lists the specifications for the HTML Form stereotype, and the purpose of each specification.

Table 19.2: HTML Form Attributes

Attribute	Specification Window	Meaning
	Tab
Action	General	Form−processing agent
Class	General	Class name for element
Enctype	General	Content type used to encode the form's data
ID	General	Element name
Lang	General	Language of element's content
Method	General	HTTP method to submit form's data
Style	General	Cascading style sheet for element
Target	General	Name of frame target
Onblur	Events	Process to run when element loses focus
Onclick	Events	Process to run on mouse click
Ondblclick	Events	Process to run on mouse double−click
Onfocus	Events	Process to run when element gains focus
Onkeydown	Events	Process to run when a key is pressed down
Onkeypress	Events	Process to run when an alphanumeric key is pressed
Onkeyup	Events	Process to run when a key is released
Onmousedown	Events	Process to run when the mouse button is pressed
Onmousemove	Events	Process to run when the mouse moves
Onmouseout	Events	Process to run when the mouse cursor is moved off of the
		element
Onmouseover	Events	Process to run when the mouse cursor is placed on the element
Onmouseup	Events	Process to run when the mouse button is released
Onreset	Events	Process to run when the form is reset
Onsubmit	Events	Process to run when the form is submitted
RTE Synchronization	RTE Options	Whether or not to generate the element
Resolve Relative	RTE Options	Automatically resolve paths in referenced files(Note: Setting
Paths Dynamically		this field to Default will set it to True/False, depending upon
		what is set in Tools → Web Modeler → User Preferences.)

An HTML form is really just a collection of input fields. Rose supports three types of input fields: an HTML

663

Chapter 19: Web Modeling

Input, an HTML Select, or an HTML TextArea. Once you have added a form, you can add more input fields using Web Modeler.

An HTML Input is a field on the form. It can have one of these types: text, password, check box, radio, submit, reset, file, hidden, image, or button. The HTML input will be modeled as an attribute of the form.

To add a new HTML Input field:

1.

Right−click the HTML form.

2.

Select Web Modeler → New → HTML Input.

3.

Select the type of input (text, checkbox, etc.).

4.

Enter the name, ID, and value of the input.

5.

Select OK to create the new input.

6.

Right−click the new input.

7.

Edit the input specifications, event handlers, and round−trip engineering options on the specification window.

This HTML input will be generated in the code as follows:

<input ID="PWD" Name="PasswordBox" Type="password">

An HTML Select is a select box field. The select box has a list of values, and allows the user to select one or more of the values in the list.

664

Chapter 19: Web Modeling

To add a new HTML Select field:

1.

Right−click the HTML form.

2.

Select Web Modeler → New → HTML Select.

3.

Enter the name and ID of the field.

4.

Select OK to create the new field.

5.

Right−click the new field.

6.

Edit the field specifications, event handlers, and round−trip engineering options on the specification window.

The field will be generated in the code as follows:

<select ID="1" Name="HTMLSelect"> </select>

An HTML TextArea is a multi−line text field on an HTML form. These fields can be used any time the user needs to enter long strings of text. Using the attributes associated with the field, you can set the number of lines that will display on the text area, whether the text area is editable, the tab index for the control, and other properties.

To add a new HTML TextArea field:

1.

Right−click the HTML form.

2.

Select Web Modeler → New → HTML TextArea.

3.

665