Issues in your diagram
You use the ECB pattern with «entity»
, «control»
, «boundary»
. This approach is meant to map classes to a use-case:
«control»
would be a use-case, so a user goal. But CLientApplication
does not represent a goal at all: it represents a component.
«entity»
would be the domain objects (in general persistent). This would be ok for User
if you mean the user record/account, and is fine for Message
.
«boundary»
are the association between the use-case and external actors. ClientApplicationUI
is acceptable for this purpose. ConnectionManager
could perhaps fit this description if the server to which it connects would be external to your system but represent a secondary actor (i.e. if it's not just the server hardware or operating system, but if it is a server application that is relevant for the user).
Way forward with a class diagram
The way to add the Server
in the class diagram depends on its role. Is it:
- the external system? Then, there is no need for it: external means that it should not appear in the class-diagram at all. It's like the primary actor: we know it exists but it's external to the system and not a class of the system (see also this similar case in another question) .
- an internal object used by
ConnectionManager
for keeping track of server address, state, etc... ? Then add a Server
class associated to the connection manager. But it's not really an «entity», nor a «boundary». It's a very technical class needed for the implementation.
- a proxy for the server, i.e. a kind of representative of the external server that channels all the dialogue with the server ? Then
Server
would be a boundary class. But what would be the role of the connection manager then ? Connection manager would then act as a «control».
Select the option above that suits best your case. All the suggestions made are correct from point of view of the robustness matrix. This being said, I'm not sure that the ECB classification is helpful in your case. It raises more question and creates more ambiguity than necessary.
However, if you have to be fully compliant with the UML specs, you'd better leave them out (both the primary actor and the server).
Alternatives
I wonder if a component diagram could not better represent what you try to show here. In this case you could have two interconnected main components: ClientApplication
and ServerApplication
: The server would stay a black box component (since you focus on the client). The client would be composed more or less of your current classes. Components are classifiers of the system under consideration, so you can use them in sequence diagrams exactly as any other classifier.