任何理論都需要實踐。

而實踐要經得起檢驗的方法是在實際工作中對那些使用該實踐的項目成員有充分的指導性和充足的自洽，若此，則該實踐方才有用。當然，達索析統公司的MagicGrid方法也不例外。

關于達索析統公司收購No Magic后及其所屬CATIA品牌下的產品矩陣關系不在我們本次討論范圍，同樣，達索析統原生的MBSE最佳實踐 Modeling Methodology for Systems(簡稱，MMS)我們會另選時間詳細分享。

 

在與國防，汽車，航空航天和高科技等各行各業的企業及組織合作時，大家需要一種明確的方法來使用SysML開發系統模型，SysML是國際系統工程理事會（INCOSE）定義的MBSE事實上的建模語言。當然，目前市場上有很多MBSE方法可供使用，而現有的方法對于解決現實世界的問題來說過于抽象。達索析統的MagicGrid方法恰好是通過總結和提煉眾多企業在MBSE項目的最佳實踐經驗而來，所以，MagicGrid方法反過來又可以通過修改或擴展以靈活有效地支持特定客戶需求。

何來如此底氣呢？

因為默識在實際工作中，體會最深的就是MagicGrid方法的以下三方面在實踐中得到了充分的驗證：

 

• 它明確定義了建模框架(Framework)及詳細過程，該過程又是基于行業中系統工程過程的最佳實踐。
  

• 它與SysML完全兼容。絕大多數情況下不需要對SysML進行擴展。

• 它與工具無關，只要該工具支持SysML即可。
  

 

MagicGrid方法基于框架

---

是的，MagicGrid方法基于框架。首先，框架無論從支持復雜體系的系統系建模到具體的工程建模，乃至嵌入式軟件建模，都是旨在指導工程師完成建模過程并回答他們的如下問題：

• 如何組織模型？

• 什么是建模工作流程？

• 什么模型工件應該在該工作流程的每個步驟中生成？

• 這些工件如何鏈接在一起等等問題？
  

所不同的是，這樣的框架按照系統的復雜程度、受眾和外延邊界，也同樣存在不同層級和對應的相應實踐。例如，全球信息柵格(也有稱為宮格、矩陣的)體系結構(簡稱，GIG)，這是在系統系的級別和角度構建的框架，提綱挈領。（注：圖片拍自《體系結構設計方法的發展及應用》，梁振興、沈艷麗編著）；

也有軟件工程領域的RUP框架，知微見著。

還有現在的敏捷開發(圖片拍自《用戶故事地圖》，作者是Jeff Patton,李濤等翻譯)。

而MagicGrid恰好是涵蓋了以上不同維度和復雜度的方法實踐，即可以面向系統工程，也可以裁剪后適用于敏捷開發，它的組織和表現方式如下圖所示，對我們大家來說，應該不陌生。

如您所見，該方法包括MBSE中問題領域、解決方案和實現域的定義。它們與ISO / IEC / IEEE 15288定義的流程一致：問題域與利益相關者需求開發流程，解決方案域與架構定義流程，以及實現域與設計定義流程。

每個域都表示為MagicGrid框架的單獨一行。

• 其中表示問題域的部分被分為兩部分，以表明應該通過從黑盒中查看感興趣的系統（SoI,System of intrest）然后從白盒的角度來定義問題域。

• 表示解決方案域的部分被分成許多行，以表明可以在多個詳細級別中指定系統的解決方案體系結構。

• 表示實現域的行沒有拆分，也不像上面的行那樣完全突出顯示，以表明除了此域中的物理需求規范之外，其他所有內容都不是MBSE的一部分，因此這些柵格元素表示為在MagicGrid方法的范圍之外。
  

 每個域定義包括要在模型中考慮和捕獲的系統的四個不同方面。這些方面與SysML的四大支柱(PILLAR)相匹配，即需求，行為，結構和參數（也稱為指標）。它們表示為矩陣的列。

                       

某行和列交叉處的單元格表示系統模型的視圖，該視圖可以包含一個或多個可以展示的工件。 展示工件可以是圖表，矩陣，地圖或表格。

 

注意，雖然權衡分析(Trade-Off)沒有在MagicGrid方法框架中顯性表達，但是在架構設計或詳細建模中我們經常要考慮針對某個問題去提供多個解決方案時，就一定會用到它，而且這是經常性的。 在這種情況下，執行權衡分析以選擇用于實現的最佳解決方案。

問題域

---

問題域定義的目的是分析利益相關者的需求(Needs)并使用SysML模型元素對其進行優化和分析澄清，以便清楚、一致地描述SoI必須解決的問題。如下表所示，問題域分析分兩個階段進行。

在第一階段，SoI被認為是一個黑盒子，主要關注的是它如何與系統的周邊環境相互作用而不了解其內部結構和行為。換句話說，執行的是針對的SoI的操作分析。

在第二階段，打開黑盒子，從白盒的角度分析SoI，這有助于詳細了解系統的運行方式。換句話說，執行SoI的功能分析。

同樣重要的是要注意問題定義不包括SoI的物理體系結構。

問題域定義的兩個階段都包括分析SoI的需求，行為，結構和參數。唯一的區別在于透視。即在相關頁面中逐步描述問題域中的建模視角不同。

解決方案域

---

一旦完成問題域分析并將利益相關者的需求轉移到模型中，就該開始考慮解決方案了。 解決方案體系結構定義了系統邏輯設計的精確模型，甚至包括它的幾種變體(與產品線有關)。 換句話說，這個抽象層為第一個抽象層中定義的問題提供了一個或多個解決方案（包括黑盒和白盒透視圖）。 

有幾種解決方案，就可以進行與之對應的多種權衡分析，以選擇實施該系統的最佳方案。

在定義了整個系統的解決方案體系結構并選擇了最佳系統配置之后（通過權衡分析），系統已準備好實施。 此時的系統已經從抽象演進為真實的，我們可以借助一維仿真對架構的邏輯正確性進行仿真了。

實現域

---

正如在下表中所看到的，MagicGrid框架僅部分涵蓋了實現域。 該方法定義了正在實施的系統的物理需求規范，但其詳細設計不是MBSE的一部分，也不是MagicGrid方法的一部分。 該系統的詳細設計是基于模型的設計（MBD）的一部分，可以使用電氣和機械CAD軟件，如果針對ESW(嵌入式軟件)，則進入詳細設計領域并/或由自動代碼生成工具等工具進行開發，這也正是體現機電軟高度協同工作的一個重要環節。

總結

---

MagicGrid方法的每個域都表示為MagicGrid框架的單獨一行。

• 其中表示問題域的部分被分為兩部分，以表明應該通過從黑盒中查看感興趣的系統（SoI,System of intrest）然后從白盒的角度來定義問題域。

• 表示解決方案域的部分被分成許多行，以表明可以在多個詳細級別中指定系統的解決方案體系結構。

• 表示實現域的行沒有拆分，也不像上面的行那樣完全突出顯示，以表明除了此域中的物理需求規范之外，其他所有內容都不是MBSE的一部分，因此這些柵格元素表示為在MagicGrid方法的范圍之外。

文章來源：默識沙龍