【正文】 多個(gè)副本 。 l 圖書館應(yīng)用系統(tǒng)將圖書和雜志借給讀者 ， 這些讀者已經(jīng)在系統(tǒng)中注冊了 ， 借閱的圖書和雜志也已在系統(tǒng)中登記了 。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 下面給出一個(gè)較完整的圖書館應(yīng)用系統(tǒng)的用例圖 。 對一個(gè)大系統(tǒng)，要列出用例清單常常十分困難。 大部分用例將在項(xiàng)目的需求分析階段產(chǎn)生 ， 并且隨著工作的深入會(huì)發(fā)現(xiàn)更多的用例 ， 這些都應(yīng)及時(shí)增添到已有的用例集中 。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 用例用來獲取需求 、 規(guī)劃和控制項(xiàng)目 。當(dāng)一個(gè)用例與另一個(gè)用例相似，但所做的動(dòng)作多一些，就可以用到擴(kuò)展關(guān)系。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 4. 使用和擴(kuò)展 (Use and Extend) 用例圖除了包含執(zhí)行者與用例之間的連接外 ， 還可以有另外兩種類型的連接 ， 用來表示用例之間的使用和擴(kuò)展關(guān)系 。 執(zhí)行者在用例圖中是用類似人的圖形來表示的，但執(zhí)行者未必是人。 單個(gè)執(zhí)行者可與多個(gè)用例聯(lián)系；反過來 ， 一個(gè)用例可與多個(gè)執(zhí)行者聯(lián)系 。 第 7章 面向?qū)ο箝_發(fā)方法與 UML B o o k B o r r o w e rJo u r n a l B o r r o w e rB o r r o w C o p yo f B o o kR e t u r n C o p yo f B o o kB o r r o w C o p yo f Jo u r n a lR e t u r n C o p yo f Jo u r n a l圖 用例圖 第 7章 面向?qū)ο箝_發(fā)方法與 UML 3. 通信聯(lián)系 在圖 ， 不帶箭頭的線段將執(zhí)行者與用例連接到一起 ，表示兩者之間交換信息 ， 稱之為通信聯(lián)系 。 UML將用例定義成系統(tǒng)執(zhí)行的一系列動(dòng)作 ， 動(dòng)作執(zhí)行的結(jié)果能被指定執(zhí)行者察覺到 。 例如 ， 在文字處理軟件中 ， “ 將某些正文置為黑體 ” 和“ 創(chuàng)建一個(gè)索引 ” 便是兩個(gè)典型的用例 。 在 UML中，一個(gè)用例模型由若干個(gè)用例圖描述，用例圖主要元素是用例和執(zhí)行者。 用例模型描述了待開發(fā)系統(tǒng)的功能需求 ， 將系統(tǒng)看作黑盒 ，從外部執(zhí)行者的角度來理解系統(tǒng) 。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 1. 用例模型 (Use Case Model) 用例模型用于需求分析階段 ， 描述的是外部執(zhí)行者 (Actor)所理解的系統(tǒng)功能 。用例模型由 Ivar Jacobson在開發(fā) AXE系統(tǒng)中首先使用，并加入由他所倡導(dǎo)的 OOSE和 Objectory方法中。 第 7章 面向?qū)ο箝_發(fā)方法與 UML UML靜態(tài)建模機(jī)制簡介 用例圖 長期以來，在面向?qū)ο箝_發(fā)和傳統(tǒng)的軟件開發(fā)中，人們一直用典型的使用情景來描述需求。驗(yàn)收測試由用戶實(shí)施，驗(yàn)證系統(tǒng)是否滿足客戶的要求。集成測試集成組件和類，以校驗(yàn)它們是否像指定的那樣合作。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 5. 測試階段 與結(jié)構(gòu)化系統(tǒng)開發(fā)方法類似，面向?qū)ο蟮拈_發(fā)方法也需要經(jīng)過單元測試、集成測試、系統(tǒng)測試和驗(yàn)收測試。如果在早期階段就考慮代碼，勢必達(dá)不到預(yù)期的目的。用 UML創(chuàng)建分析模型和設(shè)計(jì)模型時(shí)，應(yīng)避免試圖將模型轉(zhuǎn)換為代碼。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 4. 編碼階段 在編碼階段 (或者稱為構(gòu)建階段 )，設(shè)計(jì)階段的類被轉(zhuǎn)換為使用面向?qū)ο蟪绦蛟O(shè)計(jì)語言編制的實(shí)際代碼。在分析階段獲得的問題域中的類被 “ 嵌入 ” 到此技術(shù)基礎(chǔ)結(jié)構(gòu)中，這樣就能夠同時(shí)改變問題域和基礎(chǔ)結(jié)構(gòu)。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 3. 設(shè)計(jì)階段 在設(shè)計(jì)階段，分析階段的結(jié)果被擴(kuò)展為一個(gè)技術(shù)解決方案。這種協(xié)作由 UML中的動(dòng)態(tài)模型描述。被建模的類以及類之間的關(guān)系在 UML的類圖中被明確指定和描述。每一個(gè)用例都是用文本進(jìn)行描述的，它確定了客戶的需求，即在不考慮功能如何實(shí)現(xiàn)的情況下客戶所企盼的功能。外部參與者和用例之間是通過關(guān)系建模的，并允許相互之間存在通信關(guān)聯(lián)，或者被分解為更具體的層次結(jié)構(gòu)。 1. 需求分析階段 UML語言采用用例來捕獲客戶的需求。 國內(nèi)對 UML支持環(huán)境的研制開發(fā)工作尚處于起步階段 。 目前 ， 在基于 UML的開發(fā)方法和環(huán)境方面 ， 國際上已經(jīng)進(jìn)行了一些研究和實(shí)際開發(fā)工作 。 UML適用于系統(tǒng)開發(fā)過程中從需求規(guī)格描述到系統(tǒng)完成后測試的不同階段 。 第 7章 面向?qū)ο箝_發(fā)方法與 UML UML以面向?qū)ο髨D的方式來描述任何類型的系統(tǒng) ， 具有很寬的應(yīng)用領(lǐng)域 。 第 7章 面向?qū)ο箝_發(fā)方法與 UML (3) UML在演變過程中還提出了一些新的概念。 UML符號考慮了各種方法的圖形表示 ， 刪掉了大量易引起混亂的 、 多余的和極少使用的符號 ，也添加了一些新符號 。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 2. 標(biāo)準(zhǔn)建模語言 UML的主要特點(diǎn) 標(biāo)準(zhǔn)建模語言 UML的主要特點(diǎn)可以歸結(jié)為三點(diǎn) : (1) ?UML統(tǒng)一了 Booch、 OMT和 OOSE等方法中的基本概念 。 1997年 11月 17日， OMG組織采納UML 。 UML融合了 Booch、 OMT和 OOSE等方法中的基本概念 ， 但又不僅僅是上述方法的簡單匯合 ， 而是在這些方法的基礎(chǔ)上集眾家之長 ， 幾經(jīng)修改而完成的 ， 它擴(kuò)展了現(xiàn)有方法的應(yīng)用范圍 。 0 . 9 1O O P S L A 9 5 U n i f i e d M e t h o d 0 . 8合作伙伴意見其它方法B o o c h 9 3B o o c h 9 1 O M T 1O O S E工業(yè)化標(biāo)準(zhǔn)化統(tǒng)一化分散的各部分O M T 2圖 UML的發(fā)展歷程 第 7章 面向?qū)ο箝_發(fā)方法與 UML UML是一種定義良好 、 易于表達(dá) 、 功能強(qiáng)大且普遍適用的建模語言 。圖 UML的發(fā)展歷程。當(dāng)時(shí)的成員有 DEC、 HP、 ILogix、 Itellicorp、IBM、 ICON Computing、 MCI Systemhouse、 Micr osoft、 Oracle、Rational Software、 TI以及 Unisys等。1996年 6月和 10月又分別發(fā)布了兩個(gè)新的版本，即 UML UML ，并將 UM重新命名為 UML(Unified Modeling Language)。 1995年秋， OOSE 的創(chuàng)始人 Ivar Jacobson加盟到這一工作。 因此 ， 有必要在精心比較不同的建模語言優(yōu)缺點(diǎn)及總結(jié)面向?qū)ο蠹夹g(shù)應(yīng)用實(shí)踐的基礎(chǔ)上 ， 根據(jù)應(yīng)用需求 ， 求同存異 ， 統(tǒng)一建模語言 。該方法簡單、易學(xué)，適合于面向?qū)ο蠹夹g(shù)的初學(xué)者使用，但由于該方法在處理能力方面的局限，目前已很少使用。 OOSE比較適合支持商業(yè)工程和需求分析 。 第 7章 面向?qū)ο箝_發(fā)方法與 UML Jacobson于 1994年提出了 OOSE方法 ， 其最大特點(diǎn)是面向用例 (UseCase)， 并在用例的描述中引入了外部角色的概念 。軟件開發(fā)人員不必在開發(fā)過程的不同階段進(jìn)行概念和符號的轉(zhuǎn)換。 Rumbaugh等人提出了面向?qū)ο蟮慕＜夹g(shù) (OMT)方法，采用了面向?qū)ο蟮母拍?，并引入各種獨(dú)立于語言的表示符。 1991 年 ， 他將以前面向 Ada的工作擴(kuò)展到整個(gè)面向?qū)ο笤O(shè)計(jì)領(lǐng)域 。 90年代中期，一批新方法出現(xiàn)了，其中最引人注目的是 Booch 199 OOSE和 OMT2等。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 1. 標(biāo)準(zhǔn)建模語言 UML的發(fā)展歷史 早期的面向?qū)ο蠼ＵZ言出現(xiàn)于 20世紀(jì) 70年代中期，到 90年代初，數(shù)量從不到 10種增加到了 50多種。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 標(biāo)準(zhǔn)建模語言 (UML)簡介 UML概述 面向?qū)ο蟮姆治雠c設(shè)計(jì)方法的發(fā)展在 20世紀(jì) 80年代末至 90年代中期出現(xiàn)了一個(gè)高潮， UML是這個(gè)高潮的產(chǎn)物。 上面介紹的 Booch的步驟是一種松散的、不十分嚴(yán)格的方法。 一旦對象 、 對象的操作 、 數(shù)據(jù)和對象間交互作用被了解 ，對象的實(shí)現(xiàn)就很容易用某種面向?qū)ο蟮恼Z言來完成 。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 4) 建立每個(gè)對象的接口 識(shí)別出系統(tǒng)中的對象和類以后 ， 還應(yīng)該識(shí)別出對象之間的相互作用 ， 即對象的外部接口 。 3) 建立對象之間的聯(lián)系和每個(gè)對象的接口 這一步建立對象和對象類之間的聯(lián)系，標(biāo)識(shí)出每一個(gè)對象都與什么對象和對象類有關(guān)。 例如 ， 窗口被打開 、 關(guān)閉 、 縮放和滾動(dòng)等 。對象標(biāo)識(shí)出來后，還應(yīng)注意對象之間的類似之處，以建立對象類。 1) 標(biāo)識(shí)對象及其屬性 弄清對象是面向?qū)ο笤O(shè)計(jì)的核心問題，標(biāo)識(shí)對象可以從應(yīng)用系統(tǒng)的概括描述中的名詞來導(dǎo)出。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 3. 形式化處理 面向?qū)ο蟮脑O(shè)計(jì)經(jīng)過前面的分析和描述后 ， 到此實(shí)際上才展開 。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 概括描述的好壞可由提出一個(gè)問題來加以判斷： “ 假如嚴(yán)格遵循概括描述實(shí)現(xiàn)解答 ， 問題能得到解決嗎 ？ ” 概括描述應(yīng)盡可能重復(fù)使用相同的術(shù)語來描述同一件事物，避免使用同義詞。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 2. 概括描述 面向?qū)ο蟮脑O(shè)計(jì)的下一步是根據(jù)問題描述中給出的問題的解寫出不十分嚴(yán)格的概括描述 。 1. 問題定義 這里的問題定義是需求分析的另一種說法 ， 此步驟中系統(tǒng)分析人員和設(shè)計(jì)人員應(yīng)完成兩項(xiàng)必不可少的工作： (1) 描述問題本身； (2) 分析并說明已知的限制 。為了弄清對象，產(chǎn)生了數(shù)據(jù)抽象；借助定義抽象，描述了模塊，軟件的結(jié)構(gòu)也就建立起來了；靠開發(fā)使用對象的機(jī)制 (如生成消息 )，接口得到了描述。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 以上步驟中 ， 前面兩步工作實(shí)際上是屬于軟件需求分析的范疇 ， 相當(dāng)于我們在需求分析階段得到的規(guī)格說明書 。 (3) 按以下子步驟把方法嚴(yán)格化： ① 弄清對象及其屬性； ② 弄清可能被施于對象的操作； ③ 利用表達(dá)對象與操作的關(guān)系建立每個(gè)對象的接口； ④ 決定詳細(xì)設(shè)計(jì)問題，從而給出對象的實(shí)現(xiàn)描述。下面我們介紹由 Booch提出的面向?qū)ο笤O(shè)計(jì)的步驟： 第 7章 面向?qū)ο箝_發(fā)方法與 UML (1) 定義問題。盡管面向?qū)ο蟮母拍钤缫殉霈F(xiàn)，但直到 20世紀(jì) 80年代初還沒有人能給出一種方法，用以實(shí)現(xiàn)面向?qū)ο蟮脑O(shè)計(jì)。封裝使得一個(gè)對象可以像一個(gè)可插接的部件一樣用在各種程序中，就像一種集成塊可以用在不同的電路中一樣。就比如甲、乙兩人互傳電子郵件，雙方關(guān)心的是內(nèi)容和格式是否符合要求，而不是電子郵件的素材、編輯工具以及傳送方式。因?yàn)檎{(diào)用者可能會(huì)直接操縱被調(diào)用者中改變了的這些數(shù)據(jù)。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 封裝可以保證對象的界面清晰、簡單，防止由于模塊之間的相互依賴所帶來的變動(dòng)的相互影響。這個(gè)實(shí)現(xiàn)給出了由軟件對象提供的功能的實(shí)現(xiàn)細(xì)節(jié)，實(shí)現(xiàn)細(xì)節(jié)不能在定義這個(gè)對象的類的外面訪問。 該接口用以描述這個(gè)對象和其他對象之間的相互作用 。 所有對象的內(nèi)部軟件的范圍被限定在這個(gè)邊界內(nèi) 。 封裝的目的在于將對象的使用者和設(shè)計(jì)者分開，使用者無須知道對象內(nèi)部實(shí)現(xiàn)的細(xì)節(jié)，只需要知道對象接收的消息。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 4. 封裝性 封裝是一種信息隱藏技術(shù) ， 對象內(nèi)部對用戶是隱藏的 ， 不可直接訪問；用戶只能見到對象封裝界面上的信息 ， 通過對象的外部接口訪問對象 。這使得同一屬性或操作在父類和子類 (或子類的子類，可多次繼承 )中具有不同的語義。 第 7章 面向?qū)ο箝_發(fā)方法與 UML 圖形 顏色 中心點(diǎn)坐標(biāo) 顯示 隱藏 移動(dòng) 點(diǎn) 顯示 隱藏 圓 半徑 顯示 隱藏圖 多態(tài)性的例子 第 7章 面向?qū)ο箝_發(fā)方法與 UML 多態(tài)性不僅僅局限于操作 ， 同一個(gè)屬性在不同的對象類中也可以具有不同的數(shù)據(jù)類型 ， 即屬性的多態(tài)性 。這就是顯示和隱藏這兩個(gè)操作體現(xiàn)出來的多態(tài)性。在面向?qū)ο蠓椒ㄖ校鄳B(tài)并不是指一個(gè)對象類