1、过年期间在大家的帮助下投了一篇demo，会议室WAIM

2、正在对上学期的事情进行总结，准备SEKE的论文

    目前已经写完data extract 和 features analysis

    我认为存在的问题是描述啰嗦，挖掘规律不深

    第一次写论文，好艰难

论文构思：

1、introduction（软件依赖角度）

2、data pre-processing（预处理）

    描述github数据集，筛选3-5个社区，爬去项目属性，提取依赖关系，依赖项目与github项目集匹配

    匹配这里我有一个简单的思路实现自动化，计算一下准确率，验证数据集有效性

    说明github常用命名规则，方便用户快速查找定位软件项目

3、dependency network construction（依赖关系网构建，以organization为单位，一个organization一个网络，         忽略组织外的节点的pom文件）

      顶点是项目，边是依赖关系，较之前加一个权重，就是A复用B的多少模块，权重就是多少。分析一下属性，         比如入度、出度之类的。

4、RQ1：How to reuse projects? Are there some patterns about software reuse?（频繁模式发现）

     预计发现几个模式，解释一下 或者 不存在的模式 解释一下

      比如 dependency cycle这种模式基本不存在，因为软件开发中避免造成闭环

5、RQ2：How to select to reuse a project with similar function? Is there something difference between them?

      举例：单元测试类软件、数据库类软件、开源搜索引擎类软件或者还有其他

     用依赖关系形成的网络找它们之间的不同点。

6、Threats to Validity

7、related work

8、conclusion 

——————————————————————————————————————————————————

其他思路：

1、比较几个不同组织下的软件生态结构是否相同？ 张洋师兄说没有意义

2、软件复用对软件开发的效率和质量的影响？效率和质量不知道怎么度量？（第一反应效率可以用代码      行数/项目时长/开发者人数，但想了想似乎考虑的因素太少了，不考虑）

    复用本身可以提高效率和质量，但会引入版本兼容性等问题

3、开发者的角度，还没有考虑过

——————————————————————————————————————————————————

其他：

1、思考：为什么依赖网路属性和fork没有关系？

    我的理解：通常大家会想我要复用什么，一定先fork什么到自己的版本库中再复用或者二次开发，但是项目     的pom文件中的依赖关系极少数是来源于github，大部分都是来自于原始的网址（org.apache.*），复     用关系网络是我们人为的把它们和github的项目对应起来了，所以被resue一次并不意味着相应的会被       fork，所以resue跟fork的关系很弱，我个人认为fork、watch、star应该跟兴趣有关。

2、reuse与quality

    今天偶然间看了一篇文章，结论是there is no clear evidence that reuse decisions are quality-driven.

    不过这里写quality的度量指标很多，比如稳定性、复杂性、bug数量等等。

元旦假期细致的阅读了TSE那篇论文。阅读报告如下：

1、（研究意义）最重要的意义是组件复用，但是目前搜索组件返回的结果太多，这篇文章的目的就是减少搜索结果或者是说使最相近的结果出现在top-10。

2、（研究方法）构造带权重的有向图，点代表组件，边代表使用关系，根据入度来设置权重，算法等于PageRank，跟我目前的工作有所区别的是：

第一，论文中的组件含义更广

（A component may be a source-code module, a linked library, or one section of a document. ）

第二，论文中对组件进行了相似聚类

3、（研究成果）构造了工具SPARS-J (Software Product Archiving and Retrieving System for Java)

4、（实验评估）将工具应用到了三个场景，与另外两种排序方式做对比来进行评估，又找了两个公司做了case-study。

三个场景：

改进策略，考虑出边的优先级问题，give various types of priority to specific outgoing edges 
应用场景，除component search外，还有automatic software architecture composition 、code-clone detection and component recommendation. 

回答尹老师和涛哥的问题：

1、为什么可以发表在TSE这样的顶会上？

我认为，一方面在2005年的时候研究点应该算新颖（这不是重点），另一方面，也是最重要的应该是有理论有结果有工具有应用

2、这篇论文到底有没有区分功能类别排序？

我认为是没有的，排序是通排，只不过在搜索的时候根据关键字来进行了选择，某种程度上可以理解为在搜索的时候对组件进行了功能分类

1、详读MSR论文，了解人家的研究问题

2、去掉入度为0和出度为0的点，剩余6000个顶点，用Louvain community detection 算法进行社区划分，找到nutch所在的社区中所有的点和边，绘图，见nutch.pdf

3、详细分析上面的社区的模式，以及典型的软件