上傳人：2***

認(rèn)證信息

認(rèn)證類型：個(gè)人認(rèn)證

認(rèn)證主體：余**（實(shí)名認(rèn)證）

IP屬地：貴州

IP屬地：貴州 上傳時(shí)間：2022-07-20 格式：PPT 頁數(shù)：61 大小：617KB 積分：25 舉報(bào) 版權(quán)申訴

1、UML與面向?qū)ο蠓治?.1 面向?qū)ο竺嫦虺绦蛎嫦驍?shù)據(jù)面向?qū)ο竺嫦驅(qū)ο蠹夹g(shù)一定成功？理論上是成功的，但需要實(shí)踐上的配合。面向?qū)ο箝_發(fā)軟件的優(yōu)點(diǎn)：程序更容易重復(fù)使用程序更容易測(cè)試程序更容易維護(hù) 將程序分門別類，各司其職面向?qū)ο蟮娜秉c(diǎn)：面向?qū)ο笳Z言門檻較高面向?qū)ο笙到y(tǒng)分析難度高面向?qū)ο笙到y(tǒng)分析與設(shè)計(jì)所需的時(shí)間較長軟件系統(tǒng)的開發(fā)階段：需求分析階段系統(tǒng)分析階段系統(tǒng)設(shè)計(jì)階段程序設(shè)計(jì)階段測(cè)試階段安裝階段向?qū)ο蠹夹g(shù)可以省掉的是后段的時(shí)間與成本，包括程序設(shè)計(jì)、測(cè)試與維護(hù)都可以節(jié)省相當(dāng)可觀的成本。但前段時(shí)間與成本要增加許多。 在類設(shè)計(jì)上，依據(jù)RUP（Rational Unified Process）的設(shè)計(jì)理念，一

2、般會(huì)先找出三種類：Boundary Class（邊界類）：表示系統(tǒng)外部環(huán)境與內(nèi)部運(yùn)作之間交互的類(系統(tǒng)與系統(tǒng)之間、人與系統(tǒng)之間、某個(gè)類于系統(tǒng)之間)Control Class （控制類）：表示一個(gè)或多個(gè)Use Case 行為的類Entity Class（實(shí)體類）：表示系統(tǒng)保存的信息Note：在UML里面，Boundary 與 Interface 意義不同。Interface 指一組操作（方法）Boundary 指系統(tǒng)的邊界，指的是“類”BCE分類與三層結(jié)構(gòu)類似三層結(jié)構(gòu)下，會(huì)有三種類庫：User Services：包含所有的邊界類Business Services：包含所有的控制類Data Ser

3、vices：包含所有的實(shí)體類圖 Logical/main6.1 UMLUML講究的是以“交互式”、“漸進(jìn)式”的方法作分析，雛形出來之后，可以根據(jù)各種需要一步一步進(jìn)行分析修訂。目前Rational Rose已經(jīng)和面向系統(tǒng)分析劃上等號(hào)，但進(jìn)行OO分析為何會(huì)有正反兩派不同意見？OO分析采用“交互式”、“漸進(jìn)式”的開發(fā)方法，也就是分析一點(diǎn)、設(shè)計(jì)一點(diǎn)、修改一點(diǎn)，再分析、再設(shè)計(jì)，然后再修改，其目的為使整套系統(tǒng)的模型更加完整、清晰。因此分析設(shè)計(jì)階段會(huì)拉長。由此缺點(diǎn)，某些軟件公司認(rèn)為前置時(shí)間比較長，成本較高，但實(shí)際上前面做的好，可以省下后續(xù)程序設(shè)計(jì)、測(cè)試以及維護(hù)的時(shí)間，事實(shí)上反而比較省成本。6.2 Use C

4、ase以UML進(jìn)行面向?qū)ο蠓治龆挤浅Ｆ赜赨se Case的分析。在傳統(tǒng)的軟件開發(fā)過程中，流程圖時(shí)最重要的，而在新一代面向?qū)ο笙到y(tǒng)分析領(lǐng)域，Use Case則占了60%以上。過去評(píng)估軟件開發(fā)的成本時(shí)，常會(huì)以系統(tǒng)的功能數(shù)乘上所需人數(shù)，再乘以系統(tǒng)分析人員、系統(tǒng)設(shè)計(jì)人員的成本，或以程序的個(gè)數(shù)乘上程序設(shè)計(jì)人員的成本。而在面向?qū)ο蠹夹g(shù)里，習(xí)慣以Use Case的數(shù)目乘以開發(fā)的周期數(shù)（Iterations），再乘以每一周期的開發(fā)成本。面向?qū)ο笈cUse Case未引入“Use Case”時(shí)，要找出軟件系統(tǒng)的對(duì)象多半是個(gè)人自憑本事。通過Use Case的分析，終于使軟件系統(tǒng)的對(duì)象尋找機(jī)制有了一定的參照標(biāo)準(zhǔn)。U

5、se Case：由系統(tǒng)所執(zhí)行的一連串操作順序，其結(jié)果會(huì)對(duì)特定的“Actor”產(chǎn)生可觀察的結(jié)果值。傳統(tǒng)系統(tǒng)分析主要以“面向功能”的方式針對(duì)系統(tǒng)的功能說明系統(tǒng)需求。Use Case分析則是先定義處系統(tǒng)的邊界，將系統(tǒng)范圍理清楚，再通過后續(xù)的順序圖、類圖找出相關(guān)的對(duì)象、Interface或組件。例：便利店購物流程覺得好渴，進(jìn)入便利店逛逛；順便翻翻架上的雜志；到飲料柜，選了一罐可樂；到柜臺(tái)付賬；拉開拉環(huán)看有沒有中獎(jiǎng)，沒中獎(jiǎng)覺得好失望；喝可樂，舒服！如何做這個(gè)便利店管理信息系統(tǒng)？傳統(tǒng)的系統(tǒng)分析方式一看就知道要分析的是付賬、扣除庫存那一段流程。因此比較資深的系統(tǒng)分析員就會(huì)想象出這樣的畫面： 問題：一個(gè)生手如

6、何開始分析？利用 Use Case 與Actor的方式，對(duì)流程進(jìn)行分析，而且后續(xù)可以針對(duì)Use Case找出相關(guān)的對(duì)象與類找出人為的Actor：消費(fèi)者店員翻看雜志的路人甲：如果未購買則與本系統(tǒng)無關(guān)，若有購買，則也是消費(fèi)者店長：管理便利店資源。未發(fā)現(xiàn)與本系統(tǒng)有交互。若店長值班，則也是店員。 外部系統(tǒng)與此系統(tǒng)交互的其他系統(tǒng)，可以先采用假定的方式，說不定分析到后面發(fā)現(xiàn)它也是本系統(tǒng)的一個(gè)子系統(tǒng)。以付賬、扣庫存的角度來看，可能有總帳系統(tǒng)庫存管理系統(tǒng)這樣分析出4個(gè)Actor消費(fèi)者店員總帳系統(tǒng)庫存管理系統(tǒng)圖Store0情境（Scenario）：一連串的操作順序一個(gè)Use Case里面可能有相當(dāng)多的操作，以不

7、同的順序進(jìn)行，每一串操作順序都可以情境。以“買飲料”的流程看，現(xiàn)金購買是一種情境，刷卡購買也是一種情境。刷偷來的卡被逮到，也是一種情境。se Case的情境分為三種：主事件流（Main Flow）其它事件流（Alternative Flow）異常事件流（Exceptional Flow）找出Use Case 就Actor而言，必須與所要分析的系統(tǒng)產(chǎn)生交互就Use Case而言，必須對(duì)特定Actor產(chǎn)生可觀察的結(jié)果值圖（候選Use Case）Store2原則上是不編號(hào)的命名規(guī)則：動(dòng)詞+名詞由于對(duì)象里面一定包含有“操作”和“屬性”，Use Case中的動(dòng)詞部分，將來可以作為對(duì)象中的操作，名詞部分可

8、以作為對(duì)象中的“屬性”將Actor與Use Case 聯(lián)系起來分析 Use Case 4，是有用的，與“記賬”、“扣除庫存”有關(guān)分析1，5，6，產(chǎn)生的是心理作用，不符合“可觀察的結(jié)果值”，去掉檢討2，3若僅是購買飲料的流程看，2，3是與電腦系統(tǒng)無關(guān)的。但若考慮到Total Solution，則是有意義的圖Store3細(xì)線箭頭代表與Use Case交互的方向，箭頭來源為輸入端，目的為輸出端。若不清楚輸入輸出，可暫時(shí)不加。-泛化關(guān)系 ，與情境 都是可行的 （刷卡機(jī)與收銀機(jī)是否分離）問題：光找出Use Case就可以寫出程序了嗎？就有對(duì)象了嗎？運(yùn)用Use Case的目的在于合理訂出系統(tǒng)的需求及范圍，

9、以免后來徒勞無功 圖Store4Use Case與程序圖store4目前僅發(fā)展到查詢商品信息和銷售商品兩項(xiàng)，功能有限，實(shí)在不宜稱為“便利店”Total Solution。我們需要明確定出現(xiàn)有Use Case的范圍與功能，其它功能將在后續(xù)分析中完成。查詢商品信息：提供客戶進(jìn)行商品查詢銷售商品：提供店家進(jìn)行商品銷售管理程序 是根據(jù)功能得出來的，Use Case則是發(fā)展分析而來的。以“銷售商品”子系統(tǒng)而言，可以具有以下的功能：銷售商品-折扣退回變價(jià)組合商品批發(fā)子菜單各為一個(gè)程序。而Use Case卻不同，絕無所謂的程序概念，只有“對(duì)象”或組件的概念，甚至在高層次的分析階段，連“對(duì)象”與“組件”都看不

10、到，除了Use Case與Actor，什么都沒有。另外，從消費(fèi)者的角度進(jìn)行分析，消費(fèi)者指向“銷售商品”也是不合理的（消費(fèi)者哪里需要輸入什么數(shù)據(jù)？都是店家輸入的），故銷售商品應(yīng)改由店員的角度進(jìn)行分析。圖Store5Note: 原來消費(fèi)者銷售商品的線，改成由銷售管理消費(fèi)者了。這是有意義的圖Store5發(fā)現(xiàn)銷售管理消費(fèi)者的秘密了嗎？第二個(gè)特殊要求；Sell Goods要印出發(fā)票給消費(fèi)者。但是Sell Goods（銷售管理）只是計(jì)算機(jī)，所以以上工作要由店員來做。修改圖：圖Store6順便畫出了消費(fèi)者的屬性，強(qiáng)調(diào)消費(fèi)者將被設(shè)計(jì)為一個(gè)對(duì)象銷售管理消費(fèi)者的虛線，“相關(guān)關(guān)系”，表示銷售管理要向消費(fèi)者要數(shù)據(jù)沒有

11、“打印發(fā)票”，因?yàn)閲乙?guī)定銷貨一定要打印發(fā)票，所以包含在銷售管理的流程里面了圖Store6Use Case 與對(duì)象前面已經(jīng)在消費(fèi)者下添加了兩個(gè)屬性，下面繼續(xù)在“銷售管理”中查找其他對(duì)象在Rational Rose中發(fā)現(xiàn)和定義對(duì)象：將Actor 加入Logic View根據(jù)Use Case，一個(gè)一個(gè)想象可選用的對(duì)象，這些候選對(duì)象，將來可能是對(duì)象，也可能不是對(duì)象。從順序圖中加入對(duì)象，也可將既有的對(duì)象加入順序圖。根據(jù)Boundary Class，Control Class以及 Entity Class的概念找出對(duì)象，其中Control Class在順序圖中比較容易出現(xiàn)，要一邊畫順序圖，一邊找對(duì)象。

12、也可以根據(jù)Use Case說明書中的敘述，簡單制作相關(guān)的類。不要太貪心，一次加一堆類，或者一次加很多屬性、操作。尋找Use Case名、說明書中比較重要的名詞不屬于這個(gè)階段該加入的類，勿強(qiáng)行加入。比如某些控制類，因?yàn)橐院笞匀粫?huì)找出來。針對(duì)Use Case的范圍適當(dāng)加入類。加入類時(shí)，如該類已存在，則檢討該類是否恰當(dāng)，或者酌量加入新的屬性及操作。思考“銷售管理”和“查詢商品信息”，找出可加入的類：消費(fèi)者店員商品發(fā)票發(fā)票明細(xì)成分便利店在“銷售管理”里面，除了“成分”外，其余類皆會(huì)用到。圖 Logical View/StoreClass1以上每一種類均可對(duì)應(yīng)到三層結(jié)構(gòu)中的每一層Boundary Cla

13、ss，客戶端，用戶界面Control Class Entity，中間層：組件Entity Class，數(shù)據(jù)庫端Use Case運(yùn)作機(jī)制Use Case的范圍（例如：進(jìn)、銷、存）Actor 異常事件流通過這三者的相互運(yùn)作以及精確分析，才可以規(guī)劃出一套信息系統(tǒng)的需求。光這樣還不夠，新手與老手所規(guī)劃的Use Case可能有所不同。圖Store7Store86.3、Use Case 高級(jí)分析技巧 Use Case 說明書 與傳統(tǒng)軟件開發(fā)過程中慣用的“需求說明書”相比，是類似的，都是要與用戶確認(rèn)的文件。就概念上而言，用戶的一項(xiàng)需求經(jīng)過分析之后，可能會(huì)是好幾個(gè)Use Case。在“說明”欄，指出使用時(shí)機(jī)，

14、該操作何時(shí)執(zhí)行，包括涉及到用戶之間的權(quán)限區(qū)分。在進(jìn)行Use Case分析時(shí)，最怕遇到明顯的AUDI類型的操作。以傳統(tǒng)眼光來看，一般的Use Case均是新增、修改、刪除或查詢交相混雜的。而目前的系統(tǒng)分析人員都是由傳統(tǒng)系統(tǒng)分析起家的，因此著手的角度很容易受到AUDI 的限制，所分析出來的Use Case就會(huì)失去對(duì)象的精神。基本事件流 與 傳統(tǒng) 的 操作流程類似。但是“流程圖”無法與后續(xù)文檔或其他圖形之間相互修改。對(duì)于圖Store9(good)(bad)AUDI類型的Use Case 對(duì)于圖Store9(good)圖AUDI1至少有10條理由說明上述分析時(shí)錯(cuò)的“新增商品信息”有時(shí)候并非單純新增數(shù)據(jù)

15、，比如需要判斷是否已有重復(fù)的、類似的商品名，所以包含“查詢功能”。“修改商品信息”也要用到查詢。“刪除商品信息”有時(shí)候并不是真正刪除，只是加上一個(gè)標(biāo)記而已，嚴(yán)格說應(yīng)該算是Update吧“修改商品信息”更不簡單了，通常會(huì)用到很多的條件，比如By 商品名稱，供應(yīng)商等等。由店員輸入數(shù)據(jù)也是錯(cuò)誤的。商品信息應(yīng)該是由總部統(tǒng)一維護(hù)的。雖然不允許各店店員輸入修改商品信息，但是允許他們查詢商品信息的。所以這里的Actor可能就不止一個(gè)（一類），而且不同的Actor的查詢方式可能差異很大。前面的Use Case 1，2，3 都具有“更新庫存數(shù)量”功能，這算不算“修改商品信息”？因此說這里的“修改商品信息”說的太

16、大，實(shí)際是“修改商品的價(jià)格與數(shù)量以外的信息”促銷時(shí)的“組合商品”怎么加管理？“新增組合商品信息”？“新增商品信息”中如果商品有條碼，編碼怎么處理？需要提供系統(tǒng)自動(dòng)產(chǎn)生編碼、用戶輸入代碼兩種方式。刪除的情況，除了增加刪除標(biāo)記以外，還需要有真正清除的功能。為什么呢？問題在于以傳統(tǒng)的數(shù)據(jù)處理方式分析Use Case本身就是錯(cuò)的。這種分析方式也可能會(huì)對(duì)，但絕對(duì)是壞的 限制了Use Case的思考范圍命名容易讓人誤會(huì)U 和I類型的Use Case通常會(huì)結(jié)合在一起，違反“Use Case”一次只完成一件事的原理。Q通常會(huì)與其他的具有“使用關(guān)系”圖AUDI2圖AUDI2 更貼近現(xiàn)實(shí)的分析命名：盡量以“動(dòng)詞+

17、名詞”的形式命名盡可能避免 Add, Modify,Delete等字眼為配合面向?qū)ο蠹夹g(shù)，可考慮以Create代表構(gòu)造某一種對(duì)象不應(yīng)該針對(duì)“數(shù)據(jù)庫交易”繪制出圖，而是根據(jù)企業(yè)流程來繪制較為完整的圖AUDI3使用關(guān)系 和 相關(guān)關(guān)系較為完整的圖AUDI3系統(tǒng)Actor與企業(yè)Actor客戶可以下單，業(yè)務(wù)助理也可以下單，只是分析的層次不同而已。客戶下單的方式：網(wǎng)絡(luò)下單，短信下單，傳真下單。前兩種是客戶直接與系統(tǒng)交互，而后一種的操作者是業(yè)務(wù)助理，客戶是間接操作者企業(yè)模型與系統(tǒng)模型就“傳真下單”而言，在企業(yè)模型里面，業(yè)務(wù)助理是屬于系統(tǒng)范圍里面的，嚴(yán)格的說會(huì)變成一個(gè)“邊界”企業(yè)模型與技術(shù)無關(guān)，技術(shù)變更時(shí)，不

18、會(huì)影響到Use Case系統(tǒng)模型與技術(shù)息息相關(guān)，可直接描述出與信息系統(tǒng)交互的操作者。但技術(shù)變更時(shí)，操作者可能會(huì)有變更。Use Case 命名以“動(dòng)詞+名詞”的方式命名編號(hào)規(guī)則一個(gè)Use Case應(yīng)該只具有一項(xiàng)目的，名稱過長的應(yīng)該是兩個(gè)或多個(gè)順序圖命名編號(hào)#0代表成功情境，其余編號(hào)代表異常情境編號(hào)之后加上Use Case名稱最后再加上成功或失敗，失敗簡要說明原因比如：#1_Create_goods_info_login_fail需求應(yīng)該有層次地組織起來，具體方法是：一般系統(tǒng)的高層需求應(yīng)該用不超過12個(gè)左右的Use Case 表示出來。在接下來的層次，Use Case 的數(shù)量不應(yīng)超過上層用例數(shù)的5

19、到10倍。在每一級(jí)別上覆蓋所有類別的系統(tǒng)需求。第n+1層不應(yīng)該引入任何新的需求類別，但可以分解已存在的需求。如果在較低級(jí)別上，一個(gè)細(xì)化過的Use Case被發(fā)現(xiàn)不屬于任何以存在的類別，則所有較高級(jí)別的用例層次應(yīng)該更新。用例最佳開發(fā)方式是迭代式和遞增式的。客戶和項(xiàng)目管理員 用 Use Case Diagram 取得系統(tǒng)的高級(jí)視圖，確定項(xiàng)目范圍；項(xiàng)目管理員 用 Use Case Diagram 和 Use Case 文檔將項(xiàng)目分解成可管理的小塊；分析人員和客戶 使用 Use Case 文檔 了解系統(tǒng)提供的功能；文檔人員 通過 Use Case 文檔 了解系統(tǒng)提供的功能，編寫用戶手冊(cè)和培訓(xùn)計(jì)劃；分析

20、人員和開發(fā)人員 用 Sequence Diagram 和 Collaboration Diagram 了解系統(tǒng)的邏輯流程、系統(tǒng)中的對(duì)象及對(duì)象間的消息；質(zhì)量保證人員 用 Use Case 文檔、Sequence Diagram 和 Collaboration Diagram 取得測(cè)試腳本所需要的信息；開發(fā)人員用 Class Diagram 和 State Diagram 取得系統(tǒng)各部分的細(xì)節(jié)及其相互關(guān)系的信息；部署人員 用 Component Diagram 和 Deployment Diagram 顯示用生成的執(zhí)行文件、DLL文件和其他組件及這些組件在網(wǎng)絡(luò)上的部署位置；整個(gè)小組用模型來確保代碼中遵守了需求，保證代碼能夠回溯到需求。6.4、分析階段的類三層結(jié)構(gòu)表現(xiàn)層中間層數(shù)據(jù)層UML中，三層分別對(duì)應(yīng)于三個(gè)類：Boundary ClassControl ClassEntity Class從Use Case中找出相關(guān)類后，可再從BCE方式找出更多類Use CaseBCECreate a GoodsInfoCreateGoodsInfoUICreateGoodsProcess商品銷售商品SellGoodsUISellGoodsPr