Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456 FORMAL METHODS cum TECHNIQUES
Dines Bjørner's Research Interests
FORMAL METHODS cum TECHNIQUES
Dines Bjørner's Research Interests
Computer Science is, to me, the study and knowledge
about the ``things'' that can exist inside computers: Data and
processes.
Computing Science is, to me, the study and knowledge
about how to construct ``those things'': How to get problems
residing in the world outside the computer to be solved inside the
computer.
As a consequence of this ``soft spectrum'' delineation we may claim that:
Research in computer science proves theorems --
related to models of computation.
Research in computing science ``proves'' methods:
Principles, techniques and tools -- related to perceived, ie.,
mental models of how people develop software.
Computer science is more of a mathematical science,
while computing science is more of an experimental and
explorative science (``discovering & testing'' relevant methods).
The two go hand-in-hand, indspensably so.
It seems more to be
a ``smooth'' spectrum between the two,
rather than two ``isolated'', discrete points.
Further, we can say that:
At my university and in our department we graduate
informatics engineers.
That informatics is the convergence of mathematics, and
the computer &
computing sciences into software engineering applied to actual,
``outside the computer'', applications.
The engineer``walks the bridge'' between science and
technology:
constructs technology based on scientific insight, and
analyses technology so as to ascertain whether it
has scientific value.
The technician composes technological artifacts,
basically without any need for scientific insight.
The technologist is an engineer who deals with
technology in a socio-economic framework.
Before Software can be Designed its
Requirements ought be known.
Before Requirements can be established the
Domain ought be understood.
Hence I work in the triptych area of Domain Engineering,
Requirements
Engineering and Software Design.
Together I call this Software Engineering.
Main Research Interest: Programming Methodology
Thus programming, in my view, spans from:
domain engineering via
requirements engineering to
software design.
By a method I understand:
a set of principles
for selecting and applying
techniques and
tools
in order efficiently to construct
an efficient artifact, here software.
So my endeavour is to
indentify, analyse and formalise (whereever the latter is reasonable)
such principles and techniques. At the moment I am primarily
interested in domain engineering, requirements
engineering,software architecture and
program organisation design. I have identified
a number of core domain engineering issues:
intrinsics, support technology, management & organisation,
rules & regulations, and human behaviour facets as these
also relate to domain stake-holder perspectives. Similarly
I have identified a number of core requirements engineering
issues. In particular domain requirements - with its
subsidiary techniques of projection, instantiation, extension
and initialisation. In domain engineering one
describes the domain without any
reference to Requirements. The new thing here is to establish
theories of domains -- as we have theories of such ``domains'' as
physics, biology, etc.
Derived Research: Infrastructure System
Theories.
On one hand there is the study of the concept of an
`infrastructure' and its `components'.
On the other hand there is the study of
particular such infrastructure components.
As targets of the application of the above-mentioned
programming methodological ideas I apply these to such
infrastructure components as:
Transport:
Railways, Logistics, Air Traffic,
Airports, etc.