Re: Ada and UML

[Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>]

On 9/2/10 2:43 AM, Yannick Duchêne (Hibou57) wrote:
> Le Wed, 01 Sep 2010 10:20:30 +0200, Matteo Bordin <matteo.bordin@gmail.com> a écrit:

>> or you leave semantic variation points to permit model transformation
>> (code generators) to inject platform-specific semantics following a
>> precise pattern.
> Look like the question I asked in a prior post : how is the source generator driven ?

It depends on the tools.  Start from this question: What drives
your own design decisions when writing this or that source code?

In order to have a name, let's call this source of design
decisions a Shape_O_Mind.

How can you picture the decisions of Shape_O_Mind?

How does Shape_O_Mind operate?

What "tools" does Shape_O_Mind use in order to produce source
text?


Some UML tools come with source templates. UML constructs will
be mapped  to source with the help of these templates.

Some UML tools include a programming language with which to
generate source from the models.

Some UML tools tie source to models, allowing round trip
engineering. They read source, too, and assign model elements
to source code. Not sure if the programmer can always control
this assignment of meaning during this reverse engineering done
by the tool.

Some tools allow the addition of model elements, such as
elements representing subprograms.

The capabilities are not mutually exclusive.

Likely all of these tools permit writing source code
"into" the model entities; the generators will insert this source.
They will not touch it during reverse engineering.

Some UML tools may push integration further to be seamless: you use
one IDE and then a UML model is just another view of your program's
source text.


Other benefits of UML tools that, I think, are not
readily available with just Ada source text:

- model checking

- "specifictation tracking"

When tackling complex relations in some program,
Shape_O_Mind has to rely on our limited capacity for
following indirections, conditionals, etc.

The relation between the set of compilation units
corresponding to problem domain entities isn't an
immediate one either.


Some higher level model elements will *not* depend on the
programming language, or on the computer used to execute
the program. How do you express this in source?

Pictures can help ("worth a thousand words"...).
Assume three Ada packages Pj, each featuring a type Tj,
such that an object of type Tj needs to know about an object
of type T(j+1).

+----+      +----+      +----+
| T1 | <>-> | T2 | <>-> | T3 |
+ ---+      +--- +      +----+

Shape_O_Mind will have little difficulty understanding the  basic
relation or objects, once <> is know to mean aggregation;
a programmer reading source will have to analyze each Pj to find out.


Technical drawings are popular among engineers.
They seem to work.  Why, then, should they not be used
for software systems, too?

Software Through Pictures(TM) is a telling name...



Georg