Object Oriented Methodologies: The Next Generation

Object Oriented Methodologies followed on from the "first generation" of structured methodologies and were largely developed in the late 1990s following the boom in Object Oriented Languages such as C++ and Java. The underlying idea is to create the logical design from a physical design based on observing the properties of the "real world". We will call this approach to software design the object oriented approach as many of the methods in this strand take their ideas directly from object oriented languages.

Object Oriented Methodologies - a summary

Object Oriented methods of software design make an assumption of closure in the software description, but do not assume the software description is complete. From a philosophical viewpoint, these methods adopt a realist ontology and empiricist epistemology. Object Oriented methods recognize that a program description can more easily be created from a closed software description than from an open one. Software designers can easily create closed software descriptions by using (closed) reality as a baseline. However, the interpretation of reality is non-trivial, so software design methods in the object-oriented strand still need to deal with incomplete descriptions. Consequently, the man problem is with the verification of the software: are we building the product right?

Object Oriented Methodologies - pros and cons

Pros

Rather than working from the description to reality, work from reality to the description. By using (closed) reality as a baseline, software designers can more easily form closed logical descriptions, which can in turn be transformed into code for a program. Basing software descriptions on reality should produce a better requirements specification; have fewer problems with validation and lead to the design of more "natural" software.

Cons

The interpretation of reality is not foolproof and the designers of object-oriented software still have to deal with the problems caused by incomplete descriptions; once a description has been formed from reality, the correspondence between the software description and reality need to remain synchronized. Consequently, object oriented methods tend to have problems with verification (are we building the product right?) and with completeness. This problem is compounded by the restricted grammar and vocabulary of the languages used in object oriented methods which tend to exacerbate the problems caused by having an incomplete description of reality to start with.

Reading

Books

• See any of the books from the SDM books section

Articles

• Chapters 13 and 21 in D . Avison and G Fitzgerald, Information Systems Development: Methodologies, Techniques and Tools (3rd Edition), McGraw-Hill Publishing, 2002
• Jacobson. I, Christerson. M, Jonsson. P, and Övergaard. G, Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1993
• Rumbaugh. J, Blaha. M, Premerlani. W, Eddy. F and Lorensene. W. Object-Oriented Modelling and Design, Prentice-Hall. 1991
• Booch. G, Object-Oriented Design With Applications, Addison-Wesley, 1991
• Jones, C (1994) Software Challenges: Gaps in the Object-Oriented Paradigm, Computer, Vol. 27, No 6, pp 90-91.

On-line Articles

• Process-centred Review of Object Oriented Software Development Methodologies. Raman, R and Paige, R.F. (2004) Technical Report YCS 2004-381, Department of Computer Science, University of York, UK
  A departmental "yellow report" that offers a comprehensive (154 page) review of Object Oriented Methodologies. The first few pages provide a concise summary of the historical development of OO methodologies. (see also Capretz, 2003)

• A survey of structured and object-oriented software specification methods and techniques. Wieringa, R. (1998). ACM Comput. Surv., 30(4), 459-527.
  A longer and more detailed comparison between structured and object oriented approached to design using the same example (a control system for a fruit juice manufacturing plant) throughout. Section 2 of this paper is of particular interest.

• The object-oriented systems life cycle. Henderson-Sellers, B. and Edwards, J. M. (1990). Commun. ACM, 33(9), 142-159.
  An attempt to map the 'traditional' systems development life cycle on to the Object Oriented approach to systems development.

• Analyzing systems for object oriented design. Reed, G. P. and Bynum, D. E. (1989). Jackson Systems Corporation, McLean, Virginia, United States: ACM Press.
  An article that highlights the conflicts that can arise when trying to map structured methods on to Object Oriented approaches to systems design.

A practical example

• Experiences with C++ and object-oriented software development. Wybolt, N. (1990). SIGSOFT Softw. Eng. Notes, 15(2), 31-39.
  This paper discusses the re-design and re-implementation of a commercial CASE tool in C++. It describes why an object-oriented approach was chosen and the collective experience of using this approach. The author comments that, in addition to the anticipated benefits, much of what was experienced was unforeseen and unexpected. (You might also like to look at some other observations about using OO in Gordon Weakliem's Weblog)

Web pages

• The UML Resource Page from the Object Management Group. - All you ever wanted to know about UML and more besides.
• The Object Process Methodology (OPM) Official Web Site - All you want to know about OPM
• RUP and Rational Software - Rational Software Corporation, the creators of RUP, are now a division of IBM.
• Object Oriented Programming - A page on the principles of Object Oriented Programming from Wikipedia
• Rational Unified Process - A page on Rational Unified Process from Wikipedia
• Object Process Methodology - A page on the principles of Object Process Methodology from Wikipedia

Lecture notes

The notes for this session are available as a presentation (in pdf format) - lecture notes for session 6