UNIVERSIDADE PAULISTA PIM VI

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

UNIVERSIDADE PAULISTA 
PROJETO INTEGRADO MULTIDISCIPLINAR 
CURSO SUPERIOR DE TECNOLOGIA 
 
 
 
 
 
 
PIM VI – PROJETO INTEGRADO MULTIDISCIPLINAR 
PROJETO DE UM SISTEMA DE VENDA DE LIVROS PARA WEB 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 SÃO FRANCISCO DO GUAPORÉ 
2018 
 
 
UNIVERSIDADE PAULISTA 
PROJETO INTEGRADO MULTIDISCIPLINAR 
CURSO SUPERIOR DE TECNOLOGIA 
 
 
 
 
 
 
PIM I – PROJETO INTEGRADO MULTIDISCIPLINAR 
PROJETO DE UM SISTEMA DE VENDA DE LIVROS PARA WEB 
 
 Vanderlan Luciano da Silva 1633080 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 SÃO FRANCISCO DO GUAPORÉ 
2018 
 
 
RESUMO 
O estudo proposto é referente a realização de um projeto de um sistema de vendas 
de livros que estará disponível na internet no qual se denomina QR livros. Para esses 
objetivos será definida uma identificação completa do caso de uso do programa e a 
elaboração de diagramas (UML) e um diagrama de classe de análise. Será descrito 
também as regras de negócio bem como a construção do modelo de dados (MER) do 
software, desse modo, realizando a modelagem inicial do sistema. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Palavras – Chaves: Classe, software, dados 
 
 
 
 
ABSTRACT 
The proposed study is related to the realization of a project of a sales system of books 
that will be available on the internet in what is called QR books. For these purposes a 
complete identification of the use case of the program and the elaboration of diagrams 
(UML) and an analysis class diagram will be defined. It will also describe the business 
rules as well as the construction of the data model (MER) of the software, thus 
performing the initial modeling of the system. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Keywords: Class, software, data 
 
 
SUMÁRIO 
 
1. INTRODUÇÃO ............................................................................................ 6 
2. DESENVOLVIMENTO ................................................................................. 7 
2.1. Engenharia de requisitos ....................................................................... 7 
2.2. Documento de Especificação de Requisitos .................................... 8 
2.2.1. Requisitos funcionais .................................................................. 8 
2.2.2. Requisitos não-funcionais ........................................................... 9 
2.3. Modelagem de caso de uso .............................................................. 10 
2.3.1. Diagrama de caso de uso .......................................................... 10 
2.3.2. Descrição do caso de uso ......................................................... 12 
2.3.3. Protótipos de tela do caso de uso ............................................ 16 
2.4. Regras de negócio ............................................................................ 17 
2.5. Diagrama de classe de análise ........................................................ 18 
2.6. Modelo de dados MER ...................................................................... 20 
2.6.1. Diagrama MER ............................................................................ 20 
3. CONCLUSÃO ............................................................................................ 21 
 
6 
 
1. INTRODUÇÃO 
A programação orientada a objetos (POO), é um excelente modelo de análise, 
projeto e programação de software, pois é muito simples abstrair os dados e seus 
conceitos estão intrínsecos na realidade a nossa volta. De um modo geral a principal 
característica de qualquer objeto está no seus atributos e métodos bem como sua 
visibilidade, dessa forma, qualquer problema pode ser solucionado por meio de 
classes. 
Devido à grande facilidade de abstração de dados que o paradigma de 
orientação a objetos possibilita é possível realizar uma modelagem e análise de forma 
bastante abstrata de qualquer problema que se pretende resolver, ou qualquer 
solução que se deseja criar. 
Uma livraria resolveu desenvolver um sistema online, no qual irá vender livros 
para seus clientes de forma completamente automatizada e eficiente, desse modo, 
partindo para modelagem orientada a objetos (MOO), será desenvolvido então 
modelos do caso de uso, diagramas do caso de uso, diagrama de classe de análise, 
descrição dos requisitos e elaboração de um modelo de banco de dados (MER). 
Uma das principais importâncias da construção dessa estrutura abstrata é a 
representação simples dos requisitos e dados de modo a simplificar a grande 
complexidade que existe na construção do software, tornando não só o projeto, mas 
a implementação algo fácil de ser elaborado, onde as correções de erros são mais 
simples que no paradigma procedural. 
O sistema QR livros será projetado atendendo respectivamente toda a 
modelagem de requisitos, dada sua importância, descrevendo o caso de uso, 
elaborando pôr fim a modelagem de banco de dados. 
 
7 
 
2. DESENVOLVIMENTO 
 
2.1. Engenharia de requisitos 
De acordo com Sommerville, podemos dizer que as necessidades dos clientes 
podem ser traduzidas como condição para que uma determinada funcionalidade de 
um programa seja implementada. Portanto, a engenharia de requisitos neste contexto 
tem o papel de apresentar os métodos e processos para que o programa tenha essa 
funcionalidade. [1] 
A finalidade é justamente essa, de desenvolver sistemas que verdadeiramente 
atendam às necessidades dos clientes, pois, atualmente existe ainda uma grande 
carência e pouca preocupação com a engenharia de requisitos nas empresas 
desenvolvedoras de software. Devido a esse aspecto o cliente tem seu projeto 
frustrado e não implementado de forma que atenda verdadeiramente sua real 
necessidade. 
Para analisar de forma percentual essa realidade vamos ao estudo proposto 
pelo grupo de pesquisa dos Estados Unidos chamado The Standish Group. [2] 
 
 Figura 02 – Projetos implementados em gráfico 
 
 Fonte: autoria própria 
 
 
 
8 
 
2.2. Documento de Especificação de Requisitos 
 
2.2.1. Requisitos funcionais 
De acordo com o site fattocs [3]. 
 
Um requisito funcional define uma função de um sistema de software ou seu 
componente. O requisito funcional representa o quê o software faz, em 
termos de tarefas e serviços. Uma função é descrita como um conjunto de 
entradas, seu comportamento e as saídas. (Fattocs) 
 
Abaixo será descrito os requisitos funcionais do sistema de venda de livros QR 
livros respectivamente: 
RF1 – O cliente deverá realizar vendas de livros pela internet. 
RF2 – O cliente deve ter acesso ao programa por meio de um login e senha. 
RF3 – Usuário que não tiver um login e senha válidos deverá realizar um 
cadastro. 
RF4 – Para realizar o cadastro o usuário deverá informar o nome, endereço, 
telefone, data de nascimento, login e senha. 
RF5 – Após realizado o login o usuário deverá escolher o livro que deseja 
comprar. 
RF6 – Após a escolha do livro o usuário deverá efetuar a compra por meio do 
cartão de credito. 
RF7 – Caso o livro escolhido pelo usuário esteja indisponível, ele deverá fazer 
uma reserva. 
RF8 – A reserva do livro
será feita consultando um sistema de controle de 
estoque externo 
RF10 – A validação do cartão de credito deverá ser validada pelo sistema 
externo da operadora de cartão de crédito. 
 
 
9 
 
2.2.2. Requisitos não-funcionais 
Podemos dizer que esse tipo de requisito é a aplicação dos termos referente a 
usabilidade, confiabilidade, segurança, disponibilidade, manutenção e tecnologias 
envolvidas. Estes requisitos dizem respeito a como as funcionalidades serão 
entregues ao usuário do software. A importância desse fato de acordo com os literatos 
é que os requisitos funcionais não são suficientes para entregar um software que 
atenda todas as expectativas dos clientes, visto que eles não são funcionais porem 
são requisitos válidos para qualquer sistema de software. [3] 
Abaixo será descrito os requisitos funcionais não-funcionais sistema de venda 
de livros QR livros. 
Requisitos de produto: 
RNF1 – O sistema deverá ter alta disponibilidade 24hs por dia, 7 dias por 
semana. 
RNF2 – O sistema deverá ser executado em um servidor web. 
RNF3 – O sistema deverá ser capaz de processar 30 operações ao mesmo 
tempo. 
RNF4 – O sistema deve ter uma interface simples e intuitiva. 
Requisitos Organizacional: 
RNF5 – Um relatório de acompanhamento deverá ser fornecido toda segunda-
feira. 
RNF6 – O sistema deve ser desenvolvido em linguagem PHP. 
Requisitos Externos: 
RNF7 – O sistema deverá se comunicar com o banco SQL Server. 
RNF8 – O sistema não apresentará aos usuários quaisquer dados de cunho 
privativo. 
RNF9 – O sistema deverá atender às normas legais do direito do consumidor. 
 
 
10 
 
2.3. Modelagem de caso de uso 
Vimos que a engenharia de requisitos é um conjunto de métodos de 
procedimentos e ferramentas no qual tem o objetivo de descobrir, analisar, 
documentar, verificar e validar esses requisitos. 
O objetivo agora é representar a modelagem de caso de uso relativo ao sistema 
QR livros, uma abordagem que combina métodos e ferramentas e que cumpra com 
os objetivos a serem atingidos na fase de análise de requisitos. 
Modelo de caso de uso é uma representação das funcionalidades de um 
determinado sistema externamente observáveis e elementos externos aos outros 
sistemas que interagem com ele. [4] Desse modo podemos dizer que o caso de uso é 
a descrição de uma determinada ação ou comportamento de um sistema que produz 
um resultado para um determinado agente externo a esse sistema. 
Segundo Ivar Jacobson, podemos dizer que um caso de uso é um "documento 
narrativo que descreve a sequência de eventos de um ator que usa um sistema para 
completar de eventos de um ator que usa um sistema para completar um processo". 
[5] 
 
2.3.1. Diagrama de caso de uso 
Neste momento, iremos descrever o diagrama de caso de uso do sistema QR 
livros nos quais serão necessários para criação da descrição textual de cada caso de 
uso. 
Diagrama de caso de uso é uma representação gráfica do sistema de modo a 
descrever as funcionalidades que vão de encontro com as necessidades do cliente. É 
então um modelo gráfico utilizado para explicitação das funcionalidades do software. 
[5] 
Faremos uso da UML uma linguagem de modelagem unificada para a 
representação gráfica do modelo de caso de uso, pois, ela possui elementos de 
modelagem gráficos que representam visões de um sistema de software e possui 
regras e sintaxe próprias. [6] 
 
11 
 
Abaixo temos uma imagem do diagrama de caso de uso do programa QR livros, 
com as devidas especificações como fronteira, inclusão e extensão: 
 
 Figura 03 – Diagrama de caso de uso 
 
 Fonte: autoria própria 
 
12 
 
2.3.2. Descrição do caso de uso 
 
Abaixo será mostrado uma descrição do caso de uso do sistema QR livros 
através de imagens de gráficos, mostrando todas as descrições de caso de uso 
elaborado no diagrama de caso de uso. 
 
 Figura 04 – Descrição do caso acessar programa 
 
 Fonte: autoria própria 
 
 
 
13 
 
 Figura 05 – Descrição do caso realizar cadastro 
 
 Fonte: autoria própria 
14 
 
 Figura 06 – Descrição do caso escolha de livros 
 
 Fonte: autoria própria 
15 
 
 Figura 07 – Descrição do caso comprar livros 
 
 Fonte: autoria própria 
 
 
 
 
 
 
 
 
 
 
16 
 
2.3.3. Protótipos de tela do caso de uso 
Protótipo de tela do caso de uso UC001: 
 Figura 08 – Protótipo de tela uc001 
 
 Fonte: autoria própria 
 
Protótipo de tela do caso de uso UC002: 
 Figura 09 – Protótipo uc002 
 
 Fonte: Autoria própria 
 
 
 
17 
 
2.4. Regras de negócio 
Pode se dizer que regras de negócio são declarações formais sobre a forma 
como a empresa realiza a prestação de serviço. Elas refletem então, as políticas de 
negociações entre a empresa e seus clientes ou um serviço. 
Essas prescrições são de vital importância para uma organização pois visa a 
melhor satisfação de seus clientes. As diretrizes de negócio são de vital importância 
pois deve existir claro e bem definido conceitos e declarações sobre as regras de 
negócio, no desenvolvimento de qualquer sistema. [7] 
Abaixo serão descritas as regras de negócio do sistema QR livros: 
 Figura 10 – Regras de negócio RN01 
 
 Fonte: Autoria própria 
 
 Figura 11 – Regras de negócio RN02 
 
 Fonte: Autoria própria 
 
 
 
 
 
 
18 
 
 Figura 12 – Regras de negócio RN03 
 
 Fonte: Autoria própria 
 
 
 
2.5. Diagrama de classe de análise 
Podemos dizer que todo e qualquer objeto dentro de um sistema adquire uma 
responsabilidade, ou seja, uma obrigação que ele precisa realizar para que 
determinado objetivo dentro do sistema seja realizado. [5] 
No caso do sistema QR livros, temos que necessariamente definir dentro desse 
sistema a divisão de determinação, dessa forma iremos criar o diagrama de classe de 
análise de modo a ilustrar essas questões relevantes em qualquer sistema. 
Abaixo teremos um exemplo voltando para a análise do sistema QR livros. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
19 
 
 Figura 12 – Diagrama de classe de análise QR livros 
 
 
 Fonte: Autoria própria 
20 
 
2.6. Modelo de dados MER 
Os objetos ou partes envolvidas um domínio, também chamados de entidades, 
podem ser classificados como
físicos ou lógicos, de acordo sua existência no mundo 
real. Entidades físicas: são aquelas realmente tangíveis, existentes e visíveis no 
mundo real, como um cliente (uma pessoa, uma empresa) ou um produto (um carro, 
um computador, uma roupa). 
Já as entidades lógicas são aquelas que existem geralmente em decorrência 
da interação entre ou com entidades físicas, que fazem sentido dentro de um certo 
domínio de negócios, mas que no mundo externo/real não são objetos físicos (que 
ocupam lugar no espaço). São exemplos disso uma venda ou uma classificação de 
um objeto (modelo, espécie, função de um usuário do sistema). [5] 
2.6.1. Diagrama MER 
Abaixo temos o diagrama entidade relacionamento do sistema QR livros: 
 
 Figura 13 – Diagrama MER QR livros 
 
 Fonte: Autoria própria 
 
21 
 
3. CONCLUSÃO 
O desenvolvimento do presente estudo é uma das primeiras etapas de análise 
de um sistema, que com base nas definições dos autores procura se explicar e 
elucidar os pontos referente ao sistema denominado QR livros. É importante notar 
também, que o programa foi desenvolvido com base nos conceitos adquiridos de cada 
fase de modelagem de dados explicitada. 
De um modo geral o sistema QR livros por ser um sistema complexo, mostra 
se bastante simples diante das técnicas de levantamento de requisitos, modelagem 
de caso de uso, diagrama de classes de análise, modelagem conceitual de dados, 
pois, se trata na verdade de uma grande abstração de dados, fundamental para o bom 
desenvolvimento de um software atualmente. 
Devido ao alto nível de abstração de dados na fase de análise de qualquer 
sistema de software, ficou evidente que o estudo e o desenvolvimento da modelagem 
desse sistema foram realmente alcançados com sucesso. 
A engenharia de requisitos fez com que em um âmbito geral, se conhecesse 
de forma bastante clara os requisitos funcionais e não funcionais ao programa de 
venda de livros pela internet. 
A modelagem de caso de uso deu uma visão clara de como os diversas 
funcionalidade se relacionam, facilitando o entendimento de cada evento foi proposto 
uma ficha descritiva com seu respectivo ID, assim ficou fácil a identificação de cada 
funcionalidade. 
O diagrama de classe de Análise, sendo ele um diagrama (UML), fomentou a 
realização da visão estática do sistema, dando ênfase a suas multiplicidade, 
agregação e composição do sistema QR livros, também definiu suas fronteiras, classe 
de controle e suas entidades. 
Daí a importância da pesquisa e o estudo da modelagem feitas com a (UML) 
para as empresas que desenvolve ou implementa novos recursos em seus programas 
de modo a proporcionar satisfação do cliente e menor custo de implementação. 
O objetivo do estudo era a realização da modelagem de análise do sistema QR 
livros, portanto foi realizado com sucesso atendendo as definições da literatura. 
22 
 
BIBLIOGRAFIA 
 
1. SOMMERVILLE, I. Engenharia de Software. 6°. ed. São Paulo: Pearson, 2011. 
2. JENNIFER. THE STANDISH GROUP , 1998. Disponivel em: 
<https://www.standishgroup.com/>. Acesso em: 23 abr. 2018. 
3. VAZQUEZ, C. E. Engenharia de Requisitos: Software Orientado ao Negócio. 
fattocs, 2016. Disponivel em: <http://www.fattocs.com/pt/livro-ereq>. Acesso em: 
22 abr. 2018. 
4. WAZLAWICK, R. Engenharia de Software. 1°. ed. [S.l.]: Elsevier, 2013. 
5. SOMMERVILLE. ENGENHARIA DE SOFTWARE. 9°. ed. São paulo: Pearson, 
2011. 
6. ROSSI, F. Análise de sistemas orientado a objetos. São paulo: Sol , 2015. 
7. CAVALCANTE, R. Quais são as etapas da solução de regras de negócio? ASBPM, 
2016. Disponivel em: <http://www.asbpm.com.br/blog/quais-sao-as-etapas-da-
solucao-de-regras-de-negocio/>. Acesso em: 23 maio 2018.