需求分析与用例建模

《需求分析与用例建模》由会员分享，可在线阅读，更多相关《需求分析与用例建模（14页珍藏版）》请在金锄头文库上搜索。

1、第二章第二章 需求分析与用例建模需求分析与用例建模 21 需求分析阶段的工作需求分析阶段的工作 需求分析是一项软件工程活动，它包括： 1. 需求获取 a) 刻画出软件的功能和性能； b) 指明软件与其他系统元素的接口； c) 建立软件必须满足的约束。 2. 需求建模 需求分析建立起来的模型为日后软件设计人员提供了可被翻译成数据、 体系结构、 接口和过程设计的模型。 3. 需求规格说明 需求规格说明为开发人员和用户提供软件开发完成时质量评价的依据。 4. 需求评审 a) 需求分析研究的对象是用户的要求。 b) 必须全面理解用户的各项要求，准确表达被接受的用户要求。 c) 只有经过确切描述的软件需

2、求才能成为软件设计的基础。 相应地，需求分析的过程可以分成四个阶段： 1. 问题识别（需求获取） a) 研究系统的可行性分析报告和软件项目实施计划。 b) 从系统角度来理解软件并评审用于产生计划估算的软件范围是否恰当； c) 确定对目标系统的需求； d) 提出这些需求实现条件，以及需求应达到的标准。 2. 分析与综合（需求建模） a) 进行各种要求的一致性检查； b) 逐步细化所有的软件功能； c) 分解数据域，分配给各个子功能； d) 找出系统各成分之间的联系、接口特性和设计限制。 e) 判断是否存在不合理的用户要求或用户尚未提出的潜在要求。 f) 综合成系统的解决方案，给出目标系统的详细逻

3、辑模型。 3. 需求描述：编制需求分析阶段的文档 a) 软件需求规格说明 SRS； b) 初步的用户手册 User Guide； c) 确认测试计划； 1d) 修改和完善软件开发计划。 4. 需求评审(验证） 作为需求分析阶段工作的复查手段，应该对功能的正确性、文档的一致性、完备性、准确性和清晰性，以 及其它需求给予评价。 本实验指导书将主要介绍面向对象的分析建模技术。 22 用例建模的步骤用例建模的步骤 2.2.1 用例图中的重要概念用例图中的重要概念 参与者(Actor) 参与者(Actor)是系统外部的一个实体(可以是任何的事物或人)，它以某种方式参与了用例的过程。参与者 通过向系统输入

4、或请示系统输入某些事件来触发系统的执行。参与者由他们参与用例时所担当的角色来表示。 参与者包括人(Human Actor)和外部系统参与者(System Actor)。系统的用户是人参与者，用户通过与系统的 交互操纵系统，完成所需要的工作。但参与者不一定是人，也可以是一个外部系统，该系统与本系统相互作用， 交换信息外部系统可以是软件系统，也可以是个硬设备，例如在数据录入设备中的扫描仪，自动化生产系统上 的数控机床等。 注意参与者之间也可以有继承等关联关系。例如下图所示：本科生和研究生均是学生。 学生学生学生研究生本科生图 2.1 参与者继承关系示意图 用例(Use Case) 用例是对一个系统

5、或一个应用的一种单一的使用方式所作的描述，是关系单个活动者在与系统对话中所执 行的处理行为的陈述序列。 用例是一个叙述型的文档，用来描述参与者(Actor)使用系统完成某个事件时的事情发生顺序。用例是系统 的使用过程，更确切地说，用例不是需求或者功能的规格说明，但用例也展示和体现出了其所描述的过程中的 需求情况。 2用例描述活动者与系统交互中的对话。例如，活动者向系统发出请示做某项数据处理，并向系统输入初始 数据，系统响应活动者的请示进行所要求的处理，把结果返回给活动者。这种对话表达了活动者与系统的交互过程，它可以用一系列的步骤来描述。这些步骤构成一个“场景”(Scenario)，而“场景”的

6、集合就是用例。全部的 用例构成了对于系统外部可见的描述。 从这些定义可知，用例是对系统的用户需求(主要是功能需求)的描述，用例表达了系统的功能和所提供的 服务。 用例间关系 用例除了与其参与者发生关联外，还可以具有系统中的多个关系，这些关系包括：泛化关系、包含关系和 扩充关系。应用这些关系是为了抽取出系统的公共行为和变体。 1) 泛化关系(Generalization) 一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化。用例间的泛化关系和类间的泛化关系 类似，即在用例泛化中，子用例表示父用例的特殊形式。子用例从父用例处继承行为和属性，还可以添加行为 或覆盖、改变已继承的行为。当系统中

7、具有一个或多个用例是较一般用例的特化时，就使用用例泛化。 2) 包含关系(Include) 虽然每个用例的实例都是独立的，但是一个用例可以用其它更简单的用例来描述。一个用例可以简单地包 含其它用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这被称作饮食关系。在这种情况下， 新用例不是初始用例的一个特殊例子，并且不能被初始用例所代替。 饮食关系把几个用例的公共步骤分离成一个单独的被包含用例。用例间的包含关系允许包含提供者用例的 行为到用户用例的事件中。把包含用例称为客户用例，被包含用例称为提供者用例，包含用例提供功能给客户 用例。 要使用包含关系，就必须在客房用例中说明提供者用例行为

8、被饮食的详细位置。这一点和功能调用有点类 似，事实上，它们在某种程序上具有相似的语义。 3) 扩展关系(Extend) 一个用例也可以被定义为基础用例的增量扩展，这称作扩展关系。扩展关系是把新行为插入到已有用例的方法。基础用例提供了一组扩展点(Extension points)，在这些扩展点中可以添加新的行为，而扩展用例提供了 一组插入片段，这些片段能够被插入到基础用例的扩展点。 基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。事实上，基础用例没有扩展也是完整的， 这一点与包含关系有所不同。一个用例可能有多个扩展点，每个扩展点也可以出现多次。但一般情况下，基础 用例的执行不会涉及扩展用

9、例的行为，如果特定条件发生，扩展用例的行为才被执行，然后流继续。 扩展关系为处理异常或构建灵活系统框架提供了一种有效的方法。 2.2.2 用例建模的主要步骤用例建模的主要步骤 1. 调查系统需求 2. 确定系统范围和系统边界 3. 确定用例和行为者 4. 描述用例 35. 用例分类 6. 建立用例图 7. 定义用例的层次结构 23 案例分析： 某高校艺术类招生考试管理系统的需求分析和用例建模案例分析： 某高校艺术类招生考试管理系统的需求分析和用例建模 在本节中，我们选取一个实际开发案例作为实验指导的示范案例。该案例将贯穿整个实验指导书，旨在演 示整个系统分析设计的过程和思路。同时，在下一节中，

10、还提供了一些单独的实验指导，并附有详细的使用 Rational Rose 进行用例建模的过程，帮助大家加强实践，完成练习。 普通高等院校的招生工作是由教育部网上录取系统统一进行的。 但一些特殊类别的考生录取， 例如艺术类、 体育类等，高校需要在进行专业课考试和文化课考试之后自主录取。这里选取的就是苏州大学艺术类招生考试 管理系统的原型。 2.3.1 需求概述需求概述 艺术类招生考试管理系统主要工作分为两个阶段：高考前专业课考试管理阶段和高考后的考生录取阶段， 由此可初步构造两个用例，如图所示。考生录取处理必须依赖于专业考试处理的结果，即具有被录取资格的考 生必须是经过专业课考试并获得合格证者。

11、 专业课考试处理考生录取处理招生人员图 2.2 艺术类招生考试管理系统总体用例图 经与用户的沟通，确认招生考试管理需包括的工作，概括起来有： ? 专业考试评分，即提供评分专家现场评分。 ? 考生基本信息处理，即对考生基本信息的录入、修改、删除等。 ? 考生专业成绩处理，即对考生专业成绩（包括考试状态等）的录入、核对等。 ? 考生文化成绩处理，即对考生文化成绩的录入、核对等。 ? 专业考试合格证处理，即通过预测合格线等操作，最终确定专业考试合格线和打印合格证等。 ? 预录取处理，即通过预录取策略的设置来获取预录取的名单并提供手工调整预录取功能。 4? 最终录取处理，即设置最终录取名单。 ? 信息

12、查询，包括专业总分和专业考试合格证查询、预录取结果查询等。 ? 报表，包括专业考试总报表和录取总报表，以及相关统计报表等。 ? 数据导入导出，包括考生基本信息导入、考生专业分数、文化分数的导入，以及专业考试合格名单导 出、预录取、录取结果导出等功能。 ? 系统基本信息维护，如用户信息、日志查询、编号表维护、系统参数维护等。 系统的用户应包含校领导、招生办公室领导、招生办公室工作人员（包括信息录入员等）和其他相关部门 的相关人员等；对不同类型的用户，对应不同的使用权限，这些权限将由招生管理人员自行配置。 其中最主要的用户是大学招生办公室的招生人员，他们本身熟悉艺术类招生的相关政策和工作流程，会中

13、文输入， 能够使用 VFP 等工具手动地完成整个艺术招生流程。 同时， 他们具有使用教育部网上招生系统的经验， 并形成了一定的操作习惯。因而 YSZS 系统应做到界面友好，能提供帮助和纠错，并尽可能满足用户的操作习 惯。对于工作量较大的信息录入人员，系统力求做到操作简单方便，帮助用户提高输入速度和正确率。 2.3.2 用例建模用例建模 与系统核心功能相关的主要有两种用户：招生人员与信息录入员。招生人员负责协调整个招生工作，可以 参与到招生工作的各阶段中；而信息录入员则主要负责考生信息与考生成绩录入工作。在用例建模中这两种用 户被定义为行为者。 下面主要细化已提出的两个用例：考生录取处理与专业考

14、试处理。 1) 专业考试处理功能可分为： ? 专业考试基础信息维护 ? 考生基本信息处理 ? 考生专业成绩处理 ? 专业考试合格证处理 ? 招生计划信息处理 2) 考生录取处理功能可分为 ? 各省文化考试基础信息维护 ? 考生文化成绩处理 ? 考生志愿信息处理 ? 预录取处理 ? 最终录取处理 根据以上分析，构造第二层用例图如下， 5信息录入员(from Actors)招生人员(from Actors)考生基本信息处理考生专业成绩处理专业考试合格证处理招生计划信息处理专业考试基础信息维护专业课考试处理(from Business Use-Case Model)图 2.3 专业考试处理用例图 用

15、例建模的过程，除了图之外，还必须给出必要的解释。否则，建模是不完整的。图 2.3 的解释如下。 该图是对图 2.2 的“专业考试处理”功能的细化。如图， “专业考试处理”用例包含（include）了“专业 考试基础信息维护”等 5 个子用例。其中信息录入员因为权限的关系，仅参与“考生基本信息处理”和“考生 专业成绩处理”两个用例，而且在这两个子用例中间也只有录入信息和核对信息的功能，不能做信息的修改。而招生人员具备所有用例中的处理功能（除录入员的录入功能外） 。5 个子用例之间也有一定的关联，首先， “考 生基本信息处理”子用例依赖于“专业考试基础信息维护”子用例，这是因为， “考生基本信息处

16、理”中间的部 分内容（如考生的考试课目） ，是由该考生的报考的专业决定的，而专业的情况，是“专业考试基础信息维护” 的功能。类似的， “考生专业成绩处理”子用例依赖于“专业考试基础信息维护”和“考生基本信息处理”子用 例，这是因为，要进行考生专业成绩的录入，维护等工作，必须在考生的基本信息和考生所报考专业的考试信 息都完整的情况下进行。 “专业考试合格证处理”子用例依赖于“招生计划信息处理”和“考生专业成绩处理” 子用例，这是因为发放专业考试合格证的前提是考生专业成绩和招生计划都处理完毕。 6信息录入员(from Actors)招生人员(from Actors)考生文化成绩处理考生志愿信息处理预录取处理最终录取处理各省文化考试基础信息维护考生录取处理(from Business Use-Case Model)图 2.4 考生录取处理用例图 图 2.4 是图 2.2 中“考生录取处理”功能的细化，解释如下。 如图， “考生录取处理”包含（include