See also section 3.7, the Annotated Bibliography, and APPENDIX D. The classified bibliography in [Booch 94] also contains entries on OOA(B), OOD(F) and OOP(G).
[Booch 91] "In OOA, we seek to model the world by identifying the classes and objects that form the vocabulary of the problem domain, and in OOD, we invent the abstractions and mechanisms that provide the behavior that this model requires."
[Coad 91] "OOA is the challenge of understanding the problem domain, and then the system's responsibilities in that light". "To us, analysis is the study of a problem domain, leading to a specification of externally observable behavior; a complete, consistent, and feasible statement of what is needed; a coverage of both functional and quantified operational characteristics (e.g. reliability, availability, performance)". "Design. The practise of taking a specification of externally available behavior and adding details needed for actual computer system implementation, including human interaction, task management, and data management details."
And on Domain Analysis:
"Whereas OOA typically focuses upon one specific problem at a time, domain analysis seeks to identify the classes and objects that are common to all applications within a given domain, [...]". - [Booch 91]
[The following quotes on domain analysis are from [Berard 93]]
"An investigation of a specific application area that seeks to identify the operations, objects, and structures that commonly occur in software systems within this area. - Dan McNicholl
"Systems analysis states what is done for a specific problem in a domain while domain analysis states what can be done in a range of problems in a domain. ...A domain analysis is only useful in many similar systems are to be built so that the cost of the domain analysis can be amortized over the cost of all the systems.
The key to reusable software is captured in domain analysis in that it stresses the reusability of analysis and design, not code. - Jim Neighbors
"The process of identifying, collecting, organizing, and representing the relevant information in a domain based on the study of existing systems and their development histories, knowledge captured from domain experts, underlying theory, and emerging technology within the domain." - Kang et al.
Object-oriented domain analysis (OODA) seeks to identify reusable items localized around objects, e.g., classes, instances, systems of interacting objects, and kits [frameworks]. OORA analysts and OOD designers will interact on a fairly frequent basis with the domain analysis effort.
OOA and OOD stand for Object-Oriented Analysis and Object-Oriented Design, respectively. OOA strives to understand and model, in terms of object-oriented concepts (objects and classes), a particular problem within a problem domain (from its requirements, domain and environment) from a user-oriented or domain expert's perspective and with an emphasis on modeling the real-world (the system and its context/(user-)environment). The product, or resultant model, of OOA specifies a complete system and a complete set of requirements and external interface of the system to be built, often obtained from a domain model (e.g. FUSION, Jacobson), scenarios (Rumbaugh), or use-cases (Jacobson).
[Shlaer 88] is often credited as the first book on OOA, although their method adds OO techniques to the traditional structured analysis principles of Yourdon and Constantine. Their complete approach ([Shlaer 88, 92]) consists of information modeling and recursive design, or OOA/RD and represents a recent addition to the structured analysis family (as does Martin and Odell). [Yourdon 92] provides a critique, although may only refer to their earlier work. Many other methodologies including Rumbaugh's OMT, Martin and Odell's OOA/D, and many others, also share common ground with SA and other existing analysis methodologies with such constructs as associations (E-R), functional models, and even DFD's. Booch, Jacobson, and Wirfs-Brock are examples of OO methodologies representing a greater departure from the conventional "structured" techniques, with greater emphasis on objects. OOram [Reenskaug 91] provides support and emphasis on types and roles as guiding principles, which is quite powerful. [Booch 94] presents a methodology which is an evolutionary step beyond the first edition by incorporating a collection of the best features from several of the major OO methodologies, as does HP's new FUSION methodology.
A new Unified Modeling Language (previously Unified Method) is now being worked on by Grady Booch, James Rumbaugh, and Ivar Jacobson at Rational Software which should be made into a public standard, perhaps to be adopted by the OMG. The .8 docs can be found online from the Rational home page, http:/www.rational.com.
The usual progression is from OOA to OOD to OOP (implementation) and this Universal Process Model roughly corresponds to the Waterfall Model [Royce 70]. See [Humphrey 89] and [Yourdon 92] for a few of many discussions on software life-cycle models and their use. Humphrey also details Worldy and Atomic Process Models for finer grained analysis and design in the Defined Process (see below) and discusses other alternatives to the task oriented models. He also provides the following critisisms on the Waterfall Model which had led to Boehm's seminal work on the Spiral Model:
* It does not adequately address changes
* It assumes a relatively uniform and orderly sequence of development steps
* It does not provide for such methods as rapid prototyping or advanced
languages
Modern OO methodologies directly address these points and emphasize the incremental, iterative, evolutionary, concurrent and situational nature of software development. [Boehm 86] presents a seminal spiral life-cycle model with a risk-driven incremental prototyping approach. [Booch 91, 6.1] proposes a "round-trip gestalt" design with analyze-design iterations and an overall system perspective and [Berard 93] proposes an (incremental) "parallel-recursive design" with analyze-design-implement-test iterations. [Coad 91b] presents the following development cycle breakdown:
Waterfall-
Analysis
Design
Programming
Spiral-
Analysis, prototyping, risk management
Design, prototyping, risk management
Programming, prototyping, risk management
[Boehm, 1988]
Incremental-
A little analysis
A little design
A little programming
Repeat
[Gilb, 1988]
[Author's note: The spiral model is often incremental and may waterfall if called for.]
Since classes and objects are used in all phases of the OO software life-cycle, the process is often referred to as seamless, meaning there is no conceptual gap between the phases as is often the case in other software development methodologies, such as the analysis (DFD's) to design (structure charts) to programming gaps found in traditional structured analysis and design. Seamlessness together with naturalness is a big advantage for consistency.
A problem domain has many realizations, or differing OOAs. An OOA has many realizations, or differing OODs, but a similar notation is often used for the two. An OOD also has many realizations, or differing OOPs, but allows a selection from among various languages for implementation (choosing the best language to implement the design). But some, such as Bjarne Stroustrup, don't like OOA and OOD getting too far from OOP (implementation independent), for fear that great discrepancies could occur between OOD and OOP by losing sight of the implementation language, which in some cases is predetermined. See also [Stroustrup 91].
From a greater perspective, the SEI has developed the Capability Maturity Model (CMM), a process-based TQM model for assessing the level of an organization's software development and which is often required of government contractors in the US [Humphrey 89]. The CMM also serves as a 5 level improvement process by specifying steps for organizations to progress to the next level, ultimately leading to statistical (process) control and sustained improvement. Watts S. Humphrey is now working on the Personal Software Process (PSP), a scaled down version of the CMM for individuals [Humphrey 95]. Next should follow a team- based software process (TSP?). Other CMM's in the works at the SEI include a personnel management CMM (PM-CMM).
Level 1: Initial: Every project is handled differently; ad hoc and chaotic.
Level 2: Repeatable: Every project is handled similarly.
Level 3: Defined: Standard processes are defined and used for all projects.
Level 4: Managed: A measurable basis for all improvements to the process.
Level 5: Optimizing: Emphasis on defect prevention and optimizing/continually
improving the process.
CMM documentation is available online from: http://ricis.cl.uh.edu/CMM and ftp.sei.cmu.edu/pub/cmm/
See also: Kitson, D.H. and Masters, S. "An Analysis of SEI Software Process Assessment Results 1987-1991", CMU/SEI-92-TR-24
Humphrey, W., Snyder, T. and Willis, R. "Software Process Improvement at Hughes Aircraft", IEEE Software, July 1991
Dion, R., "Elements of a Process Improvement Program," IEEE Software, July 1992.
"Concepts on Measuring the Benefits of Software Process Improvement," CMU/SEI-93-TR-9.
See also [Yourdon 92], [Wilkie 93], and [Booch 94] for discussions on this often cited model. There is also an ISO 9000 standard [ISO] applicable to software quality and ami working group in Europe helping to creat the ISO SPICE [Rout 95] standard (among other work), which is similar in scope to the CMM. To join the ami mailing list email to: ami-request@aut.alcatel.at with the following message: subscribe firstname, lastname, e-mail address.
Object-oriented analysis now includes "Enterprise Modeling" [Martin 92], also found in [Jacobson 92], and along with recent business process "reengineering" efforts places information systems within an organizational perspective by modeling entire organizations or a large part of them, with the information processing system and software products development as integrated components. [Yourdon 92] even calls for "global modeling"!
This document was translated by ms2html v1.8 on 04.06.96.