如何在需求建模中正确使用用例图表达需求

1. 如何在需求建模中正确使用用例图表达需求

用UML建模时，对软件开发过程是有要求的，必须是用例驱动，以架构为中心，迭代和递增的开发.

需求建模的核心就是用例图，当然活动图这些事对用例的动态流程描述。是用例图的补充。

需求分析首先是定义边界，也就是需求中与最终实现结果相关的边界。这些就是在用例图中体现的。

2. UML图总结-需求分析阶段用例图的使用

 最近过年因为新冠病毒的肆虐各公司都开始放长假了，初步估计都是要出了元宵才能回成都上班，虽然返岗之前要在家办公（上班），但是还是得做点欠着的事情舍，其中比较重要的一个就是我的毕业设计嘞，一两个月就要交初稿了，但是我还没开始嘞
   由于毕业设计需要用到各种UML图，所以就趁这个机会好好复习和总结一下软件工程课程有关UML图的相关内容吧，毕竟这个在软件设计和分析的流程中还是占据比较重要的地位，也是软件分析的利器，能帮助我们快速分析我们要做的事情，也能使我们要做的东西一目了然，接下来就直接开始总结和复习吧，就以我的毕业设计——一个简单的在线考试系统为例开始我们的学习之旅
   用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。   例如我们在线考试系统的业务用例图：
                                           简单来说就是：用例图是由参与者（Actor）、用例（ Use Case ）、 系统边界 、箭头组成，用画图的方法来完成的一个表达系统功能的图示。   接下来分别介绍其成分。
   参与者（Actor）是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象。
    简单来说就是： 一个系统的使用者，可能涉及的角色就是一个参与者
   每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参与者。   在用例图中使用一个人形图标来表示参与者，参与者的名字写在人形图标下面。
                                           简单来说就是： 用例 是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
    系统边界 是用来表示正在 建模 系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中用方框来表示，同时附上系统的名称，参与者画在边界的外面， 用例 画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。
   要创建用例，我们需要分析哪些可以作为用例，如何识别，可以从以下几点来确定用例：
   简单来说就是：如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。
   比如在我们的考试系统中：我们的老师可以对试卷进行管理，那么展示出来的粒度较大的用例可以是这样：
                                           如果我们按照具体的操作把它抽象成多个用例（粒度变小），它也可以是这样的：
                                           它展示的系统需求和单个用例是完全一样的。
   用例之间的关系包括以下几种：

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

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


?


一、优点：


?


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


?


二、不足：


?


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


?


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


?


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