Class Name uniqueness

[barbuckle]

I notice that enterprise architect allows multiple classes to have the same name within the same package.
Is there a way to enforce uniqueness i.e. raise an error if the modeller tries to add a class to a package when a class with the same name already exists?

[Eve]

Only by creating an addin.

There is an event broadcasted to the addins before and after every element is created.  You would need to catch EA_OnPostNewElement because until that point the name is not known.

Simon

[barbuckle]

Thanks for this.
Can you provide such an add-in?

Note that this is INVALID UML since classifiers must have unique names within packages.

Also - if you generate an XSD from such a model it is equally invalid.

[sargasso]

Note that this is INVALID UML since classifiers must have unique names within packages.

Ref please?  I dont recall this.

bruce

[KP]

Bruce,

Section 7.3.2 Kernel::NamedElement, Additional Operations [2] The query isDistinguishableFrom()...

By default, two named elements are distinguishable if (a) they have unrelated types or (b) they have related types but different
names.

And then, section 7.3.3 Kernel::Namespace, Constraints [1]...

All the members of a Namespace are distinguishable within it.

Neil

[Paolo F Cantoni]

Bruce,

Section 7.3.2 Kernel::NamedElement, Additional Operations [2] The query isDistinguishableFrom()...

And then, section 7.3.3 Kernel::Namespace, Constraints [1]...

Neil

Neil,
(I sort of couldn't resist...) In that case, why doesn't EA enforce the requirement?

I guess, which ever way you look at it is IS an implied criticism of EA.  But I'm truly posing the question...  It's not rhetorical.  I'm trying to get an insight into EA and its development process.

Paolo

[sargasso]

From 7.3.2 a) class "Fred" is a different element to object "Fred" - fine and simple.

From 7.3.2 b) class "Fred" is different to class "Jane", and class "Fred" is the same entity as another class element in the namespace called "Fred".

From 7.3.3 all class "Fred"s in the namespace are instances of the same member.  (N.B. not instantiations).

None of this says to me that you cannot have more than one class of the same name in a model.  All it says is that every one of the classes with the same name is the same thing.

This may sound obtuse but my reasoning is this - and I have been through it with others who agree :

1) In many modelling situations, you may wish to include depicitions of an element at various stages in its development life.  For example, class Fred <<Ver 1.0>> and class Fred <<Ver1.2>>

2) In component and deployment models, you may well have mutiple instances of the same classifier appearing.  For example, IPstack appearing on nodes A & B as classifiers not instantiations.  (Paolo, please dont bite - its an example)

3) and,... because I say so  

The UML 2.0 itself recognises the need for multiple instances of the same element appearing in a model as evidenced by their use of "duplicate" markers in the meta-models.  (But in true autocratic fashion they didn't implement that in the spec).  However, this is a slightly different thing.

Consider a complex model containing classes with attributes that have associations to a type "int",  now I want to include my class int in the model.  If I am limited to  only being allowed one class called "int" in the model I will have associations links that look like the wiring diagram for the Queen Mary.  Much simpler to allow mulitple "ints" and realise that they are all the same thing (even if their representation differs! stereotypes and other adornments)

Finally, IMO the diagram is the model is the diagram - it must be UML compliant.  The EA Project view is not the model, it is part of the tools we use to create compliant models.  Ergo - leave my multiple ints alone please.

bruce

[Paolo F Cantoni]

Warning! Warning! Will Robinson... There is a Paolo approaching!

(A)From 7.3.2 a) class "Fred" is a different element to object "Fred" - fine and simple.

(B)From 7.3.2 b) class "Fred" is different to class "Jane", and class "Fred" is the same thing as another class element in the same namespace, called "Fred".

(C)From 7.3.3 all class "Fred"s in the namespace are instances of the same member (thing?).  (N.B. not instantiations).

(D)None of this says to me that you cannot have more than one class of the same name in a model.  All it says is that every one of the classes with the same name is the same thing.

This may sound obtuse but my reasoning is this - and I have been through it with others who agree :

(E)1) In many modelling situations, you may wish to include depictions of an element at various stages in its development life.  For example, class Fred <<Ver 1.0>> and class Fred <<Ver1.2>>

(F)2) In component and deployment models, you may well have multiple instances of the same classifier appearing.  For example, IPstack appearing on nodes A & B as classifiers not instantiations.  (Paolo, please don't bite - its an example)

(G)3) and,... because I say so  

(H)The UML 2.0 itself recognises the need for multiple instances of the same element appearing in a model as evidenced by their use of "duplicate" markers in the meta-models.  (But in true autocratic fashion they didn't implement that in the spec).  However, this is a slightly different thing.

(I)Consider a complex model containing classes with attributes that have associations to a type "int",  now I want to include my class int in the model.  If I am limited to  only being allowed one class called "int" in the model I will have associations links that look like the wiring diagram for the Queen Mary.  Much simpler to allow multiple "ints" and realise that they are all the same thing (even if their representation differs! stereotypes and other adornments)

(J)Finally, IMO the diagram is the model is the diagram - it must be UML compliant.  The EA Project view is not the model, it is part of the tools we use to create compliant models.  Ergo - leave my multiple ints alone please.

bruce

Bruce,  to quote you back... "Here be dragons!"

(A)Agreed

(B)Agreed, but note change of words and addition of comma (if that's not what you intended then blame me)!

(C)Note additional word.  (Again, if that's not what you intended then blame me)!
Instantiation: a representation of an idea in the form of an instance of it.  (I didn't write the definition!).
Does this make the statement self inconsistent?

(D)Model or Namespace?  Barbuckle's original point was within the same namespace (package at a level)

(E)Yes, it would be nice to do this, but unfortunately it isn't possible directly in the way you suggest.  In database terms, the evolution of an object is handled by a pattern I call "State Episode".  The object was in this state during this period.  It requires a minimum of two tables to implement.  The model at anyone time is a "now" model.  It can only represent any ONE thing as it is at the time.  If I need to link to "Fred" - which of the two Fred's do I link to (using automation)?  And there are two Freds - If I make changes to one they aren't reflected in the other!

(F)I didn't bite...  It may be an example... But is it an exemplar?

(G)...Astonishing conceit! (Evil_Genius passim)

(H)Yes, they "piked" out on that one.  But I thought they were talking about the different renditions.  (Similar to Rational Rose's (or Embarcadero ER Studio's) differentiation of the item in the diagram and the item itself...)  Perhaps I was wrong...

(I)Yes, it should look like the wiring diagram of the Queen Mary - for that's what you've got.  What you need is the ability to selectively display on each diagram those associations pertinent to that diagram.  UML 2 - with the ability to generalize associations gives you that.

(J)The diagrams are the model (well actually they aren't since you can't represent everything graphically) - but the point is there are multiple diagrams each one showing what you need.  No-one every displays the canonical diagram for any real model.  It's too complicated.

If I change one "instance" of X and it changes all the other instances - then I have one X if not, I have many Xs.

Paolo

[sargasso]

Paolo,

You edits are correct and I concur with your agreements.
Re your D - yes I appreciate that - my point is that (IMO) the tool is not a namespace manager.
Re your F - no its not exemplar hence the request.
Re K - (which was my main point and remember this is IMO) ---->

A screwdriver and a spanner may be SAE compliant.  However, if the workman uses the screwdriver as a cold chisel and the spanner as a hammer, it is not the fault of the tool.  Indeed I have, in my life, (ab)used instances of these implements in such a manner.  At the times it happened, quite frankly, I needed to.

I am always wary of suggestions that EA be tightened up to.... Wait for it.... force the user into UML compliant behaviour.  Many real world uses of UML require some degree of laxity.  One of EA's best features is that it supports "bending the UML laws of nature".

The time for model compliance is at the end of the modelling, not during the exploratory and problem solving activities that in my experience comprise the majority of the EA user sessions.  By way of metaphor, one would not expect an equivalent building architect's modelling tool to constrain him to only produce engineering standard diagrams.  He could then only use the tool to produce the final drawings - not the multiplicity of drafts and working drawings that came before.

I fully support the idea of having a FUNCTION within EA that can be invoked by the user that checks the model's compliance level, but reject the idea that we have a RULE within EA that PREVENTS the creation of non-compliant models.

Finally, re "If I change one "instance" of X and it changes all the other instances - then I have one X if not, I have many Xs. "
What I am saying is (possibly climbing on a large wet stepladder carrying a running chainsaw and two civet cats here) that you may very well have one instance of X. However the models you build can contain more than one abstraction of that instance.

IMO IMO IMO
IMO IMO IMO
It’s all IMO
(Ancient anti-dragon chant)

bruce

[Paolo F Cantoni]

Paolo,

(A)You edits are correct and I concur with your agreements.
(B)Re your D - yes I appreciate that - my point is that (IMO) the tool is not a namespace manager.
Re your F - no its not exemplar hence the request.
Re K - (which was my main point and remember this is IMO) ---->

(C)A screwdriver and a spanner may be SAE compliant.  However, if the workman uses the screwdriver as a cold chisel and the spanner as a hammer, it is not the fault of the tool.  Indeed I have, in my life, (ab)used instances of these implements in such a manner.  At the times it happened, quite frankly, I needed to.

(D)I am always wary of suggestions that EA be tightened up to.... Wait for it.... force the user into UML compliant behaviour.  Many real world uses of UML require some degree of laxity.  One of EA's best features is that it supports "bending the UML laws of nature".

(E)The time for model compliance is at the end of the modelling, not during the exploratory and problem solving activities that in my experience comprise the majority of the EA user sessions.  By way of metaphor, one would not expect an equivalent building architect's modelling tool to constrain him to only produce engineering standard diagrams.  He could then only use the tool to produce the final drawings - not the multiplicity of drafts and working drawings that came before.

(F)I fully support the idea of having a FUNCTION within EA that can be invoked by the user that checks the model's compliance level, but reject the idea that we have a RULE within EA that PREVENTS the creation of non-compliant models.

(G)Finally, re "If I change one "instance" of X and it changes all the other instances - then I have one X if not, I have many Xs. "
What I am saying is (possibly climbing on a large wet stepladder carrying a running chainsaw and two civet cats here) that you may very well have one instance of X. However the models you build can contain more than one abstraction of that instance.

(H)IMO IMO IMO
IMO IMO IMO
It’s all IMO
(Ancient anti-dragon chant)

bruce

(A)Thanks...

(B)Unfortunately or otherwise, I think it is forced to be...  Rational Rose handles the "multiple elements with the same name in the same namespace" problem by warning you you are doing it, but lets you override.  I think that's the minimum EA should do.

Interestingly, If you do an XMI export from Rose of a model with the same name for more than one element in the same namespace, you get an error message saying the output XMI will be unusable;  and, indeed, neither Rose nor EA will re-import that XMI file - because of the duplicate name...  Even though both allow duplicate names in the browsers!  There's NO substitute for consistency!

(C)I agree... so long as we can achieve the outcome we desire with the tool - then go for it... but see (B)

(D+E+F)On this I can absolutely agree!  Modellers need the flexibility to "break the rules" when required (certainly while we get our thoughts in order).  As the model "stabilises" we should be able to determine the degree of compliance (by running your checker process).  In my experience it is the clarity of thought brought about by the disciplines of UML that help produce the "correct" model.  (See my signature... )  BTW the checker process could be set to run continuously - for newbies to get them used to the graphical syntax, then relaxed as they get more experience.

(G)Not sure exactly what you mean here.  If you agree with the foregoing, then your example of Fred (in two different versions) is actually two Freds - since it's not possible to conceptualise the two as one in a UML model (especially if their structure or operations have evolved).  Can you give a concrete example?

(H)I'm repeating the same mantra...

Paolo

[barbuckle]

Yes well fascinating discussion guys but all I need to know (as a prospective customer) is when can I expect this to be "fixed" in ea?
A "name exists" warning would suffice if you are against enforcing UML semantics. Note that packages are organisational elements in the model so this is really quite important for any non-trivial model.

From OMG UML Spec 1.5 section 2.5.2.28
"The name of each owned ModelElement must be unique within the Namespace"
and Package is a subclass of Namespace - unchanged in UML 2.0.

UML 2.0 Superstruc Spec section 3.22.1:
"The name of a class has scope within the package in which it is declared and the name must be unique (among class names) within its package."

[Paolo F Cantoni]

Yes well fascinating discussion guys but all I need to know (as a prospective customer) is when can I expect this to be "fixed" in ea?
A "name exists" warning would suffice if you are against enforcing UML semantics. Note that packages are organisational elements in the model so this is really quite important for any non-trivial model.

From OMG UML Spec 1.5 section 2.5.2.28
"The name of each owned ModelElement must be unique within the Namespace"
and Package is a subclass of Namespace - unchanged in UML 2.0.

UML 2.0 Superstruc Spec section 3.22.1:
"The name of a class has scope within the package in which it is declared and the name must be unique (among class names) within its package."

Barbuckle,

put in a bug request direct, referring Sparx to this discussion topic, if you like.  You need to make it formal to ensure Sparx, process it.  The forum is only informal.

Paolo

[sargasso]

B) Only one further push - I dont want a spanner that beeps every time I try to use it as a hammer unless I turn that feature on.

G) I know what I mean here, but I'm having trouble expressing it, probably the same trouble I have with reading the UML metamodels.  Its essentially a philosophical comment.  Class "Fred" is an object (thing) that exists in the world.  In fact, if it is implemented on many PC's there are many Fred's.  In fact, even if its only on one PC there are probably at least two Fred's - the source code and the runable code.  Backing even further out, there are possibly (probably) another set of Fred's in the EA model used to design it.  Depending on your (the observer's) point of view, only one of these Fred's is the real Fred, the others are all abstractions.  If you are the executing O/S the only Fred that's real is the runable code, all others are abstractions of little or no importance.  If you  are a coder the real Fred is the source code file open in your editor, the runable is an artifact produced through voluntary acts controlled by you.  Etc etc.  IMO the UML is supposed to be able to represent all these real Fred's. But, I dont beleive that changing one of those Fred's in a model  ,( say to make a defect more consistent   )can change all the Fred's in the world.  

I appreciate what you and Barbuckle are saying.  I just disagree its a desireable goal for the tool.  

yet again IMO IMO....

bruce

[Paolo F Cantoni]

B) Only one further push - I don't want a spanner that beeps every time I try to use it as a hammer unless I turn that feature on.

I think what we need here is an extension of the Rose approach (which just allows you to turn off checking for the session).

[On a per-model basis, in the Options area]
Duplicate Name Checking (for those elements where UML requires name uniqueness)
(*) Always enforce name uniqueness
(o) Check with me each session
(o) Don't enforce name uniqueness

The above radio buttons determine whether the checking dialog comes up when you try to enter a duplicate name. [Symbols: (*) default, (o) possible

The dialog comes up with:
Duplicate name detected in this namespace (xxxxxx)
(*) Allow me to change the name
(o) Allow duplicate name to stand and don't check any more this session
(o) Don't enforce name uniqueness

Selecting the latter also selects the same setting in the options...

How's that?

G) I know what I mean here, but I'm having trouble expressing it, probably the same trouble I have with reading the UML metamodels.  Its essentially a philosophical comment.  Class "Fred" is an object (thing) that exists in the world.  In fact, if it is implemented on many PC's there are many Fred's.  In fact, even if its only on one PC there are probably at least two Fred's - the source code and the runnable code.  Backing even further out, there are possibly (probably) another set of Fred's in the EA model used to design it.  Depending on your (the observer's) point of view, only one of these Fred's is the real Fred, the others are all abstractions.  If you are the executing O/S the only Fred that's real is the runnable code, all others are abstractions of little or no importance.  If you  are a coder the real Fred is the source code file open in your editor, the runnable is an artifact produced through voluntary acts controlled by you.  Etc etc.  IMO the UML is supposed to be able to represent all these real Fred's. But, I don't believe that changing one of those Fred's in a model  ,( say to make a defect more consistent   )can change all the Fred's in the world.  

I appreciate what you and Barbuckle are saying.  I just disagree its a desirable goal for the tool.  

yet again IMO IMO....

bruce

Ah... I'm now getting a better handle on what you're aiming at.  I think, in part, it's related to the Conceptual vs Logical vs Physical model problem.  I was intending to create a new topic on that subject shortly anyway - for other reasons, but this concept is also relevant.  When I get some time, I'll do that.  The problem you describe is a very real problem and I think the new transformation technology may go a long way to alleviating that.  (Hence a different topic).

Paolo

[benc]

Hi Guys,

Lots of good discussion here. This post is almost by way of summary...

In answer Barbuckles specific query : Is there a way to enforce uniqueness in names? Official answer : No - not yet.

More broadly, the missing feature is a "model checking" option - both to allow "live" checking and  model checks/reports based on user request.

As it happens, we're already working on a generic constraints engine that will facilitate precisely the things that have been suggested in this thread - eg. opt-in model checks. This extends beyond basic checking for UML compliance ...

I cannot provide a release date at this stage- there's some rumours about including it in 5.1 though.

Regards
Ben