【需求工程】统一建模语言UML类图中关联、多样性和角色

UML类图关联、多样性、角色 完整解读这是UML类图的基础知识点分为图示样例 文字定义两部分我拆开逐点讲清楚。一、先看懂上面的建模样例人 ↔ 车辆1. 两个「类」人属性 姓名、出生日期车辆属性 车辆ID、生产年份中间实线代表两个类之间的关联关系关联名称是「拥有」。2. 多样性多重度图上数字1和0..*多样性写在关联线的两端描述一端的1个实例可以对应另一端多少个实例靠近「人」这端标注 1含义1台车辆只能属于1个人一辆车不能有多个车主。靠近「车辆」这端标注 0…*0 可以没有* 任意多台含义1个人可以0台、1台、多台车辆有人没买车有人有多辆车。整体关系一对多1对0或多一个人 → 0/多辆车一辆车 → 仅一个人。3. 角色图中虚线标注的文字角色写在对应类的一侧用来定义这个类在本次关联里的身份人这边角色所有者人在“拥有车辆”这件事里身份是车主、所有者。车辆这边角色自身拥有的车辆在关联里是被人所拥有的物品。4. 关联名称「拥有」写在两根多样性标注中间代表这条关联的业务语义人和车辆之间的关系动作是“拥有”。二、下方文字逐句翻译解释类之间的关联是通过边界来描述的。可选择性地为关联定义一个名称。两个矩形类之间的实线就是关联用来表达两个事物存在业务联系关联名称本例“拥有”是可选加的不加也合法加了方便看懂业务含义。另外多样性可以被注释在每一个关联的末端。多样性是关于类的实例层级的声明并且描述一个类中可以以一种特定的方式与另外一个类中所定义实例数量进行关联的实例数量。多样性多重度写在关联线两头它描述实例数量对应规则不是类与类的关系是真实数据行的对应关系举例子类“人”、类“车辆”实例就是张三、奔驰车、宝马车多样性1和0..*规定一条车辆数据只能绑定一条人数据一条人数据可以绑定0/多条车辆数据。在关联的一端或两端注释可选择性的角色能够进一步精炼出与关联相关的这个类的实例含义。角色是可选项两端可以都写、只写一端也可以不写作用区分同一个类在不同关联里的身份。拓展举例“人”既可以是车辆的「所有者」也可以是订单里的「购买人」用角色就能区分同一类在不同关系里的身份。三、补充关键知识点1. 常见多样性符号含义标注含义1有且仅有1个0..10个或1个可选最多一个0..*/*0个、1个、多个无上限1..*至少1个最多无限多2. 关联、多样性、角色三者分工关联线说明两个类有关系关联名说明是什么关系拥有、购买、租用多样性两边实例数量对应规则一对多、多对多、一对一角色这个类在关系里是什么身份所有者、商品、买家。3. 套回样例总结一句话一个所有者人可以拥有0台或多台自身拥有的车辆而每一台车辆只能归属1位所有者。回答2第一步先看这张图图一画了什么这张图描述了“人”和“车辆”在现实世界中的归属关系。两个对象类人关注他的姓名和出生日期。车辆关注它的车辆ID和生产年份。一条关系线关联叫做“拥有”。两个“身份标签”角色站在“人”这边角色叫“所有者”说明这个人是以车主的身份参与关系的。站在“车辆”这边角色叫“自身拥有的”说明这辆车是被拥有的资产而不是租的或借的。两串数字多样性 / 多重性图中标注了0.虽然有点模糊但结合上下文它通常是0..*或0..1这类符号的简写或OCR识别偏差。我们重点理解它的含义。第二步用图二的“规则”来解读这张图图二告诉我们类图上的线条、数字和标签分别有什么用。结合图一1. 什么是“关联”就是那条连线图二说类之间通过边界连线来描述关系。图一实例人和车辆之间画了一条线名字叫“拥有”。这明确表示这两个类在业务上是有联系的不是孤立存在的。2. 什么是“角色”就是线两端的身份标签图二说在关联的一端或两端注释角色能进一步精炼类的实例含义。图一实例如果没有角色你只知道“人和车有关系”但具体是车主司机还是代驾说不清。在人的那一端标上“所有者”说明人在这段关系里是“车主”。在车的那一端标上“自身拥有的”说明车在这段关系里是“被拥有的财产”。作用消除歧义。明确告诉你这里的“拥有”是“所有权归属”而不是“临时使用权”。3. 什么是“多样性多重性”就是线两端的数字图二说多样性是关于实例层级的声明描述“这一端的一个实例能关联到另一端多少个实例”。图一实例假设数字是0..*或1我们按标准逻辑推演看“人”这一端如果写的是0..*意思是“一辆车可以被 0 到多个 人拥有吗”不通常一辆车只有一个法定车主。所以更合理的解读是这里的数字在约束“人的数量”。正确的看图方法数字写在哪一端就约束哪一端的数量。假设写在车辆那端是0..*零到多写在人这端是0..1零或一。翻译成业务规则一个人所有者可以拥有 0 辆或多辆0…*车。有人没车有人是土豪有多辆。一辆车自身拥有的只能被0 个或 1 个0…1人所拥有。新车未售出时是0个主人卖出后是1个主人杜绝了一辆车登记在两个人名下的歧义。第三步三者合体起到什么作用把关联线角色标签多样性数字结合起来就能精准地定义出一条“业务铁律”不需要再用大段文字描述。这张图最终想表达的唯一、精准含义是在这个系统中我们只关心“所有权”关系。一个人作为所有者可以拥有任意多辆车包括零辆而一辆车作为被拥有的资产最多只能归属于一个人也可能暂时没主人。总结为什么要费劲画这个如果没有角色和多样性只用一条线写个“拥有”程序员可能会懵是“父子关系”的拥有继承是“司机开车”的拥有使用是“车主”的拥有所有权加上角色明确了是“所有者/资产”加上数字多样性明确了是一对多还是多对多。这样后续建数据库表比如外键怎么放、写代码逻辑比如校验一个人名下最多几辆车就有了绝对精确的依据产品经理和开发就不会吵架了。多样性 - 示例由上图判断一下描述是否正确三名导演可以合作导演一部影片。判断该描述不正确错误。根据你提供的 UML 类图或领域模型“三名导演合作导演一部影片”是不被允许的。为了帮你彻底看懂这张图我们分三步来拆解图中的“多重性多样性”约束1. 复习 UML 多重性的读法关键在 UML 中靠近哪个类的数字就约束“这个类的实例”能关联对方“多少个”实例。例如A ——— B如果 A 旁边写着1B 旁边写着0..*含义是一个 A 实例可以关联 0 到多个 B 实例而一个 B 实例必须且只能关联 1 个 A 实例。2. 针对“导演”与“电影”的关联重点图里关于“由某某执导”这条关联线的约束是靠近“导演”这一端写的是1含义一部电影即一个电影实例必须恰好关联 1 位导演。这是强制性的一对一或严格的一对一上限约束这意味着系统规定“一部电影只能有唯一的导演”。靠近“电影”这一端写的是1..3含义一位导演可以执导 1 到 3 部电影。这约束的是“一位导演名下可以挂几部电影”而不是“一部电影可以有几位导演”。3. 结论与陷阱提示你的描述是“三名导演合作拍一部电影”这意味着“一部电影”对应“3 个导演”。这在逻辑上违反了导演端写的1上限为 1的强制性约束。正确的解读是在这个模型里一部电影只能由 1 位导演执导但反过来这 1 位导演可以同时执导 1 到 3 部不同的电影。特别提示帮你避免混淆图中电影端也写着1..3它可能让你误以为“一部电影可以有 1 到 3 个导演”。但请一定看准数字所在的位置——1..3写在电影的对面靠近导演一侧它是在说导演的能力上限而不是电影的名额上限。如果想让“三位导演合拍一部电影”成立导演那一端的数字必须改成1..3或*而不是现在的1。