Specifying and Visualizing J2EE Components with UML

With the introduction of the Java 2 Platform, Enterprise Edition (J2EE), Java has evolved into the language of choice for Web and component-based enterprise development endeavors. The sheer volume of technology offered by J2EE is exciting and at the same time staggering in its scope and applicability. However, it is important for you to recognize that J2EE is purely an application development specification consisting of technology components and services, and Java is its implementation language. For this reason, the success you derive from constructing and deploying your J2EE-based applications is governed by your software design process ”visually communicating requirements, initiating the optimal analysis and design decisions, and recognizing the best implementation choices.

This chapter's objective is to provide a very clear roadmap showing how you can leverage the Unified Modeling Language (UML) to develop a software design and realize the design as an enterprise Java application using the J2EE specification and associated J2EE industry best practices. In Chapter 3, "A Developer's Guide to the Unified Modeling Language (UML)," the features and structure of the UML diagrams and artifacts were presented. In this chapter you will apply that knowledge to create a model of an enterprise application that uses J2EE components and services.

The Need for J2EE Software Design

I couldn't wait for success...so I went ahead without it.

”Jonathon Winters

J2EE software design is an extremely coordinated and disciplined process that needs to occur well before any line of Java code is written. The objective is to create a visually clear blueprint (model) for the entire application so your business requirements semantically map to J2EE technology components and services in the most efficient, performance-oriented, scalable, and maintainable manner.

The effort that is put into the software design of J2EE applications, however, is slowly diminishing , not to the point of extinction , but to a point where the project can be at risk for not delivering the necessary levels of integrity, extensibility, and maintainability the business requires to have a reason to let the application evolve . Clearly, long before application deployment, these risks must be identified and understood to ensure that the correct solution is created. As covered in Chapter 3, the time to identify technological risks is during the project inception or the analysis of the requirements when the Use Cases are being defined.

Several influences within a project contribute to the lack of software design; you should immediately recognize and address influences such as

A general lack of J2EE software design experience within a project team.

Every project must have on board a technology architect and Java developers who understand what software design involves through experience. For instance, they must understand how to leverage the J2EE specification, component design patterns, and associated best practices of developing solutions targeted for a specific application infrastructure, such as the WebLogic Platform.
A lack of communication among the design team has wide- ranging negative ramifications .

Software design is a team effort in which all members of the development team should have input and a consensus understanding on the construction and deployment of the J2EE application. In a situation in which the design is articulated in a non-teamwork fashion, there is a risk that developers will not totally understand the rationale for some of the design decisions and, hence, may defer design flaws to a later point in time.
J2EE projects are, by nature, more focused on binary deliverables that can be showcased as quickly as possible to the end users and sponsors to show progress.

J2EE software design is not application development; it is a process that leads to the software engineering effort of an application that is compliant with the J2EE specification and associated best practices. In time-crunched and showcase-based projects, the software design process is typically replaced or bypassed with a development trial-and-error process, which eventually evolves into the software design of an application. In such an approach, thought is replaced with haste and the consequences lead to a fragmented approach to constructing the software that requires more effort and time to get right. Software design should be a process in which an application's design evolves through refinement, not through complete redesign.

Analyzing Requirements for a J2EE Solution with UML

Like any process, software design is only as good as the input it receives and the formula applied to it to develop the output (application design).

The Unified Modeling Language (UML) has achieved de facto status as the notation used by architects and developers to visually represent the classes, objects, messages, and interactions in an object-oriented system. The value of adopting this notation in your development shop is best described by the infamous saying "...a picture is worth a thousand words." A UML diagram is worth an exponentially larger number of words in terms of its capability to easily and effectively describe, in visual terms, the way a system works and how all the pieces fit together.

Another value is that, like Java, UML is language and platform neutral. However, it is possible to extract more value from UML because it provides the ability to stereotype and implement language-specific behaviors such as Enterprise Java Beans (EJBs) when you know the target will be a J2EE application.

The J2EE transition actually occurs very early in the software development process; for example, the relationships between Actors and Use Cases identify the required boundary interfaces. Identifying the boundary interfaces provides very significant information for selecting design patterns, which are discussed in the next section.

Using the UML diagrams and artifacts as your input, you can perform the following:

Evaluate the design to choose candidate technologies.
Evaluate the design to identify design patterns.
Create the user interface.
Create the Boundary and Support classes.

Several key items in a UML design model identify an enterprise solution. These items are found in the Use Cases, Activity diagrams, Class diagrams, and Deployment diagrams. In Class diagrams, the user and system interfaces are referred to as Boundary classes . You can check whether your Boundary classes evaluate to a J2EE solution by identifying the need for any of the following items:

Web browser user interface
Thin client
Persistence
Multi-tiered distributed system
Multiple clients

The design may be geared toward a particular technology. If the design model references a technology, such as an EJB, your job to choose a technology will certainly be much easier. If, on the other hand, it does not, you will have to evaluate the design model and research existing technologies to discover a match. The worst case scenario may lead you to writing a lot of code from scratch.