Problem: Reoccurring software documentation fragments called documentation phrases crosscut documentation body and introduce undesired redundancy. The redundancy imposes problems with software documentation development and evolution. Objective: We want to reduce the negative effect caused by documentation phrases redundancy by centralizing the documentation phrases sources. This way a documentation phrase will have a single source that can be used for maintenance and evolution. Method: We discuss the nature of documentation phrases and argue for the support of their parametrization. We present a new documentation phrase instantiation method based on source code annotations. The provides free IDE support for writing documentation and is aided by our tool prototype. Results and contributions: Our contributions of this paper include identification of documentation phrase parametrization and the annotation-based documentation phrase instantiation. The annotation-based documentation phrase instantiation method enables to reduce the effort needed for documentation development and evolution.

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 created 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 second study shows that shared concern annotations can be used during program comprehension for the following purposes: hypotheses confirmation, feature location, obtaining new knowledge, finding relationships and maintenance notes.The first controlled experiment with students showed that the presence of annotations 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 improvement in correctness. We conclude that concern annotations are a viable way to share developers' thoughts.

Abstract-Attribute-oriented programming (source code annotations) is a program level marking technique that enables enrichment of program elements with custom metadata. In this paper we hypothesize that there is a correspondence between source code annotations and conventional formal languages in general. We analyze our observations about source code annotations from three aspects of language description: concrete syntax, abstract syntax, and semantics. The discussion provides evidence of the hypothesized correspondence and we use it as a basis for our definition of an annotation-based language (abbreviated: @L). However, the analysis also shows that compared to conventional formal languages, source code annotations have some specificities mainly connected to their binding to host program elements. The presented analysis contributes to the field of attributeoriented programming by discussing the relationship between annotations and conventional formal languages, and by surveying relational idioms in annotations' usage that can be inspirational for annotations' authors.

Currently, the most commonly created formal languages are configuration languages. So far source code annotations and XML are the leading notations for configuration languages. In this paper, we analyse the correspondence between these two formats. We show that there are typical XML to annotations mapping solutions (mapping patterns) that indicate a correspondence between embedded and external metadata formats in general. We argue that mapping patterns facilitate creating configuration tools and we use a case study to show how they can be used to devise a mapping between these two notations.

Abstract-Model-driven software development is surrounded by numerous myths and misunderstandings that hamper its adoption. We have designed our course of model-driven development approach with the goal to introduce it from the viewpoint of a programmer as a pragmatic tool for solving concrete problems in development process. The course covers several techniques and principles of model-driven development instead of concentrating on a single tool. To explain these techniques we use a case-study that is iteratively developed by the students during the course. In the paper we explain the structure of our case study, contents of individual iterations, and our overall experience with this approach.