PIM_VI - unip

Prévia do material em texto

UNIP 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
PIM VI – Projeto Integrado Multidisciplinar VI 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Polo Unip Imirim - SP 
2019 
UNIP 
Projeto Integrado Multidisciplinar 
 
 
Cursos Superiores de Tecnologia 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
PIM VI – Projeto Integrado Multidisciplinar VI 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Nome: Fábio Vicentini 
RA: 1870132 
 
Polo Unip Imirim - SP 
2019 
 
 
 
 
 
RESUMO 
 
O objetivo deste trabalho é se colocar na condição de gerente de projeto da 
empresa contratada para desenvolver sistema que controle das matrículas de cursos 
livres. Nesta condição será feita análise e avaliação do sistema proposto, elaborando 
e identificando casos de uso, descrevendo requisitos não funcionais e regras de 
negócio, construindo modelos de dados entre outras funções pertinentes a condição 
de gerente de projetos. 
Neste trabalho poderemos aplicar os conhecimentos adquiridos nas seguintes 
matérias: 
a) Análise de sistemas orientada a objetos: principalmente para descrever 
os requisitos e diagramas e casos de uso; 
b) Banco de dados: principalmente para análise dos requisitos da 
aplicação, análise do conjunto de ocorrências de dados e seus 
relacionamentos, criação da estrutura lógica do banco de dados; 
c) Gestão estratégica de recursos humanos: Melhor aproveitamento dos 
recursos humanos da empresa através do uso da tecnologia, que no 
caso em questão seria o sistema de controle de matriculas de cursos. 
Palavras-chave: gerente. sistema. requisitos. análise. modelos. 
 
 
ABSTRACT 
 
The objective of this work is to become the project manager of the contracted 
company to develop a system that controls the enrollment of free courses. In this 
condition will be made analysis and evaluation of the proposed system, elaborating 
and identifying use cases, describing nonfunctional requirements and business rules, 
building data models among other functions relevant to project manager status. 
In this work we can apply the knowledge acquired in the following subjects: 
a) Object-oriented systems analysis: mainly to describe requirements and 
diagrams and use cases; 
b) Database: mainly for analysis of the requirements of the application, 
analysis of the set of occurrences of data and their relationships, creation of the logical 
structure of the database; 
c) Strategic management of human resources: Better use of the company's 
human resources through the use of technology, which in this case would be the 
system of control of enrollment of courses. 
Keywords: manager. system. requirements. analysis. models. 
 
 
 
SUMÁRIO 
 
1. INTRODUÇÃO .......................................................................................................................................... 5 
2. IDENTIFICANDO OS CASOS DE USO .......................................................................................................... 6 
3. DIAGRAMA DE CASOS DE USO ................................................................................................................. 6 
4. RELACIONAMENTOS ................................................................................................................................ 7 
5. DESCRIÇÃO DOS CASOS DE USO .............................................................................................................. 8 
6. REQUISITOS NÃO-FUNCIONAIS ...............................................................................................................11 
7. CONTEXTO DE USO DO SISTEMA ............................................................................................................11 
8. REGRAS DE NEGÓCIO..............................................................................................................................12 
9. DIAGRAMA DE CLASSES UML..................................................................................................................13 
10. MODELO DE DADOS (MER) .....................................................................................................................14 
11. CONCLUSÃO ...........................................................................................................................................16 
12. REFERÊNCIAS ..........................................................................................................................................16 
 
5 
 
 
1. INTRODUÇÃO 
 
Uma instituição de ensino resolveu contratar uma empresa para construir um 
sistema que controle as matrículas de cursos livres, o qual tem como objetivo realizar 
o cadastro de alunos, cursos e matrículas de usuários em cursos de curta duração. O 
sistema será utilizado por atendentes e alunos matriculados. Alguns aspectos devem 
ser levados em consideração: todo acesso ao sistema é feito em terminais na escola 
por meio de login e senha. O atendente cadastra os cursos que abrangem 2 áreas 
diferentes: informática e artes. Todos os tipos de cursos possuem código, nome, data 
de início, data de término, horário, número de vagas e valor, bem como cadastra os 
alunos, informando: nome, endereço, telefone, e-mail, RG, CPF, login e senha do 
aluno. 
Ao matricular-se um aluno em um ou mais cursos, é gerado um código único, 
a data da matrícula, o valor da matrícula, o status de pagamento e o status da 
matrícula. Após o cadastro da matrícula, os dados (código matrícula) são enviados 
para o Sistema Financeiro. A matrícula pode ser cancelada por solicitação do aluno. 
No momento do cancelamento, o código da matrícula deve ser enviado para o sistema 
financeiro. 
Devem existir funções para o atendente consultar os cancelamentos por curso 
em um determinado período e listar informações de cursos disponíveis. 
Na condição de gerente de projetos da empresa contratada para desenvolver 
o sistema citado anteriormente deve ser identificado os casos de uso, elaborado o 
modelo de casos de uso, identificado relacionamentos de include, extend e 
generalização, descrever os requisitos não funcionais, identificar e descrever o 
contexto de uso, descrever as regras do negócio, elaborar o diagrama de classes de 
análise e construir o modelo de dados. 
 
6 
 
 
2. IDENTIFICANDO OS CASOS DE USO 
 
A identificação dos casos de uso tem como objetivo entender as funções do 
sistema. 
Na identificação de casos de uso utilizamos a terminologia “atores” para 
identificar os usuários que interagem com o sistema. 
Os casos de uso são descritos baseados nas necessidades desses atores, 
assim podemos compreender melhor como o sistema devera funcionar. 
Neste processo de identificação dos casos de uso podemos citar os 2 atores 
envolvidos, que seriam: 
Os alunos que utilizam a plataforma para se matricular nos cursos oferecidos 
e os atendentes que cadastram os cursos e os alunos no sistema. 
No sistema desenvolvimento foi identificado os seguintes casos de uso: 
Acesso ao sistema por meio de login e senha; 
Cadastro dos cursos no sistema, executado pelos atendentes; 
Cadastro dos alunos no sistema, executado pelos atendentes; 
Matricula nos cursos, executado pelos alunos; 
Cancelamento da matricula, executado pelos alunos; 
Consultar os cancelamentos dos cursos, executado pelos atendentes; 
Listar informações dos cursos disponíveis, executado pelos atendentes; 
 
3. DIAGRAMA DE CASOS DE USO 
O diagrama de casos de uso descreve as funcionalidades propostas para o 
sistema do ponto de vista do usuário, ajudando no levantamento dos requisitos 
funcionais e devem possuir início, meio e fim. 
7 
 
 
A seguir temos o diagrama do sistema: 
 
Figura 1 - Diagrama dos casos de uso. 
 
4. RELACIONAMENTOS 
 
Existem 3 tipos de relacionamento que seriam o include, extend e 
generalização. 
O include é utilizado quando um caso de uso é executado sempre que o caso 
deuso base for executado. 
O extend é utilizado quando um caso de uso pode ou não ser executado após 
a execução do caso de uso base. 
A generalização é utilizada quando um caso de uso faz tudo que o caso de 
uso base faz e ainda executa as próprias funções. 
No caso de include seria quando um caso de uso “A” é solicitado o caso de 
uso “B” será executada automaticamente. 
8 
 
 
No caso do extend seria quando um caso de uso “A” é solicitado o caso de 
uso “B”. 
No caso da generalização seria quando um caso de uso “A” generaliza um 
caso de uso “B”, ou seja, o caso de uso ”A” fara tudo que estiver especificado para ele 
e também tudo que estiver especificado para o item B. 
Com forme diagrama da figura 1 podemos observar que no projeto em 
questão não teremos o uso da generalização. 
No caso de uso de Login dos atendentes ao ser executado ele 
automaticamente listara todos os cursos cadastrados, assim fica determinado que 
será uma relação de include de Login para Lista dos cursos, em relação aos demais 
elementos eles poderão ou não ser executados, dependendo da necessidade do 
atendente, por essa razão a relação entre eles é denominada de extend. 
No caso de Login dos alunos ele poderá ou não realizar as outras ações o que 
implica em relações de extend com todos os casos de uso conforme o diagrama 
apresentado na figura 1. 
 
5. DESCRIÇÃO DOS CASOS DE USO 
 
Neste capitulo será descrito cada caso de uso, identificando o ator, a 
descrição, a pré-condição, o fluxo principal e pós condição caso exista. 
No projeto em questão não foi necessário fluxo secundário. 
A seguir temos as descrições completas para cada caso de uso do sistema 
de matricula de cursos proposto. 
 
 
 
9 
 
 
Caso de uso - Login 
Ator - Atendente 
Descrição 
Esta ação permite o acesso ao sistema mediante login e 
senha 
Pré-condição O atendente preenche o login e a senha 
Fluxo principal 
1- O atendente acessa o sistema através de login e senha 
2- A tela mostra automaticamente todos os cursos 
cadastrados no sistema 
3 - Exibe as opções de cadastrar aluno, cadastrar cursos, 
e listar os cancelamentos de matricula 
Pós-condição - 
Tabela 1 – Caso de uso – Login - atendente 
 
Caso de uso - Lista os cursos 
Ator - Atendente 
Descrição Esta ação lista os cursos cadastrados 
Pré-condição O atendente faz login no sistema 
Fluxo principal 1-O atendente loga no sistema 
Fluxo secundário 
1- O atendente cadastra algum curso 
2- O atendente cadastra algum aluno 
Pós-condição - 
Tabela 2 – Caso de uso – Lista os cursos – atendente 
 
Caso de uso - Cadastro de cursos 
Ator - Atendente 
Descrição Esta ação permite cadastrar novos cursos 
Pré-condição O atendente faz login no sistema 
Fluxo principal 
1- O atendente acessa a tela de cadastro de cursos 
2- O atendente preenche os dados do curso 
3 - O curso é cadastrado com sucesso 
4 - A lista de cursos é atualizada 
Pós-condição Os alunos poderão se cadastrar no curso cadastrado 
Tabela 3 – Caso de uso – Cadastro de cursos – atendente 
 
Caso de uso - Consulta dos cancelamentos dos cursos 
Ator - Atendente 
Descrição Esta ação permite cadastrar novos cursos 
Pré-condição O atendente faz login no sistema 
Fluxo principal 
1- O atendente acessa a tela de consulta de 
cancelamentos 
2- É listado todos os cancelamentos de cursos 
Pós-condição O atendente pode voltar a tela principal do sistema 
Tabela 4 – Caso de uso – Consulta dos cancelamentos - atendente 
10 
 
 
Caso de uso - Cadastro dos alunos 
Ator - Atendente 
Descrição Esta ação permite cadastrar novos alunos 
Pré-condição O atendente faz login no sistema 
Fluxo principal 
1- O atendente acessa a tela de cadastro 
2- O atendente preenche os dados do aluno 
3- O aluno é cadastrado com sucesso 
Pós-condição Os alunos poderão acessar o sistema 
Tabela 5 – Caso de uso – Cadastro dos alunos – atendente 
 
Caso de uso - Login 
Ator - Aluno 
Descrição 
Esta ação permite o acesso ao sistema mediante login e 
senha 
Pré-condição O aluno estar cadastrado no sistema 
Fluxo principal 
1- O aluno acessa o sistema através de login e senha 
2- A tela principal com as opções aparecem na tela 
Pós-condição - 
Tabela 6 – Caso de uso – Login – aluno 
 
Caso de uso - Matricular nos cursos 
Ator - Aluno 
Descrição Esta ação permiti o aluno se matricular nos cursos 
Pré-condição O curso estar cadastrado no sistema 
Fluxo principal 
1- O aluno acessa a tela de matricula 
2- O aluno escolhe o curso desejado 
3- O aluno confirma sua matricula no curso 
Pós-condição - 
Tabela 7 – Caso de uso – Matricular nos cursos – aluno 
 
Caso de uso - Cancelar matrícula 
Ator - Aluno 
Descrição Esta ação permiti o aluno cancelar sua matricula no curso 
Pré-condição O aluno tem que estar cadastrado em algum curso 
Fluxo principal 
1- O aluno acessa a tela de cancelamento 
2- O aluno escolhe o curso que quer cancelar sua 
matricula 
3- O aluno confirma o cancelamento 
Pós-condição 
O curso cancelado sera atualizado na tela de consulta de 
cancelamentos feita pelo acesso dos atendentes 
Tabela 8 – Caso de uso – Cancelar matrícula – aluno 
 
 
 
11 
 
 
6. REQUISITOS NÃO-FUNCIONAIS 
 
Os requisitos não funcionais são aqueles relacionados a usabilidade do 
sistema, eles descrevem como o sistema funcionara, e é avaliado por testes e de 
forma subjetiva. 
Alguns exemplos de requisitos não funcionais seriam requisitos de 
desempenho, requisitos da interface externa do sistema, restrições de projeto e 
atributos da qualidade. 
Neste projeto listamos os requisitos não funcionais esperados pelo sistema 
proposto. 
Desempenho: É esperado que o sistema tenha respostas ágeis aos 
comandos mesmos em momentos de picos de múltiplos acessos ao sistema por parte 
de alunos e atendentes. 
Disponibilidade: recuperação de dados após queda de energia, e fácil 
manutenção evitando janelas longas de manutenção. 
Segurança: O sistema deve ser seguro utilizando criptografia de senhas de 
usuários e protocolos de segurança adequados. 
Usabilidade: O sistema deve ser de fácil uso por parte dos usuários a maior 
parte das informações e ações devem ser executadas com a menor quantidade de 
cliques possíveis, o sistema deve possuir recursos para acessibilidade de dficientes 
visuais. 
Compatibilidade: o sistema deve ser compatível com os sistemas 
operacionais Windows e Linux e com os browsers. 
Confiabilidade: Deve haver procedimento de backup automático dos dados do 
sistema, e recurso para recuperação de dados em casos de falta de energia. 
 
7. CONTEXTO DE USO DO SISTEMA 
 
 
12 
 
 
O contexto de uso do sistema está ligado as pessoas interessadas no sistema, 
é muito útil para podermos compreender as necessidades dos usuários que 
precisaremos ter no sistema para que ele funcione de forma satisfatória e atenda as 
expectativas esperadas. 
Usuários: Atendentes e alunos 
Tarefas: Os alunos poderão se matricular nos cursos ou cancelar suas 
matriculas. Os atendentes poderão listar os cursos, cadastrar novos cursos, cadastrar 
novos alunos e listar os cancelamentos de matriculas. 
Ambiente: Os alunos e atendentes só poderão utilizar o sistema nos terminais 
da escola. 
 
8. REGRAS DE NEGÓCIO 
 
 
As regras de negócio são requisitos que definem ou restringem as funções 
que devem ser desenvolvidas para que todo o sistema funcione da forma esperada. 
A maior parte dos requisitos funcionais de um sistema estão interligados com 
as regras de negócios definidas para o mesmo. 
As regras de negócio desenvolvidas para o sistema de controle de matricula 
de cursos foram definidas da seguinte forma: 
O cadastro de atendentes e alunos devem possuir as seguintes informações 
obrigatórias: e-mail, senha, nome completo, CPF, RG, endereço e telefone. 
As senhas de acesso ao sistema devem ter entre 8 e 16 dígitos. 
Os acessos ao sistema só podem ser realizados nos terminais da escola. 
Os cursos cadastrados devem possuir código, nome, datade início, data de 
término, horário, número de vagas e valor. 
O sistema deve permitir múltiplas matrículas. 
13 
 
 
Cada matricula deve ter um código único, data da matrícula, valor da 
matrícula, status de pagamento e status da matrícula. 
Os dados da matricula devem ser enviadas para o sistema financeiro. 
As matriculas só poderão ser canceladas por solicitação dos alunos. 
O código das matriculas canceladas devem ser enviadas para o sistema 
financeiro. 
 
9. DIAGRAMA DE CLASSES UML 
 
 
O diagrama de classes UML é um modelo padronizado que tem como objetivo 
descrever o que o sistema a ser feito possui, e representa as classes e as relações 
que as mesmas possuem entre si dentro sistema. 
Este diagrama é de grande utilidade para o desenvolvimento do sistema pois 
cada classe neste diagrama representa uma tabela de banco de dados, ele é de 
grande ajuda pois ele serve para ilustrar os modelos de dados, entender a visão geral 
do sistema, expressas visualmente as necessidades do mesmo criar gráficos que 
destaquem códigos necessários que devem ser implementados ao sistema para seu 
funcionamento e fornecer uma descrição dos tipos utilizados em um sistema. 
O diagrama de classes é composto pela parte superior onde temos o nome 
da classe, parte do meio onde encontramos todos os atributos dessa classe, e aparte 
inferior onde temos listado todos os métodos dessa classe. 
A seguir temos o diagrama de classes UML do sistema proposto. 
14 
 
 
 
Figura 2 - Diagrama de classes 
Como podemos observar na Figura 2 o sistema apresenta as classes 
Atendente, Cursos e Aluno, Cada uma dessas classes apresenta atributos e métodos 
específicos e cada classe é por si só é também uma tabela de banco de dados que o 
sistema deverá ter para o funcionamento correto do mesmo. 
 
 
10. MODELO DE DADOS (MER) 
 
 
Utilizamos o MER para descrever as entidades envolvidas no sistema, seus 
atributos e o relacionamento que elas possuem entre si. 
O MER representara de forma abstrata a estrutura do banco de dados do 
sistema a ser construído. 
A seguir temos o diagrama do MER do sistema. 
15 
 
 
 
Figura 3 - Modelo de dados - MER 
Conforme podemos observar na Figura 3 o diagrama do sistema proposto 
temos 3 entidades, cada uma dessas entidades representa um tabela do banco de 
dados, cada atributo dessas entidades representa uma coluna do banco de dados. 
 
16 
 
 
11. CONCLUSÃO 
 
 
Este trabalho permitiu perceber a importância de diversas etapas na 
modelagem de um sistema. Identificar os casos de uso foi de extrema importância 
para compreender como funcionaria o sistema proposto, pois ao realizarmos essa 
atividade, temos a base para podermos mostrar o diagrama de casos de uso, que 
nada mais é do que descrevermos de uma forma visual e mais clara como nosso 
sistema funcionara. 
Após essas duas etapas descrevemos os casos de uso de forma detalhada 
suas condições, os atores e o fluxograma, essa etapa tem um detalhamento descritivo 
maior, ou seja, nos aprofundamos mais no sistema, e assim podemos identificar erros 
ou possíveis falhas que tenha passado nas etapas anteriores. 
Quando definimos as regras de negócio, podemos identificar se existe algo 
planejado para o sistema que vai contra as regras de negócio definidas, caso exista 
nesta etapa podemos voltar e fazer as alterações para adaptar o sistema as regras. 
Por último, temos claramente a definição de nossas tabelas de banco de 
dados e o relacionamento entre elas, o que é de suma importância na hora de 
desenvolvermos os mesmos. 
Toda essa etapa anterior a codificação de um sistema, é a base para o 
desenvolvido de um sistema, dessa forma os desenvolvedores poderão trabalhar em 
cima dessas definições e desenvolverem seus trabalhos de forma mais eficiente e 
com menos retrabalhos. 
 
12. REFERÊNCIAS 
Portal Devmedia, Dísponivel em: <https://www.devmedia.com.br/o-que-e-
uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408> Acesso em 
07/05/2019. 
Portal Devmedia, Dísponivel em: <https://www.devmedia.com.br/artigo-
engenharia-de-software-3-requisitos-nao-funcionais/9525> Acesso em 07/05/2019. 
https://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408
https://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408
https://www.devmedia.com.br/artigo-engenharia-de-software-3-requisitos-nao-funcionais/9525
https://www.devmedia.com.br/artigo-engenharia-de-software-3-requisitos-nao-funcionais/9525
17 
 
 
Site Lucidchart, Dísponivel em: <https://www.lucidchart.com/pages/pt/o-que-
e-diagrama-de-classe-uml> Acesso em 08/05/2019. 
Portal Devmedia, Dísponivel em: <https://www.devmedia.com.br/modelo-
entidade-relacionamento-mer-e-diagrama-entidade-relacionamento-der/14332> 
Acesso em 10/05/2019. 
 
 
https://www.lucidchart.com/pages/pt/o-que-e-diagrama-de-classe-uml
https://www.lucidchart.com/pages/pt/o-que-e-diagrama-de-classe-uml
https://www.devmedia.com.br/modelo-entidade-relacionamento-mer-e-diagrama-entidade-relacionamento-der/14332
https://www.devmedia.com.br/modelo-entidade-relacionamento-mer-e-diagrama-entidade-relacionamento-der/14332