軟體開發本身是一個複雜的工藝過程,牽涉到各種領域技術,大部分談軟體架構設計著重在軟體系統架構本身,如何妥善的分工、如何解決開發上的各種問題、使用哪一種 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/
如果文章對您有用,幫我點一下讚,或是點一下『我要推薦』,這會讓我更有動力的為各位讀者撰寫下一篇文章。
非常謝謝各位的支持與愛護,小弟在此位各位說聲謝謝!!! ^_^