Dear Geoffrey...

[Paolo F Cantoni]

Dear Geoffrey (Sparks),

Stop what you are doing!  "Go directly to Jail!  Do not pass GO...  Do not collect $200".

For six years I've been using this product and I should NOT be amazed any more at the self-inconsistencies I find within it...   However,  related to: 847: Unable to display stereotype for Realization. I find that if I create a "Realization" arc, I get a "Realisation" row in the t_connector table.  

If, however, I use the <Connector Context menu>|Advanced>|Change type... menu item, and select "Realization", I get a "Realization" in the t_connector table!

It's too late to stop build 849, but PLEASE PLEASE PLEASE don't let 850 go out without finally deciding if you are creating Realizations or Realisations and then fixing EA so that it is consistent!

It's better to be consistently wrong than inconsistently wrong!

Fellow users, please indicate your support for at least this MINIMAL amount of self consistency!  Add your votes below...

So VERY frustrated...
Paolo

[Paolo F Cantoni]

I've received a reply from Sparx:
"We are addressing these issues."

However, no ETA.  Nor any indication of which way they are going: "Realization" vs "Realisation".

In the meantime, I'm running queries to standardize on "Realisation".  I DO hope that if they change to "Realization" they'll provide a refactoring process...

Paolo

[Geert Bellekens]

In the meantime, I'm running queries to standardize on "Realisation".  I DO hope that if they change to "Realization" they'll provide a refactoring process...

Paolo, not to discourage you, but the UML specs only mention "Realization", so I suggest to standardize on that.
If I have followed it correctly I think EA used to use "Realisation" all over, and they then realised [pun intented] that they had the wrong spelling, and started to change the spelling of the realization. But of course they changed it in most places, but not all.
(how hard can it be; search and replace "Realisation" with "Realization" :-?)

Geert

[Paolo F Cantoni]

Paolo, not to discourage you, but the UML specs only mention "Realization", so I suggest to standardise on that.
Geert

Yes Geert, I DO know UML has standardised on "Realization"  

but... given a choice between being "pure" and having a partially functioning modelling tool, I've chosen the expedient route.

When Sparx finally fix this problem, they, not me should provide a refactoring tool.  Still, there's always that much maligned and misunderstood tool Microsoft Access which has a Search and Replace within columns....

Paolo

[Geert Bellekens]

but... given a choice between being "pure" and having a partially functioning modelling tool, I've chosen the expedient route.

Ah, I thought since EA uses both spellings it actually worked with both "Realisation" and "Realization", but then again, maybe I'm expecting too much  

Geert

PS:expedient: a means to an end; not necessarily a principled or ethical one
-- I'm learning every day

[«Midnight»]

This one is particularly rich...

Paolo: I agree strongly with Geert. Here in the Frozen North we have to live with the fact that UML does not translate directly into our local language. But at least we can reset our spell checkers and make the best of it.

Geert: I agree (equally) strongly with Paolo. We need some way to get or keep EA working in some (any) consistent manner. The important thing is to adopt any consistent paradigm and strongly urge Sparx to do so as well.

What really scares me is the possibility that this continues to be a low priority (i.e. the correction has no ETA) for a while. Other priorities will overshadow this correction for a few builds; over time it will likely be lost in the clutter and dropped from the list. [This is the voice of experience speaking.] Over time enough legacy models will (arguably) be built 'out here' that changing (i.e. correcting) this functionality (i.e. flaw) will somehow be seen as worse than leaving it in.

For an example of the end result take a look at the seemingly permanent schizophrenia in how aggregations are handled.

IMHO (and this is only an opinion) I'd go with the "z" option. At least the corrections to my spell checkers will be consistent.

David

[Paolo F Cantoni]

Thanks for your input guys...

The problem, though, is NOT inherently a spelling issue...  It's a data and system integrity issue!  Two different parts of the system which purportedly are generating the same conceptual outcome - DON'T!

The user HAS A RIGHT to expect that a UML Realization will be consistently specified within the t_connector table!  Generalization doesn't seem to suffer this problem - or maybe we just haven't dug deep enough...  

One of EA's saving graces is it is database based.  Simple database testing would have revealed an INVALID value being injected by the inconsistent functionality.

Paolo

[«Midnight»]

I completely agree!

[bonzo5]

As I recall from another topic, http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1247237010, that EA does not enforce unique names for actors, most of you wanted to play fast and loose with UML, doing whatever you wanted to do.  In fact, most of you wanted to use EA as nothing more that a glorified Powerpoint palette, rather than as a serious systems engineering tool.  Paulo and Midnight were the only voices that wanted to allow the engineer to strictly enforce UML 2.1 rules, perhaps allowing to toggle it off for the gamers, so they could play at UML.  Great call, Paulo--any tool such as EA should enforce consistency, because complex projects quickly overwhelm anyone's ability to keep it all in their own minds.  EA must help to manage this complexity, but require that UML rules and SE rules be followed, in order to assure high fidelity and high pedigree in the completed model.

[Paolo F Cantoni]

Hi Bonzo,

I want to be REALLY CLEAR here... You correctly say "allow" the user to strictly enforce UML rules.  That's because for a tool like EA, enforcement of UML rules should only be optional for (at least) two reasons:

• UML (very) occasionally gets things wrong and you need to be able to create the models you need.
  
• You may not be modelling in UML at all...

Thus selective enforcement of UML (and rules from other modelling technologies/methodologies) on a rule by rule basis would be cool.  I see (I think) that EA is heading in that direction.
The application of self-consistency rules, is a more complicated matter.  Notionally, you shouldn't be allowed to break them (they are like laws of physics).  However, in my experience, you do sometimes want to suspend even these rules (on a temporary basis) to be able to collect information and then use the "facts" as provided to sort out what is really going on.  The problem with EA is that it doesn't enforce many of these self-consistency rules and therefore you can't even turn them on if you want to.

You are absolutely right with regard to complexity of projects and being overwhelmed!  Modelling is a Risk Mitigation strategy - so long as the modelling tool doesn't inject additonal risk.

Paolo

[Paolo F Cantoni]

Just in case the Sparxians don't spot it in their review...

The Add>Related Elements... dialog looks for Realizations (not Realisations).  So my expedient solution - to standardise on Realisations - which keeps most of EA working for me, shafts me when I try to add Realization (only) links to a diagram.

This is, OF COURSE, the problem with choosing expedient solutions and which I argue against - if there is a choice.  Here, there isn't...

Paolo

My tag line:
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
 (which I first developed over 25 years ago) says it all...

[son-of-sargasso]

(Gee its great to see that some things never change  )





OOOOPS! I meant "Gee it's great.."

b

[Paolo F Cantoni]

Just in case the Sparxians don't spot it in their review...

The Add>Related Elements... dialog looks for Realizations (not Realisations).  So my expedient solution - to standardise on Realisations - which keeps most of EA working for me, shafts me when I try to add Realization (only) links to a diagram.

I noted with a LOT of interest the item:

• Ensured consistent handling of Realization connectors.

In the release notes for build 849.

I observe that DIDN'T extend to being able to pick them up via the Add Related Elements dialog (as I mentioned in the quote).

I've asked if it will be fixed in 850.

At least prior to 849, you could create "Realizations" as opposed to "Realisations" by taking the route of: Create a non-Realization, change it to a Realization so that they could be picked up in the Add Related Elements.   Now they just disappear down a black hole...

Paolo

[Eve]

I observe that DIDN'T extend to being able to pick them up via the Add Related Elements dialog (as I mentioned in the quote).

That's because it's an unrelated issue and selecting ANY connector type currently doesn't work in that dialog.  There is a fix in the works, but it in no way relates to realization vs. realisation.

[Paolo F Cantoni]

I observe that DIDN'T extend to being able to pick them up via the Add Related Elements dialog (as I mentioned in the quote).

That's because it's an unrelated issue and selecting ANY connector type currently doesn't work in that dialog.  There is a fix in the works, but it in no way relates to realization vs. realisation.

Thanks for that Simon.  I hadn't tested it far enough...  

We await the fix - since (for me, at least) it's becoming quite important to be able to select by Relationship type.  

Now you're working in that area, if I pop in a feature request for filtering by stereotype - might that be looked at?  At least considered as a long-term future feature?

Paolo