A heuristic-based approach to code-smell detection

Encapsulation and data hiding are central tenets of the object oriented paradigm. Deciding what data and behaviour to form into a class and where to draw the line between its public and private details can make the difference between a class that is an understandable, flexible and reusable abstraction and one which is not. This decision is a difficult one and may easily result in poor encapsulation which can then have serious implications for a number of system qualities. It is often hard to identify such encapsulation problems within large software systems until they cause a maintenance problem (which is usually too late) and attempting to perform such analysis manually can also be tedious and error prone. Two of the common encapsulation problems that can arise as a consequence of this decomposition process are data classes and god classes. Typically, these two problems occur together – data classes are lacking in functionality that has typically been sucked into an over-complicated and domineering god class. This paper describes the architecture of a tool which automatically detects data and god classes that has been developed as a plug-in for the Eclipse IDE. The technique has been evaluated in a controlled study on two large open source systems which compare the tool results to similar work by Marinescu, who employs a metrics-based approach to detecting such features. The study provides some valuable insights into the strengths and weaknesses of the two approache

Software Product Line Reengineering: A Case Study on the Geographic Domain

The growing adoption of software product lines (SPL) represents perhaps a paradigm shift in software development aiming at improving cost, quality, time to market, and developer productivity. While the underlying concepts are straightforward enough building a family of related products or systems by planned and careful reuse of a base of generalized software development assets the problems can be in the details, as successful product line practice involves domain understanding, technology selection, and so forth. Today, there is an important increment on reporting experiences and lessons about SPL development by capturing aspects that have been gathered during daily practice. Following this line, in this paper we start from our experiences of developing a software product line on the Marine Ecology domain highlighting our reasons for reengineering a previous SPL. Then, we explain step-bystep reengineering activities in terms of motivation, solutions, and lessons learned, which summarize strengths and limitations of the applied practices. Differently from other cases, here we take advantage of using domain standards as well as open source implementations within the geographic domain.Facultad de Informátic

Software Product Line Reengineering: A Case Study on the Geographic Domain

The growing adoption of software product lines (SPL) represents perhaps a paradigm shift in software development aiming at improving cost, quality, time to market, and developer productivity. While the underlying concepts are straightforward enough building a family of related products or systems by planned and careful reuse of a base of generalized software development assets the problems can be in the details, as successful product line practice involves domain understanding, technology selection, and so forth. Today, there is an important increment on reporting experiences and lessons about SPL development by capturing aspects that have been gathered during daily practice. Following this line, in this paper we start from our experiences of developing a software product line on the Marine Ecology domain highlighting our reasons for reengineering a previous SPL. Then, we explain step-bystep reengineering activities in terms of motivation, solutions, and lessons learned, which summarize strengths and limitations of the applied practices. Differently from other cases, here we take advantage of using domain standards as well as open source implementations within the geographic domain.Facultad de Informátic

Software Product Line Reengineering: A Case Study on the Geographic Domain

The growing adoption of software product lines (SPL) represents perhaps a paradigm shift in software development aiming at improving cost, quality, time to market, and developer productivity. While the underlying concepts are straightforward enough building a family of related products or systems by planned and careful reuse of a base of generalized software development assets the problems can be in the details, as successful product line practice involves domain understanding, technology selection, and so forth. Today, there is an important increment on reporting experiences and lessons about SPL development by capturing aspects that have been gathered during daily practice. Following this line, in this paper we start from our experiences of developing a software product line on the Marine Ecology domain highlighting our reasons for reengineering a previous SPL. Then, we explain step-bystep reengineering activities in terms of motivation, solutions, and lessons learned, which summarize strengths and limitations of the applied practices. Differently from other cases, here we take advantage of using domain standards as well as open source implementations within the geographic domain.Fil: Buccella, Agustina. Universidad Nacional del Comahue. Facultad de Informática. Departamento Ingeniería de Sistemas; Argentina. Consejo Nacional de Investigaciones Científicas y Técnicas; ArgentinaFil: Cechich, Susana Alejandra. Universidad Nacional del Comahue. Facultad de Informática. Departamento Ingeniería de Sistemas; ArgentinaFil: Pol'la, Matías. Universidad Nacional del Comahue. Facultad de Informática. Departamento Ingeniería de Sistemas; ArgentinaFil: Arias, Maximiliano Andrés. Universidad Nacional del Comahue. Facultad de Informática. Departamento Ingeniería de Sistemas; Argentina. Consejo Nacional de Investigaciones Científicas y Técnicas; Argentin

An Exploratory Study on How Software Reuse is Discussed in Stack Overflow

Software reuse is an important and crucial quality attribute in modern software engineering, where almost all software projects, open source or commercial, no matter small or ultra-large, source code reuse in one way or another. Although software reuse has experienced an increased adoption throughout the years with the exponentially growing number of available third-party libraries, frameworks and APIs, little knowledge exists to investigate what aspects of code reuse developers discuss. In this study, we look into bridging this gap by examining Stack Overflow to understand the challenges developers encounter when trying to reuse code. Using the Stack Overflow tags “code-reuse” and “reusability”, we extracted and analyzed 1,409 posts, composed of questions and answers. Our findings indicate that despite being popular, reuse questions take relatively longer than typical other questions to receive an accepted answer. From these posts, we identified 9 categories that group the different ways developers discuss software reuse. We found Java and ASP.NET MVC to be the most discussed programming language and framework, respectively. Based on the programming languages and frameworks mentioned in the posts, we noted that Web software development is the most frequently targeted environment. This study can be utilized to further analyze aspects about software reuse and develop guidelines to be practiced in industry and taught when forming new developer