- Introduction
- The Architectural Process
- Project Communication and the Unified Modeling Language
- The Analytical Process, J2EE Style
- Use Case Analysis
- Managing Use Case Complexity
- Object Types
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Analytical Process, J2EE Style
There are a number of different analytical methodologies that could be applied to the development of a J2EE system and virtually infinite hybrids that could be developed to suit the needs or constraints of a particular project. But one of the more popular methodologies, and one that most projects will borrow from to some degree, is the Rational Unified Process (RUP). The following section provides a brief overview of this process and explains how it can be applied to the J2EE architectural process.
The RUP Phases
The RUP analytical process divides the software development lifecycle into several phases of development:
- inception
- elaboration
- construction
- transition
These steps are executed in order in a cyclical fashion. Each pass through these steps should result in a usable software product, but not necessarily a product that meets the full requirements of the system. Software development with RUP is like building a house, then adding a garage, then adding a pool, until at last you have the house you originally set out to build.
This iterative process is considered an evolutionary approach to software development. Each iteration results in improvements and a product that is one step closer to the goal of a complete system. Each phase in the process may also involve multiple iterations before they are complete.
The inception phase represents the starting block—the absolute birth of the project. It involves the articulation of the vision for the system and the establishment of a formal project to build the system. This should be something more than the good idea scribbled on the back of a dinner napkin. A clear vision should be expressed, a business case expressed, and the scope of the project defined. These work items will be the foundation for the next phase.
In the elaboration phase, the problem domain will be detailed and the scope of the project will be defined to greater detail. Both the functional and nonfunctional requirements for the system should be defined at this point. The nonfunctional requirements can be recast as critical success factors, which describe the degree of risk involved in the development of the system.
The end result of this phase is the baseline architecture of the J2EE system and a schedule for the production of the system. Described as a baseline architecture in RUP documentation, any changes made in the construction phase should be minor.
The construction phase begins by working out the details of the baseline architecture and producing a final architecture. As with other phases of the development, it is expected that the construction phase may involve multiple iterations.
During the transition process, the system is turned over to the end user. The end user may require training and may find bugs that need fixing. Several iterations may be required before the user signs off on the formal acceptance criteria for the system.
RUP Best Practices
RUP involves several guiding principals or best practices that tie in well with J2EE:
-
develop software iteratively.
-
manage requirements.
-
use component-based architectures (and technologies).
-
visually model software.
-
control the software change process.
Develop Software Iteratively
As differentiated from other software methodologies that preceded it, RUP does not require strict, sequential execution of steps, a waterfall approach. Such a process was seen as slow and ineffective. Instead, steps are executed as cycles with the completion of each step representing a generation. A generation includes a software release and its supporting documentation. The release may not be the completed concept, but it represents a useful product nonetheless. Through its life, a software product is expected to evolve and thus continue the cycle, creating successive releases.
Manage Requirements
As on any project of sufficient size, the requirements of the project must be managed. Though this is really more of a project management issue than an architectural issue, the technical architect is generally in a position to advise the project manager of "scope creep." Additional requirements that may appear trivial to management could have a serious, costly impact on a project's architecture, and the J2EE architect must manage these requirements by clearly articulating the cost and impact of such changes.
Use Component-Based Architectures (and technologies)
Though not particular to OO development, RUP has been used with success in the construction of component-based architectures. The complexity of component-based technology and OO technologies in general requires additional upfront analysis in order to create extensible, robust systems. Thus, component-based technologies benefit from the structured yet flexible RUP approach.
Visually Model Software
The role of the architect as a communicator involves communicating complex processes to less technical project team members. Communicating the complex components and component interactions of a J2EE system require that you use visual modeling techniques. The UML visual modeling language discussed in the preceding sections help facilitate this communication process.
Control the Software Change Process
Similar to the issue of changing requirements, the software change process can impede and slow the development of a system. As an architect, you must first understand and be able to predict (with reasonable accuracy) the impact of software changes on the system. You must then communicate this cost and impact to management.
J2EE Architectural Analysis
For purposes of our J2EE architecture, we do not need to complete the design process (in fact, we would not expect it to be complete), but we do need to have some idea of high-level requirements and components. This is what is referred to in RUP as the baseline architecture, an architecture that is further refined and is not completed until the construction phase. As we have identified throughout these first few chapters, we have a number of forces acting on the architectural design process as shown in Figure 3-10: J2EE Architectural process.
)
Figure
3-10 J2EE architectural process.
The analytical steps we would need to complete our initial architecture are as follows:
Gather initial requirements using use cases.
refine and clarify use cases.
identify top-level domain objects.
perform technology evaluations.
associate business domain objects with technologies.
create component diagrams and deployment diagrams.
As these steps indicate, initial requirements are gathered using use cases. Use cases are developed, clarified, and refined, and they ultimately lead to the identification of top-level domain objects. These business domain objects are essentially what will become the components—the servlets, JSPs, and EJBs—of the J2EE system being developed.
At this point we need to determine what technology to use for these components. We would then perform technology evaluations to determine appropriate candidate technologies for implementing these business objects. The end result is a set of services and business objects (or components) and associated J2EE technologies.
Finally, we take the services and associated components that we have identified and group them into packages. At this point we also need to indicate the hardware and software requirements of our system. The UML component and deployment diagrams help to visualize the potential deployments for J2EE components.
We would expect these steps to be completed in order. But as with RUP, we would also expect these steps to be repeated iteratively. Once again, architecture involves choices among alternatives, and as the development effort continues, choices will need to be made. Through the duration of the project, functional and nonfunctional requirements may change to reflect new priorities or altered project constraints; the architecture must respond to these changes. Each iteration of refining and improving the architecture will involve responding to this inevitable change and making the choices that need to be made.