A Pedagogical Evaluation and Discussion about the Lack of Cohesion in Method (LCOM) Metric Using Field Experiment

36 A Pedagogical Evaluation and Discussion about the Lack of Cohesion in Method (LCOM) Metric Using Field Experiment.

Ezekiel Okike

School of Computer Studies, Kampala International University ,
Kampala, Uganda 256, Uganda.

Abstract Chidamber and Kemerer first defined a cohesion measure for object-oriented software – the Lack of Cohesion in Methods (LCOM) metric. This paper presents a pedagogic evaluation and discussion about the LCOM metric using field data from three industrial systems. System 1 has 34 classes, System 2 has 383 classes and System 3 has 1055 classes. The main objectives of the study were to determine if the LCOM metric was appropriate in the measurement of class cohesion and the determination of properly and improperly designed classes in the studied systems. Chidamber and Kemerer’s suite of metric was used as metric tool. Descriptive statistics was used to analyze results. The result of the study showed that in System 1, 78.8% (26 classes) were cohesive; System 2 54% (207 classes) were cohesive; System 3 30% (317 classes) were cohesive. We suggest that the LCOM metric measures class cohesiveness and was appropriate in the determination of properly and improperly designed classes in the studied system. Keywords: Class Cohesion, LCOM Metric, Systems, Software Measurement.

Introduction

Software metric is any type of measurement that relates to a software system, process or related documentation. On the other hand, software measurement is concerned with deriving a numeric value for some attributes of a software product or process. By comparing these values to each other and to standards that apply across an organization, one may be able to draw conclusions about the quality of a software or software processes. The Lack of Cohesion in Methods (LCOM) metric was proposed in [5,6] as a measure of cohesion in the object oriented paradigm.
The term cohesion is defined as the “intramodular functional relatedness” in software [1]. This definition, considers the cohesion of each module in isolation: how tightly bound or related its internal elements are. Hence, cohesion as an attribute of software modules capture the degree of association of elements within a module, and the programming paradigm used determines what is an
element and what is a module. In the object-oriented paradigm, for instance, a module is a class and hence cohesion refers to the relatedness among the methods of a class. Cohesion may be categorized ranging from the weakest form to the strongest form in the following order: coincidental, logical, temporal, procedural, communicational, sequential and functional.
i. Coincidental cohesion: A coincidentally cohesive module is one whose elements contribute to activities in a module, but with no meaningful relationship to one another. An example is to have unrelated statements bundled together in a module. Such a module would be hard to understand what it does and can not be reused in another program.
ii. Logical cohesion: A logically cohesive module is one whose elements contribute to activities of the same general category in which the activity or activities to be executed are selected from outside the module. A logically cohesive module does any of several different related things, hence, presenting a confusing interface since some parameters may be needed only sometimes.
iii. Temporal cohesion: A temporally cohesive module is one whose elements are involved in activities that are related in time. That is, the activities are carried out at a particular time. The elements occurring together in a temporally cohesive module do diverse things and execute at the same time.
iv. Procedural cohesion: A procedurally cohesive module is one whose elements are involved in different and possibly unrelated activities in which control flows from each activity to the next. Procedurally cohesive modules tend to be composed of pieces of functions that have little IJCSI International Journal of Computer Science Issues, Vol. 7, Issue 2, No 3, March 2010 www.IJCSI.org

37 relationship to one another (except that they are carried out in a specific order at a certain time).
v. Communicational cohesion: A communicational cohesive module is one whose elements contribute to activities that use the same input or output data.
vi. Sequential cohesion: A sequentially cohesive module is one whose elements are involved in activities such that output data from one activity serve as input data to the next. Some authors identify this as informational cohesion.
vii. Functional cohesion: A functionally cohesive module contains elements that all contribute to the execution of one and only one problem-related task. The elements do exactly one

…(Full text truncated)…