Barbara Staudt Lerner

Beyond schema evolution to database reorganization

While the contents of databases can be easily changed, their organization is typically extremely rigid. Some databases relax the rigidity of database organization somewhat by supporting simple changes to individual schemas. As described in this paper, OTGen supports not only more complex schema changes, but also database reorganization. A database administrator uses a declarative notation to describe mappings between objects created with old versions of schemas and their corresponding representations using new versions. OTGen generates a transformer that applies the mappings to update the database to the new definitions, thus facilitating improvements in performance, functionality, and usability of the database.1

A model for compound type changes encountered in schema evolution

Schema evolution is a problem that is faced by long-lived data. When a schema changes, existing persistent data can become inaccessible unless the database system provides mechanisms to access data created with previous versions of the schema. Most existing systems that support schema evolution focus on changes local to individual types within the schema, thereby limiting the changes that the database maintainer can perform. We have developed a model of type changes involving multiple types. The model describes both type changes and their impact on data by defining derivation rules to initialize new data based on the existing data. The derivation rules can describe local and nonlocal changes to types to capture the intent of a large class of type change operations. We have built a system called Tess (Type Evolution Software System) that uses this model to recognize type changes by comparing schemas and then produces a transformer that can update data in a database to correspond to a newer version of the schema.

Using Little-JIL to coordinate agents in software engineering

Little-JIL, a new language for programming the coordination of agents, is an executable, high-level process programming language with a formal (yet graphical) syntax and rigorously defined operational semantics. Little-JIL is based on two main hypotheses. The first is that the specification of coordination control structures is separable from other process programming language issues. Little-JIL provides a rich set of control structures while relying on separate systems for support in areas such as resource, artifact and agenda management. The second hypothesis is that processes can be executed by agents who know how to perform their tasks but can benefit from coordination support. Accordingly, each step in Little-JIl is assigned to an execution agent (human or automated). These agents are responsible for initiating steps and performing the work associated with them. This approach has so far proven effective in allowing us to clearly and concisely express the agent coordination aspects of a wide variety of software, workflow and other processes.

Exception Handling Patterns for Process Modeling

Process modeling allows for analysis and improvement of processes that coordinate multiple people and tools working together to carry out a task. Process modeling typically focuses on the normative process, that is, how the collaboration transpires when everything goes as desired. Unfortunately, real-world processes rarely proceed that smoothly. A more complete analysis of a process requires that the process model also include details about what to do when exceptional situations arise. We have found that, in many cases, there are abstract patterns that capture the relationship between exception handling tasks and the normative process. Just as object-oriented design patterns facilitate the development, documentation, and maintenance of object-oriented programs, we believe that process patterns can facilitate the development, documentation, and maintenance of process models. In this paper, we focus on the exception handling patterns that we have observed over many years of process modeling. We describe these patterns using three process modeling notations: UML 2.0 Activity Diagrams, BPMN, and Little-JIL. We present both the abstract structure of the pattern as well as examples of the pattern in use. We also provide some preliminary statistical survey data to support the claim that these patterns are found commonly in actual use and discuss the relative merits of the three notations with respect to their ability to represent these patterns.

Containment units: a hierarchically composable architecture for adaptive systems

Software is increasingly expected to run in a variety of environments. The environments themselves are often dynamically changing when using mobile computers or embedded systems, for example. Network bandwidth, available power, or other physical conditions may change, necessitating the use of alternative algorithms within the software, and changing resource mixes to support the software. We present Containment Units as a software architecture useful for recognizing environmental changes and dynamically reconfiguring software and resource allocations to adapt to those changes. We present examples of Containment Units used within robotics along with the results of actual executions, and the application of static analysis to obtain assurances that those Containment Units can be expected to demonstrate the robustness for which they were designed.

Modeling Resources for Activity Coordination and Scheduling

Precise specification of resources is important in activity and agent coordination. As the scarcity or abundance of resources can make a considerable difference in how to best coordinate the tasks and actions. That being the case, we propose the use of a resource model. We observe that past work on resource modeling does not meet our needs, as the models tend to be either too informal (as in management resource modeling) to support definitive analysis, or too narrow in scope (as in the case of operating system resource modeling) to support specification of the diverse tasks we have in mind. In this paper we introduce a general approach and some key concepts in a resource modeling and management system that we have developed. We also describe two experiences we have had in applying our resource system. In one case we have added resource specifications to a process program. In another case we used resource specifications to augment a multiagent scheduling system. In both cases, the result was far greater clarity and precision in the process and agent coordination specifications, and validation of the effectiveness of our resource modeling and management approaches.

TransformGen: automating the maintenance of structure-oriented environments

A serious problem for programs that use persistent data is that information created and maintained by the program becomes invalid if the persistent types used in the program are modified in a new release. Unfortunately, there has been little systematic treatment of the problem; current approaches are manual, ad hoc, and time consuming both for programmers and users. In this article we present a new approach. Focusing on the special case of managing abstract syntax trees in structure-oriented environments, we show how automatic transformers can be generated in terms of an implementors changes to the grammar of these environments.

Programming Process Coordination in Little-JIL

Process programming languages have not been readily adopted by practitioners. We are addressing this problem through the development of Little-JIL, a language that focuses on the coordination aspects of processes and provides a visual representation, yet one that is rigorous enough for execution and formal reasoning. We have used Little-JIL to program several software engineering processes, knowledge discovery processes, and are working on processes to coordinate robot teams. We believe the simplicity gained by focusing on coordination and visualization should make Little-JIL both readily adoptable and widely useful.

Verifying process models built using parameterized state machines

Software process and work flow languages are increasingly used to define loosely-coupled systems of systems. These languages focus on coordination issues such as data flow and control flow among the subsystems and exception handling activities. The resulting systems are often highly concurrent with activities distributed over many computers. Adequately testing these systems is not feasible due to their size, concurrency, and distributed implementation. Furthermore, the concurrent nature of their activities makes it likely that errors related to the order in which activities are interleaved will go undetected during testing. As a result, verification using static analysis seems necessary to increase confidence in the correctness of these systems. In this paper, we describe our experiences applying LTSA to the analysis of software processes written in Little-JIL. A key aspect to the approach taken in this analysis is that the model that is analyzed consists of a reusable portion that defines language semantics and a process-specific portion that uses parameterization and composition of pieces of the reusable portion to capture the semantics of a Little-JIL process. While the reusable portion was constructed by hand, the parameterization and composition required to model a process is automated. Furthermore, the reusable portion of the model encodes the state machines used in the implementation of the Little-JIL interpreter. As a result, analysis is based not just on the intended semantics of the Little-JIL constructs but on their actual execution semantics. This paper describes how Little-JIL processes are translated into models and reports on analysis results, which have uncovered seven errors in the Little-JIL interpreter that were previously unknown as well as an error in a software process that had previously been analyzed with a different approach without finding the error.

Exception handling patterns for processes

Using exception handling patterns in process models can raise the abstraction level of the models, facilitating both their writing and understanding. In this paper, we identify several useful, general-purpose exception handling patterns and demonstrate their applicability in business process and software development models.