下载文档原格式
UML各种图例面向对象的问题的处理的关键是建模问题.建模可以把在复杂世界的许多重要的细节给抽象出.许多建模工具封装了UML（也就是Unified Modeling Language ™），这篇课程的目的是展示出UML的精彩之处.UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接.而且每个部分都有一个小问题，测试一下你对这个部分的理解.为什么UML很重要?为了回答这个问题，我们看看建筑行业.设计师设计出房子.施工人员使用这个设计来建造房子.建筑越复杂，设计师和施工人员之间的交流就越重要.蓝图就成标准文档为了这个行业中的设计师和施工人员的必修课.写软件就好像建造建筑物一样.系统越复杂，参与编写与配置软件的人员之间的交流也就越重要.在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”.现在它已经成为了软件行业的一部分了.UML提供了分析师，设计师和程序员之间在软件设计时的通用语言.UML被应用到面向对象的问题的解决上.想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的.一个模型model就是根本问题的抽象.域domain就是问题所处的真实世界.模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的.记住把一个对象想象成“活着的”.对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）.对象的属性的值决定了它的状态state.类Classes是对象的“蓝图”.一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）.对象是类的实例instances.用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象.强调这个系统是什么而不是这个系统怎么工作.用例图与情节紧紧相关的.情节scenario是指当某个人与系统进行互动时发生的情况.下面是一个医院门诊部的情节.“一个病人打电话给门诊部预约一年一次的身体检查.接待员找出在预约记录本上找出最近的没有预约过的时间，并记上那个时间的预约记录.”用例Use case是为了完成一个工作或者达到一个目的的一系列情节的总和.角色actor是发动与这个工作有关的事件的人或者事情.角色简单的扮演着人或者对象的作用.下面的图是一个门诊部Make Appointment用例.角色是病人.角色与用例的联系是通讯联系communication association（或简称通讯communication）标准文档角色是人状的图标，用例是一个椭圆，通讯是连接角色和用例的线.一个用例图是角色，用例，和它们之间的联系的集合.我们已经把Make Appointment作为一个含有四个角色和四个用例的图的一部分.注意一个单独的用例可以有多个角色.用例图在三个领域很有作用.决定特征（需求）.当系统已经分析好并且设计成型时，新的用例产生新的需求标准文档∙客户通讯.使用用例图很容易表示开发者与客户之间的联系.∙产生测试用例.一个用例的情节可能产生这些情节的一批测试用例.类图类图Class diagram通过显示出系统的类以及这些类之间的关系来表示系统.类图是静态的－它们显示出什么可以产生影响但不会告诉你什么时候产生影响.下面是一个顾客从零售商处预定商品的模型的类图.中心的类是Order.连接它的是购买货物的Customer和Payment.Payment有三种形式：Cash，Check，或者Credit.订单包括OrderDetails（line item），每个这种类都连着Item.标准文档UML类的符号是一个被划分成三块的方框：类名，属性，和操作.抽象类的名字，像Payment是斜体的.类之间的关系是连接线.类图有三种关系.关联association－表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中，关联用两个类之间的连线表示.标准文档标准文档为了简单地表示出复杂的类图，可以把类组合成包packages.一个包是UML上有逻辑关系的元件的集合.下面这个图是是一个把类组合成包的一个商业模型.dependencies关系.如果另一个的包B改变可能会导致一个包A改变，则包A依赖包B.包是用一个在上方带有小标签的矩形表示的.包名写在标签上或者在矩形里面.点化线箭头表示依赖对象图Object diagrams用来表示类的实例.他们在解释复杂关系的细小问题时（特别是递归关系时）很有用.这个类图示一个大学的Department可以包括其他很多的Departments.标准文档这个对象图示上面类图的实例.用了很多具体的例子.UML中实例名带有下划线.只要意思清楚，类或实例名可以在对象图中被省略.标准文档每个类图的矩形对应了一个单独的实例.实例名称中所强调的UML图表.类或实例的名称可能是省略对象图表只要图的意义仍然是明确的.顺序图类图和对象图是静态模型的视图.交互图是动态的.他们描述了对象间的交互作用.顺序图将交互关系表示为一个二维图.纵向是时间轴，时间沿竖线向下延伸.横向轴代表了在协作中各独立对象的类元角色.类元角色用生命线表示.当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线.消息用从一个对象的生命线到另一个对象生命线的箭头表示.箭头以时间顺序在图中从上到下排列.标准文档协作图协作图也是互动的图表.他们像序列图一样也传递相同的信息，但他们不关心什么时候消息被传递，只关心对象的角色.在序列图中，对象的角色放在上面而消息则是连接线.标准文档对象角色矩形上标有类或对象名（或者都有）.类名前面有个冒号（：）.协作图的每个消息都有一个序列号.顶层消息的数字是1.同一个等级的消息（也就是同一个调用中的消息）有同样的数字前缀，再根据他们出现的顺序增加一个后缀1，2等等.状态图对象拥有行为和状态.对象的状态是由对象当前的行动和条件决定的.状态图statechart diagram显示出了对象可能的状态以及由状态改变而导致的转移.标准文档我们的模型例图建立了一个银行的在线登录系统.登录过程包括输入合法的密码和个人账号，再提交给系统验证信息.登录系统可以被划分为四种不重叠的状态：Getting SSN, Getting PIN, Validating, 以及 Rejecting.每个状态都有一套完整的转移transitions来决定状态的顺序.标准文档状态是用圆角矩形来表示的.转移则是使用带箭头的连线表示.触发转移的事件或者条件写在箭头的旁边.我们的图上有两个自转移.一个是在Getting SSN，另一个则在上Getting PIN.初始状态（黑色圆圈）是开始动作的虚拟开始.结束状态也是动作的虚拟结束.事件或条件触发动作时用（/动作）表示.当进入Validating状态时，对象并不等外部事件触发转移.取而代之，它产生一个动作.动作的结果决定了下一步的状态.活动图活动图activity diagram是一个很特别的流程图.活动图和状态图之间是有关系的.状态图把焦点集中在过程中的对象身上，而活动图则集中在一个单独过程动作流程.活动图告诉了我们活动之间的依赖关系.对我们的例子来说，我们使用如下的过程.“通过ATM来取钱.”这个活动有三个类Customer, ATM和 Bank.整个过程从黑色圆圈开始到黑白的同心圆结束.活动用圆角矩形表示.标准文档标准文档标准文档。
产品需求文档的写作(五) –用例文档(UML用例图、流程图)在产品和技术领域里都有UML的技能知识，而对于产品人员的UML则更多的是指用例图，也就是我所称呼的用户流程图。
在讲PRD文档写作的第二篇文章里，我提到了用户流程图的制作，实际上用户流程图是我在产品规则的初期对用例图的一种结构化的表达方式，由于以结构化的方式描述用例太抽象，缺少逻辑性表达，并且那篇文章更偏向于功能性用户流程，还不是实际意义上的用例，因此今天我补文一篇，细讲一下UML用例图和用例文档。
用例文档是由多个用例组成的一份文档，主要用于技术开发与测试使用，他是PRD中的重要辅助文档，用于讲解某个环节的功能逻辑，例如用户注册、活动报名等等功能都是需要用例辅助说明的。
用例文档的写作时间在原型设计之后，通常和PRD文档同步撰写。
用例文档中有两个关联文件，分别是用例图和流程图。
用例图是UML的一种类图表现方式，是从用户角度描述产品功能，并指出该用户在产品各功能中的操作权限。
流程图是通过线框图形的方式描述产品功能的处理过程，主要是描述功能的执行顺序、分支和循环的逻辑。
写用户文档的常用软件是Word，其中用例图和流程图的制作软件常用的是Visio，当然也有用Axure RP软件制作的，例如下面的第三步流程图就是用Axure RP制作的。
一份完整的用例文档分别是由以下三点内容组成，其中第3点的“用例”是描述功能逻辑的部分，根据功能的多少决定有多少个用例。
用例文档的大概组成部分如下：1、修改记录：每次修改的备注记录，同PRD文档。
2、角色介绍：描述参与系统中的各个角色3、用例：同下方步骤的第4步，其中第3步中的流程图是直接插入到第4步的流程图表格项中的。
用例文档的模板格式如同以上三点内容，通过Word文档绘制表格，在表格中撰写用例描述，表格的格式和样式参考以下示例图。
1、撰写用例文档的第一步是注明使用产品的各个角色(参与者)和角色说明(角色介绍)。
图书借阅系统用例分析1。
用户采用用例图描述的图书借阅系统主要包括三类用户:读者、图书管理员、系统管理员。
其中，读者是多个，图书管理员是几个，系统管理员是一个。
1.1读者描述：读者可以借阅、预约、续借、归还图书，可以对书籍和个人信息进行查询，可以取消预约，可以提出办理图书借阅证的申请。
示例:持有图书借阅证的任何人。
1.2图书管理员描述：图书管理员对图书信息维护，包括图书订购、新书入库、破损修补、旧书下架，另外还对读者信息进行管理，进行借阅登记等.示例：图书管理员1。
3系统管理员描述：系统管理员对系统进行维护，包括读者信息的创建、修改、删除,日志维护，权限维护,后台数据维护，还有系统信息的维护。
示例：系统管理员2.用例通过识别的参与者，对需求进一步分析，将业务需求进行分解，获得每个参与者的使用用例：2.1读者（1)读者办卡:提供为读者办理借书证的功能（2）书籍查询：为读者提供书籍查询功能(3）书籍借阅:提供借阅书籍的功能（4)书籍续借：提供续借书籍的功能（5）书籍预约：提供对某一书籍的预约功能（6）取消预约：提供对预约进行取消的功能（7）书籍归还:提供归还书籍的功能（8）读者信息查询：为读者提供个人信息查询的功能（9）缺书登记：当读者需要的书籍查询书库没有记录时，读者可将此书进行缺书登记2.2图书管理员（1）图书信息维护图书订购：参考各类图书的库存数和借阅率及缺书登记,对书籍进行统一采购新书入库：将新书到货进行编号入库书籍破损修补：当书籍有损坏时进行修补旧书下架：将遗失或淘汰的书籍从书库中清除（2)读者信息管理(3）借阅书籍登记2。
3系统管理员（1）系统维护：维护图书借阅系统的系统结构(2）日志维护：维护系统中各种日志，如借阅记录、书籍记录等(3）权限维护：确定系统各参与者的权限，维护相关权限（4)增删用户：增加或者删除用户及相关信息（5）后台数据维护:维护系统后台数据库中的各种数据3。
用例图3。
1用例说明4 类图在用例分析基础之上，根据需求可建立起系统的静态数据模型，即建立系统类图。
UML实践----用例图、顺序图、状态图、类图、包图、协作图2009-01-20 作者：Randy Miller 来源：网络面向对象的问题的处理的关键是建模问题。
建模可以把在复杂世界的许多重要的细节给抽象出。
许多建模工具封装了UML（也就是Unified Modeling Language™），这篇课程的目的是展示出UML的精彩之处。
UML中有九种建模的图标，即：∙用例图∙类图∙对象图∙顺序图∙协作图∙状态图∙活动图∙组件图∙配置图本课程中的某些部分包含了这些图的细节信息的页面链接。
而且每个部分都有一个小问题，测试一下你对这个部分的理解。
为什么UML很重要？为了回答这个问题，我们看看建筑行业。
设计师设计出房子。
施工人员使用这个设计来建造房子。
建筑越复杂，设计师和施工人员之间的交流就越重要。
蓝图就成为了这个行业中的设计师和施工人员的必修课。
写软件就好像建造建筑物一样。
系统越复杂，参与编写与配置软件的人员之间的交流也就越重要。
在过去十年里UML就成为分析师，设计师和程序员之间的“建筑蓝图”。
现在它已经成为了软件行业的一部分了。
UML提供了分析师，设计师和程序员之间在软件设计时的通用语言。
UML被应用到面向对象的问题的解决上。
想要学习UML必须熟悉面向对象解决问题的根本原则――都是从模型的建造开始的。
一个模型model就是根本问题的抽象。
域domain就是问题所处的真实世界。
模型是由对象objects组成的，它们之间通过相互发送消息messages来相互作用的。
记住把一个对象想象成“活着的”。
对象有他们知道的事（属性attributes）和他们可以做的事（行为或操作behaviors or operations）。
对象的属性的值决定了它的状态state。
类Classes是对象的“蓝图”。
一个类在一个单独的实体中封装了属性（数据）和行为（方法或函数）。
对象是类的实例instances。
用例图用例图Use case diagrams描述了作为一个外部的观察者的视角对系统的印象。
UML用例图的主要元素解析与使用方法UML（Unified Modeling Language）是一种用于软件系统建模的标准化语言，用例图是UML的一种图表类型，用于描述系统的功能需求和用户与系统之间的交互。
在软件开发过程中，用例图是非常重要的工具，它能够帮助开发团队更好地理解系统需求，设计出更合理的系统架构。
本文将对UML用例图的主要元素进行解析，并介绍其使用方法。
一、参与者（Actors）参与者是指与系统进行交互的实体，可以是人、其他系统或外部设备。
在用例图中，参与者用一个小人的图标表示。
参与者与系统之间通过用例进行交互。
一个参与者可以在多个用例中出现，也可以在一个用例中有多个参与者。
二、用例（Use Cases）用例是对系统功能的描述，它表示系统为参与者提供的一项功能或服务。
用例图中，用例用一个椭圆形图标表示。
每个用例都有一个名称，通常使用动词短语来描述功能。
用例之间可以有关系，如包含关系（include）、扩展关系（extend）等。
三、关系（Relationships）在用例图中，参与者与用例之间可以有不同类型的关系，如关联关系（association）、包含关系（include）、扩展关系（extend）等。
关联关系表示参与者与用例之间的关联，包含关系表示一个用例包含另一个用例，扩展关系表示一个用例可以扩展另一个用例。
四、系统边界（System Boundary）系统边界是用于表示系统的边界，用一个矩形框表示。
在用例图中，系统边界将参与者和用例包围在内，表示系统的范围和边界。
五、泛化（Generalization）泛化是一种继承关系，用于表示两个用例之间的继承关系。
在用例图中，泛化关系用一个带有箭头的实线表示，箭头指向父用例。
六、扩展点（Extension Points）扩展点用于表示一个用例可以被扩展的地方。
在用例图中，扩展点用一个小圆圈表示，并与扩展用例之间用虚线连接。
使用UML用例图进行系统建模时，需要按照以下步骤进行：1. 确定参与者：首先，需要确定系统中的参与者，包括用户、其他系统或外部设备。
UML中的用例与类图之间的关联关系UML（Unified Modeling Language）是一种用于软件系统建模的标准化语言，它提供了一套丰富的图形符号和规范，用于描述和设计软件系统的结构和行为。
在UML中，用例图和类图是两个重要的建模工具，它们分别用于描述系统的功能需求和结构设计。
本文将探讨用例图和类图之间的关联关系，以及它们在软件开发过程中的应用。
一、用例图的作用和特点用例图是一种用于描述系统功能需求的图形表示方法。
它通过用例（Use Case）和参与者（Actor）之间的关系来描述系统的功能和行为。
用例图可以帮助开发团队和用户明确系统的功能需求，从而指导软件系统的开发和测试工作。
用例图的特点在于它强调系统与外部参与者之间的交互关系。
一个用例表示系统的一个功能需求，而参与者则表示与系统进行交互的外部实体，如用户、系统管理员等。
用例图通过箭头来表示参与者和用例之间的关系，例如，一个参与者可以执行多个用例，一个用例也可以被多个参与者执行。
二、类图的作用和特点类图是一种用于描述系统结构设计的图形表示方法。
它通过类（Class）、关联（Association）、继承（Inheritance）等元素来描述系统中的对象和它们之间的关系。
类图可以帮助开发团队明确系统的结构和组织，从而指导软件系统的设计和实现工作。
类图的特点在于它强调系统中对象之间的关联关系。
一个类表示系统中的一个对象，而关联则表示对象之间的关系。
类图通过线条和箭头来表示类和关联之间的关系，例如，一个类可以关联到另一个类，表示它们之间存在某种关联。
类图还可以使用继承关系来描述类之间的层次结构，例如，一个类可以继承自另一个类，表示它们之间存在父子关系。
三、用例图和类图的关联关系用例图和类图之间存在着紧密的关联关系。
用例图描述了系统的功能需求，而类图描述了系统的结构设计。
用例图中的用例可以通过类图中的类来实现，从而满足系统的功能需求。
具体来说，用例图中的用例可以通过类图中的类的操作来实现。
银行系统UML 图一、用例图1.银行职员用例图登录管理账户修改账户2.客户与银行职员用例图Bank取款转账二、类图holder:String number:int type:Stringname:String ID:int数目：日期：数目：日期：ID:intname:String数目：日期：三、时序图1.登录时序图:LoginForm :MainForm Clerk2.创建登录对话框4.系统身份验证5.通过创建主界面2.存款时序图Clerk:MainForm:WithdrawForm:Account:Deposit2.请求存款操作3.修改账户时序图Clerk:LoginForm:QueryForm:AccountForm:Customer:Account1.进入主界面2.请求查询账户3.创建查询界面4.提交账号5.获得指定账户的信息6.创建账户界面7.修改账户信息8.更新账户信息9.更新账户信息Clerk:LoginForm :QueryFormCreateAccountAccount:Customer四、活动图1.银行职员登录活动图提示错误信息验证信息进入主界面N2.取款活动图验证账户是否存在且有效修改账户信息保存交易记录创建交易记录不存在或无效3.转账活动图提示错误信息验证账户是否存在且有效创建交易记录保存交易记录修改账户信息通知另一银行五、状态图六、协作图1.修改账户协作图提示错误信息验证账户是否存在且有效创建交易记录保存交易记录修改账户信息通知另一银行2.删除账户协作图Clerk:QueryForm:LoginForm七、系统组件图八、系统部署图。
《UML面向对象分析》课程实践项目报告项目名称：网上订购火车票系统项目组成员：学号：班级：指导教师：2008年 11 月 10 日目录1 需求分析 (1)1.1 需求概述 (1)1。
2 ................................... 需求分析11.3 需求模型（用例图） (5)2 静态模型 (6)2.1 类图 (6)2.2 对象图 (8)2.3 包图 (9)3 动态模型 (11)3。
1 ..................................... 时序图113.2 状态图 (13)3。
3 ..................................... 协作图143.4 活动图 (15)4 项目组成员分工说明 (16)5 总结 (17)6 参考资料 (18)1需求分析1.1 需求概述线上预订火车票系统是一款功能强大、操作简便、易维护的、具有良好人机交互界面的线上订票系统，它包括用户管理模块、系统参数设置模块、票务信息模块（提供票价、列车的实时信息）、订票管理模块（提供订票和退订功能）、实时信息提示模块(提供车况、路况、列车晚点等实时信息）、数据管理模块（提供数据备份、数据操作功能)。
实现火车票线上预定的自动化的计算机系统，为旅客提供准确、精细、迅速的火车票销售信息和方便、简单的订票功能。
线上预订火车票系统主要是对于订票信息的统一管理，满足了中小型线上订票网站对于用户的管理，订票信息的收集和处理方面的要求。
用现代化的方式取代以前的传统模式，更有利于信息的流通,资源的宏观管理。
具有体积小,代码简洁，易维护、易修改的优点.1.2 需求分析用户管理模块用户管理模块包括如下几个部分。
（1）添加用户信息：管理员可以对用户信息进行添加操作。
（4）修改用户信息权限：管理员可以修改用户的管理权限.（5）删除管理权限：管理员在权限管理中可以删除管理权限。
（6）添加管理权限：管理员在权限管理中可以添加管理权限。
2.设计模式常⽤的UML图分析（⽤例图、类图与时序图）1-⽤例图概述1. 展现了⼀组⽤例、参与者以及他们之间的关系。
2. ⽤例图从⽤户⾓度描述系统的静态使⽤情况，⽤于建⽴需求模型。
⽤例特征保证⽤例能够正确捕捉功能性需求，判断⽤例是否准确的依据。
1. ⽤例是动宾短语2. ⽤例是相互独⽴的3. ⽤例是由⽤户参与者启动的4. ⽤例要有可观测的执⾏结果5. ⼀个⽤例是⼀个单元参与者 ActorUML中，参与者使⽤⼀个⼩⼈表⽰:1. 参与者为系统外部与系统直接交互的⼈或事务，于系统外部与系统发⽣交互作⽤2. 参与者是⾓⾊⽽不是具体的⼈3. 代表参与者在与系统打交道时所扮演的⾓⾊4. 系统实际运作中，⼀个实际⽤户可能对应系统的多个参与者。
不同⾓⾊也可以只对应⼀个参与者，从⽽代表同⼀参与者的不通实例⽤例 Use Case系统外部可见的⼀个系统功能单元。
系统的功能由系统单元所提供，并通过⼀系列系统单元与⼀个或多个参与者之间交换的消息所表达。
系统单元⽤椭圆表⽰，椭圆中的⽂字简述系统功能:关系 Relationship常见关系类型有关联、泛化、包含和扩展关联 Association表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。
箭头指向：指向消息接收⽅：⼦系统 SubSystem⽤来展⽰系统的⼀部分功能(紧密联系)泛化 Inheritance继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。
⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。
⽗⽤例通常是抽象。
箭头指向：指向⽗⽤例2-类图描述系统中的类，以及各个类之间的关系的静态试图。
表⽰类、接⼝以及它们之间的协作关系，⽤于程序设计阶段。
注意:1. 抽象类或抽象⽅法⽤斜体表⽰2. 如果是接⼝，则在类名上⽅加 <<Interface>>3. 字段和⽅法返回值的数据类型⾮必需4. 静态类或静态⽅法加下划线类图实例:类图中的事务及解释如图，类图从上到下分为三部分,分别为类名、属性和操作1. 属性:如果有属性，则每⼀个属性都必须有⼀个名字，另外还可以有其它的描述信息，如可见性、数据类型、缺省值等2. 操作:如果有操作，则每⼀个操作也都有⼀个名字，其它可选的信息包括可见性、参数的名字、参数类型、参数缺省值和操作的返回值的类型等类图中的六种关系1.实现关系 implements (类实现接⼝)⽤空⼼三⾓虚线表⽰2.泛化关系 extends (表⽰⼀般与特殊的关系) is-a⽤空⼼三⾓实线表⽰3.组合关系 (整体与部分的关系) contains-a实⼼菱形实现表⽰eg.有头类、⾝体类与⼈类类三个类，则⼈类类中应包含头类及⾝体类这两个属性，则⼈类类与头类和⾝体的关系即为组合关系。
UML中各种图的画法(全)UML中各种图的画法(全)一、UML中基本的图范畴：在 UML 2 中有二种基本的图范畴：结构图和行为图。
每个 UML 图都属于这二个图范畴。
结构图的目的是显示建模系统的静态结构。
它们包括类，组件和（或）对象图。
另一方面，行为图显示系统中的对象的动态行为，包括如对象的方法，协作和活动之类的内容。
行为图的实例是活动图，用例图和序列图。
二、UML中的类图：1.类图的表示：类的 UML 表示是一个长方形，垂直地分为三个区，如图 1 所示。
顶部区域显示类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的（当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的）。
描述：顶部区域显示类的名字。
中间的区域列出类的属性。
底部的区域列出类的操作。
当在一个类图上画一个类元素时，你必须要有顶端的区域，下面的二个区域是可选择的（当图描述仅仅用于显示分类器间关系的高层细节时，下面的两个区域是不必要的）。
·类名：如果是抽象类，则采用斜体·类属性列表：name : attribute type 如 flightNumber : Integer，这是最常见的表达形式n ame : attribute type = default value 如balance : Dollars = 0，这是带有默认值的表达形式·类方法列表：name(parameter list) : type of value returned注意：在业务类图中，属性类型通常与单位相符，这对于图的可能读者是有意义的（例如，分钟，美元，等等）。
然而，用于生成代码的类图，要求类的属性类型必须限制在由程序语言提供的类型之中，或包含于在系统中实现的、模型的类型之中。
2.继承的表示：为了在一个类图上建模继承，从子类（要继承行为的类）拉出一条闭合的，单键头（或三角形）的实线指向超类。
UML九种图之⽤例图和类图前⾔近期写UML⽂档，看视频的时候感觉掌握的还能够，当真正写⽂档的时候才发现不是⼀件easy的事。
写⽂档⾃⼰⼜翻开⾃⼰的笔记看了⼀遍⼜⼀遍。
以下就给⼤家介绍⼀下我画的⼏张图：⽤例图1. ⽤例图的构成（⽤例，⾓⾊，关系）⽤例：指功能的描写叙述⾓⾊：触发起某种事件关系：⽤例图的关系（依赖，泛化，关联）2. ⽤例图的作⽤（1）⽤例视图是整个UML设计的关键，影响到整个UML设计的过程（2）⽤例模型驱动了需求分析后各个阶段的开发（3）⽤例模型⽤于需求分析阶段，表明了开发⼈员和⽤户针对需求达成的某种共识注意⼏个keyword：开发⼈员，⽤户，共同商讨达成某种共识3.设计原则将系统看做⿊盒⼦，从⽤户⾓度理解系统，不须要考虑某个功能是怎样实现的。
仅仅须要考虑系统由谁来运⾏和怎样交互和运⾏。
以下是我画的⽤例图：以⽤户的权限为基础画出来的。
类图1.类图的构成类、接⼝、协作、关系、包2.类的构成2.类图的作⽤类图⼀般在具体设计过程中出现，主要⽤来描写叙述系统中各个模块中类之间的关系，包含类或者类与接⼝的继承关系，类之间的依赖、聚合等关系。
通过类图，就能实际的把系统中的各个类，即对象描写叙述清楚，下⼀步就是依照这个具体的设计编码了。
3.类图的设计Use case——>class（要点，抽象名词得到类）——>确定类的属性和⽅法——>属性是静态⾏为描写叙述，⽅法是动态⾏为的描写叙述——>正确表达类与类之间的关系以下是我对机房收费系统设计的类图，理解的不是⾮常清楚，可定存在诸多问题，希望⼤家积极指正。
以上是我看完UML之后对⽤例图和类图的理解，感觉理解的不是⾮常清楚，若有什么问题希望⼤家积极指正。
