robinson@gatech.edu (Stephen M. Robinson) (01/30/88)
The following is a summary of responses to our query about Booch's and
Buhr's pictorial representation techniques for Ada (warning: a bit long).
A couple more questions:
We have not been successful in locating e-mail address for either
Booch (at Rational) or Buhr (at Carleton). If anyone knows either
of these we'd like to have them as we would like to contact them
for any Tech reports, etc that are available. USMail addresses
would also be appreciated.
Does anyone know of a way we could access CAEDE or Adagen or
another implementation of these diagrams to experiment with (nothing
big scale)? We are an Arpanet site.
Thanks again, especially to all those below who took the time to reply.
Regards,
Stephen Robinson, Perry Green, Paul Miller
-----------------------------------
School of Information and Computer Science, Georgia Institute of Technology
UUCPNet: ...!{uiucdcs,akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}
!gatech!robinson
CSNet : robinson@gatech.edu
Phone : (404)894-7081
USMail : S. Robinson, Georgia Tech Box 32977, Atlanta, GA 30332
-----------------------------------
------------------------------------------------------------------------
From: beth@hubcap.clemson.edu (Beth Katz)
At Maryland, we received a copy of Buhr's CAEDE system and had it running
on a Sun 3. I didn't personally use it, and I'm not sure what kind of
deal was struck to get the code. If I were you, I'd write to Buhr and
ask about it. I can't check to see whether CAEDE is still on that Sun
because Maryland's department is moving and the Suns aren't awake yet
(at least that one isn't). Good luck.
--------------------------------------------------------------------------
From: emery@mitre-bedford.arpa (Dave Emery)
We've tried using these notations, with pretty good success. However,
there are some significant holes in the notation.
We built some software using generics as a mechanism for inheritance.
In particular, we have the following kind of thing:
generic
type t is private
procedure op (a_t: t);
package class_generic is
type local_t is ...
procedure local_op (a_t : local_t);
end class_generic;
Next, we produced chains of these things. In particular, what we were
describing was a cyclic network of classes, such that class (generic
instantiation) i depends on class (generic instantiation) i-1, and
class 1 depends on the last class. Here's an outline of the actual
code (for 3 instances):
...[rather lengthy example code followed]...
There is no way to show this kind of use of generics using booch/buhr
notations. (Our actual application was more complicated, because once
you got all the class_generic instantiations done, you then used them to
instantiate another collection of generics. Someday we'll get our
paper on this project finished and published...)
In general, you need a mechanism to show run-time binding, which is
different from the compile-time binding that is true of normal 'with'
statements, and also different from the run-time tasking structures.
Actually, in our example, our class_generic.local_t is really a
pointer to a record with task objects in it, so we had a lot of
generic instances which then (dynamically, based on declarations of
objects of type local_t) had tasks in them. We had to reason about
the interactions between tasks in different instantiations of the same
generic.
-------------------------------------------------------------------------
From: Randall B. Neff <NEFF@sierra.stanford.edu>
Booch diagrams are a joke. They look real nice for tiny examples, but
fall apart on real code.
For example: draw out the Booch diagrams for TEXT_IO. It contains 60
visible subprograms and four embedded generic packages.
How do Booch diagrams handle generic instantiation, or overloaded subprogram
names.
My thesis is about 33,000 lines of Ada, broken into 18 packages with
over 400 subprograms. And this is a small Ada system. Try to imagine
what a terrible mess Booch diagrams would be.
---------------------------------------------------------------------------
From: Christopher Byrnes <cb@mitre-bedford.arpa>
In your note you asked for some impressions from someone who has been
using Booch's or Buhr's design methodologies and/or any tools which support
those methods. I'd like to share some of my experiences in this area.
I've been using Buhr CAEDE (CArleton Embedded Design Environment) tool
set we at MITRE bought from Carleton University to run on our Sun 3 UNIX
workstations. Overall I was impressed with the products, particularly with
its ability to soupport the creation of full Buhr diagrams (not just subsets
of his method) and its ability to analyze the resulting Ada tasking
structures for correctness (possible deadlocks) and performance. CAEDE's
user interface could stand some improvements (it's not a nice as what you'd
see on a Mac) but the analysis portion remains its strength.
I've used CAEDE to design some small systems, mainly as a demonstration of
what CAEDE can do. I've also used Buhr's methodology (before we got CAEDE
installed) to design the architecture of a much larger system which had Ada
tasks and UNIX processes spread around a variety of processors. In using
Buhr's notation (both manually and through CAEDE) I noted some strengths
and weaknesses that potential users should be aware of. Weaknesses
include:
(1) It's difficult to represent dynamic system architectures using Buhr,
especially when the number and connectivity of the tasks, packages and
subprograms changes over time and/or in response to changes to system
state. What I ended up doing was creating a different Buhr diagram for each
of the major transitions between system architectures and then creating a
Petri Net to show how the system architecture itself changes over time.
This a problem with most design methods, not just Buhr's. CAEDE can
support this approach by having different "views" created for each master
Buhr diagram, although some manual work is still involved.
Note that not everyone considers this lack of dynamic system architecture
support to be a weakness. Some would argue that you should never design
systems which dynamically create and destroy threads of control (and so
introduce additional non-determinism in the design) because it becomes
harder and harder to precisely map out the system state. This is another
manifistation of the "cyclic executive" (with tightly controlled threads of
controls worked out in advance) versus the "active-object oriented"
approach where the environment figures this out for you so each programmer
doesn't have to know the details of every other activity in the system.
(2) Buhr diagrams are good for capturing the high levels of system
component connectivity and interactions, but it harder to precisely define
the semantics of those interactions and how the interactions relate to your
data models. This might not be a bad thing, designers perhaps should
concentrate on the highest levels of system activity before trying to fill
in all the details. But at some point you have to start filling in the
details, where these "details" are not code but are instead more precise
design decisions. This is where I started to use Stanford's ANNA and TSL
(Ada structured comment annotation) languages to more precisely define what
the design was suppose to be doing. It's important to remember that such
a step is still necessary, even through tools like CAEDE are able to
create Ada code skeletons to begin coding from. Even a precise notation
such as Buhr still abstracts out some design considerations which should be
addressed before coding begins.
The strengths include:
(1) Ability to precisely identify and track the connections between flows
of data and flows of control among the asynchronous tasks. This is why
it's possible (either manually or automatically through CAEDE) to check for
improper tasking structures.
(2) I like to design systems which have lots of little components which can
be connected together to fit the pattern of the job to be done. The Booch
and Buhr object-oriented methods support this. CAEDE also allows you to
separate the definition of a generic entity's defintion from its use, so
you can treat generics as being part of a library of reusable componenets.
(3) There's always a tight mapping between your design constructs (the Buhr
boxes, parallelograms and arrows) and your implementation software
constructs (the Ada packages, tasks and parameters). It's fairly easy to
go back and forth between the two notations. Also both your designers and
coders are using the same model of computation (Ada's tasking model). Not
everyone thinks Ada's model of execution is the best, but it's better than
not having any model of computation at all when designing software.
(4) It was fairly easy to install and use CAEDE on our Sun workstations.
Since we got the source code (both for CAEDE and its Prolog knowledge
base), we were able to integrate CAEDE into the rest of our Ada analysis
tools (such as a Verdix Ada compiler and an ANNA processor) and our Ada
analysis environment (EASE). CAEDE doesn't treat itself as a world apart,
so the rest of the tools you have to use to develop Ada can be used with it
(although this is not for the casual user).
--------------------------------------------------------------------
From: rar%duchamps@ads.arpa (Bob Riemenschneider)
Ray Buhr and a student of his (whose name escapes me at the moment) at
Carleton U. implemented his stuff (in Prolog); that's what CAEDE is.
As of a couple of years ago, it hadn't been used for any large systems.
He's written several papers on the system and its implementation that
go well beyond the contents of the book. As far as I know, these have
only been published as Carleton tech reports.
---------------------------------------------------------------------------
From: geac!daveb@uunet.uu.net (David Collier-Brown)
Actually I use the following instead of Grady's notation, in part
because I can draw it!
|
+-------------------+
| asynch_io | -- package name
| +-----------------+
| | get(<various>) | -- publics
| | put(<various>) |
+-+-----------------+
| | internal_things | -- privates which *should*
+-+-----------------+ -- be known about by callers
--
---------------------------------------------------------------------------
From: convex!smu!spray@a.cs.uiuc.edu (Robert D Spray)
Subject: Boochgrams and Buhrgrams
They are not the same thing. The CAEDE system is documented in
CAEDE 1.3 User's Guide, SCE-85-13, Buhr et al, Carleton University,
Ottawa.
Boochgrams might be implemented by Cadre (Providence RI) who have
close ties with Rational which employs Grady Booch. Cadre may also
have a Buhrgram tool from their recent deal with GE.
Mark V Business Systems' Adagen (Encino CA) supports both diagrams.
Buhr has a recent publication in the Proceedings of the Dec 1987
SIGAda International Conference, published as an issue of Ada Letters,
Booch had a paper in the Feb 1986 issue of IEEE TSE on object
oriented design. You should be able to backtrack several
references from there.
p.s. also check out Booch's new book "Software Components with Ada"
and note that his Software Engineering with Ada is in a revised second
edition (blue cover).