Type compatibility can be defined based on name equivalence, that is, explicit declarations, or on structural matching. We argue that component software has demands for both. For types expressing individual contracts, name equivalence should be used so that references are made to external semantical specifications. For types that are composed of several such contracts, the structure of this composition should decide about compatibility. We introduce

this paper, we present an approach to tool development that attacks these problems. Progress requires synergistic, interdisciplinary collaborations between application domain and software engineering researchers. We have pursued such an approach in developing a fault tree modeling and analysis tool called Galileo. We describe our innovations in two dimensions. The first is Galileo's core reliability modeling and analysis function. The second is our work on software engineering for high-quality, low-cost modeling and analysis tools. In the reliability engineering domain, Galileo supports precise, modular, dynamic fault tree analysis using techniques developed primarily by Dugan and her colleagues. This approach addresses the problem that a single analysis technique is seldom applicable to an entire system. A good reliability engineer uses different techniques to analyze different parts of a system, decomposing a complex model into smaller pieces, applying different analysis techniques to submodels, and integrating partial results into a system-level result. Manually decomposing systems into parts, developing submodels, analyzing them with different tools and techniques, and integrating the partial results is tedious and error prone at best. By contrast, Galileo automatically detects independent sub-trees; translates them into appropriate submodels based on Markov chains, Boolean decision diagrams and other formalisms, analyzes the submodels; and integrates the results. Galileo supports precise analysis while exploiting modularity for scalability in solving problems that require time and space that is exponential in the number of basic events in the worst-case.

Abstract To support rapid software evolution, it is desirable to construct software systems from reusable components. In this approach, the architecture of a system is described as a collection of components along with the interactions among these components. Whereas the main system functional blocks are components, the properties of the system also strongly depend on the character of the component interactions. This fact gave birth to the “connector ” concept which is an abstraction capturing the nature of these interactions. The problem tackled in this paper is that even though the notion of connectors originates in the earliest papers on software architectures [20, 15], connectors are currently far from being a typical first class entity in the contemporary component-based systems. By articulating the “deployment anomaly”, the paper identifies the role connectors should play when the distribution and deployment of a component-based application is considered. Further, we introduce a connector model reflected at all the key stages of an application’s development: ADL specification, deployment, and implementation

Recent advances in wireless networking technologies and the growing success of mobile computing devices, such as laptop computers...

The Microsoft Repository is an object-oriented repository that ships as a component of Visual Basic (Version 5.0). It includes a set of ActiveX interfaces that a developer can use to define information models, and a repository engine that is the underlying storage mechanism for these information models. The repository engine sits on top of a SQL database system. The repository is designed to meet the persistent storage needs of software tools. Its two main technical goals are: . compatibility with Microsoft's existing ActiveX object architecture consisting of the Component Object Model (COM) and Automation and . extensibility by customers and independent software vendors who need to tailor the repository by adding functionality to objects stored by the repository engine and extending information models provided by Microsoft and others. This paper explains how the Repository attains these goals by providing an object-oriented database (OODB) architecture based on Microsoft's binary ob...

In a distributed object system, remoting architecture refers to the infrastructure that allows client programs to invoke methods on remote server objects in a transparent way. In this paper, we study the strength and limitations of current remoting architecture of COM (Component Object Model), and propose a new architecture called COMERA (COM Extensible Remoting Architecture) to enhance the extensibility and flexibility. We describe several application scenarios and implementations to demonstrate the power of such a componentized remoting architecture.

Abstract 1 ⎯ Microsoft Repository is an object-oriented meta-data management facility that ships in Microsoft Visual Studio and Microsoft SQL Server. It includes two main components: • A repository engine that implements a set of object-oriented interfaces on top of a SQL database system. A developer can use these interfaces to define information models (i.e., schemas) and manipulate instances of the models. • The Open Information Model, which is a set of information models that cover object modeling, database modeling, and component reuse. The repository system is designed to meet the persistent storage needs of software tools. Its main technical goals are: • Compatibility with Microsoft’s Component Object Model (COM) architecture • Extensibility by customers and independent software vendors, so they can add behavior to objects stored by the repository engine and extend information models provided by Microsoft and others. • Flexible and efficient versioning, configuration management, and checkout/checkin to support team-oriented activities. This paper describes the programming interface and implementation of the repository engine and the Open Information Model. Key words: repository, information model, versions, object-oriented database 1.

When implementing persistent objects on a relational database, a major performance issue is prefetching data to minimize the number of roundtrips to the database. This is especially hard with navigational applications, since future accesses are unpredictable. We propose using the context in which an object is loaded as a predictor of future accesses, where context can be a stored collection of relationships, a query result, or a complex object. When an object O's state is loaded, similar state for other objects in O's context is prefetched. We present a design for maintaining context and using it to guide prefetch. We give performance measurements of its implementation in Microsoft Repository, showing up to a 70% reduction in running time. We describe variations that selectively apply the technique, exploit asynchronous access, and use application-supplied performance hints. 1 Introduction One way to implement persistent objects is to map them to a relational databas...

Using COTS components in the software development process introduces new problems to software testing. In particular, a consumer (user) of a COTS component typically does not have source code access nor is she aware of how well the component has been tested or how to best test it embedded in her own application. She also doesn't have any well-established guidelines for integration test adequacy. This paper proposes a solution to this problem: software components with retrospectors, which record testing and execution history of a component and make testing information available to software testers. This paper analyzes the problems of testing component-based software, introduces retrospector techniques and discusses how retrospectors can help test component-based software. Keywords Software testing, software component model, COTS 1 INTRODUCTION In 1987, Brooks speculated that software reuse (buy versus build) might provide a silver bullet for software engineers [Bro87], the hope bein...

Many software projects today are based on the integration of independently designed software components that are acquired on the market, rather than developed within the project itself. A component standard, or integration architecture, is a set of design rules meant to ensure that such components can be integrated in defined ways without undue effort. The rules of a component standard define, among other things, component interoperability and composition mechanisms. Understanding the properties of such mechanisms and interactions between them is important for the successful development and integration of software components, as well as for the evolution of component standards. This paper presents a rigorous analysis of two such mechanisms: component aggregation and dynamic interface negotiation, which were first introduced in Microsoft's Component Object Model (COM). We show that interface negotiation does not function properly within COM aggregation boundaries. In particular, interf...