软件工程知识点总结（2）：需求分析（一）——用例建模

1 软件项目开发流程：

       需求分析→概要设计→详细设计→编码实施→测试→产品提 交→维护

2 系统必须做什么？

       获取用户需求，从用户角度考虑，用户需要系统必须完成哪些工作，也就是对目 标系统提出完整、准确、清晰、具体的要求。

       提交的主要文档：软件需求规格说明书：以书面形式准确地描述软件需求。

         ( 结构化需求模型：数据流图、数据字典、状态图）

       （面向对象需求模型：用例图、类图、顺序图等）

3 软件需求管理的过程：

       （1） 需求确认：需求获取→需求分析→需求规格编写→需求验证

       （2） 需求变更

4 需求的五个基本性质：必要的、无歧义的、可测试的、可测量的、可跟踪的

5 需求获取方式：自悟、访谈、小组会、快速建立软件原型

       自悟特点：不用与用户交流，但对需求人员的要求太高，一般不现实。

       访谈：（1） 正式访谈： 系统分析员将提出一些事先准备好的具体问题。

                  （2）非正式访谈：分析员将提出一些用户可以自由回答的开放性问题，以 鼓励被访问人员说出自己的想法。

                  （3）调查表：注意对客户分类：经过仔细考虑写出的书面回答可能比被访 者对问题的口头回答更准确。

                  （4）现场观察：用一段时间，完整旁观原始系统的使用情况，使用人员，在 此基础上与客户做进一步交流。

       条件：（1）系统分析员能够正确提出问题；（2）被访谈人能够准确表达出需 求并被分析员准确捕捉。（3）谨防“完美蠕型”

       小组会的优点：开发者与用户不分彼此，齐心协力，密切合作；及时讨论并求精； 有能导出规格说明的具体步骤。

6 快速建立软件原型是最准确、最有效、最强大的需求分析技术。快速原型就是快 速建立起来的旨在演示目标系统主要功能的可运行的程序；构建原型的要点是， 它应该实现用户看得见的功能，省略目标系统的“隐含”功能。

       建模: 就是建立模型，通过对客观事物建立一种抽象的方法，用来表征事物并获 得对事物本身的理解，是对事物的一种无歧义的书面描述。

       建模原则：现实世界能够映射到模型；模型能够描述现实世界；模型行为能够正 确反映现实世界方法。

       最杰出的建模: 地图

7 UML (Unified Modeling Language 统一建模语言）为面向对象软件设计提供统 一的、标准的、可视化的建模语言。适用于描述以用例为驱动的软件设计的全过 程。

       RUP（统一过程）是用例驱动的软件开发方法。

       UML 不是一种程序设计语言，而是一种可视化的建模语言，比 C++、Java 这样 的程序设计语言抽象层次更高，适用于任何面向对象的程序设计语言。UML 不 是工具或知识库的规格说明，而是一种建模语言规格说明，是一种模型表示的标 准。UML 不是过程，也不是方法，但允许任何一种过程和方法使用它。

       UML 视图分类分为三个视图域：结构分类、动态行为、模型管理。

面向对象分析（OOA）构造模型：

8 用例图是外部参与者所能观察到的系统功能的模型图。用例是参与者要实现的最 终目标。用例图还是软件测试人员进行测试的指导。

       用例图的组成：参与者（活动者，Actor）、用例（Use Case）、关系（Relationship）

       用例图是指由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的 用于描述系统功能的静态视图

       （1）用例间关系-泛化（继承） ——参与者之间的泛化:便于权限设置

                                                          ——用例之间的泛化：子用例和父用例相似，但表现出更特别的行为；子用例将 继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可 以重载它。

        父用例通常是抽象的。目的：支持系统的可扩展性、代码复用。

       （2）用例间关系-包含（Include）

       【箭头指向】：指向分解出来的功能用例。箭头出发的用例为基用例。包含用例 是必选的，如果缺少包含用例，基用例就不完整。

       包含关系的代码表现：B 类的对象作为 A 类的数据成员存在——对象的组合

      代码复用

       包含的两种使用场景：（1）使用包含用例来封装一组跨越多个用例的相似动作， 以便被多个基用例复用。包含关系最典型的应用就是复用。（2）当某用例的事件 流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成一个被 包含的用例。

       （3）用例间关系-扩展 extend

       【箭头指向】：指向基础用例。扩展用例是可选的，如果缺少扩展用例，不会影 响到基用例的完整性；扩展用例在一定条件下才会执行，并且其执行不会改变基 用例的行为。

       用例图补充：“系统”。系统被看作是一个提供用例的黑盒子。描述该系统功能的 用例置于方框内，代表外部实体的行为置于方框外。

       [有/无]条件条件：泛化：（ 无 ）条件发生、包含：（ 无 ）条件发生、 扩展：（ 有 ）条件发生

       为 Actor 提供【直接/间接】服务：泛化中的子用例： 提供的是（直接）服务。 扩展用例： 提供的是（直接）服务。包含中的被包含用例： 提供的是（间接） 服务。

9 用例模型建模：

       任务：获取需求，建立需求模型（用例模型：绘制用例图和编写用例文档）。

       步骤：①确定系统的参与者②确定场景③确定系统用例④确定用例之间的关系⑤ 编写用例描述文档

       ①确定系统的参与者：参与者是指直接和系统交互的一类事物，参与者主要有 如下三类：

(1) 直接使用系统的人，如 图书管理员，普通读者等（角色）；

(2) 与该系统相关的其他系统，如邮件系统；

(3) 自动发生的事件，如时间、温度等自动事件，如：库存管理系统要求每晚零 点执行一个数据汇总操作，此时时间就成为该操作的执行者。

       ②确定场景：考虑参与者用系统做什么？进一步描述场景。在系统中，按照某 个顺序执行了一系列相关的动作后，即可实现某种功能，把完成这一功能操作的 集合称为场景。一个场景就是描述软件使用者与系统之间的一系列交互活动，系 统具体执行的行为路径，即一次完成的事件流。从个体角度考虑

       场景的获取方法：开发者与用户、客户进行交流来获取。

       ③确定系统用例：用例是对一组场景共同行为的抽象，是参与者最终要实现的 目的。重点在于参与者与系统之间的交互而不是系统内部的活动。

       方法：从场景描述，理解系统需求，分析获取系统用例。

       用例要点分析：

（1）可观测：用例是参与者与系统的交互，不是系统内部的活动，且一定是参与者主动发起的，最后结果一定要反馈给参与者。习惯说用例止于边界。

（2）结果值：每个用例都会对外界参与者产生一个有价值的结果。

（3）系统执行：结果值由系统所生成

（4）由参与者执行：用例的识别和定义都是从参与者角度出发，要以参与者的 视角获取和定义。

       “由参与者执行”的两层含义：

①用例命名使用业务语言而非技术语言

②用例表达用户观点，而不是系统能提供的功能

       补充：用例的粒度

       用例定义原则：“用例是参与者所要实现的最终目标，并为参与者产生所需要的 价值”。

       用例的粒度（用例的大小）可大可小，一般一个系统易控制在 20 个用例左右。 对复杂的系统可以划分为若干个子系统处理。用例是系统级的、抽象的描述，不 是细化的（是做什么，非怎样做）

       ④确定用例之间的关系：过于复杂的用例需要适当分解，以便分解功能、提高复 用性、可扩展性等。

       包含：从多个用例中提取公共部分的功能，单独放到一个用例中，提高复用性。

       扩展：将一个基用例中在某种特定情况下才激发的功能单独成为一个用例，以保 持基用例的完整（即一般情况都能处理）。

       泛化：用例泛化一般作为抽象用例而存在，为了复用或者扩展而使用。

       ⑤根据需要可以细化用例

       用例文档又称为用例规约或用例描述。用例文档是用于描述用例的文档，每一个 用例对应于一个用例文档。在用例文档中需要用文字的方式描述用例的执行过程， 即执行者与系统的交互过程 。

       用例建模包括用例图的绘制和用例文档的编写。用例建模是软件需求分析到最终 实现的第一步，它从用户的角度来描述软件系统的功能，描述人们如何使用软件 系统。

       用例描述组成内容：

用例名称：与用例图同，并写相应编号

简要说明/描述：简要描述功能

优先级：标识软件客户对该用例实现状况的期许（一般用 1~5 表示），数字越大， 优先级越高。

参与者（执行者）：使用该用例的人或系统等。

前置条件：在用例启动时参与者和系统应置于什么状态。这个状态必须是系统可 以识别到的。如“参与者已成功登录”，不能是“参与者已打开电脑”。

后置条件：用例结束时系统应置于什么状态。即用例结束时的系统状态或持久数 据情况。

事件流：（文档中最重要的部分！！）描述如何通过交互传递由用例所承诺的价 值； 它是一个被严格流程化规范化的故事：用例开始（入口）——{用户发起请求—系 统校验请求—系统处理—系统反馈}——用例结束

事件流：

（1）基本流（没有异常/分支）：做 835 汽车，胜利桥东下车；确认 615 汽车还 运营，坐 615 汽车到轨道交通 2 号线大北门站；从地铁出来后在门口吃点东西。  

（2）扩展流（用户做出了另外的选择）：如果不饿不想吃东西，也可以旁边星 巴克做一会儿。

（3）异常流（系统没有像预期那样反馈用户数据）：如果 615 路汽车停运了， 就直接打车

基本事件流：没有任何分支、没有如果，只有顺序描述，预期会成功的路线。

①基本流必须完整，不能引用其他扩展流；

②使用主动语句，以执行者或者系统为主语；

③不涉及到界面细节；

④不使用专业术语，而是用业务语言

事件流描述示例：

1、在文本框中输入账号                                                    管理员输入账号

2、用户点击提交按钮                                                        用户向系统请求提交表单

3、系统将销售记录生成 SQL 并执行，写入数据库           系统记录销售

10 活动图是动态行为图，用于描述系统的工作流程或一个用例的内部行为。

       活动图的作用：(1)描述系统业务工作过程（涉及多个用例） （2）对用例规约 建模（一个用例）(3) 对复杂算法建模

        活动图的组成元素：1、初始节点和终点 2、活动节点 3、转换 4、决策与分支、 合并 5、分岔与汇合

1、初始节点和终点：初始节点表示活动的起点，用一个实心圆表示；终点表示 活动的终结点，用一个圆圈内加一个实心圆来表示活动终点．在活动图中，可能 包含多个活动终点。

2、活动节点：用来表示一个活动，一个活动表示一个或多个动作的集合。

       活动：活动可分解，不是原子的，工作的完成需要一定的时间。 动作是原子的，不能被分解。如上“表达式”。

3、转换：当一个活动结束时，活动控制流就会传递给下一个活动节点，在活动 图中称之为“转换”，用一条带箭头的直线（或折线）来表示转换。

4、决策与分支、合并（类似程序流程图的判断框）

       决策与分支：用菱形表示的，一个或多个离开转换。每个离开转换上都会有一个 监护条件，用来表示满足什么条件的时候执行该转换。

       合并：指两条或多条控制路径汇合的情况。用菱形符号表示。

5、分岔与汇合 分岔：表示一个控制流被两个或多个控制流代替，经过分岔后，这些控制流是并 发进行的。

       汇合与分岔相反，表示两个或多个控制流被一个控制流代替。

       合并的各路分支选择哪条由决策条件决定，不同的条件会选择不同的决策分支， 分支之间是互斥的；

       汇合的两个分支相当是两个线程，线程都要完成才能汇合，其所有分支必须完成 才行，没有条件。

       活动图的其他组成元素：