BPMN - Return values

[zigenz]

Hi all,

As my team's modelling exercise has progressed, we have increasingly been a little stupmed as to the best way to model return values.

For instance, there may be a high-level activity labelled "Process Payment".  This activity may contain a number of sub-activties, which ultimately result in either "Payment Successful" or "Payment Failed" (see following image).



Admittely it's terribly simplistic, but does this seem reasonable?  I want to ensure that I can translate this model to code at some point, so I want to make sure I get things right from the start.

Thanks all.

Z

[thomaskilian]

Hmm. I get a slight hickup when I hear "Transfer that model to code". How do you intent to create code and which at all? Are you going to create control code for your workflow machine or what? I think that all that BPML/BPEL stuff is still quite experimental.

Regarding your diagram: it looks reasonable. When you're done, there might be also a way to transform it to code.

I might be wrong, though.

[«Midnight»]

While I don't really agree with the word "experimental" in this context, I don't think you'll get too far trying to model system behavior in BPMN. There are tools that convert (some) BPMN into executable processes, but they are not deterministic enough to actually model low-level constructs such as individual function calls.

Perhaps something like SysML would be more effective for you here. SysML is quite new - at least in a standardized version, but seems to show great promise, at least for some development domains. In particular, it looks well suited to business applications, which might work for you.

Sparx does have a SysML add-in. It is not free, but available for a fee. However, there is a trial version.

David

[colinc]

In my understanding BPMN has no concept of a method call, function call, etc. whatever it is called in your language of choice. Instead you model everything as an explicit flow.

The reasoning is that it is fundamentally about business processes and workflow systems, that don't have these concepts.

There seems to be movement towards allowing the intermediate link event to be a 'gosub' rather than the current 'goto' in the next BPMN specification, in the meantime it's painful for system level modelling.