🚀 go-pugleaf

Software Engineering Institute
Information Management
Software Engineering Institute Documents





HOW TO ACCESS SEI REPORTS ELECTRONICALLY

The Software Engineering Institute (SEI) has begun electronic
distribution of some-not all-of its publications. The
procedure by which you can obtain electronic copies of SEI
reports is described on pages 1 and 2 of this document. Since
many SEI reports are yet unavailable in electronic form,
instructions for obtaining hardcopies of such reports appear
on page 5 of this document.

FTP File transfer protocol (FTP) is a facility that allows
files to be transferred to and from remote network sites.
Brief instructions for using FTP are provided below; if you
require additional information about FTP, contact your system
administrator.

SEI DIRECTORY NAME
The directories listed in /pub/documents contain files that
are accessible via anonymous FTP.


SEI MACHINE ADDRESS
The SEI machine address is:

		ftp.sei.cmu.edu
                      or 
		128.237.2.179


INSTRUCTIONS
If you are working at a UNIX machine connected to the Internet, use the 
following procedure to access SEI files.


TO CONNECT TO THE SEI FTP MACHINE
1	At your Unix prompt, type:

ftp ftp.sei.cmu.edu

2	At the login prompt, type:

anonymous

3	At the password prompt, 
type:

your electronic mail address 
(e.g., jones@cs.xsu.edu)

4	Change to the documents 
directory by typing:

cd /pub/documents

5	Get the READ.ME file by 
typing:

get READ.ME

You should now have a copy of the READ.ME file on your home 
machine.

Repeat Steps 1- 5 from the above procedure to obtain the
documents you want. Step 5 may be repeated as many times as
needed to obtain the desired documents; otherwise, terminate
the process, as is indicated below:

6	Terminate the FTP process 
by typing:

quit


COPYRIGHT NOTE
Some of the files may be temporarily read-protected pending the 
resolution of some copyright issues.
File format

The documents in /pub/documents are formatted as PostScript
files, and thus may be printed on a PostScript printer at
your site. All PostScript files have a .ps suffix.


FIGURES
Some of the files contain figures that have not yet been made
available electronically. Until this is resolved, such files
(ones containing figures markers) will print without figures.
Until the figures are made available electronically, feel
free to contact one of the distribution centers (listed
below) to obtain hardcopies of the documents.


PRINTER
Most of the documents use several of the following PostScript
fonts: Helvetica, Times, New Century Schoolbook, Courier, and
Symbol. Be certain to use a printer that can support these
fonts.  All files MUST be printed with the pages in the order
that they appear in the file. Some print spoolers attempt to
reverse the pages before printing so that the output page
stack will be in the proper order. This may cause the files
to fail to be printed. A common symptom of such a page order
error is having the file printed almost entirely in Courier
font.  Test print

You may want to test these procedures before downloading
large documents. For that purpose, a short test document
appears in the /pub/documents directory in file testTR.ps.
It is a three page excerpt from a technical report; the
second page should be blank.  Photocopying

Documents in PostScript form are intended to be reproduced as
two- sided documents. The left and right margins will be
different widths on odd- and even-numbered pages. If you
choose to make a two-sided document from the printed
original, you may wish to check the first few pages and
insert a blank page wherever needed (such as after the title
page on some documents) to ensure that the pagination is
correct.

THE ANNOTATED LISTING
Documents appearing in the annotated listing that are denoted
with the following icon are available via anonymous FTP:


QUESTIONS
If you cannot print a file, first verify that the print
failure is not due to a problem at your site. Next, reread
and retry the above instructions.  Lastly, if the problem
remains, send electronic mail to bjz@sei.cmu.edu describing
the hardware/operating system being used, the type of printer
on which you're attempting to print the document, and a
description of the problem.



HOW TO ORDER BOUND COPIES OF SEI REPORTS
Software Engineering Institute (SEI) technical reports are
available from Research Access, Inc. (RAI), National
Technical Information Service (NTIS), or the Defense
Technical Information Center (DTIC).  (Note: To order
documents from DTIC, you must provide the DTIC accession
number for the desired report. As an example, "ADA235641" is
the DTIC number for the SEI report Rate Monotonic Analysis
for Real-Time Systems.)

DISTRIBUTING CENTERS
If you wish to request a bound copy of an SEI report, please
contact RAI, NTIS, or DTIC directly. The addresses are
provided below. Several SEI reports have not yet been filed
with DTIC; therefore, they do not have DTIC accession
numbers.

RAI
Research Access Inc.
3400 Forbes Avenue
Suite 302
Pittsburgh, PA 15213
Telephone: 1800 685-6510
FAX: (412) 682-6530


DTIC
Defense Technical Information Center
ATTN: FDRA Cameron Station
Alexandria, VA 22304-6145
Telephone: (703) 274-7633

(Note that DTIC limits distribution to government contractors
who have established a DTIC account.).


NTIS
National Technical Information Service
U.S. Department of Commerce
Springfield, VA 22161-2103
Telephone: (703) 487-4600


		-----begin Part 3 (of 5) -----


Performance and Reliability Enhancement of the Durra Runtime Environment
CMU/SEI-89-TR-8, ADA207415
Weinstock, C. 

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.

A runtime environment for Durra has been operational for some
time. There are two major problems with this initial
implementation: it makes no significant attempt to tune the
performance of the system, and reliability has not been
designed into the system. This report describes a new design
for the Durra runtime environment that addresses these two
issues. The new runtime environment consists of two major
components: a local executive which runs on every processor
and is responsible for process and queue management, and a
global executive which runs replicated on several processors
and is responsible for configuration management and
reliability services.


Conducting SEI-Assisted Software Process Assessments
CMU/SEI-89-TR-7, ADA219065
Olson, T., Humphrey, W., Kitson, D.

This report describes software process assessment as it is
performed in organizations with the assistance of the
Software Engineering Institute. A software process assessment
is an appraisal or review of an organization's software
process (e.g., software development process). The main
objectives of such an assessment are to understand the state
of practice in an organization, to identify key areas for
improvement, and to initiate the actions that facilitate
those improvements. This report is specifically addressed to
the organizations and assessment team members that may be
involved in an SEI-assisted software process assessment.


Proceedings of the Workshop on Executive Software Issues August 2-3 and November 18, 1988
CMU/SEI-89-TR-6, ADA206779
Editors: Martin, D., Carey, S., Coticchia, M., Fowler, P., Maher, J.

These proceedings document the results of two sessions of the
Workshop on Executive Software Issues held at the Software
Engineering Institute on August 2-3 and November 18, 1988.
The purpose of the workshop was to define the issues that
should be brought to the attention of executives in the
defense industry, government, and academia and to propose
resolutions to those issues. The issues discussed were
divided into three broad categories: national strategy,
acquisition, and building large complex systems. Described in
the proceedings are the major issues and recommended actions.


Object-Oriented Solution Example: A Flight Simulator Electrical System, An
CMU/SEI-89-TR-5, ADA219190
Lee, K., Rissman, M.

This report describes an implementation of a subset of an
aircraft flight simulator electrical system. It is a result
of work on the Ada Simulator Validation Program (ASVP)
carried out by members of the technical staff (MTS) at the
SEI. The MTS developed a paradigm for describing and
implementing flight simulator systems in general. The
paradigm is a model for implementing systems of objects. The
objects are described in a form of design specification
called an object diagram. This report has been prepared to
demonstrate a full implementation of a system: package
specifications and bodies. The intent is to provide an
example; the code is functional, but there is no assurance of
robustness.


Human-Machine Interaction Considerations for Interactive Software
CMU/SEI-89-TR-4, ADA206574
Bass, L., Coutaz, J. 

This document introduces current concepts and techniques
relevant to the design and implementation of user interfaces.
A user interface refers to those aspects of a system that the
user refers to, perceives, knows, and understands. A user
interface is implemented by code that mediates between a user
and a system. This document covers both aspects.


Role of Assessment in Software Process Improvement, The
CMU/SEI-89-TR-3, ADA227426
Kitson, D., Humphrey, W. 

This report discusses the role of assessment in improving an
organization's software capabilities; specifically, the
ability of the organization's projects to consistently meet
cost, schedule, and quality objectives. Software process
assessments are described from both a conceptual and
pragmatic point of view. Underlying concepts of software
process, software process management, and software process
maturity are discussed. Collectively, these constitute a
framework for software process assessment and improvement.


Software Process Modeling:   Principles of Entity Process Models
CMU/SEI-89-TR-2, ADA211636
Humphrey, W., Kellner, M. 

A defined software process is needed to provide organizations
with a consistent framework for performing their work and
improving the way they do it. An overall framework for
modeling simplifies the task of producing process models,
permits them to be tailored to individual needs, and
facilitates process evolution. This paper outlines the
principles of entity process models and suggests ways in
which they can help to address some of the problems with more
conventional approaches to modeling software processes.


State of Software Engineering Practice: A Preliminary Report, The
CMU/SEI-89-TR-1, ADA206573
Humphrey, W., Kitson, D., Kasse, T.

This is the first in a series of SEI reports to provide
periodic updates on the state of software engineering
practice in the DoD software community. The SEI has
developed, and is refining, a process framework and
assessment methodology for characterizing the processes used
by software organizations to develop and evolve software
products. This report provides a brief overview of the
process framework and assessment approach, describes
assessment results obtained to date, and discusses
implications of the current state of the practice for both
customers and suppliers of DoD software.


Mode Change Protocols for Priority-Driven Preemptive Scheduling
CMU/SEI-88-TR-34, ADA207544
Sha, L., Goodenough, J.

In many real-time applications, the set of tasks in the
system as well as the characteristics of the tasks change
during system execution. Specifically, the system moves from
one mode of execution to another as its mission progresses. A
mode change is characterized by the deletion of some tasks,
addition of new tasks, or changes in the parameters of
certain tasks, e.g., increasing the sampling rate to obtain a
more accurate result. This paper discusses a protocol for
systematically accomplishing mode change in the context of a
priority-driven preemptive scheduling environment.


Real-Time Scheduling Theory and Ada
CMU/SEI-88-TR-33, ADA205048
Sha, L., Goodenough, J. 

The Ada tasking model was intended to facilitate the
management of concurrency in a priority-driven scheduling
environment. In this paper, we will review some important
results of a priority-based scheduling theory, illustrate its
applications with examples, discuss its implications for the
Ada tasking model, and suggest workarounds that permit us to
implement analytical scheduling algorithms within the
existing framework of Ada.


OOD Paradigm for Flight Simulators, 2nd Edition, An
CMU/SEI-88-TR-30, ADA204849
Lee, K., Rissman, M., D'Ippolito, R., Plinta, C., Van Scoy, R.

This report presents a paradigm for object-oriented
implementation of flight simulators. It is a result of work
on the Ada Simulator Validation Program (ASV) carried out by
members of the technical staff at the SEI.


Using the Vienna Development Method (VDM) to Formalize a Communication Protocol
CMU/SEI-88-TR-26, ADA204757
Pedersen, J., Klein, M. 

The Vienna Development Method (VDM is based upon iterative
refinement of formal specifications written in the
model-oriented specification language, Meta-IV. VDM is also
an informal collection of experiences in formal specification
within several application domains. This paper provides an
example of how VDM might be used in the area of
communications, a new domain for VDM.


Functional Performance Specification for an External Computer System Simulator
CMU/SEI-88-TR-25, ADA200611
Meyers, C., Mumm, H. 

This document defines the functional and performance
requirements for the external computer system (ECS) simulator
that interfaces with the inertial navigation system
simulator. Both the ECS simulator and the INS simulator are
being developed in Ada by the Real-Time Embedded Systems
Testbed Project at the Software Engineering Institute.  The
ECS simulator is similar to a real-world ECS, but has reduced
functionality. This document provides specifications for the
major functions of the ECS simulator.


System Specification Document: Shipboard Inertial Navigation System Simulator and External 
Computer
CMU/SEI-88-TR-24, ADA223958
Meyers, C., Weiderman, N. 

This document specifies high-level requirements for a
shipboard inertial navigation system (INS) simulator and an
external computer system that will interface with the
inertial navigation system.


Functional Performance Specification for an Inertial Navigation System
CMU/SEI-88-TR-23, ADA204850
Meyers, C., Weiderman, N. 

This document defines the functional and performance
requirements for the inertial navigation system simulator
that interfaces with the external computer system (ECS)
simulator. Both the INS simulator and the ECS simulator are
being developed in Ada by the Real-Time Embedded Systems
Testbed Project at the Software Engineering Institute.  The
INS simulator is similar to a real-world INS, but has reduced
functionality. This document provides specifications for the
major functions of the INS simulator.


Perspective on Software Reuse
CMU/SEI-88-TR-22, ADA204399
Perry, J. 

This report presents a perspective on software reuse in the
context of "ideal" software development capabilities.
Software reuse is viewed as a means of achieving-or at least
approximating--the idea capabilities. A generic application
and development model is proposed for unifying various types
of software reuse. The model can be initially formulated as a
project family architecture and produced from a domain
features analysis. The approach presented in this report is
intended to lead to a reuse strategy and methodology for
software development.


Experiment Transcripts for the Evaluation of the Rational Environment
CMU/SEI-88-TR-21, ADA204634
Downey, G., Bassman, M. (Computer Sciences Corporation), Dahlke, C. (Computer Sciences 
Corporation).

This report supplements the report Evaluation of the Rational
Environment (CMU/SEI-88- TR-15). It contains the
instantiation of the experiments presented in the Evaluation
of Ada Environments by Nelson Weiderman, N., et al.
(CMU/SEI-87-TR-1). Overall conclusions and analysis of the
Rational Environment can be found in Evaluation of the
Rational Environment.


MasterTask: The Durra Task Emulator
CMU/SEI-88-TR-20, ADA199429
Barbacci, M. 

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.


Generalized Image Library: A Durra Application Example
CMU/SEI-88-TR-19, ADA199481
Barbacci, M., Doubleday, D. 

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.


Durra Runtime Environment, The
CMU/SEI-88-TR-18, ADA199480
Barbacci, M., Doubleday, D., Weinstock, C.

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.


Distributed Ada Real-Time Kernel
CMU/SEI-88-TR-17, ADA199482
Bamberger, J., Coddington, T., Firth, R., Klein, D., Stinchcomb, D., Van Scoy, R., Colket, C.

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


Kernel Facilities Definition
CMU/SEI-88-TR-16, ADA198933
Bamberger, J., Coddington, T., Firth, R., Klein, D., Stinchcomb, D., Van Scoy, R., Colket, C.

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.


Evaluation of the Rational Environment
CMU/SEI-88-TR-15, ADA198934
Feiler, P., Dart, S., Downey, G.

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 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.


Phase I Testbed Description: Requirements and Selection Guidelines
CMU/SEI-88-TR-13, ADA223895
Holibaugh, R., Perry, J. 

The Application of Reusable Software Components Project has
constructed a reuse testbed for conducting software
engineering experiments in software reusability. The hardware
and system software of the testbed will provide a distributed
computing environment with file- server capability for the
storage of reusable components and other artifacts of the
development process. The testbed will support a variety of
domain-independent and domain- dependent reusable components.
The testbed will also support tools that foster reuse. This
document contains the requirements and selection criteria for
the testbed hardware, software, reusable resources, and an
environment. For each of these four testbed resources, the
requirements are grouped into five areas: support of
experiments, maximization of experience and reusability,
applicability to problem domains, acceleration of technology
transition, and advancing the state of the practice in reuse.


Managing Development of Very Large Systems: Implications for Integrated Environment 
Architectures
CMU/SEI-88-TR-11, ADA197671
Feiler, P., Smeaton, R. 

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.


Software Process Modeling
CMU/SEI-88-TR-9, ADA197137
Kellner, M., Hansen, G 

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.


Guide to the Assessment of Software Development Methods, A
CMU/SEI-88-TR-8, ADA197416
Wood, W., Pethia, R., Roberts Gold, L. Firth, R.

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.


Project Management Experiment, The
CMU/SEI-88-TR-7, ADA197490
Feiler, P., Smeaton, R 

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.


Serpent Runtime Architecture and Dialogue Model
CMU/SEI-88-TR-6, ADA196664
Bass, L., Hardy, E., Hoyt, K., Little, R., Seacord, R.

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.


Introduction to the Serpent User Interface Management System
CMU/SEI-88-TR-5, ADA200085
Bass, L., Hardy, E., Hoyt, K., Little, R., Seacord, R.

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.


Evaluation and Recommendations for Technology Insertion into Technical Order Maintenance
CMU/SEI-88-TR-4, ADA197136
Hansen, G., Over, J. 

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.


ISTAR Evaluation
CMU/SEI-88-TR-3, ADA201345
Graham, M., Miller, D. 

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.


Summary of SEI Technical Operations: 1987 (CMU/SEI-88-TR-1,
ADA200631) 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.


Interfacing Ada and SQL
CMU/SEI-87-TR-48, ADA199634
Engle, C., Firth, R., Graham, M., Wood, W.

The SEI was asked by the Ada Joint Program Office to
investigate the problem of interfacing programs written in
Ada with database management systems implementing the SQL
database language. The authors decided to concentrate on a
description of the problems involved in producing an
interface that would be worthy of becoming a standard. This
document is meant to assist the reader in answering the
question "What constitutes a good interface between Ada and
SQL?" The document should be useful both in the production of
a standard and in the analysis of any proposed standard.



IDL: Background and Status
CMU/SEI-87-TR-47, ADA188922
Stone, D., Nestor, J. 

This paper presents an overview of the Interface Description
Language (IDL). We describe the language and its history. We
also discuss the status of the IDL community.


Evolving Persistent Objects in a Distributed Environment
CMU/SEI-87-TR-46, ADA188924
Nestor, J. 

This paper considers a class of objects, called incrementally
mutable objects, that are intermediate between mutable and
immutable objects. Intuitively, the only permitted
modifications to an incrementally mutable object are those
that add new information to the object while preserving
existing information. Changes to incrementally mutable
objects do not require central synchronization. When a
network becomes partitioned, the same incrementally mutable
object can be safely modified in each subnetwork. A mutable
object can be modeled by a set of immutable objects that
represent each value of the object over time and an
incrementally mutable object that relates each immutable
object to its successor.  Multiple successors are permitted
to represent parallel changes.


Views for Evolution in Programming Environments
CMU/SEI-87-TR-45, ADA188923
Nestor, J. 

Programming environments have become a focal point for much
of the work directed toward improving the practice of
software engineering. Such environments must provide
mechanisms for recording and organizing the complex set of
persistent technical and management data associated with all
parts of the life cycle of large software systems. This paper
focuses on one important aspect of such persistent data: how
to allow evolution when the existing information must be
preserved without change to maintain history. First, the role
of history in programming environments is discussed. Next,
the additional demands of evolution are considered and shown
to lead to a set of problems. View mechanisms are suggested
as a solution to the problems. A simple example involving
file system directory structure is presented to illustrate
these problems. A simple view mechanism, called
multidirectories, is introduced and shown to solve the
illustrated problems.


Report on the SEI Workshop on Ada in Freshman Courses
CMU/SEI-87-TR-44, ADA188927
Ford, G. editor 

The Undergraduate Software Engineering Education Project of
the SEI Education Program sponsored a workshop on Ada in
Freshman Courses in June 1987. The workshop brought together
several educators to discuss how the software engineering
content of beginning programming and data structures courses
might be improved. This report describes the workshop and
summarizes the discussions and conclusions, and it also
includes the position papers prepared by the participants.


Issues in Software: A Blue Two Visit Feasibility Assessment
CMU/SEI-87-TR-42, ADA199877
Hefley, B. 

The SEI participated in a series of fact-finding meetings
sponsored by the Air Force Coordinating Office for Logistics
Research to gather information necessary to set the scope for
and to implement one or more Blue Two Visits on software. The
purpose of a Blue Two Visit (BTV) is to introduce to
industry's top design engineers and program managers the
day-to-day constraints Air Force maintainers face on
front-line operations bases. The participants experience
first-hand the effects of design on maintenance. This
exposure has been significant in bridging the gap between DoD
and industry in understanding, documenting, and supporting
Air Force weapon system requirements to increase combat
supportability. This report documents discussions that
attempt to address the following questions for a
software-oriented BTV: 1) Do software maintainers and users
have messages for software designers and programmers? 2) What
are these messages? 3) How can these messages be best
communicated? 4) To whom should these messages be targeted?
5) What should the BTV be called?


Classification Scheme for Software Development Methods, A
CMU/SEI-87-TR-41, ADA200606
Firth, R., Wood, W., Pethia, R., Roberts Gold, L., Mosley, V. Dolce, T.

Software development methods are used to assist with the
process of designing software for real-time systems. Many
such methods have come into practice over the last decade,
and new methods are emerging. These new methods are more
powerful than the old ones, especially with regard to
real-time aspects of the software. This report describes a
classification scheme for software development methods,
includes descriptions of the major characteristics of such
methods, and contains some words of advice on choosing and
applying such methods.


Ada Performance Benchmarks on the Motorola MC68020: Summary and Results
CMU/SEI-87-TR-40, ADA200610
Donohoe, P. 

This report documents the results obtained from running the
ACM SIGAda Performance Issues Working Group (PIWG) and the
University of Michigan Ada performance benchmarks on a
Motorola MC68020 microprocessor (MVME133 VMEmodule Monoboard
Microcomputer), using the Systems Designers Ada-Plus, the
TeleSoft TeleGen2, and the Verdix VAX/VMS hosted
cross-compilers. A brief description of the benchmarks and
the test environment is followed by a discussion of some
problems encountered and lessons learned. Wherever possible,
the output of each benchmark program is also included.


Prototype Real-Time Monitor: Ada Code
CMU/SEI-87-TR-39, ADA191095
Van Scoy, R. 

This report documents the Ada code of the prototype real-time monitor (RTM).



Prototype Real-Time Monitor: Design
CMU/SEI-87-TR-38, ADA188931
Van Scoy, R., Plinta, C., D'ippolito, R., Lee, K., Rissman, M.

This report describes the software design used to implement
the prototype real-time monitor requirements. The design is
presented at three levels: system level, object level, and
package architecture level. The report concludes with a
discussion of the key implementation obstacles that had to be
overcome to develop a working prototype: determining system
addresses, communicating with an executing application,
accessing application memory, converting data into
human-readable form, and distributed CPU architectures.


Prototype Real-Time Monitor: User's Manual
CMU/SEI-87-TR-37, ADA188930
Van Scoy, R., Plinta, C., D'Ippolito, R., Lee, K., Rissman, M.

This report defines the user interface to the prototype
real-time monitor (RTM). It defines the concepts and commands
needed by a software engineer to use the RTM. In addition to
defining the user interface, the report explains the steps
needed to tailor the RTM to work with the users application.


Prototype Real-Time Monitor: Requirements
CMU/SEI-87-TR-36, ADA188929
Van Scoy, R., Plinta, C., D'Ippolito, R., Lee, K., Rissman, M.

The requirements imposed by flight simulators and good
software engineering practice on Ada systems force software
engineers to seek new solutions to the problem of monitoring
executing software. This report examines some of these
requirements and, based on these requirements, defines a
subset for implementation as a prototype real-time monitor
(RTM).


Prototype Real-Time Monitor: Executive Summary
CMU/SEI-87-TR-35, ADA188928
Van Scoy, R., Plinta, C., D'Ippolito, R., Lee, K., Rissman, M.

This report summarizes the history, goals, and conclusions of
the prototype real-time monitor development effort. This
effort was undertaken to address two specific technical
questions: 1) How can user tools find, access, and display
data hidden in the bodies of Ada applications? 2) How can
user tools be layered on top of Ada applications? The effort
resulted in a generally usable prototype, which is documented
by four other SEI reports (CMU/SEI-87-TR-36 through
CMU/SEI-87-TR-39).


Inertial Navigation System Simulator Program: Top-Level Design
CMU/SEI-87-TR-34, ADA200605
Klein, M., Landherr, S. 

A real-time Ada application, an Inertial Navigation System
(INS) simulator, is being developed by the Real-Time Embedded
Systems Testbed Project as a vehicle to analyze issues
regarding the use of Ada in the real-time embedded domain and
to provide a context for future experimentation. The
technical philosophy behind developing a real-time Ada
artifact is to: (1) select a representative (e.g., strict
timing demands, multiple concurrent activities, low-level
I/O, error handling, interrupts, and periodic activities)
real-time application; (2) use Ada tasks as the unit of
concurrency for the real-time design; and (3) apply any
relevant practical results being produced by the real-time
scheduling research community. In particular, the INS
simulator must satisfy a set of timing requirements that are
similar to an INS with respect to data updating, message
transmission, and message reception. This document discusses
the top-level design of this application from three points of
view: data flow perspective, concurrency and control
perspective, and the Ada module perspective.



Inertial Navigation System Simulator: Behavioral Specification
CMU/SEI-87-TR-33, ADA200604
Landherr, S., Klein, M. 

The Real-Time Embedded Systems Testbed Project at the SEI is
specifying and developing a representative real-time
application. This document augments an original set of
specifications written by a Navy affiliate. The purpose of
this behavioral specification is to clarify and augment the
original.


VAXELN Experimentation: Programming a Real-Time Periodic Task Dispatcher Using VAXELN 
Ada 1.1
CMU/SEI-87-TR-32, ADA200612
Borger, M. 

The purpose of this paper is to provide the reader with some
technical information and observations, Ada source code, and
measurement results based on experimentation with respect to
developing a real-time periodic task dispatcher in Ada. In
this context, a periodically scheduled task set implies that
each task in the set is executed at its own fixed frequency;
a periodic task dispatcher is a software component that
schedules the individual tasks at their implied runtime
frequency. The results presented here are specific to a
MicroVAX-II/VAXELN 2.3 target system, the VAXELN 1.1 Ada
compiler, and a KWV11- C programmable real-time clock.
Specifically, these results provide answers to the question:
How can one achieve the effect of scheduling a set of
periodic Ada tasks when the runtime frequency of some of the
individual tasks is less than the clock-cycle frequency
supported by an Ada runtime implementation?


Annual Technical Report for Ada Embedded Systems Testbed Project
CMU/SEI-87-TR-31, ADA200609
Weiderman, N. Altman, N., Borger, M., Donohoe, P., Hefley, B., Klein, M., Landherr, S., Mumm, 
H., Slusarz, J.

The purpose of the Ada Embedded Systems Testbed Project (now
called the Real-Time Embedded Systems Project) is to
investigate some of the critical issues in using Ada for
real-time embedded applications, particularly the extent and
quality of the runtime support facility provided by Ada
implementations. The project's objective has been to generate
new information about using Ada in real-time embedded
systems. This information is in the form of benchmark test
results, higher level experiment results, and lessons learned
in designing and implementing real-time applications in Ada.
This technical report provides an overview of the results
produced in the first year of the project (through September
30, 1987). Details of these results are contained in other
referenced technical reports.


Criteria for Constructing and Using an Ada Embedded System Testbed
CMU/SEI-87-TR-30, ADA188932
Weiderman, N. 

The purpose of this report is to list some of the criteria
used in five aspects of the project: the hardware
configuration, the software configuration, the real-time
application, the Ada real-time experiments, and the
benchmarking and instrumentation techniques. Each criterion
will include a rationale. Each of the criteria listed in this
report will be categorized as either essential, highly
desirable, or desirable.


VAXELN Experimentation: Programming a Real-Time Clock and Interrupt Handling Using
VAXELN Ada 1.1
CMU/SEI-87-TR-29, ADA188100
Borger, M. 

This report describes the results of implementing an
interrupt handler totally in Ada for a MicroVAX II/VAXELN 2.3
target system, the VAXELN 1.1 Ada compiler, and a KWV11- C
programmable real-time clock. It provides an overview of
VAXELN interrupt handlers and the operation of the real-time
clock; discusses and demonstrates the use of VAXELN kernel
services to establish a link between the clock's interrupt
and the starting address of an interrupt service routine;
presents an Ada package of interfaces to the KWV11-C device;
provides Ada source code examples demonstrating the use of
this package; and presents relevant observations,
recommendations, and measurement results.


Survey of Real-Time Performance Benchmarks for the Ada Programming Language, A
CMU/SEI-87-TR-28, ADA200608
Donohoe, P 

This survey provides a summary description of some of the
major Ada benchmarks currently available and an evaluation of
their applicability to the Real-Time Embedded Systems Testbed
Project at the SEI. The benchmarks discussed are the
University of Michigan benchmarks, the ACM Performance Issues
Working Group (PIWG) benchmarks, and the prototype Ada
Compiler Evaluation Capability (ACEC) of the Institute for
Defense Analyses (IDA).


Ada Performance Benchmarks on the MicroVAX II: Summary and Results
CMU/SEI-87-TR-27, ADA200607
Donohoe, P. 

This report documents the results obtained from running the
University of Michigan and the SIGAda Performance Issues
Working Group (PIWG) Ada performance benchmarks on a DEC
VAXELN MicroVAX II using the DEC VAXELN Ada compiler. A brief
description of the benchmarks and the test environment is
followed by a discussion of some problems encountered and
lessons learned. The output of each benchmark program is also
included.


		-----end Part 3 (of 5) -----

Barbara Zayas			Software Engineering Institute
(bjz@sei.cmu.edu)		(412) 268-6378
===========================================================================
Co-moderator:  Richard Golding, Computer & Information Sciences, UC Santa Cruz
	    compdoc-techreports-request@ftp.cse.ucsc.edu