Re: Ada in command / control systems

[russ lyttle <lyttlec@removegmail.com>]

On 3/11/19 4:56 AM, Simon Wright wrote:
> lyttlec <lyttlec@removegmail.com> writes:
> 
>> Code-to-diagram generators do make life easier! Especially for
>> maintenance.  Speaking of which, is there a good one for Ada? I have a
>> couple for C/C++ but not Ada.
> 
> The trouble with code-to-diagram generators is that it's only really
> possible to make a useful diagram if it hides some aspect of the
> code, and if the code is created by humans (even just one human!) there
> won't be the architectural consistency to achieve that. For example,
> there may be many ways of representing the notion that one Target may be
> being engaged by one or more Missiles_In_Flight, but that a
> Missile_In_Flight is engaging precisely one Target.
> 
> In rather the same way that it must be quite hard to convert an
> optimised binary back to the Ada source code it was generated from.
> 
> That said, I wonder whether you meant diagram-to-code generators? In
> that case, the relationship I described above would be straightforward
> to specify in a UML class diagram, and the architectural decisions made
> in the specific code generator would mean that you would know exactly
> how to navigate the model: the function call
> 
>     Is_Engaged_By (The_Target)
> 
> would return a possibly-empty list of Missile_In_Flight.
> 
> Modelling/code generators for the sort of project that's appropriate to
> model in UML (probably not e.g. FADEC, but certainly the business logic
> of a railway signalling system) include
> 
> * Rational Rhapsody,
>    https://www.ibm.com/uk-en/marketplace/rational-rhapsody
> 
> * Bridgepoint, https://xtuml.org
> 
> * xUML, https://abstractsolutions.co.uk/our-services/executable-uml/
> 
> * my ColdFrame, https://simonjwright.github.io/coldframe/
> 
No, I meant code-to-diagram as last step with the "as-built" documents.
I've used Rational Rhapsody in conjunction with DOORS several times. 
Each time the UML diagrams were generated early in the project included 
in high-level requirements as objects in DOORS, and used to create a 
code framework. Managers want to start billing the coding team against 
the project, so they started filling in the blanks and committing code. 
A year later and 2 levels down a bug was discovered and fixed. No one 
ever changed the original UML diagrams to reflect the change. Either as 
an oversight or because they didn't want to go through the whole process 
of changing a high level requirement.
Big mess at the end.

I like using the diagrams as an engineering aid. Just not including them 
in the requirements documents. Requirements are (should be) fixed and 
unchangeable. The diagrams need to be dynamic and always reflect the 
current status of the code.