Visão Lógica

A arquitetura proposta para a AGORA-IFM relaciona-se com elementos externos a ela, compondo a plataforma AGORA. O diagrama daFigura 9ilustra a lógica de funci- onamento dessa arquitetura inserida no contexto em que foi planejada para ser aplicada. Os elementos são organizados em três camadas, as quais se referem às partes apresentadas inicialmente naFigura 1. As camadas correspondem às partes de aquisição, integração e aplicação da plataforma, estando a AGORA-IFM incluída na camada de integração. O funcionamento dos elementos externos à AGORA-IFM não foi deinido pelo autor, além disso, as comunicações que não envolvem nenhum elemento incluído na AGORA-IFM, como aquelas entre AGORA-DSM e SOS, ou SOS e banco de dados, ou banco de dados e AGORA-DS, também não foram estabelecidas pelo autor e estão ilustradas na Figura 9

apenas para representar a existência de tais comunicações.

O diagrama representa a comunicação entre elementos por uma seta, indicando uma mensagem de requisição ou de resposta, associada a um rótulo, indicando o meio de comunicação e os dados transferidos. Com exceção das comunicações entre o “Manipu- lador de dados de script” e o “Motor de script”, todas as demais são feitas por meio de

Hypertext Transfer Protocol (HTTP), assim, essas comunicações podem ser instanciadas,

por exemplo, utilizando-se Simple Object Access Protocol (SOAP). O meio de comuni- cação entre o Manipulador e o Motor não foi deinido devido à variação de meios pelos quais um motor de scripts pode ser utilizado, por exemplo como uma biblioteca estática ou dinâmica, uma aplicação não conectada à internet (of-line) instalada no mesmo ser- vidor do Manipulador, ou ainda um serviço web comum. Os dados indicados nos rótulos das setas são apresentados sem grande formalismo e de modo a facilitar o entendimento do que está sendo transferido. Os “tipos” indicados antes dos dados podem, por vezes, representar um padrão de formatação ao invés de um tipo de dado nativo. As informa- ções estão discriminadas para explicitar o que é transferido em cada mensagem, porém, elas podem ser transferidas como um único argumento em alguma estrutura de dados. Por exemplo, a mensagem “HTTP(string caminho, SWEC ofering, posição, valor, data, categoria)” é transferida via HTTP e possui apenas dois argumentos, o caminho, do tipo texto, e cinco informações de uma ou mais observações, todas registradas em um único argumento, também do tipo texto, o qual é formatado de acordo com o padrão Sensor

cada mensagem são apresentados no diagrama de componentes daFigura 8 e detalhados na subseção anterior, Visão de Desenvolvimento.

A camada inferior do diagrama 9, Camada de Aquisição, é responsável por obter, centralizar e disponibilizar informações de observações, tanto de sensores quanto de vo- luntários. Ela compreende quatro elementos: AGORA-DSM, AGORA-VOS, SOS, e um banco de dados. A aplicação AGORA Dynamic Sensor Management (DSM) é respon- sável por coletar observações de sensores, e a AGORA Volunteered Observation Service (VOS) por coletar observações de voluntários. Ambas as aplicações utilizam o Sensor Ob-

servation Service (SOS) para inserirem suas observações em um banco de dados, o qual

centraliza observações ainda não processadas. O SOS também é utilizado, por exemplo por componentes da AGORA-IFM ou pela AGORA-DS, para recuperar as observações desse banco.

Na camada intermediária, Camada de Integração, encontra-se a aplicação AGORA

Information Fusion and Management (IFM) e dois elementos utilizados por esta. A

AGORA-IFM compreende oito serviços, cujas interações são detalhas nas subseções an- teriores deste capítulo. Por outro lado, essa visão permite algumas veriicações como, por exemplo, as mensagens trocadas entre o Manipulador de dados de sensores e o SOS são equivalentes às trocadas entre o Manipulador de VGI e o SOS, assim como as mensa- gens trocadas entre esses dois manipuladores e o Orquestrador. O mesmo ocorre com as mensagens trocadas entre esses manipuladores e o Uniicador de dados, e entre este e o Orquestrador. Ainda, as respostas do Categorizador e do Manipulador de dados de script para o Orquestrador são equivalentes com exceção à quantidade de observações retor- nadas. Uma dessas respostas, dependendo do luxo de processamento selecionado, será exatamente igual à requisição do Orquestrador para o Exportador de dados, às respostas do Orquestrador para a AGORA-DS e para o Escalonador, e à resposta do Escalonador para a AGORA-DS. Por im, as requisições da AGORA-DS e do Escalonador para o Orquestrador também são iguais. Os dois elementos da camada intermediária que não pertencem à AGORA-IFM são a aplicação Motor de scripts e um banco de dados. O motor, responsável por executar scripts sobre os dados selecionados no processo de inte- gração, possui comunicações especíicas que dependem do motor instanciado. O banco de dados armazena os dados resultantes da integração, e pode ser acessado por aplicações externas como a AGORA-DS.

A camada superior, Camada de Aplicação, utiliza os dados das camadas anteriores para gerar mapas e indicadores para os tomadores de decisão envolvidos no contexto dessa plataforma. Ela compreende a AGORA Decision Support (DS), que acessa o SOS, o banco de dados processados e os serviços do Orquestrador e Escalonador. Apesar de não conigurar um luxo de processamento deinido neste projeto, aplicações desta camada também podem acessar diretamente os serviços dos demais elementos da AGORA-IFM.

3.5 Validação

Como mencionado anteriormente, a validação inal foi feita por meio de uma avali- ação arquitetural, na qual foi utilizada uma adaptação do Architecture Tradeof Analysis

Method (ATAM). A condução e os resultados dessa avaliação são apresentados no capítulo

seguinte.

3.6 Considerações Finais

Neste capítulo foi apresentada a AGORA Information Fusion and Managemente, AGORA-IFM, uma arquitetura de software para integrar informações de sensores e vo- luntários no contexto de inundações. Trabalhos relacionados a integração de dados geo- gráicos não estabelecem um processo totalmente automatizado e que possibilite usuários escolherem o método de integração. Essas características correspondem às principais con- tribuições desta pesquisa, que também deini comunicações com aplicações externas para coletar informações, processá-las e apresentá-las.

A arquitetura proposta descreve componentes, interconectados de forma padro- nizada, para manipular, categorizar, integrar e disponibilizar informações relevantes à gestão de risco de inundações. Essa arquitetura foi avaliada por meio de um método de avaliação arquitetural, detalhado no próximo capítulo. Além disso, ela também foi imple- mentada e seu comportamento foi veriicado por meio de um experimento, apresentado no Capítulo 5.

CAPÍTULO

4