基于度量的程序結構分析

第一次作業

類圖

代碼規模

代碼度量

“ ev(G)基本復雜度是用來衡量程序非結構化程度的，非結構成分降低了程序的質量，增加了代碼的維護難度，使程序難于理解。因此，基本復雜度高意味著非結構化程度高，難以模塊化和維護。實際上，消除了一個錯誤有時會引起其他的錯誤。
??Iv(G)模塊設計復雜度是用來衡量模塊判定結構，即模塊和其他模塊的調用關系。軟件模塊設計復雜度高意味模塊耦合度高，這將導致模塊難于隔離、維護和復用。模塊設計復雜度是從模塊流程圖中移去那些不包含調用子模塊的判定和循環結構后得出的圈復雜度，因此模塊設計復雜度不能大于圈復雜度，通常是遠小于圈復雜度。
??v(G)是用來衡量一個模塊判定結構的復雜程度，數量上表現為獨立路徑的條數，即合理的預防錯誤所需測試的最少路徑條數，圈復雜度大說明程序代碼可能質量低且難于測試和維護，經驗表明，程序的可能錯誤和高的圈復雜度有著很大關系。”
——引用自《OO課程中IDEA相關插件的使用》

第二次作業

類圖

代碼規模

代碼度量

第三次作業

類圖

代碼規模

代碼度量

優點和缺點自我評價

我的優點是程序結構構架地比較清晰，方法功能獨立，代碼中注釋寫得較為明確；缺點是喜歡用較長的正則表達式，沒有對最后的輸出結果進行優化。

分析自己程序的Bug

自己的程序可以較好地識別正確的，和有明顯錯誤的輸入內容，并正確地計算出結果。但遺憾的是對于一些非直觀的，相對于真實計算情境下非正常思路的輸入內容的識別力較差，比如+++2019這種類型的輸入，我在設計上沒有考慮到對這些情況的包容，或者說，對于這類輸入的分析、解析沒有較好的設計思路。

分析他人程序的Bug的策略

在本單元的程序設計中，我主要采用了以下兩種方法去測試他人的程序：
· 根據自己在編程過程中的思考和遇到的問題來對他人的程序進行測試。由于每個人的解題思路和程序構建思路是不同的，所以按照自己的程序邏輯流程可以解決的輸入內容，不一定在他人的程序中也可以順利解決。
· 我假定在進行下一階段的測試時，他所基于的之前的階段的代碼都已經經過充分測試，所有的回歸測試都能通過，也就是說，程序中最禁受不住測試的地方是他根據新要求，進行改編的新代碼。那么我會針對本次作業中的新要求的各種表現形式對他人的程序進行測試。

對象創建模式的應用

在本單元的三次作業中，我主要采用了工廠模式的對象創建方法。對Expression/Term/Factor的創建方法都是通過傳入字符串，返回一個相應的對象去完成，其中FactorX/.Sin/.Cos/.Const繼承于Factor父類。在方法調用上，他們對外的接口都基本只有.derivation() & .toString() 方法，分別返回他們加上括號的的導函數（String）和原始內容（String）。

轉載于:https://www.cnblogs.com/LifeIsAGame/p/10594591.html

總結

以上是生活随笔為你收集整理的【面向对象】第一单元总结——表达式求导的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。