Reduced multiple empirical kernel learning machine Abstract Multiple kernel learning (MKL) is demonstrated to be flexible and effective in depicting heterogeneous data sources since MKL can introduce multiple kernels rather than a single fixed kernel into applications. However, MKL would get a high time and space complexity in contrast to single kernel learning, which is not expected in real-world applications. Meanwhile, it is known that the kernel mapping ways of MKL generally have two forms including implicit kernel mapping and empirical kernel mapping (EKM), where the latter is less attracted. In this paper, we focus on the MKL with the EKM, and propose a reduced multiple empirical kernel learning machine named RMEKLM for short. To the best of our knowledge, it is the first to reduce both time and space complexity of the MKL with EKM. Different from the existing MKL, the proposed RMEKLM adopts the Gauss Elimination technique to extract a set of feature vectors, which is validated that doing so does not lose much information of the original feature space. Then RMEKLM adopts the extracted feature vectors to span a reduced orthonormal subspace of the feature space, which is visualized in terms of the geometry structure. It can be demonstrated that the spanned subspace is isomorphic to the original feature space, which means that the dot product of two vectors in the original feature space is equal to that of the two corresponding vectors in the generated orthonormal subspace. More importantly, the proposed RMEKLM brings a simpler computation and meanwhile needs a less storage space, especially in the processing of testing. Finally, the experimental results show that RMEKLM owns a much efficient and effective performance in terms of both complexity and classification. The contributions of this paper can be given as follows: (1) by mapping the input space into an orthonormal subspace, the geometry of the generated subspace is visualized; (2) this paper first reduces both the time and space complexity of the EKM-based MKL; (3) this paper adopts the Gauss Elimination, one of the on-the-shelf techniques, to generate a basis of the original feature space, which is stable and efficient. Cognitive neuroscience seeks to clarify the cognitive activity of brain mechanisms. It explores how the human brain calls on all the levels of its components, including molecular, cellular, and the whole brain area, to achieve a variety of cognitive activities. In recent years, the research have made significant progress on several core branches of cognitive neuroscience including cognitive psychology, psychological linguistics, artificial intelligence, artificial neural network and so on. In this paper, we focus on the artificial intelligence and conduct a further research on machine learning. Through our research, we hope to inspire the further connection between machine learning and the other branches of cognitive neuroscience, which is also discussed by some researchers. For example, Wang et al. (2010) applied the principal component analysis (PCA) into the original electroencephalogram (EEG) for dimension reduction, which is a novel feature extraction of machine learning. Yu et al. (2011) proposed a new computational model of bottom-up visual attention based on a pulsed PCA transform, which exploited the signs of the PCA coefficients so as to generate a spatial and motional saliency. In the literature Zhang et al. (2013) , extracted the psychophysiological measures so as to characterize the operator functional state (OFS) in the automated tasks under a complex form of human-automation interaction, where the fuzzy C-mean (FCM) algorithm was used and tested for its OFS performance. In this paper, we conduct the research from the perspective of multiple kernel learning (MKL).. The classical formulation of MKL induces a linear convex combination of the M candidate kernels as G ¼ P M l¼1 a l K l ; a l ! 0; P M l¼1 a l ¼ 1 into support vector machine (SVM) (Muller et al. 2001) . Lanckriet et al. (2004) constructed a convex Quadratically Constrained Quadratic Program (QCQP) for the combinations of multiple kernels G ¼ P M l¼1 a l K l . For extending the method of Lanckriet et al. to large scale problems, Bach et al. (2004) took the dual formulation of QCQP as a Second-Order Cone Programming (SOCP) problem. Then Sonnenburg et al. (2006a, b) reconstructed QCQP as a Semi-Infinite Linear Program (SILP) that recycles the standard SVM implementations. Rakotomamonjy et al. (2007 Rakotomamonjy et al. ( , 2008 proposed simple MKL by exploring an adaptive 2-norm regularization formulation. Szafranski et al. (2010) , Xu et al. (2010) and Subrahmanya and Shin (2010) constructed the connection between MKL and group-LASSO to model group structure. Most of them were based on implicit kernel mapping (IKM) (Muller et al. 2001) . The IKM, denoted as U i ðxÞ, can be achieved by introducing a kernel function kðx i ; x j Þ, which determines the geometrical structure of the mapped data in feature space, where we do not need to obtain the explicit mapping form, but to compute the kðx i ; x j Þ ¼ U i ðx i Þ Á U i ðx j Þ (Muller et al. 2001) . In this paper, we focus on another kernel mapping method, which is called empirical kernel mapping (EKM). The EKM, denoted as U e ðxÞ, should explicitly give the feature of x in the mapped U e -space. The classical formulation of EKM is Scholkopf et al. 1999; Xiong et al. 2005 ), which will be described in Sect. 2.3. Both of U i ðxÞ and U e ðxÞ have their own characters. The former is supposed to avoid the curse of dimensionality and keep the linearity property of learning machine in the mapped space at the same time. The latter is supposed to be much easier in processing and analysis the adaptability of a kernel for the input space than the former (Kim et al. 2006; Yan et al. 2010; Farquhar et al. 2005 ). As we stated above, the MKL with IKM has recently got much attention Bach et al. 2004; Sonnenburg et al. 2006a, b; Rakotomamonjy et al. 2007; Szafranski et al. 2010) . In contrast, it is less attracted for the MKL with EKM except our previous work MultiK-MHKS (Wang et al. 2008) .. Although those MKL algorithms, which we mentioned above, successfully increase the accuracy, the use of multiple kernels leads to increase the time and space complexity significantly, including our previous work MultiK-MHKS. A real-world application typically requires testing its trained system for numerous instances. Testing a single instance requires smaller amounts of time and space than training the entire system, but the total amount of time and space consumed during the use of the system with numerous tests is critically important in real-world applications, especially when (1) the total storage space is restricted, and (2) the real-time response during testing an instance is required to be sufficiently fast.. There are two main methods to reduce the time and space complexity. One is to pre-process the inputs before training the classifiers, and the other is to optimize the architecture of MKL algorithms. The Nyström approximation method (Williams and Seeger 2001) decreases the computational cost of kernel-based methods from Oðn 3 Þ to Oðm 2 nÞ, where n is the number of training inputs and 0\m\n. The approximation matrixG is got by randomly choosing m rows and columns from the Gram kernel matrix G without replacement. And it is not necessary to store the whole Gram kernel matrix G, but only a m Â n portion of it. Wang et al. (2011) applied it into the multi-view learning machine. Moreover, Demir and Alpaydin (2005) developed a utility-based framework to reduce the time complexity. They constructed two novel cost-conscious ensembles; the first one determined a subset of classifiers and the second dynamically selected a single classifier. Both ensembles successfully switched between classifiers according to the accuracy-cost trade-off of an application. In this paper, we pay attention onto the combination MKL with EKM, and propose a reduced multiple empirical kernel learning machine named RMEKLM for short. As we mentioned above, we take the first method to reduce the time and space complexity, that is pre-processing the EKM-space. It is the first to propose the problem about reducing the time and space complexity for EKM-based MKL algorithm. As we know, in kernel based learning the data is mapped to a kernel feature space (F ) of a dimension that corresponds to the number of training data points. In practice, however, the data forms a smaller submanifold in F . The RMEKLM borrows the idea from (Harmeling et al. 2003) , which adopts an orthonormal basis to construct a subspace of F . Then by mapping the input vector into the reduced orthonormal space, we can get a reduced vector, which can reduce the time complexity, especially the testing time complexity. The orthonormality implies that the dot product of two reduced vectors coincides with that of two corresponding input vectors mapped into the original feature space, which is a remarkable property. In order to clarify the relationship between the geometry structures of F and the reduced space intuitively, we draw Fig. 1 . In Fig. 1 , for simplicity, we suppose that the input space is 1-dimensional. The inputs are non-linear separable. By mapping them into F , which could be 3-dimensional, these feature vectors are linear separable. However, these feature vectors constitute a subspace of F . So by generating an orthonormal basis of the subspace of F , we can get the 2-dimensional subspace, and also these reduced inputs are linear separable. Furthermore, we explorer a new way to obtain a group of inputs that later forms an orthonormal basis of F , which is more efficient and stable than the original method in (Harmeling et al. 2003) . In practice, rather than storing all the training inputs in the original EKM method, we just need to store a portion of them that later constructs an orthonormal basis of F , which reduces the space cost significantly.. In implementation, we apply RMEKLM to the framework of MultiK-MHKS (Wang et al. 2008 ), since which is also an EKM-based algorithm. MultiK-MHKS borrowed the characteristic of Canonical Correlation Analysis (CCA) (Hardoon et al. 2004 ) and explicitly mapped the input data into multiple feature spaces, where each feature space can be taken as one view of the original input data. Each view is expected to exhibit some geometrical structures of the original data from its own perspective such that all the views can complement for the subsequent learning task. The MultiK-MHKS aimed to make the projection of each view onto their corresponding basis vectors maximally close to the average projection of all views.. The advantages of the proposed RMEKLM are highlighted as follows:. • Visualized geometry structure: By mapping the inputs onto an orthonormal basis of the feature space, the well structured subspace is isomorphic to the original feature space. The visualizability of the orthonormal subspace is depicted in Fig. 1 .. • Reduced time and space complexity: Since we get a subspace of the original feature space, less calculations for kernel functions will be performed, so that the learning process is sped up, especially the testing process. And we only need to store a portion of the training patterns that later construct an orthonormal basis of the feature space. Fig. 1 The picture on the top side depicts the input space. By mapping the inputs into the feature space F , we get the picture on the left-bottom side. However, the feature vectors in F constitute an orthonormal subspace of F , which is depicted on the right-bottom side Elimination, one of the on-the-shelf techniques, so as to extract a set of feature vectors of the feature space to generate an orthonormal basis, which is more efficient and stable than the other methods used in Harmeling et al. (2003) .. The rest of this paper is organized as follows. Section 2 gives the architecture of the proposed RMEKLM. Section 3 reports on all the experimental results. Finally, conclusions and future work are given in Sect. 4. In this section, we choose MultiK-MHKS, SVM-2K (Farquhar et al. 2005) , KMHKS and SVM to compare with RMEKLM for classification performance. Especially, we pay close attention to RMEKLM and MultiK-MHKS, since both of which are based on EKM. Results of the experiments show that RMEKLM can reduce both the training time and the testing time without losing much classification accuracy, particularly on the large-scale data sets. Benchmark data sets used here are listed in Table 2 . Experimental setting, classification and computation performance comparison, performance of two orthonormal basis generation algorithms will be discussed in the following subsections.

O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O


Delegation by object composition Class inheritance and method overriding, as provided by standard class-based languages, are often not flexible enough to represent objects with some dynamic behavior. In this respect, object composition equipped with different forms of method body lookup is often advocated as a more flexible alternative to class inheritance since it takes place at run time, thus permitting the behavior of objects to be specialized dynamically. In this paper, we illustrate Incomplete Featherweight Java (IFJ), an extension of Featherweight Java with a novel linguistic construct, the incomplete object. Incomplete objects require some missing methods which can be provided at run time by composition with another (complete) object. Furthermore, we present two mechanisms for the method body lookup on (composed) objects, one based on delegation and the other based on consultation. Thanks to the design of the language, the consultation-based lookup is a simple extension of the delegation-based one. Both mechanisms are disciplined by static typing, therefore the language enjoys type safety (which implies no ''message-not-understood'' run-time errors) and avoids possible accidental overrides due to method name clashes. Design patterns were introduced as ''programming recipes'' to overcome some of the limitations of class-based objectoriented languages. Indeed, standard mechanisms provided by class-based object-oriented languages, such as inheritance and dynamic binding, usually do not suffice for representing dynamic behavior of objects (we refer to [35, 18] and to the references therein for an insightful review of the limitations of inheritance). Most of the design patterns in [22] rely on object composition as an alternative to class inheritance, since it is defined at run time and it enables dynamic object code reuse by assembling existing components. Patterns exploit the programming style consisting in writing small software components (units of reuse), that can be composed at run time in several ways to achieve software reuse. However, design patterns require manual programming, which is prone to errors.. Differently from class-based languages, object-based languages do use object composition, and delegation as the mechanism for method call, to reuse code (see, e.g., the languages [36, 23, 16] , and the calculi [21, 2] ). Every object has a list of parent objects: when an object cannot answer a message it forwards it to its parents until there is an object that can process the message. However, a drawback of delegation is that run-time type errors (''message-not-understood'') can arise when no delegates are able to process the forwarded message [37] . We refer to Kniesel [26] for an overview of problems when combining delegation with a static type discipline.. Our goal is the design of a class-based language that offers a form of object composition with the following goals in mind:. • maintaining the class-based type discipline;. ✩ This work has been partially supported by the MIUR project EOS DUE. • gaining some of the flexibility of the object-based paradigm;. • preventing the message-not-understood error statically;. • preventing possible name clashes for methods with the same name but different signatures • preserving the nominal type system of Java-like languages.. In [10, 6] we introduced a novel linguistic construct, the incomplete object. The programmer, besides standard classes, can define incomplete classes whose instances are incomplete objects that can be composed in an object-based fashion. Hence, in our calculi it is possible: (i) to instantiate standard classes, obtaining fully fledged objects ready to be used; (ii) to instantiate incomplete classes, obtaining incomplete objects that can be composed (by object composition) with complete objects, thus yielding new complete objects at run time; (iii) in turn, to use a complete object obtained by composition to be composed with other incomplete objects. Therefore, objects are not only instances of classes (possibly incomplete), but they are also prototypes that can be used, via the object composition, to create new objects at run time, while ensuring statically that the composition is type safe. Then, we can use incomplete and complete objects as our re-usable building blocks to assemble at run time, on the fly, brand new objects.. Our two proposals are for Java-like languages and differ from each other with respect to the method body lookup: the first one [10] combines incomplete objects with consultation, and the second one [6] with delegation [29] . 1 In both cases an object A has a reference to an object B. However, when A forwards to B the execution of a message m, two different bindings of the implicit parameter this can be adopted for the execution of the body of m: with delegation, this is bound to the sender (A), thus, if in the body of the method m (defined in B) there is a call to a method n, then also this call will be executed binding this to A; while with consultation, during the execution of the body, the implicit parameter is always bound to the receiver B. This is depicted in Fig. 1 . Delegation is more powerful as it endows dynamic method redefinition. Both our proposals result type safe, therefore they capture statically message-not-understood errors. In particular, our proposals are two versions of Incomplete Featherweight Java (IFJ), as extensions of Featherweight Java [25, 31] .. One of our key design choices is to integrate object composition within the nominal subtyping mechanism that is typical for mainstream languages like Java (and C++). This feature makes the extension conservative with respect to the core Java, since it does not affect those parts of the programs that do not use incomplete objects. Furthermore, incomplete classes can rely on standard class inheritance to reuse code of parent classes (although this kind of inheritance does not imply subtyping in our setting). Thus, incomplete objects provide two forms of code reuse: vertical (i.e., the code reuse achieved via standard class inheritance) and horizontal (i.e., the one achieved via object composition). Finally, in order to enhance runtime flexibility in composing objects, we implicitly use structural subtyping during composition: an incomplete object can be composed with any (complete) object providing all the requested methods (that is, the signatures must match), no matter what its class is. Therefore, the language extension we propose is not a manual implementation of the object composition. In the case of a manual implementation, the object should be stored in a class field, thus forcing it to belong to a specific class hierarchy. Alternatively, one could use type Object, and then call methods using Java Reflection APIs or down-casts; however, this solution is not type safe, since exceptions can be thrown at run time due to missing methods (we will show further details concerning possible manual implementations in Section 3).. Incomplete classes, besides standard method definitions, can declare some methods as ''incomplete'', either abstract or redefining. Abstract methods are similar to abstract methods in class-based inheritance: the body of these methods must be provided during object composition. Redefining methods are similar to method overriding in class-based inheritance: they expect to redefine a method of another object. Then, we call these methods ''redefining'' because they will be the active part in the redefinition when an incomplete object will be composed with a complete object. We call the corresponding overridden methods of the complete object redefined. Moreover, just like in class-based inheritance, there is a way in an overridden method to access the previous implementation (e.g., super in Java): in a redefining method we can access the redefined version with the special variable next. We can think of next as an ''horizontal'' version of super, that is, a reference to the method body that is present in the complete object of an object composition: the method version in the incomplete object redefines the one present in the complete one. This is a form of incompleteness other than the one based on the abstraction of a method, because it assumes for an incomplete object that in a ''future'' composition a complete object will provide the method to be redefined.. All these incomplete methods, abstract and redefined, must be provided during object composition by complete objects. Thus, object composition is the run-time version of class inheritance and delegation in composed objects correspond to dynamic binding for method invocation in standard derived classes. We see this as a sort of dynamic inheritance since L ::= class C extends C {C f; K; M} it implies both substitutivity (that is, a composed object can be used where a standard object is expected) and dynamic code reuse (since composition permits supplying at run time the missing methods with those of other objects). Namely, substitutivity for composed objects is achieved by extending Java subtyping, while dynamic code reuse corresponds to the extension of standard subclassing. Therefore, we can model some features related to dynamic object evolution: while incomplete classes separate the object invariant behavior from the variant one at compile time, at run-time object composition customizes the unpredictable behavior based on dynamic conditions (for instance, the object state) in a typesafe way. In particular, some behavior that was not foreseen when the class hierarchy was implemented may be supplied dynamically by making use of already existing objects, thus generating an unanticipated reuse of code and a sharing of components.. In this paper, firstly we extend the delegation-based proposal [6] by revising and improving the formal part and by including the full proof of type soundness. Providing delegation, instead of consultation, enhances the flexibility of object composition in IFJ and makes dynamic method redefinition effective (in fact, in [10] we were not able to provide method redefinition). Moreover, it requires an interesting technical treatment to achieve a type-safe implementation. For instance, we need to avoid possible name clashes for methods with the same name but with different signatures (possibly due to the subtyping, [21] ) and possible accidental method overrides (when a method in the incomplete object, which is not redefining, has the same name and signature of a method of the complete object). In order to deal with such problems, we employ a static annotation procedure (based on static types) which is used in the operational semantics to bind the self-object this correctly in the method bodies.. Then, we show how consultation can be added to the calculus. Consultation was not only useful as a preliminary study for appreciating how the composition mechanism can be integrated in a Java-like, class-based setting (the main goal of [10] ), but it is interesting in its own, since it provides the programmer with more control on method invocation (see Section 7).. The main contributions of this paper, with respect to [6] , are inter alia: (i) putting together the consultation-based and the delegation-based proposals, by using an unique model of object composition; (ii) a full formalization of the delegationbased proposal, including a complete proof of the type safety property. The type safety property for the version with both delegation and consultation follows in a straightforward way, as discussed at the end of Section 7.. The paper is organized as follows. Section 2 defines the calculus for object composition with delegation. Section 3 illustrates the application of our proposal to recurrent programming scenarios. Sections 4 and 5 develop the typing system and the operational semantics, respectively. Section 6 presents the full proof of the type safety. Section 7 shows how consultation can be implemented in the calculus, in addition to delegation. Section 8 discusses some related works and Section 9 concludes. Our goal was to design a language based on a trade-off between the dynamic flexibility of object-based languages and the static type discipline of class-based languages. To this aim, we presented linguistic constructs to deal with incomplete objects and object composition in a type-safe way. In our proposal, objects are still instances of (possibly incomplete) classes and they are still disciplined by the nominal subtyping, but they are also prototypes that can be used, via the object composition, to create new objects at run time, while ensuring statically that the composition is type safe.. We introduced two different treatments of method body lookup, one delegation-based, the other consultation-based. The former was presented in [6] and the latter was introduced in [10] . The delegation mechanism unleashes the flexibility of incomplete objects (compared to the consultation-based proposal) by enabling a form of dynamic method redefinition. This poses some interesting technical challenges that we solved in a pragmatic way (with in mind the constraint of being easily implementable in a Java-like language). For instance, object composition and delegation introduce the ''width subtyping versus method addition'' problem that is well known in the object-based setting (see, e.g., [21] ). We solve this issue by representing objects as lists of sub-objects in such a way that we can explicitly deal with the ''scope'' of a method invocation; we believe this solution is more implementation-oriented than the dictionaries of [32] and simpler than the one of [7] .. We pointed out that delegation is more powerful than consultation because it introduces a dynamic form of method redefinition. In practice, in our calculus, the leftmost object in a composition has always the power to override the methods of the other objects whenever the method lookup is performed by delegation. However, as discussed in Section 7, there are some situations in which redefinition is not desirable. On the other hand, no redefinition at all, as it is with consultation, may be too restrictive in some other context. This highlights the benefits of providing both delegation and consultation by object composition in Java-like languages. In the present paper, the interaction between the two mechanisms has been interpreted in a basic way: the programmer can decide to switch from the delegation mechanism to the consultation one by using a specific keyword (the operator consult). As an ongoing research, we are studying intermediate and more flexible forms of method lookup, in such a way that it is possible to enforce whether a certain method (or a set of methods), in a given chain of invoked methods, is (are) overridden dynamically or not. Our formalization of objects via pairs of lists allows us to introduce new operators, for such intermediate forms of combination of consultation and delegation, in such a way that the operators are independent from each other and the semantics of the language remains compositional (as it is with the addition of consultation in Section 7).. In [8] we presented I-Java, an extension of the Java language with incomplete objects and object composition. We implemented a preprocessor that, given a program that uses our language extension, produces standard Java code (the preprocessor is available at http://i-java.sf.net). The implementation in Java of incomplete objects with delegation is currently under development. The I-Java implementation via a preprocessor suggests a basis for a formal embedding of our calculus into Featherweight Java [25] , and this is matter of an ongoing work.. In this introductory version of our calculus, we only allow an incomplete object to be completed in one shot, by composition with a completed object. To add practicality to our approach, it would be useful for incomplete objects to be also partially completed by a single composition, such that a new incomplete object is created, to be completed by one or further compositions. An additional mechanism would be to compose two incomplete objects. On the one hand, these two extensions would not pose any particular issue from an operational point of view, on the other hand they require a careful study of a suitable form of subtyping from the point of view of the type system. In fact, combining full object composition with subtyping introduces issues similar to ones discussed in [9, 7] , and they are the subject of future work. Concerning the theory of incomplete objects, our main inspiration comes from [7] ; however, while that calculus builds on top of the lambda calculus, here we aim at investigating on how object composition can fit within the basic principles of Java-like languages. Comparisons with other related work follow.. Incomplete objects in lambda calculus. An explicit form of incomplete objects was introduced in [12] , where an extension of Lambda Calculus of Objects of [20] is presented. In this work, labeled types are used to collect information on the mutual dependencies among methods, enabling a safe subtyping in width. Labels are also used to implement the notion of completion, which permits adding methods in an arbitrary order allowing the typing of methods that refer to methods not yet present in the object, thus supporting a form of incomplete objects. The context is again a lambda calculus, while in this work we are interested in incorporating object composition into Java-like languages.. Other work on delegation. In [26] , delegation is presented in the model of the language Darwin; however, this model requires some basic notions to be modified, such as method overriding. Our language, instead, proposes a conservative extension of a Java-like language (so that existing code needs not to be changed). Furthermore, in [26] the type of the parent object must be a declared class and this limits the flexibility of dynamic composition, while in our approach there is no implicit parent and missing methods can be provided by any complete object, independently from its class.. On mixins. Incomplete object mechanisms were originally inspired by mixin-based inheritance [13] : mixins are classes parametrized over the superclass and new subclasses can be generated by applying a mixin to a class (that provides all the requirements of the mixin). However, object composition in our language takes place at run time, while mixin inheritance, although more flexible than standard class-based inheritance, is still a compile-time mechanism.. On wrappers and delegates. Incomplete objects can be seen as wrappers for the objects used in object composition. However, they differ from decorator-based solutions such as the language extension presented in [11] : incomplete objects provide a more general-purpose language construct and the wrappers of [11] could be actually implemented through incomplete objects. Another form of wrapping of methods is the one offered by the delegates of C#. Delegates are objects pointing to one method or to a set of methods, that will be executed when invoked appropriately on the delegate. Therefore, it is possible to treat methods as anonymous functions, implementing a form of reuse. Delegates can be then seen as complementary to incomplete objects, as the latter implements a different form of reuse, allowing to customize a prototype (i.e., an incomplete object) in more than one way via object composition.

B O B I O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O B I O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O B I O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O B I O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B O B O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O B O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I


Bipanconnectivity and Bipancyclicity in k-ary n-cubes Abstract-In this paper, we give precise solutions to problems posed by Wang et al. and by Hsieh et al. In particular, we show that Q k n is bipanconnected and edge-bipancyclic, when k ! 3 and n ! 2, and we also show that when k is odd, Q k n is m-panconnected, for m ¼ nðkÀ1Þþ2kÀ6 2, and ðk À 1Þ-pancyclic (these bounds are optimal). We introduce a path-shortening technique, called progressive shortening, and strengthen existing results, showing that when paths are formed using progressive shortening, then these paths can be efficiently constructed and used to solve a problem relating to the distributed simulation of linear arrays and cycles in a parallel machine whose interconnection network is Q k n , even in the presence of a faulty processor. T HE choice of interconnection network is crucial in the design of a distributed-memory multiprocessor. As to which network is chosen depends upon a number of factors relating to the topological, algorithmic, and communication properties of the network and the types of problems to which the resulting computer is to be applied. One of the most popular interconnection networks is undoubtedly the n-dimensional hypercube Q n . Some of its pleasing properties, with regard to parallel computation, include the following: it is vertex-and edge-symmetric; it is Hamiltonian; it has diameter n; it has a recursive decomposition; and it contains, or "nearly" contains (as subgraphs), almost all interconnection networks currently vogue in parallel computing (see [18] for these results and more on the hypercube). Some of the commercial machines whose underlying topology is based on the hypercube are the Cosmic Cube [23] , the Ametek S/14 [2] , the iPSC [10] , [11] , the Ncube [7] , [11] , and the CM-200 [8] .. However, every vertex of Q n has degree n, and, consequently, as n increases so does the degree of every vertex. High degree vertices in interconnection networks can lead to technological problems in parallel computers whose underlying topology is that of the said interconnection network. One method of circumventing this problem, so as to still retain a "hypercube-like" interconnection network, is to build parallel computers so that the underlying topology is the k-ary n-cube Q k n . The k-ary n-cube Q k n is similar in essence to the hypercube, but by a judicious choice of k and n, we can include a large number of vertices yet keep the degree of each vertex fixed. For example, the hypercube Q 12 has 4,096 vertices and every vertex has degree 12. However, Q 16 3 has 4,096 vertices and every vertex has degree 6. Of course, one usually loses out in some other respect (for example, in terms of diameter), but often, this loss is not too catastrophic. The k-ary n-cube Q k n has not been investigated to the same extent as the hypercube, but it is known to have the following properties (among many others): it is vertex-and edge-symmetric [3] ; it is Hamiltonian [4] , [6] ; it has diameter nbk=2c [4] , [6] ; it has a recursive decomposition; and it contains many important interconnection networks such as cycles (of certain lengths) [3] , meshes (of certain dimensions) [4] , and even hypercubes (of certain dimensions) [6] . Machines whose underlying topology is based on a k-ary n-cube include the Mosaic [24] , the iWARP [5] , the J-machine [21] , the Cray T3D [16] , and the Cray T3E [1] .. Of interest to us in this paper are the different paths and cycles embedded within k-ary n-cubes. Path and cycle networks are fundamental in parallel computing; not only is there a multitude of algorithms specifically designed for linear arrays of processors and cycles of processors but also paths and cycles appear as data structures in many more algorithms for parallel machines whose processors are interconnected in a variety of topologies. For example, having a collection of processors connected in a cycle means that all-to-all message passing can be undertaken by "daisychaining" messages around the cycle. Of particular interest to us are questions relating to Hamiltonicity, pancyclicity, panconnectivity, bipancyclicity, and bipanconnectivity (these concepts are defined in the next section). These properties can be described as "strong Hamiltonicity" properties and their existence in an interconnection network enables a much higher degree of flexibility with regard to the simulation of linear arrays of processors or cycles of processors.. The notions in the preceding paragraph have been investigated in the context of a number of interconnection networks: for example, in crossed cubes [12] , [31] , Mö bius cubes [14] , augmented cubes [20] , alternating group graphs [9] , star graphs [29] , bubble-sort graphs [17] , and in hypercubes and hypercube-like networks [13] , [19] , [22] , [25] , [26] , [28] , [30] . With regard to k-ary n-cubes, these notions have been considered in [15] and [27] . In particular, it was proven in [27] that Q k 2 is almostHamiltonian connected, bipanconnected, and bipancyclic; that Q k n is almost-Hamiltonian connected, for any k; and that Q k n is Hamiltonian-connected, for odd k. Recently, it has been proven in [15] that Q 3 n is edge-pancyclic. It was posed as an open problem in [27] as to whether their results on bipanconnectivity and bipancyclicity for Q k 2 could be extended to Q k n , for arbitrary n, and it was posed as an open problem in [15] as to whether their results on panconnectivity and pancyclicity could be extended to Q k n , for arbitrary k. In this paper, we provide precise answers to both these questions. In addition, we show that when k is odd, Q k n is m-panconnected, for m ¼ nðkÀ1Þþ2kÀ6 2. , and ðk À 1Þ-pancyclic (these bounds are optimal). We also strengthen the results in [15] and [27] by introducing a path-shortening technique, called progressive shortening, and show that the construction of paths using this technique enables us to efficiently construct paths in a distributed fashion and so solve a problem relating to the distributed simulation of linear arrays and cycles in a parallel machine whose interconnection network is Q k n , even in the presence of a faulty processor (even in Q k 2 , the solution to this problem is not possible using the paths constructed in [27] ).. In the next section, we present some basic definitions and results, before improving the constructions from [27] in Q k 2 in Section 3. In Section 4, we look at the general case when k is even, and in Section 5 when k is odd. We outline our application in Section 6 before presenting our conclusions in Section 7. In tandem with [15] and [27] , we have resolved completely the main questions concerning panconnectivity, bipanconnectivity, pancyclicity, and bipancyclicity for a k-ary n-cube Q k n , when k ! 3 and n ! 2. In doing so, we have introduced the new concept of the progressive shortening of a path and shown how this concept can be used to solve a problem related to the embedding of linear arrays and cycles of processors in a distributedmemory multiprocessor whose interconnection network is a k-ary n-cube and where there is one faulty processor.. As directions for future research, we would like to see more applications of progressive shortening (and feel that the concept will prove to be more widely applicable). Also, we would like to see results on panconnectivity, pancyclicity, and so forth, extended to k-ary n-cubes in which there may be (a limited number of) faulty vertices or edges.

B O B O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O


A review of design pattern mining techniques The quality of a software system highly depends on its architectural design. High quality software systems typically apply expert design experience which has been captured as design patterns. As demonstrated solutions to recurring problems, design patterns help to reuse expert experience in software system design. They have been extensively applied in industry. Mining the instances of design patterns from the source code of software systems can assist the understanding of the systems and the process of re-engineering them. More importantly, it also helps to trace back to the original design decisions, which are typically missing in legacy systems. This paper presents a review on current techniques and tools for mining design patterns from source code or design of software systems. We classify different approaches and analyze their results in a comparative study. We also examine the disparity of the discovery results from different approaches and analyze possible reasons with some insight. During the past decade, design patterns [12] [7] [24] have been widely adopted by software industry to reuse expert design experience. Software developers become routinely reusing design patterns to solve their problems that are frequently encountered by them. Patterns document expert experience on solving recurring problem. The reuse of patterns may help the software architect to avoid pitfalls and mistakes in software design, and thus improve the quality of software products. Design patterns may help to record architectural tradeoff, capture design decisions, and reuse expert experience. Many current software systems embed instances of design patterns in system source code. After patterns are applied and implemented in a system, however, the pattern-related knowledge is generally no longer available in the source code. It is hard to trace such design information in source code. Even though the design information and diagrams are available, furthermore, it is typically not easy to find the patterns applied in a large software design. Pattern-related knowledge is normally buried under the descriptions because the participants of a pattern are not tagged with any knowledge on what roles they play in the design patterns. Without such knowledge, software designer cannot communicate with each other in terms of the patterns used. A software designer may forget the patterns he/she used over a long period of time. Thus, the benefits of applying patterns may be compromised. The important design decisions may be lost. Mining design pattern instances from system source code or design can greatly help to understand the systems and change them in the future. It also helps to trace back to the original architectural design decisions which are generally lost in system source code. Although recent model-driven development (MDD) techniques improve the documentation of design and allow the maintenance at model design level, pattern-related knowledge is still missing in high-level software design models [19] . Even the high-level design models are available, thus, mining design patterns is still essential.. Designing a software system is hard; designing high-quality reusable system is even harder. Design patterns may help to design large high-quality systems in forward engineering. On the other hand, pattern-related knowledge is generally not available in software systems. Understanding large software systems is difficult. Many legacy systems lack design documents. With the evolution of software systems, design documents may not be consistent with their source code anymore. Reverse-engineering design information can recover the early decisions and assist the understanding of the systems, and thus, improve the systems with higher quality. Many existing techniques and tools can help mining software design from system source code. These reverse engineering tools become the foundation for design pattern discovery that typically do not search the source code from scratch. The results of these tools are the source of pattern discovery.. A number of pattern mining techniques and tools have been proposed in the literature. These approaches apply different methods and present different results. To the best of our knowledge, however, there is no study to classify these approaches and analyze their results. It is important to study different approaches due to the following reasons. First, this study may help to understand the differences and similarities between different approaches. Second, it assists to identify challenging issues in pattern discovery. Third, we found that different approaches may render different results while mining the same pattern from the same system. It is interesting to know the reason for such disparity. Fourth, this study may lead to benchmarking of pattern discovery techniques.. In this paper, we present a comparative study to classify different pattern mining approaches. We study their different technical bases and summarize their results with the numbers of patterns discovered and the names of the systems experimented. In addition, we analyze the disparity of different results and the potential reasons and insights for such differences. Furthermore, we evaluate the relative strength and weakness of different approaches. We also discuss the issues related to the precision and recall.. The rest of this paper is organized as follows. Section 2 presents a comparative study based on different characteristics of design pattern discovery techniques. Section 3 introduces the different discovery results from different approaches and analyzes the reasons. We conclude the paper in Section 4. We compare the existing approaches based on the seven dimensions mentioned previously. They all differentiate themselves from others in some dimensions. Table 12 summarizes the comparative study on all different dimensions.. In this section, we present an analysis of the experiment results from different approaches and study the reasons for the disparity among the results. We found that the main reasons are missing roles, role types, and relationships, such as association, generalization, and delegation, as well as implementation variations. Such omissions are actually part of underlying theory and principles of design patterns. We backed up our analysis with some representative examples that are generalizeable to other approaches. We have not enumerate all cases for each problem because the main goal of our analysis is to identify the problems and challenges of current pattern mining techniques and to show the causes of the problems to be missing checking important object-oriented characteristics underlying the design patterns. Our study demonstrates the importance of identifying the essential characteristics of each design patterns [21] . Software design patterns encapsulate good ideas for solving high level problems in large software systems. They have been widely adopted by software industry as best practice. They benefit not only forward engineering when software architect needs to design and develop software systems from scratch, but also reverse engineering when mining and understanding of a software system is critical to its change and evolution. Patterns help to improve software architectural design by reusing expert solutions. However, patterns are normally not traceable from system source code. The design and its system may evolve and migrate independent from each other making them inconsistent. Mining design patterns from a system may greatly assist the understanding and further improvement of system quality. It also visualizes the evolution and migration of system design over time.. Many pattern mining techniques and tools have been proposed in the literature. In this paper, we presented a comparative study on these approaches in terms of the pattern aspects checked, the intermediate representations, exact or approximate matches, visualization, automated or human interactive supports, mining results and experiments based on our initial work in [22] . In addition, we discussed the results rendered by these approaches and analyzed the disparity of these results and the potential reasons. Although most of experiments conducted by these approaches are on different systems, some of them use the same systems. Our study demonstrates that there is disparity among the experiment results from these approaches even on the same systems. This signifies a key challenge in pattern discovery, that is, there is no standard and rigorous definition of the characteristics of each pattern. Patterns are normally described informally for easy understanding. Moreover, many patterns present flexible architectural design that can be instantiated into several different applications. Although formal methods have been used to specify design patterns and their integrations [15] , these approaches tend to focus on the introduction of formal methods for patterns specifications, instead of concentrating on the identification of the essential characteristics of each pattern which are important architectural design features to be discovered. Initial work addressing this challenging issue in pattern discovery has been conducted in [21] .. Most of existing approaches on pattern discovery present some experiments on open-source and/or in-house systems. Few approaches discussed the precision and recall of their techniques with the following possible reasons. First, the experimental systems, especially the open-source systems, do not provide any architecture and design documents that clearly identify the numbers and exact locations of the pattern instances. Second, patterns are generally flexible design templates that may have several variations, which may lead to different implementations. Third, design patterns are typically described informally, which may cause ambiguity, imprecision, and misunderstanding. Due to these reasons, different approaches may present different results for mining the same pattern from the same system. To the best of our knowledge, there is no benchmark system available so far. Benchmarking is important because it can help to compare different approaches with the same environment and criteria. We plan to work on benchmarking the pattern discovery techniques [20] .. New methods and tools are continuously proposed with the new trend on applying interdisciplinary technologies, such as computer vision [17] and machine learning [18] , into design pattern mining. While existing approaches and tools are typically evaluated in an ad-hoc manner, the comparison among these approaches may not result in a best choice because they are not evaluated with a common benchmark as discussed previously. A benchmark may allow the study of the best choices of tools in different situations.. Software architectural design is an abstraction of a large complex system, which aids the understanding and analysis of the system. Although the study of software architectural design may be independent from its system, maintaining the connection between a system and its architectural design is critically important. The study of software architectural design without concerning the connection to its system may lose touch of the reality. In summary, there are several benefits of our study and analysis in this paper. Our study allows a deep understanding of the problems of pattern discovery. It also identifies the challenging issues in mining patterns from both the system source code and architectural design. Furthermore, our analysis provides the insight on the effectiveness of different solutions by comparing different approaches. Moreover, our study helps to recognize new related problems, such as benchmarking and pattern charactering. Experiment is a good way to evaluate approaches. Table 11 presents a list of software systems used in the experiments by different studies. Due to the lack of documents of these systems, especially open-source systems, it is hard to evaluate the precision of different approaches. Some in-house systems may have documents that can help the analysis of the precision and recall of their approaches. For example, Streitferdt et al. [40] experiment on their own systems and Heuzeroth et al. [27] [28] use Java code of their own mining tool as experiment subjects. Although the precision and recall is relatively easy to compute for these in-house systems, they are not representative experiment samples comparing with other publicly available systems. Most approaches experiment on open-source systems, such as Java.AWT [49] , JHotDraw [51] , JEdit [50], and JUnit [52] . Due to the lack of documents of these open-source systems, it is hard to compute the precision and recall of the mining tools. Although manual checking has been conducted by some approaches for this purpose, variations of patterns and human errors may bias the values of precision and recall as discussed in the next section.

O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O B I B O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Applications of TLS and related methods in the environmental sciences Rainfall-Runoff and Signal Separation Problems: The process of converting rainfall into runoff is a highly nonlinear problem due to the soil-water interaction that starts when rainfall reaches the ground. Additional variables to consider are evaporation, transpiration, losses due to vegetation and land use, and the different flow processes that take place in a watershed. For instance, baseflow is a much slower process than groundwater and surface flow. Given records of rainfall and runoff data, one can build an accurate state-space model such aswhere at time k, u k , y k , and x k are, respectively, the rainfall, runoff, and the state of the system. Such models have been used in real-time forecasting scenarios for flood control purposes [12] . However, the above model does not take into account the nonlinearities of the rainfall-runoff process. Most lumped rainfall-runoff models separate the baseflow and groundwater components from the measured runoff hydrograph in an attempt to model these as linear hydrologic reservoir units. Similarly, rainfall losses due to infiltration as well as other abstractions are separated from the measured rainfall hyetograph, which are then used as inputs to the linear hydrologic reservoir units. This data pre-processing is in essence a nonlinear signal separation problem that separates rainfall into infiltration and excess rainfall, and the measured hydrograph into surface flow and groundwater flow. These are then used to build separate linear models such as

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Dynamic semantic location modeling in mobile enterprise applications A location model represents the inclusive objects and their relationships in a space. This paper presents a framework for dynamic semantic location modeling that is novel at three-fold: (1) Profoundly bring into the enterprise business models the location models (that underlie Location-Based Services -the killer application of M-Commerce). (2) With a novel method of dynamic semantic location modeling, enterprises effectively recognize the needs of the clients and the partners scattering in different locations, advancing existing business relationships if appropriate strategies are exerted. (3) Through the Location Model Platform of information sharing, enterprises are empowered to discover the potential business partners and estimate the values of their cooperation, enhancing their competitive advantages in a market when appropriate partnerships are formed. This proposed framework is implemented with J2EE and gives rise to certain promising evaluation results. With the advent of wireless communication technologies, the era of mobile enterprises unfold. Many international enterprises like IBM, Sun, HP and Microsoft are vying to develop mobile enterprise servers and solution architectures. According to a Cutter report, 57% of the employees in the enterprises worldwide will be defined as "mobile workforce" by 2005 [3] . Accordingly, following the e-business trend, competitive advantages built on wireless technologies in dynamic mobile environments are now widely recognized by enterprises.. The quintessence of mobile enterprises is that enterprise users are able to have personalized, seamless access to enterprise applications and services from any place and any time, regardless of the devices employed, in order to make contextualized decisions in behalf of the enterprises [1] .. On the other hand, location is an inherent feature of many mobile services. Location-based services (LBS) are information services that exploit knowledge about where an information device user is located. According to Ovum, an analyst and consulting company, the market for LBS will grow to $12 billion by 2006. However, existing LBS primarily rests on targeted advertising, linking the buyers and sellers more readily and facilitating additional revenue generation [11, 12] . LBS for enterprise decisions are rarely perceived except logistic delivery planning based on geometric models (static location models). The possibilities behind this rareness are two-fold: (1) The integration of enterprise business models and location models is not straightforward. ( 2) The limitation of existing location models hinders additional developments on enterprise-based LBS. The goal of Dynamic Semantic Location Model is to integrate enterprises business models with location models that have been playing a very important role in mobile commerce. Dynamic Semantic Location Modeling advances the former location modeling methods by embodying the dynamic and semantic features. Enterprises can build up their Business-Oriented Location Model first and then search for their potential partners in Location Model Platform. Finally, if the advanced cooperation between two enterprises can be possible, Partner Network Location Model will be constructed with their Business-Oriented Location Models. In conclusion, Dynamic Semantic Location Model provides certain solutions to enterprise-based LBS that take into account enterprise business models, transforming enterprises into high-end mobile enterprises. We have also evaluated Partner Network Location Model and Location Model Platform and created a few innovative scenarios about the integration of enterprise business models and the proposed location models. Our future work aims at realizing the proposed modeling method in a realistic domain, soliciting further adjustments required for practical exertion.

O O B I O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O B I O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


An anelastic allspeed projection method for gravitationally stratified flows This paper looks at gravitationally stratified atmospheric flows at low Mach and Froude numbers and proposes a new algorithm to solve the compressible Euler equations, in which the asymptotic limits are recovered numerically and the boundary conditions for block-structured local refinement methods are well-posed.The model is non-hydrostatic and the numerical algorithm uses a splitting to separate the fast acoustic dynamics from the slower anelastic dynamics. The acoustic waves are treated implicitly while the anelastic dynamics is treated semi-implicitly and an embedded-boundary method is used to represent orography. We present an example that verifies our asymptotic analysis and a set of results that compares very well with the classical gravity wave results presented by Durran. We developed a numerical method for low-Mach/low-Froude number flows in a continuously stratified atmosphere. The numerical algorithm uses a splitting to separate the fast acoustic dynamics from the slower anelastic dynamics. In the limit of small Mach number and small aspect ratio, we recover an anelastic system of equations, with an inhomogeneous constraint given by (66). The acoustic waves are treated implicitly while the advective transport of the solenoidal velocity field is computed using explicit upwind methods, in an overall semi-implicit discretization of the splitting. The resulting formulation, combined with a vertical normalmode analysis, provides a clear analytic separation of the acoustic, advective, and fast buoyant time scales in which the full problem, as well as the resulting sub-problems in the semi-implicit discretization, have well-posed formulations as boundary-value problems. Based on this approach, we developed a numerical method using a cut cell discretization of orography, and obtained results that compare very well with the classical gravity wave results presented in [10] . This splitting has been applied in [14] to obtain a method for which the time step can exceed by a substantial amount that obtained from the CFL condition imposed by the fastest gravity waves. Some of the further applications for this method include adaptive mesh refinement since the boundary-value problem for the component subproblems in the splitting are well-posed, and higher-order predictor-corrector step methods [26] because the different gravity modes are separated very cleanly. . Using Eqs. (25) and (33) op H ot ð183Þ. Formal linear analysis shows that the two right hand-side terms R Ã p H and R u are either quadratic in the perturbations or small because either the Mach number or the Froude number is small.. The idea is now to obtain a wave equation with variables x and t while averaging continuously the vertical variable z. First, differentiate Eq. (183) with respect to z,. where we have added and where dz ð191Þ . In this example, we use different domain sizes and different grid refinements to verify the asymptotics, as shown in Table 2 .. Figs. 7(a)-(c) show that we obtain a traveling wave solution for aspect ratios of 0.025 and under. Figs. 8 and 9(a) show that the decay in the amplitude of the solution and the amount of energy that gets transfered into the slow modes decrease as the aspect ratio decreases, as this means that the asymptotic assumptions are better verified. Fig. 9(b) shows that the convergence is first order. Fig. 7(d) shows that we are not quite in the asymptotics regime for e = 0.05. The traveling wave gets deformed at the beginning of the simulation on the left of the propagating front and then this deformed wave propagates. The decay in amplitude as the wave propagates is much larger than in the cases where we are in the asymptotic regime, and a much larger part of the motion gets transferred from the fastest mode to the slow modes.. However, it is to be noted that even when the asymptotic assumptions hold loosely (as is the case with e = 0.05), the percentage of the solution that gets transferred into the slow modes is under 4% for p H and under 6% for u d on a 128 · 64 grid. We also notice that the smaller e is, the closer the propagation velocity is to c 0 with a very good match for e = 0.0125 as seen in Fig. 8 .

O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Relationships between reading, tracing and writing skills in introductory programming This study analyzed student responses to an examination, after the students had completed one semester of instruction in programming. The performance of students on code tracing tasks correlated with their performance on code writing tasks. A correlation was also found between performance on "explain in plain English" tasks and code writing. A stepwise regression, with performance on code writing as the dependent variable, was used to construct a path diagram. The diagram suggests the possibility of a hierarchy of programming related tasks. Knowledge of programming constructs forms the bottom of the hierarchy, with "explain in English", Parson's puzzles, and the tracing of iterative code forming one or more intermediate levels in the hierarchy. The nineteen eighties was a period of extensive study of novice programmers. To name just two of the many studies from that time, Soloway et al. (1983) found that that only 38% of early computer programming students could write a program to calculate the average of a set of numbers, while Perkins and Martin (1989) reported that students had fragile knowledge of 1 Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ICER'08, September 6-7, 2008 basic programming concepts and a "shortfall in elementary problem-solving strategies". At the end of that decade, an entire volume of papers, "Studying the Novice Programmer" documented many of the difficulties of learning to program (Soloway and Spohrer, 1989 ).. At the turn of the millennium, an ITiCSE 2001 working group, the "McCracken Group", assessed the programming ability of a large set of students, from four universities across two countries (McCracken et al., 2001 ). Each student was required to write a program from a related set of program-writing tasks. Almost all students performed poorly on their task and many students did not even get close to finishing the task. The nature of the experiment did not allow the McCracken group to make firm conclusions as to why the students struggled, but they speculated that it was due to the students having a weak capacity to problem-solve. That is, as the McCracken group defined problem-solving, the students were weak at an iterative five step process: (1) Abstract the problem from its description, (2) Generate sub-problems, (3) Transform sub-problems into sub-solutions, (4) Re-compose, and (5) Evaluate and iterate.. At the ITiCSE 2004 conference held in Leeds, the only working group conducted that year (hence its name, the "Leeds Group") conducted an experiment designed to challenge the speculation that the results from the McCracken Group were due to students being weak in problem-solving (Lister et al., 2004) . The Leeds group studied student performance on programming-related tasks that did not require problem-solving. The students were required to answer several multiple choice questions. The questions were of two types, "fixed code" questions and "skeleton code" questions. In fixed code questions, students were given a piece of code and were required to identify the value in a variable after the given code had finished executing. Answering such a question requires a student to understand all the constructs in the code and also requires that they be able to systematically hand execute ("trace") through code. In skeleton-code questions, students were given a piece of code with one or two lines missing, they were also told what the code should do, and they were then required to identify the missing lines of code (as the question was multiple choice, the students did not have to write the lines, but merely identify the correct code among four options). While many students performed well on these questions, approximately 25% of the students performed at a level consistent with guessing. In the concluding remarks of their working group report (Lister et al., 2004) , the Leeds Group wrote:. "We accept that a student who scores well on the type of tests used in this study, but who cannot write novel code of similar complexity, is most likely suffering from a weakness in problem solving. This working group merely makes the observation that any research project that aims to study problem-solving skills in novice programmers must include a mechanism to screen for subjects weak in precursor, reading-related skills.". In this concluding remark, the Leeds group position the ability to read code (of a given complexity) as a precursor skill to the ability to write code (of a similar complexity). In positing the existence of such a precursor skill, the Leeds Group opened the possibility of there being a multi-level hierarchy of programming skills. The Leeds Group data already indicates two possible levels below code writing, since students were less successful at the skeletoncode questions in that study than the fixed code questions.. The BRACElet project has since built upon the results of the Leeds Group, by probing for intermediate levels in a hierarchy of programming-related skills . The initial research instrument designed by BRACElet members duplicated some of the Leeds Group fixed-code questions. The instrument also contained some other questions that were designed by a more systematic, theoretically grounded, approach than the ad hoc methods used by the Leeds Group. The revised Bloom's taxonomy (Anderson et al., 2001 ) and the SOLO taxonomy were used by BRACElet participants as a cognitive framework for assigning levels of difficulty to the tasks in the instrument (Whalley, Clear and Lister 2007; Whalley and Robbins 2007; Thompson et al. 2008) . From data collected in this initial BRACElet study, it was established that students did find the tasks from higher levels of the framework harder than those tasks assigned lower levels .. In this first BRACElet study, one of the tasks required students to "In plain English, explain what the following segment of Java code does". Student responses were analysed in terms of the SOLO taxonomy. It was found that some students responded with a correct, line-by-line description of the code (which is, in terms of SOLO, a multi-structural response) while other students responded with a correct summary of the overall computation performed by the code (which is, in terms of SOLO, a relational response). Furthermore, the better a student performed on other BRACElet tasks, the more likely the student was to give a relational response to the "explain in plain English" question. Also, when the same "explain in plain English" question was given to academics, they almost always offered a relational response. The BRACElet group ) concluded that the ability to read a piece of code and explain it in relation terms ─ that is, to see the forest and not just the trees ─ is an intermediate skill on the hierarchy of programming-related skills. Their conclusion is consistent with earlier literature on the psychology of programming (Adelson 1984 For most academics, an exam paper is an instrument for assigning grades to students. From a computing education research perspective, an exam paper is also a research instrument, an opportunity to study the knowledge, skills and learning of novices. In this paper we have used an exam paper as a research instrument to explore the concept of a hierarchy of programming-related skills. We found statistical evidence which is consistent with our prior intuition, and the prior literature, on the structure of such a hierarchy.. There were also unanticipated results in our analysis, such as indications that solving Parsons Puzzles might be a lower skill than tracing iterative code. However, there may be other characteristics of a task, apart from its nature, that determine its level of difficulty. As we (and we hope others) design and analyse future exams, such issues and anomalies will be resolved.. Are there limitations to using exams as a research instrument? For example, to better understand the relationship between "explain in plain English" tasks and code writing, perhaps we need to have each student complete 20 explanation tasks, and write 20 short pieces of code. That is not possible in an exam, given the short time length of an exam, and the need to test students on wide spectrum of knowledge and skills. But that raises an interesting conundrum at the nexus of teaching and research ─ if an exam is too short to be a valid instrument for researching students, can it then still be a valid instrument for grading students? With regard to the first two research questions addressed in this study:. • We found strong support for an association between code tracing and code writing skills, particularly when the tracing involved loops (i.e. Tracing2). The correlation between Tracing2 and Writing was 0.6267 (p<.01), accounting for 39% of the variability, with an adjusted R 2 of 38%.. • We found support for an association between code reading (i.e. "Explain in plain English") and code writing skills, with a correlation 0.5586 (p<.01) accounting for 31% of the variability, and an adjusted R 2 of 29%. In this section, we begin by setting out the results of the data screening process and then address the results of the research questions. The changes made to the procedures a posteriori are addressed under the appropriate research questions. In the previous section, the questions in the exam / research instrument were described in detail. The description included simple descriptive statistics indicating the distribution of students marks on each question and on each type of question. In this section, we present a more sophisticated statistical analysis, which examines the relationships between the exam questions, and which provides evidence (for or against) a hierarchy of programming-related skills.

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O