Prévia do material em texto
<p>Diagrama</p><p>de classes</p><p>SST</p><p>Marcio, Michel</p><p>Diagrama de classes / Michel Marcio</p><p>Ano: 2020</p><p>nº de p.: 12</p><p>Copyright © 2020. Delinea Tecnologia Educacional. Todos os direitos reservados.</p><p>Diagrama de classes</p><p>3</p><p>Apresentação</p><p>Vamos realizar o estudo dos principais conceitos e elementos que estão presentes</p><p>em diagrama de classes. Iniciaremos pelos conceitos essenciais e, na sequência,</p><p>veremos sobre a visibilidade dos atributos e operações.</p><p>Em um próximo momento, passaremos a analisar o uso do diagrama de classes em</p><p>diferentes perspectivas, finalizando nossa caminhada com uma análise de exemplos</p><p>do uso de diagramas de classe e as representações de suas propriedades.</p><p>Diagrama de classes</p><p>O diagrama de classes tem por objetivo suportar a documentação de modelagem</p><p>estática de classes, contemplando interfaces e suas associações, generalizações,</p><p>restrições, multiplicidade, dependências entre classes, propriedades e outras</p><p>operações relacionadas. Está classificado entre os diagramas de estrutura.</p><p>A figura a seguir apresenta um diagrama de classe em forma plena, contemplando</p><p>vários elementos.</p><p>Simples diagrama de classes em forma plena com atributos e métodos</p><p>+ObterNome(): String</p><p>+EspecificarNome(in nome : String)</p><p>-ObterAltura(): Duração</p><p>#EspecificarIdade(in idade: Duração)</p><p>+ObterAltura(): Comprimento</p><p>+EspecificarAltura(in altura: Comprimento)</p><p>+nome: String</p><p>-dataDeNascimento: Data</p><p>+altura: Comprimento</p><p>Pessoa</p><p>Fonte: Elaborado pelo autor (2019).</p><p>4</p><p>Há muitas variações de conceitos de modelagem relacionados a este diagrama,</p><p>incluindo alguns conceitos complexos que na prática são pouco utilizados.</p><p>O diagrama de classes pode conter as formas plena e reduzida</p><p>(PAGE-JONES, 2001, p. 87). Em ambas as formas, o nome da</p><p>classe consta em um retângulo, geralmente em negrito, de forma</p><p>centralizada.</p><p>Na forma plena há três retângulos. Sempre o nome da classe</p><p>estará no retângulo superior. No retângulo do meio, constarão</p><p>seus atributos, e no inferior, suas operações, chamadas também de</p><p>métodos.</p><p>Atenção</p><p>Quando se deseja apenas relacionar classes de modo simples, ignorando seus</p><p>atributos e operações, utiliza-se a forma reduzida. Quando se pretende detalhar os</p><p>atributos e operações de uma classe, utiliza-se a forma plena.</p><p>Visibilidade de atributos e operações</p><p>No diagrama representado na figura anterior, no retângulo do meio, verificam-se</p><p>os atributos nome, dataDeNascimento e altura. No retângulo inferior, as operações</p><p>ObterNome(), EspecificarNome(nome: String), ObterIdade(), EspecificarIdade(idade:</p><p>duração), ObterAltura(), EspecificarAltura(altura: comprimento).</p><p>O diagrama de classes permite, opcionalmente, que visibilidade e parâmetros</p><p>da classe em questão sejam introduzidos com o uso de sinais específicos e</p><p>palavras-chaves.</p><p>Por isso, os símbolos “+”, “-“ e “#” respectivamente significam público, privado</p><p>e protegido, tanto dentre os atributos como dentre as operações, chamadas</p><p>usualmente de métodos. No retângulo dos métodos verifica-se a utilização da</p><p>palavra-chave “in” para indicar que o parâmetro definido é de entrada. Poderíamos</p><p>indicar um parâmetro de saída com a palavra ”out”. Vejamos o que estes símbolos e</p><p>termos representam na prática:</p><p>5</p><p>Publico</p><p>Método ou atributo que pode ser acessado por todas as demais classes do</p><p>sistema.</p><p>Privado</p><p>Método ou atributo que não pode ser acessado por todas as demais classes</p><p>do sistema.</p><p>Protegido</p><p>Método ou atributo de uma classe que pode ser acessado apenas por</p><p>subclasses de sua classe.</p><p>Em métodos que retornam informações, foram anotados os tipos de dados de</p><p>saída. Por exemplo, em ObterNome() consta o tipo de dados de saída String.</p><p>Os atributos e operações podem ser representados com mais ou menos detalhes no</p><p>diagrama de classes.</p><p>O uso do diagrama de classes em</p><p>diferentes perspectivas</p><p>Verifiquemos como podemos utilizar o diagrama de classe de duas classes em</p><p>duas perspectivas. Tomemos as classes Registradora e Venda.</p><p>Vamos comparar seus diagramas entre as perspectivas conceitual e de</p><p>especificação, denominado Diagrama de Classes de Projeto, DCP, comparados nas</p><p>Figuras a seguir.</p><p>6</p><p>Diagrama de classe em perspectiva conceitual</p><p>hora, estáCompleto: Boolean</p><p>-/total</p><p>VendaModelo de</p><p>domínio Capta 11</p><p>perspectiva</p><p>conceitual</p><p>+...</p><p>Registradora</p><p>Fonte: Elaborada pelo autor (2019).</p><p>Diagrama de classe em perspectiva de especificação</p><p>+finalizarVenda()</p><p>+entrarItem()</p><p>+fazerPagamento()</p><p>+... -hora</p><p>-estaCompleto: Boolean</p><p>-/total</p><p>+criarLinhadeItem()</p><p>Venda</p><p>Modelo de</p><p>Projeto</p><p>vendaCorrente</p><p>1</p><p>DCP; perspectiva</p><p>de software ou</p><p>de especificação</p><p>Registrado</p><p>Fonte: Elaborada pelo autor (2019).</p><p>Nota-se no modelo de domínio, a associação entre registradora e venda,</p><p>determinada apenas pela ação “capta” e as referidas classes não têm as definições</p><p>de seus métodos. Por outro lado, no DCP constam também os métodos.</p><p>Conforme consta no diagrama a seguir, verifica-se ser possível adotar uma</p><p>perspectiva de implementação de modo a se definir tipos de dados conforme a</p><p>linguagem de desenvolvimento determinada a ser aplicada para o desenvolvimento</p><p>do projeto. No caso desta figura, temos uma perspectiva de implementação na</p><p>linguagem C#.</p><p>7</p><p>Diagrama de classe em perspectiva de implementação</p><p>+id:int</p><p>-numeroSerial:string</p><p>-codModelo:string</p><p>+finalizarVenda():void</p><p>+entrarItem(in iditem:int, in precoItemUnitario: decimal, in quantidade:decimal,</p><p>in desconto:decimal):void</p><p>+fazerPagamento(in idFormaPagamento:short, in valorPago:decimal):bool</p><p>Registradora</p><p>+id:int</p><p>-numeroSerial:string</p><p>-codModelo:string</p><p>+criarLinhadeItem(in iditem: int, in valorLiquido:decimal)</p><p>Venda</p><p>Modelo de</p><p>Projeto</p><p>vendaCorrente 1</p><p>Perspectiva de</p><p>implementação</p><p>Fonte: Elaborado pelo autor (2019).</p><p>Ferramentas como Microsoft Visio, por exemplo, permitem que se proceda desta</p><p>forma, o que pode gerar ganho de produtividade, visto que a partir da criação dos</p><p>diagramas é possível com as referidas ferramentas gerar artefatos a partir dos</p><p>quais possa ser gerado código.</p><p>É sempre importante lembrar que cada diagrama tem um propósito</p><p>e deve ser utilizado, portanto, em contexto e forma adequados.</p><p>Visando à codificação dos nossos objetos exemplificados nos</p><p>diagramas apresentados, o diagrama “simples” da perspectiva de</p><p>domínio seria insuficiente, dando margem a decisões erradas do</p><p>programador.</p><p>Reflita</p><p>8</p><p>Exemplos do uso de diagramas de classe e as</p><p>representações de suas propriedades</p><p>Associação</p><p>Linha cheia que associa classes de modo a estabelecer uma relação entre classe de</p><p>origem e classe de destino, em que a classe de destino pode ser compreendida como</p><p>um tipo de propriedade. Nas linhas das associações utiliza-se a forma de seta para</p><p>que se entenda que a classe de origem é a classe de onde a seta parte. Estas linhas</p><p>apresentam também as notações de multiplicidade. Note que um Cliente pode fazer</p><p>vários Pedidos, mas cada Pedido é realizado apenas por um Cliente.</p><p>Associação unilateral</p><p>Pedido Cliente</p><p>1*</p><p>Fonte: Elaborada pelo autor(2019).</p><p>Associações bidirecionais</p><p>Linha com setas nas duas extremidades. É um par de propriedades inversamente</p><p>vinculadas, o que significa que, se o analista seguir ambas as propriedades,</p><p>retornará um conjunto que contenha seu ponto de início. A classe Brinquedo</p><p>apresenta a propriedade Criança [1] e a classe Criança tem uma propriedade</p><p>Brinquedos [*], propositalmente escrita no plural devido à sua multiplicidade. Se</p><p>o analista partir da classe Brinquedo, encontrará sua propriedade Criança, que</p><p>contém um conjunto de brinquedos que contém a classe de origem. Note que</p><p>atribuímos à classe Criança o papel de “dono” na relação com a classe Brinquedo.</p><p>Associação bilateral</p><p>Brinquedo criança</p><p>dono</p><p>0.1*</p><p>Fonte: Elaborada pelo autor (2019).</p><p>Multiplicidade</p><p>Determina quantos objetos “podem” preencher a propriedade. Nas associações,</p><p>é possível verificar a notação de multiplicidade. Normalmente encontram-se as</p><p>seguintes multiplicidades:</p><p>9</p><p>• 0: opcional, limite inferior ou igual a zero.</p><p>• 1: valor único igual a 1.</p><p>• ≥1: obrigatório,</p><p>limite inferior ou igual a 1.</p><p>• *: valores múltiplos que geralmente referem-se a valores superiores a 1.</p><p>Generalização</p><p>Útil para tratarmos de um tipo específico de associação entre classes, originando-</p><p>se a seta com ponta triangular sem preenchimento, que indica a relação de herança.</p><p>No exemplo a seguir, temos a classe Estudante, que é uma generalização da classe</p><p>Pessoa Física, que é também uma generalização de outra classe (Pessoa). Portanto,</p><p>interpretando o diagrama, Pessoa é superclasse de Pessoa Física, e Pessoa Física</p><p>é superclasse de Estudante. Ou, Estudante é subclasse de Pessoa Física, que é</p><p>subclasse de Pessoa.</p><p>Exemplo de generalizações</p><p>+ComerMerenda(in merendadodia:merenda)</p><p>Estudante</p><p>-cpf</p><p>-foto</p><p>+PraticaAtividadeFisica():bool</p><p>PessoaFisica</p><p>-nome</p><p>-endereco</p><p>+RecolherImposto(in tributo, in valor)</p><p>Pessoa</p><p>Fonte: Elaborada pelo autor (2019).</p><p>10</p><p>Dependência</p><p>Representada por uma seta tracejada de ponta triangular aberta que aponta o</p><p>sentido a partir da classe dependente (no exemplo, Jogo de Futebol). Utilizada em</p><p>outros diagramas, como nos diagramas de componentes e de implantação, porque</p><p>indicam claramente dependência também entre componentes. É uma associação</p><p>que ocorre quando uma mudança na definição de uma das classes pode causar</p><p>mudanças na outra. Na simples relação entre as classes Jogo de Futebol e Bola na</p><p>figura a seguir, verifica-se que se a Bola deixar de ter seu formato esférico e passa</p><p>para um formato oval, a classe Jogo de Futebol deixaria de ser um jogo de futebol.</p><p>Uma Bola de formato esférico atenderia a uma suposta classe Jogo de Futebol</p><p>Americano. Logo, a classe Jogo de Futebol “depende” de uma Bola esférica.</p><p>Simples exemplo de dependência</p><p>Jodo de futebol</p><p>-bola: Bola -formato: Forma = Esférica</p><p>Bola</p><p>... ...</p><p>Fonte: Elaborada pelo autor (2019).</p><p>Palavras-chave</p><p>Utiliza-se para diferenciar o significado de símbolos da UML. Por exemplo, para</p><p>diferenciar uma interface de classes comuns, utiliza-se a palavra-chave “interface”.</p><p>Na figura a seguir, temos a “interface” Treino com todas as suas operações</p><p>requeridas. Abaixo de interface, há duas classes de implementação, TreinoVôlei</p><p>e TreinoCaratê. Ambas também apresentam palavras-chave para designar</p><p>explicitamente que tipo de classe elas são. No caso, ambas são classes do tipo</p><p>“implementation class”, classes de implementação de nossa classe Treino.</p><p>11</p><p>Exemplo de notação para interfaces com o uso de palavras-chave nos diagramas de classe</p><p>+Alongar()</p><p>+Aquecer()</p><p>+ExercitarMembrosSuperiores()</p><p>+ExercicitarMembrosInferiores()</p><p>+ExercitarCore()</p><p>+TreinarAtividadeAeróbica()</p><p>></p><p>TreinoVolei</p><p>+Treinodefundamentos()</p><p>+TreinoTático()</p><p>+Jogo()</p><p>></p><p>TreinoVolei</p><p>+Kata()</p><p>+Kihon()</p><p>+Kumite()</p><p>></p><p>TreinoCarete</p><p>Fonte: Elaborada pelo autor (2019).</p><p>Fechamento</p><p>Estudamos os principais conceitos sobre diagrama de classes, compreendendo</p><p>a importância e a relevância dentro da análise de sistemas. Vimos como</p><p>verificar e sinalizar a visibilidade dos atributos e operações dentro do diagrama,</p><p>e na sequência estudamos como o diagrama de classes pode ser utilizado em</p><p>diferentes perspectivas.</p><p>Por fim, vimos diversos exemplos do uso dos diagramas de classes e como realizar</p><p>as representações, seguindo um padrão de escrita e símbolos.</p><p>12</p><p>Referências</p><p>PAGE-JONES, M. Fundamentos do Desenho Orientado a Objeto com UML. São</p><p>Paulo: Makron Books, 2001.</p>