Avaliao Tcnica Linguagem C++

Desenvolvimento de um Chat de Comunicao

Pr-requisitos
Para o desenvolvimento de um projeto de chat, o candidato dever instalar e configurar as seguintes
ferramentas e bibliotecas em ambiente Windows (7,8 ou 10):

IDE Qt Creator 5.6.0 for Windows 32 bits (MinGW 4.9.2), que pode ser baixado atravs do
link: http://download.qt.io/official_releases/qt/5.6/5.6.0/qt-opensource-windows-x86-mingw4925.6.0.exe.

Biblioteca Boost 1.60.0, que pode ser baixado atravs do link:

https://sourceforge.net/projects/boost/files/boost/1.60.0/.

Configurao
A IDE Qt Creator ser utilizada como ambiente de desenvolvimento para a linguagem C++. A verso
supracitada j possui o compilador MinGW (verso minimalista do GCC para Windows) integrada.
J a biblioteca Boost ser utilizada com o intuito de abstrair a utilizao de mtodos e funes que
utilizam a API do sistema operacional (por exemplo, sockets de conexo, threads, sees crticas,
etc.).
Para a instalao e configurao da IDE Qt Creator, o candidato poder se basear na documentao
online da ferramenta no site: http://www.qt.io/ide/.
Para a configurao e integrao da biblioteca Boost IDE Qt Creator, o candidato poder se basear
na documentao online da biblioteca no site: http://www.boost.org/.
Ademais, qualquer frum de internet pode ser utilizado como referncia de ajuda para a realizao
das configuraes.

Projeto
O candidato dever desenvolver um aplicativo servidor e um aplicativo cliente com a finalidade de
simular um sistema de chat utilizando o modelo cliente-servidor.
Sob esta perspectiva um aplicativo servidor poder receber conexo de vrios aplicativos clientes
bem como poder desconectar qualquer aplicativo cliente de seu pool de conexes quando bem
entender. Alm disso, quando um aplicativo cliente realizar conexo, ou desconexo, o aplicativo
servidor dever salvar, em arquivo, tais eventos.
Cada cliente ser identificado pelo nickname, portanto, quando um aplicativo cliente realizar a
conexo junto ao aplicativo servidor, ele dever enviar um nickname aps a conexo. Caso o
nickname j esteja sendo utilizado, o servidor dever notificar o aplicativo cliente e, em seguida,
desconect-lo. Do contrrio, o servidor dever enviar um broadcast para os demais clientes
conectados avisando que um novo cliente est conectado e enviar uma lista de clientes conectados
para o cliente que acabou de realizar conexo. Vale ressaltar que um aplicativo cliente no pode
receber notificao de que ele mesmo se conectou ao servidor.
De forma anloga, sempre que um cliente se desconectar do servidor, este dever enviar um
broadcast para os demais clientes conectados avisando que o referido cliente saiu da lista de clientes
conectados.
Uma vez que esteja conectado, o cliente poder escolher, a partir da lista de clientes conectados,
para qual nickname gostaria de enviar uma mensagem. A forma como isso estar visvel no
aplicativo cliente ficar sob o critrio do candidato, podendo ser feito como achar melhor.

Especificaes Tcnicas
Abaixo seguem as
aplicativos servidor
instanci-las como
para comunicao
candidato.

especificaes que o candidato dever considerar para o desenvolvimento dos

e cliente. Ao ser mencionada a criao de classes, entenda que ser necessrio
objetos em tempo de execuo. Ademais, o formato das mensagens utilizadas
entre os clientes que estaro conectados ao servidor, ficar a critrio do

Aplicativo Cliente:
Para a realizao de conexo junto ao aplicativo servidor, o aplicativo cliente dever criar uma classe
que represente a conexo. Esta classe ser responsvel por alocar e desalocar um socket nos
eventos de conexo e desconexo, respectivamente, bem como escutar as respostas vindas do
servidor em um novo fluxo paralelo. Sempre que houver um evento de conexo e desconexo, o
cliente dever emitir um aviso ao usurio do aplicativo cliente, utilizando a classe de conexo, que
poder ser desenvolvida a critrio do candidato. Antes de enviar uma mensagem, o cliente deve se
certificar de que o socket esteja realmente conectado e caso contrrio emitir um alerta ao usurio do
aplicativo.
Aplicativo Servidor:
Para o gerenciamento de conexes vindas dos aplicativos clientes, o aplicativo servidor dever criar
uma classe para representar o gerenciamento de conexes. Para isso a referida classe dever
escutar novas requisies de conexo vinda dos clientes em um novo fluxo paralelo.
Uma vez que uma requisio de conexo seja recebida e seu nickname seja autenticado, uma nova
task de socket dever ser criada, alocada dinamicamente em memria e armazenada na classe de
gerenciamento de conexes atravs do uso de dicionrio de dados onde o identificador da conexo
ser o nickname enviado pelo cliente. Alm disso, a classe gerenciadora de conexes dever
notificar as demais tasks acerca da nova task criada e autenticada.
A comunicao entre cada task de socket e o gerenciador de conexes dever acontecer sob o
modelo Publish/Subscribe, no qual cada task ir ler a mensagem chegada ao socket e inser-la em
uma fila nica protegida (Publish). O servio do gerenciador de conexes, por sua vez, dever
consumir as mensagens postadas na fila e despachar aos respectivos destinos (Subscribe).
Por fim dever ser criada uma classe responsvel por gravar em disco as informaes de conexo,
desconexo e envios de mensagens ocorridos no servidor. Esta classe, doravante chamada de
classe de log, dever possuir uma fila de acesso protegido e rodar em mais um novo fluxo paralelo
que ficar responsvel por consumir as mensagens da fila e persisti-las em disco. Portanto, sempre
que um evento de conexo, desconexo e envios de mensagens ocorrer no servidor, a classe de log
dever ser acionada.
Lembre-se que uma fila de acesso protegido no pode ser acessada (seja para produo ou
consumao) por mais de um recurso simultaneamente. Portanto um mecanismo de excluso mtua
dever ser utilizado.