Applications, Methodology, Technology
Domains, Requirements, Software
Industry, Schools, University
Dines Bjørner
Department of Information Technology
Software Systems Section, Bldg. 344
Technical University of Denmark
DK-2800 Lyngby, Denmark
![[*]](http://www2.it.dtu.dk/latex2html/icons.gif/foot_motif.gif){kind=icon}
We outline a set of carefully co-ordinated
(concordant) research and advanced, exploratory and
experimental (prototype demo) development projects.
Some projects focus on the R&D of specific, informatics
applications -- from the point of view
of significant innovation,
others on the R&D of underlying methods
for the sound and economic, scalable development of
trustworthy and on-time software for such applications, and
yet others on the R&D of software technology for the
support of such developments. The applications all represent
major infrastructure components and include one or more
of
administrative systems,
airport and air
traffic monitoring and control systems,
citizen's & visitors' information and routing,
decision support systems,
electronic trading systems,
enterprise monitoring and control,
financial service: banking, securities, insurance,
clearing, etc.,
fisheries industry infrastructure support,
health care monitoring and support,
metropolitan transport systems,
railway systems and
self-service in the public administration.
The methodology R&D includes techniques for
the development of domain,
requirements and software design descriptions: stake-holder
perspectives, abstraction and concretisation facets, problem
solution facets and software views.
The technology R&D includes tools for the support of
the creation, review & evaluation (including validation
and verification) and ``demo'ing'' of large scale
domain, requirements, software architecture and program
organisation (i.e. structuring) description documents.
In later versions of this document
we give brief overviews of necessary staffing and funding, and
of propagation of specific application demos to the teaching of
informatics in primary and secondary schools, of technology
transfer to industry and of programming methodologies to
university education.
The Triptych cluster of projects is not yet a formal, externally funded project. In external versions of the present document we omit reference to the current informal and future more formalised partners. Most of the ``projects'' already ``take place'': through individual research, student term and in M.Sc. and Ph.D. projects. The present document thus outline the way in which its author currently structures his own research, arranges student, including M.Sc. and Ph.D. thesis projects, and is soliciting external projects.
The document is issued in order to inform colleagues, students, external, currently existing and possible future partners as well as external funding agencies.
The Triptych cluster of projects emphasises the innovation factor present in all its application projects. Each of these attempt to experiment with and explore significant innovations: Novel product ideas. Young people looking for an academic study find well-defined studies in the form of law and medicine: Each lead to certified and regulated professions. The study of the subject of information technology is more opaque. Some prospective students are turned off and away by the oft, by the media, propagated image of nerds. Few are attracted to the study because of ``football-playing'' robots, and other such innovative factors simply because that is not the way in which we, the people responsible for their studies ``sell'' our field. The Triptych cluster of projects, and in particular its applications projects have, as a main objective that of drawing attention to the field, its cross-disciplinarity and its fascinations. Together the three main parts of the overall Triptych project: applications, methodology and technology, shall study their interrelationships.
One aim of pursuing the many applications projects is to bring to Danish industry and institutions the possibilities of radical innovations as well as state-of-the-art methods and technology.
Another aim is to bring to IT/DTU externally visible demonstrations of novel, ``real-life'' applications that might help us attract new and many more students.
Yet another aim is to bring to IT/DTU's methodology research the possibility of validating or invalidating, as the case may be, principles, techniques and tools of software development and product innovation.
We see informatics as the ``sum'' of mathematics, datalogy (computing science), information technology and applications.
This view is reflected in all Triptych sub-projects.
The projects listed in the abstract all represent major infrastructure components.
The term infrastructure is a relatively modern
term.
It is more frequently used in socio-economic
than in scientific, let alone computing science, contexts.
According to the World Bank, `infrastructure' is an umbrella term for many activities referred to as `social overhead capital' by some development economists, and encompasses activities that share technical and economic features (such as economies of scale and spill-overs from users to non-users).
We take a more technical view, and see infrastructures as concerned with supporting other systems or activities.
Software for infrastructures is likely to be distributed and concerned in particular with supporting communication of data, people and/or materials. Hence issues of openness, timeliness, security, lack of corruption and resilience are often important.
Typically IT-support for infrastructure components rely on multi-media and Internet. This is reflected in all Triptych applications projects.
The application project component is necessary for a number of reasons: (1) to interact with methodology R&D for purposes of validating researched and proposed software development techniques, (2) to help create demos that can be used in (i) increasing public institutional and private industry awareness of the greater possibilities of infrastructure software, (ii) primary and secondary school teaching of informatics, and (iii) also university teaching, and (3) to help project partners (public institutions and private enterprises) in their innovation of new technologies and products.
Aabenhed i Dansk Administration (Self-service and openness
in Danish public administration):
Domain model, set of alternative requirements, including that of a demo, and related software architectures and program organisations for a self-service interface between citizens and public office officials, notably case officers.The innovative element is the sum total of considering public administration as a net of documents, actor negotiations and the automation of much of this. The documents span from law texts via state and local government circulars and rules & regulations to office procedures. The negotiations follow certain protocols of interacting agents. And the automation builds on visualising and animating documents and negotiations.
Methodology issues: Modelling rules & regulations in terms of non-deterministic scripts, and modelling user/staff behaviour in terms of agent systems.
We refer to WEB document Aida .
:
Domain model, set of alternative requirements, including that of a demo, and related software architectures and program organisations for ``what is an airport, what is air traffic'', their monitoring and semi-automatic control.The innovative element is that of providing ``near-total'' integration of civil aviation codes: rules & regulations governing todays communication -- between air traffic controllers and pilots -- with the monitoring and control of spatial topologies and aircraft. An element of the `Air traffic Monitoring and Control' part is the possibility of replacing ground control centres and approach towers with pilot to pilot control.
The AMaCS'2000 project of course is not proposed to tackle the full impact of the above, but only to develop demo visualiser and animator technologies.
Methodology issues: Modelling support technology, real-time and safety critical issues in terms of for example Duration Calculi, and air traffic controller vs. pilot interaction in terms of agent systems.
We refer to WEB document Air Traffic .
Citizen's & Visitors' Information and Routing:
Domain model, set of alternative requirements, including that of a demo, and related software architectures and program organisations for information gathering and summarisation, route planning and facilities reservation (travel, hotel, restaurant, etc.) for citizens and visitors (incl. tourists) for well-defined areas such as for example the Øresund Region, Singapore, Hong Kong, or similar!The innovative element can best be characterised by appealing to one of many ways of ``implementing'' CaVIaR -- namely as a hand-held, PC-connectable ``gadget'' with a keyboard and a small (some would say tiny) screen. Using that device citizens and visitors can plan their excursion around their own region and visit to such a region, like Hong Kong, Singapore, the Øresund Region, or other. Can view, via their Internet connected PC, what is on offer and can load into the CaVIaR gadget this information which can then be replayed and edited while actually performing the excursion: using GPS the user can turn the right street corners while walking, or down the right countryside lanes while driving, can enter the right shops waiting for that user to examine specific goods for sale, can find the restaurant where a booked table is waiting, etc.
Methodology issues: Script and agent systems.
Domain model, set of alternative requirements, including that of a demo, and related software architectures and program organisations for decision support systems for sustainable development.The innovative element is that a comprehensive understanding of ``what is sustainable development and to what extent can decision support be offered'' can be achieved and made a crucial element of commercial such systems, for example for environmentally sound land usage and planning. Further the innovative element is reflected in the global, Internet-based integration of geographical information systems (GIS). As it is now each GIS provider seems to bind their clients strongly to own developed data (information). The DSSfSD project aims at opening up the interfaces between existing GIS systems (ESRI, Intergraph, etc.).
Methodology issues: Ontologies for under-specified and non-deterministic systems.
Electronic Trading:
Domain model, set of alternative requirements, including that of a demo, and related software architectures and program organisations for consumers, suppliers, producers and traders in for example manufacturing.The innovative element is in the logic of trading: extensions of current passive, syntactic catalogue systems with agent protocols based on logic constraint, fuzzy logic and other interpretations of what is being offered over the net, what is being requested, of negotiations between suppliers and consumers, etc.
Methodology issues: Agent systems.
[14]
Enterprise Monitoring and Control Systems:
Domain model, set of alternative requirements, including that of a demo, and related software architectures and program organisations for management decision support in connection with strategic, tactical and operational resource management (upgrade/down-size, spatial allocation & scheduling, resp. task allocation & scheduling).The innovative element is in the ``smooth'' integration over the entire spectrum from strategic via tactical to operational resource management of data mining facilities for the first (strategy), decision support systems for the second (tactics) and (albeit known) algorithms for the last (operations).
Methodology issues: Interface between computer science and operations research, and ontologies for insufficient knowledge and approximate reasoning systems.
Banking Computing Systems:
Domain model, set of alternative requirements, including that of a demo, and related software architectures and program organisations for financial service industry in the form of a unified banking, insurance, securities trading, portfolio management and check + credit card slip clearing.The innovative element lies first in as near comprehensive an understanding of each of the above-mentioned elements of the financial service industry, then in an as near comprehensive integration of this understanding, and finally in a novel implementation of the interface between agents of the financial service industry with its clients. This implementation is here seen as a ``smart card'' interface, where the ``smart card'' in many ways replaces many computing, data storage and communication functions hitherto handled by the oftentimes very large scale main-frame-based IT centres of this industry. One may say, in slogan form: From main frames to ``smart cards'' -- away with the old, in with the new!
Methodology issues: Script systems for rules & regulations, modelling of client/staff behaviours.
:
Domain model, set of alternative requirements, including that of a demo, and related software architectures and program organisations for fisheries industry covering harbour management, fishing boat management, auction management, fish and seafood processing plant, fish transportation, fisheries inspection, food quality tracing, etc.The innovative element is in demonstrating the possibilities of an information relay (as in Danish: stafet) system whose scope is an entire fisheries industry (i.e. the Danish) and whose span is that of the recording, analysis, filtering, forwarding and use of meteorological, fisheries inspection (incl. quota), food quality standards, catch (i.e. product), supply, auction, wholesale price, transport, retail price and demand information. The project will investigate practical (Internet, Windows NT, XML, Java and other software and hardware) technologies for implementing on-board systems.
Methodology issues: Modelling of flow systems: resource/material flow, [partial] product flow, information flow, control flow.
Health Care Monitoring and Support:
Domain model, set of alternative requirements, including that of a demo, and related software architectures and program organisations for health care system spanning the full spectrum from rural clinics, private physicians, home nurses, city (poly)clinics, hospitals, insurance companies, pharmacies, etc.The innovative element lies in the total integration of the fully electronic Patient Medical Record (PMR) with all aspects of the health care system.
Methodology issues: Modelling of flow systems: resource flow, patient and staff flow, information [patient medical record (PMR)] flow, control flow.
Metropolitan Transport Systems:
Domain model, set of alternative requirements, including that of a demo, and related software architectures and program organisations for comprehensive and integrated transport system comprising railways, air traffic, river, sea and canal traffic, busses and taxis.The innovative element can for example be exemplified by mentioning such IT-based offerings as: total monitoring and greatly assisted control of public transport (perhaps away from absolute time-table based schedules to guaranteed, but variable maximum distance between transport stop times), automatic, yet on-demand forwarding of taxis to end-of-bus-route stops, electronic means of information about the current state of a metropolitan transport system (delays, offerings, etc.), etc.
Methodology issues: Transport systems, operations research.
Railway Computing Systems:
Domain model, set of alternative requirements, including that of a demo, and related software architectures and program organisations for comprehensive and integrated railway system comprising the rail (incl. signalling) authorities, rail passenger and freight operators -- and spanning from rail line & services development (design, planning, construction, maintenance), time-tabling, traffic scheduling & rescheduling, passenger ticketing, freight handling, train dispatch, monitoring & control, marshaling and shunting, rolling stock control, etc.The innovative element lies in the near total, user-oriented transparent and smooth integration of strategic, tactical and operational management as well as greatly improved IT-support of operations.
Methodology issues: Transport systems, operations research, real-time, safety critical issues.
We refer to WEB document Railway Systems and .../racosy/scheduling.psTrain Scheduling.
The above list may, to the casual, uninformed reader seem rather ambitious -- as may indeed the scope and span across -- as well as the depth to -- which several of the individual projects appear to go.
But we have had some experience in doing this in the past [24]. And: the projects rely on abstraction and modelling, stepwise development and other development principles to help conquer complexity. So: with the right, open mind, it can be done -- as we have amply shown in the past.
The methodology R&D includes techniques for the development of domain, requirements and software design descriptions: stake-holder perspectives, abstraction and concretisation facets, problem solution facets and software views.
The Triptych methodology is based on a judicious blending of informal, pragmatic, ``best practices'' software engineering techniques with those of formal, semantic ``front-of-the-wave'' computing science techniques.
It is the latter, based on more than 25 years of research, but significantly featuring rather fundamentally new contributions -- which are in need of much further research -- that offers ``dramatic'' new ways of looking at software and of making software development increasingly enjoyable, trustworthy and economic.
We refer to a number of published papers, reports and lecture notes listed in the Bibliography section. They introduce, discuss and explore the concepts outlined below.
We refer to WEB documents:
We need clarify principles of analysis and construction techniques for describing -- without any reference to computing -- the phenomena (individuals, etc.) of the application domain: terms used by professionals of the domain and terms characterising abstract concepts of that domain.Todays software development is characterised by no domain engineering!
Usually only a few stake-holder perspectives are embodied in requirements -- and none in the not existing domain descriptions. We intend to explore and experiment with domain as well as requirements stake-holder perspectives covering, individually, a broadest spectrum from application domain owners, managers, workers, clients (customers), ``the public at large'' (incl. politicians, environmentalists, etc.), IT providers, etc.
For each stake-holder perspective there can be a hierarchy of facets -- including various compositions of the intrinsics of the sub-domain, its supporting technologies, its users' rules & regulations, human user behaviours, etc.
Requirements ``reside in the domain'' it is being said by some, but some requirements do not: They are molded across a template common to most domains -- these we call the non-functional requirements.
Functional requirements are such which are formulated without any reference to computing, solely with reference to the domain.
Functional requirements usually address only a part, i.e. a projection, of the domain.
And functional requirements usually address specificities: concrete instantiations.
Finally functional requirements usually augment the domain with functionalities (concepts and facilities) that were infeasible in the domain without computing.
Relationships between formal techniques and the disposal of non-functional requirements is an area sadly neglected.Among non-functional requirements issues to be so studied are:
- Dependability -- defined as some ``sum'' of:
- Availability: Available to all authorised users on a fair basis.
- Accessibility: Accessible to all authorised users on speedy, non-exclusive, not strictly serialised basis.
- Security: Available only to authorised users.
- Safety: Fault-tolerant and defensive.
- Performance
- Maintainable:
- Perfective: Can be tuned for optimal performance
- Adaptive: Can be adapted to changing environment
- Corrective: Can be readily ``debugged''
- User Friendliness: CHI -- System reflects, in some ``isomorphic'' manner, the concepts, and only the concepts of the domain.
Co-design, the decomposition of requirements into hardware and software, and even into changes in the environment in which the computing system is placed, is at issue here.
By architecture we understand the structure of external interfaces and what can be thus observed -- that is: the architecture basically implemenents functional requirements such as the end-users see them, those people for which the system was intended in the first place!
By program Organisation we understand the internal interfaces and what can be observed over these: processes, data structures, distribution, concurrency, etc. The program Organisation basically implemenents non-functional requirements such as seen by the facilities management people charged with the daily, optimal etc. operation of the computing system.
The relationship between formal techniques and the use of effective platforms such as those definable by OMG (CORBA), in Java, etc. is a sadly neglected one. The Triptych cluster of projects sees this as an important issue to be addressed.
For each of the above items as well as for many more not explicitly listed here we need thoroughly study many method issues (development principles, analysis and construction techniques, development support tools) as well as many methodology issues (cutting across methods) -- the latter notably focused around Michael Jackson's Problem Frame concept.
An aim -- additional to those mentioned earlier -- of the Triptych applications projects is here considered a possible, beneficial side-effect: In formalising the domains of several applications we are, for each of these, formalising crucial terms of their professional sub-languages. In pursuing a larger number of projects of this kind we are now in a position to discover and study -- across many distinct such domains and languages -- commonalities: i.e. whether a theory can be established and further studied, a theory of linguistic terms of infrastructures: their logic and denotations. We consider this study a research project not to be further defined. It will be pursued as and when relevant insight is obtained.
The technology R&D includes tools for the support of the creation, review & evaluation (including validation and verification) and ``demo'ing'' of large scale domain, requirements, software architecture and program organisation (i.e. structuring) description documents.
On one hand we see software development, from domains via requirements to software designs, as the creation -- i.e. writing -- (including manipulation and disposition) of indeed very large scale documents. Included is the strong provision for both informal documents such as synopses, terminologies and narratives, and for formal documents. On the other hand there is the ``reading'' of such documents.
The first set of functionalities we relegate to document handling, the second to document visualisation & animation.
Many formal techniques are already supported by appropriate tools. More will soon follow. What is lacking are more pragmatic tools that integrate informal with formal techniques, that support the informalisable development principles, validation and management's quality control procedures.
Formal models significantly help us achieve todays highest possible trust in our developments. Clients do, and need not read formal documents. Their ``advocates'' -- as do all software engineers -- do however need cross-reference informal and formal documents. Most formal technique tools lack means for informal text processing.
A major part of the software engineers' own contribution to development is that of constructing large descriptions. These span a development spectrum from domains via requirements to software designs. Within each of these there may be steps of development and there are many kinds of documents: synopses, terminologies, narrative, formalisation with annotations, etc. A document handling system includes facilities for the automated creation, use and maintenance of directories of such documents.
Synopses are informal documents describing ``what it is all about'' -- with it being either the domain, the requirements, the architecture, etc. Synopses define the scope and span of the stage and step problem being tackled. Synopses need be carefully correlated with all other documents. Special tools are needed for this.
A terminology defines all the professional terms of the stage or step to which they belong: the application domain, the requirements, the architecture, etc. Special stake-holder perspective terms need be compartmentalised. Diverse tools are needed for this.
A narrative ``tells the story'' of the stage or step to which they belong: the application phenomena, the functional or non-functional requirements, etc. Narratives are expansions of synopses and narratives uses the terms defined in the terminology. Finally narratives form the basis for the formal models. Special tools are needed for this.
Cross-referencing between texts, whether intra or inter informal or formal texts, is a sadly neglected area. For formal techniques to scale up and become accepted in industry viable tool interfaces must established between ordinary text document handling (as implied above) and formal specification handling.
Validation: securing that one get the right product -- by continuously involving all appropriate stake-holders in regular reviews -- verification: ensuring that one gets the product right -- by sketching or completing proofs of properties, including stage and stepwise correctness are crucial development issues. In either case extensive documents are built up and must be maintained.
Version control & configuration tools usually apply only to lowest level program code texts. For formal techniques to scale up and become accepted we need develop ``similar'' version control & configuration tool support for abstract, formal and informal text levels: from domains via requirements to all steps of software designs.
Quality assurance and the full pursuit of Capability Maturity Model management requires simple and elegant means of correlating concordant documents.
Across the whole spectrum of descriptions -- from domains via requirements to all software design steps, and within each of these across synopses, terminologies, narratives, formal specifications, annotations, as well as verification and validation documents -- one needs annotations, explications and explanations.
By a demo we understand a tool that enables online correlation between all levels of development documents -- from domain via requirements to all steps of software design descriptions -- and their visualisation and animation.
By visualisation we understand the designation of phenomena mentioned in document texts: pictures, diagrams, photos, drawings, etc. The visualiser shall provide forward and backward links between informal and formal text parts and their visualisations.
By animation we mean temporal visualisations: where-ever a description document mentions time there will be a need for animations: functions from time to visualisations.
A main purpose of visualisation and animation is to help in the development process: identifying and validating the proper application domain (terms: nouns, verbs, etc.), proper functional and non-functional (for the latter especially CHI) requirements, software architectures, etc.
The above technologies are to be implemented with clear and effective interface to many other, especially formal techniques technologies Atelier B, IFAD VDM-SL ToolBox, RAISE Toolset, PVS, HOL/Isabelle, etc.
It is expected that there will eventually be the following full-time externally funded staff and students over-and-above current Software Systems section staff:
per project 3-12All of this staff works together in all three areas: Applications, Methodology and Technology.
SS/IT/DTU staff includes:
In addition many students, including M.Sc. and Ph.D. students of the software systems section of IT/DTU participate in one form or another of the Triptych cluster of projects.
As individual applications projects become more formalised we expect to see the secondment of partner staff to the relevant project -- typically in the form of paretially funded enterprise Ph.D. students.
We intend to seek external funding for research assistants to cover all three areas of R&D: applications, methodology and technology. We will formulate applications for such funding as more and more of the applications projects become formalised.
Not printed in this version of the current document.
Not printed in this version of the current document.
Not printed in this version of the current document.
The demos to be developed shall be so developed as to offer up to three interfaces.
Another mode of demo operation is aimed at potential infrastructure component stake-holders: to familiarise them with informatics possibilities and consequences, including for IT providers to prepare for new main and niche products.
One mode of demo operation shall illustrate -- for primary and secondary school children -- the structures of data (types), the operations, and the behavioural flow of resources, control and information of the man-made infrastructure components supportable by informatics.The aims and objectives of offering and using this mode are: the study of sociological systems of stake-holders -- in particular the study of transports, health care, economics, etc., and the study of their mathematical explication -- thus leading to an increased appreciation of mathematics as well as informatics.
And a third mode of demo operation is aimed at students of informatics, in particular software engineering students: to help teach them the domain engineering methods, the requirements engineering methods and the software design methods.
We have sketched a cluster of sub-projects. The Triptych project -- as the place-holder for all these sub-projects -- is intended as a focal point, as a unifier and an amplifier. The individual projects, whether within Applications, Methodology or Technology, generate beneficial side-effects (``infrastructure spill-overs'') from one of the three main clusters to the others.
The Applications sub-projects are all characterised by a very high degree of innovation: new products. The Methodology and Technology sub-projects likewise. The former for the benefit of Danish industry, the latter for the benefit of Danish research, science, education and training.
We refer to the many Web page references given pages ![[*]](http://www2.it.dtu.dk/latex2html/icons.gif/cross_ref_motif.gif){kind=icon}
to .
This document was generated using the LaTeX2HTML translator Version 97.1 (release) (July 13th, 1997)
Copyright © 1993, 1994, 1995, 1996, 1997, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -link 0 -split 0 trip.
The translation was initiated by Dines Bjorner on 9/29/1998
.