Análise da performance da constelação de satélites Galileo

(1)

Universidade de Lisboa

Faculdade de Ciˆencias

Departamento de Inform´

atica

An´

alise da performance da constela¸

c˜

ao de

sat´

elites Galileo

projecto realizado na

Critical Software S.A.

por

Artur C´

esar Rodrigues Ribeiro

Mestrado em Engenharia Inform´

atica

(Vers˜

ao P´

ublica)

(2)

(3)

Universidade de Lisboa

Faculdade de Ciˆencias

Departamento de Inform´

atica

An´

alise da performance da constela¸

c˜

ao de

sat´

elites Galileo

projecto realizado na

Critical Software S.A.

por

Artur C´

esar Rodrigues Ribeiro

Projecto orientado por Fl´avio Moreira e co-orientado pelo Prof. Thibault Langlois

Mestrado em Engenharia Inform´

atica

(4)

(5)

Declara¸

c˜

ao

Artur César Rodrigues Ribeiro, aluno no 28301 da Faculdade de Ciências da Universidade de Lisboa, declara ceder os seus direitos de cópia sobre o seu Relatório do Projecto em Engenharia Informática, intitulado ”Análise da performance da con-stela¸cão de satélites Galileo”, realizado no ano lectivo de 2006/2007 à Faculdade de Ciências da Universidade de Lisboa para o efeito de arquivo e consulta nas suas bibliotecas e publica¸cão do mesmo em formato electrónico na Internet.

FCUL, 17 de Julho de 2007

Flávio Moreira, supervisor do projecto de Artur Ribeiro, aluno da Faculdade de Ciências da Universidade de Lisboa, declara concordar com a divulga¸cão do Re-latório do Projecto em Engenharia Informática, intitulado ”Análise da performance da constela¸cão de satélites Galileo”.

(6)

(7)

Resumo

Os sistemas de navega¸cão por satélite, norte-americano e russo, o NAVSTAR GPS e o GLONASS respectivamente, foram concebidos para fins militares, apesar de neste momento a sua utiliza¸cão para fins civis já estar licenciada. O sistema norte-americano foi o mais divulgado para fins civis, mas a possibilidade de re-codifica¸cão do sinal, a qualquer altura, (já aconteceu durante a guerra do Golfo), deixam a Eu-ropa dependente da vontade do governo norte-americano, assim como impossibilita a implementa¸cão de aplica¸cões cr´ıticas que utilizem navega¸cão por satélite, como por exemplo levantar e aterrar um avião sem piloto.

O sistema de posicionamento Galileo, a ser desenvolvido pela Agência Espacial Europeia, constitui a solu¸cão para a dependência europeia no sistema de navega¸cão norte-americano. O sistema engloba o lan¸camento de 30 satélites, de órbita circular intermédia, que irão disponibilizar uma precisão superior ao actual sistema NAVS-TAR (Galileo terá precisão de 1 metro, GPS tem margem de erro de 10 a 20 metros), alargando as possibilidades de aplica¸cão prática.

O projecto do estágio PEA (Performance Evaluation and Analysis - Análise da performance da constela¸cão de satélites) encontra-se inserido no âmbito do projecto Galileo, especificamente, do sistema de controle em terra. Consiste no desenho de-talhado, produ¸cão e valida¸cão de uma ferramenta de reporting, de suporte à análise da performance da constela¸cão de satélites.

PALAVRAS-CHAVE:

ESA, Galileo, An´alise, Reporting, Eclipse RCP

(8)

(9)

Abstract

The satelite navigation systems north-american and russian, NAVSTAR GPS and GLONASS, respectively, were created for military purposes, although they are also currently being used on civilian applications. The NAVSTAR system was the most divulged for civilian purposes, but the possibility of signal re-codification at any time (already happened during Golf war), cause Europe to be dependent of the north-american government will, as it does not allow any critical application implementation.

The Galileo navigation system, being developed by ESA (European Space Agency), is the solution for this problem as it will allow Europe to have its own independent navigation system and to begin further development of advanced navigation sys-tems, such that it will be possible in the future to lift of and land a plane, without a pilot’s help. The Galileo system is composed of a satelite constelation comprising 30 satelites, commanded and controled by several ground stations with costumized software.

The intership project’s Performance Evaluation and Analysis will be part of the Galileo ground segment. It consists on the implementation of a reporting tool that will support the performance analysis of the Galieleo spacecraft constellation. Specifically, the internship includes the Detail Design, Production and Validation of such system.

KEYWORDS:

ESA, Galileo, Analysis, Reporting, Eclipse RCP

(10)

(11)

Conte´

udo

Lista de Figuras viii

Lista de Tabelas x 1 Introdu¸cão 1 1.1 Objectivo . . . 1 1.2 Audiência . . . 1 1.3 Acrónimos . . . 1 1.4 Institui¸cão de Acolhimento . . . 2 1.4.1 Missão . . . 2

1.4.2 Areas de competˆ´ encia . . . 2

1.5 Organiza¸c˜ao do documento . . . 4

2 Trabalho Realizado 5 2.1 Descri¸c˜ao do projecto . . . 5

2.1.1 Projecto Galileo . . . 5

2.1.2 Galileo Software Standard . . . 8

2.1.3 Requisitos de software . . . 10

2.2 Tecnologias . . . 13

2.2.1 Eclipse RCP . . . 13

2.2.2 JasperReports . . . 15

2.3 Plano detalhado do est´agio . . . 18

2.3.1 Plano previsto . . . 18

2.3.2 Calend´ario final . . . 18

2.3.3 Resumo dos documentos produzidos . . . 20

2.4 Processos e ferramentas . . . 22

2.4.1 Metodologias . . . 22

2.4.2 Ferramentas utilizadas . . . 24

2.5 Desenho Detalhado . . . 25

2.5.1 Input ao Desenho Detalhado . . . 25

2.5.2 Actividades desenvolvidas . . . 25

2.5.3 Output do Desenho Detalhado . . . 36 v

(12)

2.6 Implementa¸cão . . . 38 2.6.1 Input à Implementa¸cão . . . 38 2.6.2 Actividades desenvolvidas . . . 38 2.6.3 Output da Implementa¸cão . . . 46 2.7 Valida¸cão . . . 47 2.7.1 Input à Valida¸cão . . . 47 2.7.2 Actividades desenvolvidas . . . 47 2.7.3 Output da Valida¸cão . . . 49 3 Conclusão 50

A PEA Software Detail Design Document (SDD) 52 B PEA Software Operations Manual (SOM) 53 C PEA Software Validation Test Specification (SVTS) 54 D PEA Software Test Report (STR) 55

Bibliografia 56

(13)

(14)

Lista de Figuras

2.1 Galileo Segments . . . 6

2.2 Spacecraft Constellation Control Facility (SCCF) . . . 7

2.3 Performance Evaluation and Analysis (SCCF-PEA) . . . 8

2.4 Rela¸c˜ao entre as diferentes revis˜oes e componentes . . . 10

2.5 Conteúdos de um relatório: telemetria em formato tabular e gráfico . 12 2.6 Processo de gera¸cão de relatórios . . . 16

2.7 Plano previsto das tarefas de est´agio . . . 19

2.8 Calend´ario final das tarefas de est´agio . . . 20

2.9 Esfor¸co final das tarefas de est´agio . . . 21

2.10 Elementos de um relat´orio . . . 27

2.11 Arquitectura do sistema PEA . . . 28

2.12 Arquitectura do cliente PEA . . . 29

2.13 Arquitectura do componente Report Design . . . 30

2.14 Arquitectura do componente PEA MMI . . . 32

2.15 Processo de gera¸c˜ao de relat´orios adaptado ao PEA . . . 33

2.16 Camadas do processo de gera¸c˜ao de relat´orios . . . 34

2.17 PEA Mockup . . . 35

2.18 Layout de uma MMI Galileo . . . 35

2.19 Elementos do Template . . . 37

2.20 ReportDesigner - DesignCore . . . 40

2.21 PEA MMI - Configuration . . . 41

2.22 PEA MMI - Editor de relat´orios . . . 42

2.23 PEA MMI - Reporting . . . 43

2.24 PEA MMI - Servi¸co CORBA . . . 44

(15)

(16)

Lista de Tabelas

1.1 Lista de Acr´onimos . . . 1

2.1 Ciclos de vida: Reviews e fases de alto n´ıvel . . . 9

2.2 Calend´ario final de est´agio . . . 19

2.3 Documentos realizados . . . 21

2.4 Ferramentas . . . 24

2.5 Plano inicial de est´agio . . . 46

(17)

(18)

Cap´ıtulo 1

Introdu¸

c˜

ao

1.1 Objectivo

Este relatório pretende apresentar todo o trabalho realizado durante o estágio intit-ulado ”Análise da Performance da constela¸cão de Satélites Galileo”(este documento é a versão pública: não contém os documentos produzidos no estágio em anexo).

1.2 Audiˆ

encia

O relatório destina-se ao docente responsável do Projecto de Engenharia Informática e aos orientadores da empresa e da faculdade.

1.3 Acr´

onimos

A tabela 1.1 contém a lista de todos os acrónimos usados no relatório. CSW Critical Software, S.A.

ESA European Space Agency GSWS Galileo Software Standards GCS Ground Control Segment

SCCF Spacecraft Constellation Control Facility MMI Man Machine Interface

MIB Manegement Information Base MVC Model View Controller

PEA Performance Evaluation and Analysis RCP Rich Client Platform

TM Telemetry TC Telecommand

UML Unified Modelling Language Tabela 1.1: Lista de Acr´onimos

(19)

Cap´ıtulo 1. Introdu¸c˜ao 2

1.4 Institui¸

c˜

ao de Acolhimento

1.4.1 Miss˜

ao

A missão da Critical Software é fornecer solu¸cões, servi¸cos e tecnologias fiáveis e inovadoras, para sistemas de informa¸cão cr´ıticos em empresas e organiza¸cões de diversos sectores, respondendo às necessidades de clientes de diversos mercados, designadamente, telecomunica¸cões, sector público, indústria, sector aeroespacial e defesa. Presta também servi¸cos de consultoria e auditoria nas áreas das Tecnologias de Informa¸cão. A empresa foi fundada em 1998 e emprega cerca de 200 pessoas, em escritórios localizados em Coimbra, Lisboa e Porto, em San Jose na Califórnia e em Southampton no Reino Unido.

O sucesso da CSW reside na utiliza¸cão de n´ıveis elevados de qualidade e inova¸cão tecnológica como agentes na introdu¸cão de vantagens competitivas nos sistemas de informa¸cão e no negócio dos clientes e parceiros. O resultado prático é um portofólio sólido de solu¸cões de elevada qualidade e conteúdo inovador, desenvolvidas dentro dos prazos e or¸camentos com n´ıvel crescente de parcerias estratégicas com clientes de grande dimensão a n´ıvel nacional e internacional.

1.4.2 Areas de competˆ

´

encia

As áreas de competência permitem à empresa responder com flexibilidade aos de-safios mais complexos dos clientes e parceiros. A empresa está dividida de uma forma estratégica em quatros áreas de competência:

• Enterprise Application Integration & Databases (EAI&DB); • Redes e Comunica¸c˜oes;

• Sistema de Informa¸c˜ao Fabris ou MES; • Confiabilidade;

• Computa¸c˜ao de Alto Desempenho ou HPC; • Software de Ground Segment.

A área de EAI&DB lida com problemas complexos de integra¸cão e desenvolvimento de aplica¸cões, aplica¸cões em camadas múltiplas, aplica¸cões orientadas à internet, desenho e optimiza¸cão de bases de dados, data warehouse e data mining e solu¸cões de integra¸cão shop-flor utilizando para o efeito tecnologias abertas, recorrendo a boas práticas recomendadas pelas normas internacionais e investigando o estado de arte.

(20)

Cap´ıtulo 1. Introdu¸cão 3 A área de Redes e Comunica¸cões centra-se no planeamento, desenho e desenvolvi-mento de solu¸cões de comunica¸cão. A comunica¸cão eficiente é um ponto essencial nas organiza¸cões, sendo os sistemas de informa¸cão e as redes cada vez mais, tratados de uma forma integrada. Deste modo, existe uma grande necessidade de integra¸cão e media¸cão de sistemas, complementada pela necessidade de gerir, integrar e interligar múltiplos elementos da rede, protocolos e sistemas.

A área de Sistemas de Informa¸cão Fabris centra-se nos requisitos dos sistemas de informa¸cão de processos industriais e da sua integra¸cão com as linhas de produ¸cão. Os engenheiros desta área configuram solu¸cões que respondem aos requisitos es-pec´ıficos dos diferentes processos industriais, desenvolvendo solu¸cões numa plataforma comum, com componentes pré-desenvolvidos, validados e módulos testados.

A área de Confiabilidade centra-se na preocupa¸cão crescente sobre os aspectos de confiabilidade de sistemas de software e computadores. Actualmente, esta é uma questão vital devido à crescente importância do software na vida quotidiana e ao seu papel de controlo de processos e aplica¸cões empresariais e cr´ıticas. A área de Confiabilidade abrange competências em técnicas de RAMS (Reliability, Availability, Maintainability and Safety), FDIR (Fault Detection, Isolation and Recovery) e ISVV (Independent Software Verification and Validation). Em particular, como fornece-dora de ISVV, a empresa faz verifica¸cão de software e servi¸cos de valida¸cão para vários mercados como o aeroespacial, automóvel, defesa, saúde, telecomunica¸cões e finan¸cas. A sua posi¸cão independente permite à CSW ter um estatuto único neste mercado.

A área de Computa¸cão de Alto Desempenho (HPC) dedica-se à resolu¸cão de problemas de desempenho dos Sistemas de Informa¸cão de empresas e organiza¸cões. Nos servi¸cos estão inclu´ıdos a optimiza¸cão, afina¸cão e parameteriza¸cão de processos, desenvolvimento de aplica¸cões paralelas e paraleliza¸cão de código. Os problemas solucionados abrangem o controlo de grandes volumes de dados, processos de escala (mais dados, mesmo tempo), acelera¸cão de processos (mesmos dados, menos tempo) e a implementa¸cão de processos complexos e algoritmos.

A área de Software de Ground Segment fornece solu¸cões para o sector das comu-nica¸cões e User Segment, sobretudo para os sectores espacial, aeronáutico e defesa. Especificamente é uma área com competências em processamento de dados, moni-toriza¸cão e control concorrente; controlo de missão; e recentemente, experiência em Sistemas Operativos espec´ıficos de Controlo de missão (SCOS-2000), da Agência Espacial Europeia (ESA - European Space Agency), desenvolvendo projectos para algumas das mais importantes empresas e agências do sector espacial incluindo a Acaltel Space, EADS Astrium, EADS Casa Espacio, entre outras. E uma ´` area onde a Critical Software faz também investimento em investiga¸cão e desenvolvi-mento de aplica¸cões relacionadas com infraestruturas de monitoriza¸cao de controlo.

(21)

Cap´ıtulo 1. Introdu¸cão 4 Alguns dos projectos de referência de interesse incluem o desenvolvimento de uma plataforma de GIS (Sistema de Informa¸cão Geográfica, do inglês Geographic Infor-mation System); um sistema de monitoriza¸cão e controle de uma rede de sensores; e um sistema de simula¸cão de UAVs (Ve´ıculo aéreo não tripulado, do inglês Unmanned Aerial Vehicle). É nesta área que o estágio se enquadra.

1.5 Organiza¸

c˜

ao do documento

Este documento est´a organizado da seguinte forma:

• Captulo 1 - Introdu¸cão, ao documento, incluindo uma descri¸cão sobre a institui¸cão de acolhimento.

• Captulo 2 - Trabalho Realizado, descri¸cão de todo o estágio, projecto, tecnologias, metodologias, ferramentas e plano detalhado, incluindo uma de-scri¸cão detalhada de cada fase:

Desenho Detalhado, desenho e arquitectura do software.

Implementa¸cão, implementa¸cão, métricas e manual de opera¸cões do soft-ware.

Valida¸c˜ao, especifica¸c˜ao de testes e registo de falhas.

• Captulo 3 - Conclusão, contém um resumo e comentários sobre o Projecto, terminando com um visão global do futuro do projecto.

(22)

Cap´ıtulo 2

Trabalho Realizado

Este cap´ıtulo descreve detalhadamente o estágio realizado, come¸cando por uma de-scri¸cão do Projecto PEA e introdu¸cão às tecnologias e conceitos teóricos envolvidos, seguida da apresenta¸cão dos métodos e ferramentas utilizados na execu¸cão das tare-fas.

2.1 Descri¸

c˜

ao do projecto

O projecto PEA enquadra-se na missão Galileo da ESA. Nesta seçcão é feita uma introdu¸cão ao contexto, com a descri¸cão da missão, os componentes, os processos e os standards. Por fim, é apresentado um resumo dos objectivos e requisitos do PEA, que constituiram o ponto de partida para o estágio.

2.1.1 Projecto Galileo

O estágio insere-se no âmbito da missão Galileo, da ESA. Consiste na implementa¸cão de um sistema global de posicionamento, com o lan¸camento de 30 satélites e a gestão dos mesmos a partir da Terra. Particularmente, a missão divide-se em três segmentos:

• Space Segment, o segmento que inclui os sat´elites;

• Ground Mission Segment (GMS) responsável pelo controlo da navega¸cão; • Ground Control Segment (GCS) responsável pela manuten¸cão da constela¸cão

de sat´elites e onde se insere o projecto.

Os trˆes segmentos referidos podem ser visualizados na figura 2.1.

O GCS encontra-se dividido em várias Facilities, uma delas, o Spacecraft Con-stellation Control Facility (SCCF) que disponibiliza monitoriza¸cão em tempo real da constela¸cão de satélites, através dos dados recebidos e enviados: respectivamente Telemetria (TM) e Telecomandos (TC).

(23)

Cap´ıtulo 2. Trabalho Realizado 6

Figura 2.1: Galileo Segments

Telemetria é a tecnologia usada para obten¸cão e processamento de dados à distância, para sistemas complexos, como é o caso da rede de satélites Galileo, permitindo monitoriza¸cão automática, gestão de alertas e grava¸cão dos dados rece-bidos para opera¸cões eficientes e seguras. Tipicamente diz respeito a comunica¸cão sem fios (utilizando frequência rádio). A Agência Espacial Europeia usa o sistem de telemetria / telecomandos para enviar e recolher dados dos satélites. A telemetria é também uma tecnologia vital na fase de desenvolvimento de misseis, satélites e ve´ıculos aéreos, tendo em conta que o sistema pode ser destru´ıdo depois ou durante o teste. Os parâmetros de telemetria podem então ser usados pelos engenheiros para analisar e melhorar a performance do sistema. Sem telemetria estes dados poderiam não estar dispon´ıveis. Os telecomandos consistem no envio de instru¸cões de controle aos satélites, provenientes do segmento Galileo em terra, precisamente a opera¸cão inversa à recep¸cão de telemetria.

As v´arias funcionalidades do SCCF incluem:

• Processamente TM&TC: gestão da transmissão e recep¸cão dos TM e TC; • Automa¸cão: recep¸cão e processamento automático dos dados TM e TC; • Monitoriza¸cão do progresso das opera¸cões: monitoriza¸cão on-line das opera¸cões

realizadas pelos sat´elites;

• Manuten¸cão do software on-board : gestão do software on-board ; • Histórico das opera¸cões: salvaguarda de todos os TM e TC recebidos;

• An´alise da Performance (Performance Evaluation and Analysis – PEA) – onde se insere o est´agio, consiste numa ferramenta off-line capaz de produzir

(24)

re-Cap´ıtulo 2. Trabalho Realizado 7 latórios para análise dos dados TM e TC enviados e recebidos da constela¸cão de satélites.

Um esquema dos elementos do SCCF e sua contextualiza¸c˜ao pode ser visualizado na figura 2.2.

Figura 2.2: Spacecraft Constellation Control Facility (SCCF)

Particularmente o elemento PEA do SCCF é responsável pela análise da perfor-mance dos TM e TC. Para tal, este elemento deverá permitir a gera¸cão de relatórios, por pedido ou automaticamente, sobre os dados guardados no histórico. O PEA consiste numa arquitectura cliente/servidor, sendo o servidor responsável por vários componentes:

• Interface com os outros componentes;

• Manuten¸cão de uma série de bases de dados que irão guardar uma cópia de todo o histórico TM e TC da constela¸cão de satélites;

• O servidor ainda ir´a gerar relat´orios automaticamente.

O cliente PEA é apenas responsável pela interface com o utilizador, disponibilizando as funcionalidades: gestão dos relatórios e de configura¸cão das defini¸cões do próprio PEA. Na figura 2.3 encontram-se a arquitectura do PEA, onde se podem identificar os vários componentes. O âmbito do estágio “Análise da performance da constela¸cão de satélites Galileo” é o desenho, implementa¸cão e valida¸cão do cliente PEA.

(25)

Figura 2.3: Performance Evaluation and Analysis (SCCF-PEA)

2.1.2 Galileo Software Standard

O standard de desenvolvimento de software do Galileo (GSWS), define procedimen-tos a serem seguidos pela engenharia, product assurance e gestão de configura¸cões de software applicáveis a todos os produtos a serem produzidos no âmbito do Projecto Galileo, incluindo assim, o projecto de estágio.

O standard define detalhadamente todas as opera¸cões a diferentes n´ıveis, envolvi-das no processo de desenvolvimento de software. Descreve todo o ciclo de vida de cada projecto. Os processos de revisão encontram-se também detalhados no GSWS, assim como cada fase do ciclo de vida de um projecto, e que respectivas actividades de engenheaia são aplicáveis a cada fase. Isto inclui especifica¸cões de gestão de configura¸cões, qualidade, verifica¸cão e valida¸cão. Por fim, o GSWS inclui templates para todos os documentos necessários em todas as fases de desenvolvimento.

Existe, adicionalmente uma classifica¸cão atribu´ıda a cada producto de Software, de acordo com o seu n´ıvel de criticalidade: DAL (Development Assurance Level ). Esta classifica¸cão pode ir de A e E, e decidir que tecnologias, ciclos de vida, e aplicabilidade do standard, serão necessários.

O projecto PEA foi classificado como DAL-E, ou seja, de criticalidade baixa. No ˆ

ambito deste relat´orio, interessa detalhar o processo de desenvolvimento de software gen´erico especificado pelo GSWS, e o adoptado para o projecto de acordo com o n´ıvel DAL-E.

(26)

Cap´ıtulo 2. Trabalho Realizado 9 Ciclos de vida

Seja qual for o ciclo de vida selecionado para qualquer projecto, este encontra-se sempre inserido num ciclo de mais alto-n´ıvel, do componente onde se insere. A tabela 2.1 introduz todas as revisões de um ciclo genérico e respectiva correspondência com as fases de desenvolvimento, de alto n´ıvel.

Tabela 2.1: Ciclos de vida: Reviews e fases de alto n´ıvel

A rela¸cão entre as revisões de cada componente, facility e segmento, pode ser vista na imagem 2.4, relativamente aos elementos do GCS, como é o caso do PEA. As fases de revisão que se encontram na imagem, também estão mapeadas para as fases de alto n´ıvel em formato tabular: 2.1. Um ciclo de vida define as fases e a actividades de um projecto de software, desde o concep¸cão até à entrega. Especifica as rela¸cões entre as fases do projecto, o modo de transi¸cão, comunica¸cão, milestones, baselines, revisões e entregas.

Especificamente no Galileo, as fases adoptadas para um ciclo de vida gen´erico sao as seguintes:

• Planeamento; • Especifica¸c˜ao; • Desenho

(27)

Figura 2.4: Rela¸cão entre as diferentes revisões e componentes • Implementa¸cão

• Integra¸cão e Valida¸cão técnica • Valida¸cão dos requisitos • Aceita¸cão

• Opera¸c˜ao • Manuten¸c˜ao

No caso do projecto PEA, classificado como DAL-E, onde não se encontram grandes restri¸cões relativamente à escolha do ciclo de vida (pode ser em cascata ou incre-mental), foi selecionado o ciclo de vida em cascata, incluindo todas estas fases.

O plano de estágio inclu´ıa a fase de Desenho, implementa¸cão e valida¸cão, mas como será descrito mais a frente na seçcão sobre o Plano de estágio, a fase oficial do projecto, durante o periodo de estágio, foi o Desenho. No entanto apesar de não se enquandrar no contexto oficial do projecto o estágio respeitou o plano inicial, concluindo a implementa¸cão de um protótipo do software, e uma primeira fase de valida¸cão, seguindo sempre o GSWS.

2.1.3 Requisitos de software

Como já foi referido, o objectivo do projecto PEA, consiste na implementa¸cão de uma ferramenta que permita a análise da performance dos satélites da constela¸cão Galileo. Especificamante esta ferramenta deve ser capaz de produzir relatórios que permitam esta análise, contendo, num caso limite, qualquer tipo de dados (TM ou TC) dos satélites, de per´ıodos que podem ascender a 20 anos. Resumindo o conteúdo dos requisitos de software do PEA, existem três funcionalidades principais:

(28)

Cap´ıtulo 2. Trabalho Realizado 11 1. Relatórios automáticos - gerados numa data no futuro, com dados pre-definidos; 2. Relatórios configuráveis - separar conteúdo de apresenta¸cão, e tornar ambas

as defini¸c˜oes persistentes;

3. Suporte para diferentes ouputs de relat´orio - relat´orios em formatos de ficheiros diferentes.

Os relatórios deverão poder ser gerados automaticamente segundo periodicidades pre-definidas, ou gerados manualmente para casos especiais. Independentemente do tipo de gera¸cão, os relatórios deverão ser produzidos de forma a poderem ser impressos, mesmo que não sejam usados como tal.

Os operadores que utilizarão o PEA deverão poder configurar os relatórios, de modo a poder reutilizar elementos dos relatórios e facilitar a própria tarefa de criar um relatório sobre determinados dados TM ou TC. Esta flexibilidade encontra-se definida nos requisitos do projecto, onde é especificado a necessidade de imple-menta¸cão de elementos com caracteristicas e fun¸cões distintas, que juntos poderão constituir um relatório. Um resumo destes elementos, como especificado pelos req-uisitos econtra-se descrito de seguida:

• Template - Consiste na separa¸cão clara daquilo que será o estilo e layout do relatório. Todos os elementos de conteúdo estático e defini¸cões de estilo deverão estar definidos no template (font, cor, tamanhos, etc.);

• Dataset - Representa o defini¸cão dos dados a serem inseridos num determinado relatório (contém o tempo, e especifica¸cões sobre os dados: TM ou TC); • Filtro - Deverá ser poss´ıvel filtrar os dados de TM ou TC a inserir num

re-latório, tendo em conta que estes poderão ter uma dimensão considerável; • Relatório - O produto final dos 3 elementos descritos acima. Um dataset será

filtrado com um filtro, e utilizado para prencher um relat´orio de acordo com os estilos e conte´udos especificados no Template. Pode ser visto na imagem 2.5.

O objectivo de ter todos estes elementos especificados como requisitos, pretende fornecer uma flexibilidade aos operadores responsáveis pela cria¸cão de relatórios. De-verá ser poss´ıvel criar vários tipos de templates, datasets e filtros, guardá-los, reuti-lizá-los e combiná-los entre si para a produ¸cão de relatórios espec´ıficos ou periódicos. Adicionalmente o PEA deverá implementar procedimentos que permitam expor-tar um relatório gerado para diferentes formatos, em ficheiros num disco local, como alternativa à impressão. Os formatos suportados deverão permitir a edi¸cão posterior de relatórios.

(29)

(30)

2.2 Tecnologias

Durante o estágio foram utilizados vários tipos de conceitos teóricos e tecnologias, alguns já pre-selecionados para determinadas fases, e outros selecionados no decorrer do estágio. Esta seçcão descreve todos os conceitos teóricos e tecnologias aplicadas durante o estágio, que serão referenciadas nas seçcões que descrevem o trabalho realizado.

Na fase de desenho detalhado, a arquitectura do sistem foi descrita através da utiliza¸cão da linguagem de modela¸cão UML2.0. Mas esta fase também inclu´ıu uma mockup da GUI (Graphical User Interface) do PEA, implementada em Java, através da framework Eclipse RCP1 _{(Rich Client Platform), que mais tarde, na fase de}

implementa¸cão foi a framework utilizada para dar continuidade ao desenvolvimento da GUI, fazendo com que a única linguagem de programa¸cão utilizada durante o estágio fosse Java.

Interessa reter esta tecnologia utilizada, e o padrão de desenho sob o qual está estruturada: Arquitectura MVC (Model-View-Controller ). Este padrão de desenho e a própria framework eclipse RCP, serão descritas com maior detalhe mais abaixo. Nesta fase de implementa¸cão foi também usado software Open-source para facil-itar a implementa¸cão dos procedimentos de gera¸cão de relatórios. Foi utilizada uma bilblioteca chamada JasperReports2_{, que integra um motor de reporting e todas as}

funcionalidades e especifica¸cões necessárias à produ¸cão de relatórios. Como sendo um dos aspectos fundamentais da aplica¸cão final, este software encontra-se também detalhado na seçcão seguinte.

2.2.1 Eclipse RCP

A plataform Eclipse RCP ´e uma framework que tira partido dos melhores aspectos da arquitectura Eclipse. E composta por um conjunto de plug-ins, baseados na´ arquitectura de plug-ins do eclipse, que define uma base para o desenvolvimento de aplica¸c˜oes cliente mais complexas.

Fornece um sistema de janelas baseado nos conceitos de workbench, pespectiva, vistas, editores e açcões. Vários componentes gráficos e de interface com o utilizador são disponibilizados através dos toolkits SWT e JFace.

Uma aplica¸cão constru´ıda sob a plataforma eclipse RCP, poderá utilizar qualquer plug-in do próprio eclipse, ou qualquer plug-in desenvolvido por terceiros.

• Workbench – O workbench plug-in implementa a GUI workbench e define um n´umero de pontos de ”Extension Points”que suportam contribui¸c˜oes de

1_{http://www.eclipse.org}

(31)

Cap´ıtulo 2. Trabalho Realizado 14 outros plug-ins, como por exemplo, menus e açcões para a Toolbar, opera¸cões de drag&drop, diálogos, wizards, vistas e editores.

• Perspectivas – Uma perspectiva é um conjunto de vistas e editores com uma determinada disposi¸cão na janela do workbench. Define a visibilidade inicial, o layout e a visibilidade das açcões existentes. Só uma perspectiva poderá estar activa de cada vez.

• Editores – Um editor permite ao utilizador, abrir, editar e guardar objectos que sigam um ciclo de vida ”abrir-guardar-fechar”. Contribui com ac¸c˜oes para os menus e toolbars do workbench.

• Vistas – São as partes em que é poss´ıvel arrastar para qualquer posi¸cão e que constituem o layout principal da janela do workbench, como definido na perspectiva.

• Açcões – O mecanismo de açcões é suportado pelo JFace. Permite que co-mandos do utilizador sejam completamente independentes da sua componente espec´ıfica na MMI. Uma açcão representa um comando que pode ser activado por um botão, op¸cão no menu, ou item da toolbar. Cada açcão conhece as suas propriedades na MMI, que podem ser usadas para construir widgets apro-priadas para apresentar a açcão. Esta separa¸cão permite que a mesma açcão seja usada em vários sitios na mesma MMI, e significa que é fácil mudar a apresenta¸cão de uma açcão dentro da MMI, sem ter de se mudar o próprio código da açcão.

SWT

O SWT (Standard Widget Toolkit) é uma framework open source para desenvolvi-mente de GUIs em Java. Representa uma alternativa ao AWT e Swing para de-senvolvimento de applica¸cões gráficas em java. A framework está escrita em Java, acendendo a bibliotecas espec´ıficas da plataforma através do Java Native Interface, melhorando assim a performance da GUI.

O toolkit define uma API portável dispon´ıvel para todas as plataformas supor-tadas, implementando a API, em cada plataforma, acedendo a widgets nativas, sempre que poss´ıvel. Este mecanismo permite o toolkit reflectir qualquer altera¸cão no look and feel da GUI do sistema operativo onde está a correr, enquanto mantém um modelo de programa¸cão consistente para todas as plataformas.

JFace

O JFace é um toolkit de interface com o utilizador constru´ıdo sob o SWT, disponi-bilizando classes que suportam muitas das mais comuns tarefas de programa¸cão. É

(32)

Cap´ıtulo 2. Trabalho Realizado 15 um sistema independente das próprias janelas da GUI, tanto na API, como na sua implementa¸cão, sendo desenhado para trabalhar com o SWT sem o esconder. O JFace inclui no toolkit os componentes comuns de interface com o utilizador, como registo de imagens, fontes, diálogos, preferências e gestão de opera¸cões longas com feedback na GUI.

O padr˜ao Model-View-Controller

O padrão MVC é largamente utilizado em aplica¸cões que implementem uma interface com o utilizador. A plataforma eclipse RCP oferece suporte para esta arquitectura. As seçcões seguintes descrevem este paradigma aplicado à eclipse RCP, detalhando a liga¸cão entre as camadas da arquitectura e os componentes da plataforma que suportam o seu desenvolvimento.

A View Corresponde ao interface com o utilizador. Na plataforma Eclipse, ´e normalmente implementada pelo SWT, que suporta os widgets necess´arios para construir qualquer interface.

A RCP oferece dois tipos principais de partes da interface:

• Vistas, as partes m´oveis do interface que definem o layout do workbench. • Editores, as partes que tˆem um input associado, dentro da janela do workbench

e m´etodos de ciclo de vida adicionais, tais como editar e guardar.

O Controller E a camada do MVC respons´´ avel por receber o input do utilizador e propagá-lo para o Model. As açcões do JFace são utilizadas para este objectivo, em eclipse RCP. Executar uma açcão corresponde a chamar o método run() da classe em questão. Cada açcão é auto-suficiente, com um identificador, uma tool tip e um icon. Desta maneira poderá ser contribu´ıda para s´ıtios diferentes na GUI, tanto para botões como para menus.

O Model Encapsula os dados que serão mostrados na View. A biblioteca JFace fornece, para cada widget, um Viewer correspondente que estabelece a liga¸cão en-tre os objectos do dom´ınio e a própria widget, sem ser preciso modificar esses ob-jectos. Cada viewer necessita da especifica¸cão de várias classes que estabelecem propriedades espec´ıficas dos dados: como apresentá-los, como gerir o conteúdo, por exemplo.

2.2.2 JasperReports

O motor de reporting utilizado, JasperReports, é capaz de produzir relatórios com formato pronto para impressão, ou para ser exportado para diferentes formatos,

(33)

Cap´ıtulo 2. Trabalho Realizado 16 como PDF, XLS e RTF. Suporta também diferentes fontes de dados, usados na gera¸cão dos relatórios, como SGBD ou ficheiros XML.

Os relatórios são produzidos através de um report design e um datasource. O report desgin é utilizado como um template, especificando todo o layout do relatório e que dados serão inclu´ıdos, através do uso de queries e campos internos que foncionam como links para os dados a inserir no relatório. Este report design é definido num ficheiro XML, que contém o esquema espec´ıfico.

Processo de reporting

O processo interno do motor de reporting, para gerar um relatório passa por uma série de opera¸cões espec´ıficas sobre o template inicial e a fonte de dados, cujos conceitos estão explicados de seguida (encontram-se também esquematizados em 2.6):

Figura 2.6: Processo de gera¸c˜ao de relat´orios

(34)

Cap´ıtulo 2. Trabalho Realizado 17 • Compila¸cão - Depois do parsing, o template precisa de ser compilado de modo a validar a sua consistência e preparar todas as expressões e queries, numa forma de pré-processada, acelarando o processo seguinte.

• Preenchimento - Consiste na execu¸cão das queries descritas no template, numa pre-determinada fonte de dados, preenchendo o relatório de acordo com o layout e estilo também definidos no template.

• Exportar ou pre-visualizar - Depois do relat´orio ser preenchido, poder´a ser exportado ou pre-visualizado.

(35)

2.3 Plano detalhado do est´

agio

No relatório preliminar foi entregue o plano inicial previsto, para as tarefas de estágio. Nesta seçcão é feita uma compara¸cão entre esse plano e o calendário fi-nal de estágio.

2.3.1 Plano previsto

O est´agio encontra-se dividido nas seguintes tarefas:

1. Introdu¸cão – consiste na ambienta¸cão à empresa e às condi¸cões de trabalho; 2. Desenho detalhado – desenvolvimento do modelo da arquitectura do sistema

(UML 2.0), estudo das tecnologias a utilizar, esbo¸co e prototipagem da GUI; 3. Relat´orio Preliminar de est´agio;

4. Implementa¸c˜ao: concretiza¸c˜ao do componente PEA cliente e de todas as suas funcionalidades (Linguagem Java, plataforma Eclipse RCP);

5. Manual de Opera¸cões: Realiza¸cão do Manual de Opera¸cões de Software (SOM); 6. Valida¸cão: Realiza¸cão dos testes de valida¸cão do software;

7. Relat´orio Final de est´agio.

A fase de Desenho Detalhado foi composta por duas actividades: esbo¸co/an´alise de tecnologias e arquitectura/prototipagem. Na imagem 2.7 encontra-se a calen-dariza¸c˜ao das fases do projecto.

2.3.2 Calend´

ario final

As tarefas de estágio coincidiam inicialmente com o calendário do projecto, mas como é de dominio público, o projecto Galileo tem vindo a sofrer atrasos sucessivos nas várias fases de desenvolvimento, totalizando neste momento 2 anos de atraso em rela¸cão ao que estava idealizado à 6 anos (o lan¸camento dos satélites estaria previsto para 2008, neste momento acredita-se que deva acontecer perto de 2010). O projecto PEA encontra-se na mesma situa¸cão que a globalidade dos componentes do Galileo visto acompanhar os atrasos de entrega de outros componentes do mesmo n´ıvel no SCCF, que foi um dos sistemas que sofreu mais atrasos devido à sua complexidade e criticalidade (é o sistema de controlo principal da missão Galileo).

O calend´ario final encontra-se detalhado com as datas de fim para cada fase na tabela 2.2.

A fase de Desenho foi a única que se enquadrou com o projecto oficial, tendo as fases de implementa¸cão e valida¸cão sido realizadas no âmbito do estágio. Apesar

(36)

Figura 2.7: Plano previsto das tarefas de est´agio Data Tarefa

1 a 8 de Setembro Ambienta¸c˜ao.

11 a 29 Setembro Detail Design – GUI Tech/Mockups. 2 Outubro a 27 Novembro Detail Design – Modelo UML/Prot´otipo. 27 a 29 Novembro Relat´orio preliminar.

1 Dezembro a 26 Fevereiro Detail Design – Modelo UML/Mockup. 1 Dezembro a 10 de Maio Implementa¸c˜ao.

10 a 16 de Maio SOM. 16 a 25 de Maio Valida¸c˜ao. 25 a 31 Maio Relat´orio Final.

Tabela 2.2: Calend´ario final de est´agio

de nem todas as tarefas terem sido realizadas de acordo com o calendário oficial do projecto, não deixaram de ser uma mais valia para o desenvolvimento do mesmo (im-plementa¸cão e valida¸cão) tendo em conta que a fase de Desenho Detalhado adquiriu uma maturidade bastante elevada, o que leva a crer que de acordo com os requisitos actuais, não haverá altera¸cões de esfor¸co elevado a fazer ao prótipo de modo a obter o produto final. No entanto está previsto que no futuro o projeto PEA tenha novos requisitos e/ou funcionalidades adicionais.

Apesar do estágio ter coincidido com a fase de desenho detalhado, todas as fases foram conclu´ıdas, com especial relevância para a fase de implementa¸cão, como sendo a fase de maior esfor¸co no estágio. Na imagem 2.8 encontra-se o diagrama do calendário final de estágio, onde se pode observar o esfor¸co elevado das fases de desenho e implementa¸cão, em contraste com as restantes.

(37)

Figura 2.8: Calend´ario final das tarefas de est´agio Esfor¸co final

No total o est´agio compreendeu 296 dias de trabalho. Cada dia de trabalho corre-sponde a 8 horas. Os esfor¸co de desenho e implementa¸c˜ao englobam 89% do esfor¸co final, sendo o resto distribu´ıdo homogeneamente pelas restantes tarefas:

• Ambienta¸c˜ao: 5 dias (2%)

• Desenho Detalhado: 125 dias (42%) • Relat´orio preliminar: 3 dias (2%) • Implementa¸c˜ao: 139 dias (47%) • SOM: 13 dias (4%)

• Valida¸c˜ao: 9 dias (3%) • Relat´orio final: 5 dias (2%)

Na imagem 2.9 pode ser visualizada a representa¸cão gráfica da distribui¸cão de esfor¸co.

2.3.3 Resumo dos documentos produzidos

Para além da necessária leitura de documentos (inclu´ıdos nas referências), foram produzidos 13 documentos, listados na tabela 2.3.

(38)

Figura 2.9: Esfor¸co final das tarefas de est´agio Data Documento

13 Setembro GUI Software Evaluation Report - Avalia¸c˜ao do software a utilizar na GUI

18 Setembro GUI Mockup – Elabora¸c˜ao de uma primeira GUI Mockup em MS Powerpoint

26 Setembro Detail Design – Modelo UML – Primeira vers˜ao da ar-quitectura do cliente PEA

27 Outubro Modelo UML e GUI Mockup - 2a _vers˜_ao

16 Novembro SEB Baseline Requirement Analysis – Análise de 2 novos requisitos e consequente impacto nas fases seguintes 23 Novembro Apresenta¸cão do Trabalho Realizado - Apresenta¸cão

elaborada em MS Powerpoint 31 Novembro Relat´orio Preliminar

10 Maio Protótipo - Código Fonte do cliente PEA (Protótipo) 15 Maio Apresenta¸cão interna final do Trabalho Realizado

-Elaborada em MS Powerpoint

16 Maio Manual de Opera¸c˜oes - Manual do utilizador da MMI do PEA

25 Maio Especifica¸cão de Testes de Valida¸cão de Software - Doc-umento com o plano de valida¸cão do software

25 Maio Relat´orio de Testes - Documento de registo das falhas encontradas no Software durante a valida¸c˜ao

31 Maio Relat´orio Final

(39)

2.4 Processos e ferramentas

Esta seçcão apresenta uma descri¸cão detalhada sobre metodologias, ferramentas e calendário final detalhado.

2.4.1 Metodologias

Durante o estágio, foram seguidos processos e metodologias, na sua maioria definidas por um standard interno, criado pelo Sistema de Gestão de Qualidade interno, da Critical Software. Nesta sub-seçcão é feita um introdu¸cão sobre este sistema de qual-idade para depois se poder detalhar qual o processo de desenvolvimento e práticas envolvidas, que contribuiram para a gestão da qualidade do próprio projecto. Sistema de gestão de qualidade

Para a Critical Software, a aposta na qualidade de software foi uma decisão de grande importância e de carácter estratégico tendo em conta a sua competência chave: desenvolvimento de solu¸cões de alta seguran¸ca, fiabilidade, disponibilidade e desempenho de sistemas cr´ıticos permitindo a competitividade com outras empresas de grande importância.

Desde o princ´ıpio, que na empresa, existiu preocupa¸cão em definir regras básicas, procedimentos e ferramentas que pudessem garantir consistência nas tarefas e cumpri-mento de normas exigidas aos projectos.

Numa primeira fase, o número reduzido de colaboradores, de projectos e a prox-imidade entre as pessoas não exigia um Sistema de Gestão de Qualidade (SGQ) com mais do que alguns processos de gestão e implementa¸cão. No entanto, no decorrer do crescimento da empresa, sentiu-se a necessidade de criar um SGQ adequado às necessidades dos projectos que respondesse às novas exigências da Critical.

Segundo o manual de qualidade da Critical, as práticas rigorosas de gestão, coordena¸cão e controlo de projectos e processos de engenharia do SGQ baseiam-se nas seguintes normas de qualidade internacionalmente conhecidas:

• ECSS: normas europeias, definidas pela ESA, para o desenvolvimento de pro-jectos no sector aeroespacial;

• ISO 9001:2000: normas internacionais para a garantia de qualidade em pro-dutos e servi¸cos;

• TickIT: interpreta¸c˜ao da norma ISO 9001:2000 especialmente vocacionada para o desenvolvimento de software;

• ISO 12207: normas internacionais para processos de ciclos de vida no desen-volvimento de software;

(40)

Cap´ıtulo 2. Trabalho Realizado 23 • ISO 15504: normas internacionais para a avalia¸c˜ao da maturidade e capacidade

de processos;

A Qualidade representa assim um importante factor distintivo e uma vantagem competitiva para a empresa, num mercado que é extremamente concorrente. As vantagens para os clientes traduzem-se na condu¸cão de projectos dentro dos prazos e or¸camentos, elevada qualidade das solu¸cões entregues e redu¸cão de custos.

Os processos de qualidade na CSW incluem a organiza¸cão e gestão, em que a engenharia e suporte são adaptados às necessidades espec´ıficas de cada cliente e projecto. Esta flexibilidade permite à empresa dar uma resposta adequada a projectos de natureza e n´ıveis de criticalidade distintas.

O processo de melhoria do SGQ é cont´ınuo e definido com base nos comentários e n´ıveis de satisfa¸cão dos seus clientes, com a colabora¸cão directa do retorno da utiliza¸cão pelas várias áreas de engenharia da empresa e por fim, de acordo com normas e práticas internacionais de engenharia de software.

Processos utilizados durante o est´agio

Durante o estágio, além dos próprios processos definidos para a engenharia de software pelo sistema de qualidade, aos quais o projecto se enquadrava, interessa também detalhar metodologias utilizadas no desenvolvimento do PEA:

• Reuniões semanais - Sempre que poss´ıvel, e desde quase do ´ınicio do estágio, todas as semanas, a equipa do projecto reunia-se para discutir o progresso tas tarefas delegadas, actualizar o estado do projecto, delegar novas tarefas e discutir aspectos, problemas técnicos ou gerais, relacionados com o projecto. • Utiliza¸cão CVS - Todos os documentos, de revisões, de gestão, de qualidade,

código fonte produzido ou utilizado durante o estágio encontram-se guardados num repositório CVS (Concurrent Version System), especificamente, numa directoria especifica do projecto. Este sistema, além da vantagem óbvia de suportar a gestão de versões diferentes e acesso concorrente, permite que seja utilizado como um repositório de toda a informa¸cão e desenvolvimento do projecto num local centralizado. A gestão de versões permite também acesso a versões do trabalho mais antigas que poderão ter sido entregas ao cliente, que interessa rever, ou reverter.

• Sistema de informa¸cão - Todos os documentos produzidos foram registados no sistema de informa¸cão da empresa, que para os quais, lhes atribui um iden-tificador único a ser registado no CVS como tal. Este sistema de informa¸cão suporta também gestão de recursos eventos, e mesmo no desenvolvimento dos projectos. Durante o estágio, diáriamente, as horas gastas nas diferentes fases

(41)

Cap´ıtulo 2. Trabalho Realizado 24 do projecto e outras actividas extra (forma¸c˜oes, acividades de conv´ıvo, etc) foram registadas no sistema, podendo ser posteriormente consultadas.

• Revisões formais - O sistema de gestão de qualidade define um processo de revisão de documentos formal, com o preenchimento de um relatório da revisão, onde se regista todos os aspectos relevantes da revisão: propriedades e versão do documento, pessoas, tempo gasto e falhas encontradas. Este processo foi utilizado para dois documentos produzidos durante o estágio: o DDD (Detail Design Document), e o SOM (Software Operations Manual).

2.4.2 Ferramentas utilizadas

As ferramentas utilizadas para a produ¸cão de relatórios, apresenta¸cões, modelo UML, protótipo e valida¸cão estão descritas na tabela 2.4. Todas as ferramentas, foram utilizadas em Microsoft Windows. No entanto, foi também utilizado Linux no decorrer do estágio, e especialmente na fase final de implementa¸cão, e valida¸cão, visto que a plataforma alvo para o software, era especificamente o sistema operativo SLES 9.0 SP2.

Nome Vers˜ao Notas

MS Office 2003 Edi¸cão de texto, Apresenta¸cões, Folhas de cálculo

CVS 2.0 Repositório e ferramenta de gestão de versões Enterprise Architect 6.0.781 Ferramenta de modula¸cão UML

Eclipse IDE 3.2.1 Ambiente Integrado para Desenvolvimento -Linguagem Java

(42)

2.5 Desenho Detalhado

Este cap´ıtulo descreve as actividades desenvolvidas na fase de desenho detalhado, realizada no ˆambito do projecto PEA. Consiste na descri¸cao da arquitectura detal-hada.

2.5.1 Input ao Desenho Detalhado

A fase de desenho detalhado, teve como input vários documentos criados em fases anteriores, de proposta e de especifica¸cão de requisitos de software, alguns realiza-dos pelo cliente, outros pela CSW (Critical Software). Os requisitos criarealiza-dos pelo cliente, originaram uma proposta técnica por parte da CSW onde se definiu a arqui-tectura de alto n´ıvel inicial, assim como alternativas tecnológicas a adoptar. Este documento (proposta técnica) foi um ponto de partida para o ´ınicio do desenho de-talhado. Adicionalmente, durante o desenho detalhado do lado da CSW, o cliente foi actualizando o documento de Arquitectura, que foi utilizado tambem como input para o desenho final.

Em resumo os principais documentos utilizados como input, formal e informal, para a fase de desenho detalhado est˜ao descritos em baixo:

• PEA ERD (PEA Element Requirement Document) - O documento oficial de requisitos de software para o projecto PEA.

• PEA TP (PEA Technical Proposal) - A proposta t´ecnica realizada pela CSW para o projecto PEA, descrevendo a arquitectura de alto n´ıvel e as tecnologias a utilizar.

• PEA ADD (PEA Architectural Design Document) - Documento de arquitec-tura de alto n´ıvel do sistema PEA como um todo. (O cliente ´e respons´avel pelo servidor, e a CSW pelo cliente PEA).

2.5.2 Actividades desenvolvidas

A fase de desenho detalhado consisitiu numa grande parte do esfor¸co de todo o estágio, principalmente devido a ter sofrido mais do que uma iteraçcão. Isto deveu-se ao facto dos requisitos iniciais não terem sido uma baseline estável, sendo sujeitos a altera¸cões e re-interpreta¸cões durante grande parte dos primeiros meses de desen-volvimento, causando altera¸cões constantes no desenho detalhado do sistema.

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

(43)

Cap´ıtulo 2. Trabalho Realizado 26 pequena fase de investiga¸cão, que teve como objectivo confirmar as tecnologias já pré-selecionadas na proposta técnica, ou mesmo analisar novas alternativas. Após o desenho da arquitectura, foi criada uma mockup da MMI (Man-Machine Interface) na tecnologia escolhida (eclipse RCP). Para documentar as opera¸cões idealizadas nesta mockup, foi criado um manual de opera¸cões preliminar. Nas sub-seçcões seguintes e feita uma descri¸cão do trabalho realizado em cada actividade relevante. Investiga¸cão 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ão de relatórios sobre os dados de telemetria e telecomandos da constela¸cão de satélites Galileo. Esta funcionalidade é endere¸cada pelas tecnologias escolhidas jasperReports e eclipse RCP, já descritas anteriormente na seçcão sobre tecnologias.

Arquitectura detalhada

Conceitos A opera¸cão mais importante da interface do PEA é a análise dos dados, através da gera¸cão de relatórios. Na MMI, os operadores poderão ser capazes de selecionar telemetria ou telecomandos para a gera¸cão de um relatório que ira mostrar os dados em tabelas e/ou em gráficos, facilitando a análise.

Um relatório é constitu´ıdo por um template, uma lista de datasets e, opcional-mente, um filtro a ser aplicado a todos os datasets de um relatório. Estes elemen-tos já 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ão precisa que existiria entre eles. A imagem 2.10 representa esta liga¸cão entre os vários elementos do relatório.

Arquitectura do cliente A arquitectura de alto n´ıvel do sistema PEA inclui um servidor e um cliente, permitindo a existência de multi-utilizadores. O servidor é responsável pela gestão de duas bases de dados, uma de reporting e outra de

(44)

Figura 2.10: Elementos de um relat´orio

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

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

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

O PEA MMI client, permite aos utilizadores definir, gerar e pré-visualizar re-latórios, assim como gerir ficheiros de configura¸cão e as próprias BDs do servidor (backups, restauros, apagar dados e gestão de versões). 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 é poss´ıvel ver a rela¸cão entre o servidor e o cliente através 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 – Coleçcão de widgets SWT open source a serem usadas no PEA (seleçcão de datas, pré-visualiza¸cão de relatórios);

(45)

Figura 2.11: Arquitectura do sistema PEA

O cliente foi desenhado tendo em conta três aspectos chave: a framework eclipse RCP escolhida para a implementa¸cão; o padrão 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ão, processamento e gera¸cão de relatórios. 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êm uma interface definida entre eles, para normaliza¸cão das funcionalidades expostas pelo reportDesigner aos outros dois componentes. Na imagem é possivel ver a rela¸cão entre estes componentes

(46)

Figura 2.12: Arquitectura do cliente PEA

ReportDesigner O componente reportDesigner contém todas as funcionalidades relacionadas com o processamento e gera¸cão de relatórios no PEA. Contém também a especifica¸cão do modelo de dados do template e consequente processamento, tanto para a representa¸cão de templates interna ao PEA, como para processamento de templates do jasperReports. São 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õe para os out-ros componentes, e sua implementa¸cão, encontram-se neste sub-componente. • TemplateDesign - Contém a especifica¸cão do modelo e design do template para

todo o cliente PEA. Todos os outros componentes do cliente PEA usarão esta especifica¸cão para representa¸cão do template em memória. Contem também a implementa¸cão de uma das duas opera¸cões mais importante deste componente: o processamento e mapeamento de um template do PEA para um template do jasperReports.

(47)

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ários sub-componentes de acordo com as principais funcionalidades. Como já referido, as opera¸cões no PEA dividem-se entre opera¸cões de reporting e de configura¸cão. 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ém num sub-componente próprio. Por fim, a utiliza¸cão da eclipse framework é outro dos aspectos mais relevantes, levando à implementa¸cão e con-figura¸cão do workbench num sub-componente à parte. Tirando partido da arquitec-tura eclipse, cada sub-componente foi implementado num plug-in, sendo o cliente PEA MMI final a compila¸cão de todos estes plug-ins. Podemos fazer uma divisão entre estes plugins, identificando aqueles que estão 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áveis pela implementa¸cão dos ele-mentos da GUI:

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

(48)

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

unica chamada Reporting.

Os servi¸cos de suporte do cliente PEA MMI resumem-se à implementa¸cão da comunica¸cão 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, é 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ão, o sistema continuaria a funcionar, mas com opera¸cões 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 é uma aplica¸cão standalone, desenhada de modo a ser executada a partir da linha de coman-dos, pelo servidor, para impressão automática de relatórios. A sua implementa¸cão em Java inclui uma classe principal (PEAPrintClient ) que implementa o método main, invocando o processo de gera¸cao de relatórios implementado no componente reportDesigner, a partir de um determinado template e datasets.

Integra¸cão do JasperReports O processo de gera¸cão de relatórios, no PEA, utiliza os mesmos conceitos do jasperReports, já introduzidos: parsing, compila¸cão, preenchimento e exporta¸cão.

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

(49)

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és do editor de tem-plates do cliente PEA MMI. Todo este processo é utilizado para todas as opera¸cões sobre templates e pedidos de relatórios. Quando um template é criado, ou aberto

(50)

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

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

Na imagem 2.16 são apresentadas as opera¸cões de gestão de templates e cria¸cão de relatórios, divididas em três camadas: comunica¸cão, processamento e apresenta¸cão. Na camada de comunica¸cão encontramos a implementa¸cão do PEA-IF, responsável pelas as opera¸cões 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ão encontramos os componentes de-senvolvidos em eclipse RCP para apresenta¸cão e gestao de templates e relatórios:

(51)

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

editores de templates e relatórios e vistas de templates e relatórios automáticos. Mockup da MMI

A mockup realizada no desenho detalhado definiu a primeira versão da interface do PEA que mais tarde iria ser melhorada para a versão protótipo.

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

a versão final: a interface contém duas perspectivas, cada uma relativa a um dos dois grupos de funcionalidades que existem no PEA: configura¸cão e reporting.

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

A perspectiva de reporting contém uma área para editores abertos (poderão ser vários), ao centro e uma vista para cada elemento de reporting: templates, datasets, filtros e schedules (relatórios a serem gerados no futuro), à 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ão utiliza a área de alerta, porque é apenas uma ferramenta de reporting, e como tal, não existem dados de aviso ao utilizador. Toda as outras áreas 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ão existe a no¸cão de status, com a excep¸cão dos pedidos de relatórios a serem gerados automáticamente (schedules). A vista

(52)

Figura 2.17: PEA Mockup

Figura 2.18: Layout de uma MMI Galileo

de schedules foi colocada nesta zona. Na perspectiva de configura¸cão esta vista não existe, visto ser relativa à perspectiva de reporting.

(53)

Cap´ıtulo 2. Trabalho Realizado 36 configura¸cão, e que permitem acesso às opera¸cões do seu ciclo de vida (editar, apagar) foram colocadas nesta área, tanto na perspectiva de reporting como na perspectiva de configura¸cão, com a diferen¸ca que, nesta última, pelo facto de não existir status view, ocupa ambas as views.

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

2.5.3 Output do Desenho Detalhado

Formato dos relatórios Nesta fase ficou definido precisamente qual seria o for-mato dos relatórios, e os seus conteúdos. Particularmente, o elemento que define todas estas propriedades é o template, que além de todos os elementos de estilo, tem também a defini¸cão sobre que dados serão inclu´ıdos no relatório, assim como a defini¸cão dos campos estáticos.

Os campos estáticos de um relatório são:

• Campos de texto a incluir no relatório: cabe¸calhos, notas de fundo de página, t´ıtulo e sumário;

• Os estilos (font, cor, tamanho, linha e fundo).

Estes elementos podem ser considerados genéricos e aplicáveis a qualquer re-latório em geral. Os elementos espec´ıficos do PEA consistem na defini¸cão dos dados em si. O template inclui uma lista com o tipo de dados que irá conter. Existem três tipos bem definidos:

• Tabelas de telemetria; • Tabelas de telecomandos; • Gr´aficos de telemetria.

Estes elementos poderão aparecer com multiplicidade indefinida em qualquer template e por qualquer ordem. Não existe limite no software para estes campos, ou seja, não foram implementados limites no PEA para estes elementos. Os limites deverão ser impostos pelo hardware da máquina onde o PEA estará instalado, de modo a se obter fácil escalabilidade: para aumentar a capacidade máxima bastará melhorar o hardware, sem qualquer altera¸cão ao software.

Na imagem 2.19 é representado de uma forma visual a posi¸cão de cada elemento num relatório.

(54)

Figura 2.19: Elementos do Template

Documentos O fim da fase de desenho detalhado coincidiu com a conclusão do documento de desenho e da mockup da interface. Uma descri¸cão destes outputs do desenho detalhado é apresentada a seguir:

• DDD (Detail Design Document ) - Documento oficial que inclui o desenho detalhado de todo o sistema PEA, incluindo a parte do servidor e do cliente. No âmbito do estágio foi apenas elaborada a seçcão de desenho detalhado do cliente. Este documento foi uma entrega oficial do projecto PEA (ver anexo A).

• Mockup - Implementa¸cão de uma interface não funcional do cliente PEA de modo a testar os conceitos operacionais e a usabilidade pretendida. Foi também uma entrega oficial, que consistiu na apresenta¸cão da mockup numa workshop que integrava, além do cliente os futuros utilizadores do sistema, pelo gestor do projecto (Os ecrãs da mockup podem ser visualizados no manual de opera¸cões: ver anexo B).