OK, activities vs actions: when you drag an activity from the projectbrowser on to an activity diagram -and hold the CTRL down when dropping- you are presented with two options:
1) paste activity as simple link - the activity is included on the diagram. This is what one usually would do and apparently the scenario generator does (didn't know that, i prefer to work the other way around
)
2) create an action that 'links to' the activity. This is analogous to dropping a class on a diagram and selecting 'instance of element'. Think of it as saying 'the step that this action represents is executed by this activity (take a look at the action properties dialog, tab 'Call' property 'Behavior' and you will see what i mean)
Now try to drag the same activity on the diagram a second time (option 1): EA will protest.
But dragging a second -instance- (option 2) is allowed.
Now to answer your question, there are 2 drawbacks i can think of when using -activities- on flow diagrams:
1) an activity can be used only once on the same diagram (as demonstrated above)
2) EA will automatically draw all current -and future- relations between the dropped activity and any other elements on the diagram it knows of (try adding a number of activities on one diagram, and then on another diagram as well, and change some relations and you will see what i mean). You can hide relations if you want but this way you will have to keep checking and updating previous work. Even worse: if you are not carefull you end up creating the same relation a second time at some future moment.
When using activity instances (actions) the above drawbacks don't occur since the action is a separate model element with its own relations.
The drawback of using -actions- is that the extra level of indirection creates problems when you want to answer questions like e.g. 'which activities are involved in this process?'. The relationship matrix for instance visualises only direct relations, e.g. action-action, but not activity->action-action<-activity. So you will have to write some (SQL) queries or script to get the answer you need, or use the available tools like the 'traceability' window to do it manually.
So it really depends on your background and how you intend to use you model what is best.
On the whole i prefer using -actions-, because it creates a clean distinction between structural relations, and dynamic relations between activities like control/object flow. In other words: use classes & activities/use cases to visualize structural relations, and objects (= class instances) and actions (=activity instances) to visualise dynamic relations. Write script/SQL to resolve relations between the underlying classes & activities.
hope this helps,
Paulus
Show Posts
...