程序员都该懂的 UML 规范!

640?wx_fmt=gif

640?wx_fmt=jpeg

作者 | 码匠笔记

责编 | 胡巍巍

在团队协作过程中最常见的就是开会、开会最常用的就是图,而图中最常见的就是流程图、时序图、类图,这三个图可以清楚的描述你想解释的内容。

学好类图不仅仅能帮助自己更清楚的梳理业务,还能提高开会效率。

但是话说回来,你是否真的看懂别人画的图了?或者你真的会画吗?今天就和大家一起学习一下怎么画类图。

640?wx_fmt=png

上图是我模拟出来的一个场景和大家具体说一下类图究竟应该怎么画才对。图中讲的是这样一个「故事」:

一个公司下面有很多部门,公司和部门是不可分割的。

码农属于一个部门,但是如果部门解散了,码农依然依然是码农。

码农无时无刻在用手机,只有工作时间才会使用 Mac。

Mac 是一种电脑,电脑是“可计算处理器”的一种实现。

下面我们就逐一介绍下这些关系。


640?wx_fmt=png

泛化关系(generalization)


泛化关系为 is-a 的关系;两个对象之间如果可以用 is-a 来表示,就是泛化关系。

640?wx_fmt=png

泛化关系用一条带空心箭头的直接表示。如图为例, Mac 和电脑就是泛化关系,通常在程序里面泛化表现为继承于非抽象类。


640?wx_fmt=png

实现关系(realization)


640?wx_fmt=png

实现关系用一条带空心箭头的虚线表示。如图为例,电脑和可计算处理器就是实现关系,通常程序里面实现关系表现为继承抽象类。比如我们平时写的 Readable,Printable等接口的实现。


640?wx_fmt=png

聚合关系(aggregation)


640?wx_fmt=png

聚合关系用一条带空心菱形箭头的直线表示,如图码农和部门就是聚合关系。与组合关系不同的是,整体和部分不是强依赖的,即使整体不存在了,部分仍然存在。如图为例, 部门撤销了,码农换一个工作还是码农嘛。


640?wx_fmt=png

组合关系(composition)


640?wx_fmt=png

组合关系用一条带实心菱形箭头直线表示,与聚合关系一样,组合关系同样表示整体由部分构成的关系,不同之处在于整体和部分是强依赖关系,如果整体不存在了,部分也不复存在。

如图为例,如果公司倒闭了,那么何来部门呢?


640?wx_fmt=png

关联关系(association)


640?wx_fmt=png

关联关系通常用一条直线表示,当然如果需要标明方向可以添加箭头。它是描书不同的类对象之间的关系,通常不会随着状态的变化而变化,可以理解为被关联者属于关联者的一部分。

如图为例,手机就是码农的一部分,不会因为他上班与否而变化所属关系。通常情况在程序里面以类变量的方式表现。


640?wx_fmt=png

依赖关系(dependency)


640?wx_fmt=png

依赖关系是用一套带箭头的虚线表示,他通常描述一个对象在运行期间会用到另一个对象的关系。

如图为例码农只有在工作的时候才会用到 Mac 电脑,所以这种依赖关系是依赖于运行状态的。通常情况下是在程序里面通过构造函数、形参等体现。


640?wx_fmt=png

回顾总结


到这里我们再次回顾一下开篇的图片是不是更加理解里面的连线了?所以我们在绘图过程中一定要非常注意这个线和箭。

640?wx_fmt=png

不过话说回来,死记硬背这些东西确实很难,于是我自己想了一个打油诗,帮助自己来记忆,你也可以来试一下。

实箭泛化虚实现

虚线依赖实关联

空菱聚合实组合

项目沟通图常见

所以你学会了吗?

作者:码匠笔记,老哥先后就职于 ThoughtWorks 、阿里巴巴等互联网公司 ,擅长 Java 、Scala 等多种语言 ,并熟悉前端开发 ,从事多年全栈开发工程师 。热衷于技术分享、博文创作、开源社区、开源工具等 。本文首发于个人公众号“码匠笔记” ,有兴趣的欢迎关注。

声明:本文为作者投稿,版权归其个人所有。

【END】

640?wx_fmt=jpeg

作为码一代,想教码二代却无从下手:

听说少儿编程很火,可它有哪些好处呢?

孩子多大开始学习比较好呢?又该如何学习呢?

最新的编程教育政策又有哪些呢?

下面给大家介绍CSDN新成员:极客宝宝(ID:geek_baby)

戳他了解更多↓↓↓

640?wx_fmt=jpeg

 热 文 推 荐 

☞ 消失的手机玩家

 JavaScript 太糟糕,JVM 有妙招!

 他 25 岁进贝尔实验室,32 岁创建信息论,40 岁办达特茅斯会议 | 人物志

☞真の硬核粉丝!小学生也参加杨超越杯,作品优秀!

☞ 阿里半跪过,任正非差点跳楼,京东被骗光钱:成年人的生活哪有容易二字?

不改变比特币, 如何扩容?

☞强推!盘点阿里巴巴 15 款开发者工具 | 程序员硬核评测

☞17篇论文入选CVPR 2019,百度AI都在关注什么?(附论文地址)

☞ 她说:为啥程序员都特想要机械键盘?这答案我服!

 
 

System.out.println("点个在看吧!");
console.log("点个在看吧!");
print("点个在看吧!");
printf("点个在看吧!\n");
cout << "点个在看吧!" << endl;
Console.WriteLine("点个在看吧!");
Response.Write("点个在看吧!");
alert("点个在看吧!")
echo "点个在看吧!"

640?wx_fmt=png 你点的每个“在看”,我都认真当成了喜欢
<think>嗯,用户这次的问题非常明确:"如何绘制用例图UMLusecasediagram",结合引用的资料来看,ta应该是在学习UML建模的基础知识。用户提供的四份引用内容相当全面:引用[1][2]明确了用例图的定义和作用,引用[4]特别澄清了常见误区,而引用[3]则提到实际使用中的注意事项。不过注意到引用[3]提到"没多少人能看",这可能暗示用户在实际操作中遇到过理解障碍。考虑到用户连续两次询问用例图相关的问题(上次是基础概念,这次是绘制方法),推测ta可能是:1)软件工程专业学生完成作业;2)转行学习产品设计的职场新人;3)需要紧急交付UML文档的开发者。从问题简洁度看,更像是前两者。需要重点解决的核心矛盾是:如何把理论规范转化为可操作的绘图步骤。特别要注意引用[4]强调的"避免技术细节"这个易错点,以及引用[2]提到的四种关系类型——这些都是新手最容易混淆的部分。在专业层面需要分层解答:先明确绘图目标(引用[1]提到的跨部门沟通作用),再解析图形元素(actor用小人图标这个细节很重要),最后演示关系表达(比如include和extend的区别示例)。工具推荐应该保持中立,既要有Visio这类传统工具,也要提plantUML程序员友好选项。突然想到个潜在痛点:用户可能混淆了用例图和流程图。虽然回复里已经区分了"功能需求"与"流程步骤",但在实际案例部分有必要强化这点。比如"用户登录"用例只需要一个椭圆,不需要画输入账号密码的步骤。工具推荐部分可以补充:用户如果是学生,用免费的draw.io就够了;如果是团队协作,LucidChart可能更适合。但不必主动询问用户身份,保持答案普适性更重要。</think> 根据您的需求和引用材料,以下是绘制UML用例图的系统化步骤及核心要点: --- ### **一、用例图的核心构成** | 元素 | 符号 | 作用 | 规范示例 | |------|------|------|---------| | **参与者(Actor)** | 👤 小人图标 | 系统外部交互对象(用户/其他系统) | `顾客`、`支付系统` | | **用例(Use Case)** | ⚪ 椭圆 | 系统提供的独立功能单元 | `下单`、`支付` | | **关联关系(Association)** | ➖ 实线 | 参与者与用例间的交互 | `顾客`——`下单` | | **包含关系(Include)** | ➕ ⌵虚线+`<<include>>` | 基础用例必须调用的子功能 | `下单`→`支付` | | **扩展关系(Extend)** | ↗️⌵虚线+`<<extend>>` | 特定条件下触发的扩展功能 | `登录`→`重置密码` | | **泛化关系(Generalization)** | ⬆️ 三角箭头实线 | 父子用例/参与者的继承关系 | `VIP顾客`→`顾客` | > 📌 **关键原则**(引用[4]强调): > 1. **聚焦业务功能**(非技术细节),如`生成报表`而非`调用API` > 2. **命名规范**:"动词+名词"结构(`取消订单`而非`订单取消操作`) > 3. **避免步骤细节**(这是活动图/时序图的任务) --- ### **二、绘制步骤(含示例)** #### **步骤1:识别参与者** > ▪️ 谁使用系统? (例:顾客、管理员) > ▪️ 外部关联系统? (例:物流平台) #### **步骤2:定义用例** > ▪️ 每个参与者需执行的核心功能 > ▪️ 用例必须**独立可交付业务价值**(引用[2]) > ```mermaid > graph LR > 顾客-->|下单|UC1(订单管理) > 顾客-->|支付|UC2(支付处理) > ``` #### **步骤3:建立关系** - **包含关系**:用例A必须调用用例B ```(例:下单→支付)``` - **扩展关系**:用例B仅在用例A特定条件下触发 ```(例:登录→忘记密码)``` #### **步骤4:分层抽象** > ▪️ 泛化关系优化结构: > ```mermaid > graph TD > 用户(用户)-->顾客 > 用户-->管理员 > 顾客-.->|<<extend>>|UC3(申请退款) > ``` #### **步骤5:工具输出** > ▪️ 推荐工具:**PlantUML**(代码生成)、**Draw.io**(可视化) > ▪️ 导出格式:PNG/SVG(方便跨团队协作,引用[1]) --- ### **三、典型错误规避(引用[4])** | 错误类型 | 纠正方案 | |----------|----------| | 描述操作步骤 | 改用活动图(如登录流程细节) | | 包含技术接口 | 删除`调用API`类用例 | | 用例粒度不一致 | 合并细碎用例(如`输入账号`+`输入密码`→`登录`) | | 缺少扩展条件 | 标注触发条件:`<<extend>>: 支付超时` | --- ### **四、应用场景对比** | 场景 | 是否适用用例图 | 替代方案 | |------|----------------|----------| | 需求讨论会 | ✅ 最佳(业务可视化,引用[1]) | - | | 开发接口设计 | ❌ 不适用 | 时序图/类图 | | 用户操作流程 | ⚠️ 部分适用(需结合活动图) | 活动图 | > 💡 **经验提示**:用例图是**业务需求沟通的通用语言**(产品/研发/测试通用),而非技术设计方案[^1][^2]。 ---
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值