Domain Engineering Week

Monday 2012-05-07 — Thursday 2012-05-10
Dines Bjørner (Technical University of Denmark, DTU)

Dines Bjørner has been working at IBM (1960s & 1970s), Technical University of Denmark (1976 onwards), was founding director of United Nations University's International Institute for Software Technology (UNU-IIST, Macau CN, 1992-1997), and has had numerous guest lecture and research stays all over the world. He has been central in the development of VDM and Raise, and has worked on PL/1 and Ada semantics and tools. The last couple of decades his interest has switched to domain science and engineering.

Programme

Domain engineering is providing the understanding of natural, technical and human phenomena in software related terms. Such a formulation may give genuine insight in the phenomena themselves, but also forms the basis for developing software product lines (SPL). SPL has been shown to significantly (up to a factor of 10) improve software quality and development efficiency, reducing the development cycle from months to weeks.

• Monday 2012-05-07 1415-1600, room 3137:
  Lecture: A Rôle for Domain Engineering in Software Development — Why Current Requirements Engineerng Seems Flawed

  We introduce the notion of domain descriptions (D) in order to ensure that software (S) is right and is the right software, that is, that it is correct with respect to written requirements (R) and that it meets customer expectations (E). The talk will show some formulas but they are really not meant to be read by the speaker, let alone understood, during the talk, by the listeners. They are merely there to bring home the point: Professional software engineering, like other professional engineering branches rely on and use mathematics.
  And it is all very simple to learn and practise anyway!
  We end this talk with, to some, perhaps, controversial remarks: Requirements engineering, as pursued today, researched, taught and practised, is outdated, is thus fundamentally flawed. We shall justify this claim.

• Tuesday 2012-05-08 1015-1600, room 3137:
  A Mini Course in Domain Engineering

  We seek foundations for a possible theory of domain descriptions.

  • 1015 Introduction: Preliminaries. text slides
        Outlines what we mean by a domain. text slides
  • 1115 The entities that form a domain. text slides
  • 1215 Lunch break
  • 1315 Formal description of entities I. text slides
  • 1415 Formal description of entities II.
  • 1515 Domain discoverers. text slides
        Conclusion.
  • 1600 Finish

  There are other ways of formally describing domains. The one exemplified can be taken as generic for other description approaches. The seminars reflect our current thinking.

• Wednesday 2012-05-09 1415-1600, room 3137:
  Lecture: A Role for Mereology in Computing Science — To every mereology there corresponds a λ-Expression

  Leshniewski's (around 1920s) axiom system attempts to avoid Bertrand Russel's problems with classical set theory. In computer science we may think of mereology as a means to analyse the domains (for which we may wish computing support) into some manageable structure (objects etc.). We first present a version of the classical axiom system for mereology. Then a model-oriented formal description of the syntax of parts and part relations. We indicate that the model satisfies the axioms. Then we show how one can translate any mereology into a CSP (Hoare) program.

• Thursday 2012-05-10 1415-1515, room 2144:
  Departmental seminar lecture: Domain Science & Engineering: A New Facet of Informatics

  The goal of domain engineering is to construct a Domain Description. A domain description informally and formally describes - within the bounds of "what can be described" - (usually) a man-made domain such as air traffic, banking, container line shipping, hospital/health care systems, logistics, manufacturing, (gas/oil) pipeline systems, railway systems. stock exchanges, transport, ... Such facets as technology supports, rules & regulations, scripts, management & organisation, ... are tackled, A domain description may thus be studied (and improved upon), theorems derived etc., as are models of one or another physics domain. Domain engineering is as much an applied scientific endeavour in that - at least at the present stage - the outcome of doing a domain description (i.e., modelling a domain) is not known a priori and that the means for modelling are not always at hand. Domain science is then the theoretical foundation for creating models: "what can be described", "mereology", etc. The talk will survey all this and will briefly indicate that domain models can serve as a basis for requirements engineering, a conventional, usually, i.e., till now a first phase of software development. The talk will "flash" facets of models of the example domains listed earlier and will hint at philosophical issues such a mereology and a calculus of domain describers.

Each of the activities are independent of each other and are technically self-contained. The events are open for anybody interested, limited by the capacity of the rooms. They form part of the course INF329 Selected Topics in Programming Technology: Domain Engineering. If at capacity, preference is given to INF329 students.

Room 2144 (stort auditorium) is in Datablokken, Høyteknologisenteret, Thormøhlensgt 55.
Room 3137 is in Datablokken, Høyteknologisenteret, Thormøhlensgt 55.

BLDL seminars 2012