Reflections on Abstractions: Roaming the Subsumption Continuum

Abstraction Awareness is about deeper understanding of abstraction, a concept so basic to human thinking. Subsequently abstraction is discussed by basic concepts of graph theory.

In the recent post we defined 4 cases of subsumption. In order to get from these basic cases to real world situations, we see the 4 cases as the corners of a ‘continuum’ A, B, C, D, and thus we get figure (subsumption continuum).

continuum of subsumption

Here the following areas – well known from graph theory – can be identified:

CC Connected Component

A connected component is a subgraph in which any two vertices are connected to each other by paths, and which is connected to no additional vertices in the supergraph.* This is what we get when we reduce the density of A, i.e. components become less obvious to abstract/model just by their internal composition alone.

CY Connectivity

The connectivity asks for the minimum number of elements (nodes or edges) which need to be removed to disconnect the remaining nodes from each other. A higher degree of connectivity is what we get when we increase the strength of A, i.e. components become less obvious to abstract/model just by their external relationships alone.

MO Module

In a module all members have the same set of neighbors among nodes not in the module. This is what we get when we add edges to C, i.e. the abstraction/model of the class structure becomes a multi-level tree.

CL Concept Lattice

All formal concepts of a bi-partite graph constitute a lattice. This is what we get when we reduce edges from C, i.e. the abstraction/model of the class structure becomes a multi-level lattice.

EX Expander

An expander is a sparse graph that has strong connectivity properties. It is ‘quite’ hard to decompose by subsumption into classes or components. For this reason expanders are used to design robust IT networks etc.

Finally, we get E by reducing the edges in A and C and then joining them to a ‘cube’ that can not reasonably be structured by classes or components.

Thus …

we can take parts of graph theory for describing typical problem situations of abstraction. However, most of these parts of graph theory* do not address the issues of the actual abstracting mapping from original to model, as required for ‘modelling for the purpose of understanding’. This is what a theory of modelling should be about.

So long

* apart from formal concept analysis

Posted in Reflections on Abstractions | Tagged , , , , , , , , , , , , , , , | Leave a comment

Craftsman or Engineer?

A brief word on a practical software engineering issue:

A lot has been written on the differences between Craftsman and Engineer.  Recently I came across a simple example by Hofstadter & Sander, that nicely shows the basic difference in thinking. We start with a little exercise:

“Draw a square, a rectangle, a rhombus, and a parallelogram.”

Some people draw a solution as in (a), some draw solution (b).  Both are perfectly acceptable in their way:
shapes abstraction

  • With (a) you show your detail knowledge, of how the shapes are defined, s.t. you are able to give a typical example for each class.
  • With (b) you show your ability to abstract, of how the shapes are related to each other, s.t. you are able to give a special case valid for all conditions.

shapes concept lattice and context

The latter is an abstraction by constructing formal concepts, i.e. by deriving the concept (lattice) from the (context). Imho, being able to ‘navigate’ the concept lattice – that of course looks much more complex for real world subject areas – is what separates the thinking of Engineer and Craftsman.

So long

For example, from my personal experience in business analysis I may say, that typically there are lots of people on the expert side with type (a) knowledge, so what they need an analyst (on engineer-level) for, is help them to create type (b) understanding from it.

Posted in Abstract Thinking, Software_Engineering | Tagged , , , , , , , , , , , , , , , , , , | 1 Comment

Reflections on Abstractions: Subsumption I

Abstraction Awareness is about deeper understanding of abstraction, a concept so basic to human thinking. Subsequently abstraction is discussed by the means of basic relational mathematics.

We’re going to look at a subsuming mapping from lhs original to rhs model. When we assume subsumption, i.e. non-lhs-uniqueness, a single rhs node in model ‘contains’ , i.e. is mapped from, 1..n nodes of original.

Two model nodes with no edge

subsumption 2 nodes 0 edgeNext, as in figure (no edge), we look at two rhs nodes a and b with no (rhs) edge amongst them. From no edge on the rhs we can derive that not all lhs nodes in node a have a (lhs) edge with all lhs nodes in b, else we would need a negation in the mapping rule to map from all-to-all edges on lhs to no edge on rhs. Among the remaining mapping options, the rule ‘no lhs edge iff no rhs edge’ is the strictest (the ‘opposite’ of all-to-all, so to say).

Moreover, in this case no edge among the lhs nodes of a and b would make no sense, since the abstraction could not be justified by the structure of the graph. Thus, the nodes of a and b must be connected amongst themselves. Again, we take the strictest case of all-to-all connection as in figure (no edge).

Two model nodes with one edge

subsumption 2 nodes 1 edgeNext, as in figure (one edge), we look at two rhs nodes a and b with one (rhs) edge amongst them. From one edge on the rhs we can derive that one lhs nodes in node a has a (lhs) edge with one lhs node in b, else we would need a negation in the mapping rule to map from no edges at all on lhs to one edge on rhs. Among the remaining mapping options, the rule ‘all-to-all lhs edges iff one rhs edge’ is the strictest  (the ‘opposite’ of no edge at all, so to say) .

Moreover, in this case all-to-all edges among the lhs nodes of a and b would make no sense, since the abstraction could not be justified by the structure of the graph. Thus, the nodes of a and b must not be connected completely amongst themselves. Again, we take the strictest case of no edge at all connection as in figure (one edge).


abstraction subsumption

… we get four cases of subsumption as in figure (strictest cases), which next can be developed into a continuum with the four cases as corner points.

So long

Or in terms of adjacency matrices:

4 cases abstraction by subsumption adjacency

Posted in Reflections on Abstractions | Tagged , , , , , , , , , , , , | 1 Comment

Reflections on Abstractions: From ‘Siamese’ Graphs to Concept Lattices

Abstraction Awareness is about deeper understanding of abstraction, a concept so basic to human thinking. Subsequently abstraction is discussed by the means of basic graph theory and formal concept analysis.

Lets bring the definition of abstraction by subsumption, i.e. of not always lhs-unique mappings, to life. We want to detect complete subgraphs in graphs and build an abstract graph (model) from them. Think of this as building components, where their elements are extremely tightly bound. Notice that this is stronger than ‘connected components’ of graph theory.

Abstraction by ‘Siamese’ Edge

roa complete graph rhs unique not rhs uniqueFor example

(rhs-unique) gives a pretty nice example of abstraction by subsumption, where rhs-uniqueness holds. We get two rhs nodes with an edge amongst them, that ‘survived’ the mapping.

(not-rhs-unique) – a kind of ‘siamese graph’ – leaves us with the choice to simply map the middle node to two different nodes, and then introduce an additional type of edge for ‘having common node’ (e.g. meaning ‘these two rooms have a common wall’) or to introduce any other kind of construct.

Abstraction by Concept Lattice

There is an elegant construct for bi-partite graphs (that correspond to an object – attribute, or extension – intension situation) from formal concept analysis:

roa complete graph bi-partite concept lattice(bi-partite) shows an example where nodes 1 and 2 together with a and b are ‘as complete as possible’ since they have all connections allowed amongst them in a bi-partite graph. This kind of completeness corresponds to a ‘concept’ in formal concept analysis.  Thus we can draw a concept lattice as in (bi-partite), with 1-3 as objects and a-c as attributes. Notice that the edges here are read from bottom to top as generalisations, i.e. we can completely refrain from object-attribute edges here (no mesh up as by the ‘having common node’ edge above).

So long

Posted in Mathematics, Reflections on Abstractions | Tagged , , , , , , , , , , , , , , , , , | Leave a comment

Reflections on Abstractions: Subsumptions and Omissions

Abstraction Awareness is about deeper understanding of abstraction, a concept so basic to human thinking. Subsequently we provide a simple visualisation of some basic concepts.

In addition to the recent posting Abstractive and Functional Mappings we provide a simple visualisation.  There we defined abstraction by subsumption as a not lhs*-unique mapping, and abstraction by omission as a not lhs-total mapping. This, and the combination of both to an ‘omsumption’ (excuse the word), is illustrated below.

abstraction subsumption omission

So long

* lhs = left hand side

Posted in Mathematics, Reflections on Abstractions | Tagged , , , , , , , , , , , , , | 1 Comment

Reflections on Abstractions: Abstractive vs Functional Mappings

Abstraction Awareness is about deeper understanding of abstraction, a concept so basic to human thinking. Subsequently abstraction is discussed by the means of  basic binary relation theory.

From Bijection to Function

We consider mappings from and to nodes of graphs from a domain lhs to a codomain rhs. The most trivial mapping is the 1-1 mapping, where each lhs node has exactly one rhs node, and vice versa. In mathematics this is said to be a bijection.

Such a bijection can be generalised, by dropping some of its properties. Therefore, we apply the four basic properties of binary relations*:

1. lhs-total, i.e. every node in lhs is mapped to rhs
2. lhs-unique, i.e. every node from rhs is mapped from max one node in lhs
3. rhs-total, i.e. every node in rhs is mapped from lhs
4. rhs-unique, i.e. every node from lhs maps to max one node in rhs

Thus, the most specialised concept is the bijection, having all four properties. A more general concept is that of a function, where just properties 1 and 4 must always apply, i.o.w. 2 and 3 MAY be dropped.  Functions are a pretty useful concept in mathematics and its applications. However, as we will see next, for describing graph-to-graph abstractions, other combinations of the properties 1 to 4 are more suitable.

From Bijection to Abstraction

In a graph-to-graph mapping the absence of the four properties can be thought of in the following way:

1. Not lhs-total: a ‘deflating’ mapping by picking certain nodes and omitting others. Examples: all leaf nodes of a tree;  all business process steps with an external interface.

2. Not lhs-unique: a ‘deflating’ mapping by subsuming nodes of lhs in rhs. Examples: the concept of connected component in graph theory; structuring an object-oriented class model by building components.

3. Not rhs-total: an ‘inflating’ mapping, adding extra nodes to rhs, not mapped to from lhs. This can be thought of as adding a new context to the lhs. Examples: adding a ‘bottom node’ to a taxonomy s.t. it becomes a lattice; Adding dots to a drawing s.t. the shape becomes clear, a popular kind of puzzle.

4. Not rhs-unique: an ‘inflating’ mapping, that splits a node from lhs into two or more nodes in rhs. In some way this reveals the ‘internals’ of the node. Examples: two nodes from one (e.g. if it belongs to two cycles or 1 node incoming, 1 node outgoing edges); wall belonging to two rooms (which is also not lhs-unique)

Thus, in order to achieve the (strictly) reductional property of an abstraction, property 1 or 2 (or both) MUST be dropped. We suggest to call a not lhs-total mapping subsuming, and a not lhs-unique one omitting abstraction.  Whereas dropping properties 3 and 4 each constitute a reverse abstraction, i.e. ‘inflating’ from lhs to rhs, and ‘deflating’ from rhs to lhs. Notice that subsuming functions may exist (props 1, not 2, 4).

Thus …

we can see that the concept of function is less important here. Central to abstraction, and thus to relational modelling, are the concepts of subsumption and omittance. Look here for an illustration. In other words, not lhs-total and/or not rhs-unique is the necessary property to constitute an (non-trivial) abstraction.

So long

* basic properties of binary relations:

Posted in Mathematics, Reflections on Abstractions | Tagged , , , , , , , , , , , , , , , | 3 Comments

What can Software Modellers learn from Innovation Methodologies?


Recently I came across this HBR (Harvard Business Review) article A Taxonomy of Innovation on the Luma institute design methodology. It contains three categories of techniques to help innovators develop products and services: Looking, Understanding, and Making.  From my viewpoint as a modelling theorist especially the ‘Understanding’ part seemed quite similar to  what software modelling for the sake of understanding (e.g. as in requirements analysis) is about.

Subsequently, I take a closer look at the techniques that this methodology provides for gaining a better ‘Understanding’ of what users want. It is hoped to gain inspiration and ideas for software modelling (esp. modelling of requirements).  The innovation methodology comes with assistance and description of collaboration, notation, and the logical structure for each of the single techniques. As a modeller I focus mainly on the structural aspects.


Some techniques like Persona Profile or Importance/ Difficulty Matrix are quite generic and are already successfully in use in software modelling and/or engineering. However, others like Affinity Clustering or Concept Mapping strongly underestimate the structural aspect. They are not aware that structures grow over 1-sheet size, have dependencies, or change during the project.  The techniques simply do not deliver the promise to  scale with ‘the complexity of the systems in which you operate’.

Overall, there is nothing to learn for software modellers concerning structures. However, for collaborative aspects one or the other detail might be worth considering. This is not surprising, since the Luma methodology is almost solely focused on notation and collaboration, whereas software modelling is mainly focused on structure.

However, vice versa, innovation methodologies, like the one considered here, could strongly benefit from the structural thinking in software modelling. This would make them able to scale large and complex structures and handle their changes over the product life-cycle.  In other words, making the step from sketching to modelling.

Why are results from software modelling not considered by other disciplines?  Why does no one come around asking software people for help on structural issues? Are software people mainly seen as technology guys, due to the public unawareness that informatics/ computing is a structural science?


Part I: Patterns & Priorities
Part II: People & Systems
Part III: Problem Framing
More detailed descriptions of the single techniques can be found in the article

Part I: Patterns & Priorities

Affinity Clustering

Affinity Clustering‘A graphic technique for sorting items according to similarity.’

As we know from modelling theory (see here) we can structure things basically by their attributes, internal or external relationships or any combination of it. Here, it remains unclear which way is intended. So you are likely to end up wondering where to put the engine:  as part of a car or in the group of engines. In other words, sorting things is more complex, than just putting things into buckets.

 Bull’s Eye Diagramming

 ‘A way of ranking items in order of importance using a target diagram.’

We all know what happens when we ask a customer for a prioritization:
Everything is prio A. There are several ideas to address this, however none can be found here.

Importance/ Difficulty Matrix

Importance Difficulty Matrix‘A quad chart by placing items by relative importance and difficulty.’

In software engineering this is the basic chart for any testing strategy. However, since testing moves more and more towards the early stages of the software process, starting a 2-dimenisnal ABC analysis of this kind already during requirements analysis is certainly no bad idea.

Visualize the Vote

‘A quick poll of collaborators to reveal preferences and opinions.’

Analytically this is about creating views and understanding viewpoints. This always should be approached in two ways: collaboratively, by involving people, and structurally, by systematically creating perspectives on the subject matter (typically in software engineering these involve user, architectural, management perspectives etc). Unfortunately, this method here omits the structural way completely. Typically, this leads to underrepresentation of stakeholders not directly involved in the development process, like users or operators.

Part II: People and Systems

Concept Mapping

Concept Mapping‘A way of depicting the relationships between various concepts in a given topic area.’

Entities with relationships – great idea! :o)
However, as we know from modelling theory, when the number of entities increases some methods for structuring, like modules or generalisation can become very helpful.

 Experience Diagramming

Experience Diagramming‘A way of mapping a person’s journey through a set of circumstances or tasks.’

This can be done for example on classifier level, as use case, or on instance level, as test case. However, when you have a lot of them, the question of keeping them consistent remains unaddressed.  see here

Persona Profile

‘An informed summary of the mindset, needs, and goals typically held by key stakeholders.’

In software development techniques like this come in on the needs level (to understand where the requirements ‘come from’). This can be very useful, especially in consumer software development.

Stakeholder Mapping

‘A way of diagramming the network of people who have a stake in a given system.’

Also in software development, a very useful thing to do, for people having a stake in the final product as well as in its development process.

Part III: Problem Framing

Abstraction Laddering

Abstraction Laddering‘A way of reconsidering a problem statement by broadening or narrowing its focus.’

Asking for the why and how of requirements is a familiar technique in software engineering, for example by modelling business processes or prototyping.

Problem Tree Analysis

‘A way of exploring the causes and effects of a particular issue.’

In software, functionality maps effects to causes (plainly, input to output), and thus software modelling knows a variety of techniques of structuring like classes, components, and interfaces.

Rose, Thorn, Bud

‘A technique for identifying things as positive, negative, or having potential.’

A pretty generic technique. Like with the ‘Visualize the Vote’ technique, it is just collaboration based, no structural support offered.

Statement Starters

Statement Starters‘An approach to phrasing problem statements that invites broad exploration.’

This is a bit like textual entity relationship modelling. Of course you can write down ‘Person drives Car’, but how do you keep the overview of a larger amount of sentences if not by modelling? This makes it more an elicitation than a modelling technique (similar to user stories).

So long

Posted in Abstract Thinking, Model Thinking, Software_Engineering | Tagged , , , , , , , , , , , , | 2 Comments

Reflections on Abstractions: The Use Case trade-off

Loosely collecting examples of abstractions on finite relational structures:

Relational World

relational abstractionIn the posting Adjacent Rooms we had an abstraction as in figure (abstraction by ‘is related’), a mapping with the structural unsatisfactory property to be non-unique on the model-side, e.g. the ’2′ in the original is mapped to 2 different nodes in the model. However, we also saw an example where this sort of abstraction fits quite well, and thus speaks in favour of the relevance of this kind of abstractional mapping.

Real World

request processinguse cases request processingAnother such example is the abstraction of functionality by Use Cases. Figure (Request Processing) shows a simple process for handling customer requests, that can be of various kinds, like placing an order, a request for product information, or a change of the billing address. Think of the activities as nodes of a graph as above.

Now, the basic idea of a Use Case is to lump together activities such that they form an emergent behaviour (easy to comprehend). In figure (Use Cases) we have three of these. Obviously the Use Cases are overlapping, since e.g. the ‘Dispatch request’ activity is contained in all Use Cases, as well as ‘Send reply’ appears in ‘Update Static data’ as well as in ‘Request Information’ (indicated by the edges among the Use Cases). Thus we get better understandable (emergent) units of functionality, however usually for the price of a non-unique mapping.

Based on the elementary terms of relational structures, this shows the basic trade-off of Use Cases: emergence vs redundancy.


  1. The ‘extend’ or ‘include’ relationship in UML are typical elements to address this redundancy issue.
  2. Compare the kind of knowledge gained out of such a formal analysis as above to that you get from common text books on Use Cases. Moreover, seems that some very popular books, don’t address this trade-off at all (!?)

So long

Posted in Mathematics, Reflections on Abstractions, Software_Engineering | Tagged , , , , , , , , , , , , , , , | 1 Comment

Reflections on Abstractions: Adjacent Rooms

Loosely collecting examples of abstractions on finite relational structures:

Relational World

Relational abstractionFigure (abstraction by ‘is related’) shows an abstraction by subsuming directly connected nodes in the original into a single node in the model. An edge in the model indicates a common element of its nodes in the original. For example, the nodes 1, 2 become a single node (1, 2) that is related to e.g. node (2, 3) since they have the element 2 in common.

Real World

rooms wallsA practical case of such an abstraction is a structure of walls that is abstracted to rooms with the neighborhood relation, where neighborhood is defined by having a wall in common, as in figure (wall in common). For example, the bath (Ba) has walls in common with the bed room (BR) and the foyer (F).


  1. The abstraction takes into account only the relationships of the nodes. No further properties are considered.
  2. The abstraction is total on the original-side and not unique on the model-side.
  3. The model has more nodes than the original. Is this a contradiction to the reduction property of abstraction? I Don’t think so, since a reduction exists from two connected nodes to a single node. Other opinions?

So long

for an informal definition of reduction in the context of models, see Stachowiak

Posted in Abstract Thinking, Reflections on Abstractions | Tagged , , , , , , , , , , , | 6 Comments

Examples of Preterition and Abundance in Modelling

In addition to the earlier posting Stachowiak on Preterition and Abundance in Modelling here are some examples of Preterition and Abundance (also see here for all postings on Stachowiak):

Stachowiak Abundance Preterition Black WhiteIs this a black and white picture? Is this a colour image of a black/ white arrangement or a black/ white image of a coloured arrangement?  In the latter case, even if you want not to express the colour of the Original at all, you have to choose some colour for the image (here, the scale from black to white).

Stachowiak Abduction Use CaseWho triggers the Use Case? In UML the association between actor and use case is not allowed to have a direction. Thus, in order to express that an actor triggers the use case it are sometimes notated on the left hand side. So, the diagram could say that the customer triggers the use case or not. We cannot say, without any further information.

Stachowiak Maza LabyrinthWhat does the graph tell about the maze? The graph inside the maze preserves coordinates and path length. Also in the graph on the right nodes have coordinates and edges have lengths. However, they are not meaningful anymore. They were ‘sacrificed’ for the sake of a certain view.*

Notice that a lot of further questions apply in the graph on the right: does the top element represent the starting point? Is 1-2-4-6-8 a kind of primary path (typical issue in process models)? Is it better to have all edges of equal length, to indicate the abundance?

So far, just a few examples that came to my mind.

*Stachowiak gives a similar example in his book “Allgemeine Modelltheorie”. The book at Google books.

Posted in Epistemology, Herbert Stachowiak, Software_Engineering | Tagged , , , , , , , , , , , , , , , , , , | 5 Comments

Reflections on Abstractions in Relational Structures. The very basic Setting.

Abstraction Awareness is about deeper understanding of abstraction, a concept so basic to human thinking. Subsequently abstraction is discussed by the means of basic Graph Theory and Formal Concept Analysis.

A single unary relation R(x), can simply classify e.g. Naturals in evens and odds. This doesn’t take us very far.  So, they should be enhanced by either adding more unary relations or making the relation 2-ary, 3-ary etc.  Moreover, both can be combined to multiple n-ary relations. However, here we stick with the basic two cases, and adjourn the combined case until ‘later’.

fca-lattice-even-oddMultiple unary relations R(x), S(x), …, can describe complex property structures.  In the theory of Formal Concept Analysis, this is said to be a Context.  Now in order to handle the complexity of such structures by Abstraction, the concept of a Formal Concept proves very helpful.  All Formal Concepts of a structure provide a lattice, which helps us ‘understanding’ the structure.  Thus, in abstractional terms, Classification (by Formal Concepts) implies Generalisation (Concept Lattice). in detail…

graph-mod-cmpA single n-ary relation R(x, y, …), shows how the elements are related to each other.  Graph Theory provides two basic concepts here that describe Abstraction:  A Module (corresponding to the abstractional concept of Classification) lumps together all the nodes, that have the same edges to other nodes, i.e. appear the same to the outside, so to say.  A Component (corresponding to the abstractional concept of Aggregation) groups the nodes, closely connected to each other and loosely connected to the outside, roughly speaking.
Moreover, both, Modules and Components, can be sorted hierarchically, in order to simplify the ‘understanding’ of the structure.  Intuitively, I would call this Generalisation in the case of Modules.  However, for Components, the term ‘composition’ sounds more natural to me. in detail…

It is hoped, that this can provide a very basic setting for a deeper analysis of the nature of Abstraction.  Some questions arise immediately, like ‘how do formal concepts and modules fit together?’ (i.o.w. how can they be generalised?) or ‘what makes modules and components the outstanding concepts for abstraction?’ (i.o.w. what properties define the formal concept of ‘module and component’ in the context of abstraction?) etc.

So long

Posted in Mathematics, Reflections on Abstractions | Tagged , , , , , , , , , , , , , , , , , | 2 Comments

Reflections on Abstractions: Correctness and Completeness

Abstraction Awareness is about deeper understanding of abstraction, a concept so basic to human thinking. Subsequently, in strive for rigour, an earlier post on quality properties of models is compared to basic concepts of mathematical logic.

1. Correct and Complete, simply put

cc-custsysThe former post, gave a brief explanation what correct, complete, etc. means for models, as in the figure.  Where correct meant, no requirement in the model is wrong and thus every solution accepted by the customer (in C) is in accord with the model (in M) and complete is, no requirement in the model is missing and thus every solution according to the model (in M) is also accepted by the customer (in C).

2. The concept of a Formal System

In mathematical logic a formal system (FS) is a triple of a language syntax, a set of axioms and a resolution mechanism, for example, the syntax of first order logic, the axioms of the theory of equivalence relations, and the |- resolution operator, such that theorems can be derived from the axioms.

A structure that obeys such a FS is said to be a model. For example, for my red and white socks, being of equal colour defines an equivalence-relation.

A FS has at least one model if, and only if, it is consistent, i.e. the axioms are not self-contradicting, and thus can be fulfilled.

So, consistency assumed, the axioms define a set of models A, as well as any theorem defines a set of models T, and thus proving a theorem (by the resolution operator) comes down to show that the models of the axioms A are a subset of the models of the theorem T.

3. Correct and Complete, formally put

Now the above situation in a FS seems quite similar to that of a ‘customer system’: instead of written down axioms in some language, we have requirements, ‘hidden inside the head’ of the customer, that we have to explore by stating requirements (theorems). Instead of a resolution mechanism we have the customer itself, as a kind of oracle that answers our questions.

Thus, when a requirement is accepted by the customer it defines a superset of the accepted solutions (models), and hence is said to be correct. Correspondingly, if the requirements altogether define a subset of the accepted solutions (models), they are said to be complete. Thus, correct and complete, ensures that the stated and the accepted solutions are congruent (consistency assumed).

So long

Concerning ambiguity: if there is at most one model for the axioms in the FS, then together with consistency (at least one model), the model is said to be unique up to isomporphy (because maths is a structural science).

Posted in Mathematics, Reflections on Abstractions | Tagged , , , , , , , , , , , , , , , , , , , , , , | Leave a comment

Reflections on Abstractions: Cases vs Models

Abstraction Awareness is about deeper understanding of abstraction, a concept so basic to human thinking. Subsequently abstraction is discussed by the means of basic Finite Model Theory.

All finite relational structures can uniquely be described in First Order Logic (FO) up to isomorphy. This is quite pleasant, since FO is a relatively nice and simple language (for expressing queries, doing proofs, etc). For example, a structure consisting of a 2-elementary alphabet and a binary relation R (see figure) can be characterised by conjunction of the following sentences:
(1) there are exactly 2 elements
(2) for x≠y: R(x,x), R(y,y) holds, R(x,y), R(y,x) doesn’t
where both sentences can be expressed in FO (see here for formalism).

However, another way to characterise R is:
(1) as above
(2′) R is reflexive and empty else ( x=y ⇔ R(x,y) )
what is also expressible in FO.

Between the two axiom systems (I) and (II) there is an essential difference: While (I) lists all existing cases in (2), (II) uses the property of reflexivity (2′) to characterise the structure. The latter has certain advantages: it, can be expanded easily for structures of more than 2 elements, and it states a principle that can be understood by humans.

This describes by simple means of basic Finite Model Theory a very important principle in software engineering: modelling properties is more expressive than just collecting cases. This is the reason why test cases can be derived from specifications but not vice versa. Another example is Intentional Programming, addressing that the big picture ‘gets lost’ on the source code level.

Like most things in life, expressing properties by models also comes with a downside: While cases as in (I) can always be expressed in FO, properties in general cannot. For example, for expressing that the alphabet of a structure is always of even size, FO is not expressive enough.

Thus, altogether cases vs models is always a trade-off.

So long

PS for the ‘light’ version, see previous post

Posted in Mathematics, Reflections on Abstractions | Tagged , , , , , , , , , , , , , , , , | Leave a comment

Reflections on Abstractions: Generalisation and Aggregation

Abstraction Awareness is about deeper understanding of abstraction, a concept so basic to human thinking. Subsequently abstraction is discussed by the means of basic Graph Theory.

reflections on abstractionsA Component in Graph Theory is a connected subgraph ‘disconnected’ to the outside. For example, directed graph (1) consists of 3 components. This concept is basic but not very useful, since it does not allow connections among the components. For this reason, we are going to allow such connections and thus also need to generalise the notion of component, what can be done in (at least) two ways:

  • Generalisation: lump together all nodes that have the same edges to the outside, as in (2) (called “Module” in graph theory).
  • Aggregation: lump the nodes closely related, and losely related to the outside as in (3) (based on graph theoretical “Connectivity“).

By very simple means this provides the notion of two different kinds of abstraction: generalisational and aggregational. Whereat in aggregations all elements together make the interface (edges to/from the outside), in contrast to generalisation where one could pick any of the inside nodes to represent the interface.

Notice, as the above shows, aggregational abstraction is >not< a specialisation of generalisational abstraction, thus the existence of aggregational abstraction contradics the widespread understanding of abstraction as equivalent to generalisation.

So long

Posted in Mathematics, Reflections on Abstractions | Tagged , , , , , , , , , , , , , , , | 4 Comments

General Model Theory by Stachowiak

In his 1973 book “Allgemeine Modelltheorie” (General Model Theory) Herbert Stachowiak describes the fundamental properties that make a Model.  Unfortunately this is still only available in german language, so I thought why not try a translation of the essential bits:

Fundamental Model Properties

  1. Mapping: Models are always models of something, i.e. mappings from, representations of natural or artificial originals, that can be models themselves.
  2. Reduction: Models in general capture not all attributes of the original represented by them, but rather only those seeming relevant to their model creators and/ or model users.
  3. Pragmatism: Models are not uniquely assigned to their originals per se. They fulfill their replacement function a) for particular – cognitive and/ or acting, model using subjects, b) within particular time intervals and c) restricted to particular mental or actual operations.


  1. Mapping: Such originals can evolve in a natural way, be produced technically or can be given somehow else. They can belong to the areas of symbols, the world of ideas and terms, or the physical world. [...] Actually, every entity, that can be experienced (more general: ‘built’) by a natural or mechanical cognitive subject, can in this sense be considered an original of one or many models. Originals and models are interpreted here solely as attribute classes [representable by predicate classes], that often achieve the shape of attributive systems [interrelated attributes that constitute a uniform orderly whole]. The concept of mapping coincides with the concept of assigning model attributes to original attributes in the sense of a mathematical (set theoretical, algebraic) mapping.
  2. Reduction: To know once that not all attributes of the original are covered by the corresponding model, as well as which attributes of the original are covered by the model, requires the knowledge of all attributes of the original as well as of the model. This knowledge is present especially in those who created the original as well as the model , i.e. produced it mentally, graphically, technically, linguistically, etc in a reproducible way. Only then an attribute class is determined the way intended by the creator/ user of the original and the model. Here, an attribute class is an aggregation of attributes of the original as well as of the model side, out of the overall unique attribute repertoire. Thus, the original-model comparison is uniquely realisable. [...]
  3. Pragmatism: Beyond mapping and reduction the general notion of model needs to be relativised in three ways. Models are not only models of something. They are also models for someone, a human or an artificial model user. At this, they fulfill they function over time, within a time interval. Finally, they are models for a certain purpose. Alternatively this could be expressed as: a pragmatic complete determination of the notion of model has not only to consider the question ‘what of‘ something is a model, but also ‘whom for‘, when, and ‘what for‘ it is a model, wrt. its specific function. [...]
  • Stachowiak, Herbert (1973) (in german (DE)). Allgemeine Modelltheorie [General Model Theory]. Springer. ISBN 3-211-81106-0.

Have fun

Part II: Stachowiak’s K-System of Modelling

Posted in Epistemology, Herbert Stachowiak | Tagged , , , , , , , , , , , , , , | 18 Comments

Lecture Notes on Model Thinking I

Some lecture notes/ scribble on Model Thinking by Scott E. Page. Lecture Intro, Part 2: “Intelligent Citizens of the World”:

“George Box: ‘essentially all models are wrong, but some are useful’”

|=: Agree! Just a little everyday-obervation: it’s funny how often people use right/ wrong in the context of abstraction (i.e. models), not realising, without being ‘wrong’ (i.e. loosing details) it would not be a model. Such discussions usually start sth like this:
2 Rects
A:‘These are two rectangles!’ B:‘No, no, these are two essentially different things!’ … (sounds familiar?)

Have fun

Are you a hedgehog or a fox?: Try the quiz on Overcoming Bias
and this is Philip E. Tetlock: Wikipedia

Posted in Abstract Thinking, Model Thinking | Tagged , , , , , , , , , , , , | 17 Comments

Human centric Modelling

Some thoughts on Vincent Hanniet’s Agile & Modeling new way of life! :

If you ask people what concepts come to their mind when they think of modelling in software engineering, you usually hear things like “UML”, “Model Driven …”, “Autosar”, etc. Now these are big comprehensive topics, that one cannot handle without having spent some time getting into them.

In contrast, to me, modelling is a way of thinking, based on abstraction, a quite natural skill, and thus is also a quite natural thing to do for every human being, like when you’re abstracting the shape of the screen you’re just looking at as rectangular or using the word “screen” as a concept.

I do not say that seeing modelling one way is better than the other. Both are good to have. I see it like this: There is a modelling at the low-end, that all humans use every day a million times, and there is modelling at the high-end with comprehensive concepts like UML, MDD etc. Perhaps approaching the modelling topic from the low-end would make it easier accessible for most software practitioners.

Have fun

Compared to what has been published on UML, MDD etc, we still know very little about practical abstractional thinking in models, don’t we?

Posted in Model Thinking | Tagged , , , , , , , , , , , , , | 5 Comments

Are your Requirements complete?

No Analyst will ever can tell if the requirements are complete, however at least completeness can be approached by systematic analysis. The idea goes roughly like this:

Say you should tell all the Integers between 0 and 11, how would you approach that?
Bad way: “6, 3, 2, 1, 8, 6, 5 – so, that’s it or did I miss one?”
Good way: “1, 2, 3, 4, 5, 6, 7, 8, 9, 10 – bingo!” – for example.

Obviously the point is, to obtain an understanding the structure of the domain. Else it is just collecting facts. Finding appropriate systematics, I’d see mainly in the responsibility of the analyst.
Bad way: “Tell me all the integers between 0 and 11.”
Good way: “What’s the next integer after 0?” etc – for example.

To me this is already a basic application of modeling and its benefits.

Posted in Epistemology, Software_Engineering | Tagged , , , , , , , , , , , | 3 Comments

Why finiteness counts

Becoming aware of Finite Model Theory. Part 1 of n.

You arrive at a hotel, looking for a room. Unfortunately all rooms are occupied. Fortunately the hotel has countably infinite many rooms. So they move the guest of room 1 to room 2, guest of room 2 to room 3 etc so you can check in to room 1. (better don´t unpack your suitcase, in case the next guest arrives)

So compared to the real world the hotel doesn’t have to manage the occupation of its rooms, therefore it has to handle infinity, i.e. if one wants to deal with the above on a scientific level, one must be able to capture the concept of infinity formally.

Finite hotels (as well as ‘finite scientists’) don’t have to care about infinity; therefore they have to deal with the complexity of managing occupation. This can be done by keeping track of the number of empty rooms or by looking up all rooms for an empty one each time a guest arrives. The first approach is space consuming (since they have to write down the number empty rooms somewhere (i.e. space can be a piece of paper)). Instead the second approach requires time to go and check the rooms.

Thus there are two mutually exclusive things that can make occupation management interesting: infinity with all its ‘strange’ effects and the complexity (effort) of keeping track of ‘what’s going on’.

Or how Neil Immerman puts it: “In the history of mathematical logic most interest has concentrated on infinite structures….Yet, the objects computers have and hold are always finite. To study computation we need a theory of finite structures.”

Posted in Mathematics | Tagged , , , , , , , , , , , , , , , | 9 Comments

Modelling explained (to Journalists)

Party lines for software modellers #4312

In journalism dog bites man or man bites dog, makes a big difference. In modelling it’s the same entities with the same relation, just in different directions.

So long

Posted in Software_Engineering | Tagged , , , , , , , , , , | Leave a comment

Off Topic: Complexity Awareness in the Wild

From time to time I need a little rant for coming to terms with the daily madness in the  business analysis profession:

Once upon a time, there was a company that had many many employees, each equipped with a telephone. But, the employees complained: ‘it’s so hard to find out or remember another person’s phone number’.  So, the quality management department (QM) thought about this hard and finally came up with a revolutionary idea: ‘we take a big book and collect all phone numbers together with the person owning in it’. The budget was granted, the project was completed and every employee got a copy of the new book.

However, a business analyst (BA) asked back ‘why haven’t you sorted the entries, for example by surname?’ QM: ‘We have a great book with all numbers in it, so where’s the problem?’ BA: ‘explainexplainexplain…’ QM:’Well, sounds like a nice usability improvement, we put it on the list and probably address it as soon as we get additional funding.’ (i.e. postponed to never ever)

Sometime later the company expanded sharply. Suddenly the number of employees had doubled, and so did the time people needed to find a number in the phone book. So the following solutions were considered:

a)      Sort the phone book entries by surname

b)      Roll out a new technical device that does the looking up for them

c)       Define the looking-up process precisely, using the latest modeling notation

d)      Sort the phone book entries by numbers

Option a) Was favored by the BA, b) by IT, c) by QM, so they implemented d) as a compromise. However, finally, they saw this ‘sorting thing’ was no improvement, but quite expensive, therefore fired the BA and lived free of any complexity awareness ever after.

Any resemblance with companies living or dead …

Posted in Software_Engineering | Tagged , , , , , , , , , , , , | Leave a comment

Abstraction makes the Engineer

Just a brief note on abstraction in the professional world while reading [1]:

A simple example …

Say, you were given the following exercise [2]:

“Draw a square, a rectangle, a rhombus, and a parallelogram.”

Both solutions below, figures  (a) and (b) would be correct. With (a) you show your ability to abstract, with (b) your detail knowledge.

… and its practical relevance

solutionsNow take the profession of engineering (software, electrical, mechanical, …). Of course an engineer needs both of the above ways of thinking, (a) and (b). However, from my own experience I may say, what separates the engineer from the craftsman is clearly (a), the ability to abstract.

If you graduate from craftsman to engineer, the focus in education shifts from details to principles to enable you to understand the details, you have applied as a craftsman by convention or basic understanding, on a more abstract level. This is why civil engineering students have courses in physics and differential equations and studying software engineering involves complexity theory, logic and structural mathematics.

In practice applying such principles is required for doing things like handling the complexity of software by a proper architecture. In requirements engineering – understood as a common learning process of stakeholders – abstraction is essential for understanding and should not be confused with heaping loads of detailed descriptions. More general, abstraction is required to transform a single big problem into many small ones – an/the essential task of engineering.

So long


On the status quo of education: “a study we undertook in France showed that the majority of university and middle-school students are unaware of how some of these categories [square, rectangle, ...] include others, and many simply refuse to accept the idea that squares are rectangles or rhombi” [2]

Hofstadter Sander (2013) Surfaces and Essences
4. Abstraction and Inter-category Sliding
[1] Why Abstraction is central for Expertise
[2] Are Squares Rectangles?

Posted in Abstract Thinking, Software_Engineering | Tagged , , , , , , , , , , , , , , , , , | Leave a comment