类图例子

EA 14种图像以及连线关系一、结构建模1.1 类图类图展示了面向对象系统的构造模块。

描绘了模型或部分模型的静态视图，显示它包含的属性和行为，而不是详细描述操作的功能或完善方法。

类图最常用来表达多个类和接口之间的关系。

泛化（Generalizations），聚合（aggregations）和关联（associations）分别是类之间继承，复合或应用，及连接的表现。

下面的图显示了类之间的聚合关系。

弱聚合（浅色箭头）表现在类 "Account" 使用 "AddressBook"，但是不必要包含它的一个实例。

强聚合（图中的黑色箭头）表示了目标类包含源类，例如，"Contact" 和"ContactGroup"值被包含在 "AddressBook"中。

类（Classes）类是定义对象所具有的属性和行为的元素。

行为用类能理解的合适消息和适合每条消息的操作来描述。

类中也可能定义约束，标记值，构造型。

类的标柱（Class Notation）类用矩形表示。

除类的名称外，还可以选择性地显示属性和操作。

分栏分别用来显示类的名称，属性和操作。

在下面图中，类的类名显示在最上面的分栏，它下面的分栏显示详细属性，如："center" 属性显示初始化的值。

最后面的分栏显示操作，如： setWidth，setLength 和 setPosition 以及他们的参数。

属性和操作名前的标注表示了该属性或操作的可见性: 如果使用 "+"号，这个属性或操作是公共的 ; "-" 号则代表这个属性或操作是私有的。

"#"号是这个属性或操作被定义为保护的，" ~" 号代表包的可见性。

接口（Interfaces）接口是实施者同意满足的行为规范，是一种约定。

StartUML各种类图的例⼦1.UML分为：
1)静态建模：系统基础和系统固定框架结构，这些图形往往是“静态”的。

类图(Class Diagram)：常⽤来分析业务概念
⽤例图(Use Case Diagram)：常⽤
对象图(Object Diagram)：不常⽤
构件图(Component Diagram)：偶尔⽤
部署图(Deployment Diagram)：偶尔⽤
包图(Package Diagram)：不常⽤
2)动态建模：描述的是某种⾏为，是“动态”的。

活动图(Activity Diagram)：偶尔⽤
状态机图(State Machine Diagram)：同上
时序图(Sequence Diagram)：常⽤
通讯图(Communication Diagram)：不常⽤
时间图(Timing Diagram)：不常⽤
2⽤例图：
活动者：⽤户
⽤例：核⼼功能
表⽰某个（些）⽤户能够执⾏哪些功能。

⽤例图EA的功能⽐startUML更加丰富，相对来说约束也会多很多，我还是挺喜欢EA的效果的。

3.时序图
捕捉⼀段时间范围内多个对象之间的交互信息，强调信息交互的时间顺序。

startUML和Ea是⽆法表⽰时序图的返回值，这个图形他们⼤同⼩异。

4.构件图（组件图）（虚线表⽰依赖）
表⽰组件之间的关系
5.部署图
部署软件应⽤的物理设备信息
6.活动图（类似流程图）
相对来说我更喜欢EA的表⽰效果，相⽐之下offic的viso效果更加不错。

UML那些事儿：六类UML图来源：天极网作者：邱郁惠2.1 类图2.2 对象图2.3 包图2.4 活动图2.5 序列图2.6 用例图本章介绍六类UML图的主要用途，以及常见的概念及图示，以便对这六类图有一个初步的认识。

2.1 类图如果投票选最重要的UML图，我一定会把票投给类图( class diagram)。

类图是一款结构图(structure diagram)，如图2-1所示，我们可以用它来表达系统内部重要的组成结构。

一个稳定且具弹性的内部结构可以同时支撑系统对外提供的各式服务，以及系统内部复杂的运作，所以我认为类图特别重要。

接下来的各小节会谈到类图中最常见的概念及图示。

2.1.1 类一群对象(object)享有相同的结构、行为、约束和语义时，称它们是同类(class)的对象。

换句话说，定义一个类就相当于描述了一群对象。

在类中，使用属性(attribute)表达对象的结构，使用操作(operation)表达对象的行为。

如图2-2所示，定义员工(worker)类之后，便可以依据此类的描述产生一群对象。

这些:Worker对象不仅可以共用类所定义的属性，拥有自己的属性值，还可以共用类所定义的操作，或者共用约束。

图2-1 类图图2-2 类与对象类采用三格的矩形图示，顶格放置类名称，中格放置属性名称，底格放置操作名称。

不过，也可以将类的属性格或操作格隐藏起来，节省空间，如图2-3所示。

大多数的UML工具都有隐藏功能。

以StarUML为例，点选任何一个类图示都可以选择是否隐藏属性或操作，如图2-4所示。

图2-3 类图示图2-4 隐藏属性或操作2.1.2 可见性对象具有封装(encapsulation)属性，可以把数据结构和行为细节封装起来，外界无法随意存取。

对应UML的类概念，我们会看到类中有属性和操作，同时可以设定这些成员是否能被外界存取的可见性(visibility)。

以图2-5为例，单笔申购(purchase)封装了一个外界无法存取的私有属性—金额(amount)，以及一个外界可以调用的公开操作—计算(calculate)。

UML类图绘制实例-桑⽪sangpiUML类图绘制实例下⾯将使⽤如属官的借阅管理系统做⼀个图书馆管理系统的UML类图。

最终的绘制结果⼤致如下：前期建模对于图书馆的借阅系统的建模，⾸先我们把所有需要定义的基础类定义出来，再把我们的插⼊进去。

分别是Book(书籍)、Library(图书馆)、Patron(顾客)、Librarian(图书管理员)四个基础的对象。

我们尝试将四个基础类进⾏关系连接，最后的到的关系图如下（注，就算没有图书，图书馆也不会消失，因此使⽤空⼼的关联关系：业务扩展增加⽤户账号管理由于客户借还书籍过程中，图书馆⾥系统的后台会希望能够查看该顾客的曾借⽤书籍，已借阅待还书籍，以及当前客户是否有权限进⾏新书的借阅。

因此我们需要在图书馆管理系统中，引⼊**Account（账户系统）**作为代理，⽤于⽅便关联借阅的顾客和馆中的书籍。

该UML中，图书馆持有多个账号，这个不难理解；每个账号代理以前每⼀个借书者去依赖书，也不难理解；账号有指向Partron的关联关系我们也不难理解，毕竟账户作为代理⽅，肯定需要有被代理的⼈的信息；但是可能存在的困惑点在于Account和Patron之间的聚合关系，这⾥我理解是因为在本项⽬设计中，账号被设计成了可以回收利⽤的号码，因此如果该账号闲置的时候，是可以不关联任何⽤户的，直到账号被下⼀次利⽤重新分发给新⼈。

增加书籍借阅信息管理好了借书的⼈，我们的图书馆管理系统还需要增加书籍管理系统，⽤来标记每本书籍⾃⾝的状态，⽐如该书籍的条码、RFID中的信息、是否允许借出图书馆、图书的类别、图书的借出时间、图书的借阅周期（时长）、图书的应归还时期等等信息。

这些都是图书馆⾃⾝作图书管理所需要信息⽽⾮书籍本⾝的信息。

因此我们需要在原始图书的基础之上扩展⼀个图书馆的书⽬实体Book Item，⾥⾯除了书籍⾃⾝的信息之外，还包含了该书管理过程中的信息。

更新之后的UML如下：增加检索和管理功能随着图书馆书籍越来越多，图书馆管理员需要对这些书籍进⾏分类有序放置、对特定的书⽬进⾏查找，顾客需要根据条件检索⾃⼰需要的书⽬。

uml建模实例100例UML（统一建模语言）是一种用于软件开发的标准建模语言，它可以帮助开发人员更好地理解、设计和实现软件系统。

下面是100个UML建模实例。

1. 用例图：描述系统功能和外部用户的行为。

2. 活动图：描述系统中的过程和活动，通常用来描述系统的业务流程。

3. 类图：描述系统中的类、属性和方法、关系等。

4. 对象图：描述系统中的对象及其关系。

5. 状态图：描述系统中的对象或类的状态和状态转换。

6. 序列图：描述系统中的对象或类之间的交互过程。

7. 协作图：描述系统中的对象或类之间的协作过程。

8. 构件图：描述系统的组成部分和它们之间的关系。

9. 部署图：描述系统的物理部署结构和组件之间的关系。

10. 通信图：描述系统中的对象之间的消息传递。

11. 包图：描述系统中的包和它们之间的关系。

12. 组合结构图：描述系统中的组成部分和它们之间的组合关系。

13. 时序图：描述系统中的对象或类之间的时间关系。

14. 交互概述图：描述系统中的对象或类之间的协作过程。

15. 系统顺序图：描述系统中的对象或类之间的时间关系。

16. 概念图：描述系统中的概念和它们之间的关系。

17. 数据流图：描述系统中的数据流和处理过程。

18. 流程图：描述系统中的过程和流程。

19. 参与者图：描述系统中的参与者和它们之间的关系。

20. 视图图：描述系统中的视图和它们之间的关系。

21. 规则图：描述系统中的规则和它们之间的关系。

22. 用例图扩展点：描述用例图中的扩展点和它们之间的关系。

23. 活动图扩展点：描述活动图中的扩展点和它们之间的关系。

24. 类图扩展点：描述类图中的扩展点和它们之间的关系。

25. 对象图扩展点：描述对象图中的扩展点和它们之间的关系。

26. 状态图扩展点：描述状态图中的扩展点和它们之间的关系。

27. 序列图扩展点：描述序列图中的扩展点和它们之间的关系。

28. 协作图扩展点：描述协作图中的扩展点和它们之间的关系。

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业务建模实例分析在我国十年前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类图「左⽿朵梵⾼」总第11期写在最前⾯的话声明：本⽂部分资料摘⾃维基百科，还有我多年⼯作的积累和总结。

本⽂很适合作为⼀个⼯具，就当是⼀本UML说明书，请记得收藏哦，在需要⽤的时候⽅便查阅。

什么是UML维基百科对UML的定义：UML（Unified Modeling Language）是⼀种开放的⽅法，⽤于说明、可视化、构建和编写⼀个正在开发的、⾯向对象的、软件密集系统的制品的开放⽅法。

UML展现了⼀系列最佳⼯程实践，这些最佳实践在对⼤规模，复杂系统进⾏建模⽅⾯，特别是在软件架构层次已经被验证有效。

这个语⾔由葛来迪·布区，伊⽡尔·雅各布森与詹姆⼠·兰宝于1994年⾄1995年间，在Rational Software公司中开发，于1996年，⼜进⼀步发展。

UML集成了Booch，OMT和⾯向对象程序设计的概念，将这些⽅法融合为单⼀的，通⽤的，并且可以⼴泛使⽤的建模语⾔。

UML打算成为可以对并发和分布式系统的标准建模语⾔。

UML并不是⼀个⼯业标准，但在Object Management Group的主持和资助下，UML正在逐渐成为⼯业标准。

OMG之前曾经呼吁业界向其提供有关⾯向对象的理论及实现的⽅法，以便制作⼀个严谨的软件建模语⾔（Software Modeling Language）。

有很多业界的领袖亦真诚地回应OMG，帮助它创建⼀个业界标准。

从维基百科的定义中，可以总结出⼏个关键点：UML是⼀个软件建模语⾔。

是⼀个事实上的⼯业标准；UML⽤于提供⾯向对象设计的理论和实现⽅法；UML提供了⼀系列最佳⼯程实践，在系统建模、软件架构设计层次⼗分有效。

进⼀步，我们可以总结出⼏个关键字：软件建模语⾔、⼯业标准、⾯向对象、系统建模、架构设计、最佳时间。

在UML系统开发中有三个主要的模型：功能模型：从⽤户的⾓度展⽰系统的功能，包括⽤例图。

UML类图说明1：⽰例这是⼀个使⽤UML表⽰的类图的结构，通过箭头，菱形，实线以及虚线来代表⼀些类之间的关系，后⾯将按照上⾯的例⼦⼀⼀介绍说明。

上图中，abstract 车是⼀个抽象类。

⼩汽车和⾃⾏车是继承了车的抽象类，实现了抽象类的⼀些抽象⽅法，他们之间是实现关系。

SUV继承⼩汽车，SUV和⼩汽车之间是泛化关系！轮胎，发动机和⼩汽车之间是组合关系。

学⽣和班级之间是聚会关系。

学⽣和⾝份证之间是关联关系。

学⽣和⾃⾏车之间是依赖关系。

2：具体分析2.1：泛化关系上⾯UML图中，SUV和⼩汽车之间是⼀种泛化关系，SUV is a ⼩汽车，泛化关系⽤⼀种带有空⼼的箭头来表⽰。

在代码中表现的⽅式就是继承⾮抽象类的⽅式。

2.2：实现关系上⾯UML图中，⼩汽车，⾃⾏车与抽象类车，之间是⼀种实现关系。

重要的是要继承抽象类，或者实现接⼝这种关系是实现关系，在UML类图中使⽤虚线带箭头。

在代码中表现的⽅式就是继承抽象类。

2.3：聚合关系上⾯UML图中，学⽣和班级之间是⼀种聚合关系，表⽰班级有学⽣聚合⽽来，采⽤实线空⼼菱形箭头表⽰。

与组合关系不同的是，整体和部分不是强依赖的，即使整体不存在了，部分仍然存在；例如，班级撤销了，学⽣不会消失，他们依然存在。

2.4：组合关系上⾯UML图中，轮胎，发动机和⼩汽车之间是⼀种组合关系，采⽤实线实⼼菱形箭头表⽰。

与聚合关系不同的是，整体和部分是强依赖的，即使整体不存在了，组合部分也不存在；例如，⼩汽车没有，⾃然轮胎和发动起，也不会存在了。

2.5：关联关系上⾯UML图中，学⽣和⾝份证是⼀种关联关系。

关联关系是⽤⼀条直线表⽰的；它描述不同类的对象之间的结构关系；它是⼀种静态关系，通常与运⾏状态⽆关，⼀般由常识等因素决定的；它⼀般⽤来定义对象之间静态的、天然的结构；所以，关联关系是⼀种“强关联”的关系；⽐如，乘车⼈和车票之间就是⼀种关联关系；学⽣和学校就是⼀种关联关系；2.6：依赖关系上⾯UML图中，学⽣和⾃⾏车之间是⼀种依赖关系。

分析业务模型-类图（ClassDiagram）（下）摘要：类图（Class Diagram）可能是⽤得最多的⼀种UML图。

类图的基本语法并不复杂，你可能最多学习两三天就可以掌握，然⽽要真正做到活⽤类图则可能需要⼏年的功⼒。

类图是锻炼⾯向对象分析（OOA：Object-Oriented Analysis）和⾯向对象设计（OOD：Object-Oriented Design）思想的重要的⼯具，是业务结构建模的重要⼯具。

本章将会有⼤量的实战练习，你的OOA思想将会接受极⼤的考验和提升。

本⽂全长1万6千多字，并且有⼏⼗张插图，由于篇幅过长特分为上、下两篇发出。

本⽂来⾃新书《活⽤UML——需求分析⾼⼿》的第3章。

作者：张传波⼤纲：上篇：3.1 ⾯向过程与⾯向对象3.2 类图的基础知识3.3 类之间的关系3.4 演练类之间的关系下篇：3.5 类的“递归”关系与“三⾓”关系3.6 考试管理系统——类图综合训练3.7 关于对象图3.8 ⼩结与练习如果你还没有阅读上篇，请先阅读！上篇链接：3.5 类的“递归”关系与“三⾓”关系这个⼩节是类图的进阶知识，有⼀点难度，但这些知识在需求分析⼯作中⾮常实⽤。

“递归”关系我在以前公司⾯试过的⼈数可能有数百⼈，如果⾯试者说他懂类图，那么我⼏乎100%会问这个问题：Windows操作系统中有⽂件夹与⽂件，请你⽤类图表达出⽂件夹与⽂件的关系。

经过前⾯的学习，你已经具备了能画出这个图的基本知识了，请你不要看后⾯的参考答案，先⾃⼰尝试完成这个题⽬。

很多⾯试者很快就会画出这样的图：图 1.30 ⽂件夹与⽂件关系1我会接着问这些问题：1)⽂件夹⾥⾯也可以有⽂件夹啊，这个怎样表⽰出来？2)⾥⾯的⽂件夹⾥⾯也可能有⽂件夹，咋办？很多⾯试者傻眼了，只有很少数⼈可以画出来。

其实画不出来也不⽤灰⼼，我刚学习类图时，也被这个题⽬⼀下⼦难倒了，后来看到参考答案后恍然⼤悟，同时对类图产⽣⼀种莫名的敬仰！图 1.31 ⽂件夹与⽂件关系2⽂件夹⾥⾯有⽂件夹，⾥⾯的⽂件夹⾥⾯有可能有⽂件夹，这可能是⽆穷⽆尽的“递归”啊！⽽这个包含关系可以⾃⼰指向⾃⼰，可以“⾃包含”，这个⽆穷“递归”的问题就解决了，实在太完美了！⽆论是弱包含还是强包含，都可以“⾃包含”。

1、请按下述要求作出类图。

* 一个年级里有3到5个班级。

* 一个班级有1到40名学生。

* 1个班级有1名担任班主任,在此基础之上外也可能有再加一名副班主任。

2、请按下述要求作出书橱的类图。

* 可以把书放到书橱里。

* 书橱的门有木制的门或玻璃制的门。

3、请按下述要求作出网上商店的类图。

* 为了一次可以购买多件商品，为每个顾客准备一个购物车。

* 购物车里可以装入10件商品。

* 顾客分会员及非会员两类。

4、请按下述要求作出公司的类图。

* 某公司部里有科，职员从属于某一个科。

* 科之间也有可能有上下级关系。

* 现在，一个科的职员数为5到30人。

* 科里的职员数将来有可能增减。

5、请按下述要求作出宾馆的类图。

* 客房分为套间，双人间，单人间3种。

* 套间里有3张床，双人间有两张床，单人间有一张床。

1、下面关于类的描述恰当的一项是A 表示商业流程或系统的控制流程B 表示使用该系统的人与系统功能之间的关系C 表示构件之间的依赖关系D 表示类的构造及类之间的静态关系E 表示对象之间消息的交互2、从下列选项中选出一项正确表示类的图3、下面是关于类的操作的描述，请选择一项错误的A 操作中可以标记参数B 操作是在类的最下端C 类作用域的操作是在操作名下面划线表示D 返回值是在分号（；）后标记的E 在分析建模阶段可以省略4、下面关于可见性package的描述正确的一项是A 所有的类都不可访问B 只有自身类可以访问C 所有的类都可以访问D 自身类以及同一个包中的类可以访问E 自身类以及继承该类的子类可以访问5、下面关于抽象操作的描述正确的是（多选）A 抽象操作是将通用的操作，多个类都可以访问B 在操作抽象下划线表示C 在继承了该类的子类中定义操作的内容D 实际并不进行操作E 表示的是对象之间是如何连接的6、下列类型的描述正确的是（多选）A 表示不依赖实现的抽象类B 表示依赖实现的具体类C 在类型上标记《pattern》标签D 在类型上标记《type》标签E 实现类可以有多个类型7、下面关于功能（utility）的描述正确的是A 表示类间关系的含义货使用的条件B 概括各个类中使用的全局变量或程序C 给各个类的参数赋值D 使类或参与者等具备特别的含义，从而进行分类7、下面关于模板类的描述正确的是A 具备网络化状态的类B 拥有聚集关系的类C 在子类中定义实现必须的类D 只能间接拥有实例的类E 根据赋给属性的值可以生成新的类8、下面哪项是表示N项关联9、下面关于类之间关联的排序的描述正确的是A 多重度大于1时，必须要进行排序B 表示有关联的类的实例包含顺序C 表示类之间的关联具有方向D 表示排序时用{abstract}E 如果无排序，必须要明确标识出10、下面关于可诱导性的描述正确的是（多选）A 表示关联类存在顺序性B 必须在关联的两端都标识出C 必须只在关联的一端标识出D 可以在一端或两端标识出E 表示有关联的类之间存在方向性11、从下面选项出选出正确的限定子图“一个年级有3~5个班级。

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、依赖总是单向的。