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

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

七、實(shí)踐原則

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

7.2 核心原則

7.2.1 過程的指導(dǎo)原則

敏捷 Be Agile

注意每一步的質(zhì)量 Focus on quality at every step

適應(yīng)變化 Be ready to adapt

建立有效的團(tuán)隊(duì) Build effective team

建立溝通合作機(jī)制 Establish mechanisms for communication and coordination

管理變化 Manage change

評(píng)估風(fēng)險(xiǎn) Assess risk

創(chuàng)造有價(jià)值的產(chǎn)品 Create work products that provide value for others

7.2.2 實(shí)踐的指導(dǎo)原則

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

利用抽象 Understand the use of abstraction，本質(zhì)是復(fù)雜元素的簡(jiǎn)化。

追求一致 Strive for consistency，相似的部分應(yīng)該保持一致，例如一個(gè)頁面展示相似的東西，相似的功能，并用相似的顏色來區(qū)分。

注重信息表達(dá) Focus on the transfer of information

模塊化 Build software that exhibits effective modularity：一個(gè)模塊一件事，和其他模塊的交互應(yīng)該盡可能低（高內(nèi)聚，低耦合）。

巧用模式 Look for patterns：利用設(shè)計(jì)模式優(yōu)化模塊。

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

軟件需要運(yùn)維 Remember that someone will maintain the software

7.3 每個(gè)框架活動(dòng)的指導(dǎo)原則

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

7.3.3 建模原則

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

輕量級(jí)，不要提前開發(fā)現(xiàn)在不需要的需求 Travel light, don't create more models than you need.

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

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

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

軟件要適配對(duì)應(yīng)的系統(tǒng) Adapt the models you develop to the system at hand.

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

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

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

獲得及時(shí)反饋 Get feedback as soon as you can.

7.3.4 開發(fā)原則

Coding Principles

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

7.4 工作實(shí)踐

軟件工程先驗(yàn)知識(shí)：

接口 Interface

協(xié)議和模版 Conventions and templates

分層次Layering對(duì)數(shù)據(jù)和抽象編程都很重要。

算法復(fù)雜性 Algorithmic complexity 寫簡(jiǎn)單可讀性高的代碼。

哈希 Hashing ：均勻地分布數(shù)據(jù)。

緩存 Caching：時(shí)間和空間要做取舍。

并發(fā) Concurrency

云計(jì)算 Cloud Computing

安全 Security

關(guān)系型數(shù)據(jù)庫 Related Databases

八、 理解需求

中文版第七章

8.1 需求工程

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

• 起始inception：產(chǎn)品經(jīng)理定義業(yè)務(wù)用例，調(diào)研市場(chǎng)，可行性分析，明確項(xiàng)目范圍。
• 需求獲取 Elicitation：詢問客戶、用戶和其他人對(duì)產(chǎn)品的期望。
• 細(xì)化 Elaboration：將需求拓展成一個(gè)完善的需求模型。
• 協(xié)商 Negotiation：解決需求沖突。
• 規(guī)格說明 Specification：文檔、數(shù)學(xué)模型、圖形模型、使用場(chǎng)景、原型等用來表達(dá)產(chǎn)品意義的方式。
• 需求確認(rèn) Validation：根據(jù)規(guī)格說明，保證完成了所有系統(tǒng)需求，如果檢查出錯(cuò)誤要及時(shí)改正，最終產(chǎn)品符合某些標(biāo)準(zhǔn)。
• 需求管理 Requirements management：持續(xù)控制、跟蹤需求變更。

8.2 建立根基

• 確認(rèn)利益相關(guān)者（客戶、運(yùn)營(yíng)、產(chǎn)品、開發(fā)等）Identifying Stakeholders
• 識(shí)別多重觀點(diǎn) Recognizing Multiple Viewpoints
• 協(xié)同合作 Working toward Collaboration
• 提出一些破冰的問題 Asking the First Question
• 非功能性需求 Nonfunctional Requirements：質(zhì)量要求、性能要求、安全要求等
• 可追溯性 Tracebility

8.3 獲取需求

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

8.4 是個(gè)用例的例子，略

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

Building the Analysis Model

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

• 基于場(chǎng)景的元素 Scenario-based elements：用戶視角描述系統(tǒng) 如圖8.3
• 基于類的元素 Class-based elements：每個(gè)場(chǎng)景包括的一系列對(duì)象
• 行為元素 Behavioural elements：系統(tǒng)的行為會(huì)對(duì)其設(shè)計(jì)和實(shí)現(xiàn)產(chǎn)生影響。可以用狀態(tài)圖state diagram來表現(xiàn)系統(tǒng)行為。
  

8.6 溝通需求

中文翻譯版沒有，原版比較啰嗦，和前面的內(nèi)容挺重復(fù)的，略

8.7 監(jiān)控需求

Requirements Monitoring

五個(gè)任務(wù)：

分布式debug

運(yùn)行時(shí)檢測(cè) Run-time verification：軟件是否滿足要求specification

運(yùn)行時(shí)驗(yàn)證run-time validation：是否達(dá)到用戶要求

商業(yè)活動(dòng)監(jiān)控 business activity monitoring ：是否達(dá)到業(yè)務(wù)要求

進(jìn)化和共同設(shè)計(jì)evolution and codesign

8.8 驗(yàn)證需求

內(nèi)容重復(fù)，略

8.9 避免常見性錯(cuò)誤

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

應(yīng)避免三個(gè)錯(cuò)誤：對(duì)特性、靈活性、功能的過度偏好

• 對(duì)功能的偏好 Featuritis：犧牲功能的完整性來追求整體的系統(tǒng)質(zhì)量。
• 對(duì)靈活性的偏好Flexibilitis：過分強(qiáng)調(diào)代碼的靈活性，這可能會(huì)讓系統(tǒng)很難配置、很難操作。
• 對(duì)性能的偏好 Performitis：過分關(guān)注系統(tǒng)性能、開銷，例如實(shí)現(xiàn)可維護(hù)性、可靠性、安全性、安全這些非功能性需求的開銷。

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

基于場(chǎng)景的建模

基于類對(duì)象的建模

基于行為的建模

九、需求建模：基于場(chǎng)景的建模

中文版第八章

9.1 需求分析

9.1.2 總體目標(biāo)和原理

系統(tǒng)描述 -> 需求模型 -> 設(shè)計(jì)模型

需求模型必須實(shí)現(xiàn)三個(gè)主要目標(biāo)：

描述客戶需要什么？

為軟件設(shè)計(jì)奠定基礎(chǔ)

定義軟件可實(shí)現(xiàn)的一組需求

9.1.2 分析的經(jīng)驗(yàn)原則

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

• 建模的時(shí)候，應(yīng)該關(guān)注可見的需求，建立抽象模型，而不要陷入細(xì)節(jié)。
• 每個(gè)元素都是為需求服務(wù)的。
• 基礎(chǔ)結(jié)構(gòu)和其他非功能性的需求應(yīng)該在設(shè)計(jì)階段再考慮。
• 最小化整個(gè)系統(tǒng)內(nèi)的關(guān)聯(lián)。
• 需求模型是為利益相關(guān)者帶來價(jià)值的。
• 簡(jiǎn)潔（KISS原則，Keep it Simple and Stupid）

9.1.3 域分析

9.1.4 需求建模的方法

• 結(jié)構(gòu)化分析 Structured analysis：定義數(shù)據(jù)對(duì)象的屬性和關(guān)系，定義數(shù)據(jù)在系統(tǒng)中如何流動(dòng)。
• 面向?qū)ο蠓治?object-oriented analysis：定義對(duì)象和他們之間的協(xié)作方式，UML和統(tǒng)一過程UP就是面向?qū)ο蟮姆治龇椒ā?/li>

(DFD: 數(shù)據(jù)流圖 data flow diagrams)

9.2 基于場(chǎng)景建模

用UML進(jìn)行需求建模，需要先創(chuàng)建用例、活動(dòng)圖、泳道圖。use cases, activity diagrams, and swimlane diagrams

用例

• 創(chuàng)建初始用例：就是希望能實(shí)現(xiàn)什么功能
• 完善初始的用例：討論這些功能的細(xì)節(jié)，比如發(fā)生某些條件觸發(fā)什么結(jié)果、有什么限制、有什么錯(cuò)誤等。
• 編寫正式用例
  

UML模型

??

9.3 UML模型

9.3.1 活動(dòng)圖

activity diagram

類似于流程圖，

• 圓角矩形：功能
• 箭頭：流
• 菱形：分支
• 水平線：并行發(fā)生的活動(dòng)

9.3.2 泳道圖

Swimlane diagram

泳道圖是活動(dòng)圖的一種變形，將行為按對(duì)象分類。

十、需求建模：基于類的方法（面向?qū)ο?#xff09;

中文版第九章

• 類對(duì)象：學(xué)生、老師、人
• 類的屬性：身高、體重
• 類的方法：喜、怒、哀、樂
• 類-職責(zé)-協(xié)作者建模（Class - Responsibility - Collaborator, CRC）
• 關(guān)聯(lián)與依賴
• 包

10.1 類 10.2 屬性 10.3 方法

10.4 CRC建模

建立CRC索引卡：

職責(zé)要求：
【實(shí)際上就是“高內(nèi)聚，低耦合”】

把工具類單獨(dú)出來

職責(zé)應(yīng)該盡可能具有普遍性，容易復(fù)用

相關(guān)屬性和方法應(yīng)該放在同一個(gè)類里——封裝 Encapsulation，某個(gè)事物的信息應(yīng)該局限于一個(gè)類里，而不是分布在多個(gè)類中

共有方法可以提出來

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

10.5 關(guān)聯(lián)與依賴

依賴關(guān)系：客戶-服務(wù)器 client-server relationship

10.6 包

更大的包含關(guān)系

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

11.1 生成行為模型

理解交互邏輯

理解事件如何與對(duì)象交互

為每個(gè)用例生成序列

創(chuàng)建系統(tǒng)狀態(tài)圖 state diagram

檢查行為模型的準(zhǔn)確性和一致性

11.2 識(shí)別用例事件

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

11.3 狀態(tài)表達(dá)

系統(tǒng)執(zhí)行功能時(shí)每個(gè)類的狀態(tài)

系統(tǒng)執(zhí)行功能時(shí)從外部觀測(cè)到的系統(tǒng)狀態(tài)

類的狀態(tài)圖

順序圖

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。