UML课程设计--第三章.pptVIP

Agenda 用例图的基本概念 用例图内元素间的关系 用例图设计实例 用例图的基本概念 用例试图由用例图（ Use-case diagram ）与协作图（collaboration diagram ）、序列图（sequence diagram ）和活动图（ activity diagram ）组成。如图所示： 用例图的基本概念 在UML中，用例图用椭圆（oval）表示，它用来记录用户或外界环境从头到尾使用系统的一系列事件。用户被称为“活动者”（actor）。活动者可以是人，也可以是另外的一个系统。它与当前的系统进行交互，向系统提供输入或者获得输出。用例图显示了用例和活动者之间、用例之间以及活动者之间的关系（relation），关系描述了模型元素之间的语义连接。在UML中，关系使用实线表示，实线可以有箭头，也可以没有。 用例图的基本概念-----活动者 活动者是人或与系统进行交互的外部系统，如何判断活动者呢？分析如下问题： 1、谁对系统的某一需求感兴趣？ 2、组织中哪一部分使用系统？ 3、谁从系统的使用中受益？ 4、谁向系统提供信息？ 5、谁将维护系统？ 6、系统使用外部资源吗？ 7、系统和已经存在的系统交互吗？ 用例图的基本概念-----用例和用例图 用例是系统使用片段的集合，描述了所有的功能需求。它来自于客户需求的分析，这个过程称为用例分析，是整个系统开发中非常关键的过程。用例分析有助于如下工作： 1、捕捉需求 2、计划开发过程的循环往复 3、验证系统 4、动态分析从用例分析开始，它驱动整个开发过程。 用例图的基本概念-----什么是用例？ 用例是最终用户和开发人员之间的沟通渠道。 用例的一个主要用途就是作为沟通工具，使最终用户和开发人员能够清楚地理解需求。 用例将参与者和系统之间的对话模型化，并且由参与者来启动，以调用系统中的某个功能。 用例是完整的、有意义的事件流。 将所有用例放在一起，就构成了使用系统的所有可能的方式。 为什么要使用用例 将重点放在系统的可能用户上 确定用户与系统交互时要扮演的角色 确定用户出于各自的角色，期望从系统获得什么基本服务（用例） 描述每个用户或角色与其期望从系统获得的服务之间的交互 用例图的基本概念-----用例和用例图 如何标记一个用例呢？可以从以下几个方面来考虑： 1、活动者希望这个系统执行什么任务？ 2、活动者在系统中会访问那些信息（创建、存储、修改、删除等）？ 3、需要将外部的哪个变化告知系统？ 4、需要将系统的哪个时间告知活动者？ 5、如何维护系统？ 用例图的基本概念-----事件流 要建立实际的系统，还需要更多的细节，这些细节写在事件流文档中。事件流的目的是在建档时，说明用例的逻辑流程。在事件流文档中，详细描述系统用户的工作和系统本身的工作。事件流是独立于实现方法的，它通常包括：简要说明、前提条件、主事件流、其他事件流和事后条件。 1、简要说明 每个用例应有一个相关说明，描述该用例的作用。例如买机票用例可以说明为：买机票用例供客户浏览航班信息、查询和用信用卡买机票。 2、前提条件 前提条件列出开始用例之前必须满足的条件。如，前提条件可能是另一个用例已经执行，或者用户具有运行当前用例的权限。 用例图的基本概念-----事件流 3、主事件流和其他事件流 用例的具体细节在主事件流和其他事件流中描述。事件流描述执行用例功能的具体步骤。事件流关注系统做什么，而不是怎么做，它是从用户角度写成的。 主事件流和其他事件流包括如下方面： ?、用例如何开始 ?、用例的各种路径 ?、用例的正常（主）流程 ?、用例主事件流（其他事件流）的变形 ?、错误流 4、事后条件 事后条件是用例结束后执行的动作，比如一个用例结束后必须运行另一个用例。并不是每个用例都有时候条件。 用例图的基本概念-----事件流 5、设计实例 主事件流是正常情形，是用例中的最常用路径。以购买机票的事件流为例，买票时，主事件流是顺利买到票；其他事件流是从主事件流中分支出来的，但是不是错误条件。如，信用卡无效或票没有了，这些只能是合法的，不是系统中发生的错误。错误流表示错误条件，如系统无法验证信用卡或者没有航班，错误流是系统本身的问题。 以航班售票为例，书写主事件流的步骤如下： 1、客户选择浏览航班信息的选项时，用例开始 2、提示输入出发站和到达站、出发时间和到达时间 3、用户输入出发站和到达站、出发时间和到达时间 4、系统先是航班清单及票价：A1：没有这个航班 5、用户选择要订的航班 6、系统显示这个航班的所有票价选项 7、用户选择要订的票价选项：A2：用常客卡选择免费的 8、系统确认票价 9、用户确认票