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

[Franz Scholz <franz@sesuadra.mayn.de>]

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

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

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.

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

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

> 
> Have fun,
>                                    Danny

I hope so, and I hope I've gotten all these URLs right ;-)

Just my .02 EUR

	Franz

-- 
Franz Scholz
franz@sesuadra.mayn.de