Object‐Oriented Analysis

AbstractObject‐oriented analysis is a method of formulating a model of a desired software system in terms of objects and their interactions. The discipline was started by practitioners of object‐oriented design who found that conventional process‐oriented analysis methods, such as structured analysis (Gane and Sarsen, 1987; DeMarco, 1979) or SADT (Marca and McGowan, 1987), did not flow well into an object‐oriented design. The difficulties in proceeding from structured analysis to object‐oriented design stem from differences in the criteria for decomposing a system into subsystems and lower level components. Converting a process‐oriented decomposition—the result of a structured analysis—into an object‐oriented decomposition frequently requires a great deal of reorganization. [An early example of this may be found in Section of Seidewitz and Stark 1986]. Object‐oriented analysis seeks to decompose a system into interacting parts that represent the user's requirements as faithfully as conventional analysis methods, but to do so in a way that is compatible with object‐oriented design.Compatibility with object‐oriented design was intended to facilitate the transition from the analysis to the design phase. Whether it really does so is a topic still being debated. At the very least, formulating requirements in terms of objects provides a sound basis for the transition to design. It also simplifies the traceability of requirements throughout the development life cycle, and therefore reduces the disruption involved in iterating over analysis and design (i.e., backtracking to the analysis if the design implications are discovered to be infeasible).Historically, OOA arose for these reasons. Some proponents of the approach argue that the object‐oriented framework provides a more robust and accurate description of user requirements than do the conventional approaches, and is therefore to be preferred intrinsically over process‐oriented analysis.