arquitetura e interface para o módulo de análise do...
TRANSCRIPT
Universidade Federal do Rio de Janeiro
Escola PolitécnicaDepartamento de Eletrônica e de Computação
Arquitetura e interface para o módulo de análise dosistema SOMA
Autor: ________________________________________________________________ Diogo Rafael Corrêa Marques
Orientador: ________________________________________________________________ Prof. Antônio Cláudio Gómez de Sousa, D. Sc.
Examinador: ________________________________________________________________ Prof. Ricardo Rhomberg Martins, D. Sc.
Examinador: ________________________________________________________________ Prof. Sergio Barbosa Villas-Boas, P.h.D.
DEL
Março de 2015
Dedicatória
Dedico esse trabalho à minha falecida mãe Laiz Ribeiro Corrêa Marques e ao
meu falecido amigo Guilherme Paiva. Duas pessoas muito importantes na minha vida
com quem não poderei compartilhar esse momento feliz.
ii
Agradecimentos
O sistema SOMA Torres é fruto de um esforço coletivo dessa forma desejo
agradecer toda a equipe do CEPEL envolvida, em especial Alexsandra Santana da Silva,
Antônio Leite, Aureo Ruffier, João Antônio Ferreira, João Saad, Luciano Azevedo, Luiz
Gonzaga, Mária Balthazar, Miguel Michalski, Renato Rocha, Ricardo Rangel, Vinicius
Falseth.
Desejo agradecer aos funcionários e corpo docente do departamento de
eletrônica e ao povo brasileiro por manter essa instituição.
Por fim, agradeço o apoio de minha família e meus amigos em especial do meu
pai Edvaldo, e amigos Guilherme, Gustavo, Filipe, Carlos e Fabiana que me apoiaram
durante momentos difíceis.
iii
Resumo
Arquitetura e interface para o módulo de análise do sistemaSOMA
Diogo Rafael Corrêa Marques
Novembro/2014
Orientador: Antônio Cláudio Gómez de Sousa
Departamento de Engenharia Eletrônica e de Computação
A interface de análise de um sistema de monitoramento desenvolvido no CEPEL
que tem como objetivo a observação de uma torre de transmissão de FURNAS para o
estudo dos fenômenos meteorológicos associados a eventos de queda das torres. A
interface deverá ser capaz de se adaptar a adição de novas ferramentas de análise à
medida que o problema evolua.
O resultado foi uma interface que atendeu a todos objetivos.
Palavras-Chave: GUI, Sistema de monitoramento, MVP, Flex 3
iv
SumárioIntrodução.....................................................................................................................1
Tema..............................................................................................................................1
Justificativa...................................................................................................................1
Delimitação...................................................................................................................2
Objetivo.........................................................................................................................4
Metodologia..................................................................................................................4
Descrição.......................................................................................................................5
Capítulo 2......................................................................................................................7
Introdução.....................................................................................................................7
Casos de Uso.................................................................................................................8
Comunicação com o servidor........................................................................................9
Interface de Usuário....................................................................................................11
Capítulo 3....................................................................................................................16
Introdução...................................................................................................................16
Model view presenter..................................................................................................16
Vistas Principais..........................................................................................................24
Capítulo 4....................................................................................................................32
Resultados...................................................................................................................32
Objetivos.....................................................................................................................38
Limitações...................................................................................................................38
Soluções......................................................................................................................39
Conclusão....................................................................................................................40
Bibliografia.................................................................................................................41
Apêndice A..................................................................................................................42
Arquitetura do Sistema...............................................................................................42
Apêndice B..................................................................................................................43
Casos de Uso...............................................................................................................43
v
Índice de Figuras
Figura 1: Arquitetura básica do SOMA Torres..................................................................3
Figura 2: Casos de uso principais do módulo de análise...................................................8
Figura 3: Esquema da janela de resumo..........................................................................11
Figura 4: Dois exemplos de unidades de visualização....................................................12
Figura 5: Os domínios são organizados em uma estrutura hierárquica...........................12
Figura 6: Para cada domínio as análises são descendentes diretos..................................13
Figura 7: Esquema da janela de análise com destaque para os elementos de mudança de
domínio............................................................................................................................13
Figura 8: Diagrama do componente de navegação..........................................................14
Figura 9: Diagrama geral da interface.............................................................................15
Figura 10: Diagrama mostrando o relacionamento entre múltiplas instâncias do conjunto
apresentador e vista.........................................................................................................17
Figura 11: O apresentador deve se relacionar com a vista através de uma interface......19
Figura 12: O apresentador expõe apenas interfaces para seus interlocutores..................20
Figura 13: Gerente da aplicação e seus colaboradores....................................................21
Figura 14: Diagrama de sequência para a inicialização da aplicação..............................22
Figura 15: Eventos são transmitidos via EventBroadcaster e roteados via
SomaController................................................................................................................24
Figura 16: Apresentador do painel de análise(bruta) e seus colaboradores.....................25
Figura 17: Apresentador do painel de análise(histórica) e seus colaboradores...............26
Figura 18: Abstração do container de séries permite o tratamento universal para diversos
tipos de representações gráficas......................................................................................27
Figura 19: Unidades de visualização e sua especialização para gráficos........................28
Figura 20: Diagrama de sequência para atualização da janela de detalhe.......................29
Figura 21: Relacionamento entre a fábrica das barras de ferramentas e os elementos
construídos.......................................................................................................................29
Figura 22: Interface para tratar os eventos gerados por um grupo de ferramentas..........30
Figura 23: Diagrama de sequência para o tratamento de novas páginas publicadas na
análise..............................................................................................................................31
Figura 24: Sinal de Alarme (Tensão no estai A) no domínio do tempo...........................32
Figura 25: Agora no domínio da frequência (módulo apenas)........................................32
vi
Figura 26: Módulo e fase.................................................................................................33
Figura 27: Histograma.....................................................................................................33
Figura 28: Distribuição normal com os valores estatísticos das amostras......................33
Figura 29: Tabela de todos os valores estatísticos calculados.........................................34
Figura 30: Adicionando um filtro passa banda com faixa de passagem entre 0,2Hz e
0,3Hz, transição de 0,05Hz e atenuação de 10dB...........................................................34
Figura 31: Sinal filtrado no tempo...................................................................................34
Figura 32: Resultado da filtragem na frequência.............................................................35
Figura 33: Série históricas(média e mínimo) progressão temporal.................................36
Figura 34: Histograma de ambas as séries.......................................................................36
Figura 35: Distribuição Normal.......................................................................................37
Figura 36: Tabela com os valores estatísticos calculados para ambas as séries..............37
Figura 37: Arquitetura em detalhes do SOMA Torres.....................................................42
vii
Siglas
API - Application Programming Interface
CEPEL - Centro de Pesquisas de Energia Elétrica
FIR - Finite Impulsive Response
FFT - Fast Fourier Transform
GUI - Graphical User Interface
GWT - Google Web Toolkit
HTML - HyperText Markup Language
HTTP - HyperText Transfer Protocol
JMS - Java Message Service
LCDS - LiveCycle Data Services
MVP - Model View Persenter
RPC - Remote Procedure Call
UC - Use Case
UML - Unified Modeling Language
XML - Extensible Markup Language
viii
Introdução
Tema
O tema do trabalho será um sistema de monitoramento de estruturas, a fim de
medir o impacto de fenômenos meteorológicos sobre a mesma.
Justificativa
Toda estrutura é projetada levando-se em conta o ambiente que ocupará.
Informações sobre o ambiente como temperatura ambiente, velocidade do vento,
concentração de chuva/neve, presença de terremotos servem como condições de
contorno para o projeto da mesma.
Essas informações, no entanto, são retiradas de referências que podem se tornar
obsoletas ao longo do tempo, fenômenos que não foram observados antes do projeto
podem vir a ter uma presença significativa após a construção. Dentro desse cenário se
torna importante o monitoramento contínuo dessas grandezas.
A análise de formas de onda é uma das principais ferramentas usadas no estudo
de sistemas. Logo a habilidade de visualizar grandezas como corrente elétrica,
temperatura, tensão tanto no tempo quanto em frequência é fundamental em um sistema
de monitoramento e diagnóstico.
Ainda no contexto desse tipo de sistema existe uma demanda crescente em não
apenas diagnosticar a saúde atual de um ativo como também se antecipar à possíveis
falhas, a fim de atingir este objetivo é necessário o monitoramento e análise de diversas
grandezas durante um período de funcionamento e constantemente cruzar as
informações coletadas com o modelo teórico. Este cruzamento será usado para
determinar quais desvios do comportamento esperado correspondem a sintomas de
falhas. O resultado será usado para gerar um modelo matemático mais sofisticado e a
partir deste uma nova rodada de coleta e cruzamento é realizada com cada iteração
gerando conjuntos de regras cada vez mais refinados.
A iteratividade do processo será refletida na interface pois a cada iteração novas
1
ferramentas e formas de exibir o sinal poderão ser adicionadas, logo um programa que
facilite sua própria expansão e que possa ser configurado com o conjunto otimizado de
ferramentas para cada processo analisado é o ideal. Para isso precisamos de uma
arquitetura flexível, que tenha um baixo custo de manutenção e expansão.
Delimitação
A interface a ser examinada está ligada a uma derivação do projeto chamada
SOMA Torres, desenvolvido por uma equipe do CEPEL, que tem como objetivo o
estudo de uma torre de transmissão de Furnas na região sul do país. Essa região
apresenta um comportamento climático instável que é a suspeita causa das quedas de
torres dessa linha. O estudo das forças e da velocidade dos ventos aplicadas às mesmas
é fundamental para um melhor entendimento do fenômeno.
As seguintes grandezas serão observadas:
• Tensão nos estais - poderemos com essas ter uma melhor idéia sobre o
conjunto de forças aplicadas à torre.
• Dados ambientais locais (Velocidade e direção do vento e temperatura
ambiente) - podemos cruzar com a tensão a fim de estimar a influência
direta dos ventos no equilíbrio da torre.
O sistema, por sua vez, recebe as amostras colhidas desses sensores que estão
conectados ao módulo de controle que está instalado na torre. A comunicação entre
módulo e servidor é feita pela internet através de um modem 3G. O segundo conjunto
de objetivos que esse módulo tenta cumprir se refere à operação do próprio. Para o
CEPEL o desenvolvimento de uma tecnologia de aquisição de dados remotos com
alimentação independente é interessante, logo um segundo conjunto de dados será
coletado para o estudo do mesmo.
• Temperatura interna do gabinete.
• Medidas de corrente relacionadas ao consumo e geração de energia do
módulo e dos painéis solares.
• Estimativa de carga do conjunto de baterias.
• Tensão de alimentação do módulo.
Essas medidas mais as mensagens de diagnóstico do módulo ajudarão a
determinar a saúde do mesmo, tanto hardware quanto software, e no caso de falha a
2
apontar a causa.
Já o servidor tem a funções de controlar o módulo remoto, guardar os valores
amostrados e fornecê-los a interface e outros sistemas externos. O mesmo é composto
de três camadas básicas.
• Transporte - responsável pela comunicação entre o servidor e sistemas
externos. Esta pode ser feita várias maneiras tanto de maneira direta
(sockets, HTTP) ou indireta (JMS, LCDS).
• Serviços - contém código que permite a iteração com a persistência, a
capacidade de determinar os comandos a serem enviados ao módulo
remoto e qualquer outro código que atenda a um objetivo em um escopo
limitado (ex. módulo de cálculo que retorne a vida útil esperada de um
componente baseado nos dados dos sensores guardados no banco de
dados).
• Persistência - guarda os dados originados nos sensores observados pelo
sistema. Valores históricos são guardados em um banco de dados
enquanto que amostras brutas são armazenadas em um sistema de
arquivos.
A seguir podemos ver de forma resumida como os principais elementos de
software se relacionarão.
Figura 1: Arquitetura básica do SOMA Torres
Um diagrama mais completo com mais elementos e suas devidas posições nas
camadas do sistema pode ser encontrado no apêndice A.
Esse contexto será usado para definir as condições de contorno que a interface
3
do módulo de análise deve atender.
Objetivo
O objetivo geral do sistema é prover mais informações para determinar a causa
das quedas das torres na região em estudo.
Como é bem provável que novos cálculos e análises sejam necessários
dependendo da informação extraída, a interface tem duas categorias de objetivos a
serem perseguidos. Para os desenvolvedores o sucesso será medido em função da
facilidade com que a arquitetura permita o acréscimo de novas funcionalidades e a
facilidade de manutenção.
Em relação aos usuários que trabalham com a torre será o atendimento dos casos
de uso críticos definidos no capitulo dois. De maneira resumida podemos dizer que estes
são:
• Visualizar a série histórica ou de alarme, de uma ou mais fontes de dado,
em função do tempo.
• Controlar um subintervalo nessa seleção.
• Oferecer ferramentas de análise (filtros, transformadas etc).
Metodologia
O projeto será desenvolvido de maneira contínua em múltiplas iterações. Na
iteração inicial temos como base um modelo de como o sistema coletrará dados e como
a interface os deixará disponíveis. Uma vez que essa iteração esteja completa novas
iterações serão realizadas para lehorias na interface, modelo de diagnóstico e quaisquer
outras demandas de FURNAS.
Essa metodologia iterativa tem como objetivo a melhora incremental do sistema
e que a mesma acompanhe o entendimento do problema em questão, ou seja, à medida
que coletamos mais dados e os modelos matemáticos que descrevem o problema se
tornam mais refinados o sistema será capaz de se adaptar a essa evolução.
Parte das condições de contorno já estavam definidas antes do início do projeto.
4
a) A parte de serviços é toda escrita em linguagem JAVA, portanto qualquer
adição de serviço deve ser escrita nesse formato, e por outro lado, é
necessário que qualquer aplicativo do lado do cliente possa se comunicar
com as interfaces de serviço.
b) O lado do cliente será escrito em ActionScript 3 usando a API do Flex
3.6A com a IDE da adobe Flex Builder 3.
c) A modelagem será feita em UML 2.0. Usaremos os principalmente
diagramas de classe e de sequência quando precisarmos.
Com essas condições satisfeitas prosseguimos com as etapas que estão no
escopo da primeira iteração.
O primeiro passo foi o estudo das diferentes arquiteturas de relacionamento
entre modelo, regras de negócio e as vistas e dentre elas escolher a que atende às nossas
necessidades, que basicamente são a capacidade de adição de novas vistas e a
testabilidade dos elementos de controle.
Uma vez que a arquitetura tenha sido escolhida, a próxima etapa foi a de
implementar os elementos básicos com o objetivo de produzir a vista principal da
aplicação (com os elementos mais básicos possíveis).
Por fim um conjunto de passos que podem ser descritos como: implementar
vistas uma por uma e a cada vista do sistema analisar como a atual implementação da
arquitetura está se comportando na iteração com as vistas construídas até aquele ponto.
Caso a resposta não fosse favorável, seria necessário fazer algum tipo de refactoring e
as iterações continuaram até um resultado favorável com todas as vistas.
Depois a interface passou por uma etapa de testes de usabilidade internos onde
teremos a oportunidade de mudar a forma com que esta é usada e corrigir eventuais
falhas que não tinham sido detectadas até o momento.
Descrição
Esse documento será divido em cinco capítulos, onde o primeiro, introduziu o
trabalho em linhas gerais.
O segundo apresentará uma visão geral do módulo de análise como os casos de
usos principais que devem ser satisfeitos, o tipo de informação que o servidor espera e
5
provê e como esta deve ser trocada. Além de uma apresentação dos elementos visuais
que comporão as vistas principais.
O terceiro mostrará a escolha de arquitetura, seus elementos básicos e como eles
se relacionam e uma visão mais detalhada da implementação das vistas descritas no
capítulo anterior.
Os resultados serão apresentados no quatro e último capítulo através da captura
de telas onde o funcionamento real da aplicação será demonstrado e será levantado
quais objetivos foram alcançados e quais partes podem ser melhoradas.
6
Capítulo 2
Introdução
O módulo de análise deverá permitir um estudo preliminar dos sinais
armazenados pelo sistema de monitoramento. Isso implica em ter opções de seleção de
intervalos de interesse, juntamente com formas de identificá-los, a habilidade de se
aplicar filtros e mudar a perspectiva com que o sinal é visto (tempo, frequência,
estatística).
As vistas críticas serão gráficos e tabelas com estas representações a fim de dar
condições aos usuários de identificar as causas de um determinado comportamento em
um intervalo de interesse.
Quanto ao sistema de monitoramento é importante definir que tipo de dados
serão armazenados. Cada sensor envia dados constantemente, que serão referidos a
partir deste momento como ‘dados brutos’. Essa sequência de amostras, por sua vez, é
agregada e processada em janelas de tempo pré determinadas onde o resultado será
denominado de ‘dados históricos’.
Dados históricos são sempre persistidos e críticos para a análise de longo prazo
da saúde do sistema monitorado. Já os dados brutos são relevantes apenas em situações
específicas e é responsabilidade do sistema de monitoramento e seus operadores
identificarem essas instâncias. O sistema realiza essa tarefa através do sistema de alarme
que, uma vez acionado, tem como principal tarefa garantir a conservação dos dados
brutos relevantes ao evento.
Para o nosso caso, o sistema embarcado no módulo remoto fará a agregação para
o histórico e a publicação dos dados brutos no caso de alarme.
A distinção dessas duas categorias dos sinais a serem estudados no módulo de
análise é importante pois certos tratamentos e procedimentos só serão feitos em um tipo
ou outro como, por exemplo, a análise em frequência só será aplicada em dados brutos.
Por fim, a última condição de contorno para o módulo é como tais sinais serão
organizados.
Sinais categorizados como sendo históricos estão diretamente relacionados ao
sensor em questão e ao intervalo de interesse. Já os dados de alarme estão não apenas
7
relacionados às medidas que dispararam o evento como à localização temporal do
evento.
Como exemplo para o primeiro poderíamos estar interessados na velocidade
média ao redor da torre durante o mês de outubro, já no segundo estaríamos
interessados na velocidade do vento e a carga nos estais da torre durante uma ocorrência
no dia dez de novembro.
Casos de Uso
Levando em conta as condições de contorno expostas no item anterior,
chegamos aos casos de uso típicos de nossa aplicação. Esses casos se relacionam com
os principais atores do sistema da seguinte maneira:
Figura 2: Casos de uso principais do módulo de análise
Cada caso está detalhado no apêndice B.
8
Comunicação com o servidor
Uma vez que os casos de uso foram determinados e temos uma visão mais
específica do que a interface tem que prover ao usuário, fica claro que haverá uma
camada de comunicação com o sistema de monitoramento, de maneira mais específica
com a base de dados.
Lendo o item anterior podemos compilar as mensagens trocadas entre as partes.
• Listagem de sensores e alarmes (UC1 e UC2).
• Requisições de dados tanto para histórico quanto para alarme(UC1 e
UC2).
• Os dados históricos e brutos(UC1 e UC2).
Dentre as nossas definições internas as requisições de objetos pequenos são
feitas no esquema de RPC, ao passo que as estruturas mais complexas são partidas e
seus pedaços enviados sequencialmente. Na lista anterior os dois primeiros itens se
encaixam na categoria de elementos simples enquanto as séries de dados necessitam ser
repartidas.
O servidor, no entanto, já possui maneiras pré estabelecidas de se comunicar
com aplicações FLEX. Adobe disponibiliza uma infra-estrutura chamada LCDS para
realizar a comunicação entre uma aplicação escrita em ActionScript e um servidor em
Java. Existe suporte para quatro modalidades: serviço de mensagens, chamadas HTTP,
chamadas de objeto remoto e web services.
Logo para as listas e requisições, as três ultimas opções seriam aceitáveis
enquanto para os dados particionados o sistema de mensagens seria mais aconselhável.
As chamadas de objeto remoto foram escolhidas, pois apresentaram maior facilidade de
implementação e melhor desempenho.
A chamada remota de objeto permite que objetos de uma classe JAVA tenham
seus métodos executados a partir de código ActionScript e que o mesmo receba o valor
de retorno. Embora seja possível controlar a multiplicidade das instâncias geradas (uma
para todos os clientes, uma por cliente ou por chamada), não é possível controlar uma
instância específica, à exceção da instancia única, o que impõe uma restrição para que
se use código que não dependa do estado dessa instância.
Já serviço de mensagens gerencia a troca de informação entre uma fonte e todos
os cliente conectados a um determinado destino. Esse por sua vez pode ser dividido em
9
tópicos sendo possível formar um hierarquia de destinos, organizados por assunto. Essa
divisão evita que receptores tenham que receber e filtrar cada mensagem publicada no
sistema.
Por último, a definição das estruturas de dados envolvidas no protocolo de
cominucação entre as duas partes.
Requisições são objetos simples compostos apenas de atributos sem nenhuma
lógica específica em seus métodos além do acesso aos atributos, a única restrição que
foi feita é que exista classes recíprocas dos dois lados da comunicação. Então, se existe
um objeto que representa um pedido de dados históricos deverá haver uma versão em
ActionScript e outra em Java, podemos desta forma delegar a responsabilidade de
traduzir a informação trocada para o LCDS.
Já as listas de sensores e alarmes são representadas no formato XML dada sua
característica hierárquica e a sua condição de uso que não se limita à essa interface.
Sensores são identificados na hierarquia de acordo com seu posicionamento físico em
relação à planta (organizada em itens, componentes, subcomponentes etc). Alarmes, no
entanto, tem uma hierarquia temporal associada (ano, mês, dia, etc). Esses fragmentos
são carregados sob demanda de forma a manter o tempo de resposta aceitável.
Série de dados, por fim, usam conjuntos de objetos de valor para comunicação.
O primeiro é o cabeçalho que contém atributos ligados à identificação da série como
nome, título, sensor relacionado e outros de controle, como a quantidade de páginas de
dados. Depois do cabeçalho existe uma sequência de páginas de dados. Cada página é
composta de uma lista de amostras com um intervalo fixo, data de início e índice na
sequência global.
10
Interface de Usuário
Com os objetivos da interface e a forma de comunicação com o servidor
definidos, pode-se pensar na parte visual que irá satisfazer todas essas condições. Em
termos das diferentes perspectivas em que os dados serão visualizados, estas se
resumirão a diversos gráficos e afins (gráficos de linha, coluna, tabelas etc).
Logo o primeiro passo foi esquematizar a forma genérica que esses elementos
tomariam. Dois fatores foram considerados para essa vista.
1. Uma vez que o cliente carregar todos os dados será necessário escolher
seções de interesse dentro do intervalo total.
2. Dentro do intervalo serão aplicadas as diferentes perspectivas.
Para resolver a primeira especificação criamos uma vista que consiste de um
gráfico no tempo contendo o sinal inteiro e um elemento sobreposto a fim de indicar a
seção em destaque. Este elemento será manipulado pelo usuário para a escolha de
intervalos de interesse. A vista será chamada de janela de resumo e tentaremos atingir
um visual no estilo abaixo:
Figura 3: Esquema da janela de resumo
A segunda, por sua vez, será satisfeita através do conceito que demos o nome de
unidades de visualização. Essas vistas conterão o elemento específico para realizar a
perspectiva ou parte da mesma, ou seja, uma perspectiva pode conter uma ou mais
unidades organizadas da forma que for necessária. A unidade em si será formada pelo
11
componente que expressará os dados (gráfico, tabela, etc) e uma barra de
controle/navegação.
Figura 4: Dois exemplos de unidades de visualização
Uma vez que agora temos uma ideia mais concreta de como as perspectivas
foram formadas, podemos pensar em como organizá-las e ter uma visão geral de como a
interface inteira foi estruturada.
As vistas foram agrupadas por domínios e subdomínios onde os últimos
determinam uma perspectiva. Inicialmente os domínios serão: tempo, frequência (só
para alarme) e estatística. Os subdomínios serão: sinal no tempo, FFT, espectro
completo, histograma, distribuição normal e tabela de valores.
Nessa versão, apenas uma perspectiva será vista em um dado momento de modo
que esses conjuntos serão organizados em pilhas conforme explícito nas figuras abaixo:
Figura 5: Os domínios são organizados em uma estrutura hierárquica
12
Figura 6: Para cada domínio as análises são descendentes diretos
Para navegar entre as perspectivas usaremos os elementos descritos no esquema
a seguir:
Figura 7: Esquema da janela de análise com destaque para os elementos demudança de domínio
O que resta equacionar é a forma de navegar entre as vistas relacionadas a sinais
histórico e de alarme e como selecionar uma entrada específica dentro da árvore de
elementos.
A vista que desempenhará este papel será chamada de explorer e terá como
objetivo prover controles de navegação dentro e entre os módulos principais da área de
conteúdo, além de mostrar o usuário atual e oferecer a opção de encerrar a sessão.
Isso implica em controlar simultaneamente as duas pilhas tanto do lado de
navegação quanto do lado de conteúdo, para fazer a mudança entre análise de histórico
e alarme e dentro desses escolher quais fontes de dados e intervalos serão consideradas.
Para o gerenciamento da pilha de navegação escolhemos o componente acordeão
(classe “Accordion” no Flex) e dentro de cada elemento se encontram as árvores que
representam as configurações físicas dos sensores no caso de histórico, ou temporais no
13
caso de alarme.
A figura abaixo ilustra o componente:
Figura 8: Diagrama do componente de navegação
Por fim, podemos apresentar os componentes em uma imagem completa de
como vai ser a interface levando em conta a área de navegação e conteúdo:
14
Figura 9: Diagrama geral da interface
O próximo passo foi projetar uma arquitetura para realizar essa visão além de
permitir que novas perspectivas sejam adicionadas/retiradas com facilidade.
15
Capítulo 3
Introdução
A fim de construir softwares que tenham baixos custos de manutenção e
permitam que novas funcionalidades sejam adicionadas sem muitos transtornos, é
necessário que haja um isolamento entre o comportamento externalizado da classe e sua
implementação diante de seus colaboradores.
No caso de interfaces isso se expande para as vistas e, de maneira mais
específica, entre o que será mostrado e como será mostrado.
Desacoplar esses dois conceitos não é uma técnica nova e existem diversos
padrões de projeto que tratam desse problema, entre eles se destacam: Presentation-
abstraction-control, Model-view-controller, Model-view-presenter, dentre outros. Todas
essas soluções tem seus conjuntos particulares de vantagens e desvantagens e a escolha
deve ser baseada nas necessidades do projeto e da equipe. A abstração Model-view-
presenter, nos atende melhor e por isso será usada.
Model view presenter
Esse padrão, popularizado pelo GWT, consiste em separar os elementos de uma
interface em três categorias:
1. Modelo - se refere ao modelo de dados e os objetos de negócio que serão
manipulados pela interface.
2. Apresentação - lógica que implementa as regras de negócio.
3. Vistas - conjuntos de componentes que dão forma à interface.
Cada vista possui um apresentador associado responsável pelas regras de
negócio associadas à mesma. Essas vistas são gerenciadas por uma classe e tem seus
relacionamentos mapeados por outra, por fim elas se comunicam por meio de um
barramento de eventos.
Uma das vantagens fundamentais desse padrão é a facilidade de se testar a
camada de apresentação e a habilidade de conectar diferentes apresentadores pelo
16
barramento de eventos, garantindo independência entre eles e a habilidade de
comunicação ponto-multiponto.
Quanto à testabilidade, o fato da vista e o modelo estarem desacopladas permite
que as classes de apresentação tenham testes unitários, e sua logica fique independente
de testes funcionais, que por sua vez dependem de macros frágeis ou intervenção
humana. Infelizmente tais testes ainda se fazem necessários para as vistas e para
homologação da interface como um todo.
A capacidade de quebrar a solução em módulos independentes, uma vez que a
estrutura central esteja definida, permite desenvolvimento simultâneo em equipe.
Embora não seja uma necessidade presente, os planos de expansão futuros irão exigir tal
flexibilidade.
Figura 10: Diagrama mostrando o relacionamento entre múltiplasinstâncias do conjunto apresentador e vista
Modelo
Engloba todos os objetos de negócio e estão subdivididos em três categorias:
• Série de dados - contém todas as informações de uma fonte de dados
durante um intervalo definido.
• Unidades de processamento - objetos como filtros, modificam os dados
presentes da série (ex.: filtro passa baixa), ou máscaras que modificam
dados a serem exibidos mas a série permanece intocada (ex.: FFT).
17
• Objetos de valor - são aqueles que participam da comunicação entre
cliente e servidor encapsulando valores cujo conjunto tem um significado
específico.
Dessas categorias, a classe que se destaca é a “DataSeries” que contém todas as
informações relevantes para a análise de uma fonte de dados durante um período de
tempo. Dentre estas incluem-se nome, título, período de amostragem, marcações de
início e fim de intervalo, uma estrutura de filtros que mapeia a configuração das
unidades de processamento ligadas à série e um atributo que faz um cache da seleção
mais recente, de forma a otimizar o sistema de redesenho entre as vistas.
Dada a necessidade de gerir várias fontes de dados em abas de análise e módulos
diferentes, devemos ser capazes de identificar séries da mesma fonte em períodos ou
módulos diferentes. Para isso, utilizaremos como chaves únicas a combinação do nome
da análise, que é um identificador único na aplicação, e o nome da série que é único
dentro de uma análise. Dessa forma podemos garantir o roteamento correto de páginas
vindas do servidor e de eventos disparados em diversos pontos da interface.
Esse mapa de séries de dados será atribuído a uma classe que será responsável
por sua gestão.
A estrutura de filtros, por sua vez, é uma implementação do padrão de projeto,
Filter[1]. Atualmente a essa estrutura foram impostas algumas limitações como a
presença de apenas um filtro de um determinado tipo, ou o fato de não está aberto ao
usuário o uso de nomes para identificá-los.
Já os filtros em si são do tipo FIR com o uso da janela de Kaiser. Essa janela foi
escolhida por sua flexibilidade, o seu formato pode ser alterado através de um
parâmetro, o que permite ao usuário fazer uma especificação bem detalhada em
frequência.
A partir dessa família de funções podemos disponibilizar os seguintes filtros
para os usuários:
• Passa Baixa - frequências a partir do corte serão atenuadas.
• Passa Alta - frequências até o corte serão atenuadas.
• Passa Banda - frequências fora do intervalo entre os dois cortes serão
atenuadas.
• Rejeita Banda - frequências entre os dois cortes serão atenuadas.
18
Vista
Contém os componentes e a sua configuração. Não deve ter conhecimento dos
detalhes da apresentação ou do modelo apenas o tipo e quantidade de componentes
assim como seu posicionamento. Nossa adaptação também inclui lógica sobre efeitos e
estilos visuais.
Ela se comunica diretamente com o apresentador e seus componentes. O
apresentador, no entando, vê apenas uma interface, de forma que esta solução apresenta
vantagens na testabilidade e na flexibilidade caso um conjunto de regras de negócio
tenha de ser visualizada de uma maneira diferente.
Figura 11: O apresentador deve se relacionar com avista através de uma interface
Como exemplo, podemos imaginar a vista que descreve a janela de resumo. Essa
vista tem apenas um componente, um gráfico, que ocupa o espaço inteiro dessa vista.
Ela conhece os estilos associados a este componente e as regras relacionadas ao
movimento da ferramenta de seleção, mas não sabe o impacto que essas ações têm no
modelo e nas demais classes de apresentação, sua responsabilidade, neste caso, fica
limitada a passar o resultado dos movimentos da ferramenta para o apresentador
delegando a lógica de negócio a este.
19
Apresentador
A camada de apresentação será responsável pela lógica de negócio relacionada
às vistas da aplicação. Ela tanto recebe comandos e informação do usuário através das
vistas, como executa a lógica necessária para fazer as alterações no modelo. Por outro
lado a mesma também recebe notificações de mudança no modelo e as comunica pela
vista.
É o componente da arquitetura fundamental para que o isolamento entre a vista e
o modelo seja realizado, de forma que os elementos do modelo enxergam uma interface
de apresentação e a vista uma outra. Já a apresentação vê as interfaces dos dois lados e
se responsabiliza pela troca de informações entre eles.
Figura 12: O apresentador expõe apenas interfaces para seusinterlocutores
Essa configuração permite que as vistas possam ser trocadas sem alterações no
apresentador e que suas interações possam ser testadas com maior facilidade.
Gerente de aplicação
Um conjunto de componentes visuais, suas regras de negócio e modelo de dados
associado formam uma, e apenas uma vista. No entanto, desejamos uma aplicação
inteira e algo mais se faz necessário. Precisamos de uma estrutura que agregue e
organize todas as vistas presentes em uma estrutura coerente.
O gerente da aplicação é o elemento central dessa estrutura. Ele é responsável
20
pelas lógicas que se aplicarão à coletividade dos objetos de apresentação. Essas incluem
a lógica de inicialização, instruções de como as vistas se relacionam, credenciais do
usuário e coordenação da comunicação com a camada básica de aplicação, que pertence
ao ambiente Flash.
Assim que a aplicação é iniciada o gerente é responsável pela coleta das
credenciais do usuário, que nesse ponto já está com sua sessão validada, inicia o sistema
de aviso e executa as instruções que criam e configuram todas as vistas de acordo com
uma série de regras pré-estabelecidas.
Outras responsabilidades incluem pedir ao servidor informações sobre as
configurações das árvores de histórico e alarme, e manter uma coleção com todos os
apresentadores ativos.
Este conjunto de responsabilidades não é nealizado apenas pelo gerente, ele é
também delegado a outras classes que veremos a seguir:
• SystemListener - monitora o canal de sistema entre o servidor e o cliente.
Os principais objetivos são a manutenção de uma conexão ativa e o
recebimento de mensagens que tenham o escopo do sistema como um
todo.
• Assembler - constrói todos os apresentadores e suas vistas e os
interconecta de acordo com um conjunto de regras. Nesta implementação
o conjunto é imutável e é diretamente codificado.
O relacionamento entre essas classes foi mapeado abaixo.
Figura 13: Gerente da aplicação e seus colaboradores
21
A partir desta estrutura de classes é possível desenhar uma sequência de
inicialização para o aplicativo.
Figura 14: Diagrama de sequência para a inicialização da aplicação
Uma vez que o usuário tenha suas credenciais autenticadas, o gerente busca no
serviço de avisos o catálogo das mensagens de erro do sistema e espera uma resposta.
Independente da resposta, caso as mensagens não sejam recuperadas, o sistema usará as
já presentes no código e inicia o processo de criação e organização das vistas. Uma vez
que as últimas tenham sido adicionadas à aplicação, o processo pode ser retomado e é
feito um último pedido pelas árvores de topologia e de alarme, onde a interface é
liberada ao uso.
Transmissor de eventos, barramento e controladores
Como foi abordado no item anterior, esta aplicação terá muito mais do que um
simples conjunto vista - apresentador. Mesmo que as vistas já estejam organizadas e
interligadas na estrutura visual de forma a constituir uma aplicação, ainda não foi
explicado como esses conjuntos podem se comunicar com a infra-estrutura e entre si.
A princípio, a maneira mais intuitiva seria fazer a comunicação com chamadas
diretas de métodos, usando interfaces e outras técnicas para diminuir o acoplamento. No
entanto, esta solução não é o suficiente neste caso. O objetivo da arquitetura é promover
a facilidade de adição e remoção de vistas e estas técnicas implicariam na mudança do
22
código de apresentadores existentes na adição de novos.
Para atender ao objetivo de flexibilidade de adição e remoção de vistas foi
usada uma alternativa baseada em eventos de modo que o emissor e o receptor não se
referenciem diretamente e possamos trocar informações entre um apresentador e um
conjunto dos mesmos. Contudo, essa alternativa tem um custo e complexidade maiores,
envolvendo um maior número de chamadas de métodos e classes.
Desta forma é importante limitarmos o uso de eventos, a fim de não
comprometermos o desempenho da interface.
Continuaremos a definição da infra-estrutura de comunicação com a definição
de dois termos importantes:
• Chamadas horizontais - ocorrem entre a vista e o seu apresentador.
• Chamadas verticais - são feitas entre apresentadores e entre
apresentadores e infra-estrutura.
Chamadas horizontais são mais numerosas e tem um destinatário fixo. Logo
chamadas diretas proporcionam a melhor solução. Já as chamadas verticais apresentam
um cenário diferente: poucas chamadas envolvendo um ou mais destinatários que
provavelmente crescerão em número à medida que novas funcionalidades forem
adicionadas, o que torna a estrutura de eventos a solução mais atrativa.
A estrutura foi composta pelos elementos listados a seguir:
• SomaController - responsável pelo roteamento dos eventos do
transmissor até seus receptores registrados.
• EventBoradcaster - faz a transmissão dos eventos e se liga diretamente ao
controlador.
• ICommand - todas as classes receptoras tem que implementar essa
interface que possui os métodos usados pelo controlador para entregar
eventos.
• BaseEvent - serve de base para todos os eventos. Possui um atributo de
escopo que permite que um tipo específico possa ter diferentes grupos de
receptores.
Para o receptor basta apenas se registrar no ‘SomaController’ em um escopo
definido e ofereça uma instância de uma classe que implemente a interface
‘ICommand’ , enquanto que o transmissor apenas necessita chamar a classe
‘EventBroadcaster’ para transmitir o evento. Caso os escopos de transmissão e recepção
sejam iguais o evento chegará ao elemento receptor.
23
O apresentador que faz a transmissão se relaciona com as classes do sistema de
comunicação conforme ilustrado abaixo:
Figura 15: Eventos são transmitidos via EventBroadcaster eroteados via SomaController
Vistas Principais
Com a infra-estrutura definida podemos nos concentrar nas vistas que
implementarão as funcionalidades da aplicação.
Vista da análise de alarme
Representa a análise de uma ocorrência de alarme. Tem como objetivo prover
gráficos e ferramentas necessárias para uma análise preliminar dos dados contidos. A
fim de atender esta demanda a vista é composta de duas outras vistas que serão
detalhadas mais adiante. A implementação possui este conjunto de responsabilidades:
• Lógica de negócio para inserção de novas séries de dados.
• Fazer chamadas de requisição de dados, e lidar com as respostas.
• Coordenar as mudanças de domínio.
• Prover um escopo pelo qual todos os apresentadores possam se ligar a
fim de receber os eventos relevantes.
Com relação ao primeiro tópico, faremos referência ao caso de uso de número
dois. Nesse caso as seguintes regras são estabelecidas na seção de extensões: “Um
alarme de cada vez”, “Fontes de dados devem ser compatíveis”.
24
A fim de esclarecermos o significado destas regras teremos que levar em conta a
forma com que os alarmes são categorizados. A topologia de alarme é dividida em
tempo e tipo, onde os níveis ano, mês, dia e alarme identificam a ocorrência em relação
ao tempo, já os sensores estão organizados por tipo. Dessa forma a primeira regra citada
significa que duas ou mais fontes de dados em uma aba de alarme específica têm que
pertencer ao mesmo alarme.
A segunda regra, por sua vez, limita uma aba ao mesmo tipo, e a última impede
que uma mesma fonte de dado seja usada mais de uma vez.
Já o segundo tópico se refere às chamadas ao servidor e a recepção das páginas
de dados. Cabe ao apresentador dessa vista recebê-las e avisar, via barramento de
eventos, a sua chegada para todas as outras partes envolvidas.
Por fim, para o escopo poderemos usar o próprio identificador da vista, já que
este deve ser único na aplicação.
Embora essas responsabilidades estejam no escopo da vista e seu apresentador,
algumas delas são delegadas às classes colaboradoras a fim de podermos reusar as
lógicas nelas contidas.
• RawDataSeriesValidator - faz a validação das fontes de dados de acordo
com as regras descritas anteriormente.
• OccurrenceRequestService - comunicação do tipo RPC, faz os pedidos e
devolve as respostas.
• DataSeriesListener - escuta o canal apropriado por cabeçalhos e páginas
de dados publicados pelo servidor.
Figura 16: Apresentador do painel de análise(bruta) e seus colaboradores
A parte visual é bem simples contendo apenas os componentes que realizarão as
trocas de domínio. Essas trocas devem ser avisadas e mais uma vez o barramento de
eventos será usado.
25
Vista da análise de histórico
A segunda implementação da aba de análise tem os mesmos objetivos que a
anterior com pequenos desvios na lógica dada as diferenças entre sinais históricos e de
alarme. Estes desvios incluem diferentes regras de validação, e as janelas de tempo são
determinadas pelo usuário e não pelo sistema.
No caso de alarmes, seu início e fim estão definidos pelo serviço que o agendou,
já no caso do histórico a coleta de dados ocorre permanentemente, e uma janela de
tempo deve ser escolhida pelo usuário.
As regras de validação para esta vista só contemplam o tipo e a multiplicidade
das fontes. Dessa forma o diagrama de classes pode ser desenhado dessa maneira:
Figura 17: Apresentador do painel de análise(histórica) e seus colaboradores
Unidades de visualização
Não existem ferramentas capazes de resolver todos os problemas, dessa forma se
faz necessário disponibilizar opções adequadas a múltiplos cenários. Para esta versão as
vistas concretas serão:
• Sinal tempo - gráfico de linha com o eixo horizontal marcando tempo.
• FFT módulo - módulo da transformada discreta de Fourier.
• FFT fase - fase da transformada discreta de Fourier.
• Distribuição normal - outro gráfico de linha que mostra uma distribuição
gaussiana calculada com os parâmetros retirados da janela de análise.
• Histograma - gráfico de colunas mostrando a densidade de amostras em
intervalos distintos.
• Tabela de valores - tabela onde cada linha é composta por parâmetros
26
estatísticos calculados de cada série.
O FLEX possui uma biblioteca para apresentação de dados com formas definidas
para tratar dados em gráficos e tabelas, desta forma a solução tem suas condições de
contorno ditadas por esse conjunto de regras.
É importante saber que os dados a serem usados nestes componentes visuais
devem estar contidos em uma implementação da classe “Series” e que estas variam com
a classe de visualização a ser usada, exceto para os elementos de tabela.
De modo a acomodar as duas maneiras em uma estrutura única usaremos uma
classe para encapsular esses detalhes de implementação, assim os apresentadores podem
tratar os procedimentos de adição e remoção de séries de dados de forma uniforme.
O diagrama abaixo mostra a classe “SeriesContainer” que isola os requisitos dos
gráficos e tabelas da classe de apresentação.
Figura 18: Abstração do container de séries permite o tratamento universalpara diversos tipos de representações gráficas
O próximo requisito dos componentes gráficos é a organização das séries em um
vetor que deve ser atribuído ao apresentador. A classe “UnitDisplayPresenter” fará o
gerenciamento dos elementos que englobam os dados que serão mostrados nas unidades
de visualização, e haverá um subclasse, “GraphUnitDisplayPresenter”, que será
responsável pela lógica específica para os gráficos.
27
Esses relacionamentos são descritos na imagem a seguir:
Figura 19: Unidades de visualização e sua especialização para gráficos
Outra necessidade a se levar em conta é a inclusão de funções que processem o
sinal antes que seja desenhado. Como exemplos temos transformadas de Fourier ou
funções para o cálculo de parâmetros de estatística que não fazem parte dos dados
originais mas sua execução é um passo necessário para a formatação dos dados a serem
apresentados na vista. Esses artefatos serão chamados de máscaras. As principais serão
detalhadas a seguir:
• Decimação - para os gráficos de linha existe uma relação entre o número
de pixeis disponíveis no monitor e o espaço matemático descrito pela
abstração a ser apresentada. Quando esta relação se reduz teremos
sobreposição de pontos que afeta a legibilidade do gráfico e o
desempenho do algoritmo de desenho. A fim de reduzir esse efeito esta
máscara faz uma nova amostragem da série, eliminando pontos menos
relevantes visualmente.
• FFT Módulo / Fase - a transformada de Fourier resulta em uma sequência
de números complexos em função da frequência. A forma mais comum
de visualizar essa informação é através da quebra em dois gráficos com o
módulo em um e a fase em outro. Cada máscara recebe a sequência e
calcula o valor correspondente.
• Estatística - este conjunto de máscaras faz a transformação das séries, no
tempo, em funções estatísticas correspondentes.
Uma observação a ser feita é que nem todas as máscaras estão associadas a uma
vista, algumas delas podem estar associadas a um outro conceito. Por exemplo a
máscara que realiza o cálculo da FFT está associada ao domínio da frequência de
maneira a minimizar a quantidade de cálculos a serem realizados.
28
Por fim, deverá existir um mecanismo que controle a forma com que as vistas
atualizem as informações em respostas à mudanças no modelo. É desejável que ele evite
sequências desnecessárias de cálculo de maneira que apenas unidades visíveis
participem desta. O diagrama de sequência pode ser visto abaixo:
Figura 20: Diagrama de sequência para atualização da janela de detalhe
A sequência descrita acima pode ser disparada por três cadeias de eventos:
1. Visibilidade - Na troca de domínio ou subdomínio vistas mudam sua
visibilidade, logo aquelas que se tornam visíveis precisam ter seu
conteúdo atualizado.
2. Cache - se o cache da série de dados for invalidado as vistas devem fazer
o mesmo. Formas de invalidação do cache:
1. Estrutural - inserção / remoção de um filtro ou outra unidade de
processamento.
2. Janela - mudança do período de tempo a ser analisado.
O último componente da vista é a barra de ferramentas que possui um conjunto
de botões para ativar funcionalidades como filtros, réguas, exportar para formato de
planilha, etc. Estas funcionalidades estão agrupadas e existe um elemento “fábrica” que
tem como função construir a barra com os conjuntos relevantes para a vista.
A seguir o relacionamento entre a fábrica, a barra e seus grupos:
Figura 21: Relacionamento entre afábrica das barras de ferramentas e os
elementos construídos
29
Já que a barra faz parte da vista, cada uma delas precisa implementar uma
interface de modo a se comunicar com cada grupo de ferramentas, conforme descrito a
seguir.
Figura 22: Interface para tratar os eventos gerados por um grupo de ferramentas
Os grupos esperam uma interface específica às suas necessidades, e cada uma
delas deve ser descendente da interface de marcação “IToolBoxHandler”. Os grupos
existentes se dividem em:
• Controles gráficos - ferramentas como réguas, zoom, mira, que usam a
camada de anotação dos elementos gráficos. Essas ferramentas não
afetam o modelo, só a visualização é alterada.
• Controles de filtragem - controlam a inserção e remoção de filtros no
modelo de dados.
• Controles de comando - por enquanto disponível apenas no histórico,
contém apenas a ferramenta responsável por exportar os dados
disponíveis no intervalo de seleção para um formato de planilha.
Vista janela de resumo
Todos os dados mostrados nas unidades de visualização são um subconjunto dos
disponíveis à análise. A janela de resumo é responsável por mostrar o conjunto
completo e prover o controle que faz a seleção do intervalo de interesse.
A vista em si é muito similar às unidades de visualização contendo um gráfico,
máscaras e séries, porém não há uma barra de ferramentas, o controle de intervalo é o
único componente na camada de anotação e o eixo vertical, do gráfico, não é
desenhado.
Os dados não mudam com o modelo da análise, a não ser que novos pacotes
cheguem do servidor ou a série seja removida. Outras mudanças como inserção de
filtros não é refletida nessa vista.
30
Figura 23: Diagrama de sequência para o tratamento de novas páginas publicadasna análise
O diagrama de sequência acima mostra a mudança da vista quando uma página
de dados nova é recebida do servidor.
Existe um desvio nos caminhos dependendo da implementação do apresentador,
que definirá qual transformação será aplicada aos dados da página. Após o
processamento o gráfico é atualizado.
Explorador
A vista tem a função apenas de prover funcionalidades relacionadas à navegação
e à escolha dos dados a serem solicitados do servidor.
Tanto para séries de alarme e históricas as fontes são dispostas em uma estrutura
de árvore, essa estrutura é implementada no FLEX pelo componente “Tree” e aceita um
texto no formato XML como base para o desenho. Esse arquivo é construído pelo
servidor e provido à interface em sua carga.
Já a sincronização entre as pilhas do explorador e da vista principal é feita
através do barramento de eventos quando o primeiro intercepta o evento de mudança do
componente de navegação, “Accordion”, e o redireciona para o segundo que muda seu
estado de forma análoga.
31
Capítulo 4
Resultados
Nas próximas páginas serão apresentadas uma série de telas capturadas
mostrando as vistas principais da aplicação separadas por funcionalidades.
Alarme
Primeiro a sequência de vistas relacionadas à funcionalidade de alarme. Sinal
simulado a 1Hz.
Figura 24: Sinal de Alarme (Tensão no estai A) no domínio do tempo
Figura 25: Agora no domínio da frequência (módulo apenas)
32
Figura 26: Módulo e fase
Figura 27: Histograma
Figura 28: Distribuição normal com os valores estatísticos das amostras
33
Figura 29: Tabela de todos os valores estatísticos calculados
Figura 30: Adicionando um filtro passa banda com faixa de passagem entre0,2Hz e 0,3Hz, transição de 0,05Hz e atenuação de 10dB
Figura 31: Sinal filtrado no tempo
34
Figura 32: Resultado da filtragem na frequência
35
Histórico
Para o histórico teremos dados calculados a partir de uma janela de dez minutos.
Figura 33: Série históricas(média e mínimo) progressão temporal
Figura 34: Histograma de ambas as séries
36
Figura 35: Distribuição Normal
Figura 36: Tabela com os valores estatísticos calculados para ambas as séries
37
Objetivos
Com relação aos definidos com o cliente, todos os casos de uso foram
implementados, tanto o fluxo principal quanto as extensões. As capturas de telas no item
anterior ilustram este resultado e descrições detalhadas sobre cada caso de uso estão
disponíveis no apêndice A.
Já os definidos do lado dos desenvolvedores, a capacidade de criar módulos
independentes que possam ser adicionados e retirados, foi bem sucedida. A natureza
modular das vistas adicionado à delegação da montagem das mesmas para um
componente específico e comunicação entre os apresentadores tornou esse objetivo em
realidade. Essa mesma independência também proporciona facilidade na manutenção de
código já que funcionalidades específicas estão localizadas em um conjunto fechado de
classes.
Uma das maiores vantagens do MVP, testabilidade das regras de negócio sem o
envolvimento das vistas, não teve seu potencial realizado. Para que isso possa ser feito
se faz necessário que a linguagem da implementação tenha um suporte razoável a testes
unitários. O ActionScript tem bibliotecas escritas por usuários que tentam disponibilizar
algum tipo de infra estrutura para tais testes, mas na prática o fluxo de trabalho dos
mesmos impossiblita o seu uso em projetos maiores do que provas de conceito. Por essa
razão, nessa iteração serão mantidos os testes funcionais como forma de teste para
regras de negócio.
Limitações
Embora o componente responsável pela montagem da aplicação, referido como
Assembler, tenha uma grande contribuição para o sucesso da arquitetura, ele pode ser
melhorado. A implementação inicial não passa de um conjunto de instruções para
criação e montagem das vistas e seus apresentadores. Esse formato hard coded exige
que a aplicação inteira seja recompilada para qualquer mudança de configuração e como
instalações, geralmente, implicam em diferentes configurações, seria necessário uma
versão do Assembler para cada instalação. Além disso se torna difícil limitar
funcionalidades a grupos de usuários, assim como outras tarefas relacionadas à
segurança da aplicação.
Quanto à parte dos gráficos existem duas limitações importantes. A primeira, é a
38
especificação que apenas uma grandeza pode ser analisada no gráfico em um
determinado momento. Isso claramente vai atrapalhar o cruzamento de dados entre
carga nos estais e velocidade do vento entre outras análises.
A segunda é a classificação da barra de ferramentas para os gráficos como
componentes, e não como vistas. A ausência de um apresentador associado cria um
desvio de comportamento onde no futuro podemos ter um componente contendo regras
de negócio, o que violaria os princípios da arquitetura, além de tornar mais difícil a
adição e remoção de funcionalidades relacionadas a uma vista ou instalação específica.
Por fim a linguagem em si, ActionScript, não atende completamente às
necessidades para um desenvolvimento produtivo. Como exposto anteriormente, a parte
de testes não tem suporte nativo, o uso de depuradores implica na instalação de uma
versão distinta do Flash Player, que tem um atraso considerável em relação à versão
para o consumo, o que gera riscos para a segurança da máquina de desenvolvimento,
além de suporte inexistente para processamento paralelo.
Soluções
O Assembler pode ser refatorado para carregar dinamicamente as
funcionalidades baseado no conteúdo do banco de dados e das credenciais do usuário.
Dessa forma podemos resolver tanto a parte de segurança quanto a fragilidade do
código em termos da flexibilidade de configuração.
Já a parte gráfica pode ser melhorada a nível de design. Tanto no levantamento
da restrição de uma grandeza por unidade e a adição de suporte a múltiplos eixos, a fim
de lidar com possíveis diferenças de escala, quanto na promoção das barras de
ferramentas para vistas com seus próprios apresentadores. Essa mudança eliminaria o
risco de futuros itens violarem os princípios da arquitetura e facilitará a montagem de
outras variantes e sua inserção em vistas novas ou existentes.
O Actionscript, no entanto, não apresenta sinais de melhora no futuro próximo.
Com os navegadores líderes de mercado cobrindo mais de 80% do HTML 5, é razoável
concluir que esta será a última geração de aplicações em Actionscript no que se diz
respeito ao projeto SOMA.
39
Conclusão
O projeto foi bem sucedido em todos os principais objetivos embora haja espaço
para melhorias e expansão. Os dados estão sendo corretamente coletados e exibidos. A
arquitetura é flexível o suficiente para adição de novas vistas de maneira eficiente e
falhas encontradas são fáceis de ser isoladas e removidas.
Em um contexto profissional esse projeto foi enriquecedor dada minha falta de
experiência com arquiteturas de software em geral. Os conceitos aprendidos durante a
execução desse projeto melhoraram a qualidade dos meus designs substancialmente.
40
Bibliografia
[1] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal, Pattern-Oriented System Architecture: A System of Patterns, Wiley, 1996.
41
Apêndice A
Arquitetura do Sistema
Figura 37: Arquitetura em detalhes do SOMA Torres
42
Apêndice B
Casos de Uso
UC1: Visualizar histórico
Ator principal: Analista
Pré-requisitos: Usuário autorizado e lista de sensores disponível.
Resultado: Um conjunto de amostras das fontes selecionadas é mostrado na
perspectiva e no período que o analista desejar.
Fluxo Básico:
1. Usuário escolhe um período de tempo.
2. Usuário escolhe uma perspectiva.
3. Usuário escolhe um conjunto de sensores.
4. A interface gera um pedido ao servidor contendo os itens 1 e 3.
5. Servidor responde com um conjunto de amostras dos sensores listados no
item 3 durante o intervalo descrito pelo item 1.
6. A interface salva uma cópia em memória e mostra os sinais de acordo
com a persperctiva escolhida no item 2.
7. O procedimento pode ser repetido a fim de adicionar dados de novos
sensores.
Extensões:
1. Se um intervalo de tempo não for escolhido, o período das últimas 24h
será usado no lugar.
2. Cada painel de análise só pode agregar dados de uma determinada
grandeza. Caso mais de uma seja selecionada apenas uma será
apresentada.
3. Se a conexão com a rede em que o servidor está localizado estiver
indisponível o usuário será aconselhado a tentar novamente uma vez que
esta for restaurada.
4. Se um ou mais sensores não possuírem informação no período em
questão deve-se avisar ao usuário.
5. O intervalo de tempo em questão pode ser alterado. Nesse caso os dados
43
atuais serão removidos e substituídos pelos novos.
UC2: Visualizar alarme
Ator principal: Analista
Pré-requisitos: Usuário autorizado e lista de alarmes disponível.
Resultado: Um conjunto de amostras das fontes selecionadas é mostrado na
perspectiva que o analista desejar.
Fluxo Básico:
1. Usuário escolhe um conjunto de sensores dentro de uma entrada de
alarme.
2. Usuário escolhe uma perspectiva.
3. A interface gera e envia um pedido ao servidor com os dados presentes
no item 1.
4. Servidor responde com os dados do alarme em questão durante a duração
registrada do alarme.
5. A interface armazena uma cópia em memória e mostra os sinais de
acordo com a perspectiva escolhida no item 2.
6. O procedimento pode ser repetido a fim de adicionar dados de novos
sensores desde que estejam relacionados a essa ocorrência de alarme em
particular.
Extensões:
1. Apenas leituras de sensores pertencentes a uma instância de alarme, ou
compatíveis podem ser selecionados, os demais devem ser filtrados e o
usuário avisado.
2. Se a conexão com a rede em que o servidor está localizado estiver
indisponível o usuário será aconselhado a tentar novamente uma vez que
esta for restaurada.
3. Se um ou mais sensores não possuírem informação no período em
questão o usuário deve ser notificado.
UC3: Seleção de intervalos
Ator principal: Analista
Pré-requisitos: Usuário autorizado e um conjunto de dados está sendo
visualizado.
Resultado: Na perspectiva selecionada, mostra-se um subconjunto do sinal em
44
um intervalo de tempo específico.
Fluxo Básico:
1. Usuário seleciona um subconjunto, dado o intervalo completo carregado
na interface.
2. A perspectiva selecionada é atualizada e mostra apenas o resultado
condizente com o intervalo selecionado.
Extensões:
1. Neste caso o intervalo não pode violar os limites impostos pelos casos de
uso: UC1 e UC2
2. Uma vez que o tamanho do intervalo seja escolhido deverá ser possível
também alterar sua posição.
3. Caso haja algum tipo de filtro esteja sendo aplicado ao sinal, este
também deverá ser aplicado ao subconjunto.
UC4: Aplicar processamento
Ator principal: Analista
Pré-requisitos: Usuário autorizado e um conjunto de dados está sendo
visualizado.
Resultado: O conjunto à mostra na perspectiva selecionada é modificado pelo
processamento selecionado.
Fluxo Básico:
1. Usuário seleciona algum tipo de processamento.
2. A interface aplica o processamento a todos os sinais presentes no painel
selecionado.
3. A interface atualiza a perspectiva uma vez que o sinal resultante seja
calculado.
Extensões:
1. O processamento pode ter diferentes níveis de complexidade em relação
a sua configuração. Alguns podem exigir parâmetros e outros podem não
fazer nenhum pedido.
2. Se o processamento falhar o usuário precisa ser avisado.
UC5: Exportar dados
Ator principal: Analista
Pré-requisitos: Usuário autorizado e um conjunto de dados está sendo
45
visualizado.
Resultado: Uma planilha é gerada na máquina do usuário contendo os dados de
todos os sensores em uma análise específica.
Fluxo Básico:
1. Usuário seleciona a funcionalidade de exportação.
2. A interface agrega toda a informação no domínio do tempo em uma
planília.
3. A interface pergunta ao usuário o local onde o arquivo gerado deve ser
salvo.
4. O usuário escolhe um local confirmando sua intenção de salvá-lo.
5. A interface manda o arquivo recém gerado para a localização descrita no
item anterior.
Extensões:
1. O intervalo de tempo está associado ao escolhido no UC3.
2. Se a quantidade de amostras ultrapassar um limite superior o processo é
cancelado e o usuário deverá selecionar um conjunto menor.
3. Não haverá recuperação automática no caso de erros no sistema do lado
do usuário(capacidade de armazenamento esgotada, falhas de escrita,
etc).
46