前進 2021 年 Embedded World 展覽：第三篇

編者註：此系列部落格文章關於 2021 年嵌入式電子與工業電腦應用展 (Embedded World)，且一共有五篇，此第一篇文章將概述本展覽的內容。在此系列第二篇文章中，Randy 重溫其 C 程式語言能力。此部落格第三篇文章將著重說明物件導向程式設計如何降低複雜性。第四篇將說明良好的設計基礎在於有能力隨著需求改變而再次配置，無需重新實作建構模塊。最後第五篇部落格文章中將提前在 Randall 於 2021 年 Embedded World 展覽發表專題演講前，質疑作業系統是否需要無止盡擴充的空間，並且探討系統解構的議題。

從上個月至今，我一直將焦點擺在複雜性上，是因為我相信產業需要降低複雜性，我指的是使用電氣裝置時所涉及的複雜性 (提到電氣時，我主要是指電子)。我推測，裝置內部的複雜性會繼續提高。如何整理此複雜性，將是下篇文章的主題。

我在第一篇文章提過，電氣工程 (EE) 學科的註冊人數落後其他工程學科。儘管如此，我確信未來電氣裝置只會變得更多，不會更少。我更相信，電氣裝置的應用範圍會比現在還廣。創客運動即可作為例證。

電氣裝置引起廣大興趣，自製的物件種類似乎也無窮無盡。即便是未正式受過電氣工程訓練的人，對此也興致高昂。截至 2020 年第 46 週為止，maker.io、MikroE、Adafruit、Seeed 和 SparkFun 等網站，每月共吸引數百萬名不重複訪客造訪網站 (見下方圖 1)，由此顯示人們對電子裝置興致勃勃。

圖 1：服務電子裝置愛好者的網站每月不重複訪客人數

事實上，我認為電氣裝置市場遠不止是滿足電氣工程師的需求而已。電氣工程師在處理最高的複雜性方面受過訓練，或至少知道如何著手處理。不過，我認為商機在於，讓未受過充足訓練的人也懂得開發電氣裝置。簡單來說，根據我的推想，如果電氣工程師能讓電子裝置和子系統變得更容易使用，我們就能促成更大的市場。

上個月的文章最後，我談到了物件導向程式設計 (OOP)。有人認為 OOP 會增加複雜性，因為必須掌握更多的概念。我之後會談到這些概念，但現在，我要說明的是 OOP 如何降低功能重複使用性的複雜度。我也會舉例加以說明。

我的女婿擁有商學位，但他現在註冊攻讀資訊科技研究所。他跟我分享最近的一份課堂作業。他必須自己創作一套 3D 動作遊戲。

雖然他沒正式學過或接觸過任何一種 3D 圖形或即時編程技術，但他實作成功了。在教授的建議下，他使用 Unity 平台實作遊戲。雖然我在一開頭講到複雜性，但現在我要談談「重複使用性」。

我最愛的一本書是《UML 物件導向設計基礎》(Fundamentals of Object Oriented Design in UML)，作者是 Meilir Page-Jones。買這本書以前，我雖然已經有豐富的 OOP 經驗，但我知道我還是弱雞，而我想要變強。

資料來源：Amazon (https://www.amazon.com/gp/product/020169946X/ref=dbs a def rwt bibl vppi i0)

Page-Jones 以積體電路的比喻來解釋 OOP 概念，這讓我感到很開心。Page-Jones 說，這個觀點取自 Brad Cox 在 1986 年的著作，書名為《物件導向程式設計：不斷演進的做法》(Object-Oriented Programming: An Evolutionary Approach)。此外，Page-Jones 還引述了 Merrill Skolnik 的《雷達系統導論》(Introduction to Radar Systems)，書中說道：「電子工程能根據 (1) 元件、(2) 技術和 (3) 系統進行分類」。Skolnik 繼續解釋：「元件是基本的建構模塊，利用適當的技術結合在一起，以構成系統。」Page-Jones 建議用「軟體」取代「電子」、用「級別」取代「元件」，而這是相當實用的軟體系統觀點。

Page-Jones 繼續說明，要挑選哪些值得納入電系統的元件，取決於電氣工程師辨別抽象化是否實用的能力。他表示在第一個積體電路創造之前，工程師已經花了數十年的時間探索電子系統所需的有用模式。他利用這一點，幫助 OOP 開發人員瞭解到自己必須辨別出「健全、強大、便利」的級別。他說，除非那些元件能彼此相連，否則 Skolnik 所闡述的技術就無用武之地 (Skolnik 使用的是印刷電路板)。

我想表達的是，積體電路和物件導向程式設計基本上是同一概念的兩種不同實作。我承認，軟體工程看起來比硬體工程寬鬆許多。現在，似乎任何人都可以進行軟體實作，但要說軟體很容易「連接」就不對了。

MyHDL 的創造者 Jan Decaluwe 在其部落格文章中說到，在使用硬體描述語言 (HDL) 的數位設計中，利用 Verilog 或 VHDL 描述算術其實相當複雜、令人困惑，一點都不簡單。我認為，無論是可編程邏輯還是軟體系統，如果要擴大市場，軟體設計一定要做得更好。

本月文章已接近尾聲。最後我要說明「良好的」OOP 設計需要涵蓋哪些概念。最常用的概念是凝聚性和耦合性。凝聚性是指封閉式單元零件之間的關聯性，無論是軟體級別、數位模組還是積體電路。高凝聚性比低凝聚性好，因為系統更容易理解，在測試和維護等方面也更簡單。耦合性是指一個軟體或硬體要件彼此之間的連接性和依賴度。低耦合比高耦合好，因為一個要件有所變動時，另一個只會受到最低程度的影響。

Page-Jones 創造了「共生性」(connascence) 一詞，來說明耦合的危險性。按照 Page-Jones 的說法，這個詞源自拉丁文，意思是「一起誕生」。他補充說，這代表「命運共同體」。以下是他對共生性的正式定義。

當兩個軟體 [或硬體] 要件 A 和 B 之間具有共生性，即表示以下之一情況：

• 假設 A 有所變動時，B 也必須改變 (或至少必須仔細檢查)，才能維持整體的正確性，或是
• 假設需要做出變動，則 A 和 B 必須一起改變，才能維持整體的正確性。

請注意，上述定義裡，括號內的字是我補述的。Page-Jones 繼續說明了十多種共生性類型。其中一種形式取決於函數調用時引數的順序。如果順序改變了，所有相依函數也必須改變。注意，他在解釋共生性的概念時，也強調維持差異性很重要。共生性在 OOP 本質中特別適用，因為在此概念中，物件是類型相同但必須彼此分別的實例。

除了凝聚性、耦合性和共生性，還有其他概念有助於瞭解良好的 OOP 設計是如何。我列在這裡，供大家參考：

• 封閉性
• 資訊／實作隱藏
• 狀態保留
• 物件身份
• 訊息
• 級別
• 本質
• 多型
• 泛型

這些主題在前述 Page-Jones 的著作及其他 OOP 教科書中都有充分說明。

好了，我在複雜性的主題上說得太複雜了。雖然要考量的面向很多，但最基本的是，我們的目標是開發出有用的黑盒子，能讓任何人都藉此製作出新的電氣裝置。之所以是「黑」盒子，是因為我們不想或不需要洩漏裡面的內容。我們希望黑盒子的介面盡可能簡單，不必在意盒子內部的複雜性。

現在，我們對於追求的目標可能已經知道如何評估其是否良好，但我還沒談到如何實際將系統和子系統解構成可重複使用的元件或模組。這將是下一篇部落格文章的主題。