Mon, 13 Apr 1998 17:04:45 -0700
Robert Eachus wrote,
> I've actually had to convince projects to accept guidelines...
> (More than six withs on a package spec, or fifteen on a package body
> indicates that there is restructuring that should be considered. There are
> good arguments for having more withs on the main program, but a with on a
> subunit is almost always an indication of a design problem.)
The above numbers intrigued me because some time ago we had noticed
similar thresholds. In particular, we noticed that when interfacing to a
binding for some subsystem written in C (such as for X-Windows), a more
generous allotment needed to be permitted for bodies (about 20 or so).
However, your observation regarding subunits is unclear to me: are you
suggesting that subunits should ideally have *no* WITHs? Moving such
WITHs up to the parent body would meet the criterion, even though it
would still be the same design.
Here is some other data: In a recent review of several independent Ada
projects, we noticed the following pattern of typical numbers:
# WITHable specs avg WITHs/spec avg WITHs/body max WITHs/body
164 2 or 3 2 20
340 2 or 3 4 28
1450 2 or 3 13 118
7006 2 or 3 20 983
(Yes, that's 983 WITHs for a single body unit: it was a memory resident
database that correlated data of all TYPEs across the whole system.)
These numbers count subunits as bodies, and include unused WITHs, if
any; bear in mind that a spec's WITHs need not be repeated in a
body/subunit. It's an interesting pattern that invites speculation:
The architecture (ie, inter-spec dependencies) is fairly constant
regardless of program size, whereas the implementation inexorably
grows in complexity as the system size grows; and it's nonlinear.
Is this an intrinsic property or just weak design? A human limitation
or state-of-the-art? Has anyone else observed such a pattern?
C. Daniel Cooper ==========v=================v=======================v
Adv Computing Technologist | processes | All opinions are mine |
206-655-3519 | + architectures | and may not represent |
[log in to unmask] | = systems | those of my employer. |