From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED.dm2B5m94KMAPObIwxCwq5g.user.gioia.aioe.org!not-for-mail From: russ lyttle Newsgroups: comp.lang.ada Subject: Re: Ada in command / control systems Date: Mon, 11 Mar 2019 10:27:30 -0400 Organization: Aioe.org NNTP Server Message-ID: References: <2199b15b-d704-403f-a6c4-00fab29792d5@googlegroups.com> <72738cc8-3f65-4cc1-8c61-b1166cb5e3c2@googlegroups.com> <9807ec3a-4c34-4641-acfa-e9cf22de95ce@googlegroups.com> <520809e3-a705-4b10-8b54-6d67c33158a6@googlegroups.com> NNTP-Posting-Host: dm2B5m94KMAPObIwxCwq5g.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:55830 Date: 2019-03-11T10:27:30-04:00 List-Id: On 3/11/19 4:56 AM, Simon Wright wrote: > lyttlec 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.