Consistent Interface Research Articles

User interface support for the integration of software tools: an iconic model of interaction

This paper presents a model of interaction based on an iconic representation of objects. An application of the model to an iconic shell for Unix™ is described. Finally a client server architecture for the implementation of the model is introduced. We show that a software development environment can take advantage of such a model and architecture in order to provide a consistent, adaptable and extensible user interface.

The Software Life Cycle Support Environment (SLCSE): a computer based framework for developing software systems

The Software Life Cycle Support Environment (SLCSE) is a VAX/VMS-based software development environment framework which presents a common and consistent user interface accessing a comprehensive set of software development tools supporting the full spectrum of DOD-STD-2 167A software life cycle activities from Requirements Analysis to Maintenance. These tools utilize a Project Database which maintains information relevant not only to the software under development (e.g., requirements allocation, software interfaces, etc.), but also information relating to the project as a whole (e.g., schedules, milestones, Quality Assurance, Configuration Management, etc.). The Project Database supports the DOD-STD-2167A life cycle model and associated Data Item Descriptions (DIDs). SLCSE's framework approach supports the integration of new tools into the environment and permits the SLCSE to evolve over time and adapt to advances in software engineering technology.

The Software Life Cycle Support Environment (SLCSE): a computer based framework for developing software systems

The Software Life Cycle Support Environment (SLCSE) is a VAX/VMS-based software development environment framework which presents a common and consistent user interface accessing a comprehensive set of software development tools supporting the full spectrum of DOD-STD-2 167A software life cycle activities from Requirements Analysis to Maintenance. These tools utilize a Project Database which maintains information relevant not only to the software under development (e.g., requirements allocation, software interfaces, etc.), but also information relating to the project as a whole (e.g., schedules, milestones, Quality Assurance, Configuration Management, etc.). The Project Database supports the DOD-STD-2167A life cycle model and associated Data Item Descriptions (DIDs). SLCSE's framework approach supports the integration of new tools into the environment and permits the SLCSE to evolve over time and adapt to advances in software engineering technology.

User Interface Consistency in the DECwindows Program

A major goal of the DECwindows program is to provide a consistent, state-of-the-art user interface for workstation software.1 This interface extends across operating systems and many different types of application programs. Within the DECwindows program we have addressed both the technical and organizational aspects of developing consistent user interfaces across applications. Traditional methods for developing user interface consistency, such as the use of an interface style guide and toolkit, were supplemented with more innovative techniques. An exhibition and catalog of DECwindows application designs helped to develop a DECwindows school of interface design. Electronic conferencing software played an important role in facilitating communication among DECwindows contributors throughout the company. Preliminary user interviews suggest that the DECwindows interface style gives a consistent, usable feel to Digital's workstation applications.

Dynamic Data Structures and Concurrency in a Real-Time Data Acquisition System

We report on our efforts in developing an innovative real-time data acquisition system that makes extensive use of dynamic data structures, concurrency and state machine features. The Data Acquisition Command Language developed at the Los Alamos Weapons Neutron Research (WNR) Facility is a Pascal-based system that incorporates these features to maximize system performance, reliability and adaptability while supporting a consistent, familiar and comfortable user interface. The details and benefits of the implementation philosophy and underlying structures are discussed.

Viewing a programming environment as a single tool

Programming environments support the creation, modification, execution and debugging of programs. The goal of integrating a programming environment is more than simply building tools that share a common data base and provide a consistent user interface. Ideally, the programming environment appears to the programmer as a single tool; there are no firewalls separating the various functions provided by the environment. This paper describes the techniques used to integrate Magpie, an interactive programming environment for Pascal. Display windows, called browsers, provide a consistent approach for interacting with the Pascal source code or the execution state of the program. Incremental compilation allows the programmer to specify debugging actions in Pascal, eliminating the need for a separate debugging language.

Viewing a programming environment as a single tool

Programming environments support the creation, modification, execution and debugging of programs. The goal of integrating a programming environment is more than simply building tools that share a common data base and provide a consistent user interface. Ideally, the programming environment appears to the programmer as a single tool; there are no firewalls separating the various functions provided by the environment. This paper describes the techniques used to integrate Magpie, an interactive programming environment for Pascal. Display windows, called browsers, provide a consistent approach for interacting with the Pascal source code or the execution state of the program. Incremental compilation allows the programmer to specify debugging actions in Pascal, eliminating the need for a separate debugging language.

JINN, an integrated software package for molecular geneticists

I describe JINN, a microcomputer-based system designed to maintain and search a strain collection, to enter, modify and analyze sequences, and to use the EMBL Sequence Data Base. The major objective during development of this program has been integration of individual program modules to ensure a consistent and helpful user interface. The system is running under the CP/M operating system and requires little in the way of particular hardware configuration.

Integrated environments

The session on debugging in integrated environments started with Fairley's characterization of integrated environments as follows: (1) versatile collection of analysis, design, implementation, testing, and maintenance tools; (2) consistent user interface among the tools; (3) common representation of information (e.g., Stoneman's database model, Unix pipe); (4) history/version control/configuration management capability; and (5) encouragement of good practice. He then asked the audience the following questions: (1) what is your view of environments? (2) what possibilities exist for debugging in integrated environments that do not exist in a mere collection of tools? (3) what is the difference between high--level debugging and low--level debugging with high--level tools?

Integrated environments

The session on debugging in integrated environments started with Fairley's characterization of integrated environments as follows: (1) versatile collection of analysis, design, implementation, testing, and maintenance tools; (2) consistent user interface among the tools; (3) common representation of information (e.g., Stoneman's database model, Unix pipe); (4) history/version control/configuration management capability; and (5) encouragement of good practice. He then asked the audience the following questions: (1) what is your view of environments? (2) what possibilities exist for debugging in integrated environments that do not exist in a mere collection of tools? (3) what is the difference between high--level debugging and low--level debugging with high--level tools?