Re: UML & Ada

[Simon Wright <simon@pushface.org>]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> writes:

> I'd still like a diagraming model that allows representation of
> anything that can be built in Ada - with icons for all the Ada
> constructs. What I know of UML is that it tends to dictate OOD -
> which makes it kind of lousy if the system in question doesn't want
> to use OOD or is already built & you're trying to reverse-engineer
> it. (I know this is A Bad Thing, but sometimes, that's the
> mission...)

My view is that both UML and Ada do a lot more than you need, in
different ways.

UML has an enormous amount of notation (and 2.0 will have more), and
even where the semantics are precise I bet you normal engineers won't
use it consistently. A presenter at an Ada UK Technology Day (early
'01, I think) told us how neither the system designers creating
statecharts nor the programmers implementing them actually understood
the notation, with predictably unfortunate results.

If you are modelling a problem domain, you likely don't want to be
thinking about tasks. Indeed, the ideal is that your model should be
true (useful) in a number of implementations. Analyse Navigation, say,
and reuse in a cruise missile and a torpedo (I don't think that's
_very_ likely ..). Change your implementation language from C++ to Ada
but retain your model.

The point at which you need to be thinking about tasks (or threads) is
when you're deciding how to map the model onto code. You might want to
use UML, but what you're talking about now is the translation rules
which are the same for all the analysis domains of your application
(lower layers are going to have more handcrafting, of course, perhaps
with indicative-only UML models with lots of annotation).

Stuff on this at
http://www.projtech.com/
http://www.kc.com/html/products/products.html
http://www.kc.com/html/xuml.html
http://www.kc.com/as_site/
(these are quite old links, I haven't checked them recently).

The current translation rules for tasks in my ColdFrame
(http://www.pushface.org/coldframe/) are:

(1) if you mark the class "active" you get a task per instance

(2) the task is constrained by an access to its instance

(3) non-<<class>> procedure operations map to instance procedures
    which call the corresponding task entry.