[SystemSafety] Logic

[Steve Tockey]

All,
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.




Cheers,

-- steve



-----Original Message-----
From: Peter Bernard Ladkin <ladkin at rvs.uni-bielefeld.de>
Date: Saturday, February 15, 2014 10:32 AM
To: "knight at cs.virginia.edu" <knight at cs.virginia.edu>
Cc: "systemsafety at techfak.uni-bielefeld.de"
<systemsafety at techfak.uni-bielefeld.de>
Subject: Re: [SystemSafety] Logic

John,

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.)

PBL

-- 
Prof. Peter Bernard Ladkin, Faculty of Technology, University of
Bielefeld, 33594 Bielefeld, Germany
Tel+msg +49 (0)521 880 7319  www.rvs.uni-bielefeld.de




_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE