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

[José Faria]

>> None is currently (that I know of) widely adopted in the automotive
domain.  (Reasons for this would be interesting…)

'Three' words: Tools, tools, tools.

Take, for example, AADL. Despite some *very* interesting efforts like
OSATE, it isn't yet what would be considered by most a "full industrially
capable" tool.

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

Ah, ultimate questions:)

It could be useful to start all the way back from the semiotics
tetrahedron, where:

§ The *domain *(/referent /universe of discourse) denotes the existing or
conceived reality that is the subject of model creation;

§ The *conception *denotes the image of the real-world (domain) object in
the mind of the interpreting person. This notional image comprises a set of
properties that the interpreting person associates to the real-world object;

§ The *representation *denotes the result of a human actor describing
his/her conceptions using a conceptual modelling language.

With these:

§ The *syntax *of a language defines the atomic language constructs (the
symbols) and their valid combinations;

§ The *semantics *defines the meaning of the language constructs (the
symbols and their combinations). The semantics is based on the syntactic
rules. It is established through the assignment of the representations to
the conceptions.

§ The *pragmatics *deals with the effects that the interpretation of the
representation has on the interpreting actor. Or, put in other terms,
pragmatics studies the ways in which context contributes to meaning.

Given that conceptions are formed by the actor/user/human according to
his/her association with the referents in the domain, it is inevitable that
different people give different meanings to the same terms and expressions.
It is a challenge no matter the universe of discourse or language.

Formality solves the 'first half' of the problem.

A formal method allows us to use a language in which the meaning of an
expression is rigorously defined and for which meaning-preserving formal
manipulation rules are defined. Like so, expressions can be manipulated
with regard only to their form (and not their content, therefore the
“formal” designation), which allows automatic (machine) manipulation and
verification.

Yet, for the human in the loop, effective and efficient use of formality
requires him/her to have a significant degree of maturity, with a clear
mental model of what is the semantics of the notation being used.

Yes, a tool can unambiguously (i.e., always with the same interpretation)
manipulate a model. Whether that expresses pricesily what the user intended
is a different question.

So, provided you have the first -- formal semantics -- you can solve the
second half and "know they are unambiguous" if the users are well
experienced and trained enough so that they can precisely express
themselves and manipulate the language they are using.

It is often the case that the level of maturity required for that is so
that people end up using less formal notations because these 'feel' easier
to understand and manipulate. Ironically, if 'design/modelling conventions'
are commonly agreed and understood among the group of users, so that
ambiguity is reduced, this turns out 'practically effective' (when
automatic machine manipulation is not required). Most would call these
"semi-formal" approaches.


Best regards,
José


-- 
José Miguel Faria
SAFE PERSPECTIVE Ltd, Director
t: +44 (0)7918 200367
e: jmf at safeperspective.com




On Fri, Feb 26, 2016 at 9:33 AM, David MENTRE <dmentre at linux-france.org>
wrote:

> Hello,
>
> Le 26/02/2016 09:43, Peter Bernard Ladkin a écrit :
>
>> Another reason is the prevelance of MathLab/Simulink in this domain.
>> Simulink is now an executable
>> specification language. Since there is one supplier, it is de facto
>> unambiguous (there is just one
>> simulator, so the single meaning of a Simulink spec is precisely what
>> that simulator does with the
>> spec).
>>
>
> Some people have even formally defined the semantics of Simulink or a
> subset of it:
>
>
> https://scholar.google.fr/scholar?q=simulink+formal+semantics&hl=fr&as_sdt=0&as_vis=1&oi=scholart&sa=X&ved=0ahUKEwiviqDTj5XLAhVCxxoKHdvjAWgQgQMIITAA
>
> Except that semantics of MathLab/Simulink is very fragile, e.g. order of
> execution of state machines on a diagram depends on the order they were
> drawn.
>
> I would not rely on that for a safety-critical system!
>
> I know, we are not living in a perfect world. :-)
>
> Best regards,
> david
>
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
>



-- 
--
*José Miguel Faria*
*Educed *- Engineering made better
t: +351 913000266
w: www.educed-emb.com
e: jmf at educed-emb.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20160226/c85e9cea/attachment-0001.html>