第一篇：uml報告總結

UML課程設計總結

這幾周的課程設計，是對課本知識的總結和鞏固，使我對UML的幾種圖有了更深刻的理解，明白了這些圖分別表達的意思以及各圖的優缺點，還有它們對于程序設計的作用。熟悉了VS中建模，熟悉了VS中控件的意義，對UML有了更深刻的了解。下面是我在每一個圖的學習中的一些心得和體會

在項目設計階段，我覺得順序圖，活動圖，狀態圖比較重要。順序圖在這些圖例里比較直觀，用戶能很快參與到討論中，活動圖和傳統的流程圖類似，也是一個補充。狀態圖在對關鍵對象是一定要做狀態分析的，經常會在做分析的時候發現一些容易被忽視的問題。類圖在設計階段可以用。

深刻體會了UML在建模中關系和作用。UML可以為面向對象的開發系統進行說明，是的復雜的系統和功能，邏輯關系，類之間的關系可視化。用例圖幫助我們從宏觀上認識了學生選導師系統的軟件結構。狀態圖，時序圖，類圖幫助我們從微觀上認識了這個系統的結構和關系。

畫用例圖是我第一次使用VS建模，對VS中的一些工具還很生硬，僅僅知道跟著指導書來進行建模。但經過一定的練習，也有了一定的收獲和體會，使我了解了用例圖的組成，作用以及使用場合；掌握了用例之間的各種關系；知道了用例建模主要要了解各個圖形所代表的意義，用例還可以進行下一集的描述，進行下一步的深化。

對于建模過程中遇到的問題通過上網查資料，問同學并和他們進行討論，得到了比較滿意的解決，避免了自己眼高手低，從實踐中發現自己的不足，并及時改正。更讓我明白，UML的知識是十分豐富的，我現在的認識還不夠，我將會在以后的學習中，不斷提高自己的UML知識，更好地讓UML為將來的編程設計服務。

進一步加強和提高了文檔的編寫能力

增強了寫作能力和團隊精神

第二篇：UML復習總結

1.UML(unified modeling language): 統一建模語言是創建描繪軟件系統結構和設計藍圖的標準語言。它用于指定、構造、記錄軟件系統的工件并使之可視化。~ 的基本組成部分：包括 UML 的靜態、動態、包和注釋等部分。~ 的構建塊包含基本的成分、關系和關系圖。基本成分包括結構、行為、分組和注釋成分。

2.RUP(rational unified process): 統一開發過程是一種過程框架，有助于使用創建和部署用UML設計的軟件。~生命周期分為四個階段：起始階段、細化階段、構造階段、轉換 3.軟件開發生命周期(SDLC)是一個規范的、系統的軟件開發方法。可分為六個階段：可行性分析、需求分析和規范說明、設計、編碼、測試、維護。軟件的開發方法：瀑布方法、原型方法、螺旋方法、雙贏螺旋方法、增量方法。在設計階段，有兩種~：①面向功能方法以模塊為中心，注重軟件的功能。②面向對象（OO）方法支持重用、數據封裝、以及繼承、抽象和多態性等概念。

4.面向對象分析和設計（OOAD）是指根據對象、類、封裝、繼承、多態、抽象和動態邦定來分析需求以及設計軟件系統。

5.軟件系統的各個視圖：①用例視圖：表示系統為客戶提供的功能②設計~：側重于系統的靜態和動態表示③實施~：表示軟件系統中組成系統所需的各個文件和組件④部署~：表示將執行軟件系統和硬件的組合關系。

6.四種建模技術：①需求建模：包括使用用例關系圖描述需求。②靜態~：包括使用類、對象和復合結構關系圖來描述軟件系統的靜態成分③動態~：包括使用以下關系圖來描述動態成分的行為：活動關系圖、狀態機關系圖、通信關系圖、序列關系圖、交互概覽圖、時序關系圖④架構~： 描述軟件系統的內部結構如何構成：包關系圖、主件關系圖、部署關系圖 7.需求管理是一種持續的系統化方法。~的四個階段： 需求收集、~分析與協商、~規格化、~驗證。需求分析指將需求分類和組織為功能性需求和非功能性需求的過程。功能需求指軟件系統需要實現的功能和特性。非功能性需求指軟件系統需要達到的性能指標。需求驗證是在指定需求規范化后對需求進行驗證的活動。需求驗證包括：①確定所有的模糊需求②確定每條需求的來源③說明需求數量④確定需求之間的依賴關系⑤驗證需求是否簡明、可測試并且可跟蹤⑥驗證需求與軟件系統中的約束是否有沖突

8.軟件需求規格化（SRS）是詳細分析任務后產生的文檔。~必須提供信息：軟件系統定義、SRS文檔的用途、軟件系統的范圍、功能性需求、非功能性需求、目標軟件系統的運行條件 9.角色有關的關系：泛化~： 存在于有類似的行為和特性的角色之間繼承關系。關聯~： 顯示用例與角色之間通信關系。

10.用例關系圖：①顯示目標軟件系統的用例和角色之間的交互關系②顯示用例之間或角色之間的關系（如關聯和泛化等）。用例可以（文本方式，事件流方式）描述外部角色與軟件系統之間的交互過程。用例之間的關系：①擴展：指通過獲取其它用例的某些功能來建立當前用例的方式擴展關系的箭頭方向指向要被擴展的用例②包含：指一個用例的功能包含在另一個用例的功能中。包含關系里箭頭指向被包含在另一個用例中的用例。11.類關系圖表示類、接口、以及它們之間的關系。對象關系圖表示類的特定實例的屬性值以及對象之間的關系。類的屬性和操作的可見性是：+ :表示屬性或操作對于其它類可見。-：表示屬性或操作對其它類不可見。#：表示基類的屬性或操作僅對它的派生類可見。~:表示屬性或操作只對同一個包里的類是可見的。類和對象之間的關系：①關聯：表示兩個類的對象之間一般上的邏輯意義上的聯系。②聚合：表示兩個類之間的整體與局部的關系③組合：表示兩個類之間的整體與局部的關系④依賴性：表示兩個類的對象之間一般上的動態功能上的聯系⑤泛化：表示父類與子類之間派生關系⑥實現：表示類關系圖里兩個元素之間的語義關系，其中一個元素定義一個協議，另一個元素實現這個協議。12．抽象類是沒有任何直接實例的類，繼承于抽象類的類可以有直接實例，用于定義一組子類的公共特征和公共行為。接口是一組用于表示由類或組件提供的服務的操作集合，只能提供公共方法的聲明，而不能提供這些公共方法的實現，不可以創建接口的對象。兩者的相同處：①抽象類和接口都提供方法的規范，但是都不允許您直接創建實例。②抽象類和接口中指定的方法實現都在派生類中提供。不同處：①接口使您能實現多繼承，因為一個類可以實現多個接口。但是，抽象類不支持多繼承。一個類無法繼承多個抽象類②抽象類包含的屬性和方法可以是公共的、私有的或受保護的。接口只包含方法③抽象類可提供一部分方法的定義但接口不提供任何定義④抽象類在同一個包內使用，而接口可以跨多個包里實現。接口繼承與抽象類繼承的區別：①接口繼承可多繼承，而抽象類繼承不行②接口繼承中全是抽象方法，不提供定義，而抽象類繼承中可有方法定義。

13.交互關系圖：描述軟件系統的成分如何彼此交互以實現系統用例的功能。~有兩個部分：①協作者：描述交互關系圖中參與交換的系統靜態部分②交互：描述交互關系圖中靜態部分是怎樣參與動態協作的。常用的交互關系圖有：①序列關系圖：以一組按時間順序排序的消息的形式表示對象之間的交互②通信關系圖：以消息的形式表示對象間的交互

14.包關系圖用于描述軟件系統的各個包以及包之間的關系。使用包來建模軟件系統成分的好處有：①以可視化的方式顯示功能組以及它們之間的關系②使得大型軟件系統易于管理。用例分包規則：①以可視化的方式顯示功能組以及它們之間的關系② 使得大型軟件系統易于管理。類分包~：①具有相同繼承層次結構的類分組在一個包里②具有復合關系的類分組在一個包里③將相互協作、彼此交互的類分組在一個包里。

15.組件:實現一組規定接口功能的可執行部件。組件實現了一組接口。組件類型：①部署組件：描述可執行系統最終可部署部件②工作產品~：描述工程軟件有哪些文件組成③執行~：描述可執行軟件有哪些可執行部件組成

16.框架和模式是使軟件構件可重用的標準。框架：特定領域中類似應用程序的通用功能的模板，增加可重用性和減少應用程序開發時間。其特性：①類或組件的集合，具有執行一些特定或通用的功能②包含一些預定義規范的抽象和具體類接口③可以可通過子類化來擴展和實現這些抽象類和接口④定義一些抽象方法，這些方法接收系統中預定義的消息。模式：

新建的系統能滿足可重用的要求，有助于軟件組件之間更好的通信。~類型：通用職責分配軟件模式（GRASP）、四人組模式(GoF)單例模式：允許創建它自身的唯一一個實例的類。對于有些類只應許創建一個實例對象。用靜態數據成員來定義單件模式，以跟蹤所創建對象的生命期。設計模式好處：①可讓你創建能滿足新需求的可重用的解決方案而無需修改現有系統。②有助于軟件組件之間更好的通信。③有助于設計的重用、提供最有效的問題解決方案、給類分配職責。

17.實施質量流程的目的是為了在軟件開發過程中檢查所開發的軟件模型和產品的質量。質量流程包括：①用于開發軟件系統的軟件開發過程的質量②軟件開發過程中使用的軟件模型的質量③軟件開發過程結束時獲得的軟件產品的質量④質量流程自身的質量。生產質量過硬的產品時需要考慮的維度是：①技術：描述軟件開發過程所需的工具以及生成的輸出② 方法：描述軟件開發過程期間需要執行以生成輸出的操作順序③社會學：描述軟件開發過程所需的人力資源、環境條件和技能。質量保證技術檢查：語法：確保軟件模型使用正確的語法。語義：確保軟件模型表達出目標意圖并確保軟件模型的表示在項目中一致。美觀：確保軟件模型對稱并且完整。UML提供的三種擴展元素為：構造型：擴展 UML 詞匯表約束：擴展 UML 構造塊的語義關系。標記值：擴展 UML 構造塊的屬性

18靜態建模：它表示軟件系統的靜態或結構成分。它包括類關系圖和對象關系圖。它有助于描繪系統成分之間的關聯和依賴性。動態建模：它表示軟件系統靜態成分的行為過程。它包含交互、活動和狀態關系圖。它有助于表達系統在一段時間內的行為流程。

第三篇：UML實驗報告總結

實驗一 熟悉Rational Rose及建立用例模型 實驗

二、時序圖和協作圖建模

實習三 UML類圖與包圖建模（2學時）實驗四 狀態圖和活動圖建模 實驗五

組件與部署圖

實驗一 熟悉Rational Rose及建立用例模型

（2學時）

一、實驗名稱：熟悉（2學時）

二、實驗目的與要求：

? 了解和掌握Rose建模工具的使用 ? 掌握怎樣進行案例需求分析； ? 掌握UML用例圖建模技術

三、實驗內容：

1、熟悉rose上機環境及設置

2、根據以下談話設計出用例圖

Rational Rose及建立用例模型

四、實驗步驟：

見實驗說明書

實習二（2學時）

一、實驗名稱：

時序圖和協作圖建模（2學時）

二、實驗目的與要求：

? 了解和掌握Rose或Visio建模工具的使用

? 掌握怎樣進行系統分析，并進行UML靜態建模分析； ? 掌握UML時序圖和協作圖建模技術

三、實驗內容：

根據以下談話設計出時序圖和協作圖建模。

四、實驗步驟：

、UML類圖與包圖建模（2學時）

一、實驗名稱：UML類圖與包圖建模（2學時）

二、實驗目的與要求：

? 了解和掌握Rose或Visio建模工具的使用

? 掌握怎樣進行系統分析，并進行UML動態建模分析；

三、實驗內容：

四、實驗步驟：

實習四（2學時）

一、實驗名稱：

狀態圖和活動圖建模（2學時）

二、實驗目的與要求：

? 了解和掌握Rose或Visio建模工具的使用

? 掌握怎樣進行系統分析，并進行UML動態建模分析； ? 掌握UML狀態圖和活動圖建模技術

三、實驗內容：

四、實驗步驟：

實習五

組件與部署圖與代碼生成（2學時）

一、實驗名稱：

組件與部署圖（2學時）

二、實驗目的與要求：

三、實驗內容：

四、實驗步驟：

第四篇：UML實訓報告[推薦]

軟件建模實驗報告

題 目： 圖書管理系統

專業： 班級： 姓名： 學號： 指導教師： 成績：

完成日期：年月

摘 要

隨著知識化和信息化新經濟時代的到來，作為信息技術龍頭的計算機及軟件技術突飛猛進，uml成為一種不可或缺的工具。uml是一種定義良好、易于表達、功能強大且普遍適用的建模語言。它溶入了軟件工程領域的新思想、新方法和新技術。它的作用域不限于支持面向對象的分析與設計,還支持從需求分析開始的軟件開發的全過程。用現有的知識，按照軟件工程思想和系統的開發步驟，以圖書管理的應用需求為背景，分析設計了圖書管理系統，并利用rational rose對系統進行建模，完成用例圖和類圖的構建，為后期的程序設計提供標準。

根據建模需求分析，總結出本系統的參與者有借閱者和圖書管理員兩類。根據其職能不同，借閱者只能使用該系統借書、預訂書刊以及還書。圖書管理員則可使用系統進行圖書館業務的管理工作，如借閱者，書刊等的信息維護。系統可實現書籍信息的添加、修改、刪除等功能，這就保證了數據庫信息的一致性和統一性、安全性。

該系統以面向對象理論和數據庫管理信息系統開發相關知識為依據，介紹了設計開發中的模塊設計和數據與程序的連接，使sql server 2008與 visual studio 2010得到了有效的結合。

關鍵詞：圖書管理系統；uml；rational rose面向對象

目 錄 1 需求分析............................................................................................錯誤！未定義書簽。1.1 開發背景及意義........................................................................................................4 1.2 功能需求....................................................................................................................4 2 系統建模..............................................................................................................................8 2.1 創建系統用例模型......................................................................................................8 2.1.1 確定參與者........................................................................................................8 2.1.2 參與者的用例圖..............................................................錯誤！未定義書簽。2.2 系統的時序圖............................................................................錯誤！未定義書簽。2.2.1 確定系統參與者的屬性..................................................錯誤！未定義書簽。2.2.2 確定系統主要業務實體類..............................................錯誤！未定義書簽。2.2.3 確定系統類之間的關系..................................................錯誤！未定義書簽。2.3 系統的協作圖..........................................................................錯誤！未定義書簽。2.3.1 創建序列圖和協作圖......................................................錯誤！未定義書簽。2.3.2 創建狀態圖......................................................................錯誤！未定義書簽。2.3.2 創建活動圖......................................................................錯誤！未定義書簽。2.4 創建系統的部署摸型..............................................................錯誤！未定義書簽。1 需求分析

1.1 開發背景及意義

圖書館是一個專門收集、整理、保存、傳播文獻并提供利用的科學、文化、教育和科研機構。現代社會，圖書館成為繼續教育、終身教育的基地，擔負了更多的教育職能。傳遞科學情報，是現代圖書館的一個重要職能。圖書館收藏的圖書資料，是人類長期積累的一種智力資源，圖書館對這些資源的加工、處理，是對這種智力資源的開發。圖書館主要是用來學習的，如果有人遇到問題，他可以通過圖書管的書籍來解決問題。但是為了圖書館的正常運行和保護圖書，圖書館管理系統將用戶劃分為三類人：借閱者，圖書管理員，系統管理員。

一個基本的圖書館管理，可以大致分為以下流程：用戶登錄進入系統，在系統允許的情況下，進行可以進行的操作，如借書、還書和預定書籍等；管理員可以整理書籍和管理預訂的書籍等；系統管理員管理書目，管理借閱者信息等。1.2 圖書管理系統的需求分析 1.2.1系統功能需求

（1）借閱者可以通過網絡查詢書籍信息、預約書籍和續借書籍。

（2）圖書管理員作為借閱者的代理完成借閱圖書、歸還圖書和查詢借閱信息工作。（3）系統管理員可以對系統的數據進行維護，如增加、刪除和更新書目，增加、刪除

和更新借閱者帳戶，增加和刪除書籍。滿足上述需求的系統主要包括下面幾個模塊：

（1）基本數據維護模塊：提供使用者錄入、修改并維護基本數據的途徑。例如對借閱

者的書籍的各項信息的更新與修改。

（2）基本業務模塊：主要用于實現用戶借書與還書的管理，例如借閱者可以登錄系統

預訂書籍，圖書管理員可以取消書籍的預訂，當然還可以進行借書、還書等操作。（3）數據庫管理模塊：在系統中，所有書籍的信息以及借閱者的帳戶信息都要統一管

理，書籍的借閱情況、預訂情況也要進行詳細的記錄，所以要用統一的數據庫平臺進行管理。

（4）信息查詢模塊：主要用于查詢書籍的信息和借閱者的信息。

圖 1.1系統功能需求 1.2.2基本數據維護模塊

圖 1.2數據庫管理模塊

（1）添加借閱者信息：系統管理員可以添加借閱者帳戶。

（2）修改更新借閱者信息：系統管理員可以修改更新借閱者信息。（3）添加書目信息：系統管理員可以添加書目。

（4）修改更新書目信息：系統管理員可以修改和更新書目信息。（5）添加書籍信息：系統管理員可以添加書籍。（6）刪除書籍信息：系統管理員可以刪除書籍。篇二：uml實驗報告

《面向對象分析與設計uml》

實驗報告

學 號：180108213 姓 名：龐志偉

班 級：08級軟件2班

指導老師：姚宇峰

實驗及作業一

一、實驗目的了解軟件工程等基礎知識，為后續的統一建模語言uml知識的學習做好準備工作。

二、實驗設備與環境

裝有visio、rathionalrose的計算機。

三、實驗內容

1、復習闡述“軟件工程開發模型”的相關概念，并分析各種模型的優缺點，寫成實驗報告。

2、熟悉uml軟件設計工具visio、rational rose的安裝及環境

四、實驗過程及結果

1、軟件工程開發模型有（1）瀑布模型，（2）原型模型，（3）螺旋模型，（4）噴泉模型

（1）瀑布模型

將功能的實現與設計分開，便于分工協作，即采用結構化的分析與設計方法將邏輯實現與物理實現分開。將軟件生命周期劃分為制定計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護等六個基本活動，并且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。

優點：

1）為項目提供了按階段劃分的檢 瀑布模型查點。2）當前一階段完成后，您只需要去關注后續階段。3）可在迭代模型中應用瀑布模型。

缺點：

1）在項目各個階段之間極少有反饋。2）只有在項目生命周期的后期才能看到結果。3）通過過多的強制完成日期和里程碑來跟蹤各個項目階段。

（2）原型模型

原型模型又稱快速原型，它是增量模型的另一種形式；它是在開發真實系統之前，構造一個原型，在該原型的基礎上，逐漸完成整個系統的開發工作。快速原型模型的第一步是建造一個快速原型，實現客戶或未來的用戶與系統的交互，用戶或客戶對原型進行評價，進一步細化待開發軟件的需求。通過逐步調整原型使其滿足客戶的要求，開發人員可以確定客戶的真正需求是什么；第二步則在第一步的基礎上開發客戶滿意的軟件產品。

優點：克服瀑布模型的缺點，減少由于軟件需求不明確帶來的開發風險。

缺點：所選用的開發技術和工具不一定符合主流的發展；快速建立起來的系統結構加上連續的修改可能會導致產品質量低下。

（3）螺旋模型

螺旋模型采用一種周期性的方法來進行系統開發。這會導致開發出眾多的中間版本。使用它，項目經理在早期就能夠為客戶實證某些概念。該模型是快速原型法，以進化的開發方式為中心，在每個項目階段使用瀑布模型法。這種模型的每一個周期都包括需求定義、風險分析、工程實現和評審4個階段，由這4個階段進行迭代。軟件開發過程每迭代一次，軟件開發又前進一個層次。螺旋模型基本做法是在“瀑布模型”的每一個開發階段前引入一個非常嚴格的風險識別、風險分析和風險控制，它把軟件項目分解成一個個小項目。每個小項目都標識一個或多個主要風險，直到所有的主要風險因素都被確定。

優點：

1）設計上的靈活性,可以在項目的各個階段進行變更。2）以小的分段來構建大型系統,使成本計算變得簡單容易。3）客戶始終參與每個階段的開發,保證了項目不偏離正確方向以及項目的可控性。4）隨著項目推進,客戶始終掌握項目的最新信息 , 從而他或她能夠和管理層有效地交互。5）客戶認可這種公司內部的開發方式帶來的良好的溝通和高質量的產品。

缺點：

很難讓用戶確信這種演化方法的結果是可以控制的。建設周期長，而軟件技術發展比較快，所以經常出現軟件開發完畢后，和當前的技術水平有了較大的差距，無法滿足當前用戶需求。

（4）噴泉模型

噴泉模型是一種以用戶需求為動力，以對象為驅動的模型，主要用于采用對象技術的軟件開發項目。該模型認為軟件開發過程自下而上周期的各階段是相互迭代和無間隙的特性。軟件的某個部分常常被重復工作多次，相關對象在每次迭代中隨之加入漸進的軟件成分。無間隙指在各項活動之間無明顯邊界，如分析和設計活動之間沒有明顯的界限，由于對象概念的引入，表達分析、設計、實現等活動只用對象類和關系，從而可以較為容易地實現活動的迭代和無間隙，使其開發自然地包括復用。

優點：

噴泉模型不像瀑布模型那樣，需要分析活動結束后才開始設計活動，設計活動結束后才開始編碼活動。該模型的各個階段沒有明顯的界限，開發人員可以同步進行開發。其優點是可以提高軟件項目開發效率，節省開發時間，適應于面向對象的軟件開發過程。

缺點：

由于噴泉模型在各個開發階段是重疊的，因此在開發過程中需要大量的開發人員，因此不利于項目的管理。此外這種模型要求嚴格管理文檔，使得審核的難度加大，尤其是面對可能隨時加入各種信息、需求與資料的情況。

五、實驗小結：

通過本次實驗讓我了解了軟件工程開發的4中主要模型和這些模型的優缺點。初次安裝并使用uml軟件設計工具visio和rational rose使我初步認識了軟件開發中uml的設計。

實驗及作業二

一、實驗目的

1、了解面向對象的基本概念

2、熟悉面向對象的分析、設計過程

3、了解基于uml的面向對象分析設計過程

二、實驗設備與環境

裝有visio、rathionalrose的計算機。

三、實驗內容

1、熟悉rational rose的使用。

2、熟悉利用統一建模語言進行分析、設計軟件的過程，完成作業：論述面向對象（oo）方法的特點、優勢以及存在的問題。

四、實驗過程及結果

面向對象方法(object-oriented method)是一種把面向對象的思想應用于軟件開發過程中，指導開發活動的系統方法，簡稱oo(object-oriented)方法，是建立在“對象”概念基礎上的方法學。對象是由數據和容許的操作組成的封裝體，與客觀實體有直接對應關系，一個對象類定義了具有相似性質的一組對象。而每繼承性是對具有層次關系的類的屬性和操作進行共享的一種方式。所謂面向對象就是基于對象概念，以對象為中心，以類和繼承為構造機制，來認識、理解、刻畫客觀世界和設計、構建相應的軟件系統。

主要特征：封裝性，多態性 優勢：

（1）強調從現實世界中客觀存在的事物（對象）出發來認識問題域和構造系統，這就使系統開發者大大減少了對問題域的理解難度，從而使系統能更準確地反映問題域。

（2）運用人類日常的思維方法和原則（體現于oo方法的抽象、分類、繼承、封裝、消息通訊等基本原則）進行系統開發，有益于發揮人類的思維能力，并有效地控制了系 統復雜性。

（3）對象的概念貫穿于開發過程的終，使各個開發階段的系統成分具良好的對應，從而顯著地提高了系統的開發效率與質量，并大大降低系統維護的難度。

（4）對象概念的一致性，使參與系統開發的各類人員在開發的各所段具有共同語言，有效

地改善了人員之間的 交流和協作。

（5）對象的相對穩定性和對易變因素隔離，增強了系統的應變能力。

（6）對象類之間的繼承關系和對象的相對獨立性，對軟件復用提供了強有力的支持。存在的問題：

（1）軟件重用性差（2）軟件可維護性差

（3）開發出的軟件不能滿足用戶需要

五、實驗小結：

通過本次實驗了解rational rose的使用。學習利用統一建模語言進行分析、設計軟件的過程，通過上網查詢，了解有關面向對象（oo）方法的特點、優勢以及存在的問題。

第五篇：UML實訓總結

實訓總結（收獲與體會）

通過一個學期的Uml學習，我從書本上獲取了基本的理論知識，而真正的學以致用，將書本理論知識運用到實際的過程，是這次UML實訓的體現。

三個周的UML實訓，主要是圍繞著一個實訓題目“基于UML系統需求分析與設計--合倍利業務流管理系統”進行的，以小組為單位進行文檔的編寫，其中還對各種流程圖、類圖、用例圖等的繪制，整個過程設計了知識的方方面面。從中讓我認識到UML的作用和運作模式以及方法，它是一種統一建模的標準語言，現在對于大多數軟件開發來說，都使用Uml作為建模語言，形成了統一的標準。它是圖形化的的語言，可以很直觀的描述一個事物的狀態、行為與特征，很好的說明與表達了“合貝利任務管理”這個系統。

總之，在我看來，UML是一種定義良好、易于表達、功能強大且普遍適用建模語言。融入軟件工程領域的心思想、新方法和新技術，作用域不限于支持面向對象的分析和設計，也不單純是一種方法，僅僅是一組符號而已，它可以對任何具有靜態機構和動態行為的系統進行建模，所以我很喜歡適用UML，在今后的學習中，我還會進一步對該模型的學習，因為它方便、簡潔、干凈、清爽，直觀形象，把整個軟件系統的開發流程都融入進去。

這次實訓過程中，文檔方面的編寫，遇到了很多的問題，這些問題主要是對基礎知識的理解和把握不夠，不能融會貫通和學以致用，有時遇到困難的時候真的不知如何著手解決，但是，我始終相信的那句話“讀萬卷書，不如行萬里路，行萬里路不如名師指路”。所以，當遇到自己模糊和自己難以解決的問題時，向指導老師和懂的同學請教，幫助解決我遇到的問題，經過他們的講解后，我下來自己在分析，在動手，從不理解到理解，從不會到會，從懂到懂，這是一個讓我學習愉快的過程，在這個過程中，既可以豐富了自己的知識，還可以和老師和同學進行有效地方溝通。

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

實訓的日子即將結束，回想這一個過程，有過痛苦，有過煩惱，有過喜悅和有過成功。痛苦煩惱的是自己對所學書本知識掌握得不是很扎實，面對著從書本上學到的知識與實際聯系不起來，總結起來就是自己的動手練習的時間太少。而喜悅的是，在做的過程中遇到了困難和問題，主動向老師和會的同學請教，然后再做，直至做正確做成功后的那種喜悅。

團隊的力量是無窮的，通過組員的共同努力，完成了實訓項目。雖然，我們這組的項目存在著諸多的不足和缺點，但這正是以后學習和工作需要彌補的。這次實訓將為我以后進入社會提過了一筆寶貴的財富，是對我能力的一個見證。最后，不得不感謝指導教師熊飛老師的辛勤指導，和小組成員的共同努力！