Esta subseção tem o objetivo de validar a Arquitetura de Software quanto a dois dos aspectos considerados para implementar essa arquitetura: PMES e os requisitos elicitados, relacionando-os com a Arquitetura Proposta. Não é propósito desta subseção avaliar a Arquitetura de Software quanto a esses aspectos, isso fica por conta do próximo capítulo. 9 https://sites.google.com/site/gson/gson-user-guide
Capítulo 4. Arquitetura Proposta 83
4.3.3.1
PMES versus Arquitetura de Software
Uma das balizas do projeto desta AS é o PMES. Durante todo o projeto arquitetural foi pensado em como cumprir, ou não descumprir, esse conjunto de lei. Essa subseção mostra como a AS proposta se relaciona com as leis que regem esse mandamento. A avaliação de quanto a AS obedece a essas leis é realizada na avaliação da arquitetura proposta.
R - Ser reutilizado por diferentes sistemas: Esse é um dos principais objetivos da
AS proposta, fornecer serviços para diferentes sistemas. Com os dados e informações sendo disponibilizados como serviços web, diferentes sistemas podem utilizar os dados disponibilizados pela AS proposta. Outra forma de ser reutilizado é o uso da Arquitetura Proposta em outros domínios, como por exemplo, na distribuição de gasolina.
E - Ser estendido para acomodar novos comportamentos: Essa lei é cumprida devido
a facilidade de criar novas entidades no Mediador de Dados, interagindo diretamente com ele ou estendendo as classes oferecidas pelo módulo Camada de Negócio AS.
A - Oferecer Analytics: No momento, a Arquitetura não cumpre diretamente essa lei,
porém o sistema oferece diversas oportunidades de emprego de Analytics, devido a grande massa de dados potencialmente gerado. As Plataformas IoT possuem artefatos que podem ser usados para essa finalidade, como por exemplo Complex Event Processing (CEP)11 da
FIWARE.
L - Fracamente acoplado: Os módulos e subsistemas só se comunicam por mensagem,
além de estarem em ambientes e/ou máquinas virtuais separadas. O que contribui também com o cumprimento dessa lei é a total dissociação entre os Produtores de Contexto e os Consumidores onde um não precisa ter conhecimento do outro.
FU - Permitir ser mantido e atualizado: A separação em módulo e subsistemas auxilia
o cumprimento desta lei. Outra decisão arquitetural que corrobora com essa lei é empregar protocolos, padrões e algoritmos bem definidos e abertos como REST, NGSI, JSON e MVC na implementação Arquitetura Proposta.
CK - Usar conhecimento de contexto: A partir da troca de mensagens entre os mó-
dulos, o sistema consegue adquirir e usar o conhecimento de contexto para decidir se as mensagens são válidas ou não.
IN - Ser, na medida do possível, independente de rede: O sistema necessita de rede
para funcionar, uma vez que é um sistema distribuído, porém é projetado para mesmo sem rede cumprir sua tarefa de forma independente e isolado, completando-a assim que obtiver acesso a rede.
G - Preocupações de segurança e integridade equilibrada com a usabilidade: É um
dos principais requisitos do sistema, sendo trabalhado fortemente na autenticidade das mensagens trocadas entre os módulos através da assinatura digital, com o mínimo de interação humana.
Capítulo 4. Arquitetura Proposta 84
Tabela 10 – Mapeamento de Requisitos X Módulos
Requisito MD Autenticador Gateway Nó Negócio
Mínima interação do usuário R C C R
Interoperabilidade R C C C Eficiência Energética C R Ubiquidade/Mobilidade C R Segurança C R C R C Geolocalização R Disponibilidade R R C C C Flexibilidade/Extensibilidade R R Baixo custo C C C R
Adequação modelos atuais C C C C R
Fonte: O Autor
4.3.3.2
Requisitos Elicitados versus Módulos da Arquitetura de Software
A Tabela 10 lista o módulo da arquitetura proposta que: [C] Contribui para o atendimento de um requisito; e [R] Responsável direto para que o requisito seja contemplado ou que afeta diretamente esse requisito.
Como nota-se, mais de um módulo pode ser o responsável pelo atendimento do requi- sito, bem como um certo módulo pode não contribuir com esse requisito.
4.3.4
Resumo da Seção
Nesta seção foi especificada a Arquitetura de Software da arquitetura proposta neste trabalho, sendo detalhadas a Arquitetura de Software Proposta e a Implementação de Referência desta arquitetura. Para isso, foram apresentadas as Camada de Aplicação e Camada de Negócio através da metodologia 4+1. Também foi apresentado uma validação da Arquitetura de Software com o PMES e com os requisitos elicitados, relacionando-a com esses aspectos.
4.4
CONSIDERAÇÕES FINAIS DO CAPÍTULO
Neste capítulo foram apresentados um conjunto de requisitos fundamentais a serem aten- didos na implementação e implantação de uma arquitetura para SGRH no contexto deste trabalho. Após essa definição foi apresentado o modelo de arquitetura IoT usado, apre- sentando as camadas desta arquitetura. Por fim foi especificada a Arquitetura de Software da arquitetura proposta neste trabalho.
No próximo capítulo essa arquitetura será avaliada por especialistas em diversas áreas relacionada com este trabalho, a fim de validar a arquitetura proposta.
85
5 AVALIAÇÃO DA ARQUITETURA PROPOSTA
A avaliação da arquitetura de software é um meio poderoso para tomar decisões sobre sistemas, avaliar e mitigar riscos e identificar formas de melhoria e migração de sistemas de software. A avaliação da arquitetura atinge esses objetivos ao prever as propriedades dos sistemas antes de serem construídos ou respondendo a perguntas sobre os sistemas existentes (KNODEL; NAAB, 2014). Segundo Patidar e Suman (2015), na fase inicial do sistema a AS deve ser avaliada para verificar e comparar as vantagens e desvantagens de uma arquitetura.
O objetivo da avaliação da arquitetura de software é fornecer meios eficazes para de- terminar características de atributos de qualidade, identificar riscos potenciais no projeto de arquitetura e entender trade-offs no projeto (PATIDAR; SUMAN, 2015). Knodel e Naab
(2014) em um trabalho com mais de 50 avaliações de AS, concluíram que a avaliação de AS pode ser um instrumento extremamente útil para apoiar a tomada de decisão de arquitetura e orientar o alinhamento estratégico de negócios e tecnologias em um sistema. Sendo assim, podemos concluir que tão importante quanto definir a arquitetura de um sistema é realizar uma avaliação do que foi definido, com o objetivo de identificar as possíveis falhas antes que se tornem grandes problemas no futuro.
Este capítulo visa avaliar a Arquitetura Proposta neste trabalho. Para tal, na seção 5.1 serão apresentados dois métodos de avaliação de AS amplamente aceitos e validados na literatura. Posteriormente, na seção 5.2, será discutido o protocolo adotado para a avaliação desta AS. Na seção 5.3 é apresentada como foi a execução da avaliação propri- amente dita. Em seguida, a seção 5.4 discute alguns resultados e comentários a respeito das principais questões que surgiram durante a avaliação desta AS. Além disso, a seção 5.5 discute as principais ameaças à validade da avaliação.