1
Criação de Sistema de Rastreio de Pedido no Ramo de Montagens e Manutenções
Creation of an Order Tracking System in the Assembly and Maintenance Branch
Bruno Calera Sperandio– brunocalerasp@[Link]
Faculdade de Tecnologia de Catanduva – Catanduva – São Paulo – Brasil
Igor Lima de Sousa – igorlima7194@[Link]
Faculdade de Tecnologia de Catanduva – Catanduva – São Paulo – Brasil
João Vitor Alves de Souza – jv7559838@[Link]
Faculdade de Tecnologia de Catanduva – Catanduva – São Paulo – Brasil
Kaik Aparecido Gomes Da Silva – kaik.silva4@[Link]
Faculdade de Tecnologia de Catanduva – Catanduva – São Paulo – Brasil
Renan Alves Morata – renanmorata18@[Link]
Faculdade de Tecnologia de Catanduva – Catanduva – São Paulo – Brasil
RESUMO
O resumo deve ser escrito em português, em espaço simples, ser um texto sintético que inclui
as ideias principais do trabalho, ou seja, os objetivos, a metodologia, os resultados e as
conclusões, permitindo que se tenha uma visão sucinta do todo, principalmente das questões
de maior importância e das conclusões a que se tenha alcançado. Deve ser redigido em
parágrafo único, mas sem a entrada de parágrafo. Deve possuir, no mínimo, 150 e, no
máximo, 250 palavras, seguido, logo abaixo, das palavras representativas do conteúdo do
trabalho, isto é, palavras-chave e/ou descritores, conforme a NBR 6028. Texto. Texto. Texto.
Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto.
Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto.
Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto.
Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto.
Texto. Texto. Texto.
Palavras-chave: Artigo. Revista Interface. Modelo. Devem ser separadas por ponto final.
ABSTRACT
Resumo em língua inglesa (obrigatório). Segue as mesmas indicações do resumo em língua
vernácula e deve incluir as palavras chaves. Texto. Texto. Texto. Texto. Texto. Texto. Texto.
Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto.
Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto.
Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto.
Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto. Texto.
Keywords: Keywords. Keywords. Keywords. Keywords. Keywords.
2
LISTA DE FIGURAS
FIGURA 1 – REPRESENTAÇÃO DA MODELAGEM MVC.................................................................7
FIGURA 2 – BANCO DE DADOS QUE ARMAZENA AS INFORMAÇÕES DE ALUNOS E CURSOS.9
FIGURA 3 – REPRESENTAÇÃO VISUAL DAS BRANCHES EM UM DIRETÓRIO.........................11
3
SUMÁRIO
INTRODUÇÃO......................................................................................................................................4
DIAGRAMA DE CASO DE USO.........................................................................................................5
DIAGRAMA DE CLASSES..................................................................................................................5
DIAGRAMA DE SEQUENCIA............................................................................................................6
MODELAGEM MVC (MODEL-VIEW-CONTROLLER)...............................................................7
BANCO DE DADOS..............................................................................................................................8
GIT.........................................................................................................................................................10
GITHUB................................................................................................................................................11
REFERÊNCIAS.....................................................................................................................................12
4
INTRODUÇÃO
1 a 2 parágrafos de contextualização do problema
1 parágrafo falando do problema
1 parágrafo falando dos objetivos do trabalho
1 parágrafo falando sobre o que se pretende alcançar
1 parágrafo falando da organização do trabalho: Na seção 1 serão abordados os fundamentos
teóricos bla bla; na seção 2 será ....
Este artigo tem como tema a implementação de um software em uma empresa do
ramo de montagens e manutenções. Tendo como fundamentação teórica vários autores
reconhecidos na área de engenharia de software, tais como Sommerville (2011), que aborda
tecnicamente o assunto e propõe uma implementação adequada para atender o usuário com
usabilidade simples. Gilleanes (2011) demonstra sobre a UML e suas definições, destacando
como um software depende de bons diagramas em sua construção para torná-lo mais limpo e
organizado.
Seguindo essa linha de raciocínio, nota-se que ainda há carência de softwares para
esse nicho de empresa, principalmente algo que permita ao cliente acompanhar
detalhadamente em qual estágio se encontra o produto solicitado. Diferentemente dos
sistemas de rastreamento comuns, na montagem de algo encontramos restrições mais
específicas, sempre relacionadas a um projeto. A empresa possui controle sobre isso, mas não
encontra maneiras fáceis de transmitir essas informações ao cliente. Com isso em mente, o
artigo proposto busca soluções para esse problema.
Para compor a artigo utilizamos de recursos recentes na área da tecnologia baseando
em desempenho e organização tanto de código quanto de versionamento, criando versões que
sofreram alterações durante o decorrer do projeto, foi usado linguagens web como C#, Html,
CSS, Javascript entre outras para o melhor controle de armazenamento foi usado o sqlserver e
como método de armazenar em repositórios e de controle da equipe foi usado Git e GitHub.
O objetivo do artigo é promover uma comunicação fácil entre cliente e empresa,
permitindo que a empresa informe em qual estágio se encontra o produto solicitado. Além
5
disso, visa ter um controle próprio para evitar atrasos nos pedidos, concluindo-os o mais
rapidamente possível. Por outro lado, o cliente pode se sentir mais seguro sobre o seu pedido,
tendo a capacidade de acompanhar seu desenvolvimento e as etapas que faltam ser
concluídas, com prazos definidos.
1. Fundamentação Teórica
1.1 DIAGRAMA DE CASO DE USO
De acordo com Guedes (2009), o diagrama de caso de uso é o diagrama que mais
engloba informações gerais, e também é o mais informal. Ele pode ser futuramente usado de
base para outros tipos de diagramas. Ele é simples, e de fácil compreensão para os usuários
poderem entender como vão funcionar os sistemas. Na construção de um diagrama de classe é
essencial identificar quem são os "atores", eles podem variar desde usuários a hardware
especial que de alguma forma vão interagir com o sistema. No DCU também se encontra os
serviços disponíveis aos atores, conhecidos nesses sistemas como "caso de uso". Eles
costumam incluir elementos como "cenas" que mostram diferentes cenários de uso e
extensões que descrevem variações em um caso de uso principal.
1.2 DIAGRAMA DE CLASSES
Um diagrama de classes é um dos principais modelos utilizados na UML (Unified
Modeling Language), utilizado principalmente para representar a estrutura estática de um
sistema orientados a objetos. Frequentemente usado para ilustrar as classes, seus atributos,
métodos e relacionamentos, buscando facilitar o entendimento geral do sistema. Segundo
Fowler (2010), "Um diagrama de classes descreve os tipos de objetos presentes no sistema e
os vários tipos de relacionamentos estáticos existentes entre eles. ”.
Sendo algo essencial desde a fase inicial do design, o diagrama de classes busca
apresentar os principais componentes do sistema. Apresenta classes como Cliente, Produto e
Pedido, seus atributos (nome, preço) e seus métodos (fazer pedido, atualizar estoque) por
exemplo. Além de lidar com os relacionamentos entre as classes:
• Associação: Onde uma classe possui uma relação direta com outra. Ex.: Cliente e
Pedido, onde um cliente pode realizar vários pedidos e cada pedido deve estar relacionado à
um cliente.
6
• Herança ou Generalização: Onde uma classe herda alguma característica de outra
classe. Ex.: Animal e Cachorro, onde Cachorro seria uma subclasse da classe Animal e acaba
por herdar suas características.
• Agregação: Representa o relacionamento em forma um todo, onde uma classe é
composta por diversas outras classes que podem existir independentemente de seu todo. Ex.:
Curso e Aulas, um Curso pode possuir diversas Aulas, mas as Aulas podem existir
independentemente do Curso.
• Composição: Semelhante à Agregação, porém uma agregação mais forte por assim
dizer, onde essas subclasses não podem existir sem sua classe principal. Ex.: Casa e Quarto,
onde uma Casa pode existir sem a classe Quarto, mas Quarto não pode existir sem a classe
Casa.
• Dependência: Quando uma classe depende diretamente de outra para executar uma
ação. Ex.: Calculadora e Operação, onde calculadora depende diretamente da classe operação
para realizar cálculos.
DIAGRAMA DE SEQUENCIA
Segundo Guedes (2019), o diagrama de sequência é um modo de apresentar uma
forma visual de como um objeto consegue interagir com outro objeto em um sistema durante
sua execução, com essa ferramenta e possível mapear de forma simples e visível as interações
entre esses elementos, colocando em evidencia como as mensagens são transmitidas entre
eles.
O diagrama de sequência necessita de outros diagramas para ser projetado como é o
caso do diagrama de caso de uso e o diagrama de classes para identificar os objetos que serão
usados no projeto, o diagrama busca mostrar de forma visual e sequencial as interações entre
esses objetos no sistema, como eles se comunicam para alcançar um objetivo em comum.
Além de ser útil na análise e design de sistemas, esse diagrama facilita a identificação de
problemas de comunicação e a otimização de processos, permitindo uma melhor compreensão
do fluxo de informações. Também pode ser utilizado em conjunto com outras ferramentas de
modelagem, como diagramas de atividades, para proporcionar uma visão mais completa do
sistema.
7
MODELAGEM MVC (Model-View-Controller)
De acordo com Martin Fowler (ANO), no capítulo 14 de seu livro “Padrões de
Arquitetura de Aplicações Corporativas”, o padrão Modelo-Vista-Controlador (MVC) foi
primeiramente criado como um framework para a plataforma Smalltalk, desenvolvido por
Trygve Reenskaug no final dos anos 1970, e desde então tem sido uma forte referência para
os frameworks de interface de usuário, além de moldar a forma como o design dessas
interfaces é concebido.
Figura 1 – Representação da Modelagem MVC
Fonte – Fowler (2002)
Segundo Fowler (2014, p. 330), “O MVC considera três papéis. O modelo é um objeto
que representa alguma informação sobre o domínio. É um objeto não-visual contendo todos
os dados e comportamento que não os usados pela interface de usuário. Na sua forma OO
mais pura, o modelo é um objeto dentro de um Modelo de Domínio (126). Você também
poderia pensar em um Roteiro de Transação (120) como o modelo, desde que ele não
contenha nenhum mecanismo de interface com o usuário. Tal definição amplia a noção de
modelo, mas se adapta à divisão de papéis do MVC.
8
A vista representa a exibição do modelo na interface com o usuário. Assim, se nosso
modelo for um objeto cliente nossa vista poderia ser um frame cheio de controles para a
interface com o usuário ou uma página HTML com informações do modelo. A vista diz
respeito apenas à apresentação de informações, quaisquer alterações nessas informações são
manipuladas pelo terceiro membro da tríade MVC: o controlador. O controlador recebe a
entrada do usuário, manipula o modelo e faz com que a vista seja atualizada apropriadamente.
Dessa forma, a interface de usuário é uma combinação da vista e do controlador.
BANCO DE DADOS
De acordo com Elmasri e Navathe (2005), os bancos de dados desempenham um papel
fundamental em diversas áreas de aplicação, como negócios, medicina e educação,
evidenciando a importância da tecnologia de bancos de dados no crescimento do uso de
computadores. Um banco de dados é definido como uma coleção de dados relacionados que
representam aspectos do mundo real, também conhecidos como minimundo. Esses dados
possuem significado implícito e são organizados de forma lógica e coerente, atendendo a
necessidades específicas de um grupo de usuários. Além disso, os autores destacam que um
sistema gerenciador de banco de dados (SGBD) é responsável pela criação e manutenção
desses bancos, permitindo a definição, manipulação e compartilhamento eficiente das
informações, enquanto também assegura a proteção e a integridade dos dados ao longo do
tempo.
Segundo Elmasri e Navathe (2005), a construção de um banco de dados, como o
exemplo do sistema UNIVERSIDADE, envolve o armazenamento de informações que
representam alunos, cursos e disciplinas, entre outros elementos. Os dados podem ser
representados por esquemas de código, como a classificação dos alunos em diferentes turmas,
conforme ilustrado na Figura 12. Os registros em um banco de dados frequentemente
apresentam relações entre si, como no caso do aluno “Smith”, cujos dados estão conectados a
registros no histórico escolar e nos pré-requisitos do curso. A manipulação do banco de dados
se dá por meio de consultas e atualizações, que devem ser expressas de forma precisa na
linguagem de consulta do sistema gerenciador de banco de dados (SGBD) antes de serem
processadas.
9
Figura 2 – Um banco de dados que armazena as informações de alunos e cursos
Fonte – Elmasri e Navathe (2005)
De acordo com Elmasri e Navathe “A SQL é uma linguagem de banco de dados
abrangente: ela possui comandos para definição de dados, consultas e atualizações. Assim, ela
tem ambas as DDL e DML. Além disso, tem funcionalidades para a definição de visões
(views) no banco de dados, a fim de especificar a segurança e as autorizações para as
definições de restrições de integridade e de controles de transação. Ela também possui regras
para embutir os comandos SQL em linguagens de programação genérica como Java, COBOL
ou C/C+”
Segundo Elmasri e Navathe “A SQL usa os termos tabela, linha e coluna, em vez dos
termos relação, tupla e atributo, respectivamente, para o modelo relacional formal. Vamos
10
usar os termos correspondentes de modo intercambiável. O principal comando SQL para a
definição de dados é o CREATE, que pode ser usado para criar esquemas, tabelas (relações) e
domínios [da mesma forma que outros. construtores, como visões (views), asserções
(assertions) e gatilhos (triggers).”
GIT
Podemos definir o Git como um sistema de controle de versão que é amplamente
utilizado principalmente no ramo de desenvolvimento de software como também em diversas
outras áreas da programação. Um controle de versão é um sistema que permite registrar todo
tipo de alteração que é feita dentro de um arquivo ou em um conjunto de arquivos durante seu
tempo de desenvolvimento para que possa guardar todas as versões e alterações dentro de um
sistema por exemplo. O Git permite principalmente a colaboração de várias pessoas em um
mesmo código mantendo o histórico de todas as alterações feitas e diversas outras
características facilitando o processo de desenvolvimento
Com as características podemos destacar principalmente os commits que registra todo
tipo alteração e mudança que foi feita no código junto com uma mensagem que descreve
brevemente o que foi alterado. Os branches que servem como ramificações para que os
diversos desenvolvedores possam trabalhar em novas funcionalidades, correções de bugs e
outras alterações de uma forma que não altere o código principal. E também podemos citar o
merge e o rebase, que funcionam como operações para integrar os branches já criados para
unificar todo o trabalho, funcionam de maneiras semelhantes mas acabam por afetar o
histórico de versões de maneira diferente, o merge (mesclagem) combina todo o conteúdo de
um ou mais branches em um só em apenas um, criando o chamado “merge commit” que une
todas as mudanças preservando todo o histórico, já o rebase move os commits que foram
feitas em um branch para outro, em vez de criar um merge commit ele acaba por mover os
commits para o outro branch modificando o histórico.
11
Figura 3 – Representação visual das branches em um diretório
Fonte – Raphael Santiago, DIO (2024).
GITHUB
O Github é uma plataforma baseada em nuvem que foi criada a partir do Git,
funcionando como uma “interface visual” que auxiliam os diversos usuários na navegação dos
diversos repositórios com diversas outras funcionalidades como as issues que funcionam
como tópicos para gerenciar e rastrear tarefas, melhorias e discussões relacionadas a um
projeto e os pull-requests permitem sugerir mudanças no código, permite que os
colaboradores sugiram modificações dentro do branch principal mas sem alterar ele, usado
para que as mudanças possam ser revisadas antes de serem integradas e que os usuários
consigam além de monitorar todas as alterações feitas dentro de um código, também
consigam armazenar e compartilhar de forma mais simples.
12
REFERÊNCIAS
GILLEANES T. A. G. UML 2 uma abordagem prática, 2ª Edição. Editora Novatec, 2011.
SOMMERVILLE, Ian. Engenharia de Software, 9ª Edição. Editora Pearson, 2011.
VENTURA PLINIO. Requisitos de software: Uma visão detalhada sobre Requisitos Funcionais,
Requisitos Não-Funcionais e Regras de Negócio. Indtach, 2023 Disponível em:
[Link]
FOWLER, Martin. UML Essencial: Um breve guia para a linguagem padrão de modelagem
de objetos. 3. ed. Porto Alegre: Bookman, 2010.
CHACON, Scott; STRAUB, Ben. Pro Git. 2. ed. Berkeley: Apress, 2014. Disponível em:
[Link] . Acesso em: 3 out. 2024.
GITHUB. Documentação do GitHub. Disponível em: [Link] Acesso em:
3 out. 2024.