International Journal of Computer Trends and Technology (IJCTT) – Volume 54 Issue 2-December2017
Software Maintainability and Reusability using Cohesion Metrics
Adekola, O.D#1, Idowu, S.A*2, Okolie, S.O#3, Joshua, J.V#4, Akinsanya, A.O*5, Eze, M.O#6, EbiesuwaSeun#7 #1Faculty, Computer Science Department, Babcock University,Ilishan-Remo, Ogun State, Nigeria *2Faculty, Computer Science Department, Babcock University,Ilishan-Remo, Ogun State, Nigeria #3Faculty, Computer Science Department, Babcock University,Ilishan-Remo, Ogun State, Nigeria #4Faculty, Computer Science Department, Babcock University,Ilishan-Remo, Ogun State, Nigeria *5Faculty, Computer Science Department, Babcock University,Ilishan-Remo, Ogun State, Nigeria #6Faculty, Computer Science Department, Babcock University,Ilishan-Remo, Ogun State, Nigeria #7Faculty, Computer Science Department, Babcock University,Ilishan-Remo, Ogun State, Nigeria
Abstract - Among others, remarkable external software’s lifetime. Ahn et al., (2003) estimated that quality attributes of interest to software practitioners/ maintenance takes up to 80% of the total costof engineers include testability, maintainability and producing software applications. Expectation of reusability.Software engineers still combat achieving more reliable, quicker time-to-market and softwarecrisis and even chronic software affliction maintainable systems. A lot of research has gone into not because there is no standardized software the areas of software reuse and maintenance due to development process but because enough attention is the fact that these among other issues concern not given to seemingly insignificant but crucial intimately system developers/architects/engineers details of internal design attributes such as cohesion rather than end-users. Therehas been enormous and coupling especially in object-oriented systems. growth in software reuse research from the days of Consequently, the aftermath is increased structured programming concepts to object-oriented maintenance cost, effort and time which negatively methods and beyond (e.g. component based plague both the developers and users community. development) (Wang, 2000). Also, reusability being an important part of quality design and time-to-market is equally affected. Most times, software developers have the capability of creating or producing software that functionas This work addresses how to use internal attribute as desired. Theirutmostchallengeis finding ways to cohesion could improve software maintainability and produce software quickly enough to meet up with the reusability. This research also addresses general growing demand for more products and at the same design principles of object-oriented and other reuse- time having to maintain increasingly thriving oriented systems. software “crisis”. Pressman& Maxim, (2015) express the phenomena as software affliction, a long-lasted Keywords: Testability, Maintainability, Reusability, pain or distress. This work does not look in the Cohesion, Coupling, Software Affliction direction of software development life cycle or process flow but rather seeks to consider internal I. INTRODUCTION attributes such as source line of code (SLOC), complexity, cohesion and coupling with a narrowed Maintainability in software constitutes effort and ease focus on cohesion. The most important software required to modify, correct or improve the quality of internal quality metrics are cohesion and coupling a design or product. Maintenance could be done as a (Chidamber&Kemerer, 1994). Generally, internal result of a need to add new features or functionalities, attributes (such as size and cohesion) whether in fix a bug or to increase the strength of the software. traditional or object orientedmethods are critical Maintenance constitutes an essential part of indicators of external attributes which include
ISSN: 2231-2803 http://www.ijcttjournal.org Page 63
International Journal of Computer Trends and Technology (IJCTT) – Volume 54 Issue 2-December2017
understandability, maintainability and reusability. A clever but vital area to consider when it comes to attempting to alleviate software afflictionis toexamine what could be done with internalproperties such as complexity, cohesion, coupling etc.Common questions from literature include the following: are highly cohesivemodulesorcomponentsmore readily reusable, does attention to cohesion yield maintainable systems, do wehave a one-size-fit-all when it comes to software metrics to measure major external attributes?A software metric is a quantifiable measurement of some attributesor an attribute of a software product or process (Frakes& Kang, 2005).
A mapping of empirical world to formal, relational world is what is termed as measurement (Fenton &Pfleeger, 2010). Therefore, a measure is regarded as thenumber or symbol assigned to anentity bysuch Fig 1: Simple illustration of cohesion and coupling; the thick mapping in a bid to get an attribute characterized. lines indicate cohesion and the dotted lines indicate coupling(Source: Adapted from Dhanvani, 2013)
Cohesion implies the degree of relatedness among class members while coupling simply connotes There are many cohesion metrics in literature but the theinterconnectedness of modules within a software metric to employ for a particular instanceneeds to be or a program. A class with high cohesion will be a found out. Mal andRajnish, (2014), discussed a difficult candidate for refactoring, i.e. difficult to split number of metrics which were empirically validated into separate classes (Dallal& Briand, 2009).From against notable open source software projects. their meanings, high cohesion and low couplingshould implya good design as far as software II. METHODOLOGY is concerned. High cohesion,which is ranged within This research embodies case studies, systematic [0,1] shows good design as well as goodquality literature reviews and surveys. Important software (Chidamber&Kemerer, 1994; Okike, 2010a; requirements were identified in related papers. The Okike&Osofisan, 2008; Okike&Rapo, 2015). relevant documents obtained were qualitatively Further, cohesion is a measure of the degree of analyzed for convergence, and relevant details were connectivity among a single class- suffice to say it extracted using inductive approach. Existing reveals or indicates the relationship within a module. measures were evaluated. This work leveraged on For coupling, it is in order to say it indicates Chidamber and Kemerer metrics and Rajnish and relationships between modules or components of a Mal metrics and made proposition on inclusion of software or system. Cohesion measures how one method-method interaction as part of consideration function performed by an entity relate to another. It is for cohesion measures. characteristic of most metrics to evaluate cohesion by considering if methods of a class access similar sets III. LITERATURE REVIEW of instance variables (Mal &Rajnish, 2014).Coupling In software engineering, qualities such as connotes how much a component knows about the maintainability, reusability, flexibility, writeability inner workings (elements) of the other. and demonstrability are described as developer- orientedquality attributes (Berander, Damm, Eriksson, Gorschek, Henningsson, Jönsson, Kågström, Milicic, Mårtenssonn, Rönkkö, &Tomaszewski, 2005). While these are external software quality attributes, internal qualities are the likes of size, complexity, cohesion and coupling. The internal versus external quality attributes relationship could be fashionably intuitive, for example the more complex a code is the more difficult it is to maintain.
ISSN: 2231-2803 http://www.ijcttjournal.org Page 64
International Journal of Computer Trends and Technology (IJCTT) – Volume 54 Issue 2-December2017
But,the exact functional form of the relationship is and getting Staff related data. It does not include not very lucid. Therefore, this is connotes a subjectof operations that should be handled by or separated to serious research issue. another class.
IV. COHESION A. Types of Cohesion Using class illustration, cohesion means the extent or which a class carries a single, well-focused degree The following are the variousclassifications of purpose. By implication, a better design should own cohesion that require research attention: high cohesion.It means a class encapsulates only 1. Functional Cohesion: This means the properties and operations that are closely related. various constituent elementsthat make up Interestingly, high cohesion is a desirable property of the module or component are grouped a program in that it positively impacts together simply because each or almost understandability, maintenance and reuse (Girish, everyone in the group contributes to the 2014). An intimate example could be to illustrate module’s single responsibility or well- cohesion as communication between father, mother, focused task. and child within a family while its counterpart called 2. Informational cohesion: Here,the entity is coupling could be communication in between two said to represent a cohesive body of data and different families. a set or group of independent actions or
behaviours on the particular body of data. Consider the following unified modeling 3. Sequential Cohesion: This grouping occurs when parts of the modules output represent language(UML) class example: the input to the other. Staff 4. Communication Cohesion: This is when parts of the module are organized in a group +checkMail() because they use or work on the same data. +sendMail() 5. Procedural Cohesion: This is when parts of +validateMail() the module are grouped together because +printLetter() they followa certain sequence or order of execution. 6. Logical Cohesion: This is whenparts of the module are put in the same group because they are logically grouped to do the same task but might have different nature. Figure: 2. A class design with cohesion. 7. CoincidentalCohesion: This is when Note: These functionalities might be appear modules have nothing really in common logical but might not belong together except for something like convenience. 8. Temporal cohesion: This is when sometime Staff a component is used to initialize a system or set variables. - salary -emailAddress Generally, the fewer the quantity of instance +setSalary(empSalary) variablesthe higher the strength of cohesion. The +getSalary() more the variables a method operates upon the more +setEmailAddress(empEmail) the likelihood of cohesiveness that method would exhibit to its class; this is a positive virtue +getEmailAddress() (Okike&Rapo, 2015).Highly cohesive classes or modules, in general, are easier to maintain and are Fig 2: A class design with high cohesion less frequently in need of changes.Such classes or modules are more usable than others simply because In Figure 2, the Staff class should not their design follows a well-focused purpose. consistcheckMail, validate emails or sendMail. These functions could go into a supposed E-mail class, V. COUPLING hence, high cohesion would be feasible. In Figure 3, While cohesion is interaction between two or more the Staff class has only actual information for setting elements within a module, coupling is interaction /
ISSN: 2231-2803 http://www.ijcttjournal.org Page 65
International Journal of Computer Trends and Technology (IJCTT) – Volume 54 Issue 2-December2017
relationship between two modules. Coupling means components communication is carried outvia the degree to which one class or component knows message passing. about another classor component (Beck & Diehl, 6. Data Coupling: This is recorded if only data 2011). Considering two classes named X and Y, are passed between modules. given that X knows Y through its interface only, that 7. Stamp Coupling: This is when data structure is, Xinteracts or relate with Y through its application is used in transferring information from programming interface (API) then both classes are onemodule to another. loosely coupled. But if class X, other thaninteracting class Y through itsinterface also interacts or relates through the non-interface property of class Y then one can say they are regarded as tightly coupled. If the designer decides to change class Y’s non- interface part for a positive reason, class X breaks High coupling because of this tight coupling. Tight coupling makes Content coupling writing tests harder. Common coupling Control coupling Holub (2005) stated that the main problem with Loose coupling inheritance implementation is that it introduces Stamp coupling unnecessary coupling in the form of fragile base class Data coupling problem (i.e. when changes made to a base class Uncoupled impacts the functionality of many derived classes and Low coupling spread throughout the system). Most practices of object-oriented programming recommend keeping the inheritance graph as shallow as possible. Overuse of inheritance worsens coupling, leading to less flexible and reusable classes. The use of composition Fig 3: Illustration of degree/hierarchy of coupling(Source: instead of inheritance is also preferred. Chawla, n.d)
B. Types of Coupling: The goal of a good design is to eliminate unnecessary coupling. This makes maintenance of the system much easier. Loosely coupled systems are made up of The following include the different types of cohesion: components which are independent or almost 1. Content Coupling: This israted highest and independent. occurs when one of the module or componentdepends or relies on the internal workings of the other module. Invariably, VI. MAINTAINABILITY ATTRIBUTES AND when you make changesto the second BENEFITS module you will automatically need to make Maintainability refers to the degree to which changes to the one that is dependent. asoftware or component of a software can be easily 2. Common Coupling: This occurs when more modified in order to correct bugs, add quality than one modules share the same global attributes or adjustthe operating environment andthen data. Consequently, a change in the shared improve the efficiency of the entire (common) resource engenders changes in software.Generally, software maintenance phase those modules. demands that needed changes are made to the 3. External Coupling: This is when more than existing system (Michura, Capretz, & Wang, one modules share an externally imposed 2013).As a result of inevitable increases in the size data format and communication protocol. and complexity of software products,software 4. Control Coupling: This is whena module maintenance duties have also become increasingly controls or dictates the flow another and herculean.Therefore, an urgent concern in the passes information from one to the other. computing industry is the need to maintain and That is, one component passes parameters to enhance software productsas cost effective as control the activity of another component. possible and within a short time. To meet this 5. Message Coupling: This is come about objective, concepts and techniques which lead though state decentralization. This is seen as todesigning more maintainable solution should be the loosest form of coupling, suchthat given serious consideration. In short, software
ISSN: 2231-2803 http://www.ijcttjournal.org Page 66
International Journal of Computer Trends and Technology (IJCTT) – Volume 54 Issue 2-December2017
maintenance should no longer be a design Kumar, 2014). A potent weapon in the design of afterthought; that is, it should beeasy for software reuse elements or reusable components is how to maintainers to enhance the quality of the product reduce dependency and increase cohesion withoutcompulsorily tearing down and rebuilding the (Wang,2000). Properly designed components can be substantial parts of the code. And one should be able easily customized or replaced which in the end could to predict what happens to a system if change is facilitate maintenance (Crnkovic& Larsson, 2002). required. This is the reason, from design perspectives, to consider paying attention to internal attributes that could improve maintainability.
The following illustrates maintainability and the external versus internal attributes:
Metrics Internal
Attributes CDC, Concern Diffusion over components
CDO, Concern Diffusion over operations
Separation of CDLOC, Concern Diffusion over LOC
concern LOC, Line of code
Size NOA, Number of Attributes Maintainability
Coupling WOC,Weighted Operations Per component
CBC, Coupling between components Cohesion
DIT, Depth of inheritance Tree
LCOO, Lack of Cohesion in operations
Fig 4: Framework for software measurement validation (Source: Garcia, 2014) A reusable software component is a software system, VII. REUSABILITY ATTRIBUTES AND subsystem, module or program chunk that can be BENEFITS easily integratedinto newsoftware or program directly There is a continuing effort in taking the advantage of or after somenecessary changes have been made. reusing knowledge or artefacts right from procedural Basili, Briand, &Melo, (1996) indicated that error techniques to object-orientedsystem development, density (that is, errors per thousand lines of code) component oriented development and beyond. dropped from 6.11 for systemsdeveloped without Prominent in this area are program library, employing reuse to 0.12 for systems built from application product lines, component based reusable components. It has also been discovered that development, service oriented systems, legacy 40% to 60% of code is truly reusable from one systems, program generator, aspect-oriented software application to another application, 60% of design and development, design patterns, and commercial off the code are reusable in when it comes to business shelf software integration. These are categorised as applications, 75% of program functions are common systematic reuse areas where the full benefit of in two or more programs, and only about 15% of the software reuse can only be achieved (Bhatnagar& code found in most software is unique to
ISSN: 2231-2803 http://www.ijcttjournal.org Page 67
International Journal of Computer Trends and Technology (IJCTT) – Volume 54 Issue 2-December2017
oneparticular application (Ezran et al., 2002). D- Dependency Inversion Principle- Depend on Maximizing the reuse of tested, certified and abstractions, not on concretions organized artifacts can generate improvements in cost, time and quality (Basili et al., 1996). The U.S. IX. FOCUS ON OBJECT ORIENTED METRICS Department of Defencewas able to save $300 million SUITES annually by increasing its reuse level by only 1% There are many traditional metrics found in literature (Computerworld, V27(49)). This presents a good which had been applied to measure many quality case to venture into research that can improve criteria like size, complexity, comment percentage software reuse. and so on. Metric as cyclomatic complexity (McCabe, 1976) proved to be one of the best Effective reuse is not a simple addition toexisting indicators to test reliability in a system. However, software development processes; it puts strong these traditional software measures would not scale demandson development methods in order to be well scale when it comes to handling object-oriented successful. Key issues to considerhere is to define systems (Goldberg & Rubin, 1995).This is simply models and metrics which can measuresoftware because basic object-oriented characteristics like reusability (Antovski&Florinda, 2013). A metric is a polymorphism, inheritance, classes and object are quantitative indicator of an attribute of a thing while notincorporated in their design (Kaur & Kaur, 2015). a model specifies relationships among metrics In object-oriented programming, much of the explicit (Frakes& Kang, 2005). branching statements, e.g. if, while and casestatements, have been replaced by implicit branching due to inheritance andevent-driven programming. This implies that cyclomatic VIII. DESIGN PRINCIPLES complexity metric alonecannot decipher the Another subject of concern is design principles which complexity of an object-oriented program. The have intertwined relationship with giving following are some OOD metrics but the more or less consideration to known internal attributes. Some of commonest is the CK metrics suite the commonest examples of design principles include (Chidamber&Kemerer metrics) (Suresh, Pati& Ku, striving for a clearly defined, single purpose per 2012). component, striving for loosely coupled and highly cohesivecomponents, developing components with X. CK METRICS SUITE overall future use in mind and also putting extra This suite is referred to as being best indicators for effort into error handling andmaking components fault proneness. It is a convenient tool to predict the robust (Suresh, (2011). reliability of a system. The metric suite helps developers to make better design decision and at the The software-intensive industry is relentless in same time estimate testing effort(Suresh, Pati, & Ku, finding ways to develop software faster, cheaper, 2012). more predictably, with requested functionality and quality and with sufficient maintainability. The key The ChidamberandKemerer metrics suite originally thing is to improve the process for developing and consists of six metrics created to test some specific maintaining the appropriate software (Sommerville, system characteristics. They are highlighted as 2010). follows: Robert C. Martin, from his research experience, compiled and proposed different object-oriented design principleswith a common acronym called 1)WMC (Weighted Method per Class) SOLID Design principles (Martin, 2012). The This is one of the metrics that has been meaning of the acronym is: remarkedaseffective in predicting testing and maintenanceeffort. It could perform better when S- Single Responsibility Principle - A class should complemented or combined with other metrics. have one, and only one, reason to change If there exists a Class C1, having methods as O- Open Close Principle- A class should be open for m1,m2,…, mndefined as members of a class. Let c1, extensionand closed for modification c2,...,cn be labeled as the complexity of the methods, L-Liskov Substitution - Derived classes must be then WMC is illustrated with the following simple substitutable for their base equation: I-Interface Segregation Principle - Make fine grained interfaces that are client specific
ISSN: 2231-2803 http://www.ijcttjournal.org Page 68
International Journal of Computer Trends and Technology (IJCTT) – Volume 54 Issue 2-December2017
푛 WMC = 푖=1 ci, for i 1 to n. (1) LCOM is defined from the cardinality of the sets as Such that ci is regarded as the complexity of the follows: methods or functionsassociated in the ith class. If every method’s complexity is unity, then that LCOM = |A| - |B| , if |A| > |B| or implies the value of WMC will become n, meaning zero (0) otherwise (4) the number of methods involved. LCOM is described as an inverse cohesion measure. When LCOM is (0) then a class is cohesive. 2) Depth of Inheritance Tree (DIT) Eg. If class C has methods M1, M2, and M3, Thisis calculated as the maximum length of path let { I1} = (a,b,c,d,e} be set of instance variables in from a class to the root class in the inheritance class C used by method M1 (hierarchy) tree. The higher depth shows more { I2} = {a,b,e} for method M2 complexity in predicting its behavior. { I3} = {x,y,z} for method M3
3)NOC (Number of Children) Then { I1} { I2} ≠ This connoted the quantity of immediate sub-classes { I1} { I3} = that are subordinate to a known class in the class { I2} { I3} = hierarchy. This shows the influence of a class on . either the system or the design. LCOM = the number of null intersections – number of non-empty intersections. 4)CBO (Coupling between Objects) The result is one in this example LCOM = 2 –1 = 1; So, the larger the number of similar methods, the Coupling between Objects metric for a known class more cohesive the class is. is the sum total of the quantity of other classes to If none of the methods of a class display any instance which it is coupled. This helps in determining the variables, they have no similarity and the LCOM complexity of testing on the design. value for the class is zero (0). LCOM is intimately
tied to methods and instance variables of a class, 5) Response for a Class (RFC) therefore, it is described as a measure of properties of This is the set of methods that have the likelihood of an object. being executed as a result of response to a message received by an object of that class. RCF is also a Having a high value of LCOM means low cohesion measure of the possible communication between the and then the class might be in a better design if class and other classes. Large RFC showstendency of broken into two or moreseparate classes.Poor more fault. cohesion also means high complexity which can increase error tendency during system development. 6) Lack of Cohesion in Methods (LCOM)
LCOM attempts to find the degree of methods similarity and is theoretically grounded upon XI. ROBERT C. MARTINS METRIC SUITE ontology of objects according to Bunge, (1972). The Ideal models of dependency and abstraction are ontology defines the set of characteristics or reflected by these metrics. It captures some good properties thatobjects share. design principles and also representsa lucid If there existsClass C1 having n methods M1, M2, description of stability in software.This metrics is …Mn. Then{ Ii } is the set of instance variables that commonly known as package metrics (Martin, 1994). are accessed by method Mi. There are n such set {I1 It consists of the following: },…,{I n }.
Then the following two disjoint sets are defined: a) Efferent Coupling (Ce): n(classes) outside the
package that depend on classes within the package. A ={ (Ii, Ij) | Ii Ij = }, (2) b) Afferent Coupling (Ca): n(classes) inside the package that depend upon classes outside the B = { ( Ii, Ij ) | Ii Ij ≠ } package. (3) If all n sets { I1}…{ In } are then A =
ISSN: 2231-2803 http://www.ijcttjournal.org Page 69
International Journal of Computer Trends and Technology (IJCTT) – Volume 54 Issue 2-December2017
c) Instability(I) =Ce / (Ce + Ca). (5)It implies oriented systems. However, the experimentation the adaptability to of package to change. revealed that large systems would benefit more from It ranges within [0-1],such that when I = 0we the proposed metrics compared to small ones. haveabsolutely or completely stable package,and Rajnish& Mal, (2014) discussed the relevance of when I = 1 we have absolutelyinstable package. cohesion as a key design property in object oriented d) Abstractness: This is the comparison of quantity of software as used in measuring connectivity within abstract classes (and also interfaces) to the total subsystems. While LCOM searches for absence of numberof classesin thepackage under consideration. cohesion, their proposed work attempts to seek the degree of presence of cohesion. This research mainly Abstractness (A ) = abstractClasses / totalClasses. modeled the interaction between global variables and (6) methods within a program. Their experiment shows correlation between lines of code, LOC, compared to The range is [0-1];when A = 0 we have absolute some existing cohesion metrics. concrete package; when A = 1 we have absolute abstract package. XIII. MEASURING FUNCTIONAL COHESION As object-orientation requires a new way of thinking e) Normalized Distance from Main Sequence (D) and a different way to design, measuring design elements also demands a different approach beyond D connotes the perpendicular distance of a package traditional measures. Due to the complexity of from the idealized line given by: object-oriented software,there is no single, simple measure of software quality for all cases (Michura, D = A+ I-1. (7) Capretz, & Wang, 2013).
Where D = 0depicts a package which coincides with The well-known metrics proposed by Chidamber and the main sequence and Kemerer (described as the CK metrics) can be used to D = 1 depicts a packagethat is said to be far away measure some object oriented characteristics and can from the main sequence. be used to predict defects during maintenance but do not give enough information as regards the difficulty XII. OTHER RELATED WORKS: in executing such changes (Michura, Capretz, & The following is a review of related works that Wang, 2013). Also, the proposed metrics of Mal indicated efforts in promoting parallel programming &Rajnish, (2014) emphasized on predicting system and supporting frameworks: reusability.
Shumway, (1997)carried out a empirical research on XIV. LACK OF COHESION METRICS the relationship between class cohesion and size and One of the most common lack of cohesion metrics is concluded that there is no significant relationship that of Chidamber and Kemerer.This has been between cohesion and class size as measured in worked upon over the years to ensure improvement number of byte code. Also, the data set used did not and to see to its application specificity. exhibit high reuse properties which could aid investigating the relationship between reuse and XV. COHESION PRESENCE METRICS cohesion. Mal &Rajnish., (2014) proposed a cohesion metrics Badri&Badri (2004) proposed a class cohesion which shows correlation with Number Line of Code measures which attempted to consider other criterion Property, NLOC. It is also said to be a good indicator that are characteristic of object orientation in of reusability. This work principally considered assessing the relatedness of class elements. The variable-method interactions (Mal &Rajnish., 2014). researchers stated that class cohesion should not exclusively be based on common instance variables XVI. PROPOSED METRICS usage criteria. Figure 6 is a model of the proposed metrics which (in Michura, Capretz, & Wang (2013) also stated that addition to variable-method) consider method- some system characteristics are essential to deal with method interactions which is an extension or issues of system complexity and its associated adaptation of Mal &Rajnish, (2014) metrics.Notably, maintainability. The paper identifies factors that are boththe Chidamber and KemererLCOM metrics and responsiblefor difficulties in performing changes Mal and Rajnishshare in common the concept of during maintenance, and also the necessary effects variable-method interaction but the former measures that may come with those changes especially object-
ISSN: 2231-2803 http://www.ijcttjournal.org Page 70
International Journal of Computer Trends and Technology (IJCTT) – Volume 54 Issue 2-December2017
the absence of cohesion while the latter measures its presence. XVII. DISCUSSION The cohesion measurement discussed and proposed is i j k l a predictive approach to designing OO software. This informs the designer of the system status and helps to determine what proactive step to take in ensuring a system with less future problems. This work evaluates existing metrics, design principles, importance of maintainability and reusability M1 M2 M3 properties, cohesion and coupling and most importantly considers how to improve cohesion measures for the benefit of software developers.
ONCLUSION AND RECOMMENDATION Fig5: Illustration of class cohesion measure indicating XVIII. C variable-method interaction and method-method interaction. Software engineering is a disciplined approach towards creating quality software products. To get The i, j, k and l represent the variables while M1, M2 value for effort put into software design some subtle and M3 are the methods. but critical underlying characteristics need to be The mathematical model of the model is described as given serious attention by knowledge engineers, follows: software developers and practitioners. Remarkable Let class C consists of a set of instance variables V = quality attributes such as maintainability and {v1, v2,…,vn} and a set of methods M = {m1, m2, reusability are part of external properties of a system. …, mn}. The fulcrum of these is not far from the internal Then Proposed Class Cohesion, PCC is evaluated attributes. And two amongthose rated most important based on ith instance variable of a class (CVi) for are cohesion and coupling attributes. During method-data interaction and invoked methods in the maintenance for example, these have direct impacts class (CMi) for method-to-method interaction. on what the designer of software will go through let alone if such solution were to be maintained by a CVi= Numberof methods sharing the instance different developer. This report discussed the variable i of a class relevance of these internal attributes as they relate to Number of all methods in the class reusability and maintainability. Existing works on cohesion metrics were evaluated, design principles CVi = n(M(Vi)) (8) were discussed and a narrowed focus was given to cohesion measures. Most works reviewed focused on n(M) the important characteristic of cohesion which CMi = number of methods invoked by other methods models the relationship between instancevariables in the class and methods within a class. This work considers Number of all methods in the class additionalbehaviour as method-method interaction. CMi= n(M(mi)) (9) Future recommendation is the consideration or n(M) addition of other class characteristics (e.g. PCC =CVi + CMi(10) discrimination anomaly) that could improve cohesion The range of PCC is [0,2] measurement as exhibited by different designs. Then the mean CVi, andCMi cohesion count of a class of n instance variable is computed as follows: REFERENCES 푛 Cohesion PCC = (CVi + CMi) (11) n ≥ 1 푖=1 1. Ahn, Y., Suh, J., Kim, S., & Kim, H. (2003). n The Software Maintenance Project Effort Then, to evaluate a system’s cohesion comprising r Estimation Model Based on Function Points. classes, the following applies: Journal of Software Maintenance Evolution:
Such that n = number of instance variables of a class Research and Practice, 15, 71-85.
2. Allen, H. (2005). Introduction to Object- SysCo = 푟 Cohesion PCC 푖=1 (12) Oriented Analysis and Design. Best
ISSN: 2231-2803 http://www.ijcttjournal.org Page 71
International Journal of Computer Trends and Technology (IJCTT) – Volume 54 Issue 2-December2017
Software Canada Ltd. Printed in Canada and Methodology (TOSEM). TR, Simula 8920 Woodbine Ave. Suite 400. Research Laboratory. 3. Antovski, L., &Florinda, I. F. (2013). 15. Dallal, J. A. (2011). Measuring the Review of Software Reuse Processes. Discriminative Power of Object-Oriented IJCSI,International Journal of Computer Class Cohesion Metrics. IEEE Transactions Science Issues, www.IJCSI.org, 10(6), 83- on Software Engineering,37(6), 788-804. 88. 16. Dhanvani, J. (2013). Difference between 4. Badri, L., &Badri, M., (2004). A Proposal of Cohesion and Coupling. Retrieved from a New Class Cohesion Criterion: An http://freefeast.info/difference- Empirical Study. Journal of Object between/difference-between-cohesion-and- Technology, Published by ETH Zurich, coupling-cohesion-vs-coupling/ Chair of Software Engineering, JOT, 3(4). 17. Ezran, M., Morisio, M., & Tully, C. (2002), 5. Basili, V. R., Briand, L. C., &Melo, W. L., Practical Software Reuse. Springer, 374. (1996). How Reuse Influences Productivity 18. Fenton, N., &Pfleeger, S. (2010). Software in Object-Oriented Systems. Communication metrics: A rigorous and practical approach of the ACM, 39(10), 104-116. (2nd ed.). Boston, MA: PSW Publishing. 6. Beck, F., & Diehl, S., (2011). On the 19. Frakes, W. B., & Kang, K. (2005). Software Congruence of Modularity and Code Reuse Research: Status and Future. Journal Coupling. Proceedings of the 19th ACM IEEE Transactions on Software SIGSOFT symposium and the 13th Engineering, 31(7), 529-536. European conference on Foundations of 20. Garcia, A. (2014). Framework for Software software engineering, ACM, NY, USA, 354- Measurement Validation. Departamento de 364 Informática PUS research group. 7. Berander, P., Damm, L., Eriksson, J., 21. Girish, K. K. (2014). Conceptual Cohesion Gorschek, T., Henningsson, K., Jönsson, P., of Classes (C3) Metrics. International Kågström, S., Milicic, D., Mårtenssonn, F., Journal of Science and Research (IJSR) Rönkkö, K., &Tomaszewski, P. (2005). ISSN (Online) 2319-7064. Software quality attributes and trade-offs. 22. Goldberg, A., & Rubin, K. S. (1995). Blekinge Institute of Technology. Succeeding with objects: Decision 8. Bhatnagar, V., & Kumar, A., (2014). frameworks for project management. Prospective of Software Reusability. Boston, MA, USA: Addison-Wesley. International Journal of Application or 23. Kaur, M., & Kaur, R. (2015). Improving the Innovation in Engineering & Management Design of Cohesion and Coupling Metrics (IJAIEM),3(1), 411-414. for Aspect Oriented Software Development. 9. Bunge, M. (1972). Treatise on Basic International Journal of Computer Science Philosophy: Ontology II: The World of and Mobile Computing, IJCSMC, 4(5), 99 – Systems. Riedel, Boston, USA. 106. 10. Chawla, J. (n.d.). Cohesion and Coupling. 24. Liskov, B. &Guttag, J. (2000). Program Retrieved from development in Java: Abstraction, https://www.slideshare.net/jagneshchawla/c specification, and object-Oriented design ohesion-coupling. (1st ed.). Addison-Wesley Professional. 11. Chidamber, S. R., &Kemerer, C. F., (1994). 25. Mal, S., &Rajnish, K. (2014). New Class A Metrics suite for object Oriented Design. Cohesion Metric: An Empirical View. IEEE Transactions on Software International Journal of Multimedia and Engineering,20(6), 476-493. Ubiquitous Engineering,9(6), 367-376. 12. Computerworld, Software Reuse Plans 26. Martin, R. C. (2012). Clean code: A Bring Pay backs, Computer world, 27(49), handbook of agile software craftsmanship 73-76. Anthes, Gary I. (1st ed.). Upper Saddle River, NJ, Boston: 13. Crnkovic, I., & Larsson, M. (2002). Building Prentice Hall. Reliable Component-Based Software 27. McCabe T. J. (1976). "A Complexity Systems. Boston, London: ArtechHouse. Measure". IEEE Transactions on Software 14. Dallal, J. A., & Briand, L., (2009). A Engineering: 308–320. Precise Method-Method Interaction-Based 28. Michura, J., Capretz, M, & Wang, S. Cohesion Metric for object-oriented classes. (2013). Extension of Object-Oriented ACM Transaction on Software Engineering Metrics Suite for Software Maintenance.
ISSN: 2231-2803 http://www.ijcttjournal.org Page 72
International Journal of Computer Trends and Technology (IJCTT) – Volume 54 Issue 2-December2017
Hindawi Publishing Corporation ISRN 35. Shumway, M. F. (1997). Measuring Class Software Engineering, 2013(276105), 14. Cohesion in Java. (Masters dissertation, 29. Okike, E. U., &Osofisan, A. (2008). An Computer Science Department, Colorado Evaluation of Chidamber and Kermerer’s State University, Technical Report CS-97- Lack of Cohesion in Methods Metric Using 113. Different Normalization Approaches. Afr. J. 36. Suresh, G. R., (2011). Strategies for comp. & ICT,1(2), 35- 43. Deploying Reusable Software Components. 30. Okike, E. U. (2010a). A Pedagogical International Journal of Graphics & Image Evaluation and Discussion about the Lack of Processing, www.ifrsa.org, 2(4), 264-273. Cohesion in methods (LCOM) Metric Using 37. Suresh, Y., Pati, J., & Ku, R. S. (2012). field Experiment. International Journal of Effectiveness of Software Metrics for Computer Science Issues, 7(2), 36-43. Object-Oriented System. 31. Okike, E. U. (2010b). A Proposal for SecondInternational Conference on Normalized Lack of Cohesion in Method Communication, Computing & Security (LCOM) Metric Using Field Experiment. [ICCCS-2012], Department of Computer IJCSI International Journal of Computer Science and Engineering, National Institute Science Issues, 7(4), 5. of Technology, Rourkela, India, Procedia 32. Okike, E. U., &Rapo, M., (2015). Using Technology, 6(2012), 420–427. Cohesion and Capability Maturity Model 38. Wang, J. A. (2000). Towards Component- Integration (CMMI) as Software Product Based Software Engineering. Department of and Process Quality criteria: A case study of Computer Science and Information Systems Software Engineering practice in Botswana. Univ International Journal of Computer Science and Information Security (IJCSIS),13(12), 39. Ersity of Nebraska, Kearney Kearney, NE 140-149. 68849,USA 33. Pressman, R. S., & Maxim, B. R. (2015). Software engineering: A practitioner's approach (8th ed.). McGraw-Hil 34. Sommerville, I. (2011). Software engineering (9thed.). New York: Addison Wesley.
ISSN: 2231-2803 http://www.ijcttjournal.org Page 73