The following books and documents are references for these guidelines:
The thing that is different compared to what you find in Task: 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).
|