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

[David MENTRE]

Dear Mr Watts,

Le 26/02/2016 09:01, Watts Malcolm (AE/ENG1-AU) a écrit :
> I have some “graphical representations” in mind (AADL, PNML from ISO/IEC
> 15909-1:2004, SDL or SDL-RT from the telecoms domain).

Yes, AADL and SDL also come to my mind.

* SDL is clearly defined (i.e. has semantics defined for each of its 
constructions). It is both a graphical and textual language. It is an 
international standard (ITU Z.100 to Z.109, 
http://www.itu.int/rec/T-REC-z) and is apparently freely available.

Several tools are available.

* Regarding AADL, its syntax is precisely defined by I think its 
semantics is more vague. Some on-going work is done to define a more 
precise semantics for some of its annexes, like real-time annex.

As far as I know, AADL is an industrial standard defined by SAE (Society 
of Automotive Engineers in USA).

At least one open-source tool is available.

* Another good candidate would be SCADE. SCADE is a graphical language 
with a precise, mathematical semantics defined for each of its 
construction (the mathematical description is given in the certification 
kit of the KCG compiler).

The only big downside of SCADE is that it is a proprietary language and 
only one tool is available, SCADE Suite developed by Esterel 
Technologies 
(http://www.esterel-technologies.com/products/scade-suite/). And this 
tool is very, very expensive.

SCADE is a derivative of several academics synchronous data-flow 
languages: Signal, Lustre and Esterel. Those languages could be also 
good candidates for "unambiguous graphical representation".

* Harel's Statecharts are also semantically defined, even if the 
semantics is very complex. I don't know if the associated tool is still 
available on the market.


* Counter-examples are UML and SysML : their graphical syntax is clearly 
defined but their semantics are not (some people would say you have 
"semantics variation points" ;-) ).

> What do those of you who practice in this field understand by “an
> unambiguous graphical representation”?

For me, a graphical representation is unambiguous if, for each graphical 
construction or combination of constructions, its semantics (i.e. its 
meaning) is described, in an exhaustive way. Put another way, when 
somebody sees a diagram, there should be only-one-true-way to understand it.


> (Unambiguous by what criteria ? How does this differ between what one
> might expect in coding guidelines, versus modelling guidelines?)

Sorry, I don't understand this point.

> What “unambiguous graphical representations” do you use in practice ?

We are starting to use SCADE. We (my colleagues) have used SDL in the past.

> How do you know they are unambiguous ? J

Because you can read the formal description and make tools from it. Of 
course, there is always humans in the loop and so many ways to make 
mistakes (badly understand the formal description, still some 
ambiguities in the albeit formal description, ...).

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

For me, human understanding and automatic code generation are equally 
important. Such languages can be / are used like programming languages: 
you don't want the program to have a different behaviour that you 
understood on the drawing or in simulation; you are doing team work and 
you want everybody to understand the same thing from the diagrams; and 
you don't want the generated code to have a different behaviour that you 
understood.


Best regards,
D. Mentré