用例图在UML中的知识点总结

Posted 2021-04-17 51Testing软件测试网

更多精彩，请点击上方蓝字关注我们！

简介

　　用例图主要是从用户的角度出发对软件产品的功能及执行者进行描述的。

　　用例图是从需求分析到软件交付的第一步，图示化展示参与者与参与者之间、参与者与用例之间、用例与用例之间的关系，帮助开发人员更好的理解系统的功能。

　　用例图在使用UML的开发过程中非常重要，需求分析、任务分解、界面设计、类与接口的抽象、详细设计、配置管理、测试实施等阶段都是以用例图为重要支撑的。

用例图建模步骤

　　- 在需求分析过程中识别出参与者及系统边界

　　- 提取每位参与者期望的行为或者需要系统提供的功能作为用例

　　- 提炼出参与者的公共行为或者系统的公共功能以备其他用例调用、扩展或泛化

　　- 分解正常功能流程作为正常事件流，异常功能流程作为异常事件流

　　- 在用例图中对参与者、用例及它们之间的关系进行建模

用例图的元素

　　用例图中的元素有参与者、用例、及它们之间的关系。其中参与者/用例之间的关系主要有关联、泛化、包含、扩展。

　　参与者：系统外的一个实体，可以是任何人、任何事、软件系统或硬件系统

　　表示方式：参与者在UML中的标识方式

　　确定原则：确定什么样的人或事可以被当作参与者

　　- 系统开发完成后，由谁安装、启动、使用、维护或关闭系统

　　- 系统开发完成后，哪些人与该系统交互，如单/双向通信、获取数据或输入信息

　　- 系统开发完成后，哪些外部系统会与该系统关联

　　- 系统开发完成后，会有什么事触发、中断或恢复系统

　　参与者涉及的关系：关联（参见用例图的关系部分）

　　参与者注意事项

　　- 参与者对于系统而言是外部的、

　　- 参与者与系统交互可以帮助定义系统的边界

　　- 参与者在与系统交互是可以同时或不同时扮演多个角色

　　- 参与者必须有业务角度的简短描述

　　- 参与者可以有属性和可接受的条件

　　用例：是软件中的一个个功能单元，用于说明参与者是如何使用系统的。确定参与者之后，就可以根据参与者来确定系统的用例了。

　　表示方式：用例在UML中的标识方式

　　确定原则：确定什么样的功能可以被当作用例

　　- 参与者期望使用该系统完成什么工作，比如说增删改查信息，存储同步数据，业务流程等

　　- 外部条件发生变化时，参与者是否会将这些外部变化通知给该系统

　　- 系统内部出现变化时，系统是否会将这些内部变化通知给相关的参与者

　　- 系统正常运行的事件流及出现异常错误的事件流，以及定时运行的操作

　　- 系统内部管理维护，如升级、降级、配置、容灾、备份等运维操作

　　用例之间的关系：包含、扩展、泛化（参见用例图的关系部分）

　　用例规约：每个用例都应该包含以下属性。用例的可选属性包括前置条件和后置条件，具体含义参考用例图的主要属性部分

　　- 简要描述：该用例的作用或目的

　　- 事件流：表示该用例的所有场景，包括基本事件流和备选事件流

　　- 成功场景和失败场景：场景主要是由基本流和备选流组合而成的

　　用例的注意事项

　　- 用例一定是系统的功能，但系统的功能不一定是用例

　　- 用例名称常是“强动词”开头的动宾短语，直白明确

　　- 用例一定是由参与者发起的，不应该是自动启动的

　　- 用例设计时需要把握好粒度和范围

用例图的关系

　　用例图中参与者/用例之间的关系大致有四种：关联、泛化、包含、扩展

　　参与者与参与者之间的关系

　　参与者实质上也是类，参与者与参与者之间主要是泛化(继承)关系

　　- 泛化(Generalization)：使用空心三角直线标识，从子类参与者指向超类参与者

　　参与者与用例的关系

　　参与者与用例之间使用关联关系，表示该参与者代表的外部系统与系统内部功能之间的交互。

　　- 关联(Association): 使用实线箭头标识，从参与者指向用例

......

查看全文内容，点击阅读原文

上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。

更多精彩，点击下方“ 阅读原文”查看。