Book a Demo

Author Topic: C# Reverse Engineering Problems  (Read 3939 times)

wvsvenkat

  • EA Novice
  • *
  • Posts: 2
  • Karma: +0/-0
    • View Profile
C# Reverse Engineering Problems
« on: November 13, 2003, 03:07:43 pm »
Hi,

Could any of you help or confirm if this is a known problem. I have reverse engineered a c# project (.NET solution). I have one parent class and two child classes generalizing from it. However when I try to make a new class diagram and drag from the project view, all the three classes. Only one of the two generalized class is shown with the generalization arrow. Not the second one. But when I choose the "set element parent" context menu on the second one it does show the parent class, but it does not show the generalization arrow.  :-[

Any ideas?

Best Regards,

Ven

benc

  • EA Administrator
  • EA User
  • *****
  • Posts: 200
  • Karma: +0/-0
    • View Profile
Re: C# Reverse Engineering Problems
« Reply #1 on: November 13, 2003, 04:35:59 pm »
Hi Ven,

I don't believe this is a known issue.

Perhaps the connector is hidden. Try this:

1. Open the class properties for the derived class (the one that does not show the generalisation connector)
2. Go to the Link tab
3. Can you confirm that the generalisation relationship is shown?
4. If it is present, select it and right click on it
- You should see an option "Show Relation".
- Click on this option- the connector should be shown

I am not sure why the arrow would be hidden in the first place, without explicitely hiding the connector.

If the above steps do not resolve the issue, please send a bug report to sparx. If possible attach a sample source file from which you are importing, include the steps taken to reproduce the error, the build number of EA etc.

Regards,
Ben

wvsvenkat

  • EA Novice
  • *
  • Posts: 2
  • Karma: +0/-0
    • View Profile
Re: C# Reverse Engineering Problems
« Reply #2 on: November 13, 2003, 07:23:25 pm »
Hi Ben,

Thanks for quick response. I have narrowed down the problem.

1. During the reverse engineering process, if you have a fully namespace-qualified form of base class name in the derived class declaration does that problem occur, (that too only the first time when it reverse engineered, not when you synchronized the class from code subsequently)

That is:
namespace X{Class SomeDerived: Somebase{} \\This WORKS}
namespace X{Class SomeDerived: X.Somebase{} \\This DOES NOT WORK}
         
But if you remove that(full namespace qualification portion"X."), it works fine. In fact it looks like the EA gets confused and cannot identify in which package the base class "SomeBase" exists, though both the parent and the child are in the same base class. So it does not create the link to the parent (generalization).

2. However once the link is reverse engineered correctly (when not fully namespace qualified), it does not matter whether you fully namespace qualify or not through editing. It can recognize the link correctly, when you syncronize it with or without the fully namespace qualified form.

3. You should be able to create a sample Visual Studio.NET project in C# to reproduce it. If not email me I will send you a sample code to reproduce.

Thanks and Best Regards,

Ven

benc

  • EA Administrator
  • EA User
  • *****
  • Posts: 200
  • Karma: +0/-0
    • View Profile
Re: C# Reverse Engineering Problems
« Reply #3 on: November 17, 2003, 11:04:32 pm »
Hi Ven,

Thanks for the additional information- yes this narrows the problem down.

Basically, this is a limitation in the way namespaces are currently handled in EA. When EA sees "X.Somebase" it is treating the base class name as "X.Somebase". Instead it needs to recognize "Somebase" as a class name in the namespace "X", as you pointed out. Now because "X.Somebase" is not a class element that exists in the model, you only see it as a parent name, without the connector to class "Somebase".

We are developing enhancements to EA's support for namespaces and will resolve this issue as part of these efforts. I cannot give a definate time frame for the fix at this stage however.

Regards,
Ben