主頁（http://m.by236.com）：嵌入式DVR軟件中用結構化語言實現面向對象的設計思想 嵌入式DVR是一種高度集成、復雜的嵌入式設備，其軟件需要保證良好的可靠性、復用性、擴展性及高效性。 傳統的結構化設計方法，在其軟件設計中就有些“力不從心”，因為結構化的軟件要求軟件設計一開始就假定軟件需求是很明確的，系統處理數據的模式和方法也是明確的。然而DVR的用戶是面向不同領域的，而每個客戶的要求都有所不同，如有的客戶可能需要用RS485總線來控制溫度采集器，有的則可能需要來控制云臺，這在結構化設計方面就需要用不同的數據結構和方法來描述。因此，每當針對不同客戶就需要專門定制不同的軟件版本，這無疑增加了軟件的維護和測試成本，這是DVR生產廠商所不愿意看到的。并且，面向對象的設計思想需要采用面向對象的設計語言，無疑是對嵌入式設備一個巨大的考驗。當然，現在不少嵌入式開發工具，已經支持C++、JAVA等面向對象的設計語言。但是這些面向對象的語言需要很大的C++設計庫，這會增加DVR對存儲設備容量的要求。而且面向對象的設計語言在執行的時候會添加一些額外的代碼，如“析構”、“構造”函數，會導致執行效率比結構化的設計語言要低。因此一些編譯器對面向對象的設計語言的支持遠沒有對結構化的設計語言高。如LINUX下的GCC編譯器附帶的調試工具，在調試C++程序中有時就無法打印堆棧和函數的調用關系。 新型軟件設計方法 這種設計方法的實質是：用面向對象的設計思想去分析嵌入式DVR的需求；用面向對象的設計模式去設計DVR軟件構架；用結構化的語言去實現DVR系統功能。這樣一來，就可以發揮面向對象設計思想在需求分析和建模方面的方便快捷直觀的優點，同時又能保證嵌入式軟件在執行效率和存儲方面的要求。 當然，我們必須摒棄一些面向對象設計思想中需要依賴面向對象設計語言的一些特性，如運行中的多態，類型識別等。這些行為也能夠在結構化語言中實現，只是有些特性對系統設計來說就有點無關輕重了。如果把所有面向對象的特性都拿來用，這就會導致設計走向另一個極端：在嵌入式開發上使用面向對象的語言來設計系統。特別值得指出的是，面向對象語言中的內存分配，如果在嵌入式軟件上設計使用，會導致頻繁的動態分配不定大小的內存，會引起系統堆棧破碎的風險。 面向對象軟件 設計人員采用比較實用快捷面向對象的MVC結構，即模型－視圖－控制器結構，把整個系統分成三個部分：一部分是底層的軟件部分，我們在DVR軟件稱為“微內核”；一部分是人機交互部分，即界面部分；另一部分則是兩者之間的接口，我們稱之為適配器。在軟件架構上也分為三個大的部分（或者說三個軟件包）：界面、“微內核”、界面和“微內核”之間的接口。 這三個部分在迭代中最先完成的是“微內核”部分。而“微內核”設計中最關鍵的就是錄像部分，這需要考慮到各種不同的錄像種類和各種錄像條件，而做好錄像部分的用例分析就可以設計出微內核的基本架構，也就是整個軟件的“靈魂”。 完成第一次迭代設計后，DVR軟件的其它需求的開發就是一個“添枝加葉”的過程。根據面向對象設計“高內聚、低耦合”的思想原則，每次迭代的過程我們都采用模塊化的設計，。在添加每一個模塊時，統一各個模塊的接口，采用“模塊名_domsg”做為對外接口。這樣一來，就能很好地屏蔽掉各個模塊的內部處理機制，減少軟件開發的耦合程度。如“微內核”中的錄像部分可能需要讀出硬盤模塊提供的分配目錄信息。，就可以通過“hdisk_domsg”來獲取。 各個模塊開發 struct Module_Obj 在模塊開發中，也可以采用面向對象的設計模式。設計人員在采用軟件設計的過程就采用了很多“四人幫”（即“GOF”，四個國外開發者，提出面向對象軟件開發中的常用設計模式）的設計模式。如在系統啟動后就采用創建式的單例模式分配系統內存，保證系統各個模塊在系統中唯一。又如報警模塊中采用了observer(觀察者)模式，其它模塊如果要獲取報警信息，可先向該模塊注冊需要的報警信息，當該報警模塊發現有改變報警端子有報警的時候，就會把報警信息逐個通知各個已經注冊的模塊。這些模式的采用能夠很好地提高代碼的健壯性。 界面 |
