從使用者需求，談架構設計| gelis 技術隨筆 - - 點部落

我們介紹一個領域類別圖(Domain Class Diagram) 的反覆分析過程 ... 但是千萬不要將領域類別圖當作是一種高階的類別圖，因為所謂的高階，代表著會遺失 ... 軟體開發本身是一個複雜的工藝過程，牽涉到各種領域技術，大部分談軟體架構設計著重在軟體系統架構本身，如何妥善的分工、如何解決開發上的各種問題、使用哪一種DesignPattern來解決問題、如何快速開發等等，只不過，真正有用的軟體是對客戶有用的軟體、能替客戶解決問題的軟體，才是真正有價值的軟體。

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

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

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

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

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

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

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

為什麼我這麼說呢？ 我下面分幾點為各位說明： (1).在進行架構設計時，如果要避免「過度設計」，使用UML的Boundary可明確規範出哪些是系統內、哪一些是系統外的。

(2).前期在規劃系統雛形時，使用UseCase+穩健圖+ClassDiagram也可幫助您規劃系統雛形架構。

(3).透過UML這些Natation可以幫助您規劃系統時候，是否有想清楚使用者要的是什麼？ (4).在UML當中進行分析設計與實作時的，反覆設計(Iterations)、漸進式（Incremental）的方法，可以完全對應到在敏捷（Agile／Scrum）裡面的衝刺（Sprint） 也能保有必須的架構設計？注意了，是「必須」的架構設計，要做到這一點，瞭解客戶需求、有效分析客戶需求，才會是重點。

  收集與了解使用者需求 在這一次，我替某客戶開的OOAD／UML系統分析設計課程裡，其中一張投影片的內容。

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

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

在UserStory裡，強調的是，”expressesoneveryspecific"need"thatauserhas.” 在UseCase強調的是：”interactionbetweentheuserandthesoftware.” 我則將他合併起來，面對不懂UseCase的客戶，我們瞭解客戶的“need!”，回到公司內化為“interactionbetweentheuserandthesoftware”，這樣一來，我們更容易瞭解客戶的需求，減低內化的失真機率。

需求訪談分析進行的階段： 訪談、瞭解使用者需求、收集需求（確認使用者想法） 從旁側擊：有時使用者自己都不見得瞭解自己的想法 瞭解使用者平常工作的模式「作業流程」（透過陪同使用者工作一天來了解使用者真正需要什麼？） 分析階段： 找出動作者、找出使用案例 誰來使用系統？誰會跟系統互動？ 誰從系統取得資訊？誰將資訊提供給系統？ 找出系統邊界，確認系統以內及系統以外的事物 由簡入繁(但也不要將使用案例畫的太繁瑣) 逐步增加使用案例的精確度(precision)，不要一開始就陷入繁雜的細節 UML分析設計與實作時的，反覆設計(IterationModeling) 甚至在使用UML各項diagram與notations時，我們的開發團隊實際運作的軟體開發流程其實是（Agile／Scrum），在Agile或者Scrum強調的Sprint，我們再細分為，一個、到多個反覆設計(Iterations)，在每一個Iteration所要完成的需求裡，又可以細切多個IterationModeling，並期望做到： 敏捷開發-快速反應 你無法凍結需求-最小產品交付 軟體架構設計-最小產品交付 在UML的系統分析裡面，我們使用「穩健圖（robustnessdiagram）」作為從UseCase到SequenceDiagram的催化劑，幫助系統分析師在繪製循序圖時，重新檢視使用案例，同時加入更多的物件思維，也因此可以更順暢地移動到純物件化的類別圖與循序圖設計。

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

所以，使用UML進行分析時： 不會一次滿足所有使用案例、參與者 不會一次使用所有Diagrams的notations通常點到為止 使用「使用案例」長出其它「使用案例」與「參與者」 以房貸系統為例 需求分析師訪談結束後，取得如下客戶需求： UseCaseScenario： X山顧客或非X山顧客都可以使用瀏覽器到玉山首頁線上進行房屋貸款申請，非X山顧客而言，必須先填寫資料，才可進行線上申請作業。

線上需填寫資料如下： (1).土地與建物登記、或所有權等資料、房屋地址 (2).借款人身分資料、職業 (3).所得資料(如：年所得、收入來源、現有銀行存戶資料..等等） (4).婚姻狀況、子女人數 (5).貸款用途、貸款金額..等等 (6).也可直接聯繫房貸專員   我們介紹一個領域類別圖(DomainClassDiagram)的反覆分析過程 底下，筆者共進行八個Iteration，而每一個Iteration期都須同步的修改其他圖形，且都應從UseCase開始。

下面只是個範例： IterationModeling1-找出領域類別圖(DomainClassDiagram) IterationModeling2-找出「候選類別」 IterationModeling3-找出相關連性 IterationModeling4-移除與目前Domain不相關的類別 IterationModeling5-移除同義字 IterationModeling6-合併 IterationModeling7-補其不足 IterationModeling8-(回到IterationModeling3) 說明： 所謂的領域類別圖(DomainClassDiagram)，而其實就是一種初步的類別圖，又可稱為DomainClassDiagram，也為一種ConceptualModeling，但是千萬不要將領域類別圖當作是一種高階的類別圖，因為所謂的高階，代表著會遺失許多細節，但是，在繪製領域類別圖形時，也不要涉入繁瑣的細節，有些朋友在這之間並不清楚如何拿捏分寸，其實也很簡單，有機會筆者開另一篇文章詳細的介紹。

下面，筆者一步一步來說明上方共Iteration1~Iteration8會如何進行？及進行那些內容？ IterationModeling1-找出領域類別圖(DomainClassDiagram) IterationModeling2-找出「候選類別」 IterationModeling3-找出相關連性 這時，我們可以開始進行細部分析，找出其中的連結關係(Association)，要包括多重性(如：一對多、多對一、多對多..等關係) IterationModeling4-移除與目前Domain不相關的類別 細部分析之後，前面我們發現「問卷」與「房貸線上申請」並無關係，前面UseCase系統邊界的錯誤，在這個步驟將其移除 IterationModeling5-移除同義字 再細部分析時，前面我們發現「土地」與「所有權」應是同一個物件   IterationModeling6-合併 因此，我在這個步驟哩，將相同的同義字合併，並建立資料字典(DataDictionary)   IterationModeling7-補其不足 在反覆的分析過程當中，我們發現還需要有：借款人、房屋地址、婚姻狀況等，因此，在這個步驟裡需陸續補上   IterationModeling8-(回到IterationModeling3) 到了這個步驟，別忘了同步修改相關的圖形（Iteration），就算開始Implement仍然不會停止這個反覆的設計。

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

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

在UML分系設計的領域裡，您可以將(ALM／Agile)裡所提倡的Sprint或者Iteration，在每一個反覆設計裡，在細切為IterationModeling，而每一個IterationModeling有可以有多個DailyModeling，詳細的解釋，可以由下圖，也就是文章一開始的Logo來說明：   結語： 在博大而精深的UML系統分析設計理論哩，其實很難從一篇文章中將其說明清楚，尤其在搭配實作的狀況下更不容易。

而這的設計與分析的過程又與您的軟體架構設計息息相關。

下一次，筆者介紹在一個IterationModeling的階段哩，如何與系統設計銜接，如何做到恰如其分的軟體架構設計。

    簽名： 學習是一趟奇妙的旅程 這當中，有辛苦、有心酸、也有成果。

有時也會有瓶頸。

要能夠繼續勇往直前就必須保有一顆最熱誠的心。

軟體開發之路（FB社團）：https://www.facebook.com/groups/361804473860062/ Gelis程式設計訓練營（粉絲團）：https://www.facebook.com/gelis.dev.learning/   如果文章對您有用，幫我點一下讚，或是點一下『我要推薦』，這會讓我更有動力的為各位讀者撰寫下一篇文章。

非常謝謝各位的支持與愛護，小弟在此位各位說聲謝謝!!!^_^ 軟體架構設計 回首頁 透過 Gelis程式設計訓練營 與我聯繫 或者透過臉書Messenger與我聯繫 或連繫我的臉書社群【軟體開發之路】 決戰OOAD系列課程-使用UML(線上課程)   跨平台的WebAPIFramework框架設計課程（第三梯） 最近一期課程時間：2019/06/023 需要企業內訊與我聯繫： 單元測試UnitTest與Moq物件實務課程 ASP.NETCore2.1從入門到進階 由於.NETCore3.1已經LTS，所以本課程線已經跟上為.NETCore3.1，如有企業內訊需求、新開立的課程會為ASP.NETCore3.1從入門到進階 線上課程如下：(New)-單元測試UnitTest與Moq實務課程如何利用範本精靈(C#ProjectTemplate)簡化重複開發工作第二波-早鳥優惠持續中https://hiskio.com/courses/192?promo_code=NG145G2 •熱衷於OOA/OOD/OOP與UML塑模化應用程式設計、軟體工程相關，喜歡程式設計、擅長ASP.NETWebForm,MVC,WCF,WindowsForm/WPF開發、也實作過一些專案 喜歡Trouble-shooting程式設計的各種疑難問題