From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!gatech!purdue!rjh From: rjh@cs.purdue.EDU (Bob Hathaway) Newsgroups: comp.lang.ada Subject: Technical Reports Message-ID: <6213@medusa.cs.purdue.edu> Date: 9 Mar 89 02:09:01 GMT Sender: news@cs.purdue.EDU Organization: Department of Computer Science, Purdue University List-Id: I've been asked to post these to comp.lang.ada, they first appeared in comp.doc.techreports (part 2 of 2). Software Engineering Institute Carnegie Mellon University Information Management Pittsburgh, Pennsylvania 15213 1 January 1988 -- 31 December 1988 Annotated list of available documents for public release, 1988. These reports are available from the Defense Technical Information Center (DTIC) and the National Technical Information Service (NTIS). To obtain copies of the reports, please contact DTIC or NTIS directly, providing them with the ADA number for the desired report(s). (For example, _ADA200631_ is the DTIC number for the SEI report _Summary of SEI Technical Operations: 1987_.) Defense Technical Information Center (DTIC) ATTN: FDRA Cameron Station Alexandria VA 22304-6145 National Technical Information Service (NTIS) U.S. Department of Commerce Springfield, VA 22161 ------------------------------------------------------------------------------- 1988 Technical Reports ------------------------------------------------------------------------------- ADA200631 Summary of SEI Technical Operations: 1987 During 1987, the SEI had five programs in place: Ada-Based Software Engineering Program, Education Program, Software Process Program, Pilot Projects Program, and Technology Transition Program. These programs, their 1987 accomplishments, and their planned work are described in this document. In addition, the SEI affiliate functions, computing facilities, building, staff, and service accomplishments are also described. ------------------------------------------------------------------------------- ADA200630 Johnson The Software Engineering Education Directory This directory provides information about software engineering courses and software engineering degree programs that are available in the United States and Canada. ------------------------------------------------------------------------------- ADA201345 Graham, Miller, D. ISTAR Evaluation ISTAR is an integrated project support environment produced by Imperial Software Technology, Ltd. This evaluation of ISTAR is intended for software technologists considering the adoption of an integrated project support environment. Researchers and others interested in environments and evaluation methods will also benefit from this report. ------------------------------------------------------------------------------- ADA197136 Hansen, Over Evaluation and Recommendations for Technology Insertion into Technical Order Maintenance As the need for mission-critical software systems increases, Post Deployment Software Support (PDSS) activities will require increased priority in planning. PDSS is "the sum of all activities required to ensure that, during the production/deployment phase of a mission-critical computer system's life, the implemented and fielded software/system continues to support its original missions, and subsequent mission modifications and product improvements. PDSS, therefore, includes not only software "maintenance" but also the activities required for overall system support. The SEI recognizes the importance of PDSS activities in the life cycle of mission-critical systems. In March 1986, SEI personnel met with representatives of the Air Force Logistics Command (AFLC) at Ogden Air Logistics Center (OO-ALC), Hill Air Force Base, Utah, to determine if there were areas in PDSS that the SEI could address. The AFLC representatives described the activities performed at Air Logistics Centers and problems encountered in those activities. As a result of this meeting, the SEI authorized a feasibility study to determine how it might best interact with the PDSS community. This report, written in August 1987, describes the evaluation process and the ensuing recommendations for technology insertion into technical order maintenance. ------------------------------------------------------------------------------- ADA200085 Bass, Hardy, Hoyt, Little, Seacord Introduction to the Serpent User Interface Management System Serpent is an example of the class of systems known as a User Interface Management System. It uses the X Window System to interact with the end user, and is useful both as a portion of a production system and as a separate prototyping tool. Serpent supports the development and execution of the user interface of a system. It provides an editor with which to specify the user interface and a runtime system that communicates with the application to get the data to display. The system then uses the specification previously output from the editor to decide how to display that data. This report provides a technical overview of Serpent, its components, the module used in specifying the user interface, and the editor used in constructing the user interface. ------------------------------------------------------------------------------- ADA196664 Bass, Hardy, Hoyt, Little, Seacord Serpent Runtime Architecture and Dialogue Model This paper describes the runtime architecture and dialogue model of the Serpent User Interface Management System (UIMS). Serpent uses existing software systems to create a UIMS based on a structured production model to specify the dialogue, and uses a database approach for communication between its internal layers. The model for the dialogue in Serpent supports simultaneity of subdialogues and presents the dialogue specifier with a model that views data as mapping from the application to the presentation. The database approach for communication between the layers provides a model that application programmers understand well and find easy to use. The approach also provides the power necessary to decouple the application structures from the structures implicit in the user interface. ------------------------------------------------------------------------------- ADA197490 Feiler, Smeaton The Project Management Experiment This report covers a project management (PM) experiment, one of six experiments that examine different functional areas of Ada programming environments. The PM experiment was designed as part of the Evaluation of Ada Environments Project. This report describes the environment-independent part of the experiment: the activities covering the functional area, the evaluation criteria, and an experiment scenario to be performed on different environments. The experiment as it stands has been validated through internal and external review and through application to several environments that support project management. ------------------------------------------------------------------------------- ADA197416 Wood, Pethia, Roberts, Firth A Guide to the Assessment of Software Development Methods Over the past decade, the term "software engineering methods has been attached to a variety of procedures and techniques that attempt to provide an orderly, systematic way of developing software. Existing methods approach the task of software engineering in different ways. Deciding which methods to use to reduce development costs and improve the quality of products is a difficult task. This report outlines a five- step process and an organized set of questions that provide method assessors with a systematic way to improve their understanding of and form opinions about the ability of existing methods to meet their organization's needs. ------------------------------------------------------------------------------- ADA197137 Kellner, Hansen Software Process Modeling An SEI objective is to provide leadership in software engineering and in the transition of new software engineering technology into practice. This paper discusses a software process modeling case study conducted at the SEI. ------------------------------------------------------------------------------- ADA197671 Feiler, Smeaton Managing Development of Very Large Systems: Implications for Integrated Environment Architectures Version and configuration control are mechanisms for managing source code and system builds. In the development of very large systems, built by large teams, development management is the dominant factor. In this paper we examine management support for development through integrated environments and investigate the implications for environment architectures. We do so by defining a project scenario that is to be performed with integrated project support environments. The scenario has been carefully designed to not only determine the scope of management functionality provided by a particular environment, but also to probe implications for the architecture of environments. The implications discussed in this paper are: focus on user activities; the integration of project management and development support concepts; the ability to reinforce and avoid conflict with particular organizational models; the ability to support evolution and change of the product, environment, and organization; and the capability for adaptation and insertion into a work environment. The scenario is part of a methodology for evaluation of environments currently used at the Software Engineering Institute. ------------------------------------------------------------------------------- ADA198934 Feiler, Dart, Downey Evaluation of the Rational Environment This report presents an analysis of the Rational R1000 Development System for Ada, also called the Rational Environment. The evaluation combined the use of the Software Engineering Institute (SEI) methodology for evaluation of Ada environments, an analysis of functionality not covered by that methodology, and an assessment of the novel environment architecture of the Rational Environment. In addition to this report, Experiment Transcripts for the Evaluation of the Rational Environment, by Grace Downey, Mitchell Bassman, and Carl Dahlke (CMU/SEI-88-TR-21) contains support material for the experimental results. The support material is the result of performing experiments based on the SEI's environment evaluation methodology. It consists of transcripts of the experiments, the detailed answers to the evaluative questions, and the detailed performance results. ------------------------------------------------------------------------------- ADA198933 Bamberger, Colket, Firth, Klein, D., Van Scoy Kernel Facilities Definition This document defines the conceptual design of the Kernel by specifying 1) the underlying models, assumptions, and 2) restrictions that govern the design and implementation of the Kernel; and the behavioral and performance requirements to which the Kernel is built. This document is the requirements and top level design document for the Kernel. ------------------------------------------------------------------------------- ADA199482 Bamberger, Colket, Firth, Klein, D., Van Scoy Distributed Ada Real-Time Kernel This paper addresses two distinct needs of real-time applications: distribution and hard real-time scheduling mechanisms. Specifically, this paper rejects both the notion of modifying the Ada language to achieve needed real-time solutions and the current fad of extensively modifying the Ada compiler and/or vendor-supplied runtime system. Instead, this paper defines the functionality of a Distributed Ada Real-time kernel (hereafter called the Kernel). The goal of the Kernel is to support effectively the execution of distributed, real-time Ada applications in an embedded computer environment by returning control to the user, where it belongs ------------------------------------------------------------------------------- ADA199480 Barbacci, Doubleday, Weinstock The Durra Runtime Environment Durra is a language designed to support PMS-level programming. PMS stands for Processor-Memory-Switch, the name of the highest level in the hierarchy of digital systems. An application or PMS-level program is written in Durra as a set of task descriptions and type declarations that prescribes a way to manage the resources of a heterogeneous machine network. The application describes the tasks to be instantiated and executed as concurrent processes, the types of data to be exchanged by the processes, and the intermediate queues required to store the data as they move from producer to consumer processes. This report describes the Durra Runtime Environment. The environment consists of three active components: the application tasks, the Durra server, and the Durra scheduler. After compiling the type declarations, the component task descriptions, and the application description, the application can be executed by starting an instance of the server on each processor, starting an instance of the scheduler on one of the processors, and downloading the component task implementations (i.e., the programs) to the processors. The scheduler receives as an argument the name of the file containing the scheduler program generated by the compilation of the application description. This step initiates the execution of the application. ------------------------------------------------------------------------------- ADA199481 Barbacci, Doubleday Generalized Image Library: A Durra Application Example Durra is a language designed to support the construction of distributed applications using concurrent, coarse-grain tasks running on networks of heterogeneous processors. An application written in Durra describes the tasks to be instantiated and executed as concurrent processes, the types of data to be exchanged by the processes, and the intermediate queues required to store the data as they move from producer to consumer processes. This report describes an experiment in writing task descriptions and type declarations for a subset of the Generalized Image Library, a collection of utilities developed at the Department of Computer Science at Carnegie Mellon University. The experiment illustrates the development of a typical Durra application. This is a three step process: first, a collection of tasks (programs) is designed and implemented (these are the GIL programs); second, a collection of task descriptions corresponding to the task implementations is written in Durra, compiled, and stored in a library; and finally, an application description is written in Durra and compiled, resulting in a set of resource allocation and scheduling commands to be interpreted at runtime. A few sample application descriptions were developed as part of the experiment and are also reported in this document. ------------------------------------------------------------------------------- ADA199429 Barbacci MasterTask: The Durra Task Emulator Durra is a language designed to support the construction of distributed applications using concurrent, coarse-grain tasks running on networks of heterogeneous processors. An application written in Durra describes the tasks to be instantiated and executed as concurrent processes, the types of data to be exchanged by the processes, and the intermediate queues required to store the data as they move from producer to consumer processes. The tasks and types available to an application developer are described by a collection of Durra task descriptions and type declarations stored in a library. One of the components of a task description is a specification of the external timing behavior of the task. It describes the sequence of input and output port operations and the amount of processing time spent between port operations. This report describes MasterTask, a program that can emulate any task in an application by interpreting the timing expression describing the behavior of the task, performing the input and output port operations in the proper sequence and at the proper time. MasterTask is useful to both application developers and task developers. Application developers can build early prototypes of an application by using MasterTask as a substitute for task implementations that have yet to be written. Task developers can experiment with and evaluate proposed changes in task behavior or performance by rewriting and reinterpreting the corresponding timing expression. ------------------------------------------------------------------------------- -- Carnegie Mellon University Software Engineering Institute (412) 268-6378