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

> 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 want to clarify this point. The process definition is neither an activity
diagram nor a statechart diagram, but a graph of nodes (action) and sites
(graphs) that can represent all the information captured in either diagrams
and vice versa.

A user will typically not write process definitions as abstract graphs or as
XML text. They would select one visual notation to work with, or maybe even
switch from one model to another. The information is decoupled from the
visual notation, so you can begin to model something as an activity diagram,
switch to a statechart diagram, make some changes, switch back to an
activity diagram and make more changes, etc.

Creating a process definition (private or public) is an incremental process,
so you always start with something that is incomplete. You may start with a
use case diagram, list some of the information to get a base definition
there, then switch to a sequence of collaboration diagram and add more
details, then switch to an activity diagram and add more details, then go
back to the use case diagram to print it out.


> 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.

Most of them seem do prefer flowchart representation and in particular for
public processes since they can show roles on separate swimlines. But some
prefer statechart diagrams and even for private processes since they can
more easily list events and states. So there's no clear cut decision on
which visual notation works best, only that one is used more than the other.

arkin


>
> 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:50:50 UTC