By Don Awalt and Rick McUmber
RDA Corporation
本頁內(nèi)容
將抽象層次應(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)分析出是什么造就了杰出的架構(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ù)雜性中。
本文展示了將抽象層次應(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)用抽象層次的，就從電子工程師開始吧，他們?cè)O(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)中。在其原子部分的層次上確切了解一臺(tái)計(jì)算機(jī)是不可能的。在單獨(dú)一塊 Intel Itanium_ 芯片上有大約 25,000,000 個(gè)晶體管。
對(duì) 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ì)成員必須共享對(duì)層次的同一理解。只要設(shè)計(jì)師做出設(shè)計(jì)決定，他們必須將那些決定歸檔到相應(yīng)的細(xì)節(jié)層次。
三個(gè)抽象層次定義如下：
圖 i. 定義的三個(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ì)按預(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è)針對(duì)假想零售商的簡單的、指導(dǎo)性的在線定單系統(tǒng)示例來展示的。在我們的示例中，我們不僅包括了體系結(jié)構(gòu)，而且擴(kuò)展了范圍以包括系統(tǒng)需求和業(yè)務(wù)環(huán)境 — 如同由零售業(yè)所定義的。
簡單框架：四個(gè)抽象層次
我們的簡單示例定義 IT 解決方案的如下四個(gè)抽象層次：
在每個(gè)層次內(nèi)，我們既展示了該特定層次行為的動(dòng)態(tài)視圖，又展示了其靜態(tài)視圖。動(dòng)態(tài)視圖為對(duì)象之間的消息建模，而靜態(tài)視圖為對(duì)象之間的結(jié)構(gòu)和關(guān)系建模。
域抽象層次
應(yīng)用了上面的范圍規(guī)則，零售商就會(huì)作為域?qū)哟沃械暮诤凶又行牡难輪T。客戶作為外部的演員。域?qū)哟问菑目蛻舻慕嵌葋斫５摹Ｖ粸橘徺I交互建模。用于完成購買的通訊形式不包括在這個(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)的它們的對(duì)象的關(guān)系建模。換句話說，它說明了在這個(gè)抽象層次上，為了完成購買交易客戶需要了解什么對(duì)象。 圖 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ì)對(duì)類模型產(chǎn)生影響，因此將 Product 建模為一個(gè)元類會(huì)使我們的模型更加靈活。圍繞這些類，每個(gè) Payment 都與其 Purchase 相關(guān)。
如您可能看到的，這個(gè)層次的模型對(duì)大多數(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ù)交互。對(duì)此我們必須注意，不要將用于完成交互的實(shí)現(xiàn)機(jī)制包括進(jìn)來。這些細(xì)節(jié)屬于下一個(gè)抽象層次。因此，在本例中，我們只為瀏覽、選擇、購買和支付建模。我們不為如何完成這些交互（通過電話、美國郵政、電子郵件、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)視圖
動(dòng)態(tài)視圖重演了域?qū)哟钨徺I交易，這次公開了零售商的內(nèi)部業(yè)務(wù)處理。圖 4 匯總了業(yè)務(wù)處理環(huán)境，并包含了關(guān)于系統(tǒng)及其演員之間的交互的簡單使用案例描述。
靜態(tài)視圖
這個(gè)層次的靜態(tài)視圖對(duì)類模型做了改進(jìn)，以捕獲在業(yè)務(wù)處理層次使用案例中出現(xiàn)的對(duì)象。換句話說，“為了在線創(chuàng)建一個(gè)定單并履行該定單，客戶和雇員需要理解哪些對(duì)象？”圖 5 展示了業(yè)務(wù)處理層次靜態(tài)視圖的類關(guān)系圖。我們修改域類模型以捕獲在這個(gè)抽象層次上的角度。Person、Account 和 Company 抽象保持不變，Catalog 和 Product 也一樣。但是，用 Order 替換了來自域模型的抽象 Purchase 事件。
Order 包括 LineItem，它與 Catalog 中的 Product 相關(guān)聯(lián)。因?yàn)檫@個(gè)層次為公司的內(nèi)部業(yè)務(wù)處理建模，所以我們需要獲得現(xiàn)有的庫存（最小庫存單元 (SKU) 的一個(gè)屬性，它表示在一個(gè)特定位置的物品的庫存）。我們也為客戶的 UserAccount 建模，它提供對(duì)在線系統(tǒng)的訪問。Payment 是通過使用 CreditCardAccount 來完成的。Location 代表美國的一個(gè)地理位置，它作為賬單郵寄地址，同時(shí)也作為 Order 的收貨地址。Shipment 包含 Shipment 中包括的 Item。
我們?cè)谙到y(tǒng)抽象層次創(chuàng)造方法來簡化業(yè)務(wù)處理，因此該層次通常需要很多創(chuàng)造力。為此，通常使用業(yè)務(wù)處理層次上的若干不同形式來實(shí)現(xiàn)單個(gè)域?qū)哟谓灰住Ｅe例來說，一次購買可以通過在線、電話、郵件、傳真一個(gè)定單表格或者親自到零售店來完成。對(duì)于每一種形式，都需要在業(yè)務(wù)處理層次為其建模。請(qǐng)注意，盡管對(duì)零售商來說 Credit Authorizer 是一個(gè)外部演員，但是它還是在這個(gè)層次引入，這是因?yàn)橹恍枰鼘?shí)現(xiàn)在該層次首次出現(xiàn)的業(yè)務(wù)處理。
最后，請(qǐng)注意該系統(tǒng)是技術(shù)獨(dú)立的。我們的在線購買系統(tǒng)可以用任何 Web 技術(shù)實(shí)現(xiàn)。在系統(tǒng)黑盒子內(nèi)選擇技術(shù)是一個(gè)體系結(jié)構(gòu)決策。
邏輯抽象層次
邏輯層在系統(tǒng)黑盒子內(nèi)縮放，從而公開高級(jí)別的系統(tǒng)設(shè)計(jì)。架構(gòu)師選擇技術(shù)并定義高級(jí)系統(tǒng)結(jié)構(gòu)。在我們的簡單示例中，系統(tǒng)是由承載表示層、業(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ù)據(jù)訪問層）設(shè)計(jì)類。為了保持本文的簡潔，圖 7 只展示了業(yè)務(wù)層的靜態(tài)設(shè)計(jì)，以便說明系統(tǒng)層抽象是如何針對(duì)設(shè)計(jì)進(jìn)行改進(jìn)的。
圖 7. 從零售商處在線購買物品的邏輯層次靜態(tài)視圖
架構(gòu)師對(duì)系統(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í)例。此外，對(duì)系統(tǒng)來說，為每個(gè)出售的 Item 創(chuàng)建一個(gè)實(shí)例是不切實(shí)際的，因此從模型中刪除了 Item，并改為由模型跟蹤 LineItem 中訂購的物品數(shù)量以及在新 ShippedItems 類中附帶的物品數(shù)量。
架構(gòu)師還定義業(yè)務(wù)層公開的服務(wù)間隔。對(duì)于本示例，業(yè)務(wù)層為 Account、UserAccount、Order、Shipment 和 Catalog 導(dǎo)出了 Create、Read、Update 和 Delete (CRUD) 服務(wù)。橢圓形指出了 CRUD 間隔。
請(qǐng)注意，即使本層次的類不是業(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)都配置有硬件和軟件。邏輯視圖中的三個(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)師需要了解物理層以避免網(wǎng)絡(luò)瓶頸和安全暴露。
靜態(tài)視圖
靜態(tài)視圖（圖 8）將邏輯視圖中的持久類改進(jìn)為其物理表示形式。在我們的零售示例中，業(yè)務(wù)層類存儲(chǔ)在下列 SQL Server 表中。
圖 8. 從零售商處在線購買物品的物理層次靜態(tài)視圖
映射到關(guān)系表和屬性的類作為列實(shí)現(xiàn)。一對(duì)一關(guān)系和一對(duì)多關(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)師通過幾次迭代對(duì)解決方案加以發(fā)展。每次迭代都合并額外的功能 — 發(fā)票、待交定單、親自訂購、電話訂購等等。在每種情況下，架構(gòu)師都更新適當(dāng)?shù)某橄髮哟危缓髮⑦@些更新改進(jìn)到物理實(shí)現(xiàn)層。
重訪抽象層次核心原則
讓我們對(duì)照核心抽象層次原則來測試我們的示例。
| • |
這些層次的數(shù)量和范圍是定義完善的：我們有四個(gè)不同的層次：公司黑盒子、系統(tǒng)黑盒子、系統(tǒng)內(nèi)的邏輯設(shè)計(jì)以及物理實(shí)現(xiàn)。
|
| • |
每個(gè)層次內(nèi)的多個(gè)視圖：在這個(gè)簡單示例中，我們?cè)诿總€(gè)層次上展示了一個(gè)動(dòng)態(tài)視圖和靜態(tài)視圖。
|
| • |
必須保持層次間的一致性：如果對(duì)域模型作出了更改，則更改也一定會(huì)影響到較低層次。舉例來說，如果零售商決定為其產(chǎn)品提供維護(hù)合同，分析師就會(huì)將MaintenanceContract 添加到域模型，并將其改進(jìn)為其物理表現(xiàn)形式。對(duì)于維護(hù)大型系統(tǒng)來說，同步所有層次是很重要的。因?yàn)樘峤涣嗽鰪?qiáng)請(qǐng)求，所以分析師執(zhí)行對(duì)相應(yīng)細(xì)節(jié)層次的影響評(píng)估。一些增強(qiáng)請(qǐng)求影響域?qū)哟危ú⑶乙虼擞绊懰泻罄m(xù)層次）。其他請(qǐng)求只影響物理層次。
|
擴(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)境。
|
| • |
項(xiàng)目洞察力。項(xiàng)目洞察力對(duì)系統(tǒng)將會(huì)有的對(duì)企業(yè)的業(yè)務(wù)影響進(jìn)行通訊。它以投資回報(bào)分析量化了這個(gè)影響。項(xiàng)目洞察力表示該項(xiàng)目的最高抽象層次。
|
| • |
業(yè)務(wù)處理。系統(tǒng)層次為公司內(nèi)的業(yè)務(wù)處理建模。對(duì)于極其復(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è)視圖中：
| • |
邏輯。定義軟件層和執(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ī)范了。取而代之，我們?cè)谌齻€(gè)改進(jìn)的詳細(xì)層次中對(duì)系統(tǒng)要求進(jìn)行通訊。
|
| • |
分析師和架構(gòu)師可以將復(fù)雜性控制在一個(gè)單一的、集成的系統(tǒng)模型中。
|
| • |
架構(gòu)師可以專注于系統(tǒng)的單個(gè)方面，并將那些決策集成到整個(gè)解決方案中。
|
| • |
抽象層次形成了系統(tǒng)產(chǎn)品的結(jié)構(gòu)。舉例來說，軟件體系結(jié)構(gòu)文檔為每個(gè)視圖專設(shè)了一個(gè)小節(jié)。
|
| • |
抽象層次提供從要求到設(shè)計(jì)再到實(shí)現(xiàn)的直接可跟蹤能力。可跟蹤能力使小組能夠在評(píng)測更改請(qǐng)求時(shí)執(zhí)行精確的影響評(píng)估。
|
| • |
在使用同一框架開發(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è)簡單的示例，本文演示了如何應(yīng)用抽象層次，然后將該方法擴(kuò)展到支持企業(yè) IT 解決方案。它提供了一個(gè) RUP 配置框架，該框架將系統(tǒng)產(chǎn)品組織到定義完善的抽象層次。
自我評(píng)估
| • |
您當(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 Jersey: Addison-Wesley, 2001
Kroll, Per and Kruchten, Philippe. The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP. Boston MA: Pearson Education and Addison-Wesley, 2003
DeMarco, Tom and Plauger, P J Structured Analysis and System Specification. Prentice Hall PTR, 1979
腳注
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ū)、巴爾的摩、亞特蘭大、費(fèi)城和芝加哥都設(shè)有辦事處。作為微軟認(rèn)證金牌伙伴 (Microsoft Gold Certified Partner)，該公司專注于使用 .NET Framework 開發(fā)企業(yè) Web 和富客戶端系統(tǒng)。Don 目前是 Microsoft 華盛頓特區(qū)的區(qū)域總監(jiān)，他以前曾經(jīng)擔(dān)任費(fèi)城首任區(qū)域總監(jiān)。Don 經(jīng)常在行業(yè)活動(dòng)中演講，這些活動(dòng)包括 Tech Ed、Developer Days、MSDN 活動(dòng)和各種 SQL Server 及 Windows 活動(dòng)。他是 SQL Server Magazine 和 PC Tech Journal Magazine 的特約編輯，并且也為其它出版物撰寫稿件。Don 所擅長的技術(shù)領(lǐng)域包括 Web 服務(wù)、SQL Server、現(xiàn)代編程語言的發(fā)展，以及在 Microsoft 的 Prescriptive Architecture Group (PAG) 中可以看到的許多體系結(jié)構(gòu)和處理工作。可以通過
AWALT@rdacorp.com 聯(lián)系到 Don。
Rick McUmber 是 RDA 的質(zhì)量和最佳實(shí)踐總監(jiān)。他為 IBM 和 Rational Software Corporation 一共工作了 11 年，致力于為美國運(yùn)輸部、國防部、NASA 和加拿大國防部開發(fā)系統(tǒng)。從 1994 年以來，他一直在 RDA 工作，致力于為其客戶開發(fā)業(yè)務(wù)解決方案。可以通過
McUmber@rdacorp.com 聯(lián)系到 Rick。
本博客為學(xué)習(xí)交流用，凡未注明引用的均為本人作品，轉(zhuǎn)載請(qǐng)注明出處，如有版權(quán)問題請(qǐng)及時(shí)通知。由于博客時(shí)間倉促，錯(cuò)誤之處敬請(qǐng)諒解，有任何意見可給我留言，愿共同學(xué)習(xí)進(jìn)步。