Diagramas de Classes

(1)

ESCOLA ESTADUAL DE EDUCAÇÃO PROFISSIONAL DR. SOLON TAVARES Técnico em Informática

Análise de Sistemas - Profª Ingrid Santos

Diagramas de Classes - UML

O diagrama de classes ilustra _graficamente _{como será a estrutura do software (em nível} micro ou macro), e como cada um dos componentes da sua estrutura _{estarão interligados.}

Classes são representações de objetos em forma de conceito (desenho/texto) , que quando executadas serão materializados.

Em diagramas UML classes são representadas da seguinte maneira: Identificação da Classe

Atributos métodos Onde,

● Identificação da classe: _{cada objeto possui um nome ou identificador que o distingue dos} demais objetos e que permite que os outros objetos o reconheçam e o enderecem.

● Atributos: cada objeto pode possuir informações que são o registradas na forma de um conjunto de atributos. São representados da seguinte maneira:

<visibilidade> <nome do atributo> : <tipo do atributo>

A visibilidade indica se o atributo pode ou não ser acessado do exterior da classe por funções que não sejam membro da classe. Existem três especificadores de visibilidade:

+ = público: Neste caso o atributo é visıvel no exterior da classe. Tanto funções membro da classe quanto funções externas podem acessar o atributo.

- = privada: Neste caso o atributo não é visível no exterior da classe. Somente funções membro da classe podem acessar o atributo.

# = protegida. Neste caso o atributo também é privado mas funções membro de classes derivadas também têm acesso ao atributo.

Exemplos:

- nome: String - idade: int

● Métodos:_{cada objeto pode possuir um conjunto de habilidades de processamento que juntas} descrevem seu comportamento. Notação para métodos:

<visibilidade> <nome do método (parâmetros)> : <retorno> A _{visibilidade segue o mesmo conceito dos atributos.}

(2)

Os _{parâmetros são variáveis definidas junto aos métodos e que são utilizadas pelos} métodos para recebimento de valores no momento da ativação. Os parâmetros podem também ser utilizados para retorno de valores após a execução do método.

O _{retorno indica se o método retorna ou não um valor após sua execução. Caso} retorne declara-se o tipo de dado retornado (float, int, String, Pessoa…) caso não retorne declara-se void.

Exemplos:

+ calcularValor (float taxa): double + mostrarDados():void

+ pesquisar (Pessoa pessoa): boolean

RELACIONAMENTO ENTRE AS CLASSES

As classes se relacionam entre si para que possam se comunicar, compartilhar informações e colaborarem umas com as outras.

Dentre os relacionamentos estão a Associação, Agregação/Composição, Dependência e Herança.

Associação_{: Aplicável a classes que são independentes (vivem sem dependência umas das outras),} mas que em algum momento no ciclo de vida do software (enquanto ele está em execução) podem ter alguma relação conceitual.

A seta permite saber quem está apontando para quem, através da representação gráfica da

navegabilidade. Além disso, é possível compreender melhor de que lado está a responsabilidade. Pode ser usada sem indicação de seta.

Herança_{: Aplicável onde a classe generalizada (onde a “ponta da seta” do conector fica) fornece} recursos para a classe especializada (herdeira). Excetuando conceitos mais avançados (como padrões de projeto, interfaces, visibilidades específicas etc.), _{tudo que a classe mãe (generalizada)} tem, a filha (especializada) terá_.

(3)

Composição_{: É o relacionamento onde a classe composta depende de outras classes para} “existir”_{. Por exemplo, a classe “CorpoHumano” possui uma composição com a classe “Coracao”.} Sem a classe “Coracao”, a classe “CorpoHumano” não pode existir.

Agregação_{: É o relacionamento onde a classe agregada usa outra classes para “existir”, mas} pode viver sem ela_{. Por exemplo, a classe “CorpoHumano” possui uma agregação com a classe} “Mao”. Sem a “Mao” a classe “CorpoHumano” pode existir.

Exemplos 1:

No diagrama acima temos relacionamentos de Associação, Agregação, Composição e Generalização (Herança)

● Cozinha _{pode ter ou não uma PortaCozinha, podendo existir se não tiver. (Agregação)} ● PortaCozinha generaliza Porta, _{possuindo todas as características que Porta têm, além das}

suas específicas. (Generalização)

● Quarto _{deve ter PortaQuarto, não podendo existir se não tiver. (Composição)}

● PortaQuarto generaliza Porta, _{que tem}_{todas as características que Porta têm, além das suas} específicas. (Generalização)

● Sala _{deve ter PortaSala, não podendo existir se não tiver. (Composição)}

● PortaSala generaliza Porta, _{que tem} _{todas as características que Porta têm, além das suas} específicas. (Generalização)

(4)

● Sala _{pode ter ou não uma Porta que não seja uma PortaSala, mas se tiver ou não isso não} fará diferença, pois Porta _{pode existir sem} _{Sala, e Sala pode existir sem} _Porta. (Associação).

(no contexto do diagrama anterior) este tipo de representação acima é muito usado/recomendado quando:

● Uma equipe está discutindo um problema e algum profissional quer esboçar (esboço = rascunho, “rabisco”) como pensa na solução, em termos de arquitetura.

● Um profissional quer mostrar apenas as dependências entre as classes do sistema, para uma análise de impacto ou contextualização da arquitetura.

● Não há necessidade de entrar em maiores detalhes sobre as classes, apenas identificá-las e ilustrar suas relações.

Exemplo 2:

O diagrama acima já é um pouco diferente do primeiro, pois além dos compartimentos com os nomes das classes, possui também um outro compartimento contendo os _{atributos da classe} _(as classes sem atributos são classes “filhas” de outras [generalização], que portanto, implicitamente possuem todos os atributos que a classe “mãe” possui).

Este tipo de representação acima é muito usado/recomendado quando:

● O objetivo é demonstrar as classes, seus relacionamentos, seus atributos e não há necessidade de detalhar as operações da classe.

● O profissional precisa (ou entende ser necessário) dar mais contexto às classes, detalhando seus atributos, para que se compreenda melhor o escopo de cada classe do modelo e como isso compõe o entendimento sobre as relações entre as classes.

(5)

Análise de Sistemas - Profª Ingrid Santos Exemplo 3:

O diagrama acima já é bem diferente do primeiro e do segundo, pois além dos compartimentos com os nomes das classes e atributos, possui também um outro compartimento contendo as _{operações da classe.}

Este tipo de representação acima é muito usado/recomendado quando:

● O objetivo é demonstrar as classes, seus relacionamentos, e cada classe com seu escopo completo.

● Quando a empresa realiza projeto formal do software, utilizando ferramentas case, modelos de classes que serão utilizados para outra empresa (ou a mesma até) para entendimento sobre o software a ser construído.

● Muito cobrado em empresas que prestam serviço para órgãos públicos através de licitação. ● O profissional precisa (ou entende ser necessário) dar 100% de contexto às classes,

detalhando seus atributos e suas operações, para que se compreenda melhor o escopo de cada classe do modelo e como isso compõe o entendimento sobre as relações entre as classes.

(6)

REFERÊNCIAS BIBLIOGRÁFICAS

VENTURA, Plínio. _{Entendendo o Diagrama de Classes da UML. In: Ateomomento. Disponível} em: https://www.ateomomento.com.br/uml-diagrama-de-classes/.

STADZISZ, Paulo Cézar. _{Projeto de Software usando a UML. In Etel. Disponível em:} http://www.etelg.com.br/paginaete/downloads/informatica/apostila2uml.pdf.

SAUVÉ, Jacques Philippe. Diagrama de Classes. In.ufcg.edu.br. Disponível em: