我的系统具有比图中显示的更多功能，但我正在尝试根据场景进行操作。
我目前的情况是图书管理员/管理员试图从数据库中删除图书记录，普通用户可以访问数据库但他们无法访问“删除图书记录”功能。
流程应该是这样的，用户登录系统，如果他/她正确输入了登录详细信息，将检查帐户的访问级别，并根据帐户类型授予不同级别的访问权限。在验证帐户及其访问级别后，将有几个功能模块可供选择，例如事务、搜索、数据库和报告模块。在用户选择数据库模块后，他们然后选择他们想要查看/修改的记录，例如成员记录和书籍记录。然后他们会在所有以表格形式记录的图书记录中选择要删除的图书记录，然后单击“删除”删除该图书记录，系统将显示确认消息以确保用户没有' t 不小心删除了他们无意删除的记录。
实际上，我对什么可以被视为“状态”感到非常困惑。我知道这是某种条件或情况，但我在网上找到的大多数示例都让我觉得这是一种行动。
下面的状态图是否正确交付？
叙述是关于行动的连续流动。我用占位符替换了一些文本来证明这一点：
用户{action}，如果 {conditions} (...)。在 {another action}之后会有 (...)。在 {choice} {action} 然后 {another choice}之后。然后 {action} 然后 {another action}，系统将{action}。在(...) 之后，{choice}但我试图结束场景，所以我把{action}放在它后面。
这种流可以很容易地用活动图建模。
您的困惑和问题来自这样一个事实：您尝试根据动作对状态图进行建模，试图描述与要执行的动作（例如Login account）或执行Account authenticated的动作（例如）相对应的状态，并且简单地描述从一个到另一个关于状态转换的箭头。你的方法是可以理解的。不幸的是，它会导致非常复杂的状态图，正如qwerty_so在评论中解释的那样，甚至不是有效的图。
如果你想继续这样做，你需要表达明确的状态并且不要与动作混淆（例如用户身份不明，用户身份验证，......），并保持状态转换的标签非常短。但更好的方法是独立于活动图来识别粒度较小的状态。问问自己，系统进入某个状态时应该做什么，系统处于该状态时应该做什么，以及离开该状态时应该做什么。如果不清楚，那么请重新考虑这是否真的是一个好的州候选人。此外，更多地根据发生的事件而不是执行的操作来考虑状态转换。
首先，你必须知道你想要实现什么。在我看来，您想概述应用程序的功能。然后，您决定哪种图表最适合此目标。用例图通常用于提供功能概述。活动图通常用于描述单个用例中的流程。
如果您想使用状态机图来概述应用程序的功能，您可能会考虑为每个“屏幕”（对话框、窗口、网页，无论您如何称呼它）设置一个状态。然后，状态 X 表示屏幕 X 具有焦点的应用程序的状态，即用户当前与屏幕 X 交互。从状态 X 到状态 Y 的转换表示导致屏幕 Y 出现的用户动作，而屏幕 X 要么消失，要么失去焦点。
例如，初始状态是“登录”。第二个状态是“主菜单”。从“登录”到“主菜单”的过渡有“Press OK [用户名和密码正确]”动作，表示用户按下OK按钮，系统验证用户名和密码。
对于非平凡的应用程序，这可能会导致非常复杂的状态转换图。在这种情况下，您可以将图表拆分为多个图表，或者改用用例图表。