This paper addresses integrity rules that are embedded within engineering design applications and that apply between applications. A representation for integrity rules that are embedded in applications is presented and a set of related methods developed for: (a.) maintaining the integrity condition of application developed data, (b) managing the precedence order between applications, in the context of (c.) changing the schema and the associated mix of applications and (d.) iterated execution of applications and change propagation. Both integrity rules literally embedded within external applications and others required to be embedded within a database are considered. The techniques are demonstrated with an extensive example.

A new vision effecting adaptiveness in integrated manufacturing enterprises for the next decade is formulated. This vision has been developed on the basis of intensive research over the past nine years in Rensselaer's industry-sponsored Computer Integrated Manufacturing Program. Built from existing results in both the scientific community and industry, the proposed research agenda calls for new fundamental information technology to enable Adaptive Integrated Manufacturing Enterprises (AIME). It focuses on four major problems: (1) Management of multiple systems that operate concurrently over a widely distributed network without a central controller; (2) Achievement of an open systems architecture that can accommodate legacy systems as well as add new systems; (3) Exploitation of object-oriented technology in production systems with the crucial ability to manage heterogeneous views and propagate changes between views; and (4) Modeling of enterprise information requirements for inspe...

Manufacturing information integration requires translations among various functional systems' information models which are based on different paradigms (e.g., Entity-Relationship, Relational, and Object). In order to facilitate this potentially overwhelming task, a meta-model is needed to serve as the conceptual schema for models integration at both development phase and run-time. This paper presents a particular framework for the concept and discusses the promises of the TSER (Two-Stage EntityRelationship) model as a meta-model for Object-Oriented Methods, the Relational model, and Entity-Relationship models. The connections to the PDES/EXPRESS model are included.

: Many applications of object-oriented systems benefit from the ability to make objects persistent. To be fully effective, this persistence must be provided in such a way as to allow both the database of persistent objects and the applications to evolve. As they evolve, upward compatibility must be maintained so that new versions of applications can continue to use existing persistent objects and vice versa. This implies that a persistent object system must be able to handle type mismatches between objects in secondary storage and objects in an application program. In this paper, we formalize some of the categories of type mismatches that can occur as a result of application program and database evolution. We show how the concept of an object manager can be used to resolve many of the mismatches in these categories. Finally, we discuss how object managers have been incorporated into a particular persistent object system under development at Rensselaer Polytechnic Institute. 1. Introduc...

test suites enable the development of good processors and encourage expectations of trouble-free exchange. NIST, working with representatives from the United Kingdom and France, was instrumental in establishing the requirement that abstract test suites be standardized in ISO 10303. Several of the STEP conformance testing concepts were modeled after the ISO 9646 [64] series of parts. This standard helped establish a foundation for concepts, methods, and vocabulary. SC4 also had the advantage of learning from the ISO 9646 mistakes. By not standardizing the ATSs in the OSI example, one was never assured an ATS would exist for testing an implementation against a particular OSI application. No assurance of an ATS meant no assurance for an ability to test an implementation of the standard. SC4 hoped by standardizing ATSs it would: . Bring appreciation to the forefront for the requirement.

Abstract not found