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

2017-11-30

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

本篇文章，筆者介紹，在 UML 的系統分析設計領域裡，如何從使用者需求出發，如何正確收集到使用者的需求，甚至與（Agile／Scrum）結合，在 Agile 或者 Scrum 強調的 Sprint ，我們再細分為，一個、到多個反覆設計 (Iterations)，在每一個 Iteration 所要完成的需求裡，又可以細切多個 Iteration Modeling。

文章中，將介紹如何正確地進行 Iteration Modeling. 與 Continuous Modeling，以便做到恰如其分的軟體架構設計。

前言

軟體開發本身是一個複雜的工藝過程，牽涉到各種領域技術，一般我們所聽到的軟體架構設計可能都只著重在軟體系統架構本身，比如：如何妥善的分工、如何解決開發上的各種問題、使用哪一種 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），就算開始 Implement 仍然不會停止這個反覆的設計。

Iteration Modeling. Vs. Continuous Modeling

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

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

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