在多數種產業中，大部分的產品完成後，便很少再為其進行擴充或是升級。使用者一旦發現其能力不足，通常會將整個產品棄置，廠商也無法針對小部分進行擴充與升級。然而資訊工程領域卻截然不同，通常都是對既有軟體進行修改與擴充。每次的產品只能憑著開發人員的經驗來重新修改升級，找出這之中的錯誤並且逐步的修正與調整，才足以滿足使用者的需求。 然而對於資訊工程這領域來說，不論是傳統的瀑布開發法還是較新穎的敏捷開發法，其產品完成後的維護與升級成本消耗了絕大部分的開發成本。倘若產品是不易維護或擴充的，漸漸的系統內容將不會跟上使用者的需求。導致產品的生命週期縮短，使得產品漸漸被淘汰。 儘管軟體的可維護性跟擴充性是十分重要，但在軟體的開發與設計中並沒有一個有效的方法來度量而常常在開發狀態中不停發現新需求而修改。因此在大部分的軟體專案中，往往因當初錯誤的設計架構以及不停的修改軟體需求而造成複雜的耦合。若是及早發現或是系統不大，則可能短時間內的修改就能達成目標。然而最糟的情境是開發人員在進行系統擴充時必須了解整個龐大的系統架構以及如何進行一連串繁瑣的修改才能達成維護與擴充的目標。如此一來所需耗費的時間與金錢是十分巨大的。 本研究將提出一種新的耦合關係成本圖的概念。藉著使用此概念圖，來輔助開發人員可以更清楚地分析出擴充當前系統所需的成本，進而有一依循方向來進行系統重構。在修改的同時觀察耦合關係成本圖的狀態，來幫助與理解重構之後的系統所減少的維護成本與代價。 ;It is rare in many engineering disciplines, particularly hardware industry, to upgrade an existing product with new hardware components. However, software industry is very different. Software maintenance and extension can only be done by modify the existing code. Different from other industries, software′s maintenance and evolution consume most of the development costs in the long run. If a software product is difficult to maintain or expand, it will gradually fail to deal with new requirements within reasonable time and cost. Finally, the product will be replaced by new ones. Although the software’s maintainability and expandability is very important, it is always hard to get it right once for all in the design and implementation. In many application domains, requirements are continuously changing. Modifications to the source code gradually introduce couplings, errors, and bad code smells. The effort and time needed to modify the code can be increased dramatically. The worst maintenance situation is that a programmer needs to understand the code of the entire system before he can make any changes. In this thesis, we propose a new concept to describe the coupling relation of a software system. This modeling approach is called Coupling Relation Representation (CRR). Using this CRR, we can modeling the ripple effect of code refactoring. It can be used for communicating the strategies of code refactoring. A case study is explained to show how CRR can be used in code refactoring analysis.
