About Contact Site map

Calendar

Encyclopedia

Home

Mads

Articles

Object Orientation Redefined: ...

Printer-friendly

How to cite

Object Orientation Redefined

From abstract to direct objects and toward a more understandable approach to understanding

by Mads Soegaard

Extended abstract

The success of object orientation is undeniable. In 2001 the success was further emphasised when the Turing award was awarded Ole-Johan Dahl and Kristen Nygaard for conceiving “ideas fundamental to the emergence of object-oriented programming”. Eight years earlier, in 1993, Kristen Nygaard and two co-authors published an explication of what they believed was the idea of object orientation, independent of programming language or system development methodology. Their “conceptual framework for class-based object orientation” draws on their work in conceiving object orientation during the previous decades.

A core assumption of their framework is Nygaard’s mantra that “programming is understanding” and consequently that object orientation is principally an epistemological matter. Therefore, their framework attempts to explain the connection between human understanding and object-oriented formalisation, and it is to my knowledge one of the only attempts to define what the philosophical/epistemological/ontological assumptions of object orientation are. Their attempt constitutes a very positive development for the object-orientated community, which, beyond their attempt, was and is plagued with unfounded allusions to an alleged structural relationship between either the world and object-oriented objects or human thinking and object-oriented objects, e.g. “we think in objects” or the “world is made of objects with properties”. The community is also plagued with unfounded accounts as to why one object design is better or more ‘correct’ than another (except when justified by technical rationality). How can one expect to provide an explanation or justification of object designs along any sensible line of reasoning without any investigation of the foundation of such an explanation/justification?

In this report, I shall argue that the aforementioned conceptual framework for class-based object orientation is not suitable to constitute such a foundation, which was Nygaard and his co-authors’ intent, as it is based on epistemological and ontological assumptions reminiscent of modernity, a hard science view applied to the social and psychological world, an approach to categorisation as central to thinking, a view of meaning and truth as ‘underlying’, and generally a hard science approach to human understanding. Such assumptions were commonplace, especially in mainstream cognitive psychology, in the decades where Madsen, Nygaard, and Møller-Pedersen pondered on the idea of object orientation. And since cognitive psychology and computer science in these years functioned as reciprocal mirrors, it must have seemed obvious to explain a connection between understanding and object orientation on the backdrop of this synergistic relationship. However, these assumptions that came to be foundational to object orientation have at present time long shown their inadequacies in both cognitive psychology and many other disciplines. In fact, to my mind it seems self-evident that object orientation, conceived as understanding, including the central act of modelling, cannot be adequately understood from a natural science position.

As a consequence, in this report I shall present an alternative theoretical framework for object orientation based on the phenomenological tradition of Husserl and Heidegger, the social theory of Garfinkel, on the linguistic theory of Wittgenstein, on the perception-cognition theories of Gibson and Barsalou, among other theories. These theoretical positions will be explained in the light of how they may constitute the new epistemological/ontological assumptions of object orientation as well as how this change of assumptions alters the idea of object orientation. This framework can thus be used as a backdrop when answering fundamental questions like, “what is meaning in relation to object orientation?”, “what things ‘out there’ do we coordinate our code with?”, “why is this (object) design better than that one?”, etc. This update of the assumptions of object orientation, subscribing to an amodern stance, entails a redefinition of the idea of object orientation that can be characterised as a refocus from abstract to direct object encounter and a more understandable approach to understanding. By ‘understandable understanding’ I mean a more immediate and perceptually-oriented understanding than is the case for present-day object orientation, which to my mind is a quintessential engineering approach to meaning and knowledge as abstract and underlying. In my opinion, an understandable approach to understanding locates meaning in the phenomenal world of an actor, not in a disenchanted world of Newtonian facts extrapolated from sense-experience and exempted from purpose and value.

Figure 1: Preview of Figure 18 that depicts object orientation, or what may in broader terms be called ’empirical computer science’, as a specialised discipline by way of results applied from component disciplines.

Crystallised from my theoretical framework, I attempt to further a view of computer science as ‘computing science’, a discipline with an accentuation of how computing is put to use as opposed to technical rationality. I propose to conceive of the discipline in a different fashion than along the lines of the traditional research communities or university curriculae but instead as a specialised discipline by way of applied results from component disciplines (see Figure 1). Therefore, the reader must prepare himself for a line of reasoning that intentionally cuts across disciplinary borders and the genre-boundaries of most publications carrying the umbrella term ‘systems development’, ‘informatics’, or ‘computer science’.

Another consequence of changing the assumptions of object orientation is a reconception of the act of modelling. Instead of viewing modelling as a from-to relation where something ‘out there’ (i.e. the Referent System) is identified and re-presented in the software domain layer (i.e. the Model System), a subject-object reciprocal stance is adopted and I propose to view the Model System as a ‘Realm of Intended Meaning’ as it constitutes the programmer’s representation of an intended future world, as opposed to a representation of something ‘already out there’. As a further consequence of abandoning a belief in a world out there, it becomes senseless to speak of a Referent System unless it is reconceived as future meaning or the future world to be modelled. And being in the future (i.e. post-deployment) and depending on the future meaning-formation processes of the users, one cannot simply represent parts of the Referent System in the Model System. Instead, the Referent System has to be thought of as ‘real’ only to the extent that its meaning will become realised as intended once the system is appropriated by users and entangled in sociological and individual meaning-formation processes. This factor makes the Model and Referent System interdependent and one cannot any longer speak of objective modelling as a from-to relation where validity is established by checking the correspondence relation (naïve realism). Instead, one has to perform what I choose to call suggestive modelling as the Model System must assume a more proactive, suggestive, and purposive role toward the ‘construction of meaning’ to ensure that its codified intended meaning will be realised as intended in the Referent System post-deployment, where real users make sense of it (and make it into sense). This makes validity of (suggestive) modelling become not a question of descriptive correspondence but of closeness of empirically realised meaning vis-à-vis intended meaning. A model for versus a model of.

The next obvious question to treat is how to conceive of suggestive modelling in a more specific way. Fortunately, the theoretical framework for object orientation that I present in this report provides an answer, more precisely in the relationship between perception and cognition and the significance of this relationship in conceiving of meaning.

Meaning, in a natural science context and mainstream information processing cognitive psychology, is usually thought of as ‘underlying’. In information processing cognitive psychology, perception is commonly relegated the status of input device or recording system, from the outputs of which meaning and knowledge are extracted by higher-order cognitive processes. In consequence, perception cannot be regarded meaning-in-itself in orthodox cognitive psychology just as the presentation of the Model System (the View layer) is not object-oriented core meaning but merely a visual presentation of underlying meaning.

As will be evident, reconceiving modelling as suggestive modelling requires relying on epistemological theories like those of Phenomenology and Gibson’s (1979) theory of Direct Perception where meaning is indeed not underlying but very immediate. In the latter, c oncepts and knowledge are not something we ‘process’, build up, or extrapolate from sense experiences but instead it is posited that perceptual neural systems underlie both perceptual and conceptual cognitive activity. Sense experience is thus meaning in itself, not something to derive meaning from.

Such a theoretical stance brings the debate of the distinction between user interface and application semantics#1 (Model-View relationship) into the heart of a redefinition of object orientation, and notably suggestive modelling, as a ‘direct and perceptual encounter’ of meaning in the form of objects is the principal way the Model System can be ‘suggestive of interpretation’ and thus ensure its validity (as a measure of the degree of match between realised and intended meaning).

Therefore, this report is brought to an end with an archaeology of how object-oriented meaning in a non-underlying sense has been conceived over the years, from the early Smalltalk tradition and the Model-View-Controller pattern to object-oriented user interfaces (OOUIs). I show that a re-interpretation/reviving of some of these concepts may help bring the user interface back from its auxiliary and secondary role as information-transmitter-and-mediator, in line with mainstream accounts of the human perceptual system, and recognise it as the very locus of object-oriented meaning.

Background and motivation

The motivation for this project comes from experiences gained from teaching a course on object-oriented programming and systems development at the Department of Information and Media Studies at the University of Aarhus. Before teaching the course I had been pondering on the problematic epistemological/cognitive foundations of object orientation for a while but having to teach object-oriented programming and systems development to ‘unspoiled’ students underlined that something was not right with regards to the relationship between understanding and object orientation.

During the one-year course, the students were taught an object-oriented development method (Unified Process) and an object-oriented programming language (Java). What the students had particular difficulty in understanding was what the essence of object orientation was, independent of a development method or a programming language. Object orientation in the Nordic countries, and especially at the Department for Computer Science at the University of Aarhus, has always accentuated Kristen Nygaard’s mantra that “programming is understanding”, i.e. that the essence or idea of object orientation is understanding. So why did all these bright students, in their own words, find the act of ‘understanding’ counter-intuitive? After all, this is what they are trained in doing.

Allow me to elaborate on this issue. During the course, the students were to find a company or real-world organisation and make a small-scale system for this ‘customer’ (not to be put into production but to function as a working prototype). During this course of time they were taught about object-oriented programming and systems development in a manner that allowed them to iterate between acquiring text-book knowledge and trying this out in their ‘real-world’ project in cooperation with the given company.

The students generally did not have much difficulty understanding a domain model as a sort of topological view of the significant vocabulary and abstractions of the domain. They observed or interviewed the users and used the way they viewed and talked about their work as a basis for the domain model. Working iteratively, they started early making a code skeleton from the domain model and did not seem to have much trouble understanding that creating alignment between the world and the object design is what modelling is about. Continuously keeping an alignment between the world and the design artifacts such as System Sequence Diagrams and Design Class Diagrams or actual Java code helped their understanding, as was the point.

However, as soon as the students started having prototyping sessions with the users, problems arose in understanding the world-code alignment. They had difficulty understanding how to integrate the insights gained from the prototype sessions with the object-oriented classifications expressed in the domain model, object design, and code skeleton. Prototypes (at least the non-cardboard ones) created a world of tabbed panes, of dialog boxes, and other Graphical User Interface components (GUI components henceforth) that were also formalised in Java classes but it seemed unclear to the students what their relation were to the domain. For example, an applicant class is the representation of the real-world applicant but what is the thing on the screen then, the applicant screen representation? The trouble is that the screen representation is also represented in a class but this time a class without the applicant-as-domain-class’s “real-world” reference.

I explained the distinction between the technical services layer, domain layer and GUI layer, but the relationship between the domain layer and the GUI layer still seemed puzzling. It became two competing versions of reality, a problem which revealed itself in a Design Class Diagram with a lot of well-designed domain layer classes and then a constellation of GUI classes which were ‘adrift’ in relation hereto (see Figure 2). The relation between these two sets of classes seemed difficult to explain to them. The students raised questions like, ‘if the domain layer is a representation of the world out there what is the interface then, a representation of that representation?’ And ‘is the domain layer not a bit out of date in comparison with the GUI classes, the users’ new meaning’? Where was this so-called object-oriented meaning located? The confusing ‘ontological relationship’ between GUI and domain layer became even worse when I introduced the ‘best practice’ of separating the domain layer (the Model component) from the GUI classes (the View component), as is captured by architectures like Model View Controller (Krasner and Pope 1988), Seeheim Model (Green 1985) and design patterns such as InterfaceOutside (Cockburn 1996).

Figure 2: A Design Class Diagram from a group of students. They had difficulty understanding what the locus of meaning was, the GUI classes or the Domain Layer. They intuitively understood the advantages of separating business logic code from GUI code but did not understand why this was not possible without completely separating GUI and Domain layer in two different worlds.

Looking at their Design Class Diagrams, some of these classes (even thought of in precompile-time) represented the world out there. However, some of them did not, namely the GUI classes. They, on the other hand, represented what the user experienced and could relate to in run-time, c.f. the prototyping sessions. So one set of classes seemed mainly to represent the old domain (although they were ‘new’ parts added to them) while the GUI classes in runtime seemed to represent how the user was to think about and interact with the domain, the new organisational reality. Why was the relation between these two sets of classes not clearer? I found it quite difficult to put this in plain words to the students and wondered why. After all, object orientation is merely ‘a small matter of understanding’ #2.

To clarify these issues, I introduced Madsen et al.’s article toward the end of the course. It captures what the authors, among them Kristen Nygaard, mean by the idea of object orientation and represents a view of viewing programming and systems development as understanding based on categorisation, abstraction, and object-oriented meaning conceived as ‘underlying’. However, this kind of understanding was according to the students not very understandable. As one female student noted in a straightforward manner at the end of my lecture, “The problem with what you’re saying is that it is too damn abstract”.

In the end, most of the students understood what was required of them but it was clear that it required substantial ‘mental training’ and that this sort of object-oriented understanding by no means seemed natural to them.

Problem statement

Since the end of the aforementioned course, the more I have thought about what object orientation is in relation to understanding and thought processes, the more abstract and counter-intuitive the whole idea seems to me. Consequently, in this report I shall investigate what is meant by ‘understanding’ in relation to object orientation, i.e. programming-as-understanding, by examining the epistemological/ontological/philosophy of science assumptions of object orientation. In addition to such an investigation, I shall propose a theoretical framework for what I believe to be a more understandable approach to object-oriented understanding, based on an update of its epistemological/cognitive and ontological assumptions (as expressed in Madsen et al. 1993, who draw on Knudsen and Thomsen 1985). I shall also provide concrete examples of architectures and coding practices that embody my theoretical framework as well as provide a very concrete redefinition of object-oriented modelling in order to underline that my ideas are not merely theoretical constructs or idealised intellectual trumpery but indeed very viable and constructive.

The emergence of Object Orientation and the problem of ‘meaning alignment’ between world and code

As mentioned, the success of object orientation is undeniable. Almost all modern-day programming languages, even scripting languages however inherently non-object-oriented they may be, have some level of object orientation to them.

Object Orientation’s affinity for ‘meaning-alignment’

Object orientation started in back in the 60s when Kristen Nygaard developed the Simula-67 programming language. For him, programming and understanding were two sides of the same coin and he thus called his programming language Simula as it was to simulate the real world, i.e. to simulate the programmer’s understanding, not translate it into ‘unnatural’ constructs.

For this reason, Simula and its antecedents became good at handling complexity: If the correspondence between the real world and the code or object design was high (i.e. a low representational gap), the programmer would have to do less mental translations between the software world (the object design) and the real world. With an object-oriented language he could ‘code the world’ the same way ‘he viewed the world’. And, once empirical approaches such as interviewing users became accepted or even encouraged, he could ‘code the world’ the same way the ‘the user viewed the world’, i.e. the user’s conceptual or mental model of a given domain. Object orientation thus became a powerful tool for the programmer with respect to deciding on his software design.

Figure 3: Good cognitive economy for the programmer is constituted by creating alignment between either (A) the user’s conceptual model and the code/object design or (B) the world and the code/object design.

The breakthrough of object orientation came with SmallTalk (Goldberg and Robson 1983) some decades after Simula had provided the ‘proof-of-concept’ so to speak, and the industrial breakthrough came with the C++ language (Stroustrup 1986). However, at this time, the mid 80s, computers had made their way into offices and homes and the computer scientist was not the only one interacting with software. Until this point in time object orientation had provided a convenient way for the programmer to structure and view her software, but non-expert users could of course not be expected to interact with the software the same way computer scientists did. To this end, and to enable the spread of the computer beyond the server room or the programmer’s desk, the graphical user interface was added onto the software. Whereas object orientation provided the programmer with a “view of the software” at a, to him, meaningful level of abstraction, the user interface was the user’s “view of the software”. It acted as a translator between the technically challenged user and the ‘real software’ hidden somewhere behind the GUI, deep in the belly of the machine. Thus, GUI and application semantics existed in separate realms and this abstraction or separation has along the years come to be considered a best practice.

The emergence of UIs for end users did not distort the object-oriented ideas as the mapping between the users’ conceptual model and the object design (the ‘default’ level of abstraction is the object level) was still there. Nonetheless, it left the GUI to its own devices, without a coupling to the object design. This lack of coupling came under discussion in the HCI community, which had emerged as a discipline in the early 80s and quickly had become vastly productive. It was notably in connection with direct manipulation interfaces (e.g. Hudson 1987, Hudson and King 1988) and User Interface Management Systems (UIMSs) #3 (e.g. Rosenberg et al. 1988) that the missing coupling became problematised.

Figure 4: The lack of coupling between code/object design and GUI.

In these discussions it was often claimed that in order to provide really Direct Manipulation interfaces (with a high degree of semantic feedback) a tight relationship between GUI and application semantics was needed. Such as coupling would result in using the user’s perception of the interface to guide the object design, or, conversely, using the object model to guide the interface design. This, some claimed, would have the following desirable consequence:

Figure 5: From the programmer’s point of view there is an alignment between the user’s perception of the system (the new organisational reality) and the object design.

The above alignment was, as we shall see, taken up by many researchers and practitioners but (unfortunately) seemed to fade away again, perhaps due to the clear-cut division of labour between GUI-designer/HCI people and computer scientists that emerged through the 80s. Thus, one may claim with few exceptions that object orientation concerns itself with the cognitive coupling between code at the object design level and the user’s conceptual model, whereas the HCI community concerns itself with the cognitive coupling between the user (including her conceptual model if one is supposed to exist) and the visible and tangible GUI #4 (see Figure 5). This is of course an oversimplification but it suffices for our present purposes.

The disparity of Object Orientation and the need for a unifying idea

In 2001 the success of object orientation was further emphasised when the Turing award was awarded Ole-Johan Dahl and Kristen Nygaard for conceiving “ideas fundamental to the emergence of object-oriented programming, through their design of the programming languages Simula I and Simula 67” (ACM 2003). Because of the immense popularity and prevalence of the object-oriented paradigm, referring to systems development in computer science circles usually means object-oriented systems development.

This umbrella term encompasses countless specialised communities. Some concern themselves with purely technical matters like compiler-technologies, object persistence mechanisms, performance issues, etc. and these communities will not receive much attention in the present report as they usually do not engage in epistemological discussions (due to their self-perception as mathematical or otherwise natural science disciplines). On the other hand, attention will be paid to the parts of the object-oriented community that are concerned with the integration of the technical matters with the process aspects of systems development; in other words, how to get from capturing requirements, over analysing the problem domain, designing the system, and implementing it in code. This is the community concerned with Object-Oriented Analysis and Design, OOAD in shorthand, and since there does not seem to be any branch of object orientation concerned with epistemological matters, this community seems to be one of the few places where such discussions emerge.

There is a small set of widely-used OOAD methodologies and the most well-known are Unified Process (henceforth UP) (Jacobson et al. 1999), its sister-methodology Rational Unified Process (henceforth RUP), which are somewhat rigid or heavy-weight. As recent answers to the rigidity of UP and RUP, more ‘agile’ development methods have gained popularity, for example ‘Agile UP (Larman 1998, 2001) and Extreme Programming (henceforth XP) developed by Kent Beck (Beck 1999), which rethinks some of the core assumptions of the UP-RUP sisters.

What these development methodologies share with the design and use of object-oriented programming languages is that the idea of object orientation is their cornerstone. Object orientation is thus the idea that cuts across both analysis, design, and implementation and a reasonable question would consequently be what this idea really is – independent of development methodologies, languages, persistence mechanisms, or the like. This question has been attempted answered by very few and done so in a, to my mind, somewhat confusing manner. Before I review these attempts, I shall briefly provide some background.

Scandinavian Object orientation and the emphasis on modelling and understanding

Although the literature on object orientation in general is immense (ranging from persistence mechanisms to programming, over OOAD) there is a surprising lack of literature elucidating two key aspects of object orientation that are mutually dependent:

1. A general conceptual framework explaining what object orientation meansin general terms without reference to a specific language or a process model.

2. A thorough investigation of the alleged connection between object orientation and how the world is structured or between object orientation and human understanding. This connection remains an assertion until it has been researched, not just loosely commented on. The assumption is particularly evident in Scandinavian object orientation where modelling is central, but also in the North American tradition although downplayed on account of reuse (c.f. e.g. Madsen 1995).

This, however, does not mean that the history of computing has entirely ignored soft matters of programming languages. For example, the FORTRAN language was partly motivated by a wish to provide a programming language that reflected the users’, mainly mathematicians, domain (e.g. Collins 1995 and Sebesta 2002: pp. 44-45). Hence, FORmula TRANslation. Similarly, one of the chief design criteria of the COBOL language (COmmon Business Oriented Language) was its ease-of-use in order to appeal to as large a user population as possible, even at the expense of computational efficiency and expressivity (Sebesta 2002: pp. 61-63). Because of these Human Factors motivations, the languages were to some extent designed from ‘the human side’, but opening any kind of book or conference proceedings dealing with programming language design, one discovers that human concerns only constitute a minute part and that they are usually only superficially treated.

This state of affairs may perhaps have been expectable in the early years of computing when the technical rationality of hardware played a large part of the design efforts. However, when designing a programming language nowadays, or at least from the 80s and onward, one should expect of a language designer to thoroughly consider how her language design and its use will relate to ‘the real world’ and human understanding, in other words the epistemological and ontological assumptions of the language. However, judging from the ACM Conference on the History of Programming Languages (Feldman 1993) one gets the impression that language design is almost exclusively made on the background of technical or functionality-related premises. This leads to a sort of circular argumentation for programming languages where one design justifies the other and where their relation to the critical epistemological aspects of the empirical process of producing a system from start to finish, i.e. using the programming language for programming-as-understanding, is downplayed. For example, in a summary of SmallTalk’s history (Kay 1993) in the conference proceedings of the ACM Conference on the History of Programming Languages, Alan Kay makes no substantial comments on Smalltalk’s modelling aspects, about how it relates to the world it is to formalise and represent. Other language designers in the same conference (e.g. Hansen 1993 (Pascal) and Ritchie 1993 (the C language)) are also remarkably quiet about these aspects of their language design.

While some of the aforementioned languages like FORTRAN and COBOL have partly been designed for ease-of-use and claim to reflect the user’s domain, the claim of object orientation is somewhat more radical, namely that it hangs together with our very cognitive/epistemological processes as mentioned in #2 above. To start off the investigation of what is really meant hereby, as well as what object orientation as an idea means across programming languages and development methods (#1), I shall introduce Knudsen and Thomsen (1985).

A conceptual framework for programming (languages)

Modelling as the central aspect of programming

Knudsen and Thomsen (1985) have developed a framework of language independent concepts with the aim of enabling discussion of the act of programming and programming languages in general, independent of the premises of any specific language. What makes their work particularly interesting is their, typically Scandinavian, stance toward viewing programming languages, including non-object-oriented ones, firstly as a tool for conceptual modelling and only secondarily a tool for instructing the computer (p. i). They picture the act of programming in the following way.

Figure 6: The act of programming, as adapted from Knudsen and Thomsen (1985), p. 5

First, there is a distinction between the Referent System and the Model System. The Referent System is a part of the real world, e.g. a company. The Model System is a program or computer model simulating part of the Referent System, let us say the handling of applications in an HR department. The act of modelling is thus the process “in which problem specific concepts (established in the Referent System) are given a definition in terms of realized concepts (established in the Model System)” (p. 11). For example, the concept of application in the Referent System is realised in the Java class Application , the realised concept, from which Java objects are instantiated.

The sum of the problem specific concepts identified in the Referent System is called the problem area, “the domain of the programming process” (p. 7). The problem area, often referred to as problem domain, is in other words the piece of the Referent System that the programmer decides to actually model, e.g. the HR department’s handling of applications.

The focus on abstraction and conceptual superstructures

In the Referent System a concept “is a generalised idea about a collection of phenomena, based on common properties of instances in the collection” (p. 291) and a phenomenon is “a thing that has definite, individual existence in reality or in the mind” (p. 290). For example, the application submitted by John Smith is a phenomenon that, together with other applications, constitutes the general idea of an application. And since the Model System is a model of the Referent System, we find an exact copy of this structure here: The realised concepts (e.g. the Application class) are general ideas abstracted from entities that share properties (e.g. instances of the Application class). In the Model System however, the abstraction process is somewhat the reverse as entities (e.g. Java objects) are generated from realised concepts (Java classes), a distinction they call the Entity-Descriptor distinction (p. 28). Thus, in the Model System a concept is the cradle of phenomena and as such indispensable. And since the creation of objects thus require an identification of problem-specific concepts in the problem domain, the programmer is predisposed toward viewing the world in terms of concepts, he is compelled to answer “what sort of phenomenon is it?”

Conceptual distance

Between the problem specific concepts (an application) and the realised concepts (the Application class) a conceptual distance exists. Knudsen and Thomsen make the comment that “This distance can be used as an indication of the difficulties in modelling the [required program] in terms of the realized concepts” (p. 8). They do, however, treat conceptual distance as an a priori property of the modelling process, and do not investigate or theorise about its nature; e.g. how such a distance can be measured, how to separate the real world from its description, and whether the real world was really there before the description.

Thomsen and Knudsen apply the classic terminology of Greek philosophy and intensional logic to distinguish between a concept’s extension, intension, and designation. The extension of a concept is the collection of phenomena which the concept covers, the intension of a concept is the collection of properties that characterise phenomena in the extension of a concept, and the designation of a concept is the collection of names under which the concept is known (pp. 12-13). The authors acknowledge their Aristotelian heritage and contrast this to a fuzzy view of concepts where borders between concepts are more fluid. The key definitional property that distinguishes the fuzzy view from the Aristotelian (to use an Aristotelian phrase) is that membership in the Aristotelian view is a yes-no question whereas it is a question of higher and lower degrees of membership in the fuzzy view. This causes the Aristotelian view of concepts to have a higher affinity for formalisation and, in my own view, a determinability that makes modelling more comprehensible (“Well, is it or is it not?”). The authors note that they believe that many real-world concepts and phenomena are fuzzy, and this makes a formalisation based on an Aristotelian approach problematic. Therefore, “a critical aspect of the modelling function will often be to give an Aristotelian definition of problem specific concepts that have a fuzzy nature in the referent system.” (p. 18). And further: “No techniques to avoid [imperfect modelling] can be given, but of course we can try to make the models as good as possible to meet the needs of our application”. In other words, modelling means cutting your coat according to your cloth; modelling is about finding the best possible model for the problem area, i.e. the model with the least conceptual distance.

In conclusion

From the above, it becomes very clear that Knudsen et al. are (very) preoccupied with conceptual superstructures and conceptual distance in relation to understanding, modelling and programming-as-understanding. I believe this preoccupation with concepts to be very characteristic of Western thinking dating back to classical Greek philosophy. In western thinking, especially as manifested in our scientific tradition, one focuses on deriving a conceptual superstructure for each phenomenon studied; it seems we have a predisposition toward looking for a genus. We ask “what sort of thing is this?” as opposed to appreciating the thing on its own terms or on its immediate characteristics. And while a primary focus on the generalisable is fruitful in some scientific contexts it does not necessarily reflect how we think per se.

The fact that concepts are attributed this salience in Thomsen and Knudsen (1985) is further emphasised by the fact that a conceptual distance is a distance between ‘concepts’. I shall later use this focus on abstraction and conceptual superstructures as a key point of criticism.

A conceptual framework for class-based object orientation

Madsen et al. (1993) use Knudsen and Thomsen 1985 as a basis for their conceptual framework for class-based object orientation and to my knowledge Madsen et al. represent the only attempt to provide such a framework.

Madsen et al. (1993) describe the act of programming as that of understanding (e.g. p. 3), and hold that analysis, design, and implementation are all programming activities (thus understanding activities) at different levels of abstraction. This makes understanding and modelling paramount and object orientation is seen as a perspective for understanding the world and creating a world-code correspondence (p. 284). It also makes Madsen et al.’s conceptual framework a sort of ’connective tissue’ or ‘overarching idea’ that holds analysis, design, and implementation together as the phases share this common ‘understanding-approach’. In comparison, development methods like Agile Unified Process (UP) (Larman 2001) or RUP (Jacobson et al. 1999 ) use a series of heterogeneous types of modelling. For example, in RUP and Agile UP modelling during some parts of analysis may be viewed as procedural (via so-called ‘analysis artifacts’ such as Use Cases, System Sequence Diagrams) and during analysis modelling may be viewed as object-centric (via so-called ‘design artifacts’ such as Design Class Diagrams). For my students, the heterogeneous approach of UP made the relationship between the phases and indeed the whole development process less comprehensible and difficult to ‘get a hold of conceptually’. Due to the heterogeneity of perspectives on the domain (as embedded in the various analysis/design artifacts mentioned above) they even initially had difficulty understanding the connection between a domain model and a design class diagram #5.

One of the claims of the present report is that object orientation can and should form the connecting tissue between the phases mentioned above as well as interface design. However, due to problems of their basic scientific assumptions, Madsen et al.’s conceptual framework is to my mind not conducive of such a truly overarching approach. I shall elaborate on this in the section “ A critical view of object orientation”.

Object-oriented concept according to Madsen et al. (1993)

Class-based object-oriented language, in this case Java

Concept

Class

Phenomenon

Object

Intension

State and behaviour of a class ( attributes and methods)

Extension

Set of objects instantiated from a class

Denotation

Identifier, i.e. a set of identifiers pointing to an object in memory of the same or ‘underlying’ type declaration as the identifier (according to the Liskov substitution principle)

Inheritance, specialisation, and extension

Class inheritance via the ‘extends’ keyword

Aggregation and composition

Class variables (declared public or accessible via get/set methods), usually one does not mean basic data types.

Figure 7: Terms used in Madsen et al. and how they map onto a class-based object-oriented language, in this case Java.

Modelling and coordinating with a future world

A question we must also answer is to which extent object orientation is about simulation of something that is perceived to be ‘real’ or ‘already existing’. In this connection the phrase "the dialectics between tradition and transcendence" is often used in the HCI and the systems development community. The phrase is from by Pelle Ehn’s PhD thesis (1988), and captures the idea that design is a fundamental tension between tradition and transcendence. This tension is to be understood in terms of the designer's role being somewhere in the space between extending and improving the present design context (to root the design in the present tradition) and exploring, and eventually reifying possible future worlds by transcending, going beyond, the boundaries of the existing tradition, ideas, and conceptions of the design context. If this is true, object orientation should not only enable a faithful modelling of a Referent System, an ‘IT-fying’ of something existing, but also enable reifying a future world.

Madsen et al. address this question by stating that “A program execution is regarded as a physical model simulating the behaviour of either a real or imaginary part of the world” (p. 284). This makes the programmer’s unit of analysis real and/or imaginary parts of the world from which he makes program executions. Transcending the tradition can thus be done by ‘adding new aspects’ to the real world before creating one’s Model System of this world.

“The definition of object-oriented programming implies that all program executions are models of some other existing systems. For new systems this also holds, even though the existing system in that case is a system existing in the minds(s) of the programmer(s)”. (p. 285).

“The creation of computer systems of course includes a great deal of invention. These inventions may be imagined as new phenomena and concepts with a well defined role in the problem domain. They will then subsequently be realized as objects and patterns in the program execution”. (p. 285).

Analysis (i.e. understanding) in relation to object-oriented programming is thus conceived by Madsen et al. as something very constructionist. It is not merely appreciating the current world, nor is it merely a question of perspective on it. It is also a purposeful addition of new understanding to an existing understanding of the current world. This new and future world (in the mind of the programmer) can then be reified through the creation of a Model System.

Object-oriented analysis thus both involves identifying parts of the real world as well as adding new parts to it. That way, design and implementation activities are about coordinating with this “future world”, i.e. keeping the design and the code ‘in alignment’ with it.

Figure 8: Modelling is coordination with real and imaginary parts of the world, jointly constituting the problem domain.

During the development lifecycle this world is iterated over and remade several times. Each time the developer finds a better way of conceiving of the Referent System (analysis), the Model System is brought into alignment (design and implementation). Once deployed, the actual computer system will replace, augment, or somehow change the original Referent System (more specifically, the real parts of it); it becomes a part of the real world. For example, the electronic patient record replaces the paper-based record and thus becomes the patient record. After deployment, object orientation’s unit of analysis thus sometimes changes, disappears, or becomes a reference to the previous state of affairs.

To ‘construct’ the problem domain during analysis we use methods such as use case writing, exploratory, experimental, or evolutionary prototypes, domain model writing, etc. These are the analysis artifacts that first represent the problem domain. From this constructed Referent System expressed in various artifacts, relevant phenomena and concepts (jointly representing the problem domain) are picked out and modelled in the Model System, e.g. by using a ‘name-category list’ to extract nouns from use cases (Larman 2001). The problem domain is what the developer coordinates his code with during design and implementation activities, and due to the closeness of his view of the world in phenomena/concepts and the programmatic, diagrammatic, and textual means of expression available to him, a cognitive economy is established. This is what Madsen et al. mean when they state that “analysis, design and implementation are programming or modelling activities, but at different abstraction levels” (Madsen et al. 1993: p. 283) since one coordinates with the Model System in the same basic way (via phenomena and concepts) during all three phases.

Figure 9: shows how the new future reality is first established through analysis artifacts such as use cases etc. Some of the artifacts are mainly used for representing the ‘real’ parts of the Referent System and some toward the ‘imaginary parts’ of the Referent System. Subsequently, one identifies relevant phenomena and concepts, and map them over into the Model System.

An important point is that the Model System is not a computer system but modelled (future) meaning. In this regard, system merely means a coherent interrelated whole (pp. 286-289). The Model System is thus the ‘core meaning’ to which the user interface, various technical services, and other pure fabrication classes is added to make up the computer system (see Figure 10). This makes the Model System the sum of what is referred to as domain classes (collectively called the domain layer, e.g. Larman 2001) and a popular rule of thumb is that there are 5 non-domain classes for every domain class.

Figure 10: The Model System is the ‘core meaning’ to which the user interface, various technical services, pure fabrication classes are added to make up the computer system.

Although the model and the user interfaces are presented as separate concerns, Madsen et al. state that “the general approach of an object-oriented user interface is that representative elements of the model should have a representation on the screen. The user should have a feeling of manipulating the physical model directly.” (p. 312) I believe this to be an immensely important statement, one that I feel has been neglected almost completely in the object-oriented community.

A critical view of object orientation

Knowledge distillation and purification

Since the Model System is ‘core meaning’ as we concluded from the previous section, it begs the question of how we in this ‘process of knowledge’, as Madsen et al. designate it, find the ‘right’ core meaning from the wealth of representations? How do we distill/purify/crystallise meaning, i.e. ‘peel off’ the unnecessary complexity to reveal the underlying core meaning during the analysis phase? In this regard, Amarel’s quote that “solving a problem simply means representing it so as to make the solution transparent” (Amarel 1966) seems a tempting choice. In RUP and UP for example, an important aspect of the various representations (called design artifacts) is their mutually constraining relationship, called traceability (i.e. Jacobson et al. 1999: p. 10). Through these constraining relationships one can regard the development process as one of representation and re-representation (through constraining design artifacts) until the solution is transparent; one has arrived at an adequate object design, i.e. the core meaning. In classical waterfall development, as epitomised by Royce (1970), this stance was more outspoken and pure. Waterfall development may be thought of as ‘knowledge engineering’ in which knowledge is something ‘out there’ that can be ‘engineered’ to fit the representational format of the code: Each successive stage of waterfall development is about changing the ‘input representations’, i.e. design or analysis artifacts, resulting from the previous stage and yielding ‘output representations’ until the ‘solution’ has been reached.

Modern development process models like UP and RUP of course embed an iterative approach but my point is that as long as meaning is thought of as ‘underlying’, it will seem tempting to consider modelling as a process of meaning deduction or distillation. To elucidate the dangers of viewing meaning this way, let me explain one context in which Amarel’s quote is often heard, namely isomorphic problem research (e.g. Zhang 1991 and 1997) with its highly representationalist assumptions.

Isomorphic problems are problems whose underlying formal structures are claimed to be the same but whose surface structure vary (iso- means same, -morph means form). By detecting the underlying structural isomorphism the problem solver is able to solve a novel problem by superimposing the structure of the known problem upon the novel problem. Thus, the solution is assumed absolute and to be found somewhere ‘behind’ the problem’s polymorphic representational gloss, which may be more or less conducive/suggestive of its solution. A classical research example is comparison between Tic-Tac-Toe and the Number Scrabble game (also called ‘15 puzzle’) (e.g. Newell and Simon 1972, Zhang 1997, 188pp).

         Tic Tac Toe              Number Scrabble

            |   |                      |   |          
            |   |                    4 | 9 | 2         
         ---+---+---                ---+---+---
            |   |                      |   |          
            |   |                    3 | 5 | 7        
            |   |                      |   |          
         ---+---+---                ---+---+---
            |   |                    8 | 1 | 6        
            |   |                      |   |

Figure 11: The Tic Tac Toe and Number Scrabble ‘problem isomorphs’.

The Tic Tac Toe or ‘three-on-a-row’ game does not require any introduction. The Number Scrabble on the other hand is played by two players taking turns selecting a tile. When one player has selected three tiles that add up to 15, that player is the winner. As you can see, the numbers are arranged in such a way that each vertical, horizontal, and diagonal row of numbers add up to 15, thereby allowing the ‘problem’ to be solved the same way as Tic Tac Toe.

This genre of problem-solving research thus views problems as having underlying formal structures which can somehow be ‘dug up’ from the muddle or mask of representational gloss Consequently, solving a problem simply means representing it so as to make the solution transparent. For example:

“That representation makes a difference is a long-familiar point. We all believe that arithmetic has become easier since Arabic numerals and place notation replaced Roman numerals […] All mathematics exhibits in its conclusion only what is already implicit in its premises […] Hence all mathematical derivation can be viewed simply as change in representation, making evident what was previously true but obscure.” (Simon 1981: p.153)

In object-oriented literature one finds countless allusions to problem-solving research and problem isomorphs as well as Simon’s and Amarel’s stance toward ‘masking representations’ (regrettably, they remain allusions as I have not found any thorough investigation of these phenomena in relation to object orientation). To my mind, this position that the ‘underlying properties’ are the ‘real properties’ of reality as opposed to its ‘masking representation’ is clearly present in Madsen et al.’s framework (as well as how object orientation is conceived and practiced elsewhere). This becomes particularly evident through their preoccupation with the problems of giving Aristotelian definitions to ‘fuzzy’ or somehow more ‘natural’ or ‘real’ phenomena. Through this discussion, they seem to espouse the position that if one could find the right representational format to exactly match the meaning out there in the Referent System or in the minds of the people, a solution or ‘perfect Model System’ could be reached. The assumption that there is some ‘correct’ representational format of what is ‘out there’ has led to research such as Skou (2001), which is an investigation of how categorisation research in cognitive psychology hangs together with programming-as-understanding in an object-oriented language. But as Skou found out, it is a misguided research agenda to attempt to peer into the minds of people to discover a supposed format of long-term memory or categories-as-vehicles-for-inference with the aim of designing an according programming language with perfect model-world or model-mind correspondence as a result.

Thus, o ne gets the impression that a system development process is a process of meaning distillation or purification, through which complexity is ‘peeled off’ and the underlying order/truth is represented in the Model System (in a matching representational format to minimize the ‘conceptual distance’). But this misses a point in the problem-solving experiments (to continue analogising to problem-solving research). The unequivocal conclusion of such experiments (e.g. Sternberg 1996: p. 360) is that the test subjects do not necessarily experience two isomorphic problems to be ‘the same’. So although you can formally demonstrate an underlying structural isomorphism, the problem solver does not think they are ‘the same’, nor does she consciously solve two isomorphic problems by superimposing the structure of the known problem upon the novel problem. So are the problems really the same? To some scientists, maybe. But to the test subject, no.

In systems development we are in the same situation as something real to the programmer (the model) may be experienced in a completely different way by the user through the user interface. How can something be real to both parties and what then, is most real? It is quite obvious that we cannot really answer that question unless we dig a level deeper and look at some more philosophical matters.

The epistemological and ontological assumptions of object orientation

In the following I shall try to identify the epistemological and ontological assumption of class-based object orientation, which I have commenced in the above. What I intend to show is that because of Madsen et al.’s typically Scandinavian view of programming they are, in their conceptual framework, trying to answer what understanding and, more importantly, meaning are in relation to object-oriented formalisation. To my mind, this question cannot be answered from their underlying philosophy of science standpoint, as will hopefully be evident in the following. In the theoretical framework I propose later in this report I hope to be able to answer this central question from a less modernistic standpoint and, most importantly, doing so without loosing the ability to speak of formalisation and technical rationality. This should free us from a situation where we either answer what meaning and understanding are, or we answer what technical rationality and formalisation are.

Dissection along two dimensions

As mentioned, Madsen et al. believe programming to be first and formerly a question of understanding and they believe object orientation to be particularly well-suited for this. Of the three main advantages of object orientation they mention, they emphasise this aspect, Real-world Apprehension, over stability of design (being able to change an object-oriented program in the face of changing requirements with a minimum of reprogramming of the fundamental objects; the model), and reusability (being able to reuse components/objects in several contexts or programming projects). Real-world Apprehension captures the idea that “object orientation is close to our own natural perception of the real world” (Madsen et al. 1993: p. 2).

The concept of Real-world Apprehension rests on assumptions about “natural perception”, “the real world”, and lastly the connection between these two (“our own natural perception of the real world”). To analyse Madsen et al’s assumptions concerning these aspects can be analysed along several dimensions. I have chosen to use Hirschheim and Klein (1989) as inspiration, which in turn draw on Burrell and Morgan (1979) as inspiration. Hirschheim and Klein make an analytical breakdown of the assumptions of software development projects and map the assumptions onto two dimensions; an epistemological dimension called subjectivist/objectivist and an ontological dimension called order/conflict.

At one end of the epistemological spectrum, we find the objectivist position, the essence of which “is to apply models and methods derived from the natural sciences to the study of human affairs. The objectivist treats the social world as if it were the natural world” (Burrell and Morgan 1979: p. 7 as cited in Hirschheim and Klein 1989: p. 1201). The subjectivist position at the other end of the spectrum claims that methods and models from the natural sciences cannot adequately be applied to social affairs and posits that understanding must be understood from the subjective experience of individuals (Hirschheim and Klein 1989: p. 3).

Turning to the ontological dimension, we find a conception of the world as either ordered or inherently in conflict on the respective ends. In the ordered view, the world is viewed in terms of integration and functional coordination and in the conflict view, the world is viewed in terms of change and disintegration (Hirschheim and Klein 1989, p. 1201).

Figure 12: The analytical dimensions used by Hirschheim and Klein 1989 to analyse the assumptions of system development approaches/projects and their consequent outcomes. Adapted from Hirschheim and Klein 1989 p. 1202.

To exemplify two positions on this ontology/epistemology scatterplot, subscribing to an ordered ontology and an objectivist epistemology makes systems development instrumental reasoning (p. 1203). If the world is ‘out there’ and essentially agreed upon (ontology), and reasoning and understanding (epistemology) can be ‘correct’, i.e. methodically correct as in a natural science, systems development becomes a question of deducing a solution, much like an engineering task. Another position, that in many ways is the opposite of the former, subscribes to an ordered ontology, at least at the micro-sociological level (e.g. “our group/department/project is not be characterised by disintegration although we do not necessarily agree upon the world”). On the epistemological side, this position holds a subjectivist epistemology, which makes understanding both relativistic vis-à-vis the individual and at the same time non-individual in the sense that subjective experience may be culturally determined. Theorising, e.g. discerning economic laws, is one way of imposing order on the world, a sort of sense-making of what is essentially too complex and elusive. Turning to systems development, this makes the system developer become a facilitator or sense-maker. “There is no objective criterion that distinguishes good and bad systems. It all depends on what the parties come to believe to be true” (p. 1205). Good and bad is determined by the outcome of the interpretation processes whereby the subjective consciousness becomes the locus of meaning and the basis of any ontology.

The above is not only an allusion but a forthright drawing of the lines between what I believe are the assumptions of Madsen et al.’s definition of object orientation and the assumptions which I believe are necessary for a reconceptualisation of object orientation. My opinion is that while Madsen et al. may explicitly sympathise with the latter position, their backbone or tacit assumptions are still entrenched in the former position, which makes their attempt to define object orientation as programming-as-understanding impossible.

To further analyse the assumptions of object orientation, I have chosen an analytical stance similar to Hirschheim and Klein, only I have modified the order/conflict dimension and chosen to call it underlying order/continual ordering to turn the focus from political power struggles, or at least (dis)agreement about the states of world, to considering how social order and meaningfulness is sustained and reproduced, i.e. how sense on a sociological level is established.

Figure 13: These are the broad-brush analytical dimensions of my analysis. They are ‘broad-brush’ because they should be considered in terms of their semantic convenience rather than their absolute correctness. For example, the positions of epistemological objectivism and ontology of continual ordering seem to be mutually exclusive.

I shall now try to identify elements of Madsen et al.’s conceptual framework on these dimensions.

Ontology of ‘underlying order’ versus ‘continual ordering’

In the dimension of ‘underlying order’, both the social and the natural world is seen either as having an underlying order that we can research and thus deduce the nature of or as being something that emerges on the background of continual ordering efforts of the actors (both technical and social actors). The former is the foundation of most natural sciences and can be found in its most naïve and archetypical form in logical positivism, the early Wittgenstein, and quintessential cognitive science or Artificial Intelligence (AI) research. For example, Herbert Simon, a quintessential AI researcher sums up that…

“The central task of a natural science is to make the wonderful commonplace: to show that complexity, correctly viewed, is only a mask for simplicity”. (Simon 1981: p.3)

Within social theory, the view of underlying order is epitomised by the theory of Durkheim (e.g. 1933) and partly Weber (e.g. 1930). The latter position on the other hand, that of continual ordering, is found in the later Wittgenstein, in the social theory of Schütz (e.g. 1967) and Garfinkel (e.g. 1967) and as a basic assumption of Science, Technology, and Society Studies (STS); e.g. Latour (1987,1988,1991).

Underlying order vis-à-vis object orientation

Madsen et al. emphasise that not all aspects of reality can be modelled and propose information processes as the kind of phenomena that are particularly suitable to be modelled.

“An information process is a process where the qualities considered are:
• Its substance, the physical material that it transforms.
• Measurable properties of its substance, the results of measurement represented by values.
• Transformations of its substance and thus its measurable properties”. (p. 288, original emphasis)

Substance is thus physical material being transformed and is furthermore characterised by a certain volume, a unique location in time and space, and an identity (p. 288). The measurability of substance is obtained by measurements, and transformations of substance can consequently be identified by differences in measurements over time. This leads Madsen et al. to some guidelines as to the selection of phenomena from the Referent System when going about system development:

“We have to consider tangible things where the main aspect is substance, we have to consider measurable properties of substance, and finally, we have to consider the transformations on the substance” (p. 289).

This stance toward the physical and measurable is to my mind a classic attempt to de-contextualise information or somehow make it more ‘neutral’. It is assumed in the above that the physical world is somehow less controversial or subjective than the social or personal, psychological world and therefore holds some kind of ‘core data’. In this view, “Reality consists of objects, properties, and processes that are directly observable.” (Hirschheim and Klein p. 1203) and validity is thus established through some naïve realism by checking the objects’ correspondence to reality.

In my view, Madsen et al.’s approach bumps into this kind of correspondence problem; of how to conceive of the correspondence (and both ends of it) that constitutes the representational gap or conceptual distance. If one assumes underlying order, correspondence can indeed be checked, but if one agrees that social order or meaning arises from the continual ordering processes it becomes these continual and ever-changing processes that determine the validity.

In this regard, Schefe (2000) gives a thorough critique of Madsen et al.’s framework, saying that it rests on “several misconceptions, especially in the notions of ‘substance’ and ‘representation’ as a correspondence relation, and even of ‘object’.” (2000: pp. 3-4). Schefe calls Madsen et al.’s conception of modelling ‘objective modelling’ as it seems to be conceived as a correspondence theory. Schefe holds a different view and state that “Reference is not an isomorphic relationship between descriptions and their subjects” (p. 4), the abovementioned naïve realism, and consequently concludes that “The paradigm of ‘objective modelling’ has to be replaced by a paradigm of ‘purposive description’ shifting the focus of Software Engineering research to non-formal methodologies.” (p. 1).

When positing this kind of view of reference as an isomorphic relationship between descriptions and their subjects or likewise positing an underlying ontological order, a Model System can thus be highly ‘valid’ but prove to be inappropriate once used. To my mind, this yields a schism between what I choose to call information-in-use versus information-by-itself and what I mean hereby is that information ‘is’ not but emerges in use. This schism can also be found in theories of learning, where on one end of the spectrum we find Shannon and Weaver’s (1963) classical model of communication as information transmission and on the other end theories like Luhmann’s systems theory (e.g. 1995). In the latter theory, information is not transmitted but is built up inside consciousness on the background of external ‘irritation’ and from what is already in consciousness. According to the latter theory, it would be senseless to speak of what ‘information X really is’ (e.g. in the Model System) if it were only ‘correctly intercepted’ (e.g. by a user) and not ‘distorted in the transmission’ through some medium (e.g. a GUI, language in general, symbols, etc.).

Furthermore, by emphasising measurable properties of physical substance (as opposed to e.g. the ‘experience’ of users) Madsen et al. can be said to emphasise this analytical role of the system developer (i.e. peeling off the layer of complexity) as opposed to the constructive and interventionistic. This deductive or analytical stance is also evident in the choice of words of many system developers: For example, analysis phase as opposed to ‘vision’ phase, or requirements gathering as opposed to requirement construction (c.f. Beyer and Holtzblatt 1998).

According to the Wordnet dictionary (Wordnet) one of the definitions of analysis is “the abstract separation of a whole into its constituent parts in order to study the parts and their relations.” Its antonym is something ‘synthetic’ which is defined as “not genuine or natural”. This, perhaps tacit, choice of words, I believe, is indicative of the schism between, on one side, underlying order, i.e. a ‘core’ that can be deducted via analysis, and, on the other side, continual ordering, i.e. the assumption that nothing is genuine or natural but that genuineness, naturalness, and order is continually ‘constructed’ and ‘restored’.

In terms of consequences, assuming the developer’s role to be analytical may lead to a de-emphasis of participatory design practices as “users’ statements are merely one of many possible ways of deducing the underlying truth”. This position reduces the users’ experiences and opinions to variant subjective experiences of something invariant.

The independency of ‘meaning’ from the ‘subjective’ meaning-forming process of the user also corresponds well with how a system development process is normally conceived: First, the most objective part is made. This is the model, i.e. the abstract, deducted truth lying represented, but hidden, in the belly of the software. Toward the end, the interface is added onto the model which acts as the users’ interpreter vis-à-vis the software model. That the GUI is only a window to the underlying truth is emphasised by designating it as presentation layer. To use yet another analogy, think of a database with its user interface: Is the interface only a window of the ‘real’ (objective) information or does the (subjective) use of the interface and the-information-as-presented continually constitute the ‘realness’ (objectivity) of the information?

Although Madsen et al. describe object orientation as a perspective on the world (p. 284), and hence do not explicitly subscribe to a hardcore correspondence theory of truth, in my opinion they nevertheless uphold a notion of underlying order. As mentioned earlier, I believe that for their project of explaining programming-as-understanding to come to fruition one needs to change the philosophy of science assumptions of such a explanation. For example, if the assumption of underlying order is abandoned, the model of Madsen et al.’s conceptual framework may be conceived differently. Its meaning may become real in its consequence, i.e. the result of the future meaning-forming process of the users, and the developer must thus attempt to anticipate and influence this meaning-forming process. This kind of suggestive model would suggest interpretation of it and thus have a higher probability of becoming ‘real’ as opposed to what may be called a descriptive model. I thus distinguish between a descriptive model (Madsen et al.’s model that describes the real and imaginary parts of the world) versus a prescriptive or suggestive model (which is suggestive of its interpretation and whose claim of ‘realness’ is equal to the outcome of this interpretation) #6. The latter model entails re-conceiving the notion of model as a more social model, an act of communication between developer and user.

Cognitive and quasi-epistemological assumptions of object orientation

Turning now to the epistemological/cognitive assumptions of class-based object orientation, Madsen et al. state that “object orientation is close to our own natural perception of the real world” (Madsen et al. 1993: p. 2). To elaborate on this, Madsen et al. quote Krogdahl and Olsen (1986):

“The basic philosophy underlying object-oriented programming is to make the programs as far as possible reflect that part of the reality they are going to treat. It is then often easier to understand and to get an overview of what is described in programs. The reason is that human beings from the outset are used to and trained in the perception of what is going on in the real world. The closer it is possible to use this way of thinking in programming, the easier it is to write and understand programs”. (translated from Norwegian by Madsen et al. 1993)

The quote clearly illustrates the fundamental belief of the object-oriented community that ‘there is something about object orientation and thinking’, an alleged connection with cognition/epistemology. The quote unfortunately also illustrates the striking absence of any scientific basis for making such an argument. Referring to a layman’s conception of “we probably think in objects” is simply not good enough, although compelling.

One may argue that we perceive in chunks (percepts formed from sensations), that we write in words (lexical chunks), that we speak and hear in phonological and auditory chunks, etc and thus conclude that ‘phenomena’, whether lexical, perceptual, or whatever, is an adequate description of these pervasive chunks. But the mere presence of a superficial structural resemblance (the alleged ‘chunkness’ of the world and mind) does not suggest any resemblance between the phenomena in the head, in the software, and in the world (anymore than a carrot has a low representational gab vis-à-vis a triangle due to their similar perceptual structure). We must further clarify the assumptions of this thinking in objects/phenomena.

Madsen et al. elaborate on how knowledge and meaning is formed in the following paragraphs:

The process of knowledge may be split into three levels:

1) The level of empirical concreteness. At this level we conceive reality or individual phenomena as they are. We do not realize similarities between different phenomena, nor do we obtain any systematic understanding of the individual phenomena. We notice what happens, but neither understand why it happens nor the relations between the phenomena. In the programming process this corresponds to a level where we are trying to understand the single objects that constitute the system. We have little understanding of the relations between the objects, e.g. how to group them into classes.
(2) The level of abstraction. To understand the complications of the referent system, we have to analyze the phenomena and develop concepts for grasping the relevant properties of the phenomena that we consider. In the programming process this corresponds to designing the classes and their attributes and to organizing the classes into a class/sub-class hierarchy. At this level we obtain a simple and systematic understanding of the phenomena in the referent system.
(3) The level of thought concreteness. The understanding corresponding to the abstract level is further developed to obtain an understanding of the totality of the referent system. By having organized the phenomena of the referent system by means of concepts, we may be able to understand relations between phenomena that we did not understand at the level of empirical concreteness. We may also be able to explain why things happen and to predict what will happen. (Madsen et al. p. 295-296)

In other words, Madsen et al. claim that we identify phenomena (1), abstract properties from them and form concepts (2), and lastly we establish relationships between concepts and on the basis of this extrapolated knowledge we can predict, plan, and take action (3). The quote gives us something to work with in our attempt to further elucidate Madsen et al.’s epistemological assumptions.

First of all, to my mind this is a clear subject-object dualistic view of cognition/epistemology as we (the subjects) “read off” the world (the object), form a representation of it and make predictions from this model. With a stance toward more subject-object reciprocity concepts would not take such a primary role as meaning would arise in the interaction or borderland between subject and object and thus render superfluous such an elaborate representation (more on this matter shortly).

Secondly, due to the salience of concepts Madsen et al.’s conception of cognition/epistemology does not seem particularly perceptually oriented (cf. “To understand the complications of the Referent System, we have to analyze the phenomena and develop concepts for grasping the relevant properties of the phenomena that we consider”). This is further underscored by their emphasis on ‘substance’ and their advice that we should, in our modelling process, “consider tangible things where the main aspect is substance”. According to my Webster's Revised Unabridged Dictionary (1913) two possible definitions of substance are “that which underlies all outward manifestation” and “that which is real, in distinction from that which is apparent”. In other words, appearance seems to be the antonym of substance (and thus ‘underlying’)!

Madsen et al. themselves define substance as something “characterized by a certain volume and a unique location in time and space” (p. 288) and thus define it with reference to a mathematical or geometrical universe (absolute), not with reference to the phenomenal world of an actor (relative). This view clearly leans towards computational theories of cognition as the actor performs his cognising from the premises of a mathematical, geometrical or otherwise natural science universe (more on this later).

Thus, we are presented with a view of cognition, thinking, and knowledge creation that relies on (visual) perception to provide the information from which we form/distil meaning and knowledge, as well as a view of perception as not being inherent to cognition or ‘real thinking’. ‘Real thinking’ (the level of thought concreteness) as opposed to the aforementioned unreflecting (visual) perception (the level of empirical concreteness) is described by Madsen et al. to happen by way of represented concepts, using their relations and intensional properties for reasoning.

The problematic heritage and its alternatives

Object orientation’s assumptions as a product of its historical context

What I have been alluding to in the previous paragraphs are the distinctions between amodal and modal theories of knowledge (defined below), and the distinctions between information processing and non-information processing theories of cognition (both distinctions found in cognitive psychology and other disciplines concerned with understanding and epistemology). When Madsen et al. wrote their book in 1993, psychological theories had for the previous 25 years, or since 1956 to be exact, been dominated by theories (either computational or non-computational information processing theories) researched and understood from a natural science standpoint. In 1956, at a meeting at MIT critical to the discipline of cognitive psychology, Chomsky presented a paper on his transformational grammar, Miller presented his famous paper “The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information" (1956), and Newell and Simon discussed their computational General Problem Solver model. In the same period, Donald Broadbent at the Applied Psychology Research Unit in Cambridge integrated ideas from the Human Factors discipline with new ideas in Information Theory. Broadbent’s work yielded a quintessential information processing view of cognition as a sequential series of processing stages where basic stimuli (information) was processed in a series of processing stages and ended up in long-term memory storage (Broadbent 1958). This was later extended by Atkinson and Shiffrin’s (1968) influential theory of the distinction between short and long term memory.

This ‘information storage’ was in the subsequent years researched in terms of the very same Aristotelian concepts we have been treating so far (c.f. e.g. Kintsch 1980), either as storage containers, or vehicles for reasoning about ‘stored information’. And because of the above theories, notably Chomsky’s, and the advances of the computer and programming languages, cognitive representations were thought of in terms of textual representations, e.g. ((Chair=C1),(back=b1),(seat=s1),(legs=ll)). This sort of textual symbol information could be described in a programming language and be processed by a computer. Something visual could only be represented insofar as the visual could be transformed and described by the symbolic ‘format’ of the information processing system. Meaning and information was thus meaning-about-something.

This melting pot of theories provided the grounds for what we know as information processing cognitive psychology and what held the sometimes disparate theories together was the analogy between the mind and the computer as information processing devices. Computer science and cognitive psychology ‘fed off each other’ and the mind was (perhaps consequently) understood from a mathematical and natural science standpoint.

When Kristen Nygaard and others in the 60s, 70s, and 80s were pondering on how object orientation hangs together with thinking, they did so in the heyday of computer-mind analogy and on the backdrop of the aforementioned very influential theories. T he historical context thus made it very compelling to understand ‘understanding’ from a natural science standpoint as well as consider Aristotelian concepts as keystone therein. The stance of the conceptual framework for class-based object orientation as expressed by Lehrman Madsen, Thomsen, and Nygaard is to my mind therefore a very expectable perpetuation of the most prominent cognitive theories of their time.

In the following I shall review some of the aforementioned distinctions and explain how they may help us move toward a redefinition of object orientation. From observing the broad-brush directions of research in cognition and understanding for the past 40 years and redefining object orientation on the basis of theories different from the mainstream information processing approach, different from the classical amodal approach as well as on alternative underlying philosophy of science assumptions I believe we may develop both a theoretical framework as well as a base of empirical research supportive of a redefinition.

Orthodox information processing accounts of cognition and perception

In the information processing view found in cognitive psychology, humans (the subjects) pick up information about their surrounding world (the object (purposely written in the singular)), interpret that information, store it, and retrieve it later. Hence, the canonical terms are memory ‘encoding’ and ‘retrieval’ (e.g. Baddeley 1997) and the ‘content units’ of these processes are information about the world.

Such an act of ‘processing information about the outside world’ starts with perceiving, auditorily, visually, tactically etc. and perception is thus an element in the cognitive activity. To take the most principal of our senses as example, visual perception takes place when light energy hits a photoreceptor in the retina. Stimulation of the receptor is said to occur when the amount of energy exceeds a certain amount, an excitation threshold. Subsequently, simultaneous stimulations of photoreceptors, jointly constituting the retina, are merged with each other, as well as with other information like the angle between the two respective retinal images acquired from the muscles controlling the eye (binocular disparity). These basic sensations are then somewhat meaningfully arranged through processes of perceptual segregation, e.g. the gestalt principles of form perception (e.g. Köhler 1947) to form percepts. These wholes are then sent on to our higher-order cognitive processes for further ‘processing’ through a process of transduction, which is the process of converting one form of energy into another, for example from the electromagnetic energy (light) of the visual stimuli into neural energy. Where perception stops and higher-order cognition takes over is of course an open research question, but what is important is that that this percept formed from the excitation pattern of the retinal image, is said to be converted or transduced into a neural pattern in working memory (currently the most widely accepted model of memory in mainstream information-processing cognitive psychology, c.f. Baddeley 1997). Owing to the transduction processes, consciousness can treat the result as ‘meaning’ and as such, perception and cognition are conceived as independent and modular systems in the brain, as distinguishable concerns so to speak (alluding to GUI/Model separability).

Evidently, this process is likened to information processing, as (visual) information is collected, refined, modified, or otherwise processed until it appears as an object of our consciousness or in long term memory, a distillate created from ‘basic’ information as light photons or gaseous particles (e.g. by olfactory processing). Meaning are thus chunks of ‘aboutness about the world’ so that our consciousness is able to tell us that ‘that thing’ (percept formed from the retinal image) is a ‘pull-down menu from which I am to choose an item’. In this view, if the transduction did not take place we would not have consciousness and not know which subset of the perceived information to store in memory.

However, this conception of meaning gives rise to what has been called the homunculus problem which is a problem of infinite regress: How do I recognise that thing as a pull-down menu, button, or likewise? What must be occurring in my mind is an image, a retrieval of the stored ‘pull-down menu meaning chunk’, which I recognise as matching the pull-down menu (external to my mind). But who is looking at that image in my mind's eye and recognising that it matches? And what's going on in that person’s mind, and so forth? This is the homuncular regress.

There are several other problems with the information-processing view and its assumptions such as the transductional processes, e.g. the symbol grounding problem, the Chinese Box Problem, intentionality-related problems (Searle 1980) and more, but the above criticism is the most central in relation to our present discussion of object orientation.

The modal/amodal distinction

The aforementioned question of transduction is at the heart of the distinction between modal and amodal theories of knowledge and meaning. Before the twentieth century, theories of knowledge were mainly perceptual with perception, as opposed to higher-order cognitive processes or a notion of ‘semantic memory’, as the locus of meaning. Since then, perception has been relegated the status of input device or recording system, from the outputs of which meaning and knowledge is extracted, as described above and by Madsen et al.

Both a modal and amodal theory of knowledge hold that perceptual states arise in sensory-motor systems after which a subset of the states is stored in some kind of memory. However, the amodal approach hold that this subset is transduced, transformed, into a new nonperceptual representational format. These representational structures are amodal because they bear no correspondence to the perceptual states that produced them, and the two systems (the perceptual and the cognitive) are thus assumed to be different and work according to different principles. Barsalou (1999) notes that it is partly because of the development of programming languages (!) that theories have taken this amodal turn, which he finds regrettable.

Examples of such ‘meaning storage formats’ are feature lists, frames, schemata, semantic nets, production systems, connectionism (Barsalou 1999: p. 578) and some of the quintessential references for this approach are Newell and Simon (1972), Fodor (1975), Pylyshyn (1984), and Haugeland (1985).

The modal approach on the other hand holds that meaning is not abstracted or extrapolated nor semantically different from the perceptual process that gave rise to the neural activation. An amodal theory of knowledge, such as Barsalou’s (1999), posits a convergence of the orthodox distinction of perception and cognition. In fact, Barsalou grounds cognition in perception by providing evidence that neural systems common to imagery and perception underlie functions that are normally, in amodal approaches, conceived as higher-order cognitive functions, e.g. conceptual knowledge, categorial inferences, reasoning, etc. Thus, to the extent that ‘the outside world’ is represented internally, a subset of the neural activation is stored but no transduction or meaning-extraction occurs in a modal theory of knowledge. The subset is stored analogically (bearing direct correspondence to the perceptual state that produced it) and in a post-stimulation situation, it can be retrieved and ‘replayed’ or ‘revived’, so to speak, in the perceptual system (hence modally). Once revived it then can be used for reasoning.

In Barsalou’s view, meaning is inherently perceptual as meaning is the act of perceiving or ‘replaying the perceived’, re-perceiving so to speak. Semantics cannot be abstracted from perception, it lies it to be found in the perception-as-process. But more on this later.

Figure 14: In an amodal theory of knowledge, the meaning of a chair is transduced from perceptual states into distilled meaning represented in a non-perceptual representational format. Figure reproduced from Barsalou 1999 p. 579.

Figure 15: In a modal theory of knowledge, the perceptual state is stored in an analogue format that bears direct correspondence to the perceptual states that produced the neural activity. Figure reproduced from Barsalou 1999 p. 578.

Aristotle and semantic memory research

I believe that Madsen et al.’s description of “the process of knowledge” (pp. 295-296 as cited above) represents exactly such an amodal view as described above and that Aristotelian concepts is their non-perceptual representational format. This would be highly typical of their time as Aristotle’s conception of meaning was similar to virtually all attempts of explaining the relationship between language and the world, i.e. meaning, in both linguistics (e.g. Katz and Fodor 1963) and psychology (e.g. Smith, Shoben, and Ripps 1974) prior to the late 80s (c.f. Kintsch 1980). While an Aristotelian approach may be appropriate to describe a logical system, it proved, according to many researchers (e.g. Baddeley 1997, Kintsch 1980), to be inappropriate for explaining how humans deal with meaning. As Kintsch remarked, basing psychological theories on logical models of meaning” has led semantic memory research into avenues of investigation that are barren and lead nowhere” (Kintsch 1980, p. 605). Madsen et al. acknowledge that other formats such as the prototypical may be ‘better’ (however ‘better’ is to be conceived) but they remain within an amodal and information processing approach, only suggesting an alternative format.

This is the reason I have chosen to call Madsen et al’s view “quasi-epistemological” as I believe their view is in line with a classical ‘raw’ and natural science approach to thinking. I myself believe cognition to be inherently perceptual and modal/analogical and therefore consider a ‘chase of formats’ unfruitful and misguided.

Object orientation as a relativistic or cultural epistemology

Madsen et al. use the term ‘natural perception’ to describe what object orientation makes use of. To my mind ‘natural perception’ or ‘natural cognition’ is an oxymoron. I do not believe of a generic or universal ‘cognitive model’ as would be present in a naked, savage man in a natural undomesticated wilderness. Similarly, I also find Madsen et al.’s reference to ‘natural’ or otherwise unproblematic ‘kindergarten thinking’ to be problematic.

As Hutchins (1995; e.g. p. 169) and countless others (Cole 1998 to name a canonical reference) have shown, our cognitive powers are cultural, artificial or otherwise ‘unnatural’ through and through. We do not exercise our thinking in ‘natural environments’ but create our cognitive abilities by actively constructing environments in which to exercise these abilities. For Hutchins (1995) the ‘constructed environment’ was a ship bridge featuring countless artifacts taking part in the navigation of the ship and in the ‘thinking’ activities of the sailors #7. Similarly, developers exercise their cognitive powers in an environment of object-oriented tools, design patterns, and general object oriented ‘culture’ #8. Thus, object orientation can be seen as a manifestation of just such a subjectivist or cultural epistemology: Computer scientists are trained in natural science thinking, which makes the assumptions of moderate realism in object orientation, that the world is best described in terms of objects and their properties, ideal for this target group #9. If object orientation were used for analytical purposes only, in line with the tradition of using formal methods for knowledge discovery (c.f. Dix 2003), or if it were not dependant on people outside the object-oriented culture I would not necessarily consider it problematic. However, as we have found out in the above, the object-oriented Model System is ‘future meaning’, which makes it highly problematic as it consequently presupposes a coinciding of the empirically realised meaning of the users and the developer’s intended meaning (formalised in the code). Therefore, the cultural epistemology of the object-oriented community is imposed on the users and as Paul Heckel writes in The Elements of Friendly Software Design (1984): “Our instincts and training as engineers encourage us to think logically instead of visually, and this is counterproductive to friendly design.”

To be more precise, I would say that object orientation’s advantage of so-called ‘real-world apprehension’ is about the representational gap between the unit of analysis as a perspective on the world (e.g. a world of functions, procedures, phenomena and concepts or the like) and the formalisms in which the unit of analysis is realised/modelled. But perspective means the programmer’s perspective and if an objectivist ontology is abandoned, codifying future meaning (being dependant on the meaning-formation process of other people than the programmers) in a way only meaningful to the programmer is problematic. Regardless of how close this perspective may be to our education as software engineers.

Toward a redefinition of the modelling process: From physical to suggestive modelling

Hirschheim and Klein’s analysis, as well as many others, show how strongly fundamental assumptions of systems development can influence the outcome. Similarly, the ontological and epistemological assumptions of object orientation will inevitably constitute a certain ‘inherent momentum’ and thus influence the contexts in which object orientation is used.

In the above section it has been claimed that object orientation is reminiscent of ontological and epistemological assumptions of modernity and the natural sciences, and some of the consequences of changing these assumptions have been briefly suggested. Such an update of object orientation, subscribing to an amodern stance, entails a change of the idea of object orientation, the act of modelling, and the meaning of the Model System. The Model System, I have claimed in the above, must assume a more proactive, suggestive, and purposive role toward the ‘construction of meaning’ vis-à-vis the user, which makes it much less secure as it depends on interpretation and the ordering process into which it will enter. The notion that the consequences of introducing a system into an organisation are unpredictable and will change the situation that it was originally designed for is by no means a new idea (e.g. the task-artifact cycle in Carroll et al. 1991). However, object orientation has so far tried to evade the problem by building a model of more ‘stable components’, namely physicality and abstracted truth, which is as far away from the place of interpretation (e.g. the interface and its context of use) as possible. Coordinating one’s code design with the ‘core data’, the underlying order, the deducted truth, is apparently perceived to be more ‘safe’ than coordinating with something as nebulous and fuzzy as the subjective interpretation of users. However, the subjectivity of interpretation does not mean it can escape all scientific explanation or cannot be trusted or relied on. In fact, coordinating with the interpretation or ordering process is the only way, I believe, to insure that the ‘realness’ of the developer’s model is the same as the ‘realness’ of the users’. This was my reason for suggesting a redefinition of the software model as suggestive and purposive and this makes validity become not a question of descriptive correspondence but of closeness of empirically realised meaning vis-à-vis intended meaning.

The above begs the question of which ontological and epistemological material to build such a suggestive and purposive model – this is the subject of the next section.

Theoretical foundations of a redefinition

In the following I shall present an alternative theoretical framework for object orientation. The way I do this, is to present a given theoretical position (or a group of positions) and subsequently pause to account for the consequences in relation to object orientation, an object-oriented system development process, or an object-oriented programming language.

Mind-body and subject-object dualisms

The notion that mind is a non-bodily entity, a ‘soul’, has always been pervasive in Western thinking and can be found in the writings of such early philosophers as Plato. Although many philosophers thus pondered on this matter long before Descartes, he is usually credited as the father of modern mind-body dualism (e.g. Stigen 1992: 387pp ) as expressed in his writings in the 15th century. For him, ‘mind’ meant a soul without physical substance, which according to him was its definitional distinction from structures such as the body and the brain. Res cogitans versus res extensa. This dualism is today an integral and unnoticed part of our way of thinking.

The subject-object distinction is also pervasive in most Western philosophical traditions from Kant, over Hegel, to modern cognitive psychology. The subject-object distinction is a distinction between the thinker and what the thinker thinks about, although this thinking can of course be reflexive as in self-conscious thought. In this view, the world is thus divided into an objective world of physical reality and subjective mental world of thoughts. Despite the fact that in many philosophies the subject-object distinction is only a distinction used for semantic convenience, it seems to have a certain negative ‘inherent momentum’ to it, leading us to ignore the complementarity of the subject and object.

Phenomenology and the action-meaning complementarity

The German phenomenologists were the first to contend with both mind-body dualism and the subject-object dualism (e.g. Husserl 1970). Edmund Husserl (1859-1938) founded the phenomenological tradition out of dissatisfaction with the contemporary trend for ‘scientification’ of the nature of everyday experience.

“Husserl was frustrated by the idea that science and mathematics were increasingly conducted on an abstract plane that was disconnected from human experience and hu

Object-oriented concept according to Madsen et al. (1993)	Class-based object-oriented language, in this case Java
Concept	Class
Phenomenon	Object
Intension	State and behaviour of a class ( attributes and methods)
Extension	Set of objects instantiated from a class
Denotation	Identifier, i.e. a set of identifiers pointing to an object in memory of the same or ‘underlying’ type declaration as the identifier (according to the Liskov substitution principle)
Inheritance, specialisation, and extension	Class inheritance via the ‘extends’ keyword
Aggregation and composition	Class variables (declared public or accessible via get/set methods), usually one does not mean basic data types.