Python设计模式 – UML – 用例图

摘要

简介用例图主要是从用户的角度出发对软件产品的功能及执行者进行描述的。用例图是从需求分析到软件交付的第一步，图示化展示参与者与参与者

　　简介
　　用例图主要是从用户的角度出发对软件产品的功能及执行者进行描述的。
　　用例图是从需求分析到软件交付的第一步，图示化展示参与者与参与者之间、参与者与用例之间、用例与用例之间的关系，帮助开发人员更好的理解系统的功能。
　　用例图在使用UML的开发过程中非常重要，需求分析、任务分解、界面设计、类与接口的抽象、详细设计、配置管理、测试实施等阶段都是以用例图为重要支撑的。
　　用例图建模步骤
　　- 在需求分析过程中识别出参与者及系统边界
　　- 提取每位参与者期望的行为或者需要系统提供的功能作为用例
　　- 提炼出参与者的公共行为或者系统的公共功能以备其他用例调用、扩展或泛化
　　- 分解正常功能流程作为正常事件流，异常功能流程作为异常事件流
　　- 在用例图中对参与者、用例及它们之间的关系进行建模
　　用例图的元素
　　用例图中的元素有参与者、用例、及它们之间的关系。其中参与者/用例之间的关系主要有关联、泛化、包含、扩展。
　　参与者：系统外的一个实体，可以是任何人、任何事、软件系统或硬件系统
　　表示方式：参与者在UML中的标识方式

　　确定原则：确定什么样的人或事可以被当作参与者
　　- 系统开发完成后，由谁安装、启动、使用、维护或关闭系统
　　- 系统开发完成后，哪些人与该系统交互，如单/双向通信、获取数据或输入信息
　　- 系统开发完成后，哪些外部系统会与该系统关联
　　- 系统开发完成后，会有什么事触发、中断或恢复系统
　　参与者涉及的关系：关联（参见用例图的关系部分）
　　参与者注意事项
　　- 参与者对于系统而言是外部的、
　　- 参与者与系统交互可以帮助定义系统的边界
　　- 参与者在与系统交互是可以同时或不同时扮演多个角色
　　- 参与者必须有业务角度的简短描述
　　- 参与者可以有属性和可接受的条件
　　用例：是软件中的一个个功能单元，用于说明参与者是如何使用系统的。确定参与者之后，就可以根据参与者来确定系统的用例了。
　　表示方式：用例在UML中的标识方式

　　确定原则：确定什么样的功能可以被当作用例
　　- 参与者期望使用该系统完成什么工作，比如说增删改查信息，存储同步数据，业务流程等
　　- 外部条件发生变化时，参与者是否会将这些外部变化通知给该系统
　　- 系统内部出现变化时，系统是否会将这些内部变化通知给相关的参与者
　　- 系统正常运行的事件流及出现异常错误的事件流，以及定时运行的操作
　　- 系统内部管理维护，如升级、降级、配置、容灾、备份等运维操作
　　用例之间的关系：包含、扩展、泛化（参见用例图的关系部分）
　　用例规约：每个用例都应该包含以下属性。用例的可选属性包括前置条件和后置条件，具体含义参考用例图的主要属性部分
　　- 简要描述：该用例的作用或目的
　　- 事件流：表示该用例的所有场景，包括基本事件流和备选事件流
　　- 成功场景和失败场景：场景主要是由基本流和备选流组合而成的
　　用例的注意事项
　　- 用例一定是系统的功能，但系统的功能不一定是用例
　　- 用例名称常是“强动词”开头的动宾短语，直白明确
　　- 用例一定是由参与者发起的，不应该是自动启动的
　　-用例设计时需要把握好粒度和范围
　　用例图的关系
　　用例图中参与者/用例之间的关系大致有四种：关联、泛化、包含、扩展
　　参与者与参与者之间的关系
　　参与者实质上也是类，参与者与参与者之间主要是泛化(继承)关系
　　- 泛化(Generalization)：使用空心三角直线标识，从子类参与者指向超类参与者

　　参与者与用例的关系
　　参与者与用例之间使用关联关系，表示该参与者代表的外部系统与系统内部功能之间的交互。
　　- 关联(Association): 使用实线箭头标识，从参与者指向用例

　　用例与用例之间的关系
　　- 包含<<include>>： 一个用例需要使用另一个用例定义的功能来实现自身特性
　　表示方式为虚箭头 + <<include>>，从基础用例指向被包含用例

　　<<include>>的适用场景：
　　- 两个用例之间有重叠的功能，可以将重叠部分提取成第三个用例，这两个用例可以和第三个用例建立包含关系
　　提取重叠功能单元前后的用例图对比：

　　- 当一个用例功能太多时，可以使用包含关系建立若干更小的用例

　　- 扩展<<extend>>：一个用例扩展另一个用例的功能
　　表示方式为虚箭头 + <<extend>>，从扩展用例指向基础用例

　　<<extend>>的适用场景：将基本不变的常规功能放在基用例中，将可选的、易变动的或特定条件下的功能放在扩展用例中

　　- 泛化：父用例泛化为多个子用例
　　子用例继承父用例所有的属性、结构、行为和关系，并能够衍生自己的特性.
　　表示方式为空心三角箭头直线，从子用例指向父用例

　　包含 & 扩展 & 泛化的区别
　　- 包含侧重基础用例与被包含用例之间的整体/部分关系
　　- 扩展侧重基础用例与扩展用例的相互独立性
　　- 泛化侧重子用例之间的互斥性
　　用例图的主要属性
　　用例图中涉及到的属性除了用例规约中的事件流、成功场景、失败场景外，还包括前置条件、后置条件、粒度、范围等。
　　事件流：参与者与系统交互的过程。包括基本流和备选流，二者组合起来应该覆盖用例的所有场景。
　　- 基本流：用例中符合常规预期的程序执行路径，如正常的登录、查询、退出
　　- 备选流：用例中出现特殊情况时的程序执行路径，如异常的断电、宕机、磁盘满等
　　成功场景 & 失败场景：与事件流中的基本流和备选流相对应
　　前置条件：使用这个用例之前必须要满足的条件，非必选
　　后置条件：用例执行结束后的处理结果或系统状态，非必选
　　粒度 & 范围：用例所包含额系统服务或功能单元的多少。分为三个层次：概述级、目标级、子功能级。
　　- 概述级

　　- 目标级

　　- 子功能级

　　一般来说用例粒度越小，用例数越多，反之用例数越少。建议一开始不妨粗略设计用例图，然后再细化分解，比如说在开发的不同阶段使用不同的用例粒度：
　　- 需求分析阶段：一个用例覆盖主要场景，描述一次成功完整的事件流执行过程
　　- 用例分析阶段：稍多用例覆盖多个典型场景，分别描述典型场景的基本事件流和备选事件流
　　- 用例设计阶段：多个用例拆分出主要分支，覆盖大部分场景的基本事件流和备选事件流
　　- 详细设计阶段：根据系统设计的实际需要补充或修改用例描述，增减用例数量
　　用例图示例
　　以银行用户业务为例

　　用例表示例
　　如果用例图无法覆盖系统需求的具体场景，可以考虑增加用例表描述使系统更清楚易懂。

　　用例图注意事项
　　- 定义清晰的系统边界，清晰的功能分解
　　- 从参与者承担的角色出发给用例命名，要求直观易懂、前后一致
　　- 注意用例的粒度和范围，防止用例过多设计繁杂，或用例过少单一用例覆盖过多功能单元
　　- 用例本身不可能满足所有场合的需求，所以不必拘泥于用例，也可根据实际需要运用其他辅助工具是系统易于理解
　　- 分清执行者及用例的各种关系及适用场景
文章源自玩技e族-https://www.playezu.com/194568.html