[trustable-software] Open Control and Mustard

Gerald Harris gerald.harris at t-online.de
Sun Oct 9 14:56:14 UTC 2016


Hello,

Re, round trip engineering I confess to having strong prejudices against it due to bad experiences in the past. However, these were in connection with modelling tools coupled with code generation. The problems that I encountered may not apply in this area.

If an RTE toolset is used to create a model, the theory states that the code can be subsequently modified by hand and it will be possible to “automatically” update the model to reflect the code changes. My experiences have always shown two drawbacks that arise in practice.

Drawback 1: The roundtrip engineering cycle is not stable. A model which is regenerated from modified code usually appears to be far removed from the original. What can then be a lot of fun with more complex models is to walk around the RTE cycle a number of times to observe how the model and the generated code evolve. I have seen some extremely amusing evolutions even when no manual changes had been made either on the code or on the model. Very few cycles were required to create something which was dysfunctional. Shortly afterwards it could not be compiled anymore.
Disclaimer: This experience is several years old. The tools are evolving continuously. My experience from then may not be applicable anymore. However, this experiment left me with a deep distrust of RTE.

Drawback 2: The structure of the original model is lost when the model is regenerated. In order to make a complex system understandable to humans, it is usually “chunked” in a number of ways. It will be decomposed into overlapping subsystems. It might be represented as a hierarchic cascade. The models with which I have had experience, that were (re)generated using round trip engineering capabilities, were flat. Grouping into subsystems was lost. hierarchies were lost. The model was presented in a form which made human understanding extremely difficult if not quite impossible. Again, I should repeat my disclaimer from above. It is conceivable that more modern tools can overcome this hurdle.

If I understand correctly from the discussion below, a different task is in focus here. If a clearly defined development process exists, then this already provides a large part of the modelling structure. Individual entries have a clearly defined role within this structure (as requirements, designs, test specifications, etc). With this clearly defined model structure in place I can see how an RTE approach might be realistic.

However, I remain unconvinced that RTE can be successful in connection with code generation. When generating code the most successful approach that I have seen to date has been to treat the formal model declaration as the definitive source code. The generated code must then provide the necessary hooks that allow hand written code to be added (in separate source files, separately compiled and then combined during the link step).

best regards,
Gerald

> 
> ------------------------------
> 
> Date: Sat, 08 Oct 2016 16:51:11 +0100
> From: Paul Sherwood <paul.sherwood at codethink.co.uk>
> To: Discussion about trustable software engineering
> 	<trustable-software at lists.veristac.io>
> Subject: Re: [trustable-software] Open Control and Mustard
> Message-ID: <174e50591949afb45e0f20ffc4c500bd at codethink.co.uk>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> On 2016-10-08 14:40, John Lewis wrote:
>> One of the issues that has to be considered if you are using UML (or
>> any other design method) is "round-trip engineering".
>> 
>> Methods (e.g. UML, HOOD etc.) can generate code but if the code is
>> then modified, those changes need to be reflected in the higher level
>> design and (if you really want to) raced back to Requirements.
>> 
>> And of course, if undertake RTE,  matching changes to the high level
>> design.
> 
> Absolutely. We did actually take roundtripping into account in the
> Mustard [1] project, which we originally designed as a lightweight tool
> to help apply Automotive SPICE [2] (and as a minimalist alternative to
> Rational DOORS). AFAIK there's no other open source tool for this so far
> (although as Jim has highlighted there is some overlap with
> OpenControl).
> 
> The implementation is relatively simple, but effective:
> 
> - A YAML schema is used to map  and model the linkages between (eg)
> requirement - architecture - test - activity - code
> - all actual requirements, architecture and test descriptions are
> stored in YAML files
> - we can validate the YAML files to flag inconsistencies, eg any
> requirements that are not mapped to (eg) tests
> - all the YAML files are checked into a git repo
> - changes or improvements to the arch, tests etc are made as changes in
> the YAML files, and stored as commits in git
> - the git commits provide full history of how the model evolves
> - using PlantUML [3], all diagrams can be originated as text, so they
> sit in the YAML too, and hence we can track their changes as well
> 
> I don't think we've ever used Mustard on a project with code generation
> tools - that does seem to be a tricky area. Some of the graphical
> modelling tools make it pretty much impossible to implement proper
> version control. And AFAICT it's quite common for projects to get
> tangled up with manual edits to generated code.
> 
> br
> Paul
> 
> [1] https://github.com/codethinklabs/mustard
> [2] https://en.wikipedia.org/wiki/ISO/IEC_15504
> [3] http://plantuml.com
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.veristac.io/pipermail/trustable-software/attachments/20161009/4011ce7a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.veristac.io/pipermail/trustable-software/attachments/20161009/4011ce7a/attachment.sig>


More information about the trustable-software mailing list