Re: [SystemSafety] Logic

From: Steve Tockey < >
Date: Sun, 16 Feb 2014 03:22:28 +0000

A couple of comments:

First, include me in the camp with PBL and Dr. Knight: formality in software is critical, even if the application being developed isn't. As a "software professional" for over 37 years I'm constantly amazed at how informal 99% of the software development community is and their utter blindness to how much trouble that very informality leads to. I often say, "We are an industry of highly paid amateurs".

In my experience, not only is it possible to take a more formal approach to software development, it's at least an order of magnitude easier if we do.

Second, from a practical perspective most developers--me included--tend to have a hard time with all of the "upside-down As and the backwards Es" usually associated with truly formal approaches like Z, VDM, Larch, etc. There's a very interesting and relevant paper, IMHO:

Jeannette M. Wing, A Specifier's Introduction to Formal Methods, Computer, September 1990

To me at least, the gist of Wing's paper is that I should be able to use a comfortable surface notation, such as UML Statecharts and Class Diagrams as long as I have a clear mapping to a defined, formal underpinning (such as could be expressed in Z, VDM, etc.). I don't want to deal with upside-down As and backwards Es, and neither does my customer. But if I can have a formally define-able *single* interpretation of something like a UML Statechart then I get the all of the benefits the underlying formality provides together with the comfort, familiarity, and ease-of-use of something like a Statechart.

While we're on the topic of Statecharts, I would also like to toss out this fascinating (to me, anyway) paper:

M. von der Beek. A Comparision of Statechart Variants. In W.-P. de Roever H. Langmaack and J. Vytopil, editors, Formal Techniques in Real-Time and Fault-Tolerant Systems , number 863 in Lecture Notes in Computer Science, pages 128­148. Springer Verlag, September 1994.

If I remember correctly (I can't find my copy of the paper), the author describes about 17 significantly different valid interpretations of the semantics of Statecharts. In other words, von der Beek shows how the same Statechart has the potential to have as many as 17 different valid interpretations. Each interpretation would lead to a developer producing very different (behaviorally) code as an implementation of their specific interpretation--which is probably different than the interpretation intended by the creator of the Statechart. Talk about safety implications...

So while a lot of people are comfortable using simple modeling notations like Statecharts and Class Diagrams, to be really useful those diagrams have to be backed up by a single interpretation as defined by some underlying formal semantic. It doesn't necessarily have to be the same interpretation used by everyone else, but everyone here has to know--and agree--which single interpretation is in use.

This is how I interpret PBL's use of the term "FDL" in his original posting, some convenient-to-use surface notation that's backed up by a single, solid, formally defined interpretation.

Third, while "model-based development" may be a newish buzzword to a lot of people, some of us practitioners have actually been doing it for almost 30 years. And getting tremendous benefit out of doing it, too, I might add. For the life of me I simply can't understand why more software development isn't done that way. The majority of the problems commonly encountered on typical software projects simply goes away with model-based development. I'm in the process of putting together a position paper explaining what "model-based development" means to me and why I think it's vitally important for the software industry to move in that direction as quickly as possible. I'll be happy to share a draft of that paper with anyone who wants, just send me an e-mail asking for the "What is Code?" paper and I'll give you the draft when it's polished enough to share. I should have it share-able within a couple of days.

Finally, getting back to PBL's questions:

"I would think some understanding of how FDLs work is essential for any work in dependable engineering of SW. Do people agree? If so, could you please give me some evidence?"--I agree 100%. Evidence? My position paper on model-based development, von der Beek's paper on variability in Statechart semantics, and Wing's paper. I also have at least two case-study write ups where use of (well, at least semi-formal) FDLs made a huge difference in the project's outcome.

(paraphrased) "What specific formal logic needs to be taught?"--I'm not sure yet of the specifics. But I am sure that it has to be enough to provide the formal foundation for the modeling notations we find useful in software projects. I can tell you what modeling notations/methods I find useful, we can work together to figure out what underlying formal foundations would be needed.


-----Original Message-----
From: Peter Bernard Ladkin <ladkin_at_xxxxxx Date: Saturday, February 15, 2014 10:32 AM Cc: "systemsafety_at_xxxxxx <systemsafety_at_xxxxxx Subject: Re: [SystemSafety] Logic


obviously I agree with much of what you say. But I am discussing with people who believe that we
constitute an exception to much of it.

On 2014-02-15 16:02 , John Knight wrote:
> In my opinion, the situation is as follows:
> * To a very large extent, all software is critical in some way. Even
>gaming software, the failure
> of which could lead to loss of reputation, market, income, etc.

All commercial SW. But people in research areas such as AI and robotics write code all the time
which they just write. Small routines; they debug by running it; they build a cumulative collection
of more-or-less running code. That's been going on for forty years at least, probably sixty. If you
don't get the code right, then your thesis or paper is late.

The answer to the importance of SW would be "this is the kind of code we write here. Yes, other
people in industry may have to write dependable code there, but we are not pretending we teach those
techniques here, for we don't need them."

(Well, I think they do. At least some people are aware there are safety issues around mobile-robot
interactions. But I worked around that institute for four years and couldn't get anyone interested
in a safety analysis of what they were doing. They think it's stuff for lawyers and insurance
companies, not informaticians. That view will go swimmingly well until the first accident.)

> * All of engineering rests to some extent on mathematics.

No question. But which in particular? People around here would say they don't use logic. Indeed they
don't, for two reasons: (a) they don't know any; and (b) they don't write specifications for what
they do. And they don't appear to suffer any comparative disadvantage from that. If SW doesn't work,
then it doesn't work and they fix it or write something else or just don't graduate.

> * Discrete mathematics (the term I would use where you have used
>logic) is the mathematics of
> computer engineering.

Discrete math is way more than logic, of course. It includes standard things about sets and
relations. And combinatorics. The answer is that people here don't think they use any of that, for
similar reasons as above. "We don't do computer engineering - we do applied informatics for
robotics, and biology and chemistry and physics, and artificial cognition."

> * We will not make progress against the serious assurance challenges
>we face unless we apply
> mathematics.

Yes, but dependability of SW is not thought to be an issue for our students and their research.
"They will learn that in industry when they leave, if they need to."

> * All computer engineers should be trained to understand, appreciate
>and apply discrete mathematics.

Again, the response is that "we don't educate computer engineers".

There is a talk being given at the Heinz Nixdorf Institute in Paderborn next week on "Model-based
development of SW for intelligent industrial systems." Two of the CITEC people recommended it, one
of them highly. "Industrial intelligent systems" is a buzzword here, attached to a national program
based on regional industry/academic consortia of which we belong to the first. "Model-based
development" is also a newish buzzword. Of course, you can't do any "model-based" SW development
unless you use FDLs. Still, joining the dots here seems to be hard work. (The guy giving the talk is
a former student of Willi Schäfer.)


Prof. Peter Bernard Ladkin, Faculty of Technology, University of
Bielefeld, 33594 Bielefeld, Germany
Tel+msg +49 (0)521 880 7319

The System Safety Mailing List

The System Safety Mailing List
Received on Sun Feb 16 2014 - 04:22:46 CET

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:06 CEST