[SystemSafety] The Fosse of Babel

Sun Sep 23 22:28:35 CEST 2018

Steve,

I've had a brief look at it but am pressed right now, so will take a 
while to look more fully.

I agree with the principles ...

... but I personally wouldn't touch UML with a double-length, 
disinfected barge-pole. It, and most other manifestations of OO, have 
always seemed to me like an unnatural and byzantine solution looking for 
a problem. My beef with it is that it is unnecessarily complex for what 
it achieves, its formal semantics had to be retro-fitted (where they are 
used at all), and anything that I might try to achieve in UML, I can 
achieve more concisely and more clearly in structured methods (my 
favourite being a radically cut-down subset of SSADM with direct 
translation from semi-formal artefacts to a soundly-based modelling 
formalism).

Besides, I think it is a fundamental mistake to have the notion of 
"object" as an organising principle for expressing requirements and 
designs. Abstract data types are fine. It's when you get into multiple 
inheritance and polymorphism that, in my experience, the whole thing 
becomes unstuck. The most opaque and muddled designs I've ever seen have 
been formulated in UML. Moreover, to my mind at least, the notion of 
"process" is a more useful abstraction than that of "object". Why go to 
OO when most systems can be designed perfectly well and more simply as 
action-systems?

My preference is for something that is leaner and more mathematical from 
the start. I find that going from a cut-down SSADM to Coloured 
Petri-Nets (CPNs) works fine - the translation of artefacts can be quite 
direct and the CPN  formalism is a lot closer to the underlying 
mathematics to start with than UML.

There is, I admit, a bias here. For the latter quarter of my 
professional life, I have as far as possible avoided getting involved in 
large projects unless they are being done by exceptionally capable 
companies. In my experience, the larger a project is, the more likely it 
is that you'll come across a project in which key initial decisions have 
been taken by some ignoramus who commits the project to a fundamentally 
mistaken approach from the outset. Also, large projects on large 
machines often use COTS software with poorly-documented, cr at p APIs that 
really p!ss me off to use. And this is not to mention the 
lumpenprogrammers you may end up having to work with.

Focussing on smaller projects, latterly mostly bare-metal embedded 
stuff, and having significant input at the front end of the project, 
it's easier to steer people clear of daft decisions from the outset. 
Also, when programming for bare metal, I don't have to shoe-horn 
software into using some badly-design API. I write what I need myself.

I've been familiar with formal methods for over 40 years. (In fact, I 
was a founder member of the BCS-FACS Specialist Group). Perhaps 
hubristically, I consider myself quite able to pick methods and tools 
that will best serve my purpose. If someone asks me to use anything 
that's ever referred to as a "methodology", then, with a few noble 
exceptions, I'll tend to consider him/her incompetent until proven 
otherwise - especially if all his/her technical decisions are framed in 
terms of the said methodology rather than in mathematically-based methods.

I do not use "methodologies". I use methods and tools with a pretty 
direct basis in mathematics. IMO "methodologies" are for those whose 
command of mathematics is so p!ss-poor that they shouldn't be let 
anywhere near critical systems engineering in the first place.

Finally, and you may think paradoxically, I don't put this out as an 
attack on your approach. I agree with such of your principles as I've 
seen in what I've looked at in your manuscript. It's just that my 
professional experiences with projects that have used UML/OO has almost 
always been depressing. I now avoid such projects as much for my mental 
health as for anything else - and that is not hyperbole - I mean it 
literally.

End of compact and bijou rantette ;-))
O

On 22/09/18 11:54, Steve Tockey wrote:
>
> 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
>
>
>

-- 
Olwen Morgan CITP, MBCS olwen.morgan at btinternet.com +44 (0) 7854 899667 
Carmarthenshire, Wales, UK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20180923/05c11d23/attachment-0001.html>