TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Simon Wright <[log in to unmask]>
Reply To:
Simon Wright <[log in to unmask]>
Mon, 17 Feb 2003 20:09:59 GMT
text/plain (51 lines)
Peter Amey wrote:

> The problem at present, especially when targeting Ada, is that UML,
> as described in books and as implemented in current tools, drives
> you down a path of programming by class extension which may not be
> appropriate for all problem domains.  It compounds this problem by
> not providing standard support for those areas where Ada is _more_
> expressive and capable of _better_ abstraction than the design
> notation.  Ada's packages and private types for example.  I have
> even heard UML tool vendors describing Ada as "deficient" because it
> does not match UML's model of the world properly.

I think UML's area of application (I was going to write "strength") is
in modelling problem domains. I completely agree that it doesn't
handle modelling Ada implementations -- but I would not want to ask it
to. And I wouldn't want to model Java or C++ implementations either.

What I mean by that is, often you will find a tool where if you want
something in the code it has to be in the model; which is why you get
all this elaborative rubbish, where the analysis model is crufted up
with all sorts of inessential implementation detail. What you need is
a tool which will apply the software architect's rules to the analysis
model and generate the support framework required.

> The end result is that real design skills are being supplanted by
> knowledge of particular tools and mechanical ways of using them.  In
> the end we reach the farcical levels of Shlaer Mellor where the very
> existence of a software design process is denied (SM alleges that
> once you have done the OO analysis, you just code the objects and
> tip them in a box and stir - no software design is required at all).

I dare say this is what used to be sold (it certainly sounds like what
some of the practitioners were selling) and it is clearly tosh. And it
is _not_ what you would hear from executable UML practitioners
nowadays. What they will tell you is that the modelling exercise (in
the problem domain) is quite separate from the implementation exercise
(in the software domain) and that it is the proper interest of the
software domain to support (automated) translation from problem to

And the translation depends heavily on the constructs in the target
software domain. My present project is a memory-based VxWorks system
with very little persistence. The design of the software architecture
is quite different from what would be appropriate if we had a
distributed real-time database (as a neighbour project has). But the
contention of the executable UML guys is that the application model
should not change just because of this; it's the translation engine
that changes.