【正文】 一個名詞可具有多種語義。例如，圖 類和其子類圓類、點(diǎn)類中都定義了顯示和隱藏操作，圖形類中的顯示和隱藏并不確定到底顯示或隱藏何種圖形，但子類中的顯示和隱藏就涉及到具體應(yīng)該顯示或隱藏何種圖形，并且所顯示的圖形顯然是不一樣的。其特點(diǎn)是源于繼承而并非簡單的繼承，必須有不同的表現(xiàn)。 綜上所述，多態(tài)性可定義為： “ 一個類中定義的屬性或操作被繼承之后，可以具有不同的數(shù)據(jù)類型或表現(xiàn)出不同的行為。 ” 第 7章 面向?qū)ο箝_發(fā)方法與 UML 就圖 ，當(dāng)外部的某個對象調(diào)用圖形對象的顯示操作時，無須考慮該操作具體對應(yīng)多少種實(shí)現(xiàn)方法，即該對象發(fā)出的請求服務(wù)的消息中只須寫上 “ 顯示 ” ，究竟對應(yīng)哪個顯示由圖形類的操作自動識別，并傳給對應(yīng)的子類，由子類去執(zhí)行不同的顯示操作，這也稱為 “ 動態(tài)綁定 ” 。 用戶向?qū)ο蟀l(fā)送消息 ， 對象根據(jù)收到的消息調(diào)用內(nèi)部方法作出響應(yīng) 。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 封裝的定義為： (1) 一個清楚的邊界 。 (2) 一個接口 。 (3) 受保護(hù)的內(nèi)部實(shí)現(xiàn)。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 因?yàn)榉庋b技術(shù)強(qiáng)調(diào)客觀實(shí)體的內(nèi)在屬性和服務(wù) (操作 )的不可分割性以及內(nèi)部信息的隱蔽，自然而然就增加了系統(tǒng)中對象的相對獨(dú)立性，減少了它們之間的相互依賴，同時也增加了其應(yīng)用的靈活性。在非面向?qū)ο蟮南到y(tǒng)中，如果某個函數(shù)的某些參數(shù)改變了 (類型、個數(shù)等 )，或者某些非私有數(shù)據(jù)改變了，即使函數(shù)的外部功能沒有改變，都要求調(diào)用該函數(shù)的其他模塊必須隨之作相應(yīng)的改變，否則后果不堪設(shè)想。相反，面向?qū)ο蟮姆庋b性不允許一個對象直接操縱另一個對象的數(shù)據(jù)，即調(diào)用者無須知道被調(diào)用者的內(nèi)部實(shí)現(xiàn)細(xì)節(jié)，所以只要外部功能沒變，就不存在上述變動的相互影響。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 對象的封裝特性可以提高模塊之間的獨(dú)立性，使得系統(tǒng)易于調(diào)試和維護(hù)。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 面向?qū)ο蟮脑O(shè)計方法 采用面向?qū)ο蠓椒ㄟM(jìn)行系統(tǒng)開發(fā)的首要任務(wù)是采用面向?qū)ο蟮母拍罴捌涑橄髾C(jī)制將開發(fā)的系統(tǒng)對象化和模型化，建立應(yīng)用系統(tǒng)模型，然后使用面向?qū)ο蟮某绦蛟O(shè)計語言來實(shí)現(xiàn)系統(tǒng)中的對象。 20世紀(jì) 80年代以后，面向?qū)ο笤O(shè)計的設(shè)計方法取得了逐步進(jìn)展。 (2) 為真實(shí)世界問題域的軟件實(shí)現(xiàn)開發(fā)一個不嚴(yán)格的概括描述。 (4) 遞歸地重復(fù)步驟 (1)、 (2)和 (3)，以得到完整的設(shè)計。 面向?qū)ο笤O(shè)計方法將數(shù)據(jù)設(shè)計、結(jié)構(gòu)設(shè)計和過程設(shè)計三類設(shè)計元素結(jié)合起來。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 下面對 Booch提出的面向?qū)ο笤O(shè)計的各步驟作一簡單的介紹 。 無論現(xiàn)實(shí)問題的大小和復(fù)雜性如何，其軟件實(shí)現(xiàn)都應(yīng)以語法正確的簡單語句來描述，通過它應(yīng)該讓承擔(dān)項目的軟件工程師對問題有一個確切的、惟一的理解。 這種概括描述具有以下幾個特點(diǎn)： (1) 它是簡明易懂的一段文字描述； (2) 它所涉及的對象具有同一級抽象的特點(diǎn) ， 即其詳細(xì)程度在概括描述中保持一致； (3) 它應(yīng)主要表達(dá)為解決問題必須要做什么 ， 而不是如何得到解的過程； (4) 無須包括需求分析過程中所涉及的全部信息。此外，為便于理解，應(yīng)注意不要使用過分專業(yè)化的名詞。 如前所述 ， 形式化處理分為如下四個子步驟 。在這一步應(yīng)把注意力集中在如何將概括描述中所含的名詞和名詞短語分離出來。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 2) 標(biāo)識每個對象所要求的操作和提供的操作 這一步必須標(biāo)識出該對象執(zhí)行的功能 ， 這些功能描述了每個對象的行為 。 同時還應(yīng)關(guān)心由其他對象提供給它的操作 ， 因?yàn)橥ㄟ^標(biāo)識這些操作有可能導(dǎo)出新對象 。這一步中可能找出一些對象的模式，并決定是否要建立一個新類以表示這些對象的共同行為特性。 在面向?qū)ο笙到y(tǒng)中 ， 對象和對象之間的聯(lián)系是通過消息的發(fā)送和響應(yīng)來完成的 。 面向?qū)ο笤O(shè)計方法是以上步驟反復(fù)進(jìn)行 ， 直到建立起完整軟件設(shè)計的過程 。其他一些主要的面向?qū)ο蟮脑O(shè)計技術(shù)還有 Rumbaugh提出的一種稱為 “ 對象模型技術(shù) OMT”的設(shè)計方法、 Alabiso提出的基于數(shù)據(jù)流分析的面向?qū)ο笤O(shè)計技術(shù)等。它統(tǒng)一了Booch、 Rumbaugh等的表示方法，并且對其作了進(jìn)一步的發(fā)展，最終統(tǒng)一為大眾所接受的標(biāo)準(zhǔn)建模語言。雖然不同建模語言的創(chuàng)造者都努力推崇自己的產(chǎn)品，并在實(shí)踐中不斷完善，但是由于用戶并不了解不同建模語言的優(yōu)缺點(diǎn)及相互之間的差異，因而很難根據(jù)應(yīng)用特點(diǎn)選擇合適的建模語言，于是爆發(fā)了一場“ 方法大戰(zhàn) ” 。 第 7章 面向?qū)ο箝_發(fā)方法與 UML Booch是面向?qū)ο蠓椒ㄗ钤绲某珜?dǎo)者之一 ， 他提出了面向?qū)ο筌浖こ痰母拍?。 Booch 1993比較適合于系統(tǒng)的設(shè)計和構(gòu)造 。這種方法用對象模型、動態(tài)模型、功能模型和用例模型來共同完成對整個系統(tǒng)的建模，所定義的概念和符號可用于軟件開發(fā)的分析、設(shè)計和實(shí)現(xiàn)的全過程。 OMT2特別適用于分析和描述以數(shù)據(jù)為中心的信息系統(tǒng)。用例的概念是精確描述需求的重要武器 ， 貫穿于整個開發(fā)過程 ，包括對系統(tǒng)的測試和驗(yàn)證 。 另外，還有 Coad/Yourdon方法，即著名的 OOA/OOD，它是最早的面向?qū)ο蟮姆治龊驮O(shè)計方法之一。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 雖然不同的建模語言大多類同 ， 但仍存在某些細(xì)微的差別 ，妨礙了用戶之間的交流 。 1994年 10月， Grady Booch和 Jim Rumbaugh開始致力于這一工作。第一個公開版本，稱為統(tǒng)一方法 UM (Unitied Method)。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 1996年成立了 UML成員協(xié)會，以完善、加強(qiáng)和促進(jìn) UML的定義工作。這一機(jī)構(gòu)對 UML (1997年 1月 )及 UML (1997年 11月 17日 )的定義和發(fā)布起了重要的促進(jìn)作用。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 公眾反饋9 7 . 1 0 . 1 1 U M L 1 . 1 被 O M G接納為標(biāo)準(zhǔn)9 7 . 9 公布U M L 1 . 19 7 . 1 公布U M L 1 . 09 6 . 6 和 9 6 . 1 0 U M L 0 . 9 amp。 它融入了軟件工程領(lǐng)域的新思想 、 新方法和新技術(shù) ，支持從需求分析開始的軟件開發(fā)的全過程 。 UML已獲得了工業(yè)界、科技界和應(yīng)用界的廣泛支持，已有700多個公司表示支持采用 UML作為建模語言，它已成為可視化建模語言事實(shí)上的工業(yè)標(biāo)準(zhǔn)。 UML代表了面向?qū)ο蠓椒ǖ能浖_發(fā)技術(shù)的發(fā)展方向，具有巨大的市場前景，也具有重大的經(jīng)濟(jì)價值和國防價值。 (2) UML還吸取了面向?qū)ο蠹夹g(shù)領(lǐng)域中其他流派的長處 ，其中也包括非 OO方法的影響 。 因此 ， 在 UML中匯入了面向?qū)ο箢I(lǐng)域中很多人的 思想 。在 UML標(biāo)準(zhǔn)中新加了構(gòu)造型 (Stereotypes)、職責(zé) (Responsibilities)、擴(kuò)展機(jī)制 (Extensibility Mechanisms)、線程 (Threads)、過程(Processes)、分布式 (Distribution)、并發(fā) (Concurrency)、模式(Patterns)、協(xié)作圖 (Collaborations)、活動圖 (Activity Diagram)等新概念，并清晰地區(qū)分類型 (Type)、類 (Class)、實(shí)例 (Instance)、細(xì)化 (Refinement)、接口 (Interfaces)和組件 (Components)等概念。 最常用的是建立軟件系統(tǒng)的模型 ， 但它同樣可以用于描述非軟件領(lǐng)域的系統(tǒng) 。 如何恰當(dāng)?shù)貙⑦@種可視化圖形建模技術(shù)用于解決軟件開發(fā)所面臨的問題 ， 如何研制和開發(fā)支持 UML的建模過程及其支持環(huán)境 ， 仍是目前該領(lǐng)域的熱點(diǎn)問題 。 Rational公司目前正致力于推廣統(tǒng)一開發(fā)過程 (RUP， Rational Unified Process)， 研究 期稱為Objectory)， 支持 UML建模 。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 基于 UML的軟件開發(fā)方法 基于 UML的系統(tǒng)開發(fā)有五個階段：需求分析 、 分析 、 設(shè)計 、編碼和測試 。通過用例模型，可以使那些對系統(tǒng)感興趣的外部參與者與他們要求系統(tǒng)具備的功能 (即用例 )一起被建模。參與者和用例由 UML的用例圖描述，在用例圖中參與者被稱為執(zhí)行者或角色 (Actor)。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 2. 分析階段 分析階段所關(guān)注的是出現(xiàn)在問題域中的主要抽象 (類和對象 )和機(jī)制。為了實(shí)現(xiàn)用例，各類之間需要相互協(xié)作。在分析階段，只有在問題域 (現(xiàn)實(shí)世界的概念 )中的類才被建模，不包括那些在軟件系統(tǒng)中定義了細(xì)節(jié)和解決方案的技術(shù)類，如用戶界面類、數(shù)據(jù)庫類、通信類等。新類被加入進(jìn)來，以提供以下一些基礎(chǔ)結(jié)構(gòu)：用戶界面、處理對象存儲的數(shù)據(jù)庫、與其他系統(tǒng)的通信、與系統(tǒng)各種設(shè)備的接口等。設(shè)計階段將為隨后的構(gòu)建階段產(chǎn)生詳細(xì)的規(guī)格說明。這一任務(wù)的難度取決于編程語言本身的能力。在開發(fā)的早期階段，模型是幫助理解和搭建系統(tǒng)結(jié)構(gòu)的一種手段。因此，編碼是一個獨(dú)立的階段，只有到了編碼階段，模型才被轉(zhuǎn)換為代碼。對于面向?qū)ο蟮拈_發(fā)方法，單元測試是對單個類或一組類的測試，一般情況下由編程者自己完成。系統(tǒng)測試將系統(tǒng)看成是一個黑盒子，檢驗(yàn)系統(tǒng)是否具有最終用戶所期望的功能。不同的測試團(tuán)隊使用不同的 UML圖作為他們測試的基礎(chǔ)：單元測試團(tuán)隊使用類圖和類規(guī)格說明；集成測試團(tuán)隊一般使用組件圖和協(xié)作圖；系統(tǒng)測試團(tuán)隊使用用例圖檢驗(yàn)最初在這些圖中定義的系統(tǒng)行為。但是，這些使用情景是非正式的，難以規(guī)范化描述。用例方法引起了面向?qū)ο箢I(lǐng)域的極大關(guān)注，面向?qū)ο箢I(lǐng)域已廣泛接納了用例這一概念。 它的建立是系統(tǒng)開發(fā)者和用戶反復(fù)討論的結(jié)果 ， 表明了開發(fā)者和用戶對需求規(guī)格達(dá)成的共識 。 它驅(qū)動了需求分析之后各階段的開發(fā)工作 ， 不僅在開發(fā)過程中保證了系統(tǒng)所有功能的實(shí)現(xiàn) ，而且被用于驗(yàn)證和檢測所開發(fā)的系統(tǒng) ， 從而影響到開發(fā)工作的各個階段和 UML的各個模型 。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 2. 用例 (Use Case)與執(zhí)行者 (Actor) 一個用例從本質(zhì)上講是用戶與計算機(jī)之間的一次典型交互作用 。 執(zhí)行者是指用戶在系統(tǒng)中所扮演的角色 。 圖 的一部分 ， 其中的橢圓表示用例 ， 小人表示執(zhí) 行者 。 執(zhí)行者觸發(fā)用例 ，并與用例進(jìn)行信息交換 。 對同一個用例而言 ， 不同執(zhí)行者有著不同的作用：他們可以從用例中取值 ， 也可以參與到用例中 。例如，執(zhí)行者也可以是一個外界系統(tǒng)，該外界系統(tǒng)可能需要從當(dāng)前系統(tǒng)中獲取信息，與當(dāng)前系統(tǒng)進(jìn)行交互。 使用和擴(kuò)展是兩種不同形式的繼承關(guān)系。當(dāng)有一大塊相似的動作存在于幾個用例，又不想重復(fù)描述該動作時，就可以用到使用關(guān)系。 用例的獲取是需求分析階段的主要任務(wù)之一 ， 而且是首先要做的工作 。 用例集中的每個用例都是一個潛在的需求 ?？上攘谐鰣?zhí)行者清單，再對每個執(zhí)行者列出它的用例，問題就會容易很多。 用戶或客戶對它最初的需求描述如下： l 這是一個圖書館支持系統(tǒng) 。 l 圖書館負(fù)責(zé)新書的購買 。 當(dāng)書和雜志已經(jīng)過時或破舊不堪時，將它們從系統(tǒng)中刪除。 當(dāng)讀者借閱了它所預(yù)訂的圖書或雜志后 ， 或者讀者要求取消預(yù)訂時 ，他的本次預(yù)訂就被取消了 。 用例描述了圖書館系統(tǒng)提供的所有功能 ——系統(tǒng)的功能需求。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 圖書館系統(tǒng)的執(zhí)行者包括圖書管理員和讀者。讀者不直接和軟件系統(tǒng)打交道，讀者的要求由圖書管理員代為執(zhí)行。 標(biāo)題可以是一本書的名稱 、 書的作者或者是用來表示指定標(biāo)題的一個物理副本的其他信息 。 在圖書館擁有某本書之前 ， 就可以在系統(tǒng)中增加該書的標(biāo)題以允許讀者預(yù)訂此書 。這里將它作為一個用例，主要是為了能夠?qū)⒕S護(hù)任務(wù)從系統(tǒng)的主要功能中清晰地分離出來。 每一個用例都附帶有文本文檔 ， 用來描述用例以及用例與執(zhí)行者之間的交互 。對于一個想要描述的系統(tǒng)，其類模型和對象模型揭示了系統(tǒng)的結(jié)構(gòu)。類圖技術(shù)是 OO方法的核心。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 保險單D a t e R e c i e v e di sP r e p a i dN u m b e r : S t r i n gP r i c e : M o n e yD