tamie message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Use Cse 3: LTS State diagrams: how much different from workflow diagrams?
- From: "Jacques R. Durand" <JDurand@us.fujitsu.com>
- To: <tamie@lists.oasis-open.org>
- Date: Mon, 18 May 2009 16:54:04 -0700
About Use Cse
3:
See the Flash
animated version of each pattern - neat.
LTS transcript: It
seems to me that we can't avoid having to use at least some extra-operators that
support the YAWL patterns, e.g. for synchronization /
merging.
In particular look
at the "Synchronizing Merge" pattern, in the Advanced
Patterns.
Consider some
approach discussed during F2F, for concurrent paths in the state diagram that
result from the "double ordering" pattern:
That solution above
seems tricky.
Now, one could argue
that a workflow diagram should not be confused with a state diagram. In
other words, in LTS the nodes are states, not activities. This means that our
"double order" pattern could be rightly modeled as below:
But the "pure state"
solution above cannot scale up to large LTS graphs, with many concurrent
(and long) paths.
It seems that we
need a state diagram that is close enough to a workflow diagram, and therefore
supports some of the split / merge ops.
That does not mean
we need specific eTSL ops to match these workflow ops.
But at least we'd
have enough information to translate into the right eTSL script (right
definition of CATCH, right combinations of scriplet
launches).
From my viewpoint, I
'd expect to have enough information in the LTS notation to allow automatic
translation into eTSL .
So a question is how
many of the YAWL patterns do we want to support?
I am pretty sure
that eTSL event-based features will allow for a clean implementation of even the
most advanced patterns ( Synchronizing
Merge...)
Jacques
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]