用例建模[精选].ppt

用例建模 用例模型 用例模型是把应满足用户需求的基本功能集聚合起来表示的强大工具 对于正在构造的新系统用例描述系统应该作什么 对于已构造完毕的系统用例则反映了系统能够完成什么样的功能 用例模型的目的 构建用例模型是通过开发者与客户，或最终使用者共同协商完成的。 经过反复讨论需求的规格说明，达成共识，明确系统的基本功能，为后阶段的工作打下基础。 确定系统应具备哪些功能、为系统的功能提供清晰一致的描述、为系统验证工作打下基础、提供跟踪进入系统中具体实现的类和方法，检查其是否正确的能力。 用例视图: 用例是Jacobson在面象对象的软件工程中提出的，但它实际上是独立于面象对象的。 用例是获取业务过程和系统需求的有效方式，使得需求可浏览，而且技术本身是非常简单易学的。 用例描述 用例内容，即该用例所代表功能的具体实现过程，通常用普通的文字书写，在UML语言中用例内容被看作用例元素的文档性质 另一描述用例内容的工具是活动图 用例的描述应包括下面几个方面 用例的目标：用例的最终任务是什么？想得到什么样的结果？即每个用例的目标一定要明确 用例是怎样被启动的：哪个角色在怎样的情况下启动执行用例 角色和用例之间的消息流： 角色和用例之间的哪些消息是用来通知对方的？ 哪些是修改或检索信息的？ 哪些是帮助用例做决定的？ 系统和角色之间的主消息流描述了什么？ 问题系统使用或修改了哪些实体？ 用例的多种执行方案：在不同的条件或特殊情况下，用例能依当时条件选择一种合适的执行方案。具体的出错处理可以用脚本描述。 用例怎样才算完成：描述中应明确指出在什么情况下，用例才能被看作完成；当用例被看作完成时，要把结果值传给角色 用例也可以用活动图描述，即描述角色和用例之间的交互。 用例模型的组成 用例：从外部用户的角度观察系统应支持哪些功能，帮助分析人员理解系统的行为，它是对系统功能的宏观描述。 系统：一个完整的系统中通常包含若干个用例，每个用例具体说明应完成的功能，代表系统的所有基本功能集 角色：与系统进行交互的外部实体，它可以是系统用户，也可以是其它系统或硬件设备 角色 Actor 角色定义： 在系统边界之外，透过系统边界与系统进行有意义的交互的任何人或事物。 角色与系统交互： 角色向系统发送消息、从系统接受消息、或是与系统交换信息。 角色类型： 人、外部系统、外部设备或Timer 角色与用例： 角色往往是发现新用例的基础，同时也是分析员和用户交流的起点 角色的特征 角色是一个类，包含属性、行为和描述角色的文档，而不是类的实例。 角色的确定代表着系统边界的确定。 角色的命名： 必须是名词，不能写成角色的某个实例 识别系统边界和角色 通过向用户提问来识别角色： 谁使用系统提供的主要功能？（主要角色） 谁来维护、管理系统？（次要角色） 谁需要借助于系统完成日常工作任务？ 系统需要控制的硬件设备有哪些？ 系统需要与其他哪些系统交互？ 系统从哪儿得到信息？ 对系统产生的结果感兴趣的人或事是哪些？ ！不能把目光只专著于人身上。 角色间可引入继承关系 ATM系统的Actor 1、谁使用ATM系统的主要功能（提款）？ ATM系统的Actor 定义：由系统执行的一个动作序列，并能产生可观测的结果值给特定的角色 特点： 通常由某个角色直接或间接的启动 用例把可观测的执行结果反馈给角色 用例在功能上具有完整性 系统是一个黑盒，用例描述从系统的外部看来，角色和用户的交互过程，但不涉及任何的系统内部结构－避免给设计带来限制 用于描述系统行为，但不描述如何实现 识别用例 首先弄清楚系统的问题域、业务流程，整理出系统的功能需求，在此基础上结合已经识别出来的角色识别、抽象出系统用例，定义并描述它。 针对角色 某个角色要求系统为其提供什么功能；该角色需要做哪些工作？ 角色需要阅读、创建、销毁、更新或存储系统中的某些（类）信息码？ 系统中的事件一定要告知角色吗？角色需要告诉系统一些什么吗？ 由于系统新功能的识别，角色的日常工作被简化或效率提高了吗？ 针对系统 系统需要什么样的输入和输出？输入来自哪里？输出去往哪里？ 该系统的当前状况还存在哪些问题？ 改进的方向？ ！！！在用例描述中不要包含GUI设计，因为用例是针对需求的，而界面设计是“设计”，不要把设计的东西放进需求里。 用例之间的关系：Extend 一个用例中加入一些新的动作后则构成了另一个用例，这两个用例之间的关系就是通用化关系，又称扩展关系。 后者通过继承前者的一些行为得来，前者通常称为通用化用例，后者常称为扩展用例。 扩展用例只有在基本用例中的某种条件满足时才能执行，如果没有基本用例的运行，扩展用例不能运行 基本用例执行时,扩展用例不一定执行 用例之间的关系：Uses 一个用例使用另一个用例时，这两个用例之间