31 八月, 2006 13:22
推文( 0 )
前言
嵌入式系統(Embedded System)，簡單的說，就是把軟體 “放入” 硬體設備內，然後寫簡單的程式來控制硬體，一般稱之為 “韌體(Firmware)” 設計。諸如從主機板的 BIOS 設計、光碟燒錄機的控制程式、乃至於至行動電話、PDA、影音家電產品等，均可見其嵌入式系統的蹤影，可說是無處不在，應用範圍非常之廣泛。
以往寫嵌入式系統的程式，受限於記憶容量過小，只能以如 C 語言以比較低階的語法層次，來直接連結與控制硬體的操作，程式要求的是 “輕薄短小” 與 “效能佳”，而多樣化的應用層面，並不容易。而如今，硬體設備的兩個最重要與軟體開發相關的裝置：整合式晶片 (Soc, System on Chip) 與 快閃記憶體 (Flash Memory)，前者如同主機板的 CPU，以更小的體積、更佳的效能來控制硬體其它的 I/O 裝置；後者有如資料庫，可以塞更多的資料與應用程式於其內，如此嵌入一個小型的作業系統(OS)，如 Embedded Linux、Windows CE、Java Virtual Machine …等，由 OS 負責與更底層、低階的硬體裝置溝通、然後 OS 提供了高階的 APIs(Application Programming Interfaces)甚至系統框架(System Framework，如 .NET)供軟體開發者用更簡單、具彈性的高階程式語言的特性，來達成更豐富的功能。
所以，嵌入式系統的應用範圍，可就更行廣泛與活躍，軟體應用程式的地位，從以往是陪襯於硬體，現在反而是極有可能翻身，反而是 “以軟御硬”，透過軟體，讓競爭性激烈、毛利低的同質性硬體產品可以脫穎而出，能更有特色、更多的變化性。
嵌入性系統如何作需求分析與設計？
那麼，嵌入性系統的軟體設計，是否有別於 “純” 軟體應用系統的設計？ 筆者不以為然，尤其筆者教授 UML 軟體設計課程，對多家硬體製造業內的軟體開發部門與 PDA、手機等應用程式開發廠商，就近的觀察，發現到，一個比較顯明的問題是，軟體開發人員的規模，甚至比一般中型 “純” 軟體開發廠商的人員還多，但，開發人員的角色，卻連最基本的 SA/SD (系統分析/系統設計) 都沒有區分，資深的開發人員或經理擔任需求分析，幾乎沒有所謂的結構分析或設計，就是依照需求，直接下去 Coding，所以軟體開發人員的要求是會“寫程式”，能“寫出來” 最重要，資深經理比較煩惱的反而是需求的不明確。
嗯，好吧，那麼如何釐清有效的需求？ 本篇先針對這個議題來作一些說明，筆者以為，嵌入式系統的需求分析與設計，比起“純”軟體如 ERP 系統等，簡單得很多，理由為何？ 因為，系統範圍就是被“硬體”給確實“框住”，形成最有效的封裝效果，也就是用“眼睛”就可以看到，待開發的系統就是一個黑箱 (Black Box)；而“純”軟體應用系統，系統分析人員要能有較高度抽象的能力，才能以“心眼”看到與界定系統的範圍。要能在嵌入式系統做好有效的需求分析與設計，只有一個關鍵：
“找出那一個黑盒子(界定系統範圍)，瞭解該黑盒子在硬體產品內的角色與定位”。
這裡所謂的黑盒子，是指在硬體產品內一定會有一個放置軟體應用程式的控制系統(否則哪叫嵌入式系統？) 。看起來好像很簡單，不是嗎？ 但團隊成員往往就是對那一個黑盒子很模糊，沒有共識，何以見得？ 只要問每一個成員，那個黑盒子的系統名稱為何，就知道了，問 10 個可能有 8 個不同的答案，這樣就有問題了。☆註1
問題在哪裡呢？ 沒有確實把整體“Whole Map”給有效表達出來！
在嵌入式系統中，我們可以把硬體產品視為是一整個“Whole Map”，例如 IP 分享器、MP3 播放器、手機 …等。然後，找出該硬體產品與外界溝通的“介面(Interfaces)”，例如，MP3 播放器的介面包括了“Line-in”、“Line-out”、“Control UI”、“USB” …等。再來，就是就是檢視這個硬體產品內“塞”了哪些重要的組件(Parts)，而其中，有一個組件就是嵌入式系統的黑盒子所在，我們要先能釐清這些組件之間的關連、哪些組件負責與外部介面的溝通等。
有了這一張架構視圖，才能讓我們釐清，所要加值軟體應用程式所在的那一個黑盒子，在整個硬體產品內，所承擔的角色與責任為何，然後才有可能“聚焦”，團隊才能有共識，有共識後才能對該黑盒子進行更進一步的需求分析，包括找出“誰來使用系統”、“使用系統的目的”、“系統是否需要外部系統的服務”等系統外部功能面的觀點。
筆者發現到，用來表達硬體產品“整體”觀的架構視圖，可以利用 UML 的“合成結構圖(Composite Structure Diagram)”；而表達那一個黑盒子的功能需求，可以利用“使用案例圖 (Use Case Diagram)”，兩者可以達成非常好的互補：“合成結構圖”可以表達黑盒子(設計中的系統)位於硬體產品的那一個部位，以及與硬體內的其它的組件的關係；再由此可以很平順地利用使用案例圖來表達，找出使用該黑盒子的主要參與者(Primary Actor)，以及外部的支援性參與者(Supporting Actor)，且由於系統範圍明確、與外部溝通的參與者也很清楚，所以要漸增與漸進的找出該黑盒子的系統功能，也就是使用案例 (Use Case)，那就不是難事了；找出使用案例，在先不考量系統內部結構設計的前提下，要寫出程式碼，外加確保程式碼正確性的功能測試碼，那根本是輕而易舉的事了。
對比企業層級的資訊系統 (Enterprise Information System)，表達整體企業流程(Business Process)所利用的設計圖是活動圖(Activity Diagram)；而表達嵌入式系統硬體產品的全貌，包括對外溝通的介面(Interfaces)，以及內部的組件(Parts)，利用合成結構圖，可說是最為恰當的整體架構視圖，而無論是活動圖或者合成結構圖，均可以透過簡單的對應步驟，將焦點更能聚焦到表達資訊系統層級的使用案例圖，用以表達待開發的資訊系統，應該提供哪些的功能性服務(亦即，使用案例)，以及，"誰(主要參與者，Primary Actor)" 會來使用系統，系統又是需要哪些外部系統(支援性參與者, Supporting Actor)的服務。
★註1、界定系統範圍，必然會命名該系統，系統的名稱其實反應的就是該專業領域內最常用的術語(terminology)，術語就是一種概念(concept)，若概念是模糊、沒有一致性，團隊開發的過程中，必然會出現嚴重的認知差距與溝通不良問題。
合成結構圖 – 表達硬體產品的介面與內部的組件
（點擊圖片鏈接看原圖）圖1、範例–寬頻路由分享器的複合結構圖概觀
圖1是 “寬頻路由器” 的 “想像” 概觀視圖，因為筆者並非該領域的專家，無法畫出正確詳細的內部組件結構關係，但未來只要藉由與領域專家的溝通合作，在後續的開發循環 (Iteration)，要修正之，其實是很容易的。請記得，筆者從來都是假設需求不明確、流程有問題的情況下，只要確定了一個框架目標，就可以馬上實踐之，可千萬不要等到規格都很清楚的情況下才開始動工，這會很容易陷入 “分析癱瘓” 的。
圖1，是 UML 2.0 所新增的 “合成結構圖”，畫出該圖的主要步驟為：
- 觀察並分析寬頻分享器所提供(support)與需要(required)的介面(Interface)。
- 觀察並分析寬頻分享器內部結構是由哪些主要的組件(part) 所組成。
- 找出組件之間的關連(connector)、以及組件與介面之間的 “委託連接器(delegating connector)”。
從圖1，筆者關心的是，應用軟體的核心是位於哪一個 “黑盒子” 組件，以及，該黑盒子是否有與其它的組件連結。若是站在 ODM(Original Design Manufacturing) 軟體廠商的角度來看時，未來得以讓他們加以發揮的加值軟體應用程式會是位於 “RCS (Router Control System)” 組件內，所以，RCS 成為整個寬頻分享器應用軟體的核心。
使用案例圖 – 表達 RCS 系統的功能觀點
（點擊圖片鏈接看原圖）圖2、範例–表達寬頻路由分享器內 RCS 系統的使用案例模型
RCS 確定應用程式的核心所在，當確立共識後，再來就是將焦點轉移至 RCS，並且 “放大”，分析檢視出 RCS 會提供哪些 “系統功能 (System Functions)” 供外部的參與者 (Actor)來使用，這些 “系統功能”，在使用案例圖中，稱之為 “使用案例(Use Case)”。
誰來使用系統，就會成為該系統的 “主要參與者 (Primary Actor)”，圖2 的案例中，網路管理員其實是外部寬頻分享器的主要參與者，但網管人員透過寬頻分享器的介面所連進來的系統就是由 RCS 負責，所以，網管人員同時就會成為 RCS 的主要參與者。
RCS 是否需要其它系統的服務支援，若是，其它系統就成為 RCS 的 “支援性參與者 (Supporting Actor)”。從圖1 可以看出，主要與 RCS 連結的組件有微處理器、快閃記憶體 (Falsh Memory) 等，所以兩者都可以成為 RCS 的支援性參與者。其中，”Flash Memory” 的角色蠻有趣，它如同企業資訊系統的資料庫，若是，筆者會傾向看成是 RCS 系統的 “私有倉儲 (private storage)”，而不會將之視為是外部的系統，圖2 特別把它畫出來是反應圖1的合成結構圖中，”Flash Memory” 是明確獨立的硬體組件。
結語 – 發掘潛在獲利的需求，實現在嵌入式系統內
確認了硬體產品的整體(寬頻分享器)與核心焦點(RCS 嵌入軟體系統)後，團隊就有容易有一致性的共識與全貌，然後才是實現(Realize)核心系統所提供的功能，甚至，團隊可以據此集思廣益，來發掘出潛在的需求。例如，A 牌的寬頻分享器就發掘出分享器同時可以提供 Web 與 FTP、甚至提供個論壇(Forum)系統(未嘗不可！)的服務，更賦予了分享器多功能的面貌與價值。
不過圖2 是看不出 RCS 系統的內部平台為何，例如，是使用“Embedded Linux”、“Windows CE”，還是“RTOS (Real Time OS)”的作業系統，以及 OS 所提供的應用程式介面(APIs)，與系統的框架(Framework)為何，這是屬於系統內部的結構分析與設計的範疇。其實，筆者更為關心另一個議題，筆者常以為，嵌入式系統的應用軟體產品的開發理當建立“一致性模型”，也就是與平台獨立的軟體模型 (PIM, Platform Independent Model)，如此經濟效益當然能發揮到最高。不過，那又是另外一段故事了 …。
建立“合成結構圖”，由此導出“使用案例圖”，從整體看局部的焦點，從低精確度逐漸地至高精密的細節，在需求分析的階段過程中，用最少的精力，找出最重要的精華與本質，一開始把焦點集中在對的目標(Goal)上，勝過於忙忙碌碌，結果花在太多沒有必要的工作與細節上。
※ 延伸參考 ※
「從企業流程(活動)圖找出資訊系統的使用案例」。
