《软件工程导论》PPT课件-第10章-面向对象的需求分析

1、软件工程导论 第10章 面向对象的需求分析 10.1 用例图 10.2 用例建模的步骤 10.3 书写用例描述文档 10.4 用例模型的建立传统的需求表达方式是编写“软件需求规约”，采用功能分解的方式来描述系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块中，通过描述细分的系统模块的功能来达到描述整个系统功能的目的。对于用户来说，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统是如何被使用的。 在面向对象的软件开发方法中，用例是一种描述系统需求的方法，是从系统用户的角度来看系统应该提供哪些功能，以及用户应该与系统如何交互来执行这些功能。 第

2、10章 面向对象的需求分析10.1 用例图 用例建模通过用例图以简单明了的图形方式把系统的总体功能需求表达出来，再通过对每个用例的详细描述完成对每个用例的业务规则和用户与系统的交互序列的说明。 用例建模的最终成果应该是完整准确的系统用例图和详细的用例描述文档。 用例图包含3个主要元素，分别是参与者、用例和关系。关系可以分为3类： (1)第一类是参与者和用例之间的关联关系，表明参与者主要使用系统的哪些用例； (2)第二类是用例之间的关系，主要分为包含关系、扩展关系和泛化关系； (3)第三类是参与者之间的泛化关系。 10.1 用例图10.1 用例图用例图模型1. 定义系统边界；2. 确定参与者；3

3、. 识别用例；4. 确定用例之间的关系；5. 建立完整的用例图；6. 书写用例描述文档。10.2 用例建模的步骤 10.2.1 定义系统边界 定义系统边界即定义系统的范围，哪些功能是系统应该实现的，哪些不是系统应该做的，明确系统目标范围。对于银联网络的自动取款机网络系统来说，其系统边界范围就是和自动取款机相关的功能，包括用户通过自动取款机取款、查询账户、转账等以及银联网络中各个银行之间的账务结算，而对于各个银行内部的各营业部之间的计算机网络，本系统则不涉及，不属于本系统所要考虑的范畴。在用例图中，UML的系统边界用矩形框来表示。10.2.2 确定参与者 参与者是指存在于被定义系统外部并与该系统

4、发生交互的人、其他软硬件设备或其他系统，代表的是系统的使用者或使用环境。在用例图中，UML参与者的表示符号为人形图标。每一类参与者可以使用一个或多个系统用例。系统的参与者通常主要有以下3大类： - 第一类参与者是系统用户，根据用户使用系统时承 担的不同角色来进行命名; - 第二类参与者是需要与本系统通过接口进行交互的 软、硬件系统等。 - 第三类参与者是一些可运行的进程，如时间系统。10.2.2 确定参与者 识别参与者的一些要点如下所述： -参与者代表在系统边界之外的真实事物，并不 是系统的组成成分； -参与者通过系统边界直接与系统交互，参与者 的确定代表着系统边界的确定； -参与者与系统的交

5、互是要有意义的； -参与者可以是任何事物，包括人、其他软硬件 系统、其他进程等。10.2.2 确定参与者 分析人员可以通过回答下面的问题来寻找系统的参与者: （1）谁使用系统的主要功能？ （2）谁改变系统的数据？ （3）谁从系统获取信息？ （4）谁需要系统的支持以完成日常工作任务？ （5）谁需要维护、管理并保持系统正常运行？ （6）系统需要应付(处理)哪些硬设备？ （7）系统需要和哪些外部系统交互？ （8）谁/什么对系统运行产生的结果（值）感兴趣？ （9）时间、气温等内外部条件是否会触发系统执行某些功能？10.2.3 识别用例 用例用于表示系统所提供的服务，它定义了系统是如何被参与者使用的，描

6、述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段“对话”。用例就是参与者使用系统达到某个目标。用例的用途是，在不涉及系统内部实现细节的前提下，给出用户完整的需求说明。在UML标准中，用一个椭圆来表示用例，用例的名字可以写在椭圆内部，也可以写在椭圆的下方。10.2.3 识别用例 识别用例的一些要点如下： (1)用例是可观测的，用例止于系统边界； (2)用例是目标导向的，是有执行结果的； (3)用例是由系统执行的，结果值由系统生成； (4)用例以参与者的观点命名，以用户业务语言进行描述。分析人员可以通过回答下面的问题来更好地提取用例： (1)每一类参与者希望系统能够提供什么功能；

7、 (2)是否存在触发系统的外部事件； (3)当系统改变状态的时候，是否需要通知参与者； (4)系统是否需要定期备份或发送信息，如果是，由哪个参与者触发。10.2.4 确定用例之间的关系 关联关系： - 参与者和用例之间的连线表示关联关系。 - 通信关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些参与者使用的。10.2.4 确定用例之间的关系 包含关系 - 用例与用例之间的关系。 - 用例间的包含关系就是指一个用例在执行时，把另外一个用例作为自身行为的一部分来执行。 - 用例之间的包含关系可以用来简化用例图模型，同时也可以

8、提高用例的可复用性。如果一个用例的功能太复杂，可以将大用例分解为若干个小用例，使用包含关系来建模。10.2.4 确定用例之间的关系 扩展关系 - 用例之间的扩展关系就是指一个用例在执行的过程中，如果满足某种条件，则使用另一个用例对其行为进行扩展，被扩展的用例称为基本用例，被插入的用例称为扩展用例。 - 扩展关系的目的在于： 表明用例的某一部分是可选的系统行为； 表明只有在特定条件下才执行的分支流，扩展关系为处理异常或构建灵活的系统框架提供了一种十分有效的方法； 表明可能有一组行为段，其中的一个或多个段可以在基本用例中的扩展点处插入，所插入的行为段将取决于在执行基本用例时与参与者进行的交互。10

9、.2.4 确定用例之间的关系 扩展关系 - 在UML标准中，扩展关系通过带字样的虚线箭头表示，箭头指向基本用例（即被扩展的用例），如图10.5所示： - 在扩展关系中，基本用例自身应该是完整的，即基本用例应该是可理解并且有意义的，而不必引用任何扩展用例。但是基本用例并不独立于扩展用例，当有扩展条件发生时，基本用例要依赖于扩展用例才能正确执行。10.2.4 确定用例之间的关系 泛化关系 - 用例的泛化关系是指从子用例到父用例的关系，它指定了子用例如何特化父用例的所有特征和行为。 - 子用例代表了父用例的一种特殊形式。父用例可以特化形成一个或多个子用例，子用例继承父用例的所有结构、行为和关系，还可

10、以添加、覆盖或改变继承的行为。 用例间3种关系的比较 （1）包含关系：一个用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。 （2）扩展关系：一个用例（扩展用例）可以被定义为基本用例的增量扩展。一般基本用例的执行不会涉及扩展用例，只在特定的条件下扩展用例才会被执行。基本用例执行时，扩展用例不一定会被执行。 （3）泛化关系：“泛化”类似于“继承”或“多态”。UML标准中的用例泛化过程是将不同用例之间的可合并部分抽象成独立的父用例，并将不可合并部分单独成为各自的子用例。泛化侧重表示子用例间的互斥性，在同一时刻，只有一个子用例会被执行。 10.2.4 确定用例之间的关

11、系 在建立完整的用例图之后，用例建模工作只是完成了一部分，还应对每一个用例给出用例描述，即对于每一个用例，用户和系统的具体交互序列的描述。 用例描述应该包含用例的所有行为、执行用例的正常情况(即基本操作流程)以及所有异常情况下的用例执行情况。对于用例描述文档，目前还没有统一的规范格式，应在开发组内形成一个统一的风格。10.3 书写用例描述文档 10.3 书写用例描述文档 用例描述文档模板用例编号：统一对系统的所有用例进行编号，便于分析人员之间的交流。用例名称：用例图中给出的用例名称。用例描述：给用例一个简单的文字说明，简要介绍用例要完成的主要功能。参 与 者：列举出在完成本用例功能的交互序列中

12、，需要哪些参与者的参与。频 率：给出本用例功能被使用的频率，可以为系统设计人员在对性能和可维护性等方面进行平衡时提供参考。前置条件：开始用例前所必需的系统及其环境的状态，某些用例依赖于其他用例。例如，必须先登录系统，才能够预定图书。另外，列举前置条件，还有助于识别漏掉的用例，如果一个用例的前置条件不能由执行其他用例满足，就可能意味着丢失了用例。例如，预定图书却没有登录系统。后置条件：用例成功结束后系统应该具备的状态。假 设：假设用例功能可以进行的条件满足。基本操作流程：也称为主成功的路径，描述参与者为了成功地完成目标功能而与系统进行交互的活动序列，分为不同的步骤依次给出。 1. 2. 3. 扩展操作流程：用来描述参与者在与系统进行交互的活动序列中所