Dynamic Instantiation-Checking Components

Transcription

1 Dynamic Instantiation-Checking Components Nigamanth Sridhar Electrical and Computer Engineering Cleveland State University 318 Stilwell Hall, 2121 Euclid Ave Cleveland OH ABSTRACT Parameterization is an effective technique for building flexible, reusable software. When dealing with parameterized components, an important concern is the time at which parameters are bound. Many languages provide syntactic support for parameterized components; this mode of parameterization can be called static parameterization. In order to be able to support dynamic reconfiguration, the Service Facility pattern has been proposed as an enabling technology for dynamic parameterization. However, static parameterization has the advantage of strong type-checking that dynamic parameterization does not. In this paper, we present DynInstaCheck a tool that automatically instruments dynamically bound parameterized components with run-time checking code that ensures type-safe parameter binding. The source instrumentation is done in a non-intrusive way, using aspect-oriented programming. 1. INTRODUCTION Traditionally, parameterization has been used as a technique for building generic data types, especially popular in the domain of data collections, such as stacks, queues, lists, etc. This view has been further popularized by template class libraries such as the C++ Standard Template Library (STL) [8]. The recent proposals for generics in Java [1] and the.net common language runtime [6] also endorse this view of parameterized components. The essential idea with generic data collection components is that the component designer simply designs the collection while leaving some parts of the component (generally, the kind of items in the collection) unspecified. Later, when a client program wants to use such a generic component, it instantiates 1 the template by filling in the incomplete 1 We use the word instantiation to mean the setting of all parameters of a template. We refer to what is often called instantiation in the OO literature creation of a new object of a given class as object creation in order to avoid confusion. parts of the component definition, thereby resulting in a complete definition for the component. Several languages provide syntactic constructs for building parameterized components. For example, in the case of C++ templates (as with Ada generics, and similar languagesupplied parameterized programming support constructs), integration is done at compile time. So actual template parameters are bound to the formals at compile time. We call this mode of parameterization static parameterization, since the binding of parameters to a template remains static for its lifetime. Each such instantiated template defines a new type that joins the existing types of the program. At the time of instantiating a template, the client program defines a new type. This new type is added to the set of types for this compilation unit. From now on, all variables declared of this type are governed by the strong typing rules of the language. Further, before a template can be used, it must be instantiated. Without the instantiation step, a program that tries to use a template will not compile. The compiler, when it starts checking a particular program, expects all the templates that the program uses to be properly instantiated with actual parameters. While static parameterization offers a way for component designers to delay the decision of which particular actual parameters to bind to each formal template parameter, the decision cannot be postponed beyond compile time. Once the binding has been done, and the client program has been compiled into object code, no changes are possible to the binding without recompiling the client program. In some situations, however, the decision of which parameter to bind to a particular template is not apparent until run time. Further, such decisions may have to be changed during execution of the system. With statically-bound templates, such delay in commitment [12] is impossible. What we need in such cases is to be able to postpone the binding of parameters until run time. We call this mode of parameterization dynamic parameterization. The Service Facility pattern [9] is one approach to building components that support dynamic parameterization. However, this mode of parameterization brings along with it an important problem that of type-checking parameters. In the case of static parameterization, the compiler does the job of enforcing type restrictions at the time of binding. This is not possible in the case of dynamic parameterization. Since the parameters are only bound at run-time, we need some form of run-time checking to enforce type restrictions. This is the main contribution of

2 this paper. We present a tool that can automatically instrument dynamically-bound parameterized components to include these run-time checks before deployment. The tool, named DynInstaCheck, examines a given Serf component and its parameters, and generates an instantiationchecking component. The output of the tool is AspectJ code that enforces parameter binding rules. Aspect-oriented programming enables us to modularize these parameter binding rules into their own concern, without affecting the application code. The rest of the paper is organized as follows. In Section 2, we outline the type restrictions that need to be satisfied when binding parameters, and how compiler support helps in enforcing these restrictions. Section 3 presents the approach to enforcing these type restrictions in the case of dynamic parameterization. In Section 4, we present DynInstaCheck: a tool that automatically instruments components to perform the dynamic type-checking of parameters. After presenting some related work in Section 5, we conclude with a summary of our contributions and some directions for future work in Section TYPE-SAFE PARAMETERIZATION When using static parameterization, the compiler ensures that the template bindings are all legitimate from the point of view of type-correctness of parameter bindings. Before certifying a particular template as valid, a template-aware compiler performs the following checks: R1. Enforcing Instantiation. Before it is used in a client program, a template must be fully instantiated all parameters to the template must have been supplied, R2. Enforcing Restrictions. The actual template parameters result in type-correct bodies for the template s methods, and R3. Enforcing Stability of Parameters. Once parameters have been bound to a template, the bindings remain as is throughout the lifetime of the program. R1. Enforcing Instantiation. A template class cannot be used to declare and create objects before all of its formal template parameters have been bound to actuals. In a sense, the type that the template class defines is incomplete before the parameters are bound. The compiler therefore does not allow the declaration of objects of a template class before it is fully instantiated. R2. Enforcing Restrictions. Consider the code snippet of a Java generic class Sorter presented in Listing 1. When the Sorter generic is instantiated with PayrollRec, the compiler checks to see if the comparison operation (line 5) is supported by PayrollRec. If the comparison operation is not supported, the compiler will throw an error, and the binding will not be completed. R3. Enforcing Stability of Parameters. Since the static binding of parameters defines a new static type for the program, the parameters stay bound for the lifetime of the program. Listing 1: Sorter Generic Class written in Java 1 public class Sorter<Item> { 2 /*... */ 3 public void sort() { 4 /*... */ 5 if (x > y) // x and y are of type Item 6 /*... */ 7 } 8 } public class PayrollRec { /*... */ } Sorter<PayrollRec> payrollrecsorter; 3. DYNAMIC PARAMETERIZATION The Strategy design pattern [3] provides a way for building dynamically-bound parameterized components. The template component plays the role of Context and the parameters to the template are supplied as Strategies to the Context object. This way, the template object can be written to depend on the interfaces of the parameters (AbstractStrategies), and can be fully specialized after deployment, when the choice of parameters is clear. This is the approach taken by the Service Facility pattern [11], which is a composition of design patterns that enables the construction of dynamically-bound parameterized software components. The pattern composition differentiates between two kinds of objects Service Facility objects (Serfs for short), and Data objects. Serf objects create data objects (such as in Abstract Factory) and act as proxies for these data objects (Proxy pattern). The power of the parameterization mechanism in the Serf approach is similar to the power of C++ templates. The main difference is the binding time. Before a Serf can be used to create and operate on objects, all of its parameters have to be set. In order to do this, each Serf class has methods of the form setparameter corresponding to each parameter (named Parameter). Since the Serf approach binds parameters to templates at run-time, it also supports rebinding of parameters in the event that any of the decisions change. However, the pattern itself does not include support for type-checking parameter bindings. In the remainder of this section, we will describe the proof obligations that are needed to ensure correct dynamic parameter bindings in Serfs. Before doing that, however, we take a short detour to convince the reader that compiler checks are not sufficient to enforce the above requirements when dealing with dynamic binding. Since Serfs are really just objects at the linguistic level, as soon as the constructor has been invoked by the client and an object has been allocated, the Java/C# compiler considers the Serf object ready for use. However, under the semantics of the Serf design pattern, this Serf may not be ready for use yet. The reason is that there may be template parameters that need to be supplied to the Serf. So until these parameters have been set, the client should not be allowed to invoke any methods on the Serf, including create(). Since the template parameters are really just data members of a run-time object, the compiler currently does not check for these properties being set. One could instrument the compiler to perform additional static analysis to ensure that every path leading to a method call on the Serf

3 already has lines of code that set the template parameters. This would require that we had special syntax to distinguish data members that represent template parameter from regular data members. However, we would like to be able to perform these checks without making changes to the language or the compiler, so that the solution is immediately deployable. R1. Enforcing Instantiation. Before the Serf can be used to create data objects, the Serf must be properly instantiated, i.e., all the template parameters must be bound. For each template parameter, the data member that corresponds to that parameter must have been set to a value other than its initial value. In this case, we will just use the initial value conventions of Java for example, Object type variables are initialized to be null. In order to make sure that by the time a Serf is used, it is properly instantiated, there needs to be a check performed at the beginning of each method (including the create() method) to make sure that all the parameters have actually been set. So clients that want to use a Serf object have to first instantiate it by supplying appropriate actual parameters. If the Serf is not fully instantiated, an exception will be thrown. R2. Enforcing Restrictions. In the foregoing discussion, we have presented one way of making sure that a Serf object is actually instantiated before it is used. However, how do we make sure that the parameters that have been supplied are appropriate from the type-correctness standpoint? The solution we use is to embed the restrictions on parameters in the specification of the component. Each of the parameters to the Serf may be annotated with restrictions. As an example, consider a component StackExternalSorter that is designed to sort stacks on disk. So a requirement is that any items in a stack that this component is used to sort must support a comparison operation, and the items must be serializable. The specification of this ItemSerf parameter will therefore include an annotation that items must implement the ISerializable and IComparable interfaces. These checks are performed at run-time, and if they are not met, an exception is raised, and the program halts. R3. Enforcing Stability of Parameters. This check ensures that the component satisfies the requirement that once a parameter has been set, it cannot be unset, or changed. This condition can be enforced by requiring that the setparameter method for any Parameter can only be invoked once. We do this by including another clause in the pre-condition of every setparameter method to check if the Parameter is null. 3.1 Discussion Let us briefly examine the value of these exceptions raised. After all, if there were none of these checks, the program would raise an exception anyway at some point. How then is our approach any more valuable than the default case? The primary difference is when the exception is raised. By checking and enforcing these rules early enough in the execution of the program, the exceptions that we raise from our instantiation-checking component will be more useful in order to gracefully exit the program. This approach also protects the application from losing any valuable data that Listing 2: A serializable hash map component 1 public interface SerialHMapSerf extends Serf { 2 /*-- dis implements Serializable --*/ 3 /*-- dis implements AreEqual --*/ 4 public setditemserf(serf dis); 5 /*-- ris implements Serializable --*/ 6 public setritemserf(serf ris); 7 8 public void define(data d, Data r); 9 public void undefine(data d); 10 public boolean isdefined(data d); 11 public Data lookup(data d); 12 public int size(); 13 } may have been processed before a particular violation is detected during the normal course of the program. 4. INSTANTIATION-CHECKING COMPO- NENTS In this section, we present DynInstaCheck 2 a tool that generates the run-time checks that are needed to enforce legal parameter bindings in dynamically-bound parameterized components. The tool provides a graphical user interface that allows the developer of the Serf to provide template parameter information. This information is encoded in XML, and is XML encoding is then used to generate AspectJ code that will actually perform the checking upon deployment. Enforcing legal parameter bindings is an orthogonal concern relative to the application that the Serf component is part of. Keeping with the principles of separation of concerns, therefore, this dimension of the Serf must be kept separate from the application code. Moreover, these runtime checks may only be needed while the system that the Serf is being used in is being developed. Once the entire system has been developed and is ready for final deployment, these checks should not be necessary. In fact, including such run-time checks in a production system will cause an unnecessary performance burden. The instantiation checking code should therefore be modularized separately from the rest of the application. Aspect-oriented programming [7] provides an ideal way to separate the instantiation checking code into its own module, in such a way that there is no interference between the checking code and the application code. Moreover, before the final production system is deployed, the aspects that enforce legal instantiation can be removed from the system; any errors relating to illegal parameter bindings would have been resolved during the testing phase. Consider the SerialHMapSerf component presented in Listing 2. The component defines a serializable hash map, and takes two parameters the type of domain items (DItem- Serf) and the type of range items (RItemSerf) that the hash map will hold. There are two restrictions on the domain item parameter: since the hash map has to be serializable, each individual item that the hash map holds should also be serializable (implements the Serializable interface). Moreover, in order for the lookup and isdefined operations to find locate a particular domain item in the hash map, the do- 2 The tool, along with source code, is available for download at

4 Listing 3: XML input to DynInstaCheck describing the serializable hash map component 1 <component> 2 <name>serialhmapserf</name> 3 <parameter> 4 <name>ditemserf</name> 5 <restriction> 6 <relation>implements</relation> 7 <dependence>serializable</dependence> 8 </restriction> 9 <restriction> 10 <relation>implements</relation> 11 <dependence>areequal</dependence> 12 </restriction> 13 </parameter> 14 <parameter> 15 <name>ritemserf</name> 16 <restriction> 17 <relation>implements</relation> 18 <dependence>serializable</dependence> 19 </restriction> 20 </parameter> 21 </component> main item type must support the AreEqual interface that supports value-based equality testing. The range item parameter must be serializable. The DynInstaCheck interface takes as input the following: The name of the Serf component, The names of all template parameters to the Serf, and Any type restrictions on the parameters. Using these pieces of information, the tool creates a profile of the Serf with respect to its parameters, and their characteristics. This profile is encoded as an XML document. The XML parameter profile of SerialHMapSerf is shown in Listing 3. The second phase of DynInstaCheck uses the XML profile of the Serf created in the previous phase in order to generate AspectJ code that enforces legal parameter bindings for the Serf. For each of the parameters specified in the XML profile, the restrictions R1 R3 are enforced. Listing 4 shows the instantiation checking aspect SerialHMapSerf IC, which enforces legal template parameter bindings for SerialHMapSerf. The SerialHMapSerf IC aspect defines three pointcuts. The first pointcut (setditemserfmethod, lines 5 8 captures all calls to the setditemserf method. We generate this pointcut following the naming convention that the Service Facility pattern composition prescribes: template parameters are bound using methods of the form setparameter for each Parameter. Similarly, the second pointcut (setritemserfmethod, lines 10 13) captures calls to the serritemserf method. The last pointcut (serfmethods, lines 15 17) captures all other methods in the Serf excluding the methods that define template parameters. Restriction R1 is enforced by the before advice in lines This advice is executed before every component method in SerialHMapSerf and checks to see if each one of the parameters to the Serf has been set. In order to check this, the aspect maintains a private data member to represent each template parameter to the Serf (lines 2 and 3). These data Listing 4: Aspect that performs instantiation checks for SerialHMapSerf 1 public aspect SerialHMapSerf_IC { 2 private Serf DItemSerf; 3 private Serf RItemSerf; 4 5 pointcut setditemserfmethod(serialstackserf s, 6 Serf p): 7 target(s) && 8 call (public * setditemserf(serf)) && args(p); 9 10 pointcut setritemserfmethod(serialstackserf s, 11 Serf p): 12 target(s) && 13 call (public * setritemserf(serf)) && args(p); pointcut serfmethods(serialstackserf s): target(s) && call (public * *(..)) &&!call (public * set*(..)); before(serialstackserf s): serfmethods(s) { 20 if (DItemSerf == null) 21 { throw new ParamNotBoundException("DItemSerf"); } 22 if (RItemSerf == null) 23 { throw new ParamNotBoundException("RItemSerf"); } 24 } void around(serialstackserf s, Serf p): 27 setditemserfmethod(s, p) { 28 if (DItemSerf!= null) { 29 throw 30 new ParamAlreadyBoundException("DItemSerf"); 31 } 32 else 33 { proceed(p); } 34 } void around(serialstackserf s, Serf p): 37 setritemserfmethod(s, p) { 38 if (RItemSerf!= null) { 39 throw 40 new ParamAlreadyBoundException("RItemSerf"); 41 } 42 else 43 { proceed(p); } 44 } void around(serialstackserf s, Serf p): 47 setditemserfmethod(s, p) { 48 if!(p implements Serializable) { 49 throw new ParameterTypeMismatchException( 50 "DItemSerf", "Serializable"); 51 } 52 else if!(p implements AreEqual) { 53 throw new ParameterTypeMismatchException( 54 "DItemSerf", "AreEqual"); 55 } 56 else 57 { DItemSerf = p; proceed(p); } 58 } void around(serialstackserf s, Serf p): 61 setritemserfmethod(s, p) { 62 if!(p implements Serializable) { 63 throw new ParameterTypeMismatchException( 64 "RItemSerf", "Serializable"); 65 } 66 else 67 { RItemSerf = p; proceed(p); } 68 } 69 }

5 members are set to their non-null values when a valid parameter is supplied to the Serf (lines 57 and 67 for DItemSerf and RItemSerf, respectively). Restriction R2 is enforced by an around advice for every parameter: lines for DItemSerf and lines for RItemSerf. The dynamic type of the argument passed into the setparameter method is checked to make sure that all type dependencies are satisfied. If any of these dependencies is violated, an exception to that effect is thrown and the program terminates. Restriction R3 is enforced by the two around advices in lines and lines In these advices, the local copy of the parameter is checked, and if it is non-null, then an exception is raised. This is the default case for all Serfs. However, the Service Facility pattern composition support dynamically reconfigurable components. In the case of such components, there may be a legal call to a setparameter method even when the parameter has already been set. Reconfigurable Serfs will be required to implement the ReconfigurableSerf interface as opposed to the Serf interface that our example uses. In the case of a ReconfigurableSerf, restriction R3 is not enforced. Correctness considerations for when it is safe to perform reconfiguration are handled by the ReconfigurableSerf component itself as described in [10]. The aspect that is generated by DynInstaCheck, when compiled with the Serf that it checks, provides correctness guarantees for legal template parameter bindings. Further, since these checks are modularized as an aspect, turning on or off these checks is easy, and is completely de-linked from the application. 5. RELATED WORK This work is most closely related to the work on contractchecking wrappers [2]. Our instantiation rules are encoded as contract predicates on the component, and are checked in accordance with design by contract. The contract-checking components in [2] are implemented as wrapper components, while we use an aspect-oriented approach. In fact, our approach could be extended to include the kinds of checks that their wrappers can perform. This is a direction for our future research. In [5], Hallstrom et al. describe the use of aspect-oriented programming to monitor and enforce design pattern contracts [4]. Their use of aspects for contract-checking is similar to ours. In their work, they encode the formal contract for a design pattern as an aspect. This aspect, when compiled with a program implemented using a design pattern, monitors the program at runtime and detects violations of the pattern contract. 6. CONCLUSIONS Dynamic binding of parameters to components greatly increases the flexibility of software systems. But the flexibility does come at a cost care must be taken to ensure that the bindings that take place at run time are indeed correct with respect to type safety. In this paper, we have presented the various kinds of checks that need to be performed in order to ensure type-correct parameter bindings, and described a tool that automatically generates an aspect-oriented solution to performing these checks in a modular fashion. As of now, we use our tool to generate aspects to check only the types of parameters supplied to Serfs. We are currently working on extending this work in checking other kinds of relationships and dependencies among parameters to a Serf. These dependencies may include order in which parameters are supplied, time of binding relative to the state of the application, etc. Our aspects could also be extended to check pre- and post-conditions that describe the behavioral specification of the component being monitored. 7. REFERENCES [1] G. Bracha, M. Odersky, D. Stoutamire, and P. Wadler. Making the future safe for the past: Adding genericity to the java programming language. In Proceedings of the conference on Object-oriented programming, systems, languages, and applications, pages ACM Press, [2] S. H. Edwards, M. Sitaraman, B. W. Weide, and J. Hollingsworth. Contract-checking wrappers for C++ classes. IEEE Transactions on Software Engineering, 30(11): , November [3] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, [4] J. O. Hallstrom. Design Pattern Contracts. PhD thesis, Computer Science and Engineering, The Ohio State University, [5] J. O. Hallstrom, N. Soundarajan, and B. Tyler. Monitoring design pattern contracts. In Proceedings of the the 3rd FSE Workshop on the Specification and Verification of Component-Based Systems, Newport Beach, CA, [6] A. Kennedy and D. Syme. Design and implementation of generics for the.net common language runtime. In Proceedings of the ACM SIGPLAN 2001 conference on Programming language design and implementation, pages ACM Press, [7] G. Kiczales, J. Lamping, A. Menhdhekar, C. Maeda, C. Lopes, J.-M. Loingtier, and J. Irwin. Aspect-oriented programming. In M. Akşit and S. Matsuoka, editors, Proceedings European Conference on Object-Oriented Programming, volume 1241, pages , Berlin, Heidelberg, and New York, Springer-Verlag. [8] D. Musser and A. Saini. STL Tutorial and Reference Guide: C++ Programming with the Standard Template Library. Addison-Wesley, [9] N. Sridhar. Dynamically Reconfigurable Parameterized Components. PhD thesis, Computer Science and Engineering, The Ohio State University, [10] N. Sridhar, S. M. Pike, and B. W. Weide. Dynamic module replacement in distributed protocols. In Proceedings of the 23rd International Conference on Distributed Computing Systems, May [11] N. Sridhar, B. W. Weide, and P. Bucci. Service facilities: Extending abstract factories to decouple advanced dependencies. In Proceedings of the 7th International Conference on Software Reuse, pages , April [12] H. Thimbleby. Delaying commitment. IEEE Software, 5(3):78 86, May/June 1988.