[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(FC-Devel) Actor reincarnation: concepts, blind spots and roles
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
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
program and everybody involved reports happiness (anything else
be considered failure). Sometimes the thing even gets used for a
Object purists pity such a waste of good energy by downplaying the
An object by definition incorporates both data structure and
What happens to data before and after it is active, that is before
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"
all seems counterintuitive, a concession to the pureness, the
of the system.
While in 1981 Byte magazine exposed object-orientation as a major
(earlier: Simulation and Actor languages) and the term 'relational'
not yet gained momentum, hierarchical database management systems
provided the fine-grained locking and recovery facilities developers
to establish large, robust on-line transaction processing systems
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
hierarchical function decomposition which every modern theory
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
Database management: yes, they are still around and evolving.
Objects live in the dynamic but very limited environment of the
program. Data reside in a static context in which they are basically
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
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
anyway for FreeCASE itself.
I propose to adopt and support some ER-model style to be practical
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
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
Please help. I did not get any suggestions for the glossary for a
while it gets 30 hits a day. I need your input.)