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.
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.
> From: Bell, Alex E[SMTP:[log in to unmask]]
> Reply To: Bell, Alex E
> Sent: Tuesday, October 12, 1999 7:03 AM
> To: [log in to unmask]
> Subject: Re: CACM Ada comment
> I suppose I should jump in and comment and get this train back on the tracks. I would like to take this opportunity to clarify a few misconceptions.
> Contrary to popular belief, the authors are very familiar with the "round-trip" engineering support provided by the Rose and ObjectTeam products for Ada/UML. We experienced similar results using both, the issue is not the tools.
> The NMT program uses child packages with a number of motivations:
> - To support testing in a fashion that facilitates "removal" of test only software and to provide the visibility that test only software sometime needs.
> - To manage the size of our executables
> - To provide unique focus into some of our larger classes (track.kinematics, track.id, eg.)
> - To provide finer granularity of our software in the configuration management worlds.
> - To partition our classes into roles (server vs. service interfaces, eg)
> - To separate our operational software from mission support software that requires visibility into the operational context
> There are many cases when these child classes *do not* warrant representation as classes in our class diagrams, they are sometimes merely implementation issues. We are not modeling packaging in our class diagrams. I have already had a response from 2 other programs that are or have experienced the same issues.
> Bottom line: as the result of reverse engineering our implementation into UML, many of the child packages supporting the motivations above are represented as first class citizens, we do not want that. Bill Taylor and Richard Riehle have captured a few other issues that are also somewhat impacting to us but not as significantly.
> On a completely separate note, I intentionally stay out of forums like this precisely because of the tone and hostility of several of its participants. In my opinion, insults and antagonistic commentary are not welcome here and are counterproductive. It also seems as if people are commenting without even having read the subject article, I would recommend doing so to keep the discussions focused.
> Alex E. Bell