Search-based software engineering has been extensively applied to the problem of finding improved modular structures that maximize cohesion and minimize coupling. However, there has, hitherto, been no longitudinal study of developers' implementations, over a series of sequential releases. Moreover, results validating whether developers respect the fitness functions are scarce, and the potentially disruptive effect of search-based remodularization is usually overlooked. We present an empirical study of 233 sequential releases of ten different systems; the largest empirical study reported in the literature so far, and the first longitudinal study. Our results provide evidence that developers do, indeed, respect the fitness functions used to optimize cohesion/coupling (they are statistically significantly better than arbitrary choices with p ≪ 0.01), yet they also leave considerable room for further improvement (cohesion/coupling can be improved by 25% on average). However, we also report that optimizing the structure is highly disruptive (on average more than 57% of the structure must change), while our results reveal that developers tend to avoid such disruption. Therefore, we introduce and evaluate a multiobjective (MO) evolutionary approach that minimizes disruption while maximizing cohesion/coupling improvement. This allows developers to balance reticence to disrupt existing modular structure, against their competing need to improve cohesion and coupling. The MO approach is able to find modular structures that improve the cohesion of developers' implementations by 22.52%, while causing an acceptably low level of disruption (within that already tolerated by developers).
Many of the ways to depict software are based on graphs, although what nodes and edges represent differ from visualisation to visualisation. In this paper we present a light-weight approach to enrich graphbased visualisations so that nodes can represent more information. The idea is to show in each node a rectangle of pixels, each representing a certain element associated to the node, and the colour of each pixel representing up to three attributes of that element. The order of the pixels is user defined and may convey additional information. The approach is generic and allows data obtained through completely different reverse engineering processes to be shown together in a compact way that preserves the meaning of the graph layout. We illustrate our approach by showing how software architecture and defects can be related: a graph depicting the high-level components and their dependencies is enriched with information about the bugs reported for each component.
During software maintenance and evolution, developers need to deal with a large number of change requests by modifying existing code or adding code into the system. An efficient tackling of change request calls for an accurate localising of software changes, i.e. identifying which code are problematic and where new files should be added for any type of change request at hand, such as a bug report or a feature request. Existing automatic techniques for this change localisation problem are limited in two aspects: on the one hand, they are only limited to tackle a specific type of change request; on the other hand, they are focused on finding files that should be modified for a change request, yet barely capable of recommending what files or packages might be newly created. To address the limitations, we are inspired to propose a generalised change localisation approach to identify the to-be-modified files (mostly for bugs), and at the same time point out where new files or packages should be created (mostly for new feature requests) for an arbitrary type of change request. In order to tackle the key challenge of predicting to-be-created program elements, our proposed SeekChanges approach leverages the hierarchical package structure for Java projects, and model the change localisation problem as a structured information retrieval (IR) task. A systematic investigation of three structured IR strategies is carried out for scoring and ranking both the files that should be modified and the software packages in which the new files should be created to address change requests. Extensive experiments on four open source Java projects from the Apache Software Foundation demonstrate that structured IR strategies have a good performance on recommending newly created files, while the overall performance of localising change requests is equally satisfactory.
The success of a business process (BP) depends on whether it meets its business goal as well as non-functional requirements associated with it. BP specifications frequently need to accommodate changing business priorities, varying client preferences, etc. However, since business process goals and preferences are rarely captured explicitly in the dominant BP modeling approaches, adapting business processes proves difficult. We propose a systematic requirements-driven approach for BP design and configuration management that uses requirements goal models to capture alternative process configurations and provides the ability to tailor deployed processes to changing business priorities or customer preferences (i.e., non-functional constraints) by configuring their corresponding goal models at the goal level. A set of design time and runtime tools for configuring business processes implemented using WS-BPEL is provided, allowing to easily change the behaviour of deployed BP instances at a high level, based on business priorities and stakeholder preferences.
Naming conventions can help the readability and comprehension of code, and thus the onboarding of new developers. Conventions also provide cues that help developers and tools extract information from identifier names to support software maintenance. Tools exist to automatically check naming conventions but they are often limited to simple checks, e.g. regarding typography. The adherence to more elaborate conventions, such as the use of noun and verbal phrases in names, is not checked. We present Nominal, a naming convention checking library for Java that allows the declarative specification of conventions regarding typography and the use of abbreviations and phrases. To test Nominal, and to investigate the extent to which developers follow conventions, we extract 3.5 million reference - field, formal argument and local variable - name declarations from 60 FLOSS projects and determine their adherence to two well-known Java naming convention guidelines that give developers scope to choose a variety of forms of name, and sometimes offer conflicting advice. We found developers largely follow naming conventions, but adherence to specific conventions varies widely.
'/%3e%3cuse xlink:href='%23a' transform='rotate(23.036 .093 25.536)'/%3e%3cuse xlink:href='%23a' transform='rotate(45.87 1.273 16.18)'/%3e%3cuse xlink:href='%23a' transform='rotate(69.945 .996 12.078)'/%3e%3cuse xlink:href='%23a' transform='rotate(20.66 -19.689 31.932)'/%3e%3c/svg%3e)
'%3e%3cpath fill='%23012169' d='M0 0v30h60V0z'/%3e%3cpath stroke='%23fff' stroke-width='6' d='m0 0 60 30m0-30L0 30'/%3e%3cpath stroke='%23C8102E' stroke-width='4' d='m0 0 60 30m0-30L0 30' clip-path='url(%23b)'/%3e%3cpath stroke='%23fff' stroke-width='10' d='M30 0v30M0 15h60'/%3e%3cpath stroke='%23C8102E' stroke-width='6' d='M30 0v30M0 15h60'/%3e%3c/g%3e%3c/svg%3e)
'/%3e%3cuse xlink:href='%23a' transform='rotate(144 450 300)'/%3e%3cuse xlink:href='%23a' transform='rotate(216 450 300)'/%3e%3cuse xlink:href='%23a' transform='rotate(288 450 300)'/%3e%3c/svg%3e)