June 12-15, 2006 JAIST Open Seminar, Tokyo:
Domain Engineering and its Rôle in Software Engineering

Dines Bjørner

School of Information Science, JAIST

May 15, 2006

Abstract:

JAIST offers a four day, three hour per day free evening seminar at its facilities in Tokyo, June 12-15. The seminar topic is domain engineering and its rôle in software engineering.

The seminar is directed at both practicing software engineers, their management, and at researchers in computing science and software engineering.

The aims of the seminar are to cover such topics as what is a domain, what is a domain description, what is domain engineering, and how does domain engineering relate to requirements engineering?

The objectives of the seminar are (1) to enable its participants to better develop trustworthy (1.1) descriptions of domains and (1.2) prescriptions of software requirements for applications within such domains, (2) to instill in its participants a new, fresh view on software engineering, and (3) help ensure that academia and industry can embark on grand challenge descriptions of societal infrastructure domains.

The style of the four day evening seminar is informative, informal and relaxed.

The seminar will illustrate samples of descriptions of such domains as the financial service industry, transportation, and the consumer market.

Contents

• The Dogma of Domain Engineering - the Triptych Approach
• Seminar Aims & Objectives
  • Seminar Aims
  • Seminar Objectives
  
  
• Seminar Style
• Seminar Lecture Notes
  • Background Book
  
  
• Bibliography
  • Handouts
  
  
• Lecture Schedule and Contents
  • Lecture Schedule
  • Lecture Contents
    • Lecture #1: Overview of Domain Engineering
    • Lecture #2: Domain Description Principles
    • Lecture #3: Domain Facets
    • Lecture #4: Domain and Software Requirements
  
  
• Registration: By Simple E-mails
• Venue
• Follow-up Course
• Welcome

The Dogma of Domain Engineering - the Triptych Approach

Before software can be designed we must understand its requirements.

Before we can prescribe requirements we must understand the domain.

So software engineering, to us, consists of

• domain engineering -- which produces domain descriptions,
• requirements engineering -- which produces requirements prescriptions, and
• software design (&c.!) -- which produces specifications of high level designs, intermediate level designs and code (&c.!).

Seminar Aims & Objectives

Aims are about what we cover in the lectures. Objectives are about what we wish to achieve with the lectures.

Seminar Aims

We will overview and exemplify answers to the following questions:

• "what is domain engineering?",
• "how does one describe domains?",
• "what do domain descriptions contain?"
• "how do we develop requirements prescriptions from domain descriptions?"

Seminar Objectives

An immediate objective of the lectures is to enable the participants to better produce well-structured, readable informal, yet concise descriptions (and prescriptions) of matters related to software.

A medium range, perhaps wishful objective of the lectures (and of the lecturer) is to have the participants at these lectures go home, at the end of the ``lecture week'', with the following expressible impressions:

• "now I know why requirements engineering was so problematic before",
• "now I know that I should really do domain engineering first",
• "now I can see that requirements engineering can be made much simpler",
• "I really ought, or even want, to do it the Triptych way as explained in those lectures",
• "perhaps I can persuade my management to adopt the Triptych approach?",

A longer range objective of the lectures is to help achieve:

• in industry: that domain engineering become an indispensable part of software engineering, and
• in academia & industry: that we embark upon "grand challenges" of developing domain descriptions of

  $\star$

  airports (flow of passengers, material (aircraft, luggage, fuel, catering, etc.), information, control, etc., in an airport),

  $\star$

  air traffic (aircraft, terminal control, ground control, regional control centres, trans-regional control centres, etc.),

  $\star$

  container logistics (container shipping, container terminals, container stowage, etc.),

  $\star$

  the financial service industry (banks, insurance companies, portfolio management, stock brokers, traders and exchanges, the regulatory agencies, etc.),

  $\star$

  health care (patients, private physicians, clinics and hospitals, pharmacies, the regulatory agencies, etc.),

  $\star$

  manufacturing (production planning, production, warehousing, ordering, delivering, etc.),

  $\star$

  the market (consumers, retailers, wholesalers, producers, agents, brokers, the distributing chain, etc.) -- including the electronic market (including also digital rights management etc.),

  $\star$

  transportation (railways [lines and stations, monitoring and control of train traffic, i.e., signalling and switching, timetabling, scheduling and rescheduling of traffic (trains, staff [rostering], supplies), passenger and freight services (reservations, tracing, etc.)], roads nets [``similarly''], etc.),

  $\star$

  $\mathcal{E}$tcetera.

Seminar Style

We will show no formulas in the course! For those of you who know the lecturer, or just has the slightest knowledge of the person as a scientist, that may come as a surprise.

Yes, if the ideas of the Triptych approach and therefore of the principles, techniques and some of the tools of the Triptych domain and of the Triptych requirements engineering are any good, they must also be good without necessarily having to formalise the domain descriptions and the requirements prescriptions.¹

So relax: No immediately inscrutable formulas, no upside down As ($\forall$), no reflected Es ($\exists$).

Enjoy the lectures, go away at the end with a new, fresher view of software engineering.

Seminar Lecture Notes

Background Book

The lecturer has recently published a three-volume book:

Bibliography

1

Dines Bjørner.
Software Engineering, Vol. 1: Abstraction and Modelling.
Texts in Theoretical Computer Science, the EATCS Series. Springer, December 2005.

2

Dines Bjørner.
Software Engineering, Vol. 2: Specification of Systems and Languages.
Texts in Theoretical Computer Science, the EATCS Series. Springer, February 2006.

3

Dines Bjørner.
Software Engineering, Vol. 3: Domains, Requirements and Software Design.
Texts in Theoretical Computer Science, the EATCS Series. Springer, March 2006.

The lectures cover parts of [3]. You may certainly wish to buy Vol. 3, or even the whole set of three!

Handouts

For the JAIST Tokyo Lectures we will prepare a special downloadable handout of some 200 pages + copies of slides.

Lecture Schedule and Contents

Lecture Schedule

     June 2006
Su Mo Tu We Th Fr Sa
             1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17 : Lecture Week
18 19 20 21 22 23 24   ------------
25 26 27 28 29 30

The lectures are:

1. Monday 12 June, 18:30-21:40
2. Tuesday 13 June, 18:30-21:40
3. Wednesday 14 June, 18:30-21:40
4. Thursday 15 June, 18:30-21:40

Lecture Contents

Lecture #1: Overview of Domain Engineering

1. Characterisation of domains and their description.
2. Justification of domain engineering.
3. The contents of a domain description.
4. Domain stakeholders,
5. Domain acquisition and analysis.
6. Domain verification and validation.

Lecture #2: Domain Description Principles

1. Ontological Description Principles:
   1. Domain entities and their description
   2. Domain functions and their description
   3. Domain events and their description
   4. Domain behaviours and their description
2. Michael Jackson's Description Principles:
   1. Designations
   2. Definitions
   3. Refutable assertions

Lecture #3: Domain Facets

1. Intrinsics
2. Support technologies
3. Management & organisation
4. Rules & regulations
5. Scripts
6. Human behaviour

Lecture #4: Domain and Software Requirements

1. The machine
2. Domain requirements:
   1. Projection
   2. Determination
   3. Instantiation
   4. Extension
   5. Fitting
3. Interface requirements
   1. Shared phenomena and concepts
   2. Initialisation and refreshment of shared data
   3. Man-machine dialogue
   4. Physiological implements
   5. Machine-machine dialogue
4. Machine requirements -- 5 minutes!
5. Closing remarks

Registration: By Simple E-mails

• The lectures are offered for free
• But you need to please register
• Please register by sending
  • an e-mail to sate@jaist.ac.jp
  • with CC to both kokichi@jaist.ac.jp and bjorner@jaist.ac.jp

Venue

The lectures will take place at:

• Venue:
  • JAIST Tokyo Yaesu Campus
  • 9th Floor of Tokyo Station DAIMARU Building.

• Times:
  • 18:30-20:00, 20:10-21:40 - June 12th (Monday)
  • 18:30-20:00, 20:10-21:40 - June 13th (Tuesday)
  • 18:30-20:00, 20:10-21:40 June 14th (Wednesday)
  • 18:30-20:00, 20:10-21:40 June 15th (Thursday)

Follow-up Course

These (free) lectures may be followed-up by a more detailed, somewhat in-depth course of somewhat longer duration and sometime in the late fall of this year.

If interest is shown in such a (not-for-free) course then JAIST will try arrange such a course.

Welcome

I look forward to see you at JAIST in Tokyo June 12-15, 2006.

 

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

jaist/tokyo/t1.tex

latex2html -split 0 -toc_depth 6 t1

scp t1/*.* bjorner@www.jaist.ac.jp:/home/bjorner/public_html/tokyo-course-1/.

About this document ...

June 12-15, 2006 JAIST Open Seminar, Tokyo:
Domain Engineering and its Rôle in Software Engineering

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

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 t1

The translation was initiated by Dines Bjorner on 2006-05-15

Footnotes

... prescriptions.¹

We do, ourselves, of course, insist that a professional software engineer, as a matter of professionalism, do indeed produce formalisations of the indispensable informal, yet precise and logical descriptions and prescriptions.