Subsections
- By
computer science
I understand the study and
knowledge
of the "things" that can "exist inside" computing
devices (i.e., data and computations) –
and the study and
knowledge of computing devices.
- By
computing science
I understand the study and
knowledge of how to construct "those things", i.e.,
p
rogramming methodology
.
I consider myself a computing scientist primarily interested in
programming methodology.
- By a
method
I understand
a set of
principles
for
selecting
and
applying
a set of
techniques
and
tools
for the
construction
of an artifact, as here software.
- By a
formal method
I understand I understand
a method
whose principles, techniques and tools
can be understood in a
mathematical framework –
for example where, among the tools the
specification languages
can be given
a
mathemtical syntax
, a
mathematical semantics
and
a
mathematical proof system
.
I consider myself to have primarily contributed to the area of formal
methods, e.g.,
VDM
and
RAISE
.
- Before
software
can be designed
we must be
familiar with its requirements.
- Before
requirements
can be precribed
we must be familiar with
the context of the software to be developed,
that is, the
domain
.
- Hence the triptych of software development:
- first (ideally) the
domain engineering
of an appropriate domain description;
- then (ideally) the
requirements engineering
of the
requirements prescription formally related to the domain
description;
- finally the
software design
"derived" from the requirements
prescription
and (ideally) formally reasoned to
meet customers'
expectations
,
that is, to satisfy the domain description
and
be correct
wrt. the requirements prescription.
My contributions in the last many years has been to establish a proper
domain science & engineering
.
My main focus, since 1977, has been on the development of "large"
software:
compilers (like for CHILL and Ada),
and human artifact infrastructure software
(for pipelines, railways, health
care, banking, road traffic, container terminal ports, etc.).
A recent focus since 2017, has also been on
- [2]
Kai Sørlander's
Philosophy – An Interpretation/Translation,
Fall 2021
- [13]
A Philosophy Basis for Domain Science &
Engineering ?
January 2019.
- [17]
A Philosophy of Domain Science &
Engineering –
An Interpretation of Kai
Sørlander's Philosophy,
Spring 2018.
- Publications
[3,5,16,22,23,25]
indicate a rather different approach to
software engineering than is
currently en vogue.
- Instead of starting with coding programs, studying and teaching these,
- [3,5,16,23] suggests
that we start with studying the application domain,
research its wider implications, describing varieties of subsets;
- [22] then proceed by analysing and
prescribing requirements
based on a suitably delineated domain
description; and
- [75,76,77] finally developing the
code as outline in these three text books.
- As it is today nobody takes domain science & engineering seriously.
- Think of that.
- Think of civil engineering, mechanical engineering, electrical
enginering and chemical engineering
proceeding on a basis of there being no scientifc physics and
chemistry evidence.
- We are doing it all the wrong way around !
- We have to reorganise our university curricula.
- We have to reorganise our research agendas.
