【系統分析師之路】第六章 需求工程記憶敲出(Part2)

【系統分析師之路】第六章 需求工程記憶敲出(Part2)

1. 需求分析的概念

在需求獲取過程之後，緊接着要做的就是需求分析和建模的過程。
需求分析包括了結構化分析和麪向對象分析兩種，隨着技術的不斷髮展和麪向對象開發技術的普及，面向對象需求分析技術逐漸在取代相對比較老的結構化需求分析。

2. 結構化需求分析的概念

結構化需求分析主要是建立三大模型：功能模型，行爲模型和數據模型。
這三個模型分別對應三種圖：DFD數據流圖，狀態遷移圖，ER實體聯繫圖。
在這三個模型的中間，有一箇中間結點就是數據字典。
結構化時代最重要的兩個流：數據流和控制流。

3. 數據字典的概念

數據字典是用來做數據的解釋說明工作的。
不管在結構化還是在面向對象的需求分析過程中，數據字典就是作爲支撐模型的存在。
數據字典具體用來描述什麼內容呢？從DFD圖中去聯想，數據字典可以描述數據加工，外部實體，數據流，數據元素，數據存儲，數據結構等信息。
比如在DTD圖中，我們要對【註冊請求】這個數據流具體包含哪些內容進行詳細的說明，這個時候就是數據字典登場的時候了。

4. 用例圖中的弱實體概念

它相當於依附某個實體的實體。
比如員工實體包括了經理和服務員，那麼我們就說經理實體和服務員實體就是員工實體的弱實體。
站在數據模型的視角，不管是經理還是服務員，都保存在一個員工表中，使用弱實體指示爲了表現和單獨討論的時候方便罷了。

5. 數據流圖的概念

DFD圖強調自頂向下逐步求精的設計方針。
它的最概略的圖就叫做頂層圖，0層圖是頂層圖的詳細描述，而1層圖又是0層圖的詳細描述，這樣從頂層到底層實現了逐步細化求精。
DFD圖遵循平衡原則。0層圖和1層圖在輸入輸出中應該是一樣的，這叫做平衡原則，但1層圖是0層圖的細化。
如果在數據流圖中，摳掉某些線上的數據流的名字讓你補充的時候，可以運用平衡原則來填充。因爲根據原理任何一個輸入輸出都應該是平衡的。
自頂向下逐步分解，其實分解的就是數據流圖中的加工。

6. 數據流圖的圖形表達

DFD圖中由四個元素組成：加工，數據流，數據存儲，外部實體。
數據流是用實線來表示，加工使用圓圈來表示，數據存儲使用兩根平行線，比較直觀，而外部實體使用方框來表示。
外部實體其實和UML用例圖中的小人很接近，而加工和用例圖中的橢圓型比較接近，DFD中的兩根平行線，將來就可以用ER圖將它具體化。

7. 面向對象分析的概念

面向對象分析的英文爲Object-Oriented Analysis，按照面向對象的思想去分析業務需求。
進行模塊化的處理，描述問題的本質，區別每個問題的不同點相同點，確定問題中的對象。
面向對象方法的系統分析和系統設計之間界限已經不明顯了。UML既可以用在分析階段也可以用在設計階段。
面向對象分析的任務包括:
1.建模系統功能
2.發現並確定業務對象
3.組織對象並確定對象之間的關係
它的主要任務就是發現對象並進行篩選。

8. 結構化需求分析與面向對象分析的區別

結構化強調的是對業務現狀和方法進行分析；而OOA則是使用面向對象的思想對建立所需要的素材，並對其歸類和整理的過程。
面向對象分析最大的優點就是強調了複用，快速適應需求的變化而進行調整，還有更加方便用戶的參與，還能幫助我們系統分析師加強對問題域和系統責任的理解。
UML中的用例圖，順序圖等就是作面向對象分析工作的產物；數據流圖，ER圖，狀態圖是結構化需求分析的產物。

9. 面向對象分析中的三個類的概念

在面向對象世界中，提到了三個類：實體類，控制類，邊界類。
實體類對應的是ER圖中的數據模塊，一般用在信息系統的內部；
通過用例圖可以找到，系統和系統外部角色之間的交互，邊界類就是定義了外部實體訪問信息系統內部的一個接口類；
有了接口類和實體類，他們兩者之間是怎麼聯繫在一起的呢?於是就需要有銜接接口類和實體類的類：也就是控制類；
實體類：是一個在地面的球的圖形表示;在靜態圖中的類名上面，有<< entity >>這個標識。
控制類：一個類似於蘋果的圖形表示;在靜態圖中的類名上面，有<< control >>這個標識。
邊界類：一個黏在牆壁上的圓球的圖形表示;在靜態圖中的類名上面，有<< boundary >>這個標識。

• 邊界類：用戶界面類，系統接口類，設備接口類都屬於邊界類
  
• 控制類：控制類的設計與用例實現有着很大的關係，一個用例可能對應多個控制類對象
  -
• 實體類：用於對必須存儲的信息和相關行爲建模的類
  

10. 需求規格說明書與項目範圍說明書的區分

SRS需求規格說明書是用來定義項目的需求的，經過批准之後的SRS就可以形成需求基線。
項目範圍說明書是用來對產品或項目詳細的範圍進行描述。它和WBS，WBS詞典共同構成了項目範圍的基準。
我們可以根據SRS也就是需求基線作爲輸入，做成相應的範圍說明書。
需求基線變化了，那麼項目範圍說明書必然要更新；如果項目範圍基準發生變化，SRS不一定會發生變化。

11. 面向對象的多態（Polymorphism）

多態是同一個行爲具有多個不同表現形式或形態的能力。 多態就是同一個接口,使用不同的實例而執行不同操作。
多態往往需要使用高層類的指針去指向低層類的對象，然後進行統一化的的操作。
比如一個動物類，貓類和狗類繼承了動物類，它們都有"叫"這個Function，對於動物類來說，"叫"是他們的共同的類。
而小貓喵喵叫，小狗汪汪叫就是多態的很好的一個應用。

12. 面向對象中的重載，覆蓋，隱藏和接口

重載就是在一個類中有相同的類名，但是同名的方法它們的參數不同，在調用的時候，根據你調用同名方法時使用不同的參數，來達到重載的目的。
覆蓋就是一個子類的方法覆蓋掉父類中同名同參數的方法，從而達到實現不同功能的目的。當然使用覆蓋的時候有一個前提，就是父類需要定義虛方法virtual關鍵字，但是父類同名方法不是接口方法。
隱藏指的是派生類的函數屏蔽了與其同名的基類函數。如果派生類的函數與基類的函數同名，並且參數也相同，但是基類函數沒有virtual關鍵字，這個時候如果調用派生類對象的同名方法時，派生類的同名方法將被調用。換個角度看父類的同名非虛方法在這個時候就被隱藏掉了。
接口是一種類，它只有接口而沒有對於接口的實現。在接口裏面定義的方法都是純虛函數。

13. 繼承和泛化的區別與聯繫

繼承和泛化其實在很多時候可以理解爲是一回事情。在UML中繼承和泛化的圖形標識也是一樣的。它們都表示一般與特殊的關係。
接下來說說繼承和泛化之間的區別。
繼承往往是站在子類的角度講，繼承是子類需要對父類獲取；而泛化是站在父類的角度，在父類描述的基礎之上，對子類進行擴展。
繼承關係是泛化關係的反關係，也就是說子類是從父類繼承的，而父類則是子類的泛化。

14. UML4+1視圖

UML採用4+1視圖來描述軟件和軟件的開發過程，軟件架構也可以使用4+1視圖來進行描述。4+1視圖提出的本質就是將複雜的問題簡單化
程序員一般關注的是實現視圖，包括了具體物理代碼文件和組件
系統分析師一般關注的是邏輯視圖，邏輯視圖內包括了類和對象等一連串系統邏輯的信息
系統集成人員一般關注的是進程視圖，進程視圖關注的是併發，進程線程等信息。
系統與網絡工程師一般關注的是部署視圖，部署視圖內包括了系統中軟件和硬件是如何部署的。
最終用戶一般關注的是用戶視圖，也就是最終我們將在什麼樣的場景下如何使用系統。

15. UML用例圖中的三種關係

• UML依賴關係既有包含也有擴展。也就是說用例圖中也可以理解爲只有兩種關係：依賴關係（包含，擴展），泛化關係。
• 泛化關係(generalization)：兩個用例之間有父子關係的時候使用。比如用戶註冊用例包括了郵件註冊和電話註冊，這兩個註冊和用戶註冊時父子關係，在這裏就是泛化。
• 包含關係(include)：在UML1.0中叫做使用關係，包含關係中多個用例包含着一個用例，而每次動作任何一個用例，都會去調用這一個公共的用例，比如存款用例和取款用例，他們每次被調用的時候，都需要去調用查詢餘額用例，那麼存款用例和取款用例中就包括了查詢餘額用例。
• 擴展關係(extend)：和包含關係類似，但是與被包含的用例每次都會被調用相比，被擴展的用例並不會每次100%的被調用的場合，那麼就可以使用到擴展關係。比如查詢書籍信息用例和修改書籍信息用例之間的關係就是擴展關係。每次查詢不一定都會去修改書籍的信息，但是有一定的概率，查詢後去修改書籍信息。
• 還有箭頭的方向是需要特別注意的，在包含關係中，箭頭指向被包含的用例；而在擴展關係中，箭頭不是指向被擴展出來的用例，這點需要特別的注意。
  

16. UML用例圖的概念

• 用例圖的三個基本組件：Actor角色，用例UseCase，關係Relationship。
• 用例圖呈現了一些參與者，一些用例，以及它們之間的關係，主要用於對系統、子系統或類的功能行爲進行建模。
• 用例圖的主要的作用有三個：（1）獲取需求；（2）指導測試；（3）還可在整個過程中的其它工作流起到指導作用。

17. 活動圖的概念

將進程或其他計算結構展示位計算內部一步步的控制流和數據流。活動圖專注於系統的動態視圖，它對系統的功能建模和業務流程建模特別重要，並強調對象之間的控制流程。活動圖中還可以表示爲泳道。
泳道圖：具體描述哪些事情有那種角色去完成描述清楚。

18. 用例建模的四步流程

1. 識別參與者
2. 合併需求獲得用例
3. 細化用例描述
4. 調整用例模型
   步驟1-3是必須的，而步驟4不是必須的。白話用例建模的步驟就是：識別小人，做成橢圓，使用用例規約去描述去細化橢圓，調整橢圓。

19. 關於用例規約的概念：

用例圖中有用例規約的存在，用例規約在我看來其實就是用例圖的數據字典。
用例規約包括了用例的名稱，用例ID，進入用例的前置條件，執行完用例以後推出用例打算後置條件，對用例功能的詳細說明，哪些角色使用了這個用例，本用例和其他用例之間的關係是怎樣的等等等等。
PS：相對於基本事件流，用例規約還包括了異常事件流。（事件流包括了參與者動作和系統的響應）。

20. UML圖的四種關係：

這裏的四種關係容易和用例圖中的三種關係相互混淆概念，所以要特別注意。
第一種是實現關係，UML中有接口，那麼接口的實例化就是實現關係；
第二種是泛化關係，這裏的泛化關係和用例圖中所說的泛化關係是一回事；特殊一般的關係就是UML中的泛化關係。
第三種是關聯關係，關聯關係包括了組合關係和聚合關係兩種。它描述了一組鏈，鏈是對象之間的連接。
組合關係和聚合關係一個用的是實心的菱形箭頭，一個則是用空心的菱形；它們之間最大的區別就是生命週期不同。
整體與部分生命週期相同的叫組合；整體與部分之間生命週期不同的叫聚合。
最後一種是依賴關係，一個對象的變化讓另外一個對象也同時發生變化。

21. UML中的四種事物分別是什麼

結構事務
註釋事務
分組事務
行爲事務
其中註釋事務最好理解，在UML圖中總有一些事務是需要加註解的；
當UML圖多起來了，怎麼去歸納和整理呢，這個時候就需要分組事務，比如包，構件看起來好像一個盒子，這就是分組的事務；
結構事務對應的就是UML靜態圖中的類，對象，接口，活動類，構件等元素，它是最靜態的部分；
行爲事務剛好與結構事務相對應，比如消息，動作次序，連接等，它代表了時間和空間上的動作。

22. UML中的圖的分類

UML中的圖分爲了靜態圖（結構圖）和動態圖（行爲圖）
結構圖：類圖，部署圖，組件圖，對象圖，構件圖，包圖，製品圖。
行爲圖：活動圖，順序圖，通信圖，用例圖，狀態圖，定時圖，交互概覽圖。
通信圖和順序圖我們又可以把它稱之爲交互圖。
靜態圖表現系統中穩定的組成部分。

23. 活動圖與程序流程圖之間的區別與聯繫

程序流程圖來自於結構化分析與開發，活動圖多用於面向對象的分析與開發；
活動圖可以表示多個進程並行的執行，程序流程圖沒有這個功能；
活動圖中有泳道的概念，所以活動圖可以表示不同角色之間參與活動流程的細節，而程序流程圖沒有這個功能。

24. 需求建模的概念

需求建模包括了用例模型和分析模型兩個方面。
用例模型的步驟之前已經有說過了，分爲四步。首先識別參與者，接下來合併需求獲得用例，第三步是細化用例，最後一步也是可有可無的，就是對現有的用例進行調整。
分析模型的建立和用例模型建立的步驟完全不一樣，它先是定義概念類，識別類之間的關係，爲類添加相應的職責，最後建立交互圖。
用自己的話概括總結就是先定義類，然後看類與類之間存在的關係，第三給類添加相應的方法，最後建立起交互圖來。

25. 數據流圖和程序流程圖之間的區別聯繫

數據流描述的是數據的流向，而程序流程圖是一種控制流。
數據流圖展現的是功能的模型，而程序流程圖展現的是程序的細節處理。