Issue about Issues RTF reporting

[Tom_Andries]

In EA, we find issues at the project level, the model level, the element level and ... graphically represented via a "custom" kind of note.

It's getting a bit crowded, certainly because reporting is far from obvious.
Project issues and system model issues seem to be the same.
I admit they are easy to RTF report via Model->Issues section.

Issues related to a model element can be created via:
a- the maintenance tab
b- the custom graphical "Issue" in the project browser dragged as child-element under the concerned element

While the first one is more complete, the second one is quicker during user assisted modeling sessions.

Reporting problems for each:
a- In the RTF generator, you'll need to print EACH element name - regardless whether it has issues or not -!!!
For the RTF issues section does not show name and (stereo)type of the related element.
b- there's no way to filter only these "issue" elements out, I guess.

Is there any solutions to either a or b ?

Thx!

Tom

By the way
(1) Using EA with Visual Sourcesafe. Works great!
(2) RTF report generation, while sometimes reacting awkward, is a major step forward. Now I can really recommend my clients to use EA, as they get the output they want.

[thomaskilian]

...
While the first one is more complete, the second one is quicker during user assisted modeling sessions.
...

I came across this one a while ago. My conclusion so far was: Use element issues and adorn them with Tags as appropriate. I needed to add some checking mechanism with the AI. In the end it depends on what you want to do. Probably everybody has to experiment and find the best way individually.

[Tom_Andries]

Ive started using project issues only for things that come my way outside a modelling effort. Copies of mails, ideas of people passing by, ...

I'll move them to one or more modelelement as the project progresses.

Another disturbing fact is the lack of consistency: issues at project level and issues at element level do not bare the same characteristics.
As a result, any report will have to be constrainend to the common minimum.

I would expect any logical project to threat - or at least note - all issues the same way.

What do you use the tag for? Can reports be filtered thereon?

I either have to note the element somewhere in the element-specific issue, either repeat all element names on the RTF (issue or not). Both are overkill.

[thomaskilian]

I use the Tags for things like "Date Due", "Responsible" a.s.o.

For reports I take a quite unusual way. Once I played around with a Perl package for RTF generation and I pimped it up for my use. Now I'm very flexible in genrating any RTF docu I like.  Working with RTF tags is really awkward so I hardly can change anything in layout...

[Paolo F Cantoni]

I use the Tags for things like "Date Due", "Responsible" a.s.o.

For reports I take a quite unusual way. Once I played around with a Perl package for RTF generation and I pimped it up for my use. Now I'm very flexible in generating any RTF docu I like.  Working with RTF tags is really awkward so I hardly can change anything in layout...

Thomas,

Do I understand  you correctly to say that you embed no formatting information within the model itself, but use contextual information at time of generation to format the output document?  For example, using Perl (which I'm not overly familiar with), you get access to the COM model for EA, you then say (something like) all classes with stereotype "Fred" will be rendered in "Fred" styles and structure, while classes with stereotype "Bill" get Bill styles and structure.

I'm thinking of doing the same kind of thing with my Model Emitter and would be interested in your experiences.

Cheerz,
Paolo

[thomaskilian]

Paolo,
that's right - more or less. My need for documents is rather limited, but when I started, I found out that the existing (old) RTF generator was not powerful enough. So I started playing aroung with my old Perl packages. Theoreticallly I can produce nearly any documentation style. In practice there's the simple limitation that you have to know RTF tags by heart.  I spent several days working out how certain styles are represented using RTF (which was a nightmare), coded what I needed and then forgot about it. Although the code is quite structured (I even managed to create an .EAP for it), the startup for a change is rather high. You have to know Perl quite well (honestly speaking: Perl is a nightmare for humans since it is optimized for an interpreter) and you also have to fiddle around with RTF (for which I can say the same as for Perl). It's up to you. If you want to have a look, I'll send you the pointers.

[Paolo F Cantoni]

Paolo,
that's right - more or less. .
[size=13][SNIP][/size]

Thanks Thomas,

I'm not particularly worried about Perl, per se, although I might talk to you off-line about RTF.  It was really a question about the practicality of formatting down-stream, using model context.  I'm glad to see it worked well for you.  I'll probably do something similar but using my model emitter XML/XSD interface as the context generating mechanism.

Regardz,
Paolo