H.M.I JAVA para o Basic System

Universidade de Lisboa

Faculdade de Ciências

Departamento de Informática

H.M.I JAVA para o Basic System

projecto realizado na

NAV Portugal E.P.E.

por

Miguel Jorge Teófilo de Castro Seabra

Mestrado em Engenharia Informática 2007

Universidade de Lisboa

Faculdade de Ciências

Departamento de Informática

H.M.I JAVA para o Basic System

projecto realizado na

NAV Portugal E.P.E.

Por

Miguel Jorge Teófilo de Castro Seabra

Projecto orientado pelo Prof. Dr. Thibault Langlois e co-orientado por Eng. José dos Santos Mestre Vermelhudo

Mestrado em Engenharia Informática 2007

Declaração

Miguel Jorge Teófilo de Castro Seabra, aluno nº28292 da Faculdade de Ciências da Universidade de Lisboa, declara ceder os seus direitos de cópia sobre o seu Relatório de Projecto em Engenharia Informática, intitulado ”H.M.I JAVA para o Basic System”, 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ção do mesmo em formato electrónico na Internet.

FCUL, 10 de Setembro de 2007

José dos Santos Mestre Vermelhudo supervisor do projecto de Miguel Jorge Teófilo de Castro Seabra, aluno da Faculdade de Ciências da Universidade de Lisboa, declara concordar com a divulgação do Relatório do Projecto em Engenharia Informática, intitulado ”H.M.I JAVA para o Basic System”

Resumo

Com o advento dos sistemas distribuídos, a utilização de diferentes tipos de sistemas operativos e constante necessidade de troca de informação entre diferentes nós de rede torna-se cada vez mais comum a utilização de camadas de software especificas, middleware, que se encarregam da comunicação, entrega de mensagens ás aplicações e independência relativamente ao sistema operativo. O sistema middleware implementado na NAV PORTUGAL é o BS (Basic System), este sistema torna possível a troca de informação entre diferentes sistemas operativos e principalmente uma uniformização de comandos relativos á comunicação entre vários nós.

Actualmente as tarefas de monitorização, configuração e detecção de falhas no sistema BS são efectuadas maioritariamente por meio de um módulo do BS denominado BSS (Basic System Shell). Esta ferramenta não é mais que uma linha de comandos com acesso ao sistema BS local que permite a monitorização e acção sobre o sistema em tempo real. Devido ás suas características de “linha de comandos” o BSS torna pouco intuitivo e mais moroso as tarefas de “debugging”, manutenção e configuração para os utilizadores do sistema sendo que o projecto Middleware-9004 tem como objectivo a criação de uma nova BSS. Para alem deste objectivo pretende-se também que o novo BSS seja facilmente portável para diversos Sistemas Operativos tendo sido seleccionada a Linguagem JAVA para o desenvolvimento do HMI (Human Machine Interface)

Índice

1.3. Integração na Instituição de acolhimento ... 9

1.4. Definição do problema e objectivos ... 9

1.5. Siglas e Abreviaturas ... 10

1.6. Organização do Documento... 11

2. O Projecto ... 12

2.1. O Basic System ... 12

2.2. A Basic System Shell... 14

2.3. Metodologia Usada ... 17 2.4. Objectivos ... 18 2.5. Planeamento Previsto... 18 2.6. Planeamento Cumprido... 18 3. Trabalho Realizado ... 19 3.1. Levantamento de Requisitos ... 19

3.2. Arquitectura e Opções de Implementação ... 21

3.3. Trabalho Realizado ... 23

3.3.1. Documentação Elaborada ... 23

3.3.2. A Shell em JAVA ... 24

3.3.3. Problemas encontrados no desenvolvimento da Shell em Java ... 29

3.3.4. Alteração da arquitectura e tarefas BSS... 30

3.3.5. Produto Final e Atrasos... 34

3.3.6. Tecnologias Utilizadas... 35

4. Conclusão... 37

Índice de Imagens

Figura 1 – Basic System ... 12

Figura 2 – Basic System Shell ... 14

Figura 3 – Arquitectura do Basic System Shell ... 15

Figura 4 – Aspecto da actual BSS... 16

Figura 5 – Casos de Uso Identificados do novo sistema ... 19

Figura 6 – Protótipo de GUI a desenvolver ... 20

Figura 7 – Detalhe de dropdown menu e Logon window... 21

Figura 8 – Arquitectura a Implementar... 22

Figura 9 – Menu de Login Incial ... 25

Figura 10 – Aspecto da Shell desenvolvida... 26

Figura 11 – Aparência dos Sub-Menus... 26

Figura 12 – Guardar/Carregar macros ... 27

Figura 13 – Aspecto de janela de edição de macro... 27

Figura 14 – Aspecto da janela de edição de Functional Destitantions... 28

Figura 15 – Relatório de testes unitário (gerado em html) ... 28

Índice de Anexos

Anexos 1 - Planeamento Previsto ... 39

Anexos 2 - Planeamento Cumprido ... 40

Anexos 3 – Diagrama de Classes do Package “Display” ... 41

1. Introdução

1.1. Ambito

Este documento descreve o trabalho realizado no âmbito da disciplina de Projecto em Engenharia Informática da Faculdade de Ciências Universidade de Lisboa.

1.2. A Empresa

O trabalho efectuado foi realizado na empresa NAV PORTUGAL empresa responsável pelo controlo de tráfego aéreo nas regiões de voo de Lisboa e Santa Maria. A empresa tem como principal objectivo a prestação de serviços de tráfego aéreo garantindo o cumprimento de normas nacionais e internacionais.

1.3. Integração na Instituição de acolhimento

No primeiro dia de estágio, dia 9 de Outubro de 2006 foi realizada uma sessão de acolhimento pelo meu coordenador o qual me pôs a par das normas da empresa, da organização do edifício, apresentou-me a colegas de trabalho e atribuiu-me o posto de trabalho. Para alem do posto de trabalho, foi-me atribuído um computador pessoal, documentação relativa ao projecto a desenvolver e acesso ao repositório de informação.

Nos dias posteriores recebi formação relativa a: processos de qualidade de documentação, introdução ao tráfego aéreo e formação Basic System. Sempre que necessário recebi ajuda de colegas de trabalho e projecto relativamente a dúvidas que iam surgindo.

1.4. Definição do problema e objectivos

Presentemente na NAV PORTUGAL de modo a permitir troca informação entre nós heterogéneos de uma rede e uma uniformização de código é usada um Middleware chamado Basic System (BS). As tarefas manutenção dos sistemas que correm sobre BS, configuração, monitorização são feitas através de uma linha de comandos denominada Basic System Shell (BSS). A BSS corrente é programada em C/C++ sendo como tal dependente

do OS (Operating System) e compilador usados, é também presentemente usada para monitorizar o nó local. Devido ás características do BSS, linha de comandos, as tarefas de monitorização, manutenção e configuração tornam-se morosas, como tal o projecto em que me encontro intornam-serido, Middleware-9004, tem como objectivo a criação um novo BSS capaz de eliminar as restrições da BSS corrente e adicionar novas funcionalidades.

O desenvolvimento da nova BSS pressupõe o levantamento de requisitos no entanto deverá ser independente do OS e permitir a monitorização remota de diversos nós.

1.5. Siglas e Abreviaturas

BS Basic System

BSS Basic System Shell

EPE Empresa Publica Estatal

ID Identificador

OS Sistema Operativo

URD User’s Requirement Document

(Documento de Requisitos do Utilizador)

VIS Vision Document (Documento

Visão)

XML eXtensible Markup Language

• O termo “nó” , frequentemente utilizado, destina-se a identificar uma

1.6. Organização do Documento

O resto do documento encontra-se organizado na seguinte forma: • O Projecto

o O Basic System, secção onde é efectuada uma descrição pormenorizada do sistema em questão.

o Metodologia Usada, descrição da metodologia usada.

o Objectivos, secção onde é efectuada uma descrição dos objectivos do projecto.

• Trabalho Realizado

o Levantamento de Requisitos, secção onde são descritos os requisitos obtidos para uma nova versão do BSS.

o Arquitectura e opções de implementação, secção onde é descrita a arquitectura da nova Shell e as opções de implementação tendo em conta os requisitos previamente obtidos.

o Trabalho Realizado, secção onde são descritas as componentes do sistema desenvolvidas, documentação, trabalho elaborado e problemas encontrados e soluções propostas.

o Tecnologias Utilizadas, secção onde são descritas as linguagens e ferramentas utilizadas.

• Conclusão, capitulo onde são aferidas as conclusões do trabalho realizado, a experiência profissional obtida e trabalho futuro no projecto em questão.

2.

O Projecto

2.1. O Basic System

O BS, como anteriormente descrito, é uma plataforma middleware que permite a troca de informação entre vários nós e uma uniformização de comandos. Esta plataforma é amplamente usada na NAV PORTUGAL, grande parte do software utilizado pela empresa utiliza os serviços oferecidos pelo middleware. Os utilizadores do middleware são maioritariamente as equipes de manutenção e desenvolvimento.

O BS é elaborado em C/C++ e compilado no SO OS/2 e Solaris 8 e 10 sendo alguns módulos compilados usando o compilador Borland, outros o compilador IBM VisualAge para o SO OS/2 e o ambiente ‘Forte’ para o OS Solaris. O uso de diferentes compiladores deve-se ao facto de o compilador IBM permitir o uso de funções e funcionalidades não suportadas pelo Borland, sendo este último o compilador das primeiras versões do middleware.

Hardware Operating System

Real Time Program General Purpose Applications

Basic System

O BS em cada nó é composto por seis tarefas principais que comunicam entre si. Essas tarefas são:

• PM, a tarefa Program Manager é responsável pelo controlo de todas as tarefas e alterações de estado de todas as tarefas (running, paused,

crashed).

• BSSEXE, tarefa responsável pela execução de comandos e retorno de

resposta. Os comandos são recebidos da tarefa BSSINP e as respostas

são enviadas para a tarefa BSSOUT.

• BSSOUT, tarefa responsável pelo output para o ecrã de respostas a comandos efectuados mensagens de rotina, e logging para ficheiro de comandos efectuados e respostas recebidas.

• BSSINP, tarefa responsável pela leitura de input´s do utilizador via keyboard. È efectuado o parsing do comando inserido e este comando é enviado para a tarefa BSSEXE onde será executado.

• BSSMGF, tarefa responsável pelo o envio de mensagens para o destino especificado e tratamento das respostas.

• BSSLINKS, tarefa responsável pela manutenção de uma tabela no Nó local com o estado dos links para os diferentes dispositivos (Hardware). Recebe também mensagens com o estado dos links. Cada tarefa, tal como cada nó, tem um ID único de modo a ser identificada. A comunicação entre tarefas é efectuada usando uma estrutura denominada

Tmsg a qual contêm os dados da mensagem a ser enviada, o identificador do Nó e da tarefa de destino. Cada tarefa pode ter até quatro filas de espera de

mensagens, sendo a fila 1ª a de maior prioridade e a 4ª a de menor prioridade.

Módulos de software que sejam desenvolvidos usando como base o BS, comportam-se como se fossem mais uma tarefa (uma ou mais tarefas consoante o tipo de software e os módulos a serem desenvolvidos), sendo necessário atribuir um ID á tarefa, número de filas de espera e profundidade de cada fila. O comportamento destas novas tarefas é em tudo idêntico ás tarefas base do middleware sendo o programador a decidir do destino das mensagens a serem enviadas.

Aquando a execução do BS é lido um ficheiro de configuração no qual está definido o ID do Nó em questão, os argumentos de cada tarefa , o número de filas de cada tarefa o comprimento de cada fila, o identificador da tarefa e o

2.2. A Basic System Shell

O BSS consiste numa shell utilizada principalmente para tarefas de manutenção, debugging, teste. A BSS é constituída principalmente pelas tarefas BSSOut e BSSInp responsáveis pelo input e output (e logging) de comandos respectivamente. D e vi ce C o n tr o l C o m m a n d s D e vi ce S ta te L in k S ta te M e ss a g e

Figura 2 – Basic System Shell

A comunicação entre as tarefas aquando o input de comandos ou output de respostas é a mesma que no resto do BS, isto é, usa uma estrutura TMsg para transferir dados. A tarefa BSSOut para alem de efectuar o display efectua também o log dos dados recebidos e enviados para ficheiro.

Link sta te M ess age BS S C om m an ds De vice Co ntr ol C om ma nds Tas k sp ecifi c info rmat ion Ta sk R eply

2.3. Metodologia Usada

No decorrer do projecto metodologia utilizada consistiu nos seguintes passos:

• Levantamento de Requisitos: o contacto com o cliente, neste caso a própria empresa, tem como objectivo a compreensão do problema, e análise dos requisitos para o sistema a desenvolver/alterar.

• Análise do sistema/desenho da arquitectura do sistema: nesta fase, e tendo em conta os requisitos recolhidos, é efectuado um estudo das melhores de soluções de arquitectura. Após escolhida a arquitectura e tecnologias utilizadas são elaborados os documentos técnicos do projecto.

o Aprovação de Documentos pelo Departamento de Qualidade: este departamento é responsável pela aprovação de documentação de modo a assegurar que esta siga os padrões e normas em que a empresa NAV PORTUGAL é certificada. Cada documento após completado é entregue para revisão aos revisores seleccionados devendo sempre envolver o departamento de “Qualidade” entre outros departamentos (logística, manutenção, produção de software) da Direcção, as quais irão ser afectados pelo projecto. Após revisão e inclusão de eventuais comentários o documento é aprovado.

• Desenvolvimento de Software: A implementação será efectuada baseada nas especificações dos documentos previamente elaborados, serão efectuados testes unitários durante o desenvolvimento sendo possível a existência de varias iterações do desenvolvimento de um módulo de acordo com o resultado dos testes

• Testes e Avaliação do Software desenvolvido: fase em que o software desenvolvido é sujeito a uma série de testes unitários, de integração e aceitação cujo objectivo é testar o sistema desenvolvido de forma a encontrar possíveis erros, verificar se os requisitos especificados são cumpridos e testar a integração no sistema operacional.

2.4. Objectivos

O objectivo do projecto middleware-9004 consiste na recolha, identificação e análise de requisitos dos utilizadores, criação da documentação necessária (ver planeamento), e a implementação de um Graphical User Interface

(GUI) para a ferramenta BSS.

A ferramenta a ser desenvolvida não estará apenas limitada á monitorização do nó onde é lançada como presentemente, podendo estabelecer ligações com outros nós. Serão mantidas todas funcionalidades da presente BSS sendo no entanto implementada uma GUI que permitirá acesso facilitado e mais rápido ás funções e comandos mais utilizadas, GUI essa independente do SO para a sua execução.

De modo a implementar esta ferramenta torna-se necessário levantamento de requisitos de utilizador, elaboração de documentação relativa a requisitos de utilizadores, interface pessoa – máquina, descrição da arquitectura do sistema e protocolos de elaboração de testes.

2.5. Planeamento Previsto

Aquando o início do projecto foi efectuado um planeamento das diferentes fases do projecto, planeamento este, susceptível de alterações consoante o decorrer do projecto e disponibilidade de recursos humanos.

È possível visualizar o planeamento inicialmente previsto na secção Anexos, em Anexo 1 - Planeamento Previsto.

2.6. Planeamento Cumprido

O planeamento inicialmente previsto sofreu desvios, sendo possível visualizar o planeamento efectuado na secção Anexos em Anexo 2 -

Planeamento Cumprido.

Estes desvios no planeamento devem-se a atrasos quer na fase de desenvolvimento de software, cujas causas são explicadas mais á frente neste relatório, quer na fase de elaboração quer de documentação. Nesta ultima fase os atrasos deveram-se ás necessidade de varias iterações necessárias á aprovação dos documentos e á falta de disponibilidade de recursos revisores.

3. Trabalho Realizado

3.1. Levantamento de Requisitos

O levantamento de requisitos para uma nova BSS foi efectuado em conjunto com a equipe que desenvolveu o BS, equipe esta, também responsável pela manutenção do sistema.

Foi identificada uma necessidade de uma plataforma de monitorização com um GUI funcional, independente do SO, capaz de gerir/monitorizar nós remotos mantendo todas as funcionalidades da presente Basic System Shell.

Após a identificação dos requisitos foi efectuado um documento, o URD, em que foram descritos os casos de uso associados aos requisitos requeridos. Documento este o qual foi aprovado pelos departamentos afectados pela alteração do sistema (departamentos de logística, manutenção, produção de software), pelo departamento da qualidade e do cliente, validando assim um correcto levantamento dos requisitos do sistema.

A partir do momento em que existiu uma validação do levantamento de requisitos foi efectuado um estudo para a elaboração de uma interface pessoa – máquina. A abordagem consistiu em agrupar os comandos mais utilizados dentro do grupo a que se inserem, tal deu origem a 5grupos distintos: Tasks, Macros, Routes, Functional Destinations e Symbols. Dentro de cada grupo foram criados botões associados aos comandos mais usados. De modo a permitir a visualização de comandos efectuados e de dados recebidos usaram-se dois painéis. A permuta entre diferentes nós, ou criação de novas ligações é feita por meio de botões na base do ecrã. Optou-se também pela elaboração de uma barra de estados (StatusBar) e de uma linha de comando de modo a poder inserir dados.

Para tal foram sugeridos vários protótipos sendo que a aceitação do GUI final foi feita pelos departamentos anteriormente referidos, aquando a validação do documento VIS.

Seguidamente são apresentadas imagens do protótipo validado:

Figura 7 – Detalhe de dropdown menu e Logon window

3.2. Arquitectura e Opções de Implementação

Com o objectivo de tornar o GUI independente do OS optou-se por elabora-lo em JAVA. De forma a possibilitar uma transferência de dados entre o módulo JAVA e o BS utilizou-se uma biblioteca desenvolvida na NAV PORTUGAL, que recebe dados por meio de um socket TCP e entrega-os ao middleware BS. Para pentrega-ossibilitar o controlo e verificação de dadentrega-os recebidos e enviados pela biblioteca previamente mencionada optou-se por colocar a informação em formato XML.

A biblioteca que recebe dados é integrada na tarefa BssOut, ficando esta responsável pela recepção de comandos provenientes dos clientes e envio de respostas/outputs do BS para os clientes. Á excepção da criação do GUI e alteração da tarefa BssOut não foi prevista alteração da arquitectura nem dos restantes módulos.

BSSINP BSSOUT BSSEXE BSSLINKS BSSMGF Program Taskgroup, taskstate Tas_{k R} epo rting Device State Link sta te M essa ge BSS Com man ds BS S C om m an ds Dev ice Co ntro l C om ma nds E rr_o rs C o m m a n d R e p ly Message to be delivered Tas k sp ecifi c info rmat ion Task Re ply

Program tras_kgroup

task control c_ommand

Task s_pecific inform ation Co mm an d B S S C o m m a n d s (G U I) F o rm a tt e d O u tp u t Java GUI Formatted Output

3.3. Trabalho Realizado

3.3.1. Documentação Elaborada

Como descrito anteriormente, após uma breve formação de contextualização, o início do projecto consistiu no levantamento e elaboração de um documento de requisitos do utilizador (URD – User Requirements Document). Durante o período de aceitação do documento URD foram sendo desenvolvidos vários protótipos do GUI, quer em modo digital quer em esboços de papel, sendo também possível a elaboração de algumas partes do documento Visão (VIS).

De forma a descrever a arquitectura do sistema desenvolvido foi elaborado o documento SAS (Software Architecture Specification). O documento SRS (Software Requirements Specification) permite descrever os requisitos de software, isto é os inputs, outputs e interfaces de cada módulo, neste caso as tarefas.

De forma a planear os testes de aceitação do produto foi elaborado o documento em que o planeamento dos testes é efectuado o TMP (Test Management Plan) sendo que os testes de aceitação foram especificados no documento ATD (Acceptance Test Document). Os resultados dos testes de aceitação são descritos no documento ATR (Acceptance Test Report).

Sensivelmente a meio do trabalho de codificação foi necessário a alteração da documentação, tal reflectiu-se na actualização dos documentos VIS, SAS, SRS, IRS, TMP e ATD. È de frisar que sempre que eram efectuadas pequenas alterações, quer na arquitectura da aplicação, quer a nível da interface pessoa-máquina os respectivos documentos eram actualizados e submetidos a aprovação.

3.3.2. A Shell em JAVA

Aquando a aceitação do documento URD, o documento VIS foi elaborado e sujeito a aprovação e iniciou-se do desenvolvimento do GUI em Java.

Como mencionado anteriormente um requisito do GUI é ser independente do OS para tal optou-se por desenvolver a interface em JAVA 1.4.2. A versão 1.4.2 do JAVA foi escolhida especificamente devido a ser a ultima versão disponível do JRE (Java Rutime Enviroment) para o sistema operativo OS/2. De modo a elaborar os menus e botões foram utilizadas funções fornecidas pela biblioteca swing do JAVA Para possibilitar uma futura integração do software desenvolvido com outros produtos da NAV PORTUGAL e uniformizar o look and feel da aplicação foi utilizada a framework A.S.D (Air Situation Display) desenvolvida na NAV PORTUGAL

Aquando a aprovação do documento VIS, o layout do GUI foi dado como finalizado, sendo necessário apenas elaborar os algoritmos de controlo de dados, de leitura de ficheiros e classes/métodos de comunicação. O desenvolvimento de algoritmos e classes de comunicação foram elaborados paralelamente á alteração das tarefas, sendo que o ultimo estágio da programação do GUI foi a elaboração de testes unitários.

O GUI pode ser lançado aquando a iniciação do middleware BS, por meio de parâmetro no ficheiro de configuração ou pode ser lançado correndo o ficheiro jar correspondente numa máquina remota. Quando o GUI é lançado lê de um ficheiro a lista de zonas e de nós aos quais pode estabelecer ligação (caso se encontrem na mesma rede, caso contrario não será possível estabelecer comunicação).

A Basic System Shell actual permite injectar macros no sistema, macros são ficheiros com listagens de comandos bastante utilizados em tarefas de manutenção de debuging. Um dos requisitos do GUI é a possibilidade de efectuar o carregamento de ficheiros, alteração e criação dos mesmos. Em alternativa a enviar os dados do ficheiro “linha a linha”, visto os nós a monitorizar poderem estar geograficamente distantes, sendo de esperar um eventual considerável atraso nas comunicações e possível alteração do objectivo do script, optou-se por transferir o ficheiro para o nó de destino sendo então executado.

Foi também especificado que uma Shell possibilitaria a monitorização de vários nós ao mesmo tempo, tal é possível pela utilização de quatro botões que permitem mudar de nó a monitorizar ou estabelecer uma nova ligação caso não existam ainda quatro ligações estabelecidas.

Os comandos efectuados pelo utilizador, seja por meio de botões ou por linha de comandos, são enviados via o protocolo TCP/IP.

Do ponto de vista de programação, a biblioteca swing foi amplamente usada, as funcionalidades mais usadas encontram-se agrupadas em JMenus e

JMenuItem, a informação recebida e enviada é apresentada em JScrollPane

e os inputs do utilizador são inseridos em JTextArea.

No final da codificação do GUI foram efectuados testes unitários quer ás funções criadas quer a nível de funcionalidades da biblioteca swing, para tal foi usada a ferramenta JUnitTest, ferramenta esta que permite a elaboração de relatórios que servem de prova a realização de testes. Foi também utilizada a ferramenta Uispec4j de modo a possibilitar a simulação de eventos sobre componentes swing.

Após a finalização do GUI, tinham sido elaboradas cerca 8970 linhas de código organizadas em 43 classes, 13 destas referentes a testes unitários. È possível verificar no Anexo3 e Anexo4 os diagramas de classes dos

Packages responsáveis pelo display e comunicação.

Seguidamente é possível verificar o layout a ser utilizado (as cores de posição de menus poderão não corresponder á versão final do produto) e o

output da ferramenta JUnitTest.

Figura 10 – Aspecto da Shell desenvolvida

Figura 12 – Guardar/Carregar macros

Figura 14 – Aspecto da janela de edição de Functional Destitantions

3.3.3. Problemas encontrados no desenvolvimento da Shell em Java

Durante o desenvolvimento não surgiram problemas dignos de registo, para alem dos comuns bugs de programação prontamente resolvidos, e o tempo de aprendizagem/habituação necessário á linguagem swing.

Por varias vezes foram efectuadas pequenas alterações nas classes de forma simplificar o código.

Aquando a realização de testes unitários, realizados com a ferramenta JUnit e Uispec4j, foi necessário uma reestruturação do código. Esta reestruturação deveu-se á incompatibilidade da framework, desenvolvida na NAV PORTUGAL, ASD com as ferramentas JUnit e Uispec4j. O resultado foi uma melhor estruturação do código produzido e a possibilidade da execução de testes unitários. A elaboração de testes unitários e respectiva reestruturação do código levou a um ligeiro atraso dos prazos de codificação e de testes e integração.

3.3.4. Alteração da arquitectura e tarefas BSS

As alterações previstas no middleware resumiram-se apenas á alteração da tarefa BssOut. Esta tarefa deverá receber dados dos diversos clientes via TCP/IP e no formato XML encaminha-los para a tarefa BssInp receber o resultado da execução dos comandos e reencaminha-los para os clientes.

Como anteriormente mencionado, o Basic System usa dois compiladores, o Borland e o IBM Visual Age, as tarefas e bibliotecas mais recentes utilizam o compilador IBM no entanto as tarefas que compõem o BSS e bibliotecas usadas por esta estão compiladas em Borland. Tal constituiu um problema pois a biblioteca a usar para servir de ponte entre TCP/IP e o BS foi compilada em IBM VisualAge, sendo este compilador mais recente e fornecendo mais funcionalidades. Por motivos de coerência optou-se por migrar as tarefas e bibliotecas do BS (BSS incluído) do compilador Borland para o compilador IBM VisualAge.

Embora uma parte do código já tivesse makefiles feitos para o compilador IBM a tarefa de migração revelou-se morosa devido á quantidade de ficheiros e suas dependências, a efectuação de pequenas alterações no código e erros em makefiles aquando a alteração/criação destes. Esta tarefa teve consequências razoáveis no decorrer do projecto levando a um atraso nas datas de desenvolvimento do código e de testes. Após migração de compilador foram criadas as funções que efectuassem a recepção dos dados TCP/IP, para tal foi utilizada uma biblioteca elaborada na NAV PORTUGAL, que permite receber dados via TCP/IP e converte-los em TMsg, o tipo de mensagem trocado entre tarefas BS.

O protocolo de comunicação do GUI com o BS é TCP/IP, no entanto o middleware BS só comunica via estruturas de mensagem TMsg, deste modo foi necessário utilizar uma biblioteca previamente elaborada na NAV PORTUGAL que permite que um nó BS receba pacotes TCP/IP. Esta biblioteca recebe mensagens TCP/IP e reenvia-as para o BS sobre a forma de TMsg de modo a poderem ser lidas. De modo a transferirem-se dados de uma forma mais simples, facilitar futuras alterações no código/sistema e tornar a programação mais simples optou-se pela utilização de XML. As mensagens são recebidas e envidas pelo GUI e BssOut em formato XML.

Para permitir uma leitura dinâmica dos campos XML e tendo em conta a possibilidade da utilização de XML em outros projectos na empresa optou-se pela realização de uma biblioteca de parsing de XML. Após um estudo inicial do problema verificou-se que a elaboração de tal biblioteca

seria morosa e consumiria tempo e recursos não disponíveis, como tal optou-se por uma pesquisa de ferramentas de parsing XML para C/C++ freeware, opensource e independente do OS/compilador. A tarefa de encontrar software com os requisitos anteriores mencionados foi relativamente curta sendo escolhido o software “XmlParser”, após a escolha sucedeu-se um período de testes em ambiente OS/2 e com o compilador IBM VisualAge.

A biblioteca permite não só efectuar o parsing de uma mensagem XML como permite a criação de uma mensagem XML de acordo com a intenção do programador, tal funcionalidade revelou-se bastante útil e foi amplamente usada. A integração da biblioteca com o código anteriormente elaborado decorreu sem problemas, sendo possível começar iniciar a troca de mensagens entre o GUI e o middleware.

Visto que o GUI pode monitorizar e controlar nós a distancias geográficas consideráveis e não sendo de descurar atrasos na rede implementou-se um pequeno protocolo de “HeartBeat”, isto é o GUI envia uma mensagem para o servidor a cada N segundos (N – valor escolhido pelo utilizador), iniciando um timer de valor N%2, o nó monitorizado ao receber a mensagem de heartbeat responde. Se o timer do GUI expirar o utilizador do GUI é avisado da indisponibilidade do nó, este é dado como offline e o socket fechado.

Finalizada a parte da comunicação entre o GUI e o BSS foi necessário efectuar o tratamento dos comandos e reencaminhar o resultado dos mesmos para os clientes. Apesar da nova BSS substituir a anterior pretende-se que por meio de opção no ficheiro de configuração seja possível escolher quer uma quer outra. Devido á forma como o código se encontrava estruturado e de forma a permitir a permuta entre as duas BSS (antiga e nova), foi necessário alterar o código da tarefa BssInp (tarefa input).

Esta alteração de código não inicialmente prevista levou a uma pequena alteração na arquitectura da tarefa e do sistema tal como nos documentos SRS, SAS e IRS que tiveram de ser alterados e aprovados,.

Aproveitando a alteração da documentação foi elaborado um requisito que consistiu na verificação do estado das Routes (rotas entre nós). Após um estudo do código a alterar verificou-se a necessidade de também efectuar ligeiras alterações na tarefa BssLnks, de modo a cumprir o requisito.

T a s k R e p o rti_n g Lin k s tate M es sa ge BS S C om m an ds De vice Co ntro l C om ma nd s Tas k sp ecifi c info rm atio n Tas k R eply

Na tarefa BssInp, devido ás particularidades do código, o principal problema foi diferenciar os inputs do teclado dos inputs oriundos da tarefa BssOut (por sua vez oriundos dos clientes remotos via TCP/IP), não diferenciando o tratamento dos dados e permitindo o funcionamento simultâneo de ambas as formas de input.

O problema foi resolvido da seguinte forma: quando a tarefa BssInp recebe uma mensagem origunda de BssOut e com MsgId especifico, altera este campo e reencaminha a mensagem para si mesmo. A tarefa BssInp aquando a recepção da mensagem de si mesmo com o MsgId alterado a tarefa identifica a mensagem como proveniente do teclado e o tratamento dos dados é efectuado. Desta forma foi possível permitir que ambas as formas de input funcionem paralelamente tendo igual tratamento. Aquando da elaboração do planemanto não foi possivel prever esta alteração, sendo que houve uma necessidade de estudar o código, altera-lo, actualizar a documentação (documentos SAS e SRS) e efectuar testes informais, tal atrasou o projecto em algumas semanas.

Na tarefa BssLnks existe uma lista de Routes associada sendo que foi apenas necessário a realização de uma pequena função que permitisse o retorno do estado de determinada Route. Tal foi bastante célere no entanto foi necessário efectuar alterações na tarefa BssOut e no próprio GUI de forma a requisitar o estado da Route e tratar a resposta.

Acabadas ambas as alterações e efectuados testes informais foi necessário criar um buffer de dados de modo a permitir criar uma mensagem XML completa a partir de mensagens XML fragmentadas. Isto permite que uma mensagem XML dividida em diversas tramas seja lida pelo BSS. Caso exista corrupção da mensagem, mesmo quando juntas as tramas fragmentadas, a biblioteca XMLParser apresenta uma mensagem Xml Corrupted Message. Finalizada a codificação do BSS, e compilado em IBM VisualAge para OS/2, foi efectuada uma migração para o SO Solaris 10, tal requereu a recompilação da biblioteca XMLParser e da biblioteca que efectua a ponte entre TCP/IP e o BS, para alem da recompilação do código desenvolvido, esta tarefa teve um ligeiro impacto na data de inicio dos testes de aceitação.

Após a codificação a aplicação foi testada em preparação para os testes de integração. Este tipo de testes visa testar a estabilidade e funcionalidade da aplicação quando instalada no SO e hardware para o qual foi desenhada e quando usada em conjunto com o restante software.

No final da codificação das tarefas BSS as alterações efectuadas incidiram sobre cerca 11000 linhas de código

Para a formalização de todos os testes necessários: testes unitários, testes de integração e testes de validação; foi preparado um documento TMP (Test Management Plan) que descreve a programação e a arquitectura dos testes realizados.

Os testes de integração foram efectuados por um elemento externo á codificação da aplicação sendo os resultados dos testes documentados no documento ATR (Acceptance Tests Report).

Finalmente os testes de aceitação foram efectuados com a presença de um elemento representante do cliente (departamento de manutenção), o principal utilizador, em que foram seguidos os testes especificados no documento ATD. È de frisar que devido á especificidade da aplicação e á impossibilidade de recriar todas as condições de teste foram efectuados diversos testes “livres” de modo a analisar o comportamento da aplicação. Este tipo de testes visa verificar se todos os requisitos definidos se encontram presentes no produto final.

3.3.5. Produto Final e Atrasos

A versão final do produto cumpre todos os requisitos inicialmente propostos tal como todas as alterações a esses requisitos. Todas as funcionalidades da anterior BSS estão presentes, no entanto mais acessíveis devido, a uma interface mais user friendly. Não foi descurada a hipótese da utilização da anterior shell sendo possível a utilização (local) de ambas as Shell em simultâneo. O produto final permite um uso mais simples e intuitivo da aplicação não existindo dependência da plataforma de monitorização do SO.

O planeamento inicialmente previsto para o levantamento de requisitos, elaboração de documentação, codificação e testes de integração foi alterado. Este atraso, como anteriormente explicado, deveu-se a diversos problemas encontrados aquando da codificação e alterações de arquitectura necessárias nessa fase que não eram possíveis de prever aquando do planeamento do projecto. No entanto os prazos do projecto, apesar de dilatados, encontram-se dentro dos limites estabelecidos pela empresa de acolhimento, a NAV PORTUGAL.

3.3.6. Tecnologias Utilizadas

No decorrer do projecto tive o contacto com as seguintes tecnologias: • Sistemas Operativos:

o OS/2, foi um SO no qual não tinha nenhuma experiência, no entanto foi no qual mais trabalhei tendo adquirido alguns conhecimentos sobre o SO em questão.

o Solaris 10, tendo alguma experiência académica em linux foi fácil habituar-me ao SO, tendo no entanto verificado algumas diferenças face a linux, nomeadamente na configuração de placas de rede.

o Windows, foi usado durante a codificação em JAVA e elaboração de documentação.

• Compiladores:

o Borland Compiler, compilador de C++ para OS/2 o IBM Compiler, compilador de C++ para OS/2

o Sun Visual Studio, compilador de C++ para Solaris 10 • Linguagens de programação:

o C/C++, apesar da experiência académica com a linguagem C, solidifiquei fortemente os conhecimentos nesta linguagem. Tive o primeiro contacto com a linguagem C++ a qual compreendi facilmente.

o Java, consolidei os conhecimentos com a linguagem de programação JAVA nomeadamente a nível de swing.

o Uso de Debuggers, não tendo nenhuma pratica com esta ferramenta rapidamente tomei conta da sua importância na elaboração de testes e resolução de bugs.

• Linguística,

o Inglês: foi-me oferecida a possibilidade de efectuar documentação formal em Inglês, tal proporcionou-me uma experiência única na elaboração de discurso formal nesta língua.

• Outras:

o XML, tive o primeiro contacto com XML no decorrer do projecto, esta linguagem revelou-se de fácil aprendizagem e bastante útil.

o JUnit, desconhecia até á data a criação de uma ferramenta de testes unitários e o próprio conceito de teste unitário. Tal permitiu uma alteração na minha metodologia de programação permitindo a elaboração de um código mais correcto e estruturado, livre de bugs, e demonstrou-me a importância da existência de provas de teste.

4. Conclusão

A licenciatura forneceu-me importantes bases técnicas para a elaboração deste projecto. Os conhecimentos adquiridos durante a licenciatura foram amplas vezes utilizadas no decorrer do projecto tento sido interessante verificar a sua aplicação no mundo empresarial. A experiência proporcionada na NAV PORTUGAL permitiu um maior desenvolvimento e consolidação das minhas capacidades técnicas bem como a aprendizagem e familiarização com novas tecnologias.

No decorrer do projecto aprendi a gerir o trabalho mediante de prazos, elaborar requisitos e verificar a possível existência de outros tantos, obtive também alguma formação relativamente ao funcionamento de sistema de Controlo de Tráfego Aéreo. No capitulo da programação as minhas capacidades aumentaram grandemente isso reflectiu-se na estruturação do código e na metodologia de programação em que faço uso de ferramentas de testes unitários e de debugger no decorrer da codificação.

Tive o privilégio de trabalhar num projecto no qual tive contacto com pessoas de outras nacionalidades com metodologias de trabalho e cooperação diferentes das que tinha experiência.

Em suma, este projecto possibilitou-me uma fácil e produtiva integração no mundo do trabalho num projecto no qual tive contacto com varias tecnologias. O contacto e interacção com membros da equipe permitiu uma aquisição de conhecimentos técnicos, capacidade de trabalho em grupo, contacto e elaboração de documentos técnicos e uma nova visão de abordagem de um problema.