of 8
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.

ece i 10

  The International Journal Of Engineering And Science (IJES) || Volume || 5 || Issue || 2 || Pages || PP -37- 44 || 2016 || ISSN (e): 2319  –   1813   ISSN (p): 2319  –   1805 The IJES Page 37 A Unified Coupling Model for Coupling Measurement in Object Oriented Software Systems. Calvins Otieno 1 , George Okeyo 2  and Stephen Kimani 3   1  Computing Department, School of Computing and Information Technology,  Jomo Kenyatta University Of Agriculture and Technology, Company Nairobi, Kenya -------------------------------------------------------- ABSTRACT ------------------------------------------------------------ Coupling is the extent to which the functions performed by a subsystem are related. Low coupling is a characteristic of a well-designed subcomponent. The problem noted for research in this paper is lack of  standardization of measures, ambiguity in definition of measures and poor conceptual links between coupling components. The key objective of this research paper is to propose a model for coupling measurement in object oriented software system. A review of related work is conducted on coupling frameworks. In this research data was collected from various software systems, analyzed using a Poisson distribution model and unified coupling model generated. From the model an algorithm was developed for assessing coupling in software systems. In conclusion coupling model of five components; object level coupling, static level coupling, dynamic and static level coupling is developed an algorithm proposed to support coupling measurement in object oriented software  systems. In the unified model developed a coupling value of 0.049 and below indicates low coupling while a coupling value of 0.05 to 0.1 indicates high coupling in the software system. Keywords:   Coupling, Model, Framework, Object Oriented Measurement, Measure. -------------------------------------------------------------------------------------------------------------------------------------- Date of Submission: 29 September 2015 Date of Accepted: 01 March 2016 --------------------------------------------------------------------------------------------------------------------------------------   I. Introduction Coupling measures capture the degree of interaction and relationships among source code elements, such as classes, methods, and attributes in object-oriented software systems. One of the main goals behind object oriented analysis and design is to implement a software system where classes have low coupling among them. Many frameworks have been proposed to measure the coupling and cohesion to predict the fault-proneness and maintainability of software systems [5]. However, few studies have been done using coupling to measure reusability of software components.[5]. Coupling measures are used in tasks such as impact analysis [11], assessing the fault-proneness of classes [2], fault prediction [2], re-modularization, identifying of software components [17], design patterns [11] , assessing software quality[17], etc. In general, one of the goals of the software designers is to keep the coupling in an object oriented design system as low as possible [12].Classes of the system that are strongly coupled are most likely to be affected by changes and bugs from other classes; these classes tend to have an increased architectural importance and thus need to be identified [9]. Coupling measures help in such endeavors, and most of them are based on some form of dependency analysis, based on the available source code or design information. Coupling is considered as one of most important object oriented software attributes. Many frameworks have  been proposed in the last several years to measure class coupling in object-oriented systems. Class coupling (more specifically, functional coupling) is defined as the degree of relatedness between members of a class [14]. In object oriented software systems, a class should represent a single logical concept, and not to be a collection of miscellaneous features. Coupling is a more complex software attribute in object oriented systems but our understanding about coupling measurement factors is poor [8]. There is no standardization for expressing coupling measures; many measures are not operationally defined i.e. there is some ambiguity in their definitions [8]. As a result, it is difficult to understand how different measures relate to one other and what their potential use is. All above aspects ultimately shapes the need of detailed study of coupling measurement in object-oriented systems Briand et al in their research notes that there is little understanding of the motivation and empirical hypotheses  behind many of these new measures [2]. It is often difficult to determine how such measures relate to one another and for which application they can be used. As a consequence, it is very difficult for practitioners and researchers to obtain a clear picture of the state-of-the-art in order to select or define measures for object-oriented systems [2].   A Unified Coupling Model for Coupling Measurement… The IJES Page 38 The fact that there also exists little empirical validation of existing object-oriented coupling measures means the usefulness of most measures is not supported by strong industry results to validate their accuracy [8]. A vast majority of coupling frameworks abound in the literature relies on structural information, which captures relations, such as method calls or attributes usages. However, these structural frameworks lack the ability to identify conceptual links, which, for example, specify implicit relationships encoded in identifiers and objects in source code. This paper proposes a unified model that helps in coupling measurement. The model developed in this paper  provides weights and evaluation function to determine coupling levels in software system. We believe the model would be effective in measurement since it looks into class coupling level, dynamic coupling level, static coupling level and object coupling level. The proposed model has classification criteria that would help reviewers and assessors know whether software is highly coupled or loosely coupled. To enhance the applicability of the model we have developed and proposed an algorithm to outline a The remainder of this paper is organized as follows review of related work is conducted and critique of the  previous model and measures provided, a developed unified model is presented, an evaluation of the model is conducted and results of the evaluation presented, a discussion of the results and model presented and a conclusion of the model and the paper together with request for further research proposed. II. Related Work. In a research by Hitz and Montazeri they described Class Level Coupling (CLC) as coupling resulting from state dependencies between two classes in a system during the development lifecycle [6]. According to their research, Class Level Coupling is important when considering maintenance and change dependencies because changes in one class may lead to changes in other classes which use it [6]. The authors also state that CLC can occur if a method of a class invokes a method or references an attribute of another class. For example if we, let cc be the accessing class (client class), sc be the accessed class (server class). The factors determining the strength of CLC between client class c and server class are [6]: (i)   Stability of sever class: sever class is stable. Interface or body of sc is unlikely to be changed (for instance due to changing requirements). Typically, basic types provided by the programming language, or classes imported from standard libraries are stable. (ii)   Scope of access. Determines where sc is visible within the definition of cc. Within this scope, a change to sc may have an impact on cc. The larger the scope, the stronger the classes are coupled. In a research conducted by Bieman and Kang [1] they proposed two class coupling measures to evaluate the relationship between class coupling and private reuse in the system [1]. Bieman and Kang research focuses on two important criteria of coupling measure; 1   the interaction pattern 2   The special method. According to Biemen and Kang[1] we let ndc (c) be the number of directly connected methods in a class c, nic (c) is the number of indirectly connected methods in a class, and np (c) is the maximum possible number of connections in a class. Then, tight class coupling (tcc) is defined as [1] tcc(c) = ndc(c) / np(c) and loose class coupling (lcc) is defined as: lcc(c) = (ndc(c) + nic(c)) / np(c) This framework focuses on two important criteria of coupling measure; the interaction pattern and the special method. The strongest part in this framework is to consider the interaction between pattern methods. However, the connectivity factor could generate misleading information leading to poor recognition of the interaction  pattern [18]. In another research Chae et al [4] considers two characteristics of classes, which could lead to different coupling values from the general intuition of coupling [4] . The two characteristics are: the patterns of the interactions among the class members (e.g. counting the number of instance variables used by a method) and special methods. According to Chae et al [4], in order to describe these characteristics in class c, a reference graph g r  (c) is drawn to represent the interaction among the members of class c, and is defined to be an undirected graph g r  =(n,a) with[4]: The relationship for evaluating coupling in the frameworks is given as follows   A Unified Coupling Model for Coupling Measurement… The IJES Page 39 Where V(C) is a set of instance variables in the class c, M(C) is a set of methods in the class c, and R  * (M) is a set of instance variables directly/indirectly references by M. In their research Chae et al [4] define glue methods of graph g r  , m g (g r  ), as the minimum set of methods without which its reference graph g r can be divided into disjoint sub-reference graphs. Briand et al define four coupling properties to characterize coupling in a reasonable intuitive and rigorous manner [2]. The four properties are: nonnegative and normalization, null value and maximum value, monotonicity, and merging of unconnected classes [2]. However, these properties are not sufficient to tell that a measure that fulfills them all will be useful; it is likely that a measure that does not fulfill them all is ill-defined. Let R  c the set of relationships within the class c. The set of all intra-class relationships in an object-oriented system is defined as Rc. We say that R  c is maximal, if all possible relationships within class c are presented. We say Rc is maximal if R  c is maximal ∀ c ∈ c [2]. In the very first research conducted by Briand et al in 2005, it was noted that we must have a consensus on the terminology and formal definition of measure expression in software engineering before we are really able to propose and apply a framework. On the other hand, it is stated implicitly that we have to validate the frameworks that we are going to use for assessing or quantifying the attributes of software [2].Briand et al added some criteria to compare various approaches in order to be in the same perspective [2]. The five criteria of the framework to address these varieties are: types of connection (what makes a class coupled), domain of the measures, direct and indirect connections, inheritance, and access methods and constructors [2] . A research conducted by Harrison et al defines coupling between classes (CBC) as a count of the number of classes to which a class is coupled [15]. It counts each usage as a separate occurrence of coupling. This includes coupling via inheritance. This approach only performs normal count and concludes that coupling exists if count is greater than zero [15] . A further research done by Harrison et al considers the Number of Associations (NAS) in a class. In this research three hypotheses related to coupling are investigated by the authors are [15]: (i)   H1: As inter-class coupling increases, the understandability of a class decreases. This hypothesis is rejected by authors. (ii)   H2: As inter-class coupling increases, the total number of errors found in a class increases. This hypothesis is rejected by authors. (iii)   H3: As inter-class coupling increases, the error density of a class increases. This hypothesis is supported by authors. To investigate these hypotheses author studied dependent variables such as (i)   Software Understandability (SU) (ii)    Number of known errors (KE) (iii)   Error per thousand non-comment source lines (KE/KNCSL) Coupling due to object as a parameter of methods and return type for a method is considered by authors [15]. In this research it is noted that source lines of codes framework measures the number of physical lines of active code, which is, no blank or commented lines code [13]. Counting the source lines of code is one of the earliest and easiest approaches to measuring complexity. In general the higher the Source lines of code in a module the less understandable and maintainable the module is [15]. Further research on coupling by Zhao and Xu [19] first consider only direct interaction coupling  between two methods in a class. Their definition is then expanded to indirect interaction coupling via transitive method invocations. The weaknesses are considered in the following two scenarios [19]; III. Unified Coupling Model   To generate unified coupling model total of 15 soft wares were studied and analyzed. The data from the soft wares were analyzed in a Poisson model and parametric table below containing beta values generated. The beta values formed the input to the model as shown in table 1 below.. Poisson model was used to analyses the count data produced in the research. The classes for each software under study was modified and the results recorded in a table. The values were then fed into a Poisson mat lab distribution model and the values generated in the table as shown below   A Unified Coupling Model for Coupling Measurement… The IJES Page 40 Table 1 Parametric Estimates   Table 1 represents Parameter estimates for all the intercept components in the study together with the β value and various W ald chi square values as shown in the table. The β values represent the values for co nstruction for the poison model to be used to build the predictive framework in this research. From the table in can be noted that the overall β=1.090, CLC β=0.64, OLC β= - 10112, SLC β=1.070, DLC β=0.045, CLC*OLC β=0.156,CLC*SLC β= -0.235 From the table 4 th e β can therefore be used to form the poison formula given by ………….. (1)  On substituting the values we have …………….(  2)   Eliminating the logs to generate the natural logs represented by we have the overall class unified formula represented as …………… .(3) The equation 3 above represents the proposed model for this research. The model enables us to evaluate the value for unified coupling in software systems. To construct the model we used the parametric estimates value as shown in table 1. This formula was generated to assess levels of coupling in software systems. The formula involved determining the exponential of class level coupling, object level coupling, static level coupling, dynamic level coupling and combination of CLC and OLC, CLC and SLC. The formula determines their combined effects in coupling in software systems. The various betas exponential values were generated as a result figures obtained from the parametric estimates table.
Related Documents
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks