《uml培训之二用例》由会员分享，可在线阅读，更多相关《uml培训之二用例（50页珍藏版）》请在金锄头文库上搜索。
1、 STTSTT2005 Confidential2005 Confidential1 1全成通信UML Use Case 介绍2005-12-13 研发中心 周庭栋 上海全成通信技术有限公司STTSTT2005 Confidential2005 Confidential2 2全成通信目录n什么是Use Case？nUse Case的表现现形式n用例建模n软软件需求n调调整用例模型n管理用例模型的复杂杂度n为为什么使用用例nFAQSTTSTT2005 Confidential2005 Confidential3 3全成通信什么是Use Case？一个用户或其它系统与要设计的系统进行的一个交互，这
2、个交互是 为了达到某个目标。n在“饮饮料销销售机”购买饮购买饮 料n通过过ATM上查询账户查询账户 余额额n在ATM上提款n在ATM上转账转账注意：1、读读音 2、 用例/用况STTSTT2005 Confidential2005 Confidential4 4全成通信目录n什么是Use Case？nUse Case的表现现形式n用例建模n软软件需求n调调整用例模型n管理用例模型的复杂杂度n为为什么使用用例nFAQSTTSTT2005 Confidential2005 Confidential5 5全成通信Use Case表现形式用例图n参与者参与者是指存在于被定义系统外部并与该系统发生交互的
3、人或其他系统。n用例用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。 n通讯关联通讯关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪 些服务（用例），或者说系统所提供的服务（用例）是被哪些参与者所使用的。STTSTT2005 Confidential2005 Confidential6 6全成通信Use Case表现形式事件流n如何表现现用例的细节细节 ？事件流n提款-基本事件流(basic flow)1.用户插入信用卡 2. 输入密码 3. 输入提款金额 4. 提取现金 5. 退
4、出系统，取回信用卡n提款-备选事件流 (Alternative Flow)备选流1：用户可以在基本流中的任何一步选择退出，转至基本流步骤5。 备选流2：在基本流步骤1中，用户插入无效信用卡，系统显示错误并退出信用卡，用 例结束。 备选流3：在基本流步骤中，用户输入错误密码，系统显示错误并提示用户重新输入 密码，重新回到基本流步骤2；三次输入密码错误后，信用卡被系统没收，用例结束。 basic flow + (All)Alternative flow = 用例场景（Scenario、用例实例）STTSTT2005 Confidential2005 Confidential7 7全成通信目录n什么
5、是Use Case？nUse Case的表现现形式n用例建模n软软件需求n调调整用例模型n管理用例模型的复杂杂度n为为什么使用用例nFAQSTTSTT2005 Confidential2005 Confidential8 8全成通信用例建模n用例建模：使用用例的方法来描述系统的功能需求的过程n用例模型：l用例图(Use Case Diagram) 确定系统中所包含的参与者、用例和两者之间的对应关系，用例图描述的是关于系统功能的一个概述。 l用例规约(Use Case Specification) 针对每一个用例都应该有一个用例规约文档与之相对应，该文档描述用例的细节内 容。STTSTT2005
6、 Confidential2005 Confidential9 9全成通信用例建模建模步骤骤：n找出参与者n确定与参与者相关的用例n细化每个用例的用例规约STTSTT2005 Confidential2005 Confidential1010全成通信用例建模寻找参与者参与者：所有存在于系统统外部并与系统进统进 行交互的人或其他系统统。-参与者要点：n系统外 - 必须和它交互n系统边界 责任边界，非物理边界n系统边界 直接与系统交互n有意义交互 属于目标系统的责任n任何事物 人、外部系统、外部因素、时间STTSTT2005 Confidential2005 Confidential1111全成通
7、信用例建模寻找参与者n系统开发完成之后，有哪些人会使用这个系统？ n系统需要从哪些人或其他系统中获得数据？ n系统会为哪些人或其他系统提供数据？ n系统会与哪些其他系统相关联？ n系统是由谁来维护和管理的？ STTSTT2005 Confidential2005 Confidential1212全成通信用例建模寻找参与者- 系统边统边 界决定了参与者n参与者是由系统的边界所决定的，如果我们所要定义的系统边界仅限于ATM机本身，那么后 台服务器就是一个外部的系统，可以抽象为一个参与者n如果我们所要定义的系统边界扩大至整个银行系统，ATM机和后台服务器都是整个银行系统 的一部分，这时候后台服务器就
8、不再被抽象成为一个参与者。STTSTT2005 Confidential2005 Confidential1313全成通信用例建模寻找参与者用例建模时不要将一些系统的组成结构作为参与者来进行抽象，如在ATM机系统中，打印机只是系统的一个组成部分，不应将它抽象成一个独立的参与者；在一个MIS管理系统中，数据库系统往往只作为系统的一个组成部分，一般不将其单独抽象成一个参与者。 STTSTT2005 Confidential2005 Confidential1414全成通信用例建模寻找参与者- 特殊的参与者：系统时钟 有时候我们需要在系统内部定时地执行一些操作，如检测系统资源使用情况、定期 地生成统
9、计报表等等。从表面上看，这些操作并不是由外部的人或系统触发的，应 该怎样用用例方法来表述这一类功能需求呢？对于这种情况，我们可以抽象出一个 系统时钟或定时器参与者，利用该参与者来触发这一类定时操作。从逻辑上，这一 参与者应该被理解成是系统外部的，由它来触发系统所提供的用例对话。STTSTT2005 Confidential2005 Confidential1515全成通信用例建模确定用例n参与者为什么要使用该系统？ n参与者是否会在系统中创建、修改、删除、访问、存储数据？如果 是的话，参与者又是如何来完成这些操作的？ n参与者是否会将外部的某些事件通知给该系统？ n系统是否会将内部的某些事件通
10、知该参与者？ STTSTT2005 Confidential2005 Confidential1616全成通信用例建模确定用例n每个用例至少应该涉及一个参与者n每个参与者也必须至少涉及到一个用例STTSTT2005 Confidential2005 Confidential1717全成通信用例建模描述用例规约规约n用例规约内容n简要说明 (Brief Description) 简要介绍该用例的作用和目的。 n事件流 (Flow of Event) 包括基本流和备选流，事件流应该表示出所有的场景。 n用例场景 (Use-Case Scenario) 包括成功场景和失败场景，场景主要是由基本流和备
11、选流组合而成的。 n特殊需求 (Special Requirement) 描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计 约束（所使用的操作系统、开发工具等）。 n前置条件 (Pre-Condition) 执行用例之前系统必须所处的状态。 n后置条件 (Post-Condition) 用例执行完毕后系统可能处于的一组状态。STTSTT2005 Confidential2005 Confidential1818全成通信用例建模特殊需求特殊需求通常是某一用例所专有的非功能性需求，不适合在用例的事 件流中进行说明n法律或法规方面的需求 n应用程序标准和所构建系统的质量属
12、性（可用性、可靠性、性能、支持性需求）n操作系统及环境、兼容性需求 nn注意：这里记录的是专属于该用例的特殊需求；对于一些全局的非功 能性需求和设计约束记录在补充规约中。STTSTT2005 Confidential2005 Confidential1919全成通信用例建模检查检查 用例模型n功能需求的完备性 n模型是否易于理解 n是否存在不一致性 n避免二义性语义STTSTT2005 Confidential2005 Confidential2020全成通信目录n什么是Use Case？nUse Case的表现现形式n用例建模n软软件需求n调调整用例模型n管理用例模型的复杂杂度n为为什么使用
13、用例nFAQSTTSTT2005 Confidential2005 Confidential2121全成通信 软件需求分类RUP的FURPS+模型将软件需求分为以下几类：n功能(Functionality) n可用性(Usability) n可靠性(Reliability) n性能(Performance) n可支持性(Supportability) n设计约束等 除第一项功能性需求之外的其他需求都归之为非功能性需求。STTSTT2005 Confidential2005 Confidential2222全成通信 软件需求工件集n功能性需求u用例模型用例图：描述参与者和用例之间的关系 用例规约
14、：描述每一个用例的细节信息 n非功能性需求u补充规约：记录一些全局性的功能需求、非功能性需求和设计约束等 u词汇表：记录一些系统需求相关的术语 STTSTT2005 Confidential2005 Confidential2323全成通信软件需求补充规约n功能性 功能性需求主要在用例模型中刻画，但是也有部分需求不适合在用例中表述。有些功能性需求是全局性 的，适用于所有的用例，如出错处理、I18N支持等，不需要在所有的用例中描述这些功能性需求，只 需要在补充规约中统一描述就可以了。 n可用性 记录所有可用性相关的需求，如系统的使用者所需要的培训时间、是否应附合一些常见的可用性标准如 Windo
15、ws界面风格等。 n可靠性 定义系统可靠性相关的各种指标，包括： l可用性：可用时间百分比(xx.xx%)，系统处于使用、维护、升级等操作的小时数； l平均故障间隔时间(MTBF)：通常表示为小时数，但也可表示为天数、月数或年数； l平均修复时间(MTTR)：系统在发生故障后可以暂停运行的时间； l精确度：指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准 ）； l最高错误或缺陷率：通常表示为bugs/KLOC（每千行代码的错误数目）或 bugs/function-point（每个功能点的错误数目）。STTSTT2005 Confidential2005 Confidentia
16、l2424全成通信软件需求补充规约n性能 记录系统性能相关的各种指标，包括： l对事务的响应时间（平均、最长）； l吞吐量（例如每秒处理的事务数）； l容量（例如系统可以容纳的客户或事务数）； l降级模式（当系统以某种形式降级时可接受的运行模式）； l资源利用情况：内存、磁盘、通信等。 n可支持性 定义所有与系统的可支持性或可维护性相关的需求，其中包括编码标准、命 名约定、类库、如何来对系统进行维护操作和相应的维护实用工具等。 n设计约束 设计约束代表已经批准并必须遵循的设计决定，其中包括软件开发流程、开 发工具、系统构架、编程语言、第三方构件类库、运行平台和数据库系统等 等。 STTSTT2005 Confidential2005 Confidential2525全成通信软件需求词汇表n用
