[SystemSafety] Modelling and coding guidelines: "Unambiguous Graphical Representation"

[Matthew Squair]

Isn't there also a trade-off between expressiveness and 'unambiguity'?

On Mon, Feb 29, 2016 at 9:53 AM, Les Chambers <les at chambers.com.au> wrote:

> Malcolm
>
> I look forward to the day when standards bodies screw up the courage to
> mandate the state engine as the core modelling technique in control
> systems. They'd only be stating what anyone with any experience in
> designing, building and operating these systems has known for decades.
> Personally I don't care which species of state engine you use as long as
> the core concepts first introduced by Mealy (1955 paper, “A Method for
> Synthesizing Sequential Circuits”) and Moore (1956 paper,
> “Gedanken-experiments on Sequential Machines”) are at the core of your
> design.
>
> Every time I use this model I reinforce my original opinion as to what a
> great idea it is. You use less (simpler) code to achieve the same result
> and on reviewing your code 6 to 12 months later what you did and why you
> did it is much clearer. I'm currently dealing with 400 files full of my own
> code expressed in JavaScript, the jQuery JavaScript libraries, PHP, SQL,
> MySQL stored procedures and HTML. Even web applications are now heavily
> event oriented requiring a state based point of view. These apps are now
> redolent with asynchronous communications turning what used to be a simple
> job into something more resembling an operating system kernel hack. The
> object-oriented paradigm is also extremely useful, organising your code so
> you can find those few lines that are doing something they shouldn't be.
>
> Without these two fundamental approaches I and many people like me would
> have a huge problem understanding our own code two weeks after we wrote it
> (I thought I was alone with this problem until a few weeks ago when I
> discovered that several other software engineers who are much smarter than
> me have the same issue - the problem gets orders of magnitude worse with
> large software development teams).
>
>
>
> When will these standards wonks understand that pussyfooting around using
> terms like "unambiguous graphical representation" is unhelpful, creating a
> massive ambiguity in the standard itself which, as a flow on effect, spawns
> and industry in compliance gaming and wastes developers time - the
> beginnings of which we have seen on this list with all the various posts as
> to "what does it mean????"
>
> Just tell em, "Use a state engine pilgrim, or be dammed!"
>
> And to Steve Tockey - writing a book on your "representations" - go you
> good thing (Rugby metaphor). I'm sure the state engine will be prominent.
>
> Cheers
>
> Les
>
>
>
> *From:* systemsafety [mailto:
> systemsafety-bounces at lists.techfak.uni-bielefeld.de] *On Behalf Of *Watts
> Malcolm (AE/ENG1-AU)
> *Sent:* Friday, February 26, 2016 6:01 PM
> *To:* systemsafety at TechFak.Uni-Bielefeld.DE
> *Subject:* [SystemSafety] Modelling and coding guidelines: "Unambiguous
> Graphical Representation"
>
>
>
> Hello all;
>
>
>
> I’ve been asked to comment on an issue in a draft of the next version of
> automotive functional safety standard ISO 26262.
>
>
>
> Specifically, in Table 1 in Part 6 (Software Development) there currently
> is a recommendation for the “Use of unambiguous graphical representation”
>  as a part of coding and modelling guidelines.
>
>
>
> My initial comment was along the lines of “It would help practitioners if
> what was intended by this entry was clearly defined, and some examples of
> acceptable practice provided”.
>
>
>
> Ironically, I have now been asked to provide some examples of “unambiguous
> graphical representation”.
>
> I thought I should call upon the experts…
>
>
>
> I have some “graphical representations” in mind (AADL, PNML from ISO/IEC
> 15909-1:2004, SDL or SDL-RT from the telecoms domain).
>
> Each is in some measure or other “unambiguous” in syntax and/or semantics.
> Some have decades of experience with practical implementation.
>
> None is currently (that I know of) widely adopted in the automotive
> domain.  (Reasons for this would be interesting…)
>
>
>
> Before I reply to my colleagues…
>
>
>
> What do those of you who practice in this field understand by “an
> unambiguous graphical representation”?
>
> (Unambiguous by what criteria ? How does this differ between what one
> might expect in coding guidelines, versus modelling guidelines?)
>
>
>
> What “unambiguous graphical representations” do you use in practice ?
>
> How do you know they are unambiguous ? J
>
> How is the “lack of ambiguity” property useful?  (I know this sounds like
> an odd question, but lack of ambiguity is important for different reasons
> in different contexts; for human understanding, for reliable generation of
> implementation code, for automatic generation of test cases, and so on).
>
>
>
> Thanks for thoughts…
>
>
>
> Best regards
>
> *Malcolm Watts*
>
>
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
>
>


-- 
*Matthew Squair*
BEng (Mech) MSysEng
MIEAust CPEng

Mob: +61 488770655
Email: MattSquair at gmail.com
Website: www.criticaluncertainties.com <http://criticaluncertainties.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20160229/6051ffbc/attachment-0001.html>