Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!mel.dit.csiro.au!latcs1!jacob
From: jacob@latcs1.oz.au (Jacob L. Cybulski)
Newsgroups: comp.specification
Subject: Re: Difference between Spec and Code?
Message-ID: <9188@latcs1.oz.au>
Date: 9 Nov 90 03:46:12 GMT
References: <1990Nov08.035857.6734@comp.vuw.ac.nz>
Organization: Comp Sci, La Trobe Uni, Australia
Lines: 64

In article <9169@latcs1.oz.au>, I gave a description of a constraint-based
program development in which you can assume the SPECIFICATION to be a set of
constraints the PROGRAMS have to adhere to. Such constraints could either be
declarative (WHAT) or procedural (HOW).

From article <1990Nov08.035857.6734@comp.vuw.ac.nz>, by lindsay@comp.vuw.ac.nz (Lindsay Groves):
> 
> I don't understand what you are getting at -- could you elaborate?

In most of the SE literature it has been assumed that specifications must be
structured around WHATs and the designs and programs should provide the
details of HOW. In any practical software development the three phases are
inter-leaved and the rigourous sequencing of WHAT and HOW could actually
hamper developers efforts. Thus, some newly proposed methodologies (e.g.
rapid prototyping, exploratory programming, etc.) attempt to introduce the
HOWs at the early stages of software development.

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.

And this was only an artificial and a very classical problem. With the
advent of computer technologies, executable specs, logic programming,
constraint-based languages, etc., we cannot rely on the nicely structured
methodology, we cannot even guarantee that the development will ever address
the issues of HOW, or that perhaps in some environments the WHATs and HOWs
will have to be specified together.

So, I propose not to separate the WHATs and HOWs, but rather to structure
projects around the refinement stages. At any stage the software product
consists of the set of organisation constraints related to the issues of
project management, i.e. its resources, milestones, deadlines, and plans;
requirement constraints outlining user goals, preferences and limitations;
and development constraints specifying the technology in use, i.e.
algorithms, data structures, tools and methods. Any of the development
stages could address a range of issues to some degree and refine them at a
later stage. The implementation is just the process of constraint
satisfaction and in case of certain programming languages (e.g. PROLOG),
consists in extending the set of constraints until its completion.

Jacob L. Cybulski

Amdahl Australian Intelligent Tools Programme
Department of Computer Science
La Trobe University
Bundoora, Vic 3083, Australia

Phone: +613 479 1270
Fax:   +613 470 4915
Telex: AA 33143
EMail: jacob@latcs1.oz.au