TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Mime-Version:
1.0
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
X-To:
"W. Wesley Groleau x4923" <[log in to unmask]>
Date:
Thu, 14 Oct 1999 12:12:11 -0400
Reply-To:
"Robert I. Eachus" <[log in to unmask]>
Subject:
From:
"Robert I. Eachus" <[log in to unmask]>
X-cc:
In-Reply-To:
Content-Transfer-Encoding:
quoted-printable
Content-Type:
text/plain; charset="iso-8859-1"
Parts/Attachments:
text/plain (23 lines)
At 04:02 PM 10/13/1999 -0500, W. Wesley Groleau x4923 wrote:
>So can I summarize your view as 
>
>- Ada specs is a better design approach than UML for Ada code.
>OR
>- UML is a good preliminary design approach, with Ada specs for the detailed design
>OR
>- something else.....

    The second choice comes close, but better would be:  There is a huge advantage to putting a lot of effort into detailed design when programming in
Ada.  Using Ada specifications as a compilable PDL for Ada works very well, and
I am not sure that using any other tool can be worth the additional education and or training effort.  If you are using UML for preliminary design, the additional effort to use it as a detailed design tool is currently minimal, but it currently lacks expressive power compared to Ada for this purpose.  Such extensions to UML however may be very worthwhile when using other programming languages.

    I was thinking about this on the way in today.  I call the correct detailed design paradigm for Ada "left-to-right"  because it makes much more sense to lay out the dependency graphs that way.  Of course, you also need at least five colors of arrows to track the various dependencies: compilation, elaboration, call, tasking (really which unit is the master of a unit or object?), and generic instances (different in that they look like they are a compilation dependence on the spec, but are also an elaboration dependence on the body.  I also like to use a sixth color for relating spec to body when they are different compilation units.  Fortunately, obeying good software engineering principles means that you don't have to look at that graph often, usually only when contemplating major changes in the design.  I think that it has been over a year since I had to look at one of these in full gory detail.  (Which is the advantage with compiled Ada.  If it compiles, there is nothing you need to fix.  The only reason to look at the graph, as mentioned above, is to see how much change a design change will cause.)

    All these dependencies are important in other languages as well, but they are usually only visible when they result in bugs discovered during integration.

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

ATOM RSS1 RSS2