原書：《Software Engineering: A Prationer’s Approach 》—— Roger S. Pressman & Bruce R. Maxim
翻譯版：《軟件工程》，大黑書

第一部分 軟件過程 原書1-6章

七、實踐原則

這一部分還挺重要的，但中文翻譯版沒有

7.2 核心原則

7.2.1 過程的指導原則

敏捷 Be Agile

注意每一步的質量 Focus on quality at every step

適應變化 Be ready to adapt

建立有效的團隊 Build effective team

建立溝通合作機制 Establish mechanisms for communication and coordination

管理變化 Manage change

評估風險 Assess risk

創造有價值的產品 Create work products that provide value for others

7.2.2 實踐的指導原則

分治策略 Divide and conquer，一塊東西只做一件事 Seperation of Concerns, SoCs

利用抽象 Understand the use of abstraction，本質是復雜元素的簡化。

追求一致 Strive for consistency，相似的部分應該保持一致，例如一個頁面展示相似的東西，相似的功能，并用相似的顏色來區分。

注重信息表達 Focus on the transfer of information

模塊化 Build software that exhibits effective modularity：一個模塊一件事，和其他模塊的交互應該盡可能低（高內聚，低耦合）。

巧用模式 Look for patterns：利用設計模式優化模塊。

多角度展示問題和解決方案 When possible, represent the problem and its solution from a number of different perspective：例如，一個需求模型可以面向場景、面向類別、面向行為

軟件需要運維 Remember that someone will maintain the software

7.3 每個框架活動的指導原則

Principles that guide each framework activity
7.3.1 溝通原則，7.3.2 策劃原則，7.3.5 交付原則略

7.3.3 建模原則

首要目的是開發出來不是建模 The primary goal of the software team is to build software, not to create models.

輕量級，不要提前開發現在不需要的需求 Travel light, don't create more models than you need.

盡可能簡化模型 Strive to produce the simplest model thay will describe the problem or the software.

要讓模型能夠適應變化 Build models in a way that makes them amenable to change.

要能夠清晰地說明每個模型的目的 Be able to state an explicit purpose for each model that is created.

軟件要適配對應的系統 Adapt the models you develop to the system at hand.

先把能用的軟件做出來，而不是一開始就追求完美 Try to build useful models, but forget about building perfect models.

只要能表達清楚要干什么，不用對模型的語法太斤斤計較 Don't become dogmatic about the syntax of the model. If it communicates content successfully, representation is secondary.

如果直覺告訴你這個模型可能不對，相信你的直覺并嘗試找到問題。If your instincts tell you a model isn't right even though it seems okay on paper, you probably have reson to be concerned.

獲得及時反饋 Get feedback as soon as you can.

7.3.4 開發原則

Coding Principles

• 準備階段：知道你要解決什么，明確基本的邏輯，選擇一個編程語言和搭建環境，創建單元測試。
• 編程階段：考慮使用結對編程pair programming（兩人一組），選擇合適的數據結構，理解軟件架構并創建接口，讓條件邏輯盡可能簡單，創建循環時要讓它易于測試，變量名要有意義，寫注釋，輸出一些語句方便查看代碼進程。
• 驗證階段：測試代碼流程是否OK，單元測試，重構代碼。
• 測試階段：以找到現在有的和未來可能發生的錯誤為目的。

7.4 工作實踐

軟件工程先驗知識：

接口 Interface

協議和模版 Conventions and templates

分層次Layering對數據和抽象編程都很重要。

算法復雜性 Algorithmic complexity 寫簡單可讀性高的代碼。

哈希 Hashing ：均勻地分布數據。

緩存 Caching：時間和空間要做取舍。

并發 Concurrency

云計算 Cloud Computing

安全 Security

關系型數據庫 Related Databases

八、 理解需求

中文版第七章

8.1 需求工程

需求工程requirement engineering是通過一系列任務和技術來理解需求。

• 起始inception：產品經理定義業務用例，調研市場，可行性分析，明確項目范圍。
• 需求獲取 Elicitation：詢問客戶、用戶和其他人對產品的期望。
• 細化 Elaboration：將需求拓展成一個完善的需求模型。
• 協商 Negotiation：解決需求沖突。
• 規格說明 Specification：文檔、數學模型、圖形模型、使用場景、原型等用來表達產品意義的方式。
• 需求確認 Validation：根據規格說明，保證完成了所有系統需求，如果檢查出錯誤要及時改正，最終產品符合某些標準。
• 需求管理 Requirements management：持續控制、跟蹤需求變更。

8.2 建立根基

• 確認利益相關者（客戶、運營、產品、開發等）Identifying Stakeholders
• 識別多重觀點 Recognizing Multiple Viewpoints
• 協同合作 Working toward Collaboration
• 提出一些破冰的問題 Asking the First Question
• 非功能性需求 Nonfunctional Requirements：質量要求、性能要求、安全要求等
• 可追溯性 Tracebility

8.3 獲取需求

• 協作需求收集 Collaborating Requirements Gathering
• 質量功能部署 Quality Function Deployment, QFD：理解“什么功能對客戶是有價值的”，并部署這些價值。
  常規需求Normal requirements -> 達到了客戶就會滿意；
  期望需求Expected requirements -> 客戶沒說，但是沒有就會不滿；
  興奮需求Exciting requirements -> 超出預期，存在時會讓人更滿意。
• 使用場景/用例 Usage Scenarios：描述人們應該怎么使用系統。
• 獲得產品Elicitation Work Products：工作產品包括：
  （1） 要求和可行性分析
  （2）產品使用范圍
  （3）利益相關者名單
  （4）系統技術環境說明
  （5）需求列表及適用限制
  （6）使用場景
  （7）原型
• 敏捷需求獲取Agile Requirements Elicitation：用“用戶故事”描述需求
• 面向服務的方法 Service-Oriented Methods：將系統看作一系列服務的集合。

8.4 是個用例的例子，略

8.5 建立分析模型（需求模型）

Building the Analysis Model

需求模型的元素 Elements of the Analysis Model

• 基于場景的元素 Scenario-based elements：用戶視角描述系統 如圖8.3
• 基于類的元素 Class-based elements：每個場景包括的一系列對象
• 行為元素 Behavioural elements：系統的行為會對其設計和實現產生影響。可以用狀態圖state diagram來表現系統行為。
  

8.6 溝通需求

中文翻譯版沒有，原版比較啰嗦，和前面的內容挺重復的，略

8.7 監控需求

Requirements Monitoring

五個任務：

分布式debug

運行時檢測 Run-time verification：軟件是否滿足要求specification

運行時驗證run-time validation：是否達到用戶要求

商業活動監控 business activity monitoring ：是否達到業務要求

進化和共同設計evolution and codesign

8.8 驗證需求

內容重復，略

8.9 避免常見性錯誤

(看到這里忍不住說，真不怪大部分人看不下大黑書，真就直接機翻唄，中文書這部分還有個翻譯錯誤。= = )

應避免三個錯誤：對特性、靈活性、功能的過度偏好

• 對功能的偏好 Featuritis：犧牲功能的完整性來追求整體的系統質量。
• 對靈活性的偏好Flexibilitis：過分強調代碼的靈活性，這可能會讓系統很難配置、很難操作。
• 對性能的偏好 Performitis：過分關注系統性能、開銷，例如實現可維護性、可靠性、安全性、安全這些非功能性需求的開銷。

后面幾章會介紹需求建模的常見方法

基于場景的建模

基于類對象的建模

基于行為的建模

九、需求建模：基于場景的建模

中文版第八章

9.1 需求分析

9.1.2 總體目標和原理

系統描述 -> 需求模型 -> 設計模型

需求模型必須實現三個主要目標：

描述客戶需要什么？

為軟件設計奠定基礎

定義軟件可實現的一組需求

9.1.2 分析的經驗原則

和之前的原則都差不多，全書都在反復說這些原則。

• 建模的時候，應該關注可見的需求，建立抽象模型，而不要陷入細節。
• 每個元素都是為需求服務的。
• 基礎結構和其他非功能性的需求應該在設計階段再考慮。
• 最小化整個系統內的關聯。
• 需求模型是為利益相關者帶來價值的。
• 簡潔（KISS原則，Keep it Simple and Stupid）

9.1.3 域分析

9.1.4 需求建模的方法

• 結構化分析 Structured analysis：定義數據對象的屬性和關系，定義數據在系統中如何流動。
• 面向對象分析 object-oriented analysis：定義對象和他們之間的協作方式，UML和統一過程UP就是面向對象的分析方法。

(DFD: 數據流圖 data flow diagrams)

9.2 基于場景建模

用UML進行需求建模，需要先創建用例、活動圖、泳道圖。use cases, activity diagrams, and swimlane diagrams

用例

• 創建初始用例：就是希望能實現什么功能
• 完善初始的用例：討論這些功能的細節，比如發生某些條件觸發什么結果、有什么限制、有什么錯誤等。
• 編寫正式用例
  

UML模型

??

9.3 UML模型

9.3.1 活動圖

activity diagram

類似于流程圖，

• 圓角矩形：功能
• 箭頭：流
• 菱形：分支
• 水平線：并行發生的活動

9.3.2 泳道圖

Swimlane diagram

泳道圖是活動圖的一種變形，將行為按對象分類。

十、需求建模：基于類的方法（面向對象）

中文版第九章

• 類對象：學生、老師、人
• 類的屬性：身高、體重
• 類的方法：喜、怒、哀、樂
• 類-職責-協作者建模（Class - Responsibility - Collaborator, CRC）
• 關聯與依賴
• 包

10.1 類 10.2 屬性 10.3 方法

10.4 CRC建模

建立CRC索引卡：

職責要求：
【實際上就是“高內聚，低耦合”】

把工具類單獨出來

職責應該盡可能具有普遍性，容易復用

相關屬性和方法應該放在同一個類里——封裝 Encapsulation，某個事物的信息應該局限于一個類里，而不是分布在多個類中

共有方法可以提出來

類之間的協作：
類之間的三種通用關系：A屬于B（A is part of B），A需要從B中獲取信息（A has knowledge of B），A依賴于B（A depends upon B，比如頭和身子必須連接）

10.5 關聯與依賴

依賴關系：客戶-服務器 client-server relationship

10.6 包

更大的包含關系

十一、需求建模：基于行為的建模

11.1 生成行為模型

理解交互邏輯

理解事件如何與對象交互

為每個用例生成序列

創建系統狀態圖 state diagram

檢查行為模型的準確性和一致性

11.2 識別用例事件

就是把客戶說的一大堆東西抽象成【什么東西】要【做什么】

11.3 狀態表達

系統執行功能時每個類的狀態

系統執行功能時從外部觀測到的系統狀態

類的狀態圖

順序圖

總結

以上是生活随笔為你收集整理的软件工程概念总结-期末重点-(说人话版 简单中文+英文关键词)-拆书-第二部分建模（原书第7-11章）-罗杰S普莱斯曼的全部內容，希望文章能夠幫你解決所遇到的問題。

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