Uml 我的用例图是否过于复杂，活动图是否过于密集？

我正在做一个酒店预订服务问题的2个图表。我确实查过谷歌，几乎所有的图表例子似乎都很好地把演员联系起来了，但在我的例子中，我似乎无法做到这一点。同样对于活动图，我觉得它只适合部分问题，而不是所有问题

如果我的工作是正确的/至少在正确的道路上，在需要工作的地方或完全关闭的地方，我将非常感谢对我工作的任何反馈。。寻求帮助

问题:

新酒店需要一个网站，允许潜在客人通过指定房间类型（如单人房、双人房和预订日期）来预订房间。酒店有许多可用的房间类型，每种类型都有房间类型名称、客人数量和其他设施信息。酒店的每个房间都有一个唯一的房间号，并且是一种特定的类型

如果潜在客户过去已在网站注册，则可以检索他们以前存储的详细信息，例如联系电话、信用卡详细信息，以加快预订过程。如果潜在客户之前没有注册，他们必须在预订前创建一个新客户帐户

酒店的每个预订都分配了一个唯一的预订代码。在预订日期之前，客户可以使用网站编辑或取消预订。对预订的修改可以包括更改预订日期、每个房间的客人人数等。在预订过程中，客户可以打印他们的预订

当客人到达酒店时，接待员会使用预订号码查找预订以办理入住手续。在酒店住宿结束时，接待员会为客人办理退房手续。在此阶段，酒店系统通过信用卡支付系统进行支付，客人可以要求开具发票

每月报告由系统编制，可根据客户要求查看 酒店经理

为酒店制作用例和活动图

答：用例图

答：活动图

新用例图：

---

您正在混合参与者和系统。酒店是一个系统，显示为矩形

如果不假设系统的功能不同，则各类房间不属于UC diag

参数和状态不显示为用例。它们不是行动

至于标题中的问题，答案是否定的。只有几个UC图，没有一个图。没关系。活动图非常简单，甚至都在一条泳道中

定义所有代理后，您将能够使用泳道创建更复杂的活动图

编辑第二个用例图：

• 在这里，您试图设置操作的顺序。用例不是它的位置。只有谁和什么，而不是在哪里，何时，如何。您正试图将所有内容都放在用例图中。将其他问题推迟到以后的图表中。看看我的答案：，一个人犯了相反的错误——把所有的东西都放在序列图上
• 你能想到注册的事真是太好了。但是登录和注册是用例，应该在代理之间，而不是用例之间
• 您在这里混合了两个用例：一个是关于预订，另一个是关于实际到达/居住/离开。把他们分开
• 不要试图将结构信息放在这里。用例是从用户的角度来完成的，而不是从程序员的角度。现在不要试图决定内心的问题。您必须正确定义最常见的问题，仅此而已

我已经添加了用例图的一部分-仅保留

而且要注意，即使在参与者和用例的意义上，它也还没有满——您还必须拥有预订系统提供商的管理和簿记。（当然，如果系统不属于酒店）

---

关于我将酒店作为参与者的说法，我假设actor=“指定用户或与主体交互的任何其他系统扮演的角色”。本案的主题是网站预订系统。我理解错了吗？有些术语已经被接受了。参与者和系统一起被称为代理。代理是用例的连接者，参与者是人。系统可以由人组成，也可以由人来表示，但我们在分析的对话中将它们视为系统，这就足够了。但我可以想象这样一个用例，参与者可以是一只狗。或者机器人。但肯定是有个性的东西，那就是某人。系统是一些东西。那么在这种情况下，我能说酒店可以作为演员来经营吗？正如你提到的，我有几个UC图，而不是一个。我有没有办法把它们都集中在一起？