Modeling the return of an object reference

[jeshaw2]

Modeling at the CIM level, I have a HumanResource object with a method FillPosition(Position_IN) that returns, hopefully, a reference to the individual who has been selected to fill the position.

I don't want the object itself, just a reference (of the corrrect type) to it.  Nor do I want a reference to the class if such a thing happens to exis in the PSM.

In EA Properties->detail->operation for the HumanResource class, what do I put in the Return textbox?  Do I use the name of a classifier, or specify the general type known as "object" in order to get a reference to the object?

How is specifying a return in this way, differ from FillPosition(Position_IN,Individual_Out) ?

Actually, a better design would be for the FillPosition operation to make a <<staffedBy>> association between the position and the Individual and simply return a boolean success/fail token, but I needed an example to be able to ask my question which is focused on the proper use of the Return Textbox

[Paolo F Cantoni]

Jim,

Since no one else has responded, I suspect that my initial observation that your semantics were ambiguous is likely true...

Can you define HumanResource, Individual, Position and the semantics of  FillPosition?

My initial thought was that Position would have a method Fill, but since the semantics are unclear...

Paolo

[jeshaw2]

HumanResource:  An object, instantiated from the HumanResource class, that models the behavior of the Personnel function of an organization.

Position:  An object, instantiated from the Position class, that models the features of a job or role within an organization.

Individual:  An object, instantiated from the Individual class, that represents a person who has been designated to staff the position.

fillPosition:  A goal-oriented behavior of a HumanResource object which, if successful, designates an Individual to fulfill the responsibilities of the Position.

My question is, in EA, how do I make an entry in the return property of the fillPosition method that explicitly states that I expect a reference to Individual, rather than the individual itself (perhaps in some serialized form, or however objects are moved around at the PSM level)?

I guess what's running around in my head is the concept of "return an object" vs. "return a reference" analogous to "return by value" vs. "return by reference".

Does this help?

[Paolo F Cantoni]

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

Well, I'm not sure I understand your model - I'd come up with a different one - but that's not really germane any more to your actual query...

My question is, in EA, how do I make an entry in the return property of the fillPosition method that explicitly states that I expect a reference to Individual, rather than the individual itself (perhaps in some serialized form, or however objects are moved around at the PSM level)?

I guess what's running around in my head is the concept of "return an object" vs. "return a reference" analogous to "return by value" vs. "return by reference".

Does this help?

Normally, objects are reference types (in .Net speak).  You can't have objects "by value".  The only situation that I can think of that comes close is providing you with an XML property set that corresponds to the "facts" about the object.   However, this is a string and requires demarshalling to instantiate an object - corresponding to those facts.

Does that help?

Paolo

[«Midnight»]

Paolo,

Still in .Net speak, remember that Structures are value types. These are similar enough to objects that Jim's requirements would likely be relevant. And since they are often used where light 'weight' and good performance are requirements, a reference-passing pattern would be a plus.

David

[Paolo F Cantoni]

Paolo,

Still in .Net speak, remember that Structures are value types. These are similar enough to objects that Jim's requirements would likely be relevant. And since they are often used where light 'weight' and good performance are requirements, a reference-passing pattern would be a plus.

David

This is true, David.  

However, you can't return a structure by reference¹.  

My point is, that in both cases, you are returning an instance of the appropriate classifier.  That's all you need to tell the model (EA).

The tool should figure out the rest.

Paolo

¹Assertion by a .Net newbie.  I stand to be corrected.

[jeshaw2]

Dave & Paolo;

I understand what you are saying at the PSM level of abstraction, but I'm thinking of the long-term viability of the CIM as a corporate asset.  As such, a CIM needs to survive paradigm shifts in underlying PSM technologies.  On the Starship Enterprise, the return of an object may not be a simple reference to it.

Does that help?

[Paolo F Cantoni]

Dave & Paolo;

I understand what you are saying at the PSM level of abstraction, but I'm thinking of the long-term viability of the CIM as a corporate asset.  As such, a CIM needs to survive paradigm shifts in underlying PSM technologies.  On the Starship Enterprise, the return of an object may not be a simple reference to it.

Does that help?

I don't see why you need to be worried at levels above the PSM.

To me it's like worrying about the (almost) artificial difference between References and Pointers in C++.
(Again, I'm not a C++ guru) A reference is a pointer that can't be null.  Yet it has completely different syntactic implications. (dot versus -> accessors).

Under what circumstances (at a CIM level) do you need to actually worry about the accession mechanism for the returned instance?

In the case of parameters, you do need to (by implication) worry about accessions since if you have an out (or inout) parameter, it restricts your options.  

Paolo

[«Midnight»]

I suspect there are cases where, even from the lofty perspective of the CIM, you would want to specify (or at least indicate preference for) which mechanism would be used.

While this might be below the radar in the case of platform implementation of object identification (such as how an obect reference works), it might be significant in terms of whether an object is (or may be) replicated (during function returns or whatever).

[«Midnight»]

Paolo,

Opps, that was sloppy of me. You can pass a reference to a structure, but since there is no mechanism for static structures, returning such a reference would be impossible.

Sorry about that...

David

[jeshaw2]

Perhaps I've asked a sloppy question.  Let me do a rewind on my thinking.

One of my current tasks is the building of a Business Case for CIM development which I may present to C-level management.  I feel that a CIM has great value in:

• Requirements analysis:  A base for PIM development
• Asset protection:  An unchanging base of understanding the business in the face of on-going technological evolution; CIMs are expensive to develop
• Policy Analysis:  An executable model used to measure the business impact of revised management policy and/or organizational restructuring
  

Therefore, I see a CIM as a business model, not a high abstraction of an application system.  When I execute the CIM, I want it to behave just like the business behaves, without being constrained by the capabilities of an underlying implementation technology.  If I develop a CIM for policy analysis, there may never be a PIM.

Thus when, as a manager, I request HR to fillPosition, I may want:

• The object itself - That individual standing front and center at my desk on the day he/she reports to work
• A data object - An artifact that provides detailed information on the selected individual
• A object reference - The individual's name and phone number.
  

Perhaps the Return field is not the place to specify which of these I want.

[«Midnight»]

Just off the top of my head - I've got to dash and have not thought this all the way through - could we apply design patterns here?

For example:

object reference - The individual's name and phone number

might be possible through something like a memento.

I don't mean this to be 'The Way' but perhaps it could point us towards an approach.

[jeshaw2]

You are quite possibly right; I was just hoping the Return field might be a short-cut notational form.  Yes, I can see that a pattern might do, but it would be more work me to develop and for the stakeholders to understand.

Perhaps polymorphism, based on the parameter signature, is an answer.  For example:
   fillPosition(Position_in,Individual_Out)
  fillPosition(Position_in,Resume_Out)
  fillPosition(Position_in,OrgChart_Out)
All of these methods would create a relation between the individual object and the position object.  I don't think this would be considered a side-effect since the Position is passed in as a parameter. Is that correct??

I'm still not sure of the semantic difference of this form of syntax from one using the Return specification

[Paolo F Cantoni]

Perhaps polymorphism, based on the parameter signature, is an answer.  For example:
   fillPosition(Position_in,Individual_Out)
   fillPosition(Position_in,Resume_Out)
   fillPosition(Position_in,OrgChart_Out)
All of these methods would create a relation between the individual object and the position object.  I don't think this would be considered a side-effect since the Position is passed in as a parameter. Is that correct??

I'm still not sure of the semantic difference of this form of syntax from one using the Return specification

So what's wrong with:
   Individual = fillPosition(Position_in)
  Resume = fillPosition(Position_in)
  OrgChartSlot = fillPosition(Position_in)

?  Still polymorphism, based on the method signature...  

Actually, this shows the difference between the CIM and lower level models.  In the CIM, there are a multitude of ways to create a "reference" to another CIM object.  In the PSM there isn't.  If you wanted, you could generalize Resume and OrgChartSlot to IndividualReference.  Resume and OrgChartSlot would then have multiple inheritance (to IndividualReference and Document and OrgChartItem respectively).

Paolo

[«Midnight»]

Several paradigms prohibit signatures that differ only in the return type. (.Net for instance)

Although that is getting down well below the CIM, it would be nice to have a broad base of platforms with straightforward implementation paths.