MODELAGEM DE SISTEMA DE CONTROLE DE PEDIDOS PARA

ATELIÊ

GABRIEL QUILICE LUCON

JOÃO GABRIEL FERREIRA MARTINS
Faculdade de Tecnologia de Mococa
Discentes do curso de Tecnologia em Análise e Desenvolvimento de Sistemas

JACIARA SILVA CAROSIA

Faculdade de Tecnologia de Mococa
Docente do curso de Tecnologia em Análise e Desenvolvimento de Sistemas

RESUMO

Este trabalho tem como objetivo utilizar as práticas de Engenharia de Software

para a modelagem de um sistema de informação para gerenciamento pedidos
de um ateliê. A ideia deste sistema surgiu a partir da necessidade de maior
segurança e rapidez na realização do pedido e na entrega do mesmo pelo ateliê.
A manutenção dos pedidos é feita através de uma simples anotação em um
caderno, sendo muito fácil a perda de informação ou alteração desta informação.
Para informatizar esse processo, incialmente foi necessário o levantamento de
requisitos bem como a documentação dos mesmos através de modelagem
gráfica. Com o uso da modelagem UML, modelagem de banco de dados e da
prototipação, foi possível analisar os requisitos do sistema que poderá ser
implementado futuramente utilizando linguagem de programação orientada a
objetos e gerenciados de banco de dados MySql.

Palavras-chave: Tecnologia da Informação; Análise de Requisitos; UML;

Prototipação; Modelagem.
INTRODUÇÃO

A Tecnologia da Informação, mais popularmente conhecida pela sigla TI,

é um campo que entrega a computação como forma de produzir, transmitir,
armazenar, acrescentar e utilizar múltiplas informações.
Um Sistema de Informação, baseado em TI, permite que os gestores
empresariais tenham acesso aos dados em tempo real, ajudando-os nas
tomadas de decisões para que a empresa tenha vantagem sobre suas
concorrentes.
Em consonância com essa percepção a respeito de TI, percebe-se que
mesmo empresas pequenas podem tirar proveito da informatização para
melhoria de sua gestão.
O objetivo deste trabalho é a aplicação da Tecnologia da Informação no
gerenciamento de um ateliê. Diante disso, foi proposto no presente trabalho
desenvolvimento da modelagem de um sistema para o gerenciamento de
pedidos, com o objetivo de melhorar os processos na empresa, como,
manutenção de cliente e recebimento de pedidos.
O processo de recebimento de pedido é realizado através de uma
anotação em um bloco de notas no balcão do estabelecimento, problemas como
a perda de pedido ocorrem com frequência. Desta forma, a proposta do sistema
de informação a ser desenvolvido futuramente terá como finalidade facilitar e
garantir uma maior segurança ao processo citado acima.

METODOLOGIA

Para a realização deste trabalho, foi feito um levantamento bibliográfico

sobre os temas: Engenharia de Software, Sistemas de informação, levantamento
de requisitos, linguagens de programação e banco de dados. Foram realizadas
consultas em artigos acadêmicos, revistas especializadas e livros para adquirir
o conhecimento necessário para o desenvolvimento deste projeto. Com o
conhecimento adquirido, os conceitos foram aplicados na modelagem de um
sistema para o controle de pedidos de um ateliê.
Os diagramas UML foram essenciais para o desenvolvimento do projeto,
utilizamos a ferramenta LucidChart para a confecção do Diagrama de Caso de
Uso, Diagrama de Atividades e Diagrama de Classe. A criação e modelagem do
Banco de Dados foram feitas utilizando a ferramenta MySQL Workbench. Para
a prototipação das telas a ferramenta utilizada foi NetBeans IDE 8.2. Todas estas
ferramentas são gratuitas.

DISCUSSÃO E RESULTADOS

Sistema de Informação
De acordo com O’Brien (2004), Sistemas de informação é um conjunto
organizado de pessoas, hardware, software, rede de comunicação e dados, que
são coletados e transformados em informações dentro de um ambiente
organizacional.
Portanto, um Sistema de Informação tem por característica todo
mecanismo que controla dados, convertendo-os em informações, recursos ou
mecanismos usando ou não meios tecnológicos para isso.
Para Batista (2004), a definição de sistema é um conjunto estruturado ou
ordenado de partes ou elementos que se mantém em interação, ou seja, em
ação recíproca, na busca da consecução de um ou de vários objetos. Assim, um
sistema se caracteriza, sobretudo, pela influência que cada componente exerce
nos demais e pela união de todos (globalismo ou totalismo), para gerar
resultados que levam ao objetivo esperado.
Segundo Laudon e Laudon (2014), um Sistema de Informação pode ser
definido como um conjunto de componentes inter-relacionados trabalhando
juntos para coletar, recuperar, processar, armazenar e distribuir informações,
com a finalidade de facilitar o planejamento, o controle e a coordenação, a
análise e o processo decisório em organizações.

Engenharia do Software
Para Sommerville (2011, p. 19), a “Engenharia de Software é uma
disciplina de engenharia cujo foco está em todos os aspectos da produção de
software”, desde os estágios iniciais da especificação do sistema até sua
manutenção, quando o sistema já está sendo usado. No entanto, a Engenharia
de Software não se preocupa apenas com os processos técnicos do
desenvolvimento de software. Ela também inclui atividades como gerenciamento
de projeto de software e desenvolvimento de ferramentas, métodos e teorias
para apoiar a produção de software.
De acordo com Pressman (2011), o processo de software é definido como
uma metodologia para as atividades, ações e tarefas necessárias para
desenvolver um software de alta qualidade.
Sommerville (2011) considera o processo de software como um conjunto
de atividades relacionadas que levam à produção de um produto de software.
Afirma ainda que, existem várias formas de sistematizar as atividades que
direcionam a construção de software. Desse modo, é provável criar
diferenciados processos de software.
Pressman (2011, p. 42) avalia um dos modelos mais importantes de
processo, o modelo cascata. O modelo cascata, algumas vezes chamado ciclo
de vida clássico, “sugere uma abordagem sequencial e sistemática para o
desenvolvimento de software”, começando com a especificação dos requisitos
do cliente; avançando pelas fases de planejamento, modelagem, construção e
disponibilização, e culminando no suporte contínuo do software concluído.
A figura a seguir ilustra a estrutura do Modelo Cascata.

Figura 1 - Modelo Cascata

Fonte: Pressman, 2011

Para Bezerra (2015), o modelo de ciclo de vida incremental e iterativo foi

criado como uma solução aos problemas vistos no modelo cascata.
Efetivamente, um modelo de ciclo de vida iterativo e incremental pode ser
definido como uma popularização da abordagem em cascata: o software é
desenvolvido em incrementos, que por sua vez reproduz o formato em cascata.
No processo incremental e iterativo, cada iteração é uma mini cascata,
como mostra a Figura 2.
 Figura 2 - Modelo Incremental e iterativo

Fonte: Bezerra, 2015

No modelo de ciclo de vida incremental e iterativo, um sistema de software

é desenvolvido em vários passos parecidos (portanto, iterativo). Em cada etapa,
o sistema é ampliado com mais funcionalidades (logo, incremental).

Análise de Requisitos
Em conformidade com Sommerville (2011) a análise de requisitos está
inserida ao processo de engenharia de requisitos. Nessa fase, os engenheiros
de software interagem com os clientes e usuários finais para conhecer a
funcionalidade e aplicabilidade que o sistema deve oferecer.
Para Pressman (2011) a análise de requisitos é imprescindível para o
êxito de um software. Se a análise não seguir determinada logística, o resultado
poderá ser negativo. Além disso, a análise de requisitos não depende somente
de quem a faz — o cliente deve informar de maneira clara e objetiva o que quer
do sistema. O desenvolvedor ou pessoa habilitada deve manter contatos
simultâneos com o utilizador para que o resultado vá ao encontro dos anseios
do próprio. Do mesmo modo, o analista deve considerar o acordo feito entre as
partes, no que se refere ao tempo programado, à eficiência do software, à
praticidade e facilidade do uso do sistema.
 De acordo com Engholm Junior (2010), é indispensável que o software
seja organizado e documentado para que possa ser disponibilizado à equipe do
projeto e cliente em potencial

UML
Segundo Bezerra (2015, p. 26), “UML (Unified Modeling Language) é uma
linguagem visual para modelar sistemas orientados a objetos”. Isso quer dizer
que a UML é uma linguagem que define elementos gráficos (visuais) que podem
ser utilizados na modelagem de sistemas. Esses elementos permitem
representar os conceitos do paradigma da orientação a objetos. Por meio dos
elementos gráficos definidos nesta linguagem pode-se construir diagramas que
representam diversas perspectivas de um sistema.
O autor citado acima defende o advento da UML como um dos principais
meios para a documentação de sistemas que aconteceu ainda no final dos anos
90, graças ao trabalho conjunto de três especialistas da área de desenvolvimento
de software: James, Rumbaugh, Grady Booch e Ivar Jacobson.
UML tem por finalidade a criação de diagramas, cujo objetivo é modelar o
sistema de acordo com a perspectiva desejada. A escolha dos diagramas
depende da utilidade de cada projeto ou do processamento determinado pela
empresa. Há inúmeros diagramas, entretanto, para o desenvolvimento desse
trabalho foram utilizados três deles.

Diagrama de Caso de Uso

Guedes(2009) defende que o diagrama de casos de uso é o diagrama
mais geral e informal da UML, utilizado normalmente nas fases de levantamento
e análise de requisitos do sistema, embora venha a ser consultado durante todo
o processo de modelagem e possa servir de base para outros diagramas.
Apresenta uma linguagem simples e de fácil compreensão para que os usuários
possam ter uma ideia geral de como o sistema irá se comportar. Procura
identificar os atores (usuários, outros sistemas ou até mesmo algum hardware
especial) que utilizarão de alguma forma o software, bem como os serviços, ou
seja, as funcionalidades que o sistema disponibilizará aos atores, conhecidas
neste diagrama como casos de uso.
 Em conformidade com o autor citado, o diagrama de caso de uso resume
os detalhes dos usuários de seu sistema e a comunicação deles com o sistema,
conforme exemplo na figura a seguir.

Figura 3 - Exemplo de diagrama de caso de uso

Fonte: Guedes (2009)

Diagrama de Classes
Booch, Rumbaugh e Jacobson (2005) sustentam que um diagrama de
classe exibe um conjunto de classes, interfaces e colaborações, bem como seus
relacionamentos. Esses diagramas são encontrados com maior frequência em
sistemas de modelagem orientados a objeto e abrangem uma visão estática da
estrutura do sistema. Os diagramas de classes que incluem classes ativas
direcionam a perspectiva do processo estático do sistema. Os diagramas de
componentes são variantes dos diagramas de classes.
Nesse sentido, os autores citados reiteram que os diagramas de classes,
além de serem importantes para a visualização, a especificação e a
documentação de modelos estruturais, também são vitais para a construção de
sistemas executáveis por intermédio da engenharia de produção reversa.
Pender (2004) ressalta a importância desse diagrama, pois, a partir dele
pode-se realizar a engenharia reversa, ou seja, transformar um modelo em linha
de código, e transformar as linhas de código em um modelo.
A Figura 4 mostra um exemplo do diagrama de classes.

Figura 4 - Exemplo de diagrama de classes

Fonte: Magnani, 2009

Diagrama de Atividades
De acordo com Booch, Rumbaugh e Jacobson (2005) um diagrama de
atividades mostra a estrutura de um processo, como o fluxo de controle e os
dados de cada etapa de seu funcionamento. Inclui a visão dinâmica do sistema
e é significativo principalmente para a modelagem da função de um sistema. Ele
ainda destaca o fluxo de controle entre objetos.
Para Sommerville (2011), os diagramas de atividades são destinados a
mostrar as atividades que compõem um processo de sistema e o fluxo de
controle de uma atividade para a outra. O início de um processo é indicado por
um círculo preenchido; o fim, por um círculo preenchido dentro de outro círculo.
Os retângulos com cantos arredondados representam atividades, ou seja, os sub
processos específicos que devem ser realizados, conforme figura a seguir.
 Figura 5 - Exemplo de diagrama de atividades

Fonte: Sommerville, 2011

Modelagem de Dados
O trabalho de Pressman (2011) certifica a modelagem de dados como o
retrato do espaço de informações e dos objetos de dados que o software irá usar
e os relacionamentos entre eles. A modelagem baseada em classes revela
objetos, atributos e relacionamentos. Quando os modelos preliminares forem
criados, eles serão aprimorados e examinados para qualificação de sua clareza,
completude e consistência.
Ainda de acordo com o autor citado, a modelagem de dados é
fundamental na produção de um sistema de banco de dados, para validar
requisitos, proporcionando a visibilidade de erros, omissões e inconsistências,
ainda no início do projeto.
Nesse sentido, o autor nos apresenta alguns tipos de modelagem:
conceitual, lógico e físico, dos quais abordaremos apenas o conceitual, que é a
primeira fase da modelagem, onde o mundo real é representado por meio de
uma visão simplificada dos dados e seus relacionamentos. Dessa forma,
podemos determinar quais informações serão armazenadas no Banco de Dados.

Prototipação
 Sommerville (2011) afirma que um protótipo é uma versão inicial de um
sistema de software, usado para demonstrar conceitos, experimentar opções de
projeto e descobrir mais sobre o problema e suas possíveis soluções. O
desenvolvimento rápido e iterativo do protótipo é essencial para que os custos
sejam controlados e os stakeholders do sistema possam experimentá-lo no início
do processo de software.
Os protótipos facilitam o entendimento prévio que os envolvidos devem
ter com os softwares durante seu processo de desenvolvimento, permitindo, com
isso, constatar falhas ou omissões de informações e, desse modo, ajustar
prováveis requisitos necessários ao software.
Engholm Junior (2010) reconhece que a prototipação expressa como será
o sistema por meio de um esqueleto funcional, antecipando uma perspectiva que
possibilita fazer alterações necessárias para atingir os requisitos exigidos.

Modelagem de Sistema de Controle de Pedidos do Ateliê

Analisando o método de controle de pedidos do ateliê em estudo, foi feito
o levantamento de requisitos. Para tanto, fez-se necessário desenhar os
diagramas mediante a coleta de informações. Protótipos de interface foram
também criados para melhor esclarecimento dos requisitos levantados junto aos
stakeholders. A proposta desse sistema objetiva viabilizar a empresa a
implementação de um processo informatizado, mais seguro, confiável e rápido.
Evitar transtornos na entrega do produto é de extrema importância para o
ateliê. Se esse processo for bem feito, ele irá dar credibilidade a empresa e se
for um processo ruim irá prejudicar a imagem desta. Os pedidos são entregues
aos clientes mediante o nome do mesmo.
Durante todo o processo de análise de funcionalidade do ateliê, na
entrega dos pedidos, foi descoberto que a empresa armazena muitas
informações fisicamente, facilitando a duplicidade de dados, gerando um volume
muito grande de papel, impossibilitando fazer buscas de informações rápidas e
podendo gerar confusão na entrega dos produtos.
Para a proposta de informatização da empresa, foi preciso
primeiramente, realizar o levantamento de requisitos funcionais, listados logo a
seguir:
 ● O sistema deve permitir ao administrador a manutenção dos
usuários do sistema (como cadastramento, edição, consultas e
exclusões de usuários).
● O sistema deve conter uma tela de autenticação que irá verificar se
o nome do usuário e a senha estão corretos para ter acesso ao
sistema.
● O sistema deve permitir ao funcionário a manutenção de pedidos,
isto é, incluir, editar ou excluir os pedidos, bem como alterar o
status do pedido (entregue ou em produção).
● O sistema deve permitir ao funcionário a manutenção dos clientes,
(cadastrar, consultar, editar ou excluir os clientes no sistema).
● O sistema deve oferecer ao funcionário e ao administrador um
relatório de caixa diário.
Visando complementar o levantamento de requisitos e definir a
modelagem do sistema, foram construídos os diagramas de casos de uso.
Na Figura 6, apresenta a funcionalidade do sistema diante dos usuários,
e suas respectivas autorizações para com ele.
Figura 6 – Diagrama de Caso de Uso.

Fonte: Autoria própria, 2021.

 Diante das funcionalidades propostas nos diagramas anteriores, foi
criado o Diagrama de Atividade, apresentado na Figura 7.
Figura 7 - Diagrama de atividade.

Fonte: Autoria própria, 2021.

Tendo em vista as funcionalidades propostas nos diagramas anteriores,

foram criados o Diagrama de Classe, apresentado na Figura 8 e o Modelo do
banco de dados na Figura 9.
Figura 8 - Diagrama de classe.
Fonte: Autoria própria, 2021.

Figura 9 - Modelo do Banco de dados.

Fonte: Autoria própria, 2021.

 Na figura que segue é apresentada a tela de login para os usuários do
sistema.

Figura 10 - Tela de login

Fonte: Autoria própria, 2021.

A próxima figura retrata a tela de cadastros de clientes.

Figura 11 - Tela de cadastro do cliente

Fonte: Autoria própria, 2021.

A seguir, temos a tela de pedido.

Figura 12 - Tela de pedido

Fonte: Autoria própria, 2021.

E por fim, temos a tela que irá informar os valores do caixa do dia.

Figura 13 - Tela valor do caixa

Fonte: Autoria própria, 2021.

CONSIDERAÇÕES FINAIS
 A proposta deste artigo foi realizar a modelagem de um sistema para
controle de pedidos de um ateliê. Foram utilizadas as práticas da Engenharia de
Software para realizar o levantamento e documentação dos requisitos
levantados. Foram gerados diagramas UML, modelagem de banco de dados e
protótipos da interface desejada.
O intuito dessa proposta de informatização é garantir mais confiabilidade
e rapidez nos processos de entrega, confecção e recebimento do pedido. A
modelagem aqui realizada poderá viabilizar a implementação futura do sistema
que trará benefícios para a empresa. Salienta-se aqui a importância de
considerar o fator humano no levantamento dos requisitos, com a utilização da
modelagem gráfica para facilitar a comunicação nessa etapa que apresenta
grande impacto na eficácia do projeto.

REFERÊNCIAS BIBLIOGRÁFICAS

BATISTA, E. O. Sistema de informação: o uso consciente da tecnologia para o

gerenciamento. São Paulo: Ed. Saraiva, 2004.
BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. 3ª Ed. Rio
de Janeiro: Elsevier, 2015.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. Rio de
Janeiro: Elsevier, 2005.
ENGHOLM JÚNIOR, H. Engenharia do Software na prática. São Paulo: Novatec,
2010.
GUEDES, G. T. A. UML 2: uma abordagem prática. 2ª. Ed. São Paulo: Novatec
Editora, 2009.
LAUDON, K. e LAUDON, J. Sistemas de Informação Gerenciais. 11ª ed. São
Paulo: Pearson, 2014.
MAGNANI, M. WEBCASE 3.0 – Implementando diagramas de sequências e
diagramas de classes. Site Univali. 2009. Disponível em: <
http://siaibib01.univali.br/pdf/Marcelo%20Magnani.pdf>.

O’BRIEN, JAMES A. Sistemas de informação e as decisões gerenciais na era da

internet. 2. ed. São Paulo: Saraiva, 2004.
PENDER, T. UML, a Bíblia. Tradução Daniel Vieira. Rio de Janeiro: Campus,
2004.
PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional. 7ª.
Ed. Porto Alegre: McGraw-Hill, 2011.
SOMMERVILLE, I. Engenharia de software. 9ª. Ed. São Paulo: Pearson Prentice
Hall, 2011.