嵌入式系统导论--（精选）公开课件.pptVIP

嵌入式系統導論, 探矽工作室 第三章 嵌入式系統的系統設計 本章學習重點 設計系統 考慮因素 設計系統方法論與過程 設計流程的方法 需求分析與規格 整合設計及品質保證的方法 設計系統議題 設計方法論 設計目標 設計主要步驟 設計流程方法 設計方法論 設計方法論（design methodology）有以下三個重要理由 確認我們所做的每一件事情都是必須要作的 不會做無謂的白工，也不會漏掉關鍵性的重要工作，其中包含效率最佳化或是功能測試。 可以發展出電腦輔助工具或是設計經驗累積 汲取每一次產品發展的經驗。再經過量化之後，可以發展出一套工具或是方法，讓往後的產品設計步入自動化。 開發團隊遵循同一套方法論 可以讓團隊成員更容易彼此溝通。每個人都能在短時間內瞭解整體過程中將經歷哪些過程，需要何種支援與接收到何種結果；此外，也容易透過一套已經定義好的方法論，彼此相互合作協調。 設計目標 上市時間 也就是time-to-market的觀念。 設計成本 許多消費性產品對於價格非常敏感，所以產品廠商對於成本會斤斤計較是很合理的。 品質 顧客也許不需要最快最便宜的產品，但是一定會要求功能品質保證，不能只用一小段時間就壞掉了。 設計主要步驟 設計流程方法 瀑布模型(Waterfall) 螺旋模型(Spiral) 連續改進(Successive Refinement) 硬體與軟體的同步設計(SW/HW Co-deign) 階層式(Hierarchical)設計 同步工程（concurrent engineering） 瀑布模型(Waterfall) 螺旋模型(Spiral) 連續改進(Successive Refinement) 硬體與軟體的同步(SW/HW Co-deign) 設計流程 階層式(Hierarchical)設計流程 同步工程（concurrent engineering） 企圖採用一個較廣泛的看法讓整體流程最佳化。 這種方式的目的是要消除每個小型系統設計者之間的藩籬，以免設計者侷限在自己的看法而無法與其他設計者進行溝通，造成反覆或衝突的情況不斷發生。 需求分析與規格 第一階段 收集客戶所描述的訊息，整理成需求列表； 第二階段 把這些需求進一步萃取之後，定成規格（specifications） 這些規格就是系統架構設計的資料。 需求的種類 功能性需求是指系統必須要有哪些功能 非功能性需求則是指其他因素，像是大小、價格、設計時間等 常見的非功能性需求 效能 成本 實體大小與重量 電力消耗 證實需求 確認列出來的需求是真的為客戶所需要 透過模擬系統來證實需求 這個模擬系統將一些事先準備的資料來模擬一些功能，當作一個有功能限制的展示系統 說明實際作出來的系統將如何運作，可以增進客戶與設計者之間的認知 建議需求表格 好的需求文件 正確性：一個需求描述不可以誤解顧客所需，也不該過份描述不需要的需求。 精準性：需求文件應該做清楚的描述，而不是籠統的說明。 完整性：所有的需求都應該紀錄。 可證明性：所有的需求都應該有方式去證明這項需求是合理的，像是文件裡就不應該出現「親和的介面」這類字眼，因為無法定義什麼叫做親和的介面。 一致性：某項需求不應該和其他需求相互衝突。 可修改性：既然可以建立需求，當然也可以修改需求，而且不會違反上述的特性。 可追蹤性：每份文件都應該可以追蹤，包括為什麼會有這樣的需求開出來，彼此需求間的相關性，這些需求是否可能實現，以及最後是否滿足這些需求。 規格 規格比需求更精確許多，這是當作客戶與架構設計團隊之間的契約，所以在撰寫時需更加小心，才能夠正確的反應客戶的需求，並且在接下來的設計期間瞭解每一步設計過程 規格一定要讓人一目了然，符合系統的需求，也能讓客戶很清楚的瞭解他會得到什麼樣的產品。設計者常常會因為不清楚規格而產生一些問題，例如誤解規格裡某些功能，結果做出錯誤的功能，或是規格裡某些地方不完整，導致最後忽略了許多必要的功能。 透過規格制訂語言使大家清楚規格描述 規格與架構描述方法 統一塑模語言(Unified Modeling Language) SDL語言( Specification Description language) OR/AND狀態圖/表(State-based Diagram/Table) 方塊圖（block diagram） CRC卡片 統一塑模語言(Unified Modeling Language) UML是一種描述規格的語言，藉由這套語言的表達，達到系統正規化的表述，使所有看過規格的人都瞭解所描述的產品是什麼 一種物件導向（object-oriented）的塑模語言 鼓勵將設計分成好幾個互動物件的方式，取代單一方塊的設計 這些物件可以