From: CRDGW2::CRDGW2::MRGATE::"SMTP::MWSUN.MITRE.ORG::NIGAM"
Date: 3-AUG-1989 18:24:53
Description: Software Engineering Digest v6n38
Return-Path: <nigam@mwsun.mitre.org>
Received: by mwsun.mitre.org (5.54/SMI-2.2)
id AA13986; Thu, 3 Aug 89 17:05:46 EDT
Date: Thu, 3 Aug 89 17:05:46 EDT
From: nigam@mwsun.mitre.org (Alok Nigam)
Message-Id: <8908032105.AA13986@mwsun.mitre.org>
Organization: The MITRE Corp., Washington, D.C.
To: soft-eng-dist@mwunix.mitre.org
Subject: Software Engineering Digest v6n38
Software Engineering Digest Thursday, 3 August 1989
Volume 6 : Issue 38
Today's Topics:
Object-Oriented Reading List
Addendum to Object-Oriented Reading List
Re: maintenance strategies/tools
------------------------------------------------------------
Date: 1 Aug 89 21:15:16 GMT
From: Edward Berard <sei!ajpo!eberard@pt.cs.cmu.edu>
Subject: Object-Oriented Reading List
Some people have asked me for a reading list on object-oriented
technology. What follows is a partial reading list. [My own current
list contains about 300 entries, and is by no means comprehensive.]
I hope you will find this list of use.
-- Ed Berard
(301) 353-9652
--------------------------
Readings In Object-Oriented Technology
by Edward V. Berard
Berard Software Engineering, Inc.
If you are interested in reading about any rapidly evolving
technology, it is best to keep the following in mind:
% Read more than one source. Look for sources which have different,
and possibly conflicting, views of the material. It is often
difficult to determine fundamental facts when only one
viewpoint is present.
% Very often, authors confuse concepts with implementations. Ask
yourself if the author is discussing a concept, or a
particular implementation of the concept.
% Always be on the lookout for new sources. In the software
technology arena in particular, significant changes can take
place in less than a month.
% Take care to distinguish between differing viewpoints and
conflicting viewpoints.
There are many topic areas in object-oriented software technology, and
literally thousands of books, articles, tutorials, and proceedings
devoted, in whole, or in part, to object-oriented software concepts.
What we will present here is some of the representative reading
material. Just because an item is included in this reading list does
not mean that it is recommended without qualifications, nor does it
mean that it is an authoritative source on a topic. However, the
material listed here is intended to help you understand more about the
technology.
Object-Oriented Programming
Object-oriented programming books most often tend to focus on
programming language aspects of object-oriented technology. However,
many fundamental concepts can be found in the books mentioned below:
[Cox, 1986]. B.J. Cox, Object Oriented Programming: An Evolutionary
Approach, Addison-Wesley, Reading, Massachusetts, 1986.
[Goldberg and Robson, 1983]. A. Goldberg and D. Robson, Smalltalk-80:
The Language and Its Implementation, Addison-Wesley, Reading,
Massachusetts, 1983.
[Meyer, 1988]. B. Meyer, Object-Oriented Software Construction,
Prentice-Hall, Englewood Cliffs, New Jersey, 1988.
[Keene, 1989]. S.E.Keene, Object-Oriented Programming in Common Lisp,
Addison-Wesley, Reading, Massachusetts, 1989.
[Stroustrup, 1986a]. B. Stroustrup, The C++ Programming Language,
Addison-Wesley, Reading, Massachusetts, 1986.
Object-Oriented Requirements Analysis
There are a number of publicly available courses on object-oriented
requirements analysis. Since the technology is still new, these
courses present many differing viewpoints and approaches. There is,
however, one book on the topic:
[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.
Object-Oriented Design/Development
Most of the work which has been done in the area of object-oriented
life-cycle issues, outside of object-oriented programming, has been
accomplished within the Ada community. Some representative sources on
OOD are:
[Abbott, 1983]. R.J. Abbott, "Program Design by Informal English
Descriptions," Communications of the ACM, Vol. 26, No. 11, November
1983, pp. 882 - 894.
[Booch, 1982a]. G. Booch, "Object Oriented Design," Ada Letters, Vol.
I, No. 3, March- April 1982, pp. 64 - 76.
[Booch, 1986a]. G. Booch, "Object Oriented Development," IEEE
Transactions on Software Engineering, Vol. SE-12, No. 2, February
1986, pp. 211 - 221.
[Goldsack, 1985]. S.J. Goldsack, Ada for Specification : Possibilities
and Limitations, Cambridge University Press, Cambridge, United
Kingdom, 1985.
[Heitz, 1988]. M. Heitz, "HOOD: A Hierarchical Object-Oriented Design
Method," Proceedings of the Third German Ada Users Congress, January
1988, Gesellschaft fur Software Engineering, Munich, West Germany, pp.
12-1 - 12-9.
[Masiero and Germano, 1988]. P. Masiero and F.S.R. Germano, "JSD As An
Object-Oriented Design Method," Software Engineering Notes, Vol. 13,
No. 3, July 1988, pp. 22 - 23.
[Seidewitz and Stark, 1986b]. E. Seidewitz and M. Stark, General
Object-Oriented Software Development, Document No. SEL-86-002, NASA
Goddard Space Flight Center, Greenbelt, Maryland, 1986.
[Stark and Seidewitz, 1987]. M. Stark and E.V. Seidewitz, "Towards a
General Object-Oriented Ada Life-Cycle," Proceedings of the Joint Ada
Conference, Fifth National Conference on Ada Technology and Washington
Ada Symposium, U.S. Army Communications-Electronics Command, Fort
Monmouth, New Jersey, pp. 213 - 222.
Object-Oriented Databases
Object-oriented databases are not the same thing as relational
databases. In effect, object-oriented database technology today is at
the same point relational database technology was in the late 1970s.
(I know more than a few vendors who would disagree with this point.)
Some representative information on the subject can be found in:
[Babcock, 1987]. C. Babcock, "Object is DBMS Focus," ComputerWorld,
Vol. XXI, No. 40, October 5, 1987, page 25.
[Blaha et al, 1988]. M.R. Blaha, W.J. Premerlani, and J.E. Rumbaugh,
"Relational Database Design Using an Object-Oriented Approach,"
Communications of the ACM, Vol. 31, No. 4, April 1988, pp. 414 - 427.
[Bochenski, 1988]. B.A. Bochenski, "On Object-Oriented Programming,
Databases," Software, Vol. 8, No. 11, September 1988, page 42.
[Dittrich and Dayal, 1986]. K. Dittrich and U. Dayal, Editors,
Proceedings of the 1986 International Workshop on Object-Oriented
Database Systems, IEEE Catalog Number 86TH0161-0, IEEE Computer
Society Press, Washington, D.C., 1986.
[Scannell, 1988]. T. Scannell, "Freeform DBMS the 'Object' of Startup
Company's Affection," Mini-Micro Systems, Vol. XXI, No. 2, February
1988, pp. 16 - 22.
[Shriver and Wegner, 1987]. B. Shriver and P. Wegner, Editors,
Research Directions in Object-Oriented Programming, The MIT Press,
Cambridge, Massachusetts, 1987.
[Weiss, 1987]. R. Weiss, "Why Object-Oriented Databases?," Electronic
Engineering Times, No. 465, December 21, 1987, page 23.
[Wile and Allard, 1987]. D.S. Wile and D.G. Allard, "Worlds: an
Organizing Structure for Object-Bases," SIGPLAN Notices, Vol. 22, No.
1, January 1987, pp. 16 - 26.
Object-Oriented Computer Hardware
Even computer hardware can be constructed in an object-oriented
manner. Here are two references:
[Myers, 1982]. G.J. Myers, Advances in Computer Architecture, Second
Edition, John Wiley & Sons, New York, New York, 1982.
[Organick, 1983]. E. Organick, A Programmer's View of the Intel 432
System, McGraw-Hill, New York, New York,1983.
General Object-Oriented Technology References
There are a number of general references on object-oriented
technology, including:
[ACM, 1986a]. Association for Computing Machinery, Special Issue of
SIGPLAN Notices on th Object-Oriented Programming Workshop, Vol. 21,
No. 10, October 1986.
[ACM, 1986b]. Association for Computing Machinery, OOPSLA '86
Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 21, No.
11, November 1986.
[ACM, 1988a]. Association for Computing Machinery, OOPSLA '87 Addendum
to the Proceedings, Special Issue of SIGPLAN Notices, Vol. 23, No. 5,
May 1988.
[ACM, 1988b]. Association for Computing Machinery, OOPSLA '88
Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 23, No.
11, November 1988.
[Gill, 1988]. P. Gill, "MIS Slowly Warms Up to Object-Oriented
Programming," ComputerWorld, Vol. XXII, No. 8, February 22, 1988, pp
71 - 76.
[Millikin, 1989]. M.D. Millikin, "Object Orientation: What It Can Do
For You," ComputerWorld, Vol. 23, No. 11. March 13, 1989, pp. 103 -
113.
[Peterson, 1987a]. G.E. Peterson, Tutorial: Object-Oriented Computing,
Volume 1: Concepts, IEEE Catalog Number EH0257-6, IEEE Computer
Society Press, Washington, D.C., 1987.
[Peterson, 1987b]. G.E. Peterson, Tutorial: Object-Oriented Computing,
Volume 2: Implementations, IEEE Catalog Number EH0257-6, IEEE Computer
Society Press, Washington, D.C., 1987.
[Shriver and Wegner, 1987]. B. Shriver and P. Wegner, Editors,
Research Directions in Object-Oriented Programming, The MIT Press,
Cambridge, Massachusetts, 1987.
------------------------------
Date: 2 Aug 89 01:03:13 GMT
From: Edward Berard <sei!ajpo!eberard@pt.cs.cmu.edu>
Subject: Addendum to Object-Oriented Reading List
It seems that my earlier posting left out the wonderful work being
done in Europe, i.e., the European Conference on Object-Oriented
Programming (ECOOP). In addition, I included the addendum to the
conference proceedings for OOPSLA '87, but failed to include the
original proceedings. This posting should fix that.
Please remember that there are literally thousands of sources (books,
articles, and proceedings) which discuss object-oriented concepts.
-- Ed Berard
(301) 353-9652
----------------------------------------------
[ACM, 1987]. Association for Computing Machinery, OOPSLA U87
Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 22, No.
12, December 1987.
[Bezivin et al, 1987]. J. Bezivin, J.-M. Hullot, P. Cointe, and H.
Lieberman, ECOOP U87: Proceedings of the European Conference on
Object-Oriented Programming, Lecture Notes on Computer Science, Volume
276, Springer Verlag, New York, New York, 1987.
[Cook, 1989]. S. Cook, ECOOP U89: Proceedings of the European
Conference on Object-Oriented Programming, British Computer Society
Workshop Series, Cambridge University Press, Cambridge, United
Kingdom, 1989.
[Gjessing and Nygaard, 1988]. S. Gjessing and K. Nygaard, ECOOP U88:
Proceedings of the European Conference on Object-Oriented Programming,
Lecture Note on Computer Science, Volume 322, Springer Verlag, New
York, New York, 1988.
------------------------------
Date: 2 Aug 89 17:15:57 GMT
From: john foster <mcvax!ukc!axion!jfoster@uunet.uu.net>
Subject: Re: maintenance strategies/tools
> Does anyone have any experience with trying to "reverse engineer" to
> a proper maintenance environment? (or know anybody who does?)
My group here at British Telecom Research Labs has a strong interest
in reverse engineering (as part of more general research into
software maintenance). We also have past experience of using reverse
engineering in the maintenance of switching system software. I hope
the following, fairly general, comments might be of some use.
> What methods/strategies were employed?
There are (at least) three broad strategies to consider:
1. Reverse documentation, involving the use of static analysis
etc to create information to help the maintainers
2. Reverse engineering, where you start with the code and
attempt to recreate the design/spec information
3. Re-engineering, where you perform step (2) and then recreate
the system from the new spec.
(BTW, I don't claim that my use of these terms is definitive).
Identifier cross-referencing is the lowest level of our
reverse documentation work, and we then build on that to
gain higher levels of documentation. Parts of that work
are described in:
Foster, J. R. and Munro, M. "A Documentation Method Based on
Cross-Referencing" Proc Conf Software Maintenance 1987, Austin,
Texas
Fletton, N. T. and Munro, M. "Redocumenting Software Systems
Using Hypertext Technology" Proc Conf Software Maintenance 1988,
Phoenix, Arizona
(John Foster is me; Nigel Fletton is another member of the
group here; Malcolm Munro is at the University of Durham (UK)
and runs the Centre for Software Maintenance there).
We have found reverse documentation extremely useful, even though
it can't tell you _all_ the things you want to know (like the
reasons behind design decisions).
This isn't a commercial plug, incidentally, because we are not
in the market as tool suppliers in this area.
Reverse engineering (as I define it here) is a more difficult
task, but there's a lot of interest and activity. A good example
paper is:
Sneed, H. M. and Jandrasics, G. "Inverse Transformation of Software
from Code to Specification" Proc Conf Software Maintenance 1988
The paper describes a system for reverse engineering from COBOL.
Re-engineering is the most expensive of the lot, but of course it
also offers the greatest potential gain. IBM have an interesting
project involving re-engineering via formal methods: see eg
Nix, C. J. and Collins, B. P. "The Use of Software Engineering,
including the Z Notation, in the Development of CICS" Quality
Assurance, vol 14 no 3, September 1988
> What other tools did you use/can you get on the market for this sort
> of work?
There's a regularly updated survey on software maintenance tools,
published by Software Maintenance News, Staten Island, New York.
Sorry I can't quote the full reference right now, but their
phone number is (USA) 718-816-5522.
> I believe the current idea is to come up with some sort of "expert system"
> to handle (some of) the maintenance problems. I personally have my doubts
> about such an approach and would be glad to hear any positive or negative
> experiences/opinions in this (or related) areas.
I'm convinced that expert systems have a lot to offer, although these
are early days yet. But people are certainly talking about, and/or
experimenting with:
- systems to help users register their change requests (with
some problem analysis capability)
- systems to aid code analysis
- systems to aid people writing documentation
There are some papers in the proceedings of the software maintenance
conferences mentioned above, that give an idea of what's going on.
------------------------------
End of Software Engineering Digest
**********************************