Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!crackers!jjmhome!smds!rh From: rh@smds.UUCP (Richard Harter) Newsgroups: comp.object Subject: Re: Documenting OO Systems Summary: We don't just stick them together Message-ID: <413@smds.UUCP> Date: 24 Apr 91 06:11:50 GMT References: <3201:Apr705:40:4591@kramden.acf.nyu.edu> Distribution: na Organization: SMDS Inc., Concord, MA Lines: 41 In article , jls@rutabaga.Rational.COM (Jim Showalter) writes: > >> If we were strictly engineers, > >>we could down a catalog of routines and, by cleverly sticking them > >>together, build a program. > Isn't that what we DO? We gather together small chunks (e.g. various > library routines) and big chunks (e.g. X-Windows), and paste together > a system. At least, that's what a software engineer does--I've known > a lot of hackers who want to start from a blank sheet of paper each time... No, we don't really do that, except perhaps in GPSS and Simula. First let me give an example of when it is done. If you take a series of UNIX utilities and connect them via pipes you are building a composite program by pasting components together. Now what is going on here? You have a number of standard software components, each with a single input and output channel, and a single standard connector with a standard data flow protocol (the byte stream). The UNIX input-process-pipe-...-pipe-process-output paridigm allows you to create composite programs in minimal time with maximal reusability of software when it is applicable. However it is essentially inadequate if we are looking at a bigger picture of program construction via reusability of components because of linear connectivity and the single type of data flow. What one would like is a defined set of data types, a library of software elements that operate on those data types, and a suite of connectors specific to those data types. With said facilities a graphical representation showing the elements and their connections would constitute an executable program description. A key point is that when one routine calls another, or when one routine needs to know about what another routine expects, reusability is compromised. Just speculative opinion, so don't get excited folks. -- Richard Harter, Software Maintenance and Development Systems, Inc. Net address: jjmhome!smds!rh Phone: 508-369-7398 US Mail: SMDS Inc., PO Box 555, Concord MA 01742 This sentence no verb. This sentence short. This signature done.