Reverse engineered source creates two distinct classes with the same name

[fredb]

This isn't quite the case of duplicate classes being created.  I just imported a large Visual Studio C# solution with multiple projects across two source trees with some inter-dependencies, but not duplicate source.  I am, BTW, impressed that Enterprise Architect did not choke and die.  However, in several places, not a lot, a class or interface was split into two side-by-side entries in the Project Browser with the same name.  However, they do not share attributes or operations or inheritance.  For instance, if an interface extended 5 other interfaces, then one Project Browser entry might show two of the interfaces, and the other 3.  I have even dragged both entries onto a diagram and validated the unique inheritance.  What might have caused this behavior?

I have seen several posts regarding a desire to merge classes and writing an automation script to do it, but it was not recommended as it is quite complicated. This project took 3-4 hours to import.  I don't really want to reimport, as the same thing might happen.  In this latest (13) release, is there an easy way to merge two classes?  Thank you.

Fred

[qwerty]

You can merge classes manually in the following way:

- make a backup
- create a dummy diagram
- drag both classes onto that diagram as link
- for both classes choose Insert Related from the context and place all of them
- perform an auto-layout (if needed/desired)
- drag all connectors from the class to be removed to the other one
- in the project browser drag/merge operations and attributes. Alternatively you can drop them from the redundant one in the browser on the desired on in the diagram, which will actually create identical copies.
- select the redundant one and press Ctrl-U. This reveals in which diagrams it is still in use. Go to each of them and replace the redundant with the desired one. Eventually some are used as classifier, which means you need to alter that with Ctrl-L
- remove the redundant element and the dummy diagram

You see that this is a bit laborious and error prone. You could assist that with scripts, but best is to avoid such conflicts in the first place.

q.

[Eve]

At a guess you've got partial classes. Unfortunately you will get that behavior on reverse engineering partial classes. It's a compromise to allow round-trip engineering to still work.

In addition to qwerty's comments, you will also need to check for attribute/operation return/parameter classifiers which aren't covered by the usage dialog. On the plus side, if you've just imported, you're unlikely to have any sequence diagrams using those types. That's another scenario that wouldn't be picked up by the outlined steps.