前言

嵌入式系統(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 所新增的 “合成結構圖”，畫出該圖的主要步驟為：

1. 觀察並分析寬頻分享器所提供(support)與需要(required)的介面(Interface)。
2. 觀察並分析寬頻分享器內部結構是由哪些主要的組件(part) 所組成。
3. 找出組件之間的關連(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)上，勝過於忙忙碌碌，結果花在太多沒有必要的工作與細節上。

※ 延伸參考 ※
「從企業流程(活動)圖找出資訊系統的使用案例」。