des0mpw@colman.newcastle.ac.uk (M.P. Ward) (10/31/90)
In article <BLK.90Oct25142230@vanity.mitre.org>, blk@mitre.org (Brian L. Kahn) writes: > > For some time, I've puzzled over the difference (if any) between a > specification language and a programming language. The best I can > come up with is that a spec has less information about data structures > and/or algorithms than is usually found in code. ... I always used to say "a specification is more abstract than a program" (there is a continuum here ranging from "low-level" programs to "highly abstract" specifications - its not an either-or relation). Then I was challenged to define what I meant by "more abstract". The best definition I could come up with was SMALLER (and more readable - but the metric which coresponds most closely to intuitive notions of readablility is size!). Naturally, for a specification to be smaller it _has_ to contain less information: the input-output behaviour is arguably the most useful information to a user of the program, therefore the specification will have less (or no) information about data structures and algorithms. A secondary attribute of a good specification is separation of concerns. For example: one part of the spec will specify "normal" behaviour, another part will specify the action take under various error conditions. In the implementation the error handling code will be deeply intertwingled with the "normal case" code - but they are logically separate and should be separate in the specification. Another example is a report printing program where one part specifies the headings and record formats and another part specifies the pagenation (lines per page, headers and footers on each page, page count etc.) and perhaps a third part defining the end of report totals as a function of the whole database. In the implementation these will be deeply mixed, with the record formatter incrementing the line count, report totals etc. Martin. JANET: Martin.Ward@uk.ac.durham Internet (eg US): Martin.Ward@DURHAM.AC.UK or if that fails: Martin.Ward%uk.ac.durham@nfsnet-relay.ac.uk or even: Martin.Ward%DURHAM.AC.UK@CUNYVM.CUNY.EDU BITNET: IN%"Martin.Ward@DURHAM.AC.UK" UUCP:...!mcvax!ukc!durham!Martin.Ward
lindsay@comp.vuw.ac.nz (Lindsay Groves) (11/06/90)
In article <1990Oct31.102351.21789@newcastle.ac.uk>, des0mpw@colman.newcastle.ac.uk (M.P. Ward) writes: |> In article <BLK.90Oct25142230@vanity.mitre.org>, blk@mitre.org (Brian |> L. Kahn) writes: |> > |> > For some time, I've puzzled over the difference (if any) between a |> > specification language and a programming language. The best I can |> > come up with is that a spec has less information about data |> structures |> > and/or algorithms than is usually found in code. ... |> |> I always used to say "a specification is more abstract than a |> program" |> (there is a continuum here ranging from "low-level" programs to |> "highly |> abstract" specifications - its not an either-or relation). Then I |> was |> challenged to define what I meant by "more abstract". The best |> definition |> I could come up with was SMALLER (and more readable - but the metric |> which coresponds most closely to intuitive notions of readablility is |> size!). |> Naturally, for a specification to be smaller it _has_ to contain |> less |> information: the input-output behaviour is arguably the most useful |> information to a user of the program, therefore the specification |> will |> have less (or no) information about data structures and algorithms. It may be helpful to distinguish between the following questions: (i) what kind of text CAN be considered to be a specification/program? (ii) what kind of thing you SHOULD write in a specification/program? If you are concerned with (i), then Brendan's answer (that programs are the executable subset of specifications) is fine. If you are concerned with (ii), that answer is not at all helpful. In this case you would be hard pressed to better than the old adage (anyone know who said this first?): a specification should say WHAT is to be done, not HOW it is to be done. Saying that a specification is "more abstract" than a program does mean that it contains less information. The whole point, however, is that the "missing" information is concerned with HOW rather than WHAT, so (from the specifiers point of view) it is irrelevant. Such information should not be part of a specification because it clutters the specification with unnecessary detail, making it harder to understand, and because it restricts the range of possible implementations. This is precisely the point made in the article by Cliff Jones and Ian Hayes which someone mentioned a week or so back ("Specifications are not (necessarily) executable") -- that restricting formal specifications in such a way as to make them executable restricts their expressiveness and restricts possbile implementations. Lindsay
brendan@batserver.cs.uq.oz.au (Brendan Mahony) (11/06/90)
lindsay@comp.vuw.ac.nz (Lindsay Groves) writes: >It may be helpful to distinguish between the following questions: > (i) what kind of text CAN be considered to be a specification/program? > (ii) what kind of thing you SHOULD write in a specification/program? >If you are concerned with (i), then Brendan's answer (that programs are >the executable subset of specifications) is fine. If you are concerned >with (ii), that answer is not at all helpful. In this case you would be >hard pressed to better than the old adage (anyone know who said this >first?): a specification should say WHAT is to be done, not HOW it is to >be done. I think my definition does address this point (ii). If you require your specification to be executable then you are requiring that it detail (either explicitly ot implicitly through language convention) HOW the required effect may be achieved. If you do not require it to be executable then you are freed from the NECESSITY to specify details of HOW, though these may still be useful. >Saying that a specification is "more abstract" than a program does mean >that it contains less information. Perhaps more to the point, it contains fewer constraints, allowing the implementer greater freedom of action in producing the software. The primary purpose of the specification process should be to describe the system (not just software) requirements with the maximum clarity. Generally this will be assisted by paying more attention to WHAT than to HOW. Some HOW type things are so well known (e.g. the standard model of the integers, sequences etc) that their use does contribute the clarity of the specification. For example it is almost impossible to clearly specify an indexed stack without basing the specification on sequences. Though using sequences in the specification is clearly introducing an implementation bias, it is still better to do it this way since it makes the specification clearer. This is of course just my theological slant. -- 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.
mitchell@chance.uucp (George Mitchell) (11/06/90)
In article <1990Nov06.020123.29702@comp.vuw.ac.nz> lindsay@comp.vuw.ac.nz wrote: `In article <1990Oct31.102351.21789@newcastle.ac.uk>, `des0mpw@colman.newcastle.ac.uk (M.P. Ward) writes: `|> Naturally, for a specification to be smaller it _has_ to contain `|> less information: the input-output behaviour is arguably the most `|> useful information to a user of the program, therefore the `|> specification will have less (or no) information about data `|> structures and algorithms. ` .... `Saying that a specification is "more abstract" than a program does mean `that it contains less information. The whole point, however, is that `the "missing" information is concerned with HOW rather than WHAT, so `(from the specifiers point of view) it is irrelevant. In the opening chapter of _Essential_Systems_Analysis_ McMenamin and Palmer give some background of logical vs. physical, what vs. how, and strategic vs. tactical. All in all, their concept (and presentation) of "essence" and "incarnation" is very helpful. Essence: "all characteristics of a planned response system that would exist if the system were implemented with perfect technology." Essence = Essential activities = Essential memory Essential activities: "Those tasks that the system would have to do even if you could implement it using perfect technology." Essential memory: "All the data the system would have to remember if all it did was carry out the essential activities." Essential activities are divided into two, not mutually exclusive, categories: Fundamental activities and Custodial activities. Fundamental activity: "Performs a task that is part of the system's stated purpose." Custodial activity: "Establish and maintain the system's essential memory." Stimulus Stimulus | | V V -------------- --------------- Response | Custodial : : Fundamental |-------------> | Activitity : : Activity | -------------- --------------- | ^ Response | | _V____________|_ Essential Memory ---------------- -- George Mitchell, MITRE, MS Z676, 7525 Colshire Dr, McLean, VA 22102 email: gmitchel@mitre.org [alt: mitchell@community-chest.mitre.org] vmail: 703/883-6029 FAX: 703/883-5519
mitchell@chance.uucp (George Mitchell) (11/06/90)
Oops, in article <125516@linus.mitre.org> I wrote:
` Essence = Essential activities = Essential memory
^^^
Of course this should have been:
Essence = Essential activities + Essential memory
--
George Mitchell, MITRE, MS Z676, 7525 Colshire Dr, McLean, VA 22102
email: gmitchel@mitre.org [alt: mitchell@community-chest.mitre.org]
vmail: 703/883-6029 FAX: 703/883-5519cliff@cs.man.ac.uk (Cliff Jones) (11/06/90)
In article <1990Oct31.102351.21789@newcastle.ac.uk> des0mpw@colman.newcastle.ac.uk (M.P. Ward) writes: >I always used to say "a specification is more abstract than a program" >(there is a continuum here ranging from "low-level" programs to "highly >abstract" specifications - its not an either-or relation). Then I was >challenged to define what I meant by "more abstract". The best definition >I could come up with was SMALLER (and more readable - but the metric >which coresponds most closely to intuitive notions of readablility is size!). I have used the argument of size myself but I think it is less important than the tractability of the specification languages we should like to see used. It is - for example - true that a specification in terms of objects like sets and maps is shorter than one in terms of bytes/pointers but the key issue is that one can reason about the mathematical objects precisely because they have evolved to systems with sets of operators with nice algebraic properties. BTW I still stand by the *technical* arguments given in the paper by Hayes/Jones referred to earlier in this news group. cliff jones
jacob@latcs1.oz.au (Jacob L. Cybulski) (11/07/90)
Well, a number of people stressed the importance of WHAT-type of issues in program specifications and HOWs of the programs themselves. I am sure that this approach is quite valid for the traditional software process, what I am not certain of if it is valid for all types of applications. If it were correct to assume that a SPECIFICATION if a collection of constraints to be met by a series of statements constituting our PROGRAM then the questions of WHAT and HOW become quite irrelevant, since the constraints and limitations imposed by our specs may apply to both procedural and declarative aspects of our development process. According to our definition, for certain classes of programming languages, e.g. logic or constraint programming languages, SPECIFICATIONS then become partially refined PROGRAMS, to further this statement, once the SPEC is developed in sufficient detail, our development environment, as consisting of the set of programming heuristics, may actually provide the missing details automatically, thus resulting in executable specifications. Jacob L. Cybulski Amdahl Australian Intelligent Tools Program 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
lindsay@comp.vuw.ac.nz (Lindsay Groves) (11/08/90)
In article <9169@latcs1.oz.au>, jacob@latcs1.oz.au (Jacob L. Cybulski) writes: |> ... |> If it were correct to assume that a SPECIFICATION if a collection of |> constraints to be met by a series of statements constituting our |> PROGRAM then the questions of WHAT and HOW become quite irrelevant, |> since the constraints and limitations imposed by our specs may apply |> to both procedural and declarative aspects of our development process. I don't understand what you are getting at -- could you elaborate? |> According to our definition, for certain classes of programming languages, |> e.g. logic or constraint programming languages, SPECIFICATIONS then become |> partially refined PROGRAMS, to further this statement, once the SPEC is |> developed in sufficient detail, our development environment, as |> consisting of |> the set of programming heuristics, may actually provide the missing |> details |> automatically, thus resulting in executable specifications. My understanding of the notion of refinement is that you start with some general (perhaps imprecise) description of what you are trying to do (ie WHAT) and gradually "refine" it by adding more details, making decisions about data structures, algorithms etc. (ie HOW). I don't see that this makes the distinction between WHAT and HOW irrelevant. If you mean something else by partially refined, please explain. Using a set of heuristics to provide the missing details (or, at least, A VERSION OF THE MISSING DETAILS) is better than constraining specifications to make them executable, but doesn't provide a complete solution (that is to say, one that I would be satisfied with) to the problem of software development, as I might want to use data structures and algorithms other than the ones provided by these heuristics. |> Jacob L. Cybulski |> |> Amdahl Australian Intelligent Tools Program |> Department of Computer Science |> La Trobe University |> Bundoora, Vic 3083, Australia I would be interested to hear what the "Amdahl Australian Intelligent Tools Program" is and what it does. Would you care to post a few details? Lindsay
jacob@latcs1.oz.au (Jacob L. Cybulski) (11/09/90)
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
brendan@batserver.cs.uq.oz.au (Brendan Mahony) (11/12/90)
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.