Balachander Krishnamurthy

Yeast: a general purpose event-action system

Distributed networks of personal workstations are becoming the dominant computing environment for software development organizations. Many cooperative activities that are carried out in such environments are particularly well suited for automated support. Taking the point of view that such activities are modeled most naturally as the occurrence of events requiring actions to be performed, we developed a system called Yeast (Yet another Event Action Specification Tool). Yeast is a client server system in which distributed clients register event action specifications with a centralized server, which performs event detection and specification management. Each specification submitted by a client defines a pattern of events that is of interest to the clients application plus an action that is to be executed in response to an occurrence of the event pattern; the server triggers the action of a specification once it has detected an occurrence of the associated event pattern. Yeast provides a global space of events that is visible to and shared by all users. In particular, events generated by one user can trigger specifications registered by another user. Higher level applications are built as collections of Yeast specifications. We use Yeast on a daily basis for a variety of applications, from deadline notification to software process automation. The paper presents an in depth description of Yeast and an example application of Yeast, in which Yeast specifications are used to automate a software distribution process involving several interdependent software tools. >

Proxy cache coherency and replacement-towards a more complete picture

This work studies the interaction of Web proxy cache coherency and replacement policies using trace-driven simulations. We specifically examine the relative importance of each type of policy in affecting the overall costs, the potential of incorporating coherency issues in cache replacement and the inclusion of additional factors such as frequency of resource use in replacement and coherency policies. The results show that the cache replacement policy in use is the primary cost determinant for relatively small caches, while the cache coherency policy is the determinant for larger caches. Incorporating cache coherency issues in cache replacement policies yields little improvement in overall performance. The use of access frequency in cache replacement, along with temporal locality and size information, results in a simple and better performing policy than found in previously published work. Combining this new replacement policy with the best piggyback-based cache coherency policy results in a 4.5% decrease in costs and 89% reduction in staleness ratio when compared to policy combinations in current use. Preliminary work indicates that cache replacement and coherency policies continue to affect costs in the presence of HTTP protocol enhancements such as persistent connections.

Provence: A Process Visualisation and Enactment Environment

A process-centered software development environment must be open and as non-intrusive as possible. Openness is important because the nature of software process work is experimental, making it difficult to determine the forms of assistance that are needed. An extensible architecture that can incorporate new tools is more appropriate than one that fixes its components and functionality. Providing process support in a non-intrusive manner relieves organizations adopting process technology from having to change their working environment significantly. We present Provence, an architecture that inculcates these criteria and realizes them by integrating existing software components. Supporting cooperation is equally important, but we do not address this issue yet. Provence monitors developers activities, maps them to process steps, and maintains process and product data. Further, it provides a dynamic visual representation of changes to process and data throughout the lifetime of a project.

Using event contexts and matching constraints to monitor software processes

Automated monitoring of events that occur in a computer network is essential for non-intrusive software process enactment. Relevant events include modification of product artifacts like source files and documents, and execution and termination of tool invocations. Monitoring these events requires capturing the context in which they occur and constraining the monitoring to relevant events only. We introduce the concept of event context, and present constructs for using it to constrain event matching. The constructs have been implemented as an extension to an existing event monitoring system called Yeast, which serves as the event monitoring component in Provence. Provence is an open process-centered environment that monitors the actual execution of software processes, abstracted as sequences of low-level events, and maps these sequences of events into transitions in the process model enactment.

An event-based model of software configuration management

These actions require cooperation among several people to carry out a process that can become chaotic if not properly controlled. Recognizing that activities such as these are particularly well suited to automation, we have developed a tool called Yeast (Yet another Event-Action Specification Tool) that implements an event-based model of cooperative software development. Yeast is a client-server system in which clients submit and manipulate event-action specifications and a server performs specification matching and management. Higher-level applications are built as collections of Yeast specifications. In this paper we describe an application in which Yeast specifications are being used to automate the software configuration management chores of a project management system. A Yeast specification consists of an event pattern along with an action; the Yeast server submits the action to the underlying system’s command interpreter whenever it detects an occurrence of the event pattern. The action part of a specification can perform any number of actions in response to the occurrence of the event pattern, including Yeast-related actions. An event is simdv a charwe in the .vduc of an attribute of some object. Each object Le10n6. to an object class, and each attribute of an object class has a type. The Yeast server automatically recognizes the occurrence of many predefine events, such as the passage of

An Objective Reuse Metric: Model and Methology

Software reuse is an effective way to gain productivity in constructing software systems. In order to continuously monitor the progress of reuse in the context of a project, we need an objective and repeatable way to measure the extent of reuse. This paper proposes a model and methodology to automatically compute a general objective reuse measure from the source code of applications and reusable software repositories. Unlike consumer-oriented reuse measures in the literature, this measure is useful from the viewpoints of both reuse consumers and reuse producers. The former can use it to estimate the extent of reuse in their applications while the latter can use it to determine the impact of certain reusable components. In contrast to other objective code-based measures, our measure is both complete and precise in that it is calculated based on and only on those code entities that are essential to the functioning of an application. While the model and methodology are largely language-independent, we have implemented tools to compute the reuse measure from C code. We report experiences from using the measure on a few large software systems and discuss its use in discovering and encouraging reuse.

CSCW 94 Workshop to Explore Relationships between Research in Computer Supported Cooperative Work & Software Process: Workshop Report

For several years, much research has been done independently in both Computer Supported Cooperative Work (CSCW) and Software Process (SP), with no more than an occasional acknowledgment to work done in the other area. This workshop, held on October 24th, in conjunction with the CSCW conference in Raleigh, North Carolina, brought together the believers and skeptics in these two research areas with the broad goal of exploring their interrelationships in more detail. Because software development is naturally collaborative for any significant system, exploration of the link between these two research areas is quite natural and long overdue. SP is now accepted as one of the critical areas of study in software engineering. It is very important for researchers in SP to learn both positive and negative lessons from the results in closely related fields such as CSCW. More specifically, the goals of the workshop were as follows: • Determine where the research problems or approaches of the two areas overlap, and where there is divergence. • Clarify what CSCW researchers can learn from SP and what SP researchers can learn from CSCW. • Examine the experiences and lessons learned from relatively new projects which straddle the two areas. To get the ball rolling, and to get past inevitable and unproductive terminological warfare, the workshop started with a couple of short tutorials on both SP and CSCW. The set of concerns that have preoccupied researchers in each of these areas were delineated, along with major achievements and open problems. This session provided the researchers from each side with a common framework of understanding of the concerns and approaches of the other, setting the table for a productive day-long discussion. It became clear that while SP research has examined cooperation problems in a particular domain, it has delved into these issues in considerable depth. The characteristics of SP research that set it apart from the extant body of CSCW research are as follows: • There is an underlying assumption in SP that the process can be made explicit and formalized, and that this is a good thing to do. • SP researchers have made considerable progress in the modeling of large-grain, asynchronous activity; and in the mechanisms necessary to enforce the integrity of the process and the product being developed. • While not all the problems have been solved, the area of SP aims to examine all the issues (human factors, guidance …

Architecture styles and services: An experiment involving the signal operations platforms-provisioning operations system

The process of designing vertically integrated applications is enhanced if the distinct architectures, or architecture styles, and relevant performance constraints and interactions can first be identified. Applications, although running in varied environments, also may require specific architecture services, non-operational features such as portability or fault-tolerance that might be common across several architectural styles. The application design process should be an iterative exercise of first understanding system requirements and then determining how they may be partitioned according to styles and services. An integral part of this process is to identify software components and subsystems that must be developed or can be reused from other systems. This paper describes a design-partitioning process applied to the new Signal Operations Platforms-Provisioning (SOP-P) operations system. The experiment shows that it is feasible to identify large design components confined within a few architecture styles that are common to network management and operations software.

Practical software reuse: an interim report

Reuse in software has been discussed at length in the community with a variety of techniques and varying rates of success. We take a slightly longer range view and present an eight year experience report. The software discussed in this paper include some well known tools with a very large user base both inside and outside our company. The assumptions under which work was done here were: users could choose between our work and the free market, reused items will have dynamic life cycles, and a consistent and stable system architecture was vital. A lesson learnt was that a configuration and distribution process oriented to software product control and delivery provides, with some augmentation, an effective base for reuse support. Having a process-oriented software base constantly enhanced with customer feedback has promoted a high degree of reuse of our software.<<ETX>>

Software architecture and reuse-an inherent conflict?

Summary form only. Software architecture is loosely defined as the packaging of functions and objects, together with their interface, and control to implement applications in a domain. An accepted model of software reuse consists of taking a library of reusable assets, instituting a reuse process that permits augmentation of the assets in a supportive environment and providing deliverables via a streamlined development process. Classification of reusable libraries aids in packaging of objects/functions. Given the proper consideration at an earlier (architectural) level it is possible to attain large scale reuse. Without well understood constraints there is little possibility of a high degree of reuse. Role separation and constraints provide the needed stability for reuse. One way to view architecture is as a collection of architectural styles and services. An architectural style helps in arranging the components. The services support the non-functional requirements of the architectural styles. Thus to increase reuse the key is to identify a set of styles and services and combine them appropriately. Besides code, other reusable entities include scripts, documents, design, experience, specification, and application system. Reusability of specification often leads to reusable software components. Architectural constraints may dictate what components may be reused and availability of reused entities may enhance the stability of the architecture.<<ETX>>