| 2006 年 7 月 14 日 本文來自于 Rational Edge：這是這個系列教程的第四篇并且是最后一篇文章，Peter Eeles的這篇文章涵蓋了許多商業(yè)和IT組織可以從一個健全的軟件體系架構(gòu)獲得的益處。  一般來說，軟件架構(gòu)設(shè)計是降低成本，改進質(zhì)量，按時交付產(chǎn)品和按需交付產(chǎn)品的關(guān)鍵因素。在這篇文章中，我將會把討論的焦點放在實現(xiàn)這些目標所能帶來的好處上面。作為一個構(gòu)架師，證明我們的存在是沒有任何意義的。這個部分將會提供一些方法，這些方法對于把處理架構(gòu)設(shè)計作為一個軟件開發(fā)過程的關(guān)鍵部分是很有用處的。 架構(gòu)設(shè)計能夠滿足系統(tǒng)的品質(zhì) 系統(tǒng)的功能性是軟件構(gòu)架師通過組成體系架構(gòu)的多種元素之間的交互作用來支持的。然而，架構(gòu)設(shè)計的一個關(guān)鍵特性是，系統(tǒng)的品質(zhì)是通過某些手段來實現(xiàn)的。軟件的品質(zhì)，例如性能，安全性和可維護性等，它們在缺少統(tǒng)一的架構(gòu)設(shè)計視圖時是無法實現(xiàn)的，因為這些品質(zhì)并不是被限制在一個單一的架構(gòu)設(shè)計元素中，而是滲透在整個架構(gòu)設(shè)計體系中的。例如，為了滿足性能要求，可能需要考慮體系架構(gòu)中的每一個組件的實現(xiàn)時間，同時還要考慮各組件之間通訊所花費的時間。同樣地，為了滿足安全性要求，可能需要考慮兩個組件之間自然的通訊，并且要在需要的特定的地方引入安全性提示組件。所有的這些關(guān)系都屬于體系架構(gòu)，在上面的例子中，這些關(guān)系包括組件自身的和組件之間的。 一個和架構(gòu)設(shè)計相關(guān)的好處是，我們可以盡早的評估項目開發(fā)周期中的這些品質(zhì)。架構(gòu)設(shè)計模型的建立，通常是為了明確的確定我們已經(jīng)滿足了這些品質(zhì)的要求。這是非常重要的，因為不論寫在紙上的體系架構(gòu)多么的完美，實現(xiàn)的軟件才是評價體系架構(gòu)是否達到這些品質(zhì)的要求的唯一標準。 架構(gòu)設(shè)計的過程使得不同的涉眾達成一致的目標，因為架構(gòu)設(shè)計提供了一個辯論系統(tǒng)解決方案的媒體。為了支持這種辯論，體系架構(gòu)的過程需要確保架構(gòu)設(shè)計被清楚地傳達與理解。一個被有效傳達的體系架構(gòu)使得涉眾們可以辯論決議和權(quán)衡，反復(fù)討論，最終達成共識。相反，如果一個體系架構(gòu)沒有被有效的傳達，那么這種辯論將不會發(fā)生。沒有了有效的傳達，體系架構(gòu)所帶來的結(jié)果可能會是低品質(zhì)的。 在一條相關(guān)的說明中，體系架構(gòu)可能會使構(gòu)架師之間或者新成員與老成員之間的辯論達成一致（以及他們之間的視圖）。我們需要再次強調(diào)，只有體系架構(gòu)被有效傳達，它所帶來的這個好處才能體現(xiàn)出來。清楚地了解他們正在做什么的開發(fā)小組更可能按照需求完成產(chǎn)品的開發(fā)。 為此，我再次強調(diào)恰當?shù)奈臋n化體系架構(gòu)是非常重要的，這是軟件構(gòu)架師的主要職責。同樣的，一個架構(gòu)設(shè)計的概念證明是一個證明體系架構(gòu)是否滿足最初的需求的極好的方法。 架構(gòu)設(shè)計的過程支持一些步驟。很明顯，它支持設(shè)計和實現(xiàn)活動，因為體系架構(gòu)是直接使用到這些活動中的。然而，在架構(gòu)設(shè)計過程所帶來的好處中，我們可以證明其中最主要的好處通常是那些和支持相關(guān)的，被提供給項目計劃和項目管理的活動，例如：細節(jié)化分，日程安排，工作分配，成本分析，風險管理和技能開發(fā)等。架構(gòu)設(shè)計的過程可以支持所有這些相關(guān)內(nèi)容，這也正是軟件構(gòu)架師和項目經(jīng)理應(yīng)該擁有一種很密切關(guān)系的一個主要原因。這個支持的大部分來自于體系架構(gòu)確定的系統(tǒng)中重要的組件和它們之間關(guān)系的行為。請看圖1中的UML組件圖，它已經(jīng)為我們的討論作了簡化。這個圖顯示了這四個組件之間的依賴性。  圖1：UML組件圖顯示了架構(gòu)設(shè)計中的重要元素 在日程安排方面，它們之間的依賴性暗示了每一個元素被考慮的順序。從一個實施透視圖來看，例如，依賴性告訴我們Error Log組件必須最先實現(xiàn)，因為其余的所有組件都要使用它。Customer Management和Fulfillment組件可以同時實現(xiàn)，因為它們之間不存在依賴關(guān)系。最后，一旦這兩個組件也被實現(xiàn)完了，那么Account Management組件就可以被實現(xiàn)了。通過這個信息，我們可以畫出甘特圖（項目經(jīng)理的一個主要計劃編制工具），如圖2所示。圖中顯示的每一個任務(wù)在實現(xiàn)時間時都需要一些思考，但是它們中的一部分可以來源于每一個架構(gòu)設(shè)計元素的復(fù)雜性。  圖2：基于架構(gòu)設(shè)計中重要元素之間依賴性的甘特圖 很明顯這是一個很多原因的總的簡化。例如，所有這些元素都不可能作為一個單一的組件被實現(xiàn)，但是這對于一個用例來說太過復(fù)雜了。同樣，我們可以建立"存根的"或者部分的實現(xiàn)，使得每一個元素的實現(xiàn)都能夠平行實現(xiàn)。我使用這個例子來簡單的證明這個原理。 在工作分配中，體系架構(gòu)能夠再次幫助我們鑒別需要特定技能的區(qū)域，使得我們可以把工作分配給特定的資源（例如：人）。 構(gòu)架師還能協(xié)助估算項目成本。一個項目的成本來自多個方面。很明顯，任務(wù)的持續(xù)時間和分配給每一部分的資源將會決定勞動力的成本。體系架構(gòu)同樣會幫助我們決定使用在交付的系統(tǒng)中的第三方組件的成本，以及支持開發(fā)成果的所有工具的成本，因為構(gòu)架師參與的活動是一個經(jīng)過挑選的恰當?shù)拈_發(fā)環(huán)境，它允許設(shè)計人員，實現(xiàn)人員和其他小組成員使用同一個有效的方式一起工作。 構(gòu)架師的另外一個焦點是鑒別和管理項目的技術(shù)風險。技術(shù)風險的管理包括制定每一個風險的優(yōu)先次序，以及確定一個恰當?shù)娘L險緩解策略。優(yōu)先權(quán)和風險緩解策略作為輸入部分提供給項目經(jīng)理。 最后，體系架構(gòu)確定離散組件的解決方案，它可以為項目提供所需的技術(shù)輸入。如果項目或者組織中沒有足夠可用的資源，那么它會明確的辨別出哪里需要技術(shù)支持。這可以通過現(xiàn)存的職員，或者外包，或者通過雇傭新職員來實現(xiàn)。
架構(gòu)設(shè)計可以推動體系架構(gòu)的完整性 架構(gòu)設(shè)計過程的一個主要目標就是確保體系架構(gòu)能夠為設(shè)計人員和實現(xiàn)人員所承擔的工作提供可靠的構(gòu)架。很明顯，這比簡單的傳送一個體系架構(gòu)視圖要復(fù)雜的多。為了確保最終體系架構(gòu)的完整性，構(gòu)架師必須明確的定義體系架構(gòu)，因為它確定了體系架構(gòu)的重要元素，例如系統(tǒng)的組件，組件之間的接口以及組件之間的通信。 構(gòu)架師同時還必須定義恰當?shù)膽T例，標準和指導(dǎo)方針，它們將會引導(dǎo)設(shè)計人員和實現(xiàn)人員的工作。架構(gòu)設(shè)計的另外一個目標是去除部分設(shè)計人員和實現(xiàn)人員不必要的創(chuàng)意，這是通過對他們所做的事情增加必要的限制，以及讓他們清楚地知道如果不遵循這些限制將可能會導(dǎo)致體系架構(gòu)的破壞來實現(xiàn)的。出于這個原因，對活動采取恰當?shù)幕仡櫤驮u估，能夠確保體系架構(gòu)的完整性。這些活動的一個焦點是考慮設(shè)計人員和實現(xiàn)人員的工作，以及確定體系架構(gòu)的標準和指導(dǎo)方針的到位程度。 如今的系統(tǒng)越來越復(fù)雜，這種復(fù)雜性需要我們?nèi)ス芾?。自從一個體系架構(gòu)只把焦點集中在這些元素上以來，它就提供了一個抽象的系統(tǒng)，因而提供了一個復(fù)雜的管理方法。同樣，架構(gòu)設(shè)計過程考慮組件的遞歸分解。這是處理一個大的問題的很好的一個方法，它可以把這個大問題分解成很多的小問題，再逐個的解決。 抽象的體系架構(gòu)之間的通信技術(shù)使得管理更加復(fù)雜。采取業(yè)界標準可以表達這種抽象性，例如UML，因此在現(xiàn)今的產(chǎn)業(yè)中文檔化軟件系統(tǒng)是非常平常的事情。 架構(gòu)設(shè)計為復(fù)用奠定了基礎(chǔ) 架構(gòu)設(shè)計過程可以同時支持使用和建立復(fù)用資源。復(fù)用資源對于一個組織來說是有益的，因為它可以降低一個系統(tǒng)的成本，并且可以改進系統(tǒng)的質(zhì)量，這些好處已經(jīng)被證明過了（自從它被使用以來）。 一個體系架構(gòu)的建立，能夠支持資源復(fù)用的機會。例如，體系架構(gòu)的重要組件和它們之間的接口和質(zhì)量，能夠支持現(xiàn)貨供應(yīng)的組件，存在的系統(tǒng)和封裝的應(yīng)用程序等等的選擇，從而可以用來實現(xiàn)這些組件。體系架構(gòu)自身也可以被用來當作今后開發(fā)的系統(tǒng)的一個復(fù)用參考資源。甚至體系架構(gòu)內(nèi)部的組件也可以被認為是潛在的復(fù)用資源。 雖然架構(gòu)設(shè)計過程能夠鑒別現(xiàn)今項目中存在的資源復(fù)用的機會，但是跨項目和企業(yè)的資源復(fù)用會導(dǎo)致產(chǎn)生很大的沖突。 任何關(guān)于復(fù)用的討論都要和謹慎聯(lián)系在一起。由于各方面的原因，只有很少一部分復(fù)用程序能夠使用到現(xiàn)在。從技術(shù)的角度看，一個復(fù)用的程序需要確保標準，過程和工具都在恰當?shù)奈恢?。幸運的是一些基本元素正在被滿足。一個好的例子就是標準化組織：Object Management Group‘s Reusable Asset Specification (RAS)， 1 它定義了描述復(fù)用資源，封裝復(fù)用資源和連接到RAS資源庫服務(wù)的接口的標準 從非技術(shù)的角度看，當你實現(xiàn)一個復(fù)用策略時，需要始終牢記組織的考慮。例如，確定誰是建立復(fù)用資源的人員？一旦復(fù)用資源被建立，誰是負責維護它的人（建立它的小組已經(jīng)解散）？使用和建立復(fù)用資源的動力是什么？建立一個復(fù)用資源的成本是多少，這通常比建立一個不恰當?shù)膹?fù)用資源要花費更多。 架構(gòu)設(shè)計過程可以在很多方面幫助我們降低維護費用。首先最重要的是架構(gòu)設(shè)計過程要確保系統(tǒng)的維護人員是一個主要的涉眾，并且他們的需求被作為首要的任務(wù)滿足。一個被恰當文檔化的體系架構(gòu)不應(yīng)該僅僅為了減輕系統(tǒng)的可維護性；構(gòu)架師還應(yīng)該確保結(jié)合了恰當?shù)南到y(tǒng)維護機制，并且在建立體系架構(gòu)的時候還要考慮系統(tǒng)的適應(yīng)性和可擴充性。 構(gòu)架師還應(yīng)該考慮那些需要改變的區(qū)域，并把它們隔離開。這樣可以保證當單個組件或者一小部分組件發(fā)生變化時，整個系統(tǒng)不會受很大的影響。但是我們應(yīng)該承認，有一些變化，例如關(guān)系到系統(tǒng)質(zhì)量，如實現(xiàn)性和可靠性，是不能用這個方法隔離的。這就是構(gòu)架師必須確保它的原因，當架構(gòu)設(shè)計現(xiàn)在的系統(tǒng)時，他們需要考慮將來可能的需求，因為這個系統(tǒng)要從幾十人的用戶推廣到上千人的用戶群，例如，體系架構(gòu)沒有使用基礎(chǔ)的方法改變是不正常的。 架構(gòu)設(shè)計的一個重要的好處是它可以允許我們在采取改變之前推斷它所產(chǎn)生的影響。一個軟件構(gòu)架確定了主要的組件和它們之間的交互作用，兩個組件之間的依賴性以及這些組件對于需求的可追溯性。 有了這個信息，例如需求的改變等可以通過組件的影響來分析。同樣的，改變一個組件的影響可以在依靠它的其它組件上分析出來。 這種分析可以協(xié)助我們確定一個改變所產(chǎn)生的成本，改變對于系統(tǒng)的影響以及改變所帶來的風險。這個信息在我們確定改變的優(yōu)先級以及研究這些改變時是絕對必要的。 這篇文章的內(nèi)容來源于一本即將出版的圖書，我暫時把這本書命名為"軟件架構(gòu)設(shè)計過程。" 很多的人為這篇文章作了評論，我在這里要謝謝他們，他們是：Grady Booch，Dave Braines，Alan Brown，Mark Dickson，Luan Doan-Minh，Holger Heuss，Kelli Houston，Philippe Kruchten，Nick Rozanski，Dave Williams，and Eoin Woods。
| ||||||||||
聯(lián)系客服
