自定義軟件工程公司揭開偉大架構(gòu)師的秘密

1、 通行證：登錄注冊 程序員|第二書店|博文視點(diǎn)· 首頁 · 新聞社區(qū)Blog技術(shù)中心 · .NetJAVA移動(dòng)游戲管理 · 人才培訓(xùn) 被屏蔽廣告  被屏蔽廣告  被屏蔽廣告    CSDN 2006 年編輯招聘火熱進(jìn)行中 虛位以待 期待你的加盟! · 首頁 · 新聞 · 最新Blog · 最佳實(shí)踐 · 外刊外網(wǎng) · 產(chǎn)品&評測 自定義軟件工程公司揭開偉大架構(gòu)師的秘密2006.06.16    被屏蔽

2、廣告 被屏蔽廣告?zhèn)ゴ蠹軜?gòu)師的秘密By Don Awalt and Rick McUmberRDA Corporation摘要：所有偉大的架構(gòu)師都掌握了在抽象的不同層次上概念化解決方案的技能。通過將解決方案組織到離散的層次，架構(gòu)師可以專注于解決方案的單個(gè)方面而忽略所有剩余的復(fù)雜性。展示將抽象層次應(yīng)用到 IT 解決方案的技術(shù)，并將其與其他工程學(xué)科相比較。 本文內(nèi)容 將抽象層次應(yīng)用到 IT 解決方案 抽象層次：所有工程師的強(qiáng)大武器 應(yīng)用抽象層次時(shí)的核心原則 將抽象層次應(yīng)用到 IT 系統(tǒng) 簡單框架：四個(gè)抽象層次 通過迭代發(fā)展層次 重訪抽象層次核心原則 擴(kuò)展層次以支持企業(yè)解決方案 優(yōu)點(diǎn) 小結(jié) 自我評估

3、將抽象層次應(yīng)用到 IT 解決方案企業(yè)架構(gòu)師正受到其所面臨的大量復(fù)雜性的挑戰(zhàn)。開發(fā)一個(gè)能夠自動(dòng)處理企業(yè)任務(wù)的獨(dú)立的部門應(yīng)用程序是一回事。而設(shè)計(jì)并組成一個(gè)支持上萬 IT 使用者的滿是應(yīng)用程序、服務(wù)器和數(shù)據(jù)庫（全都支持多種企業(yè)活動(dòng)）的 IT 實(shí)驗(yàn)室全球網(wǎng)絡(luò)，則完全是另外一回事。要組合這些復(fù)雜性，IT 網(wǎng)絡(luò)必須隨時(shí)可用、響應(yīng)迅速并保護(hù)企業(yè)寶貴的信息資產(chǎn)。除所有這些之外，IT 網(wǎng)絡(luò)還必須足夠靈活以支持企業(yè)永遠(yuǎn)變化的需要，并且采用出現(xiàn)的新技術(shù)。一些架構(gòu)師在這種復(fù)雜性方面明顯非常出色，而且在不斷進(jìn)步。在我們的職業(yè)生涯中，能與一些真正偉大的分析師和架構(gòu)師并肩工作是非常幸運(yùn)的。反思這些經(jīng)驗(yàn)，我們已經(jīng)分析出是什么

4、造就了杰出的架構(gòu)師。 無一例外，所有偉大的架構(gòu)師都掌握了在截然不同的抽象層次上概念化解決方案的技能。通過將解決方案組織到離散的層次，架構(gòu)師可以將精力集中在解決方案的單個(gè)方面而忽略所有剩余的復(fù)雜性。他們一旦穩(wěn)定了解決方案的某個(gè)部分，接下來就能繼續(xù)處理其他方面，從而不斷地將層次發(fā)展并完善到最終可以被實(shí)現(xiàn)的粘合模型中。大多數(shù)軟件開發(fā)人員懂得應(yīng)該將解決方案分解到抽象層次。但是在實(shí)際的項(xiàng)目中，這是非常難于付諸實(shí)踐的。當(dāng)遇到第一個(gè)困難時(shí)，在急于開始編碼時(shí)是很容易放棄這些層次的。偉大的架構(gòu)師會(huì)經(jīng)受這些挑戰(zhàn)并在整個(gè)項(xiàng)目的生命周期中嚴(yán)格保持這些層次。他們意識(shí)到，如果不這樣做，最終將淹沒在復(fù)雜性中。本文展示了將抽

5、象層次應(yīng)用到 IT 解決方案的技術(shù)。首先，我們會(huì)通過一個(gè)簡單的示例演示此方法，然后提出一個(gè)基于正式抽象層次的系統(tǒng)產(chǎn)品的結(jié)構(gòu)。 抽象層次：所有工程師的強(qiáng)大武器其他的工程學(xué)科，比如土木工程師，幾個(gè)世紀(jì)以來一直利用抽象層次復(fù)制復(fù)雜性。讓我們學(xué)習(xí)一下其他更成熟的工程學(xué)科是如何應(yīng)用抽象層次的，就從電子工程師開始吧，他們設(shè)計(jì)每次更新?lián)Q代都變得更加復(fù)雜的計(jì)算機(jī)系統(tǒng)。 硬件工程師系統(tǒng)設(shè)計(jì)師使用抽象層次為計(jì)算機(jī)系統(tǒng)建模。每個(gè)層次都是定義完善的，并提供了該系統(tǒng)的一個(gè)不同角度。許多系統(tǒng)是在三個(gè)主要層次上設(shè)計(jì)的：系統(tǒng)、子系統(tǒng)和組件，如圖 1 所示。分層使工程師能夠?qū)嫶髷?shù)量的復(fù)雜性集成到一個(gè)單一的工作計(jì)算機(jī)系統(tǒng)中。在

6、其原子部分的層次上確切了解一臺(tái)計(jì)算機(jī)是不可能的。在單獨(dú)一塊 Intel Itanium_ 芯片上有大約 25,000,000 個(gè)晶體管。 對 IT 相關(guān)學(xué)科來說，這種把復(fù)雜性分解到抽象層的方法當(dāng)然不是惟一的。類似的方法被用于從航空工程到微生物學(xué)的無數(shù)其他學(xué)科。應(yīng)用抽象層次時(shí)的核心原則所有工程師在應(yīng)用抽象層次時(shí)都遵循這套核心原則。當(dāng)把抽象層次應(yīng)用到軟件時(shí)，這些原則也同樣適用。這些層次的數(shù)量和范圍是定義完善的，以便工程師能夠在復(fù)雜的系統(tǒng)上協(xié)作，所有團(tuán)隊(duì)成員必須共享對層次的同一理解。只要設(shè)計(jì)師做出設(shè)計(jì)決定，他們必須將那些決定歸檔到相應(yīng)的細(xì)節(jié)層次。 三個(gè)抽象層次定義如下： 圖 i. 定義的三

7、個(gè)抽象層次 圖 ii.抽象層次的一個(gè)簡單框架每個(gè)層次內(nèi)的多個(gè)視圖一個(gè)單個(gè)層次內(nèi)的復(fù)雜性可以變得非常多，以至于使人無法一次全部掌握。在這種情況下，工程師通過多個(gè)視圖將設(shè)計(jì)展現(xiàn)于單個(gè)層次內(nèi)。每個(gè)視圖展現(xiàn)設(shè)計(jì)的一個(gè)單獨(dú)方面，但保持在相同的抽象層次上。舉例來說，母板工程師為板的每個(gè)層創(chuàng)建一個(gè)視圖，從而為每層的連接路徑的設(shè)計(jì)建模。  圖 1. 計(jì)算機(jī)系統(tǒng)的抽象層次必須保持層次間的一致性為了讓系統(tǒng)按預(yù)期方式運(yùn)行，每個(gè)后續(xù)的層必須是其父層的適當(dāng)改進(jìn)。如果計(jì)算機(jī)系統(tǒng)設(shè)計(jì)師從 IDE 總線切換到 SCSI 總線，那么所有設(shè)備的接口規(guī)范也必須切換到 SCSI。如果層次沒有同步，那么系統(tǒng)就不會(huì)按

8、預(yù)期方式在頂層執(zhí)行。將抽象層次應(yīng)用到 IT 系統(tǒng)既然我們已經(jīng)分析了其他學(xué)科是如何應(yīng)用抽象層次的，現(xiàn)在就讓我們將此技術(shù)應(yīng)用于 IT 解決方案1。下列部分展示了應(yīng)用抽象層次為典型 IT 應(yīng)用程序的需求、設(shè)計(jì)和實(shí)現(xiàn)建模的技術(shù)。這些技術(shù)是通過一個(gè)針對假想零售商的簡單的、指導(dǎo)性的在線定單系統(tǒng)示例來展示的。在我們的示例中，我們不僅包括了體系結(jié)構(gòu)，而且擴(kuò)展了范圍以包括系統(tǒng)需求和業(yè)務(wù)環(huán)境 如同由零售業(yè)所定義的。簡單框架：四個(gè)抽象層次我們的簡單示例定義 IT 解決方案的如下四個(gè)抽象層次： 域 業(yè)務(wù)處理 邏輯 物理 在每個(gè)層次內(nèi)，我們既展示了該特定層次行為的動(dòng)態(tài)視圖，又展示了其靜態(tài)視圖。動(dòng)態(tài)視圖為對象之間的消息建

9、模，而靜態(tài)視圖為對象之間的結(jié)構(gòu)和關(guān)系建模。 域抽象層次應(yīng)用了上面的范圍規(guī)則，零售商就會(huì)作為域?qū)哟沃械暮诤凶又行牡难輪T?？蛻糇鳛橥獠康难輪T。域?qū)哟问菑目蛻舻慕嵌葋斫５?。只為購買交互建模。用于完成購買的通訊形式不包括在這個(gè)層次，但是會(huì)在業(yè)務(wù)處理層次引入。圖 2. 關(guān)于從零售商處購買物品的域?qū)哟蝿?dòng)態(tài)視圖 圖 3. 關(guān)于從零售商處購買物品的域?qū)哟戊o態(tài)視圖動(dòng)態(tài)視圖域?qū)哟蝺?nèi)的動(dòng)態(tài)視圖為客戶和零售商之間的交互建模。下圖匯總了域環(huán)境，并包含了簡單的業(yè)務(wù)交互使用案例描述。圖 4. 關(guān)于從零售商處購買物品的業(yè)務(wù)處理層次動(dòng)態(tài)視圖靜態(tài)視圖域?qū)哟蔚撵o態(tài)視圖為類結(jié)構(gòu)和在使用案例中出現(xiàn)的它們的對象的關(guān)系建模。換

10、句話說，它說明了在這個(gè)抽象層次上，為了完成購買交易客戶需要了解什么對象。 圖 5 展示了域?qū)哟戊o態(tài)視圖的類關(guān)系圖。圖 5. 關(guān)于從零售商處購買物品的業(yè)務(wù)處理層次靜態(tài)視圖客戶是 Person 的實(shí)例。客戶和零售商之間的關(guān)系被具體化為 Account。所有的 Purchase 都與客戶的 Account 相關(guān)。Purchase 與每個(gè)被購買的 Item 相關(guān)。每個(gè) Item 都與特定的 Product 相關(guān)，這里 Product 遵循元類模式。Product 的實(shí)例實(shí)際上本身就是類。將其他 Product 添加到 Catalog 完全是一個(gè)數(shù)據(jù)驅(qū)動(dòng)過程，而且不會(huì)對類模型產(chǎn)生影響，因此將 Produ

11、ct 建模為一個(gè)元類會(huì)使我們的模型更加靈活。圍繞這些類，每個(gè) Payment 都與其 Purchase 相關(guān)。如您可能看到的，這個(gè)層次的模型對大多數(shù)零售商（無論類型為在線或傳統(tǒng)，大型或小型）來說是有代表性的。這說明了為什么 Industry 域模型確實(shí)應(yīng)該將公司定義為黑盒子中心的演員。同一個(gè)行業(yè)中的公司傾向于支持帶有其外部演員的同一套業(yè)務(wù)交互。此外，域模型排除了公司的特定業(yè)務(wù)處理，這是因?yàn)樵谕恍袠I(yè)中的公司之間它們會(huì)有相當(dāng)大的變化。 域?qū)哟螄?yán)格集中在從外部演員的角度看到的業(yè)務(wù)交互。對此我們必須注意，不要將用于完成交互的實(shí)現(xiàn)機(jī)制包括進(jìn)來。這些細(xì)節(jié)屬于下一個(gè)抽象層次。因此，在本例中，我們只為瀏覽、

12、選擇、購買和支付建模。我們不為如何完成這些交互（通過電話、美國郵政、電子郵件、Web 應(yīng)用程序、親自前往、支票、信用卡或現(xiàn)金）建模。業(yè)務(wù)處理抽象層次 下一個(gè)抽象層次為公司的業(yè)務(wù)處理建模，以實(shí)現(xiàn)在域?qū)哟尾东@的交互。系統(tǒng)層次"內(nèi)部縮放"公司的黑盒子，并標(biāo)識(shí)為完成業(yè)務(wù)交易而協(xié)作的所有員工和系統(tǒng)。在這個(gè)層次，要開發(fā)的系統(tǒng)作為黑盒子中心的演員。 應(yīng)用了系統(tǒng)層次的范圍規(guī)則，在線定單系統(tǒng)就作為黑盒子中心的演員。客戶和員工作為外部演員。系統(tǒng)層次是從客戶和員工的角度來建模的。客戶在線執(zhí)行購買。支付是通過信用卡完成的。通過將物品運(yùn)送到客戶的收貨地址履行定單。出貨通知是由電子郵件發(fā)送的。 動(dòng)態(tài)視

13、圖動(dòng)態(tài)視圖重演了域?qū)哟钨徺I交易，這次公開了零售商的內(nèi)部業(yè)務(wù)處理。圖 4 匯總了業(yè)務(wù)處理環(huán)境，并包含了關(guān)于系統(tǒng)及其演員之間的交互的簡單使用案例描述。靜態(tài)視圖這個(gè)層次的靜態(tài)視圖對類模型做了改進(jìn)，以捕獲在業(yè)務(wù)處理層次使用案例中出現(xiàn)的對象。換句話說，"為了在線創(chuàng)建一個(gè)定單并履行該定單，客戶和雇員需要理解哪些對象？"圖 5 展示了業(yè)務(wù)處理層次靜態(tài)視圖的類關(guān)系圖。我們修改域類模型以捕獲在這個(gè)抽象層次上的角度。Person、Account 和 Company 抽象保持不變，Catalog 和 Product 也一樣。但是，用 Order 替換了來自域模型的抽象 Purchase 事件。O

14、rder 包括 LineItem，它與 Catalog 中的 Product 相關(guān)聯(lián)。因?yàn)檫@個(gè)層次為公司的內(nèi)部業(yè)務(wù)處理建模，所以我們需要獲得現(xiàn)有的庫存（最小庫存單元 (SKU) 的一個(gè)屬性，它表示在一個(gè)特定位置的物品的庫存）。我們也為客戶的 UserAccount 建模，它提供對在線系統(tǒng)的訪問。Payment 是通過使用 CreditCardAccount 來完成的。Location 代表美國的一個(gè)地理位置，它作為賬單郵寄地址，同時(shí)也作為 Order 的收貨地址。Shipment 包含 Shipment 中包括的 Item。 我們在系統(tǒng)抽象層次創(chuàng)造方法來簡化業(yè)務(wù)處理，因此該層次通常需要很多創(chuàng)造

15、力。為此，通常使用業(yè)務(wù)處理層次上的若干不同形式來實(shí)現(xiàn)單個(gè)域?qū)哟谓灰?。舉例來說，一次購買可以通過在線、電話、郵件、傳真一個(gè)定單表格或者親自到零售店來完成。對于每一種形式，都需要在業(yè)務(wù)處理層次為其建模。請注意，盡管對零售商來說 Credit Authorizer 是一個(gè)外部演員，但是它還是在這個(gè)層次引入，這是因?yàn)橹恍枰鼘?shí)現(xiàn)在該層次首次出現(xiàn)的業(yè)務(wù)處理。 最后，請注意該系統(tǒng)是技術(shù)獨(dú)立的。我們的在線購買系統(tǒng)可以用任何 Web 技術(shù)實(shí)現(xiàn)。在系統(tǒng)黑盒子內(nèi)選擇技術(shù)是一個(gè)體系結(jié)構(gòu)決策。 邏輯抽象層次邏輯層在系統(tǒng)黑盒子內(nèi)縮放，從而公開高級別的系統(tǒng)設(shè)計(jì)。架構(gòu)師選擇技術(shù)并定義高級系統(tǒng)結(jié)構(gòu)。在我們的簡單示例中，系統(tǒng)是

16、由承載表示層、業(yè)務(wù)層和數(shù)據(jù)訪問層的 Microsoft IIS/Microsoft ASP.NET 服務(wù)器和承載持久性數(shù)據(jù)的 Microsoft SQL Server 數(shù)據(jù)庫服務(wù)器組成的。動(dòng)態(tài)視圖邏輯層上的動(dòng)態(tài)視圖跟蹤通過系統(tǒng)主要組件的消息流。如示例所示，在提交 ConfirmOrder Web 表單的時(shí)候，圖 6 跟蹤這一消息流。圖 6. 從零售商處在線購買物品的邏輯層次動(dòng)態(tài)視圖靜態(tài)視圖這個(gè)層次的靜態(tài)視圖也將我們的視角切換到系統(tǒng)內(nèi)部。盡管業(yè)務(wù)處理層次為出現(xiàn)在業(yè)務(wù)處理中的真實(shí)抽象建立了模型，這個(gè)層次將抽象建模為其在系統(tǒng)中所要被表示的那樣。在實(shí)際的系統(tǒng)中，架構(gòu)師會(huì)為每個(gè)軟件層（表示層、業(yè)務(wù)層和數(shù)

17、據(jù)訪問層）設(shè)計(jì)類。為了保持本文的簡潔，圖 7 只展示了業(yè)務(wù)層的靜態(tài)設(shè)計(jì)，以便說明系統(tǒng)層抽象是如何針對設(shè)計(jì)進(jìn)行改進(jìn)的。  圖 7. 從零售商處在線購買物品的邏輯層次靜態(tài)視圖架構(gòu)師對系統(tǒng)層類進(jìn)行改進(jìn)以設(shè)計(jì)業(yè)務(wù)層接口。 因?yàn)橄到y(tǒng)中的所有賬戶和客戶都是零售商的，所以創(chuàng)建一個(gè)單一的 Company 實(shí)例并使其與所有賬戶相關(guān)聯(lián)是不切實(shí)際的，因此該層次中省略了 Company。我們只是存儲(chǔ) Payment 所帶的信用卡號(hào)和賬單郵寄地址，并非為每個(gè) CreditCardAccount 創(chuàng)建一個(gè)單獨(dú)的實(shí)例。此外，對系統(tǒng)來說，為每個(gè)出售的 Item 創(chuàng)建一個(gè)實(shí)例是不切實(shí)際的，因此從模型中刪除了 Item

18、，并改為由模型跟蹤 LineItem 中訂購的物品數(shù)量以及在新 ShippedItems 類中附帶的物品數(shù)量。 架構(gòu)師還定義業(yè)務(wù)層公開的服務(wù)間隔。對于本示例，業(yè)務(wù)層為 Account、UserAccount、Order、Shipment 和 Catalog 導(dǎo)出了 Create、Read、Update 和 Delete (CRUD) 服務(wù)。橢圓形指出了 CRUD 間隔。 請注意，即使本層次的類不是業(yè)務(wù)處理類的合適超集，架構(gòu)師也可以通過直接改進(jìn)業(yè)務(wù)處理類、將視角由系統(tǒng)外部更改為系統(tǒng)內(nèi)部來實(shí)現(xiàn)這個(gè)設(shè)計(jì)。物理抽象層次物理抽象層次捕獲系統(tǒng)實(shí)現(xiàn)的結(jié)構(gòu)。系統(tǒng)作為一個(gè)節(jié)點(diǎn)的網(wǎng)絡(luò)實(shí)現(xiàn)，每個(gè)節(jié)點(diǎn)都配置有硬件和軟

19、件。邏輯視圖中的三個(gè)軟件層（表示層、業(yè)務(wù)層和數(shù)據(jù)層）是以代碼形式被物理實(shí)現(xiàn)，并部署到這些節(jié)點(diǎn)上。邏輯視圖中的持久類物理存儲(chǔ)在 SQL Server 數(shù)據(jù)庫的關(guān)系表中。 動(dòng)態(tài)視圖動(dòng)態(tài)視圖跟蹤經(jīng)過物理配置節(jié)點(diǎn)的消息流。ConfirmOrder HTTP post 從客戶的瀏覽器通過 Internet 通過零售商的防火墻流動(dòng)到 Web 服務(wù)器，在那里 Microsoft Windows 將其轉(zhuǎn)發(fā)到 IIS，IIS 又將其傳遞到 Microsoft ASP.NET，然后 ASP.NET 調(diào)度 ConfirmOrder.aspx。幸運(yùn)的是，現(xiàn)代開發(fā)工具將我們與多數(shù)物理網(wǎng)絡(luò)隔離開來。但是，架構(gòu)師需要了解物

20、理層以避免網(wǎng)絡(luò)瓶頸和安全暴露。 靜態(tài)視圖靜態(tài)視圖（圖 8）將邏輯視圖中的持久類改進(jìn)為其物理表示形式。在我們的零售示例中，業(yè)務(wù)層類存儲(chǔ)在下列 SQL Server 表中。 圖 8. 從零售商處在線購買物品的物理層次靜態(tài)視圖映射到關(guān)系表和屬性的類作為列實(shí)現(xiàn)。一對一關(guān)系和一對多關(guān)系使用一個(gè)外鍵來實(shí)現(xiàn)。開放式并發(fā)通過給每個(gè)被"凝結(jié)"的父類分配一個(gè) datetime 字段來實(shí)現(xiàn)。在設(shè)計(jì)邏輯層次時(shí)，架構(gòu)師主要集中關(guān)注于實(shí)現(xiàn)系統(tǒng)功能。在確信包含了系統(tǒng)功能之后，架構(gòu)師就能夠?qū)Ｗ⒂谠谖锢韺哟蝺?yōu)化實(shí)現(xiàn)。通過迭代發(fā)展層次建立了這個(gè)框架后，架構(gòu)師通過幾次迭代對解決方案加以發(fā)展。每次迭代都

21、合并額外的功能 發(fā)票、待交定單、親自訂購、電話訂購等等。在每種情況下，架構(gòu)師都更新適當(dāng)?shù)某橄髮哟?，然后將這些更新改進(jìn)到物理實(shí)現(xiàn)層。重訪抽象層次核心原則讓我們對照核心抽象層次原則來測試我們的示例。 這些層次的數(shù)量和范圍是定義完善的：我們有四個(gè)不同的層次：公司黑盒子、系統(tǒng)黑盒子、系統(tǒng)內(nèi)的邏輯設(shè)計(jì)以及物理實(shí)現(xiàn)。 每個(gè)層次內(nèi)的多個(gè)視圖：在這個(gè)簡單示例中，我們在每個(gè)層次上展示了一個(gè)動(dòng)態(tài)視圖和靜態(tài)視圖。 必須保持層次間的一致性：如果對域模型作出了更改，則更改也一定會(huì)影響到較低層次。舉例來說，如果零售商決定為其產(chǎn)品提供維護(hù)合同，分析師就會(huì)將 MaintenanceContract 添加到域模型，并將其改進(jìn)為

22、其物理表現(xiàn)形式。對于維護(hù)大型系統(tǒng)來說，同步所有層次是很重要的。因?yàn)樘峤涣嗽鰪?qiáng)請求，所以分析師執(zhí)行對相應(yīng)細(xì)節(jié)層次的影響評估。一些增強(qiáng)請求影響域?qū)哟危ú⑶乙虼擞绊懰泻罄m(xù)層次）。其他請求只影響物理層次。 擴(kuò)展層次以支持企業(yè)解決方案既然我們已經(jīng)展示了帶有四個(gè)抽象層次的簡單示例，現(xiàn)在就讓我們擴(kuò)展這個(gè)方法來支持 IT 企業(yè)的解決方案。圖 9 展示了一個(gè) Rational 統(tǒng)一過程 (Rational Unified Process，RUP) 配置，它將項(xiàng)目產(chǎn)品組織到定義完善的抽象層次中。 表中的層次描述如下。圖 9. 將項(xiàng)目產(chǎn)品組織到定義完善的抽象層次中的 RUP 配置 域。域?qū)哟尾东@項(xiàng)目的業(yè)務(wù)環(huán)境。

23、項(xiàng)目洞察力。項(xiàng)目洞察力對系統(tǒng)將會(huì)有的對企業(yè)的業(yè)務(wù)影響進(jìn)行通訊。它以投資回報(bào)分析量化了這個(gè)影響。項(xiàng)目洞察力表示該項(xiàng)目的最高抽象層次。 業(yè)務(wù)處理。系統(tǒng)層次為公司內(nèi)的業(yè)務(wù)處理建模。對于極其復(fù)雜的單位來說，這個(gè)層次可以再細(xì)分到子層次：部門、部門間以及部門內(nèi)。 UI 規(guī)范。UI 規(guī)范設(shè)計(jì)了實(shí)現(xiàn)業(yè)務(wù)處理的用戶界面。它是由 UI 設(shè)計(jì)文檔和功能 UI 原型組成的。 詳細(xì)要求。詳細(xì)要求指定了系統(tǒng)要求的最低層次抽象。它包括諸如數(shù)據(jù)類型格式和詳細(xì)業(yè)務(wù)規(guī)則等詳細(xì)信息。它還包括專業(yè)性要求，例如，性能、可用性、安全性、國際化、配置、可擴(kuò)展性和靈活性要求等。 體系結(jié)構(gòu)。系統(tǒng)的體系結(jié)構(gòu)被組織到六個(gè)視圖中： 邏輯。定義軟件層

24、和執(zhí)行系統(tǒng)功能的主要抽象。 并發(fā)。捕獲系統(tǒng)的并行方面，包括交易、服務(wù)器場和資源爭用。 安全性。定義用于身份驗(yàn)證、授權(quán)、保護(hù)機(jī)密和日志記錄的方法。 部署。定義網(wǎng)絡(luò)拓?fù)浜拖到y(tǒng)的部署配置。 組件。定義系統(tǒng)組件、其接口以及依賴項(xiàng)。 數(shù)據(jù)。定義持久性數(shù)據(jù)的設(shè)計(jì)結(jié)構(gòu)。優(yōu)點(diǎn)將系統(tǒng)產(chǎn)品組織到離散的抽象層次有若干優(yōu)點(diǎn)： 它將系統(tǒng)要求分離到三個(gè)不同的抽象層次：業(yè)務(wù)處理、UI 規(guī)范和詳細(xì)要求。我們不會(huì)再用令企業(yè)用戶感到不知所措的單個(gè)整體功能規(guī)范了。取而代之，我們在三個(gè)改進(jìn)的詳細(xì)層次中對系統(tǒng)要求進(jìn)行通訊。 分析師和架構(gòu)師可以將復(fù)雜性控制在一個(gè)單一的、集成的系統(tǒng)模型中。 架構(gòu)師可以專注于系統(tǒng)的單個(gè)方面，并將那些決策集成

25、到整個(gè)解決方案中。 抽象層次形成了系統(tǒng)產(chǎn)品的結(jié)構(gòu)。舉例來說，軟件體系結(jié)構(gòu)文檔為每個(gè)視圖專設(shè)了一個(gè)小節(jié)。 抽象層次提供從要求到設(shè)計(jì)再到實(shí)現(xiàn)的直接可跟蹤能力?？筛櫮芰κ剐〗M能夠在評測更改請求時(shí)執(zhí)行精確的影響評估。 在使用同一框架開發(fā)幾個(gè)系統(tǒng)之后，會(huì)在每個(gè)抽象層次形成模式。單位可以編錄這些模式和每個(gè)抽象層次內(nèi)的其他最佳實(shí)踐。這個(gè)最佳實(shí)踐的目錄會(huì)作為過程改進(jìn)計(jì)劃的基礎(chǔ)。 小結(jié)為了處理復(fù)雜性，所有工程學(xué)科都應(yīng)用正式抽象層次。軟件也不例外。為了實(shí)現(xiàn)抽象層次的優(yōu)點(diǎn)，項(xiàng)目必須： 正式標(biāo)識(shí)層次，每個(gè)層次都有定義完善的范圍。 將一個(gè)層次內(nèi)的復(fù)雜性分開到多個(gè)視圖。 在層次間保持一致性。 通過一個(gè)簡單的示例，本文演

26、示了如何應(yīng)用抽象層次，然后將該方法擴(kuò)展到支持企業(yè) IT 解決方案。它提供了一個(gè) RUP 配置框架，該框架將系統(tǒng)產(chǎn)品組織到定義完善的抽象層次。 自我評估 您當(dāng)前的項(xiàng)目是否應(yīng)用了抽象層次？ 層次是否定義完善？ 項(xiàng)目團(tuán)隊(duì)是否很好地理解了這些層次？ 如果復(fù)雜性在一個(gè)層次中變得過大，團(tuán)隊(duì)是否將其分離到視圖中呢？ 團(tuán)隊(duì)是否在層次間保持一致性？ 您的項(xiàng)目會(huì)從抽象層次中獲益嗎？ 偉大的架構(gòu)師本能地遵循這些原則。我們其余的人就必須有意識(shí)地應(yīng)用抽象層次，并運(yùn)用規(guī)則在整個(gè)項(xiàng)目生命周期中保持這些層次。資源Cockburn, Alistair. Writing Effective Use Cases. New Jers

27、ey: Addison-Wesley, 2001Kroll, Per and Kruchten, Philippe. The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP. Boston MA: Pearson Education and Addison-Wesley, 2003DeMarco, Tom and Plauger, P J Structured Analysis and System Specification. Prentice Hall PTR, 1979要獲得 DoD 標(biāo)準(zhǔn)

28、 2167A 的聯(lián)機(jī)副本，請?jiān)L問 /SWPI/DOD/MIL-STD-2167A/DOD2167A.html。腳注1 很多人已經(jīng)成功地將抽象層次應(yīng)用于軟件。Ed Yourdon 和 Tom DeMarco 在 1979 年提出了結(jié)構(gòu)化分析和結(jié)構(gòu)化系統(tǒng)設(shè)計(jì)的概念。美國政府的許多分支機(jī)構(gòu)標(biāo)準(zhǔn)化了 DoD 的 2167A 標(biāo)準(zhǔn)，它要求系統(tǒng)由有層次的硬件和軟件配置項(xiàng)組成。DBA 社區(qū)經(jīng)常應(yīng)用細(xì)節(jié)層次為關(guān)系數(shù)據(jù)庫建模。特別地，Bachman 工具集和 James Martin 的信息工程方法學(xué) (Information Engineering Methodology，IEM) 先為數(shù)據(jù)庫邏輯建模，然后再為其物理建模。在 Google 上鍵入"software levels of abstraction"進(jìn)行搜索會(huì)返回若干個(gè)結(jié)果，但其中大多數(shù)來自于學(xué)術(shù)社區(qū)，而且其內(nèi)容看起來集中在正式計(jì)算機(jī)語言方面。關(guān)于作者 Don Awalt 是 RDA Corporation 的創(chuàng)始人和 CEO，該公司是一家自定義軟件工程公司，成立于 1988 年，在華盛頓特區(qū)、巴爾的摩、亞特蘭大