1. O documento descreve uma proposta de sistema de gestão integrada municipal que visa integrar e modernizar os serviços prestados pela prefeitura municipal de forma a permitir um acesso centralizado às informações e uma gestão mais eficiente. 2. O sistema será desenvolvido por módulos e implantado de forma gradativa nos órgãos municipais, utilizando microsserviços hospedados em nuvem híbrida. 3. Os principais módulos propostos são: informações municipais georreferenciadas, serviço ao cidadão, gest

1. PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS GERAIS
NÚCLEO DE EDUCAÇÃO A DISTÂNCIA
Pós-Graduação Lato Sensu em Arquitetura de Software Distribuído
André Graciano de Sousa
Jonathan Pereira Cabral
SISTEMA DE GESTÃO INTEGRADA MUNICIPAL
Belo Horizonte
2021

2. André Graciano de Sousa
Jonathan Pereira Cabral
SISTEMA DE GESTÃO INTEGRADA MUNICIPAL
Trabalho de Conclusão de Curso de
Especialização em Arquitetura de Software
Distribuído como requisito parcial à obtenção do
título de especialista.
Orientador(a):
Belo Horizonte
2021

3. RESUMO
Esse projeto aborda uma solução de aprimoramento e modernização dos serviços
providos e utilizados pela prefeitura, por meio de dispositivos móveis ou via web/desktop,
permitindo uma gestão mais eficiente, integração com sistemas e acesso a dados de forma
centralizada. Atualmente o acesso às informações se encontram em ambientes separados, em
sistemas legados não integrados, como sistema de gestão financeira, tributação, marcação de
atendimento, dados de saúde, ambiente entre outras operações. Para solucionar este problema,
o projeto visa desenvolver um sistema onde possibilite um acesso a todos os sistemas utilizados
pela prefeitura e cidadão, de forma centralizada, de fácil uso e acesso, alto nível de segurança,
baixa manutenção e baixo custo.
Palavras-chave: arquitetura de software, transparência, integração, web, dispositivos
móveis, prefeitura, sistema legado.

4. SUMÁRIO
1. OBJETIVOS DO TRABALHO ..........................................................................6
1.1. OBJETIVOS ESPECÍFICOS .........................................................................6
2. DESCRIÇÃO GERAL DA SOLUÇÃO .............................................................7
2.1. APRESENTAÇÃO DO PROBLEMA ...........................................................7
2.2. DESCRIÇÃO GERAL DO SOFTWARE (ESCOPO)....................................7
3. DEFINIÇÃO CONCEITUAL DA SOLUÇÃO..................................................8
3.1. REQUISITOS FUNCIONAIS........................................................................8
3.1.1. MÓDULO DE INFORMAÇÕES MUNICIPAIS GEORREFERENCIADAS
8
3.1.2. MÓDULO DE SERVIÇO AO CIDADÃO...................................................8
3.1.3. MÓDULO DE GESTÃO ESTRATÉGICA DE PROJETOS......................10
3.1.4. MÓDULO DE AUTENTICAÇÃO ............................................................10
3.1.5. MÓDULO DE BUSINESS INTELLIGENCE (BI)....................................10
3.1.6. MÓDULO DE INTEGRAÇÃO GERAL....................................................10
3.2. REQUISITOS NÃO-FUNCIONAIS............................................................11
3.2.1. Usabilidade...............................................................................................11
3.2.2. Acessibilidade...........................................................................................12
3.2.3. Desempenho .............................................................................................12
3.2.4. Disponibilidade ........................................................................................13
3.2.5. Manutenibilidade......................................................................................13
3.2.6. Testabilidade ............................................................................................13
3.2.7. Interoperabilidade....................................................................................14
3.2.8. Segurança.................................................................................................14
3.3. RESTRIÇÕES ARQUITETURAIS .............................................................14
3.4. MECA/NISMOS ARQUITETURAIS..........................................................15
4. MODELAGEM E PROJETO ARQUITETURAL .........................................17
4.1. MODELO DE COMPONENTES.................................................................17
4.2. MODELO DE IMPLANTAÇÃO.................................................................18
5. PROVA DE CONCEITO (POC) / PROTÓTIPO ARQUITETURAL..........20
5.1. IMPLEMENTAÇÃO E IMPLANTAÇÃO ..................................................20

5. 5.1.1. TECNOLOGIAS UTILIZADAS.................................................................20
5.1.2. HISTÓRIAS DE USUÁRIOS ....................................................................20
5.1.3. USABILIDADE.........................................................................................24
5.1.4. ACESSIBILIDADE ...................................................................................25
5.1.5. DESEMPENHO........................................................................................26
5.1.6. SEGURANÇA ...........................................................................................27
5.2. INTERFACES/ APIS ...................................................................................27
5.2.1. EUREKA...................................................................................................27
5.2.2. SESSÃO 1: MÉTODOS DO API AUTH...................................................28
5.2.3. SESSÃO 2:MÉTODOS DO CIDADÃO....................................................30
6. AVALIAÇÃO DA ARQUITETURA................................................................34
6.1. ANÁLISE DAS ABORDAGENS ARQUITETURAIS ...............................34
6.2. CENÁRIOS ..................................................................................................35
6.3. PRIORIZAÇÃO ...........................................................................................36
6.4. AVALIAÇÃO ..............................................................................................36
6.5. RESULTADO ..............................................................................................45
7. CONCLUSÃO.....................................................................................................46
REFERÊNCIAS............................................ERRO! INDICADOR NÃO DEFINIDO.
APÊNDICES ...............................................................................................................48
CHECKLIST PARA VALIDAÇÃO DOS ITENS E ARTEFATOS DO
TRABALHO ...........................................................................................................................49

6. 6
1. OBJETIVOS DO TRABALHO
O objetivo deste projeto é apresentar uma proposta de arquitetura para informatizar e
integrar todas as secretarias do município, visando agilizar o atendimento ao cidadão e a
tramitação de processos utilizando de tecnologias e geotecnologias que atendam as prioridades
do governo nas áreas de educação, saúde, meio ambiente e agropecuária. O projeto visa atender
e facilitar o controle de processos, atendimentos ao cidadão, possibilitando integração aos
sistemas utilizados pela prefeitura, de forma segura, baixo custo e com acesso em qualquer
lugar via web e dispositivos móveis. O projeto deve ser implantado em todos os órgãos
municipais, implantados por módulos baseado em microsserviços e hospedados em nuvem
híbrida.
1.1. OBJETIVOS ESPECÍFICOS
a) Criar um módulo de informações municipais georreferenciadas, responsável por
obter dados via imagens por satélite e informações disponibilizadas por órgãos
como Instituto Brasileiro de Geografia e Estatística (IBGE). Os dados
geográficos devem ser mantidos e disponibilizados, para serem utilizados por
uma Infraestrutura de Dados Espaciais (IDE) seguindo normas e diretrizes
preconizadas pelo IBGE.
b) Criar um módulo serviço ao cidadão que possibilite aos municípios consultar
informações de interesse ao cidadão como: consulta ao Imposto Predial e
Territorial Urbano (IPTU), Imposto Territorial Rural (ITR), assim como a
integração com o Sistema de Tributação Territorial Urbana e Rural (STUR).
c) Proporcionar aos municípios uma ferramenta para gestão de projetos que
possibilite a criação de uma carteira de projetos de todos os municípios para uma
gestão estratégica, com indicadores de andamento individual e global.
d) Criar um módulo de Business Intelligence que permita a mineração de dados
socioeconômicos e de gestão, armazenados em diferentes bases de dados e em
diferentes SGBDs. O uso de Data Warehouse é essencial.
e) Criar um módulo de integração geral, responsável por todo o processo de
integração entre as aplicações existentes. Esse módulo deverá fazer uso de
tecnologias como: Protocolos HTTP, TCP/IP, Rest, SOAP, baseando-se sempre
em tecnologias disponibilizadas pela Red Hat e Apache.

7. 7
2. DESCRIÇÃO GERAL DA SOLUÇÃO
O sistema apresenta uma integração de informações de vários outros serviços, buscando
centralizar as informações em um único local para agilizar o acesso do munícipe e do gestor
que terá mais informações sobre o município, facilitando e embasando a sua tomada de decisão
referente a políticas de desenvolvimento dentro do município.
2.1. APRESENTAÇÃO DO PROBLEMA
Atualmente o acesso a informações prestadas pelas prefeituras municipais se dá em sua
maioria, através de protocolos presenciais e burocráticos. Não há uma integração ágil entre os
municípios e por isso o acesso à informação pode levar dias. Processos são em grande parte
documentados em dossiês físicos e dependem de um sistema humano de organização, assim
como da confiança de que todos estão alinhados com suas diretrizes e protocolos, o que tem se
provado falho e de difícil gerenciamento.
Processos como requerimento de verificação da viabilidade de uso do espaço desejado,
aprovações de projetos habitacionais, transferências de propriedades, solicitações de escrituras,
solicitações de registro de imóveis e emissões de alvarás são protocolos iniciados e
movimentados unicamente por meio de visitas à prefeituras, o que demanda tempo e energia
não só do solicitante como dos prestadores de serviços tornando assim, o processo lento, onde
o tempo de atendimento é de pelo menos 30 minutos e não há divulgação prévia de quais
documentos são necessários para cada caso, sendo necessário que clientes enfrentem filas
apenas para conseguir tal informação.
Além disso a prefeitura encontra dificuldade em manter atualizadas informações de seus
projetos, pois seu sistema de monitoramento depende do deslocamento de técnicos para
averiguar os locais onde existem projetos ativos e por isso existe um desfasamento nas
informações dos projetos devido ao intervalo entre vistorias não sendo assim, possível
acompanhar todas as fases dos projetos cadastrados.
2.2. DESCRIÇÃO GERAL DO SOFTWARE (ESCOPO)
A integração tem como objetivo realizar a centralização de informações
disponibilizadas por vários órgãos e proporcionar ao munícipe a facilidade de pegar
informações educacionais, notícias, documentos do SUS e consulta de impostos. além de
possibilitar à prefeitura uma visão mais ampla do que ocorre no município com as informações
vindas do IBGE e de outros serviços externos (SAEM, SASCi, SAFIM e STUR).

8. 8
3. DEFINIÇÃO CONCEITUAL DA SOLUÇÃO
3.1. REQUISITOS FUNCIONAIS
3.1.1. MÓDULO DE INFORMAÇÕES MUNICIPAIS GEORREFERENCIADAS
a) Buscar Dados IBGE
Deve buscar informações referentes ao município, para melhor realizar o
controle da expansão territorial, devendo disponibilizar uma tela onde é possível obter
os dados de expansão e os locais exatos dentro do município onde essa alteração está
sendo realizada, dando assim a capacidade para que a prefeitura consiga agir de forma
rápida caso necessite realizar alguma intervenção.
b) Armazenar Dados IBGE
Deverá manter os dados consultados salvos em tabelas para realizar análise sem
ter que ficar realizando diversas consultas à API. Evitando que toda vez que precise de
alguma informação essa API externa tenha que ser consultada, um processo deve ser
executado toda segunda feira e quarta feira sempre após o horário comercial realizando
as consultas a atualizando a base local com as informações.
Além das consultas que verificam a expansão que ocorre, serão também
consultados dados socioeconômicos, facilitando a ação da prefeitura em locais mais
carentes do município buscando implementar políticas sociais.
Também consultas em dados referentes à criminalidade, para que seja possível,
adicionar efetivo policial em pontos mais críticos, tanto a parte de dados
socioeconômicos quanto a parte de segurança pública devem conter telas que
apresentem um compilado dessas informações e seus locais no mapa do município.
Deve ser disponibilizada uma tela para que seja possível o acionamento desse
processo de atualização a qualquer momento, lembrando que o funcionário deverá estar
devidamente logado para realizar essa ação, no caso de acionamento manual, deverá
ficar armazenado os dados do usuário que realizou o acionamento, data e uma
justificativa.
3.1.2. MÓDULO DE SERVIÇO AO CIDADÃO
a) Consultar Imposto

9. 9
O sistema deve permitir que por meio do número de inscrição do terreno possam
ser retirados os impostos de Imposto predial, IPTU e ITR, e devem ser retornados os
seguintes dados: inscrição, tipo (IPTU ou ITR), valor do imposto, ano, tamanho em
metros quadrados, cidade, estado e o CEP referente ao imóvel.
b) Manter Serviços
Será apresentado aos usuários dos sistemas os fluxos dos principais processos
realizados pelo executivo municipal, mostrando o catálogo de serviços realizado pelos
órgãos municipais.
Os funcionários da prefeitura com permissão para esse cadastro poderão
atualizar o andamento, já os munícipes poderão apenas solicitar os serviços e
acompanhar o andamento do atendimento.
c) Consultar Os Dados do Prontuário
• Essa funcionalidade só pode ser utilizada pelo munícipe logado na aplicação e a
partir de informações pessoais.
• Consultar os dados de exames cadastrados no SUS, informando alguns dados como
CPF, data nascimento e nome da mãe.
• Consultar os dados de consultas realizadas pelo SUS, informando alguns dados
como CPF, data nascimento e nome da mãe.
• As consultas acima devem passar pelo módulo core, que fará toda a integração com
sistemas externos.
• Será disponibilizado ao munícipe realizar a geração de relatórios referentes a
consultas, exames e atendimentos. Esses relatórios devem conter todas as
informações retornadas pelo serviço externo.
d) Manter Notícias
Os funcionários da prefeitura podem realizar o cadastro de notícias que irão
aparecer para os usuários, cada notícia deve conter título e o conteúdo, informada pelo
usuário que está realizando a postagem, os dados de data e autor devem ser armazenados
também.
O usuário ao realizar o seu login, será redirecionado para a tela de notícias onde
serão apresentadas todas as notícias, com a postagem mais recente, será apresentado o
título, data da postagem e conteúdo.

10. 10
3.1.3. MÓDULO DE GESTÃO ESTRATÉGICA DE PROJETOS
a) Consultar Redmine
Os dados de andamentos de projetos cadastrados no redmine poderão ser
consultados pelos usuários da prefeitura que estejam logados.
Devem ser apresentadas as informações de título do projeto, prazo, percentual
de conclusão, data de início, integrantes do projeto com suas devidas funções, também
deve estar disponível as informações compiladas como quantidade de projetos, podendo
agrupar por situação, data de início e fim, prazo, percentual de andamento e por
integrantes.
3.1.4. MÓDULO DE AUTENTICAÇÃO
a) Manter Usuário
O munícipe pode realizar o seu cadastro, ao acessar o sistema a página inicial
será a página de autenticação e na parte inferior apresenta a opção de cadastre-se, ele
deve informar todos os dados solicitados, nome, username (nome que deverá usar para
realizar o login), e-mail, cpf, telefone, password. Ao realizar o cadastro com sucesso ele
será direcionado a tela de login para que possa acessar a plataforma e consultar os
serviços que desejar. O usuário com perfil de administrador poderá alterar o perfil do
usuário.
3.1.5. MÓDULO DE BUSINESS INTELLIGENCE (BI)
a) Minerar Dados Socioeconômicos e Gestão
O sistema realizará consulta em dados já cadastrados em diferentes SGBDs para
realizar uma análise das informações, essas análises serão salvas no banco de dados para
posterior consultas.
b) Consulta para o dashboard das Análises.
O sistema deve ser capaz de apresentar informações de forma clara em relatórios
contendo gráficos utilizando como fonte os dados anteriormente minerados e
armazenados no banco de dados.
3.1.6. MÓDULO DE INTEGRAÇÃO GERAL
Módulo responsável por fazer a intermediação entre os sistemas externos e os serviços
internos, fazendo assim com que todo acesso externo tenha que passar por ele.

11. 11
a) Consultar Impostos no STUR
Solicita os dados de imposto ao que faz a consulta na Secretaria municipal da
fazenda.
b) Consultar Dados do SAFIM
Consultando os dados financeiros e administrativos dos funcionários, essas
informações devem conter apenas dados básicos, incluindo o salário.
Também poderá ser realizada uma consulta que trará dados compilados sobre
esses dados trazendo uma visão sobre gastos por setores, esses dados só podem ser
realizados por usuário autorizados.
c) Consultar Dados do SASCI
Essa funcionalidade só pode ser utilizada pelo munícipe logado na aplicação e a
partir de informações pessoais. Possibilita:
• Consultar os dados de exames cadastrados no SUS, informando alguns dados
como CPF, data nascimento e nome da mãe.
• Consultar os dados de consultas realizadas pelo SUS, informando alguns dados
como CPF, data nascimento e nome da mãe.
As consultas acima devem passar pelo módulo core, que fará toda a integração
com sistemas externos.
Será disponibilizado ao munícipe relatórios referentes a consultas, exames e
atendimentos. Esses relatórios devem conter todas as informações retornadas pelo
serviço externo.
d) Consultar Dados do Saem
Possibilita ao munícipe, quando em área logada do sistema, realizar consulta de
informações do histórico escolar. Já o funcionário terá uma visão mais abrangente, como
informações sobre escolas, quantidade de alunos, índices de aprovação, quantidade de
docentes, total de gastos da escola.
3.2. REQUISITOS NÃO-FUNCIONAIS
Descrição dos requisitos não funcionais seguindo a forma de estímulo resposta.
3.2.1. Usabilidade
O sistema deve ser simples e fácil de usar.

12. 12
Estímulo Consultando o IPTU/ ITR
Fonte de
Estímulo
Munícipe acessando a funcionalidade de consulta do IPTU/ ITR
Ambiente Funcionamento normal
Artefato Módulo de Serviço ao Cidadão
Resposta Sistema apresenta os dados referente ao IPTU
Medida da
resposta
O sistema apresenta apenas dois campos tipo do imposto e o número inscrição, deixando a
consulta simples e fácil de ser utilizada
3.2.2. Acessibilidade
O sistema deve ser acessível por dispositivos web em diferentes resoluções.
Estímulo Consultando o IPTU/ ITR
Fonte de
Estímulo
Munícipe acessando a funcionalidade de consulta do IPTU/ ITR
Ambiente Funcionamento normal
Artefato Módulo de Serviço ao Cidadão
Resposta A interface se ajusta de acordo com as dimensões da tela, ajustando caso necessário a
ordem dos componentes e recolhimento do menu.
Medida da
resposta
O tamanho da tela não permitiu que a alterações de tamanho interferisse na qualidade de
visualização do usuário
3.2.3. Desempenho
O sistema deve ser rápido.
Estímulo Tela de Login
Fonte de Estímulo Munícipe realizando login
Ambiente Funcionamento normal
Artefato Módulo de Serviço ao Cidadão
Resposta Munícipe realiza o login e vai para sua página principal
Medida da resposta O usuário conseguiu colocar suas credenciais e logou em menos de 10 segundos.

13. 13
3.2.4. Disponibilidade
O sistema deve estar disponível quando a alteração não impacta a aplicação como um
todo.
Estímulo Um erro identificado no micro serviço de manter serviço.
Fonte de
Estímulo
Munícipe tendo problema ao acessar serviços
Ambiente Sistema apresentando um erro grave nos dados dos serviços
Artefato Módulo de Serviço ao Cidadão
Resposta A equipe de desenvolvimento gera uma versão corretiva
Medida da
resposta
A versão corretiva é implantada, mas durante essa implantação todos os outros serviços
continuam disponíveis, menos o de manter serviço
3.2.5. Manutenibilidade
Deve ser fácil a identificação de possíveis erros no sistema
Estímulo Um erro identificado ao consultar um serviço
Fonte de Estímulo Munícipe tendo problema ao consultar serviço
Ambiente Sistema apresentando um erro grave na consulta de serviço
Artefato Módulo de Serviço ao Cidadão
Resposta A equipe que irá realizar a correção solicita os logs da aplicação.
Medida da resposta Com os logs detalhados a equipe consegue identificar de forma rápida o problema.
3.2.6. Testabilidade
O sistema deve possuir teste unitário e automatizado, para evitar que possíveis correções
gerem algum problema.
Estímulo Execução de teste no sistema
Fonte de Estímulo Desenvolvedor/Analista/Arquiteto
Ambiente Ambiente de desenvolvimento/Homologação

14. 14
Artefato Módulo de Serviço ao Cidadão
Resposta O sistema realiza os testes da consulta de IPTU e ITR.
Medida da resposta A partir de um comando o sistema deve realizar os testes
3.2.7. Interoperabilidade
O sistema tem que se comunicar com outros sistemas para realizar as ações necessárias
Estímulo Consultar exames
Fonte de
Estímulo
Munícipe consulta os exames
Ambiente Funcionamento normal
Artefato Módulo de Serviço ao Cidadão
Resposta O munícipe tem acesso aos seus exames
Medida da
resposta
O front-end realizou uma solicitação para o módulo de microsserviços (prontuário), que a
partir do módulo core acessou o SASCi.
3.2.8. Segurança
O sistema não deve permitir que pessoas não autorizadas realizem ações no sistema.
Estímulo Acesso a página de consultar prontuário
Fonte de
Estímulo
Qualquer pessoa sem está logada na aplicação
Ambiente Funcionamento normal
Artefato Módulo de Serviço ao Cidadão
Resposta O usuário é direcionado para página de login
Medida da
resposta
Ao tentar acessar uma página utilizando o link o sistema automaticamente redireciona a
pessoa para página de login já que esse acesso é restrito.
3.3. RESTRIÇÕES ARQUITETURAIS
a) O Sistema deve ser acessível por aparelhos menores como: tablets, celulares, monitores
pequenos;
b) O sistema deve ser modular para facilitar a implantação;

15. 15
c) Os módulos devem ser baseados na arquitetura de microsserviços;
d) O sistema deve ser hospedado em nuvem híbrida e on premise;
e) O sistema deve ser implantado em todos os órgãos municipais;
f) O sistema deve estar disponível em horário comercial 5 dias por semana (Seg-Sex);
g) O sistema deve ser resiliente a falha;
h) O sistema deve possuir bom desempenho;
i) O Sistema deve possuir recursos de integração contínua;
3.4. MECA/NISMOS ARQUITETURAIS
Mecanismo de Análise Mecanismo de Design Mecanismo de
Implementação
Linguagem Linguagem de programação Java 8
Persistência Banco de dados relacional MySQL
Persistência Banco para georreferenciamento PostGis
Persistência Framework ORM Hibernate
Comunicação com módulos e/ou
sistemas
Interface utilizando JSON Rest
Comunicação com módulos e/ou
sistemas
Interface Utilizando XML SOAP
Log Framework de Log Log4J
Containers Container Web e Aplicação Docker
Orquestrador Kubernetes AWS EC2
Orquestrador Kubernetes Kubernetes
Build Geração de artefato para servidor de
aplicação
Gradle
Versionamento Versionamento do código GIT
Autenticação e Autorização Verificação das credenciais JWT
Alta disponibilidade Balanceamento de carga ZUUL
Descoberta Registro de serviços EUREKA
Front-End Interface de comunicação com usuário
do sistema
ReactJS
Documentação API Documentação de API Swagger 2
Gateway API Gateway ZUUL

16. 16
Geolocalização Mapa geolocalização HERE
Repositório Docker AWS ECR Registros de container da
Amazon AWS
Deploy DevOps Jenkins
Testes Automatizados DevOps Jenkins

17. 17
4. MODELAGEM E PROJETO ARQUITETURAL
4.1. MODELO DE COMPONENTES
Componente Descrição
SGM Página WEB que irá realizar ao ponto de comunicação entre o usuário e os serviços
API Gateway É o ponto central do projeto, funcionando com um roteador entre os microsserviços. É
responsável por validar todas as requisições e redirecionar para os serviços corretos, apenas
requisições autenticadas.
Microservices São API 's de serviço separadas por contexto com um baixo acoplamento, com alta
testabilidade e manutenibilidade. Os módulos do SGM são: cidadão, gestão-projetos,
informacao-georeferenced, BI, auth)
Wrappers Wrappers possui a função de encapsular serviços externos em uma interface padronizada.
Onde os serviços expostos pelo wrapper devem seguir os padrões e práticas utilizadas pelos
serviços do SGM, retirando influências externas o máximo possível.
Data
Warehouse
Banco de dados obtidos para utilização de Big Data

18. 18
4.2. MODELO DE IMPLANTAÇÃO
O modelo de implantação visa exibir como um detalhamento dos componentes e
módulos envolvidos, bem como será a distribuição dos mesmos pelos nós e como será feita a
comunicação. Visando atender os requisitos não funcionais do sistema, com alta performance
e disponibilidade.
A implantação do sistema SGM foi desenvolvida pensando em uma arquitetura híbrida,
onde parte dos sistemas serão mantidos on premise e parte irá ficar nos servidores da Amazon
AWS. É importante lembrar que não está explícito no documento a arquitetura de componente
do orquestrador de contêineres, cluster do kubernetes (EC2).
Nessa arquitetura devemos considerar que haverá um sistema de cluster
balanceado, utilizando o elastic load balancing da AWS, proporcionando uma alta
disponibilidade. Visando uma garantir uma alta escalabilidade deixaremos o Kubernetes
responsável por toda a orquestração.
Cloud
Componente Descrição
EC2 - Elastic Compute Cloud Onde serão implantados os microservices do SGM utilizando container.
RDS MySql AWS Serviço de armazenamento de dados MySql provido pela Amazon AWS
On Premise
Kubernetes Servidor onde será instalado o orquestrador de containers
Servidor de aplicação Onde estão instaladas as aplicações legadas que o SGM deve se integrar
Data Warehouse Solução para Big Data

19. 19

20. 20
5. PROVA DE CONCEITO (POC) / PROTÓTIPO ARQUITETURAL
5.1. IMPLEMENTAÇÃO E IMPLANTAÇÃO
5.1.1. TECNOLOGIAS UTILIZADAS
Para a realização da prova de conceito foram utilizadas as tecnologias abaixo:
a) Microsserviços - Foi utilizado a tecnologia Java com o estilo arquitetural
RESTful
b) Banco de dados MySQL
c) Docker - Utilizando para conteinerização os microsserviços com todas as
dependências
d) Auth - Foi a API desenvolvida em JAVA utilizado para autenticação e
autorização dos microsserviços via Json Web Tokens (JWT)
e) Swagger - Foi utilizado para a documentação e exposição dos contratos dos
microsserviços
f) Front-end - Foi utilizado ReactJS para o desenvolvimento da página no padrão
SPA
5.1.2. HISTÓRIAS DE USUÁRIOS
Abaixo segue as histórias de usuários que apresentam alguns dos requisitos
funcionais que foram implementados:
a) Cadastro Usuário
ID 1
Estória de
usuário
Cadastro usuário
Criador Munícipe
Descrição Eu quero acessar o sistema da prefeitura, mas para visualizar as páginas do sistema deve-se
ter um login e senha registrados.
Valor do
negócio
Permitir que o usuário realize seu cadastro no sistema.
Prioridade ALTA

21. 21
Estimativa 30 horas
Tela em que o usuário pode realizar o seu cadastro para acessar a aplicação:
b) Acessar O Sistema - Login
ID 2
Estória de
usuário
Acessar o sistema - Login
Criador Munícipe/Funcionário
Descrição Eu preciso realizar alguma consulta no sistema, então vou utilizar meus dados de usuário de
senha cadastrados para acessar a aplicação, se eles estiverem corretos será aberta a tela
inicial.
Valor do
negócio
Permitir que o usuário tenha acesso às páginas do sistema.
Prioridade ALTA
Estimativa 30 horas
Tela de login, após realizar o seu cadastro ou tentar acessar a aplicação o usuário terá
que informar seus dados de acesso nesta tela, para que o sistema possa verificar se ele tem
permissão ou não de acessar o sistema.

22. 22
c) Consultar IPTU/ITR
ID 3
Estória de
usuário
Consultar IPTU/ITR
Criador Munícipe/Funcionário
Descrição Eu preciso consultar o meu IPTU, então realizar o login na aplicação, acessar a página de
consulta e selecionar o campo IPTU e informar o número da inscrição e clicar em consultar,
caso exista o registro, será exibido em uma tabela.
Valor do
negócio
Permitir que o usuário possa consultar seu IPTU/ITR
Prioridade ALTA
Estimativa 40 horas
Na tela de consultar imposto temos que informar o tipo (IPTU ou ITR) e o número de
inscrição do imóvel e o seu número de inscrição, onde o munícipe poderá consultar essas
informações.

23. 23
d) Cadastrar Notícia
ID 4
Estória de
usuário
Cadastrar notícia
Criador Funcionário
Descrição Eu preciso informar os munícipes sobre algum evento ou situação que esteja ocorrendo,
então acesso a tela de cadastrar notícia informando o título e um conteúdo e cadastro.
Valor do
negócio
Permite que o funcionário cadastre notícias
Prioridade MÉDIA
Estimativa 40 horas
A tela abaixo apresenta ao funcionário da prefeitura realizar o cadastro de uma notícia
que será apresentada a todos os usuários do sistema.

24. 24
5.1.3. USABILIDADE
a) O sistema deve ser simples e fácil de usar;
b) A tela deve apresentar facilidade de navegação, apenas apresentando os campos
necessários para o usuário atingir seu objetivo;
c) O munícipe não deve demorar mais do que 4 minutos para acessar o sistema e conseguir
consultar seu IPTU/ITR;
d) As informações apresentadas na tela devem ser claras e objetivas.
Segue abaixo o passo a passo que o usuário teria que realizar para consultar o seu
IPTU/ITR, ele apenas precisa realizar o seu login, clicar no menu consultar imposto, informar
o tipo e o número de inscrição e clicar em consultar.

25. 25
5.1.4. ACESSIBILIDADE
a) O sistema deve ser acessível por dispositivos web em diferentes resoluções;
b) A navegação deve ser simples e descomplicada;
c) A resolução da tela deve ser adaptar de acordo com o dispositivo que estiver utilizando
o sistema;
d) Deve ser compatível com os principais navegadores (browsers) da web, como o Google
Chrome e o Mozilla Firefox.
Abaixo segue a imagem da tela, sendo apresentada em um formato de 356 X 557, e
mostra que os componentes se ajustam de acordo com a tela do dispositivo que estiver sendo
utilizado.

26. 26
5.1.5. DESEMPENHO
a) O sistema deve ser rápido;
b) As consultas internas realizadas no sistema não devem demorar mais do que 4 segundos;
c) As consultas externas (integradas com outros sistemas) não devem demorar mais do que
8 segundos.

27. 27
5.1.6. SEGURANÇA
a) O sistema não deve permitir que pessoas não autorizadas realizem ações no sistema.
b) O sistema não deve permitir que usuários não autenticados acessem páginas do sistema.
c) O sistema não deve permitir que um usuário que não seja funcionário consiga atualizar
situação de serviços ou funcionalidades que sejam restritas a funcionários.
Caso um usuário não autorizado tente acessar a aplicação será apresentada a seguinte
mensagem:
5.2. INTERFACES/ APIS
Com a utilização de microsserviços manter o controle e gerenciamento dos seus pontos
de acesso é muito importante, para auxiliar a equipe de desenvolvimento foi utilizado a interface
do swagger para documentar todos os pontos de entrada aos microsserviços do sistema SGM.
Para ter acesso aos documentos basta acessar os endereços abaixo:
5.2.1. EUREKA
/eureka/apps
Esse endpoint retorna todos os serviços registrados no service-discovery

28. 28
5.2.2. SESSÃO 1: MÉTODOS DO API AUTH
a) Delete User

29. 29
b) Refresh Token
c) SIGNIN

30. 30
d) SignUp
5.2.3. SESSÃO 2:MÉTODOS DO CIDADÃO
a) Recupera IPTU

31. 31
b) RECUPERA ITR
c) RECUPERA TODAS AS NOTÍCIAS
d) CADASTRAR NOTÍCIA

32. 32

33. 33
e) RECUPERA POR ID
f) RECUPERA POR TÍTULO

34. 34
6. AVALIAÇÃO DA ARQUITETURA
6.1. ANÁLISE DAS ABORDAGENS ARQUITETURAIS
Baseado nas restrições da arquitetura e nos requisitos não-funcionais, a arquitetura
adotada foi desenvolvida baseada nos princípios de microsserviços. Onde iremos desenvolver
serviços com um alta coesão e baixo acoplamento, junto com isso um alto nível de
escalabilidade e manutenibilidade dos sistemas, onde teremos alguns serviços hospedados em
ambiente de cloud e alguns em on-premise.
O SGM interage com muitos sistemas, com a interface de comunicação desses
sistemas podem ser muito diferentes. Sistemas com contratos não padronizados são muito
desafiadores, e se vinculados diretos com o microsserviços do SGM podem trazer um
acoplamento não desejado, onde qualquer alteração nesses sistemas impactaria negativamente
nos nossos serviços. Assim a utilização do padrão Wrapper que nos permite encapsular toda
regra de acesso aos serviços externos, padronizando o contrato de acesso aos sistemas internos,
além de nossos sistemas só interagirem com sistemas de terceiros através dos nossos wrappers.
Como restrição arquitetural devíamos manter a arquitetura híbrida, com parte
dos serviços sendo mantidos na nuvem e on-premise. Sendo assim é viável contratar
fornecedores que já lidam com esse tipo de estilo arquitetural, como é o caso da Amazon AWS.
Com a utilização de serviços de infraestrutura na nuvem não é necessário dinheiro para investir
em servidores físicos, temos um grande leque de diferentes infraestruturas, como web servers,
containers de orquestração, como uma maior escalabilidade horizontal dos nossos serviços, o
que não mais complicado de conseguir quando utilizamos somente uma arquitetura on premise.
Para uma melhor implantação dos novos componentes faremos a utilização de
containers por meio do docker, onde teremos empacotados todos as dependências
independentes de onde o sistema está sendo implantado. Utilizaremos como repositório de
imagens o Amazon Elastic Container Repository (ECR) e que é totalmente provido pela AWS.
Para o gerenciamento de todos os serviços em containers é necessário o uso de
um orquestrador, que utilizamos o Kubernetes, para deploy dos serviços on premise e na nuvem.
Para o deploy dos serviços na nuvem utilizaremos o Elastic Kubernetes Service (EKS) que nos
permite facilmente configurar um cluster no cloud AWS, onde teremos muitas das tarefas de
criação e configuração feitas por pela própria AWS.

35. 35
6.2. CENÁRIOS
a) CENÁRIO 1
Ao acessar o sistema de por meio de qualquer plataforma, seja dispositivo móvel,
Desktop com redução de resolução, utilizando os principais navegadores, como Edge,
Firefox e Chrome, o sistema deve se adequar de forma automática. Ajustando todos os
componentes, cores, links, estão de acordo com a acessibilidade para atender os
requisitos não funcionais.
b) CENÁRIO 2
Ao acessar alguma URL privada o sistema não deve permitir o acesso aos
usuários não autenticados no sistema. O sistema deve redirecionar o usuário para a
página de login quando ele tentar acessar alguma tela privada sem ter se autenticado.
Assim garantindo a segurança e confiabilidade da aplicação. Estando de acordo com os
requisitos funcionais.
c) CENÁRIO 3
Ao usuário logado tentar acessar uma URL ao qual ele não possui permissão, o
sistema deve redirecionar o usuário para uma página que informe que o usuário não
possui permissão para acessar determinado recurso. Assim garantindo a confiabilidade
e segurança dos dados do sistema.
d) CENÁRIO 4
Ao acessar os realizar alguma interação com os sistemas legados o sistema deve
realizar uma comunicação de forma transparente e segura. Responsabilizando-se por
uma boa comunicação entre os módulos. Desse modo atendendo ao requisito de
interoperabilidade
e) CENÁRIO 5
Ao acessar alguma funcionalidade pública ou privada o sistema deve ter um bom
desempenho, realizando a renderização dos componentes e do objeto em até no máximo
8 segundos. Atingindo assim um dos atributos de qualidade.

36. 36
6.3. PRIORIZAÇÃO
Na priorização foi utilizado o método de árvore de utilidade reduzida e com prioridades.
Por esse procedimento os atributos são qualificados por importância e complexidade de acordo
com as características do requisito.
Atributo de qualidade Cenário Importância Complexidade
Acessibilidade Cenário 1 Alta Baixa
Segurança Cenário 2 Alta Baixa
Segurança Cenário 3 Alta Baixa
Interoperabilidade Cenário 4 Média Média
Desempenho Cenário 5 Alta Média
6.4. AVALIAÇÃO
Foram avaliados todos os cenários levantados na seção anterior. Para essas avaliações o
padrão estímulo-resposta é aplicado, para identificar os pontos de risco, sensibilidade e
tradeoffs.
a) CENÁRIO 1 – Acessibilidade
Atributo de
qualidade
Acessibilidade
Requisito de
qualidade
O sistema deve suportar dispositivos móveis e web
Preocupação O sistema deve adaptar seus componentes visuais de acordo com o dispositivo
utilizado
Estímulo Usuário utilizando as páginas da aplicação
Mecanismo Front-end
Medida de resposta O sistema deve de forma automática se ajustar a resolução das telas, seja móveis ou
desktop
Riscos A estrutura da tela pode ocasionar resultados distintos, dependendo do
dispositivo utilizado, causando uma exibição fora dos padrões.
Pontos de
sensibilidade
N/A

37. 37
Tradeoffs N/A
• Evidências
Responsividade da página por meio de um dispositivo desktop: Resolução:

38. 38
Responsividade da página por meio de um dispositivo móvel, IPAD: Resolução:
768x1024

39. 39
Responsividade da página por meio de um dispositivo móvel, Moto G4: Resolução:
360x640

40. 40
b) CENÁRIO 2 – Segurança
Atributo de
qualidade
Segurança
Requisito de
qualidade
O Sistema deve redirecionar para tela de login o usuário não autenticado
Preocupação Não permitir o acesso do usuário sem estar autenticado
Estímulo Usuário tentando acessar alguma página interna do sistema sem estar devidamente
autenticado
Mecanismo Front-end
Medida de
resposta
O sistema deve redirecionar o usuário para a página de login
Riscos A falha no sistema de autenticação é uma falha grave, onde não funcionando
corretamente pode levar a vários riscos de acesso indevido a dados sensíveis
Pontos de
sensibilidade
N/A
Tradeoffs N/A
• Evidências
Usuário sem estar autenticado deve ser redirecionado para tela de login ao tentar acessar
qualquer página

41. 41
c) CENÁRIO 3 – Segurança
Atributo de
qualidade
Segurança
Requisito de
qualidade
O Sistema não deve exibir a funcionalidade e nem permitir o acesso direto pela url ao
usuário que não possuir permissão para o recurso.
Preocupação Não permitir o acesso do usuário sem permissão
Estímulo Usuário tentando acessar alguma página ou funcionalidade que não possui permissão
Mecanismo Front-end

42. 42
Medida de
resposta
O Sistema não deve exibir para o usuário a funcionalidade e caso ele tente acessar
direto pela URL deve ser exibida uma tela de falta de privilégios
Riscos A falha no sistema de permissão é uma falha grave, onde não funcionando corretamente
pode levar a vários riscos de acesso indevido a dados sensíveis
Pontos de
sensibilidade
N/A
Tradeoffs N/A
• Evidências
O usuário autenticado como usuário cidadão, tenta acessar a tela que não tem permissão,
deve ser apresentado a mensagem de acesso negado.

43. 43
d) CENÁRIO 4 – Interoperabilidade
Atributo de
qualidade
Interoperabilidade
Requisito de
qualidade
O sistema deve possibilitar a comunicação com sistemas legados
Preocupação Utiliza padrões que possibilitem a troca de informações entre sistemas distintos
Estímulo Usuário solicitando dados do seu IPTU
Mecanismo Back-End
Medida de
resposta
O sistema deve realizar a comunicação de forma transparente e segura, retornando as
informações solicitadas
Riscos O sistema legado está fora do ar ou alterações no sistema legado que comprometam a
comunicação ou alterem o tipo de resposta.
A comunicação ser interceptada no meio do caminho assim comprometendo a
integridade do sistema
Pontos de
sensibilidade
Sobrecarga dos serviços
Tradeoffs Com uma alta demanda os tempos de resposta na comunicação podem aumentar
• Evidências
A fim de possibilitar a comunicação com os sistemas legados, foi implantado um
módulo de wrapper que possibilita o SGM de obter os dados de forma transparente.
e) CENÁRIO 5 – Desempenho
Atributo de
qualidade
Desempenho

44. 44
Requisito de
qualidade
O sistema deve possuir bom desempenho
Preocupação O sistema deve possuir um bom desempenho, renderizando todos seus componentes e
dados com no máximo de 8 segundos
Estímulo O usuário solicitando dados dos seus impostos
Mecanismo Front-end e Back-End
Medida de resposta A página deve apresentar rapidez na construção e exibição dos dados recuperados dos
microsserviços
Riscos O sistema legado apresentar instabilidade que pode implicar em um maior tempo de
resposta
Pontos de
sensibilidade
Latência de rede
Tradeoffs N/A
• Evidências

45. 45
6.5. RESULTADO
Foi possível evidenciar através de todos os cenários avaliados que a arquitetura
construída se encaixa com o que foi solicitado. Onde desenvolvemos uma arquitetura de fácil
manutenção, com uma alta escalabilidade, onde buscamos desenvolver módulos pouco
acoplados e altamente coesos. No qual traz uma grande facilidade para as equipes de
desenvolvimento,
Podemos ver também que a cultura de DevOps trouxe para nosso projeto junto com os
microsserviços uma escalabilidade vertical, sendo possível realizar toda a gestão dos
componentes de forma automática e em tempo de execução, facilitando escalabilidade,
portabilidade e reinicialização dos serviços.
Mas não podemos de falar que todas as arquiteturas possuem pontos negativos e que
podem ser ponto de atenção. Trabalhar com microsserviços requer uma mudança de mindset
das equipes de desenvolvimento, pois é muito fácil trazer um acoplamento indesejável para
dentro do serviço o que acabaria fugindo da arquitetura projetada, acarretando lentidão,
dependências de serviços externos e outros microsserviços.
Com a implementação de microsserviços aumentamos a necessidade de
interoperabilidade, assim podendo causar uma maior latência de rede, aumentando o tempo de
serialização e desserialização de dados, que pode vir a ser um ponto de gargalo no futuro.

46. 46
7. CONCLUSÃO
No primeiro momento acreditamos que com todos os cenários e restrições impostas, a
arquitetura desenvolvida irá atender as necessidades da prefeitura. Mas devemos lembrar que
toda a arquitetura necessita de melhorias constantes, para uma melhor adequação no dia a dia.
Como diminuir a utilização de sistemas legados, possivelmente transformando-os em
microsserviços e hoje existem vários padrões arquiteturais que podem ajudar nesse momento,
como o strangler pattern.
Para uma arquitetura de microsserviços tenha sucesso em um ambiente
organizacional é importante o treinamento da equipe para que seja uma equipe com experiência
em microsserviços para lidar com esse tipo de arquitetura, pois esse pode ser um grande ponto
que pode levar ao fracasso do projeto. O sucesso desse projeto está na mão de todos, que se
utilizando das normas e das boas práticas de microservices o projeto vai se adequar bem dentro
da prefeitura

47. 47
REFERÊNCIAS
Artigo Engenharia de Software 3 - Requisitos Não Funcionais. (s.d.). Fonte: DEVMEDIA:
https://www.devmedia.com.br/artigo-engenharia-de-software-3-requisitos-nao-
funcionais/9525
Fowler, M. (s.d.). Microservices Guide. Fonte: martinfowler.com:
https://martinfowler.com/microservices/
Introduction to JSON Web Tokens. (s.d.). Fonte: JWT.IO: https://jwt.io/introduction
Richardson, C. (s.d.). Pattern: API Gateway / Backends for Frontends. Fonte:
Microservices.io: https://microservices.io/patterns/apigateway.html
Richardson, C. (s.d.). Pattern: Client-side service discovery. Fonte: Microservices.io:
https://microservices.io/patterns/client-side-discovery.html
ScienceDirect. (8 de Outubro de 2015). Evaluating REST architectures—Approach, tooling
and guidelines.
Tutorial: Introdução ao React. (s.d.). Fonte: React: https://pt-
br.reactjs.org/tutorial/tutorial.html

48. 48
APÊNDICES
Repositório SGM:
https://github.com/tcc-sgm/
Repositório frontend SGM:
https://github.com/tcc-sgm/prefeitura-frontend
Repositório microservice de autenticação:
https://github.com/tcc-sgm/auth
Repositório microservice serviços para o cidadão
https://github.com/tcc-sgm/cidadao
Repositório microservice API Gateway
https://github.com/tcc-sgm/api-gateway
Repositório microservice de Service Discovery
https://github.com/tcc-sgm/service-discovery
Vídeo para prova de conceito:
https://www.youtube.com/watch?v=Tw60Spxng9E
URL SGM: localhost://3000/
Usuários para acesso ao SGM:
Usuário: admin
Senha: 12345
Usuário: cidadao
Senha: 12345

49. 49
CHECKLIST PARA VALIDAÇÃO DOS ITENS E ARTEFATOS DO TRABALHO
Nº Item a ser cumprido Sim Não Não se aplica
Completeza do documento
1 Todos os elementos iniciais do documento (capa, contracapa,
resumo, sumário...) foram definidos?
2 Os objetivos do trabalho (objetivos gerais e pelo menos três
específicos) foram especificados?
3 Os requisitos funcionais foram listados e priorizados?
4 Os requisitos não funcionais foram listados e identificados usando o
estilo estímulo-resposta?
5 As restrições arquiteturais foram definidas?
6 Os mecanismos arquiteturais foram identificados?
7 Um diagrama de caso de uso foi apresentado junto com uma breve
descrição de cada caso de uso?
8 Um modelo de componentes e uma breve descrição de cada
componente foi apresentada?
9 Um modelo de implantação e uma breve descrição de cada elemento
de hardware foi apresentada?
10 Prova de conceito: uma descrição da implementação foi feita?
11 Prova de conceito: as tecnologias usadas foram listadas?
12 Prova de conceito: os casos de uso e os requisitos não funcionais
usados para validar a arquitetura foram listados?
13 Prova de conceito: os detalhes da implementação dos casos de uso
(telas, características, etc) foram apresentadas?
14 Prova de conceito: foi feita a implantação da aplicação e indicado
como foi feita e onde está disponível?
15 As interfaces e/ou APIs foram descritas de acordo com um modelo
padrão?
16 Avaliação da arquitetura: foi feita uma breve descrição das
características das abordagens da proposta arquitetural?
17 Avaliação da arquitetura: Os atributos de qualidade e os cenários
onde eles seriam validados foram apresentados?
18 Avaliação da arquitetura: uma avaliação com as evidências dos
testes foi apresentada?
19 Os resultados e a conclusão foram apresentados?
20 As referências bibliográficas foram listadas?
21 As URLs com os códigos e com o vídeo da apresentação da POC
foram listadas?