UML中类图实例
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(Unified Modeling Language)类图是软件开发中常用的一种图形化工具,用于描述系统中的类、接口、关系等。
其中,依赖关系是类图中的一种重要关系,用于表示一个类对另一个类的使用或依赖。
本文将详细解析UML类图中的依赖关系,并通过实例分析加深理解。
依赖关系是一种比较弱的关系,表示一个类在某个特定的场景下,需要使用另一个类的功能或服务。
在UML类图中,依赖关系用带箭头的虚线表示,箭头从使用类指向被使用类。
依赖关系的特点是临时性和方向性,即一个类对另一个类的依赖可能是暂时的,而且依赖关系是单向的。
依赖关系可以通过类之间的方法调用、参数传递、返回值等方式来实现。
当一个类在某个方法中调用了另一个类的方法,或者将另一个类的实例作为参数传递给自己的方法,就表示存在依赖关系。
例如,一个订单类可能依赖于一个库存管理类,以获取商品的库存信息。
依赖关系在软件设计中起到了重要的作用。
它可以帮助开发人员将系统分解为更小的模块,提高代码的可维护性和可重用性。
通过依赖关系,一个类只需要关注自己需要使用的功能,而不需要了解被使用类的具体实现。
这样,当被使用类发生变化时,只需要修改被使用类的代码,而不需要修改使用类的代码。
下面通过一个实例来进一步说明依赖关系的应用。
假设我们正在开发一个在线购物系统,其中包含订单管理和库存管理两个模块。
在订单管理模块中,需要根据用户提交的订单信息查询库存,并更新库存信息。
这时,订单管理模块就依赖于库存管理模块。
在UML类图中,我们可以将订单管理类和库存管理类分别表示为一个矩形框,并用虚线箭头连接两个类。
箭头的方向从订单管理类指向库存管理类,表示订单管理类依赖于库存管理类。
在订单管理类中,我们可以定义一个方法,例如`checkInventory()`,该方法内部调用库存管理类的方法来查询库存。
通过依赖关系,订单管理模块可以独立于库存管理模块进行开发和测试。
UML类图绘制实例-桑皮sangpi
UML类图绘制实例-桑⽪sangpiUML类图绘制实例下⾯将使⽤如属官的借阅管理系统做⼀个图书馆管理系统的UML类图。
最终的绘制结果⼤致如下:前期建模对于图书馆的借阅系统的建模,⾸先我们把所有需要定义的基础类定义出来,再把我们的插⼊进去。
分别是Book(书籍)、Library(图书馆)、Patron(顾客)、Librarian(图书管理员)四个基础的对象。
我们尝试将四个基础类进⾏关系连接,最后的到的关系图如下(注,就算没有图书,图书馆也不会消失,因此使⽤空⼼的关联关系:业务扩展增加⽤户账号管理由于客户借还书籍过程中,图书馆⾥系统的后台会希望能够查看该顾客的曾借⽤书籍,已借阅待还书籍,以及当前客户是否有权限进⾏新书的借阅。
因此我们需要在图书馆管理系统中,引⼊**Account(账户系统)**作为代理,⽤于⽅便关联借阅的顾客和馆中的书籍。
该UML中,图书馆持有多个账号,这个不难理解;每个账号代理以前每⼀个借书者去依赖书,也不难理解;账号有指向Partron的关联关系我们也不难理解,毕竟账户作为代理⽅,肯定需要有被代理的⼈的信息;但是可能存在的困惑点在于Account和Patron之间的聚合关系,这⾥我理解是因为在本项⽬设计中,账号被设计成了可以回收利⽤的号码,因此如果该账号闲置的时候,是可以不关联任何⽤户的,直到账号被下⼀次利⽤重新分发给新⼈。
增加书籍借阅信息管理好了借书的⼈,我们的图书馆管理系统还需要增加书籍管理系统,⽤来标记每本书籍⾃⾝的状态,⽐如该书籍的条码、RFID中的信息、是否允许借出图书馆、图书的类别、图书的借出时间、图书的借阅周期(时长)、图书的应归还时期等等信息。
这些都是图书馆⾃⾝作图书管理所需要信息⽽⾮书籍本⾝的信息。
因此我们需要在原始图书的基础之上扩展⼀个图书馆的书⽬实体Book Item,⾥⾯除了书籍⾃⾝的信息之外,还包含了该书管理过程中的信息。
更新之后的UML如下:增加检索和管理功能随着图书馆书籍越来越多,图书馆管理员需要对这些书籍进⾏分类有序放置、对特定的书⽬进⾏查找,顾客需要根据条件检索⾃⼰需要的书⽬。
UML类图详细教程
UML类图详细教程UML(Unified Modeling Language)是一种用于软件系统建模的标准化语言。
在软件开发过程中,通过使用UML类图可以清晰地描述系统中的类、对象、方法和关系等要素,以帮助开发人员更好地理解和设计软件系统。
本文将详细介绍UML类图的基本元素、关系类型和用法,以及一些实际应用的示例。
接下来将分为以下几个部分进行阐述:1.基本元素2.类的属性和方法3.类之间的关系4.实际应用示例1.基本元素:a) 类(Class):类是UML类图的基本元素,用矩形框表示。
每个框内部分别包含类名、属性和方法。
b) 对象(Object):对象是类的实例,用一条带箭头的直线连接到类。
对象可以有自己的属性和方法。
c) 接口(Interface):用一个带有虚线的矩形框表示,包含接口的名称和方法。
d) 抽象类(Abstract Class):用一个带有斜线的矩形框表示,表示只能被继承,不能被实例化的类。
e) 枚举(Enumeration):用一个带有斜线和虚线的矩形框表示,表示一个有限个数的类。
2.类的属性和方法:a) 属性(Attribute):用于描述类或对象的状态,用名称和数据类型表示。
b) 方法(Method):用于描述类或对象的行为,用名称和参数列表表示。
3.类之间的关系:a) 关联(Association):用一条直线连接两个类,表示两者之间存在关系。
关联可以有方向、多重性和角色等属性。
b) 继承(Inheritance):用一条带箭头的直线连接两个类,并在箭头上方标识出继承关系。
子类继承了父类的属性和方法。
c) 实现(Realization):用一条带虚线的直线连接两个类,表示实现关系。
一个类实现了一个接口,需要实现接口中定义的方法。
d) 依赖(Dependency):用一条带箭头的虚线连接两个类,表示类之间的依赖关系。
一个类依赖于另一个类时,使用到了另一个类的属性或方法。
4.实际应用示例:假设我们要设计一个简单的图书馆管理系统,其中包括书籍(Book)、图书馆(Library)和借阅记录(BorrowRecord)等类。
uml各种图例及说明(摘录)
接口是组件间的通信方式。例如,小汽车的接口是仪表板和踏板。可通过“接口”与小汽车通信。Order组件可包含一个方法来取消订单,接口指定执行这个操作需要订单ID;换言之,要使Order对象删除订单,必须为要删除的订单传输订单ID。
uml各种图例及说明(摘录)
1、用例图
描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统,以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素,如系统、参与者和用例,并且显示了这些元素之间的各种关系,如泛化、关联和依赖。
2、类图
类图是描述系统中的类,以及各个类之间的关系的静态视图。能够让我们在正确编写代码以前对系统有一个全面的认识。类图是一种模型类型,确切的说,是一种静态模型类型。
UML类的表示符号是一个矩形,如图3-6所示。由图可知,该类有一些属性(CustomerID和Date等)和一些方法(New、PlaceOrder和Delete)。
在类图中,类相互之间具有关系。例如,Customer可将若干个Order放入系统。类之间的关系用实线表示,如图3-7所示。
二、 行为图
聚集:特殊的关联,描述整体与部分的组合关系。
泛化:是一种特殊与一般的关系,如子元素(特殊)与父元素(一般),箭头指向父元素。
实现:类元之间的关系,其中一个类元指定了由另一个类元保证执行的契约。一般用在接口和实现他们的类之间或用例和实现它们的协作之间。
UML提供9种视图:类图、对象图,用例图,序列图、协作图,状态图、活动图,构件图和部署图。
4.交互图:包括序列图(顺序图)和协作图,两者对应,顺序图是强调消息时间顺序,有对象生命线和控制焦点。协作图是强调接收和发送消息的对象的结构组织,有路径和顺序号。如下图(摘自网络):
UML类图基本画法
UML类图基本画法类简要画法类有三个单元格的矩形(看上图中的动物类)第⼀格:类名称(如果是抽象类,名称标注为斜体字)第⼆格:类属性名称第三格:类操作名称类属性或者操作的访问修改符的标注:public⽤加号标注private⽤减号标注protected⽤#号标注接⼝简要画法接⼝有两个单元格的矩形(看上图中的飞翔接⼝)第⼀格:接⼝名称(名称前⾯要加⼊接⼝标注<>)第⼆格:操作名称属性或者操作的访问修改符的标注:同类继承关系简要画法继承关系简单介绍:类似is-a的关系,如:猫是⼀个动物鸟类+实线+空⼼三⾓形+动物类(即鸟类继承动物类,参考上图中的标注①)箭头⽅向说明:箭头⽅向由⼦类指向⽗类接⼝实现关系简要画法简单介绍:接⼝表达的是⼀种has-a的关系,即拥有这类接⼝的操作,如:猫可以实现爬树的接⼝⼤雁类+虚线+空⼼三⾓形+飞翔接⼝(即⼤雁类实现了接⼝飞翔,参考上图中的标注②)箭头⽅向说明:箭头⽅向由类指向接⼝依赖关系简要画法简单介绍:依赖关系表达的是⼀种use-a的关系,即⼀个类临时引⽤另外⼀个类的⽅法实现功能动物类+虚线+箭头+氧⽓类和⽔类(即动物类依赖氧⽓类和⽔类,参考上图中的标注③)箭头⽅向说明:箭头由类指向被依赖类关联关系简要画法简单介绍:关联关系表达的是⼀种强依赖关系,需要长期知道对⽅,使⽤对⽅,如企鹅需要总是知道⽓候的变化企鹅类+实线+箭头+⽓候类(即企鹅类关联⽓候类,参考上图中的标注④)箭头⽅向说明:箭头由类指向被关联类聚合关系简要画法简单介绍:聚合关系表达的是⼀种弱拥有关系,如电脑与很多外设的关系雁群类+空⼼菱形+实线+箭头+⼤雁类(即雁群类是由⼤雁类聚合成的,参考上图中的标注⑤)箭头⽅向说明:箭头由整体指向部分合成(或说组合)关系简要画法简单介绍:合成关系表达的是⼀种强拥有关系,并且⽣命周期相同,不能单独存在鸟类+实⼼菱形+实线+箭头+翅膀类(即鸟类是由翅膀类及其它类合成的,参考上图中的标注⑥)箭头⽅向说明:箭头由整体指向部分关系常见的关系有:继承(Inheritance),关联关系(Association),(Aggregation),复合关系(Composition),依赖关系(Dependency),实现关系(Realization/Implementation)。
2.设计模式常用的UML图分析(用例图、类图与时序图)
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(也就是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业务建模实例分析在我国十年前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机两个类包含哪些属性,哪些操作,它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
UML类图的抽象与实例化关系详解
UML类图的抽象与实例化关系详解UML(Unified Modeling Language)是一种用于软件开发的标准建模语言,其中的类图是一种常用的图形表示方式,用于描述系统中的类、属性和方法之间的关系。
在UML类图中,抽象与实例化是两个重要的概念,它们分别描述了类与对象之间的关系。
本文将详细解释UML类图中抽象与实例化的含义和关系。
抽象是指将类的某些特征或行为提取出来,形成一个抽象类或接口,用于描述一类具有相似特征或行为的对象。
在UML类图中,抽象类用斜体字表示,接口则用带有虚线的斜体字表示。
抽象类和接口中的方法通常只有声明而没有具体实现,具体实现由其子类或实现类完成。
抽象类和接口的作用是为了实现代码的复用和扩展性。
通过抽象类和接口,可以定义一些通用的方法和属性,然后由具体的子类或实现类去实现或重写这些方法和属性。
这样,在系统中可以通过抽象类或接口来引用不同的子类或实现类对象,而不需要关心具体的实现细节。
实例化是指将抽象类或接口实例化为具体的对象。
在UML类图中,实例化关系用带有箭头的实线表示,箭头指向被实例化的类或接口。
实例化关系表示一个类或接口被实例化为一个具体的对象。
在实例化关系中,一个类或接口可以被多个对象实例化。
这意味着同一个类或接口可以有多个实例,每个实例都具有相同的属性和方法,但是它们的值和状态可能不同。
通过实例化关系,可以创建多个相同类型的对象,并对它们进行独立的操作和处理。
抽象与实例化是UML类图中的两个重要概念,它们之间存在着密切的关系。
抽象类和接口提供了一种抽象的方式来描述一类对象的共同特征和行为,而实例化关系则将这些抽象概念具体化为具体的对象。
抽象与实例化的关系可以通过一个简单的例子来说明。
假设有一个图书馆管理系统,其中有一个抽象类叫做"图书",它定义了一些通用的属性和方法,比如书名、作者、出版社等。
然后,通过实例化关系,可以将"图书"这个抽象类实例化为具体的对象,比如"Java编程思想"、"设计模式"等。
UML 实验2 学生选课系统类图
实验2 类图
实验目的
1.理解类的基本概念
2.理解类间的关系
3.掌握类图的绘制方法
实验学时
6学时,必做。
实验内容
分析选课系统中的类及关系,然后画出它们的类图。
实验步骤
1.分析
在选课系统中,通过分析可抽象出如下几个类:
1.学生类
2.管理员类
3.课程类
学生类和管理员类的属性较容易分析,这里只列出课程类的属性和方法:(1)课程名称
(2)开课教室
(3)课程号
(4)授课教师
(5)选课的学生
(6)开课起始时间
(7)允许选课的学生人数
(8)设置课程号
(9)设置课程名称
(10)查询课程号
(11)查询允许选课的学生人数
2.绘图步骤:
(1)打开rose,新建类图
(2)抽象出学生类管理员类课程类画出类图
(3)效果完成图
(4)添加关系
通过类图,使我们对学生、管理员、以及课程之间的关系一目了然。
UML中的类图详解及其应用场景
UML中的类图详解及其应用场景在软件开发过程中,UML(统一建模语言)被广泛应用于需求分析、系统设计和软件开发等各个阶段。
其中,类图作为UML的核心图表之一,用于描述系统中的类、对象以及它们之间的关系。
本文将详细介绍UML中的类图,并探讨其在实际应用中的场景。
一、类图的基本概念类图是一种静态结构图,用于表示系统中的类、接口、关联、继承、依赖等元素及其之间的关系。
在类图中,类用矩形表示,类名位于矩形顶部,类的属性位于矩形中部,类的操作(方法)位于矩形底部。
类之间的关系通过连线表示,如关联关系用实线箭头表示,继承关系用空心三角箭头表示,依赖关系用虚线箭头表示等。
二、类图的元素及其关系1. 类(Class):类是对象的抽象表示,用于描述具有相同属性和行为的一组对象。
类图中的类用矩形表示,类名位于矩形顶部。
2. 接口(Interface):接口是一组方法的集合,用于描述类的行为。
接口在类图中用带有<<interface>>标记的矩形表示。
3. 属性(Attribute):属性是类的特征,描述了类的状态。
属性在类图中用名称:类型的形式表示,例如“name:String”。
4. 操作(Operation):操作是类的行为,描述了类的方法。
操作在类图中用名称(参数列表):返回类型的形式表示,例如“getName():String”。
5. 关联关系(Association):关联关系描述了类之间的连接,表示一个类与另一个类之间的关联。
关联关系在类图中用实线箭头表示。
6. 继承关系(Inheritance):继承关系描述了类之间的继承关系,表示一个类继承自另一个类。
继承关系在类图中用空心三角箭头表示。
7. 依赖关系(Dependency):依赖关系描述了类之间的依赖关系,表示一个类依赖于另一个类。
依赖关系在类图中用虚线箭头表示。
三、类图的应用场景1. 系统设计:类图是系统设计的重要工具之一。
UML面向对象建模chapter3类图对象图
Product
具有泛化关系的类图
案例—银行网络系统
一、问题的陈述 银行网络系统包括人工出纳和分行共享的自动 出纳机;各分理处用自己的计算机处理业务(保存 帐户、处理事务等);各分理处与出纳站通过网络 通信;出纳站录入帐户和事务数据;自动出纳机与 分行计算机通信;自动出纳机与用户接口,接受现 金卡;发放现金;打印收据;分行计算机与拨款分 理处结帐。 要求系统正确处理同一帐户的并发访问;网络 费用平均摊派给各分理处。
连接
递归关联 带有职责的递归关联 医生
治疗
人
病人
二、聚集(aggregation)
聚集是一种特殊的关联,它指出类间的“整体-部分”关系。 1、共享聚集(shared aggregation) 其“部分”对象可以是任意“整体”对象的一部分。当 “整体”端的重数不是1时,称聚集是共享的。
整体类 部分类
共享聚集
项目
*
*
人员
2、组合聚集(composition aggregation) 其“整体”(重数为0、1)拥有它的“部分” 。部分仅属 于同一对象,整体与部分同时存在。
标题 整体类 部分类 窗口 工具框 显示区
组合聚集 窗口
标题 工具框 显示区
三、泛化
泛化指出类之间的“一般与特殊关系”,即继承关系。父 类与子类之间构成类的分层结构。
类之间的关系
UML中类的关系有关联(association) ,聚集 (aggregation) ,泛化(generalization) , 依赖 (depending)和细化 (refinement)。
一、关联
公司
0..* 顾 佣
工作于
0..*
关联是类之间的连结,分为: 1. 2. 常规关联 多元关联
UML的类图关系(c#实例)
UML的类图关系(c#实例)UML的类图关系分为:关联、聚合/组合、依赖、泛化(继承)。
/// <summary>/// UML类图关系:关联/// </summary>#region 双向关联:双方都拥有对方的一个指针,当然也可以是引用或者是值。
C1-C2class C1{public C2 theC2 = new C2();};class C2{public C1 theC1 = new C1();};#endregion#region 单向关联:C3有C4的指针,而C4对C3一无所知。
C3->C4class C3{public C4 theC4 = new C4();};class C4{};#endregion#region 自身关联(反身关联):自己引用自己,带着一个自己的引用。
class C14{public C14 theC14 = new C14();};#endregion/// <summary>/// UML类图关系:聚合/组合/// 当类之间有整体-部分关系的时候,我们就可以使用组合或者聚合。
/// </summary>//聚合:表示C9聚合C10,但是C10可以离开C9而独立存在//(独立存在的意思是在某个应用的问题域中这个类的存在有意义)。
class C9{public C10 theC10 = new C10();};class C10{};//组合(也有人称为包容):一般是实心菱形加实线箭头表示,//表示的是C8被C7包容,而且C8不能离开C7而独立存在。
//但这是视问题域而定的,例如在关心汽车的领域里,//轮胎是一定要组合在汽车类中的,因为它离开了汽车就没有意义了。
//但是在卖轮胎的店铺业务里,就算轮胎离开了汽车,它也是有意义的,这就可以用聚合了。
class C7{public C8 theC8 = new C8();};class C8{};//可以看到,代码和聚合是一样的。
UML 类图详解
UML类图在UML的静态机制中类图是一个重点,它不但是设计人员关心的核心,更是实现人员关注的核心。
建模工具也主要根据类图来产生代码。
类图在UML的9个图中占据了一个相当重要的地位。
James Rumbaugh对类的定义是:类是具有相似结构、行为和关系的一组对象的描述符。
类是面向对象系统中最重要的构造块。
类图显示了一组类、接口、协作以及他们之间的关系。
在UML中问题域最终要被逐步转化,通过类来建模,通过编程语言构建这些类从而实现系统。
类加上他们之间的关系就构成了类图,类图中还可以包含接口、包等元素,也可以包括对象、链等实例。
接口在类图中通过版型来表示<<interfac e>>,下面的介绍将主要介绍类,接口和类类似。
A. 类的UML表示类的命名尽量应用领域中的术语,应明确、无岐义,以利于相互交流和理解。
类的属性、操作中的可见性使用+、#、-分别表示public、protected、private。
B.类之间的关系类之间的关系是类图中比较复杂的内容。
有关联、聚合、组合、范化、依赖。
关联:是模型元素之间的一种语义联系,是类之间的一种很弱的联系。
关联可以有方向,可以是单向关联,也可以是双向关联。
可以给关联加上关联名来描述关联的作用。
关联两端的类也可以以某种角色参与关联,角色可以具有多重性,表示可以有多少个对象参与关联。
可以通过关联类进一步描述关联的属性、操作以及其他信息。
关联类通过一条虚线与关联连接。
对于关联可以加上一些约束,以加强关联的含义。
如下图所示:聚合是一种特殊的关联,聚合表示整体与部分的关系。
通常在定义一个整体类后,再去分析这个整体类的组成结构。
从而找出一些组成类,该整体类和组成类之间就形成了聚合关系。
例如舰队是由一系列的舰船组成。
需求描述中“包含”、“组成”、“分为….部分”等词常意味着聚合关系。
组合也是一种特殊的关联,也表示类之间整体和部分的关系,但是组合关系中部分和整体具有统一的生存期。
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类图符号各种关系说明以及举例UML中描述对象和类之间相互关系的⽅式包括:依赖(Dependency),关联(Association),聚合(Aggregation),组合(Composition),泛化(Generalization),实现(Realization)等。
依赖(Dependency):元素A的变化会影响元素B,但反之不成⽴,那么B和A的关系是依赖关系,B依赖A;类属关系和实现关系在语义上讲也是依赖关系,但由于其有更特殊的⽤途,所以被单独描述。
uml中⽤带箭头的虚线表⽰Dependency关系,箭头指向被依赖元素。
泛化(Generalization):通常所说的继承(特殊个体 is kind of ⼀般个体)关系,不必多解释了。
uml中⽤带空⼼箭头的实线线表⽰Generalization关系,箭头指向⼀般个体。
实现(Realize):元素A定义⼀个约定,元素B实现这个约定,则B和A的关系是Realize,B realize A。
这个关系最常⽤于接⼝。
uml 中⽤空⼼箭头和虚线表⽰Realize关系,箭头指向定义约定的元素。
关联(Association):元素间的结构化关系,是⼀种弱关系,被关联的元素间通常可以被独⽴的考虑。
uml中⽤实线表⽰Association 关系,箭头指向被依赖元素。
聚合(Aggregation):关联关系的⼀种特例,表⽰部分和整体(整体 has a 部分)的关系。
uml中⽤带空⼼菱形头的实线表⽰Aggregation关系,菱形头指向整体。
组合(Composition):组合是聚合关系的变种,表⽰元素间更强的组合关系。
如果是组合关系,如果整体被破坏则个体⼀定会被破坏,⽽聚合的个体则可能是被多个整体所共享的,不⼀定会随着某个整体的破坏⽽被破坏。
uml中⽤带实⼼菱形头的实线表⽰Composition关系,菱形头指向整体。
1.1.1 依赖(Dependency):虚线箭头表⽰1、依赖关系也是类与类之间的联结2、依赖总是单向的。
uml类图-对象图-包图PPT课件
Company
W heel
Department
-
24
Company Department
-
25
类图的抽象层次
在软件开发的不同阶段使用的类图具有不同的抽 象层次。一般地,类图可分为三个层次,即概念 层,说明层和实现层。
类的概念层,说明层和实现层的划分最先是由
Steve Cook和John Daniels引入的。
➢类 ➢ 接口 ➢ 协作 ➢ 依赖、泛化和关联关系
类图可以包含注解和约束; 类图还可以有包或子系统,二者都用于把 模型元素聚集成更大的组件。
-
5
类(Class)
A class is the descriptor for a set of objects with similar structure, behavior, and relationships.
Camera Sensors::Vision::Camera 包中可以包含其它建模元素,如class, interface, component, node, use case, package, … , 等。 包可以嵌套,但嵌套层次不要过深。 包没有实例,即在系统运行时见不到包。 包之间可以存在依赖关系, 但这种依赖关系不存在传递性。
➢ 概念层(Conceptual)类图描述应用领域中的概念,一般地, 这些概念和类有很自然的联系,但两者并没有直接的映射关 系。
➢ 说明层(Specification)类图描述软件的接口部分,而不是软件 的实现部分。
➢ 实现层(Implementation)类图才真正考虑类的实现问题,揭示 实现细节。
-
3
类图的应用
类图用于对系统静态设计视图建模。与数据模型 不同,它不仅显示了信息的结构,同时还描述了 系统的行为。 类图中可以包含接口,包,关系等建模元素,也 可以包含对象,链等实例。
UML中的类图和泳道图的区别与实例分析
UML中的类图和泳道图的区别与实例分析UML(统一建模语言)是一种用于软件系统建模的标准化语言,它提供了多种不同类型的图表,用于描述系统的不同方面。
其中,类图和泳道图是两种常用的图表类型,用于表示系统中的类和流程。
本文将重点探讨类图和泳道图的区别,并通过实例分析来进一步理解它们的应用。
一、类图类图是UML中最常用的图表类型之一,用于描述系统中的类、属性和方法之间的关系。
它以类为中心,通过类之间的关联、继承和依赖等关系来展示系统的结构。
类图通常由类、属性、方法和关系四个主要元素组成。
在类图中,类用矩形框表示,类的名称位于框的顶部,类的属性和方法分别位于框的中间和底部。
属性和方法的可见性可以用符号表示,例如"+"表示public,"-"表示private。
关系可以用线连接类之间的关联、继承和依赖关系。
例如,考虑一个简单的图书馆管理系统,我们可以使用类图来描述系统的结构。
在该系统中,有图书类和借阅者类,它们之间存在关联关系。
图书类具有属性(书名、作者、出版社等)和方法(借阅、归还等),借阅者类具有属性(姓名、年龄、借阅记录等)和方法(借阅、归还等)。
通过类图,我们可以清晰地了解系统中的类及其之间的关系。
二、泳道图泳道图是一种用于描述系统流程的图表类型,它以泳道(lane)为单位,展示了不同参与者之间的交互和协作。
泳道图通常由泳道、活动和消息三个主要元素组成。
在泳道图中,泳道用长方形表示,每个泳道代表一个参与者或一个角色。
活动用矩形框表示,表示参与者执行的具体活动。
消息用箭头表示,表示不同参与者之间的消息传递。
例如,考虑一个简单的在线购物系统,我们可以使用泳道图来描述用户、商家和物流公司之间的交互。
在该系统中,用户首先选择商品并下单,商家接收订单并处理,物流公司负责配送商品。
通过泳道图,我们可以清晰地了解不同参与者之间的协作和流程。
三、类图和泳道图的区别尽管类图和泳道图都是UML中常用的图表类型,但它们有着不同的应用场景和重点。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
UML中类图实例
接口:空心圆+直线(唐老鸭类实现了‘讲人话’);
依赖:虚线+箭头(动物和空气的关系);
关联:实线+箭头(企鹅需要知道气候才迁移);
聚合:空心四边形+实线+箭头(雁群和大雁的关系);
合成/组合:实心四边形+实线+箭头(鸟和翅膀的关系);泛化/继承:空心三角形+实线(动物和鸟的继承关系);实现:空心三角形+虚线(实现大雁飞翔的接口);
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) {
}
}。