Bruno Carreiro da Silva

Crosscutting patterns and design stability: An exploratory analysis

It is often claimed that inaccurate modularisation of crosscutting concerns hinders program comprehension and, as a consequence, leads to harmful software instabilities. However, recent studies have pointed out that crosscutting concerns are not always harmful to design stability. Hence, software maintainers would benefit from well documented patterns of crosscutting concerns and a better understanding about their actual impact on design stability. This paper presents a catalogue of crosscutting concern patterns recurrently observed in software systems. These patterns are described and classified based on an intuitive vocabulary that facilitates their recognition by software engineers. We analysed instances of the crosscutting patterns in object-oriented and aspect-oriented versions of three evolving programs. The outcomes of our exploratory evaluation indicated that: (i) a certain category of crosscutting patterns seems to be good indicator of harmful instabilities, and (ii) aspect-oriented solutions were unable to modularise concerns matching some crosscutting patterns.

An Integrated Approach for Model Driven Process Modeling and Enactment

The adoption of MDA in software development is increasing and is widely recognized as an important approach for building software systems. However, theres a lack of standard terminology and notation addressing design aspects of an MDA process. The available MDA tools and environments are particularly focused in defining and executing model transformations, while a development process involves other important definitions which should be carried out during the process enactment. This paper presents an integrated approach for MDA process modeling and enactment based on specializations of some SPEM 2 concepts. To support and evaluate our approach a tool was developed and applied in two case studies.

Concern-based cohesion as change proneness indicator: an initial empirical study

Structure-based cohesion metrics, such as the well-known Chidamber and Kemerers Lack of Cohesion in Methods (LCOM), fail to capture the semantic notion of a software components cohesion. Some researchers claim that it is one of the reasons they are not good indicators of change proneness. The Lack of Concern-based Cohesion metric (LCC) is an alternative cohesion metric which is centered on counting the number of concerns a component implements. A concern is any important concept, feature, property or area of interest of a system that we want to treat in a modular way. In this way, LCC focus on what really matters for assessing a components cohesion - the amount of responsibilities placed on them. Our aim in this paper is to present an initial investigation about the applicability of this concern-based cohesion metric as a change proneness indicator. We also checked if this metric has a correlation with efferent coupling. An initial empirical assessment work was done with two small to medium-sized systems. Our results indicated a moderate to strong correlation between LCC and change proneness, and also a strong correlation between LCC and efferent coupling.

Supporting model-driven development using a process-centered software engineering environment

The adoption of Model-Driven Development (MDD) is increasing and it is widely recognized as an important approach for building software systems. In addition to traditional development process models, an MDD process requires the selection of metamodels and mapping rules for the generation of the transformation chain which produces models and application code. In this context, software process tasks should be performed in a specific sequence, with the correct input artifacts to produce the output ones. However, existing support tools and transformation engines for MDD do not have a process-centered focus that addresses different kinds of software process activities, such as application modeling and testing to guide the developers. Furthermore, they do not enable process modeling nor the (semi) automated execution of activities during process enactment. The MoDErNE (Model Driven Process-Centered Software Engineering Environment) uses process-centered software engineering environment concepts to improve MDD process specification and enactment by using a metamodeling foundation. In MoDErNE, a software process model may be enacted several times in different software projects. This paper details the MoDErNE environment, its approach and architecture and also the case studies through which the tool was evaluated.

Modden: An Integrated Approach for Model Driven Development and Software Product Line Processes

In a Software Product Line reuse should be considered from the artifacts conception stage and, when implemented, these artifacts can be part of a library to be further reused by every domain application. In a model-driven context an application development can be seen as a set of transformations that lead to a final system. However, during the transformation process reuse techniques are not usually considered. Modden is a SPL approach that uses model-driven techniques. Through the integration of these two approaches we aim to enhance model-driven techniques by the reuse of models, code, transformation rules and so on. As a result, Modden aims to leverage the reuse of these artifacts in different software development process phases. It comprises two processes, one to develop core assets and another to develop specific assets for the product line, a SPL UML profile and a model driven development supporting tool.

Concern-based cohesion: Unveiling a hidden dimension of cohesion measurement

Cohesion has been avidly recognized as a key property of software modularity. Ideally, a software module is considered to be cohesive if it represents an abstraction of a single concern of the software. Modules with several concerns may be harder to understand because developers must mentally separate the source code related to each concern. Also, modules implementing several concerns are more likely to undergo changes as much as distinct development tasks may target its different concerns. The most well-known cohesion metrics are defined in terms of the syntactical structure of a module, and as a consequence fail to capture the amount of concerns realized by the module. In this context, we investigated the potential of a new metric, called Lack of Concern-based Cohesion. This metric explicitly counts the number of concerns realized by each module. We compared this metric with other five structural cohesion metrics by applying them over six open source software systems. We studied how those metrics are associated with module changes by mining over 16,000 repository revisions. Our results pointed out that the concern-based metric captured a cohesion dimension that is not reflected by structural metrics, and, as a consequence, adds to the association of cohesion and change-proneness.

AN APPROACH TO MODEL-DRIVEN DEVELOPMENT PROCESS SPECIFICATION

The adoption of MDA in software development is increasing and is widely recognized as an important approach for building software systems. Meanwhile, the use of MDA requires the definition of a software process that guides developers in the elaboration and generation of models. While first model-driven software processes have started to appear, an approach for describing them in such way that they may be better communicated, understood, reused and evolved systematically by the development team is lacking. In this context, this paper presents an approach for the specification of MDA processes based on specializations of some SPEM 2 concepts. In order to support and evaluate our approach a tool was developed and applied in a particular MDA process for specific middleware services development.

Evaluating Maintainability of MDA Software Process Models

The description of a software process is called a process model. As well as traditional software processes/methods (e.g. RUP, XP, OSDP, etc.) an MDA software process requires the selection of metamodels and mapping rules for the generation of the transformation chain that produces models and application code. Before software process enactment, process models should be evaluated in order to improve some quality attributes and maintainability is one of the main factors for software process reuse and improvement. This paper presents a conceptual framework including a metrics suite to evaluate maintainability of MDA process models. We also describe an empirical assessment involving three case studies where the metrics suite was applied to over five MDA process models. We compared the results indicated by the measurements with software engineer opinions surveyed by an online questionnaire. We found that the results from the metrics-based conceptual framework application match software engineers’ perceptions.

Model Transformation Using Graph Transactions

Model transformations are central to model driven software engineering. The main aim of defining a model transformation is to reuse this model by adapting it to a new situation or context (aims of transformation include synthesis, reverse engineering, migration, optimization, refactoring, etc). Given two metamodels T 1 and T 2 a model transformation takes as input a model of T 1 and delivers as result a corresponding model with respect to T 2. Since many modelling languages are diagrammatic (like class-diagrams, message sequence charts, state charts), it is natural to use graphs as a formal basis to describe metamodels of these languages. Rules that transform graphs can be used to describe the transformation process. Here we propose the use graph grammars with transactions to describe model transformations. The notion of (graph) transaction can be very useful in proving essential properties of model transformation, like termination, confluence and correctness.

Two quasi-experiments on cohesion metrics and program comprehension

Cohesion represents the degree to which a software module is focused on a single responsibility. It believes that the more cohesive, the easier it will be to understand the source code of a module. However, there is no empirical evidence about the relationship between cohesion, quantified by metrics, and the effort for understanding programs. In this context, we conducted two quasi-experiments to evaluate the relationship between cohesion measurements and the effort spent to understand the source code of classes in object-oriented systems. The results provide no evidence that cohesion affects program comprehensibility.