Re: [unrev-II] Jack Park's "10 Step" Program

From: Jack Park (
Date: Wed Apr 26 2000 - 09:33:35 PDT

  • Next message: John J. Deneen: "Re: [unrev-II] Groupware and Corporate Repositories"

    Longish, sorry.

    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 <>
    > 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:
      List owner:

    Shortcut URL to this page:

    This archive was generated by hypermail 2b29 : Wed Apr 26 2000 - 09:53:20 PDT