miliuniverse.blogg.se

#Sequence diagram example for login registration#
#Sequence diagram example for login password#

UML is great! But it's the wrong tool for UI design.

Last but not least security experts would advise you never to tell that the user name is ok but password incorrect.I wonder if it would not make it much clearer, then, to have two separate (and simpler to read diagrams). Then I wonder if the user could not anyhow click on "Sign up" instead of starting entering the login information.I’d put the second alternate in a nested box in the else operand (i.e.Now, I think you are ready to continue with your modelling and your project. 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). Then it shows immediately the interaction between UI elements and classes behind the scene. Your revised diagram is much more understandable: first messages for the user now correspond to feedback made by the UI. Edit: your second diagram You're revised diagram I wonder if there would not be a nested alt block. Not fully clear how you want this scenario to work.

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).

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.In your case this is a minor issue, since we can easily find out that it should be the account database. ) shall cover the lifeline that should react first, as explained here. By the way, a minor issue in your diagram: The interaction constraint that guard operands in an alt fragment (e.g.But otherwise, it's quickly only wishful thinking that has nothing to do with UML semantics. If you have some clear messages that correspond to information content provided to or by the actor, the sequence diagram stays understandable. When you use actors in sequence diagram as explained here, then be at least careful with messages exchanged with the actor.

More generally, by the book, actors should in principle not appear in a sequence diagram, even if it's a common practice.

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.

This diagram is unfortunately ambiguous and misleading.

#Sequence diagram example for login password#

#Sequence diagram example for login registration#