Object-Process Methodology and its Applications for
Complex, Real-Time Systems Modeling
Dov Dori
Technion, Israel institute of Technology and
Massachusetts Institute of Technology
ABSTRACT
Function, structure, and behavior are the three main aspects that any conceivable system
exhibits. Function is the top-level utility that the system provides its beneficiaries who
use it or are affected by it, either directly or indirectly. The system’s function is enabled
by its architecture – the combination of structure and behavior. The system’s architecture
is what enables it to function so as to benefit its users.
Most interesting useful and challenging systems are those in which structure and
behavior are highly intertwined and hard to separate. For example, in a manufacturing
system, the manufacturing process cannot be contemplated in isolation from its inputs –
raw materials, model, machines, and operators – and its output – the resulting product.
The inputs and the output are objects, some of which are transformed by the
manufacturing process, while others just enable it. The situation with Pattern recognition
is not essentially different—here too, objects to be recognized and processes that enable
their recognition go hand in hand to the extent that trying to separate them is not just
incorrect, but it is also counterproductive.
Modeling of complex systems should conveniently combine structure and behavior in
a single model. Motivated by this observation, Object-Process Methodology (OPM) is a
comprehensive, holistic approach to modeling, study, development, engineering,
evolution, and lifecycle support of systems. Among many fields of application, it was
also applied to pattern recognition, as we describe below.
Employing a combination of graphics and a subset of English, the OPM paradigm
integrates the object-oriented, process-oriented, and state transition approaches into a
single frame of reference. Structure and behavior coexist in the same OPM model without
highlighting one at the expense of suppressing the other to enhance the comprehension of
the system as a whole.
Rather than requiring that the modeler views each of the system's aspects in isolation
and struggle to mentally integrate the various views, OPM offers an approach that is
orthogonal to customary practices. According to this approach, various system aspects
can be inspected in tandem for better comprehension. Complexity is managed via detail
levels, which are generated and traversed through by several abstraction/refinement
mechanisms.
Due to its structure-behavior integration, OPM provides a solid basis for modeling
complex systems in general and real time systems in particular. This paper provides an
overview of OPM, its ontology, semantics, and symbols. It then describes experiences
with recent modeling projects of real-time systems for industrial applications in Israel and
abroad. Finally, outlook into future R&D directions in OPM are presented.
Modeling Complex Systems with Object-
Process Methodology
Dov Dori
Technion, Israel Institute of Technology
and
Massachusetts Institute of Technology
Abstract. Object-Process Methodology (OPM) is a systems engineering approach to modeling,
development, and lifecycle support of complex, multidisciplinary systems. The basic premise of the OPM
paradigm is that objects and processes are two types of equally important classes of things. Objects are
(physical or informatical) things that exist, while processes are things that transform objects. Objects and
processes jointly specify the function, structure and behavior aspects of the modeled system within a single
framework in a domain-independent manner and without highlighting one aspect at the expense of
suppressing another. The model is described concurrently and interchangeably in graphics and text, both of
which are formal yet intuitive. OPM is supported by OPCAT—a commercial tool used in leading industries
and universities worldwide.
INTRODUCTION
Modeling of complex systems should conveniently combine structure and behavior in a single model.
Motivated by this observation, Object-Process Methodology OPM (Dori 1995, 2002) is a comprehensive,
holistic approach to modeling, study, development, engineering, evolution, and lifecycle support of
systems. OPM is an ontology- and systems theory-based vehicle for systems engineering and knowledge
representation that perfectly meets the formality and intuition requirements through a unique combination
of graphics and natural language. Most interesting useful and challenging systems are those in which
structure and behavior are highly intertwined and hard to separate. For example, in a manufacturing system,
the manufacturing process cannot be contemplated in isolation from its inputs—raw materials, model,
machines, and operators—and its output—the resulting product. The inputs and the output are objects,
some of which are transformed by the manufacturing process, while others just enable it.
Employing a combination of graphics and a subset of English, the OPM paradigm integrates the object-
oriented, process-oriented, and state transition approaches into a single frame of reference. Structure and
behavior coexist in the same OPM model without highlighting one at the expense of suppressing the other
to enhance the comprehension of the system as a whole. Rather than requiring that the modeler views each
of the system's aspects in isolation and struggle to mentally integrate the various views, OPM offers an
approach that is orthogonal to customary practices. According to this approach, various system aspects can
be inspected in tandem for better comprehension. Complexity is managed via the ability to create and
navigate via possibly multiple detail levels, which are generated and traversed through by several
abstraction/refinement mechanisms.
THE OPM ONTOLOGY
The elements of the OPM ontology, shown in Table 1, are divided into three groups: entities, structural
relations, and procedural links.
entities structural relations procedural links
Figure 1. The three groups of OPM symbols in the toolset of OPCAT 2
Entities, the basic building blocks of any system modeled in OPM, are of three types: stateful objects,
namely objects with states, and processes. As defined below, processes transform objects by (1) creating
them, (2) destroying them, or (3) changing their state. The symbols for these three entities are respectively
shown as the first group of symbols at the left hand side of Figure 1, which is the symbols in the toolset
available as part of the GUI of OPCAT 2 (Dori, Reinhartz-Berger et al. 2003).
Objects are (physical or informatical) things that exist, while processes are things that transform (create,
destroy, or change the state of) objects. Following is a set of basic definitions that build on top of each
other.
An object is a thing that exists.
Objects are the things that are being transformed in the system.
Transformation is generation (creation) or consumption (destruction) of an object, or a change of its state.
Processes are the things that transform objects in the system.
A process is a thing that represents a pattern of object transformation.
Table 1. Things of the OPM ontology and their basic attributes
Thing /
Symbol Description / OPL sentence
Attribute
A thing (entity) that has the potential of stable, unconditional physical or mental
existence.
Object
Object Name is an object.
A thing representing a pattern of transformation that objects undergo.
Process
Processing is a process.
An attribute that determines whether the thing (object or process) is physical
(shaded) or informational.
Essence
Processing is physical.
An attribute that determines whether the thing is environmental (external to the
system, dashed contour) or systemic.
Affiliation
Processing is environmental.
In OPL, bold Arial font denotes non-reserved phrases, while non-bold Arial font denotes reserved phrases.
In OPCAT, various OPM elements are colored with the same color as their graphic counterparts (by
default, objects are green, processes are blue, and states are brown).
Objects and processes are collectively called things. The first two lines of Table 1 show the symbol and
a description of the two types of OPM things. The next two lines show two basic attributes that things can
have: essence and affiliation.
Essence is an attribute that determines whether the thing is physical or informational.
The default essence is informatical. A thing whose essence is physical is symbolized by a shaded shape.
Affiliation is an attribute that determines whether the thing is environmental (external to the system) or
systemic.
The default affiliation is systemic. A thing whose affiliation is environmental is symbolized by a dashed
contour. Objects can be stateful, i.e., they may have one or more states.
A state is a situation at which an object can exist at certain points during its lifetime or a value it can
assume.
Stateful objects can be affected, i.e., their states can change.
Effect is a change in the state of an object.
Table 2. States and values
Symbol Description / OPL sentence
A situation at which an object can exist.
Stateful object with two
states
Website can be reachable or unreachable.
A value that an object can assume.
Value
Temperature is 15.
Stateful object with three A state can be initial, default, or final.
states: initial, default, and
final Car can be new, which is initial, used, which is
default, or junk, which is final.
OPM STRUCTURE MODELING
Structural relations express static, time-independent relations between pairs of entities, most often between
two objects. Structural relations, shown as the middle group of six symbols in Figure 1, are of two types:
fundamental and tagged. Fundamental structural relations are a set of four structural relations that are used
frequently to denote relations between things in the system. Due to their prevalence and usefulness, and in
order to prevent too much text from cluttering the diagram, these relations are designated by the four
distinct triangular symbols shown in Figure 1. The four fundamental structural relations are:
(1) aggregation-participation, a solid triangle, , which denotes the relation between a whole thing and its
parts,
(2) generalization-specialization, a blank triangle, , which denotes the relation between a general thing
and its specializations, giving rise to inheritance,
(3) exhibition-characterization, a solid inside blank triangle, , which denotes the relation between an
exhibitor – a thing exhibiting a one or more features (attributes and/or operations) – and the things that
characterize the exhibitor, and
(4) classification-instantiation, a solid circle inside a blank triangle, , which denotes the relation between
a class of things and an instance of that class.
Table 3 lists the four fundamental structural relations and their respective OPDs and OPL sentences.
The name of each such relation consists of a pair of dash-separated words. The first word is the forward
relation name, i.e., the name of the relation as seen from the viewpoint of the thing up in the hierarchy. The
second word is the backward (or reverse) relation name, i.e., the name of the relation as seen from the
viewpoint of the thing down in the hierarchy of that relation.
Each fundamental structural relation has a default, preferred direction, which was determined by how
natural the sentence sounds. In Table 3¸the preferred shorthand name for each relation is underlined. As
Table 3 shows, each one of the four fundamental structural relations is characterized by the hierarchy it
induces between the root—the thing attached to the tip of the triangle and the leaves—the thing(s) attached
to the base of the triangle, as follows.
(1) In aggregation-participation, the tip of the solid triangle, , is attached to the whole thing, while the
base—to the parts.
(2) In generalization-specialization, the tip of the blank triangle, , is attached to the general thing, while
the base—to the specializations.
(3) In exhibition-characterization, the tip of the solid inside blank triangle, , is attached to the exhibitor
(the thing which exhibits the features), while the base is attached to the features (attributes and
operations).
(4) In classification-instantiation, the tip of the solid circle inside a blank triangle, , is attached to the
thing class, while the base—to the thing instances.
Table 3. The fundamental structural relation names, OPD symbols, and OPL sentences
Structural Relation Name Root OPD with 3 OPL Sentences with 1, 2, and 3
Refineables refineables refineables
Forward Backward
Whole A consists of B.
Aggregation Participation A consists of B and C.
Parts A consists of B, C, and D.
Exhibitor A exhibits B.
Exhibition Characterization A exhibits B and C.
Features A exhibits B, C, and D.
General B is an A.
Generalization Specialization B and C are As.
Specializations B, C, and D are As.
Class B is an instance of A.
Classification Instantiation B and C are instances of A.
Instances B, C, and D are instances of A.
Table 3 lists the four fundamental structural relations and their respective OPDs and OPL sentences.
The name of each such relation consists of a pair of dash-separated words. The first word is the forward
relation name, i.e., the name of the relation as seen from the viewpoint of the thing up in the hierarchy. The
second word is the backward (or reverse) relation name, i.e., the name of the relation as seen from the
viewpoint of the thing down in the hierarchy of that relation.
Each fundamental structural relation has a default, preferred direction, which was determined by how
natural the sentence sounds. In Table 3¸the preferred shorthand name for each relation is underlined. As
Table 3 shows, each one of the four fundamental structural relations is characterized by the hierarchy it
induces between the root—the thing attached to the tip of the triangle and the leaves—the thing(s) attached
to the base of the triangle, as follows.
(1) In aggregation-participation, the tip of the solid triangle, , is attached to the whole thing, while the
base—to the parts.
(2) In generalization-specialization, the tip of the blank triangle, , is attached to the general thing, while
the base—to the specializations.
(3) In exhibition-characterization, the tip of the solid inside blank triangle, , is attached to the exhibitor
(the thing which exhibits the features), while the base is attached to the features (attributes and
operations).
(4) In classification-instantiation, the tip of the solid circle inside a blank triangle, , is attached to the
thing class, while the base—to the thing instances.
The things which are the leaves of the hierarchy three, namely the parts, features, specializations, and
instances, are collectively referred to as refineables, since they refine the ancestor, the root of the tree.
Refineable is a generalization of part, feature, specialization, and instance.
The third column in Table 3 lists for each fundamental structural relations the name of the root (whole,
exhibitor, general, class) and the corresponding refineables (parts, features, specializations, and instances).
The next column contains an OPD with three refineables, while the rightmost column lists the syntax of
three OPL sentences for each fundamental structural relation, with one, two, and three refineables,
respectively.
Having presented the common features of the four fundamental structural relations, in the next four
subsections we provide a small example for each one of them separately.
Aggregation-participation denotes the relation between a whole and it comprising parts or components.
Consider, for example, the excerpt taken from Section 2.2 of the RDF Primer (Manola and Miller 2003):
… each statement consists of a subject, a predicate, and an object.
This is a clear case of whole-part, or aggregation-participation relation. The OPM model of this
statement, which consists of both the OPD and the corresponding OPL, is shown in Figure 2. Note that the
OPL sentence, "RDF Statement consists of Subject, Predicate, and Object." which was generated by
OPCAT automatically from the graphic input, is almost identical to the one cited from the RDF Primer.
The same OPD exactly (disregarding the graphical layout) can be produced by inputting the text of the OPL
sentence above. This is a manifestation of the OPM graphics-text equivalence principle.
Figure 2. OPD of the sentence "RDF Statement consists of Subject, Predicate, and Object."
Generalization-specialization is a fundamental structural relationship between a general thing and one or
more of its specializations. Continuing our example from the RDF Primer (Manola and Miller 2003),
consider the very first sentence from the abstract:
The Resource Description Framework (RDF) is a language for representing
information about resources in the World Wide Web.
Let us take the main message of this sentence, which is that RDF is a language. This is exactly in line
with the OPL syntax, so we can input the OPL sentence “RDF is a Language.” into OPCAT and see what
we get.
The result, without any diagram editing, is shown in Figure 3, along with the conversation window titled
“Add new OPL sentence,” in which this sentence was typed prior to the OPD creation.
We continue to scan the RDF Primer (Manola and Miller 2003), where is Section 2.2.1 we find the
sentence
RDF has a simple data model.
To model this statement, we need to rephrase this sentence into the following three sentences:
1. RDF is characterized by a data model.
2. The data model of RDF is characterized by a complexity attribute.
3. The value of this complexity attribute is “simple.”
Figure 3. The OPD obtained by inputting into OPCAT the OPL sentence "RDF is a Language."
These three sentences are further rephrased to conform to the OPL syntax as follows:
1. RDF exhibits Data Model.
2. Data Model exhibits Complexity.
3. Complexity is simple.
Figure 4. The OPD representing the sentence “RDF has a simple data model."
Reading through the RDF Primer, we find in Section 3.3 on datatypes the sentence:
Datatypes are used by RDF in the representation of values, such as integers, floating point numbers,
and dates. … RDF predefines just one datatype, rdf:XMLLiteral, used for embedding XML in RDF.
An OPL interpretation of these two sentences, respectively, is:
1. RDF exhibits many Datatypes.
2. XMLLiteral is an instance of Datatype.
OPM BEHAVIOR MODELING
Procedural links connect entities (objects, processes, and states) to express dynamic, time-dependent
behavior of the system. Behavior, the dynamic aspect of a system, can be manifested in OPM in three
ways:
(1) A process can transform (generate, consume, or change the state of) objects,
(2) An object can enable a process without being transformed by it, and
(3) An object or a process can trigger an event that might, in turn, invoke a process if some conditions are
met.
Accordingly, a procedural link can be a transformation link, an enabling link, or an event link. In order to
be able to talk about object transformation, we need to first define state and demonstrate how states are
used. In Figure 6 we added to the object Check two states: The initial state uncashed and the final state
cashed. This causes the addition of the following OPL sentence to the OPL paragraph:
Figure 5. The OPM model of XMLLiteral, an instance of a Datatype of RDF
Figure 5 is the OPM model of XMLLiteral, an instance of a Datatype of RDF.
Check can be uncashed, which is initial, or cashed, which is final.
A transformation link expresses how a process transforms one or more objects. The transformation of an
object can be its consumption, generation, or state change. The transforming process is the transformer,
while object that is being transformed is called transformee.
Having added the states to the object Check, we can now show how the process Cashing affects Check by
changing its state. In Figure 7, Cashing was added and linked to the two states of Check: An input link
leads from the initial uncashed state to Cashing, while an output link leads from Cashing to the final state
cashed. The OPL sentence generated automatically by OPCAT as a result of adding these input and output
links is:
Cashing changes Check from uncased to cashed.
Figure 6. Adding states to Check
Sometimes we may not be interested in specifying the states of an object but still show that a process does
affect an object by changing its state from some unspecified input state to another unspecified output state.
To express this, we suppress (hide) the input and output states of the object, so the edges of the input and
output links “migrate” to the contour of the object and coincide, yielding the effect link shown in Figure 8.
The OPL sentence that represents this graphic construct is:
Cashing affects Check.
We have seen that one type of object transformation is effect, in which a process changes the state of an
object from some input state to another output state. When these two states are expressed (i.e., explicitly
shown), then we can use the pair of input and output links to specify the source and destination states of the
transformation. When the states are suppressed, we express the state change by the effect link, a more
general and less informative transformation link. State change is the least drastic transformation that an
object can undergo. Two more extreme transformations are generation and consumption, denoted
respectively by the result and consumption links. Generation is a transformation which causes an object,
which had not existed prior to the process execution, to become existent. For example, Check is born as a
result of a Check Making process.
Figure 7. The Cashing process changes the state of Check from the uncashed to cashed.
As Figure 9 shows, the object Check is generated as a result of executing the process Check Making. The
result link is the arrow originating from the generating process and leading to the generated object. The
OPL sentence that represents this graphic construct (shown also in Figure 9) is:
Check Making yields Check.
In contrast to generation, consumption is a transformation which causes an object, which had existed prior
to the process execution, to become non-existent. For example, Check is consumed as a result of a
Destroying process.
Figure 8. Suppressing the input and output states of Check cause the two link edges to migrate
to the contour of Check and coincide, yielding the single bidirectional effect link between Check
and Cashing.
Figure 9. The object Check is generated as a result of executing the Check Making process.
As Figure 10 shows, the object Check is consumed as a result of executing the process Destroying. The
consumption link is the arrow originating from the consumed object and leading to the consuming process.
The OPL sentence that represents this graphic construct (shown also in Figure 10) is:
Destroying consumes Check.
Figure 10. The object Check is consumed as a result of executing the Destroying process.
We sometimes wish to be specific and state not only that an object is generated by a process, but also at
what state that object is generated. Some other times, we might wish to be able to state not only that an
object is consumed by a process, but also at what state that object has to be in order for it to be consumed
by the process. As Figure 9 shows, the object Check is generated in its unendorsed state as a result of
executing the process Check Making.
Figure 11. The object Check is generated in its unendorsed state as a result of executing the
Check Making process.
The OPL sentence that represents this state-specified result link graphic construct (shown also in Figure
11) is:
Check Making yields unendorsed Check.
In comparison, the “regular,” non-state-specified result link is the same, except that the (initial) state is
not specified:
Check Making yields Check.
The difference is the addition of the state name (unendorsed in our case) before the name of the object
(Check) that owns that state. Analogously, a state-specified consumption link leads from a (final) state to
the consuming process. For example, assuming a check can only be destroyed if it is cashed, Figure 12
shows the state-specified consumption link leading from the final state cashed of Check to the consuming
process Destroying.
The OPL sentence that represents this state-specified consumption link graphic construct (shown also in
Figure 12) is:
Destroying consumes cashed Check.
APPLICATIONS OF OPM AND SUMMARY
OPM has been applied in many domains, including education (Dori & Dori, 1996), computer integrated
manufacturing (Dori, 1996A; Dori, Gal & Etzion, 1996), The R&D universe and its feedback cycles
(Myersdorf & Dori, 1997), real-time systems (Peleg & Dori, 2000), banking (Dori, 2001), requirements
engineering (Soffer, Golany, Dori & Wand, 2001), Web applications development (Reinhartz-Berger, Dori,
& Katz, 2002), ERP modeling (Soffer, Golany & Dori, 2001), axiomatic design (Soderborg, Crawley &
Dori, 2002), computational synthesis (Dori & Crawley, 2003), software reuse (Reinhartz-Berger, Dori, &
Katz, 2002), systems architecture (Soderborg, Crawley, & Dori, 2003), and Web Service Composition
(Yin, Wenyin, & Chan. 2004).
This paper has presented an overview of Object-Process Methodology and its applications in a variety of
domains. There are a number of important OPM-related issues that could not be discussed in detail in this
chapter due to space limitations. One such topic is complexity management. Complexity is managed in
OPM via in-zooming, unfolding, and state-expression, which provide for looking at any complex system at
any desired level of granularity without loosing the context and the "big picture." Another issue is the
systems development and evolution methodology with OPM, for which a comprehensive reflective
metamodel (which uses OPM) has been developed. These issues and others are treated in detail in the OPM
book (Dori, 2002).
Figure 12. The object Check is consumed in its cashed state as a result of executing the
Destroying process.
The domain-independent nature of OPM makes it suitable as a general, comprehensive, and
multidisciplinary framework for knowledge representation and reasoning that emerge from conceptual
modeling, analysis, design, implementation, and lifecycle management. The ability of OPM to provide
comprehensive lifecycle support of systems of all kinds and complexity levels is due to its foundational
ontology that builds on a most minimal set of stateful objects and processes that transform them. Another
significant uniqueness of OPM is its unification of system knowledge from both the structural and
behavioral aspects in a single diagram – OPD. It is hard to think of a significant domain of discourse and a
system in it, in which structure and behavior are not interdependent and intertwined. A third unique feature
of OPM is its dual knowledge representation in graphics and text and the capability to automatically switch
between these two modalities. Due to its single model, expressed in both graphics and text, OPM lends
itself naturally for representing and managing knowledge, as it is uniquely poised to cater to the tight
interconnections between structure and behavior that are so hard to separate.
OPM and its supporting tool OPCAT continue to evolve. The site www.ObjectProcess.org is a rich,
continuously updated resource of OPM-related articles, free software downloads, and more.
REFERENCES
1. Dori, D. (1994). Automated Understanding of Engineering Drawings: An Object-Oriented Analysis.
Journal of Object Oriented Programming, 35-43, Sept.
2. Dori, D. (1995). Object-Process Analysis: Maintaining the Balance between System Structure and
Behavior. Journal of Logic and Computation, 5(2), 227-249.
3. Dori, D. (1996A). Object-Process Analysis of Computer Integrated Manufacturing Documentation and
Inspection. International Journal of Computer Integrated Manufacturing, 9(5), 39-353.
4. Dori, D. (2001). Object-Process Methodology Applied to Modeling Credit Card Transactions. Journal of
Database Management, 12(1), 2-12.
5. Dori, D. (2002). Object-Process Methodology - A Holistic Systems Paradigm, Springer Verlag, Berlin,
Heidelberg, New York.
6. Dori, D., & Crawley, E. (2003). Towards a Common Computational Synthesis Framework with Object-
Process Methodology. 2003 AAAI Spring Symposium Series: Computational Synthesis: From Basic
Building Blocks to High Level Functionality, Stanford University, Stanford, CA, Technical Report SS-03-
02.
7. Dori, D., Gal, A., & Etzion, O. (1996). A Temporal Database with Data Dependencies: a Key to Computer
Integrated Manufacturing. International Journal of Computer Integrated Manufacturing, 9(2), 89-104.
8. Dori, D., & Dori, Y.J. (1996). Object-Process Analysis of a Hypertext Organic Chemistry Module. Journal
of Computers in Mathematics and Science Teaching, 15(1/2), 65-84.
9. IDEF Family of Methods. A Structured Approach to Enterprise Modeling and Analysis, 2001.
www.idef.com
10. Knowledge Interchange Format, 2001. http://logic.stanford.edu/kif/
11. Myersdorf, D.. & Dori, D.(1997). The R&D Universe and Its Feedback Cycles: an Object-Process
Analysis. R&D Management, 27, 4, 333-344.
12. Peleg M., & Dori, D. (2000). The Model Multiplicity Problem: Experimenting with Real-Time
Specification Methods. IEEE Transaction on Software Engineering, 26(8), 742-759.
13. Reinhartz-Berger, I., Dori, D., & Katz, S. (2002). OPM/Web – Object-Process Methodology for
Developing Web Applications. Annals of Software Engineering. 13, 141–161.
14. Reinhartz-Berger, I., Dori, D., & Katz, S. (2002). Open Reuse of Component Designs in OPM/Web. Proc.
IEEE 26th Annual International Computer Software and Applications Conference, 19-26.
15. Soderborg, N., Crawley E., & Dori D. (2002). System Definition for Axiomatic Design Aided by Object-
Process Methodology. Proc. 2nd International Conference on Axiomatic Design, Cambridge, MA, USA,
134-140.
16. Soderborg, N., Crawley E., & Dori D. (2003). OPM-Based System Function and Architecture: Definitions
and Operational Templates. Communications of the ACM, 46(10), 67-72.
17. Soffer, P., Golany, B., & Dori, D. (2003). ERP Modeling: A Comprehensive Approach. Information
Systems 28(6), 673-690.
18. Soffer, P., Golany, B., Dori, D., & Wand Y. (2001). Modeling Off-the-Shelf Information Systems
Requirements: An Ontological Approach. Requirements Engineering, 6, 183-199.
19. Wenyin L., & Dori, D. (1998). A Generic Integrated Line Detection Algorithm and its Object-Process
Specification. Computer Vision – Image Understanding (CVIU), 70(3), 420-437.
20. Wenyin L., & Dori, D. (1998A). Genericity in Graphics Recognition Algorithms. In Graphics Recognition
– Algorithms and Systems, Lecture Notes in Computer Science, K. Tombre and A. K. Chhabra (Eds.),
1389, 9-18.
21. Wenyin L., & Dori, D. (1999). Object-Process Based Graphics Recognition Class Library: Principles and
Applications. Software - Practice and Experience, 29, 15, 1355-1378.
22. Yin, L., Wenyin, L., & Changjun, J. (2004). Object-Process Diagrams as Explicit Graphic Tool for Web
Service Composition”, Journal of Integrated Design & Process Science: Transactions of the SDPS, 8(1),
113-127.
BIOGRAPHY
Dov Dori, PhD, is Associate Professor and Head of the Information Systems Engineering Area at the
Faculty of Industrial Engineering and Management, Technion, Israel Institute of Technology, and a
Research Affiliate at MIT, Cambridge. His research interests include Conceptual Modeling Systems
Development Methodologies, Information Systems Engineering, Computer-Aided Software Engineering
and Document Analysis and Recognition. Prof. Dori has developed Object-Process Methodology (OPM), a
holistic systems paradigm for conceptual modeling, presented in his 2002 book (by Springer). Prof. Dori is
Fellow of International Association for Pattern Recognition and Senior Member of IEEE, and he authored
over 100 journal publications and book chapters.
