软件工程模型与方法第9章面向对象分析

5a.
对基本路径中某个步骤的扩展描述，前边加基本路径编号
特殊需求：
与用例相关的非功能性需求
技术与数据的变化列表： 输入输出方式上的变化以及数据格式的变化。
发生频率：
用例执行的频率。
待解决的问题：
不清楚的、尚待解决的问题可集中在此进行罗列
用例之间的关系
包含关系
➢ 用例A在其内部说明的某一位置上显式地使用用例B行 为的结果，成为用例A包含用例B。
外部系统：所有与系统交互的外部系统。
设备：所有与系统交互的设备。其与系统 相连，向系统提供外界信息，或者从系统 获取信息，在系统的控制下运行。例如传 感器、受控马达、条形码扫描设备等。
如何找到参与者
通过回答以下问题找到参与者： （1）谁使用系统的主要功能？ （2）谁需要系统的支持以完成其日常工作任务？ （3）谁负责维护、管理并保证系统的正常运行？ （4）系统需要和哪些外部系统交互？ （5）系统需要处理哪些设备？ （6）对系统产生的结果感兴趣的人或事物是哪些
进行方便地维护。
在线考试系统的参与者
任课教师的部分目标和助教的目标相同， 于是可以创建一个新的抽象参与者――阅 卷者，它的目标是使用系统方便有效地开 展阅卷工作；
教师和助教再继承阅卷者
•学生
•阅卷者
•系统维护人 员
• 教师 • 助教
9.2.3 识别用例
用例的定义： 一个用例（use case）描述系统的一项功能，功能
识别用例
从参与者角度出发，识别每类参与者在系 统中要实现的目标，从中抽取用例。
用例可以分为三种不同的级别：
➢ 企业级别的目标：如盈利、扩大目标市场等； ➢ 用户级别的目标：如取款、在线考试等； ➢ 子功能级别的目标：如验证用户身份、记录系
统日志等。
识别用例重点要识别的是用户级别用例。
基本业务过程
面向对象分析步骤
（3）从用例出发，将系统看作一个黑盒子 ，识别出参与者和系统交互的系统事件， 在系统顺序图中进行描述，并进一步识别 出系统操作。
（4）从系统顺序图和领域模型出发，建立 系统操作契约，描述响应系统事件的系统 操作执行后对系统状态的影响，从而回答 系统“做什么”的问题。此处的系统状态变化 指的是领域模型中概念的创建和删除，概 念属性的修改以及概念之间关联的建立和 删除。
前置条件:
规定了在用例中的一个场景开始之前必须为“真”的条件。
后置条件：
规定了用例成功结束后必须为“真”的条件。
主要成功场景:（基本路径）描述了能够满足项目相关人员兴趣的一个典型的成功路径。不包括条件和分支
1．
……
n．
扩展（或替代流程）: （备选路径）说明了基本路径以外的所有其他场景或分支
*a.
描述任何一个步骤都有可能发生的条件，前边加*
（4）由于系统新功能的识别（如那些典型的还没有实现 自动化的人工系统），参与者的日常工作被简化或效率提 高了吗？若是，则该用例对于该参与者有意义、值得实现 。
参与者之间的继承关系
参与者是一个类，因此在参与者之间可以 引入类之间的继承关系，通过定义某个抽 象参与者来简化参与者的定义。
如果一组参与者具有共同的性质，可以把 这些性质抽取出来放在另一个参与者中， 这组参与者再从中继承，这种关系称为参 与者之间的继承关系。
在线学生和系统 维护人员。
各个参与者的系统目标：
➢ 任课教师：能维护题库；能设计一次考试的出题规则 ，设定考生范围和考试时间及时长；能顺利开展考试 ；能方便有效地开展阅卷工作；能得到有价值的统计 信息。
➢ 助教：能方便有效地开展阅卷工作； ➢ 学生：能顺利进行考试，能查询自己的考试成绩； ➢ 系统维护人员：能对系统的用户、权限、系统参数等
用例的包含关系举例
假设在一个旅游电子商务网站系统中，有 如下用例：
➢ 购买机票 ➢ 预定酒店
系统用户
子系统描述
1. 题库管理子系统 对考题进行管理。题目类型有选择题、填空题、解答题和
程序设计题，功能要求：
➢ 能增、删、改、查询题目。 ➢ 能支持使用Excel批量导入试题到数据库的功能。
2. 考试子系统 根据一定的试题生成规则现场生成一套试题供学生进行解
答，并记录答案。考试采用逐题方式进行，做完一题再出 现下一题。学生可以用上翻、下翻键来选择返回上一题还 是进行到下一题。考试采用人工计时方式。若到考试结束 时间，则系统强行要求学生结束答题；若学生提前做完， 则可以按结束考试键终止答题。当学生选择结束考试时， 给出选择题的成绩，并将学生所做的试题及答案记录到数 据库中。
➢ 包含关系图示表示如下左图。
➢ 避免用例中相同功能的重复描述；避免过长的用例。
扩展关系
➢ 在不能改变已有用例的情况下，扩展用例的功能。 ➢ 扩展用例中必须包含触发和扩展点说明。 ➢ 扩展管理的图示表示如下右图。
• 基用例 •《include》
•被包含的用 例
•基用例
•《extend》
•扩展用 例
识别参与者的任务就是找到参与者并明确其在系 统中要实现的目标。
参与者是一个类 。 参与者可以发出请求，要求系统提供服务，系统
以某种方式进行响应，或者把响应的结果给其他 的参与者；系统也可以向参与者发出请求，参与 者对此做出响应。
参与者的分类
主要参与者：指的是在使用系统服务的过程中满 足自己目标的那些参与者，如使用在线考试系统 的任课教师和学生。识别出这类参与者，可以帮 助找到用户目标，从而确定系统的功能需求。
基本业务过程（EBP，Elementary Business Process ）是指由一个人在某个时间某个地点执行的一项 任务，这项任务是对某一业务事件的反应，而且 能够增加可以度量的业务价值，并且能够保持数 据状态的一致。
进行用例分析时，应该专注于EBP级别的用例， 但是当一个子功能在多个用户目标级别用例中重 复出现，或这个子功能是多个用户目标级别用例 的前置条件，如“验证用户身份”、“记录日志”等 ，则可以定义一个用例来表示该子功能。
系统边界以外是与系统进行交互的人员、 设备、外部系统或组织。
系统是由一条边界包围起来的未知空间， 系统只通过边界上的有限个接口与外部交 互。
9.2.2 识别参与者
参与者（actor）是具有行为能力的事物，可以是 一个人（由所扮演的角色来识别）、计算机系统 或硬件设备。
它们位于系统边界之外，通过和系统进行有意义 的交互来实现它们的目标。
对用例的理解
（2）用例通常是由某个参与者来驱动执行，只有 当外部的参与者与系统交互时，该功能才会发生 作用。
（3）用例中，只描述参与者可以看到的系统行为 特征。
（4）用例描述的是一个参与者所使用的一项系统 级功能，该项功能应该相对完整。
（5）可观察的结果值是指系统对参与者的动作要 做出响应，在经过若干次交互之后，系统把最终 有意义的结果值反馈给参与者。
画出系统用例图
➢ 识别系统边界 ➢ 识别参与者 ➢ 识别用例 ➢ 确定用例之间关系
给出用例的文本描述
➢ 用例描述模板
用例建模目标
9.2.1 确定系统边界 9.2.2 识别参与者 9.2.3 识别用例 9.2.4 其他需求分析工作
9.2 用例建模
9.2.1 确定系统边界
系统边界是一个系统所包含的所有系统成 分与系统以外各事物的分界线。
➢ 问题域（problem domain）：被开发系统的应用领域 ，即在现实世界中由这个系统进行处理的业务范围
➢ 系统职责（system responsibilities），所开发的系统应 该具备的职能
OOA与OOD的职责划分
OOA针对现实世界中的问题域与系统职责，用面 向对象的方法建立起针对问题域和系统职责的模 型，作为分析的结果。OOA模型不考虑与系统的 具体实现相关的因素（譬如，采用什么程序设计 语言和数据库），从而使OOA模型独立于具体的 实现环境。
OOD则是针对系统的具体实现，运用OO方法进行 系统设计。其中包括两方面的工作：一是根据实 现条件对OOA模型做某些必要的调整和修改，使 其成为OOD模型的一部分；二是针对具体实现条 件，建立人机界面、数据存储和控制驱动等模型 。这些部分与OOA采用相同的概念和表示法。
软件分析所面临的问题
1．对问题域和系统职责的理解 2．交流问题 3．需求的不断变化 4．软件复用的要求
次要参与者：指的是为系统提供服务的那些参与 者，如一个对信用卡支付进行授权的外部系统。 识别出这类参与者，可以帮助确定外部接口和协 议。
后台参与者：指的是对用例的行为感兴趣的那些 参与者，如政府的税务机关。识别出这类参与者 ，可以保证找到所有方面的兴趣并让用例满足之 。
谁能充当参与者
人员：可以从直接使用系统的人员中发现 参与者。其从系统获取信息，或者向系统 提供信息。
用例描述
用例描述的目标是将用例的功能和应用场景描述 清楚，包括
➢ 用例在何时开始，何时结束 ➢ 参与者何时与系统交互 ➢ 交互什么内容 ➢ 所有可能的交互场景
对用例的描述，可以用自然语言，也可以采用用 户自定义的语言。为了更清楚地说明问题，也可 以采用面向对象的类图、交互图、状态图或活动 图来做进一步的描述。
用例描述模板
用例编号: 用例名称: 范围：
每一个用例一个唯一的编号，方便在文档中索引。 (状语＋）动词＋（定语＋）宾语，体现参与者的目标。 应用的软件系统范围
级别：
企业目标级别/用户目标级别/子系统目标级别
主要参与者:
调用系统服务来完成目标的主要参与者
项目相关人员及其兴趣:
用户应包含满足所有相关人员兴趣的内容
在线考试系统功能描述
本系统主要是为程序设计类课程考试而设 计，但是也应该能适应到其他的课程。目 的在于：
➢ 1.增加考试灵活性，减轻任课教师的出题、判 卷和统计工作；