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

From: Steve Tockey < >
Date: Sat, 27 Feb 2016 05:57:35 +0000

I can't speak for SysML but UML is definitely way too loosey goosey. Intentionally, in fact. The truth is that the committee that built UML couldn't reach agreement on interpretations of certain elements of the language so those elements were simply left undefined.

There is (was?) a mechanism in UML called a "profile". The purpose of a profile was to allow an organization to define their interpretation of an undefined UML construct to address the built-in ambiguity. At least a team could define "this is what WE mean when we say this in a model".

Date: Friday, February 26, 2016 4:25 PM
To: José Faria <jmf_at_xxxxxx Subject: Re: [SystemSafety] Modelling and coding guidelines: "Unambiguous Graphical Representation"

So,

What about UML and SysML? Do they qualify or are they too loosey goosey?

Matthew Squair

MIEAust, CPEng
Mob: +61 488770655
Email; Mattsquair_at_xxxxxx Web: http://criticaluncertainties.com

On 26 Feb 2016, at 9:22 PM, José Faria <jmf_at_xxxxxx

>> 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_xxxxxx



On Fri, Feb 26, 2016 at 9:33 AM, David MENTRE <dmentre_at_xxxxxx
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_xxxxxx



--
--
José Miguel Faria
Educed - Engineering made better
t: +351 913000266
w: www.educed-emb.com<http://www.educed-emb.com/>
e: jmf_at_xxxxxx

_______________________________________________
The System Safety Mailing List
systemsafety_at_xxxxxx



_______________________________________________ The System Safety Mailing List systemsafety_at_xxxxxx
Received on Sat Feb 27 2016 - 06:57:45 CET

This archive was generated by hypermail 2.3.0 : Thu Apr 18 2019 - 22:17:07 CEST