COTS products can play various architectural roles in software systems: as interfaces to problem-specific functionality, as components that provide such functionality itself, and as intermediary connectors and components in more complex systems. In doing so, COTS products impose their own, unique constraints on organization and functionality. Over the last ten years, we have gained considerable experience with adopting, adapting, and living with the limitations of COTS products. Our goal was to adapt the COTS product to make it fit the application rather than adapting the application needs to make them fit the COTS product - thus, in essence, adapting the COTS product without access to its source code or documentation (a unique form of maintenance). We report on a large set of experiences involving eight COTS products and a wide range of COTS-Based Software Systems - most of which were done with and for industrial partners or government agencies. This experience report attempts to both give a feeling for how applications can be augmented with such COTS interfaces and also tries to tease out the specific architectural issues that anyone adapting COTS products is certain to face.

We exploit the spreadsheet metaphor to make deductive problem-solving methods available to the vast population of spreadsheet end users. In particular, we show how the function-based problem-solving capabilities of spreadsheets can be extended to include logical deductive methods in a way that is consistent with the existing spreadsheet "look and feel." We also show a spreadsheet-based framework for authoring logic implication rules. This framework was conceived with the objective of reproducing many of the characteristics that make spreadsheet programming accessible to end users. In the proposed framework, rule authors describe the semantics of a binary relation by constructing a functional spreadsheet model that computes the image of that binary relation. This model is subsequently translated into a collection of logic implication rules. We implemented this deductive spreadsheet system on top of Microsoft Excel and adopting the World Wide Web Consortium (W3C) standard ontology language OWL+SWRL formalisms.

COTS products can play various architectural roles in software systems: as interfaces to problem-specific functionality, as components that provide such functionality itself, and as intermediary connectors and components in more complex systems. In doing so, COTS products impose their own, unique constraints on organization and functionality. Over the last ten years, we have gained considerable experience with adopting, adapting, and living with the limitations of COTS products. Our goal was to adapt the COTS product to make it fit the application rather than adapting the application needs to make them fit the COTS product - thus, in essence, adapting the COTS product without access to its source code or documentation (a unique form of maintenance). We report on a large set of experiences involving eight COTS products and a wide range of COTS-Based Software Systems - most of which were done with and for industrial partners or government agencies. This experience report attempts to both give a feeling for how applications can be augmented with such COTS interfaces and also tries to tease out the specific architectural issues that anyone adapting COTS products is certain to face.

This paper introduces a functional spreadsheet framework for authoring logic implication rules. This framework was conceived with the objective of reproducing many of the characteristics that make spreadsheet programming accessible to end-users. In the proposed framework, rule authors describe the semantics of a binary relation by constructing a functional spreadsheet model that computes the image of that binary relation. This model is subsequently translated into a collection of logic implication rules. We implemented and integrated this framework into a deductive spreadsheet system that extends Microsoft Excel with the World Wide Web Consortium (W3C) standard ontology language OWL + SWRL.

We have gained considerable experience with adapting COTS products to act variously as interfaces to problem-specific functionality and to provide such functionality itself. Several experimental implementations were based on a tool called the Briefing Associate that augmented Microsoft's PowerPoint to support the authoring of semantically grounded applications. Others were based on other Microsoft Office products, such as Access and Excel, and yet others were based on modeling tools such as IBM Rational Rose or Mathwork's MatLab. This report both gives a feeling for how applications can be augmented with such COTS interfaces and also discusses some of the problems that anyone adapting COTS tools is certain to face.

Commercial-off-the-shelf (COTS) software tends to be cheap, reliable, and functionally powerful due to its large user base. It has thus become highly desirable to incorporate COTS software into software products (systems) as it can significantly reduce development cost and effort, while maintaining overall software product quality and increasing product acceptance. However, incorporating COTS software into software products introduces new complexities that developers are currently ill equipped to handle. Most significantly, while COTS software frequently contains programmatic interfaces that allow other software components to obtain services from them on a direct call basis, they usually lack the ability to initiate interactions with other components. This often leads to problems of state and/or data inconsistency. This paper presents a framework for integrating COTS software as proactive components within a software system that maintain the consistency of the state and data they share with other components. The framework utilizes a combination of low-level instrumentation and high-level reasoning to expose the relevant internal activities within a COTS component required to initiate the communication needed to maintain consistency with the other components with which it shares state and data. We will illustrate these capabilities through the integration of IBM's Rational Rose into a design suite and demonstrate how our framework solves the complex data synchronization problems that arise from this integration.

The key objective of this workshop is to explore innovative approaches to the adoption of software engineering tools and practices-in particular by embedding them in extensions of Commercial Off-The-Shelf (COTS) software products and/or middleware technologies. The workshop aims to advance the understanding and evaluation of adoption of software engineering tools and practices by bringing together researchers and practitioners who investigate novel solutions to software engineering adoption issues.

The ANTs environment consists of numerous distributed software agents and hardware components. System development in such an environment requires a means of observing and validating the potentially hidden activities of these components. Existing visualization and debugging tools provide some mechanisms for observing behaviors and detecting faults in individual components, but the fast-paced nature of ANTs agents makes these conventional user interfaces (visualizations) and debugging techniques less effective. This chapter will discuss several techniques for visualizing and debugging complex, real-time, agent-based systems. These techniques vary in their level of invasiveness and general applicability.

Rather than being a major (and uncontrollable) source of instability to a COTS extension, upgrades of COTS products - over a ten year period - have produced little or no impact on our extensions. We hypothesize that this evolution stability is not an accident, but rather the result of the architectures in which those extensions were developed.

The whole idea of product families is building shared assets that can be leveraged to develop members of the product family. This has led product family developers to focus on three classes of shared assets because they knew how to leverage assets of those classes. These classes are reference architectures, reusable components, and component generators. Reference architectures define the span of a product family by providing a framework for obtaining the members through instantiation. The leverage gained from this class arises from shared structure, interaction protocols, services, interfaces, and components. Reusable components are generalized versions of components that can be specialized for particular family members through configuration and/or run-time parameters. The leverage gained from this class arises from avoiding the time and cost of rebuilding those components for each family member and from using more mature, higher quality, and better tested components. The structure, protocol, interface, and service restrictions specified in the reference architecture make it feasible to define the range that the components of that architecture must span. It can then be determined whether this space can be spanned through configuration and run-time parameterization. If so, prebuilt reusable components are the appropriate shared asset class. If not, generators must be employed to custom build each family member from specifications. The leverage gained from this third class is the same as the reusable component class, only the means of obtaining this shared asset is different.

The Semantic Web has clear benefits for information consumers, but for authors it typically means added work with no immediate payoff. This article describes Briefing Associate (BA), a tool that eases the effort by automating markup within a popular commercial off-the-shelf (COTS) application. The BA is a descendent of the Design Editor, an application for producing visual, domain-specific design environments. Both tools are implemented as extensions of Microsoft's PowerPoint, which, as this paper describes, is a key factor in our research.

It is becoming increasingly desirable to incorporate commercial-off-the-shelf (COTS) tools as software components into larger software systems. Due to their large user base, COTS tools tend to be cheap, reasonably reliable, and functionally powerful. Reusing them as components has the benefit of significantly reducing development cost and effort. Despite these advantages, developers encounter major obstacles in integrating most COTS tools because these tools have been constructed as stand-alone applications and make assumptions about their environment that do not hold when used as part of larger software systems. Most significantly, while they frequently contain programmatic interfaces that allow other components to obtain services from them on a direct call basis, they almost always lack the notification and data synchronicity facilities required for active integration. The authors present an integration framework for adding these notification and data synchronization facilities to COTS tools so that they can be integrated as active software components into larger systems. We illustrate our integration framework through tool suites we constructed around Mathworks' Matlab/Stateflow and Rational's Rose (two widely-used, large COTS tools). Our experience to date is that it is indeed possible to transform standalone COTS tools into software components.

This is a short paper about a simple technique for making applications robust by marking data that violates specially identified invariants and using those marks as guards around code which is sensitive to that invariant.Such a capability is needed when dealing with the exceptions that arise in practical applications and distinguish them from idealized specifications. Previous techniques either required the removal of the constraint so that the exception would be allowed, or its modification to exclude the particular exception from the restriction.Our technique softens the entire constraint without introducing special cases, and is intended primarily for temporary exceptions. Rather than synchronizing all updates required by some constraint, it allows them instead to occur distributed in time in any arbitrary order. Thus, it is particularly useful in multiclient applications with shared responsibilities and authority, such as cooperative design (including software development).While the constraint is violated, the offending data is automatically marked by guards to screen it from, or identify it to, code segments sensitive to the violation. When the time distributed update is complete so that the data is no longer inconsistent, the guards are automatically removed so that the data can again be processed normally.The relevance of this work to the Process Workshop is that it provides a technique for relaxing the synchronization problem among multiple users cooperating on some compound update and allows them instead to operate asynchronously. That is, this technique allows us to write more realistic process programs describing the flexible time-distributed coordinations among agents without loosing the formal constraints on their shared goals. The cost of this flexibility is the conditionalization of the cooperating agents to tolerate these temporary inconsistencies.We have created two implementations of our technique for softening constraints to allow temporary inconsistencies. Both are fully automatic and both handle arbitrary constraints expressed in our first-order logic formalism. The first converts the original constraint into a pair of constraints that require the presence of the guards while the original constraint is violated and their absence otherwise. These new constraints have “repairs” which fix violations by respectively inserting or removing the guards. The second implementation replaces the original constraint by an inference rule which derives the guard if and only if the original constraint predicate was violated.Our contribution lies in formally representing constraints whose temporary inconsistency can be tolerated by an application, and in automatically marking the particular offending data while the constraint is being violated. The goal of minimizing the number and duration of such violations is informal and implicit. The task of identifying sensitive code segments and determining how they should respond to the temporary inconsistencies is likewise informal and manual.Our work has an interesting relationship with the recent work on transactions by Pu, Kaiser, and Hutchinson @cite(Split-Transactions) addressing the times and set of users over which a constraint applies. They, too, are interested in multi-party transactions, and have proposed “splitting” transactions into pieces with differing visibility scopes so that users in some group could see the changes made by the splits within the transaction, while those outside the group wouldn't see any changes until the entire transaction was committed.Split-Transactions can be viewed as another approach to exception handling. Rather than dealing with an exception or an inconsistency after a completed transaction, Pu, Kaiser, and Hutchinson subdivide the transaction so that the multi-party coordinations can occur within it. As in all transactions, constraints are only applied when committed. Thus, during the transaction the effect is to remove the constraints.The power of the Split-Transaction approach is the scoping (potentially multi-level) that it provides to allow groups to cooperatively prepare a compound update for a broader community. However, within the transaction, since the constraints are not in effect, the inconsistency is not explicit, and hence cannot be tracked, managed, or supported except by informal mechanisms outside the system.But there is no reason why Split Transactions couldn't be combined with our own techniques for tolerating inconsistency to provide the advantages of both. While the inconsistency existed, it would be guarded by Pollution Markers, but it would only be visible to the group (dynamically formed) needed to resolve that inconsistency. After it was resolved, the Pollution Markers would be removed, and the new consistent state would be visible outside the group.