Diagrama de classes - unidade 3

Prévia do material em texto

Unidade 3 – diagrama de classes
Alguns dos softwares gratuitos de modelagem de dados:
Astha, Draw.io, Lucidchart, Gliffy, yUML, Creately. 
Diagrama de classes em uml
É extremamente utilizado por engenheiros de software e analistas de sistemas para realizar a documentação da arquitetura do software a ser desenvolvido. Os diagramas de classe são um tipo de diagrama de estrutura, porque descrevem o que, especificamente, deve estar contido no sistema a ser modelado. 
A linguagem de modelagem unificada – UML teve seu desenvolvimento baseado em um modelo padronizado para descrever e tratar, de forma direcionada, uma abordagem para a programação orientada a objeto, que, cada vez mais, vem se expandindo no mercado corporativo entre os desenvolvedores de soluções tecnológicas. 
Os diagramas de classe são os componentes essenciais da linguagem de modelagem unificada, da mesma forma que as classes são os componentes básicos dos objetos.
Perspectivas
Os diagramas de classe podem ser construídos a partir de duas perspectivas:
	Conceitual
	Implementação
	
É a forma abstrata de observação dos objetos a serem modelados. Isso independe da linguagem de programação a ser utilizada.
	
Nesse momento, o foco é para a reflexão de detalhes de implementação para a definição das classes e dos objetos.
	
Representa uma entidade, processo ou conceito do mundo real:
Identidade: valor de uma característica que o identifica.
Atributo: qualidade e características.
 
Comportamento: habilidade para processamento.
	
Representa um módulo que recebe e produz dados:
Identidade: identificador para a linguagem a ser implementada. 
Atributo: variáveis e seus respectivos tipos de dados.
Comportamento: funções ou procedimentos. 
É sabido que os resultados obtidos determinam o comportamento do objeto.
componentes de um diagrama de classe
O diagrama de classes, dentro do seu formato padrão estabelecido, é composto de três partes:
	
Nome da classe
	
Parte superior: vem com a informação do nome da classe. Essa parte é fundamental, pois terá a referência do classificador ou de um respectivo objeto.
	
Atributos (características)
	
Parte do meio: vem com a informação dos atributos da respectiva classe. Essa parte é utilizada para descrever com clareza as qualidades da classe. É fundamental para se descrever uma instância específica de uma determinada classe.
	
Operações(comportamentos)
	
Parte inferior: vem com a informação que incluirá as respectivas operações da classe (os métodos). Será mostrado em formato de listas. Cada operação terá a sua própria linha. As operações irão descrever como a classe interagirá com os demais dados.
componentes adicionais dos diagramas de classes
É sabido que as classes pertencentes a um respectivo diagrama de classes representarão os principais objetos do modelo, bem como as interações no aplicativo a ser desenvolvido ou as classes a serem programadas. Para isso, é preciso entender a composição básica e necessária de um diagrama de classes. 
	
Classes
	
No cenário da UML, uma classe deverá representar um determinado objeto ou um conjunto de objetos que compartilham uma estrutura e um comportamento comum.
As classes são representadas graficamente pela figura de um retângulo, que inclui linhas referentes ao seu nome, seus respectivos atributos e suas operações. Quando for desenhar a classe em um diagrama de classes, é importante que fique claro que somente a primeira linha deve ser preenchida com informações; as outras linhas são opcionais, caso queira fornecer mais detalhes para aquela classe.
	
Sinais
	
São caracterizados pelos símbolos que trazem, em sua representatividade, as comunicações de forma unidirecional e assíncrona entre objetos ativos no modelo.
	
Tipos de dados
	
São denominados de classificadores e têm por objetivo definir os valores dos dados a serem utilizados. Os tipos de dados definidos modelarão os tipos primitivos e também as enumerações necessárias.
	
Pacotes
	
São vistos como formas projetadas para estruturar os classificadores relacionados em um determinado diagrama de classes. Sua simbologia é determinada por uma grande forma de retângulo com abas. 
	
Interfaces
	São estabelecidas por uma coleção de assinaturas de operações e/ou definições de atributos que definem um conjunto íntegro e ajustado de comportamentos. Têm características semelhantes às classes, exceto que uma classe pode conter uma instância de seu tipo e uma interface precisa ter pelo menos, uma classe para implementá-la.
	
Enumerações
	
São caracterizadas por representações dos tipos de dados definidos pelo usuário no processo de levantamento de requisitos. Uma enumeração, no seu processo de definição, incluirá os grupos de identificadores que representam valores da respectiva enumeração. 
	
Objetos
	
São caracterizados pelas instâncias definidas de uma determinada classe ou classes. Os objetos poderão ser inseridos em um diagrama de classes para representar instâncias concretas ou prototípicas. 
	
Artefatos
	
São caracterizados pelos elementos do modelo que representarão as respectivas entidades concretas em um sistema de informação. 
Lista de atributos da classe voo:
A seção de atributos de uma classe tem, por definição, listar cada um dos atributos da classe em uma linha específica. A seção de atributos é uma opção, mas, se for usada, é preciso que contenha cada atributo da classe exibido na forma de lista, de acordo com o seguinte modelo: nome: tipo de atributo. 
Podemos descrever os atributos da classe com as informações do tipo de atributo. 
	Nome do atributo
	Tipo de atributo
	Numerovoo
	Número inteiro
	datapartida
	Data
	duracaovoo
	Minutos
lista de operações da classe voo
As operações das respectivas classes estarão devidamente documentadas no terceiro compartimento do retângulo do diagrama de classes, que, como já citado anteriormente, poderá ser opcional. Com os devidos atributos estabelecidos, as operações de uma respectiva classe são exibidas no modelo de lista, com cada operação em sua própria linha. 
· Nome (lista de parâmetros): tipo de valor retornado. 
	Nome da operação
	Retorno de parâmetros
	Tipo de valor
	
Atrasovoo
	 Nome Digite
numerodeminutos minutos
	
N/A
	
horaaterrizagem
	
N/A
	
Data
A tabela acima informa que a operação atrasovoo tem um parâmetro de entrada, que é o numerodeminutos, do tipo minutos. Contudo, a operação atrasovoo não tem um valor de retorno.
É importante ressaltar, ainda que a operação atrasovoo não tem um valor de retorno, porque essa decisão foi tomada no momento de sua criação. Quando em uma determinada operação houver parâmetros da operação. Cada parâmetro usa o seguinte formato: nome do parâmetro : tipo de parâmetro. 
IMPORTANTE
O código gerado a partir de um diagrama de classes precisa de classes cujos tipos de atributo sejam limitados aos tipos de atributos já existentes nas linguagens de programação que são tradicionais no mercado ou aos tipos incluídos no modelo que também serão implementados no sistema.
É sabido que, em alguns casos, faz-se necessária a atribuição de um valor padrão para um ou mais atributos.
A especificação contida na UML permite que a utilização da identificação do valor padrão do atributo seja feita na seção de atributos de acordo com a notação abaixo: 
• nome: tipo de atributo = valor padrão 
Exemplo: 
saldoconta : real = 1000
hERANÇA
Trata da capacidade da classe-filha herdar as funcionalidades das superclasses e, na sequência, incluir uma nova funcionalidade própria. 
Para modelar a herança no respectivo diagrama de classes, é preciso usar a simbologia de uma linha sólida que é desenhada a partir da classe-filha (a classe que herda o comportamento da superclasse), com uma ponta de seta (ou um triângulo) fechada, não preenchida, apontando para a superclasse. 
Exemplo:
	Funcionário
	
	
	Coordenador
	
	
	Professor
	
	
Atributos e visibilidade
Público (+) – Indica que o atributo tem visibilidade liberada, sem restrições, para qualquer classe. 
Privado (-) – Indicaque o atributo é acessado somente pela própria classe. 
Protegido (#) – Indica que o atributo é acessado por qualquer classe derivada. 
Pacote (~) – O atributo é acessado pelo relacionamento da classe com a classe que é externa. 
Relacionamento entre as classes
Relacionamento
Permite compartilhar informações e colaborar com a execução dos processos do sistema que foi modelado para atender a uma demanda. Ele descreve, de forma clara, o vínculo que ocorre, na sua essência, entre os objetos de uma ou mais classes que foram contemplados no diagrama de classes. 
Existem três tipos de relacionamento, com suas respectivas subdivisões internas:
associações
Ao realizar a modelagem em um sistema, determinados objetos estarão relacionados entre si. Os relacionamentos entre esses objetos, por sua vez, também precisam ser modelados para que haja mais clareza e entendimento sobre todos os tipos de relação entre as classes. 
a. Associação unidirecional
Duas classes são relacionadas, mas somente uma classe reconhece que o relacionamento existe entre elas. 
Símbolo: 
É desenhada com base em uma linha sólida com uma ponta de seta aberta. Não pode ser utilizada uma ponta de seta fechada nem um triângulo. A ponta da seta sempre aponta para a classe reconhecida. 
	Dependente
	grauparentesco: string
	
Para a composição da associação, é importante que haja um nome da função e um valor de multiplicidade, que valem somente para a classe que é reconhecida.
	Funcionário 
	numemat: int
nomefunc: string
salario: double
	manterfunc(): void
 
0..*
Possui
O nome da função está escrito abaixo do símbolo de associação e o valor de multiplicidade vem escrito logo acima. 
b. Associação bidirecional (padrão)
Uma ligação entre duas classes mapeadas no diagrama de classes. Nesses casos, ambas as classes estarão cientes de que pertencem ao relacionamento, a menos que você qualifique a associação como algum outro tipo. 
Símbolo: 
É caracterizada por uma linha sólida que faz a ligação entre as duas classes. 
	Funcionário 
	numemat: int
nomefunc: string
salario: double
	manterfunc(): void
	Funcionário 
	numemat: int
nomefunc: string
salario: double
	manterfunc(): void
	Dependente
	grauparentesco: string
	
 1 0..*
 Possui
c. Associação reflexiva
Quando uma determinada classe se associa com ela própria. Isso não quer dizer que uma instância da classe esteja relacionada com ela própria, mas sim que uma determinada instância da classe está relacionada a outra instância da classe. 1
	Funcionário
	codigo: int
nome: String
	manterfunc(): void
	 	Gerência
	
	0..*
No relacionamento representado graficamente acima, uma instância da classe Funcionário pode ser o gerente de outra instância da classe Funcionário. Por outro lado, como a função de relacionamento “gerencia” tem uma multiplicidade de 0..*, pode acontecer de um Funcionário não ter nenhum outro Funcionário para gerenciar.
d. Classe de associação 
Na modelagem das associações, algumas vezes é necessário incluir outra classe (terceira classe), porque ela inclui informações de suma importância sobre o relacionamento em questão. Para isso, é necessário usar a chamada classe de associação a ser vinculada à associação primária. 
Uma classe de associação tem a sua representatividade no formato de uma classe normal. A única diferença existente é que a linha de associação entre as classes primárias faz uma interseção com uma nova linha pontilhada que se conecta à classe de associação. 
	Produto
	codigo: int
tipo: string
valor: double
	manterfunc(): void
	Funcionário
	cnpj: int
nome: string
	manterfunc(): void
	 Classe de associação
	Fornecimento
	data: date
valor: double
e. Associação ternária
Permite a associação entre três classes. 
É representada por um losango (diamante) e, ainda, suporta uma associação de classe ligada a ela. Nesse caso, desenha-se uma linha tracejada a partir do losango para a classe em que será feita a associação ternária. 
1..*
0..*
	Produto
	
	
	Funcionário
	
	
1..*
	 
	Funcionário
	
	
Agregação
Condiz com um tipo especial de associação, usado para modelar um determinado relacionamento do “todo com as suas respectivas partes integrantes”.
Nos relacionamentos denominados básicos, que possuem a necessidade do uso de agregação, o ciclo de vida de uma respectiva classe mapeada como “parte” é independente do ciclo de vida da classe mapeada como “todo”. 
a. Agregação básica
A agregação básica existente em um modelo tem a finalidade de indicar que uma determinada classe fará parte de outra. Quando há esse tipo de relacionamento, a classe-filha poderá ter uma vida maior do que a classe-pai (superclasse). 
Símbolo: 
	Produto
	codigo: int
tipo: string
valor: double
	manterfunc(): void
	Funcionário
	cnpj: int
nome: string
	manterfunc(): void
b. Agregação de composição
É mais uma forma de relacionamento de composição, mas, nesses casos, o ciclo de vida da instância da classe-filha depende do ciclo de vida da instância da classe-pai (superclasse).
Símbolo: 
	Departamento
	codigo: int
tipo: string
	
	Empresa
	cnpj: int
nome: string
	manterfunc(): void
No relacionamento modelado no diagrama de classe acima, uma instância da classeEmpresa sempre terá pelo menos uma instância da classeDepartamento. Como o relacionamento em questão é um relacionamento de composição, se a instância de Empresa for excluída/removida, a instância de Departamento também será, de forma automática, excluída/removida. 
A classe da parte somente pode estar relacionada a uma instância da classe-pai (como a classe Empresa citada no exemplo acima). 
generalização 
É tida como um relacionamento entre um elemento geral e um outro mais específico. O elemento que se entende por mais específico possui todas as características do elemento geral e contém ainda mais algumas particularidades. 
a. Generalização normal 
A classe mais específica, chamada de subclasse, herda tudo da classe mais geral, a superclasse. Os atributos, as operações e todas as associações são herdados. 
	Poupança
	
	
Símbolo: 
	Conta Corrente
	
	
b. Generalização restrita
Se divide em:
· Generalização de sobreposição – quando as subclasses herdam de uma superclasse por sobreposição. 
· Generalização disjuntiva – quando um objeto pertence a apenas um tipo de classe. Quaisquer outras subclasses criadas posteriormente poderão herdar de somente uma subclasse. 
· Generalização completa – quando todas as subclasses possíveis foram enumeradas na hierarquia. 
· Generalização incompleta – quando todas as subclasses foram enumeradas na hierarquia. 
	
modelando o diagrama de classes
os benefícios dos diagramas de classes
· Ilustrar de forma clara os modelos de dados utilizados para a criação dos sistemas de informação, não importa o quanto são simples ou complexos. 
· Entender de forma mais eficaz a visão geral dos esquemas de uma aplicação a ser desenvolvida. 
· Expressar visualmente as referidas necessidades que devem ser tratadas em um sistema e também divulgar claramente essas informações para toda a empresa. 
· Criar gráficos específicos, com detalhamentos que gerem destaque para qualquer código específico necessário para ser programado e implementado. 
agilidade x UML
Se refere a produzi-lo com uma determinada velocidade, entregando-o no menor tempo possível e melhorando o processo de produção de forma contínua. 
Não se pode falar em agilidade sem a devida eficiência. Além disso, não pode haver desperdício de tempo. 
Para que a dupla agilidade – eficiência funcione, é necessário que:
· Esteja claro o que se deseja.
· Todos na empresa saibam o que será entregue.
· Esteja claro como a produção do software vai acontecer. 
A produção de um diagrama de classes é algo complexo, mas necessário, pois quando se entede um “requisito” de forma errada, há um custo para fazer errado, desfazer e refazer da forma correta. Esse tipo de erro gera um custo que poderia ter sido evitado daprimeira vez.
objetivo da utilização do diagrama
Tem como objetivo principal a especificação dos componentes que farão parte da construção do sistema de informação e como esses componentes se interligam do ponto de vista estrutural. 
· Design: será necessária a definição de um modelo a ser seguido para um software que ainda não foi concebido, assim especificando um modelo antes de efetivamente construir o software executável (diminuindo o desperdício).
· Engenharia reversa: é importante que haja uma reflexão na estrutura que já existe de um software, em que, a parte do código-fonte, faz-se uma leitura automática (ou não) das classes e das suas relações se produz o diagrama (para entendimento da estrutura do software executável)
· Esboço de ideias: é importante que se desenhem modelos estruturais para troca de ideias e alinhamento entre os analistas de sistemas envolvidos no projeto. 
mapeando o diagrama de classes
Regras úteis 
· É melhor mapear demais do que de menos.
· Não exclua entidades simplesmente porque os requisitos não indicam necessidade de guardar requisitos sobre elas.
· Comece fazendo uma relação das entidades candidatas.
· Considere os substantivos e rases nominais nas descrições textuais do domínio do problema como possíveis candidatos a entidades e/ou atributos. 
Como fazer a identificação?
· Existem informações que devem ser analisadas e/ou informadas.
· Existem sistemas externos ao modelado?
 - Se existirem, eles deverão ser tratados como classe pelo sistema para que possa interagir com outros meios externos. 
· Qual papel dos atores no sistema?
- Talvez o papel deles possa ser visto como uma classe. 
Identificando as associações
· Foque nas associações cujos conhecimentos devem ser mantidos. 
· Use nomes e expressões verbais que façam sentido quando forem lidas no contexto do modelo desenvolvido.
· Evite demonstrar o uso de associações deriváveis e restritas.
· É muito mais importante que haja a identificação dos conceitos do que das associações.
· Muitas associações tendem a gerar confusão no modelo em vez de torná-lo inteligível. 
Identificando as generalizações
· A subclasse terá atributos adicionais de interesse?
· A subclasse terá associações adicionais de interesse?
· A subclasse se comportará de forma diferenciada da superclasse ou das subclasses?
· Criando superclasses:
- As subclasses com potencial representarão variações de um conceito similar?
- As subclasses satisfarão 100% da regra estabelecida?
- Todas as subclasses possuirão um atributo comum definido na superclasse?
- Todas as subclasses possuirão uma associação comum que se relacionará com a superclasse?
Identificando as agregações
· Verifique se algumas classes podem se agrupar em algum composto:
- Elas geralmente são criadas/destruídas no mesmo momento?
- Elas possuem relacionamentos comuns?
· Verifique se alguma classe pode ser subdividida em partes:
· As partes possuem tempo de vida limitado ao tempo de vida do composto?
· Elas possuem relacionamentos particulares e de interesse?
Identificando os atributos 
· Atributos devem representar, preferencialmente, tipos primitivos de dados ou de valores simples. 
· Atributos não podem ser usados para:
- Representar um conceito complexo.
- Relacionar conceitos (chaves estrangeiras).
Identificando os métodos
· Os métodos são acrescentados na perspectiva de implementação e são derivados a partir do diagrama de interação. 
· É importante que haja distinção da operação de método.
· Operação é uma coisa que se evoca (chamada do procedimento). Para realizar uma operação, a classe implementa um método (corpo do procedimento).
· É fundamental identificar operações que alteram ou não o estado (os atributos) de uma classe.
· Não modificam: query, métodos e obtenção e getting methods.
· Modificam: modificadores, métodos de atribuição ou fixação, setting methods. 
Uma classe que será definida no diagrama de classe da UML possuirá três compartimentos, sendo um para cada um dos itens a seguir:
· Nome (primeiro).
· Atributos (segundo).
· Operações (terceiro).
Nem sempre é necessário e/ou relevante fazer a apresentação de cada classe no menor nível de detalhe, ou seja, com os três compartimentos, e com todo rigor nas especificações dos atributos e operações. 
modelo de um diagrama de classes
Explicação da construção do modelo:
· 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 tem, 
· 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 tem, 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 tem, além 
· das suas específicas (generalização).
· 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).
image3.png
image4.png
image5.png
image6.png
image1.png
image2.png