Thu, 13 Feb 2003 13:09:57 -0500
See @ below.
From: Stephen Leake [mailto:[log in to unmask]]
Sent: Thursday, February 13, 2003 11:57 AM
To: Bruce Hennessy
Cc: [log in to unmask]
Subject: Re: Designing for Ada 95?
Bruce Hennessy <[log in to unmask]> writes:
> Although I would agree that Ada makes it easy to partition code and hence
> responsibilities, I would also say that diagramming in UML, or Booch etc.,
> is a necessary thing to do in order to model the system you are building
> before writing package specs. Of course this depends on the complexity
> of what you are building.
I have never understood why people feel "diagramming" is better than
writing Ada specs.
@ You want to be sure you are assigning the proper responsibilities to
@ if you can accomplish that in Ada specs more power to you. You also want
@ able to communicate that design to others, including non hard-core
I understand writing very high level context diagrams, and even first
level data flows.
Beyond that, Ada is a better tool for discussing the details.
@ Agreed that at some level there's nothing like the code to understand
@ what's going on; but as initial intro to the system, a design overview
@ big time - and of course must be maintained to match what's happening in
> Forget about having a pissing contest on which diagram technique to
> use; the thing with UML is that it is a global standard, hence a
> language that all developers can use to communicate design ideas.
Ada is also a "global standard". I suspect you mean "more people know
UML than other diagramming languages".
@ Its a programming standard, not a design mechanism - apart from your
@ remark above about using Ada specs to communicate some level of design.
> The important thing is to utilize the diagrams to develop a design.
I agree, but I don't see the value in using diagrams for more detail
than top level data flows.
@ Are you doing OO systems? In any case, depending on the complexity of the
@ pictures, along with text, are real helpful in getting to know how the
@ hangs together.