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

軟體開發本身是一個複雜的工藝過程,牽涉到各種領域技術,大部分談軟體架構設計著重在軟體系統架構本身,如何妥善的分工、如何解決開發上的各種問題、使用哪一種 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 來說明:

 

結語:

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

 


 

簽名:

學習是一趟奇妙的旅程

這當中,有辛苦、有心酸、也有成果。有時也會有瓶頸。要能夠繼續勇往直前就必須保有一顆最熱誠的心。

軟體開發之路(FB 社團)https://www.facebook.com/groups/361804473860062/

Gelis 程式設計訓練營(粉絲團)https://www.facebook.com/gelis.dev.learning/


 

如果文章對您有用,幫我點一下讚,或是點一下『我要推薦,這會讓我更有動力的為各位讀者撰寫下一篇文章。

非常謝謝各位的支持與愛護,小弟在此位各位說聲謝謝!!! ^_^