第一篇：UML學(xué)習(xí)心得體會(huì)

——uml學(xué)習(xí)體會(huì)

養(yǎng)成良好的繪制uml序列圖的習(xí)慣 在學(xué)習(xí)uml的過(guò)程中，你可能會(huì)遇到繪制uml序列圖的問(wèn)題，這里就討論一下怎樣才能養(yǎng)成良好的繪制uml序列圖的習(xí)慣。

有一些方法可以幫助您提高uml序列圖的質(zhì)量和效力。它們包括：和主題問(wèn)題專家一起驗(yàn)證決策；使解決方案盡量簡(jiǎn)單；為繪制消息和返回值選擇一種一

致且有效的風(fēng)格；將序列圖分層；遵循一致的邏輯風(fēng)格；牢記序列圖是動(dòng)態(tài)的。一：驗(yàn)證決策

繪制uml序列圖時(shí)，我做了一些對(duì)其它模型可能有潛在影響的決策。例如，在對(duì)第10步建模時(shí)，假設(shè)（大致上是個(gè)設(shè)計(jì)決策）費(fèi)用顯示屏幕同時(shí)也處理學(xué)生對(duì)費(fèi)用是否可接受所進(jìn)行的驗(yàn)證。該決策應(yīng)該由用戶界面原型反映出來(lái)，并由主題問(wèn)題專家(sme)進(jìn)行驗(yàn)證。您應(yīng)該和sme（特別是那些對(duì)于如何開(kāi)發(fā)類似模型有著深刻見(jiàn)解的富有經(jīng)驗(yàn)的人）一起執(zhí)行序列圖的繪制工作。

二：保持簡(jiǎn)單

在對(duì)第2和第3步建模時(shí)，我忽然意識(shí)到學(xué)生可能應(yīng)該使用口令進(jìn)入系統(tǒng)。在向sme提出了這個(gè)概念后發(fā)覺(jué)我錯(cuò)了：姓名和學(xué)號(hào)組合對(duì)于我們的目的來(lái)說(shuō)已經(jīng)足夠唯一，并且學(xué)校也不希望增加復(fù)雜的口令管理。這是個(gè)很有意思的決策，因?yàn)檫@是學(xué)校的一個(gè)運(yùn)作策略，所以可以作為一條商業(yè)規(guī)則記載到增補(bǔ)規(guī)范中。通過(guò)與sme一起檢驗(yàn)這個(gè)想法，而不是假定我比他們知道得更多，我避免了“鍍金”的機(jī)會(huì)，因而減少了我們小組開(kāi)發(fā)這一系統(tǒng)所需的工作。

三：繪制消息和返回值

繪制uml序列圖時(shí)我更喜歡從左至右地繪制消息，從右至左地繪制返回值，盡管這樣對(duì)于復(fù)雜的對(duì)象／類來(lái)說(shuō)不總是非常合適。我將消息上的標(biāo)簽和返回值對(duì)齊到離箭頭最近的位置。我不喜歡在序列圖上標(biāo)出返回值，為的是使圖盡可能地簡(jiǎn)化。不過(guò)，始終標(biāo)出返回值也同樣有效，特別是在序列圖用于設(shè)計(jì)而不是分析目的時(shí)。（我希望我的分析圖盡量簡(jiǎn)單，而設(shè)計(jì)圖盡量全面。）在分析期間，我的目標(biāo)是理解邏輯和確保邏輯的正確性。而在設(shè)計(jì)期間，則要賦予消息精確的細(xì)節(jié)。

四：將序列圖分層 繪制uml序列圖時(shí)我喜歡將序列圖從左至右地分層。先標(biāo)出參與者，然后是控制器類，然后是用戶界面類，最后是商業(yè)類。在設(shè)計(jì)期間，可能需要添加系統(tǒng)類和持久類，我通常將它們放在序列圖的最右側(cè)。以這種方式將序列圖分層往往使它們更易于閱讀，并且更容易找出分層邏輯問(wèn)題，例如用戶界面類直接訪問(wèn)持久類。

五：遵循一致的邏輯風(fēng)格

請(qǐng)注意，在圖1序列圖所示的過(guò)程中，邏輯風(fēng)格做了部分更改。一開(kāi)始，特別是在登錄時(shí)，用戶界面處理一些基本邏輯--而在選擇研習(xí)班，以及稍后的驗(yàn)證時(shí)，則是控制器類進(jìn)行處理。這實(shí)際上是個(gè)設(shè)計(jì)問(wèn)題。我不會(huì)在這個(gè)問(wèn)題上糾纏太久，但和往常一樣，我建議選擇一種適合于您的建模風(fēng)格，然后始終如一地貫徹在所有序列圖中。

六：牢記序列圖是動(dòng)態(tài)的繪制uml序列圖時(shí)您可能聽(tīng)說(shuō)過(guò)諸如動(dòng)態(tài)建模和靜態(tài)建模這樣的術(shù)語(yǔ)，其他一些熟悉面向?qū)ο蠼＜夹g(shù)的開(kāi)發(fā)人員常常會(huì)提到它們。您甚至可能聽(tīng)到過(guò)有關(guān)每種風(fēng)格的優(yōu)點(diǎn)的爭(zhēng)論。動(dòng)態(tài)建模技術(shù)主要集中在標(biāo)識(shí)系統(tǒng)中的行為，包括序列圖的繪制和活動(dòng)圖的繪制（請(qǐng)參閱“如何繪制uml活動(dòng)圖”）以及uml協(xié)作圖的繪制。而靜態(tài)建模則集中在系統(tǒng)的靜態(tài)方面，包括類、它們的屬性，以及類之間的關(guān)聯(lián)。類模型和持久／數(shù)據(jù)模型一樣，都是靜態(tài)建模的主要產(chǎn)物。uml學(xué)習(xí)心得(一)uml（unified modeling language，統(tǒng)一建模語(yǔ)言）是一組用于描述ooad過(guò)程的圖形化表達(dá)方式。uml為交流面向?qū)ο蟮脑O(shè)計(jì)中的需求，行為、體系結(jié)構(gòu)的實(shí)現(xiàn)提供了一套綜合的表示法。(二)uml由9個(gè)不同類型的圖組成：

用例圖：顯示了系統(tǒng)的外部可視行為。

用例圖描述了系統(tǒng)外的人員和系統(tǒng)的交互動(dòng)作，以及系統(tǒng)的響應(yīng)，該類型的圖可以用于描述系統(tǒng)的功能需求。

活動(dòng)圖：顯示系統(tǒng)行為的峽谷納西描述。

活動(dòng)圖描述了單個(gè)功能需求內(nèi)部的細(xì)節(jié)行為，包括基本的場(chǎng)景和一些可選的場(chǎng)景。

組件圖：顯示了系統(tǒng)的體系結(jié)構(gòu)。

組件圖描述了系統(tǒng)的可部署單元（可執(zhí)行文件，組件，數(shù)據(jù)存儲(chǔ)和其他一些內(nèi)容）以及一些借口，可部署單元通過(guò)這些接口進(jìn)行交互，該圖可以用于研究系統(tǒng)的體系結(jié)構(gòu)。

順序圖：顯示了對(duì)象隨著時(shí)間的交互。

順序圖描述了某個(gè)功能需求的路徑或場(chǎng)景內(nèi)相對(duì)時(shí)間的詳細(xì)行為，該圖可用于理解系統(tǒng)元素之間的消息流程。

協(xié)作圖：顯示了對(duì)象的交互，強(qiáng)調(diào)對(duì)象之間的關(guān)系。（在uml2.0里面找不到了）

類圖：顯示了類的定義和關(guān)系。

類圖描述了系統(tǒng)設(shè)計(jì)中的類和接口，以及他們之間的關(guān)系。該圖可用于定義內(nèi)部的，面向?qū)ο蟮拇a結(jié)構(gòu)。

狀態(tài)圖：顯示了響應(yīng)時(shí)間的狀態(tài)改變。

狀態(tài)圖描述了系統(tǒng)如何改變狀態(tài)以相應(yīng)內(nèi)部的和外部的事件，確保每個(gè)事件都被適當(dāng)?shù)奶幚怼?/p>

部署圖：顯示了系統(tǒng)的物理體系結(jié)構(gòu)。

部署圖描述了系統(tǒng)的可部署單元（應(yīng)用，組件，數(shù)據(jù)存儲(chǔ)等）如何被賦予不同的節(jié)點(diǎn)，這些節(jié)點(diǎn)如何交互通信，用于系統(tǒng)映射和負(fù)載的研究。

包圖：顯示了設(shè)計(jì)的層次結(jié)構(gòu)。

包圖描述了設(shè)計(jì)的相關(guān)元素如何按組結(jié)合在一起，以及他們之間的關(guān)系。(三)各種圖的作用

1.用例圖（usecasediagram）

它是uml中最簡(jiǎn)單也是最復(fù)雜的一種圖。說(shuō)它簡(jiǎn)單是因?yàn)樗捎昧嗣嫦驅(qū)ο蟮乃枷耄质腔谟脩粢暯堑?，繪制非常容易，簡(jiǎn)單的圖形表示讓人一看就懂。說(shuō)它復(fù)雜是因?yàn)橛美龍D往往不容易控制，要么過(guò)于復(fù)雜，要么過(guò)于簡(jiǎn)單。用例圖表示了角色和用例以及它們之間的關(guān)系。

2.類圖（classdiagram）uml面向?qū)ο笾惺亲畛Ｓ玫囊环N圖，類圖可以幫助我們更直觀的了解一個(gè)系統(tǒng)的體系結(jié)構(gòu)。通過(guò)關(guān)系和類表示的類圖，可以圖形化的方式描述一個(gè)系統(tǒng)的設(shè)計(jì)部分。3.對(duì)象圖 uml面向?qū)ο笾袑?duì)象圖是類圖的實(shí)例，幾乎使用與類圖完全相同的標(biāo)識(shí)。它們的不同點(diǎn)在于對(duì)象圖顯示類的多個(gè)對(duì)象實(shí)例，而不是實(shí)例的類。一個(gè)對(duì)象圖是類圖的一個(gè)實(shí)例。由于對(duì)象存在生命周期，因此對(duì)象圖只能在系統(tǒng)某一時(shí)間段存在。4.狀態(tài)圖

描述一個(gè)實(shí)體基于事件反應(yīng)的動(dòng)態(tài)行為，顯示了該實(shí)體如何根據(jù)當(dāng)前所處的狀態(tài)對(duì)不同的時(shí)間做出反應(yīng)的。通常創(chuàng)建一個(gè)uml狀態(tài)圖是為了以下的研究目的：研究類、角色、子系統(tǒng)、或組件的復(fù)雜行為。5.時(shí)序圖

又稱順序圖，描述了對(duì)象之間動(dòng)態(tài)的交互關(guān)系，著重體現(xiàn)對(duì)象間消息傳遞的時(shí)間順序。順序圖由一組對(duì)象構(gòu)成，每個(gè)對(duì)象分別帶有一條豎線，稱作對(duì)象的生命線，它代表時(shí)間軸，時(shí)間沿豎線向下延伸。uml面向?qū)ο笾许樞驁D描述了這些對(duì)象隨著時(shí)間 的推移相互之間交換消息的過(guò)程。消息用從一務(wù)垂直的對(duì)象生命線指向另一個(gè)對(duì)象的生命線的水平箭頭表示。圖中還可以根據(jù)需要增加有關(guān)時(shí)間的說(shuō)明和其他注釋。6.協(xié)作圖 uml面向?qū)ο笾袇f(xié)作圖用于顯示組件及其交互關(guān)系的空間組織結(jié)構(gòu)，它并不側(cè)重于交互的順序。協(xié)作圖顯示了交互中各個(gè)對(duì)象之間的組織交互關(guān)系以及對(duì)象 彼此之間的鏈接。與序列圖不同，協(xié)作圖顯示的是對(duì)象之間的關(guān)系。另一方面，協(xié)作圖沒(méi)有將時(shí)間作為一個(gè)單獨(dú)的維度，因此序列號(hào)就決定了消息及并發(fā)線程的順 序。協(xié)作圖是一個(gè)介于符號(hào)圖和序列圖之間的交叉產(chǎn)物，它用帶有編號(hào)的箭頭來(lái)描述特定的方案，以顯示在整個(gè)方案過(guò)程中消息的移動(dòng)情況。

協(xié)作圖用途：

通過(guò)描繪對(duì)象之間消息的移動(dòng)情況來(lái)反映具體的方案。

顯示對(duì)象及其交互關(guān)系的空間組織結(jié)構(gòu)，而非交互的順序。7.活動(dòng)圖（activitydiagram）uml面向?qū)ο笾衭ml活動(dòng)圖記錄了單個(gè)操作或方法的邏輯，單個(gè)用戶案例，或者單個(gè)業(yè)務(wù)流程的邏輯。描述系統(tǒng)中各種活動(dòng)的執(zhí)行順序，通常用于描述一個(gè)操作中所要進(jìn)行的各項(xiàng)活動(dòng)的執(zhí)行流程。同時(shí)，它也常被用來(lái)描述一個(gè)用例的處理流程，或者某種交互流程。

活動(dòng)圖由一些活動(dòng)組成，圖中同時(shí)包括了對(duì)這些活動(dòng)的說(shuō)明。當(dāng)一個(gè)活動(dòng)執(zhí)行完畢之后，控制將沿著控制轉(zhuǎn)移箭頭轉(zhuǎn)向下一個(gè)活動(dòng)?；顒?dòng)圖中還可以方便地描述控制轉(zhuǎn)移的條件以及并行執(zhí)行等要求。

組件圖是用來(lái)反映代碼的物理結(jié)構(gòu)。從組件圖中，可以了解各軟件組件（如源代碼文件或動(dòng)態(tài)鏈接庫(kù)）之間的編譯器和運(yùn)行時(shí)依賴關(guān)系。使用組件圖可以將系統(tǒng)劃分為內(nèi)聚組件并顯示代碼自身的結(jié)構(gòu)。

組件圖的主要目的是顯示系統(tǒng)組件間的結(jié)構(gòu)關(guān)系。9.配置圖

uml面向?qū)ο笾信渲脠D描述系統(tǒng)中硬件和軟件的物理配置情況和系統(tǒng)體系結(jié)構(gòu)。

在配置圖中，用結(jié)點(diǎn)表示實(shí)際的物理設(shè)備，如計(jì)算機(jī)和各種外部設(shè)備等，并根據(jù)它們之間的連接關(guān)系，將相應(yīng)的結(jié)點(diǎn)連接起來(lái)，并說(shuō)明其連接方式。在結(jié)點(diǎn)里面，說(shuō)明分配給該結(jié)點(diǎn)上運(yùn)行的可執(zhí)行構(gòu)件或?qū)ο?，從而說(shuō)明哪些軟件單元被分配在哪些結(jié)點(diǎn)上運(yùn)行。uml是一種軟件建模語(yǔ)言，可以對(duì)任何具有靜態(tài)結(jié)構(gòu)和動(dòng)態(tài)行為的系統(tǒng)進(jìn)行建模。在關(guān)注它建模特性的同時(shí)更要關(guān)注它的過(guò)程特性--在什么時(shí)間做什么工作，用什么模型，讓哪些人來(lái)做。對(duì)系統(tǒng)用戶而言，軟件的開(kāi)發(fā)模型向他們描述了軟件開(kāi)發(fā)者對(duì)軟件系統(tǒng)需求的理解。讓系統(tǒng)用戶查看軟件對(duì)象模型并且找到其中的問(wèn)題，可以使開(kāi)發(fā)者不至于從一開(kāi)始就發(fā)生錯(cuò)誤。對(duì)軟件開(kāi)發(fā)而言，軟件的對(duì)象模型有助于他們對(duì)軟件的需求以及系統(tǒng)的架構(gòu)和功能進(jìn)行溝通。對(duì)軟件的維護(hù)和技術(shù)支持者而言，在軟件系統(tǒng)開(kāi)始運(yùn)行后的相當(dāng)長(zhǎng)的一段時(shí)間內(nèi)，軟件的對(duì)象模型能夠幫助他們理解程序的架構(gòu)和功能，迅速地對(duì)軟件所出現(xiàn)的問(wèn)題進(jìn)行修復(fù)。建模并不是僅對(duì)大型的軟件系統(tǒng)，甚至一個(gè)小型的留言本也能從建模的過(guò)程中受益。利用uml可以有效地解決軟件設(shè)計(jì)和分析過(guò)程中的溝通和交流問(wèn)題，可以高效的了解整個(gè)系統(tǒng)結(jié)構(gòu)，并且在設(shè)計(jì)之初就將軟件的設(shè)計(jì)結(jié)構(gòu)和思想固化在紙上有利于規(guī)避項(xiàng)目實(shí)施 過(guò)程中程序員離開(kāi)的風(fēng)險(xiǎn)。uml可以貫穿軟件開(kāi)發(fā)周期中的沒(méi)一個(gè)階段，在開(kāi)發(fā)階段，他可以用于說(shuō)明、可視化、構(gòu)建和書(shū)寫面向?qū)ο筌浖破返脑O(shè)計(jì)語(yǔ)言。uml能貫穿整個(gè)軟件開(kāi)發(fā)過(guò)程是因?yàn)樵诿總€(gè)階段都能夠提供相應(yīng)相應(yīng)的圖形來(lái)對(duì)應(yīng)，使得改變需求，設(shè)計(jì)代碼，測(cè)試分析能變得相對(duì)簡(jiǎn)單。在需求分析過(guò)程中，應(yīng)該分為兩個(gè)過(guò)程：1 需求的獲取

2、需求的分析。需求的獲取，往往不受到重視，在網(wǎng)上經(jīng)?？吹接腥苏f(shuō)，特別是國(guó)內(nèi)目前的情況，項(xiàng)目工期緊，公司往往想方設(shè)法先把項(xiàng)目拿下來(lái)，然后就拿自己公司 以往做過(guò)的項(xiàng)目做藍(lán)本，然后再根據(jù)顧客的需求改動(dòng)，再次開(kāi)發(fā)，測(cè)試，交付就完工了。但如果需求的獲取，做不好，往往對(duì)后面的步驟流程造成很大的影響，造成 太多的改動(dòng)和損失。所以為了得到更好的需求，使用uml建模能變得相對(duì)簡(jiǎn)單。例如需求的用例圖對(duì)系統(tǒng)的功能模型的搭建。用例間的關(guān)系有包含、擴(kuò)展、泛化三類。用例圖包括角色、用例和關(guān) 系。角色可以有角色的描述，用例可以有用例的描述，這些描述在交流或評(píng)審中會(huì)非常有用。用例可以泛化，泛化用例具有基本用例的功能，還可以做得更多。角色 也可以泛化，泛化角色能執(zhí)行原角色能執(zhí)行的所有用例，還可以執(zhí)行更多的用例。除了基本用例，角色不能與包含用例、擴(kuò)展用例和泛化用例有聯(lián)系。一個(gè)用例可以 對(duì)應(yīng)一個(gè)類圖。增、刪、改、查一般來(lái)說(shuō)對(duì)于大多數(shù)應(yīng)用做為一個(gè)簡(jiǎn)單的操作即可，不必要作為一個(gè)用例來(lái)分析。篇三：uml實(shí)訓(xùn)總結(jié) 實(shí)訓(xùn)總結(jié)（收獲與體會(huì)）

通過(guò)一個(gè)學(xué)期的uml學(xué)習(xí)，我從書(shū)本上獲取了基本的理論知識(shí)，而真正的學(xué)以致用，將書(shū)本理論知識(shí)運(yùn)用到實(shí)際的過(guò)程，是這次uml實(shí)訓(xùn)的體現(xiàn)。

三個(gè)周的uml實(shí)訓(xùn)，主要是圍繞著一個(gè)實(shí)訓(xùn)題目“基于uml系統(tǒng)需求分析與設(shè)計(jì)--合倍利業(yè)務(wù)流管理系統(tǒng)”進(jìn)行的，以小組為單位進(jìn)行文檔的編寫，其中還對(duì)各種流程圖、類圖、用例圖等的繪制，整個(gè)過(guò)程設(shè)計(jì)了知識(shí)的方方面面。從中讓我認(rèn)識(shí)到uml的作用和運(yùn)作模式以及方法，它是一種統(tǒng)一建模的標(biāo)準(zhǔn)語(yǔ)言，現(xiàn)在對(duì)于大多數(shù)軟件開(kāi)發(fā)來(lái)說(shuō)，都使用uml作為建模語(yǔ)言，形成了統(tǒng)一的標(biāo)準(zhǔn)。它是圖形化的的語(yǔ)言，可以很直觀的描述一個(gè)事物的狀態(tài)、行為與特征，很好的說(shuō)明與表達(dá)了“合貝利任務(wù)管理”這個(gè)系統(tǒng)?？傊?，在我看來(lái)，uml是一種定義良好、易于表達(dá)、功能強(qiáng)大且普遍適用建模語(yǔ)言。融入軟件工程領(lǐng)域的心思想、新方法和新技術(shù)，作用域不限于支持面向?qū)ο蟮姆治龊驮O(shè)計(jì)，也不單純是一種方法，僅僅是一組符號(hào)而已，它可以對(duì)任何具有靜態(tài)機(jī)構(gòu)和動(dòng)態(tài)行為的系統(tǒng)進(jìn)行建模，所以我很喜歡適用uml，在今后的學(xué)習(xí)中，我還會(huì)進(jìn)一步對(duì)該模型的學(xué)習(xí)，因?yàn)樗奖?、?jiǎn)潔、干凈、清爽，直觀形象，把整個(gè)軟件系統(tǒng)的開(kāi)發(fā)流程都融入進(jìn)去。

這次實(shí)訓(xùn)過(guò)程中，文檔方面的編寫，遇到了很多的問(wèn)題，這些問(wèn)題主要是對(duì)基礎(chǔ)知識(shí)的理解和把握不夠，不能融會(huì)貫通和學(xué)以致用，有時(shí)遇到困難的時(shí)候真的不知如何著手解決，但是，我始終相信的那句話“讀萬(wàn)卷書(shū)，不如行萬(wàn)里路，行萬(wàn)里路不如名師指路”。所以，當(dāng)遇到自己模糊和自己難以解決的問(wèn)題時(shí)，向指導(dǎo)老師和懂的同學(xué)請(qǐng)教，幫助解決我遇到的問(wèn)題，經(jīng)過(guò)他們的講解后，我下來(lái)自己在分析，在動(dòng)手，從不理解到理解，從不會(huì)到會(huì)，從懂到懂，這是一個(gè)讓我學(xué)習(xí)愉快的過(guò)程，在這個(gè)過(guò)程中，既可以豐富了自己的知識(shí)，還可以和老師和同學(xué)進(jìn)行有效地方溝通。

在這次實(shí)訓(xùn)過(guò)程中，感觸最深的也就是合作精神了。獨(dú)木難成林，單槍匹馬，那是最錯(cuò)誤的思想和做法。這次我是深有感觸了。對(duì)于一個(gè)系統(tǒng)的分析，到最終項(xiàng)目的完成，需要分析每個(gè)文檔，然后在寫出紙質(zhì)的文檔，而在每個(gè)文檔中，內(nèi)容比較多，分析也要求比較到位，所以單獨(dú)憑借一個(gè)人去完成，似乎有點(diǎn)困難，于是我們小組，將每個(gè)文檔進(jìn)行分析，能獨(dú)立成塊就分配給每一個(gè)人，這樣，每個(gè)人都有自己的任務(wù)，誰(shuí)也不會(huì)閑著，既學(xué)到了知識(shí)，也充實(shí)了自己。另外一點(diǎn)，就是我深深體會(huì)到了積累知識(shí)的重要性。在實(shí)訓(xùn)當(dāng)中我們遇到了不少難題，但是經(jīng)過(guò)我們大家的討論和老師細(xì)心的一一指導(dǎo)，問(wèn)題得到了解決。兩個(gè)月的實(shí)訓(xùn)結(jié)束了，收獲頗豐，同時(shí)也更深刻的認(rèn)識(shí)到要做一個(gè)合格的程序員并非我以前想像的那么容易，最重要的還是細(xì)致嚴(yán)謹(jǐn)。社會(huì)是不會(huì)要一個(gè)一無(wú)是處的人的，所以我們要更多更快地從一個(gè)學(xué)生向工作者轉(zhuǎn)變，總的來(lái)說(shuō)我對(duì)這次實(shí)習(xí)還是比較滿意的，它使我學(xué)到了很多東西，為我以后的學(xué)習(xí)做了引導(dǎo)，點(diǎn)明了方向。實(shí)訓(xùn)的日子即將結(jié)束，回想這一個(gè)過(guò)程，有過(guò)痛苦，有過(guò)煩惱，有過(guò)喜悅和有過(guò)成功。痛苦煩惱的是自己對(duì)所學(xué)書(shū)本知識(shí)掌握得不是很扎實(shí)，面對(duì)著從書(shū)本上學(xué)到的知識(shí)與實(shí)際聯(lián)系不起來(lái)，總結(jié)起來(lái)就是自己的動(dòng)手練習(xí)的時(shí)間太少。而喜悅的是，在做的過(guò)程中遇到了困難和問(wèn)題，主動(dòng)向老師和會(huì)的同學(xué)請(qǐng)教，然后再做，直至做正確做成功后的那種喜悅。

團(tuán)隊(duì)的力量是無(wú)窮的，通過(guò)組員的共同努力，完成了實(shí)訓(xùn)項(xiàng)目。雖然，我們這組的項(xiàng)目存在著諸多的不足和缺點(diǎn)，但這正是以后學(xué)習(xí)和工作需要彌補(bǔ)的。這次實(shí)訓(xùn)將為我以后進(jìn)入社會(huì)提過(guò)了一筆寶貴的財(cái)富，是對(duì)我能力的一個(gè)見(jiàn)證。最后，不得不感謝指導(dǎo)教師熊飛老師的辛勤指導(dǎo)，和小組成員的共同努力！篇四：uml課設(shè)心得

六月23號(hào)至六月27號(hào)，是我們班進(jìn)行uml專用周課程設(shè)計(jì)的時(shí)間，雖然時(shí)間并不是很長(zhǎng)，只有短短的一個(gè)星期而已，但是讓我受益匪淺，通過(guò)這次的uml課程設(shè)計(jì)，使我所學(xué)的書(shū)本知識(shí)得到了全面的檢驗(yàn)，也讓我對(duì)這門課程有了更加深厚的體會(huì)。

這次課程設(shè)計(jì)我們沒(méi)有另外選題，而是在我們之前做過(guò)的系統(tǒng)之上加以完善和改進(jìn)?，F(xiàn)在看看之前提交的作品，確實(shí)不近人意；但經(jīng)過(guò)在網(wǎng)上的不斷查找資料，終于還是將它完成。之前我做的系統(tǒng)狀態(tài)圖和活動(dòng)圖，為了鍛煉自己這次選擇了交互圖（也就是時(shí)序圖和協(xié)作圖）。雖然說(shuō)自己沒(méi)有這方面的經(jīng)驗(yàn)，也不是特別熟悉其工作流程，但是有了在網(wǎng)上 查找資料得來(lái)的一些基礎(chǔ)和課本里的講解，自己對(duì)它也有了一定初步的認(rèn)識(shí)，雖然不是很全面，但還是跌跌撞撞的完成。其中還因?yàn)楹徒M員沒(méi)有溝通好導(dǎo)致用的類不同，費(fèi)了好大勁才改回來(lái)。

最后，這次課設(shè)使我們發(fā)現(xiàn)考試真的并不是最重要，最重要的是能運(yùn)用所學(xué)的知識(shí)。在整個(gè)uml課程的學(xué)習(xí)過(guò)程中，我們突破了傳統(tǒng)學(xué)習(xí)模式，把被動(dòng)接受轉(zhuǎn)變?yōu)橹鲃?dòng)學(xué)習(xí)。不再是用學(xué)到的知識(shí)解題，而是在實(shí)際運(yùn)用時(shí)遇到什么學(xué)什么，重在把知識(shí)應(yīng)用于實(shí)際。立體的運(yùn)用比死板的模仿更有效也更容易接受。下學(xué)期就大四了，也就是大學(xué)校園里的最后一年，而課設(shè)里學(xué)到的動(dòng)手能力和分析問(wèn)題解決問(wèn)題的能力也將是我們畢業(yè)找工作的一大籌碼。篇五：uml學(xué)習(xí)重點(diǎn)匯總

第一章 oom&軟件建模概述 uml（unified modeling language）

通用的標(biāo)準(zhǔn)建模語(yǔ)言,可以對(duì)任何具有靜態(tài)結(jié)構(gòu)和動(dòng)態(tài)行為的系統(tǒng)進(jìn)行建模。標(biāo)準(zhǔn)建模語(yǔ)言u(píng)ml適用于以面向?qū)ο蠹夹g(shù)來(lái)描述任何類型的系統(tǒng),而且適用于系統(tǒng)開(kāi)發(fā)的不同階段,從需求規(guī)格描述直至系統(tǒng)完成后的測(cè)試和維護(hù)。

特點(diǎn)：統(tǒng)一標(biāo)準(zhǔn)，面向?qū)ο?，可視化、表達(dá)能力強(qiáng)，獨(dú)立于過(guò)程，uml很適合于以體系結(jié)構(gòu)中心的、用例驅(qū)動(dòng)的、迭代式和漸增式的軟件開(kāi)發(fā)過(guò)程 第二章 uml構(gòu)成 1.uml的“4+1視圖”

從某個(gè)角度觀察系統(tǒng)構(gòu)成系統(tǒng)的一個(gè)視圖，每個(gè)

數(shù)據(jù)庫(kù)

5活動(dòng)圖——泳道圖

泳道將活動(dòng)圖中的活動(dòng)化分為若干組，并把每一視圖都是系統(tǒng)描述的一個(gè)投影，說(shuō)明了系統(tǒng)某個(gè)側(cè)面的特征。（1）用例視圖（2）邏輯視圖（3）組件視圖（4）進(jìn)程視圖（并發(fā)視圖）（5）配置視圖（部署視圖）2.uml的模型圖：

模型圖是一組uml模型元素構(gòu)成的有向圖表示，它通常由一組節(jié)點(diǎn)（uml基本模型元素）, 及節(jié)點(diǎn)之間的連線（關(guān)系）組成。(1)用例視圖：用例圖(2)靜態(tài)模型：類圖、對(duì)象圖、包圖、構(gòu)件圖和配置圖(3)動(dòng)態(tài)模型：活動(dòng)圖、順序圖、狀態(tài)圖和協(xié)作圖 3.用例圖.用例圖是表達(dá)用例和參與者及其關(guān)系的載體。關(guān)系包括：關(guān)聯(lián)關(guān)系，依賴關(guān)系 實(shí)現(xiàn)關(guān)系： 3.用例圖(續(xù))——用例之間關(guān)系1（包含與擴(kuò)展）.3.用例圖(續(xù))——用例之間關(guān)系2（泛化）.3.用例圖(續(xù))——用例與參與者

用例use case：一組用例的實(shí)例（場(chǎng)景），其中每個(gè)實(shí)例都是系統(tǒng)執(zhí)行的一系列活動(dòng)，這些活動(dòng)產(chǎn)生了對(duì)每個(gè)參與者而言可觀察的返回值。描述了從參與者角度看系統(tǒng)做了什么

用例模型本身不是面向?qū)ο蠼＜夹g(shù)。

參與者actor: 是指在系統(tǒng)外部與系統(tǒng)交互的人或其他系統(tǒng)，以某種方式參與了系統(tǒng)內(nèi)用例的執(zhí)行。4.交互式視圖圖(順序圖、協(xié)作圖)1）協(xié)作圖：采用圖的形式展示對(duì)象間的交互 2）順序圖：采用柵欄格式展示對(duì)象間的交互

順序圖與協(xié)作圖的優(yōu)缺點(diǎn)： 順序圖

（優(yōu)點(diǎn)）強(qiáng)調(diào)消息的時(shí)間順序及對(duì)象生命線（優(yōu)點(diǎn)）大量詳細(xì)表示法選項(xiàng)

（缺點(diǎn)）強(qiáng)制在右側(cè)增加新對(duì)象，消耗空間大 協(xié)作圖（優(yōu)點(diǎn)）強(qiáng)調(diào)結(jié)構(gòu)組織，復(fù)雜交互表達(dá)更容易（優(yōu)點(diǎn)）空間利用率高，和方便添加新對(duì)象（缺點(diǎn)）不宜查詢消息的順序，表示法選項(xiàng)少 5 活動(dòng)圖

活動(dòng)圖用于表示完成一個(gè)操作所需要的活動(dòng)，或者是一個(gè)用例實(shí)例（場(chǎng)景）的活動(dòng)?；顒?dòng)圖適合描述動(dòng)作流和并發(fā)處理行為。5活動(dòng)圖——實(shí)例

組指定給負(fù)責(zé)這組活動(dòng)的業(yè)務(wù)組織即對(duì)象。泳道區(qū)分了負(fù)責(zé)活動(dòng)的對(duì)象，明確地表示了哪些活動(dòng)是由哪些對(duì)象進(jìn)行的。

每個(gè)活動(dòng)只能明確地屬于一個(gè)泳道。6 狀態(tài)圖（狀態(tài)機(jī)）

狀態(tài)圖(state diagram)一個(gè)對(duì)象在其生存期間的動(dòng)態(tài)行為，表現(xiàn)對(duì)象響應(yīng)事件所經(jīng)歷的狀態(tài)序列以及伴隨的動(dòng)作。并不是所有類都有相應(yīng)的狀態(tài)圖。狀態(tài)圖只適用于：具有若干個(gè)確定狀態(tài)，類的行為在這些狀態(tài)下 會(huì)受到影響且被不同的狀態(tài)改變。

狀態(tài)圖與活動(dòng)圖的區(qū)別與聯(lián)系（1）相同的圖形符號(hào)。

（2）描述一個(gè)系統(tǒng)或?qū)ο笤谏嬷芷诘臓顟B(tài)或行為。（3）描述系統(tǒng)或?qū)ο笤诙噙M(jìn)程中同步或異步操作并發(fā)行為。

（4）用條件分支來(lái)描述系統(tǒng)或?qū)ο蟮男袨榭刂屏?。?lián)系：

（2）描述多個(gè)對(duì)象共同完成一個(gè)操作的機(jī)制不同。活動(dòng)圖置于責(zé)任區(qū)（泳道）中，責(zé)任區(qū)將活動(dòng)按責(zé)任目標(biāo)和組織歸屬的原則分類。狀態(tài)圖采用狀態(tài)嵌套方式描述多

對(duì)象協(xié)作。

7、類圖

類圖表示系統(tǒng)中類及類和類之間的關(guān)系，用于對(duì)系統(tǒng)的靜態(tài)結(jié)構(gòu)進(jìn)行描述。類用來(lái)表示系統(tǒng)中需要處理的事物.類的關(guān)系：

（1）關(guān)聯(lián)：關(guān)聯(lián)表示兩個(gè)類的對(duì)象之間存在某種語(yǔ)義上的聯(lián)系。

（2）聚集：聚集也稱為聚合，關(guān)聯(lián)的特例 聚集表示類與類之間的關(guān)系是整體與部分的關(guān)系。

（3）泛化：uml中的泛化關(guān)系就是通常所說(shuō)的繼承關(guān)系，它是通用元素和具體元素之間的一種分類關(guān)系。（4）依賴和細(xì)化。2)類的關(guān)系——關(guān)聯(lián)

間具有細(xì)化關(guān)系。細(xì)化用來(lái)協(xié)調(diào)不同階段模型之間的關(guān)系。

構(gòu)件圖由構(gòu)件、接口及構(gòu)件之間的關(guān)系組成。構(gòu)件圖主要用于系統(tǒng)的靜態(tài)實(shí)現(xiàn)視圖模型，通過(guò)構(gòu)件的依賴關(guān)系描述系統(tǒng)軟件的組織結(jié)構(gòu)，展示系統(tǒng)不同物理構(gòu)件及其關(guān)系。

系統(tǒng)業(yè)務(wù)模型：業(yè)務(wù)過(guò)程和文檔。系統(tǒng)開(kāi)發(fā)管理模型：開(kāi)發(fā)期間產(chǎn)物及關(guān)系 系統(tǒng)實(shí)現(xiàn)模型：系統(tǒng)實(shí)現(xiàn)的構(gòu)件建模

第六章 從需求到設(shè)計(jì) 包圖（package diagram）概念性的模型管理工具，用于將大型的軟件系統(tǒng)中大量的建模元素有序的組織起來(lái)。

運(yùn)用包可以把語(yǔ)義上相近的可能一起變更的模型元素組織在同一個(gè)包中，對(duì)包中的元素作為一個(gè)整體對(duì)待，并 2)類的關(guān)系——聚集

聚集也稱為聚合，是關(guān)聯(lián)的特例。聚集表示類與類之間的關(guān)系是整體與部分的關(guān)系。

（1.共享聚集 聚合：聚集關(guān)系中處于部分方的對(duì)象可同時(shí)參與多個(gè)處于整體方對(duì)象的構(gòu)成.（2.組合聚集.組合：部分類完全隸屬于整體類.部分與整體共存.整體不存在部分也隨之消失。2)類的關(guān)系——泛化 uml中的泛化關(guān)系就是通常所說(shuō)的繼承關(guān)系（或一般與特殊關(guān)系）。2)類的關(guān)系——依賴

兩個(gè)類之間有依賴，表明其中一個(gè)類.客戶類.依賴于另一個(gè)類（供應(yīng)類）所提供的某些服務(wù)。2)類的關(guān)系——細(xì)化

當(dāng)對(duì)同一個(gè)事物在不同抽象層次上描述時(shí)，這些描述之

系統(tǒng)物理配置模型：數(shù)據(jù)文件、日志、安裝/卸載等文件且控制它們的可視性和存取。包擁有內(nèi)容，包括類、接構(gòu)件建模 口、組件、節(jié)點(diǎn)、協(xié)同。use case、圖，甚至其它包。集成系統(tǒng)模型：對(duì)api建模，幫助利用已有組件。第三章 unified process(1)構(gòu)件: 系統(tǒng)中遵從并實(shí)現(xiàn)一組接口的物理的、可替換up的構(gòu)成：二維的面向?qū)ο箝_(kāi)發(fā)模型，兼顧技術(shù)和管理。的軟件模塊。構(gòu)件是軟件復(fù)用的基本物理實(shí)現(xiàn)單元，是工作流:過(guò)程工作流(業(yè)務(wù)建模+需求+分析與設(shè)計(jì)+實(shí)施+邏輯元素模型（類、接口、協(xié)同等）的物理包

測(cè)試+部署)和3個(gè)支持工作流（配置和變更管理+項(xiàng)目管理+環(huán)境）4個(gè)階段：初始＋細(xì)化＋構(gòu)造＋交付 up的迭代策略。

up的迭代開(kāi)發(fā)策略:以體系結(jié)構(gòu)為中心，以質(zhì)量管理和

風(fēng)險(xiǎn)控制為目標(biāo)，以用例為驅(qū)動(dòng)，采用迭代式以螺旋上

升的模式進(jìn)行軟件開(kāi)發(fā)。(2)構(gòu)件的接口:一個(gè)構(gòu)件可以定義對(duì)其他構(gòu)件可見(jiàn)的接第四章 初始階段(inception)口。構(gòu)件間依賴通過(guò)指向所使用的構(gòu)件接口來(lái)表示。接1.初始階段的目標(biāo)和任務(wù)：

口描述一個(gè)構(gòu)件能提供服務(wù)的操作，是一個(gè)有操作而無(wú)做適當(dāng)?shù)恼{(diào)研，以形成對(duì)新系統(tǒng)的整體目的和可實(shí)現(xiàn)的類。包括輸入和輸出接口。

行性形成一個(gè)合理的意見(jiàn)。

建立項(xiàng)目的軟件范圍和邊界條件，包括一個(gè)操作“前景”，“接受準(zhǔn)則”和產(chǎn)品中包含什么，不包含什么? 確定核心的用例，這是系統(tǒng)運(yùn)行的主要場(chǎng)景，它將決定系統(tǒng)設(shè)計(jì)的方案

針對(duì)主要的場(chǎng)景，確定或者演示至少一個(gè)備選的系統(tǒng)結(jié)9 部署圖（deployment diagram）

構(gòu)

由節(jié)點(diǎn)和節(jié)點(diǎn)之間的聯(lián)系組成，描述了處理器、設(shè)備和對(duì)整個(gè)項(xiàng)目估計(jì)總成本和計(jì)劃(更詳細(xì)的估計(jì)將安排在軟件構(gòu)件運(yùn)行時(shí)的體系結(jié)構(gòu)。

細(xì)化階段中)估計(jì)可能的風(fēng)險(xiǎn)(不可預(yù)計(jì)性的來(lái)源）為項(xiàng)目準(zhǔn)備支持環(huán)境 2.初始階段的制品： 用例模型＋用例描述，詞匯表，補(bǔ)充性規(guī)格說(shuō)明，前景，業(yè)務(wù)規(guī)則 9 部署圖——結(jié)點(diǎn) 3.用例描述

節(jié)點(diǎn)是存在于運(yùn)行時(shí)的代表計(jì)算資源的物理元素，可摘要：簡(jiǎn)介描述用例，通常只給出主成功場(chǎng)景。以代表一種物理硬件設(shè)備或軟件元素。非正式：用若干非正式段落來(lái)描述用例，通常給出多個(gè)包含：處理器和設(shè)備兩種類型 不同場(chǎng)景。

詳述：詳細(xì)描述用例，通常給出所有的步驟及場(chǎng)景，并10 部署圖——結(jié)點(diǎn)間聯(lián)系

給出前置和后置條件等細(xì)節(jié) 節(jié)點(diǎn)間通過(guò)物理連接發(fā)生聯(lián)系，以從硬件方面保證注意：用例描述的方法 系統(tǒng)各節(jié)點(diǎn)之間的協(xié)同運(yùn)行。包括通訊關(guān)聯(lián)、依賴聯(lián)系4.用例的獲取過(guò)程

等。(1)選擇系統(tǒng)邊界(2)尋找參與者(3)確定每個(gè)參與者的目標(biāo)(4)定義用例 5.用例的定義:一般為每一個(gè)用戶目標(biāo)定義用例

確定用例的經(jīng)驗(yàn)方法：

(1)老板測(cè)試：必須看到可量化的價(jià)值(2)ebp：能夠增加可量化的業(yè)務(wù)價(jià)值，并且以持久狀態(tài)留下數(shù)據(jù)(3)規(guī)模測(cè)試： 6.rup與用例

(1)意義：記錄功能需求；迭代計(jì)劃的重要部分，預(yù)算的關(guān)鍵輸入；實(shí)現(xiàn)驅(qū)動(dòng)設(shè)計(jì)；影響用戶手冊(cè)和測(cè)試(2)初始階段：確定系統(tǒng)目標(biāo)、范圍、涉眾；絕大部分摘要描述、10～20％詳述；確定是否繼續(xù)開(kāi)發(fā)(3)細(xì)化階段：80～90％被細(xì)化描述；分多次迭代(4)構(gòu)造階段：多次時(shí)間定量迭代；補(bǔ)充次要用例 第五章 細(xì)化階段(elaboration)1.細(xì)化階段的目標(biāo)和任務(wù): 8.系統(tǒng)順序圖

表述系統(tǒng)是什么，而不解釋它是如何做的，將系統(tǒng)作為黑盒子 系統(tǒng)順序圖

它展示了對(duì)一個(gè)特定的用例，外部的參與者產(chǎn)生的事件，它們的順序以及系統(tǒng)內(nèi)的事件

協(xié)作與耦合從較高層到較低層進(jìn)行，避免從較低層到較高層的耦合第七章 模式與對(duì)象設(shè)計(jì) 1 職責(zé)和職責(zé)驅(qū)動(dòng)設(shè)計(jì) 類的契約和責(zé)任，分為：行為職責(zé)和認(rèn)知職責(zé)。在對(duì)象設(shè)計(jì)中，職責(zé)被分配給對(duì)象，稱為rdd。2 設(shè)計(jì)模式

設(shè)計(jì)模式：對(duì)被用來(lái)在特定場(chǎng)景下解決一般設(shè)計(jì)問(wèn)題的類和相互通信的對(duì)象的描述。即，對(duì)特定問(wèn)題的描述或解決方案。

目的: 易于理解，維護(hù)，擴(kuò)展和重用 3 grasp模式 控制器（controller），創(chuàng)建者（creator），信息專家 構(gòu)建核心體系架構(gòu)，解決高風(fēng)險(xiǎn)問(wèn)題，完成絕大部分需求的定義，并估計(jì)并估計(jì)總體計(jì)劃和資源，保證架構(gòu)，需求和計(jì)劃足夠穩(wěn)定，風(fēng)險(xiǎn)被充分規(guī)避，確定和解決項(xiàng)目中所有與架構(gòu)密切相關(guān)的風(fēng)險(xiǎn)，從與架構(gòu)密切相關(guān)的場(chǎng)景中確定一個(gè)基準(zhǔn)體系架構(gòu)，產(chǎn)生一個(gè)達(dá)到產(chǎn)品級(jí)質(zhì)量水準(zhǔn)的演化性原型，也可以是一個(gè)或更多個(gè)探索型拋棄型原型，能夠展示基準(zhǔn)的體系架構(gòu)以合理的價(jià)格和合適的時(shí)間支持系統(tǒng)需求，建立一個(gè)支持環(huán)境 2.核心活動(dòng): 盡快定義和驗(yàn)證體系架構(gòu)，并確定體系架構(gòu)基線 細(xì)化設(shè)想（vision）為構(gòu)造階段建立詳細(xì)的迭代計(jì)劃并建立基線 細(xì)化開(kāi)發(fā)用例并將其部署到開(kāi)發(fā)環(huán)境中 細(xì)化體系架構(gòu)并選擇組件 3.關(guān)鍵思想和實(shí)踐

實(shí)行短時(shí)間定量、風(fēng)險(xiǎn)驅(qū)動(dòng)的迭代，及早開(kāi)始編程，對(duì)架構(gòu)核心和風(fēng)險(xiǎn)部分進(jìn)行適應(yīng)性設(shè)計(jì)，實(shí)現(xiàn)和測(cè)試，盡早，頻繁，實(shí)際的測(cè)試，基于來(lái)自測(cè)試，用戶，開(kāi)發(fā)者的反饋進(jìn)行調(diào)整，通過(guò)一系列討論會(huì)，詳細(xì)編寫大部分用例和其他需求，每個(gè)細(xì)化迭代舉行一次 4.制定迭代計(jì)劃: 通過(guò)風(fēng)險(xiǎn)、覆蓋范圍和關(guān)鍵程度組織需求和迭代。

風(fēng)險(xiǎn)：技術(shù)復(fù)雜性；其他因素

覆蓋性：在早期迭代中，系統(tǒng)中主要的部分都有所涉及 關(guān)鍵性：具有高業(yè)務(wù)價(jià)值的功能

在每個(gè)迭代前將用例和特征進(jìn)行排序 迭代單位：(1)用例；(2)場(chǎng)景 5.細(xì)化階段的制品: 領(lǐng)域模型，設(shè)計(jì)模型，軟件架構(gòu)文檔，數(shù)據(jù)模型，用例示意板，用戶界面模型 6.領(lǐng)域模型(domain model)領(lǐng)域模型是對(duì)真實(shí)世界中概念類的表示，而不是軟件對(duì)象的表示。它不是用來(lái)描述軟件類、軟件架構(gòu)領(lǐng)域?qū)踊蛴新氊?zé)軟件對(duì)象的一組圖。

領(lǐng)域模型用一套類圖表示，但類沒(méi)有操作。領(lǐng)域模型可以顯示：領(lǐng)域?qū)ο蠡蛘吒拍铑?；概念類之間的關(guān)聯(lián)；概念類的屬性

概念類來(lái)源：現(xiàn)實(shí)（組織、地點(diǎn)、設(shè)備等）對(duì)象；業(yè)務(wù)（業(yè)務(wù)實(shí)體和概念）對(duì)象；過(guò)程（需要記錄的時(shí)間）對(duì)象。9.操作契約

通過(guò)領(lǐng)域模型中的對(duì)象的狀態(tài)變換(實(shí)例創(chuàng)建或刪除;屬性修改;關(guān)聯(lián)形成或者打破)，定義了系統(tǒng)操作執(zhí)行后的詳細(xì)的系統(tǒng)行為.契約co2: enteritem 操作 : enteritem(itemid: itemid, quantity: integer)前提（preconditions）: there is a sale underway 后置條件（postconditions）: 一個(gè)saleslineitem的實(shí)例sli被創(chuàng)建；sli與當(dāng)前的 sale 對(duì)象相關(guān)聯(lián)；sli.quantity的數(shù)值被賦值，依據(jù)itemid的匹配，sli 與productspecification相關(guān)聯(lián) 第六章 從需求到設(shè)計(jì) 1.軟件的邏輯體系結(jié)構(gòu)

邏輯架構(gòu)（logical architecture）是軟件類的宏觀組織結(jié)構(gòu)，它將軟件類組織成包（命名空間），子系統(tǒng)和層等。

層（layer）：對(duì)類、包或子系統(tǒng)的粗粒度的分組，具有對(duì)系統(tǒng)主要方面加以內(nèi)聚的職責(zé)。較高的層可以調(diào)用較低的層。常見(jiàn)的層：

用戶界，應(yīng)用邏輯和領(lǐng)域?qū)ο?，技術(shù)服務(wù) 典型的分層模式 2.軟件架構(gòu)

架構(gòu)是一組重要決策，其中涉及軟件系統(tǒng)的組織，對(duì)結(jié)構(gòu)元素及其組成系統(tǒng)的接口的選擇，這些元素特定于其相互協(xié)作的行為，這些結(jié)構(gòu)和行為元素到規(guī)模更大的子系統(tǒng)的組成，以及指導(dǎo)該組織結(jié)構(gòu)的架構(gòu)風(fēng)格。3.分層設(shè)計(jì)模式（模型-視圖分離, 如mvc架構(gòu)）系統(tǒng)的大型邏輯結(jié)構(gòu)組織為獨(dú)立的，職責(zé)相關(guān)的離散層，具有清晰內(nèi)聚的關(guān)注分離。較低的層是低級(jí)別和一般性服務(wù)，較高的層則是與應(yīng)用相關(guān)。（information expert），高度內(nèi)聚（high cohesion），低耦合（low coupling）4 命令——查詢分類原則

執(zhí)行動(dòng)作（更新、調(diào)整）的命令方法，這種方法通常具有改變對(duì)象狀態(tài)等副作用，并且是 void 的（沒(méi)有返回值）。向調(diào)用者返回?cái)?shù)據(jù)的查詢，這種方法沒(méi)有副作用，不會(huì)永久性的改變?nèi)魏螌?duì)象的狀態(tài)。一個(gè)方法不應(yīng)該同時(shí)屬于以上兩種類型。

第二篇：UML實(shí)驗(yàn)心得體會(huì)

uml實(shí)驗(yàn)報(bào)告

學(xué)院

班級(jí) 學(xué)號(hào) 姓名

uml實(shí)驗(yàn)報(bào)告

實(shí)驗(yàn)一：用例圖

實(shí)驗(yàn)結(jié)果：

小結(jié)實(shí)驗(yàn)心得體會(huì)：

用例模型用于需求分析階段，它描述了待開(kāi)發(fā)系統(tǒng)的功能需求，并驅(qū)動(dòng)了需求分析之后各階段的開(kāi)發(fā)工作。用例圖是uml中用來(lái)對(duì)系統(tǒng)的動(dòng)態(tài)方面進(jìn)行建模的7種圖之一。用例圖描述了用例、參與者以及它們之間的關(guān)系。用例圖從用戶角度描述系統(tǒng)功能，并指出各功能的操作者。通過(guò)本次實(shí)驗(yàn)，我熟悉rational rose建模環(huán)境，更加清楚的了解了用例圖的語(yǔ)義和功能，如何清晰明了的識(shí)別參與者、用例，學(xué)會(huì)了如何使用事件流描述用例。同時(shí)掌握了用例間的類屬關(guān)系、include關(guān)系和extend關(guān)系的語(yǔ)義、功能和應(yīng)用。最后通過(guò)本次實(shí)驗(yàn)學(xué)習(xí)了如何使用用例圖為系統(tǒng)的上下文以及系統(tǒng)的需求建模。

思考題：

1.如果要?jiǎng)h除參與者、用例，請(qǐng)問(wèn)是在導(dǎo)航窗口刪除，還是在繪圖窗口刪除？

答：都可以刪除，但在繪圖窗口中有兩種刪除方式：一種是只刪除參與者、用例，而不改變 其在導(dǎo)航窗口中的存在，另一種是從建模中完全刪除。

2.如果要?jiǎng)h除參與者和用例的聯(lián)系，用例和用例的聯(lián)系，請(qǐng)問(wèn)是在繪圖中刪除，還是 在參與者或用例的設(shè)置對(duì)話框中刪除？

答：都可以刪除。

實(shí)驗(yàn)二：類對(duì)象模型的建立

實(shí)驗(yàn)結(jié)果：

小結(jié)實(shí)驗(yàn)心得體會(huì)：

類圖是面向?qū)ο笙到y(tǒng)建模最常用的圖，描述了類圖、接口集、協(xié)作以及它們之間的關(guān)系。類圖描述了系統(tǒng)的靜態(tài)設(shè)計(jì)視，該視主要體現(xiàn)系統(tǒng)的功能需求，即系統(tǒng)應(yīng)該提供給用戶的服

務(wù)。通過(guò)本次實(shí)驗(yàn)，加深了我對(duì)類圖語(yǔ)義的理解和功能的應(yīng)用，掌握了類之間的聯(lián)系，關(guān)聯(lián)、依賴、聚合等，同時(shí)基本掌握了在rational rose中繪制類的關(guān)聯(lián)、依賴、泛化關(guān)系。

思考題：選中一個(gè)模型對(duì)象，點(diǎn)擊鼠標(biāo)右鍵，比較快捷菜單項(xiàng)“edit——delete”與“edit——delete from model”，它們二者之間區(qū)別在哪里？

答：“edit——delete”只是在繪圖窗口中刪除了模型對(duì)象，而“edit——delete from model”則是徹底的刪除了模型對(duì)象。

實(shí)驗(yàn)三：順序圖、協(xié)作圖

實(shí)驗(yàn)結(jié)果：

順序圖：

1.歸還圖書(shū)

2.借出圖書(shū)

協(xié)作圖：

1.歸還圖書(shū)

2.借出圖書(shū)

小結(jié)實(shí)驗(yàn)心得體會(huì)：

順序圖描述了對(duì)象之間的動(dòng)態(tài)合作關(guān)系，它強(qiáng)調(diào)對(duì)象之間消息發(fā)送的時(shí)間順序，同時(shí)顯示對(duì)象之間的交互。協(xié)作圖與順序圖是同構(gòu)的，rose可自動(dòng)轉(zhuǎn)換。順序圖是強(qiáng)調(diào)消息的交互作用圖，協(xié)作圖描述了對(duì)象間的關(guān)系，是強(qiáng)調(diào)發(fā)送和接收消息的對(duì)象的組織結(jié)構(gòu)的交互作用圖。通過(guò)本次實(shí)驗(yàn)，掌握了對(duì)圖書(shū)管理功能中的借書(shū)用例、還書(shū)用例進(jìn)行動(dòng)態(tài)建模。實(shí)驗(yàn)過(guò)程中由于對(duì)rational rose工具軟件的不熟識(shí)，導(dǎo)致出現(xiàn)了不該出現(xiàn)的錯(cuò)誤。在設(shè)計(jì)階段，順序圖中需要引入邊界類和控制類，在識(shí)別對(duì)象職責(zé)的基礎(chǔ)上，需要將消息轉(zhuǎn)換為類的方法，為方法定義參數(shù)、返回值類型，便于計(jì)算機(jī)的實(shí)現(xiàn)。其中，為方法定義參數(shù)、返回值類型的時(shí)候，還是不能夠快速準(zhǔn)確的作出判斷。

實(shí)驗(yàn)四：活動(dòng)圖

實(shí)驗(yàn)結(jié)果：

篇二：uml實(shí)驗(yàn)總結(jié)

實(shí)驗(yàn)一

1．源代碼生成，在邏輯視圖中繪制下圖，生成java源文件 生成代碼步驟：

“tools”-〉“java”-〉“genenate codes”。

public class meeting { private string username;private string scheduled_user;private date start_time;private date end_time;private string label;public string getuser(){ return null;} public string getother(){ return null;} public date getstart(){ return null;} public date getend(){ return null;} public string getlabel(){ return null;} public string tostring(){ return null;} public void main(string args){ return null;} } 2．進(jìn)行逆向工程，自行找到一個(gè)項(xiàng)目軟件源代碼，進(jìn)行逆向工程。（ftp上有一個(gè)小源程序文件）

逆向工程的實(shí)現(xiàn)

“tools”->“java”-〉“reverse engineer java?”。public class student { private string name;public student(){ } public void test(){ } } 實(shí)驗(yàn)二

根據(jù)下屬需求，分析參與者和用例，并建立網(wǎng)絡(luò)教學(xué)系統(tǒng)的用例圖。網(wǎng)絡(luò)教學(xué)系統(tǒng)的功能需求主要包括以下幾個(gè)方面： ① 學(xué)生可以登錄網(wǎng)站瀏覽信息、查找信息和下載文件。②

教師可以登錄網(wǎng)站輸入課程簡(jiǎn)介、上傳課件文件、發(fā)布消息、修改和更新消息。③ 系統(tǒng)管理員可以對(duì)頁(yè)面維護(hù)以及批準(zhǔn)用戶的注冊(cè)申請(qǐng)。

錄入課程簡(jiǎn)介

下載文件 查找信息

修改消息

注冊(cè)信息處理

實(shí)驗(yàn)三

1、已知借書(shū)的活動(dòng)圖如圖3所示，若要求欠費(fèi)的讀者需結(jié)清欠款才能借書(shū)，請(qǐng)完善該活動(dòng)圖，并在rose內(nèi)繪制出來(lái)。

圖3 借書(shū)處理活動(dòng)圖

2、圖4為圖書(shū)“借書(shū)”活動(dòng)圖，文字描述此活動(dòng)圖包括哪些活動(dòng)，活動(dòng)按照怎樣的順序發(fā)生？

圖4 “借書(shū)處理”活動(dòng)圖

（1）讀者查找所需的圖書(shū)，若找到圖書(shū)，將所需的圖書(shū)帶到借閱臺(tái)；（2）工作人員輸入讀者信息，檢查讀者身份是否合法，如果讀者身份合法，進(jìn)入（3）；

（3）錄入圖書(shū)信息，并檢查圖書(shū)是否允許借閱，如果允許，則記錄借閱信

息，否則直接進(jìn)入（4）；

（4）檢查是否還有圖書(shū)需要錄入，如果還需錄入，進(jìn)入（3），否則提借閱信息。

3、繪制“刪除讀者信息”用例的活動(dòng)圖。刪除讀者信息一般按照以下步驟進(jìn)行：

（1）管理員在錄入界面，輸入待刪除的讀者名；

（2）“業(yè)務(wù)邏輯”組件在數(shù)據(jù)庫(kù)中，查找待刪除的讀者名；

（3）如果不存在，則顯示出錯(cuò)信息，返回步驟（1），如果存在則繼續(xù)；（4）“業(yè)務(wù)邏輯”組件判斷“待刪除的讀者”是否可以刪除；

（5）如果不可以，則顯示出錯(cuò)信息，返回步驟（8），如果可以則繼續(xù)；（6）在數(shù)據(jù)庫(kù)中，刪除相關(guān)信息；（7）顯示刪除成功信息；（8）結(jié)束。

篇三：uml實(shí)訓(xùn)總結(jié)

實(shí)訓(xùn)總結(jié)（收獲與體會(huì)）

通過(guò)一個(gè)學(xué)期的uml學(xué)習(xí)，我從書(shū)本上獲取了基本的理論知識(shí)，而真正的學(xué)以致用，將書(shū)本理論知識(shí)運(yùn)用到實(shí)際的過(guò)程，是這次uml實(shí)訓(xùn)的體現(xiàn)。

三個(gè)周的uml實(shí)訓(xùn)，主要是圍繞著一個(gè)實(shí)訓(xùn)題目“基于uml系統(tǒng)需求分析與設(shè)計(jì)--合倍利業(yè)務(wù)流管理系統(tǒng)”進(jìn)行的，以小組為單位進(jìn)行文檔的編寫，其中還對(duì)各種流程圖、類圖、用例圖等的繪制，整個(gè)過(guò)程設(shè)計(jì)了知識(shí)的方方面面。從中讓我認(rèn)識(shí)到uml的作用和運(yùn)作模式以及方法，它是一種統(tǒng)一建模的標(biāo)準(zhǔn)語(yǔ)言，現(xiàn)在對(duì)于大多數(shù)軟件開(kāi)發(fā)來(lái)說(shuō)，都使用uml作為建模語(yǔ)言，形成了統(tǒng)一的標(biāo)準(zhǔn)。它是圖形化的的語(yǔ)言，可以很直觀的描述一個(gè)事物的狀態(tài)、行為與特征，很好的說(shuō)明與表達(dá)了“合貝利任務(wù)管理”這個(gè)系統(tǒng)。

總之，在我看來(lái)，uml是一種定義良好、易于表達(dá)、功能強(qiáng)大且普遍適用建模語(yǔ)言。融入軟件工程領(lǐng)域的心思想、新方法和新技術(shù)，作用域不限于支持面向?qū)ο蟮姆治龊驮O(shè)計(jì)，也不單純是一種方法，僅僅是一組符號(hào)而已，它可以對(duì)任何具有靜態(tài)機(jī)構(gòu)和動(dòng)態(tài)行為的系統(tǒng)進(jìn)行建模，所以我很喜歡適用uml，在今后的學(xué)習(xí)中，我還會(huì)進(jìn)一步對(duì)該模型的學(xué)習(xí)，因?yàn)樗奖?、?jiǎn)潔、干凈、清爽，直觀形象，把整個(gè)軟件系統(tǒng)的開(kāi)發(fā)流程都融入進(jìn)去。

這次實(shí)訓(xùn)過(guò)程中，文檔方面的編寫，遇到了很多的問(wèn)題，這些問(wèn)題主要是對(duì)基礎(chǔ)知識(shí)的理解和把握不夠，不能融會(huì)貫通和學(xué)以致用，有時(shí)遇到困難的時(shí)候真的不知如何著手解決，但是，我始終相信的那句話“讀萬(wàn)卷書(shū)，不如行萬(wàn)里路，行萬(wàn)里路不如名師指路”。所以，當(dāng)遇到自己模糊和自己難以解決的問(wèn)題時(shí)，向指導(dǎo)老師和懂的同學(xué)請(qǐng)教，幫助解決我遇到的問(wèn)題，經(jīng)過(guò)他們的講解后，我下來(lái)自己在分析，在動(dòng)手，從不理解到理解，從不會(huì)到會(huì)，從懂到懂，這是一個(gè)讓我學(xué)習(xí)愉快的過(guò)程，在這個(gè)過(guò)程中，既可以豐富了自己的知識(shí)，還可以和老師和同學(xué)進(jìn)行有效地方溝通。

在這次實(shí)訓(xùn)過(guò)程中，感觸最深的也就是合作精神了。獨(dú)木難成林，單槍匹馬，那是最錯(cuò)誤的思想和做法。這次我是深有感觸了。對(duì)于一個(gè)系統(tǒng)的分析，到最終項(xiàng)目的完成，需要分析每個(gè)文檔，然后在寫出紙質(zhì)的文檔，而在每個(gè)文檔中，內(nèi)容比較多，分析也要求比較到位，所以單獨(dú)憑借一個(gè)人去完成，似乎有點(diǎn)困難，于是我們小組，將每個(gè)文檔進(jìn)行分析，能獨(dú)立成塊就分配給每一個(gè)人，這樣，每個(gè)人都有自己的任務(wù)，誰(shuí)也不會(huì)閑著，既學(xué)到了知識(shí)，也充實(shí)了自己。另外一點(diǎn)，就是我深深體會(huì)到了積累知識(shí)的重要性。在實(shí)訓(xùn)當(dāng)中我們遇到了不少難題，但是經(jīng)過(guò)我們大家的討論和老師細(xì)心的一一指導(dǎo)，問(wèn)題得到了解決。兩個(gè)月的實(shí)訓(xùn)結(jié)束了，收獲頗豐，同時(shí)也更深刻的認(rèn)識(shí)到要做一個(gè)合格的程序員并非我以前想像的那么容易，最重要的還是細(xì)致嚴(yán)謹(jǐn)。社會(huì)是不會(huì)要一個(gè)一無(wú)是處的人的，所以我們要更多更快地從一個(gè)學(xué)生向工作者轉(zhuǎn)變，總的來(lái)說(shuō)我對(duì)這次實(shí)習(xí)還是比較滿意的，它使我學(xué)到了很多東西，為我以后的學(xué)習(xí)做了引導(dǎo)，點(diǎn)明了方向。

實(shí)訓(xùn)的日子即將結(jié)束，回想這一個(gè)過(guò)程，有過(guò)痛苦，有過(guò)煩惱，有過(guò)喜悅和有過(guò)成功。痛苦煩惱的是自己對(duì)所學(xué)書(shū)本知識(shí)掌握得不是很扎實(shí)，面對(duì)著從書(shū)本上學(xué)到的知識(shí)與實(shí)際聯(lián)系不起來(lái)，總結(jié)起來(lái)就是自己的動(dòng)手練習(xí)的時(shí)間太少。而喜悅的是，在做的過(guò)程中遇到了困難和問(wèn)題，主動(dòng)向老師和會(huì)的同學(xué)請(qǐng)教，然后再做，直至做正確做成功后的那種喜悅。

團(tuán)隊(duì)的力量是無(wú)窮的，通過(guò)組員的共同努力，完成了實(shí)訓(xùn)項(xiàng)目。雖然，我們這組的項(xiàng)目存在著諸多的不足和缺點(diǎn)，但這正是以后學(xué)習(xí)和工作需要彌補(bǔ)的。這次實(shí)訓(xùn)將為我以后進(jìn)入社會(huì)提過(guò)了一筆寶貴的財(cái)富，是對(duì)我能力的一個(gè)見(jiàn)證。最后，不得不感謝指導(dǎo)教師熊飛老師的辛勤指導(dǎo)，和小組成員的共同努力！篇四：uml實(shí)驗(yàn)報(bào)告

學(xué) 生 實(shí) 驗(yàn) 報(bào) 告 書(shū)

實(shí)驗(yàn)課程名稱

uml建模技術(shù)

開(kāi) 課 學(xué) 院

指導(dǎo)老師姓名

學(xué) 生 姓 名

學(xué)生專業(yè)班級(jí)

2009 — 2010學(xué)年 第 一 學(xué)期

實(shí)驗(yàn)課程名稱： uml建模技術(shù)

實(shí)驗(yàn)課程名稱：

uml建模技術(shù)

篇五：uml實(shí)驗(yàn)——狀態(tài)圖 實(shí)驗(yàn)報(bào)告

南京信息工程大學(xué)實(shí)驗(yàn)(實(shí)習(xí))報(bào)告

實(shí)驗(yàn)名稱 狀態(tài)圖 實(shí)驗(yàn)(實(shí)習(xí))日期 2014.04.26 得分 指導(dǎo)老師

系專業(yè) 班級(jí)

一、實(shí)驗(yàn)?zāi)康?/p>

1．熟悉活動(dòng)圖的基本功能和使用方法。

2．掌握如何使用建模工具繪制活動(dòng)圖方法。

二、實(shí)驗(yàn)器材

1．計(jì)算機(jī)一臺(tái)。

2．rational rose 工具軟件。

三、實(shí)驗(yàn)內(nèi)容

通過(guò)前面內(nèi)容的學(xué)習(xí)，完成了對(duì)圖書(shū)館的圖書(shū)館管理系統(tǒng)的需求的初步分析，得出系統(tǒng)的用例圖和相應(yīng)的活動(dòng)態(tài)。通過(guò)這兩類圖我們可以初步了解系統(tǒng)的業(yè)務(wù)處理過(guò)程，但對(duì)業(yè)務(wù)處理過(guò)程的處理狀態(tài)間轉(zhuǎn)換了解仍不夠，這不利于設(shè)計(jì)人員對(duì)系統(tǒng)業(yè)務(wù)的進(jìn)一步理解，而狀態(tài)圖能從對(duì)象的動(dòng)態(tài)行為的角度去描述系統(tǒng)的業(yè)務(wù)活動(dòng)。因此，指派你運(yùn)用本節(jié)所學(xué)的狀態(tài)圖，完成如下任務(wù)：

1.完成圖書(shū)業(yè)務(wù)模塊中還書(shū)用例的狀態(tài)圖。

四、實(shí)驗(yàn)步驟 1．業(yè)務(wù)分析：由前面章節(jié)對(duì)圖書(shū)館管理系統(tǒng)中的還書(shū)主要業(yè)務(wù)的描述和分析可知，還書(shū)業(yè)務(wù)的動(dòng)態(tài)行為是由：空閑（idle）、圖書(shū)查找（finding）、還書(shū)（reversion）、失?。╢ailure）、歸還成功（success）5種狀態(tài)及激活相互轉(zhuǎn)換的事件。

2．繪制狀態(tài)圖：請(qǐng)您根據(jù)分析運(yùn)用uml繪制還書(shū)用例的狀態(tài)圖。

分析：

還書(shū)的狀態(tài)圖，還書(shū)的主要業(yè)務(wù)都是由管理員來(lái)完成，首先管理員必須先登錄系統(tǒng)，并通過(guò)驗(yàn)證后，便可以進(jìn)行下一步的操作，查找該書(shū)的相關(guān)信息，如存在，則進(jìn)行還書(shū)操作，如不存在該信息，則給出提示信息；

繪圖步驟：

（1）在用例圖中的還書(shū)（revesion）用例，單擊右鍵，如圖3.1所示，新建一個(gè)狀態(tài)圖，命名為revesion狀態(tài)圖。

（2）雙擊“receivesion”狀態(tài)圖，展開(kāi)后，在左邊的工具欄上選取一個(gè)實(shí)心圓點(diǎn)，此結(jié)點(diǎn)為開(kāi)始結(jié)點(diǎn)；當(dāng)還書(shū)的時(shí)候，操作者先要詢問(wèn)系統(tǒng)的狀態(tài)，如果系統(tǒng)忙，操作者則必需等待，因此，得到系統(tǒng)的兩種狀態(tài)。

（3）操作者在詢問(wèn)系統(tǒng)和狀態(tài)后，得到兩種狀態(tài)，如果系統(tǒng)忙，操作者必需要等待、結(jié)束，重返步驟（1）。

（4）如系統(tǒng)空閑，則進(jìn)行對(duì)還書(shū)的信息進(jìn)行查詢操作；查詢也有兩種結(jié)果，一是查詢得到該書(shū)的相關(guān)信息，二查詢不到該書(shū)的相關(guān)信息；則此時(shí)有兩種狀態(tài)，需要建立兩種狀態(tài)。

（5）最后，操作者進(jìn)行了操作后，系統(tǒng)會(huì)給出操作的結(jié)果給操作者；操作成功或失敗，都會(huì)有提示信息給出。整個(gè)的還書(shū)的過(guò)程便完成。

（7）根據(jù)分析設(shè)計(jì)情況，進(jìn)一步添加或細(xì)化狀態(tài)圖。

五、實(shí)驗(yàn)報(bào)告要求

1．整理實(shí)驗(yàn)結(jié)果。

2．小結(jié)實(shí)驗(yàn)心得體會(huì)。

通過(guò)本次試驗(yàn)學(xué)習(xí)到了項(xiàng)目中狀態(tài)圖的繪制，了解了他們之間的關(guān)系以及關(guān)系處理的方法，熟悉了對(duì)rational rose 工具軟件的使用，在以后做軟件項(xiàng)目設(shè)計(jì)有很大的幫助。

第三篇：UML JSP課程設(shè)計(jì)心得體會(huì)

在這次課程設(shè)計(jì)過(guò)程中，在這與代碼為伴的一個(gè)月里，我真的收獲了很多。這次軟件工程大型課程設(shè)計(jì)，既鞏固了這學(xué)期學(xué)的UML知識(shí)，又復(fù)習(xí)了關(guān)于數(shù)據(jù)庫(kù)和java的知識(shí)，更是學(xué)會(huì)了如何將所學(xué)知識(shí)運(yùn)用到實(shí)際，真正的應(yīng)用到軟件開(kāi)發(fā)、網(wǎng)站開(kāi)發(fā)中來(lái)。

這次課程設(shè)計(jì)還有一個(gè)額外收獲，就是初步學(xué)會(huì)了用JSP開(kāi)發(fā)網(wǎng)頁(yè)。雖然做出來(lái)的網(wǎng)頁(yè)不是特別美觀，有些地方還存在一些瑕疵，但是從對(duì)網(wǎng)頁(yè)編程一竅不通到能做出一個(gè)功能基本完善的簡(jiǎn)單的畢業(yè)設(shè)計(jì)選題系統(tǒng)，一步步走來(lái)，其中收獲的不僅僅是全新的知識(shí)，對(duì)于自學(xué)能力、動(dòng)手能力、合作能力甚至接受挑戰(zhàn)的勇氣方面的影響，也都是巨大的。對(duì)于我來(lái)說(shuō)，以前只接觸過(guò)用C語(yǔ)言在DOS界面下編程，用java編寫簡(jiǎn)單的桌面應(yīng)用程序，最多只是簡(jiǎn)單的連接數(shù)據(jù)庫(kù)，所以一開(kāi)始聽(tīng)說(shuō)要編網(wǎng)頁(yè)的時(shí)候，實(shí)在是缺乏信心，在編程過(guò)程中遇到一些棘手的問(wèn)題的時(shí)候，甚至一度想要逃避，可最終還是堅(jiān)持下來(lái)了。雖然這點(diǎn)小程序?qū)τ谑炀氄莆站W(wǎng)頁(yè)編程語(yǔ)言的人來(lái)說(shuō)不算什么，但對(duì)于我來(lái)說(shuō)，沒(méi)有接觸過(guò)的東西，就是一個(gè)新挑戰(zhàn)，任何語(yǔ)言的學(xué)習(xí)，在入門的時(shí)候都是最困難的?，F(xiàn)在對(duì)于網(wǎng)頁(yè)編程已經(jīng)有了一個(gè)初步的了解，對(duì)于有些概念的理解還不是很準(zhǔn)確，不過(guò)會(huì)努力在以后的學(xué)習(xí)過(guò)程中慢慢理解，在以后的編程過(guò)程中慢慢熟悉這些概念。

除了學(xué)習(xí)新語(yǔ)言的收獲外，在編程過(guò)程中對(duì)于功能的實(shí)現(xiàn)、一些異常的處理還有界面的設(shè)計(jì)，也有著很深的感觸。既然要做畢業(yè)設(shè)計(jì)選題系統(tǒng)，那么就要先考慮到用戶的功能需求，分析不同的用戶都是要通過(guò)網(wǎng)站做什么，每個(gè)用戶都有哪些權(quán)限；對(duì)于數(shù)據(jù)庫(kù)的操作來(lái)說(shuō)，是要向數(shù)據(jù)庫(kù)中插入數(shù)據(jù)，還是更新還是刪除。而且要考慮到各個(gè)方面異常的處理，比如用戶名、密碼錯(cuò)誤怎么辦，輸入的信息錯(cuò)誤怎么處理，成功更新數(shù)據(jù)庫(kù)信息后要彈出什么提示框，要轉(zhuǎn)入那個(gè)頁(yè)面等等。對(duì)于異常處理，我做的還不夠好，由于時(shí)間精力有限，有一些異常情況沒(méi)有考慮到，功能實(shí)現(xiàn)的還不夠完美，在以后的編程過(guò)程中我會(huì)在力所能及的范圍內(nèi)盡量考慮周全，既然要做程序，那就要盡量做的完善。對(duì)于界面的設(shè)計(jì)，由于時(shí)間關(guān)系，沒(méi)有采用流行的Dreamweaver，感覺(jué)有點(diǎn)遺憾，網(wǎng)頁(yè)的背景圖片都是自己手工合成的，略顯簡(jiǎn)陋了些，唯一值得欣慰的就是實(shí)現(xiàn)了我一直想要的布局效果，以后在美工方面也會(huì)努力的提高自己的能力。

另外對(duì)于實(shí)際應(yīng)用中課程之間的融合也是有了一個(gè)初步的概念。一開(kāi)始總覺(jué)得UML沒(méi)有什么實(shí)際的用處，但通過(guò)這次課程設(shè)計(jì)我發(fā)現(xiàn)，每門課程都是有它獨(dú)特的意義的，UML中畫出的類圖、順序圖、活動(dòng)圖等等都對(duì)自己編程過(guò)程有著極佳的指導(dǎo)意義，這些圖能使編程思路變得更加清晰。

總而言之，這一個(gè)月的感受可謂五味雜陳，是三言兩語(yǔ)難以說(shuō)清的，最明顯的還是感覺(jué)到自己知識(shí)的不足，對(duì)于一些東西還是缺乏一個(gè)系統(tǒng)的準(zhǔn)確的理解。java是門很有用的語(yǔ)言，考試范圍之外的東西還有很多很多；JSP讓我接觸到了全新的網(wǎng)頁(yè)編程，也讓我知道，學(xué)無(wú)止境，想要全面深入的掌握一門語(yǔ)言，還是要付出很大的努力的。

第四篇：UML實(shí)驗(yàn)報(bào)告

一：需求分析

在我國(guó)十年前ATM（自動(dòng)取款機(jī)）還是一個(gè)很新鮮的事物，現(xiàn)在在城市的大街小巷隨處可見(jiàn)。我們?cè)谌粘Ｉ钪幸步?jīng)常和ATM打交道。本章我們將以簡(jiǎn)化的ATM系統(tǒng)為例將前面幾章中學(xué)到的用例圖、類圖、順序圖、狀態(tài)圖、活動(dòng)圖及協(xié)作圖知識(shí)運(yùn)用到此例中。二：銀行ATM機(jī)系統(tǒng)UML建模設(shè)計(jì) 1.用例圖

參與者“銀行儲(chǔ)戶”和ATM機(jī)。簡(jiǎn)化后的ATM機(jī)僅有取款、存款及其余功能。其余功能不做詳細(xì)說(shuō)明。

銀行儲(chǔ)戶在ATM機(jī)上完成取款、存款及其他業(yè)務(wù)。2.類圖

整個(gè)銀行系統(tǒng)包括了帳戶庫(kù)、銀行儲(chǔ)戶庫(kù)及ATM系統(tǒng)。

許多單個(gè)的帳戶組成了帳戶庫(kù)。帳戶具有帳戶類型、帳戶號(hào)、余額三個(gè)屬性，均為private，其類型分別為char，int，double。六個(gè)操作分別為setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance為protected其余均為public。

setType設(shè)置帳戶類型，返回類型為void，參數(shù)類型為char，輸入帳戶類型。getType獲取帳戶類型，返回類型為char，無(wú)參數(shù)。

setAccountNumbe設(shè)置帳戶號(hào)，返回類型為void，參數(shù)類型為int，輸入帳戶號(hào)。getAccountNumbe獲取帳戶號(hào)，返回類型為int，無(wú)參數(shù)。

caculateBalance計(jì)算余額，返回類型為void，參數(shù)為double，第一個(gè)參數(shù)為輸入存取款數(shù)額，第二個(gè)參數(shù)為存款余額，既為輸入也為輸出。getBalance獲取帳戶余額，返回類型為double，無(wú)參數(shù)。

許多銀行儲(chǔ)戶組成了儲(chǔ)戶庫(kù)。ATM系統(tǒng)包含了許多ATM機(jī)。銀行儲(chǔ)戶及ATM機(jī)兩個(gè)類包含哪些屬性，哪些操作，它們的可見(jiàn)性及操作的返回類型、參數(shù)個(gè)數(shù)、參數(shù)類型從類圖上都一目了然。更多的屬性及操作都可以一一加上，使這個(gè)類圖更詳細(xì)更完整，從而使參與項(xiàng)目的每個(gè)成員都能無(wú)歧義的明了整個(gè)設(shè)計(jì)的類的結(jié)構(gòu)。同樣對(duì)于一個(gè)真正的銀行系統(tǒng)，這個(gè)類圖過(guò)于簡(jiǎn)單。比如帳戶類型我們可以先定義一個(gè)abstract class，它包含一個(gè)帳戶最基本的屬性及操作。而有些操作先定義為abstract，如余額的計(jì)算。然后再繼承這個(gè)abstract class，我們可以有saving account 和checking account等等。不同的帳戶有不同的余額計(jì)算方法，我們可以加上具體的算法。對(duì)于不同的帳戶可能還有一些它特有的操作，我們也可以加上，比如saving account在存款達(dá)到多少時(shí)可以享受機(jī)票打折的優(yōu)惠。通過(guò)類圖不僅可以使設(shè)計(jì)者明確的表達(dá)自己的設(shè)計(jì)意圖，也能幫組自己整理思路，充實(shí)及優(yōu)化自己的設(shè)計(jì)。

3.順序圖

描述顧客在ATM機(jī)上取款時(shí)信息的流動(dòng)情況。以時(shí)間為順序。因?yàn)槭鞘纠龍D，所以整個(gè)過(guò)程是沒(méi)有出現(xiàn)任何故障時(shí)的流程，并且只畫到了取款結(jié)束。通過(guò)這個(gè)圖，我們可以看出消息是如何在系統(tǒng)中不同對(duì)象之間進(jìn)行交互。

通過(guò)流程圖我們可以很清楚地看到系統(tǒng)是如何工作的，系統(tǒng)各部分之間的信息及控制是如何發(fā)送的，整個(gè)流程是否合理。流程圖對(duì)我們的設(shè)計(jì)起到了很好的幫助作用。注意在本圖沒(méi)有一個(gè)生命線終端有一個(gè)“X”，這是因?yàn)檫@個(gè)流程中還未遇到有對(duì)象生命結(jié)束。當(dāng)有對(duì)象生命結(jié)束時(shí)需在對(duì)應(yīng)的生命線終端畫“X”，表明這個(gè)對(duì)象在這時(shí)被銷毀。

首先銀行儲(chǔ)戶將ATM卡插入讀卡機(jī)，讀卡機(jī)將信息傳給客戶管理，客戶管理提出查詢密碼，顯示部分將輸入密碼請(qǐng)求顯示出來(lái)….銀行儲(chǔ)戶讀卡機(jī)顯示輸入設(shè)備客戶管理點(diǎn)鈔機(jī)事務(wù)管理1: 插入ATM卡2: 接受ATM卡3: 查詢密碼4: 顯示輸入密碼請(qǐng)求5: 輸入密碼6: 密碼傳遞7: 請(qǐng)求確認(rèn)密碼的合法性8: 確認(rèn)密碼的合法性9: 詢問(wèn)服務(wù)類別10: 顯示輸入服務(wù)類別請(qǐng)求11: 輸入取款請(qǐng)求12: 取消請(qǐng)求13: 詢問(wèn)取款數(shù)額14: 顯示輸入數(shù)額請(qǐng)求15: 輸入取款數(shù)額16: 傳遞取款數(shù)額17: 詢問(wèn)取款數(shù)額確認(rèn)18: 顯示確認(rèn)數(shù)額請(qǐng)求19: 輸入確認(rèn)20: 傳遞確認(rèn)信息21: 數(shù)額合法性確認(rèn)請(qǐng)求22: 確認(rèn)數(shù)額的合法性23: 計(jì)算儲(chǔ)戶余額24: 出鈔請(qǐng)求25: 出鈔26: 取鈔27: 傳遞余額并詢問(wèn)是否需要其它服務(wù)28: 顯示儲(chǔ)戶余額并顯示其它服務(wù)

第五篇：UML實(shí)驗(yàn)報(bào)告[推薦]

UML實(shí)驗(yàn)報(bào)告

班 級(jí)：軟件0841

姓 名：張文成 學(xué) 號(hào)：081842173

實(shí)驗(yàn)內(nèi)容：

用例建模、分析建模、設(shè)計(jì)建模（1）、設(shè)計(jì)建模（2）

實(shí)驗(yàn)一：用例建模

[實(shí)驗(yàn)?zāi)康腯 〃掌握客戶需求分析的方法和步驟

〃了解以用例驅(qū)動(dòng)的軟件開(kāi)發(fā)方法 〃識(shí)別并編寫用例

〃掌握用Rose 進(jìn)行用例建模的具體方法和步驟

[實(shí)驗(yàn)內(nèi)容] 要求學(xué)生根據(jù)周圍的實(shí)際情況，自選一個(gè)小型應(yīng)用項(xiàng)目，分析業(yè)務(wù)需求，識(shí)別并編寫用例、繪制用例圖以理解系統(tǒng)需求。亦可采用教師指定的“企業(yè)綜合信息管理系統(tǒng)”中的“進(jìn)銷存管理子系統(tǒng)”

[實(shí)驗(yàn)原理和步驟] 建模原理：

(1)需求獲取。以任務(wù)和客戶為中心，通過(guò)會(huì)議、面談等手段對(duì)客戶需求進(jìn)行調(diào)研，獲得系統(tǒng)目標(biāo)、范圍和功能要求的初步說(shuō)明。(2)用例分析。確定用例，同時(shí)采用分層思想，對(duì)用例的層次級(jí)別進(jìn)行劃分（高層用例、子系統(tǒng)級(jí)、用戶目標(biāo)級(jí)）

（3）用例描述。分層繪制用例圖，撰寫用例的文字描述（采用單欄格式）。

步驟：

（1）需求獲取。自選題目，與相關(guān)客戶、領(lǐng)域?qū)＜业确磸?fù)商討，獲得系統(tǒng)目標(biāo)、范圍和功能要求的初步說(shuō)明。（也可采用教師指定的題目：“企業(yè)綜合信息管理系統(tǒng)”中的“進(jìn)銷存管理子系統(tǒng)”，但要仔細(xì)研讀“企業(yè)現(xiàn)狀”、“系統(tǒng)目標(biāo)、范圍和功能要求”等文字說(shuō)明）。（2）用例分析。確定系統(tǒng)范圍和邊界、確定參與者、確定用例。（3）用例描述。分層繪制用例圖、描述用例。

畫圖原理：

采用Rose 軟件進(jìn)行用例建模必須建立在完好的系統(tǒng)用例分析基礎(chǔ)之上．只有做好系統(tǒng)用例分析，系統(tǒng)用例建模才能這到預(yù)期的效果。步驟：

（1）分層繪制用例圖，每層采用“包”進(jìn)行管理。

（2）以“企業(yè)綜合信息管理系統(tǒng)”-> “進(jìn)銷存管理”子系統(tǒng)-> “銷售管理”-> “合同管理”->“收款單處理”為主線，完成附錄2 中的操作過(guò)程（亦可選擇“企業(yè)綜合信息管理系統(tǒng)”-> “進(jìn)銷存管理”子系統(tǒng)-> “庫(kù)存管理”-> “原材料出庫(kù)”->“領(lǐng)料單處理”主線）

[ 實(shí)驗(yàn)結(jié)果]

實(shí)驗(yàn)2 分析建模

[ 實(shí)驗(yàn)?zāi)康腯(1)理解面向?qū)ο笙到y(tǒng)分析和對(duì)象類建模(概念建模)的概念(2)了解和掌握面向?qū)ο笙到y(tǒng)分析的方法和步驟(3)了解和掌握尋找待開(kāi)發(fā)系統(tǒng)中類(概念)的方法和技巧(4)掌握使用ROSE 繪制概念模型的方法

[ 實(shí)驗(yàn)內(nèi)容] 在用例分析的基礎(chǔ)上，選擇第一個(gè)迭代周期打算開(kāi)發(fā)的用例，建立相關(guān)的概念模型。

[ 實(shí)驗(yàn)原理和步驟] 建模原理：

(1)使用概念目錄列表（見(jiàn)下圖）和非正式分析法（識(shí)別出問(wèn)題域的文本描述中的名詞短語(yǔ)，然后將其作為概念或?qū)傩缘暮蜻x對(duì)象。）相結(jié)合的方法識(shí)別概念。因此，待開(kāi)發(fā)用例的文字描述中，名詞可能成為概念或?qū)傩缘暮蜻x對(duì)象；表示行為的動(dòng)詞詞組有可能成為事務(wù)型或過(guò)程型對(duì)象；形容詞詞組有可能對(duì)應(yīng)抽象的名詞型概念。

采用的技術(shù)基本上就是：ER 圖+純行為+OO 的聚合、泛化。（2）最終關(guān)聯(lián)的數(shù)量介于“需要知道”型關(guān)聯(lián)與【“需要知道”型關(guān)聯(lián)+“需要理解”型（從通用關(guān)聯(lián)列表中派生出 的，見(jiàn)下圖）】之間。

步驟：

（1）識(shí)別關(guān)鍵用例作為第一個(gè)迭代周期的開(kāi)發(fā)目標(biāo)（一般是在用例圖中被依賴得比較多的用例）?？梢赃x“企業(yè)綜合信息管理系統(tǒng)”-> “進(jìn)銷存管理”子系統(tǒng)-> “庫(kù)存管理”-> “原材料出庫(kù)”->“領(lǐng)料單處理”主線中的“領(lǐng)料單處理”用例；也可以選“企業(yè)綜合信息管理系統(tǒng)”-> “進(jìn)銷存管理”子系統(tǒng)-> “銷售管理”-> “合同管理”->“收款單處理”主線中的“增加銷售合同”或“收款單處理”用例。（其實(shí)，選“庫(kù)存管理”主線更合適；當(dāng)然，如果要實(shí)現(xiàn)產(chǎn)銷一體化，以銷售訂單指導(dǎo)生產(chǎn)和采購(gòu)，并實(shí)現(xiàn)零庫(kù)存目標(biāo)，那么一切工作就以銷售管理為中心。即便如此，首選“增加合同”用例也更為合適。）

（2）識(shí)別概念和重要屬性。

（3）建立概念間的關(guān)聯(lián)。

畫圖原理：

（1）可以采用“邏輯視圖”下的類圖描述概念模型，只不過(guò)每個(gè)類中只有類名和屬性，沒(méi)有方法。在概念建模 階段也沒(méi)有必要確定屬性的類型和訪問(wèn)屬性。

（2）概念間的關(guān)聯(lián)可以采用一般關(guān)聯(lián)（無(wú)方向?qū)嵕€），當(dāng)然，對(duì)于聚合和泛化，應(yīng)采用相應(yīng)的連線（組合：實(shí)心菱形+實(shí)線；聚合：空心菱形+實(shí)線；泛化：空三角形+實(shí)線）

步驟：

（0）前提條件：第一個(gè)迭代周期可以選“企業(yè)綜合信息管理系統(tǒng)”

-> “進(jìn)銷存管理”子系統(tǒng)-> “庫(kù)存管理”->“原材料出庫(kù)”->“領(lǐng)料單處理”主線中的“領(lǐng)料單處理”用例；也可以選“企業(yè)綜合信息管理系統(tǒng)”->“進(jìn)銷存管理”子系統(tǒng)-> “銷售管理”-> “合同管理”->“收款單處理”主線中的“增加銷售合同”或“收款單處理”用例。做好與此用例相關(guān)的概念模型

（1）建立相關(guān)的概念模型的基礎(chǔ)上，在“邏輯視圖”下的類圖中描述概念模型，可以直接在類圖main 中繪制，也可采用類似用例圖中用過(guò)的分包機(jī)制

(2）繪制概念和重要屬性。（3）繪制概念間的關(guān)聯(lián)。

[ 實(shí)驗(yàn)結(jié)果]

[ 實(shí)驗(yàn)總結(jié)] ① 對(duì)重點(diǎn)實(shí)驗(yàn)結(jié)果進(jìn)行分析；

② 實(shí)驗(yàn)中的問(wèn)題和提高：對(duì)自己的分析或設(shè)計(jì)進(jìn)行評(píng)價(jià)，指出合理和不足之處，提出改進(jìn)的方案。

③ 收獲與體會(huì)：篩選概念的要點(diǎn)；區(qū)分概念與屬性的要點(diǎn)；關(guān)聯(lián)取舍的要點(diǎn)；畫圖時(shí)如何防止關(guān)聯(lián)重名。

實(shí)驗(yàn)3 設(shè)計(jì)建模（1）

[ 實(shí)驗(yàn)日期]2011年5月20日 [ 實(shí)驗(yàn)?zāi)康腯(1)理解順序圖的基本概念

（2）了解和掌握軟件工程中用例邏輯時(shí)序的分析方法（3）掌握使用ROSE 創(chuàng)建順序圖的方法

[ 實(shí)驗(yàn)內(nèi)容] 在用例模型和概念模型的基礎(chǔ)上，對(duì)首選的用例進(jìn)行事件分解，識(shí)別出系統(tǒng)事件（系統(tǒng)操作），（并寫出契約的后置條件）；為每個(gè)系統(tǒng)事件畫順序圖，為對(duì)象分配職責(zé)。

[ 實(shí)驗(yàn)原理和步驟] 原理：

(1)在系統(tǒng)順序圖中，所有的系統(tǒng)都被當(dāng)成黑盒子看待，順序圖的重點(diǎn)是參與者發(fā)起的跨越系統(tǒng)邊界的事件。

(2)系統(tǒng)事件是由某參與者發(fā)起的指向系統(tǒng)的輸入事件。一個(gè)事件的發(fā)生能夠觸發(fā)一個(gè)響應(yīng)操作的執(zhí)行。

(3)請(qǐng)仔細(xì)研究下圖,考察它是如何從左邊的“購(gòu)買商品”用例的文字描述中分解出3 個(gè)系統(tǒng)事件的。

（4）參照用例模型和概念模型，為每個(gè)系統(tǒng)操作估計(jì)后置條件。（實(shí)例創(chuàng)建、形成關(guān)聯(lián)、屬性修改）（5）按照設(shè)計(jì)模式為對(duì)象分配職責(zé)。

步驟：

（1）分析首選用例的文字描述，按事件進(jìn)行分解，識(shí)別出系統(tǒng)事件。（下面以“企業(yè)綜合信息管理系統(tǒng)”-> “進(jìn)銷存管理”子系統(tǒng)-> “銷售管理”-> “合同管理”->“收款單處理”主線中的“收款單處理”用例為例）。

我們暫不考慮批處理。第一個(gè)核對(duì)，因?yàn)橐獙ⅰ柏浛罱痤~填寫到合同中”。后置條件顯然有“銷售合同”的屬性修改。此合同顯然已經(jīng)存在，不需要?jiǎng)?chuàng)建，但需要根據(jù)合同編號(hào)find，然后形成關(guān)聯(lián)。第二個(gè)核對(duì)需要根據(jù)合同明細(xì)到倉(cāng)庫(kù)的“存貨明細(xì)”（概念模型中還沒(méi)有）中去查。此核對(duì)發(fā)生前雖然敲了一下鍵盤，但隨后并沒(méi)有新的消息穿越系統(tǒng)邊界，因此這仍然是同一個(gè)系統(tǒng)事件。先考慮成功場(chǎng)景，應(yīng)該向庫(kù)存系統(tǒng)發(fā)提貨單（概念模型中還沒(méi)有）就結(jié)束了。后續(xù)的削減庫(kù)存（核銷）、預(yù)警顯然不是銷售管理員的職權(quán)，并且真正的核銷必須由倉(cāng)庫(kù)的發(fā)貨人執(zhí)行，才能保證貨帳一致。并且“生產(chǎn)廠家”與“郵購(gòu)公司”的運(yùn)作方式不同，后者是自己的員工取貨并郵寄，而前者還有可能是來(lái)人來(lái)車取貨，這時(shí)倉(cāng)庫(kù)收到取貨單后并不能立即自動(dòng)處理（開(kāi)發(fā)貨單），必須等取貨人到達(dá)才能處理。

根據(jù)題意，本項(xiàng)目應(yīng)該是“生產(chǎn)廠家”模式。這又存在一個(gè)問(wèn)題，如

果在開(kāi)出提貨單后不修改庫(kù)存，可能影響并發(fā)用戶和后續(xù)付款單的處理。所以有必要設(shè)計(jì)一個(gè)“臨時(shí)存貨明細(xì)”（概念模型中還沒(méi)有）（不是真實(shí)的“存貨明細(xì)”）供修改，何時(shí)按存貨明細(xì)”進(jìn)行刷新應(yīng)該是庫(kù)存管理系統(tǒng)的事（比如每天夜里刷新，但因?yàn)橛暄┨鞖?，取?人遲遲不提貨，是提貨單作廢（相當(dāng)于退回銷售系統(tǒng)，付款單變?yōu)槲刺幚恚┻€是就強(qiáng)行刷新（此時(shí)有沖突危險(xiǎn)）？）失敗場(chǎng)景。向“生產(chǎn)調(diào)度部門”發(fā)送“產(chǎn)品生產(chǎn)申請(qǐng)單”。如果是專門為此單進(jìn)行生產(chǎn)，那么還應(yīng)該有庫(kù)存系統(tǒng)發(fā)來(lái)的“產(chǎn)品入庫(kù)通知處理”用例來(lái)調(diào)用本用例進(jìn)行發(fā)貨。本題顯然一概根據(jù)付款單運(yùn)作，因此如果失敗，就不處 理付款單，但按日期把它排在待處理付款單的前面。從前面的分析來(lái)看，就一個(gè)系統(tǒng)事件，我們就命名為“付款單處理(pb:付款單)”（2）為每個(gè)系統(tǒng)事件估計(jì)后置條件。(以上已做了部分分析)（3）按設(shè)計(jì)模式進(jìn)行設(shè)計(jì)。

首先考慮控制者,領(lǐng)域控制者選參與者角色，即“銷售人員”。為了避免使用FORM,窗口等表示層對(duì)象,我們?nèi)嗽煲?個(gè)類”應(yīng)用協(xié)調(diào)者”向控制者發(fā)送消息。

[ 實(shí)驗(yàn)結(jié)果]

① 對(duì)重點(diǎn)實(shí)驗(yàn)結(jié)果進(jìn)行分析；

② 實(shí)驗(yàn)中的問(wèn)題和提高：對(duì)自己的分析或設(shè)計(jì)進(jìn)行評(píng)價(jià)，指出合理和不足之處，提出改進(jìn)的方案。

③ 收獲與體會(huì)：事件分解的要點(diǎn)；控制者選擇的要點(diǎn)；繪制順序圖的要點(diǎn)。

[ 實(shí)驗(yàn)總結(jié)] ① 對(duì)重點(diǎn)實(shí)驗(yàn)結(jié)果進(jìn)行分析；

② 實(shí)驗(yàn)中的問(wèn)題和提高：對(duì)自己的分析或設(shè)計(jì)進(jìn)行評(píng)價(jià)，指出合理和不足之處，提出改進(jìn)的方案。

③ 收獲與體會(huì)：事件分解的要點(diǎn)；控制者選擇的要點(diǎn)；繪制順序圖的要點(diǎn)。

實(shí)驗(yàn)4 設(shè)計(jì)建模（2）

[ 實(shí)驗(yàn)日期] 2011年5月27日 [ 實(shí)驗(yàn)?zāi)康腯(1)理解面向?qū)ο箢愔g關(guān)聯(lián)關(guān)系的概念(2)了解和掌握分析類之間的關(guān)聯(lián)關(guān)系的方法

(3)了解和掌握待開(kāi)發(fā)系統(tǒng)中類之間關(guān)聯(lián)關(guān)系的分析方法(4)完善設(shè)計(jì)類圖，掌握使用ROSE 對(duì)關(guān)聯(lián)進(jìn)行建模的過(guò)程

[ 實(shí)驗(yàn)內(nèi)容] 根據(jù)設(shè)計(jì)建模（1）中的交互分析，進(jìn)一步設(shè)計(jì)關(guān)聯(lián)和對(duì)象可見(jiàn)性（補(bǔ)

上遺漏的關(guān)聯(lián)）,完善設(shè)計(jì)類圖。

[ 實(shí)驗(yàn)原理和步驟] 建模原理：

（1）關(guān)聯(lián)關(guān)系描繪了給定類的對(duì)象個(gè)體之間的語(yǔ)義連接，是類與類之間的連接。關(guān)聯(lián)可以分為一般關(guān)聯(lián)、聚合關(guān) 聯(lián)、組合關(guān)聯(lián)和依賴關(guān)聯(lián)等。

（2）一般關(guān)聯(lián)包括一對(duì)類的二元關(guān)聯(lián)及多個(gè)類之間的多元關(guān)聯(lián)。

（3）聚合(Aggregation)表示整體和部分之間較強(qiáng)的關(guān)聯(lián)關(guān)系，聚合關(guān)系的多重性大于1，則稱為共享聚合。

（4）組合(Composition)關(guān)系表示整體和部分之間有比聚合關(guān)系更強(qiáng)的關(guān)系，它們之間是一對(duì)一的關(guān)系，即同生死共存亡，組合關(guān)系不能共享。

（5）依賴關(guān)系是一種使用關(guān)系，表現(xiàn)為一個(gè)對(duì)象僅僅調(diào)用了另一個(gè)對(duì)象的服務(wù)?？梢允褂孟铝械闹笇?dǎo)方針列出暫時(shí)性的關(guān)系：

(1)存在兩個(gè)或兩個(gè)以上的類相互之間就可能有關(guān)聯(lián)。(2)類的操怍(成員函數(shù))的參數(shù)列表里出現(xiàn)其他類的對(duì)象。(3)一個(gè)類包含另一個(gè)類的對(duì)象(對(duì)象成員)。(4)根據(jù)一般常識(shí)可能會(huì)出現(xiàn)的關(guān)聯(lián)。步驟：

（1）分析已建立的設(shè)計(jì)類圖和交互圖，進(jìn)一步設(shè)計(jì)關(guān)聯(lián)和

對(duì)象可見(jiàn)性（補(bǔ)上遺漏的關(guān)聯(lián)）。（下面以“企業(yè)綜合 信息管理系統(tǒng)”-> “進(jìn)銷存管理”子系統(tǒng)-> “銷售管理”-> “合同管理”->“收款單處理”主線中 的“收款單處理”用例為例）。

在銷售管理子系統(tǒng)中，定義的各個(gè)類之間一般都有關(guān)系發(fā)生。銷售人員和客戶(大客戶)共同簽署銷售合同，銷售合同中涉及到多種可以銷售的產(chǎn)品，合同經(jīng)公司經(jīng)理審查并簽字后該合同才能生效，付款單需要客戶付款，銷售人員簽發(fā)催款單向客戶催繳欠款，銷售人員制定銷售計(jì)劃，銷售人員要檢查督促執(zhí)行期合同按合同執(zhí)行、履 約，履約后的合同轉(zhuǎn)到履約合同數(shù)據(jù)庫(kù)存檔備查等等。例如：

（a）銷售人員與客戶：一般關(guān)聯(lián)，多對(duì)多

（b）銷售合同與合同明細(xì)，銷售計(jì)劃與計(jì)劃明細(xì)：組合。（c）付款單與客戶：依賴關(guān)系?！度绻犊顔晤愔杏小敖y(tǒng)計(jì)付款金額(客戶類客戶對(duì)象)”操作的話，付款 單類就依賴客戶類》（2）完善設(shè)計(jì)類圖 畫圖原理：

（1）關(guān)聯(lián)關(guān)系描繪了給定類的對(duì)象個(gè)體之間的語(yǔ)義連接，是類與類之間的連接。關(guān)聯(lián)可以分為一般關(guān)聯(lián)、聚合關(guān) 聯(lián)、組合關(guān)聯(lián)和依賴關(guān)聯(lián)等。

（2）一般關(guān)聯(lián)包括一對(duì)類的二元關(guān)聯(lián)及多個(gè)類之間的多元關(guān)聯(lián)。

（3）聚合(Aggregation)表示整體和部分之間較強(qiáng)的關(guān)聯(lián)關(guān)系，聚合關(guān)系的多重性大于1，則稱為共享聚合。

（4）組合(Composition)關(guān)系表示整體和部分之間有比聚合關(guān)系更強(qiáng)的關(guān)系，它們之間是一對(duì)一的關(guān)系，即同生死共存亡，組合關(guān)系不能共享。

（5）依賴關(guān)系是一種使用關(guān)系，表現(xiàn)為一個(gè)對(duì)象僅僅調(diào)用了另一個(gè)對(duì)象的服務(wù)。步驟：

（1）在關(guān)聯(lián)和對(duì)象可見(jiàn)性分析的基礎(chǔ)上，補(bǔ)充一般關(guān)聯(lián)、組合，泛化、依賴

（a）一般關(guān)聯(lián)關(guān)系要注意關(guān)聯(lián)的命名以及哪個(gè)是role A 哪個(gè)是role B。

(b)一般關(guān)聯(lián)選中role B detail 中的aggregate，就變成聚合；再選中by value 就變成組合。(c)依賴畫虛線箭頭。（2）完善設(shè)計(jì)類圖

[實(shí)驗(yàn)結(jié)果] ① 對(duì)重點(diǎn)實(shí)驗(yàn)結(jié)果進(jìn)行分析；

② 實(shí)驗(yàn)中的問(wèn)題和提高：對(duì)自己的分析或設(shè)計(jì)進(jìn)行評(píng)價(jià)，指出合理和不足之處，提出改進(jìn)的方案。

③ 收獲與體會(huì)：分析依賴關(guān)系的要點(diǎn)，繪制關(guān)聯(lián)的要點(diǎn)。通過(guò)實(shí)驗(yàn)了解UML的建模的步驟和方法，了解用例圖和類圖等的畫法，了解系統(tǒng)的分析和建模方法。增加動(dòng)手和思維能力，使自己更加的了解軟件系統(tǒng)前期開(kāi)發(fā)的軟件定義和分析方法。