Path: utzoo!attcan!uunet!cs.utexas.edu!husc6!bunny!jwg1 From: jwg1@gte.com (James W. Gish) Newsgroups: comp.software-eng Subject: Re: OOP and software reuse Message-ID: Date: 11 Jul 90 20:50:32 GMT References: <39400113@m.cs.uiuc.edu> <112789@linus.mitre.org> <112896@linus.mitre.org> Sender: jwg1@GTE.COM Organization: GTE Laboratories Incorporated, Waltham, MA Lines: 54 In-reply-to: mitchell@community-chest.uucp's message of 10 Jul 90 17:31:09 GMT In article <112896@linus.mitre.org> mitchell@community-chest.uucp (George Mitchell) writes: > In article jwg1@gte.com (James W. Gish) > (That's me) wrote: > `So, for the foreseeable future I believe our best hope is in > `providing intelligent tools for assisting us in adapting code and > `associated artifacts including, for example, documentation and test > `cases, to new uses. > > This comment reflects what I feel is an improper emphasis on > implementation. It is partly because of the pervasiveness of this > mindset that the appraisal of the "foreseeable future" is probably quite > correct. However, if we are able to look at reuse from the total > life-cycle, it can be possible [in a domain ANALYSIS] to identify domain > specific objects with standardized interfaces. It can also be possible > to DESIGN objects that provide the minimum essential functionality which > can be extended without object modification. In IMPLEMENTATION it can > be possible to create code and documentation that will permit the object > to be easily reused and maintained. In MAINTENANCE it can be possible > to have a domain wide CM program and provide support to all users. > Finally, in the user statement of REQUIREMENTS it can be possible to > communicate the requirements for a new system (at least partially) in > terms of the previously specified objects that will compose that system. > This would be a nice world to live in, but I don't think its terribly realistic. I think that this is a noble goal which we should continue to strive for, but I'm not convinced we will achieve it until we change some of our fundamental notions of software development. In particular, our idea of parts or components needs to be changed drastically of any kind of reasonable construction of parts to work like you want. Subroutines and parameters or even objects and methods as we know them today just DON'T cut it; they are just not easily composable. We desperately need some new ideas here. As far as domain analysis goes, the difficulty is that you don't just do a domain analysis and things are fine and stable from that point forward; domains evolve, and your standardized interfaces have to evolve along with the domains. Also, 'domains' are not something that you can easily define the boundaries of; I don't know of any that are completely self-contained. What ever you define your domain to be, it consists of many overlapping, co-dependent domains. The way to address this is to decide in what context, what model of computation, you want to use the results of your domain analysis. But context is related to the application(s) of interest in the domain. And here's the rub - new applications and technologies arise and, in effect, invalidate the requirements you made on your original domain analysis, further destabilizing your standard interfaces. But it is important to continue dreaming and striving... -- Jim Gish (jgish@gte.com) Principal Investigator Software Reusability Project GTE Laboratories Inc.