Reporting actors with every use case?

[marcelloh]

I wonder if this is possible?
(and how it is done :-))

[RoyC]

What exactly do you mean by 'report'? There are various ways to extract this kind of information from EA. What is the process and end result you have in mind?

[marcelloh]

I've got a package with a couple of actors and a couple of use cases.
Let's say Actor "SalesPerson" uses UC1 and UC2
Then I would like to see in the documentation of UC1 that there is an Actor called "SalesPerson".
Even if I have a actor form another package, I would like to make this clear in the doc's.
(This is just because not every UC is going to everybody.)

[RoyC]

I'm assuming that when you say 'documentation' you mean an RTF report. Yes, you can filter your report to show only Use Cases and the Actors related to them. You must run this report at a package level - select the parent package and press [F8] to define the report. See the Options tab of the Generate RTF Documentation dialog.

http://www.sparxsystems.com.au/EAUserGuide/index.html?rtfdocumentoptions.htm

Under the Exclude details for panel, click on All, then deselect Actor and Use Case. Note that this will include any 'Use Case extends Use Case' relationships too.

You can also isolate the Actor - Use Case relationships on the Relationship Matrix (and print the results or transfer them via a CSV file to a spreadsheet). Or you can locate the relationships using either the Relationships window or the Element Browser window.

For full details, see the Help.

[marcelloh]

I've tried this, and these are my selected sections:
+ Package
   + Diagram
      + Constraint
      + Scenario
      + Model Document
      + Requirement
      + External Requirement
      + Child Elements

There is a page, which shows an Actor.
It's the actor that it this particular Package, but another Actor,
which is a an application wide Actor, is not shown.

The layout where the "Actor-page" is printed with, is the layout of the Use Cases, so it has "strange" headers for an Actor.

And now what I was asking  :
I want the actor to be included in the part where UC1 starts, and again where UC2 starts. If I give my documentation, I want the reader to understand which Actors are involved with the particular Use Case they are reading.

Perhaps this can be done by generating several different documents with different layouts in one run and merge them myself.
If I try this (from within the resource view), the program really does something, but where the end-results are stored, I don't know. (I can't ask properties there!)

Hope the above dutch-braindump is more helpful  :-/
  

[RoyC]

I'm not sure what is happening here, but I would have thought that to make your report show Actors related to Use Cases you would have to also select the Connector and Source (or Target?) checkboxes in the section selections in the RTF Template Editor.

You perhaps should send a support request to Sparx Support (with Midnight's usual caveats and requests) to get the RTF gurus to have a look and give their advice.

[marcelloh]

I've now got this:
+ Package
  + Diagram
     + Constraint
     + Scenario
     + Connector
        + Source
           + Element
     + Model Document
     + Requirement
     + External Requirement
     + Child Elements

And it shows me the Actors-names. but.....
also the Use Case a several times and...
the header is repeated for every element-record there  

[Krzysztof Swiatkowski]

I think you can get what you want if you have a diagram with UC's and Actors in each package. Then you can select
+Package
++Diagram
+++Element <- this will create documentation for each element on a diagram which will include Actors from all over the project.

HTH
Kris

[marcelloh]

I'm sorry, but this is not the case. (I tried this.)
And my question was to have actors inside every use case, not in the package.

So each use case should have this:

• Name
• Notes
• Constraints
• Actors (even external ones)
• Scenario's
• Linked document
• Requirements (Even external ones)

[dbax]

I for one understand what you're going through. I had a similar situation and ended up generating document which included everything and then manually removing unnecessary data.
I would like nothing more but to see RTF generator being "beefed" up with some conditional parameters (i.e. WHERE Element.Type="Actor") in place of tags so that certain information can be included based on the certain characteristics or properties of an element (I use element very loosely here to imply every tag in the document).
I had a lot of previous experience generating documentation out of Rational SODA and even though I didn't like it (very buggy and "sensitive') it had such functionality as specifying conditions prior to generating a document.
I know we can resort to programming (done that too) and get information out of EA using EA's automation interface but that's not that simple and not easily understandable by the average user.
Having said this, your only option is to resort to the suggestion from "ged" and use in your document a section where you can dump "Package->Diagram->Element" and then cut everything else from there but Actors. Another one is to use Connector->Source->Element with Element.FullName and Element.Type included. That way you can see which elements are of type of Actor and remove the other ones.
Unfortunately, as you can see manual workaround is required. I guess that's with every documentation we have to deal with - you kind of have to spend some time typing and formatting  
Regards,

D

[RoyC]

From my original response:

"You can filter your report to show only Use Cases and the Actors related to them. You must run this report at a package level - select the parent package and press [F8] to define the report. See the Options tab of the Generate RTF Documentation dialog.

http://www.sparxsystems.com.au/EAUserGuide/index.html?rtfdocumentoptions.htm

Under the Exclude details for panel, click on All, then deselect Actor and Use Case. "

Does this make any difference? I would hope that this filter would reduce the amount of cutting and dumping of material from your report. Doesn't it help?

[marcelloh]

Of course this works, but it doesn't generate the actors within the use case.

I learned that Actors uses a use case, not a package, so my documentation should represent the stuff that an analyst would hand out to another person. If generation means, that I have to cut and paste stuff, the generation doesn't work. (Or it generates things that are not usable!)

Assume that I am a programmer, and I tell the customer: Hey, I've made stuff for you, but you only have to get some crap out, recompile, and you're good to go!

As an hint what a use case should look like:
http://epf.eclipse.org/wikis/openup/openup/guidances/templates/use_case_specification_E97E98B0.html?nodeId=e2337d48
There is a good example, which I pretty much follow.
That's how I'm feeling right now.  

[«Midnight»]

Marcelloh,

I think there's hope - both here and for your other threads - but it involves some work on your end.

You seem to have several requirements relating to presentation of use cases, whether withing EA or in reports.

Without voicing any opinion on the value of these as EA features - I'll leave that for the user community to do, and ultimately for Sparx to decide - I think the immediate issue is: How can this be done now? [That is, while your project is still ongoing.]

You've made it pretty clear that the available workarounds do not provide results that are satisfactory for your needs.

Given the number of things you need to accomplish, it could be a while before Sparx can resolve all the issues that apply. That's assuming that you can make a sufficient case for implementation of all the necessary features, not a sure thing at all.

So...

The good news is that most if not all the needs you've identified (so far) are related. From the sound of things the solutions should be highly synergistic.

I suggest that you reconsider the value of EA automation to solve your problems. This need not be a complex program, nor would it necessitate acquisition of a high-end development environment. It could even be 'slapped together' in something like VBA, perhaps running as a Word macro. [I've used this approach to solve documentation problems more complex than yours, with very workable results.]

Take a few days to get the hang of EA automation. You don't need to go too deep, just enough to identify elements from diagram objects, and trace their links to other elements. From there you should be able to get pretty much all you need.

You could also use a similar approach to populate other diagrams with only those elements you need, after you create the diagrams and preset some of their options. You'd probably want to position elements on the resulting diagrams by hand once your program finished up.

The only issue you'd face is understanding how to automate your output. If you use something like Word for reporting then you need to understand that model. If you use another RTF-capable application then Word might be a suitable first step. This approach is almost certainly easier than manipulating RTF directly.

From your earlier posts I gather that this is not your preferred approach by far. I do understand your concerns. Still, given the number of threads you've started, it seems that your project is getting bogged down. I'm just suggesting that it might pay off to revisit automation in order to get to delivery.

David

[Pkhaiat]

We have a similar requirement, and have adopted the solution suggested by a previous post, namely driving the RTF report from the diagram. Assuming that you have a diagram showing the Use Case & its associated actors, the issue is that the actors may come from different packages. Using Diagram Elements should work, but ONLY if you go to the Diagram properties & select "Document each contained element in RTF" in the Diagram tab.