Classifier Name, GenFile and GUIDS

[Paolo F Cantoni]

This is NOT a rhetorical question...  

We're assembling some enterprise-wide models from various preexisting .EAP models - that were reverse engineered from code at various times and via various structures.

We've encountered situations where we have the same named Classifier, with the same GenFile but with different EA_GUIDs.

This is a violation of the essential EA conceptual model is it not?  I'm not blaming EA here, I'm just asserting the rule below...  NOTE: These classifiers may be in different namespaces - but the question still applies.

One of the domain identifications of a Classifier is the combination of Name and GenFile which should generate a unique combination (and can thus be given a unique GUID).

If we come across these, we need to find some way of merging them do we not?

TIA,
Paolo

[«Midnight»]

I'm not really sure this is the case Paolo.

IMHO...

The GenFile attribute looks like it came along sometime after the overall schema (for lack of a better term) of EA came together. While it might be 'nice' if name and GenFile constituted a unique ID, I don't think this was the absolute intent, nor would it necessarily be enforced.

At the same time I don't see a compelling reason for this not to be the case - we'd have something analogous to a candidate key in a relational table. Perhaps this needs to be explored and brought to Sparx for interpretation or implementation.

In the meantime, unless Sparx immediately jumps in and decides to treat this as a bug (rather than just an oversight in design) I don't think you should be relying on this as a feature in the near term.

David

[Paolo F Cantoni]

I'm not really sure this is the case Paolo.

IMHO...

The GenFile attribute looks like it came along sometime after the overall schema (for lack of a better term) of EA came together. While it might be 'nice' if name and GenFile constituted a unique ID, I don't think this was the absolute intent, nor would it necessarily be enforced.

Dave, I didn't make myself clear enough - the posting was a bit rushed...

I'm not suggesting this is a formal aspect of EA's conceptual model, more a consequence.  I'm certainly not expecting EA to enforce it.  It's just that as we are assembling stuff from "all over the place", we need a strategy to merge different instances of the same element.  But how do we decide it's the same Element?

At the same time I don't see a compelling reason for this not to be the case - we'd have something analogous to a candidate key in a relational table. Perhaps this needs to be explored and brought to Sparx for interpretation or implementation.

Yes, I see the Element Name + GenFile as an alternate key to the Element's primary key (it's GUID).  I'm raising this concept here for Sparx's comment.

In the meantime, unless Sparx immediately jumps in and decides to treat this as a bug (rather than just an oversight in design) I don't think you should be relying on this as a feature in the near term.

David

Since EA already allows more than one Element of the same type with the same Name within the same Namespace (a violation of the UML Specification - in my view).  I'd rather Sparx fixed that first.  However, a comment to the effect that we can conceptually treat two Elements with the same name and same (absolute) GenFile as the same element would be useful for our validation processes.

Paolo

[«Midnight»]

We're in a bit of a bind here Paolo. UML's use of packages differs (somewhat randomly IMHO) from the concept of "namespace" as found in some language specifications.

Take for example those cases where multiple distinct anonymous elements (of the same type) may coexist within the same package. There is also the old (in the sense of "early") context of a package as a way to arbitrarily partition a system. How this is accomplished was left largely to the discretion of vendors, and results range from no handling of multiple (unstereotyped) packages to very formal interpretations.

In any case, all I can suggest is rewording things to avoid the word "namespace" when speaking of UML. This won't solve any problem we have, but it might make it a little easier to get through the day.

Sigh...

[Paolo F Cantoni]

We're in a bit of a bind here Paolo. UML's use of packages differs (somewhat randomly IMHO) from the concept of "namespace" as found in some language specifications.

Take for example those cases where multiple distinct anonymous elements (of the same type) may coexist within the same package. There is also the old (in the sense of "early") context of a package as a way to arbitrarily partition a system. How this is accomplished was left largely to the discretion of vendors, and results range from no handling of multiple (unstereotyped) packages to very formal interpretations.

In any case, all I can suggest is rewording things to avoid the word "namespace" when speaking of UML. This won't solve any problem we have, but it might make it a little easier to get through the day.

Sigh...

Well,  these Elements aren't anonymous - they have real names so...

Your point regarding UML namespaces vs platform specific language namespaces is well taken, but doesn't apply here (in my view).  I'm specifically suggesting that if an absolute location is provided for GenFile and the name is the same, we are literally talking about the same thing...

Let's wait for Sparxians to give their opinion.

Paolo

[«Midnight»]

But...

I'm specifically suggesting that if an absolute location is provided for GenFile and the name is the same...

This could make things problematical if either the name and GenFile change. I gather you are combining them to insulate us from this, as well as to make it less likely that there will be duplicates for either the name or GenFile.

This probably bears some serious thought, as there might be unexpected side effects, depending on how Sparx has implemented and used these (and other) attributes in code.

I'm a bit concerned that this is a read/write attribute, that can refer to a local file. We might want to further explore (the various problems related to) file names and paths before we tackle this. This has come up before, as you well know, and remains an area where there are several 'unknowns' outstanding.

Maybe some kind of URI would be the solution, although this too fans out a bit.

I'll think on this a bit, and we should continue the thread as ideas firm up.

[Eve]

As I have said a few times in the forum in response to questions where it has caused synchronisation not to happen, EA uses the name and filename to determine what class to synchronise with when reverse engineering.

So in general that should be enough (as far as reverse engineering) is concerned for uniqueness.  However, inner classes require the special treatment of also having the parent class match.

If you are able to, it may be worth doing a directory import that includes the file(s) in question with the prompt to remove classes not found.

[Paolo F Cantoni]

As I have said a few times in the forum in response to questions where it has caused synchronisation not to happen, EA uses the name and filename to determine what class to synchronise with when reverse engineering.

So in general that should be enough (as far as reverse engineering) is concerned for uniqueness.  However, inner classes require the special treatment of also having the parent class match.

If you are able to, it may be worth doing a directory import that includes the file(s) in question with the prompt to remove classes not found.

Thanks for that Simon,

If I have two classes with the same name and GenFile location (but perhaps in different hierarchies), will Synchronisation/Reverse Engineering update BOTH classes (if I use import Source Directory).  

I guess if I synchronise a specific class, then only that instance will be synchronised...

Paolo

[Eve]

No, import source directory will only update one class.  It was only designed to have a single class to update.  The actual instance that is synchronised will be undefined if there are more than one, but I'm certain only one will be updated.

I suggested the import directory because this will confirm one they are duplicates because one will be leftover at the end of the import.  But I suspect you wouldn't want it to automatically remove either because of links to/from it that need to be moved to the other class.

[Paolo F Cantoni]

No, import source directory will only update one class.  It was only designed to have a single class to update.  The actual instance that is synchronised will be undefined if there are more than one, but I'm certain only one will be updated.

I suggested the import directory because this will confirm one they are duplicates because one will be leftover at the end of the import.  But I suspect you wouldn't want it to automatically remove either because of links to/from it that need to be moved to the other class.

Dare I suggest that if there is more than one and since the outcome is not deterministic, EA issues a warning that no class will be updated?

Surely this would be safer...

Paolo