面向對象分析與設計(第3版)（簡體書）

《面向對象分析與設計（第3版）》是UML創始人Grady Booch的代表作之一。全書分為理論和應用兩部分。理論部分深刻剖析了面向對象分析與設計（OOAD）的概念和方法。應用部分連續列出了5個不同類型、不同領域的應用，描述如何從初始階段到交付階段，將OOAD理論和方法應用到項目中。應用部分所涉及的領域包括系統架構、數據獲取、密碼分析、控制系統和Web開發，還給出了一些關於重要問題的有效建議，包括分類、實現策略和高性價比的項目管理。《面向對象分析與設計（第3版）》介紹的概念都基於牢固的理論基礎。同時，作者十分注重實效，基於其豐富的經驗，面向軟件工程實踐者的實際需要，提出了改進的對象開發方法，用於解決系統和軟件開發者面臨的複雜問題；運用大量例子說明了基本概念，解釋了方法，並展示了在不同領域的成功應用。書中的表示法採用最新的UML 2.0，因此本書是學習UML 2.0不可多得的參考書。本書非常適合實際系統和軟件的開發者、系統分析師或架構師、項目經理閱讀，也可以作為高等院校軟件工程和高級編程課程的教材使用。·

Grady Booch，在軟件架構、軟件工程和建模領域的創新工作是世界知名的。從1981年Rational公司創建開始，他就一直擔任該公司的首席科學家。Grady于2003年3月成為了IBM院士（IBM Fellow）。Grady是統一建模語言（UML）最早的開發者之一，也是幾個Rational產品的最早開發者之一。Grady曾擔任世界各地一些複雜的軟件密集型項目的架構師和架構指導者。Grady是6本暢銷書的作者，包括UML Users Guide和Object-Oriented Analysis with Applications。Grady發表了幾百篇有關軟件工程的技術文章，其中包括在20世紀80年代早期發表的文章，這些文章最先提出了面向對象設計的術語和實踐。他曾在世界各地演講和諮詢。Grady是美國計算機協會（ACM）、美國電氣電子工程師學會（IEEE）、美國科學促進會（AAAS）、有社會責任的計算機專家協會（CPSR）的成員。他是IBM院士、ACM院士、世界技術網絡院士，也是軟件開發論壇夢想家。Grady是敏捷聯盟、Hillside集團和軟件架構師世界學院的創始委員會成員，也是Northface大學的顧問委員會成員。Grady於1977年從美國空軍學院獲得學士學位，于1979年從加州大學聖巴巴拉分校獲得電子工程科學碩士學位。Grady與他的妻子和他的貓生活在科羅拉多。他的興趣包括閱讀、旅行、唱歌和彈奏豎琴。Robert A. Maksimchuk，是Unisys Chief Technology Office的一名研究主管。他關注新出現的建模技術，目的是提升Unisys 3D可視企業建模框架的戰略方向。Bob為這項任務帶來了不同行業的大量系統工程、建模、面向對象分析與設計的專業知識。他是UML for Mere Mortals和UML for Database Design的合著者，也寫了許多文章。他曾經周遊世界各地，在各種技術論壇上作為重要演講者發言，舉辦關於UML和面向對象開發的研討會和培訓。Bob是電氣電子工程師學會（IEEE）和國際系統工程學會（INCOSE）的成員。Michael W. Engle，是洛克希德馬丁公司的首席工程師。他有超過26年的技術和管理經驗--從項目啟動到運營支持，涵蓋了完整的系統開發生命週期。利用系統工程師、軟件工程師和系統架構師的背景，Mike運用了面向對象技術，為複雜的系統開發提供創新的開發方式。Bobbi J. Young， Ph.D.，是Unisys Chief Technology Office的一名研究主管。她有著多年的IT行業從業經驗，與商業公司和國防部合同供應商一同工作。Young博士是一名諮詢師，她在項目管理、企業架構、系統工程和面向對象分析與設計方面提供現場指導。在她的職業生涯中，她關注於系統生命週期過程和方法學，同時也關注企業架構。Young博士擁有生物學、計算機科學和人工智能學位，她獲得了管理信息系統的博士學位，也曾是美國海軍預備役的一名指揮官（已退伍）。Jim Conallen，是IBM Rational的模型驅動開發戰略小組的一名軟件工程師。在這個小組中，他積極參與，將對象管理集團（OMG）的模型驅動架構（MDA）計劃應用於IBM Rational的模型工具中。Jim在基於資產的開發和可複用資產規範（RAS）領域也很活躍。Jim經常在會議上演講，也經常寫文章。他的專業領域是Web應用開發。他開發了UML的Web應用擴展（WAE）。這是對UML的一種擴展，讓開發者能夠利用UML在合適的抽象和細節層面上對Web應用的架構進行建模。這項工作是IBM Rational Rose和Rational XDE Web Modeling功能的基礎。Jim與人合著了兩個版本的Building Web Applications with UML，第一個版本採用微軟公司的ASP技術，後一個版本採用J2EE技術。Jim的經驗也來自於加入Rational之前的工作，那時他曾是獨立的諮詢師、Peace Corps的志願者和大學講師。他還是3個孩子的父親。Jim從Widener大學獲得了計算機和軟件工程的學士學位和碩士學位。Kelli Houston是IBM Rational的IT諮詢專家。她是IBM內部方法的方法架構師，負責編寫方法並集成IBM的方法。除了方法架構師的角色，Kelli還在IBM內部領導Rational Method Composer（RMC）特別興趣小組（SIG）工作，為客戶和IBM內部諮詢師提供有效使用RMC方面的諮詢和現場指導服務。·

書中的表示法采用最新的UML2.0，因此《面向對象分析與設計(第3版)》是學習UML2.0不可多得的參考書。《面向對象分析與設計(第3版)》非常適合實際系統和軟件的開發者、系統分析師或架構師、項目經理閱讀，也可以作為高等院校軟件工程和高級編程課程的教材使用。
原著中所附“分類書目”可從http://www.broadview.com.cn/17389下載。

人類渴望得到精神上的寧靜、美學上的成就、家庭的安全、正義和自由。這一切都不能通過工業化的生產效率來直接滿足。但是，生產效率讓人們得到充足的物質享受，而不至于與匱乏苦苦斗爭。這為精神、美學和家庭事務贏得了時間，也使得社會能夠將一些特殊的技能賦予司法機構以及維護權利的機構。
作為計算機專業人員，我們努力地去構建能工作而且有用的系統：作為軟件工程師，我們面臨著在計算資源和人力資源有限的條件下創建復雜系統的任務。面向對象技術已經發展為管理許多不同種類的系統中內在復雜性的手段。對象模型已被證明是非常有力和統一的概念。

第1篇 概 念第1章 複雜性1.1 複雜系統的結構1.1.1 個人計算機的結構1.1.2 植物和動物的結構1.1.3 物質的結構1.1.4 社會機構的結構1.2 軟件固有的複雜性1.2.1 定義軟件複雜性1.2.2 為什麼軟件在本質上是複雜的1.3 複雜系統的5個屬性1.3.1 層次結構1.3.2 相對本原1.3.3 分離關注1.3.4 共同模式1.3.5 穩定的中間形式1.4 有組織和無組織的複雜性1.4.1 複雜系統的規範形式1.4.2 人在處理複雜性時的能力局限1.5 從混沌到有序1.5.1 分解的作用1.5.2 抽象的作用1.5.3 層次結構的作用1.6 複雜系統的設計1.6.1 作為科學和藝術的工程1.6.2 設計的含義1.7 小結第2章 對象模型2.1 對象模型的演進2.1.1 程序設計語言的換代2.1.2 第一代和第二代早期程序設計語言的拓撲結構2.1.3 第二代後期和第三代早期程序設計語言的結構2.1.4 第三代後期程序設計語言的結構2.1.5 基於對象和面向對象的程序設計語言的結構2.2 對象模型基礎2.2.1 面向對象編程2.2.2 面向對象設計2.2.3 面向對象分析2.3 對象模型要素2.3.1 抽象的意義2.3.2 封裝的意義2.3.3 模塊化的意義2.3.4 層次結構的意義2.3.5 類型的意義2.3.6 併發的意義2.3.7 持久的意義2.4 應用對象模型2.4.1 對象模型的好處2.4.2 開放式問題2.5 小結第3章 類與對象3.1 對象的本質3.1.1 什麼是對象，什麼不是對象3.1.2 狀態3.1.3 行為3.1.4 標識符3.2 對象之間的關係3.2.1 鏈接3.2.2 聚合3.3 類的本質3.3.1 什麼是類，什麼不是類3.3.2 接口和實現3.3.3 類的生命週期3.4 類之間的關係3.4.1 關聯3.4.2 繼承3.4.3 聚合3.4.4 依賴關係3.5 類與對象的互動3.5.1 類與對象的關係3.5.2 類與對象在分析和設計中的角色3.6 創建高品質的類與對象3.6.1 評判一種抽象的品質3.6.2 選擇操作3.6.3 選擇關係3.6.4 選擇實現3.7 小結第4章 分類4.1 正確分類的重要性4.1.1 分類的困難4.1.2 分類的增量和迭代本質4.2 確定類和對象4.2.1 經典方法和現代方法4.2.2 面向對象分析4.3 關鍵抽象與機制4.3.1 確定關鍵抽象4.3.2 識別機制4.4 小結第2篇 方 法第5章 表示法5.1 統一建模語言5.1.1 簡單歷史回顧5.1.2 模型與多重視圖5.1.3 圖分類5.1.4 在實踐中使用圖5.1.5 概念模型、邏輯模型和物理模型5.1.6 工具的角色5.1.7 面向對象開發的產品5.1.8 規模上的伸縮5.1.9 UML的語法和語義5.1.10 UML 2.0信息資源5.2 包圖5.2.1 基本概念：包表示法5.2.2 基本概念：元素的可見性5.2.3 基本概念：依賴關係5.2.4 基本概念：包圖5.2.5 高級概念：導入和訪問5.3 組件圖5.3.1 基本概念：組件表示法5.3.2 基本概念：組件圖5.3.3 基本概念：組件接口5.3.4 基本概念：組件實現5.3.5 高級概念：組件的內部結構5.4 部署圖5.4.1 基本概念：工件表示法5.4.2 基本概念：節點表示法5.4.3 基本概念：部署圖5.5 用例圖5.5.1 基本概念：執行者5.5.2 基本概念：用例5.5.3 基本概念：用例圖5.5.4 高級概念：“include”和“extend”關係5.5.5 高級概念：泛化5.6 活動圖5.6.1 基本概念：動作5.6.2 基本概念：開始和停止5.6.3 基本概念：判斷節點和合併節點5.6.4 基本概念：分區5.6.5 高級概念：分叉、結合和併發5.6.6 高級概念：對象流5.6.7 高級概念：其他元素5.7 類圖5.7.1 基本概念：類表示法5.7.2 基本概念：類關係5.7.3 高級概念：模板（參數化）類5.7.4 高級概念：可見性5.7.5 高級概念：關聯端名稱和限定符5.7.6 高級概念：約束5.7.7 高級概念：關聯類和注解5.8 序列圖5.8.1 基本概念：對象與交互5.8.2 基本概念：生命線與消息5.8.3 高級概念：銷毀事件5.8.4 高級概念：執行說明5.8.5 高級概念：交互使用5.8.6 高級概念：控制結構5.9 交互概述圖5.9.1 基本概念：框5.9.2 基本概念：控制流元素5.9.3 基本概念：交互圖元素5.10 組合結構圖5.10.1 基本概念：組合結構的部分5.10.2 基本概念：組合結構的部分與接口5.10.3 基本概念：組合結構連接器5.10.4 高級概念：協作5.11 狀態機圖5.11.1 基本概念：初始狀態、最終狀態和簡單狀態5.11.2 基本概念：轉換與事件5.11.3 高級概念：狀態活動--入口活動、執行活動和出口活動5.11.4 高級概念：控制轉換5.11.5 高級概念：複合狀態與嵌套狀態5.11.6 高級概念：併發與控制5.11.7 高級概念：子狀態機狀態5.11.8 高級概念：其他狀態機圖元素5.12 時間圖5.12.1 基本概念：更多相同之處5.12.2 基本概念：佈局5.12.3 基本概念：事件5.12.4 基本概念：約束5.12.5 高級概念：另一種表示形式5.12.6 高級概念：事件與消息5.13 對象圖5.13.1 基本概念：對象5.13.2 基本概念：對象關係5.13.3 高級概念：端點名稱和限定符5.14 通信圖5.14.1 基本概念：對象、鏈接和消息5.14.2 基本概念：順序表達式5.14.3 高級概念：消息與同步5.14.4 高級概念：迭代子句和警戒條件5.15 小結第6章 過程6.1 首要原則6.1.1 成功項目的特徵6.1.2 追求理性的開發過程6.2 宏觀過程：軟件開發生命週期6.2.1 概述6.2.2 宏觀過程的內容維：科目6.2.3 宏觀過程的時間維：里程碑和階段6.2.4 宏觀過程的時間維：迭代6.2.5 發行計劃6.3 微觀過程：分析與設計過程6.3.1 概述6.3.2 抽象層次6.3.3 活動6.3.4 產品6.3.5 微觀過程與抽象層次6.3.6 識別元素6.3.7 確定元素間的協作6.3.8 確定元素間的關係6.3.9 詳細確定元素的語義6.4 小結第7章 實戰7.1 管理和計劃7.1.1 風險管理7.1.2 任務計劃7.1.3 開發複查7.2 人員配備7.2.1 資源配置7.2.2 開發團隊角色7.3 發佈版本管理7.3.1 配置管理和版本控制7.3.2 集成7.3.3 測試7.4 複用7.4.1 複用的元素7.4.2 建立複用制度7.5 質量保證和測量指標7.5.1 軟件質量7.5.2 面向對象測量指標7.6 文檔化7.6.1 開發遺產7.6.2 文檔化的內容7.7 工具7.7.1 工具種類7.7.2 組織上的意義7.8 特殊主題7.8.1 領域特定問題7.8.2 採納面向對象技術7.9 面向對象開發的好處和風險7.9.1 面向對象開發的好處7.9.2 面向對象開發的風險7.10 小結第3篇 應 用第8章 系統架構--基於衛星的導航8.1 初始8.1.1 衛星導航系統的需求8.1.2 定義問題的邊界8.1.3 確定任務用例8.1.4 確定系統用例8.2 細化8.2.1 開發一個好的架構8.2.2 定義架構開發活動8.2.3 驗證所建議的系統架構8.2.4 分配非功能需求和確定接口8.2.5 規定系統架構及其部署8.2.6 分解系統架構8.3 構造8.4 交付之後8.4.1 添加新的功能8.4.2 改變目標硬件第9章 控制系統--交通管理9.1 初始9.1.1 列車交通管理系統的需求9.1.2 決定系統用例9.2 細化9.2.1 分析系統功能9.2.2 定義TTMS架構9.2.3 從系統工程到硬件和軟件工程9.2.4 關鍵抽象和機制9.3 構造9.3.1 消息傳送9.3.2 列車時刻表計劃9.3.3 顯示信息9.3.4 傳感器數據采集9.3.5 發佈版本管理9.3.6 系統架構9.3.7 子系統規格說明9.4 交付之後第10章 人工智能--密碼分析10.1 初始10.1.1 密碼分析需求10.1.2 定義問題的邊界10.1.3 黑板框架的架構10.1.4 知識源的分析10.2 細化10.2.1 黑板對象10.2.2 依賴和認定10.3 構造10.3.1 設計黑板對象10.3.2 設計知識源10.3.3 設計控制器10.3.4 集成黑板框架10.3.5 添加新的知識源10.4 交付之後10.4.1 系統增強10.4.2 改變需求第11章 數據采集--氣象監測站11.1 初始11.1.1 氣象監測站需求11.1.2 定義問題的邊界11.1.3 場景11.2 細化11.2.1 氣象監測系統用例11.2.2 架構框架11.3 構造11.3.1 幀機制11.3.2 發佈計劃11.3.3 傳感器機制11.3.4 顯示機制11.3.5 用戶界面機制11.4 交付之後第12章 Web應用--休假跟蹤系統12.1 初始12.1.1 需求12.1.2 用例模型12.2 細化12.2.1 部署視圖12.2.2 邏輯視圖12.2.3 進程視圖12.2.4 實現視圖12.2.5 用例視圖12.3 構造12.3.1 用戶體驗模型12.3.2 分析和設計模型12.3.3 實體12.3.4 控制器12.3.5 Web頁面和用戶界面12.4 交付和交付之後附錄A 面向對象編程語言附錄B 進一步閱讀注解術語表分類書目·

2.時間和空間語義
當確定存在某個操作，并定義了它的功能語言之后，必須決定它的時間語義和空間語義。這意味著我們必須決定它完成操作需要的時間以及存儲空間。這樣的決定通常是用最佳、平均和最差等術語來表達的，最差的情況規定了能夠接受的上限。
前面也曾提到，當一個對象通過一個鏈接向另一個對象傳遞消息時，這兩個對象必須以某種方式同步。在多控制線程的情況下，這意味著消息的傳遞比子程序調用要更復雜。在使用的大多數語言中，對象之間的同步不成問題，因為我們的程序只包含一個控制線程，這意味著所有的對象都是被依次訪問的。這種情況下的消息傳遞很簡單，因為它的語義基本上與簡單的子程序調用相同。但是，在支持并發的語言中，我們必須關注更為復雜的消息傳遞形式，以避免兩個控制線程以無限制的方式訪問同一個對象，從而引發問題。前面曾提到，在多個控制線程下仍能保持語義的對象要么是守衛的，要么是同步的。
3.6.3選擇關系
在類之間和對象之間選擇關系與選擇操作是有聯系的。如果決定對象x向對象Y發送消息M，那么X必須能夠直接或間接地訪問Y；否則，就不能夠在X的實現中命名操作M。所謂能夠訪問，指的是一種抽象能夠看到另一種抽象，并引用它的外部視圖中的資源。只有當它們的范圍重疊，并且訪問得到授權時（例如，類的私有部分只能被該類本身和它的友元訪問），一種抽象才可以訪問另一種抽象。因此，耦合是度量可訪問程度的指標。
1.Demeter法則
在選擇對象間的關系時，有一條有用的指導原則，稱為Demeter法則。它指出，“類的方法不應該以任何方式依賴于任何類的結構，除了它自己類的當前（頂層）結構之外。而且，每個方法只能夠對一個非常有限的類集的對象發出消息”[56]。應用這一法則的基本效果就是創建了一些松耦合的類，它們的實現秘密被封裝了起來。這樣的類是相當沒有負擔的，即為了理解一個類的意思，不需要理解許多其他類的細節。