Policy-directed Coordination And Cooperation
Dewayne E. Perry · 2005
and Modeling such a process requires design decisions about the granularity of the ,process activities, about the degree of prescription defined within those activities, and about the policies that govern the triggering and termination of the activities and that define the nature of interaction and communication among the programmers evolving the system. Whatever choices are made for these issues, the resulting process is of necessity one with concurrent, independent, and asynchronous activities - that is, there will be multiple and different activities acting on the multiple and different states of the product. The critical issue is that of coordinating and synchronizing these independent activities. The general goals in Interact and Intermediate are to support goal-directed process modeling in such a way to maximize concurrency of activities and to minimize control of the human element in the process. To do this, I have separated the model specification from the enaction - that is, I have separated the modeling from the support and and in doing so have separated the (mostly) static aspects of process modeling from the (mostly) dynamic aspects of model enactment. Interact provides facilities for defining objects, policies, and activities: object definitions are used to model both the product and the project; policies definitions are used to model various facts and relationships about both the product and the project as well as to define synchronization (or interaction) abstractions; activity definitions are used to model the process activities that transform the product and project from one state to another. Activities are defined in terms of the activating policies, the defined goals and resulting obligations. Where desired, the process designer may bind the user to a particular implementation of the activity by supplying some structure to what is normally considered a primitive entity. Object declarations include type definitions, type instances, and object delinitions. Types and type instances enable the process designer to define the appropriate abstractions that are necessary for the model and to define the values for those abstractions. Objects have types and may assume the values defined for those types, For example, the model of software artifact serves as the coordinating object for the various activities that transform the product from one state to another; the model of the project defines the objects by which non-product related communications take place. Of paramount importance, however, are the policy definitions. They define the relationships among objects in several ways. First, policies may be primitive. These serve as base abstraclions which are asserted as results of activities. Second, policies may encapsulate logical expressions that relate (in various ways) base