Re: Scenarios in Activity Diagram

[Remy Fannader]

Hi,
AD should should be used to described activities independently of
applications because core business rules are set by business analysts
and are meant to be reused across systems and platforms.
Scenarii are execution paths of activities. As such they are also
instances of use cases, identified by the triggering conditions (event
and context) as well as decisions taken along that path. That
distinction is critical when use cases are to access shared
resources.
http://caminao.wordpress.com/how-to-implement-symbolic-representations/use-cases/
http://caminao.wordpress.com/how-to-implement-symbolic-representations/patterns/functional-patterns/use-case-patterns/
http://caminao.wordpress.com/system-engineering/products-projects-processes/reuse/
Remy


On Aug 5, 1:50 am, mariem haoues <mariemho...@gmail.com> wrote:
> Hello everybody,
>
> As i know activity diagram can be used to represent a use case, and a use
> case can contain scenarios.
>
> Can we have more than one nominal scenario?
>
> Best regards.

[H. S. Lahman]

Responding to haoues...

 

As i know activity diagram can be used to represent a use case, and a use case can contain scenarios.

Can we have more than one nominal scenario?

Saying that an AD represents a use case in an OO context is actually very rarely true. Uses cases are often complex -- which is why they are divided into scenarios. As such a single use case may require behaviors from several different objects and, perhaps, several entire subsystems to execute. In such cases lots of objects and behavior responsibilities may be involved and the ADs just describe particular pieces of the use case.

As far as scenarios are concerned, unless you are building a tool that must interpret UML diagrams, my advice is not to get too hung up on technical definitions. Use cases are a form of requirements specification, so the Golden Rule that is relevant is: present the use cases in whatever form will be least ambiguous for the software developer. What matters in uses cases are the steps that need to be executed and their sequencing, not technical definitions of subdivisions.

A scenario is just a sequence of actions that can be associated, as a group, with a particular problem space context. Quite often one will use scenarios in conditional use cases to identify alternative sequences or sequences that are variants on a "main" or "primary" sequence. Some authors refer to the "main" sequence as the "nominal scenario" and the alternatives/variants as "variant scenarios". It really doesn't matter. What matters is that the UCD makes it clear what the sequences are and the conditions under which they are invoked. As long as the developers are not confused, you are good.

-- 
Life is the only flaw in an otherwise perfect nonexistence
   -- Schopenhauer

Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared.

H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html

[Ken Lloyd]

This gets to a fundamental point re: "what is a model?" (as in Unified
Modeling Language). A model is not one static immutable thing, but
represents a category of models in superposition that are played out
asynchronously, and of which scenarios are examples of one concern.

This makes entry level UML difficult to understand, so it is rightly avoided
for newcomers. But in the real world, software is developed for multiple
users, with multiple execution paths through the network graph that
represents its application. The nodes on that graph represent activities
(again, a category of possible action graphs).

So, the neophyte views UML models as one thing, and experts view them very
differently.

-----Original Message-----
From: umlf...@googlegroups.com [mailto:umlf...@googlegroups.com] On Behalf
Of RJB
Sent: Tuesday, August 07, 2012 3:34 PM
To: umlf...@googlegroups.com
Subject: [UML Forum] Scenarios in Activity Diagram

A scenario is a simple text description of one path through a use case. It
keeps things simple by not spelling out all the alternatives in one
scenario. But you can add extensions to a scenario that express alternatives
pathways. A well written use case organizes scenarios arround a particular
user need/goal.

The most useful things in the scenarios are the steps. Each step can be
expressed as a sequence diagram of messages inside the system, between the
objects, and so to the OO design.

An activity diagram is useful for sorting out complex logic. It is worrying
if you need an activity diagram to work out a scenario which should be
simple.

An activity diagram of a use case might sort out some logic, but before you
know it you've got a 1970's style structured design, or worse, spaghetti.

Another use for an activity diagram is expressing an algorithm. These tend
to appear as the implementation of a method/operation in a class.

--
You received this message because you are subscribed to the Google Groups
"UML Forum" group.
Public website: www.umlforum.com
To post to this group, send email to umlf...@googlegroups.com To
unsubscribe from this group, send email to
umlforum+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/umlforum?hl=en?hl=en

[H. S. Lahman]

Responding to Lloyd...

> This gets to a fundamental point re: "what is a model?" (as in Unified
> Modeling Language). A model is not one static immutable thing, but
> represents a category of models in superposition that are played out
> asynchronously, and of which scenarios are examples of one concern.
>
> This makes entry level UML difficult to understand, so it is rightly avoided
> for newcomers. But in the real world, software is developed for multiple
> users, with multiple execution paths through the network graph that
> represents its application. The nodes on that graph represent activities
> (again, a category of possible action graphs).

One could argue these comments apply to the entire OO paradigm. B-)

As you and Botting pointed out, somewhat more articulately than I did,
that UML complexity means that the semantics of things like ADs and
scenarios are dependent on where the observer is standing and what color
glasses are worn.