It is questionable whether this question really belongs here, but, in any case, it does not fit in Stack Overflow or any other Stack Exchange site. So here I go.

The purpose

My current pet project consists in developing a software tool to generate code from business process specifications.

The program's inputs are...

  • Process diagrams (very detailed ones, of course!)
  • User interfaces, if necessary, for those activities to be automated
  • Identification of interfaces with third-party programs, either already existing or to be constructed later

And the program's outputs are...

  • Table, view and stored procedure creation scripts
  • Application code (CRUD, information flow between processes/activities/users, etc.)

The problem

Well, I still do not know which process modeling notation I should use.

The alternatives

Personally, I like EPC (event-process chain) diagrams very much because of the simplicity of their structure:

  • The process flow must start with an event and must end with an event. If there are several alternative branches, this rule applies to all branches and possible flows.

  • Events may trigger zero or more activities. If they trigger zero activities, they are final events. If they trigger two or more activities, a branch opening must be used.

  • When completed, an activity must trigger exactly one event.

  • Activities may be triggered by one or more events. If they are triggered by two or more events, a branch closing must be used.

  • Everything else (i.e., anything that is not an event or an activity; e.g. personnel, resources, physical materials, information) can be added after completing the description of the process flow.

However, at least judging from other software developers I know, EPC diagrams are unpopular. Everyone else seems to be using BPMN, which are of course excellent for describing functional / responsibility aspects (i.e., who performs each activity), but are horrible for everything else, because the lanes get in the way.

The constraints

Other notations I know but have explicitly rejected are...

  • UML sequence diagrams: Because a diagram must be created for each alternative flow, the cost of which would be prohibitive for users of my tool.

  • IDEF: IDEF0 is great for mapping information flows, but IDEF3 is a horrible process flow notation: gotos should not be allowed at this level.

The questions

Which process notations have you used? Which one would you recommend me for my project?

  • If you've already rejected some notations, what does that mean? Does that mean you're hoping for confirmation of your choice? Or are you hoping for some other standard notation to surface?
    – S.Lott
    Commented Jul 6, 2011 at 15:06
  • The second one. I want something that is not as rejected as EPC, but allows the modeler to be just as precise.
    – isekaijin
    Commented Jul 6, 2011 at 15:09
  • I don't understand what you mean by "a diagram must be created for each alternative flow". UML provides mechanisms for showing alternative flows in the same diagram. Also, UML works quite well if your goal is to communicate your design to other developers. It falls flat on its face when you try to take it to the level of executable models and/or capturing every little detail. It also is not suitable for showing non-developers (for the most part) as their eyes glaze over quite quickly when you try. But as a way of documenting your design it works quite well.
    – Dunk
    Commented Jul 6, 2011 at 16:50
  • @Dunk: "UML works quite well if your goal is to communicate your design to other developers." My goal is to automate the development of programs whose only purpose is to provide an interface to CRUD operations or to shuffle data between tables. By taking developers out of the process, the design-validation-feedback loop becomes shorter, and the stage at which actual complex processes can be developed can be reached earlier.
    – isekaijin
    Commented Jul 6, 2011 at 17:24
  • Ah...ok then as I said UML does not work well for non-developers so ignore my previous comment.
    – Dunk
    Commented Jul 6, 2011 at 17:48

1 Answer 1


Which process notations have you used?


Which one would you recommend me for my project?


Graphical business process notation gets cluttered and difficult to work with when you start digging into real details.

We've evolved programming languages specifically because graphical notation is too coarse-grained to be really useful.

Essentially, business processes are a kind of programming language, and an existing language with a number of predefined classes and objects may be more clear than a mountain of pictures.

A clear DSL (not XML-based) may be more helpful than graphics.



(Yes, YAWL is XML-based, but it's not totally evil and one can fabricate a Python-like syntax for YAWL that builds XML and diagrams. No, I haven't done it, but it shouldn't be that hard.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.