Managing Systems Complexity via Refinement in OPM Models

Managing Systems Complexity via Refinement in OPM Models Dov Dori Technion, MIT Presentation at the Monash-Technion HD VC Seminar Series Technion, Haifa, Israel Oct 24, 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 conceptual modeling language must therefore be designed to control and manage this complexity. �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 language or methodology would have been required.

The completeness–clarity tradeoff �Like most classical engineering problems, complexity management entails a tradeoff. �There must be a balance between two conflicting requirements that pull in opposite directions: �completeness and clarity.

Completeness and Clarity defined �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.

Completeness vs. Clarity: Where is the conflict? �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) �Based on Miller’s magic number 5+/-2 (1956)

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 has to sacrificed, no detail should spared! �The question is how we distribute the information at various detail levels into diagrams that integrate as seamlessly as possible. 1/10/2022 7

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, �combine the partial solutions to obtain a complete solution. �System development methods have adopted the decomposition principle, either intentionally or not. 1/10/2022 8

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 UML – the OMG standard for software systems development (Object Management Group, 2000). 1/10/2022 9

The UML Approach to Managing System Complexity: Aspect-Based Decomposition �UML and Sys. ML (Systems Modeling Language that is a profile of UML) addresses the systems complexity problem by adopting a “Divide and Conquer” strategy �UML and Sys. ML divide the system model into each one of the important aspects of the system � structure, � dynamics, � state transitions � Requirements, parametics (in Sys. ML) �For each aspect there is one or several diagram types

Diagram Types in UML and Sys. ML 11

Is Divide and Conquer by Aspect a Good Strategy? �How do we go about using the 9 (in Sys. ML) 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?

“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. 1/10/2022 13

Divide and Conquer: By Aspects or by Details? 1/10/2022 14

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 1/10/2022 15

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 8 th International Conference (EVOLANG 8), Utrecht, Netherlands, 14 - 17 April 2010 16

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) 1/10/2022 17

Leading MBSE Methodologies (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 Sys. ML 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

The basic OPM things: Objects and Processes 19

OPM Entities – the bricks: Things and States �Object: A thing that exists or might exist physically or informatically. �Objects are stateful: Object State 1 State 2 � 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. 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 1/10/2022 21

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 OPD: OPL: Purifying changes Copper from raw to pure.

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

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 24

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

OPM Feature II: Bi-modal expression �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

Resources: OPM book Dov Dori, Object-Process Methodology - A Holistic Systems Paradigm, Springer Verlag, Berlin, Heidelberg, New York, 2002 1/10/2022 27

Resources: OPM-related Publications http: //esml. iem. technion. ac. il/ 1/10/2022 28

Complexity Management: Recap l l The ability to trade off clarity and completeness: l Clarity is the ability to clearly present and see the system’s structure and behavior l 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: l In-zooming/out-zooming (applied primarily to processes) l Unfolding/folding (applied primarily to objects) l 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

Zooming into End-of-Life

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 48