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.

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.

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.

Little-JIL, a language for programming coordination in processes is an executable, high-level language with a formal (yet graphical) syntax and rigorously defined operational semantics. The central abstraction in Little-JIL is the “step,” which is the focal point for coordination, providing a scoping mechanism for control, data, and exception flow and for agent and resource assignment. Steps are organized into a static hierarchy, but can have a highly dynamic execution structure including the possibility of recursion and concurrency.

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.

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.

Persistent data often has a long lifetime. During its lifetime, the types that are used to structure the data may undergo evolution to support new requirements or provide more efficient services. This evolution often makes the persistent data inaccessible unless it also evolves with the types. Existing systems that support type and data evolution focus on changes isolated to individual types, thereby limiting what can be easily accomplished during maintenance. We extend this work by presenting a model of compound type changes that can also describe changes simultaneously involving multiple types and their effects on data. We then describe TESS (Type Evolution Software System), a system to automate the evolution of types and their associated data when the types undergo compound type changes.

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 implementor's changes to the grammar of these environments.