第一篇：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建模，教会了我很多，而我要做的，就是在以后的学习与生活中更加努力的学习来迎接它带来的知识与挑战。
点击咨询 