本書的主要內(nèi)容 “擁有一把錘子未必能成為架構(gòu)師”，這句諺語(yǔ)在對(duì)象技術(shù)領(lǐng)域同樣適用。對(duì)創(chuàng)建對(duì)象系統(tǒng)來說，了解面向?qū)ο笳Z(yǔ)言（例如Java）是必要的，但不是首先要做的。了解“對(duì)象思想”才是關(guān)鍵所在！
本書是對(duì)應(yīng)用了統(tǒng)一建模語(yǔ)言（UML）和模式的OOA/D的介紹。同時(shí)，對(duì)于迭代開發(fā)，本書使用統(tǒng)一過程（Unified Process）的敏捷方法作為示例迭代過程。
UML和對(duì)象思想 UML并不是OOA/D，也不是方法，它只是圖形表示法。如果沒有真正掌握如何創(chuàng)建優(yōu)秀的面向?qū)ο笤O(shè)計(jì)，或者如何評(píng)估和改進(jìn)現(xiàn)有設(shè)計(jì)，那么學(xué)習(xí)UML或者UML CASE工具是毫無意義的。對(duì)象思想才是重點(diǎn)和難點(diǎn)。因此本書重點(diǎn)闡述對(duì)象設(shè)計(jì)。 而且，我們需要一種用于OOA/D和“軟件藍(lán)圖”的語(yǔ)言，這既是一種思考的工具，也是一種溝通的形式。因此，本書也將探討如何在OOA/D中應(yīng)用UML，并涵蓋經(jīng)常使用的UML表示法。
OOD的原則和模式 應(yīng)該如何為對(duì)象分配職責(zé)（responsibility）?對(duì)象之間應(yīng)該如何協(xié)作？什么樣的類應(yīng)該做什么樣的事情？這些都是系統(tǒng)設(shè)計(jì)中的關(guān)鍵問題，而本書將會(huì)講授作為經(jīng)典OO設(shè)計(jì)之象征的職責(zé)驅(qū)動(dòng)設(shè)計(jì)（responsibility-driven design）。同時(shí)，某些針對(duì)設(shè)計(jì)問題的，經(jīng)過反復(fù)驗(yàn)證的解決方案可以被表示成為最佳實(shí)踐的原則、啟示或模式（pattern），即問題-解決方案公式，這些公式是系統(tǒng)化的、典型的設(shè)計(jì)原則。本書將會(huì)通過講授如何應(yīng)用模式或原則，使讀者更快地學(xué)習(xí)和熟練使用這些基本的對(duì)象設(shè)計(jì)習(xí)慣用法。
案例研究 本書對(duì)OOA/D的介紹是通過一些貫穿全書的案例研究（ongoing case study）來闡述的，并且充分深入到分析和設(shè)計(jì)中，考慮和解決了現(xiàn)實(shí)問題中令人生畏但必須被考慮和解決的細(xì)節(jié)。
用例 OOD(以及所有軟件設(shè)計(jì))與作為其先決活動(dòng)的需求分析(requirement analysis)具有緊密聯(lián)系，而在需求分析中通常包含用例（use case）的編寫。因此，盡管這些主題并非是特定與面向?qū)ο蟮模矔?huì)在案例研究的開始對(duì)其進(jìn)行介紹。
迭代開發(fā)、敏捷建模和敏捷UP 需求分析和OOA/D需要在某種開發(fā)過程的語(yǔ)境中進(jìn)行描述和實(shí)踐。在這種情況下，使用著名的統(tǒng)一過程 （Unified Process）的敏捷（輕量的、靈活的）方法作為迭代開發(fā)過程（iterative development process）的樣例，并在這一過程中介紹需求需求分析和OOA/D的主題。然而，這里所涵蓋的分析和設(shè)計(jì)主題對(duì)于許多開發(fā)過程是通用的，在敏捷UP的語(yǔ)境中學(xué)習(xí)它們并不影響這些技術(shù)對(duì)于其他方法的適用性，這些方法包括Srucm、Feature-Driven Development(FDD)、lean Development、Crystal Methods等等。
重要的學(xué)習(xí)目標(biāo) 在OO開發(fā)中，至關(guān)重要的能力是熟練地為軟件對(duì)象分配職責(zé)。為什么？ 因?yàn)榉峙渎氊?zé)是必須要執(zhí)行的一項(xiàng)活動(dòng)（無論是畫UML圖時(shí)還是進(jìn)行程序設(shè)計(jì)，都要為軟件對(duì)象分配職責(zé)），并且它對(duì)軟件構(gòu)件的健壯性、可維護(hù)性和可重用性具有重要影響。
什么是分析和設(shè)計(jì) 分析（analysis）強(qiáng)調(diào)的是對(duì)問題和需求的調(diào)查研究，而不是解決方案。“分析”一次含義廣泛，最好加以限制，如需求分析（對(duì)需求的調(diào)查研究）或面向?qū)ο蠓治觯▽?duì)領(lǐng)域?qū)ο蟮恼{(diào)查研究）。
設(shè)計(jì) （design）強(qiáng)調(diào)的是滿足需求的概念上的解決方案（在軟件方面和硬件方面），而不是其實(shí)現(xiàn)。與“分析”相同，對(duì)“設(shè)計(jì)”一詞最好也加以限制，如面向?qū)ο笤O(shè)計(jì)或數(shù)據(jù)庫(kù)設(shè)計(jì)。
什么是面向?qū)ο蠓治龊驮O(shè)計(jì) 在面向?qū)ο蠓治觯╫bject-oriented analysis）過程中，強(qiáng)調(diào)的是在問題領(lǐng)域內(nèi)發(fā)現(xiàn)和描述對(duì)象（或概念）。
在面向?qū)ο笤O(shè)計(jì)(object-oriented design，簡(jiǎn)稱對(duì)象設(shè)計(jì))過程中，強(qiáng)調(diào)的是定義軟件對(duì)象以及它們?nèi)绾螀f(xié)作以實(shí)現(xiàn)需求。
1、定義用例 需求分析可能包括人們?nèi)绾问褂脩?yīng)用的情節(jié)或場(chǎng)景，這些情節(jié)或場(chǎng)景可以被編寫成用例（use case）。用例不是面向?qū)ο笾破罚皇菍?duì)情節(jié)的記錄。但用例是需求分析中的一種常用工具。
2、定義領(lǐng)域模型 面向?qū)ο蠓治鲫P(guān)注從對(duì)象的角度創(chuàng)建領(lǐng)域描述。面向?qū)ο蠓治鲂枰b別重要的概念、屬性和關(guān)聯(lián)。 面向?qū)ο蠓治龅慕Y(jié)果可以表示為領(lǐng)域模型，在領(lǐng)域模型中展示重要的領(lǐng)域概念或?qū)ο蟆Ｐ枰⒁獾氖牵I(lǐng)域模型模型并不是對(duì)軟件對(duì)象的描述，它使真實(shí)世界領(lǐng)域中的概念和想象可視化。因此，它也被稱為概念對(duì)象模型（conceptual object model）。
3、分配對(duì)象職責(zé)并繪制交互圖 面向?qū)ο笤O(shè)計(jì)關(guān)注軟件對(duì)象的定義--它們的職責(zé)和協(xié)作。順序圖(sequence diagram,UML的一種交互圖)是描述協(xié)作的常見表示法。它展示出軟件對(duì)象之間的消息流，和由消息引起的方法調(diào)用。
4、定義設(shè)計(jì)類圖 除了在交互圖中顯示對(duì)象協(xié)作的動(dòng)態(tài)視圖外、還可以用設(shè)計(jì)類圖（design class diagram）來有效地表示類定義的靜態(tài)視圖。這樣可以描述類的屬性和方法。
什么是UML 統(tǒng)一建模語(yǔ)言（UML）是描述、構(gòu)造和文檔化系統(tǒng)制品的可視化語(yǔ)言。
在上面的UML定義中，關(guān)鍵點(diǎn)是可視化這個(gè)詞，UML是圖形化表示法的事實(shí)標(biāo)準(zhǔn)，用來繪制和展示與軟件有關(guān)的圖形（以及文字）。本書重點(diǎn)關(guān)注UML的常用圖、這些常用圖中的常用特性和在未來版本中不太可能變化的核心表示法。
UML定義了各種UML簡(jiǎn)檔（UML profile），這些簡(jiǎn)檔專用于某些常用主題領(lǐng)域的表示法子集，例如對(duì)EJB使用UML EJB簡(jiǎn)檔。
在更深入的層次上，UML表示法的基礎(chǔ)是UML元模型(meta-model)，它描述建模元素的語(yǔ)義，UML元模型主要對(duì)模型驅(qū)動(dòng)架構(gòu)（Model Driven Architecture，MDA）CASE工具供應(yīng)商具有影響。開發(fā)者并不需要對(duì)其進(jìn)行學(xué)習(xí)。
+ - 1、應(yīng)用UML的三種方式
-
UML作為草圖 非正式的、不完整的圖（通常是在白板上手繪草圖），借助可視化語(yǔ)言的功能，用于探討問題或解決方案空間的復(fù)雜部分。
UML作為藍(lán)圖 相對(duì)詳細(xì)的設(shè)計(jì)圖，用于：1）逆向工程，即以UML圖的方式對(duì)現(xiàn)有代碼進(jìn)行可視化，使其易于理解。2）代碼生成（前項(xiàng)工程）。
對(duì)于逆向工程，UML工具讀取源文件或二進(jìn)制文件，并生成UML包圖、類圖和順序圖（一般情況下）。這些“藍(lán)圖”能夠幫助讀者從整體上理解元素、結(jié)構(gòu)和協(xié)作。
無論是人工還是使用自動(dòng)工具生成代碼，在此之間繪制一些詳細(xì)的圖都能夠?yàn)樯纱a的工作提供指導(dǎo)。一般情況下，代碼生成工具使用圖生成一些代碼，然后由開發(fā)者編寫并填充其他代碼。
UML作為編程語(yǔ)言 用UML完成軟件系統(tǒng)可執(zhí)行規(guī)格說明。可執(zhí)行代碼能夠被自動(dòng)生成，但并不像通常一樣為開發(fā)者所見或修改；人們僅使用UML“編程語(yǔ)言”進(jìn)行工作。如此應(yīng)用UML需要有將所有行為或邏輯進(jìn)行圖形化表示的實(shí)用方法，但是目前在理論、工具的健壯性和可用性方面仍然處于發(fā)展階段。
UML和銀彈思想 時(shí)間檢驗(yàn)真理。UML僅僅是標(biāo)準(zhǔn)的圖形化表示法，使用常用符號(hào)的可視化建模能夠帶來極大的幫助，但它不可能與設(shè)計(jì)和對(duì)象思想同等重要。設(shè)計(jì)知識(shí)是極不尋常的且更為重要的技能，它并不是通過學(xué)習(xí)UML表示法或者CASE或MDA工具就可以掌握的。如果不具備良好的OO設(shè)計(jì)和編程技能那么即使使用UML，也只能畫出挫劣的設(shè)計(jì)。如果要深入了解這一主題，建議閱讀“Death by UML Fever”(UML的發(fā)明者Grady Booch亦為認(rèn)可)和"What UML Is and Isn't?" 因此，本書是對(duì)OOA/D和應(yīng)用UML進(jìn)行熟練OO設(shè)計(jì)的介紹
敏捷建模（agile modeling）強(qiáng)調(diào)了UML作為草圖的方式，這也是使用UML的普通方式，而且通常對(duì)時(shí)間投入具有高回報(bào)（一般費(fèi)時(shí)較短）。雖然UML工具能夠提供幫助，但是建議也考慮使用UML的敏捷建模方法。
+ -
2、應(yīng)用UML的三種透視圖 UML描述的是原始圖類型，如類圖和順序圖。它并沒有在這些圖上疊加建模的透視圖。例如，同樣的UML類圖表示法既能夠描繪現(xiàn)實(shí)世界的概念，又能夠描繪Java中的軟件類。
Systropy面向?qū)ο蠓椒◤?qiáng)調(diào)了這一觀點(diǎn)。其主旨是，同一種表示法可以用來描述模型的三種透視圖和類型
-
概念透視圖 用圖來描述現(xiàn)實(shí)世界或關(guān)注領(lǐng)域中的事物。
規(guī)格說明（軟件）透視圖 用圖（使用與概念透視圖中相同的表示法） 來描述軟件的抽象物或具有規(guī)格說明和接口的構(gòu)件，但是并不約定特定實(shí)現(xiàn)（例如，非特定為C#或Java中的類）。
實(shí)現(xiàn)（軟件）透視圖 用圖來描述特定技術(shù)中的軟件實(shí)現(xiàn)。
在實(shí)際設(shè)計(jì)過程中，很少會(huì)使用規(guī)格說明透視圖（推遲了目標(biāo)技術(shù)的選擇，例如使用Java還是使用.Net）；大多數(shù)面向軟件的UML圖都會(huì)采用實(shí)現(xiàn)透視圖。
不同透視圖中“類”的含義 在原始的UML中，圖1-6中的矩形被稱為類（class），但這個(gè)術(shù)語(yǔ)包含各種現(xiàn)象，如物理事務(wù)、抽象概念、軟件事物、事件等等。
一個(gè)方法在原始UML之上添加了另一個(gè)術(shù)語(yǔ)。例如，在UP中，領(lǐng)域模型中的UML框被稱為領(lǐng)域模型(domain concept)或概念類（conceptual class）。領(lǐng)域模型表示的是概念透視圖。設(shè)計(jì)模型中的UML框被稱為設(shè)計(jì)類（design class），設(shè)計(jì)模型依據(jù)建模者的需要，表示的是規(guī)格說明透視圖或?qū)崿F(xiàn)透視圖。
為清晰起見，本書中與類相關(guān)的術(shù)語(yǔ)將與UML和UP保持一致，這些術(shù)語(yǔ)如下：
1、概念類（conceptual class）--現(xiàn)實(shí)世界中的概念或事物。在概念或本質(zhì)透視圖中使用。UP領(lǐng)域模型中包含概念類。
2、軟件類（software class）--無論在過程還是方法中，都表示軟件構(gòu)件在規(guī)格說明或?qū)崿F(xiàn)透視圖中的類。
3、實(shí)現(xiàn)類（implement class）--特定OO語(yǔ)言中的類。
為何在某些章中沒有大量使用UML 本書的主題并不是UML表示法，而是在OOA/D和相關(guān)需求分析的語(yǔ)境下，對(duì)UML應(yīng)用、模式和迭代過程的全景揭示。需求分析通常先于OOA/D，因此，本書在開始幾章先介紹關(guān)于用例和需求分析的重要主題，然后再后繼各章中詳細(xì)介紹OOA/D和UML。
可視化建模的優(yōu)點(diǎn) 用符號(hào)來表示說明問題所冒的風(fēng)險(xiǎn)是顯而易見的，繪制或閱讀UML意味著我們要以更加可視化的方式工作，開發(fā)我們的腦力，以便更快地掌握（主流）二維框-線表示法中的符號(hào)、單元及關(guān)系。
這個(gè)古老而樸素的道理常常會(huì)遺失在大量的UML細(xì)節(jié)和工具中。這是不應(yīng)該的！圖可以幫助我們更為便利地觀察全景，發(fā)現(xiàn)軟件元素或分析之間的聯(lián)系，同時(shí)允許我們忽略或隱藏旁支末節(jié)。這是UML或其他圖形化語(yǔ)言的本質(zhì)價(jià)值。