元旦假期细致的阅读了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。
三个场景：
Application to JDK 1.4.2
Searching Java Classes
三个排序方式：
the component rank
Namazu using full-text search with the TF-IDF method
hand-made ordering by software experts to determine the significance of the components
改进策略，考虑出边的优先级问题，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、这篇论文到底有没有区分功能类别排序？
我认为是没有的，排序是通排，只不过在搜索的时候根据关键字来进行了选择，某种程度上可以理解为在搜索的时候对组件进行了功能分类
-
-
-
-
-
-
-
-
陈梦雯 8年前
上午跟涛哥讨论了目前工作的三个点：（为第一篇文章做准备）
1、依赖网络结构，与MSR论文的第二点做比较
2、深入细节分析复用关系的各种模式
3、pagerank值跟网络图属性跟项目属性之间的关系
下午再一次详细阅读了MSR论文的RQ2，找出了他得出的每一个结论：
1、整体分析包括：整体依赖网路的描述，连通图划分，除最大连通子图外的其他结点具有什么特征，绘制依赖网路图
2、具体分析最大连通子图包括：划分社区，计算modularity是多少，代表什么含义，绘制社区划分后的依赖图，权威点是什么含义，处于中心点的项目有什么特征，一般是什么类别的项目，以他们为中心形成的生态系统具有什么样的模式，生态系统是否为互联的，每一个生态系统的size有多大
3、细节分析包括：拿具体的生态系统做case_study
晚上开始对照上述一二三点进行分析：
RQ1：（与MSR论文第二部分进行对比）
What ecosystems exist across Github-hosted projects and what is their structure?
两个角度的出发点：
1）Github整体项目集与JAVA整体项目集的对比
2）从评论中提取依赖关系和从配置文件中提取依赖关系的对比
第一部分 整体分析：（连通图划分与分析，无向图/有向图的弱连通分量）
图节点：130078，（项目集92400，依赖集44273，公共交集 6595）
连通分量个数：398
最大连通分量节点数：128937
第二大连通分量节点数：18
除最大连通分量外剩余节点数（包括项目集和依赖集）：1141
除最大连通分量外剩余节点与项目集交集节点数：448
未完，明天继续。。。
-
-
-
陈梦雯 8年前
继续对之前所说的A->B->C（A依赖于B依赖于C）加A->C（A依赖于C）的模式（起名为三角形模式）进行典型案例分析。初步分析结果如下：已经分析了两个案例的代码
1、都是同一个USER下的，正在统计数据集中所有的三角形模式的个数，目的是看三角形模式发生在同一个USER下和不同USER下的比例，即三角形模式存在的场景。
2、案例一：A没有直接依赖于C；案例二、A没有直接依赖于B（从这里可以看到pom文件提取依赖关系有很大的不确定性）
3、（其他问题的argue）对于A直接依赖于C，argue是否应该把C作为单独的依赖包加入到A中？。（一种思路不应该加入，因为A可以import B.C.*，可以减少代码冗余，另一种思路应该加入，因为A import C，可是使代码架构更清晰）这个问题处于argue中，不好讲到底哪一种好哪一种不好（跟余跃师兄和杨程师兄讨论过）
4、（余跃师兄观点）可以做成删除代码依赖包冗余或是删除没有确实被使用的依赖包的工具。（没有确实被使用的依赖包，可以根据代码的import部分的修改记录对应到pom文件的dependency，应用场景为前一版本使用了A依赖包，且A存在于pom文件，更新版本后A被其他代替，项目不再使用A依赖包，但A仍存在于pom文件中）
5、（分析案例的同时激发了其他灵感）项目集中有一些项目，它们的名字都有公共前缀，（比如datanucleus-guava，datanucleus-jdo-query，datanucleus-api-jdo等等）它们都依赖了一些相同的项目，从项目名也看出来它们之间在某种程度上有相似性，是不是可以看它们中不同的依赖项目能否反映出它们本身的差别？（纯属YY）
请尹老师和涛哥 给点意见
@尹刚(jacknudt) @王涛(wangtao)
-
陈梦雯 8年前
尹 刚 写到：
收到，已上传，另外两点，我研究一下很好！请把论文附在本问题后面。大家都看看梦雯的判断是不是很到位，另外:
1 近几年的软件排序的研究有没有特别相近的工作？
2 这篇tse的工作，他的算法我们能不能拿到源代码，或者我们自己将其实现？以做对比实验？
-
尹刚 8年前
很好！请把论文附在本问题后面。大家都看看梦雯的判断是不是很到位，另外:
1 近几年的软件排序的研究有没有特别相近的工作？
2 这篇tse的工作，他的算法我们能不能拿到源代码，或者我们自己将其实现？以做对比实验？
- 当前状态 新增
- 选定优先级 正常
- 指派给 陈梦雯
- 里程碑 --
- 开始日期 2016-01-03
- 结束日期
- 预计工时(H) 0.00 小时
- 完成度 0%
- 关联Commit 无
