Java Development News:

Developing Applications with J2EE & UML

Most J2EE projects I run across today have little in the way of analysis and design deliverables to show how they got where
they are. The whole endeavor lacks the ability to be tracked; that is, it lacks traceability. In this article, I present
the Use Case pattern as a mechanism to improve a projects chances of hitting its delivery goal, but more importantly, as
a mechanism that establishes a sound architecture that is much more accommodating to future change. The Use Case pattern
provides J2EE applications with more insight into how new applications, and modifications to existing applications, will
affect such things as the selection of the type of EJB component and the ramifications to existing transaction boundaries.

When we hear the word pattern, it is usually in the context of design patterns. However, design patterns are typically
used in a tactical sense, attending to one vertical challenge of the application. The important question to ask is how can
patterns be applied in a strategic sense, taking into consideration all the aspects of a projects lifecycle? For instance,
little is provided in the way of patterns that focus on the testing aspects of the project. An even larger gap that is
created in the rush to the design pattern is the projects inability to absorb future change. For instance, if the
application needs to change, either during development or after the move to production, how does the team trace the
effects both forwards and backwards? Fine-grained design patterns just dont get their maximum benefit unless a super
pattern for the entire project is brought into focus at the same time.

The Use Case Pattern is a super pattern that encourages project teams to recognize the needs of all the players on the
project and more importantly, to instill traceability as a key goal of all deliverables. The Use Case Pattern relies on
three artifacts that the UML offers : the Use Case, Class, and Interaction Diagrams. Diagrams in and of themselves are
useless without some level of additional support material. This is especially true of the Use Case diagram, whose worth
would be suspect without the support of an accompanying template.

Use cases represent the uses of the application. Use cases are coarse-grained and if presented with one, the user will
tell you they represent major categories of functionality. As an example, Take Orders is a use case in an online shopping
cart application. However, Verify Customer Number is merely a step in the course of some pathway in that use case and is
not a use case in its own right. A use cases template then,describes several pathways through a use case. These pathways
can range anywhere from the happy path, or the most commonly occurring pathway, to alternate pathways, and of course
exception paths, or as one of my clients calls them crappy paths. Figure 1 provides a brief view of a use case diagram
and its happy path. We can also make the bold statement that every single pathway is testable. Quite early in the inception
phase of the project, the testing team can create test cases, or use case scenarios, to exercise every pathway in an
application.

Figure 1 Use Case and Happy Path

Most software engineers today know the purpose of the class diagram. Classes represent both the structure and behavior of
some collection of real-world entities in the system. The UML defines three types of classes: boundary, control, and
entity. Most classes in an application, particularly the entity classes, are found directly in the use cases. However,
as we shall see in a moment, the use case is also a key source of both the boundary and control classes as well.

The UML offers two forms of interaction diagrams: the sequence diagram and the collaboration diagram. It is important to
state early in the discussion of interaction diagrams that they are design models of the pathways through the use cases.
They represent objects bubbling with excitement, sending messages to one another to satisfy the ultimate goal of the user.
From the UML diagrams described so far, traceability is afforded both forward and backward. If requirements change, we start
with the use case and assess the impact on the remaining two diagrams.

So what does all this have to do with Java? This is where the architectural aspect of the use case pattern comes into play.
One might still get the diagrams right but quite often when I go into a client project, there is still no bridge between
what the diagrams describe and the code. At this point, the diagrams become dead, lifeless hulks of some previous view
of the application. What follows in the remainder of the article are the pieces that tie the applications deliverables
in the analysis and design portion of the application to what we deliver in the form of code.

First, every use case the application defines will have an associated use case control class created for it. Control
classes act as coordinators of activity. Others have also suggested this approach as a means to limit access to the internal
workings of the application as well as a way to reduce network chatter. Second, every happy and stand-alone alternate path
in that use case will have a corresponding operation defined in its related use case control class. The method implementing
the operation will directly manage the messaging defined in its corresponding interaction diagram (sequence/collaboration).
Exception paths are usually dealt with within the course of some other pathway. The same is true for variation paths, which
are alternate paths that dont stand on their own, but are merely left or right turns along the course of some other
pathway.

In the EJB world, these use case control classes are implemented as Session Beans. Depending on the nature of the use case,
the session bean may be either a stateless session bean (SLSB) or stateful session bean (SFSB). If you follow the suggestion
of Tyler Jewell in his excellent article Stateful Session EJBs: Beasts of Burden
http://www.onjava.com/pub/a/onjava/2001/10/02/ejb.html , one would hope they would all be SLSB. Each use case session
bean will have a corresponding operation as described above which implements the messaging defined in its corresponding
interaction diagram. Most of the messaging within the use case operations will be directed at entity beans. However, it
could be directed at other session beans as well, particularly if you have includes relationships between use cases.
In the non-EJB world, all the classes referred to are simply Java Beans. However, the architecture is identical.
Figure 2 provides an overview of the traceability afforded by the Use Case pattern.

Figure 2 Mapping of Components using the Use Case Pattern

As Figure 2 shows, there is an order to the progression of mapping to components: (1) From use-cases we find our entity
classes (2, 3). (4) From the use-cases we create interaction diagrams (e.g., sequence/collaboration) that model our classes
now acting as living objects sending messages to one another with the sole purpose of accomplishing the goal of the
use-case pathway. (5) For each use-case, a use-case controller will be implemented as either an SFSB or an SLSB. This
use-case controller bean will contain operations that implement the orchestration logic to carry out an individual
interaction diagram. Again, these map directly to the use-case pathways.

This pattern also quite successfully predicts how transaction boundaries are distinguished. Many times I see projects
struggle with where to place the logic that controls the boundaries for the pathways through the application. With the use
case pattern the guesswork is removed. All transaction demarcation occurs within the use case control classes, ALWAYS. In
the case of EJB applications, each method within each use case session bean is assessed as to its need for a transaction.
All update-oriented operations in the session beans will be marked RequiresNew. All other operations in the session beans
will be marked Supports. All entity beans can be marked at the bean level as Supports.

Right away, without going any further, we have some awesome traceability going for the project team at this point. New
requirement? Find which use case the requirement belongs to (perhaps it is a new pathway or a variation on an existing
pathway), find its owning use case control class and related operation which houses the messaging for the pathway and
assess the impact. This is where the leap over the wall usually happens in most architectures I run across. There may
be use cases defined for the project but the resulting code implementing the behavior has absolutely no traceability back
to the use case. In this approach, everything bridges back to the use case What a novel idea, actually tying code back to
the reason were building the code in the first place. This way, the test team knows the impact on their test plans and
even the users know the impact on any training documentation or procedure manuals they might be creating.

The good news isnt over yet. What about the externalization of what the use case pathways represent? If we have a pathway
through the Order Inquiry use case, where do we describe what the results look like? One requirement may demand the
result be delivered as an HTML page. Another requirement might also require it be rendered on a cell phone or PDA device
using Wireless Markup Language (WML). The inner workings of the use case control class method which implements the
interaction diagram for the order inquiry pathway should be void of any display logic. It should function the same
regardless of what its ultimate destiny may be. This is where the notion of the use case realizations comes into play.

A use case realization can be thought of as an instance of a use case pathway which considers its unique rendering
requirements. For both the HTML and WML implementations, there is an interaction diagram that deals with its unique user
interface requirements. However, both the HTML and WML requirements would utilize the services of the sequence diagram
implemented in the use case control class that just deals with returning a value object back to the order information.
How we choose to render the result is done in both a user interface boundary and a control class. In the Java world
(regardless of EJB/non-EJB status) this is accomplished using two architecture components: A Servlet that initially
intercepts the client request (control) and a Java Server Page (JSP) to render the output back to the client (boundary).
Using custom tag libraries, a JSP page would format WML back to the PDA device and yet a different JSP page would format
HTML to the browser. Figure 3 shows a UML component diagram outlining the different components working together.

Figure 3 UML Component diagram with the Use Case pattern

The use case pattern provides a framework that serves the needs of many project participants. It provides a basis for all
project communication regardless of the lifecycle phase of the project. Of premier importance is the traceability it
provides the project. Impact analysis due to change is built into the application by virtue of its architecture. When
to use session beans is now quite clear. The operations in the session beans are also direct decendents of the interaction
diagrams created during design. EJB transaction definition decisions become less of an issue because all work begins with
the session bean acting in the role of use case controller. The application also benefits from a more agile use of the UML,
focusing in on those key artifacts that provide the application the biggest bang for their buck. The use case pattern can
go a long way towards providing more predictability to not only the end result of a project deliverable, but also to the
ability of the application to discover, assess, and absorb future change.

This article is a synopsis of the topics covered in the book, "Developing Applications with Java and UML" published by Addison-Wesley (Nov 2001) by Paul R. Reed, Jr. Paul is president of Jackson-Reed, Inc. (www.jacksonreed.com), a training and consulting firm that focuses on the implementation of Object-Oriented and Distributed systems for clients in the United States, Europe, Asia, and the Middle East. Reach Paul at prreed@jacksonreed.com.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.