Aula 8 - Solução em classes

Prévia do material em texto

Disciplina: Projeto de TCC em Sistemas de
Informação
Aula 8: Solução em classes
Apresentação
Segundo os desenvolvedores, um dos diagramas de maior relevância dentro do contexto da orientação a objeto é o modelo
de classes, que pretende apresentar as classes do sistema com suas estruturas (atributos e métodos) e os relacionamentos
entre elas.
A técnica adotada nesta aula pressupõe a existência do diagrama de casos de uso e as descrições textuais de cada caso de
onde serão derivadas as classes do negócio. O modelo de classes será re�nado e acrescido de outras até chegar ao nível em
que contenha as classes a serem implementadas na linguagem de programação, dando forma ao sistema elaborado para
paulatinamente usar e re�nar diversos diagramas da UML.
Nesse momento, porém, nossa atenção atém-se à derivação das classes de negócio (implementar suas necessidades).
Essas classes são derivadas dos casos de uso. No �nal, ainda aplicaremos nesta aula os conceitos expostos em seu projeto
de TCC.
Objetivos
Revisar elementos e relacionamentos do diagrama de classes;
Analisar a técnica de derivar classes a partir de casos de uso;
Aplicar os conceitos de técnica de derivação de classes em seu projeto de TCC.
Conceitos de diagrama de classes
O diagrama de classes é considerado por muitos o principal diagrama da UML. Trata-se também do mais utilizado por seus
usuários para a modelagem de seus sistemas orientado a objetos. Esse diagrama descreve, de forma grá�ca, os tipos de:
• Objetos que interagem para realizar as funcionalidades previstas no sistema;
• Relacionamentos estáticos entre os objetos.
O diagrama evolui à medida que o projeto avança. Em sua primeira versão, na fase de
análise, ele apresenta as classes do negócio (também chamadas de entidades) e é
compatível com as funcionalidades dos casos de uso. Seu nome é diagrama de classes
conceitual.
Classe
É uma abstração da realidade, representando algo do mundo real. Uma classe é representada por um compartimento contendo
três partes.
• Classe: Nome da classe (cliente);
• Atributos: Dados que se retém da classe (nome e matrícula);
• Operações: Procedimentos que a classe executa para prestar seu serviço ao sistema, como os métodos Criar (), Destruir () e
Incluir Cliente ().
Classe x objeto
A classe é o molde de um conjunto de objetos a�ns, ou seja, com as mesmas características (atributos e métodos). Um objeto é
uma instância de uma classe.
Veja a seguir a imagem de um objeto especí�co (José) pertencente à classe Cliente.
Visão geral do diagrama de classes e seus elementos
A �gura a seguir ilustra um diagrama conceitual contendo apenas classes de negócio.
 Fonte: (FOWLER, 2005)
Classes com seus atributos e operações
Um atributo descreve uma propriedade estrutural da classe, um dado relevante que desejamos armazenar. Segundo a UML, a
forma mínima de representar um atributo é: visibilidade Nome: tipo.
Conforme mostra a �gura a seguir, a classe Disciplina tem quatro atributos. Vejamos o atributo Código:
• O sinal menos (-) antes do nome é a visibilidade, o que explicaremos adiante;
• Código é o nome do atributo;
• String é o tipo de dado do atributo.
Uma operação de classe é representada pelo método, um procedimento ou função da classe. Segundo a UML, a forma mínima de
representar um método é: visibilidade Nome (Lista de parâmetros): tipo.
A classe Disciplina da �gura a seguir tem quatro métodos. Vejamos o método RecuperaCreditos(Cod:int):int:
• O sinal mais (+) antes do nome é a visibilidade, que explicaremos adiante;
• RecuperaCreditos é o nome do método;
• (Cod:int) é a lista de parâmetros, composta, no caso, de apenas um parâmetro (Cod é o nome do parâmetro; int, o tipo de dado
dele);
• Int é o tipo de dado que RecuperaCreditos retorna.
Atenção
Observe que, em três métodos, o tipo de dado é void. Isso signi�ca que esses métodos não retornam um tipo de dado. Eles não
são uma função, e sim um procedimento.
Associação entre classes
Associação é o mais simples e comum relacionamento entre as classes. Ocorre entre uma, duas ou mais classes distintas, não
correlatas e independentes. Ao �nal do relacionamento, as classes permanencem com suas vidas próprias.
Na imagem a seguir, o relacionamento de associação está evidenciado por uma linha sólida que conecta as duas classes: Cliente
e Pedido.
Uma associação pode ser feita com a mesma classe. No processo chamado de autoassociação ou associação unária, uma
classe se relaciona com ela própria. Já na próxima �gura, Disciplina tem como pré-requisito outra disciplina:
É possível que tenhamos relacionamentos com três ou mais classes conforme ilustraremos a seguir:
Multiplicidade nos relacionamentos
Indica quantos objetos de cada classe participam do relacionamento.
Exemplo de multiplicidade: relacionamento entre Cliente e Pedido. Nele, um cliente faz um pedido. Analisemos a multiplicidade de
cada um dos dois lados do relacionamento.
• Cliente: O cliente pode realizar nenhum ou vários pedidos;
• Pedido: O pedido pertence a 1 (e somente 1) pedido.
Observe que destacamos a multiplicidade das duas classes nas �guras a seguir. Na primeira imagem, ela aparece do lado de
Pedido; na segunda, de Cliente:
Podemos veri�car agora a imagem completa do relacionamento com as multiplicidades em ambas as classes:
As possíveis multiplicidades são:
Visibilidade Comentários
+ Publico Qualquer classe pode usar o método ou o atributo.
- Privado Apenas a própria classe pode usar o método ou o atributo.
~ Pacote Apenas classes dentro do pacote podem usar o método ou atributo.
# Protegido Apenas as subclasses (herança), ou classe especializada, podem usar o atributo ou método.
Multiplicidade Significado
1 Exatamente 1 (um).
1..* Um ou vários (muitos).
0..* Nenhum (zero) ou vários (muitos).
* Muitos. A leitura é nenhum (zero) ou vários (muitos).
0..1 Nenhum (zero) ou 1 (um).
m..n Faixa de valores. Exemplo : 1 a 3 , 4 a 7 ou 6 a 11.
Avaliemos agora a �gura a seguir. Ela indica uma competição de natação em que cada bateria pode ter de 2 a 8 nadadores. Além
disso, cada nadador pode participar em uma ou várias baterias:
Visibilidade de atributos e métodos
Diz respeito ao que as classes podem ver de outras. A ideia é que cada classe tenha elementos privados e públicos.
Público
Pode ser visualizado e usado por qualquer outra classe.
Privado
Só pode ser usado pela classe proprietária.
A UML permite que sejam rotulados atributos e métodos de uma classe com indicador de visibilidade. Em todos os exemplos
vistos até aqui, usamos as visibilidades públicas (sinal de mais +) para os métodos e as privadas (menos -) para os atributos. A
UML fornece quatro possibilidade de visibilidade:
Podemos destacar algumas diretrizes relevantes sobre visibilidade:
1
Um dos princípios básicos da orientação a objetos, o encapsulamento diz que os atributos de uma classe não devem ser
usados por outras, e sim apenas por métodos da própria classe. A conclusão é que os atributos devem ser classi�cados
com visibilidade privada (sinal -).
2
Uma classe deve prestar serviço às demais através de seus métodos. Pelo menos um dos métodos da classe deve ter
visibilidade pública para que as demais classes possam usá-lo.
3
Em um relacionamento de generalização/especialização, se quiser que todos os atributos e métodos sejam herdados
pela classe especializada (subclasse), ambos devem ter visibilidade protegida na classe geral (superclasse).
Outros relacionamentos entre classes
Os relacionamentos representam os mais relevantes elementos de um diagrama de classes. Estudaremos os relacionamentos
mais usados na modelagem de classes. Além das associações, são possíveis os seguintes relacionamentos:
Classes de associação
Generalização/
especialização
Agregação e composição
Dependência
Veja a seguir cada um deles:
Classes de associação
É uma classe que surge do relacionamento de associação entre outras duas classes.
Suponha que um Leitor (classe) de uma biblioteca solicite o empréstimo de um Exemplar de Livro (outraclasse). Nesse momento,
surge a necessidade de armazenar os seguintes atributos:
1
Data de empréstimo
2
Data de devolução
3
Método para registrar o empréstimo
4
Método para a devolução
5
Método para tratar multa em caso de atraso
na devolução
Tais atributos e métodos não podem ser associados à classe Leitor nem à Exemplar de Livro, pois eles não dizem respeito a elas
(duas classes). Surge então uma nova classe (Empréstimo) como consequência da associação entre Leitor e Exemplar de Livro:
ela deverá armazenar todos os atributos e métodos derivados dessa asssociação.
O relacionamento é representado por reta pontilhada, a partir de uma associação entre duas classes, conforme a imagem a
seguir. Ela ilustra esse relacionamento entre classes:
Generalização/especialização
Implementa o conceito de herança com reaproveitamento de código. Uma classe mais geral se relaciona com outra mais
especí�ca (herdada), que herda todas as características (atributos e métodos) permitidos da classe mais geral.
1
Mais geral: Superclasse
2
Mais especí�ca: Subclasse
A imagem a seguir ilustra o relacionamento de generalização/especialização. Seu exemplo típico envolve clientes (pessoas físicas
e jurídicas) com diferenças e semelhanças. Seu agrupamento obedece ao seguinte método:
1
Semelhanças (classe mais geral)
2
Cliente (superclasse)
3
Diferenças (subclasses e pessoas física e
jurídica)
Na imagem, esse relacionamento aparece representado por uma reta cuja seta (sem preenchimento na ponta) aponta para a
classe mais geral.
Agregação e composição
Esses dois relacionamentos são do tipo todo-parte.
Clique nos botões para ver as informações.
Relacionamento mais forte, em que podemos prever a ocorrência simultânea das seguintes características:
• Embora uma classe possa ser um componente de muitas outras classes, toda instância deve ser componente de apenas
um proprietário. Teremos, portanto, a cardinalidade 1 do lado do objeto todo (proprietário). Os objetos parte somente podem
pertencer a um único objeto todo;
• Se o todo for excluído, todos os objetos parte devem ser também. Quando o todo morrer, todos os objetos parte também
morrerão. As vidas do todo e das partes são coincidentes.
Composição 
Quando, em um relacionamento todo-parte, as duas propriedades acima não forem identi�cadas.
Agregação 
A constatação de que o relacionamento é uma agregação ou composição deriva da análise das duas características descritas
acima. Ambos são representados pelas seguintes �guras:
• Agregação: Losango (ou diamante) sem preenchimento do lado do objeto todo;
• Composição: Mesmo elemento, porém colorido de preto, também do lado do objeto todo.
As �guras a seguir ilustram cada um dos relacionamentos. A primeira delas mostra um
relacionamento de agregação entre as classes Prova e Questões; a segunda, entre as
classes Pedido e Itens de Pedido. Analisemos cada um desses relacionamentos à luz das
duas características descritas para explicar por que elas são agregação e composição.
Por que o relacionamento entre Prova e Questões é uma agregação?
• O objeto parte Questões pode pertencer a mais de um todo, uma vez que uma questão pode ser parte integrante de mais de uma
(várias) prova(s);
• Quando uma prova deixar de existir, as questões nela contidas podem (e devem) continuar existindo para serem usadas em
outras provas. Logo, a vida das partes não é coincidente com a vida do todo.
Dica
Como nenhuma das propriedades foi analisada como verdadeira, concluímos que o relacionamento entre Prova e Questões não
se trata de composição, e sim de agregação.
Por que o relacionamento entre Pedido e Itens Pedido é uma composição?
• O objeto parte Itens Pedido não pode pertencer a mais de um todo, pois aquele item é daquele pedido e não poderá estar em
outro.
• Quando um Pedido deixar de existir, não fará sentido os seus itens permanecerem ativos, vivos. Portanto, quando o Pedido (todo)
morrer, os Itens Pedido (parte) também morrem.
Dica
Como as duas características foram analisadas como verdadeiras, podemos concluir que o relacionamento entre Pedido e Itens
Pedido é uma composição.
Embora as duas características ajudem muito a elucidar a dúvida sobre qual dos dois relacionamentos é o mais apropriado,
devemos sempre analisar o contexto para entender como se relacionam os itens todo e parte.
Atenção
A composição é um relacionamento que diz muita coisa a quem vai implementar as classes na linguagem de programação, pois
orienta que a criação e destruição das partes está condicionada à vida do todo. Já a agregação não tem essa particularidade: ela
poderá, se assim for desejado, ser substituída por uma associação simples, já que não tem grandes valores semânticos, a não ser
explicitar uma relação todo-parte.
Dependência
A dependência entre duas classes existe se mudanças na de�nição de uma classe puderem demandar mudanças na de�nição da
outra. Dependências podem ser evidenciadas quando uma classe:
• Tem outra classe como parte de seus dados;
• Menciona outra classe como parâmetro na chamada de método.
Se a interface da classe dominante muda, as mensagens enviadas podem não ser mais válidas, requisitando alterações na classe
dependente.
Exemplo
Em modelagem UML, veremos muitas dependências, mas você deve ser seletivo e modelar dependências apenas quando elas
forem relevantes para o contexto especí�co de sua aplicação. Um dos usos mais comuns de dependência é na modelagem de
um relacionamento transitório cujo objeto é passado para outro como parâmetro.
A imagem a seguir ilustra um relacionamento de dependência entre as classes Estudante e Disciplina. A dependência está
representada por uma seta pontilhada que sai da classe dependente. Portanto, no relacionamento abaixo, Disciplina depende de
Estudante.
Observe ainda o método Incluir da classe Disciplina: ele usa como parâmetro o objeto aluno, que é da classe Estudante. Isso
signi�ca que qualquer mudança na interface (assinatura) de Estudante poderá afetar a classe Disciplina.
Nome do relacionamento e papel nos relacionamentos
Conforme a �gura a seguir demonstra, pode ser dado um nome ao relacionamento (no caso, Faz). Podemos destacar na �gura os
seguintes itens:
Com o sentido da leitura determinado pela seta, que nos indica como se deve ler, seu resultado �nal é: Cliente Faz Pedido. Seu
uso é opcional.
Nome do relacionamento entre Pedido e Itens Pedido. A seta apontada para Itens Pedido indica que a leitura é nesta direção:
Pedido possui Itens Pedido.
Papel que Cliente tem no relacionamento entre Cliente e Pedido.
Cada um dos seus itens.
Papel que tem no relacionamento entre Pedido e Itens Pedido.
Navegabilidade nos relacionamentos de associação
Observe o diagrama de classes (imagem a seguir) no qual está sendo representada a navegabildade da associação entre as
classes Cliente e Endereços. O simbolo é a seta colada na classe Endereços.
A interpretação a ser feita é:
• O Cliente sabe quais são seus endereços;
• Apesar disso, o endereço não sabe a quais clientes pertence;
• A classe Cliente poderá enviar mensagens à classe Endereços, mas o contrário não ocorre;
• Essa é uma notação semântica que ajuda muito na implementação.
Derivando diagramas de classes dos casos de uso
A empresa Faixa Amarela Ltda. confecciona faixas de anúncios ou outras �nalidades por encomenda. Como os pedidos vêm
crescendo, seu Pereira, proprietário da grá�ca, encomendou um sistema que controle suas atividades compreendidas
basicamente por controle, acompanhamento dos pedidos e cadastramento de seus clientes.
Caso de uso Descrição
Consultar pedidos do
período
Permitir que sejam consultados todos os pedidos de um período informado pelo usuário.
Cadastrar cliente Registrar os dados cadastrais dos clientes que realizam seus pedidos.
Registrar pedido Registrar os pedidos de faixa feitos pelos clientes.
Registrar entrega do
pedido
Sinaliza que o pedido foi entregue ao cliente, devendo haver mudança do estado do pedido nesse momento.
Registrar início da
produçãoA fábrica deve sinalizar a data em que a produção foi iniciada e confirmar a data de entrega, devendo haver
mudança de estado do pedido nesse momento.
Registrar fim da
produção do pedido
Sinaliza que a produção da faixa chegou ao fim, devendo haver mudança do estado do pedido nesse
momento.
Consultar clientes sem
pedido
Relaciona todo cliente que não faz pedido há mais de 6 meses (com base na data corrente).
Confirmar recebimento
de sinal
Confirmar que o cliente pagou o sinal, sendo a base para o cálculo da data de entrega do produto. Deve
haver mudança de estado do pedido nesse momento.
Caso de uso Classe nova Método de qual classe
Cadastrar cliente Cliente Cadastrar cliente
Registrar pedido Pedido Incluir pedido
Confirmar recebimento de sinal Pedido Receber sinal do pedido
Registrar início de produção Pedido Iniciar produção
Registrar fim da produção do pedido Pedido Finalizar produção
Registrar entrega do pedido Pedido Entregar pedido
<< Include >> Pesquisar pedido Pedido Pesquisar pedido
Consultar clientes sem pedido Pedido Relação clientes sem pedido
Consultar pedidos do período Pedido Relação de pedidos
Considere ainda uma breve descrição da �nalidade de cada caso de uso:
O diagrama conceitual de classes pode ser extraído dos casos de uso. De uma forma simpli�cada, casos de uso podem ser:
• Classes;
• Métodos de classes.
Analisando os casos de uso, temos:
Considere ainda uma breve descrição da �nalidade de cada caso de uso:
Classe Atributos
Cliente Nome, CNPJ, rua, número, complemento, bairro, cidade, CEP, telefone residencial, telefone comercial, telefone
celular, e-mail e status.
Pedido Data do pedido, tamanho da faixa (altura e largura), texto a ser escrito na faixa, cor da faixa (amarela, preta ou
branca), cor do texto (branco, preto, azul ou vermelho), previsão de entrega, valor do serviço e valor do sinal
(50% do valor total do serviço).
Classes envolvidas: Cliente e Pedido;
Relacionamento entre as classes: Associação;
Papel do relacionamento: Cliente Faz Pedido.
Já a cardinalidade do relacionamento está assim dividida:
1 Cliente faz * pedidos;
1 Pedido é de 1 Cliente.
Teremos então:
1 do lado Cliente;
0..* do lado Pedido.
Atributos das classes identi�cados nas especi�cações dos casos de uso
Um erro muito comum em diagrama de classes é a confusão que se faz com tabelas (de bancos de dados relacionais), usando os
conceitos de chave primária e chave estrangeira em relacionamentos 1:* ou *..*. Esse conceito não existe em diagrama de
classes.
Classe e tabela são bem distintos nesse sentido. A classe deve conter apenas os atributos que pertençam a ela e que a
identi�quem enquanto classe. Analisemos a tabela a seguir tendo em vista o exemplo da grá�ca de faixas:
Já temos aqui o primeiro problema nos dados destacados em negrito. Foi dito que cada pedido poderia conter mais de uma faixa
a ser produzida (hoje são até 5 faixas por pedido). Isso signi�ca que os dados em destaque deverão ser armazenados 5 vezes ou
mais (caso a produção cresça no futuro). Podemos inferir daí as seguintes conclusões:
Isso acarreta uma anomalia de armazenamento de atributos, pois deveríamos possuir 5
vezes cada dado de 1 faixa. Esses dados poderiam não ser usados sempre, causando
desperdício de armazenamento e uma estrutura pouco ortodoxa
Percebe-se, nesse momento, a necessidade de uma nova classe chamada de Faixas Pedido.
Relacionada à classe Pedido, ela armazenaria todos os dados das faixas de um pedido. Tal
solução resolve em de�nitivo também o problema da quantidade de faixas por pedido (que
hoje é de cinco, mas amanhã ela pode tanto aumentar como diminuir). Dessa forma, o
pedido pode ter quantas faixas forem necessárias.
Surge, então, a necessidade da classe Faixas Pedido:
Atenção
Como estamos ainda na fase de modelagem conceitual de classes, podemos perfeitamente dizer que o relacionamento entre
Pedido e Itens Pedido é uma associação, deixando para uma modelagem mais adequada o momento do diagrama de classe de
projeto.
Esse cuidado não impede de nos exercitarmos no tema. Poderemos, portanto, estabelecer o
relacionamento mais correto semanticamente falando.
Classe Atributos
Cliente Nome, CNPJ, rua, número, complemento, bairro, cidade, CEP, telefone residencial, telefone comercial, telefone
celular, e-mail e status.
Pedido Data do pedido, previsão de entrega, valor do serviço e valor do sinal.
Faixas Pedido Altura, largura, texto, cor da faixa, cor do texto e valor da faixa.
Atividade
1. Podemos dizer que o relacionamento entre Pedido e Faixas Pedido é de todo-parte.
a) Trata-se de agregação ou composição?
b) As faixas de pedido têm vida própria? 
c) Ao excluir um pedido, as faixas desse pedido continuarão existindo? 
d) As faixas do pedido serão criadas pelo objeto Pedido? 
e) Qual a cardinalidade do relacionamento?
• Um Pedido pode conter N faixas;
• Uma faixa somente pode ser de um Pedido.
Inclusão de Itens Pedido no diagrama de classes
Voltamos aos atributos das classes para analisar agora as especi�cações de casos de uso. Vejamos a tabela �nal com os
atributos de cada classe apresentados a seguir:
Classe Atributos
Confirmar recebimento de sinal Data Pago Sinal
Valor Pago Sinal
Registrar início de produção Data Início Produção
Registrar fim de produção Data Fim Produção
Data Entrega
Registrar entrega do pedido Data Real Entrega
A análise de algumas especi�cações de casos de uso nos indica novos atributos conforme apresenta a imagem a seguir:
Atenção
Cabe analisar com os usuários, de forma profunda, a real necessidade de termos na classe os pedidos Data Pago Sinal (uma
previsão) e Valor Pago Sinal (o que foi realizado). Se for necessário, eles devem ser mantidos. Caso contrário, basta 1 dos 2
atributos. Qualquer um deles deve ser mantido caso o valor calculado do sinal possa, em um caso que seja exceção, ser diferente
daquele pago pelo cliente como sinal do pedido.
Poderemos então considerar, diante das incertezas apontadas, que o modelo acima
representa uma versão parcial do modelo conceitual de classes. Devemos destacar
ainda os métodos com base nos casos de uso, embora eles ainda precisem ser mais
bem investigados com a elaboração dos diagramas e sequência. Isso nos daria a
certeza das responsabilidades de cada classe e que métodos devem ser adicionados a
cada uma delas.
Numa análise inicial, com base nos casos de uso, teríamos a seguinte responsabilidade para cada classe:
Caso de uso Classe Nome dos métodos
Cadastrar cliente Cliente Cadastrar ou Incluir
Registrar pedido Pedido Incluir Pedido
Registrar início da produção Pedido Iniciar Produção
Registrar fim da produção Pedido Finalizar Produção
Registrar entrega do pedido Pedido Entregar Pedido
Confirmar recebimento de sinal Pedido Receber Sinal
Inicialmente, não alocaremos as duas consultas como métodos, o que será feito após a análise do diagrama de sequência dos
respectivos casos de uso. A versão do diagrama conceitual de classes acrescida dos atributos extraídos dos casos de uso seria
esta:
Diagrama conceitual de classes de seu TCC
Com base no exposto nesta aula, sua tarefa é a seguinte: derivar as classes e montar o diagrama conceitual delas com base no
diagrama de casos de uso e em suas especi�cações textuais.
 Fonte: Shutterstock
Atividade
2. A partir dos pares de classes, indique o melhor relacionamento entre as classes de cada par.
I. Pedido e item pedido.
II. Disciplina e professor.
III. Funcionário e gerente.
IV. Prova e questão.
a) I. Composição; II-Associação; III-Generalização/especialização; IV-Agregação.
b) I. Agregação; II-Associação; III-Generalização/especialização; IV-Composição.
c) I. Classe de associação; II-Agregação; III-Generalização/especialização; IV-Composição.
d) I. Composição; II-Dependência; III-Generalização/especialização; IV- Agregação.
e) I. Agregação; II-Dependência; III-Generalização/especialização; IV- Agregação.
3. Considere o funcionamento de uma clínica oftalmológica que seja totalmente manual. Uma clínica precisade um sistema de
agendamento de consultas e exames:
1. Um paciente contata a clínica por telefone ou pessoalmente e solicita a marcação de uma consulta com seu médico de
preferência, informando data e hora desejadas.
2. A atendente veri�ca na agenda do médico a disponibilidade mais próxima de data e hora e marca a consulta.
3. Na data e hora agendadas, o paciente realiza a sua consulta em que o médico pode solicitar exames e prescrever
medicamentos.
4. Após a consulta ao paciente, ele solicita à atendente a marcação de seus exames, informando data e hora pretendidas. A
atendente veri�ca a disponibilidade do médico e agenda o exame para o paciente.
5. A qualquer momento, o paciente pode solicitar o cancelamento não apenas da consulta mas também do exame.
Com base no enunciado, pedimos:
• De�nição dos requisitos;
• Diagrama de casos de uso.
4. Considerando os requisitos e casos de uso da atividade 2 acima, elabore o diagrama conceitual de classes.
Referências
BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML - Guia do Usuário. 2.ed. Rio de Janeiro: Elsevier, 2005. cap. 1 e 2.
FOWLER, Martin. UML Essencial - Um Breve Guia Para a Linguagem-Padrão. 3.ed. Porto Alegre: Artmed, 2005. cap. 1.
LARMAN, Craig. Utilizando UML e Padrões? Uma Introdução à Análise e ao Projeto Orientados a Objetos e ao Processo
Uni�cado. 3.ed. Porto Alegre: Artmed, 2007. cap. 2.
Próxima aula
Revisão dos elementos e construção do modelo conceitual de dados;
Aplicação em seu projeto de TCC: construção do modelo conceitual de dados.
Explore mais
Para complementar os assuntos estudados nesta aula, não deixe de ler o material indicado:
O que são os diagramas de classe <https://www.devmedia.com.br/orientacoes-basicas-na-elaboracao-de-um-diagrama-de-
classes/37224> .
https://www.devmedia.com.br/orientacoes-basicas-na-elaboracao-de-um-diagrama-de-classes/37224