从 class 图制作用例图的困惑
Confusion in making use case diagram from class diagram
我正在尝试借助我的 class 图制作一个用例图，但问题是我在这里感到困惑，我应该采取什么作为演员，会发生什么，我应该采取什么属性在哪里使用 <<extend>> ？
请帮忙。提前谢谢你。
您不能从 class 设计创建用例。只有相反的方式。形式服从功能，而不是相反。
您的 class 图表明您还不熟悉 class 建模。您的 classes Book Ticket 和 Make Payment 听起来像是用例而不是正确的 classes。 class 是数据和处理这些数据的功能的容器，而用例是参与者在系统的帮助下执行的一项工作。
为您提供所需的帮助对于这个平台来说可能范围太广了。研究有关 UML 建模的介绍性文本，以了解哪种类型的模型可以表达什么。并且不要觉得有义务使用该语言提供的所有元素。有很多用例模型不需要包含和扩展关系。
正如 Thomas 所指出的，没有从 class 设计到用例的算法方法。事实上，对于给定的 class 图，甚至根本不认为存在用例（例如，如果 classes 仅表示业务对象之间的关系，没有参与者）。
但是，从人的角度分析你的具体图表，你可以很好地推断出一个class图表：
1) 确定候选演员
参与者指定由用户或与主体交互的任何其他系统扮演的角色。您图表中的候选对象是：visitor、admin 和 registered user
class和Movie、Book tickets、Make payment显然不代表一个用户的角色。
2) 确定候选用例
用例定义系统和参与者之间的交互以实现某些目标。因此，让我们集思广益，找出所有看起来像交互的东西：
非常明确的候选用例：Book tickets（class和Registered user的方法），Make payment（class和方法Registered user)
不太明确的候选用例或交互：View movie（Registered user的关系和方法），update movie（关系），Add movie record（ method of admin), Update movie record (admin的方法), delete movie record (admin的方法), Confirm registration of visitor (从关系推断), '注册(method of a user),取消票(and method of注册用户),登录(method of注册用户),注销(method of注册用户),更新可用座位(method of订票),confirm transaction（方法），refund money of cancelled ticket（方法）
Implicit/inferred 用例或交互：create and maintain admin、create a visitor、register and maintain a registered user account，还有什么？
3）整理用例
在确定的所有潜在用例和交互中，并非所有都应获得用例状态。然后，您必须找到哪些是用例，哪些只是同一用例的交互部分。例如：
update movie catalog 将由 update movie、Add movie record、Update movie record、delete movie record.Get registered 和 Confirm registration of visitor 显然是同一用例的一部分，因为目标是相同的：注册用户。 - ...
我让你作为练习来解决其余的问题。
4) 评价演员
在确定有意义的用例后，您可能想要审查您的候选参与者：
一些候选演员可能看起来实际上只是与用户无关的对象（这里不是这种情况，但它可能是，例如，如果你有一个电影制作人，这只是与电影相关的信息，而不是系统用户的信息）。
为您已确定的重要用例确定明显缺失的参与者。举个例子，我一开始以为是互联网电影业务。但是方法 Update Seats 很明显我们在谈论一个真正的剧院。那么谁会从用户那里获得付款、分发机票、偿还与系统相关的费用呢？如果只是在线预订系统，我们没问题。如果收银台操作员也将使用该系统，那么我们应该添加此参与者。
找出候选演员之间的关系。注册用户首先是访客。我们是否应该在图中同时表示它们？
5) 画出你的用例图
现在您拥有了所有元素，可以制作用例图了。但是您仍然必须决定要表示的详细程度。这里有一个建议：
我正在尝试借助我的 class 图制作一个用例图，但问题是我在这里感到困惑，我应该采取什么作为演员，会发生什么，我应该采取什么属性在哪里使用 <<extend>> ？
请帮忙。提前谢谢你。
您不能从 class 设计创建用例。只有相反的方式。形式服从功能，而不是相反。
您的 class 图表明您还不熟悉 class 建模。您的 classes Book Ticket 和 Make Payment 听起来像是用例而不是正确的 classes。 class 是数据和处理这些数据的功能的容器，而用例是参与者在系统的帮助下执行的一项工作。
为您提供所需的帮助对于这个平台来说可能范围太广了。研究有关 UML 建模的介绍性文本，以了解哪种类型的模型可以表达什么。并且不要觉得有义务使用该语言提供的所有元素。有很多用例模型不需要包含和扩展关系。
正如 Thomas 所指出的，没有从 class 设计到用例的算法方法。事实上，对于给定的 class 图，甚至根本不认为存在用例（例如，如果 classes 仅表示业务对象之间的关系，没有参与者）。
但是，从人的角度分析你的具体图表，你可以很好地推断出一个class图表：
1) 确定候选演员
参与者指定由用户或与主体交互的任何其他系统扮演的角色。您图表中的候选对象是：visitor、admin 和 registered user
class和Movie、Book tickets、Make payment显然不代表一个用户的角色。
2) 确定候选用例
用例定义系统和参与者之间的交互以实现某些目标。因此，让我们集思广益，找出所有看起来像交互的东西：
非常明确的候选用例：
Book tickets（class和Registered user的方法），Make payment（class和方法Registered user)不太明确的候选用例或交互：
View movie（Registered user的关系和方法），update movie（关系），Add movie record（ method of admin),Update movie record(admin的方法),delete movie record(admin的方法),Confirm registration of visitor(从关系推断), '注册(method of a user),取消票(and method of注册用户),登录(method of注册用户),注销(method of注册用户),更新可用座位(method of订票),confirm transaction（方法），refund money of cancelled ticket（方法）Implicit/inferred 用例或交互：
create and maintain admin、create a visitor、register and maintain a registered user account，还有什么？
3）整理用例
在确定的所有潜在用例和交互中，并非所有都应获得用例状态。然后，您必须找到哪些是用例，哪些只是同一用例的交互部分。例如：
update movie catalog将由update movie、Add movie record、Update movie record、delete movie record. 组成
Get registered和Confirm registration of visitor显然是同一用例的一部分，因为目标是相同的：注册用户。- ... 我让你作为练习来解决其余的问题。
4) 评价演员
在确定有意义的用例后，您可能想要审查您的候选参与者：
一些候选演员可能看起来实际上只是与用户无关的对象（这里不是这种情况，但它可能是，例如，如果你有一个电影制作人，这只是与电影相关的信息，而不是系统用户的信息）。
为您已确定的重要用例确定明显缺失的参与者。举个例子，我一开始以为是互联网电影业务。但是方法
Update Seats很明显我们在谈论一个真正的剧院。那么谁会从用户那里获得付款、分发机票、偿还与系统相关的费用呢？如果只是在线预订系统，我们没问题。如果收银台操作员也将使用该系统，那么我们应该添加此参与者。找出候选演员之间的关系。注册用户首先是访客。我们是否应该在图中同时表示它们？
5) 画出你的用例图
现在您拥有了所有元素，可以制作用例图了。但是您仍然必须决定要表示的详细程度。这里有一个建议：