应用错误收集

您无法从类设计中创建用例。只有相反的方式。形式遵循功能，反之亦然。

您的类图表明您还不熟悉类建模。您的班级Book Ticket和Make Payment听起来像是用例而不是正确的类。类是处理这些数据的数据和功能的容器，而用例是演员在系统帮助下执行的一项工作。

为此平台提供所需的帮助可能过于宽泛。研究UML建模的入门文本，以了解哪种类型的模型可以表达什么。并且不要觉得有必要使用语言提供的所有元素。有很多用例模型不需要包含和扩展关系。

正如托马斯指出的那样，没有算法从类设计到用例。实际上，对于给定的类图，它甚至都没有被授予根本就存在用例（例如，如果类只表示业务对象和没有actor之间的关系）。

但是，通过从人的角度分析您的特定图表，您可以很好地推断出类图：

1）确定候选人

演员指定用户或与主题交互的任何其他系统所扮演的角色。您的图表中的候选人是：visitor，admin和registered user

类Movie，Book tickets，Make payment显然不代表用户的角色。

2）确定候选用例

用例定义系统和参与者的交互以实现某个目标。所以，让我们集思广益，找到看起来像互动的一切：

非常明确的候选用例：Book tickets（Registered user的类和方法），Make payment（Registered user的类和方法）
< / LI>
不太明确的候选用例或互动：View movie（Registered user的关系和方法），update movie（关系），Add movie record（管理方法），Update movie record（管理员方法），delete movie record（管理员方法），Confirm registration of visitor（根据关系推断），＆＃39;获取注册(method of a user),取消机票{{1注册用户(and method of登录),注册用户(method of退出),注册用户(method of更新可用席位),预订门票），{{1 （方法），(method of（方法）
隐式/推断用例或互动：confirm transaction，refund money of cancelled ticket，create and maintain admin，还有其他什么？

3）整理用例

在确定的所有潜在用例和交互中，并非所有用户都应获得用例状态。然后，您必须找到哪些用例，哪些只是相同用例的交互部分。例如：

create a visitor将由register and maintain a registered user account，update movie catalog，update movie，Add movie record组成。
Update movie record和delete movie record显然属于同一个用例，因为目标是相同的：注册用户。
... 我让你作为一个执行者解决剩下的问题。

4）审核演员

在确定了有意义的用例之后，您可能想要审核您的候选参与者：

有些候选演员可能看起来实际上只是与用户无关的对象（在这里并非如此，但例如，如果你有一部电影，它可能是制作人，这只是与电影有关的信息，但不是系统的用户。
确定您已识别的重要用例明显缺少的参与者。例如，我首先认为这是一个互联网电影业务。但是方法Get registered显然表明我们正在谈论一个真实的剧院。那么谁将从用户那里获得付款，分发机票，偿还与系统有关的款项？如果它只是在线预订系统，我们没事。如果cahs桌面操作员也应该使用该系统，那么我们应该添加这个actor。
找出候选人之间的关系。注册用户首先是访客。我们应该在图表中代表它们吗？

5）绘制用例图

现在您拥有了所有元素，您可以制作用例图。但您仍需要决定要表示的详细程度。这是一个建议：