When defining an "Actor" you should know that definition
An Actor models a type of role played by an entity that interacts with
the subject (e.g., by exchanging signals and data), but which is
external to the subject (i.e., in the sense that an instance of an
actor is not a part of the instance of its corresponding subject).
Actors may represent roles played by human users, external hardware,
or other subjects. Note that an actor does not necessarily represent a
specific physical entity but merely a particular facet (i.e., "role")
of some entity that is relevant to the specification of its associated
use cases. Thus, a single physical instance may play the role of
several different actors and, conversely, a given actor may be played
by multiple different instances
In your system, we could say that the Actors are ( User, Web browser, Web server (Application, Content database) )
.
Our next step will be defining the "Call Messages" and "Return Messages" between our actors.
A message defines a particular communication between Lifelines of an
Interaction.
As per your events mentioned, we will try to break it down a little more to explain them better.
- User Loads Application.
- [User] ----"RequestResource()"---> [Web Browser]
- [Web Browser] -----"RequestAccessForUser()"---> [Web Server]
- [Web Server] ------"CheckUserExists()"-----> [Content Database]
- [Content Database] ---"Exists Return Message" ----> [Web Server]
- Keep returning the response to the user and loads your page on his browser.
Here you can find that there's a probability that user isn't registered, then there's something called "Alternative paths".
OF course you can minimize the steps by decreasing actors number but for learning and simplicity that will be a very good solution. Below are some examples and tutorials will definitely help.
Visual Paradigm introduction to write your first Sequence Diagram
Sequence Diagram Examples
Best Answer
To represent interactions in a more or less complex and GUI-rich applications I, too, often found myself interested in representing .NET events in sequence diagrams. To my view, there is no really descriptive way to effectively do it using standard means.
A formally justifiable way could be as follows: raising an event is basically nothing but calling a defined function in the target instance, the only difference is that you call it not directly, but via the system event message loop. So, behind the scenes, raising an event is identical to calling some HandleMessage("MyEvent", params object[] args) function in the system itself, the parameters being the name of the event and a list of optional arguments. I do not know what the exact name and signature are, but this does not really matter.
In the above figure, a Source instance issues an event MyEvent with a list of arguments that lands on the system receiver. The receiver finds the addressee (Target) and calls its corresponding method (Target.OnMyEvent()). To emphasize that this call is event-triggered, I introduce a stereotype called "Event".
This scheme may look somewhat clumsy, but, to me, it covers the case.