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

[Steve Tockey]

Les,
Thanks for the kind words. I'm still making progress on the book. Yes, state engines are essentially half of the requirements modeling section. I do talk about use case diagrams and sequence diagrams but they are a mere convenience to readers, the core of the model is in a (logical) class model and a set of state engines. I have about 20 chapters that are far enough along to share with anyone that wants them. Let me know if you're interested, feedback is welcomed.


Cheers,

-- steve


From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de<mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de>> on behalf of Les Chambers <les at chambers.com.au<mailto:les at chambers.com.au>>
Date: Sunday, February 28, 2016 2:53 PM
To: "'Watts Malcolm (AE/ENG1-AU)'" <Malcolm.Watts at au.bosch.com<mailto:Malcolm.Watts at au.bosch.com>>, "systemsafety at TechFak.Uni-Bielefeld.DE<mailto:systemsafety at TechFak.Uni-Bielefeld.DE>" <systemsafety at TechFak.Uni-Bielefeld.DE<mailto:systemsafety at TechFak.Uni-Bielefeld.DE>>
Subject: Re: [SystemSafety] Modelling and coding guidelines: "Unambiguous Graphical Representation"

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<mailto: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 ? :)
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

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