TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

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

Print Reply
Content-Type:
text/plain
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Subject:
From:
"Bell, Alex E" <[log in to unmask]>
Date:
Tue, 12 Oct 1999 07:03:37 -0700
MIME-Version:
1.0
X-cc:
"Sando, David R" <[log in to unmask]>
Reply-To:
"Bell, Alex E" <[log in to unmask]>
Parts/Attachments:
text/plain (22 lines)
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

ATOM RSS1 RSS2