[Context]. Microservice architectures have become a dominant paradigm for modernizing monolithic systems. However, identifying appropriate services remains a challenging and largely manual task. Existing decomposition approaches are predominantly code-centric, limiting their applicability in early design stages where only textual requirements are available. [Problem]. Despite recent advances in Large Language Models (LLMs), there is still limited empirical evidence regarding their ability to synthesize complete microservice architectures directly from natural-language requirements, including both service definitions and inter-service interactions. [Goal]. This study investigates whether an LLM can bridge the gap between requirements engineering and architectural design by generating microservice architectures solely from textual requirements, and evaluates the structural agreement and perceived quality of the generated solutions. [Method]. We conduct a mixed-method study using the OpenAI o3 model under zero-shot (ZS) and few-shot (FS) prompting strategies across two systems (Bookstore and PetClinic), with one execution per system and prompting condition. Generated architectures are evaluated through (i) quantitative comparison with implemented reference architectures using precision, recall, and F1-score for service identification and communication recovery, and (ii) a blinded expert assessment of correctness, completeness, modularity, and plausibility, supplemented by a structured descriptive synthesis of open-ended feedback. [Results]. The findings indicate that OpenAI o3 can identify services from requirements, achieving higher agreement with the references under FS prompting (F1 ≈ 0.79 for ZS and ≈ 0.97 for FS). Communication recovery is more challenging, with ZS producing overly dense architectures characterized by high recall but low precision (F1 ≈ 0.61). FS prompting improves structural agreement and perceived architectural quality, achieving F1 ≈ 0.82 for communication recovery while reducing unsupported dependencies. Expert evaluation corroborates these findings, indicating that FS-generated architectures are consistently perceived as more modular, coherent, and plausible than ZS outputs. [Conclusion]. Within the evaluated scope, OpenAI o3 shows potential to support requirements-driven architectural synthesis, particularly when guided by minimal exemplar-based prompting. The results should be interpreted as model- and context-specific evidence from two relatively small systems and a single execution per condition, rather than as model-independent proof of effectiveness.
Context: The rapid expansion of Artificial Intelligence (AI), particularly Generative AI, has intensified ethical challenges in computing education, exposing tensions between technical training and ethical responsibility. While ethical principles are widely endorsed in international AI governance frameworks, their effective integration into computing curricula remains uneven, especially in Global South contexts. Goal: This study investigates the ethical literacy of undergraduate computing students and examines how educators perceive their role, institutional constraints, and pedagogical challenges in fostering ethics education under the pressure of Generative AI. Method: We adopted a sequential explanatory mixed-methods design. First, a survey with 56 undergraduate computing students at the University of Brasília (UnB) examined familiarity with 21 AI ethical principles, perceived relevance, and curricular exposure. Second, semi-structured interviews with 31 computing educators explored how ethics integration has evolved, the impact of Generative AI on teaching practices, perceived student ethical maturity at graduation, and structural barriers to effective ethics education. Quantitative data were analyzed descriptively, and qualitative data were examined through iterative coding procedures. Results: Students demonstrated strong agreement regarding the importance of ethical principles in computing and reported high self-perceived preparedness to assess social impacts. However, a clear gap emerged between perceived importance and formal curricular exposure. Educators, in turn, identified Generative AI as an operational accelerator that intensified assessment reconfiguration, academic integrity concerns, and accountability tensions. Interviews also revealed a dominant perception of low ethical maturity at the transition to professional practice, alongside systemic barriers including curricular overload, limited faculty preparation, and institutional governance gaps. Conclusions: The findings suggest the existence of a structural ethical literacy gap in computing education, reinforced by curricular fragmentation and insufficient institutional support, and amplified by the rapid integration of Generative AI. Addressing this gap requires coordinated curricular reform, faculty development, and institutional governance strategies that integrate ethical reasoning as a core technical competency rather than a peripheral concern. This competency is particularly important for future software engineers who must evaluate AI-generated artifacts, assume accountability for AI-supported engineering decisions, and negotiate socio-technical trade-offs throughout the software lifecycle.
Semantic conflicts occur when a developer introduces changes to a codebase that unintentionally affect the behavior of changes integrated in parallel by other developers. Since merge tools used in practice cannot detect this type of conflict, complementary tools have been proposed, such as SAM (SemAntic Merge), based on the SMAT approach and relies on the generation and execution of unit tests in Java. Despite showing good conflict detection capabilities, SAM presents a high rate of false negatives (existing conflicts not signaled by it). Part of this problem is due to the natural limitations of unit test generation tools, specifically Randoop and EvoSuite. To understand if these limitations can be overcome by large language models (LLMs), this work proposes, and integrates into SMAT, LUCIA (LLM-based Unit-tests for Conflict Identification & Analysis), a new test generation tool based on the Ollama framework to interface with various local LLMs, including the Llama, Gemma, DeepSeek, and Qwen families. We then explore these models' capability to generate tests, using different interaction strategies, prompts with different contents, and different model parameter configurations. We evaluate the results with two distinct samples: a benchmark with simpler systems, used in related work, and a more significant sample based on complex systems used in practice. Finally, we evaluate the effectiveness of LUCIA in detecting conflicts, comparing the selected LLMs with each other and against the original test generation tools used by SAM: Randoop, Randoop Clean, EvoSuite, and Differential EvoSuite. Our evaluation shows that LLMs effectively detect semantic conflicts, with Llama and Qwen outperforming the other models. While no single model could surpass traditional tools, multiple models combined achieved superior performance in conflict detection. Overall, the new extension identified three additional conflicts undetected by SAM, representing a 200% improvement in identifying unique conflicts compared to the single-model approach (Code Llama 70B) used in our previous work. These results reinforce previous findings that LLMs can generate unit tests that are effective in detecting semantic conflicts, while demonstrating the superior effectiveness of multi-model approaches.
Objective: This study investigates the quality of tests and the associated sentiments in Dart, the primary language for mobile application development with the Flutter framework. Methods: The study begins by using the DNose tool to detect 14 types of test smells in code written in the Dart language, along with their associated sentiments. Next, we evaluate the tool in terms of precision, recall, accuracy, and F1-score. Using this tool, we conduct a detailed analysis of tests in open-source projects extracted from the language’s central repository. Results: The study starts with a dataset of 5,410 Dart projects, from which 4,154 repositories were successfully cloned after processing. Based on the cloned projects, we generated a dataset containing 1,115,938 occurrences of test smells and their associated sentiments. The analysis allowed us to characterize the most frequently encountered test smells and identify their causes. We observed the presence of test smells in 77% of test files. Another key characteristic observed in the analyzed projects was the scarcity of tests: 1,873 projects had one or no tests, which led us to expand the analysis to a broader base. In addition, we analyzed the relationship between developers’ sentiments and the identified test smells, enabling us to classify test smells according to sentiment. Conclusion: This research makes a significant contribution by providing in-depth insights into the quality of tests and associated sentiments in projects from Dart’s official repository, as well as offering an open-source tool for detecting 14 types of test smells and their associated sentiments.
The Graphical User Interface (GUI) is increasingly becoming the focus of developers and testers. A well-designed, defect-free interface can significantly affect whether the application functions properly and provides a satisfying user experience. In particular, in the era of smartphones with varying screen sizes and operating systems, mobile developers and testers are increasingly developing and using interface tests. This article aims to characterize the practical landscape of Mobile GUI testing by analyzing discussions among practitioners across six Stack Exchange communities, identifying the main challenges, tools, and platform-specific differences reported by developers and testers. To achieve this goal, we collected and filtered data from Stack Exchange Data Dumps covering the years 2012 to 2023, combining automated keyword-based filtering with manual validation by three independent analysts, resulting in 714 posts and 203 comments for analysis. The yielded findings show that the main challenges are device compatibility, unexpected UI interference, and limitations in automation tools. Appium emerges as the most prevalent tool, mentioned in over 40% of analyzed posts, while platform-specific frameworks such as Espresso and UI Automator (Android) and XCTest and XCode UI Test (iOS) are also widely discussed. The results also show that Android offers greater testing flexibility, whereas iOS imposes stricter restrictions that require additional configuration. This study provides a practitioner-driven synthesis of real-world Mobile GUI testing practices, shedding light on the main trends and practices developed by the community.
