Duplicate Type Definitions

[Matt Edwards]

Is it possible to globally require that all types in a given package be uniquely named, or if not, a tool that will locate and list all duplicate class definitions and facilitate some kind of merge?

In a similar vein, when reverse engineering classes by namespace for example, if a source file changes its location on disk, sometimes a new class is created where it should instead synchronize the existing class.

[KP]

You can find duplicates with a custom SQL search. Something like this:

Code: [Select]

SELECT FirstObject.Name, FirstObject.Object_ID, FirstObject.Object_Type
FROM t_object AS FirstObject, t_object AS SecondObject
WHERE FirstObject.Name = SecondObject.Name
AND FirstObject.Object_Type = SecondObject.Object_Type
AND FirstObject.Object_ID <> SecondObject.Object_ID
AND FirstObject.Package_ID = SecondObject.Package_ID
ORDER BY FirstObject.Name
(To create a custom search, Ctrl+F and press "Manage Searches"...)

[Matt Edwards]

Will that be improved in a future release? We'd prefer to enforce unique names across the board.

[Aaron B]

Matt,

You might also consider writing your own custom Model Validation rules to check for duplicate element names within each package.  Model Validation is extended via Add-In.  There is no existing Add-In available to perform this validation that I am aware of.  Information on how to extend model validation can be found in the help file under the SDK chapter.
http://www.sparxsystems.com/uml_tool_guide/sdk_for_enterprise_architect/validation.html

You could also add validation to check the filename associated with each class to make sure the file exists and raise a warning if the file is not found.

[Matt Edwards]

We have multiple developers involved in our round-trip engineering process, and we would prefer the location of these classes not to factor into the import/synchronization process, as anyone might at anytime want to sync from their local workspace. Is that possible?

[«Midnight»]

Hi Matt,

Although the examples in the EA documentation are mostly absolute paths, local paths work (fairly) well in relative hierarchies.

They seem to be stored with the model. In a shared project you will need to ensure that everyone uses the same directory structure.

I don't know how much information there is on the Sparx site, but there has been discussion of this here in the forum from time to time. Some of the threads describe potential pitfalls and limitations; it might save you some time if you are aware of these ahead of time.

I don't remember any lengthy discussions in the recent past - I could have missed something though - so be prepared to go back quite a while if you search the forum.

HTH, David

[Matt Edwards]

I'd like to completely decouple the file path from any target model artifacts that may have the same fully-qualified name, so that importing a type does not result in the creation of a duplicate artifact. It sounds like I need to develop a custom add in to address this. Is that correct?

[«Midnight»]

Without knowing the specifics of your situation... Yes, that sounds correct. I believe the path for each element (of an appropriate type) is stored as an element property. You should also review the properties of the parent package in case any settings are inherited by child elements.

[Matt Edwards]

I don't believe there are any nuances to this, at least there shouldn't be. Inside any given source file, there may live a class.  We want EA to recognize this class, ignoring the name of the file in which it was found, and synchronize it if it already exists under the current root package.

I can see how this might complicate round-tripping changes back into the file, but if forced to choose between reconciling source code files and hunting for and merging duplicate types in the model, well, there are hundreds of tools to facilitate transforming source code files, and NONE to facilitate cleaning up an EA model.

[«Midnight»]

The utility of something like this is fairly obvious. Consider for example the case of a 'code file' that contains several class definitions. You might find this kind of thing in older programming languages, or in some .Net solutions, to cite just a couple of cases.

Even so, you are left with the problem of figuring out where you originally found the code, then tracking down the current location of that file at synchronization time.

The bottom line is that you will have to write an add-in. However you approach this, your program has to cover each end user's configuration. The path to the code files could be different for each user, and might change between iterations (a user might download a new code tree and synchronize with that).

You might want to do a walkthrough of how this might interact with version control (of EA) to see if this could raise issues.

Of course, all my musings don't get you any closer to a solution. Sorry about that.

David

PS: What my musings do show is that this problem is not easily contained. That alone might explain why EA does not (perhaps cannot) deal with this issue. Perhaps some detailed analysis (under separate cover) might provide something specific for a feature request or two.