TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Proportional Font
Show HTML Part by Default
Show All Mail Headers

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

Print Reply
Subject:
From:
Simon Wright <[log in to unmask]>
Reply To:
Simon Wright <[log in to unmask]>
Date:
Fri, 15 Oct 1999 20:51:20 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (35 lines)
> From: "Harbaugh, John S" <[log in to unmask]>
>
> I just want to amplify on Alex's point.  You can use UML to create a
> language-independent OO model of the problem, or to model arrangements
> of Ada packages, or C++ classes.  In the latter case, code generation
> is relatively straight forward, since the diagrams include
> language-specific details.  If, on the other hand, you follow the
> literature and create a "pure" OOA model, you are by definition hiding
> language details.  Consequently, the UML is underspecified.
> Furthermore, there appears to be a one-to-many mapping from a pure OO
> model to Ada implementations (I suspect this is the case for other OO
> languages as well).  This would require a forward-engineering tool to
> make assumptions as to which implementation pattern to use.

Or perhaps you would tell it which pattern to use. Or perhaps even you
would be able to create your own patterns!

Seems to me that it must be better not to pollute your domain models
with implementation detail. The domain model should be
language-independent.

Some of you will recognise a Shlaer-Mellor OOA/RD convert here. The
OOA/RD word for "implementation pattern" above is "software
architecture", BTW.

> BTW, I have looked at the output of Rational Rose Ada reverse
> engineering tool.  It draws pretty good unit visibility diagrams,
> although it does not distinguish hierarchical visibility from
> "withing" visibility :-(.  But the class diagrams it generates are
> pretty confused and do not look like useable UML at all.  This is
> surprising - I would thing that the compiled source code provides more
> than enough information to create a simplified model diagram.

The problem may well be that the code contains far too much information!

ATOM RSS1 RSS2