RE: Same model for both Public and Private process ??

Assaf,

Yes, I agree that Activity Diagram is one of those richest model and other 
diagrams (state transition diagram, use case diagram, object interaction 
diagram ... etc) can be derived from it.  Another richest model is perhaps 
the "state transition diagram".  If so, then "activity diagram" is 
transformable to "state transition diagram" without losing information and 
vice versa.  I think we have no disagreement in this although I would like 
to see if anyone has proved this.

Besides "model completeness", another equally important aspect is which 
"model representation" fits better into the designer's mental model at 
different stages of the development process.  In most cases, developers are 
NOT going to spend all the energy to first work out the activity diagram 
and then derive the use case diagram, object interaction diagram ... etc. 
from there.

In your mail, are you making an assumption that the activity diagram (which 
has all details) has already exist first.  And then from which the designer 
arbitrarily take out information he consider to be implementation details, 
and then resulting in a "public process".

I suspect the business user you talk to (who favors the flowchart 
representation) are those who defines the implementation of private 
process.  If so, they are thinking "what should I do when I receive this 
message ?" and therefore a flowchart is definitely a better fit in their 
mental model.

For those who is defining the "public process", they are thinking about 
"what are the possible messages that I can receive now ?" and "what are the 
possible messages that I can send next ?".  These messages look more like 
an "event" rather than an "activity".  And the set of "possible events" is 
constrainted by the stage of the interaction, which seems to be a natural 
fit to being model as a "state".  Therefore I personally think a "state 
transition diagram" is a more natural fit to my mental model than a 
flowchart (which keep pushing me to think into too much detail).

But the fact that Rosetta PIP is expressed in an activity diagram may 
indicate my thoughts are wrong.  I would like to hear comments from those 
working on Rosetta PIP.

Best regards,
Ricky

At 09:10 PM 2/2/2003 -0800, Assaf Arkin wrote:
>Think of a process definition (external or internal) as being a multiple
>edge connected directed graph of activities. Let each node be a site that
>can further contain such a graph fully encapsulated within that site, with
>each graph forming a node in a tree of graphs under that site.
>
>(Long winded, but so far we have managed to represent the most complex
>processes that way)
>
>Define a visual notation as a visual representation of such a graph by
>transforming information captured in the graph into a collection of shapes,
>lines and textual captions. Two interesting properties:
>
>1. You can define any number of visual notations (transformations) and thus
>have any number of visual representations (views) of the same process
>definition
>
>2. You can capture all the information in a visual notation, but you can
>also have notations that capture some of that information (as much or as
>little as you want), yet the information is never lost!
>
>For example, since each node is associated with a role within a finite set
>of roles (e.g. with site of receiver denoting role), one could use the
>process definition to draw a use case diagram. Flows will not be expressed,
>but all the information depicted in the use case diagram could be derived
>directly from that graph.
>
>You could also represent this graph as a sequence diagram, collaboration
>diagram, activity diagram or statechart diagram. All the non-visual
>information required to construct these visual diagrams is captured in the
>graph, and you could have multiple views (diagrams) of the same graph.
>
>Talking to business users we have found out that flowcharts (activity
>diagrams of sort) are generically the most appealing visual notation.
>Statechart and sequence diagrams are preffered by some users and in some
>applications, flowcharts are simply a more widely understood notation.
>
>People think in terms of states and transitions, but they may find the
>step-oriented approach to be an easier way to express how these states and
>transitions come about. For most people it is easier to think in terms of
>"state where I do X, decision, state where I do Y" (flowchart) rather than
>"state in which X occurs, state in which Y occurs, a condition on transition
>from X to Y" (statechart).
>
>If written in English, a flowchart diagram would be written in the active
>voice, while a statechart diagram would be written in the passive voice.
>Business users tend to use the active voice more often, and that might be
>the only explanation for that perference.
>
>The process definition iself should be based on a formal model and allow
>both narratives to exist.
>
>arkin

Received on Monday, 3 February 2003 13:18:15 UTC