[SystemSafety] The Fosse of Babel

[Steve Tockey]

Olwen,

“What software engineering needs more than anything else is not new research but better application of what we already know”

Yes. Agreed.


“ . . . it's quite clear that we're NOT EVEN TRYING to design EELs - when the state of knowledge in computer science is almost certainly capable of giving an EEL suitable semantics and making compilers for it”

Maybe most people are not even trying, but some are. I think a lot of progress has already been made in that area.


“I posit that, if we ever get a firm grip on software quality, it will be because we have developed what I call, "end-to-end" languages - call them EELs for short. An EEL is a language into which we translate natural language requirements such that thereafter, all tasks in the software lifecycle can be supported directly by the EEL.

That means that an EEL must support:

1.    Statements of requirements

2.    Description of designs

3.    Low-level processing

4.    Unit and integration testing

5.    System testing

6.    Proof of correctness conditions at all life cycle stages

7.    Identification of configuration items (COBOL's Identification Division was prescient here - three cheers for Auntie Grace)

... and generally any other task in the life cycle related to product quality.”

While I don’t claim to hav fully solved the EEL problem, I think I have a pretty good solution to the problem that has been used on a number of real-world, significantly-sized projects. It is all written up in a manuscript that’s under contract with IEEE Computer Society Press (aka Wiley) titled, “How to Engineer Software". Since it’s not published yet, I will continue to make the manuscript available “for review purposes”.  It is available on DropBox:

https://www.dropbox.com/sh/jjjwmr3cpt4wgfc/AACSFjYD2p3PvcFzwFlb3S9Qa?dl=0

There is a companion demonstration model editor and model compiler available at

https://www.dropbox.com/sh/7vbg4dgzf1ipqua/AABYnykze04x4VqEuzIBvcxba?dl=0


I think these are the key features relevant to your notion of an EEL:

*) It all centers around the notion of a “Semantic Model” that captures the precise policy and process semantics that are the reason for building the software in the first place. Software exists to automate enforcement of some set of “policies” and carry out some set of “processes”. For the developers to automate the right policies and processes, those developers need to understand those semantics at least as well (if not better) than the domain experts understand it. Part II of the book, chapters 7 through 12, explain how to build, evaluate, and maintain these semantic models. One of the sections in Chapter 12 does talk about how to derive acceptance test cases from the semantic model.

*) The semantics of the semantic models (the “meta-model”) is presented in Appendix L. It shows how the semantic modeling language is grounded in fundamental discrete mathematics and computer science like Set Theory, Finite Automata Theory, Measurement Theory, etc. It is almost certainly not at a level of formalism that some esteemed members of this group would necessarily approve of, but at least it is a pretty solid start.

*) Part III, chapters 13 through 22, show how a semantic model can be translated into design and code. Chapters 14 through 17 discuss by-hand translation. Chapters 20 and 21 discuss “open model compilation” automation translation where derivation of executable code is controlled by an open, rule-based compiler. If you don’t like the generated source code, you don’t edit the generated code. You edit the production rules and have the compiler generate the code that you do like.

*) Chapter 18 discusses a number of formalisms in software: “Programming by Intent”, proper use of assertions, proofs of correctness, . . .

If you read the manuscript, I would appreciate hearing your impressions of it. You might want to start with the outline (“aOutline.pdf”) to get a sense of the overall structure of the book and then move into the detailed chapters.


Best,

— steve



From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de<mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de>> on behalf of Olwen Morgan <olwen.morgan at btinternet.com<mailto:olwen.morgan at btinternet.com>>
Date: Friday, September 21, 2018 at 7:25 AM
To: "systemsafety at lists.techfak.uni-bielefeld.de<mailto:systemsafety at lists.techfak.uni-bielefeld.de>" <systemsafety at lists.techfak.uni-bielefeld.de<mailto:systemsafety at lists.techfak.uni-bielefeld.de>>
Subject: [SystemSafety] The Fosse of Babel



" ...  let us go down, and there confound their language, that they may not understand one another's speech.So the Lord scattered them abroad from thence upon the face of all the earth ..."

Genesis 11:7-8


(No, by quoting part of the Tower of Babel story I've not suddenly gone all god-bothering - I'm more of a Buddhist than anything else). But this serves to introduce an idea:


Ask around and I expect you'd find a reasonable consensus that mathematics is the hardest thing in the sciences and translation is the hardest thing in the humanities. (As an occasional translator, FR-EN and DE-EN, I can certainly vouch for this as regards translation.)


Now, by the standards of hard mathematics, the kind of mathematics that you need to do software engineering rigorously isn't particularly hard. On the other hand something that is done in every software process I've seen is translation. We start with requirements in natural language, we do design in another formalism, programming in another and testing using yet further formalisms. Much of the use of mathematics in software engineering is to provide a lingua-franca that allows us to reason about whether a description of something in one kind of formalism is actually consistent with its description in a different formalism.


This makes pertinent the question of WHY the software engineering process is one of successive translations between different formalisms. Are we not asking for trouble if we have to use the most difficult thing in the sciences to keep us afloat because we're doing the most difficult thing in the humanities?


I posit that, if we ever get a firm grip on software quality, it will be because we have developed what I call, "end-to-end" languages - call them EELs for short. An EEL is a language into which we translate natural language requirements such that thereafter, all tasks in the software lifecycle can be supported directly by the EEL.

That means that an EEL must support:

1.    Statements of requirements

2.    Description of designs

3.    Low-level processing

4.    Unit and integration testing

5.    System testing

6.    Proof of correctness conditions at all life cycle stages

7.    Identification of configuration items (COBOL's Identification Division was prescient here - three cheers for Auntie Grace)

... and generally any other task in the life cycle related to product quality.


An obvious thing to do is to start designing languages that include annotations for; proofs, testing, configuration control, etc. Proof annotation are well established in SPARK Ada and within the Frama C project. It would be no great task to include proof annotations in a language itself. Proof annotations could also support automatic test generation.


Yet, looking at current programming languages, it's quite clear that we're NOT EVEN TRYING to design EELs - when the state of knowledge in computer science is almost certainly capable of giving an EEL suitable semantics and making compilers for it. What software engineering needs more than anything else is not new research but better application of what we already know.


O


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20180922/de995a3b/attachment-0001.html>