
軟體架構與設計介紹
系統的架構描述了其主要元件、它們之間的關係(結構)以及它們如何相互互動。軟體架構與設計包括多個構成因素,例如業務戰略、質量屬性、人員動態、設計和IT環境。

我們可以將軟體架構與設計分為兩個不同的階段:軟體架構和軟體設計。在架構階段,非功能性決策被制定並與功能性需求分離。在設計階段,功能性需求得以實現。
軟體架構
架構作為系統的藍圖。它提供了一種抽象方法來管理系統複雜性,並在元件之間建立通訊和協調機制。
它定義了一個結構化的解決方案,以滿足所有技術和運營需求,同時最佳化諸如效能和安全之類的常見質量屬性。
此外,它涉及一組關於與軟體開發相關的組織的重要決策,並且這些決策中的每一個都可能對質量、可維護性、效能和最終產品的整體成功產生相當大的影響。這些決策包括:
選擇系統由其組成的結構元素及其介面。
在這些元素之間的協作中指定的行為。
將這些結構和行為元素組成大型子系統。
架構決策與業務目標保持一致。
架構風格指導組織。
軟體設計
軟體設計提供了一個設計方案,描述了系統的元素、它們如何組合以及如何協同工作以滿足系統需求。制定設計方案的目標如下:
協商系統需求,並與客戶、市場營銷和管理人員設定期望。
在開發過程中充當藍圖。
指導實施任務,包括詳細設計、編碼、整合和測試。
它位於詳細設計、編碼、整合和測試之前,領域分析、需求分析和風險分析之後。

架構的目標
架構的主要目標是確定影響應用程式結構的需求。精心設計的架構降低了構建技術解決方案相關的業務風險,並在業務需求和技術需求之間架起橋樑。
其他一些目標如下:
展現系統的結構,但隱藏其實現細節。
實現所有用例和場景。
嘗試滿足各個利益相關者的需求。
處理功能性和質量需求。
降低所有權目標並提高組織的市場地位。
提高系統提供的質量和功能。
增強對組織或系統的外部信心。
侷限性
軟體架構仍然是軟體工程中一個新興的學科。它具有以下侷限性:
缺乏表示架構的工具和標準化方法。
缺乏分析方法來預測架構是否會導致滿足需求的實現。
缺乏對軟體開發中架構設計重要性的認識。
缺乏對軟體架構師角色的理解以及利益相關者之間的溝通不暢。
缺乏對設計過程、設計經驗和設計評估的理解。
軟體架構師的角色
軟體架構師提供技術團隊可以為整個應用程式建立和設計的解決方案。軟體架構師應該在以下領域擁有專業知識:
設計專業知識
軟體設計的專家,包括各種方法和途徑,例如面向物件設計、事件驅動設計等。
領導開發團隊並協調開發工作以確保設計的完整性。
能夠審查設計提案並在它們之間進行權衡。
領域專業知識
正在開發的系統的專家,並規劃軟體的演進。
協助需求調查過程,確保完整性和一致性。
協調正在開發的系統的領域模型的定義。
技術專業知識
有助於系統實現的可用技術的專家。
協調程式語言、框架、平臺、資料庫等的選型。
方法論專業知識
可能在SDLC(軟體開發生命週期)期間採用的軟體開發方法論的專家。
選擇合適的開發方法來幫助整個團隊。
軟體架構師的隱藏角色
促進團隊成員之間的技術工作,並加強團隊中的信任關係。
資訊專家,分享知識並擁有豐富的經驗。
保護團隊成員免受可能分散他們的注意力並降低專案價值的外部力量的影響。
架構師的可交付成果
一套清晰、完整、一致且可實現的功能目標
系統的功能描述,至少包含兩層分解
系統的概念
系統的設計,至少包含兩層分解
關於時間、操作員屬性以及實施和操作計劃的概念
確保遵循功能分解並控制介面形式的文件或流程
質量屬性
質量是對卓越程度或無缺陷或不足狀態的衡量。質量屬性是與系統功能分離的系統屬性。
實現質量屬性可以更容易地區分好的系統和壞的系統。屬性是影響執行時行為、系統設計和使用者體驗的整體因素。
它們可以分類為:
靜態質量屬性
反映系統的結構和組織,直接與架構、設計和原始碼相關。它們對終端使用者是不可見的,但會影響開發和維護成本,例如:模組化、可測試性、可維護性等。
動態質量屬性
反映系統在其執行期間的行為。它們直接與系統的架構、設計、原始碼、配置、部署引數、環境和平臺相關。
它們對終端使用者可見,並在執行時存在,例如吞吐量、健壯性、可擴充套件性等。
質量場景
質量場景指定如何防止故障演變成失效。根據其屬性規範,它們可以分為六個部分:
來源 - 生成刺激的內部或外部實體,例如人員、硬體、軟體或物理基礎設施。
刺激 - 當到達系統時需要考慮的條件。
環境 - 刺激在特定條件下發生。
工件 - 整個系統或其某些部分,例如處理器、通訊通道、永續性儲存、程序等。
響應 - 刺激到達後進行的活動,例如檢測故障、從故障中恢復、停用事件源等。
響應度量 - 應該測量發生的響應,以便可以測試需求。
常見的質量屬性
下表列出了軟體架構必須具有的常見質量屬性:
類別 | 質量屬性 | 描述 |
---|---|---|
設計質量 | 概念完整性 | 定義整體設計的連貫性和一致性。這包括元件或模組的設計方式。 |
可維護性 | 系統以一定程度的輕鬆程度進行更改的能力。 | |
可重用性 | 定義元件和子系統適用於其他應用程式的能力。 | |
執行時質量 | 互操作性 | 系統或不同系統透過與外部各方編寫和執行的其他外部系統進行通訊和交換資訊來成功執行的能力。 |
可管理性 | 定義系統管理員管理應用程式的難易程度。 | |
可靠性 | 系統隨著時間的推移保持執行的能力。 | |
可擴充套件性 | 系統處理負載增加而不會影響系統性能或易於擴充套件的能力。 | |
安全性 | 系統防止超出設計用途的惡意或意外行為的能力。 | |
效能 | 系統在給定時間間隔內執行任何操作的響應能力的指示。 | |
可用性 | 定義系統執行和工作的時間比例。可以將其衡量為預定義期間系統總停機時間的百分比。 | |
系統質量 | 可支援性 | 系統提供有助於識別和解決問題(當它無法正常工作時)的資訊的能力。 |
可測試性 | 衡量為系統及其元件建立測試標準的難易程度。 | |
使用者質量 | 可用性 | 定義應用程式透過直觀地滿足使用者和消費者的需求的程度。 |
架構質量 | 正確性 | 負責滿足系統的所有需求。 |
非執行時質量 | 可移植性 | 系統在不同計算環境下執行的能力。 |
完整性 | 使系統單獨開發的元件能夠正確協同工作的能力。 | |
可修改性 | 每個軟體系統適應其軟體更改的難易程度。 | |
業務質量屬性 | 成本和進度 | 關於上市時間、預期專案生命週期和遺留系統利用率的系統成本。 |
市場潛力 | 關於市場競爭的系統使用情況。 |