Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Paolo F Cantoni

Pages: 1 ... 350 351 [352] 353 354 ... 410
Uml Process / Re: "CRUD"ing in Use Cases
« on: May 24, 2006, 06:59:59 am »
Don't forget Peter F. Drucker...


Uml Process / Re: "CRUD"ing in Use Cases
« on: May 24, 2006, 01:02:45 am »
However, nothing will beat your own practice  ;)
Right on Thomas,

This reminds me of the aphorism:

An amateur practices until they get it right.

A professional practices until they can't get it wrong...   8)


Uml Process / Re: Modeling the return of an object reference
« on: May 26, 2006, 08:19:59 am »
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 rigour 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  ;D
Sorry for spreading confusion...  The point about my original syntax is that very very few languages are able to support polymorphism by return type (only) and then in a very restricted fashion.

As to the TypeOf(Individual) construct I was trying to show that if you tried to use polymorphism by return type, you'd have to transform it to named specific method somewhere on the transform chain in order to use it in the PSM.  Since in the expression:

Individual = fillPosition(Position), Individual is actually a variable, you'd need to get it's type (such as Person - or Individual the type) so as to transform it to:
Individual = fillPosition_Person(Position) or fillPosition_Individual(Position).


Uml Process / Re: Modeling the return of an object reference
« on: May 25, 2006, 06:39:22 pm »
As far as I can gen it couldn't work in any language :-/

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


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

Individual = fillPosition(Position)

Code: [Select]

Individual = fillPosition_TypeOf(Individual)(Position)

as I indicated previously


Uml Process / Re: Modeling the return of an object reference
« on: May 24, 2006, 11:29:24 pm »

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 it1?
Code: [Select]

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

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

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

Uml Process / Re: Modeling the return of an object reference
« on: May 24, 2006, 05:05:19 pm »
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... ;D


Uml Process / Re: Modelling the return of an object reference
« on: May 24, 2006, 01:51:15 pm »
Perhaps polymorphism, based on the parameter signature, is an answer.  For example:

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(Positionin)
  Resume = fillPosition(Positionin)
  OrgChartSlot = fillPosition(Positionin)

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


Uml Process / Re: Modeling the return of an object reference
« on: May 24, 2006, 07:09:52 am »
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.  


Uml Process / Re: Modeling the return of an object reference
« on: May 24, 2006, 06:43:59 am »

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.

This is true, David.  

However, you can't return a structure by reference1.  

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.


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

Uml Process / Re: Modeling the return of an object reference
« on: May 24, 2006, 05:43:10 am »

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?


Uml Process / Re: Modeling the return of an object reference
« on: May 23, 2006, 06:25:29 am »

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


Uml Process / Re: Frames
« on: May 23, 2006, 05:18:57 pm »
What about the "panel" stereotype?


Uml Process / Re: BPMN Association
« on: May 19, 2006, 12:28:19 am »
An Association Flow is line that MUST be drawn with a dotted single black line (as seen in Figure 10.)
As I indicated in the previous post, Association Flow is a non sequitur (and therefore probably a typo).
Your point is taken.  I'm assured by Neil that the decision to go with a UML Dependency has nothing to do with the fact that a UML dependency already is defined as a dashed line!


Uml Process / Re: BPMN Association
« on: May 19, 2006, 12:21:16 am »
I received the following reply from Neil (KP) at Sparx:

The problems of different technologies using the same words to mean different things...

A UML Association is described as follows:
"An association specifies a semantic relationship that can occur between typed instances. It has at least two ends represented by properties, each of which is connected to the type of the end. More than one end of the association may have the same type."

A BPMN Association is described as follows:
"An Association is used to associate information and Artifacts with Flow Objects. Text and graphical non-Flow Objects can be associated with the Flow Objects and Flow. An Association is also used to show the activities used to compensate or an activity."

The BPMN Association doesn't sound much like a UML Association to me - there is no notion of types or properties. In the absence of an official UML Profile for BPMN to map BPMN elements to UML metaclasses, we have had to consider what we felt fitted best.

In my opinion, BPMN Associations are closer in nature to UML Dependencies than UML Associations. If you can think of a UML metaclass more appropriate than Kernel:: Dependency then I would be pleased to hear, but (name excepted) Kernel:: Association isn't it.

Neil has given permission to post it here and to discuss it.

The question seems to hinge on whether a BPMN Association is closer to a UML Association or a UML Dependency.

Just for completeness, here's the UML definition of a UML Dependency:
"A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation.  This means that the complete semantics of the depending elements is either semantically or structurally dependent on the definition of the supplier element(s)."
Incidentally, a UML dependency is ALWAYS a directed relationship.  Specifically, the arrow is at the supplier end - denoting that the client is dependent upon the supplier.

It seems to me (from my reading of the BPMN Specification) that the BPMN Association falls between the two stools of UML Association and UML Dependency.

Conceptually it is described as an Association (since it doesn't "flow").  However, a UML Association is specifically between typed instances - which Flow Objects (in BPMN aren't).  However, when a BPMN Association is directed, the arrowhead (from what I can see) is actually at the client end rather than the supplier.  This makes it more like a navigable UML Association in that respect.

Consistency, Consistency, Consistency! TM

As Neil said, there is no formal UML BPMN profile.

The more I look at the specification, the more I think there are actually distinctly two types of BPMN Association:  The undirected (Note-Link) form and the directed (more associative) form.  The compensation Association Neil mentioned in the BPMN Association definition is definitely one of the latter.

Perhaps, OMG will sort this out in a later revision of the Specification.   ::)

Thoughts anyone?

BTW Neil, as you can see... I am no longer as hard line as I was earlier...  ;D
[size=0]©2006 Paolo Cantoni, -Semantica-[/size]

Uml Process / Re: BPMN Association
« on: May 18, 2006, 07:22:10 pm »
I'm with you now.  I agree regarding the reference difference.  I noticed it as well and changed it in my BPMN to be what I intended, but didn't recognize the inconsistency with the rest of the tool.  Good thing to point out.
OK, I'll post a formal defect to Sparx.  For my part, if they can't fix it immediately, I'm satisfied with it being fixed in a near future major release.  It's the commitment that I'm after.  Also, Since Sparx haven't changed the DB in a long while, I think a refactor tool to automatically convert all Dependencies with «Association» stereotypes to Associations should be provided.
I think I see the point on pools and lanes.  I need to think about it more though.  It isn't just arbitrary because if I understand right, a sequence flow cannot pass through a pool boundary, but it can a lane boundary.  Oh.. yeah.. I got it.  I like it.  It helps separate the business in a way.  I should only use a pool for a very discrete and independent business entity (be it an entire company, unit within a business, or a role/individual).
Yes, I sort of see it as an ActorCollection.  The downside of this is that each collection has to have at least one item (the Lane) - which is the actual Actor.  But the improvement in consistency is a small price to pay.
I'm still learning BPMN.  I'm trying to make some BPMN diagrams in Sparx EA, but I'm having troubles figure out how to use EA to do some of the things that I know can be done with BPMN.  For example, there are a bunch of specializations for each of the BPMN types.  Like a sub process.  How do I draw a sub process?  How do I tie the sub process as a single activity object to the actual full blow up sub process itself?  I know this is a tangent from this thread, but we're on the topic.

We're all learning BPMN, I think.  In fact, I'd suggest to Sparx that it will be a hot topic and it may pay them to set aside a separate forum for BPMN.
I agree with you questions.  I'd like answers to those also.  Perhaps it would be worth a separate thread?


Pages: 1 ... 350 351 [352] 353 354 ... 410