Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!brolga!uqcspe!batserver.cs.uq.oz.au!brendan From: brendan@batserver.cs.uq.oz.au (Brendan Mahony) Newsgroups: comp.specification Subject: Re: Difference between Spec and Code? Message-ID: <5624@uqcspe.cs.uq.oz.au> Date: 12 Nov 90 00:53:00 GMT References: <1990Nov08.035857.6734@comp.vuw.ac.nz> <9188@latcs1.oz.au> Sender: news@uqcspe.cs.uq.oz.au Reply-To: brendan@batserver.cs.uq.oz.au Lines: 62 As I have already stated, I believe the purpose of the (highest) specification should be to describe the requirements of the system as clearly and succintly as possible. For the most part this aim is well served by concentrating on what must be done rather than how is should be done. The details of algorithms are usually complex and more difficult to understand than a simple statement of the aim of the algorithm. Moreover the less said at first about how, the greater the freedom of choice is at subsequent stages of development. However it should always be remembered that the primary aim is clarity and that a theological pursuit of abstractness will often run contrary to this aim. Thus it is often productive to use off-the-shelf data structures such as queues and stacks in the initial specification. Even if they must later be eliminated from the design they will improve understandability. I feel I must question Cybulski's advocacy of early emphasis of procedural aspects. This faces the danger of obscuring the purpose of the system under construction. Further he attempts to support his case by claiming that greater flexibility may be gained by early considerations of procedural aspects. I find this proposition extremely doubtful. It is fairly clear the later introduction of procedural concerns aids flexibility rather than the contrary. In particular it may allow a cheaper non-computerised solution to be found. jacob@latcs1.oz.au (Jacob L. Cybulski) writes: >Let me give you a nice texbook example, ref. Barbee Teasley Mynatt "Software >Engineering with Student Project Guidance," Prentice-Hall Int. The book >introduces the problem of estimating and projecting ticket sales revenues >from art performances. The author adopts Yourdon and DeMarco methodology, >and introduces a series of neat developments steps leading from REQUIREMENT, >and SPECIFICATION through DESIGN to the IMPLEMENTATION and TESTING. >Somewhere between the design and implementation there is a SELECTION of the >programming language, i.e. Pascal. An interesting thing about this >particular example is that if a decision were made to implement the program >in a spreadsheet, then about 90% of the development effort could have been >avoided, i.e. detailed specs, flows, data dictionaries, then algorithm >elaborations, etc. To make it worse the technical requirements for the >project would allow the spreadsheet-based system to provide the correct >time-space efficiency. I do not deny the value of the text but I think that >this strong separation of WHATs and HOWs at the early stage of software >development was actually to the detriment of entire project. I think you should ponder this example more. First the criteria Cybulski uses to determine that a spreadsheet would offer a better solution are themselves non-procedural. He seems to feel that the early emphasis on on what has lead inexorably to the use of a low level language, Pascal. In fact it is more likely the decision to use a standard procedural language was made much earlier than the particular selection of Pascal. Possibly this decision was made too early, thus leading to all the wasted work on data dictionaries etc. It seems very likely the entire methodology is predicated on the decision that languages such as Pascal would be used in the coding phase. Of course it may be the case that a simple ledger, a pen and a calculator would provide the best price to performance ratio :-). -- Brendan Mahony | brendan@batserver.cs.uq.oz Department of Computer Science | heretic: someone who disgrees with you University of Queensland | about something neither of you knows Australia | anything about.