Recording Concerns in Source Code Using Annotations Matúš Sulír, Milan Nosáľ, Jaroslav Porubän Department of Computers and Informatics Faculty of Electrical Engineering and Informatics Technical University of Košice Letná 9, 042 00 Košice, Slovakia Abstract A concern can be characterized as a developer’s intent behind a piece of code, often not explicitly captured in it. We discuss a technique of recording concerns using source code annotations (concern annotations). Using two studies and two controlled experiments, we seek to answer the following 3 research questions: 1) Do programmers’ mental models overlap? 2) How do developers use shared concern annotations when they are available? 3) Does using annotations cre- ated by others improve program comprehension and maintenance correctness, time and confidence? The first study shows that developers’ mental models, recorded using concern annotations, overlap and thus can be shared. The sec- ond study shows that shared concern annotations can be used during program comprehension for the following purposes: hypotheses confirmation, feature lo- cation, obtaining new knowledge, finding relationships and maintenance notes. The first controlled experiment with students showed that the presence of an- notations significantly reduced program comprehension and maintenance time by 34%. The second controlled experiment was a differentiated replication of the first one, focused on industrial developers. It showed a 33% significant im- provement in correctness. We conclude that concern annotations are a viable way to share developers’ thoughts. Keywords: program comprehension, concerns, source code annotations, Email addresses: [email protected] (Matúš Sulír), [email protected] (Milan Nosáľ), [email protected] (Jaroslav Porubän) c 2016. This manuscript version is made available under the CC-BY-NC-ND 4.0 license: http://creativecommons.org/licenses/by-nc-nd/4.0/. This is the accepted version of: M. Sulír, M. Nosáľ, J. Porubän. Recording concerns in source code using annotations. Computer Languages, Systems and Structures (COMLAN), Vol. 46, 2016, pp. 44–65, Elsevier. http://doi.org/10.1016/j.cl.2016.07.003 empirical studies 1. Introduction Programmers developing a program continuously create a mental model, which is a representation of the program in their mind. They try to express the mental model in the programming language constructions. However, some parts of the mental model are not explicitly expressed in the source code. They are either implicitly indicated in complicated implementation details, or lost. 1.1. Motivation Suppose a developer encounters the Java code excerpt shown in Figure 1 a). While reading it, the following ideas may gradually appear in his or her mind: • The method addProduct adds some product somewhere. • As it is in the Catalog class, it adds the product to the catalog. • An addition to a catalog changes its state – the catalog is modified. • There is a condition checking whether a user is logged. • To successfully perform this operation, a logged user must be a manager; otherwise an exception is thrown. While this process may seem natural, it has the following shortcomings: • The fact that the code modifies a catalog is formed only after reading two parts of the code far apart. • The information that a “manager account” is necessary is formed after reading a rather lengthy piece of code. • There is one important piece of information not identified at all: The added product actually appears in the catalog only after the administrator approves it. This information is not apparent from this excerpt, and may be the result of cooperation of many remotely related classes. 2 a) Source code public class Catalog { ... public void addProduct (Product product) { if (!user.isLogged() || !user.getRoles().contains(UserRole.MANAGER)) { throw new SecurityException("Insufficient privilleges"); } this.productList.add(product); } } b) Mental model product catalog manager adding modification account required … Figure 1: An example of unannotated source code and the corresponding mental model Now suppose the developer originally writing the code, or any other pro- grammer maintaining it, annotated the source code with concern annotations (source code annotations are declarative marks used to decorate source code with metadata [1]), as displayed in Figure 2 a). The developer later reading it would rapidly obtain a mental model containing useful information about the code, without even looking at the method implementation, scrolling through the code to stitch the pieces of information, or even debug it to explain unex- pected behavior. Furthermore, it would be possible to find all methods requiring approval in case of refactoring or business policy changes. As annotations are a part of the Java language, no additional tools are required: standard IDE (integrated development environment) features like Find Usages could be used. 1.2. Aim The purpose of this paper is to investigate the viability of source code an- notations as a medium to share parts of developers’ mental models. Therefore, we form our hypothesis as follows: Annotations created by one group of devel- opers are useful for comprehension and maintenance tasks performed by other developers. 3 a) Source code public class Catalog { ... @CatalogModification @AccountRequired(UserRole.MANAGER) @ApprovalRequired(UserRole.ADMIN) public void addProduct (Product product) { if (!user.isLogged() ...) ... } } b) Mental model product catalog manager approval by adding modification account admin required required … Figure 2: The annotated source code and the corresponding mental model Our first goal is to find out whether at least some of the concerns recognized by one programmer can be recognized by other developers. If so, then the mental model of one developer at least partially overlaps with the other persons’ mental model. This is a necessary condition for concern annotation sharing to be useful. Then we examine the usability of concern annotations using an observational study and two controlled experiments. We formulate the research questions as follows: • RQ1: Do programmers’ mental models, recorded using concern annota- tions, overlap? • RQ2: How do developers use shared annotations when they are available? • RQ3: Can annotations created by others improve program comprehension and maintenance correctness, time and confidence? To answer each of the questions, we used an appropriate empirical research method [2]. 4 2. Basic Concepts Before describing the studies, we introduce the notion of concerns, concern annotations, and their relation to a mental model. 2.1. Mental Model A mental model is “an internal, working representation of the software under consideration” [3]. It is described by its static structures – pieces of knowledge, and by dynamic behavior – the processes forming these pieces. Now we will focus mainly on the static structures. Since there have been multiple attempts to describe the structure of a men- tal model, each researcher has its own point of view. Mayrhauser and Vans distinguish these types of structures in their review [3]: Chunks are mappings from a label like “sorting” to the program text implementing it, or to a set of other chunks like “comparing” and “swapping”. Plans are similar, but they may include relationships across various pieces of the code, and the problem domain knowledge. Hypotheses are conjectures about parts of the program, which the programmers try to prove or disprove. Our view of a mental model unifies chunks, plans and hypotheses into a set of concerns. In the programmer’s mind, a concern is represented by a short label, as shown in Figure 1 b), and its corresponding source code elements. 2.2. Concerns A concern can be characterized as a developer’s intent of a particular piece of code: What should this code accomplish? What am I trying to achieve with it? How would I tersely characterize it? Is there something special about it? Some concerns may be obvious by looking at the code itself (chiefly from the identifiers), but many concerns are hidden. Basically, a concern represents a software system requirement, or a design decision about the code [4]. A concern can be observed in three dimensions [5]: stakeholders (from whose perspective is the concern observed – e.g., a programmer); level (at what level of construct granularity is the concern expressed, e.g., low-level constructs such as 5 a loop); and expression (how is the concern expressed, starting with the mental model and ending with the source code). Due to these and other reasons, concerns’ coverage can overlap. For exam- ple, a single method can implement persistence – contributing to the persistence concern; and in the same time it can contain code securing it against unautho- rized access – a part of the security concern implementation. Thus, one piece of code can belong to multiple concerns [6], in this case, both persistence and security. 2.3. Concern Annotations Since a method can belong to multiple concerns, expressing concerns using only identifiers (naming conventions) is not sufficient: naming conventions do not scale well. See Listing 1 for an example using the Persistence keyword in the identifier to express that the method implements persistence, and Secured- Method with OnlyAdmin to specify that it contributes to the security concern by allowing access only to an administrator. Listing 1: Expressing concerns using naming conventions public addNewUserPersistenceSecuredMethodOnlyAdmin(User user) { ... } It is possible for