Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[Snowball <snowballinfo@rase.com>]

Robert C. Martin wrote:

> 
> Objects execute inside computers.  They take up memory space and CPU cycles.
> Classes are source code.  They specify the objects and create a structure
> from which the objects are created.
> 
This is true for C++ and some other languages, however for Smalltalk
Classes are 
objects which take up memory space (and sometimes CPU cycles). 

> Any method that concentrates on one more than the other is doing a disservice
> to its inventors and its users.  Rather we must focus on both.  We generally
> use dynamic models (i.e object diagrams, interaction diagrams, etc) to specify
> objects and the way that they interact.  We use static models (i.e. class
> diagrams, package diagrams, etc) to specify classes and the static
> relationships between them.

When we are talking about static and dynamic models, something bothers
me. There are 
two types of complexities in any system. One is the static or structural
(or 
sometimes I call it detail) complexity, the other one is dynamic
complexity. 
To me some canonical forms of systems such as class hierarchy can be
reasonably understood 
by static diagrams, however, it is not very intuitive to attempt to
model dynamic behavior 
in static diagrams such as object or interaction diagrams. I can
differentiate between 
structural complexity and dynamic complexity with an example: a car
engine totally taken 
apart and lying on the floor with all parts visible, and even sorted out
to parts, may 
create an atmosphere for us to develop a detailed understanding of each
part but will not 
give us a clear idea of how it runs. An engine timing diagram can help
us but the best way 
to understand how an engine works is to observe it "running" preferably
with a power to control 
the motion of the time domain. This means that we can take the engine,
replace one of the side walls 
of it with say a glass panel, and let it slowly run, even single step,
so that we can follow the 
entire motion. Same analogy for a software system running would be to
add a layered visual 
debugger and a reverse engineering tool to obtain and animate certain
diagrams to observe how the 
behavior of the system changes in time. (It just happens that I am
working on such a visual 
debugger for Smalltalk to be added to a tool I developed)

> There is a mapping between the two kinds of models that must be maintained.
> Every relationship on a dynamic model; that is, ever pathway accross which
> a message is sent; must be supported by a static relationship in a static
> model.

I totally agree here. To me, they are essentially two different views of
the same system. 
We are mostly defining the structure (time independent portion) of the
system with the static 
models, and we shape the behavior of the system (or how a system behaves
in time). 
Of course in many current languages there is a sharp distinction between
these two views 
although in the real world this distinction is thinner than we think.
For every system adaptation 
is a key to survival. Adaptation requires structural change. That means
adding and/or deleting 
classes, or changing class structure or behavior in time. If this is the
case the ?staticness?
(is there such a word?) of the static diagrams will not hold any more. A
correct class diagram 
for a system initially will not be the correct diagram after some
classes are added or modified 
dynamically. 

Tansel Ersavas
RASE Inc.
mailTo:tansel@deep.net
http://www.rase.com/