免费看黄网站在线看,亚洲欧美人成人综合在线50p,波霸欧美性猛交xxxxxx

　　本文最初發(fā)表在IEEE軟件雜志，現(xiàn)在由 InfoQ & IEEE 計(jì)算機(jī)協(xié)會(huì)為您呈現(xiàn)。
　　軟件架構(gòu)師在設(shè)計(jì)時(shí)需要作出很多決策。作出正確的關(guān)鍵架構(gòu)決策，其重要性不言自明。^1-3但是，要總結(jié)出什么是關(guān)鍵決策絕非易事，更不用說何時(shí)以及如何作這樣的決策。早先，架構(gòu)決策作為設(shè)計(jì)決策的一部分已被定性為做起來很難⁴，改起來又費(fèi)勁。⁵為了澄清這些問題，我們?cè)谙旅娼o出的架構(gòu)決策定義中增加了一些條件邏輯⁶：

　　架構(gòu)決策要識(shí)別出關(guān)鍵設(shè)計(jì)難點(diǎn)和隱藏在所選方案中的原理。它們是慎重的設(shè)計(jì)決策，這些決策將軟件密集型系統(tǒng)視作一個(gè)整體或?qū)⒃撓到y(tǒng)的一個(gè)或多個(gè)核心組件及組件間的關(guān)聯(lián)關(guān)系歸于任意既定的視圖。架構(gòu)決策產(chǎn)生的結(jié)果影響系統(tǒng)的非功能性特征和軟件質(zhì)量指標(biāo)。

　　根據(jù)上述定義，無論是選擇一門編程語(yǔ)言、架構(gòu)模式、應(yīng)用容器技術(shù)或中間件資產(chǎn)都算作架構(gòu)決策。比如，Broker這樣的集成模式描述了分布式系統(tǒng)會(huì)遇到的阻力，包括位置獨(dú)立性和網(wǎng)絡(luò)問題⁷ 。這些阻力適合作為決策的驅(qū)動(dòng)力，所以是否將Broker模式添加到架構(gòu)中來就是一種需要慎重判斷的架構(gòu)決策。一些頂尖的軟件工程方法，比如IBM統(tǒng)一方法框架（Unified Method Framework），需要將架構(gòu)決策記錄成文并且在統(tǒng)一的地方對(duì)這些關(guān)鍵決策進(jìn)行論證⁸。

　　在把各個(gè)功能分散對(duì)應(yīng)到各系統(tǒng)模塊時(shí)，記錄日志可以保證設(shè)計(jì)的完整性。通過確保架構(gòu)的可擴(kuò)展性，這些日志支持漸進(jìn)式系統(tǒng)。它們也為新加入項(xiàng)目的人員提供了參考，以避免對(duì)已經(jīng)確定了的問題重復(fù)考量。日志可以在事后捕獲架構(gòu)決策。創(chuàng)建這種日志是一種短期受益很少但長(zhǎng)期受益頗多的文檔活動(dòng)⁹。如果我們對(duì)某個(gè)特定的項(xiàng)目放松文檔要求，并假設(shè)同一應(yīng)用類型的多個(gè)項(xiàng)目遵照同樣的架構(gòu)樣式——共享同樣的原則和模式——那么我們可以考慮將架構(gòu)決策從文檔工件升級(jí)為設(shè)計(jì)指導(dǎo)。

　　這些設(shè)計(jì)指導(dǎo)可以幫助那些習(xí)慣了某一特殊類型的應(yīng)用和架構(gòu)風(fēng)格的架構(gòu)師們理解做決策的需求和可選方案，而這些方案往往基于成功應(yīng)用于類似情況下的相同知識(shí)。這樣的話，重現(xiàn)的架構(gòu)決策就成為可復(fù)用資產(chǎn)，就像方法和模式那樣。這會(huì)衍生出新的使用場(chǎng)景。比如，重現(xiàn)的問題可以用作審核檢查列表，幫助劃分設(shè)計(jì)和開發(fā)工作項(xiàng)的優(yōu)先級(jí)，促進(jìn)企業(yè)和項(xiàng)目架構(gòu)師之間的溝通。

　　SOA決策——建模框架

　　在設(shè)計(jì)過程中將重現(xiàn)的架構(gòu)決策提升到指導(dǎo)角色的高度，首先需要有效地捕獲和總結(jié)相關(guān)的項(xiàng)目經(jīng)驗(yàn)。這是知識(shí)工程的行為。面向服務(wù)架構(gòu)（SOA）決策建模（SOAD）提供了支撐該行為的一種知識(shí)管理框架¹⁰。當(dāng)SOA風(fēng)格應(yīng)用于某一特定類型的應(yīng)用，如企業(yè)應(yīng)用，SOAD可提供一種技術(shù)以系統(tǒng)地識(shí)別這些應(yīng)用中重現(xiàn)的那些決策。SOAD對(duì)已有的元模型和模板進(jìn)行了增強(qiáng)^8,11 ，具體說來就是將決策需求從決策制定中區(qū)分出來。它建立了多層次的知識(shí)組織可以將平臺(tái)獨(dú)立的決策從平臺(tái)特定的決策中區(qū)分出來。在概念層次，設(shè)計(jì)備選參考架構(gòu)模式，比如Martin Fowler定義的那些¹² 或其它的^7,13,14。

　　SOAD框架使得知識(shí)工程師以及軟件架構(gòu)師能夠管理決策依賴，這樣他們可以檢查模型一致性并刪除不相干的決策。一個(gè)條理清晰的問題集可以指導(dǎo)決策過程。有了框架提供的支持，架構(gòu)師能夠根據(jù)決策更新設(shè)計(jì)工件，而決策是通過將決策產(chǎn)出件注入模型轉(zhuǎn)換中而實(shí)現(xiàn)的⁶。

　　為了支持復(fù)用，SOAD元模型定義了兩種類型的模型：

指導(dǎo)模型用以識(shí)別必需的決策。
決策模型用以記錄決策制定。

　　圖1展現(xiàn)了這些模型之間的關(guān)系和內(nèi)部結(jié)構(gòu)。⁶

　　圖1. 面向服務(wù)架構(gòu)（SOA）決策模型（SOAD）框架。SOAD元模型被實(shí)例化到一個(gè)指導(dǎo)模型內(nèi)，該指導(dǎo)模型可識(shí)別某一特定架構(gòu)風(fēng)格（如SOA）所必需的決策。架構(gòu)師對(duì)指導(dǎo)模型做裁剪以創(chuàng)建針對(duì)某一項(xiàng)目的決策模型雛形。

　　指導(dǎo)模型是一種可復(fù)用的資產(chǎn)，它包括在某類特定應(yīng)用類型中使用某一架構(gòu)風(fēng)格時(shí)所必需的架構(gòu)決策的知識(shí)。該模型基于已完成的、采用同一類架構(gòu)風(fēng)格的項(xiàng)目中獲得知識(shí)。如圖1所示，每個(gè)問題都提示架構(gòu)師：這是一類特定的設(shè)計(jì)問題，需要作出架構(gòu)決策。問題反映了決策驅(qū)動(dòng)各種類型，比如質(zhì)量指標(biāo)、根據(jù)其優(yōu)點(diǎn)和缺點(diǎn)確定的參考潛在備選方案以及在之前應(yīng)用中的已知用法。知識(shí)工程師將這些問題和備選方案寫成文檔，編寫文檔時(shí)采用將來時(shí)態(tài)，其口吻就像技術(shù)導(dǎo)師在交談時(shí)所使用的口吻一樣。

　　通過裁剪不相干項(xiàng)、改進(jìn)增強(qiáng)相關(guān)項(xiàng)、增加新問題項(xiàng)，指導(dǎo)模型可為具體項(xiàng)目提供指導(dǎo)。決策模型作為架構(gòu)文檔工件不僅包含需要做的架構(gòu)決策，還包含已做完的架構(gòu)決策。其輸出件是項(xiàng)目中實(shí)際所做決策的日志記錄，并附帶決策依據(jù)。在SOAD中，產(chǎn)出件代表軟件架構(gòu)師現(xiàn)在（或過去）在項(xiàng)目中獲取的設(shè)計(jì)研討紀(jì)要。一個(gè)決策模型可以重用一個(gè)/多個(gè)指導(dǎo)模型。它可以為已作出的決策提供信息使其在項(xiàng)目結(jié)束后通過資產(chǎn)總結(jié)活動(dòng)（可能包括所有從以往經(jīng)驗(yàn)中得到的正式或非正式評(píng)論）將信息反饋給指導(dǎo)模型。在SOA設(shè)計(jì)中，比如，一個(gè)保險(xiǎn)公司的業(yè)務(wù)流程模型可能描述了某個(gè)后臺(tái)系統(tǒng)必須實(shí)現(xiàn)和集成的三個(gè)不同的業(yè)務(wù)活動(dòng)（客戶索賠、理賠審核和風(fēng)險(xiǎn)評(píng)估）以及相應(yīng)的服務(wù)操作。

　　架構(gòu)師必須要為項(xiàng)目選擇一種集成風(fēng)格，比如由Gregor Hohpe和Bobby Woolf針對(duì)此問題識(shí)別出的四大可選模式之一：文件傳輸、共享數(shù)據(jù)庫(kù)、RPC或消息傳輸¹³。架構(gòu)師也必須選擇一種集成技術(shù)，如HTTP和Java消息服務(wù)（JMS），以使不同業(yè)務(wù)活動(dòng)之間相互交互。問題陳述（“在業(yè)務(wù)流程中的業(yè)務(wù)活動(dòng)及服務(wù)操作和其他模塊——比如遺留系統(tǒng)——交互時(shí)，將會(huì)用哪種技術(shù)？”）以及決策驅(qū)動(dòng)（“互操作性、可靠性和工具支持”）對(duì)所有三種服務(wù)操作同樣適用。

　　與具體項(xiàng)目相關(guān)的決策成果，比如備選方案及理由，取決于每個(gè)操作各自的需求。比如，“對(duì)于客戶索賠來說，我們選擇RPC和HTTP的理由是Java和C#模塊必須以一種簡(jiǎn)單并可交互的方式來集成，所以我們看重可用Web services工具的支持。”可是，“對(duì)于風(fēng)險(xiǎn)評(píng)估來說，我們選擇消息傳輸和JMS的理由是需要集成的一些后臺(tái)系統(tǒng)可用性較差，我們一定要保證消息的可靠性。”

　　從一般性問題到SOA指導(dǎo)模型

　　我將使用保險(xiǎn)公司的例子來做總結(jié)，然后擴(kuò)展出兩個(gè)必需的決策——集成風(fēng)格和集成技術(shù)的問題。首先需要把那些CS架構(gòu)中出現(xiàn)的普遍問題加入到一張通用的模塊及連接器的圖中，如圖2所示，模塊和連接器都是服務(wù)消費(fèi)者（客戶）和服務(wù)提供者（服務(wù)）在分層系統(tǒng)中的一種概括。

　　圖2. 通用的模塊及連接器架構(gòu)中普遍存在的問題。每個(gè)模塊和連接器產(chǎn)生的問題是普遍問題的具體化。該層次可向下一實(shí)現(xiàn)層轉(zhuǎn)變，譬如從概念模型組件模型，到細(xì)化組件模型，再到實(shí)現(xiàn)組件模型。

　　舉例來說，層次n可能被實(shí)例化為表現(xiàn)層、業(yè)務(wù)邏輯層和持久層之類的面向服務(wù)的企業(yè)應(yīng)用¹²。從這樣的實(shí)例化來看，保險(xiǎn)公司示例中的三個(gè)業(yè)務(wù)活動(dòng)（客戶索賠，理賠審核和風(fēng)險(xiǎn)評(píng)估）和服務(wù)操作都屬于架構(gòu)中業(yè)務(wù)邏輯這一層。在優(yōu)化設(shè)計(jì)使之成為具體架構(gòu)時(shí)，圖中每一小塊（比如，圖2，“接口簽名？”）都應(yīng)該看作一個(gè)普遍問題，需要仔細(xì)研究。接下來需要將普遍問題和SOA模式結(jié)合起來。有些作者已經(jīng)對(duì)該SOA模式進(jìn)行了描述——比如Uwe Zdun和他的同事們¹⁴。 SOAD框架將使用如下SOA定義⁶：

　　從架構(gòu)設(shè)計(jì)的視角來看，SOA引入了一個(gè)服務(wù)消費(fèi)者（請(qǐng)求方），一個(gè)服務(wù)提供者和一份服務(wù)契約。這些模式促進(jìn)了架構(gòu)模塊化和平臺(tái)透明性原則。組合架構(gòu)模式，如企業(yè)服務(wù)總線（ESB），管理服務(wù)消費(fèi)者與服務(wù)提供方之間的交互和物理分布，以此來支持諸如協(xié)議透明性和消息格式透明之類的原則。服務(wù)組合模式將各種處理邏輯組合起來，參照邏輯分層原則和流程獨(dú)立性。而服務(wù)注冊(cè)模式定義了如何查找服務(wù)提供者等相關(guān)原則，如位置透明和服務(wù)虛擬。

　　圖3描述了將通用的CS組件實(shí)例化成功能架構(gòu)概覽圖中，解釋了這些模式機(jī)器構(gòu)建模塊在SOA中是怎么交互的⁶。

　　如圖3所示，SOA風(fēng)格的本質(zhì)是通過服務(wù)契約、ESB消息傳輸和服務(wù)注冊(cè)達(dá)到服務(wù)消費(fèi)者和服務(wù)提供者之間的解耦。ESB模式由另外三種模式組成：中介器模式、路由器模式和適配器模式。為了將平臺(tái)特定設(shè)計(jì)從平臺(tái)獨(dú)立設(shè)計(jì)中區(qū)分開，SOA基于模式的特征淡化了Web Service等技術(shù)。將圖2中的普遍問題和圖3中的SOA模式結(jié)合起可以引出具體問題的重現(xiàn)。識(shí)別這些問題及備選方案可以使技術(shù)專家們從使用這些模式的項(xiàng)目經(jīng)驗(yàn)中獲得決策驅(qū)動(dòng)因素、優(yōu)點(diǎn)、缺點(diǎn)以及建議。

　　圖3.SOA模式及其協(xié)作和功能性分解。服務(wù)消費(fèi)者和提供者通過ESB模式進(jìn)行交互。服務(wù)注冊(cè)羅列出服務(wù)消費(fèi)者可用的所有服務(wù)契約和服務(wù)提供者。

　　執(zhí)行層決策

　　認(rèn)定SOA為首選架構(gòu)風(fēng)格，這本身就是一種管理決策，因此選擇特定的SOA參考架構(gòu)就是執(zhí)行層的決策。這需要在名詞術(shù)語(yǔ)上達(dá)成一致，比如層次和模塊的名稱，相關(guān)模式語(yǔ)言的識(shí)別。架構(gòu)原則也可能采用執(zhí)行層決策的形式，比如，選擇開源資產(chǎn)還是某軟件廠商和服務(wù)器基礎(chǔ)設(shè)施？這對(duì)應(yīng)到圖2中的通用問題就是“整體的層次間組織結(jié)構(gòu)？（Overall layer organization）”

　　概念性的、平臺(tái)獨(dú)立的設(shè)計(jì)問題

　　服務(wù)設(shè)計(jì)者必須根據(jù)操作簽名中的請(qǐng)求和響應(yīng)消息參數(shù)來決定服務(wù)契約的粒度。這些簽名指定了服務(wù)調(diào)用的語(yǔ)法和消息載體的結(jié)構(gòu)。這一問題關(guān)心服務(wù)契約的設(shè)計(jì)。根據(jù)圖3所示的SOA模式，服務(wù)契約是SOA接口的實(shí)例化；因此，根據(jù)圖2，通用問題“接口簽名是什么？（Interface signature）” 適用于該設(shè)計(jì)上下文。詳細(xì)的ESB設(shè)計(jì)和配置又引起另一類問題。架構(gòu)師們必須選擇消息交互模式，比如單向操作及請(qǐng)求——應(yīng)答（異步與同步通訊）。他們也必須要詳述路由器、中介器和適配器模式的具體用法，描述如何將消息從服務(wù)消費(fèi)者轉(zhuǎn)移到服務(wù)提供者（路由器）、如何當(dāng)消息在ESB（中介器）中傳輸時(shí)進(jìn)行消息內(nèi)容的轉(zhuǎn)換、如何與非SOA的系統(tǒng)和模塊（適配器）進(jìn)行集成¹³。

　　遵循SOA風(fēng)格的架構(gòu)師也必須細(xì)化服務(wù)組合設(shè)計(jì)（如果他們選擇了這種SOA模式）。選擇某個(gè)集中式流程管理器¹³，如工作流引擎（與之相對(duì)的是在各個(gè)應(yīng)用或模塊中的分布式狀態(tài)管理），就業(yè)務(wù)邏輯層的內(nèi)部結(jié)構(gòu)而言，是一項(xiàng)重要的架構(gòu)決策。至于服務(wù)注冊(cè)，設(shè)計(jì)時(shí)和運(yùn)行時(shí)的注冊(cè)查詢是設(shè)計(jì)問題的一個(gè)例子。“組件的生命周期管理（Component life-cycle management）”是對(duì)應(yīng)的通用問題（如圖2）。

　　平臺(tái)相關(guān)的設(shè)計(jì)問題

　　概要設(shè)計(jì)問題不會(huì)涉及到任何技術(shù)標(biāo)準(zhǔn)或其具體實(shí)現(xiàn)。然而，選擇一種或多種SOA模式的架構(gòu)師也必須負(fù)責(zé)解決平臺(tái)相關(guān)的問題——比如說，選擇并勾畫諸如WS* Web Service作為集成技術(shù)的具體實(shí)現(xiàn)技術(shù)。一旦選擇了某種技術(shù)，架構(gòu)師就必須選擇和配置實(shí)現(xiàn)平臺(tái)。許多SOA模式都有商用和開源中間件的實(shí)現(xiàn)。架構(gòu)師必須決定是否需要購(gòu)買該中間件以及，如果購(gòu)買了，如何進(jìn)行安裝和配置。

　　可復(fù)用的設(shè)計(jì)資產(chǎn)：SOA指導(dǎo)模型

　　根據(jù)前文摘要中的定義，我描述的所有SOA設(shè)計(jì)問題都適合作為架構(gòu)決策。比如，服務(wù)操作的簽名將會(huì)對(duì)性能和互操作性等質(zhì)量屬性產(chǎn)生影響。而且，這些問題會(huì)重復(fù)出現(xiàn)。只要一個(gè)項(xiàng)目應(yīng)用了SOA模式，那它就必須一而再再而三的解決類似的問題。因此，我們期待知識(shí)的重復(fù)利用。

　　我在SOA指導(dǎo)模型中收集了500個(gè)經(jīng)常重現(xiàn)的問題^6,10。

　　SOAD案例研究報(bào)告

　　實(shí)踐架構(gòu)師已經(jīng)在十多個(gè)項(xiàng)目中成功地應(yīng)用了SOAD和SOA指導(dǎo)模型。這些項(xiàng)目包括為歐洲某國(guó)社會(huì)保障部開發(fā)的養(yǎng)老金計(jì)劃管理應(yīng)用、為某電信公司開發(fā)的客戶和訂單管理方案以及為某多渠道零售商開發(fā)的B2B電子商務(wù)應(yīng)用。這些案例研究確定了很多重現(xiàn)的問題。參與項(xiàng)目的架構(gòu)師對(duì)SOA指導(dǎo)模型中知識(shí)的相關(guān)性和可行性方面做了評(píng)估。評(píng)估結(jié)果表明在設(shè)計(jì)活動(dòng)方面速度和質(zhì)量都有改進(jìn)，并且SOAD視角和方法也廣受贊賞^6,9。

　　SOAD框架反饋

　　在案例研究項(xiàng)目過程中，我和幾百位架構(gòu)師就SOAD的價(jià)值和可用性等方面進(jìn)行了交流，聽取了他們的反饋意見。只有一位架構(gòu)師公開不同意SOAD的基本假設(shè) ——即當(dāng)在同一類型的項(xiàng)目上使用相同的架構(gòu)風(fēng)格時(shí)，會(huì)出現(xiàn)相同的架構(gòu)決策，而這一反對(duì)最終發(fā)現(xiàn)實(shí)際上是誤會(huì)一場(chǎng)。SOAD并沒有聲明某個(gè)決策始終會(huì)產(chǎn)生相同的成果；它只是表明那種對(duì)決策所需要的問題，會(huì)重現(xiàn)。

　　案例研究參與者們發(fā)現(xiàn)SOAD元模型是能夠被直觀理解的、包含有用且充分的信息，這些屬性都有助于做關(guān)鍵決策。他們還建議添加一些別的屬性。他們還建議采用不同的方式來構(gòu)造指導(dǎo)模型——包括由企業(yè)架構(gòu)框架定義的組織機(jī)構(gòu)的維度。

　　參與者將決策的依賴管理視作決策模型的一項(xiàng)重要優(yōu)勢(shì)，因?yàn)橛梦谋拘问降臎Q策日志來管理這些決策的依賴是很困難的。他們還指出，當(dāng)一種成熟的決策方法已經(jīng)存在時(shí)，任何其他的方法都必須與其保持一致。他們將SOAD視作一種支撐資產(chǎn)——一項(xiàng)內(nèi)置在通用目標(biāo)方法中的決策制定技術(shù)——而不是一種孤立的方法。

　　SOA指導(dǎo)模型的反饋

　　案例研究的參與者都很認(rèn)同指導(dǎo)模型的內(nèi)容和各細(xì)節(jié)層次。他們認(rèn)為它不夸張很合適、與SOA行業(yè)項(xiàng)目相關(guān)、而且歸檔清晰，總之是恰如其分。

　　他們對(duì)主動(dòng)決策模型和回顧市決策模型有一些疑惑。有一個(gè)用戶通過決策日志簡(jiǎn)單地從指導(dǎo)模型中拷貝問題的描述和建議屬性，由此生產(chǎn)決策依據(jù)。這在部門內(nèi)部技術(shù)質(zhì)量評(píng)估審核會(huì)上，這一做法引起了高級(jí)架構(gòu)師的批判。總之，必須要對(duì)使用SOAD的期望進(jìn)行管理。SOAD的不鼓勵(lì)孤立地執(zhí)行架構(gòu)思考。

　　使用場(chǎng)景和討論

　　SOAD是以決策為中心的方法指導(dǎo)設(shè)計(jì)工作的。它的一大優(yōu)勢(shì)是目標(biāo)受眾、軟件架構(gòu)師能從不同的使用場(chǎng)景中理解架構(gòu)決策的核心概念——架構(gòu)文檔。這使SOAD在其他場(chǎng)景中的的應(yīng)用得以簡(jiǎn)化：

IT用戶可以通過要求提供方交付標(biāo)準(zhǔn)的、與其軟件方案或產(chǎn)品一致的決策日志來維護(hù)對(duì)他們應(yīng)用的控制。用戶可以根據(jù)SOAD元模型使決策日志結(jié)構(gòu)化，并從共享指導(dǎo)模型中生成這些日志。
那些開發(fā)多種軟件密集型產(chǎn)品（線）的公司可以要求其企業(yè)架構(gòu)師創(chuàng)建一個(gè)公司范圍的指導(dǎo)模型。通過采用公司指定的SOAD元模型、方法和工具組能夠?qū)χ笇?dǎo)模型活動(dòng)提供支持。這種方法可以縮短產(chǎn)品近入市場(chǎng)的時(shí)間，還能使不同產(chǎn)品的架構(gòu)保持一致。
指導(dǎo)模型中加注了最佳實(shí)踐建議，通過共享其中的技術(shù)知識(shí)，提供復(fù)雜商業(yè)套件的廠商可以減少培訓(xùn)、客戶化定義和技術(shù)支持。
在專業(yè)服務(wù)中，實(shí)踐群體重視明晰的知識(shí)管理，可復(fù)用資產(chǎn)能夠創(chuàng)建指導(dǎo)模型用以支持基于勞動(dòng)力的交付模型向基于資產(chǎn)的交付模型（戰(zhàn)略再利用）轉(zhuǎn)變。
培訓(xùn)師可以將指導(dǎo)模型作為一種系統(tǒng)化的方法來教授模式和各種技術(shù)最佳實(shí)踐。
那些想要以一種可復(fù)用的、高效的方法來評(píng)估中間件和企業(yè)應(yīng)用分析師和受眾可以把標(biāo)準(zhǔn)化的、領(lǐng)域相關(guān)的問卷建立在可復(fù)現(xiàn)的設(shè)計(jì)問題上。他們可以根據(jù)SOAD元模型來為這些問題建模。

　　SOAD 假設(shè)多數(shù)問題都會(huì)重復(fù)發(fā)生。如果不是這樣的話，那指導(dǎo)模型資產(chǎn)不能為其產(chǎn)出物帶來足夠的價(jià)值。如果多個(gè)項(xiàng)目采用相同的架構(gòu)風(fēng)格，那么問題發(fā)生的假設(shè)很有可能成立。然而，使用SOAD描述問題和備選方案還包括對(duì)知識(shí)工程的承諾。指導(dǎo)模型必須比具體項(xiàng)目的決策日志具有更高的編輯標(biāo)準(zhǔn)，所以創(chuàng)建這樣模型的決策必須支持知識(shí)管理策略。它需要一個(gè)基本的模型、一個(gè)審核、批準(zhǔn)和維護(hù)流程。使用SOAD三年，我的經(jīng)驗(yàn)告訴我，平均來看，專業(yè)工程師完全可以在一個(gè)人天內(nèi)完成對(duì)一個(gè)問題的建模。

　　架構(gòu)師已經(jīng)能夠從不完整的建模知識(shí)中獲益，比如以問題的形式清晰地描述的問題檢查清單。除此之外，工具能夠部分地自動(dòng)化生成資產(chǎn) ——比如，從項(xiàng)目工件中提取出架構(gòu)知識(shí)的挖掘工具。從工具設(shè)計(jì)的角度來看，展示信息的多少、上下文相關(guān)的過濾和排序能力是成功的關(guān)鍵。架構(gòu)師一般都會(huì)花時(shí)間和企業(yè)（組織）內(nèi)外的干系人進(jìn)行溝通，所以他們不一定愿意從頭到尾閱讀指導(dǎo)模型（雖然我一些同事已經(jīng)這樣做了）。工具可以將指導(dǎo)模型裁剪到和某個(gè)給定設(shè)計(jì)上下文相關(guān)的問題和備選方案，要先裁剪然后才能在項(xiàng)目中全面施行。SOAD的元模型能偶這樣的工具開發(fā)，比如，為問題設(shè)定范圍屬性，指出問題一般應(yīng)在那個(gè)項(xiàng)目解決得到解決。

　　結(jié)論

　　最初創(chuàng)建SOAD 的原因是支持企業(yè)應(yīng)用和SOA設(shè)計(jì)，而指導(dǎo)模型的使用則是作為可重用資產(chǎn)也適用于其他應(yīng)用系統(tǒng)和架構(gòu)風(fēng)格。它支持的應(yīng)用場(chǎng)景包括教育、知識(shí)交換、設(shè)計(jì)方法和治理。下一步對(duì)它的擴(kuò)展包括，將其擴(kuò)展到其他的業(yè)務(wù)和技術(shù)領(lǐng)域以及目標(biāo)受眾，如除軟件架構(gòu)師之外的業(yè)務(wù)人員。其他解決指導(dǎo)模型所面臨的挑戰(zhàn)的計(jì)劃，比如知識(shí)可視化和維護(hù)性¹⁵ 。

　　指導(dǎo)模型編制了重復(fù)出現(xiàn)的問題和選項(xiàng)，通過這種方式來推進(jìn)架構(gòu)知識(shí)的重復(fù)使用，自此，SOAD使得架構(gòu)師能夠在某個(gè)問題的求解上下文中分享最佳實(shí)踐。我們可能從錯(cuò)誤中能夠得到最好的學(xué)習(xí)，誰規(guī)定了所有的錯(cuò)誤都必須要自己犯過才行呢？

　　關(guān)于作者

　　Olaf Zimmermann是IBM蘇黎世研究院的一名研究專員。他的研究興趣關(guān)注于應(yīng)用和集成架構(gòu)、SOA設(shè)計(jì)、架構(gòu)決策以及各種服務(wù)和知識(shí)管理的框架。Zimmerman擁有斯圖加特大學(xué)計(jì)算機(jī)科學(xué)專業(yè)博士學(xué)位。他也是開源組織的杰出IT架構(gòu)師、IBM執(zhí)行IT架構(gòu)師并著有Web Services展望（Springer, 2003）一書。你可以通olz@zurich.ibm.com和他取得聯(lián)系。

　　參考文獻(xiàn)

　　1. L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, 2nd ed., Addison-Wesley, 2003.

　　2. N. Rozanski and E. Woods, Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, Addison- Wesley, 2005.

　　3. P. Eeles and P. Cripps, The Process of Soft- ware Architecting, Addison-Wesley, 2010.

　　4. M. Fowler, "Who Needs an Architect?" IEEE Software, vol. 20, no. 5, 2003, pp. 2-4.

　　5. G. Booch, internal conference presentation to IBM Academy of Technology, 27 Apr., 2009.

　　6. O. Zimmermann, "An Architectural Decision Modeling Framework for Service-Oriented Architecture Design," PhD thesis, Univ. of Stuttgart, 2009.

　　7. F. Buschmann, K. Henney, and D. Schmidt, Pattern-Oriented Software Architecture, Vol. 4 - A Pattern Language for Distributed Computing, Wiley, 2007.

　　8. IBM Unifi ed Method Framework, work product description (ARC 0513), IBM, 2009.

　　9. M. Ali Babar et al., eds., Software Architecture Knowledge Management: Theory and Practice, Springer, 2009.

　　10. O. Zimmermann et al., "Managing Architectural Decision Models with Dependency Relations, Integrity Constraints, and Production Rules," J. Systems and Software and Services, vol. 82, no. 8, 2009, pp. 1246-1267.

　　11. J. Tyree and A. Ackerman, "Architecture Decisions: Demystifying Architecture," IEEE Software, vol. 22, no. 2, 2005, pp. 19-27.

　　12. M. Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley, 2003.

　　13. G. Hohpe and B. Woolf, Enterprise Integration Patterns, Addison-Wesley, 2004.

　　14. U. Zdun, C. Hentrich, and S. Dustdar, "Modeling Process-Driven and Service-Oriented Architectures Using Patterns and Pattern Primitives," ACM Trans. Web, vol. 1, no. 3, 2007, article no. 3; doi.10.1145/1281480.1281484.

　　15. M. Nowak, C. Pautasso, and O. Zimmermann, "Architectural Decision Modeling with Reuse: Challenges and Opportunities," Proc. 2010 ICSE Workshop Sharing and Reusing Architectural Knowledge (SHARK 10), ACM Press, 2010, pp. 13-20.

　　本文最初出現(xiàn)IEEE軟件雜志（雙月刊）2011年第一期，64頁(yè)到69頁(yè)。IEEE軟件雜志致力于為那些緊跟快速技術(shù)變更的軟件從業(yè)者提供創(chuàng)新性思想、專家分析和各種真知灼見。

　　查看英文原文： Architectural Decisions as Reusable Design Assets