Yes, but that will break the Overview Pyramid for Java systems.

We need to find a solution that deals with this variation if we want to keep the Overview Pyramid at all.

Doru

On Tue, Mar 3, 2015 at 3:40 PM, stephan <stephan@stack.nl> wrote:
Name: Famix-Extensions-StephanEggermont.283
Author: StephanEggermont
Time: 3 March 2015, 3:39:46.019928 pm
UUID: 727a4f0e-c96c-43c6-8903-6ca15bc76c7a
Ancestors: Famix-Extensions-TudorGirba.282

Use pacakges instead of namespaces for nop
OverviewPyramidMetrics


On 03-03-15 15:29, stephan wrote:
That makes sense, as the OverviewPyramidMetrics use
nop := aMooseModel allModelNamespaces size.

There is no test in Famix-Tests-Extensions that tells me what to expect.
It is something I noticed when migrating it.

Stephan

http://forum.world.st/OverviewPyramid-metrics-td4782812.html

On 03-03-15 15:03, Alexandre Bergel wrote:
I have the same result.
Importing many packages results in NOP=1

Alexandre


On Mar 3, 2015, at 7:41 AM, Sebastian Tleye <sebastian.tleye@gmail.com> wrote:

Hi,

I have a system with several classes and several packages. I want to do an Overview pyramid visualization. I select them all and when I do the pyramid it says NOP = 1 (number of packages equals 1), then I have a high NOC.

Why is this happening? Is it correct?

Thanks

--
Sebastián Tleye
_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
Moose-dev@iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev



--
www.tudorgirba.com

"Every thing has its own flow"