我的用例图太复杂，活动图太密集？答案

【问题标题】：Is my use case diagram too complicated and Activity diagram too dense?我的用例图太复杂，活动图太密集？
【发布时间】：2014-01-28 11:24:37
【问题描述】：

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

如果我的工作是正确的/至少在正确的路径上以及需要工作的地方或完全关闭，我将不胜感激。Tnks 寻求帮助。

问题：

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

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

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

当客人到达酒店时，接待员会使用预订号来查找预订并登记入住。在客人入住酒店结束时，接待员会为客人办理退房手续。正是在这个阶段，酒店系统通过信用卡支付系统收取他们的费用，客人可能会要求开具发票。

月度报告由系统准备，可根据要求查看酒店经理。

为酒店制作用例和活动图。

答案：活动图

【问题讨论】：

【解决方案1】：

您正在混合演员和系统。酒店是一个系统，将显示为一个矩形。

如果他们不假设系统的不同功能，那么各种房间不属于 UC 诊断。

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

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

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

编辑第二个用例图：

您在此处尝试设置操作的顺序。用例不是它的地方。只有谁和什么，而不是何地、何时、如何。您正在尝试将所有内容都放在用例图中。将其他问题推迟到以后的图表中。看看我的答案：https://stackoverflow.com/a/21408074/715269，一个人犯了相反的错误——把所有东西都放在序列图中。
很高兴您考虑注册。但是登录和注册是用例，应该在代理之间，而不是用例之间
您在这里混合了两种用例：一种是关于预订的，另一种是关于真正到达/居住/离开的。将它们分开。
不要试图把结构信息放在这里。用例是从用户的角度来完成的，而不是从程序员的角度。现在不要试图决定内心的问题。您必须正确定义最常见的问题，仅此而已。

我已经添加了用例图的部分 - 仅限预订。

请注意，即使从参与者和用例的意义上来说，它也不完整 - 您还必须拥有预订系统提供商的管理和簿记。（当然如果系统不属于酒店）

【讨论】：