D. Batory and B. Geraci. Validating Component Composition in Software System Generators. Proceedings of the International Conference on Software Reuse, pages 72--81, 1996.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....various approaches exist (e.g. GenVoca [11] Koala [112] there is a need for more general, languageindependent solutions. Moreover, configuration validation, for instance by modeling configuration constraints, is needed to automatically detect and prevent invalid component configurations [51, 8, 9]. Abstractions for component compositions can be domain specific and are either technical or consumer related. The group of products (or systems) that can be built from technical abstractions forms a product family [115] or system family) The group of products that can be built from ....

D. Batory and B. J. Geraci. Validating component compositions in software system generators. In M. Sitaraman, editor, Proceedings of the Fourth International Conference on Software Reuse, pages 72--81. IEEE Computer Society Press, 1996.

....computer software both are sequences of actions which perform some task. Our work on building scripts from components thus takes us close to work on software composition and reuse. In our model below we draw heavily from the inspiring work by Don Batory s software group at Univ. Texas at Austin [Batory, 1995]. 1.2 Overview To give a flavor of the script composition method described here, have a quick look ahead to Figure 8. This figure illustrates how a particular script representing a visit to a restaurant is constructed from more general components (of types acquisition , clientserver ....

....problem of script composition. We have found many of the GenVoca concepts can be applied to our task, but we have also deviated from certain aspects of this method. We summarize these similarities and differences here. Good overviews of the GenVoca method are given in [Batory and O Malley, 1992, Batory and Geraci, 1995, Batory et al. 1992] Batory et al. 1992, Batory et al. 1993] give examples of components and composition in the domain of data structures. P2 [Batory et al. 1993] and the object oriented P [Singhal and Batory, 1993] are software generators which compose software components based on the ....

[Article contains additional citation context not shown here]

Batory, D. and Geraci, B. J. (1995). Validating component compositions in software system generators. Tech Report 95-03, Dept CS, Univ. Texas at Austin, TX.

.... message dispatch, synchronization, real time constraints, atomic transactions, error detection messages sent and received metaobject protocols (e.g. Chi95] dynamic (and static) not specified local and (gobal ) static and dynamic optimizations any any GenVoca [Bat96] [BG96], BO92] static constraints, configuration rules local and global static optimizations components corresponding to any concerns parameterization Generative Programming static dynamic constraints, configuration rules local and global, static and dynamic optimizations any (a ....

D. Batory and B.J. Geraci. Validating Component Compositions in Software System Generators. In [Sit96], pp. 72-81

....compositions by stacking blocks in which the propositional properties of the components propagate up the levels of the block structure. From this perspective, design rules are implemented using attribute grammar validation that requires and constrains properties up and down the composed structure [Batory et al. 1996]. A consequence of this perspective is that design rules are specified with the following four propositional constraints. 1. Require above a legal type equation must contain the listed properties in a component declared to the left of this component in a type equation. 2. Require below a ....

....languages (DSLs) Smaragdakis et al. 1997] the results of previous DSL research imply many of the benefits realized by P3. Because of their concise, domain specific nature, DSLs can reduce maintenance costs, increase productivity, and facilitate system evolution [Batory et al. 1992, Batory at al. 1996, and Van Duersen et al. 1997] The formalization presented in this paper is intended to maximize such benefits by presenting a clear basis for the maintenance and extensibility of P3. The method by which our optimizer selects data structures draws on research in automatic programming. Balzer ....

BATORY, D., AND GERACI, B.J. Validating Component Compositions in Software System Generators, International Conference on Software Reuse, Orlando, Florida, 1996.

....compositions by stacking blocks in which the propositional properties of the components propagate up the levels of the block structure. From this perspective, design rules are implemented using attribute grammar validation that requires and constrains properties up and down the composed structure [6]. A consequence of this perspective is that design rules are specified with the following four propositional constraints. 1. Require above a legal type equation must contain the listed properties in a component declared to the left of this component in a type equation. 2. Require below a ....

D. Batory and B.J. Geraci. Validating Component Compositions in Software System Generators, International Conference on Software Reuse, Orlando, Florida, 1996.

....of research as well. Mahler in his article about Shape [13] mentions the problems of multiple variances and the problems of semantic consistency in the presence of building compositions where components share in such multiple variances, but does not address them in that paper. Batory and Geraci [3] come to grips with some of these problems in the context of their domain specific system generators, adjusting the choice of some of the components dependent on other component choices to generate a consistent domain specific system. Their mechanisms for doing this consistent generation are ....

Don Batory and Bart J. Geraci. "Validating Component Compositions in Software System Generators", Technical Report TR-95-03, Department of Computer Sciences, University of Texas at Austin, February 1995. Updated August 1995.

....of all the abstract operators in the particular database schema at hand. Symmetric layers can, thus, be composed in arbitrary ways; this provides DBIs many ways to construct optimizers using the same layers. However, not all the compositions are necessarily meaningful or correct. Batory and Geraci [8] describe methods for validating the correctness of component compositions. We will assume that compositions of our layers are always correct. We will not address the problem of validating layer compositions; we are aware these problems are present. To allow optimizer specifications using layers, ....

....is shown in Figure 6.7. It is formed by composing the SE 4 The layer ordering of Figure 6.5 is actually an example of a composition error, in that the SEQUENTIAL layer should lie above all join layers for it to be useful. Errors like this can be detected using Batory and Geraci s algorithms [8]. SEQUENTIAL JOIN(S 1 ; S 2 ) JOIN(S 2 ; S 1 ) JOIN(JOIN(S 1 ; S 2 ) S 3 ) JOIN(S 1 ; JOIN(S 2 ; S 3 ) JOIN(S 1 ; S 2 ) JOIN CONC(S 1 ; S 2 ) SORT(S 1 ) SORT CONC(S 1 ) RET(F 1 ) RET CONC(F 1 ) DISTRIBUTION JOIN(S 1 ; S 2 ) JOIN CONC(XFER(S 1 ) XFER(S 2 ) XFER(S 1 ) ....

[Article contains additional citation context not shown here]

Don Batory and Bart Geraci. Validating component compositions in software system generators. Technical Report TR 95--03, The University of Texas at Austin, 1995.

....there are a number of tools that facilitate a convenient application development, e.g. configuration editors, semantic checkers, component repositories, generators, etc. An important tool is the constraint checker. Possible approaches to checking design constraints include attribute grammars [16], temporal logic [17] and a special type of first order logic [18] 2. formal component model: The formal component model is defined through the reference architecture and lies at the heart of a DSDE. The mapping of an application architecture onto Czarnecki the underlying layer is done by a ....

D. Batory and B. Geraci, "Validating Component Compositions in Software System Generators, " in Proceedings of the ICSR 4, Orlando, pp. 72--81, 1996.

....operation composition operators of the formal specification language Object Z[31, 33] Software generation systems synthesise software systems by composing components from component libraries. Batory and O Malley[9] developed software system generators, called GenVoca generators. Batory and Geraci[8] discuss the problem of validating the generated compositions, to ensure their semantic correctness. Biggerstaff[12] expresses the importance of factoring out common library components for subsequent composition, alleviating the problem of exponential component explosion. Composition of components ....

D. Batory and B. J. Geraci. Validating Component Compositions in Software System Generators. In Sitaraman [111], pages 72--81.

....of research as well. Mahler in his article about Shape [10] mentions the problems of multiple variances and the problems of semantic consistency in the presence of building compositions where components share in such multiple variances, but does not address them in that paper. Batory and Geraci [2] come to grips with some of these problems in the context of their domain specific system generators, adjusting the choice of some of the components dependent on other component choices to generate a consistent domain specific system. Their mechanisms for doing this consistent generation are ....

Don Batory and Bart J. Geraci. Validating Component Compositions in Software System Generators. Technical Report TR-95-03, Department of Computer Sciences, University of Texas at Austin, February 1995. Updated August 1995.

....phase to the analysis and maintenance phases of development. While this article focuses on functional components, the methodology presented is compatible with any software reuse artifacts where a refinement ordering exists between specifications. This includes source code, high level components [1], software architectures [9, 26] and program transformations [4] Note also that component retrieval is not confined to library reuse; it can also be considered in the context of integrating components into generic software architectures, either statically [1] or dynamically [27] While the ....

.... source code, high level components [1] software architectures [9, 26] and program transformations [4] Note also that component retrieval is not confined to library reuse; it can also be considered in the context of integrating components into generic software architectures, either statically [1] or dynamically [27] While the potential benefits of software reuse are far reaching, in practice software reuse has not flourished. There are both managerial and technical reasons for this. One major technical barrier has been providing tools to automate the reuse process. To understand the ....

Don Batory and Bart J. Geraci. Validating component compositions in software system generators. In Murali Sitaraman, editor, Fourth International Conference on Software Reuse, pages 72--81, Orlando, Florida, April 1996. IEEE Computer Society Press.

....compatible interfaces, but the resulting algorithms are invalid for some reason. To verify the semantic correctness of a system, each component must supply domain specific information that describes the assumptions and restrictions on the use of the component. Details of this process are given in [Bat96]. sys c d g [ c d g [ c d g [ 16 complicated than functional composition; Figure 2.4 illustrates the exchanges that occur in the system . A functional interpretation of sys would have an innermost to outermost evaluation semantics; i.e. component g would be evaluated ....

Don Batory and Bart Geraci. Validating component compositions in software system generators. In International Conference on Software Reuse, 1996. 130

.... x s postcondition to top (i.e. top x = postcondition dx top) and top y is computed similarly (top y = postcondition dy top) Given the operators and , there is a straightforward, recursive algorithm for the top down propagation of postconditions and the testing of component preconditions [Bat95]. 3.2.2 Bottom Up Design Rule Checking Every parameter of a component has preconditions (called prerestrictions) for instantiation; every component also has postconditions (called postrestrictions) that are exported to higher layers in a type equation. Figure 4 depicts a typical situation: ....

....the same operators and used in top down design rule checking are used in bottom up design rule checking. Just as in the case of top down design rule checking, there is a simple, recursive algorithm for the bottom up propagation of postrestrictions and the testing of parameter prerestrictions [Bat95]. 8. Postconditions for different parameters are generally not the same. For example, the realm of a parameter can be expressed as a postcondition. If a component had two parameters and the realms for both were different, so too would be their postconditions. q r s t system rooted at r w ....

[Article contains additional citation context not shown here]

D. Batory and B.J. Geraci, "Validating Component Compositions in Software System Generators ", UT/CS TR-95-03, University of Texas at Austin, 1995.

....are simple algorithms to determine automatically if a composition of components is consistent and that it implements the specifications of a target system. While demonstrating consistency falls short of formal verification, it is an major step forward in making software system generation practical [Per89, Bat95b]. Software component technologies and generator technologies have been developed for the domains of avionics, database systems, file systems, network protocols, and data structures. Related composition encapsulation technologies in software architectures are [Gor91, Per92, Gar93] Readers who are ....

D. Batory and B.J. Geraci, "Validating Component Compositions in Software System Generators", Department of Computer Sciences, University of Texas at Austin, TR-93-03, February 1995.

....designed to be interoperable and composable with other components. The constraints on using components in type equations i.e. their compatibility or incompatibility with other components is directly encoded as composition rules (a.k.a. design rules) in the generator s domain model [Bat95]. However, recognizing composition constraints and adding these constraints to the domain model is the responsibility of domain analysts and component implementors. There is no tool support or automatic way of recognizing the compatibilities and incompatibilities of components; deep domain ....

....identical, not all components implemented operation O. This meant that components of R were not always interchangeable and that not all syntactically correct compositions of Genesis components were semantically correct. Automatic design rule checking was needed to validate compositions [Bat95]. 4. The relatively small size of GenVoca libraries is not a consequence of limited prototypes, but rather the scalability of GenVoca domain models [Bat93, Big94] 5. Components were added to realms in the order that maximally stressed realm interfaces. We discovered that once the first few ....

[Article contains additional citation context not shown here]

D. Batory and B.J. Geraci, "Validating Component Compositions in Software System Generators", ICSR 1996 (this proceedings).

....T rules and one I rule. The purpose of the layer is to either transform the JOIN operator into the Merge join algorithm, or to a concrete 3 Not all the compositions of GenVoca layers are necessarily meaningful or correct. Methods for validating the consistency of compositions are discussed in [1]. Operator Tree Prairie Layer 1 Prairie Layer n P2V Preprocessor Volcano Rules Volcano Rule Engine Access Plan (a) Schematic representation optimizer SEQUENTIAL [ MERGE [ SORT [ RET ] layer SEQUENTIAL trule JOIN(S 1 ; S 2 ) JOIN(S 2 ; S 1 ) trule JOIN(JOIN(S 1 ; S 2 ) S 3 ) ....

Don Batory and Bart Geraci. Validating component compositions in software system generators. Technical Report TR 95--03, The University of Texas at Austin, 1995.

No context found.

D. Batory and B.J. Geraci. "Validating Component Compositions in Software System Generators", International Conference on Software Reuse, Orlando, Florida, 1996.

....advantages to modeling software in this manner. One is scalability: a small number of components can define vast families of systems (i.e. distinct type equations) Big94, Bat93] Another advantage is that it is possible to reason about a software system in terms of its constituent components [Bat95]. 2.1 The Myth of Standardized Interfaces GenVoca components are composable because they export and import standardized interfaces. As we noted in Section 1, no single interface captures all views of an abstraction. What then does it mean for a GenVoca interface to be standardized How are ....

....designed to be interoperable and composable with other components. The constraints on using components in type equations i.e. their compatibility or incompatibility with other components is directly encoded as composition rules (a.k.a. design rules) in the generator s domain model [Bat95]. However, recognizing composition constraints and adding these constraints to the domain model is the responsibility of domain analysts and component implementors. There is no tool support or automatic way of recognizing the compatibilities and incompatibilities of components; deep domain ....

[Article contains additional citation context not shown here]

D. Batory and B.J. Geraci, "Validating Component Compositions in Software System Generators", Dept. Computer Sciences, TR-95-03, University of Texas at Austin, 1995.

....(called realms) of plug compatible components. A software system or program is defined as a composition of components, called a type equation. The set of all syntactically and semantically correct type equations (i.e. software systems that can be generated) is expressed as an attribute grammar [BG96] As mentioned earlier, a data language compiler is itself a generator. It translates data language statements into programs that perform the intended actions of that statement. Rosetta catalogs are realms, and operator trees (i.e. data language programs) are type equations. What distinguishes ....

D. Batory and B.J. Geraci. Validating component compositions in software system generators. In International Conference on Software Reuse, April 1996.

No context found.

D. Batory and B.J. Geraci, "Validating Component Compositions in Software System Generators", Dept. Computer Sciences, TR-95-03, University of Texas at Austin, 1995.

....too would be their postconditions. x = postcondition dx top) and top y is computed similarly (top y = postcondition dy top) Given the operators and , there is a straightforward, recursive algorithm for the top down propagation of postconditions and the testing of component preconditions [Bat95]. 4.2 Bottom Up Design Rule Checking Every parameter of a component has preconditions (called prerestrictions) for instantiation; every component also has postconditions (called postrestrictions) that are exported to higher level layers in a type equation. Figure 4 depicts a typical situation: ....

....design rule checking. Just as in the case of top down design rule checking, there is a simple, recursive algorithm for the bottom q r s t system rooted at r w Figure 4. System Instantiation of Parameters 6 up propagation of postrestrictions and the testing of parameter prerestrictions [Bat95]. 4.3 Attribute Grammars McAllester [McA94] observed that attribute grammars unify realms, components, attributes, top down and bottom up design rule checking. From previous sections, we know that realms of components define a grammar. Attributes model states of system (type equation) ....

[Article contains additional citation context not shown here]

D. Batory and B.J. Geraci, "Validating Component Compositions in Software System Generators", UT/CS TR-95-03, University of Texas at Austin, 1995.

....[Joh88] 5. One difference is that collaborations among abstract classes are defined within abstract classes in frameworks, whereas realm virtual machines do not define such collaborations. Another difference is that GenVoca components have subjective interfaces, whereas frameworks do not [Bat95b]. 6. Parameterizations that we examine in this paper are simple enough to dispense with formal parameter names. S : a b c ; T : d S e S f S ; W : n W m W p q T S ; S = a, b, c T = d[S] e[S] f[S] W = n[W] m[W] p, q[T,S] Figure 3: Realms, Components, and Grammars ....

....correct. It is common for there to be domain specific constraints in addition to realm membership that instantiating components must satisfy. These additional constraints are called design rules. Design rule checking (DRC) is the process of applying design rules to validate type equations [Per89, Bat95b]. Domain Models and MIL Compilers. A GenVoca domain model is an attribute grammar: it is a set of realms (grammar rules) and design rules (semantic actions checks) that govern component composition. In effect, a GenVoca generator is not only a transformation system, it is also a compiler for a ....

D. Batory and B.J. Geraci, "Validating Component Compositions in Software System Generators", Department of Computer Sciences, University of Texas at Austin, TR-93-03, February 1995.

.... x s postcondition to top (i.e. top x = postcondition dx top) and top y is computed similarly (top y = postcondition dy top) Given the operators and , there is a straightforward, recursive algorithm for the top down propagation of postconditions and the testing of component preconditions [Bat95]. 3.2.2 Bottom Up Design Rule Checking Every parameter of a component has prerestrictions for instantiation, and every component has postrestrictions that are exported to higher layers in a type equation. Figure 5 depicts a typical situation: components q, r, s, t, and w are composed ....

....the same operators and used in top down design rule checking are used in bottom up design rule checking. Just as in the case of top down design rule checking, there is a simple, recursive algorithm for the bottom up propagation of postrestrictions and the testing of parameter prerestrictions [Bat95]. 3.2.3 Attribute Grammars McAllester [McA94] observed that attribute grammars unify realms, components, attributes, top down and bottom up design rule checking. From previous sections, we know that realms of components define a grammar. Attributes model static properties of system (type ....

[Article contains additional citation context not shown here]

D. Batory and B.J. Geraci, "Validating Component Compositions in Software System Generators ", UT/CS TR-95-03, University of Texas at Austin, 1995.

....There is a practical benefit of unifying architectural styles with GenVoca components. It is well known that there are syntactically correct compositions of components that are semantically incorrect. Design rule checking algorithms test for composition correctness. VAGs [McA94] and the DRC model [Bat95] are different systems for accomplishing design rule checking. Analogously, we noted in [Bat93] that there may be some combinations of flavors that are not correct. If this is the case (although we do not yet have good examples of such combinations) tools used for design rule checking (DRC) ....

D. Batory and B.J. Geraci, "Validating Component Compositions in Software System Generators", ADAGE-UT-94-03. Also, Technical Report TR-95-03, Department of Computer Sciences, University of Texas at Austin, February 1995.

No context found.

D. Batory and B. Geraci. Validating Component Composition in Software System Generators. Proceedings of the International Conference on Software Reuse, pages 72--81, 1996.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC