Creation of, and Conversion to, Object-Oriented Requirements
By Edward V. Berard
The Object Agency
PROLOGUE
Localization is the process of placing items in close physical proximity to each other, usually with the connotation of having some mechanism for precisely defining the boundaries of the "area" into which the items are being gathered. (For other definitions, see, e.g., [Ross et al, 1975] and [Booch, 1986].) Object-oriented approaches localize information around objects and functional decomposition approaches localize information around functions. Data-driven approaches localize information around data and data structures.
Traceability is the degree of ease with which a concept, idea, or other item may be followed from one point in a process to either a succeeding, or preceding, point in the same process. For example, one may wish to trace a requirement through the software engineering process to identify the delivered source code which specifically addresses that requirement. Traceability is greatly facilitated when the same localization scheme is used throughout the software engineering process.
Many software engineering projects begin with the establishment of requirements. Requirements embody the wants and needs of the client with regard to the software product. Care must be taken in the determination and creation of the requirements because they will be used as input to the "acceptance testing" process. (See, e.g., [Myers, 1976] and [Myers, 1979].) Specifically, the client will accept or reject the delivered software product based on how closely that product conforms to the stated requirements.
Based on experience, verifying that object-oriented code meets specific functional requirements is difficult. However, experience has also shown that verifying object-oriented code against object-oriented requirements is at least as easy as verifying functional code against functional requirements. This suggests that, if an object-oriented approach is going to be used for design and coding, the original requirements should be object-oriented, or should be converted to an object-oriented form.
The purpose of this article is to discuss the beginnings of an object-oriented requirements analysis effort. Specifically, its focus is on the initial gathering and formulation of object-oriented requirements, as opposed to the final packaging of the requirements. It is also the intent of this article to discuss the conversion of existing functional requirements into object-oriented requirements.
ESTABLISHING A MINDSET
As a rule, most software people are quite comfortable with the concept of functional requirements. The concept of functions being performed by subroutines, procedures, paragraphs, and functions is very familiar to them. Further, they have conveyed this view of the world to many of their customers. This functional mindset is so well-entrenched (not only mentally, but also in existing standards, policies, and procedures) that many software personnel can conceive of no other mechanism for describing requirements.
Suppose, however, we were attempting to define the requirements for a piece of hardware, e.g., an automobile, a personal computer, or a stereo system. These items will still have to meet requirements, but notice how our view of requirements has shifted, e.g.:
- While functionality is still important, we now speak of the "functionality of a (tangible, hardware) component." Whereas in software there is a tendency to view the component and functionality as one and the same, this tendency is not as strong with hardware.
- We talk about how the components will interact to affect a solution, as opposed to "what functions will be invoked." More importantly, instead of describing an invocation hierarchy, we speak of components interacting with each other (without the necessity of some "master routine" supervising these interactions).
- Our models make virtually no mention of "flow of data" and "flow of control." We may talk about "components controlling other components," or "components communicating with other components." We are not troubled by the fact that there may be many simultaneous, independently executing threads of control. (For example, we assume that the fuel gauge can function relatively independently of engine temperature monitor.)
An object-oriented mindset is much closer to a hardware mindset than it is to the conventional software functional mindset. If you are having trouble imagining what a set of object-oriented requirements look like, ask yourself how a set of requirements for a computer or an automobile might be created. Remember, "functionality" is still important in object-oriented requirements, but it is now localized within objects and within descriptions of the interactions among objects.
WHAT DO WE MEAN BY "REQUIREMENTS ANALYSIS"?
Depending on who you talk to, you will get a variety of definitions for "software requirements analysis," e.g.:
- the first activity to occur in the software life-cycle,
- the establishment of what needs to be done (as opposed to a discussion of the details of how it is to be accomplished), and
- the analysis of requirements which have previously been established by the client.
While there have been attempts at standard definitions for "analysis" or "requirements analysis" (e.g., [IEEE, 1983]), it is difficult to precisely define the process. Still, if you were to examine studies of software development methodologies (e.g., [Agresti, 1986], [Bergland and Gordon, 1981], [Birrell and Ould, 1985], [Blank et al, 1983], [DoI, 1981], [Firth et al, 1988], [Freeman and Wasserman, 1982], [Freeman and Wasserman, 1983], and [Teledyne Brown Engineering, 1987]) certain trends would begin to emerge.
First, if we were to examine a dictionary, we might find the following definitions for "analysis:"
- the separation of a thing into the parts or elements of which it is composed
- the examination of a thing to determine its parts or elements; also a statement showing the results of such an examination.
These definitions, however, do not completely describe what we mean by analysis in a software engineering context. Our comparative study of software development methodologies would show that we usually expect the following things from an analysis effort:
- an examination of a concept, system, or phenomenon with the intention of accurately understanding and describing that concept, system, or phenomenon,
- an assessment of the interaction of the concept, system, or phenomenon with its existing or proposed environment,
- the proposal of two to three alternative solutions for the client with an accurate and complete analysis of the alternatives, and
- an accurate and complete description of the solution to be delivered to the client.
Notice that the deliverables include not only "an 'analysis' of the client's problem," but an accurate and complete description of the system to be delivered. In effect, we must demonstrate an adequate understanding of the original problem, and we must precisely and concisely describe the solution we will be delivering to the client. This solution must be within any client stipulated constraints.
Second, an examination of virtually all software requirements analysis methodologies shows that requirements analysis ends with the description of the "user interface." The user interface is a detailed description of the product as the user will see (interact with) it. Further, "user" can be taken to mean anything from a human user, to other software products, to computer hardware.
Third, while design activities tend to be programming language specific, analysis activities can ignore programming language to a large extent. In truth, requirements analysis for software applications is somewhat influenced by the choice of programming language. However, most approaches to requirements analysis strive to be independent of programming language considerations. Most of the suggested approaches to software design, on the other hand, must deal with programming language concepts (e.g., modules, packages, and software interfaces) directly.
Fourth, user visibility is very high during analysis, and very low during design. User visibility is a term used to describe the level of client involvement during the software life-cycle. User visibility is highest during the "analysis" and "use" phases. User visibility is lowest during the "design" and "coding" phases. During analysis, software engineers must accurately extract the client's requirements and state them in terms which can be easily verified by the client.
[Notice that some sources (e.g., [DeMarco, 1979]) advocate that everything mentioned during analysis should be easily understood by the (potentially non-technical) client. However, the analyst must have a high level of confidence that the proposed solution can indeed be constructed within any user-stipulated constraints, as well as on time and within budget. Therefore, it is likely that some of the technical information produced during the analysis effort will be more appropriate for software engineers than for (non-technical) clients.]
Fifth, The end of each phase (or partial phase) of the software life-cycle is a decision point. At each decision point, management must often make decisions on how to proceed, or whether to proceed. Without a system specified in sufficient detail, meaningful decisions are often difficult, if not impossible. The requirements analyst must propose a solution in sufficient detail to allow meaningful management decisions. The deliverables from an analysis effort should therefore include:
- a complete description of the "user interface," including such items as a detailed list of all system capabilities, timing constraints, report formats, system limitations, installation instructions, operating instructions, deliverable system documentation, necessary hardware and software, and reliability information,
- a discussion of delivery dates, estimates of system development costs, installation costs, operating costs, training costs, and transition plans,
- any necessary legal documents, and
- other information deemed useful by either the analyst or the client
THE CONTEXT FOR OBJECT-ORIENTED REQUIREMENTS ANALYSIS
Some software engineering activities may have already been accomplished, or may be on-going, by the time one attempts to establish the object-oriented requirements for a given project. Object-oriented domain analysis (OODA) is an activity which identifies, documents, and configuration manages reusable object-oriented components within a given application domain. Rather than be associated with any one project, OODA is a continually on-going effort which interacts with many software engineering efforts.
During OORA, software engineers will both solicit reusable object-oriented components from the OODA effort, and contribute new candidate components to the OODA system. In reuse-conscious installations, there is a highly symbiotic relationship between the OODA effort and individual projects. (See, e.g., [Arango, 1989], [Booch, 1987], [Neighbors, 1980], and [Prieto-Diaz, 1988] for a general discussion of domain analysis, and, e.g., [Shlaer and Mellor, 1989] for one view of OODA.) This brings up another aspect of OORA, i.e., software reusability is key to a successful OORA effort. (Note that we do not wait until coding begins to consider software reusability.)
An activity which usually immediately precedes many requirements analysis efforts is a feasibility study. Feasibility studies have two main goals:
- to determine the feasibility of attempting a specific project (or series of projects), and
- to accomplish the above with both a high level of confidence, and a minimum expenditure of resources.
Feasibility is typically much more than mere technical feasibility. Also important are financial, political, marketing, and time-related feasibility.
(Feasibility studies are often conducted using the techniques of analysis, although the application of these techniques is usually much more informal (than during analysis).)
BEGINNING THE ANALYSIS EFFORT
Regardless of the life-cycle approach you have chosen (e.g., functional decomposition or object-oriented), there are two activities which must be accomplished before a meaningful analysis effort can begin, i.e.:
- the sources of requirements information must be identified, and
- once identified, the sources of requirements information must be characterized.
Very seldom are requirements for a given project contained in a single, self-contained document. The OORA analyst must identify all valid, worthwhile sources of requirements information. These sources can include, for example:
- pre-existing requirements documents,
- standards documents,
- knowledgeable people,
- previously-existing software (including prototypes), and
- descriptions of "real world" systems of objects.
[Notice that if a set of non-object-oriented requirements already exists, they can be used as input to the OORA process, i.e., they can be converted to object-oriented requirements. The "bad news" is that a conversion effort is necessary. The "good news" is that you have a "starting point" for the OORA effort, and there is already some understanding of the original problem.]
Characterizing the sources of requirements information involves two main activities: characterizing the source itself, and characterizing the information provided by the source. The following are important considerations when attempting to characterize a source of requirements information:
- the credibility of the source,
- the ease of access that the OORA analyst will have to the source,
- the level of authority associated with the source,
- the types of information which this source can provide,
- the responsiveness of the source, and
- the longevity of the source.
The following are important considerations when attempting to characterize the information provided by a source of requirements information:
- the form of the information provided, e.g., textual, graphical, verbal, machine-executable, and machine-readable,
- the completeness of the information provided,
- determining how current the information is,
- determining how volatile the information is,
- the relevance of the information,
- how can the information be verified,
- how understandable is the information,
- the importance and priority of the information, and
- the interrelationships among the pieces of information, e.g., how will a change in one piece of information impact other pieces of information?
PROBLEMS WITH REQUIREMENTS
Even with careful identification of sources of information, and careful characterization of requirements information, there will still very likely be problems with the requirements information. Software engineers are very seldom (if ever) presented with a "clean" set of requirements. Software engineers will have to plan on addressing problems with any set of requirements.
[Software engineers must make sure that they are addressing problems in the requirements -- not adding useless enhancements. All too often, software engineers think that they, and not the client, know what the "real" requirements are. When attempting to fix "problems" in the requirements, software engineers should continually ask themselves, "is this a crucial and necessary fix, or is this an "enhancement" for my own gratification?" All "fixes" and "enhancements" to the requirements must be cleared with the client.]
Typical problems with requirements information include:
- omissions: Very often the initial set of user-supplied requirements (and information) is incomplete. This means that, during the course of analysis, the software engineer will have to either locate, or generate, new information. This new information is, of course, subject to the approval of the client. (Note that this location or generation of new information may be considered by some to be "design.")
- contradictions: Contradictions may be the result of incomplete information, imprecise specification methods, a misunderstanding, or lack of a consistency check on the requirements. If the user alone cannot resolve the contradictions, the software engineer may be required to propose a resolution to each problem.
- ambiguities: Ambiguities are often the result of incompletely defined requirements, lack of precision in the specification method, or a conscious decision to leave their resolution to the software engineers performing analysis. Resolution of ambiguities may require some "requirements design" decisions on the part of the software engineers.
- duplications: Duplications may be the outright replication of information in the same format, or the replication of the same information in several different places and formats. Sometimes duplications are not obvious, e.g., the use of several different terms to describe the same item. Software engineers must be careful when identifying and removing unnecessary duplications.
- inaccuracies: It is not uncommon for software engineers to uncover information which they suspect is incorrect. These inaccuracies must be brought to the client's attention, and resolved. Often, it is not until the client is confronted with a precisely-described proposed solution that many of the inaccuracies in the original requirements come to light.
- too much design: One of the greatest temptations in software engineering is "to do the next guy's job," i.e., to both define a problem and to propose a (detailed) solution. One of the most difficult activities during analysis is the separation of "real requirements" from arbitrary (and unnecessary) design decisions made by those supplying the requirements.
A metarequirement is a stipulation of a "design decision" which is both supplied and required by the client. For example, a client might require that data be encrypted using a specific algorithm, or that a specific location in memory be used to store a specific piece of information. Software engineers must carefully separate true metarequirements from unnecessary design decisions made by the client. Metarequirements should be kept to a minimum.
- failure to identify priorities: A software engineer must have some basis for making decisions. Without a clearly-defined, well thought out, and comprehensive set of priorities, it will be difficult to select from a number of alternatives. Software engineers must realize that emphasis on one priority often inversely impacts several others, e.g., an overemphasis on efficiency very often impairs the reliability of the system.
- irrelevant information: Software engineers are often reluctant to throw away any information. Their clients often feel it is better to supply too much information rather than too little. Without some clear cut mechanisms to identify and remove irrelevant information, it will be difficult to develop accurate, cost-effective, and pragmatic solutions to a client's problems.
CREATION OF, AND CONVERSION TO, OBJECT-ORIENTED REQUIREMENTS
The chief differences between the original creation of object-oriented requirements, and the conversion of existing requirements to object-oriented form, is in the types of information available, and in the potential understanding of the problem. If someone has already established a set of non-object-oriented requirements (e.g., functional requirements), these non-object-oriented requirements are simply one of the sources of requirements information.
The understanding of the problem is a tricky issue. All too often, software engineers, their managers, and sometimes even their clients, think that the only way to understand a problem is strictly in functional terms. This can greatly hamper the generation of object-oriented requirements, e.g., while data flow diagrams are entirely appropriate in a functional decomposition approach, they are virtually useless in an object-oriented approach. Unfortunately, a functional decomposition approach to requirements analysis can sometimes make the establishment of object-oriented requirements more difficult than if the original set of (functional) requirements were completely discarded.
Given a reasonably complete, and reasonably accurate, set of functional requirements, and a skilled, object-oriented software engineer, a set of functional requirements can be converted to object-oriented requirements with a minimum of trouble. Further, if done well, object-oriented requirements tend to be more complete than functional requirements.
A MODEL
If we were to examine a number of different approaches to requirements analysis (e.g., [DeMarco, 1979] and the requirements analysis parts of [Marca and McGowan, 1988] and [Ward and Mellor, 1985]) we would see a common model consisting of three parts:
1. A series of graphical models (e.g., data flow diagrams, actigrams, and state transition diagrams). Some of these graphical models depict static relationships, while other show dynamic behavior. Many of these graphical techniques can be used at multiple levels of abstraction.
2. One or more repositories of information supporting the graphical models (e.g., the data dictionary in Structured Analysis).
3. A specified packaging of the analysis results, i.e., the deliverables. (e.g., the Structured Specification in Structured Analysis)
It is the intent of this article that we address the first two points. The last point, which potentially involves the creation of an object-oriented requirements specification (OORS), will be left for another time.
OBJECT-ORIENTED MODELS
In constructing object-oriented models during object-oriented requirements analysis (OORA), we do not restrict ourselves to graphical models. In OORA, object-oriented models may be:
- graphical, e.g., semantic networks (e.g., [Barr and Feigenbaum, 1981] and [Winston, 1984]), state transition diagrams (e.g., [Shlaer and Mellor, 1988] and [Ward and Mellor, 1985]), Petri Net Graphs (e.g., [Peterson, 1981] and [Reisig, 1985]), object-message diagrams, and timing diagrams,
- textual, e.g., prose (e.g., [Abbott, 1983]), mathematical descriptions (e.g., [Jones, 1986]), and logical descriptions (e.g., [Conery, 1988]),
- executable, e.g., models created using object-oriented programming languages/environments (e.g., Smalltalk ([Goldberg, 1984]), Trellis ([O'Brien et al, 1987]), DSM ([Shah et al, 1989]), Actor ([Franz, 1990]), and Prograph ([Cox and Pietrzykowski, 1989])), and
- otherwise, e.g., CRC (Class-Responsibility-Collaboration) cards ([Beck and Cunningham, 1989]).
Some graphical modeling techniques are best for showing static relationships, e.g., semantic networks for depicting specialization and aggregation. Other graphical techniques can be used to demonstrate dynamic behavior, e.g., state transition diagrams and Petri Net Graphs. [For still other object-oriented graphical modeling techniques, see [Cunningham and Beck, 1986] and [Loomis et al, 1987].] Care must be taken to ensure that the selected graphical technique(s) either are object-oriented in nature, or encourage object-oriented thinking.
Textual models seem best for describing low-level items (e.g., internal methods). Russell J. Abbott ([Abbott, 1983]) and Grady Booch ([Booch, 1983]) have demonstrated how one can create simple textual models for small designs (or small parts of large designs). Few people have the training to effectively carry out the mathematical design of even small software systems.
Executable models, to be most effective, require high-level languages (or high-level interfaces), libraries of reusable, object-oriented components, and user-friendly environments. Even with these items, there are problems, e.g., some object-oriented modeling tools lack support for multiple inheritance, concurrency, and unencapsulated composite operations. Most importantly, we do not want the limitations of any programming language having an appreciable impact on our thinking during OORA. (Still, the future of object-oriented software engineering seems to lie in the direction of executable specifications.)
SUPPORTING THE MODELS: "THE OBJECT DICTIONARY"
Object-oriented models may be static or dynamic. They may show individual or group characteristics. They may be graphical, textual, executable, or otherwise. However, they all deal with objects. Objects are the physical and conceptual things we find in the world around us. An object may be hardware, software, a concept (e.g., velocity), or even "flesh and blood." Objects are complete entities, e.g., they are not "simply information," or "simply information and actions." (Software objects strive to capture as completely as possible the characteristics of the "real world" objects which they represent.) Finally, objects are "black boxes," i.e., their internal implementations are hidden from the outside, and all interactions with an object take place via a well-defined interface.
Objects encapsulate:
- knowledge of state,
- operations and their corresponding methods (operations "advertise" an object's capabilities to the external world, while methods are the actual internal implementations for the operations),
- in the case of composite objects, other objects (i.e., we may have both heterogeneous and homogeneous composite objects),
- [optionally] exceptions,
- [optionally] constants, and
- most importantly, concepts.
For small object-oriented systems, our objects may consist solely of classes, metaclasses, and instances. A class is an object which is used to create instances, i.e., a class is a template, description, pattern, or "blueprint" for a category or collection of very similar items. Among other things, a class describes the interface these items present to the outside world. (There are alternative definitions for "class.") An instance is a specific thing or characteristic. Instances are usually created using classes as templates. A metaclass is a class whose instances are themselves classes.
Systems engineering tells us that the size of the largest items in a system is directly proportional to the size of the overall system, i.e., as the size of the system goes up, so do the sizes of its largest components. While large and complex objects may often be represented using only classes, metaclasses, and instances, these items are not sufficient for all large systems.
As we build larger object-oriented systems, we find a need for "systems of objects." Further, we find a need for two different types of systems of objects: subsystems and systems of interacting objects. Subsystems are collections of items (instances, classes, operations, other subsystems, and/or systems of interacting objects) which represent a large, object-oriented concept. Subsystems are highly logically cohesive (i.e., all the components of a subsystem are there to support a single, high-level, object-oriented concept), but are only weakly physically cohesive (i.e., a direct or indirect physical connection between any two given components of a subsystem is not a requirement).
In many cases, subsystems may be viewed as the concept of a class taken to the next higher level, e.g., a "class which can export other classes in its interface." An overly simplistic view of a subsystem is that of a library, e.g., the X Windows system could be viewed as a single large subsystem, or it could be organized into a series of smaller subsystems.
(I will discuss the details of subsystems in another article. For further reading, see, e.g., [Booch, 1987] and [Rational, 1986].)
Systems of interacting objects are large, physically cohesive collections of objects. By "physically cohesive" we mean that there is a direct or indirect physical connection between any two objects within the system of interacting objects. Systems of interacting objects typically have multiple, completely disjoint, interfaces (although it is possible for a system of objects to have only a single cohesive interface). For example, consider an automobile engine object. It may present one interface to the transmission, another to the fuel system, and yet another to the cooling system. While most people would agree that an automobile engine is a single cohesive object, they would also agree that it has multiple, completely-disjoint interfaces.
Unlike subsystems, systems of interacting objects are not granular, i.e., one cannot simply extract an individual component.
(I will also discuss the details of systems of interacting objects in another article.)
The major purpose of our "object dictionary" is to encapsulate the specifications for the objects (small and large) which populate our models. Therefore, we would expect to see the following items in our object-dictionary:
- specifications for small objects, i.e., classes, metaclasses, and instances,
- specifications for subsystems, and
- specifications for systems of interacting objects.
Please note that objects are more complex than mere data, and will require correspondingly more complex documentation. I will save a discussion of the documentation for subsystems and systems of interacting objects for another article, and will now discuss the documentation for small objects.
[An interesting side note: Since objects, and their corresponding documentation are more complex than simple data and data descriptions, attempting to use a conventional "data dictionary" to store object-related information may prove less than satisfactory.]
OBJECT AND CLASS SPECIFICATIONS (OCS)
We can document individual classes, metaclasses, and (occasionally) non-class instances using an object and class specification (OCS). (Note: Some people have taken to pronouncing "OCS" as "ox," and the plural as "oxen.") An OCS has five parts (there are rules for the composition, verification, and software quality assurance for each part):
- a precise and concise description: This may be viewed as an "executive summary" of the object. It may be textual, graphical, and otherwise.
- graphical models: This section contains graphical models representing both static and dynamic views of the object.
- operations: This section briefly describes the operations and methods for both the suffered and required operations for the object. (A suffered operation is something which happens to the object. A required operation is an operation which the object itself cannot supply, but which is needed to ensure the correct and desired behavior of the object.)
- state information: All objects have state, even if that state is constant. An understanding of state information provides us with a better understanding of the object's behavior, and provides a basis for such things as comparisons between object.
- exceptions and constants: Exceptions are a mechanism whereby an object may alter the state of the system in which it finds itself. Exceptions are used by an object to communicate exceptional conditions (e.g., list is full, node is off-line, or sensor is not enabled) to its environment. An object may choose to export useful constants (e.g., empty list or encryption seed) from its interface.
A typical OCS is about 5-6 pages (typeset) in length, but may be as small as 3 pages and as large as 8-9 pages.
It is important to realize that OCSs contain no application-specific information. Specifically, they may be viewed as "spec sheets" for an object, and are designed with the intention that they will be reused (unchanged) in other applications. (I will discuss the details of OCSs in another article.)
ATTACKING AN ANALYSIS PROBLEM
No two projects/products are the same. No two people think in exactly the same manner. Therefore, it should not be surprising that no two OORA efforts are the same. For example, some OORA analysts start by examining the available requirements information, and identifying as many different objects as possible. Other OORA analysts choose a more top-down approach, i.e., they identify the objects at the highest levels of abstraction, and then begin constructing object-oriented models of the problem (and sometimes potential solutions).
In truth, an object-oriented approach will be a mixture of composition and decomposition strategies. For small, easily-understood problems, a purely compositional approach may suffice. However, for larger, more complex problems, the initial approach will be more of an object-oriented decomposition process.
SHORT MAPS
Regardless of whether they are using a compositional or a decompositional approach, OORA analysts will want to identify and track information relating to the objects in their system. A simple mechanism for doing this is a "short map." A short map resembles an index, i.e., it is simply a list of the candidate objects which were found in the requirements information, and associated with each candidate object, is a list of places where that object was found in the requirements information. The most useful short maps are those which reflect a survey of the entirety of the requirements information.
OCS PRECURSORS
Once candidate objects have been identified, and a short map has been created, the OORA analyst may choose to reorganize the information in the original requirements. Using the short map, the OORA analyst selects each candidate object in turn, and gathers into one place everything that is know about that object. This collection of information contains both information about the object in isolation (i.e., independent of any particular application), and information about how this object is used in this specific application. This collection of general, and application-specific, information for an object is referred to as an "OCS precursor."
[In truth, the information contained in an OCS precursor may describe a large object (i.e., a subsystem or system of interacting objects). In this case, the information will be used, in part, to produce a subsystem specification (SS) or a system of interacting objects specification (SIOS), rather than an OCS. However, the term is used by convention, and because the OORA analyst may not be able to tell (initially) about the size of the object.]
The information in an OCS precursor is used for two purposes:
1. To create or select a specification for the general object, and
2. To aid in the construction of application-specific models of both the original problem and proposed solutions.
Please note that since the original requirements may not have been created with objects in mind, we may have to refine our object descriptions, and identify necessary omitted objects.
CONCLUSION
Object-oriented approaches to analysis share much in common with more traditional methods of analysis. For example, OORA analysts can construct models of both the problem space and solution space. (For a discussion of the terms "problem space" and "solution space", see [Ledgard and Marcotty, 1981].) Further, the OORA analyst can support these models with an "object dictionary."
Regardless of the starting point, e.g., with or without functional requirements, a set of object-oriented requirements can be produced. (This article, however, did not discuss the entire OORA process.)
BIBLIOGRAPHY
[Abbott, 1983]. R.J. Abbott, "Program Design by Informal English Descriptions," Communications of the ACM, Vol. 26, No. 11, November 1983, pp. 882 - 894.
[Agresti, 1986]. W. W. Agresti, Editor, Tutorial: New Paradigms for Software Development, Institute of Electrical and Electronic Engineers (catalog number EH0245-1), Washington, DC, 1986.
[Arango, 1989]. G. Arango, "Domain Analysis: From Art to Engineering Discipline," Proceedings of the Fifth International Workshop On Software Specification and Design, May 19-20, 1989, Pittsburgh, Pennsylvania, IEEE Computer Society Press, Washington, D.C., May 1989, pp. 152 - 159.
[Barr and Feigenbaum, 1981]. A. Barr and E.A. Feigenbaum, Editors, The Handbook of Artificial Intelligence, Volume 1, HeurisTech Press, Stanford, California, 1981.
[Beck and Cunningham, 1989]. K. Beck and W. Cunningham, "A Laboratory for Teaching Object Oriented Thinking," OOPSLA '89 Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 24, No. 10, October 1989, pp. 1 - 6.
[Bergland and Gordon, 1981]. G. D. Bergland and R. D. Gordon, Editors, Tutorial: Software Design Strategies, Second Edition, IEEE Computer Society Press (catalog number EHO184-2), New York, New York, 1981.
[Birrell and Ould, 1985]. N. D. Birrell and M. A. Ould, A Practical Handbook for Software Development, Cambridge University Press, New York, New York, 1985.
[Blank et al, 1983]. J. Blank, M. M. H. Drummen, H. Gersteling, T. G. M. Janssen, M. J. Krijger and W. D. Pelger, Software Engineering: Methods and Techniques, John Wiley & Sons, New York, New York, 1983.
[Booch, 1983]. G. Booch, Software Engineering with Ada, Benjamin/Cummings, Menlo Park, California, 1983.
[Booch, 1986]. G. Booch, Software Engineering with Ada, Second Edition, Benjamin/Cummings, Menlo Park, California, 1986.
[Booch, 1987]. G. Booch, Software Components With Ada, Benjamin/Cummings, Menlo Park, California, 1987.
[Conery, 1988]. J.S. Conery, "Logical Objects," in Proceedings of the 5th International Conference/Symposium on Logic Programming, Seattle, Washington, August 1988, MIT Press, Cambridge, Massachusetts, pp. 470 - 474.
[Cox and Pietrzykowski, 1989]. P.T. Cox and T. Pietrzykowski, "User-Oriented Software: A New Methodology for Software Development," Computer Language, Vol. 6, No. 9, September 1989, pp. 79 - 92.
[Cunningham and Beck, 1986]. W. Cunningham and K. Beck, "A Diagram for Object-Oriented Programs," OOPSLA '86 Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 21, No. 11, pp. 361 - 367.
[DeMarco, 1979]. T. DeMarco, Structured Analysis and System Specification, Yourdon Press, New York, New York, 1979.
[DoI, 1981]. Report on the Study of an Ada-based System Development Methodology, Volume 1, Department of Industry, London, England, 1981.
[Firth et al, 1988]. R. Firth, L. R. Gold, R. Pethia, and B. Wood, A Guide to the Assessment of Software Development Methods, Technical Report CMU/SEI-88-TR-8, ESD-TR-88-009, Carnegie Mellon University, Software Engineering Institute, Pittsburgh, Pennsylvania, April, 1988.
[Franz, 1990]. M. Franz, Object-Oriented Programming: Featuring Actor, Scott, Foresman and Company, Glenview, Illinois, 1990.
[Freeman and Wasserman, 1982]. P. Freeman and A. I. Wasserman, Software Development Methodologies and Ada (Methodman), Department of Defense Ada Joint Program Office, Arlington, Virginia, 1982.
[Freeman and Wasserman, 1983]. P. Freeman and A. I. Wasserman, Editors, Tutorial on Software Design Techniques, Forth Edition, IEEE Computer Society Press (catalog number EHO205-5), Silver Spring, Maryland, 1983.
[Goldberg, 1984]. A. Goldberg, Smalltalk-80: The Interactive Programming Environment, Addison-Wesley, Reading, Massachusetts, 1984.
[IEEE, 1983]. IEEE, Standard Glossary of Software Engineering Terminology ANSI/IEEE Std 729-1983, Institute of Electrical and Electronics Engineers, New York, New York, 1983.
[Jones, 1986]. C.B. Jones, Systematic Software Development Using VDM, Prentice-Hall, Englewood Cliffs, New Jersey, 1986.
[Ledgard and Marcotty, 1981]. H. Ledgard and M. Marcotty, The Programming Language Landscape, Science Research Associates, Chicago, Illinois, 1981.
[Loomis et al, 1987]. M.E.S. Loomis, A.V. Shaw, and J.E. Raumbaugh, "An Object Modeling Technique for Conceptual Design," Proceedings of ECOOP '87: European Conference on Object-Oriented Programming, Springer Verlag, New York, New York, 1987, pp. 192 - 202.
[Marca and McGowan, 1988]. D.A. Marca and C.L. McGowan, SADT -- Structured Analysis and Design Technique, McGraw-Hill Book Company, New York, New York, 1988.
[Myers, 1976]. G.J. Myers, Software Reliability: Principles and Practices, John Wiley & Sons, New York, New York, 1976.
[Myers, 1979]. G. J. Myers, The Art of Software Testing, John Wiley & Sons, New York, New York, 1979.
[Neighbors, 1980]. J.M. Neighbors, "Software Construction Using Components," Technical Report 160, Department of Information and Computer Sciences, University of California, Irvine, 1980.
[O'Brien et al, 1987]. P.D. O'Brien, D.C. Halbert, and M.F. Kilian, "The Trellis Programming Environment," OOPSLA '87 Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 22, No. 12, December 1987, pp. 91 - 102.
[Peterson, 1981]. J.L. Peterson, Petri Net Theory and the Modeling of Systems, Prentice-Hall, Englewood Cliffs, New Jersey, 1981.
[Prieto-Diaz, 1988]. P. Prieto-Diaz, "Domain Analysis for Reusability," Proceedings of COMPSAC '87, 1987, pp. 23 - 29, reprinted in IEEE Tutorial: Software Reuse: Emerging Technology, Edited by W. Tracz, IEEE Catalog No. EH0278-2, IEEE Computer Society Press, Washington, D.C., 1988, pp. 347 - 353.
[Rational, 1986]. Rational, Inc., Large-System Development and Rational Subsystems, Document Control Number 6004, Rational, Inc., Mountain View, California, November, 1986.
[Reisig, 1985]. W. Reisig, Petri Nets: An Introduction, Springer-Verlag, New York, New York, 1985.
[Ross et al, 1975]. D. T. Ross, J. B. Goodenough, C.A. Irvine, "Software Engineering: Process, Principles, and Goals," Computer, Vol. 8, No. 5, May 1975, pp. 17 - 27.
[Shah et al, 1989]. A.V. Shah, J.E. Rumbaugh, J.H. Hamel, and R.A. Borsari, "DSM: An Object-Relationship Modelling Language," OOPSLA '89 Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 24, No. 10, October 1989, pp. 191 - 202.
[Shlaer and Mellor, 1988]. S. Shlaer and S.J. Mellor, Object-Oriented Systems Analysis: Modeling the World In Data, Yourdon Press: Prentice-Hall, Englewood Cliffs, New Jersey, 1988.
[Shlaer and Mellor, 1989]. S. Shlaer and S.J. Mellor, "An Object-Oriented Approach to Domain Analysis," Software Engineering Notes, Vol. 14, No. 5, July 1989, pp. 66 - 77.
[Teledyne Brown Engineering, 1987]. Software Methodology Catalog, Technical Report MC87-COMM/ADP-0036, Teledyne Brown Engineering, Tinton Falls, New Jersey, October 1987.
[Ward and Mellor, 1985]. P.T. Ward and S.J. Mellor, Structured Development for Real-Time Systems, Volumes 1-3, Yourdon Press, New York, New York, 1985.
[Winston, 1984]. P.H. Winston, Artificial Intelligence, Second Edition, Addison-Wesley, Reading, Massachusetts, 1984.
Used by Permission.