Re: Ada in command / control systems

[Maciej Sobczak <see.my.homepage@gmail.com>]

> You can build blocks out of blocks. In terms of software development 
> this is trivial aggregation. Modern languages have a lot more under the 
> belt.

And a lot of coding and design standards saying what not to use. :-)

> How about user-defined types of edges? [...]

This is thinking in terms of solution, not in terms of a problem.
Why would I care about features that are borrowed from code-based programming languages in a model-based tool, without a particular problem to solve?

> Groups of edges used 
> together? How about parametrized blocks? Substitutability of blocks upon 
> connection with other blocks and polymorphism of blocks and edges? 
> Interfaces of blocks constraining implementations of?

I don't see any reason why a model-based tool should not have them. But I also don't see any reason to have them unless I have a problem where they are needed.

> We had a project where the customer required the HMI designed in a 
> graphical language like Simulink. Once the diagram became impossible to 
> read and even less to understand. We stopped using it.

Yet, that will not prevent the same customer asking for it again. Guess how do I know.

> The biggest 
> problem was missing edges. If a block misses an input how to find the 
> block providing it among thousands of blocks?

Which is exactly the same problem as with source code. If the information is missing, you have to figure out where to get it from (among thousands of source modules, of course, no less).

> Instead we took the internal representation of the diagram. It was a 
> file with sections describing blocks, edges and their connections. So we 
> edited that file directly!

Yes, Tcl makes it possible. Which might be actually a proof that model-based approach can be a safe choice if such a rescue option exists.
Having said that, I have also seen a tool that used XML as an underlying format, where everything was "linked" by means of UUID identifiers, woven as attributes in absolutely every entity. I think that character-wise, these UUIDs made a majority of the file content. Even though it was formally still a text file, modifications by hand were just impossible. So, it all depends on the tool vendor. But this is certainly something to look into at tool evaluation time.

> When the patched file got loaded, it was 
> rendered as an utter mess of overlapping blocks and edges leaving 
> nowhere, piercing the diagram like cosmic rays. Naturally our manual 
> editing destroyed the layout! The automatic rearranging tool indignantly 
> crashed when faced proud results of our creativity. The diagram worked 
> but nobody could see it.

Interesting story about a particular low-quality tool, saying nothing whatsoever about the approach as a whole. There are anecdotes about buggy compilers and incomprehensible sources as well.

> OK, but if you have a block of N inputs and M outputs which is supposed 
> to implement some part of controller activity. In order to test it, you 
> must know what kind of analytical function it represents.

And in what way is it worse from source code?

> So if Ada were used to generate Simulink blocks, the roles would change?

For the sake of argument, you might also generate Ada source from assembly.
But I doubt it would impress the actual stakeholders.

> In my view the level is determined not by artifacts of software design 
> process but by the abstraction level

Yes, and this is determined by the fact that you can provide *various* lower-level implementations/refinements of higher-level requirements, thus leaving some space for engineering work and decision making on the way. As long as models don't constrain the underlying implementation (source) in a way that would make them 1:1 equivalent, they are considered to be higher-level than source. This is how models are used, although there is also a place and market for visualization tools that generate diagrams from code.

> Always ready! MBD was a hype already in late 90's. Remember OOA&D?

Yes, and it didn't go anywhere.
Or maybe the enterprise folks, who where fond of UML at that time are now all gone "agile". But in general, OOA&D is still alive and kicking, especially in the industrial applications.

> Code 
> generated from class diagrams?

Yep.

> Especially because there are rivals on the market of snake oil sellers, 
> the AI is back! I expect mission critical software written in the form 
> of trained NN! (:-))

Yes, let's fasten our seatbelts. But in the context of this discussion, this is not a rival, it is *another*, *additional* reason to forget about hand-coded sources. It's not like MBD will lose. It's really one more reason for companies not to write source code. The source code will lose, because there will be even more ways not to write it.

> Yes, for a while. But you and I have suspicion that this is not really 
> sustainable.

In a sense you are right, it's all pile of shit. But still, there is no coming back. People are really determined to invent all kind of necessary shit, as long as it saves them from writing code. And this is what bothers me.

-- 
Maciej Sobczak * http://www.inspirel.com