DOUGLAS TYBEL

DIAGRAMA DE CLASSE
Orientaes bsicas na elaborao de um diagrama de classe

Douglas Tybel 07/07/2011

Contedo
ORIENTAES BSICAS NA ELABORAO DE UM DIAGRAMA DE CLASSE ............................................................................................................. 3 INTRODUO................................................................................................ 3 Relacionamento entre classes ........................................................................ 4 So conexes entre classes: ...................................................................... 4 CENRIO ....................................................................................................... 5 IDENTIFICAR OS OBJETOS TANGVEIS ..................................................... 8 IDENTIFICAR OS OBJETOS POR SEUS ATRIBUTOS................................. 9 LISTA COMPLETA COM TODOS OS OBJETOS ENCONTRADOS ........... 10 Agrupar os Objetos por semelhana ......................................................... 11 Elimitar Classes desnecessrias ou repetidas .......................................... 11 MONTANDO O DIAGRAMA DE CLASSE .................................................... 13 Realizando as primeiras ligaes .............................................................. 13 Efetuando as ligaes entre as Classes ................................................... 14 DIAGRAMA DE CLASSE COMPLETO......................................................... 16 CENRIO PARA EXERCITARMOS ............................................................. 17 CONCLUSO ............................................................................................... 19 REFERNCIAS ............................................................................................ 19

ORIENTAES BSICAS NA ELABORAO DE UM DIAGRAMA DE CLASSE DOUGLAS DE OLIVEIRA TYBEL

Possui graduao em Administrao com habilitao em Anlise de Sistemas pela Faculdade Vale do Cricar (2006). Ps-graduao em Engenharia de Softwares (2008). Professor na Faculdade Vale do Cricar.

RESUMO: Este artigo orienta o leitor na elaborao de um diagrama de classe, procurando estabelecer, de forma sinttica, os principais pontos para a abstrao dos objetos e classes de um cenrio especfico. Neste sentido, descreve-se sequencialmente, os sucessivos componentes para a construo de um diagrama de classe completo.

PALAVRAS-CHAVE: Diagrama. Objeto. Classe. Abstrao

INTRODUO
Em programao, um diagrama de classes uma representao da estrutura e relaes das classes que servem de modelo para objetos. Podemos afirmar de maneira mais simples que seria um conjunto de objetos com as mesmas caractersticas, 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 retngulo com trs divises, so elas: O nome da classe, seus atributos e por fim os mtodos. Vejam abaixo na Figura1 sua representao:
Clientes -codPessoa -numCliente +setCadastrar() +getConsultar()

Figura 1 - Classe Clientes

4 Porque to 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 to importante encontrarmos. Observe tambm que para identificarmos uma classe, precisamos antes identificar seus objetos com caractersticas semelhantes. Ao analisarmos um cenrio, poderemos identificar inmeros objetos, contudo nem todo objeto ser til para nosso diagrama de classe, essa classificao dos objetos que usaremos chamado de Abstrao. Abstrao a forma de concentrarmos apenas nos aspectos essenciais do nosso cenrio. Para o desenvolvimento do nosso diagrama de classe, precisaremos de um cenrio qualquer onde realizaremos um passo a passo at abstrairmos todas as classes, a partir deste ponto, poderemos efetuar as ligaes e cardinalidade.
Classe1 +atributo1 #atributo2 -atributo3 +operacao1() #operacao2() -operacao3()

Figura 2: Demonstrao de visibilidade

A classe pode tem sua acessibilidade definida por visibilidade com os acessos: public,private, protected, para tal, so usados os respectivos smbolos: +,- e #. + public - private # protected

RELACIONAMENTO ENTRE CLASSES

So conexes entre classes:

1. Dependncia

5 uma relao do tipo usa em que as mudanas na implementao de uma classe podem causar efeitos em outra classe que a usa. Exemplo: uma classe usa a outra. 2. Generalizao o uma relao do tipo um entre uma coisa geral (superclasse) e uma coisa mais especfica (subclasse). 3. Associao o uma relao estrutural na quais classes ou objetos esto interconectados.

Uma associao entre objetos chamada de uma ligao (link). Nome da associao Papeis da associao Multiplicidade da associao Agregao da associao Composio da associao

CENRIO
Voc trabalha para uma empresa de desenvolvimento como Analista de Sistemas. O responsvel pelo setor que voc trabalha, em uma reunio, 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 obrigatrio controlar os pedidos de suporte/servio que so feitos pelos clientes. O ramo da empresa Servie Desk1 o fluxo do processo segue abaixo:

O cliente entra em contato com a central atravs do telefone;

O Service Desk uma Central de Servios de atendimento integrado em Tecnologia da Informao, baseado na ITIL, que presta assessoria, gesto e integrao de recursos e ferramentas, para atendimento interno (staff) ou externo (clientes direto e indiretos).

6 Um atendente tem um prazo curto para registrar esta solicitao, informando os dados do cliente, o que foi solicitado, o nvel de urgncia, o grupo de atendimento, o tcnico, um ou mais equipamentos envolvidos na manuteno. Anotar toda a interao realizada no equipamento, como por exemplo: Se ele conectar remotamente ao equipamento, deve informar em um histrico e suponhamos que 3 segundos depois ele reinicie o equipamento, dever informar no histrico tambm. Resumindo: Toda interao deve ser anotada no registro com data e hora. Caso ele consiga resolver o que foi solicitado, o tcnico do Service Desk ir salvar o registro com a situao de Resolvido encerrando o caso, contudo dever em um local especfico do registro definir como ele resolveu o caso, informando que se tratava de um Incidente2, Problema deve ser
3

ou Solicitao4. O registro

categorizado, escolhendo dentre trs classificaes:

Categoria >> Sub Categoria >> Item da categoria, onde a categoria uma lista de tipo de servio, como por exemplo: Se foi Hardware ou Software. A Sub Categoria est relacionada com a categoria, pois dependendo do que foi escolhido na primeira lista ser mostrada na segunda que ser uma Sub Categoria, como por exemplo: No caso da escolha de Hardware, seria informado na subcategoria algum tipo de pea do equipamento que o tcnico interagiu, tipo DVD/R, no caso de Categoria ser Software a sub categoria deveria ser qual software, tipo: Word, Excel e etc...E no item da categoria deveria ser escolhido o que foi realizado pelo tcnico, no caso de Hardware >> DVD/R, poderia ser SUBSTITUIDO, LIMPADO..etc. No caso de Software >> Word >> INSTALADO,DESINSTALADO etc... Caso o tcnico do Service Desk no consiga resolver no seu prazo que ser o mais curto, dever enviar o registro para outro grupo de atendimento onde existiro outros tcnicos que podero
2 3

Parada repentina ou reduo da qualidade do servio. Vrios incidentes j ocorridos sem soluo. 4 Pedido de servio.

7 ir at o equipamento fisicamente para resolver o problema com um prazo mais extenso. Um grupo composto por vrios tcnicos, no registro deve constar o grupo que atendeu e o tcnico, 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 fsico tenta entrar em contato com o cliente, mas no o obtiver sucesso, o tcnico 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 situao do registro para Pendente pelo cliente, definir tambm a data e hora para o prximo contato. Esta situao de pendncia significa que o tcnico no est atendendo por culpa do cliente e o tempo em que o registro fica nesta situao 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 especfico o que foi feito neste registro resumidamente. Se a situao do registro estiver definida como Resolvido, uma pesquisa de satisfao dever ser enviada para o solicitante.

IDENTIFICAR OS OBJETOS TANGVEIS

Para identificarmos um objeto, precisamos antes entender como v-los, para isso, basta ter como regra que: O objeto algo tangvel, que podemos perceb-lo a nossa frente, sendo possvel encontr-lo no mundo real ou virtual. Exemplos de objetos que podemos perceber ao ir a uma lanchonete: Mesa, Cadeira, Atendente, Lanche, Bebida e etc. Vamos tentar encontrar os objetos do nosso cenrio, observe o primeiro item abaixo: O cliente entra em contato com a central atravs do telefone;

Nesta frase acima, podemos identificar como objetos: Cliente Telefone

Cliente considerado um objeto, pois tangvel e existem vrios outros iguais a ele com as mesmas caractersticas, assim como o telefone.

No segundo item do cenrio identificamos: Atendente Solicitao Grupo Tcnico Equipamento Histrico

O nico item acima que gera dvida se ou no um objeto, seria histrico, pois no normal vermos este objeto, entretanto ele existe, veja o exemplo deste objeto no mundo real: Na escola existe o histrico escolar ou na clnica existe histrico mdico e etc.

No terceiro item do cenrio identificamos: Categoria Sub Categoria Item da categoria

9 Observe que estes objetos acima so difceis de identificarmos no mundo real, mas preste ateno no cenrio de uma locadora de DVD veja que as placas com o gnero dos filmes so categorias, aquelas placas so objetos tangveis representando categorias que j seria sua classe me. Os itens quatro e cinco do cenrio esto apenas explicando o processo, no identificamos nenhum objeto novo. No sexto e ultimo item do cenrio identificamos os seguintes objetos: Pedido Pesquisa satisfao

IDENTIFICAR OS OBJETOS POR SEUS ATRIBUTOS

Aps identificarmos os objetos que estavam visveis no cenrio, agora teremos que encontr-los atravs de seus atributos, onde os atributos so

caractersticas do objeto, suponhamos que no cenrio acima, foi falado sobre algum objeto, contudo no foi pronunciado seu nome, dificultando assim sua localizao. Para encontrarmos teremos que identificar atributos ou

caractersticas, como por exemplo: se no cenrio dado acima, tivssemos o atributo CPF, poderamos identificar que esta caracterstica pertence ao cliente, identificando assim o objeto Cliente sem que seu nome houvesse sido pronunciado no cenrio. Voc deve repassar todo cenrio novamente em busca destas caractersticas sem objetos, abaixo segue alguns que identifiquei: Data Hora Situao Tipo de Servio Prazo

Observe que os atributos Data, Hora, Situao, Tipo de Servio e Prazo so referente ao pedido, sendo assim, para identificarmos novas classes a partir desses atributos, teremos que realizar a seguinte pergunta para cada um deles:

10 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? = No Eu preciso uma lista de Hora? = No Eu preciso uma lista de Situao? = Sim Eu preciso de uma lista de Tipo de Servio? = Sim Eu preciso uma lista de Prazos? = Sim As perguntas com resposta Sim, sero novas classes, segue abaixo as novas classes encontradas: Situaes Tipo de Servios Prazos

LISTA COMPLETA COM TODOS OS OBJETOS ENCONTRADOS

Listaremos abaixo para facilitar nossa visualizao, todos os objetos encontrados aps nossa abstrao: Cliente Telefone Atendente Solicitao Grupo Tcnico Equipamento Histrico Categoria Sub Categoria Item da categoria Pedido Pesquisa satisfao Situaes Tipo de Servios

11 Prazos

Agrupar os Objetos por semelhana Nosso prximo passo agrupar todos os objetos encontrados por caractersticas semelhantes, como por exemplo: Mesa e Cadeira tm as mesmas caractersticas, sendo classificadas como Mveis. Assim devemos trabalhar os itens acima:

Cliente, Atendente e Tcnico = Pessoas Solicitao, Histrico, Pedido e Pesquisa de Satisfao = Documentos Telefone = Equipamentos

Veja que alguns dos objetos acima no foram classificados, devido a no necessidade de tal processo, pois j est em sua classificao correta, devemos apenas usar o plural, pois normalmente uma classe est no plural devido sua origem em agrupar vrios objetos.

Elimitar Classes desnecessrias ou repetidas

Observe no item anterior que muitas classes so do mesmo gnero, fazendo com que esteja repetida no diagrama e se uma classe se repete no banco de dados ser uma tabela criada sem propsito nenhum. Para eliminar, vejamos primeiro as classes que agrupamos por semelhana: Observe que Pedido e Solicitao no cenrio fez referncia a uma mesma coisa, assim podemos ento eliminar uma das duas, eu eliminei a solicitao. Veja que o objeto Telefone um item de equipamentos, sendo assim podemos tambm elimin-lo: Abaixo a nova lista de classes: Pessoas Cliente Atendente Grupo Tcnico

12 Equipamento Histrico Categoria Sub Categoria Item da categoria Pedido Pesquisa satisfao Situaes Tipo de Servios Prazos

13

MONTANDO O DIAGRAMA DE CLASSE

Para iniciarmos os primeiros passos de nosso diagrama de classe, desenhe em uma folha de papel um retngulo com trs divises para cada classe. Veja abaixo na Figura2, como deve ficar:

Pessoas -codPessoa -Pessoa

Clientes -codPessoa -numCliente +setCadastrar() +getConsultar()

Atendentes -codPessoa -numAtendente

Tcnicos -codPessoa -numTecnico

Grupos -codGrupo -codFuncinario

Pedidos -codOrdem -codDoc -codCliente -codFuncionario -codGrupo -codTipo -codCategoria -codsubCategoria -codItem Categorias -codCategoria -categoria

Sub_Categorias -codCategoria -subCategoria

Itens_da_Categoria Documentos Tipos de Servios -codTipo -codDoc -documento -codItem -item

Situao -codSituao -situao

Histrico_de_Atendimento -codHistrico -codDoc Equipamentos -codEquipamento

Figura 3 - Diagrama de classe sem ligaes e cardinalidade

Realizando as primeiras ligaes

Para efetuarmos a primeira ligao, faremos com os objetos que agrupamos por caractersticas semelhantes, como por exemplo: Clientes, Atendentes e Tcnicos se relacionam com pessoas, segue abaixo as ligaes:

14

Pessoas -codPessoa -Pessoa 1

0..1 Clientes -codPessoa -numCliente 0..1 +setCadastrar() +getConsultar() 1 Atendentes -codPessoa -numAtendente

0..1 Tcnicos -codPessoa -numTecnico

Figura 4 - Parte do diagrama de classe envolvendo pessoas

Pedidos -codOrdem -codDoc -codCliente -codFuncionario -codGrupo -codTipo -codCategoria -codsubCategoria -codItem

0..1

Documentos -codDoc -documento 1

Figura 5 - Parte do diagrama de classe envolvendo documentos

Efetuando as ligaes entre as Classes

Este ponto trabalhoso, pois devemos testar classe por classe em busca de ligaes, veja abaixo como realizar esta tarefa: Sabemos que o cliente entra em contato com o atendente que gera um pedido. Com esta informao observamos que um pedido foi gerado da interao entre cliente e atendente, em que um cliente pode solicitar vrios pedidos para um atendente e um atendente a vrios 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 havamos identificado antes. O importante sobre a N para N que a classe que nasceu recebe os cdigos das classes que o fizeram a relao, ficando a classe Pedido com o cdigo do cliente e o cdigo da atendente.

15 Sabe-se tambm que esse pedido ser repassado para um tcnico que o atender, sendo assim um tcnico pode atender a vrios pedidos e um pedido pode ser atendido por um tcnico, 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: cdigo do tcnico. Faa o processo para todas as classes, use sempre a pergunta dessa forma: Um Nome de um objeto da classe pode nome da ligao (verbo) um ou vrios nome da classe Como ficaria entre Pedidos e situao: Um pedido pode passar por uma ou vrias situaes? Resposta: Vrias (N), pois ao abrir o pedido pode estar na situao em andamento, ou at mesmo, em outro ponto do tempo pode ficar pendente e ser concluda ao final do servio. Ao realizar a pergunta, a cardinalidade que descoberta sempre vai para a classe de destino, depois precisamos fazer o reverso, a mesma pergunta com o verbo ao contrrio do seu uso, por exemplo: Se usar conter o reverso seria estar contido. Uma situao pode ter passado por um ou vrios pedidos? Resposta: Vrias (N), uma vez que uma situao pode ser usada por diversos pedidos, veja que existem, por exemplo, diversos pedidos com a situao de Concludo. A cardinalidade presente ser de N para N ou muitos para muitos, indicando que devemos criar uma classe de relacionamento entre as duas para absorver as chaves primrias de ambas as classes.
Pedidos -codPedido * * -Ter Situacoes -codSituacao

Figura 6: Cardinalidade entre Pedidos e Situacoes

16

DIAGRAMA DE CLASSE COMPLETO

Pessoas -codPessoa -Pessoa 1

0..1 Clientes -codPessoa -numCliente 0..1 +setCadastrar() +getConsultar() * 1 Equipamentos -codEquipamento * 1 Pedido_Equipamentos -codPedido -codEquipamento * 1 * 1 Pedidos -codOrdem -codDoc -codCliente -codFuncionario -codGrupo -codTipo -codCategoria -codsubCategoria -codItem 1* * 1 Atendentes -codPessoa -numAtendente

0..1 Tcnicos -codPessoa -numTecnico 1 Grupos -codGrupo -codFuncinario 1 1 * 1 Categorias -codCategoria -categoria 1 Sub_Categorias 1 -codCategoria -codSubCategoria -subCategoria *

1 Tipos de Servios -codTipo * Pedido_Situaes -codSituao -codOrdem -tempoNaSituao * 1

* 1 Itens_da_Categoria -codItem -item

Histrico_de_Atendimento -codHistrico -codDoc

Situaes -codSituao -situao

Figura 7 - Diagrama de classe completo

17

CENRIO PARA EXERCITARMOS

Voc trabalha para uma empresa coorporativa, seu cargo Analista de Sistemas. O responsvel pelo setor Ativos
5

lhe enviou um email solicitando o

desenvolvimento de um software para resolver um problema que o setor tem constantemente enfrentado com as auditorias internas, esta medida de suma importncia e o desenvolvimento deve ser realizado o mais breve possvel antes que auditoria externa faa a prxima visita. Sua tarefa foi desenvolver um diagrama de classe para que seja iniciado o desenvolvimento deste novo software. Abaixo segue o cenrio informado pelo responsvel do projeto: A empresa que nos contratou, deseja adquirir o certificado ISO 9001 em qualidade, entretanto um dos itens de verificao o registro de movimentao dos ativos.

Segue abaixo o que foi explicado pelo responsvel:

O cliente entra em contato com a central atravs do telefone solicitando vrios tipos de servio para a TIC6, alguns deles so: remanejamento/instalao/alienao monitores, impressoras e etc.);
7

de Ativos (computadores,

Quando um equipamento instalado ou movido, seu histrico de movimentao deve ser registrado e em um software central, tambm deve ser possvel saber exatamente sua localizao.

A localizao do equipamento dividida por cidade, imvel, andar e sala, por exemplo: Suponhamos que a empresa tenha filiais em cidades distintas sendo que em cada cidade existem

Em contabilidade, Ativo um termo bsico utilizado para expressar o conjunto de bens, valores, crditos, direitos e assemelhados que forma o patrimnio de uma pessoa, singular ou coletiva, num determinado momento, avaliado pelos respectivos custos 6 Tecnologias da Informao e Comunicao - sigla para designar a informtica e sua potencializao com os recursos de comunicao 7 Perda de algum bem material, fsico, mental, emocional, cultural, social, poltico e/ou econmico.

18 outros imveis desta mesma filial, sendo estes imveis divididos por andares e cada andar pode ter vrias salas separadas. No cadastro do Ativo deve ser informada esta localizao detalhadamente, a ponto do auditor ao verific-lo saiba

exatamente a localizao do equipamento. Quem envia as solicitaes de movimentao so os tcnicos da TIC, tendo em vista que so eles que fazem esta instalao ou movimentao do Ativo. Um usurio que no seja da TIC, proibido de tomar esta ao. Ao enviar a solicitao ele deve informar a etiqueta do ativo e a localizao de destino para o setor de Ativos, assim atravs desta solicitao que ficar com situao de pendente at que seja movida pelo funcionrio do setor de Ativos possvel alterar o cadastro do Ativo para a nova localizao. O funcionrio do setor de Ativo deve de posse da movimentao enviada para mover o ativo, acessar o cadastro do ativo e alterar sua localizao de acordo com o solicitado e tambm alterar a situao da solicitao do tcnico da TIC para a nova situao: MOVIDA. O histrico destas solicitaes deve ser classificado por etiqueta do ativo e pelo tcnico da TIC que o fez, a fim de posteriores conferncias.

19

CONCLUSO

Neste artigo conferimos as orientaes bsicas na elaborao de um diagrama de classe, onde o ponto chave foi usar o processo de abstrao como aliado na busca dos objetos espalhando em um contexto do cenrio. Vimos ainda como classificar as classes eliminar duplicidades, identificar classes por atributos e etc. A dica passada aqui como identificar os objetos em um cenrio a fim de projetar um diagrama de classe reduzindo falhas. Interessante dizer que crianas identificam objetos mais facilmente do que os adultos, pois o conhecimento sobre o processo pode deixar qualquer um cego devido ao foco, fazendo com que alguns objetos fiquem invisveis. Lembre-se de aplicar os passos: Identificar Objetos, Classific-los e eliminar duplicidade, feito isso, voc ter o mais complicado que so as classes, depois com ajuda de um bom livro de anlise ou um professor, realizar as cardinalidade no ser problema algum.

REFERNCIAS

Melo, Ana Cristina. Desenvolvendo Aplicaes com UML, 1 Edio, Brasport, 2002. Melo, Ana Cristina. Desenvolvimento aplicaes com UML 2.0: do conceitual implementao / Ana Cristina Melo. 2. Ed. Rio de Janeiro : Brasport, 2004. ISO 9001.