Object Process Methodology (OPM) is an approach to designing information systems by depicting them using object models and process models. OPM was conceived and developed by Prof. Dov Dori, at the Technion – Israel Institute of Technology. A paper that first presented ideas underlying OPM was published in 1995. The comprehensive resource is Dori's book Object-Process Methodology - A Holistic Systems Paradigm[1]
Contents |
Object-Process Methodology (OPM) is a modeling language. OPM combines a minimal set of building blocks – stateful objects and processes that transform them – with a dual graphic-textual representation in a single diagram type.
OPM uses two types of elements: entities and links. Entities are used to express "physical" or "informational" elements which can be inside or outside of the system being designed, i.e. "systemic" or "environmental".[1]
The entities used in OPM are objects, states and processes. An object is a thing existing for a period of time. A state is a situation an object can be in. A process is a phenomenon that transforms one or more objects by creating them, altering their states or destroying/consuming them.
The links used in OPM are structural links and procedural links. A structural link forms a relation between two objects and is persistent. A procedural link is used to link a process to an object - in which case it indicates a change in the state of the object - or to another process - in which case it indicates the launching of the second process when the first ends.
OPM supports cardinality constraints, meaning a way to indicate to what extent two objects can relate to each other. In OPM these constraints are called participation constraints. The following constraints can be formulated:
Objects, processes and links between them are depicted by using the Object Process Diagram (OPD).
The OPD treats complexity by using three refinement and abstraction mechanisms:
Having only one diagram, this methodology knows no multiplicity in depicting objects and processes, which improves exchangeability between different diagrams and even different methods.
The graphical representation of the OPM elements in an OPD is as follows:
| Object | An object is a thing that exists. | |
| Process | A process defines how objects are transformed. | |
| State | A state is an object's situation. |
| Symbol | |||
| Meaning | Relates a whole to its parts | Relates an exhibitor to its attributes | Relates a general thing to its specializations |
Example uses of the OPM structural links:
| Aggregation | A consists of B and C | |
| Exhibition | A exhibits B as well as C | |
| Generalization | B is an A. C is an A |
| Symbol | |||||
| Meaning | The source object/state is an agent of the target process | The source object/state is an instrument of the target process | The source/target process yields/consumes the target/source object | The source object is affected by the target process | The source process invocates the target process when it is finished |
Another feature of Object Process Methodology is the Object Process Language - an OPD can be translated in sentences, telling the storyline of the diagram. The power of OPL lies in the fact that it is readable by humans but also interpretable by computers, thus making it an inter-exchangeable language.
Modeling through OPM is possible with a specialized tool called Object-Process Case Tool.
The application has several strong features, which are listed below.
Further Use Case Maps (UCM) have some similar goals as OPM.[2]