Patent Grant
7137104
1. Field of the Invention
This invention generally relates to the field of object-oriented programming and class hierarchies and more specifically to constructing software systems by composing the code associated with a set of class hierarchies into an executable system.
2. Description of Related Art
Class hierarchy composition aims at constructing software systems by composing the code associated with a set of class hierarchies into an executable system, or by weaving separately written aspects into a class hierarchy. See generally William Harrison and Harold Ossher, “Subject-Oriented Programming (A Critique Of Pure Objects)” In Proceedings of the Conference on Object-Oriented Programming Systems, Languages, and Applications, pages 411–428, 1993 and Gregor Kiczales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffrey Palm, and William G. Griswold. An overview of AspectJ, In Proc. 15th European Conf. on Object-Oriented Programming (ECOOP'01), Budapest, Hungary, June 2001. Advocates of composition argue that, by putting the functionality associated with each system feature in a separate hierarchy, a better separation of concerns is achieved, resulting in code that is easier to understand, maintain, and change.
Although considerable amounts of work have been devoted to developing specification formalisms for software composition, and on the methodological aspects of compositional software development, current techniques and tools for hierarchy composition operate on a purely syntactical basis and cannot provide any semantic guarantees about the behavior of the composed hierarchy. It is thus our aim to develop a semantically well-founded notion of composition that enables reasoning about the behavior of composed class hierarchies. Accordingly a need exists to overcome the shortcomings of the prior art systems and to provide a semantically well-founded notion of composition that enables reasoning about the behavior of composed class hierarchies.
Research on aspect-oriented software development has been gaining in popularity recently see for example Communications of the ACM. 44(10), October 2001, “Special Issue On Aspect-Oriented Programming.” In essence, the goal of this field is to obtain more extensible and reusable designs by distributing unrelated functionality over disjoint hierarchies or aspects. To achieve this, a mechanism for composing these functionalities into executable code is needed. In our setting, this is accomplished by composing hierarchies. Aspect-oriented languages such as AspectJ (see Gregor Kiczales, Erik Hilsdale, Jim Hugunin, Mik Kersten, Jeffrey Palm, and William G. Griswold, “An overview of AspectJ”, In Proc. 15th European Conf. on Object-Oriented Programming (ECOOP'01), Budapest, Hungary, June 2001) have language constructs that allow one to specify the conditions under which a piece of advice is “woven in” at a joint point. Until recently, there has been very little work on the semanticfoundations of composition
The work most closely related to ours is the Aspect Sandbox (ASB) project by Wand et al. (see Mitchell Wand, Gregor Kiczales, and Christopher Dutchyn, “A Semantics For Advice And Dynamic Join Points In Aspect-Oriented Programming”, October 2001), who incorporate several key aspect-oriented language constructs such as join points, pointcut designators, and advice into a simple language with procedures, classes, and objects. Wand et al. formalize the semantics of this language using a denotational semantices. Wand et al. do not provide any guarantees about the noninterference of aspects, nor do they determine the semantic impact of “weaving in” an aspect.
Ernst presented a class hierarchy composition system, where the composition operator is built into the syntax of the programming language gbeta. Explicitly specified compositions may trigger propagation of implicit compositions, for example an explicit combination of methods or classes may trigger implicit composition of other (e.g. auxiliary) methods or classes. Ernst showed that his composition system and propagation mechanism preserve static type correctness, but nothing is said about preservation of dynamic client behavior.
Our approach is similar in spirit to the work by Binkley et al. (see David Binkley, Susan Horwitz, and Thomas Reps “Program Integration For Languages With Procedure Calls”, ACM Transactions on Software Engineering and Methodology, pages 3–35, January 1995.) on the integration of C programs that are variations of a common base, by analyzing and merging their program dependence graphs. Similar to our work, Binkley et al. use an interference test, which is a sufficient criterion for noninterference. The main differences between Binkley et al. and our work is that Binkley et al. operates at the statement level, whereas our techniques operate on calling relationships between methods. Binkley et al. do not consider object-oriented language features.
Composition of object-oriented programs has been studied by other authors in the context of component-based systems. See Oscar Nierstrasz and Dennis Tsichritzis (ed.). “Object-Oriented Software Composition”, Prentice Hall, 1995. One approach is concerned with the dynamic interaction of concurrent objects, and the goal is to create new behavior as a composition of given behavior. Our approach aims to preserve old behavior while combining given behavior. Another line of research has investigated the composition of systems from components, where the components are treated as black boxes and come with some interface specification, usually in the form of a type system.
Briefly, in accordance with the present invention, disclosed is a system, method and computer readable medium for providing class hierarchy composition aims at constructing software systems by composing a set of class hierarchies into an executable system. Current composition algorithms cannot provide semantic guarantees. The present invention provides a composition algorithm, together with an interference criterion and its correctness proof, which guarantees that behavior of the original hierarchies is preserved for interference-free compositions. In case of interference, an impact analysis can determine the consequences of integration. The method is based on existing program analysis technology and is illustrated by various examples.
In one embodiment, a method is directed to composing two or more class hierarchies 1 and
2 with associated applications A1 and A2 respectively, resulting in at least one composed class hierarchy
3, and reporting a behavior of application A1 and application A2 when executing against
3, the method comprising:
The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the claims at the conclusion of the specification. The foregoing and other features and also the advantages of the invention will be apparent from the following detailed description taken in conjunction with the accompanying drawings. Additionally, the left-most digit of a reference number identifies the drawing in which the reference number first appears.
1⊕
2, according to the present invention.
1⊕
3, according to the present invention.
It should be understood that these embodiments are only examples of the many advantageous uses of the innovative teachings herein. In general, statements made in the specification of the present application do not necessarily limit any of the various claimed inventions. Moreover, some statements may apply to some inventive features but not to others. In general, unless otherwise indicated, singular elements may be in the plural and vice versa with no loss of generality. In the drawing like numerals refer to like parts through several views.
This patent is based in part on a paper entitled “Semantic-Based Composition of Class Hierarchies” with identical named authors, which will be presented on Jun. 10–14, 2002, at the ECOOP (European Conference On Object-Oriented Programming) in Málaga, Spain which is hereinto incorporated by reference in its entirety.
1 Introduction
Class hierarchy composition aims at constructing software systems by composing the code associated with a set of class hierarchies into an executable system, or by weaving separately written aspects into a class hierarchy. The present invention provides the following approach:
Hence, the present invention permits a developer to quickly determine if a proposed composition may result in behavioral changes, and-if so-report precisely which parts of the program may be affected. It should be understood that these techniques can be incorporate t in a system such as Hyper/J in the form of a tool that performs various sanity checks on compositions.
Turning now to 1 defines classes Course, Person, Student, and Professor, and provides functionality for enrolling students in courses, for associating professors with courses, and for professors to approve the graduation of students (method Professor.approveGraduation ( )). This latter operation requires the approval of the courses taken by a student, modeled using a method approveCourses( ). The details of approveCourses ( ), but one can easily imagine adding functionality for keeping track of a student's course load and grades which would be checked by the professor to base his decision on. Class Driver1 contains a small test driver that exercises the functionality of hierarchy
1.
Hierarchy 2 is concerned with employment and advisory relationships. A student can designate a professor as his/her advisor (method Student.setAdvisor( )), and a professor can hire a student as a teaching assistant using method Professor.hireAssistant( ). Class Driver2 exercises the functionality in this hierarchy.
Hierarchy 3 shows a slightly more elaborate model, where a distinction is made between (undergraduate) Students and PhDStudents. This impacts the approval of graduations, because PhDStudents are also required to produce a thesis of sufficient quality (modeled by method Professor. approvePhDThesis ( )). The details of this method are omitted but are understood by those of average skill in the art.
Let us now consider the composition of 1 and
2. These hierarchies are not disjoint, since they contain the same classes. However, since there are no “syntactic collisions” between members in
1 and
2 (i.e.,
1 and
2 do not contain methods with the same name and signatures (i.e., arguments of methods), but with different bodies), one can simply construct a hierarchy that contains the union of the classes in
1 and
2, where each class in the combined hierarchy contains the union of the methods/fields that occur in the corresponding class(es) in
1 and
2. The resulting hierarchy is shown in
What can be said about the behavior of 1⊕
2? In this case, our interference check guarantees that the behavior of the client applications of these hierarchies (modeled by Driver1.main ( ) and Driver2.main ( )) are unaffected by the composition. For this specific composition, we can even provide the stronger guarantee that the behavior of any client of
1 and
2 is preserved. As shown below, this is not always the case.
Now consider composing 1 and
3, which contain different methods Professor.approveGraduation ( ), an example of static interference. Method approveGraduation ( ) in
3 is “more general” than approveGraduation ( ) in
1. In constructing
1⊕H3 (see
3 should be preferred over that in
1. In this case, our techniques report dynamic interference, i.e., preservation of behavior for clients of the original hierarchies cannot be guaranteed. Impact analysis reports that Driver3.main ( ) is not affected by the composition, but that the behavior of Driver1.main ( ) may have changed.
Composition of Hierarchies
One of the first issues that arise when composing two class hierarchies is the question in which classes and methods in the input hierarchies correspond. The Hyper/J composition system (see Peri Tarr, Harold Ossher, William Harrison, and Stanley M. Sutton, Jr. “N Degrees Of Separation: Multi-Dimensional Separation Of Concerns”, In Proceedings of the 1999 International Conference on Software Engineering, pages 107–119, May 1999) relies on a specification language to express these correspondences. For example, one can specify “merge-by-name” compositions in which two classes in different input hierarchies are matched if they have the same name, and one can explicitly specify pairs of matching classes (with different names) using an “equate” construct. In order to simplify the presentation in this present invention, we will assume that classes are matched “by name” only. Compositions that are not name-based can be modeled using an additional preprocessing step in which classes and methods are renamed appropriately. In particular, manually established relations between entities in the two hierarchies are assumed to be modeled by appropriate renaming.
Class Hierarchies
Definition 1 defines the notion of a class hierarchy. To keep our definitions simple, we assume that fields and abstract methods have undefined bodies (body (m)=⊥), and that fields and abstract methods cannot have the same name.
Definition 1 (class hierarchy). A class hierarchy is a set of classes together with an inheritance relation:
=(C, ≦). For a class C∈C we also write C∈
. A class C∈
has a name and contains a set of members (according to this definition, members (C) does not contain inherited members that are declared in superclasses of C):C=(n, M), where name(C)=n, members(C)=M. A member m ∈ members(C) is characterized by its name, its signature and its body: m=(f, σ, B) where σ∈C*×C, where f is the name of the function, σ is the signatures of the function, and B is the body of the function. We will use namesig(m) to denote the combination <f, σ> that together uniquely identify a member within a class, and body(m) to denote the body B of member m.
Classes and Inheritance Relations in the Composed Hierarchy
Semantically sound composition requires that the original inheritance relations can be order-embedded into the composed hierarchy. That is, a relationship A instanceof B that holds in an input hierarchy should also hold in the composed hierarchy. In general, one cannot simply compute the union of the inheritance relations in the input hierarchies because the resulting hierarchy may contain cycles. We therefore use a well-known factorization technique that produces an acyclic hierarchy such as those taught by 4. B. A. Davey and H. A. Priestley. Entitled Introduction to Lattices and Order. Cambridge University Press 1990. This construction has the advantage that hierarchies can be composed even if there are cycles in the union of the original inheritance relations, which might sometimes be useful in practice.
Given two input hierarchies 1 and
2, their composition is denoted
1⊕
2. The construction of
1⊕
2 is given in Definition 2. This involves: creating a set of pairs of the form <class, hierarchy> (step 1), determining the “union” of the inheritance relations in the input hierarchies (assuming that classes are matched by name) (step 2), determining cycles in the transitive closure of these inheritance relations, and constructing a set of equivalence classes ε corresponding to these cycles (steps 3–5), creation of a class in the composed hierarchy for each equivalence class in ε (step 6), associating a name and a set of members (step 7) with each class, and creation of the inheritance relations in the composed hierarchy (step 8). The term “class” as in “equivalence class” is different form “class” as in “class hierarchy”; we use this “overloading” in order to be compatible with both mathematical and computer science conventions.
Definition 2 (hierarchy composition). Let 1=(C1,≦1) and
2=(C2,≦2) be two class hierarchies. Then,
1⊕
2=(C,≦), which is defined as follows:
The name function determines the name of the composed class from the names of the classes in equivalence class [C]ρ and will not be formally defined here (some examples will be given below). Note that the members of a composed class do not include inherited members from the original classes, but only members defined locally in the original classes. Different members operators will be presented for different kinds of compositions in Definitions 4 and 6 below.
Note that ≦′ is not necessarily transitive, hence the use of the closure operator. As usual, [x]ρ consists of all classes ρ-equivalent to x, and [x]ρ≦[y]ρx≦′y; we assume that ≦ is the smallest partial order satisfying the conditions from the definition. We will use ε to denote the set of all equivalence classes [<C,
>]ρ, for any <(C,
>∈S. Moreover, we define a partial order on εby: <C,
>≦′<C′,
′)>
[<C,
>]ρ≦[C′,
′]ρ. Intuitively, one can imagine this order as the directed acyclic graph of all strongly connected components of the union of the two input hierarchies.
In the hierarchy of 1>, <A,
2,>}, {<B,
1>}, {<C,
1>, <C,
2>}, {<D,
1>}, {<E,
1>}, {<F,
2,>}, {<G,
2>}}. Consequently, the following inheritance relations are constructed: B<A, F<A, C<F, G<F, D<C, E<C. Here, class names in the composed hierarchy are generated from the names of the classes in the corresponding equivalence sets (e.g., class A corresponds to {<A,
1>, <A,
2>}). Note that immediate subclass/superclass relations need not be preserved F is now between A and C.
For the slightly more interesting example of 1>, <A,
2>, <C,
1>, <C,
2>, <F,
2>}, {<B,
1>}, {<D,
1>}, {<E,
1>}, {<G,
2>}}. The composed hierarchy contains a class for each of these equivalence classes (for the purposes of this example, we assume that the name function constructs a class name by concatenating the names of elements in the equivalence class). There is an inheritance relation X<Y if the equivalence class corresponding to X contains a class x, and the equivalence class corresponding to Y contains a class y such that x inherits from y in one or both of the input hierarchies. For example, class B inherits from ACF because <B,
1< is part of equivalence class {<B,
1>}, <A,
1> is part of equivalence class {<A,
1>, <A,
2>, <C,
1>, <C,
2>, <F,
2>}, and class B inherits from class A in
1. Again, immediate subclass/superclass relations need not be preserved: some immediate relations (e.g., F<C) have been collapsed.
In case classes have been merged, new class names have been introduced as well (e.g. ACF in the above example). Thus any client code must be transferred accordingly: any occurrence of the old class name x must be replaced by name([x]ρ). In the example, any occurrence of class names A, C, or F in client code must be replaced by ACF.
A final issue to note is that the composed inheritance relation may contain multiple inheritance. This may cause problems in languages such as Java that do not support general multiple inheritance. We consider this issue to be outside the scope of this present invention, and plan to pursue an approach in which multiple inheritance is automatically transformed into delegation.
Basic Composition
In defining the set of members in the composed hierarchy, the question arises of what to do when two or more classes in an equivalence class [x]ρ define the same member. We will refer to such cases as static interference. The easiest approach of dealing with this issue is to simply disallow composition if static interference occurs. We will refer to this scenario as basic composition. As we shall see shortly, the absence of static interference does not guarantee preservation of behavior.
Definition 3 defines basic static interference. Note that it does allow situations where an equivalence class [x]ρ contains two elements <C1, 1> and <C1,
2> such that C1 and C2 each contain a member m, provided that (i) body(m)=⊥holds for at least one of these m's, or (ii) that the two m's have the same body.
Definition 3 (basic static interference). ε contains basic static interference if there is an equivalence class [x]ρ∈E such that for some <C1, >, <C2,
′>∈[x]ρ, C1≠C2, m1∈members (C1), m2∈members (C2), namesig(m1)=namesig (m2) we have that: body(m1)≠⊥, body(m2)≠⊥, and body(m1)≠body(m2).
Definition 4 defines the set of members in the composed hierarchy. Note that, in cases where the classes in an equivalence class contain multiple methods with the same name and signature, the unique method with a non-⊥ body is selected.
Definition 4 (members). Let E be free of basic static interference, and let [x]ρ∈ε be an equivalence class. Define:
The transitive closure of the inheritance relations in 1 and
2 of
1>}, S2={<Person,
1>}, S3={<Student,
1>, <Student,
2>}, S4={<Professor,
1>, <(Professor,
2>}, S5={<Driver1,
1>}, and S6={<Driver2,
2>}. Definition 3 states that there is basic static interference if an equivalence class S contains multiple methods with the same name but different bodies. Singleton equivalence classes such as S1, S2, S5, and S6 cannot give rise to interference because a class can contain only one method with a given name and signature. S3 and S4 do not give rise to interference either because Student and Professor in
1 and
2 do not contain conflicting methods. Hence, there is no basic static interference.
Consider composing the class hierarchies 1 and
3 of
1>, <Professor,
3>}. ε exhibits basic static interference because both elements of S contain a member Professor.approveGraduation(Student) and the bodies of these methods are different. Hence, basic composition cannot be applied to
1 and
3.
Overriding Composition
As shown in 2 is an “improved” or “generalized” version of a method in
1. To address such cases, we augment basic composition with a mechanism that allows one to express conditions such as “member B.m in
′ has precedence over member A.m in
”. This is captured by a precedence relation << containing elements <
, m1><<<
′, m2> indicating that method m2 of hierarchy
′ has precedence over method m1 of hierarchy
. Note that it may be the case that
,=
′. It is assumed that ‘<<’ is a partial order.
The static interference notion of Definition 3 only requires minor modifications to allow situations where an equivalence class contains two classes C1 and C2 originating from hierarchies 1 and
2, respectively, such that <
1, m1> and <
2, m2> are <<-ordered. Definition 5 shows the resulting definition.
Definition 5 (overriding static interference). ε contains overriding static interference w.r.t. ‘<<’ if there is an equivalence class [x]ρ∈ε such that for some <C1, >, <C2,
>∈[x]ρ, C1≠C2, m1∈members (C1), m2∈members (C2), and namesig (m1)=namesig(m2) we have that: body (m1)≠⊥, body (m2)≠⊥, body(m1)≠body(m2), (
, m1>
<
,′, m2>, and <
′, m2>
<
, m1>.
Definition 6 shows the members function for overriding compositions. In the sequel, we will often say “⊕
,2 is free of overriding syntactic interference” if it is obvious which ordering ‘<<’ is used.
Definition 6 (members). Let ε be free of overriding static interference w.r.t ‘<<’, and let [x]ρ∈ε be an equivalence class. Define:
Consider an overriding composition of hierarchies 1 and
3 of
1><<<Professor.approveGraduation (Student),
3>. Then, the set of equivalence classes ε constructed by Definition 2 is: S1={<Course,
1>}, S2={<Person,
1>}, S3={<Student,
1>}, S4={(Professor,
1>, <Professor,
3}, S5={<Driver1,
1>}, S6={<PhDStudent,
3>}, and S7={<Driver3,
3>}. Since singleton sets never give rise to interference, we only need to verify that S4 does not cause overriding static interference. This is the case because the only method that occurs in both Professor classes is approveGraduation( ), and these methods are <<-ordered. The composed hierarchy can now be constructed using Definition 6, and was shown earlier in
Type Correctness
A class hierarchy is type correct if: (1) any member access e.m( . . . ) refers to a declared member definition, and (2) for any assignment x=y, the type of x is a superclass of the type of y. As a first step towards providing semantic guarantees about the composed class hierarchy, we demonstrate that the composed hierarchy is type correct. Due to space limitations, we only demonstrate these properties for basic compositions. The arguments for overriding compositions are similar.
Definition 7 (type correctness). Let be a hierarchy.
Note that if TypeOf(1,2, o)=C, then by construction TypeOf(
1⊕
2, o) =class([C]ρ). As an example, consider
1, v)=A. Then, in
1⊕
2, v)=A and in
1⊕
2, v)=ACF. The latter case demonstrates that sometimes new class names are introduced, and member declarations must be changed accordingly. In particular, whenever name([C]ρ)≠name(C), all declarations containing class name C must be updated to reflect the new class name name([C]ρ). This will only happen if classes have been merged due to cycles in the transitive inheritance relations of the input hierarchies.
The following two lemmas show that assignments and member lookups in the composed hierarchy remain type correct. Note that this includes assignments due to parameter-passing in method calls, and implicit assignments to this-pointers.
Lemma 1 (assignment correctness). Let x=y be an assignment in 1,2. Then, this assignment is still type correct in
1⊕
2.
Proof. Without loss of generality, let x=y ε 1. Then, TypeOf (
1, x)≧1TypeOf(
1, y). By construction, TypeOf(
1⊕
2, x)=class([TypeOf (
1, x)]ρ)≧class([TypeOf (
1, y)]ρ)=TypeOf(
1⊕
2, y).
Lemma 2 (member access correctness). If 1 and
2 are type correct and with-out basic static interference, then StaticLookup(
1,2, TypeOf(
1,2, o), m), ≠⊥
StaticLookup(
1⊕
2, TypeOf(
1⊕
2, o), m)≠⊥
Proof. Without loss of generality, let C=TypeOf(1, o), and let D be the class which contains m′=StaticLookup(
1, TypeOf(
1, o), m) . Then, we have C≦1D, m∈members(D) and by construction m∈members(class([D]ρ)) as there is no static interference. Furthermore, class([C]ρ)≦class([D]ρ) and TypeOf(
1⊕
2, o)=class([C]ρ). m could also occur in a subclass of class([D]ρ) in
1⊕
2, but for class D′ which contains m″=StaticLookup(
1⊕
2, TypeOf(
1⊕
2, o), m), we have in any case that D′≦class ([D]ρ), hence StaticLookup(
1⊕
2, TypeOf (
1⊕
2, o), m)≠⊥.
Corollary 1. For hierarchies 1 and
2 without static interference,
1⊕
2is type correct.
Dynamic Interference
Even basic composition (which makes the strongest assumptions about static noninterference) does not guarantee preservation of client behavior. This can be seen in the basic composition of
However, H1⊕H2 contains an overriding definition of foo( ) in class B, hence the call to foo( ) in C. main( ) binds to B.foo( ) instead of A.foo( ) as it did in 1. Hence, behavior of
1's client C.main( ) is not preserved.
1, A.foo( )><<<
2, A. foo( )>) that is free of overriding static interference. However, in the composed hierarchy, variable x is bound to a B-object instead of an A-object. Thus, the call x.bar( ) suddenly resolves to B.bar( ) instead of A.bar( ) as in
1.
Dynamic Interference
The term dynamic interference is used to refer to run-time behavioral changes such as the ones in the above examples. Some additional definitions are required to make this notion precise. To this end, we will use an operational semantics, where the effect of statement execution is described as a state transformation.
Definition 8 (state, state transformation).
Details of Var and Value are left unspecified, as they are not important for our purposes. (See Java subsets, Atshushi Igarashi, Benjamin Pierce, and Philip Wadler, “Featherweight Java: A minimal core calculus for Java” and GJ, In Proc. SIGPLAN/Conference an Object-Oriented Program-min, Systems, Languages and Applications (OOPSLA'99), pages 132–146, ACM, November 1999 and 12. Tobias Nipkow and David von Oheimb. “Java light is type safe—definitely”, In Proc. SIG-PLAN/SIGACT Symposium on Principles of Program Languages (POPL'98), pages 161–170. ACM, January 1998). Var includes local variables, parameters, and this-pointers in method invocation stack frames—note that the domain of Var may change as execution proceeds. Value comprises primitive values (e.g., integers) and objects in the heap. In order to model reference-typed fields, we assume that Var also contains an element for each field f of an object o, where o is an object in Value whose type contains a field f (either directly or through inheritance).
Now let us assume that we have a hierarchy together with some client code K which is type correct with respect to
. We define:
Definition 9 (execution sequence).
Definition 10 states that two hierarchies and
′ are behaviorally equivalent if the same sequence of statements is executed using the two hierarchies, for all given clients of
with appropriate inputs and initial states. Definition 11 states that a composed hierarchy
1⊕
2 exhibits dynamic interference if
1 and
1⊕
2 are not behaviorally equivalent (for some client of
1 with associated input and initial state), or if
2 and
1⊕
2 are not behaviorally equivalent (for some client of
2 with associated input and initial state).
Definition 10 (behavioral equivalence). Two hierarchies ,
′ are behaviorally equivalent if for all clients K of
with appropriate inputs and initial states I, σ0 we have that E(
, K, I, σ0)=E(
′, K, I, σ).
Definition 11 (dynamic interference). 1⊕
2 contains dynamic interference, if (for some
1-client K with associated I, σ0)
1 and
1⊕
2 are not behaviorally equivalent, or if (for some
2-client K with associated I, σ0)
2 and
1⊕
2 are not behaviorally equivalent.
Remark. From an observational point of view, E(1, K, I, σ0)=E(
1,
2, K, I, σ0) is not a necessary condition for behavioral equivalence, because a modified sequence of statements might still produce the same visible effects. However, we are not interested in cases where the observable behavior of a client of a composed hierarchy is accidentally identical to its original behavior.
Checking for Dynamic Interference
We would like to verify whether or not a certain composition exhibits dynamic interference. In general, determining whether or not two arbitrary programs will execute the same statement sequences for all possible inputs is undecidable of course. However, for the compositions studied in this present invention, the situation is not hopeless. Our approach will be to develop a noninterference criterion that implies E(1, K, I, σ0)=E(
1⊕
2, K, I, σ0) that is based on static analysis information. This approach is also used in our earlier work on semantics-preserving class hierarchy transformations see generally G. Snelting and F. Tip. “Understanding Class Hierarchies Using Concept Analysis” ACM Trans. on Programming Languages and Systems, pages 540–582, May 2000 and Gregor Snelting and Frank Tip “Reengineering class hierarchies using concept analysis” In Proc. ACM SIGSOFT Symposium on the Foundations of Software Engineering, pages 99–110, Orlando, Fla., November 1998. Being a sufficient, but not a necessary condition, our criterion may occasionally generate false alarms. However, we believe that the impact analysis of Section 4 will provide the user with sufficient information to determine whether reported interferences can occur in practice.
Definition 12 defines a function srcHierarchy that defines the class hierarchy that a program construct originated from. The srcHierarchy of an object is defined as the srcHierarchy of the statement that created it. Definition 13 uses srcHierarchy to define the projection of a state onto a hierarchy.
Definition 12 (srcHierarchy). For =(C, ≦), C=<c, M>∈
, m∈M and a statement s in body (m), we write srcHierarchy(C)=srcHierarchy(m)=srcHierarchy(s)=
. Moreover, let s≡new C( . . . ) be an object creation site, and let object o∈Value be an instance of C created by s at run-time. Then, srcHierarchy (o)=srcHierarchy (s). Further, for any x∈Var, we define srcHierarchy(x)=srcHierarchy(s), where s is the static program part responsible for the creation of x at run-time.
Definition 13 (state projection). The projection of a program state σ onto a hierarchy is defined as σ|
={x
v|x
v∈σ, srcHierarchy(x)=
}. Moreover, we extend the projection operator to apply to a sequence of program states as follows:
Σ(1⊕
2, K, I, σ0)|
1=σ0|
1→σ1|
1→σ2|
1→ . . . , where Σ(
1
2, K, I, σ0)=σ0→σ1→σ2→
The noninterference criterion relies on information produced by a points-to analysis. A points-to analysis computes for each reference-typed variable the set of objects that it may point to. Definitions 14 and 15 define appropriate notions ObjectRefs of object references and Objects of objects.
Definition 14 (object reference). Let be a hierarchy. Then, ObjectRefs (
)
Var is the set of all object references in
. This includes class-typed local variables, method parameters, fields, static variables, and this pointers of methods.
Definition 15 (object). Let be a hierarchy. Then, Objects(
) is the set of all object creation sites in
, that is, all statements S≡new C( . . . ); occurring in some method body. Moreover, for o∈Objects(
), o≡new C( . . . ), we define TypeOf (
, o)=C.
Object creation sites in Objects() should not be confused with run-time objects in Value. Finally, Definition 16 formalizes the notion of points-to sets. We do not make any assumptions about the specific algorithm used to compute these points-to sets. Any method suitable for object-orientated languages will do such as Donglin Liang, Maikel Pennings, and Mary Jean Harrold Extending and evaluating flow-insenstitive and context-insensitive points-to analyses for java. In Proc. ACM SIG-PLAN/SIGSOFT Workshop on Program Analysis for Software Tools and Engineering (PASTE'01, pages 73–79, Snowbird, Utah, 2001 and Atanas Rountev, Ana Milanova, and Barbara G. Ryder. Points-to analysis for java using annotated constraints. In Proc. ACM SIGPLAN Conf. on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA'01), Tampa, Fla., 2001.
Definition 16 (points-to sets). Let be a hierarchy, and let p∈ObjectRefs (
). Then PointsTo(
, p)
Objects (
) is the set of all objects (represented by creation sites) that object reference p might point to at run-time.
The noninterference criterion (Definition 17) states that the method invoked by a virtual method call p.m( . . . ) (as determined by applying StaticLookup on the receiver object) in 1⊕
2 is the same as it was in
1. Note that the condition does not say anything about
2 objects. While the points-to sets in the composed hierarchy may also contain
2 objects, these objects are never created by clients of
1, and therefore need not be considered.
Definition 17 (noninterference criterion).
A composition 1⊕
2 meets the noninterference criterion if for all p∈ObjectRefs (
1), for all method calls p.m( . . . ) in
1, and for all o∈PointsTo(
1
2, p) ∩ Objects (
1) we have that StaticLookup(
1, T, m)=StaticLookup(
1⊕
2, T′, m) where T=TypeOf (
1, o), and T′=TypeOf(
1⊕
2, o).
The use of points-to information deserves a few more comments. First, one might wonder about the consequences of using imprecise points-to information (i.e., overly large points-to sets). In this case, the “for all o” in the noninterference criterion runs over a larger scope than necessary, making the criterion stronger than necessary, and spurious interference may be reported. However, the criterion is safe in the sense that it will never erroneously report non-interference.
Note also that the criterion is much more precise than the static checks from Section 2. To see this, consider again the examples of
StaticLookup(1⊕
2, T, m)=StaticLookup(
1, T′, m)
is limited by the size of the points-to set associated with the receiver of the method call. This effectively restricts the condition to method calls that are actually reachable, and to many fewer spurious interferences being reported.
Most points-to analysis algorithms compute information that is valid for a specific client K This has the advantage that the points-to sets are more precise, reducing the number of false alarms. However, in this case the noninterference criterion only holds for the client K. To compute results that are safe for any client, one could employ algorithms such as Atanas Rountev, Barbara G. Ryder, and William Landi, “Data-flow analysis of program fragments” In Proceedings of Symposium on the Foundations of Software Engineering (FSE 1999), pages 235–252, Toulouse, France, 1999 that are capable of analyzing incomplete programs.
Concerning the complexity of the interference test, it is dominated by the computation of points-to information, as the test itself just performs two static lookups per member access, which is linear in the program size. Various points-to algorithms of various precisions are known, ranging from Steengaard's almost linear algorithm (which scales millions of LOC) to Andersen's cubic algorithm which has recently been scaled to a million-line C-program by using a new approach for dynamically computing transitive closures. The performance of this algorithm on object-oriented applications are still unknown, as far as we know.
Justification
We will now demonstrate that the noninterference criterion of Definition 17 ensures that the behavior of client K of 1 is preserved. The analogous argument for
2 is completely symmetrical.
Lemma 3 states that it is sufficient to demonstrate that the sequence of call targets in 1 does not change after composition.
Lemma 3. For all K, I and σ0, we have that: T(1, K, I, σ0)=T(
1⊕
2, K, I, σ0)
E(
1, K, I, σ0)=E(
1⊕
2, K, I, σ0) and therefore: T(
1, K, I, σ0)=T (
1⊕
2, K, I, σ0)
Σ(
1, K, I, σ0)=Σ(
1⊕
2, K, I, σ0)|
1
Proof. The proof is by induction on the length n of sequence E(1, K, I, σ0). For n=0, the statement is trivial, as both hierarchies start in state σ0. Now consider statement Sn in E(
1, K, I, σ0). By induction, the previously executed statements S1, S2, . . . Sn-1 are the same in both E(
1, K, I, σ0) and E(
1⊕
2, K, I, σ0), and lead to corresponding states σn-1 and σn-1|
1, respectively.
Now, Snis a statement at some position π in some method m1 of 1. By assumption, the sequence of executed method bodies is the same in
1⊕
2. Since there is no static interference, we may conclude that we are at the same position π in some method m2 in
1⊕
2, for which body(m1)=body(m2). Hence, Sn is also the next statement to be executed in E(
1⊕
2, K, I, σ0).
Now there are two cases. 1) Sn is a method call p.m( . . . ). Then, by assumption, this call resolves to the same target tv| which is executed in the same state σn-1. Thus, after execution of the method body, both hierarchies are in the same state σn at the same position π′ in the same method bodies m1 and m2.) Sn is not a method call. Then, it must be the same in m1 and m2 due to the absence of static interference. Hence, after execution, the same state σn is reached.
Theorem 1 (correctness of criterion). Let 1⊕
2 be a composition that meets the noninterference criterion of Definition 17. Then, we have that: E(
1, K, I, σ0)=E(
1⊕
2, K, I, σ0) and Σ(
1, K, I, σ0)=Σ(
1⊕
2, K, I, σ0)|
1, for all K, I, σ0.
Proof. Again the proof is by induction on n. For n=0 the statement is trivial, as both hierarchies start in state σ0. Now consider statement Sn in E(1, K, I, σ0). By induction, the previously executed statements S1, S2, . . . Sn-1 are the same in both E(
1, K, I, σ0) and E(
1⊕
2, K, I, σ0) and lead to corresponding states σn-1 and σn-1|
1, respectively. As in the previous lemma, we may conclude that Sn is the same in both execution sequences. (This time the necessary fact that the previous call targets have been the same is not by assumption, but by induction: if S1, S2, . . . are the same in both E(
1, K, I, σ0) and E(
1⊕
2, K, I, σ0), so are S1, S2, . . . and tv1, tv2, . . . ).
Now there are two cases. If Sn is not a method call or data member access, we may conclude that the corresponding states σn and σn|1 are produced in Σ(
1, K, I, σ0) and Σ(
1⊕
2, K, I, σ0)|
1, respectively. In case Sn=p.m(x), we know σn-1(p)∈PointsTo(
1⊕
2, p) (remember that σn-1 was reached in both
1 and
1⊕
2). Furthermore, σn-1(p)∈Objects (
1), as σn-1|
1∈Σ(
1, K, I, σ0), and
1 does not contain
2 objects.
We know StaticLooku (1, TypeOf(
1,o), m)≠⊥ and by the type correctness lemma thus StaticLookup(
1⊕
2, TypeOf(
1⊕
2, o), m)≠⊥. By the static noninterference criterion, both static lookups must compute the same result, namely method definition (resp. data member) m. After execution of m's body (resp. access to m's value in state σn-1), we may as in the above lemma conclude that execution of both hierarchies is in the same state σn.
For the example of 1, o)=PointsTo(
1⊕
2, o)={B1}. For the method call o.foo( ), we obtain StaticLookup (
1, TypeOf(
1,B1), foo( ))=StaticLookup (
1, B, foo( ))=A.foo( ), but StaticLookup(
1⊕
2,TypeOf(
1⊕
2, B1), foo( ))=StaticLookup(
1⊕
2, B, foo( ))=B.foo( ). Hence, dynamic interference is reported.
In Example 7 and in subsequent examples, we use the labels shown in boxes in
For client Driver1.main( ) in 1⊕
2, c1) ∩Objects(
1)={C1}, PointsTo(
1⊕
2, p1) ∩Objects(
1)={P1}. Hence, StaticLookup(
1, TypeOf(
1, C1), enroll( ))=Course.enroll( )=StaticLookup(
1⊕
2, TypeOf(
1⊕
2, C1), enroll( )). Moreover, we have that StaticLookup(
1, TypeOf(
1, C1), assign( ))=Course.assign( )=StaticLookup(
1⊕
2, TypeOf(
1⊕
2, C1), assign( )), and that StaticLookup(
1,TypeOf(
1, P1), approveGraduationo)=Professor.approveGraduation( )=StaticLookup(
1⊕
2,TypeOf(
1⊕
2, P1), Professor.approveGraduation( )). Similar arguments can be made for all other method calls in
1 is preserved in
1⊕
2. In fact, the basic composition in
1, PointsTo(
1⊕
2, p) ∩ Objects(
1) contains all allocation sites S∈Objects(
1) where TypeOf(
1⊕
2, S)≦TypeOf(
1⊕
2, P). Nevertheless, StaticLookup(
1, TypeOf(
1, S), m)=StaticLookup(
1⊕
2, TypeOf(
1⊕
2, S), m), because in the example the methods from
1 and
2 are either disjoint or identical.
Overriding Compositions
The noninterference criterion was designed for basic compositions. It can be applied to overriding compositions as well, but will report failure as soon as a method call p.m( . . . ) resolves to methods that have different bodies in 1 and
1⊕
2. Nevertheless, interference checks may still succeed if the overridden methods are not reachable from client code. Constructing an interference check for overriding compositions that ignores conflicts that users are aware of (via the <<-ordering) is a topic for future research.
Let us apply the criterion to 1, a)=PointsTo(
1⊕
2, a)={B1}, but due to the overriding, StaticLookup(
1, TypeOf(
1, B1), foo)=A.foo( )
1≠A.foo( )
2=StaticLookup (
1⊕
2, TypeOf(
1⊕
2, B1), foo( )). Here, we use subscripts
1 and
2 to indicate the hierarchies that the different methods A.foo( ) originate from. Hence, the behavior of call a.foo( ) is not preserved. For call x.bar( ), we obtain PointsTo(
1⊕
2, x)={B2}, hence PointsTo(
1⊕
2, x) ∩ Objects(
1)=Ø Thus the criterion is trivially satisfied for x.bar( ).
Remark: In Example 8, one might wonder why the criterion is satisfied for x.bar( ) despite the fact that the behavior of this call obviously changed: We have that B.bar( ) is called in 1⊕
2 whereas A.bar( ) was called in
1. This secondary behavioral change is caused by another change in behavior (in this case, the changed behavior of call a.foo( ), which causes x to be bound to an object of type B). While the noninterference criterion does not necessarily detect secondary behavioral changes, it does find all primary changes, which suffices to guarantee behavioral equivalence. We plan to use impact analysis to obtain a more precise understanding of where behavioral changes occur, as will be discussed in Section 4.
Impact Analysis
When the purpose of composition is to add functionality that is not completely orthogonal to the system's existing functionality, changes in behavior are often unavoidable. The interference check of Section 3 determines whether the behavior of a specific client K is affected. In principle, one could manually apply the interference check to successively smaller clients to determine the impact of the composition. However, such a non-automated process would be tedious and labor-intensive, and problematic in cases where it is not possible to partition the code in K In order to provide a less labor-intensive approach, we plan to adapt the change impact analysis of Barbara, G. Ryder and Frank Tip. Change impact analysis for object-oriented programs. In Proceedings of the ACM SIGPLAN-SIGSOFT Workshop on Program Analysis for Software Tools and Engineering (PASTE'01), pages 46–53, Snowbird, Utah. June 2001 in order to automatically determine the set of program constructs affected by a composition. The remainder of this section presents some preliminary ideas on how this can be accomplished.
Change Impact Analysis
We begin with a brief review of the change impact analysis. In this work, it is assumed that a program is covered by a set of regression test drivers T=t1, . . . , tn. Each test driver is assumed to consist of a separate main routine from which methods in the application are called. Prior to the editing session, a call graph Gi is built for each t1. Any of several existing call graph construction algorithms can be used. We plan to employ an algorithm that has been demonstrated to scale to large applications see generally Frank Tip and Jens Palsberg, “Scalable Propagation-Based Call Graph Construction Algorithms”, In Proc. ACM SIGPLAN Conf. on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA'00), pages 281–293, Minneapolis, Minn., 2000. SIGPLAN Notices 35(10).
After the user has ended the editing session, the edits are decomposed into a set A of atomic changes. A consists of (i) a set AC of (empty) classes that have been added, (ii) a set DC of classes that have been deleted, (iii) a set AM of methods that have been added, (iv) a set DM of methods that have been deleted, (v) a set CM of methods whose body contains one or more changed statements, (vi) a set AF of fields that have been added,(vii) a set DF of fields that have been deleted, and (viii) a set LC of elements of the form <T, C.m( )>, indicating that the dispatch behavior for a call to C.m( ) on an object type T has changed. In general, a simple user edit can imply several atomic changes. For example, addition of a method may involve the addition of an empty method (in AM), a change in dispatch behavior (in LC) of existing call sites in cases where the added method overrides an existing method, and a change of a method body (in CM).
By analyzing the call graphs Gi and the set of atomic changes A, a subset of affected tests T′T is determined.
Any test driver that is not in T′ is guaranteed to have the same behavior as before. If a test driver ti occurs in T, the user can run this test to determine if the new behavior of the test meets his expectations. If this is not the case, an additional analysis (also based on call graphs) determines a subset of atomic changes A′A that contribute to ti's altered behavior. The user can apply successively larger subsets of A′ to identify the change that “broke” test driver ti. Alternatively, divide-and-conquer strategies can be applied to quickly narrow down the search space such as Andreas Zeller “Yesterday my program worked. Today, it does not. Why?” In Proc. of the 7th European Software Engineering Conf./7th ACM SIGSOFT Symp. on the Foundations of Software Engineering (ESEC/FSE'99), pages 253–267, Toulouse, France, 1999.
Impact Analysis for Composition
We adapt the analysis to determine the impact of a composition 1⊕
2 on a set of test drivers T=t1, ,tk associated with hierarchy Hi by interpreting a composition as a set of changes w.r.t
i such as Barbara G. Ryder and Frank Tip. Change impact analysis for object-oriented programs such as In Proceedings of the ACM SIGPLAN-SIGSOFT Workshop on Program Analysis for Software Tools and Engineering (PASTE'01), pages 46–53, Snowbird, Utah. June 2001. To do so, we need to establish a relationship between classes/members in
1⊕
2, and the classes/members in
1 and
2 that these classes/members originate from. This is expressed by Definition 18 below.
Definition 18 (origin). Let 1=(C1,≦1) and
2=(C2,≦2) be two class hierarchies, let
=
1⊕
2=(C, ≦), and let ε be the set of equivalence classes constructed by Definition 2. Furthermore, let C be a class in C, and let m∈members (C).
Define:
Definition 18 defines the origin of a class C in C as the set of (class,hierarchy) pairs in its equivalence class, and the origin of a method m in C is the set of methods in each such class with the same name and body as m. Note that these definitions work with both of the members definitions given earlier.
For hierarchy =
1⊕
3 of
1>, <Professor,
3>} and origin(Professor.approveGraduation)={<Professor, approveGraduation,
3>}.
It is now straightforward to construct the sets of atomic changes w.r.t. one of the original hierarchies. For example, for the composition =
1⊕
3, where
=<C,≦>,
1=<C1,≦1>, and
3=<C4,≦4>, the sets AC and CM w.r.t.
1 may be computed as:
The other sets of atomic changes are computed similarly. We can now apply the analysis to determine the impact of the composition.
Consider the overriding composition of 1⊕
3, as a set of changes w.r.t.
1, we find that Driver1.main( ) is affected, because CM contains method Professor.approveGraduation( ), which occurs in the call graph for Driver1.main( ). Moreover, interpreting
1⊕
3 as a set of changes w.r.t.
3, we find that Driver3.main( ) is not affected, because the call graph for Driver3.main( ) does not contain any added, changed, or deleted methods, or any edges corresponding to a changed dispatch behavior.
Thus far, we have computed the impact of a composition on a set of test drivers. In order to obtain more fine-grained information, one could construct a separate call graph for each method m in hierarchy 1 (using appropriate conservative assumptions about the run-time types of parameters and accessed fields), and proceed as before. Then, impact could be reported as the set of methods whose behavior might have changed. For example, if separate call graphs are constructed for all methods of
1 in the overriding composition
⊕
3 of
Related work
We already discussed how our impact analysis is a derivative of the change impact analysis (see Barbara G. Ryder and Frank Tip. Change impact analysis for object-oriented programs. In Proceedings of the ACM SIGPLAN-SIGSOFT Workshop on Program Analysis for Software Tools and Engineering (PASTE'01), pages 46–53, Snowbird, Utah., June 2001). Offutt and Li (see Michelle L. Lee, “Change Impact Analysis Of Object-Oriented Software”, PhD thesis, George Mason University, 1998 and Michelle L. Lee and A. Jefferson Offutt, “Algorithmic Analysis Of The Impact Of Changes To Object-Oriented Software”, in IEEE International Conference on Software Maintenance, pages 171–184, Monterey, Calif., November 1996) also presented a change impact analysis for object oriented programs, which only relies on structural relationships between classes and members (e.g., containment), and is therefore much less precise than approaches such as Barbara G. Ryder and Frank Tip, “Change Impact Analysis For Object-Oriented Programs”, in Proceedings of the ACM SIGPLAN-SIGSOFT Workshop on Program Analysis for Software Tools and Engineering (PASTE'01), pages 46–53, Snowbird, Utah., June 2001 that rely on static analysis.
Exemplary Implementations
The present invention can be realized in hardware, software, or a combination of hardware and software. A system according to a preferred embodiment of the present invention can be realized in a centralized fashion in one computer system, or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system—or other apparatus adapted for carrying out the methods described herein—is suited. A typical combination of hardware and software could be a general-purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein.
An embodiment of the present invention can also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which—when loaded in a computer system—is able to carry out these methods. Computer program means or computer program in the present context mean any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following a) conversion to another language, code or, notation; and b) reproduction in a different material form.
A computer system may include, inter alia, one or more computers and at least a computer readable medium, allowing a computer system, to read data, instructions, messages or message packets, and other computer readable information from the computer readable medium. The computer readable medium may include non-volatile memory, such as ROM, Flash memory, Disk drive memory, CD-ROM, and other permanent storage. Additionally, a computer readable medium may include, for example, volatile storage such as RAM, buffers, cache memory, and network circuits. Furthermore, the computer readable medium may comprise computer readable information in a transitory state medium such as a network link and/or a network interface, including a wired network or a wireless network, that allow a computer system to read such computer readable information.
The computer system can include a display interface 808 that forwards graphics, text, and other data from the communication infrastructure 802 (or from a frame buffer not shown) for display on the display unit 810. The computer system also includes a main memory 806, preferably random access memory (RAM), and may also include a secondary memory 812. The secondary memory 812 may include, for example, a hard disk drive 814 and/or a removable storage drive 816, representing a floppy disk drive, a magnetic tape drive, an optical disk drive, etc. The removable storage drive 816 reads from and/or writes to a removable storage unit 818 in a manner well known to those having ordinary skill in the art. Removable storage unit 818, represents a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive 816. As will be appreciated, the removable storage unit 818 includes a computer usable storage medium having stored therein computer software and/or data.
In alternative embodiments, the secondary memory 812 may include other similar means for allowing computer programs or other instructions to be loaded into the computer system. Such means may include, for example, a removable storage unit 822 and an interface 820. Examples of such may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units 822 and interfaces 820 which allow software and data to be transferred from the removable storage unit 822 to the computer system.
The computer system may also include a communications interface 824. Communications interface 824 allows software and data to be transferred between the computer system and external devices. Examples of communications interface 824 may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, etc. Software and data transferred via communications interface 824 are in the form of signals which may be, for example, electronic, electromagnetic, optical, or other signals capable of being received by communications interface 824. These signals are provided to communications interface 824 via a communications path (i.e., channel) 826. This channel 826 carries signals and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link, and/or other communications channels.
In this document, the terms “computer program medium,” “computer usable medium,” and “computer readable medium” are used to generally refer to media such as main memory 806 and secondary memory 812, removable storage drive 816, a hard disk installed in hard disk drive 814, and signals. These computer program products are means for providing software to the computer system. The computer readable medium allows the computer system to read data, instructions, messages or message packets, and other computer readable information from the computer readable medium. The computer readable medium, for example, may include non-volatile memory, such as Floppy, ROM, Flash memory, Disk drive memory, CD-ROM, and other permanent storage. It is useful, for example, for transporting information, such as data and computer instructions, between computer systems. Furthermore, the computer readable medium may comprise computer readable information in a transitory state medium such as a network link and/or a network interface, including a wired network or a wireless network, that allow a computer to read such computer readable information.
Computer programs (also called computer control logic) are stored in main memory 806 and/or secondary memory 812. Computer programs may also be received via communications interface 824. Such computer programs, when executed, enable the computer system to perform the features of the present invention as discussed herein. In particular, the computer programs, when executed, enable the processor 804 to perform the features of the computer system. Accordingly, such computer programs represent controllers of the computer system.
The present invention can be implemented as an application 808 such as a tool kit as part of a compiler such as IBM VisualAge™ line of products or IBM WebSphere™ those available from Borland or Microsoft and programming environments Eclipse or other open source platforms (www.eclipse.org). In another embodiment, the present invention is implemented as part of a compiler and messages are presented to a user during the reporting of behavior differences during the class compositions.
It is important to note, that any behavioral difference of methods and/or fields as compared application A1 as executing against composed hierarchy 3 with application A1 as executing against the composed hierarchy
1.(and similarly with A2) can be formed into a report. In one embodiment this report is editable with interactive tools such as browsers and editors and portions of the program text that have behavior differences are marked or highlighted for user review.
It should be understood by those skilled in the art that the present invention provided a basis to provide better semantic support for composition-based software development. The present invention provides the basis for other work that includes:
Although specific embodiments of the invention have been disclosed, those having ordinary skill in the art will understand that changes can be made to the specific embodiments without departing from the spirit and scope of the invention. The scope of the invention is not to be restricted, therefore, to the specific embodiments. Furthermore, it is intended that the appended claims cover any and all such applications, modifications, and embodiments within the scope of the present invention.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5546584 | Lundin et al. | Aug 1996 | A |
| 5615333 | Juettner et al. | Mar 1997 | A |
| 5983020 | Sweeney et al. | Nov 1999 | A |
| 6142684 | Kirshenbaum et al. | Nov 2000 | A |
| 6179491 | Choi et al. | Jan 2001 | B1 |
| 6230314 | Sweeney et al. | May 2001 | B1 |
| 6275976 | Scandura | Aug 2001 | B1 |
| 6467086 | Kiczales et al. | Oct 2002 | B1 |
| 6480856 | McDonald et al. | Nov 2002 | B1 |
| 20040015822 | Linton et al. | Jan 2004 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20030221182 A1 | Nov 2003 | US |
