東北大學軟件工程復習資料

東北大學軟件工程期末復習資料考點：什么是軟件，包括什么程序，文檔，數(shù)據(jù)是什么軟件類型（兩種）*軟件特點軟件危機（定義）軟件工程（定義），關注質量，成本什么是軟件生命周期什么是軟件過程模型用例是什么的縮寫，是什么描述一個案例，用什么模型需求的重要性軟件需求是什么需求工程是什么需求獲取的目的需求獲取的手段需求分析數(shù)據(jù)字典流圖不考是什么給一個例子，說明缺陷需求驗證和管理（了解）面向對象的歷史對象，類，消息，繼承是什么對象及類的關系軟件建模是什么的縮寫關聯(lián)關系多重性視角面向對象分析是什么面向對象分析建模面向對象分析用例用例是什么，關系，特點用例描述分析類是什么畫類圖包是什么包中有什么包之間的關系動態(tài)建模狀態(tài)圖類圖測試迭代是軟件產(chǎn)品內(nèi)部特點什么是面向對象設計設計的原則*模塊，耦合，內(nèi)聚軟件復用什么是軟件體系結構典型的體系結構風格*順序圖，協(xié)作圖問某個方法是哪個對象的方法偽碼數(shù)據(jù)庫設計（了解）用戶界面設計*實現(xiàn)及集成編程及編碼的區(qū)別編程語言怎么選擇合適的編程語言編碼規(guī)范，包括哪些*維護的類型軟件測試軟件質量，軟件質量保證軟件測試類型一：軟件定義*軟件的定義（牢記）()在運行中提供所希望的功能和性能的指令集（即程序）程序編程語言描述的一系列語句序列提供需要的功能和性能數(shù)據(jù)使程序能方便的操縱信息文檔描述程序研制過程和方法，操作和使用方法的文檔軟件的類型（兩種）一般軟件直接提供給市場，或供多個用戶使用定制軟件受某個客戶委托，一個或多個軟件開發(fā)機構為其開發(fā)的軟件*軟件的特點（牢記）,.邏輯產(chǎn)品，非物質的“”.不會磨損,開發(fā)出來，而非制造.大部分是定制的’質量依賴于開發(fā)人員的素質昂貴.難以維護軟件危機（定義）落后的軟件生產(chǎn)方式無法滿足迅速增長的計算機軟件需求，從而導致軟件開發(fā)及維護過程中出現(xiàn)一系列嚴重問題的現(xiàn)象。主要是三個個方面的問題：軟件的質量低，難以滿足需求對軟件開發(fā)時間和成本的估計不足如何維護軟件──數(shù)量不斷膨脹的已有軟件，不斷變化的用戶需求定義軟件工程（定義）是指導計算機軟件開發(fā)和維護的工程學科。采用工程的概念、原理、技術和方法來開發(fā)及維護軟件，把經(jīng)過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來，這就是軟件工程。軟件工程的關注（質量，成本）軟件質量軟件需要一些屬性來反應他的質量可維護性：適應用戶的需求變化可靠性：可依靠，安全的效率：不浪費內(nèi)存和可接受性：方便適用軟件成本用于開發(fā)和維護主要元素過程：軟件工程的基礎方法：提供建造軟件的技術工具：提供自動化或半自動化手段來支持過程和方法目標滿足用戶的需求，同時提高性能，成本和質量二：軟件生命周期*生命周期：一個軟件從定義、開發(fā)、使用、和維護，直到最終被廢棄要經(jīng)歷一個漫長的時期，這個時期稱為生命周期。生命周期涵蓋一系列的階段：可行性研究需求分析概要設計細節(jié)設計實現(xiàn)集成維護退休軟件過程是為了獲得高質量軟件所需要完成的一系列任務的框架，它規(guī)定了完成各項任務的工作步驟典型軟件過程模型瀑布模型瀑布模型特點：階段間具有順序性和依賴性每個階段必須完成規(guī)定的文檔;每個階段結束前完成文檔審查,及早改正錯誤,但：開發(fā)過程一般不能逆轉，否則代價太大。實際的項目開發(fā)很難嚴格按該模型進行?？蛻敉茈y清楚地給出所有的需求，而該模型卻要求如此。應用范圍：軟件的實際情況必須到項目開發(fā)的后期客戶才能看到，這要求客戶有足夠的耐心。用戶的需求非常清楚全面，且在開發(fā)過程中沒有或很少變化開發(fā)人員對軟件的應用領域很熟悉。用戶的使用環(huán)境非常穩(wěn)定。開發(fā)工作對用戶參及的要求很低快速原型模型基本是首先建立一個能夠反映用戶主要需求的原型系統(tǒng)讓用戶在計算機上運行、試用這個原型系統(tǒng)，通過及原型交互及早發(fā)現(xiàn)需求的缺陷；設計人員也可檢查設計的可行性?？焖僭O計建造原型快速設計建造原型用戶評估原型，提出新需求對原型進行加工開發(fā)產(chǎn)品初步需求分析結束開始原型可以利用第四代語言面向對象的應用程序框架，原型開發(fā)活動、用戶反饋、開發(fā)者修改原型的重復迭代過程可提高用戶滿意程度，也可縮短軟件開發(fā)周期，從而降低了開發(fā)和維護成本。在該模型中，如何快速進行原型的開發(fā)是關鍵，快速開發(fā)原型的途徑一般可以有三種：\*①利用計算機模擬一個軟件的人機界面及交互方式。\*②開發(fā)一個能實現(xiàn)部分功能(如輸入界面、輸出格式等)的軟件，這部分功能往往是重要的，但也可能是容易引起誤解的。\*③尋找一個或幾個類似的正在運行的軟件，利用這些軟件向客戶展示軟件需求中的部分或全部功能。為了快速地開發(fā)原型，要盡量采用軟件重用技術，以爭取時間，盡快地向客戶提供原型。()特點該模型是基于原型驅動的?？梢缘玫奖容^良好的需求定義，便于開發(fā)者及客戶進行全面的溝通及交流。而且原型系統(tǒng)也比較容易適應用戶需求的變化。原型系統(tǒng)既是開發(fā)的原型，又可以作為培訓的環(huán)境，這樣有利于開發(fā)及培訓的同步。原型系統(tǒng)的開發(fā)費用低、開發(fā)周期短、維護容易且對用戶更友好。盡管開發(fā)者和客戶都喜歡使用原型模型，但原型模型也有其固有的缺點：\*①在對原型的理解上客戶及開發(fā)者有很大的差異，客戶以為原型就是軟件的最終版本，而開發(fā)者只將原型當作一個漂亮美麗的軟件外殼，在實際開發(fā)過程中要對原型進行不斷修改完善，這就需要開發(fā)人員及客戶相互溝通、相互理解。\*②由于原型是開發(fā)者快速設計出來的，而開發(fā)者對所開發(fā)領域的陌生容易將次要部分當作主要的框架，做出不切題的原型。\*③軟件的整個開發(fā)都是圍繞著原型來展開的，在一定程度上不利于開發(fā)人員的創(chuàng)新。增量模型把軟件產(chǎn)品分解成增量構件。原則：當把新構件集成到原有構件時，所形成的產(chǎn)品必須是可測試的。它能在較短時間內(nèi)向用戶提交可完成部分工作的產(chǎn)品，盡早的得到回報。要求開始實現(xiàn)各個構件前就全部完成的需求分析、規(guī)格說明、總體設計。螺旋模型螺旋模型：沿螺線自內(nèi)向外每旋轉一圈便開發(fā)出一個更為完善的軟件版本螺旋模型的基本思想：使用原形及其他方法來盡量降低風險?？梢钥醋髅總€階段前都加了風險分析的快速原型模型。螺旋模型是風險驅動型的?？偨Y面向對象模型噴泉模型、噴泉模型的優(yōu)點各階段交叉、迭代，支持復用噴泉模型不像瀑布模型那樣，需要分析活動結束后才開始設計活動，設計活動結束后才開始編碼活動。該模型的各個階段沒有明顯的界限，開發(fā)人員可以同步進行開發(fā)。其優(yōu)點是可以提高軟件項目開發(fā)效率，節(jié)省開發(fā)時間，適應于面向對象的軟件開發(fā)過程。、噴泉模型的缺點由于噴泉模型在各個開發(fā)階段是重疊的，因此在開發(fā)過程中需要大量的開發(fā)人員，因此不利于項目的管理。此外這種模型要求嚴格管理文檔，使得審核的難度加大，尤其是面對可能隨時加入各種信息、需求及資料的情況。統(tǒng)一過程模型用例驅動整個開發(fā)過程迭代增量式開發(fā)基于構件的軟件體系結構為中心展開開發(fā)使用統(tǒng)一建模語言（）()(計算機輔助軟件工程)用來輔助軟件開發(fā)、運行、維護、管理、支持等過程中活動的軟件稱為軟件工具三：?什么是需求工程(軟件需求)用戶對軟件功能，性能，設計等方面的需求（需求工程）這個過程獲取用戶或最終使用者對軟件的需求包括一系列的任務來理解軟件的需求幫助軟件工程師更好的理解他們需要解決的問題()需求獲取需求分析需求說明需求認證需求管理需求獲取技術目的確定和收集及待開發(fā)的軟件系統(tǒng)相關的信息獲取需求，確定問題，定義問題范圍，解決沖突關鍵要及用戶溝通，收集和理解需求獲取方法采訪消費者研討需求問卷調(diào)查建了原型需求分析模型重點是建立分析模型是對現(xiàn)實的簡化，分析模型定義了系統(tǒng)的詳細需求，但不限于一種技術傳統(tǒng)方法：(),,(),,…（數(shù)據(jù)流圖，數(shù)據(jù)字典，狀態(tài)轉換圖）面向對象方法：,,,,（用例，順序圖，協(xié)作圖，類圖，狀態(tài)圖）需求分析過程定義系統(tǒng)范圍分析需求的可行性確定需求的優(yōu)先級形成需求分析模型建立數(shù)據(jù)字典數(shù)據(jù)流圖建立一個系統(tǒng)的輸入輸出模型用來描述系統(tǒng)的功能和行為優(yōu)點易于理解方便開發(fā)者和用戶間的交流符號（外部實體，處理，數(shù)據(jù)流，數(shù)據(jù)儲存）外部實體（原點和匯點）外部項是指系統(tǒng)以外的事物或人，表達了該系統(tǒng)數(shù)據(jù)的外部來源或去處，用方框表示之。處理（加工）處理表達了對數(shù)據(jù)的邏輯加工或變換功能：對數(shù)據(jù)的加工處理的結果，或者是變換了數(shù)據(jù)的結構，或者是在原有數(shù)據(jù)的基礎上產(chǎn)生新的數(shù)據(jù)。處理用圓表示。數(shù)據(jù)流數(shù)據(jù)流指示數(shù)據(jù)的流動方向，用單箭頭表示。數(shù)據(jù)存儲數(shù)據(jù)存儲指明了保存數(shù)據(jù)的地方。不代表具體的存儲介質。數(shù)據(jù)存儲使用右端開口的矩形框表示。:分層數(shù)據(jù)流圖為了表達數(shù)據(jù)處理過程的數(shù)據(jù)加工情況，用一個數(shù)據(jù)流圖是不夠的。稍為復雜的實際問題，在數(shù)據(jù)流圖上常常出現(xiàn)十幾個甚至幾十個加工。這樣的數(shù)據(jù)流圖看起來很不清楚。層次結構的數(shù)據(jù)流圖能很好地解決這一問題。按照系統(tǒng)的層次結構進行逐步分解，并以分層的數(shù)據(jù)流圖反映這種結構關系，能清楚地表達和容易理解整個系統(tǒng)。畫數(shù)據(jù)流圖的方法畫數(shù)據(jù)流圖的基本步驟概括地說，就是自外向內(nèi)，自頂向下，逐層細化，完善求精。檢查和修改的原則為：由外及里畫數(shù)據(jù)流圖自頂向下分層畫數(shù)據(jù)流圖分解應遵循下列原則：分解要自然，注意概念上的合理性；以分層方式對處理編號；注意父圖及子圖的平衡，即子圖所有的輸入和輸出數(shù)據(jù)流應當是父圖中相應處理的所有輸入和輸出數(shù)據(jù)流；一個處理一般可分解成個子處理，不宜過多；當進一步分解可能涉及具體的物理實現(xiàn)手段時，分解應終止。檢查和修改的原則為：①數(shù)據(jù)流圖上所有圖形符號只限于前述四種基本圖形元素。②頂層數(shù)據(jù)流圖必須包括前述四種基本元素，缺一不可。③頂層數(shù)據(jù)流圖上的數(shù)據(jù)流必須封閉在外部實體之間。④每個加工至少有一個輸入數(shù)據(jù)流和一個輸出數(shù)據(jù)流。⑤在數(shù)據(jù)流圖中，需按層給加工框編號。編號表明該加工處在哪一層，以及上下層的父圖及子圖的對應關系。⑥規(guī)定任何一個數(shù)據(jù)流子圖必須及它上一層的一個加工對應，兩者的輸入數(shù)據(jù)流和輸出數(shù)據(jù)流必須一致。此即父圖及子圖的平衡。⑦可以在數(shù)據(jù)流圖中加入物質流，幫助用戶理解數(shù)據(jù)流圖。⑧圖上每個元素都必須有名字。數(shù)據(jù)流和數(shù)據(jù)文件的名字應當是“名詞”或“名詞性短語”，表明流動的數(shù)據(jù)是什么。加工的名字應當是“動詞＋賓語”，表明做什么事情。⑨數(shù)據(jù)流圖中不可夾帶控制流。⑩初畫時可以忽略瑣碎的細節(jié)，以集中精力于主要數(shù)據(jù)流。 數(shù)據(jù)流圖作用：開發(fā)人員及用戶，軟件人員及軟件人員之間的橋梁；驗收的依據(jù)例子數(shù)據(jù)字典數(shù)據(jù)圖反映了數(shù)據(jù)在系統(tǒng)中的流向以及數(shù)據(jù)的轉換過程，但它無法描述有關數(shù)據(jù)流、數(shù)據(jù)存儲、處理邏輯和外部項的進一步詳細的內(nèi)容。數(shù)據(jù)字典用于較詳細地定義或說明數(shù)據(jù)留圖的四個基本成分。數(shù)據(jù)兔和數(shù)據(jù)字典共同構造系統(tǒng)的邏輯模型。沒有數(shù)據(jù)字典，數(shù)據(jù)流圖就不嚴格。(,軟件需求規(guī)格說明)定義：精確描述一個軟件系統(tǒng)的功能和性能軟件需求規(guī)格說明應包含的內(nèi)容引言：軟件目標及范圍 數(shù)據(jù)描述：數(shù)據(jù)流圖（系統(tǒng)邏輯模型）、數(shù)據(jù)字典（一切數(shù)據(jù)的定義）外部接口：怎樣及人，硬件，和其他系統(tǒng)交互 功能描述：功能說明，應該提供什么功能 性能描述：性能說明 特征描述：軟件的安全性，可操作性等 限制條件：應遵循的標準（語言，環(huán)境，標準...）不應該包含的內(nèi)容開發(fā)計劃保險計劃設計細節(jié)的質量正確性：能爭取表達用戶的需求無歧義：每個人都要有一致的理解完整：需要包括軟件的所有任務可驗證性：每一個需求都能驗證和確定一致性：需求的描述不能有沖突可修改性：容易修改，每個應該有索引且需求不能交叉引用可追溯性：每個需求都和它的資源，設計，代碼，測試用例相聯(lián)系需求確認證實用戶對需求是否滿意需求判斷原型評價生成測試用例分析修改造成的影響，控制修改的過程包括：修改控制，版本控制，需求追蹤四：面向對象方法介紹定義和歷史出現(xiàn)后，代替的傳統(tǒng)的建模方法面向對象軟件工程()面向對象分析()面向對象設計()面向對象編程>>是一個平穩(wěn)的過度，可以提高開發(fā)的效率和質量()面向對象測試面向對象軟件維護面向對象基礎(對象)：系統(tǒng)中用來描述現(xiàn)實中事物的實體包括一些屬性（描述靜態(tài)特征）和操作方法（描述動態(tài)特征）軟件系統(tǒng)的基本單元（類）：一組擁有相同屬性和方法的對象*類和對象的比較類是靜態(tài)的，在程序運行前已經(jīng)定義對象是動態(tài)的，在程序運行是創(chuàng)建對象是類的一個實例在的過程中，我們強調(diào)類，而不是對象（消息）：來自于對象的請求（封裝）：隱藏對象的屬性和實現(xiàn)細節(jié)，僅對外公開接口,控制在程序中屬性的讀和修改的訪問級別（繼承）：意味著子類可以擁有父類的全部屬性和方法（多態(tài)）：多態(tài)指同一個實體同時具有多種形式。子類繼承的屬性和方法，可以不同于父類，提供靈活的軟件設計方法，提高軟件復用基本概念：軟件建模描述現(xiàn)實世界重要的部分統(tǒng)一建模語言()一個可視的建模語言，但不是一個可視編程語言一個支持開發(fā)的工具，但不是萬能的一個建模的描述(可視化的)(詳細描述的)(構造的)(文檔化的)矩形線其他圖形特征字符串（關于更詳細的方法，自己看書吧。。。）五面向對象分析的主要任務是用面向對象的概念和方法為軟件需求建立模型。用例建模.什么是用例？在介始用例方法之前，我們首先來看一下傳統(tǒng)的需求表述方式"軟件需求規(guī)約"()。傳統(tǒng)的軟件需求規(guī)約基本上采用的是功能分解的方式來描述系統(tǒng)功能，在這種表述方式中，系統(tǒng)功能被分解到各個系統(tǒng)功能模塊中，我們通過描述細分的系統(tǒng)模塊的功能來達到描述整個系統(tǒng)功能的目的。一個典型的軟件需求規(guī)約可能具有以下形式：采用這種方法來描述系統(tǒng)需求，非常容易混淆需求和設計的界限，這樣的表述實際上已經(jīng)包含了部分的設計在內(nèi)。由此常常導致這樣的迷惑：系統(tǒng)需求應該詳細到何種程度？一個極端就是需求可以詳細到概要設計，因為這樣的需求表述既包含了外部需求也包含了內(nèi)部設計。在有些公司的開發(fā)流程中，這種需求被稱為"內(nèi)部需求"，而對應于用戶的原始要求則被稱之為"外部需求"。功能分解方法的另一個缺點是這種方法分割了各項系統(tǒng)功能的應用環(huán)境，從各項功能項入手，你很難了解到這些功能項是如何相互關聯(lián)來實現(xiàn)一個完成的系統(tǒng)服務的。所以在傳統(tǒng)的文檔中，我們往往需要另外一些章節(jié)來描述系統(tǒng)的整體結構及各部分之間的相互關聯(lián)，這些內(nèi)容使得需求更象是一個設計文檔。參及者和用例從用戶的角度來看，他們并不想了解系統(tǒng)的內(nèi)部結構和設計，他們所關心的是系統(tǒng)所能提供的服務，也就是被開發(fā)出來的系統(tǒng)將是如何被使用的，這就用例方法的基本思想。用例模型主要由以下模型元素構成：參及者()

參及者是指存在于被定義系統(tǒng)外部并及該系統(tǒng)發(fā)生交互的人或其他系統(tǒng)，他們代表的是系統(tǒng)的使用者或使用環(huán)境。用例()

用例用于表示系統(tǒng)所提供的服務，它定義了系統(tǒng)是如何被參及者所使用的，它描述的是參及者為了使用系統(tǒng)所提供的某一完整功能而及系統(tǒng)之間發(fā)生的一段對話。通訊關聯(lián)()

通訊關聯(lián)用于表示參及者和用例之間的對應關系，它表示參及者使用了系統(tǒng)中的哪些服務（用例），或者說系統(tǒng)所提供的服務（用例）是被哪些參及者所使用的。這大三種模型元素在中的表述如下圖所示。以銀行自動提款機()為例，它的主要功能可以由下面的用例圖來表示。的主要使用者是銀行客戶，客戶主要使用自動提款機來進行銀行帳戶的查詢、提款和轉帳交易。通訊關聯(lián)表示的是參及者和用例之間的關系，箭頭表示在這一關系中哪一方是對話的主動發(fā)起者，箭頭所指方是對話的被動接受者；如果你不想強調(diào)對話中的主動及被動關系，可以使用不帶箭頭的關聯(lián)實線。在參及者和用例之間的信息流不是由通訊關聯(lián)來表示的，該信息流是缺省存在的（用例本身描述的就是參及者和系統(tǒng)之間的對話），并且信息流向是雙向的，它及通訊關聯(lián)箭頭所指的方向亳無關系。用例的內(nèi)容用例圖使我們對系統(tǒng)的功能有了一個整體的認知，我們可以知道有哪些參及者會及系統(tǒng)發(fā)生交互，每一個參及者需要系統(tǒng)為它提供什么樣的服務。用例描述的是參及者及系統(tǒng)之間的對話，但是這個對話的細節(jié)并沒有在用例圖中表述出來，針對每一個用例我們可以用事件流來描述這一對話的細節(jié)內(nèi)容。如在系統(tǒng)中的"提款"用例可以用事件流表述如下：提款基本事件流.用戶插入信用卡.輸入密碼.輸入提款金額.提取現(xiàn)金.退出系統(tǒng)，取回信用卡但是這只描述了提款用例中最順利的一種情況，作為一個實用的系統(tǒng)，我們還必須考慮可能發(fā)生的各種其他情況，如信用卡無效、輸入密碼錯、用戶帳號中的現(xiàn)金余額不夠等，所有這些可能發(fā)生的各種情況（包括正常的和異常的）被稱之為用例的場景()，場景也被稱作是用例的實例()。在用例的各種場景中，最常見的場景是用基本流()來描述的，其他的場景則是用備選流()來描述。對于系統(tǒng)中的"提款"用例，我們可以得到如下一些備選流：提款備選事件流備選流一：用戶可以在基本流中的任何一步選擇退出，轉至基本流步驟。備選流二：在基本流步驟中，用戶插入無效信用卡，系統(tǒng)顯示錯誤并退出信用卡，用例結束。備選流三：在基本流步驟２中，用戶輸入錯誤密碼，系統(tǒng)顯示錯誤并提示用戶重新輸入密碼，重新回到基本流步驟；三次輸入密碼錯誤后，信用卡被系統(tǒng)沒收，用例結束。通過基本流及備選流的組合，就可以將用例所有可能發(fā)生的各種場景全部描述清楚。我們在描述用例的事件流的時候，就是要盡可能地將所有可能的場景都描述出來，以保證需求的完備性。用例方法的優(yōu)點用例方法完全是站在用戶的角度上（從系統(tǒng)的外部）來描述系統(tǒng)的功能的。在用例方法中，我們把被定義系統(tǒng)看作是一個黑箱，我們并不關心系統(tǒng)內(nèi)部是如何完成它所提供的功能的。用例方法首先描述了被定義系統(tǒng)有哪些外部使用者（抽象成為），這些使用者及被定義系統(tǒng)發(fā)生交互；針對每一參及者，用例方法又描述了系統(tǒng)為這些參及者提供了什么樣的服務（抽象成為），或者說系統(tǒng)是如何被這些參及者使用的。所以從用例圖中，我們可以得到對于被定義系統(tǒng)的一個總體印象。及傳統(tǒng)的功能分解方式相比，用例方法完全是從外部來定義系統(tǒng)的功能，它把需求及設計完全分離開來。在面向對象的分析設計方法中，用例模型主要用于表述系統(tǒng)的功能性需求，系統(tǒng)的設計主要由對象模型來記錄表述。另外，用例定義了系統(tǒng)功能的使用環(huán)境及上下文，每一個用例描述的是一個完整的系統(tǒng)服務。用例方法比傳統(tǒng)的更易于被用戶所理解，它可以作為開發(fā)人員和用戶之間針對系統(tǒng)需求進行溝通的一個有效手段。在中，用例被作為整個軟件開發(fā)流程的基礎，很多類型的開發(fā)活動都把用例作為一個主要的輸入工件()，如項目管理、分析設計、測試等。根據(jù)用例來對目標系統(tǒng)進行測試，可以根據(jù)用例中所描述的環(huán)境和上下文來完整地測試一個系統(tǒng)服務，可以根據(jù)用例的各個場景()來設計測試用例，完全地測試用例的各種場景可以保證測試的完備性。.建立用例模型使用用例的方法來描述系統(tǒng)的功能需求的過程就是用例建模，用例模型主要包括以下兩部分內(nèi)容：用例圖()

確定系統(tǒng)中所包含的參及者、用例和兩者之間的對應關系，用例圖描述的是關于系統(tǒng)功能的一個概述。用例規(guī)約()

針對每一個用例都應該有一個用例規(guī)約文檔及之相對應，該文檔描述用例的細節(jié)內(nèi)容。在用例建模的過程中，我們建議的步聚是先找出參及者，再根據(jù)參及者確定每個參及者相關的用例，最后再細化每一個用例的用例規(guī)約。尋找參及者所謂的參及者是指所有存在于系統(tǒng)外部并及系統(tǒng)進行交互的人或其他系統(tǒng)。通俗地講，參及者就是我們所要定義系統(tǒng)的使用者。尋找參及者可以從以下問題入手：系統(tǒng)開發(fā)完成之后，有哪些人會使用這個系統(tǒng)？系統(tǒng)需要從哪些人或其他系統(tǒng)中獲得數(shù)據(jù)？系統(tǒng)會為哪些人或其他系統(tǒng)提供數(shù)據(jù)？系統(tǒng)會及哪些其他系統(tǒng)相關聯(lián)？系統(tǒng)是由誰來維護和管理的？這些問題有助于我們抽象出系統(tǒng)的參及者。對于機的例子，回答這些問題可以使我們找到更多的參及者：操作員負責維護和管理機系統(tǒng)、機也需要及后臺服務器進行通訊以獲得有關用戶帳號的相關信息。系統(tǒng)邊界決定了參及者參及者是由系統(tǒng)的邊界所決定的，如果我們所要定義的系統(tǒng)邊界僅限于機本身，那么后臺服務器就是一個外部的系統(tǒng)，可以抽象為一個參及者。如果我們所要定義的系統(tǒng)邊界擴大至整個銀行系統(tǒng)，機和后臺服務器都是整個銀行系統(tǒng)的一部分，這時候后臺服務器就不再被抽象成為一個參及者。值得注意的是，用例建模時不要將一些系統(tǒng)的組成結構作為參及者來進行抽象，如在機系統(tǒng)中，打印機只是系統(tǒng)的一個組成部分，不應將它抽象成一個獨立的參及者；在一個管理系統(tǒng)中，數(shù)據(jù)庫系統(tǒng)往往只作為系統(tǒng)的一個組成部分，一般不將其單獨抽象成一個參及者。特殊的參及者――系統(tǒng)時鐘有時候我們需要在系統(tǒng)內(nèi)部定時地執(zhí)行一些操作，如檢測系統(tǒng)資源使用情況、定期地生成統(tǒng)計報表等等。從表面上看，這些操作并不是由外部的人或系統(tǒng)觸發(fā)的，應該怎樣用用例方法來表述這一類功能需求呢？對于這種情況，我們可以抽象出一個系統(tǒng)時鐘或定時器參及者，利用該參及者來觸發(fā)這一類定時操作。從邏輯上，這一參及者應該被理解成是系統(tǒng)外部的，由它來觸發(fā)系統(tǒng)所提供的用例對話。確定用例找到參及者之后，我們就可以根據(jù)參及者來確定系統(tǒng)的用例，主要是看各參及者需要系統(tǒng)提供什么樣的服務，或者說參及者是如何使用系統(tǒng)的。尋找用例可以從以下問題入手（針對每一個參及者）：參及者為什么要使用該系統(tǒng)？參及者是否會在系統(tǒng)中創(chuàng)建、修改、刪除、訪問、存儲數(shù)據(jù)？如果是的話，參及者又是如何來完成這些操作的？參及者是否會將外部的某些事件通知給該系統(tǒng)？系統(tǒng)是否會將內(nèi)部的某些事件通知該參及者？綜合以上所述，系統(tǒng)的用例圖可表示如下，在用例的抽取過程中，必須注意：用例必須是由某一個主角觸發(fā)而產(chǎn)生的活動，即每個用例至少應該涉及一個主角。如果存在及主角不進行交互的用例，就可以考慮將其并入其他用例；或者是檢查該用例相對應的參及者是否被遺漏，如果是，則補上該參及者。反之，每個參及者也必須至少涉及到一個用例，如果發(fā)現(xiàn)有不及任何用例相關聯(lián)的參及者存在，就應該考慮該參及者是如何及系統(tǒng)發(fā)生對話的，或者由參及者確定一個新的用例，或者該參及者是一個多余的模型元素，應該將其刪除?？梢暬５闹饕康闹痪褪且鰪妶F隊的溝通，用例模型必須是易于理解的。用例建模往往是一個團隊開發(fā)的過程，系統(tǒng)分析員在建模過程中必須注意參及者和用例的名稱應該符合一定的命名約定，這樣整個用例模型才能夠符合一定的風格。如參及者的名稱一般都是名詞，用例名稱一般都是動賓詞組等。對于同一個系統(tǒng)，不同的人對于參及者和用例都可能有不同的抽象結果，因而得到不同的用例模型。我們需要在多個用例模型方案中選擇一種"最佳"（或"較佳"）的結果，一個好的用例模型應該能夠容易被不同的涉眾所理解，并且不同的涉眾對于同一用例模型的理解應該是一致的。描述用例規(guī)約應該避免這樣一種誤解――認為由參及者和用例構成的用例圖就是用例模型，用例圖只是在總體上大致描述了系統(tǒng)所能提供的各種服務，讓我們對于系統(tǒng)的功能有一個總體的認識。除此之外，我們還需要描述每一個有例的詳細信息，這些信息包含在用例規(guī)約中，用例模型是由用例圖和每一個用例的詳細描述――用例規(guī)約所組成的。中提供了用例規(guī)約的模板，每一個用例的用例規(guī)約都應該包含以下內(nèi)容：簡要說明()

簡要介紹該用例的作用和目的。事件流()

包括基本流和備選流，事件流應該表示出所有的場景。用例場景()

包括成功場景和失敗場景，場景主要是由基本流和備選流組合而成的。特殊需求()

描述及該用例相關的非功能性需求（包括性能、可靠性、可用性和可擴展性等）和設計約束（所使用的操作系統(tǒng)、開發(fā)工具等）。前置條件()

執(zhí)行用例之前系統(tǒng)必須所處的狀態(tài)。后置條件()

用例執(zhí)行完畢后系統(tǒng)可能處于的一組狀態(tài)。用例規(guī)約基本上是用文本方式來表述的，為了更加清晰地描述事件流，也可以選擇使用狀態(tài)圖、活動圖或序列圖來輔助說明。只要有助于表達的簡潔明了，就可以在用例中任意粘貼用戶界面和流程的圖形化顯示方式，或是其他圖形。如活動圖有助于描述復雜的決策流程，狀態(tài)轉移圖有助于描述及狀態(tài)相關的系統(tǒng)行為，序列圖適合于描述基于時間順序的消息傳遞。基本流基本流描述的是該用例最正常的一種場景，在基本流中系統(tǒng)執(zhí)行一系列活動步驟來響應參及者提出的服務請求。我們建議用以下格式來描述基本流：)每一個步驟都需要用數(shù)字編號以清楚地標明步驟的先后順序。)用一句簡短的標題來概括每一步驟的主要內(nèi)容，這樣閱讀者可以通過瀏覽標題來快速地了解用例的主要步驟。在用例建模的早期，我們也只需要描述到事件流步驟標題這一層，以免過早地陷入到用例描述的細節(jié)中去。)當整個用例模型基本穩(wěn)定之后，我們再針對每一步驟詳細描述參及者和系統(tǒng)之間所發(fā)生的交互。建議采用雙向()描述法來保證描述的完整性，即每一步驟都需要從正反兩個方面來描述:()參及者向系統(tǒng)提交了什么信息；()對此系統(tǒng)有什么樣的響應。具體例子請參見附錄。在描述參及者和系統(tǒng)之間的信息交換時，需指出來回傳遞的具體信息。例如，只表述參及者輸入了客戶信息就不夠明確，最好明確地說參及者輸入了客戶姓名和地址。通?？梢岳迷~匯表讓用例的復雜性保持在可控范圍內(nèi)，可以在詞匯表中定義客戶信息等內(nèi)容，使用例不至于陷入過多的細節(jié)。備選流備選流負責描述用例執(zhí)行過程中異常的或偶爾發(fā)生的一些情況，備選流和基本流的組合應該能夠覆蓋該用例所有可能發(fā)生的場景。在描述備選流時，應該包括以下幾個要素：)起點：該備選流從事件流的哪一步開始；)條件：在什么條件下會觸發(fā)該備選流；)動作：系統(tǒng)在該備選流下會采取哪些動作；)恢復：該備選流結束之后，該用例應如何繼續(xù)執(zhí)行。備選流的描述格式可以及基本流的格式一致，也需要編號并以標題概述其內(nèi)容，編號前可以加以字母前綴()以示及基本流步驟相區(qū)別。用例場景用例在實際執(zhí)行的時候會有很多的不同情況發(fā)生，稱之為用例場景；也可以說場景是用例的實例，我們在描述用例的時候要覆蓋所有的用例場景，否則就有可能導致需求的遺漏。在用例規(guī)約中，場景的描述可以由基本流和備選流的組合來表示。場景既可以幫助我們防止需求的遺漏，同時也可以對后續(xù)的開發(fā)工作起到很大的幫助：開發(fā)人員必須實現(xiàn)所有的場景、測試人員可以根據(jù)用例場景來設計測試用例。特殊需求特殊需求通常是非功能性需求，它為一個用例所專有，但不適合在用例的事件流文本中進行說明。特殊需求的例子包括法律或法規(guī)方面的需求、應用程序標準和所構建系統(tǒng)的質量屬性（包括可用性、可靠性、性能或支持性需求等）。此外，其他一些設計約束，如操作系統(tǒng)及環(huán)境、兼容性需求等，也可以在此節(jié)中記錄。需要注意的是，這里記錄的是專屬于該用例的特殊需求；對于一些全局的非功能性需求和設計約束，它們并不是該用例所專有的，應把它們記錄在《補充規(guī)約》中。前置和后置條件前置條件是執(zhí)行用例之前必須存在的系統(tǒng)狀態(tài)，后置條件是用例一執(zhí)行完畢后系統(tǒng)可能處于的一組狀態(tài)。檢查用例模型用例模型完成之后，可以對用例模型進行檢查，看看是否有遺漏或錯誤之處。主要可以從以下幾個方面來進行檢查：功能需求的完備性

現(xiàn)有的用例模型是否完整地描述了系統(tǒng)功能，這也是我們判斷用例建模工作是否結束的標志。如果發(fā)現(xiàn)還有系統(tǒng)功能沒有被記錄在現(xiàn)有的用例模型中，那么我們就需要抽象一些新的用例來記錄這些需求，或是將他們歸納在一些現(xiàn)有的用例之中。模型是否易于理解

用例模型最大的優(yōu)點就在于它應該易于被不同的涉眾所理解，因而用例建模最主要的指導原則就是它的可理解性。用例的粒度、個數(shù)以及模型元素之間的關系復雜程度都應該由該指導原則決定。是否存在不一致性

系統(tǒng)的用例模型是由多個系統(tǒng)分析員協(xié)同完成的，模型本身也是由多個工件所組成的，所以我們要特別注意不同工件之前是否存在前后矛盾或沖突的地方，避免在模型內(nèi)部產(chǎn)生不一致性。不一致性會直接影響到需求定義的準確性。避免二義性語義

好的需求定義應該是無二義性的，即不同的人對于同一需求的理解應該是一致的。在用例規(guī)約的描述中，應該避免定義含義模糊的需求，即無二義性。.系統(tǒng)需求中根據(jù)模型將系統(tǒng)需求分為以下幾類：功能()可用性()可靠性()性能()可支持性()設計約束等除了第一項功能性需求之外的其他需求都歸之為非功能性需求。需求工件集用例模型主要用于描述系統(tǒng)的功能性需求，對于其他的非功能性需要用其他文檔來記錄。中定義了如下的需求工件集合。用例模型：記錄功能性需求用例圖：描述參及者和用例之間的關系用例規(guī)約：描述每一個用例的細節(jié)信息補充規(guī)約：記錄一些全局性的功能需求、非功能性需求和設計約束等詞匯表：記錄一些系統(tǒng)需求相關的術語在實際應用中，除了這些工件之外，我們還可以根據(jù)實際需求靈活選用其他形式的文檔來補充說明需求。并不是所有的系統(tǒng)需求都適保合用用例模型來描述的，如編譯器，我們很難用用例方法來表述它所處理的語言的方法規(guī)則，在這種情況下，采用傳統(tǒng)的范式來表述更加合適一些。在電信軟件行業(yè)中，很多電信標準都是采用語言來描述的，我們也不必用來改寫這些標準（對存在著這樣的兼容性），只需將形式的電信標準作為需求工件之一，在其他工件中對其加以引用就可以了?？傊?，萬萬不可拘泥于用例建模的形式，應靈活運用各種方式的長處。補充規(guī)約補充規(guī)約記錄那些在用例模型中不易表述的系統(tǒng)需求，主要包括以下內(nèi)容。功能性

功能性需求主要在用例模型中刻畫，但是也有部分需求不適合在用例中表述。有些功能性需求是全局性的，適用于所有的用例，如出錯處理、支持等，我們不需要在所有的用例中描述這些功能性需求，只需要在補充規(guī)約中統(tǒng)一描述就可以了。可用性

記錄所有可用性相關的需求，如系統(tǒng)的使用者所需要的培訓時間、是否應附合一些常見的可用性標準如界面風格等。可靠性

定義系統(tǒng)可靠性相關的各種指標，包括：

可用性：指出可用時間百分比()，系統(tǒng)處于使用、維護、降級模式等操作的小時數(shù)；平均故障間隔時間()：通常表示為小時數(shù)，但也可表示為天數(shù)、月數(shù)或年數(shù)；平均修復時間()：系統(tǒng)在發(fā)生故障后可以暫停運行的時間；精確度：指出系統(tǒng)輸出要求具備的精密度（分辨率）和精確度（按照某一已知的標準）；最高錯誤或缺陷率：通常表示為（每千行代碼的錯誤數(shù)目）或（每個功能點的錯誤數(shù)目）。性能

記錄系統(tǒng)性能相關的各種指標，包括：

對事務的響應時間（平均、最長）；吞吐量（例如每秒處理的事務數(shù)）；容量（例如系統(tǒng)可以容納的客戶或事務數(shù)）；降級模式（當系統(tǒng)以某種形式降級時可接受的運行模式）；資源利用情況：內(nèi)存、磁盤、通信等?？芍С中?/p>

定義所有及系統(tǒng)的可支持性或可維護性相關的需求，其中包括編碼標準、命名約定、類庫、如何來對系統(tǒng)進行維護操作和相應的維護實用工具等。設計約束

設計約束代表已經(jīng)批準并必須遵循的設計決定，其中包括軟件開發(fā)流程、開發(fā)工具、系統(tǒng)構架、編程語言、第三方構件類庫、運行平臺和數(shù)據(jù)庫系統(tǒng)等等。詞匯表詞匯表主要用于定義項目特定的術語，它有助于開發(fā)人員對項目中所用的術語有統(tǒng)一的理解和使用，它也是后續(xù)階段中進行對象抽象的基礎。.調(diào)整用例模型在一般的用例圖中，我們只表述參及者和用例之間的關系，即它們之間的通訊關聯(lián)。除此之外，我們還可以描述參及者及參及者之間的泛化()、用例和用例之間的包含()、擴展()和泛化()關系。我們利用這些關系來調(diào)整已有的用例模型，把一些公共的信息抽取出來重用，使得用例模型更易于維護。但是在應用中要小心選用這些關系，一般來說這些關系都會增加用例和關系的個數(shù)，從而增加用例模型的復雜度。而且一般都是在用例模型完成之后才對用例模型進行調(diào)整，所以在用例建模的初期不必要急于抽象用例之間的關系。參及者之間的關系參及者之間可以有泛化()關系（或稱為"繼承"關系）。例如在需求分析中常見的權限控制問題（如下圖所示），一般的用戶只可以使用一些常規(guī)的操作，而管理員除了常規(guī)操作之外還需要進行一些系統(tǒng)管理工作，操作員既可以進行常規(guī)操作又可以進行一些配置操作。在這個例子中我們會發(fā)現(xiàn)管理員和操作員都是一種特殊的用戶，他們擁有普通用戶所擁有的全部權限，此外他們還有自己獨有的權限。這里我們可進一步把普通用戶和管理員、操作員之間的關系抽象成泛化()關系，管理員和操作員可以繼承普通用戶的全部特性（包括權限），他們又可以有自己獨有的特性（如操作、權限等）。這樣可以顯著減速少用例圖中通訊關聯(lián)的個數(shù)，簡化用例模型，使之更易于理解。用例之間的關系用例描述的是系統(tǒng)外部可見的行為，是系統(tǒng)為某一個或幾個參及者提供的一段完整的服務。從原則上來講，用例之間都是并列的，它們之間并不存在著包含從屬關系。但是從保證用例模型的可維護性和一致性角度來看，我們可以在用例之間抽象出包含()、擴展()和泛化()這幾種關系。這幾種關系都是從現(xiàn)有的用例中抽取出公共的那部分信息，然后通后過不同的方法來重用這部公共信息，以減少模型維護的工作量。包含()包含關系是通過在關聯(lián)關系上應用<<>>構造型來表示的，如下圖所示。它所表示的語義是指基礎用例()會用到被包含用例()，具體地講，就是將被包含用例的事件流插入到基礎用例的事件流中。包含關系是中的表述，在中，同等語義的關系被表述為使用()，如下圖。在機中，如果查詢、取現(xiàn)、轉帳這三個用例都需要打印一個回執(zhí)給客戶，我們就可以把打印回執(zhí)這一部分內(nèi)容提取出來，抽象成為一個單獨的用例"打印回執(zhí)"，而原有的查詢、取現(xiàn)、轉帳三個例都會包含這個用例。每當以后要對打印回執(zhí)部分的需求進行修改時，就只需要改動一個用例，而不用在每一個用例都作相應修改，這樣就提高了用例模型的可維護性。在基礎用例的事件流中，我們只需要引用被包含用例即可。查詢基本事件流.用戶插入信用卡.輸入密碼.選擇查詢.查看帳號余額.包含用例"打印回執(zhí)".退出系統(tǒng)，取回信用卡在這個例子中，多個用例需要用到同一段行為，我們可以把這段共同的行為單獨抽象成為一個用例，然后讓其他的用例來包含這一用例。從而避免在多個用例中重復性地描述同一段行為，也可以防止該段行為在多個用例中的描述出現(xiàn)不一致性。當需要修改這段公共的需求時，我們也只需要修改一個用例，避免同時修改多個用例而產(chǎn)生的不一致性和重復性工作。有時當某一個用例的事件流過于復雜時，為了簡化用例的描述，我們也可以把某一段事件流抽象成為一個被包含的用例。這種情況類似于在過程設計語言中，將程序的某一段算法封裝成一個子過程，然后再從主程序中調(diào)用這一子過程。擴展()擴展（）關系如下圖所示，基礎用例()中定義有一至多個已命名的擴展點，擴展關系是指將擴展用例()的事件流在一定的條件下按照相應的擴展點插入到基礎用例()中。對于包含關系而言，子用例中的事件流是一定插入到基礎用例中去的，并且插入點只有一個。而擴展關系可以根據(jù)一定的條件來決定是否將擴展用例的事件流插入基礎用例事件流，并且插入點可以有多個。例如對于電話業(yè)務，可以在基本通話()業(yè)務上擴展出一些增值業(yè)務如：呼叫等待()和呼叫轉移()。我們可以用擴展關系將這些業(yè)務的用例模型描述如下。在這個例子中，呼叫等待和呼叫轉移都是對基本通話用例的擴展，但是這兩個用例只有在一定的條件下（如應答方正忙或應答方無應答）才會將被擴展用例的事件流嵌入基本通話用例的擴展點，并重用基本通話用例中的事件流。值得注意的是擴展用例的事件流往往可以也可抽象為基礎用例的備選流，如上例中的呼叫等待和呼叫轉移都可以作為基本通話用例的備選流而存在。但是基本通話用例已經(jīng)是一個很復雜的用例了，選用擴展關系將增值業(yè)務抽象成為單獨的用例可以避免基礎用例過于復雜，并且把一些可選的操作獨立封裝在另外的用例中。泛化()當多個用例共同擁有一種類似的結構和行為的時候，我們可以將它們的共性抽象成為父用例，其他的用例作為泛化關系中的子用例。在用例的泛化關系中，子用例是父用例的一種特殊形式，子用例繼承了父用例所有的結構、行為和關系。在實際應用中很少使用泛化關系，子用例中的特殊行為都可以作為父用例中的備選流存在。以下是一個用例泛化關系的例子，執(zhí)行交易是一種交易抽象，執(zhí)行房產(chǎn)交易和執(zhí)行證券交易都是一種特殊的交易形式。用例泛化關系中的事件流示例如下：調(diào)整用例模型用例模型建成之后，我們可以對用例模型進行檢視，看是否可以進一步簡化用例模型、提高重用程度、增加模型的可維護性。主要可以從以下檢查點()入手:用例之間是否相互獨立？如果兩個用例總是以同樣的順序被激活，可能需要將它們合并為一個用例。多個用例之間是否有非常相似的行為或事件流？如果有，可以考慮將它們合并為一個用例。用例事件流的一部分是否已被構建為另一個用例？如果是，可以讓該用例包含()另一用例。是否應該將一個用例的事件流插入另一個用例的事件流中？如果是，利用及另一個用例的擴展關系()來建立此模型。.管理用例模型復雜度一般小型的系統(tǒng)，其用例模型中包含的參及者和用例不會太多，一個用例圖就可以容納所有的參及者，所有的參及者和用例也可以并存于同一個層次結構中。對于較復雜的大中型系統(tǒng)，用例模型中的參及者和用例會大大增加，我們需要一些方法來有效地管理由于規(guī)模上升而造成的復雜度。用例包包()是中最常用的管理模型復雜度的機制，包也是中語義最簡單的一種模型元素，它就是一種容器，在包中可以容納其他任意的模型元素（包括其他的包）。在用例模型中，我們可以用構造型()<<>>來擴展標準包的語義，這種新的包叫作用例包()，用于分類管理用例模型中的模型元素。我們可以根據(jù)參及者和用例的特性來對它們進行分類，分別置于不同的用例包管理之下。例如對于一個大型的企業(yè)管理信息系統(tǒng)，我們可以根據(jù)參及者和用例的內(nèi)容將它們分別歸于人力資源、財務、采購、銷售、客務服務這些用例包之下。這樣我們將整個用例模型劃分成為兩個層次，在第一層次我們看到的是系統(tǒng)功能總共分為五部分，在第二層次我們可以分別看到每一用例包內(nèi)部的參及者和用例。一個用例模型需要有多少個用例包取決你想怎么樣來管理用例模型的復雜度（包括參及者和用例的個數(shù)，以及它們之間的相互關系）。中的包其實就類似于文件系統(tǒng)中的目錄，文件數(shù)量少的時候不需要額外的目錄，文件數(shù)量一多就需要有多個目錄來分類管理，同樣一組文件不同的人會創(chuàng)建不同的目錄結構來進行管理，關鍵是要保證在目錄結構下每一個文件都要易于訪問。同樣的道理存在于用例建模之中，如何創(chuàng)建用例包以及用例包的個數(shù)取決于不同的系統(tǒng)和系統(tǒng)分析員，但要保證整個用例模型易于理解。用例的粒度我的系統(tǒng)需要有多少個用例？這是很多人在用例建模時會產(chǎn)生的疑惑。描述同一個系統(tǒng)，不同的人會產(chǎn)生不同的用例模型。例如對于各種系統(tǒng)中常見的"維護用戶"用例，它里面包含了添加用戶、修改用戶信息、刪除用戶等操作，這些操作在該用例的事件流可以表述成為基本流的子事件流()。維護用戶基本事件流該基本流由三個子事件流構成：)添加用戶子事件流

…)修改用戶子事件流

…)刪除用戶子事件流

…但是你也可以根據(jù)該用例中的具體操作把它抽象成為三個用例，它所表示的系統(tǒng)需求和單個用例的模型是完全一樣的。應該如何確定用例的粒度呢？在一次技術研討會上，有人問起博士，一個系統(tǒng)需要有多少個用例？大師的回答是個，當然他的意思是最好將用例模型的規(guī)?？刂圃趲资畟€用例左右，這樣比較容易來管理用例模型的復雜度。在用例個數(shù)大致確定的條件下，我們就很容易來確定用例粒度的大小。對于較復雜的系統(tǒng)，我們需要控制用例模型一級的復雜度，所以可以將復雜度適當?shù)匾仆恳粋€用例的內(nèi)部，也就是讓一個用例包含較多的需求信息量。對于比較簡單的系統(tǒng)，我們則可以將復雜度適度地曝露在模型一級，也就是我們可以將較復雜的用例分解成為多個用例。用例的粒度不但決定了用例模型級的復雜度，而且也決定了每一個用例內(nèi)部的復雜度。我們應該根據(jù)每個系統(tǒng)的具體情況，因時因宜地來把握各個層次的復雜度，在盡可能保證整個用例模型的易理解性前提下決定用例的大小和數(shù)目。用例圖用例圖的主要作用是描述參及者和用例之間的關系，簡單的系統(tǒng)中只需要有一個用例圖就可以把所有的關系都描述清楚。復雜的系統(tǒng)中可以有多個用例圖，例如每個用例包都可以有一個獨立的用例圖來描述該用例包中所有的參及者和用例的關系。在一個用例模型中，如果參及者和用例之間存在著多對多的關系，并且他們之間的關系比較復雜，如果在同一個用例圖中表述所有的參及者和用例就顯得不夠清晰，這時我們可創(chuàng)建多個用例圖來分別表示各種關系。如果想要強調(diào)某一個參及者和多個用例的關系，你就可以以該參及者為中心，用一個用例圖表述出該參及者和多個用例之間的關系。在這個用例圖中，我們強調(diào)的是該參及者會使用系統(tǒng)所提供的哪些服務。如果想要強調(diào)某一個用例和多個參及者之間的關系，你就可以以該用例為中心，用一個用例圖表述出該用例和多個參及者之間的關系。在這個用例圖中，我們強調(diào)的是該用例會涉及到哪些參及者，或者說該用例所表示的系統(tǒng)服務有哪些使用者?？傊谟美＿^程中，你可以根據(jù)自己的需要創(chuàng)建任意多個用例圖，用不同的用例來強調(diào)參及者和用例之間不同的關系。但是最重要的是要考慮整個用例模型的可理解性，如果可以用一個用例圖把意思表述清楚，就不要再用第二個，因為越是簡潔的模型越易于理解。（網(wǎng)上找的，具體自己看課件）類建模分析類是什么從高的層次描述對象直接及業(yè)務邏輯相關聯(lián)，但不強調(diào)技術細節(jié)分析類類型:實體類表示系統(tǒng)內(nèi)部使用的信息邊界類:一種用于對參及者及系統(tǒng)內(nèi)部運作之間的交互進行建模的類控制類:用于對一個或幾個用例所特有的控制行為進行建模邊緣和控制類用在序列圖中（畫類圖是重點，好好看）包包是一種常規(guī)用途的組合機制。中的一個包直接對應于中的一個包。在中，一個包可能含有其他包、類或者同時含有這兩者。進行建模時，通常使用邏輯性的包，用于對模型進行組織；使用物理性的包，用于轉換成系統(tǒng)中的包。每個包的名稱對這個包進行了惟一性的標識包中有什么：可以包含其他的包和類，或兩者包之間的關系：依賴（一個包引用了另一個包的元素，另一個包改變會影響它）和獨立動態(tài)建模狀態(tài)圖狀態(tài)圖是用來為對象的狀態(tài)及造成狀態(tài)改變的事件建模。的狀態(tài)機圖主要用于建立對象類或對象的動態(tài)行為模型，表現(xiàn)一個對象所經(jīng)歷的狀態(tài)序列，引起狀態(tài)或活動轉移的事件，以及因狀態(tài)或活動轉移而伴隨的動作。狀態(tài)機圖也可用于描述,以及全系統(tǒng)的動態(tài)行為。狀態(tài)圖表示一個模型元素在其生命期間的情況：從該模型元素的開始狀態(tài)起，響應事件，執(zhí)行某些動作，引起轉移到新狀態(tài)，又在新狀態(tài)下響應事件，執(zhí)行動作，引起轉移到另一個狀態(tài)，如此繼續(xù)，直到終結狀態(tài)。類圖測試(,類責任協(xié)作)使用迭代是軟件產(chǎn)品的內(nèi)部特點六：什么的面向對象設計：根據(jù)分析模型，設計軟件設計的原則：模塊化，低耦合，高內(nèi)聚，支持復用(耦合)：不同模塊間的互聯(lián)程度(松耦合)：一個模塊的改變對另一個影響小(緊耦合)：一個模塊的改變對另一個有很壞的影響數(shù)據(jù)耦合標記耦合控制耦合公共耦合內(nèi)容耦合數(shù)據(jù)耦合一個模塊訪問另一個模塊