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.

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.

Computer usage has evolved from small special purpose applications to large Commercial Off The Shelf Software (COTS) products that dominate the landscape. These COTS products present major challenges for our traditional software assistance paradigm. This talk will explore those challenges and suggest research opportunities for software assistance in extending COTS products, in integrating them with other components, and in using them.

Summary form only given, as follows. We're surrounded by inconsistency: in our requirements, in the data that our software processes, and in those software systems themselves. Yet our formal systems can’t handle such inconsistency. Most of them lose the ability to form any valid conclusions or analyses in the presence of even a single inconsistency. This forces our programs to operate in terms of an idealized model rather than the real world with the attendant requirement to either maintain a mapping between the two or force human operators to resolve the inconsistencies before the data is processed by the idealized system. My "Tolerating Inconsistency" paper introduced a simple way to scope formal constraint systems so that they applied only to the consistent data. Data inconsistent with these rules could then be represented and processed by giving them special marks to place them outside the rules’ scope. My talk will review the influence this idea had on the field and my subsequent work.

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.

As more and more programming environments incorporate explicit process descriptions, generic process capabilities will become crucial to the convenient instantiation and maintenance of process description. However, partly because process modeling languages have followed the example of programming languages in general, they are surprisingly weak in supporting generic process descriptions.We propose mechanisms whereby generic process capability can be added to any process formalism. The generic portions of the process description can then be refined through instantiation. We define a system architecture in which a generic process description can be refined gradually during its enactment. Such capabilities will be crucial to incorporating explicit process descriptions into the program environments of the future.

Article Free Access Share on The OO software development process (panel) Authors: Dennis de Champeaux View Profile , Bob Balzer View Profile , Dave Bulman View Profile , Kathleen Culver-Lozo View Profile , Ivar Jacobson View Profile , Stephen J. Mellor View Profile Authors Info & Claims OOPSLA '92: Conference proceedings on Object-oriented programming systems, languages, and applicationsOctober 1992Pages 484–489https://doi.org/10.1145/141936.141974Published:31 October 1992Publication History 0citation383DownloadsMetricsTotal Citations0Total Downloads383Last 12 Months9Last 6 weeks0 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteeReaderPDF

No abstract available.

Automatic programming consists not only of an automatic compiler, but also some means of acquiring the high-level specification to be compiled, some means of determining that it is the intended specification, and some (interactive) means of translating this high-level specification into a lower-level one which can be automatically compiled.

We are deeply indebted to the members of ISI Software Division who developed the basic technology and approach for our effort. We especially wish to acknowledge the contributions of our colleagues, Dave Dyer and Matt Morgenstern, to the conceptualization and design of the system.

A system for mechanically transforming formal program specifications into efficient implementations under interactive user control is described and illustrated through a detailed example. The potential benefits and problems of this approach to software implementation are discussed.

This paper is concerned with the need for computer-based tools which help human designers formulate formal process-oriented specifications. It first determines some attributes of a suitable process-oriented specification language, then examines the reasons why specifications would still be difficult to write in such a language in the absence of formulation tools. The key to overcoming these difficulties seems to be the careful introduction of informality based on partial, rather than complete, descriptions and the use of a computer-based tool that uses context extensively to complete these descnrptions during the process of constructing a well-formed specification. Some results obtained by a running prototype of such a computer-based tool on a few informal example specifications are presented and, finaliy, some of the techniques used by this prototype system are discussed.