1.1Multi-dimensional software views

1、軟件構造中的多維視圖

?

·Moment維度關注于程序在某一時刻的表現，而Period關注的是程序在一段時間內的表現。

·Build-time維度關注程序還未被投入運行，編碼階段的表現，而Run-time維度更關注于程序運行時的表現；

·

1.build time views

code-level view: functions \classes\methods\interfaces(代碼邏輯組織）

component-level view: file \directories\packages\libraries (代碼物理組織）

Static linking :庫被拷貝進代碼形成整體，執行的時候無需提供庫文件（build time）

4）build time ，period， component-level view

versioning

版本控制是給計算機軟件的不同的狀態分配唯一的名字或者編號的過程。

2. runtime views

（runtime就是運行，程序被載入目標機器，開始執行。）

以下是在各種視圖（views）中的含義

code-level ：邏輯實體在內存中如何呈現？（in-memory states）

component-level ：物理實體在物理硬件環境中如何呈現？（physical environment）

moment：邏輯/物理實體在內存/硬件中特定時刻的形態。

period ：邏輯/物理實體在內存和/硬件中隨時間如何變化。

dynamic linking :動態鏈接

2、視圖之間的聯系

?

①從無到有，寫出了代碼，就進入了Build-time維度，開始只是單個的沒有任何聯系的代碼文件，所以是在moment+Code-level維度；

②此時隨著時間的推移，代碼刪刪改改，就屬于Period+Code-level了，而代碼越寫越多成為了一個包，甚至形成了一個庫，于是就屬于moment+Component-level維度了；

③但是隨著時間的推移，庫文件由于需求的變化發生了變化，所以就屬于Period+Component-level；

④代碼寫好了，投入運行，進入Run-time維度，觀察的如果是某一句代碼的執行后結果，那就是moment+Code-level維度，但如果看的是代碼執行的軌跡，那就是Period+Code-level維度，而如果看的是一個庫文件的連接情況等，那就是moment+Component-level維度了；

⑤如果看的是線程或進程的執行過程，也就是通過日志等手段查看一段時間內系統都做了什么事情，那么就是Period+Component-level了。

1.2 Quality Objectives of Software Construction

1、外部質量與內部質量

外部質量因素影響用戶，內部質量因素影響軟件本身和它的開發者，外部質量取決于內部質量。

2、外部質量的具體方面

（1）正確性（Correctness）：至高無上的質量指標，按照預先定義的“規約”執行。一個可用的軟件一定是正確的，所以首要保證軟件的正確性，其他的都可以做妥協、讓步，但只有這一項不可妥協。

（2）健壯性（Robustness）:是對正確性的補充，即在出現“規約”定義之外的情形的時候，軟件要做出恰當的反應，通俗地說就是出現異常時不要“崩潰”。

但軟件的“正常”與“異?！笔侵饔^而非客觀的，所謂的“異?！?#xff0c;取決于spec的范疇，那些未被“規約”覆蓋的情況即為“異常情況”。

（3）可擴展性（Extendibility）

（4）可復用性（Reusability）

（5）兼容性（Compatibility）

（6）效率（Efficiency）

（7）可移植性（Portability）

（8）易用性（Easy of use）

（9）功能性（Functionality）

3、折中處理

①正確的軟件開發過程中，開發者應該將不同質量因素之間如何做出折中的設計決策和標準明確的寫下來；

②當某一項滿足的足夠好的時候有可能其他項的表現極差，此時需要做權衡，使得各部分的表現都較好，在某些特定要求下也可以放棄優化其他項而做到某一項的極致；

③雖然需要折中，但“正確性”絕不能與其他質量因素折中。

5、五個關鍵的質量指標

·Elegant and beautiful code：代碼要容易理解，通過統一變量/方法的命名標準、代碼的風格、注釋、包組織結構、必要時重構代碼等方式讓代碼盡可能的容易理解。

·Design for/with reuse：ADT/OOP、接口、繼承(Overload、Override)、多態、泛型、框架等技術可用于提高代碼的可復用性。

·Low complexity：當復雜度較低的時候，代碼就容易被擴展新的功能，所以要高內聚低耦合，遵從SOLID原則、OO設計模式、使用VCS控制代碼版本

·Robustness and correctness：使用測試驅動的開發、異常處理、Assertion機制、防御式編程等技術保證程序的健壯性和正確性。

·Performance and efficiency：使用設計模式、并行/多線程等技術提升性能。

二、軟件測試與測試優先編程

認可“測試”的價值，搞清楚“測試優先”的哲理

1.測試的特點

測試：

–> 在規定的條件下對程序進行操作，以發現程序錯誤，衡量軟件品質，并對其是否能滿足設計要求進行評估的過程。

①測試跟其他活動的目標相反：破壞、證錯、“負能量”，即我們希望發現“錯誤”，要轉變心態，用“讓其出錯”和“盡快出錯”作為寫高質量代碼的日常法寶；

②要認識到即使是再好的測試也不能保證程序里不存在錯誤

2.測試用例

測試用例 = 輸入+執行條件+結果

最主要的方法——單元測試：針對軟件的最小單元模型開展測試，隔離各個模塊，容易定位錯誤和調試。

基于等價類劃分的測試：將被測函數的輸入域劃分為等價類，從等價類中導出測試用例。

此外還要注意邊界值分析方法的補充，即在進行等價類劃分的時候，需要把邊界也作為等價類之一加入考慮。

3.代碼覆蓋度

覆蓋度：

1.代碼覆蓋度

–> 基于代碼的測試覆蓋評測測試過程中已經執行的代碼的多少，與之相對的是要執行的剩余代碼的多少。

2.輸入空間覆蓋度

–> 參照模塊的規格說明，測試用例占總輸入空間的比例。

效率：

–> 成果（測試結果）/資源（測試時間空間）

代碼覆蓋度越低，測試越不充分，但要做到很高的代碼覆蓋度，需要更多的測試用例，測試代價高。

測試效果：路徑覆蓋 > 分支覆蓋 > 語句覆蓋

測試難度：路徑覆蓋 > 分支覆蓋 > 語句覆蓋

4.兩類測試

黑盒測試：黑盒測試：用于檢查代碼的功能，不關心內部實現細節。檢查程序是否符合規約

白盒測試：要考慮內部實現細節，根據程序執行路徑設計測試用例。一般比較早執行

總結

以上是生活随笔為你收集整理的哈工大软件构造笔记1的全部內容，希望文章能夠幫你解決所遇到的問題。

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