軟體架構設計鮮思維－從合成結構到使用案例模型

http://www.ithome.com.tw/itadm/article.php?c=37307
軟體架構設計鮮思維－從合成結構到使用案例模型

軟體架構設計鮮思維－從合成結構到使用案例模型

文/ iThome (記者) 2006-05-23

以「寬頻路由分享器」這類的嵌入式系統為例，說明牽涉到軟體、硬體整合設計時，如何從合成結構圖到使用案例模型，以釐清功能需求。

作者：王克明 信仁軟體設計顧問中心軟體架構師、機械化師文書官、系統工程師、Oracle DBA、IT部門副理、講師、顧問 軟體架構設計中，設計師可使用UML的「合成結構圖（Composite Structure Diagram）」所呈現的架構視圖，表達產品整體觀；後續開發加值應用軟體時，可以將產品的硬體部分當成一個黑盒子（Black Box），藉以表達黑盒子的功能需求，這時候可以應用「使用案例圖（Use Case Diagram）」。兩者能達成非常好的互補，合成結構圖表達黑盒子（設計中的系統）位於硬體產品的哪一個部位，以及與硬體內的其他的組件的關係；再由此 可以很平順地利用使用案例圖來表達，找出使用該黑盒子的主要參與者（Primary Actor），以及外部的支援性參與者（Supporting Actor）。 由於系統範圍明確、與外部溝通的參與者也很清楚，所以要漸增與漸進的找出該黑盒子的系統功能，也就是使用案例（Use Case），那就不是難事了；找出使用案例，在先不考量系統內部結構設計的前提下寫出程式碼，外加確保程式碼正確性的功能測試碼，那根本是輕而易舉的事。 我們以「寬頻路由分享器」這類的嵌入式系統為例，說明牽涉到軟體、硬體整合設計時，如何從合成結構圖到使用案例模型，以釐清功能需求。至於案例圖 說中硬體元件只是用於示意的框架，不是強調組件關係的正確性，以免讓應用軟體的程式設計師誤解系統需求的範疇，或陷入分析癱瘓（paralysis）。 嵌入性系統與「純軟體應用系統」的設計差異？ 那麼，嵌入性系統的軟體設計，是否有別於「純」軟體應用系統的設計？從多家硬體製造業內的軟體開發部門與 PDA、手機等應用程式開發廠商就近的觀察中，發現到一個比較顯明的問題，這類廠商中軟體開發人員的規模，甚至比一般中型「純」軟體開發廠商的人員還多， 但開發人員的角色卻連最基本的系統分析/系統設計都沒有區分。資深的開發人員或經理擔任需求分析，幾乎沒有所謂的結構分析或設計，就是依照需求後直接撰寫 程式碼，反而是需求的不明確。 嗯，好吧，如何釐清有效的需求？嵌入式系統的需求分析與設計，比起「純」軟體如ERP系統等簡單得很多，理由為何？因為系統範圍就是被「硬體」確 實「框住」，形成最有效的封裝效果，工程師可以將待開發的系統當成是一個黑盒子；而「純」軟體應用系統，系統分析人員要能有較高度抽象的能力，分析與界定 系統的範圍。要能在嵌入式系統做好有效的需求分析與設計，只有一個關鍵：「找出黑盒子（界定系統範圍），以及了解該黑盒子在硬體產品內的角色與定位」。 好像很簡單，不是嗎？但團隊成員往往就是對那一個黑盒子很模糊，沒有共識。只要問每一個成員，那個黑盒子的系統名稱為何，就可以了解他們為何難以定義系統 的需求範疇。問題在哪裡呢？因為沒有確實把整體圖像有效表達出來。在嵌入式系統中，我們可以把硬體產品視為是這個整體圖像，例如IP分享器、MP3播放 器、手機等，然後找出該硬體產品與外界溝通的「介面（Interface）」，例如，MP3播放器的介面包括了「Line-in」、「Line- out」、「Control UI」、「USB」等。再來，就是就是檢視這個硬體產品內塞了哪些重要的組件，而其中有一個組件就是嵌入式系統的黑盒子所在，我們要先能釐清這些組件之間 的關連、哪些組件負責與外部介面的溝通等。 有了這一張架構視圖才能讓我們釐清，所要加值軟體應用程式所在的那一個黑盒子，在整個硬體產品內所承擔的角色與責任為何，然後才有可能「聚焦」， 團隊才能有共識。有共識後才能對該黑盒子進行更進一步的需求分析，包括找出誰來使用系統、使用系統的目的、系統是否需要外部系統的服務等系統外部功能面的 觀點。 確立軟體廠商設計的核心 從寬頻路由分享器的例子，工程師須了解應用軟體的核心是位於哪一個「黑盒子」組件，以及該黑盒子是否有與其他的組件連結。若是站在設計代工製造 （ODM）軟體廠商的角度來看時，未來得以讓他們加以發揮的加值軟體應用程式是位於RCS（Router Control System）組件內，所以RCS成為整個寬頻分享器應用軟體的核心。 RCS確定應用程式的核心所在，當確立共識後，再來就是將焦點轉移至RCS，並且「放大」，分析檢視出RCS會提供哪些「系統功能」供外部的參與者來使用，這些「系統功能」，稱之為「使用案例」。 誰來使用系統，就會成為該系統的「主要參與者」。從圖中得知，網路管理員其實是外部寬頻分享器的主要參與者，但網管人員透過寬頻分享器的介面所連進來的系統就是由RCS負責，所以網管人員同時就會成為RCS的主要參與者。 RCS是否需要其他系統的服務支援？若是，其他系統就成為RCS的「支援性參與者」。從案例圖中可以看出，主要與RCS連結的組件有微處理器、快 閃記憶體（Falsh Memory）等，所以兩者都可以成為RCS的支援性參與者。其中，快閃記憶體的角色蠻有趣，它如同企業資訊系統的資料庫，或看成是RCS系統的私有倉儲 （private storage），而不會將之視為是外部的系統。圖中特別把它畫出來是反應合成結構圖中，快閃記憶體是明確獨立的硬體組件。 發掘潛在獲利的需求，實現在嵌入系統內 確認了整體（寬頻分享器）與核心焦點（RCS），團隊有了全貌、一致性的共識後，再來才是實作核心系統所提供的功能。甚至，團隊可以據此集思廣 益，來發掘出潛在的需求。例如，A 牌的寬頻分享器就發掘出分享器同時可以提供Web與FTP 的服務，更賦予了分享器多功能的面貌與價值。 建立合成結構圖，由此推導出使用案例圖。從整體看局部的焦點，從低精確度逐漸地至高精密的細節，在階段過程中用最少的精力，找出最重要的精華與本質，一開始把焦點集中在對的目標上，勝過於忙忙碌碌，結果花在太多沒有必要的工作上。

--
萬歲！您的郵件已被捨棄。一封垃圾郵件也沒有！

--
萬歲！您的郵件已被捨棄。一封垃圾郵件也沒有！