Modeling & Abstraction at the very heart of Business Requirements Analysis

In between Business Engineers and IT Architects, how does a Business Analyst (BA) for requirements fit in? From industrial practice we know a BA definitely makes a lot of sense. So, now we try to conceptualise this extra benefit. As we’ll see, it’s mainly based on abstraction (and thus modeling).

Business and Technology perspectives

Say, your company performs the business tasks described in figure (BizTasks):

Biz Tasks. CEO vs Janitor.

If you asked the CEO what her company is doing here, she would say sth like “We send greetings and invoices”, where ‘send’ means write and ship it, since a CEO doesn’t care if it is performed in 1, 2, or more steps, she solely has the business perspective.

If you asked the janitor, or whoever may be responsible for the tasks’ infrastructure, he would say sth like “We write ‘stuff’ and ship it”. The essential difference for him is, that he has to provide the writers with, say, a typewriter and a pen, and the mail office with, say, envelopes, stamps and a mail box nearby, in other words he has the technology perspective.

So, now that we have the biz and tech views, what is the requirements analyst’s view on this? And, moreover, is an analyst just a bit biz and a bit IT person, or does an analyst’s view makes sense on its own?

How Abstraction makes the Business Analyst

Although the janitor’s view is determined by technology, it doesn’t contain any technology itself, i.e. it consists of biz concepts (completely understandable to the CEO) only. Such a view is pretty exactly that of a BA in software requirements analysis: providing the implementors with relevant information about the business, in a technology free way.
Thus, does the BA have to be a technology specialist, in order to state relevant requirements?

Not if the BA can use an abstraction that hides the technology details. Notice, that abstraction is more than just reduction. It also has a ‘practical aspect’ (Stachowiak), in plain words, the abstraction has to make some ‘sense’ in it self. This is why a BA is not just a half-and-half biz and IT semi-specialist. The abstracting nature of the BA’s perspective makes software requirements analysis a self-contained discipline.

Information System as the Abstraction of Choice

As practice shows the concept of Information System (IS) is a ‘quite good’ abstraction for software requirements. For our purposes, by an IS we mean a system of information flows among participants. Moreover we assume an IS to be analytic, not designed, i.e. extracted from the world (by abstraction), not constructed into it. There are various definitions of IS* that are more or less all come down to data, functions, and interfaces.

In other words, analysis of software requirements means describing the world in terms of data, functions, and interfaces. No need of technology knowledge – in theory, of course. In practice some tech and biz knowledge is required as well, however the core competency – in which the BA differs – is the capability of abstracting (and thus modelling) the IS from the business. Also notice, that this is far more than just the ability to ‘think analytically’ often found in BA job ads.

So, remember: If you do not abstract, it is not analysis.

So long

* textbook e.g.: Antoni Olive (2007) Conceptual Modeling of Information Systems.

For now, of course the open issue left, is a closer look on how an IS fits the above purpose.

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

Software Requirements Analysis: From the Art of Tidying Up to the Art of Abstraction

Requirements analysis is more than just tidying up, it’s about understanding the complexity of structures. An explanation inspired by the art of Ursus Wehrli:

Is Requirements Analysis just a kind of Tidying Up?

Recently I discussed with some project responsibles, the option to use an issue management system (namely JIRA) for gathering software requirements. The people obviously thought of requirements as a big set of snippets, that have to be collected and ordered, very much like a stamp collection. This seems to be a common misunderstanding of the nature of requirements, which can be elucidated nicely by the art of Ursus Wehli.

Ursus Wehrli is a Swiss comedian and artist, who makes books in which he “tidies up” works of art, for example, sorts the elements of a Kandinsky painting by colour and size, or orders the letters of an alphabet soup alphabetically. (more here: NYT)

Why Tidying Up is not enough

Let’s picture this little Wehrli-forgery here, a unjumbled version of a public transport map:

wehrli zürich tidyIt has lines (heavy for city trains, double for long distance), station names and station nodes. So, what is missing? What exactly makes the difference to a complete map? Obviously, it’s the relationships among the map elements that are missing here.

However, since the elements can still be classified and ordered, there must be some relationships left, determined by the elements’ properties. In this kind of representation they are made explicit, such that it becomes easy to ‘query’ e.g. if there is a station named ‘Opfikon’, or what line is the longest. Thus, simplification by ‘tidying up’ also has certain benefits.

Why Managing Relationships is not enough

wehrli zürich relationSo, why not simply add the relationships to the list, as in (Public Transport related)? It defines the relations name to station node, and station node to line, with station nodes identified by numbers 1 to 11.

So, technically all information would be available. However, for humans it’s still too hard to deal with. The relationships are now manageable by the system, but they are not yet expressed in a human-oriented notation. This is why an issue management system (IMS) is not enough to deal with requirements, even if it’s capable of managing relationships. An IMS’ focus is on sorting and grouping things, for example to make a todo-list of requirements, or to support the management of the analysis process.

And why even Visualisation is not enough

wehrli zürich transport mapFor the typical use of a public transport map, a diagram as (Public Transport) is certainly appropriate, i.e. the human understandability can be accomplished simply by choosing an appropriate notation. And even if the lines and stations become just more, we simply can increase the size of the map. However, if the structure gets more complex, i.e. the elements are ‘closer’ related, diagrams quickly become hard to understand. Visualisation scales well concerning size, but not concerning complexity.

Visualisation of relationships is usually what modelling tools are good at. However, as we have seen the tidy perspective has its advantages, too. Thus, beyond visualising the modelling results (i.e. diagrams), modelling tools should provide ‘tidy’ perspectives (like an IMS), in order support the modelling process. In other words, working out models is more than just documenting them.

Abstraction for Analysis

wehrli zürich airportIf things get more complex – just think of a map with a more complex system of stations and lines (trams, etc) – it might become beneficial to create views on the model, e.g. all available lines from the airport, as in figure (Airport Transport), with connecting lines indicated at each station. Similarly, think of a requirements model of a whole software application, decomposed into data, use-case, state, etc. views/ diagrams. This goes beyond visualisation, this is about abstraction. Thus, as compared to the ‘art of tidying up’, choosing appropriate views on a model, in order to understand its complexity, constitutes the ‘art of abstraction’ (so to say).

By the way, this is also what distinguishes modelling from simple drawing tools. (Just in case, the next project wants to do requirements analysis with VISIO)

So long

Notice that additionally to the relations in (Public Transport related) the diagram (Public Transport) contains the coordinates of the stations. Although, they are only schematic, they provide an approximate geographical location information.
Ursus Wehrli

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

Modelling with Classes: Square and Rectangle revisited

Classic problem in class-modelling: how to express that a square is a special kind of rectangle?  Practically the best approach is in general to refrain from subclassing and add a boolean method isSquare() to the rectangle class instead.

In order to deepen understanding, let us scrutinize the situation a bit closer here, using logical/ structural foundations of modelling:  Undoubtedly, Square is a subclass of Rectangle, since all squares constitute a proper subset of all rectangles. This could be simply describes as:

(R1) Rectangle: real a, real b, {a>0}, {b>0}
(S1) Square: real a, {a>0}
A method area() would look like: a * b in Rectangle and a² in Square.

However, additionally we have the challenge of inheritance, that is, we want to obtain the description of Square by just extending the description of Rectangle. This is not satisfied by the solution above, since Square drops the b. Notice, that we talk about just the description of the classes here. Their extensions (rectangles and squares) remain unaffected. Of course, one could specify it like this:

(S2) Square: real a, real b, {a>0}, {a=b}
But here b is redundant and e.g. area() could be a * b or a² arbitrarily.

Thus, for a subclass Square we can choose to drop inheritance or accept redundancy. Now, inheritance is a very desirable feature.  For example, it allows the area() method of (S2) to remain unchanged in the Square class.  Just imagine, how confusing developing would become, when subclasses exhibit methods of superclasses differently structured or named.

This is why it’s recommendable to accept redundancy for the benefits of inheritance here. To implement this either by a subclass Square, as in (S2), or inside the Rectangle class, as with an isSquare() method, is left to practical considerations.

So long

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

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 , , , , , , , , , , , , , , , , , , | 3 Comments

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: 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

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, Requirements, 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 , , , , , , , , , , , , , , , | 5 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

Modeling for Understanding and/xor/etc Execution

Inspired by the discussion on “Executable models are models or programs? (and does it matter?)” on Modeling Languages.

Say, we have a list of a few thousand requirements, each nicely and precisely formulated e.g. like this*:
(1) p∈Personc∈Car drives(p, c)

From a purely logical perspective, we would be fine, since such sentences can be processed by e.g. a model checker in order to check its logical qualities etc. However, from a human point of view, such a list of requirements is impossible to understand, e.g. to discuss with the requirements provider. Therefore, describing the requirements in a restricted, easy to visualize language, i.e. modeling, is very helpful. For example, think of the above sentence as part of an ER-diagram. Thus, modeling solely for the purpose of understanding can have a value.

An even larger value could be achieved if the same models were used for understanding and generating (other models or code) or even direct execution. This is the big promise of various tool vendors and language standards. Due to the nature of their interests (perhaps) they appear quite reluctant towards certain practical difficulties that come with such an approach.

ER Tree and Org ChartThe following example is inspired by a software project situation I recently encountered. Say, we develop a database application that holds the organization structures of companies. They are all assumed as hierarchical, i.e. tree-like. So, firstly, we model a general tree structure as an ER model, as in (er-tree). For example, every r must have leafs l in L or forks f in F. Every such f must have further forks or leafs, until all leafs are reached (the 1:… cardinality guarantees that it’s acyclic). Secondly, we enrich this solely structural model with some business specific properties, as in (er-org). For example, the team entity type inherits the structural (tree) properties from the board, but not its business properties, so we have to put the latter into a subclass of R, Board.

Now, say, you are the requirements provider from the business side, how would you think of an org chart? Certainly, not like this. In general, it is definitely no bad idea to establish a common language of discourse between analyst and requirements provider, even if it is new to the latter. This is always a trade-off between effort of getting used to it and benefit for communication and thinking. However, models like the above clearly push it too far.

Thus, we have two concerns in the application domain, precision of processing towards execution, as well as ease of understanding towards the requirements provider. In simple development approaches, we can perhaps use a simplified model for the customer, and maintain the actual model manually ‘behind the scenes’. However, a sophisticated approach – as executable modeling – should be able to handle a consistent mapping between the two, as it does between business and architectural concerns – at least if it wants to go the whole (ambitious) way, from biz to exe.

So long

* If you don’t like the first order logic, you may think of it in natural language.


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

Splitting the Requirements Atom

Requirements should exhibit, besides their logical properties (correct, complete, consistent, unambiguous), further important qualities. Atomicity is one of them. When is a requirement said to be atomic? For example, can (1) a = 21 be an atomic requirement? Well, it could be split into (2) a ≥ 21 and a ≤ 21 or even worse into (3) a is odd, a is not a prime, a > 15 ∧ a < 25 Does that mean (1) not atomic? In requirements literature there are lots of statements like: “A requirement is not atomic, if it can be split into more than one requirement.”, but nothing rigorous (as it seems). Alternatively, can the atomicity concept from logic take us further? Logically, a requirement is a sentence, i.e. they evaluate to either true or false. In particular, an atomic sentence is a formula that doesn’t contain any logical symbols (and, or, not, quantifiers) and thus no variables. However, with requirements we want to express properties on the class level (Boy loves Girl), usually not for single instances (Abelard loves Heloise). So, the atomicity concept from logic is not sufficient for requirements. Perhaps it can be expanded in a reasonable way? Worth to think about. Fortunately, the above example contains only a constant a, such that the atomicity concept of logic applies without modification. This leaves us with 2 kinds of atomicity: 1. the logical one, s.t. a=21 can be called atomic. 2. the ‘atom splitting’ one that divides = into le, ge, s.t. a = 21 could not be called atomic. How do these 2 interpretations relate to each other? Are they contradictory? Atomicity in 1 and 2 is compatible if = seen as an abstraction of ≥ and ≤. This means, they are statements on different abstraction levels, and since it makes lot of sense to picture requirements on different levels of abstraction separately it is perfectly reasonable to call a = 21 atomic. For example, Use Case Diagrams are a perfectly reasonable way to describe functional requirements, although they do not contain all details. Notice, that in addition, higher abstraction levels often use reduced language, that makes it impossible to express the details anyway, as in the = and Use Case Diagram example. Thus, a = 21 can be called atomic, with respect to a certain abstraction level, and can also be split into details, like a ≥ 21 and a ≤ 21. Such details on rock bottom level are sometimes called atoms, too (e.g. by Robertson & Robertson). So long |= PS Open Issue: can the logical atomicity be broadened to a useful concept in requirements?

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

What kind of Computer Science matters?

Just came across Why Computer Science Matters? by Vugranam Sreedhar. He observes a decline in real computer scientists in favour of ‘commodity programmers’. Basically, I have to (sad but true) agree here, and would like to take a closer look at the roles involved, beyond well-trained computer scientists and commodity programmers only.

Let us recapitulate first*: In general, Information Systems (IS) perform 3 kinds of functions:

  • Memory function: maintain a representation of the state of the domain
  • Informative  function: provide information about the state of the domain
  • Active function: perform actions that change the state of the domain

Algorithms like a solution to the 8-queens problem provide complex kinds of active functionality.  Whereas a typical database application mainly provides memory and informative functionality.  Database applications (in all kinds and variations) are typical for business software. Developing them, can be broken down into structuring the overall problem, and implementing the resulting parts. Clearly, here the overall structuring is the much more ambitious task.  Thus, we get 3 kinds of people:

  • Software ‘Scientist’, solves complex algorithmic problems (focus on active functionality)
  • Software ‘Craftsman’, implements data access functionality and mid-complex business logic (focus on single memory and informative functionality)
  • Software ‘Engineer’, structures large data centric information systems (focus on overall memory and informative functionality)

Now, if we compare SwScientits and SwEngineers, although they are both jobs on an academic level, they are clearly of a different kind. Metaphorically speaking, SwScis solve a single small very complex word problem, whereas SwEngs take a very large text and break it down into many word problems of medium complexity.

So how did we get to focus so much on educating SwCraftsmen?** Was it perhaps that academia used to educate SwScientists only? Of course, if one asks industry, they say, they want ready to employ people, and they want them quick, and also a lot of them.*** And finally, did academia start to deliver SwCraftsmen, where actually SwEngineers would have been appropriate?

So long

PS: Related stuff: Craftsman or Engineer?, Word Problems they don’t teach you in School.

* textbook: Antoni Olive (2007) Conceptual Modeling of Information Systems.
** or ‘commodity programmers’ (Vugranam Sreedhar)
*** best provided by vocational education?

Posted in Software_Engineering | Tagged , , , , , , , , , , , , , , | Leave a 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