廢話

update on 4.24：這里是brz，軟工期中考前一天，又來寫了，這種背概念的科目最討厭了。稍微整理一下下。
完成了前四章

update on 5.27：期中考咣咣一頓寫，考的好像都會，最后反正分沒幾個。要做小組作業了，又來補一下。

update on 6.18：準備期末考，剛問候完現代交換原理，開始復習軟工。
重構了復習提綱

update on 6.19：整了點練習題。

update on 6.21：總了個結。

知識點總結

Part1 軟件工程概述

軟件的定義： 軟件是包括程序、數據及其相關文檔的完整集合。

軟件至今未完全擺脫手工藝的制作方式。

軟件是復雜的的原因：實際需求的復雜性、程序邏輯的復雜性。

現代軟件的需求者是市場用戶，決定質量的因素是管理水平。

軟件危機具體表現在：

1. 軟件開發成本難以估算，無法制定合理的開發計劃；
2. 用戶的需求無法確切表達；
3. 軟件質量存在問題；
4. 軟件的可維護性差；
5. 缺乏文檔資料；

產生軟件危機的原因：軟件系統本身的復雜性；軟件開發方法和技術的不合理以及不成熟。

軟件工程的定義：

1. 首次提出： 軟件工程是為了經濟地獲得能夠在實際機器上高效運行的可靠軟件而建立和使用的一系列好的工程化原則。
2. IEEE： 應用系統化的、規范化的、定量的方法來開發、運行和維護軟件（即將工程應用到軟件），以及對上述方法的研究。

軟件工程三要素：方法、工具、過程。

1. 方法：提供了“如何做”的技術；
2. 工具：提供了自動或半自動的軟件支撐環境；
3. 過程：將軟件工程的方法和工具綜合起來以達到合理、及時地進行計算機軟件開發的目的。

軟件工程的目標：生產具有正確性、可用性以及開銷適宜的軟件產品。

軟件工程的最終目的：擺脫手工生產軟件的狀況，逐步實現軟件研制和維護的自動化。

軟件工程過程包含的主要活動：

1. 軟件規格說明：規定軟件的功能及其使用限制；
2. 軟件開發：產生滿足規格說明的軟件；
3. 軟件確認：通過有效性驗證以保證軟件可以滿足客戶的要求；
4. 軟件演進：為了滿足客戶的變更要求，軟件必須在使用過程中不斷地進行改進。

PDCA循環（戴明環）：針對工程的質量目標，將工程過程分為 Plan, Do, Check, Action 四個環節。

軟件生命周期的六個基本步驟：

1. 制定計劃 P
2. 需求分析 D
3. 設計 D
4. 程序編碼 D
5. 測試 C
6. 運行維護 A

軟件過程模型： 對軟件開發過程的抽象，包含活動、軟件工件、參與角色。

瀑布模型：

特點： 推遲了軟件實現，強調在軟件實現前必須進行分析和設計工作。

瀑布模型讓人們意識到，由于需求很難調研充分，所以很難一次性開發成功。

演化模型：

第一次開發得到試驗性的原型產品，只為了探索可行性，弄清楚需求。

增量模型：

結合了瀑布模型和演化模型的優點。最高優先級的部分得到多次測試，保障了重要部分的可靠性。

RUP： 一個基于面向對象的程序開發方法論。
分為初始階段、細化階段、構造階段、交付階段。
每個階段結束于一個主要的里程碑，并在階段結尾評估這個階段的目標是否已經滿足。

敏捷建模： 主要特點是具有快速且靈活的響應變更的能力。

噴泉模型：

沒有特定的次序要求，在任意開發階段可以隨時補充其他開發階段中遺漏的需求。

別的模型懶得寫了，應該不考，敢考就敢掛。

---

完整的需求規格說明是很難一次性得到的，因為：

• 在開發早期用戶的想法比較模糊，很難完全準確地表達出對系統的全面要求；
• 開發過程中用戶可能會產生新的要求；
• 開發者可能在設計和實現時遇到困難，需要改變需求。

原型： 模擬某種最終產品的原始模型。

原型方法： 獲得一組基本需求后，通過快速分析構造出一個小型的軟件系統原型，滿足用戶的基本要求。
用戶可以通過使用原型系統，提出修改意見，從而減少用戶與開發人員對系統需求的誤解，使需求盡可能準確。

原型方法主要用于明確需求，但也可以用在軟件開發的其他階段。

優點：

1. 有助于快速理解用戶對于需求的真實想法；
2. 容易確定系統的性能，確認各項重要服務的可應用性，確認系統設計的可行性，確認系統作為產品的結果；
3. 軟件原型的最終版本，有的可以直接作為產品，有的略加修改后就能成為最終系統的組成部分，這樣有利于建成最終系統。

局限性：

1. 大型系統不經過系統設計直接用原型模擬比較困難；
2. 對于需要大量計算、邏輯性較強的程序模塊，原型方法難以構造該模塊的原型；
3. 對于原有應用的業務流程、信息流程混亂的情況，原型的構造和使用有一定的困難。

存在的問題：

1. 文檔容易被忽略；
2. 建立原型的許多工作會被浪費掉；
3. 項目難以規劃和管理。

Part2 軟件需求分析

需求介紹

需求的定義： 研究一種無二義性的表達工具，它能為用戶和軟件人員雙方都接受，并能把“需求”嚴格地、形式地表達出來。

需求分析的困難：

1. 用戶無法清楚表達需求
2. 雙方對需求的理解不一致
3. 用戶經常變更需求

需求分析的必要性：

1. 它使得軟件開發人員在系統分析的基礎上深入描述軟件的功能和性能，指明軟件和其他系統元素的接口，建立軟件必須滿足的約束條件。
2. 它允許軟件開發人員對關鍵問題進行細化，并構建相應的分析模型：數據、功能和行為模型。
3. 分析模型成為設計模型的基礎，需求規格說明書也為軟件測試人員和用戶提供了軟件質量評估的依據。
4. 它能準確表達用戶對系統的各項要求。

需求分析的對象：用戶要求。

需求分析的任務：準確定義新系統的目標，編制需求規格說明書。

需求分析的目標：借助當前系統的邏輯模型到處目標系統的邏輯模型，解決系統“做什么”的問題。

需求分析的操作性原則：

1. 問題的信息域必須被表示和理解；
2. 軟件將完成的功能必須被定義；
3. 軟件的行為必須被表示。

需求分析的工程化原則：

1. 首先要正確地理解問題，再建立分析模型；
2. 記錄每個需求的起源及原因，保證需求的可回溯性；
3. 開發一個人機交互過程的原型；
4. 給需求賦予優先級：緊張的開發時間要求盡量避免一次性實現每個軟件需求，應采用迭代增量的開發模型；
5. 努力刪除歧義性：因為大多數需求以自然語言描述，存在歧義的可能性，正式的技術評審是發現并刪除歧義性的一種有效方法。

用戶需求說明書 和 軟件需求規格說明書 的區別：

• 前者主要采用自然語言來表達用戶需求，其內容相比于后者比較粗略，不夠詳細；
• 后者是前者的細化，更多的采用計算機語言和圖形符號來刻畫需求，軟件需求是系統軟件設計的直接依據；
• 兩者之間并不存在一一對應關系。

需求類別：

• 功能需求：列舉所開發的軟件在功能上應該做什么，這是最主要的需求。
• 性能需求：給出所開發軟件的技術性能指標，尤其是系統的實時性和其他時間要求，如響應時間、處理時間、消息傳送時間等；資源配置要求，精確度，數據處理量等。
• 環境需求：是對軟件運行時所處環境的要求。包含硬件要求、軟件要求（系統軟件）、使用要求（對操作人員的要求）。

需求描述方法

UML是一種標準的圖形化建模語言，它是面向對象分析與設計的一種標準表示，有以下特點：

1. 它是一種可視化的建模語言；
2. 它是一種建模語言規格說明；
3. 它允許任何一種過程和方法使用它。

UML的 $4+1$ 視圖：

1. 用例視圖：用戶角度看到的系統功能。
2. 邏輯視圖：展現系統的靜態或結構特征。
3. 進程試圖：描述設計的并發和同步特性。
4. 構建視圖：關注代碼的靜態組織與管理。
5. 部署視圖：關注硬件以及軟硬件的映射。

UML的九個基本圖：

1. 用例圖： （從用戶的角度）描述系統的功能；
2. 類圖： 描述系統的靜態結構（類及其相互關系）；
3. 對象圖： 描述系統在某個時刻的靜態結構（對象及其相互關系）；
4. 順序圖： 按時間順序描述系統元素間的交互；
5. 協作圖： 按照時間和空間的順序描述系統元素之間的交互 和 他們之間的關系。
6. 狀態圖： 描述了系統元素（對象）的狀態條件和響應。
7. 活動圖： 描述了系統元素之間的活動。
8. 構件圖： 描述了實現系統的元素的組織；
9. 部署圖：描述了環境元素的配置并把實現系統的元素映射到配置上。

視圖與圖的關系：

• 用例視圖：使用用例圖和活動圖；
• 邏輯視圖：使用類圖、對象圖、順序圖/協作圖；
• 進程視圖：使用狀態圖和活動圖；
• 構件視圖：使用構件圖；
• 部署視圖：使用部署圖。

面向對象的需求分析中包含兩個模型：領域模型和用例模型。領域模型表示“當前系統”邏輯模型的靜態結構和業務流程，用例模型是“目標系統”的邏輯模型，包含：用例圖、用例說明、系統順序圖、操作契約。

領域模型： 針對某一特定領域內概念類或對象的抽象可視化表示。僅僅關注客觀世界中的事務并將其可視化，而不關注軟件對象。關鍵思想： 軟件類的名稱要源于領域模型的概念類和職責，減小人們的思維和軟件模型之間的表示差異。

識別概念類： 用例描述中的名詞可能是概念類或者是其屬性。屬性一般可以賦值，概念類則不可以，不確定時當做概念類處理。注意名詞和類之間沒有映射關系，因為自然語言具有二義性。

領域模型的創建步驟：

1. 找出候選概念類；
2. 描述這些概念類，用問題域中的詞匯為其命名，排除與需求無關的概念類；
3. 添加概念類之間的關聯；
4. 添加概念類的屬性。

類的關系：

1. 依賴關系： A 使用了 B（A使用了B的實例 / A調用了B的方法），則 A 對 B 有依賴。
2. 關聯關系： A 知道 B 的屬性和方法，關聯可以是單向也可以是雙向的。
3. 聚合關系： A 是整體，B 是部分，但其生命周期并沒有必然聯系。
4. 組合關系： 比聚合更強，整體和部分不可分開，生命周期一致。
5. 繼承關系： B 是 A 的子類，則 B 擁有 A 的所有屬性和方法，在此基礎上可以再做拓展；
6. 關聯類： C 中含有對 A, B 之間的關聯有用的信息。

畫圖：

1. 依賴關系： A 虛線箭頭指向 B；
2. 關聯關系： A 實線箭頭指向 B，或用實線與 B 連接；
3. 聚合關系： A 空心菱形箭頭指向 B；
4. 組合關系： A 實心菱形箭頭指向 B；
5. 繼承關系： B 空心箭頭指向 A；
6. 關聯類： C 用虛線連接到 A 和 B 之間的關聯。

例子：

用例模型的創建步驟：

1. 確定問題域的分析范圍；
2. 確定該范圍內可能出現的角色；
3. 根據業務背景或者領域模型，確定每個角色需要的用例，并形成用例圖；
4. 基于確定的用例，整理成規范的用例描述文本；
5. 在可能的情況下，將多個角色的用例圖合成一個相對完整的用例圖；
6. 針對每個用例，確定系統順序圖中角色與系統之間的交互，并繪制系統順序圖。
7. 基于系統順序圖，確定每個事件交互經過系統處理后應該返回給角色的聲明性結果，即操作契約。

用例模型的基本結構：

用例圖有三個基本要素組成：

1. 角色：使用系統的對象。
2. 用例：角色使用系統功能實現需求目標的一系列成功或失敗的場景。
3. 關系：角色和用例，用例和子用例之間的關系。

基本用例： 與角色直接相關的用例，表示系統的功能需求。

子用例： 根據場景描述分析歸納得出的用例，與角色無關，與基本用例相關。基本用例中相同的必須執行的操作可以提取成為包含子用例，而相同的某種條件下可以執行的操作成為擴展子用例。

用例說明范例：

系統順序圖： 在用例描述的基礎上，描述角色與系統之間的交互信息，并用可編程的方式命名。一般只需要三個UML符號元素：

• 角色；
• 代表軟件系統的對象；
• 兩者的交互信息。

例子：

操作契約： 使用前置和后置條件的形式，描述領域模型中對象的詳細變化，作為系統操作的結果。模板為：

創建操作契約的指導原則：

1. 根據系統順序圖確定所有系統操作；
2. 對于每個系統操作，結合對應的用例領域模型，找到相關的概念類對象。
3. 對于復雜的操作（用例描述中不清楚的），確定其后置條件（僅描述變化，不關注其實現），包含：對象實例的創建和刪除、對象屬性修改、對象關聯的形成和斷開。

例子：

---

--------期中考分割線--------

---

Part3 軟件設計方法

軟件設計的概念與原則

軟件設計的兩個階段：概要設計、詳細設計。

概要設計：

1. 制定設計規范
2. 軟件系統結構的總體設計
3. 數據結構設計
4. 編寫軟件概要設計說明書

詳細設計：

1. 確定各個功能模塊內的算法以及數據組織方式。
2. 確定某種表達形式來描述算法。
3. 編寫軟件詳細設計說明書。

模塊： 可單獨命名且可編址組成的部分。
包含三個基本屬性：功能；邏輯；狀態。

設計原則：

1. 單一職責。
2. 開閉原則：對擴展開放，對修改關閉。
3. 里氏替換原則：任何函數中父類可以替換成子類而功能不變。（如正方形不能是長方形的子類，即表達子類應該是父類的細化，而不是特例，不過也需要根據需求來分析）
4. 依賴倒置原則：高層模塊不依賴于底層模塊，兩者都依賴于抽象；細節也依賴于抽象，抽象不依賴于細節。比如函數 funA 調用了 funB，那么 funA 只需要依賴 funB 的功能，而不必關心其具體實現。

軟件設計的方法

在明確軟件框架的基礎上，設計：

1. 對象： 確定系統有哪些對象；
2. 功能： 確定對象的屬性和行為；
3. 關系： 確定對象之間的交互關系。

層次化的模型結構：用戶界面層、控制器層、業務/應用層、持久化層。

對象的職責通過調用對象的方法來實現，面向對象設計最關鍵的活動是正確地給對象分配職責。有下面幾種職責分配模式：

1. 類職責分配模式：核心邏輯來源于領域模型的概念類，再補充一些功能類。確定兩類職責：了解型（了解能用什么，要得到什么）、行為型（具體能干什么）。
2. 控制器模式：把接受和處理系統事件的職責分配給控制器層的對象。
3. 創建者模式：B聚合或包含A，或與A有很大聯系時，B負責創建A。
4. 信息專家模式：將職責分配給擁有履行職責的能力（擁有相關信息）的對象。

擁有相關信息后，可創建設計類圖：

1. 掃描出所有類，添加屬性
2. 添加方法
3. 添加詳細信息，如類型、返回值等
4. 添加關聯
5. 添加額外信息

Part4 程序實現方法

關鍵點：源程序文檔化。

標識符命名： 含義清晰，可閱讀性好。

源程序布局： 確定編碼規范（縮進，空格）。

注釋：

1. 序言性注釋：在代碼之前，描述模塊作用。
2. 功能性注釋：對程序中復雜結構進行局部說明。

Part5 軟件測試方法

軟件測試的三個必要條件： 明確的測試目標，測試用例，測試環境。

兩種測試方法： 白盒測試，黑盒測試。

五種測試類型： 單元測試（對單元使用白盒測試），集成測試（對模塊使用黑盒測試），確認測試，系統測試，驗收測試。

白盒測試

概念： 將測試對象看做一個透明的盒子，可利用其內部邏輯進行測試。

測試內容：

1. 模塊內的所有執行路徑
2. 所有的邏輯判斷，“真”和“假”都要測試一次

控制流圖：

1. 順序結構的多個節點可以合并為一個節點
2. 分支結構的匯聚處創建一個虛擬匯聚節點
3. 復合判斷條件要拆開成多個邏輯判斷節點

環路復雜度： 確定了控制流圖中獨立路徑的上界。
計算方法：（有三種，記一種就行）等于圖中的區域數。（區域即被點和邊劃分出的空白區域，外面的開放區域也算）

黑盒測試

概念： 將測試對象看做一個不透明的盒子，只關心其功能是否滿足需求說明書以及概要設計說明書，根據功能說明進行測試。

等價類： 相同類型的一組數據。由于不能窮舉測試，所以選取每個等價類中的一組數據進行測試。
具體分為 有效等價類 和 無效等價類。
等價類劃分表：

測試用例設計： 首先為等價類編號，然后設計用例盡可能多覆蓋沒有測試過的有效等價類，最后設計用例每次覆蓋一個無效等價類。

邊界測試：測試邊界附近的數據的邏輯。

因果圖：用于考慮輸入條件的各種組合，畫完之后整理得到判定表。

練習題

很多手寫的答案懶得上傳了，而且我寫的也不很對，不能給帶歪了。

北郵2021~2022期末考

第一題：
（感覺有點主觀的）
軟件危機包含五個方面：開發成本難以控制，需求不明確，質量不能保證，可維護性差，缺乏文檔資料。
我認為軟件工程方法讓這些問題得到了一定程度上的解決。首先結構化的需求分析方法產生的用戶需求說明書確保了對用戶的需求有充分的理解，而軟件功能需求說明書確保了開發方向無誤，軟件質量可靠性也得到提升。瀑布模型等開發模型也強調了開發時文檔資料的撰寫，這同時保證了軟件的可維護性，按部就班的開發下，開發成本（時間，人力）也得到了控制。

第二題：
需求獲取的難點：用戶無法準確表達需求；雙方對需求的理解不一致；用戶經常變更需求。
應對方法包含：生命周期模型中的制定計劃部分，首先確定了初步需求；需求分析部分制作了領域模型用于和用戶確認需求，確保需求無誤；開發過程中也可以先開發一個原型給用戶使用，再次確認需求的細節；最后測試部分確保需求得到滿足。

第三題：
概要設計負責設計程序的框架結構、開發方法、功能劃分等，而不涉及具體實現；詳細設計則需要描述每個模塊中每個方法的具體邏輯與算法。
軟件設計中的軟件對象是用于描述系統功能的類，而操作契約后置條件表示的對象是這個類的內部具體實現邏輯，兩者從不同角度描述了類的功能。

第四題：
明確的測試目標，測試用例，測試環境。
需要先定位問題，然后修改出問題的部分，重新再對該部分進行單元測試，功能無誤后重新集成再進行集成測試。

第五題：
好像不在今年考點里，先不管。

關鍵詞：商品，商品信息，購物車，商品數量，訂單，物流，物流運單。
概念類：商品，購物車，訂單，物流。

今年不考結構化需求與分析。

重點！必考！

超級大原題。

北郵2018期末考

一、判斷題
（去掉了一些課件上根本沒見過的）

軟件工程三要素是：程序、數據及相關文檔。
錯。是方法、工具、過程。

UP模型是一種以用例為驅動并融合了噴泉和增量模型的軟件生命周期模型。
對。但理論上今年不考。

數據、功能和行為模型構成了需求分析階段的一組三元模型
對。但理論上今年不考。

軟件開發的最終目標是實現目標系統的邏輯模型。
錯。最終目標是：以較低的成本，可控的進度……高質量的，滿足用戶需求的系統。（反正一大串，一眼錯）

UML規范所規定的概念類關系中，從弱到強依次是：依賴關系、關聯關系、聚合關系、組合關系、繼承關系。
對。

無論是外觀還是用例控制器，均無需實現系統事件請求的內容。
對。

確認測試是以測試人員為主，開發人員為輔，并且以系統設計說明書為參照標準的測試階段。
錯。是需求規格說明書。

在基于等價類劃分法設計測試用例時，應該使得每個測試用例覆蓋盡可能多的無效等價類。
錯。一個用例只應該覆蓋一個，要不然無法確定每個無效等價類都能被正確處理。

二、選擇題

1、D
2、D 不能加快開發進程
3、C
4、B
5、課件也妹說有這種約束啊
6、A
7、D
8、C 這是交叉引用的內容
9、B 但不考
10、B

考后總結

今年考題結構和2021~2022那一套基本一樣啊，最后一個大題換了個名字又拿來用了，很能偷懶了。

今年選擇題判斷題倒沒有很偏，見到好歹能說：哥們我好像對你有點印象啊。雖然還是有些不會的，但可以說一句良心了。（$20$ 分）

簡答題依然抽象，只有把概念都背完的神人能做了。印象中有這些題：OOD中動態結構設計和靜態結構設計的作用和聯系；操作契約后置條件有哪三種，作用是什么（哎這個真的很怪啊問的，問有哪種不就是創建實例、形成關聯、修改屬性值，還問有什么作用？作用不就是創建能創建的實例，形成能形成的關聯，修改能修改的屬性值嗎？？我真的迷惑好久）；需求分析的主要活動和可作為里程碑的結果是什么。剩下倆不太記得了。（$4\times 5$ 分）

大題有：黑盒測試的等價類劃分（$10$ 分，比較常規）；畫控制流圖，問環路復雜度和路徑獨立集（$10$ 分）；給了個操作契約，問系統順序圖（還有個 $3$ 分小問不記得了）（$10$ 分）；以及和2021~2022幾乎一樣的大題，就是把第二小問換成畫領域模型（$30$ 分）。

考得一般啊，算了不管了。