The object-oriented software development method: a practical approach to object-oriented development

ABSTRACT

The Object-Oriented Software Development Method (OOSD) includes object-oriented requirements analysis, as well as object-oriented design. OOSD is a practical method of developing a software system which focuses on the objects of a problem throughout development. OOSD's focus on objects early in the development, with attention to generating a useful model, creates a picture of the system that is modifiable, reusable, reliable, and understandable — the last perhaps most important because the picture of a software system created by a development method must be an effective device for communication among developers, customers, management, and quality-assurance personnel. Most object-oriented methods competing for the attention of the software developer actually apply traditional Structured Analysis (function-based), or variations of Structured Analysis, to requirements activity, and work through a transition process to an object-oriented design [1,2,7,10,11]. In these methods the developer begins with functionally-based requirements analysis, and only reaches an object-oriented design by the intermediary step of converting a traditional, functionally-decomposed data flow diagram (DFD) to an object-oriented DFD (or equivalent). In this conversion process, objects are identified through a set of heuristics which group “transformations” in the DFD generated during requirements analysis. These methods carry a number of interesting but unfortunate burdens. Lower-level objects, which directly relate to real-world objects, are easily identified, but higher-level objects are generally more arbitrary, so that developers do not consistently identify a hierarchy of objects which achieves significant improvement in software engineering goals (e.g., reliability, maintainability, reusability). The heuristics for identifying objects usually relate the DFD transforms to the object that controls execution of an operation, rather than the object which “owns” the operation. These methods generally ignore the need to convert behavior descriptions of the DFD transforms into behavior descriptions of the objects. Finally, the use of Structured Analysis in an otherwise object-oriented approach complicates the tracing of requirements by forcing the developer to look first to DFD transforms and their behavior descriptions, and then to the objects.

REFERENCES

• 1: S. C. Bailin, An object-oriented requirements specifications method, Communications of the ACM, v.32 n.5, p.608-623, May 1989 [doi>10.1145/63485.63491]
• 2: Grady Booch, Software Component with ADA, Benjamin-Cummings Publishing Co., Inc., Redwood City, CA, 1987
• 3: Grady Booch, Software engineering with Ada, Benjamin-Cummings Publishing Co., Inc., Redwood City, CA, 1983
• 4: Buhr, R., Machine Charts for Visual Prototyping in System Des/gn, SCE Report 88-2, Department of Systems and Computer Engineering, Carleton University, Ottawa, Ont., Canada (August 1988).
• 5: R. J. A. Buhr, System design with Ada, Prentice-Hall, Inc., Upper Saddle River, NJ, 1984
• 6: Tom Gilb, Principles of software engineering management, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 1988
• 7: Kjell Nielsen , Ken Shumate, Designing large real-time systems with Ada, McGraw-Hill, Inc., New York, NY, 1988
• 8: Orr, K., Structured Requirements Definition, Ken Orr and Associates, Inc., Topeka, KS (1981).
• 9: The Random House College Dictionary, Random House, Inc., New York, NY, pp. 339, 916 (rev. ed. 1975).
• 10: Sally Shlaer , Stephen J. Mellor, Object-oriented systems analysis: modeling the world in data, Yourdon Press, Upper Saddle River, NJ, 1988

INDEX TERMS

Primary Classification:
  D. Software
  D.3 PROGRAMMING LANGUAGES

Additional Classification:
  K. Computing Milieux
  K.6 MANAGEMENT OF COMPUTING AND INFORMATION SYSTEMS
      K.6.3 Software Management
          Subjects: Software development

General Terms:
Design, Performance