Actividades desenvolvidas

A fase de desenho detalhado consisitiu numa grande parte do esfor¸co de todo o est´agio, principalmente devido a ter sofrido mais do que uma iterac¸c˜ao. Isto deveu- se ao facto dos requisitos iniciais n˜ao terem sido uma baseline est´avel, sendo sujeitos a altera¸c˜oes e re-interpreta¸c˜oes durante grande parte dos primeiros meses de desen- volvimento, causando altera¸c˜oes constantes no desenho detalhado do sistema.

No total foram efectuadas duas grandes itera¸c˜oes (arquitectura e mockup) que v˜ao ser descritas nesta sec¸c˜ao como uma s´o, por simplifica¸c˜ao. A arquitectura do sistema consistiu no defini¸c˜ao dos componentes de software, e consequente diagra- mas de classes para cada componente. Esta fase teve de ser precedida de uma

Cap´ıtulo 2. Trabalho Realizado 26 pequena fase de investiga¸c˜ao, que teve como objectivo confirmar as tecnologias j´a pr´e-selecionadas na proposta t´ecnica, ou mesmo analisar novas alternativas. Ap´os o desenho da arquitectura, foi criada uma mockup da MMI (Man-Machine Interface) na tecnologia escolhida (eclipse RCP). Para documentar as opera¸c˜oes idealizadas nesta mockup, foi criado um manual de opera¸c˜oes preliminar. Nas sub-sec¸c˜oes seguintes e feita uma descri¸c˜ao do trabalho realizado em cada actividade relevante. Investiga¸c˜ao de tecnologias

Esta actividade teve como objectivo decidir qual ou quais o software open source a utilizar de modo a reduzir o esfor¸co do projecto e endere¸car as necessidades levan- tadas pelos requisitos.

As ferramentas escolhidas para incluir no desenvolvimento do PEA foram as mesmas que foram inicialmente selecionadas no proposta t´ecnica, nomeadamente a biblioteca de Reporting JasperReports e de charting JFreeChart3_{. Ambos para}

serem integrados no desenvolvimento em Eclipse RCP. A plataforma eclipse fun- ciona como a framework para o desenvolvimento da interface do projeto PEA, e o JasperReports (com JFreeChart embebido) como o motor de reporting.

A principal funcionalidade do cliente PEA, consiste na gera¸c˜ao de relat´orios sobre os dados de telemetria e telecomandos da constela¸c˜ao de sat´elites Galileo. Esta funcionalidade ´e endere¸cada pelas tecnologias escolhidas jasperReports e eclipse RCP, j´a descritas anteriormente na sec¸c˜ao sobre tecnologias.

Arquitectura detalhada

Conceitos A opera¸c˜ao mais importante da interface do PEA ´e a an´alise dos dados, atrav´es da gera¸c˜ao de relat´orios. Na MMI, os operadores poder˜ao ser capazes de selecionar telemetria ou telecomandos para a gera¸c˜ao de um relat´orio que ira mostrar os dados em tabelas e/ou em gr´aficos, facilitando a an´alise.

Um relat´orio ´e constitu´ıdo por um template, uma lista de datasets e, opcional- mente, um filtro a ser aplicado a todos os datasets de um relat´orio. Estes elemen- tos j´a foram descritos anteriormente como os conceitos que estavam inicialmente definidos. No entanto, no decorrer do desenho detalhado, o que estava por definir era a rela¸c˜ao precisa que existiria entre eles. A imagem 2.10 representa esta liga¸c˜ao entre os v´arios elementos do relat´orio.

Arquitectura do cliente A arquitectura de alto n´ıvel do sistema PEA inclui um servidor e um cliente, permitindo a existˆencia de multi-utilizadores. O servidor ´e respons´avel pela gest˜ao de duas bases de dados, uma de reporting e outra de

Cap´ıtulo 2. Trabalho Realizado 27

Figura 2.10: Elementos de um relat´orio

configura¸c˜ao. O cliente ´e o principal utlizador destas bases de dados, permitindo ao operador a gest˜ao de todos os elementos que se encontram nas BD.

O cliente PEA foi tamb´em dividido em duas aplica¸c˜oes distintas: uma com interface com o utilizador, permite a gera¸c˜ao de relat´orios e configura¸c˜ao do sistema (PEA MMI client); outra apenas para ser corrida da linha de comandos, incluindo apenas a gera¸c˜ao de relat´orios (PEA command line client). A gera¸c˜ao de relat´orios em si ´e implementada no cliente, e quando o servidor necessitar de gerar relat´orios para satisfazer pedidos calendarizados, ser´a utilizado o PEA command line client embebido, para gera¸c˜ao autom´atica de relat´orios. Ambos os clientes partilham o mesmo motor e processo de reporting, mas o PEA MMI cont´em duas camadas adicionais, de interface com o utlizador e de comunica¸c˜ao com o servidor.

O conceito de cliente PEA, engloba as duas aplica¸c˜oes cliente (MMI e command line). Para referir a qualquer uma das aplica¸c˜oes espec´ıficamente, ser˜ao referidas como cliente PEA MMI, ou cliente PEA da linha de comandos.

O PEA MMI client, permite aos utilizadores definir, gerar e pr´e-visualizar re- lat´orios, assim como gerir ficheiros de configura¸c˜ao e as pr´oprias BDs do servidor (backups, restauros, apagar dados e gest˜ao de vers˜oes). De modo a obter estes pe- didos, o cliente usa os servi¸cos disponibilizados pela interface definida pelo servidor, chamada PEA-IF, e implementada usando tecnologia CORBA.

Por fim, na imagem 2.11 ´e poss´ıvel ver a rela¸c˜ao entre o servidor e o cliente atrav´es do interface PEA-IF, assim como todas as bibliotecas COTS (Commercial off-the-shelf ) usadas no PEA:

• JasperReports – O motor de reporting; • JFreeChart – O motor de gera¸cao de gr´aficos;

• ExternalWidgets – Colec¸c˜ao de widgets SWT open source a serem usadas no PEA (selec¸c˜ao de datas, pr´e-visualiza¸c˜ao de relat´orios);

Cap´ıtulo 2. Trabalho Realizado 28

Figura 2.11: Arquitectura do sistema PEA

O cliente foi desenhado tendo em conta trˆes aspectos chave: a framework eclipse RCP escolhida para a implementa¸c˜ao; o padr˜ao de desenho MVC; e o motor de reporting jasperReports.

Tanto o cliente MMI como o de linha de comandos necessitam de funcionalidades de compila¸c˜ao, processamento e gera¸c˜ao de relat´orios. Estas funcionalidades em co- mum entre os dois clientes foram identificadas e agrupadas num terceiro componente, a ser partilhado entre os dois, chamado reportDesigner.

Em resumo, o cliente PEA tem trˆes componentes: • PEA Command Line Client;

• PEA MMI Client; • Report Designer.

Estes componentes tˆem uma interface definida entre eles, para normaliza¸c˜ao das funcionalidades expostas pelo reportDesigner aos outros dois componentes. Na imagem ´e possivel ver a rela¸c˜ao entre estes componentes

Cap´ıtulo 2. Trabalho Realizado 29

Figura 2.12: Arquitectura do cliente PEA

ReportDesigner O componente reportDesigner cont´em todas as funcionalidades relacionadas com o processamento e gera¸c˜ao de relat´orios no PEA. Cont´em tamb´em a especifica¸c˜ao do modelo de dados do template e consequente processamento, tanto para a representa¸c˜ao de templates interna ao PEA, como para processamento de templates do jasperReports. S˜ao duas funcionalidades distintas que foram imple- mentadas em sub-componentes distintos, unidos por um terceiro que funciona como o core do componente:

• DesignCore - A interface que o componente reportDesigner exp˜oe para os out- ros componentes, e sua implementa¸c˜ao, encontram-se neste sub-componente. • TemplateDesign - Cont´em a especifica¸c˜ao do modelo e design do template para

todo o cliente PEA. Todos os outros componentes do cliente PEA usar˜ao esta especifica¸c˜ao para representa¸c˜ao do template em mem´oria. Contem tamb´em a implementa¸c˜ao de uma das duas opera¸c˜oes mais importante deste componente: o processamento e mapeamento de um template do PEA para um template do jasperReports.

Cap´ıtulo 2. Trabalho Realizado 30 • JasperDesign – Este sub-componente contem a segunda opera¸c˜ao de proces- samento e mapeamento de estruturas de templates, neste caso, o oposto ao sub-componente templateDesign, processa um template do jasperReports para um template do PEA.

As dependˆencias entre estes sub-componentes pode ser vista na imagem 2.13.

Figura 2.13: Arquitectura do componente Report Design

PEA MMI O cliente PEA MMI foi dividido em v´arios sub-componentes de acordo com as principais funcionalidades. Como j´a referido, as opera¸c˜oes no PEA dividem- se entre opera¸c˜oes de reporting e de configura¸c˜ao. Cada um destes grupos encontra- se implementado em sub-componentes distintos. Adicionalmente, o cliente PEA MMI necessita de comunicar com o servidor, implementando um stub de CORBA, inserido tamb´em num sub-componente pr´oprio. Por fim, a utiliza¸c˜ao da eclipse framework ´e outro dos aspectos mais relevantes, levando `a implementa¸c˜ao e con- figura¸c˜ao do workbench num sub-componente `a parte. Tirando partido da arquitec- tura eclipse, cada sub-componente foi implementado num plug-in, sendo o cliente PEA MMI final a compila¸c˜ao de todos estes plug-ins. Podemos fazer uma divis˜ao entre estes plugins, identificando aqueles que est˜ao relacionados com a GUI em si, e aqueles que fazem parte das camadas mais inferiores, e que disponibilizam servi¸cos para os plugins da interface. Os plugins respons´aveis pela implementa¸c˜ao dos ele- mentos da GUI:

• Workbench Plugin - Corresponde ao workbench da eclipse RCP, contendo as configura¸c˜oes do layout inicial.

Cap´ıtulo 2. Trabalho Realizado 31 • Configuration Plugin - Respons´avel por toda a gest˜ao de configura¸c˜ao do sis- tema PEA (ficheiros e actividades de configura¸c˜ao). Estas funcionalidades est˜ao todas compiladas numa perspectiva chamadada Configuration. Esta per- spectiva contem as defini¸c˜oes para o editor e vista de ficheiros de configura¸c˜ao. • Reporting Plugin - Respons´avel por toda a gest˜ao dos elementos de reporting do sistema, guardados na base de dados de reporting, do servidor. Suporta tamb´em as opera¸c˜oes de processamento, gera¸c˜ao, pr´e-visualiza¸c˜ao e exporta¸c˜ao de relat´orios. Estas funcionalidades foram todas compiladas numa perspectiva ´

unica chamada Reporting.

Os servi¸cos de suporte do cliente PEA MMI resumem-se `a implementa¸c˜ao da comunica¸c˜ao CORBA com o servidor:

• CORBA Services - Este sub-componente contem toda a implementa¸c˜ao e su- porte aos objectos CORBA da interface com o servidor.

Na realidade, ´e poss´ıvel retirar determinados plugins do sistema, sem retirar funcionalidades a outros plugins nem prejudicar o funcionamento do sistema em si (exemplo: retirando-se o plug-in de configura¸c˜ao, o sistema continuaria a funcionar, mas com opera¸c˜oes de reporting apenas).

A rela¸c˜ao entre todos este componentes, incluindo a plataforma eclipse RCP, pode ser vista na imagem 2.14.

PEA Command Line Client O cliente PEA da linha de comandos ´e uma aplica¸c˜ao standalone, desenhada de modo a ser executada a partir da linha de coman- dos, pelo servidor, para impress˜ao autom´atica de relat´orios. A sua implementa¸c˜ao em Java inclui uma classe principal (PEAPrintClient ) que implementa o m´etodo main, invocando o processo de gera¸cao de relat´orios implementado no componente reportDesigner, a partir de um determinado template e datasets.

Integra¸c˜ao do JasperReports O processo de gera¸c˜ao de relat´orios, no PEA, utiliza os mesmos conceitos do jasperReports, j´a introduzidos: parsing, compila¸c˜ao, preenchimento e exporta¸c˜ao.

A diferen¸ca entre o processo no jasperReports, e aquele que foi adoptado no PEA, ´e o template, e a fonte dos dados utilizados no preenchimento do relat´orio. O cliente PEA acede aos templates e dados atrav´es da interface PEA-IF, descarregando-os em formato XML. Os templates em XML guardados no servidor, ter˜ao o formato definido pelo jasperReports, tirando partido de uma ampla especifica¸c˜ao de elemen- tos de um relat´orio. O processo do PEA ´e ent˜ao uma adapta¸c˜ao do processo do jasperReports, `as necessidades do PEA, como se pode ver na imagem 2.15.

Cap´ıtulo 2. Trabalho Realizado 32

Figura 2.14: Arquitectura do componente PEA MMI

A diferen¸ca principal existe em tempo de preenchimento: os dados utilizados para preencher o template, s˜ao descarregados pelo PEA-IF em formato XML, contendo a lista de datasets a inserir, todos concatenados num s´o ficheiro.

O template pode ser descarregado do servidor ou criado atrav´es do editor de tem- plates do cliente PEA MMI. Todo este processo ´e utilizado para todas as opera¸c˜oes sobre templates e pedidos de relat´orios. Quando um template ´e criado, ou aberto

Cap´ıtulo 2. Trabalho Realizado 33

Figura 2.15: Processo de gera¸c˜ao de relat´orios adaptado ao PEA

para edi¸c˜ao, tem de ser convertido pelo motor de reporting do PEA, entre os for- matos de jasperReports, e o pr´oprio formato interno ao PEA. Se o template ou relat´orio for pr´e-visualizado, ter´a de ser preenchido, ou com dados de teste, ou com os dados finais, respectivamente, usando o mesmo processo. Quando um template ´e preenchido, ´e obtida uma instˆancia do objecto JasperPrint, que permite a sua pre-visualiza¸c˜ao ou exporta¸c˜ao. Para mostrar o template ou relat´orio preenchido na MMI, ´e utilisada uma widget de SWT externa (SWT JasperViewer).

Na imagem 2.16 s˜ao apresentadas as opera¸c˜oes de gest˜ao de templates e cria¸c˜ao de relat´orios, divididas em trˆes camadas: comunica¸c˜ao, processamento e apresenta¸c˜ao. Na camada de comunica¸c˜ao encontramos a implementa¸c˜ao do PEA-IF, respons´avel pelas as opera¸c˜oes de download/upload dos templates e datasets em XML. Na ca- mada de processamento encontram-se o motor de reporting do jasperReports e do PEA, enquanto que na camada de apresenta¸c˜ao encontramos os componentes de- senvolvidos em eclipse RCP para apresenta¸c˜ao e gestao de templates e relat´orios:

Cap´ıtulo 2. Trabalho Realizado 34

Figura 2.16: Camadas do processo de gera¸c˜ao de relat´orios

editores de templates e relat´orios e vistas de templates e relat´orios autom´aticos. Mockup da MMI

A mockup realizada no desenho detalhado definiu a primeira vers˜ao da interface do PEA que mais tarde iria ser melhorada para a vers˜ao prot´otipo.

No entanto, as principais ideias concretizadas nesta mockup, mantiveram-se at´e `

a vers˜ao final: a interface cont´em duas perspectivas, cada uma relativa a um dos dois grupos de funcionalidades que existem no PEA: configura¸c˜ao e reporting.

A perspectiva de reporting como constru´ıda para a mockup pode ser visualizada na imagem 2.17.

A perspectiva de reporting cont´em uma ´area para editores abertos (poder˜ao ser v´arios), ao centro e uma vista para cada elemento de reporting: templates, datasets, filtros e schedules (relat´orios a serem gerados no futuro), `a direita; adicionalmente aos menus e toolbars, em cima.

Ambas as perspectivas no cliente PEA MMI, foram desenhadas de acordo com um documento de guidelines elaborado para as aplica¸c˜oes com MMIs, da miss˜ao Galileo. Uma das guidelines diz respeito ao layout dos displays na MMI. Na imagem 2.18 encontra-se um diagrama desta estrutura.

A layout da MMI do PEA n˜ao utiliza a ´area de alerta, porque ´e apenas uma ferramenta de reporting, e como tal, n˜ao existem dados de aviso ao utilizador. Toda as outras ´areas foram adaptadas ao PEA usando os elementos da plataforma eclipse RCP.

• Menu/Toolbar Area - MenuBar e toolbar do Eclipse RCP.

• Editor Area - O layout das duas perspectivas foi configurado de modo a abrir editores nesta ´area.

• Status View - No PEA n˜ao existe a no¸c˜ao de status, com a excep¸c˜ao dos pedidos de relat´orios a serem gerados autom´aticamente (schedules). A vista

Cap´ıtulo 2. Trabalho Realizado 35

Figura 2.17: PEA Mockup

Figura 2.18: Layout de uma MMI Galileo

de schedules foi colocada nesta zona. Na perspectiva de configura¸c˜ao esta vista n˜ao existe, visto ser relativa `a perspectiva de reporting.

Cap´ıtulo 2. Trabalho Realizado 36 configura¸c˜ao, e que permitem acesso `as opera¸c˜oes do seu ciclo de vida (editar, apagar) foram colocadas nesta ´area, tanto na perspectiva de reporting como na perspectiva de configura¸c˜ao, com a diferen¸ca que, nesta ´ultima, pelo facto de n˜ao existir status view, ocupa ambas as views.

• Alert View - N˜ao foi implementada no PEA.