Software Engineering thread

Metrics for object-oriented design

The MOOD (Metrics for Object Oriented Design) set proposal was a pioneering proposal of a coherent metrics set for object-oriented design. It guaranteed both a good coverage of OO design features such as inheritance, polymorphism, information hiding and coupling, along with a formal definition on a percentage scale that allowed language and size independence, thus fostering comparability. Several independent researchers have validated the MOOD metrics as predictors for maintenance effort and reliability and for supporting code-smells detection and assessing refactoring results. This metric set has been adopted by several tool vendors such as Krakatau professional , Aivosto Project Analyzer or Cantata++ , thus providing some evidence that my contributions in this topic have found an application in industry. In addition, we keep receiving regular requests from practitioners and researchers all over the world, for information on free MOOD collection tools, namely for Java code. Although several papers report the usage of MOOD in Java programs, we could not yet find an open source tool for that purpose. To fill this gap we are currently working on the extension of a well-known open-source metrics collection tool available from sourceforge to support MOOD2 metrics collection, an evolution of the original set. My prospect is to support the resulting tool, thus contributing to UNL’s objective to ensure the provision of quality services at the international level.

Metamodel driven measurement

While reviewing two decades of published work on software metrics, we always felt uncomfortable by the lack of formality in their definition. This situation leads to subjectivity in their interpretation and in the implementation of collection tools. When we defined the MOOD set, we used mathematics formulae, but still had to explain the context and interpretation of each term in natural language. We then realized that we could use an abstract representation of the relevant concepts and their relationships of the target domain – an ontology – to avoid the subjectivity of natural language. Since the target domain is the one of mograms (term that was suggested to designate both models and programs expressed in any language) whose abstract syntax is indeed a model, we get a modeling ontology, or simply a “metamodel”. The use of a metamodel improved metrics definition objectivity but there was still a notational gap. When we came across the OCL constraint language, we figured out that we found the perfect match and proposed the M2DM (Meta-Model Driven Measurement) technique in which metrics are defined as OCL expressions upon the adopted metamodel. M2DM allows the clarification of the target domain, grants accurateness in metrics specification due to the use of OCL and offers automatic metrics collection, provided we are able to instantiate the metamodel appropriately. As a result, it facilitates metrics usage by practitioners and experiments replication by researchers. The original proposal used the GOODLY metamodel, but since then we have used it in other contexts, such as with the following OMG’s metamodels: CORBA, UML 1.x, UML 2.0 and Common Warehouse Metamodel.

Assessing and refactoring modularity

One of the more widespread theories found in software engineering books is that cohesion is a good design feature since it promotes encapsulation and coupling is evil, due to the potential side-effects. Therefore, the mitigating solution turns out to be expressed by the following two recurrent rules/advices: “minimize coupling and maximize cohesion”! We always looked at the latter as somehow flawed prescriptions, since that, when taken strictly, they would lead to a monolithic system. Indeed, a system with just one module fulfills both rules. We theorized that the solution to an optimally modularized system would need to take into account a third driving force: divide and conquer. In other words, a complex system should be split in parts. We defined a modularization merit factor based upon the previous three design desiderata and explored several agglomerative clustering techniques to find the optimal solution on several OO open-source projects from well reputed origins, regarding class packaging. The conclusion was that those systems were far from the optimal split, that is, it was possible to derive much better clustering solutions using clustering algorithms. We plan to resume this research topic for aspect-oriented systems, where we will consider the multidimensionality facets of modularity.

DSL for object-oriented design

Our modularity refactoring and metrics collection experiments upon source code, raised our attention to the need of a more abstract notation for expressing OO design, namely to facilitate the comparability among systems written in different OO programming languages. For that purpose, we proposed a domain-specific language (DSL) which was coined GOODLY (a Generic Object-Oriented Design Language? Yes!). Prototypes of C++ to GOODLY, Smalltalk to GOODLY and Eiffel to GOODLY transformation tools were developed by my junior advisees by then. We abandoned GOODLY in favor of the USE tool concrete syntax for expressing OO designs, proposed by Martin Gogolla’s team at Bremen University, which resembles a lot to GOODLY, but had the advantage of being integrated in the best OCL specification environment we ever put my hands on. However, looking back to this decision, we regret having lost the ability to express higher level modularity constructs (e.g. packages) and constraining feature access and navigation by means of visibility constructs (aka access control modifiers) that were present on GOODLY’s syntax.

Component-based software engineering

Most claims in component-based development (CBD) are supported by qualitative expert opinion, rather than by quantitative data. This contrasts with the normal practice in other sciences, where a sound experimental validation of claims is standard practice. Experimental Software Engineering (ESE) aims to bridge this gap. Our goals here were to contribute to the evolution of ESE, in what concerns the replicability and comparability of experimental work, and to apply our proposals to CBD, thus contributing to its deeper and sounder understanding. We started by proposing a process model for ESE, aligned with current experimental best practices, and combined this model with M2DM, which we renamed to ontology-driven measurement (ODM), for the sake of generality. We used both the process model and ODM to perform a series of experimental works in CBD, including the cross-validation of a component metrics set for JavaBeans, a case study on the influence of practitioners expertise in a sub-process of component development (component code inspections), and an observational study on reusability patterns of pluggable components (Eclipse plug-ins). These experimental works implied proposing, adapting, or selecting adequate ontologies, as well as the formal definition of metrics upon each of those ontologies.

Code smells detection

The idea of automating code smells detection by using metrics is not new, but such proposals usually require the setting-up of metrics’ thresholds, used by tools as decision criteria. Those thresholds are not consensual and, to the best of my knowledge, were not validated, thus leaving the detection process still in the realm of subjectivity. To address this problem, we proposed to use Binary Logistic Regression estimation models (one per each code smell) calibrated by expert’s knowledge. Positive and statistically significant results were obtained in an experiment to detect the Long Method code smell, using a relatively large sample of pre-annotated source code by human experts, indicating where they found instances of each code smell. Currently we are preparing a second experiment with more code smells and we are developing an Eclipse plugin that combines a metrics tool with a statistics tool (R system), to integrate the proposed technique in the Java IDE. In the near future, we plan to use machine-learning techniques with the same sample and compare the detection accuracy. The next step will then be to integrate the code-smells detection models in the refactoring process and provide a sound advice to practitioners on the quality improvements obtained by applying alternative transformations taken from a refactoring catalog.