An approach to automatically enforce object-oriented

50

Int. J. Computer Applications in Technology, Vol. 49, No. 1, 2014

An approach to automatically enforce object-oriented constraints Maen Hammad* Department of Software Engineering, The Hashemite University, P.O. Box 150459, Zarqa 13115, Jordan E-mail: [email protected] *Corresponding author

Mustafa Hammad Department of Information Technology, Mu’tah University, P.O. Box 7, Mu’tah – AL Karak 61710, Jordan E-mail: [email protected]

Mohammad Bsoul Department of Computer Science and Applications, The Hashemite University, P.O. Box 150459, Zarqa 13115, Jordan E-mail: [email protected] Abstract: This paper presents an approach to automatically enforce object-oriented constraints during incremental C++ code changes. The approach is realised as a tool to keep track on code changes and to notify developers with violations of predefined OO constraints. The OO constraints under consideration are taken from object-oriented design metrics. The object-oriented metrics mainly cover class size, coupling between classes, number of subclasses and inheritance tree. The goal of this work is to help designers to monitor design during incremental code changes. Object-oriented design metrics are automatically extracted from source code. The extracted metrics are used by designers to define the constraints. The tool supports defining and managing these OO constraints. After a code change is committed, design changes are identified and predefined constraints are checked for possible violations. The evaluation of the tool shows that it helps in detecting violations of design constraints, and it saves time and efforts of developers. Keywords: object-oriented constraints; OO metrics; software evolution and maintenance. Reference to this paper should be made as follows: Hammad, M., Hammad, M. and Bsoul, M. (2014) ‘An approach to automatically enforce object-oriented constraints’, Int. J. Computer Applications in Technology, Vol. 49, No. 1, pp.50–59. Biographical notes: Maen Hammad is an Assistant Professor in Software Engineering Department at The Hashemite University, Jordan. He completed his PhD in Computer Science at Kent State University, USA, in 2010. He received his Master’s degree in Computer Science from Al-Yarmouk University, Jordan and his BS in Computer Science from The Hashemite University, Jordan. His research interest is software engineering with focus on software evolution and maintenance, program comprehension and mining software repositories. Mustafa Hammad is an Assistant Professor at Information Technology Department in Mu’tah University, Al Karak, Jordan. He received his PhD in Computer Science from New Mexico State University, USA, in 2010. He received his Master’s degree in Computer Science from Al-Balqa Applied University, Jordan, in 2005 and his BSc in Computer Science from The Hashemite University, Jordan, in 2002. His research interest is software engineering with focus on static and dynamic analyses and software evolution. Mohammad Bsoul is an Associate Professor in the Computer Science Department of The Hashemite University. He received his BSc in Computer Science from Jordan University of Science and Technology, Jordan, Master’s degree from the University of Western Sydney, Australia, and PhD from Loughborough University, UK. His research interests include wireless sensor networks, grid computing, distributed systems and performance evaluation.

Copyright © 2014 Inderscience Enterprises Ltd.

An approach to automatically enforce object-oriented constraints

1

Introduction

Software systems are subject to change and evolution (Lehman and Ramil, 2001, 2002). Designers of software systems prefer to keep control on the quality of architecture of the software. This is necessary to avoid drastic changes in the design, which may increase the maintenance cost of the software. Object-oriented constraints are important elements that designers prefer to enforce to keep the architecture of system software in a good shape. Good shape means the design can be easily extended, maintained, tested and understood. One of the object-oriented design principles is to make modules have high cohesion and low coupling (Schach, 2010). Classes are preferred to be independent units that perform specific tasks. More methods in a class may decrease the cohesion of that class, which is not preferred because it makes the class difficult to understand and reuse. On the other hand, more called methods and more relationships to other classes may increase the coupling of a class, which is also not preferred owing to the increase in the maintenance cost. We adopted the object-oriented metrics defined by Chidamber and Kemerer (1994) as the basis to control and preserve the quality of object-oriented design. The values of these metrics reflect the quality of the object-oriented design. These metrics are widely used to measure the quality of object-oriented software. So, these metrics have been adopted in this work because our goal is to help developers in preserving the design quality during development. For example, long inheritance trees, more inherited methods, large classes, more called methods and more relationships to other classes make classes hard to understand, test and maintain. So, object-oriented design metrics can be viewed as object-oriented constraints that help in controlling the quality of the design. The upper value for each design metric represents a constraint that should not be exceeded during software evolution. As a result, object-oriented constraints help to guarantee safe evolution for software with large and continuous maintenance tasks in which the software is evolved via increment code changes (or commits). During maintenance activities, developers should be automatically notified once their code changes violate any enforced constraint. It is difficult for developers to monitor design while they make code changes. For example, suppose that the depth of the inheritance tree (DIT) in a system is limited to 10. Now, for each new subclass, developers have to manually count the DIT to be sure that it is less than 10. Manual checking is subject to human error. It also takes time, especially with large systems. So, developers focus on code changes rather than the architecture. As a result, the architecture may suffer from major flaws that decrease its quality. The problem is worse for developers of open source and global projects. This is because these types of projects are to large volume of code changes. Also, a large number of developers are involved in the development process from different geographical areas (Mishra and Mishra, 2011). Furthermore, the development

51

process is not centralised with central management as close-source projects. As a result, automated tools are needed to help designers in controlling the development process. Controlling means enforcing a set of constraints to preserve the quality of the architecture of object-oriented systems. The tools should be able to define constraints and automatically keep track on code changes to detect violations in constraints. In this paper, we present an approach, realised as a tool, to automatically identify violations of predefined object-oriented constraints from incremental code changes. Object-oriented constraints under consideration are taken from object-oriented design metrics. The unit of change is the ‘commit’. After each commit, code changes are analysed to determine if it breaks an enforced design constraint. As a result, by alerting designers with violations during code changes activities, OO constraints can be preserved, which means the quality of the design can be preserved too. The paper presents the following three contributions: 1

An approach to automatically identify violations of predefined constraints from code changes. The approach is realised as a tool, named MetricsEnforcer, that helps developers and designers to preserve object-oriented constraints.

2

An automated method to extract design metrics from source code. The extracted metrics are the base for OO constraints.

3

A flexible method to define and manage object-oriented constraints. A flexible XML format is proposed to represent constraints.

The proposed approach saves time and efforts by automatically identifying violations in any enforced OO constraint once they occur (i.e., code change). The focus of the approach is code changes that are committed during post-delivery maintenance activities. So, OO constraints are preserved and enforced during software evolution. In our approach, we reduce checking violation time by examining code changes only not the whole code. So, violations are identified from code changes once they are committed. In addition, the developed tool has the ability to do a consistency checking for the whole code against predefined constraints. The motivations behind this work are the needs, of software developers, for approaches and tools to control the quality of OO design during maintenance activities. There is a need for a set of constraints that can be used to control and measure the quality of OO design. There is also a need for a tool to automatically control the quality of OO design during maintenance activities. By providing such tools, the quality of design is preserved and hence reduces time and cost of maintenance, which is a goal of each developer. This paper is organised as follows. Section 2 describes OO constraints that are enforced by the approach. The details of the proposed approach and the supporting tool are detailed in Section 3. The evaluation is shown in Section 4. Section 5 discusses the threats to validity. Related work is

52

M. Hammad et al.

presented in Section 6 followed by conclusions and future work in Section 7.

2

Enforced object-oriented constraints

Object-oriented metrics, (Chidamber and Kemerer, 1994; Chidamber et al., 1998) measure certain properties of object-oriented software systems. These metrics are used to measure the quality of object-oriented design. So, designers should be aware of the values of these metrics to keep the design in a good shape. The object-oriented design metric that were defined by Chidamber and Kemerer (1994) are: •

weighted methods per class metric (WMC).

•

depth of the inheritance tree (DIT)

•

number of children metric (NOC)

•

coupling between object classes metric (CBO)

•

response for a class metric (RFC)

•

lack of cohesion in methods metric (LCOM).

WMC measures the complexity of a class based on the sum of complexities of all its methods. The complexity of each method is its weight. The WMC represents the sum of all weights of methods in a class. If a class has m methods and each method has a weight wi, then WMC = SUM(wi) where i = 1, 2, …, m. For example, consider the weight of a method is defined as the total number of its lines of code (LOC). The WMC of the class is the sum of all weights (LOC) for its methods. The DIT is the Depth of the Inheritance Tree from a subclass to its root node. The NOC is the number of direct subclasses of a class. The CBO is the number of other classes coupled to a class. The RFC if the number of methods (NOM) in a class that response to a message received by an object of a class. The LCOM is a count of method pairs that are not similar minus the count of method pairs that are similar. Our approach automatically enforces OO constraints. These enforced constraints are based on the abovementioned object-oriented design metrics. We consider setting the upper limit of a metric as an OO constraint. Definition: the maximum value X of an object-oriented metric is an object-oriented constraint. Designers can view an object-oriented metric as a constraint. For example, the DIT metric can be viewed as a constraint in which the depth of any inheritance tree in the system should not exceed a specific value during software changes activities. We propose a set of modifications based on the above-mentioned object-oriented metrics. The NOC and DIT are used without modifications. The modified metrics are: •

the NOM, which is an adaptation from the WMC metric where the weight assigned to each method is the value one

•

the number of called methods (NCM) is taken from the RFC metric, which represents the number of external methods called by a class

•

we classified the CBO classes metric into two metrics; the number of dependency relationships of a class (NOD) and the number of association relationships (NOC).

Both CBO and NOD metrics represent the number of outgoing relationships to other classes. For example, if a class A has two dependency relationships to classes B and C, then the number of dependencies of class A is two. The same applies for associations. By using these two different metrics, we give designers more options to control the coupling between classes. We did not include the LOCM metric in the approach. The LOCM deals with the similarity of methods within a class, which may not have a big impact on the design. The upper limit value of a metric X should not be exceeded during software evolution. The developed tool automatically identifies code change that causes violations for predefined constraints. The object-oriented constraints that we consider in our approach are: •

the maximum number of children for a class (M_NOC)

•

the maximum number of methods in a class (M_NOM)

•

the maximum number of inherited methods in a class (M_NIM)

•

the maximum depth of the inheritance tree (M_DIT).

•

the maximum number of called methods from a class (M_NCM)

•

the maximum of dependency relationships of a class (M_NOD)

•

the maximum of association relationships of a class (M_NOA).

These proposed design constraints help developers and designers in controlling the overall object-oriented design/ architecture of the software systems. The M_NOC constraint limits the number of direct children via inheritance of a specific class. Designers may prefer to control the number of classes that reuse the super class. The M_NOM constraint limits the NOM for a class. This constraint helps to control the size of the class. The M_NIM constraint limits the number of inherited methods in a leaf node. This constraint is useful to control the complexity of leaf nodes. The M_NIM constraint also leads to control the size of classes in the inheritance tree. The M_DIT limits the Depth of the Inheritance Tree. As depth increases, testing becomes more difficult. We consider this constraint as a property for the root node. So, the inheritance tree with the root class A should not exceed the maximum depth determined in class A. The M_NCM, M_NOD and M_NOA constraints help designers to control

An approach to automatically enforce object-oriented constraints

53

the degree of coupling for a class or among classes. In view of huge cargo of airdrop system, the multi-level multi-chute system is usually chosen to handle this problem. Generally speaking, the multi-level multi-chute system includes main parachute, decelerate parachute, auxiliary parachute, traction parachute and so on. The structure of Cargo Airdrop System is shown in Figure 1. Each level of parachutes connects through the rope and the suspenders. Usually, different size parachutes have different purpose, and all parachutes will open in term of strictly timing sequence. Otherwise, it will be very dangerous for cargo and transport system.

designers determine their constraints as upper-limit values for each shown metric. The upper value of each metric is a constraint that should be preserved during software evolution. Finally, during software evolution each code change is analysed to determine violations for any constraint if it exists. The MetricsEnforcer tool enables designers to view the extracted metrics of current code and to set the upper limit of these values (i.e., setting the OO constraints). After designers determine constraints, they are saved in the XML format constraintsXML. constraintsXML files are used in the process of checking for violations.

Figure 1

Figure 2

A sample of constraintsXML file for class SampleClass

The object-oriented constraints are represented in a flexible XML format named constraintsXML. The tool enables designers to fill the values of each metric for classes. Then, the constraintsXML file is automatically generated by the MetricsEnforcer tool. The values of these constraints are determined by designers. Figure 1 shows an example of a constraintsXML file for a class named SampleClass with seven enforced constraints. In this class, the maximum number of methods (M_NOM) constraint is set by a designer to 10. This means, for all future maintenance activities, the NOM for SampleClass should not exceed 10. For each class, with OO constraints, the tool automatically creates a constraintsXML file. As shown in the figure, every constraint has a unique tag. Each class is saved with its constraints that are determined and managed by designers. The NULL value for the M_NIM constraint means that it is not enforced. The same applies for M_NOD and M_NOA constraints. A set of XPath queries is used to parse the constraitsXML file. For instance, to find the maximum depth of the inheritance tree (M_DIT) of a class A, the following query is applied: //class[name=’A’]/constraints/M_DIT/text()

3

The approach

Figure 2 shows the framework of the MetricsEnforcer tool. The process starts by extracting the object-oriented metrics from the source code. In the next step, the extracted metrics are shown to designers as a set of statistics. These statistics help designers to understand the big picture of the current status of the design. On the basis of the shown metrics,

The framework of the MetricsEnforcer tool

3.1 Extraction of OO metrics The object-oriented metrics are automatically extracted from the source code. The extraction process is summarised in the following two steps: •

the source code is automatically represented in the XML representation srcML (Collard et al., 2002, 2003)

•

a set of XPath queries are used to parse srcML to extract the metrics of the source code.

srcML (Collard et al., 2002, 2003) is an XML representation of C++ source code where each code element is tagged with its syntactic information. Figure 3 shows a C++ function and its srcML representation. Since srcML is an XML representation, it can be parsed by a set of XPath queries, or any XML parsing tool. For example, to find the total number of methods in class A, srcML is parsed using the following XPath query. //class[name=’A’]/function_decl As another example to find the DIT of a leaf class A, the following XPath query is used to find the super class of A: //class[name=’A’]/super/name/text() Suppose that the super class of A is named class B, then a similar query is applied to find the super class of B. The process is repeated until we reach the root note. For each visited class in the tree, the number of its methods is counted. The total number of counted methods is used to check the number of inherited methods constraint (M_NIM).

54 Figure 3

M. Hammad et al. A C++ function and its corresponding srcML representation

To find the number of children of a class A, all classes in srcML are checked to determine which classes have a super class named A. The NCM by a class A is found by parsing srcML files of header and source files of class A. Each function class can be identified in srcML by tag named . The number of dependencies of class A is found by parsing all methods of class A to locate any non-primitive type declarations (i.e., classes). If class A declares a local (i.e., method’s scope) object or reference of type B, then there is a dependency relationship between classes A and B. On the other hand, if class A declares a reference or object of type D as a data member, then there is an association relationship between class A and class D. The name of the class is extracted with all its object-oriented metric statistics. Then, these statistics are shown to designers. This information helps designers in determining the constraints (detailed in the next section). Extracted object-oriented metrics are useful to give a summary about the current status of classes and design.

type Date. This is an association relationship from Cylinder class to Date class. The fillColour method defined a local object of type Colour. This is a dependency relationship from Cylinder class to Colour class. The Cylinder class calls only one external method, which is d.print( ). Three methods are inherited from Circle and Point classes, which are printPoint, printCircle and printArea. There are no subclasses for Cylinder class, which means the Cylinder class has zero children. All these statistics are automatically shown to designer via the interface of the MetricsEnforcer tool on the ‘Class Statistics’ panel as shown in Figure 5. Figure 4

A C++ example for three classes

Figure 5

A snapshot from the interface of the MetricsEnforcer tool. (a) It shows the metrics statistics of the Cylinder class shown in Figure 4. (b) It shows a specific metric for all classes (see online version for colours)

3.2 Setting OO constraints The extracted statistics for each class are shown to designers by the MetricsEnforcer tool. For example, Figure 4 shows a C++ example for three classes: Point, Circle and Cylinder. The tool is used to extract the statistics of the Cylinder class, which are shown in Figure 5. Figure 5 shows snapshots from the interfaces of the MetricsEnforcer tool shown to designers for the leaf class Cylinder. In Figure 5(a), object-oriented metrics of the Cylinder class are shown to designers. Cylinder class inherits from Circle class, which in turn inherits from Point class. The DIT is three. Cylinder class has two methods: fillColour and printDate. It has also one data field object of

(a)

(b)

An approach to automatically enforce object-oriented constraints In Figure 5(b), designers can view the values of specific design metric for all classes. The extracted values for each class are shown in the ‘Current Value’. The interface enables designers to set the upper values for this constraint for all classes. This is done by filling the ‘Max Value’ column. By showing these statistics, designers will have a summary for the current status of classes and design. Statistics of Point and Circle classes are also shown once users select any of them from the drop-down list ‘Classes’. Different values of statistics are shown based on the class. For example, the depth of the NOM is zero and the NCM is also zero. If one of the constraints, shown in the Design Constraints panel, is not enforced, users should enter the ‘−1’ value in that field. Now, designers fill the text fields of design constraints. constraintsXML file is then generated. After designers view extracted object-oriented metrics from the code, they enter the upper-limit value for each metric. We consider this upper value an OO constraint that should be enforced during maintenance tasks. The tool MetricsEnforcer enables designers to fill the fields of constraints for each class. Designers have to determine the design constraints for each class they want to enforce. The constraintsXML file is automatically generated once designers fill all fields of design constraints. Designers can manage and update their constraints at any time. Once the class is selected from the drop-down list, its current metrics are automatically recovered from its up-to-date srcML representation. The metrics are filled in ‘Class Statistics’ fields. The previously defined constraints for the class are filled in the ‘Design Constraints’ fields. Now, the values of constraints in text fields can be updated and a new version of constraintsXML file is generated for the class under consideration. Each class has both XML representations: srcML and constraintsXML. Both representations are parsed to check any violation in any design constraint. After each commit, srcML is regenerated to keep it up to date. The process of identifying violation of enforced constraints is detailed in the following procedure: 1

Changed source code files are represented in srcML.

2

Analyse code changes using the srcTracer (Hammad et al., 2009, 2011) tool to identify design changes.

3

If the design change is an addition of a new subclass A: a

b

4

parse srcML to find the root class of the inheritance tree of A and to count the current DIT from the subclass A to the root parse constraintsXML file of the root class to check the M_DIT constraint and compare it with number found in 2-a.

If the design change is an addition of a new method to class A: a

parse srcML to count the current NOM in class A, the NOM in all ancestors of class A, and the NCM by class A

b

5

55 parse constraintsXML file of class A to check the M_NOM, M_NIM and M_NCM constraints and compare them with numbers found in 3-a.

If the design change is an addition of a new association/dependency relationship from class A to class B: a

parse srcML file of class A to find the current number of classes involved in any (dependency or association) relationship from class A to other classes

b

parse constraintsXML file of class A to check the M_NOD/M_NOA constraints and compare them with numbers found in 4-a.

Once developer commits a code change, both old and new versions of source files affected by the change are represented in srcML (Step 1). Both srcML files are used by the srcTracer (Source Tracer) (Hammad et al., 2009, 2011) to identify design changes caused by the commit (Step 2). srcTracer automatically identifies code changes that break traceability links between code and design. A design change is any change that affects the UML class diagram of the code. The change could be addition/deletion of a class, a method, or a relationship. The relationship could be a generalisation, dependency, or association. The process of identifying design changes from code changes that is followed by srcTracer is summarised in the following procedure: 1

Generate the srcML for each of the two file versions

2

Generate the srcDiff (Maletic and Collard, 2004) from the two srcML files

3

Query srcDiff to identify design changes

4

a

Added/Deleted classes

b

Added/Deleted methods

c

Added/Deleted relationships

Report the design change.

The approach presented by Hammad et al. (2009, 2011) identifies if a code change impacts the UML class diagram or not and what is the impact (i.e., code-design consistency). In this paper, the approach is used to determine if a code change impacts OO constraints (i.e., design-constraints consistency).

3.3 Checking for violations The unit of code change is the commit. After a commit, design changes are identified from the code change by the srcTracer tool (Hammad et al., 2009, 2011). The identified design changes are compared against the constraints saved in constraintsXML file. So, constraintsXML file is parsed after a design change is identified to check any possible violation of enforced constraint. Not all constraints are checked at a time. The checking process depends on the type of design change.

56

M. Hammad et al. The tool has been tested by two human subjects who are software developers and familiar with C++. These two subjects have been asked to implement a set of maintenance tasks for each file from the selected 20 files. The maintenance tasks are designed to directly support testing design constraints under consideration. The designed maintenance tasks follow these patterns:

The identified design changes by srcTracer are used in Steps 3–5. In Step 3, the M_DIT is checked in case the design change is an addition of a new subclass. The checking is done in two steps; finding the DIT metric for the new version of the code (Step 3-a), and comparing the extracted DIT value with the M_DIT constraint (Step 3-b). The same applies for the other constraints in Steps 4 and 5. In case the MetricsEnforcer tool detects a violation, a message with the following pattern is shown to the developer who committed the code change.

•

Add method(s) named M to class C

•

Add a subclass named SUB to the class SUPER

•

NEW METHOD of CLASS Employee was added Employee::taxCalculations

•

Declare a data field object named O to class C

•

•

Declare a local object named O in method M

VIOLATION in NUMBER of METHODS for CLASS Employee

•

Add method(s) named M to the super class SUPER

•

MAX NUMBER of METHODS ALLOWED is 8

•

Call method CLASS1::M1 from method CLASS2::M2.

•

NEW CHILD of CLASS Employee was added

•

VIOLATION in NUMBER of CHILDREN for CLASS Employee

•

MAX NUMBER of CHILDREN ALLOWED is 3.

The message shows the type of design change that caused the violation. It also shows the location of the violation and the enforced value that should be preserved.

4

Evaluation

The tool has been tested on a set of maintenance tasks that we developed. The maintenance tasks are applied on an open-source project. The open-source project that was used in the evaluation is the Kdenetwork project, which is part of the KDE open-source project (www.kde.org). Release 4.1.0 of Kdenetwork has been used for the evaluation. The release can be downloaded from (http://download.kde.org/Attic/ 4.1.0/src/). We selected Kdenetwork because it is a medium-size project. It is also written in C++ and it is available online by the subversion of the KDE project (http://websvn.kde.org/trunk/KDE/kdenetwork/). A subset of source code files have been randomly selected from the project for the evaluation. We took into consideration that the selected files cover all the discussed design constraints. The number of selected files is 20 with 10 classes. The procedure that we followed of the evaluation process is: 1

the selected files have been used to initialise the tool

2

the design constraints of all classes under consideration have been set to the classes’ statistics of release 4.0.0

3

human subjects are asked to implement and commit a set of maintenance tasks that we developed

4

after each commit, the tool analyses committed code changes and saves its results

5

the code changes of each commit and the tool’s results for that commit were checked manually to determine the correctness of the saved results.

We tried to cover all design constraints under consideration in the maintenance tasks. For example, the second pattern is used to test the DIT. The fifth pattern is used to test the number of inherited methods. The sixth pattern is used to test the NCM. Figure 6 shows one of the classes that were used for evaluation. The name of the class is NFSFile. The class is defined in the header file filesharing_4.0.0\advanced\ nfs\nfsfile.h. The class defined 10 methods. So, the M_NOM constraint of the tool was set to 10. One of the designed maintenance tasks for this class asks subjects to add a new method to the class. When subjects commit this code change, MetricsEnforcer reports a warning about a violation to the NOM design constraint. If the tool does not report a warning, it means the tool failed to identify the violation. Figure 6

One of the Kdenetwork classes that used to evaluate MetricsEnforcer

An approach to automatically enforce object-oriented constraints The results of the tool were checked manually with code to evaluate the correctness of the results. We found that the tool could identify most of the violations in OO constraints with some exceptions. The correctness results are shown in Table 1. The ‘Correctness’ column shows the result of the manual checking of the tool’s results against code changes for each constraint. The percentage represents the number of correct violations identified by the tool divided by the total number of violations that should be correctly identified. For example, the tool correctly identified nine out of 10 (90%) of the violations for M_NCM constraint that are committed by the first subject. This means that the maintenance tasks involve the addition of 10 new method calls that are distributed over all classes under testing. All these 10 new calls violate the M_NCM constraint for each class. The tool correctly identified nine of them for the first subject and all of them for the second subject. Table 1

Correctness results of MetricsEnforcer’s performance in detecting violations of predefined OO constraints Correctness

OO constraint

Subject 1

Subject 2

No. of methods

(15/15) 100%

(15/15) 100%

No. of called methods

(9/10) 90%

(10/10) 100%

No. of inherited methods

(1/3) 30%

(1/3) 30%

No. of Children

(4/6) 70%

(3/6) 50%

Depth of inheritance tree

(2/4) 50%

(2/4) 50%

No. of dependencies

(9/10) 90%

(8/10) 80%

No. of associations

(8/10) 80%

(9/10) 90%

The variations in the percentages of the two subjects are due to the different interpretations of the maintenance tasks by developers. The programming style of developers also had some impact on the results. The evaluation also showed that the tool saves time and efforts in enforcing OO constraints compared with manual process. The tool has low accuracy in identifying violations in case of multiple inheritances exist. In this case, the M_DIT is not correctly evaluated for some cases. This is due to tracing the multi-paths of the inheritance tree of the leaf class. The same applies in counting the number of inherited methods and number of children. Another problem occurred when the inheritance tree could not be followed. For example, one class inherits another super class from external project. In this case, the super class should be traced in an external project. The solution to this problem is to get srcML for all internal and external projects of the system. In some cases, the tool could not identify all dependencies and associations relationships. Some declared objects or references were not correctly identified because some non-primitive types are not classes. For instance, EntryList in the following example is not only a non-primitive type but also it is not a class. typedef Q3PtrList EntryList;

5

57

Threats to validity

The developed approach was evaluated on one open-source project. Results may be different with other types of projects that support different types of applications. Furthermore, the selected open-source project is not a large-scale project. The developed maintenance tasks might not cover all possible cases of OO constraints violations. Results may change with different or actual maintenance tasks. The performance of MetricsEnforcer depends on the efficiency of srcML and srcTracer.

6

Related work

Marinescu (2004) proposed a mechanism called detection strategy for formulating metrics-based rules that capture deviations from good design principles and heuristics. The approach helps to localise classes or methods affected by a particular design flaw. In our approach, we do not identify design flaws; instead, we identify violations of predefined OO metrics. Aldrich et al. (2002) proposed ArchJava, a small backwards-compatible extension to Java that integrates software architecture specifications into Java implementation code. ArchJava unifies architectural structure and implementation in one language to ensure traceability between architecture and code. It also supports the co-evolution of architecture and implementation. The work has been extended in Aldrich (2008). ArchJava does not support the consistency of object design metrics as MetricsEnforcer does. Antoniol et al. (2000) presented an approach to trace OO design to implementation. The goal was to check the compliance of OO design with source code but not design metrics. Oussalah et al. (2005) proposed a model called software architecture evolution model (SAEV) that offers evolution operations described by evolution strategies and evolution rules to manage the architectural elements evolution. The approach is more architectural oriented rather than design metric oriented. Many approaches focus on enforcing the high-level architecture of the software. Reiss (2002, 2005) presented a framework for constraining software evolution. Constraints are defined between the artefacts representing the different software aspects. The approach preserves UML class diagrams as design constraints with source code. In our approach, we preserve object-oriented design metrics not UML diagrams. Eichberg et al. (2008) presented an approach to express constraints on structural dependencies between arbitrary ensembles, which are continuously enforced as the software evolves. They defined the term ensemble to denote any logical grouping of code elements affected by a structural dependency constraint to be expressed. The approach differs from our approach in defining domain-specific language embedded for defining ensembles. The approach differs in the type of enforced constraints. Gustafsson et al. (2002) presented architecturecentric software evolution method. They presented Maisa, a Java-based tool for evaluating software architectures. Maisa is integrated with the reverse engineering tool

58

M. Hammad et al.

Columbus (Ferenc et al., 2002). It keeps track of the evolution of the software system by storing the measurements in a database. MetricsEnforcer differs in focusing on enforcing OO metrics not the high-level architecture of the software system. Many empirical studies (Basili et al., 1996; Gyimothy et al., 2005; Zhou and Leung, 2006; Alshayeb and Li, 2003; Sato et al., 2007; Marcus et al., 2008; Capra et al., 2008; Kelly, 2006; Singh and Saha, 2012) were conducted to investigate the relationship between object-oriented design metrics and software quality. From these studies, we inferred the importance of controlling and monitoring changes in OO design constraints based on OO metrics. In the field of presenting design patterns as constraints, Lovatt et al. (2005) presented a conventional compiler but extended to include the extra checks needed to enforce design patterns. Patterns are enforced at the class level; the class has to be written to conform to the pattern. Blewitt et al. (2005) presented a pattern specification Prolog-like language called SPINE, to allow design patterns to be defined in terms of constraints on their implementation in Java. Eichberg et al. (2008) presented an approach to express constraints on structural dependencies between program elements to avoid erosion of the intended structure of the code. The approach defines a new logic-based language called LogEn to express ensembles and constraints on their dependencies. Kim and Shen (2007) proposed an approach to evaluating the conformance of class diagrams described in UML to pattern specifications described Role-Based Meta-modelling Language. Zhu et al. (2009) presented a tool called LAMBDES-DP to support the use of design patterns during development. We do not use any logic- or role-based approach to enforce the constraints. Our approach differs from related work in the field in many ways. First, the constraints we defined are based on the OO design metrics and hence preserving the quality of design. Second, the OO constraints are represented in flexible XML format. Third, violations of constraints are directly identified from code changes without logic programming approaches.

7

Conclusions

The paper presented an approach to automatically enforce object-oriented constraints during software development. The presented approach identifies violations directly from code changes. The enforced constraints by the approach are mainly taken from object-oriented metrics. These metrics are represented in an XML format that can be easily extended to include more constraints. To utilise the proposed approach in development, a tool named MetricsEnforcer has been developed. The MetricsEnforcer tool can be realised as a plug in tool in an IDE to support the enforcement of object-oriented constraints during incremental code changes.

MetricsEnforcer has some limitations in dealing with multiple inheritances. The tool also may not identify exactly all dependency and association relationships in case of some non-primitive types are not classes. Our future works aim to enforce other types of constraints, mainly non-object-oriented constraints such as line of code (LOC). Other types of constraints are under consideration; the programming style and documentation. For example, designers may prefer to enforce specific naming style for identifiers. Another example is the enforcement of specific style for comments that to document code elements.

References Aldrich, J. (2008) ‘Using types to enforce architectural structure’, Seventh Working IEEE/IFIP Conference on Software Architecture, Vancouver, BC, pp.211–220. Aldrich, J., Chambers, C. and Notkin, D. (2002) ‘ArchJava: connecting software architecture to implementation’, 24th International Conference on Software Engineering (ICSE’02), Florida, USA, pp.187–197. Alshayeb, M. and Li, W. (2003) ‘An empirical validation of object-oriented metrics in two different iterative software processes’, IEEE Transactions on Software Engineering, Vol. 29, No. 11, pp.1043–1094. Antoniol, G., Caprile, B., Potrich, A. and Tonella, P. (2000) ‘Design-code traceability for object-oriented systems’, Annals of Software Engineering, Vol. 9, Nos. 1–4, pp.35–58. Basili, V.R., Briand, L.C. and Melo, W.L. (1996) ‘A validation of object-oriented design metrics as quality indicators’, IEEE Transactions on Software Engineering, Vol. 22, No. 10, pp.751–761. Blewitt, A., Bundy, A. and Stark, I. (2005) ‘Automatic verification of design patterns in Java’, 20th IEEE/ACM international Conference on Automated Software Engineering (ASE’05), California, USA, pp.224–232. Capra, E., Francalanci, C. and Merlo, F. (2008) ‘An empirical study on the relationship among software design quality, development effort, and governance in open source projects’, IEEE Transactions on Software Engineering, Vol. 34, No. 6, pp.765–782. Chidamber, S.R. and Kemerer, C.F. (1994) ‘A metrics suite for object oriented design’, IEEE Transactions on Software Engineering, Vol. 20, No. 6, pp.476–493. Chidamber, S.R., Darcy, D.P. and Kemerer, C.F. (1998) ‘Managerial use of metrics for object-oriented software: an exploratory analysis’, IEEE Transactions on Software Engineering, Vol. 24, No. 8, pp.629–639. Collard, M.L., Kagdi, H.H. and Maletic, J.I. (2003) ‘An XMLBased lightweight C++ fact extractor’, 11th IEEE International Workshop on Program Comprehension (IWPC’03), Portland, OR, pp.134–143. Collard, M.L., Maletic, J.I. and Marcus, A. (2002) ‘Supporting document and data views of source code’, 2nd ACM Symposium on Document Engineering (DocEng’02), Virginia, USA, pp.34–41.

An approach to automatically enforce object-oriented constraints Eichberg, M., Kloppenburg, S., Klose, K. and Mezini, M. (2008) ‘Defining and continuous checking of structural program dependencies’, 30th ACM/IEEE International Conference on Software Engineering (ICSE’2008), Germany, pp.391–400. Ferenc, R., Magyar, F. et al. (2002) ‘Columbus – reverse engineering tool and schema for C++’, 18th IEEE International Conference on Software Maintenance (ICSM'’02), Canada, pp.172–181. Gustafsson, J., Paakki, J., Nenonen, L. and Verkamo, A.I. (2002) ‘Architecture-centric software evolution by software metrics and design patterns’, 6th European Conference on Software Maintenance and Reengineering (CSMR’02), Budapest, pp.108–115. Gyimothy, T., Ferenc, R. and Siket, I. (2005) ‘Empirical validation of object-oriented metrics on open source software for fault prediction’, IEEE Transactions on Software Engineering, Vol. 31, No. 10, pp.897–910. Hammad, M., Collard, M.L. and Maletic, J.I. (2009) ‘Automatically identifying changes that impact code-todesign traceability’, 17th IEEE International Conference on Program Comprehension (ICPC’09), Vancouver, Canada, pp.20–29. Hammad, M., Collard, M.L. and Maletic, J.I. (2011) ‘Automatically identifying changes that impact code-todesign traceability during evolution’, Journal of Software Quality, Vol. 19, No. 1, pp.35–64. Kelly, D. (2006) ‘A study of design characteristics in evolving software using stability as a criterion’, IEEE Transactions on Software Engineering, Vol. 32, No. 5, pp.315–329. Kim, D. and Shen, W. (2007) ‘An approach to evaluating structural pattern conformance of UML models’, 2007 ACM Symposium on Applied Computing (SAC’07), Seoul, Korea, pp.1404–1408. Lehman, M.M. and Ramil, J.F. (2001) ‘Rules and tools for software evolution planning and management’, Annals of Software Engineering Vol. 11, No. 1, pp.15–44. Lehman, M.M. and Ramil, J.F. (2002) ‘Software evolution and software evolution processes’, Annals of Software Engineering, Vol. 14, Nos. 1–4, pp.275–309. Lovatt, H.C., Sloane, A.M. and Verity, D.R. (2005) ‘A pattern enforcing compiler (PEC) for Java: using the compiler’, 2nd Asia-Pacific Conference on Conceptual Modeling, Australia, pp.69–78. Maletic, J.I. and Collard, M.L. (2004) ‘Supporting source code difference analysis’, IEEE International Conference on Software Maintenance (ICSM’04), Chicago, Illinois, pp.210–219.

59

Marcus, A., Poshyvanyk, D. and Ferenc, R. (2008) ‘Using the conceptual cohesion of classes for fault prediction in object-oriented systems’, IEEE Transactions on Software Engineering, Vol. 34, No. 2, pp.287–300. Marinescu, R. (2004) ‘Detection strategies: metrics-based rules for detecting design flaws’, IEEE International Conference on Software Maintenance (ICSM’04), Chicago, Illinois, pp.350–359. Mishra, D. and Mishra, A. (2011) ‘A review of non-technical issues in global software development’, Int. Journal of Computer Applications in Technology, Vol. 40, No. 3, pp.216–224. Oussalah, M., Sadou, N. and Tamzalit, D. (2005) ‘A generic model for managing software architecture evolution’, 9th WSEAS International Conference on Systems (ICS’05), Greece, Article No. 35. Reiss, S. (2002) ‘Constraining software evolution’, 18th IEEE International Conference on Software Maintenance (ICSM’02), Montreal, Canada, pp.162–171. Reiss, S. (2005) ‘Incremental maintenance of software artifacts’, 21st IEEE International Conference on Software Maintenance (ICSM’05), Budapest, pp.113–122. Sato, D., Goldman, A. and Kon, F. (2007) ‘Tracking the evolution of object-oriented quality metrics on agile projects’, 8th International Conference on Agile Processes in Software Engineering and Extreme Programming, Italy, pp.84–92. Schach, S. (2010) Object-Oriented and Classical Software Engineering, 8th ed., McGraw-Hill. Singh, Y. and Saha, A. (2012) ‘Prediction of testability using the design metrics for object-oriented software’, Int. Journal of Computer Applications in Technology, Vol. 44, No. 1, pp.12–22. Zhou, Y. and Leung, H. (2006) ‘Empirical analysis of object-oriented design metrics for predicting high and low severity faults’, IEEE Transactions on Software Engineering, Vol. 32, No. 10, pp.771–789. Zhu, H., Bayley, I., Shan, L. and Amphlett, R. (2009) ‘Tool support for design pattern recognition at model level’, 33rd Annual IEEE International Computer Software and Applications Conference (COMPSAC’09), Seattle, USA, pp.228–233.