jls@netcom.COM (Jim Showalter) (06/13/91)
A discussion about formal specification methods got started over in comp.software-eng, to which I posted the below response. Via e-mail, someone suggested this should be posted to this group too, so here goes: [someone with whom I agree states:] >I'd assert, however, that >more than 95% of a reasonably sized program's code is an attempt at writing >a non-ambiguous specification. 1/2 :-) Excellent point, and a great way to succintly express my dissatisfaction with formal specification languages. I have seen such languages work well in a restricted domain (e.g. state transition tables), but in the larger scheme of things they either wind up too specific for the general case, or so general they are no longer concise. I am reminded of a time when a former employer was considering changing its method of implementing document generators from writing programs in Ada to using a textual grammar to write "meta-documents" that would then be compiled to Ada code via a translator. On the surface this new method had a lot of appeal--it would eliminate the need to write Ada code just to generate documents, it seemed like it would be an easier language to learn because it was specialized to document generation, it was closer to the end product (documentation) so it seemed like a more natural mapping between the problem space and the solution space, etc etc etc. On closer investigation, however, the scheme broke down: we kept finding places where we would need to add more complexity to the specification language in order to handle this or that case that had arisen in the course of generating documents, until the resulting grammar was nearly as complex as Ada itself but WITHOUT a base of commercially available parsers, formatters, editors, compilers, debuggers, etc. Yes, we considered the hybrid strategy of providing a general grammer for 80% of the cases with an escape-to-Ada mechanism for the trickier cases, but we realized that this made nobody particularly happy--now the implementor was faced with mastering TWO programming languages, plus which the onus of providing a means of communication among the various Ada-escapes was placed on the implementor (how, for example, do you hand global state back and forth between separated invocations of individual Ada programs?...). In the end, we concluded that the initial appeal of "simplicity" for the textual strategy didn't hold up under analysis, and that sticking with pure Ada implementation was the superior strategy. I think there is a lesson here for anyone who wants to specify systems in a formal language--it may well be the case that any time one wants to formally specify a system of suitable complexity to be interesting, the resulting specification language is itself so complex that it provides scant improvement over English or, alternatively, the language of implementation itself. (There are certainly development groups I'm aware of that use Ada as their specification and implementation language.) -- *** LIMITLESS SOFTWARE, Inc: Jim Showalter, jls@netcom.com, (408) 243-0630 **** *Proven solutions to software problems. Consulting and training on all aspects* *of software development. Management/process/methodology. Architecture/design/* *reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++. *
brendan@cs.uq.oz.au (Brendan Mahony) (06/13/91)
In <1991Jun12.203347.17380@netcom.COM> jls@netcom.COM (Jim Showalter) writes: >[someone with whom I agree states:] ->I'd assert, however, that ->more than 95% of a reasonably sized program's code is an attempt at writing ->a non-ambiguous specification. 1/2 :-) It would seem that 5% of the program code is completely wasted then :-). >I think there is a lesson here for anyone who wants to specify systems >in a formal language--it may well be the case that any time one wants >to formally specify a system of suitable complexity to be interesting, >the resulting specification language is itself so complex that it provides >scant improvement over English or, alternatively, the language of >implementation itself. (There are certainly development groups I'm aware >of that use Ada as their specification and implementation language.) I think you are getting a little bit confused between two connotations of the word specify. I would label them specify-requirements and characterise. If you want a full characterisation of the behaviour of a program then it is likely that you will be able to express it most succinctly in the programming language itself. This is the most complete specification of the expected behaviour of the program. If on the other hand you simply want to specify what you intend to use the program to do, it is rare that arrays, files, pointers, interrupts etc are required to express your meaning. The best language to write this specification is the language people normally use in discussing the sort of problem that is to be solved. If you wish to perform integer calculations then integer arithmetic proves the appropriate language; if you wish to heat a room you use the language of thermodynamics; etc.. What you really need is a specification language that lets you adopt the vocabulary appropriate to the application domain. It is also useful to adopt a development strategy that lets you progressively replace the language of the application domain with the language of programming (arrays, files, pointers, etc.) so that each level of development may be discussed in the most appropriate language for the objects being manipulated. -- 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.