抽象工具排解系統設計復雜性
——
加入技術交流群
抽象工具排解系統設計復雜性
嵌入式開發工具不斷包含更高層次的抽象來平衡設計復雜性的增長
要點
● 抽象通過隱藏細節來降低復雜性。
● 抽象不會減少某項設計的細節數量。
● 自動化開發工具可簡化以前的創新設計思路和實現方法，并使之商品化。
● 抽象隱藏細節，但不應該妨礙您檢查細節。
復雜性是相對的。如果您無法在特定環境內描繪問題的特性并了解問題，那么復雜性就會使您無法解決問題。同時，復雜性為你提供制造出與眾不同產品的機會。再則，復雜性如果被你攻克，就會成為您搞出與眾不同設計的基礎，并成為競爭對手的障礙，盡管是臨時障礙。如果沒有足夠的復雜性，就很難提供獨特的增值功能， 這是因為競爭對手可以很容易地仿制您的開發成果，并在他們的產品中增加這些功能。
一條工程經驗法則是：設計小組能夠以最低成本，在最短的開發時間內交付組合有最佳功能的產品，條件是他們只關注其中的兩個要素，犧牲第三個要素。在一個競爭的領域內，至關重要的是要實現所有這三個要素，這又會提高設計成果的總復雜性（附文《無法滿足的胃口》）。幸好，您不必徹底了解產品的每一個細節就能使用它。使用能支持特定領域的抽象工具或能為自己正在研制的系統創建特定抽象的工具，就是一種降低設計復雜性、提高開發效率的技術。
抽象是對某系統的細節進行組織的過程，這樣您就可以專注于總體情況的關鍵要素。抽象并不會減少——甚至還可能增加——您必須為某項設計而要處理的細節數量。然而，抽象能夠組織這些細節，以便您能減少你為設計中任何一部分必須考慮的細節數量。建立有用抽象的挑戰性在于根據環境和誰將使用這些抽象，確定哪些性能是必不可少的，哪些性能是可以忽略的。抽象是智能框架，從多個方面對某個系統進行抽象也許是很有用的。設計師和用戶也許需要使用同一系統的不同抽象。對于分層抽象來說，工作在每個抽象層次的設計師也許需要與一組不同的細節打交道。
對某個系統適當地進行抽象，可以為設計小組的每名成員降低系統復雜性，這是因為您可以避免每位設計師去考慮不相關的細節。實際上，您是在簡化和限定每一位設計師必須面對的條件范圍。抽象某個系統，可能有利于匯總系統微觀行為，以便能在宏觀層次揭示微觀行為，使之概念化，再進行處置。有時，不必了解各事件的具體順序就可以從存儲器中提取數據，或對這些數據進行算術運算。然而有些時候，例如，當您的系統對連續數據流進行實時的計算密集型操作時，了解并控制這兩種機制的細節對于項目的成功是至關重要的。
抽象某個系統可以幫助您鑒別、隔離并管理一個系統的邏輯部件之間在計算和接口兩個方面的相關性，這樣您就能在各部分中解決大問題。如果您缺乏恰當的詞匯和其它符號工具來表述某個問題，您就會在解決該問題時面臨嚴重的障礙。恰當地抽象某個系統，可以為您提供詞匯和符號集，從而在設計小組成員之間就各個部分及其相互關系進行有意義的溝通。恰當的詞匯和符號集是適用于特定應用和特定領域的。一個標準的或通用的符號集可能無法使您充分表述您正在努力解決的系統和問題，它可能會使您偏向采用一種次優方法。
工具、工具、工具
產品設計正在一代一代地增加占用更多處理能力的復雜功能，而產品設計周期比以往任何時候都短。為了跟上這些設計日益提高的復雜性，開發小組可以依靠以下手段：重復使用既有設計；獲得第三方知識產權 (IP) 的許可證；使用各種抽象或隱藏目標平臺實現細節的工具。匯編器、編譯器、建模工具、代碼發生器、操作系統和外設驅動程序都能隱藏目標處理平臺的細節，而且一般都能提高設計師的工作效率。這幾類工具通常不提供應用級抽象；它們按分層方式工作，從而抽象目標實現細節并使之自動化，而無需了解系統的行為。
另一類代碼發生器，比如 Celoxica 公司和 Stretch 公司的產品，有助于把 C 源碼自動轉換成硬件塊。這些工具使您能夠保持一致的軟件開發方法，并仍能受益于采用并行單元的硬件處理速度加快。AccelChip 公司和 Catalytic 公司的代碼發生器工作于更高的層次，直接依靠 Matlab 文件，來生成可合成的 RTL，或把浮點模型轉換成定點目標代碼。
應用抽象工具試圖使系統行為與實現方法無關。Aonix公司、The MathWorks公司、National Instruments公司、Teja 公司提供的工具，能為十分關鍵的信號安全處理或高度并行的多處理器應用系統提供特定域抽象。特定域抽象工具包括合適的符號工具和結構，而這些工具與結構使您能更自然地表述和探索該域中的設計方法，不過在目標域之外，它們的用處通常是有限的。通用抽象工具，如 I-Logix 公司和 IBM 公司的 UML（統一建模語言）工具， 使您能夠創建自己的抽象，而且在更廣的應用范圍內都很有用，但要依靠您運用您的工程專業知識來構建有意義的特定域抽象。
圖 1，UML 是OMG公司 的模型驅動體系結構的基礎。與平臺無關的模型包含系統行為，而特定平臺模型根據特定平臺映射規則和與平臺無關模型的標記，包含實現細則。
MDA（模型驅動的體系結構）開發工具使系統行為細節的建模與實現方法細節的建模無關，具體做法是將這些模型分割成與UML 平臺無關的模型和特定平臺模型（圖 1）。與平臺無關模型不包括技術實現細節，側重于描述系統的功能和行為。MDA 開發工具應用映射模板來產生特定平臺模型。為了實現這種轉換，您必須精確調節與平臺無關的模型，并對它做注釋，以便加進語義學和規則，用以生成代碼。MDA 開發工具根據這些模型產生機器生成的代碼，您可以對照行為模型來測試已生成代碼的正確性。如果您改變行為模型或實現模型，則重新生成的代碼始終會利用這些變化。
只要對較低層次實現細節的生成進行抽象和自動化，這些工具就能提供一種使設計能在各種目標平臺之間移植，并使設計塊能被反復使用的機制。然而，抽象只能實現移植機制。例如，如果目標處理器沒有代碼生成器，您就必須人工移植設計實現。除了這些益處之外，隨著更高層次的工具在目標級變得更成熟、更便于使用、更有效，能夠維持既有設計細節并實質性參與嵌入式設計的人數會相應增多（圖 2）。擁有技巧和知識以便使用較低級別工具進行設計的人現在要比能使用較高級工具進行設計的人少。
要點
● 抽象通過隱藏細節來降低復雜性。
● 抽象不會減少某項設計的細節數量。
● 自動化開發工具可簡化以前的創新設計思路和實現方法，并使之商品化。
● 抽象隱藏細節，但不應該妨礙您檢查細節。
復雜性是相對的。如果您無法在特定環境內描繪問題的特性并了解問題，那么復雜性就會使您無法解決問題。同時，復雜性為你提供制造出與眾不同產品的機會。再則，復雜性如果被你攻克，就會成為您搞出與眾不同設計的基礎，并成為競爭對手的障礙，盡管是臨時障礙。如果沒有足夠的復雜性，就很難提供獨特的增值功能， 這是因為競爭對手可以很容易地仿制您的開發成果，并在他們的產品中增加這些功能。
一條工程經驗法則是：設計小組能夠以最低成本，在最短的開發時間內交付組合有最佳功能的產品，條件是他們只關注其中的兩個要素，犧牲第三個要素。在一個競爭的領域內，至關重要的是要實現所有這三個要素，這又會提高設計成果的總復雜性（附文《無法滿足的胃口》）。幸好，您不必徹底了解產品的每一個細節就能使用它。使用能支持特定領域的抽象工具或能為自己正在研制的系統創建特定抽象的工具，就是一種降低設計復雜性、提高開發效率的技術。
抽象是對某系統的細節進行組織的過程，這樣您就可以專注于總體情況的關鍵要素。抽象并不會減少——甚至還可能增加——您必須為某項設計而要處理的細節數量。然而，抽象能夠組織這些細節，以便您能減少你為設計中任何一部分必須考慮的細節數量。建立有用抽象的挑戰性在于根據環境和誰將使用這些抽象，確定哪些性能是必不可少的，哪些性能是可以忽略的。抽象是智能框架，從多個方面對某個系統進行抽象也許是很有用的。設計師和用戶也許需要使用同一系統的不同抽象。對于分層抽象來說，工作在每個抽象層次的設計師也許需要與一組不同的細節打交道。
對某個系統適當地進行抽象，可以為設計小組的每名成員降低系統復雜性，這是因為您可以避免每位設計師去考慮不相關的細節。實際上，您是在簡化和限定每一位設計師必須面對的條件范圍。抽象某個系統，可能有利于匯總系統微觀行為，以便能在宏觀層次揭示微觀行為，使之概念化，再進行處置。有時，不必了解各事件的具體順序就可以從存儲器中提取數據，或對這些數據進行算術運算。然而有些時候，例如，當您的系統對連續數據流進行實時的計算密集型操作時，了解并控制這兩種機制的細節對于項目的成功是至關重要的。
抽象某個系統可以幫助您鑒別、隔離并管理一個系統的邏輯部件之間在計算和接口兩個方面的相關性，這樣您就能在各部分中解決大問題。如果您缺乏恰當的詞匯和其它符號工具來表述某個問題，您就會在解決該問題時面臨嚴重的障礙。恰當地抽象某個系統，可以為您提供詞匯和符號集，從而在設計小組成員之間就各個部分及其相互關系進行有意義的溝通。恰當的詞匯和符號集是適用于特定應用和特定領域的。一個標準的或通用的符號集可能無法使您充分表述您正在努力解決的系統和問題，它可能會使您偏向采用一種次優方法。
工具、工具、工具
產品設計正在一代一代地增加占用更多處理能力的復雜功能，而產品設計周期比以往任何時候都短。為了跟上這些設計日益提高的復雜性，開發小組可以依靠以下手段：重復使用既有設計；獲得第三方知識產權 (IP) 的許可證；使用各種抽象或隱藏目標平臺實現細節的工具。匯編器、編譯器、建模工具、代碼發生器、操作系統和外設驅動程序都能隱藏目標處理平臺的細節，而且一般都能提高設計師的工作效率。這幾類工具通常不提供應用級抽象；它們按分層方式工作，從而抽象目標實現細節并使之自動化，而無需了解系統的行為。
另一類代碼發生器，比如 Celoxica 公司和 Stretch 公司的產品，有助于把 C 源碼自動轉換成硬件塊。這些工具使您能夠保持一致的軟件開發方法，并仍能受益于采用并行單元的硬件處理速度加快。AccelChip 公司和 Catalytic 公司的代碼發生器工作于更高的層次，直接依靠 Matlab 文件，來生成可合成的 RTL，或把浮點模型轉換成定點目標代碼。
應用抽象工具試圖使系統行為與實現方法無關。Aonix公司、The MathWorks公司、National Instruments公司、Teja 公司提供的工具，能為十分關鍵的信號安全處理或高度并行的多處理器應用系統提供特定域抽象。特定域抽象工具包括合適的符號工具和結構，而這些工具與結構使您能更自然地表述和探索該域中的設計方法，不過在目標域之外，它們的用處通常是有限的。通用抽象工具，如 I-Logix 公司和 IBM 公司的 UML（統一建模語言）工具， 使您能夠創建自己的抽象，而且在更廣的應用范圍內都很有用，但要依靠您運用您的工程專業知識來構建有意義的特定域抽象。
圖 1，UML 是OMG公司 的模型驅動體系結構的基礎。與平臺無關的模型包含系統行為，而特定平臺模型根據特定平臺映射規則和與平臺無關模型的標記，包含實現細則。
MDA（模型驅動的體系結構）開發工具使系統行為細節的建模與實現方法細節的建模無關，具體做法是將這些模型分割成與UML 平臺無關的模型和特定平臺模型（圖 1）。與平臺無關模型不包括技術實現細節，側重于描述系統的功能和行為。MDA 開發工具應用映射模板來產生特定平臺模型。為了實現這種轉換，您必須精確調節與平臺無關的模型，并對它做注釋，以便加進語義學和規則，用以生成代碼。MDA 開發工具根據這些模型產生機器生成的代碼，您可以對照行為模型來測試已生成代碼的正確性。如果您改變行為模型或實現模型，則重新生成的代碼始終會利用這些變化。
只要對較低層次實現細節的生成進行抽象和自動化，這些工具就能提供一種使設計能在各種目標平臺之間移植，并使設計塊能被反復使用的機制。然而，抽象只能實現移植機制。例如，如果目標處理器沒有代碼生成器，您就必須人工移植設計實現。除了這些益處之外，隨著更高層次的工具在目標級變得更成熟、更便于使用、更有效，能夠維持既有設計細節并實質性參與嵌入式設計的人數會相應增多（圖 2）。擁有技巧和知識以便使用較低級別工具進行設計的人現在要比能使用較高級工具進行設計的人少。
評論