Add essay notes

Everloom-129 · Jun 15, 2022 · 3f9076d · 3f9076d
1 parent b259a83
commit 3f9076d
Show file tree

Hide file tree

Showing 27 changed files with 207 additions and 0 deletions.
diff --git a/ASE/ASE.md b/ASE/ASE.md
@@ -0,0 +1,33 @@
+# ASE 论文整理
+
+## 1. Introduction
+
+开发团队需要量化项目的维护问题和技术债，来确定是否需要重构，这是比较困难的事情。论文对此使用三种自动架构分析(automated architecture analysis) 和DV8，在ABB上的8个大项目测试，并将结果反馈回项目开发团队，举行采访等等，来说明其是否有用。  
+第一个技巧：用架构维护指标度量(architecture measurement)，其包括decoupling level(DL)和propagation cost(PC), 第二个技巧：架构缺点检测(architecture flaw analysis)，量化bug和change，通过design structure matrix可视化。第三个技巧：架构根分析(architecture root analysis), Design rule space(DRSpace):一些用于实现某模式，特征等的架构关联文件，architecture root: 把系统里最易错文件集合起来的DRSpace。
+
+## 2. Research Questions
+
+1. DV8是否有助于管理层与开发层交流？
+2. 和其他公司内部项目和一些基准模式比，DV8是否有助于从事者理解其系统维护性  
+3. DV8是否有助于开发者准确找到有严重设计错误的文件(hotspot)
+
+## 3. Procedure
+
+如下：
+![Figure1](Figure1.png)
+
+## 4. Architecture measurement  
+
+测量DL和PC，各个项目的DL和PC，可看出DL和PC负相关，且DL越高，PC越低，项目维护性越高
+
+## 5. Architecture flaw analysis
+
+一个是flaw detector，生成DSM，一个是flaw cost calculator,量化维护费用
+
+## 6. Architecture root analysis
+
+未细看
+
+后面是作者的一些总结，未细看，重要的是第三部分Procedure，要更深入了解architecture flaw 和architecture root , DSM等可以看论文具体部分
+
+
diff --git a/ASE/ASE论文笔记.pdf b/ASE/ASE论文笔记.pdf
diff --git a/ASE/Figure1.png b/ASE/Figure1.png
diff --git a/BENCHMARK/BENCHMARK.md b/BENCHMARK/BENCHMARK.md
@@ -0,0 +1,78 @@
+# Benchmark  论文整理
+
+## 1. Introduction
+
+**论文背景**  
+在软件开发中，不同tool对检测not-quite-right的定义不同,技术债不一定相同。不同tools对类似文件问题的报告是否相同，那些tool有更可能找出可能导致大问题的技术债并不确定。
+
+**extrinsic maintainability measures**  
+版本修改数，bug修复数，版本修改的代码行数，修复bug的代码行数
+
+**常见软件measure(度量标准)**  
+Line of code, complexity, cycles,cycle包含file和package两个方面
+
+**两个概念**
+co-change(historical)  
+code-based(structural)
+
+## 2. Research Questions
+
+1. 通过对类似问题文件的报告，不同tool的检测效果相符合程度为多少？
+2. 对一些常见问题，不同tool检测是否一致?
+3. tool检测到的问题是否真包含技术债，
+
+## 3. Empirical Study
+
+**A. Tool Selection**  
+选择软件的标准：易获得，可以在文件层面分析，结果机器可读（文件是任务分配的最小单位，与maintenance cost有关)  
+
+论文所选的tool如下
+![Table1](Table1.png)
+(h)表示此measure包含了一个计划提交历史的信息， 第三列表示此measure是否是其他measure的汇总  
+Security Hotspot（安全热点）：需要审查的安全敏感代码段
+
+**B. Subject Selection**  
+选择project的标准：至少1000次提交，源代码主要为Java。从20-MAD dataset中寻找
+
+论文所选的subject如下
+![Table2](Table2.png)
+"#Com" 为 commit数目
+
+**C. Data Processing**
+![Figure1](Figure1.png)
+不同的tool有不同的输入，有不同的输出，Archinaut(ARCH)既是measure producer的一部分，也是不同tool结果整合的工具  
+SCC是用来测量代码大小和复杂度的一个工具（可以认为是准确的）
+JEC是作者单独制作的tool  
+
+在Data Analysis部分，file 部分与cycle部分分离开，研究不同file measure的相关度，既对原数据分析，也对通过SCC数据normalized过后的数据分析，并看每个measure重叠的最多的20个最差的文件。同时对cycle，研究其overlapping
+
+## 4. Results
+
+**RQ1**  
+**File measure的分析**
+![Table3](Table3.png)
+![Table4](Table4.png)
+![Table5](Table5.png)
+表格直观地显示三个不同measure的相关系数，可以看出的是size大致都一样，但complexity（尤其是normalized后的）不同tool的结果不一样，且complexity受size影响大
+
+
+![Table6](Table6.png)
+![Table7](Table7.png)
+此两个表格中数字为project的数目,可以看出的是不同tool所确认的最有问题的文件非常不同
+
+**Cycle measure 的分析**
+![Table8](Table8.png)
+分析DES，DV8，S101三个tool对各个project所能检测到的package cycle和file cycle，结果如上，可以看出不同tool对cycle的结果还是很不一样的
+
+**RQ2**
+分析了size，complexity，cycle,smell detection不同的原因  
+size作者无法解释  
+complexity源于循环复杂度和文件层面复杂度计算不同  
+cycle源于计算cycle的instance不同和cycle的member计算不同
+
+**RQ3**
+通过一个文件在提交中出现的次数(#Change),和bug修复有关的文件修改数(#Bug),提交中增加或删除的代码行数(#ChangeChurn),bug修复有关提交中增加或删除的代码行数(#BugChurn)来预估maintenance cost，最后得出结论，除了需要历史提交的一些measure，对识别易错和易变的文件来说，大部分tool并不比常见measure更加indicative
+
+## 5. Conclusion
+
+选出6个tool，对10个project测试，比较各个tool不同之处，分析其不同源于哪，那个tool找出最针对maintenance的问题。最后得出的结论是一些基本的measure不同tools的结果都不同，也无法找出最针对maintenance的问题,也说明利用historical而不单单是structural的重要性。
diff --git a/BENCHMARK/BENCHMARK论文笔记.pdf b/BENCHMARK/BENCHMARK论文笔记.pdf
diff --git a/BENCHMARK/Figure1.png b/BENCHMARK/Figure1.png
diff --git a/BENCHMARK/Table1.png b/BENCHMARK/Table1.png
diff --git a/BENCHMARK/Table2.png b/BENCHMARK/Table2.png
diff --git a/BENCHMARK/Table3.png b/BENCHMARK/Table3.png
diff --git a/BENCHMARK/Table4.png b/BENCHMARK/Table4.png
diff --git a/BENCHMARK/Table5.png b/BENCHMARK/Table5.png
diff --git a/BENCHMARK/Table6.png b/BENCHMARK/Table6.png
diff --git a/BENCHMARK/Table7.png b/BENCHMARK/Table7.png
diff --git a/BENCHMARK/Table8.png b/BENCHMARK/Table8.png
diff --git a/DesigniteJava/DesigniteJava.jar b/DesigniteJava/DesigniteJava.jar
diff --git a/DesigniteJava/Java代码度量分析工具：Designite简介.pdf b/DesigniteJava/Java代码度量分析工具：Designite简介.pdf
diff --git a/JSS/Image_20220611172901.png b/JSS/Image_20220611172901.png
diff --git a/JSS/JSS.md b/JSS/JSS.md
@@ -0,0 +1,96 @@
+# JSS 论文整理
+
+## 1. 相关概念
+
+### 1.1 **Smell**  
+
+软件开发过程中遇到的架构问题.  与antipattern, flaw, anomaly 一样,包括三个architecture, design, implementation从高到低三个level,文章主要专注于architecture level
+
+### 1.2 **Architectural Technical Debt (ATD) 技术债**  
+
+交付第一次代码就像陷入债务。 债务是可以加快开发速度，只有通过重写代码，及时偿还债务。如果不偿还债务，就会发生危险。 把时间花在写一些不正确的代码上的每一分钟都算作该债务的利息。 整个软件项目可能在未合并代码的部署，面向对象设计或其他方面的债务问题而陷入停顿。(Ward Cunningham)
+
+这种隐喻和金融债务非常类似，这也是这个隐喻的高明之处：为了解决短期的资金压力，获得短期收益，个人或企业向银行或他人借款，从而产生债务，这种债务需要付出的额外代价是利息。
+
+如果短期商业的投资所带来的收益大于利息，这也许是一种明智的做法，但如果入不敷出，收益不及债务产生的利息就会导致资产受损。虽然长期来看这种投资仍然有可能扭亏转盈，但是整个过程风险很大，随时会导致个人或企业破产。
+
+### 1.3 论文大概和研究的问题
+
+JSS整理了之前一些关于architectural smell detection论文，分析他们的一些**基本发布信息**， **所采用的的techniques** , **所采用的的tool**， **相关的limitation**，分析各种technique，tool针对哪种smell，他们是如何验实的等等。
+
+## 2. 和architecture相关的一些概念  
+
+1. **Technique Styles**
+   1. Rules-based  
+    用已有的指标和阈值(metric and threshold)和已经已有的框架，探索步骤和知道步骤(framework, heuristics, guidelines)来探测一些架构问题。这种风格最常用  
+   2. Graph-based  
+    把系统某个成分或实体当成node，他们之间的关系当成edge，用图来表示架构各个实体及其关系。
+   3. Design structure matrix (DSM)  
+    用二维矩阵来表示软件架构的各种关系，常用来设计管理复杂系统。
+   4. Model-driven  
+    通过抽象概念和建模(abstraction and modeling) 来表示系统的架构和各种行为
+   5. Code smell analysis  
+    关注于如何从源代码的smell来检测软件架构中的smell
+   6. Reverse engineering and history-based  
+    Reverse engineering: 通过现有的软件系统来推测其设计与架构，以及其相关生产过程  
+    History-based: 理解软件架构的模式和改动
+   7. Search-based  
+    把软件工程的问题转为可计算的寻找问题(computational search problem),以元探索式的方式(metaheuristic)来解决
+   8. Visualization  
+    把架构smell检测可视化，从而有助于大型软件系统的理解
+   9. Others  
+(各种style具体如何实现见论文)
+
+2. **Architecture style**  
+即各种常见架构的种类  
+    1. Service-oriented 
+    2. Model-View-Controller(MVC)
+    3. Layered
+    4. Component 
+    5. Cloud
+    6. Client-server
+    7. C-language
+    8. Java EE
+    9. Android
+    10. Aspect-oriented
+
+3. **Architecture Smell**  
+    Serviced-oriented, performance, dependency, package 等等，具体见论文附录
+
+4. **Validation Type**  
+   各论文是如何证实其方法技巧的，主要分为empirical study和case study两类
+
+5. **Quality characteristics**  
+   各论文的性能分析，包括maintainability, performance, security等方面
+
+更多信息见论文第四部分Analysis framework
+
+## 3. 主要（有用）成果
+
+### 1. 各论文中其使用的technique style的分类
+
+![Figure4](Image_20220611172901.png)
+
+### 2. 各论文使用的technique其检测的smell的分类
+
+Rule-based 类
+![Table3](Table3.png)
+Graph-based 类
+![Table4](Table4.png)
+DSM 类
+![Table5](Table5.png)
+model-driven类
+![Table6](Table6.png)
+code smell analysis类
+![Table7](Table7.png)
+reverse engineering and history-based类
+![Table8](Table8.png)
+search-based类
+![Table9](Table9.png)
+
+visualization类  
+![Table10](Table10.png)
+
+### 3. 各tools可检测到的smell
+
+![Table11](Table11.png)
diff --git a/JSS/Table10.png b/JSS/Table10.png
diff --git a/JSS/Table11.png b/JSS/Table11.png
diff --git a/JSS/Table3.png b/JSS/Table3.png
diff --git a/JSS/Table4.png b/JSS/Table4.png
diff --git a/JSS/Table5.png b/JSS/Table5.png
diff --git a/JSS/Table6.png b/JSS/Table6.png
diff --git a/JSS/Table7.png b/JSS/Table7.png
diff --git a/JSS/Table8.png b/JSS/Table8.png
diff --git a/JSS/Table9.png b/JSS/Table9.png