| 級別: 初級 Peter Eeles, 高級 IT 架構師, IBM
2006 年 4 月 15 日 本文來(lái)自于 Rational Edge：這篇關(guān)于軟件架構的較新規則的介紹，是一個(gè)關(guān)于“架構”的四篇系列文章的的第一篇。作者以定義規則的關(guān)鍵術(shù)語(yǔ)開(kāi)始，繼續探索設計出色的架構對于架構所部署的環(huán)境所起的作用。 我們毫不懷疑世界正變得越來(lái)越依靠軟件。軟件是諸如無(wú)處不在的手機，和復雜的空中控制系統的核心元素。事實(shí)上，如果沒(méi)有軟件，例如eBay 和 Amazon等我們理所當然認為是創(chuàng )新的企業(yè)將不可能存在。甚至那些金融業(yè)，零售業(yè)和公共部門(mén)等傳統行業(yè)也相當的依賴(lài)于軟件。在當今的時(shí)代，某種程度上，我們很難發(fā)現一個(gè)企業(yè)完全與軟件不相關(guān)。 高新企業(yè)為了生存，因此他們所依靠的軟件必須能提供其所需的功能；所需的高質(zhì)量；所承諾的可用性，和可接受的價(jià)格。 這篇文章的主題就是關(guān)于可以影響這些屬性的軟件架構。我所關(guān)注的是“強軟件系統”，在IEEE中定義如下： 一個(gè)軟件集成系統就是軟件對于設計，構建，配置和整個(gè)系統的發(fā)展具有深入影響的系統[來(lái)自 IEEE 1471，"架構的定義" 部分] 在本文中，“架構”與“軟件架構”是相同的含義。雖然這篇文章關(guān)注于軟件集成系統，但是應該注意，軟件集成系統仍然需要硬件來(lái)運行，并且諸如可靠性和性能等品質(zhì)是通過(guò)軟硬件的結合實(shí)現的。所以解決方案中的硬件部分不能被忽略。文中后面將更詳細的討論這部分內容。 定義的架構 我們對于“架構”的定義沒(méi)有缺陷。甚至存在支持定義集的網(wǎng)站。1 文中的定義來(lái)自IEEE標準 1472000，IEEE對強軟件系統的架構描述的推薦實(shí)踐，參見(jiàn)IEEE 1471。2 定義如下，其中重要部分用粗體字表示。 架構是在組件，彼此間和與環(huán)境間的關(guān)系，引導設計發(fā)展原則中體現的系統的基本結構。[IEEE 1471] 這些標準還定義了以下相關(guān)概念： 系統是為實(shí)現某個(gè)（些）特殊作用的組件的集合。專(zhuān)用系統包括個(gè)人應用，傳統概念上的系統，子系統，系統中的系統，產(chǎn)品線(xiàn)，產(chǎn)品系列，整個(gè)企業(yè)和其他利益集團。一個(gè)系統是為了實(shí)現一個(gè)或多個(gè)任務(wù)而存在。[IEEE 1471] 環(huán)境決定了開(kāi)發(fā)，操作，策略和其他影響系統的設置和條件。[IEEE 1471] 任務(wù)是指系統為了實(shí)現對對象設置的使用或操作。[IEEE 1471] 涉眾是對于系統有利益關(guān)系或關(guān)注的個(gè)人，團隊或組織。[IEEE 1471] 正如我們所見(jiàn)，“組件”貫穿于這些定義。正如有意留下一個(gè)模糊的概念來(lái)解釋?zhuān)蟛糠旨軜嫸x沒(méi)有提到“組件”，IEEE 1471也不例外。組件也許是邏輯上的或物理存在的，技術(shù)上獨立的或特定的，規模大的或規模小的。由于文章的原因，我使用了UML 2.0規范的組件定義；并且我相當寬松的使用這個(gè)概念來(lái)包含各種所遇到的架構成分，包括了對象，技術(shù)組件（例如Enterprise JavaBean），服務(wù)，程序模塊，遺留系統，包應用程序等。這些是 UML 2.0中對“組件”的定義： [組件]是包括內容的系統模型部分，且它的顯示是可替換的。組件定義了所需接口的行為。例如，組件類(lèi)似類(lèi)型(type)，它與所需接口行為一致。（包括靜態(tài)和動(dòng)態(tài)語(yǔ)義）3 這里的定義包括了多種不同的概念，文中后面將有更詳細的介紹。雖然工業(yè)界對于“架構”的概念沒(méi)有普遍的共識，但是有必要考慮一些其他的定義使得他們可以被遵照。參照一下下面的定義，重點(diǎn)處我已經(jīng)用粗體表示。 架構是對軟件系統組織，結構部分和系統包含接口的選擇，集合部分的特定行為，較大子系統部分的構成和架構風(fēng)格的重大決定的設置。[Kruchten]4 系統或計算系統的軟件架構是包含軟件部分，外部可見(jiàn)特性部分，和他們之間的關(guān)系的系統的結構。[Bass et al.]5 [架構]是系統的組織結構和相關(guān)行為。架構可被重復分解為通過(guò)接口，互聯(lián)部分的關(guān)系和結合部相互作用的部分。通過(guò)接口相互作用的部分包括類(lèi)，組件和子系統。[UML 1.5]6 軟件架構或系統由組成系統的結構的相互作用和軟件結構的重要設計決定組成。設計決定應成功實(shí)現所期望支持的質(zhì)量。設計決定為系統開(kāi)發(fā)，支持和維護提供概念上的基礎。 [McGovern]7 雖然在某些方面定義有些區別，但我們可以看到大部分是相同的。例如，大部分定義都指出一個(gè)架構關(guān)注于結構和行為，僅關(guān)注于重要決定，可以與架構風(fēng)格一致，受涉眾和環(huán)境的影響，體現基于原因的決定。所有這些方面，都在下面提到。 一個(gè)架構定義結構 如果你要求人們?yōu)槟忝枋觥凹軜嫛?，十分之九的人都?huì )參照結構來(lái)解釋。這在關(guān)于構建或其他土木工程結構（例如橋梁）中非常常見(jiàn)。雖然這些條目中的其他屬性（例如行為，目的適當性和美學(xué)觀(guān)念）也存在，但是結構的屬性是最熟悉的和最經(jīng)常被提到的。 我們對你會(huì )讓某人來(lái)描述一下他所工作的軟件系統架構一點(diǎn)也不會(huì )感到奇怪，他們將會(huì )給你展示一份系統結構方面的圖表——無(wú)論這些內容是否是架構層，組件，或是分布結點(diǎn)。事實(shí)上，結構是架構的基礎屬性。架構會(huì )以各種形式展示他們自己，且大部分架構的定義是非常模糊的。一個(gè)結構組件可能是一個(gè)子系統，進(jìn)程，庫，數據庫，計算結點(diǎn)，饋贈系統，按需產(chǎn)品等等。 許多架構的定義不但承認了他們自己的結構元素，而且還有結構元素的組成，關(guān)系（任何連接部分都需支持這樣的關(guān)系），接口。這些部件都以不同方式被提供。例如，連接段可以是套接字，同步的或異步的，與某個(gè)協(xié)議相關(guān)等。 圖1提供了結構元素的例子。這幅圖顯示了包含展示順序進(jìn)程系統的結構部分的UML類(lèi)圖。我們看到有三個(gè)類(lèi)——OrderEntry，CustomerManagement，和AccountManagement。OrderEntry類(lèi)與CustomerManagement和AccountManagement類(lèi)相連。 圖1：UML類(lèi)圖顯示了結構元素 一個(gè)架構定義行為 與定義結構元素一樣，架構定義了這些結構元素的相互作用。這些作用可以實(shí)現所期望的系統行為。圖2展示了允許系統支持在順序進(jìn)程系統中的次序定義的UML順序圖。在這里我們能看到五個(gè)交互作用。第一，Sales Clerk使用OrderEntry類(lèi)創(chuàng )建了一個(gè)順序。OrderEntry使得客戶(hù)得到使用CustomerManagement類(lèi)的細節。然后OrderEntry使用 AccountManagement類(lèi)創(chuàng )建一個(gè)次序，用次序條目構建順序。 圖2：UML是序列圖顯示了行為元素 圖2與圖1相連，因為我們能從圖2中的關(guān)于交互作用的定義得到圖1中的相關(guān)內容。例如，OrderEntry事例在被執行中要依靠CustomerManagement事例，正如在圖2中所示的一樣。這種依賴(lài)就如OrderEntry和CustomerManagement間通信所反映的依賴(lài)關(guān)系一樣。 一個(gè)架構關(guān)注于重要元素 當一個(gè)架構定義了結構和行為，它不會(huì )在意所有的結構和行為的定義。它只在意那些被認為是重要的元素。重要的元素是那些有持久影響的，例如結構部分的主要部分，與核心行為相關(guān)的元素，和對諸如可靠性和可測量性等重要品質(zhì)相關(guān)的元素?？偟膩?lái)說(shuō)，架構不關(guān)心這些元素的細節。架構的重要性還可以以經(jīng)濟的重要性來(lái)表達，因為某些元素的主要驅動(dòng)者是創(chuàng )建的成本和變更的成本。 由于架構僅關(guān)注于重要元素，它給我們提供了在考慮中的系統的一個(gè)特殊透視圖——與架構最相關(guān)的透視圖。8在這種含義下，一個(gè)架構是一個(gè)系統的抽象，可以幫助架構師管理復雜性。 我們僅僅應注意重要元素的設置不是靜態(tài)的。作為一個(gè)需要被提煉，確定風(fēng)險，可執行的軟件構建和經(jīng)驗總結的結果，重要元素的設置可能會(huì )改變。但是，面對改變的架構的穩定性是好的架構，好的可執行架構進(jìn)程，好的架構師的標志。如果架構需要根據變化不斷作出調整，那么這不是一個(gè)好的標志。但是，如果架構相對穩定，那么相反的也對。 一個(gè)架構可以平衡涉眾需求 架構是為了實(shí)現涉眾的需要而創(chuàng )造的。但是，一般來(lái)說(shuō)不可能滿(mǎn)足所有的需求。例如，涉眾可能會(huì )問(wèn)特定的時(shí)間框的功能，但是這兩方面（功能和時(shí)間框）是互斥的?；蛘邽榱藵M(mǎn)足時(shí)間表而減少范圍或者所有的功能可以擴展時(shí)間框實(shí)現。類(lèi)似的，不同的涉眾之間可能有相互沖突的需求，所以應滿(mǎn)足適當的平衡性。所以作折中是構建進(jìn)程的主要方面，且妥協(xié)是架構的重要屬性。 僅僅提供一個(gè)任務(wù)的例子，考慮如下涉眾群各自的所需： - 最終用戶(hù)關(guān)心直覺(jué)，正確的行為，性能，可靠性，可用性，有效性和安全性。
- 系統管理員關(guān)注直覺(jué)行為，管理和輔助監測。
- 業(yè)務(wù)人員關(guān)注有競爭力的特性，市場(chǎng)的時(shí)效性，對于其他產(chǎn)品的定位和開(kāi)銷(xiāo)。
- 客戶(hù)關(guān)注開(kāi)銷(xiāo)，穩定性和計劃性。
- 開(kāi)發(fā)者關(guān)注清晰的需求和簡(jiǎn)單而一致的設計方法。
- 項目經(jīng)理關(guān)注追蹤項目，計劃，資源的生產(chǎn)使用和預算的可預見(jiàn)性。
- 維護人員關(guān)注易理解性，一致性，和文檔化的設計方法，與易修改性。
正如表中可看到的，對于架構師的另一個(gè)挑戰是涉眾群不僅僅關(guān)注系統所提供的需求功能。他們所關(guān)注的在實(shí)際中是不起作用的，因為在系統中他們不發(fā)生作用。（例如，關(guān)于成本和計劃的關(guān)注）但是這些關(guān)注體現了系統質(zhì)量或局限。非功能需求經(jīng)常是架構師所關(guān)注的最重要的需求。 一個(gè)架構基于基本原理體現決策 一個(gè)架構的重要部分不僅僅是最終結果，架構本身，而是他為什么是如此的原因。因此，確信你已把使用這個(gè)架構和原因文檔化就非常重要了。 這個(gè)信息與許多涉眾都有關(guān)系，尤其是那些維護系統的人。這些信息對需要參考設計理由的架構師來(lái)說(shuō)非常有價(jià)值，因為他們可以省去不必要的步驟。例如，當需要重復架構和架構師重新審視所做的決定時(shí)，這些信息非常有用。 一個(gè)架構可以符合一個(gè)架構樣式 大部分的架構來(lái)源于有相似關(guān)注的共享系統。這些相似性可被描述成某種特殊模式的架構風(fēng)格，雖然經(jīng)常是復雜和組合模式（由許多模式共同作用）。一種架構風(fēng)格展示一個(gè)經(jīng)驗法典，并且有利于架構師重復使用類(lèi)似經(jīng)驗。架構風(fēng)格的例子包括分布式的風(fēng)格，管道和過(guò)濾器風(fēng)格，數據中心風(fēng)格，基于規則的風(fēng)格等。一個(gè)系統可以包含多于一個(gè)架構風(fēng)格。Shaw和Garlan的描述如下： [架構風(fēng)格] 按照結構組織的模式定義了系統。更具體的，架構風(fēng)格定義了組件和連接型的語(yǔ)法，和連接的方法。9 在 UML 中的定義: [模式] 是對于普遍問(wèn)題的普遍解決方案。10 除了重復經(jīng)驗，由于一種風(fēng)格以文檔的形式保存了使用它的理由和它的結構與行為，所以架構風(fēng)格的應用使類(lèi)似架構師的工作變得容易起來(lái)。 一個(gè)架構被其環(huán)境所影響 系統貯存于環(huán)境中，且環(huán)境影響架構。這就是有時(shí)所提到的“環(huán)境中的架構”?；旧?，環(huán)境決定了系統運行的范圍，這些又決定了架構。影響架構的環(huán)境的因素包含架構所支持的商務(wù)環(huán)境，系統涉眾群，內部技術(shù)限制（例如需要符合組織標準），和外部技術(shù)限制（例如對外部系統的接口或遵守外部規則的標準）。 相反的，如在Bass, Clements, 和Kazman所描述的，11架構可能還影響它的環(huán)境。不但是從技術(shù)前景的架構創(chuàng )新改變了環(huán)境--例如它可能對擁有組織的可重復使用價(jià)值有貢獻——架構的創(chuàng )新可能在技術(shù)方面改變環(huán)境。 當提到軟件集成系統，有一個(gè)必須被提到的關(guān)于環(huán)境的特殊部分。為了軟件的有用性，它必須執行。為了執行，軟件運行在硬件之上。所以最終系統是軟硬件的結合，與諸如可靠性和性能等完美結合的實(shí)現。軟件不能在單獨的硬件條件下實(shí)現這些功能。 IEEE 標準 12207-1995，IEEE 信息技術(shù)標準 －－ 軟件生命周期過(guò)程，定義了與之前IEEE1471不同的系統（關(guān)注于軟件集成系統），但與在系統工程方面定義的相同： [系統]是包含了一個(gè)或多個(gè)進(jìn)程，硬件，軟件，工具與可以滿(mǎn)足需求的人的集合。 [IEEE 12207]12 Systems Engineering (RUP SE)的Rational Unified Process配置包含一個(gè)類(lèi)似的定義。 [系統]是提供為企業(yè)執行商業(yè)目的或任務(wù)的服務(wù)資源。系統組件包括硬件，軟件，數據和工作人員13。 在系統工程方面，根據軟件，硬件和人的使用定義事務(wù)。例如，如果性能為重，那么可能決定某一個(gè)系統元素的硬件實(shí)現，而不是軟件或人。另一個(gè)例子是為了給客戶(hù)提供可用系統，所以要給客戶(hù)提供接口。更復雜的情況需要通過(guò)軟硬件和人的結合實(shí)現系統功能。 我們非常有趣的注意到系統工程特別關(guān)注于對待軟件和硬件，因此避免把硬件和軟件相比作為第二級，或是執行軟件的載體，或是反過(guò)來(lái)。 一個(gè)架構影響團隊結構 架構定義了一組連貫的相關(guān)元素。例如，順序進(jìn)程系統架構可能已定義了一組次序入口，計數管理，客戶(hù)管理，實(shí)現，外部系統集成，持續性和安全性。 每一組都會(huì )要求不同的技術(shù)。因此，一旦被定義好，統一軟件開(kāi)發(fā)小組結構就非常有意義了。但是，情況經(jīng)常是最初的小組結構影響了構架，而不是相反情況。因為結果通常都是一個(gè)不太理想的架構?！翱低幝伞?規定“如果你有4個(gè)編譯小組，那你會(huì )有4路編譯器”。 實(shí)際上，我們經(jīng)常會(huì )無(wú)意識地創(chuàng )建架構，以反映創(chuàng )建架構的組織。 但是，完全從實(shí)際出發(fā)，事實(shí)上這種有點(diǎn)理想的觀(guān)點(diǎn)經(jīng)常是不實(shí)際的，因為當前小組結構和技術(shù)都有實(shí)際可能的限制，并且架構師必須考慮在內。 一個(gè)架構呈現在每一個(gè)系統中 每個(gè)系統都有一個(gè)架構，即使這個(gè)架構沒(méi)有被文檔化，或者如果系統非常簡(jiǎn)單且包含單一元素。對架構文檔化很有價(jià)值。文檔化的架構比沒(méi)有的考慮的更周全——因此也更有效，所以根據架構的進(jìn)程可以更細致的考慮。 相反地，如果架構沒(méi)有文檔化，那么很困難來(lái)證明滿(mǎn)足了諸如可維護性，最佳適應性等的需求。似乎大部分現今存在的無(wú)文檔的架構都有些隨意性而不是目的性。 一個(gè)架構擁有一個(gè)特定的范圍 有許許多多種架構，最著(zhù)名的是與建筑和其他工程相關(guān)的。甚至在軟件工程領(lǐng)域，我們經(jīng)常會(huì )遇到不同形式的架構。例如，除了軟件構架的概念，我們會(huì )遇到諸如企業(yè)架構，系統架構，組織架構，信息架構，硬件架構，應用架構，基礎設施架構等。你會(huì )見(jiàn)到其他類(lèi)型的，每種類(lèi)型都定義了一個(gè)架構的具體范圍。 不幸的是，產(chǎn)業(yè)界沒(méi)有相互形式間的協(xié)定，所以導致了對同一形式的不同意思。但是，從圖3中可以推斷出這些形式的范圍。當你們在考慮和討論下面這張圖的時(shí)候，你肯定會(huì )發(fā)現很多你不同意的元素或是在你們的組織中不同的使用方法。但是重要的是——這些形式的確存在，卻沒(méi)有一致的觀(guān)點(diǎn)。 圖3：不同領(lǐng)域的范圍 圖3展示的元素有： - 軟件架構——這篇文章主要的關(guān)注點(diǎn)。
- 硬件架構——包括CPU, 內存，硬盤(pán)，周邊設備例如打印機，與連接這些元素的部分。
- 組織架構——是一些關(guān)于商業(yè)進(jìn)程，組織結構，規則和職責，與組織核心能力的部分。
- 信息架構——包含組織好的信息結構。
- 軟件架構，硬件架構，組織架構和信息架構是全部系統架構的子結構。
- 企業(yè)架構，與系統架構很相似，包括硬件，軟件，人員等。但是，企業(yè)架構與商業(yè)有很強的聯(lián)系，因為它專(zhuān)注于商業(yè)對象的聯(lián)系，專(zhuān)注于商業(yè)敏捷性和組織效率。企業(yè)架構可能穿插于公司間。
正像人們期盼的那樣，有相應形式的架構師（例如軟硬件架構師等）和架構（例如，軟硬件架構等）。 現在我們已瀏覽過(guò)這些定義了，但還有很多未回答的問(wèn)題。企業(yè)架構與系統架構間有什么不同？一個(gè)企業(yè)是一個(gè)系統？信息架構與數據集成軟件應用中的數據架構是一樣的？不幸的是，沒(méi)有對這些問(wèn)題的一致的答案。 對現在來(lái)說(shuō)，你會(huì )意識到這些不同，但是產(chǎn)業(yè)界不存在對這些內容的一致定義。因此，對你的建議只是選擇那些與你的組成相似的形式并且合適的定義他們。至少你會(huì )獲得某些一致性，并減少錯誤傳達的可能。 總結 這篇文章關(guān)注于定義軟件架構的核心特性。但是，仍然有很多未被解答的問(wèn)題。什么是軟件架構師的角色？架構師最重要的活動(dòng)是什么？從“建立架構”中能得到什么好處？這些問(wèn)題將在后續文章中被解答。 感謝 這篇文章的內容來(lái)源于一本即將出版的新書(shū)，暫時(shí)叫做“軟件架構建立過(guò)程”。最后，我衷心的感謝對內容提出寶貴意見(jiàn)的人們，他們是Grady Booch，Dave Braines，Alan Brown，Mark Dickson，Holger Heuss，Kelli Houston，Luan Doan-Minh，Philippe Kruchten，Nick Rozanski，Dave Williams，和Eoin Woods。 注釋 1 軟件工程研究所（SEI）架構Web站點(diǎn) －－ 架構定義，提供了一個(gè)好的例子。參見(jiàn) http://www.sei.cmu.edu/architecture/definitions.html 2 IEEE Computer Society，強軟件系統的架構描述的IEEE推薦實(shí)踐：IEEE 標準 1472000，2000。 3 對象管理組織，UML 2.0 結構規格說(shuō)明：文檔號 03-09-15。2003年九月。 4 Philippe Kruchten，Rational統一過(guò)程：介紹，第三版。Addison-Wesley Professional 2003。 5 Len Bass，Paul Clements 和 Rick Kazman，軟件架構實(shí)踐，第二版。Addison Wesley 2003。 6 對象管理組織，OMG 統一建模語(yǔ)言規格 1.5版，文檔號 03-03-01。2003年三月。 7 James McGovern等，企業(yè)架構的實(shí)踐指南。Prentice Hall 2004 8 一個(gè)在本系列的后續文章中所涵蓋的角色。 9 Mary Shaw 和 David Garlan，軟件架構 -- 關(guān)于一個(gè)正在形成的學(xué)科的觀(guān)察。 Prentice Hall 1996， 10 Grady Booch，James Rumbaugh 和 Ivar Jacobson，統一建模語(yǔ)言用戶(hù)指南。Addison Wesley 1999。 11 Bass 等，前面引用的書(shū)。 12 IEEE Computer Society，IEEE 信息技術(shù)標準 －－軟件生命周期過(guò)程。IEEE 標準 12207-1995。 13 Murray Cantor，“系統工程的Rational統一過(guò)程”。The Rational Edge，2003年八月。 http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/aug03/f_rupse_mc.pdf | 
