an abstract approach to cohesion...

32
An Abstract Approach to Cohesion Evaluation Sérgio Bryton, Fernando Brito e Abreu November 2006 Unlimited distribution subject to the copyright. Technical Report FCT/QUASAR-2006-TR-206

Upload: doananh

Post on 04-Jan-2019

223 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

An Abstract Approach to Cohesion Evaluation Sérgio Bryton, Fernando Brito e Abreu November 2006 Unlimited distribution subject to the copyright.

Technical Report FCT/QUASAR-2006-TR-206

Page 2: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

Contents

1 Introduction 1

1.1 Cohesion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 AOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Report structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Case Study 3

3 Factors 5

3.1 Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.1.1 Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.1.2 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.1.3 Density . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.1.4 Transitiveness . . . . . . . . . . . . . . . . . . . . . . . . . 73.1.5 Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . 83.1.6 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 Metrics contribution analysis . . . . . . . . . . . . . . . . . . . . 93.2.1 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Metrics 11

4.1 De�nitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Related Work 16

6 Conclusions and Future work 17

A Conventional logging 19

B AspectJ logging 23

C Metrics contribution 27

D Size metrics 28

E Sizeless metrics 29

i

Page 3: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

List of Figures

2.1 Shopping-cart UML Class diagram . . . . . . . . . . . . . . . . . 3

iii

Page 4: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

List of Tables

1.1 Meyer's object-oriented system architecture elements . . . . . . . 1

3.1 Metrics contribution summary . . . . . . . . . . . . . . . . . . . 10

4.1 Size metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2 Sizeless metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.3 Average metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

C.1 Metrics contribution . . . . . . . . . . . . . . . . . . . . . . . . . 27

D.1 Source Cohesion Size Metrics . . . . . . . . . . . . . . . . . . . . 28

iv

Page 5: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

Acknowledgments

This technical report has been developed under the SOFTAS ( POSC / EIA /60189 / 2004 ) project.

v

Page 6: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

Abstract

Cohesion, as a dimension of modularity, is of great importance to softwaremaintainability and reuse which are ever present concerns when it comes todesign and maintenance activities, and also when new paradigms, from whichAOP can be a good example, must be evaluated.

The most prominent proposed frameworks for cohesion measurement arehighly focused on the coupling mechanisms from the paradigm to which they aredeveloped for, instead of being focused at the phenomenon itself. This approachrestricts the use of these frameworks to each paradigm; also, di�erent paradigmscan not be compared because di�erent mechanisms can not be compared, andcomparing only the common mechanisms from di�erent paradigms is compar-ing only part of the cohesion and, as such, inconclusive. Consequently, thephenomenon understanding remains vague; otherwise, with the existing knowl-edge, we would be able to clearly say how to improve it, regardless of paradigmor language.

Also, cohesion is a phenomenon present at every development phase (design,implementation, etc) and system state (static or dynamic), and as such, its eval-uation must always be possible, contrary to the speci�cs of current frameworks.

A di�erent approach on cohesion will be proposed. This approach is basedon a cohesion empirical study focused on the di�erent ways that cohesion canbe looked at. A new taxonomy for cohesion will be proposed - the cohesionfactors. Each cohesion factor can distinguish features on itself and, all the factorscombined, give a clearer picture of the cohesion phenomenon, enabling a betterreasoning on the ways it can be improved, and allowing cohesion measurementregardless of paradigm, language, development phase or system state, in orderto enable improvements and comparisons.

Page 7: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

Chapter 1

Introduction

1.1 Cohesion

Cohesion is the degree of interaction within a module 1. At a good softwaredesign, high cohesion is a goal to achieve. This means that the software moduledoes exactly, and only, what it was designed for 2.

Eventhough cohesion has been discussed for a long time now, it is everythingbut a closed subject. Whenever new paradigms emerge, maintainability is anissue to ponder and, consequently, cohesion bene�ts, must be evaluated, withinthe new context, with proper metrics.

Throughout this report, �ne grained cohesion units and Meyer's de�nitionsfrom the elements of an object-oriented system architecture 3, where a system isa set of clusters, a cluster is a set of modules, and a module is a set of features,will be used.

Cluster Module FeatureUML Component Class, Interface Method, PropertyJava Package Class, Interface Function, Variable

AspectJ Package Aspect Advice, Pointcut

Table 1.1: Correspondence between some concepts from di�erent languages andMeyer's object-oriented system architecture elements

1.2 AOP

Aspect-Oriented Programming (AOP) is an emergent and becoming widely usedparadigm, as an evolution on Object-Oriented Programming (OOP).

AOP eliminates some of OOP disadvantages, categorized as code tanglingand code scattering, thus increasing modularity and consequently maintainabil-ity, as widely claimed but still unproven and disputable, until such bene�ts canbe adequately quanti�ed and validated.

1fazer referencia ao livro do schach2referencia sobre os ideiais da coesao. relacionar manuteno com modularidade e com facil-

idade de manuteno3fazer referencia ao livro do meyer

1

Page 8: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

As such, AOP e�ects on cohesion are predictable and must be analyzed.Several metrics for evaluating cohesion at AOP have already been proposed,but while most of them are merely an adaptation from their OOP counterpartsand do not capture well the new paradigm features, other are too AOP speci�cand cannot be applied to OOP, thus denying any comparison possibility.

Having the evaluation of AOP cohesion bene�ts for a goal, new metrics forthis purpose must attain to three essential requirements; they must be applicableindependently of the paradigm being used, they must be language independent,and �nally they must capture well the cohesion changes that AOP is claimed tointroduce.

1.3 Report structure

At chapter 2 a case study will be presented, which will be used for di�erentpurposes throughout the rest of the document.

Next, at chapter 3, cohesion factors will be presented and discussed, andan assessment on some of the existing metrics contribution to cohesion factorsmeasurement will be performed.

At chapter 4, several metrics for cohesion factors will be proposed to demon-strate their adequacy to evaluate and compare cohesion at systems, indepen-dently of their paradigm or language, with particular emphasis on OOP andAOP functional equivalent systems.

Finally, chapters 5 and 6 present related work and conclusions and futurework respectively.

2

Page 9: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

Chapter 2

Case Study

The following case study, which will be used throughout this report, is a loggingexample developed by R. Laddad[Lad03]. It was chosen due to its easy ofunderstanding and because logging is eventually one of the most used featuresto explain AOP and its modularity bene�ts, namely on cohesion by the reductionof code tangling.

The example is a shopping-cart functionality, at which logging is imple-mented in two di�erent ways, the conventional way and the AspectJ way, bothmaking use of the standard Java Logging API. The code corresponding to bothimplementations can be found at appendixes A and B respectively.

The shopping-cart system is composed by 4 classes; the Item class whichmodels a shopping item that can be purchased; the ShoppingCart class whichmodels a shopping cart; the Inventory class which models the shop inventory,and the ShoppingCartOperator class which manages the shopping cart. Thereis also the Test class designed to test the whole system.

Figure 2.1: Shopping-cart UML Class diagram

The conventional implementation of logging embeds the logging invocationsin each module, thus originating code tangling.

3

Page 10: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

The AspectJ implementation of logging adds the aspect TraceAspect to thesystem, which modularizes the logging concern by implementing the loggingfunctionality, thus eliminating the need for core modules to carry any logging-related code.

4

Page 11: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

Chapter 3

Factors

3.1 Taxonomy

Several metrics for cohesion have already been proposed. Examples of these forthe object-oriented paradigm are those from. . . For the aspect-oriented paradigmwe have. . .

Most of these metrics are highly focused at the cohesion mechanisms fromthe paradigm to which they are developed for, that is, they try to capture theways each paradigm feature implements cohesion. An example of this wouldbe. . .

Without questioning the importance of such mechanisms on cohesion, as wellas the e�ort on understanding and measuring them, cohesion is beyond cohesionmechanisms. When a new paradigm arrives, cohesion persists, with new andperhaps some of the previous mechanisms.

If cohesion exists at systems developed with several paradigms and lan-guages, then it should be comparable among them; however, if the only mea-sures, available up to date, are of cohesion mechanisms, and those di�er betweenparadigms and languages, they can not be compared, which means we don't fullyunderstand it, and its implications, besides the mechanisms themselves.

If cohesion is really explain by cohesion mechanisms measurement, then weshould be able to understand how to combine, or how to switch them, in orderto optimize it.

Therefore, either cohesion mechanisms measurement is not adequate to co-hesion understanding, or cohesion mechanisms measurement by itself does notexplain cohesion.

Cohesion is the relative interdependence among a modules features. As such,this relation is what cohesion really is, regardless of paradigms, languages andthe ways it can be instantiated - the cohesion mechanisms.

This relation between features, is what must be understood, the di�erentview points we can use to look at it, how they relate with each other and howthey relate with cohesion, and then, what are the contributes of each cohesionmechanism to it, how they should be measured, and how they can be combinedor switched to improve cohesion.

A measure must preserve our intuitive notions about the attribute and theway in which it distinguishes di�erent objects [Kitchenham95]. Once the inten-

5

Page 12: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

tion is to measure cohesion, the intuitive notions about cohesion have to be putout front, and the way it distinguishes di�erent objects must be analyzed, to�nd the cohesion factors.

The relation between features can be looked at from di�erent view points.Cohesion factors are those view points.

Cohesion factors can be assessed at any development phase (high/low leveldesign, implementation) or system state (static or dynamic), as long as themetrics used capture well the inherent cohesion mechanisms.

A cohesion relation is the dependency relation that exists between a pair offeatures from a module. The feature which initiates the relation will be calledthe source, and the one which receives it will be called the target.

A cohesion instance is the concrete implementation of a cohesion relation. Acohesion relation can have di�erent instances, like when a method calls anothermethod several times within its execution.

The concrete implementation of the previous cohesion relation occurs atfeature getPrice() from class Item.

3.1.1 Role

Once that a cohesion relation always implies two features, these have di�erentroles, the source and the target, according to which has initiated the cohesionrelation. Has said before, a cohesion relation is a dependency relation. Thesource depends on the target, because if the source needs to use the target, andthe target is changed or removed, it will most certainly a�ect the source, beingthis the reason for the need to understand from which features a source may bea�ected. For the same reason, it is also important to understand which featuresa target might a�ect.

Features contribute to the overall module's cohesion when they act as sourcesor targets and therefore it is important to understand a features contribution tocohesion from both roles. A feature might also exclusively act as a source or asa target, within a module, being this another reason to understand a featurescontribution to cohesion from both roles.

3.1.2 Structure

Features can be distinguished based on the way its cohesion relations are dis-tributed by other features.

Coverage

A feature, when executing the task to which it was implemented, will mostnaturally relate with other features; it is desirable that it does. Also, a featuremay be the target of cohesion relations from other features.

Coverage expresses the amount of di�erent features that relate to a speci�cfeature.

From the source point of view, coverage is the amount of di�erent targetswithin its cohesion relations.

Picture x provides an example for source coverage with two modules, m1and m2 both with three di�erent features, f1, f2 and f3. At m1 there are twocohesion relations from feature f1 to features f2 and f3 respectively, and at m2

6

Page 13: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

there is only one cohesion relation from feature f1 to f2, all represented by arrowswhere the start indicates the source of these cohesion relations which is alwaysf1. At this example, density from each cohesion relation is always the same andtransitiveness and ownership are not being considered.

At our example from picture x, feature f1 from module m1 has higher cover-age then f1 from m2 and therefore provides a higher contribute to its modulescohesion. From the target point of view, coverage is the amount of di�erentsources within its cohesion relations. Picture y provides an example for targetcoverage with two di�erent modules, m1 and m2, both with three di�erent fea-tures, f1, f2 and f3. At module 1 there are two cohesion relations, one fromfeature f1 to f2, and another one from feature f2 to f3. At module m2 there arealso two cohesion relations, one from feature f1 to f3 and another from featuref2 to f3. All cohesion relations are represented by arrows where their start is thesource. At our example, density from each cohesion relation is always the sameand transitiveness and ownership are not being considered. At our examplefrom picture y, feature f3 from module m2 has higher coverage than feature f3from module m1 and provides a higher contribute to its module's cohesion.

3.1.3 Density

The more instances a cohesion relation has, the more this relation is contributingto the overall module's cohesion, because the dependency relation from thesource to the target is stronger than if it had less instances.

Cohesion density expresses the number of instances per cohesion relation,therefore being a factor to consider when analyzing a features contribution tothe overall module's cohesion or comparing it with other features. A cohesionrelation can have many instances. These can be static or dynamic whetherthey are implemented at design or run-time respectively. Consequently we havestatic and dynamic density, regarding when we measure it. At picture x is anexample of density. There are two modules, each of them with two features, f1and f2.

At each module there is a cohesion relation between its features, where f1is the source and f2 is the target. However, while at module 1 this couplingrelation has 1 instance, at module 2 there are 3 instances for the same couplingrelation. At both modules these instances are represented by arrows.

At our example, f1 depends more on f2, at module 2, than the homonymousfeatures at module 1, because it has more cohesion instances. Thus, the cohesionrelation from f1 to f2 at module 2 has higher density and is consequently morecohese then the coupling relation from f1 to f2 at module 1. . . . source and targetpoints of view. . . actualizar a imagem. . .

3.1.4 Transitiveness

At a cohesive module, features interact to achieve some purpose. One featureuses another which, in turn, uses a di�erent one, and so on. When one featureexplicitly uses another, we would say that the �rst has a direct cohesion relationto the latter. On the other hand, if one feature uses another which, in turn, usesa di�erent one, we may say that the �rst one indirectly uses the last one, whichwould be the same to say that the �rst one has an indirect cohesion relation tothe last one. We may also de�ne a cohesion relation as being indirect when it

7

Page 14: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

is the consequence of another cohesion relation. Once that a module's cohesionresults from each features relations, every cohesion relation must be taken intoconsideration when analyzing it, wether being direct or indirect. Indirect co-hesion relations are important to the overall module's cohesion, once that theyidentify hidden cohesion relations that strengthen the module's cohesion. Atpicture x we have an example of both ways of transitiveness where cohesionrelations are represented by arrows. At module 1, feature f1 uses feature f2,which in turn uses feature f3. Therefore, feature f1 has a direct cohesion rela-tion with f2 and an indirect cohesion relation with f3. At module 2, feature f1uses features f2 and f3. Therefore, feature f1 has direct cohesion relations withfeatures f2 and f3.

. . . source and target points of view. . . images . . . why can't features be con-sidered to contribute equally to a module's cohesion when they have di�erentcohesion relations? . . .

3.1.5 Ownership

The set of features from a module contains not only features which are imple-mented there and to which we will call native, but may also contain some thatare not implemented there, which we will call adopted.

Programming paradigms like object-oriented and aspect-oriented program-ming have mechanisms, like inheritance and introductions respectively, withwhich is possible to implement adopted features.

Once that these features belong to the module's set of features, native fea-tures may eventually use them and vice-versa, therefore establishing relationsthat might be considered as cohesion relations. We will call these adoptedcohesion relations. We will call relations between native features only native co-hesion relations. It is our belief that only native relations should be consideredfor cohesion measurement and that adopted relations should be considered whenmeasuring coupling in the context of density and ownership coupling factors,once that they are implemented at di�erent modules.

. . . source and target points of view . . .

. . . images . . .

. . . why can't we consider adopted features as contributing to the module'scohesion??? . . .

3.1.6 Type

A cohesion instance, depending on the mechanism being used, can introducelower or higher levels of cohesion. As such, cohesion type should be used tomeasure each cohesion instance strength. In spite some research has been doneon this area, like the one from . . . , further research is necessary in order toevaluate how each mechanism type can contribute to the overall cohesion eval-uation.

Cohesion type as originally de�ned by [. . . ] expresses the way cohesion islower or higher, depending on the way it is implemented. It can be, from thelowest to the highest, as follows: . . .

8

Page 15: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

3.2 Metrics contribution analysis

So far, many cohesion metrics have been proposed for di�erent paradigms.Most of them are heavily based on speci�c cohesion mechanisms from thoseparadigms.

Cohesion factors measurement for a speci�c software system must be achievedthrough the measurement of cohesion mechanisms from the particular paradigmused to implement that system.

Therefore, it is important to understand to which cohesion factors measure-ment these metrics contribute. It is also important to �nd out which cohesionfactors require further metrics development.

3.2.1 Metrics

Given the importance of OOP at the actual programming context and the emer-gent and promising AOP, we chose to analyze some of the metrics used to mea-sure cohesion at these paradigms.

The selected OOP metrics have previously been analyzed in the context ofthe Uni�ed Framework for Cohesion Measurement in Object-Oriented Systemsproposed by Briand [BDW97]. These metrics were originally proposed by Ederet al. [EKS94], Chidamber and Kemerer [CK91] [CK94], Hitz and Montaz-eri [HM95], Bieman and Kang [BK95], Henderson-Sellers [HEN96], Lee et al.[LLWW95] and Briand et al. [BMB93] and [BMB94].

For this analysis were also selected metrics for AOP cohesion measure-ment; these were proposed by Zhao [ZHAO04], Ceccato and Tonella [CT04]and Sant'Anna et al. [SGCS05]

3.2.2 Analysis

Up until now, most of the metrics proposed to evaluate cohesion at structuredprogramming, object-oriented programming and now AOP, have put a greatemphasis on cohesion mechanisms, and has been an evidence that these haveincreased in variety and complexity.

However, these metrics' contribution to measure the di�erent ways cohesionrelations can distinguish features is still very scarce, which means that eventhough cohesion mechanismshave been addressed, cohesion factors were not, orat least not as they should, and therefore cohesion has not been fully addressedby existing metrics.

For a better understanding of how the selected metrics contribute to cohesionfactors measurement, at appendix C we can see for each metric the cohesionfactor to which it contributes.

At table . . . , which is based at appendix C, we can see the number of metricsthat contribute to each ccohesion factor measurement. The content of this tableis represented at graphic . . . .

By contribution we mean that the metrics under study do not necessarilycapture the cohesion factor to its full extent, but may eventually be used forthat purpose, once that they capture it at least partially.

From the analysis we can see that:. . .

9

Page 16: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

For each paradigm, a framework of adequate metrics should exist to fullycapture each cohesion factor, considering every cohesion mechanism with regardto the paradigm for which they are conceived.

Factor NumberCoverage 14Density 1Source 14Target 0Direct 14Indirect 4Native 14Adopted 0

Table 3.1: Number of metrics which contribute to each cohesion factor mea-surement

Existing metrics cover well each paradigm cohesion mechanisms and, as longas being applied with the aim to assess cohesion factors, they can be combinedto achieve that.

Like Briand et al state, it is di�cult to understand how di�erent cohesionmeasures relate with eachother, and unclear the potential uses of many existingmeasures and how these might be used in a complimentary manner [BDW].One of cohesion factors' contributes is bringing some light to this subject. Withcohesion factors, existing mechanism based metrics can complement themselvesto measure one or several cohesion factors, regardless of paradigm or mechanismbeing used.

3.2.3 Conclusions

10

Page 17: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

Chapter 4

Metrics

4.1 De�nitions

This chapter focus on establishing some metrics for cohesion factors measure-ment and exemplifying their usage within the case study proposed at chapter2.

Since one of cohesion factors' goals is to enable metrics development, whichcan be used to compare coupling among functional equivalent systems, namelybetween OOP systems and their AOP refactored counterparts, and that sizevariations between both paradigms are implicit, as well as that metrics should bedimensionless [Abreu], a collection if size and sizeless metrics will be proposed,as well as some metrics based on sizeless metrics, to demonstrate how the lattercan be used to establish comparisons at module and mainly system level.

Further work will focus on these and other metrics and their formalizationwith OCL1 within the MMDM2 methodology [Abreu].

All the metrics proposed at tables 4.1, 4.2 and 4.3 are for demonstrating howcohesion factors can be used to establish metrics adequate to capture cohesionproperties, regardless of paradigm, programming language or system state.

4.2 Examples

The results from the above metrics extraction, from the systems of the casestudy presented at chapter 2, are at tables of appendixes D and E. At appendixD are size metrics from source and target viewpoints, and at appendix E aresizeless metrics, also from both viewpoints.

Size and sizeless metrics for cohesion structure factors were extracted sep-arately for the combinations of the di�erent possibilities of transitiveness andownership.

For a better reasoning on the results achieved, several graphs are presented,one for each structure coupling factor, for both size and sizeless metrics, atappendixes D and E respectively. At each graph we can observe the metricsresults for each module from systems 1 and 2 from our case study, for thecombination of the di�erent possibilities of transitiveness and ownership.

1Object Constraint Language2Meta-Model Driven Measurement

11

Page 18: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

Acronym Name |De�nitionSCohCovS Source Cohesion Coverage Size |Number

ofdif-fer-entco-he-siondes-ti-na-tionsusedbytheco-he-sionre-la-tionsfromafea-ture

TCohCovS Target Cohesion Coverage Size |Numberofdif-fer-entco-he-sionori-ginsusedattheco-he-sionre-la-tionsthathaveafea-tureforatar-get

Table 4.1: Cohesion factors size metrics

12

Page 19: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

Acronym Name |De�nitionSCohCovI Source Cohesion Coverage Index |Percentage

ofdif-fer-entco-he-siondes-ti-na-tionsusedbytheco-he-sionre-la-tionsfromafea-ture

TCohCovI Target Cohesion Coverage Index |Percentageofdif-fer-entco-he-sionori-ginsusedattheco-he-sionre-la-tionsthathaveafea-tureforatar-get

Table 4.2: Cohesion factors sizeless metrics

13

Page 20: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

Acronym Name |De�nitionSCohCovIA Source Cohesion Coverage Index Average |Average

ofSCo-hCovI

TCohCovIA Target Cohesion Coverage Index Average |AverageofTCo-hCovI

FCohIA Feature Cohesion Indexes Average |AverageofSCo-hCovIandTCo-hCovI

MCohIA Module Cohesion Indexes Average |AverageofFCo-hIAfromallfea-turesofamod-ule

SCohIA System Cohesion Indexes Average |AverageofMCo-hIAfromallmod-ulesfromasys-tem

Table 4.3: Cohesion factors average metrics

14

Page 21: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

No ownership or indirect cohesion examples are present at our case study.At appendix E are metrics based on cohesion factors' indexes, for module

and system level cohesion measurement. For a better reasoning on the resultsachieved, two graphs are presented, for the metrics presented at table F. Ateach graph we can observe the metrics results from both systems from our casestudy.

Metrics for density and type cohesion factors will be developed and gatheredwithin the context of future work.

These examples can also be used, with considerable precaution, to help em-pirical reasoning on some of the e�ects AOP can have on OOP cohesion, oncethat our case study tries to simulate a possible OOP to AOP refactoring. How-ever, to take further considerations on this matter, a deeper statistical analysison top of more mature and formalized metrics must be conducted.

4.3 Conclusions

15

Page 22: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

Bibliography

[Lad03] Ramnivas Laddad. Simplify your logging with aspectj.http://www.developer.com/java/other/article.php/3109831, Novem-ber 2003.

18

Page 23: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

Appendix A

Conventional logging

package traditionalLogging;

import java.util.logging.*;

public class Item {

private String _id;

private float _price;

static Logger _logger = Logger.getLogger("trace");

public Item(String id, float price) {

_id = id;

_price = price;

}

public String getID() {

_logger.logp(Level.INFO, "Item", "getID", "Entering");

return _id;

}

public float getPrice() {

_logger.logp(Level.INFO, "Item", "getPrice", "Entering");

return _price;

}

public String toString() {

_logger.logp(Level.INFO, "Item", "toString", "Entering");

return "Item: " + _id;

}

}

19

Page 24: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

package traditionalLogging;

import java.util.logging.Level;

import java.util.logging.Logger;

public class ShoppingCartOperator {

static Logger _logger = Logger.getLogger("trace");

public static void addShoppingCartItem(ShoppingCart sc,

Inventory inventory,

Item item) {

_logger.logp(Level.INFO, "ShoppingCartOperator",

"addShoppingCartItem", "Entering");

inventory.removeItem(item);

sc.addItem(item);

}

public static void removeShoppingCartItem(ShoppingCart sc,

Inventory inventory,

Item item) {

_logger.logp(Level.INFO, "ShoppingCartOperator",

"removeShoppingCartItem", "Entering");

sc.removeItem(item);

inventory.addItem(item);

}

}

20

Page 25: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

package traditionalLogging;

import java.util.*;

import java.util.logging.Level;

import java.util.logging.Logger;

public class ShoppingCart {

private List _items = new Vector();

static Logger _logger = Logger.getLogger("trace");

public void addItem(Item item) {

_logger.logp(Level.INFO, "ShoppingCart", "addItem", "Entering");

_items.add(item);

}

public void removeItem(Item item) {

_logger.logp(Level.INFO, "ShoppingCart", "removeItem", "Entering");

_items.remove(item);

}

public void empty() {

_logger.logp(Level.INFO, "ShoppingCart", "empty", "Entering");

_items.clear();

}

public float totalValue() {

// unimplemented... free!

_logger.logp(Level.INFO, "ShoppingCart", "totalValue", "Entering");

return 0;

}

}

21

Page 26: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

package traditionalLogging;

import java.util.*;

import java.util.logging.Level;

import java.util.logging.Logger;

public class Inventory {

private List _items = new Vector();

static Logger _logger = Logger.getLogger("trace");

public void addItem(Item item) {

_logger.logp(Level.INFO, "Inventory", "addItem", "Entering");

_items.add(item);

}

public void removeItem(Item item) {

_logger.logp(Level.INFO, "Inventory", "removeItem", "Entering");

_items.remove(item);

}

}

package traditionalLogging;

public class Test {

public static void main(String[] args) {

Inventory inventory = new Inventory();

Item item1 = new Item("1", 30);

Item item2 = new Item("2", 31);

Item item3 = new Item("3", 32);

inventory.addItem(item1);

inventory.addItem(item2);

inventory.addItem(item3);

ShoppingCart sc = new ShoppingCart();

ShoppingCartOperator.addShoppingCartItem(sc, inventory, item1);

ShoppingCartOperator.addShoppingCartItem(sc, inventory, item2);

}

}

22

Page 27: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

Appendix B

AspectJ logging

package aspectizedLogging;

import java.util.*;

public class Inventory {

private List _items = new Vector();

public void addItem(Item item) {

_items.add(item);

}

public void removeItem(Item item) {

_items.remove(item);

}

}

23

Page 28: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

package aspectizedLogging;

public class Test {

public static void main(String[] args) {

Inventory inventory = new Inventory();

Item item1 = new Item("1", 30);

Item item2 = new Item("2", 31);

Item item3 = new Item("3", 32);

inventory.addItem(item1);

inventory.addItem(item2);

inventory.addItem(item3);

ShoppingCart sc = new ShoppingCart();

ShoppingCartOperator.addShoppingCartItem(sc, inventory, item1);

ShoppingCartOperator.addShoppingCartItem(sc, inventory, item2);

}

}

package aspectizedLogging;

public class Item {

private String _id;

private float _price;

public Item(String id, float price) {

_id = id;

_price = price;

}

public String getID() {

return _id;

}

public float getPrice() {

return _price;

}

public String toString() {

return "Item: " + _id;

}

}

24

Page 29: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

package aspectizedLogging;

public class ShoppingCartOperator {

public static void addShoppingCartItem(ShoppingCart sc,

Inventory inventory,

Item item) {

inventory.removeItem(item);

sc.addItem(item);

}

public static void removeShoppingCartItem(ShoppingCart sc,

Inventory inventory,

Item item) {

sc.removeItem(item);

inventory.addItem(item);

}

}

package aspectizedLogging;

import java.util.logging.*;

import org.aspectj.lang.*;

public aspect TraceAspect {

private Logger _logger = Logger.getLogger("trace");

pointcut traceMethods()

: execution(* *.*(..)) && !within(TraceAspect) && !within(sampleLogging.*)

&& !within(traditionalLogging.*);

before() : traceMethods() {

Signature sig = thisJoinPointStaticPart.getSignature();

_logger.logp(Level.INFO, sig.getDeclaringType().getName(),

sig.getName(), "Entering");

}

}

25

Page 30: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

package aspectizedLogging;

import java.util.*;

public class ShoppingCart {

private List _items = new Vector();

public void addItem(Item item) {

_items.add(item);

}

public void removeItem(Item item) {

_items.remove(item);

}

public void empty() {

_items.clear();

}

public float totalValue() {

// unimplemented... free!

return 0;

}

}

26

Page 31: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

Appendix C

Metrics contribution

Metric Acronym N A N A N A N A Density ReferenceLCOM1 x [BDW97]LCOM2 x [BDW97]LCOM3 x [BDW97]LCOM4 x [BDW97]LCOM5 x [BDW97]

Table C.1: Number of metrics which contribute to each cohesion factor mea-surement

27

Page 32: An Abstract Approach to Cohesion Evaluationctp.di.fct.unl.pt/QUASAR/Resources/Papers/2006/2006_TR206_QUASAR... · UML Component Class, Interface Method, Property Jaav Pacagek Class,

Appendix D

Size metrics

Table D.1: Source Cohesion Size Metrics for Conventional and Aspectized Log-ging systems from case study at chapter 2

28