Software Engineering, Page 015

III. Analysis

Capturing requirements is an activity that involves close interaction with the software system's customer. During this activity the system must be described in language that is comfortable to the customer. In contrast, during analysis, the developers are free to view the system in terms with which they are comfortable. While still largely interested in behavioral aspects of the system, and not implementation details, the developes do begin to conceptualize component parts of the system, and the interactions among these.

The analysis model is meant to bridge the gap between gather requirements from the customer and designing a system that can be implemented. It does so by:

moving away from the customer's view of the proposed system and the need to discuss the system only in terms that are familiar to the customer;
imposing more rigor, thus addressing issues of requirements consistency and completeness;
affording the customer a new way to view the system, potentially contributing to requirements validation (the customer might be interested in and willing to view the analysis model, which though alien to the customer, is conceptual and not so detailed as the design will be);
introducing objects and a minimal model to help initiate the design process. (The final design might bear little similarity however.)

A. Conceptual objects

In object-oriented analysis (OOA), conceptual objects are introduced to describe a conceptual system that has the functionality required by the actual system to be developed. These objects may very well correspond to actual software objects in the final code, but this is not necessarily the case. For example, one object in the analysis model might later correspond to a module in the design containing multiple objects. It could also happen that an analysis object has no counterpart in the design.

The convensional strategy for OOA, due to Jacobson and now Rational's Unified Software Development methodology, is to separate objects into three types: boundary, entity, control. The interactions between these objects is normally only described in a somewhat sketchy way, certainly as compared with the object interactions that must be detailed during the design activity. We are concerned about the nature of the information communicated between analysis object, but not the specific details (ordinarily).

1. Boundary objects

Boundary objects represent things through which actors and the system will be interacting. These would include buttons, forms, windows, keypads, terminals, computers, etcetera.

2. Entity objects

Entity objects tend to play a passive role as far as object-to-object interaction is concerned. They might for example, be just data repositories, i.e. complex data structures, used by other objects. However, like boundary objects, entity objects might correspond to real-world objects, but these would not be interfaces.

3. Control objects

As the name suggests, control objects are "take charge" objects. The are typically created dynamically for the purpose of orchestrating some specific task.

4. Object interactions

The recommended approach to Jacobson's OOA is to have objects interact in the following way:

Actors interact with boundary objects.
Boundary objects create control objects to coordinate some activities (and pass control). The control objects should be destroyed after they complete their tasks.
Control objects interact with other control objects and with entity objects. They might even create other control objects and entity objects.
Entity objects are passive. They do not initiate interactions.