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

前言

軟體開發本身是一個複雜的工藝過程,牽涉到各種領域技術,一般我們所聽到的軟體架構設計可能都只著重在軟體系統架構本身,比如:如何妥善的分工、如何解決開發上的各種問題、使用哪一種 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 範本設計

留言

  1. 感謝提供好文,期待大大下篇新的。

    回覆刪除
    回覆
    1. 那裡,對您有幫助是最重要的😊

      最近講課忙碌現在才回,第二篇應該快出來了,哈哈哈😀

      刪除

張貼留言

這個網誌中的熱門文章

ASP.NET Blazor 關鍵報告

什麼是 gRPC ?