PROJETO INTEGRADOR DESENVOLVIMENTO DE SISTEMAS ORIENTADO A OBJETOS

Prévia do material em texto

SERVIÇO NACIONAL DE APRENDIZAGEM COMERCIAL 
SENAC 
 
 
 
CURSO DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS 
 
 
 
PROJETO INTEGRADOR – DESENVOLVIMENTO DE SISTEMAS ORIENTADO A OBJETOS. 
 
 
 
 
 
Integrantes do grupo: 
Adeilson Barbosa de Lima Junior 
Ailene dos Santos Bezerra 
João Gabriel Felipe da Costa Melo 
Lucas Costa Silva 
Pedro Kenzo Rodrigues Tanaka 
Waltecio Allysson Dias de Oliveira 
 
 
 
 
 
EAD - ENSINO À DISTÂNCIA - 2025 
 
 
Sumário 
INTRODUÇÃO ...................................................................................................... 4 
CASO DE USO ...................................................................................................... 5 
DIAGRAMA DE CLASSES ....................................................................................... 9 
PROTÓTIPO DE INTERFACE ELABORADO NO FIGMA ................................................ 9 
MODELAGEM RELACIONADA A IMPLEMENTAÇÃO DO SQL...................................... 14 
CONCLUSÃO ...................................................................................................... 21 
REPOSITÓRIO TÉCNICO DO PROJETO ..................................................................... 22 
 
 
 
 
 
Lista de Figuras 
Figura 1 – Diagrama de caso de uso universidade .................................................... 5 
Figura 2 - Diagrama de classes............................................................................... 9 
Figura 3 -Tela inicial para cadastro ........................................................................ 10 
Figura 4 – Página para preenchimento de informações ........................................... 11 
Figura 5 – Página para campo de informações mais específicas .............................. 11 
Figura 6 – Informação de cadastro aprovado .......................................................... 12 
Figura 7 – Mensagem de erro por informação divergente no cadastro ...................... 13 
 
 
 
 
INTRODUÇÃO 
 
O projeto a seguir tem como objetivo a modelagem de um sistema orientado a objetos, 
voltado á gestão de cadastros de uma grande universidade. A proposta busca ampliar os 
conceitos de Análise de Sistemas e utilizar a linguagem unificada de modelagem (UML) 
como ferramenta de apoio ao desenvolvimento. 
A UML possibilita a representação visual dos requisitos e funcionalidades do sistema por 
meio de diagramas padronizados, o que auxilia no entendimento sobre o projeto entre 
os membros da equipe de desenvolvimento, promovendo uma visão mais clara e 
estruturada sobre o mesmo. 
Na primeira entrega do projeto integrador foram elaborados os seguintes itens: 
1 Diagrama de Caso de Uso: 
Contempla os principais cenários de cadastro de pessoa física e jurídica, incluindo 
alunos, professores e fornecedores. 
 
2 Descrição dos casos de uso: 
Contém o cenário principal, fluxos alternativos, pré-condições e pós-condições 
de cada funcionalidade levantada. 
 
3 Diagrama de Classes: 
Representa a estrutura base do sistema em termos de entidade, atributos, 
relacionamento e herança. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
CASO DE USO 
 
Casos de uso: 
1. Cadastro de pessoa física 
2. Cadastro de pessoa jurídica 
3. Cadastro de aluno 
4. Cadastro de professor 
5. Cadastro de fornecedor 
6. Validar dados (CPF/CNPJ) 
 Atores: 
1. Professor 
2. Aluno 
3. Fornecedor 
4. Gestor de cadastros 
 
Figura 1 – Diagrama de caso de uso universidade 
 
Fonte: Autores (2025) 
 
Os casos de uso serão descritos a seguir, considerando: Atores, pré-condições, pós-
condições, fluxo principal e cenários alternativos. 
 
 
 
 
 
CASO DE USO 01 – CADASTRO DE PESSOA FÍSICA 
Item Descrição 
Atores Usuário (Aluno ou Professor), Gestor de Cadastros 
Pré-condições O usuário deve acessar o sistema e selecionar a opção de cadastro de pessoa 
física. O sistema deve estar disponível e conectado ao banco de dados. 
Fluxo principal 1. O usuário solicita o cadastro de pessoa física. 
2. O sistema apresenta o formulário com os campos obrigatórios (nome, CPF, data 
de nascimento, endereço, telefone, e-mail). 
3. O usuário informa os dados. 
4. O sistema executa o caso de uso Validar Dados (CPF). 
5. O gestor de cadastros confirma a inclusão. 
6. O sistema grava os dados e apresenta mensagem de sucesso. 
Cenário alternativo 1 CPF inválido: 
O sistema identifica que o CPF não é válido. 
 Exibe mensagem de erro e solicita correção e retorna ao formulário para 
correção. 
Cenário alternativo 2 Pessoa já cadastrada: 
O sistema identifica que o CPF já consta na base de dados. 
Exibe mensagem de duplicidade e o cadastro não é concluído. 
Pós condições A pessoa física é cadastrada no sistema com os dados obrigatórios 
registrados e disponível para futuras consultas ou alterações. 
 
 
CASO DE USO 02 – CADASTRO DE PESSOA JURÍDICA 
 
Item Descrição 
Atores Usuário (fornecedor) e gestor de cadastros. 
Pré-condições O usuário deve acessar o sistema e selecionar a opção de cadastro de pessoa 
jurídica. O sistema deve estar disponível e conectado ao banco de dados. 
Fluxo principal 1. O usuário solicita o cadastro de pessoa jurídica. 
2. O sistema apresenta o formulário com os campos obrigatórios (razão social, 
CNPJ, endereço, telefone, e-mail, ramo de atividade). 
3. O usuário informa os dados. 
4. O sistema executa o caso de uso Validar Dados (CNPJ). 
5. O gestor de cadastros confirma a inclusão. 
6. O sistema grava os dados e apresenta mensagem de sucesso. 
Cenário alternativo 1 CNPJ inválido: 
O sistema identifica que o CNPJ não é válido. 
Exibe mensagem de erro e solicita correção e retorna ao formulário para correção. 
Cenário alternativo 2 Pessoa jurídica já cadastrada: 
 O sistema identifica que o CNPJ já consta na base de dados. 
 Exibe mensagem de duplicidade e o cadastro não é concluído. 
Pós condições A pessoa jurídica é cadastrada no sistema com os dados obrigatórios registrados e 
disponível para futuras consultas ou alterações. 
 
 
CASO DE USO 03 – CADASTRO DE ALUNO 
 
 
CASO DE USO 04 – CADASTRO DE PROFESSOR 
Item Descrição 
Atores Aluno e gestor de cadastros. 
 
 
Pré-condições O aluno deve acessar o sistema e selecionar a opção “Cadastro de Aluno”. O sistema deve 
estar disponível e conectado ao banco de dados. 
Fluxo principal 1. O aluno solicita o cadastro de aluno. 
2. O sistema abre o formulário de Cadastro de Pessoa Física. 
3. O aluno informa os dados obrigatórios (nome, CPF, data de nascimento, endereço, 
telefone, e-mail). 
4. O sistema realiza o caso de uso Validar Dados (CPF). 
5. O gestor de cadastros confirma a inclusão. 
6. O sistema grava os dados e apresenta mensagem de sucesso. 
Cenário alternativo 1 CPF inválido: 
O sistema identifica que o CPF informado é inválido. 
Exibe mensagem de erro e solicita correção e retorna ao passo 4 do fluxo principal. 
Cenário alternativo 2 Aluno já cadastrado: 
O sistema identifica duplicidade de CPF, exibe mensagem e não efetiva o cadastro. 
Pós- condições O aluno é registrado no sistema como pessoa física e os dados ficam armazenados para 
consultas ou alterações. 
 
 
Item Descrição 
Atores Professor, Gestor de Cadastros 
 
 
Pré-condições O professor deve acessar o sistema e selecionar a opção “Cadastro de Professor”. O 
sistema deve estar conectado ao banco de dados. 
Fluxo principal 1. O professor solicita o cadastro de professor. 
2. O sistema abre o formulário de Cadastro de Pessoa Física. 
3. O professor informa os dados obrigatórios (nome, CPF, data de nascimento, área de 
atuação, endereço, telefone, e-mail). 
4. O sistema realiza o caso de uso Validar Dados (CPF). 
5. O gestor de cadastros confirma o cadastro. 
6. O sistema grava os dados e apresenta mensagem de sucesso. 
Cenário alternativo 1 CPF inválido: 
O sistema identifica CPF inválido. 
 Exibe mensagem de erro, solicita correção e retorna ao passo 4 do fluxo principal. 
Cenário alternativo 2 Professor já cadastrado: 
 O sistemaidentifica duplicidade de CPF, exibe mensagem e encerra o processo. 
Pós-condições O professor é registrado no sistema como pessoa física e seus dados ficam disponíveis 
para futuras consultas e alterações. 
 
 
 
CASO DE USO 05 – CADASTRO DE FORNECEDOR 
 
CASO DE USO 06 – VALIDAR DADOS (CPF/CNPJ) 
Item Descrição 
Atores Fornecedor e gestor de cadastros 
Pré-condições O fornecedor deve acessar o sistema e selecionar a opção “Cadastro de Fornecedor”. O 
sistema deve estar conectado ao banco de dados. 
Fluxo principal 1. O fornecedor solicita o cadastro de fornecedor. 
2. O sistema abre o formulário de Cadastro de Pessoa Jurídica. 
3. O fornecedor informa os dados obrigatórios (razão social, CNPJ, endereço, telefone, e-mail, 
ramo de atividade). 
4. O sistema realiza o caso de uso Validar Dados (CNPJ). 
5. O gestor de cadastros confirma os dados. 
6. O sistema grava as informações e apresenta mensagem de sucesso. 
Cenário alternativo 1 CNPJ inválido: 
O sistema identifica CNPJ inválido, exibe mensagem de erro, solicita correção e retorna ao 
passo 4 do fluxo principal. 
Cenário alternativo 2 Fornecedor já cadastrado: 
 O sistema encontra duplicidade no CNPJ, exibe mensagem e encerra o cadastro. 
Pós-condições O fornecedor é registrado como pessoa jurídica e seus dados ficam disponíveis para futuras 
consultas e alterações. 
Item Descrição 
Atores Gestor de Cadastros (indiretamente também Aluno, Professor e Fornecedor ao fornecerem 
seus dados) 
Pré-condições O usuário (Aluno, Professor ou Fornecedor) deve ter preenchido o campo de CPF ou CNPJ no 
formulário de cadastro. O sistema deve estar conectado à base de dados ou serviço de 
validação. 
Fluxo principal 
1. O sistema recebe o CPF ou CNPJ informado. 
2. O sistema verifica a conformidade do número (estrutura, dígitos verificadores, formato). 
3. O sistema consulta a base para checar se já existe registro associado ao mesmo CPF/CNPJ. 
4. Caso os dados sejam válidos e não haja duplicidade, o fluxo retorna para o cadastro 
correspondente. 
 
Cenário alternativo 1 CPF/CNPJ inválido: 
2a. O sistema identifica que o número informado não é válido. 
2b. Exibe mensagem de erro solicitando correção. 
2c. Retorna ao formulário de cadastro. 
Cenário alternativo 2 CPF/CNPJ já existente: 
O sistema identifica que o CPF ou CNPJ já está registrado, exibe mensagem de duplicidade e o 
cadastro não é concluído. 
Pós-condições O sistema retorna o resultado da validação (sucesso ou erro). 
Em caso de sucesso, o fluxo do cadastro segue normalmente e em caso de erro ou 
duplicidade, o cadastro não é realizado. 
 
 
 
DIAGRAMA DE CLASSES 
 
Figura 2 - Diagrama de classes 
 
Fonte: Autores (2025) 
 
O diagrama de classes representa um sistema de cadastro de pessoas. A classe Pessoa é 
a base, contendo atributos comuns como nome, endereço, e-mail e telefone. A partir 
dela derivam Pessoa Física (com CPF e data de nascimento) e Pessoa Jurídica (com CNPJ 
e razão social). 
De Pessoa Física surgem Aluno (matrícula, curso, situação) e Professor (matrícula, 
titulação, departamento). Já de Pessoa Jurídica deriva Fornecedor (categoria e status de 
credenciamento). 
A classe Gestor Cadastros é independente e tem a função de validar e cadastrar pessoas 
no sistema. O modelo organiza as entidades, reutiliza atributos por herança e separa 
responsabilidades de forma clara. 
 
PROTÓTIPO DE INTERFACE ELABORADO NO FIGMA 
 
 
 
O Figma é uma ferramenta muito prática para criar designs de sites, aplicativos e 
interfaces digitais. Ele funciona direto no navegador, o que facilita sua utilização sem a 
necessidade de instalar programas e pode acessar seus projetos de qualquer lugar. Uma 
das maiores vantagens do Figma é a colaboração em tempo real: várias pessoas podem 
editar o mesmo arquivo ao mesmo tempo, facilitando o trabalho em equipe e evitando 
versões diferentes de um mesmo projeto. 
Além disso, o Figma oferece muitos recursos úteis, como bibliotecas de componentes, 
prototipação e plugins que ajudam a economizar tempo. Seu uso é simples e intuitivo, 
permitindo que tanto iniciantes quanto profissionais criem layouts bonitos e 
organizados. Por ser rápido, flexível e colaborativo, o Figma se tornou uma das principais 
ferramentas de design atualmente. 
Com o Figma, é possível criar protótipos navegáveis, ou seja, simulações de como o site 
ou app vai funcionar sem precisar usar outras ferramentas; você pode criar botões, 
cartões, menus e transformá-los em componentes. Depois, pode reutilizá-los em várias 
telas, mantendo tudo organizado e com visual consistente; equipes maiores podem criar 
bibliotecas de design, como guias de estilo, cores, fontes e componentes que todos 
podem usar, garantindo padronização. 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 3 -Tela inicial para cadastro 
 
 
 
Fonte: Autores (2025) 
 
De início usuário vai se deparar com essa tela, onde ele poderá escolher que tipo de 
cadastro ele precisa realizar, tanto para pessoa física como jurídica são necessárias 
informações para dar procedimento ao cadastro. 
 
Figura 4 – Pagina para preenchimento de informações 
 
Fonte: Autores (2025) 
 
Ao escolher que tipo de cadastro irá realizar, o usuário será direcionado para uma das 
páginas correspondente a sua escolha, nela, ele irá preencher as informações de acordo 
com o que se pede e abaixo confirmar que tipo de cadastro está sendo feito. 
 
Figura 5 – Pagina para campo de informações mais específicas 
 
 
 
Fonte: Autores 2025 
 
Seguindo, o usuário vai ser direcionado para a próxima página, podendo ser: Professor, 
aluno, fornecedor, pessoa física ou pessoa jurídica e um campo de informações mais 
especificas precisará ser preenchido até finalizar clicando em cadastre-se. 
 
 
 
Figura 6 – Informação de cadastro aprovado 
 
 
 
Fonte: Autores 2025 
 
Se tudo for preenchido corretamente a mensagem informará que seu cadastro foi 
finalizado e você poderá concluir. 
 
Figura 7 – Mensagem de erro por informação divergente no cadastro 
 
Fonte: Autores 2025 
 
 
 
Caso alguma informação preenchida anteriormente estiver divergente, uma mensagem 
de erro deverá aparecer para o usuário, informando que o mesmo deve rever e tentar 
novamente 
 
MODELAGEM RELACIONADA A IMPLEMENTAÇÃO DO SQL 
 
O script monta uma estrutura perfeita para representar: 
• Pessoas 
• Pessoas físicas 
o Alunos 
o Professores 
o Gestores 
• Pessoas jurídicas 
o Fornecedores 
Cada uma respeitando o conceito de herança do diagrama UML. 
Análise do create_tables.sql 
Banco de dados 
 
Cria o banco de dados apenas se ainda não existir, e depois seleciona para uso. 
 
Tabela pessoa — Classe Base 
 
 
 
Essa é a classe genérica. Todas as outras pessoas (alunos, professores, fornecedores...) 
também terão um registro. 
Campos comuns a qualquer pessoa: 
• nome 
• endereço 
• telefone 
• e-mail 
O id é gerado automaticamente. 
 
Tabela pessoa_fisica — Herda de pessoa 
 
Aqui acontece a herança: 
• O id não é AUTO_INCREMENT, ele deve ser igual ao id existente na tabela pessoa 
• Ou seja: a PF "estende" uma pessoa 
Campos específicos de PF: 
• CPF 
• data_nascimento 
 
Tabela pessoa_juridica — Herda de pessoa 
 
 
 
Mesma lógica: o ID vem da tabela pessoa. 
Campos específicos: 
• cnpj 
• razao_social 
• ramo_atividade 
 
Tabela aluno — Herda de pessoa_fisica 
 
O aluno é uma especialização de pessoa física. 
Campos específicos: 
• matrícula 
• curso 
• situação 
 
Tabela professor — Herda de pessoa_fisica 
 
 
 
Professor também é uma pessoa física, com atributos próprios. 
Campos específicos: 
• matrícula 
• área de atuação 
• titulação 
• departamento 
 
Tabela fornecedor — Herda de pessoa_juridica 
 
Fornecedor é uma empresa, logo herda da tabela pessoa_juridica. 
Campos específicos: 
• categoria 
• status_credenciamento 
 
Tabela gestor_cadastros — Herda de pessoa_fisica 
 
 
 
Gestor é uma pessoafísica, mas com um identificador próprio (id_gestor). 
 
Análise dos Dados de Teste (insert_examples.sql) 
O banco foi modelado com herança entre tabelas, onde: 
• pessoa é a tabela base 
• pessoa_fisica e pessoa_juridica são especializações 
• aluno, professor, fornecedor, gestor_cadastros dependem de registros 
previamente criados 
Essa estrutura geralmente possui chaves estrangeiras (FKs) exigindo que: 
1. Um registro exista na tabela pessoa 
2. Para pessoas físicas, também exista na tabela pessoa_fisica 
3. Somente depois disso o sistema permite inserir em aluno, professor etc. 
Isso obriga o script a seguir uma ordem correta de inserção, e a ordem não for seguida, 
o banco rejeita as operações com erro. 
 
Exemplo estudado: Aluno de ID = 1 
Para criar o aluno de ID 1, o script faz: 
Inserção na tabela pessoa 
 
Aqui o ID 1 passa a existir no sistema. 
 
Inserção na tabela pessoa_fisica 
 
A tabela pessoa_fisica utiliza o mesmo ID, representando que João Silva é uma pessoa 
física, Como o ID 1 já existe em pessoa, a referência está correta. 
Inserção na tabela aluno 
 
 
 
 Aqui ocorre a validação final: 
• O banco só aceita esse registro porque o ID 1 já existe em pessoa 
• E também já existe uma pessoa_fisica com ID 1 
• Assim, João Silva está autorizado a ser cadastrado como aluno 
Se a ordem fosse invertida (por exemplo, tentando inserir no aluno antes), o banco 
retornaria Erro. 
O script segue a ordem correta de inserção nas tabelas para respeitar as chaves 
estrangeiras. O ID é mantido o mesmo em todas as tabelas, e o banco só permite isso 
porque primeiro a pessoa é criada, depois sua especialização (PF ou PJ) e só então o 
papel (aluno, professor etc.) é atribuído. Isso garante integridade referencial. 
 
Análise das Consultas de Teste (queries.sql) 
Como o arquivo queries.sql reconstrói os objetos usando JOINs 
Sua modelagem utiliza herança entre tabelas: 
• pessoa = entidade base 
• pessoa_fisica e pessoa_juridica = especializações 
• aluno, professor, fornecedor, gestor_cadastros = papéis específicos 
Isso significa que nenhuma tabela isolada contém todas as informações do objeto, pois 
os atributos ficam distribuídos nas três camadas. Para consultar o objeto completo, é 
necessário recompor esses dados usando JOIN, unindo as tabelas base + especialização 
+ papel. Assim, cada consulta do arquivo queries.sql funciona como uma "montagem do 
objeto", como se o banco estivesse reconstruindo o objeto “Aluno”, “Professor”, 
“Fornecedor”, etc. 
 
Exemplo: Reconstituição do objeto Professor 
O professor existe em três tabelas: 
1. pessoa → nome, endereço, telefone, email 
2. pessoa_fisica → cpf, data de nascimento 
3. professor → matrícula, área de atuação, titulação, departamento 
 
 
Nenhuma delas sozinha representa um professor completo. 
Por isso, o arquivo usa: 
 
 
Tabela principal da consulta 
 
Começa pela tabela professor, que contém os atributos específicos da função docente. 
 
Unindo com pessoa_fisica 
 
Isso recupera dados de quem é o professor (CPF, data de nascimento). O JOIN funciona 
porque o mesmo ID existe nas duas tabelas. 
 
Unindo com pessoa 
 
Agora puxa dados básicos: nome, endereço, email etc., finaliza a reconstituição do 
objeto. 
 
 
 
 
 
 
O resultado contém atributos de todas as camadas: 
 
Origem - Atributos 
Pessoa - nome, telefone, email 
pessoa_fisica - cpf 
Professor - matrícula, área_atuacao, titulação, departamento 
O join é exatamente o mecanismo que simula a herança, reconstruindo o objeto 
completo. 
O arquivo queries.sql usa JOINs para reconstruir objetos completos a partir das 
tabelas relacionadas pela herança. Como os dados de cada entidade estão 
distribuídos em três tabelas (pessoa pessoa_fisica/pessoa_juridica papel), os JOINs 
reagrupam essas informações como se fossem um único objeto. A consulta do 
professor, por exemplo, junta pessoa + pessoa_fisica + professor para formar a 
entidade final. 
 
CONCLUSÃO 
 
O projeto utiliza UML para representar visualmente requisitos e estruturas, facilitando o 
entendimento entre os membros da equipe. Foram criados diagramas de caso de uso, 
classes, protótipo de interface e modelagem de banco de dados em SQL. Os casos de 
uso contemplam cadastros de pessoa física, jurídica, aluno, professor e fornecedor, além 
da validação de CPF e CNPJ. Cada fluxo detalha pré-condições, cenários alternativos e 
pós-condições. O diagrama de classes demonstra o uso de herança: Pessoa é a classe 
base, estendida por Pessoa Física e Jurídica, que originam Aluno, Professor e Fornecedor. 
O gestor de cadastro realiza validações e confirma os registros. 
O protótipo de interface foi desenvolvido no Figma, destacando telas iniciais, formulários 
e mensagens de sucesso ou erro. A modelagem SQL implementa herança por meio de 
tabelas relacionadas por chaves estrangeiras com IDs compartilhados. Inserções seguem 
ordem hierárquica para garantir integridade referencial. Consultas SQL utilizam joins 
para reconstruir objetos completos agrupando informações das tabelas. O projeto 
demonstra organização estrutural, reutilização de atributos e alinhamento com boas 
práticas de OOP e banco de dados. 
 
 
 
REPOSITÓRIO TÉCNICO DO PROJETO 
Link do GitHub: https://github.com/JoaoGabriel12558/Projeto-Integrador-ADS 
(O código-fonte SQL, protótipos e diagramas estão disponíveis neste endereço.)