Sequence diagram for sending requests to JSON API and for using an SMTP Server?

Question

I have developed a web application that sends HTTP requests to a JSON API and gets responses from it. It is also sending E-mails via an SMTP server to users. I am stuck on how to modelise these scenarios in my sequence diagrams.

Edit:

The sequence for logging in goes as the following:

1-The user inputs his login and password to the view

2-The view sends the inputted data to the controller

3-The controller calls a function located in the WebService class

4- The functions creates an instance of the login request model (The login request model is a class that has the same format as the JSON data that will be sent)

5- The function serializes the created instance to JSON and sends it via HTTP to the remote Web service

6- The functions reads the response stream and deserializes it into a new instance of the response class

7-The instance created then is sent back to the controller

8-The controller runs a test on the received instance to see if the user has provided correct credentials or not

9-Based on the test results, the controller redirects the user to either the landing page (in case he inputted the right credentials) or sends a message in the index page indicating that the credentials are wrong

In this case, what will be the actors in my sequence diagram and what should I put in it and what should I leave undescriped?

Answer 1

Your initial diagram is a good start.

I've annotated it here with english text in black (so taht everybody can benefit from it), the references of your numbered sequence list, and some changes in magenta. I've also added 3 circles to highlight some general remarks:

Remark 1: it's unclear for me if this first message is synchronous (plain arrow). Does your user class really wait for a return ? I think this could be asynchronous, and the final message that comes back would then not necessarily be an return message (dotted line).

Remark 2: the incoming message 4 on the request template/model is asynchronous. So I'd expect the answer being an asynchronous message as well (not dotted).

Remark 3: Here (and on several other occasions), you have an incoming "create" message. If you create a new object, you'd better start the lifeline there, to show the instantiation.

Remark: you can show alternative interactions (at the end of the sequence) less ambiguously by using an alt region.

Final remark: you worry about different kind of transmission (i.e. JSON vs. SMTP). The UML diagram doesn't show the format of the message. So if the flow is the same but only the protocol changes, you could just keep it (and eventually make an annotation to show that its JSON or SMTP). If you'd have different kind of interactions in the sequence, you could use an alt.