系統的功能性是軟體構架師通過組成體系架構的多種元素之間的互動作用來支援的。然而，架構設計的乙個關鍵特性是，系統的品質是通過某些手段來實現的。軟體的品質，例如效能，安全性和可維護性等，它們在缺少統一的架構設計檢視時是無法實現的，因為這些品質並不是被限制在乙個單一的架構設計元素中，而是滲透在整個架構設計體系中的。例如，為了滿足效能要求，可能需要考慮體系架構中的每乙個元件的實現時間，同時還要考慮各元件之間通訊所花費的時間。同樣地，為了滿足安全性要求，可能需要考慮兩個元件之間自然的通訊，並且要在需要的特定的地方引入安全性提示元件。所有的這些關係都屬於體系架構，在上面的例子中，這些關係包括元件自身的和元件之間的。
乙個和架構設計相關的好處是，我們可以盡早的評估專案開發周期中的這些品質。架構設計模型的建立，通常是為了明確的確定我們已經滿足了這些品質的要求。這是非常重要的，因為不論寫在紙上的體系架構多麼的完美，實現的軟體才是評價體系架構是否達到這些品質的要求的唯一標準。
架構設計的過程使得不同的涉眾達成一致的目標，因為架構設計提供了乙個辯論系統解決方案的**。為了支援這種辯論，體系架構的過程需要確保架構設計被清楚地傳達與理解。乙個被有效傳達的體系架構使得涉眾們可以辯論決議和權衡，反覆討論，最終達成共識。相反，如果乙個體系架構沒有被有效的傳達，那麼這種辯論將不會發生。沒有了有效的傳達，體系架構所帶來的結果可能會是低品質的。
在一條相關的說明中，體系架構可能會使構架師之間或者新成員與老成員之間的辯論達成一致（以及他們之間的檢視）。我們需要再次強調，只有體系架構被有效傳達，它所帶來的這個好處才能體現出來。清楚地了解他們正在做什麼的開發小組更可能按照需求完成產品的開發。
為此，我再次強調恰當的文件化體系架構是非常重要的，這是軟體構架師的主要職責。同樣的，乙個架構設計的概念證明是乙個證明體系架構是否滿足最初的需求的極好的方法。
uml元件圖顯示了架構設計中的重要元素
在日程安排方面，它們之間的依賴性暗示了每乙個元素被考慮的順序。從乙個實施透檢視來看，例如，依賴性告訴我們error log元件必須最先實現，因為其餘的所有元件都要使用它。customer management和fulfillment元件可以同時實現，因為它們之間不存在依賴關係。最後，一旦這兩個元件也被實現完了，那麼account management元件就可以被實現了。通過這個資訊，我們可以畫出甘特圖（專案經理的乙個主要計畫編制工具），每乙個任務在實現時間時都需要一些思考，但是它們中的一部分可以**於每乙個架構設計元素的複雜性。
基於架構設計中重要元素之間依賴性的甘特圖
很明顯這是乙個很多原因的總的簡化。例如，所有這些元素都不可能作為乙個單一的元件被實現，但是這對於乙個用例來說太過複雜了。同樣，我們可以建立"存根的"或者部分的實現，使得每乙個元素的實現都能夠平行實現。我使用這個例子來簡單的證明這個原理。
在工作分配中，體系架構能夠再次幫助我們鑑別需要特定技能的區域，使得我們可以把工作分配給特定的資源（例如：人）。
構架師還能協助估算專案成本。乙個專案的成本來自多個方面。很明顯，任務的持續時間和分配給每一部分的資源將會決定勞動力的成本。體系架構同樣會幫助我們決定使用在交付的系統中的第三方元件的成本，以及支援開發成果的所有工具的成本，因為構架師參與的活動是乙個經過挑選的恰當的開發環境，它允許設計人員，實現人員和其他小組成員使用同乙個有效的方式一起工作。
構架師的另外乙個焦點是鑑別和管理專案的技術風險。技術風險的管理包括制定每乙個風險的優先次序，以及確定乙個恰當的風險緩解策略。優先權和風險緩解策略作為輸入部分提供給專案經理。
最後，體系架構確定離散元件的解決方案，它可以為專案提供所需的技術輸入。如果專案或者組織中沒有足夠可用的資源，那麼它會明確的辨別出**需要技術支援。這可以通過現存的職員，或者外包，或者通過僱傭新職員來實現。
架構設計過程的乙個主要目標就是確保體系架構能夠為設計人員和實現人員所承擔的工作提供可靠的構架。很明顯，這比簡單的傳送乙個體系架構檢視要複雜的多。為了確保最終體系架構的完整性，構架師必須明確的定義體系架構，因為它確定了體系架構的重要元素，例如系統的元件，元件之間的介面以及元件之間的通訊。
構架師同時還必須定義恰當的慣例，標準和指導方針，它們將會引導設計人員和實現人員的工作。架構設計的另外乙個目標是去除部分設計人員和實現人員不必要的創意，這是通過對他們所做的事情增加必要的限制，以及讓他們清楚地知道如果不遵循這些限制將可能會導致體系架構的破壞來實現的。出於這個原因，對活動採取恰當的回顧和評估，能夠確保體系架構的完整性。這些活動的乙個焦點是考慮設計人員和實現人員的工作，以及確定體系架構的標準和指導方針的到位程度。
如今的系統越來越複雜，這種複雜性需要我們去管理。自從乙個體系架構只把焦點集中在這些元素上以來，它就提供了乙個抽象的系統，因而提供了乙個複雜的管理方法。同樣，架構設計過程考慮元件的遞迴分解。這是處理乙個大的問題的很好的乙個方法，它可以把這個大問題分解成很多的小問題，再逐個的解決。
抽象的體系架構之間的通訊技術使得管理更加複雜。採取業界標準可以表達這種抽象性，例如uml，因此在現今的產業中文件化軟體系統是非常平常的事情。
架構設計過程可以同時支援使用和建立復用資源。復用資源對於乙個組織來說是有益的，因為它可以降低乙個系統的成本，並且可以改進系統的質量，這些好處已經被證明過了（自從它被使用以來）。
乙個體系架構的建立，能夠支援資源復用的機會。例如，體系架構的重要元件和它們之間的介面和質量，能夠支援現貨**的元件，存在的系統和封裝的應用程式等等的選擇，從而可以用來實現這些元件。體系架構自身也可以被用來當作今後開發的系統的乙個復用參考資源。甚至體系架構內部的元件也可以被認為是潛在的復用資源。
雖然架構設計過程能夠鑑別現今專案中存在的資源復用的機會，但是跨專案和企業的資源復用會導致產生很大的衝突。
任何關於復用的討論都要和謹慎聯絡在一起。由於各方面的原因，只有很少一部分復用程式能夠使用到現在。從技術的角度看，乙個復用的程式需要確保標準，過程和工具都在恰當的位置。幸運的是一些基本元素正在被滿足。乙個好的例子就是標準化組織：object management group『s reusable asset specification (ras)，1
它定義了描述復用資源，封裝復用資源和連線到ras資源庫服務的介面的標準
從非技術的角度看，當你實現乙個復用策略時，需要始終牢記組織的考慮。例如，確定誰是建立復用資源的人員？一旦復用資源被建立，誰是負責維護它的人（建立它的小組已經解散）？使用和建立復用資源的動力是什麼？建立乙個復用資源的成本是多少，這通常比建立乙個不恰當的復用資源要花費更多。
架構設計過程可以在很多方面幫助我們降低維護費用。首先最重要的是架構設計過程要確保系統的維護人員是乙個主要的涉眾，並且他們的需求被作為首要的任務滿足。乙個被恰當文件化的體系架構不應該僅僅為了減輕系統的可維護性；構架師還應該確保結合了恰當的系統維護機制，並且在建立體系架構的時候還要考慮系統的適應性和可擴充性。
構架師還應該考慮那些需要改變的區域，並把它們隔離開。這樣可以保證當單個元件或者一小部分元件發生變化時，整個系統不會受很大的影響。但是我們應該承認，有一些變化，例如關係到系統質量，如實現性和可靠性，是不能用這個方法隔離的。這就是構架師必須確保它的原因，當架構設計現在的系統時，他們需要考慮將來可能的需求，因為這個系統要從幾十人的使用者推廣到上千人的使用者群，例如，體系架構沒有使用基礎的方法改變是不正常的。
架構設計的乙個重要的好處是它可以允許我們在採取改變之前推斷它所產生的影響。乙個軟體構架確定了主要的元件和它們之間的互動作用，兩個元件之間的依賴性以及這些元件對於需求的可追溯性。
有了這個資訊，例如需求的改變等可以通過元件的影響來分析。同樣的，改變乙個元件的影響可以在依靠它的其它元件上分析出來。
這種分析可以協助我們確定乙個改變所產生的成本，改變對於系統的影響以及改變所帶來的風險。這個資訊在我們確定改變的優先順序以及研究這些改變時是絕對必要的。
軟體架構設計的好處
系統的功能性是軟體構架師通過組成體系架構的多種元素之間的互動作用來支援的。然而，架構設計的乙個關鍵特性是，系統的品質是通過某些手段來實現的。軟體的品質，例如效能，安全性和可維護性等，它們在缺少統一的架構設計檢視時是無法實現的，因為這些品質並不是被限制在乙個單一的架構設計元素中，而是滲透在整個架構設計...
軟體架構設計
首先我們應該了解什麼是軟體架構設計？架構大體分為以下幾種 邏輯架構 模組劃分 介面定義 領域模型 開發架構 技術選型 檔案劃分 編譯關係 物理架構 硬體分布 軟體部署 方案優化 執行架構 技術選型 控制流劃分 同步關係 資料架構 技術選型 儲存格式 資料分布 程式設計師向架構師轉型的關鍵突破 學會系...
軟體架構設計
在嵌入式軟體開發的專案中，很少見到有專案架構師這一工作職稱，但是大型專案的總是會有架構師一說。1 為什麼嵌入式開發很少會出現架構師這一職責。嵌入式開發的專案，一般有兩種模式 一類是 完全由開發人員自己設計 排除庫函式 另一類是基於固有的作業系統進行開發。前者一般都是針對特定應用，所有 的規模不會很大...