臺灣博碩士論文加值系統

重視響應變化的軟體開發團隊廣泛的採用敏捷軟體開發方式。在敏捷開發過程，專案管理員通常會定義某些軟體開發規範 (程式原件命名標準，避免壞味道，保存設計架構等) 以在軟體演進時同時維護設計品質。
而目前缺乏一個及時的規則檢查機制，導致規範並沒有在專案中被強制執行，而這讓違規行為容易發生並對軟體的長期演進有負面影響。
針對這一點，這篇論文提出了一個名為 ``CommittingGuard' 的工具與其領域特定語言來支持及時檢查軟體的開發規範。
管理者可以使用 CommittingGuard 領域特定語言來指定自己定義的上傳規則，違反規則的上傳將被 CommittingGuard 阻止，這樣一來，軟體開發規範``及時'的被檢查了且開發人員可以迅速修正違規的地方。
這篇論文針對 CommittingGuard 領域特定語言在表示現實的軟體開發規範的能力進行了兩項評估。

Agile software development processes are widely adopted in software development teams that highly value responsiveness to changes.
In agile processes, configuration managers typically specify certain software development regulations on software artifacts (i.e. program element naming standards, forbidden bad smells, preserve design structures) to continuously maintain the design quality of software systems along with their evolution paths.
Currently, development teams lack an in-time and flexible checking mechanism for rapid identification of regulation violations. Without such a mechanism, regulations are not effectively enforced in development teams.
Consequently, regulation violations are easily introduced to software systems and would bring long-term negative impact to software evolution.
To this point, these thesis proposes a tool named ``CommittingGuard' with its domain-specific language (DSL) to support the in-time checking for software development regulations are proposed in this thesis.
The configuration manager can use the DSL to specify customized committing rules.
These committing rules are treated as the must-adhered standard by each programmer who attempt to commit software change.
Rule-violating commits are stopped by CommittingGuard right at the commit time.
This way, regulation checking is carried out ``Just-In-Time' and violations can be fixed rapidly.
Two studies on empirical software development regulations have been conducted to confirm the effectiveness of CommittingGuard.

Abstract (Chinese) - i
Abstract (English) - ii
Acknowledgments - iv
1 Introduction - 1
2 Related Work - 6
2.1 Software Development Regulation Checking - 6
2.2 Short-Term Quality Assurance - 8
3 Design Principles - 11
4 The CommittingGuard Tool - 15
4.1 An Usage Scenario - 15
4.2 Overview of the Design - 16
4.3 The Object Oriented Program Model - 19
4.4 The CommittingGuard Domain-Specic Language - 21
4.5 Tool Implementation - 23
5 Evaluation - 26
5.1 Study Real World Software Development Regulations - 26
5.1.1 Study Design - 26
5.1.2 Study Result - 31
5.2 Study Design Structure Preservation - 31
5.2.1 Study Design - 31
5.2.2 Study Result -37
6 Conclusion - 40
References - 42

[1] Checkstyle 5.7. http://checkstyle.sourceforge.net, 2014.
[2] JCSC. http://jcsc.sourceforge.net, 2005.
[3] N. Moha, Y. Gueheneuc, L. Duchien, and A. L. Meur, Decor: A method for the speci cation and detection of code and design smells, IEEE Transactions on Software

Engineering, vol. 36, no. 1, pp. 20-36, Jan 2010.
[4] O. Ciupke, Automatic detection of design problems in object-oriented reengineering, in Technology of Object-Oriented Languages and Systems, 1999. TOOLS 30

Proceedings, Aug 1999, pp. 18-32.
[5] FxCop. http://msdn.microsoft.com/en-us/library/bb429476(v=vs.80).aspx, 2014.
[6] Eclipse. https://www.eclipse.org, 2014.
[7] Apache Subversion. http://subversion.apache.org, 2011.
[8] J. Dong, S. Yang, and Y. Sun, A classi cation of design pattern evolutions, Journal of Object Technology, pp. 96-109, 2007.
[9] Y. Kamei, E. Shihab, B. Adams, A. Hassan, A. Mockus, A. Sinha, and N. Ubayashi, A large-scale empirical study of just-in-time quality assurance, IEEE Transactions on

Software Engineering,vol. 39, no. 6, pp. 757-773, June 2013.
[10] G. Travassos, F. Shull, M. Fredericks, and V. R. Basili, Detecting defects in object-oriented designs: Using reading techniques to increase software quality, SIGPLAN

Not., vol. 34, no. 10, pp. 47-56,Oct. 1999.
[11] N. Tsantalis and A. Chatzigeorgiou, Identi cation of move method refactoring opportunities, IEEE Transactions on Software Engineering, vol. 35, no. 3, pp. 347-367,

May 2009.
[12] M. Munro, Product metrics for automatic identi cation of bad smell design problems in java source-code, in 11th IEEE International Symposium on Software Metrics

(METRICS 2005), Sept 2005.
[13] B. Biegel and S. Diehl, Jccd: A
exible and extensible api for implementing custom code clone detectors, in Proceedings of the IEEE/ACM International Conference on
Automated Software Engineering, ser. ASE '10, 2010, pp. 167-168.
[14] A. Mockus and D. M. Weiss, Predicting risk of software changes, Bell Labs Technical Journal, vol. 5, no. 2, pp. 169-180, April 2000.
[15] S. Kim, E. Whitehead, and Y. Zhang, Classifying software changes: Clean or buggy? IEEE Transactions on Software Engineering, vol. 34, no. 2, pp. 181-196, March 2008.
[16] J. Eyolfson, L. Tan, and P. Lam, Do time of day and developer experience a ect commit buggi-
ness? pp. 153-162, 2011.
[17] Bamboo. https://www.atlassian.com/software/bamboo, 2014.
[18] Cascade. http://www.conifersystems.com/cascade, 2010.
[19] CruiseControl. http://cruisecontrol.sourceforge.net, 2001.
[20] Continuum. https://today.java.net/pub/a/today/2006/05/30/continuous-integration-with-continuum.html, 2006.
[21] Microsoft Team Foundation Server. http://msdn.microsoft.com/en-us/library/ms364061.aspx,2014.
[22] C. A. Kent Beck, Extreme Programming Explained: Embrace Change, 2nd Edition. Addison-Wesley, 2005.
[23] R. M. M. Lanza, Object-Oriented Metrics in Practice - Using Software Metrics to Characterize,Evaluate, and Improve the Design of Object-Oriented Systems. Springer-

Verlag Berlin Heidelberg,2006.
[24] R. Marinescu, Detection strategies: metrics-based rules for detecting design
aws, in Software Maintenance, 2004. Proceedings. 20th IEEE International Conference on,

Sept 2004, pp. 350-359.
[25] Eclipse Naming Conventions. http://wiki.eclipse.org/Naming Conventions, 2014.
[26] Code Conventions for the Java Programming Language. http://www.oracle.com/technetwork/java/index-135089.html, 1999.
[27] Regular Expressions. http://docs.oracle.com/javase/tutorial/essential/regex/index.html, 2014.
[28] M. Fowler, Refactoring-Improving the Design of Existing Code. Addison-Wesley, 1999.
[29] W. Li and R. Shatnawi, An empirical study of the bad smells and class error probability in thepost-release object-oriented system evolution, Journal of Systems and

Software, vol. 80, no. 7, pp.1120-1128, 2007.
[30] S. Chidamber and C. Kemerer, A metrics suite for object oriented design, IEEE Transactions on Software Engineering, vol. 20, no. 6, pp. 476-493, Jun 1994.
[31] F. B. e Abreu, The mood metrics set, Proc. ECOOP'95 Workshop on Metrics, 1995.
[32] B. Nuseibeh, To be and not to be: On managing inconsistency in software development, in Proceedings of the 8th International Workshop on Software Speci cation and

Design, ser. IWSSD'96, 1996, pp. 164-169.
[33] S. P. Reiss, Incremental maintenance of software artifacts, pp. 113-122, Sept 2005.
[34] E. Gamma, R. Helm, and R. Johnson, Design patterns : elements of reusable object-oriented software. Addison-Wesley, 1995.
[35] SVNKit. http://svnkit.com, 2012.
[36] L. W. Mar, K. C. Wu, and H. C. Jiau, A scripting environment for refactoring process execution, 2011 Joint Conference on Taiwan Software Engineering and Object-

Oriented Technology and Applications (TCSE ＆ OOTA), pp. 176-181, July. 2011.
[37] java.util.regex. http://docs.oracle.com/javase/7/docs/api/java/util/regex/package-summary.html,2014.