Projeto Integrador Transdisciplinar em Banco de Dados II

(11) 9 1467-6527
(11) 9 1467-6527
Olá, estudante! Somos a Colaborar Educacional e podemos te ajudar nessa atividade!
Conteudista: Prof. Me. Artur Marques
Revisão Textual: Prof.ª Dra. Selma Aparecida Cesarin
Material Teórico
Material Complementar
DESAFIO
Situação-Problema 1
Projeto Integrador Transdisciplinar em Banco de
Dados II

Atividade de Entrega
REFERÊNCIAS
Referências

 Atenção, estudante! Aqui, reforçamos o acesso ao conteúdo
onlinepara que você assista à videoaula. Será muito importante para o
entendimento do conteúdo.
1 / 8
Material Teórico
Olá, estudante!
Vamos iniciar a disciplina abordando os conceitos necessários
para que você possa realizar a atividade através das situações-
problema mais à frente.
Introdução
Extrair classe de requisitos ágeis a partir de cartões de história do usuário pode ser simples para
quem já tem prática e está acostumado no dia a dia de trabalho. Porém, diﬁcilmente você
aprenderá

Domain-Driven Design
CRC
isso em Disciplinas normais ou até mesmo em Cursos por aí que prometem muito.
Nesta Disciplina, você vai entender com exemplos como podemos fazer isso e sairá na frente em
qualquer processo seletivo. Podemos garantir.
Vamos conhecer, então, como as técnicas e as Metodologias modernas são utilizadas. A ideia aqui,
então, é trabalhar com requisitos ágeis e depois com a extração de classes, para que você entenda
de onde vem as tabelas que você usa quando modelam um Banco de Dados.
Vamos conhecer algumas definições rápidas de técnicas, que veremos:
Modelagem de caso de uso: é uma maneira de capturar requisitos funcionais e podem
ser usados para extrair classes. Um caso de uso representa uma interação específica
entre um usuário (ator) e o sistema. Ao analisar os cenários de caso de uso, é possível
identificar as principais entidades (classes) envolvidas e seus relacionamentos;
(DDD): é uma abordagem que se concentra na compreensão do
domínio ou espaço do problema do software. Ele enfatiza a colaboração entre
especialistas do domínio e desenvolvedores. Com o DDD, você pode identificar
classes mapeando conceitos de domínio para as histórias de usuários. Essas classes
normalmente representam entidades-chave, objetos de valor, agregações e serviços
dentro do domínio;
Mapeamento de histórias de usuário: é uma técnica que ajuda na visualização e na
organização de histórias de usuários. Ao criar um mapa histórico de usuário, você pode
identificar histórias de usuários relacionadas e agrupá-las em atividades ou fluxos de
trabalho de Nível Superior. Esse processo pode revelar classes que estão envolvidas
na implementação dessas atividades ou fluxos de trabalho;
Cartões (Class-Responsability-Collaboration): são cartões físicos ou virtuais usados
para representar classes, suas responsabilidades e colaborações. Durante uma sessão
colaborativa, os membros da equipe podem criar cartões CRC com base em histórias de
usuários. Cada cartão representa uma classe, e as responsabilidades e colaborações
associadas a essa classe podem ser identificadas por meio de discussões e de
brainstorming;

Object-Oriented Analysis and Design
Leitura
Quer Entender Gherkin?
Clique no botão para conferir o conteúdo.
Behavior-Driven Development (BDD): é uma metodologia ágil que enfatiza a colaboração
entre desenvolvedores, testadores e partes interessadas do negócio. Os cenários BDD,
escritos em uma linguagem estruturada como, por exemplo, Gherkin, descrevem as
interações do usuário com o sistema e os comportamentos esperados. Ao analisar
esses cenários, é possível identificar as classes envolvidas no cumprimento dos
comportamentos desejados;
(OOAD): é uma abordagem tradicional para o
desenvolvimento de software, que se concentra na identificação de classes, seus
atributos, métodos e relacionamentos. Ele envolve técnicas como análise de caso de
uso, diagramas de sequência e diagramas de classe para extrair classes de histórias de
usuários. Pode ser usado em projetos Ágeis ao lado de outras Práticas Ágeis.
Já percebeu que o desafio é grande não é mesmo? Porém, queremos ressaltar que a escolha da
técnica ou da metodologia depende do contexto específico e das preferências da Empresa, ou até
mesmo da equipe. Isso envolve maturidade e, claro, experiência.

Modelagem de Caso de Uso
Vamos, então, descrever os usos.
Modelagem de caso de uso é uma técnica poderosa usada no desenvolvimento de software para
capturar e entender os requisitos funcionais de um sistema. Ela fornece uma abordagem
estruturada para identiﬁcar as interações entre os usuários (chamados de atores) e o sistema,
ajudando a extrair as classes envolvidas.
Observe os exemplos apresentados a seguir.
Sistema de Compras On-line
Caso de uso: fazer pedido;
Ator: cliente;
Descrição: este caso de uso representa o processo de um cliente fazer um pedido em
um sistema de compras on-line;
Cenário Principal
O cliente navega no catálogo de produtos;
O cliente adiciona itens ao carrinho de compras;
O cliente analisa os itens no carrinho de compras;
O cliente fornece informações de envio e faturamento;
1
2
3
4

O sistema calcula o valor total;
O cliente confirma o pedido;
O sistema processa o pagamento;
O sistema envia uma confirmação do pedido para o cliente.
Classes Identificadas
Cliente: representa o cliente que interage com o sistema;
Produto: representa os itens disponíveis no catálogo de produtos;
Carrinho de compras: gerencia os itens adicionados pelo cliente;
Pedido: representa o pedido do cliente, incluindo informações de envio e faturamento;
Pagamento: processa as transações de pagamento;
Disparador: envia e-mails de confirmação de pedido para os clientes.
Nesse exemplo, podemos perceber nitidamente a forma como abstraímos as classes a partir dos
requisitos, gerando classes que, por sua vez, terão atributos como: Cliente (CPF, nome, CEP,
endereço, complemento, UF e cidade, entre outros). Você colocará os metadados referentes aos
atributos, por exemplo: CPF (campo alfanumérico, 10 caracteres, ou seja, XXXXXXXXXX – sem
mascaramento de ponto. Com mascaramento, ficariam 13 caracteres, ou seja, XX.XXX.XXX-XX. Assim
você vai construindo a modelagem conceitual do seu Banco, baseado nas classes e nos
relacionamentos possíveis, montando o diagrama ER, fazendo as cardinalidades e depois
normalizando as tabelas.
5
6
7
8

Plataforma de Mídia Social
Caso de uso: atualização de status de postagem;
Ator: usuário;
Descrição: este caso de uso representa um usuário postando uma atualização de status
em uma plataforma de mídia social.
Cenário Principal
O usuário insere o texto de atualização de status;
O usuário adiciona anexos de mídia (por exemplo, fotos e vídeos);
O usuário seleciona as configurações de privacidade (por exemplo, público, somente
amigos);
O usuário marca amigos ou adiciona informações de localização (opcional);
O usuário clica no botão "postar";
O sistema processa e salva a atualização de status;
O sistema atualiza o perfil e o news feed do usuário;
O sistema envia notificações aos usuários relevantes (se aplicável).
Classes Identificadas
1
2
3
4
5
6
7
8

Usuário: representa o usuário que interage com a Plataforma de Mídia Social;
Atualização de status: representa a atualização de status postada pelo usuário;
Anexo de Mídia: representa os arquivos de Mídia anexados;
Configurações de privacidade: gerencia as configurações de privacidade da atualização
de status;
Etiqueta: representa os amigos marcados na atualização de status;
Local: representa as informações de local associadas à atualização de status;
Perfil: armazena e gerencia informações de perfil de usuário;
Feed de notícias: atualiza e exibe conteúdo relevante para o usuário;
Notificação: trata da geração e envio de notificações.
Ao analisar as interações entre os atores e o sistema, conseguimos extrair classes que representam
entidades, comportamentos e colaborações necessárias para implementar a funcionalidade
desejada. Lembre-se de que esses exemplos são apenas ilustrações simplificadas e, em cenários
do mundo real, análises e refinamentos adicionais podem ser necessários.
(DDD)
Vamos ver como funciona o Domain-Driven Design (DDD) para extrair classes de requisitos, porém,
antes, vamos ver um pouco de DDD.
É uma abordagem de desenvolvimento de software que coloca forte ênfase na compreensão e
modelagem do domínio ou espaço de problema em que o software opera.
Dom
ain-DrivenDesign

O DDD se concentra na colaboração entre especialistas do domínio e equipes de desenvolvimento
para obter compreensão profunda do domínio de negócios. Ele incentiva o uso de uma linguagem
onipresente compartilhada que preenche a lacuna entre o jargão técnico e a terminologia de
domínio. Ao fazer isso, o DDD ajuda a criar um entendimento comum entre as partes interessadas,
permitindo uma comunicação eficaz e promovendo um melhor design de software.
No centro do DDD, está a noção de modelo de domínio, que representa os principais conceitos e
comportamentos do domínio. O modelo de domínio consiste em entidades, objetos de valor,
agregações e serviços que capturam a essência do domínio do problema. Esses blocos de
construção são identificados por meio de uma extensa análise de domínio e servem como base para
o design do software.
Certo. Vamos ver como isso ocorre na prática.
Sistema Bancário
Em um sistema bancário, o modelo de domínio pode incluir o seguinte:
Cliente: representa um indivíduo ou organização que detém uma conta;
Conta: representa uma conta bancária e seus atributos associados, como saldo e
número da conta;
Transação: representa uma transação financeira, incluindo detalhes como valor, data e
tipo de transação;
Depósito: representa um tipo específico de transação, que aumenta o saldo da conta;
Saque: representa um tipo específico de transação, que diminui o saldo da conta;
Transferência: representa um tipo específico de transação, que envolve a
movimentação de fundos entre contas;

Serviço de conta: fornece operações para gerenciar atividades relacionadas à conta,
como abrir uma conta, fazer depósitos ou saques e transferir fundos.
Plataforma de
Para uma plataforma de comércio eletrônico, o modelo de domínio pode incluir o seguinte:
Produto: representa um produto disponível para venda, incluindo atributos como nome,
descrição e preço;
Carrinho de compras: representa um contêiner temporário no qual os usuários podem
adicionar produtos para compra;
Pedido: representa a intenção de um cliente de comprar um ou mais produtos,
incluindo detalhes como endereço de entrega e informações de pagamento;
Pagamento: representa o processo de autorização e captura de pagamento para um
pedido;
Estoque: representa a disponibilidade de produtos no sistema, rastreando quantidades
e níveis de estoque;
Catálogo: fornece operações para procurar e pesquisar produtos;
Serviço de carrinho: lida com operações relacionadas ao carrinho de compras, como
adicionar ou remover produtos;
Serviço de pedidos: gerencia o processo de criação e o processamento de pedidos,
incluindo atualizações de estoque e processamento de pagamentos.
Certo. Vimos como funciona a produção dos macro requisitos, mas como extrair?
E-com
m
erce

Extrair um modelo de classe de requisitos usando DDD envolve analisar o domínio do problema,
identiﬁcar conceitos de domínio e mapeá-los para classes que encapsulam seu comportamento e
estado. Aqui estão dois exemplos reais para ilustrar como os modelos de classe podem ser
derivados de requisitos usando DDD.
Sistema de Gestão Hoteleira
Requisitos
Gerencia quartos de hotel, incluindo tipos de quarto, disponibilidade e preços;
Lida com reservas de hóspedes, check-ins e check-outs;
Providencia serviço de quartos para os hóspedes, incluindo pedidos, encomendas e
entregas;
Gere relatórios sobre taxas de ocupação, receita e feedback dos hóspedes.
Modelo de Classe Extraído
Quarto: representa um quarto de hotel com atributos como número do quarto, tipo e
disponibilidade;
Tipo de quarto: representa os vários tipos de quartos disponíveis, como individuais,
duplos ou suítes;
Reserva: representa uma reserva de hóspede com detalhes como datas de check-
in/out, quarto e informações do hóspede;
Hóspede: representa um hóspede com atributos como nome, informações de contato e
preferências;

Pedido: representa uma ordem de serviço de quarto, incluindo os itens, quantidades e
detalhes de entrega;
Relatório: representa vários tipos de relatórios, como taxa de ocupação, receita ou
feedback de hóspedes;
Hotel: representa a entidade geral do Hotel, gerenciando quartos, reservas, pedidos e
relatórios;
Serviço de quarto: cuida da gestão das operações de Serviço de Quarto, como pedidos
e entregas.
Plataforma de Aprendizagem a Distância
Requisitos
Gerencie cursos, incluindo criação, inscrição e acompanhamento de progresso;
Forneça fóruns de discussão para que os alunos interajam e façam perguntas;
Ofereça avaliações e questionários para avaliar o conhecimento dos alunos a partir de
suas matrículas;
Facilite sessões ministradas por instrutores e salas de aula virtuais;
Acompanhe o desempenho dos alunos e gere relatórios de progresso.
Curso: representa um curso educacional com atributos como título, descrição e
duração;

Aluno: representa um aluno inscrito em um curso, incluindo atributos como nome,
informações de contato e progresso;
Fórum de discussão: representa um fórum para os alunos interagirem e fazerem
perguntas, com recursos como tópicos e respostas;
Avaliação: representa uma avaliação ou questionário para avaliar o conhecimento do
aluno;
Instrutor: representa um instrutor ou professor associado a um curso;
Sessão: representa uma sessão conduzida por instrutor ou sala de aula virtual, incluindo
detalhes como data, hora e materiais;
Relatório de progresso: representa um relatório sobre o progresso de um aluno em um
curso;
Matrícula: gerencia a matrícula de alunos em cursos.
Perceba que os modelos de classe são derivados analisando os requisitos e identificando os
conceitos-chave de domínio e seus relacionamentos.
As classes capturam o comportamento essencial e o estado do sistema, permitindo um design
centrado no domínio.
Claro, os exemplos que expusemos aqui são simplificados e, em cenários do mundo real, análises e
refinamentos adicionais podem ser necessários, bem como a descoberta de novas classes.
Normalmente, os especialistas do domínio (analistas de negócios ou donos de produtos), partes
interessadas e equipes de desenvolvimento colaboram para refinar iterativamente os modelos de
classe e garantir que eles representem com precisão o domínio do problema (escopo e
detalhamento para a solução específica de software).

Mapeamento de Histórias do Usuário
Agora, vamos tratar da técnica de mapeamento de histórias do usuário, tipicamente um processo
ágil, lembrando-se de que se trata de uma técnica que permite que as equipes visualizem e
organizem histórias de usuários de forma estruturada, facilitando uma compreensão holística da
funcionalidade e da experiência do usuário do produto. Ele ajuda a criar um entendimento
compartilhado entre as partes interessadas e permite a priorização e o planejamento dos esforços de
desenvolvimento.
Essa técnica envolve a criação de uma representação visual, normalmente, na forma de um Mapa ou
Quadro de história, que retrata as histórias do usuário em um ﬂuxo lógico. O Mapa consiste em
linhas horizontais, que representam diferentes atividades ou ﬂuxos de trabalho do usuário, e colunas
verticais que representam os níveis de interação do usuário ou funcionalidade do sistema.
Figura 1 – Exemplo de Mapa de Histórias de Usuário
Fonte: Reprodução

#ParaTodosVerem: foto em cores de um quadro branco com post-its escritos em
Inglês contendo um Mapa de Histórias do usuário para um futuro sistema para
eventos e palestras. No topo dessa imagem, há 3 títulos em post-its azuis:
Participante, Anfitrião e Moderador. No segundo nível desse mapa, há 7 post-its
verde claro, sendo 3 pertencentes a Participante: Selecionar Evento, que tem,
abaixo dele, 3 post-its amarelos (selecionar eventos, buscar por localidade e buscar
por tipo de atividade). Ver detalhes do evento tem, abaixo dele, dois post-its
amarelos (ver detalhes básicos e ver os participantes) e Entrar no evento tem, logo
abaixo dele, mais 3 cartões (entrar como participante, pagar para afiliação e
pagamento/retirada). Mais ao centro, No cartão azul de anfitrião, temos mais 3
post- its verdes: Criar novo evento e, abaixo dele, em post-its amarelos (entrar nos
detalhes do evento, receber a aprovação e receber reprovação). Logo ao lado, há
outro post-it verde: Promoção do Evento e, logo abaixo, mais dois post-its amarelos
(compartilha no Facebook e compartilha no Twitter). Por fim, no lado mais à direita do
quadro, há o post-it azul Moderador, com um cartão verde Revisão de Eventos e
mais 3 post-its subordinados (buscar novos eventos, aprovar novo evento e rejeitar
novo evento). Fim da descrição.
A seguir, vamos dar alguns exemplos.
Aplicativo de Gerenciamento de Tarefas
Aqui, um aplicativo de gerenciamento de tarefas pode ter esta aparência:
Atividade/Fluxo de Trabalho: Criar Tarefa
Como usuário, quero poder criar uma tarefa;
Como usuário, desejo atribuir uma tarefa a um projeto ou categoria específica;
Como usuário, desejo definir uma data de conclusão para a tarefa;
Como usuário, desejo adicionar uma descrição ou detalhes adicionais à tarefa;

Como usuário, quero priorizar tarefas com base em sua importância;
Como usuário, desejo salvar ou enviar a tarefa criada.
Atividade/Fluxo de Trabalho: Exibir Tarefas
Como usuário, quero ver uma lista de todas as minhas tarefas;
Como usuário, desejo filtrar tarefas com base em seu projeto, data de conclusão ou
prioridade;
Como usuário, quero pesquisar tarefas específicas;
Como usuário, desejo exibir os detalhes de uma tarefa específica;
Como usuário, quero marcar uma tarefa como concluída.
Veja outra modelagem.
de Reserva de Viagens
Atividade/Fluxo de Trabalho: Pesquisar e
Selecionar Voos
Como usuário, quero pesquisar voos disponíveis com base em minhas datas e destinos
de viagem;
Como usuário, quero ver uma lista de resultados de pesquisa com opções de voos,
incluindo preços e companhias aéreas;
Site

Como usuário, quero filtrar e classificar os resultados da pesquisa com base em vários
critérios;
Como usuário, quero selecionar um voo preferido e ver mais detalhes;
Como usuário, quero escolher o número de passageiros e as preferências de assento;
Como usuário, quero adicionar voos selecionados ao meu itinerário ou carrinho de
compras.
Atividade/Fluxo de Trabalho: Reserva Completa
Como usuário, quero revisar os voos selecionados e o custo total;
Como usuário, quero inserir informações do passageiro e detalhes de contato;
Como usuário, quero fornecer detalhes de pagamento e concluir a reserva;
Como usuário, quero receber um e-mail de confirmação com os
detalhes da reserva;
Como usuário, quero ter a opção de cancelar ou modificar a reserva.
Vimos que o Mapa ajuda a visualizar e organizar as histórias de usuários em atividades ou fluxos de
trabalho significativos, separados por blocos de atividades, que podem ser facilmente
transportados para um quadro, usando post-its. Ele permite que as equipes tenham visão
abrangente da funcionalidade do produto, priorizem os esforços de desenvolvimento e identifiquem
quaisquer lacunas ou dependências.
Certo. Mas como transformar esses “requisitos” na forma de cartões em classes?

E-commercePlatform
Há uma receita!
Extrair um modelo de classe de requisitos usando o Mapeamento de História de Usuário envolve
identificar os substantivos e entidades mencionados nas histórias de usuário e mapeá-los para
classes que representam essas entidades.
Nos exemplos a seguir, ilustramos como ficará.
Histórias de Usuários:
Como cliente, quero procurar produtos por categoria;
Como cliente, quero adicionar produtos ao meu carrinho de compras;
Como cliente, quero visualizar e modificar os itens no meu carrinho de compras;
Como cliente, quero prosseguir para o checkout e fazer um pedido;
Como administrador, quero gerenciar o inventário de produtos;
Como administrador, quero acompanhar pedidos e atualizar seu status.
Modelo de Classe Extraído:
Cliente: representa um cliente com atributos como nome, e-mail e endereço;
Produto: representa um produto com atributos como nome, preço e quantidade;

Categoria: representa uma categoria ou classiﬁcação de produto;
Carrinho de compras: representa um carrinho de compras, que contém uma coleção de
produtos;
Pedido: representa um pedido feito por um cliente, incluindo detalhes como
informações do cliente e status do pedido;
Administrador: representa um administrador com privilégios para gerenciar o sistema;
Inventário: gerencia o estoque de produtos, incluindo atributos como quantidade
disponível e reabastecimento;
Status do pedido: representa os diferentes estados ou status de um pedido.
Histórias de Usuários
Como usuário, quero criar um post e compartilhá-lo com meus seguidores;
Como usuário, quero curtir e comentar posts de outros usuários;
Como usuário, quero seguir/deixar de seguir outros usuários para ver suas publicações
no meu feed;
Como usuário, quero visualizar meu perﬁl e atualizar minhas informações;
Como administrador, desejo gerenciar contas de usuário e lidar com relatórios.

Usuário: representa um usuário com atributos como nome de usuário, e-mail e senha;
Postagem: representa uma postagem criada por um usuário, incluindo atributos como
conteúdo, carimbo de data/hora e curtidas/comentários;
Comentário: representa um comentário feito por um usuário em uma postagem;
Seguidor: representa a relação entre os usuários, indicando quem está seguindo quem;
Perfil: representa o perfil de um usuário, contendo informações como biografia, foto
do perfil e configurações;
Administrador: representa um administrador com privilégios para gerenciar contas de
usuário e manipular relatórios;
Relatório: representa um relatório enviado por usuários, contendo detalhes sobre o
conteúdo ou o usuário denunciado.
Analisando as histórias de usuários e identificando os substantivos, as classes que representam as
entidades podem ser derivadas. Essas classes capturam os dados essenciais e o comportamento
necessário para implementar a funcionalidade necessária. O mapa de história do usuário permite
que as equipes visualizem as relações e as dependências entre as classes, auxiliando no
desenvolvimento de um modelo de classes coeso.
Cartões de Classe–Responsabilidade–Colaboração (CRC)
É uma técnica colaborativa usada em design de software orientado a objetos para identificar e
definir classes, suas responsabilidades e suas colaborações dentro de um sistema. Promove o
trabalho em equipe, incentiva a participação ativa e fornece uma representação visual da estrutura
do sistema.

Para construir isso, envolve a criação de cartões físicos ou digitais para representar classes em um
sistema.
Figura 2 – Colaborações entre cada objeto
#ParaTodosVerem: desenho em preto e branco mostrando um esquema circular
composto por 6 retângulos contendo dizeres em seu interior, conectados mediante
emprego de setas, ligando a saída de um retângulo, conectando-o a outro
retângulo, e assim sucessivamente, até completarem a conexão do último
retângulo. Começando de cima para baixo do retângulo, no topo desse esquema,
e indo no sentido da esquerda temos: retângulo superior: Objetos; próximo
retângulo: possuem; próximo retângulo: responsabilidades (o que o objeto
conhece + o que o objeto faz); no retângulo mais inferior na base do esquema
temos: precisam de; no primeiro retângulo da subida do esquema temos:
Colaboradores (o padrão de

cooperação (comunicação) entre objetos. Por ﬁm, o último retângulo: realizadas
por, que se liga à caixa inicial. E o ciclo recomeça. Fim da descrição.
Cada cartão contém o nome da classe, suas responsabilidades e suas colaborações com outras
classes. A técnica é normalmente conduzida em um ambiente de grupo, em que os membros da
equipe participam ativamente do brainstorming e da deﬁnição das classes.
Veja os exemplos a seguir.
Sistema de Gestão de Bibliotecas
Classe: Livro
Responsabilidades:
•Armazenar informações sobre o livro (título, autor, data de publicação etc.);
•Gerenciar o status de disponibilidade do livro;
•Permitir devoluções e empréstimos de livros.
Colaborações:
•Colabora com a classe biblioteca, para atualizar o status de disponibilidade;
•Colabora com a classe mutuário, para lidar com operações de devolução e
empréstimo.
Classe: Biblioteca

Responsabilidades:
•Gerenciar o acervo de livros;
•Manter o status de disponibilidade dos livros;
•Fornecer funcionalidades de pesquisa e recuperação.
Colaborações:
•Colabora com a classe livro, para atualizar a disponibilidade e recuperar informações
do livro;
•Colabora com a classe do mutuário, para lidar com o empréstimo e a devolução de
livros.
Classe: Mutuário
Responsabilidades:
•Cadastrar as informações do mutuário (nome, contato etc.);
•Lidar com empréstimos e devoluções de livros.
Colaborações:
•Colabora com a classe Livro, para empréstimos e devolução de livros;
•Colabora com a classe Biblioteca, para recuperar a disponibilidade do livro e atualizar
o status do empréstimo.
A técnica estimula a participação ativa, promove a discussão e o compartilhamento de conhecimento
e fornece uma representação visual da estrutura do sistema. Os Cartões CRC servem como

referência durante as fases de projeto e implementação, garantindo entendimento claro das classes
e suas interações dentro da solução de software.
Desenvolvimento Orientado ao Comportamento (BDD)
É uma metodologia de desenvolvimento de software que enfatiza a colaboração, a comunicação e
um entendimento compartilhado entre as partes interessadas, incluindo desenvolvedores,
testadores e representantes de negócios. Ele se concentra em deﬁnir os comportamentos e os
resultados desejados de um sistema de software por meio do uso de cenários escritos em linguagem
natural.
O BDD gira em torno do conceito de "comportamento" e usa linguagem estruturada, como Gherkin,
(leia o conteúdo no início desse texto para você aprender e para descrever o comportamento
esperado do sistema, de forma que possa ser entendido por partes interessadas técnicas e não
técnicas).
Figura 3 – Ciclo de trabalho BDD/TDD
Fonte: Reprodução
#ParaTodosVerem: ﬁgura com desenho colorido representando um esquema
mostrando o ciclo de trabalho entre o desenvolvimento orientado pelo
comportamento e sua associação com o desenvolvimento orientado por teste.
Para

Checkout
isso, é utilizada, no canto superior esquerdo, uma seta vermelho claro curva, no
intuito de formar a parte superior de um círculo na cor vermelha. Logo abaixo,
para fazer a parte inferior desse círculo, encontramos uma seta curva vermelho
escuro, no interior dessas duas metades, cujas setas superior e inferior formam o
nosso ciclo menor, que tem uma inscrição BDD. No canto superior esquerdo, mais
ao alto, temos uma caixa cujo contorno é azul escuro associado a esse ciclo BDD,
com os dizeres: Escrever recurso falho. Na diagonal, no sentido do canto inferior
direito, temos uma seta azul claro dobrada para formar um círculo fechado,
demonstrando que são necessários tantos ciclos quanto o número de iterações
focadas em entregar o que foi pedido. No canto superior direito desse círculo, em
azul, está escrito: n ciclos. No interior desse círculo azul claro, há um outro
componente do ciclo que se vale de três segmentos feito por setas, cada uma de
uma cor, dividindo o ciclo em três partes (azul escuro no topo, verde na lateral
direita e vermelho escuro na lateral esquerda). Os dizeres, na sequência, trazem
os seguintes textos: seta azul escuro: escrever teste falho; seta verde: escrever
código para passar no teste e na seta vermelha: refatoração. Fim da descrição.
O ciclo BDD passa pela escrita de um cenário de validação, automatizado, para, em seguida, a
criação dos testes de unidade, fazer o teste passar e por fim refatorar.
Ele promove uma abordagem colaborativa para o desenvolvimento de software, no qual
desenvolvedores, testadores e representantes de negócios trabalham juntos para definir e validar o
comportamento do sistema.
A seguir, vamos ver como fica isso em um exemplo simples.
Processo de (Pagamento no “Caixa”) de um Comércio Eletrônico
Cenário: Colocação Bem-sucedida do Pedido
Dado que um cliente selecionou itens para compra;
Quando o cliente procede ao pagamento no caixa virtual;

Em seguida, o cliente deve fornecer informações de envio e pagamento;
O sistema deve processar o pedido;
O cliente deve receber uma confirmação do pedido.
Nesse exemplo, o cenário descreve o comportamento do processo de pagamento no caixa virtual
do sistema de comércio eletrônico. Ele começa com o estado inicial (Dado), em que um cliente
selecionou itens para compra. As etapas subsequentes (Quando, então) descrevem as ações e os
resultados esperados do sistema. O cenário foca no comportamento desejado, enfatizando o que
o sistema deve fazer e os resultados esperados.
Ao escrever cenários em linguagem natural, o BDD facilita uma compreensão compartilhada dos
resultados esperados do software. Esses cenários servem como especificações executáveis que
orientam o processo de desenvolvimento e teste, garantindo que o software atenda aos
comportamentos e aos objetivos desejados.
Certo. Agora, vamos ver como podemos extrair classes desse modelo estruturado, o BDD. Porém,
isso envolverá analisar os comportamentos descritos nos cenários e identificar as entidades e suas
interações dentro do sistema, conforme apresentado a seguir.
Sistema Bancário
Cenário: Consulta de Saldo de Conta:
Dado que um cliente tem uma conta bancária;
Quando o cliente solicita uma consulta de saldo da conta;
Em seguida, o sistema deve recuperar o saldo da conta;

E o mostra ao cliente.
Cliente: representa um cliente com atributos como nome, número de conta e
informações de contato;
Conta bancária: representa uma conta bancária com atributos como número da conta,
saldo e tipo de conta;
Exibição: representa o componente da interface do usuário responsável por exibir
informações ao cliente.
Uma outra situação está apresentada a seguir.
Cenário: Pós-criação
Dado que um usuário está logado na plataforma de mídia social;
Quando o usuário cria uma postagem;
Em seguida, o sistema deve armazenar o conteúdo da postagem;
E o associa ao perﬁl do usuário.
1
2
3

Usuário: representa um usuário com atributos como nome de usuário, e-mail e senha;
Postagem: representa uma postagem com atributos como conteúdo, carimbo de
data/hora e curtidas/comentários;
Perfil: representa o perfil de um usuário, contendo informações como biografia, foto
do perfil e configurações.
Ao analisar os cenários, é possível identificar entidades ou classes, seus atributos e
responsabilidades. As classes capturam os dados essenciais e o comportamento necessário para
cumprir os requisitos.
Além disso, os cenários também podem indicar colaborações entre classes ou entidades, que
ajudam a determinar as relações e as dependências dentro do modelo de classe.
Análise e Projeto Orientado a Objetos (OOAD)
É uma abordagem de desenvolvimento de software que se concentra em modelar entidades do
mundo real como objetos e projetar sistemas de software com base em suas interações e
relacionamentos.
Envolve a análise e a compreensão dos requisitos do usuário, seguido pelo projeto de um sistema,
usando princípios orientados a objetos.

Figura 4 – As diferenças entre análise e projeto
#ParaTodosVerem: figura em preto e branco dividindo um retângulo em dois
quadrados mediante emprego de uma linha pontilhada central que os separa. Do
lado esquerdo, está escrito Análise. Na base desse primeiro quadrado, estão os
dizeres: Modelagem do problema (entender). Por outro lado, à direita, há o outro
quadrado, em cujo centro encontramos o nome Projeto. Na base desse quadrado,
temos os seguintes dizeres: Modelagem da solução (criar). E esses são os reais
significados e diferenças entre Análise (entendimento do problema) e Projeto (o
que farei para resolver esse problema). Fim da descrição.
O OOAD engloba duas fases principais:
Análise e projeto, que dá ênfase à compreensão do domínio do problema, à
identificação de entidades e à captura de requisitos;
Design, que se concentra na criação de uma solução definindo classes, seus
relacionamentos e seus comportamentos.

Um exemplo: sistema de gestão de bibliotecas
Fase de análise:
•Identificar entidades-chave: livros, usuários, bibliotecários;
•Requisitos de captura: empréstimo de livros, devoluções, pesquisa, cadastro de
usuários.
Fase de design:
•Identificar classes: livro, usuário, bibliotecário;
•Definir relacionamentos: usuário empresta livros, bibliotecário gerencia livros;
•Especificar comportamento: o livro pode ser verificado, devolvido e pesquisado por
vários critérios.
Você deve ter percebido que o uso dessa abordagem de problema envolve a criação de classes
que representam as entidades identificadas, determinando seus atributos e operações e
estabelecendo relações entre classes.
Essas classes encapsulam os dados relevantes e o comportamento necessários para atender aos
requisitos do sistema.
Seguindo os princípios de encapsulamento, herança e polimorfismo, essa abordagem permite a
criação de sistemas de software modulares e reutilizáveis. Enfatiza a representação de entidades
do mundo real como objetos e modelando suas interações dentro do sistema.
Como fazemos a extração de classes a partir dessa estrutura?

Vejamos como acontece se tivermos um sistema de entrega de refeições.
Sistema de Entrega de Comida
Requisitos
Os clientes devem ser capazes de navegar e pesquisar restaurantes disponíveis e seus
menus;
Os clientes devem poder fazer pedidos de comida;
Os restaurantes devem receber e processar os pedidos de comida;
O sistema deve acompanhar o status do pedido e fornecer atualizações aos clientes;
Os entregadores (motoboys) devem ser designados para a entrega de pedidos.
Modelo de Classe
Cliente: representa um cliente com atributos como nome, informações de contato e
histórico de pedidos;
Restaurante: representa um restaurante com atributos como nome, localização e itens
de menu;
Pedido: representa um pedido de comida com atributos como ID do pedido, itens,
detalhes do cliente e status;
Entregadores: representa a equipe de entrega com atributos como ID e disponibilidade;
On-
line

Entrega: representa uma entrega de comida com atributos como ID de entrega,
pessoal atribuído e status de entrega.
Então, como observamos, os modelos de classe são derivados analisando os requisitos e
identificando as principais entidades envolvidas no sistema. Cada classe representa uma entidade
distinta e encapsula os atributos relevantes e o comportamento associado a ela.
As relações entre as classes são estabelecidas com base nas interações e dependências descritas
nos requisitos.
Em suma, podemos escrever que o modelo de classe desempenha um papel crucial na formação da
estrutura e do comportamento do software. Ele fornece um plano para os componentes do sistema,
seus relacionamentos e suas interações.
Vejamos a importância e no que os modelos de classe e a posterior extração deles ajuda:
Abstração e encapsulamento: por exemplo, em um sistema de comércio eletrônico,
classes como produto, cliente e pedido encapsulam atributos e métodos relevantes
específicos para suas funções;
Reusabilidade e modularidade: por exemplo, no sistema de comércio eletrônico, a
classe Produto encapsula as informações do produto e pode ser reutilizada em
diferentes partes do sistema, como o catálogo, o carrinho de compras e o
gerenciamento de pedidos;
Relações e interações: por exemplo, no sistema de comércio eletrônico, a classe
Pedido pode ter associações com as classes cliente e produto, representando a relação
entre os clientes e seus pedidos, bem como os itens incluídos em um pedido;
Herança e polimorfismo: por exemplo, no sistema de comércio eletrônico, uma
hierarquia de classes pode incluir subclasses como Produto Especial ou Produto com
desconto herdando da classe Produto base, permitindo comportamento ou preços
especializados;

design
Padrões de e arquitetura: o modelo de classe orienta a aplicação de padrões de
projeto e ajuda na definição de componentes arquitetônicos, como camadas, módulos
ou serviços.
O modelo de classe fornece um esquema que orienta o processo de desenvolvimento, garantindo
que o sistema de software resultante esteja alinhado com os requisitos, seja sustentável e facilite
futuros aprimoramentos ou modificações.
Mas não pararemos por aqui, porque você agora já sabe como extrair classes de requisitos usando
diversos métodos, certo?!
Vamos trabalhar um exemplo prático baseada na última descoberta de classes que fizemos:
Modelo de Classe
Cliente: representa um cliente com atributos como nome, informações de contato e
histórico de pedidos;
Restaurante: representa um restaurante com atributos como nome, localização e itens
de menu;
Pedido: representa um pedido de comida com atributos como ID do pedido, itens,
detalhes do cliente e status;
Entregadores: representa a equipe de entrega com atributos como ID e disponibilidade;
Entrega: representa uma entrega de comida com atributos como ID de entrega,
pessoal atribuído e status de entrega.

Você vai perceber que inserimos uma entidade nova chamada item pedido, derivado da relação
cliente com o seu pedido.
Cliente
IDCliente (chave primária)
Nome
Informações de Contato
Histórico de Pedidos
Restaurante
IDRestaurante (Chave primária)
Nome
Localização
Pedido
IDPedido (chave primária)
IDCliente (Chave Estrangeira)
Data do pedido
Estado
Itempedido
IDItem (chave primária)
IDPedido (Chave Estrangeira)
IDProduto (Chave Estrangeira)
Quantidade

Produto
IDProduto (chave primária) IDRestaurante (Chave Estrangeira) Nome
Preço
Entregadores
IDEntregador (chave primária) Nome
Disponibilidade
Entrega
IDEntrega (chave primária) IDPedido (Chave Estrangeira) IDEntregador (Chave Estrangeira) StatusEntrega
Nesse modelo entidade-relacionamento, cada entidade do modelo de classe é representada como
uma tabela no Banco de Dados.
Os atributos de cada entidade tornam-se colunas nas respectivas tabelas.
As relações entre entidades são representadas usando restrições de chave estrangeira, que
estabelecem as associações entre tabelas.
As relações que inferimos foram as seguintes:

CREATE TABLE Cliente (
IDCliente INT PRIMARY KEY, Nome VARCHAR(50),
InformacoesContato VARCHAR(100), HistoricoPedidos VARCHAR(200)
);
CREATE TABLE Restaurante (
IDRestaurante INT PRIMARY KEY,
Um cliente pode ter vários pedidos, portanto, a tabela Pedido inclui uma chave
estrangeira fazendo referência à tabela Cliente;
Cada pedido pode conter vários itens de pedido, portanto, a tabela ItemPedido inclui
chaves estrangeiras que fazem referência às tabelas Pedido e Produto;
Cada produto pertence a um restaurante específico, portanto, a tabela Produto inclui
uma chave estrangeira que faz referência à tabela Restaurante;
As entregas estão associadas a pedidos e entregadores específicos, portanto, a tabela
Entrega inclui chaves estrangeiras que fazem referência às tabelas Pedido e Pessoal de
Entrega.
Esse modelo entidade-relacionamento fornece uma visão conceitual do banco de dados,
destacando as entidades, atributos e relacionamentos envolvidos no sistema de comércio eletrônico
de comida.
Como implementamos o SQL para aquelas ER que propusemos?
A seguir, está o código SQL no Oracle, sem muita sofisticação e padrões, para implementar o
modelo de entidade-relacionamento que desenvolvemos:

Nome VARCHAR(50),
Localização VARCHAR(100)
);
CREATE TABLE Pedido (
IDPedido INT PRIMARY KEY,
IDCliente INT,
DataPedido DATE,
StatusEntrega VARCHAR(20),
FOREIGN KEY (IDCliente) REFERENCES Cliente(IDCliente)
);
CREATE TABLE ItemPedido (
IDItemPedido INT PRIMARY
KEY, IDPedido INT,
IDProduto INT,
Quantidade INT,
FOREIGN KEY (IDPedido) REFERENCES Pedido(IDProduto),
FOREIGN KEY (IDProduto) REFERENCES Produto(IDProduto)
);
CREATE TABLE Produto (
IDProduto INT PRIMARY KEY,
IDRestaurante INT,
Nome VARCHAR(50),
Preço DECIMAL(10, 2),
FOREIGN KEY (IDRestaurante) REFERENCES Restaurante(IDRestaurante)
);
-- Create the Entregadores
table CREATE TABLE Entregadores
(
IDEntregadores INT PRIMARY
KEY, Nome VARCHAR(50),
Disponibilidade VARCHAR(20)
);
CREATE TABLE Entrega (
IDEntrega INT PRIMARY KEY,
IDPedido INT,
IDEntregador INT,
StatusEntrega VARCHAR(20),
FOREIGN KEY (IDPedido) REFERENCES Pedido(IDPedido),
FOREIGN KEY (IDEntregadores) REFERENCES Entregadores(IDEntregadores)
);

Observe que esse código SQL pressupõe o uso de tipos de dados apropriados para os atributos,
como INT para identificadores numéricos, VARCHAR para dados textuais, DATE para datas e DECIMAL
para preços. Além disso, esse exemplo criará as tabelas necessárias com suas restrições de chave
primária e chave estrangeira, estabelecendo as relações entre as entidades no modelo entidade-
relacionamento.
Com isso, fizemos todo o caminho, desde mostrar as técnicas de conversão de requisitos, até a
geração das classes, com exemplo para cada uma das técnicas, descrevemos um diagrama E-R e,
por fim, geramos o código SQL baseado no ORACLE-SQL para apresentar um exemplo.

2 / 8
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta disciplina:
VÍDEOS
Tutorial de Diagramas de Classes UML
Saiba como fazer classes, atributos e métodos neste tutorial de Diagrama de Classe UML.
Clique no botão para conferir o vídeo indicado.
Modelagem de Dados – Modelo Conceitual, Lógico e Físico
Aprenda a modelar banco de dados. Modelagem conceitual, modelagem lógica, modelagem física.
Clique no botão para conferir o vídeo indicado.

LEITUR
A
–
– Requisitos, Classes e Objetos
Neste Artigo, vamos conhecer um pouco mais sobre análise de requisitos, classes e objetos em UML.
https://bit.ly/3PpyYT3
Orientações Básicas na Elaboração de um Diagrama de Classes
Este Artigo orienta o estudante na elaboração de um diagrama de classe, procurando estabelecer,
de forma sintética, os principais pontos para a abstração dos objetos e classes de um cenário
especíﬁco.
https://bit.ly/3NJdUWx
UML Unifled Modeling Language

3 / 8
Caro(a), estudante.
Agora, vamos compreender o cenário que será abordado na
primeira situação-problema da disciplina.
Atente-se à situação profissional que você precisará entender
para poder realizar a atividade.
Imagine que você tenha sido contratado como desenvolvedor para modelar as classes de um
sistema de gerenciamento de estoque de uma loja de roupas. Esse sistema precisa atender a
diversas necessidades, como o cadastro de produtos, controle de estoque, emissão de relatórios de
vendas, além de possibilitar que os funcionários realizem vendas e cadastrem clientes. Essa loja
de roupas tem um amplo catálogo de produtos, incluindo peças de vestuário, acessórios e outros
itens relacionados à moda. Com um fluxo constante de vendas, é essencial garantir um controle
eficiente do estoque para suprir a demanda dos clientes. Atualmente, a loja enfrenta dificuldades
devido à ausência de um sistema automatizado de gerenciamento de estoque. Os processos
manuais utilizados não são eficientes, resultando em erros de contagem, atrasos na reposição de
produtos esgotados e dificuldades na identificação de itens em falta. Isso acarreta prejuízos
financeiros, insatisfação dos clientes e demanda excessiva de tempo e esforço dos funcionários para
realizar as

tarefas relacionadas ao controle de estoque. Um desafio adicional é o espaço físico limitado para
armazenar os produtos. A loja precisa otimizar o uso desse espaço, evitando perdas por
obsolescência ou danos aos itens estocados. Portanto, é necessário estabelecer um sistema de
gerenciamento de estoque que considere essa restrição e garanta a integridade e a qualidade dos
produtos.
Para a implementação desse sistema, a loja conta com uma equipe de funcionários capacitados e
dispostos a aprender o novo sistema de gerenciamento de estoque. Além disso, há recursos
financeiros disponíveis para investir em equipamentos tecnológicos e treinamento dos
colaboradores, a fim de assegurar a eficácia e o bom funcionamento do sistema.
Com base nesse contexto, sua tarefa como desenvolvedor é criar as classes necessárias para o
sistema de gerenciamento de estoque da loja de roupas, levando em consideração todas as
funcionalidades requeridas. Elabore a estrutura adequada, considerando as interações entre as
classes.

4 / 8
Vamos compreender o cenário que será abordado na segunda
situação-problema da disciplina.
Você foi contratado como o novo analista de sistemas da empresa Fatottodelacitá para resolver um
desafio crucial para a própria Empresa. O problema a ser solucionado envolve o desenvolvimento
de um sistema de gerenciamento de tarefas, com foco nas etapas de modelagem de classes e
modelagem de entidade-relacionamento.
Sua missão é projetar e implementar uma solução eficiente que permita o cadastro e controle de
tarefas, o acompanhamento de prazos, a emissão de relatórios de desempenho, além de facilitar o
registro do tempo gasto em cada tarefa e a alocação adequada das tarefas para os
desenvolvedores.
Nesse cenário desafiador, você terá um papel fundamental no projeto, aplicando seus
conhecimentos e habilidades como analista de sistemas para superar os obstáculos enfrentados
pela Empresa. Sua experiência será crucial na modelagem das classes e E-R para a construção de
um sistema automatizado que traga mais transparência, agilidade e eficiência ao gerenciamento das

tarefas. Além disso, a sua capacidade de entender as necessidades e as expectativas dos
diferentes envolvidos no processo será essencial para o sucesso do projeto.
Assim, você terá o desafio de projetar as classes e entidades-relacionamento necessárias, garantir
sua qualidade e eficiência. Seu objetivo final será entregar uma solução de modelagem que
otimize o trabalho da equipe de desenvolvimento, promovendo um aumento na produtividade.
Perceba que é uma oportunidade valiosa de desenvolvimento profissional, colocando em prática
seus conhecimentos de modelagem, aprendendo com desafios reais e contribuindo para o
sucesso da empresa Fatottodelacitá.

5 / 8
Por fim, vamos compreender o último cenário, abordado na
terceira situação-problema da disciplina.
Você foi contatada como a nova analista de requisitos para solucionar o seguinte desafio proposto
pelo empresário, fundador da Empresa: ele deseja criar um sistema de vendas on-line para sua loja
de roupas, porque sempre trabalhou com loja de rua, os tempos mudaram e ele precisa evoluir para
continuar sobrevivendo e sua loja existindo. Todavia, o empresário precisa superar a limitação de
vendas presenciais e expandir seu negócio para o ambiente on-line, oferecendo aos clientes a
possibilidade de visualizar os produtos disponíveis na loja e realizar compras pela Internet. O sistema
deve ser capaz de lidar com informações detalhadas sobre os produtos, como nome, descrição,
preço, tamanho e cor. Além disso, cada produto deve estar associado a uma categoria específica,
como camisetas, calças, sapatos etc. É necessário também manter um registro completo de todas
as compras feitas pelos clientes, incluindo os detalhes de cada pedido. A Empresa conta, além de
você, dois programadores e um especialista em Banco de Dados também contratados
recentemente e que não conhecem muito de modelagem, mas de execução somente. Com base
nessas

informações, você precisará entregar documentação importante para direcionar o desenvolvimento
e, para tanto, deverá seguir o exposto a seguir:
Identificar as classes necessárias para implementar o sistema de vendas on-line;
Criar um diagrama de classes que represente as classes identificadas, incluindo seus
atributos e associações;
Desenvolver um modelo de entidade-relacionamento, considerando as classes
identificadas e as informações contextualizadas.

Importante!
Apesar de os desafios serem semelhantes, seus enunciados levam em consideração
negócios completamente diferentes e que exigiram estudo desses negócios para que
você os entenda e os desenvolva.
6 / 8
Problema em Foco
Orientações para o Desenvolvimento de seu Projeto
Situação 1
É importante você compreender os obstáculos enfrentados atualmente pela loja, como
a falta de um sistema automatizado, erros de contagem, atrasos na reposição de
produtos e dificuldades de identificação de itens em falta;

A partir disso, você deverá definir a estrutura do sistema, identificando as principais
classes que serão necessárias. Recomenda-se a criação de classes como "Produto",
"Estoque", "Relatório", "Funcionário", "Venda" e "Cliente", conforme mencionado
anteriormente;
Você, poderá utilizar sua criatividade para determinar quais atributos e métodos serão
necessários em cada classe, considerando as funcionalidades requeridas pelo sistema.
Situação 2
Antes de começar o projeto, é fundamental que você entenda completamente o
problema em questão. Ao compreender os obstáculos enfrentados, você
poderá propor uma solução personalizada que aborde especificamente essas
questões;
Em seguida, concentre-se no levantamento de requisitos. Realize uma análise
minuciosa das necessidades e expectativas dos usuários finais, incluindo gerentes e
desenvolvedores. Identifique as funcionalidades essenciais que o sistema de
gerenciamento de tarefas deve ter, como cadastro de tarefas, controle de prazos,
emissão de relatórios de desempenho e alocação de tarefas. Defina a arquitetura do
sistema, identificando as classes e depois converta para as entidades-relacionamento
necessárias.
Sugere-se a construção das seguintes classes:
Tarefa: representa uma tarefa a ser realizada no sistema;
Desenvolvedor: representa um desenvolvedor que trabalha no sistema;
Gerente: representa um gerente responsável pelo gerenciamento das tarefas e dos
desenvolvedores;
Relatório: representa um relatório de desempenho do sistema.

Os atributos de cada classe são por sua conta.
Situação 3
Caros estudantes, aqui, há algumas dicas e direcionamentos para que você consiga
realizar essa atividade;
Análise de requisitos: compreenda completamente as necessidades do empresário e
dos potenciais clientes dele antes de sair modelando. Isso inclui entender a
visualização de produtos, o processo de compra, a categorização dos produtos, o
registro de compras e outros aspectos relevantes;
Identificação das classes e atributos: com base nos requisitos levantados, identifique as
classes necessárias para o sistema. Isso envolve definir as entidades principais, como
Cliente, Produto, Categoria, Carrinho de Compras e Pedido, e seus atributos
correspondentes, como nome, descrição, preço etc., para cada uma dessas classes e
outras que você encontrar durante a sua análise;
Diagrama de classes: crie um diagrama de classes que represente as classes
identificadas, incluindo os atributos e as associações entre elas. É importante definir
corretamente os relacionamentos, como a associação entre Cliente e Pedido, e
considerar a multiplicidade dessas associações;
Modelo de entidade-relacionamento: com base nas classes identificadas, você deverá criar um
diagrama de entidade-relacionamento (E-R) que represente a estrutura do Banco de Dados. Isso
inclui definir as entidades, seus atributos e os relacionamentos entre elas, como a associação entre
Produto e Categoria. Um software livre chamado BR modelo é muito útil.

7 / 8
Atividade de Entrega
Muito bem, estudante.
Agora que você já leu todas as situações-problema, você pode
fazer o download deste arquivo para realizar a atividade de
entrega.
Caso preﬁra, o arquivo também se encontra no Ambiente Virtual
de Aprendizagem.

 Muito bem, estudante! Vocêconcluiuo material deestudos! Agora, volteao
AmbienteVirtual deAprendizagempararealizar aAtividade.
8 / 8
Referências
PRESSMAN, R. Engenharia de software. 8. ed. Porto Alegre: AMGH, 2016.
#cruzeiro#cruzeiro
#cruzeiro#cruzeiro
#cruzeiro#cruzeiro
#cruzeiro#cruzeiro
#cruzeiro#cruzeiro
#cruzeiro#cruzeiro
#cruzeiro#cruzeiro
#cruzeiro#cruzeiro
#cruzeiro#cruzeiro
#cruzeiro#cruzeiro
#cruzeiro#cruzeiro
#cruzeiro#cruzeiro

Projeto Integrador Transdisciplinar em Banco de Dados II

Mais conteúdo relacionado

Semelhante a Projeto Integrador Transdisciplinar em Banco de Dados II

Mais de Colaborar Educacional

Último

Projeto Integrador Transdisciplinar em Banco de Dados II