国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

文檔選項 將此頁作為電子郵件發(fā)送 拓展 Tomcat 應(yīng)用 下載 IBM 開源 J2EE 應(yīng)用服務(wù)器 WAS CE 新版本 V1.1

級別: 初級

Peter Eeles, 高級 IT 架構(gòu)師, IBM

2006 年 4 月 15 日

本文來自于 Rational Edge：這篇關(guān)于軟件架構(gòu)的較新規(guī)則的介紹，是一個關(guān)于“架構(gòu)”的四篇系列文章的的第一篇。作者以定義規(guī)則的關(guān)鍵術(shù)語開始，繼續(xù)探索設(shè)計出色的架構(gòu)對于架構(gòu)所部署的環(huán)境所起的作用。

高新企業(yè)為了生存，因此他們所依靠的軟件必須能提供其所需的功能；所需的高質(zhì)量；所承諾的可用性，和可接受的價格。

這篇文章的主題就是關(guān)于可以影響這些屬性的軟件架構(gòu)。我所關(guān)注的是“強軟件系統(tǒng)”，在IEEE中定義如下：

一個軟件集成系統(tǒng)就是軟件對于設(shè)計，構(gòu)建，配置和整個系統(tǒng)的發(fā)展具有深入影響的系統(tǒng)[來自 IEEE 1471，"架構(gòu)的定義" 部分]

在本文中，“架構(gòu)”與“軟件架構(gòu)”是相同的含義。雖然這篇文章關(guān)注于軟件集成系統(tǒng)，但是應(yīng)該注意，軟件集成系統(tǒng)仍然需要硬件來運行，并且諸如可靠性和性能等品質(zhì)是通過軟硬件的結(jié)合實現(xiàn)的。所以解決方案中的硬件部分不能被忽略。文中后面將更詳細(xì)的討論這部分內(nèi)容。

定義的架構(gòu)

我們對于“架構(gòu)”的定義沒有缺陷。甚至存在支持定義集的網(wǎng)站。¹ 文中的定義來自IEEE標(biāo)準(zhǔn) 1472000，IEEE對強軟件系統(tǒng)的架構(gòu)描述的推薦實踐，參見IEEE 1471。² 定義如下，其中重要部分用粗體字表示。

架構(gòu)是在組件，彼此間和與環(huán)境間的關(guān)系，引導(dǎo)設(shè)計發(fā)展原則中體現(xiàn)的系統(tǒng)的基本結(jié)構(gòu)。[IEEE 1471]

這些標(biāo)準(zhǔn)還定義了以下相關(guān)概念：

系統(tǒng)是為實現(xiàn)某個（些）特殊作用的組件的集合。專用系統(tǒng)包括個人應(yīng)用，傳統(tǒng)概念上的系統(tǒng)，子系統(tǒng)，系統(tǒng)中的系統(tǒng)，產(chǎn)品線，產(chǎn)品系列，整個企業(yè)和其他利益集團。一個系統(tǒng)是為了實現(xiàn)一個或多個任務(wù)而存在。[IEEE 1471]

環(huán)境決定了開發(fā)，操作，策略和其他影響系統(tǒng)的設(shè)置和條件。[IEEE 1471]

任務(wù)是指系統(tǒng)為了實現(xiàn)對對象設(shè)置的使用或操作。[IEEE 1471]

涉眾是對于系統(tǒng)有利益關(guān)系或關(guān)注的個人，團隊或組織。[IEEE 1471]

正如我們所見，“組件”貫穿于這些定義。正如有意留下一個模糊的概念來解釋，大部分架構(gòu)定義沒有提到“組件”，IEEE 1471也不例外。組件也許是邏輯上的或物理存在的，技術(shù)上獨立的或特定的，規(guī)模大的或規(guī)模小的。由于文章的原因，我使用了UML 2.0規(guī)范的組件定義；并且我相當(dāng)寬松的使用這個概念來包含各種所遇到的架構(gòu)成分，包括了對象，技術(shù)組件（例如Enterprise JavaBean），服務(wù)，程序模塊，遺留系統(tǒng)，包應(yīng)用程序等。這些是 UML 2.0中對“組件”的定義：

[組件]是包括內(nèi)容的系統(tǒng)模型部分，且它的顯示是可替換的。組件定義了所需接口的行為。例如，組件類似類型(type)，它與所需接口行為一致。（包括靜態(tài)和動態(tài)語義）³

這里的定義包括了多種不同的概念，文中后面將有更詳細(xì)的介紹。雖然工業(yè)界對于“架構(gòu)”的概念沒有普遍的共識，但是有必要考慮一些其他的定義使得他們可以被遵照。參照一下下面的定義，重點處我已經(jīng)用粗體表示。

架構(gòu)是對軟件系統(tǒng)組織，結(jié)構(gòu)部分和系統(tǒng)包含接口的選擇，集合部分的特定行為，較大子系統(tǒng)部分的構(gòu)成和架構(gòu)風(fēng)格的重大決定的設(shè)置。[Kruchten]⁴

系統(tǒng)或計算系統(tǒng)的軟件架構(gòu)是包含軟件部分，外部可見特性部分，和他們之間的關(guān)系的系統(tǒng)的結(jié)構(gòu)。[Bass et al.]⁵

[架構(gòu)]是系統(tǒng)的組織結(jié)構(gòu)和相關(guān)行為。架構(gòu)可被重復(fù)分解為通過接口，互聯(lián)部分的關(guān)系和結(jié)合部相互作用的部分。通過接口相互作用的部分包括類，組件和子系統(tǒng)。[UML 1.5]⁶

軟件架構(gòu)或系統(tǒng)由組成系統(tǒng)的結(jié)構(gòu)的相互作用和軟件結(jié)構(gòu)的重要設(shè)計決定組成。設(shè)計決定應(yīng)成功實現(xiàn)所期望支持的質(zhì)量。設(shè)計決定為系統(tǒng)開發(fā)，支持和維護提供概念上的基礎(chǔ)。 [McGovern]⁷

雖然在某些方面定義有些區(qū)別，但我們可以看到大部分是相同的。例如，大部分定義都指出一個架構(gòu)關(guān)注于結(jié)構(gòu)和行為，僅關(guān)注于重要決定，可以與架構(gòu)風(fēng)格一致，受涉眾和環(huán)境的影響，體現(xiàn)基于原因的決定。所有這些方面，都在下面提到。

一個架構(gòu)定義結(jié)構(gòu)

如果你要求人們?yōu)槟忝枋觥凹軜?gòu)”，十分之九的人都會參照結(jié)構(gòu)來解釋。這在關(guān)于構(gòu)建或其他土木工程結(jié)構(gòu)（例如橋梁）中非常常見。雖然這些條目中的其他屬性（例如行為，目的適當(dāng)性和美學(xué)觀念）也存在，但是結(jié)構(gòu)的屬性是最熟悉的和最經(jīng)常被提到的。

我們對你會讓某人來描述一下他所工作的軟件系統(tǒng)架構(gòu)一點也不會感到奇怪，他們將會給你展示一份系統(tǒng)結(jié)構(gòu)方面的圖表——無論這些內(nèi)容是否是架構(gòu)層，組件，或是分布結(jié)點。事實上，結(jié)構(gòu)是架構(gòu)的基礎(chǔ)屬性。架構(gòu)會以各種形式展示他們自己，且大部分架構(gòu)的定義是非常模糊的。一個結(jié)構(gòu)組件可能是一個子系統(tǒng)，進程，庫，數(shù)據(jù)庫，計算結(jié)點，饋贈系統(tǒng)，按需產(chǎn)品等等。

許多架構(gòu)的定義不但承認(rèn)了他們自己的結(jié)構(gòu)元素，而且還有結(jié)構(gòu)元素的組成，關(guān)系（任何連接部分都需支持這樣的關(guān)系），接口。這些部件都以不同方式被提供。例如，連接段可以是套接字，同步的或異步的，與某個協(xié)議相關(guān)等。

圖1提供了結(jié)構(gòu)元素的例子。這幅圖顯示了包含展示順序進程系統(tǒng)的結(jié)構(gòu)部分的UML類圖。我們看到有三個類——OrderEntry，CustomerManagement，和AccountManagement。OrderEntry類與CustomerManagement和AccountManagement類相連。

圖1：UML類圖顯示了結(jié)構(gòu)元素

一個架構(gòu)定義行為

與定義結(jié)構(gòu)元素一樣，架構(gòu)定義了這些結(jié)構(gòu)元素的相互作用。這些作用可以實現(xiàn)所期望的系統(tǒng)行為。圖2展示了允許系統(tǒng)支持在順序進程系統(tǒng)中的次序定義的UML順序圖。在這里我們能看到五個交互作用。第一，Sales Clerk使用OrderEntry類創(chuàng)建了一個順序。OrderEntry使得客戶得到使用CustomerManagement類的細(xì)節(jié)。然后OrderEntry使用 AccountManagement類創(chuàng)建一個次序，用次序條目構(gòu)建順序。

圖2：UML是序列圖顯示了行為元素

圖2與圖1相連，因為我們能從圖2中的關(guān)于交互作用的定義得到圖1中的相關(guān)內(nèi)容。例如，OrderEntry事例在被執(zhí)行中要依靠CustomerManagement事例，正如在圖2中所示的一樣。這種依賴就如OrderEntry和CustomerManagement間通信所反映的依賴關(guān)系一樣。

一個架構(gòu)關(guān)注于重要元素

當(dāng)一個架構(gòu)定義了結(jié)構(gòu)和行為，它不會在意所有的結(jié)構(gòu)和行為的定義。它只在意那些被認(rèn)為是重要的元素。重要的元素是那些有持久影響的，例如結(jié)構(gòu)部分的主要部分，與核心行為相關(guān)的元素，和對諸如可靠性和可測量性等重要品質(zhì)相關(guān)的元素。總的來說，架構(gòu)不關(guān)心這些元素的細(xì)節(jié)。架構(gòu)的重要性還可以以經(jīng)濟的重要性來表達，因為某些元素的主要驅(qū)動者是創(chuàng)建的成本和變更的成本。

由于架構(gòu)僅關(guān)注于重要元素，它給我們提供了在考慮中的系統(tǒng)的一個特殊透視圖——與架構(gòu)最相關(guān)的透視圖。⁸在這種含義下，一個架構(gòu)是一個系統(tǒng)的抽象，可以幫助架構(gòu)師管理復(fù)雜性。

我們僅僅應(yīng)注意重要元素的設(shè)置不是靜態(tài)的。作為一個需要被提煉，確定風(fēng)險，可執(zhí)行的軟件構(gòu)建和經(jīng)驗總結(jié)的結(jié)果，重要元素的設(shè)置可能會改變。但是，面對改變的架構(gòu)的穩(wěn)定性是好的架構(gòu)，好的可執(zhí)行架構(gòu)進程，好的架構(gòu)師的標(biāo)志。如果架構(gòu)需要根據(jù)變化不斷作出調(diào)整，那么這不是一個好的標(biāo)志。但是，如果架構(gòu)相對穩(wěn)定，那么相反的也對。

一個架構(gòu)可以平衡涉眾需求

架構(gòu)是為了實現(xiàn)涉眾的需要而創(chuàng)造的。但是，一般來說不可能滿足所有的需求。例如，涉眾可能會問特定的時間框的功能，但是這兩方面（功能和時間框）是互斥的?；蛘邽榱藵M足時間表而減少范圍或者所有的功能可以擴展時間框?qū)崿F(xiàn)。類似的，不同的涉眾之間可能有相互沖突的需求，所以應(yīng)滿足適當(dāng)?shù)钠胶庑?。所以作折中是?gòu)建進程的主要方面，且妥協(xié)是架構(gòu)的重要屬性。

僅僅提供一個任務(wù)的例子，考慮如下涉眾群各自的所需：

• 最終用戶關(guān)心直覺，正確的行為，性能，可靠性，可用性，有效性和安全性。
• 系統(tǒng)管理員關(guān)注直覺行為，管理和輔助監(jiān)測。
• 業(yè)務(wù)人員關(guān)注有競爭力的特性，市場的時效性，對于其他產(chǎn)品的定位和開銷。
• 客戶關(guān)注開銷，穩(wěn)定性和計劃性。
• 開發(fā)者關(guān)注清晰的需求和簡單而一致的設(shè)計方法。
• 項目經(jīng)理關(guān)注追蹤項目，計劃，資源的生產(chǎn)使用和預(yù)算的可預(yù)見性。
• 維護人員關(guān)注易理解性，一致性，和文檔化的設(shè)計方法，與易修改性。

正如表中可看到的，對于架構(gòu)師的另一個挑戰(zhàn)是涉眾群不僅僅關(guān)注系統(tǒng)所提供的需求功能。他們所關(guān)注的在實際中是不起作用的，因為在系統(tǒng)中他們不發(fā)生作用。（例如，關(guān)于成本和計劃的關(guān)注）但是這些關(guān)注體現(xiàn)了系統(tǒng)質(zhì)量或局限。非功能需求經(jīng)常是架構(gòu)師所關(guān)注的最重要的需求。

一個架構(gòu)基于基本原理體現(xiàn)決策

一個架構(gòu)的重要部分不僅僅是最終結(jié)果，架構(gòu)本身，而是他為什么是如此的原因。因此，確信你已把使用這個架構(gòu)和原因文檔化就非常重要了。

這個信息與許多涉眾都有關(guān)系，尤其是那些維護系統(tǒng)的人。這些信息對需要參考設(shè)計理由的架構(gòu)師來說非常有價值，因為他們可以省去不必要的步驟。例如，當(dāng)需要重復(fù)架構(gòu)和架構(gòu)師重新審視所做的決定時，這些信息非常有用。

一個架構(gòu)可以符合一個架構(gòu)樣式

大部分的架構(gòu)來源于有相似關(guān)注的共享系統(tǒng)。這些相似性可被描述成某種特殊模式的架構(gòu)風(fēng)格，雖然經(jīng)常是復(fù)雜和組合模式（由許多模式共同作用）。一種架構(gòu)風(fēng)格展示一個經(jīng)驗法典，并且有利于架構(gòu)師重復(fù)使用類似經(jīng)驗。架構(gòu)風(fēng)格的例子包括分布式的風(fēng)格，管道和過濾器風(fēng)格，數(shù)據(jù)中心風(fēng)格，基于規(guī)則的風(fēng)格等。一個系統(tǒng)可以包含多于一個架構(gòu)風(fēng)格。Shaw和Garlan的描述如下：

[架構(gòu)風(fēng)格] 按照結(jié)構(gòu)組織的模式定義了系統(tǒng)。更具體的，架構(gòu)風(fēng)格定義了組件和連接型的語法，和連接的方法。⁹

在 UML 中的定義:

[模式] 是對于普遍問題的普遍解決方案。¹⁰

除了重復(fù)經(jīng)驗，由于一種風(fēng)格以文檔的形式保存了使用它的理由和它的結(jié)構(gòu)與行為，所以架構(gòu)風(fēng)格的應(yīng)用使類似架構(gòu)師的工作變得容易起來。

一個架構(gòu)被其環(huán)境所影響

系統(tǒng)貯存于環(huán)境中，且環(huán)境影響架構(gòu)。這就是有時所提到的“環(huán)境中的架構(gòu)”?；旧?，環(huán)境決定了系統(tǒng)運行的范圍，這些又決定了架構(gòu)。影響架構(gòu)的環(huán)境的因素包含架構(gòu)所支持的商務(wù)環(huán)境，系統(tǒng)涉眾群，內(nèi)部技術(shù)限制（例如需要符合組織標(biāo)準(zhǔn)），和外部技術(shù)限制（例如對外部系統(tǒng)的接口或遵守外部規(guī)則的標(biāo)準(zhǔn)）。

相反的，如在Bass, Clements, 和Kazman所描述的，¹¹架構(gòu)可能還影響它的環(huán)境。不但是從技術(shù)前景的架構(gòu)創(chuàng)新改變了環(huán)境--例如它可能對擁有組織的可重復(fù)使用價值有貢獻——架構(gòu)的創(chuàng)新可能在技術(shù)方面改變環(huán)境。

當(dāng)提到軟件集成系統(tǒng)，有一個必須被提到的關(guān)于環(huán)境的特殊部分。為了軟件的有用性，它必須執(zhí)行。為了執(zhí)行，軟件運行在硬件之上。所以最終系統(tǒng)是軟硬件的結(jié)合，與諸如可靠性和性能等完美結(jié)合的實現(xiàn)。軟件不能在單獨的硬件條件下實現(xiàn)這些功能。

IEEE 標(biāo)準(zhǔn) 12207-1995，IEEE 信息技術(shù)標(biāo)準(zhǔn) －－ 軟件生命周期過程，定義了與之前IEEE1471不同的系統(tǒng)（關(guān)注于軟件集成系統(tǒng)），但與在系統(tǒng)工程方面定義的相同：

[系統(tǒng)]是包含了一個或多個進程，硬件，軟件，工具與可以滿足需求的人的集合。 [IEEE 12207]¹²

[系統(tǒng)]是提供為企業(yè)執(zhí)行商業(yè)目的或任務(wù)的服務(wù)資源。系統(tǒng)組件包括硬件，軟件，數(shù)據(jù)和工作人員¹³。

在系統(tǒng)工程方面，根據(jù)軟件，硬件和人的使用定義事務(wù)。例如，如果性能為重，那么可能決定某一個系統(tǒng)元素的硬件實現(xiàn)，而不是軟件或人。另一個例子是為了給客戶提供可用系統(tǒng)，所以要給客戶提供接口。更復(fù)雜的情況需要通過軟硬件和人的結(jié)合實現(xiàn)系統(tǒng)功能。

我們非常有趣的注意到系統(tǒng)工程特別關(guān)注于對待軟件和硬件，因此避免把硬件和軟件相比作為第二級，或是執(zhí)行軟件的載體，或是反過來。

一個架構(gòu)影響團隊結(jié)構(gòu)

架構(gòu)定義了一組連貫的相關(guān)元素。例如，順序進程系統(tǒng)架構(gòu)可能已定義了一組次序入口，計數(shù)管理，客戶管理，實現(xiàn)，外部系統(tǒng)集成，持續(xù)性和安全性。

每一組都會要求不同的技術(shù)。因此，一旦被定義好，統(tǒng)一軟件開發(fā)小組結(jié)構(gòu)就非常有意義了。但是，情況經(jīng)常是最初的小組結(jié)構(gòu)影響了構(gòu)架，而不是相反情況。因為結(jié)果通常都是一個不太理想的架構(gòu)?！翱低?guī)律” 規(guī)定“如果你有4個編譯小組，那你會有4路編譯器”。 實際上，我們經(jīng)常會無意識地創(chuàng)建架構(gòu)，以反映創(chuàng)建架構(gòu)的組織。

但是，完全從實際出發(fā)，事實上這種有點理想的觀點經(jīng)常是不實際的，因為當(dāng)前小組結(jié)構(gòu)和技術(shù)都有實際可能的限制，并且架構(gòu)師必須考慮在內(nèi)。

一個架構(gòu)呈現(xiàn)在每一個系統(tǒng)中

每個系統(tǒng)都有一個架構(gòu)，即使這個架構(gòu)沒有被文檔化，或者如果系統(tǒng)非常簡單且包含單一元素。對架構(gòu)文檔化很有價值。文檔化的架構(gòu)比沒有的考慮的更周全——因此也更有效，所以根據(jù)架構(gòu)的進程可以更細(xì)致的考慮。

相反地，如果架構(gòu)沒有文檔化，那么很困難來證明滿足了諸如可維護性，最佳適應(yīng)性等的需求。似乎大部分現(xiàn)今存在的無文檔的架構(gòu)都有些隨意性而不是目的性。

一個架構(gòu)擁有一個特定的范圍

有許許多多種架構(gòu)，最著名的是與建筑和其他工程相關(guān)的。甚至在軟件工程領(lǐng)域，我們經(jīng)常會遇到不同形式的架構(gòu)。例如，除了軟件構(gòu)架的概念，我們會遇到諸如企業(yè)架構(gòu)，系統(tǒng)架構(gòu)，組織架構(gòu)，信息架構(gòu)，硬件架構(gòu)，應(yīng)用架構(gòu)，基礎(chǔ)設(shè)施架構(gòu)等。你會見到其他類型的，每種類型都定義了一個架構(gòu)的具體范圍。

不幸的是，產(chǎn)業(yè)界沒有相互形式間的協(xié)定，所以導(dǎo)致了對同一形式的不同意思。但是，從圖3中可以推斷出這些形式的范圍。當(dāng)你們在考慮和討論下面這張圖的時候，你肯定會發(fā)現(xiàn)很多你不同意的元素或是在你們的組織中不同的使用方法。但是重要的是——這些形式的確存在，卻沒有一致的觀點。

圖3：不同領(lǐng)域的范圍

圖3展示的元素有：

• 軟件架構(gòu)——這篇文章主要的關(guān)注點。
• 硬件架構(gòu)——包括CPU, 內(nèi)存，硬盤，周邊設(shè)備例如打印機，與連接這些元素的部分。
• 組織架構(gòu)——是一些關(guān)于商業(yè)進程，組織結(jié)構(gòu)，規(guī)則和職責(zé)，與組織核心能力的部分。
• 信息架構(gòu)——包含組織好的信息結(jié)構(gòu)。
• 軟件架構(gòu)，硬件架構(gòu)，組織架構(gòu)和信息架構(gòu)是全部系統(tǒng)架構(gòu)的子結(jié)構(gòu)。
• 企業(yè)架構(gòu)，與系統(tǒng)架構(gòu)很相似，包括硬件，軟件，人員等。但是，企業(yè)架構(gòu)與商業(yè)有很強的聯(lián)系，因為它專注于商業(yè)對象的聯(lián)系，專注于商業(yè)敏捷性和組織效率。企業(yè)架構(gòu)可能穿插于公司間。

正像人們期盼的那樣，有相應(yīng)形式的架構(gòu)師（例如軟硬件架構(gòu)師等）和架構(gòu)（例如，軟硬件架構(gòu)等）。

現(xiàn)在我們已瀏覽過這些定義了，但還有很多未回答的問題。企業(yè)架構(gòu)與系統(tǒng)架構(gòu)間有什么不同？一個企業(yè)是一個系統(tǒng)？信息架構(gòu)與數(shù)據(jù)集成軟件應(yīng)用中的數(shù)據(jù)架構(gòu)是一樣的？不幸的是，沒有對這些問題的一致的答案。

對現(xiàn)在來說，你會意識到這些不同，但是產(chǎn)業(yè)界不存在對這些內(nèi)容的一致定義。因此，對你的建議只是選擇那些與你的組成相似的形式并且合適的定義他們。至少你會獲得某些一致性，并減少錯誤傳達的可能。

總結(jié)

這篇文章關(guān)注于定義軟件架構(gòu)的核心特性。但是，仍然有很多未被解答的問題。什么是軟件架構(gòu)師的角色？架構(gòu)師最重要的活動是什么？從“建立架構(gòu)”中能得到什么好處？這些問題將在后續(xù)文章中被解答。

感謝

這篇文章的內(nèi)容來源于一本即將出版的新書，暫時叫做“軟件架構(gòu)建立過程”。最后，我衷心的感謝對內(nèi)容提出寶貴意見的人們，他們是Grady Booch，Dave Braines，Alan Brown，Mark Dickson，Holger Heuss，Kelli Houston，Luan Doan-Minh，Philippe Kruchten，Nick Rozanski，Dave Williams，和Eoin Woods。

注釋

¹ 軟件工程研究所（SEI）架構(gòu)Web站點 －－ 架構(gòu)定義，提供了一個好的例子。參見 http://www.sei.cmu.edu/architecture/definitions.html

² IEEE Computer Society，強軟件系統(tǒng)的架構(gòu)描述的IEEE推薦實踐：IEEE 標(biāo)準(zhǔn) 1472000，2000。

³ 對象管理組織，UML 2.0 結(jié)構(gòu)規(guī)格說明：文檔號 03-09-15。2003年九月。

⁴ Philippe Kruchten，Rational統(tǒng)一過程：介紹，第三版。Addison-Wesley Professional 2003。

⁵ Len Bass，Paul Clements 和 Rick Kazman，軟件架構(gòu)實踐，第二版。Addison Wesley 2003。

⁶ 對象管理組織，OMG 統(tǒng)一建模語言規(guī)格 1.5版，文檔號 03-03-01。2003年三月。

⁷ James McGovern等，企業(yè)架構(gòu)的實踐指南。Prentice Hall 2004

⁸ 一個在本系列的后續(xù)文章中所涵蓋的角色。

⁹ Mary Shaw 和 David Garlan，軟件架構(gòu) -- 關(guān)于一個正在形成的學(xué)科的觀察。 Prentice Hall 1996，

¹⁰ Grady Booch，James Rumbaugh 和 Ivar Jacobson，統(tǒng)一建模語言用戶指南。Addison Wesley 1999。

¹¹ Bass 等，前面引用的書。

¹² IEEE Computer Society，IEEE 信息技術(shù)標(biāo)準(zhǔn) －－軟件生命周期過程。IEEE 標(biāo)準(zhǔn) 12207-1995。

¹³ Murray Cantor，“系統(tǒng)工程的Rational統(tǒng)一過程”。The Rational Edge，2003年八月。 http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/aug03/f_rupse_mc.pdf