Dov DoriTechnion, MIT

Presentation at theINNOVATIVE APPROACHES & RESEARCHES FOR

MANAGING COMPLEXITYGORDON 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)

Why is Complexity a Problem?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 Need for Complexity ManagementThe 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.

In search for Completeness and ClarityCompleteness 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

Completeness vs. ClarityOn 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)

04/18/23 7

Simplicity is a must for modeling complex systems 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!

04/18/23 8

The “Divide and Conquer" StrategyThe 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.

04/18/23 9

Achieving Simplicity via the “Divide and Conquer" Strategy

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).

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

11

Diagram Types in UML and SysMLSysML Diagram

StructureDiagram

BehaviorDiagram

Use CaseDiagram

ActivityDiagram

Internal BlockDiagram

Block DefinitionDiagram

SequenceDiagram

State MachineDiagram

ParametricDiagram

RequirementDiagram

Modified from UML 2

New diagram type

Package Diagram

Same as UML 2

Is Divide and Conquer by Aspect a Good Strategy?

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?

04/18/23 13

“Divide and Conquer" OPM Style: Detail Decomposition

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.

04/18/23 14

Divide and Conquer: By Aspects or by Details?

04/18/23 15

The Minimum Description Length (MDL) Principle 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

16

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

04/18/23 17

What is OPM - Object-Process Methodology?A minimum description length language and a

comprehensive systems engineering paradigm forModelingCommunicatingDocumenting EngineeringLifecycle support

of complex, multi-disciplinary systemsBased on simultaneous representation of structure (via

stateful objects) and behavior (via processes)

Leading MBSE Methodologies (INCOSE Task Force, Estefan, 2008 p 43)

18

• 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 OPM is in the process of becoming ISO standard and the basis for Model-Based ISO Standards Authoringbasis for Model-Based ISO Standards Authoring

19

The basic OPM things:The basic OPM things:Objects and ProcessesObjects and Processes

20

OPM Entities – the bricks: Things and States

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

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.

Object

Processing

State 1 State 2

04/18/23 21

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

Compact Ontology: A Minimum Length OPM alphabet

22

What is in an OPM Model?The OPM model consists of a set of

Object-Process Diagrams (OPD set) and a correspondingObject-Process Language (OPL text) – a subset of English

OPL: Purifying changes Copper from raw to pure.

OPD:

OPM Elements: Entities and Links

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

24

The OPD Top-Down Hierarchy

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 objects they transformExpressing object states Each is a refinement of its ancestor. The “BIG PICTURE” is clear and not lost when looking at

details in low-level diagramsEach OPD is not too clutteredTogether they specify the system completely

25

OPM Feature I:OPM Feature I: Three-Aspect Unification Three-Aspect Unification

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.

26

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

OPM Feature II:OPM Feature II: Bi-modal expression Bi-modal expression

04/18/23 27

Resources: OPM book

Dov Dori, Object-Process Methodology - A Holistic Systems Paradigm, Springer Verlag, Berlin, Heidelberg, New York, 2002

04/18/23 28

http://esml.iem.technion.ac.il/ Resources: OPM-related Publications

Complexity Management: RecapThe ability to trade off clarity and

completeness: Clarity is the ability to clearly present and see

the system’s structure and behaviorCompleteness is the extent to which all the

details of the system are specifiedThese two model attributes necessarily

contradict each other

Complexity Management in OPM

Three refinement/abstraction mechanisms: In-zooming/out-zooming (applied primarily

to processes)

Unfolding/folding (applied primarily to objects)

State expression/state suppression

Complexity Management in OPM: An ACR System Example

In-Zooming Solves the Comprehension-In-Zooming Solves the Comprehension-Completeness Dilemma Completeness Dilemma

The two OPDs and OPL Paragraph The two OPDs and OPL Paragraph side-by-sideside-by-side

The Outcome of Crash Severity MeasuringThe Outcome of Crash Severity Measuring

Animated Simulation CheckAnimated Simulation Check

The System Diagram (SD) ofThe System Diagram (SD) of

Product Lifecycle EngineeringProduct Lifecycle Engineering

Zooming into Product Lifecycle EngineeringZooming into Product Lifecycle Engineering

The System Map: A Tree ViewThe System Map: A Tree View

The System Map: All the OPDs in one ViewThe System Map: All the OPDs in one View

Zooming into the Details of DesignZooming into the Details of Design

Zooming into the Details of ManufacturingZooming into the Details of Manufacturing

Zooming into Making within ManufacturingZooming into Making within Manufacturing

Zooming into Software Module Zooming into Software Module Developing within MakingDeveloping within Making

Zooming into Assembly & TestingZooming into Assembly & Testing

Zooming into CommerceZooming into Commerce

Zooming into Use & ServiceZooming into Use & Service

46

SD1.4 - End Of Life in-zoomed

                                                                                                                                                            

Product is physical.

Zooming into End-of-LifeZooming into End-of-Life

48

Complexity Management with OPM: Summary

OPM advocates minimal length description language:Using the minimal set of concepts and symbols required to

specify systems’ function, structure, and behaviorOPM uses a single type of diagram – OPD, and it isTranslated on the fly to natural language – OPL (for dual

channel processing)Complexity is managed by detail (not aspect) decompositionThree refinement-abstraction mechanisms:

In-zooming – Out-zoomingUnfolding – FoldingState expression – suppression