UML建模参考样例3

UML示例图UML示例图在Visio里，包和类的关系是包含关系，将类拖入包的文件夹之后，关系就建立了，二元关联符号可以设置为：聚合、合成。

接口：空心圆+直线（唐老鸭类实现了‘讲人话’）；依赖：虚线+箭头（动物和空气的关系）；关联：实线+箭头（企鹅需要知道气候才迁移）；聚合：空心四边形+实线+箭头（雁群和大雁的关系）；合成：实心四边形+实线+箭头（鸟和翅膀的关系）；泛化：空心三角形+实线（动物和鸟的继承关系）；实现：空心三角形+虚线（实现大雁飞翔的接口）；UML类图解释UML类图：1. 首先看“动物”矩形框，它代表一个类。

该类图分为三层，第一层显示类的名称，如果是抽象类就要用斜体显示。

第二层是类的特性，通常就是字段和属性。

第三层是类的操作，通常是方法和行为。

注意前面的符号，‘+’表示public, ‘—’ 表示private, ‘#’表示protected.2. “飞翔”矩形框表示一个接口图，它与类图的区别主要是顶端有《interface》显示，第一行是接口名称，第二行是接口方法。

接口还有另一种表示方法，俗称棒棒糖表示法，就是唐老鸭类实现了“讲人话”的接口。

interface IFly interface Ilanguage{ {void Fly(); void Speak();} }3. 动物，鸟，鸭，唐老鸭他们之间都是继承的关系，继承关系用空心三角形+实现来表示。

4.“大雁”实现了“飞翔”接口。

实现接口用空心三角形+虚线来表示。

（注：下面的图中应为空心三角形）class Bird:Animal class WideGoose:IFly{ {//继承动物类 //实现飞翔接口} }5. 企鹅与气候有很大的关系，企鹅需要“知道”气候的变化，需要“了解”气候规律。

当一个类“知道”另一个类时，可以用关联(association)关系。

关联关系用实线箭头来表示。

class Penguin :Bird{private Climate climate;//在企鹅Penguin中，引用到气候Climate对象}6. “大雁”和“雁群”这两个类。

UML用例图模板定期存款存款业务员ULM用例图1、UC1用例名称：查看客户资料⏹参与者(Actor)[参与者]⏹简要说明(Brief Description)[简要介绍该用例的作用和目的]⏹事件流(Flow of Event) [事件流应该表示出所有的场景]★基本流1)基本流12)基本流1[把所有的基本流列出来]★备件流1)基本流12)基本流2⏹用例场景(Use-Case Scenario)[ 场景主要是由基本流和备选流组合而成]★成功场景1)成功场景12)成功场景2★失败场景1)失败场景12)失败场景2⏹特殊要求(Special Requirement)[描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）]⏹前置条件(Pre-Condition)[执行用例之前系统必须所处的状态]⏹后置条件(Post-Condition)[用例执行完毕后系统可能处于的一组状态]2、UC2用例名称：活期存款⏹参与者(Actor)[参与者]⏹简要说明(Brief Description)[简要介绍该用例的作用和目的]⏹事件流(Flow of Event) [事件流应该表示出所有的场景]★基本流3)基本流14)基本流1 [把所有的基本流列出来]★备件流3)基本流14)基本流2⏹用例场景(Use-Case Scenario)[ 场景主要是由基本流和备选流组合而成]★成功场景3)成功场景14)成功场景2★失败场景3)失败场景14)失败场景2⏹特殊要求(Special Requirement)[描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）]⏹前置条件(Pre-Condition)[执行用例之前系统必须所处的状态]⏹后置条件(Post-Condition)[用例执行完毕后系统可能处于的一组状态]。

UML期末大作业题目：班级：姓名：学号：目录一、订餐系统中的用例图 (1)1、主管的用例图： (2)2、客户的用例图： (3)3、送餐人员的用例图： (4)4、厨师的用例图： (4)5、系统管理员用例图： (4)二、订餐系统的时序图 (5)1、用户充值时序图： (5)2、客户订餐时序图： (6)3、主管查询时序图： (6)4、菜单更新时序图： (7)三、订餐系统中的类图 (8)1、类图的生成： (8)2、系统中的其它类。

(8)四、订餐系统中的活动图 (10)1、客户的活动图： (10)2、送餐人员的活动图： (11)3、厨师的活动图： (11)4、主管的活动图： (12)五、订餐系统的构件图 (13)1、业务对象构件图： (13)2、用户界面构件图： (14)六、订餐系统的部署图 (15)一、订餐系统中的用例图用例图(Use Case Diagram)在需求分析阶段有很重要的作用，它描述人们希望如何使用一个系统，作为参与者的外部用户所能观察到的系统功能的模型图。

开发的全过程都是围绕需求阶段的用例图进行的。

我们所要开发的订餐系统内容十分丰富，用户包括授权的主管、客户、厨师及送餐人员、未授权的用户以及外部数据库系统，其角色层次图如图4-14所示:未授权用户进人订餐系统后可以浏览系统内的公共资源，如餐馆的基本情况、菜单、新闻等，还可以通过注册系统申请成为授权用户。

授权用户通过订餐系统的身份认证后享有系统规定的资源，主管可以查看一天的销售情况、菜单、顾客的建议、顾客提交的订单、库存；顾客可以查看菜单、向餐馆提出建议、以及订餐等；厨师可以查看顾客提交的订单、顾客提出的建议、菜单、库存等；送餐人员可以查看顾客提交的订单获得地址、菜单等。

外部数据库则主要用于和系统进行数据交换。

经过以上分析得到订餐系统用例模型图如下：作为教学评估系统的参与者有：（1）主管：主管可以登录系统查看一天的销售情况、顾客的建议、顾客提交的订单、以及查看库存、修改菜单等；（2）顾客：查看菜单、向餐馆提出建议、以及订餐等。

UML业务建模实例分析在我国十年前ATM（自动取款机）还是一个很新鲜的事物，现在在城市的大街小巷随处可见。

我们在日常生活中也经常和ATM打交道。

本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。

参与者"银行储户"和ATM机。

简化后的ATM机仅有取款、存款及其余功能。

其余功能不做详细说明。

图5.1 自动取款机（ATM）系统用例图银行储户在ATM机上完成取款、存款及其他业务。

图5.2所示的银行系统类图和图3.5是类似的，只是将工作人员换成了ATM。

整个银行系统包括了帐户库、银行储户库及ATM系统。

许多单个的帐户组成了帐户库。

帐户具有帐户类型、帐户号、余额三个属性，均为private，其类型分别为char，int，double。

六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance为protected其余均为public。

setType设置帐户类型，返回类型为void，参数类型为char，输入帐户类型。

getType获取帐户类型，返回类型为char，无参数。

setAccountNumbe设置帐户号，返回类型为void，参数类型为int，输入帐户号。

getAccountNumbe获取帐户号，返回类型为int，无参数。

caculateBalance计算余额，返回类型为void，参数为double，第一个参数为输入存取款数额，第二个参数为存款余额，既为输入也为输出。

getBalance获取帐户余额，返回类型为double，无参数。

许多银行储户组成了储户库。

ATM系统包含了许多ATM机。

银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。

公司经理银行税务局客户企业员工财务管理进销存管理行政事务管理生产调度管理生产设备管理人力资源管理<<依赖>><<依赖>><<依赖>><<依赖>>见第三章 企业综合信息管理系统最高层用例图销售管理库存管理采购管理<<依赖>><<依赖>>财务管理子系统公司经理生产调度管理子系统企业员工客户见第三章 的2层用例图—进销存管理子系统销售计划规定销售合同管理售后服务管理《依赖》《依赖》财务管理子系统公司经理生产调度管理子系统企业员工客户见第三章 第3层—销售管理子系统修改合同增加销售合同付款单处理履约合同检查打印催款单销售合同查询<<依赖>><<依赖>><<依赖>>公司经理财务管理子系统生产调度管理子系统合同管理员仓库管理员客户见第三章 销售合同管理子系统采购管理销售管理身份验证库存管理<<包含>><<包含>><<包含>>系统管理员见第三章 用例之间的包含关系签订销售合同核对合同核对货物清单制作并发放出库单核对付款单发货合同履约[未付款][缺货][有货][已付款]见第三章 销售合同履约过程活动图：出库单：合同：付款单签订销售合同核对合同核对货物清单核对付款单发货合同履约：出库单：付款单[未付款][缺货][有货][已付款]：合同见第三章 活动图中的对象及对象流执行销售合同制作出库单核对付款单安排发货合同履约发货[已付款=合同总款并且 已发货=合同总发货量][没付款][有货][已付款][无货]见第三章 活动图中的条件线程签订销售合同执行销售合同*合同履约见第三章 描述销售合同从签订到履约的活动态并发活动图核对付款单核对合同排除未付款合同付款累加合同客户未履约合同客户履约[已付款][未付款][付款累加<合同总金额][付款累加=合同总金额]见第三章 “核对付款单”子活动图核对付款单核对合同检查合同订单项排除未付款合同更新库存制作并发放缺货单制作并发放出库单制作并发放生产单[已付款][对每一订单项]*[未付款][有货][缺货]见第三章 检查合同、核对付款单并发放出库单的活动图《Interface 》建立销售合同《Interface 》销售合同查询《Interface 》付款通知单《Interface 》到款通知单《Interface 》催款单合同管理器《Interface 》建立采购合同合同统计表销售合同容器销售合同《Interface 》合同统计表采购合同容器采购合同《Interface 》采购合同查询《Interface 》付款通知单《Interface 》到货通知单《Interface 》催货单管理管理存储存储销售员库房财务客户业务员财务库房客户1111111111**见第四章 合同管理子系统的对象类图合同-合同编号:string -甲方:string-乙方:string-商品名称:string -规格:string 《构造新对象》+合同():购进合同-首付款时间:string -首付款额:double -首到货时间:date -首到货量:double -付款时间2:date-付款额2:double 销售合同-首到款时间:date -首到款额:double -首发货时间:date -首发货量:double -到款时间2:date -至款额2:double见第四章合同的继承关系用户接口出错处理企业综合信息管理系统数据库见第四章与企业综合信息管理系统相关的包财务管理系统《subsystem》进销存管理系统《subsystem》人力资源管理系统《subsystem》生产调度管理系统《subsystem》《资金往来》《使用》《使用》《使用》《使用》见第四章企业综合信息管理系统包含的子系统合同管理系统《subsystem》合同管理器采购合同管理器销售合同容器合同销售合同采购合同合计统计仓库管理系统《subsystem》出入库单管理器出入库单容器入库单容器出库单入库单库存管理器库存单进销存管理子系统保所包含的类。

UML建模案例——超市进销存管理系统超市进销存管理系统是一个重要的信息管理系统，用于管理超市的商品进货、销售和库存情况。

该系统可以帮助超市提高管理效率，减少人力资源的浪费，并使整个进销存流程更加顺畅和高效。

总体描述：超市进销存管理系统主要包括进货管理、销售管理和库存管理三个模块。

进货管理模块用于管理超市的商品进货，包括商品入库、供应商管理和进货单管理。

销售管理模块用于管理超市的商品销售，包括销售单管理和销售统计分析。

库存管理模块用于管理超市的商品库存情况，包括库存盘点和库存报警。

用例图：进货管理模块的用例图包括以下用例：录入商品信息、录入供应商信息、录入进货单、查询供应商、查询进货单、生成进货结算单。

销售管理模块的用例图包括以下用例：录入销售信息、查询销售信息、生成销售结算单、生成销售统计报表。

库存管理模块的用例图包括以下用例：库存盘点、库存报警。

类图：进货管理模块的类图包括以下实体类：商品、供应商、进货单、进货结算单。

销售管理模块的类图包括以下实体类：商品、销售单、销售结算单、销售统计报表。

库存管理模块的类图包括以下实体类：商品、库存盘点单、库存报警。

序列图：进货管理模块的序列图描述了以下过程：录入商品信息、录入供应商信息、录入进货单，以及生成进货结算单。

销售管理模块的序列图描述了以下过程：录入销售信息、生成销售结算单。

库存管理模块的序列图描述了以下过程：库存盘点、库存报警。

状态图：商品的状态图描述了商品的生命周期，包括新增、入库、销售和已报废四个状态之间的转换。

实体关系图：实体关系图描述了商品、供应商、进货单、销售单和库存盘点单之间的关系。

该系统的优点在于可以实现对超市的进货、销售和库存情况进行全面的管理和监控。

通过自动化的数据录入和统计分析，可以减少人工错误和减少劳动力成本。

同时，通过销售统计分析，可以帮助超市制定更加科学的销售策略，提高销售业绩。

另外，库存报警功能可以在库存不足时及时提醒超市进行补充，避免因为库存短缺而影响销售。

UML建⽴类模型⽰例UML建⽴类模型⽰例类模型是⾯向对象分析的核⼼，⽤类图来描述。

类图主要描述系统中类、类与类之间的关系。

1找出类要找出系统中的类，也要⾸先掌握识别类的⽅法，然后再从系统中把类⼀个⼀个找出来。

1.1 怎样找识别类⽐识别⽤例要困难得多。

虽然从理论上说，我们⽣活在⼀个实体世界中，周围的⼀切都是对象，但是识别起来并⾮易事。

因为长期以来，⼈们，特别是程序开发⼈员，在认识世界时总是从功能出发，因⽽反映在头脑⾥的往往是功能⽽不是实体对象。

识别类的⽅法不⽌⼀种，但通常使⽤的识别⽅法是名词识别⽅法。

下⾯，简单介绍⼀下名词识别⽅法。

⼀般来说，描述问题域实体都⽤名词或名词短语。

应⽤名词识别⽅法时，要从系统描述中找出名词、名词短语或名词性代词，它们往往对应着对象(类)。

其中单数名词可以识别为对象，⽽复数名词则可以识别为类。

但是要注意，并不是每个名词都对应着⼀个对象(类)，可能有的名词只是其他对象的⼀个属性，也可能⼏个名词对应着⼀个对象(类)。

找出的名词是否都应该成为系统的对象(类)，有⼀个简单的判断⽅法：考察其是否有与该对象(类)相关的⾝份和⾏为，如果有，那么它就是系统中的⼀个对象(类)。

⾝份指的是⼀个对象的唯⼀标识，正如⼈的⾝份证唯⼀地代表⼀个⼈⼀样。

另外，也可以运⽤⾃⼰的开发经验来识别系统中的类。

在传统的数据库设计中，E.R图中的实体表⽰系统中的持久的元素，要映射为数据库中的数据表。

UML中的实体也表⽰系统中的持久的元素。

两者的区别在于，UML中的实体除表⽰系统中的持久的元素外，还具有⾏为特性——操作。

因此，如果UML初学者识别类时开始有困难，不妨⾸先找出系统中E—R图中的实体，即系统中的持久的元素，然后参照E.R图中的实体去定义UML中的实体。

1.2找出类现在，采⽤名词识别⽅法来识别系统实例中的类。

第⼀步，从系统描述中找出⽤来描述问题域实体的名词。

根据9.1节对系统的描述，可以得到以下⼀些名词：企业、家⽤电器、市场竞争⼒、公司、创新基⾦、产品、管理部门、决策信息、创新基⾦管理信息系统、新系统、票据、⼈⼯处理⽅式、开发计划、研究项⽬、财务室、项⽬开⽀的经费、报销⼈、公司财务报销规定、汽油票⾦额、发票的⾦额、飞机票、项⽬经费总额、招待费、财务档案、⽤户、报表、系统资源、公司领导。

实训3 绘制UML的各种图形
一、实验目的要求和注意事项
练习各类UML图的画法。

二、实验主要内容
1、运行visio，熟悉其工作界面。

2、绘制各类UML图。

三、实验仪器设备
微机：每人一台
四、实验步骤
1、运行Visio，熟悉其工作界面。

2、学习UML图的常用符号。

3、结合例题绘制各类UML图。

五、相关知识
（1）状态图
（2）活动图
六、具体任务
任务1绘制状态图：门有opened、closed、locked三种状态，请绘制门的状态图。

任务2绘制状态图：电水壶：on和off两个状态，初态off，烧坏则转换到终态。

trunOn 事件发生时，判断水壶是否有水，若没有水，则仍处于off状态，若有水，则turnOn事件引起烧水活动，使状态从off转入on，水开，则从on转入off状态。

任务3绘制活动图：学生请假活动图
1、学生请假须先经过班主任同意；
2、班主任在准假时，如学生请假时间超越审批权限，还要请系办审批，经系办审批后，系办将假条存根留下，事后转班主任存查；
3、学生请假获准后，应立刻报告班长，以便班长向任课教师报告。