UML用例图

Posted 2023-04-04

参考技术A UML(Unified Modeling Language)，统一建模语言,又称标准建模语言，是为软件系统建立可视化模型。主要包括用例图、时序图、协作图、活动图、部署图、构件图、类图、状态图等等。

之前有写过UML时序图： 产品经理必备之UML时序图

用例图（Use Case Diagrame）是UML的一种，主要用来描述用户、需求、系统功能之间的关系，能够充分展示一个外部用户能够观察的系统功能模型图，以一种可视化的直观方式理解系统的功能需求，以便使系统用户更容易理解这些元素的用途，也便于开发人员最终实现这些元素。

用例图是跳出当前系统，站在用户的角度去看系统，思考系统功能，这样我们能更加理解业务，表达清楚需求。从用户的视角，我们不会使用专业术语去进行业务的沟通，可以做到真正以用户为中心去获取需求，转化为产品服务。

用例图可以帮助我们更全面的考虑系统内事物之间的互相影响，关注整体的运行规律，而不是只考虑个别事物的情况。

1、参与者 ：是系统外部的一个实体，它以某种方式参与了用例的执行过程。参与者不一定是人，也可以是部门，也可以是外部系统，也可以是其他事物。通常用人形图标表示。

2、用例 ：是对系统的用户需求（主要是功能需求）的描述，用例表达了系统的功能和所提供的服务，说明了系统是如何与最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。通常用椭圆表示。

用例注意事项：

     用例粒度的确定，没有标准，只能根据实际情况分析。一个大型系统，可能会有上百个用例，一个小产品，也许只有几个用例。

     一个用例是一个完整的使用场景，不是零散的动作步骤。比如，拿起手机打电话是个完整的场景，拿起手机只是一个步骤。

     一个用例有一个明确、独立的目标，如果一个用例包括多个目标，则可再逐层细化出子用例。

3、系统边界 ：将系统内外分开，参与者在外面，用例在里面。边界内的用例，就是系统要实现的事情。通常用矩形框表示。

4、关系：

（1）关联关系：用一条实线表示，这条实线一般有三种形式：无箭头、有指向用例的箭头、有指向执行者的箭头。箭头的方向代表了数据流向或谁启动谁。

（2）归纳（泛化）关系：表示参与者与参与者之间、用例与用例之间的关系。一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化。

        用带空心箭头的实线表示，箭头指向被泛化的用例，即子用例指向父用例，泛化是从下到上的过程。（子用例继承父用例所有的结构、行为和关系，是父用例的一种特殊形式。）

（3）包含关系：表示用例与用例之间的关系，其中一个用例（父用例）的行为包含了另一个用例（子用例）的行为。

     用虚线箭头+<>表示，箭头指向被包含的用例。一般是父用例包含很大的范围，专门抽出子用例来着重表达，又或者是复用用例。

（4）扩展关系：表示用例与用例之间的关系，是在特定条件下，由扩展用例指向被扩展用例。

      用虚线箭头+<<extend>>字样，箭头指向被扩展的用例。拓展用例是在特定条件出现时，才会被执行的用例。

1、不是每个需求都要画用例图，要视情况而定，简单的需求完全可以不用画。

2、画图是为了表达、传递信息，当我们画用例图时，不管画的多么酷炫，本质都是在分析业务场景、系统功能性需求，并描述出来。

阅读原文

对产品经理感兴趣的朋友，可以移步“ 需求管理 ”，期待共同交流。

UML建模（一）---UserCase用例图

参考技术A

用例图源于Jacobson的OOSE方法，用例图是需求分析的产物，描述了==系统的参与者与系统进行交互的功能，是参与者所能观察和使用到的系统功能的模型图==。它的主要目的就是帮助开发团队以一种可视化的方式理解系统的功能需求，包括基于基本流程的“角色”关系以及系统各个功能之间的关系。它通过用例（Use Case）来捕获系统的需求，再结合参与者（Actor）进行系统功能需求的分析和设计。

用例图有四部分组成： 用例（Use Case）、参与者（Actor）、系统边界、关联

在一个系统开发前，我们必定首先要确定系统的用户，系统的用户就是系统的参与者。除此以外，我们还会想打，我们开发的系统与其他的系统有什么关联？因此，系统的参与者可分为两类，一类是人，包括系统的使用者、维护者等，另外一类是其他系统。

用例（Use Case）是==参与者（Actor）可以感受到的系统服务或功能单元。==

任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的用例，所以识别用例的最好方法就是==从分析系统参与者开始，在这个过程中往往会发现新的参与者。==

用例是有粒度的，用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。

所谓系统边界是指系统与系统之间的界限。把系统边界以外的同系统相关联的其他部分称之为系统环境。

为了减少模型维护的工作量、保证用例模型的可维护性和一致性，可以在用例之间抽象出 包含（Include）、扩展（Extend）和泛化（Generalization） 这几种关系

1、 包含关系 是指用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。
包含关系用来把一个较复杂用例所表示功能分解成较小的步骤。包含用例是必须的，如果缺少包含用例，基用例就不完整；包含用例必须被执行。
箭头指向：指向分解出来的功能用例。

用例图虽然作为UML中的一部分，给团队成员提供一种形象的系统表述，但是，用例图也由它本身的缺陷，用例图一般在需求分析阶段就给出了，有的时候对于系统的需求，并不能很好的表述，对于没有UML背景的人来说，更是一种痛苦与折磨，但是，话又说回来，作为软件开发人员，没有UML背景是说不过去的；有的时候，我们需要借助用例图对客户讲解系统，而让客户去理解用例图则是很困难的。
虽然，在用例图中的关系种类不是很多，也不是很复杂，但是UML的表示确实很让人费解的，别的还好，特别是扩展（Extend）和包含（Include），表示方式都一样的，仅靠上面的说明来进行区分，在一个复杂的系统中，是很容易看错的，从而理解出错，同时，扩展（Extend）中的箭头指向一直是让我很费解的，为什么需要让箭头指向基用例呢？
鉴于用例图有的时候并不能清楚地表达功能需求，开发中大家通常用用例描述表来补充某些不易表达的用例，请大家参考下图：