Research - February 11, 2018

General - on Domain Science & Engineering

A List of Recent Work

"Older" Publications related to Domains

Programming Methodology versus Theoretical Computer Science

An "Old" Note on My Research

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 cover them. 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 requirements).

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, [190], with a fall out from my work for John Warner Backus, [192], and my work at the IBM ACS/1 Laboratory, [193], 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; [185] 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 was [160](1987).

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 [29,39,27,]). 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 [112] - 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 [160] into [56,57,58](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 [58]. 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 [50,40,35](2008,2009,2010).

Dines Bjorner 2018-02-11