At 10:49 AM 10/12/1999 -0700, AdaWorks wrote:
>Perhaps the real problem is reflected in the comments of Dr. Eachus where he
>notes the emphaisis on using UML at a high-level of design and "decorating"
>it with appropriate details.  It may be heretical to suggest, but I wonder
>if there is a better approach than UML for Ada.  That is, are there good
>alternative modeling notations and methods that more closely map to the
>Ada language?

    First of all, I haven't completed my doctorate, and at this rate I'll be retired when I do.  I started looking for a language other than APL to use, because even I couldn't understand the algorithms I was writing, so my thesis committee wouldn't have a chance.  I looked at a language called Green which was almost right but had a few problems.  I've been trying to fix all those problems ever since.  (We are starting to get close...)

    Back to the main issue, in 1984 we had a discussion at what became the first SIGAda meeting--before then we were AdaTech--on the appropriate design language for Ada.  This had been a topic of considerable controversy, but at this meeting everyone agreed that the right PDL/detailed-design language for Ada was compilable Ada.  In other words, compilable package and other specifications was the final product of detailed design.  (This later was expressed in IEEE 990.)

    Why the sudden shift in position by Jean Sammet among others?  Because those of us who had used existing design tools, including some that were very Ada-like, found that a large number of design problems were recognized when the PDL was translated into Ada specifications.  Some of these required significant redesign, others just required adding a parameter or variable to an interface.
Since we were all using Ada compilers to do this checking as early as possible during the design process, it made sense to make the specs the output of detailed design.  Note that since the actual coding of the bodies was usually easy if all the design bugs had been ironed out, we also ended up with the "usual" Ada schedule:  20% requirements analysis, 30% design, 30% detailed design, 15% code, 5% integration and test.  (And as anyone with experience on large projects can tell you, the way to go over budget and slip schedule is to start coding too soon.)

    Also note that there have were many "annotation" languages for Ada 83 which provided tools that also checked that structured comments matched the code. Byron was probably the most successful of these.  Why have they fallen out of favor with Ada 95?  If I had to guess, it is that everyone has gotten better at expressing the design directly in the code and recognizing standard design idioms.

    Finally there is a question that really needs to be answered before trying to 'improve' UML or Ada as a detailed design tool.  How much benefit could be gained from such an effort?  My opinion is not much.  The amount of effort in process of going from UML to Ada specifications devoted to bookkeeping and writing code is minimal.  The major effort is in making the various decisions that need to be made and documenting them.  Formalizing the documentation process would just add training requirements and documentation effort without adding much benefit for good designers.  For poor designers, it would just make programming in Ada harder, but it is already almost impossible for a poor designer or software engineer to write in Ada in a disciplined manner.

                                        Robert I. Eachus

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