Dov Dori (Auth.) - Model-Based Systems Engineering With OPM and SysML-Springer-Verlag New York (2016) PDF
Dov Dori (Auth.) - Model-Based Systems Engineering With OPM and SysML-Springer-Verlag New York (2016) PDF
Dov Dori (Auth.) - Model-Based Systems Engineering With OPM and SysML-Springer-Verlag New York (2016) PDF
Model-Based Systems
Engineering with
OPM and SysML
Model-Based Systems Engineering with OPM and SysML
Dov Dori
Springer Science+Business Media LLC New York is part of Springer Science+Business Media (www.springer.com)
Foreword
Architecting and engineering large, complex socio-technical systems, as well as gaining deep
understanding of existing natural and man-made systems, have eluded people for many years. Our
thinking about systems and their role in improving humans’ quality of life has evolved over the last two
decades. We now understand better that successful systems do not materialize in a haphazard way.
Rather, they must be carefully architected just like edifices, accounting for the needs, wants and
requirements of their intended beneficiaries, and alternative architectures—ways in which these desired
functions are embodied in form. These early decisions are critical to the system-to-be, as they determine
the concept to be followed and consequently the whole direction the system development takes and the
nature of the final outcome: how well the system performs in terms of delivering value, i.e., benefit at
cost, while maintaining the other requirements of safety, robustness, ease of use, environmental
friendliness, and many others.
As I was gaining these insights some 15 years ago, I realized that no matter how convincing your
ideas are, and how compelling are the arguments, there is only so much one can do with preaching and
hand-waving. It became obvious to me that making progress in the area of architecting and engineering
complex systems is contingent upon a solid foundation of language and methodology. It so happened,
that at that time, around year 2000, Dov stepped into my office, the office of the Head of the Aero-Astro
Department at MIT, with a draft of his first book, titled Object-Process Methodology—A Holistic Systems
Paradigm (Springer, 2002). Reading this draft in a plane I immediately understood that what I was
holding in my hands was exactly what I was looking for.
Object-Process Methodology (OPM) is a systems modeling paradigm that represents the two things
inherent in a system: its objects and processes. OPM is fundamentally simple; it builds on a minimal set
of concepts: stateful objects—things that exist, and processes—things that happen and transform objects
by creating or consuming them or by changing their states. This duality is recognized throughout the
community who studies systems, and sometimes goes by labels such as form/function, structure/function,
and functional requirements/design parameters. Objects are what a system or product is. Processes are
what a system does. Yet, it is remarkable that so few modeling frameworks explicitly recognize this
duality. As a result, designers and engineers try to jump from the goals of a system (the requirements or
the “program”) immediately to the objects. Serious theory in such disparate disciplines as software
design, mechanical design and civil architectural design all recognize the value of thinking about
processes in parallel with objects. Not only does OPM represent both objects and processes, but it
explicitly shows the connections between them.
OPM has another fundamental advantage—it represents the system simultaneously in formal graphics
and natural language. The two are completely interchangeable, conveying the exact same information.
The advantage in this approach lies in appreciating the human limitation to the understanding of
complexity. As systems become more complex, the primary barrier to success is the ability of the human
designers and analysts to understand the complexity of the interrelationships. By representing the system
in both textual and graphical form, the power of “both sides of the brain”—the visual interpreter and the
language interpreter—is engaged. These are two of the strongest processing capabilities that are hard-
wired into the human brain. Since each model fact is expressed both graphically and textually, in a subset
v
vi Foreword
of natural English, it is readily accessible to non-technical stakeholders, enabling them to take part in the
early, critical stages of the system architecting and development, in which the most important decisions
are made.
OPM allows a clear representation of the many important features of a system: its topological
connections; its decomposition into elements and sub-elements; the interfaces among elements; and the
emergence of function from elements. The builder of viewer of the model can view abstractions, or zoom
into detail. One can see how specification migrates to implementation. These various views are
invaluable when pondering the complexity of a real modern product system.
OPM semantics was originally geared towards systems engineering, as it can model information,
hardware, people, and regulation. However, in recent years OPM started to serve also researchers in
molecular biology, yielding tangible published new findings related to the mRNA lifecycle. This is a
clear indication of the universality of the object and process ontology: As it turns out, one can use this
minimal set of concepts to model systems in virtually any domain. Perhaps one exception is quantum
physics, where our macro notions of particle (object?) and wave (process?), as well as matter (object?)
and energy (process?) get fuzzy as we try to ‘inspect’ subatomic particles such as electrons. For any
system from the molecular level up, all the way to the most complex natural, socio-technical and societal
systems, the object-process paradigm works extremely well. OPM models concurrently explicate the
function (utility), structure (form) and behavior (dynamics) of systems in a single, coherent model that
uses one kind of diagram at any desired number of levels of detail by drilling down into the details of
processes hand-in-hand with the objects they transform. The set of these self-similar object-process
diagrams are represented not just visually, but also textually, catering to humans’ dual channel
processing, a key cognitive assumption of how we process information to convert it into actionable
knowledge.
Having realized the value of OPM to systems architecting and engineering, I adopted it in my thinking
and teaching, and it has become an important cornerstone of courses I have been teaching in systems
architecture at MIT and elsewhere. In particular, OPM has become a key element in the teaching of core
courses in the Systems Design and Management graduate program at MIT. I have used OPM in the SDM
System Architecture course. It has proved an invaluable tool to professional learners in developing
models of complex technical systems, such as automobiles, spacecraft and software systems. It allows an
explicit representation of the form/function duality, and provides an environment in which various
architectural options can be examined. The addition of OPM to my subject has added the degree of rigor
of analysis necessary to move the study of technical system architecture towards that of an engineering
discipline.
OPM is also used as a representational framework in the new book which I co-authored, System
Architecture: Strategy and Product Development for Complex Systems (Pearson, 2015), which
develops an approach to architecture and demonstrates it with examples ranging from pumps, circuits,
and sorting algorithms, to complex systems in networking and hybrid cars. Indeed, the task of
architecting and engineering a new system has become more complicated by the increasing number of
components involved, the number of disparate disciplines needed to undertake the task, and the growing
size of the organizations involved. Despite the common experience that members of many organizations
share, they often lack a common product development vocabulary or modeling framework. Such a
framework should be based on system science, be able to represent all the important interactions in a
Foreword vii
system, and be broadly applicable to electrical, informational, mechanical, optical, thermal, and human
components.
OPM provides such a framework. Indeed, in 2008, the task force of the International Council on
Systems Engineering (INCOSE) has recognized OPM as one of the six leading model-based systems
engineering methodologies. Looking at the historical development of engineering disciplines, it is an
appropriate time for such a rigorous framework to emerge. Disciplines often move through a progressive
maturation. Early in the history of an intellectual discipline, we find observation of nature or practice,
which quickly evolves through a period in which things are classified. A breakthrough often occurs when
classified observations are abstracted and quantified. These phases characterize much of the work done to
date in systems engineering and product development. Mature disciplines, such as mechanics, are well into
the era of symbolic manipulation and prediction. Maturing disciplines such as human genomics are in the
phase of symbolic representation.
OPM is a parallel development in symbolic representation of systems. Over the past two decades, the
understanding of the need for systematic modeling capability has broadened. As OPM was developed in
response to this growing recognition, so have other approaches. The most notable of these are UML,
which includes 13 kinds of diagrams, geared for software engineering, and its derivative, SysML, which
includes nine kinds of diagrams, designed more generally for systems engineering. Both SysML and
OPM are listed as leading standards in the Guide to the Systems Engineering Body of Knowledge
(SEBoK), an online ongoing project jointly sponsored by the Systems Engineering Research Center
(SERC), the International Council on Systems Engineering (INCOSE), and the Institute of Electrical and
Electronics Engineers Computer Society (IEEE-CS).
SysML and OPM represent two different approaches to system modeling. In SysML up to nine
diagrams are used, which are independently derived, and may not be completely consistent. In OPM one
main diagram emerges. The need to integrate several kinds of diagrams may be more complicated. I make
the distinction between complexity—the inherent fact that a system contains many parts interacting in
multiple, often inexplicable ways, and complicatedness—the way a system model is presented through a
certain modeling language and is perceived by a user. While there is not much we can do to reduce
systems’ inherent complexities, we can and should strive to reduce the complicatedness of the
representation to the bare necessities without sacrificing accuracy and details. OPM with its minimal
ontology of stateful objects and processes favorably responds to this challenge.
While the emphasis of the book is on OPM, because of the relatively wider spread use of SysML, Dov
has included SysML with adequate presentation of its syntax and semantics, as well as synergies with
OPM, comparison with OPM in terms of such factors as length of the standard specification, and ways
OPM can replace many SysML diagram kinds with a single diagram kind. The coverage of both
languages in the same book is unique, as Model-Based System Engineering (MBSE) books to date have
mostly used SysML. This dual coverage of OPM and SysML is highly valuable, since the reader gets
deeper perspective on MBSE that penetrates beneath the idiosyncrasies of a particular conceptual
modeling language.
I recommend using this textbook for an intermediate or advanced course in model-based system
engineering, product development, engineering design, and software engineering. It would be ideal for
courses that attempt to show how various disciplines come together to form a multi-disciplinary product.
With OPM now formally recognized as an ISO specification, it can form the backbone of a corporate or
viii Foreword
enterprise modeling framework for technical products and large-scale socio-technical systems. Such a
representation would be especially valuable in conceptual and preliminary design, when much of the
value, cost and risk of a product are established, but when few other modeling frameworks are available
for decision support.1
Professor Edward Crawley Massachusetts Institute of Technology, July 2015
1
Edward Crawley is the Ford Professor of Engineering and a Professor of Aeronautics and Astronautics at MIT. He is
a member of the U.S. National Academy of Engineering and serves as the President of the Skolkovo Institute of
Science and Technology in Moscow. Prof. Crawley is the first author of two recent books: “System Architecture:
Strategy and Product Development for Complex Systems” and “Rethinking Engineering Education, the CDIO
Approach”.
Preface
The quest for simplicity in a complex world has occupied thinkers for millennia. How to conceptualize
what humans observe around them and what they wish to design in order to improve the quality of
people’s lives has been one of the major driving forces in advancing civilization. The advent of
computers in the middle of the previous century was a great impetus to fostering thoughts about how to
conceptually represent things in the real world. The initial accepted train of thought produced procedural
programming, which put procedures, routines, functions, etc. at the center of programming. Further
contemplations have led to the idea of putting objects, which are more static in nature, as the anchor of
programs. The shift to the object oriented (OO) paradigm for programming languages, which occurred in
the 1980s and 1990s, was followed by the idea that programming should be preceded by analysis and
design of the programs, or, more generally, the systems those programs represent and serve. Naturally,
the approach which was taken is also object-oriented.
In the early 1990, a plethora of some three dozen object-oriented analysis and design methods and
notations flourished, leading to what was known as the “Methods War”. Around that time, in 1991, when
I moved from University of Kansas to Technion, Israel Institute of Technology, as I was tasked with
teaching software design, I got interested in these topics. It was not long before I realized that just as the
procedural approach to software was inadequate, so was the “pure” OO approach, which puts objects as
the sole “first class” citizens, with “methods” (or “services”) being their second-class subordinate
procedures. However, I could not put my finger on what was missing.
My Eureka moment was in 1993, when I and colleagues from University of Washington were trying
to model a system for automated transforming of hand-made engineering drawings to CAD models, a
topic around which my research focused during that time. Drawing objects as the model’s building blocks
and connecting them on the white board, it dawned on me that not all the boxes in the model were really
objects; some were things that happen to objects. When I circled those things, a pattern of a bipartite
graph emerged, where the nodes representing objects—the things that exist—were mediated by those
circled nodes, which I immediately called processes. This was the first object-process diagram (OPD)
ever drawn. I realized then that the pendulum of the previously accepted procedural software to the
primarily static OO paradigm moved too drastically. While the shift from procedures to objects as the
focus of interest was a right move, it went too far, as it suppressed the systems’ procedural aspect, which
is essential to faithfully describe how systems change over time.
Forbidding processes, such as cake baking or check cashing, from being conceptual entities in their
own right, and allowing their representation only as methods of object classes, results in distorted models,
in which a check “owns” the cashing method or the cake owns the baking process. In real life, however,
baking is a pattern of transformation of ingredients making up the dough that requires a baker, an oven,
and energy to prepare the dough and convert it into a cake. Similarly, a check cannot cash itself; it
requires a check writer having an account with sufficient funds, a check casher, and a bank clerk or an
ATM. Each of the objects involved in these methods could just as well be the owner of the method.
Modeling baking and cashing as stand-alone processes—conceptual things that represent physical or
informatical object transformation patterns—open the door for creating models that are much more
faithful to the way we conceive reality and convey it to others.
ix
x Preface
Indeed, recognizing processes as bona fide conceptual modeling building blocks beside, rather than
underneath objects, is the prime foundation of Object-Process Methodology (OPM). OPM is founded on
a universal minimal ontology, according to which objects exist, while processes transform them.
Transformation includes object creation and consumption, as well as change of the state of an object.
Therefore, OPM objects are stateful—they can have states. Hence, stateful objects and processes that
transform them are the only two concepts in OPM’s universal minimal ontology. Two other cornerstones
of OPM are its bimodal graphical-textual representation and its built- in refinement-abstraction
complexity management mechanisms of in-zooming and unfolding of a single type of diagram—OPD.
When I tried to publish a paper titled “Object-Process Analysis: Maintaining the Balance between
System Structure and Behavior” with the buds of these ideas in 1993, it was serially rejected off hand
with claims along the line that it had already been proven that what I was suggesting is impossible, like
“mixing water with oil.” Finally, the Journal of Logic and Computation accepted it, perhaps because
being mathematics- rather than software-oriented, it was more tolerant toward ideas that went against the
then new and glorious OO paradigm.
Meanwhile, in 1997, the “Methods Wars” culminated in the adoption of the Unified Modeling
Languages (UML), by the Object Management Group (OMG), making it the de-facto standard for software
design. UML 1 had nine types of diagrams. In 2000, when I attended a Technical Meeting of OMG in
which UML was considered for progression from version 1 to 2, I proposed considering UML for being
extended to handle not just software systems, but systems at large, a proposal that was dismissed off-hand
by most attendees, who were software people. However, following a 2001 initiative of the International
Council on Systems Engineering (INCOSE), in 2003 OMG issued the UML for Systems Engineering
Request for Proposals, and in 2006 OMG adopted SysML (Systems Modeling Language) 1.0
specification, which is based on UML 2. Since then, SysML has become the de-facto standard for
systems engineering.
Meanwhile, the first book on OPM, Object-Process Methodology—a Holistic Systems Paradigm,
(Dori, 2002) was published, and OPM has been successfully applied and papers published in many
diverse domains, ranging from the Semantic Web to defense and to molecular biology. In December 2015,
after six years of work, ISO adopted and published OPM as ISO 19450—Automation systems and
integration—Object-Process Methodology.
The realization and recognition that models can and should become the central artifact in system
lifecycles has been gaining momentum in recent years, giving rise to model-based systems engineering
(MBSE) as an evolving filed in the area of systems engineering. SysML and OPM have been serving as
the two MBSE languages, but since SysML was adopted as a standard about eight years before OPM and
has been backed by top-notch vendors, its adoption is currently more widespread. However, OPM is
rapidly gaining acceptance in academia and its application in diverse industry segments is spreading.
This textbook, designed for both self-learning and as an undergraduate or graduate course, endows its
readers with deep understanding of MBSE ideas, principles, and applications through modeling systems
using both OPM and SysML. The book is comprised of three parts that encompass 24 chapters. Each
chapter ends with a bulleted summary and a set of problems. Solutions to problems may be available in
http://esml.iem.technion.ac.il/.
Part I introduces OPM and SysML via step-by-step modeling of a car automatic crash response
system. Chapter 1 starts with a description of the system and its initial OPM model. In Chap 2 we
enhance the model with text and animated simulation. Chapter 3 introduces links that connect things in
Preface xi
the model. In Chap. 4 we introduce and use SysML’s first three diagrams. Chapter 5 presents ways for
managing the complexity of systems, while the dynamic aspect of the system is modeled in Chaps. 6 and
7. Abstraction and refinement mechanisms as means to manage complexity are the focus of Chap. 8, the
last chapter in Part I.
Part II, Model-Based Systems Engineering Fundamentals, is a formal, theory-grounded exposure to
OPM and SysML that discusses MBSE ontology, conceptual modeling constructs, and applications.
Chapter 9 introduces and defines conceptual modeling. Chapter 10 presents the two basic building blocks
of OPM—objects and processes, while Chap. 11 is about the textual modality of OPM—OPL. In Chap.
12 we turn to an orderly study of SysML with its four pillars and nine kinds of diagrams. The dynamic,
time-dependent aspect of systems is the focus of Chap. 13, followed by studying the structural, time-
independent system aspect in Chap. 14. Following Chap. 15, which deals with participation constraints
and fork links, in Chap. 16 we introduce the four fundamental structural relations.
In Part III, Structure and Behavior: Diving In, we go to the heart of conceptual modeling, elaborating
on the four fundamental structural relations and whole system aspects, including complexity management
and control. Chapters 17 and 18 discuss aggregation-participation and exhibition-characterization,
respectively. Chapter 19 is about states and values, concepts that are needed for generalization-
specialization and classification-instantiation, both of which are elaborated on in Chap. 20. Chapter 21
concerns complexity management and the refinement-abstraction mechanisms of OPM, as well as
complexity management in SysML. Chapter 22 is about OPM operational semantics and control links—
the way control is managed during execution of the system. In Chap. 23 we specify how to model logical
operators and probabilities. Finally, Chap. 24 is an overview of ISO 19450—Automation Systems and
Integration—Object-Process Methodology, adopted by the International organization for Standardization
in December 2015.
With respect to OPM, this book can be considered a superset of ISO 19450. While OPM, as specified
in this book, is ISO 19450-complaint, the book provides in-depth motivation, rationale, and philosophical
foundations for decisions made during the design of ISO 19450. These cannot be elaborated on in a
standard, which, by its nature, is expected to be short and decisive, with little justifications. OPM points
in the book that are not covered in ISO 19450 can be considered optional, or, in ISO nomenclature,
informative, as opposed to normative—abiding ISO specifications.
This book is a product of six years of work, during which I have made all efforts to make it accurate,
consistent, and formal, while also not lose the human touch and the interest of the future reader. It is my
sincere hope that the book will serve as a reliable reference to MBSE in general and to OPM and SysML
in particular.
xii Preface
Examining the above word cloud of this book (created by a program developed skillfully by Jason
Davies),2 based on close to 140,000 words contained in this book, we can see that the most frequent
words are process, object, and link. Indeed, this is a most faithful testimony that OPM focuses on how to
model systems (two other most frequent words in the cloud) by relating processes to objects using links.
Relation is there too, along with other notable words, including diagram, attribute, structural,
procedural, semantics, state, control, change, effect, agent, time, constraint, and function. Of course,
SysML is there between process and model, near OPD (Object-Process Diagram—OPM’s graphical
modality) and OPL (Object-Process Language—OPM’s textual modality). This list gives a good idea of
what this book is about.
I wish to thank my three MIT collaborators, Prof. Ed Crawley and Prof. Oli de Weck from
Engineering Systems Division and the Aero-Astro Department, and Pat Hale, Director of Systems Design
and Management Program. Special thanks to my PhD student, Yaniv Mordecai, who provided insightful
comments on many of the chapters in this book. I thank the Technion, Israel Institute of Technology,
which provided me with the environment to develop OPM and with the 2013-4 sabbatical to complete
this book. Finally, I wish to thank my beloved wife, Prof. Judy Dori, who provided pedagogical guidance
and moral support, which made it possible for me to finish the book.
Dov Dori Massachusetts Institute of Technology, July 2015
2
https://www.jasondavies.com/wordcloud/
Table of Contents
xiii
xiv Table of Contents
Informatical
(flat)
essence
Physical
(shaded)
Systemic
(solid)
affiliation
Environmental
(dashed)
Textual –
Object-Process Whole consists of Exhibitor exhibits Specialization is a Instance is an instance of
Language (OPL) Part. Attribute. General. Class.
xxi
xxii Main ISO 19450-compliant OPM Symbols
State Changing
Creating yields Affecting affects changes Affectee from
Consuming consumes
Resultee. Affectee. input state to output
Consumee.
state.
Processing requires
Agent handles
Instrument.
Processing.
This book focuses on conceptual systems modeling with OPM—Object-Process Methodology, and
SysML—Systems Modeling Language. SysML is an accepted de-facto standard of the Object
Management Group (OMG) since 2006, while OPM has become ISO 19450 publically available
specification in 2014. Leaving theoretical background and discussions to Part II and detailed technical
specifications to Part III, this first part introduces OPM and SysML via a running case study of a car
automatic crash response system that we model step-by-step, exposing modeling principles and practices
as we go. Chapter 1 starts right away with a description of the system to be modeled and an initial, gentle
OPM model. In Chap. 2 we enhance the model with text and animated simulation. Chapter 3 introduces
links that connect things in the model. In Chap. 4 we pause modeling the automatic crash response
system with OPM and move to introducing and using SysML's first three diagrams: Use case, block, and
state machine diagrams. Resuming modeling the system with OPM, Chap. 5 will expose us to in-
zooming—the most powerful refinement mechanism that enables managing the complexity of systems.
The dynamic, behavioral, time-dependent aspect of the system is the topic of Chap. 6. In Chap. 7, we are
exposed to specifics of controlling the system's behavior. Deepening our knowledge about abstraction
and refinement mechanisms as means to manage complexity is the focus of Chap. 8, the last one in Part I.
Chapter 1
Ready to Start Modeling?
…all models are wrong; the practical question is how wrong do they have
to be to not be useful.
Box and Draper (1987)
With diagrams the meaning is obvious, because once you understand how
the basic elements of the diagrams fit together, the meaning literally
stares you in the face.
1
http://cms.cerritos.edu/auto/basic-its/ost.htm.
sufficient severity. Regardless of whether the air bags deploy, the SDM transmits crash
information to the vehicle’s OnStar module.
Within seconds of a moderate-to-severe crash, the OnStar module will send a message to the
OnStar Call Center (OCC) through a cellular connection, informing the advisor that a crash has
occurred. A voice connection between the advisor and the vehicle occupants is established. The
advisor can then conference in 911 [emergency] dispatch or a public safety answering point
(PSAP), which determines if emergency services are necessary. If there is no response from the
occupants, the advisor can provide the emergency dispatcher with the crash information from
the SDM that reveals the severity of the crash. The dispatcher can identify what emergency
services may be appropriate. Using the Global Positioning System (GPS) satellite, OnStar advisors
are able to tell emergency workers the location of the vehicle.
The “big picture” that emerges from this system description is that the ACR system aims to provide
an automatic response in case of a severe car crash. In the following sections we methodically model this
system using OPM and then SysML.
2
This is the first of 13 OPM principles, which are listed throughout the book in a frame and also appear at the end of
the book for quick reference after Chap. 24 under the heading “OPM Principles at a Glance”.
Dori – Model-Based Systems Engineering with OPM and SysML 5
regarding the function often provokes a debate between the system architecture team members at this
early stage, but this is highly valuable. Such discussions frequently expose differences and often even
misconceptions among the participants regarding the system that they set out to architect, model, and
design. Thus, agreement on the system’s function and its most appropriate name increases the likelihood
of ending up with a useful model.
Figure 1.1 describes the Automatic Crash Responding process in OPM notation using OPCAT,3 an
OPM-based modeling software environment such as OPCAT (Dori et al. 2003). It is highly recommended
that the reader installs OPCAT and follows the modeling activities presented here.
Based on the definition of a process as a thing that transforms an object, no process is meaningful
unless it transforms at least one object. That object is known as the transformee of the transforming
process or the operand of the system’s function.
Fig. 1.2 Vehicle Occupants Group is added as an object to the Automatic Crash Responding process
3
The object-process diagrams (OPDs) in this book were drawn using OPCAT, a software environment that enables
OPM-based modeling. OPCAT can be downloaded and installed free from http://esml.iem.technion.ac.il/, a website
that also contains an OPCAT hands-on tutorial and many articles on OPM. OPCAT tutorial is also found on that site.
Dori – Model-Based Systems Engineering with OPM and SysML 7
transformation does the Vehicle Occupants Group undergo? To answer this question, we examine the
following definition of transformation.
Fig. 1.3 An effect link is added between the Automatic Crash Responding process and the Vehicle Occupants
Group object, indicating that the process affected (changed the state of) the object
Our model currently contains three elements. The first is the Automatic Crash Responding process,
the second is the object Vehicle Occupants Group, and the third is the link between the process and the
object.
1.6 Summary
We have started modeling the Automatic Crash Responding system using OPM.
OPM has a single diagram type: the object-process diagram (OPD).
OPM is built of objects, which exist, and of processes, which transform objects.
Object transformation is object creation, object consumption, or object change.
8 Ready to Start Modeling?
1.7 Problems
An engineering student was asked to sketch a graphical representation of the system of garbage recycling
came up with the sketch in Fig. 1.4.
8. Add the beneficiary to the OPD as an object and link it to the process defined as the system’s
function.
9. Identify the operand of the system’s function.
10. Add the operand to the OPD and link it to the process.
Identify other main objects that the process affects, add them to the OPD, and link them to the
process.
Chapter 2
Text and Simulation Enhancements
We went next to the School of Languages. … The first Project was to shorten
Discourse by cutting Polysyllables into one, and leaving out Verbs and Participle,
because in Reality all things imaginable are but Nouns. … However, many of the most
Learned and Wise adhere to the new Scheme of expressing themselves by Things.
Jonathan Swift, Gulliver’s Travels (1726)
Winograd and Flores (1987) noted that “Nothing exists except through language… In saying that some
‘thing’ exists (or that it has some property) we have brought it into a domain of articulated objects and
qualities that exist in language.”
Indeed, language greatly enhances our ability to understand systems and communicate our
understanding to others. This chapter presents two enhancements to OPM models: textual model
representation and animated model simulation.
We introduce the object-process language (OPL) as the textual modality of OPM that complements
the graphical representation through OPDs (object-process diagrams). We show the equivalence between
this graphical specification and the natural language specification through OPL. The chapter also shows
another important means of enhancing model understanding: its animated simulation.
This is a clear and unambiguous sentence in plain English that was generated immediately, in
response to the modeler linking the two things, and it explains what OPCAT has “understood” from this
operation.
Figure 2.1 shows a partial screenshot of OPCAT. The top pane contains the OPD and the bottom
contains the OPL sentence generated in response to the modeler’s insertion of the effect link.
In OPCAT, the default color of OPL words or phrases (word sequences) that represent objects is
green; this is the same color as the corresponding object boxes in the OPD. Likewise, the default color of
phrases representing process names in OPL is blue, which is also the color of the corresponding process
ellipses.
The graphics-text conversion is a two-way street: just as it was possible to extract the OPL paragraph
above from the OPD in Fig. 2.1, that OPD can be reconstructed from its OPL paragraph; that is, the
collection of OPL sentences that specify in text what the OPD specifies in graphics. As an exercise, the
graphics-text equivalence principle can be verified by reconstructing Fig. 2.1 versa. It is easier to edit the
graphics and get the immediate textual feedback.
Fig. 2.1 A screenshot of OPCAT showing the OPD on top and the first object-process language (OPL) sentence
generated in response to the modeler’s insertion of the effect link
The ability to switch back and forth between graphics and text means that OPM system specification
writers and modelers are less likely to make costly design errors. Moreover, readers of the textually
specified model are more likely to fully comprehend the system and detect mistakes or omissions. The
specification reader can fill gaps in his or her understanding of the system that may have formed while
examining one modality by looking at the other one. In doing so, the reader reinforces familiarity with the
specification and can more easily detect design errors or omissions.
A state is a situation or position at which an object can be, or a value it can assume,
for some positive amount of time.
Since states are possible situations or values of an object, they have no “life” of their own; they have
meaning only in the context of the object to which they belong and within which they reside.
Automatic Crash
Responding
Fig. 2.2 The states of Vehicle Occupants Group are added: possibly injured is the input state and being helped is
the output state
In order to be specific about the effect that the Automatic Crash Responding process has on the
Vehicle Occupants Group object, we first need to come up with appropriate names for the states of this
object, both before and after the occurrence of the process. Immediately after the crash, the Vehicle
Occupants Group is possibly injured; after Automatic Crash Responding, they are being helped. These
are the corresponding input and output states of the Vehicle Occupants Group object with respect to the
Automatic Crash Responding process.
Figure 2.2 shows the OPD after adding the two states of Vehicle Occupants Group, with possibly
injured being the input state and being helped—the output state. The symbol of state is a rounded corner
rectangle—rountangle1 for short—that encloses the state name, which starts with a lower-case letter. The
state symbol is drawn inside the rectangle of the object that “owns” the state. This adding of states
created the following new OPL sentence:
Vehicle Occupants Group can be possibly injured or being helped.
1
This term was coined by D. Harel.
14 Text and Simulation Enhancements
OPL sentences in this book are written in Arial font. Reserved phrases, such as “can be”, are in regular
font while all the rest (including commas and periods) are in bold font.
Fig. 2.3 The effect link in Fig. 2.2 is replaced by an input-output link pair that explicates the change of state of the
Vehicle Occupants Group from the possibly injured input state to the being helped output state
The arrow from the input state to the process is the input link, and the arrow from the process to the
output state is the output link. Together, these two links constitute the input-output link pair. In response
to this editing of the model, the previous OPL sentence, “Automatic Crash Responding affects Vehicle
Occupants Group.”, is replaced by the following OPL sentence:
Automatic Crash Responding changes Vehicle Occupants Group from possibly injured to being helped.
By specifying the affecting process and the affected object with its input and output states, this
sentence accurately reflects the details of the dynamics of the system.
As noted, the convention is that, unlike names of things (objects or processes), which have a capital
letter at the start of each word, state names are always written in lower case. More descriptive names,
Dori – Model-Based Systems Engineering with OPM and SysML 15
such as “possibly injured” or “being helped”, as in our case study, should be given. It is important to
check that the resulting OPL sentence makes sense.
Fig. 2.4 Executing the OPM model shown in the OPD of Fig. 2.3. Left: the system before the Automatic Crash
Responding process starts. Center: the process in action; the object is in transition from its input state to its output state.
Right: the system after the Automatic Crash Responding process has terminated
The screenshot in the center of Fig. 2.4 shows the process in action, marked as solid (colored blue).
During the time that the Automatic Crash Responding process is active (that is, when it executes), the
object Vehicle Occupants Group is in transition from its input state, possibly injured, to its output state,
being helped. This is marked by both states being semi-solid (light brown).
Observing the animation in action reveals that the input state gradually fades out while the output
state becomes solid. At the same time, two red dots, shown in the middle of both arrows, travel along the
input-output link pair, denoting the “control” of the system; that is, where the system is at each time
point. One red dot travels from the input state to the affecting process. At the same time, the second dot
travels from the process along the output link to the output state. Finally, the screenshot on the right
shows the system after the Automatic Crash Responding process had terminated. At this stage, Vehicle
Occupants Group is at its output state, being helped.
The animated execution of the system model has several benefits. Firstly, it is a dynamic visualization
aid, which helps both the modeler and the target audience to follow and understand the behavior of the
system over time. Secondly, similar to a debugger of a programming language, it facilitates verification
of the system’s dynamics and spotting of logical design errors in its flow of control. Therefore, it is
2
You may want to try it yourself if you have modeled the system with OPCAT: Click the “Test System” film icon.
16 Text and Simulation Enhancements
highly recommended that the system model be animated frequently as it is being constructed, so that
design errors do not accumulate, but are corrected as soon as they are made.
2.4 Summary
OPM has two equivalent representation modalities: the graphic—object-process diagram (OPD)
and the textual—object-process language (OPL).
The OPL sentences and the OPD complement each other, as they appeal to the parallel visual
and verbal cognitive processing channels of the human brain.
A state is a situation at which an object can be.
An effect link indicates some state change of the linked object by the linked process.
An input-output link pair indicates the specific state from and to which the process changes the
object.
An OPM model is amenable to animated simulation, which facilitates understanding the
system’s dynamic aspect and testing its logical flow.
2.5 Problems
Continuing with the Baggage Handling System that you modeled in Chap. 1, let us assume that the
current model is presented in Fig. 2.5.
1. Match a corresponding OPL sentence for each link in the OPD of the Baggage Management
System in Fig. 2.5.
2. Add the states unloaded and loaded to the object Baggage.
3. Replace the effect link between the process in your model and Baggage by an input-output link
pair.
Dori – Model-Based Systems Engineering with OPM and SysML 17
Fig. 2.5 System Diagram—top-level Object-Process Diagram (OPD) of the Baggage Handling System
Links are graphical expressions of relations between things. OPM links connect processes with objects or
their states, providing meaning to relationships among them. This chapter expands the use of links in our
model and explains the semantics of various kinds of links.
A procedural link is a link that specifies a dynamic aspect of the system by connecting
an object (or one of its states) and a process.
Procedural links can be transforming or enabling. Transforming links express transformation—
generation, consumption, or state change—of the object by the process to which it is linked. Enabling
links express enablement. They connect a process to an enabler—an object that enables the occurrence of
that process but is not transformed by that process.
Structural links model the structure of the system by expressing long-term relations between things in
the model. Structural links include aggregation-participation (whole-part), generalization-specialization,
and other long-lasting relations.
A structural link is a link that specifies a static aspect of the system by connecting an
object to another object or a process to another process.
beneficiary. In our case, Vehicle Occupants Group is also the operand of the system; it is the main object
transformed by the system’s function, with its input and output states.
We are not quite done yet; while the function and the operand are important, they do not provide the
full picture of the system, even at this most abstract level. Objects that enable this function should be
presented in addition to the beneficiary. These enablers include human and non-human objects, which in
OPM are referred to as agents and instruments, respectively.
An agent of a process is a human or a group of humans that interacts with the system
to enable and/or control that process, but is not transformed by it.
Automatic Crash
Responding
Advisor
Fig. 3.1 Advisor is added as the agent of Automatic Crash Responding using the agent link from Advisor to
Automatic Crash Responding. The optional stick figure also indicates that the object is a human
The agent link, , shown in Fig. 3.1, is a “black lollipop”—a connecting line starting at the object
and ending with a black circle at the process end. This symbol denotes that the object linked to the
process is a human whose presence is mandatory for the process to happen.
The agent link indicates that there is a “human in the loop”, usually indicating that an interface is
required between the human—the agent—and the system in order for the agent to interact with it. Fig. 3.1
shows Advisor added as an agent to the Automatic Crash Responding process. The process cannot start
or be sustained without the agent, but the process does not transform the agent: It does not create or
consume it, nor does it change the agent’s state. Hence, agent is a human enabler of the process. The
OPL sentence that is generated as a result of adding the agent link is:
Advisor handles Automatic Crash Responding.
Dori – Model-Based Systems Engineering with OPM and SysML 21
The OPL reserved word handles denotes the need for an agent to enable the process. While the Vehicle
Occupants Group object is a group of people, they not an agent. These people are the beneficiary and
operand of the system—they do change and are hence transformed by the system’s function and benefit
from it.
ACR System
Automatic Crash
Responding
Advisor
Fig. 3.2 ACR System is added as instrument of Automatic Crash Responding using the instrument link from ACR
System to Vehicle Occupants Group
Figure 3.2 shows the instrument ACR System added using the instrument link from Advisor to Vehicle
Occupants Group. The instrument link is the line ending with a blank circle at the process end, which
denotes that the object at the origin of the link is an instrument with respect to this process. An instrument
is an inanimate, non-human enabler of the process; in other words, the process cannot start or take place
without the existence and availability of the instrument throughout the process duration. Like the agent,
the instrument is not transformed as a result of the process occurrence.
The OPL sentence that OPCAT generated as a result of adding the instrument link is:
Automatic Crash Responding requires ACR System.
22 Connecting Things with Links
The OPL reserved word requires denotes the need for an instrument to enable the process.
ACR System
Fig. 3.3 Vehicle is added as part of the ACR System, and the tagged structural link from Vehicle Occupants Group to
Vehicle is added with the tag “occupies”
Figure 3.3 shows our SD with Vehicle added and linked to these two objects with two links. These
two links are called structural links. The first is aggregation-participation link, from ACR System to
Vehicle. The second link is tagged structural link from Vehicle Occupants Group to Vehicle. We next
discuss each one of these structural links.
Vehicle is connected via an aggregation-participation (whole-part) link as part of the ACR System.
The aggregation-participation symbol is , a solid equilateral triangle with its tip directed upwards and
linked to the whole, and its base linked to the part or parts. This graphical aggregation-participation link
is expressed textually the following OPL sentence:
ACR System consists of Vehicle.
The OPL reserved phrase consists of denotes the aggregation-participation relation, with the whole
(ACR System in our case) preceding it and the part (Vehicle in our case), or parts, following it.
Dori – Model-Based Systems Engineering with OPM and SysML 23
Vehicle is connected to Vehicle Occupants Group via a second type of structural link—the tagged
structural link. A tagged structural link is an open arrow that points from one object to another. The tag is
a “user-defined” phrase—a phrase that is defined by the modeler and recorded along the link, expressing
the nature of the structural relation between the two connected objects (or processes). In our model, the
link’s tag is occupies. It is bold since it is defined by the modeler and is not an OPL reserved phrase.
Adding the tagged structural link initiates the generation of the following OPL sentence:
Vehicle Occupants Group occupies Vehicle.
Tags in tagged structural links provide the modeler with the ability to express the semantics of any
structural relation between any two objects or any two processes in the system. As the above OPL
sentence demonstrates, a tagged structural link gives rise to an OPL sentence in which the name of the
object connected to the source of the link’s arrow appears first (Vehicle Occupants Group in our case),
followed by the tag name (occupies), followed by the name of the object connected to the destination of
the link’s arrow (Vehicle).
As for Automatic Crash Responding, which is our main process and the system’s function, it is
possible at this point to say that it is informatical, because it only involves conveying the information that
the vehicle has been involved in a crash and that there has been a subsequent call for help for its
occupants. The actual helping process, which is physical, is outside the scope of this system. The essence
of the Automatic Crash Responding process can be changed later to physical if we realize that it involves
one or more physical subprocesses.
24 Connecting Things with Links
Vehicle Occupants Group can also be considered as environmental, because it is not part of the ACR
System but rather the beneficiary and the operand—the object on which the system operates to transform
it. In our case, the transformation is from the possibly injured state to the state of being helped. Figure
3.4 displays Vehicle Occupants Group as a physical object by its shading. This is also reflected in the
following OPL sentence:
Vehicle Occupants Group is physical.
The thing’s attribute whose values are systemic and environmental is called affiliation.
The input state, intact, is the initial state; that is, the state at which the object starts its lifecycle after
being generated. This is denoted graphically by the thick contour around intact. The output state,
26 Connecting Things with Links
crashed, is the final state; that is, the state from which the object cannot exit. This is denoted graphically
by the double contour around crashed. Textually, by the corresponding OPL sentence specifies the two
states:
Vehicle is initially intact and finally crashed.
Using the initial and final state symbols, possibly injured and being helped are designated in Fig. 3.5
as the initial and final states of Vehicle Occupants Group, respectively:
Vehicle Occupants Group is initially possibly injured and finally being helped.
Fig. 3.5 The effect of Crashing is made explicit by replacing it with an input-output link pair that specifies
the input and output states of Vehicle. The event link from the crashed state of Vehicle triggers
Automatic Crash Responding
Having specified the states of Vehicle, we replace the single effect link between Crashing and Vehicle
by an input-output link pair. The semantics of this change can be best understood by examining the OPL
sentences generated before and after this replacement. Originally, the OPL sentence that corresponded to
the OPD in Fig. 3.4 read as follows:
Crashing affects Vehicle.
After replacing the effect link in Fig. 3.4 by the input-output link pair in Fig. 3.5, the OPL sentence is:
Crashing changes Vehicle from intact to crashed.
The latter sentence is clearly more informative, as it tells us specifically from what input state to what
output state the Crashing process changed Vehicle. However, this additional detail comes at the expense
of loading the OPD with two links—the input and output links—instead of the single effect link.
Dori – Model-Based Systems Engineering with OPM and SysML 27
This OPL sentence reflects the combined semantics of the event control modifier, which is expressed
by the reserved OPL word initiates, with that of the instrument link, which is expressed by the reserved
OPL word requires. AS the sentence demonstrates, Vehicle at its crashed state is simply crashed Vehicle.
3.9 Summary
Enablers are required for a process to occur, but are not affected by the occurrence of that
process.
An agent is a human enabler, while an instrument is a non-human enabler.
Two types of links connect entities with each other: structural links and procedural links.
o Procedural links, which are between a process and an object or one of its states, express the
behavior of the system; for example, an effect link.
o Structural links express persistent, long-term relations between two connected objects or between
two connected processes in the system; for example, an aggregation-participation link.
Since the structural and the procedural links are expressed in the same diagram, they help
integrate the structure and the behavior of the system.
Things—that is, objects and processes—are classified by their
o Essence into physical things and informatical things, and by their
o Affiliation into systemic things and environmental things.
A process is triggered by an event link.
28 Connecting Things with Links
3.10 Problems
When a passenger arrives at the airport with her baggage, she checks it in. The airline loads the
baggage on-board the aircraft.
1. Define three states of Baggage based on the holder or the location of the baggage from the time
the Passenger arrives at the Airport until Baggage is loaded on the Airplane.
2. Add three states to the OPD you started to construct in the previous chapter (remember to use
lower-case letters).
3. What is the OPL sentence that describes the states of Baggage?
4. What is the process that changes Baggage from the first state to the second state?
5. Add this process to the OPD along with the input link from the first state to the process and from
the process to the second state.
6. What is the OPL sentence that describes the change of Baggage states?
7. Repeat problems 4–6 with the process that changes Baggage from the second state to the third.
8. Perform animated simulation on your model by triggering each one of the two processes and
watch the states change as expected. Provide screenshots of the model at the various states.
When the aircraft arrives at the destination airport, the baggage is unloaded and returned to the
passenger.
9. Based on the text above, repeat problems 7–8 with the process that changes Baggage from the
third state to the first.
Chapter 4
SysML: Use Case, Block, and State
Machine Diagrams
SysML supports the specification, analysis, design, verification, and validation of a
broad range of complex systems. These systems may include hardware, software,
information, processes, personnel, and facilities.
OMG SysML, v1.3 p.1 ( Accessed June 20, 2014 )
We leave OPM for a while and turn to start our parallel SysML model. SysML is a multi-view language,
where each view uses a different type of diagram. There are nine SysML diagram types in total. In this
chapter we are exposed to three diagram types: the use case diagram, the block definition diagram, and
the state machine diagram. The use case diagram shows the context of the system and how the system is
used to bring value to at least one of its actors. The block definition diagram presents the blocks of the
system—major entities of interest. The state machine diagram shows how states of blocks in the system
are changed. Comparing OPM and SysML, we already see that the approaches they take are different and
complementary. OPM uses a single model that combines the various system aspects, while SysML uses a
number of diagram types, each focusing on some particular aspect of the system.
A use case is a way the system is used, a service it provides to at least one of its users.
According to the OMG SysML 1.3 (2012) standard, a use case diagram “describes the usage of a
system (subject) by its actors (environment) to achieve a goal that is realized by the subject providing a
set of services to selected actors” (OMG SysML 1.3, 2012, p.145).
Before drawing use case diagrams, use cases need to be written in text. This text takes on different
formats. Depending on need, use cases are written in varying degrees of formality. They can be
brief—short one-paragraph summary, usually of the main success scenario;
casual—informal paragraph format, where multiple paragraphs describe various scenarios; and
fully dressed—the most elaborate level, where all the steps and variations are written in detail,
and there are supporting sections, such as preconditions and success guarantees.
Figure 4.1 is a preliminary use case diagram of the Automatic Crash Response (ACR) system.
The name of the use case in our use case model is “Automatically respond to crash.” As Fig. 4.1
shows, the use case is depicted as an oval with the name inside it. The system users are called actors.
An actor is an external entity that interacts with the system and can get services from
it.
An actor is depicted either as a human stick figure, or as the stereotype «actor»; see Table 4.1. Two
actors appear in the use case diagram in Fig. 4.1: Vehicle Occupants and Advisor. An actor is by
definition an external entity. Unlike OPM, SysML does not require that the actor be a person; it can be
anything with which the system interacts.
Fig. 4.1 A preliminary SysML use case diagram of the Automatic Crash Response (ACR) system
Vehicle Occupants are undoubtedly an external entity, since they are not part of the system, but
rather its users and beneficiaries. The case for the Advisor is not that clear-cut, since the Advisor can be
considered as part of the system, and rather than getting a service from the system, she is the one that
provides the service. However, the requirement that an actor gets a service is not mandatory, and as a
human, the Advisor interacts with the system. In this model, we exclude humans from being considered
part of the system; hence Advisor is also an actor. Each one of the two actors is linked to the use case via
a communication path—a line between the actor and the use case.
The system which provides the required function in a use case diagram is called subject.
A subject in a use case diagram is the system that provides the service.
Dori – Model-Based Systems Engineering with OPM and SysML 31
A use case subject is depicted as a rectangle with the subject name at the rectangle's top center. As
Fig. 4.1 shows, the subject in our use case diagram is called ACR-System.
The entire use case diagram is depicted within a diagram frame—a rectangle that is required for any
SysML diagram. In its upper leftmost corner, a diagram frame has name tag—a rectangle with a tapered
bottom right corner—which contains the heading name. The heading name has the following syntax:
<diagramKind> [modelElementType] <modelElementName> [diagramName]
The fields diagramKind, which is bolded, and modelElementName are mandatory. Each diagramKind
has a two or three lower case letter abbreviation. As shown in Fig. 4.1, the diagramKind of our use case is
uc, while the diagramName is ACR-System. The two other tokens, modelElementType and
diagramName are optional, and if they appear, they are enclosed within brackets, enabling the diagram
reader to tell them apart.
Table 4.1 lists the main elements of a use case diagram, their semantics and symbols.
Table 4.1 The main elements of a use case diagram, their semantics and symbols
Guillemets, also known as the symbols for rewind («) and fast forward (»), are angle quotes, as the
ones surrounding the following word: «guillemets». In SysML, a word within a pair of guillemets denotes
a stereotype—an extensibility mechanism that enables creating new model elements.
A stereotype is depicted as a rectangular box with the stereotype name, such as “block” within a pair
of guillemets, «block», recorded in the top middle of the box, as is the case with «actor» in Table 4.1. The
name of the actor, ActorName, is recorded beneath the «actor» stereotype notation.
32 SysML: Use Case, Block, and State Machine Diagrams
A SysML block definition diagram (bdd) defines features of blocks and relationships
between blocks, such as associations, generalizations, and dependencies.
The block definition diagram captures the definition of blocks in terms of properties and operations,
and relationships, such as a system hierarchy or a system classification tree. A related SysML diagram is
the internal block diagram (ibd), which captures the internal structure of a block in terms of properties
and connectors between properties.
Fig. 4.2 A preliminary block definition diagram of the Automatic Crash Response (ACR) system
Figure 4.2 is a preliminary block definition diagram (bdd) of the Automatic Crash Response (ACR)
system. The diagramKind, bdd, denotes this. This bdd expresses the two major blocks of the system and
the relation between them, as well as the major actors and their relations the blocks.
This two blocks in the bdd are ACR-System and Automatic-Crash-Response. They are linked by the
ReferenceAssociation labeled “provides”. Advisor is shown as an actor which is part of the ACR-System.
This whole-part relation is expressed by the black diamond, the SysML symbol for whole-part relation.
Dori – Model-Based Systems Engineering with OPM and SysML 33
Vehicle Occupants is another actor. It is linked by the ReferenceAssociation labeled “benefit from” to the
Automatic-Crash-Response block (Fig. 4.2).
Table 4.2 The main elements of a block definition diagram, their semantics and symbols
Element:
Symbol
Semantics
Block
A modular component which defines a col- «block»
lection of features to describe a part of the BlockName
system or another element of interest.
Actor:
An external entity that interacts with the «actor»
ActorName ActorName
system and can get services from it
ReferenceAssociation: association1 property1
A link between blocks indicating the nature 0..1 {ordered} 1..*
of their association
PartAssociation:
association1 property1
A link between blocks indicating that the
0..1 {ordered} 1..*
block linked to the diamond is the whole
Generalization:
A link between two block indicating that the
block linked to the triangle is the general one
state rountangle frame, and a final state—by a double rountangle frame. This eliminates the need for the
two kinds of pseudo states that SysML uses.
Fig. 4.3 A SysML State Machine diagram (stm) of the ACR system
Table 4.3 The main elements of a state machine diagram, their semantics and symbols
Dori – Model-Based Systems Engineering with OPM and SysML 35
Table 4.3 shows the main elements of a state machine diagram, their semantics and symbols. As the
table shows, a state can be composite and contain inner, lower-level processes. A transition can be
labeled, in addition to a trigger, also by an optional guard in brackets and one or more optional activities
that syntactically follow the backslash symbol (\), which are actions done during the transition.
4.4 Summary
SysML has nine types of diagrams that model various aspects of the system
The use case diagram is often the first to be prepared since it provides the context of the system
and how actors interact with it.
Block is a basic unit, akin to class in UML, used in the block definition diagram and internal
block diagram. It serves to define the structure of the system.
State machine diagram is a SysML diagram that specifies the possible states of relevant blocks
in the system and transitions between these states.
4.5 Problems
1. Draw a SysML use case diagram of the system described below.
A passenger arriving at an airport deposits her baggage with the airline she is flying with. A
baggage handling system manages the transfer of the baggage to the passenger’s destination.
2. Draw a block definition diagram of the system in the system described above.
3. Baggage Location has states passenger, origin airport, aircraft, destination airport, other
location. Model this using a SysML state machine diagram and indicate what causes transitions
between states.
4. Compare the three types of diagrams created in the three problems above in terms of their
information content.
5. What can be said about the system by looking at each diagram alone?
6. How can the information be integrated to obtain a complete view of the system?
Chapter 5
Refinement Through In-Zooming
The deepest parts of the ocean are totally unknown to us… What goes on in those
distant depths? What creatures inhabit, or could inhabit, those regions twelve or
fifteen miles beneath the surface of the water? It’s almost beyond conjecture.
Jules Verne, 20,000 Leagues under the Sea (1869)
The previous chapters have exposed us to the basic concepts of OPM, yet we have barely scratched the
surface of the system we are modeling. In this chapter, we specify more details about the system while
revealing some more modeling concepts of OPM and how they can be utilized to represent our system in
more detail. In order to examine the text that specifies the system we are modeling, we return our focus to
information from the first sentences:
“The accelerometer … measures the crash severity.”
We combine this information with that from a sentence in the sequel:
“Within seconds of a moderate-to-severe crash, the OnStar module will send a message …”
The text skims over important information that we need to glean indirectly. We have already modeled
the fact that the Vehicle is (at state) crashed. The phrase “moderate-to-severe crash” indicates that we
need to model the crash severity, as this determines whether a message will be sent. The implicit
assumption, which we model here, is that if the crash is light, it is unlikely to have caused an injury, so
the system should not be activated. Consequently, it makes sense to have Crash Severity Measuring as the
next process to model.
Fig. 5.1 The Automatic Crash Responding process is in-zoomed, showing its first subprocess, Crash Severity
Measuring, nested inside it
window), and the new one, called SD1—Automatic Crash Responding in-zoomed (to the right of SD). Figure
5.2 also shows at the OPD hierarchy pane on the left hand side the OPD process tree, which currently has
just two OPDs: SD and SD1.
Fig. 5.2 A screenshot of OPCAT, concurrently showing two OPDs: SD (left) and SD1—Automatic Crash Responding in-
zoomed (right). The OPD hierarchy tree is presented on the left pane
SD and SD1 are the two OPDs that currently constitute the OPD set; that is, the set of OPDs,
organized as a process tree, which together specify the system. The OPD set keeps growing as additional
OPDs are gradually constructed to increasingly refine the model and make it more concrete. The ability to
add a descendant, subordinate OPD whenever the one currently under work reaches its congestion limits
makes it possible to avoid over-cluttering any single OPD.
The OPL sentence that links the OPL paragraph of SD to the OPL paragraph of SD1 is:
Automatic Crash Responding from SD zooms in SD1 to Crash Severity Measuring.
This kind of sentence indicates the hierarchical relationships between any two OPL paragraphs
representing OPDs from adjacent hierarchy levels. In our cases, it indicates that SD1 is a child of SD.
This principle stipulates that it is enough for a model fact to appear only once in any OPD of the OPM
model in order for it to be valid for the entire model. This principle does not preclude the possibility of
representing any model fact any number of times in as many OPDs as the modeler wishes. However,
although any number of entities can be included in any OPD, for the sake of clarity and avoiding clutter,
it is often highly desirable to include only those elements that are necessary in order to grasp a certain
aspect or view of the system. In our case, we have elected not to include the tagged structural link in SD1,
as it does not add to comprehension of the point we want to make in this OPD.
As soon as Crashing occurs, the state of Vehicle changes from its initial intact state to its final crashed
state. Upon entry of Vehicle to its crashed state, the state-specified instrument event link from the
crashed state to Crash Severity Measuring initiates this subprocess. Crash Severity Measuring is the first
(and currently the only) subprocess of the in-zoomed Automatic Crash Responding process. Crash
Severity Measuring changes Crash Severity from its initial state, none, to exactly one of the three other
states.
Figure 5.3 expresses this graphically by way of (1) the input link from the none value of Crash
Severity to the Crash Severity Measuring process, and (2) the three alternative output links emanating
from the same point on the ellipse of Crash Severity Measuring to each one of the three values, light,
moderate, and severe, joined by a dashed arc. This dashed arc indicates the XOR (exclusive OR) logical
operator among links. In OPCAT it shows up automatically only when the XOR’ed links emerge from a
common point, as is the case here, or arrive at a common point (as in Fig. 6.2).
The facts that these three output links originate from the same point and that a dashed arc connects
them together symbolize the XOR logical operator between the links: Crash Severity Measuring
determines that Crash Severity can have precisely one of its three possible output values: light, moderate,
or severe, but not any two or all three at the same time. Indeed, the OPL sentence that describes this state
change is:
Dori – Model-Based Systems Engineering with OPM and SysML 41
Fig. 5.3 Crash Severity, with its four states, is added as an attribute of Vehicle. The state none is the initial and input
state, and light, moderate, and severe are the possible output states of the Crash Severity Measuring process
Crash Severity Measuring changes Crash Severity from none to exactly one of light, moderate, or severe.
Fig. 5.4 Animated execution of the system at its current design: Crash Severity Measuring has just finished, changing
Crash Severity from none to severe
5.7 Summary
In-zooming is a refinement mechanism that helps manage system complexity.
Zooming into a process creates a new OPD with an inflated in-zoomed process.
Lower-level processes (subprocesses) are nested within this in-zoomed process and they can be
linked to lower-level objects inside or outside the in-zoomed process.
Recursive in-zooming results in an OPD set that has a tree structure, in which lower-level OPDs
model increasingly refined details about the system.
The model fact representation OPM principle stipulates that in order for an OPM model fact to be
represented, it needs to appear in at least one OPD in order for it to be represented in the model.
Using this principle helps decrease diagram clutter, making each diagram simple enough to be
grasped without cognitive overload.
Dori – Model-Based Systems Engineering with OPM and SysML 43
5.8 Problems
Continuing with the Baggage Handling System, let us assume that the current model is presented in Fig. 2.5.
1. Check if all the enablers—agents and instruments—of the Baggage Handling process appear in
Fig. 2.5. If there are missing enables, add them.
2. What is the appropriate link type between Airline on the one hand and Aircraft and Airline
Personnel on the other? Add the links the model.
3. What is the appropriate link between Passenger and Baggage? Add it to the model.
4. Which objects are physical? Express this in the model.
5. Which objects are environmental? Express this in the model.
6. Which objects in the model should be stateful? Add the relevant states to each such object.
Chapter 6
The Dynamic Aspect of Systems
The expert may, in the process of explaining some idea or description of a behavior,
suddenly reach for pad and draw sketches of what he/she does, and say “it has to look
like this” or “I know just by looking at the chart if something is wrong.”
Firlej and Helens (1991)
Continuing with modeling our case study, in this chapter we further discuss process issues, such as
execution order and how to specify that processes are sequential, concurrent, or alternative. These issues
are related to the system's dynamic aspect and to its operational semantics.
Fig. 6.1 Crash Severity Measuring has determined that Crash Severity is light, so Exiting changes the state of
Vehicle Occupants Group to uninjured
According to this description, following Crash Severity Measuring, as a result of a crash whose Crash
Severity is moderate or severe, a message is created and then sent via the OnStar Call Center to the
advisor, who sends help based on the message. Accordingly, as Fig. 6.2 shows, we add three subsequent
subprocesses: Message Creating, Message Sending, and Help Sending. The following OPL sentence
expresses the XOR relation between the condition links from the moderate and severe states of Crash
Severity to Message Creating.
As we recall, the model fact representation OPM principle states that an OPM element needs to appear
in at least one OPD in order for it to be represented. Based on this principle and in order to simplify the
OPD, the environmental process Crashing, which appeared in Fig. 6.1, has been removed from Fig. 6.2.
This enables us to add objects mentioned in the text that are relevant here: the OnStar Call Center and the
Cellular System, which are parts of the ACR System (in addition to the Vehicle), as well as the Advisor
and the Message.
Dori – Model-Based Systems Engineering with OPM and SysML 47
Fig. 6.2 Message Creating, Message Sending and Help Sending are added as three sequential subprocesses
along with the objects OnStar Call Center, Cellular System, Message, and Advisor
The five subprocesses in Fig. 6.2 are arranged by their execution order (the timeline perspective) from
top to bottom. This is based on the following timeline OPM principle.
The Timeline OPM Principle
The timeline within an in-zoomed process is directed by default from the top of the in-zoomed
process ellipse to its bottom.
48 The Dynamic Aspect of Systems
The timeline OPM principle is followed by default, unless there is indication to deviate from the
timeline. Indications to deviate from the top-to-bottom timeline within an in-zoomed process include
internal events within the scope of the process which can cause loops.
The top-most point of the process ellipse serves as a reference point, so a process whose reference
point is higher than its peer starts earlier. If the reference points of two or more processes are at the same
height (within some tolerance), these processes start simultaneously.
According to the timeline OPM principle, Crash Severity Measuring is executed first, followed by
Exiting (in case of light Crash Severity) or, in case of moderate Crash Severity or severe Crash Severity,
by Message Creating, followed by Message Sending and Help Sending.
Fig. 6.3 Help Sending is in-zoomed, exposing four subprocesses that culminate in the Vehicle Occupant Group at the
state of being helped. (Note: in this and in the next OPD the c of the condition link is drawn inside the circle)
50 The Dynamic Aspect of Systems
Fig. 6.4 Help Sending executed, showing a specific thread of execution in progress. It can be traced by following the
state of each object
6.6 Summary
The condition link semantics is that if the object to which the link is attached exists, or if the
state to which the link is attached is the current object state, then the process executes, otherwise
it is skipped.
The XOR relation between procedural links indicates that exactly one of the possible interactions
denoted by these links materializes.
XOR is denoted graphically by a common point from which all the XOR'ed links originate or at
which they terminate, and a dashed arc through these links whose center is the common links'
point.
The timeline OPM principle stipulates that the timeline within the context of an in-zoomed
process is directed by default from the top of the in-zoomed process ellipse to its bottom.
Dori – Model-Based Systems Engineering with OPM and SysML 51
The subprocess execution order is determined by the height of the top subprocess ellipse points,
such that the one at the top starts first.
If the top ellipse point of two or more subprocesses is at the same height, within a predefined
tolerance, they start simultaneously. This is the way to model process synchronization.
6.7 Problems
Let us consider the OPD in Fig. 6.5. It the OPD obtained by zooming into the Baggage Handling process
in SD in Fig. 2.5, called “SD1 – Baggage Handling in-zoomed”.
Fig. 6.5 SD1 – Baggage Handling in-zoomed, the OPD obtained by zooming into the Baggage Handling process in
SD in Fig. 2.5
3. What is the appropriate structural link between Passenger and Baggage that would be consistent
with SD (Fig. 2.5)? Add it to the model.
4. Baggage Location is an attribute of Baggage whose values (attribute states) are the various
possible locations of Baggage. What are the four Baggage Location values in the model? What
is the initial state and what is the final state? How can you tell?
5. Add to Baggage a second attribute, called Baggage Holder, with three values: passenger,
security, and airline.
6. Show how subprocesses of Baggage Handling change the value of Baggage Holder.
7. How does Origin Baggage Handling change the state of Baggage Location?
8. What is the semantics of the dashed arc between the arrows from Origin Baggage Handling to
aircraft and other?
Chapter 7
Controlling the System’s Behavior
The picture... corresponds to the concept or memory image associated with the words.
Schapiro (1996)
Control in the context of conceptual modeling is the ability to determine the flow of processes and how
they transform objects under various conditions and circumstances. Several control structures enable us to
determine how the system will behave over time. These include Boolean objects for branching and
control modifiers—condition and event indicators that are added to procedural links and augment their
semantics. In this chapter we discuss and show how control structures are used to model system behavior.
Fig. 7.1 The states of the Boolean object “Response Received?” determine the system’s behavior
The name of a Boolean object may end with a question mark, in which case its OPL version is put in
quotes, as in “Response Received?” The question should be phrased such that when combined with the
answer using a state-specified instrument link or a condition link the resulting OPL sentence will make
sense, although it might not sound very natural.
As Fig. 7.1 shows, the name of our Boolean object is “Response Received?” and it has the two states,
yes and no. Each one of these states is linked with a condition link, denoted by the letter c next to the
circle of (and in older versions inside) the instrument link. Each condition link is to one of the two
alternative processes. Since by the definition of state an object cannot be at the same point in time in more
than one state, “Response Received?” is either yes or no, as expressed by the following OPL sentence:
“Response Received?” can be yes or no.
Since both the no and the yes states are respectively connected to the processes Crash Information
Providing and Public Aid Conferencing with condition (rather than instrument) links, exactly one of these
two possible processes can occur: either Public Aid Conferencing occurs and Crash Information Providing
is skipped, or Crash Information Providing occurs and Public Aid Conferencing is skipped. This is how
alternative processes are modeled in OPM. In Fig. 7.1, these two alternative processes are at the same
height to emphasize that one or the other happens, but not both. This is good practice that facilitates the
Dori – Model-Based Systems Engineering with OPM and SysML 55
diagram comprehension, but the flow of control would be the same even if the alternative process ellipse
heights would not be the same.
A Boolean pair is a pair of inverse names for the states or values of a Boolean object.
There are several predefined Boolean pairs that can be incorporated into an automated OPM-
supporting tool. Examples include the Boolean pairs true and false, positive and negative, black and
white, on and off, up and down, black and white, good and bad, right and left, top and bottom, correct
and incorrect, right and wrong, right and left, north and south, high and low, big and small, OK and not
OK, approved and denied, passed and failed, greater than or equal to x and smaller than x (which can
also be written as >=x and <x, where x can be any input number), and greater than x and smaller than or
equal to x (which can also be written as >x and <=x). In addition to these pre-defined Boolean pairs, the
user can, of course, use any other Boolean pair simply by specifying the names of the two states of the
Boolean object.
There is nothing methodologically special about a Boolean object that differentiates it from any other
informatical object, except that is has exactly two states. In the general case, an object can have any
number of states (including zero, in which case it is stateless). Having several states is akin to a “case
statement” in programming languages, as each state, in turn, can be an instrument or a condition for some
subsequent process. If a state-specified instrument link originates from the state, the semantics is “wait
until the object is at the specified state.” If a condition link originates from the state, the semantics is “do
the process if the object is at the specified state, else skip this process.”
and
Crash Information Providing occurs if “Response Received?” is no.
56 Controlling the System's Behavior
Like an instrument link, a condition link can also originate from a stateless object (an object without
states) rather than from an object’s state. In this case, if the object exists (either from the beginning of the
system execution or because it was created at some point during the system execution), then execution of
the target process is attempted, and if not—the process is skipped.
Comparing the condition link to the instrument link, we see that the semantics of a condition link is
weaker than an instrument link. This is so because in the case of a condition link, the process being
triggered is skipped if not all the preconditions for the occurrence (execution) of that process are fulfilled.
Conversely, in the case of an instrument link, the execution of the system halts and waits until all the
conditions for the target process occurrence are fulfilled. In a programming language terms, the condition
link is analogous to “if…then”, whereas the instrument link is analogous to “wait until…” Indeed, the
OPL reserved phrase of the condition link is “occurs if”, while for the instrument link it is “required”.
7.3 Generalization-Specialization
Let us now consider the text that follows:
… The advisor then can conference in 911 dispatch or a public safety answering point (PSAP)…
If there is no response from the occupants, the advisor can provide the emergency dispatcher with
the crash information.
Three help entities are mentioned here: 911 Dispatch, Public Safety Answering Point, and Emergency
Dispatcher. From the text it is evident that the entity getting the crash information, Emergency
Dispatcher, is a generalization of both 911 Dispatch and Public Safety Answering Point. Conversely, 911
Dispatch and Public Safety Answering Point are both specializations of Emergency Dispatcher.
Generalization-specialization is a powerful structural relation, which provides for abstracting any
number of objects or process classes into superclasses. Syntactically, the generalization-specialization
relation is a white triangle whose tip is linked to the generalizing link and whose base—to the specializing
ones. In Fig. 7.1, this link is shown connecting the general Emergency Dispatcher to the two
specializations, 911 Dispatch and Public Safety Answering Point. The OPL phrase expressing this relation
is “is a” (or “is an”). The following OPL sentences express this:
911 Dispatch is an Emergency Dispatcher.
Public Safety Answering Point is an Emergency Dispatcher.
Semantically, the generalization-specialization link induces inheritance of features, states, and links
from the generalizing superclass—the general to its subclasses—the specializations. For example, the
single agent link from Emergency Dispatcher to Emergency Service Dispatching in Fig. 7.1 is inherited
to both 911 Dispatch and Public Safety Answering Point. This is an example of the power of
generalization and the inheritance it induces: instead of drawing six agent links from 911 Dispatch and
Public Safety Answering Point to each one of the three bottom subprocesses in Fig. 7.1, only three are
drawn, but they are interpreted as six.
Dori – Model-Based Systems Engineering with OPM and SysML 57
this object touches the outer Crash Severity Measuring process, acting like parentheses in algebra to
denote that it applies to all the subprocesses within it.
Vehicle consists of Sensing and Diagnostic Module, 2 to many Front Sensors, and 2 to many Side Sensors.
Comparing this to the XOR in the same OPD, we see that XOR is expressed by the reserved OPL phrase
“exactly one of”, as in the following OPL sentence.
Diagnosing changes Crash Severity to exactly one of light, moderate, or severe.
not explicitly specified, in Fig. 7.3 we add the process Acceleration Measuring, with Accelerometer as its
instrument and Acceleration Measuring as its resultee—the object that results from this process.
Crash Severity Measuring zooms into Impact Sensing, Acceleration Measuring, and Diagnosing in that sequence,
as well as Acceleration Signal and Shock Signal.
This sentence lists the three subprocesses that get exposed in the in-zoomed Crash Severity
Measuring: Impact Sensing, Acceleration Measuring, and Diagnosing. The reserved phrase “in that
sequence” indicates that the top-to-bottom order in which the subprocesses are listed is their execution
order. This list of processes is followed by the reserved OPL phrase “as well as”, followed by the list of
two contained objects: Shock Signal and Acceleration Signal. The reserved OPL phrase “as well as”
60 Controlling the System's Behavior
separates between the list of processes and the list of objects in an in-zoomed process. The subprocesses
are parts of the in-zoomed process while the objects are attributes of that in-zoomed process. For an in-
zoomed object, the order would be reversed: The list of objects would come first, followed by “as well
as”, followed by the list of processes. In this case, the internal objects are parts of the in-zoomed object,
while the internal processes are operations of that in-zoomed object.
The two informatical objects Shock Signal and Acceleration Signal are created inside the Crash
Severity Measuring process by two of its subprocesses. They are then immediately consumed by the third
subprocess, Diagnosing, and disappear. In general, objects inside an in-zoomed process are temporary:
they exist and are recognized solely within the scope of that process. This would remain true even if we
use two instrument links instead of the two consumption links. If we wish to preserve these objects, they
must reside outside the in-zoomed process.
7.10 Summary
A Boolean object has two states and is used for modeling flow of control.
A condition link has a control modifier c added to a procedural link, augmenting its semantics
with skip meaning.
Generalization-specialization is a fundamental structural relation that induces inheritance of
features (attributes and operations), links, and states from the general thing to the specialized
thing.
Participation constrains enable specifying how many objects of the same class participate in a
relation.
Dori – Model-Based Systems Engineering with OPM and SysML 61
OR is a relaxed version of the XOR logical operator that allows any subset of participating links
to be active at once, rather than exactly one of them, as XOR does.
Objects within an in-zoomed process are recognized only in the scope of that process. If they are
used in places outside that scope they must be placed outside the in-zoomed process.
7.11 Problems
Figure 7.4 is SD1.1—Origin Baggage Handling in-zoomed. This is the OPD obtained by zooming into
the Origin Baggage Handling process in SD1 (Fig. 6.5).
So far we always increased the refinement (detail) level of our model and we did it via zooming into
processes. There are cases where we need to decrease the refinement level, or, in other words, abstract the
model. This can happen when we realize that there are too many details already squeezed into a single
diagram, making it too crowded and hence less comprehensible. We do not want to delete details of the
model, as they are important for complete system specification. Yet we want then taken out of a specific
crowded diagram. We do this by creating a new OPD at an intermediate detail level by zooming out of
the too detailed OPD and creating one at a higher level of abstraction. In this chapter we focus on this
abstracting process and then discuss and improve a structural view of the system.
Fig. 8.1 Message Creating and Message Sending are about to be out-zoomed and replaced by Message Handling
Doing so has another advantage: in Fig. 8.2 we define an aggregate object, called In-vehicle ACR
Subsystem as a part of Vehicle. Having done this, we can now model only In-vehicle ACR Subsystem as
part of ACR System rather than modeling the entire Vehicle as part of ACR System. This new In-vehicle
ACR Subsystem object consists of OnStar Module and all the other objects inside Vehicle that are part of
the ACR System. This modification further simplifies the OPD. Figure 8.2 indeed looks simpler than its
previous version in Fig. 8.1.
This simplified version enables us to explicate the relation between Advisor and OnStar Call Center
without overcomplicating it. We add a tagged structural link with the tag operates from, yielding the
following OPL sentence:
Advisor operates from OnStar Call Center.
Dori – Model-Based Systems Engineering with OPM and SysML 65
Fig. 8.2 Abstracting Message Creating and Message Sending from Fig. 8.1 into Message Handling. Link colors
facilitate OPD comprehension and highlight the c of instrument condition links inside the circle
ACRSystem
2.m
2.m
Front Sensor
Side Sensor
Diagnostics Accelerometer
Sensing Unit Unit
ACR System consists of OnStar Call Center, Cellular System, GPS, and In-vehicle ACR Subsystem.
In-vehicle ACR Subsystem consists of Sensing and Diagnostic Module, Cellular System, GPS, OnStar Module,
and Sensors Set.
Sensing and Diagnostic Module consists of Accelerometer, Sensing Unit, and Diagnostics Unit.
Sensors Set consists of 2 to many Front Sensors, 2 to many Side Sensors, and Sensing Unit.
ACR System
OnStar
Call Center
In-vehicle ACR GPS
Subsystem
Cellular System
Ex-vehicle
In-vehicle GPS Ex-vehicle GPS Cell Phone
Cell System
Sensors Set
2.m
2.m
Front Sensor
Side Sensor
OnStar Module
Sensing and
Diagnostic Module
Accelerometer
Diagnostics
Sensing Unit Unit
Fig. 8.5 The structural hierarchy of the ACR System after resolving the inconsistencies with GPS and Cellular System
The solution for this inconsistency, presented in Fig. 8.5, is to break each of these two objects into two
parts: GPS is split into In-vehicle GPS and Ex-vehicle GPS, while Cellular System is divided into Cell
Phone and Ex-vehicle Cell System. Both In-vehicle GPS and Cell Phone are parts of In-vehicle ACR
Subsystem, while Ex-vehicle GPS and Ex-vehicle Cell System are both parts of ACR System but not of
the In-vehicle ACR Subsystem.
8.4 Summary
While the objective of OPM-based modeling is to go top-down and refine model facts as we go,
to avoid diagram clutter it is sometimes required to abstract two or more processes in the
crowded OPD and create a new OPD at an interim level.
Abstraction can be achieved by process out-zooming: Creating an abstract process, which, when
in-zoomed, will include the out-zoomed subprocesses (and possibly others).
Right after a process is in-zoomed, all the procedural links are still attached to it.
Dori – Model-Based Systems Engineering with OPM and SysML 69
As subprocesses are added, procedural link edges should be dragged from the in-zoomed process
ellipse to the appropriate subprocesses.
Only links that apply to all the subprocesses inside the in-zoomed process should remain
attached to the in-zoomed process.
A structural view is achieved by removing all the processes and the procedural links from the
model.
The structural view enables focusing on the system structure and examining possible structural
improvements.
8.5 Problems
During Sorting & Loading, the Airline Personnel carries out Baggage Sorting, changing the
Baggage Holder from security to airline. This Baggage Sorting process can result in correct or
incorrect sorting. If sorting is correct, Loading of the Baggage to the correct Aircraft takes place,
so the Baggage Location changes from origin to aircraft. Otherwise, loading of incorrectly sorted
baggage changes its Baggage Location from origin to other.
In the OPD SD 1.1.1 in Fig. 8.6, Sorting & Loading from Fig. 7.4 is in-zoomed. Referring to Fig. 8.6
and Fig 7.4, answer the following questions.
1. What is “Soring Is Correct?” what is it used for?
2. Correct Sort Loading is above Incorrect Sort Loading. Does this mean that the former process
will always be performed prior to the latter? Explain.
3. Can both Correct Sort Loading and Incorrect Sort Loading happen in the same execution of
Sorting & Loading? Explain.
4. Is it possible that when Baggage Location is other, the Baggage Holder is security?
5. Under what condition does the process Sorting & Loading takes place? Explain.
6. Why does only Origin Airport and not Destination Airport appear is the OPD?
7. In Fig. 7.4, there is a XOR relation to states aircraft and other of Baggage Location. When
Sorting & Loading is in-zoomed in Fig. 8.6, this XOR relation does not show up. Is this OK?
Explain.
8. Why is the XOR relation to states aircraft and other of Baggage Location needed in Fig. 7.4?
9. What two instrument links end at the Sorting & Loading? Explain the meaning of this, and why
Aircraft is only linked with Correct Sort Loading?
70 Abstracting and Refining
If the baggage is not located in the destination airport (Baggage Location is other), Lost&Found
Handling occurs. The Lost & Found Desk uses the SITA World Tracer and the IATA Tag to locate
the baggage. If it is located, Corrective Handling takes place, otherwise the passenger is
reimbursed.
In the OPD SD1.2 in Fig. 8.7, Lost&Found Baggage Handling is in-zoomed. Referring to Fig. 8.7,
answer the following questions.
10. What are the attributes of Baggage?
11. Under what condition does Baggage Locating happen?
12. What are the instruments of Baggage Locating?
13. What kind of thing is Baggage Located?
14. Can Reimbursing and Corrective Handling both happen at the same execution of Lost&Found
Baggage Handling? Explain.
15. What states of what attributes of Baggage does Corrective Handling change? From what state to
what state?
Dori – Model-Based Systems Engineering with OPM and SysML 71
Fig. 8.7 SD1.2—Lost&Found Baggage Handling in-zoomed—the OPD obtained by zooming into the Lost&Found
Baggage Handling process in SD in Fig. 6.5
Part I was an informal introduction to OPM and SysML, in which we used a detailed case study of the
Automatic Crash Response system. We have discussed aspects of OPM and various SysML diagram
kinds. Part II provides a more formal and theory-grounded exposure of OPM and SysML. It covers in an
orderly fashion the ontology, conceptual modeling constructs, and applications. Chapter 9 introduces and
defines what conceptual modeling is and what is its purpose and context. Chapter 10 presents the two
basic building blocks of OPM—objects and processes. In a similar fashion to the way Part I is structured,
Chap. 11 is about the textual modality of OPM—OPL. In Chap. 12 we turn to an orderly study of SysML
with its four pillars and nine kinds of diagrams. The dynamic, time-dependent aspect of systems is the
focus of Chap. 13. This is naturally followed by studying the structural, time-independent system aspect
in Chap. 14. Following Chap. 15, which deals with participation constraints and fork links, in Chap. 16
we introduce the four fundamental structural relations. This concludes Part II. In Part III, titled Structure
and Behavior—Diving In, we turn to elaborate on each of the four fundamental structural relations
separately and continue with whole system aspects, including complexity management and control.
Chapter 9
Conceptual Modeling: Purpose and
Context
A conceptual model is a formal model, in which every entity being modeled in the real
world has a transparent and one-to-one correspondence to an object in the model.
Simmons (1994)
Before going into formal presentations of OPM and SysML as conceptual system modeling languages and
OPM as a systems engineering methodology, we discuss the theoretical aspects underlying the framework of
systems, systems architecture, and systems engineering, within which conceptual modeling is a valuable
intellectual activity.
apparent. This, in turn, requires a solid infrastructure for recording, storing, organizing, querying, and
presenting the knowledge being accumulated and the creative ideas that build on this knowledge.
and detail level of the model. We can rephrase the above principle almost inversely: A language with
fewer symbols and fewer diagram kinds that is based on a universal ontology can describe any system
with better comprehensibility than a language with more symbols and more diagram kinds.
Alleviating the human cognitive load is highly desirable, because the modeler must cope with the
inherent, irreducible complexities of man-made systems to be built (systems engineering) or natural
systems to be investigated (science), so reducing the unnecessary complexity (often called
complicatedness) by providing a simpler language is of tremendous value.
Q10: what are the two universal aspects, i.e., the two aspects from which things in the universe can be
viewed, considered, and described?
A10: The two universal aspects are (1) structure—the way objects relate to each other and processes
relate to each other—and (2) behavior—the way processes transform objects over time.
This first version of the Object-Process Corollary says nothing about the level of complexity of the
systems that are amenable to being modeled with stateful objects, processes, and relations among them.
9.2.5 Why Not Just One Kind of Thing? A Graph with Nodes and Links?
One may argue that an even more minimalistic representation than three kinds of elements—objects,
processes, and relations among them—could be just two: things and relations among them. Indeed, quite a
number of knowledge representation frameworks have come up with this idea of representing knowledge via
a graph with nodes of just one kind and links connecting them. Some of these frameworks, which vary in
their level of formality, are surveyed in Dori (2004). These include the concept maps (Arnheim 1969),
entity-relationship diagram (Chen 1976), semantic networks (Lehman 1999), conceptual graphs (Chein and
Mugnier 1992), and systemigrams (Blair et al. 2007). Looking at examples of graphs expressed in these
approaches, one quickly reveals that since there is only one kind of node, there is no distinction between an
object and a process, so the ability to distinguish between structure and behavior—the two distinct facets
that must be represented in any model—is severely crippled, or even nonexistent. At the small price of
increasing the number of elements in the ontology from two to three, we gain a tremendous capability of
concurrently modeling both the structure and the behavior of a system.
Indeed, objects are the things that exist. Relations among them constitute the structure of the system.
This is the static, structural aspect of the system. To understand the system’s dynamic, procedural aspect,
to know what happens to objects in the system and how it operates to provide value, a second,
complementary type of thing is needed—a process. We know of the existence of an object if we can name
it and refer to its unconditional, relatively stable existence, but without processes we can neither tell how
this object is created or destroyed, nor how its states change over its lifetime.
Dori – Model-Based Systems Engineering with OPM and SysML 81
A stateless object is an object that has no states. A stateful object is an object that has one or more
states. These states are stable in the sense that it takes a process to switch an object from one of its states
to another, and as long as no process acts on the object, the object remains in the same state.
Figure 9.1 presents the main symbols of OPM. The symbols for object, state, and process are
respectively shown as the first (left-most) group of symbols. The rest of the symbols are links: structural
links are shown in the middle group and procedural links—in the right-most group. Their names and
semantics have been mentioned in Part I, and will be further elaborated as we proceed.
Objects and processes, collectively referred to as OPM things, are the two types of OPM’s universal
building blocks. OPM views objects and processes as being on equal footing, so processes are not
necessarily subordinate to or owned by objects. Symmetrically, objects are not necessarily inferior to
processes, nor are processes necessarily owned by objects.
State is depicted in Fig. 9.1 between object and process. Discussed in more detail later on, state is a
situation in which an object can be at some point during its lifetime.
Being able to tell objects and processes apart and use them properly in a model is key to modeling in
OPM. To define these fundamental concepts and to communicate their semantics, we next discuss the
concepts of existence and transformation.
A state is a possible situation or position at which an object can be for some positive
amount of time.
This definition implies that a state has a meaning only within and in the context of an object. A state
has no meaning out of the contexts of its owning object. For example, states of the object Organization
can be private or public, and states of the object Record can be locked or unlocked. The states private and
locked have no meaning outside the context of their respective owning objects.
Fig. 9.2 Two concepts for a nail-driving system: Top-left: hammer; Top-right: DEWALT 18-Volt 18-Gauge 2 in.
Cordless Brad Nailer; Botto-left: OPD of the Nail-Driving System; Bottom-right: The corresponding OPL1
In a simple system, such as a nail-driving system—the hammer shown at the top-left of Fig. 9.2, being
a combination of two interacting elements—head and handle—the number of interacting parts is not the
predominant feature. What is important is that the hammer is a system that provides the function of nail
driving. Looking closely at this hammer, one can distinguish lower-level functional elements, such as
claw to extract nails, but they are not really separate parts, further emphasizing the functional aspects of
this system. The same function of nail driving can be accomplished by a much sophisticated system, such
as the one presented on the top-right of Fig. 9.2. Although this is a much more complex system, it
provides basically the same nail-driving function (and is indeed called “nailer”).
The OPM model (the OPD and the corresponding OPL) at the bottom of Fig. 9.2 emphasize the
common function of these two systems. The difference between the two systems is in several
performance metrics that can be deduced from the following description, provided in the Web site of this
product: “The DEWALT DC608K—18 Gauge 2 in. Cordless Brad Nailer delivers consistent nail
1
From this point on, the OPDs are not shaded, as they are accompanied by their corresponding OPL paragraphs. The
colors of the various OPL phrases in the OPL here are as they appear in OPCAT. In subsequent OPLs, reserved OPL
phrases are in non-bold Arial font, and non-reserved phrases—in Bold Arial.
Dori – Model-Based Systems Engineering with OPM and SysML 85
penetration into both soft and hard joints. The sequential operating mode allows for precision placement
and the bump operating mode provides the user with production speed. The straight magazine, accepts 18
gauge nails ranging in lengths from 5/8 in. to 2 in. Its 12-position dial allows the user to move between
applications without having to re-acquire exact depth setting.” As we see, the function of this system is
described as delivering “nail penetration”, same as a hammer, albeit possibly with better speed, power,
and accuracy. Thus, according to our definition of system, both hammer and the Cordless Brad Nailer are
nail driving systems.
Fig. 9.3 Search results of images of “bathing system” (top) and “sitting system” (bottom)
Figure 9.4 is an OPM model of the Nail-Driving function and the Nail-Driving System—the instrument
for achieving this function. The method used with each kind of Nail-Driving System can be captured in the
diagram as a specialization of Nail-Driving. Hammer and Cordless Brad Nailer are two such
specializations; they are incarnations of two different concepts for achieving the system’s function: The
Hammer, which is basic, and the Cordless Brad Nailer, which is more complex (and consequently more
expensive).
Fig. 9.4 OPM model of the Nail-Driving function and Nail-Driving System with its Hammer and Cordless Brad Nailer
specializations
A beneficiary is a stakeholder who extracts value and benefits from the system.
Customers (either real or potential) are key stakeholders.
A customer is the stakeholder who orders the system and sponsors its development,
implementation, deployment, and support, or purchases a product that is part of the
system.
The first kind of customer in the definition above is usually an organization who needs a specially-
designed system and orders it from the supplier (defined below). The second kind is usually an individual
who purchases a consumer good that was designed and manufactured by a supplier based on the
anticipation that people will be willing to pay for it because the customer foresees the value that this
system (in this case product, defined below) would deliver. Either way, without customers it is hard to
imagine why a system would be developed in the first place.
A user is a stakeholder who operates the system or directly interacts with it.
For relatively simple systems, such as household products, the customer and the user are the same. For
example, a car owner who drives it is the customer, user, and beneficiary, while other passengers are only
beneficiaries. Beneficiaries of a national missile defense system are the country’s citizens, although they
are neither the users nor the customers. The supplier is another key stakeholder.
more recently, systems engineering. Non-trivial systems, which are the focus of interest of systems
engineering, comprise a significant amount of processes acting to transform a large number of
interconnected objects (the system’s components) in a way that enables the attainment of the system’s
function.
In both the nautical and the aeronautics cases, rudder is a subsystem of a vehicle—a vessel and an
airplane, respectively, with the function of changing course or turning or navigating the vehicle. This
function of the rudder is part of the function of the vehicle, which is people and goods moving, and which
requires also propulsion, supplied by the vehicle’s propulsion subsystem.
Structure is the static, time-independent aspect of the system:
It might be interesting to compare our definition of architecture to the one used by the U.S. DoD
Architecture Framework (DoDAF 2007), which is based on IEEE STD 610.12:
Architecture: the structure of components, their relationships, and the principles and guidelines
governing their design and evolution over time.
TOGAF (2011) provides a similar definition in response to the question “What is an Architecture?”
An Architecture is the fundamental organization of something, embodied in its components, their
relationships to each other and the environment, and the principles governing its design and
evolution.
The common element in both definitions and our definition of architecture is the system’s structure.
However, the DoDAF and TOGAF definitions lack the integration of the structure with the behavior to
provide the function. On the other hand, the DoDAF definition includes “the principles and guidelines
governing the design and evolution of the system’s component over time”. However, these do not seem to
be part of the system’s architecture. Rather, principles and guidelines govern the architecting process,
which culminates in the system’s architecture. Interestingly, DoDAF Architecture Framework Version
2.02, Change 1 (DoDAF 2015), the version of January 2015 does not contain any clear definition of
architecture (and neither does the 2009 edition)!
The system’s environment is a collection of things that are outside the system but
interact with it.
The interaction of the system with its environment causes the system, and possibly its environment, to
change. To ensure sustainability, systems engineers must make sure to prevent or undo this adverse
change, especially as it pertains to possibly irreversible detrimental effects of current and contemplated
systems on global warming and natural resource depletion. This is not just a moral or ethical obligation—
it is a matter of securing sustainable life on earth of all organisms, including people, beyond the next
couple of decades…
A thing which is part of the system is systemic, while a thing which is part of the system’s
environment is environmental. The OPM thing’s attribute whose values are systemic and environmental
is affiliation. Making the distinction between systemic and environmental things is very important in
modeling, as it indicates what are the things that the architect can have control of and what should be
considered as given. For example, in designing a gas station, is the car systemic or environmental?
Obviously, cars and their drivers are going to interact with the gas station, but the gas station architect
does not have a control over the sizes of the cars and the locations of their gas tank openings—these are
given and must be accounted for. Therefore, car is environmental to gas station.
Dori – Model-Based Systems Engineering with OPM and SysML 91
Syntax is the language’s set of symbols and rules that specify how the symbols can be
combined to yield syntactically-legal constructs.
Not any syntactically-legal construct in the language is meaningful.
actual part from this model. As another example, Newton’s second law, F= m×a, is a formal model of the
relation between a rigid body’s force, mass, and acceleration, expressed as a mathematical equation.
Interestingly, however, the rigid body, with which this model is concerned, with mass and acceleration
being its attributes, is nowhere to be found in this model. Rather, it is implicit that this is the subject of
this model. This still conforms to our definition of a model as an abstraction of some portion of conceived
reality.
System
Fig. 9.5 An example of an informal model—Basic building blocks of a system (ISO/IEC 26702 IEEE Std. 1220-2005)
schematically and in two dimensions). Unfolding of things (objects or processes) exposes their parts,
features (attributes or operations), specializations, or instances. Both refining processes—in-zooming and
unfolding—can be done in the same OPD or in a new OPD. New OPD refining (in-zooming or unfolding)
creates a new OPD in which the refined thing is elaborated to express more details.
9.6 Summary
Science can be thought of as reverse engineering of nature.
The Minimal Ontology principle states that if a system can be specified at the same level of
accuracy and detail by two languages of different ontology sizes, then the language with the
smaller size is preferred over the one with the larger size.
Objects exist, processes happen.
Ontology is a set of concepts and their relations in some domain of discourse.
A minimal universal ontology is the ontology that is necessary and sufficient to model the universe
and systems in it.
The Object-Process Theorem: Stateful objects, processes, and relations among them constitute a
minimal universal ontology.
The Object-Process Assertion: Using stateful objects, processes, and relations among them, along
with refinement mechanisms of in-zooming and unfolding, one can conceptually model systems in
any domain and at any level of complexity.
The thing importance OPM principle: The importance of a thing T in an OPM model is directly
related to the highest OPD in the OPD hierarchy where T appears.
An object is a thing that exists or can exist physically or informatically.
A state is a possible situation or position at which an object can be for some positive amount of
time.
Transformation of an object is (1) creation (generation, construction), (2) consumption
(elimination, destruction), or (3) effect—change in the state of that object.
A process is a thing that transforms an object.
The object transformation by process OPM principle: In a complete OPM model, each process
must be connected to at least one object that the process transforms or one state of the object that
the process transforms.
A system is a function-providing object.
A stakeholder is an individual, an organization, or a group of people that has an interest in, or
might be affected by, a system being contemplated, developed, or deployed.
A beneficiary is a stakeholder who extracts value and benefits from the system.
A customer is the stakeholder who orders the system and sponsors its development,
implementation, deployment, and support.
Dori – Model-Based Systems Engineering with OPM and SysML 95
A user is a stakeholder who operates the system or directly interacts with it.
A supplier is a stakeholder who oversees the development, support, and maintenance of the system
or product.
A function of an artificial system is its top-level value-providing process, as perceived by the
beneficiary.
Structure of a system is its form—the assembly of its physical and informatical components along
with the long-lasting relations among them.
Behavior of a system is it dynamics—the way the system changes over time by transforming
systemic (internal) and/or environmental (external) objects.
Architecture of a system is the combination of the system’s structure and behavior which enables it
to perform its function.
The system’s environment is a collection of objects that are outside the system but interact with it,
causing the system and possibly its environment to change.
The function-behavior distinction: Behavior is how the system changes along the time dimension,
while function is what value the system delivers to its beneficiary through its operation.
A language is a means of communication among humans, and possibly also machines, to express
concepts, ideas, processes, and methods.
Syntax is the language’s set of symbols and rules that specify how the symbols can be combined to
yield syntactically-legal constructs.
Semantics is the meaning that a subset of the language’s syntactically-legal constructs conveys.
A model is an abstraction of some portion of conceived reality or of a contemplated system
expressed in some language.
A modeling language is a language for constructing models in some domain.
A formal modeling language is a modeling language that has a mathematically-grounded syntax
definition, enabling its automated analysis, checking, and synthesis.
A formal model is a model expressed in a formal modeling language.
A conceptual model is a formal model of a system which expresses its architecture by depicting its
structure and behavior to a level of detail that is sufficient for its subsequent detailed design and
eventual materialization.
A conceptual modeling language is a formal modeling language for constructing conceptual
models of systems.
9.7 Problems
1. Referring to the OPD in Fig. 7.4, find:
A process which is more important than an object,
96 Conceptual Modeling: Purpose and Context
the informatical point of view, all the physical copies of some informatical object are the same. Two
copies of the same book are identical insofar as their informatical content (semantics) is considered. They
are printed on separate pages and bound as two distinct physical object instances. Even if one copy is a
paper copy and the other is electronic, from the informatical viewpoint they are still the same.
From the informatical viewpoint, two identical (paper or computer) files containing blueprints and
manufacturing instructions for a Model X car are, the same object, because the informatical content they
convey is identical. Physically, the pieces of media, on which this physical object is recorded, are
different, since they are physical matter that obeys the laws of nature. Likewise, two copies of the same
file are physically different, as they occupy different address spaces in the computer’s primary or
secondary memory. However, when viewed as informatical objects, they are identical.
At any given point in time before, during, or after the occurrence of the process, the observed object
can potentially be different from what it was in a previous point in time. Using our human memory, we
get the sense of a process by comparing the present form of the object being transformed to its past form.
Hence, a process exists only as a concept, a mental construct in humans’ minds. We give names to
processes to refer to changing patterns of objects. Focusing on transformation, we adopt the following
definition.
Earlier we said that objects exist and processes happen. Here we just said that a process exists, but
only as a mental construct. In this regard, we could think of processes as (mental) objects too, and devise
a modeling paradigm that is based only on objects as “first class citizens”, arguably having an even more
compact universal ontology than OPM. Indeed, this is the object-oriented approach. However, as we
show throughout the book, the value of adding process as a concept in the universal ontology that is
separate from object far exceeds the price of adding another concept to this ontology.
We use the suffix “ee”, as in employee, here and in several other cases defined soon, to create a new
word that denotes an object which a process (verb) X acts on. Here, X = Transform. We will soon
encounter also Consumee, Resultee, and Affectee.
In a theoretic, frozen, static universe at absolute zero, no processes exist and no transformation occurs.
Without processes, all we can describe are static, persistent structural relations among objects. In realistic
earthly settings, processes and objects are of comparable importance as building blocks in the description
and understanding of natural systems and the universe as a whole (which is the mission of science), and
of designing artificial systems (which is the mission of engineering).
10.4.1 Are Objects and Processes the Semantic Analogues of Nouns and Verbs?
In natural languages, almost invariably, objects are syntactically represented as nouns. Processes are
syntactically often represented as verbs, but they can be nouns too. For example, brick is syntactically a
noun and semantically an object, while constructing is a verb and a process. However, construction in the
context of “the construction process” is also a noun, although semantically it is the same as “the
constructing process.” To make the point, we note that the phrase the construction process is plausible,
while the brick process is not. Likewise, the phrase the brick object is plausible, while the construction
object (where object is not referred to as a synonym for goal) is much less plausible. Even more
Dori – Model-Based Systems Engineering with OPM and SysML 103
confusing is the object building (noun), which is the outcome of the building (constructing) process. It is
spelled and uttered the same as the process of building (verb). It is only from their context inside a
sentence that these two semantically different words are distinguishable.
A common software design strategy is the noun/adjective/verb object oriented design strategy
(MacIntyre 2010). In his blog, MacIntyre wrote:
… Then I learned C++, object oriented programming, and was introduced to the holy grail of object
oriented design advice, which went something like this: Take your requirements and circle all the nouns,
those are your classes. Then underline all the adjectives, those are your properties. Then highlight all your
verbs, those are your methods.
This Noun/Adjective/Verb design strategy seemed like the most ingenious piece of programming wisdom
ever spoken … but it’s led us down a misguided path. It’s the verb that’s misunderstood. The verb
should be another class, not a method. It should be a process class. As a programming concept, a
process is just as much a ‘thing’ as any real world object. The verb should be a class, which accepts the
noun as an input to be processed.
Interestingly, MacIntyre intuitively arrived at the conclusion that the verb is “another class”
(emphasis in source). He realized that a process is not less important than an object, and therefore should
not be a method owned by an object but a “process class” in its own right.
The examples discussed above demonstrate that the tempting assertion that object and process are the
semantic analogues of the syntactic concepts noun and verb is at best crude and inaccurate. Hence, rather
than relying on the syntactic notions of parts of speech, we need to establish a semantic, content-based
way to analyze words in a sentence that would enable us to tell objects from processes. This will enable
us to overcome the pitfalls and idiosyncrasies of natural languages.
The preprocess object set of a process P, Pre(P), is the set of objects required to exist,
possibly in certain states, in order for P to start executing once it was triggered.
The triggering object itself is not part of the preprocess object set. Existence of the preprocess object
set, is the process precondition—the condition for the occurrence of the process. Being a process, the
noun representing it does not exist, but rather occurs, happens, operates, executes, transforms, changes, or
alters at least one other noun, which would be an object.
Let us consider two process examples: Flight and Manufacturing, shown in Fig. 10.1. In the Flight
example (the OPD on the left), Airplane, Pilot, and Runway are objects in the preprocess object set, since
Flight cannot occur without them. In set notation: Pre(Flight) = {Airplane, Pilot, Runway}.
For Manufacturing (the OPD on the right), the preprocess object set consists of Raw Material,
Operator, Machine and Model: Pre (Manufacturing) = {Raw Material, Operator, Machine, Model}. Product
is not in this set since it does not exist yet and is not needed for the process to start happening.
Fig. 10.2 Example of a state-specified object, open Runway, in the preprocess object set of Flight
Similarly, as the OPD on the right in Fig. 10.2 shows, in order for Manufacturing to take place, it is
required that Machine be operational and Model be updated. In this case, the result will be pre-tested
Product. In set notation: Pre (Manufacturing) = {Operator, Raw Material, operational Machine, updated
Model}. This is expressed in the three corresponding OPL sentences:
Operator handles Manufacturing.
Manufacturing requires operational Machine and updated Model.
Manufacturing consumes Raw Material.
The postprocess object set of process P, Post(P), is the set of one or more objects that
exist, possibly in certain states, after P finished executing.
Existence of all the objects in the postprocess object set, some possibly in specified states, is the
postcondition of that process.
The preprocess object set and the postprocess object set are not necessarily disjoint; they may be at
least partially overlapping. In the Flight example in Fig. 10.1, all three objects in the preprocess object set,
Airplane, Pilot, and Runway, are also in the postprocess object set: Post (Flight) = {Airplane, Pilot,
Runway}. We should note, however, that only Airplane and Pilot are transformed: their Location attribute
change from origin to destination. In Fig. 10.2 this is not modeled explicitly, only implicitly, specifying
that Airplane and Pilot each undergoes some state change.
In the Manufacturing example in Fig. 10.1, Raw Material, Operator, Machine and Model are in the
preprocess object set, while Operator, Machine, Model, and Product are in the postprocess object set: Post
106 Things: Objects and Processes
Fig. 10.3 pre-tested Product is in the preprocess object set, while tested Product is in the postprocess object set
The involved object set of process P, Inv(P), is the union of P’s preprocess object set
and postprocess object set.
In set notation: Inv(P) = Pre(P) ∪ Post(P).
In the examples in Fig. 10.1, Inv (Flight) = {Runway, Pilot, Airplane}, and Inv (Manufacturing) =
{Operator, Machine, Model, Raw Material, Product}.
Fig. 10.4 The procedural link uniqueness OPM principle demonstrated Left: Expressing Person as both agent and
affectee of Eating is made possible via state expression. Right: When the states are suppressed, only the effect link
remians
For example, in the OPD on the left of Fig. 10.4, when a Person is engaged in Eating, Person is both
the agent, since Person handles Eating, and the affectee of this process, since Eating changes Person from
hungry to satisfied. This is possible because the states hungry and satisfied of Person are expressed.
When the states are suppressed (on the right), we cannot have both agent and effect links between Person
and Eating, so we must make a choice. As we define formally and explain in more detail in Sect. 21.13,
the choice of the link is based on the precedence of the procedural links. Since a transforming (in our case
effect) link is semantically stronger than an enabling link (in our case agent), the effect link prevails. We
can still use both links if we zoom into Eating, exposing its three subprocesses: Food Picking, Food
Swallowing, and Food Digesting. Only the latter subprocess affects the Person, so now Person can be
linked with an agent link to Food Picking and Food Swallowing, and with an effect link to Food
Digesting. When zooming out of Eating and suppressing the states of Person, Person and Eating will
again be linked by the effect link, since overall the state of Person changed, in line with the link
precedence.
As another example, Truck is obviously an instrument for Transporting. Transporting zooms into
Loading, Moving, and Unloading. Loading changes Truck from unloaded to loaded, so Truck it is
obviously affected. However, after Moving is over, Unloading changes Truck back from loaded to
unloaded, so as a whole, inspecting Truck from the Transporting level, Truck is unaffected and hence can
be modeled as an instrument of Transporting rather than its affectee.
108 Things: Objects and Processes
An object may have the role of an instrument in an abstract OPD and a transformee in another
descendent, more detailed and concrete OPD. At the abstract OPD, the process does not appear to affect
the object, because the object’s initial state is the same as its final state. Therefore, at the abstract OPD the
object is an instrument, as indicated by an instrument link. However, at a descendent, more concrete
OPD, that same process does appear to change the state of that object from the initial state and then back
to the initial state.
As a final example, in Fig. 10.5, the left OPD (SD: Dish Washing System), a Dishwasher object is an
instrument for the Dish Washing process, since no change in state of the Dishwasher is visible at that
extent of abstraction. In the descendent OPD (SD1: Dish Washing in-zoomed), Dish Washing zooms into
Loading (of a dirty Dish Set), Cleaning (which changes Dish Set from dirty to clean), and Unloading (of a
clean Dish Set). Loading changes the state of Dishwasher from empty to loaded, while Unloading
changes it back from loaded to empty, so empty is both the initial and final state. While the Dishwasher
is an instrument in SD, the System Diagram, at the descendent, more detailed OPD, the Dishwasher is an
Dori – Model-Based Systems Engineering with OPM and SysML 109
affectee—it becomes loaded and then empty again. The only effect visible in the System Diagram is the
effect on Dish Set.
The time association criterion is satisfied if the noun in question can be thought of as
happening through time.
Continuing our example, both Flight and Manufacturing start at a certain point in time and take a
certain amount of time. Both time and duration are very relevant features of these two nouns in question.
The verb association criterion is satisfied if the noun in question can be derived from,
or has a common root with a verb or has a synonym which is a verb.
Flying is the verb associated with Flight. The sentence “The airplane flies” is a short way of
expressing the fact that the Airplane is engaged in the process of Flight. Similarly, to manufacture
(produce, yield, make, create, generate) is the verb associated with Manufacturing. The sentence “The
operator manufactures the product from raw material using a machine and a model.” is the natural
language short way of the OPL paragraph on the right in Fig. 10.1.
Here we rely on verb—a syntactic construct, but is not mandatory that the verb be syntactically from
the same root as the process name; it can be a synonym as long as the semantics is the same. For example,
Marrying is a process, which is associated with the verb to marry. To wed is also a legal verb, albeit less
frequently used. Alternatively, we could use Wedding to fit it to the verb wed. Many objects, such as
Dori – Model-Based Systems Engineering with OPM and SysML 111
Apple and Airplane, are not associated with any verb, so they do not fulfill this process criterion. It is easy
to verify that both Apple and Airplane do not meet the other process test criteria either. Boundary cases of
things exist, as discussed in Sect. 10.10 with examples.
Fig. 10.7 An OPM model of a box with one (left) and six (right) pencils
112 Things: Objects and Processes
Tags of tagged structural relations are also non-capitalized either, as in the OPL sentence “Box
contains Pencil.” which is the textual modality of the OPD on the left of Fig. 10.7. The tag contains along
the arrow from Box to Pencil is lower-case.
The process name in the running example in Part I of this book, Automatic Crash Responding, could
be simply Responding, but that might seem too general, since it does not specify what the response is for.
Even Crash Responding alone is not quite sufficient, as it could be done without an automated system.
We also avoid calling this process Response, as this name does not follow the gerund process naming
mode and can be justifiably conceived as an object—the outcome of the responding process.
The recommended gerund process naming mode comes in several versions of increasing length and
information content:
1. The transforming (verb) version: the process name (syntactically the gerund form of the verb, namely
verb + ing), as in Making or Responding.
2. The object transforming version: a concatenation of an OPM object (syntactically a noun) with the
process name (syntactically the verb’s gerund), as in Cake Making or Crash Responding. This is the
recommended naming mode in most cases.
3. The qualified transforming version: a concatenation of an attribute value (syntactically an adjective)
with the process name, as in Quick Making or Automated Responding.
4. The qualified object transforming version: a concatenation of an attribute value with an object and
the gerund. The attribute value can qualify the process, as in Quick Cake Making or Automatic Crash
Responding, or it can qualify the object, as in Sweet Cake Making or Fatal Crash Responding.
A second process naming option, often used by modelers, is the imperative process naming mode, as
in “respond” or more specifically, “respond to crash”, or “automatically respond to crash”. OPM
discourages this mode, because it is less compact and less elegant, and the OPL sentences created using
this mode in the current OPM 19450 are awkward. Modeling languages usually do not prescribe such
naming conventions. Modelers are therefore unaware of nuances such as the difference between the
gerund and imperative process name modes. The Functional Analysis approach advocates naming
functions imperatively: “Start Engine”. “Launch Missile”, “Turn Left”, but this does not seem to be a
premeditated and mandatory way, just a short and sometimes convenient way of expression.
Consequently, many modelers use both the gerund and the imperative process name modes
interchangeably or in a mixed way, making the model less coherent and unnecessarily more cognitively
demanding.
As we shall see, objects and processes have much in common in terms of being specified through
structural relations such as aggregation, generalization, and characterization. The need to talk about these
two concepts in a generalized way, without repeating “object or process” over and over again,
necessitates the advent of a yet more abstract term. We call this simply a “thing.”
A system’s primary essence is the Essence value of the majority of the things in the
system.
The default essence value of a thing is the primary essence of the system. The motivation, based on
experience, for defining the primary essence is to save the modeler the need to mark the vast majority of
the things in the system as either informatical or physical. A supporting tool should therefore provide an
option for the modeler to specify a system’s primary essence as a means to reduce the amount of things
for which the modeler has to specify their essence.
The OPL paragraph corresponding to an OPD should not include an OPL sentence to indicate the
Essence or Affiliation value of a thing if it is the default, unless the thing is isolated—it has not yet been
connected to any other thing during the course of the modeling process. The reason for this is the need to
avoid violating the graphics-text OPM principle. Suppose the default essence of the OPDs in Fig. 10.9 is
physical. Upon drawing the physical object Car and prior to linking it to anything, the OPL sentence “Car
is physical” shall appear, as shown in the OPD on the left, otherwise there would be a thing (Car)
depicted in the OPD that has no mention in the OPL, violating the graphics-text OPM principle. However,
116 Things: Objects and Processes
as soon as the isolated thing becomes linked to another thing, as shown in the OPD on the right, the OPL
sentence dedicated to specifying the thing’s default Essence or Affiliation shall be removed.
Fig. 10.9 The primary essence of the Car Anti-lock Breaking System (ABS) is physical, therefore, once Car is linked to
ABS, the first sentence is removed from the OPL sentence
Each one of these processes can be considered as a change-preventing process—a process that works
against some “force” which would otherwise change the operand—the object being operated on. For
example, Supporting of a Laptop can be rephrased as Fall Preventing, Keeping of a Coin can be rephrased
as its Loss Preventing, and Holding of a Hostage can be rephrased as Escape Preventing of that Hostage.
Due to their nature as state-preserving, these “pseudo-processes” might rather be modeled using tagged
structural relations between two objects. We discuss this in the context of structural relations.
Fig. 10.11 Spark as a transient object (left) and modeling without it using the invocation link (right)
Looking back at Fig. 10.10 and comparing it to Fig. 10.11, we can see the pattern: The use of the
invocation link as a shorter version of modeling generation and immediate consumption of a transient
object is analogous to the use of the tagged structural link as a shorter version of modeling a persistent
process. Another example is Signaling and the transient object Signal.
Dori – Model-Based Systems Engineering with OPM and SysML 119
Fig. 10.12 Tanning top level (left) and an in-zoomed view (right)
In the OPM ontology, Skin is an object, while dark and pale are states of an attribute of the object
Skin called Complexion. Skin is one of the parts of Person. Tanning is a process, and Sun is an instrument
that enables the Tanning process, the effect of which is to change the Complexion of the Skin from pale to
dark. This terminology and the OPM model in Fig. 10.12 seem more intuitive and appropriate for non-
mathematical systems than the operand, operator and transform ontology. The “sunshine factor” is a bit
problematic to describe. It is not clear whether it refers to the shining process of the sun or to the object
that aggregates the photons of energy radiated by the sun, which the skin absorbs.
120 Things: Objects and Processes
In OPM, we would model Radiating as a first subprocess of Tanning. Radiating requires (i.e., is
enabled by the instrument) Sun. Radiating, in turn, produces the object Solar Energy, which is absorbed
by the Skin via the second subprocess, Absorbing & Pigmenting, the one that changes the Complexion of
Skin from pale to dark. In summary, the operator is the process (Tanning). The operand is the affectee in
its state before the process occurred (Skin in its pale Complexion state), while the transform is its state
after the process occurred (Skin in its dark Complexion state).
10.12 Summary
A property is a metamodel attribute of an OPM element. A property value of each element in an
OPM model remains fixed.
The OPM approach considers processes as “first class citizens” alongside objects rather than
below object.
An object is a thing that exists or has the potential of physical or informatical existence.
Two instances of a physical object are identical if and only if they occupy the same space at the
same time.
From an informatical viewpoint, all the physical copies of some informatical object are the same.
Transformation is generation (construction, creation) or consumption (destruction, elimination)
or change (effect, state transition), of an object.
A process is a mental construct representing a pattern of object transformation.
In “cause and effect” analysis, cause is a triggering event that attempts to cause a process to start
executing.
The effect in “cause and effect” analysis is the transformation that one or more of the objects
linked to the executing process undergo.
Parts of speech (noun, verb, adjective, adverb …) are syntactic constructs, while OPM things
(object and process) are semantic constructs.
The preprocess object set of a process P, Pre(P), is the set of objects required to exist, possibly
in certain states, in order for P to start executing once it was triggered.
The postprocess object set of process P, Post(P), is the set of one or more objects that exist,
possibly in certain states, after P finished executing.
The involved object set of process P, Inv(P), is the union of P’s preprocess object set and
postprocess object set: Inv(P) = Pre(P) ∪ Post(P).
The object-process distinction problem is the problem of telling whether a given a noun is an
object or a process.
The process test is a formal procedure for solving the object-process distinction problem.
The process test assumes that by default, a noun is an object, so to be a process it must meet
three criteria: (1) object transformation, (2) time association, and (3) verb association.
Dori – Model-Based Systems Engineering with OPM and SysML 121
o The object transformation criterion is satisfied if the noun in question transforms at least one of
the objects in the involved object set.
o The time association criterion is satisfied if the noun in question can be thought of as happening
through time.
o The verb association criterion is satisfied if the noun in question can be derived from, or has a
common root with a verb or has a synonym which is a verb.
The capitalization OPM convention is that the first letter in each word of the name of a thing is
capitalized, while states are lower-case.
The singular name OPM principle specifies that a name of an OPM thing must be singular.
The OPM process naming convention is to name a process by making its last word a gerund
whenever this is possible and is acceptable and makes sense in the domain nomenclature.
Thing is a generalization of object and process.
A state-preserving process is a process that maintains a steady state of status quo, and can be
suppressed by replacing it with a tagged structural relation.
A transient object is a short-lived object, and can be suppressed by replacing it with an
invocation link.
10.13 Problems
1. Give an example of a scientific discovery and explain how it can be thought of as reverse
engineering of nature.
2. Why is it impossible to touch a process even if it is physical?
3. Why is a process in an OPD that has no transforming link attached to it meaningless?
4. Who are the “players” in cause and effect analysis? What is the role of each one of them?
5. Give an example of two sentences that express the same fact but have different parts of speech.
6. What are the objects and processes in the first sentence above? And in the second?
7. Construct an OPM model of the system described in the previous question.
8. In the OPM model of the process test system in Fig. 10.6, what are the members in the
preprocess object set, in the postprocess object set, and in the involved object set?
9. Select two things from the OPD in Fig. 10.3 and apply the process test on each one of them.
10. What is the preferred way of modeling persistent processes?
11. What is a possible shortcut for modeling transient objects?
12. Model the following specification: Running of an internal combustion engine is contingent upon
the presence of the objects air and gasoline vapor mixture inside the object cylinder at the right
pressure and temperature (attributes of mixture). The triggering event is the point in time when a
spark (created by a previous timed process) ignites the mixture. As a result of this process, the
gasoline mixture is consumed and the piston’s kinetic energy value increases.
Chapter 11
Object-Process Language: The Text
Among general-purpose modeling languages dominate the graphical ones such as
UML; textual modeling languages are not as popular though they have a big
potential.
Mazanec and Macek (2012)
OPM is bimodal: it employs both the visual (graphical) modality—OPD, and the verbal (textual)
modality—OPL. The textual OPL representation of the OPM model has both human-oriented and
machine-oriented goals. This chapter is devoted to presenting OPL and discussing its merits.
OPL is defined formally using a context-free grammar, so the OPL text file can serve as a basis for
generating application artifacts that include executable code and database schema. This approach enables
round-trip engineering, in which changes in the analysis, design and specification are almost
automatically reflected in the final application. These traits make the combination of the graphic-oriented
OPD and its equivalent text-based OPL counterpart an ideal infrastructure for systems specification.
An OPL specification (OPL Spec) of an OPM model is the collection of all the unique
OPL sentences that express textually all the model facts that the OPD set expresses
graphically.
specifies
OPM
Model System
graphically specifies
OPD OPL
Set textually specifies Spec
+ graphically specifies +
OPL
OPD Paragraph
textually specifies
Punctuation +
Link Set Mark
3..*
Phrase
Word +
Thing Set
2..* Thing
Name
The two objects at the top of the OPD in Fig. 11.1 are OPM Model and System, connected with a
unidirectional tagged structural link from the former to the latter, yielding the OPL sentence OPM Model
specifies System. Further, OPM Model consists of OPD Set and OPL Spec. These are the two
complementary modalities—the graphical and the textual. From this point on, the OPD shows two
parallel hierarchies—the graphical and the textual—where going down entails increased level of detail.
The graphical hierarchy is OPD Set, OPD, OPD Construct, and (at the same level) Link Set and Thing
Set. The textual hierarchy that is parallel to the graphical OPD Set and OPD is OPL Paragraph and OPL
Sentence. An OPD and its corresponding OPL Paragraph are collections of model facts that a modeler
places into the same diagram—the same model context. At the next refinement level in this hierarchy, an
OPD Construct is the graphical counterpart of its corresponding textual OPL Sentence, and again, both
express the same model fact. Then, Link, which is a graphic element, is paralleled by Reserved OPL
Phrase, since the latter textually specifies the former, as in the reserved OPL phrase consists of, which is
the textual counterpart of the aggregation-participation symbol, , and in affects, which is the textual
counterpart of the effect link, .
Fig. 11.2 Three exemplary production rules expressing the OPL syntax in EBNF
A reserved OPL phrase is an OPL phrase built into the OPL EBNF syntax definition
that connects two or more non-reserved OPL phrases.
Reserved OPL phrases are parts of the sentence syntax that express relations or connections between
non-reserved OPL phrases, or constrains on them. Examples of reserved OPL phrases are “requires”,
“yields”, “consumes” “and”, “or”, “affects”, “exactly one of”, “at least one”, and “consists of”. These
definitions of reserved and non-reserved phrases stipulate that the former are the mortar that “glues” and
holds together in a meaningful way the model building blocks—the non-reserved phrases that express
system-specific terms.
The following bolding OPL convention helps distinguish between the two kinds of OPL phrases.
The Bolding OPL Convention
Non-reserved OPL phrases appear in Arial bold font, while reserved OPL phrases appear in Arial
non-bold font. Punctuation marks are bolded.
For example, the OPL phrase “Automatic Crash Responding” in the OPL sentence “Automatic Crash
Responding affects Vehicle Occupants Group.” is non-reserved and therefore appears in Arial bold font.
The non-bold phrases, such as “and”, “or”, “affects”, “exactly one of”, and “consists of”, are reserved OPL
phrases.
A CASE tool implementation needs to automatically translate the model facts expressed by the OPD
constructs into OPL sentences. To further help distinguish between things, such tools should use colors in
fonts of phrases that match their colors in the OPD. For objects, the default color in OPCAT is green, for
processes—blue, for states—brown, and non-reserved OPL phrase are in black font. If your book version
Dori – Model-Based Systems Engineering with OPM and SysML 129
enables seeing colors, Fig. 10.6, which is an OPCAT-generated OPM model of the process test system,
exemplifies this coloring convention.
language. The syntax and semantics of OPL are well defined, eliminating the ambiguity that is often
inherent in natural languages.
The syntax of OPL is designed such that the resulting text constitutes plain natural, albeit syntactically
restricted, English sentences. Therefore, the bimodal graphics-text representation of the OPM model helps
involve non-technical stakeholders in the requirements elicitation and initial conceptual modeling of the
system under development. This involvement of such stakeholders engages them as active participants
and helps detect errors soon after their inadvertent introduction.
For example, suppose that instead of using the bidirectional arrow , which is the effect link, the
modeler of Fig. 1.3, would use by mistake the unidirectional arrow , which is the result link, from the
process Automatic Crash Responding to the object Vehicle Occupants Group to express the fact that
Automatic Crash Responding affects Vehicle Occupants Group. In this case, the following OPL sentence
would have been created:
Automatic Crash Responding yields Vehicle Occupants Group.
Obviously, this sentence, while syntactically correct, makes no sense. The modeler or the customer’s
representative participating in the modeling session would likely detect it on the spot. The detected error
can then immediately be rectified and the correction can be verified by simply reading the newly created
OPL sentence.
Any natural (and artificial) language can be selected as the target language to which the OPD
constructs are converted. Moreover, the graphic representation is language-neutral and can therefore serve
as a means for translating from one language to another.
lifecycle, before they had a chance to propagate and cause costly damage. Any graphics edit (addition or
removal of an element) changes the OPL script. Changes can be implemented until a satisfactory result is
obtained and the customer can “sign” on the model as the blueprint of the system to be developed.
Fig. 11.3 OPM model of Gas Metal Arc based Welding. Top: OPD. Bottom left: OPL. Bottom right: Tesperanto
Tesperanto is an enhancement of OPL that follows OPM’s gradual presentation principles, which
cater to humans’ cognitive limited capacity. It includes heuristics for sentence length adjustments,
synonyms, word ordering, phrase recurrence control, and other algorithms aimed at making the
132 Object-Process Language: The Text
Tesperanto text look less mechanistic and more human readable. Figure 11.3 is an OPM model of Gas
Metal Arc based Welding. The OPD at the top is automatically translated to both OPL and Tesperanto in
the bottom left and right, respectively. This simple example demonstrates the differences in fluency of
reading OPL vs. Tesperanto. While both text-from-graphics translations faithfully reflect the formal and
verified OPM graphic model, Tesperanto is more humanly readable and less boring, repetitive, and
mechanical. For example, while in the OPL the process Welding is repeated four times, once for each kind
of procedural relation, in the Tesperanto translation it only appears once. Since Tesperanto is still
evolving as a subject of research, it is not further used in this book.
11.8 Summary
Object-Process Language (OPL) is a subset of English that expresses textually the OPM model
that the OPD set expresses graphically.
The formal syntax for OPL is expressed by a context-free grammar in Extended Backus-Naur
Form (EBNF) in Annex A of ISO 19450 Publically Available Specification (PAS).
A model fact is a relation between two or more things in an OPM model.
An OPD element is the graphical expression of a thing or a link.
An OPD construct is a collection of connected OPD elements.
OPL serves two goals, oriented to two directions: humans and machines.
The human-oriented OPL goal is to convert the set of OPDs comprising the OPM model into a
natural language text.
The machine-oriented OPL goal is to provide a firm basis for automatically generating the
infrastructure for the application development.
An OPL paragraph of an OPD is a collection of OPL sentences that express textually the same
model facts that this OPD expresses graphically.
The graphics-text equivalence OPM principle: Any model fact expressed graphically in an OPD
is also expressed textually in the corresponding OPL paragraph.
A metamodel is a model of a model.
The metamodel of the structure of an OPM system model shows two parallel hierarchies—the
hierarchy of graphic objects and the corresponding hierarchy of text objects.
An OPL specification of an OPM model is the collection of OPL sentences that express textually
all the model facts that the OPD set expresses graphically.
An OPL phrase is a sequence of one or more words.
A non-reserved OPL phrase is a modeler-defined OPL phrase that expresses a system- or
domain-specific OPM model entity or relation name.
A reserved OPL phrase is an OPL phrase built into the OPL EBNF syntax definition that
connects two or more non-reserved OPL phrases.
Dori – Model-Based Systems Engineering with OPM and SysML 133
The dual-channel assumption is that humans possess separate systems for processing visual and
verbal representations.
The syntax and semantics of OPL are defined as a subset of English, eliminating the ambiguity
that is often inherent in natural languages.
Tesperanto is the next generation of OPL.
11.9 Problems
1. What are the pros and cons of having a textual system model specification modality alongside
the graphical modality?
2. If you were to design a new modeling language with the constraint that it can use only one
modality, which one would you choose? Why?
3. Which of the following three definitions of “meta”, taken from dictionary.com, fits metamodel?
4. A prefix appearing in loanwords from Greek, with the meanings “after,” “along with,” “beyond,”
“among,” “behind,” and productive in English on the Greek model: metacarpus; metagenesis.
5. A prefix added to the name of a subject and designating another subject that analyzes the
original one but at a more abstract, higher level: metaphilosophy; metalinguistics.
6. A prefix added to the name of something that consciously references or comments upon its own
subject or features: a meta-painting of an artist painting a canvas, metacognition; meta-analysis.
7. Copy three OPL sentences from this chapter and reverse their bolding, that is, make each bold
word not bold and vice versa. What version do you prefer—the original or the reversed? Why?
Chapter 12
SysML: Foundations and Diagrams
Whether it is an advanced military aircraft, a hybrid vehicle, a cell phone, or a
distributed information system, these systems are expected to perform at levels
undreamed of a generation ago.
Friedenthal, Moore, and Steiner (2012)
Systems Modeling Language (SysML) is a profile of the Unified Modeling Language (UML), i.e., a
customized version intended for systems engineering applications. We begin the presentation of SysML
with a brief description of UML, followed by an overview of SysML and its various diagram types, with
reference to OPM. Recall that while OPM uses a single model that combines the various system aspects
and presents them in graphics and text, SysML uses nine diagram kinds, each focusing on some particular
aspect of the system. We focus on the SysML diagram kinds that have not been discussed so far:
sequence diagram, activity diagram, requirements diagram, and parametrics diagram. The sequence
diagram shows the time flow and exchange of messages among blocks. The activity diagram presents the
activities performed by the system, their order and their control. The requirements diagram presents user
and derived requirements that the system shall satisfy. Finally, the parametrics diagram models the
computations that take place in the system.
been recognized as problematic, primarily since UML is software-centric, so its ontology and taxonomy
is limited to software artifacts. For example, physical characteristics and components of a system are
hardly expressed in UML diagrams. In addition, UML does not adequately support modeling of
hierarchies within a system model, an essential issue in systems engineering.
The drive to adapt UML to systems engineering applications brought about the establishment of the
OMG Systems Engineering Domain Special Interest Group (SE DSIG). This OMG group, supported by
the International Council on Systems Engineering (INCOSE) and ISO AP 233 workgroup, worked
together on the requirements of the modeling language. The result was the UML for Systems Engineering
Request for Proposal, or UML for SE RFP in short (OMG UML 2003), issued by the OMG in March
2003. SysML was the only response to the RFP. The SysML team consisted of industry users, tool
vendors, government agencies, professional organizations and academia. Four and a half years after the
RFP was published, version 1.0 of the SysML specification was formally released by OMG as an OMG
specification in September 2007.
diagrams, reflecting relationship to other model constructs. Generally, the SysML requirements constructs
are not meant to replace the external requirements management tools, but rather to better integrate the
system requirements with other parts of the model.
SysML Diagram
UML-based UML-modified new
Activity Diagram
UML-modified
Control
Fill Flow Ship
Order Order
Fig. 12.3 A simple SysML activity diagram with block and action nodes and control and object flows
Activity is the fundamental behavioral element in the various SysML behavioral diagrams (excluding
the use case diagram). The role of the activity diagram (see Fig. 12.3) is to represent the flow of inputs
and outputs and the flow of control between actions. To this end, the activity diagram incorporates
sequences and conditions for coordinating activities. Activities and activity diagrams exist also in UML,
but SysML provides several extensions (Bock 2006), including means to support “continuous” flow
modeling, such as rate restrictions. Support for probabilities and extensions to control (known as “control
as data”) were added to SysML activity diagrams. In addition, to smoothly align SysML with the widely-
used classical systems engineering behavior diagram (known as EFFBD—Enhanced Functional Flow
Block Diagrams; Bock, 2005), the «effbd» stereotype is specified. When this stereotype is applied to an
activity, it means that the activity must conform to the constraints necessary for EFFBD.
The use case diagram is intended to describe basic high-level functionally by specifying the usage of
the system by its actors to achieve a goal. It is often the first kind of diagram used to specify semi-
formally with the customer to define the function and scope of the system to be developed.
Activity diagram is the only behavioral diagram kind that is extended in SysML with respect to UML
2, while the other three SysML behavioral diagram kinds remain unchanged or were eliminated.
Sequence diagram is used to represent message-based flow of control between interacting entities, which
may be actors, systems, or parts of a system. The state machine diagram models state-based behavior
using object states and transitions.
An action (denoted by a rountangle) is a basic (usually atomic) unit of process in an activity diagram.
As Fig. 12.3 shows, an activity diagram is composed of nodes and edges, where a node can be an action
or a block (denoted by a rectangle), and an edge can be a control flow if it is between actions, or an object
flow (or block flow) if it is between a block and an action.
Fig. 12.4 The action Order Processing (left) has a little trident symbol, denoting it is elaborated into an activity (right).
The blocks Order, Invoice, and Product are denoted as pins—input and output parameters
Model
Prioritize
Enterprise
Enterprise
Business
Requirements
Architecture
Model
Actions ordered Enterprise Support
time-wise from Requirements Project Teams
top to bottom
Model
Describe
Enterprise
Enterprise
Technical
Requirements
Architecture
Fig. 12.6 The three special action notations: (a) accept event (b) send signal (c) time event
The Order Processing activity diagram has initial and final pseudo nodes—the black and black-on-
white circles—to denote the activity start and end, respectively. It also has two synchronization nodes: a
fork node—the thick vertical line from the initOrder action to the Create Invoice and Ship Order
actions, and a join node—the thick vertical line from these two actions to the final pseudo node. The fork
node indicates concurrent beginning of actions exiting from it, while the join node—the termination of all
the actions incoming into it.
Dori – Model-Based Systems Engineering with OPM and SysML 141
A swimlane is a kind of activity diagram that provides a way to group activities performed by the
same actor or to group activities in a single thread. Figure 12.5, adapted from Agile Modeling (2015), is
an example of a swimlane activity diagram. The actors are indicated in the vertical swimlanes and the
diagram timeline runs from top to bottom with horizontal links crossing the swimlane borders where
necessary.
Virus alert
Message Scan for Notify
arrived viruses Admin
Forward to
User
Every 20 seconds
Fig. 12.7 Activity diagram with accept event, send signal, time event, pin, and a join node
Found
Message : TradingSystem : StockExchange
Investor
sendOrder(Order)
need to buy Gates
buySecurity(name) Other Trading System
validatePurchase
acknowledge
Synchronous
Other Trading System
Message Creation
Order
Message
Return sendOrder(Order)
sendUpdates
Message
acknowledge
Lost
X Destroy
Message
Message
Fig. 12.9 SysML sequence diagram message kinds and their symbols
Three other dependencies of similar nature are «verify», «refine», and «trace». The «verify»
dependency is between a requirement and a block that provides a way of verifying it. This can be a block
having the stereotype «testCase». The «refine» dependency denotes that some elaborate requirement
refines a more general requirement, e.g., a client’s requirement. The «trace» dependency denotes that
some block provide a way to trace a requirement. The «trace» dependency provides a way to keep track
of where requirements are fulfilled in the system, as it is often the case that requirements are difficult to
trace or it is not clear why some component was included in the model.
A standard requirement includes properties to specify its unique identifier and text requirement.
Additional properties such as verification status, can be specified by the user. Indeed, requirements
diagrams are depicted in a large variety of forms and styles.
Figure 12.11 presents four examples found on the Web that demonstrate this variability in styles.
The diagram in the top left is titled req TV Remote Control. It contains four requirements, the main of
which is also called TV Remote Control. The three others, called Weight, Color, and Eco-Friendliness, are
“children”—lower-level requirements that are subordinates of the parent requirement TV Remote Control.
Dori – Model-Based Systems Engineering with OPM and SysML 145
This is designated by the lines with the crossed circles at their ends, in accord with the standard
specification in Fig. 12.10. In addition to the text and ID attributes, each requirement here has the
attributes source, kind, verifyMethod, risk, and status.
The diagram in the top right is titled Requirement Diagram Top-Level User Requirements. The
standard specifies that req be used to designate a Requirement Diagram. The use of the black diamond,
which is a symbol from block definition diagram (bdd) is another non-standard application. The
containment symbol should be used instead.
The diagram in the bottom left, titled req Detection Performance, shows the use of all the six
dependency kinds discussed above. For example, «testCase» Low SNR Target Without Interference
«verify» «requirement» Sensor2 Detection Performance. Another example is «block» Signal Processor
«satisfy» «requirement» Sensor2 Detection Performance. None of the requirements in this diagram has
146 SysML: Foundations and Diagrams
the feature compartment with the minimal set of features—text and ID, but the standard (Sect. 16.3.1.2)
does allow to elide (leave out) this compartment.
Interestingly, Scan Environment, which is a use case, is at the origin of the «refine» dependency. This
does not seem to be allowed by the standard, since according to OMG SysML v1.3 Sect. 16.3.1.1 (p.144)
“The Requirement Diagram can only display requirements, packages, other classifiers, test cases, and
rationale.” However, this link between use cases and requirements can be useful. Trying to defend the
legality of mixing symbols from various diagrams, we find that the informative Annex A—Diagrams of
SysML v1.3 Standard (p. 168) states:
“Although the taxonomy provides a logical organization for the various major kinds of diagrams, it
does not preclude the careful mixing of different kinds of diagram types, as one might do when one
combines structural and behavioral elements (e.g., showing a state machine nested inside a compartment
of a block). However, it is critical that the types of diagram elements that can appear on a particular
diagram kind be constrained and well-specified. The diagram elements tables in each clause describe
what symbols can appear in the diagram, but do not specify the different combinations of symbols that
can be used.”
This paragraph essentially grants SysML modelers complete freedom to mix and match any symbol
from any SysML diagram kind with any other symbol. All one has to do is “careful mixing” and ensuring
that “the types of diagram elements that can appear on a particular diagram kind be constrained and
well-specified.” However, what “constrained and well-specified” means is itself not specified, leaving it
open to any interpretation of the modeler.
Finally, the diagram in the bottom right, titled CLD Dispenser Requirements, shows in the top
compartment of each requirement, in addition to the name (e.g., Fuel Type Delivery) also the requirement’s
priority (e.g., {Requirement Type=Non-Functional}) and type (e.g., {Type=1}). The feature compartment
contains relatively elaborate text (e.g., “Only one type of fuel can be delivered”), but it does not contain an
ID. Three blocks (Valve, Dispenser Controller, and FT) satisfy the Dispenser Fuel Type requirement, which is
derived from another, more comprehensive requirement.
For reuse purposes, constraint blocks are defined in a Block Definition Diagram. Parametric Diagrams
use constraint blocks to constrain the value properties of other blocks. Constraint blocks may thus be
reused on block definition diagrams and packaged into general-purpose or domain-specific model
libraries. This constraining is done by binding the constraint parameters (such as m in the example above)
to specific actual value properties of a block (such as the mass of a vehicle). A parametric diagram
example appears in Fig. 12.13. Figure 12.14 is an OPD representation of this parametric diagram.1
A parametric diagram (see Fig. 12.12 right) uses one or more constraint property blocks to constrain
the properties of one or more other blocks by binding the parameters through a mathematical relation. A
constraint property may be shown on a parametric diagram using a standard form of internal property
rectangle with the «constraint» keyword (short for constraintProperty) preceding its name (see Fig. 12.12
left). However, a constraint property may also be shown on a parametric diagram using a rountangle (see
Fig. 12.12 middle). As with the standard rectangle form, compartments and internal properties may be
shown within the rountangle. Using this shape enables avoiding the need to explicitly record the
«constraint» keyword.
Figure 12.13 presents a parametric diagram that constraints fuel flow rate to a car fuel demand and
fuel pressure through the relation FuelFlow = Pressure/(4*(InjectorDemand)), presumably due the fact that
this is a 4-cylinder engine.
Any mathematical operation, from the basic four arithmetic operations to the most complex
computation, can be viewed in OPM in terms of a calculating (informatical) process that uses (but not
consumes) one or more input parameters to produce an output. With this in mind, any SysML parametric
diagram can be presented as an OPD where the constraint is a Calculating process preceded by the
mathematical expression that binds and constrains the input parameters. The input parameters are
instruments, unless we wish to specify that they are not kept after the Calculating process ends.
Fig. 12.12 A generic constraint block (left) and a parametric diagram (right). Source: OMG SysML v1.3, p.84
1
Another, more complex example for doing calculations in appears in Fig. 22.5 and in Fig. 22.6.
148 SysML: Foundations and Diagrams
Fig. 12.13 A parametric diagram that constraints fuel flow rate to fuel demand and fuel pressure (source: OMG SysML
v1.3, p.199)
Adopting this simple concept transformation, Fig. 12.14 is an OPD representation of the parametric
diagram in Fig. 12.13. In addition to this compact graphic representation, we get “for free” the OPL
textual representation, which can be readily translated to code in any programming language or even
directly executed to compute Pressure/(4*(Injector Demand)). Another, more involved example for doing
calculations in OPM appears in Figs. 22.5 and 22.6.
2
It is possible to generate a textual modality using some commercial SysML tools’ reporting and documentation
modules but this is not part of the language standard and there is no predefined syntax for formal sentences.
150 SysML: Foundations and Diagrams
Fig. 12.15 Two ways to show an object flow. Top: pin notation. Bottom: object notation
The activity diagram at the bottom of Fig. 12.15 looks very similar to an OPD. It looks like all we
need to do is replace the activity symbol—the rountangle—with the OPD symbol for process—the
ellipse, we will get a semantically equivalent model. Doing this produces the OPD in Fig. 12.16. The two
models really look isomorphic: just replace the shape and voila! However, to gain insight into the exact
semantics of this OPD, we should read its OPL paragraph:
152 SysML: Foundations and Diagrams
Fig. 12.16 First attempt at OPM modeling of the activity diagram at the bottom of Fig. 12.15
Designing yields Blueprint.
Manufacturing consumes Blueprint.
Is this really what we wanted to model? Is Blueprint really consumed by Manufacturing? What we
really want to model is that once ready, Blueprint enables Manufacturing. However, Manufacturing does
not consume Blueprint, but rather references it, so Blueprint is an enabler, or, more specifically, an
instrument: It is required by the Manufacturing process, but it is not destroyed by it. Moreover, while
Blueprint is an informatical object, Manufacturing is a physical process.
The OPL paragraph of this OPD is indeed more telling and it confirms our improved graphical model
(Fig. 12.17):
Designing yields Blueprint.
Manufacturing is physical.
Manufacturing requires Blueprint.
Fig. 12.17 An improved OPM model of the activity diagram at the bottom of Fig. 12.15
Contemplating on the thought process that this exercise involved, we realize that the semantics of the
activity diagram is less expressive than that of the OPD. Arrows between an activity and an object in an
activity diagram have flow semantics, while in OPM they have transformation semantics—creation,
consumption, or state change. The Blueprint in the activity diagram simply “flows” between the two
actions, implicitly changing its logical location as it does so, but weather Blueprint is consumed by
Manufacturing or it just enables it is not specified. Conversely, the OPM arrows do not have flow
semantics—they do not imply that the object involved changes its location, only that it undergoes some
transformation.
The activity diagram cannot distinguish between an instrument and a consumee (neither can any other
SysML diagram type, at least not directly). The distinction between the informatical essence of Designing
and Blueprint on one hand and the physical essence of Manufacturing on the other hand cannot be
modeled either. Neither this essence distinction nor the distinction between an enabler and a transformee
can be modeled in a straightforward manner by any one of the nine SysML diagram kinds.
Dori – Model-Based Systems Engineering with OPM and SysML 153
Fig. 12.18 Example of an activity diagram decision node. Left: a relevant portion of the OPD. Right: an equivalent
activity diagram
Fig. 12.20 The Flow Rate requirement from Fig. 12.19 expressed in an OPM model
This requirement is presented in the requirements diagram in Fig. 12.19. In OPM we define an
informatical object class Requirement, which has an instance to Flow Rate Regulation. Since Flow Rate
satisfies this requirement, extending the OPD in Fig. 12.14, we express this relation using OPM’s tagged
structural link satisfies in Fig. 12.20.
Another approach is to formally model the requirement and derive the textual requirement
specification from the resulting OPL text, rather than writing freestyle requirements. Using the exhibition-
characterization relation, we can model the Requirement in Fig. 12.20 as exhibiting several parts,
including Client Free Text, Vitality, Urgency, Satisfying Status, and Deriving Requirement. The value of
the attribute Client Free Text of the instance Flow Rate Regulation will be “Gasoline flow rate shall be
Dori – Model-Based Systems Engineering with OPM and SysML 155
directly proportional to the piston pressure and inversely proportional to the injector demand and to the
number of pistons”.
To increase the generality we can model the object Piston Set whose Size attribute value is a
parameter instead of the number 4 in the mathematical expression which is part of the process name
“Flow Rate as Pressure/(4*(Injector Demand)) Calculating”. Furthermore, instead of including this
expression in the process name, we can in-zoom and model how the result is computed step-by-step using
the parameters. This way if any one of the parameters or even the expression changes, the process name
does not need to be changed.
12.11 Summary
Activity diagrams are illustrations of workflows, which describe the flow among actions and are
closest in semantics to OPDs.
An action is a basic unit in an activity diagram, but by using the rake symbol it can be elaborated
into an entire activity diagram in its sown right, providing for a refinement mechanism similar to
OPM in-zooming.
Flows in activity diagrams can be of two kinds: control flow and object flow.
Accept, send, and time event action nodes have special syntax and semantics.
Join and fork nodes are used for synchronizing actions.
Arrows between an activity and an object in an activity diagram have flow semantics, while in
OPM they have transformation semantics—creation, consumption, or state change.
Flow of control in activity diagrams is achieved through decision nodes, which are diamond-
shaped nodes to which a decision input notes are often attached. In OPM, flow of control is
based in part on Boolean objects.
Requirements diagrams bridge typical requirements management tools and the system model.
Parametric diagrams use constraint property blocks to bind system parameters to each other via
mathematical expressions. In OPM this can be done by expressing the mathematical formula as a
computation process.
156 SysML: Foundations and Diagrams
Requirements and parametric diagrams (like all the other SysML diagram kinds) can be modeled
in OPM without special symbols.
12.12 Problems
1. Draw an activity diagram of the OPD in Fig. 7.4.
2. Draw an activity diagram of the OPD in Fig. 8.6.
3. Using the rake symbol, connect the two activity diagrams from problems 1 and 2.
4. For each one of the two activity diagrams from problems 1 and 2, indicate the control flows by
red and each object flow by green.
5. Explain the difference in the semantics of arrows between activity diagram and OPD.
6. Use the specification below to draw a requirements diagram.
A passenger arriving at an airport deposits her baggage with the airline she is flying with. A
baggage handling system manages the transfer of the baggage to the passenger’s destination.
7. Compare the requirements diagram from Problem 6 with the OPD in Fig. 2.5.
8. Draw a parametric diagram for the formula E = mC2.
9. Draw an OPD for the formula E = mC2.
10. Compare the parametric diagram from Problem 8 with the OPD from Problem 9.
Chapter 13
The Dynamic System Aspect
Every day we are confronted with systems that have an inherent tendency to change.
The weather, the stock market, or the economic situation, are examples.
Meinhardt (1995)
Systems change over time. An important motivation in the development of OPM has been to strike a
needed balance in a system’s conceptual model between the structural, static and procedural, dynamic
aspects of the system. The dynamic aspect of a system specifies how the system operates to attain its
function, complementing its static aspect. OPM is at least process-oriented as it is object-oriented. Indeed,
OPM models unify structure and behavior in one coherent frame of reference, with time being the
fundamental underlying concept. This chapter addresses modeling the dynamics aspect of a system.
Effect is a change in the state of an object that a process causes by its occurrence.
While the terms “change” and “effect” seem almost synonymous, there is a subtle difference in their
usage. We use effect to refer to what the process does to the object, and change—to what happens to the
object as a result of the process occurrence. Later in this section we refine the above definition of effect
with the notions of input and output links.
small, such as a change in the location of the object or in its color, we tend to say that the object was
altered from one of its states to another while keeping its identity. As the extent of the effect grows, so
does the difference between the object before the process started and after it ended. At some point, the
two become so conceptually different that the modeler is inclined to think of the object resulting from the
process as a newly created object. The object that had existed before the process took place may have
been eliminated or at least changed radically. As we show below, the issue of whether an object changed
only its state or its entire identity is similar in natural and artificial systems.
All states
removed,
input-output Constructed Object Existing Object Consumed Object
link pair
joined,
resulting in
result,
effect, and
Constructing Affecting Consuming
consumption
links
silkworm, on the other hand, has four distinct forms of existence. It transforms from egg to larva (worm,
or caterpillar) to pupa, the larva undergoes complete transformation within a protective cocoon or
hardened case, to butterfly, which, in turn, lays the eggs of the next silkworm generation. Each
transformation yields an object that is very distinct from its predecessor in shape and function. The
difference is so profound that each such transformation is called metamorphosis. We are inclined to view
each reincarnation as a separate object rather than a mere change of the same object’s state. A frog, like
other amphibians, transforms from spawn to egg to tadpole to legged tadpole to froglet to adult, providing
an example similar to the silkworm.
Fig. 13.2 Two concurrently simulated models of Frog lifecycle. Left: Change of object state. Right: Change of object
identity
Figure 13.2 shows an OPCAT screenshot of two OPM models that are simulated concurrently. The
model on the left shows Frog as a single object with six states: spawn, egg, tadpole, legged tadpole,
froglet, and adult. Thanks to the invocation links, once invoked by externally activating Splitting, this
model completes a whole cycle from spawn to adult.
The model on the right shows six different stateless objects of the various incarnations of frog: Spawn
Frog, Egg Frog, Tadpole Frog, Legged Tadpole Frog, Froglet Frog, and Adult Frog (here each process
Dori – Model-Based Systems Engineering with OPM and SysML 161
needs to be invoked separately; this can be avoided if we replace each consumption link, e.g., the one
from Egg Frog to Hatching, with an event consumption link). At this point of the simulation the process
Legs Growing is active (as the dark color and points along the arrows show). The pertinent OPL sentence
for the model on the left is:
Legs Growing changes Frog from tadpole to legged tadpole.
The pertinent OPL sentences for the model on the right is:
Legs Growing consumes Tadpole Frog.
Legs Growing yields Legged Tadpole Frog.
The frog and silkworm examples are conveniently thought of as changes of object although
genetically they are the same organism, because the various incarnations of these creatures are profoundly
different from each other in both appearance and behavior. The human and lion examples, on the other
hand, are more naturally modeled as a change of the object’s state.
Generalizing the natural and artificial examples, when the change is not profound or drastic, we are
inclined to think that the object only alters its state while retaining its identity. When the transformation is
extreme, a change in object identity takes place. As is the case in similar situations, the borderline
between “drastic” and “non-drastic” is not well-defined. Analyzing the same system, different modelers
may provide different viewpoints on whether a particular object should lose its identity and become a new
object. Indeed, we will see instances where it makes sense to model changes in objects either as a change
in their state (or attribute value), or as a change in their identity, and both versions would be acceptable.
A procedural link is a link between a process and an object or its state, or between
two processes.
The majority of procedural links are between a process and an object or its state. The only three
procedural link kinds between two processes are the invocation link and the overtime and undertime
exception links discussed in Chap. 22. As discussed in Sect. 10.10.3 an invocation link may replace a
transient, short-lived physical or informatical object that a source process creates to initiate the destination
process, which immediately consumes the transient object. This is also true for the exception links (where
the object may be a message). Therefore we often omit the last part of the procedural link definition and
say that a procedural link is a link between a process and an object or its state.
The structure-behavior integration that procedural links provide is one of the most important features
of OPM. This integration within a single model eliminates in the first place the inherent diagram kind
multiplicity problem (Peleg and Dori 2000) that are characteristic of object-oriented methods such as
UML and SysML, whose ontology is far from being minimal.
13.3.2 Transformees
We have defined transformee of process P is an object B that P transforms as a result of its occurrence.
The transformation can be construction, effect (change of state) or consumption. Transformee is a role
that the object B assumes with respect to the particular process P. so B can be a transformee with respect
Dori – Model-Based Systems Engineering with OPM and SysML 163
to some process P1 and an enabler with respect to another process P2. A transformee can be one of three
types defined below.
Fig. 13.3 Result, effect, and consumption link between File and File Creating, File Editing, and File Deleting,
respectively
A result link is a unidirectional transformation link from a process to the resultee that
this process creates.
Fig. 13.4 Processing linked the three transformee types by their corresponding transforming links Enablers
Fig. 13.5 Consumption and result timing: Steel Rod is consumed and disappears as soon as Machining starts. Shaft is
created only when Machining ends
In Fig. 13.5, Steel Rod is a consumee for the process Machining, which generates the resultee Shaft.
Once Machining has started, it consumes Steel Rod. However, Shaft is considered to be created only upon
termination of Machining. During the process, Steel Rod does not exist anymore, but neither does Shaft.
13.5 Enablers
Suppose you wish to move from your place to an apartment in another city. To do this, you need a
moving truck, which you rent from a moving truck rental company. You return the truck to the same
place where you took it and with the same amount of gasoline as you took it. Hence, ignoring the
amortization of the truck, nothing in it has changed. However, you would not be able to carry out the
166 The Dynamic System Aspect
moving without it. We say that the Truck is an enabler of the Moving process. Moreover, since some of
your furniture are very heavy, you need a Friend as a second enabler of the Moving process.
An enabler of a process is an object that enables the process execution. Its presence is needed
throughout the duration of the process, but when the process is over, the enabler exists at the same state as
it was when the process started. In other words, an enabler of a process is an object that must be present
throughout the process duration in order for that process to occur and terminate successfully, but is not
transformed as a result of the occurrence of the process.
An enabler E of a process P is an object that must exist and be available in order for
P to start, and remain present throughout the occurrence of P in order for P to
terminate normally, with E ultimately unaffected.
The enabler might undergo state change during the process, but, as the enabler definition states, when
the enabled process is over, the enabler is at the same state at which it started. For example, the enabler
Oven in Fig. 13.7 will change state from off to on at the beginning of the enabled Baking process, and
from on back to off just prior to the end of Baking.
As the Moving example has shown, some enables are human, while others are inanimate. Hence, an
enabler has two specializations: an agent or an instrument, as defined below.
1
A robot can still be called an embedded-software agent, and programs acting in the Internet on behalf of humans can
still be called software agents. Agent without any qualification is reserved for individuals or groups of humans.
Dori – Model-Based Systems Engineering with OPM and SysML 167
while interacting with the rest if the system—the system’s usability and the users’ experience and delight
from using a well-designed and human-friendly and accommodating system.
The agent link is somewhat analogous to the actor—the “stick figure” in UML’s or SysML’s use-case
diagram. In OPM, however, no separate kind of diagram is needed, as modeling the user is incorporated
into the single OPM model. Use cases in SysML notation can automatically be extracted from the OPM
model, as can other SysML models (Grobshtein and Dori 2011).
Not any human or organization is necessarily only an agent. For example, if a Student is engaged in
the process of Studying, his or her Knowledge Level attribute change, say from shallow to deep. In this
case, Student is not only an agent, but also a transformee. Likewise, if a department in an enterprise is
undergoing business process reorganization, its structure and/or behavior changes as a result of this
process, so in addition to being an agent, it is also a transformee.
The procedural link uniqueness OPM principle states that at any level of detail, an object and a
process can be connected with at most one procedural link. Semantic strength and link precedence are
defined and discussed in detail in Chap. 21. Here we note only that transforming links are semantically
stronger than enabling links, because the transforming links denote creation, consumption, or change of
the linked object, while the enabling links only denote enablement. A transforming link has precedence
over an enabling link as shown in Fig. 21.15, therefore if we need to choose between an agent link and an
effect link, as in the examples above, effect link shall be chosen.
An enabling link is a procedural link that connects a process with an enabler of that
process.
An agent link is an enabling link that connects a process with an agent of that process.
An instrument link is a procedural link that connects a process with an enabler of that
process.
Fig. 13.7 Enabling links example: The agent link from Baker and the instrument link from Oven
Graphically, as Fig. 13.7 shows, an enabling link is a “lollipop”, a line leading from the enabler
(Baker) to the process (Cake Making) it enables, which ends with a circle touching the process side. If the
enabler is a human or a group of humans, the enabling link is an agent link, denoted as a “black lollipop”,
i.e., its ending circle is filled in (black).
The distinction between a human and a non-human enabler is important, since for humans to interact
with the system, a dedicated interface needs to be designed. Hence, an optional stick figure can be added
at the top-left corner of the agent’s object symbol, as shown in Fig. 13.7. This optional stick figure is
especially useful when the human in the model is an affectee, i.e., she or he is affected by the process to
which it is linked, in which case we must use the effect link rather than the agent link. In this case, the
stick figure retains the information that a human is involved.
If the enabler is an instrument, the enabling link is a “white lollipop”, i.e., its ending circle is blank
(white). The two OPL sentences associated with these links are:
Agent handles Processing.
Processing requires Instrument.
The OPL syntax of the first (agent) sentence is designed such that the agent appears first, followed by
the reserved OPL phrase handles, followed by the process name. For the instrument sentence, the OPL
syntax is such that the process name appears first, followed by the reserved OPL phrase requires, followed
by the instrument name. This difference in both the OPL phrases and the order of the enablers in the
sentences underlines that being humans, agents are more important than instruments.
Dori – Model-Based Systems Engineering with OPM and SysML 169
All the process enablers must be present throughout the execution of the process which they enables.
For example, in Fig. 13.7 both the agent Baker and the instrument Oven must be present throughout a
Cake Baking process.
Fig. 13.8 The same object playing the roles instrument and affectee: Moving Truck is an instrument of Moving and an
affectee of Servicing
they belong only to the pre-process object set, while resultees are created, so they belong only to the post-
process object set.
Fig. 13.9 The Involved Object Set partitioned into Preprocess Object Set and Postprocess Object Set
The Preprocess Object Set and the Postprocess Object Set are not necessarily disjoint—they may be
overlapping. Indeed, in Fig. 13.9, the overlapping members are the two enablers—Agent and Instrument,
and one transformee—the Affectee. Agent and Instrument might belong to both object sets, because, by
their definition, being enablers, they are required throughout the process (and are not supposed to change
as a result of the occurrence of the process they enable). Affectee belongs to both the preprocess object set
and postprocess object set, because it continues to exist after the process occurred, albeit in a different
state. Consumee is the only involved object which is not in the Postprocess Object Set, because the
Processing process consumed it, so it does not exist after Processing terminated. In an anti-symmetric
manner, Resultee is the only involved object which is not in the Preprocess Object Set, because
Processing generated it, so it did not exist prior to the beginning of Processing. The procedural links are
summarized in Table 13.1.
specify not just what object a process consumes, but also the particular state that the object needs to be at
in order for the process to be able to consume it. State-specified procedural links provide for this.
A state-specified agent link is an agent link that originates from a specific state s of an
agent G to process P, denoting that in order for G to handle P, G must be at state s
throughout the duration of P.
172 The Dynamic System Aspect
Like its state-specified consumption link and result link counterparts, the state-specified instrument
link originates from a specific state and terminates at a process. The semantics of this link is that the
process is enabled if and only if the object exists and is at the state from which the link originates. This is
contrasted with the “regular” instrument link, which originates from the enabling instrument but not from
any particular state of that instrument. For example, a pilot must be sober in order to qualify as an agent
for the flying process of an Airplane. In OPL: Sober Pilot handles Flying.
The difference between the two instrument link types is demonstrated in Fig. 13.10, where on the left
hand side, the object Moving Truck is the instrument for Moving, implying that the state at which this
Moving Truck is does not matter. On the right hand side, the instrument link originates from the state
serviced of Moving Truck, implying that only if Moving Truck is serviced, Moving can take place.
Fig. 13.10 Instrument link vs. state-specified instrument link: Left: Instrument link—Moving Truck is an instrument of
Moving. Right: State-specified instrument link—serviced Moving Truck is an instrument of Moving
Table 13.2 summarizes the semantics, symbols, source, and destination of the two state-specified
enabling links.
Dori – Model-Based Systems Engineering with OPM and SysML 173
Table 13.2 State-specified enabling links: semantics, symbols, source, and destination
Each one of the three transforming links—consumption, effect, and result—has a state-specified
version, as defined below. The three transformees—consumee, transformee and resultee—are also roles
with respect to the corresponding processes associated with them, as are agent and instrument. Similarly,
the terms “input state” and “output state” refer to roles of two states of an affectee with respect to the
affecting process. The input state is the state just before the affecting process starts, while the output state
is the state the object is at just as that process ends.
The state-specified consumption link expresses the fact that the consumee is consumed by the process
if and only if the consumee is in the specified state—the one to which the consumption link is connected.
174 The Dynamic System Aspect
A state-specified result link is a result link that originates from process P and ends at
a state s of the resultee R, denoting that when P terminates, it creates R in state s.
The state-specified result link expresses the fact that the resultee is generated by the process only at
the specified state—the one to which the result link is connected.
A state-specified effect link is an in-out (input-output) link pair, whose input link
originates from an input state si of the affectee A and ends at process P, and whose
output link originates from P and ends at an output state so of A, denoting that in order
for A to be affected by P, A must be in si, in which case when P terminates A will be at
so.
Figure 13.11 shows two examples of state-specified consumption and result links. Machining can only
consume Raw Metal Bar in state cut and generate Part in state pre-tested. The corresponding OPL sentences
follow. The OPL syntax for a state-specified object is “state name” followed by “Object Name”. This
syntax is demonstrated in the two OPL sentences in Fig. 15.13 by cut Raw Metal Bar and by pre-tested
Part. When naming a state, one should therefore test its expressiveness by evaluating whether the phrase
that results from this concatenation makes sense and reads well in OPL sentences where it appears.
Since the function of this system is Machining, Cutting and Testing are environmental processes.2
Cutting must precede Machining in order to change Raw Metal Bar from its pre-cut to its cut state, while
Testing changes Part from pre-tested to tested. Additional examples of state-specified transforming links
appear in Table 13.3.
Machine
Operator
Raw Metal Bar
pre-cut cut
Machining
Part
pre-tested tested
Cutting
Coolant
Testing
2
In a system with a larger scope of Manufacturing, the three processes Cutting, Machining, and Testing, in that
sequence, would all be systemic subprocesses of Manufacturing.
Dori – Model-Based Systems Engineering with OPM and SysML 175
Instead of the single effect link in Table 13.1, when states were not present, in Table 13.4 there are
three types of state-specified effect link pairs. Each link pair consists of an input link and an output link.
176 The Dynamic System Aspect
The difference between them stems from the origin of the input link and the destination of the output link.
We use the word in-out as a shorthand notation for input-output.
Table 13.4 Input output state-specified procedural links: semantics, symbols, source, and destination
In the example for the in-out-specified effect link in Table 13.4, the OPL sentence is:
Dori – Model-Based Systems Engineering with OPM and SysML 177
Here, raw and purified are the input (source) and output (destination) states of Copper, respectively.
An input-specified effect link pair of process P is a pair of links consisting of an input link from the
input state sin of object B to P and an output link from P to B.
In the example for the output-specified effect link in Table 13.4, the OPL sentence is:
Testing changes Sample from awaiting test.
Here, awaiting test is the input state of Sample. The output state of Sample is not specified, implying that
(depending on the outcome of Testing) it can be any one of the three of Sample states.
Here, painted is the output state of Engine Hood. The input state of Engine Hood is not specified,
implying that it can be any one of the three Engine Hood states.
The value effect link is the counterpart of the state-specified effect link of an object that is not an
attribute. The difference is that while the state-specified effect link changes an object from one
unspecified state to another, the value effect link changes the value from some unspecified value to
another.
An in-out-specified value effect link pair is a pair of a value-specified input link and
a value-specified output link which change that attribute value from the input vale to
the output value.
Table 13.5 Value-specified procedural links: semantics, symbols, source, and destination
The in-out-specified value effect link pair is the counterpart of the in-out-specified effect link pair of
an object that is not an attribute. The difference is that while the in-out-specified effect link pair changes
Dori – Model-Based Systems Engineering with OPM and SysML 179
an object from one specified state to another specified state, the value effect link changes the value from
some specified value to another specified value.
The names of the values are parameter names. For example, t_new is the new value of Temperature of
Engine set by Heating. We can also assign actual numbers to the parameters, as demonstrated in Fig.
13.12.
Fig. 13.12 Value-specified procedural links with parameters and actual numeric values
13.11 Summary
A change of an object is an alteration in the state of that object.
Effect is a change in the state of an object that a process causes.
Construction is an extreme case of object effect, where the object’s input state is nonexistent
and the output state is existent.
Consumption is an extreme case of object effect, where the object’s input state is existent and
the output state is nonexistent.
When the transformation is extreme, a change in object identity takes place.
When the change is not profound or drastic, the object only alters its state while retaining its
identity.
A transformee of process P is an object B that P transforms as a result of the occurrence of P.
o A consumee of a process P is a transformee of P that P consumes as a result of the occurrence of P.
o A resultee of a process P is a transformee of P that P creates as a result of the occurrence of P.
o An affectee of a process P is a transformee of P that that P affects as a result of the occurrence of P.
180 The Dynamic System Aspect
A transforming link is a procedural link that connects a process with a transformee of that
process.
o A result link is a unidirectional transformation link from a process to the resultee that this process
creates.
o An effect link is a bidirectional transformation link that connects a process with an affectee of
that process.
o A consumption link is a unidirectional transformation link from a consumee to the process that
consumes it.
An enabler E of a process P is an object that must exist and be available in order for P to start,
and remain present throughout the occurrence of P in order for P to terminate normally, with E
ultimately unaffected.
o An agent is an enabler who is a human or a group of humans.
o An instrument is a non-human enabler.
An enabling link is a procedural link that connects a process with an enabler of that process.
o An agent link is an enabling link that connects a process with an agent of that process.
o An instrument link is a procedural link that connects a process with an enabler of that process.
An input state of object B is a state si of B at which B is when process P starts.
An input link is a link from the state si to process P.
An output state of object B is a state so of B at which B is when process P ends.
An output link is a link from process P to the state so.
A state-specified consumption link is a consumption link that originates from an input state si of
the consumee C and ends at process P, denoting that in order for C to be consumed by P, it must
be in state si.
A state-specified result link is a result link that originates from process P and ends at a state s of
the resultee R, denoting that when P terminates, it creates R in state s.
A state-specified effect link is an in-out (input-output) link pair, whose input link originates
from an input state si of the affectee A and ends at process P, and whose output link originates
from P and ends at an output state so of A, denoting that in order for A to be affected by P, A
must be in si, in which case when P terminates A will be at so.
o An in-out-specified effect link pair of process P is a pair of links consisting of an input link from
the input state sin of object B to P and an output link from P to the output state sout of B.
o An input-specified effect link pair of process P is a pair of links consisting of an input link from
the input state sin of object B to P and an output link from P to B.
o An output-specified effect link pair of process P is a pair of links consisting of an input link from
object B to P and an output link from P to the output state sout of B.
A value changing link is a link between a process and an unspecified value of an attribute which
the process changes.
Dori – Model-Based Systems Engineering with OPM and SysML 181
13.12 Problems
1. Give two examples of each of the following, provide their OPM models, and verify that the
resulting OPL describes your original intent.
2. Change of an objects.
3. Consumption of an objects.
4. Creation of an objects.
The following questions relate to Figs. 13.13 and 13.14, which describe a system being simulated by
animation.
5. What is the system described in this OPD?
6. What are the affectee, agent and instrument?
7. What is the OPL sentence that describes effect?
8. What is the relation between Driver and Car? What link is used to express this?
9. What is the relation between Gasoline Tank and Car? What link is used to express this?
10. What is the process within Car Fueling taking place at this time?
11. What object does it transform and how? What is the OPL sentence describing this?
12. What link is missing between this process and Pump? What is the OPL sentence that would be
created if you added this link?
13. What are the five affectees in this OPD? Which one is different than the other four and why?
14. What agent link is missing?
15. Describe the state changes of Pump.
16. What can you tell from the colors of the states of the various objects? Please refer specifically to
Gasoline Tank.
17. What effect link is missing? Hint: Look at the one present.
18. Suppose Car is the only vehicle in the Gas Station throughout the Car Fueling process. Where
would you place the states called car present and car absent?
19. How would the corresponding link change as a result?
20. What process reverts Gas Station to its original state?
182 The Dynamic System Aspect
Car
Gasoline Tank
drives
empty full
Driver
Car Fueling
Gas Station
21. Based on your responses to the previous two questions, explain why is it OK that in Fig. 13.13
Gas Station is an instrument, while in Fig. 13.14 it is an affectee?
Chapter 14
The Structural System Aspect
The Piglet lived in a very grand house in the middle of a beech-tree, and the beech-
tree was in the middle of the Forest, and the Piglet lived in the middle of the house.
Next to his house was a piece of broken board which had: “TRESPASSERS W” on it.
Winnie-The-Pooh, by A. A. Milne
Structure pertains to the relatively fixed, non-transient, long-term relationships that exist among objects—
components or parts of the system. Alternatively, structure can be viewed as a snapshot—a picture of the
generally dynamic system, or part of it, at some point in time. This snapshot captures the entire system at
some state, where each stateful object is at some state or in transition between two of its states, and
specific relationships between objects hold. Structure is contrasted with the complementary dynamic
aspect of the system, or its behavior, which has to do with the changes the system undergoes over time,
along with the causes for and effects of these changes. In other words, structure is about the static aspect
of the system, while behavior is about its dynamic aspect. This chapter is devoted to discussing the
structure of systems and expressing it through OPM.
A unary structural relation is possible with respect to aggregation participation, which is a structural
relation. For example, as the OPD in Fig. 14.1 shows, a Military Unit is comprised of one or more
(smaller) Military Units.
Fig. 14.1 Modeling a unary structural link as a link from the object to itself
As an example of how to model ternary or higher arity structural relations, consider modeling the
following sentence: “An underwater tunnel connects the city with an airport.” The relation “connects” can
be thought of as ternary relation, as it involves the three objects in that sentence. Using the state-
preserving process Connecting, we can model this system in OPM using three procedural links, as shown
in Fig. 14.2.
Fig. 14.2 Modeling a ternary structural link as three procedural links with the state-preserving process Connecting
As this example shows, n-ary relations with n 3 can be analyzed as a set of structural or procedural
binary links. Figure 14.3 shows the system in Fig. 14.2 using two structural links only and no process
whatsoever. Moreover, as we shall see, given that the relation tagged connected is transitive, it is possible
to conclude that “City and Airport are connected.”
Dori – Model-Based Systems Engineering with OPM and SysML 185
Fig. 14.3 The system in Fig. 14.2 specified using structure only
In view of this observation, we focus our attention on binary relations. Binary structural relations are
held between two things with the same perseverance, i.e., either between two objects—things whose
perseverance value is persistent, or static, or between two processes—things whose perseverance value is
transient, or dynamic. For example, aggregation-participation is a fundamental structural relation that is
applicable to processes just as well as it is to objects. However, in general, structural relations are more
prevalent with objects than they are with processes, so in this chapter we focus on binary structural
relations between objects.
A structural link is an arrow with an open head that represents a binary structural
relation in an OPD from a source object to a destination object.
The relation between structural relation and structural link is the same as the relation between
procedural relation and procedural link: In both cases, the link expresses graphically what the relation
expresses verbally. For example, the procedural (instrument) link in Fig. 14.2 between Underwater Tunnel
and Connecting is the graphical expression of the instrument relation between these two things. Likewise,
the structural (bidirectional tagged) link in Fig. 14.3 between Underwater Tunnel and City is the graphical
expression of the structural relation between these two objects, tagged connected.
The open head arrow, , which symbolizes a structural link, is contrasted with the closed triangular
arrowheads of the transforming links. As a reminder, transforming links include the four unidirectional
links symbolized as with different sources and destinations: (1) the consumption link (from object
to process), (2) the result link (from process to object), (3) the input link (from state to process), and (4)
the output link (from process to state). As we see, these four links share the same graphical symbol, and
the only difference between them is their different sources and destinations. The only bidirectional
transforming link is the effect link, , connecting a process and an object to denote an unspecified
state change (when we discuss values, which are states of attributes, we will see another use for this
symbol as well as for the input and output links).
A tagged structural link is structural link with a structural tag recorded along the
link.
On the left of Fig. 14.4 is an example of an OPD with four objects—Airport, City, Highway, and
Underwater Tunnel, and three tagged structural links. Two are unidirectional, with the tags serves and
surrounds. The third is a bidirectional tagged structural link with the tags “passes through the” and
“provides for shortening the”.
The OPD on the right of Fig. 14.4 demonstrates that a structural relation can exist also between two
processes. As the OPL sentences in Fig. 14.4 demonstrate, the syntax of a tagged structural OPL sentence
is a simple concatenation of the source thing followed by the tag, followed by the destination thing. The
tag is non-capitalized and is in bold Arial letters since it is user-defined rather than a reserved phrase.
Dori – Model-Based Systems Engineering with OPM and SysML 187
Fig. 14.5 Highway and Underwater Tunnel are linked with a bidirectional tagged structural relation
Engine Engine
is at
at ta
ta ch
is ch ed
at ed
ta to
ch
ed
to
Gearbox Gearbox
Fig. 14.6 Reciprocity exemplified. Left: The relation between Engine and Gearbox is reciprocal, since the two tags in the
bidirectional tagged structural relation, “is attached to”, are identical. Right: The equivalent, more succinct OPD, with
attached as the single reciprocity tag
A reciprocal structural link—the graphical expression of the reciprocal structural relation—is defined
as follows.
Reciprocity is a property of a structural relation that denotes whether its forward and
backward structural relations have the same semantics.
In the metamodel of a Structural Link, the three possible values of its Reciprocity property are
positive, neutral, and negative. The Reciprocity value is positive if the semantics of the link’s tag in both
the forward and backward directions is the same, negative if the tag semantics in the forward direction is
the opposite of that in the backward direction, and neutral if the tag semantics in the forward direction is
neither the same nor the opposite of that in the backward direction. The default Reciprocity value of
Structural Link is neutral.
A bidirectional tagged structural link with positive reciprocity can be called shortly a reciprocal
structural link, one with negative reciprocity is an anti-reciprocal structural link, and one with neutral
reciprocity—a non-reciprocal structural link.
190 The Structural System Aspect
Database conta
ins
Folder conta
ins
File conta
ins
Record
structural relation contains is transitive, we say that the value of the transitivity attribute of the structural
relation contains is positive. The structural relation in the middle of, which appears several times in the
excerpt from Winnie-The-Pooh at the beginning of this chapter, is also transitive.
A neutral transitive structural relation is a structural relation that may or may not be transitive.
Consider the relation is friend of as an example of a neutral transitive structural relation. It may be true
that if Al is friend of Ben and Ben is friend of Chen, then it may be the case that Al is friend of Chen, but
this is not guaranteed. Likewise, if A, B and C are closed shapes in a plane, A touches B and B touches C
may imply that A touches C, but this is not guaranteed. Hence, the transitivity value of both is friend of
and touches is neutral.
An example of a structural relation with negative transitivity is “directly contains”: If in Fig. 14.7 the
relation “contains” is replaced by “directly contains”, then if “Database directly contains Folder” and
“Folder directly contains File”, then it is false that “Database directly contains File”. A similar example
can be drawn for Fig. 14.8 if we change “feeds” to “directly feeds”.
As another example, suppose Jack is father of Jim and Jim is father of Jill, then Jack is not father of
Jill. As a final example from plane geometry, consider three points, A, B, C, and D along a straight line,
such that AB, BC, and CD are three line segments. If AB touches BC and BC touches CD, then the
sentence AB touches CD is always false. Hence, in this system, the transitivity of the structural relation
touches between two line segments on a line is negative.
In the metamodel of a Structural Link, the three possible values of its Transitivity property are
positive, neutral, and negative. The Transitivity value is positive if the semantics of the link’s tag is
transitive, negative if the tag semantics is such that the relation is never transitive, and neutral if the tag
semantics does not enable determining if the transitivity is positive or negative. The default Transitivity
value of Structural Link is neutral.
192 The Structural System Aspect
Table 14.1 Examples for the three values of Reciprocity and Transitivity
Value
feeds, contains, is ancestor of, adjacent, is next to, is is father of, directly
Transitivity surrounds, above, mixed, consists friend of, holds hand of contains, directly feeds
of
Knowledge about the reciprocity and transitivity values of links in the model can help deduce
relations that can extend beyond the link destination, and this can be automated to generate new
knowledge from a complex model, where remote relations that may extend over several OPDs are not
obvious by merely inspecting the model visually. Table 14.1 provides several examples for each one of
the three values of the two structural relation properties—Reciprocity and Transitivity.
To enhance the analytical power of an OPM model, non-default values of a link’s reciprocity and
transitivity can be stored in a model by an OPM modeling tool as a property (meta-attribute) of the link,
which can be made accessible, (e.g., by double-clicking the link). For example, if the OPM model
contains a tagged structural relation with the tag “contains”, we can store the fact that the value of the
Transitivity property of this relation is positive, i.e., contains is a transitive relation. This enables the
model to deduce that if A contains B and B contains C, then A contains C.
14.2.3 Null Tags, Null Structural Links, and Their Default OPL Phrases
The tag in both the unidirectional and the bidirectional tagged structural links may be the null tag, i.e., an
empty tag. The OPM models in Fig. 14.9 show Freedom and Justice connected by a unidirectional (top)
and bidirectional (bottom) null structural links—structural links with null tags.
The default null tags are the most general ones; they involve word relation, as defined below.
The unidirectional default null tag is the default null tag for the unidirectional
structural link, and its associated OPL reserved phrase is “relates to”.
The bidirectional default null tag is the default null tag for the bidirectional structural
link, and its associated OPL reserved phrase is “related”.
For the OPDs in Fig. 14.9, these default null tags give rise to the OPL sentences written on the right
hand side of Fig. 14.9.
Dori – Model-Based Systems Engineering with OPM and SysML 193
.
Fig. 14.9 Freedom and Justice connected by a unidirectional (top) and bidirectional (bottom) null structural links
A Model-specific null tag is a tag defined by the system modeler that overrides the
default null tags for a specific system model, an enterprise, or a domain.
As there are two default null tags, the unidirectional default null tag and the bidirectional default null
tag, there are two respective user-defined null tags: the unidirectional model-specific null tag and the
bidirectional model-specific null tag.
Fig. 14.10 Example of use of the bidirectional user-defined null tag connected
For example, suppose for the system represented by Fig. 14.9, the system modeler sets the user-
defined unidirectional null tag to “leads to” and the user-defined bidirectional null tag to “equivalent”.
The two OPL sentences corresponding to the two OPDs in Fig. 14.9 would then be:
Freedom leads to Justice.
Freedom and Justice are equivalent.
Since user-defined null tags are, by definition, user-defined, they are bolded by default, but the user
can define them to be non-bold. The minimal scope of user-defined tags is the entire OPM model, but, as
noted, it can be extended to a group of models or to an enterprise or to an entire domain.
One of the most useful bidirectional user-defined null tag is connected. For example, suppose in the
OPM model in Fig. 14.10 the bidirectional user-defined null tag has been defined to be connected, the
OPL paragraph would change accordingly to the two first OPL sentences in Fig. 14.10.
194 The Structural System Aspect
14.4 Summary
A structural relation is a linkage, connection, or association between two objects or between
two processes that holds in the system for at least some time.
A binary structural relation is bidirectional.
Dori – Model-Based Systems Engineering with OPM and SysML 195
A structural link is an arrow with an open head that represents a binary structural relation in an
OPD from a source object to a destination object.
A structural tag is a phrase that expresses the semantics—the nature, meaning, or content—of
the structural relation between the two things that participate in the relation.
A tagged structural link is structural link with a structural tag recorded along the link.
A bidirectional tagged structural link is a combination of two tagged structural links in opposite
directions.
Property is an attribute of an OPM model element.
A reciprocal structural relation is a structural relation for which it holds that if A B and B
′ A then = ′.
A reciprocal structural link is a bidirectional tagged structural link, in which the identical
forward and backward tags are replaced by a single reciprocity tag.
Reciprocity is a property of a structural relation that denotes whether its forward and backward
structural relations have the same semantics.
A transitive structural relation is a structural relation for which it holds that if A B and B
C then A C.
Transitivity is a property of a structural relation, which determines whether the structural
relation is transitive.
The values of both the reciprocity and the transitivity properties of a structural relation can be
positive, neutral, or negative.
The unidirectional default null tag is the default null tag for the unidirectional structural link,
and its associated OPL reserved phrase is “relates to”.
The bidirectional default null tag is the default null tag for the bidirectional structural link, and
its associated OPL reserved phrase is “related”.
A user-defined null tag is a tag defined by the system modeler that overrides the default null
tags for a specific system model, an enterprise, or a domain.
State-preserving processes convey a message of continuity, stability, detachment from time, or
steady state.
14.5 Problems
1. In Fig. 14.2, is Connecting a state-preserving process? Explain.
2. What is the difference between a structural relation and a structural link?
3. In Fig. 14.5, change each one of the two unidirectional tagged structural relations to a
bidirectional one.
4. Update the OPL to reflect the changes you made in response to the previous question.
5. In Table 15 add three examples in each one of the six cells.
196 The Structural System Aspect
6. Give three examples of state-preserving processes that are not provided in this chapter.
7. Write six English sentences that express binary structural relations. For each sentence draw the
corresponding OPD and write the OPL sentences.
8. Draw three OPDs that express unidirectional binary structural relations and three OPDs that
express bidirectional binary structural relations. For each OPD write the corresponding OPL
sentence(s).
9. Pick up a book, a newspaper or a magazine you have handy and open it at a random page.
a. Find 7–10 structural relations expressed in this page.
b. Write their OPL sentences.
c. Draw their OPDs.
10. Draw an OPD of a real product in your house or one that you are familiar with that has at least
three levels of aggregation. Write the corresponding OPL paragraph (the OPL sentences that are
equivalent to the OPD).
11. Find examples of three relations, one with a positive transitivity, one with a neutral and one with
a negative transitivity. Draw their OPDs and write their OPL sentences.
12. When Don turns his laptop on, using the power button, his Internet browser is set to open with
the URL of his favorite comics site, which he reads on a daily basis. A button near the top of his
browser opens his email account. After reading both, he shuts down the computer.
a. Apply OPM to model this description in three different ways:
(1) Using only objects and structural relations;
(2) Using as many processes and states as possible, and only procedural relations; and
(3) Using a combination of the two ways above.
b. Reflecting on the three models you built, answer the following questions.
(1) Which model most faithfully described the system?
(2) Which model conveys the most details?
(3) Which model captures best what Don was doing? Why?
(4) Which model do you prefer? Explain and point to likes and dislikes in each.
Chapter 15
Participation Constraints and Forks
Fork: the point or part at which a thing, as a river or a road, divides into branches.
Dictionary.com
In all the examples and discussions so far we have tacitly assumed that each thing, be it object or process,
participates in the relation singly, i.e., in a quantity of exactly 1. Indeed, the convention in OPDs is that
when no quantity is explicitly recorded by the side of a structural link, it is taken to be 1, which is the
default value. In general, however, we may wish to specify a certain number or a range of numbers of
instances of the same class of things that participate in the relation. Similarly, our models so far have
tacitly assumed that a process involves one object instance of each object class to which it is linked.
Indeed, this is the default. However, it is sometimes required to model the fact that more than one object
takes part in a process. Process participation constraints and link cardinalities are designed to take care of
this. We then turn to another useful notation—the fork—which is based on the observation that structural
relations are distributive in a sense analogous to the distributive law in algebra. This is graphically
represented via forks, as defined, discussed and demonstrated in this chapter.
destination side of the structural link is different than 1, it has to be specified explicitly, as shown in Fig.
15.1 for a structural relation.
1
Usually that means concatenating the letter s, but a program that generates OPL sentences from OPDs should also
account for exceptions of converting a noun from singular to plural. Indeed OPCAT handles most of the irregularities
associated with plurals.
Dori – Model-Based Systems Engineering with OPM and SysML 199
Two compound participation constraints are exemplified in Fig. 15.4. In the left OPD, the compound
participation constraint comprises two ranges. In the first range, qmin = 3 is the lower bound and qmax = 5 is
the upper bound. The two quantities are separated by two consecutive dots. The second range is 8..10. In
the right OPD of Fig. 15.4, the compound participation constraint comprises one number, 2, and one
parameterized range, 3*n, where n 4.
Often, qmin is a small number, such as 0, 1, or 2, while qmax is the symbol *, which stands for many. The
symbol * is a “reserved symbol” in participation constraint, meaning that the exact value of “many” is not
fixed as in an algebraic equation. A letter stands for a parameter—a particular, yet unspecified number.
Table 15.1 The abbreviated participation constraint symbols, their bounds, phrases, and sample OPDs with
corresponding OPL sentences
15.4 Cardinality
In a structural relation, each link edge—one on the source side and the other on the destination side—can
have a participation constraint that is in general independent of the participation constraint on the other
edge.
entity relationship diagrams (ERDs), proposed by Chen (1976), which are used to design databases. Here
we see that they comprise one quarter of the 16 possible combinations.
Table 15.2 The 16 cardinality types obtained by combinations of pairs of the four participation constraint kinds
Fig. 15.7 Participation constraints in procedural links with parameters, ranges, and parameter constraints
As both the OPD and the OPL express, in this Blade Replacing system, a Jet Engine has b Installed
Blades. Two to four (a number set to k) Aviation Engine Mechanics handle the process, for which they
use k Blade Fastening Tools. The Blade Replacing process is also handled by one or two Aerospace
Engineers. This process yields b Dismantled Blades, which undergo Blade Inspecting, an environmental
process that yields a number a (which is at most b) of inspected Blades. The process consumes a total of
b Blades, of which i are inspected and b–i are new. This is the number of new Blades obtained by
Purchasing them. This example shows not only how parameterized participation constraints are used with
procedural links, but also how they can serve to express parameter constraints—constraints among the
parameters. Additional constraints can be added. For example we could specify that i≤b to avoid getting a
negative number for b–i.
Dori – Model-Based Systems Engineering with OPM and SysML 205
If A, B, and C are all objects or are all processes, and is a structural relation, then
A B, A C A (B, C ).
This is not just a law in mathematics and in OPM, but, as we see next, the same idea is applicable also
in natural languages. The two OPDs in Fig. 15.9 provide an example of the graphical application of the
distributive law of structural relations. In the OPD on the left hand side of Fig. 15.9 there are two disjoint
tagged structural links, both bearing the same tag employs. One employs tag is recorded along the link
from Firm to Graphic Designer and the other—along the link from Firm to Systems Engineer. This OPD
206 Participation Constraints and Forks
has exactly two graphic sentences, each giving rise to one OPL sentence. Denoting the relation employs
by , Firm by A, Graphic Designer by B and Systems Engineer by C, ignoring the added participation
constraints, this is like writing A B, A C.
Fig. 15.9 The distributive law of structural relations applied in OPDs. Left: disjoint links. Right: joint links
This is not just a law in mathematics and in OPM, but, as we see next, the same idea is applicable also
in natural languages. The two OPDs in Fig. 15.9 provide an example of the graphical application of the
distributive law of structural relations. In the OPD on the left hand side of Fig. 15.9 there are two disjoint
tagged structural links, both bearing the same tag employs. One employs tag is recorded along the link
from Firm to Graphic Designer and the other—along the link from Firm to Systems Engineer. This OPD
has exactly two graphic sentences, each giving rise to one OPL sentence. Denoting the relation employs
by , Firm by A, Graphic Designer by B and Systems Engineer by C, ignoring the added participation
constraints, this is like writing A B, A C.
In the OPD on the right hand side of Fig. 15.9, the two employs tagged structural links are joined at
their origin and fork (diverge) somewhere along the link. Since now only one structural link emanates
from the source object, the two OPL sentences become one. Using our notation, again ignoring the added
participation constraints, this is like writing A (B, C). The expressions representing the left and right
OPDs are the same as those in the algebraic formula of the distributive law above (with the addition of the
participation constraints). Indeed, they are semantically equivalent both graphically and textually.
Processes can also be related by structural relations that are distributive, but since the use of structural
relations is much more prevalent for objects, we focus on objects.
Graphically, joining of the origin of the two structural links in Fig. 15.9 having the same tag employs
has the same function as the algebraic parentheses. The parentheses in the distributive law expression
A(B, C) AB, AC enable using just once. Analogously, the joint tagged link enables using
employs just once in both the OPD and is corresponding OPL sentence. Finally, the OPL reserved word
and is analogous to the comma in the distributive law expression. Joining structural relations with the
same tag gives rise to forks, which are discussed next.
Dori – Model-Based Systems Engineering with OPM and SysML 207
A fork is a combination of two or more structural links with the same semantics
expressed by the same tag.
A fork has a common joint edge on the origin side of the link, called handle, which splits into two or
more edges on the destination side of the link, each of which is a tine.
Handle thing is the thing linked to the handle of the fork link
Danube
River
pas
pa
h
pa pas
ugh ough gh ss ses passes th
roug
sse
ug
thro
ses
r ou es s th
ses ses th thr thro
ugh rough
ro
s s th r o
th
p a ro ug
es th
pas e
thro
ss h
es
ug
pa h
ss
ugh
pa
pass
Germany Austria Slovakia Hungary Croatia Serbia Bulgaria Romania Moldova Ukraine
Danube River passes through Moldova. Danube River passes through Germany.
Danube River passes through Romania. Danube River passes through Hungary.
Danube River passes through Serbia. Danube River passes through Austria.
Danube River passes through Slovakia. Danube River passes through Bulgaria.
Danube River passes through Ukraine. Danube River passes through Croatia.
Fig. 15.10 The 10 countries through which the Danube River passes through
Fig. 15.11 The 10 “passes through” tagged links in Fig. 15.10 are replaced by a single fork with the same tag
Figure 15.12 is an example of a fork in which all the linked things are processes, demonstrating that
all the things connected by a fork are of the same persistence: either all are object or all are processes.
This is so because structural relations are between things of the same persistence, i.e., between two
objects or between two processes. Therefore, if the handle thing is an object, the tine things are all objects
too, and vice versa.
The tine thing set of a fork is the set of all the things linked to the tines of the fork.
The tine object set of a fork is the set of all the objects linked to the tines of the fork, while the tine
process set of a fork is the set of all the processes linked to the tines of the fork.
The tine object set of the fork labeled employs in the OPD in Fig. 15.9 includes the two types of
occupations that the Firm employs. The tine object set of the fork labeled employs in the OPD in Fig. 15.9
is {Graphic Designer, Systems Engineer}. The tine object set of the fork labeled passes through in the
OPD Fig. 15.11 is {Germany, Austria, Slovakia, Hungary, Croatia, Serbia, Bulgaria, Romania, Moldova,
Ukraine}.
Frequently, showing all the fork things overloads the OPD both graphically and mentally, as is the
case in Fig. 15.11. If the tine object set is significantly greater than 2, as in Fig. 15.11, it may be
convenient to omit some of the objects in the tine object set that are not relevant for what that particular
OPD is designed to convey. Indeed, recall that the model fact representation OPM principle stipulates that
an OPM model fact needs to appear in at least one OPD in order for it to be represented in the model;
objects that are not relevant in a particular OPD do not need to be shown in it. Following this principle,
not each OPD in a system’s OPD set that contains the handle thing must contain all the things in the tine
thing set. Suffice it that each one of the tine things appears once in a relation to the handle thing in
order for it to be part of the set of tine things. We exemplify and elaborate on this when we define and
discuss the fork degree and comprehensiveness properties next. One OPD may contain one subset of the
tine thing set, while in other OPDs that belong to the same OPD set, other subsets of things connected to
tines can be hidden to alleviate cognitive load and enhance the diagram readability.
Three fork properties help refine the OPM model: degree, comprehensiveness, and orderability. These
are discussed next in this section.
Fork degree is a property of fork whose value is the size of the tine object set.
210 Participation Constraints and Forks
For example, the degree of the fork in Fig. 15.9 whose handle is Firm is 2.The degree of the fork from
Danube River in Fig. 15.11 is 10, as the tine object set of the fork labeled passes through in the OPD in
Fig. 15.11 includes all ten countries through which the Danube River passes.2
The tine thing set of a fork is the union of the tine sets emanating from the same
handle and having the same tag in all the OPDs in the OPD set.
For example, suppose another OPD in the OPM model to which the OPD in Fig. 15.9 belongs has the
following tine object set of size 4: {Systems Engineer, Programmer, Software Engineer, Project Leader}.
Suppose also that these are the only two OPDs in the OPD set of that OPM model where the object Firm
appears with the tagged structural link labeled employs. The tine object set of the fork labeled employs
would then be: Tine-object-set (Firm employs) = {Graphic Designer, Systems Engineer} {Systems
Engineer, Programmer, Software Engineer, Project Leader} = {Graphic Designer, Systems Engineer,
Programmer, Software Engineer, Project Leader}. The fork degree of the OPD that shows all the
occupations that the firm employs is 5—the size of the tine object set.
2
For trivia lovers: The Danube river passes across the most national borders (askville.amazon.com).
Dori – Model-Based Systems Engineering with OPM and SysML 211
Fig. 15.13 A non-comprehensive fork is marked by the short bar perpendicular to the fork near the handle object
The default value of the fork’s Comprehensiveness property is positive, meaning that the fork is
comprehensive and indicating that all the objects in the tine set of the fork are attached to the fork’s
handle. In this default case the handle will not be marked with the non-comprehensive fork symbol. The
other value of Comprehensiveness is negative, so the fork is non-comprehensive, implying that the tine
set is incomplete, as at least one tine thing is missing. The OPL reserved phrase “and at least one more” at
the end of the OPL sentence in Fig. 15.13 expresses this. A non-comprehensive fork can be made
comprehensive by completing the missing things in the forks’ tine thing set while removing the non-
comprehensive fork symbol, thereby changing its Comprehensiveness state from negative to positive.
Orderability is a Boolean property of a fork’s thing tine set, which is positive if the
things in the tine thing set are ordered and negative otherwise.
Like Comprehensiveness, Orderability is a Boolean attribute of the Tine Set of a Fork, whose values
are positive and negative. A Tine Set with negative Orderability is an Unordered Tine Set, and this is the
default, so it requires no special indication.
For a thing tine set with positive orderability, there often (but not always) exists some logical relation
of the things in the tine thing set {T1 … TN} such that T (j) T (j+1) for each T (j) in {T (1),T (2),..,T (N)}. For
example, if Ti; 1 < i < N is a set of N natural numbers, and is the < inequality symbol, then the
orderability of the tine thing set is positive. If the tine thing set is the parts of a scientific paper {header,
body, footer} there is no that determines this order.
A Tine Set with positive Orderability is an Ordered Tine Set. To denote that a fork’s tine set is
ordered, the word ordered appears next to the handle of the fork, as demonstrated in the OPD in Fig.
15.14. The word ordered is a graphic symbol rather than a reserved OPL phrase, because it is part of the
OPD just like the non-comprehensiveness fork symbol.
212 Participation Constraints and Forks
As Fig. 15.14 shows, the OPL reserved phrase for denoting that a tine thing set is ordered, is “in this
order”, which is added after a comma at the end of the sentence. For a non-comprehensive and ordered
fork, the OPL phrase is “and at least one more, in that sequence”.
Fig. 15.14 An ordered tine set of a fork relation is marked by the word “ordered” next to the fork’s handle
To express the order graphically, the things in the tine thing set must be arranged either horizontally
from left to right, as in Fig. 15.15, or vertically, from top to bottom. The object boxes may not be ordered
nicely even though the orderability of the tine thing set is positive.
To resolve this potential ambiguity, the ordering algorithm is to arrange the objects by the left-to-right
order of their leftmost side of the object box (increasing x coordinate), and for those with the same left
side coordinate, arrange by top-to-bottom order of the topmost side of the object box (decreasing y
coordinate, or increasing if we consider the coordinates of pixels in a monitor). The same applies to
processes, where the box is the one that encloses the process ellipse.
Order rule is a property of an ordered tine thing set, which specifies textually in the
OPD the rule or criterion according to which the things in the tine thing set are
ordered.
The Order Rule can be null, which is the default, or any other phrase written in lower-case letters.
Order Rule whose value is null means that there is no order criterion, and nothing (if there is no order) or
“ordered” (if there is order but the rule is trivial, such as the order of the days of the week) is written next
to the handle.
If there is an ordering rule that needs to be specified, the phrase “ ordered by” rather than “ordered” is
used in the OPD next to the fork, and recorded below it is the order criterion itself. For example, the
OPD in Fig. 15.15 indicates an ordered tine set with the order rule “river flow”, implying that the countries
are ordered by following the flow of the Danube River.
Dori – Model-Based Systems Engineering with OPM and SysML 213
Fig. 15.15 Order criterion marked by the phrase “ordered by”, followed by the order criterion “ river flow” below it
15.9 Summary
A participation constraint is a number or a mathematical expression recorded along a link next
to an object, which denotes the multiplicity (number of repetitions) of that object in that relation.
A structural participation constraint is a participation constraint recorded along a structural
link.
A procedural participation constraint is a participation constraint recorded along a procedural
link.
The default participation constraint is 1, and it is implicit.
A parameterized participation constraint is a participation constraint which is a mathematical
expression with one or more parameters.
A range participation constraint is a participation constraint with lower and upper bounds, each
possibly an expression, on the number of possible objects that can take part in the relation.
Source participation constraint is the participation constraint on the source side of the
(structural or procedural) link.
Destination participation constraint is the participation constraint on the destination side of the
(structural or procedural) link.
Cardinality is a property of a link whose value depends on the combination of the source and
destination participation constraints of the structural link.
The distributive law of structural relations: If A, B, and C are all objects or are all processes,
and is a structural relation, then A B, A C A (B, C ).
A fork is a combination of two or more structural links with the same semantics expressed by the
same tag.
Handle is the joint origin-side edge of the fork.
Tine is the split destination-side edge of the fork.
Handle thing is the thing linked to the handle of the fork link
214 Participation Constraints and Forks
15.10 Problems
1. Model a system in which three cranes are used to lift an elevator to the top of a new building.
2. Change the objects, the tag in the tagged structural relations, and the participation constraints in
each of the four OPDs in in Fig. 15.5 such that meaningful sentences are obtained.
3. Select from Table 15.2 3 of the 16 cardinality types. For each, create and OPD that demonstrates
it.
4. Model a library comprised of n shelves, each of which can hold up to 20 books.
5. For the library in the previous question, model a process Maximal Number of Books Computing
that does what its name says.
6. Model two object forks with objects and two process forks, and write their OPL paragraphs.
7. For each fork in the previous problem, draw an OPD assuming that the distributive law of
structural relations does not exist. Which option is more compact? Why?
8. Specify the tine thing set and the fork degree for each one of the four forks in the previous
problem.
9. For one object fork or one process fork from the previous question add a new fork whose tine
thing set has a non-empty intersection with the old fork.
10. Add a non-comprehensiveness fork symbol where appropriate in the forks of the previous
question.
11. Draw the comprehensive fork of the two forks from the previous question.
12. Is there any potential order criterion in any one of the four forks from the first question? If so,
pick one and add to it is orderability criterion. If not—design a new ordered fork and specify its
order criterion.
13. Write the OPL sentences for all the OPDs in your answers to the questions in this chapter.
Chapter 16
Fundamental Structural Relations
Four structural relations are most prevalent and play an especially important role in specifying and
understanding systems. Termed the fundamental structural relations, these relations are:
Aggregation-participation, which denotes the relation between a whole and its parts,
Exhibition-characterization, 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,
Generalization-specialization, which denotes the relation between a general thing and its
specializations, giving rise to inheritance, and
Classification-instantiation, which denotes the relation between a class of things and an instance of
that class.
This chapter is devoted to discussing these structural relations, while subsequent chapters deal with
each of them separately.
Table 16.1 The fundamental structural relation names, OPD symbols, and OPL sentences
Structural Relation Name
OPL Sentence(s)
[Participant Name] Graphic Symbol
Forward Backward with OPD usage
Forward Backward
[Refineable] [Refinee]
Whole
Aggregation Participation Whole consists of
[Whole] [Part] Part A and Part B.
Part A Part B
General Specialization A
Thing and
Generalization Specialization
Specialization B
[General] [Specialization] Specialization Specialization are General
A B Things.
Class Instance A and
Classification Instantiation Instance B are
[Class] [Instance] instances of
Instance A Instance B Class.
1
The pair of words “dash-separated” is a pair of dash-separated words (pun intended).
Dori – Model-Based Systems Engineering with OPM and SysML 217
is selected to be the more meaningful of the two: Aggregation, Characterization, Generalization, and
Classification.
As Table 16.1 shows, all the four fundamental structural relation symbols are equilateral triangles
linked via orthonormal polylines, i.e., lines whose segments are parallel to either one of the diagram axes
(also called Manhattan lines). The tip of the triangle is linked through an orthonormal polyline to the root
of the hierarchy tree—the aggregate or whole in our case (Whole, in the first row of Table 16.1, for
example). The triangle’s base is linked through other orthonormal polylines to each one of the parts of the
aggregate (Part A and Part B in our example). The fact that the links of the fundamental structural
relations run horizontally or vertically but not diagonally (like all the procedural links) helps differentiate
them visually from procedural links. Using different colors for different links that cross each other (which
should be avoided as much as possible) is also helpful in crowded OPDs.
The OPL sentences of the fundamental structural relations are also either in the forward or the
backward direction. The direction was similarly determined by how natural the sentence sounds in plain
English. The forward direction is used for aggregation and characterization:
Whole consists of Part A and Part B.
Exhibitor exhibits Attribute A, as well as Operation B.
As usual, the multiple versions of these two OPL sentences, which include three or more refinees, are:
Specialization A, Specialization B, and Specialization C are General Things.
Instance A, Instance B, and Instance C are instances of Class.
16.4 Summary
Four structural relations are fundamental and therefore are assigned graphic symbols.
Refineable is a thing amenable to refinement via a fundamental structural relation.
Refinee is a thing that refines a refineable.
The four fundamental structural relations are:
Aggregation-participation;
Exhibition-characterization;
Generalization-specialization; and
Classification-instantiation.
Each fundamental structural relation has a unique triangular symbol.
The symbol replaces the tag, making the OPD more graphic and more quickly comprehensible.
Each fundamental structural relation induces a hierarchy.
Complex hierarchies can be created by mixing the four relations.
In certain domains, additional structural relations might be fundamental and user-defined dedicated
symbols can be allocated for them.
16.5 Problems
1. For each thing in Table 16.1 indicate whether it is a refineable or a refinee.
2. For each OPD in Table 16.1 draw an alternative OPD without using a fundamental relation.
3. For each OPL sentence in Sect. 16.2 provide a concrete OPL example and its corresponding
OPD.
Having laid down in Part II the fundamentals and foundations of model-based systems engineering in
both OPM and SysML, Part III goes to the heart of conceptual modeling. In the first four chapters of this
Part, we delve into the details and usage of each one of the four fundamental structural relations. Chapters
17 and 18 discuss aggregation-participation and exhibition-characterization, respectively. Chapter 19 is
about states and values, concepts that are needed for the two remaining fundamental structural relations—
generalization-specialization and classification-instantiation, both elaborated on in Chap. 20. Chapter 21
concerns complexity management. It defines and describes the four refinement and abstraction
mechanisms of OPM while also discussing complexity management in SysML. Chapter 22 is about OPM
operational semantics and control links—the way control is managed during execution of the system. In
Chap. 23 we specify how to model logical operators and probabilities. Finally, Chap. 24 is an overview of
ISO 19450 Publically Available Specification (PAS)—Automation Systems and Integration—Object-
Process Methodology, adopted by the International organization for Standardization in 2014.
Chapter 17
Aggregation-Participation
The whole is more than the sum of its parts.
Aristotle, Metaphysica
This chapter discusses the first fundamental structural relation, possibly the most important one:
aggregation-participation—the relationship between the whole and its parts. Any interesting system can
be described as a whole decomposed into parts. The system as a whole and any one of its parts can then
be described separately using natural language adjectives to assign attribute values to objects and adverbs
to assign attribute values to processes. Without the ability to mentally take things apart and examine their
features, our ability to study systems would be greatly hindered. Aggregation-participation is also known
as whole-part (Coad and Yourdon 1991), composition (Kilov and Simmonds 1996), or the part-of
relationship (Fowler 1996).
In 1924, Wertheimer and Reizler (1944) introduced the gestalt theory, which basically claims that
“what is happening in the whole cannot be deduced from the characteristics of the separate pieces” and
that what happens to parts of the whole is determined by laws relating to the structure of that whole. A
configuration or pattern of elements in any domain is unified as a whole so much that its properties
cannot be derived from a simple summation of its parts. In psychology, Rescher and Oppenheim (1995)
have provided a conceptual framework for the precise explication of the gestalt concept of “whole” and
summarized the intuitive requirements or conditions of talking about a whole and its parts:
The whole must possess some attribute in virtue of its status as a whole, an attribute peculiar to it
and characteristic of it as a whole. The parts of the whole must stand in some special and
characteristic relation of dependence with one another; they must satisfy some special condition in
virtue of their status as parts of a whole.
1
Already in this sentence, as well as in this footnote, we have a built-in example that shows the multiple uses of
“have.”
224 Aggregation-Participation
paragraph on the right hand side of Fig. 17.1, in which one OPL sentence, “Lamp consists of Light Bulb,
Base, and Electric Cord.” replaces six OPL sentence on the left.
Lamp Lamp
co
ns
of
f ist
s
consists
to
is part of
f is of
pa
r
tso pa
is sis rt
c on of
in contact in contact
Fig. 17.1 Aggregation expressed by three tagged structural links (left) and the aggregation-participation symbol (right)
The solid black triangle —the aggregation-participation relation symbol—replaces the pair of
forward and backward textual tags of the bidirectional structural link that express textually the
aggregation-participation relation. Like the rest of the fundamental structural relation symbols, the
aggregation-participation relation symbol is a helpful shorthand graphic notation convention for this
important and widely used structural relation. The symbol helps identify the relation easily in the OPD,
saving graphic clutter and excessive text typing and reading.
Being a structural relation, the aggregation-participation relation abides by the distributive law, two or
more structural links can be represented as a fork. In the OPD at the right of Fig. 17.1, the relations
between Lamp and its three parts are expressed using the specific symbol designated for the aggregation-
participation relation, a solid black equilateral triangle, , whose base is horizontal. The whole is linked
to the top of the triangle and the parts—to its base. This enables replacing the first six OPL sentences on
the left with a single one—the first on the right. Unlike the tag “consists of” in Fig. 17.1, which, being
user-defined, is bold, the phrase “consists of” in Fig. 17.1 is a reserved OPL phrase and therefore it is not
bold.
An example of the use of the aggregation-participation fundamental structural relation can be found in the
following excerpt taken from Sect. 2.2 of the RDF Primer (Manola and Miller 2004):
“…each statement consists of a subject, a predicate, and an object.”
The use of the phrase “consists of” is a clear indication of the existence of a whole-part, or
aggregation-participation relation between the whole and its part. Indeed, as we have seen, OPM uses this
as a reserved phrase to denote this relation. The OPD that is equivalent to this OPL sentence (and should
be generated from it by any OPM-supporting tool such as OPCAT) is depicted in Fig. 17.2. Indeed, this
OPL sentence is almost identical to the original one above.
Fig. 17.2 OPD of the sentence “RDF Statement consists of Subject, Predicate, and Object”
The black triangle, which denotes the aggregation-participation fundamental structural relation, has its
tip is linked to the aggregate (the whole, which is the object RDF Statement), while its (always horizontal)
base is linked to its three parts: Subject, Predicate, and Object. This is a fork, in which RDF Statement is
the handle object, and the set {Subject, Predicate, Object} is the tine object set. If forks did not exist, the
OPD would have required three separate aggregation links, each with its own black triangle symbol. As
we will soon see in Fig. 17.4, since UML and SysML do not have the notion of fork, we would indeed
need three separate aggregation (diamond symbols) to express the same three model facts.
“An RDF triple contains three components: the subject, which is an RDF URI reference or a
blank node, the predicate, which is an RDF URI reference, and the object, which is an RDF URI
reference, a literal or a blank node.”
Comparing these two excerpts from the same document, we must deduce that “has three parts” has
the exact same meaning as “contains three components,” as both relate to the composition or structure of
an RDF triple. Moreover, if we accept that the semantics of the verbs “contains” and “has parts” in this
context is the same as “consists of,” then we can summarize the two citations above in the following OPL
sentence:
RDF Triple consists of Subject, Predicate, and Object.
The problem of multiple words, idioms, or phrases that have the same or almost the same semantics,
which is demonstrated here, is a major issue in natural language processing (NLP) and understanding.
Using their natural human intelligence, human beings normally have no problem assigning the same
semantics to such different syntactic entities, and grasp subtle differences when they exist and are
relevant. The example above shows that even in highly formal documents, such as one defining the
semantic Web, in which semantics is the issue of discourse, free use is made of equivalent idioms and
phrases, justifiably counting on the human intelligence to resolve it.
Indeed, people interpret meaningful sentences effortlessly all the time without even paying attention to
the fact that other words and a totally different syntax was used to express the same semantics. When
NLP techniques are considered, this issue becomes of prime importance, and has to be dealt with
meticulously. OPL solves this problem by being a subset of English that is defined formally via a context-
free grammar. Future developments in automated sematic sentence understanding can be key to model
evolution of ground-truth, humanly validated kernel OPM models, such as the one developed by Somekh
et al. (2014) for the mRNA lifecycle.
as naming an attribute when only the names of its values are explicit.2 In cases like these, we must
exercise our creativity to generate an appropriate phrase that best captures the essence of what we wish to
express.
The capability of inventing meaningful names, or generating expressive phrases, is a very important
component of the analysis process. It provides us with the power to abstract into a whole a collection of
things that would otherwise be very difficult to think about and relate to as a unity. Recall that indeed the
first OPM principle—the Function-as-a-Seed OPM Principle—calls for starting the process of modeling a
system by defining, naming, and depicting the function of the system. The name of the function shall
express what the system is designed to do, and what value its beneficiaries will gain from using it.
Fig. 17.3 Naming an aggregate which has no single word in natural language
Shared aggregation, also called simply aggregation, denoted as a white (blank) diamond next to
the whole end of the link, is a loose, “weak” type of whole-part relationship. Unlike composite
aggregation, in shared aggregation, the part has “life of its own,” and it can be part of more than one
whole. According to Object Management Group (2010, p. 39), “precise semantics of shared
aggregation varies by application area and modeler.” While usually, in shared aggregation each
part can exist independently of the whole, leaving the semantics of a relation vague is not a good
idea to begin with. The tagged structural relation in OPM is user-defined, and this would be a better
way to express specific semantics by application area or modeler, rather than leaving the semantics
of a language symbol open to a variety of interpretations by various modelers even in the same
domain and even if all of them relate to the same system model.
The connecting lines of the aggregation relation in UML need not be orthonormal and are usually
diagonally straight, as Fig. 17.4 demonstrates. UML and SysML do not have the fork construct, so as Fig.
17.4 shows, each part in a UML (and SysML) class diagram needs to be connected with a dedicated
aggregation symbol.
Composition is stronger than aggregation in that the whole is “responsible” for its parts, so when the
whole is consumed so are all the objects of which it is composed. Hence, the part cannot be owned by
more than one whole. Here is what the UML 2.0 Superstructure document v 2.2 (2005) says about
composite aggregation (p. 41):
“An association may represent a composite aggregation (i.e., a whole/part relationship). …
Composite aggregation is a strong form of aggregation that requires a part instance [to] be
included in at most one composite at a time. If a composite is deleted, all of its parts are normally
deleted with it. Note that a part can (where allowed) be removed from a composite before the
composite is deleted, and thus not be deleted as part of the composite.”
Window
1 1
1
+scrollbar
2 +title +body 1
1
Slider
Header Panel
Fig. 17.5 OPM model demonstrating how UML/SysML shared and composite aggregation can be modeled in tandem
Fig. 17.6 The OPD label “ordered” and the OPL reserved phrase “in that sequence” indicate the order of the parts of
RDF Triple from left to right (in the OPD on the left) or top-down (in the OPD on the right)
We model graphically the fact that the three elements of an RDF triple are ordered by adding the label
ordered next to the black triangle symbolizing the aggregation-participation relation, as shown in the OPD
in Fig. 17.6. The parts can be ordered with no sematic difference either from left to right, as the OPD on
230 Aggregation-Participation
the left shows, or top-down, as the OPD on the right shows. The corresponding OPL phrase is “in that
sequence”, which follows a comma after the name of the last part in the ordered list.
The OPD in Fig. 17.7 is an example of an aggregation hierarchy, which specifies the reading order of
a scientific paper, i.e., the order in which the parts of the paper should be read, with participation
constraints, which are discussed in Chap. 15.
When dealing with processes, orderability is intimately related to the top-to-bottom timeline within an
in-zoomed process, which dictates the process execution order. We elaborate on this in Chap. 21 while
discussing complexity management.
Fig. 17.7 The ordered aggregation hierarchy of a scientific paper with participation constraints
In order to model this sentence in OPM, using our prior knowledge about graphs and assuming that a
graph has at least two nodes and one arc (which is the case with RDF graphs), we break the sentence
above into the following three simpler, more explicit sentences:
Dori – Model-Based Systems Engineering with OPM and SysML 231
Fig. 17.8 The OPM model of a graph consisting of at least one node and optional arcs
Under the assumption that if two things consist of exactly the same set of parts, or components, they
are equivalent (if not the same), one can deduce that RDF Triple and RDF Statement are equivalent. This
statement is expressed in the OPM model depicted in Fig. 17.9 by the (vertical) null tag bidirectional
structural link between these two objects, which combines model facts from Figs. 17.6 and 17.8. This
OPD also expresses that Subject and Object in an RDF Graph are Nodes in a general Graph, and that
Predicate in an RDF Graph is an Arc in a Graph.
Another example for the use of the null tag bidirectional structural relation is when we model the
sentence from Sect. 6.1 of (Klyne et al. 2004)
The predicate is also known as the property of the triple.
This is expressed in the OPD of Fig. 17.9, where Property is linked to Predicate with a null tag
bidirectional structural link to indicate that they are equivalent, assuming that the null tag default is
“equivalent”. This translates to the OPL sentence “RDF Triple and RDF Statement are equivalent.”
232 Aggregation-Participation
Fig. 17.9 An OPM model demonstrating a bidirectional tagged structural link with one tag
Fig. 17.10 The non-comprehensive aggregation symbol is a short vertical line below the aggregation triangle expressing
that not all the parts are shown
Fig. 17.11 Application of non-comprehensive aggregation in the Resource Description Framework Statement
Fig. 17.13 The non-comprehensivemness symbol demonstrated for aggregation and characterization. Left: Original
Process Test model. Right: Updated model after removing Verb Association Criterion
Being a fork property, the non-comprehensiveness symbol can be used not only for aggregation, but
also for each of the other three fundamental structural relations—exhibition, specialization, and
classification. To correctly use the non-comprehensive symbol, an OPM modeling tool must keep track of
the set of refinees for each refineable and adjust the symbol and corresponding OPL sentences as the
modeler changes the collection of refinees. This is demonstrated in Fig. 17.13, where we reuse the OPM
Model of the Process Test from Fig. 10.6, this time providing only the two relevant OPL sentence. On the
left is the original model, while on the right the object Verb Association Criterion, which is both a part of
Process Test and an attribute of Noun, has been removed, causing an automatic update of the OPD to
include the non-comprehensive symbol for both the aggregation and the exhibition. The OPL sentences
were updated as well.
As we can see, the OPL phrase for non-comprehensive exhibition-characterization is “and at least one
other feature”. We use feature rather than attribute because, as we discussed in Chap. 16 and will elaborate
in Chap. 18, feature can be an attribute (object) or an operation (process), both of which can be attached
to the base of the same exhibition symbol, . Similarly, the OPL phrase for non-comprehensive
generalization-specialization is “and at least one other specialization”, and the OPL phrase for non-
comprehensive classification-instantiation is “and at least one other instance”.
Dori – Model-Based Systems Engineering with OPM and SysML 235
The OPD in Fig. 17.14 and the OPL that follows it exemplify this. Since an Airplane consists of two
Wings, the participation constraint 2 is recorded next to the object Wing. Airplane also consists of a
certain number of Engines, the exact number of which is determined by a couple of parameters. The
example in Fig. 17.14 uses three parameters, E, B, and W, to express the number of Engines in an
Airplane, the number of Engines attached to the Body, and the number of Engines attached to a Wing,
respectively.
As exemplified in Fig. 17.14, there is a specific syntax of parameterized participation constraints as
they are recorded in an OPD. This syntax defines a small-syntax language, called Parameterized
Participation Constraints (PPC) mini-language. It draws from, and is similar to, the syntax of arithmetics
and set notation in conventional third-generation and OO programming languages, such as C, C++ and
Java. This syntax, specified informally next using this example, must not be confused with the much more
complex syntax of OPL, which is presented formally in EBNF in the OPM ISO 19450 PAS (see Chap.
24). The PPC mini-language must also not be confused with UML’s OCL, which is also designed as an
add-on to UML to specify constraints that cannot be expressed graphically in UML, as Sect. 22.10
discusses briefly.
To demonstrate the PPC mini-language syntax, let us follow the example in Fig. 17.14. The set of four
constraints, each expressed in a line of text in Fig. 17.14 above the object Engine are the E parameter
constraint set—the set of four constraints for E, where E is the parameter for the number of Engines in
the Airplane. The parameter (E in our case) appears first, followed by semicolon, followed by zero or
236 Aggregation-Participation
more (four in our case) constraints separated by semicolons. Each constraint is an equality or inequality,
or a set membership notation. The left hand side is the parameter name, the right hand side is a
mathematical expression, and the two sides are separated by one of the equality or inequality symbols =,
≠ (or != when only the ASCII character set is available), <, >, ≤ (or <=), ≥ (or >=), or by the membership
notations ∈ (or “in”), or ∉ (or “not in”).
As noted, the symbols and syntax used in the constraint expressions are based on common
conventions of programming languages. For example, multiplication is denoted by an asterisk, as in E =
B+2*W. The reserved phrase in is the set-theoretic symbol ϵ, so “b in {0, 1}” is the same as “b ϵ {0, 1}”. In
our example, the first constraint, E >= 1, constrains the number of Engines in the Airplane to be at least
one. The second constraint, E = B+2*W, is the total number of Engines, which is equal to the number of
Engines in the Body (which can be 0 or 1), and W is the number of Engines in each Wing (which can be 0,
1, 2, or 3).
Fig. 17.15 The parameterized participation constraints from Fig. 17.14 expressed differently
As this example shows, the OPL syntax for the parameterized constraints set is such that the main
parameter precedes the name of the object to which it relates, followed by a comma and the reserved
phrase where, followed by a comma-separated list of constraints with the reserved phrase and preceding
the last constraint.
Figure 17.15 presents another way to specify the parameterized participation constraints, which is
different than that in Fig. 17.14, but it uses the same parameterized constraint syntax and has the same
semantics. The PPC mini-language is compared in Sect. 22.10 with Object Constraints Language (OCL)
that augments UML.
17.10 Summary
Aggregation-participation is a fundamental structural relation which denotes the fact that a
refineable—the whole—aggregates one or more refineables—the parts.
Aggregation-participation is a pair of forward and backward structural relations.
Dori – Model-Based Systems Engineering with OPM and SysML 237
The solid black triangle, , is the aggregation-participation relation symbol. It replaces the pair
of forward and backward textual tags of the aggregation-participation relation.
Aggregating is the process of creating a whole from its parts, while participating is enumerating
the parts that comprise the aggregate.
In UML 2 and SysML, there are two types of aggregation in class diagrams: shared—weak
aggregation, marked as a white diamond, and composite—strong aggregation, marked as a black
diamond.
In OPM the distinction between composite and shared aggregation is not necessary, since one
can model exactly what part or parts are consumed when the whole is consumed and what parts
remain.
Orderability is a Boolean property of the aggregation relation, inherited from fork.
To denote that the aggregation is ordered, we add the symbol ordered next to the aggregation
triangle.
Comprehensiveness is another Boolean property of the aggregation relation, inherited from fork.
To denote that the aggregation is non-comprehensive, we add a short horizontal bar below the
aggregation triangle.
The Parameterized Participation Constraints (PPC) mini-language has a small syntax that
determines how to phrase a set of constraints for a parameter in a participation constraint.
17.11 Problems
1. Draw two OPDs of a two-story house and its major parts, one without and one with the
aggregation participation link.
2. Which OPD was easier to draw? Why?
3. Use the second OPD from the first problem to demonstrate the use of orderability in terms of
vertical location of the parts of the house, the highest one being the first. Add parts as needed.
4. Demonstrate non-comprehensiveness by removing one or more parts from the OPD in the
previous question.
5. Add at least two participation constraints to an OPD from one of the previous question.
6. Draw OPDs describing two objects for which the parts are ordered and two for which they are
not.
7. Draw two OPDs for an object consisting of at least eight different parts at the first participation
level, with non-comprehensive aggregation. A subset of the parts should appear in one OPD and
another subset in the other OPD such that the union of the subsets is comprehensive.
8. According to Figs. 17.13 and 17.14 what are the possible numbers of engines in an Airplane?
238 Aggregation-Participation
9. Use parameterized participation constraints to create the aggregation hierarchy of a high rise
building. The building has a certain number of floors, each having two types of apartments,
standard and luxury. In each floor from floor 4 and above there are three standard and two
luxury apartments. In the first three floors, there is one small and two large offices. Decide how
many floors there are and how many faucets are required for each unit, and create the
appropriate OPD with participation constraints. Complete details as you see fit. Using your
OPD, compute the number of faucets the contractor needs to order for a 22 story building.
Chapter 18
Exhibition-Characterization
I must be able to attribute properties to the objects.
Kant (1787)
To define and describe things in the world, natural languages use adjectives and adverbs. Without these
types of words, which describe objects and are also interchangeably called attributes, features, qualities,
characteristics, or properties, neither objects nor processes can be adequately distinguished and
understood. Exhibition-characterization is the fundamental structural relation that binds a refineable
(object or process)—the exhibitor, with a refinee—another object or process, called feature, which
characterizes the exhibitor.
The forward (downward) direction of the exhibition-characterization relation, from the exhibitor to its
features, is the exhibition direction, while the reverse (upward) direction, from each feature to the
exhibitor, is the characterization direction. The above definition assumes the forward direction of the
exhibition-characterization relation. Viewed in the backward direction, the feature is said to characterize
the exhibitor. Figure 18.1 expresses on the left the exhibition-characterization relation as a bidirectional
tagged structural link, yielding two OPL sentences, while on the right, the relation’s designated symbol is
used, resulting in a single OPL sentence with the (non-bold) reserved OPL word exhibits.
Fig. 18.1 The exhibition-characterization relation expressed as a bidirectional tagged structural link (left) and with the
relation’s designated symbol (right)
The word for the backward relation, characterization, is much more commonly used in the context of
the relation than its forward counterpart, exhibition. Characterization is therefore the short name of the
relation. Based on this, we may occasionally drop the “exhibition” part of the name of this fundamental
structural relation and abbreviate it to characterization, bearing in mind that this is the direction up the
hierarchy level.1
they produce there.” Similar observations were made by Newton (in Optica, 1721) about the color of
rays, and by Leibnitz (in Discourse on Metaphysics, 1686) about size, figure and motion.
This distinction was criticized by Berkeley (1710) in his “immaterialism” theory, which denied the
existence of material substance altogether. According to Berkeley, familiar objects, like a table, are only
ideas in the human perceiver’s mind, and cannot exist without being perceived. The ideas created by
sensations are all that people can know for sure. When an object is stripped of all its secondary qualities,
the idea that there is some object has no support, since without qualities one cannot give any content to
the idea of the object existence. Kant (1783) also went against this distinction, claiming that both primary
and secondary, qualities are subjective, as they are located in the brain of a knowing observer. This
discussion complements our previous treatment in Sect. 10.3 of object identity.
The OPL sentence that relates an Exhibitor to three features, Feature 1, Feature 2, and Feature 3, is:
Exhibitor exhibits Feature 1, Feature 2, and Feature 3.
All the features on the list must be of the same perseverance, i.e., all are attributes (object features) or
all are operations (process features). If some of the features are attributes while others are operations, we
divide the features into two lists, one of attributes and the other—of operations. If the exhibitor is an
object, then the first list of features is of (one, two, or more) attributes, and the second—of operations.
The list of attributes is connected to the list of operations by the reserved OPL phrase as well as. As an
example, the following OPL sentence specifies an Object exhibitor with three attributes and two operations:
Object exhibits Attribute 1, Attribute 2, and Attribute 3, as well as Operation 1 and Operation 2.
If the exhibiting thing is Process, the list of operations precedes the list of attributes:
Process exhibits Operation 1 and Operation 2, as well as Attribute 1, Attribute 2, and Attribute 3.
242 Exhibition-Characterization
Procedure, Routine,
transient (dynamic) Process Operation Method, Service
Subroutine, Function,
OPM treats features as things that have their own right of existence, regardless of the fact they may
also characterize higher-level things. While aggregation-participation and generalization-specialization
are recognized relations in SysML (as in UML) and have their own symbols (black or white diamond for
the former, white triangle for the latter), exhibition-characterization is not an explicit relation and does not
have a symbol. Rather, an attribute is recognized as such in UML by its location in the second of the three
vertically-arranged compartments that comprise the UML object class symbol. In SysML there can be an
arbitrary number of compartments in a block, so each compartment must be labeled. For example, in Fig.
18.2, the label is “values”.
Paradoxically, although OPM does not attempt to be “purely” object-oriented, it is more object-
oriented in its treatment of characterization than the OO paradigm. In OO, attributes and methods are
encapsulated, or embedded, within objects. Are attributes not objects, but rather “different animals” that
reside within the object? If an attribute is not an object, then what is it? Does the world consist not only of
objects but also of attributes (and methods)? OPM does not encounter this dilemma, since it defines
feature generically as a thing that describes a thing and as one that specializes into an attribute—an
object—and an operation—a process.
To demonstrate the problem caused by not treating attributes as objects, consider a “classical”
example of Name and Address as attributes of the object class Person, and Moving as an operation of
2
Person. As Fig. 18.2 shows on the left, in SysML this is done by assigning a title to each compartment.
The top compartment has the «Block» stereotype title, which is analogous to Object in UML and OPM,
with the name of the block, Person, underneath it. Below this top compartment are the “values”
(attributes) compartment, with Name and Address as the values, and at the bottom is the operations
2
We assume here that Person is capable of Moving without the need for external objects, such that Moving can be
considered an operation of Person.
Dori – Model-Based Systems Engineering with OPM and SysML 243
compartment, with Moving as the listed operation. In UML and many of its predecessors, such as Object
Modeling Technique, OMT (Rumbaugh et al. 1991) the attributes and operations are listed always in the
second and third class box compartments, respectively, so no titles are needed.
On the right hand side, Fig. 18.5 shows the corresponding OPM notation: Name and Address are
separate objects, and Moving is a process. Since Name and Address are linked to Person with the
exhibition-characterization symbol, they are also attributes of Person. For the same reason, Moving is an
operation of Person. A side benefit of this notation is that we can connect Moving to Address with an
effect link to denote the fact that Moving has an effect on the Address of Person, already combining
structure and behavior in this simple OPD.
Fig. 18.2 Expressing attributes (values) and operations in SysML (left) and in OPM (right)
Outside the context of Person, both Name and Address are bona fide objects in their own right.
Moreover, as shown in Fig. 18.3, each one of them consists of parts: Name consists of First Name
followed by Last Name; Address consists of Street, City, Zip Code, State and Country, in that sequence.
Fig. 18.3 Expressing parts of attributes in SysML (left) and in OPM (right)
An operation of an object is a process that is internal to the object: it can be performed by the object or
its part(s) and affects only objects that are parts, features, or specializations of that object. In other words,
an operation of an object B1 has no side effect on, nor does it require any object that is outside of B1.
Under this condition, the operation can be identified as being “owned” by B1. The OO approach, and
consequently UML and SysML, view all processes as operations that are encapsulated within and owned
by objects. This encapsulation is a major source of confusion and an impediment to faithful system
modeling. In OPM, encapsulation is valid only when the process is internal to the object. In cases like
this, the process is defined as an operation of the encapsulating object.
A few examples of pairs of an object and its operation are Airplane—Flight, Person—Walking,
Printer—Printing, Officer—Commanding, and Dog—Watching. Figure 18.6 presents four OPM models
that correspond to these pairs. As these examples show, an operation is a specialization of a process. As
such, a name given to an operation should be a gerund, i.e., a verb form ending with the “ing” suffix.
Many objects, in particular physical and artificial ones, exhibit a major operation that expresses the
main function that the object is designed to perform; the service it is expected to provide. Such objects are
systems. A system (which is artificial) provides value to the system’s beneficiary. For example, the
function that the object Printer supplies is Printing, the function of Airplane is Flying, the function of
Crane is Lifting, and the function of Dryer is Drying. This is in line with our definition of an artificial
system as an object that carries out a function.
describing a process—is not explicitly defined in the OO approach. Here we refer to an object B1—the
attribute—that characterizes a higher level process P1. Conversely, we say that the process P1 exhibits the
attribute B1. Few examples of pairs of a process and its attribute are Diving—Depth, Commanding—
Language, Printing—Quality, Striking—Duration, Manufacturing—Quantity, Watching—Effectiveness,
Singing—Volume, Skiing—Location, and Flying—Speed.
Figure 18.7 presents OPM models that correspond to the first four process-attribute pairs. Each of
these process-attribute pairs can be embedded in a natural language sentence. Here are possible examples,
where the processes are bold and their attributes are italicized:
(1) Diving at a depth of 30 meters or more requires the diver to make decompression stops.
(2) The language the office was using for commanding was foreign and strange.
(3) The printing of this device is of poor quality.
(4) The employees have been striking for duration of over two weeks.
While all the processes in these examples are nouns having the gerund form, they can be easily
converted into sentences where the processes are verbs, with the same semantics as before:
(1) A diver who dives at a depth of 30 meters or more is required to make decompression stops.
(2) The officer commands in a foreign language.
(3) This device prints with poor quality.
(4) The employees strike, and this has been lasting for a duration of over two weeks.
As these examples show, this OPM extension of the OO, UML and SysML attribute and operation
concepts is a direct consequence of recognizing processes as bona fide independent kind of things
besides, rather than being necessarily subordinates of objects, or second-class citizens that are owned
objects.
object changes the object that exhibits (“owns” in OO terms) that operation. Likewise, an operation of a
process changes the exhibiting process—the process that exhibits that operation.
In daily life we do not think so much about operations of processes. The best way to understand the
meaning of an operation of a process is to look at time. A change of an object along the timeline means
that the state of an object (or its value, in case that object is an attribute) inspected at time t is different
from its state at a later time t + t. Extending this idea from objects to processes, if we sample a process
at two different points in time, we may notice a change in that process, manifested as a difference in the
value of one of the attributes of that process, which is caused by an operation of that process.
Figure 18.8 contains four partial OPM models, each showing a process and its operation. In the model
on the left, Accelerating is an operation that changes the value of the attribute Velocity of the Moving
process. Similarly, the operation Stabilizing of the Fluctuating process changes the value of the Amplitude
attribute of Fluctuating. Next, Delaying is an operation of Transmitting that changes its Duration attribute.
Finally, Interfering is an operation of the Communicating process, which changes the value of the Signal-
to-Noise Ratio attribute of the Communicating process.
In mathematical terms, a change of an object along the timeline is a first derivative of some quantity
(which is an attribute value of that object) with respect to time. In an analogous manner, since a process is
a pattern of transformation (responsible for transforming an object), an operation of a process is a
transformation of a transformation, or a change of a change. In mathematical terms, this is a second
derivative (derivative of the derivative) of some quantity with respect to time. Indeed, the examples of
pairs of a process and its operation shown in Fig. 18.8 have the notion of changing a process and can be
quantified mathematically using second order derivatives. For example, in the OPM model on the left of
Fig. 18.8, if we denote the attribute Velocity of the process Moving of an object as a function of time by
v(t), then we know that v(t) is the first derivative of the attribute Position s of the object as a function of
time: v(t) = s′(t). Denoting by a(t) the attribute Acceleration of the Accelerating process, we have a(t) =
v′(t) = s″(t), where a(t) is the first derivative of Velocity and the second derivative of Position.
aggregation-participation are fork relations, structural hierarchies of these relations (as well as
generalization-specialization, discussed in a couple of chapters) can be formed.
Consider the object City, whose feature hierarchy is depicted in Fig. 18.9. Three important attributes
of City, in addition to its Name, are Location, Population, and Climate. Besides being attributes of City,
Location, Population and Climate are objects in their own right, so each may have its own set of features
or parts. Location has the attributes of the Continent, Country, Region, and Coordinate Set. Population
exhibits the attributes Size and Demographics and the operations Aging and Earning. Demographics, in
turn, consists of Average Age and Average Income. Aging and Earning are two operations that
respectively affect the two parts of Demographics, and Precipitating is an operation of Climate that
affects Average Precipitation.
may be the adjectives round, square, elliptic, etc. There is no bias in Shape toward any of its values.
Conversely, Length is biased towards the long extreme of the short—long value spectrum. Picking up
Shortness instead would tilt the bias to the other extreme. Hence, a sentence such as “The shape of the
house is square.” makes perfect sense, whereas “The length of the stick is long,” while syntactically
correct, is semantically awkward. Skipping the name of the attribute, we would rather say “The stick is
long.” In this case, the attribute Length is implicit in the sentence. We could also skip the attribute name
of the attribute Shape in the sentence “The shape of the house is square.” and say “The house is square.”
We call such an attribute implicit. Implicit attribute sentences are usually used when the attribute name is
taken from one of its extreme values. Examples are Length, taken form the pair long–short, Beauty, taken
from the pair beautiful–ugly, and Width, taken from the pair wide–narrow. Interestingly, the choice of
which of the extremes is chosen as the name of the attribute tends to favor the one that is considered
better or larger. Thus, it is much less natural to respectively name these attributes Shortness, Ugliness,
and Narrowness, although these words are legal nouns.
The use of implicit attribute sentences in natural language is the rule rather than the exception.
Skipping the name of the attribute to which the value belongs and make direct reference to the object that
exhibits the value is most prevalent. Implicit attributes are so widespread, that in many cases the natural
language does not have a dedicated noun for the attribute itself, while the adjectives, which are the values
or states of that attribute, do have widely recognized and used names.
As an example, consider the implicit attribute sentence “This book is interesting.” The adjective
interesting refers to an attribute of this book, whose possible values may be “interesting” and “boring.”
There is no single noun for an attribute whose values are interesting and boring. Plausible names of this
attribute may be either Interest Level or Boredom Level. However, each is biased toward one of the
extremes of the spectrum or the other. Ideally, we would like a word that is neutral and not biased toward
any one of the possible attribute values.
In other cases, it is obvious that the name of the attribute was invented after the value was already in
use. For example, Laziness is a name of an attribute which has lazy as one of its values (and energetic or
industrious or hardworking as another), and the suffix “ness” hints to its later introduction into the
language. Obviously, if we attach to a Person an attribute called Laziness, we would expect the value of
this attribute to be lazy rather than hardworking. More simply and more naturally, we would like to say
that “Person is lazy.” This sentence is much shorter, clearer, and straightforward compared with the two
OPL sentences “Person exhibits Laziness.” and “Laziness of Person is lazy.” Indeed, as discussed Sect.
18.8 OPM has the option of implicit attribute, where lazy and hardworking are directly modeled as states
of Person rather than values of its Laziness attribute, which, in this case, becomes redundant.
However, in the general case, in OPM, where modeling is formal, we often have to explicitly model
the attribute before we can model its states or values, and if there is no word for the attribute, we have to
invent it. Indeed, in OPM there is the problem of finding adequate names for properties (metamodel
attributes) of Thing. The name of the property of Thing whose values are natural and artificial is Origin.
We have also called Essence the property of Thing whose values are physical and informatical.
Perseverance has been chosen as the name for the property whose values are persistent (in which case
the thing is an object) and transient (in which case the thing is a process). The choice of these property
names points to the difficulty in finding the right word to name an attribute (or property) whose values are
prevalent. For example, transient and persistent, which are the values of the property Perseverance, are
Dori – Model-Based Systems Engineering with OPM and SysML 251
widely used, while Perseverance is not recognized in conjunction with these adjectives. Origin and
Essence are neutral. Perseverance is less neutral; the American Heritage Dictionary (1996) defines
perseverance as “steady persistence in adhering to a course of action, a belief, or a purpose;
steadfastness.” Steady persistence inclines toward the notion of Object, since its Perseverance value is
indeed persistent. However, course of action has the notion of a process…
18.8.1 Explicitness
OPM caters to the natural language tendency to skip attributes and jump directly to their values, as Sect.
18.7 discusses, by providing the option to model attributes implicitly, as Fig. 18.10 demonstrates.
An attribute is implicit if its values are assigned as states directly to the exhibitor with
no specification of the attribute name.
Explicitness is an attribute of an attribute whose values are explicit (the default) and
implicit.
It is easy to identify an implicit attribute: If an object has states that are placed directly inside its
rectangle rather than in its attribute, then the attribute whose values are within the object is implicit. By
default, an attribute is explicit—its Explicitness value is explicit. It often makes sense to use an implicit
attribute, as this circumvents the attribute naming problem discussed in the previous section—the need to
invent a name for the attribute. We saw the example of Laziness in the previous section. As another
252 Exhibition-Characterization
example, Lamp can be on or off. It would be cumbersome to define a dedicated explicit attribute for these
states and difficult to find a good name for it: “Onness”? “Offness”? “Operational Status”? None of these
makes sense.
It is not possible to have more than one implicit attribute for the same thing, because this would mix
values of different attributes in the same sentence without affiliating them with the proper “owning”
attributes. For example, examining Fig. 18.10, we observe that sentences such as “Stick can be light,
heavy, short, or long” do not make sense, because values of the Weight and Length of Stick are mixed.
We can have either Weight or Length as implicit attributes, but not both. In the OPM model on the left of
Fig. 18.10, both Weight and Length are explicit attributes of Stick. In the middle, Length is an explicit
attribute, with values long and short, while Weight is implicit, with states light and heavy. Finally, in the
OPM model on the right, the opposite is true: Weight is an explicit attribute, with values light and heavy,
while Length is implicit.
18.8.2 Mode
Some attributes are qualitative while others are quantitative. We have seen the example of the attribute
Shape of House, where possible values can be round, square, and rectangular. These values cannot be
quantified by a numeric value. They are just qualitatively different from each other. We say therefore that
Shape is a qualitative attribute. Other examples of qualitative attributes include Mood, with states happy,
sad, angry, etc., Health, with states healthy and sick, and Marital Status, with states single, married,
divorced, etc. Examples of quantitative attributes are Weight [Kg] and Height [m]. As these examples show,
quantitative attributes need to be followed by the unit of measurement in brackets, as discussed in Chap.
22. Since an attribute can be qualitative or quantitative, qualitative and quantitative are values of a
property of Attribute called Mode.
A quantitative attribute is hard if its value cannot be deduced or computed from other
attributes.
A quantitative attribute is soft if its value can be deduced or computed from other
attributes.
18.8.4 Emergence
Depending on whether a feature is exhibited only by the object as a whole or only by one or more (but not
all) of its parts, a Feature (an Attribute or an Operation) can be inherent or emergent.
A feature of an object is inherent if a least one of the object’s parts exhibits it.
A feature of an object is emergent if no one of the object’s parts alone exhibits it.
Emergence is a property of an object whose values are inherent (the default) and
emergent.
To understand the difference between emergent and inherent features, consider Airplane’s attribute
Weight and its operation Flying. Weight of Airplane is the sum of the individual Weight values of each one
of the parts that make up the Airplane. Flying, on the other hand, was not an operation that any part of
Airplane could exhibit on its own. Rather, this feature emerges from the unique ensemble of the parts of
Airplane that endows Airplane with the ability to carry out the Flying operation. Hence, Flying is an
emergent feature (operation in this case) of Airplane, while Weight is an inherent feature (attribute in this
case) of the Airplane.
In systems, operations are frequently emergent, because systems are built with the intent of achieving
some function that is not localized in or achievable by any part of the system alone. Flying of Airplane is
an excellent example. Bar-Yam (1997) distinguishes between simple and complex systems and claims
254 Exhibition-Characterization
that complexity can emerge from a collection of simple parts that comprise a system. The converse can be
true as well: a system composed of complex parts may exhibit simple behavior at a larger scale. For
example, planet Earth is a highly complex system, but when viewed from the perspective of its movement
around the sun, it is relatively simple, pointing to the relativity of the term complexity.
A link is homogeneous if it connects two things that exhibit the same perseverance
value.
Homogeneity is a property of a link whose values are homogeneous (the default for
structural links) and non-homogeneous (the default for procedural links).
Almost all the structural links are only homogeneous: they either connect two objects or two
processes. The only exceptional structural link that is Exhibition-Characterization, which can be both
homogeneous (in case it connects an object with an attribute or a process with an operation) or non-
homogeneous (in case it connects an object with an operation or a process with an attribute). All the
other structural links, and in particular the remaining three fundamental structural relations, are
homogeneous. Analogously, almost all the procedural links are non-homogeneous, as they connect an
object to a process. The only procedural links that are homogeneous are the invocation link discussed in
Sect. 10.10.3 and the overtime and undertime exception links discussed in Chap. 22.
18.9 Summary
Exhibition-characterization is a relation between a thing and the features that characterize it.
The shorthand name of this relation is characterization and its symbol is .
Characterization is the only fundamental structural relation for which all four combinations of an
object and a process, as an exhibitor and a feature, are possible.
A feature which is an object, is called an attribute, while a feature which is a process is an
operation.
Dori – Model-Based Systems Engineering with OPM and SysML 255
An attribute is implicit if its values are assigned directly to the exhibitor with no specification of
the attribute name.
An attribute is explicit if it is a separate object that is linked to the exhibitor with an exhibition-
characterization relation.
Explicitness is an attribute of an attribute whose values are explicit (the default) and implicit.
An attribute is qualitative if its values are non-numerical.
An attribute is quantitative if its values are numerical.
An operation is quantitative if it transforms a quantitative attribute, otherwise it is quantitative.
Mode is a property of a feature that determines whether it is qualitative (the default) or
quantitative.
A quantitative attribute is hard if its value cannot be deduced or computed from other attributes.
A quantitative attribute is soft if its value can be deduced or computed from other attributes.
Touch is an attribute of a quantitative attribute which determines whether it is hard (the default)
or soft.
A feature of an object is inherent if a least one of the object’s parts exhibits it.
A feature of an object is emergent if no one of the object’s parts alone exhibits it.
Emergence is a property of an object whose values are inherent (the default) and emergent.
A link is homogeneous if it connects two things that exhibit the same perseverance value.
A link is non-homogeneous if it connects two things that exhibit opposite perseverance values.
Homogeneity is a property of a link whose values are homogeneous (the default for structural
links) and non-homogeneous (the default for procedural links).
18.10 Problems
1. For each one of the four exhibitor-feature combinations, draw an OPD that is not provided as an
example in this chapter.
2. “The quick brown fox jumps over the lazy dog” is an English-language sentence called
pangram—a phrase that contains all of the letters of the alphabet. Create an OPM model of this
sentence in which Jumping is an operation of Fox.
3. In the model you created in the previous question change each explicit attribute to an implicit
one and vice versa.
4. Provide two examples of inherent features and two of emergent features.
5. Create an OPM model of the structure—parts and features—of the Pazyryk burial mounds
chariot in the Hermitage Museum in St. Petersburg according to the following description
(image available in URL).
This large four-wheel chariot is one of the striking finds of the Pazyryk burial mounds. It consists of a number of
parts joined together by leather straps and wooden nails. The trunk is made of two frames joined by means of short
carved poles and leather straps. The frames constitute the basis for the canopy. Each of the four large wheels has 34
256 Exhibition-Characterization
spokes. The axles do not have a rotary device, and the distance between the back and front wheels is only 5 cm, which
meant that the chariot could only be used on flat ground. It could, however, be easily disassembled and transported
on horses. Thanks to the permafrost, the chariot is in an excellent state of preservation.
Chapter 19
States and Values
The Caterpillar … got down off the mushroom and crawled away into the grass
merely remarking as it went, “One side will make you grow taller, and the other side
will make you grow shorter.”
Alice in Wonderland. Lewis Carroll, 1899
To be able to talk explicitly about a change in an object over time, we assign to it a number of possible,
“legal” states. Hence, a state is a situation an object can be at. States and values add expressiveness to
OPM. A value is a state of an attribute. As such, it is a specialization of state: Whereas objects can have
states, only states of attributes, which are objects that describe other object, are called values. States and
values enable modeling change in an object while that object retains its identity. We have been using the
terms states and values quite intuitively since the early chapters of this book. If objects and processes are
the building blocks of OPM, and links are the mortar, states can be considered as the finish of the house:
the paint job, the furniture, and architectural elements. At any time in the life of the object, when no
process is acting on it, that object is at one of its states. Cause and effect are tightly linked with the
concepts of change of state over time. This chapter formalizes the concepts of states and values, and
shows how they can be used to enhance model expressiveness.
A State is a situation or position at which an object can exist for some period of time
during its existence.
The initial state of an object B is the state at which B is upon its generation or as the
system starts executing.
The final state of an object B is the state at which B is upon its consumption or as the
system finishes executing.
The default state of an object B is the state at which B is expected to be when its state
is not specified.
Fig. 19.1 Initial, final, and default states demonstrated in the lifecycle of a Frog with simulation. The initial state is spawn
(bold frame) and adult is both the final state (double frame) and the default state (the open arrow pointing at adult). The
simulation emphasizes closing the lifecycle
Dori – Model-Based Systems Engineering with OPM and SysML 259
An object can have zero or more initial states, zero or more final states, and at most one default states.
The same state can be any combination of initial, final and/or default. The initial and final states are
especially useful for objects that exhibit a lifecycle pattern, such as a product, a system, or our familiar
frog from Chap. 13. The default state is useful for specifying the state at which an object is when no state
is specified. The symbols for initial, final, and default states are a bold state frame, a double state frame,
and a state frame pointed to by an open arrow, respectively. These are demonstrated in the simulated
lifecycle of Frog in Fig. 19.1: The initial state of Frog is spawn (cell mass), denoted by the bold state
frame. The state adult is both the final state, denoted by the double frame, and the default state—the open
arrow pointing at the adult state frame.
The conceptual simulation in Fig. 19.1 shows the process Mating & Fertilizing (Amplexus)—the
highlighted solid ellipse—operating on Frog to change it from the state adult to the state spawn (cell
mass). The corresponding OPL sentence is:
Mating & Fertilizing (Amplexus) changes Frog from adult to spawn (cell mass).
This state transition emphasizes the cyclical nature of Frog, as the final (and default) state of Frog,
adult, yields Frog in the initial state, spawn (cell mass), through the Mating & Fertilizing (Amplexus)
process.
Object
State Set
?
Default State
* Final State
Fig. 19.3 A metamodel of Object showing the specializations of State: Initial State, Final State, and Default State,
with their participation constraints
In the metamodel in Fig. 19.3, State and its three specialization—Initial State, Default State, and Final
State—are all objects. This metamodel specifies the participation constraints for the three State
specializations. The OPL on the right states that State Set can consist of “optional Initial States” and
“optional Final States”, i.e., zero, one, or more than one initial states and zero, one, or more than one final
states. Indeed, while usually an object has at most one initial state, it can have more than one. For
example, some process can create the object in one initial state while another process can create the same
object in a different initial state. Alternatively, as we show below, the same process can create an object
stochastically at one of two or more initial states. An object may also have more than one final state, from
which it cannot exit. However, State Set can consist of “an optional Default State”, i.e., there may be at
most one default state.
Fig. 19.4 Example of the difference between state and value. Left: off and on are states of the object Lantern. Right: off
and on are values of the attribute Operational Status of the object Lantern
State transition is an unstable period of time for an object, which takes place when a
process acts on it to change its state.
Consider the following car painting example. When a white Car is painted red, its input state (the
value of its Color attribute when it enters the body shop for painting) is white. This is shown in the top left
OPD in Fig. 19.5 by the state white of Color highlighted. The output state of Car (the value of its Color
attribute when it leaves the body shop) is red. This is shown in the bottom right OPD in Fig. 19.5 by the
state red of Color highlighted. In-between these two stable states, Painting takes place. During this time
interval, when the Car is being painted, i.e., throughout the Painting process, which may be a couple of
days, the value of its Color attribute is not completely white any more, but it is not yet red either. Indeed,
while the Car is being painted, it is in transition between two Car states. We say that while undergoing the
Painting process, the Color of Car is unstable. This is shown in the top right and bottom left OPDs in Fig.
19.5, where the highlighting of the red and white states gradually change from red and white. The
262 States and Values
duration of the transition, the time when Car is neither completely red nor white, is equal to the duration
of the painting process.
Fig. 19.5 The Car Painting system in action: The Car starts as white (top left) and ends as red (bottom right). The
diagrams at the bottom of each OPD are the lifespan diagrams
As the car painting example demonstrates, objects and processes in the system have history, which is
accumulated as the system performs its function. The history of an object begins at the time when it is
created and becomes an identifiable entity, and it ends at the time when it is consumed so it is no longer
the same identifiable entity. The history includes a time record of when the object was created, by what
process, the state changes the object went through while it maintained its identity, when the object was
consumed, and by what process.
History is meaningful only with respect to a particular system execution, i.e., the system at the
operational level, or instance level, but not the conceptual level, or class level, because only when a
system executes its function, it is possible to track and record what process instance started and ended
Dori – Model-Based Systems Engineering with OPM and SysML 263
when, and what object instance was transformed, whether it was created or consumed, or whether its state
was changed.
The history of a process includes, for each execution of each process in the system, the time at which
it started and ended. A particular process execution constitutes a process instance. The history also
includes the transformee and enabler instances in the involved object set. A useful tool to view, trace, and
analyze the history of objects and their states, and of processes in a system is the lifespan diagram, which
OPCAT indeed includes.
A lifespan diagram is a diagram which, for any point in time during the life of the
system, shows what objects exists in the system, what state each object is at, and what
processes are active.
The four lifespan diagrams shown at the bottom of each one of the four OPDs in Fig. 19.5 record the
history of the car painting system as time progresses. In the diagram below the OPD in the top-left, only
the first time period is displayed. Painting is not active, and the Car is white. In the second diagram, the
first three time periods are displayed. In the third period, Painting is active, and the Car is no longer white.
The same happens in the fourth period, as shown in the third diagram. Finally, in the fifth period, shown
in the bottom diagram, Painting is no longer active, and the Car is red.
Fig. 19.6 Raw Metal Bar and Part are objects that can be in transition between states
As another example, in the OPD in Fig. 19.6, Cutting takes Raw Metal Bar from its pre-cut to its cut
state. As long as Cutting is active, the state of Raw Metal Bar is in transition and bound to the Cutting
process: Cutting takes it out of its pre-cut state but has not yet brought it to its cut state with process
completion. During Cutting, the state of Raw Metal Bar is unstable and therefore indeterminate: it could
264 States and Values
be partly cut and reusable or mostly cut and unusable. In either case, it is not available for Machining,
since it is not in its cut state. Likewise, during Testing, Part is already not pre-tested, yet it is still not
tested.
If an active affecting process stops prematurely or takes too long, the state of any affectee remains
indeterminate, unless exception handling resolves the object to one of its permissible states. This can be
done using overtime or undertime exception link, discussed in the chapter on OPM operational semantics.
Figure 19.7 demonstrates the problem and the use of path labels on consumption and result links
which solves this problem. If Tomato, Cucumber and Meat all exist, then the result is the generation of
Salad, Stew, and Steak. However, we cannot tell what ingredients went into what dish. And what if we
want to model that for vegetarians we wish to prepare only Salad and for meat eaters only Stew and
Steak?
This is solved by using the path labels carnivore and herbivore, recorded along the procedural links, as
shown in Fig. 19.7 and expressed by the OPL. Path labels uniquely determine which link to follow on
exiting the process: The link to be followed is the one having the same label as the one with which we
entered the process. Using path labels, it is possible to follow a specific scenario in the model that span
multiple consecutive procedural links. As this example demonstrates, path labels remove the logical AND
requirement from the objects in the preprocess object set. Here, only all the objects in the preprocess
object set whose links have the same label must exist in order for the precondition to be met. Thus,
Tomato and Cucumber alone, or Meat alone, meet the precondition for Food Preparing, and the outcome
is dictated by the path label.
A path label is a label on a procedural link which specifies that the link to be followed
is the one with the same label as the one with which the process was entered.
Dori – Model-Based Systems Engineering with OPM and SysML 265
Path labels remove the ambiguity arising from multiple outgoing procedural links, and they can also
be used for state-specified links. For example, in Fig. 19.8 there are two output links: one from Heating to
the state liquid of Water and the other to state gas. Entering this process from state ice, it is not clear
whether the flow of control should go to state liquid or to state gas, unless we use path labels. An
alternative would be to have two separate processes, one called “Ice-to-Liquid Heating” and the other—
“Liquid-to-Gas Heating”. A similar solution can be applied to Fig. 19.7. Without path labels, every pair of
incoming and outgoing procedural links must have its own process.
Path labels provide a memory mechanism, which is required for state machines, where the next state
transition depends on the state of the system and on the previous move. When the process precondition
involves an object or state connected via a path-labeled procedural link, and the postprocess object set has
more than one possibility for destination object or state, the appropriate postprocess object set destination
shall be the one obtained following the link with the same path label as the link connecting one or more
objects and/or states from the preprocess object set.
From a metamodel perspective, Path Label is an (optional) property of Procedural Link. The memory
mechanism dictates that if the scenario unfolded through a path with some path label, then it must
proceed to the next step following the direction marked with same path label.
Fig. 19.9 presents an animated simulation of a simple Push Button, which when pushed shuts off a
lamp that is turned on and turns it on if it is shut off. The Push Button “remembers” its state, so whenever
it is pushed, it switches states. We can use the same idea to model a “flip-flop”, a two-state device which
offer basic memory for sequential logic operations and used for digital data storage of binary numerical
data. This OPM model mechanism can also be used to achieve the “NOT” logical operator, as discussed
in Sect. 23.2.
266 States and Values
Fig. 19.9 A simple Push Button with memory based on the flip-flop mechanism
Fig. 19.10 Top-level OPD (SD) of the Brain Self-Organized Criticality System
Dori – Model-Based Systems Engineering with OPM and SysML 267
Figure 19.10 is SD, the top-level OPD of the Brain Self-Organized Criticality System. It demonstrates
a feedback loop: A noisy or strongly illuminated Brain Activity Environment invokes Sleep Depriving.
Moving on to Fig. 19.11, SD1, where Brain Self-Organized Criticality Maintaining is in-zoomed, we see
an animated simulation of the system model. What has happened until this frozen moment in the
simulation is that Brain Self-Organization Level, initially at state critical, changed to too chaotic, and the
process Brain Self-Organized Criticality Maintaining was initiated, starting with the first subprocess —
Order Level Monitoring. Since (following path chaotic) the observation is that the Brain Self-Organization
Level is too chaotic, the value of Observed Brain Organization Level changes to too chaotic. Note that
Brain Self-Organization Level is an attribute of the process Brain Self-Organized Criticality Maintaining
since it is an object within the scope of that process that needs to be maintained within a nominal value
range or within a certain tolerance.
For example, the Human Body needs to maintain a temperature within a narrow range of 36.4-37.0
degrees Celsius. Similarly, an air conditioning system needs to maintain the Room Air temperature of 69-
268 States and Values
72 degree Fahrenheit. The Temperature Maintaining process starts with the subprocess Temperature
Monitoring, which can be too low, within range, or too high. If the Observed Temperature it is too low,
Heating occurs (in a Human Body this can be done by Body Fat Burning; in an Air Conditioning System—
by Furnace Igniting), changing the Temperature Level of the Human Body or the Room Air from too low
to within range. If the Observed Temperature is within range, no corrective action is needed, so no
subprocess occurs, and if the Observed Temperature it is too high, Cooling occurs (by Perspiring or
Condensing), again restoring the value of the Temperature Level attribute to within range. As some time
passes by, the Environment, being hot or cold, tends to shift the Temperature value from it desired range
to too high or too low, respectively, and a new cycle of Temperature Marinating occurs.
The similarity between maintaining temperature in a biological system and in an artificial one
demonstrates that complex systems, be they biological or man-made, are subject to the same underlying
feedback principle of taking a corrective action when necessary to maintain a desired attribute value.
What is common to both is the “cyber-physical” control mechanism that involves both physical and
informatical (“cybernetic ”) objects and processes: While Temperature is a physical attribute, the
Temperature Monitoring process uses physical means (Thermometer or Skin Nerve Cells) to generate an
informatical object—the value of Observed Temperature. This value is transmitted to the control
mechanism—the “ brain” of the system—by a passing through a communication channel. This can be an
electronic signal via a wire in the air conditioning system or an electric signal from the skin to the brain in
the human body. Using the signal value, the control mechanism then determines what physical action
(Heating or Cooling) has to be taken, closing the feedback loop.
All cyber-physical systems have in common this interplay between informatical objects that signify
the state of the world, as sensed by the system, and systemic physical processes to counter the adverse
effect of the environment on the desired value of the attribute to be maintained. Indeed, as the OPM
model shows, the object Observed Brain Organizational Level Fig. 19.11 (which is analogous to the
informatical object Observed Temperature) is informatical—it is without shadow. Although the
implementations in living and inanimate objects are different, the underlying cyber-physical mechanism
is highly similar, if not identical.
with the three objects Payer, Payee, and Bank. This is denoted in the OPD by the three corresponding
links from the state to the associated object.
Table 19.1 State-specified structural relations and links summary
Fig. 19.12 Associating states with objects via the state-object association link exemplified: Oven is both an object in the
system and a state of Product
270 States and Values
Fig. 19.13 Associating attribute values with objects via state-specified structural link
As an example of a source-and-destination state-specified link, in Fig. 19.14, each one of the three
Phase values of Water is associated with its corresponding Temperature value range via three source-and-
destination state-specified tagged structural links whose tag is “exists for the range of”.
The state space of an object is the Cartesian product of the sets of states of all the
attributes and parts of the object.
Moving on to a more complex example, Airport in Fig. 19.16 exhibits four attributes with two states
each: Weather Conditions, Tower Services, and Radar Coverage, as well as Pilot Familiarity with three
states. The Cartesian product of the sets of states of each attribute enumerates the object’s state space. For
our Airport example, this Cartesian product is Weather Tower Service Radar Coverage Pilot
Familiarity = {fair, hazardous} {available, unavailable} {nonexistent, existent} {poor, fair,
excellent} Thus, there are 2223 = 24 states of Airport.
In general, if an object has n attributes (including an implicit one, if it exists) and stateful parts, each
having vi values, then the size of the state space is:
n
S vi
i 1
272 States and Values
In this context, each attribute can also be referred to as a dimension, analogous to the way that vectors
can serve as dimensions (e.g., the three orthogonal vectors called X, Y, and Z that span a 3-dimensional
Cartesian point space). For example, one of the 24 states of Airport, obtained by listing the first state in
each of the four attributes of Airport above, is:
(Weather = fair, Tower Service = available, Radar Coverage = strong, Pilot Familiarity = poor).
Each such point can be the precondition for some process. Figure 19.16 shows the preconditions for
two alternative subprocesses of Landing Decision Making that Air Traffic Controller makes: Landing
Permission Granting and Landing Permission Denying. The preconditions for these two processes are
expressed in the OPL sentences.
Fig. 19.16 Examples of compound states (points in the state space) of Airport required for Landing Permission Granting
and Landing Permission Denying
This example includes the use of condition links, discussed in the chapter on OPM operational
semantics, and of OR and XOR (X-OR) logical operators, which are discussed in another separate
chapter, dedicated to these operations.
Fig. 19.17 Determining the compound states dark and lit of Table Lamp with processes
Some of the points in the object’s state space are not feasible, for example: (Table Lamp = dark, Switch
= on, Power Chord = plugged in, Light Bulb = intact).
The processes determine what points in the object state
space are feasible. For two dimensions, this can be also presented in a table, possibly as a two-
dimensional array inside an in-zoomed object. However, a table does not express the reasoning behind the
feasibility or infeasibility of each point.
274 States and Values
19.9 Summary
A State is a situation or position at which an object can exist, or a value an attribute can assume,
for some period of time during its existence.
An initial state of an object B is a state at which B is upon its generation or as the system starts
executing.
A final state of an object B is a state from which B cannot exit.
A default state of an object B is the state which B is expected to be when its state is not
specified.
Value is a state of an attribute, therefore it is a specialization of state.
In addition to being at some state, an object can also be unstable, when it is in transition between
two states—the input state and the output state.
State transition is an unstable period of time for an object, which takes place when a process
acts on it to change its state.
A lifespan diagram is a diagram which, for any point in time during the life of the system,
shows what objects exists in the system, what state each object is at, and what processes are
active.
A state-specified tagged structural link is a tagged structural link that connects a state of an
object to another object or to a state of another object.
An atomic state is a state that is not combined of other states.
A compound state is a state that combines at least two other states.
The state space of an object is the Cartesian product of the sets of states of all the attributes and
parts of the object
19.10 Problems
1. A car can be driven if it has fuel, the battery is charged, and the car keys are found. Draw an
OPD with attributes and states that specify these conditions.
2. Enumerate the state space of the car in the previous question: (1) as a list, (2) in a table.
3. Draw OPDs and write the OPL sentences of three objects having initial and final states.
4. Draw OPDs and write the OPL sentences of three objects having a default state.
5. The Car-Driver Complex requires not only the states of car enumerated in problem 1, but also a
sober, awake, and licensed driver.
6. Incorporate these requirements in an OPD of the Car-Driver Complex.
7. Write the OPL paragraph of this OPD.
8. Suggest an alternative way to display the OPD of (a).
Dori – Model-Based Systems Engineering with OPM and SysML 275
9. An ordered set of values of Size of some object can be Miniature, Tiny, Small, Medium, Big,
Large, Extra Large, Great, Giant, and Colossal. Alternatively, one can have a range of numbers
of some specified measurement unit (e.g., meters for length or kilograms for mass) that indicate
a more accurate and “objective” specification of the same Size attribute. Pick up an object with
two sets of attributes, one qualitative and the other quantitative. Use the textual values of Size
above and map them in an OPD to numeric ranges of your choice.
Chapter 20
Generalization and Instantiation
As this term is most commonly used, a generalization is an “all” statement, to the
effect that all objects of a certain general kind possess a certain property.
Lowe (1983)
While discussing aggregation and exhibition, we talked about entire groups of objects or processes—any
scientific paper, any employee, any running. However, what if we wanted to consider the example of a
specific paper, written by a certain John Doe? Or if we wanted to consider a group of employees, namely
managers, who receive a certain salary out of the range of salaries available for the company? Perhaps we
would like to discuss running in a marathon, as opposed to just any kind of running? We need to be able
to pay particular attention to a specialized group, which belongs to a more general group, or even a
specific instance out of a class of objects. As its name clearly points out, generalization-specialization is
the relation between a general and a special case of a thing. Classification-instantiation is the relation
between a class of things and a unique instance from the class. Since these two concepts are important to
systems modeling, we consider them two of the four fundamental relations; and since they are intimately
related, they are discussed and explained together in this chapter.
Person in the left OPD of Fig. 20.1 is the general case, while Man and Woman are its special cases.
Other examples are “Dog and Cat are Pets.”, “Pascal, Java, and C++ are Programming Languages.”,
1
The shorthand term “gen-spec” is borrowed from Coad and Yourdon (1991).
“Airplane and Car are Vehicles.”, “Flying and Sailing are Transporting.”, and “Ketchup and Mustard are
Condiments.”
In order to comply with the English grammar, the process specialization sentence is slightly different
than the (object) specialization sentence in that (1) instead of the reserved phrase “is a,” the reserved word
“is” is used, and (2) while the generalizing object is plural, as in Vegetables, in multiple process
specialization sentence it is singular, as in Cooking. Consider the following OPL sentences.
Fig. 20.3 Left: A general pattern of Cooking. Right: The specializations of Cooking Tool, Cooking, and Food, and the
specialized links between these specializations
Specializations of objects and processes can be combined to specify specialized procedural links
between the object and process specializations. Figure 20.3 shows on the left a pattern of Cooking, which
uses Cooking Tool as an instrument and yields Food. On the right are three specializations of Cooking
Tool, Cooking, and Food. Each Cooking Tool specialization is an instrument of a specialization of
Cooking, yielding a specialization of Food.
280 Generalization and Instantiation
20.2 Inheritance
The most prominent and immediate benefit gained from using the gen-spec relation is the inheritance it
induces.
Connect the new general using the generalization-specialization relation link to the
specializations;
Remove from the specializations all of the common features and common parts that the
specializations now inherit from the new general; and
Migrate any common tagged structural link and any common procedural link that connects a
thing T to each one of the specializations from the specializations to the general, such that there
will be a single link from T to the general.
Fig. 20.4 Left Camera and its Analog Camera and Digital Camera specializations
Since Digital Camera and Analog Camera are specializations of Camera, we can replace Camera with
its Digital Camera and its Analog Camera specializations. This has indeed been done in Fig. 20.5, which
demonstrates the basic semantics of inheritance: the specialization—the refinee— inherits features
(attributes and operations) from the general—the refineable.
Fig. 20.5 Digital Camera and Analog Camera are specializations of Camera, therefore each can substitute Camera from
Fig. 20.4
In OPM not only features are inherited; links and states are inherited as well. The inheritor can
therefore replace the ancestor. Digital Camera and Analog Camera inherit not only the features of Camera,
which are the attribute Optical Zoom and the operation Image Capturing; they also inherit the tagged
282 Generalization and Instantiation
structural relation uses from Camera to Capturing Medium. Moreover, not only structural relations are
inherited; procedural relations are inherited as well. The inheritor, however, may have more features,
links, or states.
Fig. 20.6 The parts, specializations and features of Camera are specified along with the specializations of Capturing
Medium
This implies that the parts Camera consists of are inherited to the two Camera specializations:
Digital Camera consists of Lens, Body, and Image Capturing Mechanism.
Analog Camera consists of Lens, Body, and Image Capturing Mechanism.
Not only aggregation is inherited. Any tagged structural relation, such as uses, is inherited. Since the
tagged relation uses links Camera to Capturing Medium, when we specify the specializations of both
Camera and Capturing Medium without taking care of the structural relation uses, we introduce link
under-specification. This under-specification, encountered earlier, stems from the fact that the structural
relation uses from Camera to Capturing Medium does not specify which Camera specialization (Analog
Camera or Digital Camera) uses which Capturing Medium specialization (Image Storage Medium or Film).
To set this straight, we specify which Camera specialization uses which Capturing Medium
specialization.
Dori – Model-Based Systems Engineering with OPM and SysML 283
Fig. 20.7 State inheritance: Film and Image Storage Medium inherit the states and the input and output links to and
from Image Capturing
Figure 20.10 shows an OPD in which Vehicle exhibits the attribute Travelling Medium with values
ground, air, and water surface. Travelling Medium is the discriminating attribute of Vehicle, because the
three values of Travelling Medium define the three specializations of Vehicle. These are Car, Aircraft, and
Ship, with the corresponding Travelling Medium values ground, air, and water surface.
A general may have more than one discriminating attribute. The maximum number of specializations
with more than one discriminating attribute is the Cartesian product of the number of possible values for
each discriminating attribute, where some combination of attribute values may be invalid. For example,
extending the content of Fig. 20.10, another attribute of Vehicle might be Purpose with the two values
civilian and military. Based on these two values, there are two Vehicle specializations: civilian Vehicle and
military Vehicle. Due to multiple inheritance, the result is an inheritance lattice where the number of the
most detailed specializations would be 3 × 2 = 6 as follows: civilian Car, civilian Aircraft, civilian Ship,
military Car, military Aircraft, and military Ship.
Fig. 20.8 State inheritance induced by the OPD in Fig. 20.9. Left: Camera is substituted by Digital Camera, and
Capturing Medium—by Image Storage Medium. Right: Camera is substituted by Analog Camera, and Capturing
Medium—by Film
Dori – Model-Based Systems Engineering with OPM and SysML 285
Fig. 20.10 The discriminating attribute Travelling Medium and its specializations
20.5 Classification-Instantiation
An instance is an actual thing of some class of things, all having the same set of features, same structure,
and same behavior. For example, Lassie and Blackie in Fig. 20.12 are instances of Dog. Dog is the class
of all the dogs, and Lassie is an actual exemplar of that class. The symbol of instantiation is a black
inverted triangle inside a larger white triangle.
In spoken English, the sentence “Lassie is a dog” is more natural, but the phrase “is a” is reserved for
the specialization sentence, so to avoid conflicts and be explicit, the phrase “is an instance of” links an
instance with its class in an OPL sentence that expresses instantiation. The plural version, used for more
than one instance, is “are instances of,” as in “Bach, Beethoven and Brahms are instances of Composers.”
The definitions of class and instance are more general than their OO counterparts, as they refer to
things rather than to objects. In metamodel terms, since a Thing is an Object or a Process, Class
specializes into an Object Class and a Process Class. Likewise, Instance specializes into an Object
Instance and a Process Instance: An Object Instance is an incarnation of the pattern specified by the
Object Class and a Process Instance is an incarnation of the pattern specified by the Process Class.
Fig. 20.12 The instantiation symbol links a class (Dog) to one or more of its instances
The template that the class defines includes everything that is inherited. As we have seen, in OPM it
means that not only features, but also structural relations and procedural relations are inherited, and for
object classes states are also inherited. Unlike a specialized class, an instance cannot exhibit any feature
that its class does not exhibit, nor can an instance of an object be at a state that is not a state of its class.
An object instance can be uniquely identified in the system, so at any given point in time it is possible to
observe whether it exists, and if so—what its states and attribute values are.
Fig. 20.13 The specialization hierarchy of Car all the way to the instance Jack’s Car and its specific attribute values at
the time of observing it
Consider now a different system of the Motor Vehicles Taxation Office in some country, which, for
taxation purpose differentiates between Taxation Classes of Motor Vehicles as follows: Commercial Van,
Sedan, Collector Car, Sports Utility Vehicle, and Luxury Car. For this system, cars are differentiated into
these types based on their Market Value and Application. Furthermore, the system maintains and
constantly updates a list of each Vehicle Manufacturer and each Vehicle Model by Year Model, with an
indication of which Vehicle Model belongs to which Taxation Class. Here, the Taxation Class is an
attribute of Vehicle. Commercial Van, Sedan, etc., are values of the Taxation Class attribute of Vehicle.
The instances of the class Vehicle in this system are the various Year Models, because the system is only
concerned with setting tax levels on cars by Taxation Class and does not care about individual cars.
Finally, consider a car dealership. Here, of course, each individual car has its own record, including its
VIN, make, model, year, owner, etc. This is the “classical” case of instance, similar to the one presented
in Fig. 20.13, where each instance is a physical entity with its unique identifier. However, as we have
seen, instances can be informatical, such as car models, vehicle types or records in a file.
Fig. 20.14 The attribute values of the calss Person are constrained with value ranges (class on left and instance on
right)
290 Generalization and Instantiation
The OPD in Fig. 20.15 presents the class Metal Powder Mixture, indicating that its Specific Weight
attribute value can range from 7.545 to 7.537 gr/cm3. An operational (runtime) instance of Metal Powder
Mixture is Mixture Lot #7545 with Specific Weight attribute value is 7.555 gr/cm3. This value is within the
allowable range.
Fig. 20.15 Constrsaining attribute value. Left: The class and it attribute value range. Right: the instance and its actual
value, which is in the constrained range
The OPL sentence “Mixture Lot #7545 exhibits Specific Weight in gr/cm3.”, is not present in the OPL of
Fig. 20.15, because that sentence is implicit from the expressed fact “Mixture Lot #7545 is an instance of
Metal Powder Mixture, and therefore Mixture Lot #7545 inherits this attribute from Metal Powder Mixture.
associated; these can be identified only when we are at the instance level, or operational level of the
system.
Fig. 20.16 Movie Showing as an example of a process class (left) and its instace (right)
A process instance is a concrete occurrence of a process class, whose preprocess and postprocess
object sets are sets of object instances. In particular, a process instance has a time stamp, a specific date
and time at which the process started or ended. Figure 20.16 depicts on the left Movie Showing as an
example of a process class, with Movie, and Theatre as instruments of this process class, Date & Time as
its attribute, and Audience as the class’ affectee. In the OPD on the right, Gone With The Wind Premiere
Gala Movie Showing is a process instance of the Movie Showing process class. All the instances are
greyed out to distinguish them from their classes. Gone With The Wind is an instance of Movie, Atlanta
Theatre is an instance of Theatre, Atlanta Audience is an instance of Audience, and Dec. 15 1939 8PM
(Dirks 2015) is the value of Date & Time at which the process instance took place. The same objects
instance can participate in two or more process instances. For example, the same is an instance of Movie,
identified by its name as Gone With The Wind, can participate in all the process instances of Gone With
The Wind Movie Showing (other than the premier gala one), but each Atlanta Audience is a different
instance of Audience, since it is comprised of a different set of movie goers.
292 Generalization and Instantiation
20.9 Summary
Generalization-specialization is the relation between a general thing and a specialization of that
thing.
Classification-instantiation is the relation between a class of things and a unique instance that
belongs that class.
Generalization-specialization gives rise to inheritance from the generalized thing to the
specialized one(s).
Inheritance is of features (attributes and operations), structural relations and procedural relations.
For objects, states are inherited too.
OPM processes specialize in a manner similar to objects.
States of specialized objects can override inherited states.
A class is a template, from which things that instantiate the class can be generated as members of
that class.
Instance is a relative term. A specialization in one system can be an instance in another.
A process instance is a particular occurrence of a process at a given point in time and whose
involved object set is a set of object instances.
20.10 Problems
1. Provide two examples of object specializations and two of process specializations. Specify them
in OPDs and OPL.
2. Create a specialization hierarchy of sports games, which would include as a minimum volleyball,
basketball, soccer, football, tennis, and baseball. Apply OPM to show what features are common
and inherited, and what are game-specific.
3. Repeat the previous problem for a specialization hierarchy of track and field sport types, which
would include at least three types of running, three types of swimming and three types of
throwing.
4. Considering the inheritance of procedural links, are the effect links redundant? Why or why not?
5. Draw the OPD expressed in the OPL paragraph below.
Pilot, Sailor, and Driver are Occupations.
Airplane, Vessel, and Truck are Transportation Systems.
Flying, Sailing, and Driving are Transporting.
6. Complete the OPD from the previous question with the following model facts: (1) Pilot, Sailor,
and Driver handle Flying, Sailing, and Driving, respectively. (2) Flying, Sailing, and Driving
require Airplane, Vessel, and Truck, respectively.
Dori – Model-Based Systems Engineering with OPM and SysML 293
7. Give examples of two systems where instances in the first system are specializations in the
second. Draw the OPD and write the OPL of these systems.
8. The main types of welding are: (1) Gas—Uses gas flame over metals until molten puddle is
formed. Most popular fuels used with oxygen include acetylene and hydrogen. (2) Arc—Two
metals are joined by generating an electric arc between a covered metal electrode and the base
metal. (3) Oxygen and Arc Cutting—Metal cutting in welding is the severing or removal of
metal by a flame or arc. Use OPM to describe these welding types.
9. Specify three instances of electrical appliances at your home. For each one describe its object
class with at least three levels of aggregation-participation hierarchy and the operations it
performs. Use the instantiation symbol to denote your appliance and provide an attribute that
uniquely identifies it.
Chapter 21
Complexity Management:
Refinement and Abstraction
The human mind, after all, can only juggle so many pieces of data at once before
being overwhelmed.
C. Downton (1998)
The very need for systems analysis and design strategies stems from complexity. If systems or problems
were simple enough for humans to be grasped by merely glancing at them, no methodology would have
been required. Due to the need for tackling sizeable, complex problems, a system development
methodology must be equipped with a comprehensive approach, backed by set of reliable and useful
tools, for controlling and managing complexity. OPM provides four refinement-abstraction mechanisms
to manage systems’ inherent complexity: (1) unfolding–folding, (2) in-zooming–out-zooming, (3) state-
expressing–state-suppressing, and (4) view creating. These mechanisms, defined and discussed in this
chapter, make possible the specification of contextualized model segments as separate, yet interconnected
OPDs. Taken together, they provide a complete model of the functional, value providing system. These
mechanisms enable presenting and viewing the modelled system, and the elements it contains, in various
contexts that are interrelated by the common objects, processes and relations. The set of clearly specified
and compatible interconnected Object-Process Diagrams completely specify the entire system to an
appropriate extent of detail and provide a comprehensive representation of that system with a
corresponding textual statement of the model in OPL. This chapter elaborates on complexity management
issues and specifies the various abstracting-refining mechanisms.
Requirements analysis and conceptual design are first steps in the lifecycle of a new system, product
or project. Creating (sometimes unconscious) resistance on the side of the prospective audience—the
various stakeholders—to accept the analysis and design results, because they look too complex and thus
intimidating, may have the adverse effect of jeopardizing the likelihood of success of subsequent phases
of the product development.
The severity and frequency of the detail explosion problem calls for an adequate solution to meet the
needs of the systems modeling and analysis community. A major test of any analysis methodology is
therefore complexity management—the extent to which it provides reasonable tools for managing the
ever-growing complexity of the modeling outcomes in a coherent, clear, and useful manner. Such
complexity management tools are extremely important for organizing the knowledge that the system
architects and designers accumulate and generate during the system architecting and design process.
Equally important is the role of complexity management tools in facilitating the communication of the
analysis and design results to other humans, including customers, beneficiaries, peers, superiors and
system developers down the development cycle road—implementers, testers, operators, etc.
Trying to incorporate the details into one big diagram, the amount of drawn symbols gets very large,
and their interconnections quickly become an entangled web. Because the diagram has become so
cluttered, it is increasingly unwieldy and difficult to comprehend. System architects experience this detail
explosion phenomenon on a daily basis, and anyone who has tried to model a non-toy system of even
modest complexity will sympathize with and endorse this description. This information overload happens
even if the language (such as UML and SysML) advocates using multiple diagram kinds for the various
system aspects. While some of the diagram kinds might be simpler than one kind (as in OPM), combining
them all to obtain a holistic system view is cognitively much more difficult. A system modeling language
must include integral mechanisms for controlling and managing this complexity. This entails being able
to present and view the system at various levels of detail that are consistent with each other.
The determination of when an OPD becomes too complex due to excessive amount of details is left to
the discretion of the modeler, because it cannot be defined by merely fixing a maximal number of model
elements in the OPD. There are other factors, such as regularity, layout, and link crossings that affect
comprehension Nonetheless, a modeling tool such as OPCAT should limit the size of the canvas on which
a single OPD is drawn. This indirectly limits the number of entities and enforces periodic use of in-
zooming and unfolding.
Since this refinement and detail removal can be done recursively and at any required number of times,
we can tackle highly complex systems and still keep the model humanly accessible and comprehensible.
Hence we can make the following OPM model complexity assertion:
The OPM Model Complexity Assertion
Applying refinement mechanisms of in-zooming and unfolding to stateful objects or processes,
OPM can conceptually model systems at any level of complexity.
difficult transition
UML: aspect-based decomposition
structure behavior states
abstract
detailed
Advocating the integration of the various system aspects into a single model, the approach OPM takes
is orthogonal, detail-based decomposition: Rather than applying a separate model for each system aspect,
OPM handles the inherent system complexity by decomposition of the system into a hierarchy of self-
similar diagrams of the same single kind—OPDs—via its abstracting-refining mechanisms. These enable
presenting and viewing the system, and the things that comprise it, at various detail levels. The entire
system is completely specified through its OPD set—a set of compatible OPDs, each providing a partial
view of the system being investigated or developed, which together provide a full picture of the system.
Each OPD is accompanied by its automatically generated OPL paragraph.
Figure 21.1 shows the two orthogonal complexity management strategies. In the aspect-based
decomposition, two thick, solid, vertical lines separate the structure, behavior and state transition aspects
from each other. The thin bidirectional horizontal arrows across these lines symbolize difficult transition
among the various models. The detail-based decomposition is represented by the two thin, dashed,
horizontal lines that separate the various levels of detail—abstract, detailed and concrete, from each other.
The thick bidirectional vertical arrows symbolize easy transition among the detail levels. The diagram is
schematic; it by no means implies that horizontally there are only three levels of abstraction in OPM. In
fact, this number is not bounded. The diagram should also not be interpreted as if vertically there are only
three diagram types in a multi-diagram-type approach.
Fig. 21.2 The parts of Complexity Managing and its effect on the System Model’s Completeness and Clarity
attributes
Fig. 21.3 A stateful object with all states expressed (left) and a suppressed version (right)
The inverse operation of state suppression—state expression—exposes one or more hidden object
states. The modeler may suppress any subset of states. The complete set of states of an object is the union
300 Complexity Management: Refinement and Abstraction
of the set of states of that same object appearing in all of the OPDs in the OPD set—the set of OPDs of
the entire OPM model.
Graphically, the annotation indicating that an object presents a proper subset (i.e., at least one but not
all) of its states, shall be a small state suppression symbol in the object’s right bottom corner. This symbol
appears as a small state with an ellipsis label, which signifies the existence of one or more states that the
view is suppressing, The textual equivalence of the state suppression symbol shall be the OPL reserved
phrase “or at least one other state”.
Fig. 21.4 The OPD from Fig. 21.2 after state suppression of the two attributes and folding of Complexity Management
Folding is the inverse operation of unfolding. It is a collapsing and abstracting mechanism, which can
be applied to a hierarchy of an unfolded refineable. Folding is applied from the bottom of the hierarchy
upward. Each folding operation hides some or all of the refineables. Folding all the refineables leaves just
the refineable—the root of the tree hierarchy.
Since each of the four fundamental structural relation links may undergo unfolding and folding, the
four kinds of unfolding-folding pairs are the following.
aggregation unfolding—exposing the parts of a whole, and participation folding—hiding the parts of
the whole,
Dori – Model-Based Systems Engineering with OPM and SysML 301
In-diagram unfolding is unfolding in which the refineable and its refinees appear
unfolded in the same OPD in which the refinee was originally.
Since unfolding uses one of the four the fundamental structural links, in-diagram unfolding is
graphically, syntactically, and semantically equivalent to using the corresponding fundamental structural
links. While in-diagram unfolding increases the load of the diagram, it saves the need to create a new
diagram, but if there are many refinees, or the current OPD is already busy, we will prefer new-diagram
unfolding.
New-diagram unfolding is unfolding in which the refineable and its refinees appear
unfolded in a new OPD.
Both in- and new-diagram unfolding can be applied to both objects and processes. Graphically, in
new-diagram unfolding, the unfolded refineable is denoted by a thick contour in both the more abstract
OPD in which the refineable appears folded, without refinees, and in the new, more detailed OPD, in
which the refineable appears unfolded and connected to its refinees with one or more fundamental
structural link.
The modeler should make a decision as to whether to use in-diagram or new-diagram unfolding based
on clarity considerations: If the current OPD is already crowded and tends to be cluttered, a new OPD
should be created to prevent the current OPD from becoming unwieldy. If in-diagram unfolding had been
applied and later the OPD became too crowded, the modeler can then switch from in-diagram to new-
diagram unfolding, thereby alleviating the complicatedness of the current OPD (at the price of an
additional OPD in the OPD set). Thus, the modeler decision whether to use in-diagram or new-diagram
unfolding should account for the trade-off between the clutter added to the current OPD and the need to
create a new OPD for displaying the refinees and associated links amongst them.
Partial unfolding may be depicted using the non-comprehensiveness symbol for aggregation,
exhibition, and classification. To satisfy a particular contextual relevance for an OPD, a modeler may
choose which refinees appear unfolded.
While unfolding and folding can be applied to both objects and processes, it is more prevalent for
objects, while processes can be refined via in-zooming, discussed next, or via unfolding. Process
unfolding is useful for functional decomposition which is very important in complex systems. Such
systems have many more auxiliary functions, in addition to the core function, that are concurrent or
302 Complexity Management: Refinement and Abstraction
independent of the core function’s flow. There is usually at least one more function—system setup and
management, a set of many services. Service-oriented systems offer several parallel or concurrent
services that cannot be thought of as working serially. Real-time systems perform several functions in
parallel rather than serially, while each component continuously samples its input from the other
components and acts upon it.
Fig. 21.5 Port folding. Left: the unfolded model. Right: The port-folded version
Based on Mordecai and Dori (2013), a possible solution is port folding, shown in Fig. 21.6. Port
folding is a specialization of folding, an intermediate state between complete folding and complete
unfolding, in which we shift the process refinee—the operation—to the contour of the object refineable—
the exhibitor. Graphically, this looks similar to a SysML activity diagram port on the folded exhibitor.
Port folding is a useful representation if the modeler wants to use the object rectangles to give an idea
about the physical layout and relative sizes of the various system components. The reserved phrase “as
ports” (or “as a port” for singular) at the end of the exhibition sentence indicates port folding. Port folding
can also be applied to attributes of processes.
example, in Fig. 21.6, the process Check-Based Paying from Fig. 19.13 is in-zoomed in the descendant
OPD on the right, showing its four subprocesses, as expressed in the OPL sentence:
Check-Based Paying zooms into Writing & Signing, Delivering & Accepting, Endorsing & Submitting, and
Cashing & Cancelling, in that sequence.
The execution order of these four processes follows the timeline OPM principle, repeated here:
The Timeline OPM Principle
The timeline within an in-zoomed process is directed by default from the top of the in-zoomed
process ellipse to its bottom.
The execution order is expressed in OPL by the reserved phrase in that sequence at the end of the in-
zooming sentence. The exposition of the four subprocesses in the context of the Check-Based Paying
process provides for explicitly specifying how the states of both Check and Keeper change throughout the
lifecycle of check, as also expressed in the OPL sentence to the left of the OPD.
Within the context of the in-zoomed process there may be partial order: overall there is an order
dictated by the timeline, but two or more processes can be performed in parallel. As an example, suppose
a process P zooms into seven subprocesses, SP1, SP2 … SP7, such that SP1 executes first, then SP2 and
SP3 in parallel, then SP4, and finally SP5, SP6, and SP7 in parallel. Then the OPL sentence will be:
P zooms into SP1, parallel SP2 and SP3, SP4, and parallel SP5, SP6, and SP7, in that sequence.
Fig. 21.6 The process Check-Based Paying from Fig. 19.13 is in-zoomed, showing the details of the state changes that
Check and Keeper undergo, as well as the agents involved in each subprocess
304 Complexity Management: Refinement and Abstraction
OPM can be considered process-oriented from the aspect of giving priority to modeling processes first
(initially the system’s function, the process that delivers the external value) and recursively zooming into
this function while modeling the objects that are relevant to each process at the corresponding detail level.
zooms into Element (1,1), Element (1,2), and Element 1,3), in that horizontal sequence. Thus, Element (1,2) will be
the second element in the first row of the matrix. A third dimension can be achieved by zooming into
each element, this time vertically, and this can proceed recursively. Each in-zooming operation, applied to
all the elements at the current level, adds one more dimension. Since each element can have a value, we
can use OPM to do matrix operations, such as addition or multiplication, and OPM tables can be used for
relational databases.
Time is one-dimensional and flows only forward, so to determine process execution order—the
timing—we only needed the vertical axis to specify the order of the subprocesses in an in-zoomed
process. Physical objects, however, are three-dimensional, so for object in-zooming we can at least
schematically model the relative layout of object parts in two dimensions, taking advantage of the fact
that the paper or computer screen used for conceptual modeling are two-dimensional. The limitation here
is that objects are rectangular rather than arbitrarily shaped, but we can still get a schematic, albeit rough,
2D layout. Moreover, if the in-zoomed object is an informatical object, such as a table or a matrix,
zooming into it can expose the actual cells of the table or matrix as individual objects.
Since the aggregation-participation fundamental structural relation does not prescribe any partial order
of process performance, the modeling of synchronous process refinement must use in-zooming, in which
order can be defined. The system in Fig. 10.5 is synchronous: there is a fixed, well-defined order of each
subprocess within the in-zoom context of Dish Washing.
To model asynchronous process refinement we use the aggregation-participation fundamental
structural link, either through in-diagram aggregation unfolding or as a new-diagram aggregation
unfolding of the process. Figure 21.8 depicts a portion of a Home Safety System that carries out the
function Home Safety Maintaining, which includes the subprocesses Burglary Handling, Fire Protecting,
and Earthquake Alarming. Since the order of these three subprocesses is unknown, the OPD uses in-
diagram aggregation unfolding with an aggregation-participation link from this function rather than an in-
zoomed version of Home Safety Maintaining. Home Safety Maintaining in-zooms to a recurring systemic
process, Monitoring & Detecting, for which Detection Module is an instrument and Threat Appearing is an
environmental process.
Importantly, when a process is in-zoomed, its subprocesses are its parts, while the objects exposed as
a result of this in-zooming are the process’ attributes. Symmetrically, when an object is in-zoomed, its
internal objects are its parts, while its internal processes are its operations. The latter fact provides for
depicting processes as operations of an object by putting them inside the in-zoomed view of that object.
Fig. 21.9 The eqivalence between in-zooming (left) and unfolding (right)1
An OPD tree is a directed tree graph whose nodes are OPDs obtained by recursive
refinement (in-zooming and/or unfolding) of processes in the system, starting with the
function—the process in SD.
The OPD set is the set of all the nodes in the OPD tree.
1
The red contour is assigned by OPCAT automatically to a thing that is both in-zoomed and unfolded.
308 Complexity Management: Refinement and Abstraction
Detail level of an OPD is the number of nodes in the OPD tree that need to be
traversed from that OPD to the root, SD, including SD itself.
The OPD tree is a tree of processes—a graph whose nodes are OPDs. The root is SD, the System
Diagram, and the other nodes are the descendant OPDs, marked with their OPD labels, such as SD1,
which is at detail level 1, SD2.3, which is at detail level 2, etc. The directed edges of an OPD tree have
labels with each edge pointing from the parent OPD, which contains the refineable element, to a child
OPD containing refinees, which elaborates a process in the parent OPD via new-diagram in-zooming for
synchronous subprocesses or new-diagram aggregation unfolding for asynchronous subprocesses.
Since in-zooming has the semantics of aggregation-participation, each in-zooming in the hierarchy is
also interpreted as aggregation-participation in order to preserve the tree structure. Figure 21.10 shows at
the top the OPD tree—the hierarchy of the Product Lifecycle Engineering system OPM model (Dori and
Shpitalni 2005). The OPD set of the model in Fig. 21.10 has 11 OPDs spanning 4 levels of detail.
While the OPD tree is presented like a file hierarchy (see Fig. 21.10 top), the system map, shown at
the bottom of Fig. 21.10, is a more elaborate presentation of the OPD tree.
The system map is an elaborate OPD tree, in which each node in the tree is a
miniaturized icon of the OPD, with thick grey arrows pointing from each process in
one OPD to its refined (in-zoomed or unfolded) version in the child OPD.
The system map explicitly depicts the elements (things and links) in each OPD (node). Because the
system map may become very large and unwieldy, mechanisms shall allow access to model content and
the associations among elements. The system map helps navigate in a complex system that may comprise
hundreds of OPDs at many levels of detail. As an example, the executable OPM model of the mRNA
decay model in Somekh et al. (2014) contains hundreds of objects and processes in over 40 OPDs at 9
levels of detail, with hyperlinks from a thing in the model to the paper from which the model fact was
extracted.
Figure 21.11 is a screenshot of a simulated execution of the mRNA Decay OPM model (Somekh et al.
2014), showing it being at an OPD SD2.4.2.2.1.2.4.2 – elF4F Dissociates Cap and Decaysome in-zoomed,
as indicated also by the frame around this process in the OPD tree on the left. This OPD demonstrates the
self-similarity of OPDs: regardless of what detail level an OPD is at, it used only stateful objects,
processes, and relations among them.
Currently, the system in Fig. 21.11 is executing in parallel four subprocesses (in dark blue), after
having completed the subprocess elF4F Dissociates Cap above them. The dissociation is manifested in
each of these four subprocesses by consuming a link, modeled as an object in its own right, between two
objects, e.g., the factor Xrn1 and the protein elF4E at the bottom are dissociated by the process elF4E and
Xrn1 Dissociation. Below the OPD is the lifespan diagram, enabling inspection of each object and process
at each point in time. The browser on the left is open on the relevant paper, one of the 43 papers from
which the model facts in this OPD were taken, obtained by clicking on the in-zoomed process.
This example demonstrates the indispensability of the refinement mechanisms, and in particular in-
zooming. Without it, it would be impossible to comprehensibly show the hundreds of things in the model
and the thousands of links among them in a single OPD or in any other kind of diagram.
Dori – Model-Based Systems Engineering with OPM and SysML 309
In addition, an OPM tool set should provide a mechanism for creating views, as OPDs with associated
OPL sentences, of objects and processes that meet specific criteria. These views may include the critical
path for minimal system execution duration, or a list of system agents and instruments, or an OPD of
objects and processes involved in a specific kind of link or set of links. For example, an OPD can be
created by (1) refining (unfolding or in-zooming) an object or (2) collecting and presenting in a new OPD
things that appear in various OPDs for expressing assignment of system sub-functions to system-module
objects.
Fig. 21.10 The tree hierarchy (top) and system map (bottom) of the Product Lifecycle Engineering system OPM
model
310 Complexity Management: Refinement and Abstraction
The ultimate OPD is single flat representation of the OPM system model.
The ultimate OPD is obtained by recursively flattening the OPD tree from the bottom up all the way to
the OPD tree toot, such that the entire model is represented in this single OPD. Except for very small
system models, the ultimate OPD is definitely unfit for use by humans due to our limited cognitive
capacity. However, for computer processing—knowledge management, navigation, querying, etc., the
ultimate OPD is very useful.
Fig. 21.11 A screenshot of simulated execution of the mRNA Decay OPM model (Somekh et al. 2014), showing detail
level 8—SD2.4.2.2.1.2.4.2—elF4F Dissociates Cap and Decaysome in-zoomed
An OPD object tree is a tree whose root is an object B and whose nodes are things
that result from recursively refining B via unfolding and in-zooming, where each in-
zooming is converted to aggregation-participation.
Each tree stems from a distinct refineable object that unfolds or in-zooms to reveal its details—not
necessarily just parts as in the process in-zooming, but possibly also features, specializations, or
instances. Rather than identifying the possible flow of execution control as in the OPD (process) tree,
Dori – Model-Based Systems Engineering with OPM and SysML 311
each OPD object tree encapsulates the information about an object as a hierarchical structure. Since in-
zooming has the semantics of aggregation-participation, like the OPD tree, each in-zooming in the
hierarchy of the OPD process is also interpreted as aggregation-participation in order to preserve the tree
structure. Complete or partial OPD object trees can be presented as views (see Sect. 21.18). The root of
each OPD object tree can be attached as a child of the node in the OPD (process) tree, creating the system
map (see Sect. 21.12).
21.14 Out-Zooming
Out-zooming is the inverse operation of in-zooming. A scenario in which the need for out-zooming arises
is when the modeler observes that the current OPD is already over-crowded, making it necessary to hide
the content of an in-zoomed process in the current OPD. In-diagram out-zooming does not create a new
OPD, which implies removing and losing the subprocesses and objects inside the process being out-
zoomed. Therefore, unless the modeler decides that these subprocesses are too detailed for the purpose at
hand and is ready to delete them, in-diagram out-zooming does not make a lot of sense.
New-diagram in-zooming elaborates a refineable in an existing OPD, say SDn, where n is the current
level of detail, by creating a new OPD, SDn+1, which elaborates the refineable at the next detail level by
adding subprocesses, associated objects, and relevant links. Figure 21.12 is a metamodel of the New-
Diagram In-Zooming and New-Diagram Out-Zooming processes. The OPM model on the right uses in-
diagram in-zooming of the model on the left to elaborate the two processes: New-Diagram In-Zooming, for
creating a new-diagram in-zoomed context, filled in with subprocesses and objects, and New-Diagram
Out-Zooming, for creating a new-diagram out-zoomed (empty) context. New-Diagram In-Zooming begins
with Content Showing, followed by Link Refining. New-Diagram Out-Zooming begins with Link
Abstracting, the inverse process of Link Refining, followed by Content Hiding, the inverse process of
Content Showing.
Semi-Zoomed OPD is an interim object, which is created and subsequently consumed during both New
Diagram In-Zooming and New-Diagram Out-Zooming. This interim object appears only within the contexts
of both New-Diagram In-Zooming and New-Diagram Out-Zooming.
In Fig. 21.13, the metamodel on the left hand side of Fig. 21.12 is elaborated by embedding an actual
OPDs inside its objects SDn, SDn+1, and Semi-Zoomed OPD. In this particular OPM model example,
SDn, presented in Fig. 21.13 at the top middle, includes the process P, which is a refineable about to be
in-zoomed, as well as four objects: the consumee C, the agent A, the instrument D, and the resultee B,
connected to P with the corresponding different procedural links. This OPD inside the meta-object SDn is
instrument for the New-Diagram In-Zooming on the left.
Content Showing is the first of the two New-Diagram In-Zooming subprocesses. During Content
Showing, the boundary of P expands to make room for showing its content—the model subprocesses P1,
P2, and P3, as well as the interim model object BP. The result of Content Showing is presented as the
content of the interim object Semi-Zoomed OPD. This interim object is recognizable only in the context of
New-Diagram In-Zooming. The second subprocess, Link Refining, done by the modeler, consumes it while
creating SDn+1 presented in Fig. 21.13 at the bottom in the middle.
During Link Refining, the procedural links attached to the contour of P migrate to the appropriate
subprocesses as determined by the modeler. Thus, since P1 consumes C, the consumption link arrowhead
312 Complexity Management: Refinement and Abstraction
migrates from P to P1. The agent A handles both P1 and P2, so in SDn+1 two agent links, one to P1 and
the other to P2, replace the single one in SDn from A to P. P3 requires D, so the instrument link migrates
from P to P3. Finally, since BP results from P1, and P3 consumes it, the corresponding result and
consumption links are added, making BP an interim, internal object of P, recognizable only within the
context of P. Likewise, P1, P2, and P3 are internal processes of P, and as such they are recognizable only
within the context of P. The OPD inside the meta-object SDn+1 is instrument for the New-Diagram Out-
Zooming on the right. What happens next is the exact inverse of what we have seen, both in the order of
the subprocesses and what each of them does.
Link Abstracting is the first of the two New-Diagram Out-Zooming subprocesses. During Link
Abstracting, the links connected to subprocesses and interim objects of P migrate to (the boundary, the
ellipse circumference of) P itself, resulting in exactly the same Semi-Zoomed OPD that is depicted inside
New-Diagram In-Zooming. This Semi-Zoomed OPD interim object is consumed by Content Hiding,
creating SDn presented in Fig. 21.13 at the top in the middle. The boundary of P can now shrink, as it is
empty and there is no need for making room to show its content (the model subprocesses P1, P2, and P3,
Dori – Model-Based Systems Engineering with OPM and SysML 313
as well as the interim model object BP), which is now hidden. The result of Content Showing is presented
as the content of the interim object Semi-Zoomed OPD.
Fig. 21.13 The metamodel on the left in Fig. 21.12 elaborated with an example of an actual OPM model inside it
In the middle of Fig. 21.14, P123 undergoes new-diagram out-zooming, resulting in SD1.1[new] (in a
real implementation, the new OPDs shall not be marked with [new]; this label only helps the explanation
here).
314 Complexity Management: Refinement and Abstraction
Here is how this is done. The modeler indicates the things in the set TO (things to be out-zoomed) and
the name of the new interim process to be created (P123 in our case). The grey background denotes these
candidate elements. The process-to-be P123 now undergoes new-diagram out-zooming, following the two
subprocesses described earlier: link abstracting and content hiding. As a result of link abstracting, the
links that were connected to subprocesses of the future P123 process migrated to the contour of the now-
created P123, and as a result of content hiding, P123 becomes empty, as shown in SD1[new].
Fig. 21.14 Simplifying SD1 of the OPM model on the left by in-diagram out-zooming followed by new-diagram in-
zooming yields a new OPM model on the left, in which SD1[new] and SD1.1[new] replace SD1
In order to preserve the model facts that were eliminated (such as the model facts that A is agent to P1
and P2), a new OPD, SD1.1[new], was created with these facts. Hence, on the right of Fig. 21.14 is the
new OPD set, which now has four OPDs: SD[new], SD1[new], SD1.1[new], and SD1.1.1[new], renumbered
to reflect the new OPD hierarchy, In this augmented hierarchy, the complicated OPD SD1 has been
replaced by two simpler OPDs – SD1[new] and SD1.1[new].
Dori – Model-Based Systems Engineering with OPM and SysML 315
Examining SD1[new], we see that it is indeed less complicated and less crowded than the original SD1,
since it has a net of five fewer elements: three removed processes, P1, P2, and P3, one removed object,
BP, two removed links, and one added process, P123. This new OPD is inserted into the process
hierarchy, pushing the old SD1.1, which remains unchanged, one detail level down, from detail level 2 to
detail level 3. Due to the addition of SD1.1[new], SD1.1is renumbered to be SD1.1.1[new].
Fig. 21.15 Abstracting different procedural links invokes the link precedence
To sustain this principle, OPM resolves the conflict between candidate links by determining, based on
the links’ semantic strength, which link remains or which new link replaces the candidates in the abstract
OPD. The loss of detail information is consistent with the notion of abstraction. Semantic strength and
link precedence are two concepts to guide the determination of which links to retain and which to hide
when an OPD is out-zoomed or folded.
Semantic strength of a procedural link is the significance of the information that the
link carries.
Information concerning a change in existence, either creation or elimination, is more significant than
information about change to an existing thing. The relative semantic strength of the two conflicting
procedural links determines the link precedence. When two or more procedural links compete to remain
316 Complexity Management: Refinement and Abstraction
represented in an OPD that is being abstracted (out-zoomed, folded, or state-suppressed), the link that
prevails is the one with the highest semantic strength.
Table 21.1 shows link precedence among the transforming links: P in the upper left corner is out-
zoomed. The column headings show the three possible transforming links between P1 and B, while the
row headings show the three possible links between P2 and B. The table cells show the prevailing link
between B and P after P is out-zoomed. Cells marked as “Invalid” indicate the impossibility of the
combination. For example, inspecting the center cell, if P1 consumes B, then B no longer exists when P2
later tries to consume it again. Since object creation and consumption are semantically stronger (i.e., they
have higher semantic strength) than affecting the object by changing its state, result and consumption
links have precedence over effect links, as demonstrated in Table 21.1. However, since result and
consumption links are semantically equivalent, when they compete, the prevailing link shall be the effect
link because the effect link allows both creation and elimination as effects.
Within the enabling links, an agent link has precedence over an instrument link, because in artificial
systems the humans are central to the process, they handle the system and must ensure its proper
operation. In addition, wherever there is human interaction, an interface should exist and this information
should be available to the modeler of a refineable so that they can design the human-system interface
according to the conceptual model specification.
Summarizing the semantic strength of the procedural non-control links, the primary link precedence is
as follows:
Consumption = Result > Effect > Agent > Instrument
Here, the = and > symbols refer to the semantic strength of the links. State-specified links have higher
precedence than basic links that do not specify states.
Things (objects or processes) must not occlude each other. They are either completely contained
within higher-level things, in case of zooming, or have no overlapping area. An exception to
this guideline is when port folding (See Sect. 21.8) is applied.
The diagram should not contain too many links.
A link should not cross the area occupied by a thing.
The number of links crossing each other should be minimized.
An OPD model specification is the collection of successive OPDs in the system’s OPD
tree.
Dori – Model-Based Systems Engineering with OPM and SysML 321
21.21 Summary
Complexity management is essential for taming the complexity of real-world systems, both
man-made and natural.
The OPM Model Complexity Assertion is that applying refinement mechanisms of in-zooming
and unfolding to stateful objects or processes, OPM can conceptually model systems at any level
of complexity.
OPM’s complexity management approach is detail-level-based decomposition, which is in
contrast with UML and SysML approach of aspect-based decomposition.
The completeness-clarity trade-off is the tension between the need to specify the system such
that all the model facts are represented, while maintaining a clear, comprehensible representation
of the system.
The three refinement-abstraction mechanisms are unfolding–folding, in-zooming–out-zooming,
and state-expressing–state-suppressing. A fourth is view-creating–view-deleting.
State-expressing is showing one or more of an object’s states; state-suppression is hiding one or
more of the object’s states.
Each of the four fundamental structural relation links may undergo unfolding and folding, so
there are four kinds of unfolding-folding pairs.
In-diagram unfolding is unfolding in which the refineable and its refinees appear unfolded in
the same OPD in which the refinee was originally.
New-diagram unfolding is unfolding in which the refineable and its refinees appear unfolded in
a new OPD.
322 Complexity Management: Refinement and Abstraction
21.22 Problems
1. Based on Fig. 21.1, create an OPM model that explains the two specializations of
decomposition, what they mean, and which kind is used by what language.
2. Present on object with four states and a process that affects it.
3. Suppress the states that are not relevant to the model in the previous question and add the
incomplete state symbol.
4. Model a complex object with three levels of unfolding, including aggregation unfolding and
exhibition unfolding.
5. Select two subprocesses from Fig. 21.6. For each, apply new-diagram in-zooming and add model
elements as you see fit.
6. Perform out-zooming from the in-zoomed processes in the two OPDs created in the previous
problem.
7. What is the ultimate OPD of the system in Fig. 21.6?
8. Is the process in Fig. 21.6 synchronous or asynchronous? Explain.
9. Is the process in Fig. 21.17 synchronous or asynchronous? Explain.
Dori – Model-Based Systems Engineering with OPM and SysML 325
10. Draw an in-zoomed map of part of the Mid-West of the USA with at least six states, where each
state is an object, while maintaining approximate spatial relations among the states.
11. In Fig. 21.13, change the OPDs inside SDn and SDn+1 such that a need to invoke the procedural
link precedence shall arise.
12. For the model in the previous problem, create the Semi Zoomed OPD analogous to that in Fig.
21.13.
13. In Fig. 21.14, define TO as {P3, P4, P5, BK}, perform the out-zooming, and show the resulting
SD[new], SD1[new], SD1.1[new], and SD1.1.1[new].
Chapter 22
OPM Operational Semantics and
Control Links
Control Flow Semantics presents a unified, formal treatment of the semantics of a
wide spectrum of control flow notions as found in sequential, concurrent, logic,
object-oriented, and functional programming languages.
de Bakker and de Vink (1996)
To control the flow of system execution, OPM has precise operational semantics, based on the event-
condition-action paradigm and expressed by modifying the procedural links with control modifiers—
event and condition symbols. This is the focus of this chapter.
precondition for every process to which the object is a source of the link, and the event ceases to exist. If
and only if the evaluation reveals satisfaction of the precondition, then the process starts executing.
Events can occur also through the end of a subprocess inside an in-zoomed process, as well as through
invocation link and exception link, which occur between processes. Thus, according to the event-
condition-action paradigm, starting the performance of a process (the “action”) has two prerequisites: (1)
an initiating event (the “event”), and (2) satisfaction of a precondition (the “condition”). Events and
preconditions in concert specify OPM flow of execution control for process performance. The flow of
execution control is the consequence of successive event-condition-action sequences that begin with
initiation of the system function by an external event and end when the system function either completes
executing successfully or terminates abnormally.
Event and condition links do not exist independently. Rather, they are modified versions of the
various procedural links. Each procedural link from an object or a state to a process (i.e., object or state in
the preprocess object state) has a corresponding event link and a corresponding condition link.
A control modifier is one of the two letter symbols e and c, added to a procedural link,
which add to the semantics of that link the event and condition semantics, respectively.
An event link is a procedural link with the control modifier e, indicating the addition
of event semantics to the link’s destination process.
An event link specifies a source event and a destination process—the process that is initiated upon the
event occurrence. The event occurrence triggers evaluation of the process’ precondition. Satisfying the
precondition allows process performance (execution) to proceed, rendering the process active. If the
process precondition is not satisfied, then process performance shall not occur. Regardless of whether the
evaluation is successful or not, being a point in time, the event is lost. If the process precondition is not
satisfied, process initiation shall not occur until another event activates the process.
initiated process,
The object initiates the process,
Consumption initiating which consumes
which, if performed, consumes
event link consumee the initiating
the object. Food initiates Eating, which
consumes Food.
consumee
Graphically, a lightening symbol jagged (and possibly curved) line from the invoking source process
to the invoked destination process ending with a closed arrowhead at the invoked process denotes an
invocation link. This is the symbol of the common invocation link.
There is a second kind of invocation link—self-invocation link, which enables modeling invocation of
a process by itself: Upon process completion, the process immediately invokes itself. A self-invocation
link is symbolized by a pair of invocation links, originating at the process and joining head to tail before
ending back at the original process shall denote the self-invocation link. Invocation links are summarized
in Table 22.5. If a waiting period is needed between two consecutive invocations, a Waiting process with
specified time constraints (see below) can be inserted as a destination from the invoking process and as a
target back to the same process. An invocation link from the last subprocess to its parent in-zoomed
process can be used to create loops.
A condition link is a procedural link with the control modifier c, indicating the
addition of condition semantics to the link’s destination process.
A condition link provides a bypass mechanism, which enables system execution control to skip, or
bypass, the destination process if its precondition satisfaction evaluation fails. Without the condition link
bypass mechanism, failure to satisfy the precondition causes the process to wait for another event.
334 OPM Operational Semantics and Control Links
Upon the arrival of the new event, that process precondition is evaluated again, and if it is satisfied,
the process starts executing, otherwise it is again waiting for the next event. This can cause the control to
get stuck indefinitely in that process in an infinite loop. Using the condition link prevents such situations.
As discussed in Sect. 21.17, as is the case with all control links, if a condition link is attached to a
process P, and P is in-zoomed, the condition link migrates automatically to the first subprocess (or two or
more first concurrent subprocesses) of P. The modeler may move the link from that first subprocess to
another subprocess or add another link from the same source to one or more subprocesses other than the
first one.
If an object instance
exists and the rest of the
process precondition is
satisfied, then the
Condition
process performs and Conditioning Conditioned
consumption
consumes the object object process
link
instance, otherwise Process occurs if Object exists, in
execution control which case Process consumes
advances to initiate the Object, otherwise Process is
next process. skipped.
If an object instance
exists and the rest of the
process precondition is
satisfied, then the
Condition process performs and Conditioning Conditioned
effect link affects the object object process
instance, otherwise Process occurs if Object exists, in
execution control which case Process affects
advances to initiate the Object, otherwise Process is
next process. skipped.
If at runtime (i.e., during execution of the system model) a consumee instance exists when an event
initiates the process, then the presence of that consumee instance satisfies the process precondition with
respect to that object. If evaluation of the entire precondition, which accounts for the entire preprocess
object set (of which the consumee is a part) is satisfied, the process starts and consumes that consumee
instance. However, if a consumee instance does not exist when an event initiates the process, then,
regardless of the rest of the preprocess object set, the process precondition evaluation fails, and the flow
of execution control bypasses (skips) the process without executing that process.
A condition effect link like its regular, non-condition effect link counterpart, connects an affectee to a
process, with the addition of the control modifier c. If at runtime an affectee instance exists when an event
initiates the process, then the presence of that affectee instance satisfies the process precondition with
respect to that object. As with the condition consumption link, if evaluation of the entire precondition,
which accounts for the entire preprocess object set (of which the affectee is a part) is satisfied, the process
starts and affects that affectee instance, but if not, then the process precondition evaluation fails, and the
flow of execution control bypasses the process without executing that process.
addition of the control modifier c. If at runtime an agent instance exists when an event initiates the
process, then the presence of that agent instance satisfies the process precondition with respect to that
object. If evaluation of the remaining precondition is satisfied as well, the process starts and that agent
handles its performance. However, if an agent instance does not exist when an event initiates the process,
then the process precondition evaluation fails and the flow of execution control bypasses, or ‘skips’ the
process without process performance.
A condition instrument link is an instrument link from an instrument to a process, annotated with the
control modifier c. If at runtime an instrument instance exists when an event initiates the process, then
the presence of that instrument instance satisfies the process precondition with respect to that object. If
evaluation of the entire preprocess object set satisfies the precondition, the process starts. However, if an
instrument instance does not exist when an event initiates the process, then the process precondition
evaluation fails and the flow of execution control bypasses, or ‘skips’ the process without process
performance (Table 22.7).
Table 22.7 Condition enabling link summary
Figure 22.1 is an OPD with a condition instrument link from Nearby Mobile Device to Cellular
Network Signal Amplifying, which occurs only if an environmental object Nearby Mobile Device exists
and is otherwise skipped, as there is no point in amplifying if no device is nearby. Table 22.6 summarizes
the basic condition transforming links.
Dori – Model-Based Systems Engineering with OPM and SysML 337
If at runtime an instance of the instrument exists and is at the specified state when an event initiates
the process, then the process precondition is satisfied with respect to that object. If evaluation of the entire
preprocess object set satisfies the precondition, the process starts and that instrument must remain existent
and at the same state throughout the duration of the process
If at runtime an instance of the instrument does not exist or exists at a different state than the one
attached to the link source, then the process precondition with respect to that object is not satisfied, the
process precondition evaluation fails, and the flow of execution control bypasses performing the process.
Table 22.9 summarizes the condition state-specified enabling links.
Fig. 22.2 Three ways to indicate process duration: Left—expected (nominal) time only, middle—minimal and maximal,
right—minimal, expected, and maximal time durations
The value of the process’ Expected Duration is the statistical mean of the duration of that process.
Duration optionally exhibits the Duration Distribution attribute with a value identifying the name and
parameters for a probability distribution function associated with the process duration or a non-analytical
distribution. At run-time, the value of Duration is determined separately for each process instance (i.e., for
each individual process occurrence) by sampling from the process Duration Distribution. The Duration
property provides for defining exception links. There are two kinds of exception link: overtime exception
link and undertime exception link.
Dori – Model-Based Systems Engineering with OPM and SysML 341
A source process may have both overtime and undertime links, each connected to a different
destination time exception handling process. Suppose in the example in Fig. 22.3 we add an Overtime
Exception Handling process, then the additional OPL sentence would be:
Overtime Exception Handling occurs if duration of Processing exceeds 60.0 min.
Unlike most procedural links, which connect an object and a process, but similar to the invocation
link, the two time exception links are procedural links that connect two processes directly. An implicit
interim object Overtime Exception Message or Undertime Exception Message is created by the OPM’s
process execution mechanism upon realizing that the process failed to terminate by the maximal allotted
time or ended prematurely, falling short of the minimal allotted time, respectively. Since the OPM
operational mechanism creates and immediately consumes these objects, their depiction is not explicit in
the model. This is similar to the invocation link, which suppresses the creation of an interim object by the
source process and its immediate consumption by the destination process. Table 22.10 summarizes the
two time exception links.
The exceptions these links handle relate only to time, but they can also be used for modeling
execution exceptions. For instance, if a process with minimal time duration attached to an undertime
exception link is skipped, which means its duration was 0, then the exception handling process is
initiated.
Yield rate is the transformation rate of a result link connecting a resultee B and a
process P whose value is the rate of creation of B by P.
Effect rate is the transformation rate of an effect link connecting an affectee B and a
process P whose value is the rate of affecting B by P.
344 OPM Operational Semantics and Control Links
State change rate is the transformation rate of an in-out link pair whose input and
output links connect the input state bi and output state bo of an affectee B to a process
P, whose value is the rate of changing the state of B by P from bi to bo.
Figure 22.4 provides an example of consumption rate and yield rate. The modeler may create an
exception if the quantity of the resultee or the consumee is less than the rate times the expected process
duration.
Fig. 22.5 SD of the Machining system with Residue Length Computing as an operation of Machining
Fig. 22.6 SD1 of the Machining system from Fig. 22.5, in which Residue Length Computing is in-zoomed
346 OPM Operational Semantics and Control Links
The Machining process generates Shaft at a yield rate of 3 units/hr, therefore in 3 hours we get 9
Shafts, as indicated by the participation constraint near Shaft. The length of each Shaft is 0.22 m and the
Size of the Shaft Batch (cut during 3 hr) is 9. All these data are provided in the model in Fig. 22.5.
Zooming into Residue Length Computing in Fig. 22.6, we see that it has two subprocesses. The first is
Used Length Computing (u=s*l) and the second—Residue Computing (residue=il–u). The names of the
processes contain in parentheses the arithmetic expressions to be carried out by each process. The
expression on the first subprocess computes u, the value of Used Length of Rod, as u=s*l. It takes s=9 as
the value of the Size of the Shaft Batch and l=0.22 m as the Length of each Shaft. The product, u=s*l
=9*0.22 =1.98 m, is the input for the next subprocess, in which the model computes residue=il-u, since the
length of the residue is the difference between il, the value of the initial Length of the Rod, 3.00 m, and u,
the value of Used Length of Rod, so residue=il–u=3.00–0.22=1.02 m. Different parameter values will, of
course, yield different results. This example demonstrates how OPM enables mixing conceptual modeling
with quantitative modeling which provides reasoning for the various mathematical steps involved in the
computation.
subprocess(es) within the context of the deepest process. Control returns to the in-zoomed process after
its last subprocess completes its execution (Fig. 22.8).
Fig. 22.7 SD of Machining, where Shaft Batch is a set of 9 object instances from the class Shaft, so creating Shaft
Batch implies iteration of Machining nine times, each time producing one Shaft
Fig. 22.8 SD1 of Machining, in which Machining is in-zoomed, expressing the fact that Cutting and Lathing are
performed sequentially and iteratively 9 times to yield the nine Shafts
An implicit invocation link can be (1) from a process to its first (or several) subprocess(es), (2) from a
subprocess to one or more subprocesses just below it along the time line inside the context of an in-
zoomed process, or (3) from the last in-zoomed subprocess(es) to their enclosing, context defining
process.
Specifically, (1) upon arriving at an in-zoomed process context, control immediately transfers to the
subprocess (es) with the highest ellipse (oval) top-most point within this in-zoomed process context. The
implicit invocation link from an in-zoomed process to its top-most subprocess transfers execution control.
(2) Along the process timeline, the completion of a source subprocess (or the last subprocess to finish
executing in the case of two or more subprocesses that started concurrently) immediately initiates the
subsequent subprocess(es) using the implicit invocation link. (3) Upon completion of performing the
subprocess with an ellipse top-most point that is lowest within this in-zoomed process context, execution
control returns to the in-zoomed process.
When two or more subprocesses have their top-most ellipse points at the same height, then an implicit
invocation link initiates each process and they start in parallel upon individual precondition satisfaction.
The process that completes last initiates the next subprocess or set of parallel subprocesses.
In the OPD on the left hand side of Fig. 22.9, Cleaning invokes Coating, so Cleaning affects Product
first and then Coating affects Product. The invocation link dictates this process sequence. In the
equivalent OPD on the right hand side of Fig. 22.9, Finishing zooms into Cleaning and Coating, with the
former’s ellipse top point above the latter’s, so when Finishing starts, control immediately transfers to
Cleaning, and when Cleaning ends, the implicit invocation link invokes Coating. The two OPDs are
semantically equivalent, but the one on the left does not have Finishing as an enclosing context, making it
less expressive from a system viewpoint while using two links more than the OPD on the left.
Fig. 22.9 Invocation link (left) and implicit invocation link (right)
ellipse top point at the same height, the control initiates them in parallel. If there are no more
subprocesses to invoke, control returns to the in-zoomed refineable process.
Figure 22.10 shows subprocesses of Processing with the following partial order: A, (B, C), D, (E, F,
G). B and C start upon completion of A. D starts upon completion of the longer process from among B and
C. E, F, and G start upon completion of D. Execution control returns to Processing upon completion of
the longest process from among E, F, and G.
Fig. 22.10 Partial subprocesses order and implicit parallel invocation link set
In Fig. 22.12, the OPD on the left contains invalid consumption and result links, as annotated in the
OPL. The consumption link gives rise to the OPL sentence “P consumes C.” The reason is that applying
link distribution, the consequence is the three OPL sentences “P1 consumes C.”, “P2 consumes C.”, and
“P3 consumes C.”. However, since P1 consumes C first according to its temporal order, the same instance
of C does not exist when P2 or P3 performs, and therefore neither P2 nor P3 can consume C again.
Similarly, the same instance of B results only once. The OPD on the right depicts valid links since they
specify which of the subprocesses of P consumes C (it is P1) and which one yields B (P2).
Since attaching a consumption or result link to an in-zoomed process is invalid, when a process is in-
zoomed, all the consumption and result links that were attached to it shall be attached initially or by
default to its first subprocess. It is the modeler’s responsibility to move the links to subsequent
subprocesses as needed.
Dori – Model-Based Systems Engineering with OPM and SysML 351
Fig. 22.11 Link distribution across in-zooming context. Left: the shorter, correct version. Right: the equivalent loinger
version
Fig. 22.12 Link distribution restriction for consumption and result links
As soon as the modeler in-zooms P in Fig. 22.12 and inserts P1 into its context, the modeling tool
should migrate the destination end of the consumption link emanating from C from P to P1. Similarly, the
source end of the result link to B should also migrate from P to P1. When the modeler adds P2, the
modeler may migrate the destination end of the consumption link and/or the source end of the result link
from P1 to P2, as Fig. 22.12 shows.
352 OPM Operational Semantics and Control Links
A split input link is the input link of the split in-out-specified link pair.
A split output link is the output link of the split in-out-specified link pair.
In Fig. 22.13, the OPD in the middle is underspecified because if P1 changes A from s1 to s2, P2
cannot do this again, but it can go the other way—change A from s2 back to s1, but neither is explicitly
specified. P1 can change A from s1, i.e., take it out of s1 and leave it in transition between s1 and s2. In-
between P1 and P2 there may be one or more other interim subprocesses, during which A is still in that
transition. P2 then changes A to s2. The OPD on the right models this case (without interim
subprocesses), creating a split input link from s1 of A to P1 and a split output link from P2 to s2.
Table 22.12 summarizes the split input-output specified effect link pair. There are no control-modified
versions of the split input-specified effect link, because this can cause the of effect link semantics to be
distorted. For example, if in Fig. 22.13 P1 is skipped, A stays in s1, so if P2 is not skipped, A was not
taken out of s1, so it cannot change to s2 according to the semantics of the effect link.
Dori – Model-Based Systems Engineering with OPM and SysML 353
Fig. 22.14 The OPM model of the constraint “Married people are of age >= 18”
Dori – Model-Based Systems Engineering with OPM and SysML 355
22.13 Summary
An event is a point in time at which something significant to the system execution happens.
Events and preconditions in concert specify OPM flow of execution control for process
performance according to the event-condition-action paradigm.
The event-condition-action paradigm stipulates that starting the performance of a process (the
“action ”) has two prerequisites: an initiating event and satisfaction of a precondition derived
from the preprocess object set.
A control modifier is one of the two letter symbols e and c, added to a procedural link, which
add to the semantics of that link the event and condition semantics, respectively.
A control link is a procedural link with the addition of a control modifier.
An event link is a procedural link with the control modifier e, indicating initiation of the link’s
destination process, triggering that process’ precondition evaluation.
A condition link is a procedural link with the control modifier c, indicating that if the
precondition of the link’s destination process is not met, then that process is skipped.
The skip semantics precedence OPM principle states that skip semantics, induced by a control
link, takes precedence over wait semantics, induced by a non-control link.
A maximal-timed process is a process for which the modeler determines a maximal duration.
An overtime handling process is a time exception process that determines what to do in case the
time performance of a maximal-timed process exceeds its maximal allowable time.
An overtime exception link is a procedural link from a maximal-timed process to an overtime
handling process, indicating that if the duration of a maximal-timed process exceeds its maximal
duration, then the overtime exception process is initiated.
A minimal-timed process is a process for which the modeler determines a minimal duration.
An undertime handling process is a time exception process that determines what to do in case
the time performance of a minimal timed process falls short of its minimal duration.
An undertime exception link is a procedural link from a minimal-timed process to an undertime
exception process, indicating that if the time performance of a timed process falls short of its
minimal allowable time, the undertime exception process is initiated.
356 OPM Operational Semantics and Control Links
22.14 Problems
1. Why is the event link in Fig. 3.5 needed?
2. What is the role of the condition link in in Fig. 6.1?
3. Explain why in Fig. 7.1 two condition links are needed.
4. Use Fig. 21.15 as a template and replace B, P, P1 and P2 in it with meaningful things.
5. Explain why each one of the five entries in Table 21.1 marked “invalid” is indeed invalid.
6. Explain why in Fig. 21.13 P123 (the set TO of thing to out-zoom) cannot contain P4 and BK
only.
7. What thing must be added to P4 and BK such that TO becomes valid?
8. Assuming TO is the set as you suggested in the previous question, draw the resulting
SD1.1[new].
9. Create the OPM model of uninterrupted irrigating by water as a consumee for the process
irrigating. The consumee has an attribute quantity [liter] with value 1000 and the consumption
link has a consumption rate [liter/sec] with value 50.
10. Create the OPM model of the following system. Gasoline and Diesel Oil are resultees of the
process Refining, which consumes Crude Oil. The resultees Gasoline and Diesel Oil each have an
attribute Volume [m3]. The Refining to Gasoline result link has yield rate [m3/hour] with value
1000 and the Refining to Diesel Oil result link has yield rate [m3/hour] with value 800. Assuming
there is enough Crude Oil, if Refining activates and performs for 10 hours, it will yield 10,000
[m3] of Gasoline and 8,000 [m3] of Crude Oil.
Chapter 23
Logical Operators and Probabilities
Logic and probability theory are two of the main tools in the formal study of
reasoning, and have been fruitfully applied in areas as diverse as philosophy,
artificial intelligence, cognitive science and mathematics.
Stanford Encyclopedia of Philosophy (2013)
Logical operators, including AND, NOT, OR, and XOR (exclusive OR) enable modeling complex
conditions on performance of processes. Using XOR, OPM can also assign probabilities to such outcomes
as creating one of several possible objects, or an object in a specific state. We discuss these in this
chapter.
Fig. 23.1 Logical AND used with agent and instrument links
In Fig. 23.2 (left), Meal Preparing yields all three of the dishes. In Fig. 23.2 (right), Meal Eating
consumes all three dishes.
Fig. 23.2 Logical AND used with result and consumption links
In the OPD on the left of Fig. 23.3, Interest Rate Changing affects the three objects Exchange Rate,
Price Index, and Interest Rate. In the OPD on the right, all three effects of Interest Rate Raising on
Exchange Rate, Price Index, and Interest Rate are made explicit via three pairs of in-out-specified effect
links.
Fig. 23.3 Logical AND used with effect link and with in-out specified link pairs
Dori – Model-Based Systems Engineering with OPM and SysML 359
Fig. 23.4 The mRNA Decay and Nuclear Import Process (Somekh et al. 2014) showing the use of NOT via existent and
non-existent states of molecules
The mRNA Decay and Nuclear Import Process is the in-zoomed process in Fig. 23.4 (Somekh et al.
2014). This OPD shows how the existent and non-existent states of molecules are used to implement
“NOT”. For example, the existent state of the complex CCR4Not (no pun intended), depicted at the
bottom right corner, is linked to Decaysome Import—the third subprocess from the top, so only if
CCR4Not exists can this subprocess take place. However, in this case there are six other substances (such
as Edc3) that can each enable the process, and they are linked with an OR logical operator (discussed
below), so only lack of all the seven substances would prevent CCR4Not occurring. If the non-e (short for
360 Logical Operators and Probabilities
non-existent) state of CCR4Not would be linked with a condition link to Decaysome Import, that would
mean (disregarding other links) that the absence of CCR4Not is the condition for the occurrence of
Decaysome Import.
A link fan is a set of f (f ≥2) procedural links of the same kind that originate from a
common point, or arrive at a common point, on the same object or process.
The convergent end of a link fan is the end that is common to the f fan links.
The divergent end of a link fan is the end that is not common to the f fan links.
The convergent end is attached to one thing, while the divergent end is attached to f things, where f is
the size of the link fan set—the number of links in the fan. A link can be a member of both a divergent
fan on its source and a convergent fan on its target.
Since the links are procedural, one end is attached to object and the other to processes or vice versa.
Formally, the attribute value of the Perseverance of the Thing attached to the link fan’s convergent end is
the opposite of the attribute value of the Perseverance of the f Things attached to the link fan’s divergent
end. Thus, as the OPD in Fig. 23.5 shows, if the attribute value of the Perseverance of the thing attached
to the link fan’s convergent end is dynamic (transient), then the thing is a Process. In this case, the
attribute value of the Perseverance of the f Things attached to the link fan's divergent end is static
(persistent), implying that these f things are all Objects.
Suppose an agent link to a third safe owner, Safe Owner C, is added to the fan, making f = 3. The OPL
sentence then becomes:
Exactly one of Safe Owner A, Safe Owner B, or Safe Owner C handle Safe Opening.
Suppose an agent link to a third safe owner, Safe Owner C, is added to the fan, making f=3. The OPL
sentence then becomes:
At least one of Safe Owner A, Safe Owner B, or Safe Owner C handles Safe Opening
362 Logical Operators and Probabilities
A diverging fan is a link fan whose links point to its divergent end.
Table 23.1 presents a summary of XOR and OR converging consumption and result links for f>2,
showing in the top row that a converging consumption link fan is formed when the source things are
objects and the destination thing is a process. In a converging result link fan, the source things are
processes and the destination thing is an object. Conversely, as Table 23.2 shows, when the source thing
is an object and the destination things are processes, we get a diverging consumption link fan, while
when the source thing is a process and the destination things are objects, a diverging result link fan is
formed.
Table 23.1 Summary of XOR and OR converging fans for consumption and result links
Dori – Model-Based Systems Engineering with OPM and SysML 363
Table 23.2 Summary of XOR and OR diverging fans for consumption and result links
XOR OR
Diverging
consumption
link fan
Diverging
result link
fan
An effect link is bidirectional, so the things linked by an effect link fan are both source and destination
at the same time, voiding the definitions of convergent and divergent link fans. Instead, as Table 23.3
shows, the distinction occurs with respect to multiple objects or multiple processes that a link fan
connects.
Table 23.3 Summary of XOR and OR joint effect link fans
364 Logical Operators and Probabilities
Since an enabler is an object, both agent and instrument link fans can be diverging, with multiple
processes as targets, as shown in Table 23.4, or converging, with multiple enablers as sources, as shown
in Table 23.5.
Table 23.4 Diverging agent and instrument link fans
Invocation link fans can also be diverging or converging for both XOR and OR, as shown in Table 23.6,
where the semantics of questionable combinations is specified.
Table 23.6 Invocation link fans
In the OPD, we add the number m outside and next to the XOR arc, as demonstrated by the number 2
recorded in the OPD on the left of Fig. 23.6.
In general, in combinatorial XOR we constrain the model to select exactly m of f links, we use the
reserved phrase “exactly m of” where m < f , and the number of possibilities is .
23.5.2 Combinatorial OR
Similar to the combinatorial XOR, we generalize the OR logic to combinatorial OR. We do so by
extending the logic from 1 to any number m (up to one less than f ) links by replacing “at least one of” in
an OPL sentence by “ at least m of”, where m < f. Using again the OPL sentence above, which extends
the model in Fig. 23.5, where the link fan size is f = 3, instead of “one” we can write m = 2, effectively
introducing a sum combinatorial number of possibilities.
At least 2 of Safe Owner A, Safe Owner B, or Safe Owner C handle Safe Opening.
3
In this case, the number of possibilities is 32 3
= 3+1=4. In the OPD, we add the number m outside
and next to the OR arc, as demonstrated by the number 2 recorded in the OPD on the right of Fig. 23.6.
In general, for constraining the model to select at least m of f links, we use the reserved phrase “at
1
least m of” where m < f, and the number of possibilities is .
Dori – Model-Based Systems Engineering with OPM and SysML 367
Two or more processes can have the same state as their source. For example, as the OPD on the right
hand side of Fig. 23.8 shows, either P1 or P2 (but not both) can consume B when it is at state s1: Either P1
or P2 consumes s1 B. If there are more than two processes, the OPL sentence becomes: Exactly one of P1,
P2, or P3 consumes s1 B. A similar situation occurs with state change in the OPD on the right of Fig.
23.8: Either P1 or P2 changes B from s1 to s2. And for more than two processes: Exactly one of P1, P2, or P3
changes B from s1 to s2.
Fig. 23.8 Left: P1 XOR P2 can consume B when it is at state s1. Right: P1 XOR P2 can change B from s1 to s2
23.7 presents the event and condition effect link fans, as representatives of the basic (non-state-specified)
links version of the modified link fans.
Table 23.7 Event and condition XOR effect link fans
State-specified
consumption
link fan Exactly one of P, Q, or R occurs if B is s2, in
S2 B initiates exactly one of P, Q, or R, which which case the occurring process consumes B,
consumes the initiated process. otherwise these processes are skipped.
State-specified
agent link fan
State-specified
instrument
link fan
S2 B initiates exactly one of P, Q, or R, which Exactly one of P, Q, or R requires that B is s2,
requires s2 B. otherwise these processes are skipped.
The stateless case: The stateless case:
S2 B initiates exactly one of P, Q, or R, which Exactly one of P, Q, or R requires that B is s2,
requires B. otherwise these processes are skipped.
370 Logical Operators and Probabilities
Fig. 23.9 Event link has OR semantics (right) since they are unlikely to happen at the same moment
Fig. 23.10 Equivalence between result link and a set of XOR state-specified result links
Dori – Model-Based Systems Engineering with OPM and SysML 371
P yields s1 B with probability 0.32, s2 B with P yields A with probability 0.3, B with probability q, or sc1 C
probability 0.24, or s3 B with probability 0.44. with probability 0.7–q.
A probabilistic link fan is a link fan with a probability value assigned to each of its
links, such that the sum of the probability values of all the links is exactly 1.
Graphically, in a probabilistic link fan, a probability value in the form , where is the link
probability numeric value or a parameter, such that ∑ 1. This symbol, which appears along
each one of the f links in the probabilistic link fan, denotes the probability that the system execution
control mechanism will select that particular link and follow that path.
The corresponding OPL sentence is the XOR diverging link fan OPL sentence without link
probabilities omitting the phrase “exactly one of…” and adding instead the phrase “…with probability ”
following each participating thing name with a probability annotation .
Figure 23.11 shows two probabilistic state-specified object creation examples and their deterministic
OPL analogues. In the OPD on the left, process P can create object B in three possible states, s1, s2, or
s3, with corresponding probabilities 0.32, 0.24, and 0.44 (totaling 1), as indicated along each result link of
the result link fan. In the OPD on the right, P can create one of the objects A, B, or sc1 C, i.e., C at state
sc1, with the probabilities 0.3, q, and 0.7–q (totaling 1), respectively.
For a process P with a result link that yields a stateful object B with states s1 through sn, and with
initial state si, P creates B at state si with probability 1. If B has m < n initial states, P shall create B at one
of the initial states with probability 1/m.
For a probabilistic result link fan, any one of the resultees may be an object without or with a specified
state. For all the link fans comprising other procedural link kinds (including those with the event and
372 Logical Operators and Probabilities
condition control modifiers), where the targets of the links in the link fan are processes, the source may be
an object or a specified state of an object.
Fig. 23.12 Objects with and without specified states as resultees and consumees of a probabilistic link fan
Fig. 23.13 Examples of various probabilistic state-specified change: from a state to one of two final states (left),
probabilistic result to one of three final states (middle), and probabilistic change from one state to another (right)
The OPD on the left hand side of Fig. 23.12 shows a probabilistic result link fan in which P yields one
of the objects A or B, or C at state sc1, or D at state sd1 or sd2, each with its specified probabilities. The
OPD in the middle of Fig. 23.12 shows a probabilistic consumption link fan in which A is consumed, with
Dori – Model-Based Systems Engineering with OPM and SysML 373
specified probabilities, by one of the processes P or Q or R. The OPD in the bottom expresses the same,
with the additional fact that A must be at state s2.
Figure 23.13 presents examples of various probabilistic state-specified transformations. On the left is
a state change from a state to one of two final states. In the middle—probabilistic creation (result), and on
the right—probabilistic change from one state to another.
23.9 Summary
Logical operators, including AND, OR, and XOR (exclusive OR) enable modeling complex
conditions on performance of processes.
Two or more procedural links of the same kind that originate from, or arrive at, different points
along the process ellipse circumference (the process context), have the semantics of the logical
AND operator.
A link fan is a set of f ≥2 procedural links of the same kind that originate from a common point,
or arrive at a common point, on the same object or process.
The convergent end of a link fan is the end that is common to the f fan links.
The divergent end of a link fan is the end that is not common to the f fan links.
A link fan with a single dashed arc denotes the logical XOR operator.
A link fan with a double dashed arc denotes the logical OR operator.
A converging fan is a link fan whose links point to its convergent end.
A diverging fan is a link fan whose links point to its divergent end.
Each one of the XOR link fans for consumption, result, effect, and enabling links and their state-
specified versions has a corresponding control-modified link fan: an event link fan and a
condition link fan.
Link probability is an optional attribute value assigned to a procedural link in a XOR diverging
link fan that specifies the probability of following that particular link among the possible links in
the fan link.
A probabilistic link fan is a link fan with a probability value assigned to each of its links, such
that the sum of the probability values of all the links is exactly 1.
23.10 Problems
1. Combine the two OPD in Fig. 23.1 to express that each one of the two safe owners must have all
the three keys to open the safe.
2. Combine the two OPD in Fig. 23.2 to express that the chef prepares either entrée or starter and
dessert, and the diner eats whatever is prepared.
374 Logical Operators and Probabilities
3. In the top-left and bottom-right OPDs in Table 23.1 replace the thing manes with content that
will yield sense-making OPL sentences.
4. Repeat the previous question for Table 23.2.
5. Do the same for one OPD in each one of Tables 23.3, 23.4, and 23.5.
6. Chose any three OPDs from the last three questions and add probabilities to them. If needed,
modify them.
Chapter 24
Overview of ISO 19450
This book contains a comprehensive coverage of OPM that is compatible with ISO 19450 Publically
Available Specification (PAS) titled “Automation systems and integration—Object-Process
Methodology”, and in French: “Systèmes d’automatisation et intégration—Méthodologie du processus-
objet”. The ISO 19450 PAS has been adopted by the International Organization for Standardization (ISO)
in December 2015 through the work of ISO Technical Committee 184/ Sub-committee 5 (TC184/SC5) after
a six-year effort, mainly by Richard Martin, David Shorter, Alex Blekhman, and this author. This book
was prepared in parallel with the ISO 19450 PAS standard, so the two are almost completely aligned with
each other. Since the standard (formally PAS) must conform to the rules of ISO for standard authoring, it
is structured differently and is not as elaborate as the book. Rather, it is an orderly exposition of OPM that
enables tool developers to use it, along with this book, as a solid basis for developing an ISO 19450-
complaint software tool to support OPM-based conceptual modeling. ISO standards like ISO 19450 PAS
contain normative parts and often also one or more informative parts. To be compliant with the standard,
a normative part must be strictly followed, while an informative part is not mandatory. This book is a
superset of ISO 19450 PAS. About 90% of the material in this book is aligned with ISO 19450. The rest
can be considered as the equivalent of an addition to the informative part of the standard—it should be
followed, but ISO 19450 in its current initial form does not mandate it. This closing chapter describes
briefly the content of the ISO 19450 PAS, where each section is devoted to a summary of one or more
sections of ISO 19450.
OPM notation supports the conceptual modelling of systems with formal syntax
and semantics. This formality serves as the basis for model-based systems
engineering in general, including systems architecting, engineering,
development, life cycle support, communication, and evolution. Furthermore,
the domain-independent nature of OPM opens system modelling to the entire
scientific, commercial and industrial community for developing, investigating
and analysing manufacturing and other industrial and business systems inside
their specific application domains; thereby enabling companies to merge and
provide for interoperability of different skills and competencies into a common
intuitive yet formal framework.
Tesperanto can be considered as a textual version of The Imitation Game, better known as Turing
Test—a test proposed in 1951 by Alan Turing, which was designed to settle the issue of machine
intelligence. While in the original Turing Test a human judge has to decide whether she or he is
interacting with a human or a computer, in the textual version of Turing Test, the judge has to decide
whether a given text was written by a computer or by a human. Quite clearly, OPL text, while being
comprised of syntactically correct English sentences will quickly be identified as written by a computer, it
will be more difficult for a human to reveal this when presented with a Tesperanto text.
According to ISO directives, the definitions must be phrased such that if we can substitute an
Italicized term with its definition and still get a legible, sense-making definition. For example, when we
perform the term substitution of procedural relation in the definition of procedural link, we get:
3.56
procedural link
graphical notation of connection or association between an object or object state and a process in OPM
This explains why none of the term definitions neither starts with a capital letter nor end with a period.
We can continue with this substitution process twice, first for process:
3.56
procedural link
graphical notation of connection or association between an object or object state and a transformation of
one or more objects in the system in OPM
3.56
procedural link
graphical notation of connection or association between an object or object state and a creation
(generation, construction) or consumption (elimination, destruction) of an object or a change in the state of
an object of one or more objects in the system in OPM
As we see, this is still working, although, unavoidably, the definition gets longer and longer. This can
go on until all substitution have been made, and the validity check is done by verifying that no cycle has
been created, i.e., the term being defined must not appear anywhere in the definition.
The list of term definitions is followed by Clause 4—Symbols and Clause 5—Conformance. Then
comes Clause 6—Object-Process Methodology principles and concepts, discussed next.
System function and modelling purpose shall guide the scope and extent of
detail of an OPM model. … The function or benefit expectations of stakeholders
in general and beneficiaries in particular shall identify and prescribe the
modelling purpose. This, in turn, shall determine the scope of the system
model.
Dori – Model-Based Systems Engineering with OPM and SysML 379
The use of “shall” is mandatory and prevalent in standards, as the first line in the quote above
demonstrates; it implies a mandatory, conformance issue. Next, unification of function, structure, and
behaviour is discussed:
… The combination of system structure and behaviour enables the system to
perform a function, which shall deliver the (functional) value of the system to
at least one stakeholder, who is the system’s beneficiary. An OPM model
integrates the functional (utilitarian), structural (static), and behavioural
(dynamic) aspects of a system into a single, unified model. Maintaining focus
from the viewpoint of overall system function, this structure-behaviour
unification provides a coherent single frame of reference for understanding the
system of interest, enhancing its intuitive comprehension while adhering to
formal syntax.
The Clause then goes on to elaborate on the difference between function and behavior, the former
being a subjective, utilitarian aspect, while the latter is the objective dynamic system aspect. With respect
to setting the boundary of the system, 19450 states:
The system’s environment shall be a collection of things, which are outside of
the system but which may interact with the system, possibly changing the
system and its environment. The modeller shall distinguish these
environmental things, which are not part of the system, from systemic things,
which are part of the system. The modeller is not able to architect, design or
manipulate the structure and behaviour of environmental things even though
those environmental things may influence or be influenced by the system.
The last subject in the first subclause of Clause 6 is the clarity-completeness trade-off:
Overwhelming detail and complicatedness are inherent in real-life systems.
Making such systems understandable entails a trade-off that should balance
between two conflicting criteria: clarity and completeness. Clarity shall be the
extent of unambiguous comprehension that the system’s structure and
behaviour models convey. Completeness shall be the extent of specification for
all the system’s details. These two model attributes conflict with each other. On
the one hand, completeness requires the full stipulation of system details. On
the other hand, the need for clarity imposes an upper limit on the extent of
detail within an individual model diagram, after which comprehension
deteriorates because of clutter and overloading.
The next subclause in Clause 6—OPM Fundamental Concepts—presents first the bimodal representation
of OPM—its graphics text equivalence:
An OPM model shall be bimodal with expression in semantically equivalent
graphics and text representations. Each OPM model graphical diagram, i.e. an
Object-Process Diagram (OPD), shall have an equivalent OPM textual
paragraph comprised of one or more OPM language sentences using the Object-
Process Language (OPL).
380 Overview of ISO 19450
Then OPM elements are defined as things and links. This is the first step in defining the OPM metamodel,
described in ISO 19450, as shown in Fig. 24.2.
In the sequel, the critical difference between a conceptual models and a runtime model is explained,
emphasizing that when constructing OPM models, modelers need to understand the distinction between
the conceptual model they are creating and an operational occurrence of that model that they may use to
assess system behavior. The modeler may simulate system behavior by creating object and process
operational instance occurrences, and then follow the flow of execution control embodied in the
connections and OPM semantic rules.
1
The shading like the one in this figure indicates OPDs and excerpts copied from ISO 19450.
Dori – Model-Based Systems Engineering with OPM and SysML 381
Each annex has an attribute whose values are “normative” and “informative”. The term normative in
ISO standards means that this is an abiding operational part of the standard and shall be followed by
whoever claims to conform to the standard.
Conversely “informative” means that this is a non-abiding part of the standard that may be followed
but is not mandatory to claim conformance to the standard. In this sense, all the material in this book that
is not included in the normative parts of ISO 19450 can be aggregated into another informative annex.
Based on Bibliowicz and Dori (2012), a fifth (informative) annex, in which OPDs are defined with a
graph grammar, was planned to be included in ISO 19450. It was finally removed because of technical
problems with the multiple graphical elements that were too difficult to handle with the new ISO
publication system.
2
ISO 14977 is a freely available standard that can be downloaded free of charge from http://isotc.iso.org/livelink/
livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm
382 Overview of ISO 19450
Fig. 24.3 A sample of the EBNF notation expressing the context-free grammar of OPL
specifies
OPM System
Model
graphically specifies
OPD OPL
Set textually specifies Spec
+ +
graphically specifies OPL
OPD textually specifies Paragraph
OPL +
graphically specifies
+ OPD
Construct textually specifies Sentence
Punctuation +
can be in-zoomed to create
Thing Set
2..*
Thing
Name
Person
Birth minor adult
Growing
or
or
in
t
in
ul
t
m
ul
Age [yr]
m
ad
ad
Legal Status
e
0 <18 >=18 Changing
Fig. 24.7 Legal Status Changing changes Person from minor to adult when Growing changes Age of Person from
<18 to >=18. (Figure D.1 in ISO 19450)
Alternatively, Fig. 24.8 uses the object System Clock, which any system may have, either explicitly as
in this example, or implicitly, to trigger an event when the System Clock, which starts upon Birth, and
when it reaches 18 yr it creates an event that triggers Legal Status Changing.
Fig. 24.8 The System Clock event initiating Legal Status Changing (Figure D.2 in ISO 19450)
References
Bunge, M. Treatise on Basic Philosophy, Vol. 3, Ontology I, The Furniture of the World. Reidel, Boston,
MA, 1977.
Bunge, M. Treatise on Basic Philosophy, Vol. 4, Ontology II, A World of Systems. Reidel, Boston, MA,
1979.
Chein, M. & Mugnier, M.L. Conceptual graphs: fundamental notions.Rev. Intell. Artif. 6(4), pp. 365–406,
1992.
Chen, P.P. The Entity Relationship Model – Toward a Unifying View of Data. ACM Trans. on Data Base
Systems 1(1), pp. 9–36, 1976.
Clark, J. M. & Paivio, A. Dual coding theory and education. Educational Psychology Review, 3(3), 149–
210, 1991.
Coad, R. and Yourdon, E. Object-Oriented Analysis. Prentice-Hall, Englewood Cliffs, NJ, 1991.
Cook, S. In the Foreword to Warmer and Kleppe (1999).
Descartes, R. Principles of Philosophy (1647). Trans. Valentine Rodger Miller and Reese P. Miller. D.
Reidel Publishing Company, p. 282, 1984.
Dittrich, K.R., Gatziu, S., and Geppert, A. The Active Database Management System Manifesto: A
Rulebase of ADBMS Features. Lecture Notes in Computer Science 985, Springer, pp. 3–20, 1995.
Dirks, T. The Greatest Films, 2001. http://www.filmsite.org/gone.html. Accessed March 16, 2015.
DoDAF – DoD Architecture Framework Version 1.5, 2007.
DoDAF – DoD Architecture Framework Version 2.02, Change 1, 2015.
http://dodcio.defense.gov/TodayinCIO/DoDArchitectureFramework.aspx. Accessed March 16, 2015.
Dori, D., Object-Process Methodology – A Holistic Systems Paradigm, Springer Verlag, Berlin,
Heidelberg, New York, 2002 (ISBN 3-540-65471-2; Foreword by Edward Crawley. Hard cover, 453
pages, with CD-ROM). eBook version: http://link.springer.com/book/10.1007/978-3-642-56209-
9/page/1
Dori, D., ViSWeb – The Visual Semantic Web: Unifying Human and Machine Knowledge
Representations with Object-Process Methodology. The International Journal on Very Large Data
Bases (VLDB), 13, 2, pp. 120–147, 2004.
Dori, D. Words from Pictures for Dual Channel Processing: A Bimodal Graphics-Text Representation of
Complex Systems. Communications of the ACM, 51(5), pp. 47–52, 2008.
Dori, D., Martin, R., and Blekhman, A. Model-Based Meta-Standardization: Modeling Enterprise
Standards with OPM. 2010 IEEE International Systems Conference, San Diego, CA, USA, April 5–
8, 2010.
Dori, D. Reinhartz-Berger, I., and Sturm, A. Developing Complex Systems with Object-Process
Methodology using OPCAT. LNCS 2813, pp. 570–572, 2003.
References 389
Downton, C. In Smolan, R. and Erwitt, J. One Digital Day. Time Book/Random House in association
with Against All Odds Production, 1998.
Firlej, M. and Helens, D. Knowledge Elicitation: A Practical Handbook. Prentice-Hall, New York, 1991.
Fowler, M. UML Distilled, Second Edition. Addison-Wesley, Reading, MA, 1999.
Friedenthal, S., Moore A., and Steiner, R. A Practical Guide to SysML (Second Edition), The Systems
Modeling Language, Morgan Kaufmann, 2014.
Galileo, G. The Assayer, 1623, as reprinted in (Drake, 1957, p. 274)
Grobshtein, Y. and Dori, D. Generating SysML Views from an OPM Model: Design and Evaluation.
Systems Engineering, 14 (3), pp. 327–340, 2011.
Harel, D. Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming 8,
pp. 231–274, 1987.
Harel, D. On Visual Formalisms. Communications of the ACM 31(5), pp. 514–530, 1988.
Helighen, F. Principia Cybernetica Web (1997). http://pespmc1.vub.ac.be/occamraz.html Accessed May
27, 2015.
Holt, J. UML for Systems Engineering: Watching the Wheels. IEE Professional Applications of
Computing, 2004.
IATA http://www.iata.org/about/Pages/index.aspx Accessed May 31, 2015.
Kant, I. Prolegomena to Any Future Metaphysics That Will Be Able to Present Itself as a Science (in
German). Riga, 1783.
Kilov, H. and Simmonds, I. D. Business Patterns: Reusable Abstract Constructs for Business
Specification. In Humphreys, P., Bannon, K., McCosh, A., Migliarese, P. and Pomerol, J.S. (Eds.),
Implementing Systems for Supporting Management Decisions. Chapman and Hall, London, 1996.
Klyne G., Carroll, J.J., and McBride, B. RDF 1.1 Concepts and Abstract Syntax, 2004
http://www.w3.org/TR/rdf-concepts Accessed March 16, 2015.
Koffka, K. Principles of Gestalt Psychology: New York: Harcourt-Brace, 1935.
Kostovic, I. and Rakic, P. Developmental history of the transient subplate zone in the visual and
somatosensory cortex of the macaque monkey and human brain. J. Comp. Neurol., 297: 441–470,
1990. doi: 10.1002/cne.902970309
Latimer, C. and Stevens, C. Some remarks on Wholes, Parts and Their Perception. Psycoloquy 8(13), Part
Whole Perception (1), 1997.
Lehman, F. (ed.) Semantic networks in artificial intelligence. Pergamon, Oxford, UK, 1999.
390 References
MacIntyre, J. What’s wrong with the noun/adjective/verb object oriented design strategy (2010).
https://whileicompile.wordpress.com/2010/08/01/the-noun-adjective-verb-object-oriented-design-
strategy-sucks/ Accessed June 9, 2015.
Manola F. and Miller E. RDF 1.1 Primer, 2014. http://www.w3.org/TR/2014/NOTE-rdf11-primer-
20140624/. Accessed March 16, 2015.
Mayer, R.E. The promise of multimedia learning: using the same instructional design methods across
different media. Learning and Instruction 13, pp.125–139, 2003.
Mayer, R.E. and Moreno, R. Nine Ways to Reduce Cognitive Load in Multimedia Learning. Educational
Psychologist 38(1), pp. 43–52, 2003.
Mazanec, M. and Macek O. On General-purpose Textual Modeling Languages. Proc. 12th Annual
International Workshop on Databases, Texts, Specifications, and Objects, Zernov, Rovensko pod
Troskami, Czech Republic, pp. 1–12, 2012.
Meinhardt, H. The Algorithmic Beauty of Sea Shells. Springer-Verlag, Berlin, 1995.
MIT ESD. Massachusetts Institute of Technology Engineering Systems Division Vision.
http://esd.mit.edu/about/vmv.html Accessed May 28, 2015.
Mordecai, Y. and Dori, D. I5: A Model-Based Framework for Architecting System-of-Systems
Interoperability, Interconnectivity, Interfacing, Integration, and Interaction, 23rd International
Symposium of the International Council on Systems Engineering INCOSE IS-2013, Philadelphia,
PA, USA, June-2013.
Ockham, W., Quaestiones et decisiones in quattuor libros Sententiarum, Petri Lombardi ed., Lugd., 1495.
OMG OCL Object Constraint Languge, Version 2.4, 2014. http://www.omg.org/spec/OCL/2.4/PDF/
Accessed June 20, 2015.
OMG SysML System Modeling Language, Version 1.3, 2012. http://www.omg.org/spec/SysML/1.3/
PDF/ Accessed March 16, 2015.
OMG UML Unified Modeling Language, Infrastructure, Version 2.4.1, 2011I. http://www.omg.org/spec/
UML/2.4.1/Infrastructure/PDF/ Accessed March 16, 2015.
OMG UML Unified Modeling Language, Superstructure, Version 2.4.1, 2011S. http://www.omg.org/
spec/UML/2.4.1/Superstructure/PDF Accessed March 16, 2015.
OMG UML for Systems Engineering RFP, 2003. http://syseng.omg.org/UML_for_SE_RFP.htm
Accessed March 16, 2015.
Ouellette, J. A Fundamental Theory to Model the Mind. Quanta Magazine, 2014. https://www.
quantamagazine.org/20140403-a-fundamental-theory-to-model-the-mind/. Accessed March 18, 2015.
Peleg, M. and Dori, D. The Model Multiplicity Problem: Experimenting with Real-Time Specification
Methods. IEEE Transactions on Software Engineering 26(8), pp. 742–759, 2000.
References 391
The OPM principles are listed below in the order they appear in the book.