UML各种图详解
UML图（类图）各元素解释
UML图（类图）各元素解释
普通类图
属性/⽅法的表⽰其实都是： 符号属性名/⽅法名: 返回类型
符号：+(public) 公开⽅法及属性; -(private) 私有⽅法及属性; #(protected) protected⼀样的效果属性名/⽅法名: 说⽩了就是属性名或者⽅法名的名称，如果是⽅法的话，要多个()，内容就是参数类型返回类型: ⽅法独有的，没返回值的话写voide即可，有返回值就写上相对应的返回值的类型
若要表⽰是接⼝的话， 在类名上⽅加上 <<interface>> 即可
关联类型
单向关联
单实⼼箭头实线： 说明的是A关联了B，A对象中持有B对象
双向关联
⽆箭头实线：说明是A和B对象互相关联，A持有B对象，B也持有A对象⾃关联
指向⾃⾝的单实⼼箭头：表明是A对象持有了A对象
实现接⼝
虚线空⼼箭头：说明B实现了A接⼝
泛化关系
实线空⼼箭头：说明B继承了A。
UML各种图例齐全—用例图、类图、状态图、包图、协作图、顺序图详细说明画法和功能
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－表示两种类的实例间的关系.如果一个类的实例必须要用另一个类的实例才能完成工作时就要用关联.在图中，关联用两个类之间的连线表示.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（也就是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类图，常用符号小计1、首先看该图中的动物矩形框，它代表的是一个类，类图分三层，第一层是类名（动物），第二层是特性（通常我们说的属性或是字段），第三层是操作（通常我们说的方法或行为），注意特性和操作前面的+，“+”代表public，“-“代表private，“#”代表protected。
在这里需要注意一下，动物类的名称是斜体，这就表示该类是抽象类。
同样的鸟类也是抽象类。
2、再看左下角的飞翔，它是一个接口图，与类图的不同就在于，顶部有一个<<interface>>，第一行是接口名称，第二行是接口方法。
接口还有一种表示方法是棒棒糖表示法，如图中的唐老鸭实现讲人话的接口。
3、鸟继承自动物类，鸭继承自鸟类，唐老鸭又继承自鸭类，继承的关系用空心三角形+实线来表示。
4、大雁实现了飞行的接口，接口用虚线+空心三角来实现5、企鹅需要了解天气情况，气候的变化，那么如果一个类“知道”另一个类时，可以用关联(association)。
关联关系要用实线箭头来表示6、一个雁群可以包括很多只雁，但雁并不是雁群的一部分，像这样的关系就满足聚合(aggregation)关系，聚合是一种弱的拥有关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分。
聚合关系用空心菱形+实线表示。
7、合成(composition)是一种强的拥有关系，体现的严格的部分与整的关系，部分和整的生命周期一样。
上图中鸟和翅膀就是合成的关系，其中图中标注的1，2被称为基数。
表明这一端的类可以有多个实例，鸟肯定是两个翅膀喽，一个是没法飞的，哈哈。
8、动物与氧气、水之间是依赖的关系，没有氧气和水，动物（当然也包括人）根本是无法生存的，所以嘛。
不管是动物还是植物还是高级动物人也好，都要依赖于氧气和水的，依赖（dependency)关系，用虚线箭头来表示。
或许还有好多好多其他的常用符号，欢迎朋友们和我一起沟通。
UML中的活动图和状态图的区别与实际应用案例解析
UML中的活动图和状态图的区别与实际应用案例解析UML（Unified Modeling Language）是一种用于软件系统建模的标准化语言，它提供了一套丰富的图形符号和规范，帮助开发人员更好地理解和设计软件系统。
在UML中，活动图和状态图是两种常用的图形表示方式，用于描述系统中的活动流程和对象状态。
本文将探讨这两种图形的区别，并通过实际应用案例来解析它们的具体应用。
活动图是一种用于描述系统中活动流程的图形表示方式。
它主要由活动（Action）、控制流（Control Flow）和决策节点（Decision Node）等元素组成。
活动图可以清晰地展示系统中的各种活动以及它们之间的关系和顺序。
活动图通常用于描述业务流程、系统交互和软件系统中的算法等。
例如，在一个在线购物系统中，我们可以使用活动图来描述用户选择商品、添加到购物车、填写订单信息、确认支付等流程。
通过活动图，我们可以更好地理解和设计系统中的各个步骤，从而提高系统的可靠性和可维护性。
与活动图相比，状态图主要用于描述系统中对象的状态和状态之间的转换。
状态图由状态（State）、转移（Transition）和事件（Event）等元素组成。
状态图可以清晰地展示对象在不同状态之间的转换和触发条件。
状态图通常用于描述系统中的状态机、对象的生命周期和系统中的并发操作等。
例如，在一个自动售货机系统中，我们可以使用状态图来描述售货机的工作状态，如待机状态、售货状态和故障状态等。
通过状态图，我们可以更好地理解和设计系统中对象的状态变化，从而提高系统的可靠性和性能。
活动图和状态图在应用上有一些区别。
活动图主要用于描述系统中的活动流程，强调活动之间的顺序和关系。
它更适合于描述系统中的业务流程和交互流程等。
而状态图主要用于描述系统中对象的状态和状态之间的转换，强调对象状态的变化和触发条件。
它更适合于描述系统中的状态机和对象的行为。
下面通过一个实际应用案例来进一步解析活动图和状态图的具体应用。
UML用例图的基本概念
UML的用途
需求分析
UML可以帮助开发人员更好地理 解客户需求，通过用例图等工具 将客户需求转化为可执行的用例。
系统设计
UML可以帮助开发人员在系统设 计阶段进行系统架构和组件的设 计，通过类图、时序图等工具进 行系统的分析和设计。
05
案例分析
案例一：简单登录系统用例图分析
总结词：简单明了
详细描述：简单登录系统通常包括用户名和密码输入、验证和登录成功或失败的反馈等基本功能。在 UML用例图中，可以清晰地表示出系统的主要功能和参与者的角色。
案例二：网上购物系统用例图分析
总结词：复杂多样
详细描述：网上购物系统涉及到多个参与者，如顾客、管理员和供应商等，以及多种复杂的业务功能，如商品展示、购物车 管理、订单处理和支付等。在UML用例图中，需要对各个功能进行详细的描述和分类，以便更好地理解系统的结构和功能。
用例图在系统设计中的应用
架构设计
用例图可以用于指导系统的架构设计，通过分析用例之间 的关系和交互，设计系统的组件和模块结构。
01
接口设计
用例图可以帮助设计系统组件之间的接 口，明确组件之间的输入输出关系和交 互协议。
02
03
系统流程设计
用例图可以用于描述系统的流程，通 过分析用例的执行顺序和交互逻辑， 设计系统的流程和顺序结构。
用例图在需求分析中的应用
1 2
沟通工具
用例图作为一种可视化图形表示，可以作为沟通 工具，帮助开发团队、客户和利益相关者理解系 统的需求和功能。
需求确认
通过绘制用例图，可以与利益相关者讨论和确认 系统的需求，确保对需求的理解和期望是一致的。
UML中共有5种静态图
UML中共有5种静态图：用例图，类图，对象图，组件图和配置图。
（1）用例图Use Case Diagram用例图展现了一组用例、参与者以及它们之间的关系可以用来描述系统的静态使用情况。
上图中小人形状的用户和ATM是参与者、椭圆形状的如插入卡、输入密码等是用例（2）类图Class Diagram类图展示了一组类、接口、子类以及他们之间的关系，在建模中最常用到的图就是类图；可以用类图说明系统的静态设计视图，包含主动类的类图。
上图中反应了5个类之间的关联关系，人民币账户和美元帐户从账户继承，账户和ATM相关联，两种账户和用户相关联（3）对象图Object Diagram对象图展示了一组对象和他们间的关系，可以用来说明类图中翻译的事物实例的数据结构和静态快照，表达了系统的静态设计视图和静态过程视图，除了显示和原型方面的因素外，它与类图的作用是相同的。
（4）组件图Component Diagram组件图，又名构件图，展现了一组组件之间的组织和依赖，用于对源代码、可执行的发布、物理数据库和可调整的系统建模。
上图中组件1和组件3依赖于组件2（5）配置图Deployment Diagram配置图展现了对运行时处理节点以及其中组件的配属，它描述系统硬件的物理拓扑结构，以及在此结构上执行的软件。
用配置图说明系统结构的静态配置视图，即说明分布、交互和安装的物理系统。
上图中，三个处理机与两个涉笔，相互之间是关联的关系UML中动态图有四种，分别是：时序图、协作图、状态图和活动图。
（1）时序图Sequence Diagram时序图展现了一组对象和由这组对象收发的信息，用于按时间顺序对控制流建模。
可以用时序图来说明系统的动态视图。
这里貌似有不同的说法Visual Paradigm里面叫时序图为Timing Diagram，而我参照的教材里边没有这种图，按理说是应该有的。
上图反应了用户与ATM交互的整个过程。
（2）协作图Collaboration Diagram协作图展现了一组对象之间的链接以及这组对象收发的消息，强调收发消息对象的组织结构，按组织结构对控制流建模。
UML序列图总结
UML序列图总结序列图主要用于展示对象之间交互的顺序。
序列图将交互关系表示为一个二维图。
纵向是时间轴，时间沿竖线向下延伸。
横向轴代表了在协作中各独立对象的类元角色。
类元角色用生命线表示。
当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。
消息用从一个对象的生命线到另一个对象生命线的箭头表示。
箭头以时间顺序在图中从上到下排列。
序列图中涉及的元素：1.生命线：生命线名称可带下划线。
当使用下划线时，意味着序列图中的生命线代表一个类的特定实体。
2.同步消息发送人在它继续之前，将等待同步消息响应3.异步消息在发送方继续之前，无需等待响应的消息4.注释5.约束约束的符号很简单；格式是: [Boolean Test]6.组合片段组合片段用来解决交互执行的条件及方式。
它允许在序列图中直接表示逻辑组件，用于通过指定条件或子进程的应用区域，为任何生命线的任何部分定义特殊条件和子进程。
常用的组合片段有：a.抉择（Alt）抉择用来指明在两个或更多的消息序列之间的互斥的选择，相当于经典的if..else..。
抉择在任何场合下只发生一个序列。
可以在每个片段中设置一个临界来指示该片段可以运行的条件。
else的临界指示其他任何临界都不为True 时应运行的片段。
如果所有临界都为False 并且没有else，则不执行任何片段。
b.选项（Opt）包含一个可能发生或不发生的序列c.循环（Loop）片段重复一定次数。
可以在临界中指示片段重复的条件。
d.并行（Par）下表列出了常用的组合片段：。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
UML用例图
用例图主要用来图示化系统的主事件流程，它主要用来描述客户的需求，即用户希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块。
展示了一个外部用户能够观察到的系统功能模型图。
用例图中涉及的关系：
1》泛化(Inheritance)
就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用
例将继承父用例的所有结构、行为和关系。
子用例可以使用父用例的一段行为，也可以重载它。
父用例通常是抽象的。
2》包含(Include)
包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。
3》扩展(Extend)
扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。
包含(include)、扩展(extend)、泛化(Inheritance)的区别：
条件性：泛化中的子用例和include中的被包含的用例会无条件发生，而extend中的延伸用例的发生是有条件的；
直接性：泛化中的子用例和extend中的延伸用例为参与者提供直接服务，而include 中被包含的用例为参与者提供间接服务。
对extend而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内
容。
对Inheritance而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的
关系；
UML类图
类名：如果是抽象类，则采用斜体（继承用实线）
'. 1》接口的表示：
一个类和一个接口不同：一个类可以有它形态的真实实例，然而一个接口必须至少有一
个类来实现它。
在 UML 2 中，一个接口被认为是类建模元素的特殊化。
因此，接口就象类
那样绘制，但是长方形的顶部区域也有文本“interface”。
2》UML 支持的可见性类型的标志
标志可见性类型
+Public
#proteted
-private
~package
3》多重值和它们的表示
可能的多重值描述
表示含义
0..1 0个或1个
1只能1个
0..*0个或多个
* 0个或多个
1..*1个或多个
3只能3个
0..50到5个
5..15 5到15个
4》类图之间的关系有：泛化（继承），依赖，关联，聚合/组合。
1.聚合/组合
聚合是一种特别类型的关联，用于描述“总体到局部”的关系。
在基本的聚合关系中，
部分类的生命周期独立于整体类的生命周期。
举例来说，我们可以想象，车是一个整体实体，而车轮轮胎是整辆车的一部分。
轮胎可以在安置到车时的前几个星期被制造，并放置于仓库中。
在这个实例中，Wheel类实例清楚地独立地Car类实例而存在。
然而，有些情况下，部分类的生命周期并不独立于整体类的生命周期-- 这称为合成聚合。
举例来说，考虑公司与部门的关系。
公司和部门都建模成类，在公司存在之前，部门不能存在。
这里Department类的实例依赖于Company类的实例而存在。
·基本聚合（聚合）
有聚合关系的关联指出，某个类是另外某个类的一部分。
在一个聚合关系中，子类实例可以比父类存在更长的时间。
为了表现一个聚合关系，你画一条从父类到部分类的实线，并在父类的关联末端画一个未填充棱形。
图中清楚的表明了类Car对象包含了另一类Wheel的4个实例，这两者在概念上是密不可分的，
其中的一个类是另一个类的构成成分。
菱形表示“包含”，箭头表示被包含的对象，数字4表示包含的数目。
·组合聚合（组合）
组合聚合关系是聚合关系的另一种形式，但是子类实例的生命周期依赖于父类实例的生命周期。
注意:组合关系如聚合关系一样绘制，不过这次菱形是被填充的。
2.依赖
依赖可以说是要完成C5里的所有功能，一定要有C6的方法协助才行
3.关联
可以分为单向关联，双向关联
双向关联：
C1-C2：指双方都知道对方的存在，都可以调用对方的公共属性和方法。
单向关联：
C3->C4：表示相识关系，指C3知道C4，C3可以调用C4的公共属性和方法。
没有生命期的依赖。
一般是表示为一种引用。
UML序列图
序列图的主要目的是定义事件序列，产生一些希望的输出。
重点不是消息本身，而是消息产生的顺序；不过，大多数序列图会表示一个系统的对象之间传递的什么消息，以及它们发生的顺序。
1》生命线：
生命线名称可带下划线。
当使用下划线时，意味着序列图中的生命线代表一个类的特定实例。
序列图的实例名称有下划线，而角色名称没有。
2》注释
3》约束
约束的符号很简单；格式是: [Boolean Test]
4》抉择（Alt）
抉择用来指明在两个或更多的消息序列之间的互斥的选择，相当于经典的if..else..。
5》选项（Opt）
包含一个可能发生或不发生的序列
6》循环（Loop）
片段重复一定次数。
可以在临界中指示片段重复的条件。