包括注册和登录的序列图 [英] Sequence diagram including Registration and Login

问题描述

我正在尝试构建一个序列图，表明用户可以:

• 如果详细信息正确，请登录到应用程序.如果详细信息正确，则将其重定向到主仪表板
• 如果详细信息不正确，则会将其重定向到注册页面，然后在该页面上检查其详细信息，以查看是否已在输入的电子邮件下注册了用户.如果尚未注册，则会创建一个用户并将其重定向到主仪表板
• 如果已经注册，则用户名或密码错误"；显示消息

我不确定这是否是显示注册和登录的正确或最佳方法，我觉得该图读取不正确.这是否很好地说明了情况?还是我应该添加更多内容.

初始图:

根据答案进行了修订:修订后的图表是否可以更好地说明这种情况?

使用嵌套alt进行了进一步修订

最终修订版

解决方案

不幸的是，此图是模棱两可的，并且具有误导性.

• 登录屏幕将类似于 Redirect to AppDashBoard 的消息发送给参与者.这是否意味着您的系统只是告诉用户他(她)应该去AppDashBoard?实际上，actor根本不会对消息做任何事情:是不是您的系统将显示另一个窗口或另一个页面，而不管用户在做什么?您必须避免这种情况.
• 从一般意义上讲，从书上来讲，即使是很常见的行为，原则上演员也不应出现在序列图中.当您在时序图中使用角色作为

  不要使用UML设计UI

  UML很棒！但这是用于UI设计的错误工具.这就像在键盘上用锤子敲打文本:像这样的非常简单的UI设计在UML中看起来非常复杂.

  设计用户旅程的全景图使用线框，情节提要或几种技术的组合和易于理解的用户流.这将促进与更多利益相关者的讨论，并允许更快地显示用户界面元素和参与者之间的交互.然后，在一个单独的步骤中，您可以在UML中设计所涉及的类之间的交互.您可能更喜欢将注意力集中在边界和控件之间较困难的交互以及较不明显的交互上)，而对于那些琐碎的交互则不要浪费太多时间.

  I am trying to build a sequence diagram where I show that a user can:

  • Log in to an application if their details are correct. If details are correct they are redirected to the main dashboard
  • if the details are incorrect they are redirected to the registration page where their details are then checked to see if a user is already registered under the entered email. If not already registered a user is created and they are redirected to main dashboard
  • if already registered then a "username or password incorrect" message is shown

  I am not sure if this is the correct or best way to show registration and login, I feel like the diagram is not reading correctly. Does this explain the scenario well? or is there more I should add to this.

  Initial diagram:

  Revised following the answer: Does this revised diagram explain the scenario better?

  Further revised with Nested alt

  FINAL Revision

  解决方案

  This diagram is unfortunately ambiguous and misleading.

  • Login screen sends a message like Redirect to AppDashBoard to the actor. Does this mean that your system just tells the user that he/she should go to AppDashBoard ? In fact, does the actor do anything with the message at all: isn't it your system that will display another windows or another page regardless of what the user is doing? You have to avoid this.
  • More generally, by the book, actors should in principle not appear in a sequence diagram, even if it's a common practice. When you use actors in sequence diagram as explained here, then be at least careful with messages exchanged with the actor. If you have some clear messages that correspond to information content provided to or by the actor, the sequence diagram stays understandable. But otherwise, it's quickly only wishful thinking that has nothing to do with UML semantics.
  • By the way, a minor issue in your diagram: The interaction constraint that guard operands in an alt fragment (e.g. [if user authenticated] ) shall cover the lifeline that should react first, as explained here. In your case this is a minor issue, since we can easily find out that it should be the account database.
  • Finally, if Registration and AppDashBoard are UI elements, it would be helpful to distinguish them from other elements that are not visible to the user. You may for example use a stereotype such as «Boundary», or even more concrete ones like «Dialogue window» or «Webpage» (you may freely define those in an ad-hoc profile).

  Not fully clear how you want this scenario to work. I wonder if there would not be a nested alt block.

  Edit: your second diagram

  You're revised diagram

  Your revised diagram is much more understandable: first messages for the user now correspond to feedback made by the UI. Then it shows immediately the interaction between UI elements and classes behind the scene. Finally, it also allows to check robustness (see the wikipedia link: database coordinates application logic behind the scene and it would in the BCE logic be a "controller", and controller should not speak to actors).

  Now, I think you are ready to continue with your modelling and your project.

  Some further suggestions

  • I’d put the second alternate in a nested box in the else operand (i.e. the dotted region) of the first one. This makes the relationship clearer.
  • Then I wonder if the user could not anyhow click on "Sign up" instead of starting entering the login information. I wonder if it would not make it much clearer, then, to have two separate (and simpler to read diagrams).
  • Last but not least security experts would advise you never to tell that the user name is ok but password incorrect.

  It would then look somewhat like this:

  Don't design UI with UML

  UML is great! But it's the wrong tool for UI design. It's like typeing text with a hammer on the keyboard: a very simple UI design like here looks terribly complicated in UML.

  Design the big picture of the user journey using wireframes, storyboards, or a combination of several techniques and easy-to-understand user flows. This will facilitate discussion with more stakeholders and allow to show much faster the interaction between user-interface elements and the actor. Then, in a separate step you can design in UML the interaction between classes involved. You may prefer to focus on the more difficult interactions and the less obvious ones between boundaries and controls) and not loose too much time for very trivial ones.

  这篇关于包括注册和登录的序列图的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！