Path: utzoo!attcan!uunet!cs.utexas.edu!usc!apple!voder!pyramid!athertn!hemlock!mcgregor From: mcgregor@hemlock.Atherton.COM (Scott McGregor) Newsgroups: comp.software-eng Subject: Re: CASE - The Emperor has no clothes on! Keywords: CASE rubbish Message-ID: <25254@athertn.Atherton.COM> Date: 13 Jun 90 16:26:18 GMT References: <25200@athertn.Atherton.COM> <137090@sun.Eng.Sun.COM> <37538@genrad.UUCP> <5190@stpstn.UUCP> Sender: news@athertn.Atherton.COM Reply-To: mcgregor@hemlock.Atherton.COM (Scott McGregor) Organization: Atherton Technology -- Sunnyvale, CA Lines: 127 I have discovered that my editing window size had accidentally been changed before my last posting, contributing to it being difficult to read. I wish to apologize for this, and I have attached a fixed version of my posting. Sorry ---Scott >> The trouble with Computer Aided Software Engineering is that it >> presumes the existence of such a thing as Software Engineering. >After working with CASE for a number of years, one day it dawned on me >that *all* software is developed using CASE! Ever develop software >without the aid of a computer? :-) (keypunches don't count..) I agree with Jim Becker; CASE is a multifacetted term and means much more than simple SA/SD drawing tools. Software engineering is the making of tradeoffs to produce a program that satisfies minimum expectations of those people who directly or indirectly will pay to use the program. (I use SATISFIES, as opposed to OPTIMIZE quite intentionally. And it is the unwritten expectations not the written ones that are the really critical ones. I derive these principles from Herb Simon's micro-economic model of "satisficing behavior"). In CASE, it is "Software" because that is the structural material from which solutions are built. It is "Engineering" because it involves the some of the same sort of complexity management tradeoffs as one might see in Industrial Engineering or other Engineering disciplines. Of course that doesn't mean that the techniques and principles of safe design are as mature as in these other disciplines, just that the required tradeoff analysis is comparable. Computer Aided simply means that "computers" are used to more easily develop software that satisfies the requirements. As Jim Becker points out in his reply to Brad Cox above, we mostly do use computers to develop software. So I think that CASE is a good thing, but frequently much maligned because so many tools marketted as "CASE" under deliver on their computer aided promise. A similar situation has occurred in "Software Reuse". I think that in fact a considerable amount of software development is done WITH large amounts of "software reuse". However, the libraries being reused are the programmer's own past programs. Many of the "most productive" programmers are those with the most extensive private libraries, typically the most senior programmers. But when those programmers are moved to a new OS, and new programming language they usually get hit hard with a learning curve, which is really the re-generation of a critical mass of self-written utility routines in their new OS and programming libraries. So the problem of software reuse may not really be the problem of getting people to reuse code--they do that already--the problem may be getting them to reuse other peoples code, and in *motivating* them to search and understand for other people's reusable routines. I've had plenty to say on this topic before, especially with respect to a historical situation I observed concerning a human technical librarian who maintained a software library, so I won't repeat that again unless there are further requests. But, I think there is an analagous problem for CASE tools. I think that tools are possible that do considerably more to aid software development than most tools marketted as CASE today. I would say that some of the integrated program development environments, such as LightSpeed C, some APSEs, and even the EMACS Lisp development environment are substantial contributions to computer aided software development over just separate editors, and compilers and linkers that many people still develop with. However, if we are to really address COMPUTER AIDED software development, I think we should re-examine what it is about humans that needs aiding, and what computers do better that might be used to aid the humans in their weak areas. In my previous articles and talks on use of "Prescient Agents" in CASE, I have mentioned three areas that human capabilites could benefit from computer aid: 1) Augment Human Memory. Human short term memory is extremely limited--typically 7 plus or minus 2 "chuncks" of associative memory seem to be all that most of us have. This makes it hard to manage complex tasks that require us to constantly remember many items and relationships. Human long term memory is subject to total loss as well as corruption. In pre-computer times many techniques were developed to help remember multiple things. One of the most successful was reducing a memory to writing and keeping the writing around. From this the publishing industry developed. In the computer world the analogous memory augmentation tool is the database or repository. SA/SD tools are an attempt to provide one means of reducing some thoughts about system structure to a more permanent written material. 2) Improve Human Communication. Human communication is frequently at low baud rate. High bandwidth media like video or good written communication takes a long time to create. Voice medium is cheaper to create but carries less information in a unit time, and is harder to control from the recipient's standpoint. Because of this low bandwidth, we often undercommunicate, hoping or assuming that recipients of our communications will be able interpret our communication much more richly by applying a presumed shared context. (This problem of communication presuming a shared context is well known in knowlege engineering and is the focus of the very intriguing CYC project at MCC). If software developers are using their computers to do much of their work, many aspects of their context are implicit in the spatial and temporal relationships between their work artifacts. Because people often undercommunicate and over-assume that a full communication has occurred, we frequently note that things "fall through the cracks". Fred Brook's dictim that adding more programmers to a late project makes it later, and similar observations about the impossibility of doing good programs as the number of people involved increase due to the exploding inter-person communication problem are well known and traceable to this area. Because these computer can have a more complete capturing of environmental clues and context (assuming its more permanent memory is used), when it mediates a communication, it can also ensure a more complete transmission of context as well. This is one of the focusses of prescient agents. Computer mediated structured and semi-structured discourse (e.g. GIbis, Information Lens, the Coordinator...) are also attempts to aid humans in this arena. 3) Enhance Human Reasoning. Humans are not good at long repetative calculations where precision is required. Linear programs and similar techniques are one way of improving human reasoning. But attention focus management and other user interface techniques that help the user stay focussed on their tasks and not on their tools, which manage memory and mediate communication (a la Doug Engelbart's NLS and Augment) are also important here. I believe that CASE tools could go much further in the above direction than the have today. Much of the benefits in ME CAD and EE CAD tools are in their improved capabilities in the above three arenas rather than in their diagramatic methodologies, etc. which were frequently well established far before computers played much of a part. Scott L. McGregor mcgregor@atherton.com