【正文】 mport， refine 關(guān)聯(lián)（ Association） 關(guān)系 圖例 Job Salary Company Person employer 關(guān)聯(lián)（ association） employee * 1..* Job boss 0..1 worker * Manage Account Corporation {Xor} 圖例 Person – 對于關(guān)聯(lián)可加上一些約束，以規(guī)定關(guān)聯(lián)的含義 – 約束的字符串括在花括號 {}內(nèi) – UML定義了 6種約束可加在目標(biāo)（ target）關(guān)聯(lián)端： implicit， ordered， changeable，addonly， frozen， xor 關(guān)聯(lián)（ Association） 關(guān)系 圖例 Record goals for goals against wins losses ties Team Player season * Year team goalkeeper * * 圖例 Polygon Point GraphicsBundle color texture density 1 1 bundle {ordered} Contains + vertex 3..* 關(guān)聯(lián)（ Association） 關(guān)系 圖例 Bank Person Account * 0..1 Chessboard Square rank:Rank file:File 1 1 泛化（ Generalization）關(guān)系 泛化（ Generalization） Polygon Spline Shape …. 圖例 Ellipse 擴(kuò)展機(jī)制（ Extension Mechanism） ? UML提供了豐富的模型化的概念和表示法，足以為常見的典型的軟件系統(tǒng)建立模型。 – 擴(kuò)展機(jī)制（ Extension Mechanism）： UML語言的擴(kuò)展機(jī)制，允許 UML的使用人員根據(jù)需要自定義一些構(gòu)造型等語言成分，擴(kuò)展 UML和把 UML客戶化，更便于完成自己的軟件系統(tǒng)的開發(fā)工作。一種是如類與對象的劃分，另一種是如接口與接口的實(shí)現(xiàn)的劃分。除此之外，還可以對該元素加上各種裝飾，說明其它方面的細(xì)節(jié)特征。 UML語言的公共機(jī)制 ? UML規(guī)定了語言的四種公共機(jī)制：說明、裝飾、通用劃分、擴(kuò)展機(jī)制 – 說明（ Specification）： UML不只是一個圖形語言，還規(guī)定了對于每一個UML圖形的文字說明的語法和語義。對象類分別組織在構(gòu)件中，成為應(yīng)用系統(tǒng)中的可復(fù)用的模塊。對象建模定義對象的行為、保證 Use Case和業(yè)務(wù)規(guī)則得到正確的支持。在建立模型時，可以用 UML的圖形表示法使系統(tǒng)可視化，同時用 UML的說明描述系統(tǒng)的細(xì)節(jié) – 具體地說， UML提供了以下的系統(tǒng)模型化功能： ? Use Case建模： Use Case抽取系統(tǒng)的功能需求 ? 對象類建模和對象建模： UML支持基本的和高級的對象類和對象建模。通過繪制 UML圖形，可以從不同的抽象角度使系統(tǒng)可視化。 UML模型有關(guān)概念和表示法 ? UML圖形是模型元素集合的可視化表示。 – 關(guān)聯(lián)是指模型構(gòu)建塊之間的結(jié)構(gòu)關(guān)系，兩者存在結(jié)構(gòu)性的鏈接（ Link） – 聚合（ Aggregation） 是一種特殊的關(guān)聯(lián)，表示結(jié)構(gòu)的整體與部分的關(guān)系。 UML概述 Booch方法 OMT 其它方法 統(tǒng)一方法 [1995年 10月 ] UML [1996年 6月 ] UML [1996年 10月 ] UML [1997年 1月 ] UML [1997年 11月 ] OOSE UML伙伴的合作 提交給 OMG的其它語言模型 OMG頒布的標(biāo)準(zhǔn) ? UML包括 3個方面的內(nèi)容： – 模型的概念和表示法 – 語言的公共機(jī)制 – 對象約束語言 ? UML簡史 UML模型有關(guān)概念和表示法 ? UML提供了 3類基本的標(biāo)準(zhǔn)模型構(gòu)建塊：事物、關(guān)系和圖形 – 事物是一個模型的一級抽象成員，即構(gòu)成模型的元素 – ―事物”代表任何可以定義的東西 ? 事物共有 4類：結(jié)構(gòu)類的事物、行為類事物、分組類的事物、注釋類的事物。 – 在面向?qū)ο蟮男g(shù)語中，常把對象之間的實(shí)例連接稱為鏈接（ Link）， 而把存在實(shí)例連接的對象類之間的聯(lián)系稱為關(guān)聯(lián)（ Assocaition） ? 多態(tài)性（ Ploymorphism） UML概述 ? UML是一種標(biāo)準(zhǔn)的軟件建模語言，它是一種用于對一個軟件系統(tǒng)的制品進(jìn)行可視化描述、詳細(xì)描述、構(gòu)造以及文檔化的語言。 – 在面向?qū)ο蟮男g(shù)語中常把一般與特殊的關(guān)系稱為泛化（ Generalization） 和特化（ Specialization） 聯(lián)系 ? 組合（ Composition） – 組合結(jié)構(gòu)（ Composition Structure） 表示對象類之間的組成關(guān)系，即部分與整體的關(guān)系 – 部分對于整體是“ apartof‖關(guān)系，整體對于部分是“ hasa‖關(guān)系。 然而，接口順序圖還指示 API調(diào)用流（ API call flows） ? 因為每個系統(tǒng)內(nèi)部的 API調(diào)用很可能是專有的，在一個建議中使用接口順序圖是受限或可略去。 – 接口（ Interfaces） : 一個接口是操作的集合，這些操作用于描述一個類或構(gòu)件（ ponent）提供的服務(wù)（ service） – 協(xié)作（ Collaborations） : 一個協(xié)作包括一些類、接口和其它一些元素，這些元素協(xié)同工作，提供比這些元素的總和都要大的協(xié)作行為。 ? 類圖通常包括以下內(nèi)容： – 類（ Classes） : 一個類是具有相同屬性、操作、關(guān)系和語義的對象的集合。這些操作可以有不同的可見特性（ visibility properties）、 并發(fā)特性（ concurrency properties）、 構(gòu)造型（ stereotype）、 標(biāo)記值（ tagged value） 和約束（ constraint） ? 畫操作時可以只顯示它們的名字，也可以將它們的跡（ signature） 和其它特性顯示出來 interface URLStreamHandler OpenConnection ParseURL() SetURL() ToExternalForm() Figure 22/ Operations in an Interface Class 接口類 （ Interface Classes） ? 接口類可成對地描述，分為“接口類”（ Interface Class） 和“應(yīng)用接口類” (Application Interface Class) – “基本接口類”駐留在接口一側(cè)的系統(tǒng)中，“應(yīng)用” 駐留在接口的另一側(cè) – 通常，由“應(yīng)用”調(diào)用的方法需要一個由“基本接口類”實(shí)現(xiàn)的結(jié)果 ? 在描述一個系統(tǒng)時，可使用兩中非常有用的接口類：接口類“框架”（ Framework） 和接口類“通用業(yè)務(wù)”（ Generic Service） – “框架”是一些類，這些類為一個域（ domain） 中的應(yīng)用描述一個可擴(kuò)展的模板。 ? 使用包可對為得到必需的接口類（ Interface Class）而需做進(jìn)一步分析的內(nèi)容進(jìn)行描述；另一方面，使用包可將在一個特定接口處所需要的接口類成組 Call Control Figure 20/ Example of a Package Figure 21/ Mapping Packages to Applications Call Control Authentication :a :b :c :d Messaging Application X Application Y Requires subelement a,b,c 步驟 3——接口類和類圖 （ Interface Classes and Class Diagrams） ? 接口有名字，一個接口是一個操作的集合，這些操作用于描述一個類（ class） 或一個構(gòu)件（ ponent） 提供的服務(wù)（ service）。 ? 包將語義上等價的元素成組，并且這些元素趨向于作為一個組而變化。在我們的方法中，應(yīng)用或業(yè)務(wù)由一些包構(gòu)成。 ? 對于功能實(shí)體的分配，應(yīng)該注意： – 一個功能實(shí)體原則上可分配到任何物理地點(diǎn) – 一些功能實(shí)體可被分配到同一物理地點(diǎn) – 對于每一補(bǔ)充業(yè)務(wù)，應(yīng)該定義包括其基本業(yè)務(wù)的功能實(shí)體的網(wǎng)絡(luò)場景（ work scenarios） – 功能實(shí)體分配在不同的物理地點(diǎn)可能表明節(jié)點(diǎn)在能力上有細(xì)微的不同 – 對于所使用的功能模型，功能實(shí)體對之間的關(guān)系應(yīng)該對所有推薦的場景保持不變 ? 在第 3階段定義信令協(xié)議、交換能力和業(yè)務(wù)能力時應(yīng)被考慮所有的場景 面向?qū)ο蠓椒ㄖ械牟襟E （ Alternative steps utilizing Object Oriented techniques） ? 在描述 IN接口時，可使用面向?qū)ο螅?OO） 的技術(shù)，也可使用非 OO技術(shù)，要么對同一接口使用 OO方法，要么使用非 OO方法。一個信息流可以是需要證實(shí)的，如果是需要證實(shí)的，需要一個具有相同名字的返回信息流 – 當(dāng)交互的功能實(shí)體在物理上分離的地點(diǎn)實(shí)現(xiàn)，信息流通常通過信令系統(tǒng)協(xié)議傳送 – 使用表來說明信息流中的每一項，并應(yīng)該指出每一項是否是必需的，或者是可選的，并且指出信息流通過哪個關(guān)系傳遞 步驟 4——功能實(shí)體動作 （ Functional entity actions） ? 對接收到每一信息流，標(biāo)識并列出來從接收到此信息流到發(fā)出由此而產(chǎn)生的結(jié)果信息流（ next resulting information flow ）這一段，功能實(shí)體中執(zhí)行的動作 ? 每一功能實(shí)體動作通過一個參考號碼（ reference number） 來標(biāo)識 步驟 5——功能實(shí)體的 SDL圖（可選） （ SDL diagrams for functional entities（ optional）） ? 根據(jù)提供業(yè)務(wù)時功能實(shí)體執(zhí)行的動作、由于動作而產(chǎn)生的信息流以及引起動作觸發(fā)的信息流，可用 SDL圖形表示形式地描述一個給定的業(yè)務(wù) ? 基于第 3步中產(chǎn)生的信息流圖， SDL圖詳細(xì)地描述了正常、不成功和異常的業(yè)務(wù)操作，并與信息流圖一致 ? SDL由 ITUT 。這樣一個交互稱為一個“信息流”，需要為信息流取個能夠說明此信息流目的的名字 – 需要繪制信息流圖（ information flow diagrams）來描述成功的業(yè)務(wù)操作所必需的所有信息流，同樣也需要為其它情況繪制信息流圖。另外，提供對所使用的SIB的定義的應(yīng)用（ reference）。 – 當(dāng)且僅當(dāng)補(bǔ)充業(yè)務(wù)的功能實(shí)體需要通信，并且基本業(yè)務(wù)中已定義的信息流并不能滿足這些通信需求時，才定義補(bǔ)充業(yè)務(wù)的功能實(shí)體之間的關(guān)系 基本業(yè)務(wù)模型與補(bǔ)充業(yè)務(wù)模型間的關(guān)系 （ Relationship between basic and supplementary service models） 步驟 2——業(yè)務(wù)屬性的 SIB描述 （ SIB description o