导航
1前言
2.1用例
2.2参与者
2.3系统
2.4子系统
3.1关联关系
3.2包含关系
3.3扩展关系
3.4泛化关系
3.5依赖关系
4结束语
1 前言
在建筑行业，大到百层的摩天大楼，小到两层的乡间别墅，在施工之前都需要设计。地基挖多深，使用什么样的主体框架，承重多少，客厅与卧室如何连通，厨房的排烟管在什么位置......建筑行业先设计后施工已经成为标准范式，即使盖一间公园的厕所，如果没有设计图纸，也会让人觉得不可思议，工人们更不知道如何动手。
反观软件行业，我们离传统的建筑设计，差的就不是一星半点了。以我自己的亲身经历为例，从业二十年间，从十来人的创业公司，到上万人的上市公司，真正把软件设计规划好的，少之又少，其中主要原因是管理决策者们很难提前意识到软件架构设计的重要性，另外在中国，一部分开发人员经历了项目的磨砺刚具备了设计经验，但35岁年龄已到，他们被迫转去了其它岗位......
建筑设计有上千年的历史了，而软件诞生不过区区几十年，虽然软件设计的思想、方法、工具无法媲美建筑领域的千年沉淀，但在软件设计中，UML无疑是最闪亮的那颗星。 我们知道图的表达能力远大于文字，在软件设计中，UML是图形表达的唯一通用标准，意味着使用不同技术的开发者之间，比如Python与C++开发者，不同的软件岗位之间，比如产品与开发，开发与测试，UML都是大家的通用沟通语言，并且以图形化的方式传递信息。
用例图是UML中最简单，使用最高频的图之一，它通常用于诠释“这个软件做了什么”。用例图的的表达非常简单并且通俗易懂，不论对外与产品、测试人员交流，对内与研发人员沟通，或是向完全不懂软件的领导汇报，用例图都是最得力的工具，因为它一眼就能看懂。
2 UML用例图中的元素
2.1 用例
用例为椭圆形，可表示功能、动作、行为、过程等。
2.2 参与者
参与者为人形，表示参与系统交互的角色，可为人、事物、外部系统等。
2.3 系统
内容
2.4 子系统
内容
3 UML用例图中的关系
3.1 关联关系
内容
3.2 包含关系
内容
3.3 扩展关系
扩展指的是一个用例对另一个用例行为的增强。
注：扩展与包含的箭头方向相反，这表明扩展取决于扩展用例而非基用例，扩展用例决定扩展的执行时机，基用例对此一无所知。
3.4 泛化关系
泛化类似于类的继承。
3.5 依赖关系
内容
4 结束语
本文是UML的开篇，这个系列会以通俗易懂的方式向大家呈现UML的基础知识，以及UML在项目中的应用示例，希望软件从业人员能够看懂UML，使用UML，并提升自己软件设计的质量。
<全文完>