Integrating multiple specifications using domain goals

Abstract

Design is a process which inherently involves tradeoffs. We are currently pursuing a model of specification design which advocates the integration of multiple perspectives of a system. We have mapped the integration problem onto the negotiation problem of many issues between many agents in order to apply known resolution techniques. Part of that mapping requires the modeling of domain goals which serve as issues for negotiation. Herein, we describe the use of domain goals in our conflict resolution process which is applied during the integration of specifications. Consider the problem of integrating two databases which (I) have constraints governing their form, (2 1’ represent rich semantic entities, and 3) are the resu t of a large design effort-possibly con 6 ucted by multiple agents. Problems arise immediately: how does one determine (1) the correspondence between database entities, (2) the identification of conflicts, and (3) the resolution of those conflicts? Each of these problems in turn consists of subproblems: determining correspondences is a labeling P roblem that involves as ects of graph isomorphism lo] and concept learning 41; identification of conflicts requires P a theory of goa s and plans[29]; finally, a theory of compromise and negotiation IS necessary for the resolution of conflicts[22]. Instances of this integration problem may be found in the merging of database versions, program versions[l4], software designs[l2], and the area we are exploring-specification designs[25]. In this paper we will consider a model which uses the general notion of plan integration as part of its specification Permission to copy without fee all or part of this ma terial is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permis sion of the Association for Computing Machinery. To copy otherwise, or to republish, requries a fee and/or specific permission. integration knowledge. Viewed as an integration element of rich semantic entities (i.e., plans consist operators b , organized in a particular partial order, generated y a complex problem solving process. Commonly, the planning process involves the maintenance of a goal tree which records the derivation of subgoals and plan operators from the root goals of a plan. Our extended goal tree, termed the development record, plays a significant role in the characterization and resolution of integration interactions. In section 3, we describe the model around which we are constructing a computer-based system which automates integration via the maintenance and analysis of the development record. Section 4 traces the integration algorithm as two types of integrations are carried out. As a precursor, we describe the methodology by which we construct parallel designs and allow for their subsequent integration. Functional decomposition is a methodology in which software components can be independently designed under the constraints of common interfaces. Recognizing the benefits of such a methodology, Feather melded this approach with that of the transformational implementation paradigm[l] with the added twist that interface constraints need not be consistent across development lines[8 . I Such an approach benefits from incremental deve opment, i.e., (1) ease of understanding via a record of gradual refinement, (2) automation of specification editing operators, (3) reuse of (intermediate) specifications rather than code, and (4) maintenance of the specification by altering elaborations and then “repla ing” them to a create a new specification (cf. !?i!;2(t!)d t 2 It also benefits from parallel development, re UC ion lines o in the number of concerns along development, and (2) explicit consideration of compromises during the integration of independently developed specification components. We are are currently formalizing Feather’s model to allow for automation. Consider figure 1 as we describe our version of the Parallel Elaboration of Specifications (PES) methodology. At the top of the