- DB's research continues after his retirement at age 70 in 2007.
- After designing hardware equipment for IBM 1962-1969
and working with, first, John W. Backus on reduction languages
and, then, with Ted Codd on relational databases, 1969-1972,
DB "switched" to computer & computing science in 1973 at the
IBM Vienna Lab.
DB understands the knowledge about and
those conceptual phenomena that goes on
Computer science is often also referred to as
DB understands the knowledge about and
how to construct those conceptual phenomena.
Another term for computing science is
DB understands the knowledge
and study of
the engineering practice of software development --
one in which
the artefacts of the software engineer are
considered mathematical entities.
Hence DB's focus on
- DB's view of
is as follows:
- that is, coding can be contemplated,
- one must first have a reasonable grasp of its requirements,
- that is, which properties that software must enjoy.
- one must first have a reasonable grasp of the domain,
- that is, the environment in which the software is to serve.
- So, to DB,
includes three main
the knowledge and study of
analyse and describe domains,
the knowledge and study of
how to analyse and prescribe requirements, and
- Up till around the early 1990s DB's research was mostly
- Since the mid 1990s DB's focus was on
- DB's interest in
when he worked out how requirements prescriptions
derived systematically from domain descriptions [.]
-  From Manifest Domain Descriptions
to Requirements Prescriptions
-  Manifest Domains: Analysis & Description
A New Foundation for Computing Science
To be published: Journal of Algebraic and
Logic Programming (2016)
[ProCoS] How it all Began: As seen from Denmark
To be published: Springer Lecture Notes
Domain Engineering - A Basis for Safety Critical Software.
Australian System Safety Conference, Melbourne, 28-30 May 2014.
It appears that safety analysis conventionally applies to the
requirements and the design phases of software development.
This work steps safety analysis one further step back -- to domain
40 Years of Formal Methods
- Some Obstacles and Some Promises
Co-written with Klaus Havelund. Invited "distinguished lecture" for
Singapore, May 2014.
Domain Analysis: Endurants - An Analysis & Description Process
In Specification, Algebra, and Software: A Festschrift
Symposium in Honor of Kokichi Futatsugi.
Springer, LNCS 8373, pp 1-34, 2013.
Domain Science and Engineering as a Foundation for Computation
Chapter 7, pages 159-177.
Computational Analysis, Synthesis, and Design of Dynamic Systems.
CRC [Francis & Taylor], 2013 (eds.: Justyna Zander and Pieter
A Rôle for Mereology in Domain Science and Engineering
Synthese Library (eds. Claudio Calosi and Pierluigi Graziani).
Springer, Amsterdam, The Netherlands, October 2013.
Domains: Their Simulation, Monitoring and Control -
of Ideas and Suggestions
In Rainbow of Computer Science, Festschrift for Hermann Maurer
on the Occasion of His 70th Anniversary.,
Festschrift (eds. C. Calude,
G. Rozenberg and A. Saloma), pages 167-183. Springer,
Believable Software Management
Encyclopedia of Software Engineering, 1(1):1-32, 2011.
From Domains to Requirements
Montanari Festschrift, volume 5065 of LNCS (eds. Pierpaolo Degano, Rocco De Nicola and José
pages 1-30, Heidelberg, May 2008. Springer.
With Asger Eir.
Compositionality: Ontology and Mereology of Domains.
Observations in the Context of Software Engineering.
eds. Martin Steffen, Dennis Dams and Ulrich Hannemann.
Festschrift for Prof. Willem Paul de Roever Concurrency,
Compositionality, and Correctness,
Volume 5930 of LNCS,
pages 22-59, Heidelberg, July 2010. Springer.
- Throughout 40 years DB's research focus has been on
- That is, studying and teaching
how to construct
- This is in contrast to studying and teaching computer science.
- Studying and teaching computing science is not about neat, small
- There are really no propositions, lemmas and theorems.
- No neat proofs.
- It appears that papers on methodology are harder to get
- Most editors and most referees judge papers in our area
based on criteria of (theoretical) computer science.
- Most institute and department heads seems to
the distinction between computer and computing science.
My research, since my leaving the IBM Vienna Laboratory in 1976,
has been based almost exclusively on extensive experiments: you may
call them advanced "prototype" developments, that is, developments
containing a large degree of trial-and-error and rough-sketching, and
aiming, as they are these days, on documenting pleasing domain
descriptions and "therefrom derived" requirements prescriptions.
Out of these experiments then come a number of observations - and
these then form the contents of my research papers.
My research, since my IBM Vienna days, has focused on
computing science, in particular
programming methodology: on how to construct
software. I was never much for the more foundational side of
computing, or as I call it, computer science.
I am in particular "smitten" by the question what is a
method ? I see a method as a set of principles to be used in the
analysis of problems and in the synthesis of solutions to these
problems. I see the analysis and synthesis to be based on techniques
and tools. The principles are then about the selection and practical
use of the analysis
and synthesis techniques and tools -- research must uncover these
principles, techniques and tools. Software engineering textbooks must
I see a good software development method to be one that
provides for efficient development approaches resulting in efficient
software that meets customers expectations (and only and exactly
those) and software that is correct (that is satisfies its
From the IBM Vienna days, and for many years after, into the early 1980s,
my research interests sprang from a core of semantics of programming
languages. It all really started with the PL/I project of the IBM
Vienna Laboratory, , with a fall out from my work
for John Warner Backus, , and my work at the IBM
ACS/1 Laboratory, , being minor precursors. I am still
of the strong conviction that every professional software engineer
must be strongly versed in the formal and applied aspects of syntax
and semantics - with semantics being the "real thing"!
Gradually, and also under the impression of the work of the members of
IFIP Working Groups 2.2 and (notably) 2.3, my interest swung in the
direction the software transformation from formal specification to
actual code;  is, but an early example. Throughout
the 1980s I published many papers in this area and also wrote and
rewrote, until the end of the 1990s, several rather complete sets of
lecture notes based -- notably -- on my research, the latest version
Further, and again, gradually, my interest widened to first study the
software engineering field of requirements engineering, then onto
domain engineering (and, lastly, to its foundations: domain science
[22,32,20,]). Since I was
not satisfied with what I read up on requirements engineering I
started thinking "programming language semantically": what
lies "before" requirements engineering ? My answer was, to me,
quite obvious: the language of the domain for which the requirements
are to be written, therefore we must try understand that language,
that is, its semantic types, as much as possible, before we can write
down the requirements. Thus was born "my version" of domain
engineering. At that time I took up the position as first and founding
UN Director of the UN University's research and post-graduate
training center, UNU-IIST.
At UNU-IIST we applied the idea of describing domains, also formally,
to railways (China), banking (Russia), ministries of finance
(Vietnam), telecommunications (The Philippines), etc., and a view
emerged, which found a first form in  - presented in
April 1996 to Academia Europaea's Informatics Section. My methodology
work on domain engineering has developed since and now accounts for
most of my publications since the late 1990s.
In my work on domain engineering I "discovered" that core aspects of
requirements prescriptions can be "derived" in a systematic, but not
formal manner from domain prescriptions, and related back to these in
a formal way. This solved the uneasiness I had always had with most of
the `Requirements Engineering' literature.
It also took the form of a complete rewrite of  into
[49,50,51](2006). The structure of this
2414 page book took form during a PhD School I lectured at near Minho,
Portugal, kindly invited there by Prof. Jose Nuno de Oliveira.
But I was not finished with domain engineering in 2006 although it
became quite a corner stone of . I wrote many
papers and - spurred on by better didactical understandings,
improved pedagogical approaches and opportunities to present this in
PhD course forms:
I wrote, in succession the Internet-based lecture notes
- Natl. Univ. of Singapore (2004-2005),
- JAIST (Kanazawa, Japan, 2006),
- Univ. Henri Poincaré (Nancy, France, Fall 2007),
- Techn. Univ. of Graz (Austria, Fall 2008),
- Univ. of Saarland (Germany, Spring 2009)
- Univ. of Edinburgh (Scotland, Sept.-Oct., 2009),
- Univ. of Tokyo (Japan, Nov.-Dec., 2009),
- Techn. Univ. of Vienna (Austria, April, 2010),
- Eötvös Lorant Univ. (Hungary, Budapest, Oct. 2010),
- Uppsala Univ. (Sweden, Nov. 2010,
- Univ. or Bergen (Norway, May 2012),
- Peking Univ. (China, Nov. 2012),
- East China Normal Univ. (Shanghai, Dec. 2012)