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的构造快包含3种:(1) 事物(4种):结构事物,⾏为事物,分组事物,注释事物(2) 关系(4种):泛化关系,实现关系,依赖关系,关联关系(3) 图(10种):⽤例图,类图,对象图,包图,组件图,部署图,状态图,活动图,序列图,协作图事物是对模型中最具代表性的成分的抽象;关系把事物结合在⼀起;图聚集了相关的事物。
(2) 关系(4种)UML 中类与类, 类与接⼝, 接⼝与接⼝这间的关系有: 泛化(generalization) 关系, 关联(association)关系( 关联, 聚合, 合成), 依赖(dependency)关系,实现(realization)关系.泛化(generalization)关系是⼀个类(称为⼦类、⼦接⼝)继承另外的⼀个类(称为⽗类、⽗接⼝)的功能,并可以增加它⾃⼰的新功能的能⼒,继承是类与类或者接⼝与接⼝之间最常见的关系;在Java中此类关系通过关键字extends明确标识,在设计时⼀般没有争议性。
实现(realization)关系指的是⼀个class类实现interface接⼝(可以是多个)的功能;实现是类与接⼝之间最常见的关系;在Java中此类关系通过关键字implements明确标识,在设计时⼀般没有争议性;依赖(dependency)关系: 也是类与类之间的连接. 表⽰⼀个类依赖于另⼀个类的定义. 依赖关系总是单向的。
可以简单的理解,就是⼀个类A 使⽤到了另⼀个类B,⽽这种使⽤关系是具有偶然性的、、临时性的、⾮常弱的,但是B类的变化会影响到A;⽐如某⼈要过河,需要借⽤⼀条船,此时⼈与船之间的关系就是依赖;表现在代码层⾯,为类B作为参数被类A在某个method⽅法中使⽤。
(A use B)在java 中. 依赖关系体现为: 局部变量, ⽅法中的参数, 和对静态⽅法的调⽤.关联(association)关系:表⽰类与类之间的联接, 它使⼀个类知道另⼀个类的属性和⽅法.关联可以使⽤单箭头表⽰单向关联, 使⽤双箭头或不使⽤箭头表⽰双向关联, 不建议使⽤双向关联. 关联有两个端点, 在每个端点可以有⼀个基数, 表⽰这个关联的类可以有⼏个实例.常见的基数及含义:0..1:0 或1 个实例.0..*: 对实例的数⽬没有限制.1: 只能有⼀个实例.1..*: ⾄少有⼀个实例.他体现的是两个类、或者类与接⼝之间语义级别的⼀种强依赖关系,⽐如我和我的朋友;这种关系⽐依赖更强、不存在依赖关系的偶然性、关系也不是临时性的,⼀般是长期性的,⽽且双⽅的关系⼀般是平等的,表现在代码层⾯,为被关联类B以类属性的形式出现在关联类A中,也可能是关联类A引⽤了⼀个类型为被关联类B的全局变量;在java 语⾔中关联关系是使⽤实例变量实现的.关联关系还包括:聚合,组合关系。
学生管理系统用例图、类图、对象图的绘制(UML)

参与者1--系统管理员:参与Biblioteka 2--教师:参与者3—学生:
类图与对象图的绘制
有一个学生管理系统,其中有参与者三人,分别为系统管理员、教师和学生,需求如下:
(1)系统管理员登录系统后,通过身份验证,能够对学生的基本信息进行管理,包括录入学生基本信息、修改学生基本信息、查询学生基本信息、删除学生基本信息,并且可以找回自己的密码。
(2)教师在日常管理中可以登录系统,如果忘记了自己的密码,则可以找回。可以通过系统查询、修改和删除学生的考试成绩。当考试结束后,教师有权将学生成绩录入系统。
UML类图及类与类之间的关系

UML类图及类与类之间的关系原⽂地址:类图⽤于描述系统中所包含的类以及它们之间的相互关系,帮助⼈们简化对系统的理解,它是系统分析和设计阶段的重要产物,也是系统编码和测试的重要模型依据。
1. 类类(Class)封装了数据和⾏为,是⾯向对象的重要组成部分,它是具有相同属性、操作、关系的对象集合的总称。
在系统中,每个类都具有⼀定的职责,职责指的是类要完成什么样的功能,要承担什么样的义务。
⼀个类可以有多种职责,设计得好的类⼀般只有⼀种职责。
在定义类的时候,将类的职责分解成为类的属性和操作(即⽅法)。
类的属性即类的数据职责,类的操作即类的⾏为职责。
设计类是⾯向对象设计中最重要的组成部分,也是最复杂和最耗时的部分。
在软件系统运⾏时,类将被实例化成对象(Object),对象对应于某个具体的事物,是类的实例(Instance)。
类图(Class Diagram)使⽤出现在系统中的不同类来描述系统的静态结构,它⽤来描述不同的类以及它们之间的关系。
在系统分析与设计阶段,类通常可以分为三种,分别是实体类(Entity Class)、控制类(Control Class)和边界类(Boundary Class),下⾯对这三种类加以简要说明:(1) 实体类:实体类对应系统需求中的每个实体,它们通常需要保存在永久存储体中,⼀般使⽤数据库表或⽂件来记录,实体类既包括存储和传递数据的类,还包括操作数据的类。
实体类来源于需求说明中的名词,如学⽣、商品等。
(2) 控制类:控制类⽤于体现应⽤程序的执⾏逻辑,提供相应的业务操作,将控制类抽象出来可以降低界⾯和数据库之间的耦合度。
控制类⼀般是由动宾结构的短语(动词+名词)转化来的名词,如增加商品对应有⼀个商品增加类,注册对应有⼀个⽤户注册类等(3) 边界类:边界类⽤于对外部⽤户与系统之间的交互对象进⾏抽象,主要包括界⾯类,如对话框、窗⼝、菜单等。
在⾯向对象分析和设计的初级阶段,通常⾸先识别出实体类,绘制初始类图,此时的类图也可称为领域模型,包括实体类及其它们之间的相互关系。
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机两个类包含哪些属性,哪些操作,它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。
- 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 clas s 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)
{
}
}
(学习的目的是增长知识,提高能力,相信一分耕耘一分收获,努力就一定可以获得应有的回报)。