Help needed: Activity diagrams with Actors ?

[JohnDoe]

Hello,

in a useCase diagram, Actors are being placed to describe, who initiates and uses a UseCase. Now, when opening a composite diagram underneath a UseCase, I can describe the flow of activities of a useCase. While notating the activities, I often find different users being involved in executing single steps.

What do you suggest:
a) add those users to the higher level UseCase diagram, showing their access on the same UseCase and add notes to every Actor/useCase-association  ?
b) add those Actors to the single steps inside the composite activity diagram to demonstrate, which steps requests the usage of a special user ?

What do the UML philosophs think about it ?

Thanks in advance for any idea or help.

Regards
Bernd

[Davinchi]

Hi Bernd,

You can use partitions or swimlanes to specify who's in charge of executing an activity.

Check the EA help files, to know how to use them.

Hope that helps,

David.

[«Midnight»]

Bernd,

You should rarely need to add notes to your use case diagrams. Just position the actors to make it clear whether each actor is primary (does something) or secondary (is affected).

In your 'child' diagram, swimlanes (or any other subordinate construct, depending on the diagram type) should clarify why each actor is 'in the picture.'

Also, remember that actors and users are closely related but not necessarily the same.

David

[JohnDoe]

Hi,

thanks for the comments !

Swimlanes are just visual helpers, but not usable for reports.

I want to define an amount of processes using activity diagrams. The allowance to execute steps shall be bound to roles and not concrete actors. Of course a group of users will use the UseCase, but they shall colaborate while executing those UseCase steps in a specific way. Therefore I need to model the steps and connect them to "roles", which allows the administrators to create new complex combinations of roles (such as conflict manager with 12 roles, configuration manager with 23 roles etc.) during runtime and associate them with accounts.

What UML element or stereotype do you suggest for collecting those roles ?

Regards
Bernd

[thomaskilian]

What about an Actor stereotyped as <<Role>>?

[«Midnight»]

And perhaps show an inheritance or aggregation relationship between them to show who which roles...

[bioform]

Not sure if this helps.... But a handy approach...

1. For each actor I define, I then go ahead and create a partition for that actor and place the partition under that actor in the project browser.

2. Create an activity diagram for the use case.

3. Drag the UC's actor's partition into the diagram as a LINK.
4. Drag the system's partition into the activity diagram as a LINK.

5. Extend the partitions....
6. Create the activity flow(s), dropping the items in the appropriate partition, and connecting them with the appropriate connectors (e.g., control flow)

7. THEN the tricky part... if you explore the RDBMS table that holds the diagram components you will see where the object's X/Y coordinates are stored, then I have written code that determines which partition 'contains' which action/activities... then I exploit this information in various ways... to support training, documentation, testing, etc. Pretty powerful way to 'derive' information from the model for both documentation efforts, and 'enhancements' to EA...

Best Wishes...

MAN, I just love going under the hood and tweaking!

[KP]

7. THEN the tricky part... if you explore the RDBMS table that holds the diagram components you will see where the object's X/Y coordinates are stored, then I have written code that determines which partition 'contains' which action/activities... then I exploit this information in various ways... to support training, documentation, testing, etc. Pretty powerful way to 'derive' information from the model for both documentation efforts, and 'enhancements' to EA...

I've used a similar technique in the past but using the Automation Interface. You can check the DiagramObject.left, .right, .top and .bottom attributes for all objects in the same Diagram.DiagramObjects collection.

[bioform]

Exactly... If you take the time to understand the tables and/or the object model you can really do some amazing things!

[Paolo F Cantoni]

Exactly... If you take the time to understand the tables and/or the object model you can really do some amazing things!

Which is the major reason we went with EA (in spite of its UI (Unique Interface)

Paolo