background-shape
DOI

DOI

Citation

Angelov, Boyan. (2021, July 4). Abstraction Levels: A Systems Thinking Method for Complexity Reduction. Zenodo. http://doi.org/10.5281/zenodo.5068787

In my recent work, both in writing and consulting, I’ve been using the term “abstraction level” quite freely - that is until I realized that my audience is not familiar with the term. After some research, I realized that what I freely borrowed from computer science was not commonly used in other disciplines. This is why I decided to elaborate on this concept in more detail. This article attempts to explain what this method is and how it helps solve complex contemporary problems, whether in technology, science, or society. I will show several practical examples, coming from chess (!) and computer science.

But first, let’s start with definitions of key terms. I will be using my favorite complexity definition from Raul Espejo:

Complexity is the difficulty of distinguishing the parts and relationships of the elements of a system. In other words, it’s the number of distinctions we can make about a system.

And now the “abstraction levels” definition from computer science:

The method of hiding the working details of a subsystem, allowing the generation of design patterns such as separation of concerns or interoperability.

With those two definitions, we can tackle the examples where we aim to reduce complexity by using abstraction levels.

Chess

Note: the diagram is shown above.

An interesting example of applying abstraction levels to real-world problems is the game of chess. We’ll use several positions to illustrate three different levels of abstraction, all of them having a different purpose. Let’s start with the first level of abstraction, which is also the “highest” one (which requires the least amount of information to be created) - the general phases of a game. Almost any chess game goes through three - opening, middle game, and the end-game. The rules in how to play those successfully are different - hence the need for the player to pay attention to which phase they are in. For example, in the opening stage, one vital thing to pay attention is to conquer the squares in the center of the board (those will eventually provide a mid-to-long-term advantage), and “develop” the pieces. On the other hand, when there are just a few remaining pieces on the board, it becomes much more important to be quick and calculate the opponent’s moves correctly, which becomes possible due to the lower number of possible states (complexity) in the system at this point.

For the next level, strategy, we go one deeper. Any position in chess can be observed at a global (board) level for general patterns. Those can include an imbalance in the position (such as opposite king castling) or bishops of the opposite color from the opponent’s pawn structure. Such high-level tactical components are essential for the chess player to take advantage of.

Finally, we move into the lowest possible level of abstraction, one of the individual pieces. Here we focus on a specific part of the board, ignoring the two higher levels of abstraction for a moment. For example, we can see if there is the possibility of making a check to the opponent’s king, whether a particular piece is hanging or a discovered attack.

Software

Since the term “abstraction levels” itself originates from the field of computer science, it was only natural to provide an example from there. We’ll show one from the field of web development. Most websites are built mainly using three languages: HTML, CSS, and JavaScript. Those are responsible for the page’s content, appearance, and behavior (roughly speaking), respectively. As is in writing prose - there are surprisingly different ways to write a software program that does the same thing - some better than others. Let’s have a look.

We can compare two ways of making the same website. Have a look at this code sample:

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Title Here</title>
</head>

<style>
    background-color: red;
    font-size: 13px;
</style>

<body>
    <p id="demo">A Paragraph.</p>

    <button type="button" onclick="myFunction()">Try it</button>

    <script>
        function myfunction() {
            document.getElementById("demo").innerHTML = "Paragraph changed!";
        }
    </script>
</body>

</html>

Here we have a combination of the three languages in the same file. You can see HTML elements, and inside of them, also CSS (inside of the <style> tag), and also JavaScript code in <script>. This website would work as expected, so what’s the issue? Imagine this page grows (which is inevitable in web development). Usually, you would have different people doing the work on the frontend (HTML and CSS) and the backend part (JavaScript), all with their associated tools (IDEs, linters, etc.). If the code is written as the first example, they would often encounter issues when editing the same file, looking at code they don’t need to see, and their tools might not work.

<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Title Here</title>
    <link rel="stylesheet" href="styles.css">
</head>

<body>
    <p id="demo">A Paragraph.</p>

    <button type="button" onclick="myFunction()">Try it</button>

    <script src="script.js"></script>
</body>

</html>

On the other hand if the team is separating the different parts of the website in different files like in the second example above (look at the style.css and script.js files), everything will be much clearer and easier to understand - even if the functionality doesn’t change at all. This is one example of where an abstraction (this example shows a case of separation of concerns) is useful.

I hope those examples help showcase a method that can prove to be useful for complex knowledge work. There are other examples of successful application of abstraction levels in different fields, such as the Model-View-Controller pattern and organizational charts. I invite the motivated reader to explore further.