相同的流程，根据视角不同的状态图
我想做一个状态图来表示用户登录。据我了解，可以从两个角度来完成：
对象：状态
- 用户：已登录，未登录（也许也已初始化和销毁）。
- 系统：等待登录、正在验证登录、错误、已登录。
这是否正确？另外，像这样的多个状态图真的有必要吗？
I want to do a state diagram to represent a user logging in. As far as I understand things, it could be done from two points of view:
Object: States
- User: Logged in, Not logged in (perhaps Initialized and Destroyed too).
- System: Waiting for login, Verifying login, Error, Logged in.
Does this appear correct? Also, are multiple state diagrams like this really necessary?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
“必要”取决于您想要记录的方面，但我会说不需要。
如果您处于规范阶段（用例阐述），我通常建议根本不要使用状态图；我发现活动更适合这个目的。在我看来，状态图更适合设计描述。
这是因为活动关注流程本身，因此从外部角度描述某些内容，而状态图描述内部流程，其中某些定义的实体在不同状态之间移动。
当你制作状态图时，你必须回答“有状态的东西是什么？”的问题。以及“每个状态对事物意味着什么？” （如果您愿意，可以将“事物”替换为“系统的一部分”。）
就您而言，我建议用户（严格来说，用户帐户）拥有状态，而不是系统。
从问题中尚不清楚场景是什么，但如果我们讨论的是典型的操作系统用户帐户，它可能应该具有“注销”、“登录”、“过期”和“锁定”等状态。
如果您确实还想对系统端进行建模，那么您可能应该将其分解为更小的部分，例如用户客户端（或终端，或其他）。根据上述内容，关键问题是“当用户登录时（整个）系统的行为是否有所不同？”想必事实并非如此。用户客户端（而不是整个系统）将具有您列出的状态。
但在其他条件相同的情况下，我想说描述登录/注销周期的状态图应该关注用户帐户。
"Necessary" depends on what aspect you are trying to document, but I would say no.
If you are in a specification phase (use case elaboration), I usually advise not to use state charts at all; I find that activities are better suited for this purpose. State charts, in my view, are better suited for design descriptions.
This is because activities focus on the flow itself and thus describe something from an external point of view, whereas state charts describe an internal flow in which some defined entity moves between different states.
When you do a state chart you must answer the questions "what is the thing that has a state?" and "what does each state mean to the thing?" (Replace 'thing' with 'part of the system' if you prefer.)
In your case, I would suggest that it is the user (strictly speaking, the user account) that has the state, not the system.
It's not clear from the question what the scenario is, but if we're talking about a typical OS user account, it should probably have states like Logged Out, Logged In, Expired and Locked.
If you do specifically want to model the system side as well, then you should probably break it down to a smaller part, such as a User Client (or Terminal, or whatever). In keeping with the above, the key question is "does the (whole) system behave differently when a user is logged in?" and presumably it doesn't. The User Client, rather than the whole system, would then have states you list.
But all else being equal, I would say that a state chart describing the login/logout cycle should focus on the user account.