Free sorting of diagrams and packages in browser

[NilsH]

Hello,

I have the following request (will be posted to Sparx via HTML form, too) for an "extended free sorting" feature:

• For maintaining complete documents (e.g. requirement documents or specifications) within EA, it is necessary to freely position a diagram (or any other object) within a package. This means, it should be possible to position a diagram in between two requirements on the same package level.
• Going along with this, sub-packages should be (able to be) displayed at the bottom of a package, just as the document structure is in reality (compare document structure in a word processing tool).
• Furthermore, it would be nice to set the "extended free sorting" option for a project, not (only) for the local EA installation. Otherwise, document structures would not be seen with the wrong setting. Modifications would then lead to a corrupted document structure.

Current (Nov. 2009, build 848) situation and it's restrictions:
With the correct setting of the project browser options ("allow free sorting"), it is possible to freely sort all objects - except diagrams and sub-packages. These are always positioned at the top of the package (first diagrams, then sub-packages), which is not acceptable when writing reports. In typical reports, it should be possible to insert images (positioned in the diagrams) at every point of the structure. Sub-packages are exported at the correct position in the created document, but this is not apparent for the user when looking at the structure in the project browser.

When the project is opened without the "free sorting" option, the sorting is not displayed, but still saved in the project.

Feel free to comment.

Best regards,
Nils

[Eve]

Are you aware that even if this was implemented, the diagrams appear in a different section of the rtf report, so you can't mix diagrams and elements at the same level no matter what you do?

I would instead recommend (although I don't use the reporting feature much) embedding diagrams under different elements.  This would allow you to have the diagrams in the appropriate place in the report.

[Oliver F.]

Current (Nov. 2009, build 848) situation and it's restrictions:
With the correct setting of the project browser options ("allow free sorting"), it is possible to freely sort all objects - except diagrams and sub-packages. These are always positioned at the top of the package (first diagrams, then sub-packages), which is not acceptable when writing reports. In typical reports, it should be possible to insert images (positioned in the diagrams) at every point of the structure. Sub-packages are exported at the correct position in the created document, but this is not apparent for the user when looking at the structure in the project browser.

As Simon already wrote the document structure in RTF reports is not determined by the position of the element type in the project browser but by the position in the RTF template. Thus your sorting will lead to no change unless Sparx also frees the template structure from this limitation. Which would lead to critical side effects.
For HTML reports this does not apply as you have full access to the navigation from the project browser. However I am not aware whether the free sorting is reflected in the HTML report.

If you want special documentation for a requirement by a diagram just place it below that element or use the notes feature of the diagram.

Oliver

[NilsH]

Are you aware that even if this was implemented, the diagrams appear in a different section of the rtf report, so you can't mix diagrams and elements at the same level no matter what you do?

I would instead recommend (although I don't use the reporting feature much) embedding diagrams under different elements.  This would allow you to have the diagrams in the appropriate place in the report.

Oh, I see. Ok, placing of diagrams always below another item (e.g. a requirement) as a nested item would be an acceptable procedure.

Nevertheless, displaying sub-packages at the end of a package as in the export would still be desirable, as well as the project-related free sorting option.

Regards,
Nils

[Oliver F.]

Nevertheless, displaying sub-packages at the end of a package as in the export would still be desirable, as well as the project-related free sorting option.

Again, you can do this in the RTF template by specifying the child packages section to reside at the desired location.

Oliver

[NilsH]

Again, you can do this in the RTF template by specifying the child packages section to reside at the desired location.

Yes, the sorting can be defined in the RTF template, but at the moment, the resulting document order (sub-packages subsequent to the elements/requirements of the parent package) is not represented in the EA GUI.

Example for the EA structure (current situation):

• Package X
• Subpackage 1
• Requirement N
• Subpackage 2
• Requirement A
• Requirement B
• Requirement C

Example for the resulting report (current & intended situation):

Package X (heading)
Requirement A (text)
Requirement B (text)
Requirement C (text)
Subpackage 1 (heading)
Requirement N (text)
Subpackage 2 (heading)

Do you see what I mean? A normal user may get confused by the different structure.

Regards,
Nils

[smendonc]

[highlight]<Do you see what I mean? A normal user may get confused by the different structure.>[/highlight]

So how would you handle the case where you have multiple reports for different users with different structures.  It still wouldn't be possible to reflect every report structure at the same time in the browser.

IMO the report is a specific view of the model not the model itself.

[NilsH]

So how would you handle the case where you have multiple reports for different users with different structures.  It still wouldn't be possible to reflect every report structure at the same time in the browser.

IMO the report is a specific view of the model not the model itself.

For hierarchical text documents, I only know the structure as shown above (text always belongs to the last written heading, not to a superior heading), but with a more general approach (also creating tables etc.), you are probably right.

[Oliver F.]

My above point was pointed at your requirement to organize your model not with regard to modeling issues but with regard to documentation requirements. This is a way which I do not recommend as it might lead to a chaotic approach in the end. Your model might not reflect the way it is built but the way people would like to see it documented.
So it is a very good idea to clearly separate views (eg. a RTF report) from the model.

Oliver