Identifying design problems in the source code

Sousa, Leonardo; Oliveira, Anderson; Oizumi, Willian; Barbosa, Simone Diniz Junqueira; Garcia, Alessandro; Lee, Jaejoon; Kalinowski, Marcos; Mello, Rafael de; Fonseca, Baldoíno; Oliveira, Roberto; Lucena, Carlos José Pereira de; Paes, Rodrigo

doi:10.1145/3180155.3180239

Cited by 39 publications

(35 citation statements)

References 54 publications

(76 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In the studies of Fontana et al [66], [67], they described three representative architecture smells and presented a tool, Arcan, to support their detection. Instead of investigating detection techniques, Sousa et al's work [68] focused on how developers actually proceed to identify design problems by using the design problem symptoms.…”

Section: Related Workmentioning

confidence: 99%

Architecture Anti-Patterns: Automatically Detectable Violations of Design Principles

Cai

Kazman

et al. 2021

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

In large-scale software systems, error-prone or change-prone files rarely stand alone. They are typically architecturally connected and their connections usually exhibit architecture problems causing the propagation of error-proneness or change-proneness. In this paper, we propose and empirically validate a suite of architecture anti-patterns that occur in all large-scale software systems and are involved in high maintenance costs. We define these architecture anti-patterns based on fundamental design principles and Baldwin and Clark's design rule theory. We can automatically detect these anti-patterns by analyzing a project's structural relationships and revision history. Through our analyses of 19 large-scale software projects, we demonstrate that these architecture anti-patterns have significant impact on files' bug-proneness and change-proneness. In particular, we show that 1) files involved in these architecture anti-patterns are more error-prone and change-prone; 2) the more anti-patterns a file is involved in, the more error-prone and change-prone it is; and 3) while all of our defined architecture anti-patterns contribute to file's error-proneness and change-proneness, Unstable Interface and Crossing contribute the most by far.

show abstract

Section: Related Workmentioning

confidence: 99%

Architecture Anti-Patterns: Automatically Detectable Violations of Design Principles

Cai

Kazman

et al. 2021

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

show abstract

“…The harmful effects of design problems have led to the discontinuance or reengineering of some software systems 27,28 . Silva et al, 29 Xiao et al, 30 and Sousa et al 31 show that design issues are one of the most common categories of technical issues that lead to the failure of software systems. Therefore, given the negative effects of design problems, it is recommended that developers should remove them from software systems as early as possible 32,33 in the software development process.…”

Section: Background and Related Workmentioning

confidence: 99%

A critical assessment of the design issues in e‐commerce systems development

Ehikioya

Guillemot

2020

Engineering Reports

View full text Add to dashboard Cite

Designers of electronic commerce (e-commerce) transaction system applications face many challenges; some are old while others are emerging because of the emerging nature of the e-commerce domain itself. This article examines the critical design challenges at different stages of the design process of e-commerce applications. The high-level designs have a large number of new issues specific to Web applications. Among them, the security and networking problems are the most determinant for the success of the applications. At the detailed design level, the languages and the user interface are major concerns. The user interface, specific to the Web, forces designers to redefine the traditional concept of the end user for the more appropriate customer-centric concept. This is necessary to address the needs of consumers and for the survival of e-commerce businesses.In addition, we also examine issues bothering the development team and the e-commerce environment. Designers experienced in non-Web applications can be more successful at developing e-commerce applications if they address the issues we identified in this article in a creative way. K E Y W O R D Sdesign issues, e-commerce, e-commerce systems/application INTRODUCTIONThe concept of electronic commerce (e-commerce) has crystallized into a fairly well understood concept 1-7 ; its popularity and fast paced acceptance as an alternative to the brick and mortar market economic model 3,8 tend to undermine a clear understanding, and clear exposition of the characteristics, of e-commerce. Most adherents of e-commerce often focus only on the exchange of value end product 6,7 without paying close attention to, or knowing the intricacies of, the underlying transaction itself. 1,4,[9][10][11][12][13] Therefore, a proper characterization of e-commerce applications is fundamental. We focus on the design challenges in e-commerce transactions in a typical business-to-consumer (B2C) e-commerce domain, which is more popular, more widely patronized by users, and attracts a higher volume of e-commerce transactions. The B2C e-commerce includes retail transactions of products or services from businesses to individual shoppers (ie, businesses sell products or services to individual consumers). Thus, the seller is a business organization whereas the buyer is a consumer.

show abstract

“…Other studies have focused on investigating the identification of design problems from the perspective of developers as well [47,48]. Sousa et al [47] conducted a qualitative study to investigate how developers identify design problems in practice.…”

Section: Other Approaches To Identify Design Problemsmentioning

confidence: 99%

“…They also observed that developers often search for multiple symptoms of design problems, such as code smells, during the identification. In a subsequent study, Sousa et al [48] proposed a theory to describe how the identification of design problems happens in practice. Their theory explains factors that influence developers during the identification of design problems.…”

Section: Other Approaches To Identify Design Problemsmentioning

confidence: 99%

On the identification of design problems in stinky code: experiences and tool support

et al. 2018

Self Cite

View full text Add to dashboard Cite

Background: Developers often have to locate design problems in the source code. Several types of design problems may manifest as code smells in the program. A code smell is a source code structure that may reveal a partial hint about the manifestation of a design problem. Recent studies suggest that developers should ignore smells occurring in isolation in a program location. Instead, they should focus on analyzing stinkier code, i.e., program locations-e.g., a class or a hierarchy-affected by multiple smells. There is evidence that the stinkier a program location is, the more likely it contains a design problem. However, there is no empirical evidence on whether developers can effectively identify a design problem in stinkier code. Developers may struggle to make an analysis of inter-related smells affecting the same program location. Besides that, the analysis of stinkier code may require proper tool support due to its analysis complexity. However, there is little knowledge on what are the requirements for a tool that helps developers in revealing stinkier program locations. As a result, developers may not be able to identify design problems due to tool issues. Method: To address this matter, we aimed at achieving three goals. In the first case, we proposed Organic-a tool supporting the analysis of stinky code. In the second case, we applied a mixed-method approach to analyze if and how developers can effectively find design problems when reflecting upon stinky code-i.e., a program location affected by multiple smells. We conducted a study with 11 software professionals. Finally, in the third case, we aimed at understanding if Organic could be used by developers to identify design problems. To achieve this goal, we used a method from the Semiotic Engineering theory. This method enabled us to evaluate what are the tool issues that may hinder the identification of design problems in stinky code. Result: Our study revealed that only 36.36% of the developers found more design problems when explicitly reasoning about multiple smells as compared to single smells. Moreover, 63.63% of the developers reported much lesser false positives when using the first approach as compared to the latter. The second study, in its turn, showed that most developers may be unable to identify design problems in stinky code without proper tool support. Conclusion: Our experiences, in particular the second study, helped us to refine the features of Organic for better supporting developers in reflecting upon stinkier code. For example, analyses of stinky code scattered in class hierarchies or packages is often difficult, time-consuming, and requires proper visualization support. Moreover, without effective support, it remains time-consuming to discard stinky program locations that do not represent design problems.

show abstract

Identifying design problems in the source code

Cited by 39 publications

References 54 publications

Architecture Anti-Patterns: Automatically Detectable Violations of Design Principles

Architecture Anti-Patterns: Automatically Detectable Violations of Design Principles

A critical assessment of the design issues in e‐commerce systems development

On the identification of design problems in stinky code: experiences and tool support

Contact Info

Product

Resources

About