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

[Matthew Squair]

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 gmail.com
Web: http://criticaluncertainties.com

> On 26 Feb 2016, at 9:22 PM, José Faria <jmf at educed-emb.com> wrote:
> 
> 
> >> 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
> 
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20160227/7c75b2a3/attachment-0001.html>