Dov Dori
Technion, MIT
Presentation at the
INNOVATIVE APPROACHES & RESEARCHES FOR MANAGING
COMPLEXITY
GORDON CENTER FOR SYSTEMS ENGINEERING
July 5, 2011

The field of study of complex systems holds that the dynamics of complex systems are founded on universal principles that may be used to describe disparate problems ranging from particle physics to the economics of societies.
Y. Bar-Yam (1997)
The human mind, after all, can only juggle so many pieces of data at once before being overwhelmed.
C. Downton (1998)
Bad design complicates things unnecessarily and confuses us.
Good design can tame complexity.
D. A. Norman (2010)

 Complexity is inherent in real-life systems.
 An integral part of a system development methodology must therefore be a set of tools for controlling and managing this complexity.
 Like most classical engineering problems, complexity management entails a tradeoff that must be balanced between two conflicting requirements:
 completeness and
 clarity.

 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, both a system development methodology and language must be equipped with a comprehensive approach, backed by set of reliable and useful tools, for controlling and managing this complexity.
 This challenge entails balancing two forces that pull in opposite directions and need to be traded off:
completeness and clarity.

 Completeness means that the system must be specified to the last relevant detail.
 Clarity means that to communicate the analysis and design outcomes, the documentation, be it textual or diagrammatic, must be legible and comprehensible.
 To tackle complex systems, a methodology must be equipped with adequate tools for complexity management
 We must strike the right balance between these two contradicting demands.
 Languages and tools must address and solve this completeness-clarity tradeoff problem

 On one hand, completeness requires that the system details be stipulated to the fullest extent possible.
 On the other hand, the need for clarity imposes an upper limit on the level of complexity of each individual diagram
 This limit precludes a diagram that is too cluttered or
overloaded from being adequate as a means of communication, since:
 Excessive detail violates the Human Limited Channel
Capacity cognitive principle of Mayer (2008)

 One has little hope to effectively model complex, multidisciplinary systems using a language and approach that is unnecessarily complex to begin with.
 We cannot ignore the inherent complexity of
systems, but
 We can simplify the way they are modeled by
minimizing the number of concepts, symbols, and diagram types.
 No accuracy is sacrificed, no detail spared!
4/13/2020 7

 The decomposition "divide and conquer" strategy, has been recognized for a very long time and in many domains as an effective means to
 overcome complexity and
 enable solving complex problems.
 The idea:

 break a complex problem into smaller, manageable pieces, solve each of them separately and
 combine the partial solutions to obtain a complete solution.
 System development methods have adopted the decomposition principle, either intentionally or not.
4/13/2020 8

 Most modeling methods apply this strategy by breaking the system into a number of models, each dealing with a different aspect of the system, such as structure, behavior, and function.
 Each model applies a different set of symbols and
concepts, and together they are expected to convey a complete system specification.
 This aspect decomposition is at the heart of standard, state-of-the-art object-oriented development methods like UML (Object Management Group, 2000).
4/13/2020 9

The Object-Oriented Approach to Managing
System Complexity:
Aspect-Based Decomposition
 OO development methods, notably the UML standard
(Object Management Group, 2000), address the systems complexity by a “Divide and Conquer” strategy
 UML and SysML divide the system model into each one of the important aspects of the system


 structure, dynamics, state transitions
 For each aspect there are several diagram types

SysML Diagram
Behavior
Diagram
Requirement
Diagram
Structure
Diagram
Activity
Diagram
Sequence
Diagram
State Machine
Diagram
Same as UML 2
Modified from UML 2
New diagram type
Use Case
Diagram
Block Definition
Diagram
Internal Block
Diagram
Package Diagram
Parametric
Diagram
11

 How do we go about using the 9 (in SysML) or 13 (in UML) different diagrams?
 What is the right order of modeling?
 When do we know that time has come to leave one type of diagram and move to the next?
 Which one comes next?
 When is the right time to return to the other diagram type?
 Which one to return to?
 How to ascertain consistency of the model across the multiple diagram types?

 OPM’s approach is entirely different.
 A basic principle of OPM is that structure and behavior within a system are so intertwined that effectively separating them is extremely harmful, if not impossible.
 Therefore, aspect-based decomposition is unacceptable, as it inevitably violates the singularity of the OPM model.
 The alternative OPM has adopted is detail decomposition:
 Rather than decomposing a system according to its various aspects, the decomposition is based on the system’s levels
of abstraction.
13 4/13/2020

Divide and Conquer: By Aspects or by Details?
difficult transition
4/13/2020 14

The Minimum Description Length (MDL)
Rissanen (1978)
 The purpose of language is to encode information, so that it can be communicated.
 MDL was originally used to evaluate mathematical models of data
 The complexity of the model can be measured by
 the size of the encoding system (the modeling language) and
 the size of the encoded data (the modeled system)
 Object-Process Methodology is a Minimum
Description Language
15 4/13/2020

Role of the MDL Principle in Evolution of Languages*
 Both the producer and the comprehender of a communication want the encoding to be simple.
 However, they have competing concerns as well.
 The producer desires conciseness and the comprehender desires fidelity.
 The likelihood of correctly decoding the data is in our context the extent to which a given model is fully understood by the comprehender
 The Minimum Description Length (MDL) Principle captures these two pressures on language.
* Schrementi, G. and Gasser, M. Minimum Description Length and Generalization in the Evolution Of
Language. In THE EVOLUTION OF LANGUAGE, Proceedings of the 8th International Conference
(EVOLANG8), Utrecht, Netherlands, 14 - 17 April 2010 16

 A minimum description length language and a comprehensive systems engineering paradigm for
 Modeling
 Communicating
 Documenting
 Engineering
 Lifecycle support of complex, multi-disciplinary systems
 Based on simultaneous representation of structure (via stateful objects) and behavior (via processes)
17 4/13/2020

(INCOSE Task Force, Estefan, 2008 p 43)
• IBM Telelogic Harmony-SE
• INCOSE Object-Oriented Systems Engineering Method
(OOSEM)
• IBM Rational Unified Process for Systems Engineering
(RUP SE) for Model-Driven Systems Development (MDSD)
• Vitech Model-Based System Engineering (MBSE)
Methodology
• JPL State Analysis (SA)
• Object-Process Methodology (OPM)
Q: Why is SysML not listed in this survey?
A: It is a language, not a methodology. OPM is both
OPM is in the process of becoming ISO standard and the basis for Model-Based ISO Standards Authoring
18

19

 Object : A thing that exists or might exist physically or informatically.
 Objects are stateful :


Objects can have states
At each point in time a stateful object is
State 1
Object
State 2

 at one of its states - static, or in transition between two states – undergoing change
 Process : A thing that transforms an object.
 Transforming an object is:


 creating it, consuming it, or changing its state.
Processing
20

Compact Ontology: A Minimum Length OPM alphabet
OPM unifies the system’s structure and behavior throughout the analysis and design of the system within one frame of reference using a small alphabet:
 Two types of things:
(1) stateful objects
(2) processes
 Two families of links:
(1) structural links: connect objects with objects
(2) procedural links: connect processes with objects
21 4/13/2020

The OPM model consists of a set of
Object-Process Diagrams ( OPD set ) and a corresponding
Object-Process Language ( OPL text ) – a subset of English
OPD:
OPL: Purifying changes Copper from raw to pure.
22

 Entity types:



Object: A thing that exists for some time
State: A situation at which an object can be
Process: A thing that transforms an object
 Link types:


Structural link: A link denoting a persistent relation between objects
Procedural link: A link between a process and the object it transforms or a state of that object








The root diagram is the most abstract level called System
Diagram (SD)
 The OPDs in the OPD set are hierarchical by construction via recursively refining entities:
 Zooming into processes of interest
Unfolding
Expressing objects they transform object states
Each is a refinement of its ancestor.
The “BIG PICTURE” is clear and not lost when looking at details in low-level diagrams
Each OPD is not too cluttered
Together they specify the system completely
24

 Function (utility aspect: why is the system designed, what value is it expected to provide?),
 Structure (static aspect: what is the system made of), and
 Behavior (dynamic aspect: how the system changes over time)
Are expressed in OPM bi-modally in a single model.
The model view multiplicity problem is avoided
– no mental integration load.
25

 An OPM model is expressed by two modalities :
 Intuitive yet formal graphics via a set of interrelated Object-Process Diagrams ( OPDs ), and
 An equivalent subset of natural language text (currently English), called Object-Process
Language ( OPL ) that is derived automatically from the user input graphics
26

Dov Dori, Object-Process
Methodology - A Holistic
Systems Paradigm , Springer
Verlag, Berlin, Heidelberg,
New York, 2002
4/13/2020 27

http://esml.iem.technion.ac.il/
4/13/2020 28

 The ability to trade off clarity and completeness:
 Clarity is the ability to clearly present and see the system’s structure and behavior
 Completeness is the extent to which all the details of the system are specified
 These two model attributes necessarily
contradict each other


/
(applied primarily to processes)

/
(applied primarily to objects)

/

Complexity Management in OPM:
An ACR System Example

In-Zooming Solves the Comprehension-
Completeness Dilemma

The two OPDs and OPL Paragraph side-by-side

The Outcome of Crash Severity Measuring

Animated Simulation Check

Zooming into Product Lifecycle Engineering

The System Map: All the OPDs in one View

Zooming into the Details of Manufacturing

Zooming into Making within Manufacturing

Zooming into Software Module
Developing within Making

46

 OPM advocates minimal length description language:
 Using the minimal set of concepts and symbols required to specify systems’ function, structure, and behavior
 OPM uses a single type of diagram – OPD, and it is
 Translated on the fly to natural language – OPL (for dual channel processing)
 Complexity is managed by detail (not aspect) decomposition
 Three refinement-abstraction mechanisms:
 In-zooming – Out-zooming
 Unfolding – Folding
 State expression – suppression
48