關於需求分解及功能定義

近挨了不少罵，感覺是要開竅了，架構，不在油鍋里滾幾圈還真不是誰都能搞定的。

最近電控系統開發有些滯後，原因，混亂，其實無外乎一點：對於一個自動控制系統來說，更多的人為介入究竟是讓控制系統的開發變得簡單還是變得複雜，這個問題其實是沒有定數的，比如剛開始思考SBW系統的時候，我會覺得這個問題實在太棘手，雖然想法很容易描述（stakeholder requirment），但是系統級別的需求定義是在是很難抽取，尤其是考慮到對於車輛控制來說，多個控制器構成的系統，單一的去定義某一個控制器的架構往往難以奏效，所以。。。開展架構定義一定從整個電驅系統入手，要納入BCM/VCM/ECM/CAR及Driver進入每一個控制設計的體系中，要考慮系統之間的交互（interface），如果將系統割裂開進行系統需求及功能的定義容易導致功能定義和設計難以覆蓋，但是，並不意味著只要從全局系統去考慮就能夠設計出一個完美的軟體架構，全局考慮往往帶來的負面因素的發散，所以此時設計邊界（boundary），所謂邊界，即要將整個控制系統中功能實現在不同的控制器（modal）中，系統角度的考量加上合理的邊界劃分，才能夠明確具體的介面，同時也形成有效的輸出，寫到這兒，不得不感慨老王頭大魔王的屬性，Tsinghua就是NB，寥寥數語直接把我數十天的冥思苦想解釋透了，但這也只是原則性的定義，讀進去這兩句話理解這兩句話與真正的將這兩句話應用在架構的設計上相差絕非十萬八千里，所以說，良好的設計源於良好的實踐。

在本次架構的設計中，剛開始的考量建立在MBSE上，希望能夠通過全模型的設計完成設計，最終用事實證明，工具只能是工具，譬如raphsody中每個模型看似簡單，但是難在上手，印象最深刻的莫過於如何定義use case，如何剝離抽取use case，一萬個人眼中有一萬個哈姆雷特，將一個整體拆解開，可以有一萬種方式，所以究竟選擇哪種方式沒有嚴格的答案，但是，從本次的定義中，可以抽取的一個詞：解耦，何為解耦，解耦的前提在於一個真實系統一定是千絲萬縷相互交融，譬如用例一詞，可以解釋為使用模式，它應該具備幾個特點：首要是完整，一個用例需要是一個完整的過程，這個過程有始有終，以Sbw為例，我們的用例一定是一個完整的駕駛過程，自然這是一個相對的概念，所以用例第二屬性，對象附著，用例分解的依據即為系統的級別：人-〉車-〉控制器-〉模塊，用例定義本身即為系統功能定義梳理的過程，每一個用例的詳細的描述所形成的活動圖綜合形成所有的狀態及其狀態切換條件，繼而形成底層模塊的劃分。

最後，用例的合併，每個用例都會形成自身的模塊/狀態及遷移條件，雖然我們在用例定義中規定里解構的需求，但是我們設計的目標僅為一個系統，他的組成元素是模塊/S-Function/Fsm等，通過這些元素要實現全部的用例的合併，過於複雜的系統及功能，通過矩陣式結構分解，將需求分解到對應的模塊及狀態中，最終整合，能夠實現準確的定義分解，這才是一個好的有效地準確的全面地軟體架構！

路很長，且行竊思考，在老王頭的罵聲中成長！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！