Abstract
Background: Approaches to documenting the software patterns of a system can support intentionally and manually documenting them or automatically extracting them from the source code. Some of the approaches that we review do not maintain proximity between code and documentation. Others do not update the documentation after the code is changed. All of them present a low level of liveness. Approach: This work proposes an approach to improve the understandability of a software system by documenting the design patterns it uses. We regard the creation and the documentation of software as part of the same process and attempt to streamline the two activities. We achieve this by increasing the feedback about the pattern instances present in the code, during development-i.e., by increasing liveness. Moreover, our approach maintains proximity between code and documentation and allows us to visualize the pattern instances under the same environment. We developed a prototype-DesignPatternDoc-for IntelliJ IDEA that continuously identifies pattern instances in the code, suggests them to the developer, generates the respective pattern-instance documentation, and enables live editing and visualization of that documentation. Results: To evaluate this approach, we conducted a controlled experiment with 21 novice developers. We asked participants to complete three tasks that involved understanding and evolving small software systems-up to six classes and 100 lines of code-and recorded the duration and the number of context switches. The results show that our approach helps developers spend less time understanding and documenting a software system when compared to using tools with a lower degree of liveness. Additionally, embedding documentation in the IDE and maintaining it close to the source code reduces context switching significantly.

Abstract
Service-based architecture is an approach that emerged to overcome software development challenges such as difficulty to scale, low productivity, and strong dependence between elements. Microservice, an architectural style that follows this approach, offers advantages such as scalability, agility, resilience, and reuse. This architectural style has been well accepted and used in industry and has been the target of several academic studies. However, analyzing the state-of-the-art and -practice, we can notice a fuzzy limit when trying to classify and characterize the architecture of service-based systems. Furthermore, it is possible to realize that it is difficult to analyze the trade-offs to make decisions regarding the design and evolution of this kind of system. Some concrete examples of these decisions are related to how big the services should be, how they communicate, and how the data should be divided/shared. Based on this context, we developed the CharM, a model for characterizing the architecture of service-based systems that adopts microservices guidelines. To achieve this goal, we followed the guidelines of the Design Science Research in five iterations, composed of an ad-hoc literature review, discussions with experts, two case studies, and a survey. As a contribution, the CharM is an easily understandable model that helps professionals with different profiles to understand, document, and maintain the architecture of service-based systems.& COPY; 2023 Elsevier Inc. All rights reserved.

Abstract

Abstract

Abstract
Monitoring a system over time is as important as ever with the increasing use of cloud-native software architectures. This paper expands the set of patterns published in a previous paper (Liveness Endpoint, Readiness Endpoint and Synthetic Testing) with two solutions for supporting teams in diagnosing occurring issues — Deployment Tracking and Exception Tracking. These patterns advise tracking relevant events that occur in the system. The Deployment Tracking pattern provides means to limit the sources of an anomaly, and the Exception Tracking pattern makes a specific class of anomalies visible so that a team can act on them. Both patterns help practitioners identify the root cause of an issue, which is instrumental in fixing it. They can help even less experienced professionals to improve monitoring processes, and reduce the mean time to resolve problems with their application. These patterns draw on documented industry best practices and existing tools. In order to help the reader find other patterns that supplement the ones suggested in this study, relations to already-existing monitoring patterns are also examined. © 2023 Copyright held by the owner/author(s).