軟工視頻之軟體分析

學習有點慢慢，15集的視頻將近看了十天。不過好在看完了，記錄也還能接受。要不，又是做無用功了。好了，廢話少說，看我的總結吧。

一般，對於一個新名詞，我們都會怎麼思考它。大多數人一般都會想它是什麼、有什麼特點（意義）。我們來瞭解下神奇的軟工世界吧。

軟體工程（Software Engineering，簡稱SE），是一門研究用工程化方法構建和維護有效、實用的和高品質的軟體的學科，就是和軟體有關的工程，而軟體是什麼，軟體是系統中與硬體相互依存的另一部分，包括程式、資料、及其相關文檔的完整集合。

那麼，問題又來了，程式、資料、文檔又是啥。

程式：按設計的功能和效能要求的指令序列。資料：正常操作資訊的資料結構。文檔：程式開發、維護和使用有關的額圖文材料

 

其實軟體工程沒有具體的定義，不同公司有不同的解釋：

Boehm：運用現代科學技術知識來設計並構造電腦程式及為開發、運行和維護程式必需的相關檔案資料

IEEE：軟體工程師開發、運行、維護和修複軟體的系統方法

Fritz Bauer：建立並使用完善的工程化原則，以較經濟的手段獲得能在實際機器上有效啟動並執行可靠軟體的一系列方法

 

什麼特點。

1. 邏輯實體，非物理實體（抽象性）

2. 生產與硬體不同，開發過程中無明顯製造過程

3. 運行和使用期間，沒有硬體的機械磨損，老化問題

4. 開發和運行手系統限制，有不同程度的依賴性

5. 至今未完全擺脫手工操作

6. 本身複雜（實際問題，邏輯結構）

7. 成本昂貴

8. 很多設計社會因素（智慧財產權等）

 

其他方面瞭解：

分類情況有很多種。依據功能劃分分為系統軟體、支撐軟體、應用軟體；按規模劃分，有微型、小型、中型、大型、甚大型、計大型之分；還有按工作方式、服務物件、使用頻率、失效影響等區分。

 

軟體工程基本原理：

1.用分階段的生存周期計劃嚴格管理

2.堅持進行階段評審

3.實行嚴格的產品控制

4.採用現代程式設計技術

5.結果應能清楚地審查

6.合理安排軟體開發小組的人（少而精）

7.承認不斷改進軟體工程實踐的必要性

 

軟體工程的項目基本目標是：

付出較低的開發成本

達到要求的軟體功能

取得較好的軟體效能

開發的軟體易於移植

需要較低的維護費用

能按時完成開發工作，即時交付使用

 

軟體工程原則：分解性、獨立性、一致性、確定性

  生存周期（六個階段）：（從開發至被廢棄）問題定義、可行性研究、需求分析、設計、編碼、測試、運行與維護；三大階段：軟體計劃階段、開發階段和維護階段

  軟體開發模型，例如瀑布模型、B模型、快速原型模型（RapidPrototyping Model）、演化模型、漸增模型、螺旋模型等。

 

通過上面瞭解了軟體工程，那麼我們可能會認為做個軟體有啥的，做出來不就行了，那麼我們看看具體怎麼做吧。

如果直接就開始軟體建立，那為啥還要叫軟體工程，直接叫編程不就完了。其實軟體工程師工程化的，需要考慮方方面面，不僅要建立軟體，還要為軟體作說明，以及維護，讓非專業的人知道怎麼使用和維護軟體，這才是重點。那麼讓非專業人士瞭解，就需要多種文檔的建立啦。由於視頻我還沒有看完，所以只能先介紹我瞭解的文檔了。

文檔也就是軟體規格說明書，用來規定軟體的功能與運行環境，滿足規格的條件和完成客戶需求。軟體規格說明書的特點：易理解性、可見度、可支援性、可接受性、可靠性、健壯性、可維護性、速度。

首先，第二章介紹的是可行性研究報告。

 

可行性研究步驟：

複查系統規模和目標

研究當前正在使用的系統

到處新系統的高層邏輯模型

向使用者推薦建議方法

推薦行動方針，做出關鍵性的決定

草擬開發計劃，寫出可行性論證報告

提交上級和專家審查

 

 

軟體計劃內容

軟體功能規模，軟體能力對硬體的要求，介面介面的性質和複雜性等

環境資源：

人力資源，在不同的階段對不同的人員的要求

硬體，包括目標機器，及其他機器

軟體，包括職支撐軟體和使用軟體

制定進度表，包括交付日期，如何組織分配力量

軟體成本，只要雙方都能接受即可（估算）

資源效能描述：要什麼樣水平的人，什麼樣的功能效能的硬體和軟體

 

價格評估

影響因素：人口、產品、工程、資源

1.參數化演算法

C=f（Vi);C是軟體價格，Vi所選取的影響軟體價格的獨立參數

2.程式碼（LOC）價格估算技術

有關參數：原始碼行，是軟體產品計量單位，不包括注釋，作業命令……

  勞動量，一個人蔘加勞動時間的長短

  軟體生產率，單位勞動時間完成軟體的數量

  LOC計算方法，對設計的系統進行功能分解，根據曆史資料和經驗選擇每個軟體功能塊的LOC價格

3.任務分解方法

思想：首先把軟體開發工程分解為若干個相對獨立的任務，再分別估計每個開發工作單位的成本，最後累加得出總成本

4.自動估計成本方法

減輕人的勞動但要有大量的經驗資料做基礎，要有狼嚎資料庫系統支援

 

成本/效益分析 

成本估計方法：自頂向下估價、自底向上估價

成本/效益分析法：

運行費：取決與系統的操作費用和維護費用

系統的經濟效益：因新系統而增加的收入+新系統節省的運行費；系統經濟效益一般在整個生存周期內都存在

 

項目開發計劃

引言：編寫目的、項目背景、定義、參考資料

項目描述：工作內容、條件與限制、產品、運行環境、服務、驗收標準

實施計劃：任務分解、進度、預算、關鍵問題

人員組織及分工

交付期限

專題計劃要點

 

第三章介紹的是軟體需求

 

任務:深入描述軟體的功能和效能

確定軟體設計的約束和軟甲同其他系統元素的介面細節

定義軟體的其他有效性需求（藉助於當前系統的邏輯模型到處目標系統的邏輯模型，解決目標系統的“做什麼”的問題）

  需求包括：功能需求、效能需求、環境需求、可靠性需求、安全保密要求、使用者介面需求、資料使用需求、成本消耗需求、開發進度需求、預先估計以後系統可能達到的目標

 

方法共性：

支援資料域分析的機制

功能表示的方法

介面的定義

問題分解的機制以及對抽象的支援

邏輯視圖和物理視圖

系統抽象模型

 

軟體需求分析的原則

需要能夠表達和理解問題的資訊域和功能域

要能以層次化得方式對問題進行分解和不斷細化

 

軟體需求規格說明的原則

從現實中分離功能描述要“做什麼”而不是“怎麼實現”

要求使用面向處理的規格說明語言（或稱系統定義語言）

 

軟體需求方法

由對軟體問題的資訊域和功能域的系統分析過程及其表示方法

大多是由資訊驅動（資訊流即資料流，不包括控制）

 

結構化分析方法

面向資料流

使用資料處理類型軟體

 

資料流圖（DFD）：通過資料流向表達軟體需求

資料流圖的作用：

1.系統分析員用這種工具可以自頂向下分析系統資訊流程

2.可在圖上畫出需要電腦處理的部分

3.根據資料存貯（zhu），進一步作資料分析，向資料庫設計過渡

4.根據資料流向，定出存取方式

5.對應一個處理過程，用相應的語言、判定表等工具表達出處理方法

 

資料流圖的優缺點：

1. 總體概念強，每一層都明確強調“幹什麼”，“需要什麼”，“給什麼”

2.可以反映出資料的流向和處理過程

3.由於自頂向下分析，容易及早發現系統各部分的邏輯錯誤，也容易修正

4.容易與電腦處理相對照

5.不直觀，一般都要在作業流程分析的基礎上加以概括、抽象、修正來得到

6.如果沒有電腦系統協助的話，人工繪製太麻煩，工作量較大

 

檢查和修改資料流圖的原則

1.資料流圖上所有圖形符號只限於前述四種基本圖形元素

2.資料流圖的主圖必需包括前述四種基本元素，缺一不可

3.每個加工至少有一個輸入資料流和一個輸出資料流

4.在資料流圖中，需按層給加工框編號。編號表明該加工所處層次及上下層的親子關係

5.規定任何一個資料流子圖必需與它上一層的一個加工對應，兩者的輸入資料流和輸出資料流必需一致

6.圖上每個元素都必須有名字

7.資料流圖中不可夾帶控制流程

8.初畫圖時可以忽略瑣碎的細節，以集中精力於主要資料流

9.不許有交叉層疊的情況

 

資料詞典

配合資料流圖，清楚地表達資料處理的要求

（主）詞條描述——對圖形元素定義（名字，別名或編號，分類，描述，定義，位置，其它等）

 

用於寫加工邏輯說明的工具：

結構化英語，是一種介於自然語言和形式化語言之間的語言，由英語命令動詞，資料詞典中定義的名字，有限的自訂詞，邏輯關係詞IF_THEN_ELSE、CASE_OF、WHILE_DO、REPEAT_UNTIL等組成；語言的本文用基本控制結構進行分割，加工的操作用自然語言短語來表示；其基本控制結構有三種：簡單陳述句結構；重複結構；判定結構

 

判定表（將各種邏輯通過列表的方式列舉出來）

先條件後動作最後最佳化；最佳化先從動作開始。

描述加工的基本說明，適用多個邏輯的，清晰描述複雜的條件組合與應該做的動作對應關係；但不能表述不確定的加工處理，重複迴圈的加工處理

判定樹（通過樹狀圖表示邏輯組合）

用來表達加工邏輯的一種工具，有時比判定表更直觀

優點：形式簡單，直觀，判定表的資料來源數多餘兩個的時候，判定表寫起來別較多，判定樹比較形象

不足：簡潔度不如判定表，越接近樹葉的地方越多

其它還有I/P/O圖、層次方框圖、PHA圖等，不做詳細介紹。

 

工具的選擇方式： 

1.從機器的可讀性來講：結構化英語、判定表優於判定樹

2.從描述的直觀性來講：判定樹較好

3.對於邏輯驗證和最佳化能力：判定表較好（所有的可能性都列出來）

 

原型化方法

開發初期，完整準確的規格說明不易得到，使用者往往對系統僅一個模糊想法，難完全準確表達系統全面要求

軟體原型的分類：

探索型	探索需求分析
實驗型	取得資料
進化型（演化型或漸進型）	以開始的目標系統為核心不斷完善

最常用的動態分析方法

狀態遷移圖是描述系統的狀態如何相應外部的訊號進行推移的一種圖形表示，圓圈“○”表示可得到的系統狀態，箭頭“→”表示從一種狀態向另一種狀態的遷移，“。”表示轉移即系統的事件。優點：單純性，機械地分析許多情況，易機那裡分析工具，如可轉換為狀態遷移表，處理功能強；狀態之間的關係描述直觀（不能有交叉不清）

時序圖（Sequence Diagram），亦稱為順序圖表或循序圖或順序圖，是一種UML互動圖。它通過描述對象之間發送訊息的時間順序顯示多個對象之間的動態協作。它可以表示用例的行為順序，當執行一個用例行為時，時序圖中的每條訊息對應了一個類操作或狀態機器中引起轉換的觸發事件。

Petri網簡稱PNG（Petri Net Graph），廣泛應用於硬體與軟體系統的開發中，適用於描述與分析相互獨立、協同操作的處理系統，即並發執行的處理系統；標記，或稱令牌（token），是表明系統當前處於什麼狀態的標誌

第四章介紹的是軟體概要設計說明書和詳細設計說明書

  即第四章描述的是軟體的設計。

 概要設計的過程步驟：

S1:設計系統方案

S2：選取一組合理的方案

S3：推薦最佳實施方案

S4：功能分解

S5： 軟體結構設計

S6：資料庫設計、檔案結構的設計

S7：制定測試計劃

S8：編寫概要設計文檔

S9：審查與複審概要設計文檔

 

軟體設計的概念與原則

1.  將軟體劃分成若干獨立成分的依據

2.  怎樣表示不同的成分內的功能細節和資料結構

3.  怎樣同一衡量軟體的技術品質

軟體設計的目標和任務

根據用資訊域表示的軟體需求，以及功能和效能需求，進行

資料設計

系統結構設計

過程設計

注意：一般先概念設計，後詳細設計

 

軟體設計的過程：

制定規範

軟體系統結構的總體設計

處理方式設計

資料結構設計

可靠性設計（品質設計）

編寫概要設計階段的文檔（概要設計說明書和資料庫的說明書、完善使用者手冊）

概要設計評審

 

 

軟體設計基礎：

自頂向下，逐步細化

體繫結構自頂向下方式，各個層次過程細節和資料細節逐層細化

軟體結構

模組結構和資料的結構

把一個問題分解為多個子問題，然後非別解決子問題（子問題開發工作量之和小於原問題開發工作量【數學問題】）

程式結構，分為兩種

樹狀結構（階層）：

層次分明，只有一個節點，沒有副節點，多個子節點（兄弟之間沒有什麼聯絡，只與父節點有關）；縱向叫深度，橫向叫快讀，每個節點輸入叫扇入，輸出叫扇出

網狀結構：

任何兩個節點可以建立聯絡，層次模糊，不易看出根節點

結構圖（S/C圖）

反映程式中模組之間的層次調用關係和聯絡

模組化

能夠把一個大而複雜的軟體系統劃分成易於理解的比較單純的模組結構

1.模組

矩形框表示，模組名，各個模組名不能相同

模組名（以功能、功能縮寫、已定義模組、子程式或過程），一般以功能命名，功能非單一以主要功能命名

2.模組的調用關係和介面

3.模組間的資訊傳遞

傳入和傳出資訊必不可少，要表明資訊名稱和特徵

傳遞資訊較多時要描寫主要資訊

4.表示模組A有條件地調用另一個模組B

菱形框表示，標記點一定要在上一模組，盡量也要寫上條件

 

弧形的表示迴圈調用，右箭頭的表明迴圈調用的方向（順序）

 

程式的系統結構圖

小的結構圖深度大概5-7層，中型十幾層或10層，複雜型幾十層，反映問題的複雜性

寬度指任意一層的模組書，寬度越大，複雜度越高

扇出太多表明受其他模組影響較大，扇出不要太多，一般2-5，不要超過9-10，減小扇出，勢必要增加深度

扇入表示驅動模組（上一個模組）有多少，扇入一般1-5，要控制數量

一個好的系統結構圖應該呈現“甕”型

抽象化

軟體系統進行模組設計時，可有不同的抽象層次，即分解系統；

控制分解速度

過程：分層抽象，逐漸細化；

根據任務需求進一步細化；

程式過程抽象（編程階段）；

資料抽象，在不同層次上描述資料對象的細節，定義與該資料對象相關的操作

資訊隱蔽

劃分模組的時候（定義層次），模組內的資料發生變化的時候，盡量不要影響其他相關模組或少影響，即不允許其他的模組使用本模組

 

 

模組的獨立性

模組的基本屬性：

功能：描述該模組實現什麼功能

邏輯：描述模組內部怎麼做

狀態：該模組使用時的環境和條件

獨立性是指軟體系統中每個模組只涉及軟體要求的具體的子功能

一般採用兩個準則度量模組獨立性，即模組間耦合和模組內聚

 

模組間的耦合

 

獨立性越強，耦合性越低

非直接耦合（Nondirect Coupling）

兩模組之間沒有直接關係

資料耦合（Data Coupling）

如果一個模組模組訪問另一個模組時，彼此之間是通過簡單資料參數（不是控制參數、公用資料結構或外部變數來交換輸入、輸入資訊的）

標記耦合（Stamp Coupling）

如果一組模組通過參數表傳遞記錄資訊，就是標記耦合

控制耦合（Control Coupling）（中耦合）

如果一個模組通過傳送開關、標誌、名字等控制資訊，明顯地控制選擇另一模組的功能

外部耦合（External Coupling）

一組模組都訪問同一全域簡單變數而不是同一全域資料結構，而且不是通過參數表傳遞該全域變數的資訊，較強耦合

公用耦合（Common Coupling） 若一組模組都訪問同一個公用資料環境，較強耦合有兩種情況：鬆散公用耦合和緊密公用耦

（a）A模組寫入的資料（B模組不需要的）可能匯入到B模組

（b）兩個模組都能修改資料，容易造成混亂，盡量避免

  合理使用公用耦合，可減少使用記憶體量

 

內容耦合（Content Coupling）

模組內聚

內聚性越高，模組獨立性越強。內聚是可以互相轉換的。

 

功能內聚（Functional Cohesion）

一個模組中各個部分都是完成某一具體功能必不可少的組成部分，是不可分割的，最理想的模組內聚

資訊內聚（Informational Cohesion）

也稱（順序內聚），模組完成多個功能，各個功能都在統一資料結構上操作，每一項功能有一個唯一的進入點，較強內聚

通訊內聚（Communication Cohesion）

如果一個模組內各功能部分都使用了相同的輸入資料，或產生相同的輸出資料

過程內聚（Procedural Cohesion）

使用流程圖做為工具設計程式時，把流程圖中的某一部分划出來組成模組

時間內聚（Classical Cohesion）

也叫瞬間內聚

1.各個模組的執行與時間有關

2.通常要求所有功能必須在同一時間段內執行；

3.動作僅執行一次，往往影響其他模組；

4.模組內各部分內聚的時間關係反映了某些實質問題

邏輯內聚（Logical Cohesion）

把集中相關的功能組合在一起

巧合內聚（Coincidental Cohesion）

各部分之間沒有聯絡，或者即使有聯絡，這種聯絡也很鬆散

 

結構化設計方法

首先研究、分析和審查資料流圖；然後根據資料流圖決定問題的類型，典型類型：變換型和事務型

 

系統結構圖中的模組

傳入模組

輸入物理資料流，傳出邏輯資料流，左斜

傳出模組

傳出邏輯輸出資料流（一般），右斜

變換模組

從上級模組取得資料，經過變換後在返還上級模組

協調模組

對所有下屬模組進行協調與管理

變換型系統結構圖（一條線）,過程大致分為三步：取得資料，變換資料和給出資料

事務型系統結構圖（有分支）,接受一項事務，根據交易處理的特點和性質，選擇指派一個適當的處理單元，然後給出結果

變換分析

方法四步組成：

1.重畫資料流圖

2.區分有效（邏輯）輸入、有效（邏輯）輸出和中心變換部分

3.進行一級分解，設計上層模組

4.進行二級分析，設計輸入、輸出和中心變換部分的中、下層模組

 

中心交換就是主模組位置

1.      在選擇木塊設計的次序時，須對一個木塊的全部直屬員工模組都設計完成

2.      在設計下層模組時，應考慮模組的耦合和內聚問題

3.      使用“黑箱”技術：在設計當前模組時，先把這個模組的所有下層模組定義成“黑箱”

4.      在模組劃分時，一個模組的直屬員工模組一般在5個左右（調用的模組）

5.      如果出現以下情況，就停止模組的功能分解：

6.    當木塊不能再細分為明顯的子任務時；