Ownership

[jeshaw2]

It is said that there are some questions that should only be asked by little children or great philosophers.  My hope is that this is not one of them.  

Precisely what does the term owner, and or ownership mean in the UML 2 context? The UML 2 Structure Specification often speaks of one element owning another, but it does not provide me a definition that is useful in thinking about Object Oriented design.  

A need to clarify ownership became apparent in a discussion on Collections, Containers, Composites and Nests

Some of my concerns about owning and ownership are:

• What rights does an owner have over an owned element?

• Is own like owning an automobile where I have a title of ownership that I may transfer to others; control who may use the car; destroy the car if I choose; modify the car's behavior, etc.?
  

• When speaking of creation and destruction, it is often noted that we are speaking about objects that hold information about the modeled entity, not the real-world entity itself. Does this hold for all ownership discussions in UML modeling?

• In the UML, ownership seems to be so closely associated with other concepts, such as Composites, that a bit of metonymy (Using one aspect of something to stand for the whole) begins to set in.  Does a composite, by definition, own its component parts?  One might be tempted to unequivocally say "Yes".  However, if ownership implys rights of creation and destruction, this becomes blurred under Inversion of Control (IoC) designs.
  

• Specifying the AggregationKind on an Association results in a diamond decorator at one end of the line where (shared|not owned =>unfilled diamond) or composite (not shared|owned => filled diamond).  In my mind, this blurs the distinction of ownership with aggregation and composition.  As I assert in the parent thread, these concepts stand apart from each other and are not synonyms nor antonyms.
  

• If one class is said to own another, what are we implying about the behavior of those classes?  Is the owning class responsible for any behavior in regards to the owned class?  Is the owned class expected to defer to the owning class (as a slave does to its master) in any way?
  

• In a portioning type of association, does a bread loaf intrinsically own its slices?

• In a substance_of type of association does the bread loaf intrinsically own the flour from which it is made?

• If one element owns another, how is that implemented in the generated code?  I think this goes beyond the coding of attributes, constructors, etc.  I suspect that implementing ownership requires more logic than that.  Perhaps the coding of behaviors that enforce ownership or perhaps stewardship in someway.  I'm speaking of the code that is needed beyond what a code generator might produce to that produced by a human programmer.

I would like to hear everyone's thought on this.

[Paolo F Cantoni]

Given the deafening silence, I'll throw something in...

I asked around at work today and the general consensus was:

Ownership is essentially (and solely) about creation and destruction.

The owner creates the owned.  At this point, the owner is the only thing that can destroy the owned.

The (current) owner controls access to the owned.

A policy determines how many owners the owned item may have a time.  Ownership is cloned by passing a reference to the owned to the the additional owner - through an ownership transfer interface.  When multiple owners are permitted, a mechanism is (must be) provided to notify the other owners when one owner destroys the owned.  References to the owned are then invalidated.

A policy determines if ownership can be transferred.  If ownership is transferred, the previous owner loses access to the owned.

A combination of these two polices can be used in Factory patterns to accomplish their processing.

Access to the owned can be provided to others, through passing a reference to the owned via a non-ownership interface.  The accessor cannot destroy the accessed.

There's some thoughts from downunder...

Paolo

[jeshaw2]

Given the deafening silence,

This entire UML topic has gone deaf.  Perhaps our discussions have answered a lot of questions?

Your comments are powerfull and I provisionally accept them.  However, I need to think about this area:

A policy determines how many owners the owned item may have a time.  Ownership is cloned by passing a reference to the owned to the the additional owner - through an ownership transfer interface.  When multiple owners are permitted, a mechanism is (must be) provided to notify the other owners when one owner destroys the owned.  References to the owned are then invalidated.
 
A policy determines if ownership can be transferred.  If ownership is transferred, the previous owner loses access to the owned.

 Joint ownership is common in the real-world, but this is the first time I've thought formally about it in modeling.  In my earlier days, I confused joint ownership with multiple inheritance and got so confused I put the whole matter out of my mind. The ownership transfer interface concept is powerfull! It models the passing of a real-world title of the owned item. I would like to see an abstraction of how this plays out under joint ownership conditions.  There is, however,  some loss of distinction here between ownership and accessability.  Must one own an entity to access it?

Can anyone discuss the concepts of ownership & accessability in  the context of multi-threaded processes?  I put this into the subActivity_of meronymy. I'm thinking of about thread ownership and also sibling threads having access to their parent's attributes.

Also, the UML mentions [ref: below] that ownership implys that the owner provides space for the owned.  How does that play out under joint ownership?  If an object is cloned, then do we have two objects, each needing their own space?

When I coined the phrase OwnershipKind, I was speaking in half jest.  Thinking of your comments, I went back to the UML Suuperstructure:

7.3.2 AggregationKind (from Kernel)
AggregationKind is an enumeration type that specifies the literals for defining the kind of aggregation of a property.
...
Description
AggregationKind is an enumeration of the following literal values:
• none Indicates that the property has no aggregation.
• shared Indicates that the property has a shared aggregation.
• composite Indicates that the property is aggregated compositely, i.e., the composite object has
responsibility for the existence and storage of the composed objects (parts).
Semantic Variation Points
Precise semantics of shared aggregation varies by application area and modeler.
The order and way in which part instances are created is not defined.

I think they have the concept correct...well, almost..., but they got the names & enumeration lables wrong:  
Aggregation => Ownership
AggregationKind => OwnershipKind
shared =>  Shared access? | Joint ownership?  :-/ I prefer the latter.
composite => Sole owner?
This is not far from the observations from 'down under'    Also, the last underlined statement give us a license to make of this what we will.    I'm firming up my convictions about using the term Ownership Diamonds.

[Paolo F Cantoni]

Jim,
Just a quick note on part of your post.

[size=13][SNIP][/size]
The ownership transfer interface concept is powerful! It models the passing of a real-world title of the owned item. I would like to see an abstraction of how this plays out under joint ownership conditions.  There is, however, some loss of distinction here between ownership and accessibility.  Must one own an entity to access it?

Yes, I thought the real-world idea of Title is a powerful thing.  I often re-use real world concepts in this way.  That way, the systemic processing ends up being very "natural".

As to how the ownership transfer interface plays out, there are a number of things you can do in computer systems or in analogues of the real world that you can't do in the real world.  Just because you CAN do it, doesn't mean it's a good idea to do it.  For example, the notion of a public destructor giving anybody the ability to destroy me I think is too dangerous.  The idea behind the ownership transfer interface is that the destructor is set up to require authorisation from an owner to conclude destruction.  In other words, the destructor requires proof of title before it allows destruction.

The ownership transfer interface includes the non-ownership (accessor) interface.  Essentially, you need access to destroy, but getting access doesn't give you the right to destroy (you need title).

[size=13][SNIP][/size]

Does that clarify things?

[jeshaw2]

On the ownership transfer interface, it does clarify things. The other issues still remain; plus I have a new concern.

What can we say about an object's ownership when it is serialized and presistant in a database or 'beamed' across the network to a new host?

Are we adamant still, that ownership does not contain a responsibility to provide space for the owned object?

[Paolo F Cantoni]

[size=13][SNIP][/size]
Are we adamant still, that ownership does not contain a responsibility to provide space for the owned object?

Jim,
Just a quick note...

I don't think I said that ownership does not contain responsibility for space.  Creation requires allocation of space (somewhere).  What I was trying to say was that ownership is solely in the context of creation and destruction (and, of necessity, concepts that flow from those two processes - like space management).

I'll have more to say later...

Paolo

[jeshaw2]

OIC  

In other words, the destructor requires proof of title before it allows destruction. The ownership transfer interface includes the non-ownership (accessor) interface.  Essentially, you need access to destroy, but getting access doesn't give you the right to destroy (you need title). ...

and, of necessity, concepts that flow from those two processes - like space management

These thoughts are related to my concept of Stewardship responsibilities which I may, or may not, develop more fully later.  Depends on how much of it is assigned to the owner by way of this discussion.

I've started thinking about abstraction layers of the Ownership Transfer Interface.  Perhaps, for example, higher levels providing getter access, then a specalization to add setter|mutator access, and finally a lower level for entitled access.  But then, isn't this some of what ports are all about on the Composite Structure diagram?  Hummm, this may be an implementation issue.  :-/

I'm getting a little nervous about over engineering this interface.  Could it be that I'm talking about levels of policy abstraction?

[Paolo F Cantoni]

Jim,

Looking back at (my) post number 2, I've just spotted a typographical error:

Ownership can be cloned or shared via the Ownership Sharing Interface - the current Owner retains ownership but shares it with the other party.  (the typo was Ownership Transfer Interface - there is NO transfer here...)

Ownership Transfer Interface is used to transfer ownership from one party to another - the transferor loses ownership.

Accession Interface grants access (Get/Set).

Being granted ownership (either by creation, sharing or transfer) automatically provides access.

Transferring ownership may relinquish access [Policy].

Transfers may be made back to an existing owner.

The last owner cannot relinquish ownership - they must destroy the object.

Because accession does not allow destruction, one can pass a cast of a polymorphic object through the interface.

Because ownership does allow destruction, then only the original type can be referenced.  This ensures that space is correctly managed.

It's important to ascribe to each interface the appropriate policies.  Thus get/set access is a policy decision on the Accession Interface.  They aren't on the Ownership Interfaces.

So, I don't think the term is policy abstraction, but it is about policy based design...

HTH,
Paolo

[jeshaw2]

You speak with such clarity of thought!   I was also wandering those lines of thought.  Yes! I agree with all of that.

My concern with 'over engineering' arose out of thinking about simple arrays and vectors containing references to primative types with wrappers.  I don't think I want to impose high-order interfaces on them unnecessarily.

I think we've come a long way with the definition of ownership. So far, our points work well in the context of parts ownership.  By way of review, do you think it works well with ownership of features and propertys as well?

[sargasso]

1) Just a quicky on the "provides space" issue

responsibility for the existence and storage of the composed objects

If this is the source of the space comment, then I don't think "responsible for storage" is synonomous with "provides memory allocation"  - its another level of abstraction up.  

For example, my_booking::reservation  may own my_ticket::ticket,  my_ticket  is created by my_booking and stored as a physical piece of paper printed by a whole heirarchy of other elements chaining through to my_printer ....
my_booking has the responsibility for, and manages the storage of my_ticket, but it is not directly responsible for "creating the space".


2) I'm still trying to cath up with you guys - I'm only getting about 10 min per day of free time at the moment.  However, it seems to me that this thread has been a biot ambiguous about delineating between "instance ownership" and "ownership at the classifier level".  Poalo's 1st reply seems for instance, to directly relate to ownership at the instance level.  Don't know if you guys have transcended this problem, but I'm still struggling with it.

CUL

bruce

[Paolo F Cantoni]

1) Just a quicky on the "provides space" issue
If this is the source of the space comment, then I don't think "responsible for storage" is synonymous with "provides memory allocation"  - its another level of abstraction up.

bruce,
Could be so... Keep talking...

For example, my_booking::reservation  may own my_ticket::ticket,  my_ticket  is created by my_booking and stored as a physical piece of paper printed by a whole hierarchy of other elements chaining through to my_printer ....
my_booking has the responsibility for, and manages the storage of my_ticket, but it is not directly responsible for "creating the space".

See above...

2) I'm still trying to catch up with you guys - I'm only getting about 10 min per day of free time at the moment.  However, it seems to me that this thread has been a bit ambiguous about delineating between "instance ownership" and "ownership at the classifier level".  Paolo's 1st reply seems for instance, to directly relate to ownership at the instance level.  Don't know if you guys have transcended this problem, but I'm still struggling with it.

Well, for my part, I am explicitly discussing instance ownership since that's what's meant by the ownership diamond (as Jim now, more correctly calls it).  However, can you explain the difference between "instance ownership" and "ownership at the classifier level"?

Paolo