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

[Soren Skogstad Nielsen <ddf8732@dialip.sdn.dk>]

Snowball wrote: (and many others)
> 

> 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 have some experience with a notation which keeps the dynamic and
static properties in sync. Thereby you actually have ONE basic model
from which you may derive a static AND a dynamic view. It is my
experience that the interplay between the static and dynamic views
enlightens my understanding of the structure of both and thereby of
their same underlying model. To this notation is coupled a 
description of when to look for what in the two views. This guide
telling when to decide on what (coupling, inheritance, methods,
aggregation, etc) is in fact what I understand with the concept a
methodology. 
It is described under the name of OoASE, a tool supporting the notation
and the
methodology is available too. You may send me a mail if interested in
more information.

- The world is just one big friendly surprise -

Soren Skogstad Nielsen
A-Informatik
Bredgade 36 E Copenhagen Denmark
email: soren.s.nielsen@ddf.dk