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

State of Refactoring Adoption: Towards Better Understanding Developer Perception of Refactoring

Context: Refactoring is the art of improving the structural design of a software system without altering its external behavior. Today, refactoring has become a well-established and disciplined software engineering practice that has attracted a significant amount of research presuming that refactoring is primarily motivated by the need to improve system structures. However, recent studies have shown that developers may incorporate refactoring strategies in other development-related activities that go beyond improving the design especially with the emerging challenges in contemporary software engineering. Unfortunately, these studies are limited to developer interviews and a reduced set of projects. Objective: We aim at exploring how developers document their refactoring activities during the software life cycle. We call such activity Self-Affirmed Refactoring (SAR), which is an indication of the developer-related refactoring events in the commit messages. After that, we propose an approach to identify whether a commit describes developer-related refactoring events, to classify them according to the refactoring common quality improvement categories. To complement this goal, we aim to reveal insights into how reviewers develop a decision about accepting or rejecting a submitted refactoring request, what makes such review challenging, and how to the efficiency of refactoring code review. Method: Our empirically driven study follows a mixture of qualitative and quantitative methods. We text mine refactoring-related documentation, then we develop a refactoring taxonomy, and automatically classify a large set of commits containing refactoring activities, and identify, among the various quality models presented in the literature, the ones that are more in-line with the developer\u27s vision of quality optimization, when they explicitly mention that they are refactoring to improve them to obtain an enhanced understanding of the motivation behind refactoring. After that, we performed an industrial case study with professional developers at Xerox to study the motivations, documentation practices, challenges, verification, and implications of refactoring activities during code review. Result: We introduced SAR taxonomy on how developers document their refactoring strategies in commit messages and proposed a SAR model to automate the detection of refactoring. Our survey with code reviewers has revealed several difficulties related to understanding the refactoring intent and implications on the functional and non-functional aspects of the software. Conclusion: Our SAR taxonomy and model, can work in conjunction with refactoring detectors, to report any early inconsistency between refactoring types and their documentation and can serve as a solid background for various empirical investigations. In light of our findings of the industrial case study, we recommended a procedure to properly document refactoring activities, as part of our survey feedback

A coalgebraic semantic framework for reasoning about UML: sequence diagrams

If, as a well-known aphorism states, modelling is for reasoning , this paper is an attempt to define and apply a formal semantics to UML sequence diagrams in order to enable rigourous reasoning about them. Actually, model transfor- mation plays a fundamental role in the process of software development, in general, and in model driven engineering in particular. Being a de facto standard in this area, UML is no exception, even if the number and diversity of diagrams expressing UML models makes it difficult to base its semantics on a single framework. This paper builds on previous attempts to base UML semantics in a coalgebraic setting and illustrates the application of the proposed framework to reason about composition and refactoring of sequence diagrams.(undefined

Lab Package Development and Evaluation for the Course “Software Engineering”

Antud töös koostatakse üliõpilastele mõeldud praktikumide pakett. Paketi eesmärgiks on\n\rõpetada üliõpilased analüüsima ja arendama tarkvara järgides test-juhitud arendusprotsessi\n\r(TDD). TDD on tänapäeval üks enim kasutatud metoodikaid ja seda saab lihtsalt kasutada\n\rhariduslikus kontekstis. See on mõeldud bakalaureusetaseme tudengitele, kellel puudub\n\rprogrammeerimises tugev baas. Praktikumipakett sisaldab praktikumideks\n\rvajalikku dokumentide komplekti ja omab kindlat struktuuri. Dokumendid on juhendid, mis\n\rvõimaldavad arendada konkreetseid oskusi nagu eelduste kogumine, testimine ja\n\rrefaktoreerimine. Vastavad oskused omandatakse järgides rangelt TDD metoodikat. Seega\n\rüliõpilased peavad aru saama kõigist TDD detailidest. Antud töös on praktikumipakett\n\rjagatud kaheks osaks. Esimene osa arendab analüütilisi oskusi ja teine osa koodi kirjutamist.\n\rEsimeses osas tutvustatakse üliõpilastele TDD teoreetilist tausta ja nad õpivad TDD\n\rkasutamist spetsiaalse väikese rakenduse arendamise kaudu. Üliõpilased õpivad eeldusi\n\rlooma, domeeni mudelit arendama ja eelduste põhjal loodud näidiseid arendama. Mängust\n\rja kõikidest näidistest valmistatakse „koodi skelett“, mille peale saavad õpilased ehitada\n\rrakenduse. Teises osas tegelevad üliõpilased peamiselt koodi kirjutamisega ja järgivad TDD\n\rahelat, et mõista kõiki TDD üksikasju. Kõigepealt õpivad üliõpilased looma ja arendama\n\rtestjuhtumeid, mis kõik põhinevad näidetel. Seejärel alustatakse koodi kirjutamisega ja\n\rliigutakse ühelt testjuhtumilt teisele. Samal ajal õpivad nad ka refaktoreerimise tehnikaid.\n\rPraktikumipaketti hinnati ülikooli õppejõudude poolt. Vastused küsimustikule on esitatud\n\rtöös. Peamiselt olid vastajateks õppejõud, kellel on laialdane kogemus OOP õpetamises.\n\rTulemused on küllaltki huvitavad. Praktikumipaketi struktuur tundus mõistetav ja selge.\n\rHindamiskava oli piisavalt lihtne ja õppejõud nõustusid, et praktikumipakett arendab laia\n\rvalikut oskusi, mis on vajalikud TDD rakendamiseks. Oluline on veel edasi uurida, kuidas\n\rsaab viimistleda TDD-d hariduslikel eesmärkidel kasutamiseks.In this thesis, a lab package will be delivered for undergraduate students. The aim of the\n\rpackage is to teach students how to analyze and develop software following Test-Driven\n\rDevelopment (TDD) process. TDD is one of the most used methodologies nowadays. It can\n\rbe easily used in the educational context to develop programming skills. The lab package is\n\raimed at bachelors’ students who don’t have a solid experience in programming. The lab\n\rpackage contains a set of necessary documents and has a certain structure. The documents\n\rare usually guidelines, which support the development of particular skills such as\n\rrequirements’ gathering, testing and refactoring. Those skills should be learned in a certain\n\rworkflow so that students will follow TDD methodology rigorously. Hence, students need\n\rto understand all details of TDD. In my thesis, the lab package is divided into two parts. The\n\rfirst part develops analytical skills and the second part develops coding skills. In the first\n\rpart, students are introduced to the theoretical background of TDD. Then, they see how TDD\n\ris used in practice by developing a special small app. During the first part, students learn\n\rhow to generate requirements, develop domain model, develop examples based on the\n\rrequirements. Examples are particular test cases for each requirement. There is a prepared “\n\rcode skeleton” of the game and all examples that the students can build upon. In the second\n\rpart, students do mainly coding. The main feature is that students follow TDD circle. I want\n\rstudents to understand all specifics of TDD. In the beginning, students will learn how to\n\rgenerate and develop test cases. All test cases are based on examples. Then, they start coding\n\rand move on from one test case to another. While coding, they also learn refactoring\n\rtechniques. The lab package was evaluated by university professors. The results are provided\n\rin the form of answers to questionnaire. The main audience are university professors who\n\rhave an extensive experience in teaching OOP. The results are quite interesting. On the one\n\rhand, the structure of the lab package was understandable and clear, the grading scheme was\n\rtransparent and simple. The professors also agreed that the lab package develops a wide\n\rrange of skills. Those skills are necessary for TDD. There is some research to be conducted\n\rto elaborate how TDD can be applied for educational purposes

State of Refactoring Adoption: Better Understanding Developer Perception of Refactoring

We aim to explore how developers document their refactoring activities during the software life cycle. We call such activity Self-Affirmed Refactoring (SAR), which indicates developers' documentation of their refactoring activities. SAR is crucial in understanding various aspects of refactoring, including the motivation, procedure, and consequences of the performed code change. After that, we propose an approach to identify whether a commit describes developer-related refactoring events to classify them according to the refactoring common quality improvement categories. To complement this goal, we aim to reveal insights into how reviewers decide to accept or reject a submitted refactoring request and what makes such a review challenging.Our SAR taxonomy and model can work with refactoring detectors to report any early inconsistency between refactoring types and their documentation. They can serve as a solid background for various empirical investigations. Our survey with code reviewers has revealed several difficulties related to understanding the refactoring intent and implications on the functional and non-functional aspects of the software. In light of our findings from the industrial case study, we recommended a procedure to properly document refactoring activities, as part of our survey feedback.Comment: arXiv admin note: text overlap with arXiv:2010.13890, arXiv:2102.05201, arXiv:2009.0927

Experiences In Migrating An Industrial Application To Aspects

Aspect-Oriented Software Development (AOSD) is a paradigm aiming to solve problems of object-oriented programming (OOP). With normal OOP it’s often unlikely to accomplish fine system modularity due to crosscutting concerns being scattered and tangled throughout the system. AOSD resolves this problem by its capability to crosscut the regular code and as a consequence transfer the crosscutting concerns to a single model called aspect. This thesis describes an experiment on industrial application wherein the effectiveness of aspect-oriented techniques is explained in migration the OOP application into aspects. The experiment goals at first to identify the crosscutting concerns in source code of the industrial application and transform these concerns to a functionally equivalent aspect-oriented version. In addition to presenting experiences gained through the experiment, the thesis aims to provide practical guidance of aspect solutions in a real application

Realizing Change-Driven Consistency for Component Code, Architectural Models, and Contracts in Vitruvius

During the development of component-based software systems, it is often impractical or even impossible to include all development information into the source code. Instead, specialized languages are used to describe components and systems on different levels of abstraction or from different viewpoints: Component-based architecture models and contracts, for example, can be used to describe the system on a high level of abstraction, and to formally specify component constraints. Since models, contracts, and code contain redundant information, inconsistencies can occur if they are modified independently. Keeping this information consistent manually can require considerable effort, and can lead to costly errors, for example, when security-relevant components are verified against inconsistent contracts. In this technical report, we present details on realizing an approach for keeping component-based architecture models and contracts specified in the Java Modeling Language (JML) consistent with Java source code. We use change-driven incremental transformations and the Vitruvius framework to automate the consistency preservation where this is possible. Using two case studies, we demonstrate how to detect and propagate changes and refactoring operations to keep models and contracts consistent with the source code

Technical and Economical Model (Workpackage 2.1)

The objective of this workpackage is to define a model for (i) assessing the effort of software modification, (ii) identifying healing actions following practices from the Squale quality model defined in the previous workpackage (WP1.3). It defines the input for the next workpackage which is about planning actions once their effort is characterized. The key constraints of this work are: • The remediation effort should be expressed in the context of a quality model. It should act as a quantification of the work to obtain a better (or good) quality of the entity under analysis. • The remediation should be based on practices as described in the workpackage 1.3