ACTION DESIGNER
                        OBJECT ORIENTED ANALYSIS
                             AN EXPERIMENT
                             As of 3/1/90


    Object-Oriented Analysis (OOA), Object-Oriented Design (OOD) and
    Object-Oriented Programming (OOP) have gotten a lot of attention
    lately.  Most of the discussion has centered on programming
    languages like C++ and Smalltalk.  To say that there is 
    controversy would hardly describe the battle.

    I'd like to fire a slavo of my own: you can't do OOP or OOD if
    you can't do OOA.  In other words, if we don't know where we
    are, how can we know where we are going or how to get there?

    Now, you might reply, OOA is easy.  Identify the objects making
    up the system (any system), define them as abstract data types
    and you've done OOA.  From there, it is straightforward to
    do OOD and OOP.  Says who?

    We aren't even close to having robust OOA methodologies and tools.
    Maybe we shouldn't bother, but my gut tells me that it is 
    worthwhile to pursue the subject.  One of the problems is, we 
    need some kind of a model as a starting point.  It would also 
    be a good idea if the model had some basis in practical 
    experience as well as theory.

    AD contains an EXPERIMENTAL feature: Action Diagram constructs
    for one such model.  The model is derived from a recent book:

             OBJECT-ORIENTED ANALYSYS
             Peter Coad and Edward Yourdon
             Yourdon Press, 1990

    If you have an interest in the subject, you will want to pick this
    one up.  The authors claim industrial strength experience in OOA
    and present a potentially useful model which they claim has worked
    for them.

    The OOA process Coad and Yourdon describe involves identifying
    objects, structure, and subjects and defining attributes and
    services.  They also present a diagramming technique that I
    don't much care for.

    Here is what they say about objects:

             "An object is an encapsulation and an abstraction:
             an encapsulation of Attributes and exclusive Services
             on those Attributes; an abstraction of the problem
             space, representing one or more occurances in the
             problem space."

    Whew.  You'll have to read the book to put some flesh on those
    bones.  But, this is the basis for AD's OOA extension.  

    You can use the Object menu just like the Action menu to insert
    OOA supporting control brackets.  There are brackets for Classes 
    Sub Classes, Attributes and Services.  They will allow you to 
    describe hierarchies of objects and browse them by controlling 
    the level of detail displayed.  Keep in mind that Objects are
    synonomous with OOP Classes, Attributes with Variables and
    Services with Methods.

    I think that, with some refinements, it eventually will be 
    possible to generate code.

    Rather than try to rewrite the book here, why don't you take a
    look at what is in AD, try it out, read the book and call me so
    we can work through this together.  I'll add more to this 
    discussion as I learn more.  Maybe we can get some sort of
    thread going on CompuServe.

    Please register.

    Lou Barnett
    MetaLogic Corporation
    (805) 529-4498