ANALISE E DESENVOLVIMENTO DE SISTEMAS

OTÁVIO AUGUSTO ROSA BAIO RA: 2029914

JEFERSON COSTA DA SILVA RA: 0545094

PROJETO INTEGRADO MULTIDISCIPLINAR

ARARAQUARA, SP
2019
OTÁVIO AUGUSTO ROSA BAIO RA: 2029914
JEFERSON COSTA DA SILVA RA: 0545094

PROJETO INTEGRADO MULTIDISCIPLINAR

Trabalho bimestral apresentado ao curso

de Análise e Desenvolvimento de Sistemas
da Universidade Paulista - UNIP

ARARAQUARA, SP
2019
 OTÁVIO AUGUSTO ROSA BAIO RA: 2029914
JEFERSON COSTA DA SILVA RA: 0545094

PROJETO INTEGRADO MULTIDISCIPLINAR

Trabalho bimestral apresentado ao curso

de Análise e Desenvolvimento de Sistemas
da Universidade Paulista - UNIP

Aprovado em:

BANCA EXAMINADORA
_______________________/__/___

Universidade Paulista – UNIP

 RESUMO

O presente projeto demonstra o levantamento e a análise de requisitos de um sistema

para empresa destinada à venda de jogos eletrônicos, acessórios e produtos geek,
utilizando as técnicas aprendidas.

Todo projeto tem como objetivo aprofundar estudos sobre as ideias apresentadas nas
matérias Análise de Sistemas Orientada a Objetos, Banco de Dados e Gestão
Estratégica de RH.

O conhecimento da Análise de Sistemas Orientada a objetos e Banco de Dados torna

uma determinada percepção intelectual, dentro de todo conteúdo estudado.

A Gestão Estratégica de Recursos Humanos é um conjunto de práticas e

ferramentas apoiadas em políticas e normas estabelecidas e reconhecidas com
o objetivo de assegurar o continuado desenvolvimento, comprometimento e
valorização das pessoas envolvidas na manutenção, crescimento e obtenção do
sucesso dos negócios, sempre buscando atingir os melhores níveis de
excelência, produtividade e competitividade.

Entretanto, todo projeto estará em torno dessas matérias, trazendo o melhor

entendimento de cada situação a ser apresentada e tornando assim toda
complexibilidade facilitada para o entendimento.

Palavras-chave: Estratégica, percepção, Sistemas, Projeto.

 ABSTRACT

This project demonstrates the survey and analysis of requirements of a system for a
company destined to the sale of electronic games, accessories and geek products,
using as learned techniques.

The entire project aims to deepen studies on how to analyze the analysis of Object
Oriented Systems, Database and Strategic HR Management.

The knowledge of Analysis of Object Oriented Systems and Database becomes an

intellectual perception, within all the studied content.

Strategic Human Resource Management is a set of practices and tools supported by

policies and standards and recognized in order to maintain the development,
commitment and appreciation of people who use business maintenance, growth and
performance, always seeking to reach the best levels of excellence, students and
candidates.

However, the entire project can be placed around these matters, bringing the best
understanding of each situation to be published and thus making all complexity easier
to understand.

Key words: Strategic, perception, Systems, Project.

 LISTA DE ILUSTAÇÕES

Figura 1 – casos de uso - estoquista (autoria própria) .......................................................................... 24

Figura 2 - Diagrama de atividades - estoquista (autoria própria) ......................................................... 25
Figura 3 - Casos de uso - atendente (autoria própria) .......................................................................... 26
Figura 4 - Diagrama de atividades - atendente (autoria própria) ......................................................... 28
Figura 5 - Casos de uso - supervisor (autoria própria) .......................................................................... 29
Figura 6 - Diagrama de atividades - supervisor (autoria própria) ......................................................... 30
Figura 7 - Diagrama de classes (autoria própria) .................................................................................. 32
Figura 8 - MER – Esboçando toda linha de casos do projeto (autoria própria) .................................... 34
 LISTA DE TABELAS

Tabela 1 - requisitos funcionais (autoria própria) ................................................................................. 21

Tabela 2 - requisitos não funcionais (autoria própria) .......................................................................... 21
Tabela 3 - Descrição de casos de uso - estoquista - RF01 - (autoria própria) ....................................... 24
Tabela 4 - Descrição de casos de uso - estoquista - RF02 - (autoria própria) ....................................... 25
Tabela 5 - Descrição de casos de uso - atendente - RF03 - (autoria própria) ....................................... 26
Tabela 6 - Descrição de casos de uso - atendente - RF06 - (autoria própria) ....................................... 27
Tabela 7 - Descrição de casos de uso - atendente - RF05 - (autoria própria) ....................................... 27
Tabela 8 - Descrição de casos de uso – supervisor – RF07 - (autoria própria)...................................... 29
Tabela 9 - Descrição de casos de uso – supervisor – RF07 - (autoria própria)...................................... 30
 SUMÁRIO

1. INTRODUÇÃO .............................................................................................................................. 8
2. SOFTWARE PARA VENDA DE PRODUTOS ...................................................................... 10
3. MOTIVAÇÃO PARA IMPLEMENTAÇÃO.............................................................................. 11
4. FUNDAMENTAÇÃO TEÓRICA ............................................................................................... 12
4.1. Comunicação .......................................................................................................................... 13
4.2. Planejamento .......................................................................................................................... 13
4.3. Modelagem .............................................................................................................................. 14
4.4. Construção .............................................................................................................................. 15
4.5. Emprego................................................................................................................................... 15
4.6. Metodologia de desenvolvimento ........................................................................................ 16
5. BANCO DE DADOS .................................................................................................................. 17
5.1. Exemplos de utilização .......................................................................................................... 18
6. AMBIENTE DE TRABALHO .................................................................................................... 20
7. DESENVOLVIMENTO E MÉTODOS...................................................................................... 21
7.1. Analise de requisitos do sistema.......................................................................................... 21
7.2. Requisitos funcionais ............................................................................................................. 21
7.3. Requisitos não funcionais ..................................................................................................... 21
7.4. Regras de negócio ................................................................................................................. 22
7.5. Descrição de casos de uso estoquista................................................................................ 24
7.5.1. Diagrama de atividades estoquista.................................................................................. 25
7.6. Descrição de casos de uso atendente ................................................................................ 26
7.6.1. Diagrama de atividades atendente .................................................................................. 28
7.7. Descrição de casos de uso supervisor ............................................................................... 29
7.7.1. Diagrama de atividades supervisor ................................................................................. 30
7.8. Diagrama de classes.............................................................................................................. 31
7.9. MER .......................................................................................................................................... 33
8. CONSIDERAÇÕES FINAIS ..................................................................................................... 35
 8

1. INTRODUÇÃO

Para se dar início ao processo de desenvolvimento de um software, deve-se

considerar todo o contexto relacionado a utilização de algum tipo de sistema para
operação e funcionamento de atividades rotineiras, facilitando ao usuário trabalhos
que por sua vez possam ser repetidamente inapropriados para os dias atuais onde a
competitividade do mercado é extremamente alta e vence quem mais se adapta aos
custos de operação.
Um sistema operacional é um programa que atua como intermediário entre o
usuário e o hardware de um computador. O propósito de um sistema
operacional é propiciar um ambiente no qual o usuário possa executar outros
programas de forma conveniente, por esconder detalhes internos de
funcionamento e eficiência, por procurar gerenciar de forma justa os recursos
do sistema (Silberschatz, Galvin e Gagne, 2000, p.22]
Tendo em vista o projeto de desenvolvimento apresentado e as características
de um sistema operacional para o mercado onde terá sua utilização, foi possível e
necessário obter uma relação entre os tipos de produtos juntamente de suas ações e
atividades desenvolvidas pelos usuários, que trouxe a importância da aplicação em
relação a algumas vantagens como: agilidade no processo de venda, apresentação
mais detalhada ao cliente, controle de produtos, controle financeiro e melhoria com o
aproveitamento e desenvolvimento dos funcionários que o utilizarão.
Seguindo com o planejamento, o conteúdo faz a abordagem de alguns dos
principais processos para que se tenha um desenvolvimento de software
concretizado, que segundo Ricardo R. Gudwin (2015) são os processos de
comunicação, planejamento, modelagem, construção e emprego de modo a ser
realizado por um ou uma equipe de trabalhadores. No mesmo contexto do projeto
Roger S. Pressman (2011) diz que, essa cinco pontos são aplicados iterativamente
quantas vezes forem necessárias afim de se ter o sistema parte por parte, até que o
mesmo seja concluído.
Outro ponto que se deve ter em mente ao iniciar um projeto é o modo como
serão tratados todos os assuntos do projeto, onde é feito o planejamento e introdução
da metodologia de desenvolvimento, que disponibiliza uma série de atividades
próprias para que o sistema seja concluído em tempo e funcionalidades de acordo
com as especificações de requisitos.
 9

Como o processo de utilização do software planejado faz a abordagem de

atividades que se tornam repetitivas e que necessitam de códigos específicos para
algumas operações, como venda e cadastros. Foi necessário a implementação de um
banco de dados que facilita essas atividades ao usuário, disponibilizando meios para
buscas e geração de códigos automáticos diversificados, onde não ocorrem
repetições.
Ao se tratar de um projeto onde pode ou deve ser utilizada uma equipe de
desenvolvedores para a realização dos trabalhos dependendo do grau e tamanho do
software planejado, foi abordado o assunto sobre o ambiente em que um funcionário
possa se sentir bem, potencializando seu grau de produção, que segundo Weiss
(1991), para que possa atingir padrões elevados das pessoas envolvidas, deve-se
reconhecer o ambiente e as responsabilidades, recompensando os envolvidos de
acordo com seu grau de esforço.
 10

2. SOFTWARE PARA VENDA DE PRODUTOS

Atualmente os sistemas vem desempenhando um papel muito importante

relacionado ao funcionamento de vários tipos de organizações, sendo esse utilizado
de formas variáveis e adequadamente ao setor que possui a necessidade de
aplicação. Como os processos de venda tanto fisicamente quanto online de quaisquer
tipos de produtos e serviços não fogem desse parâmetro, não poderíamos deixar de
pensar na tecnologia para a evolução e atualização desse setor.
Para Rezende e Abreu (2000), os sistemas são vistos como ferramentas para
as atividades funcionais das organizações, juntamente de suas abrangências, sendo
assim meios de facilitação dos processos de funcionamento, esses que asseguram a
qualidade, produtividade e novas tecnologias. Essas ferramentas fazem a construção
de modelos informativos que auxiliam as tomadas de decisões, tornando assim sua
rotina de trabalho mais ágil e produtiva.
Para que seja relacionado esse assunto, pode-se ter como exemplo a
utilização de sistema para o mercado de venda de produtos gamer e geek, que
segundo matéria apresentada por Afonso Ferreira da redação Uol notícias (2014),
onde o mesmo apresenta o crescente nível de investimento que vem sendo realizado
devido aos entusiastas desse setor estarem cada vez mais dispostos a obter os itens
colecionáveis desejados, além disso apresenta também um aumento de 15% nas
vendas de uma referida loja de quadrinhos, setor esse que vem sendo cada vez mais
impulsionado com o sucesso dos filmes de super heróis da atualidade.
Desse modo entende-se que quanto mais organizada a operação no ponto de
vista de venda e controle dos itens, com o crescente mercado desse tipo, proporciona
um nível maior no aproveitamento do tempo em relação a gestão e dos seus recursos
financeiros com o controle de estoque, trabalho esse que um software de gestão e
controle pode suprir todas as suas necessidades.
 11

3. MOTIVAÇÃO PARA IMPLEMENTAÇÃO

O processo de venda de produtos é essencial para o desenvolvimento,

funcionamento e expansão econômica de empresas, senda essa independentemente
de seu ramo de atuação ou público-alvo. Sendo assim, nada mais importante que um
bom estudo para atualização de processos, esse que muitas vezes não é realizado
de maneira satisfatória, tornando os resultados igualitário ao seu processo.
Pensando nisso, o projeto se baseia com a solicitação para o desenvolvimento
de um software de controle, que será utilizado especificamente para a venda de jogos
eletrônicos e produtos geeks, onde a instituição solicitante do sistema procura
conseguir tornar suas atividades mais organizadas, tendo controle sobre o estoque de
produtos, vendas, realização de cadastros do itens, entre outras funções relacionadas
ao funcionamento de sua loja.
Tendo em vista um processo de venda para esses produtos, e entendendo que
um sistema de venda são ferramentas que proporcionam uma ajuda aos vendedores,
disponibilizando métodos mais adequados para se controlar a operação, pode-se
mensurar os benefícios de um sistema de tecnologia para uma organização, que
podem ser destacados:
 Agilidade no processo de venda;
 Apresentação mais detalhada ao cliente;
 Controle de produtos;
 Controle financeiro;
 Melhor aproveitamento dos funcionários;
 Dentre outros benefícios.
 12

4. FUNDAMENTAÇÃO TEÓRICA

Para que se tenha um início de projeto promissor, deve-se estudar todas as

atividades ligadas ao desenvolvimento do software, onde primeiramente é definida e
analisada as especificações e requisitos do cliente, com o objetivo de formar uma base
e orientação para definir o melhor modelo e metodologia de construção do projeto.
Segundo Ricardo R. Gudwin (2015), para desenvolver um determinado projeto
de sistema é importante que sejam seguidos dois processos da engenharia de
software, que são, o processo de desenvolvimento e a linguagem de modelagem.
Ainda segundo o autor, um processo de desenvolvimento se caracteriza na junção de
atividades desenvolvidas por um ou uma equipe de trabalhadores, onde esses
seguem um cronograma logico de passos, determinando as principais necessidades
dos usuários para construção de um programa.
Esse processo de desenvolvimento tem como objetivo abordar algumas
atividades vistas como essenciais para qualquer projeto, que conforme Roger S.
Pressman (2011) apresenta essas atividades de uma forma genérica, e são formadas
pelos processos de:
 Comunicação: é formada pela interação entre as partes interessadas no
projeto, com a intenção de identificar as necessidades e os requisitos do
sistema.
 Planejamento: é formada pela identificação da melhor forma de
condução do projeto em seu desenvolvimento, de seu cronograma e
utilização da metodologia adequada.
 Modelagem: é formada pela apresentação de um esboço funcional e
visual, com o objetivo de visualizar o funcionamento do sistema tendo
em vista a compreensão do problema de forma mais detalhada.
 Construção: faz parte do processo de codificação e geração de erros do
software sendo criado.
 Emprego: é formado pelo processo de entrega do produto ao cliente,
onde o mesmo retorna com suas impressões de utilização e avaliações
da aplicação.
 13

comunicação, planejamento, modelagem, construção e emprego são aplicados

repetidamente quantas forem as iterações do projeto, sendo que cada iteração
produzirá um incremento de software. Este disponibilizará uma parte dos
recursos e funcionalidades do software. A cada incremento, o software torna-
se mais e mais completo. (ROGER S. PRESSMAN, 2011 pg. 41).

4.1. Comunicação

Para o processo de comunicação, deve-se associa-lo ao levantamento de

requisitos do sistema, que é umas das atividades mais importante em relação a
qualquer projeto, tendo o objetivo de buscar o compreendimento do problema com o
foco no contato entre cliente e usuários.
Segundo descrição de GAUSE e WEIBERG (1989), a primeira comunicação
com o cliente é de extrema importância para que se possa identificar os responsáveis
que necessitam de sua utilização e que se tenha o entendimento básica do problema,
com isso gerando um nível de satisfação para essa primeira abordagem.
Deve-se formar para esse tipo de comunicação uma base que pode ser
trabalhada no formato de entrevista, e conforme CARVALHO e CHIOSSI (2001)
descreve que, para que se tenha sucesso nessa atividade, é muito importante que o
responsável por essa entrevista faça uma elaboração antecipada referente aos itens
mais importantes para equipe de desenvolvimento, deixando claro ao entrevistado
qual será os objetivos a serem alcançados por esse processo.

4.2. Planejamento

Falando sobre a etapa de planejamento, pode-se dizer que é o processo em

que são elaborados os planos das atividades a serem realizadas para que o
desenvolvimento do projeto tenha sucesso fazendo o cumprimento de todos os
objetivos no prazo estipulado. Esse processo tem como um dos principais métodos
para a garantia de entrega as divisões de tarefas entre a equipe e a escolha de
metodologia de desenvolvimento a ser seguida.

Todos os modelos de processo de software podem acomodar as atividades

metodológicas genéricas(...), porém, cada um deles dá uma ênfase diferente a
essas atividades e define um fluxo de processos que invoca cada atividade
 14

metodológica (bem como tarefas e ações de engenharia de software) de forma

diversa. (ROGER S. PRESSMAN, 2011 pg. 59).

Conforme afirma SBROCCO e MACEDO (2012), desenvolver um software sem

que se siga uma metodologia, na maioria das vezes não cumprem com os resultados
esperados, especificamente falando sobre projetos complexos. Em contrapartida, os
modelos tradicionais de desenvolvimento, podem não atender as expectativas para
todos os casos, tendo em vista nesse caso, os projetos que não precisam de práticas
formais e precisam ser entregues de forma mais ágil.

Dessa forma, conclui-se que para cada tipo de desenvolvimento, deve-se levar
em conta quais os riscos de funcionamento do sistema e qual o tempo necessário
para sua entrega ou finalização.

4.3. Modelagem

A etapa de modelagem deve ser apresentada de forma clara ao cliente e

usuários do software, para que se tenha um bom entendimento e um acordo entre as
partes envolvidas no processo. Para isso existem métodos e processos que viabilizam
essa atividade, onde uma das principais técnicas de representação para modelagem
é a linguagem de modelagem UML, que para Ricardo R. Gudwin (2015), a linguagem
de modelagem é correspondente a um padrão de artefatos simbólicos que possam
apresentar de forma visual a formação e funcionamento do sistema, utilizados para
modelagem ou planos de construção de sistemas de software.
A modelagem é uma parte central de todas as atividades que levam à
implantação de um bom software. Construímos modelos para comunicar a
estrutura e o comportamento desejados do sistema. Construímos modelos para
visualizar e controlar a arquitetura do sistema. Construímos modelos para
compreender melhor o sistema que estamos elaborando, muitas vezes
expondo oportunidades de simplificação e reaproveitamento. Construímos
modelos para gerenciar os riscos. BOOCH, RUMBAUGH e JACOBSON (2012,
pag. 32).
Essa linguagem de modelagem por sua vez, como a metodologia de
desenvolvimento, possui tipos variados de representações que cabe aos
desenvolvedores utilizarem aquele que mais se encaixa com o projeto. Dentre esses
 15

tipos, pode-se destacar dois principais modelos utilizados no processo de modelagem

pelas organizações, que são os diagramas de caso de uso e os diagramas de classes.
Para Booch, Rumbaugh e Jacobson (2012), os casos de uso fazem a
representação de um conjunto de casos e seus atores, com ênfase em sua união no
processo das atividades, sendo importantes para melhor visualização comportamental
do sistema.
Ainda segundo o Autor Booch, Rumbaugh e Jacobson (2012), em relação aos
diagramas de classes, eles apresentam os relacionamentos existentes entre os
conjuntos de classes, interfaces e suas colaborações, sendo utilizados na maioria das
vezes em modelagens orientadas a objetos disponibilizando uma perspectiva
detalhada dos processos e seus componentes.

4.4. Construção

A construção trata-se da etapa onde é feita a decisão sobre qual linguagem de

programação mais se adequa ao projeto, onde se tem início ao desenvolvimento dos
códigos juntamente com a testagem e validação de todas as funcionalidades após
serem desenvolvidas.

4.5. Emprego

O emprego faz parte de todas as atividades desenvolvidas após o projeto do

software ter sua conclusão, onde é entregue ao cliente para utilização, avaliação e
feedback juntamente com a iniciação dos processos de manutenção e atualização.
 16

4.6. Metodologia de desenvolvimento

Para que um projeto de software consiga ter seu desenvolvimento e aplicação

de forma correta com o cumprimento do tempo acordado, é necessário que se tenha
uma organização voltada para a realização das atividades, sendo assim pode-se fazer
a utilização principal dos modelos de desenvolvimento, que são muito importantes
para qualquer projeto de software. Existem vários tipos de metodologias para a
realização desses projetos, onde temos como base para projetos que devem ter sua
entrega em um tempo consideravelmente rápido, a utilização das metodologias de
desenvolvimentos ágeis, que visam principalmente o tempo e os requisitos principais
do projeto de software.

O manifesto ágil foi criado considerando a velocidade demandada para novos

sistemas de software, com o objetivo de abandonar métodos antigos que se
mostravam ultrapassados devido ao uso de hardwares mais avançados,
linguagens de programação, ambientes de desenvolvimento e necessidades
organizacionais. SBROCCO e MACEDO (2012, pag. 88).
Segundo SBROCCO, José Henrique Teixeira de Carvalho; MACEDO, Paulo
Cesar (2012), os métodos ágeis disponibilizam atividades necessário para que se
empregue no decorrer do desenvolvimento de um software, onde percebe-se que
apesar de apresentarem informalidade, as metodologias ágeis não deixam de levar
em consideração os processos de documentação, mas sim fazendo isso de forma
objetiva e considerando as partes essenciais do projeto.
 17

5. BANCO DE DADOS

Segundo KORTH, H.F. e SILBERSCHATZ, A. (1994), banco de dados é

definido com um conjunto de dados que se relacionam uns aos outros, onde esses se
armazenam independentemente das aplicações que os utilizam, tornando disponível
para acesso as funções do sistema de uma organização. O banco de dados tem o
propósito de armazenamento de dados utilizados por aplicações simultâneas ou que
devem ter sua busca múltiplas vezes, facilitando e eliminando as informações
consecutivas de dados, sendo o acesso a esses dados permitido por meios de
linguagens que fazem a manipulação e controle dos mesmos. Como forma de
expressão simplificada, um banco de dados faz o papel de manter e buscar
informações contidas em um determinado setor da aplicação quando há a solicitação
do usuário.
Falando de uma forma mais especifica para o processo de banco de dados,
tempos alguns comandos que são utilizados para o processo de criação do mesmo,
esses comandos são descritos a seguir.
O comando CREATE TABLE cria uma tabela, inicialmente vazia, no banco de
dados corrente. O usuário que executa o comando se torna o dono da tabela.
Se for fornecido o nome do esquema (por exemplo, CREATE TABLE
CADASTRO_CLIENTE) então a tabela será criada no esquema especificado, senão
será criada no esquema corrente. As tabelas temporárias são criadas em um esquema
especial e, portanto, não pode ser fornecido o nome do esquema ao se criar tabelas
temporárias. O nome da tabela deve ser distinto do nome de qualquer outra tabela,
sequência, índice ou visão no mesmo esquema.
O comando CREATE TABLE também cria, automaticamente, o tipo de dado
que representa o tipo composto correspondendo a uma linha da tabela. Portanto, as
tabelas não podem ter o mesmo nome de um tipo de dado existente no mesmo
esquema.
As cláusulas opcionais de restrição especificam as restrições (testes) que as
linhas novas ou modificadas devem satisfazer para a operação de inserção ou de
modificação ser bem-sucedida. Uma restrição é um objeto SQL que ajuda a definir o
conjunto de valores válidos para a tabela de várias maneiras.
 18

O comando INSERT INTO é utilizado para inserir itens dentro de uma tabela
direcionada ao banco de dados especificado. Tal comando pode ser executado com
atribuições de um SELECT.

O comando SELECT é utilizado para extrair os dados das tabelas de um banco

de dados. Ele pode extrair dados de uma ou mais tabelas ao mesmo tempo,
executando desde simples consultas até comandos mais complexos, fazendo buscas,
junções, filtros comparativos, ordenações e diversos outros itens. Abaixo,
mostraremos algumas das principais cláusulas para o uso do comando SELECT.
O comando utilizado para apagar dados é o DELETE.
• Nome_tabela: nome da tabela que será modificada
• Where: cláusula que impõe uma condição sobre a execução do comando

5.1. Exemplos de utilização

5.1.1. Exemplo de uso CREATE TABLE CADASTRO_CLIENTE:

“ CREATE TABLE CADASTRO_CLIENTE (

CODIGO INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
RG INTEGER UNSIGNED NULL,
CPF INTEGER UNSIGNED NULL,
NOME VARCHAR NULL,
DATA_CADASTRO INTEGER UNSIGNED NULL,
ENDEREÇO VARCHAR NULL,
TELEFONE INTEGER UNSIGNED NULL,
EMAIL_CLIENTE VARCHAR NULL,
PRIMARY KEY(CODIGO)
);”

5.1.2. Exemplo de uso INSERT INTO

“INSERT INTO CADASTRO_CLIENTE(CODIGO,

RG,
 19

CPF,
NOME,
DATA_CADASTRO,
ENDEREÇO,
TELEFONE,
EMAIL_CLIENTE) VALUES ('01', '44949499','3434333454','TESTANDO DA
SILVA','06061996','AV MORO ALI','169988877')”

5.1.3. Exemplo de uso SELECT

SELECT SIMPLES
“SELECT NOME FROM CADASTRO_CLIENTE;”

5.1.4. Exemplo de uso USO DELETE:

“DELETE FROM CADASTRO_CLIENTE

WHERE NOME = ANA;”
 20

6. AMBIENTE DE TRABALHO

Ao se tratar de um projeto de desenvolvimento onde existe uma equipe

responsável por todo o processo, é essencial que se tenha a definição de um ponto
muito importante além das atividades que serão cobradas pela empresa responsável
por criar e distribuir os softwares de seus funcionários, que é o tipo de organização.
Cada empresa deve adotar seu tipo de organização com relação a suas atividades,
dessa forma tornam o processo de trabalho dividido entre cargos de especialidades e
superiores bem definidos.
Para que isso se torne um fator de grande importância para o ambiente de
trabalho é necessário essencialmente que, segundo Davis e Newstron (1991), as
organizações saibam as capacidades de seus funcionários e quais os objetivos que
se espera de seus trabalhos, além de deixar bem claro os benefícios que isso pode
traze-los onde o resultado da produtividade humana é a combinação entre os fatores
organizacionais de motivação e as habilidades individuais de cada funcionário.
Conseguir o máximo e o melhor dos outros quer dizer que você deve
estabelecer padrões elevados, mas razoáveis, deve reconhecer suas próprias
responsabilidades, bem como a dos empregados, e deve deixar que o
empregado pague o preço pelo mal resultado, ou receba a recompensa pelo
sucesso (WEISS, 1991, p. 36).
Dessa forma para que se tenha uma equipe sempre disposta a entregar bons
resultados, não se pode deixar que alguma circunstância por parte da organização
faça com que vire um obstáculo aos funcionários.
 21

7. DESENVOLVIMENTO E MÉTODOS

7.1. Analise de requisitos do sistema

A análise dos requisitos do sistema se inicia com a reunião de toda a equipe de

desenvolvimento e se necessário também a presença do cliente solicitante do
software, onde são discutidos e observados os requisitos necessários para que o
sistema consiga ter um bom desempenho, formando assim os requisitos funcionais e
não funcionais.

7.2. Requisitos funcionais

Representação das funcionalidades em requisitos funcionais do sistema.

Identificador Descrição Casos de uso

RF00 Login CU00
RF01 Cadastro dos produtos CU01
RF02 Editar produtos cadastrados CU01
RF03 Cadastrar clientes CU02
RF04 Editar informações dos clientes CU02
RF05 Consultar informações dos produtos CU02
RF06 Efetuar venda dos produtos CU02
RF07 Cancelamento de venda e de produtos CU03
Tabela 1 - requisitos funcionais (autoria própria)

7.3. Requisitos não funcionais

Representação dos requisitos não funcionais do sistema.

Identificador Descrição
RNF01 Cada usuário terá sua função
RNF02 O cadastro de produtos deve ter separação em categorias
RNF03 O cadastro dos produtos deverá informar dados específicos para o sistema
RNF04 O cadastro do cliente deverá informar dados específicos para o sistema
RNF05 Os itens que compõem uma venda só poderão ser eliminados pelo supervisor
RNF06 A venda poderá ser cancelada apenas pelo supervisor
Tabela 2 - requisitos não funcionais (autoria própria)
 22

7.4. Regras de negócio

As informações de como o sistema será funcional em termos de utilização para

os usuários do sistema é de extrema importância para o desenvolvimento do software
e por isso é ideal que se conheça todo o fluxo de trabalho do local onde será aplicada
a tecnologia.

 Processo de recebimento de mercadorias

O processo de recebimento de mercadorias será feito pelo estoquista, que ao
receber as entregas fará a separação por itens dependendo de seus locais de
armazenagem, com isso facilitará sua inclusão no sistema. Após essa separação ser
feita, o estoquista antes da armazenagem faz o cadastro do item inserindo as
informações necessárias no sistema que são: nome do produto, categoria, fabricante,
quantidade e valor do produto, onde será gerado um código de barras para que o item
seja armazenado com suas devidas identificações.

 Processo de cadastro do cliente

O processo de cadastro é iniciado pelo atendente com a presença do cliente,
para que o mesmo consiga efetuar uma compra, o atendente fará o cadastro
solicitando algumas informações pré-definidas do sistema que são: RG, CPF, nome,
data do cadastro, endereço, telefone e e-mail, onde após salvar essas informações
será gerado o código do cliente.

 Consulta de preços
A consulta de preços pode ser solicitada por um cliente antes do mesmo efetuar
uma compra ou escolher o produto, bastando apenas informar e solicitar ao atendente
qual item deseja obter esse tipo de informação.

 Processo de venda
O processo de venda é feito após o cliente indicar o item desejado, onde o
atendente fará o preenchimento da venda com o código do cliente e o código do item,
gerando assim um código de venda único com as seguintes informações: data da
 23

venda, o valor da venda, opções para pagamento (dinheiro/cartão), o status de

pagamento e o status da venda.

 Exclusão de item da venda

Caso o cliente faça a escolha de um produto e em meio ao processo de venda
efetuado pelo atendente, seja solicitado a alteração ou exclusão de um dos itens por
desistência, o atendente deverá solicitar a presença do supervisor que fará a inserção
de seu usuário e senha para o item tenha sua exclusão efetuada.

 Cancelamento de venda
Em caso de o cliente efetuar uma compra e após isso resolver desistir da
mesma, o atendente deverá solicitar a presença do supervisor que irá inserir seu
usuário e senha para que o sistema permita o cancelamento da venda. Quando esse
caso ocorrer o sistema deverá enviar automaticamente uma mensagem ao financeiro
da empresa informando o código da venda que foi cancelada e suas respectivas
informações.
 24

7.5. Descrição de casos de uso estoquista

O estoquista será responsável por cadastrar todos os novos produtos recebidos

na empresa, sendo esse feito pela inserção das informações: nome, categoria,
fabricante, quantidade, valor do produto e garantia para jogos e acessórios, onde após
essas informações inseridas e salvas será gerado um código de barras único para
cada item.

Figura 1 – casos de uso - estoquista (autoria própria)

Identificação: Efetuar cadastro,

Escopo: Sistema próprio de controle,

Descrição do propósito: Permitir o usuário estoquista a cadastrar os produtos no sistema,

Ator primário: Estoquista,

Interessados: Estoquista e organização,

Pré‑condições: Receber mercadorias de entrega,

Pós‑condições: Item cadastrado com suas devidas informações,

Fluxo normal:

 1 – O estoquista recebe a mercadoria,

 2 – O estoquista inicia o processo em cadastro de produtos,
 3 – O estoquista informa: Nome, categoria, fabricante, quantidade, valor do produto,
 4 – Após o estoquista salvar o cadastro é gerado um código de barras,

Fluxo alternativo:

 1 – Para o processo 3 o estoquista deve inserir todas as informações, caso isso não ocorra não será
possível concluir o cadastro,
 2 – Para o processo 3 onde a categoria informada for de jogos ou acessórios, será necessário inserir a
data proposta como garantia do produto.

Requisitos funcionais Relacionados: RF01 – cadastro de produtos

Requisitos não funcionais relacionados: RNF02 – separação dos produtos por categorias
Tabela 3 - Descrição de casos de uso - estoquista - RF01 - (autoria própria)
 25

Identificação: Editar Cadastro

Escopo: Sistema próprio de controle,

Descrição do propósito: Permitir o usuário estoquista a editar os produtos cadastrados no sistema,

Ator primário: Estoquista,

Interessados: Estoquista e organização,

Pré‑condições: Ter ao menos um item cadastrado,

Pós‑condições: Item alterado conforme planejado,

Fluxo normal:

 1 – O estoquista informa o código de barras do produto a ser alterado,

 2 – O estoquista faz a alteração necessária,
 3 – O estoquista salva a alteração,
 4 – O código de barras é atualizado,

Fluxo alternativo:

 1 – O estoquista deverá informar o código de barras original do cadastro,

 2 – O estoquista deverá salvar a alteração efetuada, caso contrário voltará aos dados anteriores,

Requisitos funcionais Relacionados: RF02 – editar produtos cadastrados

Tabela 4 - Descrição de casos de uso - estoquista - RF02 - (autoria própria)

7.5.1. Diagrama de atividades estoquista

O diagrama de atividades será utilizado para representar todo o fluxo de

atividades desenvolvidas pelo estoquista,

Figura 2 - Diagrama de atividades - estoquista (autoria própria)

 26

7.6. Descrição de casos de uso atendente

O atendente será responsável pelo cadastro de clientes inserindo as

informações: RG, CPF, nome, data do cadastro, endereço, telefone, e-mail do cliente,
onde após essas informações inseridas e salvas será gerado um código de cadastro.
Também será responsável por efetuar o processo de venda dos produtos.

Figura 3 - Casos de uso - atendente (autoria própria)

Identificação: Cadastrar clientes

Escopo: Sistema próprio de controle,

Descrição do propósito: Permitir ao usuário efetuar o cadastro de novos clientes,

Ator primário: Atendente,

Interessados: Atendente e cliente,

Pré‑condições: Cliente não estar cadastrado no sistema,

Pós‑condições: Obter o código de cliente após o preenchimento de todos os dados necessários,

Fluxo normal:

 1 – O atendente recebe um novo cliente,

 2 – O atendente inicia o cadastro inserindo os dados: RG, CPF, nome, data do cadastro, endereço,
telefone, e-mail,
 3 – Após concluir o preenchimento dessas informações e salvar, será gerado o código do cliente,

Fluxo alternativo:

 1 – Caso o funcionário insira caracteres incorretos como letras em campos numéricos, o sistema
apontará a obrigatoriedade do uso correto,
 2 – Caso o funcionário deixe algum campo sem preenchimento, o sistema não irá permitir que prossiga,
 3 – Caso o cliente deseje alterar alguma informação, basta o atendente inserir seu código e efetuar a
atualização necessária,

Requisitos funcionais Relacionados: RF03 – cadastro de clientes e RF04 - Editar informações dos clientes

Requisitos não funcionais relacionados: RNF04 – informação de dados específicos para o cadastro
Tabela 5 - Descrição de casos de uso - atendente - RF03 - (autoria própria)
 27

Identificação: Consulta de preços

Escopo: Sistema próprio de controle,

Descrição do propósito: Permitir que o atendente faça uma breve consulta de preços para o cliente,

Ator primário: Atendente,

Interessados: Atendente e cliente,

Pré‑condições: Possuir ao menos um item cadastrado,

Pós‑condições: Apresentar ao atendente o valor do produto solicitado pelo cliente,

Fluxo normal:

 1 – O atendente é solicitado pelo cliente sobre o preço de algum item,

 2 – O atendente faz a busca no sistema sobre o item questionado,
 3 – O sistema apresenta ao atendente as informações do item,

Fluxo alternativo:

 1 – Caso o cliente informe nome incorreto ou produto não cadastrado, o sistema não fará a busca
retornando com a mensagem de produto não cadastrado,

Requisitos funcionais Relacionados: RF05 – consultar informação do produto

Tabela 7 - Descrição de casos de uso - atendente - RF05 - (autoria própria)

Identificação: Venda de produtos

Escopo: Sistema próprio de controle,

Descrição do propósito: Possibilitar que o atendente efetue a venda de um produto cadastrado no sistema,

Ator primário: Atendente,

Interessados: Atendente e cliente,

Pré‑condições: Possuir ao menos um cadastro de cliente e de produto,

Pós‑condições: Efetuar a venda do produto solicitado pelo cliente, gerando o código de venda para o financeiro,

Fluxo normal:

 1 – O cliente deseja comprar algum dos produtos e é atendido pelo funcionário da loja,
 2 – O atendente então faz a busca de cadastro do cliente e inicia o processo,
 3 – O atendente insere código do cliente e código do produto a ser vendido,
 4 – O atendente finaliza o processo de venda com a concordância do cliente,
 5 – É gerado o código de venda que possui: data, valores, opções de pagamento e status,

Fluxo alternativo:

 1 – Ao inserir os dados do cliente, o atendente percebe que o mesmo não possui cadastro, sendo assim
devendo faze-lo para prosseguir com a venda,
 2 – Ao prosseguir o processo da venda e o cliente desistir de algum item inserido, ou até mesmo da
compra, será necessário que o supervisor insira seu login e senha para o desbloqueio,

Requisitos funcionais Relacionados: RF06 – Efetuar venda de produtos

Tabela 6 - Descrição de casos de uso - atendente - RF06 - (autoria própria)
 28

7.6.1. Diagrama de atividades atendente

O diagrama de atividades será utilizado para representar todo o fluxo de

atividades desenvolvidas pelo atendente,

Figura 4 - Diagrama de atividades - atendente (autoria própria)

 29

7.7. Descrição de casos de uso supervisor

O papel do supervisor para a organização é o de controlar e dar suporte a todas

as operações efetuadas pelo estoquista e principalmente pelo atendente, onde terá o
papel e usuário administrador, podendo reverter erros dos usuários além de ter acesso
a todas as opções do sistema. Responsabilidade principal será de ter o acesso a
exclusão de itens pré-venda e estornar as vendas com a solicitação do cliente.

Figura 5 - Casos de uso - supervisor (autoria própria)

Identificação: Cancelamento de venda

Escopo: Sistema próprio de controle,

Descrição do propósito: Permitir que o supervisor faça o cancelamento de uma venda concluída,

Ator primário: Supervisor,

Interessados: Supervisor, atendente e financeiro,

Pré‑condições: Ter a solicitação do cliente sobre o cancelamento e possuir ao menos uma venda efetuada,

Pós‑condições: Gerar o código de cancelamento de venda ao financeiro baixando os valores vendidos,

Fluxo normal:

 1 – O atendente ao efetuar uma venda percebe alguma inconsistência ou a solicitação de estorno pelo
cliente,
 2 – O atendente faz o processo de estorno e entra em contato com o supervisor para que insira as
credencias de autorização,
 3 – O supervisor faz a análise do caso e insere login e senha na caixa de diálogo,
 4 – O código da venda é enviado ao financeiro para controle,

Requisitos funcionais Relacionados: RF07 – cancelamento de produtos e vendas,

Requisitos não funcionais relacionados: RNF06 – os cancelamentos só podem ser autorizados pelo supervisor.

Tabela 8 - Descrição de casos de uso – supervisor – RF07 - (autoria própria)

 30

Identificação: Cancelamento de produtos

Escopo: Sistema próprio de controle,

Descrição do propósito: Permitir que o supervisor faça a eliminação dos itens de uma venda,

Ator primário: Supervisor,

Interessados: Supervisor e atendente,

Pré‑condições: O atendente ter iniciado uma venda e já ter inserido um produto na mesma,

Pós‑condições: Retirar o item solicitado pelo atendente do processo de venda,

Fluxo normal:

 1 – O atendente inicia uma venda,

 2 – O cliente solicita a exclusão de um dos itens,
 3 – O atendente marca o item para eliminação e aciona o supervisor,
 4 – O supervisor insere suas credenciais na caixa de diálogo apresentada pelo sistema,
 5 – O item é eliminado da venda,

Fluxo alternativo:

 1 – O atendente deve fazer a marcação do item para eliminação, caso contrário o supervisor não será
acionado para tal processo,

Requisitos funcionais Relacionados: RF07 – cancelamento de produtos e vendas,

Requisitos não funcionais relacionados: RNF06 – os cancelamentos só podem ser autorizados pelo supervisor.

Tabela 9 - Descrição de casos de uso – supervisor – RF07 - (autoria própria)

7.7.1. Diagrama de atividades supervisor

O diagrama de atividades será utilizado para representar todo o fluxo de

atividades desenvolvidas pelo supervisor,

Figura 6 - Diagrama de atividades - supervisor (autoria própria)

 31

7.8. Diagrama de classes

Uma classe num Diagrama de Classes (ou até mesmo no código fonte) é
apenas um conceito. Um conceito em forma de desenho (se num diagrama) ou texto
(se em código fonte).

Quando a Classe é materializada através de um software, (quando o software

está “rodando”) torna-se um objeto (isso se dá quando é alocado um ponteiro de
memória para esta classe).O diagrama de classes ilustra graficamente como será a
estrutura do software (em nível micro ou macro – veremos adiante sobre as
possibilidades de uso do diagrama), e como cada um dos componentes da sua
estrutura estarão interligados.

Lembramos que na UML também temos o Digrama de Objetos. Este diagrama

serve para ilustrar as classes do software instanciadas, ou seja, materializadas em
objetos na memória do sistema operacional.

Objetivos de utilização

 O diagrama de classes, como citado, tem como objetivo principal a

especificação dos componentes do software e como estes se interligam, do
ponto de vista estrutural, ou seja, da sua estrutura.
 Possui semelhança com diversos diagramas existentes por aí, aplicáveis às
mais diversas áreas, pois (como vários diagramas) é algo como “caixas ligadas
com setas”.
 Lembrando que sem entender para que servem as caixas, os compartimentos
de cada caixa, e as ligações entre as caixas, não é possível entender um
modelo de classes.
 32

Figura 7 - Diagrama de classes (autoria própria)

 33

7.9. MER

Desenvolvido em 1976, pelo cientista americano Peter Chen, o Modelo de

Entidade de Relacional, conhecido pelos engenheiros de software apenas como MER,
nada mais é do que um conceito que descreve todas as entidades existentes no
domínio de negócio, assim como o modo como essas entidades se relacionam e as
características de cada uma dessas entidades.

As entidades também recebem o nome de objetos, assim como atributos são

usados como sinônimos de características para o relacionamento de todas as partes
de um Modelo de Entidade de Relacionamento.

O MER (Modelo de Entidade de Relacionamento) consiste em um banco de

dados do sistema.

No entanto, vale lembrar que nem sempre é necessário realizar todos os

modelos do sistema, já que alguns são tão complexos que podem levar muito tempo
para serem produzidos e ficarem grandes demais. O mais comum é que os modelos
sejam feitos por módulos ou entidades.
Portanto, o Modelo de Entidade de Relacionamento pode ser classificado como
o modelo conceitual de todo o projeto.
 34

Figura 8 - MER – Esboçando toda linha de casos do projeto (autoria própria)

 35

8. CONSIDERAÇÕES FINAIS

Todo projeto adotou as técnicas utilizadas nas matérias Análise de Sistemas

Orientada a Objetos, Banco de Dados e Gestão Estratégica de RH, tornando assim:
 Melhor compreensão nos conceitos técnicos;
 Facilidade de implantação;
 Estrutura organizacional;
 Visão de gestão de projetos e profissionalismo;
 Etc;
Nesse sentido, a utilização de recursos digitais permite aos colaboradores e
clientes realizarem seu trabalho de forma mais rápida e eficiente. Além disso, diminui
o tempo de espera dos clientes tornando assim a maior satisfação e a melhor
organização de todo sistema e empresa.
É de suma importância a implantação de software em uma empresa pois torna
o ambiente organizado, automatizado e seguro. Lembrando que a todo software faz
com que a organização e desenvolvimento pessoal seja satisfatório. Entretanto, deve-
se tomar medidas de desenvolvimento para que todo projeto e solicitação do cliente
seja de maneira satisfatória, tornando assim, estratégias de tratativas de soluções de
maneira rápida, portanto, todo desenvolvimento, organização do projeto citado
exemplifica toda a rotina de empresa destinada a venda de jogos eletrônicos,
acessórios e produtos geek;
 36

REFERÊNCIAS

RICARDO R. Gudwin, Engenharia de software: uma visão prática 2º edição, 2015.

SILBERSCHATZ, A. & GAGNE, G. & GALVIN, P. B. Fundamentos de Sistemas
Operacionais. Tradução de Adriana Cashin Rieche. Rio de Janeiro, 2004.
REZENDE, Denis Alcides; ABREU, Aline França de. Tecnologia da informação
aplicada a sistemas de informação empresariais: o papel estratégico da informação e
dos sistemas de informação nas empresas. São Paulo: Atlas, 2000.
ROGER S. Pressman, Engenharia de software, Uma Abordagem Profissional, 7°
edição, 2011.

GAUSE, D. C.; G. M. Weiberg, Explorando requisitos: Qualidade antes do Design,

Dorset House, 1989.

CARVALHO, A. M. B. R.; CHIOSSI, T. C. dos S. Introdução a Engenharia de software.

Campinas: Unicamp, 2001.

BOOCH G.; RUMBAUGH J.; JACOBSON, I. UML: Guia do usuário, Rio de Janeiro:
Campus, 2º edição, 2012.

SBROCCO, José Henrique Teixeira de Carvalho; MACEDO, Paulo Cesar

de: Metodologias Ágeis. Engenharia de Software Sob Medida. São Paulo: Érica, 2012.

KORTH, H.F. e SILBERSCHATZ, A.; Sistemas de Bancos de Dados, Makron Books,

2a. edição revisada, 1994.

DAVIS, K. e NEWSTROM, J. W. Comportamento humano no trabalho – Uma

abordagem psicológica. São Paulo: Pioneira, 1992.
WEISS, D. Motivação e resultado – Como obter o melhor de sua equipe. São Paulo:
Nobel, 1991.
Afonso Ferreira ao site Uol notícias, empreendedorismo, São Paulo, 2014, Acesso
em: 29/04/2020, disponível em:
https://economia.uol.com.br/empreendedorismo/noticias/redacao/2014/08/11/loja-
para-nerds-vende-estatua-por-r-12-mil-e-fatura-r-250-mil-por-mes.htm