[SystemSafety] proofs

[Steve Tockey]

Paul,
For what it’s worth, Design by Contract is a required element of my coding standard. No contract means your code automatically fails the review. The contract and the code also have to be consistent.

Consistent and correct use of contracts not only makes reuse easier, as you say, in my experience it also accelerates development and significantly reduces long-term maintenance costs.

Can you make it part of the organization’s design / coding standard and enforce it through some kind of review? Without some form of enforcement, it won’t happen in practice because too many developers are too lazy / sloppy / unprofessional / ...


— steve 


发自我的 iPad

> On Nov 23, 2018, at 4:43 AM, "paul_e.bennett at topmail.co.uk" <paul_e.bennett at topmail.co.uk> wrote:
> 
>> On 23/11/2018 at 11:52 AM, "Steve Tockey" <Steve.Tockey at construx.com> wrote:
>> 
>> Paul,
>> Are you familiar with “Design by Contract”? Much of what you are 
>> talking about for abstract function-level behavior can be 
>> expressed in Design by Contract form. The missing piece would be 
>> artifacts of implementation choices (e.g., because an unsigned 
>> short was used inside the function, a maximum of 128 things can be 
>> supported).
> 
> I have heard of it, yes.
> 
>> It could be that a well-stated contract together with an explicit 
>> statement of technical limits could be sufficient.
> 
> If all functions had such documentation, then the selection for software
> component reuse is made simpler.
> 
>> The next question would be, “What about when the code is much 
>> bigger than a single function?”
> 
> There is a clue to my preferred programming environment in everything
> I post. The finer granularity I spoke of is because it is based on a truly
> component oriented approach and, by ensuring that the documentation
> standard is applied throughout, we get quite a good appreciation of what
> we are using underneath any function we implement. That programming
> environment is extensible by adding functions into the collective, so we
> are always super-setting, rather than sub-setting.
> 
> Even the most complex application, in my preferred programming
> environment, is constructed from the bottom up from using functions.
> The lower order functionality can be fully proven before you add the next
> layer. It is all about ensuring a solid foundation.
> 
> So far, the hardest part, for me, is ensuring that others, who write for the
> same environment, follow the documentation guidelines to teh extent that
> a documentation tool we use can peel the descriptive data into a file for
> presentation purposes.
> 
> Scalability has never been a problem.
> 
> Regards
> 
> Paul E. Bennett IEng MIET
> Systems Engineer
> Lunar Mission One Ambassador
> -- 
> ********************************************************************
> Paul E. Bennett IEng MIET.....
> Forth based HIDECS Consultancy.............
> Mob: +44 (0)7811-639972
> Tel: Due to relocation - new number TBA. Please use Mobile.
> Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
> ********************************************************************
> 
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety