PIM VI Análise de Sistemas Nota 6.5 -> ABNT Errada

Prévia do material em texto

UNIP Ead 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia 
 
 
 
 
 
PRÁTICAS DE ANÁLISE ORIENTADA A OBJETOS E BANCO DE DADOS 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
SÃO CARLOS 
2019 
 
 
 
 
 
UNIP Ead 
Projeto Integrado Multidisciplinar 
 Curso Superiores de Tecnologia 
 
 
 
 
 
 
PRÁTICAS DE ANÁLISE ORIENTADA A OBJETOS E BANCO DE DADOS 
 
 
 
 
 
 
 
 
 
Nome: Cláudia Ferreira Dias, RA: 1873439 
Nome: Paulo Victor Moraes Daun, RA: 1873389 
Nome: Rafael Franco, RA: 1873476 
Nome: Thiago Baldino Moreira, RA: 1887806 
 
 
 
 
 
 
 
UNIP 
2019 
 
 
Resumo: 
O presente PIM – VI, pretende estudar as matérias: 
Análise Orientada a Objetos. 
 Casos de uso, diagramas de casos de uso, relacionamentos include, extend e 
generalização, requisitos não funcionais e regras de negócio. 
- Banco de dados. 
• Modelagem MER. 
• Cardinalidade. 
• Programação utilizando banco de dados SQL Server da Microsoft. 
Gestão de recursos humanos. 
 Estudos dos grupos de trabalho. Como organizar o grupo para separar as tarefas do 
PIM-VI. 
Inclui também diagramas de casos de uso, diagramas de classe e MER. 
O Título do trabalho práticas se deve ao fato das matérias da UNIP – EaD terem sido feitas 
em formas de projeto tornando o estudo de uma forma moderna. 
Palavras-chave: Casos de uso, diagramas de casos de uso, relacionamentos include, extend e 
generalização, requisitos não funcionais e regras de negócio, Modelagem MER com SQL 
Server. 
 
 
 
 
 
 
 
 
 
 
 
 
 
Abstract 
This PIM - VI, intends to study the following subjects: 
Object Oriented Analysis. 
Use cases, use case diagrams, include relationships, extend and generalization, 
nonfunctional requirements, and business rules. 
Database. 
MER modeling. 
Cardinality. 
Programming using Microsoft SQL Server database. 
Human resource Management. 
Studies of working groups. How to organize the group to separate the PIM-VI tasks. 
It also includes use-case diagrams, class diagrams and MER. 
The title of the practical work is due to the fact that the UNIP - EaD materials have 
been made in project forms making the study in a modern way. 
Keywords: Use cases, use-case diagrams, include relationships, extend and 
generalization, non-functional requirements and business rules, MER modeling with 
SQL Server. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
SUMÁRIO 
 
 
1 INTRODUÇÃO: ............................................................................................................................. 6 
2 Casos de uso .................................................................................................................................... 7 
2.1 Generalização, Include , Extend e Herança......................................................................................8 
2.2 Modelo dos casos de uso no PIM-VI ............................................................................................ 10 
3 Requisitos não funcionais .............................................................................................................. 20 
3.1 No PIM – VI Requisitos não funcionais ....................................................................................... 23 
4 Contextos de uso.............................................................................................................................24 
5 Regras de negócio ......................................................................................................................... 24 
6 Diagrama de classe ........................................................................................................................ 27 
6.1 Boundary, Control e Entity.............................................................................................................28 
7 Modelo de dados (MER) ............................................................................................................... 29 
7.1 Entidades.........................................................................................................................................29 
7.2 Atributos.........................................................................................................................................29 
7.3 Relacionamentos.............................................................................................................................30 
7.4 Cardinalidade do relacionamento...................................................................................................32 
7.5 Conceito cardinalidade máxima......................................................................................................32 
7.6 Modelos MER – Conceitual .......................................................................................................... 33 
7.7 Modelo Lógica................................................................................................................................33 
7.8 Mapeamento....................................................................................................................................34 
7.9 Outras regras...................................................................................................................................34 
8 Conclusão: ..................................................................................................................................... 42 
Referências: ............................................................................................................................................... 
 
 
 
 
 
 
6 
 
 
1 INTRODUÇÃO: 
 
 
No presente PIM, foi feito um projeto de análise orientada a objetos, banco de dados e gestão 
de recursos humanos, em um site de cadastro de matrículas fictício de uma universidade. Os 
objetivos foram aplicar as matérias para um excelente aprendizado de forma moderna. 
Para os casos de uso, e MER foram feitos os diagramas usando os softwares Br Modelo, 
Astah, SQL Server , MySQL. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
7 
 
 
2 Casos de uso 
 
 
Casos de uso é a descrição de uma sequência de como será o usuário externo ao sistema de 
software, por exemplo, uma pessoa vai ao banco no terminal de auto-atendimento, ou em um 
site da universidade efetuar sua matrícula ou uma loja de e-commerce etc. 
Os usuários externos são chamados de atores. Não necessariamente precisam ser humanos, há 
casos de usos com pombos, carros outros sistemas etc. 
Um caso de uso nunca mostra o sistema interno do sistema e também não é um ator de si 
mesmo. Atores não são componentes internos do sistema. 
Os casos de uso são mostrados por nomes que o represente. Uma boa prática é utilizar verbos 
no infinitivo. Por exemplo: Efetuar saque conta corrente. 
Os atores normalmente são mostrados no substantivo. 
Modelo do caso de uso: 
No PIM-IV UNIP-EAD foram utilizadas as notações: 
 
Fonte: Livro-Texto UNIP-EAD análise orientada o objeto página 67 volume II. 
8 
 
Fonte: Do autor 
2.1 Generalizações Include, Extend e Herança: 
Include – Sempre os dois casos serão executados. Por exemplo, não há como escolher o curso 
para cancelar a matrícula sem que seja solicitado o cancelamento da matrícula. Exemplo com 
a matemática: Dois conjuntos A e B. Se A inclui (include) B não como executarB sem 
executar A. 
Extend – Não necessariamente os dois casos são executados. Exemplo: Quando o aluno entra 
no sistema (faz login) não necessariamente ele precisa efetuar a matrícula. 
Herança – Utilizada para economizar linhas no caso de uso. Quando temos atores ou casos de 
uso com as mesmas características. 
 
Fonte: Livro-Texto UNIP-EAD análise orientada o objeto página 71 volume II. 
9 
 
O caso de uso pai “Validar segurança de acesso” entrega suas característica para Validar 
segurança Acesso por Senha e Validar segurança acesso por biometria, que também são 
chamadas de classes filhas. 
 
Fonte: Do autor. 
Descrição do caso de uso: 
Forma natural e seqüencial de se descrever uma sequência pelo autor. Com textos e tabelas 
como no exemplo: 
 
Fonte: Livro-Texto UNIP-EAD análise orientada o objeto página 73 volume II. 
No PIM – VI: 
Observações: Será anexado no site da UNIP, junto com o PIM o diagrama. No documento 
Microsoft Word não há resolução adequada. 
10 
 
 
Fonte: Do autor. 
2.2 Modelo dos casos de uso no PIM-VI 
001- Cadastrar usuário 
002 - Validar o usuário 
003- Cadastrar curso 
004- Efetuar matrícula 
005 - Consultar informação 
006 - Cancelar matrícula 
007 - Gerar Recibo e log de dados 
008 -Validar matrícula 
009 - Efetuar segunda matrícula 
010 - Enviar informações para o setor financeiro 
011 - Escolher curso 
012 - Validar Cancelamento 
013 - Listar cursos disponíveis 
014 - Consultar cancelamento por curso 
 
11 
 
Número de caso de uso: 001 
Identificação: Entrar no sistema. 
Escopo: Site do sistema. 
Descrição do propósito: esse caso de uso permite ao aluno ou funcionário logar no sistema. 
Ator primário: aluno ou funcionário. 
Interessados: cliente ou funcionário. 
Pré-condições: o sistema deve estar no ar. 
Pós-condições: o aluno ou funcionário deve conseguir logar no sistema. 
Fluxo normal: 
 
1. A pessoa entra no site. 
2. Inclusão para validar o usuário. 
3. O sistema exibe as operações possíveis de serem feitas. 
4. Extensão de cadastrar curso. 
5. Extensão efetuar matrícula. 
6. Extensão de consultar informação. 
7. Extensão de cancelar matrícula. 
 
Fluxo alternativo: 
 
Requisitos relacionados: 002 Validar o usuário, 003 Cadastrar curso, 004 efetuar matrícula, 
005 Consultar informação, 006 Cancelar matrícula. 
 
Número de caso de uso: 002 
Identificação: Validar usuário. 
Escopo: Site do sistema. 
Descrição do propósito: esse caso de uso permite ao sistema determinar o tipo de usuário e se 
este é válido. 
Ator primário: aluno ou funcionário. 
Interessados: cliente ou funcionário. 
Pré-condições: o sistema deve estar no ar. 
Pós-condições: o aluno ou funcionário deve conseguir logar no sistema. 
Fluxo normal: 
 
12 
 
 1. A pessoa escolha uma opção entre aluno e funcionário. 
 2. A pessoa digita o login e a senha. 
Fluxo alternativo: 
2.1 Caso digitado login ou senha errado exibe uma mensagem. 
 
Requisitos relacionados: 001 Entrar no sistema. 
 
Número de caso de uso: 003 
Identificação: Cadastrar curso. 
Escopo: Site do sistema. 
Descrição do propósito: esse caso de uso permite a um funcionário cadastrar um curso na área 
de artes ou informática 
Ator primário: funcionário. 
Interessados: funcionário. 
Pré-condições: Um funcionário deve ter logado no sistema. 
Pós-condições: Um curso é adicionado ao sistema. 
Fluxo normal: 
 
 1. O funcionário seleciona de qual área é o curso que pretende cadastrar. 
 2. O funcionário preenche os campos com as informações sobre o curso. 
Fluxo alternativo: 
 2.1 Caso digitado algo inválido uma mensagem é exibida. 
 
Requisitos relacionados: 001 Entrar no sistema, 002 Validar o usuário. 
 
Número de caso de uso: 004 
Identificação: Efetuar matrícula. 
Escopo: Site do sistema. 
Descrição do propósito: esse caso de uso permite a um aluno efetuar uma matrícula em um 
curso da área de artes ou informática. 
Ator primário: aluno. 
Interessados: aluno. 
Pré-condições: Um aluno deve ter logado no sistema. 
Pós-condições: Um aluno é cadastrado com sucesso. 
13 
 
Fluxo normal: 
 
 1. O aluno seleciona em que tipo de curso ele deseja se cadastrar(artes ou informática). 
 2. O aluno seleciona em qual curso deseja realizar a matrícula. 
 3. O aluno preenche suas informações 
 3. Inclui Validar matrícula. 
 4. Inclui Gerar Recibo e log de dados 
Fluxo alternativo: 
 2.1 Caso o curso desejado pelo aluno não exista este sai do sistema sem realizar a 
matrícula. 
 3.1 Caso o aluno digite uma informação inválida uma mensagem de aparecer. 
Requisitos relacionados: 008 Validar matrícula, 007 Gerar Recibo e log de dados. 
 
Número de caso de uso: 005 
Identificação: Consultar informação. 
Escopo: Site do sistema. 
Descrição do propósito: esse caso de uso permite a um funcionário consultar informações 
sobre o curso. 
Ator primário: funcionário. 
Interessados: funcionário. 
Pré-condições: Um funcionário deve ter logado no sistema. 
Pós-condições: Um funcionário estará ciente das informações sobre o curso. 
Fluxo normal: 
 
 1. Um funcionário seleciona qual tipo de informação deseja consultar. 
 2. Estende listar cursos disponíveis 
 3. Estende Consultar cancelamento por curso 
Fluxo alternativo: 
 
Requisitos relacionados: 013 Listar cursos disponíveis, 014 Consultar cancelamento por 
curso. 
 
Número de caso de uso: 006 
Identificação: Cancelar matrícula. 
14 
 
Escopo: Site do sistema. 
Descrição do propósito: esse caso de uso permite a um aluno cancelar sua matrícula em um 
curso. 
Ator primário: aluno. 
Interessados: aluno. 
Pré-condições: Um aluno deve ter logado no sistema. 
Pós-condições: Uma matrícula de um aluno será cancelada. 
Fluxo normal: 
 
 1. Inclui Escolher curso 
 2. O aluno digita as informações referentes ao cancelamento do curso 
 3. Inclui Validar cancelamento 
Fluxo alternativo: 
 2.1. Caso uma informação inválida seja digitada uma mensagem deve aparecer. 
 
Requisitos relacionados: 011 Escolher curso, 012 Validar Cancelamento. 
 
Número de caso de uso: 006 
Identificação: Cancelar matrícula. 
Escopo: Site do sistema. 
Descrição do propósito: esse caso de uso permite a um aluno cancelar sua matrícula em um 
curso. 
Ator primário: aluno. 
Interessados: aluno. 
Pré-condições: Um aluno deve ter logado no sistema. 
Pós-condições: Uma matrícula de um aluno será cancelada. 
Fluxo normal: 
 
 1. Inclui Escolher curso 
 2. O aluno digita as informações referentes ao cancelamento do curso 
 3. Inclui Validar cancelamento 
Fluxo alternativo: 
 2.1. Caso uma informação inválida seja digitada uma mensagem deve aparecer. 
 
15 
 
Requisitos relacionados: 011 Escolher curso, 012 Validar Cancelamento. 
 
Número de caso de uso: 007 
Identificação: Gerar Recibo e log de dados. 
Escopo: Site do sistema. 
Descrição do propósito: esse caso de uso gera um histórico da matricula do aluno 
Ator primário: aluno. 
Interessados: aluno. 
Pré-condições: Um aluno deve ter logado no sistema. 
Pós-condições: Um recibo é gerado ao final do processo. 
Fluxo normal: 
 
 1. Um recibo contendo o pagamento do efetuado e informações da matrícula é gerado 
e apresentado ao aluno. 
Fluxo alternativo: 
 
Requisitos relacionados: 008 Validar matrícula. 
 
Número de caso de uso: 008 
Identificação: Validar matrícula. 
Escopo: Site do sistema. 
Descrição do propósito: esse caso de uso permite validar sua matrícula. 
Ator primário: aluno ou funcionário. 
Interessados: aluno ou funcionário. 
Pré-condições: Tero cadastro no sistema sendo aluno ou funcionário, o sistema estar no ar. 
Pós-condições: A matrícula é validade com sucesso. 
Fluxo Normal: 
1- É mostrada a tela de login para o funcionário ou aluno. 
2- A pessoa acessa o sistema 
3- Efetua a matrícula, depois é validada como segurança para o aluno. 
16 
 
Fluxo Alternativo: 
1- O aluno ou funcionário digita a senha errada e é mostrado erro. 
2- O aluno ou funcionário decidem depois do login não se cadastrar, logo pode-se fazer logout 
sem cadastrar o curso. 
Requisitos relacionados: 007 - Gerar Recibo e log de dados, 010 - Enviar informações para o 
setor financeiro 
 
Número de caso de uso: 009 
Identificação: Efetuar segunda matrícula. 
Escopo: Site do sistema. 
Descrição do propósito: esse caso de uso permite ao aluno efetuar uma segunda matrícula no curso 
desejado, sendo informática ou artes. 
Ator primário: aluno ou funcionário. 
Interessados: aluno ou funcionário. 
Pré-condições: Um aluno já deve ter cadastrado um curso, e deve estar logado ao sistema. 
Pós-condições: Um aluno é cadastrado com sucesso. 
Fluxo normal: 
1- A pessoa escolhe uma opção entre aluno e funcionário. 
2- A pessoa digita login e senha 
3- O aluno ou funcionário ,seleciona em qual curso deseja realizar a matrícula. 
4- O aluno ou funcionário preenche suas informações. 
5- Inclui Validar matrícula 
6- Inclui Gerar Recibo e log de dados. 
Fluxo alternativo: 
1- Caso o curso desejado pelo aluno não existe este sai do sistema sem realizar a matrícula. 
2- Caso o aluno digite uma informação inválida uma mensagem de erro deve aparecer. 
Requisitos relacionados: 004 Efetuar matrícula, 009 Efetuar segunda matrícula, 
007 Gerar Recibo e log de dados,008 Validar matrícula,10 Enviar informações para o setor 
financeiro 
17 
 
 
Número do caso de uso: 10 
Identificação: Enviar sistemas para o setor financeiro. 
Escopo: site do sistema. 
Ator primário: Funcionário. 
Ator secundário: Aluno. 
Pré-condições: O funcionário ter logado no sistema. 
Pós-condições: São enviados os dados de validação de matrícula ao setor financeiro. 
Fluxo normal: 
1- A pessoa seleciona login com aluno ou funcionário. 
2- Efetua a matrícula 
3- É validada a matrícula e enviada ao sistema financeiro pelo software 
Fluxo alternativo: O aluno cancela a matrícula do aluno e é enviado ao sistema financeiro pelo 
software. O funcionário também necessita cancelar . 
Número do caso de uso: 11 
Identificação: Escolher curso. 
Escopo: site do sistema. 
Ator primário: Aluno. 
Ator secundário: Funcionário. 
Interessados: Aluno 
Pré-condições – Aluno estar matriculado e o sistema estar no ar. 
Pós-condições – O curso é cancelado. 
Fluxo normal: 
1- O aluno entra no sistema. 
2- O aluno cancela a matrícula. 
3- O aluno escolhe o curso desejado para o cancelamento. 
4- O funcionário valida o cancelamento e envia as informações para o setor financeiro. 
18 
 
Fluxo alternativo: 
 O aluno entra nas opções de cancelamento, porém decidi continuar com o curso. Logo não há 
alterações 
Requisitos relacionados: 014 Consultar cancelamento por curso,010 Enviar informações para 
o setor financeiro ,012 Validar Cancelamento 
 
Número do caso de uso: 12 
Identificação: Validar cancelamento. 
Escopo: Site do sistema. 
Interessados: Funcionário e aluno. 
Ator principal: Funcionário 
Ator secundário: Aluno 
Pré-Condições: O aluno estar matriculado e o sistema estar no ar, o funcionário logado no sistema. 
Pós-Condições: É validado o cancelamento da matrícula. 
Fluxo normal: 
1 _ O funcionário valida o cancelamento da matrícula, e é enviado as informações ao setor 
financeiro. 
Fluxo alternativo: 
2 – Não há. 
Número do caso de uso: 13 
Identificação: Listar cursos disponíveis. 
Listar cursos disponíveis 
Escopo: Site do sistema. 
Ator primário: Aluno. 
Interessados: Aluno 
Pré-condições – Sistema estar no ar, aluno entrar no sistema. 
19 
 
Pós-condições – São listados os cursos disponíveis para efetuar a matrícula. 
Fluxo normal: 
1- O aluno consulta as informações. 
2- A lista é exibida ao aluno 
Fluxo alternativo: 
1- Não há 
Número do caso de uso: 14 
Escopo: Site do sistema. 
Ator principal: Aluno 
Ator secundário: Aluno 
Pré-Condições: O aluno estar matriculado e o sistema estar no ar, para consultar informações sobre 
cancelamento de curso. 
Pós-Condições: É mostrada a consulta do cancelamento. 
Requisitos relacionados: 005 Consultar informação. 
 
Número do caso de uso: 14 
Escopo: Site do sistema. 
Ator principal: Aluno 
Ator secundário: Aluno 
Pré-Condições: O aluno estar matriculado e o sistema estar no ar, para consultar informações sobre 
cancelamento de curso. 
Pós-Condições: É mostrada a consulta do cancelamento. 
Fluxo Normal: 
1- O aluno consulta as informações. 
2- É exibida a consulta de cancelamento por curso. 
Fluxo Alternativo: 
20 
 
Não há; 
Requisitos relacionados: 005 Consultar informação. 
 
 
3 Requisitos não funcionais 
Requisito não funcional também chamado de atributo de qualidade deve especificar as 
informações abstratas do software. Um requisito não funcional de qualidade tem a capacidade 
de especificar todas as funções do sistema a ser utilizado de forma abstrata, com atributos 
altamente complexos em sua documentação, tem a capacidade de rastreabilidade e validação 
do seu caso. 
Requisitos não funcionais (RNF) exprimem limitações sobre os serviços oferecidos pelo 
sistema de software (SOMMERVILLE, 2010). 
Segundo Versolatto (2015) os requisitos funcionais são insuficientes para descrever o sistema 
de software, pois é necessário descrever outros aspectos: atributos do sistema e atributos do 
ambiente do sistema, normalmente classificados como requisitos não funcionais. 
Encontram-se muitas asserções a respeito classificatório de requisitos não funcionais, 
Sommerville (2010). 
Essa classificação é feita a partir da origem dos requisitos não funcionais, segundo Versolatto 
(2015) são: 
▪ Requisitos Organizacionais: provenientes da organização do cliente, como a 
padronização de uma linguagem de desenvolvimento. 
▪ Requisitos de Produto: são aqueles que restringem o comportamento do sistema de 
software, como o espaço em disco que ele irá ocupar. 
▪ Requisitos Externos: são requisitos de fora da fronteira do sistema de software, como 
requisitos legais, de cumprimento da legislação. 
Outra proposição foi que Sommerville (2010), descreveu a norma ISO/IEC 25010:2011 como 
uma classificação e definição de requisitos não funcionais. 
Versolato (2015) observa que o International Organization por Standardization (ISO) é um 
grupo fundado em 1947, sem relações com órgãos governamentais, localizado na cidade de 
Genebra, na Suíça, com o objetivo de definir diretrizes normativas. 
21 
 
A diretriz representa seis características que determina a qualidade de software: 
funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. 
Essas características, também denominadas atributos de qualidade, são comumente usadas 
quando trabalhamos com requisitos não funcionais. 
Sengundo Versollato (2015) os atributos de qualidade segundo a ISO 25010 (2011) são: 
Funcionalidade: Está ligado à capacidade do sistema de software de prover 
funcionalidades que atendam às necessidades explícitas e implícitas quando usado sob 
as condições especificadas. 
Confiabilidade: Está ligado à capacidade do sistema de software de manter um 
determinado nível de desempenho quando usado sob as condições especificadas 
Usabilidade: Está ligado à capacidade do sistema de software de auxiliar os usuáriosna realização de suas tarefas, de maneira produtiva (ROCHA; BARANAUSKAS, 
2003). 
Eficiência: Está ligado à capacidade do sistema de software de prover desempenho 
apropriado, relativo à quantidade de recursos utilizados. 
Manutenibilidade: Está ligado à capacidade do sistema de software de ser modificado, 
sendo que essa modificação pode ser uma correção, melhoria ou adaptação. 
Portabilidade: Está ligado à capacidade do sistema de software de ser portável entre 
plataformas de ambientes. 
Esses atributos possuem uma estratificação para outros atributos de qualidade, conforme 
citado também por Cortês e Chiossi (2001). 
• Funcionalidade: – Adequação: é a garantia de que o software possui as funções que 
foram definidas. – Acerácea: está relacionado ao grau de precisão dos resultados 
gerados pelo software. – Interoperabilidade: é a capacidade do software de interagir 
com outros sistemas. – Segurança de acesso: está ligado à capacidade do software de 
prevenir acessos por pessoas ou aplicações não autorizados 
Conformidade: se o software foi desenvolvido seguindo os padrões, convenções ou 
regras pré - estabelecidas no projeto. 
• Confiabilidade: – Maturidade: está relacionada à baixa frequência de falhas ou 
defeitos do software em operação. – Tolerância a falhas: está relacionada a um 
determinado nível de desempenho que o software deve atingir, mesmo em momentos 
de problemas. – Facilidade na recuperação: está ligada à capacidade do software de se 
22 
 
restabelecer, restabelecer seus dados e parâmetros sem que haja necessidade de 
intervenção, após uma falha. 
• Usabilidade: – Inteligibilidade: medida da facilidade do usuário para reconhecer a 
lógica de funcionamento do software. – Facilidade no aprendizado: medida da 
facilidade encontrada pelo usuário para aprender a utilizar o software. – 
Operacionalidade: medida da facilidade para operar o produto com segurança e sem 
falhas. 
• Eficiência: – Comportamento em relação ao tempo: está relacionado ao tempo de 
resposta e de processamento do software em seus serviços. – Utilização de recursos: 
está relacionado à quantidade de recursos utilizados (CPU, Memória, Processador) e 
ao tempo de resposta e de processamento do software em seus serviços. 
• Manutenibilidade: – Facilidade na análise: medida do esforço necessário para 
diagnosticar falhas e localizar as partes para corrigir os problemas. – Facilidade na 
alteração: medida do esforço necessário para corrigir as falhas ou adequar o produto a 
eventuais mudanças. – Facilidade na estabilização: medida do esforço necessário em 
se estabilizar o software após as alterações. – Facilidade no teste: medida do esforço 
necessário para testar o produto de software alterado. 
• Portabilidade: – Adaptabilidade: está ligado à facilidade em se adaptar o software 
para funcionar em outros ambientes. – Capacidade para ser instalado: medida do 
esforço necessário para instalar o software em um ambiente de operação. – 
Coexistência: está relacionado ao nível de conformidade do software a padrões 
referentes à portabilidade. – Capacidade para substituir: medida do esforço necessário 
em substituir um software por outro previamente especificado 
São complexos em sua documentação, rastreabilidade e validação. A qualidade na elicitação 
dos requisitos não funcionais atua como fator crítico de sucesso para o projeto de software. O 
fator de sucesso deve-se ao fato de que todo requisito não funcional especificado deve 
fornecer subsídios numéricos para que seja validado. 
Segundo Versolatto(2015) um exemplo é “um sistema de autoatendimento bancário, é 
desejável que tenhamos disponibilidade, ou seja, um equipamento deve estar disponível a 
qualquer momento que um cliente deseje efetuar um saque. No entanto, para descrevermos 
um requisito não funcional, somente o desejo não basta, precisamos de características, dados e 
números que nos possibilitem garantir que a disponibilidade será atingida ou não. Se 
especificarmos que o sistema deve estar disponível por 99,5% do tempo nos dias úteis, das 6h 
às 22h, temos subsídios suficientes para mensurar o atingimento ou não dessa meta de 
qualidade." 
23 
 
3.1 No PIM – VI Requisitos não funcionais 
 RNF Funcionalidade O usuário deve sempre estar 
com um hardware logado a 
internet para poder entrar no 
sistema. 
2 RNF Segurança de acesso Por se tratar de um sistema 
em que se emite dados 
pessoais e se tem transações 
financeiras, o sistema deve se 
preocupar com as 
informações prestadas pelo 
usuário, tendo então login e 
senha registradas com o 
intuito de evitar vazamentos 
de informações prestadas 
pelo mesmo. 
3 RNF Usabilidade Sabendo que o usuário pode 
vir a digitar login e senha 
erradas o software deve 
transmitir na tela uma 
mensagem informando o 
ocorrido voltando a tela para 
que possa ser digitado 
novamente o login e senha. 
4 RNF Inteligibilidade O software deve ter funções 
de fácil entendimento ao 
usuário. 
5 RNF Eficiência O software deve ter uma 
capacidade de desempenho 
na qualidade de acesso 
evitando travamentos ao ser 
acessado. 
6 RNF Confiabilidade O software deve permitir ao 
usuário efetuar o 
cancelamento da matricula do 
respectivo curso escolhido 
caso mesmo venha a desistir. 
7 RNF Robustez Caso o software venha a ter 
alguma falha o mesmo deve 
permitir que o usuário 
continue efetuando sua 
matricula no sistema. 
 
4 Contextos de uso: 
Contexto de uso é como vai ser utilizado, por quem, sendo realizada uma determinada 
sequência. É o que podemos chamar de 5W1H cinco W’s ( Whats, Who, When, Where, Why) 
e um H (How) 
24 
 
Why/Por que/ Motivo : representa o objetivo do processo. 
Where/Onde : representa onde o processo ( atividade) é executado, as características do 
ambiente. 
When/Quando : representa o momento que a atividade é realizado 
Who/Quem : Quem são os responsáveis pela atividade. Fazendo uma analogia com os casos 
de uso, são os atores. 
How/Como – Reunião de Todos os 5W’s. Fonte: Livro-Texto UNIP. 
No PIM – VI : 
Why – Objetivo de se realizar a matrícula no curso de informática ou artes. 
Whre/Onde – No sistema. Site de matrícula. Ambiente WEB. 
Who/Quem – Alunos realizam o cadastro e o funcionário valida as informações. 
How – Fazendo login e no site, ou pedindo informações. 
5 Regras de negócio 
Regras de negócio possuem vital importância para a “modelagem de processos de negócio”. 
Como definição segundo Versollato(2015). 
” Elas são um conjunto de restrições que definem como um processo de negócio uma 
organização deve ser executado, que, além de representar determinados 
conhecimentos a respeito de um processo, também representam importantes aspectos 
restritivos na execução deste processo (BUSINESS RULES GROUP, 2000). 
 Por exemplo senhas de acesso para login intranet. Seriam bons exemplos de regras de 
negócio associadas a esse processo: 
• O usuário só poderá fazê-lo na rede interna da empresa. 
• A senha deve ter no mínimo 8 caracteres contendo no mínimo uma letra maiúscula, e um 
caractere especial. 
As regras estão restringindo o uso de senhas, podendo variar conforme a necessidade da 
empresa. 
25 
 
Segundo Ross (2003 apud Versollato,2015p. 80),“Existem alguns princípios básicos nos quais 
devemos estar atentos quando estamos trabalhando na elicitação das regras de negócio, com 
ênfase principalmente na descrição e detalhamento delas. Alguns desses princípios são: 
• Princípio da unicidade: regras de negócio devem ser únicas. 
•Devem ser escritas e expressas de forma explícita e com linguagem clara, diminuindo 
possíveis ambiguidades. 
• Preferencialmente devem ser especificadas pelas pessoas com maior conhecimento. 
 • Como estãoem constantes mudanças, regras de negócio devem ser gerenciáveis. 
 
As regras de negócio determinam as restrições e a forma como os processos de negócio são 
efetuados e esses processos de negócio representam uma visão mais detalhada das 
funcionalidades expressas, por exemplo, nos casos de uso. 
Concluindo as regras de negócio limitam a execução dos casos de uso. É de extrema 
necessidade que as relações entre caso de uso e regras de negócio sejam respeitadas. 
Regras de negócio são susceptíveis as mudanças podendo gerar modificações nos casos de 
uso. 
Uma das formas mais comum de descrever regra de negócio, é a descrição por linguagem 
natural. 
O mais importante e determinante da linguagem natural é a preocupação em relação à 
totalidade das descrições a serem feitas no que se almeja, isto por que não se espera confusões 
no resultado. 
Quanto ao formato da documentação segundo Bezerra (2006 apud Versollato, 2015p. 81) 
propõe um formulário que contenha os seguintes elementos: 
 • identificação; 
 • descrição; 
• fonte; 
• histórico. 
26 
 
O reconhecimento certifica e dá suporte ao princípio da unicidade das regras de negócio, 
usando a linguagem natural e valendo-se sobre a fonte da rastreabilidade quanto à preferência 
das regras serem especificadas pelas pessoas com maior conhecimento. 
O histórico é primordial para administração das regras de negócio, quanto ao período de 
criação e alteração. 
É importante, em um projeto de software, a preocupação com a qualidade da documentação e 
da modelagem de casos de uso, processos de negócio e regras de negócio. 
Identificação Aluno fazer login no site – RN01 
Descrição Aluno faz login no site para poder se matricular em informática ou artes. 
Fonte Manual PIM - VI 
 
Identificação Aluno efetua a matrícula – RN02 
Descrição Aluno escolhe o curso entre matemática e artes e faz a matrícula. 
Fonte Manual PIM - VI 
 
Identificação Aluno efetua a segunda matrícula – RN03 
Descrição Aluno escolhe o curso entre matemática e artes e faz a matrícula, 
escolhendo o curso que não efetuou a matrícula da primeira vez. O aluno 
pode solicitar a segunda matrícula sempre que quiser não sendo 
necessário a efetuação ser feita em seguida da primeira. Se só for feita 
apenas uma matrícula a RN04 já é executada. Caso for feita uma 
segunda matrícula depois do logoff do site novamente a RN04 é 
executada. 
Fonte Manual PIM - VI 
 
 
Identificação Atendente faz a matrícula solicitada pelo ano – RN04 
Descrição Atende faz matrícula no curso de informática ou artes, depois é enviada 
ao sistema financeiro. Também podem ser feitas duas matrículas. Sendo 
a segunda matrícula quando o aluno quiser. 
Fonte Manual PIM - VI 
 
Identificação Aluno solicita cancelamento de curso – RN05 
Descrição Aluno escolhe o curso qual curso quer cancelar. 
Fonte Manual PIM - VI 
 
Identificação Atendente cancela o curso – RN06 
Descrição Atendente cancela o curso solicitado pelo aluno e envia para o sistema 
27 
 
financeiro. 
Fonte Manual PIM - VI 
 
Identificação Consultar informações – RN07 
Descrição Aluno consulta informações no sistema sobre cursos disponíveis, e 
informações sobre cancelamento de curso. 
Fonte Manual PIM - VI 
 
Não há histórico, pois o PIM – VI é somente para estudos, não será realizado um login real 
por exemplo. 
6 Diagrama de classe 
Tem objetivo de representar de forma estática as classe do sistema. Fonte Livro Texto 
Unidade 4 análise orientada a objetos. 
Diagrama de classe é no PIM-VI é o relacionamento entre aluno com o sistema, ao cadastrar 
uma matrícula , ou pedir informações. 
Também será anexado no sistema UNIP para melhor visualização. 
28 
 
 
Fonte : Do autor 
6.1 Boundary, Control e Entity : 
Boundary – Representa a comunicação entre o usuário e o sistema. Em português boundary 
significa fronteira. Uma fronteira entre o usuário e o sistema. Exemplo: Cliente e caixa do 
banco, aluno e site de matrícula. 
Control – Representa as unidades de controle. O aluno realizar o cadastro, mostrar na tela que 
foi concluído com sucesso, ou até retornar mensagens de erro. 
Entity – As ações do diagrama, acontecimentos do mundo real. 
O diagrama também será anexado ao site da UNIP EAD. 
29 
 
 
Fonte: Do autor. 
7 Modelo de dados (MER) 
O modelo de entidade e relacionamentos feita pelo Professor Peter Chan é a forma natural de 
se representar todas as estruturas de dados de forma natural e totalmente objetiva. 
Para fazer o MER utilizam-se entidades, atributos e relacionamentos. 
7.1 Entidades: 
Representam partes do mundo real no nosso MER, Possuímos dois tipos de entidades, físicas 
e lógicas. As físicas sendo substantivos concretos como pessoas, animais, lápis etc. As 
entidades lógicas podem ser substantivos abstratos derivados do que pretende fazer com as 
entidades físicas, por exemplo: Vendas em uma loja. As entidades são representadas por 
retângulos nomeados por substantivos. 
 Fonte: Do autor. 
 
 
7.2 Atributos: 
30 
 
São as características de uma entidade, dentro no nosso MER. Exemplo: CPF da pessoa, RG 
da pessoa, nome, endereço, telefone, e-mail etc. São representados por elipses contendo a 
característica ou mesmo por pequenos círculos ligados à entidade. 
 Fonte: Do autor 
 Fonte: Livro texto UNIP Casos de uso. 
7.3 Relacionamentos: 
Com as entidades se referenciam, trocam informações, associam - se, como se relacionam 
uma com as outras etc. Exemplo: Aluno se matricula em um curso, jogador de futebol faz um 
gol, aluno faz matrícula em um curso de ensino superior. Relacionamentos são identificados 
por losangos. 
 Fonte: Do 
autor 
7.4 Cardinalidade do Relacionamento 
31 
 
As cardinalidades são representadas por linhas e losangos. Em baixo da entidade , na figura 
abaixo e nos diagramas MER , ficam as cardinalidades mínima e máxima de um 
relacionamento. 
Onde o ” número da esquerda” da entidade pessoa associa – se com o “número da esquerda” 
da entidade ingresso. O primeiro número tem que se associar sempre com o primeiro número. 
O primeiro número sempre é o mínimo. No caso da figura somente uma pessoa pode comprar 
um ingresso. 
Um para um (1,1) – As entidades relacionam – se somente um elemento com outro. Por 
exemplo um aluno se matricula em um curso, uma pessoa pode apenas possuir um currículo, 
apenas um RG. 
 
 
Fonte: Do autor 
Um para muitos (1,1) (1,n) ou (1,n) (1, n) – 
(1,1) (1,n) - Só uma entidade de um lado, porém com muitas entidades do outro. 
Conceito de cardinalidade mínima: 
 Por exemplo uma pessoa pode comprar no mínimo um ingresso para o cinema (1,1 ) (1, n) : 
 
32 
 
Fonte: Do autor 
“Esquerda com esquerda” ou da matemática na matéria estruturas algébricas, “x com x”. 
No mínimo uma pessoa pode comprar somente um ingresso. 
7.5 Conceito cardinalidade máxima: 
Fonte: Do autor 
Uma pessoa pode comprar no máximo quantos ingressos ela quiser. Sempre maior que 1 . 
(1,n) (1,n) : 
Mínima – Uma pessoa compra um ingresso 
 Máxima – N pessoas compram N ingressos. 
Fonte: Do autor 
Muitos para muitos (n,m) (n,m) – Sempre com mais de um relacionamento para o outro da 
forma que quiser. Dois autores escrevem mais de um livro juntos. 
Além de (n,m) também pode ser representado por (* .. * ). Podemos também ter a 
cardinalidade nula, no qual não há relacionamentos. Indicada por (0) zero. 
No MER utilizamos tabelas. Cada entidade é uma tabela. Que contém seus atributos que se 
relacionam com outras entidades que também são tabelas. 
Chave primária – Atributoúnico de uma entidade. Não pode ser repetido. Por exemplo, cada 
pessoa tem seu CPF. 
33 
 
Chave estrangeira – É a chave primária de uma entidade sendo entregue a outra. 
Fonte : Do autor 
 
De forma resumida foram esses os conceitos para fazer o MER do PIM-VI da UNIP EAD. 
Nenhum modelo MER possui métodos. 
7.6 Modelos MER – Conceitual 
Modelo Conceitual – Usamos a proposta do PIM-VI da UNIP EAD para construir o modelo 
conceitual. O software utilizado foi o BR - Modelo feita na UFSC (Universidade Federal de 
Santa Catarina) e UNIVAG(MT) para a construção do modelo. O modelo conceitual é o 
primeiro passo da modelagem de dados com o objetivo de ser próxima do mundo real e 
visualmente clara ao cliente ou a pessoa que está lendo o modelo. 
Fonte: Do autor. 
Os atributos foram adquiridos seguindo a proposta do PIM-VI da UNIP-EAD. 
Aluno possui chave primária Código_Aluno. 
Curso possui chave primária Cod_Curso. 
No modelo conceitual não possui chave estrangeira. 
7.7 Modelo Lógico: 
34 
 
O modelo conceitual já foi aprovado pelo usuário, então começa o modelo lógico que diz 
como será o nosso banco de dados, e os tipos de dados , inteiro, real etc. 
Partindo do modelo conceitual, esse modelo já possui chave estrangeira. Para fazer o modelo 
lógico o primeiro passo é o mapeamento: 
7.8 Mapeamento: 
(1,n) : O lado n recebe a chave estrangeira, a FK. No nosso modelo conceitual o lado n é a 
entidade matrícula. Uma tabela recebe informações de duas. Na maioria das vezes as tabelas 
dos lados é que entregam a chave estrangeira. 
Como dito anteriormente a chave estrangeira é a chave primária colada em outra tabela. 
7.9 Outras regras 
(n, n): é criada uma nova tabela. Quando tem duas tabelas lado um, entregam a chave para a 
tabela de lado N. 
Fonte : Do autor. 
(1,1): é feito a união das tabelas, e é colocada em uma tabela só. 
O modelo lógico foi construído utilizando o software MySQL – Oracle . Não foi utilizado 
nenhum tipo de comando SQL apenas o modelo conceitual. 
 
Fonte : Do autor. 
35 
 
Observa – se as opções de manuseamento de banco de dados , que são importantes para o 
desenvolvimento dos nossos estudos: 
 
Fonte: Do autor. 
PK – Primary key 
NN – Not Null – campos que não podem ficar em branco como CPF do aluno, nome etc. 
UQ – Unique – Atributo único. Não pode ser repetido. 
AI – Auto Increment - auto incrementa as iterações: por exemplo, o usuário João tem o RA 
começando em um, Maria começando em dois... Pode-se escolher qualquer número inteiro 
(positivo ou negativo) . Muito interessante a função para não ter necessidade de digitar o 
número para o usuário sempre. Exemplo: Lista de chamada da escola. 
7.10 Modelo Físico: 
Última etapa. Deve – se conhecer o SGBD a ser utilizado. Utilizamos o SQL Server 2014, 
versão gratuita para estudos da Microsoft. Serão utilizados DDL e DCL. 
Com o SGBD corretamente instalado: 
Começamos criando um banco de dados: 
Usamos o New Query: 
 
Fonte: Do autor 
Utilizamos o comando CREATE para criar o banco de dados: Neste exemplo o banco de 
dados UNIP. 
 
36 
 
Fonte : Do autor. 
Apertamos o botão execute: 
 
Fonte: Do autor 
Para sabermos se o comando foi executado: Recebemos a mensagem de sucesso ou de erro. 
 
Fonte : Do autor. 
Podemos acidentalmente ou por algum outro motivo gerar um erro. Vamos por exemplo usar 
o comando propositalmente com o erro em CREATE escreveram CRATE. 
37 
 
Fonte : Do autor 
Pode acontecer de o banco de dados feito não aparecer no Object-Explorer : Para isso no 
próprio Object-Explorer (cuidado para não utilizar nos campos Query) utilizamos o botão 
refresh ou apertamos F5: 
Fonte: Do autor. 
Depois novamente no Query usamos o comando USE DATABASE UNIP para utilizarmos 
somente o nosso banco, e não gravar dados ou alterar outro banco de dados. 
38 
 
Fonte: Do autor. 
Para conferirmos se está usando o banco de dados UNIP observamos na parte superior na 
escolha de banco de dados. O banco de dados além do comando USE também pode ser 
escolhido pela caixa de escolhas AVAIBLE DATA BASES. 
Fonte: Do autor. 
Agora vamos construir o modelo físico do PIM-VI UNIP-EAD 
Primeiro passo é partir do modelo lógico. 
Escolher as tabelas que não possuem chaves estrangeiras. Se começar pela tabela com chave 
estrangeira não há como criar a chave, pois ela não existe em sua forma primária. 
 
Fonte: Do autor. 
Vamos criar a tabela curso. Para isso usamos o tipo CREATE . 
Copiando para o SQL Server : 
Fonte: Do autor. 
39 
 
O COD_CURSO deve ser a chave primaria. Para não haver necessidade de digitar para cada 
aluno um código usamos o IDENTITY para gera - los automaticamente. 
Idêntico para curso e matrícula. No SQL Server podemos usar a mesma Query para criar as 
duas tabelas. 
 
Fonte: Do autor. 
Adicionar as chaves estrangeiras após as tabelas estarem prontas com o ALTER TABLE; 
Fonte: Do autor 
ALTER TABLE MATRICULA 
Altera a tabela matrícula 
ADD COD_ALUNO INT NOT NULL, adiciona a tabela aluno para futuramente receber a 
chave estrangeira. 
CONSTRAINT fk_COD_ALUNO FOREIGN KEY (COD_ALUNO) 
Cria a chave estrangeira . 
40 
 
REFERENCES ALUNO usa a tabela ALUNO como referência. Para a tabela curso o 
procedimento é o mesmo. 
Podemos a partir de esses dados gerarem o MER modelo lógico pelo SQL Server. 
Fonte: Do autor. 
Botão direito do mouse em Database Diagrams e depois New Database Diagram. Dentro do 
banco de dados UNIP. 
 
Fonte: Do autor. 
Clica em Add. 
41 
 
Então o MER é gerado: 
Fonte: Do autor. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
42 
 
8 Conclusão: 
No presente PIM – VI, houve muito aprendizado. Nós, os alunos, aprendemos muito sobre 
como construir diagramas de classe, diagramas de sequência, modelagem de banco de dados 
MER e engenharia de software. Com um aprendizado moderno todas as matérias foram bem 
apresentadas facilitando a compreensão . O projeto de uma forma prática fez muita diferença 
no aprendizado. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
43 
 
Referências: 
 
VERSOLATTO, Fábio Rossi. Análise de Sistemas Orientada a Objetos. São Paulo: Editora 
Sol, 2015. 
 
PINTO, Gisele Lopes Batista. Administração de banco de dados. São Paulo: Editora Sol, 
2012. 
 
Ajuda e comentários do SQL Server. Disponível em :https://docs.microsoft.com/pt-br/sql/sql-
server/sql-server-get-help?view=sql-server-2017 Acesso em: 1 de jun. 2019.