Analysis

Analysis and design activities help transform the requirements of the system into a design that can be realized in software. Analysis and design can be done separately or combined as part of one set of activities. Use case analysis comprises those activities that take the use cases and functional requirements to produce an analysis model of the system (Figure 10-1). The analysis model is made up of classes and collaborations of classes that exhibit the dynamic behaviors detailed in the use cases and the requirements.

Figure 10-1. Analysis team activities and artifacts

The model represents the structure of the proposed system at a level of abstraction beyond the physical implementation of the system. The classes typically represent objects in the business domain, or problem space: shopping cart, order, line item, product, and so on. Ideally, the level of abstraction is such that these same classes could be applied equally to architectures other than Web applications; however, in practice, some alterations are always necessary. Important processes and objects in the problem space are identified, named, and categorized during analysis.

Analysis focuses on the functional requirements of the system, ignoring for the moment the architectural constraints of the system. The emphasis is on ensuring that all functional requirements, as expressed by the use cases and other documents, are realized somewhere in the system. Ideally, each requirement item and use case is linked to the classes and packages that realize them. This link is important in establishing the traceability between requirements and use cases and the classes that will realize them.

Use case design, on the other hand, is primarily a refinement of the analysis model. Design activities use the nonfunctional requirements of the system and the constraints of the architecture to refine the analysis model into something that can be coded. The designer must take into consideration that nothing happens in zero time, that computers have limited memory, and that things can go awry. The designer is often the pragmatist of the team.

When done as separate activities, two models are produced: an analysis model and a design model. Because the analysis model is a direct-input design, either it can be kept as a separate model and maintained separately, or it can evolve into the design model.

A separately maintained analysis model is useful when the system is being designed for multiple target architectures. If the system is very complex, the additional abstraction layer provided by a discrete analysis model may be useful in understanding the system. It is especially useful for answering some of the "why did we ever do it that way?" questions that always seem to pop up late in a project.

The benefits of a separate analysis model must be weighed against the cost of maintenance. Often, the design activities and the realities of software development change things so they can be realized in software. Design activities almost always drive the evolution of the system's model away from the idealized analysis view. Maintaining the analysis model means evolving it with the design model. Eventually, the finer details of the analysis model will be lost, so even if it is maintained, it is best to keep only the most important domain classes and relationships. Once the analysis model becomes significantly out of sync with the design model, its usefulness is limited.