Modeling the return of an object reference

[KP]

So what's wrong with:
   Individual = fillPosition(Position_in)
   Resume = fillPosition(Position_in)
   OrgChartSlot = fillPosition(Position_in)
 
 ?  Still polymorphism, based on the method signature...  

This is what I would go with: explicitly stating what it is you want to receive rather than "encrypting" that information behind an easy-to-overlook property of a return parameter.

By the way, I had a trawl of the UML superstructure and neither Kernel::Parameter or Kernel::Operation has a means of expressing "by reference" or "by value", so a tagged value of your own devising would be needed.

EDIT: obviously those should say Kernel :: Parameter and Kernel :: Operation, but I think I'll leave them with the silly smilies!

[sargasso]

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.

Reflecting on your post re business archictects needing to be experienced business managers, consider this.

You are in your plush 45th floor office, you click on the intercom and yell to your PA, "Get me Brian Johnson now".

Is your PA supposed to get you:
- Mr Johnson in person?
- His file?
- Him on the phone?

IOW I dont think you can do what you are trying to do - even in reality???

BTW:
To me, both Jim and Paolo's examples are not polymorphism.  At least in .NET it is "specialised behaviour exhibited by an object referenced as a base class".  So if we have 3 specialisations of animal - fish, bird, cow - and animal specifies a base behavior "move" which is overridden in each specialised class, (e.g. fish swims, bird flies and cow walks), then:

cow daisy = new cow();
cow myrtle = new cow();

animal[] herd = new animal[2];

herd[0] = daisy;
herd[1] = myrtle;

foreach (animal x in herd) {
   x.move
}


will result in the exhibition of the cow class move behviour i.e. walking.

but if daisy and myrtle are declared as objects of type fish then the foreach loop will exhibit the fish class move behaviour i.e.  swim!  Which is a good thing because the idea of a cow in a fishtank scares me somewhat.

bruce

[Paolo F Cantoni]

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.

yes, that's true, you'd need to polymorphise on name...

Paolo

[jeshaw2]

To me, both Jim and Paolo's examples are not polymorphism.  At least in .NET it is "specialised behaviour exhibited by an object referenced as a base class".

Actualluy, this is an Ad Hoc form of polymorphism known as operator overloading.  
Consider in Java

Code: [Select]


Public class HumanResource {
    ...
    public fillPosition(Position,Resume) {
         /*return a resume object
    };

    Public fillPosition(Position,Individual){
         /* return an individual object
    };
}  a call to HumanResource.fillPosition(Position,Resume) will create a different behavior than a call to HumanResource.fillPosition(Position,Individual).  The external view perceives the method fillPosition to be polymorphic based on the parameter types in the signature of the call.  

[sargasso]

But dont overloads have to return the same type?  Which isn't what you want?

Type differentiated overloads would give you the answer, but you would still have to specify in the CIM which return type you want.

bruce

edit

Then again, you could specialise the class to get the answer you want, as in


class HumanResource {
...
public abstract FillPosition(Positiojn p) {...}
}

class ResumeResource : HumanResource {
public Resume new FillPosition(Position) {..}
}

class IndividualResource : HumanResource {
...
public Individual new FillPosition(Position p) {...}
}


but that seems like overkill.

[jeshaw2]

OOPS!  I coded it incorectly.  Each method is declared with its own return type.  Here is the fix. Sorry.

Code: [Select]


Public class HumanResource {
    ...
    public Resume fillPosition(Position,Resume) {
    /*return a resume object
    };

    Public Individual fillPosition(Position,Individual){
    /* return an individual object
    };
}


So no, overloaded operations don't have to return the same type in Java.  If they don't make any return at all, then their method type is declared as "Void".

Type differentiated overloads would give you the answer, but you would still have to specify in the CIM which return type you want.

Which is why I went with the two parameter In/Out form of the call.

[sargasso]

Which is why I went with the two parameter In/Out form of the call.

Which brings me tortuously and circuitously back to the original question.

If we need to differentiate in the CIM model which return type we want ( as we would have to when telling the PA which form of Mr Brown we wanted), then why bother with overloading, polymorphism, blahblah.

I would just give HumanResource class 3 methods (CIM or PIM) that clearly differentiate what we want done and returned:

Indiviual i = hr.GetIndividual(position)
Resume r = hr.GetResume(position), and
OrgChart o = hr.GetOrgInfo(position)



bruce

[Paolo F Cantoni]

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

So no, overloaded operations don't have to return the same type in Java.  If they don't make any return at all, then their method type is declared as "Void".

Which is why I went with the two parameter In/Out form of the call.

But this only works because the two methods have different parameter signatures...

The following wouldn't work would it¹?

Code: [Select]


Public class HumanResource {
    ...
    public Resume fillPosition(Position) {
    /*return a resume object
    };

    Public Individual fillPosition(Position){
    /* return an individual object
    };
}

Paolo
[size=10]¹I know almost nothing about Java...[/size]

[sargasso]

As far as I can gen it couldn't work in any language :-/
How would the called unit know which method to invoke?  And dont tell me the callee is appraised of the expected return type - if Resume and Individual have a common ancestor, say Object what it is supposed to do if I call it with
Object x = fillPosition(position)



bruce

[jeshaw2]

No Paolo, it would not work.  Java would not see any difference in the signatures.

I don't think we have set a proper base for our polymorphism discussion and we are going in circles with it.  I suggest that issue be restarted in a different thread if anyone wishes to continue its discussion.

As MDA does not envision an automated CIM2PIM transformation, we are free to do syntacticly anything we want in the absence of a UML specification as long as we define and remain consistent with that in our modeling domain.

Therefore, I like KP's recommendation the best and will move forward along those lines.  It is both clear in its semantic and easy to explain to the "Great Unwashed".  

Thank you all for your participation in this thread.

[Eve]

No, the callee doesn't know the expected return type.  The callee always returns the one type and the compiler/interpreter can look at the context and determine which function to call.

A hypothetical language could do this and in the situation where the context is a common anscestor of two or more overridden calls it could give an error that specifies the problem.  Maybe it would even look at how x is used later to determine what type it is, and maybe it would decide that it doesn't care which one you use in that situation, and a subsequent use would need to handle all possible types returned.

And because the CIM world doesn't care about how it happens in any target language it's valid to describe use that way.  It is then up to the transformation (whether manual or automatic) to PIM and PSM to represent this in a way that is possible on that platform.  It could be three methods with different names as you suggested before, three overloaded methods with a different out parameter or three overloaded methods only on the return type.

[Paolo F Cantoni]

As far as I can gen it couldn't work in any language :-/

bruce,

It was, of course, a rhetorical question...

Jim,

If you adopt KP's solution, the CIM->PIM transform will need to transform:

Code: [Select]


Individual = fillPosition(Position)

to:

Code: [Select]


Individual = fillPosition_TypeOf(Individual)(Position)
as I indicated previously

Paolo

[jeshaw2]

Paolo;

My adoption of KP's notation was based upon a manual transformation to PIM.  Are you suggesting that there is an automated CIM2PIM capability?  If so,

• Where is it?
• is the PIM version of the notation a problem?
  

[KP]

It's not my notation - I just agreed with Paolo

[jeshaw2]

Individual = fillPosition_TypeOf(Individual)(Position)

Interesting syntax.  I've been away from the code too long; what language is that?  I thought a PIM was still language independent.

This syntax seems to imply sufficient rigor to support an automated CIM2PIM transformation, where the MDA folks say a manual transformation is the only possible way to go.

Further, KP's notation is really Paolo's notation which Paolo now seems somehow concerned about.  

And what happened to the proposition of using Generics to achieve type independence (assuming polymorphism is inappropriate)?  :-/   Could it be that Paolo's notation is a form of Generics?

I'm confused, but that's how I learn