Publications

 The aim of this mostly analytical paper is to propose a definition of {\sl what an infrastructure is.\/} This definition will be stated in terms of properties of properties of mathematical models of the domain of the `infrastructure', in terms of properties of requirements put to computing \& communications support, and in terms of characteristics of possible architectures for software that support the `infrastructure'. The paper is presently in draft form, but is circulated in order to solicit comments. Eventually a version of the paper will be presented at the Spring Session of the Mathematics and Informatics Section of {\sf Academia Europaea}, 11--12 April 1996 in Amsterdam, The Netherlands.

 This paper is part speculative, part technical, and mostly discursive! The paper is also comprehensive and should be readable by a large fraction of the software community. The conjectures of the paper are based on more than 30 years of extensive experience in computing and software systems development: in the formal, abstract specification of software system architectures, and in their stepwise implementation. The conjecture of the paper is this: For a software house, a producer of products, to be able, in future, to compete effectively it must possess: (i) deep and broad (large scale) problem domain knowledge represented in the form of `mathematical theories of application domains', (ii) ready access to `software devices and mechanisms', and (iii) otherwise pursue development steadily using a large variety of `design calculi'. The paper will define the single-quoted concepts, and will illustrate large-scale applications.

 We study the concept of Problem Frames first suggested by Michael A. Jackson. For each of a number of Problem Frames we suggest an explanation of that Frame in terms of the set of application Domains, the set of Requirements and the set of Designs that seem to best characterise it. For each we give graphic and formal characterisations. Our presentation also focuses on the Syntax, Semantics and Pragmatics of Problem Frames.

 Based on an Air Traffic example we illustrate issues of Domain Analysis (of: air space, time tables, and traffic), and of Requirements Capture (of: scheduling systems, and of air traffic control). We relate also to the issue of Software Architecture% (Keynote address: APSEC'95: Asia Pacific Software Engineering Conference, 6--9 December 1995, Brisbane, Australia).

 This is a compendium of 4 papers:

• [(a)] Dines Bjørner. Trustworthy Computing Systems: The ProCoS Experience, February, 1992. Published in: 14th International Conf. on Software Engineering, Melbourne, Australia, May 11-15, 1992, pp. 15-34.
• [(b)] Dines Bjørner and Jørgen Fischer Nilsson. Algorithmic & Knowledge Based Methods -- Do they "Unify"? Published in: International Conf. on Fifth Generation Computer Systems: FGCS'92, Tokyo, June 1-5, 1992 (separate folder, pp. 191-198).
• [(c)] Dines Bjørner. From Research to Practice: Self-reliance of the Developing World through Software Technology -- Usage, Education & Training. Published in: IFIP Transaction, IFIP World Congress '92, Madrid, September 7-11, 1992, pp. 65-71.
• [(d)] Dines Bjørner. A Rôle for UNU-IIST: Developing Countries' Access to New Information Technologies. Presented at: Access to Science and Technology, The Rôle of Information Technology, Kyoto University and UNU Symp., Kyoto, May 12-14, 1992; Expected publ. by UNU Press.

Distributed only with publishers permission

 Before an architecture for a software system (or package) --- that is: a definition of concepts and facilities of the software system (resp.\ package) to be developed --- can be given, one first establishes proper requirements expected of that software, that is: we base software development on requirements specifications. These requirements are captured from understanding first the domain in which the software is to serve and then from understanding the expectations of the new software as an operational part of the thus extended domain. Thus understanding the domain seems to be a very first order of `business'! In this paper we present an example of the collection of (informal) procedures and (formal) techniques that are being applied in understanding the Railway System domain --- as part of a large scale technology transfer project joint with various software development and computer centers of the Chinese Railways in researching and developing proper software eventually for all aspects of railway operation in China.

 In this paper we review (i) basic functions of gapa with respect to its possible needs for computers and communications (Henceforth we will abbreviate computer and communications by cac.) (notably software); (ii) the basic tasks confronting upper level management of papa institutions when considering cac; (iii) the basic tasks confronting cac facilities management when procuring, monitoring the development of and operating new software technology for gapa; and (iv) the basic tasks confronting {\sf New Development of Software Technology}. In this latter we cover current thoughts on software development process modeling, current methods, principles, techniques, and tools of software development. We need to cover (i--iii) in order to properly understand the setting for and offerings of what is covered in (iv) (Special {\sl Theme\/} paper. {\sf New Software Technology Development} first prepared in September 1995 for an International Symposium: {\sf New IT Applications for Governance and Public Administration}, convened by the UN's Department for Development Support and Management Service: UNDDSMS, Beijing, November 9--14, 1995. This symposium was subsequently moved (tentatively) to June 1996, same venue).

 We describe work done at \unuiist\ involving staff from the Chinese railways. The immediate aim is to develop software that can improve the efficiency of the Chinese railway system, particularly in the scheduling of trains. In the longer term we hope to develop the capacity of the Chinese railways to produce and even market their own software. The part of the project described here includes the development of formal models of some basic components of railways (networks of stations and lines and timetables) and the activities needed to schedule and reschedule trains using a \emph{running map}. This part finished with the delivery of a prototype running map tool, and some conclusions are drawn about the formal development of this tool.

Presents the co-ordinates along, and principles according to which UNU-IIST will select and pursue its Programmatic Activities the next couple of years

 Based on an abstract notion of resources, their macro allocation and macro scheduling, we give models of strategic, tactical and operational planning as well as of the actual overall operations of a typical transportation or manufacturing enterprise. We comment on macro- vs. micro allocation and scheduling. The former binds resources to locations and time intervals, the latter binds tasks to (already location allo- cated and interval scheduled) resources. The abstract and the instantiated models are claimed to represent views of classes of application domains and to constitute essential elements of an analysis of such a domain.

 The programme and project mission of {\sf UNU/IIST}\ is reviewed, as are the policies according to which {\sf UNU/IIST}\ offers fellowships and engages in joint research projects and in advanced development projects with institutions in developing (and other) countries. We then detail all the programmatic activities that took place during 1995 --- with this review forming a major part of this report. A special emphasis is paid to Macau\--oriented actions. The ongoing relations between {\sf UNU/IIST}\ and the {\sf UN}\ System (\&c.) as such are briefly reviewed, as is the status of personnel, finances \& budget. Extensive reference is made both to internal {\sf UNU/IIST}\ documents and to {\sf UNU/IIST}\ reports and research and technical notes. Programmatic activity, staffing, budget and other plans for the 1996\--1997 Biennium are covered throughout

 We outline basic aspects of a method for developing systems. The method concerns a sequentially ordered set of development stages. For each stage we describe principles and techniques. The major stages include: problem delineation, domain theory, requirements capture and software development. Each stage may consist of several partially ordered related steps. Typical software development steps include the (externally observable) software architecture, the (internally structuring) program organisation, zero, one or more software design steps and the [final] code step. Development work within stages and steps are recorded in descriptions. Such documents contain both informal parts: synopsis, narrative and terminology, and formal parts. The latter are expressed in a number of relatable design calculi. \\ An emphasis of the method is its applicability to very large scale infra\-structure systems. An infrastructure system is seen as a base and a set of extensions. Each base + extension defines the terms of a sub-language --- the professional language spoken by employees of an appropriate subpart of the infrastructure. \\ The method is formulated around a concept of Problem Frames introduced by Michael Jackson.

 We define and motivate the need for research into, advanced development and actual deployment, by public and private sector institutions and enterprises, of an advanced class of uses of geographically widely distributed information technology systems of computers and communications in achieving {\sl software support for infrastructure systems} (This paper represents the \unuiist\ position statement for the {\sf Infotech Malaysia '95} National Conference to be held in Kuala Lumpur (and otherwise video broadcast across Malaysia, 1--3 November 1995)).