From: bjz@sei.cmu.edu (Barbara Zayas)
Newsgroups: comp.doc.techreports
Subject: Software Engineering Institute reports (Part 5 of 5)
Date: Tue, 6 Oct 1992 13:05:59 GMT
Organization: Software Engineering Institute
NNTP-Posting-Host: oak.ucsc.edu
Originator: golding@oak



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 5 (of 5) -----

MISCELLANEOUS

Quarterly Update, Apr-Jun 1992
2Q92, CMU/SEI-92-CDRL-103-2, ADA254721

Quarterly Update, Jan-Mar 1992
1Q92, CMU/SEI-92-CDRL-103-1

1991 Summary of Technical Operations
CMU/SEI-91-CDRL-106, ADA248153
January 1992

Quarterly Update, Jul-Sep 1991
3Q91, CMU/SEI-91-CDRL-103-3, ADA245104

Quarterly Update, Apr-Jun 1991
2Q91, CMU/SEI-91-CDRL-103-2

Quarterly Update, Jan-Mar 1991
1Q91, CMU/SEI-91-CDRL-103-1, ADA236099

Quarterly Update, Jul-Sep 1990
3Q90, CMU/SEI-90-CDRL-103-3

Quarterly Update, Apr-Jun 1990
2Q90, CMU/SEI-90-CDRL-103-2, ADA22681

Quarterly Update, Jan-Mar 1990
1Q90, CMU/SEI-90-CDRL-103-1, ADA22697

Quarterly Update, Jul-Sep 1989
3Q89, CMU/SEI-89-CDRL-103-3

Quarterly Update, Apr-Jun 1989
2Q89, CMU/SEI-89-CDRL-103-2

Quarterly Update, Jan-Mar 1989
1Q89, CMU/SEI-89-CDRL-103-1


Serpent: Guide to Adding Toolkits
CMU/SEI-91-UG-8, ADA240607

Serpent is a user interface management system (UIMS) that
supports the development and implementation of user
interfaces, providing an editor to specify the user interface
and a runtime system that enables communication between the
application and the end user. This manual describes how to
add toolkits to Serpent. A generic description of how to
integrate any toolkit into Serpent is followed by
descriptions of two tools. These tools are Glue, a
generalized widget integration facility, and Six, a generic
Serpent-to-Xt binding driver.

Readers of this guide are assumed to have programming
experience in C or Ada, and to have read and understood the
concepts described in the Serpent Overview (CMU/SEI-91- UG-1)
and Serpent: System Guide (CMU/SEI-91-UG-2).


Serpent: Ada Application Developer's Guide
CMU/SEI-91-UG-7, ADA244653

Serpent is a user interface management system (UIMS) that
supports the development and implementation of user
interfaces, providing an editor to specify the user interface
and a runtime system that enables communication between the
application and the end user. This manual describes how to
develop applications using Serpent. Readers are assumed to
have read and understood the concepts described in the
Serpent Overview, as well as to have had experience using the
Ada programming language.


Serpent: C Application Developer's Guide
CMU/SEI-91-UG-6, ADA240609

Serpent is a user interface management system (UIMS) that
supports the development and implementation of user
interfaces, providing an editor to specify the user interface
and a runtime system that enables communication between the
application and the end user. This manual describes how to
develop applications using Serpent. Readers are assumed to
have read and understood the concepts described in the
Serpent Overview (CMU/SEI-91-UG-1), as well as to have had
experience using the C programming language.


Serpent: Slang Reference Manual
CMU/SEI-91-UG-5, ADA240608

Serpent is a user interface management system (UIMS) that
supports the development and implementation of user
interfaces, providing an editor to specify the user interface
and a runtime system that enables communication between the
application and the end user. This manual describes the
model, syntax, and semantics of the Slang dialogue language,
the language within Serpent used for the specification of
user interfaces. Readers should be familiar with general UIMS
concepts, have a working knowledge of programming languages,
and understand the concepts described in the Serpent Overview
(CMU/SEI/91- UG-1) and Serpent: System Guide
(CMU/SEI-91-UG-2).


Serpent: Dialog Editor User's Guide
CMU/SEI-91-UG-4, ADA242331

Serpent is a user interface management system (UIMS) that
supports the development and implementation of user
interfaces. This document provides guidelines for using the
Serpent dialogue editor.


Serpent: Saddle User's Guide
CMU/SEI-91-UG-3, ADA240602

Serpent is a user interface management system (UIMS) that
supports the development and implementation of user
interfaces, providing an editor to specify the user interface
and a runtime system that enables communication between the
application and the end user. This document describes Saddle,
the language used to specify interfaces between an
application and Serpent. Included is information on creating
Saddle files (files that define the data shared by the
application and the user interface) and executing Saddle.


Serpent: System Guide
CMU/SEI-91-UG-2, ADA240605

Serpent is a user interface management system (UIMS) that
supports the development and implementation of user
interfaces, providing an editor to specify the user interface
and a runtime system that enables communication between the
application and the end user. This document introduces the
environment variables used by Serpent, the file naming
conventions and expected file types, and how to build a
Serpent dialogue/application from scratch.


Serpent Overview
CMU/SEI-91-UG-1, ADA240606

Serpent is a user interface management system (UIMS) that
supports the development and implementation of user
interfaces, providing an editor to specify the user interface
and a runtime system that enables communication between the
application and the end user. This document provides an
overview of the Serpent system. It is intended for software
engineers involved in user interface development and assumes
no previous knowledge of Serpent.


Hartstone Benchmark User's Guide, Version 1.0 
CMU/SEI-90-UG-1, ADA235740
Donohoe, P.

The Hartstone benchmark is a set of timing requirements for
testing a system's ability to handle hard real-time
applications. It is specified as a set of processes with
well-defined workloads and timing constraints. The name
Hartstone derives from HArd Real Time and the fact that the
workloads are presently based on the well-known Whetstone
benchmark.  This report describes the structure and behavior
of an implementation in the Ada programming language of one
category of Hartstone requirements, the Periodic Harmonic
(PH) Test Series. The Ada implementation of the PH series is
aimed primarily at real-time embedded processors where the
only executing code is the benchmark and the Ada runtime
system. Guidelines for performing various Hartstone
experiments and interpreting the results are provided. Also
included are the source code listings of the benchmark,
information on how to obtain the source code in
machine-readable form, and some sample results for Version
1.0 of the Systems Designers XD Ada VAX/VMS - MC68020
cross-compiler.


Kernel User's Manual, Version 1
CMU/SEI-89-UG-1, ADA228514
Bamberger, J., Coddington, T., Firth, R., Klein, D., Stinchcomb, D., Van Scoy, R.

This manual describes the models underlying the Kernel and
its concept of operations, presents the primitives available
to the application program, and provides a number of
abstractions that may readily be built on top of Kernel
primitives.


AJPO User's Guide for MH, the Rand Message Handling System, An
CMU/SEI-88-UG-1, ADA204635
Moss, S., Jackson, P. 

The purpose of this document is to provide an introduction to
the fundamentals of the Rand Message Handling (MH) system.
The document is intended to be a tutorial on and a quick
reference to the aspects of MH that are used most frequently.
This document does not provide detailed discussions of the
technical aspects of MH, nor does it cover all of the topics
relevant to advanced use of MH. For more detailed
information, see the documents referenced below, or check for
Unix man pages online or in the Unix Programmer's Manual.

Parts of this document are based on MH for Beginners by Mary
Hegardt and Tim Morgan and The Rand MH Message Handling
System: Tutorial by Marshall T. Rose and Jerry N.  Sweet. For
more detailed information, we recommend The Rand MH Message
Handling System: User's Manual by Marshall T. Rose and John
L. Romine.


Distributed Ada Real-Time Kernel (DARK) Technology Transition Plan
SEI-88-TP-1
Carey, S. 

This plan describes the project objectives and progress of
the Distributed Ada Real-Time Kernel (DARK) Project in order
to effectively plan and execute appropriate technology
transition activities. The information contained within the
document was gathered from sources listed in the plan
history.


TECHNICAL MEMOS

Intelligent Assistance Without Artificial Intelligence
SEI-86-TM-14, ADA182094
Kaiser, G., Feiler, P. 

SMILE is a distributed, multi-user software engineering
environment that behaves as an intelligent assistant. SMILE
presents a `fileless environment,' derives and transforms
data to shelter users from entering redundant information,
automatically invokes programming tools, and actively
participates in the software development and maintenance
process.  Unlike other intelligent assistants, SMILE is not a
rule-based environment: its knowledge of software objects and
the programming process is hardcoded into the environment. We
describe SMILE's functionality and explain how we achieved
this functionality without reliance on artificial
intelligence technology.


Relationship Between IDL and Structure Editor Generation Technology
SEI-86-TM-13, ADA181937
Feiler, P. 

This paper discusses observed commonalities and differences
between IDL and structure editor generation technologies. IDL
(Interface Description Language) is technology for generation
of tool intercommunication support with roots in compiler
generation. Structure editor generation technology has its
roots in syntax-directed editors. It produces environments
for interactive viewing and manipulation of formally
specified structures.  Both technologies use a formal
notation for structural and constraint descriptions. From
these descriptions both generation tools automatically
produce software for reading, writing, and manipulating
instances of the described structures, as well as for
checking specified constraints on information contained in
the structures. The IDL technology emphasizes generation of
batch-oriented applications while the structure editor
generation technology is tailored to supporting interactive
applications. Structure editor generation technology has been
applied to itself, i.e., to building an interactive structure
editor generation environment.


Architecture for Intelligent Assistance in Software Development, An
SEI-86-TM-12, ADA181743
Kaiser, G., Feiler, P.

We define an architecture for a software engineering
environment that behaves as an intelligent assistant. Our
architecture consists of two key aspects: an objectbase and a
model of the software development process. Our objectbase is
adapted from other research, but our model is unique in that
it consists primarily of rules that define the preconditions
and multiple postconditions of software development tools.
Metarules define forward and backward chaining among the
rules. Our most significant contribution is opportunistic
processing, whereby the environment automatically performs
software development activities at some time between when
their preconditions are satisfied and when their
postconditions are required. Further, our model defines
strategies that guide the assistant in choosing an
appropriate point for carrying out each activity.


Granularity Issues in a Knowledge-Based Programming Environment
SEI-86-TM-11, ADA182981
Feiler, P., Kaiser, G. 

We are in the process of developing MARVEL, a knowledge-based
programming performing and coordinating their activities.
During the design of MARVEL, we discovered that the
granularity to which logical entities are refined in its
software database and the granularity with which its software
tools process the entities and report their results to the
human users have a strong impact on the degree of
intelligence that can be exhibited, as well as on the
friendliness and performance of the environment. In this
paper, we describe the many choices among alternative
granularities and explain the decisions we made during the
design of MARVEL.


Software Development Environments
SEI-86-TM-10, ADA181742
Ellison, B. 

The growing demand for reliable large scale software systems
cannot be met without advances in software development
environments. Although promising technologies are emerging, a
number of issues must be addressed to ensure the timely
transition of those technologies and projects to be
undertaken by the Software Engineering Institute to address
those issues.


IDL: Past Experiences and New Ideas
SEI-86-TM-9, ADA182022
Newcomer, J. 

This paper is based on the author's experience in
constructing an implementation of the Interface Description
Language (IDL). The result of this experience was some
insights into language design, human interfaces, and system
structuring, as well as methodologies for the composition of
complex tools. Certain complexities of the IDL implementation
are discussed in this paper, showing that quite efficient
implementations are possible. Finally, a set of interesting
directions for IDL and IDL derived systems are suggested,
including programming environment and database related work.


Toward a Persistent Object Base
SEI-86-TM-8, ADA182983
Nestor, J. 

To better understand the needs of future programming
environments, two current technologies that support
persistent data in programming environments are considered:
file systems and data base systems. This presents a set of
weaknesses present in those current technologies. These
weaknesses can be viewed as a checklist of issues to be
considered when evaluating or designing programming
environments.


Challenges of Educating the Next Generation of Software Engineers, The
SEI-86-TM-7, ADA181293
Gibbs, N., Ford, G. 

The continuing growth in the number, size, and complexity of
software systems has created an enormous demand for high
quality software engineers. A strategy for educating new
software engineers is presented, and the projects of the
Education Division of the Software Engineering Institute that
support this strategy are described.


Beyond Programming-in-the-Large: The Next Challenges for Software Engineering
SEI-86-TM-6, ADA181294
Shaw, M. 

As society's dependence on computing broadens, software
engineering is being called upon to address new problems that
raise new technical and non-technical concerns. Aspirations
and expectations for the application of computers appear to
be unbounded, but present software development and support
techniques will not be adequate to build computational
systems that satisfy our expectations, even at very high
cost. Each order of magnitude increase in the scale of the
problems being solved leads to a new set of critical problems
that require essentially new solutions. The next challenges
for software engineering will deal with software as one of
many elements in complex systems, which we call program-
as-component and with the role of software as an active
participant in the software development process, which we
call program-as-deputy.


Education for the Future of Software Engineering
SEI-86-TM-5, ADA175227
Shaw, M. 

The discipline of software engineering is developing rapidly.
Its practitioners must deal with an evolving collection of
problems and with new technologies for dealing with those
problems. Software engineering education must anticipate new
problems and technologies, providing education in the
enduring principles of the field in the context of the best
current practice. Since changes in the discipline cannot be
completely anticipated, software engineers must be able to
assume responsibility for their own continuing professional
development. This paper describes significant changes now
taking place in the field of software engineering and
proposes some goals and objectives for the professional
education of software engineers.


Software Support for Heterogeneous Machines
SEI-86-TM-4, ADA175237
Barbacci, M. 

This paper describes a new research effort carried out
jointly between the Software Engineering Institute and the
Department of Computer Science at Carnegie Mellon University.
The objective of the project is to investigate languages,
methodologies, and tools for programming computer systems
consisting of networks of heterogeneous processors. Typical
users of these notations (and associated support software)
will be the developers of real-time, computation-intensive
applications such as those contemplated under the Strategic
Computing Initiative. In particular, this research is being
conducted in the context of the Autonomous Land Vehicle
application, running on the Heterogeneous Machine being
developed in the Computer Science Department. This paper
provides some background on the nature of the problem posed
by these applications, the opportunities presented by the
emergence of heterogeneous machines, and the goals of this
project.


Understanding the Implications of Selling Rights in Software to the Defense Department: A 
Journey Through the Regulatory Maze
SEI-86-TM-3, ADA175166
Samuelson, P. 

This article of the Software Licensing project of the SEI
examines problems related to DoD procurement policy as
reflected in the DoD acquisition regulations (DoD FAR SUPP).
It discusses ambiguities and inconsistencies found in the
acquisition regulations and ways in which these problem areas
might result in unexpected disadvantages to both the
government and industry. Issues related to funding of
software development, treatment of technical data and
documentation, the concept of unlimited rights, the making of
derivative works and other modifications of software, and the
interface between the DoD acquisition policy and intellectual
property laws (such as copyright and trade secret law) are
discussed. The article serves to catalogue potential problems
that might arise under the DoD acquisition regulations.


Comments on the Proposed Defense and Federal Acquisition Regulations
SEI-86-TM-2, ADA175165
Samuelson, P. 

This paper compares and contrasts the software/data rights
sections (Subpart 27.4) of the DoD procurement regulations
(DoD FAR SUPP) and the Federal Acquisition Regulations (FAR).
The regulations currently in force, as well as recently
proposed revisions to those regulations, are examined.
Criticisms are made of the DoD regulations, as well as
suggestions as to how those regulations could be brought more
in line with procurement related legislation, intellectual
property law and general commercial practice within the
software industry. Inconsistencies and ambiguities found in
Subpart 27.4 of the DoD acquisition regulations are discussed
at some length. A recommendation is made that the DoD adopt a
regulatory policy more like that found in the FAR.


Adequate Planning for Acquiring Sufficient Documentation
About and Rights in Software to Permit Organic or Competitive Maintenance
SEI-86-TM-1, ADA175167
Samuelson, P. 

Both the DoD and industry have significant concerns regarding
maintenance and enhancement of software. The DoD wants to be
certain it will be able to maintain and enhance software, and
where cost effective, to compete maintenance of software.
Industry wants to ensure that its proprietary interests will
be adequately protected. This paper will explore possible
ways in which both groups' interests might be satisfied.


		-----end Part 5 (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