【正文】 on of current OO analysis methods reveals that: ? The creators of a method usually express only a weak preferences for the sequence in which models are developed. ? There is as yet no consensus about the process. ? There appear to be two clusters of approaches: (1) Early characterization of the static dimension by developing a vocabulary in terms of classes, relations, etc. (2) Early characterization of the behavioral dimension, the systemcontext interactions. We have similarly adopted a weak bias. Our presentation belongs to the cluster of methods that focuses on the static dimension first and, after having established the static models, gives attention to the dynamic aspects. However, this position is mutable if and when necessary. For instance in developing large systems, we need topdown functional depositions to get a grip on manageable subsystems. Such a deposition requires a preliminary investigation of the dynamic realm. Chapter 9 (Ensembles) discusses these issues in more detail. A prescribed sequence for analysis is given via an example in Chapter 10 (Constructing a System Model). A formalization of this ``algorithm39。 emphasizes the notion as a noun phrase. The dynamic row indicates that some form of state machinery is employed to describe the behavior of a prototypical element of a class . Multiple versions of causal connections capture the ``social39。 and ``relationship39。. We do not ascribe to these distinctions, at least at the analysis level. Our definition of objects makes them all active, as far as we can tell. This active versus passive distinction seems to be more relevant for the design phase (cf., Bailin ). This notion of objects being active is motivated by the need to faithfully represent the autonomy of the entities in the ``world39。s operator descriptions. We will stay away from procedural characterizations in favor of declarative ones. Active Objects Some OO analysis methods have made the distinction between active and passive objects. For instance Colbert defines an object as active if it ``displays independent motive power39。s eye view definition is that an object is a conceptual entity that: ? is identifiable。39。39。39。. He gives examples of multiple what/how layers that connect all the way from user needs to the code. We will follow a few steps of his reasoning using the single requirement from our ATM example that clients can obtain cash from any of their accounts. 1. Investigating the desired functionality from the user39。 we have ``One person39。 is remended. A minianalysis and minidesign for such a prototype can prevent rampant throwaway prototyping. Models Most attention in the analysis phase is given to an elaboration of functional requirements. This is performed via the construction of models describing objects, classes, relations, interactions, etc. Declarative Modeling We quote from Alan Davis : A Software Requirements Specification is a document containing a plete description of what the software will do without describing how it will do it. Subsequently, he argues that this what/how distinction is less obvious than it seems. He suggests that in analogy to the saying ``One person39。39。. ? A requirements document may propose construction of a line of products rather than one system in particular. This represents a request for an OO domain analysis. Domain analysis specifies features mon to a range of systems rather than, or in addition to, any one product. The resulting domain characterization can then be used as a basis for multiple target models. Domain analysis is discussed in more detail in Chapter 13 . Until then, we will concentrate most heavily on the analysis of single target systems. However, we also note that by nature, OO analysis techniques often generate model ponents with applicability stretching well beyond the needs of the target system under consideration. Even if only implicit, some form and extent of domain analysis is intrinsic to any OO analysis. Across such scenarios we may classify inputs as follows: Functionality: Descriptions that outline behavior in terms of the expectations and needs of clients of a system. (``Client39。 seldom means that the specification is really plete. ``Obvious39。. In this case, the requirements are most likely highly inplete. The characterization of the ATM system in Chapter 1 is an example. The notion of a bank card (or any other technique) to be used by a customer for authentication is not even mentioned. In this case, elaboration on the requirements is a main goal. Intensive interaction between analyst and client will be the norm. ? In the ideal case, a document may present a ``totally39。s at GTE, TRW and IBM regarding the costs to repair errors made in the different phases of the life cycle. As seen in the following summary table, there is about a factor of 30 between the costs of fixing an error during the requirement phase and fixing that error in the acceptance test, and a factor of 100 with respect to the maintenance phase. Given the fact that maintenance can be a sizable fraction of software costs, getting the requirements correct should yield a substantial payoff. Development Phase Relative Cost of Repair Requirements Design Coding 1 Unit test 2 Acceptance test 5 Maintenance 20 Further savings are indeed possible. Rather than being aimed at a particular target system, an analysis may atte