soft-eng@MITRE.MITRE.ORG (Alok Nigam) (05/10/89)
Software Engineering Digest Tuesday, 9 May 1989 Volume 6 : Issue 18 Today's Topics: Object Oriented Design - Books? Computer langauges and software lifecycle - references request (U) (3) Re: Ada vs. COBOL study (U) SCCS for Symbolics (U) Design Methodologies - Fact or Illusion. (U) (2) Design Methodologies - Fact or Illusion. (U) Re: grep vs. SEARCH (Was Re: Software Development Tools) (U) Re: Ancient dispute ------------------------------------------------------------ Date: Tue, 25 Apr 89 08:09:13 PAC From: COSTEST@IDUI1.BITNET <Bill Junk> Subject: Object Oriented Design - Books? A recent posting seemed to inquire about books on Object Oriented Design. I just received a copy of Object-Oriented Software Construction by Pertrand Meyer. Its published by Prentice Hall and has a 1988 copyright. I haven't had time to really get into it but it appears to be relatively complete and has significant detail in both design and programming areas. The language used is Eiffel. It looks to me that programming concepts are used to illustrate important design concepts. Some earlier books on the subject were really just programming books with minor discussion of design. This book seems to have the right priorities. ------------------------------ Date: 26 Apr 89 01:12:20 GMT From: "William Thomas Wolfe,2847," <hubcap!billwolf%hazel.cs.clemson.edu@gatech.edu> Subject: Re: Computer langauges and software lifecycle - references request (U) > The major problem is that very few problems/systems these days are suited to > COBOL. All the new sexy things (real-time, windows, graphics, ...) don't work > well in COBOL. Don't forget multitasking, reuseable ADTs, packages, true exception handling, operator overloading, or separate compilation... Personally, I'd like to see a good COBOL vs. Ada study, if anybody knows of one (or is interested in doing one)... ------------------------------ Date: 26 Apr 89 13:04:10 GMT From: Charlie Martin <romeo!crm@cs.duke.edu> Organization: Duke University CS Dept.; Durham, NC Subject: Re: Computer langauges and software lifecycle - references request (U) As far as a study comparing COBOL and Ada -- I'd be pleased to hear someone propose an experiment design that could compare Ada and COBOL (or any two languages) in a reasonbly rigorous fashion. ------------------------------ Date: 27 Apr 89 19:30:00 GMT From: m.cs.uiuc.edu!render@uxc.cso.uiuc.edu Subject: Re: Computer langauges and software lifecycle - references request (U) > Personally, I'd like to see a good COBOL vs. Ada study, > if anybody knows of one (or is interested in doing one)... Why? This would be like comparing a pterodactyl and a red-tailed hawk. They both fly, but they're at different evolutionary stages. A better study would be C++ vs. Ada, since they're both touted as being on the leading edge of PLs for software engineering. ------------------------------ Date: 28 Apr 89 01:20:22 GMT From: "William Thomas Wolfe,2847," <hubcap!billwolf%hazel.cs.clemson.edu@gatech.edu> Subject: Re: Ada vs. COBOL study (U) > Why? This would be like comparing a pterodactyl and a red-tailed > hawk. They both fly, but they're at different evolutionary stages. You know that, and I know that, but there are large numbers of businesses who DON'T know that, and it would be very helpful to have a study which would convincingly demonstrate the benefits (obvious to you and I) of switching to a far more advanced language. ------------------------------ Date: 26 Apr 89 15:02:00 GMT From: gistdev!tasha!andy@uxc.cso.uiuc.edu Subject: SCCS for Symbolics (U) Does anyone know of any source code control utilities for non-LISP applications on Symbolics 3650 computers running Genera 7.2? Please respond by e-mail. Thanks in advance, - ------------------------------------------------------------------------------- Andrew Warinner | "Semper ubi sub ubi" - J. Caesar GIST, Inc. | 1800 Woodfield Dr. | Disclaimers! We don't need no stinking disclaimers... Savoy, IL 61874 | ARPANET: andy%gistdev@uxc.cso.uiuc.edu (217) 352-1165 | UUCP : Euunet,pur-ee,convexL!uiucuxc!gistdev!andy - ------------------------------------------------------------------------------- ------------------------------ Date: 25 Apr 89 14:19:53 GMT From: Neil Haddley <mcvax!ukc!dcl-cs!neil@uunet.uu.net> Organization: Department of Computing at Lancaster University, UK. Subject: Design Methodologies - Fact or Illusion. (U) Design Methodologies - Fact or Illusion. - ---------------------------------------- I would greatly appreciate references to any papers, or books, which discuss the merits and demerits of Design Methodologies, and also any good references to the Design Process (Support). as a taste of what I am hoping for: "So called design methodologies for software systems are no such thing and are simply notations to express a pre-formulated software design ... it is profitable to turn our attention to building design support systems to assist with the design process itself." "Science [and Software Development] is an essentially anarchistic enterprise: theoretical anarchistic is more humanitarian and more likely to encourage progress than its law-and-order alternatives." "Software Development support tools do not always have to turn around formal notations being used to capture the intermediate results of the design process, which then provides input data for expert-system type advisors." ------------------------------ Date: 27 Apr 89 16:17:00 GMT From: m.cs.uiuc.edu!render@uxc.cso.uiuc.edu Subject: Design Methodologies - Fact or Illusion. (U) You may or may not consider this pertinent, but a good survey book is _Software Specification Techniques_, edited by Narain Gehani and Andrew D. McGettrick (Addison-Wesley, 1986). The book contains several papers detailing various aspects of the specification process (which I, at least, consider synonymous with design). If you want generalities and opinion (like those you quoted), then read Dijkstra's _Selected Writings on Computing_. Also, several software conferences have tracks devoted to design methods and tools, so look in a library or a catalog of conference proceedings. ------------------------------ Date: 25 Apr 89 04:26:21 GMT From: Rahul Dhesi <bsu-cs!dhesi@iuvax.cs.indiana.edu> Organization: CS Dept, Ball St U, Muncie, Indiana Subject: Re: grep vs. SEARCH (Was Re: Software Development Tools) (U) In article <58236@yale-celray.yale.UUCP> leichter@CS.YALE.EDU (Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU)) writes: >Can I reasonably assume that a user on a Unix system has access, somehow, to a >usable Pascal compiler? Don Knuth made the assumption that Pascal would be >universally available when he developed TeX. Knuth made a wrong assumption: That the use of an otherwise clause in the case statement was portable. This has little to do with the UNIX versus VMS debate. It does have something to do with how not to write portable code. ------------------------------ Date: Thu, 27 Apr 89 12:26:11 PDT From: PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU Subject: Re: Ancient dispute In Software Engineering Digest Volume 6 : Issue 16 Tom Thomson <tom%prg.oxford.ac.uk@NSS.Cs.Ucl.AC.UK> makes a valid point: >[...]byte-stream files are such a low-level >component that one might reasonably expect rather higher order components to >be the norm. I agree that a byte stream file is a low level data object/data store. However byte streams (notice the abscence of the word 'file') are the "Highest Common Interface" between all processors and data storage devices. It is easy to write many programs that all use this interface and therefore, be able for them to communicate via multivendor networks. Further programs that use a byte stream interface can communicate, directly to each other, using one processor, if the operating system or language is powerful enough to connect the output of one program to another, apparently concurrent program, with no visible intervening data storage. A byte stream is to software as wire is to hardware. permitting Software Engineers to construct new pieces of software by connecting together previously existing components is a vital. Both theorists (Hoare for example) methodologists (Jackson),and practitioners (Kernighan and Richie) have actively promoted cooperating sequential processes. Perhaps the habit of designing and implementing software as communicating components may become universal one day - and if it does who needs UNIX(R) any more! Dr. Richard J. Botting, Chair, Department of computer science, California State University, San Bernardino, CA 92407 ------------------------------ End of Software Engineering Digest **********************************