第一篇：UML建模優缺點

1.UML的優點：

UML語言使系統建模過程標準化，統一化，規范化。

UML在整個軟件開發過程中采用相同的概念和表示方法，在不同的開發階段，不必轉換概念和表示方法，避免了傳統軟件開發方法的兩個鴻溝。

UML采用圖形化的表現形式。產生的模型易于理解，易于開發人員與用戶之間的溝通，從而能夠及時得到用戶的反饋信息。

用UML進行系統建模所得到的建模制品不僅僅包括各種模型框圖，還有大量豐富的文檔，這些文檔給系統后期的維護工作帶來了便捷。UML不是一門程序設計語言，但可以使用代碼生成工具將UML模型轉換為多種程序設計語言代碼，或使用反向生成工具將程序源代碼轉換為UML模型。2.UML的缺點：

任何事物都有正反兩個方面，UML這種新興的建模工具也存在它本身的一些不足，總結如下：

無法從語法上建立狀態圖與順序圖的關系。

無法從語法上建立活動圖與順序圖在流程描述中的關系。協作圖和順序圖中與消息相伴的參數不能與類圖建立關系。

第二篇：個人博客UML建模

圖書管理系統的分析及設計---應用UML建模

2010 —— 2011 學 年 第 一 學 期

信息技術學院

《軟件系統建模與UML》綜合設計實驗

***系統的UML建模

班

級 學

號 姓

名 任課教師

日

期

2010年12月30日

0 圖書管理系統的分析及設計---應用UML建模

目 錄

第1章 系統需求..............................................2 第2章 需求分析..............................................4

2.1 識別參與者...........................................4 2.2 識別用例.............................................5 2.3 用例的事件流描述....................................11 第3章 靜態結構模型.........................................16 3.1 定義系統對象........................................16 3.2 定義用戶界面類......................................16 3.3 建立類圖............................................16 第4章 動態行為模型.........................................19 4.1 創建系統順序圖（協作圖）............................19 4.2 創建系統的狀態圖....................................19 4.3 創建系統的活動圖....................................29 第5章 數據庫模型...........................................31 第6章 物理模型.............................................32 6.1 創建系統組件圖......................................32 6.2 創建系統部署圖......................................33 圖書管理系統的分析及設計---應用UML建模

第1章 系統需求

系統概述

Blog是一種讓編寫者可以表達自己意見、發表自己的看法以及見聞的方式。系統目標是使好友之間有一個交流溝通的平臺，通過博客可以互相了解彼此的生活狀況，系統擁有發布日志，心情，照片，留言評論等功能。

系統功能分析

本Blog系統將完成以下功能：

? 網站首頁功能

? 用戶的注冊、登錄和登出 ? 個人消息中心管理功能 ? 照片管理功能 ? 相冊分類管理功能 ? 文章管理功能 ? 文章分組管理功能 ? 心情管理功能

? 日志，照片，心情評論管理功能 ? 留言板留言，回復功能 ? 裝扮空間功能圖書管理系統的分析及設計---應用UML建模

根據以上分析，畫出系統功能圖（PPT原版）： 圖書管理系統的分析及設計---應用UML建模

第2章 需求分析

2.1 識別參與者

參與者關系圖如圖2-1所示：

游客其他會員博主

圖2-1 參與者關系圖

游客：未注冊的用戶，只擁有普通瀏覽功能

注冊會員：已注冊成為會員，與游客是泛化關系，擁有查看，評論，留言，回復留言評論的功能

博主：博客的擁有者，與會員是泛化關系，擁有查看，評論，回復評論，對自己博客的所有的文章，心情，照片，評論留言具有管理的權限。圖書管理系統的分析及設計---應用UML建模

2.2 識別用例

主用例圖如圖2-2所示：

看文章看相冊看心情看留言板日志評論看主人資料圖片評論游客看評論回復心情評論留言板留言會員評論文章，照片，心情文章博主修改博客內容照片相冊回復、刪除留言評論心情管理好友更改裝扮

圖2-2 主用例圖圖書管理系統的分析及設計---應用UML建模

管理留言板用例圖如圖2-3所示：

查看留言游客添加新留言會員回復留言博主刪除留言

圖2-3 管理留言板用例圖圖書管理系統的分析及設計---應用UML建模

管理文章用例圖如圖2-4所示：

查看文章評論查看文章游客添加新評論會員回復評論添加文章博主刪除文章修改文章刪除評論

圖2-4 管理文章用例圖圖書管理系統的分析及設計---應用UML建模

管理相冊用例圖如圖2-5所示：

查看評論游客查看照片添加新評論會員回復評論上傳照片刪除照片/修改博主創建相冊刪除/修改相冊刪除評論回復評論

圖2-5管理相冊用例圖圖書管理系統的分析及設計---應用UML建模

管理心情用例圖如圖2-6所示：

查看評論游客查看照片添加新評論會員回復評論上傳照片刪除照片/修改博主創建相冊刪除/修改相冊刪除評論回復評論

圖2-6 管理心情用例圖圖書管理系統的分析及設計---應用UML建模

注冊登錄用例圖如圖2-7所示：

瀏覽博客游客注冊進入自己博客會員登錄訪問別人博客

圖2-7 注冊登錄用例圖

管理好友用例圖如圖2-8所示：

添加好友博主刪除好友

圖2-7 管理好友用例圖

更改裝扮用例圖如圖2-9所示：

博主更改裝扮

圖2-9 更改裝扮用例圖 圖書管理系統的分析及設計---應用UML建模

2.3 用例的事件流描述

2.3.1瀏覽博客用例描述

用例名稱：瀏覽博客用例

用例描述：用戶進入自己或者其他會員的博客 參與者：博主，其他會員，游客 前置條件：進入博客 后置條件：退出博客

假設條件：用戶已進入網上博客 基本操作流程：

1、進入網上博客

2、查看信息中心，文章，好友心情，相冊，留言板等

3、退出網上博客 備選流程：

點擊“進入自己博客”可以進入自己博客

2.3.2管理留言板用例描述

用例名稱：管理留言板用例

用例描述：博主可以通過此用例添加、刪除留言，回復留言

會員可以留言，游客只能瀏覽 參與者：博主，其他會員，游客 前置條件：成功進入到留言板模塊 后置條件：退出留言板模塊 假設條件：用戶已經進入網上博客 基本操作流程：

1、進入留言板模塊

2、博主：添加，刪除，修改留言，回復留言

3、會員：添加留言，游客只能查看

3、退出留言板模塊 圖書管理系統的分析及設計---應用UML建模

備選流程：

點擊導航超鏈接可以直接進入其他模塊

2.3.3管理文章用例描述

用例名稱：管理文章用例

用例描述：博主可以通過此用例添加、刪除、修改文章及評論、回復評論

會員可以瀏覽文章以及進行評論，游客只能瀏覽 參與者：博主，其他會員，游客 前置條件：成功進入到文章模塊 后置條件：退出文章模塊 假設條件：用戶已經進入網上博客 基本操作流程：

1、進入文章模塊

2、博主：添加，刪除，修改文章，評論及回復評論

3、會員：瀏覽文章，添加評論和回復評論，游客只能查看

3、退出文章模塊 備選流程：

點擊導航超鏈接可以直接進入其他模塊

2.3.4管理相冊用例描述

用例名稱：管理相冊

用例描述：博主可以通過此模塊添加、刪除、修改相冊；添加、刪除照片

會員可以瀏覽相冊，照片，以及對照片進行評論；游客只能瀏覽 參與者：博主，其他會員，游客 前置條件：進入相冊模塊 后置條件：退出相冊模塊 假設條件：用戶已進入網上博客 基本操作流程： 進入相冊模塊

游客：查看相冊照片，評論，回復 圖書管理系統的分析及設計---應用UML建模

3、會員：查看相冊照片，評論照片，回復評論

4、博主：查看、添加、刪除、修改相冊、照片、回復評論

5、退出相冊模塊 備選流程：

點擊導航超鏈接可以直接進入其他模塊

2.3.5管理心情用例描述

用例名稱：管理心情

用例描述：博主可以通過此用例添加、刪除、修改心情，及添加、刪除評論、回復評論；

會員可以瀏覽心情，以及進行評論，回復評論，游客只進行查看 參與者：博主，其他會員，游客 前置條件：成功進入到心情界面 后置條件：退出心情界面 假設條件：用戶已進入網上博客 基本操作流程：

1、進入心情界面

2、博主添加，刪除，修改心情，添加、刪除評論及回復評論

3、會員為心情評論或者回復評論，游客只能查看

4、退出心情界面 備選流程：

點擊導航超鏈接可以直接進入其他模塊

2.3.6管理好友用例描述

用例名稱：管理好友

用例描述：博主可以通過此模塊添加好友 參與者：博主

前置條件：博主已登陸自己博客 后置條件：退出添加好友模塊 假設條件：用戶已登錄自己博客 圖書管理系統的分析及設計---應用UML建模

基本操作流程：

1、進入管理好友模塊

2、選擇要添加或者刪除的好友的會員名稱

3、點擊添加或者刪除

4、添加或者刪除成功

4、退出管理好友模塊 備選流程：

點擊導航超鏈接可以直接進入其他模塊

2.3.7查看信息中心用例描述

用例名稱：查看信息中心

用例描述：博主可以通過此模塊更改個人信息

所有用戶都可以通過此模塊瀏覽博主信息 參與者：博主，其他會員，游客 前置條件：成功登錄到個人信息模塊 后置條件：退出個人信息模塊 假設條件：用戶已進入網上博客 基本操作流程：

1、進入個人信息模塊

2、所有會員：查看博主信息

3、博主：更改個人信息

4、退出個人信息模塊 備選流程：

點擊導航超鏈接可以直接進入其他模塊圖書管理系統的分析及設計---應用UML建模

2.3.8裝扮博客用例描述

用例名稱：裝扮博客

用例描述：博主可以通過此模塊更改皮膚裝扮 參與者：博主

前置條件：博主已登陸自己博客 后置條件：退出裝扮模塊 假設條件：用戶已登錄自己博客 基本操作流程：

1、進入裝扮模塊

2、選擇喜歡的皮膚

3、點擊裝扮，裝扮成功

4、退出裝扮模塊 備選流程：

點擊導航超鏈接可以直接進入其他模塊 圖書管理系統的分析及設計---應用UML建模

第3章 靜態結構模型

進一步分析系統需求，發現類以及類之間的關系，確定它們的靜態結構和動態行為，是面向對象[7]分析的基本任務。系統的靜態結構模型主要用類圖和對象圖描述。

3.1 定義系統對象

博主：博客的擁有者，擁有博客的所有權限，也可理解為后臺管理員或者系統管理員；

前臺用戶：分為會員和游客

會員：可以查看和評論博主的文章，心情，相冊，以及在留言板留言；

游客：只具有查看博主的博客的權限；

3.2 定義用戶界面類

通過對系統的不斷分析和細化，可識別出下述界面類、類的操作和屬性。圖書管理系統的分析及設計---應用UML建模

邊界類如圖3-1所示：

圖3-1 邊界類圖 圖書管理系統的分析及設計---應用UML建模

3.3 建立類圖

實體類圖如圖3-2所示：

圖3-1 實體類圖 圖書管理系統的分析及設計---應用UML建模

第4章 動態行為模型

4.1 創建系統順序圖

文章、心情、照片的添加順序圖如圖4-1所示：

: 博主 : 日志管理界面1: 添加日志2: 添加文章信息3: 添加修改成功 : 文章 : 照片管理界面 : 照片 : 心情管理界面 : 心情4: 返回添加成功5: 添加照片信息6: 添加照片7: 添加修改成功8: 返回添加成功9: 添加心情10: 添加心情信息11: 添加修改成功12: 返回添加成功

圖4-1 文章、心情、照片的添加順序圖圖書管理系統的分析及設計---應用UML建模

文章、心情、照片的刪除順序圖如圖4-2所示：

: 博主 : 日志管理界面1: 刪除日志2: 刪除文章信息3: 返回刪除成功 : 文章 : 照片管理界面 : 照片 : 心情管理界面 : 心情4: 顯示刪除成功5: 刪除照片信息6: 刪除照片7: 返回刪除成功8: 顯示刪除成功9: 刪除心情10: 刪除心情信息11: 返回刪除成功12: 顯示刪除成功圖4-2 文章、心情、照片的刪除順序圖圖書管理系統的分析及設計---應用UML建模

文章、心情的修改順序圖如圖4-3所示：

: 博主1: 修改日志 : 日志管理界面 : 文章 : 心情管理界面 : 心情2: 修改文章信息3: 返回修改成功4: 顯示修改成功5: 修改心情6: 修改心情信息7: 返回修改成功8: 顯示修改成功

圖4-3 文章、心情的修改順序圖 圖書管理系統的分析及設計---應用UML建模

文章、心情、照片的查看順序圖如圖4-4所示：

: 游客1: 查看文章(): 未登錄瀏覽頁面 : 文章 : 心情 : 照片 : 留言板2: 選擇符合添加文章3: 返回要查看的文章4: 返回文章信息5: 查看心情()6: 選擇符合添加心情7: 返回要查看的心情8: 返回心情信息9: 查看照片()10: 選擇符合添加照片11: 返回要查看的照片12: 返回照片信息13: 查看留言板()14: 選擇留言15: 返回留言板16: 返回留言板信息圖4-4 文章、心情、照片的查看順序圖 圖書管理系統的分析及設計---應用UML建模

留言添加、回復順序圖如圖4-5所示：

: 會員1: 添加留言 : 留言管理界面 : 留言板 : 留言板回復2: 添加留言3: 返回添加成功4: 顯示添加成功5: 繼續添加6: 回復留言7: 添加回復8: 添加回復信息9: 返回添加回復信息成功10: 返回添加回復成功11: 顯示添加成功12: 繼續回復

圖4-5留言添加、回復順序圖圖書管理系統的分析及設計---應用UML建模

留言刪除順序圖如圖4-6所示：

: 博主 : 留言管理界面1: 刪除留言2: 刪除留言信息(): 留言板3: 返回刪除成功()4: 顯示刪除成功5: 繼續刪除留言()

圖4-6留言刪除順序圖如圖書管理系統的分析及設計---應用UML建模

登錄注冊順序圖如圖4-7所示：

: 游客1: 登錄(): 登錄界面 : 會員 : 注冊界面2: 驗證()3: 返回登陸成功4: 驗證()5: 注冊()6: 返回注冊成功7: 再次登錄()8: 驗證()9: 返回登錄通過

圖4-7登錄注冊順序圖圖書管理系統的分析及設計---應用UML建模

管理好友順序圖如圖4-8所示：

: 博主 : 好友管理界面 : 好友1: 添加好友()2: 添加好友信息3: 返回添加成功4: 顯示添加成功5: 刪除好友()6: 刪除好友信息7: 返回刪除成功8: 顯示刪除成功

圖4-8 管理好友順序圖圖書管理系統的分析及設計---應用UML建模

4.2 創建系統的狀態圖

好友狀態圖如圖4-8所示：

未成好友狀態添加好友刪除好友成功添加未成功添加好友狀態未成功關閉狀態

圖4-8好友狀態圖圖書管理系統的分析及設計---應用UML建模

會員狀態圖如圖4-9所示：

其他會員游客注冊博客會員查看別人博客退出狀態查看別人博客登陸自己博客登陸自己博客博主

圖4-9會員狀態圖

文章狀態圖如圖4-10所示：

查看狀態關閉不是會員評論回復評論不是博主是會員刪除文章評論是博主可編輯狀態可修改文章回復文章評論刪除文章修改文章添加新文章

圖4-9文章狀態圖 圖書管理系統的分析及設計---應用UML建模

4.3 創建系統的活動圖

管理文章活動圖如圖4-10所示：

登錄自己博客驗證密碼，用戶名是否匹配驗證通過刪除文章驗證未通過失敗返回失敗結果成功返回成功登錄失敗退出圖4-10管理文章活動圖 圖書管理系統的分析及設計---應用UML建模

登錄注冊活動圖如圖4-11所示：

登錄驗證用戶名密碼密碼錯誤退出用戶名不存在注冊不注冊注冊注冊成功用戶名不存在輸入用戶名密碼用戶名已存在繼續注冊放棄注冊注冊失敗

圖4-11登錄注冊活動圖 圖書管理系統的分析及設計---應用UML建模

第5章 數據庫模型

數據庫模型如圖5-1所示：

圖5-1 數據庫模型圖

圖書管理系統的分析及設計---應用UML建模

第6章 物理模型

6.1 創建系統組件圖

網上博客組件圖如圖6-1所示：

會員登陸、注冊文章分組文章評論回復心情主程序照片相冊留言板好友留言板回復個人消息中心

圖6-1 網上博客組件圖

圖書管理系統的分析及設計---應用UML建模

6.2 創建系統部署圖

網上博客部署圖如圖6-2所示：

客戶端瀏覽器WEB瀏覽器

HTTP瀏覽器TomCat服務器圖6.2 網上博客部署圖

數據庫服務器SQL Server 2008

第三篇：UML(ATM系統)動態建模

實驗3 動態建模

一、實驗目的與要求 掌握分析ATM系統用例中用例的流程，分析對象之間的交互關系 掌握用UML設計參與對象之間的交互，用狀態圖、時序圖、協作圖和活動圖來描述系統的行為。

二、實驗設備、環境

PC(一臺)，Windows 2000或以上版本，安裝Microsoft Visio 2003

三、實驗內容及步驟 交互圖：實現ATM系統的序列關系圖和通信（協作）關系圖； 2 分析設計軟件系統的狀態圖。（（1）和（2）選做一個狀態圖）；

（1）ATM系統

（2）具體題目如下：某銷售POS機，它的工作流程是：當客戶到收銀臺后，收銀員逐一輸入用戶購買的商品，輸入完之后，計算出總金額，然后等待用戶付款，確定支付成功之后，完成收銀，等待下一個客戶。請為其繪制出相應的狀態機圖。

3分析設計ATM系統的活動圖（選做1個活動圖）。

建立動態模型：

建立序列關系圖、狀態圖、活動圖

步驟：

?

編寫腳本

?

確定各個對象之間的事件

?

構造事件追蹤圖（交互圖）?

構造狀態圖

?

添加活動和動作

一、時序關系圖

1）ATM系統的正常情況腳本

? ATM請儲戶插卡；儲戶插入一張現金兌換卡。? ATM接受該卡并讀它上面的卡號。

? ATM要求儲戶輸入密碼；儲戶輸入自己的密碼“1234”等數字。

? ATM請求系統驗證卡號和密碼；核對儲戶密碼，然后通知顯示器顯示說這張卡有效。

? ATM要求儲戶選擇事務類型（取款、轉賬、查詢等）；儲戶選擇“取款”。? ATM要求儲戶輸入取款額；儲戶輸入“880”。

? ATM確認取款額在預先規定的限額內，然后要求處理這個事務；成功處理完這項事務并返回該賬戶的新余額。

? ATM吐出現金并請儲戶拿走這些現金；儲戶拿走現金。? ATM問儲戶是否繼續這項事務；儲戶回答“不”。

? ATM打印賬單，退出現金兌換卡，請儲戶拿走它們；儲戶取走賬單和卡。? ATM請儲戶插卡。

2）ATM系統的異常情況腳本

? ATM請儲戶插卡；儲戶插入一張現金兌換卡。? ATM接受該卡并順序讀它上面的數字。

? ATM要求密碼；儲戶誤輸入“8888”等數字。

? ATM請求總行驗證卡號和密碼；經驗證發現密碼錯誤，拒絕這張卡。? ATM顯示“密碼錯”，并請儲戶輸入密碼；儲戶輸入“1234”等數字；ATM請求總行驗證后知道輸入密碼正確。

? ATM要求儲戶選擇事務類型；儲戶選擇“取款”。

? ATM詢問取款額；儲戶改變主意不想取款了，按“取消”。? ATM退出現金兌換卡，請儲戶拿走它們；儲戶取走卡。? ATM請儲戶插卡。

ATM 腳本的事件時序圖如下圖所示：（正常情況）

用戶讀卡器顯示器ATM卡用戶賬戶事務提款機插卡讀卡初始化提示輸入密碼輸入密碼驗證密碼獲取密碼獲取賬戶初始化提示選擇業務選擇業務執行事務初始化提示輸入金額輸入金額獲取余額驗證取款金額計算余額計算利息更新賬戶配給現金打印收據退卡

二、狀態圖

主屏]do：顯示主屏幕插卡[可讀]Do：要求密碼輸入密碼Do:驗證賬戶繼續密碼錯拿走卡退卡do：退卡請拿走卡插卡[不可讀]不可讀的卡do：顯示信息取消取消do:顯示取消信息無效賬戶賬戶有效Do:要求類型取消輸入類型Do:要求金額取消結束do：打印賬單Do:顯示無效賬戶信息輸入金額等待5秒Do:處理事務中止取消Do:請求繼續拿走現金do：吐出現金請拿走現金事務成功取消事務失敗Do:失敗信息網絡響應等待網絡響應中斷do：顯示取消信息ATM類的狀態圖

處理事務驗證賬戶請求處理事務請求驗卡事務成功事務失敗無效賬戶賬戶有效密碼錯

事務處理狀態圖

賬戶驗證狀態圖

三、活動圖

插卡<沒有接收動作>輸入密碼<沒有接收動作>輸入賬戶類型輸入金額取卡取錢<沒有發送動作>

四、實驗體會

順序圖的重點是完成某個行為的對象類之間所傳遞的消息的時間順序。一個順序圖事務對象角色，生命線，激活期和消息構成。協作圖用于描述系統的行為是如何有系統的成分合作實現的。協作時一種靜態結構，是一個系統對實現某些服務所涉及的對象及其交互的投影。一個協同定義了一組對某些服務有意義的參加者和它們的聯系，這些參加者定義了交互中的對象所扮演的角色。

第四篇：UML建模的要點總結

UML建模的要點總結

預備知識：

一、UML的特性與發展現狀

UML是一種Language(語言)

UML是一種Modeling(建模)Language UML是Unified(統一)Modeling Language

1、已進入全面應用階段的事實標準

2、應用領域正在逐漸擴展，包括嵌入式系統建模、業務建模、流程建模等多個領域

3、成為“產生式編程”的重要支持技術：MDA、可執行UML等

二、建模的目的與原則

1、幫助我們按照實際情況或按我們需要的樣式對系統進行可視化;提供一種詳細說明系統的結構或行為的方法;給出一個指導系統構造的模板;對我們所做出的決策進行文檔化。

2、僅當需要模型時，才構建它。

3、選擇要創建什么模型對如何動手解決問題和如何形成解決方案有著意義深遠的影響;每一種模型可以在不同的精度級別上表示;最好的模型是與現實相聯系的;單個模型是不充分的。對每個重要的系統最好用一組幾乎獨立的模型去處理。

三、誰應該建模

1、業務建模：以領域專家為主，需求分析人員是主力，系統分析員、架構師可參與

2、需求模型：以需求分析人員為主，系統分析員是主力，領域專家提供指導，架構師和資深開發人員參與

3、設計模型：高層設計模型以架構師為主，系統分析員從需求方面提供支持，資深開發人員從技術實現方面提供支持。詳細設計模型則以資深開發人員為主，架構師提供指導。

4、實現模型：以資深開發人員(設計人員)為主，架構師提供總體指導。

5、數據庫模型：以數據庫開發人員為主，架構師提供指導，資深開發人員(設計人員)予以配合。

正式開始

UML組成，三部分(構造塊、規則、公共機制)，關系如下圖所示：

一、構造塊

1、構造塊是對模型中最具有代表性的成分的抽象

建模元素：UML中的名詞，它是模型基本物理元素。

行為元素：UML中的動詞，它是模型中的動態部分，是一種跨越時間、空間的行為。

分組元素：UML中的容器，用來組織模型，使模型更加的結構化。

注釋元素：UML中的解釋部分，和代碼中的注釋語句一樣，是用來描述模型的。

1.1、建模元素

類(class)和對象(object)

接口(interface)

主動類(active class)

用例(use case)

協作(collaboration)

構件(component)

節點(node)

類(class)和對象(object)

類是對一組具有相同屬性、相同操作、相同關系和相同語義的對象的抽象

UML中類是用一個矩形表示的，它包含三個區域，最上面是類名、中間是類的屬性、最下面是類的方法

對象則是類的一個實例(object is a Instance of Class)

接口(interface)

接口是描述某個類或構件的一個服務操作集

主動類(active class)

主動類實際上是一種特殊的類。引用它的原因，實際上是在開發中需要有一些類能夠起到 啟動控制活動的作用

主動類是指其對象至少擁有一個進 程或線程，能夠啟動控制活動的類

用例(use case)

用例是著名的大師Ivar Jacobson首先提出的，現已經成為了面向對象軟件開發中一個需求分析的最常用工具

用例實例是在系統中執行的一系列動作，這些動作將生成特定執行者可見的價值結果。一個 用例定義一組用例實例。

協作(collaboration)

協作定義了一個交互，它是由一組共同工作以提供某協作行為的角色和其他元素構 成的一個群體。

對于某個用例的實現就可 以表示為一個協作

構件(component)

在實際的軟件系統中，有許多要比“類”更大的實體，例如一個COM組件、一個DLL文件、一個JavaBeans、一個執行文件等等。為了更好地對在UML模型中對它們進行表示，就引入了構件(也譯為組件)

構件是系統設計的一個模塊化部分，它隱藏了內部的實現，對外提供了一組外部接口。在系統中滿足相同接口的組件可以自由地替換

節點(node)

為了能夠有效地對部署的結構進行建模，UML引入了節點這一概念，它可以用來描述實際的PC機、打印機、服務器等軟件運行的基礎硬件

節點是運行時存在的物理元素，它表示了一種可計算的資源，通常至少有存儲空間和處理能力

1.2、行為元素

交互(interaction)： 是在特定語境中，共同完成某個任務的一組對象之間交換的信息集合

交互的表示法很簡單，就是一條有向直線，并在上面標有操作名

狀態機(state machine)：是一個對象或交互在生命周期內響應事件所經歷的狀態序列

在UML模型中將狀態畫為一個圓 角矩形，并在矩形內寫出狀態名稱及其子狀態

1.3、分組元素

對于一個中大型的軟件系統而言，通常會包含大量的類，因此也就會存在大量的結構事物、行為事物，為了能夠更加有效地對其進行整合，生成或簡或繁、或宏觀或微觀的模型，就需要對其進行分組。在UML中，提供了“包(Package)”來完成這一目標

1.4、注釋元素

結構事物是模型的主要構造塊，行為事物則是補充了模型中的動態部分，分組事物而是用來更好地組織模型，似乎已經很完整了。而注釋事物則是用來錦上添花的，它是用來在UML模型上添加適當的解釋部分

2、關系

UML模型的關系比較多,下圖

2.1 關聯關系

關聯(Association)表示兩個類之間存在某種語義上的聯系。關聯關系提供了通信的路徑，它是所有關系中最通用、語義最弱的。

在UML中，使用一條實線來表示關聯關系

在關聯關系中，有兩種比較特殊的關系：聚合和組合

聚合關系：聚合(Aggregation)是一種特殊形式的關聯。聚合表示類之間的關系是整體與部分的關系

如果發現“部分”類的存在，是完全依賴于“整體”類的，那么就應該使用“組合”關系來描述

組合是聚合的變種，加入了一些重要的語義。也就是說，在一個組合關系中一個對象一次就只是一個組合的一部分，“整體”負責“部分”的創建和破壞，當“整體”被破壞時，“部分”也隨之消失

聚合就像汽車和車胎，汽車壞了胎還可以用。組合就像公司和下屬部門，公司倒閉了部門也就不存在了!

2.2 泛化、實現與依賴

泛化關系描述了一般事物與該事物中的特殊種類之間的關系，也就是父類與子類之間的關系。

實現關系是用來規定接口和實現接口的類或組件之間的關系。接口是操作的集合，這些操作用于規定類或組件的服務。

有兩個元素X、Y，如果修改元素X的定義可能會引起對另一個元素Y的定義的修改，則稱元素Y依賴(Dependency)于元素X。

二、規則

命名：也就是為事物、關系和圖起名字。和任何語言一樣，名字都是一個標識符

范圍：與類的作用域相似.可見性：Public，Protected，Private，Package

三、UML公共機制

1、規格描述

在圖形表示法的每個部分后面都有一個規格描述(也稱為詳述)，它用來對構造塊的語法和語義進行文字敘述。這種構思，也就使可視化視圖和文字視圖的分離 ：

2、UML修飾與通用劃分

在為了更好的表示這些細節，UML中還提供了一些修飾符號，例如不同可視性的符號、用斜體字表示抽象類

UML通用劃分：

1)類與對象的劃分：類是一種抽象，對象是一個具體的實例

2)接口與實現的分離：接口是一種聲明、是一個契約，也是服務的入口;實現則是負責實施接口提供的契約

3、UML擴展機制

這部分不容易描述，待改

構造型：在實際的建模過程中，可能會需要定義一些特定于某個領域或某個系統的構造塊

標記值則是用來為事物添加新特性的。標記值的表示方法是用形如“{標記信息}”的字符串

約束是用來增加新的語義或改變已存在規則的一種機制(自由文本和OCL兩種表示法)。約束的表示法和標記值法類似，都是使用花括號括起來的串來表示，不過它是不能夠放在元素中的，而是放在相關的元素附近。

4、UML視圖和圖

圖名

功能

備注

類圖

描述類、類的特性以及類之間的關系

對象圖

描述一個時間點上系統中各個對象的一個快照

復合結構圖

描述類的運行時刻的分解

構件圖

描述構件的結構與連接

部署圖

描述在各個節點上的部署

包圖

描述編譯時的層次結構

用例圖

描述用戶與系統如何交互

活動圖

描述過程行為與并行行為

狀態機圖

描述事件如何改變對象生命周期

順序圖

描述對象之間的交互，重點在強調順序

通信圖

描述對象之間的交互，重點在于連接

定時圖

描述對象之間的交互，重點在于定時

交互概觀圖

是一種順序圖與活動圖的混合附：開發過程與圖的對應關系

本文來自CSDN

博

客，轉

載

請

標http://blog.csdn.net/Mac_cm/archive/2009/07/27/4384704.aspx

UML 1原有 UML 1非正式圖

UML 2.0新增

UML 1原有

UML 1原有

UML中非正式圖 UML 1原有 UML 1原有 UML 1原有 UML 1原有 UML 1中的協作圖 UML 2.0 新增 UML 2.0新增 明

出

處

：

第五篇：uml建模報告ATM自動柜員機系統

UML建模報告

（2010 / 2011 學年 第 2學期）

題 目：

基于UML的ATM自動

柜員機系統

專

業：

成員：

指

導

教

師：

基于UML的ATM自動柜員機系統建模報告

一、需求分析

（1）功能需求：

1.登陸：客戶通過輸入正確的登陸密碼即可登陸ATM。

2.取款：允許客戶取出自己賬戶中的現金。3.客戶存款：允許客戶把現金存入自己賬戶。4客戶查詢余額：允許客戶查詢自己的賬戶余額。

5客戶轉賬：允許客戶將自己賬戶中的金額轉移至另一賬戶。6客戶更改密碼：允許客戶修改自己的登錄密碼。

（2）系統操作要求：

1．要求用戶每次取款數額為50的整數倍；

2．要求用戶一次取款數額不得大于1000元； 3．要求用戶一天取款數額不得超過5000元； 4．要求用戶每次取款數額不得大于賬戶余額； 5．要求用戶設置的登錄密碼為6位。

（3）系統性能要求：

1．要求反應時間不得大于10秒鐘； 2． 系統設計目標：

ATM自動取款機可以提供24小時不間斷服務，操作簡單，可以很方便為用戶提供取款、轉賬/匯款、查詢賬戶余額等服務。

（4）實現手段：

使用ASP.NET進行界面設計，建立一個數據庫保存客戶的賬戶信息，使用C#語言功能函數并對數據庫中的賬戶信息進行操作。

二、總體設計

本系統總共分為登陸、查詢、存款、取款、轉賬、修改密碼等6個功能模塊。

1.登錄模塊：登陸模塊使用字符匹配算法，要求用戶在輸入賬號之后輸入登陸密碼，只有輸入正確的密碼才能登陸自己的賬戶。否則提示密碼錯誤。

2.查詢模塊：用戶輸入正確的密碼后就可登陸自己的賬戶并接受服務。查詢功能允許用戶查得自己賬戶上的余額信息。

3.存款模塊：允許客戶向自己的賬戶中存入現金。

4.取款模塊：允許客戶從賬戶中取走現金，要求取出的金額不能大于所剩余款，否則提示余額不足。

5.轉賬模塊：允許客戶將自己賬戶中的金額轉移至另一賬戶。要求所轉的金額不能多于所剩余款，否則提示余額不足。

6.修改密碼模塊：允許用戶修改自己的登陸密碼，密碼仍然是6位數的，修改之后，下次登陸就應該用新密碼。

三、詳細設計 用例圖：

類圖：

客戶取錢的協作圖：

其他功能的協作圖與此類似。

賬目類的狀態圖：

ATM系統的部署圖：

四、測試報告 我們在客戶數據庫中建立四個賬戶，如下：

其中四個屬性分別是客戶名、賬號、密碼、賬戶余額。打開網頁，進入初始頁面：

若選擇取回磁卡，顯示如下：

1.登錄功能測試

我們選擇繼續以進行測試，單擊測試進入如下頁面：

若輸入不存在的賬號，則出現提示：

現在我們輸入正確的賬號，這里以08060112為例：

單擊確認，系統將提示客戶輸入密碼，正確的密碼是“123456”，我們輸入“333333”以進行測試，系統提示密碼錯誤：

我們輸入正確的密碼“123456”，單擊確認，則進入交易界面：

2.查詢功能測試

單擊查詢，顯示如下

與數據庫表中的number值比較可得，結果正確。3.取款功能測試

選擇返回，回到主菜單，單擊取款，系統提示客戶輸入取款金額：

我們輸入300單擊確認，顯示如下

單擊確定回到主菜單，單擊查詢，顯示如下：

余額為700，說明取款成功，取款功能順利實現。4.轉賬功能測試

單擊返回，回到主菜單，單擊轉賬，系統提示用戶輸入轉入賬號，我們以轉入08060119為例：

單擊確認，系統提示轉賬金額，我們輸入300：

單擊確認，提示轉賬成功：

單擊確定回到主菜單，這時我們單擊查詢08060112的余額：

結果正確，我們再通過數據庫查詢08060119的余額，打開表格，右擊，執行，顯示如下：

結果也正確，說明轉賬功能也已順利實現。5.存款功能測試

單擊返回回到主菜單，單擊“存款”，我們通過輸入數值來模擬放入現金：

單擊確認，系統提示操作成功：

單擊“確定”回到主菜單，單擊查詢，顯示如下：

結果正確。

6.修改密碼功能測試

單擊返回回到主菜單，單擊“修改密碼”，系統提示如下：

我們將密碼修改為“555555”，輸入“555555”后，提示操作成功：

單擊確定就回到主菜單。這時我們取回磁卡重新登錄以測試密碼是否已經修改。依舊輸入卡號08060112，單擊確認，輸入舊密碼“123456”，提示密碼錯誤：

單擊確定，重新輸入新密碼“555555”，單擊確認，則可順利登錄到主菜單

可見，密碼已經修改成功，另一方面，我們查看數據庫中的數據，右擊，執行，顯示如下：

可以看到賬戶08060112的password屬性已經變為“555555”，因此，修改密碼功能也能順利實現。至此，ATM系統的六大功能都已通過測試并正確無誤。

五、總結

通過這次UML建模的學習，我們學會了很多知識。之前我對UML建模一無所知，但現在我已學會了一些UML建模的基本知識，并學會了建立一些簡單的模型。

雖然只有短短的幾個禮拜，但收獲卻是很大的。首先是分析問題的能力，剛拿到這個題，總覺得無從下手，不知道題目到底要我們做什么，心里只是干著急，不知道該干嘛。經過一周的迷茫，我們開始靜下心來，分析題目，找參考書，嘗試性地進行編程。到第三周，我們終于做出了一個成果并且編譯沒有錯誤。之后就是嘗試運行，運行的過程中出現很多問題。比如轉賬，修改密碼等，但經過我們細心的測試、排查，還是找到了錯誤的原因并進行了糾正。因此，我們的查錯改錯的能力也得到了提高。最重要的是，我們通過這次實習學會了互相合作，俗話說“三個臭皮匠頂個諸葛亮”，也許我們單獨做很難完成這個程序。但是只要我們團結一致就沒有克服不了的困難。這次實習在我們的大學生活乃至整個人生中都有著非常重要的意義，是一筆不小的財富，難忘的經歷。我們會以此為基礎走好人生的每一步。

以上是我們對UML建模的學習的一點總結，同時也是為自己的未來整理好思路，為以后的學習做好準備。UML建模，教會了我很多，而我要做的，就是在以后的學習與生活中更加努力的學習來迎接它帶來的知識與挑戰。