FORMAL METHODS cum TECHNIQUES
Dines Bjørner's Research Interests

Technical University of Denmark

January 11, 2006
db@imm.dtu.dk

The Basics

• I was part of the team which first developed, researched and applied
  VDM: The Vienna Development Method.
  • Click !
• I was the instigator of the development of, research into and am, today, a "user" of
  RAISE: Rigorous Approach to Industrial Software Engineering.
  • UNU/IIST: Click !
  • Dines Bjørner: Click !
  • Terma, Inc.: Click !
• I am interested in all programming and software engineering aspects of formal methods -
  - but prefer to call it formal techniques.
• I have recently published three textbooks - with Springer - on "all" aspects of formal methods/techniques in software engineering.

Some Dogmas

• On Computer vs. Computing Science:
  • 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, indispensably 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.

References

• Please click for references and access to my Reports and Publications

Towards a TripTych of Formal Software Development

• The Paradigm:
  • 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.
    

    I am currently working on a domain model for multi-modal transportation nets. This documents is, as of January 12, rather incomplete.

    Such models ought be of interest to companies like:

    • Alstom,
    • Alcatel--Dassault Transportation (Thales),
    • Atkins (Denmark),
    • Banestyrelsen: Danish National Railway Authority,
    • Bombardier Transportation,
    • Copenhagen Airports,
    • DSB: Danish ``State'' Railways,
    • GE Transportation Systems, Global Signalling,
    • Pacific Railways,
    • Scandinavian Airlines (SAS),
    • Siemens Transportation Systems,
    • Transvision (Denmark),

    I can provide references to many reports and publications concerning this area.

  The below entries will soon be equipped with appropriate URLs.

  • Financial Service Industry: Banking, Insurance, Securities Trading, etc.

    Ought be of interest to companies like:

    • Danica (insurance),
    • Danish National Stock Exchange,
    • Danske Bank + BG Bank,
    • Hitachi,
    • IBM,
    • Jyske Bank,
    • Nordea,
    • TopDanmark (insurance),
    • Unisys, etc.

    I can provide references to reports concerning this area.

  • Healthcare Sector: Flow of people, materials, information and control in the healthcare secotr - patient medical jounrals being a first study.

    Ought be of interest to companies like:

    • H:S + KAS (Copenhagen Capital City and Province Hospitals),
    • IBM,
    • Sundhedsstyrelsen (Danish National Board of Health),
    • Systematic,
    • Tieto Enator,
    • WM Data,
    • etc.

    We can provide references to reports concerning this area.

  • Electronic Business / Electronic Government:

    The published paper ... The Market Domain .... ought be of interest to companies interested in E-Commerce.

  • Project and Production Planning and Execution:

    I am currently working on a domain model of manufacturing. This documents is, as of January 12, VERY incomplete.

    Ought be of interest to companies like:

    • Baan,
    • Computer Associates,
    • Maconomy,
    • Microsoft Business Solutions Denmark (Navision),
    • SAP,
    • etc.

    I can provide references to reports concerning this area.

• The Infrastructure Paradigm Question:

  An aim is -- eventually -- to identify infrastructure component theories, and thereby to better answer the question: ``What is an Infrastructure ?''

...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...

About this document ...

FORMAL METHODS cum TECHNIQUES
Dines Bjørner's Research Interests

This document was generated using the LaTeX2HTML translator Version 2002-2-1 (1.70)

Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

The command line arguments were:
latex2html -split 0 -toc_depth 6 research

The translation was initiated by on 2006-01-11