MoDELS ’08: Abstraction, the neglected side of modelling

Jeff Kramer did a very interesting talk about abstraction in the first keynote of MoDELS ’08. He’d start with the question why some students are able to produce elegant designs and also comprehend complex distributed algorithms, while others can just apply patterns and don’t grasp the essence. He states that the heart of the problem is the ability to deal with abstraction.

What is abstraction?

In principle abstraction consist of two elements:

  • Simplify and focus (removing details)
  • Generalisation (core or essence)

Jeff gives a nice example of the London underground map. In 1930 the underground lines are visualized according to the actual curves and distances of the lines. However, the map isn’t easy to read. In 1932 Harry Beck came up with the first schematic image map, which just shows the essence, e.g. the underground lines and stations, without showing the curves and real distances. Nowadays each public transfer map uses this way of abstraction. One important thing: you have to mind the gap with reality. It’s not a map of London, distances between stations can be much longer than visualized (so don’t try to walk without looking at a real map). The message: fit for purpose.

Why is abstraction important in Software Engineering? Just because software is abstract. All kind of activities in Software Engineering have to deal with abstraction. For example:

  • Requirements: elicit critical aspects of the real world, neglect the irrelevant.
  • Design: avoid unnessary implementation constraints. Design is often done using abstract syntax or abstract machines.
  • Programming: use data abstraction, classes, and so on.

Is it possible to teach abstraction?

Jeff cites Jean Piaget, which defines four stages of cognitive development. The 4th stage, which is usually from 12 years old to adult, is called ‘formal operational thought’. In this phase man learns to think abstractly, systematically and hypothetically. The bad news is that only 30%-35% of adults will develop the ability for abstract thought. The question is, can we teach abstraction and thereby give the other 65% also some ability for abstract thought? Or can we just improve it?

Although abstract thinking is key to software engineering, no courses on abstraction are given at university. However, each course in software engineering studies uses abstract thinking. So, abstraction is essential, but is thaught indirectly.

According to Jeff it can be ensured that students can make use (or understand) abstraction, by

  • Teaching enough mathematics,
  • Teaching (formal) modelling and analysis.

He goes something deeper into modelling, with some definitions. If you’re interested in the fundamentals of modelling and meta modelling, just read the first part of my article on Combining GPLs and DSLs for Model Driven Engineering.

He concludes that teaching abstraction works for understanding abstract models. However, producing a model is still difficult, unless you’re part of the lucky 35%.

Conclusion

If we want the best Software Engineers we have to teach abstraction. Teaching abstraction in an indirect way works quite well, however, making it more explicit will help in understanding the essence and making the knowlegde transferrable among domains. Besides teaching abstraction it is important to test formal operational thinking, put in another way: we have to test whether someone has the ability to think abstractly. Jeff is researching the possibility for such a test.

The article The camel has two humps came into my mind when listening to Jeff. This article describes the ability to learn programming and points out that programming teaching is useless for those who are bound to fail and pointless for those who are certain to succeed.

1 Comments Added

Join Discussion
  1. Brian Leapman October 6, 2008 | Reply

    Johan,
    I have been looking at your web site and Mendix. I am looking at Pega Systems for a particular application of model driven execution based on Universal Process Architecture, which uses just three abstract components to describe any process at any level of fractal detail.
    Question, are you familiar with Pega. What do you regard as the major differences and benefits of Mendix over them?
    Can we set up a link to talk about these topics and some others that might mutually benefit us both.
    Many thanks,
    Brian Leapman

Leave a Reply