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!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Ada in command / control systems Date: Tue, 5 Mar 2019 19:55:26 +0200 Organization: Tidorum Ltd 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net HUwNv2fOOt9bc2h7U1QbDgz7YkMz/Y1QqbNYR8kFO7s+B0Uqr9 Cancel-Lock: sha1:kR62pNQeTTkpAOz2R4UennQbX2w= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <520809e3-a705-4b10-8b54-6d67c33158a6@googlegroups.com> Xref: reader01.eternal-september.org comp.lang.ada:55790 Date: 2019-03-05T19:55:26+02:00 List-Id: On 19-03-05 11:51 , Maciej Sobczak wrote: ... > Everybody relies on pictures and the general consensus is that you > cannot do proper engineering without them. So there is nothing > strange if people expect pictures in software engineering, too. Anecdote regarding the importance of pictures: A colleague of mine was working on some on-board satellite SW (ultimately) for ESA. At the SW Requirements Review, the customer's representative (that is, the main reviewer) rejected the SW Requirements Specification (the object of the review) as "poor" and demanded that it be "rewritten" -- a very unusual level of criticism. After some close questioning the reviewer admitted that he had only glanced at the document and decided to reject it because it contained no pictures or diagrams. He had not read enough to have found any specific errors or shortcomings. Fortunately, the other reviewers had a better opinion of the document (having actually read it) and the review passed with only the usual amount of corrections required. End of anecdote. I'm not sure which side -- if either -- of the present argument this anecdote supports, but I tend to agree with Dmitry on the limitations of the graphically oriented model-based-design tools. When the model and design are devised and shown at so high a level as to be easily comprehensible, the model usually becomes approximate, which means that running code cannot be generated from the model. The design pictures that are really useful for understanding a piece of SW are almost always abstractions and simplifications and could be called "useful lies". Unfortunately this means that the pictures must be manually created, and manually maintained as the SW evolves. It may be possible to make the model-based design tools encompass more levels of abstraction and detail, and perhaps separate aspects of the design so that different aspects could be designed and illustrated by different diagrams, with the tool able to "weave" all aspects into the generated code. The several types of diagrams defined in UML may be an attempt in this direction. However, AIUI current model-based tools are each based on a single kind of "model" -- say, state-charts -- and then Dmitry's criticism applies. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .