Re: Ada95 and UML

[Simon Wright <simon@pushface.org>]

"Robert C. Leif, Ph.D." <rleif@rleif.com> writes:

> Simon writes:
> > True; model + translation rules -> code. This is possible provided
> > your model is expressed with the precision required by the translation
> > rules[1].
> 
> What Simon writes is true of any formal rewriting system.
> As stated, it maybe too general to be useful.
> 
> Let us suppose, however, that in this context "model" is limited to
> UML, and "code" stands for Ada.
> 
>   In this hypothetical situation, it should be possible to
> go from the model to an executable, and not very many people
> at all need to be concerned with the intermediate representation.
> Assembly language or machine code is fine. No need to bother
> anyone with Ada.  Keep it simple.
> 
>   But my conceit misses the point of using modeling as
> an abstraction to help understand the problem and/or the
> solution.  The model is deliberately more simple than the final
> design and implementation.  That is the nature of modeling.
> To require the model to carry all the details seems misguided,
> sophomoric, to me.

I think we may be slightly at cross purposes here.

So far the scheme I've been working on is a means of converting a UML
model into a code skeleton, rather like what you can get from Aonix in
StP.

The point is that the model can and should contain all the
problem-domain concepts, relations, policies etc[2] but shouldn't
contain stuff about the implementation[0]; the translation engine (be
it machine or human) which converts that representation into code is
governed by rules designed by the software architect.

The same translation rules can convert a model of a different problem
domain into (skeleton[1]) code for the same runtime, or different
translation rules can convert the same model into code for a different
runtime.

This isn't so far from the way that different compilers can generate
different code for different architectures from the same source (eg,
parallelizing Fortran compilers for vector processors).

My feeling is that in many cases the Ada constructs that you might
want to implement the model have no place in the model itself. I could
never get excited about Raymond Buhr's notation, for example -- one
might as well have just written the Ada!

-S

[0] Often you need 'guidance' information .. but rules like 'implement
the container for this class using an Array rather than a Map if the
Identifier is an integral or enumerated type with a range of less than
256 values' are perfectly feasible, provided you have enough control
over the translation infrastructure.

[1] Work is under way on a Precise Action Specification sceme for OMG,
to become part of UML eventually -- so that the intellectual effort of
fully understanding a problem domain, actions and all, can be reused
at minimal cost.

[2] I can't see why you would _want_ to have a model of the problem
domain which was too vague to generate code from! You need to abstract
away the implementation detail, sure, but why fuzz over problem
detail? You need to be very sure about what the model actually means,
can't do that if you leave stuff out and don't have a set of rules to
tell you _precisely_ what the semantics of modelling constructs are.


(rant off!)