From: wgg@cs.ucsd.edu (William Griswold)
Newsgroups: comp.software-eng,comp.object
Subject: Re: Software costs revisited?
Date: 24 Jul 92 01:39:35 GMT
Followup-To: comp.software-eng,comp.object
Organization: CSE Dept., U.C. San Diego

In article <22493@hacgate.SCG.HAC.COM> hayes@valkris.aero.org (Brian Hayes 74-35 x65129) writes:
>...
>It is always interesting to read about motivation for using OO.  I'm
>currently reading Booch's "Object-Oriented Design With Applications"
>(1991) and his stated motivation for OO is that previous/other methods 
>have failed to master complexity (with regard to "industrial strength
>software") which leads to the software crisis were a project is "late,
>overbudget and deficient in their stated requirements."
>
>I am new to OO, so forgive my ignorance, but, IMHO:  These motivations
>are not good enough to justify using OO.  I believe that functional 
>oriented analysis and design is as good as OOA and OOD if not better.
>The problem in the past (and currently) is that few people/projects
>apply a rigorous life-cycle methodology when producing systems.  One 
>problem, of course is that there are few methodolgies that are 
>rigorous enough (appoligies to Hatley-Pirbahi method, ADARTS, and 
>other similar methods and methodologies who fall short of being 
>rigorous).
>
>As I investage and analyze the OO paradigm, I will be attempting to 
>find answers to the following questions:
>Are the OO methodologies rigorous enough? 
>When I complete my OOA phase, can I be assured that the system will 
>work and meet requirements?
>When I complete the OOD phase, can I be assured that the system 
>will work and will meet requirements?
>
>*** Brian Hayes hayes@hac2arpa.hac.com (310) 616-5129 ***

I don't know how OOA/D fares with regard to completeness criteria.  However,
one important quality of a design is how well it positions the implementors
for future change, since most of a good program's lifetime is spent in
maintenance.  

For maintenance, one desirable characteristic of a system is locality of
change.  If an enhancement or repair can be implemented within one or two
modules/classes (and it is not necessary to check every module in the system
for consistency), then the design has succeeded in making the life of
maintainers easier, and improves the chances of a reliable product.

It is widely understood that functional design tends to lead to
implementations that require non-local changes more often than
data-oriented design methods.  A classic reference in this regard is:

@article{ParnasCriteria,
author = "D. L. Parnas",
title = "On the Criteria to be Used in Decomposing Systems into Modules",
journal = CACM,
volume = 15,
number = 12,
year = 1972,
month = Dec,
pages = "1053--58"}

In fact, modules only succeed in isolating representation (which is one
class of likely change), but do not particularly help you with extending
interfaces and behavior.  Classes help some in this regard via suclassing,
inheritance and polymorphism.  An article in June 1992 IEEE Computer,
``Using Tool Abstraction to Compose Systems'' by Garlan, Kaiser and Notkin
describes a rather different, more dynamic approach.

						Bill Griswold
						UCSD, Dept. of CS&E
						wgg@cs.ucsd.edu
Newsgroups: comp.software-eng