Element Report for packages – no children?

[Ken Norcross]

Hi All,

I am trying to get to work an element report that targets stereotyped packages spread across our model.

It seems as though the behavior of eaDocX is different when using the Element Report.

If I directly connect a package to a section in the document everything works as expected, all of the children of the package are processed for formatting in the report.

If I create an Element Report that targets the same package(s) the children of the package are not processed.

This can be demonstrated in a single document with 2 sections, one section directly related to a package, and another section that finds the same package through an Element Report set up to use the package as a source.

Both sections share the same profile definition, but the results are not the same. The Element Report section does not process the children of the package.

My goal is to create an element report that will scan our complete model and report on packages with a certain stereotype (and report on the contained children and sub-packages of the package).

[Ken Norcross]

Some additional detail…

eaDocX v3.4.1.1

Sparx v10.0.1008

[eadocX Support]

Is the problem still there in 3.5 ? I made some changes in this area, so it just might have got fixed…

[Ken Norcross]

The timing is not good for me to upgrade eaDocX (nor Sparx) so I cannot answer this.

[eadocX Support]

Hi Ken – you’re quite – the behavior is different, and deliberately so.
The Element Report collects all the elements of the required type into a flat list, then prints that list. So, if you tell it to collect ‘Package’ elements, you’ll get the packages all printed in a flat list, including sub-packages and sub-sub-packages, all the way to the bottom of the tree, but all printed in the same way. We deliberately don’t print children of packages, here, because you’d get lots of packages multiple times.

If you want to print the packages ‘as normal’, that is, with their children and sub-packages, then they way I’ve done that is to connect the required packages to something else. In my case, this was an element which represented a particular software release, which I connected to packages of Requirements, Changes, Issue etc.
This worked well, and allowed me to print documents for each release, even though the EA model wasn’t structured by release (it was by business area).

[Ken Norcross]

Thanks, I have not thought of doing anything like this, this is an interesting technique and I will explore this, thanks!

[Ken Norcross]

I will also explore model views and ad-hoc diagrams, thanks for the pointer to another direction.

[Author]

Posts