Advances in Information Science and Applications - Volume II
Mathematical Model for Object Oriented Class
Cohesion Metric -MCCM
Dr. Omer Saleh,Tejdeda Alhussen Alhadi, Xavier Patrick Kishore, Sagaya Aurelia
Abstract—Despite inherent difficulties, measuring software quality is
important because it makes evaluation and improvement of various
aspects of software. In this study, a new cohesion metric named
MCCM is proposed and its first empirical validations arebeing a
structural metric, MCCM can be used in every stage of software
lifecycle.
Keywords—MCCM; Metric; Cohesion; Connectivity;
Indirect; Method Invocation; Attribute Usage
I
A class with low cohesion does many unrelated things, or
does too much work. Such classes are undesirable; they suffer
from the following problems:
• Hard to comprehend
• Hard to reuse
• Hard to maintain
• Delicate; constantly effected by change [6].
Direct;
III. DEVELOPED METRIC: MCCM
I. INTRODUCTION
Three steps are followed while calculating the cohesion of a
class using the new metric. In the first step, the relationship
between methods are examined by looking into the method
invocations and the first graphic (GxA) is obtained. In the
second step, the relationship between methods are examined by
looking into the attribute usage, and the second graphic (GxB) is
obtained. In the third and last step, the graphics created in the
previous steps are combined into one graphic (Gx). In the
remaining sections these steps are elaborated in detail.
n order to improve the software’s quality, the software
quality should be measured at various stages of software
lifecycle and the obtained measures should be compared and
evaluated. One or more metrics should be chosen before
making measurement. At this time, one is faced with the
difficulty of finding properties that are agreed upon about
software quality, which is already hard to define. In order to
begin measuring at the earlier phases of software lifecycle, a
metric needs to use the internal quality factors. Coupling [1]
and cohesion [2] are fundamental properties used for this aim.
In the software that are produced by the proper usage of Object
Oriented Programming (OOP) approach, low coupling and
high cohesion is expected [3]. There are lots of metrics for
coupling and cohesion in the literature, but more empirical
studies are needed as the verification of software metrics is not
easy [4]. In this paper, for the estimation of class cohesion is
based on different relationships that may exist between its
methods. It takes into account several ways of capturing the
functional cohesion of the class, by focusing on Connectivity
between methods.
A. Examination of Method Invocations
A directed line is created between methods from the calling
method to the called method if one of the methods calls the
other. The obtained graphic Gx1 can be expressed asbelow [7]:
If a directed graphic Gx1(V, E) and V = Mx, E={<m, n> € V ×
V|(m calls n)}
M1
M2
Direct
M3
Fig.1. Direct connection graphic (Gx1)
II. CLASS COHESIONMETRICDEFINITION
To find indirect connections, the directed lines are used in
graphic Gx1. By looking at Fig.2, it can easily be seen that
method M1 is calling method M2 and method M2 is calling
method M3. Consequently, method M1 is calling method M3
indirectly. Then, a directed line is created from method M1 to
method M3. The connection graphic Gx2 obtained in this way
can be expressed as such:If a directed graphic Gx2(V, E) and
The degree to which the methods within a class are
related to one another and work together to provide wellbounded behavior. Effective object-oriented designs maximize
cohesion since it promotes encapsulation. Cohesion is an
internal software attribute that depicts how well connected the
components of a software module are. This can be determined
by knowing the extent to which the individual components of a
module are required to perform the same task [5].
Cohesion, in object-oriented terms, is a measure of how
strongly related and focused the responsibilities of a module
are.
V=Mx,
(1)
The graphic Gx2 obtained from graphic Gx1 can be seen in
Fig.2.
Dr. Omer Saleh, Department of Computer Science, Faculty of Education,
Beniwalid, Libya ([email protected])
Tejdeda Alhussen Alhadi, Department of Computer Science, Faculty of
Education, Beniwalid, Libya ([email protected])
Xavier Patrick Kishore, Department of Computer Science, Faculty of
Education, Beniwalid, Libya ([email protected])
Sagaya Aurelia1, Department of Computer Science, Faculty of Education,
Beniwalid, Libya ([email protected])
ISBN: 978-1-61804-237-8
Direct
Indirect
M1
640
M2
M3
Advances in Information Science and Applications - Volume II
considered, the method invocation relation between two
methods can be defined as below [11]:
Fig.2.Indirect connection graphic (Gx2)
As the last step of investigation of method invocations, the
direct and indirect connected methods are shown by combining
the previously obtained graphics Gx1 and Gx2 into one graphic
GxA. The graphic GxA can be seen in Fig.3 which is obtained
from example graphics Gx1 and Gx2 [8][9].
Method_inv(Mi,Mj)=
(2)
Indirect
M1
Direct
Direct
M2
Let n be number of attributes shared by Mi and Mj .
Attr_usg (Mi , Mj)= n
(3)
M3
The relation between two methods, Relation (Mi, Mj), is the
sum of method invocation and attribute sharing between
methods Mi and Mj, where Mi Mx, Mj Mx, and i ≠ j [12].
Fig.3. Method invocation graphic (GxA)
B.
Examination of Attribute Usage
A graph showing a sample case of method-attribute relation is
drawn in order to see attribute usage by methods. If a method
uses an attribute, an undirected line is created between the
method and the attribute [9]. An example graphic GxB which is
obtained in this way can be seen in Fig.4.
M1
M2
Direct
A1
M3
Direct
The total relation value of the class is found from the
relation of two methods as below:
Total_Relation(x) =
(5)
Total_Relation(x) =
M4
Indirect
A3
A2
Relation(Mi,Mj) = Method_inv(Mi,Mj) + Attr_usg(Mi, Mj) (4)
(6)
Direct
A4
The maximum number of public methods pairs is [13]:
n * (n – 1) / 2
Fig.4 Direct and Indirect attribute usage graphic (GxB)
C.
This means an invocation exists in every (Mi, Mj) relation
and this can be found by the number of all possible (Mi, Mj)
relations:
Method Invocation and Attribute Usage
The graphic Gx is obtained by combining the graphics GxA
and GxB created in the previous steps into one graphic. By the
examination of indirect method invocations and determination
of indirect attribute usage, the final version of Gx is obtained. A
Gx graphic which is generated by using the example graphics
given in previous steps can be seen in Fig.5 [10][11].
Max (Method_inv) =
(8)
Similarly, maximum attribute sharing relation in the class
can be defined as; Max (Attr_ usg) = means all attributes of the
class are shared in every (Mi, Mj) relation:
Max_( Att_usg)=
Indirect
M1
Direct
Indirec
A1
(7)
(9)
The value of Max_Relation(X) can be defined as below:
Direct
M2
Direct
M3
Max_Relation (x) =
Direct
Indirect
A3
A2
M4
+
(10)
According to above explanations
A4
MCCM =
Indirect
CI.
Several researchers [4][14][15] have proposed properties
that software metrics should posses in order to increase their
level of confidence; the points considered while developing
MCCM are verified.
Fig.5. Final relationship graphic (Gx)
IV. METHOD CONNECTIVITY COHESION METRIC (MCCM)
•
Let X denote a class, Ix the set of attributes, and Mx the set
of methods of the class. When a directed graphic Gx(V, E) is
ISBN: 978-1-61804-237-8
THEORETICAL VALIDATION
5B
641
Property 1: Non-negativity
Advances in Information Science and Applications - Volume II
The cohesion of a class of an object oriented system should
belong to a specified interval (i.e. Cohesion (C) [0, Max].
Normalization allows meaningful comparisons between the
cohesions of different classes, since they all belong to the same
interval.
• Property 2: Normalization
In the case of Fig.8, the intuition leads one to expect
minimum cohesion as there are no method interactions
involved. Metric computation for the graphic in Fig.8.(a) (m =
3, a = 2) is as follows:
MCCM =
Determines if the result of the metric is normalized i.e.
values returned by the metric is between 0 and 1; classes with
zero cohesion value have the least cohesion while classes with
cohesion value 1 have perfect cohesion.
•
When MCCM is computed for graphic in Fig.8.(b) (m = 2, a
= 1), it is calculated as:
MCCM =
Property 3: Null value and maximum value
The cohesion of a class of an object oriented system is null if
there is no interactions among the components of the class (i.e.
interaction among the methods and attributes of the class) and
it is maximum if the interaction among the components is
maximal.
M2
M1
M3
M2
M1
•
A1
A2
A1
As a result, the proposed metric gave the same value,
depicting minimum cohesion for both of the graphics in Fig.8,
in parallel with the intuition.
The MCCM of a class = 0 if there is no interactions among
the components of the class and MCCM = 1 if all methods are
directly or indirectly connected (i.e. if the interactions among
the components of the class is maximal). Therefore, the value
of MCCM lies in the interval [0, 1] inclusive. Hence, the metric
satisfies the Property 1, 2 and 3.
Consider three classes c1, c2 and c3 such that, Cohesion
(c1) <Cohesion (c2) and Cohesion (c2) < Cohesion (c3), then
Cohesion (c1) < Cohesion (c3).
Fig.7.(b)
Fig.7.(a)
Property 4: Transitivity
Fig.7. Example graphics for maximum relation
When Fig.7 is examined, one intuitively expects the metric
to give the maximum cohesion value “1” for both cases a and
b. Metric computation for the graphic in Fig.7.(a) (m = 3, a =
2) is as follows:
M1
A2
A1
MCCM =
M1
M3
M2
A2
A1
Class A
When MCCM is computed for graphic in Fig.7.(b) (m = 2, a
= 1), it is calculated as:
M1
M2
A3
Class B
M2
M2
M1
M3
MCCM =
As a result, the proposed metric gave the same value,
depicting maximum cohesion for both of the graphics in Fig.7,
in parallel with the intuition.
M1
A1
M2
M3
A2
Fig.8.(a)
M1
A1
A1
A2
A3
Class C (The union of Class A and B)
M2
Fig.9. Example graphics for Transitivity
If we have three classes A, B and C, such that Cohesion
(Class A) < Cohesion (Class B) and Cohesion (Class B) <
Cohesion (Class C). Then it implies that Cohesion (Class A) <
Cohesion (Class C). Therefore, MCCM satisfies the property 4.
A1
Fig.8.(b)
•
Fig.8. Example graphics for minimum relation
ISBN: 978-1-61804-237-8
A2
642
Property 5: Relative number of cohesive interactions
Advances in Information Science and Applications - Volume II
If the interactions among the components of the class
increase, the metric should indicate higher cohesion [16][17].
M3
M2
M1
A2
A1
If the indirect connections are not taken into account, metric
computation for the graphic in Fig.11.(b) is calculated as
follows:
M3
M2
M1
MCCM =
MCCM =
A2
A1
When the indirect connections are not taken into account, the
metric gave the same result. However, it is desirable for a good
metric to differentiate these results. If the indirect connections
are taken into account, metric computation for the graphic in
Fig.11.(a) stays as the same, as there are no indirect
connections in this graphic. If the indirect connections are
taken into account, metric computation for the graphic in
Fig.11.(b) is calculated as follows:
Fig.10.(b)
Fig.10.(a)
Fig.10. Example graphics for interaction
When Fig.10. is examined, one intuitively expects the metric
to give a cohesion value better for Fig.10.(b) than for Fig.10.(a)
as there are more interactions in Fig.10.(b) than there are in
Fig.10.(a). Metric computation for the graphic in
Fig.10.(a) (m = 3, a = 2) is calculated as:
MCCM =
MCCM =
This example shows the importance of considering the
indirect connections: Inclusion of indirect relations into
MCCM has enabled the metric to produce results in parallel
with the intuition.
When MCCM is computed for graphic in Fig.10.(b) (m = 3, a
= 2), it is calculated as:
MCCM =
CIII. CONCLUSION
As computing becomes more pervasive, a software defect
can lead to bad results such as financial loss, time delay or the
loss of human life in even worse cases. Therefore, software
systems should operate as error free and consistent systems.
Increasing demand on software quality introduces us the
“quality” characteristic as an important factor for a software
product. Cohesion, an important quality factor for Object
Oriented Programming paradigm, can be described as the
degree of connectivity among the elements of a single module.
It is expected that cohesion to be high and coupling to be low
in a well designed system [9].
The current state of the MCCM metric is encouraging as it
gives results that are normalized and parallel with intuitions.
MCCM uses both direct and indirect method relations in its
calculations; however, it does not take inherited methods into
account. For these reasons, continuation of empirical works
and the ability to use inherited methods in calculations are
planned as future work.
As a result, it is seen that MCCM depicts higher cohesion as
the interactions among the components of the class increase.
CII.
Point of Consideration: Considering indirect relations
If the indirect connections are not taken into account, the
cohesiveness cannot be measured precisely [18]. In this case, a
metric should indicate lower cohesion. When Fig.11 is
examined, one intuitively expects the metric to give the
cohesion value better for Fig.11.(b) than for Fig.11.(a).
However, if the indirect relations are not taken into account,
this expected result cannot be seen.
Direct
M1
M2
Direct
Direct
M3
Fig.11.(a)
M1
M2
Direct
Indirect
M3
REFERENCES
[1]
Fig.11.(b)
Fig.11. Example for considering indirect relations [19]
[2]
If the indirect connections are not taken into account, metric
computation for the graphic in Fig.11.(a) is calculated as
follows:
ISBN: 978-1-61804-237-8
643
Al Dallal, J. and Briand, L., A Precise Method-Method InteractionBased Cohesion Metric for Object-Oriented Classes, ACM Transactions
on Software Engineering and Methodology (TOSEM), 2012, Vol. 21,
No. 2, pp. 8:1-8:34.
Badri, L. and Badri, M., A Proposal of a New Class Cohesion Criterion:
An Empirical Study, Journal of Object Technology, 3(4), 2004, pp. 145159.
Advances in Information Science and Applications - Volume II
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
management from Canada Global Centre, Canada. Now he is
heading Computer Science department, Faculty of Education,
Azzaytuna University, Baniwalid, Libya. His research interest
includes multicriteria optimization for solving optimal control
problems and Fuzzy logic. He has published 12 papers and
attended various national and international Level conferences
and workshops.
Al Dallal, J., Measuring the Discriminative Power of Object-Oriented
Class Cohesion Metrics, IEEE Transactions on Software Engineering,
2011c, Vol. 37, No. 6, pp. 788-804.
Briand, L. C., Daly, J. W., and Wüst, J. K., "A Unified Framework for
Coupling Measurement in Object-Oriented Systems." IEEE Transactins
on Software Engineering, vol. 25, no. 1, 1999.
Fenton E. N., Pfleeger S. L.: “Software Metrics – A Rigorous &
Practical Approach”, PWS Publishing company, Boston, 1997.
T. Meyers and D. Binkley, An empirical study of slice-based cohesion
and coupling metrics, ACM Transactions on Software Engineering
Methodology, 17(1), 2007, pp. 2-27.
Baldassari, B., Robach, C. and du Bosquet, L., “Early metrics for Object
Oriented Designs”, Proc. 1st Int’l. Workshop on Testability Assessment
(IWoTA), 2004, pp. 62-69.
Kramer, S. and Kaindl, H., "Coupling and cohesion metrics for
knowledge-based systems using frames and rules", ACM Trans. on Soft.
Engineering and Methodology (TOSEM), vol. 13,no. 3, July 2004, pp.
332-358.
Poshyvanyk D., Marcus A., The Conceptual Chesion of Classes. 21st
IEEE Int’l. Conf. on Software Maintenance (ICSM'05), 2005, pp. 133142.
R. Subramanyam and M. Krishnan. Empirical Analysis of CK metrics
for Object-Oriented Design Complexity : Implications for Software
Defects. IEEE Transactions on Software Engineering, 29(4):297-310,
Apr 2003.
Linda Badri and Mourad Badri: “A Proposal of a New Class Cohesion
Criterion: An Empirical Study”, in Journal of Object Technology, vol. 3,
no. 4, April 2004,
Fernndez, L., and Pea, R., A Sensitive Metric of Class Cohesion,
International Journal of Information Theories and Applications, 13(1),
2006, pp. 82-91.
Bieman J. M., Kang B., “Cohesion and Reuse in an Object-Oriented
System”, in Proc. ACM Symp. Software Reusability (SSR’94), 259-262,
1995.
Al Dallal, J., Mathematical Validation of Object-Oriented Class
Cohesion Metrics, International Journal of Computers, 2010, Vol. 4, No.
2, pp. 45-52.
Al Dallal, J. Theoretical validation of object oriented lack-of-cohesion
metrics, proceedings of the 8th WSEAS International Conference on
Software Engineering, Parallel and Distributed Systems (SEPADS
2009), Cambridge, UK, February 2009.
[16] Briand, L. C., Wst, J., and Lounis, H., Replicated Case Studies for
Investigating Quality Factors in Object-Oriented Designs, Empirical
Software Engineering, 6(1), 2001, pp. 11-58.
Marcus, M., Poshyvanyk, D., and Ferenc, R., Using the Conceptual
Cohesion of Classes for Fault Prediction in Object-Oriented Systems,
IEEE Transactions on Software Engineering, 34(2), 2008, pp. 287-300.
Al Dallal, J., Incorporating Transitive Relations in Low-Level DesignBased Class Cohesion Measurement, Software: Practice and Experience,
2013a, Vol. 43. No. 6, pp. 685-704.
Counsell, S., Swift, S., and Crampton, J., The Interpretation and Utility
of Three Cohesion Metrics for Object-Oriented Design, ACM
Transactions
on
Software
Engineering
and
Methodology(TOSEM),Vol.15,No.2,2006,pp.123-149.
Ms. Tejdeda Alhussen Alhadi (Feburary 1, 1980) is now with
Faculty of Education, Azzaytuna University, Bani-walid,
Libya. She is into teaching profession for more than 13 years.
She has done B.Sc and M.Sc in Computer Science from
Libyan Academy. She has also been involved in various
administration related activities. Her specialization includes
Database, Software Engineering and Artifical intelligence. She
has published various national and international papers and
guided many projects.
Mr. Xavier Patrick Kishore (November 6,
1973) received his BSc Mathematics (1994),
Master of Computer Application (2002) and
Diplomas in E-Commerce and Advanced
software Technology. He has received Brain
bench certification in Java and HTML. Now
he is working in Department of computer
science
Faculty
of
Education,
Azzaytuna
University,Baniwalid, Libya.
He
is
specializedin
programming languages.
His current research interest
includes Natural languageprocessing. He has authored more
than 9 papers and attended many conferences.
Er. Mrs. Sagaya Aurelia (November 9,1978)
par-time research scholar in Bharathidasan
university . Now she is with department of
Computer Science, Faculty of Education,
Azzaytuna University, Bani-walid, Libya. She
received her Diploma in Electronics and
Communication (1997),B.E (Bachelor of Engineering
specialized
in
Electronics
and
Communication
Engineering(2000)
and
M.Tech
in
Information
Technology(2004),she has also done her Postgraduation
diplomas in Business Administration
(PGDBA) and
Journalism and Mass Communication (PGDJMC). She has
received Brainbench certification in HTML. Her
current
research interest includes Virtual reality, Augmented reality
and Human Computer Interaction and User interface Design.
She has authored14 papers and attendance several national and
international level workshops and conferences.
Dr. Omer Saleh Mahmod Jamah (January
25,1973) is now the Director of Post graduate
cum Research and Development and Head of
the department of Computer science, Faculty
of education, Azzaytuna university, Baniwalid,
Libya. He received his B.Sc. in Control System
and Measurement (1995), M.Sc. in Electrical
and Computer Measurement (2004), and Ph.D. in Electrical
engineering, Automatics computer science and electronics
from AGH University of technology, Krakow, Poland.
He has done his Diploma in Planning and time
ISBN: 978-1-61804-237-8
644
© Copyright 2024 ExpyDoc
