Summary Software evolution is the process of adapting, maintaining, and updating a software system. This process concentrates the most significant part of the software costs. Many works have studied software evolution and found relevant insights, such as Lehman's laws. However, there is a gap in how software systems evolve from an internal dimensions point of view. For instance, the literature has indicated how systems grow, for example, linearly, sub‐linearly, super‐linearly, or following the Pareto distribution. However, a well‐defined pattern of how this phenomenon occurs has not been established. This work aims to define a novel method to analyze and predict software evolution. We based our strategy on time series analysis, linear regression techniques, and trend tests. In this study, we applied the proposed model to investigate how the internal structure of object‐oriented software systems evolves in terms of four dimensions: coupling, inheritance hierarchy, cohesion, and class size. Applying the proposed method, we identify the functions that better explain how the analyzed dimensions evolve. Besides, we investigate how the relationship between dimension metrics behave over the systems' evolution and the set of classes existing in the systems that affect the evolution of these dimensions. We mined and analyzed data from 46 Java‐based open‐source projects. We used eight software metrics regarding the dimensions analyzed in this study. The main results of this study reveal ten software evolution properties, among them: coupling, cohesion, and inheritance evolve linearly; a relevant percentage of classes contributes to coupling and size evolution; a small percentage of classes contributes to cohesion evolution; there is no relation between the software internal dimensions' evolution. The results also indicate that our method can accurately predict how the software system will evolve in short‐term and long‐term predictions.

Software evolution is the process of developing, maintaining, and updating software systems. It is known that the software systems tend to increase their complexity and size over their evolution to meet the demands required by the users. Due to this fact, researchers have increasingly carried out studies on software evolution to understand the systems' evolution pattern and propose techniques to overcome inherent problems in software evolution. Many of these works collect data but do not make them publicly available. Many datasets on software evolution are outdated, and/or are small, and some of them do not provide time series from software metrics. We propose an extensive software evolution dataset with temporal information about open-source Java systems. To build this dataset, we proposed a methodology of four steps: selecting the systems using a criterion, extracting and measuring their releases, and generating their time series. Our dataset contains time series of 46 software metrics extracted from 46 open-source Java systems, and we make it publicly available.

Summary A design pattern is a general reusable solution to commonly recurring problems in software projects. Bad smells are symptoms existing in the source code that possibly indicate the presence of a structural problem that requires code refactoring. Although design pattern and bad smells be different concepts, literature has shown that they may be related and cooccur during the evolution of a software system. This paper presents an empirical study that investigates cooccurrences of design patterns and bad smells as well as identifies the main factors that contribute to the emergence of the relationship between them. We carried out a case study with five Java systems to: (1) investigate if the use of design pattern reduces bad smell occurrence, (2) identify cooccurrences of design patterns and bad smells, and (3) identify situations that contribute for the cooccurrence emergence. As the main result, we found that the application of design pattern not necessarily avoid bad smell occurrences. The results also show that some design patterns such as composite, factory method, and singleton, are intrinsically modular and might be useful in creating high‐quality systems. However, other design patterns such as adapter‐command, proxy, and state‐strategy, have presented high cooccurrence frequency with bad smells; therefore, they require attention in their implementation. Finally, via manual inspection in the components with cooccurrence, we found that the identified cooccurrences appeared due to poor planning and inadequate application of design patterns.

Bad smells are symptoms of problems in the source code of software systems. They may harm the maintenance and evolution of systems on different levels. Thus, detecting smells is essential in order to support the software quality improvement. Since even small systems may contain several bad smell instances, and considering that developers have to prioritize their elimination, its automated detection is a necessary support for developers. Regarding that, detection strategies have been proposed to formalize rules to detect specific bad smells, such as Large Class and Feature Envy. Several tools like JDeodorant and JSpIRIT implement these strategies but, in general, they do not provide full customization of the formal rules that define a detection strategy. In this paper, we propose FindSmells, a tool for detecting bad smells in software systems through software metrics and their thresholds. With FindSmells, the user can compose and manage different strategies, which run without source code analysis. We also provide a running example of the tool. Video: https://youtu.be/LtomN93y6gg.

Recent results have shown how to do graph-coloring-based register allocation in a way that decouples spilling from register assignment. This decoupled approach has the main advantage of simplifying the implementation of register allocators. However, the decoupled model, as described in previous works, faces many problems when dealing with register aliasing, a phenomenon typical in architectures usually seen in embedded systems, such as ARM. In this paper we introduce the semi-elementary form, a program representation that brings decoupled register allocation to architectures with register aliasing. The semi-elementary form is much smaller than program representations used by previous decoupled solutions; thus, leading to register allocators that perform better in terms of time and space. Furthermore, this representation reduces the number of copies that traditional allocators insert into assembly programs. We have empirically validated our results by showing how our representation improves two well known graph coloring based allocators, namely the Iterated Register Coalescer (IRC), and Bouchez et al.'s brute force (BF) method, both augmented with Smith et al. extensions to handle aliasing. Running our techniques on SPEC CPU 2000, we have reduced the number of nodes in the interference graphs by a factor of 4 to 5; hence, speeding-up allocation time by a factor of 3 to 5. Additionally the semi-elementary form reduces by 8% the number of copies that IRC leaves uncoalesced.

This paper presents Arcademis, a Java-based framework for communication middleware development. Arcademis consists of a set of abstract classes, interfaces and concrete components that define the general architecture of middleware systems. Its main objective is to support the implementation of non-monolithic and easily configurable middleware platforms. Arcademis can be used by middleware developers to deploy systems that meet the requirements of a particular network or technology. Instances of Arcademis can also be customized by distributed systems engineers to meet the requirements of a particular application. For example, new transport protocols, connection management policies, authentication algorithms or invocation semantics can be easily configured in middleware platforms derived from Arcademis. In order to illustrate the use of the framework, the paper describes the RME system, a middleware derived from Arcademis that adds a remote method invocation service to the CLDC configuration of Java 2 Micro Edition (J2ME). Copyright © 2006 John Wiley & Sons, Ltd.