UML系统建模及系统分析与设计课件：需求分析与用例建模.ppt

3.用例建模的步骤⑺寻找每一个用例在正常条件下的执行过程。⑻寻找每一个用例在非正常条件下的执行过程。⑼用UML建模工具画出分层的用例模型图。⑽审核用例模型。⑾编写用例模型图的补充说明文档。4.业务用例建模当进行一个项目的需求分析时，首先要听用户谈他们的需求，或者看用户提交的业务需求文档。用户一定会提出一个又一个的功能或要求，它们中的每一个要求就成为了最初的用例。分析这些用例，关注它们的每一个参与者，以及它们相互之间的关系，这就形成了最初的用例模型。在采用用例分析的方式与客户沟通需求的时候，应当着重关注的是参与者及其目标，即每个功能的参与者是谁，完成这个功能的目标是什么，以及如何完成这个目标。4.业务用例建模这时的用例说明采用概述的方式，即只进行主成功场景（基本流程）的描述。此后，继续细化用例，各个用例的替代场景（分支流程）逐渐被整理出来，用例再一步步细化。开发人员对一些需求的认识一开始可能存在着偏差，因此，需要不断更正用例描述。一些新的功能可能被用户提出来，形成一些新的用例。如此反复数轮之后，项目需求的整体框架才逐渐清晰。然后应该讨论系统边界，对用例模型进行再一次调整。3.2.2确定系统边界和范围 1.确定系统的边界任何一个系统都有一个边界的问题。边界问题就是确定系统和相邻系统交接部分。定义系统边界就是定义系统的范围，即哪些元素属于本系统，哪些元素属于相邻系统，明确系统目标范围。系统边界是一个软件系统需要处理的整个问题空间的范围。一个软件系统不可能处理所有问题，必须得给它定义这个问题空间的范围。2.确定系统的范围在确定好系统的执行者和用例后，系统的边界就确定了。然后就需要确定项目的范围，清晰的定义项目的范围，将不需要做的事情放到一边，同时为需要做的划分优先级。系统范围是指整个系统中安全基线所涉及的对象和考虑的范围，系统范围确定是一个划定系统安全边界的过程，该边界界定了安全基线的管辖范围，即将系统划分为内部和外部两部分，系统内部即为安全基线的系统范围，系统外部即为系统环境，而系统安全边界正是这两部分的接口。3.2.3确定参与者 通常将系统外部与系统内部交互的事物统称为参与者，也有的称为执行者或者角色。参与者是在系统之外与系统交互的某人或事物，每一个执行者都对应一种特定的角色，每一个系统之外的实体对应多种执行者，就好比一个人在系统中他会有多种角色一样，又或者几个人可以用一个执行者来表示，因为他们对于系统来讲属于同一个角色。参与者是在系统之外，在系统之内的不是参与者，参与者与系统有明显的系统边界。如何寻找参与者可以参考如下的信息源：标示系统范围和边界的上下文图；现有的系统文档和系统手册；项目会议和研讨会的记录；现有的需求文档、项目章程或工作陈述。参与者总是在你的系统之外，他们从来都不是系统的一部分。为了帮助找到执行者，可以在人、其他的软件、硬件设备、数据存储、或者网络目录中进行寻找。参与者是在系统之外，透过系统边界与系统进行有意义交互的任何事物。通俗地讲，参与者就是所要定义系统的使用者。寻找参与者可以从以下问题入手：⑴系统开发完成之后，有哪些人会使用这个系统？⑵系统需要从哪些人或其他系统中获得数据？⑶系统会为哪些人或其他系统提供数据？⑷系统需要与哪些其他系统交互？⑸系统是由谁来维护和管理并保持其正常运行？⑹系统需要应付（处理）哪些硬设备？⑺谁（或什么）对系统运行产生的结果感兴趣？⑻有没有自动发生的事件？3.2.4确定需求用例 用例图中首先要明确的概念就是用例。用例是系统的一个功能单元，描述了参与者与系统发生的一次交互行为。用例，就是一件事情，要完成这件事情，需要一系列活动。做一件事情可以有很多不同的方法和步骤，也可能会有各种各样的意外情况，因此，这件事情由很多不同情况的集合构成，在UML中称为场景。用例必然是以动宾形式出现，用例相对独立，但不意味用例不与其他用例交互而独立完成参与者的目的。3.2.4确定需求用例 确定用例主要是看各参与者需要系统提供什么样的服务，或者说参与者是如何使用系统的。如银行的ATM自动提款机系统，用户提款就是一个用例。用例就是一个用来描述参与者如何使用系统来实现其目标的一组场景的集合。用例强调的是一组场景，在这组场景不多但相互之间存在功能上的共性，就像一个大功能模块下的多个子模块。这组场景中的每一个，又分别形成一个个子用例。寻找用例的方法：⑴从原始需求中寻找所包含的功能。⑵未来的系统，需要和哪些系统发生信息交互？⑶哪些人将操作未来的软件系统？⑷系统有哪些受限的条件？⑸未来的软件界面怎样组织？⑹系统的响应有哪些去向？3.2.5用例模型的关系