有關(guān)基于模型的設(shè)計(jì)mbd一些概念和理解-展示頁(yè)
2025-07-03 18:02本頁(yè)面
【正文】 就是為了發(fā)現(xiàn)這個(gè)階段的錯(cuò)誤，以防錯(cuò)誤被帶到后續(xù)的開發(fā)過程中。所以，我們期望能夠盡早的發(fā)現(xiàn)開發(fā)過程中引入的bug。沒錯(cuò)，代碼生成是一個(gè)很大的好處，但，代碼生成不是唯一的，也不是最大的好處。我個(gè)人的體會(huì)，這個(gè)階段，不要著急建模，一定要先弄清需求，另外，建模的時(shí)候，模型架構(gòu)非常重要。如果不考慮Simulink/Stateflow的應(yīng)用上的問題，也就是說，如果我們都是熟練的Simulink/Stateflow用戶，那么建模過程的主要工作是需求分析，通俗點(diǎn)講，需求弄清楚了，建模也就是非常簡(jiǎn)單的事情了。如果這部分需求在系統(tǒng)需求文檔里已經(jīng)有非常清楚的定義，那么我們可以以系統(tǒng)需求文檔作為依據(jù)建立模型。當(dāng)然，根據(jù)系統(tǒng)需求的詳細(xì)程度，我們可以考慮是否要寫專門的軟件需求。 如果想通過基于模型的設(shè)計(jì)提升軟件開發(fā)團(tuán)隊(duì)的開發(fā)效率，提高軟件品質(zhì)，我覺得至少有如下幾點(diǎn)可以考慮：1. 算法建模2. 算法模型的驗(yàn)證3. 文檔自動(dòng)化4. 代碼生成5. 代碼和模型的等效性驗(yàn)證傳統(tǒng)的開發(fā)過程中，我們有一個(gè)環(huán)節(jié)，需求捕獲，也即，從系統(tǒng)需求分解出軟件需求。 我的理解是，通過對(duì)算法建模進(jìn)行軟件設(shè)計(jì)的過程，都可以叫基于模型的設(shè)計(jì)。有關(guān)基于模型的設(shè)計(jì)（MBD）一些概念和理解先胡亂問幾個(gè)大問題：1. 什么叫基于模型的設(shè)計(jì)？2. 為什么要基于模型的設(shè)計(jì)？3. 基于模型的設(shè)計(jì)過程中，需要做什么事情？再問幾個(gè)小問題：1. 模型驗(yàn)證是否必要？2. 模型驗(yàn)證有哪些工作可以做？3. 模型驗(yàn)證是否一定需要被控對(duì)象模型？4. 代碼生成效率如何？5. 底層驅(qū)動(dòng)是否要建模？6. Embedded Coder（以前的RTW Embedded Coder）支持哪些芯片？7. MIL、SIL、PIL、HIL的目的和實(shí)現(xiàn)方式？8. 如何定點(diǎn)化？9. 如何做代碼集成？什么叫基于模型的設(shè)計(jì)？這是一個(gè)很大的話題，因?yàn)楸救四芰λ?，僅討論使用Simulink模型開發(fā)嵌入式軟件的設(shè)計(jì)過程。也就是說，我只能聊基于模型的嵌入式軟件設(shè)計(jì)。當(dāng)然，如果僅限于算法建模，把Simulink/Stateflow當(dāng)做Visio使用，而不去進(jìn)行其他環(huán)節(jié)的工作，這樣的基于模型設(shè)計(jì)是不完整的，可能對(duì)你的開發(fā)效率不會(huì)有很大的提升。在基于模型的設(shè)計(jì)過程中，我們同樣可以通過分析系統(tǒng)需求，獲得軟件需求。在基于模型的軟件設(shè)計(jì)中，我們主要關(guān)心的是系統(tǒng)的功能需求，或者說可以通過軟件實(shí)現(xiàn)的功能需求。當(dāng)然，如果系統(tǒng)需求不是足夠清楚，那我們有必要編寫專門的軟件需求文檔。當(dāng)然，建模的時(shí)候，要考慮未來的驗(yàn)證、實(shí)現(xiàn)以及后期維護(hù)的問題。有了模型之后，接下來要做什么事情？代碼生成？這是很多比較初級(jí)的用戶容易犯的錯(cuò)誤，犯這個(gè)錯(cuò)誤的用戶，很大程度上是因?yàn)闆]有弄清楚為什么要做基于模型的設(shè)計(jì)？為什么要做基于模型的設(shè)計(jì)？我相信很多用戶沒有仔細(xì)考慮這個(gè)問題，很多用戶做基于模型的設(shè)計(jì)的理由是：國(guó)外的公司都這么做，同行其他公司都這么做...... 弄清為什么要基于模型的設(shè)計(jì)，也就是要弄清楚基于模型的設(shè)計(jì)到底可以給我們帶來哪些好處？很多人會(huì)非常自然的想到，代碼生成，代碼生成可以提高軟件開發(fā)效率。最大的好處是，算法的早期驗(yàn)證，之前NASA有研究表明，開發(fā)初期引入的bug，如果到了晚期才發(fā)現(xiàn)出來，那么修復(fù)這一的bug，會(huì)產(chǎn)生非常大的費(fèi)用。如何盡早的發(fā)現(xiàn)設(shè)計(jì)上的錯(cuò)誤？傳統(tǒng)的開發(fā)模式里，我們使用review的方式去發(fā)現(xiàn)錯(cuò)誤，在質(zhì)量體系ISO9001里面有定義，任何一份設(shè)計(jì)，都必須要評(píng)審。而評(píng)審的效率，卻是非常低下的。比如，我在做完一份設(shè)計(jì)之后，我會(huì)邀請(qǐng)我的同事來評(píng)審我的工作，而參加評(píng)審的這些同事，往往不能有足夠的時(shí)間了解我的這份工作，而只能在評(píng)審會(huì)上聽我介紹我做的工作，這樣的評(píng)審，可能會(huì)發(fā)現(xiàn)一些非常明顯的問題，除此之外的，很難發(fā)現(xiàn)問題。而仿真，從效率上講，要遠(yuǎn)高于評(píng)審，仿
環(huán)評(píng)公示相關(guān)推薦
鄂ICP備17016276號(hào)-1