2024年4月11日发(作者：amd的显卡都说不适合打游戏)
用例图
用例图(Use Case Diagram)是 由软件需求分析到最终实现的第一步，它描述人们如
何使用一个系统。用例视图显示谁是相关的用户、用户希望系统提供什么样的服务，以及
用户需要为系统提供的 服务，以便使系统的用户更容易理解这些元素的用途，也便于软
件开发人员最终实现这些元素。用例图在各种开发活动中被广泛的应用，但是它最常用来
描述系统及 子系统。
当用例视图在外部用户出现以前出现时，它捕获到系统、子系统或类的行为。它将系
统功能划分成对参与者（即系统的理想用户）有用的需求。而交互部分被称作用例。用例
使用系统与一个或者多个参与者之间的一系列消息来描述系统中的交互。
用例图包含六个元素，分别是：参与者(Actor)、用例(Use Case)、关联关系
(Association)、包含关系(Include)、扩展关系(Extend)以及泛化关系(Generalization)。
用例图可一个包含注释和约束，还可一个包含包，用于将模型中的元素组合成更大的
模块。有时，可以将用例的实例引入到图中。用例图模型如下所示，参与者用人形图标来
标识，用例用椭圆来表示，连线表示它们之间的关系。
一．参与者（Actor）
1． 参与者的概念
参与者是系统外部的一个实体，它以某种方式参与用例的执行过程。参与者通过向系
统输入或请求系统输入某些事件来触发系统的执行。参与着由参与用例时所担当的角色来
表示。在UML中，参与者用名字写在下面的人形图标表示。
每个参与者可以参与一个或多个用例。它通过交换信息与用例发生交互（因此也与用
例所在的系统或类发生了交互），而参与者的内部实现与用例是不相关的，可以用一组定
义其状态的属性充分的描述参与者。
参与者有三大类：系统用户、与所建造的系统交互的其它系统和一些可以运行的进
程。
第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每个系统中。命
名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。
第二类参与者是其它的系统。这类位于程序边界之外的系统也是参与者。
第三了参与者是一些可以运行的进程，如时间。当经过一定的时间触发系统中的某个
事件时，时间就成了参与者。
２．确定参与者
在获取用例前首先要确定系统的参与者，开发人员可以通过回答以下的问题来寻找系
统的参与者。
发布者：admin，转转请注明出处：http://www.yc00.com/num/1712842500a2132727.html
评论列表（0条）