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

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

Hi Franz, hi all.

Franz Scholz wrote:
 
> On Fri, Aug 28, 1998 at 03:42:52AM +0200, Danny Werner wrote:
> > persistence: All that happens to data before and after it is
> > active (as an object).
> [ Definition of objects, some historical notes snipped]
> > 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.
 
> Talking about persistence of objects: it seems to me that this is
> exactly what constructors and destructors might be used for:
>         Constructor -> initialize object to known state
>         Destructor -> object leaves scope, data is not needed anymore

From the viewpoint of the running program, this is perfectly
correct.
What happens before Construction and after Destruction?

> I'm mostly doing C++ things but it occurs to me that this might be going
> along with "finalize" in Java and persistency in CORBA (at least as used
> in the MICO-ORB: http://www.vsb.cs.uni-frankfurt.de/mico/ or
> http://www.icsi.berkeley.ed/mico/).

That's the way I understood it, too. So either we are right or we
get
to the same mistaken conclusion.

> > 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'd express a different opinion: UML inherited a very big part from
> ER-modeling via all the earlier OO-Modeling methods at least in the
> class diagrams. Being a bit more abstract I'd define class diagrams
> as basically "ER-with-methods-and-inheritance" (at least to someone
> who only knows about ER-modeling ;-). And _yes_ I know, there is more
> to it, but just drop inheritance and methods and you'll get a nice
> ER-diagram from a UML class-diagram (though using a different graphical
> notation).

Syntactically: yes. I agree completely. Even inheritance [is-a] and
aggregation [has-a] can be done - (with some team-conventions - as
special relations (associatons is the term in several CASE-tools, to
add to the confusion :-). 

But the question is: Is this model, the model you got by dropping
methods, (and maybe inheritance in your view) a good model for
storing your data? 

Not necessarily so. Even probably not, because the model was
designed
with only dynamics in a protected run-time environment in mind. Even
reconstructability has not yet been considered.  
 
> Concept graphs will also fit nicely in there as they allow us to model
> all those associations and inheritances. But IMHO if we'd find a
> UML meta-model representation in any language (e.g. argo for a Java
> implementation) we won't need any specializations as UML is intended to
> be a superset of all those /elder/ modeling methods, which I'd call
> something like "draw your ER-diagram using UML notation and forget
> about everything you don't need or understand".
 
> > I think full UML support as a target for FreeCASE is very ambitious
> > and I am very reluctant to want even more.
 
> UML-diagrams are difficult to map to any language, even Rational is
> not fully capable of it (at least this was the last state I heard about),
> but OTOH if we could map use-cases directly to an executable, we wouldn't
> need any tools anymore.

Even more ambitious. I just don't believe that is feasible (yet?)
and
for myself I dismissed it as a worthwhile target (I'll help anybody
who has
convincing ideas about that, though).
 
> > 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).

> Ok, I think I've elaborated my thoughts about that above.

Please take a look at 'role' and 'persistence' in Kendall Scott's
UML dictionary at http://www.softdocwiz.com/UML.htm which is
referred
to in the Glossary under 'UML'.

> > (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.)

> Sorry for not looking at your site first, but
> I'd go for http://www.rational.com/uml as a start, the various UML
> documents do contain glossaries which even include definitions from
> other modeling techniques and their mapping to the UML terms.
> There is even a project for mapping the UML-terms into the german language
> at http://www.system-bauhaus.de/ (but I have not looked at this, only
> read about it).

Been there, done that ;-)
I see the same blind spots there. 

> Just my .02 EUR

LOL

Thanks for your reaction, 
TTYL,

				Danny