Re: Ada in command / control systems

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2019-03-06 08:26, G. B. wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
> 
>> 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.
> 
> I like to think that there are “almost-pictures”. When I want to understand
> a concurrent Ada program, then this may require knowing the communications
> while keeping in mind the shared resources. For understanding
> communications, Ada offers some visual(!) clues: e.g., the control
> structure of a task body together with „accept“ and “requeue”. There may be
> “select” at the other end. These appear(!) in predictable places, shaped by
> syntax and style(!). That’s the start of a picture . And it’s abstraction,
> since presumably I shouldn’t need to study most of the details in between
> the visual clues. Call the result semantic folding that focuses on
> communications.

You refer more or less the UML sequence diagram here.

The problem with this sort of pictures is its literality. They represent 
an instance of task communication and not communication in its entirety 
as an abstraction of multitude of possible communication instances.

This is one method to convey an idea: the picture illustrates some case, 
the details are supposed to be worked out later. The implementation is 
focused on the details.

And as every programmer knows the idea might be great but alas not 
working because of some minor case like the index out of the array bounds...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de