LCOM1, LCOM2 and LCOM3 — less suitable for VB
LCOM1, LCOM2 and LCOM3 are not as suitable for Visual Basic projectsas LCOM4. They are less accurate especially as they don’t consider theimpact of property accessors and procedure calls, which are bothfrequently used to access the values of variables in a cohesive way.They may be more appropriate to other object-oriented languages such asC++. We provide these metrics for the sake of completeness. You can usethem as complementary metrics in addition to LCOM4.
LCOM1 Chidamber & Kemerer
LCOM1 was introduced in the Chidamber & Kemerer metrics suite. It’s also called LCOM or LOCOM, and it’s calculated as follows:
Take each pair of methods in the class. If they access disjoint sets of instance variables, increase P by one. If they share at least one variable access, increase Q by one.
P – Q
, if P > QLCOM1 =
LCOM1 = 0 indicates a cohesive class.
LCOM1 > 0 indicates that the class needs or can be split into two or more classes, since its variables belong in disjoint sets.
Classes with a high LCOM1 have been found to be fault-prone.
A high LCOM1 value indicates disparateness in the functionality provided by the class. This metric can be used to identify classes that are attempting to achieve many different objectives, and consequently are likely to behave in less predictable ways than classes that have lower LCOM1 values. Such classes could be more error prone and more difficult to test and could possibly be disaggregated into two or more classes that are more well defined in their behavior. The LCOM1 metric can be used by senior designers and project managers as a relatively simple way to track whether the cohesion principle is adhered to in the design of an application and advise changes.
LCOM1 has received its deal of critique. It has been shown to have a number of drawbacks, so it should be used with caution.
First, LCOM1 gives a value of zero for very different classes. To overcome that problem, new metrics, LCOM2 and LCOM3, have been suggested (see below).
Second, Gupta suggests that LCOM1 is not a valid way to measure cohesiveness of a class. That’s because its definition is based on method-data interaction, which may not be a correct way to define cohesiveness in the object-oriented world. Moreover, very different classes may have an equal LCOM1.
Third, as LCOM1 is defined on variable access, it’s not well suited for classes that internally access their data via properties. A class that gets/sets its own internal data via its own properties, and not via direct variable read/write, may show a high LCOM1. This is not an indication of a problematic class. LCOM1 is not suitable for measuring such classes.
Implementation details. The definition of LCOM1 deals with instance variables but all methods of a class. Class variables (Shared variables in VB.NET) are not taken into account. On the contrary, all the methods are taken into account, whether Shared or not.
Project Analyzer assumes that a procedure in a class is a method if it can have code in it. Thus, Subs, Functions and each of Property Get/Set/Let are methods, whereas a DLL declare or Event declaration are not methods. What is more, empty procedure definitions, such as abstract MustOverride procedures in VB.NET, are not methods.
Readings for LCOM1
- Shyam R. Chidamber, Chris F. Kemerer. A Metrics suite for Object Oriented design. M.I.T. Sloan School of Management E53-315. 1993. http://uweb.txstate.edu/~mg43/CS5391/Papers/Metrics/OOMetrics.pdf
- Victor Basili, Lionel Briand and Walcelio Melo. A Validation of Object-Oriented Design Metrics as Quality Indicators. IEEE Transactions on Software Engineering. Vol. 22, No. 10, October 1996. http://www.cs.umd.edu/users/basili/publications/journals/J60.pdf
- Bindu S. Gupta: A Critique of Cohesion Measures in the Object-Oriented Paradigm. Master of Science Thesis. Michigan Technological University, Department of Computer Science. 1997.
LCOM2 and LCOM3 (Henderson-Sellers, Constantine & Graham)
To overcome the problems of LCOM1, two additional metrics have been proposed: LCOM2 and LCOM3.
A low value of LCOM2 or LCOM3 indicates high cohesion and a well-designed class. It is likely that the system has good class subdivision implying simplicity and high reusability. A cohesive class will tend to provide a high degree of encapsulation. A higher value of LCOM2 or LCOM3 indicates decreased encapsulation and increased complexity, thereby increasing the likelihood of errors.
Which one to choose, LCOM2 or LCOM3? This is a matter of taste. LCOM2 and LCOM3 are similar measures with different formulae. LCOM3 varies in the range [0,1] while LCOM2 is in the range [0,2]. LCOM2>=1 indicates a very problematic class. LCOM3 has no single threshold value.
It is a good idea to remove any dead variables before interpreting the values of LCOM2 or LCOM3. Dead variables can lead to high values of LCOM2 and LCOM3, thus leading to wrong interpretations of what should be done.
Definitions used for LCOM2 and LCOM3
m number of procedures (methods) in class a number of variables (attributes) in class mA number of methods that access a variable (attribute) sum(mA) sum of mA over attributes of a class
Implementation details. m is equal to WMC. a contains all variables whether Shared or not. All accesses to a variable are counted.
LCOM2 = 1 – sum(mA)/(m*a)
LCOM2 equals the percentage of methods that do not access a specific attribute averaged over all attributes in the class. If the number of methods or attributes is zero, LCOM2 is undefined and displayed as zero.
LCOM3 alias LCOM*
LCOM3 = (m – sum(mA)/a) / (m-1)
LCOM3 varies between 0 and 2. Values 1..2 are consideredalarming.
In a normal class whose methods access the class’s own variables, LCOM3varies between 0 (high cohesion) and 1 (no cohesion). When LCOM3=0, each method accesses all variables. This indicates thehighest possible cohesion. LCOM3=1indicates extreme lack of cohesion. In this case, the class should besplit.
When there are variables that are not accessed by any of the class’smethods, 1 < LCOM3 <= 2. This happens if the variables are dead orthey are only accessed outside the class. Both cases represent adesign flaw. The class is a candidate for rewriting as a module.Alternatively, the class variables should be encapsulated with accessormethods or properties. There may also be some dead variables toremove.
If there are no more than one method in a class, LCOM3 is undefined.If there are no variables in a class, LCOM3 is undefined. An undefinedLCOM3 is displayed as zero.
Readings for LCOM2/LCOM3
- Henderson-Sellers, B, L, Constantine and I, Graham , ‘Coupling and Cohesion (Towards a Valid Metrics Suite for Object-Oriented Analysis and Design)’, Object-Oriented Systems, 3(3), pp143-158, 1996.
- Henderson-Sellers, 1996, Object-Oriented Metrics: Measures of Complexity, Prentice Hall.
- Roger Whitney: Course material. CS 696: Advanced OO. Doc 6, Metrics. Spring Semester, 1997. San Diego State University. http://www.eli.sdsu.edu/courses/spring97/cs696/notes/metrics/metrics.html
Implementation details. The definition of CBO deals with the instance variables and all the methods of a class. In VB.NET terms, this means non-Shared variables and Shared & non-Shared methods. Thus, Shared variables (class variables) are not taken into account. On the contrary, all method calls are taken into account, whether Shared or not. This distinction does not seem to make any sense, but we follow the original definition.
If a call is polymorphic in that it is to an Interface method in .NET, this is not taken as a coupling to either the Interface or the classes that implement the interface. If a call is polymorphic in that it is to a method defined in a VB Classic interface class (base class), it’s a coupling to the interface class, but not to any classes that implement the interface. This is a limitation of the implementation, not the definition of CBO.
In this implementation of CBO, when a child class calls its own inherited methods, it is coupled to the parent class where the methods are defined. The original CBO definition does not define if inheritance should be treated in any specific way. Therefore, we follow the definition and treat inheritance as if it was regular coupling.
Coupling and Cohesion: The Two Cornerstones of OO Programming
Object-oriented programming has two main objectives: to build highly cohesive classes and to maintain loose coupling between those classes. High-cohesion means well-structured classes and loose coupling means more flexible, extensible software. Applying object-oriented metrics to your design and code can help you determine whether you’ve achieved these goals.
What is Cohesion?
In OO methodology, classes contain certain data and exhibit certain behaviours. This concept may seem fairly obvious, but in practice, creating well-defined and cohesive classes can be tricky. Cohesive means that a certain class performs a set of closely related actions. A lack of cohesion, on the other hand, means that a class is performing several unrelated tasks. Though lack of cohesion may never have an impact on the overall functionality of a particular class—or of the application itself—the application software will eventually become unmanageable as more and more behaviours become scattered and end up in wrong places.
Thus, one of the main goals of OO design is to come up with classes that are highly cohesive. Luckily, there’s a metric to help youverify that you’ve designed a cohesive class.
The LCOM Metric: Lack of Cohesion in Methods
The Lack of Cohesion in Methods metric is available in the following three formats:
LCOM1: Take each pair of methods in the class and determine the set of fields they each access. If they have disjointed sets of field accesses, the count P increases by one. If they share at least one field access, Q increases by one. After considering each pair of methods:RESULT = (P > Q) ? (P - Q) : 0
A low value indicates high coupling between methods. This also indicates potentially high reusability and good class design. Chidamber and Kemerer provided the definition of this metric in 1993.
LCOM2: This is an improved version of LCOM1. Say you define the following items in a class:m: number of methods in a classa: number of attributes in a class.mA: number of methods that access the attribute a.sum(mA): sum of all mA over all the attributes in the class.LCOM2 = 1- sum(mA)/(m*a)
If the number of methods or variables in a class is zero (0), LCOM2 is undefined as displayed as zero (0).
LCOM3: This is another improvement on LCOM1 and LCOM2 and is proposed by Henderson-Sellers. It is defined as follows:LCOM3 = (m - sum(mA)/a) / (m-1) where m, a, mA, sum(mA) are as defined in LCOM2.
The following points should be noted about LCOM3:
- The LCOM3 value varies between 0 and 2. LCOM3>1 indicates lack of cohesion and is considered a kind of alarm.
- If there is only one method in a class, LCOM 3 is undefined and also if there are no attributes in a class LCOM3 is also undefined and displayed as zero (0).
Each of these different measures of LCOM has a unique way to calculate the value of LCOM.
- An extreme lack of cohesion such as LCOM3>1 indicates that the particular class should be split into two or more classes.
- If all the member attributes of a class are only accessed outside of the class and never accessed within the class, LCOM3 will show a high-value.
- A slightly high value of LCOM means that you can improve the design by either splitting the classes or re-arranging certain methods within a set of classes.
New on the Java Boutique:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling API boasts simplicity, ease-of-integration, a well-rounded feature set, and it’s free!
Reverse Complement is a simple applet that converts DNA or RNA sequences into three useful formats.
Elsewhere on internet.com:
Lots of Java information on webdeveloper.com
Thorough Java resource at the Web Developer’s Virtual Library.
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
Low: The convenience store. You go there for everything from gas to milk to ATM banking. Products and services have little in common, and the convenience of having them all in one place may not be enough to offset the resulting increase in cost and decrease in quality.
High: The cheese store. They sell cheese. Nothing else. Can’t beat ’em when it comes to cheese though.