TCC 8o SEMESTRE DOCUMENTACAO DE DETRITOS ESPACIAIS PDF

UNIVERSIDADE PAULISTA – UNIP
ENRICO RICCATO PRATTI PEREIRA

GUILHERME O ALVES DO NASCIMENTO
IGOR ALVES DA ROCHA
MATHEUS DA SILVA NASCIMENTO
THIAGO HENRIQUE PEREIRA SOARES
TRABALHO DE CONCLUSÃO DE CURSO
SÃO PAULO
2022
IGOR ALVES DA ROCHA
SOFTWARE PARA DOCUMENTAÇÃO E CONVERSAÇÃO SOBRE

DETRITOS ESPACIAIS
Trabalho de conclusão de curso para

obtenção do título de graduação em Ciência da
Computação apresentado à Universidade
Paulista – UNIP.
Orientador: Profº. MSC. Marco Gomes
SÃO PAULO
2022
IGOR ALVES DA ROCHA
SOFTWARE PARA DOCUMENTAÇÃO E CONVERSAÇÃO SOBRE

DETRITOS ESPACIAIS
Trabalho de conclusão de curso para

obtenção do título de graduação em Ciência da
Computação apresentado à Universidade
Paulista – UNIP.
Aprovado em:
BANCA EXAMINADORA
____________________________/ /__
Prof. Nome do Professor
Universidade Paulista – UNIP
____________________________/ /_
Universidade Paulista – UNIP
____________________________/ /_
Universidade Paulista UNIP
RESUMO
Os detritos espaciais que cercam o nosso planeta Terra e todo o espaço sideral,
tem aumentado com passar dos anos, através dos lançamentos de foguetes, satélites
e outras missões que são realizadas pelas agências espaciais. Essa problemática,
conhecida também como Lixo Espacial, apresenta seus riscos visto que esses detritos
podem conter, substâncias prejudicais e até mesmo radioativas, afinal toda matéria
tem um prazo de validade. O entendimento sobre esses acontecimentos, se faz
necessário junto as grandes agências espaciais, para que esses eventos sejam
reduzidos e os detritos que já circulam pelo espaço, tenham um destinatário correto
que reduza os impactos futuros que os mesmos podem causar a Terra.
Apesar de haver inúmeros acordos internacionais sobre esse tema e já existir

tecnologia capaz de recolher esses resíduos no espaço, o trabalho desenvolvido tem
como objetivo conscientizar a população em geral sobre os benefícios e malefícios
que as missões espaciais podem trazer para o futuro, sejam elas missões guiadas por
astronautas ou não. Desde o Sputnik, lançado a sessenta e cinco anos, inúmeras
colisões ocorreram e algum desses detritos chegaram a atingir o planeta Terra,
mesmo com leis e acordos em cima desse tema, não podemos descartar o fim das
missões no espaço, por acúmulo de detritos espaciais.
Palavras Chave: Detritos espaciais – Impactos – Espaço – Software

ABSTRACT
The space debris that surrounds our planet Earth and all of the outer space, has
increased over the years, through the launches of rockets, satellites and other missions
that are carried out by space agencies. This problem, also known as Space Garbage,
presents its risks since these debris can contain harmful and even radioactive
substances, after all, all matter has an expiration date. The understanding of these
events is necessary with the great space agencies, so that these events are reduced
and the debris that already circulates through space, have a correct destination that
reduces the future impacts that they can cause the Earth.
Although there are numerous international agreements on this topic and there
is already technology capable of collecting this waste in space, the work developed
aims to make the general population aware of the benefits and harms that space
missions can bring to the future, be they missions guided by astronauts or not. Since
Sputnik, launched sixty-five years ago, numerous collisions have occurred and some
of this debris has reached planet Earth, even with laws and agreements on this topic,
we cannot rule out the end of space missions, due to the accumulation of space debris.
Keywords: Space debris – Impacts – Space – Software

SUMÁRIO
1 INTRODUÇÃO ................................................................................................ 9
1.1 CONTEXTUALIZAÇÃO ............................................................................... 10
1.2 PROBLEMA DE PESQUISA ........................................................................ 11
1.3 MOTIVAÇÃO ................................................................................................ 12
1.4 JUSTIFICATIVA ........................................................................................... 13
1.5 OBJETIVOS ................................................................................................. 14
1.5.1 Objetivo Geral ............................................................................................... 14
1.5.2 Objetivo Específico ....................................................................................... 14
1.6 METODOLOGIA (S) DE PESQUISA ........................................................... 15
1.7 ESTRUTURA DO TRABALHO .................................................................... 15
2 REFERENCIAL TEÓRICO ........................................................................... 17
2.1 LIXO ESPACIAL .......................................................................................... 17
2.1.1 Foguetes....................................................................................................... 18
2.1.2 Sonda Especial ............................................................................................. 19
2.1.3 Satélite Artificial ............................................................................................ 20
2.2 DIREITO AMBIENTAL ESPACIAL .............................................................. 22
2.2.1 Colisão Terrestre .......................................................................................... 22
2.3 REDE DE COMPUTADORES ...................................................................... 23
2.3.1 Modelo TCI/IP ............................................................................................... 24
2.4 BANCO DE DADOS RELACIONAL ............................................................ 26
2.4.1 Modelo Relacional ........................................................................................ 26
2.5 NÍVEIS DE ACESSO .................................................................................... 27
2.6 ENGENHARIA DE SOFTWARE .................................................................. 28
2.7 RUP .............................................................................................................. 29
2.8 ENGENHARIA DE REQUISITOS................................................................. 29
3 MATERIAIS E MÉTODOS ........................................................................... 32

3.1 DELINEAMENTO DE PESQUISA................................................................ 32
3.2 MATERIAIS .................................................................................................. 35
3.2.1 Visual Studio Code ....................................................................................... 35
3.2.2 WAMP .......................................................................................................... 36
3.2.3 Eclipse .......................................................................................................... 37
3.2.4 Postman ....................................................................................................... 38
3.3 BASE DE DADOS ........................................................................................ 39
3.4 BANCO DE DADOS RELACIONAL ............................................................ 40
3.5 CHAT DE CONVERSAÇÃO ........................................................................ 41
3.6 SERVIDOR E HOSPEDAGEM ..................................................................... 42
3.7 NIVEIS DE ACESSO .................................................................................... 43
3.8 SEGURANÇA DO SOFTWARE ................................................................... 44
4 MODELAGEM .............................................................................................. 46
4.1 ANÁLISE DE REQUISITOS ......................................................................... 46
4.1.1 Requisitos Funcionais................................................................................... 46
4.1.2 Requisitos Não Funcionais ........................................................................... 47
4.2 UNIFIED MODELING LANGUAGE (UML) .................................................. 47
4.3 DIAGRAMAS ............................................................................................... 48
4.3.1 Diagrama de Caso de Uso ........................................................................... 48
4.3.2 Diagrama de Classes ................................................................................... 50
4.3.2.1 Project ........................................................................................................... 51
4.3.2.2 User ............................................................................................................... 51
4.3.2.3 Message ........................................................................................................ 51
4.3.2.4 Feed .............................................................................................................. 51
4.3.2.5 Register ......................................................................................................... 51
4.3.2.6 Login.............................................................................................................. 51
4.3.2.7 ForgetPassword ............................................................................................ 51

4.3.2.8 AuthenticateUser ........................................................................................... 51
4.3.3 Diagrama de Banco de Dados (MER) .......................................................... 52
5 ABORDAGEM UX E UI DESIGNER ............................................................ 54
5.1 UX DESIGN .................................................................................................. 54
5.2 UI DESIGN ................................................................................................... 55
6 PROTÓTIPO ................................................................................................ 57
6.1 HOME PAGE ................................................................................................ 57
6.2 REGISTER PAGE ........................................................................................ 57
6.3 CONFIRM PAGE .......................................................................................... 58
6.4 LOGIN PAGE ............................................................................................... 59
6.5 HOME (USUÁRIO) ....................................................................................... 60
6.6 PERFIL ......................................................................................................... 61
6.7 EDITA PERFIL ............................................................................................. 62
6.8 FEED ............................................................................................................ 62
6.9 CREATE POST ............................................................................................ 63
6.10 FEED PROJECT .......................................................................................... 64
6.11 CREATE PROJECT ..................................................................................... 65
6.12 COMPANIES ................................................................................................ 66
6.13 USERS ......................................................................................................... 67
6.14 MENSAGES ................................................................................................. 67
6.15 CHAT SEND IMAGE .................................................................................... 68
7 RESULTADOS ............................................................................................. 69
8 CONCLUSÃO............................................................................................... 70
9 TRABALHOS FUTUROS ............................................................................. 72
REFERENCIAS ............................................................................................ 73
9
1 INTRODUÇÃO
O primeiro satélite artificial foi produzido pela antiga União Soviética, o objeto
foi apelidado de Sputnik, sendo lançado em órbita terrestre em 4 de outubro de 1957.
Alguns meses após o lançamento, o Estados Unidos lançou o seu primeiro satélite em
janeiro de 1958, deste modo, tornando-se recorrente os lançamentos de satélites no
espaço para finalidades distintas (ENSINA RTP, 2017).
Primordialmente, convém frisar que já foram lançados cerca de 9 mil satélites,

sendo 5 mil classificados como lixo ou detrito espacial e aproximadamente 2.6 mil
ainda em operação (Ogando, 2020), resultando em mais de 3 mil toneladas de objetos
alocados na órbita terrestre, esses objetos são desde a peças de espaçonaves a parte
de foguetes, que vagam pelo espaço sem a devida documentação quando o satélite
se torna inutilizável (Ogando, 2020).
Além disso, após fragmentação desses objetos se cria um problema, visto que
dificulta a manutenção e observação, estima-se que existem mais de 130 milhões de
objetos possuindo cerca de 1mm de diâmetro, classificado como lixo espacial, um
detrito espacial é qualquer fragmento de um detrito que não possui mais utilidade e
está em órbita no espaço sideral por exemplo: um parafuso solto de uma nave
(Vigilância EUA, 2020).
Todavia, podemos observar que esses objetos adentram a atmosfera terrestre

em algum momento sendo fragmentações destruídas durante o percurso de reentrada
na atmosfera, porém algumas partições nem sempre são pulverizadas e caem em
locais distintos às vezes inacessíveis ou incalculáveis impactando no ecossistema ou
na comunicação global, deste modo não são documentadas de maneira eficaz a
queda do detrito, visto que não há uma boa comunicação entre especialistas da área.
Portanto, com o desenvolvimento de um acervo de banco de dados para

documentar a queda de um detrito espacial com suas informações, afim de facilitar
sua identificação, torna-se necessário o desenvolvimento de uma plataforma para
conscientização, compartilhamento e circulação de informações para cientistas e
estudiosos, consequentemente auxiliando na diminuição dos impactos ambientais
gerados pelos detritos espaciais.
10
1.1 CONTEXTUALIZAÇÃO
Segundo a ESA (2020) atualmente, existe um monitoramento coeso sendo

realizado pela Astroscale UK Ltd localizada no Japão e no Surrey Satellite Technology
Ltd (SSTL) que tem sede no Reino Unido, a vigilância espacial ocorre por dois satélites
que possuem imãs com finalidade identificar possíveis lixos espaciais e realizar a
limpeza da órbita terrestre. Contudo, alguns fatores de imprevisibilidades não
permitem a identificação e remoção desse lixo espacial, sendo assim, o detrito obtêm
reentrada precoce na atmosfera, pousando em um local indefinido, deste modo
impactando no ecossistema (ESA,2020).
Salientando, além dos impactos gerados do detrito espacial ao colidir com o

solo terrestre o lixo espacial é nocivo aos próprios astronautas, pois detritos espaciais
não documentados geram uma “conjunção vermelha” (quando um detrito chega tão
perto que passa a ser uma ameaça para a estação espacial), aumentando riscos de
catástrofes (Lewis, 2015).
Contudo, a documentação escassa de objetos espaciais resulta na criação de

novos detritos espaciais, por exemplo: objetos espaciais possuem uma massa
elevada e se movem em velocidades astronômicas, podendo atingir 28.440 km/h,
assim sendo, caso ocorra uma colisão entre eles os objetos são fragmentados se
tornando centenas ou milhares de detritos que vagarão pelo espaço, perdendo total
comunicação com seu país de origem, até entrarem na atmosfera terrestre podendo
cair em algum local indefinido sem prévia observação.
Segundo Agência espacial europeia (2020) em média, nas últimas duas

décadas, 12 fragmentações acidentais ocorreram no espaço a cada ano. As listagens
de detritos espaciais abandonados como foguetes geralmente ocorrem em
congressos internacionais de astronáutica de forma online, os objetos são listados e
classificados como preocupantes ou não, entretanto não há uma documentação
aprofundada de reentrada atmosférica ou quedas já ocorridas no solo, visto que as
principais quedas ocorrem na Antártida ou nos oceanos, sendo considerados lugares
inacessíveis para prenunciação.
11
1.2 PROBLEMA DE PESQUISA
Os detritos ou lixos espaciais que não são documentados ao cair em um local

indefinido impactam em diversas atividades na sociedade contemporânea, visto que
podem gerar situações alarmantes, sendo uma delas a danificação na comunicação
global ou poluição ecossistêmica.
Existem softwares que utilizam paradigmas para registro de materiais e

conteúdos pertencentes a lixos e detritos espaciais, porém essas plataformas
restringem o acesso do conteúdo apenas para o usuário que enviou o arquivo a rede,
por consequência o conteúdo não é compartilhado e informações e explorações que
abrangem a área não são disseminadas, como consequência a área estagna gerando
impactos socioambientais atuais.
A inexistência de dados e plataformas que estimulam a comunicação e

compartilhamento global de informações e materiais referentes a detritos espaciais,
afim de definir parâmetros que documentem os reais impactos gerados e corroborem
para atenuar a problemática é explicita, pois geralmente as informações sobre detritos
espaciais são debatidas apenas em congressos de especialistas ou retidas em banco
de dados governamentais, chegando a sociedade apenas notícias através de mídias
sociais e veículos de comunicação.
Contudo, a carência de recursos financeiros e desconhecimento técnico acerca

do assunto por parte da sociedade e de programação e desenvolvimento de software
atrativo colabora com a ausência de exploração do conteúdo referente a
documentação da queda de lixo espacial no solo terrestre. Deste modo, a cultura
nacional brasileira também interfere, em virtude de não incentivo e investimento na
área espacial. Ratificando, a inexistência de técnicas especializadas para
desenvolvimento de plataformas documentais e de comunicação entre estudiosos,
especialistas e leigos influenciam no impacto da problemática.
A importância da informação, independente do contexto onde for utilizada (seja

no nível operacional, tático ou estratégico) é fundamental, e esta importância só tende
a aumentar de acordo com a complexidade da sociedade e das organizações
inseridas, ou seja, a forma como a informação é trabalhada, obtida e exibida deve ser
o objeto de profunda análise, para que se evite risco no momento em que seja
12
necessária obtenha-se apenas “ruido” (FREITAS et al., 1997).
Dessarte, a elaboração de uma plataforma semelhante a uma mídia social

interativa prova-se necessário para obtenção de melhores resultados evolutivos na
sociedade e redução dos impactos gerados pelo lixo espacial, que se choca no solo
terrestre e o conteúdo remetente a área astronômica. Nessa conformidade, o
trabalhou se referenciou no desenvolvimento de uma aplicação com diversas
funcionalidades específicas, afim de avaliar a documentação e maior acervo de banco
de dados de proliferação de conteúdo de quaisquer detritos reduzem os impactos
gerados, sendo possível por algum modo a previsibilidade de futuras quedas,
induzindo a evolução literária, científica e técnica.
A questão de pesquisa que norteia este trabalho é: como a documentação da

queda de detritos espaciais auxilia na sociedade?
1.3 MOTIVAÇÃO
Diariamente, a Terra é atingida por pelo menos um pedaço de lixo espacial. Os

EUA, por exemplo, têm um projeto de vigilância espacial, o US Surveillance Network,
que atualmente "vigia" dezenas de milhares de objetos maiores que uma bola de tênis
flutuando ao redor do planeta. E cientistas estimam que possa haver nada menos que
100 milhões de fragmentos com mais de 1mm em órbita (BBC, 2015).
Atualmente, os Estados Unidos, a China e a Rússia lideram a lista de países

com mais satélites operacionais em órbita. Ao todo, e com a inclusão do Japão e do
Reino Unido, o grupo de países é responsável por operar 76% de todos os satélites.
O Brasil possui uma agência espacial que envia satélites ao espaço e que possui
astronautas, mas o setor de tecnologia e inovação do Brasil não é explorado, tendo
investido 2,7 bilhões, entretanto o país obteve PIB (produto interno bruto) de 7,4
trilhões de reais, sendo assim a proliferação que represente a queda de detritos
espaciais se tornando escassa.
Todavia, registros de lixo espacial são realizados por diversas pessoas, mas
não se obtêm dados efetivos desses objetos pela ausência de aplicações que auxiliem
e instruam indivíduos a realizarem esse processo. O lixo espacial representa mais
13
perigo para satélites ativos e naves espaciais tripuladas no espaço (e futuras

expedições espaciais) do que propriamente aos habitantes da Terra, pois, ao entrar
em contato com a atmosfera, grande parte dos destroços é queimada e destruída. Os
que conseguem atravessar essa barreira geralmente caem nos oceanos, já que estes
representam 75% do volume do planeta. Ressaltando, que alguns registros ocorreram
sobre quedas em locais com moradores, porém o indivíduo leigo não possui
conhecimento do que realizar ao avistar tal objeto.
O registro documentado de detritos espaciais que caem sobre os oceanos e

em locais com moradores deve ser realizado em uma aplicação, de modo que a
informação e instruções técnicas referentes a área tecnológica e científica possam
evoluir a sociedade contemporânea e influenciar a globalização. Afim de apresentar,
divulgar e comunicar informações sobre detritos que caem no solo terrestre a pesquisa
mostrará a importância do desenvolvimento de um software para documentação e
conversação referente aos detritos espaciais que adentram a atmosfera terrestre,
demonstrando a engenharia do software e auxiliar em decisões futuras e
demonstrações dos impactos gerados por tais objetos.
1.4 JUSTIFICATIVA
Segundo a telesintese (2018) o setor de satélites cresceu 3% no mundo, a

construção e manutenção de equipamentos em terra foi responsável por US$ 119,8
bilhões da receita total do setor. Uma evolução de 5,6% ano a ano. Este segmento
inclui dispositivos, VSats, gateways, dispositivos GNSS (de navegação por satélite),
além de equipamentos de rede. (TELESINTESE, 2018).
Salientando, pode-se observar que o aumento de lançamentos e evolução

tecnológica auxiliará no crescendo de detritos espaciais nos próximos anos, visto que
o número de desativações e reentradas na atmosfera serão maiores,
consequentemente a queda de fragmentos em solo terrestre ou no oceano
aumentarão como resultado. Atualmente, apenas dez países possuem a capacidade
de fabricar e lançar satélites, incluindo o Brasil. Entretanto, outros também fabricam
satélites, embora se utilizem de lançadores estrangeiros para coloca-los em órbita.
(Rossetto, 2013).
14
Contudo, apesar dos valores monetários desembolsados no desenvolvimento

de satélites artificiais pequenos fragmentos conseguem sobreviver a força
atmosférica, pois eles não são autodestrutíveis, visto que as empresas de produção e
envio para diminuição de custos criam os objetos utilizando essa metodologia, sendo
assim um método para destruição de um detrito espacial seria a autocombustão
utilizando-se de mais combustível.
O Brasil já foi o destino de um detrito caído do espaço, em fevereiro de 2012

na cidade de Anapurus, no estado do Maranhão, quando moradores observaram um
objeto metálico caindo do céu, o qual atingiu algumas árvores no local. A esfera
possuía cerca de 30 quilos e 1 metro de diâmetro e se tratava de parte de um foguete
francês catalogado como Ariane 4. (GAMA, 2012). Porquanto, caso houvesse uma
documentação através de uma plataforma web e informações compartilhadas
referindo-se ao detrito espacial disponíveis tornaria mais fácil seu reconhecimento e
identificação.
1.5 OBJETIVOS
1.5.1 Objetivo Geral
Este trabalho tem por objetivo o desenvolvimento de um software que permita

e auxilie na documentação, conversação e compartilhamento de informações a queda
de detritos espaciais e suas respectivas reentradas na atmosfera terrestre.
1.5.2 Objetivo Específico
• Identificar os impactos gerados por um detrito espacial
• Identificar os impactos gerados pela poluição sideral
• Elaborar um instrumento que permita a conversação em máquinas

simultâneas sobre detritos espaciais
• Permitir a documentação de dados sobre detritos espaciais
• Disponibilizar conteúdo informativo sobre artigos e detritos espaciais

15
1.6 METODOLOGIA (S) DE PESQUISA
No presente trabalho serão utilizados os procedimentos de pesquisa

qualitativas e quantitativas, abordando uma combinação de abordagem para obtenção
de resultados. As seguintes metodologias de pesquisa serão aplicadas: pesquisa
bibliográficas e pesquisa-ex-post-factos.
A metodologia de pesquisa bibliográfica foi escolhida, em virtude de explicar e

apresentar definições de nomenclaturas, procedimentos utilizados, lançamento,
direito constitucional e impactos gerados pelos detritos espaciais, utilizando de fontes
confiáveis todos os aspectos serão explorados e explicados utilizando de
embasamento teórico e referências bibliográficas integras.
A metodologia de pesquisa-ex-post-factos é implementada, afim de utilizar-se

de fatos que já ocorreram como por exemplo a culminação de um satélite artificial
lançado no espaço em detrito espacial, por fim obtendo sua reentrada e
fragmentações intactas e resistentes caindo sob o solo terrestre. Buscando,
demonstrando e avaliando fatores ou variáveis independentes que influenciaram na
ocorrência do impacto ambiental gerado pelo objeto espacial.
1.7 ESTRUTURA DO TRABALHO
O trabalho é divido em 8 partes:
O capítulo um apresenta elementos pré-textuais destinado ao conteúdo

introdutório como: introdução, contextualização, problema de pesquisa, motivação,
justificativa, objetivos e a metodologia de pesquisa.
O capítulo dois apresenta o Referencial Teórico, possuindo como objetivo a

explicação primordial do sistema e sua fundamentação.
O capítulo três descreve os materiais e métodos utilizados no desenvolvimento

do trabalho.
O capítulo quatro demonstra os resultados obtidos e realiza uma discussão

sobre sua funcionalidade.
16
O capítulo cinco, obtêm-se a conclusão do trabalhando, mostrando sua

importância e sinalização de trabalhos futuros.
O capítulo seis apresenta referências bibliográficas que auxiliaram no

desenvolvimento do trabalho.
O capítulo sete serão anexados informações e documentos como o RUP e

modelos replicados da engenharia de software.
17
2 REFERENCIAL TEÓRICO
Neste capítulo serão descritos conceitos teóricos utilizados para o

desenvolvimento do trabalho.
2.1 LIXO ESPACIAL
Segundo Tedesco (2018) o lixo espacial pode ser definido como objetos criados
pelos humanos e que se encontram em órbita terrestre, porém não representam
utilidade nenhuma, por exemplo, parte de foguetes, ônibus espaciais, satélites
artificiais, tanques de combustíveis e fragmentos de explosões que ocorrem na órbita.
(Tedesco, 2018).
Atualmente, empresas privadas, governamentais e países efetuam

lançamentos de objetos ao espaço. Convém frisar que o desenvolvimento e envio de
objetos ao espaço sideral são realizados por indústrias especializadas, afim de
realizar estudos e observações que possuem distintas características como criação
de um novo GPS (Sistema de posicionamento global), observar características
comportamentais de astros celestes, posicionamento de telescópios, sondas
espaciais ou enviar seres humanos para estações espaciais alocadas na órbita
terrestre.
Segundo o estudo de Rosetto (2013) sobre o monitoramento espacial, o

equipamento possui um tempo de combustível que funciona como sua vida útil, de
modo que ao findar-se, o objeto tornar-se um corpo itinerante pelo espaço até chocar-
se com algo. (Rossetto, 2013).
Entretanto, com intuito de observar e controlar objetos indesejáveis vagando

pelo espaço, estudos e monitoramento são realizados por diversos países com o
desenvolvimento de satélites e telescópios posicionados estrategicamente para
futuramente “varrer” o lixo utilizando alguns métodos que atualmente se encontram
em estudos como o procedimento japonês que visa a limpa da órbita terrestre
utilizando imãs e sensores. (Sarah Alves, 2021).
Ressaltando, por existirem diferentes tipos de detritos espaciais torna-se uma

tarefa complexa seu monitoramento, visto que alguns possuem apenas 1mm de
18
diâmetro, deste modo, os principais impactos gerados por essa poluição sideral são
as poluições oceânicas e impactos gerados na vida aquática, pois ao detrito adentrar
na atmosfera terrestre fragmentos que não foram pulverizados pelo atrito com o ar
chocam-se com os oceanos, solo ou até vilarejos que existam moradores. Optamos
por selecionar os principais detritos espaciais para descrições detalhadas.
2.1.1 Foguetes
Os foguetes são máquinas que produzem a força ou o impulso necessário para

empurrar um objeto para a frente. Eles são usados para lançar naves espaciais, além
de servir para disparar mísseis e fogos de artifício. (Britannica Escola, 2021).
O engenheiro americano Robert H. Goddard construiu o primeiro foguete

movido a combustível líquido em 1925. Em outubro de 1957, a União Soviética usou
um foguete para lançar a primeira nave espacial, o satélite Sputnik 1, em órbita em
torno da Terra. (Britannica Escola, 2021).
Cada foguete possui sua particularidade de fabricação. Os principais foguetes

espaciais são produzidos por físicos e engenheiros, a principal matéria-prima para o
desenvolvimento de um foguete é o alumínio podendo representar até 98% do
foguete, possui motores em sua estrutura (até quatro) que funcionam por propulsão
(CREF, 2019). Seu combustível pode ser líquido ou sólido que são alocados em tubos
e são sobreaquecidos pelos motores, afim de gerar uma fissão nuclear bombardeando
seu núcleo com nêutrons.
Todavia, eles são lançados a órbita terrestre com ou sem tripulantes, muitas
vezes a caminho de estações espaciais, planetas ou satélites próximos, mas torna-se
uma ameaça como lixo espacial ao perder sua utilidade ou sofrer algum dano, por
exemplo, caso sofra algum impacto durante a viagem e perca um parafuso ou tintura,
esse objeto ou textura vagará pelo espaço até obter reentrada na atmosfera terrestre,
sendo imprevisível seu local de queda ou dano que poderá ser causado.
19
Figura 1: Foguete Atlas-Centauro 10 decolando
Fonte: nasa.gov
2.1.2 Sonda Especial
Sondas espaciais são naves não tripuladas, possuem utilidades na exploração

de áreas e corpos remotos no universo. Elas carregam equipamentos de laboratório,
para realizar medições, que serão enviadas à Terra por telemetria. Entre esses
equipamentos, estão magnetômetros, que medem o campo magnético de diferentes
astros, e detectores de partículas, que analisam as propriedades de raios cósmicos
presentes no espaço. (AEROJR, 2019).
Entretanto, algumas sondas conseguem sair do próprio sistema solar, por

exemplo a Voyager 2 que hoje está localizada em uma região considerada interestelar
que se encontra ainda no sistema solar, mas até 2030 a sonda conseguirá quebrar
esse paradigma, deste modo perdendo quaisquer contato com a Terra por questões
de energia. (Revista Galileu, 2018).
20
Atualmente, existem diferentes tipos de sondas como a sonda de sobrevoo que

carrega uma câmera e possuem finalidades de fotografar corpos celestes, a sonda
orbital, sendo enviada para a órbita de determinado astro e alocando em sua órbita,
sendo assim transmitindo informações para a Terra e a sonda de aterrissagem que
tem como objetivo aterrissar na superfície de algum astro para fotografar e enviar
dados. (Amorim, 2021).
As sondas tornam-se lixos espaciais ao perderem sua utilidade, deste modo a

comunicação com o objetivo é perdido ou desligado, fazendo com que o objeto
continue em órbita terrestre e continue vagando pelo espaço até voltar para Terra.
Figura 2: Spirit, veículo explorador que chegou a Marte em 2004
Fonte: nasa.gov
2.1.3 Satélite Artificial
Um satélite artificial é um objeto no espaço que circunda a órbita terrestre ou

outro astro. O satélite artificial é criado pelo homem, como a estação espacial
internacional de astronautas que orbita a Terra. (PixForce, 2018).
O primeiro satélite artificial surgiu em 4 de outubro de 1957, sendo lançado pela

antiga União Soviética, apelidado de Sputnik 1 a sua função era de transmitir sinais
de rádio do espaço, entretanto, após esse lançamento diversas empresas
governamentais e privadas efetuaram distintos lançamentos de satélites ao espaço
para distintas funções. (PixForce, 2018).
21
Eventualmente, existem satélites geoestacionários e satélites orbitais, o satélite

geoestacionário estagna em um ponto estratégico da terra, enquanto o satélite orbital
viaja no plano equatorial em velocidade constante. As principais funções de satélites
são as de transmitir ondas de rádio para confecção de mapas, comunicação,
militarismo, observação de outros corpos celestes no espaço e replicação de missões
em microgravidades.
Os satélites são corpos compostos por módulos e possuem como materiais um

computador de bordo, câmeras e baterias, sendo seu principal material o alumínio, de
modo que combinadas da maneira correta desempenham diversificadas atividades.
Por não possuir uma vida útil pré-definida o satélite artificial transforma-se em resíduo
orbital quando perde sua utilidade, em virtude dessa ocorrência o objeto sideral, vaga
pelo espaço podendo gerar acidentes com outros corpos ou cair em locais
indesejáveis.
Figura 3: Sputnik 1, imagem ilustrativa do primeiro satélite orbitando a Terra
Fonte: Dmitrii Ustinov/ArtStation

22
2.2 DIREITO AMBIENTAL ESPACIAL
A sociedade contemporânea necessita cada vez mais da exploração espacial

para evolução tecnológica, entretanto há estudos realizados que a quantidade
exorbitante de detritos no espaço são danosos, em decorrência disso há pesquisas
voltadas a legislação a ser aplicável, quando ocorre algum tipo de dano ao solo
terrestre, ocorre a aplicação do Direito Ambiental Espacial, ou seja, aplicação de
normas, princípios e tratados que protegem o meio ambiente com a adoção de
práticas sustentáveis e respeitosas (SOMMER; CARDOSO, 2016).
Primordialmente, apenas os estados possuíam o direito de lançar objetos ao

espaço, porém ao longo das décadas, organizações intergovernamentais
internacionais como empresas privadas adquiriram a possibilidade de efetuar
lançamentos, principalmente após o investimento nesse setor econômico, porém
mediante de um seletivo processo de requisitos. (SOMMER; CARDOSO, 2016).
Apesar do tema não ser tão explorado nacionalmente no território brasileiro,

existem debates e tratados que são fomentados acerca disso em conferências
mundiais. Atualmente, a ONU (organizações das nações unidas) é responsável em
autenticar, validar e aprovar lançamentos de qualquer objeto a órbita terrestre.
(SOMMER, CARDOSO, 2016).
2.2.1 Colisão Terrestre
Após o objeto que se encontra na órbita terrestre seja desativo ou substituído

e continue no espaço ele não deixa de ser responsabilidade de seu lançador. O trato
constitucional previsto pela ONU prevê que se o detrito espacial colidir com a Terra e
causar algum dano outrem, o estado lançador arcará com a ônus de indenização, a
determinação foi instaurada pela convenção sobre a responsabilidade internacional
por danos causados por objetos espaciais, ratificado pelo Brasil no decreto nº
71.981/73, em seu Art. 2º dispõe: um Estado lançador será responsável absoluto pelo
pagamento de indenização por danos causados por seus objetos espaciais na
superfície da Terra ou a aeronaves em voo.(BRASIL, 1973)
Portanto, medidas cabíveis afim de atenuar a problemática e diminuir impactos

gerados por detritos espaciais e a caráter de responsabilizar o estado lançador são
23
essenciais, visto que no direito os princípios são de suma importância, pois eles
proporcionam a base do ordenamento jurídico, além de apontar a direção que
devemos escolher em ocasiões conflitantes.
Figura 4: detrito espacial fotografado na Costa do Marfim.
Fonte: Zolgafo
2.3 REDE DE COMPUTADORES
Uma rede de computadores caracteriza-se por dois ou mais computadores

interligados, não importando por qual meio (cabos ou ondas de rádio), desde que
sejam capazes de trocar informações entre si e/ou compartilhar seus recursos de
hardware. (Tedesco, 2017).
Ressaltando, para haver uma comunicação fluida entre máquinas é necessário

que elas estejam utilizando a mesma regra de rede naquele momento utilizando
protocolos criados, deste modo medidas de segurança são aplicadas na construção
de determinada rede para que os dados possam se movimentar de maneira compacta.
O sistema topológico visa construir uma comunicação, interligando módulos e

processados através de enlaces físicos, funcionando como rede de transmissão,
deste modo formulando um conjunto de regras com o intuito de organizar a
comunicação se denominando como protocolos.
Posteriormente, uma rede de computadores utiliza diversos modelos para

24
construção de protótipos físicos e desenvolvimento de regas, em virtude disso um dos

modelos mais aplicados é a metodologia de utilização TCP/IP. Este modelo é aplicado
em desenvolvimento afim de permitir a comunicação entre máquinas, com intuito de
simplificar a circulação de variados dados e informações através de um software.
2.3.1 Modelo TCI/IP
O modelo de referência TCP/IP foi desenvolvido pelo Departamento de Defesa

dos Estados Unidos (DoD). (Acacio, 2007). O DoD exigia uma comunicação segura
para transmissão de dados, deste modo a criação do modelo ocasionou na resolução
de transmissão de dados confiáveis sobre quaisquer circunstâncias. (Acacio, 2007).
TCP (Protocolo de Controle de Transmissão) é o responsável por quebrar uma

mensagem em partes menores, as enviando pela internet, enquanto o IP (Protocolo
de Interconexão), possui a finalidade de fornecer o endereço correto para a entrega
da informação. Atualmente, o modelo TCP/IP é aplicado de forma padronizada, desde
que obteve sua criação em setembro de 1981, tornando-se o padrão de aplicação que
a internet utiliza para modelar seu tráfego de informações. (Acacio, 2007).
Consequentemente, o molde utilizado se baseia na comunicação de cliente

servidor, no qual um computador envia solicitações a um outro computador, por
finalidade de executar uma tarefa na rede. Em outras camadas, existem protocolos
utilizados para diferentes funções como o HTTP usado para internet, FTP (protocolo
que transfere arquivos) e o próprio SMTP, responsável por enviar e receber
mensagens de email. Este protótipo é dividido em camadas que possuem diferenças
características e nomenclaturas sendo denominadas como: aplicação, transporte,
internet e acesso à rede.
a) Aplicação: esta camada possui diversos protocolos que permitem o

funcionamento correto do modelo TCP/IP. A camada de aplicação não possui
um modelo exatificado para o desenvolvimento de um software, sendo o
protocolo escolhido de acordo com a necessidade de construção sendo eles:
FTP,TELNET, HTTP, SMTP, POP3, DNS.
b) Transporte: a camada de transporte é vital para a transmissão de dados, visto

25
que ela efetua a transferência de dados entre as máquinas. Convém frisar que
ela oferece serviços de transporte fim-a-fim formando uma conexão lógica entre
dois pontos da rede e define a conectividade ponto-a-ponto entre as aplicações
do host.
c) Internet: esta etapa é responsável pela determinação de definir o melhor

caminho para transmitir os dados, afim de eleger a melhor rota de comutação.
Nesta cama é utilizado o protocolo de IP, entretanto ela possui outros menos
utilizados como: ICMP, ARP e RARP. (NetAcademy, 2007).
d) Acesso à rede: a camada de acesso à rede tem função de lidar com o hardware
da interface de rede, com a estrutura das frames, com o endereçamento físico,
com o controlo de acesso à rede e com a utilização do meio físico para
comunicação (NETWORKING, 2017).
Figura 5: modelo de representação TCP/IP
Fonte: modeloosietcpip
26
2.4 BANCO DE DADOS RELACIONAL
A palavra banco de dados surgiu do termo inglês Databanks. Atualmente, este

termo foi alterado para Databases (Banco de dados), possuindo deste modo um
significado mais plausível. (SETZER; CORRÊA DA SILVA, 2005, p. 1).
Segundo DATE (2004, p. 10), um banco de dados é uma coleção de dados

persistentes, usada pelos sistemas de aplicação de uma determinada empresa. Deste
modo, um banco de dados é uma coletânea de dados armazenados em um
determinado local afim de permitir a manutenção de atividades, afim de facilitar o
encontro de informações.
Em primeiro lugar, o banco de dados relacional surgiu em meados dos anos

70, sendo denominado como sistemas de gerenciamento de banco de dados
relacionais (SGBDR), um banco de dados relacional é um mecanismo de
armazenamento que permite a persistência de dados e opcionalmente implementar
funcionalidades, deste modo visando a automatização de tarefas, visto que utiliza uma
padronização denominada como modelo relacional. (Bóson, 2019).
Em virtude disso, um modelo relacional foi proposto para sua utilização, sendo
caracterizado como modelo de dados representativo (ou de implementação) que foi
proposto por Ted Codd, em 1970, se baseando em conceitos matemáticos e conjunto
de lógica de predicado, os primeiros sistemas obtiveram sua disponibilização em
1980, desde então o protótipo é aplicado em diversos sistemas como: Access, Oracle,
MySql, entre outros (ELMASRI; NAVATHE, 2011, p. 38).
2.4.1 Modelo Relacional
O modelo relacional é uma arquitetura que pode ser descrita de maneira formal
ou informal, possuindo semântica formal com tabelas linhas e colunas. No modelo
relacional os dados são organizados em coleções de tabelas bidimensionais e são
denominadas como relações. (Bóson, 2017).
A relação é a forma de organizar os dados em linhas e colunas embasado em

conjuntos lógicos, essa ideia visa três aspectos fundamentais se referindo a estrutura
de dados, integridade e manipulação de dados. (Elisângela, 2011). Sendo assim, o
27
banco de dados é representado com um conjunto de relações e conjunto de valores,

deste modo organizando de maneira otimizada os dados.
Entretanto, para organização e restrição de manipulações indevidas de dados

afim de definir funcionalidades o banco de dados relacional possui uma chave
primária, sendo identificada como um atributo exclusivo que não se repete na relação
alocado em uma tabela, afim de diferenciar os dados, porém para permitir relações
entre tabelas existe a chave estrangeira, consistindo em uma variável que faz
referência a chave primária de outra tabela, por exemplo, existe uma tabela cliente e
sua chave primária está definida como cpf e outra tabela chamada pedidos podemos
ter uma chave estrangeira chamada cpf também que efetua relacionamento com a
chave primária da tabela cliente e cria um vínculo entre elas.
Figura 6: Modelo relacional de um banco de dados
Fonte: leavingtech, 2020.
2.5 NÍVEIS DE ACESSO
Níveis de acesso podem ser definidos como a gestão descentralizada da

plataforma. Esse recurso é a hierarquia de permissões dentro da plataforma. As
opções disponíveis são: administrador, administrador de unidade, treinando, entre
outros. ( Didatica, 2019).
28
Os níveis de acesso determinam a gestão de acesso de um determinado

usuário em uma plataforma, deste modo restringindo informações e funcionalidades
avaliando o perfil de cada indivíduo em uma plataforma. Este modelo é utilizado
empresarialmente e o padrão é conter três níveis diferentes de acessos, sendo eles
nível 1, nível 2 e nível 3 e administrador. (1Doc, 2019).
a) Administrador: este nível de acesso refere-se ao(s) responsável(is) pelo

sistema, este nível de acesso possui acesso a todas funcionalidades e
possuem aplicabilidade para alteração de qualquer dado ou informação.
b) Nível 1: este grau se remete a um setor classificado como pessoas de

confiança, neste nível o usuário possui acesso a documentos, pode enviar,
cadastrar e ler documentos, alterar informações, por fim visualizar informações
do banco de dados.
c) Nível 2: O nível 2 possui aspecto operacional afim de permitir o usuário

visualizar, cadastrar e ler documentos, entretanto não permite a alteração de
documentos e informações.
d) Nível 3: São usuários do software que apenas podem visualizar documentos,

mas não podem enviar, alterar e nem cadastrar novas informações, deste modo
possuindo um acesso simplificado das funções.
2.6 ENGENHARIA DE SOFTWARE
A engenharia de software é uma abordagem sistemática e disciplinada para o

desenvolvimento de software (PRESSMAN, 2006). A base da engenharia de software
é um conjunto de atividade que são utilizadas para o desenvolvimento de um
programa.
A área da engenharia de software abrange programas que são executados por

aparelhos como computadores ou celulares, sendo manipulados por engenheiros de
software. Presentemente, se torna imprescindível a utilização de aplicativos para
realização de qualquer atividade, deste modo sendo indispensável para a globalização
atual.
29
Os softwares são desenvolvidos através de modelos adaptados, padrões e

modelos fomentados durante décadas, conseguinte, visando a qualidade e a
aplicabilidade com intuito de atender e suprir as necessidades e expectativas dos
usuários daquele produto.
Um software possui requisitos para seu desenvolvimento, passando por

períodos de avaliações e validações, de modo geral requisitos são condições
impostas de funcionalidades que determinado aplicativo deverá conter, sendo assim
no modelo atual existem dois tipos de requisitos: requisitos funcionais e requisitos não
funcionais.
a) Requisitos funcionais: os requisitos funcionais são serviços que o sistema

deverá fornecer em seu desempenho, declarações de serviços que o sistema
deve disponibilizar, como o sistema deve reagir a entradas específicas e se
comportar em determinadas situações. (UNESP, 2005).
b) Requisitos não funcionais: os requisitos não funcionais são restrições sobre os

serviços ou as funções oferecidas pelo sistema, eles podem estar relacionados
às propriedades emergentes do sistema, como confiabilidade, tempo de
resposta e ocupação de área. (SOMMERVILLE, 2011).
2.7 RUP
RUP é uma sigla que significa Rational Unified Process, que traduzindo para o
português, quer dizer Processo Unificado da Rational. (Alicia, 2020), o RUP é um
modelo utilizado da engenharia de software para o desenvolvimento de uma
aplicação, sua principal função é apresentar as atividades realizadas por cada
integrante do grupo de desenvolvedores. No gerenciamento de um projeto, o RUP
(Rational Unified Process) apresenta uma solução disciplinada na organização de
tarefas entre os colaboradores.
2.8 ENGENHARIA DE REQUISITOS
A engenharia de requisitos de software é um setor da área de engenharia de

software, denominada como uma etapa de planejamento, onde há uma comunicação,
30
visando o levantamento de requisitos que são encarados como funcionalidades que o

software desenvolvido possuirá, satisfazendo os anseios do cliente com consistência.
(Opencadd, 2018).
Outrossim, pode-se afirmar que nesse estágio dados são coletados,

averiguados, descritos e documentados, consequentemente transformados em
informações para desenvolvimento de um software, na medida em que a engenharia
de requisitos de um software fará um roteiro de paralelismo definindo minuciosamente
as etapas a serem seguidas para melhor obtenção do software desejado e suas
aplicações requeridas pelo cliente.
Em primeiro lugar, a engenharia de requisitos de um software surgiu no período

da “crise do software” na década de 70. A crise de software demonstrava a
necessidade e complexidade de desenvolvimento de uma aplicação com alta
demanda que o mercado e os profissionais da área de TI não acompanhavam por
alguns fatores como: gestão de custo, estimativa de prazos e produtividade
profissional, por consequência paradigmas, técnicas e métodos foram desenvolvidos
com etapas pré-estabelecidas com o intuito de contornas essas adversidades, por fim
com a evolução sistemática e aperfeiçoamento dos profissionais da tecnologia ao
decorres dos anos a engenharia de requisitos de software se consolidou, sendo
aplicada de maneira essencial.
Eventualmente, com a evolução estratégica dessa área padrões e etapas foram

desenvolvidos, afim de facilitar na criação de um software, as etapas predefinidas da
engenharia de requisitos são: elicitação, análise e negociação, especificação,
modelagem, validação e gestão. Cada etapa desempenha uma função essencial no
desenvolvimento e na qualidade de software, deste modo impactando no projeto
inegavelmente.
a) Elicitação: a etapa de elicitação realiza o levantamento de requisitos, se torna

incumbido a tarefa de a tarefa de identificar os fatos relacionados aos requisitos
do Sistema, de forma a prover o mais correto e mais completo entendimento
do que é demandado daquele software (facom, 2017). Neste tópico é
relacionado a forma que a informação foi adquirida e todos os posicionamentos
envolto da problemática.
31
b) Análise e negociação: a análise e negociação de requisitos verifica a

necessidade dos requisitos listados, afim de determinar a consistência e
completude, deste modo a consistência determina que nenhum requisito dever
contraditório, enquanto a completude denomina que nenhum serviço que seja
necessário tenha sido esquecido. Sobretudo, o tópico prioriza a inclusão,
eliminação ou modificação de condições impostas (Opencadd, 2018).
c) Especificação: nesta etapa o sistema é especificado e traduzido de forma

técnica, deste modo todos os requisitos do software que se pretende construir
incluindo requisitos funcionais e não-funcionais são documentados em
linguagem natural (português, inglês, etc.). (engsoftmoderna, 2020).
d) Modelagem: a modelagem utiliza da UML (Unified Modeling Language). Nessa

etapa são criados diagramas de casos que são usados para documentar e
modelar diversos aspectos do sistema. O diagrama de caso é utilizado para
demonstrar a funcionalidade do sistema utilizando o ponto de vista do usuário.
e) Validação: a validação se ocupa em demonstrar que os requisitos elicitados

realmente foram desenvolvidos e o sistema foi coberto, atendendo a proposta
imposta (engsoftmoderna, 2020).
f) Gestão: o gerenciamento de requisitos é uma matriz de rastreabilidade dos

requisitos elicitados, para que numa eventual necessidade de alteração,
possam ser imediatamente analisados os impactos e efeitos (Mário, 2014).
32
3 MATERIAIS E MÉTODOS
Precipuamente, afim de atingir os resultados propostos no desenvolvimento do

projeto, neste tópico serão abordadas as ferramentas utilizadas para a construção
sólida de informações e os materiais que são os aspectos relativos aplicados na
criação do software, deste modo descrevendo pontualmente as atividades realizadas.
Em primeiro lugar, com intuito de atingir os objetivos propostos no desenvolvimento
do software para documentação de detritos espaciais e validar as ideias formuladas,
se realizou um desenvolvimento fragmentado por etapas distintas.
O primeiro estágio consistiu na obtenção de uma base de informações

consistentes e confiáveis referentes aos detritos espaciais, em subsequência os
requisitos de desenvolvimento foram elicitados, em virtude disso avaliando e
determinando aspectos funcionais e não funcionais da aplicação. Para determinar
objetivos e delimitar a viabilidade de criação do software foi consultado o Stuffin, sendo
uma ferramenta que permite observar os satélites existentes na órbita terrestre em
tempo real, sendo assim validando o alcance de uma plataforma com informações
sólidas referentes a temática proposta.
Em seguida, a implementação de algoritmos que resultassem na criação de um

banco de dados e servidores para permitir a comunicação entre máquinas para alocar
e divulgar informações que documentam estudos e debates referentes aos detritos
espaciais foi aplicado utilizando a arquitetura do modelo MVC (Model-View-
Controller), dessa forma com testes de funções e sub-rotinas que se refere aos
aspectos técnicos do funcionamento do software.
Por fim, as correções sobre a aplicação foram realizadas, com finalidade de

otimizar o software e validar a pesquisa qualitativa para obtenção de resultados e
avanços em áreas características responsáveis pelos detritos espaciais que orbitam
a Terra e sua queda no solo.
3.1 DELINEAMENTO DE PESQUISA
O estudo se baseou no modo de pesquisa exploratório, através de revisão

bibliográfica em consultas literárias como: livros, sites, artigos científicos e órgãos
públicos, sendo de intuito de pesquisa teórico. Este tipo de pesquisa tem o foco em
33
proporcionar maior familiaridade com o problema em questão (GIL, 2007).
Contudo, para realizar a validação do software e sua fundamentação literária a

metodologia utilizada é de característica descritiva, visto que aspectos da engenharia
de requisitos serão replicados para descrição dos procedimentos experimentais
abordados em sua arquitetura.
Os métodos e técnicas utilizados foram os modelos predefinidos pelas práticas

implementadas da engenharia de software, engenharia de requisitos e modelos de
arquitetura habitualmente utilizados no mercado comercial de software.
Os procedimentos utilizados para definição dos requisitos necessários para

formulação da arquitetura foram obtidos através de um estudo tratado como
qualitativo, baseado na engenharia de requisitos na obra denominada Engenharia de
software (Pressman, 2011).
A projeção do modelo organizacional do software foi projetada para arquitetura

através da elaboração de alguns diagramas na linguagem UML (Unified Modeling
Language). A UML é um artefato que permite a documentação cronológica da série
de artefatos que irá modelar o sistema orientado a objeto, com diagramas de casos
de uso.
34
Figura 7: Exemplo de diagrama de caso de uso
Fonte: ONG J.A, 2021
A proposta de iniciação do desenvolvimento da ferramenta após a elicitação de

requisitos estendeu-se para definição e separação de requisitos funcionais e não
funcionais, para determinar o comportamento do software, com a utilização de
métodos existentes na produção de uma aplicação.
Os requisitos funcionais referem-se aos serviços que o sistema deverá

oferecer, determinando assim o comportamento em distintas situações a entrada
especifica de dados, como por exemplo: o acesso de informações ao banco de dados
com artigos documentados sobre detritos espaciais ou interações com diferentes
interfaces que permitem a leitura dos arquivos ou conversação entre os usuários da
plataforma.
Enquanto, os requisitos não funcionais definem aspectos de restrições do

sistema, ou seja, características imprescindíveis para o funcionamento coeso do
software, mas que o usuário não tem acesso direto como: sincronização de dados,
35
confiabilidade, tempo de resposta, níveis de acesso ou representações de dados no

servidor. A falha funcional deste aspecto de requisito poderá inutilizar o sistema, em
virtude disso a implementação de tratamento de erros foi acrescentada para contornar
essas requisições.
Enfim, para otimizar a construção, a metodologia utilizada foi aplicada sobre

diferentes linguagens de programação que permitiam maior manipulação e testes de
API (Application Programming Interface) que permitem a aceleração na obtenção de
padrões e conjuntos de sub-rotinas no código, utilizando linguagens como: JAVA,
HTML, JAVASCRIPT e MYSQL.
3.2 MATERIAIS
Para obtenção de resultados significativos o estudo utilizou de ferramentas

existentes para elaboração e teste de algoritmos desenvolvidos durante as etapas
estabelecidas, no qual foram adaptados por nós a extensão e separação de uso de
cada material. Em suma, os materiais utilizados foram descritos nesta seção.
3.2.1 Visual Studio Code
Criado pela Microsoft em 2015, o Visual Studio Code é um editor de código,

afim de permitir o desenvolvimento de aplicações web. Esta plataforma possui
disponibilidade em variados sistemas operacionais como: Windows, Linux e Mac OS,
deste modo possuindo uma grande versatilidade.
Em virtude de ser uma plataforma gratuita, a aplicação possui a características

que permite uma navegação consistente pelo código, sendo assim, o aplicativo possui
suporte para diversas linguagens de programação diferentes por exemplo: C#, C++,
PHP, Java, HTML, R, CSS, SQL, Markdown, TypeScript, LESS, SASS, JSON, XML e
Python.
Além disso, o software detém recursos que permitem a modularidade no

desenvolvimento dos algoritmos, permitindo de modo organizacional a fragmentação
do código em distintos pacotes, deste modo, respeitando as boas práticas e
arquiteturas de projetos exemplificando: o modelo MVC (Model-View-Controller).
36
Figura 8: Visão geral do Visual Studio Code.
Fonte: VS Code, 2015.
3.2.2 WAMP
WAMP (Windows, Apache, MySQL, PHP) é um conjunto de programas, de

forma que se o usuário instalar o esse aplicativo em determinada máquina todos os
softwares desse conjunto serão instalados também. A principal finalidade dessa
aplicação é permitir o desenvolvimento de programas destinadas a web.
A variabilidade do WAMP permite o desenvolvimento de um servidor usufruindo

do apache, afim de viabilizar o processamento de diferentes linguagens de
programações e que seja possível a comunicação fluída com o protocolo HTTP(
Hypertext Transfer Protocol) que é o protocolo para transferência de texto, por meio
deste protocolo é possível estabelecer o contato com a comunicação de redes e
linguagens de programação como PHP ( Hypertext Preprocessor) e banco de dados
como o MYSQL para gestão de dados.
Em contrapartida, a gerência de banco de dados é facilitada, sendo realizada

através de uma interface gráfica, a plataforma é gratuita, que é disponibilizada no
próprio site do WAMPSERVER e disponibiliza a exibição do site desenvolvido de
forma local mesmo sem a utilização de internet.
37
Figura 9: Visão geral do WAMP
Fonte: WAMP, 2020.
3.2.3 Eclipse
O Eclipse é uma ferramenta IDE que compreende vários tipos de linguagem e

que aceita a instalação de plugins para emular o desenvolvimento da plataforma.
(Thiago, 2012). A interface de desenvolvimento aceita variados exemplos de
linguagens de programação tal como: C, C++, JAVA, Python e PHP, entretanto a
linguagem mais utilizada na plataforma é JAVA.
A ferramenta fornece bibliotecas que permitem a criação de interfaces gráficas

e desenvolvimento voltado a objetos, de modo que respeitem as boas práticas de
construção e arquitetura de um software, permitindo a separação do código em
pacotes e em classes diferentes.
No entanto, o material utilizado no Eclipse como kit foi o Spring tool que é uma
plataforma de código aberto, dispondo em seu kit ferramentas pré-instaladas para o
desenvolvimento de aplicações em Java utilizando tecnologias, auxiliando na
automatização de processos no desenvolvimento do software e na criação de
algoritmos.
38
Figura 10: Interface inicial do Eclipse IDE.
Fonte: Eclipse, 2017
3.2.4 Postman
O Postman é uma ferramenta que dá suporte à documentação das requisições

feitas pela API (Application Programming Interface) ele possui ambiente para a
documentação, execução de testes de APIs e requisições em geral. (Versiani, 2021).
Os testes de aplicações são realizados através requisições HTTP e da análise do seu
retorno.
Esse software é essencial no auxílio de criação de uma aplicação, visto que o

Postman permite a análise dos testes de forma otimizada, pois é possível reduzir o
tempo de produção de funções (rotinas), afim de melhorar o comportamento do
código.
Além disso, a aquisição dessa ferramenta é gratuita, em virtude disso a sua

utilização é constante nos últimos anos. A cada requisição enviada para teste, o
Postman realiza a análise e apresenta visualmente os aspectos da API (Application
Programming Interface), deste modo reduzindo os testes no desenvolvimento do
projeto.
39
3.3 BASE DE DADOS
Após a verificação na literatura, foi possível obter uma base de dados sólidas
observando trabalhos e plataformas que disponibilizassem informações autênticas
com intuito de apresentar os detritos espaciais existentes em órbita terrestre, seus
impactos e soluções para contornar a problemática.
Inicialmente, a base de dados para detecção dos detritos espaciais existentes

em órbita terrestre foi obtida através da plataforma Stuff in Space, desenvolvida em
2015 a plataforma trabalha com um mapa tridimensional, disponibilizando em tempo
real a localização dos detritos que orbitam a Terra, utilizando do banco de dados da
USSTRATCOM( USSUnited States Strategic Command) para alimentar suas
informações diariamente, sendo assim disponibilizando um acervo com os satélites
artificiais que existem atualmente.
Ao analisar imagens disponibilizadas em tempo real da órbita terrestre, se

tornou possível identificar uma exorbitante quantidade de satélites artificiais em órbita
terrestre, entretanto de modo que não exista uma plataforma primária que permita
uma comunicação alinhada entre a sociedade sobre esses objetos, sua queda e
danos causados a documentação se torna escassa.
Figura 11. Órbita terrestre visualizada através do Stuff in Space
Fonte: Stuffin.com
40
3.4 BANCO DE DADOS RELACIONAL
Inicialmente, a obtenção do banco de dados foi realizada através da criação de

servidores locais utilizando a ferramenta WAMP, de modo que configurasse de
maneira local um usuário denominado como administrador para criação do banco de
dados usufruindo da linguagem MYSQL. Por consequência, o banco de dados
principal foi criado e sobre o banco de dados tabelas com procedimentos e funções
foram originadas.
Primeiramente, convém frisar que para haver compatibilidade entre o banco de

dados e a plataforma foi elaborado o desenvolvimento de uma classe exclusiva para
estabelecer a conexão entre o banco de dados e o java. A classe denomina-se como
“ConexãoBD”, para funcionamento coeso a classe engloba o driver que integra a
extensão da biblioteca JDBC, url permitindo a conexão com a porta do localhost da
máquina, user sendo o usuário normalmente descrito como “root” e pass para inserção
de senha para acessar o banco de dados.
O modelo de dados do MYSQL é de entidade-relacionamento, sendo assim

permite o desenvolvimento de diferentes tabelas para realização de tarefas, deste
modo foram criadas tabelas com diferentes finalidades, sobretudo as principais
funções são: permitir o cadastro, alteração, exclusão ou consulta de dados de
usuários, permitir o registro de mensagens transmitidas, gerenciamento de
informações gerais, validação de dados como o login ou nível de acesso e
armazenamento de documentos transitados entre os usuários. Entretanto, foi
desenvolvida uma tabela para armazenamento de dados dos usuários que foram
cadastrados na plataforma, possuindo login (sendo seu nome de usuário) e senha. A
tabela possui uma chave primária para que haja um controle.
O banco de dados relacional MYSQL é imprescindível para a subsequência no

funcionamento coeso do projeto, impactando no comportamento direto dos requisitos
não funcionais estabelecidos, deste modo as características de entidade-
relacionamento foram exploradas, estabelecendo interações entre tabelas, deste
modo, com intuito de preservar a segurança e aplicar automatizações procedures e
triggers para automatização de processos foram implementados, realizando uma
maior resposta de manutenções e requisições de sistema instanciados durante o uso.
41
Figura 12: Modelo de arquitetura de três camadas de um banco de dados.
Fonte: UFCG, 2011.
3.5 CHAT DE CONVERSAÇÃO
A elaboração de um chat de conversação é a premissa essencial para um

funcionamento coeso do software, a criação do software foi providenciada através da
metodologia multi-thread com socket, afim de estabelecer comunicação ponta a ponta
entre indivíduos com intuito de permitir a conversação, compartilhamento e
documentação de lixo espacial.
Uma Thread em linguagem de programação pode ser considerada um fluxo de

controle sequencial dentro de um programa, onde damos alguma tarefa e ela o realiza,
provendo maior performance. (Leonardo, 2015). O thread funciona como um
subsistema, de modo que a implementação de múltiplas threads funcionem como
enumeras rotinas executando concorrentemente no mesmo processo.
O socket é definido como um modelo de comunicação em dois sentidos, com

intuito de viabilizar uma conexão entre cliente/servidor, onde é passado como
parâmetro um IP e uma porta de servidor. (Leonardo, 2015). Essa opção de
implementação é obtida através da linguagem de programação em java, sendo
utilizada como corriqueira na arquitetura de chats de conversação.
Em primeiro lugar, a criação do chat com multi-threads e sockets obteve-se

através da implementação de algoritmos com conceitos práticos como estrutura de
decisão, definição de comportamento e tratativa de erros como try-catch, visto que a
42
produção foi efetuada na linguagem de programação JAVA na IDE eclipse, por fim de
maneira secundária, interfaces gráficas que permitissem a interação visual com o
sistema foram criadas utilizando a linguagem CSS (Cascading Style Sheets), O CSS
(Cascading Style Sheets) é um mecanismo que permite a adição de estilos visuais
atrativos em documentos web, provando-se essencial na aplicação deste trabalho.
Figura 13: Dois chats simultâneos do protótipo desenvolvido
Fonte: Astroid, 2021
3.6 SERVIDOR E HOSPEDAGEM
Na área computacional, um servidor é definido como um recurso dentro de um

sistema computacional maior, capaz de processar aplicações, prestar serviços e
armazenar dados. Esses sistemas podem ser físicos ou virtuais, estarem instalados
local ou remotamente, geralmente são escaláveis e possuem alto poder de
processamento.
É fundamental obter um domínio inicialmente para possibilitar o acesso aos

recursos oferecidos por um site, o domínio é um endereço de acesso de um
determinado site, existem diferentes terminações de domínios, mas no Brasil a
principal é:.com.br. Consequentemente, a obtenção de um endereço é primordial para
o funcionamento lógico do software gerado.
43
Deste modo, a utilização de um servidor pode ser aplicada para diferentes

propósitos, no caso deste trabalho sua utilização foi essencial para hospedar a
aplicação desenvolvida, sendo possível disponibilizar o seu acesso na internet. Após
a realização de um deploy, que em engenharia de software é definido como a etapa
de implementação do sistema, a hospedagem é essencial, visto que no caso da
validação deste projeto é insubstituível seu emprego.
3.7 NIVEIS DE ACESSO
A definição de diferentes níveis de acesso foi implementada com objetivo de

distinguir e classificar diferentes usuários cadastrados na ferramenta, assim sendo
disponibilizando diferentes recursos na plataforma se baseando na sua posição
estabelecida no software ao cadastrar e autenticar o usuário.
A lógica de arquitetura para diferentes níveis de acesso foi obtida através da

criação de classes em java na IDE eclipse, utilizando do recurso Enum. O Enum são
paradigmas que consistem em conjuntos com valores fixos, funcionando como uma
lista de valores pré-estabelecidos, à visto disso possuindo essa nomenclatura Enum.
Em virtude dos aspectos apresentados, se tornou elementar a criação de diferentes
níveis de acesso, a declaração de Enum foi possível através da utilização de
procedimentos e sub-rotinas, respeitando as regras de negócio da engenharia de
requisitos; os privilégios são definidos como total, parcial e restrito ao sistema.
Os privilégios totais ao sistema são somente disponibilizados aos

administradores e desenvolvedores primários do sistema, enquanto os privilégios
parciais serão requeridos aos usuários secundários como cientistas e estudiosos da
área de detritos espaciais, por fim os privilégios restritos são referenciados para os
indivíduos cadastrados e validados como leigo e inexperiente no assunto tratado.
O uso de hierarquia de classes é delineado mediante do uso de arrays-list em

conjunto de construtores definidos com getters e setters que chama os construtores
definidos como abstratos permitindo a própria subclasse do Enum escolher a
permissão enumerada na lista de cada tipo de nível de acesso.
44
3.8 SEGURANÇA DO SOFTWARE
Pela observação dos aspectos analisados, a necessidade da segurança do

software é essencial para validação e preservação dos dados de cada indivíduo e da
veracidade das informações oferecidas na ferramenta, de modo que permita a
consolidação na confiabilidade do software.
A realização da segurança do software é enumerada por: confiabilidade,

criptografia e validação de login. O padrão para validação de login é efetivado através
da verificação de requisições estabelecidas na validação de lógica no banco de dados,
a permissão do login foi implementada utilizando o padrão aberto OAuth, esse modelo
é comumente utilizado pelos aplicativos atualmente, visto que permitem o acesso as
aplicações usando contas relativas de outros sites como exemplo: facebook, google e
Microsoft.
OAuth é um protocolo de autorização que permite a autenticação da aplicação

sobre outra autenticação, este método requere a permissão do usuário de adentrar
em sua conta sem acessar sua senha, caso a requisição seja aceita o aplicativo
disponibiliza os materiais daquela aplicação. Em suma, no projeto foi implementado
este método, em subsequência token de acessos foram utilizados como instrumento
de gerar senhas em cadeias de caracteres que validam o acesso de determinado
usuário, afim de evitar fraudes e roubo de dados.
A criptografia, ou a encriptação dos dados, é essencial para a segurança de um

sistema, já que ela transforma os dados em algo ilegível para quem não possui a
chave de segurança responsável por descriptografar aqueles dados. A criptografia é
responsável pela confidencialidade dos dados.
Com a autenticação é possível verificar a identidade do usuário, servidor, host

ou qualquer entidade do sistema. Tipicamente a autenticação é realizada através de
uma senha, mas existem várias outras maneiras de se realizar uma autenticação,
como os tokens bancários, muito comuns hoje em dia, ou através da utilização de
chaves.
Entretanto, a criptografia de ponta a ponta para preservação de mensagens

enviadas entre usuários será realizada. A criptografia de ponta a ponta protege os
45
dados de forma que proporcione uma segurança nas mensagens encaminhadas

durante uma conversa em determinado chat, esse método de criptografia permite que
apenas os dois pontos obtenham acesso consistente ao conteúdo do texto enviado,
evitando que mensagens interceptadas permitam a invasão de privacidade do
remetente e destinatário.
Por fim, a criptografia de dados foi implementada nesse sistema distribuído por
meio da linguagem java, o modelo de criptografia aplicado é o AES 256. Este modelo
é um algoritmo de criptografia simétrico, a cifra de blocos é capaz de lidar com 256
bits, de modo que o algoritmo permita a conexão com o banco de dados restringindo
os dados armazenados e validando as matrizes dos dados em bytes.
Figura 14: Exemplo de implementação da criptografia AES 256 (HTIJ, 2019)
Fonte: HTIJ, 2019.

46
4 MODELAGEM
Neste capítulo é documentada a modelagem do sistema que atenda os

requisitos impostos, afim de permitir a aplicação prática de uso do software referente
a conversação e documentação de detritos espaciais. A modelagem prevê a descrição
dos requisitos da engenharia de software sendo elas: análise de requisitos, diagrama
de caso de uso, diagrama de classe, diagrama de banco de dados e diagrama de
linguagem UML.
4.1 ANÁLISE DE REQUISITOS
Afim de apresentar as funções disponibilizadas pelo software modelado, os

tópicos mostrarão as funções de requisitos funcionais e requisitos não funcionais do
sistema, deste modo delimitando especificadamente os objetivos propostos.
4.1.1 Requisitos Funcionais
A aplicação tem premissa de desenvolvimento em duas partes:
• Gestão do usuário: nesse aspecto o usuário é responsável por toda a parte

de criação e edição da sua conta, podendo alterar a qualquer momento suas
informações pessoais.
• Gestão da aplicação: a gestão de aplicação se refere ao ambiente onde o

usuário é responsável por toda a parte de criação de conteúdo para a página,
podendo criar ou alterar seus posts e se comunicar com outros usuários via
chat.
Gestão do usuário
RF01: A aplicação deve permitir criar, alterar e excluir um usuário;
RF02: A aplicação deve permitir criar, alterar e excluir um perfil de usuário;
RF03: A aplicação deve autenticar o e-mail do usuário na criação do perfil;
RF04: A aplicação deve permitir a alteração da senha do usuário caso haja

esquecimento;
47
Gestão da aplicação
RF05: A aplicação deve permitir criar, alterar e excluir um post comum.
RF06: A aplicação deve permitir criar, alterar e excluir um post de projeto.
RF07: A aplicação deve permitir o envio de mensagem para outros usuários.
RF08: A aplicação deve permitir criar, alterar ou excluir comentários em um

post comum ou post de projeto.
RF09: A aplicação deve permitir criar, alterar e excluir um projeto.
4.1.2 Requisitos Não Funcionais
RNF01: A aplicação deve ser desenvolvida em plataforma orientada a WEB.
RNF02: A Aplicação deve ser desenvolvida na linguagem JavaScript.
RNF04: A aplicação deve utilizar um banco de dados NoSQL.
RNF05: A aplicação deve solicitar a autenticação do usuário e senha para

acesso.
RNF06: A aplicação deve validar o e-mail do usuário para registro de conta.
4.2 UNIFIED MODELING LANGUAGE (UML)
A UML (UNIFIED MODELING LANGUAGE) é uma linguagem utilizada para

desenvolver a modelagem de um sistema, dessa forma sendo vital sua aplicação.
Esse modelo é definido para documentar em forma de gráfico e diagramas o
comportamento estrutural que o software terá em seu desempenho.
Primeiramente, nós recorremos A UML como modelo de projeção estrutural do

software, visto que o padrão organizacional de demonstrar a teoria do funcionamento
é essencial para uma formação otimizada, afim de compreender os aspectos
envolvidos para um bom funcionamento. Em suma, a UML nos permitiu simplificar e
48
compreender os requisitos necessários para um funcionamento qualificado.
Durante o desenvolvimento, os diagramas utilizados foram: diagrama de caso

de uso, diagrama de classes e o diagrama de banco de dados (MER), dessa maneira
fragmentou a ordenação do projeto e tornou a visão sobre o sistema efetiva,
diminuindo a ocorrência de erros graves durante sua implementação.
Figura 15: Imagem diagramas utilizados no desenvolvimento do ASTROID.
Fonte: Autoria Própria.
4.3 DIAGRAMAS
Usaremos dos diagramas para apresentar os conceitos e ideias desenvolvidas

de maneira mais objetiva visualmente e com uma estrutura mais simplificada, para
melhor entendimento.
4.3.1 Diagrama de Caso de Uso
Com o Diagrama de Caso de Uso, colocamos em evidencia as maneiras como

os usuários podem interagir com o sistema do nosso software desenvolvido. Ele não
mostra muito detalhes desses processos, ele é mais usado para dar uma visão geral
dos relacionamentos de casos de uso, sistema do software e o usuário.
49
Como detalhado na imagem abaixo, os usuários são representados por uma

forma oval, os usuários por bonecos palitos e as possíveis interações são modeladas
por linhas que ligam o usuário aos casos de uso.
Com esse diagrama é possível:
• Esclarecer as metas de interação entre usuário e sistema
• Organizar e definir os requisitos funcionais
• Modelar o fluxo básico desses eventos
Figura 16: Imagem diagrama de cado de uso no desenvolvimento do ASTROID.

50
4.3.2 Diagrama de Classes
O Diagrama de Classes foi usado para documentar toda a arquitetura do

software, esse diagrama precisa ser bem estruturado, para descrever o que esta
presente no software desenvolvido.
Eles são componentes básicos da Linguagem de Modelagem Unificada (UML),

afinal cada componente desse diagrama, relata qual classe realmente será
programada e qual a suas funções de interação, como mostra a imagem abaixo.
Figura 17: Imagem do Diagrama de Classes no desenvolvimento do ASTROID.

51
4.3.2.1 Project
A função Project detalha aos usuarios todos os post já realizados em nosso

software referente aos detritos espaciais, de todos os usuarios.
4.3.2.2 User
A User é usada para identificar se o usuario já possui um cadastro em nosso

software desenvolvido.
4.3.2.3 Message
Atraves da função Message, um usuario com cadastro em nosso software

consegue mandar mensagem e imagens no bate papo, com outros usuarios
cadastrados em nossa plataforma.
4.3.2.4 Feed
Na aba Feed, o usuario consegue ter acesso a todos os post realizados pelo
por ele, além de conseguir enviar novos post, seja eles em textos ou imagens.
4.3.2.5 Register
Com a funçao Register, novos usuarios da plataforma, conseguem fazer seus

cadastros, para conseguir interagir com outros usuarios e realizar post sobre detritos
espaciais em nosso software.
4.3.2.6 Login
A função Login, permite o acesso de um usuario já cadastrado em nossa

plataforma, atraves do seu email e sua senha.
4.3.2.7 ForgetPassword
Caso o usuario tenha esquecido a sua senha de acesso, com a função

ForgetPassword, o mesmo recebe uma senha aleatoria em seu email, para acessar a
sua conta e posteriormente realizar a mudança da senha.
4.3.2.8 AuthenticateUser
Atraves dessa função, uma medida de segurança é estabelecida, garantindo

que o usuario que acesse o seu perfil, tenha autorizaçao para o uso do software.
52
4.3.3 Diagrama de Banco de Dados (MER)
O diagrama de banco de dados foi utilizado no projeto, afim de documentar as

entidades de relacionamento existente entre o banco de dados. Como forma de
estabelecer os aspectos para desenvolvimento do banco de dados e sua
apresentação, o projeto consistiu em três tabelas, User, Post e Mensage. Cada tabela
possui uma finalidade distinta e atendem os requisitos impostos na engenharia do
software e análise de requisitos.
A tabela User é a principal, essa tabela é destinada a criação e armazenamento

de informações sobre o usuário, seja o usuário novo ou antigo, a filtragem dos dados
é realizada por essa entidade. O modelo de entidade possui dez campos definidos
como tipos inteiro e texto. Os campos existentes nessa tabela são: Nome, avatar,
biografia, primeiro nome, segundo nome, visto por último, sexo, país e id do usuário.
A chave primária dessa tabela é o Id usuário.
Outrossim, a tabela Post possui intuito de cadastrar e armazenar no banco de

dados de forma lógica os posts realizados na plataforma, essa entidade possui um
campo como chave estrangeira, com objetivo de estabelecer relacionamento entre a
tabela User e post, deste modo estabelecendo uma comunicação entre as tabelas. A
entidade post possui os campos: creator id, comment, Project, timestamp, type, user
id sendo a chave estrangeira referenciada para tabela User.
Por fim, a última tabela é a mensage, ela tem como meta o armazenamento
das mensagens no banco de dados e permitir uma comunicação fluída e mútua entre
os usuários, conforme predefinido, existe relacionamento entre a entidade mensage e
user, visto que para haver uma mensagem é necessário ter um usuário, sendo dessa
forma a comunicação existente. Essa tabela possui alguns campos para guardar os
valores de maneira metódica, as variáveis são: mensagem_id que é a chave primária,
autor_id, timestamp, chat id, membros, contente, nome, id_chat, user_id sendo a
chave estrangeira que permite o relacionamento entre as duas tabelas. Abaixo é
apresentado a elaboração do diagrama de entidade e relacionamento (MER) para
exemplificar a prática desenvolvida.
53
Figura 18: Imagem do Diagrama de entidade e relacionamento do ASTROID.

54
5 ABORDAGEM UX E UI DESIGNER
Neste capítulo serão abordados os conceitos e diferenças de UX e UI design e

seu detalhamento e aplicações práticas de seus conceitos no desenvolvimento do
software.
5.1 UX DESIGN
A UX (User Experience) é a experiência do usuário (IRONHACK, 2019). Sendo

assim, a UX é a área responsável em se preocupar com a interação do usuário com
a plataforma, garantindo um produto fluído em todas as etapas, finalmente, facilitando
o manuseio de navegação, tornando-a intuitiva e descomplicada.
Primordialmente, convém ressaltar que as principais estruturas da experiência

do usuário são: atrativo visual, utilidade, acessibilidade, credibilidade, intuitividade,
desempenho técnico e confiabilidade. Atualmente, é indispensável a utilização e
preocupação com os aspectos da experiência do usuário em qualquer projeto.
Prosseguindo, de acordo com uma pesquisa feita pela universidade Missouri

localizada nos Estados Unidos com 20 alunos do curso de tecnologia e informação a
primeira impressão mais impactante para o usuário é o design, provando desse modo
a fundamental participação e aplicação dos conceitos da experiência do usuário em
qualquer projeto.
Em nosso projeto, utilizamos os pilares da experiência do usuário como forma

de tornar a plataforma inteligível com uma excelente arquitetura de informações. A
necessidade de uma plataforma que possua flexibilidade e facilidade para divulgação
científica é evidenciada na sociedade, porém as aplicações que existem geralmente
não correspondem as expectativas que os usuários e estudiosos precisam e esperam.
Portanto, com intuito de mudar esse paradigma nós utilizamos na construção

do ASTROID o conceito de uma rede social que mantenha usuários com informações
uteis e atualizados em tempo real sobre detritos espaciais com a intuitividade que uma
plataforma desse gênero possui, também mantendo a liberdade que cada indivíduo
tem em seu manuseio, enfim, com uma acessibilidade facilitada as informações, tendo
em vista a maneira que as pessoas se comportam na internet.
55
Figura 19: apresentação das informações utilizando os conceitos UX.
5.2 UI DESIGN
UI design (user interface design) se refere a interface do usuário, essa área é

responsável pela demanda de produzir interfaces para computadores, celulares e
outros dispositivos eletrônicos, tendo como base principal a usabilidade, afim de
proporcionar uma experiência agradável aos usuários.
As principais estruturas para padronização efetiva do UI Design são: visual

design, cores, design gráfico, layouts e tipográfica. Ao contrário do que se pensava
em outrora, diversas pesquisas já provaram que o nosso cérebro reage
instantaneamente ao que a visão emite para ele.
Segundo a pesquisa da universidade Missouri dos Estados Unidos prevê que

em média os usuários prestam mais atenção inicialmente ao design gráfico e a
harmonia organizacional das informações iniciais apresentadas por 5 segundos,
sendo assim já definindo a primeira impressão que gera a percepção,
consequentemente influencia e convence o usuário a permanecer no site ou se retirar.
Conseguinte, a aplicação e combinação dos aspectos visuais da interface do

usuário e a organização das informações que o mesmo deverá obter contato
estabelece a imagem e reputação do software indiscutivelmente.
56
Entretanto, no desenvolvimento do ASTROID toda a arquitetura do software

obteve criação através da aplicação de todos os conceitos desse âmbito, a junção
arquitetônica foi baseada no desenvolvimento da identidade artística visual
estabelecendo originalidade ao site, com finalidade de tornar a experiência do
estudioso intuitiva através de emblemas, palavras chaves e uma estética que
permitisse uma combinação de cores harmoniosas para observação.
Todos os materiais utilizados durante a ilustração do site são originais,

desenvolvidos com padrões empregados da UI e conhecimentos técnicos adquiridos
de computação gráfica como: representação das cores, geometria de layout,
manipulação de imagens e modelos de iluminação.
Figura 20: Conceitos de UI aplicado e interface intuitiva.

57
6 PROTÓTIPO
Tendo em vista os aspectos observados e abordados, as implementações de

todos os requisitos propostos na seção 4.1 de “Análise de requisitos” foram criadas
fielmente, consequentemente o software requerido obteve êxito em funcionamento.
Cada imagem a seguir apresentará as funcionalidades do protótipo em execução.
6.1 HOME PAGE
A Home Page é a primeira página do software, essa página é uma página de

primeira experiência do usuário, entretanto tem funções imprescindíveis, ela é
responsável em direcionar o usuário para a tela de login ou tela de registro de novo
usuário.
Figura 21: Imagem apresentando Home Page do software.
6.2 REGISTER PAGE
A Register Page é a página proposta ao registro de novo usuário, nessa página

o indivíduo criará seu usuário para ter acesso a plataforma, essa página exige apenas
o e-mail de cadastro do usuário e uma senha, no rodapé da página contém um botão
que ao clicar o indivíduo será direcionado a página de login.
58
Figura 22: Página de cadastro de novo usuário.
6.3 CONFIRM PAGE
A página de confirmação é destinada a autenticar o novo usuário e cadastrar

seus dados no banco de dados, afim de gerar e permitir seu acesso ao software. Ao
realizar o cadastro uma mensagem é enviada ao e-mail que o novo usuário cadastrou,
esse e-mail permite a confirmação de cadastro do indivíduo, entretanto caso o e-mail
de confirmação não chegue a caixa de entrada a página comporta a função de
reenviar a verificação clicando no botão “resend verification Email”. Após confirmar o
cadastro ele estará apto para realizar o login no sistema e usufruir das funções
disponibilizadas para todos os usuários no software.
59
Figura 23: Imagem da página de confirmação de cadastro de novo usuário.
6.4 LOGIN PAGE
A Login Page é a página responsável por permitir o login do usuário que

possui uma conta criada na plataforma, ela requere o e-mail e senha utilizados no
registro, a autenticação é simples, porém eficaz. Se o e-mail não constar no registro
o acesso será negado, se a senha e e-mail não coincidirem com os dados do
registro o acesso consequentemente será negado, apenas será possível adentrar a
plataforma com e-mail e senhas válidos cadastrados no banco de dados.
60
Figura 24: Página de login de usuário.
Fonte: Autoria própria.
6.5 HOME (USUÁRIO)
A interface HOME (usuário) é a página visível após o usuário realizar o login

em sua conta na plataforma, deste modo essa interface constitui das funções e botões
HOME, Feed, Projects, Users, Companies e messages. Cada botão do cabeçalho
direciona o usuário para uma página diferente do próprio software. No canto superior
direito é exibido o nome e foto de perfil do usuário, por fim no mesmo canto superior
contém o botão de Logout, tendo como função permitir a saída do usuário da conta.
61
Figura 25: página inicial do usuário.
6.6 PERFIL
A página perfil é para apresentar informações sobre o usuário como: nome,

post e edição de perfil. Essa página é simples e dinâmica na apresentação de
informações.
Figura 26: Interface de perfil.

62
6.7 EDITA PERFIL
A área de edição de perfil permite ao usuário a alteração de alguns de seus

dados como: nome, sobrenome, localização, sexo e trabalho. Após o usuário realizar
a alteração de qualquer dado as informações são atualizadas no sistema,
consequentemente podendo ser visualizada pelo usuário e outros utilizadores do
software.
Figura 27: interface de edição de perfil.
6.8 FEED
A página de feed é o local que aparece todas os posts realizados por todos os
usuários que um determinado usuário tem adicionado em sua lista de amizade na
rede. O fluxo de mensagens referentes a detritos espaciais é apresentado nessa
interface. O fluxo de informações aparece em modelo pilha, sendo a postagem mais
recente a primeira a ser exposta no topo do fluxo de informações. Nessa área é
possível criar post clicando no botão “create post”, de modo que seja possível enviar
uma imagem, um texto ou ambos (restrito a informação referente a detrito espacial).
63
Figura 28: FEED de notícias
6.9 CREATE POST
Create Post é a área destinada permitir a criação de um post sobre um detrito

espacial e suas respectivas informações, as funções permitidas são: envio de texto,
envio de imagem ou envio de texto com imagem, o desenho de paisagem no canto
inferior permite o envio de uma imagem, por fim para o post ser enviado ao Feed de
informações é necessário clicar no botão post (localizado no canto inferior direito da
imagem abaixo).
64
Figura 29: Criação de post no feed do usuário.
6.10 FEED PROJECT
O Feed Project é uma interface onde aparecem os eventos que os usuários

planejaram como reuniões e encontros para compartilhar informações sobre detritos
espaciais, de modo a permitir a proliferação das informações de maneira dinâmica e
incentivar a interação entre organizações e pessoas, porém com enfoque a utilização
de corporações.
65
Figura 30: FEED projects.
6.11 CREATE PROJECT
O Create Project se encontra na região superior da página FEED projects, o

create Project tem função da criação e divulgação de um evento relativo aos detritos
espaciais, em suma, essa área de destinada ao uso de corporações, sendo possível
colocar o tipo de evento a data, e-mail e a descrição do projeto a ser criado.
66
Figura 31: imagem Create Project.
6.12 COMPANIES
A área de “Companies” permite cadastrar e apresentar instituições que utilizam

a plataforma com seu nome e sua descrição.
Figura 32: Página de companhias cadastradas na plataforma.

67
6.13 USERS
A página de users é onde aparecem todos os usuários que um determinado

usuário tem adicionado em suas conexões na rede. Nessa área é possível clicar no
símbolo ao lado do nome do usuário para abrir o chat e iniciar uma conversa sobre
detrito espacial com o outro usuário.
Figura 33: Página de usuários.
6.14 MENSAGES
A página mensages é onde se encontra o chat que permite a interação através

da conversa entre dois usuários, utilizando a comunicação entre máquinas é possível
conversar com outro usuário que você tenha adicionado em suas conexões. Nesse
chat é possível enviar mensagens de texto, documentos e imagens.
Figura 34: Chat de mensagem e interação entre usuários.

68
6.15 CHAT SEND IMAGE
Chat Send Image é a função obtida após interagir com o botão ao lado do
enviar, após clicar no botão a interface de imagens contidas no computador do usuário
é aberta, permitindo-o escolher a imagem que deseja enviar ao outro usuário em sua
conversação sobre detritos espaciais.
Figura 34: Interface para envio de imagens durante conversação entre usuários.

69
7 RESULTADOS
Os resultados obtidos durante o desenvolvimento e estudo do trabalho foram

satisfatórios, por meio das problemáticas apresentadas, foram analisadas alternativas
para a remoção e diminuição dos detritos espaciais, possíveis maneiras de reduzir os
danos da poluição que são deixamos pelos mesmos e conscientizar a sociedade
sobre esse problema, que podem causar grandes riscos futuros.
Através do desenvolvimento de uma rede social, cujo objetivo é reunir

informações sobre o assunto, os usuários podem se cadastrar como empresas, que
disponibilizam informações sobre o tema através de artigos, matérias e até mesmo
através de entretenimento, ou apenas como usuário comum, onde o mesmo tem
apenas interesse em obter informações sobre detritos espaciais e também ter
oportunidade de debater com outros usuários, expor suas opiniões e até mesmo
tirarem suas dúvidas, através dos comentários.
Utilizando das ferramentas: Spring Tools, Visual Studio Code e MySql para
desenvolvermos as IDE’s e dar funcionalidade a nossa rede social. A API integrada
com o front end, deu vida a nossa interface gráfica e utilizamos do OAuth2 para
autenticarmos e dar autorização aos usuários que visitam a plataforma e realizam o
seu cadastro em nossa rede.
Com um maior aprofundamento no tema através dos pontos que evidenciamos,

encontramos maneiras eficientes de transmitir e compartilhar informações sobre a
queda dos detritos espaciais e suas possíveis voltas a atmosfera terrestre e dessa
maneira ter um controle maior sobre o número de usuários que estão tendo acesso a
esses conteúdos e informações.
Afinal, quanto maior o número de pessoas com acesso a esse conteúdo, maior
será o nível de comoção com os detritos que rondam o espaço e prejudicam nosso
planeta diretamente. Trazendo assim maiores responsabilidade das autoridades para
que mais atitudes sejam tomadas, em relação a esse tema apresentado no decorrer
do trabalho.
70
8 CONCLUSÃO
No início do projeto apresentando, partimos do princípio de que os detritos

espaciais poderiam causar grandes impactos ao meio ambiente, por falta de
informações e identificações dos mesmos. Essa problemática atualmente, precisa ser
abordada e debatida no meio científico e social, pois a falta de informações e de ações
contra esses resíduos que circulam a nossa atmosfera, pode acarretar consequências
maiores, em um futuro não tão distante, tendo em virtude as centenas de aeronaves
com satélites que são lançados ao espaço em um pequeno intervalo de tempo.
Baseando-se nesses fatos, o trabalho realizado, abordou os problemas que

ocorrem e podem ocorrer em escala maior, caso atitudes não sejam tomadas,
principalmente se tratando dos países que são potencias no mundo atual. As
informações que no mundo atual tem um poder de alcance global muito rápido, sobre
esse assunto, junto das documentações sobre os detritos que adentram a atmosfera
terrestres, devem ser levadas com maior importância, para decisões futuras que terão
de ser tomadas com os impactos que serão causados por esses objetos.
O planeta Terra e a sociedade como um todo, pode sofrer com descaso que
são tratados os detritos espaciais, muito em função também do descaso das grandes
empresas e nações emissoras desses satélites, que não fornecem a sociedade
informações sobre o assunto.
Apesar de apenas um ser humano no mundo ter sido atingido por um fragmento
que decorreu da explosão de um foguete, o risco de que outra pessoa seja atingida
existe, embora seja muito difícil. Afinal quando perdem velocidade e caem em direção
da superfície da Terra, grande parte dos resíduos é destruída na atmosfera por conta
do atrito, pressão e altas temperaturas. Porém caso consigam passar por essa
camada protetora, as chances de caírem na água são muito grandes, visto que o
planeta Terra é setenta e cinco porcento coberto pelos oceanos.
O surgimento de novas tecnologias ainda são problemas, que precisam de

novas soluções, para continuar em andamento, pois trata-se de pesquisas que
precisam de altos investimentos e muita transparência dos meios envolvidos quanto
ao projeto, para serem aperfeiçoadas. Pois a maioria das instituições que
desenvolvem esses estudos, nem sempre conseguem fundos permanentes de auxílio,
71
pois os órgãos privados ou não, que podem apoiar, justificam que tecnologias dessa
magnitude possuem grandes gastos financeiros.
Contudo, neste trabalho, deixamos em vista que o assunto a respeito dos

resíduos espaciais, deve ser mais abordado não apenas no meio acadêmico ou que
fique restrita a agências internacionais espaciais, afinal trata-se de um problema que
exige a conscientização de todos, pois afeta a todos os seres humanos, desde a
queda de objetos na Terra, o que pode ocasionar poluição ou acidentes até à
inviabilização de missões no espaço futuras que acarretaria um regresso no estudo
do universo.
72
9 TRABALHOS FUTUROS
Os detritos espaciais, assim como qualquer outro tipo de resíduo pode conter
substâncias perigosas, até mesmo radioativas. Podemos levar em consideração como
futuro projeto e solução desse tema, o estudo de possíveis impactos e o cálculo dos
riscos, que podem vim a ocorrer com relação as missões espaciais que serão
realizadas futuramente, sejam elas tripuladas por astronautas ou não.
Conforme mostrado ao longo do projeto apresentado, ficou claro que o número

de detritos espaciais, aumentou gradativamente desde o lançamento do primeiro
satélite e já houve também muitas colisões e quedas desses resíduos registrados no
mundo. Apesar de houver milhares de problemas que já acontecem e já estão ou vão
se agravar e os que podem vir a acontecer, acreditamos que esse será, um dos
maiores.
Se medidas severas não forem colocas em práticas em relação a esses

resíduos que cercam o planeta Terra e outros planetas do sistema solar, missões
futuras podem se tornar inviáveis por diversos riscos. Colisões devastadoras podem
vim a ocorrer, além do contato com substâncias perigosas, como já citado. Apesar de
ocorrer acordos e legislações entre as grandes nações, referentes ao assunto, é
importante a conscientização da população e principalmente das grandes lançadoras
de objetos espaciais, afinal nos tempos atuais os estudos espaciais tem crescido cada
vez mais no mundo todo.
73
REFERÊNCIAS
HTIJ. Exemplo de criptografia de criptografia Java AES 256. Disponível em:

https://howtodoinjava.com/java/java-security/aes-256-encryption-decryption.
Acessado em 08 de maio de 2021.
SOMMERVILLE, Ian. Engenharia de Software. 9.ED. Local: São Paulo, 2011.
PRESSMAN, Roger. Engenharia de Software: Uma abordagem

profissional. 7.ED. Local: Porto Alegre, 2011.
NOGUEIRA, Marcelo. Engenharia de Software: Um Framework para a

Gestão de Riscos em Projetos de Software, Ed. Ciência Moderna, 2009.
LÉGALES. Detritos espaciais. Disponível em:

http://www.astronoo.com/pt/artigos/detritos-espaciais.html. Acessado em 21 de abril
de 2021.
SOUSA, PINTO. Os Dias da História - Lançamento do Sputnik, o 1º satélite

artificial. Disponível em: https://ensina.rtp.pt/artigo/lancamento-do-sputnik- o-1o-
satelite-artificial. Acessado 21 de abril de 2021.
Universidade Estadual Paulista. Requisitos de software, 2005. São Paulo,

2021.
MELICIO, ANDRÉ. Banco de dados relacional. Disponível em:

https://livingtech.com.br/2020/07/01/banco-de-dados-relacional. Acessado em: 22 de
abril de 2021.
MORAES, LETICIA. Modelagem da reentrada de resíduos espaciais e

avaliação dos impactos ao meio ambiente. 2019. 53f. (Graduação em engenharia)
– Universidade Estadual Paulista. São José dos Campos, 2019.
RODOTÁ, ANTONIO. O que é a ESA. Disponível em:

http://www.esa.int/Space_in_Member_States/Portugal/O_que_e_a_ESA. Acessado
em: 22 de abril de 2021.
FOGUETE, BRITANNICA. Como funcionam os foguetes. Disponível em:

<https://escola.britannica.com.br/artigo/foguete/482384>. Acessado em: 26 de abril
74
de 2021.
TELESINTESE. Setor de satélites crescem 3% no mundo em 2017.

Disponível em: https://www.telesintese.com.br/setor-de-telecomunicacoes-por-
satelite-cresceu-3-no-mundo-em-2017. Acesso: 26 de abril de 2021.
NASCIMENTO, JULIANA. Resíduos espaciais: impactos às missões no

espaço e poluição do meio ambiente. 2019. 65f. (Engenharia ambiental). Disponível
em:
<http://bdta.ufra.edu.br/jspui/bitstream/123456789/1440/1/Res%C3%ADduos%20esp
aciais%20impactos%20%C3%A0s%20miss%C3%B5es%20no%20espa%C3%A7o%
2 0e%20polui%C3%A7%C3%A3o%20do%20meio%20ambiente.pdf>. Acesso em: 27
de abril de 2021.
AMORIM, BRUNO. Sondas Espaciais. Disponível em:

http://www.invivo.fiocruz.br/cgi/cgilua.exe/sys/start.htm?infoid=1155&sid=9. Acesso
em: 30 de abril de 2021.
PIXABAY. Detritos de foguete chinês atingem vilarejos da costa do

marfim. Disponível em: https://aventurasnahistoria.uol.com.br/noticias/historia-
hoje/detritos-de-foguete-chines-atingem-vilarejos-da-costa-do-marfim.phtml.
Acessado em: 28 de abril de 2021.
OPENCADD. Engenharia de requisitos no desenvolvimento de software.

Disponível em: https://opencadd.com.br/engenharia-de-requisitos-no-
desenvolvimento-de-software. Acessado em: 28 de abril de 2021.
IRONHACK. O que é UX Design e sua aplicação. Disponível em:

https://www.ironhack.com/br/desenho-ux-ui/afinal-o-que-e-ux-design-a-evolucao-do-
web-design. Acessado em: 04 de agosto de 2022
MISSOURI. Eye-tracking studies: first impressions form quickly on the

web. Disponível em: https://news.mst.edu/2012/02/eye-tracking_studies_show_firs/.
Acessado em: 04 de agosto de 2022.

TCC 8o SEMESTRE DOCUMENTACAO DE DETRITOS ESPACIAIS PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCC 8o SEMESTRE DOCUMENTACAO DE DETRITOS ESPACIAIS PDF

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE PAULISTA – UNIP

ENRICO RICCATO PRATTI PEREIRA

TRABALHO DE CONCLUSÃO DE CURSO

SOFTWARE PARA DOCUMENTAÇÃO E CONVERSAÇÃO SOBRE

Trabalho de conclusão de curso para

Orientador: Profº. MSC. Marco Gomes

SOFTWARE PARA DOCUMENTAÇÃO E CONVERSAÇÃO SOBRE

Trabalho de conclusão de curso para

Apesar de haver inúmeros acordos internacionais sobre esse tema e já existir

Palavras Chave: Detritos espaciais – Impactos – Espaço – Software

Keywords: Space debris – Impacts – Space – Software

1.1 CONTEXTUALIZAÇÃO ............................................................................... 10

1.2 PROBLEMA DE PESQUISA ........................................................................ 11

1.3 MOTIVAÇÃO ................................................................................................ 12

1.4 JUSTIFICATIVA ........................................................................................... 13

1.5 OBJETIVOS ................................................................................................. 14

1.5.1 Objetivo Geral ............................................................................................... 14

1.5.2 Objetivo Específico ....................................................................................... 14

1.6 METODOLOGIA (S) DE PESQUISA ........................................................... 15

1.7 ESTRUTURA DO TRABALHO .................................................................... 15

2 REFERENCIAL TEÓRICO ........................................................................... 17

2.1 LIXO ESPACIAL .......................................................................................... 17

2.1.2 Sonda Especial ............................................................................................. 19

2.1.3 Satélite Artificial ............................................................................................ 20

2.2 DIREITO AMBIENTAL ESPACIAL .............................................................. 22

2.2.1 Colisão Terrestre .......................................................................................... 22

2.3 REDE DE COMPUTADORES ...................................................................... 23

2.3.1 Modelo TCI/IP ............................................................................................... 24

2.4 BANCO DE DADOS RELACIONAL ............................................................ 26

2.4.1 Modelo Relacional ........................................................................................ 26

2.5 NÍVEIS DE ACESSO .................................................................................... 27

2.6 ENGENHARIA DE SOFTWARE .................................................................. 28

2.7 RUP .............................................................................................................. 29

2.8 ENGENHARIA DE REQUISITOS................................................................. 29

3 MATERIAIS E MÉTODOS ........................................................................... 32

3.2 MATERIAIS .................................................................................................. 35

3.2.1 Visual Studio Code ....................................................................................... 35

3.2.2 WAMP .......................................................................................................... 36

3.2.3 Eclipse .......................................................................................................... 37

3.2.4 Postman ....................................................................................................... 38

3.3 BASE DE DADOS ........................................................................................ 39

3.4 BANCO DE DADOS RELACIONAL ............................................................ 40

3.5 CHAT DE CONVERSAÇÃO ........................................................................ 41

3.6 SERVIDOR E HOSPEDAGEM ..................................................................... 42

3.7 NIVEIS DE ACESSO .................................................................................... 43

3.8 SEGURANÇA DO SOFTWARE ................................................................... 44

4.1 ANÁLISE DE REQUISITOS ......................................................................... 46

4.1.1 Requisitos Funcionais................................................................................... 46

4.1.2 Requisitos Não Funcionais ........................................................................... 47

4.2 UNIFIED MODELING LANGUAGE (UML) .................................................. 47

4.3 DIAGRAMAS ............................................................................................... 48

4.3.1 Diagrama de Caso de Uso ........................................................................... 48

4.3.2 Diagrama de Classes ................................................................................... 50

4.3.2.1 Project ........................................................................................................... 51

4.3.2.2 User ............................................................................................................... 51

4.3.2.3 Message ........................................................................................................ 51

4.3.2.4 Feed .............................................................................................................. 51

4.3.2.5 Register ......................................................................................................... 51

4.3.2.7 ForgetPassword ............................................................................................ 51

4.3.3 Diagrama de Banco de Dados (MER) .......................................................... 52

5 ABORDAGEM UX E UI DESIGNER ............................................................ 54

5.1 UX DESIGN .................................................................................................. 54

5.2 UI DESIGN ................................................................................................... 55