UML用例图

1. UML用例图

UML(Unified Modeling Language)，统一建模语言,又称标准建模语言，是为软件系统建立可视化模型。主要包括用例图、时序图、协作图、活动图、部署图、构件图、类图、状态图等等。
  
 之前有写过UML时序图： 产品经理必备之UML时序图 
  
 用例图（Use Case Diagrame）是UML的一种，主要用来描述用户、需求、系统功能之间的关系，能够充分展示一个外部用户能够观察的系统功能模型图，以一种可视化的直观方式理解系统的功能需求，以便使系统用户更容易理解这些元素的用途，也便于开发人员最终实现这些元素。
  
 用例图是跳出当前系统，站在用户的角度去看系统，思考系统功能，这样我们能更加理解业务，表达清楚需求。从用户的视角，我们不会使用专业术语去进行业务的沟通，可以做到真正以用户为中心去获取需求，转化为产品服务。
  
 用例图可以帮助我们更全面的考虑系统内事物之间的互相影响，关注整体的运行规律，而不是只考虑个别事物的情况。
                                                                                  
  1、参与者 ：是系统外部的一个实体，它以某种方式参与了用例的执行过程。参与者不一定是人，也可以是部门，也可以是外部系统，也可以是其他事物。通常用人形图标表示。
  
  2、用例 ：是对系统的用户需求（主要是功能需求）的描述，用例表达了系统的功能和所提供的服务，说明了系统是如何与最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。通常用椭圆表示。
  
 用例注意事项：
  
       用例粒度的确定，没有标准，只能根据实际情况分析。一个大型系统，可能会有上百个用例，一个小产品，也许只有几个用例。
  
       一个用例是一个完整的使用场景，不是零散的动作步骤。比如，拿起手机打电话是个完整的场景，拿起手机只是一个步骤。
  
       一个用例有一个明确、独立的目标，如果一个用例包括多个目标，则可再逐层细化出子用例。
  
  3、系统边界 ：将系统内外分开，参与者在外面，用例在里面。边界内的用例，就是系统要实现的事情。通常用矩形框表示。
  
  4、关系： 
  
 （1）关联关系：用一条实线表示，这条实线一般有三种形式：无箭头、有指向用例的箭头、有指向执行者的箭头。箭头的方向代表了数据流向或谁启动谁。
  
 （2）归纳（泛化）关系：表示参与者与参与者之间、用例与用例之间的关系。一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化。
  
         用带空心箭头的实线表示，箭头指向被泛化的用例，即子用例指向父用例，泛化是从下到上的过程。（子用例继承父用例所有的结构、行为和关系，是父用例的一种特殊形式。）
  
 （3）包含关系：表示用例与用例之间的关系，其中一个用例（父用例）的行为包含了另一个用例（子用例）的行为。
  
      用虚线箭头+表示，箭头指向被包含的用例。一般是父用例包含很大的范围，专门抽出子用例来着重表达，又或者是复用用例。
  
 （4）扩展关系：表示用例与用例之间的关系，是在特定条件下，由扩展用例指向被扩展用例。
  
       用虚线箭头+>字样，箭头指向被扩展的用例。拓展用例是在特定条件出现时，才会被执行的用例。
  
 1、不是每个需求都要画用例图，要视情况而定，简单的需求完全可以不用画。
  
 2、画图是为了表达、传递信息，当我们画用例图时，不管画的多么酷炫，本质都是在分析业务场景、系统功能性需求，并描述出来。
  
  阅读原文 
  
 对产品经理感兴趣的朋友，可以移步“ 需求管理 ”，期待共同交流。

2. 一文读懂 UML 用例图

当你脑子里有一个商业案例时，你该怎么向老板介绍呢？一大段文字，或是动手写个 Demo？老板很忙，老板也不见得懂你所说的“高大上”技术，有没有那种实现成本较低但又包含较多信息的表现方式呢？有，画张图呗！
  
 今天起再开个专题，谈谈我们开发中常用到的一些图形建模手段。前言结束，我们从 UML 视图启航。
  
 UML——Unified Modeling Language——统一建模语言，是业务建模阶段最常用和最重要的一种视图。由于它简单易懂，常常用于跨组织的文档或演示的说明中；这里所谓的跨组织指的不仅仅是开发部门间，而是指跨产品、设计、测试、运维等等部门的业务交流中。UML 设计中，第一张图一般都是用例图：是的，就是那个有“小人”的图。
  
 用例图主要有三个部分组成：用例（Use Case）、参与者（Actor），以及它们互相间的关系（Relationship）；形式上就是用椭圆、小人，以及箭头的连线组合。
                                          
 我们先不细说椭圆或是箭头的具体含义。我觉得讲用例图最好还是从具体的 Use case 入手为好。我们试着设计一款简单的银行 APP，它包含注册、登陆、交易等等操作。我们一步步拆解挥着用例图的过程。
  
 画用例图的第一步通常是拖出一个巨大的矩形块，并将其命名为我们的目标系统——Banking App。一个用例图一般只会有一个 System，之后我们会把所有该系统相关的是功能（“用例”）放置在系统内部，系统的相关方（“参与者”）放置在系统的左右两侧。
                                          
 第二个绘制元素就是参与者，即系统相关方，可以是人、组织、外部设备，或是其他系统。在我们这个银行案例里，该 App 的相关方有两个：就是客户（Customer）和银行（Bank）。
                                          
 通常来说，一个用例图中会有两三个参与者，我们会把主要参与者放在系统左侧，次要参与者（主要参与者的回应方）放在右侧；显然我们的 App 主要是面向客户的，所以把客户放在了左边。
  
 第三步就是在系统内添加具体的用例，也就是该系统所提供的功能或是业务块。我们的银行 APP 比较简单，只提供如下业务：
                                          
 第四步，我们再把参与者与用例串联起来，就是我们所说的关系（Relationships）。用例图中，关系还可以继续细分：
                                                                                                                          
 最后，所有 UML 视图事实上都可以加注释，专业术语叫延伸（Extension points）和批注（Note）；这两种注释性质形同，都是起说明作用：
                                          
 好了，UML 用例图大体就讲完了。我们再回顾一下用例图的使用场景，在产品设计阶段，我们可以使用用例图为用户、系统和功能服务建立起抽象关系，以便描述产品所呈现的外部动态特征。在一些大厂中，通常由产品经理或是设计师来首先绘制 UML 用例图，再交于开发团队实现。
  
 我们举了一个银行 App 的例子，事实上有点大了；现实开发中，一个 Use Case 图通常只对应的一个简单的业务流而已。我们自己在写用例图时，也要注意在宏观层面将联系紧密的功能模块抽象为一个简单的 Case，然后逐步地为这些较大的功能模块画出细分 Case 的用例图。

3. 如何应用UML用例图描述软件系统的用户需求

用例图当然很好用，不然RUP（Rational Unified Process，统一软件开发过程，统一软件过程)也不会让用例驱动作为核心方法论之一，当然用例图自身也有很多不足，需要其它技术作补充。


?


一、优点：


?


简洁、直观。是的，确实比较直观，几个小人人、几个椭圆，外加几条不多的线，用一个矩形一框就出来了，了不起再弄个用例描述，系统交互行为很清晰地表达出来。
规范、易理解。用例图是UML建模里比较常用的一个图，你用，我用，大家都用，并且标识、要素等均符合UML2中的约定，并且不依赖开发语言，所以说它和其它图一样规范因为规范所以对UML建模用户来说是易理解的。
用户导向、描述精准。用例方法完全是站在用户的角度上（从系统的外部）来描述系统的功能的。我们不管系统内部实现功能的机制，仅仅把系统看作一个黑盒，然后参与者与其进行交互，也就是用例是基于用户场景的，所以能更精准地表达用户功能需求。
需求与设计分离。因为用例图是站在系统外的视角描述系统需求的，所以并没有介入到系统内部实现细节，这就让需求和设计工作分离开来，条理清晰。
便于设计测试用例。用例图描述的就是一个用户场景，测试设计人员正好可以根据用例图设计测试用例。
边界清晰。一个矩形框把系统边界清晰、明确地表达出来，便于设计人员据此把握系统范围。
敏捷。用例图允许我们讲故事、写卡片，允许我们比较敏捷地实现功能需求方面的管理与交流。


?


二、不足：


?


不能表达非功能需求。用例图是描述用户功能需求的工具，对于可靠性、性能等非功能需求无能为力。
对不懂UML的客户或程序员来说难以理解。对UML支持者来说，用例图可能是规范的、清晰的、简单的、易理解的，但对并未掌握UML建模技术的人来说理解那些椭圆并非易事，再说还有一系列如同伪代码似的事件流。
粗粒度。是的，用例图不涉及设计实现细节，只是一个功能划分，粒度非常粗，很多细节无从描述，需要用其他工具进行辅助说明。


?


三、常见的错误用法和问题：


?


客户看不懂用例图，又要提供一个高大上（画UML图）的需求规格文档。这时候怎么办呢？作者建议画客户需要画的，然后把用例图制作成一个个卡片去跟客户讲故事，客户不会连故事都听不懂吧除非你讲故事的水平比画图的水平还拙劣。
架构师或程序员看不懂用例图。看不懂的话这些用例委实就成了摆设，这时又该怎么办呢？对的，仍旧讲故事，说业务场景并用用例规约加以辅助说明。
用例图涉及到实现细节。这个要加以避免，如果过早介入系统内部实现细节，过多的系统内部设计描述会让客户和程序员疲惫不堪。
系统边界模糊不清。建议用例图绘制时从上往下画，比较复杂的子系统可以拆在不同的用例图中。
用例过多。系统总的用例数不宜超过50个，建议最好是20-30个。过多的用例必定会有过多的Association、include、extend、generalize等关系，各种关系错综复杂违背了我们使用用例图的初衷。