Christian Gram

Design principles for interactive software

Foreward. Preface. The context of interactive systems development. External properties: the users perspective. Internal properties: the software developers perspective. Software architecture models. Tools and materials. Example: interface for air traffic controllers. Conclusions. Glossary. Summary tables. References. Index.

History of the Nordic Computer Industry

In this panel session, people from the four countries — Finland, Sweden, Norway, and Denmark — who participated in the early development of computers and computer industry discuss how the computer industry started and what happened 30 to 40 years ago. We will try to answer questions as follows. How and why did the computer development and industry start in each country? How did it manage the change from research/development into industry? How and why did some of the early companies not succeed? What were main achievements and successes?

Tools and Materials

An interactive system is seen by different people from different points of view. The system user is concerned with external properties, such as those that influence task coverage, flexibility and robustness during system use. The developer is often more concerned with those internal properties which address such things as the costs and reliability of development throughout the entire development life cycle.

Software Architecture Models

This chapter demonstrates how one can use analysis of software architectures to generate software designs that are compatible with a chosen ‘property profile’. Such a profile must be determined during requirements specification. The approach used in this chapter is to take each external and internal property, and describe (in)compatibilities between it and some interactive software architectures. Architectures developed and refined during the system and software design phases can be compatible with this profile in four ways.

External Properties: the User’s Perspective

The usability of an interactive system is linked to the quality of the dialog, and quality shall here be expressed through a number of measurable properties of the dialog. The aim of this chapter is to identify and define a set of user-centered properties of interactive systems which promote high quality from the perspective of the users. The set must be as complete and mutually independent (‘orthogonal’) as possible. At the same time these so-called external properties must be usable in the software development process as yard-sticks or ‘measures’ in the quality plan for the development. For a particular system, some of the properties may be absolute requirements (this interactive system must have such and such property), while others are desired in a quality plan but are given some ‘weight of importance’ (0 ≤ ω < 1). Once we understand these properties and their implications, and also the internal properties presented in the next chapter, we will be able to discuss how to construct interactive systems possessing desired and required properties.

Internal Properties: The Software Developer’s Perspective

Every engineering project is driven by the need to produce an acceptable product which matches the users’ requirements and which will therefore be accepted in accordance with contractual obligations. Where a product is being produced speculatively in the hope of attracting users, there is just as strong a set of requirements (including costing and timing) as when a specific client has ordered something.

University Education on Computers

Following a session on university education, this panel discussed early Nordic visions and experiences on university computing education, contrasting them to today’s needs and the international development at that time. This report gives short papers by the panelists (their opening statements), and a brief summary (the chair’s interpretation) of the views that were raised in the ensuing discussion.

Example: Interface for Air Traffic Controllers

This chapter introduces a single large example of using the properties and architecture which have been discussed in earlier chapters. The example chosen is an Air Traffic Control (ATC) Support System. The concrete meaning of the abstract properties introduced in earlier chapters will be discussed in that context, showing how one property interacts with other properties. The relevance of this to the design is shown by examples, which are followed by a discussion of possible architectures for the ATC Support System.

The Context of Interactive Systems Development

Interactive computer systems are built in order to help people achieve some goals as efficiently as possible. Users at work have tasks to perform, and the systems they use should support these extensively and appropriately. This chapter establishes a context for discussing the quality of interactive systems.

Correctness in the Small

The meaning of a program can be specified by pre- and postconditions, and the semantics of each statement can be defined by its weakest precondition. We present the development including implementation of a simple system to verify small programs. The system contains a weakest precondition calculator and a theorem prover; it is specified using VDM (as described in [1]) and implemented in Prolog. This paper shows how VDM was used as a natural specification tool and contains in appendices some key functions in VDM and their translation into Prolog.