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)

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

In search for 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

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

5/15/20157 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!

5/15/20158 The “Divide and Conquer" Strategy 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.

5/15/20159 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 SysML

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?

5/15/ “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.

5/15/ Divide and Conquer: By Aspects or by Details?

5/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, April 2010

5/15/ What is OPM - Object-Process Methodology? 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)

Leading MBSE Methodologies (INCOSE Task Force, Estefan, 2008 p 43) (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 basis for Model-Based ISO Standards Authoring

19 The basic OPM things: Objects 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 1State 2

5/15/ 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 corresponding Object-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 transform Expressing 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

25 OPM Feature I: 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: Bi-modal expression

5/15/ Resources: OPM book Dov Dori, Object-Process Methodology - A Holistic Systems Paradigm, Springer Verlag, Berlin, Heidelberg, New York, 2002Object-Process Methodology - A Holistic Systems Paradigm

5/15/ Resources: OPM-related Publications

Complexity Management: Recap 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

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- Completeness Dilemma

The two OPDs and OPL Paragraph side-by-side

The Outcome of Crash Severity Measuring

Animated Simulation Check

The System Diagram (SD) of Product Lifecycle Engineering

Zooming into Product Lifecycle Engineering

The System Map: A Tree View

The System Map: All the OPDs in one View

Zooming into the Details of Design

Zooming into the Details of Manufacturing

Zooming into Making within Manufacturing

Zooming into Software Module Developing within Making

Zooming into Assembly & Testing

Zooming into Commerce

Zooming into Use & Service 46

SD1.4 - End Of Life in-zoomed Product is physical. Zooming 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 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