下载文档原格式
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⽤例图实例解析⽤例图主要⽤来描述“⽤户、需求、系统功能单元”之间的关系。
它展⽰了⼀个外部⽤户能够观察到的系统功能模型图。
【⽤途】：帮助开发团队以⼀种可视化的⽅式理解系统的功能需求。
⽤例图所包含的元素如下： 1. 参与者(Actor) 表⽰与您的应⽤程序或系统进⾏交互的⽤户、组织或外部系统。
⽤⼀个⼩⼈表⽰。
2. ⽤例(Use Case) ⽤例就是外部可见的系统功能，对系统提供的服务进⾏描述。
⽤椭圆表⽰。
3. ⼦系统(Subsystem) ⽤来展⽰系统的⼀部分功能，这部分功能联系紧密。
4. 关系 ⽤例图中涉及的关系有：关联、泛化、包含、扩展。
如下表所⽰： a. 关联(Association) 表⽰参与者与⽤例之间的通信，任何⼀⽅都可发送或接受消息。
【箭头指向】：指向消息接收⽅ b. 泛化(Inheritance) 就是通常理解的继承关系，⼦⽤例和⽗⽤例相似，但表现出更特别的⾏为；⼦⽤例将继承⽗⽤例的所有结构、⾏为和关系。
⼦⽤例可以使⽤⽗⽤例的⼀段⾏为，也可以重载它。
⽗⽤例通常是抽象的。
【箭头指向】：指向⽗⽤例 c. 包含(Include) 包含关系⽤来把⼀个较复杂⽤例所表⽰的功能分解成较⼩的步骤。
【箭头指向】：指向分解出来的功能⽤例 d. 扩展(Extend) 扩展关系是指⽤例功能的延伸，相当于为基础⽤例提供⼀个附加功能。
【箭头指向】：指向基础⽤例 e. 依赖(Dependency) 以上4种关系，是UML定义的标准关系。
但VS2010的⽤例模型图中，添加了依赖关系，⽤带箭头的虚线表⽰，表⽰源⽤例依赖于⽬标⽤例。
【箭头指向】：指向被依赖项 5. 项⽬(Artifact) ⽤例图虽然是⽤来帮助⼈们形象地理解功能需求，但却没多少⼈能够通看懂它。
很多时候跟⽤户交流甚⾄⽤Excel都⽐⽤例图强，VS2010中引⼊了“项⽬”这样⼀个元素，以便让开发⼈员能够在⽤例图中链接⼀个普通⽂档。
点餐系统UML设计点餐系统UML设计是一种用于描述点餐系统的统一建模语言（Unified Modeling Language，UML）图形表示方法。
在点餐系统中，顾客可以通过系统选择想要的食物并下订单，系统会将订单传输给厨房或者餐厅，并进行相应的处理。
以下是一个点餐系统的UML设计示例：1.用例图用例图描述了系统的功能和角色之间的交互。
一个基本的点餐系统用例图包括以下元素：-顾客：顾客可以进行点餐、支付订单和查看订单等操作；-服务员：服务员负责接待顾客、记录订单和传输订单给厨房；-厨房：厨房负责接收订单并进行食物制作；-餐厅管理员：餐厅管理员负责管理菜单和餐厅信息。
2.类图类图描述了系统中的类以及它们之间的关系。
一个基本的点餐系统类图包括以下类：-顾客类：顾客拥有属性（如姓名、手机号）和方法（如点餐、支付订单）；-服务员类：服务员拥有属性（如姓名、工号）和方法（如记录订单）；-订单类：订单拥有属性（如订单编号、下单时间）和方法（如计算订单总价、传输至厨房）；-厨房类：厨房负责接收订单并进行食物制作；-菜单类：菜单拥有属性（如菜名、价格）和方法（如添加菜品、修改菜品）；-餐厅类：餐厅拥有属性（如名称、地址）和方法（如添加菜单、派送订单）。
3.活动图活动图描述了系统中各个对象间的动态行为以及对象间的相互作用。
一个基本的点餐系统活动图包括以下活动：-顾客点餐：顾客选择菜品、调整菜品数量并下单；-订单处理：服务员接收订单、记录订单并传输至厨房；-食物制作：厨房接收订单、制作食物并通知完成状态；-订单派送：餐厅接收订单、派送订单并通知顾客。
4.状态图状态图描述了一个对象在不同状态下的转换。
在点餐系统中，可以使用状态图描述订单状态的转换，如订单状态可以是“等待中”、“制作中”和“已完成”。
5.顺序图顺序图描述了系统中各个对象之间的消息传递顺序。
在点餐系统中，可以使用顺序图描述顾客下单时与服务员的交互、服务员传输订单给厨房以及订单派送给顾客的过程。
1.1UML动态建模中的带泳道的UML活动图实现示例1.1.1带泳道的UML活动图及实现示例1、泳道（1）泳道将模型中的活动按照职责组织起来通常很有用。
例如，可以将一个商业组织处理的所有活动组织起来。
这种分配可以通过将活动组织成用线分开的不同区域来表示。
由于它们的外观的缘故，这些区域被称作泳道。
1)活动图中的活动可以被分成为几个区域，每个区域在图中用虚线分开而因此被叫做泳道。
2)泳道是活动图的内容的组织单元。
它没有内在的语义，但可以根据建模者的意愿使用。
通常，每个泳道代表真实世界组织内的一个组织单元。
（2）为什么要采用泳道------活动图所存在的问题1)活动图告诉我们发生了什么，但没有告诉我们该项活动由谁来完成。
在程序设计中，这意味着活动图没有描述出各个活动由哪个类来完成。
泳道解决了这一问题。
2)在活动图里泳道区分了其中活动的不同职责，在泳道活动图中，每一个活动都只能明确的属于一个泳道。
（3）泳道的作用1)它将活动图的逻辑描述与顺序图、合作图的责任描述结合起来。
2)泳道可以用于建模某些复杂的活动图。
这时，每一个泳道可以对应于一个协同，其中活动可以由一个或多个相互连接的类的对象实现。
（4）泳道的UML图示泳道用矩形框来表示，属于某个泳道的活动放在该矩形框内，将对象名放在矩形框的顶部，表示泳道中的活动由该对象负责。
1.1.2在Rose工具中提供了对泳道的技术支持1、泳道的工具按钮下面以某个网上商场系统中的团体订购业务为示例说明实现的过程2、产生泳道：拖动该泳道，然后再命名该泳道再产生出其它的对象、并命名他们3、在泳道中添加各个对象的活动项4、同时也可以修改该泳道的信息1.1.3活动图的实现示例1、某个网上书店项目中的团体购书的客户活动图2、某个“网上银行”项目中的企业开户的业务过程的活动图3、BBS系统中的注册用户的各种活动状况图4、活动图示例---图书销售（一个特定的用例业务流）的活动图在销售业务流程中，主要的内容便是图书的销售，如图：。
13种uml简介、工具及示例UML（Unified Modeling Language）是一种用于软件开发的标准化建模语言，它使用图形表示法来描述软件系统的不同方面。
在软件开发过程中，使用UML可以帮助开发人员更清晰地理解系统的结构和行为，从而更好地进行设计和实现。
UML提供了包括结构模型、行为模型和交互模型在内的多种建模方式，其中每种模型都有各自的符号和语法规则。
通过使用这些模型，开发人员可以将系统分解成不同的部分，然后逐步细化这些部分的设计，以便更好地组织和管理项目。
在UML中，最常用的建模元素包括用例图、类图、时序图、活动图、状态图等。
每种图表都有其特定的用途和表达能力，开发人员可以根据实际需要选择合适的图表进行建模。
除了建模元素外，UML还定义了一系列的建模工具，这些工具可以帮助开发人员更高效地进行建模和分析。
其中一些常用的建模工具包括Enterprise Architect、Rational Rose、StarUML等。
下面将对13种UML简介、工具及示例进行详细介绍：1. 用例图（Use Case Diagram）用例图是UML中描述系统功能和用户交互的基本图表之一。
它用椭圆表示用例，用直线连接用例和参与者，展示了系统外部用户和系统之间的交互。
用例图可以帮助开发人员更清晰地理解系统的功能需求，从而指导系统的设计和实现。
示例：一个简单的在线购物系统的用例图包括用例“浏览商品”、“添加商品到购物车”、“提交订单”等，以及参与者“顾客”和“管理员”。
2. 类图（Class Diagram）类图是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.每个类图包括类，关联和多样性表示.方向性和角色是为了使图示得更清楚时可选的项目.包和对象图为了简单地表示出复杂的类图，可以把类组合成包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（Unified Modeling Language）是一种用于软件开发的建模语言，它提供了一套标准的图形符号和规范，帮助开发人员更好地理解和设计软件系统。
其中，时序图（Sequence Diagram）是一种常用的UML图形，用于描述对象之间的交互。
在本文中，我将分享一个实例，展示如何使用UML时序图绘制一个简单的购物系统的交互过程。
首先，我们需要明确系统中的各个角色和对象。
在这个购物系统中，我们有顾客（Customer）、购物车（Shopping Cart）、商品（Product）和订单（Order）等角色和对象。
接下来，我们可以开始绘制时序图。
首先，我们将顾客和购物车之间的交互表示出来。
顾客通过选择商品将其添加到购物车中，我们可以使用一个箭头来表示这种交互。
箭头的起点是顾客，终点是购物车。
在箭头上方，我们可以标注一些关键信息，如“addProduct(product: Product)”来说明顾客添加商品的操作。
接着，我们可以绘制购物车和商品之间的交互。
购物车需要获取商品的信息，并将其展示给顾客。
我们可以使用另一个箭头来表示这种交互，箭头的起点是购物车，终点是商品。
同样地，在箭头上方，我们可以标注一些关键信息，如“getProductInfo()”来说明购物车获取商品信息的操作。
在时序图中，我们还可以使用垂直虚线来表示时间的推移。
例如，在顾客添加商品到购物车后，购物车需要一定时间来获取商品信息。
我们可以在箭头下方绘制一条垂直虚线来表示这段时间。
除了角色和对象之间的交互，时序图还可以展示条件和循环。
例如，在购物车获取商品信息后，如果商品库存不足，购物车需要向顾客显示一个提示信息。
我们可以使用条件框来表示这种条件，并在条件框中标注相关信息，如“if stock < 1”。
此外，时序图还可以展示并发和同步。
例如，在顾客添加商品到购物车后，购物车需要同时更新商品库存和计算订单总价。
UML示例图
7
推荐
在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.“大雁”和“雁群”这两个类。
大雁是群居动物，每只大雁都属于一个雁群，一个雁群可以有多只大
雁。
所以它们之间就满足聚合(Aggregation)关系。
聚合表示一种弱的“拥有”关系，体现的是A 对象可以包含B对象，但B对象不是A对象的一部分。
聚合关系用空心的菱形+ 实线箭头表示。
class WideGooseAggregate
{
private WideGoose[] arrayWideGoose;
//在雁群WideGooseAggregate类中，有大雁数组对象arrayWideGoose
}
7.“鸟”和“翅膀”这两个类。
鸟和翅膀似整体和部分的关系，并且翅膀和鸟的生命周期是相同的，在
这里鸟和其翅膀就是合成关系。
合成(composition)是一种强的“拥有”关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样。
合成关系用实心的的菱形+实线箭头来表示。
另外，合成关系的连线两端还有一个数字“1”和数字“2”，，这被称为基数。
表明这一端的类可以有几个实例，很显然，一个鸟应该有两支翅膀。
如果一个类可能有无数个实例，则就用“n”来表示。
关联关系，聚合关系也可以有基数的。
class Bird
{
private Wing wing;
public Bird()
{
wing=new Wing();
//在鸟Bird类中，初始化时，实例化翅膀Wing,它们之间同时生成
}
}
8.“动物”、“氧气”与“水”之间。
动物有几大特征，比如有新陈代谢，能繁殖。
而动物要有生命，
需要氧气，水以及食物等。
也就是说动物依赖于氧气和水。
它们之间是依赖关系(Dependency),用虚线箭头来表示。
abstract class Animal
{
public bolism(Oxygen oxygen,Water water) {
}
}。
