RE-THINKING SOFTWARE ENGINEERING APPROACHES:
A CRITICAL REFLECTION ON THEORY BUILDING
Balbir S. Barn and Tony Clark
Middlesex University, The Burroughs, London, U.K.
Keywords:
Theory building, Modeling, Software engineering.
Abstract:
This paper re-appraises Peter Naur’s influential paper on Programming as Theory Building in the context of
modern software engineering practice. The central argument is that such practice is focussed primarily on
methods, notations, lifecycles and the description of artifacts such as models. Instead we propose that a theory
building view is more appropriate, and that the concept of a theory should underpin a software design process
which then calls for new tools and a new research agenda.
1 INTRODUCTION
This account sets out to re-appraise Peter Naur’s in-
fluential paper on Programming as Theory Building
(Naur, 1985) in the context of software engineering
practice and in particular the model building focus of
the last few years. We contend that software engi-
neering in its efforts to establish itself as a science
has focussed exclusively on methodology, lifecycles,
processes and the description of artifacts. This we be-
lieve has lead to an number of emergent issues no-
tably, there are too many methods, the processes of
software design are bloated and a focus on the pro-
duction of artifacts without evaluation of the good-
ness of artifacts. These points were first raised by
Naur and we propose a return to a more fundamen-
tal re-think originating from a re-appraisal of Naur’s
work on theory building. In doing so, we suggest that
making theory building the core unit of focus in the
software process will create new insights into the de-
sign of software and open avenues of research that are
rooted in the Philosophy of Science.
The starting point for this work has been triggered
by the extent of activity that is currently surrounding
Enterprise Architecture. As systems supporting busi-
ness become increasingly more significant and com-
plex an important approach to management and plan-
ning of systems that has gained prominence is model-
based Enterprise Architecture (EA). EA has its ori-
gins in Zachman’s original EA framework (Zachman,
1999) while other leading examples include the Open
Group Architecture Framework (TOGAF) (Spencer,
2004) and the framework promulgated by the De-
partment of Defense (DoDAF) (Wisnosky and Vogel,
2004). In addition to frameworks that describe the na-
ture of models required for EA, modeling languages
specifically designed for EA have also emerged. One
leading architecture modelling language is Archimate
(Lankhorst et al., 2010).
Central to enterprise architecture is the notion of
development and presentation of models. Given the
plethora of models available two concerns of note
arise: Firstly, given the range of models available, it is
difficult to ascertain why a particular model is relevant
and preferable over others. This arises from a lack of
clarity of the link between the contents and structure
of a model on one hand and its purpose on the other
(Johnson et al., 2004). If the general purpose of mod-
els is to answer questions then we need to have a clear
understanding of why we use the models we do. Sec-
ondly, evaluation of quality of models in general, and
therefore EA models, is relatively under researched.
While there are international standards for software
systems there is “little agreement among experts as to
what makes a “good” model” (Moody, 2005). Partly
this may be attributed to a relatively immature field,
or more likely, the production of a model is a socio-
technical event so evaluation is against a person’s tacit
needs. Others assert a “good” model is not an inher-
ent property rather it is how effective it is in support-
ing the analyses conducted against it. Each analysis
or question of an EA model might require different
perspectives or slices of information. Empirical mea-
surements of the goodness of an EA model are gener-
59
S. Barn B. and Clark T..
RE-THINKING SOFTWARE ENGINEERING APPROACHES: A CRITICAL REFLECTION ON THEORY BUILDING.
DOI: 10.5220/0003610700590064
In Proceedings of the 6th International Conference on Software and Database Technologies (ICSOFT-2011), pages 59-64
ISBN: 978-989-8425-76-8
Copyright
c
2011 SCITEPRESS (Science and Technology Publications, Lda.)
ally lacking in the literature.
How these requirements are aligned to Naur’s the-
ory building view and whether the questioning the
“why” of a model and its “goodness” is fundamen-
tal to assessing the efficacy of a model in representing
knowledge of a domain. It is these aspects that we be-
lieve that a re-appraisal of Naur’s ideas will provide a
new insight.
The remainder of the paper is structured as fol-
lows: Section 2 outlines the main hypotheses posed
by Naur and presents a more detailed analysis of as-
pects of some of the key issues raised by current soft-
ware engineering practice (programs as models and
methods). Section 3 presents our hypothesis of mak-
ing theory building central to the software engineer-
ing process. Section 4 presents the main conclusions
and an indication of future research in this area.
2 REFLECTIONS ON NAUR
Peter Naur wrote “Programming as Theory Building”
in 1985, it was reprinted later in his collection of
works, Computing: A Human Activity in 1992 (Naur,
1992). The paper presents a discussion that con-
tributes to what programming is. While it is tempting
to assume from the title of the paper that Naur is fo-
cused on the minutiae of programming, he is specific
in that programming denotes the “whole activity of
design and implementation” and thus his theory ap-
plies to the field of software engineering. The fun-
damental premise asserts that programming should
be regarded as an activity by which programmers
achieve a certain insight or theory of some aspect of
the domain that they are addressing. The knowledge,
insight or theory that the programmer has come into
possession of is a theory in the sense of Ryle (Ryle,
1949). That is, a person who has a theory knows
how to do certain things and can support the actual
doing with explanations, justifications and responses
to queries. That insight or theory is primarily one of
building up a certain kind of knowledge that is intrin-
sic to the programmer whilst any auxiliary documen-
tation remains a secondary product. Of particular in-
terest, is how Naur explains the life-cycle of a pro-
gram. Programs are created by the establishment of
a theory, the maintenance of a program is dependent
on the theory being transferred between program-
mers; and the program dies when the theory has de-
cayed. Program revival is described as re-establishing
the theory behind the program which cannot be done
merely from documentation and should only be con-
sidered in exceptional circumstances as the cost of
theory revival is prohibitive and the resulting theory
may be different from that originally conceived.
In addition to the theory view of a program life
cycle, he also directed criticism at the then signifi-
cant emphasis of methods for program development.
He claimed that the methods based on sequences of
actions of certain kinds cannot lead to the develop-
ment of a theory of the program because the intrinsic
knowledge held by a human has no inherent division
into parts nor an inherent ordering. Instead the person
possessing the knowledge is able to present multiple
viewpoints as responses to requests. Where methods
were supplemented with notations or formalizations
then these were treated as secondary items as the the-
ory of a program is intrinsic and cannot be expressed.
Thus: “...there can be no right method”.
2.1 Programs as Models
Naur was concerned with programs, but Enterprise
Architecture is concerned with the production of
models of interconnected systems or components.
Thus we need to explore the relationship between pro-
grams and models and use that as a basis for analysing
the applicability of Naur’s hypothesisin the context of
Enterprise Architecture.
A major activity in software engineering and com-
puter science in general is modelling and as Fetzer
has noted “the role of models in computer science ap-
pears to be even more pervasive than has been gen-
erally acknowledged..”(Fetzer, 1999). A key feature
of modelling is the existence of an isomorphic rela-
tionship between the parts of the model and the parts
of the thing modelled at some level of abstraction.
Smith whilst noting these different types of models
emphasizes the nature and importance of “representa-
tion”(Smith, 1991) :
“To build a model is to conceive of the world
in a certain delimited way... Computers have
a special dependence on these models: you
write an explicit description of the model
down inside the computer...”.
Smith suggests this feature distinguishes computers
from other machines because they run by manipulat-
ing representations. “Thus there is no computation
without representation” (Smith, 1991, p, 360) If we
pursue this analysis further: From Naur we can state
that the program is a theory; from general computa-
tion principles, we can state: the program is a model.
This leads to the notion that there is an equivalence
between program = theory = model. We might mod-
erate this further by noting that a program is a repre-
sentation of a slice of “the” theory. In general though,
this blurring between programs, theories and mod-
els is confusing and inaccurate. While models may
ICSOFT 2011 - 6th International Conference on Software and Data Technologies
60
exhibit an isomorphic relationship with their subject
matter, this relationship may not reveal the theoreti-
cal connections that allow the theory to be defended
in the form of Ryle’s definition of a theory. Ideally,
then, the theory must be statable independent of the
computer model. In an essay that predates Naur’s pa-
per but still based on a prevailing view of the time that
programs are theories, James Moor notes:
“My claim is that this is rarely, if ever, the
correct response. Even if there is some the-
ory behind a model, it cannot be obtained by
simply examining the computer program. The
program will be a collection of instructions
which are not true or false, but the theory will
be a collection of statements which are true
or false. Thus, the program must be inter-
preted in order to generate a theory. Abstract-
ing a theory from the program is not a sim-
ple matter for different groupings of the pro-
gram can generate different theories. There-
fore, to the extent that a program, understood
as a model, embodies one theory it may well
embody many theories.”(Moor, 1978, p.221)
From this analysis arises two key concerns. Firstly,
programs and models may have multiple theories and
a program or model may not refer to the same the-
ory. Secondly these theories must be state-able inde-
pendent of the program or the model. Then, there is
an additional dichotomy: Is a program a representa-
tion of one view of an aggregate theory or is the pro-
gram a representation of a component theory of the
aggregate theory? These complexities, in the case of
Naur’s Programming as theory perspective have im-
plications, because if the program is the only vehicle
through which a theory can demonstrate that require-
ments of the intended system have been met, then,
that theory testing process comes too late in the sys-
tem life cycle.
2.2 On Methods and Theory Building
Earlier we noted that Naur had reserved considerable
criticism for methods. We develop this discussion fur-
ther in this section. The tendency of methods research
in the IS discipline is to propose algorithmic steps to
analysing and designing solutions to problems. As
Naur notes: A method implies a claim that program
development can and should proceed as a sequence of
actions leading to a particular kind of documented re-
sult”. In contrast, a theory building view holds that
a theory held by a person has no inherent division
into parts and no inherent ordering”. At large, IS/SE
research is embarked on a journey based on epistemo-
logical foundations and as a consequence has mostly
neglected techne (the technical know how of getting
things done) and phronosis (wisdom derived from so-
cialised practices) (Wyssusek, 2007). In a more gen-
eralised form, this has correspondence to the distinc-
tions between explicit and tacit knowledge (Nonaka
and Takeuchi, 1995) and Naur would seem to be argu-
ing the case for methods research that suggests more
attunement with the effects that methods may have in
the education of programmers. That is, the creation
and embedding of tacit knowledge rather than the pro-
duction of artifacts representing explicit knowledge
through an algorithmic process.
Naur cites a study of five different methods by
Floyd et al (cited here for completeness (Floyd,
1984))where the key result that a system of rules will
lead to good solutions is an illusion, what remains is
the effect of methods on the education of program-
mers. Thus the use of methods may themselves not
lead to a good design but the practice of the method
may lead to a better innate ability for theory building.
Much research in IS literature relates to methods for
IS development but this point is absent until we con-
sider the advent of what we mightterm as micro meth-
ods - such as the literature surrounding Design Pat-
terns (Gamma et al., 1995). Here Naur seems to have
predicted the advent of design patterns approaches to
theory building: “the quality of the theory built by a
programmer will depend to a large extent on the pro-
grammers familiarity with model solutions of typical
problems with techniques of description and verifica-
tion and with principles of structuring systems con-
sisting of many parts in complicated interactions.”.
If the quality of the theory that a programmer has
developed will depend on the familiarity of the pro-
grammer with a specific class of problem and perhaps
the clarity of the question to be asked then methods
that create a familiarity with model solutions of typ-
ical problems will be more effective. This of course
resonates with the shift towards design patterns, anal-
ysis patterns and even enterprise architecture patterns
where there has been a focus on capturing explicit
knowledge as pattern solutions to specific problems.
The class of problem under consideration is a key is-
sue. It is clearly true that some classes of programs
are easier than others (clerical versus algorithmic).
Clerical programs that require little or no algorith-
mic complexity are more amenable to automation and
have less need for theory building. A good example
where program = model and methods to arrive at a
theory of a program occurred when Texas Instruments
and (later Sterling Software Ltd) developed the Infor-
mation Engineering Facility (IEF) - a model driven
environment that used an integrated set of diagrams
and modeling notation to generate relatively low com-
RE-THINKING SOFTWARE ENGINEERING APPROACHES: A CRITICAL REFLECTION ON THEORY BUILDING
61
plexity applications such as air-line frequentflyer pro-
grams (Texas-Instruments, 1988) .
Another aspect of methods is the use of notations
and languages. Here, Naur is quite damning. For
him notations or formalizations are treated as sec-
ondary items as the theory is intrinsic and cannot be
expressed. Thus: “...there can be no right method”.
Given that the theory is intrinsic to the human
much like tacit knowledge there may be more than
one way of “knowing” how to ride a bicycle and as
we can’t explicate that knowledge, then these mul-
tiple theories may exist. This is consistent with the
Popperian understanding that questions the notion of
“the” theory. Naur however, in his discussions around
program revival suggests that a program cannot be
revived (i.e. its theory re-constituted) from axillary
documentation alone. The programmers that origi-
nally conceived the theory must be present. Naur
would seem to preclude the existence of the multiple
views of theories. For us then something interesting
emerges: the notion of theory evolution from the ini-
tial theory construction to the various viewpoints of
theories. If such collections of theories are to be man-
aged, then methods and emerging tools that support
domain specific modelling are critical. One potential
benefit from theory slicing using viewpoints, is that
a viewpoint constructed for a model and a viewpoint
constructed for a program can be compared as there
is a common language underpinning all viewpoints.
Such comparison and reasoning may provide a route
to addressing the issue of the ‘quality’ or ‘goodness’
of a model. Figure 1 presents a conceptual model of
emerging concepts and relationshipsaround howmul-
tiple theories, programs and models relate.
Figure 1: Domain theories, programs and models.
3 THE PROPOSED APPROACH
The need for requirements or domain level under-
standing is critical as that is the start of all software
engineeringactivity. A key aim of domain specific ap-
proaches is to provide abstractions that are meaning-
ful to a domain expert and which shield the developer
from having to work in terms of implementation con-
cepts. However, technologies for performing domain
specific modelling often focus more on the syntactic
or structural features of the domain rather than their
meaning. Following Naur we argue that the act of do-
main specific modelling involves the construction of
theories that represent features from the application
domain.
A theory is a set of statements about a domain.
There is no limitation to the level of detail expressed
by a theory, and in particular it is not limited to ex-
pressing functional features about an application. A
theory should capture a description of a system from
a particular stakeholder viewpoint and there may be
many different theories about the same system. For
example, a theory may describe the responses for a
set of user operations. Another theory may describe
features of the user interface in terms of usability
and ergonomics. A further theory may describe non-
functional requirements such as quality of service, re-
source cost, and operational resilience.
A theory must be able to determine which state-
ments about the system are true and which are false.
A theory should allow stakeholders to express theo-
rems: statements about the system that may or may
not be true, and be able to determine whether these
statements are true or not.
An important feature of a theory is that it provides
a language for expressing theorems and thereby al-
lows stakeholders to specify both desirable and un-
desirable system properties. It must be possible to de-
duce whether a given theorem is true using the theory,
although there is no requirement that the deduction is
automatic.
Theories should be transformable so that one the-
ory can be translated into another theory in a way that
preserves the truth or otherwise of the theorems. This
is important to be able to work at an appropriate level
of abstraction (a domain specific theory) and then to
embed the theory into a theory about an implemen-
tation technology (semantics preserving code genera-
tion).
Theories should be compositional so that different
stakeholder views can be merged into a single theory.
It is important that the composition mechanisms can
determine whether or not the resulting theory is con-
sistent, i.e. that no theorems in the component theori-
ICSOFT 2011 - 6th International Conference on Software and Data Technologies
62
es are contradictory.
Our proposal is for theory building to be placed at
the centre of system development and for the theory
to be the foundational artifact. Theories can then be
used to unify different phases of system development
including specification, design, implementation and
maintenance. Each phase is characterized by prop-
erties of the theories, however, in principle, the same
meta-technology can be used throughout:
Specification is characterized by multiple theories
that capture different functional and non-functional
properties of the required system.
Design is characterized by theories that describe
the system in terms of an idealized engine. Specifi-
cation is linked to design using theory mappings that
embed the required properties into idealized execu-
tions.
Implementation is characterized by theories in
terms of a technology platform and design theories
are translated in much the same way as advocated by
Model Driven Architecture approaches.
Maintenance is characterized by understanding a
provided system in terms of implementation theories
and then abstracting execution details through design
and into specification-level theories.
The following diagram shows aspects of the pro-
cess:
Figure 2: Theory Building Process.
The diagram above shows how a developer inter-
acts with the system development process based on
theories and is not intended to prescribe any particu-
lar method. For example, starting with the conceptu-
alization of a system, the developer constructs a the-
ory in terms of its desirable properties. Slices of the
theory give aspects of the system that can be made in-
creasingly concrete to produce executable models of
the system. MDA principles can be applied to the ex-
ecutable models in order to produce the source code
and other artifacts. The developer above may be in-
terpreted as a new project member whose task is to
quickly become a productive contributor. The project
member is introduced to various abstract theories that
capture aspects of the system and which are linked to
the executable code via mappings. The project mem-
ber must understand the theory languages (far simpler
than the implementation code) and can test their un-
derstanding by formulating new theorems, checking
their validity and tracing their deduction through to
code. Interpreting the diagram in reverse allows us
to use theories to address the issue of program main-
tenance and re-engineering. In this case, an exist-
ing system and its associated artifacts are analyzed in
order to produce partial models that can be formu-
lated as theorems about aspects of the system’s exe-
cution. These descriptions can be constructed using
code inspection, existing reverse engineering tools,
discussions with human experts, reading documenta-
tion, and most likely by a mixture of all of these. By
abstracting the concrete theorems it is possible to pro-
duce partial theories that can be composed to produce
one or more complete abstract descriptions. By main-
taining the system in terms of theories, our claim is
that the overhead of understanding and maintaining
the system (the knowledge management problem) is
reduced.
4 CONCLUSIONS
This paper has proposed that the current focus on soft-
ware engineering from the perspectives of methods,
lifecycles, and descriptions of artifacts has led to a
number of problems notably the a large number of
methods that have little or no research evidence that
provides data on a method’s efficacy; bloated life-
cycle processes such as those exemplified by TOGAF;
over-engineered artifact design arising from concepts
and notations that have little semantic integrity such
that the models produced are difficult to assess as to
their “goodness”. Radically we have proposed that
theory building and the core features of the notion of
a theory may address these issues. We have not pro-
posed how tools may be built , instead we suggest that
there is the potential for a new emerging agenda on
theory building.
REFERENCES
Fetzer, J. (1999). The role of models in computer science.
The Monist, 82:20:36.
Floyd, C. (1984). Eine untersuchung von software-
entwicklungsmethoden. In Programmierumgebungen
und Compiler, pages 248–274.
RE-THINKING SOFTWARE ENGINEERING APPROACHES: A CRITICAL REFLECTION ON THEORY BUILDING
63
Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1995).
Design patterns: elements of reusable object-oriented
software. Addison-Wesley Professional.
Johnson, P., Ekstedt, M., Silva, E., and Plazaola, L. (2004).
Using enterprise architecture for cio decision-making:
On the importance of theory. In Proceedings of the
2nd Annual Conference on Systems Engineering Re-
search (CSER).
Lankhorst, M. M., Proper, H. A., and Jonkers, H. (2010).
The anatomy of the archimate language. IJISMD,
1(1):1–32.
Moody, D. L. (2005). Theoretical and practical issues in
evaluating the quality of conceptual models: current
state and future directions. Data Knowl. Eng., 55:243–
276.
Moor, J. H. (1978). Three myths of computer sci-
ence. British Journal for the Philosophy of Science,
29(3):213–222.
Naur, P. (1985). Programming as theory building. Micro-
processing and Microprogramming, 15(5):253–261.
Naur, P. (1992). Computing: a human activity. ACM New
York.
Nonaka, I. and Takeuchi, H. (1995). The knowledge creat-
ing company. Oxford University Press.
Ryle, G. (1949). The concept of mind. University Of
Chicago Press.
Smith, B. (1991). Limits of correctness in computers. Aca-
demic Press Professional, Inc.
Spencer, J. e. a. (2004). TOGAF Enterprise Edition Version
8.1. Van Haren Publishing.
Texas-Instruments (1988). A guide to information engineer-
ing using the ief: Computer-aided planning, analysis,
and design. Technical report, Texas Instruments Inc.
Wisnosky, D. and Vogel, J. (2004). DoDAF Wizdom: A
Practical Guide to Planning, Managing and Execut-
ing Projects to Build Enterprise Architectures Using
the Department of Defense Architecture Framework
(DoDAF). Wizdom Systems, Inc.
Wyssusek, B. (2007). A philosophical re-appraisal of peter
naur’s notion of "programming as theory building". In
Proceedings of the 15th European Conference on In-
formation Systems (ECIS), pages 1505–1514.
Zachman, J. (1999). A framework for information systems
architecture. IBM systems journal, pages 454–470.
ICSOFT 2011 - 6th International Conference on Software and Data Technologies
64