從使用者需求，談架構設計

前言

軟體開發本身是一個複雜的工藝過程，牽涉到各種領域技術，一般我們所聽到的軟體架構設計可能都只著重在軟體系統架構本身，比如：如何妥善的分工、如何解決開發上的各種問題、使用哪一種 Design Pattern 來解決問題、如何快速開發等等，只不過，真正有用的軟體是對客戶有用的軟體、能替客戶解決問題的軟體，才是真正有價值的軟體。

如果，您有非常妥善的軟體架構設計、並整合的 CI／CD 自動化整合測試部署、交付流程，也整合了 Containers 等相關技術，但是 CI／CD 過去卻不是使用者所想要的軟體，那你頂多只是做到了可快速的不斷的交付軟體直到客戶滿意為止，但，如果一開始的需求方向就錯誤了，那就不是 CI／CD 自動化整合測試部署、交付流程所能夠解決的問題，因為你的核心架構可能都需要重新翻寫。

當然，並不是說上述架構設計、自動化測試整合部署流程不重要，架構設計、自動化測試整合部署流程固然很重要，只是，相形之下，做出客戶需要的軟體，後續的各種軟體架構設計、自動化測試作業也才有真正的價值。

關於軟體架構設計

事實上，真實世界中的軟體架構設計應該必須由使用者需求出發，正確收集到使用者的需求，也才能夠正確地做出最佳的架構設計，就專案而言，所以，如果您在分析、與紀錄使用者需求所使用的方式，能與開發團隊相同，且一致的語言 (透明化)，這一致的語言可能還包括，你在分析階段所以使用的 notations 表示法，甚至到您開始做系統設計 (System Design) 所使用的 Architecture documents 、甚至 implement 所定義的 （Programming rule/Coding Standard）等，都在這個的範圍內，也可以說，如果您分析工具如果是建築於團隊開發的共同規範之上，那麼不管你們是團隊進行內部溝通（SA對SD／SD對PG），或是與使用者溝通，都可以將 Gap 降至最低。

在我自己的開發團對裡，我們取用 UML 部分的圖形與 notations 來使用，若您運用的恰當，它可以幫助你在分析使用者需求時，釐清、切割清楚什麼是使用者最關心的，因為，這其實都會與你之後的架構設計息息相關。

為什麼我這麼說呢？

我下面分幾點為各位說明：
(1). 在進行架構設計時，如果要避免「過度設計」，使用 UML 的 Boundary 可明確規範出哪些是系統內、哪一些是系統外的。
(2). 前期在規劃系統雛形時，使用 Use Case + 穩健圖 + Class Diagram 也可幫助您規劃系統雛形架構。
(3). 透過 UML 這些 Natation 可以幫助您規劃系統時候，是否有想清楚使用者要的是什麼？
(4). 在 UML 當中進行分析設計與實作時的，反覆設計 (Iterations)、漸進式（Incremental）的方法，可以完全對應到在敏捷（ Agile／Scrum）裡面的衝刺 （Sprint）

也能保有必須的架構設計？注意了，是「必須」的架構設計，要做到這一點，瞭解客戶需求、有效分析客戶需求，才會是重點。

收集與了解使用者需求

在這一次，我替某客戶開的 OOAD／UML 系統分析設計課程裡，其中一張投影片的內容。

一般來說，在座需求需求收集時，我會建議需求收集者採用的需求收集工具以簡單為主，能夠快速收集、回到公司後，也能夠快速閱讀、內化、瞭解、吸收的為主，盡量不要使用太複雜、繁雜的需求收集工具，這會影響需求收集的效果，需求收集效果受影響，是會間接的影響到需求收集的準確度。

使用案例分析進行的方式

在新興的使用案例分析方法裡，我慢慢搭配 User Story 來收集使用者需求，許多人，會把 User Story 與 Use Case 直接拿來做比較，但我則不然，我直接取用對專案有幫助的部分。

• 在 User Story 裡，強調的是，”expresses one very specific "need" that a user has.”
• 在 Use Case 強調的是：”interaction between the user and the software.”

我則將他合併起來，面對不懂 Use Case 的客戶，我們瞭解客戶的 “need!”，回到公司內化為 “interaction between the user and the software”，這樣一來，我們更容易瞭解客戶的需求，減低內化的失真機率。

需求訪談分析進行的階段：

• 訪談、瞭解使用者需求、收集需求（確認使用者想法）
• 從旁側擊：有時使用者自己都不見得瞭解自己的想法
• 瞭解使用者平常工作的模式「作業流程」（透過陪同使用者工作一天來了解使用者真正需要什麼？）

分析階段：

• 找出動作者、找出使用案例
• 誰來使用系統？誰會跟系統互動？
• 誰從系統取得資訊？誰將資訊提供給系統？
• 找出系統邊界，確認系統以內及系統以外的事物
• 由簡入繁(但也不要將使用案例畫的太繁瑣)
• 逐步增加使用案例的精確度(precision)，不要一開始就陷入繁雜的細節

UML 分析設計與實作時的，反覆設計 (Iteration Modeling)

甚至在使用 UML 各項 diagram 與 notations 時，我們的開發團隊實際運作的軟體開發流程其實是 （Agile／Scrum），在 Agile 或者 Scrum 強調的 Sprint ，我們再細分為，一個、到多個 反覆設計 (Iterations)，在每一個 Iteration 所要完成的需求裡，又可以細切多個 Iteration Modeling，並期望做到：

• 敏捷開發 - 快速反應
• 你無法凍結需求 - 最小產品交付
• 軟體架構設計 - 最小產品交付

在 UML 的系統分析裡面，我們使用「穩健圖（ robustness diagram ）」作為從 Use Case 到 Sequence Diagram 的催化劑，幫助系統分析師在繪製循序圖時，重新檢視使用案例，同時加入更多的物件思維，也因此可以更順暢地移動到純物件化的類別圖與循序圖設計。

且穩健分析利用 B-C-E （邊界、控制、實體）來說明系統使用案例在執行時，動作者（Boundary）進行的流程（Control）、需要哪些實體（Entity）等，有機會，筆者會在下一篇文章詳細的介紹 B-C-E （邊界、控制、實體）分析方法。

所以，使用 UML 進行分析時：

• 不會一次滿足所有使用案例、參與者
• 不會一次使用所有 Diagrams 的 notations 通常點到為止
• 使用「使用案例」長出其它「使用案例」與「參與者」

以房貸系統為例

需求分析師訪談結束後，取得如下客戶需求：

Use Case Scenario：

X山顧客或非X山顧客都可以使用瀏覽器到玉山首頁線上進行房屋貸款申請，非X山顧客而言，必須先填寫資料，才可進行線上申請作業。

線上需填寫資料如下：

(1). 土地與建物登記、或所有權等資料、房屋地址

(2). 借款人身分資料、職業

(3). 所得資料(如：年所得、收入來源、現有銀行存戶資料..等等）

(4). 婚姻狀況、子女人數

(5). 貸款用途、貸款金額..等等

(6). 也可直接聯繫房貸專員

我們介紹一個領域類別圖 (Domain Class Diagram) 的反覆分析過程

底下，筆者共進行八個 Iteration ，而每一個 Iteration 期都須同步的修改其他圖形，且都應從 Use Case 開始。下面只是個範例：

• Iteration Modeling 1 - 找出領域類別圖 (Domain Class Diagram)
• Iteration Modeling 2 - 找出「候選類別」
• Iteration Modeling 3 - 找出相關連性
• Iteration Modeling 4 - 移除與目前 Domain 不相關的類別
• Iteration Modeling 5 - 移除同義字
• Iteration Modeling 6 - 合併
• Iteration Modeling 7 - 補其不足
• Iteration Modeling 8 - (回到 Iteration Modeling 3)

說明：

所謂的領域類別圖 (Domain Class Diagram)，而其實就是一種初步的類別圖，又可稱為 Domain Class Diagram，也為一種 Conceptual Modeling，但是千萬不要將領域類別圖當作是一種高階的類別圖，因為所謂的高階，代表著會遺失許多細節，但是，在繪製領域類別圖形時，也不要涉入繁瑣的細節，有些朋友在這之間並不清楚如何拿捏分寸，其實也很簡單，有機會筆者開另一篇文章詳細的介紹。

下面，筆者一步一步來說明上方共 Iteration 1 ~ Iteration 8 會如何進行？及進行那些內容？

Iteration Modeling 1 - 找出領域類別圖 (Domain Class Diagram)

Iteration Modeling 2 - 找出「候選類別」

Iteration Modeling 3 - 找出相關連性

這時，我們可以開始進行細部分析，找出其中的連結關係 (Association)，要包括多重性(如：一對多、多對一、多對多..等關係)

Iteration Modeling 4 - 移除與目前 Domain 不相關的類別

細部分析之後，前面我們發現「問卷」與「房貸線上申請」並無關係，前面 Use Case 系統邊界的錯誤，在這個步驟將其移除

Iteration Modeling 5 - 移除同義字

再細部分析時，前面我們發現「土地」與「所有權」應是同一個物件

Iteration Modeling 6 - 合併

因此，我在這個步驟哩，將相同的同義字合併，並建立資料字典 (Data Dictionary)

Iteration Modeling 7 - 補其不足

在反覆的分析過程當中，我們發現還需要有：借款人、房屋地址、婚姻狀況等，因此，在這個步驟裡需陸續補上

Iteration Modeling 8 - (回到 Iteration Modeling 3)

到了這個步驟，別忘了同步修改相關的圖形（Iteration Modeling），就算開始 Implement 仍然不會停止這個反覆的設計。

Iteration Modeling. Vs. Continuous Modeling

所謂的 Continuous Modeling 其實是一種週期性的活動，通過使用各式 UML Diagram 進行定期的簡短討論，共享改進觀點或改變團隊內的模型結構，期望達到，團隊間，有效購通、與有效地同步程式碼的目的。

UML 的分析與設計的理論，其實是博大而精深的，絕對不是在單一幾篇文章就能夠介紹的完的。

在 UML 分系設計的領域裡，您可以將 (ALM／Agile) 裡所提倡的 Sprint 或者 Iteration，在每一個反覆設計裡，在細切為 Iteration Modeling，而每一個 Iteration Modeling 有可以有多個 Daily Modeling，詳細的解釋，可以由下圖，也就是文章一開始的 Logo 來說明：

結語：

在博大而精深的 UML 系統分析設計理論哩，其實很難從一篇文章中將其說明清楚，尤其在搭配實作的狀況下更不容易。而這的設計與分析的過程又與您的軟體架構設計息息相關。下一次，筆者介紹在一個 Iteration Modeling 的階段哩，如何與系統設計銜接，如何做到恰如其分的軟體架構設計。

---

關於 Gelis：

資深 .NET 技術顧問

FB 社團 (軟體開發之路)：

https://www.facebook.com/groups/361804473860062/

FB 粉絲團 (Gelis 的程式設計訓練營)：

https://www.facebook.com/gelis.dev.learning/

我講授過的課程 SlideShare：

https://www.slideshare.net/GelisWu

以下是我經營的項目與內容：

(1). 企業內訓課程

(2). 專業顧問

企業內訓課程：

1. .NET Core 3.1 從入門到進階

先前實體課程連結

2. 跨平台的 Web API Framework 框架設計

先前實體課程連結

3. 決戰 OOAD 系列課程 - 使用 UML

先前實體課程連結

4. 單元測試 UnitTest 與 Moq 物件實務課程

先前實體課程連結

5. 快速開發系列 - C# Project Templates 範本設計