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 ... 415
Uml Process / Re: Is a Association a Method?
« on: November 24, 2006, 11:42:21 pm »
Is this where we should have the black dot (where the line connects with the classifier) ?

EA doesn't (yet) support the ownership dot.   The check-box is there to support it when it comes. [Edited in the light of subsequent postings...]  My comments related to the fact that if you selected a role, then you are specifying that the End is owned.  Technically, EA should check that box automatically if you select a role.  Sparx have recently conceded that they should (and will) be synchronizing owned AssociationEnds and Attributes better.  In the meantime - they have (with build 800) added some cross-checking.  This should be included (see below).

I don't know how familiar you are with modelling tools in general, but for the most part, when a tool manufacturer says they support a particular version of a standard they usually mean "What is the absolute minimum I can do and still get away with saying I support it...".

Sparx are no worse than others and better than most...

Put in a formal change request - both for the dot and the checkbox.


Uml Process / Re: Is a Association a Method?
« on: November 24, 2006, 05:17:31 pm »

I don't know enough about Java; but 'Getters' and 'Setters' are methods... can remember something about being good encapsulation practise, before we got C# and first class Properties. ::)

And I haven't quite worked out 2.1 'Owned end' options yet; if it's own then the end belongs to the class otherwise the association; presumably some kind of accessor function would be needed.

Doe's UML say anything about how you implement association in a runtime?

Or am I just rambling, it's gone midnight.

Hi Kevin,

In [size=13]Property Redux[/size] I agree with you that 'Getters' and 'Setters' are just methods (my emphasis).

As to owned Ends...  If the AssociationEnd has a Role, then that End is owned by the Classifier at the other End.  (That's why the dropdown on the Roles shows the opposite End's attributes - but see: [size=13]DB relationships vs UML Associations[/size]).  If the Association has no role on that End, then the End is owned by the Association.


Uml Process / Re: Is a Association a Method?
« on: November 24, 2006, 04:16:05 pm »
An Association is a link between two objects.  It is definitely not a method.  Therefore, one would not find it in the project browser.  Links appear as a line between the two objects in a diagram.  As normally implemented in code, and depending on the navigation directionalities, links appear as attributes in the associated objects.

I'm really surprised to hear that RSM treats associations as methods.
Most modelling tools DO show Associations in the browser (typically below methods).  They appear twice - once for each end.  That's probably what Ralph is referring to.

When you first come across to EA, it is a bit of a shock not to see them there...  EA's UI (Unique Interface) strikes again.  However, it must be said, that after a while you don't really miss them not being there too much, as other windows DO show them (Hierarchy window [Ctrl+Shift+4]).  But since you can't get at their properties through these windows, it doesn't quite give you the same functionality as the other products.


Uml Process / Re: how to copy and paste a whole sequence digram
« on: November 23, 2006, 02:38:28 pm »

I want to know, how I can copy a whole sequence diagram within the messages (not only the lifelines)? Any idea?
Using EA 6.5.797

We've had some success doing it via queries directly to the DB.

(usual caveats).

As I've said elsewhere, Sequence diagrams are distinctly different from most others.  If you need more help - just ask.


Uml Process / Re: Newb - How to restrict range?
« on: November 12, 2006, 03:36:51 pm »
I didn't think that was allowed under W3C specifications...

If it is, can you point me at the spec?


Uml Process / Re: Navigability
« on: November 02, 2006, 08:04:00 pm »
On the other hand, because the package end is not navigable, there is no attribute for the Package in Stuff.

The equivalent represented with end ownership notation would have a dot at the end of the navigability arrow.
While I agree with what you've said, what is the function of the +package then?


Uml Process / Re: Navigability
« on: November 02, 2006, 05:42:59 pm »
No, I don't think it is.  As I said, Figure 7.23 shows the UML 2.1 notation for associations navigable in both directions to use the arrow head on both ends.
Sorry Simon, I missed the reference (to 7.23)...   :-[
This is how I see it now...

6.5.2 basically says the standard is self inconsistent (basically becuase they haven't updated all the diagrams to be 2.1 conformant).

Figure 7.23 is a normative statement describing what the UML 2.1 notation should be....

Consequently, EA IS conformant to UML 2.1.

As a consequence, if the original diagram (posted by SF_lt) were drawn by EA 6.5(799.) with Direction: set to Bi-Directional, there should be arrows at both ends with the shared aggregation diamond at the Package end.

This would be UML 2.1 conformant.

Is it now a case of... "by George he's got it!"?


Uml Process / Re: Navigability
« on: November 02, 2006, 03:40:29 pm »
OK Simon,

Now we're all agreed...  ;D  What's the outcome?  Is EA currently non-conformant for Associations?  (Bi-directional gives 2 arrows instead of none)

BTW: I don;t think that dictum apples to edges other than Associations.  Thus Bi-directional Dependencies should still have arrows at both ends...

My AU$0.05


Uml Process / Re: Navigability
« on: November 02, 2006, 11:11:57 am »
I agree with Paolo, that provided example is non-conformant with the UML 2.1.

On page 24, figure 7.5 of UML Superstructure is also non-conformant if strictly to follow their's own (OMG) conventions. For example, in figure 7.7 conformant and non-conformant links are used  ;)
You could add Figures 7.6 and 7.8...

See my tag line...  ;)

Uml Process / Re: Navigability
« on: November 02, 2006, 06:09:19 am »
As I read the [size=13]UML 2.1 Superstructure (interim)[/size] Specification (6.5.2 Diagram format), this is now a non conforming representation.

That is to say that since both ends are named it is, prima facie, navigable in both directions.  

If the Association is navigable in both directions, then under UML 2.1 there should be NO arrows.

The diagram is therefore non-conformant.

In addition, since setting the EA association to be bi-directional will cause EA to draw arrows at both ends, EA is therefore (currently) non-conformant.


Uml Process / Re: implicit primary key?
« on: November 02, 2006, 05:51:39 pm »

I think you are describing what is more commonly called a Surrogate Key:

"Sometimes, it is useful to allocate a special column to use as the primary key of a table.  We can enforce a high degree of stability by ensuring that no external (or domain) column is used as any part of the key.  The special column “takes the place of” the other columns that would normally constitute a candidate key in the external domain.  In other words, this key is a surrogate for the external candidate, hence: surrogate key."

I would model the column, make it a PK and then add the additional stereotype (which you can now do with 6.5) of «surrogate».


Uml Process / Re: navigability and OCL
« on: November 02, 2006, 05:46:16 am »
If you give us a reference in the UML specification, we'll have another go at answering your question...


Uml Process / DB relationships vs UML Associations
« on: October 19, 2006, 01:30:53 am »
EA handles Data Modelling using a Rational/IBM de facto standard. There is an RFP which has now closed for an OMG specification: [size=13]ab/05-12-02 (Information Management Metamodel (IMM) RFP)[/size]. The EA approach is documented in: [size=13]Database Modeling in UML[/size].

Apart from some bugs - which are just defects in implementation not conceptual problems - the way in which EA has implemented Data Modelling is adequate. An example of such a bug can be found at: [size=13]Bug: DB Relationship Roles[/size]

However, there are some consequences of this implementation that may not be obvious to the casual observer (Me... :D).

Normally, in UML we have the concept that "a named navigable AssociationEnd is an Attribute" [size=10](my emphasis)[/size]. As I point out in: [size=13]BUG: Attribute/AssociationEnd NOT paired[/size], this means that the Target Roles are (the names of) the Source Class' Attributes... (and vice versa...)

However, in EA if the class is stereotyped as «table», this isn't the case.  If the table is the target, for the target role you get a list of the target's unique indexes (including the primary key) only. (Actually you get the names of the appropriately stereotyped operations). If the table is the source, for the source role you should only get the source's defined foreign key constraints.

Now this is as it should be - as per generally accepted data modelling practice. But it isn't standard UML. So be careful!

(Try adding/removing the «table» stereotype and observe the changes in EA's behaviour. Again, I stress this is as it should be - but needs some getting used to...)

As a safeguard, I recommend that you explicitly use one of the two available Data Modelling notations (IDEF1X or Information Engineering) for the inter-table relationships. This can be done via the Diagram Properties dialog. This will alert the user that the behaviour of the Roles will be different!

However, as I point out in: [size=13]Mixed connector notation on diagrams[/size] we will increasingly be mixing association types on the same diagram and will need to be able to alert the user as to the different behaviours by individually assigning the rendering.

[size=0]©2006 Paolo Cantoni, -Semantica-[/size]

Uml Process / Re: Structured Activity Nodes
« on: October 18, 2006, 11:38:13 pm »
Hi Paolo,
probably I'm on a totally different boat. To me both represent shadows (in Platon's sense) on the wall stemming from the same "algorithm". But probably I'm completely wrong here. No need for discussion  ;)
OK  Thomas...  But I, at least, would appreciate someone confirming I haven't "got hold of the wrong end of the stick"...


Uml Process / Re: Structured Activity Nodes
« on: October 18, 2006, 01:30:37 am »
A bit off-topic, but what is the advantage of a diagram like Figure 10 over the code in Figure 9? Except maybe it takes 10 times more time to understand Figure 10 than 9 and probably 100 times longer to create the drawing.

It's not a question of advantage.  The two figures are doing completely different jobs.  If anything, Figure 9 is the outcome of the repository traversal in Figure 10.  Figure 10 is there to tell Sparx how their internal representation of the concepts in Figure 9 is to be set up (at least on a conceptual or API level).


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