The OPM language
What is OPM
OPM, the Object-Process Methodology, is a modelling language standardised as ISO 19450. It describes any system, from a factory to a code review, with just two kinds of thing and a small set of links between them. Spoletta uses it as the language flows are drawn in.
Two kinds of thing
- Objects are things that exist: a ticket, a patch, a release, a person. An object can be in one of several states, such as
draftorapproved. On the board an object has square corners. - Processes are things that happen: they create objects, use them up, change them, or change their state. On the board a process is rounded.
That is the whole cast. Unlike flowcharts, which draw only the steps, or data models, which draw only the data, OPM puts both on the same diagram. A process means nothing without the objects it transforms, and an object only changes when a process acts on it.
Links say how they meet
Things are joined by links, in two families:
- Procedural links join a process and an object, and say what the process does to it: creates it, needs it, consumes it, changes it, or waits for it to enter a state. These drive a run. See Procedural links.
- Structural links join objects, and say what an object is made of or is a kind of. They give an object its shape. See Structural links.
One model, two views
Every OPM diagram can also be read as sentences of OPL, the Object-Process Language. The two say exactly the same thing: the diagram for seeing the whole at a glance, the sentences for checking each fact.
Editor is a person.
Post can be good or weak.
Review is a human process, which a person carries out.
Editor handles Review.
Review yields Post as good or weak, deciding which.
Managing size by zooming
Real processes have sub-steps. Rather than drawing everything on one huge diagram, OPM lets you zoom into a process: inside it is a diagram of its own. In Spoletta that is a flow process, and each level stays small enough to read. See Zooming in.
How Spoletta uses OPM
Spoletta keeps OPM's meaning and adds what a running system needs: each process has a kind saying who carries it out, each object holds JSON, a start node says where a run begins, and two plain connections between processes, next and on failure, cover ordering without data and exceptions. The pages that follow cover each construct in turn.