《面向對象軟體工程——使用UML、模式與Java（第2版）》是2007年清華大學出版社出版的圖書，作者是Bernd Bruegge等。
基本介紹
- 書名：面向對象軟體工程——使用UML、模式與Java（第2版）
- 作者：Bernd Bruegge等著，葉俊民等譯
- ISBN：9787302135548
- 定價：69元
- 出版時間：2007-12-6
- 裝幀：平裝
編輯推薦,前言,圖書目錄,
編輯推薦
B.Bruegge和A.H.Doutoit編寫的《面向對象軟體工程——使用UML、模式和Java》（第2版），是卡耐基·梅隆大學（CMU）高年級本科生和研究生的教材，是我所能見到的各類軟體工程教材中最棒的一本，例如：“業餘軟體工程師總在尋找奇蹟——試圖用某種驚人的方法或工具來讓軟體開發變得輕而易舉，但職業軟體工程師都知道不存在這種靈丹妙藥”，“有兩條構造軟體設計的原則：其一是使設計足夠簡單，以至於不存在明顯的缺陷；其二是使系統足夠複雜，以至不存在明顯的缺陷”等，這些充滿哲理的話，總能給人以啟發。
前言
高達8 611米的K2山峰高高地聳立在西喜馬拉雅山的喀喇崑崙山脈上，它是世界上第二高的山峰，被認為是高度在8000米以上最難攀登的山峰。對K2山峰的探險，即便是在天氣最適宜的夏季，通常也要連續用上幾個月時間。而且，即使在夏季，暴風雪天氣也是會非常頻繁出現的。進行一次登山探險活動，通常需要數千磅的設備，這些設備包括攀登齒鏈、抵禦惡劣天氣的防護裝備、帳篷、食物、通信工具和支付給數以百計的搬運工的薪水和鞋子。策劃這樣一次探險性登山活動，需要花費一個登山者大量的時間，需要數十個後援者協助。一旦開始攀登，很多難以預料的突發事件，如雪崩、工人罷工和設備故障等，將迫使登山者調整原有計畫、找出解決問題的新辦法或者決定回撤。目前，對K2山峰的探險成功率不到40%。
美國國家空間系統（National Airspace System，NAS）監管並控制著美國的空中交通。NAS擁有18 300多個航空站點、21個空中交通控制中心和460餘個控制塔。這些站點和中心所擁有的設備總數總計超過34 000件，這些設備包括雷達系統、信息交換機、無線電收發設備、計算機系統和顯示設備等。當前的基礎設施老化得很快。例如，支持21個空中交通的控制中心的計算機系統是20世紀80年代早期購買的IBM 3083大型機。從1996年起，美國政府啟動了一個項目來更新NAS基礎設施，以使之現代化，這一更新計畫包括改善衛星導航系統、改善數字控制器以及飛行員通信系統，並且在空中線路控制、飛機著陸順序安排、飛機駛離和駛向跑道時所涉及的地面交通控制等方面實現更高程度的自動化。但是，想讓如此複雜系統的基礎設施現代化，只能循序漸進地工作。因此，當引入具有新功能的設備時，仍要支持原有設備的正常運轉。例如，在這一過渡時期內，控制器將不得不同時具有模擬和數字兩種聲音通道，以實現與飛行員的通信。最後，NAS的現代化和全球空中交通同時發生巨大增長，後者預計在未來10～15年後，會成倍增長。被稱為“先進自動化系統（Advanced Automation System，AAS）”的NAS的最初現代化嘗試，因存在與軟體相關問題，在開始時延誤幾年以及在花費上超出預算數十億美元後，於1994年被 取消。
上面的兩個實例所討論的均是複雜系統，在此，外部條件將引發意想不到的變化。問題的複雜性超出了任何人可以控制的範疇。變化使得參與者放棄常用的方法而創造新的解決方案。在上述兩個實例中，有多名參與者要求進行合作，以開發出新的技術來對付這些挑戰。因為，如果不這樣做，我們將無法達到目標。
本書就是關於如何處理複雜且不斷變化的軟體系統的。
主題
套用域（登山計畫、空中交通控制、金融系統以及文字處理等）通常包括很多軟體開發者不熟悉的概念。而解決方案域（用戶界面工具包、無線通信、中間件、資料庫管理系統、交易處理系統和可損耗的計算機系統等）則通常是不成熟的，而且會給開發者帶來很多具有競爭性的實現技術。因此，系統和開發項目都是複雜的、涉及到很多不同的構件、工具、方法和人員。
當開發者對用戶的套用域有了更多的理解之後，他們將更新系統需求。當開發者對正在出現的技術或者對現行技術的缺陷有了更多了解之後，他們會調整系統的設計和實現。當質量控制發現系統中的缺陷，以及用戶要求增加新功能時，開發者將修改系統及其相關的產品，從而導致不斷變化。
複雜性和不斷發生的變化，代表了這樣一些挑戰：它們使得任何個人都不可能去控制系統及其演化。即使目標就在眼前，如果控制不恰當，複雜性和不斷的變化也將使得解決方案在宣布之前就會流產。如果對套用域的理解存在過多錯誤，會使得出台的解決方案對用戶毫無用途，從而不得不返工。不成熟或不兼容的實現技術，會造成系統的穩定性變差，以及系統被延遲交付。處理不了變化，將帶來新的系統缺陷，從而使得系統性能降低到無法使用的程度。
本書反映了作者十多年來構造系統，以及教授軟體工程課程的體會。我們發現，學生常常孤立地學習程式設計技術和軟體工程技術，常常選擇小的問題作為研究用例。所帶來的結果是，學生們能夠有效地解決定義明確的問題，但當他們第一次真正面對複雜而真實的開發項目時，常常會感到束手無策。真實的開發過程需要很多不同的技術和工具，要求方方面面的人員進行合作。針對這種情況，現今的軟體工程本科課程體系中通常包括一門軟體工程項目管理的課程，講授組織成一個開發項目所必須的知識。
工具：UML、Java和設計模式
編寫本書時，在我們的頭腦中一直有一個項目課程。這個項目除了可以作為課程設計的項目外，還可以在其他場合中使用，如短期集訓或者短期研發（R&D）項目等。我們使用了真實系統中的實例，並檢驗UML（Unified Modeling Language）、基於Java的技術、設計模式、設計原理、配置管理以及質量控制等現代技術之間的互動。此外，我們討論了與項目管理相關的問題，這些問題與上述技術及其對複雜性和變化的影響有關。
原則
我們遵循如下5個原則來進行軟體工程教學：
實踐經驗。我們認為軟體工程教學必須與實踐結合起來。學生只有參與開發一個複雜系統（即一個沒有任何學生能完全理解的系統），才能理解複雜性。
問題的解決。在我們看來，軟體工程教學必須建立在解決實際問題之上。因此，沒有絕對正確或絕對錯誤的解決方案，只有文檔標準相對做得比較好的解決方案和做得比較差的解決方案。儘管我們檢驗了現有的解決實際問題的方法並鼓勵重用（reuse）這些方法，但同時我們也鼓勵對標準解決方案的批評與改進。
有限資源。如果擁有充足的時間和資源，我們將能夠建立起理想的系統。這樣系統的建立存在一些問題。首先，這一想法是不現實的。其次，即使在開發過程中具有足夠的資源，如果最初要解決的問題在開發過程中很快發生了變化，那么我們最終將交付一個解決了錯誤問題的系統。因此，我們有必要假設問題的解決過程在資源方面受到限制。同時，我們強烈地意識到資源的缺乏將促使開發者使用基於構件的開發方法、重用知識、設計方案和編碼。換句話說，我們將支持用工程方法進行軟體開發。
跨學科性。軟體工程是一個跨學科的領域。軟體工程涉及電子工程、計算機工程、計算機科學、商務管理、圖形設計、工業設計、建築學、戲劇與寫作等領域的知識。軟體工程是一個套用領域。當試圖理解並對套用域進行建模時，開發者與其他（包括用戶和客戶在內的）人員進行定期溝通，他們中的一些人對軟體開發知之甚少。這將要求我們從多個角度、使用多種術語來看待和處理系統。
溝通。即使開發者僅僅為開發而建構軟體，開發者仍然需要在其內部之間進行溝通。作為開發者，我們不能只限於與同行進行溝通，還需要討論被選方案、闡述解決方案、探討折中的解決方案，以及了解和評價其他人的工作。大量軟體工程項目的失敗都可歸咎於信息表達不準確，以及信息的遺失。我們必須學會與所有項目參與者進行溝通，這其中最重要的參與者就是客戶和最終用戶。
上述5項原則是本書的基礎。這些原則將鼓勵並使得讀者能夠使用符合實際的、現代的解決方案來解決複雜和不斷變化的問題。
關於本書
本書的基礎是套用於軟體工程的面向對象技術。本書既不是一本探討所有可能方法的軟體工程概論圖書，也不是一本關於算法和數據結構的程式設計圖書。相反地，我們將重點放在一定範圍的技術上，並且在適度複雜的環境中解釋這些技術的套用，例如一個包含20～60個參與者的多組開發項目。因此，本書也反映了我們本身的偏好、實力和弱點。儘管如此，我們仍然希望所有的讀者都能夠從本書中找到他們所需要的東西。本書共有16章，分為3個部分，可作為一個學期的教學課程。
第1部分“開始”包含3章。在這部分中，我們將重點介紹軟體工程環境中開發者所必須具備的基本技能。
* 第1章“軟體工程導論”，描述了程式設計和軟體工程之間的差異、本學科當前 存在的挑戰，以及本書中將用到的概念的基本定義。
* 第2章“使用UML建模”，描述了面向對象技術中所用到的建模語言UML的基本組成。我們將建模作為一項複雜性處理技術提出來。本章將教會讀者如何閱讀和理解UML圖。在隨後的章節中，我們將講授如何創建UML圖來對系統的不同方面進行建模。在全書中，我們使用UML為多種不同的產品進行建模：從軟體系統到軟體過程和工作產品（work product）等。
* 第3章“項目組織和溝通”，我們介紹了項目組織和溝通的基本概念。開發者和管理者將一半以上的時間花在與其他人溝通上，所使用的溝通方法主要是面對面進行溝通，以及通過E-mail、群件、電視會議或書面檔案等方式進行溝通。建模用於處理複雜性，溝通則用於處理變化。本章我們將描述項目組織以及探討如何才能進行有效的溝通。
第2部分“複雜性處理”，在這部分中，我們將集中探討那些有助於開發者詳細說明、設計和實現複雜系統的技術和方法。
* 第4章“需求獲取”，第5章“分析”。這兩章從用戶角度描述了系統定義。在需求獲取的過程中，開發者決定用戶所需求的功能，以及實現這一功能的可行方法。在分析階段，開發者將上述知識形式化，並保證其完整性和一致性。在此，我們主要討論如何使用UML來處理套用域的複雜性。
* 第6章“系統設計：分解系統”，第7章“系統設計：關於設計目標”。這兩章從開發者角度出發，對系統進行了定義。在這一階段，開發者使用了設計目標和子系統分解的形式定義系統的結構。開發者探討了全局性問題，如：系統到硬體的映射、持久數據的存儲以及全局控制流等。我們將在開發者如何使用體系結構風格、構件以及UML來處理解決方案域的複雜性方面進行集中討論。
* 第8章“對象設計：重用範式解決方案”、第9章“對象設計：接口規格說明”和第10章“將模型映射到代碼”描述了與解決方案域相關的具體建模活動和構建活動。在這一階段，開發者找出並調整設計模型和框架以實現某些子系統。他們使用一些約束語言，如UML對象約束語言（Object Constraint Language）來精化和精確說明類接口。最後，開發者將詳細的對象設計模型映射到原始碼和資料庫框架。
* 第11章“測試”。在這一章里，我們將描述對照系統模型對系統行為的驗證。通過測試可以發現系統中的錯誤，包括那些系統發生變化時以及系統需求發生變化時產生的錯誤。測試活動包括單元測試、集成測試和系統測試。我們將介紹幾種測試技術，包括：白盒測試、黑盒測試、基本路徑測試、基於狀態的測試和檢查，並討論這些技術在面向對象系統中的套用。
第3部分 “管理更改”。在這一部分中，我們將集中討論在整個系統開發中支持變化的控制、評價以及實現的方法和技術。
* 第12章“基本原理管理”。這一章描述了設計決策的獲取，以及對這些設計決策的論證。我們針對需求獲取、分析和系統設計這3個階段所開發出來的模型，就一個系統應該做什麼和應該如何去做，提供了不同的視點，這將有助於複雜問題的處理。為了能夠處理變化，我們也需要知道系統為什麼是這樣的。設計決策的獲取、可選方案的評估，以及對這些方案的論證，使我們得以了解系統的基本原理。
* 第13章“配置管理”。在這一章中，我們描述了對項目發展過程進行建模的技術和工具。配置管理有助於我們對變化進行處理，這樣就補充了基本原理。版本管理記錄了系統開發的進程。發布管理保證了一次發布過程中的各個構件的質量，以及這些構件之間的一致性。變化的管理，保證了對系統的修改始終與項目目標相一致。
* 第14章“項目管理”。這一章描述了一些在啟動軟體開發項目、跟蹤項目進度以及處理所遇到的危險和意外事件中所必需的技術。我們主要關注那些有助於大批參與者按照計畫合作並交付高質量系統所涉及的組織、角色和管理活動。
* 第15章“軟體生命周期”。這一章描述了軟體的生命周期，例如Boehm的螺旋模型和統一的軟體開發過程，並提供了開發活動的抽象模型。在這一章中，我們還討論了能力成熟度模型，該模型用來評價相關開發組織的成熟度。
* 第16章“方法學：綜合考慮各種因素”。這一章描述了將上述章節中所描述的內容套用於具體情況的方法學和啟發式準則。無論需求獲取做得怎樣徹底，也無論計畫做得多么詳細，任何規模的實際項目都將遇到未知的事件和變化。不確定性處理使得實際項目和系統與我們在書本上了解到的項目和系統差別極大。在本章中，我們介紹了很多不同的方法學，討論了每一個項目中需要解決的問題，提出了3個實際項目的實例分析。
上面這些主題是密切相關的。為了強調這一點，我們選擇了一種重複的方法。每章都由5節組成。第1節用一個實例介紹與主題相關的問題。第2節簡要描述了與這些主題相關的活動。第3節通過一些簡單的實例來解釋主題的基本概念。第4節使用真實系統中的例子來詳細講解主要技術活動。最後，我們講述管理活動並討論典型的折中方案。從第4～第10章，我們對一個稱為競技場的複雜多用戶遊戲管理系統進行了實例分析，通過越來越複雜的實例來重複和詳述同一個概念，我們希望讀者能夠獲得面向對象軟體工程的實際知識。
課程
構造一個大型、複雜系統可以比作攀登一座大山。有了路線描述固然不錯，但路線將永遠不會完全被勾畫出來，因為新的意外會隨時會出現。儘管我們在本書中規劃了軟體工程知識，變化還會發生，而我們現在所堅信的方法學也會變得過時。
怎樣教會我們的學生去處理這類快速變化的情況？對我們而言，最重要的是我們不僅應該向學生傳授必要的知識，而且還應該教會他們應對、處理危機的能力。儘管研究路線描述是明智的，但是沒有什麼能夠取代在這條路線上進行實際旅行的經驗。
本書是為本科畢業班的學生和研究生編寫的，適合作為一個學期的軟體工程課程的教材。學生應該具有一定的使用C、C++、C#或Java進行編程的能力。我們希望學生具有必要的解決問題的技能以解決技術問題，但無須具備接觸過系統開發中常見複雜多變情況的經驗。此外，本書也可以用於支持其他類型的課程，例如短期密集的專業課程培訓等。
項目和高級課程
一門項目課程應包括本書中的所有章節，大多應按順序講授。教師可以考慮在介紹課程時，提前介紹第14章中的項目管理概念，以讓學生熟悉如何制定計畫和控制狀況。
介紹性課程
一門有作業的介紹性的課程應該把重點集中在每一章的前3節上。第4節以及實例分析可以用做作業材料，也可以通過使用紙制UML圖表、文檔和編碼來模擬構造一個小型系統。
短期技術課程
本書也可以用來作為短期且密集的專業培訓指導。一門技術性課程，其重點在於UML和面向對象的方法方面，所涉及的部分章節按順序為第1、2、4、5、6、7、8、9、10和第11章，包括了從需求獲取到測試的所有開發階段。高級課程還應該包含第12章“基本原理管理”和第13章“配置管理”。
短期管理課程
本書還可以用作面向管理者的短期密集培訓課程。管理課程的重點集中在溝通、風險管理、基本原理、成熟度模型和UML，可選用的章節按順序為第1、2、3、14、15、16、12和第13章。
與第1版的不同之處
本書的第2版源於一個充分限定範圍的項目。我們的目標是增加兩個新章節和一個實例分析，作為對我們從本書的第1版讀者處收到的反饋意見的回應。完成這項工作用了近一年時間。
然而兩年後，我們寫了4個新章節並對現存章節進行了全面審視。在增加細節實例、跟上軟體工程的最新發展、保持本書的一致性和滿足進度表之間，我們決定在進度表上進行讓步。我們希望最後產品的質量能夠反映出這一延遲的決策是值得的。感謝我們的出版商Alan Apt，感謝他的無限耐心。在本書中，我們所做的改變如下：
* 貫穿全書的實例分析。我們收到了很多讀者的請求，他們要求有一個貫穿全書的實例，使得各個章節之間的關係變得顯而易見。因此，我們將ARENA作為貫穿全書的實例，它將出現在所有技術章節中。
* 擴展了對象設計資料。我們擴展了設計模式的覆蓋範圍並加強了與重用相關的所有材料，這一擴展體現在第8章這一新章節的組成上。同樣，我們從概念和實例兩個方面擴展了OCL（Object Constraint Language，對象約束語言）的覆蓋範圍，並將這一材料包含在第9章這一新章節中。在上述做法中，我們一直避免將本書寫成參考手冊，而將重點放在提供有關這些概念套用方面的知識上。
* 擴展了選擇實現活動的範圍。我們發現很多學生開始很難將新資料的內容（例如，需求工程、UML建模）與他們已經理解的概念（例如，程式設計）聯繫起來。為了解決這一問題，我們擴展了本書的範圍，包括了精選的關於實現的主題。在第10章這一新章節中，我們描述了怎樣將模型映射到原始碼。
* 項目管理和軟體生命周期資料的重新組織。軟體工程課程常常將項目管理和軟體生命周期主題放在一起處理，並在本課程的一開始就進行討論，從而導致了軟體工程自頂向下的教學方法。根據經驗，我們發現如果學生沒有接觸過大型項目中所固有的問題，那么上述內容很難為學生們所理解。因此，我們選擇了自底向上的教學方法，通過在越來越廣的範圍里、越來越多地反覆觸及這些內容，以使得學生逐步掌握其內容。在本課程的前面章節中，如第3章只關注從開發者的角度看項目管理的基本概念。在第14章中，我們從初任項目經理的角度再次回顧並擴展了這些概念。一旦項目管理中的問題理解清楚之後，在第15章中，我們將把重點放在軟體生命周期問題和怎樣通過項目傳遞過程的知識上面。第14章和第15章從理想化和學術角度對待這一主題。為了在理想主義與現實主義之間尋求平衡點，我們在第16章中討論了實際項目所面臨的方法學問題。
關於作者
Bernd Bruegge博士曾經在卡耐基·梅隆大學（CMU）研究並教授軟體工程課程，期間歷時20年之久，在CMU，Bruegge獲得了碩士和博士學位。Bruegge博士還獲得了德國漢堡大學的畢業證書。目前，Bruegge博士是慕尼黑工業大學計算機科學系的教授，並負責教授軟體工程，同時，Bruegge博士還是CMU的客座教授。本書中的內容，是Bruegge博士以書本形式和網路教育形式所進行的面向對象軟體工程課程教學的內容，這些內容的收集與使用有長達15年的歷史。Bruegge博士於1995年在CMU獲得Herbert A.Simon的教學優秀獎。Bruegge博士還是一位國際顧問，他使用了本書中介紹的技術，設計並實現了很多套用系統，在這裡列舉一小部分：DaimlerChrysler工程反饋系統、美國環境保護處的環境建模系統、市警察局的事故管理系統等。
Allen Dutoit博士是慕尼黑工業大學的研究人員。Allen Dutoit博士在CMU獲得了碩士和博士學位，在Lausanne的瑞士洛桑聯邦技術學院獲得過畢業證書。從1993年開始，Allen Dutoit博士與Bruegge教授一起，在CMU和慕尼黑工業大學教授軟體工程課程，在這期間他們使用並完善了本書中所用的描述方法。Allen Dutoit博士的研究領域包含了軟體工程和面向對象系統的多個方面，涉及需求工程、基本原理管理、分布開發系統和基於原型開發的系統等。Allen Dutoit博士曾經是CMU軟體工程學會和複雜工程系統學會的會員。
圖書目錄
前言 III
序言 V
致謝 XIII
第1部分 開 始
第1章 軟體工程導論 2
1.1 導言：軟體工程的失誤 2
1.2 什麼是軟體工程 3
1.2.1 建模 4
1.2.2 問題解決 5
1.2.3 知識獲取 6
1.2.4 基本原理 6
1.3 軟體工程概念 7
1.3.1 參與者和角色 8
1.3.2 系統和模型 8
1.3.3 工作產品 9
1.3.4 活動、任務和資源 9
1.3.5 功能性需求和非功能性需求 10
1.3.6 符號、方法和方法學 10
1.4 軟體工程開發活動 11
1.4.1 需求獲取 11
1.4.2 分析 11
1.4.3 系統設計 13
1.4.4 對象設計 13
1.4.5 實現 14
1.4.6 測試 14
1.5 管理軟體開發 14
1.5.1 溝通 15
1.5.2 基本原理管理 15
1.5.3 軟體配置管理 16
1.5.4 項目管理 16
1.5.5 軟體生命周期 16
1.5.6 總結 16
1.6 競技場實例分析 17
1.7 推薦讀物 18
1.8 練習 18
參考文獻 19
第2章 使用UML建模 21
2.1 導言 21
2.2 UML綜述 22
2.2.1 用例圖 22
2.2.2 類圖 23
2.2.3 互動圖 24
2.2.4 狀態圖 24
2.2.5 活動圖 25
2.3 建模活動中的概述 26
2.3.1 系統、模型和視圖 26
2.3.2 數據類型、抽象數據類型和
實例 28
2.3.3 類、抽象類和對象 28
2.3.4 事件類、事件和訊息 30
2.3.5 面向對象建模過程 31
2.3.6 偽證和原型構造 32
2.4 UML的深入透視 33
2.4.1 用例圖 33
2.4.2 類圖 39
2.4.3 互動圖 46
2.4.4 狀態圖 48
2.4.5 活動圖 50
2.4.6 圖的組織 52
2.4.7 圖的擴展 54
2.5 推薦讀物 55
2.6 練習 55
參考文獻 57
第3章 項目組織和溝通 58
3.1 引言：一個關於火箭的例子 58
3.2 項目綜述 59
3.3 項目組織的綜述 62
3.3.1 項目組織 62
3.3.2 角色 64
3.3.3 任務和工作產品 66
3.3.4 進度表 68
3.4 項目溝通綜述 69
3.4.1 計畫內的溝通 69
3.4.2 計畫外的溝通 74
3.4.3 溝通機制 76
3.5 組織活動 81
3.5.1 加入一個項目組 82
3.5.2 加入溝通基層組織 82
3.5.3 參加項目組情況通氣會議 83
3.5.4 組織客戶和項目總結 85
3.6 推薦讀物 86
3.7 練習 86
參考文獻 88
第2部分 處理複雜性
第4章 需求獲取 90
4.1 導言：可用性實例 90
4.2 需求獲取綜述 91
4.3 需求獲取概念 92
4.3.1 功能性需求 93
4.3.2 非功能性需求 93
4.3.3 完整性、一致性、清晰性和
正確性 95
4.3.4 現實性、確認性和可追蹤性 95
4.3.5 綠地工程、再工程和界面工程 96
4.4 需求獲取活動 96
4.4.1 標識參與者 97
4.4.2 標識場景 98
4.4.3 標識用例 100
4.4.4 求精用例 102
4.4.5 標識參與者和用例之間的
關係 104
4.4.6 標識初始分析對象 107
4.4.7 標識非功能性需求 108
4.5 需求獲取管理 110
4.5.1 與客戶協商規格說明：聯合
套用設計 110
4.5.2 追蹤性維護 112
4.5.3 需求獲取的文檔化 112
4.6 競技場實例分析 114
4.6.1 初始問題描述 114
4.6.2 標識參與者和場景 115
4.6.3 標識用例 119
4.6.4 求精用例與標識關係 121
4.6.5 標識非功能性需求 125
4.6.6 獲得的教訓 126
4.7 推薦讀物 126
4.8 練習 127
參考文獻 128
第5章 分析 130
5.1 導言：光幻影 130
5.2 分析概述 131
5.3 分析的概念 132
5.3.1 分析對象模型和動態模型 132
5.3.2 實體、邊界和控制對象 133
5.3.3 泛化和特化 134
5.4 分析活動：從用例到對象 135
5.4.1 標識實體對象 135
5.4.2 標識邊界對象 137
5.4.3 標識控制對象 139
5.4.4 使用順序圖將用例映射成對象 139
5.4.5 使用CRC卡建模的對象之間
的互動 143
5.4.6 標識關聯 143
5.4.7 標識聚集 145
5.4.8 標識屬性 146
5.4.9 建模單一對象狀態相關的行為 147
5.4.10 建模對象之間的繼承關係 148
5.4.11 分析模型回顧 148
5.4.12 分析小結 150
5.5 分析管理 151
5.5.1 將分析文檔化 151
5.5.2 分配責任 152
5.5.3 對分析的溝通 153
5.5.4 分析模型的疊代 154
5.5.5 客戶發出的結束信息 155
5.6 競技場實例分析 156
5.6.1 標識實體對象 157
5.6.2 標識邊界對象 160
5.6.3 標識控制對象 161
5.6.4 對象之間互動的建模 161
5.6.5 評價和加固分析模型 164
5.6.6 獲得的教訓 166
5.7 推薦讀物 166
5.8 練習 167
參考文獻 168
第6章 系統設計：分解系統 170
6.1 導言：一個平面規劃的例子 170
6.2 系統設計概述 172
6.3 系統設計概念 172
6.3.1 子系統與類 173
6.3.2 服務與子系統接口 174
6.3.3 耦合與內聚 174
6.3.4 分層與劃分 177
6.3.5 體系結構風格 180
6.4 系統設計活動：從對象到子系統 186
6.4.1 出發點：線路規劃系統的分析
模型 186
6.4.2 明確設計目標 188
6.4.3 明確子系統 190
6.5 推薦讀物 192
6.6 練習 193
參考文獻 194
第7章 系統設計：貫徹設計目標 195
7.1 介紹：一個冗餘系統的例子 195
7.2 系統設計活動概述 196
7.3 概念：UML部署圖 197
7.4 系統設計活動：貫徹設計目標 198
7.4.1 將子系統映射到處理器和
構件 199
7.4.2 標識並存儲持久性數據 201
7.4.3 提供訪問控制 203
7.4.4 設計全局控制流 208
7.4.5 標識邊界條件 210
7.4.6 評審系統設計 212
7.5 系統設計管理 214
7.5.1 系統設計文檔化 214
7.5.2 分配責任 215
7.5.3 系統設計交流 216
7.5.4 系統設計疊代 217
7.6 競技場實例分析 218
7.6.1 標識設計目標 218
7.6.2 標識子系統 219
7.6.3 將子系統映射到處理器和構件 221
7.6.4 標識並存儲持久性數據 222
7.6.5 提供訪問控制 223
7.6.6 設計全局控制流 224
7.6.7 標識邊界條件 225
7.6.8 課程小結 227
7.7 推薦讀物 227
7.8 練習 228
參考文獻 229
第8章 對象設計：重用模式解決
方法 230
8.1 導言：挫折 230
8.2 對象設計概述 232
8.3 重用的概念：解決方案對象、繼承和
設計模式 234
8.3.1 套用對象和解決方案對象 235
8.3.2 說明繼承和實現繼承 235
8.3.3 授權 237
8.3.4 Liskov替換準則 238
8.3.5 設計模式中的授權和繼承 238
8.4 重用活動：選擇設計模式和構件 240
8.4.1 使用橋樑模式封裝數據存儲 242
8.4.2 使用適配器模式封裝可繼承
構件 243
8.4.3 使用策略模式封裝上下文 245
8.4.4 使用抽象工廠模式封裝平台 247
8.4.5 使用命令模式封裝控制流 249
8.4.6 使用合成設計模式封裝層次 249
8.4.7 選擇設計模式的啟發式準則 251
8.4.8 標識和調整套用框架 252
8.5 管理重用 255
8.5.1 對重用進行文檔編輯 257
8.5.2 分配責任 258
8.6 競技場實例分析 258
8.6.1 使用抽象工廠設計模式 259
8.6.2 使用命令設計模式 260
8.6.3 使用觀察者設計模式 261
8.6.4 課程回顧 262
8.7 推薦讀物 262
8.8 練習 263
參考文獻 264
第9章 對象設計：接口規格說明 266
9.1 導言：一個鐵路的例子 266
9.2 接口規格說明概述 268
9.3 接口規格說明概念 269
9.3.1 類實現者、類擴展者和類
使用者 269
9.3.2 類型、簽名和可見性 270
9.3.3 契約：不變式、前置條件和
後置條件 271
9.3.4 對象約束語言 273
9.3.5 OCL收集：集合、包和序列 276
9.3.6 OCL量詞：全稱量詞forAll和
存在量詞exists 279
9.4 接口規格說明活動 280
9.4.1 標識遺漏的屬性和操作 280
9.4.2 說明類型、簽名和可見性 282
9.4.3 說明前置條件和後置條件 283
9.4.4 說明不變式 285
9.4.5 繼承契約 286
9.5 管理對象設計 288
9.5.1 對象設計文檔化 289
9.5.2 分配責任 293
9.5.3 在需求分析中使用契約 294
9.6 競技場實例分析 294
9.6.1 標識在聯賽方式（TournamentStyle）和回合（Round）中遺漏的
操作 295
9.6.2 定義說明聯賽方式（Tournament- Style）和回合（Round）
中的契約 296
9.6.3 定義說明淘汰賽方式（KnockOut- Style）和淘汰回合（KnockOut- Round）契約 298
9.6.4 課程回顧 300
9.7 推薦讀物 300
9.8 練習 301
參考文獻 302
第10章 將模型映射到代碼 304
10.1 導言：一個關於書的例子 304
10.2 映射的概述 306
10.3 映射的概念 306
10.3.1 模型轉換 307
10.3.2 重構 308
10.3.3 正向工程 309
10.3.4 逆向工程 310
10.3.5 轉換準則 311
10.4 映射活動 311
10.4.1 最佳化對象設計模型 312
10.4.2 將關聯映射到集合 314
10.4.3 將契約映射到異常 320
10.4.4 將對象模型映射到持久存
儲模式 323
10.5 管理實現 328
10.5.1 編寫轉換文檔 328
10.5.2 分配責任 329
10.6 競技場實例分析 329
10.6.1 競技場中的統計類
（Statistics） 330
10.6.2 將關聯映射到集合 332
10.6.3 將契約映射到異常 333
10.6.4 將對象模型映射到資料庫
模式 335
10.6.5 課程回顧 336
10.7 推薦讀物 336
10.8 練習 337
參考文獻 338
第11章 測試 339
11.1 導言：測試太空梭 339
11.2 測試概述 341
11.3 測試概念 344
11.3.1 故障、錯誤狀態和失敗 345
11.3.2 測試用例 347
11.3.3 測試樁和測試驅動 348
11.3.4 更正 349
11.4 測試活動 350
11.4.1 構件檢查 350
11.4.2 可用性測試 351
11.4.3 單元測試 352
11.4.4 集成測試 359
11.4.5 系統測試 364
11.5 管理測試 369
11.5.1 制定測試計畫 369
11.5.2 編寫測試文檔 370
11.5.3 分配責任 372
11.5.4 回歸測試 373
11.5.5 使測試自動化 374
11.6 推薦讀物 375
11.7 練習 375
參考文獻 377
第3部分 管 理 更 改
第12章 基本原理管理 380
12.1 導言：將火腿切成薄片 380
12.2 基本原理概述 381
12.3 基本原理概念 383
12.3.1 集中式的交通控制 384
12.3.2 定義問題：問題 385
12.3.3 探索求解空間：提議 386
12.3.4 評價求解空間：標準和
討論 387
12.3.5 使求解空間崩潰：解決方案 389
12.3.6 執行解決方案：活動項 390
12.3.7 基於問題的模型和系統
實例 390
12.4 基本原理的活動：從問題到決策 394
12.4.1 CTC系統設計 394
12.4.2 在會議中獲取基本原理 395
12.4.3 異步獲取基本原理 401
12.4.4 在討論變化的時候獲取
基本原理 402
12.4.5 重新構造基本原理 405
12.5 管理基本原理 406
12.5.1 將基本原理文檔化 407
12.5.2 分配責任 408
12.5.3 關於基本原理交流的
啟發式規則 409
12.5.4 問題的建模和協商 409
12.5.5 衝突解決策略 411
12.6 推薦讀物 412
12.7 練習 412
參考文獻 413
第13章 配置管理 415
13.1 導言：一個飛機的實例 415
13.2 配置管理概述 417
13.3 配置管理概念 418
13.3.1 配置項和CM聚集 419
13.3.2 版本和配置 419
13.3.3 變化請求 420
13.3.4 升級和發布 421
13.3.5 倉庫和工作空間 421
13.3.6 版本標識方案 421
13.3.7 變化和變化集 423
13.3.8 配置管理工具 425
13.4 配置管理活動 425
13.4.1 配置項和CM聚集標識 427
13.4.2 升級管理 429
13.4.3 發布管理 430
13.4.4 分支管理 432
13.4.5 不同版本管理 435
13.4.6 變更管理 437
13.5 對配置管理的管理 438
13.5.1 配置管理的文檔化 439
13.5.2 分配配置管理任務 439
13.5.3 計畫配置管理活動 440
13.6 推薦讀物 440
13.7 練習 441
參考文獻 442
第14章 項目管理 443
14.1 介紹：STS-51L發射決定 443
14.2 項目管理概述 445
14.3 項目管理概念 449
14.3.1 任務和活動 450
14.3.2 工作產品、工作包和角色 451
14.3.3 工作分解結構 451
14.3.4 任務模型 452
14.3.5 技能矩陣 453
14.3.6 組織 454
14.3.7 可視組織結構 455
14.3.8 組織結構圖譜 456
14.3.9 軟體項目管理計畫 457
14.4 項目管理活動 459
14.4.1 計畫項目 460
14.4.2 組織項目 463
14.4.3 控制項目 467
14.4.4 終結項目 472
14.5 推薦讀物 472
14.6 練習 473
參考文獻 474
第15章 軟體生命周期 476
15.1 導言：玻利尼西亞航行 476
15.2 IEEE 1074：開發軟體生命周期
過程的標準 479
15.2.1 過程與活動 479
15.2.2 軟體生命周期建模 481
15.2.3 項目管理 481
15.2.4 前期開發 482
15.2.5 開發過程 482
15.2.6 後期開發 483
15.2.7 整體過程（交叉開發
過程） 483
15.3 評價軟體生命周期模型的成熟度 484
15.4 生命周期模型 486
15.4.1 以順序活動為中心的模型 487
15.4.2 以疊代活動為中心的模型 488
15.4.3 以實體為中心的模型 492
15.5 推薦讀物 495
15.6 練習 495
參考文獻 496
第16章 方法學：綜合考慮各種
因素 497
16.1 導言：首次攀登喬戈里峰（K2峰） 497
16.2 項目環境 500
16.3 方法學問題 501
16.3.1 做多少計畫 502
16.3.2 多大程度上的重用 502
16.3.3 構建多少模型 503
16.3.4 過程分為幾步 504
16.3.5 多大程度上的控制和監控 505
16.3.6 什麼時候重定義項目目標 505
16.4 方法學領域 506
16.4.1 Royce方法學 506
16.4.2 極限編程 511
16.5 案例分析 514
16.5.1 XP項目：ATRACT 515
16.5.2 局部主客戶：FRIEND 517
16.5.3 分散式項目：JAMES 523
16.5.4 案例分析總結 528
16.6 推薦讀物 531
16.7 練習 532
參考文獻 532
第4部分 附 錄
附錄A 設計模式 536
A.1 抽象工廠（Abstract Factory）：
封裝平台 536
A.2 適配器（Adapter）：對遺留代碼的
包裝 537
A.3 橋樑（Bridge）：允許選擇性實現 538
A.4 命令（Command）：封裝控制流 538
A.5 組合（Composite）：表示遞歸的
層次結構 539
A.6 層面（Facade）：層面子系統 540
A.7 觀察器（Observer）：將實體從
視圖中分離出來 541
A.8 代理（Proxy）：封裝開銷大的對象 542
A.9 策略（Strategy）：封裝算法 543
A.10 選擇設計模式的啟發式準則 544
參考文獻 545
附錄B 術語表 546
參考文獻 570
XVI
面向對象軟體工程——使用UML、模式與Java（第2版）
XIX
目 錄
