I and two university colleagues of mine are designing a simple CMS software for a university exam using UML. Such software just needs to deal with sending an article, assigning an article for review, sending a review and scoring an article. Our solution expects a 3-tier client-server architecture, with tiny clients requesting services and a server responding to requests by interfacing with a DBMS (persistent data) and a SMTP server (e-mail notifications).
I'm at a point where I can't decide how to structure my client-side classes. I figured out a set of boundary classes representing single services and contain related methods (authentication, submit paper, review paper...), and a single control class which roles are requesting connection to the server and the creation of a new session, and it contains the methods to actually send messages to the server.
This is according to the single responsibility principle that states that any class should be responsible over a single functionality of the software: so, I have a class for signing up/logging in, one to submit an article, and so on, and then the control class that receives requests from other boundary classes and send messages to the server.
On the other hand, I was told by other people I asked that I could even get rid of my client-side controller class and give boundary classes methods to directly send request messages to the server. This still seems legit to me: boundary classes only send requests according to the particular service they were supposed to provide to the user.
Question is: is having a control class in my client application useful, redundant, or wrong at all? How can I improve my classes structure?