最近以来有个学习任务，就是翻译一篇关于软件工程相关的论文。我选择了一篇How Software Developers Tagging to Support Remingding and Refinding。由于本人水平有限，基本直译，有很多不准确不通之处。希望读到文章的人批评指导，大家交流改进，在此基础之上使得翻译和我个人的能力得以提高。我记录了自己工作的时间，确实这篇文章的翻译耗费了我一定的时间。文章来自IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 35, NO. 4, JULY/AUGUST 2009，作者M a r g a r e t - A n n e S t o r e y , J o d y R y a l l , J a n i c e S i n g e r , D e l M y e r s , L i - T e C h e n g , a n d M i c h a e l M u l l e r。这里我只用作学习交流。
下面是我的时间表（逐渐有意识的使自己养成记录工作时间的习惯）:
下面是我的译文：
软件设计师怎样使用标记来帮助提醒和重新查找
摘要：设计师经常给源代码添加注释，帮助他们来记住相关的信息和感兴趣的位置，以备将来深入研究。查找和重新查找这些笔记是构成软件维护的导航索引的一种形式。虽然在现在的开发环境中有一些支持编写和导航注释的工具。我们观察到，这些注释经常起不到提醒的作用并且有时候程序员都很难找到。针对这些缺点，我们为软件导航设计了一种称作TagSEA的新方法。TagSEA结合了航标的概念（一种在空间导航做标记的原理）和社会标签的概念来帮助程序员在语法上给源代码批注定义丰富的注释。这个工具提供了对创建，编辑，导航和管理注释的支持。我们从两个实证研究中提出这样的结果，这个实验中我们观察和分析专业的程序员二十四个月以来怎样用源代码注释来支持他们的开发活动。我们的发现显示语义上的注释添加有助于提升他们的效率。我们也提供了怎样提高一般注释工具使用的建议。
1.介绍
现代集成开发环境提供了各种各样途径的来让软件设计师用户定义的注释。这样的例子有：自定义书签，任务标记注释，交叉引用超链接。我们对导航的研究突出了两个重要的用户自定义注释的活动：提醒和重新查找。提醒帮助程序员回忆起某一段特定代码的信息。重新查找帮助程序员重新访问某段代码的特定部分。
一个简单的用户自定义注释提醒功能的例子包括内联源代码注释。在许多情况下注释提醒使用对某个区域或者代码行相关性短语，如：这是个错误或非法缺陷。用户自定义注释重新查找的的一个简单的例子就是书签的使用。书签允许开发者标记代码的特定区域方便以后重新查找。
显然，用户自定义注释在软件活动管理和导航中发挥着重要的作用。然而，从我们对软件开发者的观察和采访中，我们发现当前的源代码注释经常很难查找，筛选和管理。因此，我们深入研究怎样使用额外的语义信息去丰富这些注释，同时提高导航和管理工具的支持。
在我们寻求对注释支持的提高中，我们受到其他领域提醒和重新查找原理的启发。首先我们受到了航点的启发，航点即用来在航行中导航的。水手们通过设置航标标记地理位置来确定他们感兴趣的地方的位置。电子导航设备允许水手们增加数据元来描述航标，然后使用工具和其他的水手们组织和分享航标。
其次，我们受到了在社会书签系统中普遍使用的标签的启发。标签是不受约束的关键字，这些关键字自由的和一些信息相关联用于描述它并且帮助随后的重新查找。最常见的标签的体现是基于web的书签，这个书签包含一个或多个标签，作者id，和日期。标签的例子可以到网站flickr和delicio看到。
结合这两个比喻，我们发展了在软件上下文中标签航标的概念。在源代码中涉及特定位置的航标被标记。这些航标可以进一步通过元数据描述，包括作者，创建时间和描述性标签。我们为软件工程活动工具开发标签，去体现标记航标的概念。学习工具的使用可以使我们进一步去在软件开发和维护中探索注释的使用。
我们关于TagSEA的基本假设是航标的标记可以提高重新查找（通过航标和他相关的查看器）和提醒（通过不受约束的标签词汇和其他的元数据）。TagSEA最初的版本就被引入了。这里我们报告了从多个案例研究得来的结果，这些研究描述开发人员24个月以来怎样使用工具的。这些案例研究引起对软件开发和维护中注释使用的研究，和对创建和管理这些注释工具的推荐。
余下的论文是这样组织的：在第二部分，我们描述各种集成开发环境的特性和研究支持提醒和重新查找的工具。在第三部分，我们简要的回顾一下TagSEA的特性。第四部分，总结我们研究得主要问题。案例的研究和我们的发现在第五部分和第六部分描述。第七部分，
根据我们研究得问题，我们综合讨论我们从研究中得到的发现。对有效性的限制和威胁在第八部分呈现。
2.相关的研究
现代的集成开发环境和编程语言经常提供各种途径支持提醒和重新查找。在这部分，我们描述了许多这类的工具并且综合他们底层的设计来突出对提醒和重新查找工具支持的差距。我们回顾从内部和外部的源代码支持注释和导航的工具。
2.1非结构化源代码注释
开发者常用的创建提醒的方法就是对非结构化源代码的使用。这些评论可以用来声明关于代码的信息或者为将来工作显示位置。一个熟悉的例子就是非正式表达和关键字如:”修改”，“修复我”或者开发者的名字的首字母，去强调有怀疑的代码。这样的评论可能会分布在整个软件中。这些评论的导航通常不被集成开发环境或者编程语言支持。导航到这样的评注，开发者必须浏览源代码或者使用基于文本的搜索工具。对分布在行间的评注有限支持的导航的缺点使得开发人员必须记住关键字或者记住评注出现的位置。因此，虽然评注有时对开发人员的提醒可能是有效的，但它们不能有效的支持重新查找。
2.2支持导航的编程语言
各种编程语言都有特定的语法来通过行间，语法上的评注对导航提供支持。例如，javadoc有“@see”和“@link”标签，伴随着代码的引用（如：包，类，方法）或者统一定为资源。现代java集成开发环境自动将这些标签转换成可点击的超链接。自定义java注释也提供自解释性，允许开发者定义自定义的注释（如@hack）并且将他们嵌入到源代码中。开发者能够定义编译时注释怎样被对待（例子生成一个报告或工具来支持导航）。
2.3任务注释
针对在评注中常用的搜索关键词，现代集成开发环境经常提供明确的工具对关键词导航提供支持。这个特点很受开发人员的欢迎。我们主持的关于eclipse开发人员的调查，我们发现81个受访者中78人在使用任务注释。集成开发环境提供这个特性，如eclipse和visual studio，允许开发人员通过向代码评注中插入特殊的关键词来创建任务注释。点击一个专门的视图中的注释引导程序员到相关代码的位置。因为代码注释中直接插入任务注释，它们能够立即被看到并且能够随着代码的改善而更新。
一些集成开发环境有预定义关键字作为任务注释。例如，在eclipse中预定义关键字--被称为任务标记--的是“TODO”，”FIXME”，和“xxx”.额外的关键字可以是用户自定义的。然而，这个功能很少被使用。从我们的调查中，我们发现在81个开发人员中只有11个人自定义了任务注释词汇。只有一个或两个关键词有定义。一些开发人员甚至都没有意识到任务注释能够自定义。
Ying也研究了一个开源项目中的任务注释，创建了一个他们使用的分类。他们发现程序员使用这样的评注来交流以及支持导航。因此，看来源注释对提醒和重新查找是支持的，至少是在初级水平。
为了解用于导航的任务注释使用的频率，我们对墨菲的数据做了进一步的检验。发现关于任务注释的选择事件是用户视图选择的0.2%，在研究期间在42个程序员中间只有13个人使用。我们关于开发者的先前研究显示，关于任务注释的一些问题可以使用各复杂工具的支持解决。特别的，额外的元数据，例如日期和作者，可能在帮助开发者辨别哪个任务注释是重要的和哪个是过期的有帮助。
2.4书签
书签使开发者在他们的工作空间中标记他们感兴趣的位置。开发者也能给书签增加一个描述性的标签。书签在集成开发环境中表现为一个行间的图标或文件，在书签存在的地方。
像任务标签，导航通过一个特殊的集成开发环境视图过滤查看。通过单击书签，程序员能够导航到代码的位置。
虽然看似非常有用，我们的研究和墨菲的东西，显示在软件开发中书签很少使用。在我们关于eclipse开发人员的调查中，我们发现80个调查对象中的67人，从来或很少使用书签。通过对墨菲的程序员日志数据的分析，我们发现了支持这个结果的论证。通过我们对这个数据的的分析，我们发现书签选择时间低至百分之0.02，只有12个程序员中的四个使用它们。虽然这些研究引导的是eclipse的用户，我们从其他集成开发环境的用户中得到的反馈是书签很少被使用。
我们的研究显示低使用率是由于三个原因。第一，虽然用户界面的支持使得在代码间添加一个书签很容易，但是书签缺乏足够的信息来促进随后的恢复。第二，书签由于缺乏可见性必须有一个专门的视图来看到他们，因此，容易被忘记，难以管理，很快的过时。最后，
随着代码的发展，由于和代码不固定和它的松散的相关性书签变得不同步了。
总之，书签应该同时支持提醒和重新查找。但是由于缺少元数据，低可见性，和代码的低同步性，他们的可用性面临严重的问题。
2.5分组的担忧
另一类开发工具对导航横切关注点提供了支持。ConcernMapper这个插件允许开发者将关心和相关的程序元素联系起来。重新查找在一个专门的视图中通过选择要求的确定的元素完成。问题很容易创建和访问，并且因为他们在程序中和元素相关联，随着项目的发展他们自动更新。
Jaser是一个和ConcernMapper很相似的工具。使用Jasper，开发人员能够将不同的工件中相关的片段创建成一个工作集。工件可以是各种类型，包括文档，代码片段，文本，和统一定位资源。工作集显示在一个专门的可用于导航的视图中。在ConcernMapper操作主要采用自上而下的角度（聚焦在结构元素）的地方，Jasper允许开发者从自下而上的角度构建相关的工件（聚焦于相关片段的工件）。Jasper也允许开发者在工作集中增加描述性的文本。
Eclipse Wiki和Jasper相似，但多了使用自有格式文本的方法来创建导航帮助。开发者能够在代码中创建wiki形式的文本文件，这样代码能够使用代码预览工具混合自有格式的文本和带有超链接的统一定位资源。
ConcernMapper，Jasper，和Eclipse Wiki支持提醒和重新查找。提醒通过分组相关的项目完成。Jasper通过附加提供上下文的文本进一步支持提醒。重新查找通过专门视图里的导航指引到感兴趣的项目。
2.6隐式任务上下文
另一类旨在通过隐式评估和任务上下文代表提高重新查找的研究工具。这些工具监视用户的交互行为然后删除可用的导航目标来匹配特定的任务。Mylun是这类工具中最先进的，但是他依赖于程序员打开和关闭任务来切换上下文。提醒在Mylyn中通过约束环境来完成，这样只有相关的资源能够呈现。NavTracks和ReamTracks我最近的活动允许程序员选择可能与当前任务相关的元素。这类工具通过限制选择或建议可能的导航目标来支持重新查找。
2.7旅游和导游
旅游和导游能够帮助提醒程序员怎样找到一个不常见的任务并帮助新程序员发现相关区域的代码。Eclipse提供方便去创建备忘录，一组连续的步骤指导用户通过一个过程。JTourBus使用旅游的概念自始至终将源代码视作一种文档形式。相似的，Mismar允许开发者从彼此相关的代码中选择工件和创建一个向导用来理解他们之间的关系。旅游和导航和航点路线的概念相似，这个概念是我们为程序员探索的演示工具。
2.8总结
现代集成开发环境提供支持提醒和重新查找的工具，都是通过行内机制和与代码分开储存的注释（如在ConcernMapper中的关注点和JRourBus中的旅游。然而，这些工具既不支持元数据也不对提醒和重新查找的精细的管理，我们相信对于注释管理工具这是至关重要的方面。TagSEA和以上提到的很多工具共享元素，但是也给部分航点添加了用户自定义层次标签的概念。
3TAGSEA
TagSEA是Eclipse集成开发环境的插件，它结合了航点的概念，这个航点带有为软件开发者使用的标签。虽然TagSEA通过这个研究形成了，但是底层的概念基本保持不变。
在这篇论文中，我们用了几个从显示定义中受益的术语。航点在软件对应到一个专门的为稍后检索标记的位置。通常这个位置在源代码元素（类或方法）中，但是也可能驻留在其他资源中。添加到航点的涉及信息的元数据表明了标记位置的意义和目的。在这个版本的TagSEA中，支持的元数据包括标签，日期，作者和自由格式的文本信息。标签是无约束的关键，这个关键字是作为航点元数据一部分而存在的。
图一显示了TagSEA的视图。程序员通过相关的标签和部分源代码使用javadoc风格的关键字创建航点。特别是，程序员在批注区域创建的“@tag”航点，紧随其后的是标签。描述性的文本信息能够在一个冒号后添加。
无限制数量的标签可以和任何航点关联。个人标签通过空格分割（看图1）。程序员能够使用航点关联层次标签，用一个以圆点分割或括号，例如:“@tag bug.performance”或者“@tag bug（performance）”.这表明这里有个带有标签“performance”他的父标签是“bug”.Javadoc语法允许java程序员更容易采用TagSEA，此时java程序员已经熟悉了这个约定，例如@作者，@版本。生成的航点会自动的与相联系的最亲密的java元素联系。一旦航点被创建，它们就能用来导航或者通过上传到航点代码控制系统和其他人共享信息。
另一种实现航点的机制能够增加额外的工具支持导航java注释（看2.2部分）。然而，因为我们想要扩展工具和包含没有java的航点，我们没有追求这种方法。
通过@tag概念表明航点会在编辑器文本，左边框，滚动条中突出，这样清晰的突出他们感兴趣的地方。表签树显示了代码中所有的标签和他们被使用的次数（注意:单个标签可以通过源代码有多个引用和相关资源）。分层的标签能够扩展或者按意愿简约。在标签树中选择一个或者多个标签揭示了在航点视图中相关联的航点。导航视图显示了和航点有关的信息，它的位置，作者，和创建的时间。在上图中，和标签“zest.sequence”相关联的11个航点被显示。在航点视图中点击进入打开文件编辑器，定位到编辑器航点标记的位置，去突出java元素。标记顾虑器允许程序员查找或者过滤标签来寻找与特定文本字符串相关联的标签。例如，一个程序员能够查到所有的有bugID的标签。过滤的结果显示在标签树中（在这个图中不适用）。
TagSEA也承认默认的和用户自定义的eclipse标签注释，例如TODO和FIXME。这些注释显示在标签树中并且能通过航点视图来给特定位置的代码导航。管理越来越多的标签对社会标签系统来说是一个关心的事，对于大型软件系统来说这可能也是个问题。因此，每次在过滤器文本框里输入，在部分匹配输入查询的标签树中会立即更新列表，这允许用户通过部分文本输入压缩和寻找标签空间。用户也可以通过元数据在航点视图中将航点排序。我们还添加了支持重构标签，这样他们可以被轻松的重命名，辨识或者删除。减少独一无二的标签的创建能够通过使用一组一致的标签解决。TagSEA提供自动标记起作用而在已存在标签的基础上建议术语。
TagSEA在eclipse也能利用一些功能来促进导航更容易和提醒标记的代码。例如，在包资源管理器中的文件用迷你型标签装饰表明航点在资源中的存在。程序员能够点击这些标记来导航到这些位置。
初看，TagSEA可能和目前在大多数集成开发环境中支持任务注释工具相似。然而在
几个我们认为很重要的几个关键方面是不同的。首先，标签是程序员以轻量级的方式动态创建的。在创建注释之前，对用户来说没必要预先确定单词或者分类标签。这个用户自定义的标签和先前的研究一致，在这个研究中Furnas以及其他人表明用户对于公共的对象和概念更喜欢使用他们自己的词汇表。此外，文森报道称，要想航点有用，他们必须尽可能的有特点，从而表明生成唯一标签的能力是重要的。其次，使用TagSEA，程序员能创建分层标记来产生一个轻量级的分类。这可能用注释解决潜在的阻塞问题，问题所在市太多的注释使用相同的关键字分组。第三个区别是标记层次可重构，这允许程序员很容易改变标记了的代码。
举例来说，把标签“bug14.fix-this”改变成“bug14.fixed”。尽管先进的集成开发环境提供对代码重构的支持，但是很少支持代码重构注释。最后，航点有其他元数据进一步支持重新查找。
在这篇论文的其他部分，我们多次研究那个调查，这些不同怎样改变开发者使用源代码注释用来提醒和重新查找。因为在过去的24个月中这个工具已经得到了发展，我们讨论了不同的工具，用户可以使用这些特性。
4.研究设计
我们评估了我们的研究问题使用了定性研究方法，以下详细说明。我们使用定性的方法有几个原因。第一，为了回答我们研究的问题，我们需要这种方法研究丰富的数据。第二，因为我们选择在一个生态有效上下文（现实）中研究用户自定义的注释，一个实验验证是不可能的。第三，我们的研究仍处于初级阶段并且定性方法是最适合获得信息来完善我们的工具和我们的研究问题。事实上，使用定性方法已经成为常见的早期工作的新的软件工程方法和工具，包括在源代码中对注释和导航的支持。
我们定制四个由TagSEA提供支持的研究问题的工具，在帮助程序员提醒和重新查找中起到的作用如下：
Q1：专业的程序员创建什么类型的航点和标签？
Q2：他们为什么创建这些注释？
Q3：如果程序员选择不适用TagSEA，为什么？
Q4：如果标签看做有效的，工具怎样支持用户自定义注视的反馈信息。
为了回答这些问题，我们首先进行了一个案例研究，是对在每天的编程任务中使用TagSEA的专业程序员。使用多种数据收集技术，我们深入的研究了这些程序员在问题的研究上提出的见解（看表1）。这个案例的研究设计和发现在第五部分呈现。
5.工业案例研究
5.1开发人员研究
我们招聘了六个主要任务是软件开发的程序员，他们来自剑桥的一个工业实验室，美国马萨诸州，和另外两个来自加拿大的维多利亚,不列颠哥伦比亚省(BC)的开发实验室的两个程序员。我们使用了一个便利抽样技术。特别的，我们选择用户，因为他们有相关的作为研究人员参与实验的经验。我们没有坚持他们使用TagSEA，虽然我们要求他们下载了它。TagSEA提供给这些程序员为期八周的时间。
所有的程序员从事不同的编码项目。我们将来自剑桥的程序员简称为c1到c6，来自加拿大的用户简称为b1到b2。
5.2数据收集
我们使用的五个数据收集方法如下:
1.我们对参与者进行了一个预先研究得问卷，要求了详细的编程经验，项目类型和大小，还有eclipse和社会标签的先进特点的经验。
2.我们在他们使用TagSEA的各个时间点从程序员的源代码中提取评论注释。这些数据让我们检查源代码的评论和注释的任务的使用。可惜，由于公司隐私的原因并不是所有的开发者都能够将他们的源代码提交给我们。
3.大约每隔三周我们收集元数据（包括标签）用来识别航点。
4.在剑桥程序员的帮助下我们进行了为期三周的焦点小组研究来验证我们最初的分析。
5.我们进行了关于工具见解的离职的调查和问卷调查的调查。
5.3数据分析
对每个程序员，我们收集可用的数据和进行初步的探索分析。这是随着设计分段的编码过程和从采访中，开放式问卷调查，和焦点小组获得的文本标签。在可能的情况下，我们寻求证据的融合来支持我们的主张。例如，我们从注释分析中得出的结论是通过采访和问卷验证的。这个验证允许我们构造一个关于我们用户的描述性的故事，考虑到他们特定的编程经验和编程环境，详细说明他们怎样使用或不使用TagSEA。
我们还动手分类标签来描述每个航点。两个程序员，每个都有一定的研究经验，独立的为每个用户每个航点的所有标签派生代码，然后通过共识合并他们的代码。正如常见的定性分析，我们找到程序员来验证我们对标签的含义的解释的正确性，因为我们可能误解了使用标签的含义或目的。
意图的两个意图类别被识别：INFO和TODO；信息指的是一般类别的维护信息的注释。信息包括四个子类。其中最通用的是信息特点，表明一个特定的功能的信息。信息作者是一个信息特点，在这里作者可以清楚的别识别。信息修改涉及注释一个错误修复。信息旅游涉及旅游或者航点路线。备忘是一般类别任务文档的注释。备忘有四个子分类，每个都涉及一个指定的操作：修复一个错误，改变或者完成代码的某个方面，检查一个现实问题，指定需要记录的代码。
从先前版本的论文中被修改的代码来更好的代表纵向案例研究中观察到的航点的使用（看第六部分）。这个代码类似有高德和胡伯曼分类方法的标签类型，标签是用在社会书签系统的，除了我们提炼到软件开发和维护的子类型。
除了每个航点的分类，我们在一个时间片内记录航点的数量和标签。作为一个读者的提醒者，一个标签是用户提供的关键字来索引一个航点。一个航点可以有一个或多个和它相关的标签。我们还测量一个标签重用的次数。
5.4调查结果
5.4.1用户
两个来自剑桥的程序员，c2和c3，和一个来自BC实验室的用户，b2采用TagSEA。表2在研究期间为每个用户展示了航点的数量和分类的总结和他们的改变。表3展示了标签的数量，特殊标签和标签的重用率。
表3
标签数量和标签重用度
C2使用TagSEA超过了八周的课程研究时间，在研究结束后仍然在使用。在这个研究前她加入了公司，并且正在一个团队项目中致力于扩展现有的代码。她的航点大多数被分为INFO以支持将来的任务（看表2）。在对c2的采访中，我们能够证实她创建的大多数的航点是用来导航的。她说这是对需要更多检查的地方的一个提醒。从她代码的分析中，我们能证实她不使用任务标签并且很少的源代码评注能被看做是对未来导航的支持。这个用户只用一个实例层次标签，但是她经常使用两个标签来描述一个航点。她不为航点添加额外的信息。有相同的标签被重用的实例，一个标签描述了在三个文件中的六个航点。
我们观察的一个有趣的标签叫做“home”。在采访中，c2表示那是一种支持导航的特殊标签。她还创建了一个标签类型来匹配她的名字并且被用来表明她做过改变的几个地方。她赞成Javadoc@author特性被使用过，但是她说她更喜欢轻量级的TagSEA来表示她改变的地方。在离职的采访中，c2表示她将继续使用TagSEA，但她优先选择书签和eclipse任务标签。C2提到“她喜欢TagSEA因为输入快和轻量级”。
C3在研究前的六个月加入公司。他在整个的八周研究过程中一直在使用这个工具并且在结束研究后仍然在使用。C3独自致力于支持大项目的基础代码的提供。表2显示了c3创建标签类型的摘要，和在研究过程中做的改变。对于用户，在整个研究期间对于标签和航点会经常性的改变，这表明用户能够有效的管理和更新航点。在随后的问卷中当被问及是否随着时间他使用的工具会改变，他回答：“是的，我开始用标签描述代码的功能，但是我变到基于任务的标签”，表明一个事实就是他标签的所有分类是TODO。这些用户没有创建任何层次标签，但经常使用多个标签对航点提供进一步的组织。这些用户添加的一个有趣的标签是“坏的坏的坏的”。他最初用“坏”标记的位置标明这个位置要求严重的反工。随着时间的推移，他想增加对这个位置的重点讨论，但是以一种幽默的方式表达这个悬而未决的问题。这个方法是基于早期个人在代码中使用“hackhackhack”的实践。
C3在随后的问卷中，说使用航点的最有效的例子是为随后的集成在API中标记特殊的改变。C3使用TagSEA当做“去做/为随后员工记住这”的工具。他试图使用TagSEA当做一个TODO的状态指示器而不是对导航的支持。C2和c3使用的不同体现在表2，在这里c2对航点的使用更关注维护信息,而c3
使用航点更关注与TODOS。C3说在任务注释和书签中他将支持使用TagSEA。他提到TagSEA更灵活因为用户能够在代码中直接定义他们自己的标签并将他们展示在标签视图中。
从来自bc实验室的两个程序员给我们回复的邮件来看，只用B2下载了那个工具并完成了之前的问卷。由于工作中的要求他只能在工作中使用两周这个工具。这个程序员有十年以上的编程经验。他和其他的两个团队成员致力于一个要求的项目。
他无法向我们提供代码用于分析。然而，他向我们提供了他的标签（看表2）。我们也要求了他向我们提供交互的数据（由TagSEA记录的）关于他怎样使用这个工具。这些数据显示给我们他使用航点来支持他的导航活动并且也使用重构工具来管理他的表签。在采访中，他提到重构工具是非常强大的。他创建了层次标签并且增加了额外的信息。
在问卷中，B2注释说他使用航点来探索复杂的代码路径和待办事项。他没用他们来维护信息。在随后的采访中证实他使用标记航点来支持需要进一步检查的事物。
我们不能够分析他的代码，所以我们不能决定他怎样使用普通的评论或任务注释来导航。然而在随后的问卷中，B2他既不使用书签也不使用任务注释。他感觉Eclise任务标签注释没用因为它会模糊许多由集成开发环境生成的待办事项。虽然他清楚任务标签能够定制，但是他在采访中表明它太冗长。当被问及问卷中的书签，他答道：“我从来没使用过书签标记。TagSEA增加了集成开发环境的工具应该变成Eclise标准的一部分”。
5.4.2不使用者
为了回答我们第三个研究问题，我们研究了不使用者来理解为什么他们不使用这个工具。来自剑桥的六个用户中的两个和来自bc的一个用户不使用这个工具，因为技术问题。C1不使用这个工具因为他的工作要求java和非java开发，并且在这个研究期间，TagSEA不支持非java工作。B1和C6使用一个集成开发环境配置不运行TagSEA.
来自剑桥的两个用户C4和C5只使用了很短时间的TagSEA。C5是一个高级软件工程师和eclipse专家，第一天尝试了这个工具，但最后放弃了他。在一个大工程中他的工作涉及创建和维护他自己的源代码。他清楚的意识到怎样在他的代码中导航。因此，和eclipse快捷键和先进的工功能相比他看不到任何使用TagSEA的优势。在采访中，他提到他不评注他的代码，但签入评注到版本控制系统中，这样他能够在版本历史中复审。他大量使用了一个错误追踪系统和版本历史浏览器来管理他的任务。通过检查他的代码我们证实了他不使用评注。我们发现在四个月的修订中只有一个任务注释和少于是个我们可以视作导航标记的描述性评注。
C4是一个来自另一个部门在一个临时任务的软件工程师。C4大部分时间专注于自己编码为给一个大项目提供基础支持。C4在这个研究得中途停止使用这个工具。普莱尔使用TagSEA，他通过eclipse的偏好设置创建了自定义任务标签，但不是所有，是TagSEA都提供支持的。可惜，由于保密的原因我们不能访问他的代码，所以我们不能判定他做了哪种评注。在离职面谈中，C4提到输入标记是乏味的。
6纵深个案研究
虽然工业案例研究给我们提供了关于TagSEA使用者和不使用者的的见解，但是我们想检查长期使用这个工具创建注释和软件开发过程中的效果。我们检查了三个开源项目。三分之二的项目是我们在维多利亚大学的内部项目，其中一个就是TagSEA本身。第三个项目是我们小组外部检查，然而，他的一个开发人员最近加入了我们小组式的我们能够更进一步的检查和了解在那个项目中注释是怎样使用的。
保持开发人员匿名，我们涉及的其他两个工程称作Viztk和PIM，我们采访的关于这两个项目的开发人员，我们称作v1，v2和v3。结果给了我们关于所有研究问题的见解，除了关于不使用这个工具的人员的问题。我们注意到有一些关于VizTK和TagSEA的偏见，因为和维多利亚大学研究小组由关联。PIM没有这个偏见。
6.1项目研究
6.1.1 VizTK
VizTK最初是在90年代末发起的作为探索和理解C源代码的方法。它能扩充允许可视化和大的空间信息的理解。VizTK 由110,464行java代码组成并且由维多利亚的学的两名专职程序员维护。VizTK 软件的开发人员在2006年二月开始使用TagSEA标准。
6.1.2PIM
PIM是一个使用java在Eclipse客户端平台编写的开源的个人信息管理系统。它是一个用来组织电子邮件，任务，资产的扩展的应用。在本研究得时间，PIM工程有43,021行java代码组成。它是由其他开发人员贡献并由一个程序员编写和维护的。领导这个项目的程序员在2006八月开始使用TagSEA。他要求所有的PIM的贡献者使用TagSEA。在2007年九月来自PIM的程序员加入了我们的组织作为一个博士生。但在此之前，他和我们小组没任何联系。
6.1.3TaSEA
TagSEA最初由维多利亚大学的10名研究人员和开发者设计。经过项目的生命周期，它有一到三个专职的专业开发者维护。开发者来自维多利亚的大学和IBM，人员分布为加拿大，美国，爱尔兰。在研究期间，TagSEA由106501行java代码组成。TagSEA项目当TagSEA工具能用的时候就使用了它---大约在2006五月--从它提供的方便中获得方便，但也指导设计。
6.2数据收集和分析
我们的数据收集是通过来自每个项目源代码管理系统的一个月一次的代码快照收集。我们能够检索VizTK超过两年的历史，对PIM来说少于两年，对TagSEA是一年。在2007年TagSEA经历了一个主要的移动和改变，使它在 这个日期之前难以提取数据。在2006年早期PIM从一个CVS存储库变为Subversion存储库。
因为这个原因几个月的历史记录丢失了。所有，PIM的开发人员在这个时候重组了存储库并且建议我们不要采用这段时间的数据，因为他变得复杂。
我们提取的评注包含Eclipse的任务标签和自定义重访问关键字。我们也记使用TagSEA特殊关键字@tag录和计算航点。
随着工业案例研究，我们使用前面给出的分类分类航点。这是随着每个项目的首席程序员的采访扩展的。在采访中，开发者被问及eclipse和TagSEA的使用。20个注释的样例，基于分类表分层，从每个项目中选择，要求采访者也使用我们的分类系统进行分类。受访者被要求边想边说，以帮助我们分析他们思考不同类型标签的的过程。
6.3调查结果
在这部分，我们讨论来自问卷数据分析和来自研究采访分析的结果。
6.3.1航点和任务标签的使用
从代码注释提取的数据，我们计算了eclipse任务标签的数量行航点的数量，描绘在图2中。PIM和VizTK项目显示了eclipse任务标签数量的减少，而航点成为了最受欢迎的机制。TagSEA项目总是显示较多的航点，因为从数据收集开始它就开始使用航点。在2007年10月航点的数量有很大的衰减，当一个程序员删除了大量不想关的航点。这个结果表明在这三个项目中开发者至少像eclipse任务标签一样使用航点。
正如在工业案例研究中，我们计算了标签出现和特殊标签的数量（见表4）。层次标签被当做独一无二的标签统计。我们使用这个数据计算标签重用的频率。也就是说，我们问道，有多少标签只用一次，两次等等，纵观这三个项目，我们发现了一个共同的模式，大多数标签只被使用一次或两次，然而少数的标签经常使用。例如，在VizTK中，VizTK标签被使用超过五十次。
这些标签的重用率和企业社会标签系统的重用率相似，如4.92（团队标签，私有结构讨论），5.51（在一个增强员工记录直接标记个人），9.81（关于日志的标签），12.74（社会书签）。我们注意到这些大型的系统至少有700用户。因此，比率不具有直接可比性。
分析标签的数据显示，这三个项目都利用了TagSEA分层标签的能力并且经常重用更高级的标签的名字。例如，几乎TizTK所有的标签以prefix为项目名的开始。在PIM中，很多标签以todo或tour开头。标签层次的深度显示结构和分组在每个项目中使用。层次的平均和最大的深度在表5中显示。在大多部分，标签至少有两个层次，VizTK和PIM最大的层次深度为三，TagSEA项目是五。
正如工业案例研究，通过开发人员介绍使用定性分类方案，我们也编写任务注释和航点。这个分类的结果显示在表6.像工业案例研究，这个结果向我们说明程序员使用TagSEA用于不同的目的。VizTK的开发者主要使用标签来维护信息，然而，PIM的开发人员用来跟踪要求改变的地方。这让人们想起c2和c3的区别。
6.3.2程序员采访
从2005年十一月开始V1曾是VizTK的主要软件开发者。在使用TagSEA之前，他使用TODOS标记不完备的代码，能够被改善的代码，被检测的地方。他选择使用TagSEA这样他能够给自由形式的评论增加层次标签，为将来提供容易的导航。检查他的代码，这显然是航点主要使用的显示。他仍旧使用TODOS但比以前使用少了。
随着时间，他发现他实际中没有经常使用导航返回航点，所以他更少在代码中标记尽管他有潜在的返回的好处。现在，当他需要文件的概念横跨软件结构时他趋于给他的评注增加标签，例如，一系列的位置都可能受变更的影响。他也标记需要重新访问的位置。
VizTK的开发者利用层次标签的第一层反应项目的名称。他偶尔使用三个层次增加差别。为了导航到代码中这些位置，他使用了航点视图过滤特性，如果他记得标签的名字。否则，使用标签树，他扩展了层次结构的顶层并且用来浏览目标。当在系统相似区域处理其他东西时，他增加了作者元数据。他使用了TagSEA内容辅助的特性维护一个一致的标签词汇表。他从不使用TagSEA的重构特性。
V2是PIM开源项目的创造者。从他开始使用TagSEA，他停止使用eclipse的任务注释并且开始使用层次标签todo标签标记任务。随着对这个工具的熟悉他对这个工具的使用逐渐发生了变化。最初，他为文档目的专注于创建旅游。随后，他开始为todo创建航点，为代码提供信息。这个开发者不使用航点视图导航。他在编辑器中创建他的标签然后使用编辑器或搜索工具浏览他们。他喜欢航点的层次特性。首席开发者没利用作者或日期员数据，因为他觉他给代码增加了太多的东西。
V3是TagSEA的主要软件开发者，他最初使用TagSEA时重点在代码中标记错误和修补错误，及相关的错误的数量。意图是将源代码连接错误信息存储，和相关的MyLyn任务上下文。随着时间，开发者发现这不提供将来使用，且会使代码混乱。
我们创建了航点，他很少使用内容帮助，因为他发现简单的输入标签很快。然而，他有时候使用内容帮助增加作者和元数据，但是很少，他认为元数据会使他的注释混乱。他使用了重构的特性用于大规模删除不再需要的航点。他很少使用这个功能重组标签。
V3现在使用TagSEA用于短期中断的提醒和标记可以提高的多个领域。使用层次标签创建提醒和来自VizTK项目的v1开发者相似。
他看到了TagSEA灵活和可扩展词汇表的好处。尤其，和其他开发者合作市词汇表很有用。虽然V3没使用TagSEA导航的特性，但他发现使用这个工具创建提醒很有用。为了定位标签，v3使用浏览代码的组合，航点视图，在包浏览器中可视化的装饰。
7.讨论
在这部分，我们结合和综合了来自案例研究和主题讨论的发现，也显示了我们研究得四个问题的答案。
Q1:对于使用这段，什么类型的航点和标签被创建？
层次标签。纵向的用户和专业的程序员B2都发现层次结构组织标签很有效，尤其基于不同的项目或者组件。
一个有趣的结果是来自剑桥的两个专业的程序员在大部分都没使用层次标签。在C2的案例中她最初认为层次标签不易使用，且她的标签没那么复杂，她没看到增加层次标签的好处。在c3的案例中，他觉得标签是一些不好的关键词。他更喜欢使用一组语义相似的标签。
标签重用和管理。一些标签被重用。这些结果的特点是长尾分布，这在很多社会标签的研究中都发现了。
内容帮助的特性，使得存在的标签重用更容易，在工业程序员检测的版本中不可用。这无论怎样，在开源开发者的版本中可用，目前只有一个开发者说他经常使用内容帮助，而其他两个不使用。
我们的数据也显示了用户编辑过的和移除过的航点。这个结果在大多数的社会标签的研究中都不同，表明用户不重构他们的标签。像典型的书签，随着时间的推移用户会产生更少的航点。
与此相关，我们也看到了TagSEA的重构支持删除，维护，和标签的创建。在工业案例研究中，标签被删除或者重命名，建议他们的使用随着时间变化。在水平的案例研究中，相似的行为也被观察了。另外，在TagSEA项目中，2007年底我们看到了大清理活动。
Q2:为什么程序员创建这些注释？
短期的和长期的提醒。开发者创建的提醒都是为短期或者长期的任务的。就短期提醒来说，我们看到了用户创建短暂标签来帮助他们返回之前中段的位置的证据。TagSEA的开发者，例如创建了独一无二的标签”tagsea.starthere”这样就难以忘记可以标记一个单一的地方，在这里他可以恢复中断任务。我们也看到了开发者为短期任务创建标签的证据，这样他们能容易记得。正如先前提到的，一个开发者C3创建了一个“badbadbad”标签，标记一个他需要返回并修改的地方。
长期任务的提醒经常不容易记住并且经常以一个简短问题的形式或者什么需要做的陈述。例子包括提醒代码需要被完成，检测，重构。
从2007年对Eclipse开发者关于他们怎样使用eclipse任务标签注释的采访中，我们注意到很多任务标签并不提醒。结合我们纵向的研究，我们发现开发者辨别航点的实例有些时候在代码中包含任务的信息。然而，他们说如果任务被解决之后这些航点是为了更多的提供信息，而不是当做提醒。
重新查找相关的信息。我们看到了标签关键字的使用难以忘记，这被选来帮助重新查找。例如，c2使用home标签来加快导航到下一个任务的焦点。
通过纵向案例研究中的采访，我们发现了层次结构的标签袁旭开发者重新查找注释的证据。有趣的是，每个开发者都使用不同的技术来导航。TagSEA的开发者经常只返回少数的航点，也就是他们能救助的那些。他利用筛选来发现和导航到这些航点。VizTK的开发者有些时候也这样做，但是经常从标签树中选择项目标签并通过浏览子表来发现合适的标签。PIM的开发者很少使用航点视图，重新查找标签通过选择基于 文本的搜索或者简单的在编辑器中浏览源代码。
标签的重用表明标签有时候在代码中用来文档的横切关注。VizTK的开发者最初标记他认为可能要返回的位置。人儿，正如他注意到的他很少返回到那，他开始只用标签标横切软件空间的位置。这些位置将标记一个一些代码改变需要改变其他部分代码的地方，提供给他了一个简单的方法导航到这些地方。TagSEA的开发者也提到使用航点表明多个区域，这里性能能得到改善。
提醒和重新查找。虽然我们有明确的注释描述提醒的使用和其他的标签描述重新查找，但是这两部分之间有重叠。例如，VizTK和TagSEA的开发者在纵向的研究中有时在TODO-CHANGE和INFO-FEATURE标签之间分类时有困难。在这些案例中，写注释能轻松的帮助提醒，也能提醒开发者关于注释的详细情况当他被重新找到。这往往发生在低优先级的开发者的注释中。
我们假设程序员创建的标签支持仅在案例的重新查找。在很多案例中，程序员不确定是否他们需要再次使用资源，但是不管怎样把它文件化，以这种方式组织它能够较容易的重新查找。因此，航点被创建不仅支持将来重新查找也提醒为什么航点在这。
Q3：为什么一些用户不使用TagSEA？
对于这个研究问题，我们只考虑了工业程序员的部署看那些不使用我们工具的用户。
由于技术原因缺乏采纳。三个来自工业研究得雇佣的程序员没使用TagSEA，因为不兼容问题。当评估复杂环境插件时这是个常见的问题，例如eclipse。
现有的工具足够注释需要。使用TagSEA的两个开发者只用了小段时间，这是个值得思考的有趣的案例，能够使用工具，但选择了不使用。
C5说这个工具对他没用。我们发现，通过严格的外部工具管理或者先进的用户界面特性c5复制了TagSEA的大部分有点。同样，c4已经创建了自定义的任务注释并且对自动标记工作不能完成很沮丧。这些结果很有趣的证明了用户努力去自定义他们的环境来满足他们注释的需要。
Q4:注释工具怎样改进？
考虑到很多用户，包括我们工具不使用者，注释是软件开发很关键的部分，我们利用我们从TagSEA研究中的经验来理解怎样更普遍的提高对注释工具的支持。
可见性和透明度。TagSEA是专门设计来创建标签使源代码更可见，但是，用户仍发现可见性是个问题。如果一个标签在视线之外，它很容易被忘记。程序员会忘记他们想要返回的地方如果他们没有被提醒。然而，给予用户充足的线索和避免混乱之间的平衡是重要的。在我们的研究中，用户抱怨代码的杂乱是很常见的。
此外，随着带注释的位置的数量的增加，这些位置的相对可见度下降了。采用管理的方法，分组（例如，在TagSEA中的层次标签），重构可能更有效。有额外的元数据来帮助搜索这些位置，但是元数据的使用必须是轻量级的否则它的优势不会显现。元数据可能的话，应该被自动捕捉。
公共和私有的注释。在剑桥实验室的焦点小组的讨论，有个重要的讨论就是注释应该是个人的还是共享。不使用TagSEA的人员，尤其关注这个问题。一个程序员用涂鸦来描述添加到代码中的标签。其他人喜欢在源代码中的标签注释，举例来说，c3的问卷：”没有公开的标签对让我使用。最糟糕的情况下，它们对别人是无趣的。最好的情况下，它们帮助编写代码文档”。我们从中得到的结论是私有的和公共的注释都是需要的，但是它们应该以集成的方式提供给用户而不是以分开工具的方式和不同的用户界面。此外，这个工具应该有过滤注释的机制。
作者和日期的元数据是次要的。一个来自TagSEA使用者的惊奇的发现就是作者和日期元数据不经常添加到航点中。这可能是因为专业的程序员没意识到怎样用它，或者是因为元数据增加了混乱。只有一个开发者为他的航点增加了元数据。然而，我们的确看到了创建标签费描述信息，这表明信息对追踪是重要的和有用的。注释工具能够自动的捕捉这些信息来增强搜索和过滤注释。
航点的比喻。在我们的采访和焦点小组中我们注意到用户经常对术语航点和标签混淆。从我们设计演变这个工具的经验中，我们意识到航点的概念可能和终端用户不是高度相关。的确，在大多社会书签系统中，标记的术语没有明确标识（虽然有时他们被称为社会书签）。
综合。另一个重要的考虑因素是程序员怎样利用多种资源。最初的TagSEA标签只是在源代码中创建来标记位置。然而，我们发现程序员想标记多种相关的资源，包括文档和其他非代码工件。目前的TagSEA版本支持标记不同的资源。我们建议其他的注释工具能够从支持不同类型资源的集成注释中受益。
8有效性的威胁
在这部分，我们讨论对我们研究得有效性的威胁。我们讨论框架方面的威胁一般应用于量化研究。这些威胁对定量研究解释的地方没什么特别。
结构效度。探究软件开发维护中注释怎样使用，我们开发了TagSEA.我们希望看到注释怎样支持重新查找和提醒。然而，正如其他工具，工具的特性能够驱动我们的结果。
特别，在工业案例研究中使用的早期版本的工具有局限性。这个不完善可能影响工具的可用性和效率。特别的，部署在剑桥的版本没有完全支持重构和自动标记功能没有完全实现--这可能影响了程序员对层次标签的使用也影响了程序员不使用这个工具。
一般来说，尽管如此，我们鼓励用户以不同的方式使用这个工具，表明工具本身不是限制他们创建他们需要的标签的能力。
内部效度。定性研究面对他们自己的验证问题，这不同于我们在实验研究中的发现。这里带着对Creswell敬意我们谈论我们研究的有效性，他确定了八个为提高定性研究验证的策略。
尽量的，我们按照Creswell的方法提高我们的研究得有效性。首先，我们基于这几个数据源来分析结果。第二，我们回访我们研究得参与者从他们的角度确保我们正确的解释了数据。第三，我们提供了丰富的细节描述终端用户怎样使用TagSEA，和更普遍的注释。第四，我们坦诚的对待我们的偏见并且使用这个自我反映来报告我们的结果。第五，我们的确报告了有差异的信息，都是关于使用TagSEA的用户但是没按照我们期望的方式，也有关于不使用这个工具的人员的原因。第六，至少在纵向研究中，我们能够有一个长期的观点系统是怎样运行的。我们既不参与同行汇报，这里有人知道我们会质疑我们批评我们的结果，也不使用一个外部审计师，这里人们不知道我们而做同样的事。总之，我们采用了几步使得从定性的角度看我们的方法是有效的。
外部效度。当然这是我们研究的最大限度。我们试着通过和在自己的上下文开展实际问题的工程师开展一个工业研究，来提高外部效度。然而，在工业案例研究中，我们只有三个使用者。此外，在纵向研究中，两个使用者是TagSEA的研究成员，帮助开发了这个工具。这些开发人员主动去使用这个工具可能会曲解我们的结果。很少的用户，很难知道我们概括的结果。然而，需谨慎的记住我们研究的目的是深入探索开发人员怎样使用注释。因此，我们感觉在我们的研究周期，一个定性的方法，增强一些定性数据，是合适的方法。在将来，我们打算进行实验让我们概括结果更可靠。
可靠性。为了确保我们结果的可靠性，我们进行了两个不同的案例研究，一个工业参与者和另一个纵向研究的。我们来自两个上下文的结果是并发的，都是根据客户的经验，标签重用数量，和工具提供的多种用途的灵活性。正如我们继续研究怎样创建注释，我们能够对我们的发现的可复制性有更大的信心。
总之，选择进行一个定性研究，我们收获了使用者和不使用者问题的深刻理解。这允许我们反映TagSEA和注释怎样更普遍的用于软件开发。此外，定性数据的使用允许我们理解工具随着时间怎样使用。然而，我们使结果更普遍受限于我们的方法。
9结论
标签在软件工程中使用了数十年，用于在软件版本控制系统中签到和分支事件和在跟踪系统中记录错误。Brother‘ICICLE是早期探索的极限，控制词汇表标记的结构在代码检查期间。Snippet.dzone.com和bytermycode.com只是源代码的社会标记，但是要求用户发送代码片段到公共服务器上，这里标签应用到碎片。然而，标签在源代码中没有充分作为分类机制探索和检索轻量级注释。
我们探究了在源代码中作为标签的用户自定义的注释。我们被鼓励一写在我们研究中的程序员希望能够继续使用TagSEA，这表明这个工具的特性填补了感知的需要。我们相信TagSEA吸引人的一部分是在源代码中创建自定义的标签词汇表易用性和灵活性，这对应于用户的喜好使用他们自己的对象和概念的词汇。虽然常规的源代码评注有表现力，但是TagSEA的自定义词汇表成为支持导航的标签树中的实体。我们对注释支持提醒和重新查找的方法特别感兴趣。我们发现，有点出乎意料，在我们纵向研究中的开发者似乎适合于使用”just in case”的策略。这里，提醒和重新查找的目的不同，但是在不确定的将来为了不同的目的都支持导航。
我们注意到研究了的程序员怎选TagSEA的特性以不同的方式来支持他们的任务和文档需求，这是一个没想到的和积极的结果。我们假设这个结果来这个工具自灵活性和轻量级的特性，建议将来的工具采用一个概念性的框架，这样可以应用于很多不同的上下文。
我们预计来自我们研究的结果不仅可以用来提高TagSEA也可以用于在其他集成开发环境中的注释工具。
鸣谢
作者们感谢来自两个案例研究中的参与者。他们也感谢Christoph，Ian Bull，和匿名评论者，感谢他们的反馈，帮助我们极大的提高论文的质量。
参考文献
[1] L. Brothers, V. Sembugamoorthy, and M. Muller, “ICICLE: Groupware for Code Inspection,” Proc. Conf. Computer Supported Cooperative Work, pp. 169-181, 1990.
[2] R. Capra, “An Investigation of Finding and Refinding Information on the Web,” PhD dissertation, Virginia Polytechnic Inst. and State Univ., Blacksburg, 2006.
[3] C. Cattuto, A. Baldassarri, V.D.P. Servedio, and V. Loreto, “Vocabulary Growth in Collaborative Tagging Systems,” http://arxiv.org/abs/0704.3316, 2007.
[4] L.-T. Cheng, M. Desmond, and M.-A. Storey, “Presentations by Programmers for Programmers,” Proc. Int’l Conf. Software Eng., pp. 788-792, 2007.
[5] E.H. Chi, A. Kittur, T. Mytkowicz, B. Pendleton, and B. Suh, “Augmented Social Cognition: Understanding Social Foraging and Social Sensemaking,” Proc. Human Computer Interaction Consortium Workshop, Plenary Paper, 2007.
[6] M.J. Coblenz, A.J. Ko, and B.A. Myers, “JASPER: An Eclipse PlugIn to Facilitate Software Maintenance Tasks,” Proc. Object Oriented Programming, Systems, Languages and Applications Workshop Eclipse Technology Exchange, pp. 65-69, 2006.
[7] J.W. Creswell, Qualitative, Quantitative, and Mixed Methods Approaches, second ed. Sage Publications, 2003.
[8] B. Dagenais and H. Ossher, “Mismar: A New Approach in Developer Documentation,” Proc. Int’l Conf. Software Eng., pp. 4748, 2007.
[9] L. Damianos, J. Griffith, and D. Cuomo, “Onomi: Social Bookmarking on a Corporate Intranet,” Proc. WWW Tagging Workshop, position paper, 2006.
[10] R. Deline, M. Czerwinski, and G.G. Robertson, “Easing Program Comprehension by Sharing Navigation Data,” Proc. IEEE Symp. Visual Languages and Human-Centric Computing, pp. 241-248, 2005.
[11] C. Fraser, C. Luce, J. Starke, and J. Sillito, “Tool Support for Working with Sets of Source Code Entities,” Proc. IEEE Symp. Visual Languages and Human-Centric Computing, pp. 73-77, 2008.
[12] G.W. Furnas, T.K. Landauer, L.M. Gomez, and S.T. Dumas, “The Vocabulary Problem in Human System Communication: An Analysis and Solution,” Comm. ACM, vol. 30, no. 11, pp. 964971, 1987.
[13] S. Golder and B.A. Huberman, “Usage Patterns of Collaborative Tagging Systems,” J. Information Science, vol. 32, no. 2, pp. 198-208, 2006.
[14] T. Hammond, T. Hannay, B. Lund, and J. Scott, “Social Bookmarking Tools: A General Review,” D-Lib Magazine, vol. 11, no. 4, Apr. 2005.
[15] Javadoc Home Page, http://java.sun.com/j2se/javadoc, 2009.
[16] M. Kersten and G. Murphy, “Mylar: A Degree-of-Interest Model for IDEs,” Proc. Int’l Conf. Aspect Oriented Software Development, pp. 159-168, 2005.
[17] M. Kersten, M. Chapman, A. Clement, and A. Coyler, “Lessons Learned Building Tool Support for AspectJ,” Proc. Industry Track Conf. Aspect-Oriented Software Development, Mar. 2006.
[18] F.J. Larkin, Basic Coastal Navigation: An Introduction to Piloting, second ed. Sheridan House, 1999.
[19] I. Majid and M.P. Robillard, “NaCIN—An Eclipse Plug-In for Program Navigation-Based Concern Inference,” Proc. Object Oriented Programming, Systems, Languages and Applications Workshop Eclipse Technology Exchange, pp. 70-74, 2005.
[20] C. Marshall, “Annotation: From Paper Books to the Digital
Library,” Proc. Int’l Conf. Digital Libraries, pp. 131-140, 1997.
[21] M.J. Muller, “Comparing Tagging Vocabularies among Four Enterprise Tag-Based Services,” Proc. 2007 Int’l ACM Conf. Supporting Group Work, pp. 341-350, 2007.
[22] G. Murphy, M. Kersten, and L. Findlater, “How Are Java Software Developers Using the Eclipse IDE?” IEEE Software, vol. 23, no. 4, pp. 76-83, July/Aug. 2006.
[23] C. Oezbek and L. Prechelt, “JTourBus: Simplifying Program Understanding by Documentation That Provides Tours through the Source Code,” Proc. Int’l Conf. Software Maintenance, pp. 64-73, 2007.
[24] Y.X. Pan and D.R. Millen, “Information Sharing and Patterns of Social Interaction in an Enterprise Social Bookmarking Service,” Proc. Hawaii Int’l Conf. Systems Science, pp. 158-168, 2008.
[25] J.-H. Pfeiffer, A. Sardos, and J.R. Gurd, “Complex Code Querying and Navigation for AspectJ,” Proc. Object Oriented Programming, Systems, Languages and Applications Workshop Eclipse Technology Exchange, pp. 60-64, 2005.
[26] M.P. Robillard and F. Weigand-Warr, “ConcernMapper: Simple View-Based Separation of Scattered Concerns,” Proc. Workshop Eclipse Technology Exchange, pp. 65-69, Oct. 2005.
[27] Selznak, “We Are Morons: A Quick Look at the Win2k Source,” www.kuro5hin.org/story/2004/2/15/71552/7795, 2009.
[28] J. Singer, R. Elves, and M.-A. Storey, “NavTracks: Supporting Navigation in Software Maintenance,” Proc. Int’l Conf. Software Maintenance, pp. 325-334, 2005.
[29] M.-A. Storey, L.-T. Cheng, I. Bull, and P. Rigby, “Shared Waypoints and Social Tagging to Support Collaboration in Software Development,” Proc. Conf. Computer Supported Cooperative Work, pp. 195-198, 2006.
[30] M.-A. Storey, L.-T. Cheng, J. Singer, M. Muller, D. Myers, and J. Ryall, “How Programmers Can Turn Comments into Waypoints for Code Navigation,” Proc. Int’l Conf. Software Maintenance, pp. 265-274, 2007.
[31] M.-A. Storey, J. Ryall, R.I. Bull, D. Myers, and J. Singer, “TODO or to Bug: Exploring How Task Annotations Play a Role in the Work Practices of Software Engineers,” Proc. Int’l Conf. Software Eng., pp. 251-260, 2008.
[32] J. Teevan, “Supporting Finding and Re-Finding through Personalization,” PhD dissertation, Massachusetts Inst. of Technology, 2007.
[33] N. Vinson, “Design Guidelines for Landmarks to Support Navigation in Virtual Environments,” Proc. Conf. Human Factors in Computing Systems, pp. 278-285, 1999.
[34] A. Ying, J. Wright, and S. Abrams, “Source Code That Talks: An Exploration of Eclipse Task Comments and Their Implication to Repository Mining,” Proc. Workshop Mining Software Repositories, pp. 1-5, 2005.