Re: Documenting Individual Objects

[agate!howland.reston.ans.net!zaphod.mps.ohio-state.edu!darwin.sura.net!ne ws.duc.auburn.edu!eng.auburn.edu!henley@ucbvax.Berkeley.EDU (James Paul Henley]

In article <1993Apr23.162629.8897@zoe.network23.com> terry@zoe.network23.com (T
erry) writes:
>
>development.  The problem I have seen with current documentation methods is
>that it difficult to know what state changes will occur as a result of a
>message send.  This is very important when developing a complex application.
>Such applications frequently are decomposed as cooperating agents.  The
>problem is when a method of one object may send a message to a cooperating
>agent which results in another message eventually being sent back to the
>original object and changing its state.  The programmer who wrote the original
>message may be unaware of the complex relationship and therefore the state
>change results in the object being in an unanticipated state and eventually
>causing a software error.  While it may be easy to say that this occurred
>as a result of poor design, when one examines each method in a local context
>they appear ok.  Whats really needed is to examine them in a global context.
>This is the same as the tradeoff between local and global optimization.
>The object-oriented paradigm aids the designer in decomposing a problem by
>reducing the complexity of the problem into a description of several smaller,
>but local, descriptions.  What we need is a tool to recompose the global
>description from the local descriptions so the global interactions can be
>brought to our attention.  Sort of looking at the forest instead of the trees.
>

Believe it or not, you just summed up how I intend to use OO for Chemical
Process Modeling.  I need a tool to decompose a process into cooperating
agents, which we would call "Unit Operations".  Then I need to take it
one step further and decompose those into "Stages".  Each stage is fairly
simple to describe, at least compared to the process as a whole.  Then those
stages need to send messages back and forth, and the unit operations need
to send messages back and forth, and the result of this exchange of 
information is highly complex, with the state of every single stage being
affected by the complex relationships.

I am counting on the complexity of the interactions between software objects
to be analogous to the complexity of the interactions between real objects.
The interactions in a chemical process are continuous, and so you have to
correct for the fact that you are using a model that is based on discrete
events.

Really what I am doing is the same in principle as analog computers, which
are still used in the chemical industry.  You can build an electrical circuit
that is analogous to a simiplified chemical process, and then use the
same analysis techniques, such as Laplace transforms, and transfer functions.
The problem is that to model a real world process accurately, you have all
sorts of non-continuous perturbations that transfer functions simply can't
handle.  And when you try to model highly non-linear, *very* complex systems,
such as real world chemical processes tend to be, the anaysis using
transfer functions gets out of hand in a hurry.

Surely some of your "applications" have applications outside of Computer
Science, don't they?  I can see where an accounting application, for 
example, would have complexities that only an accountant would fully
understand.  While I was in grad school, I moonlighted as a programmer,
and I customized an accounting package written in FoxBase for SCO Xenix.
Although I completely understood how the information got from place to 
place, and how the calculations were performed, I still did not understand
how any one particular transaction affected the overall picture as well
as the plant comptroller did.   And all those blasted paper trails drove
me crazy, but then I never had to face the auditors...

Dr. James P. Henley Jr.
Department of Chemical Engineering
Auburn University