generation activity diagrams from usecase scenario

[Edward G]

Hi

if you select to create an activity diagram from use case scenario the EA adds activity with the same name as use case has and then withih the activity creates activity diagram. I can't understand why the EA creates the activity, where i can get any explanation of the behavior?

Thank you

[qwerty]

It's a template and you have to fill in whatever makes sense.

q.

[Edward G]

Hi qwerty

What have I to fill?

I understand when I write steps of scenario.  Then I can create activity (and other available) diagram. Why I have to made it through activity elements. Is it constraint of EA. Is it special practice? Where I can recognate with it?

Thanx

[qwerty]

I'd recommend the books from Cockburn or Bittner/et al. about UC modeling. ADs and scenarios are alternative ways to describe the same thing. From my practice I can tell that it is best to use either where appropriate an not both as it introduces redundancy. ADs are recommended where you have many alternatives. Textual is better/easier (to create and read) where you have a straight line of actions.

q.

[jfzouain]

Hi

Also recommend the same book, but I disagree at not to use both only when needed. You are correct on on a small Use Case with only a Basic and Alternate path that text is better.
But my experience tells me that presenting an Activity Diagram right before the Use Case scenario, if is only one Alternate, the reader will undestand better the UC flow.
Remember this chinese proverb "A picture is worth a thousand words"

 

[qwerty]

I will not start arguing here One should setup his mind on own experience. So think about both sides of the coin. Actually I prefer ADs (eventually extended with some BPMN) over textual description. Only in the simple cases I think that SDs are superfluous. YMMV.

q.

[Helmut Ortmann]

Hi,

in my personal view: If you use Activity diagrams to early you get sidetracked in to much details. You know every detail but you fail to see what's really important for success. You use developer glasses, not that of your stakeholders.

The most benefit of Use Cases is to see the mayor things that are important for your customers (not your developers).

Therefore the restrictions of Use Case force you to focus on the important things. More isn't really possible with Use Cases.

Helmut

[Edward G]

Hi all!

Thank you for your opinion but I don't ask it is better or is not to draw an activity diagram before text scenario or vs.

I ask! WHY when you create an activity diagram from use case scenario the EA adds ACTIVITY with the same name as use case has and then withih the activity creates activity diagram. WHY is not direct into activity diagram. And where we can get any explanation?

As for me I prefer text description instead of diagrams. But my friend - a RUP specialist -prefer to made model before text and obtain text from diagram following MDA.

That is an example for such approach: IBM Rational Harmony Deskbook Rel 4.1

[Gary]

You have an activity because an Activity diagram is used to illustrate an activity of interest. They describe "how" your activity of interest accomplishes the process set out in the activity name. It comprises of actions that are chained together to represent the process. Incidentally activity diagrams should not really contain activites, they contain actions. The activity is the thing being modelled by the actions. Which is why an activity diagram sits under an activity element.

Gary

[qwerty]

Well, see my first reply to your question. That IS the answer.

q.

[Edward G]

It's a template and you have to fill in whatever makes sense.

q.

Well, see my first reply to your question. That IS the answer.

Well, English is not my native language so I couldn't assigned your answer to my question  

[Edward G]

Which is why an activity diagram sits under an activity element.

Gary

Thanx. Gary. Logic is clear.

[qwerty]

Well, English is not my native language so I couldn't assigned your answer to my question  

My bad. I tend to give more short answers than few longer ones (most of the time).

q.