EA Does Not Enforce Unique Names for Actors

[bonzo5]

I imported some model data into EA and was disappointed to see that EA allowed multiple actors to all have the same name, rather than enforcing the rigor of unique names for each actor.  It is always desirable for a modeling tool to enforce rigor, such as systems engineering schema or UML, and not to allow the user to do whatever he wants to.

[KP]

Check out this thread: http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1217968453

[Geert Bellekens]

I do not agree.
I don't want my modelling tool to enforce such rules upon me. If having uniquely named actors is a modelling rule in my method then I will enforce that myself, as with all other moddeling rules.

Geert

[bonzo5]

EA's failure to enforce UML 2 means that it is not fully UML 2-compliant.  If some users want to play fast and loose, naming every object with the same name, then they should be using Visio or Powerpoint.  Perhaps Sparx could add a toggle that would explicitly enforce UML 2, SysML, etc. for the users that have complex models and desire to comply with OMG.

[Geert Bellekens]

I haven't seen anything in the UML 2 specs requiring unique naming for actors (or other elements) within a model.
The only unique constraint on names I found was that the EnumerationLiteral's name has to be unique whithin its Enumeration.
Could you please show me where you found this requirement?


Geert

[Frank Horn]

I agree with Geert in that EA should stay as flexible as it is and not enforce things which may not be needed in all circumstances.  There's more to EA than UML, after all.

An option to enforce unique names (per project, per model, per package) would be allright though, I've been missing this myself at times.

[KP]

I haven't seen anything in the UML 2 specs requiring unique naming for actors (or other elements) within a model.
The only unique constraint on names I found was that the EnumerationLiteral's name has to be unique whithin its Enumeration.
Could you please show me where you found this requirement?


Geert

NamedElements must be "distinguishable" within a namespace, i.e. have different names or different types. UML 2.2 Superstructure, section 7.3.33 if you want to read it for yourself.

Regarding whether EA should enforce this or not, my personal opinion is not if it interrupts my workflow, but it should probably be checked in the model validation, i.e. check it after you've created your model, not during. The thread I pointed to higher up this page gives instructions on how to do this...

[Paolo F Cantoni]

NamedElements must be "distinguishable" within a namespace, i.e. have different names or different types. UML 2.2 Superstructure, section 7.3.33 if you want to read it for yourself.

Regarding whether EA should enforce this or not, my personal opinion is not if it interrupts my workflow, but it should probably be checked in the model validation, i.e. check it after you've created your model, not during. The thread I pointed to higher up this page gives instructions on how to do this...

Neil, I agree in principle with your comment, but I'd like to add the ability (optional) to check in real time  as I create a new vertex or arcs.  I mean , if I'm using a name that already exists in the namespace then I really want to know if someone else has already defined this "thing".  Otherwise I create arcs to all sorts of stuff and then when the validation (finally) tells me I've got a potential duplicate I've got to refactor (potentially a lot of) stuff.  That can severely "interrupt my workflow".

Paolo

[Geert Bellekens]

NamedElements must be "distinguishable" within a namespace, i.e. have different names or different types. UML 2.2 Superstructure, section 7.3.33 if you want to read it for yourself.

Thanks for the answer. I didn't know that.
So in any case, this "unique naming" feature should only work on "NamedElements" within a namespace, not across the whole model.
And I guess it could become one of the constraints checked when the "Strict UML" syntax option is selected.

[«Midnight»]

NamedElements must be "distinguishable" within a namespace, i.e. have different names or different types. UML 2.2 Superstructure, section 7.3.33 if you want to read it for yourself.

Regarding whether EA should enforce this or not, my personal opinion is not if it interrupts my workflow, but it should probably be checked in the model validation, i.e. check it after you've created your model, not during. The thread I pointed to higher up this page gives instructions on how to do this...

Neil, I agree in principle with your comment, but I'd like to add the ability (optional) to check in real time  as I create a new vertex or arcs.  I mean , if I'm using a name that already exists in the namespace then I really want to know if someone else has already defined this "thing".  Otherwise I create arcs to all sorts of stuff and then when the validation (finally) tells me I've got a potential duplicate I've got to refactor (potentially a lot of) stuff.  That can severely "interrupt my workflow".

Paolo

Neil, Paolo (et al),

Perhaps this could be handled by adding a rule.

That said, perhaps EA could allow us to specify several additional 'default' rules that would always be run when (various forms of) validation were performed. This would include when 'strict' UML syntax was checked by EA (if that option were turned on).

And of course the same technique would also apply to MDG Technologies. They would be able to specify additional default rules to be run when a diagram (package, or whatever) was stereotyped within the scope of the technology.

Just tossing in another 0.02 CAD, for whatever fluctuating value it might have.

David

[bonzo5]

Thanks, all for your helpful comments.  Not to further ruffle feathers, I also believe that activity diagram swimlanes should also correspond to the actors whose activities they represent.  In short, the swimlane should not exist as a different name from an actor--it should be the congruent.  A swimlane without a corresponding same name actor is not valid--I should be able to toggle between the two views, since they are the same.  The issue is that EA swimlanes are nothing more than background, window-dressing, or wallpaper and do not properly enforce the concept that they are congruent to the actor.

[Geert Bellekens]

I'm sorry, but again I have to object.
In UML the swimlane you described is defined as an ActivityPartition.
If we look at this definition then you can see that an ActivityPartition represents an Element.
EA allows us to link a classifier to a swimlane, which is already more limited then the UML specification.
Elements are one of the most general UML types, almost anything in UML is an Element (including actors), so constraining the swimlanes to only be able to represent an actor would not be UML compliant.
You should remember that UML is only a language, and not a methodology. UML is used in many different ways, and EA should be able to support all that.
I can see however where you are coming from, and in the methodology we use we also link swimlanes only to actors. But there are many other uses possible.

PS. Be aware that there are two kinds of swimlanes in EA.
There is the "ActivityPartition" that can be found in the Activity Diagram Toolbox, and there is the "swimlane" that can be created when right clicking on a diagram and choosing "Swimlanes and Matrix..."
Both concepts allow to connect a classifier (including actors) but I believe the first concept is the UML ActivityPartition where the latter is just an EA diagram feature.

Geert