高質量嵌入式系統開發的集成測試技術
加入技術交流群
將UML模型有效地用于嵌入式應用的軟件工程，要求開發進程能確保：模型是嚴格而完整的；在不影響模型的情況下優化所生成的系統實現；系統的整體結構由進程通過多個版本及要求的升級來維持。
為達到這些目標，基于模型的軟件工程采用一種轉換方法，重點討論采用這種轉換方法在代碼中添加測試支持，但該技術也可應用于手工實現的UML模型。這種轉換方法的特點將在下文介紹。
b. 分析模型
分析是針對問題本身為其建立與實現無關的模型方案的過程。有效的分析模型是嚴密而完整的，而且與實現方法無關。UML是由OMG定義的一種標準符號，主要用于表達分析建模。分析過程可以產生：
域(domain)模型：這是一種UML類圖，它將系統分解成獨立的主題區域，稱為域。這些域由包和從屬箭頭顯示橋表示，其中后者是域之間的需求流(flow of requirement)。可以對域進行分析，或者用其它方法開發，如人工編寫的代碼、繼承代碼、從其它源生成、從某個庫導入等等。域服務是組成域接口的方法。由于域為某個問題區定義了完整的規范，所以可以獨立對其測試，然后再與其它域結合以便進一步測試。
信息模型：對于每一個要分析的域來說，UML類圖可用于定義組成該域結構的類(class)。類之間互相關聯，還可繼承其它類。
情境(scenario)模型：UML序列表或UML協作圖捕獲某個特定域的主要情境，用于表現域服務(操作)、類服務(方法)、類事件消息及該域引用的域外服務之間的相互作用。
狀態模型：對于接受事件消息的每一個類來說，UML狀態圖可用于捕捉類周期，并定義該類與狀態有關的特性。
行為模型：對于每個域服務、類服務和狀態行為，都會生成一個詳細而明確的行為描述。這由一種行為語言來表達，這種分析級“編程”語言提供了完整的分析級執行基元，而不會影響實現。用行為語言來表示行為細節，可以在實現分析基元的轉換階段之前保留極大的自由度，這對于優化至關重要。
c. 設計
設計是產生可將分析構造映射到運行時間環境中的策略和機制的過程。其概念與分析不同，大部分初步設計工作可以在與分析活動無關的情況下進行。
d. 轉換
轉換是用設計策略將每一個要分析域的UML模型映射到實現的過程。設計分兩個階段進行：
結構設計：識別系統的執行單元(線程/任務/進程)，將其分配至處理器，并將域分配至單元。
機械設計：開發將分析映射到實現的詳細模式(用模板描述)，并建立基本機制以支持這一實現。
評論