Packages, Namespaces & groupings

[Paolo F Cantoni]

Sparx (quite rightly, in my view) recommends that if the platform specific language you are code engineering has namespaces, then you should import the source directory creating a package per namespace.

In another posting Re: POSSIBLE BUG: Namespaces in C# code  I observe the perennial problem of UML  -  that packages are namespaces not folders.

Elsewhere (Classifier Name, GenFile and GUIDS ) Midnight observes that UML's definition of namespace doesn't fully align with various platform specific languages' definitions of namespace.

EA (of necessity) has introduced the concept of Namespace Root (in order to map a point in the UML hierarchy, with a value in a code file).

If you reverse engineer based on creating a package per namespace, there is no provision for grouping the classes beneath the namespace package.  If you create a package and move some classes there, the next time you synchronize, the classes are moved back out.  It is possible to have hundreds of classes under one namespace.

I am therefore proposing that EA add the notion of a Grouping Only package that means "does not participate in the namespace".

Say I have the following structure:

System
....SubSystem
........Component  - declared Namespace Root
............Namespace1
...............Namespace2
....................Grouping1 - declared Grouping Only
................Grouping2 - declared Grouping Only

If a class A exists in package Namespace1 and the code has the statement namespace Namespace1  Then synchronisation will leave it where it is.

If I move it to Namespace2 (but leave the code as is) then Synchronization will move it (back) to package  Namespace1

If I move it to Grouping2 (but leave the code as is) then Synchronization will leave it in package  Grouping2 (because Grouping 2 is still "in" Namespace1).

It should be noted that the effect of declaring a package as a Namespace Root, is to make all the higher packages "Grouping Only".  I'm just re-using the concept lower down.

Thoughts?  Votes?

Paolo

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

[Paolo F Cantoni]

This proposal also has implications for Database Sub-modelling.  See: [size=13]Database Sub-Models[/size].

Paolo

[SF_lt]

agree, this should be quick easily doible with the stereotypes

[paulourada]

Hi Paolo -

I have a similar issue, and have asked Sparx to implement something like what you've just described.  

Here's my issue.  We have actually organized our project exactly the way you've described: namespaces with organizational containers under them (suppose more than one person wants to work in the same namespace, but on different aspects of it?).  In order to get this to codegen properly, I have hijacked the Namespace* templates to generate just the namespaces we want (actually, just two namespaces - one is a framework and the other is the application).

Here's an example.  Suppose that I have a class, Foo in namespace Name and class Bar in namespace Space, and Bar derives from Foo.  Both classes are in one or more "organizational folders.  When you codegen Bar without namespaces turned on, you get the following:

Code: [Select]


namespace Space {
class Bar : public Foo
{
}

} //namespace Space


The generated namespace declaration is the result of the template modification.  The using statement is missing (because of some fancy footwork in File Impl codegen template) so this may not compile (depending on how smart or how diligent your compiler is) because Foo is not in the same namespace as Bar.  So, you think, "Aha!  I'll just qualify Foo, and that's nicer C++ code as well!" and you then have something like this:

Code: [Select]


namespace Space {
class Bar : public Name::Foo
{
}
} //namespace Space


However, now when you synchronize the class Bar in the model, the specialization relationship disappears, and the class box is now decorated with Name::Foo to indicate that the base class is missing from the diagram.

So, I asked Sparx to somehow conditionally make the package a namespace.  I thought that a package tag something like isNamespace with a default of "true" would do the trick.  Other UML modeling tools have such a facility -- or they used to.  It's been a few years since I used that other tool.

I haven't heard anything from Sparx since then.  So, if anyone has heard anything more about this, please drop me a line.

Thanks,
Paul

[Paolo F Cantoni]

We've decided to hijack the [  ] Abstract checkbox on the Package.  For this purpose.  We've also attached the stereotype «collation» to indicate a grouping function.

Can anybody give me an example of an abstract package?  (this is not a rhetorical question, I'm really asking )

As a temporary work around, it would be great if Sparx could refactor Ea to not include {abstract} packages in the namespace list.

Thoughts? Votes?
Paolo

[sargasso]

  Gee I love it when you guys talk dirty like this.


Thoughts: It's deteriorating the value of the <abstract> concept and may have ramifications. I know not what.

Votes:

Can anybody give me an example of an abstract package?

Should be taken up with OMG.

Real thoughts: "Packages" were (originallly) supposed to be purely organizational not structural. Components were supposed to be structural.  IMO namespace rooting should be (should always have been) lodged in/on a component basis.  However, I cannot blame EA for the mess we are currently in (and have been in for some time).  This time the blame lies entirely with OMG for confusing the package(organization)/component(deployable (((read "referentiable"))) entity).

Vote: Not sure, pragmatics v. polemic.  Where be the value?

bruce

[«Midnight»]

Yes Paolo, I agree,

Please see my responses to the other 'derived' posts that cite this one.

And sorry bruce, I've no light to shed on your point. You've said it well.

David

[Mr. Sanders]

Hello Bruce and Paolo,

please go to the development halls of sparxs and implement it.

We need that too.

But I can't see the mess you were talking about, Bruce.

Packages are namespaces and components are the deployable units.

The problem is how EA handles it.

It makes no sense, e.g. to start the build, debug, test, deployment and run command on a package.

These commands must be bound to a component of course and not to a package.

The deployment encompasses the classes of the target binary
and therefore it only makes sens on a component to run a build, debug, test script.

I have worked years with rose (no I don't want to use it again, don't be afraid) and they solved this problems.

You can drag and drop classes on components and thess components are the container/grouping where the work has to be done.

IMO the reverse engineering is bad in EA and the namespace root didn't make it better.

It's even worse, because EA automatically sets a namespace root when you import a source dir. This leads to a wrong code generation when starting from this point, because suddenly we have a namespace where no should be.

It's even worse, because you have to checkout every package level up to your namespace root, even if the pakages above your node where you want to reverse engineer are not affected.

This blocks team collaboration.

I don't think that OMG is the problem. For me its the package, namespace, namespace root logic of EA.

Michael

[peter.zrnko]

It's even worse, because you have to checkout every package levele up to your namespace root, even if the pakages above your node where you want to reverse engineer are not affected.

This blocks team collaboration.

If the option "Save nested version controlled packages to stubs only" is set, then it's not necessary to check out parent controlled package if you want to check out child controlled package.

...

And add my vote to the "grouping only packages" feature.

[Mr. Sanders]

Hello Peter,

the problem is not the checkout.
The problem is the reverse engineering.

Let's name namespace root 'NSR'.
Assume you have the follwing packages:

NSR.A.B.C

Now you get code with class

A.B.C.D.NewClass

The problem is, that you have to trigger the reverse engineering from namespace root (this is the fault of sparx IMHO). So as the consequence you have to checkout
package A AND package B AND package C, even if packages A AND B are not involved. This is the EA logic and this is cumbersome and contraproductive in a team collaborative environment.

If reverse engineering of the new namespace A.B.C.D lasts 4 days (this is our scenario, 17.000 classes, 4.000 interfaces) the team is blocked for 4 days working on packages A and B.
Although NOTHING happens in A and B!

It's just checked out because of the sparx logic and this strange namespace root concept and that it doesn't allows reverse engineering from the namespace root, if not ALL  subpackages are checked out. Even if nothing happens in the middle subpackages, but only in the leaf nodes.

Michael

[Paolo F Cantoni]

Real thoughts: "Packages" were (originally) supposed to be purely organizational not structural. Components were supposed to be structural.  IMO namespace rooting should be (should always have been) lodged in/on a component basis.  However, I cannot blame EA for the mess we are currently in (and have been in for some time).  This time the blame lies entirely with OMG for confusing the package(organization)/component(deployable (((read "referentiable"))) entity).

Hi bruce,
missed your original posting...

While I agree with everything you've said above, my  original question still stands - can anyone provide me with a real world example of an {abstract} package?

Proposal is risky, but only temporary, since Sparx IS going to implement a better solution aren't you lads?

I believe our current, interim, solution is a calculated (low) risk.

Paolo

[Paolo F Cantoni]

Proposal is risky, but only temporary, since Sparx IS going to implement a better solution aren't you lads?

Apparently not. At least not right now...

But they propose:

"We're not going to implement this at this stage, but you can achieve the same effect using a transformation.

The Namespace template could be modified to the following.

%if packagePath == "" or packageStereotype=="collation" or
packageAbstract=="T"%
%list="Namespace" @separator="\n"%
%list="Class" @separator="\n"%
%endTemplate%

Package
{
 %TRANSFORM_CURRENT()%
%list="Namespace" @separator="\n" @indent="  "%
%list="Class" @separator="\n" @indent="  "%
}

Note that this will treat a package as grouping only package if either it is abstract or has the collation stereotype."

HTH,
Paolo

[paulourada]

Hi Paolo -

Does this solution help the synchronization issues mentioned above?  It seems to me that they are two different issues.

Paul Ourada
Principal Software Engineer
Covidien (formely Tyco Healthcare)
Energy-based Devices (formerly Valleylab)

[Mr. Sanders]

Hello Paul,

yes, in my point of view, we have two problems here,
and Paolos solution, doesn't help the reverse-engineering problems.

But I think Paolo will provide a solution for the other problem soon too! Isn't it Paolo

[Paolo F Cantoni]

But I think Paolo will provide a solution for the other problem soon too! Isn't it Paolo

Not as far as I know...  

See Sparx about solution outcomes...  I can only provide solution proposals...

Paolo