3 面向對象嵌入式系統開發筆記3-疊代和增量式的嵌入式系統開發過程
3.1智力勞動和機械勞動
管理把勞動在複雜性視角上分為簡單和複雜勞動。同樣從智能視角可劃分為機械和智力勞動。機械勞動結構方面是針對某一/某幾個部分發生作用，從行為方面說是有限序列的重複作用。智力勞動結構上說多點作用，權重分布不是簡單的線性，行為方面，對多點的作用是一個綜合和運籌的過程。
人工智能表明，人類大腦是由神經元網絡組成的。人類之是以智慧，文字是很大的原因。事實上，越是越需要智慧的勞動，越需要長時間的學習。知識是如此的廣大，但能進入到每個人大腦的中的知識卻非常有限。大腦中的知識存儲不是替代的方式，而是疊加方法。疊代是人類智力勞動的本質特征，它是由大腦神經元網絡性質所決定的。
計算制品的制作過程無疑時一種智力勞動，它具有智力勞動所固有的絕大部分特點。事實上，在開發軟體過程中，無論是提出需求的使用者還是軟體系統開發人員，對于系統所具有的全部特征尤其是行為特征的認識并不是一次性完成的。
使用者對需求的認識實在抽象概念到具體産品實作再到概念的反複循環中得到的。
開發人員對制品的了解也是在反複疊代過程中完成的。
以往的軟體工程中，解決這種需求變更的理論和方法十分有限，面向對象技術從誕生的那一天開始，就自然地相容了變更問題。
3.2 用例驅動、以架構為中心和疊代增量式過程
目前，計算機解決問題朝着更龐大、更複雜的方向發展，部分原因時計算機的性能逐年增強，使用者期望值随之增大。計算機軟體開發的工程化方法研究沒有停止過，出現了瀑布模型、原型模型、螺旋模型等，對軟體産業發展産生巨大的推動作用。但是軟系統複雜性則更加，加之固有的需求變更等原因，以往的的模型難以應付，另外由于軟體開發在生命過程中描述方法的不統一，各個過程階段之間形成了難以跨越的鴻溝。
軟體問題可以歸結為開發人員将大型軟體所包含的各個部分內建為一個整體協作運作的系統問題。軟體開發團隊需要一種受控的工作方式，需要一個過程來內建軟體開發的方方面面并需要通用的方法或過程來完成如下工作：
-指導一個群組活動的順序
-布置每個開發人員和整個群體的任務
-确定開發何種制品
-提出監控和測量一個項目産品活動的準則
UML主要發起人提出了一種軟體問題解決方案，統一軟體開發過程，包含将一個将使用者需求轉化為軟體系統開發所需要的活動集合，更像是一個通用的過程架構。突出特點可以用用例驅動、以架構為中心、疊代式增量式過程三個關鍵字說明。
目标：指導開發人員有效地實作并實施滿足使用者需求的系統。
衡量：成本、品質、傳遞時間。
3.2.1 用例驅動
參與者：使用者，不僅僅是人。
互動：使用者與系統之間的互相作用。
用例：一個有意義的互動。
用例擷取的是系統(某一級類元）的功能需求，所有的用例集合是用例模型，可以取代需求規格書。
用例除了能夠在使用者、分析和設計人員之間提供了解、交流和達成共識的平台外，也是系統分析、設計、和開發人員進入工作的基礎以及成為系統最後測試驗收的依據。還能夠驅動系統設計、實作、和測試的進行。
每個軟體開發組織的業務流程組織過程可能是不同的，但是一定要有一個業務流程，否則業務組織就會處于混亂狀态。
雖然用例可以驅動過程，但是這個過程不是單向的。用例與系統架構是協調發展的。用例驅動不僅是分析系統需求時，也是開發技術人員介入系統的切入點，而且是各個層級的類元（系統、子系統、類）的構造過程也是從用例開始的。反過來系統架構又會影響用例的調整。
需求捕獲目标：1.發現真正的需求；2.以适合使用者和開發人員的方式加以表示。
真正的需求是指實作時可以給使用者帶來預期價值的需求。注意往往在項目開始，使用者本身也不能十分确定這些東西。
分析和設計期間，使用者模型經過分析模型轉換為設計模型。簡單地說，分析和設計模型都是由類元和說明如何實作用例的實作結合組成的。分析模型是需求的詳細的規格說明，開發人員利用分析模型将需求工作流中描述的用例轉換為概念性類元間的協調。分析模型也可以用來建立可複用的軟體元件。分析模型與設計模型不同，他是一個概念集合而不是軟體實作元素的集合。分析模型中的每個元素都可以從實作它的設計模型中得到跟蹤。
設計模型是一個用于描述用例實作的類元集合。它即關注功能需求和非功能需求，也關注與實作環境有關的并最終影響系統的其他限制。是系統實作的藍圖。和實作模型之間存在直接的映射關系
開發人員根據設計模型實作設計好的類。或者說把設計模型直接精化，實作過程不改變系統結構，隻是在設計好的架構（骨架）裡添加血和肉。軟體開發人員所建立的源代碼和相關文檔的集合就成為實作模型。實作模式是設計模型依某種關系形成的直接映射。這種映射何以通過自動程式實作也可以通過人工完成。
最後，測試工作流期間，測試人員驗證系統是否能夠實作用例中所描述的功能和系統需求。每個測試用例定義了輸入、運作條件和結果的集合。測試用例和相應的用例存在跟蹤依賴關系。執行用例的測試屬于系統功能測試。疊代該過程不同之處在于功能測試不一定等待系統全部完成後才開始，執行用例的測試可以在分析模型、設計、實作模型上以不同的粒度進行。測試模型除了與功能有關的測試（黑盒)用例外，還應該由對于各層級系統的結構和實作方面的測試(白盒)。
3.2.2 以架構為中心
構架這裡一般指軟體系統組織總要決定的集合，是對系統全方位的問題的決策。軟體構架不隻是涉及結構和行為，還涉及到使用、功能、性能、柔性、複用、可了解性、經濟性和技術限制以及折衷方案、美學等。本書中，體系結構表示機械、電子和軟體三個部分的系統結構和之間接口(關系）的定義.
本書中架構是指反應系統軟體類元結構和行為本質特征的軟體體系結構，就像一個建築物鋼筋骨架。系統分析的主要目的之一是獲得一個穩定的和經得起較長時間檢驗檢驗的系統軟體分析架構，而其他元件可以通過疊代逐漸增加和精化。
軟體架構概念包含了系統中最重要的靜态和動态特性。架構是根據用例模型和系統的其他方面限制（硬體的功能與結構、作業系統、網絡通信需求）共同影響綜合形成的。架構刻畫了系統的整體設計，它去掉了細節部分，突出了系統的重要部分。換句話說，它是系統在體系結構層級的抽象。因為究竟什麼是重要的部分依賴于判斷，判斷又來自于經驗，是以，架構的好壞也就依賴于架構設計師的素質。然而，過程可以幫助他們确定正确的目标，如易了解性、适于将來變化的柔性以及可複用性等。也可以從已有的模式中選擇元件或者從中獲得靈感。
每一個系統都具有功能和表現形式兩個方面。這裡功能與用例相對應，通過用例來精細化描述系統行為。用例和架構之間互相影響的。一方面，用例在實作時必須适合架構；另一方面，架構必須預留白間以實作現在或将來需要的用例。事實上，開發過程中架構和用例往往都是并行進化的。
軟體開發不僅僅是盲目依賴用例驅動工作流就能完成的，要得到一個可用的系統還需要考慮更多的因素，比如架構和系統限制，可以把架構看成是所有參與開發的人員必須達成或者至少能夠給共同了解的系統實作的規格說明書。
要建立一個狗窩、小房子、教堂、購物中心或者摩天大樓，情況是不一樣的。許多大型建築需要一組建築設計師來設計它們。設計組成員必須彼此了解設計的進度，也就是說，他們需要把自己的工作用其他成員能夠明白的形式記錄下來，并且用一種非專業人員如業主、使用者和其他項目相關人員等可以了解的方式表達出來。最後，還得通過施工圖紙将設計交給建築商。
一個大型、複雜的嵌入式系統軟體需要一個架構設計師，以便于開發人員可以向着一個共同的目标努力。
嵌入式系統軟體開發過程需要一個架構通常原因如下：
1.了解系統
2.組織開發
3.鼓勵複用
4.進化系統
1.了解系統
系統的描述必須被所有相關人員所了解。以架構為中心和基于模型的開發，可以防止出現這種無法了解的想象。
2.組織開發
通過将系統劃分為帶有明确定義接口的子系統或元件，并讓一個開發小組或個人負責其中的一個部分，無論他們是在哪裡，架構都可以減少負責不同子系統的開發組之間的交流工作量。一個好的架構應該明确定義這些接口，盡可能減少子系統間的通信。
3.鼓勵複用
就像計算機硬體推行标準化需要一定的時間一樣，軟體元件的标準化也需要積累經驗，空吧會需要經曆更長的實踐過程。
軟體産業要達到很多硬體領域已經達到的标準化水準，好的架構模式和明确的接口是實作這個一目标的關鍵。好的架構為開發人員提供了可以在其上開展工作的骨架，而架構模式是已經驗證時正确的，安全可靠的和接口定義明确的架構。
4.進化系統
實際要求是，開發人員應該可以改變部分設計和實作，而不必擔心這種改變會對整個系統産生非期望的效果。使用基于模型和以架構為中心的方法，開發人員完全可以在系統中實作心得功能（用例）,而不會對現有的設計和實作造成太大的影響。換句話說，系統本身應該對變化具有一定的柔性（容變能力）。
3.2.3 疊代和增量式過程
将一個長期而複雜的任務劃分成一系列較小的任務時切實可行的，每一個小任務可以成為一個袖珍項目，每個袖珍項目都是一次能夠産生一個增量的疊代過程。每一個疊代都需要經過需求、分析、設計、實作和測試等主要流程。而增量是指通過一次疊代時目标或者從模型，或者從代碼方面會有所增長。為了獲得最佳效果，疊代過程必須時受控的，也就是說，他們必須按照計劃好的步驟有選擇地執行。
開發人員基于兩個因素确定在一次疊代過程中要實作的目标。首先，疊代過程要處理一組用例，其次，疊代過程要解決突出的風險問題。
疊代前期，技術方面主要是形成系統架構為基本目标，疊代後期主要以標明的架構為向導來建立設計，用元件來實作設計，并驗證這些元件是否滿足相關用例。
為了在開發過程中取得最好效果，項目組應設法選擇疊代過程實作目标。事實上，減少不可預見問題最需要的就是開發經驗，同時開發經驗也是降低系統其他風險的最直接保障。受控疊代的好處如下：
1.将成本風險降低為獲得增量所需要的費用
2.降低産品早期階段的錯誤風險
3.加快項目的進度
4.适應計算制品中必然存在的需求變更問題
用例驅動、以架構為中心和疊代增量式過程三個概念時三位一體的，去掉三個概念中的任何一個都會使同意過程開發過程不夠完整）。
初始階段，疊代過程圍繞着如何将一個好的想法發展為最終産品的構想而進行。需要弄清如下：
1.系統向他的使用者提供什麼樣的基本功能？
2.該系統的架構應該時什麼樣子的？
3.開發該産品的計劃如何，開銷多大？
這個階段需要處理用例。這個階段，架構是實驗性的，通常隻是包括主要子系統的大緻輪廓。要确定系統最主要的風險及其優先順序，需要對下一個階段（細化階段）進行詳細規劃，并對整個項目進行粗略的估計。
細化階段，主要圍繞着形成系統架構而進行。該階段，需要詳細說明該産品的絕大部分用例，并設計出能夠被測試的系統架構。在細化的末期，需要規劃完成整個項目所需要進行的所有活動，估算完成項目所需要的資源。這裡的關鍵問題是：用例、架構和計劃是否足夠穩定可靠，風險是否得到充分控制，是否能夠按照合同的規定完成整個開發任務。
在構造階段，主要圍繞着詳細設計和實作産品而進行。在這一階段，将構造出最終産品，或者說為骨架增加肌肉和美化皮膚。在構造階段的末期，産品将包括組織内部實作相關的和使用者要求的對所釋出版本達成共識額所有用例。但是，産品時智力勞動的制品，不可能沒有缺陷的，很多缺陷将在移交階段發現和改正。這個階段的末期需要回答的問題是：移交給使用者的産品是否完全滿足了使用者的需求？
移交階段，主要圍繞完善産品的實作而進行。少數有經驗的使用者試用該産品并報告産品的缺陷和不足，開發人員則改正所報告的問題，通過适當的疊代過程，最終完成該産品。移交階段包括制作、使用者教育訓練、提供線上支援以及改正傳遞之後的缺陷等活動。
ROPES模型
分析
1.需求分析，從客戶那裡擷取需求，辨識黑盒的系統的全部需求，包括功能和非功能上的。
2.系統分析，将系統的關鍵概念和關鍵結構進行細化，并将系統功能劃分給各個硬體元件和軟體元件。不隐指任何類或對象，更不用說去識别他們，經常在大型系統上，這個階段需要确定大尺度的組織單元，為組織單元構造詳盡的行為規格說明，按軟體、電子、機械三方面對系統将功能進行劃分，最後用可能的方式最執行模型進行行為測試。目标時獲得檔次疊代的實施模型、運作規格說明和軟硬體規格說明。
3.對象分析。該階段要給出重要的對象何類，以及他們的主要屬性。系統分析定義了系統要求具備的行為，這些行為 要通過這個階段給出的對象結構予以滿足。這裡的類和對象時實作前邊階段定義的系統功能主要概念結構，而不是最終實作的實體結構。這個階段得到的模型為概念模型而不能成為實體模型的原因。對象分析包括對象結構分析和對象行為分析兩個基本過程。在實踐中，這個過程通常是交替甚至并發進行的。這個階段的主要活動包括：應用對象定義政策來發現重要對象，對對象進行抽象進而給出類，解釋對象和類時如何關聯的，構造符合用例行為需要的對象協作機制，定義互動對象最重要的行為，給出對象最重要的操作和屬性，将性能限制分解為類操作的性能限制等。
設計
設計定義了與分析模型保持移植的對所處理問題的特定解決方案。設計模型和分析模型都是系統模型在不同抽象層次上的試圖，顯然它兩保持一緻是非常重要的。分析模型到設計模型的進化可以通過細化和轉化兩種方式進行。轉換時自動/半自動過程。細化時人工方式主要包括如下：
1.架構設計。主要關注影響大部分或全部應用政策的設計決策。系統分析階段的架構主要時針對包括電子、機械和軟體三方面的概念架構，而這個階段的架構設計主要指軟體架構。主要活動包括任務的是識别和特征刻畫，定義軟體元件及其分布情況，設計模式的應用，全局性錯誤（保險性、容錯等）處理等。
2.機制設計。該階段給前面産生的架構（協作）添加心得更精細化的内容，并根據某些系統優化标準對其進行優化。作用域空間是系統架構中的單個協作，通過添加類或者應用模式對協作中的類元具體化。系統大需要多次疊代，系統小一次定義每個協作或系統架構中所有的類是可能的。這個子階段的活動包括添加類或應用模式來細化協作，确定類之間的關系實作，确當類的絕大多數屬性和操作等。所獲得的設計模型應該時面向對象軟體實作的最小劃分的全集，也就是說系統的所有可封裝的類和對象在這裡全部表示完畢。
3.詳細設計。時設計的最低層次。這個子階段，添加了優化最終原型所需要的更詳細資訊，包括對關聯、聚合群組合的實作方式的定義，操作的前置不變量和後置不變量、類的異常處理、屬性的确切類型和有效範圍、方法或則和狀态中的複雜算法設計等。這個階段所得到的設計模型，應該能使看得懂模型的代碼設計人員無異議低進入代碼設計過程。
轉換
轉換過程将系統UML模型轉換為所使用的開發語言程式的源代碼，并聽過編譯器生成可執行目标代碼。這個階段的單元測試屬于百合測試，用于保證所測試單元的内部正确性并符合設計要求。
測試
測試過程要在應用程式時應用一組測試用例并産生可觀察的結果。這個測試階段過程屬于黑盒測試。用例主要基于需求分析和對象分析階段所确定的場景。每次測試對一個疊代原型進行，包括內建測試和驗證測試兩個子過程。
評審
不可或缺，最終确認此次疊代産生的原因的正确性與不足，決定是否增加疊代次數。
3.3 嵌入式系統軟體架構
3.3.1 什麼是系統軟體架構
實踐中發現從三個相關但不相同的視角來模組化系統就可以描述系統的無論從結構還是從行為方面的本質特征。三個視角為内部結構視角、類元互動視角和類元生命曆史狀态視角，反應這三個是視角的UML模型時類模型、互動模型和狀态模型。這裡把這個三個模型的集合成為系統的軟體架構。
類模型描述系統内部類元的特征、類元之間的互相關系以及類元所屬的每個類的屬性和操作，該模型捕獲系統的靜态特征。分析階段産生的概念模型，就是最高層次的類模型。
互動模型描述類元要如何互動才能産生所需要的結果，它從系統獨立類元間的互動視角描述了系統類元件的協作行為。跨越了從系統整體來看的外部共鞥到内部結構的界限，也跨越了系統由結構到行為的界限。可以從不同抽象層次上模組化,與狀态模型互補。
狀态模型,可以從不同層面（系統、子系統、對象）以整個類元行為的全為描述空間，從可控制視角描述全景行為。描述所表現類元通過相應外部激勵而産生的操作序列，而不是描述操作做了些什麼，對什麼進行操作或操作是如何實作的。典型的軟體過程其實合并了這三個方面：資料結構來表現類元的屬性，按事件設定操作順序，定在類元之間傳遞資料和控制。
3.3.2 組成架構的三種模型
1.類模型
描述系統中類元的結構，及他們的辨別，與其他類元的關系、屬性和操作。提供了狀态模型和互動模型的上下文。對象是面向對象劃分世界的單元，而類是對象的靜态描述。目标時從真實世界中捕獲那些對應用而言的重要的概念。
2.狀态模型
描述了與操作的時間和順序相關的某個類元全景行為，及标記變化的時間，界定事件上下文的狀态以及事件和狀态的組織。捕獲控制，它反映操作出現的順序，不考慮操作做了什麼，他們在操作什麼，或者他們時如何實作的。狀态圖中的動作和事件轉化成了類模型中類元的操作。
3.互動模型
描述了類元之間的互動，某一級别域（系統、子系統、元件）内部獨立類元之間如何通過協作來完成該與從外部看來的功能行為。由UML通信圖或順序圖來表達。
3.3.3 架構模型間的關系
每一種模型都描述了系統的一個方面，也包含了對其他模型的應用。類模型描述狀态模型和互動模型操作的資料結構。類模型中的操作對應于時間和動作。狀态模型描述了類元的控制結構，它顯示了依賴于類元取值的決策，并引發動作來改變類元取值和狀态。互動模型專注于類元之間的資訊交換，并提供了系統協作的整體視圖。
對于架構的三個模型無法捕獲系統的那部分内容，通過附加其他圖或描述語言仍然可以接受的。
3.4 過程中的階段制品
管理方面，應該注重裡程碑時間的記錄和技術文檔的歸檔。裡程碑事件包括可行性研究、使用者需求、項目開發計劃、需求模型、分析模型、設計模型、實作模型和測試模型等，可能還需要加上使用者手冊和維護手冊等。這裡僅讨論技術過程所需要文檔，不涉及項目管理文檔
1.需求分析文檔
從書面的使用者需求開始合理的技術介入點。需求分析的結果制品是分析模型，包括用例圖和場景圖。
需求分析之後，系統的後期活動都應圍繞這架構進行。分析架構從技術上來說，是系統自上而下向内部的第一層觀察，如果系統足夠大且足夠複雜，這一層可能隻看到構成系統的子系統和構件，如果系統足夠小且足夠簡單，這一層可能看到的就是構成系統的類（甚至對象)和構件。重點不是系統的具體實作而是功能實作，往往是粗粒度的，知注重咋樣的協作達到系統的功能要求，而對于非功能要求是不需要細緻考慮的。
2 .設計階段
産生能偶被編碼人員具體實施的設計架構，對分析架構的進一步淨化。包括選擇和細化兩個主要内容，選擇是一種優化過程，對于分析架構的實作可能由多種方案可以選擇，設計要從中按照某種優化原則選擇出最佳，可以參考已完成的各種設計模式。如果模式不能滿足系統的設計要求，需要自己實作系統的所有細節。從架構的設計力度方面可以再分為架構設計、機制設計和詳細設計三個子過程。架構設計需要對分析架構進行設計視角的再次确認，根據實作需要進行适當調整；機制設計的最小考慮單元應該是最小實體類和對象，而設計的重點是這些最小實體間的協作，涉及到關系、結構、職責和角色等，詳細設計的目标時系統編碼人員可以從這個模型開會時直接進行編碼的工作，它涉及到對象所有屬性和操作的絕體落實如關心、服務、接口、狀态和算法的實作等。
3. 轉換階段
把本次疊代原型生成目标代碼。目标代碼可與i在目标機上運作，也可以在開發機上模型與運作，這個階段的測試成為單元測試。單元測試僅保證代碼所實作的功能的正确性。
4.測試階段
根據疊代開始的原型所涉及的需求用例來涉及測試用例，并根據測試用例填寫測試文檔。保證原型能安裝在架構内運作的過程就是內建測試。
5.評審階段
是一次疊代的借宿，也是疊代的開始。項目管理和技術評價的一個交彙點，最後要形成交給管理部門存檔的表格或者是一組檔案。