[互联网]4用例图.ppt

用例图 用例图概述 参与者 用例 各种关系 用例文档 用例图建模技术 实例练习 用例图的优点与主要作用 软件开发的首要工作是了解需求 需求分析难于确定的最主要原因是：软件的开发者并不是最终软件的使用者 用例图的优点 可视化地表达系统需求，直观规范 用例图的主要作用： 在探讨问题时，便于系统用户、系统分析和设计人员、领域专家沟通交流、达成共识 使开发者快速准确的了解用户需求和相关概念 用例图的定义与组成 定义：由参与者、用例以及它们之间的关系构成的用于描述系统功能的动态视图 组成元素 参与者（Actor） 用例（Use Case） 关系（Relationship） 参与者 定义： 人、系统或类的外部实体的抽象 存在于系统外部并直接与系统进行交互 表示方法： 使用一个人形图标来表示 参与者的名字写在人形图标下面。 参与者的种类 参与者不仅可以由人承担，还可以是其他系统、硬件设备，甚至是时钟。 人：当系统需要与某个人交互时（用户） 其它系统： 当系统需要与其它系统交互时 如：ATM系统中，银行后台系统就是参与者 硬件设备： 当系统需要与硬件设备交互时 如：门禁系统中，磁卡读写器就是参与者； 时间： 当系统需要定时触发时 如：定时闹钟系统中，时间就是参与者。 如何识别参与者？ 1）系统完工之后，谁在使用系统完成日常的工作？ 2）系统是由谁来维护和管理的？ 3）谁对系统产生的结果感兴趣？ 4）系统需要从谁那里获得数据？又为谁提供数据？ 5）系统需要与哪些其他系统交互（使用其他系统或被其他系统所使用）？ 6）系统控制的硬件设备有哪些？ 7）系统功能的执行是否受时间的影响？ 注意事项 同一个人或事物可以扮演不同的角色 参与者不是指人或事物本身，而是指人或事物当时所扮演的角色。 不能将参与者的名字设置为参与者某个实例的名字 参与者之间的关系 参与者实质上也是类，因此它拥有与类相同的关系描述 参与者与参与者之间主要是泛化关系 用例的定义 定义： 是参与者可以感受到的系统服务或功能单元。 用文本的形式描述了参与者为了使用系统的某项功能而与系统之间发生的交互过程 表示方法： 使用椭圆图形来表示 用例名称写在椭圆下方 用例名的两种表示方法 思考 用例的名称应使用动词开头 下列用例的名字是否合理？ 注意事项 用例必须由某个参与者触发激活后才能执行 每个用例至少应该对应一个参与者 如果存在没有参与者的用例，就可以考虑将这个用例并入其他用例之中 用例表明的是一个类，而非某个具体实例 用例不是一个椭圆，而是一个完整的描述 用例与场景 定义：在系统中，按照某个顺序执行了一系列相关的动作后，即可实现某种功能，把完成了这一功能操作的集合称为场景。 用例与场景的关系 类是对一组对象共同属性和行为的抽象 用例是对一组场景共同行为的抽象 场景就是用例的实例，是用例的一次完整的、具体的执行过程 场景包括成功场景和失败场景 在描述用例时应覆盖所有的场景，避免遗漏某些需求 场景举例 开发者获取需求的步骤 第一步：首先将用户的工作流程表示为场景，然后，将同类场景抽象为用例，以描述系统功能 第二步：客户和用户通过审查场景，并测试开发者提供的原型系统，以验证和确认需求规格说明 第三步，当系统需求定义成熟和稳定后，开发者和客户共同对需求规格说明进行确认。包括：系统的功能性需求、非功能需求、用例和场景在内的需求确认 如何识别用例？ 任何用例和参与者都无法独立存在 识别用例通常从分析系统参与者开始： 1）参与者希望系统提供什么功能？ 2）参与者是否需要获取或管理系统中某些信息？如果是的话，参与者又是如何完成这些操作的？ 3）参与者是否会将外部的某些事件通知给系统？ 4）系统中发生的事件是否需要通知参与者？ 5）是否存在影响系统的外部事件？ 真实项目中如何发现用例？ 请遵循如下思维习惯： 首先弄清楚有多少部门，多少岗位(参与者)？ 然后找到每一个岗位的业务代表，问他们类似的问题： 你平时都做什么？（参与者目标） 这件事是谁交办的？（交互） 做完了你需要通知或传达给谁吗？（交互） 做这件事情你都需要填写些什么表格吗？（用例） 用例的粒度 用例的粒度：用例所包含的系统服务或功能单元的多少 用例的粒度越大，其包含的功能就越多，最终得到的用例数就越少； 用例的粒度越小，其包含的功能就越少，得到的用例数就越多； 用例的粒度 粒度的选择 适中合适： 粒度太大，用例数目过少，就会分析不充分 粒度太小，用例数目过多，就会使模型庞大繁杂，难于理解和使用 具体问题具体分析 简单问题：粒度小一些，将比较复杂的用例拆分成多个 复杂问题：粒度大一些，让一个用例包含较多的需求信息量，将复杂度适当引往用例内部 用例之间的关系——包含 包含关系：用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身