[SystemSafety] Another question

[Matthew Squair]

More robust than resilient, aircraft today are certainly much more
dependable than their predecessors, at least until a very rare event or
combination of events occurs which we didn’t address.

On 28 September 2018 at 5:13:04 pm, SPRIGGS, John J (john.spriggs at nats.co.uk)
wrote:

> ... and M. Saint Exupéry was writing about modern aeroplanes; I am not
> sure that we have made them simpler, but they are more dependable and
> resilient than the ones he flew.
>
> -----Original Message-----
> From: systemsafety [mailto:
> systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of Coq,
> Thierry
> Sent: 26 September 2018 09:47
> To: systemsafety at lists.techfak.uni-bielefeld.de
> Subject: Re: [SystemSafety] Another question
>
> Hello,
> UML is only a language, not a method or a modelling technique. It can be
> used in numerous ways, most of them unsuited for critical real-time systems.
> It's also very sad that, like other languages such as C, C++, Java, it has
> bloated instead of become more lean. Antoine de Saint Exupery once said
> (loosely translated from French): "perfection is achieved, not when there's
> nothing more to add, but when there's nothing more to remove".
> I had expected after UML 1 that UML 2 would be more concise and have less
> diagrams, and that there would be an easy-to-understand mix of textual and
> graphical notations to express requirements to architecture to design to
> implementation to validation and safety cases. It has not happened.
>
> On the other hand, I would like to testify that although it has not been
> easy, it has been possible to integrate ESTEREL and UML in a real-time
> method in order to produce time-provable pieces of software. It was done
> some time ago. My guess is that there are several teams out there that have
> done the same thing using a subset of UML (like other subsets mentioned in
> this thread) and using that subset to define requirements, architecture,
> design and/or implementation, combined it with their preferred semi-formal
> or formal modelling techniques and built part of their validation
> documentation with it. The added value was the easier understanding of the
> simple and precise (subset of) UML for the non-engineers,
> non-system-engineers and non-functional-safety-engineers in the team and in
> the client's team.
>
> Best regards,
> Thierry Coq
>
>
> -----Original Message-----
> From: systemsafety [mailto:
> systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of Les
> Chambers
> Sent: Tuesday, September 25, 2018 1:34 PM
> To: Olwen Morgan <olwen.morgan at btinternet.com>;
> systemsafety at lists.techfak.uni-bielefeld.de
> Subject: Re: [SystemSafety] Another question
>
> Olwen
> Re comment:
> If you explore the formal methods literature, you'll easily find modelling
> techniques that UML does not properly embrace.
>
> Can you name one or two. Always ready to be educated.
>
> Les
>
>
> On 24/09/18 23:41, Les Chambers wrote
>
> <snip>
>
> ... I am with you on the UML. It's just a container for all the
>
> modelling techniques we've developed over the past 50 years. No
> developer has to consume all the Kool-Aid. You just take a sip and use
> what's useful in your own special >>> context. Why anyone would take a
> dislike to it is a mystery to me.
>
> Beg to differ. If you explore the formal methods literature, you'll
> easily find modelling techniques that UML does not properly embrace. I
> dislike any formalism for systems engineering that is:
>
> (a) not formally defined or has had formal definitions (clumsily)
> retro-fitted, or
>
> (b) forces upon me a verbosity that more mathematically-based
> techniques do not.
>
> ... and as regards "lunatic fringe" environments, it remains true to
> say that if you don't know what you want:
>
> (i)Â Â Â you won't know when you've got it, or
>
> (ii)Â Â if you've belatedly decided what you do want, reworking what
> you've got that isn't what you want does not exactly have an
> impressive track record in systems engineering.
>
> I may be wrong but I doubt that you'd find Sukhoi systems engineers
> working the way the F35 systems engineers have. Russian engineering
> seems to be predicated on a much more incremental philosophy ... which
> is quite possibly why US astronauts have to go to Baikonur to thumb a
> lift to the ISS.
>
> O
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
>
>
>
>
> --
> Les Chambers
> les at chambers.com.au
> +61 (0)412 648 992
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
>
>
> **************************************************************************************
> This e-mail and any attachments thereto may contain confidential
> information and/or information protected by intellectual property rights
> for the exclusive attention of the intended addressees named above. If you
> have received this transmission in error, please immediately notify the
> sender by return e-mail and delete this message and its attachments.
> Unauthorized use, copying or further full or partial distribution of this
> e-mail or its contents is prohibited.
>
> **************************************************************************************
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
>
> ***************************************************************************
> If you are not the intended recipient, please notify our Help Desk at
> Email information.solutions at nats.co.uk
> immediately. You should not copy or use this email or attachment(s) for
> any purpose nor disclose
> their contents to any other person.
>
> NATS computer systems may be monitored and communications carried on them
> recorded, to
> secure the effective operation of the system.
>
> Please note that neither NATS nor the sender accepts any responsibility
> for viruses or any losses
> caused as a result of viruses and it is your responsibility to scan or
> otherwise check this email
> and any attachments.
>
> NATS means NATS (En Route) plc (company number: 4129273), NATS (Services)
> Ltd
> (company number 4129270), NATSNAV Ltd (company number: 4164590)
> or NATS Ltd (company number 3155567) or NATS Holdings Ltd (company number
> 4138218).
> All companies are registered in England and their registered office is at
> 4000 Parkway,
> Whiteley, Fareham, Hampshire, PO15 7FL.
>
> ***************************************************************************
>
> _______________________________________________
> 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/20180928/3dc1f6da/attachment.html>