Search

In this paper, we share our experience in designing and running a project-based exam for a Software Engineering course at the undergraduate level. We underline the teaching objectives and content of the course which aim to prepare students for the industrial environment, e.g., various design perspectives on the project, software quality assurance and evaluation, tools for development and software quality assessment, project management and team work. We present our project-based exam and summarize hints on its design, organization, and evaluation. Project examples are also introduced.

Technical debt indexes are metrics for assessing the quality of a software system. Both academic and commercial tools have begun to provide computations of such indexes based on design violations and smells (e.g., cycles among system elements). When computing a debt index for a given project, a common use case is that engineers look at the index values for spotting design issues that negatively affect system evolution and quality. In this context, those smells being critical for the system architecture should be promptly identified soastoe valuate proper remediation actions. However, the interpretation of an index value in terms of problematic smells is usually a manual and labor-intensive task for engineers. To help with this task, we propose a tool called Sen4Smells that performs an automated sensitivity analysis for a given debt index based on the evolution of both the index values and the corresponding smells across (past) system versions. The Sen4Smells output is a ranking of smells that, due to their variations or instability, are major contributors to the debt index, and thus, can impact on architecture quality. Sen4Smells is designed as a pipeline that combines information from existing tools for smell detection, predefined d ebt i ndex f ormulas, and the Sobol method for sensitivity analysis. As a demonstration of the tool functionality, we briefly present implementations for the Arcan and Sonargraph tools with their respective debt indexes.

Design patterns are recommended solutions for typical software design problems, with an extensively studied and documented impact on various quality factors. Flaws in design at a higher levels of abstraction are manifested in architectural smells. Some of those smells, similarly to code smells, can reduce the expected advantages of design patterns or even prevent their proper implementation. In this paper we study if and how design patterns and architectural smells are related, and how this knowledge could be exploited in practice. We present an empirical study with an analysis of 16 design patterns and 3 architectural smells in 60 open source Java systems. We analyze their diffuseness and correlation, and we extract association rules that describe their presence and dependencies. We demonstrate that there exist relationships between architectural smells and design patterns, both at the class and package levels. Some smells appear falsely positive, as they result from conscious decisions made by programmers, while the application of some patterns can be a cause of certain smells. Our results provide evidence that design patterns and architectural smells are related and affect each other. With knowledge about the relationships, programmers can avoid the side effects of applying some design patterns.

Today, software development is characterized by keywords such as collaborative, teamwork, distributed, agile, dynamic, qualitative and tool-supported among many others. In this paper, we present our experience in teaching three software development tools often used in industry in a software engineering course for undergraduate students: GitHub, SonarQube, and Microsoft Project. The main reasons behind the use of these tools during the development of a software project were: (1) students become familiar with examples of tools adopted in industry and academia, (2) students are enabled to collaborate in teams for the achievement of a common goal, and (3) students become aware of the management tasks needed by a project developed in teams. We exploited these tools in the software engineering course in the last three academic years. The students feedback on using these tools gathered through a questionnaire was positive. Students were enthusiastic in learning about new tools and their support for software development and management. In this paper we summarize the students feedback during three academic years and the lessons we have learned from their feedback.

Bad design decisions in software development can progressively affect the internal quality of a software system, causing architecture erosion. Such bad decisions are called Architectural Smells (AS) and should be detected as soon as possible, because their presence heavily hinders the maintainability and evolvability of the software. Many detection approaches rely on software analysis techniques which inspect the structure of the system under analysis and check with rules the presence of AS. However, some recent approaches leverage natural language processing techniques to recover semantic information from the system. This kind of information is useful to detect AS which violate "conceptual" design principles, such as the separation of concerns one. In this research study, I propose two detection strategies for AS detection based on code2vec, a neural model which is able to predict semantic properties of given snippets of code.

Architectural smells represent symptoms of problems at architectural level that can negatively impact internal software qualities and lead to architectural debt. Detecting architectural smells and identifying the most critical ones is the key to prioritize refactoring efforts and prevent software architecture erosion. In this paper we focus our attention on three architectural smells based on dependency issues, called Cyclic Dependency, Unstable Dependency, and Hub-Like Dependency. Moreover, we evaluate the PageRank and Criticality of these smells through the analysis of six projects. PageRank is a measure that estimates whether an architectural smell is located in an important part of the project, where the importance is evaluated according to how many parts of a project depend on the one involved in the architectural smell. We describe a case study on the analysis of the possible relation existing between the PageRank and Criticality of the smells. The results show how the two measures can be both used to locate the architectural smells that need particular inspections and attention.

With the introduction of microservice architecture, many investigate how to migrate their legacy systems into this architectural paradigm. The migration process requires the recovery of the project architecture to be migrated together with the knowledge necessary to understand how to decompose the code and obtain new microservices. At the moment, this process is realized mostly manually. This paper introduces an approach to identify candidate microservices in monolithic Java projects, implemented in a tool named Arcan and the validation of the approach in an industrial setting. The approach involves static analysis of the system architecture, architectural smell detection and topic detection, a text mining method used here to model software domains starting from code analysis. We report the feedbacks we get from an experienced industrial developer who carried out the migration described in the case study. From this collaboration with industry we collected useful information to enhance the approach, improve the tool and replicate the study.

Different indexes have been proposed to evaluate software quality and technical debt. Usually these indexes take into account different code level issues and several metrics, well known software metrics or new ones defined ad hoc for a specific purpose. In this paper we propose and define a new index, more oriented to the evaluation of architectural violations. We describe in detail the index, called Architectural Debt Index, that we integrated in a tool developed for architectural smell detection. The index is based on the detection of architectural smells, their criticality and their history. Currently only dependency architectural smells have been considered, but other architectural debt indicators can be considered and integrated in the index computation.