Re: Ada202X: Easy to use "UML private"-like components

[Martin <martin@thedowies.com>]

On Friday, June 21, 2013 7:36:40 PM UTC+1, Robert A Duff wrote:
> Martin <martin@..........com> writes: > Secondly, I have to explain that using Ada "private" gives you "UML protected": Not exactly. Ada "private" means clients can't see it, but child packages (which should be thought of as part of the same abstraction) can. It's a completely different visibility model than UML. I don't see any reason to be embarrassed about that. > Option 2: > type T is tagged record > null; > private > F : Float; > end record; > > > I prefer Option 2. > > Thoughts? I don't think making Ada more like UML is a worthwhile goal. If it were, I'd prefer your option 1. But I don't see the point: In Ada, packages are about visibility. That's different from languages that conflate the concept of "module" and "type" (which has both advantages and disadvantages). Overall, I prefer the Ada way. If you want derived types to see their parent types components, you put the derived types in a child package; if you don't, then you don't. Attempts to mimic UML in Ada lead to a mess, as you've shown. I share your disdain for what you called "opaque" types -- it forces you into heap management, which leads to extra trouble. But I object to calling them "opaque" types. Ada folks usually call them "stt access types" and "stt incomplete types", or "Taft amendment types", because they were invented by Tucker Taft and added to Ada 83 at the last minute when nobody realized all the headaches they cause for compiler writers. The term "opaque type" comes from Modula-2, IIRC, and is more like an Ada private type, with some annoying restrictions added. - Bob


Back from holiday...I'll leave all the Modula-2 discussion well alone. I was just using "opaque" in the English dictionary definition sense - no implication of links to other languages implied...but thanks for the background!

I hindsight, all the recent changes to Ada-syntax style probably does favour Option 1.

Anyway, the keyword in the topic was "easy" - perhaps I should have written it in ALL-CAPS :-)

There are current options of how to achieve UML-like private-ness but all are clunky and some are horrific and, given their access-types not available for safety-critical systems (where coding standard still often forbid such usage).

As to making Ada more UML-like, that's not really my goal...but I'd certainly like to make common UML constructs easy to achieve in Ada.

It's a topic I've raised at various conferences for 10 years or more.

I had hoped a standard UML <-> Ada mapping could be agreed between the UML & Ada compiler tool vendors; certainly they all gave positive responses to such a move all those years ago. They all had company's developing their own Stereotype/Tag UML<->Ada solutions, so all saw this wheel being re-invented year after year, company after company.

Sadly, I expect the companies who were re-inventing these wheels, saw their work as "IP" and not to be shared with the wider community. Opportunity lost.

Interest has been raised in UML/Ada recently but sadly the current state-of-the-art is not as mature as the current UML/Java or UML/C++...and I live in a MDA focused s/w dept, where UML is a must and where auto-code generation is much used.

NB: Lots of recent s/w grads seem to be literal in only in UML + Java...it have become, for better or for worse, a UML world.

-- Martin