Resultados de la entrevista

In this section, we present an illustration of architectural styles and ser- vices as a way of building new applications out of reusable components. First, we briey discussYeast, an event-action specication tool, as an example of a tool that enables an architectural style.Yeastis described in detail in Chapter 9. Next, we show how two architectural services, namely fault tolerance and visualization, have been added to Yeast. Fault tolerance is described in more detail in Chapter 8 and visualization in Section 11.2.

1.6.1 Architectural Style

Yeastruns as a daemon on a single machine on a network and accepts client specications from users. When these specications are matched, user-specied actions are triggered by Yeast. Client commands|such as, add, remove, and suspend specications|can be issued from any of several machines in the network. Yeastpermits arbitrary actions to be triggered when event patterns of interest are matched. It can match tem- poral events and nontemporal events, such as changes of attributes in objects belonging to a variety of object classes. The list of predened attributes for these object classes can be extended, as can the classes themselves. With the use of external event notications (called announce- ments), Yeast can model a wide range of applications that follow the event-action paradigm.

Yeast supports an event/condition/action architectural style, mak- ing such platforms easier to build. The application rst decides on the set of events of interest and the manner (both temporal ordering as well as combination of patterns) in which the events should be detected. Then, a collection ofYeastspecications is registered with a Yeast daemon. Several applications have been built on top of Yeast, ranging from au- tomatic coordination of database les from a network of machines to a schedule maintenance system.

Software Reuse: A Decade-Long Experiment 21

1.6.2 Architectural Services

We next look at two architectural services that dramatically improved the power and capability ofYeast. The rst is the fault tolerance service provided by a combination of a library and a watcher process. The second example is visualization support provided via a language mechanism.

1.6.2.1 Fault Tolerance

Software fault tolerance is a way to make software withstand faults that arise during execution. It is signicantly more than checking boundary conditions and several techniques have been identied. It is not enough to rollback, recover, and restart; nor is it enough to test adequately. Some faults in programs fall in the category of transient failures resulting from a particular input sequence or a set of environment conditions. The ap- proach taken in libft/watchd is to provide a platform that, with some modications to the software, provides an acceptable level of recovery from catastrophic conditions, as well as an opportunity to modify soft- ware faults when an exception happens.

The rst half of the fault tolerance technique is a library that, when linked with application programs, provides a checkpointing facility for recovering from failures. The second half is a watch daemon that aids in locating the fault. The library and the watch daemon free individual application programs from having to do their own separate fault tolerance. A signicant amount of useful code is thus reused.

Consider the example ofYeast, of which some customers require fault tolerance. Yeastclients do not know where theYeastdaemon process is running on the network. If the machine on which theYeastdaemon is running crashes, two problems arise: The existing set of specications is no longer being matched, and new client commands cannot communicate with a Yeast daemon. Ad hoc solutions, while reasonable, require a signicant amount of code to be added to Yeast, none of which deals with event-action matching|the stated purpose of the application.

The libft/watchd technique is suited for a distributed environment. The list of data structures signicant to Yeastis isolated in a section of

22 Belanger and Krishnamurthy

Yeastcode and theYeastdaemon process is registered with watchd.

This requires minimal modications to Yeast. Upon a machine crash, the shadow process restarts aYeastdaemon on another machine on the network with the most recent value of the signicant data structures. This enables continued matching of the existing specications with no loss of state. Additionally, new client connections are automatically routed to the new daemon process, thus making the machine crash transparent to the users on the network.

1.6.2.2 Visualization

Visualization is often a key component of interfaces and application front ends. Visualization can be static or dynamic, depending on the applica- tion needs. For example, graph layouts are often a useful way to present visual information, especially when dealing with software entities. A ex- ible way to provide this is to use a graph description language consisting of nodes and edges at a simple level, and attributes (such as color) and abstractions (such as clusters, groupings) at a higher level. The choice for a visual representation language is driven by simplicity that minimizes the time spent in learning an additional language.

Unlike libft/watchd, where a library is used, a language is used here to describe the service. A graph drawing program should be able to parse a graph description language and construct a picture quickly. dot [GKNV93] is a tool that reads and writes graphs in an attributed graph description language. By combining dot with lefty [KD91] (a pro- grammable graphics editor), dotty was created. dotty can be used as a standalone tool or as a front end for applications that use graphs. In dotty, the lefty program implements the insertion and deletion of nodes and edges, the drawing of the picture, and functions that map user actions to operations on the picture. dotty can thus read dot input and create a dynamic front end that can be controlled through simple commands. dot, lefty, and dotty are all described in Section 11.2. Section 9.6.2.2 describes the visualization ofYeast specications in more detail.

The graphical front end forYeasttook a couple of hours to build and

In the most recent version of

libft with global checkpointing, the need for even this modest step has been obviated.

Software Reuse: A Decade-Long Experiment 23

needed an addition of about 50 lines of code to Yeast. This technique has since been replicated for other tools in the department|a recent example is for a software process visualization environment, Provence (see Chapter 10).

We have examined how one tool (Yeast) has taken advantage of the architectural services that are available separately from the basic tools that they serve. Other examples can be found in this book.

1.7 Summary

Our experience shows that there is considerable value in a reasonably comprehensive set of reusable items of mixed levels (component, service, style, platform) when supported by strong marketing and distribution capabilities. The set can be put together in a variety of ways. A reuse factor greater than ve has been achieved locally using libraries (with a real reuse factor of 2 to 2.5 when the actual percentage usage of library functions is considered). The real impact is much greater than that if the use of architectural roles and levels is considered, but we do not yet have accurate measures of that eect.

The book follows the four-level structure described in Section 1.5. The software entities in the substrate and base levels concentrate on the princi- ples on which they were built and the reusability they oer to the higher- level tools. The standalone tools chapters begin with a description of the tool, describe their architecture, and highlight the lower-level com- ponents reused by them. They also point toward how they were used as components to the tools in the later chapters. The chapters dealing with connected tools discuss the reuse of the standalone tools at the component level and show how they were assembled eciently.