[Object Process Methodology](https://esml.technion.ac.il/opm/introduction-to-opm/) (OPM) is a framework for modeling systems. In software development, a sketch is an informal diagram that focuses on communication rather than completeness.
In 2008, Joe Gollner wrote a concise description of [Object Process Methodology](https://www.gollner.ca/2008/03/object-process.html): > The Object Process Methodology offers an astoundingly simple framework for modeling systems and scenarios of unlimited complexity. The root of its ability to do so lies in the fact that it departs from the prevailing fixation with Object Orientation (OO) which, in ultimately trying to represent the world using constructs relevant to software, inevitably spawns bewildering models as soon as it moves beyond anything more "real" than a software component. > The main departure that OPM makes, as its name suggests, is the elevation of "processes" to being peers to "objects". In the real world, there are _things_ and there are _things that happen to things_ and this basic decomposition of conceptual units fits reality to a tee. > So it is that whereas the full envelope of UML diagrams provides over 150 individual symbols, OPM manages to get by with literally a handful. This simplicity then makes a second major departure possible - the elimination of the litany of diagram types. In OPM, there is only one diagram type and only one integrated view. This is one major reason why business people can immediately grasp the contents of an OPM model.
Tools supporting OPM (i.e. [OPCAT](https://esml.technion.ac.il/opm/opcat-installation/), [OPCloud](https://www.opcloud.tech)) simultaneously edit an _Object Process Diagram_ (OPD) alongside _Object Process Language_ (OPL). This automation ensures correctness as the modeler views the relations expressed in the diagram with the precise meaning in the language. For subject matter experts not familiar with the meaning of every node (e.g. processes are ovals, objects are rectangles, states ar rounded rectangles) and edge (i.e. each arrowhead has a different meaning), some understanding is lost.
The OPM tools unfortunately create an OPD as a graphic image (e.g. JPG, PNG) separately from the OPL text. Marking up a read-only graphic image with text is unmaintainable.
In software development, sketching can be done on a whiteboard, while modeling is done separately in a tool. For the Unified Modeling Language (UML), Martin Fowler expresses the approach as [UmlAsSketch](https://martinfowler.com/bliki/UmlAsSketch.html): > Since sketching is pretty informal and dynamic you need to do them quickly and collaboratively, so a common medium is a white board. Sketches are also useful in documents, in which case the focus is communication rather than completeness. The tools used for sketching are lightweight drawing tools and often people aren't too particular about keeping to every strict rule of the UML. Most UML diagrams shown in books, such as mine, are sketches. Their emphasis is on selective communication rather than complete specification. Hence my sound-bite "comprehensiveness is the enemy of comprehensibility".
[Graphviz](https://graphviz.org/Gallery/directed/UML_Class_diagram.html), as implemented in Federated Wiki, enables labels (on nodes and edges) as internal links. Replicating an _Object Process Sketch_ from an OPM tool, and augmenting the arrowheads on edges with a label is an aim towards improving comprehensibility.