POSSIBLE BUG: Namespaces in C# code

[lpartington]

EA doesn't always seem to associate a type usage with the correct type definition when importing C# code.  It's not clear whether this is a bug, or there is some import setting that is not correct - it certainly seems more like a bug.

An example of the problem is when we have a base class in one namespace, and a client of that class in another namespace:

namespace A.B
{
   public class BaseClass2
   {
       public BaseClass2()
       {
       }
   }
}

namespace A.C
{
   public class Class23 : BaseClass2
   {
       public Class23()
       {
       }
   }

   public class Class24 : B.BaseClass2
   {
       public Class24()
       {
       }
   }
}

BaseClass2 as referenced by Class23 should NOT BE FOUND - the only definition of BaseClass2 is in namespace A.B, but Class23 is in namespace A.C.  However, when an import is done (either "package per directory" or "package per namespace"), EA INCORRECTLY associates Class23 with A.B.BaseClass2.  Furthermore, according to the C# specification, B.BaseClass2 should be found by searching up the A.C namespace hierarchy, so that A.B.BaseClass2 is found, but EA does NOT associate Class24 with A.B.BaseClass2.

Does anyone have any ideas as to whether this is a bug, or is there an import setting that might help?

A set of test cases was created to determine whether the relationship between a class and it's base class is correct,  using various combinations of using directives and base class namespace qualifiers, as shown in the following table:

Code: [Select]


Imported as "Package per directory"
                       using                         INHERITANCE RELATIONSHIP
Class Name   using A.B  BaseClass1=... INHERIT        modelled by EA
------------------------------------------------------------------------------
Class11      no         YES            BaseClass1     inherits correctly
Class12      no         YES            B.BaseClass1   NONE BUT SHOULD
Class13      no         no             BaseClass1     INHERITS BUT SHOULDN'T
Class14      no         no             B.BaseClass1   NONE BUT SHOULD
Class15      YES        no             BaseClass1     inherits correctly
Class16      YES        no             B.BaseClass1   NONE BUT SHOULD

NOTE that there are 4 cases which DON'T WORK CORRECTLY!


Imported as "Package Per Namespace"
                       using                         INHERITANCE RELATIONSHIP
Class Name   using A.B  BaseClass1=... INHERIT        modelled by EA
------------------------------------------------------------------------------
Class21      no         YES            BaseClass1     inherits correctly
Class22      no         YES            B.BaseClass1   inherits correctly
Class23      no         no             BaseClass1     INHERITS BUT SHOULDN'T
Class24      no         no             B.BaseClass1   inherits correctly
Class25      YES        no             BaseClass1     inherits correctly
Class26      YES        no             B.BaseClass1   inherits correctly

NOTE that there is 1 case which DOESN'T WORK CORRECTLY!

[Eve]

Hello Lachlan,

Having trouble answering your email support request because the mail keeps bouncing.  You see to have two issues.

1. You import C# code where no parent can be resolved and EA creates a relationship anyway.  This happens because once an import is done EA is completed the information from using statements is no longer available for linking purposes and therefore the relationship will be created regardless of any namespaces available.  This happens after all other options have been exhausted.  You can avoid this behaviour by making sure that all classes being used by the imported classes are imported before or at the same time.

2. When importing C# with a package per directory qualified relationships are not imported properly.  This is because EA uses the package structure to help resolve the namespace qualifiers for linking purposes.  In your example there is no package B that contains BaseClass1.  As a result no relationship can be created.  This is part of the reason for the warning that all languages that support namespaces should be imported with 'Package per Namespace'.  It doesn't give as accurate a view of the code structure, although it can still be helpful in some circumstances.

I hope that this information helps.

[Paolo F Cantoni]

[size=13][SNIP][/size]
2. When importing C# with a package per directory qualified relationships are not imported properly.  This is because EA uses the package structure to help resolve the namespace qualifiers for linking purposes.  In your example there is no package B that contains BaseClass1.  As a result no relationship can be created.  This is part of the reason for the warning that all languages that support namespaces should be imported with 'Package per Namespace'.  It doesn't give as accurate a view of the code structure, although it can still be helpful in some circumstances.

Simon,

This is the perennial problem of UML  - in that packages are namespaces not folders

In addition, EA goes to great lengths to hide the physical file associated with the EAElement.

Perhaps there is need for two views of the model:

1) The Repository Browser (what we currently call the Project Browser)  which details the model as structured from the point of view of UML  (NOTE: packages should be rendered as UML package glyphs NOT folder glyphs)

2) The Artifact Explorer that is structured according to the physical location of the artifacts.  That is, take the GenFile column in the database and use it to drive the structure of this view.  Rendering is as per Windows Explorer - with Folders rendered as folders, drives as drives, nodes as nodes.

That way, you clearly separate the two concepts.  If your model and file structure match, the two windows will match; if not, you have the views you need.

Now, if that's a good idea, it should be extended to adorn the Repository Browser element icons with an indicator to say there is/isn't a physical file associated with this EAElement and if there is, whether it exists or not. (Check for file existence would NOT normally be continuous - but on a per request basis)

Thoughts anyone?  Votes?
Paolo

[size=0]©2006 Paolo Cantoni, -Semantica-[/size]

[mikewhit]

Although I can understand the original EA approach of a "unified" (and superficially simpler) paradigm, separating the concepts as Paolo says does allow a clearer view of what's going on, once you understand the difference !

And yes, it should use the package icon rather than a folder one.

[Paolo F Cantoni]

Although I can understand the original EA approach of a "unified" (and superficially simpler) paradigm, separating the concepts as Paolo says does allow a clearer view of what's going on, once you understand the difference !

And yes, it should use the package icon rather than a folder one.

Thanks for that Mike,

As is so often the case, I find the simple approach all too quickly becomes simplistic.

I prefer the Einsteinian dictum:  "Keep things as simple as possible, but no simpler..."

Paolo