Re: Ada in command / control systems

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

> > What do you mean "nothing above that"? There can be many levels of requirements. [...]

> Thus it is simply code in some mostly declarative language. As such it 
> must undergo testing, verification, validation etc.

No, it's not code. It's requirements. Yes, in undergoes verification. Which is actually good - I don't understand, are you now criticizing models for them being verified?

> > The fact that Simulink can generate code automatically is actually not important here,
> 
> It is a key feature allowing to circumvent normal software quality 
> assertion and developing process.

I don't understand this statement (maybe we are running out of fuel in this discussion). Models are used to express ideas and expectations. Whether there is a code generation involved is a secondary issue. You might as well say that automatic soldering of electronics elements from electric diagrams is a key feature of the modeling tool. Yet I have never seen it happen (nor even attempted).

> I don't think there are many people who could write code from a 
> non-trivial Simulink diagram.

Great, we are now focusing on some added value. So let's remove Simulink from the process and we have what? The customer asking for a product. How is that any better? Are there many people who could write code from a non-trivial customer expectation? The models exist to replace that single long jump with two (or more) smaller jumps, presumably easier to follow, trace, and verify. Even if the model is used only to shake out and improve the original requirements, without any code involved on the way, that's already good.

> It is far more difficult than writing 
> assembler code from Ada program.

Then maybe the intellectual gap is still too wide. And that only confirms my previous statements: source code is the lowest-level artifact we should care about (assembler can be written by a machine). Moving from requirements to source requires intellectual contribution from the expert and automating that part is not necessarily easy or desired (but still interesting).

> The question is the purpose of? For example, the purpose of writing pay 
> checks for the developers team. Certainly you might have something 
> useful for that. Or something more close, getting the top managers off 
> the back of developers. Some PPT presentation would be of great help. 
> You should state the purpose first.

I did. The purpose is to reduce the gap that is to be covered by a single engineering activity. Writing source code while listening to the customer over the phone does not work, so let's try to create something intermediary to provide opportunity to verify that our understanding of the high-level requirements are correct and that there is an idea for actual implementation that is feasible and has desired properties. This is exactly the purpose of the low-level model.

> This is not comparable. When writing code in a normal language 
> programmers know the limitation of the mental model they use

I've seen evidence for the contrary. And I've also seen perfect programs that do not fulfill the original requirements, and were therefore useless. So there is something missing.

> There are lots of red lines and 
> alarm bells each competent programmer knows.

I presume that a competent modeler knows a thing, too.

> Moreover, nobody is 
> competent as the proclaimed purpose of all exercise was: any moron can 
> design quality software in Simulink knowing nothing about programming.

I have never said anything like this. Actually, I believe that the effective use of modeling requires expertise that a typical coder does not have.
 
> One must know everything about programming, 
> control, about numeric methods, and about domain-space problem in order 
> to use Simulink en large.

So Simulink is bad, because you have to be competent? That's a really poor criticism of modeling.
I'm asking whether the process can benefit from the presence of such tools. I'm ready to acquire the competencies that I lack, if needed.

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