(FC-Devel) Actor reincarnation: concepts, blind spots and roles

[Danny Werner <danny@vrijdag.xs4all.nl>]

persistence: All that happens to data before and after it is active
(as an object).

Data and objects reflect real-world entities.
As such they are concepts. Both need a (similar but different)
organizing process in any application development.
Calling 'our' method "Concept Oriented Design" as Chen Ofek proposed
would IMO overstress the similarities and give us an extra blind
spot.
Where they _are_ similar however (connected nodes),
concept graphs can help us a lot.

Data driven in the 90's:
Some RADs go like this: after a JRP a preliminary
ER-model is made and the initial 'prototype' is just a collection
of CRUDs. The timebox ends before any significant change in the
(now)
program and everybody involved reports happiness (anything else
would
be considered failure). Sometimes the thing even gets used for a
while.
Object purists pity such a waste of good energy by downplaying the
dynamic aspects.

An object by definition incorporates both data structure and
behaviour.
What happens to data before and after it is active, that is before
and
after it is an object, is out of scope in a very natural way.
Persistence traditionally has been the blind spot of thinking in
objects. "System image" saving (early Smalltalk), "serializing"
objects
all seems counterintuitive, a concession to the pureness, the
elegance
of the system.

While in 1981 Byte magazine exposed object-orientation as a major
force
(earlier: Simulation and Actor languages) and the term 'relational'
had
not yet gained momentum, hierarchical database management systems
allready
provided the fine-grained locking and recovery facilities developers
need
to establish large, robust on-line transaction processing systems
(the
fact that some of those will even be ported to the next century only
illustrates that they are hard to get rid of).

It seems that the two historical responses to the classic
proces-oriented
hierarchical function decomposition which every modern theory
despises
1. data (base) driven application development and 
2. object oriented development
do not get along very well. OODBMS even sounds like a contradiction;
Object management: yes, every run-time environment for oopl has to
do that.
Database management: yes, they are still around and evolving.
Objects live in the dynamic but very limited environment of the
running
program. Data reside in a static context in which they are basically
open
to any query, comparison and (mis-)interpretation.

The structures designed for hidden, active, objects in a dynamic,
but essentially closed system differ from the structures designed
for
exposed, passive, data in a static but open context.

I think full UML support as a target for FreeCASE is very ambitious
and I am very reluctant to want even more.
However, I agree with Scott Ambler in
"Software Development Magazine sep 1998 page 69"
who states that the UML is incomplete in this respect.
So we want to support the activities in software projects?
We will have to take persistence issues serious, our "customer"
counts on it. Furthermore we will have to deal with persistence
issues
anyway for FreeCASE itself.

I propose to adopt and support some ER-model style to be practical
and
build on years of experience (Yes I have my preferences. 
Which? Later. Maybe).

(Uh-Oh. Hm.. this requires a lot of work on the glossary: Words like
  association,
  subtyping,
just have different connotations, impact, when used in ER-modelling
vs. Object-modelling context. We will need crisp definitions (
or at least descriptions) of what we mean with words like
  graph,
  diagram,
  node,
  port,
  connection,
  structure,
  model,
  concept,
  repository,
  meaning,
  role.
Please help. I did not get any suggestions for the glossary for a
month now,
while it gets 30 hits a day. I need your input.)

Have fun,
                                   Danny