UML学习复习PPT-用例.ppt

用例 高天迎 用例 1 用例的概念 2 用例建模技术 3 实例——图书馆管理系统中的用例 需求分析 需求分析的任务是确定所开发的软件的功能、性能、数据等各个方面的要求。主要解决系统“做什么”的问题。 需求分析是软件整个开发过程中的一个关键过程。 需求分析中的“沟通鸿沟”： 需求分析需要各方面人员（如分析人员、开发人员、客户等）的参与，而这些人员有着不同的知识背景，对目标系统的认知程度也各不相同，这种差异导致各方面人员之间沟通困难，人为的给需求分析的实施增加了难度。 需求规格说明书的目录框架参考 需求 需求定义：需求（requirement）就是系统（更广义的说法是项目）必须提供的能力和必须遵从的条件。 需求分类： 功能性（行为的），有具体的完成内容的需求。 客户登录、邮箱网站的收发收发邮件、论坛网站的发帖留言等。 用户能够搜索所有的数据集合 每一个订单需要分配一个唯一标识符，用户可以永久保存起来 需求 非功能性（其它所有的行为） ，软件产品为满足用户业务需求而必须具有且除功能需求以外的特性，包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。 性能要求：要求系统能满足100个人同时使用，页面反应时间不能超过6秒； 可靠性： 系统能7×24小时连续运行，年非计划宕机时间不能高于8小时。要求能快速的部署，特别是在系统出现故障时，能够快速的切换到备用机。?? 领域规则，法律，知识产权… 需求 在统一过程（UP）中，需求按照“FURPS+”模型进行分类。 功能性（Functional）：特性、功能、安全性； 可用性（Usability）：人性化因素、帮助、文档； 可靠性（Reliability）：故障频率、可恢复性、可预测性； 性能（Performance）：响应时间、吞吐量、准确性、有效性、资源利用率； 可支持性（Supportability）：适应性、可维护性、国际化、可配置性。 需求 “FURPS+”中的“+”是指一些辅助性的和次要的因素，比如： 实现（Implementation）：资源限制、语言和工具、硬件等； 接口（Interface）；强加于外部系统接口之上的约束； 操作（Operation）：对其操作设置的系统管理； 包装（Packaging）例如物理的包装盒； 授权（Legal）：许可证或其他方式。 需求问题的代价 想改进就能改进吗？ 需求——石头问题 需求问题——对策 1. 概念 1.1 概述 1.2 参与者 1.3 用例 1.4 用例之间的关系 1.1 概述 用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供的服务。 用例图最常用来描述系统以及子系统。 1.1 概述 用例图包含6个元素： 参与者（Actor） 用例（Use Case） 关联关系（Association） 包含关系（Include） 扩展关系（Extend） 泛化关系（Generalization） 1.2 参与者 定义：Actor是指系统以外的，需要使用系统或与系统交互的东西，包括人，设备和其它系统。Actor有不同的译名，如：参与者, 活动者, 执行者, 行动者等。 系统外部的一个实体。 参与用例的执行过程。 通过向系统输入或请求系统输入某些事件来触发系统的执行。 由参与用例时所担当的角色来表示。 每个参与者可以参与一个或多个用例。 1.2 参与者 参与者的种类： 系统用户 与所建造的系统交互的其他系统 一些可以运行的进程 确定参与者 如何寻找系统的参与者 谁使用系统的主要功能？ 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务？ 谁负责维护、管理并保持系统正常运行？ 系统需要应付（处理）哪些硬设备？ 系统需要和哪些外部系统交互？ 谁（或什么）对系统运行产生的结果感兴趣？ 有没有自动发生的事件 确定参与者 对参与者建模的过程中需要注意的问题 参与者对于系统而言总是外部的 参与者可以直接或间接的同系统交互 一个人或事物在与系统交互时，可以扮演多个角色 每一个参与者必须有简短的描述 参与者间的关系 参与者(actor)之间可以存在泛化关系，表示一个一般性的参与者与另一个更为特殊的参与者之间的联系。 参与者间的泛化关系示例： 说明 例：在线银行系统的一些可能的参与者 客户：从系统获取信息并执行金融交易。 管理人员：开办系统的用户。获取并更新信息。 厂商：接受作为转帐支付结果的资金 mail系统 说明 责任类似或重叠——泛化出一个抽象执行者 1.3 用例 Use Case概念是Jacobson于60年代和70年代在爱立信公司开发AKE，AXE系列系统时发明的，并在其博士论文(85年)和92