Book a Demo

Author Topic: Action vs. Activity  (Read 29040 times)

Allirav

  • EA Novice
  • *
  • Posts: 18
  • Karma: +0/-0
  • Implementing many interfaces....
    • View Profile
Action vs. Activity
« on: December 19, 2006, 06:31:37 am »
Can someone explain to me when you would use an Activity vs. an Action?

My initial impression is that an Action is a lower-level of granularity than an Activity.

Additionally, I THINK I could use actions to describe the steps within a Use Case.

So, an Activity may have multiple use cases associated with it.  A Use Case may have multiple actions associated with it.

Of course, a given use case may have multiple Activities associated with it, but it would not be the usual case.


StefanPears

  • EA User
  • **
  • Posts: 119
  • Karma: +6/-0
  • Unwissenheit schützt vor Erkenntnis nicht
    • View Profile
Re: Action vs. Activity
« Reply #1 on: December 19, 2006, 09:18:57 am »
Well, everything you say is right. I'd like to add some more information:

An activity is usually described by a flow build from actions and connections.
In business sense an action is atomic
A use case can be described by an activity diagram, which contains one or more activities which contain one or more actions and connections
Actions and activities can be reused in several contexts, so you have a m-to-n-relationship between use cases and activities/actions

There is surely a lot more to say. You should have a look at the UML2.1-specification. You can download it for free from www.omg.com.

hth Stefan
« Last Edit: December 19, 2006, 09:19:21 am by sbirner »

bioform

  • EA User
  • **
  • Posts: 230
  • Karma: +0/-0
  • Forty-Two?
    • View Profile
Re: Action vs. Activity
« Reply #2 on: December 27, 2006, 04:03:34 pm »
Very good response...

I do use an activity diagram to document the Basic, Alternate, and Exception paths of a Use Case. Additionally I change the line types to a different weight and color for each path type...

From this, I am able with some code to "derive" the scripts (Actor/System interaction) that the activity diagram represents... Currently able to derive the "basic path" (no brainer), "alternate" paths (bit more difficult) which are than "mapped" by the user (via a UI) to specific scenarios of the "alternate" type.

I have yet to start doing the "exception" paths, but they should be a variation on the code...

From there... It's automated creation of the Basic Path, and Alternate Path test cases (Acceptance Tests) and they inherit the script from their UC Scenarios...

Pretty cool so far... Just a hack, until I can get the time to create my first add-in...
Time is what keeps everything from happening at once, Space is what keeps it all from happening to you. <unknown>