Orientações básicas na elaboração de um diagrama de classes

Curso completo: Curso completo de UML

Em programação, um diagrama de classes é uma representação da estrutura e relações das classes que servem de modelo para objetos. Podemos afirmar de maneira mais simples que seria um conjunto de objetos com as mesmas características, assim saberemos identificar objetos e agrupá-los, de forma a encontrar suas respectivas classes. Na Unified Modeling Language (UML) em diagrama de classe, uma classe é representada por um retângulo com três divisões, são elas: O nome da classe, seus atributos e por fim os métodos. Vejam na Figura 1 sua representação.

Por que é tão importante encontramos as classes para o desenvolvimento de um sistema? É simples, pois cada classe do diagrama representa uma tabela do banco de dados, por esse motivo é tão importante encontrarmos. Observe também que para identificarmos uma classe, precisamos antes identificar seus objetos com características semelhantes.

Importante: Eu sobrevivo sem UML?

Ao analisarmos um cenário, poderemos identificar inúmeros objetos, contudo nem todo objeto será útil para nosso diagrama de classe, essa classificação dos objetos que usaremos é chamado de Abstração. Abstração é a forma de concentrarmos apenas nos aspectos essenciais do nosso cenário.

Para o desenvolvimento do nosso diagrama de classe, precisaremos de um cenário qualquer onde realizaremos um passo a passo até abstrairmos todas as classes, a partir deste ponto, poderemos efetuar as ligações e cardinalidade.

Desafios de quem trabalha com desenvolvimento

Você trabalha para uma empresa de desenvolvimento como Analista de Sistemas. O responsável pelo setor que você trabalha, em uma reunião, distribuiu tarefas para cada membro da equipe. Sua tarefa foi desenvolver um diagrama de classe para que seja iniciado o desenvolvimento de um novo software.

A empresa que nos contratou, deseja adquirir o certificado ISO 9001 em qualidade, entretanto uma das normas repassadas foi que, deve ser obrigatório controlar os pedidos de suporte/serviço que são feitos pelos clientes.

O ramo da empresa é Service Desk [1] o fluxo do processo segue abaixo:

• O cliente entra em contato com a central através do telefone;
• Um atendente tem um prazo curto para registrar esta solicitação, informando os dados do cliente, o que foi solicitado, o nível de urgência, o grupo de atendimento, o técnico, um ou mais equipamentos envolvidos na manutenção. Anotar toda a interação realizada no equipamento, como por exemplo: Se ele conectar remotamente ao equipamento, deve informar em um histórico e suponhamos que três segundos depois ele reinicie o equipamento, deverá informar no histórico também. Resumindo: Toda interação deve ser anotada no registro com data e hora.
• Caso ele consiga resolver o que foi solicitado, o técnico do Service Desk salvará o registro com a situação de “Resolvido” encerrando o caso, contudo deverá em um local específico do registro definir como ele resolveu o caso, informando que se tratava de um Incidente [2], Problema [3] ou Solicitação [4].
• O registro deve ser categorizado, escolhendo dentre três classificações: Categoria >> SubCategoria >> Item da categoria, onde a categoria é uma lista de tipo de serviço, como por exemplo: Se foi Hardware ou Software. A SubCategoria está relacionada com a categoria, pois dependendo do que foi escolhido na primeira lista será mostrada na segunda que será uma SubCategoria, como por exemplo: No caso da escolha de Hardware, seria informado na subcategoria algum tipo de peça do equipamento que o técnico interagiu, tipo DVD/R, no caso de Categoria ser Software a subcategoria deveria ser qual software, tipo: Word, Excel e etc...E no item da categoria deveria ser escolhido o que foi realizado pelo técnico, no caso de Hardware >> DVD/R, poderia ser SUBSTITUÍDO, LIMPADO..etc.. No caso de Software >> Word >> INSTALADO, DESINSTALADO etc...

Caso o técnico do Service Desk não consiga resolver no seu prazo que será o mais curto, deverá enviar o registro para outro grupo de atendimento onde existirão outros técnicos que poderão ir até o equipamento fisicamente para resolver o problema com um prazo mais extenso. Um grupo é composto por vários técnicos, no registro deve constar o grupo que atendeu e o técnico, pois cada registro conta como receita em reais para o grupo sendo apurado ao efetuar fechamento mensal. O pagamento para os grupos de atendimento é feito por quantidade de registros atendidos no prazo estipulado.

Se mesmo o grupo de atendimento físico tenta entrar em contato com o cliente, mas não o obtiver sucesso, o técnico poderá deixar o registro agendado, para realizar esta tarefa deve ser informado no registro à data e hora que será retornado o atendimento do chamado e definir a situação do registro para “Pendente pelo cliente”, definir também a data e hora para o próximo contato. Esta situação de pendência significa que o técnico não está atendendo por culpa do cliente e o tempo em que o registro fica nesta situação será debitado ao final do apuramento, a fim de beneficiar o grupo que o atende, pois cada grupo tem um tempo para atender os registros e se ultrapassar este prazo recebe multa em cima do valor do chamado.

Ao final caso o pedido tenha sido designado para outro grupo, ou esteja em andamento, pendente, cancelado ou resolvido, deve-se informar em um campo específico o que foi feito neste registro resumidamente. Se a situação do registro estiver definida como “Resolvido”, uma pesquisa de satisfação deverá ser enviada para o solicitante.

Identificar os objetos Tangíveis

Para identificarmos um objeto, precisamos antes entender como vê-los, para isso, basta ter como regra que: O objeto é algo tangível, que podemos percebê-lo a nossa frente, sendo possível encontrá-lo no mundo real ou virtual. Exemplos de objetos que podemos perceber ao ir a uma lanchonete: Mesa, Cadeira, Atendente, Lanche, Bebida etc.

Vamos tentar encontrar os objetos do nosso cenário, observe o primeiro item abaixo:

O cliente entra em contato com a central através do telefone;

Nesta frase acima, podemos identificar como objetos:

• Cliente
• Telefone

Cliente é considerado um objeto, pois é tangível e existem vários outros iguais a ele com as mesmas características, assim como o telefone.

No segundo item do cenário identificamos:

• Atendente
• Solicitação
• Grupo
• Técnico
• Equipamento
• Histórico

O único item acima que gera dúvida se é ou não um objeto, seria histórico, pois não é normal vermos este objeto, entretanto ele existe, veja o exemplo deste objeto no mundo real: Na escola existe o histórico escolar ou na clínica existe histórico médico etc.

No terceiro item do cenário identificamos:

• Categoria
• SubCategoria
• Item da categoria

Observe que estes objetos acima são difíceis de identificarmos no mundo real, mas preste atenção no cenário de uma locadora de DVD veja que as placas com o gênero dos filmes são categorias, aquelas placas são objetos tangíveis representando categorias que já seria sua classe mãe.

Os itens quatro e cinco do cenário estão apenas explicando o processo, não identificamos nenhum objeto novo.

No sexto e último item do cenário identificamos os seguintes objetos:

• Pedido
• Pesquisa satisfação

Identificar os objetos por seus atributos

Após identificarmos os objetos que estavam visíveis no cenário, agora teremos que encontrá-los através de seus atributos, onde os atributos são características do objeto, suponhamos que no cenário acima, foi falado sobre algum objeto, contudo não foi pronunciado seu nome, dificultando assim sua localização. Para encontrarmos teremos que identificar atributos ou características, como por exemplo: se no cenário dado acima, tivéssemos o atributo CPF, poderíamos identificar que esta característica pertence ao cliente, identificando assim o objeto Cliente sem que seu nome houvesse sido pronunciado no cenário.

Você deve repassar todo cenário novamente em busca destas características sem objetos. A seguir temos alguns identificados:

• Data
• Hora
• Situação
• Tipo de Serviço
• Prazo

Observe que os atributos Data, Hora, Situação, Tipo de Serviço e Prazo são referente ao pedido, sendo assim, para identificarmos novas classes a partir desses atributos, teremos que realizar a seguinte pergunta para cada um deles: “Eu preciso uma lista de: Atributo?”, onde no lugar de Atributo você substitui por atributos acima. Veja os testes abaixo:

• Eu preciso uma lista de Data? = Não
• Eu preciso uma lista de Hora? = Não
• Eu preciso uma lista de Situação? = Sim
• Eu preciso de uma lista de Tipo de Serviço? = Sim
• Eu preciso uma lista de Prazos? = Sim

As perguntas com resposta Sim, serão novas classes, segue abaixo as novas classes encontradas:

• Situações
• Tipo de Serviços
• Prazos

Lista completa com todos os objetos encontrados

Listaremos abaixo para facilitar nossa visualização, todos os objetos encontrados após nossa abstração:

• Cliente
• Telefone
• Atendente
• Solicitação
• Grupo
• Técnico
• Equipamento
• Histórico
• Categoria
• SubCategoria
• Item da categoria
• Pedido
• Pesquisa satisfação
• Situações
• Tipo de Serviços
• Prazos

Agrupar os objetos por semelhança

Nosso próximo passo é agrupar todos os objetos encontrados por características semelhantes, como por exemplo: Mesa e Cadeira têm as mesmas características, sendo classificadas como Móveis. Assim devemos trabalhar os itens acima:

• Cliente, Atendente e Técnico = Pessoas
• Solicitação, Histórico, Pedido e Pesquisa de Satisfação = Documentos
• Telefone = Equipamentos

Veja que alguns dos objetos acima não foram classificados, devido a não necessidade de tal processo, pois já está em sua classificação correta, devemos apenas usar o plural, pois normalmente uma classe está no plural devido sua origem em agrupas vários objetos.

Eliminar classes desnecessárias ou repetidas

Observe no item anterior que muitas classes são do mesmo gênero, fazendo com que esteja repetida no diagrama e se uma classe se repete no banco de dados será uma tabela criada sem propósito nenhum.

Para eliminar, vejamos primeiro as classes que agrupamos por semelhança:

Observe que Pedido e Solicitação no cenário fez referência a uma mesa coisa, assim podem então eliminar uma das duas, eu eliminei a solicitação.

Veja que Telefone é um item de equipamentos, sendo assim podemos também eliminá-la:

Abaixo a nova lista de classes:

• Pessoas
• Cliente
• Atendente
• Grupo
• Técnico
• Equipamento
• Histórico
• Categoria
• SubCategoria
• Item da categoria
• Pedido
• Pesquisa satisfação
• Situações
• Tipo de Serviços
• Prazos

Montando o Diagrama de Classe

Para iniciarmos os primeiros passos de nosso diagrama de classe, desenhe em uma folha de papel um retângulo com três divisões para cada classe.

Veja abaixo na Figura 2, como deve ficar:

Realizando as primeiras ligações

Para efetuarmos a primeira ligação, faremos com os objetos que agrupamos por características semelhantes, como por exemplo: Clientes, Atendentes e Técnicos se relacionam com pessoas, segue abaixo as ligações:

Efetuando as ligações entre as classes

Este ponto é trabalho, pois devemos testar classe por classe em busca de ligações. Vejamos a seguir como realizar esta tarefa.

Sabemos que o cliente entra em contato com o atendente que gera um pedido. Com esta informação observamos que um pedido foi gerado da interação entre cliente e atendente, onde um cliente pode solicitar vários pedidos para um atendente e um atendente atende a vários clientes. Sua cardinalidade será N para N, onde N quer dizer muitos, sendo: Muitos para Muitos, quando ocorre esse tipo de cardinalidade nasce uma nova tabela ou classe, entre esses dois foi a classe pedidos, que já havíamos identificado antes. O importante sobre a N para N é que a classe que nasceu recebe os códigos da classe que o fez relação, ficando a classe “Pedido” com o código do cliente e o código da atendente.

Sabemos também que esse pedido será repassado para um técnico que o atenderá, sendo assim um técnico pode atender a vários pedidos e um pedido pode ser atendido por um técnico, sendo representado por 1-N, lembrando que a classe que recebe o N herda o campo chave da outra classe como chave estrangeira, sendo assim ficará a tabela de pedidos com mais um campo chamado: código do técnico.

Faça o processo para todas as classes, use sempre a pergunta dessa forma:

• Um “Nome de um objeto da classe” pode “nome da ligação (verbo)” um ou vários “nome da classe”
• Como ficaria entre Pedidos e situação:
• Um pedido pode ter uma ou várias situações?

Resposta: Várias, pois ao abrir está em andamento, em outro ponto do tempo pode ficar pendente e ser concluída ao final do serviço.

Diagrama de Classe Completo

Cenário para exercitarmos

Você trabalha para uma empresa corporativa, seu cargo é Analista de Sistemas. O responsável pelo setor Ativos [5] lhe enviou um e-mail solicitando o desenvolvimento de um software para resolver um problema que o setor tem constantemente enfrentado com as auditorias internas, esta medida é de suma importância e o desenvolvimento deve ser realizado o mais breve possível antes que auditoria externa faça a próxima visita. Sua tarefa foi desenvolver um diagrama de classe para que seja iniciado o desenvolvimento deste novo software.

Quando um equipamento é instalado ou movido, seu histórico de movimentação deve ser registrado e em um software central, também deve ser possível saber exatamente sua localização.

A localização do equipamento é dividida por “cidade, imóvel, andar e sala”, por exemplo: Suponhamos que a empresa tenha filiais em cidades distintas sendo que em cada cidade existem outros imóveis desta mesma filial, sendo estes imóveis divididos por andares e cada andar pode ter várias salas separadas.

No cadastro do Ativo deve ser informada esta localização detalhadamente, a ponto do auditor ao verificá-lo saiba exatamente a localização do equipamento.

Quem envia as solicitações de movimentação são os técnicos da TIC, tendo em vista que são eles que fazem esta instalação ou movimentação do Ativo. Um usuário que não seja da TIC, é proibido de tomar esta ação. Ao enviar a solicitação ele deve informar a etiqueta do ativo e a localização de destino para o setor de Ativos, assim através desta solicitação que ficará com situação de pendente até que seja movida pelo funcionário do setor de Ativos é possível alterar o cadastro do Ativo para a nova localização.

O funcionário do setor de Ativo deve de posse da movimentação enviada para mover o ativo, acessar o cadastro do ativo e alterar sua localização de acordo com o solicitado e também alterar a situação da solicitação do técnico da TIC para a nova situação: MOVIDA.

O histórico destas solicitações deve ser classificado por etiqueta do ativo e pelo técnico da TIC que o fez, a fim de posteriores conferências.

Neste artigo conferimos as orientações básicas na elaboração de um diagrama de classe, onde o ponto chave foi a usar o processo de abstração com aliado na busca dos objetos espalhando em um contexto do cenário. Vimos ainda como classificar as classes eliminar duplicidades, identificar por atributos etc.

A dica passada aqui é como identificar os objetos em um cenário a fim de projetar um diagrama de classe sem falhas. Interessante dizer que crianças identificam objetos mais facilmente do que os adultos, pois o processo nos cega, deixando alguns objetos invisíveis.

Lembre-se de aplicar os passos: identificar objetos, classificá-los e eliminar duplicidade, feito isso, você terá o mais complicado que são as classes, depois com ajuda de um bom livro de análise ou um professor, realizar as cardinalidade não será problema algum.