> 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
Some of you will recognise a Shlaer-Mellor OOA/RD convert here. The
OOA/RD word for "implementation pattern" above is "software
> 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!