Guidelines: Building Web
Applications with the UML
Topics
The following books and documents are references for these guidelines:
The thing that is different compared to what you find in Activity:
Use-Case Analysis is that the boundary classes are more focused and singular
in purpose. Objects of these classes have a short life, and any client state (in
web pages) needs to be managed explicitly by specific mechanisms. For example,
Microsoft Active Server Pages use "cookies" as an index into a map of
the state of all the currently active clients.
Also, when you read the specification of a use case, the following
applies:
- Any mention of a web page translates to a boundary class.
- Any mention of a hyperlink translates to an association from a boundary
class to another boundary class or controller class.
- Verbs or descriptions of processes tend to map to controller
classes.
- Nouns map to entity classes.
The boundary class, through which communication is initiated, talks to a
controller class. The controller class typically will not respond back through
the same instance of this boundary class.
As use-case analysis is going on, the scenarios can be described with
sequence diagrams. This helps validate the existence of analysis objects against
a scenario of a use case. If analysis objects are discovered not to participate
in any of your scenarios, they are suspect and need to be reevaluated. The risk
here is that if you go too deep in detail, the diagrams become large and
unmanageable. To avoid this, concentrate on short discrete scenarios, and only
include boundary and principal controller and entity objects.
Remember that in web applications boundary objects have a short lifespan. A
boundary class may however be instantiated several times during the execution of
a scenario, meaning that there are several boundary objects instantiated from the same class
in the diagram.
The actor in an analysis level sequence diagram interacts with a boundary
object. A navigate message is sent from the actor to the boundary object.
Initial Boundary Class Designs
A boundary class can be mapped to a client page class.
If the boundary class involves inputting information, you would typically
associate it with a form (or web form) through aggregation. A form can be
modeled as a nested class of the client page, since its entire lifecycle is
governed by the client page. Forms always have a submit relationship to a server
page, which processes the form's values, ultimately leading to a new returned
client page.
If the user interface requires some dynamic behavior on the client, the
easiest way this can be accomplished is through the use of dynamic HTML on the
client. In the design model, this usually appears as operations on the client
page. Operations on the client page map directly to java script functions.
Attributes of a java page map directly to page scoped variables of the page.
Dynamic HTML event handlers are captured as tagged values.
If the user interface has very sophisticated behavior, you would consider
associating an applet with the boundary class, using an aggregation.
If your architecture is based on a distributed object system (such as RMI,
IIOP, or DCOM), then the client page may reference interfaces to components that
communicate directly with the server using RMI, IIOP, or DCOM, circumventing
HTTP. These types of relationships are usually stereotyped <<rmi>>, <<iiop>>, or
<<dcom>> to indicate to the designer any areas where network traffic will
happen, thus being candidate bottlenecks.
Initial Entity Class Designs
In designing a web application, the only thing different about entity classes
is, if the object resides within the scope of the client page, the entity object
will map to a java script object.
Initial Controller Class Designs
Control classes map to server pages. Controllers express and coordinate the
business logic, and coordinate other logics. They typically reside on the
server. Many controller objects are responsible for building client pages
(essentially, they stream HTML as their principal output). Controller objects
can interact with server-side resources, such as databases, middle tier
components, transaction monitors, and so forth.
Controller classes typically map to server-side scripted web pages (active
server pages, java server pages).
|