The impact dependency properties english language essay

CHAPTER 3

3. 1 Introduction

This chapter deals with the object-oriented concepts of impact analysis perspective and presents an overview of the various entities considered in this research. It starts by identifying the components of analysis in our research, their relationship types, properties that govern impact dependency and the various dependency types of an object-oriented system. It then progresses to the categorization of the various code change types applicable to object-oriented at the class and members level. Furthermore, the chapter discusses ways of analyzing dependency with class methods as well as the impact model of our research.

3. 1. 1 Change Impact Viewpoints

In object-oriented programming, classes and objects are the basic building blocks just like functions and procedures are for a function-oriented programming. An object interacts with another basically by sending a message to the object to perform some service it provides. Hence, messaging is what ties an object-oriented (OO) system together. Objects are entities that encapsulate two members: data (class field) and action (class method) members. The data member defines the state of the object, while the method member defines the allowable operations on the object’s private data. For an object, the defined operations together specify the behavior of the object. In this research, class member shall be referred to either a data or method member. Accordingly, when a class or class member changes, it could impact other classes through message passing, inheritance from an impact analysis viewpoint. In object-oriented software (OOS), class methods and fields are usually the entities at the granularity level that is important to our analysis.

3. 1. 2 Basic Component Types

A class constitutes the basic entity of our analysis, which is a general definition of a kind of an object. In this research, a system is viewed as a set of classes connected by different links. A class on the other hand, defines possible sets of objects; methods and data. Thus, a component is referred to as class, method, or field. The relationships these components are shown in Figure 1. When a change is considered, it is important to identify the system components that will be impacted by the change. The affected components are specified through the analysis of the system based on the change proposal and the unaffected components are ignored. The rationale is to ensure that only the components truly affected by the change are modified and that the system will still run correctly after change implementation. Therefore, our focal point is on how the system’s components relate with one another, their reacts to a change and which components are affected by a change. Figure 1: Component Relationships

3. 1. 3 Relationship Type

In OOS system, classes do not exist in a vacuum. They interact with one another using different types of relationships. Relationships between classes come in different strengths and are critical to effective impact analysis. The strength of a class relationship indicates how dependent the classes involved in the relationship are on each other. Thus, changes to one class may likely affect the other class or classes. However, understanding the relationships between classes is challenging since it encode much of the complexity which in turn affects change impact results in different ways. There are different relationships among classes which can either be direct or indirect [1]. (See Figure 1)

A. Direct Relationship

As shown in Figure xxx, let consider two classes X and Y of a software system. We say, there is a direct relationship R between class X and Y (XRY) if X and Y have one of the following relationships types: Containment, Use, Invocation or Inheritance. (See Figure 1) They are defined as follows: 1. Containment Relationship: Class X aggregates or contains class Y if Y is declared as a class member of X. This implies that the definition of a class X implies objects of another class Y, thereby suggesting some kind of a whole–part relationship between X and Y. 2. Use Relationship: Class X uses class Y if Class X contains Class Y or Class X send message to Class Y. Use relationship can be formed in several ways [1]: i. Containment: If class X contains class Y, it implies that class X uses Class Y. Also, if X contains Y via reference, it implies that X contains a reference to Y. ii. Method parameter passing in classes: Class X is said to use each parameter, Pi, where i = 1.. n, of a method, m, if m belongs to X and takes parameters P1, … Pn. Hence, m is in the reference sets of each of Pi, where Pi can be any class and type. iii. Classes as lvalue of an assignment statement: Within an assignment statement, if class X or any of its members is specified as the lvalue, implies that X or its member is defined by all the rvalues. Hence, they belong to the reference set of all the rvalue. iv. Method’s Return type: A method, m defines its return type. Hence, m belongs to the reference set of this return type. v. Variables declared in a method: A variable is said to be used by a method, m if m references the variable. Thus, the variable belongs to the reference set of m. 3. Inheritance Relationship: If class Y is declared as a super class of X, then we say class X inherits from class Y. This implies that, X can inherit the properties of Y, say instance variables, interfaces, and instance methods as though they were defined within class X. 4. Invocation Relationship: Method m of Class X invokes method n of Class Y if mx calls some services ny.

B. Indirect Relationship

This is simply a cyclic relationship in which an impact of a class X on another class Y indirectly impacts itself. Accordingly, we say X has an indirect relationship with Y if there exists a path Y1, Y2, …, Yn, such that XRY1, Y2RY3 , … , YnRY, expressed by XR+Y.

3. 1. 4 Impact Dependency Properties

As shown in Figure xxx, classes must interact with one another to achieve the overall system objectives. With the complex dependencies that exist among the class components, when a change is consider on one component, other components may be affected directly or indirectly. The properties that govern how the determination of the component in the change proposals is impacted are reflexive, transitive and cyclic [2]. Let X, Y and Z be classes of a system and D the change impact dependency. Therefore:

i. Reflexive:

A class X is said to be reflexive if X depends on itself. This is given by XDX. This means that, if X is impacted, it will impact itself. In an implementation, this is called a local or member dependency.

ii. Transitivity:

A change impact dependency is said be transitive if a change to one class may propagate to other classes indirectly. That is, if X impacts Y and Y impacts Z, then by implication X impacts Z. It is represented as XDY, YDZ => XDZ.

iii. Cyclic:

This property entails that cycles exist in the impact dependency representation. It implies that, there exists a path of relationships that returns back to the class where an impact started. In other words, a change to a class affects itself through other classes.

3. 2 Object-oriented System Dependency

There are a number of dependencies that exist among components (i. e. classes, methods and data objects) of OOS. From the maintainer’s perspective, dependency in a software system constitutes, a direct relationship between components in the system, such that a change to one component may have an impact that will require changes to the other. For instance, let X, Y be classes of a system and whenever a class X uses another class Y, then we say, X depends on Y if changes to Y have a direct effect on the behaviour of X. In such a situation, the class X is called the dependant and the class Y is called the dependency. Thus, the maintainer modifying Y must take the possible side effects in X into account and seriously. In the realm of OOP, the complex dependencies are the result of features such as encapsulation, inheritance, polymorphism, and dynamic binding which are specific to it [4]. These dependencies are identified based on the nature of the relationships among components. These include the use, invocation or call, inheritance, implementation and member or Local dependencies [3, 5]. (see Figure 2 ) However, these dependencies make it cumbersome to predict or identify the ripple effects of changes [2]. Figure 2. Component dependencySince much of the complexity arises from the relationships among classes, it is important and necessary to identify all primary dependencies in order to perform impact analysis effectively. In this research, we shall only consider the dependencies that are clearly defined within and between classes: use, inheritance, member (local), and invocation dependencies. Implementation dependence is deal with as inheritance dependencies [3]. Detail descriptions of the dependencies are discussed below:

i. Dependencies between Classes

There are inheritance dependencies, implementation dependencies, and the use dependencies among classes. 1. Inheritance dependencies (INH)Given two classes C1 and C2, INH exists if: C2 inherits from C1C1 inherits from C2C2 indirectly inherits from C12. Use Dependencies (USE)The USE dependency stipulates that an object of the class may be declared as the member field of another class or the class is instantiated and used in another class method(s). That is, C1 uses C2C1 aggregates or contains C2C1 aggregates or contains C2 by value or referenceii. Dependencies between a Class and Members (LOCAL)The dependence between a class and its members is mainly the LOCAL. Also, within a method, a class can also be instantiated or used, such dependency is the USE between this method and the class instantiated. LOACL exists in the following ways: 1. Class and MethodMethod m returns object of CC implements method m2. Class and FieldField f is an instance of Cf is a class variable of Cf is an instance variable of Cf is defined by Ciii. Dependence between a Method and a Field (USE)A method regularly uses the field(s), and such dependency is the USE. The nature of USE can take the shape of one of the following scenarios: f is a parameter for method mf is a local variable in method mf is a non-local variable used in mf is defined by miv. Dependencies between Methods (INVOCATION)Methods are often called to carry out operations. Dependence between methods is presented as INVOCATION. The nature of INVOCATION is as follows: Method m1 invokes method m2Method m1 overrides m2v. Dependencies between Fields (USE)This dependency is the USE. For instance, f1 of Method m1 defines or uses f2 of Method m2.

3. 3OO Change Type Categorization

In OOS, there are different types of code changes (CCT) that can be done and the knowledge of these changes and their corresponding impacts is critical to software maintenance. Thus, we need to carefully identify the type of changes that needs to be implemented and their impacts when faced with change proposal. In this section, we will categorize various ChT at three different perspectives of OOS; field, method and class. In this research, we target software systems coded in Java language. Albeit, some changes are specific to other OO languages such as C++, the ChTs considered in this research are common to both Java and C++. Why is of essence to identify different ChTs and their impact is that different changes modified in programs have different impact to other components. This is confirmed by [3, 5]. It implies that, some changes do or do not affect other components regardless of some dependencies that existed between the changed components and other part of the program. Therefore, our task is to take account of the impact range of the different ChTs during the course pact analysis in order to ensure that only components truly affected by a change are changed. In subsequent sections, we present the different ChTs based which are based on [2][3][4][5]. They are categorized according to the component they affect. Tthat is, we categorized them based on the characteristics of each type of code change and how each type can influence other parts of the system is analyzed. We consider changes in three forms; deletion, addition and modification.

3. 3. 1 Class Change Types Category

Unlike the structured-oriented programming (SOP), a class is the basic entity of OOP which represents a set of objects that share a common structure and a common behavior. The different ChTs that can be carried at the class level include the addition of a new empty class, deletion of a whole existing class, modifying the usage modifiers of the class as well as the inheritance derivation between classes. For usage modifiers (i. e access, static, abstract, and final modifiers), details about them are discussed below: Access modifier: The access modifiers of a class impose a restriction on the access class members (i. e. information hiding principle which stems from the use of keywords such as public, protected and private). Abstract Modifiers: The abstract modifier in an existing class demonstrates that a class is incomplete and composed of an abstract method(s), thus cannot be instantiated. Final modifiers: Final modifier of a class describes that no class can inherit any feature from the final class. The sole purpose is to prevent the class from being inherited. Thus, a class can be declared final if its definition is complete and no derived classes are desired or required. Static modifiers: The modifier static pertains only to member classes and is often used in an inner class. When adding the static modifier to an inner class, the inner class becomes a nested top-level class and can be used as a normal top-level class [3]. Furthermore, change to the inheritance relation between two classes is not an exception. Such changes includes the deletion, addition of a base class (or an interface) and the inheritance derivation between two classes. By inheritance relationships, we mean how a child class inherits methods and fields from its parent class. Table 1 presents amore detailed category of class ChTs. The arrangement is as follows: the left column is the ChT’s abbreviation, the middle column is the change description which indicates the meaning of various ChTs, and the right column (Impact Range) describes the impact range of the ChT. Table 1: Class Change Types

ChT

Change Description

Impact Range

CA

Class Addition (common)When a class is newly added, it does not yet have any classes that use it. Thus, it has no impact on any other class.

CD

Class DeletionDeletion of a class means that all members in that class are deleted will not be available to any related classes any more, so all of the classes related to it will be affected.

ICA

Increase Class AccessWhen a class access modifier is modified from ” private” to ” public”, the class is visible to all classes and has no effect on itself and classes that uses, inherits or calls it.

DCA

Decrease Class AccessWhen a class access modifier is modified from ” public” to ” private”, the class is no longer visible to all classes and will affect the classes that uses, inherits or call it other than itself.

AAbC

Add ” Abstract” Modifier to the ClassAdding the modifier ” abstract” to the class will impact or affect those classes that inherits, invokes or use the members of the class

DAbC

Delete ” Abstract” Modifier from the ClassDeleting the modifier ” abstract” from the class will impact or affect those classes that inherits, invokes or use the members of the class

CCN

Change Class NameChanging the name of a Class will affect the class, its children and other classes that use it.

APC

Add Parent ClassWhen a new Super class is added, it will affect all the classes that inherit it.

DPC

Delete Parent ClassWhen an existing Super class is deleted, it will affect all the classes that use, inherit or invoke it.

CID

Change Inheritance Derivation

CID1

Private -> PublicWhen inheritance type changes from private to public, it means all the public/protected members of the super class are public/protected members of the subclasses respectively. Thus, no impact is created on any class.

CID2

Public -> PrivateWhen inheritance type changes from public to private, it means all the public/protected members of the super class becomes private members of the subclasses. Thus, the members are no more visible to other classes that invokes, use, or inherit them.

AFC

Add Final Modifier to the ClassAddition of a modifier ” final” to class means that the class cannot be inherited will not be available to any related classes any more, so all of the classes related to it will be affected.

DFC

Delete Final Modifier to the ClassDeletion of a modifier ” final” to class means that the class is inheritable and available to any related classes, so it will have no effect on classes related.

ASC

Add Static Modifier to the ClassAddition of a modifier ” static” to class will have effect on all related classes or member classes.

DSC

Delete Static Modifier to the ClassAddition of a modifier ” static” to class will have effect on all related classes or member classes.** Common class=> non-abstract, static, or final class

3. 3. 2Class Methods Change Types Category

Class method as a class member can also be changed in different ways like the class itself. The categories of ChTs that are relevant at the class method levels are adding an ordinary new method declaration, deleting a whole existing method, and modifying the method. Method modification on the other hand, ranges from modifying method usage modifiers, method name, method parameters, return type of a method to and statements within the method body [1, 3]. In a nutshell, excluding the method modifiers, other method modifications are simply known as method signature change. In later section, we will enumerate how dependency in methods can be extracted. The methods usage modifiers ChTs of a method are similar to that of a class but differ in level of operation. They include: Access modifiers: The method access modifier specifies the level of visibility of the method outside the class which they belong. Just like in a class, access modifiers are also declared with the keywords; private, protected and public. Abstract modifiers: A method is said to be abstract method if it is declared without an implementation. Its intent is to be overridden in every class that is derived from the base class. In addition, if abstract methods are declared in a class, the class itself must be declared abstract. Final modifiers: A final modifier in a method indicates that the method can not be overridden by inherited classes. That is, it disallows the inherited classes to change the meaning of the method. Static modifier: A static modifier on a method definition specifies that this method belongs only to the class and not a particular instance of the class. This implies that it can be invoked via the class name and not the object name. Additionally, a static method can not refer to a non-static method as well as the non-static variable of the class. For the ease of comprehension, Table 2 presents a more detailed explanation of the different class method ChTs. Table 2: Class Method Change Types

ChT

Change Description

Impact Range

AM

Add ordinary Method

A newly added method has no classes that use it yet, though the class children have to know the new method. Thus, it has no effect on any class.

DM

Delete ordinary Method

When a method is deleted, it is no longer available to its clients, so all of its clients are affected. If the method is public, it will affect the data members or methods from the changed class, its clients, and its children. If it is private, it will only affect the data members or methods from the changed class [].

IMA

Increase Method Access

If a method is changed from Private to Public, it will not affect any other classes except reveal the state of the object.

DMA

Decrease Method Access

If a method is changed from Public to Private, it will affect any client classes and subclasses that reference this method, because this method will not be visible again.

CSM

Change Statement within a Method

Changing a statement within a method body will affect the class children and other member methods that invoke it.

AAbM

Add Abstract modifier to a Method

Adding the modifier ” abstract” to an existing method will affect all the client classes and subclasses that inherits, invoke or use it. That is, it will affect any methods or data members that relate to this method.

DAbM

Delete Abstract modifier from a Method

Deleting the modifier ” abstract” from method will affect all the client classes and subclasses that inherit or invoke. That is, it will affect any methods or data members that relate to this method.

MRM

Modify Return Type of the Method

Modifying the Return type of a method will affect all the client classes and subclasses that inherit or invoke the method.

MNPM

Modify Name of Parameters of the Method

Modifying only the name of the parameters will only impact the statements within the method body but not on other entities outside this method.

MPM

Modify Parameters of the Method

Modifying other parameters of the method other than the name will affect the subclasses and other methods invoking or invoked by the method.

MNM

Modify Name of the Method

If name of a method has changed, it will affect any methods or data members that relate to this method. If the method is public, it will affect the data members or methods from the changed class, from its clients, and from its children. If it is private, it will only affect the data members or methods from the changed class.

AFM

Add Final modifier to the Method

To add the modifier final to a method, it means the method cannot be overridden by the inherited classes. Hence it will affects all subclasses related to it or invoke it.

DFM

Delete Final modifier from the Method

To delete the modifier final from a method, it means the method will be available or visible to all inherited classes. Hence it will have no affects all subclasses related to it or invoke it.

ASM

Add Static modifier to the Method

To add the modifier static to a method, it will have effects on the classes or subclasses related to it or invoke it.

DSM

Delete Static modifier from the Method

To delete the modifier static from a method, it will have effects on the classes or subclasses related to it or invoke it.

3. 3. 3Class Field Change Types Category

The class field is not an exception. The category of ChTs that may occur at the class field level includes the addition, deletion and modification to a field. Like the class and class method ChTs, the modification to a class field involves the field usage modifier (i. e. final, static and access), type and name. The usage modifiers are discussed below to distinguish it from that of the class or method. Access modifiers: Access modifier to a field is similar to the description of the method’s access modifier. Final modifier: The final modifier of a field shows that the field cannot have its value changed after its initialization. That is, the field is a constant. Static modifier: A class field where only one instance of the field exist, in spite of of the number of class instances created. Here, access is via the class name other than an object and the static variables can be used by all objects of the class to perform some joint actions. In addition, other changes that are applicable at the field level are the field type and the field name change. A more detailed class field change categorization is presented in Table 3. Table 3: Class Field Change Types

ChT

Change Description

Impact Range

AF

Add ordinary Field

When a class field member is added newly, it affects no class because it does not have any classes to use it yet though the subclasses have to know the new field member if it is public

DF

Delete ordinary Field

If a class field member is deleted, it will not be available to its client anymore, so all its clients will be affected. However, if this field member is public, it will affect the field members or methods from the changed class, from its clients, and from its subclasses. If it is private, it will only affect the field members or methods from the changed class.

IFA

Increase Field Access

Modifying a class field from Private to Public will not affect any other classes except to reveal the state of the object.

DFA

Decrease Field Access

Modifying a class field from Public to Private will affect any client classes and subclasses that reference this field member. Field members and methods in the changed class will not be affected by this change.

MFT

Modify Field Type

If the type of the class field is changed, it will affect the methods or other field members referencing it. If this class field is public member, it will affect the data members or methods from the changed class, its clients, and its subclasses. If it is private, it will affect the data members or methods from the changed class only.

MFN

Modify Field Name

When the name of a class field is changed, it will have effects on any member methods that uses it or subclasses that inherited it if is public.

AFF

Add Final modifier to Field

When adding the modifier Final to a field, it means the field cannot have its value changed and will have impacts on all members or classes that related to it.

DFF

Delete Final modifier from Field

When deleting the modifier Final from a field, it means the field value can be changed and will not impact any members or classes that related to it.

ASF

Add Static modifier to Field

When adding the modifier Static to a field, it means the field cannot be accessed through object and will have impacts on all members or classes that related to it.

DSF

Delete Static modifier from Field

When adding the modifier Static to a field, it means the field can be accessed through object and will have impacts on all members or classes that related to it.

3. 4Analysis of Reference Dependency within Member Methods

In section xxx, we mentioned that modifications to member method includes modifying method name, modifying method parameters, modifying return type of a method and modifying statements within the method body [1, 3]. In this section, our aim is to describe how the reference relationships among data items from different types of statements can be extracted. The rationale is to enable the quick identification of all only impacted statements during impact analysis given a change request. Firstly, we would define a method containing the statements as the host member method of those statements. Within a host method, they are statements and control structures. We discussed them as follows:

1. Statements:

In OOP languages such as Java, two kinds of primitive statements are of the essence: assignment and method invocation. Assignment Statement: An assignment statement is of the form: Variable x = expression; In the above format, assignment operator (=) assigns the result of any expression on the right hand side to a variable x on the left hand side. From the perspective of impact analysis, x depends on all the rvalue (i. e. variables, constants, objects and their members on the right hand side of assignment). Elements referenced in the expression belong to the definition set of x, while x belongs to the reference set of each of those elements. Thus, the impact of change is equal to the impacts of the assigned variables [1]. Message Passing: A message constitutes the fundamental means of communication between objects in a program. To illustrate how reference sets can be extracted in a message, we considered a message whose host method returns a value used as the expression in an assignment statement as follows: Variable x = object. method (P1, P2, …, Pn); where Pi= Parameter list, i= 1, 2,…. nHere, both variable x and the host member method of this variable depend on the object on the right hand side and all its parameters. Hence, x and the container member method of this statement belongs to the referencing set of object and Pi.

2. Control Flow Statements:

In this subsection, we shall consider the conditional and generalization will be extended to the loop statements. If-else statementThe if-else statement for instance, in Java has the following form. if (x) {statement1} else {statement2

}

In the statement, the host member method references all the elements in x and in statement1 and statement2. For the fact that x value determines the path of execution, the referencing set of all the data elements in x includes all the data elements in statement1 and statement2. Accordingly, for the loop statements, the referencing sets of all the data elements in x include all the data elements in the loop.

3. 4. 1 Methods versus Parameters

Figure xxxx presents the structure of a defined method. Firstly, to define and use a method is to specify its task and too call or invoke it respectively. From the impact analysis perspective, the parameters and the variables in a method are considered critical to change propagation. When a method is invoked, the formal parameter (FP) is replaced by the actual parameter (AP) in accordance with the method declaration. Figure 3: A defined method structureAs shown in Figure xxx, the method’s name and the parameter types are called the method signature given by: Method_Name(P1,…. Pn)During the course of invoking the method, FP1 to FPn are replaced by AP1 to APn. This implies that a change to the APi (where i= 1, 2.., n) will have effect on other members if they are used in the body of the method. Thus, the referencing sets of APi are FPi. Accordingly, variables and methods used in the body of the method belong to the referencing set of the current method. For local variables, their scope is restricted to the body of the method that contains them. However, they have the capability of propagating change from one member to another one within same class. For instance, consider the code segment in Figure xxx. Class C{public: int d; void m1 (){…d1= d1+1;…}; void m2 () {…d2 = 30 + d1;..};

…..

};

Figure 4. Methods defining local variablesIn Figure xxx, m1 and m2 are members of class C, and a local variable d1 defined by m1 and another member m2 defined by d2. Hence, a change on C. m1() will affect C. m2 () due to d1 involvement. As a result, we can say that the declared local variables, d1 are referencing set of the current method m2 as long as they are used, referenced or defined in the body of the method.

3. 5Impact Models

An impact model is a model that is specifically designed for CIA. It is used to predict which components would be impacted if a change were really implemented. In literature, traditional impact-analysis models are based on static or dynamic analysis of source code to identify the impact set [1, 3]. Different types of such models were discussed by [1] and divided into two dimensions: static and dynamic impact as well as syntactic and semantic impact. However, our interest in this research is on changes that have syntactic and static impacts. Figure 4: Impact Model Dimensions [1]In syntactic impact, a given change is characterized by a code transformation somewhere in the system. That is, impact is computed only by information extracted from the source code as the data flow, the control flow and the calling hierarchy that is obtained from the dependency graph constructed [1]. Based on this, if the system is accompanied by a successful re-compilation after change is effected, then impact is considered absent otherwise present. The presence of impact however signifies that code modifications is needed and must be carried in the system in order to obtain a syntactically correct code that will accomplish re-compilation. In addition, semantic knowledge is indispensable at tracking down the possible ripple effects. On the other hand, static impact computes impact sets is based on the static information obtained at compile time. Although call graph and program dependencies graph for the analysis are utilized, there are known to be safe, less precise, and produce very large impact set which are difficult for practical use [3]. Therefore, our objective is to device a means to ensure that the computed impact set is smaller as possible. Since our focal point is only on syntactic impacts, appropriate measures that we have to apply are based on impacts that are dependent on the static nature of the source code. Furthermore, the impact emanating from the execution of a program (i. e. dynamic impacts) such as polymorphism, dynamic binding are not considered in this research.

3. 6 Chapter Summary

Objects and classes are the basic building blocks in object-oriented programming. An object must interact with one another through message sending in order to perform some service it provides. In order words, messaging is what binds an OO system together and a change to one component will inevitably impact others. In this chapter, we have discussed the basic components of analysis in this research. We have discussed the concept of class in OOS and its encapsulating entities known as members of the class: data (class field) and action (class method). The class methods and fields are all components at the granular level that is important to our analysis in the perspective of impact analysis. Since object components relates with one another, the existence of certain features specific to the OO paradigm gives rise to different types of relationships. However, from the impact analysis point of view, it has been shown that such complex dependencies make it cumbersome to anticipate effects of a change whenever change proposal is to be implemented. Thus, the identification of such relationships is critical to maintenance effectiveness. We have discussed the various relationships, different dependencies exist as a result if the relationships as well as the properties critical to the determination. Furthermore, the discussion progresses to different code change types that exist within the realm of OOS. The identification of such code change type is considered a sin qua non whenever OO impact analysis is considered. The ultimate fact is that, though dependencies (direct or indirect) exist among components, certain code change types do not produce impact on other components. The knowledge of this idea is vital to predicting impact sets that are accurate and precise. We categorized different code changes at the class, method and field levels as well as their respective impact range. We also discussed how to analyze and extract dependency from class method. Lastly, we discussed the impact model that we intent to use in this research. Our model will take the static code analysis approach which is use to discover the impact sets. Albeit static-analysis-based approach can safely predict the impact of changes, their traditional assumptions often produce impact sets that are very large for practical use. Therefore, our task in this research is to device approach that overcomes this ugly drawback.