Re: Comparison : Ada and UML (comparison… indeed)

[Matteo Bordin <matteo.bordin@gmail.com>]

> >> There has to be some sort of profile (both in allowable UML constructs
> >> and what they mean in terms of program execution). "If you model like
> >> _this_ and generate code using _our generator_, the result will work
> >> like _that_".
>
> > Sure, but this way you may risk to model your application based on a
> > precise code generation strategy, possibly loosing portability and
> > platform-independence of models.
>
> Even a PIM has to have pretty precise semantics. I suppose I should have
> said, "If you model like _this_ and generate code using _our
> *standard-conformng* generator_, the result will work like _that_".
>
> If that's not so, the platform-independence isn't worth much.

Right: model semantics shall not be dependent on the code generator
otherwise model-based verification results may not be valid anymore if
you change code generator.

Example: HRT-HOOD (an extension of HOOD 3.1 for real-time systems) was
conceived as a language/method to design *Ada* systems - i.e. its
dynamic semantics was defined in terms of Ada constructs. The language/
method and its mapping to Ada were in fact inseparable. Now, suppose
you perform some kind of real-time analysis on your HRT-HOOD model: is
it still valid if you change code generator and/or target language?
Possibly not, meaning that you may need to update your model-based
verification tool to cope with your new code generator. This is the
main risk of coupling modeling language semantics with code gen
strategy.

The dynamic semantics of HRT-UML/RCM, the successor of HRT-UML, was
based on the abstract notion of Ravenscar Computational Model in the
hope that the model-based real-time analysis would be independent of
the code generator - of course assuming the code generator was able to
generate code conforming to the HRT-UML/RCM semantics.