前言
嵌入式系統(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);而“純”軟體應用系統,系統分析人員要能有較高度抽象的能力,才能以“心眼”看到與界定系統的範圍。要能在嵌入式系統做好有效的需求分析與設計,只有一個關鍵:
“找出那一個黑盒子(界定系統範圍),瞭解該黑盒子在硬體產品內的角色與定位”。


Kenming's 軟體設計
Kenming's .NET 實作
since 2004.05.11
關於本站授權聲明