标签：关系 复习 类图 关联 软件工程 Order 书籍 属性
类图
前言
copy自老师的PPT，不只有知识点，还有一些相关内容的介绍顺便复制进来了。 如有问题请多指教
1 类图的概念
1、类图
类图是描述类、协作(类或对象间的协作)、接口及其关系的图。
类图是逻辑视图的重要组成部分，用于对系统的静态结构建模，涉及到具体的实现细节。
- 在系统分析阶段，类图主要用于显示角色和提供系统行为的实体的职责；
- 在系统设计阶段，类图主要用于捕捉组成系统体系结构的类结构；
- 在系统编码阶段，根据类图中的类及它们之间的关系实现系统的功能。
2、类图的作用
类图常用来描述业务或软件系统的组成、结构和关系。
3、类图的组成元素
- 类
- 接口
- 协作
- 关系
- 注释
- 约束
- 包
2 UML中的类
类的表示
（１）类的定义
类是具有相似结构、行为和关系的一组对象的抽象。
（２）类的表示
（３）类的命名
由字符、数字、下划线组成的惟一的字符串；
采用CamelCase格式（大写字母开头，混合大小写，每个单词一大写开始，避免使用特殊符号）
类名的两种表示方法
- 简单名 Order
- 路径名 java::awt::Rectanget、businessRule::Order
（４）类的属性
属性描述了类的静态特征；
属性名一般第一个字母小写；
属性的定义格式
[可见性] 属性名 [:类型] [ ‘[’多重性[次序]‘]’] [=初始值] [{特性}]
说明：可见性包括+、-、#
例：#visibility:Boolean=false
colors:Color[3]
points: Point[2…* ordered]
name:String[0…1]
（５）类的操作
- 操作名的命名规范习惯采用和属性名相同的命名规则。
- 类的操作的定义格式
[可见性] 操作名 [(参数列表)] [:返回类型] [{特性}] - 例： +hide():Boolean
#create()
-attachXWindow(xwin:XwindowPtr)
（６）类的职责
职责指类承担的责任和义务。在矩形框中最后一栏中写明类的职责。
（７）类的约束
约束指定了类所要满足的一个或多个规则。 在UML中，约束是用花括号括起来的自由文本。
3 类图中的关系
- 一般意义上的关联关系
- 细化后关系的性质分为4种：
- 包含
- 泛化
- 依赖
- 实现
关联（association）
关联是模型元素间的一种语义联系，当类之间在概念上有连接关系时，类之间的连接叫做关联。
队员和球队之间的关联，可以用短语“队员为篮球队效力”来刻画，
图形表示为：
关联有名称、角色、多重性和导航性等语法。
（1）关联名
- 描述关联的作用；
- 通常使用动词或动词短语；
（2）角色
- 关联两端的类可以某种角色参与关联；
- 通常使用名词或名词短语；
（3）多重性
- 某个类有多少个对象可以和另一个类的单个对象关联；
在UML中，常用的关联的多重性表示格式如下：
0..1 0或1
1 1
0..*（0..n） 0或多个
* 0或多个
1..* （1..n） 1或多个
8 8
5，7..10 5或7~10
（4）导航性
- 用箭头显示导航性；
- 描述源对象通过链接访问目标对象；
- A类有一个成员变量保存的是B类的一个引用，也就是说由A类可以找到B类，可以画成下图所示
包含
一辆汽车有4个轮子，我们可以这样表示
你可能觉得这样表示还不太合适，汽车应该包含4个轮子，或者说轮子本来就属于汽车的一部分，那怎样画能更加贴切表示这样的关系呢？我们可以这样画：
聚合
- 类之间的一种整体与部分的关系
- 体现了一种层次结构，整体类位于部分类的上层，多个部分类处于并列的层次
组合
- 是一种特殊形式的聚合（强聚合），聚合中的每个部分只能属于一个整体；
- 表示类之间整体和部分的关系。
- 整体与部分具有相同的生存期。
关于聚合与组合
- “弱”包含表示如果部门没有了，员工也可以继续存在；
“强”包含表示如果部门没有了，员工也不再存在。 - 在做软件需求时，往往会将所有的包含关系画成“弱”包含，后面发现某些关系可以表示为“强”包含时，才转为实心菱形。
泛化
- 表示两个类元间“一般”与“特殊”的关系。
- 对应面向对象编程语言中类与类之间的继承关系。
- “is a kind of”关系，XX是一种XX
实现
- 表达一种说明元素与实现元素之间的关系；
- 类和接口之间的关系是实现关系，表示类实现接口提供的操作
- 显示一个类引用另一个类
依赖
- 显示一个类引用另一个类
- 你很爱你老婆，没有你老婆你活不下去，可以这样表示
- 如果一个烟鬼嗜烟如命，用类图可以这样表示：
- 你很爱你老婆，没有你老婆你活不下去，可以这样表示
- 软件开发中，往往会设计一些公用类，供别的类调用，如果这些公用类出问题了，那调用这些公用类的类都会因此而出问题。
- 依赖指的是类之间的调用关系，表现为成员变量、方法的参数或者对静态方法的调用。
关于依赖
假设你正在设计一个能显示公司全体成员的制表系统，公司的员工可以填写这个系统中的电子表格。员工要选择菜单来填写表格。在你的设计中，有一个Syetem（系统）类和一个Form（表格）类。System类的众多操作中有一个displayForm（f:Form），系统所要显示的表格取决于用户选择的表格。
这种设计的UML表示法可以画成如下
例
神州飞船
根据以下描述，画出相应的UML类图
- 神舟六号飞船是神州飞船系列的一种，它由轨道舱、返回舱、推进舱和逃逸救生塔等组成。
- 航天员可以在返回舱内驾驶飞船，轨道舱是航天员工作和休息的场所。在紧急的情况下，可以利用逃逸救生塔逃生。
- 在飞船两侧有多个太阳能电池翼，可以为飞船提供电能
运算类
简易画图软件
小李打妖怪
老张开车去东北
4 阅读类图
阅读顺序应遵循的原则
- 先看清有哪些类；
- 然后看看类之间存在的关系；
- 结合多重性来理解类图的结构特点以及各个属性和方法的含义
电子商务网站的静态模型
读图过程
- 读出类：
- 读出关系：从图中关系最复杂（也就是线最密集）的类开始阅读，本图中最复杂的就是Order类。
- OrderItem和Order之间是组合关系，根据箭头的方向可知Order包含了OrderItem。
- Order类和Customer、Consignee、DeliverOrder是关联关系。也就是说，一个订单和客户、收货人、送货单是相关的。
多重性：用来说明关联的两个类之间的数量关系
- Order类，有两个方法：dispatch()和close()，从名字中可以猜出它们分别实现“分拆订单生成送货单”和“完成订单”。而在DeliveOrder()类中则有一个Close()方法，同理它应该表示“完成送货”。而在OrderItem中有一个stateChange()方法和deliverState，不难猜出它就是用来改变其“是否交给收货人”标志位的
- 先调用Order的dispatch()方法，它将根据其包含的OrderItem中产品信息，来按供应商户分拆成若干个DeliverOrder。商户登录系统后就可以获取其DeliverOrder，并在执行完后调用close()方法。这时，就将调用OrderItem的stateChange()方法来改为其状态。同时再调用Order的close()方法，判断该Order的所有的OrderItem是否都已经送到了，如果是就将其真正close()
增强的辅助建模元素
- 导航箭头：类的实例之间只能沿着导航箭头的方向传递 ，在Order中可以获取其相应的Consignee，而从Consignee中是无法了解与其相关的Order的
- 角色名称：Customer端有一个“+Owner”字符串 ，这表示Customer扮演的角色是Owner，也能对关联进行命名
- 导出属性：是指可以根据其他值计算出来的特性，这种属性应在其名称前加上一个“/”符号。
- 限定符：在Order和OrderItem之间的组合关系中，OrderItem这端多了一个方框，里面写着“ProductId”。它在UML中称为限定符，存在限定符的关联称为受限关联。它用来表示某种限定关系。在本例中，它的用途是说明：对于一张订单，每一种产品只能用一个订单项
- 约束：用来说明规则，{xor}…
- 职责：在类的属性栏中添加注释行表示，或增加了一个新的分栏
5 如何建立类图
1、类图的抽象层次
- 概念类
描述应用领域中的概念，仅包含类名，不考虑细节。 - 分析类
分析不针对具体语言，包含一些类的细节特性。 - 设计类
针对具体的语言，考虑类的实现细节。
2、建立类图的步骤
- 分析问题域，确定需求；
- 寻找类，确定类的含义和职责；
- 定义类的属性和操作；
- 确定类之间的关系；
- 精化类和类间的关系；
- 绘制类图。
3、寻找类的方法
使用名词/动词寻找类：
- 收集相关信息
- 补充的需求规格说明
- 用例
- 项目说明文档
- 其他文档
- 分析信息
- 名词、名词短语 类或属性
- 动词、动词短语 操作
使用CRC分析法寻找类：
C-class（类）
R-responsibility（职责）
C-collaboration（协作）
CRC分析法是根据类所要扮演的职责来确定类。
根据边界类、控制类、实体类帮助分析系统中的类：
UML中类有三种主要的版型：边界类、控制类和实体类。
- 边界类：位于系统与外界的交界处。如：窗体、对话框、报表、以及表示通讯协议的类、直接与外部设备交互的类。
- 实体类：保存要放进持久存储体的信息。持久存储体就是数据库、文件等可以永久存储数据的介质。通常每个实体类在数据库中有相应的表，实体类中的属性对应数据库表中的字段。
- 控制类：是控制其他类工作的类。
例
需求描述
李小平是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计。
发现类
李小平是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计。
筛选备选类
- “李小平”、“人”、“家里”很明显是系统外的概念，无须对其建模；
- 而“个人图书管理系统”、“系统”指的就是将要开发的系统，即系统本身，也无须对其进行建模；
- 很明显“书籍”是一个很重要的类，而“书名”、“作者”、“类别”、“出版社”、“书号”则都是用来描述书籍的基本信息的，因此应该作为“书籍”类的属性处理，而“规则”是指书号的生成规则，而书号则是书籍的一个属性，因此“规则”可以作为编写“书籍”类构造函数的指南。
- “基本信息”则是书名、作者、类别等描述书籍的基本信息统称，“关键字”则是代表其中之一，因此无需对其建模；
- “功能”、“新书籍”、“信息”、“记录”都是在描述需求时使用到的一些相关词语，并不是问题域的本质，因此先可以将其淘汰掉；
- “计算机类”、“非计算机类”是该系统中图书的两大分类，因此应该对其建模，并改名为“计算机类书籍”和“非计算机类书籍”，以减少歧义；
- “外借情况”则是用来表示一次借阅行为，应该成为一个候选类，多个外借情况将组成“外借情况列表”，而外借情况中一个很重要的角色是“朋友”—借阅主体。虽然到本系统中并不需要建立“朋友”的资料库，但考虑到可能会需要列出某个朋友的借阅情况，因此还是将其列为候选类。为了能够更好地表述，将“外借情况”改名为“借阅记录”，而将“外借情况列表”改名为“借阅记录列表”；
- “购买金额”、“册数”都是统计的结果，都是一个数字，因此不用将其建模，而“特定时限”则是统计的范围，也无需将其建模；不过从这里的分析中，我们可以发现，在该需求描述中隐藏着一个关键类—书籍列表，也就是执行统计的主体。
得到候选类
书籍 计算机类书籍 非计算机类书籍 书籍列表
借阅记录 借阅记录列表
在使用“名词动词法”寻找类的时候，很多团队会在此耗费大量的时间，特别是对于中大型项目，这样很容易迷失方向。其实在此主要的目的是对问题领域建立概要的了解，无需太过咬文嚼字 。
职责分析
- 书籍类：从需求描述中，可找到书名、类别、作者、出版社；同时从统计的需要中，可得知“定价”也是一个关键的成员变量。
- 书籍列表类：书籍列表就是全部的藏书列表，其主要的成员方法是新增、修改、查询（按关键字查询）、统计（按特定时限统计册数与金额）。
- 借阅记录类：借阅人（朋友）、借阅时间。
- 借阅记录列表类：主要职责就是添加记录（借出）、删除记录（归还）以及打印借阅记录
限定与修改
- 导航性分析：Book与BookList之间、BorrowRecord和BorrowList之间是组合关系均无需添加方向描述，而Book与BorrowRecord之间则是双方关联，也无需添加。
- 约束：Book对象创建后就不能够被删除只能被修改，因此在Book类边上加上用自由文本写的约束 ；一本书要么属于计算机类，要么属于非计算机类，因此在ItBook和OtherBook间加了 “{Xor}”约束。
- 限定符：一本书只有一册，因此只能够被借一次，因此对于一本Book而言只能有一个RecordId与其对应。
补充
递归关系
如果面试的人说懂类图，公司100%会问这样一个问题Windows操作系统中有文件夹和文件，请用类图表达出文件夹和文件的关系。
接着又会被问到：
- 文件夹里也可以有文件夹呀，这个怎样表示？
- 里面的文件夹里面也可能有文件夹，咋办？
- 这个包含关系可以指向自己，可以“自包含”，这个无穷递归问题就解决了。
- 这种“递归”结构一旦展开就会形成一个树形结构，需求分析时，如果发现树形的业务结构，可以考虑使用“自包含”或者“自关联”来分析。
三角关系
公司和雇员的关系，要求列出公司和雇员至少3个关键属性
思考如下问题
- 薪金是雇员的关键属性吗？合同期、职位呢？
- 公司和雇员，这两者的关系在法律上是如何确立的
公司与雇员要签署劳动合同，劳动合同上会有薪金、合同期、职位这些重要的内容，那么薪金、合同期、职位算是雇员的属性吗？
在表示公司与雇员的关系的直线上，拉出一条虚线，虚线另一端连接劳动合同类，这样的类叫做关联类，关联类是对两个类的关系的进一步约束。
最开始你可能会认为薪金、职位、合同期似乎应该是雇员的属性，但现在应该认识到，这三个关键内容应该体现在公司和雇员的关系上，这些内容应该体现在劳动合同上。
公司、雇员、劳动合同的关系，还可以画成这样
这个图最能体现“三角”关系了，关联类也可以表达成这样的方式。但实际工作还是以关联类的方式来表达，关联类的表达方式更加贴切和专业一点。
在需求分析时，发现三个类形成了类似的“三角”关系，可以思考其中一个类是不是可能为关联类，但并不是所有的“三角”关系就一定会有关联类
将薪金、职位、合同期这些信息直接当成雇员的属性也不是不可以的，这跟我们做系统的目标有关系，如果只是做简单的员工信息管理，可能就没有必要将合同提炼出来，如果要做一个人事管理系统，就需要我们将业务模型分析的更加透彻。
关联类这样复杂的东西，客户是不大可能直接告诉你的，在需求分析中发现和提炼出关联类，这对需求的理解以及项目后期的设计将会有很大的帮助。
识别关联类
关于画类图
- 直线、几对几的关系、角色、箭头可以搭配使用，只要能准确反映出业务关系就可以了。
- 做软件需求分析时，如果觉得两个业务概念之间有联系，但暂时不能确定具体是怎样的，那么就先画一条线将两者连起来再说，随着你对业务的理解，这条线会进一步具体化，你可以为这条线添加更多的元素。
标签：关系,复习,类图,关联,软件工程,Order,书籍,属性 来源： https://blog.csdn.net/qq_43661601/article/details/111476378
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。