Re: Ada in command / control systems

[Simon Wright <simon@pushface.org>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> 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.

I once bought "System Design with Ada", R J A Buhr, Prentice Hall 1984,
for a lot of money (at the time), which I deeply regretted. He had a
diagrammatic notation for every possible mode of operation of a task
entry or a select statement. And more. The thing was, you might as well
have read/written the Ada.