Construindo Diagramade Classes - Luciano Cardoso.

Prévia do material em texto

Construindo Diagrama de Classes
Prof. Luciano Cardoso
lucianoscardoso@gmail.com
Construindo Diagrama de Classes
• Introdução
– Elaborar de forma criteriosa diagramas de classes 
é um fator de sucesso de projetos de software por 
que, além do fato de ser um momento propenso à 
inserção de defeitos no software, são neles em 
que são transformados os problemas do usuário 
em uma solução computacional, servindo como 
uma ponte entre requisitos e codificação. Se esta 
ponte for mal projetada, o software também será.
Construindo Diagrama de Classes
• Diagramas da UML
– Diagramas Estruturais (estáticos)
– Diagramas Comportamentais (dinâmicos)
Diagramas Estruturais
– Diagrama de classes (Class Diagram) - apresenta classes conectadas por 
relacionamentos. Usado para exibir entidades do mundo real, além de 
elementos de análise e projeto.
– Diagrama de objetos (Object Diagram) - apresenta objetos e valores de 
dados. Corresponde a uma instância do diagrama de classes, mostrando o 
estado de um sistema em um determinado ponto do tempo.
– Diagrama de componentes (Component Diagram) - mostra as dependências 
entre componentes de software, apresentando suas interfaces.
– Diagrama de estrutura composta (Composite Structure Diagram) - usado para 
mostrar a composição de uma estrutura. Útil em estruturas compostas de 
estruturas complexas ou em projetos baseados em componentes
– Diagrama de pacotes (Package Diagram) - usado para organizar elementos de 
modelo e mostrar dependências entre eles
– Diagrama de implantação (Deployment Diagram) - mostra a arquitetura do 
sistema em tempo de execução, as plataformas de hardware, artefatos de 
software e ambientes de software (como sistemas operacionais e máquinas 
virtuais)
Diagramas Comportamentais
• Diagrama de casos de uso (Use Case Diagram) - mostra os casos de uso, 
atores e seus relacionamentos que expressam a funcionalidade de um 
sistema.
• Diagrama de atividades (Activity Diagram) - representa a execução de 
ações ou atividades e os fluxos que são disparados pela conclusão de 
outras ações ou atividades.
• Diagrama de máquina de estados (Statechart Diagram) - representa as 
ações ocorridas em resposta ao recebimento de eventos.
Diagramas Comportamentais
• Diagramas de interação:
– Diagrama de seqüências (Sequence Diagram) - mostra as interações 
que correspondem a um conjunto de mensagens trocadas entre 
objetos e a ordem que essas mensagens acontecem.
– Diagrama de comunicação (Communication Diagram) - é o antigo 
diagrama de colaboração, que mostra objetos, seus inter-
relacionamentos e o fluxo de mensagens entre eles
– Diagrama temporal (Timing Diagram) - mostra a mudança de estado 
de um objeto numa passagem de tempo, em resposta a eventos 
externos.
– Diagrama de visão geral de interação (Interaction-Overview Diagram) -
uma variação do diagrama de atividades que mostra de uma forma 
geral o fluxo de controle dentro de um sistema ou processo de 
negócios. Cada nó ou atividade dentro do diagrama pode representar 
outro diagrama de interação.
Construindo Diagrama de Classes
• Classes;
• Atributos;
• Operações / Métodos;
• Relacionamentos;
Construindo Diagrama de Classes
Construindo Diagrama de Classes
• Identificar Classes
– Classes representam entidades (conceitos) do 
mundo real, ou seja, do problema para o qual o 
software estiver sendo desenvolvido. Elas são uma 
descrição de um conjunto de objetos que 
compartilham os mesmos atributos, operações, 
relacionamentos e semântica e representam o 
principal bloco de construção de um sistema 
orientado a objetos. 
Construindo Diagrama de Classes
• Identificar Atributos
– Podemos definir atributos como sendo as 
propriedades que caracterizam objetos definidos 
através das classes.
– Assim, para identificarmos os atributos das 
classes, devemos procurar por propriedades que 
caracterizam o objeto em questão, considerando a 
especificação dos requisitos e nosso 
conhecimento do domínio. 
Construindo Diagrama de Classes
• Identificar Operações
– O próximo passo é a definição de quais operações 
estarão alocadas em cada classe. As operações 
definem as habilidades de um determinado 
objeto, ou seja, tudo aquilo que ele pode realizar 
(ações).
– Dessa forma, ao procurar por operações 
estaremos identificando ações que o objeto de 
uma classe é responsável por desempenhar no 
contexto do sistema.
Construindo Diagrama de Classes
• Identificar Relacionamentos
– Com todas as classes identificadas e especificadas, 
devemos definir como elas estão relacionadas 
para que possamos elaborar o diagrama de 
classes. Os principais tipos de relacionamento 
entre classes presentes na UML são:
Construindo Diagrama de Classes
• Associação: são relacionamentos estruturais entre instâncias e 
especificam que objetos de uma classe estão ligados a objetos de outras 
classes. É representado por uma linha simples ligando duas classes e pode 
conter atributos como nome, multiplicidade e navegabilidade. O nome 
descreve a semântica (significado) do relacionamento; a multiplicidade 
indica quantos objetos de uma determinada classe um objeto pode se 
comunicar; a navegabilidade especifica quem enxerga quem no 
relacionamento, ou seja, se um objeto tem conhecimento da existência de 
outro;
Construindo Diagrama de Classes
• Generalização (herança simples ou composta):
– relacionamento entre um elemento mais geral e um mais específico 
onde o elemento mais específico herda as propriedades e operações 
do elemento mais geral. A relação de generalização também é 
conhecida como herança na orientação a objetos e denotam relações 
“é um tipo de” onde subclasses são especializações de superclasses.
• Agregação regular: tipo de associação (é parte de, todo/parte) 
onde o objeto parte é um atributo do todo. Agregação é 
representada por uma linha simples com um losango sem 
preenchimento do lado do todo;
• Composição: relacionamento entre um elemento (o todo) e outros 
elementos (as partes) onde as partes só podem pertencer ao todo e 
são criadas e destruídas com ele. O relacionamento de composição 
é representado por uma linha simples com um losango preenchido 
do lado do todo.
Construindo Diagrama de Classes
• Para identificarmos esses tipos de relacionamentos, aliado a 
nosso conhecimento no domínio do problema, efetuamos a 
leitura da especificação dos casos de uso e, para 
relacionamentos de:
– Generalização: verificamos se há alguma relação “é um tipo de” 
entre as classes identificadas;
– Associação:verificamos se há a necessidade de um objeto de 
uma classe utilizar serviços disponibilizados por um objeto de 
outra classe ou, simplesmente, conhecer o outro objeto;
– Agregação: verificamos se há alguma relação “parte de” entre as 
classes identificadas;
– Composição: verificamos se há alguma relação “parte de” forte 
entre as classes identificadas.
Construindo Diagrama de Classes
• Revisar Modelo
– Nesta etapa, devemos revisitar o modelo construído 
e verificar se ele faz sentido e contempla os conceitos 
definidos na especificação de requisitos do software. 
Identificando-se algum problema, este deve ser 
ajustado. 
– Estando o diagrama finalizado, este poderá ser 
entregue para a equipe de desenvolvimento junto 
com o arquiteto de software que realizará os devidos 
ajustes para tornar o diagrama mais próximo daquilo 
que será realmente implementado. 
Construindo Diagrama de Classes
• Exemplo prático
– Sistema para Transportadora
Exemplo prático
Para este sistema, os funcionários da transportadora devem cadastrar 
Clientes, Filiais, Veículos, Funcionários, Tipos de Veículos, Cidades, 
Distâncias, Categorias de Frete e Fretes de Clientes.
Clientes são pessoas físicas e possuem nome,endereço e telefone. Filiais 
têm nome, endereço, telefone, funcionário responsável e vários veículos. 
Veículos devem possuir número de placa e um tipo de veículo, além de ser 
necessariamente de uma filial. Funcionários são identificados pelo seu 
número de matrícula, e devem conter ainda nome, endereço, telefone e 
dependentes (com nome e data de nascimento), além de estar associado, 
obrigatoriamente, a uma filial. Tipo de Veículo apresenta uma descrição 
(como caminhão e moto) e o peso máximo que pode transportar, além de 
estar associado a veículos. Cidades contêm o nome da cidade e o estado a 
que pertence, representando as cidades abrangidas pela empresa de 
transporte. 
Exemplo prático
Distâncias envolvem as cidades origem e destino e, para cada par de 
cidades atendidas, deve haver a distância em quilômetros entre elas. 
Categoria do frete deve conter descrição e um percentual, que deve 
incidir sobre o valor do frete onde, por exemplo, entregas rápidas têm 
aumento de 10%, entregas super-rápidas têm aumento de 30%, e 
entrega normal não tem acréscimo no valor.
Cada Frete tem um código, um cliente, o veículo que deve efetuar o 
frete, cidade origem e cidade destino, funcionário responsável e itens 
a serem transportados, não podendo haver um frete sem os dados 
citados. Cada frete deve ter ainda o seu valor, que deve ser calculado 
através da distância entre as cidades envolvidas e da categoria do 
frete. Para isso, deve existir um valor padrão para o km rodado. Um 
Item de Transporte é cada objeto a ser transportado num frete e deve 
possuir apenas uma descrição e seu peso. Por fim, temos que o 
sistema ainda deve emitir Nota Fiscal com todas as informações de um 
determinado frete, logo após seu cadastramento.
Exemplo prático
• Diagrama de Caso de uso;
– Podem fazer!
Exemplo prático
Exemplo prático
• No diagrama de casos de uso observa-se que, como é o 
funcionário quem utiliza todas as funções do sistema, todos 
os casos de uso estão ligados a ele. Outra característica é 
relativa ao caso de uso EmitirNotaFiscal. 
• Como este caso de uso é disparado sempre que um frete 
for cadastrado, representa-se esta situação utilizando uma 
seta com o estereótipo “<<Include>>”, indicando que o 
caso de uso CadastrarFrete dispara o caso de uso 
EmitirNotaFiscal. 
• Este tipo de situação é utilizado quando se deseja destacar 
uma funcionalidade do sistema, como neste caso, ou 
quando uma determinada funcionalidade é utilizada por 
mais de um caso de uso, evitando que seja descrita mais de 
uma vez. 
Exemplo prático
• Especificação de casos de uso
Exemplo prático
• Encontrem as classes, não se preococupem 
com associações, atributos, operações.
Exemplo prático
• Classes (preliminares)
– Cliente, Filial, Veículo, Funcionário, Dependente, 
Tipos de Veículo, Cidade, Distância, Categoria de 
Frete, Fretes, Itens de Frete, e Parâmetro 
(contendo o valor do km rodado) representando 
elementos do domínio da aplicação
Exemplo prático
• Encontre os atributos
Exemplo prático - Atributos
Exemplo prático
• Encontre as operações
Exemplo prático
Exemplo prático
• O último passo refere-se à identificação dos 
relacionamentos e, para isso, efetua-se a 
análise dos casos de uso de forma a encontrar 
estas relações entre as classes já identificadas:
– Generalização: verifica-se se há alguma relação “é 
um tipo de” entre as classes identificadas.
Exemplo prático
• classes Funcionario e Cliente (ambos são 
pessoas físicas, pelo enunciado do estudo de 
caso) possuem atributos em comum (nome, 
endereco, e telefone), optou-se por criar uma 
classe PessoaFisica que agrupe estas 
características. Uma dúvida poderia surgir em 
relação à classe 
Exemplo prático
• Poderia surgir em relação à classe Filial, que 
possui os mesmos atributos. Neste caso, não 
será considerada herança entre estas classes, 
mesmo contendo os mesmos atributos. Isso 
por que uma Filial não é uma pessoa física e, 
portanto, não deve haver herança 
• a semântica “é um tipo de” não se aplica
Exemplo prático
• Associação: verifica-se se há a necessidade de um objeto de uma 
classe utilizar serviços disponibilizados por um objeto de outra 
classe ou, simplesmente, “conhecer” o outro objeto.
• Neste estudo de caso, observam-se várias associações no modelo, 
como entre Frete e Cliente (um frete é de um cliente e um cliente 
pode fazer vários fretes), entre Frete e Veiculo (um frete possui um 
veículo e um veículo pode fazer vários fretes), entre Frete e 
Funcionario (um frete possui um funcionário responsável e um 
funcionário pode ser responsável por vários fretes), entre Frete e 
CategoriaFrete (um frete possui uma categoria e uma categoria 
pode estar associada a vários fretes), entre Frete e Cidade (neste 
caso, existem duas associações entre estas classes, uma vez que um 
frete tem uma cidade representando sua origem e outra seu 
destino. (continua...)
Exemplo prático
• Além disso, cidades podem ser origem e/ou destino de diferentes 
fretes), entre Filial e Funcionário (uma filial possui diversos 
funcionários e um funcionário está lotado numa filial), entre Filial e 
Veiculo (uma filial possui diversos veículos e um veículo é de uma 
única filial) e, finalmente, entre Veiculo e TipoVeiculo (um veículo 
tem um tipo e um tipo pode estar associado a diferentes veículos).
Exemplo prático
• Auto-Associação: verifica-se se existe alguma classe que 
necessita ser relacionada a ela mesma. Neste estudo de 
caso, existe uma auto-associação na classe Cidade, 
representando que uma cidade pode estar associada a 
diversas outras, representando as distâncias atendidas pela 
empresa de transportes.
• Agregação: verifica-se se há alguma relação “parte de” 
entre as classes identificadas. Neste estudo de caso, não foi 
necessária a utilização de agregações.
Exemplo prático
• Composição: verifica-se se há alguma relação “parte de” forte 
entre as classes identificadas. Neste estudo de caso identificam-se 
dois relacionamentos deste tipo, um entre as classes Funcionario e 
Dependente, uma vez que os dependentes são como atributos 
internos de funcionários; e outro entre as classes Frete e ItemFrete, 
pelo mesmo motivo de estar representando atributos internos que 
foram deslocados para outra classe em função de suas 
características próprias e também pela multiplicidade.
• Além disso, a exclusão de um funcionário necessariamente 
implica na exclusão de seus dependentes, bem como a exclusão de 
um frete implica na exclusão de seus itens. Nestes casos, modelam-
se estas situações através de composições.
Exemplo prático
• Navegação: verifica-se se existem navegações desnecessárias entre 
classes. Neste estudo de caso, na associação entre as classes 
Veiculo e TipoVeiculo, utilizou-se a navegabilidade no sentido 
Veiculo TipoVeiculo, uma vez esta última não precisa utilizar 
nenhuma das operações definidas na classe Veiculo. O mesmo foi 
feito na associação entre as classes Frete e CategoriaFrete, 
mantendo a navegabilidade no sentido Frete � CategoriaFrete.
• Classe Associativa: verifica-se se existem informações que precisam 
estar vinculadas à associação de dois objetos. Neste estudo de caso, 
a classe Distancia está associada ao relacionamento entre dois 
objetos da classe Cidade, representando a distância entre elas. 
Modelam-se situações como esta utilizando uma classe associativa.
Exemplo prático
Conclusão
• Observem o detalhe de pessoafísica;
– Classe abstrata;
• Isso pode ser refinado ainda muitas vezes;
• Sua modelagem não precisa estar “igualzinha” 
para estar certa.