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
During the process of software architectural design, numerous questions arise which must be answered. These questions may be about requirements on the proposed system (the problem space) or about how the system should be designed and developed (the solution space). As questions arise they may be answered immediately, deferred until later, or provisionally answered with an assumption about the answer. The objective of this work was to explore the nature of questions that arise during architecture. We explored the types of questions, how they are organized, how they are tracked, and how and when they are answered. We started by surveying highly experienced architects about their practices with respect to architectural questions. We also performed a controlled experiment with master students about organizing architectural questions that clarified and substantiated the survey data. We learned that architectural questions include slightly more questions about the problem space than the solution space, as well as a minority of questions related to the managing of the project. We found that architects often use ad hoc methods to organize and track them, although they typically organize them along more than one dimension. We learned also that, about a third of the time, architects make assumptions about the answers to architectural questions in order to make progress on the architecture. This suggests that some projects may have risks of incorrect design or later costly rework due to inadequate tracking or incorrectly answered architectural questions.

Abstract
Objectives: The purpose of this study was to field-test a recently developed AR-based serious game designed to promote SSE self-efficacy, called Spot. Methods: Thirty participants played the game and answered 3 questionnaires: a baseline questionnaire, a second questionnaire immediately after playing the game, and a third questionnaire 1 week later (follow-up). Results: The majority of participants considered that the objective quality of the game was high, and considered that the game could have a real impact in SSE promotion. Participants showed statistically significant increases in SSE self-efficacy and intention at follow-up. Of the 24 participants that had never performed a SSE or had done one more than 3 months ago, 12 (50.0%) reported doing a SSE at follow-up. Conclusions: This study provides supporting evidence to the use of serious games in combination with AR to educate and motivate users to perform SSE. Spot seems to be an inconspicuous but effective strategy to promote SSE, a cancer prevention behavior, among healthy individuals. Practice implications: Patient education is essential to tackle skin cancer, particularly melanoma. Serious games, such as Spot, have the ability to effectively educate and motivate patients to perform a cancer prevention behavior.

Abstract
[No abstract available]

Abstract

Abstract