[UML Forum] Activity Diagram: Concept and clear traceability of data tokens

[maurice_t]

Hello,

my problem in modeling some workflows using activity diagrams is a
little hard to describe. It is concerned with the overview of which
action deals with the available data tokens. For example this
activity:

parameter: userId -> action: fetchUser -> action: print user ->
activity end

In this serial chain it is quite clear that an activity parameter is
injected which is used by the fetchUser action. The action produces a
User-Token that is printed.

But sometimes two things have to be done which could be solved
serially but this would mix up the data tokens and lessen the
clearness of the activity. Imagen, two Users shall be fetched,
compared and the 'better' one shall be printed. In a serial version it
would like this (p = parameter, a = action, o = object)

p: userId -> a: fetchUser1 -> a: fetchUser1 -> a: compareUsers -> o:
User[winner] -> a: printUser -> activity end

Rgis chain could be extended by much more objects that are loaded
(contracts, orders etc ..). If I got the token concept right, every
data token from each action reaches the printUser action, which can
use any of them on demand.

Sometimes I see that - apparently for reasons of clearness - such a
chain is forked although no real parallelism is intended:

_ a: fetchUser1 -
p: userId -> > -> a: compareUsers -> o:
User[winner] -> a: printUser -> activity end
- a: fetchUser1 -

So my questions are, did I get the token concept right? Is there any
preffered way of illustrating the data tokens of interest or is it
expected that the reader tracks _all_ data tokens, which were produced
and has to accept, that only some of them are used by the following
actions?

Please forgive the rough illustration of the activities, but I have no
tool at hand at the moment.

--
You received this message because you are subscribed to the Google Groups "UML Forum" group.
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.

[H. S. Lahman]

Responding to maurice_t...

> But sometimes two things have to be done which could be solved
> serially but this would mix up the data tokens and lessen the
> clearness of the activity. Imagen, two Users shall be fetched,
> compared and the 'better' one shall be printed. In a serial version it
> would like this (p = parameter, a = action, o = object)
>
> p: userId -> a: fetchUser1 -> a: fetchUser1 -> a: compareUsers -> o:
> User[winner] -> a: printUser -> activity end
>
> Rgis chain could be extended by much more objects that are loaded
> (contracts, orders etc ..). If I got the token concept right, every
> data token from each action reaches the printUser action, which can
> use any of them on demand.
>

The flows just represent algorithmic flow of control in the solution;
not data flows. (Interaction Diagrams are the closest UML notation to
classic DFDs, at least in an OO context.) The tokens are simply messages
and there is no specification of whether they have data packets. So your
diagram will work fine; it just implies that the fetch activities merely
store the data as object attributes so it can be conveniently accessed
by subsequent processes.

[In an OO context well-formed applications rarely pass data in behavior
collaboration messages. That's because OO methods are supposed to
navigate to whatever data they need themselves (in OOA/D; nonfunctional
requirements may dictate passing data during OOP). That makes data
integrity much easier to manage at OOP time for distributed or
concurrent implementations. So the only time data is passed in a message
is when requirements mandate special synchronization, such as grouping
sensor samples in a particular time slice.]

> Sometimes I see that - apparently for reasons of clearness - such a
> chain is forked although no real parallelism is intended:
>
> _ a: fetchUser1 -
> p: userId -> > -> a: compareUsers -> o:
> User[winner] -> a: printUser -> activity end
> - a: fetchUser1 -
>

This is actually the preferred way to do it because it is very clear
that the two fetches can be processed in parallel. In your first diagram
that cannot be assumed, even if it is true. That can be critically
important at OOP time if one implements the OOA/D model for concurrent
processing.

However, that is much less important today than it was two decades ago.
One now has MDA Marking Models to guide OOP for things like concurrent
processing when necessary. So today many developers don't bother with
fork/join just to specify concurrency opportunities and will only use
them for more obscure flow of control issues.

> So my questions are, did I get the token concept right? Is there any
> preffered way of illustrating the data tokens of interest or is it
> expected that the reader tracks _all_ data tokens, which were produced
> and has to accept, that only some of them are used by the following
> actions?
>

If you want to specify data packets you can do that in an Interaction
Diagram.

In fact, you really don't need ADs at all today, at least in OO
contexts. All you need are Class Diagrams, Component Diagrams, State
Charts, and an Abstract Action Language (AAL) for specifying behavior
responsibilities. Any translation transformation engine can
unambiguously generate correct 3GL or Assembler code from OOA models
using just those notations. (Though a transformation engine can generate
an Interaction Diagram automatically from the other diagrams for
documentation, white board IDs are useful for keeping track of things
when developing the other diagrams.)

Historically ADs were primarily used to describe behavior
responsibilities when UML was first introduced. However, they are
verbose and tend to be a pain to maintain (a new bubble always seems to
go in the middle of the densest part of the diagram). So they have been
largely replaced for describing methods by text-based AALs that were
introduced once OMG defined an execution meta model for UML.

Some people still use ADs to document large-scale processing; sort of
the Executive Summary overview of the processing. ADs are also central
to some non-OO development methodologies. But today subsystems are much
smaller and that sort of overview is no longer necessary, at least for
disciplined OO development.

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

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

[Maurice Huellein]

Thank you for your detailed answer. Especially the part about using AD at all was very interesting. At the moment I am using them very
extensive to describe workflows which are not yet modelled in terms of classes and methods. They shall picture the next level after Use
Cases, so which part takes (in general) an action or how (a very small number of) actors interact whith each other.
For this case I found Interaction Diagrams much to fine grained and very confusing if one actor/ life line executes mutiple actions in sequence.
But on the other hand I get quite fast at limits with AD when I try to interconnect different Activities by showing which parameters or data are
interchanged. This is where I am concerned about, whether a viewer of the diagram understands the flow of the data used by the actions

2010/5/20 H. S. Lahman <h.la...@verizon.net>

[H. S. Lahman]

Responding to Huellein...

> Thank you for your detailed answer. Especially the part about using AD
> at all was very interesting. At the moment I am using them very
> extensive to describe workflows which are not yet modelled in terms of
> classes and methods. They shall picture the next level after Use
> Cases, so which part takes (in general) an action or how (a very small
> number of) actors interact whith each other.

That's fine. It is really determined by the methodology that makes
things play together. Not everything in UML needs to be used in every
application; it is a hybrid notation intended to support quite different
construction approaches.

In this case what you describe is more Domain Modeling or a form of
requirements specification. So whatever works best in your environment
can't be bad. B-)