第3章 uml系统建模与分析设计需求分析与用例建模01（课件）.pptVIP

软件工程方法 3.2 客户需求分析与用例建模 用例驱动是统一过程的重要概念，或者说整个软件生产过程就是用例驱动的。 分析、设计、实现、测试都是用例驱动的，都是以实现用例为目标。 用例的捕获手段——抽象 用例建模的步骤 确定系统的范围和边界； 确定系统的执行者和用例； 对用例进行描述； 定义用例之间的关系； 审核用例模型。 3.2.4 确定执行者(参与者) 执行者（actor）是指在系统外部与系统交互的人或其他系统，他以某种方式参与了系统内用例的执行。 Actor：在系统之外与系统交互的某人或某事物。 Actor在建模过程中是处于核心地位的。 参与者 业务工人 1．定义执行者时应注意的几个问题 （1）执行者之间可以有继承关系 （2）执行者代表一种角色而不是具体某个人 （3）对同一个人担任角色的限制 （4）执行者可分成主执行者和副执行者 （5）执行者还可细分为主动执行者和被动执行者 3.2.5.确定用例1.用例的特征 响应性。一个用例不自动执行，总是有执行者启动。 回执性。 用例执行完毕，向执行者提供可识别的返回值。 完整性。 用例表示一个完整的功能，必须是一完整的描述。 必须以向执行者提供返回值作为该用例完整性的标志。 用例的执行结果对参与者来说是可观测的和有意义的。 如，系统会监控参与者在系统里的操作，并在参与者删除数据之前备份。虽然它是系统的一个必需组成部分，但它在需求阶段却不应该作为用例出现。 因为这是一个后台进程，对参与者来说是不可观测的，它应该在系统用例分析阶段定义。 又比如，登录系统是一个有效的用例，但输入密码却不是。这是因为登录系统对参与者是有意义的，这样他可以获得身份认证和授权，但输入密码却是没有意义的，输入完了呢？有什么结果吗？ 用例必然是以动宾短语形式出现的。即，这件事必须有一个动作和动作的受体。 例如，喝水是一个有效的用例，而“喝”和“水”却不是。虽然生活常识告诉我们，在没有水的情况下人是不会做出喝这个动作的，水也必然是喝进去的，而不是滑进去的. 但是我们所见的很多用例中类似“计算”，“统计”，“报表”，“输出”，“录入”之类的并不在少数。 3.2.5.2.寻找和确定用例 业务用例：开始阶段，在确定用户需求过程中，系统分析员通过与客户交流建立业务模型来发现和确定的用例。 系统用例：系统构造阶段，系统分析和设计人员在进行系统分析和设计时，根据系统的需求建立的用例。 在系统开发的开端阶段，应把注意力集中在业务用例上，在精化阶段和构建阶段再考虑系统用例 建立用例模型时，可询问： 用户(执行者)需要系统提供哪些业务功能,即系统能做什么? 用户最关心系统中哪些事件?从功能观点看,这些事件表示什么? 用户要了解系统在工作中发生了哪些事件及其结果? 用户自己需要做什么? 用户是否要在系统中创建、删除、读、修改或存储某类业务数据？ 系统为了维持正常运转需要增加的功能和信息的交互； 这些信息从何而来，到哪里去？ 实现当前系统（可能是人工系统而不是自动化系统）的关键问题是什么？ 通过与用户反复交流，确定主要业务用例和次要业务用例。 对于建立的每一个业务用例，都需要一组系统用例来辅助和支持。（不严谨） 系统用例是执行者与系统的交互，它描述了系统的功能需求和动态行为。 系统用例用于建立系统用例模型，可通过分析系统的业务流和控制流来寻找和确定系统用例。（活动图） 应当先建立业务用例模型，然后再从业务用例模型向系统用例模型映射。 注意用例图的层次，从系统到子系统逐层建立用例图。 结构性观点：自行车是一种交通工具，它由传动系统、刹车系统等部分组成。 功能性观点：自行车可以骑行。 使用者观点：人们可以用双脚蹬动踏板而向前行进，可以用手捏合刹车使自行车停下来。 总结： 功能是脱离使用者的愿望而存在的。 功能是孤立的，给一个输入，通过计算就有一个固定的输出－－只要按下开关灯就亮。 用例是系统性的，它需要描述谁在什么情况下通过什么方式开灯，结果是什么。 功能描述的是一个个点。 用例描述的是一个系统性工作。 3.2.5.3.描述用例 用例名： 简单名： 路径名： 用例的文字描述应包括以下内容: 用例的目的（功能）； 该用例在什么情况下被哪个执行者启动执行； 用例与执行者之间交互哪些消息来通知对方作出决定； 交互的主消息流及因此被使用或修改的实体； 用例中可供选择的异常事件流； 用例结束标志：给执行者返回一个可识别的值。 举例 用例名称：学生选课 执行者：学生 目的：完成一次学生选课的完整过程。 类型：主要的、基本的 级别：一级 过程描述： （1）学生输入标识码（ID），系统识别标识码的有效性； （2）对学生进行注册识别； （3）流览本学期预开课程； （4）选择学生自己要上的课程并确认； （5