互聯(lián)設備和系統(tǒng)已成為我們?nèi)粘I钪胁豢苫蛉钡囊徊糠?,我們認為這是理所當然的。使用智能手機找到到達目的地的最快方式,坐在沙發(fā)上在平板電腦上閱讀新聞,或者使用智能手機應用程序控制智能供暖——這些系統(tǒng)讓生活變得更加方便。然而,這種便利性的提高需要更嚴格的安全和安全要求,而這些要求必須由開發(fā)此類系統(tǒng)的人員來管理。對于自動駕駛來說尤其如此,高效的安全理念是重中之重。
軟件架構師應具備的專業(yè)知識和技能
產(chǎn)品復雜性的增加和硬件功能的增強導致嵌入式系統(tǒng)中軟件的范圍不斷擴大。軟件實現(xiàn)了大多數(shù)系統(tǒng)中的大部分功能。嵌入式軟件開發(fā)部門正在不斷增長。這在汽車行業(yè)和當前的勞動力市場中尤為明顯。例如,梅賽德斯奔馳計劃從 2030 年起通過基于軟件的系統(tǒng)產(chǎn)生大部分收入。軟件開發(fā)不再是一個人的表演,而是由分布在全球多個地點的大型團隊完成。在過去的幾年里,嵌入式軟件在嵌入式行業(yè)的大多數(shù)公司中都取得了顯著的重要性,甚至在機電一體化領域也是如此。但這僅僅是開始。
更加關注敏捷軟件開發(fā)方法
敏捷軟件項目使用基于測試驅(qū)動的軟件開發(fā)技術的漸進式軟件架構開發(fā)。這是兩種主要方法:
· 功能架構:軟件系統(tǒng)由功能或特性及其依賴關系來表示。
· 組件架構:開發(fā)一個粗略的草案以及幾個包含經(jīng)過微調(diào)的軟件結構的詳細草案。
軟件架構是項目成功的關鍵
想要滿足其負責任的工作要求的軟件架構師需要涵蓋以下關鍵方面的廣泛專業(yè)知識:
1. 對軟件架構的基本理解:在抽象層面上,軟件架構是需求和軟件實現(xiàn)之間的橋梁。在軟件中,架構描述了由軟件組件、軟件層、軟件子系統(tǒng)、接口及其依賴性等組成的粗略結構(在特殊情況下還包括模塊和類)。對于這些架構元素,還可以描述交互的和單獨的行為。運行時架構是軟件架構的另一個關鍵要素。
2. 軟件架構師的角色:每個擁有所需專業(yè)知識的人都可以在公司中擔任軟件架構師的角色。然而,對于真正專業(yè)的方法,個人角色應該是首選。根據(jù)項目的規(guī)模,可以有一名或多名軟件架構師參與項目。
3. 首席架構師管理軟件架構師團隊:軟件架構師協(xié)調(diào)項目中多個角色的一切,因此需要技術和非技術知識——經(jīng)驗越多越好。軟件架構師的角色可能不應該分配給缺乏經(jīng)驗的大學畢業(yè)生——它需要外向、創(chuàng)新、果斷和經(jīng)驗豐富的個性。
設計過程——創(chuàng)建軟件架構
設計流程描述了軟件(架構)的開發(fā)過程。每個公司都必須確定并實施最適合他們的流程。軟件架構師在定義此過程中發(fā)揮著關鍵作用?;赩模型類型表示,該設計過程可以應用于完整嵌入式系統(tǒng)的開發(fā),即不僅僅應用于軟件的開發(fā)。
需求(什么)和相關架構(如何)
在分析過程中,分析師(在大多數(shù)情況下也是架構師)在各個層面上確定并記錄各自的需求(“什么”)。這些要求是創(chuàng)建架構(“如何”)的基礎。基于子系統(tǒng)架構,軟件架構師與同一級別的其他開發(fā)領域(例如硬件開發(fā))協(xié)調(diào)開發(fā)子系統(tǒng)的軟件架構。
根據(jù)需求,測試團隊開發(fā)測試用例,以在開發(fā)過程的后期證明正確的實現(xiàn)。這也是在不同層面上進行的。 “測試設計”和“安全設計”是軟件架構背景下的基本主題。
設計依據(jù)及影響因素
軟件需求(功能性和非功能性)源自圖 3 所示的 X 分析(此處:軟件分析)?;诎踩院涂煽啃缘能浖|(zhì)量屬性分別如下所示。
通過分析影響因素,軟件架構師確定:
· 軟件架構需求的相關性
· 未來需求的變化
· 軟件架構后果的推導
非功能性軟件需求包括軟件的軟件質(zhì)量屬性,例如:
· 可移植性
· 可維護性
· 可靠性
· 安全/安保
· 資源需求
· 表現(xiàn)
· 實時兼容性
一些質(zhì)量屬性是一致的,而另一些質(zhì)量屬性也可能產(chǎn)生相反的效果??紤]到這一點,我們可以問以下問題:哪些需求對架構(功能性還是非功能性)影響更大?正確答案是非功能性需求。因此,除了子系統(tǒng)架構之外,軟件需求及其產(chǎn)生的影響因素是軟件架構最重要的設計依據(jù)。
溝通和文檔
通過全面的軟件架構文檔,軟件架構師為所有利益相關者提供了項目的基礎,從而為參與項目的每個人提供了完全的可追溯性,確保了公司的連續(xù)性。文件也是與利益相關者持續(xù)協(xié)調(diào)溝通的基礎。
這里最重要的利益相關者是軟件開發(fā)人員,他們詳細完善軟件架構并最終用目標編程語言實現(xiàn)它。除了軟件開發(fā)人員之外,其他角色(例如測試團隊)對軟件架構也有合法的興趣。除非您知道需要什么,否則您無法驗證實施是否正確。
統(tǒng)一建模語言 (UML) 是一種符號,用于記錄軟件架構的各種視圖和方面,并在設計中對其進行細化 - 直至自動代碼生成。
軟件設計原則提高軟件質(zhì)量
我們的整個生活都是由規(guī)則決定的——即使有些人認為他們不必遵守這些規(guī)則。我們所有人都面臨著新冠病毒大流行以及相關的規(guī)則和規(guī)定。您小時候肯定玩過樂高積木,或者您今天也玩過自己的孩子,關于如何正確安裝積木是有規(guī)則的。
軟件架構師憑借其不斷增長的知識,繪制出軟件開發(fā)的風格指南,描述了軟件架構開發(fā)的規(guī)則。這些規(guī)則不能應用于任何架構,因為它們?nèi)Q于特定的要求。在任何情況下,將規(guī)則應用于軟件架構都可以提高軟件質(zhì)量。
高內(nèi)聚是一個架構設計原則。它的目的是通過在一個架構元素中處理邏輯相關的任務來減少冗余,而不是在多個架構元素之間分配類似的任務。已發(fā)布可應用于嵌入式軟件架構的具體設計原則。軟件架構師可以通過軟件架構模式在實際系統(tǒng)中實現(xiàn)設計原則。
架構開發(fā)和架構模式必須滿足安全要求
基于他們的技術知識,軟件架構師使用他們的模式目錄開發(fā)軟件架構。一般來說,模式是針對重復出現(xiàn)的問題(挑戰(zhàn))的已知的、經(jīng)過驗證的、評級的和可調(diào)整的解決方案。例如,在安全相關系統(tǒng)中必須考慮和照顧功能安全性和可靠性等方面。在為我們提供全自動支持的系統(tǒng)中(例如自動駕駛),安全性和可靠性是產(chǎn)品成功的關鍵。
使用模式可能是軟件架構開發(fā)中的一個挑戰(zhàn)。例如,只有方形磚可用,但一個要求可能是圓形輪廓。根據(jù)樂高原理,可以通過將積木分級組裝成一排或多排來解決。由于我們不是第一代開發(fā)軟件的人,因此幾乎所有軟件開發(fā)領域甚至軟件架構的開發(fā)都已經(jīng)創(chuàng)建了模式。
質(zhì)量保證和質(zhì)量評估
軟件架構師負責軟件質(zhì)量和質(zhì)量保證。在開發(fā)架構之前必須定義質(zhì)量屬性。軟件架構師知道這些屬性對其軟件架構的影響,并且軟件測試團隊知道如何證明它們。順便說一句,屬性不能在開發(fā)過程結束時“測試”到產(chǎn)品中。
在質(zhì)量方面,存在以下區(qū)別:
· 內(nèi)部質(zhì)量(例如軟件架構)
· 外部質(zhì)量(客戶所看到的)
工藝質(zhì)量對產(chǎn)品質(zhì)量有重大影響。再次回到樂高的類比——所有的磚塊都必須組裝起來以支撐結構,否則,一旦進行額外的擴展,它就會倒塌。對于軟件架構來說也是如此;它們必須滿足所有質(zhì)量要求并提供之前定義的所有功能。
過去,軟件架構預計能夠保持 20 年或更長時間的功能。如今,由于不斷出現(xiàn)的要求、法規(guī)和法律,它們正在不斷擴展和改進。因此,開發(fā)過程應適應這一方面,因為它是產(chǎn)品進一步開發(fā)的關鍵。
確保質(zhì)量的最簡單方法
與其他架構師和利益相關者一起進行評審是確保軟件架構質(zhì)量的最簡單方法。它們用于評估架構是否符合所需的質(zhì)量屬性。通過 UML 模型生成的軟件架構文檔是審查的合適基礎。
在基于場景的審查中,參與者會通過架構檢查預定義的案例。例如,如果一個架構在硬件方面要求可移植,這個過程就包括更換硬件,以證明該軟件架構能夠滿足這個要求。
工具使開發(fā)軟件架構變得更加容易
軟件架構師負責或至少共同負責軟件開發(fā)的工具環(huán)境。他或她了解工具市場,能夠識別需求、開發(fā)工具需求、評估并最終選擇工具。在一家沒有工具組的公司里,他還負責工具集成。這些工具使參與軟件開發(fā)的每個人(尤其是軟件架構師)的工作變得更加輕松。
工具使軟件架構師的工作變得更加輕松:
· 需求管理
· 版本和配置管理
· 造型
· 生成文檔和程序代碼
· 構建系統(tǒng)
· 靜態(tài)分析
· 動態(tài)分析
軟件架構的實現(xiàn)
軟件架構師將整個架構或其部分傳遞給一名或多名軟件開發(fā)人員進行進一步細化(設計和實現(xiàn))。軟件架構師與軟件開發(fā)人員合作創(chuàng)建的編碼風格指南顯示了如何用目標編程語言實現(xiàn)軟件架構。嵌入式系統(tǒng)編程的典型目標語言是 C 和 C++。
在C++中,軟件架構可以通過命名空間在程序代碼中有效地表示。軟件架構師和軟件開發(fā)人員必須確保定義的軟件架構在其整個生命周期中得到保留,并且不會被編程“致死”(也稱為軟件侵蝕)。
如果軟件開發(fā)人員確定需要更改架構,則所有相關決策和架構更改均由負責的軟件架構師協(xié)調(diào)。產(chǎn)品對安全性、保密性和模塊化的要求越高,軟件架構師在整個開發(fā)過程中的作用就越關鍵和重要。