0

In this sequence diagram I am trying to show:

  • Admin can login.
  • If login success -> redirect to admin dashboard
  • Once at admin dashboard, admin can click UI buttons to [ edit, view & delete ] a user

I am not sure if this diagram displays this correctly. Is it okay just to use Boundary "Admin Panel" to show different options or should each option be it's own boundary? e.g. boundary for edit user, delete user & view user.

Any feedback to improve this to make it clearer would be really appreciated

Thanks in advance. enter image description here

Krellex
  • 613
  • 2
  • 7
  • 20
  • 1
    your diagram is tooooooooooo long, I did not even try to read it, cut it in several. Do you know the interaction use (§ 17.7 from page 590 in [formal/2017-12-05](http://www.omg.org/spec/UML/2.5.1)) ? – bruno Feb 20 '21 at 13:22
  • Ah okay. Thanks for the response & link. I will have a look at the interaction page – Krellex Feb 20 '21 at 13:34
  • Interesting that despite a failing login in the top section the user can go on and delete other users. – qwerty_so Feb 20 '21 at 19:11
  • Thanks for pointing that out, I was unsure of how alt blocks worked – Krellex Feb 20 '21 at 19:37
  • One more reason to create multiple SD. One would be: Failed login. In many cases I see people creating trivial SDs. That's like a broken pencil: pointless. Use SD to bring light to _complicated_ collaborations. Also: you should accept Christophe's answer as correct (check tick mark). – qwerty_so Feb 21 '21 at 10:42

1 Answers1

2

This diagram shows too much and in a misleading way.

This diagram says that the Admin will login, then edit a user, the view a user, then delete a user. But I don’t think that you want to say that the Admin will always do all these actions and in this precise order. This is why this diagram is misleading.

Moreover, I don’t think that when doing the three in this order there would be anything different from the case it would be done in a different order. So there’s no need to show all the possibilities in a single diagram.

So, my advice:

  • cut this diagram in 4 different interactions: login, edit, view, and delete. All but the first one would have as precondition that user is logged in. In fact I make more assertive here what was already suggested for your registration scenario in your earlier question today
  • UML is neutral about what you can or should represent with the sequence diagram. Nevertheless, it is best kept for explaining interactions that are not obvious. Using it as a kind if visual programming for obvious interactions may be time-consuming modelling that tends to quickly be obsolete.
  • also, sequence diagrams are not the best way for modelling user interface. If you model your user interface with a wireframe storyboard (see links in the edit of my answer to your earlier question), you could then link the relevant sequence diagram to the relevant user interface design. The advantage is that you could verify with users that UI latch expectations based on the wireframe, but document for the developers what happens behind the scene, thus allowing to better understand how the short sequence contributed to the whole.
Christophe
  • 68,716
  • 7
  • 72
  • 138
  • Thanks for replying! I see what you're saying here. I am trying to show what the admin can do and that is: view, edit & delete a user. I was not sure what the best way to show this. As you say, it won't happen in this order and I really didn't know how to show this other than to just have the admin execute them. You mentioned 4 interactions. Each interaction after login (edit, view & delete) should be nested inside a successful login as you mentioned in the previous post? – Krellex Feb 20 '21 at 19:35
  • 2
    @ASH If you want to show what the admin can do, or better said what goals of admin the system should help to achieve, you’d better consider use cases. Use cases do not show actions, nor does it provide any sequencing of activities, but it helps to focus on what different kind if user needs. And then you can link your sequence diagrams (e.g view/edit/delete) to provide more details for the use cases view user/edit user/delete user. – Christophe Feb 20 '21 at 19:43
  • Oh I have made a use case diagram for my admin. My teacher for my module wanted us to also make a sequence diagram for the admin as well. I see what you're saying and I totally agree. I need to somehow display this inside a sequence diagram, I do not have much experience with sequence diagrams and don't really know how to go about displaying admins privileges besides just showing them being carried out – Krellex Feb 20 '21 at 21:25