The technical architect is typically responsible for leading the application design process. In this role, the architect is as much a facilitator as an application designer. This chapter shows you ways to utilize use-case analysis along with the layered approach described in the previous chapter to construct effective designs for J2EE applications and document them in an object model. Along the way, I'll share some techniques for leading a group design process.

Finished use cases are essential for effective application design. Without them, the object-modeling sessions will produce more questions than answers. If you do find vague points or unaddressed issues in the use-case documentation, apply the technique of making assumptions to fill the gaps. Document the assumptions you make so you can confirm them with the business side later. Your use-case analysis is more likely to be incomplete when you're working on a large project.

Object-modeling exercises are applicable for the Java portions of a J2EE application that are custom written (e.g., not provided by a software vendor). Modeling of third-party software components should be limited to those classes directly called by your application.

The technical architect is responsible for facilitating design discussions, which should involve the business logic and presentation-tier developers in the design process. Because of its subjective nature, the object-modeling process can be a large source of frustration and a project bottleneck. I've seen some projects where the architect produces the object model privately and then attempts to coerce other developers to follow. Although a lone modeler may be able to produce an object model more quickly than a team, the model is more likely to contain errors and omissions, and only the architect understands and is loyal to it.

When the model is produced privately, it doesn't get substantive developer support. After all, if developers can't understand or agree with a plan, they certainly won't want to follow it. Many developers react to architect-produced models by ceasing to contribute anything meaningful to the project from that point. The architect may want to "draft" a model as a way to move the design process along, but developers should clearly understand that this draft is presented solely to prompt discussion and is entirely subject to change.

As a practical matter, when I need to get meaningful support from multiple developers, I go through the longer exercise of forming the plan collectively. Developers who have had input to a model and repeated opportunities to suggest enhancements to it are going to be more enthusiastic about implementing it.

Appoint a scribe for all modeling sessions. It's difficult to facilitate design sessions and take accurate and complete notes of the items discussed at the same time. As the architect is usually leading the session, one of the developers should act as scribe, perhaps on a rotating basis. After the design session, the scribe is responsible for updating the object model to reflect changes discussed in the session.

The remainder of this chapter presents a framework you can use to guide development staff through the object-modeling process. The first step in the process is to identify the major objects in your application using the use cases as a guide. Next, you refine these objects into classes, determine how they interact, and identify attributes and methods. Throughout the chapter, I show you how to streamline the process and avoid those annoying bottlenecks.