Category level IS architecture level. An architecture delineates categories
of components and their interrelationships. Category level can draw from the
many studies of design patterns. Class level dives inside each category and
fleshes out just how things should actually look and communicate. In the
UML methodology, you would define categories (equivalent to Java packages),
then do a sequence diagram on those categories as a means of fleshing out
the use cases (scenarios). Once you know that something in category A needs
to send some highlevel message to category B, then you begin to visualize
the classes and methods inside the categories that will carry out the
gestalt of the message. So, you next plan your classes, using
class/method-level sequence diagrams to flesh out whole scenarios in detail,
inventing messages and methods as you go.
Doug's need to understand WBI does, indeed, jump deeply into implementation
issues; it appears to be motivated by the fact that Doug considers
Transcoding rather central to the whole system and worthy of "jumping ahead"
to mess with. In the end, WBI may not statisfy our needs for open source or
cross platform capability; there are other approaches to the Transcoding
The process has no real problem with jumping ahead; in fact it turns out to
be rather iterative in nature since you will occasionally (read: always)
find reason to go back and reexamine your assumptions, requirements, and so
Remember, everything is supposed to draw from the original narrative. It
should read something like the combined works of marketing (what the market
thinks it wants), engineering (what folks think can be done), and vision
(what folks want to get done). Thus far, Doug has elucidated a rather vast
and huge picture of what needs to be done (his vision), but has not yet
drilled down to the bloody details of what that should look like. Right
now, we know we want a dynamic knowledge repository. What the hell is that?
Doug's Augment sets the stage. Rod Welch brings to the table an existence
proof of concept for some aspects of a DKR. Visit his web site. David
Gelernter (another visionary) has brought to the table another existence
proof of concept (LifeStreams) which has some fundamental similarities to
Rod's work. Doug Lenat has demonstrated existence proof of the concept of
evolutionary epistemology (Eurisko), and VerticalNet, the company for which
I work, is generating proof of the need for and value of ontological
engineering (the study of what is) at the bottom of everything. And under
that lies knowledge representation (Erics atomic structures). My gosh! Parts
of a DKR are already up and running in one form or another out there. It
remains for us, as I think Doug has asked, to describe just what goes into a
DKR, and go build it.
Thusly, it seems to me that our job should be to revisit the narrative: mine
this mailing list for gems and formulate a draft text. Mine Rod's web site,
his technology white papers and so forth, mine Gelernter's work, look at
Lenat's work, look around, and formulate a final narrative that everyone can
agree adequately lays out the vision, the market, and the technology
available to us.
Along the way, contributions to the use case and scenario arena will be
valuable. Indeed, they contribute something to the marketing narrative, and
to the requirements document. Ultimately, the requirements document rules.
We damned well better build something that satisfies those requirements.
Testing will determine whether the requirements are satisfied.
Yes, there will be some of us who will jump way ahead and hack some code,
trying to see what works. Doing so adds spice to the narrative, but always
remember that the narrative is NOT ALLOWED to delineate any aspect of
implementation, only to discuss technology.
From: Eric Armstrong <firstname.lastname@example.org>
> To redress the balance, here were Jack's 10 steps,
> derived from the ISO9000 program:
> 1. Descriptive Discussion
> 2. Preliminary Requirements
> 3. Use Cases
> 4. Scenarios
> 5. Requirements Refinement
> 6. Category Level Design
> 7. Class Level Design
> 8. Dynamic Interaction Design
> 9. Coding
> 10. Testing
> Now, to be fair, this is a waterfall model. So we're going
> to find ourselves bouncing all over the place. But it may
> well be that we can focus our *meetings* as though the
> process were actually linear.
> As I recall previous discussions, Jack volunteered that
> Doug had provided #1, and my requirements document made
> a first cut at #2. That made use cases / scenarios the
> next important part of the process, where I have been
> endeavoring to focus attention.
> I am not sure where the WBI proposal fits into this
> framework, but I suspect it is somewhere between item 6
> and 7. I'm not sure what "Category Level Design" is.
> (Jack, can you elaborate on that one?) And I don't see
> a heading for Architectural Design -- I suppose that
> could be subsumed under Class Level Design, although I
> tend to think of it the other way round. (Jack: Can you
> comment on that? Or maybe the explanation of Category
> Level Design will clean things up...)
IT Professionals: Match your unique skills with the best IT projects at
Community email addresses:
Post message: unrev-II@onelist.com
List owner: unrev-IIemail@example.com
Shortcut URL to this page:
This archive was generated by hypermail 2b29 : Wed Apr 26 2000 - 09:53:20 PDT