Generative Analysis for Generative AI

This chapter is from the book

Generative Analysis: The Power of Generative AI for Object-Oriented Software Engineering with UML

Learn More Buy

This chapter is from the book

This chapter is from the book 

Generative Analysis: The Power of Generative AI for Object-Oriented Software Engineering with UML

Learn More Buy

1.4 Abstraction

As we saw above, the notion of abstraction is intimately related to the notion of maps. In fact, without abstraction, we could not have maps. But what is abstraction?

If you read ISO 10746-2, the Reference Model for Open Distributed Processing (RM-ODP), you’ll find the following definition for abstraction:

• Abstraction: “The suppression of irrelevant detail.”—ISO 10746-2

That’s a good definition, but we also like to define abstraction constructively, as follows:

• Abstraction: The selection of important details within a particular context.

Our definition emphasizes that abstraction is a process of choice, of selecting those details that you consider to be important to the problem in question. All other details are automatically discarded.

These two definitions raise two important questions.

• How do we identify irrelevant detail?

• How do we identify important detail?

We can answer these questions by bringing in the concepts of the purpose of the abstraction and the utility of the detail. The purpose of the abstraction may be defined by the following questions.

• What are the goals of the abstraction?

• Who (or what) will benefit?

• What, specifically, are those benefits?

• How will we measure those benefits?

Abstractions must have at least one overarching goal, but there are usually several related subgoals. There are various formal ways to express these that we will look at later. Generally, there should be fewer than ten goals. If there are very many goals, then this probably indicates that you need different abstractions. We take it as axiomatic that there is a purpose to an abstraction only if there are specific, measurable benefits to identifiable parties.

We can define important details as those details that have utility regarding the purpose of the abstraction. Conversely, irrelevant details are those that have no utility regarding the purpose of the abstraction. This allows us to divide the set of details into those that are useful to the purpose of the abstraction and those that are not. We only include useful details, and we omit all those that are not useful. If there are any that we are unsure about, we omit them and add them back in if needed.

• The notions of purpose and utility together define a particular level of abstraction.

Take some time to consider the above definition. We know that a lot of business analysts and software engineers have a somewhat different view in which abstraction is often seen as making something fuzzy or vague. But this is simply not the case. Details are included or not included according to the purpose, but nothing is made fuzzy! A level of abstraction can, and must, be very precisely defined in terms of purpose and utility, and the “right” level of abstraction for a given problem is not arbitrary. It is precisely defined by the purpose.

However, if a level of abstraction is not precisely defined, then the whole model can seem fuzzy because you see a particular level of detail in one part and expect that same level of detail in another, but it is not there. This is a good test—if you look at a model of some sort and it seems fuzzy, then this is an indication that there are mixed levels of abstraction, which suggests that the purpose of the abstraction has probably not been well-defined or even consciously considered.

Defining the purpose of an abstraction is a step that is often overlooked. But if you have not defined the purpose of your abstraction, then, by definition, it can’t be fit for purpose. Nevertheless, we time and again see models (often UML models or business models) where the purpose of the abstraction was never defined or even thought about. Such models tend to be a mix of many levels of abstraction, and they satisfy no one. They may be too low level in some places and too high level in others, and while they can convey some useful information, they are more often just confusing. This is the sort of thing that has given modeling a bad reputation in some quarters.

The matter of levels of abstraction is in some ways quite a subtle matter that requires you to think deeply about what you hope to achieve from the abstraction. We think this is why programmers sometimes struggle with it. In programming, we learn to operate on a very specific and well-defined level of abstraction—that of source code—and we never really have to think about it. This level of abstraction is automatically checked for us by the compiler or interpreter and by tests. Moving up a level to analysis models can seem strange, as can moving down a level to assembler, because these are unfamiliar levels of abstraction that require us to think about the problem in a different way: to include fewer details in the former and more details in the latter. However, the mental agility to shift levels of abstraction will become more and more important as we move forward into Generative AI–enabled software engineering. The ability to operate, often simultaneously, at different but well-defined levels of abstraction will become a necessary skill. Generative Analysis has many tools and techniques, which we will present shortly, that will help with this.

Similarly, business analysts, who are often used to working at a high level of abstraction at the level of business concepts, may find the lower level of abstraction required by Generative AI difficult. This is because it requires much more attention to details that business analysts typically abstract away. It is no longer adequate to talk about things in general terms. Models must be made precise enough so that a Generative AI can turn them into code. We believe that training in modeling, using a formal modeling language such as UML, needs to be part of the toolbox of every business analyst so that they can learn to express their ideas more precisely.

Here is a useful metaphor that might help you understand levels of abstraction. Based on nlp and General Semantics, we can define an abstraction as follows:

• Abstraction: A partially complete map that maintains sufficient similarity to the territory to be useful in a specific context.

In some ways, this is our favorite definition. The map metaphor allows us to form a mental image of the definition, which is fun and useful. The “specific context” emphasizes that the map, the abstraction, has a purpose.

1.4.1 Limits on levels of abstraction

In experiments, Pavlov found that dogs can probably abstract to, at most, two or three levels [Pavlov 1]. He explored this by using a signal (a bell) just before his dogs were fed and noting whether they salivated and so on. He found that the dogs easily associated the signal with food and would then respond when they received the signal, even if no food was forthcoming. This amounts to one level of abstraction:

He then went on to experiment with stacking different signals as follows:

He found that dogs could respond to, at most, two or three levels of abstraction, and then the chain of association was broken. It is difficult to interpret this, but one interpretation is that dogs can only abstract to two or three levels at most. So abstract algebra (for example) is out of the question.

Unlike dogs and, we assume, most other animals, human beings can abstract to much higher but currently unknown levels. Korzybski has suggested that it is this ability to abstract to apparently arbitrary levels that is the feature (along with time-binding) that most distinguishes humans from other animals [Korzybski 1]. This ability to abstract enables us to reason about the world, to reason about reasoning, to perform mathematics, to construct OO models, to create software systems, and to create Generative AIs. The human mind could be called a self-modifying abstraction machine. The Generative AIs available now (May 2023) appear to be self-modifying prediction machines. It is a crucial difference, and might be the difference between AI and AGI (Artificial General Intelligence).

This experiment also shows that the process of abstraction generates feedback. Our higher-order abstractions influence lower-order processes, and the process of abstracting itself. Thus, words can change minds and can influence perceptions, feeling, and thinking; can affect physiology; and can cause us to act. This process is illustrated in a simplified form in Figure 1-1. In extreme cases of deep trance or mental disorder, words can even generate hallucinatory abstractions leading to maps that are detached from the objective level.

Figure 1-1 Simplified view of abstraction as a feedback/feed-forward mechanism

1.4.2 Example of abstraction

Here is an example of abstraction that anyone can understand and that has nothing to do with software engineering. We will return to the London Underground. We want to create a map of the London Underground network that will enable passengers to navigate via the tube from station to station. (By the way, you can easily substitute your own local public transport network here, and the example will still work.)

We already have very detailed maps of London that include the tube stations, so what is the purpose of this abstraction? We can define the purpose as follows.

• What are the goals of the abstraction? To allow passengers to navigate from station to station using the tube network.

• Who (or what) will benefit? Passengers on the tube network.

• What, specifically, are those benefits? They will be able to navigate from station to station. They will be able to plan journeys. They will be able to see where there is wheelchair access.

• How will you measure those benefits? Ten passengers will be given a copy of the map and asked to make ten journeys each. They will then rate the map on a scale of 1 to 10 for readability, ease of navigation, and ease of journey planning. Each passenger will also be asked to identify on the map all stations that have wheelchair access.

The purpose is well-defined, so we should be able to get a good result. There are two ways to create the desired abstraction. We can start from a very high level of abstraction and add details to get more concrete, or we can start at a very low level of abstraction and remove details to become more abstract. Both approaches are valid and, if done correctly, should get us to the same result.

We will start at a very high level of abstraction, a mathematical graph, which is an entity with nodes that represent each station and edges that represent tube lines. We abstract this information from a geographical map of London. Is this map useful? Not really; we have omitted the names of the stations and lines, so we can’t use it for navigation, and we have omitted wheelchair access. Moving down a level of abstraction, we decide to include the names of the stations and lines and an indicator for wheelchair access. This is now usable, but we have not specified how the stations and lines should be arranged on the page (in mathematical terms, its embedding in 2D space), so it could be very difficult to read because there are many possible layouts. Moving down another level of abstraction, this is the London tube, so we might think that the layout should, if possible, mirror the actual geographical relationships. Oh no! This is too concrete. The map is a mess—some stations are clumped together and some are miles apart. The whole thing is unreadable. We have gone to too low a level of abstraction. If we move the level of abstraction up a bit, and lose most of the geographical information, we can arrange the stations so that they correspond roughly with the overall shape of London, but the layout is neat enough to be usable. Testing shows that the map scores low for readability because overlapping lines are all the same color. We add more detail by color coding each line.

This is an example of abstracting as a constructive process that lowers the level of abstraction by adding details (see our definition above). However, notice that at one point we went to too low a level of abstraction and had to move back up a bit. This is very common, and you should expect to have to do this a lot.

We can also work at abstraction from the other direction, by starting at a very low level of abstraction and suppressing details. We start with a complete map of London, including all the streets, buildings, tube lines, stations, and everything else in their correct geographical relationships. We then go up a level of abstraction and remove everything that is not relevant to navigating the tube. This leaves us with the tube lines, the names of the lines, the stations, and the names of the stations. At this point, they still maintain their geographical relationships, and the map looks a mess because there are very long distances between some stations and very short distances between others. Moving up another level of abstraction, we can lose the actual distances between stations and make them all separated by about the same amount. The map looks a bit better, but it still looks untidy and is hard to read. Moving up another level of abstraction, we lose more of the spatial relationships between things and move stations and lines around a bit on the page to make the map readable. Testing shows that we have omitted indications of wheelchair access because this was not included on our original geographical map of London. We move down a level of abstraction by adding this detail. Testing shows that the map is hard to read because overlapping tube lines are all the same color. We go down another level of abstraction and add the detail of color coding the lines. The map is now fit for purpose.

This is an example of abstracting as a subtractive process that raises the level of abstraction, as defined in ISO 10746-2. Notice that at two points we had to go down a level of abstraction, first to add wheelchair access and then to color code the lines.

Interestingly, both approaches to abstraction end up at pretty much the same place, which is where Beck ended up in 1931 when he created the tube map based on the metaphor of a circuit diagram (we will discuss metaphor later!). Metaphor can be a powerful way to generate ideas for how to abstract something. For example, Beck used the metaphor “the London Underground is like an electrical circuit” to come up with abstraction mechanisms to create the tube map we know and love. To us, the Beck map is wonderful! It is an inevitable and seemingly unavoidable attractor in the space of map abstractions that virtually all tube maps in the world have been drawn to.

1.4.3 Quantitative abstraction and qualitative abstraction

In the above example, you might have noticed that there were two different things going on. The first was a very simple process of adding or removing detail from the map. The second was a more complex process of changing the nature of the map by altering its geometry. We like to think of these processes as different types of abstraction.

• Quantitative abstraction: The addition and removal of detail; for example, removing streets. Quantitative abstractions can be ordered because there is a metric: the amount of information added or removed.

• Qualitative abstraction: Where the abstraction moves to a different level of organization; for example, changing the shape of the map and the relationships between things so that normal geometric intuitions no longer apply. This forces us to view the map on a more abstract level, at a different order of knowing. There is no universally agreed metric, so levels of quantitative abstraction admit to no particular ordering.

Although we speak of “levels of abstraction,” and this generates the mental image of things stacked on top of each other, it is difficult to order qualitative abstractions, because there is no obvious metric. Any ordering is necessarily subjective. For example, if we consider the paintings Composition VII by Wassily Kandinsky and Broadway Boogie Woogie by Piet Mondrian, there is no doubt that they are clearly on different levels of qualitative abstraction, but it is entirely subjective as to whether one is more abstract than the other.

We think a lot of confusion about the concept of “levels” of abstraction is that abstraction is a multidimensional term with at least these two dimensions of meaning. In quantitative abstraction, the levels are distinct and ordered because there is a clear metric. In qualitative abstraction, the levels are distinct but not necessarily ordered, because there is no obvious metric.

1.4.4 Our cat doesn’t understand abstract algebra

We might reasonably ask whether there is a limit to the human ability to abstract. We don’t know, but we observe that if an animal’s abstractions are pretty much at the objective level, largely about things and events, then our abstractions are also at that level as well as at the level of stories about things and events. There is no meta-level here because stories about stories are just stories. But what if there are “truths” that can’t be expressed as stories? This might indicate levels of qualitative abstraction above our own that are not accessible to us, just as abstract algebra indicates levels of qualitative abstraction that are not accessible to a cat.

There are hints that this may be the case. For example, in physics, the double-slit experiment still does not submit to a logically coherent narrative, even after all these years [Lincoln 1] [Penrose 1]. In mathematics, Steven Wolfram has found, through brute-force search, the simplest axiom system for Boolean algebra. He says: “I made some attempt to understand it, but it was clear that it wasn’t something a human could readily understand.” Wolfram couldn’t tell a story about it, due to the “lack of human connection points,” and so it makes no sense even though it is mathematically correct and the simplest axiom system. He also notes that mathematicians have always selected certain theorems above others, at least partly because they fit into a narrative and make sense but the others don’t [Wolfram 1]. This tiny number of highlighted theorems are often mathematically no better or worse than the other theorems in what is a truly vast space of mathematical possibilities.

Nearer to home, in computer science, Generative AI may be indicating something similar. Although the mechanics of the software may be traced out exhaustively, nobody has yet been able to construct a narrative that explains how it works. It is sobering to think that such a narrative may not be possible because it requires an inaccessible level of qualitative abstraction. But of course, this must never stop us from trying. If we ever achieve AGI, perhaps it will eventually be able to operate at levels of qualitative abstraction that we can’t access, and we won’t be able to understand everything it does, even if it tries to explain itself. Nevertheless, we will continue to try to teach our cat abstract algebra.