Domain Science & Engineering Seminar Offers

I list 9 possible seminars - of which one (#3) is a small, five short lectures, mini-course.
At any one time I may decline some of these seminars: currently I decline seminars 7., 8., and 9.
(They will take a week's preparation altogether, for first presentation.)
Topics 10.-15. each requires a week's preparation for first presentation.

Methodology

1. Domain Science & Engineering: A New Facet of Informatics

This talk is a "subset" of seminar #2. First parts are similar. Seminar #2 cover Requirements Engineering in some detail, seminar #1 does not. Seminar #1 discusses rôle of Domain Science and Engineering in broad terms, seminar #2 does not. This seminar will "flash" narratives and formulas whereas seminar #2 will cover them in some detail.

Abstract: 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, manage- ment & organisation, ... are tackled, A domain description may thus be studied (and improved upon), theorems derived etc., as ar 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.

2. 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 (D).

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 engin- eering branches rely on and use mathematics.

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.

3. A Mini Course in Domain Science & Engineering

Abstract We seek foundations for a possible theory of domain descriptions. Full text, All slides

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.

Theory

4. A Role for Mereology in Computing Science

To every mereology there corresponds a $\bgroup\color{red}$\lambda$\egroup$ -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.

Domain Examples

5. The Tokyo Stock Exchange

Abstract We present a domain description of the Tokyo Stock Exchange trading rules. The background for the talk was a description of these rules by Prof. Tetsuo Tamai, Tokyo University. Prof. Tamai published this description in "Social Impact of Information System Failures." Computer, IEEE Computer Society Journal, 42(6):58-65, June 2009.

6. Pipelines

Abstract Oil and gas pipe lines are being increasingly monitored and controlled by computerised systems involving sensors and actuators attached to the pipe line units: wells, pumps, pipes, valves. forks, joins and sinks of the pipe lines, with these units possibly being powered by solar systems and able to communicate data to and from satellites and with these communicating with computers. In this paper we shall try to bring a new area of computer science and software engineering in closer contact with researchers of fluid mechanics and engineers designing pipe lines, including their IT systems. The paper is evolving. Today we just present one of three models of pipe lines. In Sect. 1 we formulate the problem of describing a domain of pipe systems for liquid and gaseous systems. In Sect. 2 we describe the non-temporal aspects of pipe lines. The description is both informal and formal. In this paper we use the RAISE specifcation language RSL. Sect. 3 is presently absent. It shall show how we extend the description of Sect. 2 with temporal properties. For that we use the Duration Calculus. It then behooves us to show that the temporal model integrates with the model of Sect. 2. Sect. 4 is presently missing. It shall show how we extend the description of Sects. 2 and 3 with fuid dynamics properties. The formal description is a simplification in terms of a set of Bernoulli (etc.) differential equations. It now behooves us to show that the fluid dynamics model integrates with the models of Sects. 2 and 3. In Sect. 5 (Conclusion) we sketch a programme of research aimed at bridging the integration gaps between the temporal model of Sect.3 and the standard model of Sect.2, and the fluid dynamics models of Sect.4. and the models of Sects. 2 and 3.

7. License Languages

Abstract Classical digital rights license languages were (and are) applied to the electronic "downloading", payment and rendering (playing) of artistic works (for example music, literature readings and movies). In this talk we generalise such applications languages and we extend the concept of licensing to also cover work authorisation (work commitment and promises) in health care and in public government. The digital works for these two new application domains are patient medical records and public government documents. Digital rights licensing for artistic works seeks to safeguard against piracy and to ensure proper payments for the rights to render these works. Health care and public government license languages seek to ensure transparent and professional (accurate and timely) health care, respectively "good governance". Proper mathematical definition of licensing languages seeks to ensure smooth and correct computerised management of licenses. We shall motivate and exemplify three license languages, their pragmatics, syntax and informal as well as formal semantics.

8. The Market: The Supply Chain

By an $\bgroup\color{red}$\mathcal{E}$\egroup$ -Transaction System we shall understand a computer & communications-based system which support, and, in parts automates exchanges of contractual, action-invoking local state-changing messages (ie., transactions) between a wide variety of actors (traders). By "The Market" we shall first understand a structure of consumers, retailers, wholesalers and producers -- ie., the traders. Later we shall extend our notion of "The Market".

We present informal English language descriptions (narratives) and formal models of a "Market" concept. What generally characterise traders are the kind of interactions they engage in: Issuing inquiries and offering quotations, placing and accepting orders, effecting and accepting deliveries, posting and paying invoices, etc. Traders dynamically form "supply chains". Any trader may, potentially, over different interactions, act any one of the trader rôles listed earlier. We then "lift" the market to include agents (acting on behalf of any one of the traders listed earlier), and brokers (acting on behalf of `sequences' of two or more ``adjacent'' traders while basically engaging in the kind of transactions enumerated above). (We stress that the notion of `agents' used here is not the same notion as it is currently en vogue in the AI community. But, as we point out in a concluding section the two relates.) We finish by first making some remarks on the use of the model presented as a basis for requirements development. Then we "lift" the notion of traders to not just representing pairs of buyers and sellers in a conventional supply chain of merchandise, but any pairs of (institutional) $\bgroup\color{red}$\mathcal{G}$\egroup$ overnment to $\bgroup\color{red}$\mathcal{G}$\egroup$ ( $\bgroup\color{red}$\mathcal{G}2\mathcal{G}$\egroup$ ), $\bgroup\color{red}$\mathcal{G}$\egroup$ to
$\bgroup\color{red}$\mathcal{B}$\egroup$ usiness, $\bgroup\color{red}$\mathcal{G}$\egroup$ to $\bgroup\color{red}$\mathcal{C}$\egroup$ itizen, $\bgroup\color{red}$\mathcal{B}2\mathcal{G}$\egroup$ , $\bgroup\color{red}$\mathcal{B}2\mathcal{B}$\egroup$ , $\bgroup\color{red}$\mathcal{B}2\mathcal{C}$\egroup$ , $\bgroup\color{red}$\mathcal{C}2\mathcal{G}$\egroup$ , $\bgroup\color{red}$\mathcal{C}2\mathcal{B}$\egroup$ , and $\bgroup\color{red}$\mathcal{C}2\mathcal{C}$\egroup$ transaction possibilities.

9. Web Systems, Cloud-databases and Transaction Protocols

Abstract This divertimento sketches some observations on relationships between "window-" and "Web-based graphic user interfaces (GUI)" and underlying Internet-based Linda and JavaSpaces-like "data spaces", that is, shared network-accessible repositories for arbitrary data structures accessible through a variant of "SQL". All "double-quoted terms" are give precise descriptions.

More Domain Examples

10. Container Line Industries

11. Logistics

12. Railways

13. Domains: Their Simulation, Monitoring and Control

14. Believable Software Management

15. Transportation Systems

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

About this document ...

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

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