slice is two-phase graph-reachable, introduced by Susan B. Horwitz and etc. 10, 11] and Karl J. Ottenstein etc. 19] respectively. In object-oriented program, the ...
A Hierarchical Slice-Based Framework for Object-Oriented Coupling Measurement Bixin Li
Turku Centre for Computer Science TUCS Technical Reports No 415, July 2001
A Hierarchical Slice-Based Framework for Object-Oriented Coupling Measurement Bixin Li
Turku Centre for Computer Science TUCS Technical Report No 415 July 2001 ISBN 952-12-0853-8 ISSN 1239-1891
Abstract There is great interest in use of the object-oriented approach to software engineering. This is due to a variety of claims about how it may improve the development of software, including such factors as greater reusability and increased extensibility. In order to help managers and developers achieve these goals, a variety of software metrics have been proposed to help track the status of software designs. Several software measurement frameworks have been introduced in order to measure object-oriented program, most of them are based on information-ow or statistics computation. In this article, a new measuring coupling framework based on hierarchical slice model (HSM) is introduced to measure object-oriented program. HSM is obtained via not only computing data-ow and control-ow but also computing all kinds of dependence relationships between components in object-oriented program. The measurement result gained by this method based on HSM is more precise than others.
Keywords: framework, program slice, coupling measurement, hierarichical model
TUCS Research Group
Programming Methodology Research Group
1 Introduction Object-oriented design and object-oriented programming appear to be the structured programming of the 1990's. The reasons to develop and use software metrics for software implemented in imperative programming languages also apply to software developed using object-oriented programming languages. Perhaps metrics are even more important in the object-oriented paradigm, because, in many ways, object-oriented programming can be even more complex than imperative programming. Software metrics researchers need to focus on this new paradigm. Attributes that are well understood in the world of procedural programming may not be directly relevant to objectoriented software. For example, the concepts of coupling and cohesion need to be rede ned in order to be applied to object-oriented systems or to abstract data types. The object-oriented paradigm is ideal for metrics research. In an object-oriented system, the basic program unit is a class rather than a procedure. A class with its encapsulation of state with associated methods (operations) is a signi cantly di erent and richer abstraction than the procedure units within procedural programs. The inclusion of inheritance in object-oriented systems further complicates the static relations between classes. Therefore, rigorous, well de ned models and abstractions suitable for de ning metrics of attributes of object-oriented software are needed. In this article, we rst introduce some basic coupling criterions in objectoriented program, then a new measuring coupling framework based on hierarchical slicing model is presented. The rest of the paper is organized as follows: Section 2 describes most important factors may a ect software measurement of object-oriented program. These factors show explicitly the di erences between procedural and objectoriented software from the perspective of deriving software metrics. These di erences translate into appropriate research goals for developing metrics for object-oriented software. In Section 3, an abstract model of object-oriented program is given. Section 4 provides some details of the object-oriented coupling criterions. The hierarchical slicing model and a measuring coupling framework based on it is created in section 5. Related works in this area are compared and analysed in section 6. Concluding remarks and future work are in Section 7.
2 Factors Aecting Object-Oriented Metrics In object-oriented program, many factors may a ect the research of software metrics, some most important of them are: localization, encapsulation, 1
information hiding, inheritance, and object abstraction mechanism etc. Object-oriented approaches localize information around objects. In most conventional software, localization is based on functionality. Metrics focusing on component interrelationships emphasized functional interrelationships, e.g., module coupling. In object-oriented software, localization is based on objects. This means that some of our metrics identi cation and gathering e ort must recognize the "object" as the basic unit of software. Within systems of objects, the localization between functionality and objects is not a one-to-one relationship. For example, one function may involve several objects, and one object may provide many functions. Encapsulation is the binding together of a collection of items: Low-level examples of encapsulation include records and arrays. Subprograms (e.g., procedures, functions, subroutines, and paragraphs) are mid-level mechanisms for encapsulation. In object-oriented (and object-based) programming languages, there are still larger encapsulating mechanisms, e.g., C++'s classes, Ada's packages, and Modula 3's modules. In many object-oriented programming languages, encapsulation of objects (e.g., classes and their instances) is syntactically and semantically supported by the language. In others, the concept of encapsulation is supported conceptually, but not physically. Encapsulation has two major impacts on metrics: the basic unit will no longer be the subprogram, but rather the object, and we will have to modify our thinking on characterizing and estimating systems. Information hiding is the hiding of details. The general idea is that we show only that information which is necessary to accomplish our immediate goals. There are degrees of information hiding, ranging from partially restricted visibility to total invisibility. Encapsulation and information hiding is not the same thing, e.g., an item can be encapsulated but may still be totally visible. Information hiding plays a direct role in such metrics as object coupling and the degree of information hiding. Inheritance is a mechanism whereby one object acquires characteristics from one, or more, other objects. Some object-oriented languages support only single inheritance, other object-oriented languages support multiple inheritance. The types of characteristics which may be inherited, and the speci c semantics of inheritance vary from language to language. Many objectoriented software engineering metrics are based on inheritance, e.g.: number of children, number of parents, and class hierarchy nesting level. Inheritance will produce coupling between classes. Abstraction is a mechanism for focusing on the essential details of a concept or item, while ignoring the inessential details. There are di erent types of abstraction, e.g., functional, data, process, and object abstraction. In object abstraction, we treat objects as high-level entities. A key issue in deriving 2
metrics appropriate for object-oriented software is de ning abstractions or models of object-oriented software properties. A traditional system is a collection of procedures and functions. Some metrics developed for traditional software can be applied to object-based and object-oriented software 7,8,13].
3 Hierarchical Model of Object-Oriented Program We can nd that there are many levels in object-oriented system when we study how to measure and test object-oriented system. We create a hierarchical model including four levels from the object-oriented system by using abstract techniques. Figure 1 represents the hierarchical model of an objectoriented system and the pertinent abstraction levels . Fig.1 shows the correspondence between the levels of concerns, the pertinent abstraction levels and levels of slice. Hierarchical slicing criterion statement level method level class level modular level
Hierarchical dependence graph(HDG) Statement level dependence graph (SLDG) Method level dependence graph (MLDG) Class level dependence graph (CLDG) modular level dependence graph (PLDG)
Fig.1 Hierarchical model of an object-oriented system
Statement-level. The statement-level concerns about program statements, control predicates, and di erent kinds of variables, such as local variables, instance variables, class variables, etc. This is the most complicated level, since di erent kinds of data dependency relations and control dependency relations should be covered in this level. It has been shown to be prone to errors or lack of precise, even not very hard, by starting slicing in this level all from scratch. However, it's our exact goal to derive program slices up to the statement-level, if it will have any bene ts to our future use, such as software metrics, or testing. Method-level. The method-level refers to the methods or attributes de ned in a class. This level corresponds to procedures or functions in traditional procedure-based systems. There exist two kinds of relations: usedby relation between a method and the member variables referred to by the method, and procedure-call relation between the client and server methods in a method-call invocation. This level of slicing is useful in program tracing and pro ling. 3
Class-level. An object-oriented program (for example a Java program) viewed from the class-level is composed of a set of top level classes or interfaces. In this level, there are two kinds of relations: extension relation between superclass and its subclasses, and rei cation relation between a class and the interfaces it claims to implement. Class is the elementary building block of an object-oriented system, thus slicing in this level is crucial in extracting frameworks or design patterns from real application domains. Modular-level. Some object-oriented programs, such as a Java program are organized as sets of packages, whose naming structure is hierarchical. At modular-level, we only focus on the modulars and their relations. Slicing in the modular-level is not necessary but by doing so, it may attract our attention to the most concerned parts and free our e orts out of dealing with unrelated ones.
4 Coupling in Object-Oriented program Coupling is the degree of interdependence between modules. Usually, coupling is an attribute of pairs of modules, rather than of the design as a whole. The entire set of modules in the design exhibits global coupling, which can be derived from the coupling among the possible pairs. In object-oriented program, coupling describes the interdependency between methods, between object classes and between modulars etc respectively. Coupling measurement is important content in measurement theory research area. Coupling is used to measure the connectivity caused by the connection of two or more modules. High coupling makes the system more complicated and makes it too dicult for us to understand, change or override a system for high interactive relationship between modules. Low coupling design may reduce complexity. In traditional modularize system, coupling is a measurement of content of interdependence among di erent modular. Coupling is concerned with the complexity of modular interface, modular entrance and the information communicating through interface. In object-oriented system, coupling is produced by methods call each other or share common data and inheritance. So, there are at least three kinds of coupling produced from object-oriented system, they are interaction coupling, component coupling and inheritance coupling. Thereinto, interaction coupling maybe produced by two methods belong to di erent classes (objects), or same class (object). Coupling is used to measure how a modular a ect another one in traditional software system, traditional method for computing coupling is based on information-ow introduced by Henry and Kafura 8]. Mark Harman applied program slices to measure the coupling in functional program 12]. 4
4.1 Interaction coupling
4.1.1 Interaction coupling between methods In object-oriented program, there are many kinds of interaction couplings between methods. Methods are coupled by interaction in terms of invocation of each other and/or sharing of data. Since interaction coupling is most similar to the classical de nition of coupling between modules we adopt the various degrees of classical coupling to describe interaction coupling. In the following we analyse where interaction coupling in object-oriented system di ers from the classical notion of coupling. The di erence mainly stems from two interrelated facts. Firstly, methods belong to object classes. This implies that object classes may be interaction coupled, too. Secondly, interaction coupled methods may belong to the same object class. This implies that we have to distinguish interaction between di erent classes from interaction with a single class. Content coupling, one method directly accesses the implementation of another method. Common coupling, methods exchange information via nonstructural, global, shared data space. External coupling improves common coupling by structuring the global, shared data space, such aspublic variables in Java program. Control coupling, methods communicate each other via special parameter passing (indicating they are not content, common, or external coupled), but one method controls the internal logic of another method. Stamp coupling transfers whole data structures as a parameter. The essence of stamp coupling is as follows: a method depends on some data structure de ned externally, the method has to be changed if this data structure changes. Data coupling, two methods are data coupled if they communicate only by parameters and these parameters are relevant as a whole. Data coupling is the best one of coupling form whenever two methods have to interact. Data coupled methods minimize maintenance e ort due to a great restriction of change propagations. The theoretical optimum of interaction coupling is no direct coupling, i.e., two methods do not (directly) depend on each other, and thus also their object classes are not interaction coupling.
4.1.2 Interaction coupling between classes
One class is consisting of member variables and related member methods, here, variables indicate states and methods indicate behaviour. Class's variables are core and the external is method, these methods di erentiate one class from another. Classes implement complicate function by interacting action, one class send a message to notify other class what to do. Since all behaviours of any object can be described by method, the interaction 5
between objects can be completely realized by message mechanism. There two levels interact coupling between classes (objects): class level coupling is de ned as the coupling that result from state dependencies between classes during development life-cycle, where the state of a class refers to the class de nition and the program code of its methods. Object level coupling is de ned as the coupling that result from state dependencies between objects during system run-time.
4.2 Inheritance coupling
In object-oriented program, the basic unit is class, all dependence relationships between components can be nally transferred to dependence relationships between classes. Inheritance coupling is a kind of coupling relationship between classes (objects), i.e., two classes are inheritance coupled if one class is a direct or indirect subclass of the other. Inheritance coupling is also different from interaction coupling and component coupling in that it does not only exhibit the coupling property between subclasses and superclasses but implicitly also the coupling property between an interaction coupled class and the inheritance structure. There are many inheritance couple forms in object-oriented program. Overriding coupling produced by overriding parent class's method, Re nement coupling produced by re ning parent class's method. Extension coupling produced by introducing new instance variables and methods in a class, In object-oriented program, there are two overriding forms: overridden signature and overridden implementation. Overriding signature will make the program become more complex soon. Unlike overriding signature, overriding implementation will be better for no signature being overridden randomly and no method being deleted. Re nement coupling is better than overridden coupling, because re nement couple changes inherited information according to prede ned rules.
4.3 Component coupling
As opposed to interaction coupling where object classes and methods are involved component coupling concerns only object classes, i.e., component coupling only exists between object classes. The component relationship between classes is de ned by the use of a class as the domain of some instance variables of another class. Class c1 is a component of class c if and only if c1 appears in c, c1 appears in c if and only if they satisfy one of the following conditions: 1)c1 is the domain of one of instance variables of c, 2)c1 is the domain of one of parameters of some method in c, 3)c1 is the domain of local 6
variable of some methods in c. All of subclasses in c1 and c are component coupling if c1 and c is component coupling. Component coupling usually implies interacted coupling.
5 A Measuring Framework Based on Program Slicing Model 5.1 Hierarchical slicing model
Program slicing is a method of program reduction introduced by Mark Weiser 23]. A slice of a module at statement s with respect to variable v is the set of all statements and predicates that might a ect the value of v at s. Weiser's algorithm for computing slices is based on data ow analysis. It is suggested in 19, 11] that a program dependence graph representation could be used to compute slices more eciently and precisely. An algorithm for computing slices using a program dependence graph representation is presented by Horwitz, Reps, and Binkley 11]. A backward slice is obtained by walking backwards over the program dependence graph to obtain all the nodes that have an e ect on the value of the variable of interest. Similarly, forward slice is obtained by walking forwards over the program dependence graph to obtain all the nodes that are a ected by the value of a variable. Program slice is actually an abstract of some program in people's mind when he analyse or understand or debug or test a program. In traditional structure program, the basic construct is procedure, we must analyse and compute all kinds of data-ow and control-ow in a procedural or between two procedural, i.e., we must consider how to compute intraprocedural and interprocdural slice. The algorithm for computing intraprocedural slice is graph-reachable algorithm. The algorithm for computing interprocedural slice is two-phase graph-reachable, introduced by Susan B. Horwitz and etc.10, 11] and Karl J. Ottenstein etc.19] respectively. In object-oriented program, the basic construct is class, except for considering all kinds of dataow and control-ow dependence relationships, we should also consider all other dependence relationships, such as inheritance dependence relationship, message dependence relationship, declare dependence relationship, reference dependence relationship, concurrent dependence relationship etc. In order to compute object-oriented program slice, we usually adopt two ways as following: one way for computing object-oriented program slice is an objectoriented extension version based on traditional algorithm (graph-reachable algorithm and two phase graph-reachable algorithm) another way is that we should introduce new algorithm to compute object-oriented program slice 7
for the especially features in object-oriented program. Many people are employing themselves in engaged with this research area. A. Krishnaswamy extended system dependence graph (SDG) for computing object-oriented program slice by adding class hierarchy (CHG) graph to SDG, the extension version of SDG was called object-oriented program dependence graph (OPDG), he also created an algorithm based on OPDG, then, a C++ program slice was gained by using his algorithm 18]. Marry Jean Horrald etc. compute C++ program slice by adding class dependence graph (ClDS) to traditional SDG, then they can compute object slice based on object dependence graph (ODG) introduced by them15, 16]. Frank Tip etc. use class hierarchy graph (CHG) to compute class hierarchy slice 6]. Christoph Steindl presented an approach for computing intermodular slice in objectoriented program 22]. Jianjun Zhao presented basic method to compute object-oriented concurrent program slice and dynamic object-oriented program slice in his papers25,26]. Bixin Li introduced a new model called hierarchy slice model based on all of achievements gained by all these pioneers in his Ph.D thesis 17], and a new hybrid algorithm is produced consisting of both graph-reachable algorithm and stepwise re nement algorithm, he uses this hybrid algorithm to implemented the computing of Java program slice. Program slicing technique has been applied in many software engineering areas, such as program comprehension, reverse engineering, software maintenance, software test, software metrics etc. Especially, in software metrics aspect, Mark weiser de ned several kinds of metrics based on slice in his paper 23,24]. Longworth rst applied slice to measure cohesion in procedural program 13]. Linda M. Ott and J. Thuss eliminated the inconsistency noticed by Longworth by using metric slice20,21]. A metric slice must consider the use and used data relationship exists in a procedural, in other words, a metric slice is the conjunction of forward slice and backward slice. In this section, we present a measuring framework based on object-oriented program slice, Papers 1,2,12] and all other papers about program slicing 6, 11, 13, 15,16, 18, 22] forms the foundation of our framework. Hierarchical slicing criterion statement level method level class level modular level
HDG SLDG MLDG CLDG PLDG
hybrid slice algorithm (HSA) graph-reachable and stepwise algorithm graph-reachable and stepwise algorithm graph-reachable and stepwise algorithm graph-reachable and stepwise algorithm
Fig.2 Hierarchical slice abstract model of object-oriented system
In order to measure multiple levels coupling in object-oriented program, we rst introduce hierarchical slice model. The hierarchical slicing model for 8
object-oriented program consists of three parts: hierarchical slicing criterion, hierarchical dependence graph (HDG) and hybrid slice generating algorithm. Fig.2 represents the description of HSM
5.1.1 Hierarchical slicing criterion Denition 1 (statement-level slice) Statement-level slicing criterion is a
triple (m s v), here s is a statement in method m, and v is variable referenced in s. Statement-level slice is a set that consists of all statements and control predicates a ecting and a ected by the value of variable v in point s. The former is called backward slice, and the later is called forward slice. Considering variables set V, statement-level slice is also de ned as following: Denition 1' (statement-level slice) Statement-level slicing criterion is a triple (m s V ), here s is a statement in method m, and V is variables set referenced in s. Statement-level slice is a set that consists of all statements and control predications a ecting and a ected by the value of variable V in point s. Denition 2 (method-level slice) Method-level slicing criterion is a triple (C m V m), here m is a method in certain class C, and V m is local variables set used in m. Method-level slice is a set which consists of all member functions and variables a ecting and a ected by the value of variables set V m in method m. Denition 3 (class-level slice) ) Class-level slicing criterion is a triple (P c V c ), here c is a class in certain modular P, and V c is variables set de ned or used in c. Class-level slice is a set which consists of all classes a ecting and a ected by the value of variables set V c. Denition 4 (modular-level slice) ) modular-level slicing criterion is a triple (S p V p), here p is a package in certain system S, and V p is variables set de ned or used in p. modular-level slice is a set which consists of all modulars a ecting and a ected by the value of variables set V p.
5.1.2 Hierarchical dependence graph Hierarchical dependence graph consists of four-levels dependence graphs: statement-level dependence, method-level dependence graph, class-level dependence graph and modular-level dependence. A statement-level dependence graph (SLDG) will be derived for each member method of each class. The SLDG of member method m of class c is a pair (SN, SE), where SN is the node set, each of the node corresponds to a certain statement in m and SE is the edge set. There are three kinds of 9
dependence relationships between statements. Statement node j may data depends on node i, where variable x is declared and accessible from j. There exists sequential control dependency between a statement and its immediate last statement. And transfer control dependency occurs in conditional statements or loop statements, where the body depends on the predicate part of these statements. SE is composed of all these kinds of dependencies. A method-level dependence graph (MLDG) will be derived for each class. There are two kinds of dependency between member variables and member functions: used-by relation between a method and the member variables accessed by the method, and calling relation between a method and the methods (may belong to the other classes) that are called from within the method. In class-level dependence graph (CLDG), we focus on all the classes and interfaces and the relations among them. There are 6 kinds of dependency between classes (interfaces): extending, implementing, class-level association, inner-class, method-level association (local variable), and local-class. Only modulars (such as Java's packages, C++'s class clustter, Molula 3's modules etc. ) is concerned in modular-level dependence graph (PLDG). There are di erent dependencies between modulars: such as importing, or sub-packaging dependency between Java's packages.
5.1.3 Hybrid slice generating algorithm Hybrid slice generating algorithm is consisting of hierarchical graph-reachable algorithm and stepwise slicing algorithm. Hierarchical graph-reachable algorithm means that graph-reachable algorithm will be used in single level of hierarchical dependence graph. Stepwise slicing algorithm will be used to compute slice from top level to bottom level, i.e. from modular-level to statement-level. Details about hierarchical slicing model please to reference 17] Next, we will give some basic coupling and cohesion measurement suits for object-oriented program based on these slicing criterion de nitions and models. In all next equations, we use N(x) to represent node number of certain structure X (such as method, class and modular) in corresponding dependence graph. V(X) represents the set of principle variables in structure X. # and j represents set cardinality and restriction operators respectively. 10
5.2 Measuring Coupling
5.2.1 Measuring Coupling based on variable-related slice Denition 5 Let Slice(m s1 v1) and Slice(m s2 v2) denote the program
slices with respect to variables v1 and v2 respectively, then the coupling between variables v1 and v2 is de ned as follows: s1 v1) \ Slice(m s2 v2)) Coupling(v1 v2) = #(Slice(m #(Slice(m s1 v1) Slice(m s2 v2))
(1)
Obviously, 0 coupling(v1,v2) 1. We can measure the correlativity between variable v1 and v2 with coupling between them, the higher the coupling is, the bigger the correlativity is. Similarly, we can de ne the coupling between two variable sets as follows.
Denition 6
s1 V1s1) \ Slice(m s2 V2s2 )) Coupling(V1s1 V2s2) = #(Slice(m #(Slice(m s1 V1s1) Slice(m s2 V2s2 ))
(2)
#(Slice(c m1 V1m1 ) \ Slice(c m2 V2m2 )) Coupling(m1 m2) = #(Slice(c m1 V1m1 ) Slice(c m2 V2m2 ))
(3)
#(Slice(P c1 V1c1) \ Slice(P c2 V2c2 )) Coupling(c1 c2) = #(Slice(P c1 V1c1) Slice(P c2 V2c2 ))
(4)
Here, Slice(m s1 V1) and Slice(m s2 V2) denote the program slices with respect to variables sets V1 and V2 respectively. coupling(V1s1 V2s2)(0 coupling(V1 V2) 1) shows the correlativity between variable sets V1 and V2 referenced in any two statements. The bigger the value of coupling(V1s1 V2s2) is, the higher the degree of V1s1 inuencing V2s2 or V2s2 inuencing V1s1 is. This also shows the correlativity between s1 and s2. Denition 7 Let Slice(c m1 V1m1) and Slice(c m2 V2m2) denote the program slices with respect to slicing criterion (c m1 V1m1) and (c m2 V2m2) respectively, then the coupling between methods m1 and m2 is Obviously, 0 coupling(m1 m2) 1. Denition 8 Let Slice(p,c1,V1c1) and Slice(p,c2,V2c2) show the program slices with respect to slicing criterion (s c1 V1c1) and (s c2 V1c2) respectively, then the coupling between class c1 and c2 is de ned as follows: Here, 0 coupling(c1 c2) = coupling(V1c1 V2c2) 1. Denition 9 Let Slice(s p1 V1p1) and Slice(s p2p1V2p2) denote thep2 program slices with respect to slicing criterion (s p1 V1 ) and (s p2 V2 ) respectively, then the degree of coupling between packages p1 and p2 is de ned 11
as follows: Obviously, 0
p1 p2 Coupling(p1 p2) = #(Slice(S p1 V1p1 ) \ Slice(S p2 V2p2 )) #(Slice(S p1 V1 ) Slice(S p2 V2 ))
(5)
coupling(p1 p2) = coupling(V1p1 V2p2) 1.
5.2.2 Measuring Coupling based on information-ow or inheritance
In traditional software system, to understand the measurement, consider the way in which data move through a system. We say a local direct ow exists if either: 1) a module invokes a second module and passes information to it or 2) the invoked module returns a result to the caller. Similarly, we say that a local indirect ow exists if the invoked module returns information that is subsequently passed to a second invoked module. A global ow exists if information ows from one module to another via a global data structure. In object-oriented software system, information may ow into a method from a class (including the method), information may ow into a class from a modular (including the class), information may ow into a modular from a system (including the modular), information may ow between two methods, two classes, two modulars or two subsystems. Various levels coupling measurement will be produced because of such information ow, some of them are given below: Denition 10 (Flow into method) We de ne the information-ow (including data-ow and control ow) into a method m from its context (a class c containing m) as follows S Slice(c m V m)) ; N(m)) #(( Flowmc =
v2V (m)
N(c) ; N(m)
(6)
Using backward slicing, we can use Flowmc to assess how much of the class c containing method m a ects the outcome of the method. Using forward slicing we could assess how much of the containing class is a ected by method m. Denition 11(Flow between methods) We de ne the information-ow (including data-ow and control ow) from m1 to m2 in class c (which contains method m1 and m2) as follows S Slice(c m2 V m2 )jN(m1)) #(( Flow(cm1 m2) =
v2V (m2)
N(m2)
(7)
De nition measures the relative amount of the body of m1 which contributes to the computation of the result of m2. The slice-based measure not only 12
allows us to detect such an information ow, but also, it allows us to measure the bandwidth of information ow. Coupling is a measure of how information ow between methods. To measure coupling, it is necessary to see how much of each of methods m1 and m2 contribute to one another. This can be calculated in terms of the ow into each other of the method from the other. Denition 12 we de ne the level of coupling between method m1 and method m2 in a class c (which contains both m1 and m2) as follows Coupling(cm1 m2) =
Flow(cm1 m2) N(m1) + F low(cm2 m1)N(m2) N(m1)N(m2)
Similarly, we can de ne coupling between two classes in a modular. Denition 13 S Slice(p c V c)) ; N(c)) #(( Flowcp =
v2V (c)
N(p) ; N(c)
(8)
(9)
Flowcp shows that information ows from modularp(which including class c) to class c. Denition 14 S Slice(p c2 V c2)jN(c1)) #(( Flow(pc1 c2) =
v2V (c2)
N(c2)
(10)
Flow(pc1 c2) implies that information ows from class c1 to class c2 in a modular p. Thus, the coupling between two classes c1 and c2 based on informationow can also be de ned as follows:
Denition 15
Coupling(pc1 c2) =
Flow(pc1 c2)N(c1) + F low(pc2 c1)N(c2) N(c1)N(c2)
(11)
The following three equations are coupling measurement between two modulars: Denition 16 In system s which including modular p, information ow from s to p, Flowps, can be computed according following equation: S Slice(s p V )) ; N(p)) #(( Flowps =
v2V (p)
N(s) ; N(p)
(12)
Denition 17 In system s, information ow from modular p1 to modular
p2, Flow(sp1 p2), can be computed according following equation: S Slice(s p2 V p2)jN(p1)) #(( Flow(sp1 p2) =
v2V (p2)
13
N(p2)
(13)
Denition 18 In modular p, coupling between modular p1 and modular p2 based on information-ow can be computed according to following equation: s s Coupling(sp1 p2) =
Flow(p1 p2)N(p1) + F low(p2 p1)N(p2) N(p1)N(p2)
(14)
5.3 Example Analysis
Example 1 We show the hierarchical slicing approach by slicing the Java program P shown in Fig.3 step by step. source program 1. class A f 2. public in x 3. public f1( ) 4. f x=1 g g 5. class B extends Af 6. public int y 7. public f1( ) 8. fx=2g 9. public f2( ) 10. fx=3gg 11. class C extends Af 12. public int y
13. public f1( ) 14. fx=yg g 15. class D f 16. public void f3(A a) 17. fa.f1( ) 18. return g 19. class E f 20. public static void main(String str ])f 21. A a1=new B( ) 22. D d1=new D( ) 23. d1.f3(al)g g
Fig.3. A simple Java program
Suppose we input a slicing criterion (23, a1). Since statement 23 belongs to main method, and belongs to class E, method level slicing criterion is (main, a1), and class level slicing criterion is (E, a1). Assume that all these classes belong to a modular named P, then modular level slicing criterion is (P, a1). In order to get slice at modular level, we start from the node that represents modular P, nd all nodes whose import edges directly or indirectly arrive P node. The set of all these nodes is modular level slice of the Java program with respect to slicing criterion (P, al). In the above example, the modular level slice is P itself because only one modular is in question. In order to get class level slice, we rstly eliminate irrelevant nodes from CLDG based on modular level slice, then from the class enclosing the slicing interest point, statement 23, gure out the set I composed of all nodes that can be reached from class node E along creation edges, and nd the set II of all nodes which can be reached from every class node in set I along inheritance or implement edges. The union of I and II is the class level slice with respect to slicing criterion (23, al). Here, I=fB, D, Eg, II=fAg, thus the class level slice with respect to slicing criterion (23, al) is fB, D, E, Ag. To get the method level 14
slice, we rst eliminate irrelevant method nodes and variable nodes of class C and A from MLDG based on class level slice set fB, D, E, Ag. Then traverse backward from f3 node of D along de ning edges, we get node a of D. Then traverse backward from nodes a of D and x of B along used-by edges, we get nodes f1 of B and main. Thus, the method level slice is fmain, D f3, B f1, D a, B xg. By eliminating all the irrelevant statements from SLDG based on method level slice set fmain, D f3, B f1, D a, B x g, we get the statement level slice that is shown in Fig.4. slice 1. class Af 2. public in x 3. 4. g 5. class B extends Af 6. public int y 7. public f1( ) 8. fx=2g 9. 10. g 11. 12.
13. 14. 15. class Df 16. public void f3(A a) 17. fa.f1( ) 18. return g 19. class Ef 19. class Ef 21. A a1=new B( ) 22. D d1=new D( ) 23. d1.f3(a1)gg
Fig.4. The resulting statement level slicing with respect to slicing criterion (23, a1) of Java program in Fig.4.
Now, let's look at how much contribution the program P give to class E. S Slice(P E V E )) ; N(E)) #(( FlowEP =
v2V (E )
E a1)) ; N(E)) = 5 = #((Slice(P N(P ) ; N(E) 9 (15)
N(P ) ; N(E)
FlowEP shows that the relative amount of information ows from program p (which including class E) to class E, i.e., the contribution of program p to class E with respect to a1. Since class E includes main method, FlowEP can help to determine the importance of other parts of the program in performing the speci ed functions. We also discuss the degree of correlation of two classes from this example. Considering class-level slice. the class-level slice with respect to slicing criterion (23, al) is fB, D, E, Ag. The contribution of class A, B, C and D Sto class E may be computed respectively as follows: #(( Slice(P E V E )jN (A)) = #((Slice(NP (EE)al)jN (A)) = 25 Flow(PA E) = v2VSE N (E) ( )
Flow(PB E) = Flow(PC E) =
#((
#((
v2V (E)
S
v2V (E)
Slice(P E V E )jN (B ))
N (E ) Slice(P E V E )jN (C )) N (E )
15
= #((Slice(NP (EE)al)jN (B)) = 45
= #((Slice(NP (EE)al)jN (C)) = 05 = 0
#((
S
Slice(P E V E )jN (D))
= #((Slice(NP (EE)al)jN (D)) = 45 By now, it is very obvious which class is more important to class E with respect to al. In order to compute the degree of compuling between two classes, we must compute another slice, for the limited space, other aspects are ignored here. Example 2 Fig.5 represents a method written in c++ language and its three slices considering variables a, b and c.
Flow(PD E) =
source program 1. sumprodsub() f
v2V (E)
N (E )
slice(13, c) sumprodsub()
slic(12, b) sumprodsub()
f
f
slice(11, a) sumprodsub() f
2. int a=0 int a=0 3. int b=1 int b=1 4. int c=100 int c=100 5. int i,n=10 int i,n=10 int i,n=10 int i,n=10 6. for(i=1i < ni++) for(i=1i < ni++) for(i=1i < ni++) for(i=1i < ni++) f
7.a=a+i 8.b=b*i 9.c=100-i 10.g 11.printf("%dnn",a) 12.printf("%dnn",b) 13.printf("%dnn",c) g
f
f
b=b*i
c=100-i g
g
printf("%dnn",c) g
printf("%dnn",b) g
f
a=a+i g
printf("%dnn",a) g
Fig.5. A c++ method m and its three slices about variables a, b and c respectively.
Then the coupling between variable a and variable b, variable a and variable c, variable b and variable c is as follows respectively. #(Slice(sumprodsub 11 a)\Slice(sumprodsub 12 b)) 3 Coupling(a b) = #( Slice(sumprodsub 11 a)Slice(sumprodsub 12 b)) = 13 Slice(sumprodsub 11 a)\Slice(sumprodsub 13 c)) 3 Coupling(a c) = #( #(Slice(sumprodsub 11 a)Slice(sumprodsub 13 c)) = 13 Slice(sumprodsub 12 b)\Slice(sumprodsub 13 c)) 3 Coupling(b c) = #( #(Slice(sumprodsub 12 b)Slice(sumprodsub 13 c)) = 13 Note that there are same degree of coupling between variables a and b or a and c or a and c. It shows that the three variables have the same important position in this method. But since 133 is much less than 0.5, we can think that the correlation between a and b or a and c or a and c is very low, i.e., it will be very low for one variable to a ect another one when it is modi ed.
6 Related Work A great deal of recent studies have been carried out into coupling and associated metrics. Chidamber and Kemerer3,4] gave an initial de nition of 16
coupling as any evidence of a method of one object. The initial de nition of the Chidamber and Kemerer Coupling Between Objects (CBO) metric excluded coupling due to inheritance. Eder et al.5] presented three dimensions of coupling, i.e., interaction coupling, component coupling and inheritance coupling. our measuring coupling framework is based on the three dimensions of coupling, but extends them for computing the degree of coupling based on hierarchical slicing models. Briand et al. describe coupling as the degree of interdependence among the components of a software system 1]. They also present a uni ed framework for coupling measurement in object-oriented system, in 2] they compared several current coupling measurement frameworks based on multiple attributes, and give uni ed framework based on the common attributes, their work is excellent. Hitz and Montazeri 9] propose a framework for dealing with coupling and cohesion in OO systems making the distinction between object level and class level coupling, the former relating to the state of an object at run-time, which may be di erent to the static class level coupling of the latter. Li and Henry 14] describe class level coupling in terms of data abstraction coupling (DAC), measured in terms of instance variables having an abstract data type. Harman et al.12] rst address the coupling measurement using slicing, but he only study functional coupling problem in functional program.
7 Conclusion and Future Work In this paper, we have established a measuring coupling framework based on hierarchical slice model (HSM). We can compute the coupling over di erent levels based on the framework. Especially, we mainly discuss the computation of variables-related coupling, information ow related coupling and inheritance coupling. Observe that slice-based measurement is more precise measure of dependency than information ow, since the presence in the slice of a single node outside the body of m indicates an information ow from c (including m) to m. However, as well as detecting such a ow by determining precisely how much of the slice lies outside the body of m. The slice-based measurement is therefore more precise in describing the level of information ow than measurements that merely detect its presence. Note that this paper only forward the rst step to object-oriented coupling measurement with program slicing model, there are still many aspects about object-oriented coupling measurement needed to be studied in future work. More detailed models may be necessary to derive speci c coupling metrics, and nested units make it more dicult to use slice models to model systems. Measurement tools developed for supporting the framework are needed. Future research 17
ought to focus on quantitative evaluations of structural style, and the relation between style and attributes such as reuse, reliability, and maintainability. We also need better the hierarchical slicing models for deriving other objectoriented metrics.
References 1] L. Briand, J.W.Daly, and J. Melo. An investigation into coupling measures for c++. In proceedings of the 19th International Conference on Software Engineering (ICSE'97), Keele, UK, 1997. 2] L. Briand, J.W.Daly, and J. Wust. A uni ed framework for coupling measurement in object-oriented systems. Isern-96-14, Fraunhofer Institute for Experimental Software Engoneering,1996. 3] S. Chidamber and C. Kemerer. A metrics suite for object oriented design. IEEE Trans. Software Engineering, 20(6). pages 476{493, 1(1994) 4] S. R. Chidamber and C. F. Kemerer. Towards a metrics suite for object oriented design. Proc. OOPSLA'91, pages 197{211, October 1991. 5] J. Eder, G. Kappel, and M. Schre. Coupling and cohesion in objectoriented system, technical report, Univ. of Klagenfurt, 1994. 6] Tip, F., Choi, J.-D., Field, J., and Ramalingham, G. (1996). Slicing class hierarchies in C++. In Proceedings of the 11 th conference on Object-Oriented Programming, Systems, Languages and Applications (OOPSLA'96), San Jose. 31 7] B. Henderson-Sellers. Some metrics for object-oriented software engineering. Proc. TOOLs Paci c '91 (Technology of Object-Oriented Languages and Systems, pages 131{139, 1991. 8] S. Henry and D. Kafura. Software structure metrics based on information ow. IEEE Trans. Software Engineering, SE-7(5):510{518, 1981. 9] M. Hitz and B. Montazeri. Measuring prodct attributes of objectoriented systems. W. Sch?fer and P. Botella, eds. Proceedings of ESEC'95 Fifth European Software Engineering Conference, Barcelona, Spain, Sept. 1995, Lecture Notes in Computer Science 989, SpringerVerlag, 1995. 18
10] Susan B. Horwitz and Thomas W. Reps. The use of program dependence graphs in software engineering. In Proceedings of the Fourteenth International Conference on Software Engineering, Melbourne, Australia, May 1992. 11] Susan B. Horwitz, Thomas W. Reps, and David Binkley. Interprocedural slicing using dependence graphs. In Proceedings of the ACM SIGPLAN '88 Conference on Programming Language Design and Implementation, volume 23(7) of ACM SIGPLAN Notices, pages 35-46, Atlanta, GA USA, July 1988. 12] Mark Harman, Margaret Okunlawon, Bala Sivagurunathan and Sebastian Danicic. Slice-Based Measurement of Coupling. IEEE/ACM ICSE workshop on Process Modelling and Empirical Studies of Software Evolution ( PMESSE'97), Boston, Massachusetts, 17th - 23rd May 1997, pages 26-32. 13] H.D. Longworth. Slice-based program metrics. Master's thesis. MTU, Department of Computer Science, 1985. 14] W. Li, S. Henry, D. Kafura, and R. Schulman. Measuring object-oriented design. Journel of Object-Oriented Programming, vol. 8, no. 4, pages, 48-55,1995. 15] Loren D. Larsen and Mary Jean Harrold. Slicing object-oriented software. In Proceedings of the 18th International Conference on Software Engineering, pages 495-505, Berlin, March 1996. 16] D. Liang and M.J. Harrold. Slicing objects using system dependence graphs. In Proceedings of the 1998 International Conference on Software Maintenance, pages 358-367, November 1998. 17] Bixin Li. Program slicing techniques and its application in objectoriented software metrics and software test. Ph.D thesis, Nanjing University, P.R.China, Dec., 2000. 18] A. Krishnaswamy, "Program Slicing: An Application of Object-Oriented Program Dependency Graphs," Technical Report TR94-108, Department of Computer Science, Clemson University, 1994. 19] Karl J. Ottenstein and Linda M. Ottenstein. The program dependence graph in a software development environment. In Proceedings of the 19
ACM SIGSOFT/SIGPLAN Software Engineering Symposium on Practical Software Development Environments, volume 19(5) of ACM SIGPLAN Notices, pages 177-184, 1984. 20] L. M. Ott. Using slice pro les and metrics during software maintenance. Proc. 10th Annual Software Reliability Symp, pages 16{23, June 1992. 21] L. M. Ott and J.J. Thuss. Slice based metrics for estimating cohesion. Proc. 1993 IEEE-CS Int. Software Metrics Symp., pages 71{81, May 1993. 22] Christoph Steindl. Intermodular slicing of object-oriented programs. In International Conference on Compiler Construction (CC'98), 1998. 23] M.D. Weiser. Program slicing. In proceedings of the 5th International Conference on Software Engineering, pages 439-449. IEEE,1982. 24] Mark Weiser. Program slicing. IEEE Transactions on Software Engineering, 10(4):352-357, July 1984 25] Jianjun Zhao, Jingde Cheng, and K. Ushijima. Slicing concurrent logic programs. In T. Ida, A. Ohori, and M. Takeichi, editors, Second Fuji International Workshop on Functional and Logic Programming, pages 143-162, 1997. 26] Jianjun Zhao. Dynamic slicing of object-oriented programs. Technical Report SE-98-119, Information Processing Society of Japan (IPSJ), May 1998
20
Turku Centre for Computer Science Lemminkaisenkatu 14 FIN-20520 Turku Finland http://www.tucs.abo.
University of Turku Department of Mathematical Sciences
Abo Akademi University Department of Computer Science Institute for Advanced Management Systems Research
Turku School of Economics and Business Administration Institute of Information Systems Science
