第一講軟件工程概論與需求分析2024/8/301內(nèi)容軟件危機軟件工程傳統(tǒng)開發(fā)模式面向?qū)ο竽Ｊ経ML需求分析基于用例的需求分析2024/8/3021.軟件危機1.1從千年蟲問題談起千年蟲如同一個定時炸彈一樣，十幾年前就有人提出了預警，但是無人注意直到日期到來的前兩年，才引起了恐慌2024/8/3041.2軟件危機的提出“軟件危機”是1958年在NATO會議上作為一個正式的議題被提出來軟件項目不成功的例子比比即是：1999年10月，耗資1.25億美元的NASA的火星氣象衛(wèi)星失蹤，據(jù)信這是由于簡單的數(shù)據(jù)轉(zhuǎn)換錯誤所導致的。人們發(fā)現(xiàn)衛(wèi)星軟件中，有些數(shù)據(jù)使用英制，它們應被轉(zhuǎn)換成公制。這個衛(wèi)星應當充當另一項任務中的火星極地著陸項目的通信轉(zhuǎn)發(fā)器，那個任務也失敗了，原因不明。2024/8/305美國IBM公司在1963年至1966年開發(fā)的IBM360機的操作系統(tǒng)。這一項目花了5000人一年的工作量，最多時有1000人投入開發(fā)工作，寫出了近100萬行源程序。......據(jù)統(tǒng)計，這個操作系統(tǒng)每次發(fā)行的新版本都是從前一版本中找出1000個程序錯誤而修正的結(jié)果。......這個項目的負責人F.D.Brooks事后總結(jié)了他在組織開發(fā)過程中的沉痛教訓時說：“......正像一只逃亡的野獸落到泥潭中做垂死的掙扎，越是掙扎，陷得越深，最后無法逃脫滅頂?shù)臑碾y。......程序設計工作正像這樣一個泥潭，......一批批程序員被迫在泥潭中拼命掙扎，......誰也沒有料到問題竟會陷入這樣的困境......”。IBM360操作系統(tǒng)的歷史教訓成為軟件開發(fā)項目的典型事例為人們所記取。2024/8/3062024/8/3072024/8/308一些數(shù)據(jù)：大約70％的軟件開發(fā)項目超出了估算的時間，大型項目平均超出計劃交付時間20％到50％，90％以上的軟件項目開發(fā)費用超出預算，并且項目越大，超出項目計劃的程度越高美國政府審計局：只有不到2％的合同定購軟件在發(fā)布時具有可用性——98％以上的項目都失敗了2024/8/3092.軟件工程2.1定義Boehm：運用現(xiàn)代科學技術知識來設計并構(gòu)造計算機程序及為開發(fā)、運行和維護這些程序所必需的相關文件資料IEEE：軟件工程是開發(fā)、運行、維護和修復軟件的系統(tǒng)方法FritzBauer：建立并使用完善的工程化原則，以較經(jīng)濟的手段獲得能在實際機器上有效運行的可靠軟件的一系列方法2024/8/30112.2要素軟件工程三要素：方法、工具和過程軟件工程方法為軟件開發(fā)提供了“如何做”的技術軟件工具為軟件工程方法提供了自動的或半自動的軟件支撐環(huán)境軟件工程過程定義了:

方法使用的順序要求交付的文檔資料為保證質(zhì)量和適應變化所需要的管理軟件開發(fā)各個階段完成的里程碑2024/8/30122.3原理⑴用分階段的生命周期計劃嚴格管理

項目概要計劃

里程碑計劃

項目控制計劃

產(chǎn)品控制計劃

驗證計劃

運行維護計劃⑵堅持進行階段評審⑶實行嚴格的產(chǎn)品控制——基準配置管理(Baselineconfigurationmanagement)⑹開發(fā)小組的成員應該少而精1+1<2⑷采用現(xiàn)代程序設計技術⑸結(jié)果應能清楚地審查—setstandards⑺承認不斷改進軟件工程實踐的必要性2024/8/30133.傳統(tǒng)開發(fā)模式3.1瀑布模型瀑布模型(WaterfallModel)

維護開發(fā)定義DefinitionFeasibilityStudyRequirementsAnalysisProgramDesignCoding&ModuleTestingIntegration&SystemTestingDelivery&MaintenanceSystemDesign2024/8/3015(1)問題定義和可行性研究確定要開發(fā)軟件系統(tǒng)的總目標給出功能、性能、可靠性以及接口等方面的要求完成該軟件任務的可行性研究估計可利用的資源(計算機硬件，軟件，人力等)、成本、效益、開發(fā)進度制定出完成開發(fā)任務的實施計劃,連同可行性研究報告，提交管理部門審查2024/8/3016(2)需求分析對待開發(fā)軟件提出的需求進行分析并給出詳細的定義編寫軟件需求說明書或系統(tǒng)功能說明書及初步的系統(tǒng)用戶手冊提交管理機構(gòu)評審2024/8/3017(3)設計總體設計—“如何解決問題”可以列出多種解決方案進行比較把各項需求轉(zhuǎn)換成軟件的體系結(jié)構(gòu)。結(jié)構(gòu)中每一組成部分都是意義明確的模塊，每個模塊都和某些需求相對應詳細設計—對每個模塊要完成的工作進行具體的描述，為源程序編寫打下基礎編寫設計說明書，提交評審。2024/8/3018(4)編碼把軟件設計轉(zhuǎn)換成計算機可以接受的程序代碼，即寫成以某一種特定程序設計語言表示的“源程序清單”寫出的程序應當是結(jié)構(gòu)良好、清晰易讀的，且與設計相一致的2024/8/3019(5)測試單元測試，查找各模塊在功能和結(jié)構(gòu)上存在的問題并加以糾正組裝測試，將已測試過的模塊按一定順序組裝起來按規(guī)定的各項需求，逐項進行有效性測試，決定已開發(fā)的軟件是否合格，能否交付用戶使用2024/8/3020(6)運行和維護改正性維護運行中發(fā)現(xiàn)了軟件中的錯誤需要修正適應性維護為了適應變化了的軟件工作環(huán)境，需做適當變更完善性維護為了增強軟件的功能需做變更2024/8/30213.2瀑布模型的特點⑴順序性、依賴性⑵推遲程序的物理實現(xiàn)⑶質(zhì)量保證的觀點——階段文檔與評審的要求，利于盡早發(fā)現(xiàn)錯誤。易于組織，易于管理缺點？需求變化后引起的代價將很高2024/8/3022結(jié)構(gòu)分析設計過程

階段關鍵問題結(jié)束標準問題定義問題是什么？關于規(guī)模和目標的報告書可行性研究有可行的解嗎？系統(tǒng)的高層邏輯模型數(shù)據(jù)流圖成本/效益分析需求分析系統(tǒng)必須做什么？系統(tǒng)的邏輯模型數(shù)據(jù)流圖數(shù)據(jù)字典算法描述

2024/8/3023結(jié)構(gòu)分析設計過程

階段關鍵問題結(jié)束標準總體設計概括地說，應該如何解決這個問題？可能的解法：系統(tǒng)流程圖成本/效益分析推薦的系統(tǒng)結(jié)構(gòu)；層次圖或結(jié)構(gòu)圖詳細設計怎樣具體地實現(xiàn)這個系統(tǒng)？編碼規(guī)格說明：HIPO圖或PDL編碼和單元測試正確的程序模塊源程序清單；單元測試方案和結(jié)果綜合測試符合要求的軟件綜合測試方案和結(jié)果；完整一致的軟件配置維護持久地滿足用戶需要的軟件完整準確的維護記錄2024/8/3024本質(zhì)上是功能分解，以實現(xiàn)功能的過程為中心，而用戶的需求變化主要是針對功能的。這就使基于過程的設計不易被理解；且功能變化往往引起結(jié)構(gòu)變化較大，穩(wěn)定性不好。系統(tǒng)有明確的邊界定義，且系統(tǒng)結(jié)構(gòu)依賴于系統(tǒng)邊界的定義，這樣的系統(tǒng)不易擴充和修改。數(shù)據(jù)與操作分開處理，可能造成軟構(gòu)件對具體應用環(huán)境的依賴，可重用性(reusability)較差.結(jié)構(gòu)化技術的缺點2024/8/30254.面向?qū)ο竽Ｊ?.1面向?qū)ο蠓治觥⒃O計與編碼面向?qū)ο蟮姆治觯∣OA）分析問題論域，找出問題解決方案，發(fā)現(xiàn)對象，分析對象的內(nèi)部構(gòu)成和外部關系，建立軟件系統(tǒng)的對象模型面向?qū)ο蟮脑O計（OOD）根據(jù)已確定的系統(tǒng)對象模型，運用面向?qū)ο蠹夹g，進行系統(tǒng)軟件設計面向?qū)ο蟮木幋a2024/8/3027(1)面向?qū)ο蟮姆治鰡栴}論域分析業(yè)務范圍，業(yè)務規(guī)則，業(yè)務處理過程，確定系統(tǒng)的責任，范圍和邊界，確定系統(tǒng)的需求發(fā)現(xiàn)和定義對象和類識別對象和類，確定它們的內(nèi)部特征：屬性和操作，這是一個抽象過程識別對象的外部聯(lián)系對象與對象，類與類之間的各種外部聯(lián)系，包括一般與特殊，整體與部分，實例連接（關聯(lián)），消息連接等建立系統(tǒng)的靜態(tài)結(jié)構(gòu)模型對象類圖和對象圖，系統(tǒng)與子系統(tǒng)結(jié)構(gòu)圖等，繪制相應的圖建立系統(tǒng)的動態(tài)行為模型對象之間的交互關系等2024/8/3028(2)面向?qū)ο蟮脑O計設計對象和類具體設計對象和類的屬性，操作，設計對象與類的各種外部聯(lián)系的實現(xiàn)結(jié)構(gòu)，設計消息與事件的內(nèi)容、格式等設計系統(tǒng)結(jié)構(gòu)設計組件與子系統(tǒng)，以及它們的相互的靜態(tài)和動態(tài)關系設計問題論域子系統(tǒng)負責領域的業(yè)務服務設計人機交互系統(tǒng)設計數(shù)據(jù)管理子系統(tǒng)設計任務管理子系統(tǒng)進程管理設計優(yōu)化，提高系統(tǒng)性能2024/8/3029(3)比較結(jié)構(gòu)化設計方法以功能分解為中心面向?qū)ο蠓椒ㄗ匀坏匾哉撚蛑械膶ο笞鳛檐浖幕痉治龊驮O計單元，改善了軟件的可理解性，可重用性2024/8/30305.UML5.1UML歷史面向?qū)ο蟮姆治雠c設計(OOA＆D)方法的發(fā)展在80年代末至90年代中出現(xiàn)了一個高潮.UML是這個高潮的產(chǎn)物。它不僅統(tǒng)一了Booch、Rumbaugh和Jacobson的表示方法，而且對其作了進一步的發(fā)展，并最終統(tǒng)一為大眾所接受的標準建模語言。2024/8/3032三個好朋友

2024/8/30335.2UML定義UML(統(tǒng)一建模語言)是為軟件系統(tǒng)的制品進行描述（specifying）、可視化（visualizing）、構(gòu)造（constructing）、文檔化（documenting）的一種語言。它同樣適用于商業(yè)模塊和其他非軟件系統(tǒng)。在大型和復雜系統(tǒng)的建模中，UML成功地描述一些優(yōu)秀的工程實施。2024/8/3034曹操孫權(quán)Environment

話說三國演義OOAD

適用于社會組織法分析(Domain)西蜀2024/8/3035曹操孫權(quán)Environment

劉備關羽孔明張飛赤壁之戰(zhàn)其它流程(Domain)西蜀曹操進兵引發(fā)西蜀的流程誰來執(zhí)行流程呢?2024/8/3036

OOAD最關心流程與元素

1.描述流程(劇情)----分析

赤壁之戰(zhàn)其它流程2.安排主/配角(元素)演出----設計劉備關羽孔明張飛2024/8/3037

OOAD最主要的工具

UML(Unified

Modeling

Language)

OMG

認可的世界標準

19972024/8/3038

為什么需要

UML呢?

貝多芬作曲時使用五線譜您設計軟件時使用UML2024/8/3039

為什么需要

UML呢?

五線譜有多種音符UML也有多種符號劉備孔明關羽曹操赤壁之戰(zhàn)其它流程空城計退敵

UseCase圖

Sequence圖2024/8/3040

UseCase敘述

曹操舉兵南下,西蜀就擬定策略,展開部署並聯(lián)絡孫權(quán),鼎力對抗曹操大軍.曹操赤壁之戰(zhàn)孫權(quán)西蜀

把西蜀看成黑箱!!

準備打開西蜀黑箱2024/8/3041

Scenario敘述

曹操赤壁之戰(zhàn)孫權(quán)

把西蜀黑箱打開!!

劉備關羽孔明張飛2024/8/3042

Scenario敘述

曹操赤壁之戰(zhàn)孫權(quán)劉備關羽孔明張飛

曹操舉兵南下,劉備請孔明擬定策略.派遣關羽和張飛防守荊州,同時請孔明聯(lián)絡孫權(quán),共同對抗曹操.孔明聯(lián)合孫權(quán),借東風,火燒曹軍于赤壁.2024/8/3043

Scenario敘述

使用UML

表示之2024/8/3044

Scenario敘述

劉備孔明關羽求戰(zhàn)請擬定策略張飛請防守荊州請防守荊州前線孫權(quán)曹操請聯(lián)絡孫權(quán)請孫權(quán)領兵相助借東風火攻火攻曹軍2024/8/3045劉備的責任?

劉備求戰(zhàn)請擬定策略請防守荊州請聯(lián)絡孫權(quán)我必需迎戰(zhàn)曹操!!2024/8/3046使用UML表示-----類圖

劉備求戰(zhàn)劉備迎戰(zhàn)曹操迎戰(zhàn)曹操迎戰(zhàn)曹操迎戰(zhàn)曹操迎戰(zhàn)曹操迎戰(zhàn)曹操2024/8/3047使用UML表示

孔明請擬定策略請聯(lián)絡孫權(quán)請孫權(quán)領兵相助借東風火攻火攻曹軍孔明擬定策略聯(lián)合孫權(quán)借東風火攻2024/8/3048使用UML表示

關羽張飛請防守荊州請防守荊州前線關羽防守荊州張飛防守荊州前線2024/8/3049

關羽防守荊州張飛防守荊州前線劉備迎戰(zhàn)曹操孔明擬定策略聯(lián)合孫權(quán)借東風火攻UML的Class圖

您已熟悉UseCaseSequence圖Class圖現(xiàn)在準備進入OOP階段2024/8/30503.

認識

OOP

OOP階段的任務

----銜接OOAD的工作----從UML到Java----從Java

到組件2024/8/3051

使用Java

劉備迎戰(zhàn)曹操寫Java程序‘Class劉備Method

迎戰(zhàn)曹操()……EndMethod2024/8/3052

孔明擬定策略聯(lián)合孫權(quán)借東風火攻使用Java

寫Java程序‘Class孔明Method

擬定策略()……EndMethodMethod

聯(lián)合孫權(quán)()……EndMethodMethod

借東風火攻()……EndMethod2024/8/3053‘Class劉備Method

迎戰(zhàn)曹操()……EndMethod使用VisualBasic‘Class孔明Method

擬定策略()……EndMethodMethod

聯(lián)合孫權(quán)()……EndMethodMethod

借東風火攻()……EndMethod‘Class關羽Method

防守荊州()……EndSub‘Class張飛Method

防守前線()……EndMethod依樣畫葫蘆準備填寫Method內(nèi)容2024/8/3054

寫Java程序內(nèi)容

劉備求戰(zhàn)請擬定策略請防守荊州請聯(lián)絡孫權(quán)寫Java程序‘Class劉備孔明

k;關羽

g;Public劉備（孔明k1,關羽g1）Public

迎戰(zhàn)曹操(){

k.擬定策略

g.防守荊州

k.聯(lián)合孫權(quán)}2024/8/3055寫Java程序內(nèi)容

孔明請擬定策略請聯(lián)絡孫權(quán)請孫權(quán)領兵相助借東風火攻借東風火攻寫Java程序‘Class孔明DimsAs孫權(quán)Function

擬定策略()……EndFunctionSub

聯(lián)合孫權(quán)()

s.請領兵相助

s.借東風火攻EndSubSub

借東風火攻()……EndSub2024/8/3056寫VB代碼

‘Class劉備DimkAsNew孔明DimgasNew關羽Sub

迎戰(zhàn)曹操()

k.擬定策略

g.防守荊州

k.聯(lián)合孫權(quán)EndSub‘Class孔明DimsAs孫權(quán)Function

擬定策略()……EndFunctionSub

聯(lián)合孫權(quán)()

s.請領兵相助

s.借東風火攻EndSubSub

借東風火攻()……EndSub2024/8/3057寫Java代碼

把Java類編譯為Class組件JVM2024/8/30586.需求分析6.1概述軟件產(chǎn)品建造的第一步：需求分析根據(jù)用戶對產(chǎn)品的功能的期望,提取出產(chǎn)品外部功能的描述。2024/8/30606.2需求分析的困難性2024/8/30617.需求分析與UML7.1需求分析的途徑：用例視圖用例視圖——支持產(chǎn)品外部功能描述的視圖用例視圖從軟件產(chǎn)品的使用者的角度而不是開發(fā)者的角度，描述用戶對待開發(fā)的產(chǎn)品的需求，分析產(chǎn)品所需的功能、動態(tài)行為因此需要容易理解2024/8/30637.2軟件的外部特征當軟件的使用者考查一個軟件產(chǎn)品的功能時，其考慮的內(nèi)容通常包括：軟件的功能的設置的合理性軟件的運行效率軟件功能使用的方便程度這些內(nèi)容是軟件產(chǎn)品的外部特性，是軟件系統(tǒng)通過其邊界呈現(xiàn)給用戶的特性外部特性通常是動態(tài)的，通過外部特性，軟件系統(tǒng)的使用價值得到了體現(xiàn)呈現(xiàn)在軟件系統(tǒng)的邊界上的外部特征，是由軟件系統(tǒng)的內(nèi)部實現(xiàn)決定的，但是，對于軟件系統(tǒng)的使用者而言，軟件功能的內(nèi)部實現(xiàn)不是他們關心的問題，他們所關心的只是其所需要的功能是否以令其滿意的方式得到了實現(xiàn)2024/8/30647.3需求分析原則分析軟件系統(tǒng)的功能設置時，應該把重點放在描述軟件系統(tǒng)的外部邊界上，即重點考慮用戶對軟件系統(tǒng)的功能設置的合理性、方便性和運行效率的要求，而不應該在需求分析階段就過多地考慮軟件系統(tǒng)的結(jié)構(gòu)和內(nèi)部實現(xiàn)機制。這是在對軟件系統(tǒng)進行需求分析時，應該遵循的一個重要原則

2024/8/30657.4需求分析內(nèi)容/1軟件系統(tǒng)不是孤立存在的，不但需要分析共有哪些用戶將要使用軟件系統(tǒng)，而且還需要分析軟件系統(tǒng)的運行結(jié)果將要對哪些對象產(chǎn)生影響，這包括：指定運行結(jié)果的輸出和存儲的媒介指定被軟件系統(tǒng)運行結(jié)果控制的硬件設備如顯示器、打印機、工業(yè)機器人、數(shù)控機床等2024/8/3066當提取出了軟件系統(tǒng)運行的外部環(huán)境中與之交互的對象之后，需要為這些對象與軟件系統(tǒng)進行的交互指定具體內(nèi)容。這包括：對交互中包含的動態(tài)行為進行詳細描述還包括對這些動態(tài)行為進行合理的分類和組織使得這些動態(tài)行為所代表的軟件系統(tǒng)的功能的設置能為用戶提供其所需的價值，并具備令用戶滿意的易用性和效率媒介：交互圖狀態(tài)圖2024/8/30678.用例建模8.1活動者(1)概述對軟件產(chǎn)品的需求分析就是定義軟件系統(tǒng)的邊界，包括兩個方面的內(nèi)容：分析軟件產(chǎn)品與外界的聯(lián)系確定軟件產(chǎn)品與外界的聯(lián)系時包含動態(tài)行為及其相互關系在UML中，下列建模元素為上述兩個方面的內(nèi)容提供支持：活動者(actor)用例(usecase)它們存在于用例視圖中，所在模型圖：用例圖(usecasediagram)

2024/8/3070(2)定義活動者：位于系統(tǒng)之外并和系統(tǒng)進行交互的一類對象用它可以對軟件系統(tǒng)與外界發(fā)生的交互進行分析和描述軟件系統(tǒng)在和外界發(fā)生交互時涉及的具體的對象，在UML里，用活動者來建模2024/8/3071(3)活動者建模的對象軟件系統(tǒng)的使用者：

軟件系統(tǒng)的使用者要通過使用軟件和系統(tǒng)交互，使用者處于系統(tǒng)之外隨著軟件系統(tǒng)的應用領域的不同，在用例視圖模型中代表系統(tǒng)使用者的活動者的數(shù)目也有可能不同對于那些通用的軟件產(chǎn)品，如：文字處理軟件、網(wǎng)絡通訊軟件、圖形繪制軟件，它們的使用者通常是不需要分類的，只需要一個活動者就可以代表其所有的用戶對于那些專業(yè)化較強的專用軟件系統(tǒng)，如，管理信息系統(tǒng)、工業(yè)生產(chǎn)流程控制系統(tǒng)等，它們的使用者隨其在軟件的應用領域的職責的不同，對軟件的使用方式也會有所不同，例如，在一個公司的管理信息系統(tǒng)中，公司的管理者對信息系統(tǒng)的存取權(quán)限將高于公司的普通員工，有必要對軟件系統(tǒng)的使用者進行分類，多個不同的活動者將同時出現(xiàn)在用例視圖模型中2024/8/3072活動者除了可以代表作為人的軟件使用者之外，還可以代表直接和軟件系統(tǒng)交互的軟件系統(tǒng)賴以運行的軟/硬件平臺以及與軟件系統(tǒng)有信息交換的計算機外部設備例如，繪圖軟件它調(diào)用操作系統(tǒng)提供的圖形繪制接口，控制圖形在顯示設備上的輸出，這時可以把操作系統(tǒng)的的圖形接口和圖形輸出設備用一個活動者來建模類似的情形也可以應用于描述軟件系統(tǒng)的計算結(jié)果的保存上，軟件系統(tǒng)的計算結(jié)果通常都是通過操作系統(tǒng)的文件存取接口以文件的形式存放在計算機的外部存儲器上的，在為軟件系統(tǒng)的邊界建模時，如果需要強調(diào)軟件系統(tǒng)的結(jié)果的保存，就可以把操作系統(tǒng)的文件存取接口和文件本身用一個活動者來代表2024/8/30732024/8/30748.2用例1)概述指定活動者以后，需要詳細描述活動者和軟件系統(tǒng)交互的具體內(nèi)容，對交互所代表的軟件系統(tǒng)的功能進行分類，對這些功能詳細指定其代表的軟件系統(tǒng)的動態(tài)行為在UML里，軟件系統(tǒng)的功能和其代表的動態(tài)行為是用用例來建模的2024/8/30762)什么是用例用例代表系統(tǒng)為響應活動者引發(fā)的一個事件而執(zhí)行的一系列的處理，而且這處理應該為系統(tǒng)作用者產(chǎn)生一種可見的價值用例描述了當活動者和軟件系統(tǒng)進行交互時，軟件系統(tǒng)所執(zhí)行的一系列的動作序列，這些動作序列不但應包含正常使用的各種動作序列，而且應包含對非正常使用時軟件系統(tǒng)的動作序列的描述用例用來為軟件系統(tǒng)所提供的功能及其動態(tài)特征建模，在考慮軟件系統(tǒng)的功能劃分時，要考慮功能設置的合理性和使用的方便性一個用例代表活動者和系統(tǒng)的一次交互，用例視圖中用例的設置，就代表了軟件系統(tǒng)的功能的劃分為了得到合理而方便的軟件系統(tǒng)的功能設置，必須仔細考慮每個用例代表的動態(tài)行為的內(nèi)容，使得每個用例都能產(chǎn)生一個有價值的結(jié)果在通過用例考慮軟件系統(tǒng)的功能劃分時，應使得功能的分布較為均衡、易于理解、易于使用，這也是用例的定義中所謂“產(chǎn)生可見的價值”的含義2024/8/30773)用例的例子假定設計開發(fā)一個名為“位圖觀察器(bmpviewer)”的軟件產(chǎn)品，它為用戶提供圖像顯示和瀏覽的功能。經(jīng)過對用戶提出的功能需求的分析和整理，得出的用戶期望得到的產(chǎn)品的功能如下：打開一個bitmap文件可對文件進行放大顯示(Zoom-in)可對文件進行縮小顯示(Zoom-out)可對文件進行瀏覽(Pan)可將文件繼續(xù)保存到磁盤2024/8/3078利用用例和活動者的概念，把上述功能在通過用例在用例圖上加以表達在這里把上列的每項功能都用一個用例表示2024/8/30794)用例與活動者的關聯(lián)關系活動者和軟件系統(tǒng)的交互是具體地和特定的某項功能相聯(lián)系的，而軟件系統(tǒng)的功能在UML模型是用例，所以系統(tǒng)作用者和軟件系統(tǒng)的交互表明了活動者和用戶之間存在著某種對應為了表達活動者通過某項功能與系統(tǒng)交互，在UML模型中，可以通過用一條直線把活動者和用例相連接來表示2024/8/3080這條直線在UML里代表關聯(lián)關系例如，圖中“用戶”和“打開文件”用例之間的關聯(lián)關系代表用戶對軟件系統(tǒng)的打開文件功能的使用2024/8/3081關聯(lián)關系是UML的關系的一種，它代表兩個類的對象之間的語義連接未經(jīng)過修飾的關聯(lián)關系是雙向的兩個類之間有關聯(lián)關系，代表兩個類之間可以互相訪問，因而提供了它們進行交互的基礎在用例圖中使用的關聯(lián)關系通常被修飾為單向的關聯(lián)關系，它在模型圖被表示為一條帶箭頭的直線單向關聯(lián)關系是關聯(lián)關系的一個特例，它由關聯(lián)關系經(jīng)修飾而得，它意味著訪問是有向的在處于有向關聯(lián)關系中的兩個類中，位于箭頭所指方向的類的對象可以被另一個類的對象訪問，反之則不然2024/8/3082和系統(tǒng)打交道的外部對象有3個，其中“用戶”代表軟件的使用者，它通過訪問這項用例啟動軟件“打開文件”的功能。系統(tǒng)對這些事件應采取一系列的動作進行響應，響應的過程中，將訪問硬盤中的數(shù)據(jù)，并更新顯示因此，有兩個系統(tǒng)作用者與此相對應，“位圖文件”，“顯示窗口”：“顯示窗口”代表用來顯示位圖的操作系統(tǒng)圖形用戶界面的一個窗口，“位圖文件”代表保存在計算機外部存儲器的位圖文件從這個例子也可以看到，活動者不僅僅代表人，還可以是軟件或硬件系統(tǒng)

2024/8/3083關聯(lián)關系的有向性在圖中所示的用例中，“打開文件”對應的系統(tǒng)所采取的動作序列中涉及文件“讀取”，但關聯(lián)關系的箭頭仍指向文件而不是反之。這是因為有向關聯(lián)關系的箭頭代表的是訪問的方向，而不是數(shù)據(jù)的流向數(shù)據(jù)文件不會（主動地）訪問用例，所以對讀取或保存文件，都應有同樣的訪問方向2024/8/30845)事件流與場景

事件流用例代表系統(tǒng)和活動者之間發(fā)生的一系列的事件，這些事件流構(gòu)成了用戶對系統(tǒng)功能的一次使用在用例圖中必須對事件流進行描述，以構(gòu)成一個完備的用例模型對事件流的描述包括四種形式，即：形式文本非形式文本交互圖狀態(tài)圖相應的UML成員作為這些描述的載體文本和正式文本可用注標（note）表示交互圖和活動圖本身即是一個標準的UML成員2024/8/3086

主事件流（mainflowofevents）和次要事件流（alternativeflowofevents）用來區(qū)分對系統(tǒng)功能的合法使用和非法使用主事件流（mainflowofevents）合法使用只有一個次要事件流（alternativeflowofevents）可包含若干個在描繪事件流時，必須用足夠清晰的語言以使得一個普通的用戶能夠理解2024/8/3087場景（Scenario）一個用例可以有多個事件流，每一個事件流是一個完整的用戶對系統(tǒng)的功能的使用。它們出于同一個目的，但出于事件流不同，使得系統(tǒng)產(chǎn)生的響應不同 這樣的用例/事件流的對應關系正是前面講到的UML公用劃分機制的一個例子,它是對系統(tǒng)功能使用的特例（合法或非法的）,

因此事件流是用例的實例（instance）用例的實例在UML中被稱為場景（Scenario）2024/8/30886)用例圖中的關系(1)概述在分析和整理活動者和系統(tǒng)用例的時候，可能用到：使用關系泛化關系包含關系擴展關系2024/8/3090(2)使用關聯(lián)使用關聯(lián)是指一個用例使用另一個用例的功能行為使用關聯(lián)用于在用例之間共享公共的功能行為使用關聯(lián)是一種泛化關聯(lián)，在用例圖上用一個基本用例指向公共的用例的泛化箭頭表示，并在箭線上標有構(gòu)造型<<Use>>2024/8/3091(3)泛化關系在UML中，兩個類之間的泛化關系代表子類共享了超類的行為和結(jié)構(gòu)。它實際上就是C++里面的類之間的繼承和導出關系在用例圖中，活動者是類的變體用例是具有類的特征的建模元素（分類符）,因此，可以用泛化關系描述活動者或用例之間的繼承2024/8/3092在一個帳單管理系統(tǒng)中，用例PhoneOrder和InternetOrder在結(jié)構(gòu)和行為方面存在很多相似之處。因此可以定義一個通用的用例PlaceOrder，來表示結(jié)構(gòu)和公共的行為。抽象的用例PlaceOrder自身并不一定要是完整的，但是它提供了一個公共的行為框架，子用例可以使自己完整2024/8/3093(4)包含關系包含關系(include)：位于兩個用例之間的包含關系意味著基用例顯式地在其指定位置將另一個用例包含進來,使其成為自己的行為的一部分包含關系可用于提取共用的用例在具有包含關系的兩個用例中，被包含的那個用例不能單獨存在，它只能以實例的形式存在于包含它的用例之中2024/8/3094在一個ATM系統(tǒng)中，用例WithdrawCash,DepositCash和TransferFunds都需要包含系統(tǒng)識別客戶這一功能。該行為可以提取出來作為一個新的包含用例，稱為IdentifyCustomer,它被其它三個基用例所包含。這些基用例獨立于具體的識別方法，該方法被封裝在包含用例中。從基用例的觀點看，它們不關心用戶識別是從銀行磁卡上識別出來的還是從視網(wǎng)膜掃描上識別出來的。它們只需要IdentifyCustomer的結(jié)果,就是客戶的標識符另一方面，從IdentifyCustomer用例的角度看，它不關心基用例是如何使用客戶標識的或者在執(zhí)行它之前，發(fā)生了什么——識別的方法始終是一樣的2024/8/30952024/8/3096(5)擴展關系擴展關系：兩個用例之間的擴展關系，代表基用例可以隱式地包含另一個用例作為其行為的一部分，包含的位置間接地由另一個用例（擴展用例）確定?；美梢元毩⒂跀U展用例單獨存在當