Chapter 6: Classes and Packages

To add an instantiated class utility:

1.

Select the Instantiated Class Utility button from the toolbar.

2.

Click anywhere inside the diagram to place the new class.

3.

Type the name of the class.

OR

1.

Add a class to a Class diagram or to the browser using one of the methods listed above.

2.

Open the class specification window.

3.

In the Type field, select InstantiatedClassUtility.

4.

Click OK.

OR

1.

Select Tools → Create → Instantiated Class Utility.

2.

Click anywhere inside the diagram to place the new class.

3.

Type the name of the class.

Interfaces

One guideline in object−oriented programming is to separate the implementation of a class from its interface. Most object−oriented languages now support the concept of an interface, which contains only the method signatures (without the implementation) for a class.

For example, we may have a class that deals with security. It has methods called CheckID, CheckPassword, and LogSecurityViolation. The CheckID operation takes the user ID as a parameter and returns a Boolean signifying whether or not the ID is valid. CheckPassword takes the password entered by the user and also returns a Boolean. LogSecurityViolation takes no parameters.

224

Chapter 6: Classes and Packages

Various pieces of the system will need to call the CheckID operation, for example. The typical approach is to create a class, which we'll call SecurityImplementer, that contains all three of the security methods as well as code to implement the functions.

One option is to allow the rest of the system to directly call methods of the SecurityImplementer class whenever they need security functionality. A problem could occur, however, if the Security−Implementer class changes. What happens if we change the way that the methods work or if we want to replace our C++−based security class with a Java−based security class? There could be ripple effects throughout the system.

So rather than take this approach, we create the SecurityImplementer class with its methods and their implementations, but we also create a SecurityInterface class, which holds only the operation signatures. Other classes will reference the interface rather than the implementer class so that if the implementer needs to change, the rest of the system won't be affected.

This concept has been used as the basis for interface definition language (IDL), which allows you to define language−independent interfaces. In Rose, an interface is modeled as a class with a circle icon, which is often called a "lollipop," as follows:

Web Modeling Stereotypes

One of the new features in Rose is the support of web modeling stereotypes. Using this feature, you can more thoroughly describe the structure of your web applications, labeling which classes in the model correspond to client pages, server pages, applets, session objects, or other web constructs.

Note You can read more about this topic in Chapter 19, "Web Modeling."

In this section, we'll briefly discuss each of the stereotypes available in Rose Web Modeler. If you are using these stereotypes, you may first want to customize the Class Diagram toolbar to be able to see buttons for these. To do so, open a Class diagram and right−click the Class Diagram toolbar. Select Customize, find the web stereotype buttons, and then add them to the toolbar.

Many of these stereotypes have their own symbols on a Class diagram. In Rose, you can view the classes with their symbols by right−clicking the class and selecting Options → Stereotype Display → Icon. To switch back to stereotypes with text labels instead, select the Label option.

Note If you have changed the stereotype display to Icon but you're still not seeing the symbols, be sure the default language on the Notation tab of Tools → Options is set to Web Modeler before you create the classes. If the classes are already created, be sure they are mapped to a component whose language is set to Web Modeler (see Chapter 10, "Component View," for component mapping).

Client Page

A client page is an HTML−formatted page that is displayed on the client machine by a web browser. A client page may have some embedded logic with JavaScript or VBScript, but typically will carry out only user interface logic. In most situations, business logic should, whenever possible, be carried out on the server.

In Rose, a client page is modeled with the following symbol:

225

Chapter 6: Classes and Packages

Server Page

A server page is a page that is executed on the server and typically carries out business, rather than user interface, functionality. The server page can communicate with the resources available on the server, such as the database, other server pages, and business objects. The separation between client and server pages helps the team to separate the business logic from the user interface.

In Rose, a server page is modeled with the following symbol:

Form

A form is a simple HTML page that doesn't do business processing. It exists only to display information to the end user and to allow the end user to enter some information in simple fields. Once the user enters the information, the form passes control to a server page, which carries out any business logic in response to the information on the form.

On a Class diagram, a form looks like this:

Application

One of the challenges in web programming is the inability to keep track of the client's state. In other words, once a client has made a request to the server and the server has processed the request, the server does not keep track of where the client is or what it is doing. If the client needs something else, it needs to establish a new connection to the server and send a new request.

When using Active Server Pages (ASP), an application object helps with this problem. It allows the server to keep track of some information across all of the clients that are currently using the system. All clients share

226

Chapter 6: Classes and Packages

the same application object.

In Rose, an application object is modeled as a class with a Web Application stereotype:

Applet

An applet is a Java construct. It is a (typically small) compiled program that is downloaded to the client and runs on the client machine. Applets are frequently used to add some functionality to the user interface that is not generally available. Although ActiveX controls serve the same purpose, they are not currently supported by all browsers.

Applets are shown on a Class diagram with the following symbol:

Session

Session objects exist for largely the same reason as application objects. The difference is that while all clients share the same application object, a session object is unique to a particular client. It allows the server to keep track of what the client is doing and what it has requested in the past—in other words, the state of the client.

A session object is modeled as a class with a Web Session stereotype:

COM Object

The COM object stereotype is used to model ActiveX components. Although not all browsers currently support ActiveX, there are a number of ActiveX controls in use today (and more are being created all the time!). As long as you know that your clients are running Microsoft's Internet Explorer or another browser that supports ActiveX, you can use these controls to enhance the user interface. Like applets, ActiveX controls run on the client machine.

COM objects appear on the Class diagram with the following symbol:

227