What Differentiates UHR - Discussion

Go Back - (Bolding added by Jack)

---

Date: Mon, 19 Apr 1999 13:40:26 -0400
From: "Marc Merlin" <mmerlin@acm.org>
To: "Jack Harich" <mailto:jack@jcon.org>

Monday, 19 April 1999

Jack,

Thanks for the update on the UHR page.  Although I can't say whether your
tabulation of meta-concepts is definitive or not, I do think that your take
on Component Based Development is more complete than it was in your original
meta-concept table.

It's not clear to me how one goes about doing an accurate enumeration of
fundamental concepts, though.  In my opinion the two most significant
concepts in the history software engineering are Parnas' definition of the
module as instrument of information hiding and Wirth's advocacy of
decomposition of systems by stepwise refinement.  These aren't complex
notions in that they don't consist of many subsidiary concepts, but their
impact on the practice of engineering software systems can not be
underestimated.

Now do these foundational concepts stand on their own or would they be
subsumed in some other category or categories?  Some would say that stepwise
refinement - although not introduced by the structured programming
"revolution" - was certainly part of the procedural abstraction
instrumentation that came part and parcel with the advent of structured
programming languages.  Likewise abstract data typing - sans encapsulation -
certainly reared its head during that epoch.  Does that concept get an
honorable mention somewhere?  Similarly, reuse gets emphasized in component
methodologies and, of course, in UHR, but, as has been noted by many
authors, procedural libraries - a legacy of the structured programming
movement, if not an objective - represent the most successful example of
reuse in the tattered history of software engineering.

Most component advocates would say that configurable component properties
are an essential ingredient of their idea of a component based development.
Likewise they would aspire to a zero-coding approach where possible.  Many
would include some sort of scripting or "glue" language to allow for the
composition of components where ready-made solutions are simply not
available.  Does CBD get to claim declarative knowledge or scripts as
fundamental concepts?  What about genericity ala Ada or C++ templates?  Some
people would claim that it is a concept fundamental to any genuine
conception of reuse (see D'Souza and Willis, "Objects, Components and
Frameworks") others would say that it is the spawn of the devil (see anyone
of a number of critics of C++ ).  Who gets to claim or disown genericity?

All in all, I'm saying that this type of "feature" comparison is fraught
with difficulty.  It also invites us to short change approaches that we are
not familiar with - imagine seeing some else's presentation of your table
with a single item under the UHR entry saying "reuse is the way" - or
selectively lump methodologies together or break them apart.  For example, a
reasonable person - not necessarily me - could claim that UHR is a plan for a
mature and specialized component-based architecture and does not merit an
entry of it's own in such a table.

I feel that you have made a very good case for pursuing the UHR in the JSL
mailing list and else where.  I know that it has a myriad of things to
recommend it.  I just don't think that the meta-concept comparison table
does very much in demonstrating its superiority.

That's all for now.

Cheers,
Marc

---