Uma Sistemática para implementação de Atividades Práticas em Cursos de Computação: um Estudo de Caso

Transcrição

1 Uma Sistemática para implementação de Atividades Práticas em Cursos de Computação: um Estudo de Caso Vera Lúcia da Silva, Adilson Marques da Cunha Divisão de Ciência da Computação - Instituto Tecnológico de Aeronáutica (ITA) Praça Marechal Eduardo Gomes, 50 - Vila das Acácias - CEP: São José dos Campos SP Brasil {vera,cunha}@comp.ita.br Abstract. This article presents a systematic to implement practical activities for subjects taught at undergraduate and graduate courses in the area of Computer Science at Brazilian Aeronautical Institute of Technology (Instituto Tecnológico de Aeronáutica ITA). It tackles situations found on actual environments of the work market, exposing students to its dynamics and difficulties. To verify this systematic, a case study was developed aiming to increase integration levels between developing software system prototypes to be embedded within a Control Station called VIGILANTE and an Amphibian Flying Car Experimental Vehicle named TRIPHIBIUS. In this Case Study, It was applied the state of the art in terms of the existing technologies of object oriented Software Engineering. Resumo. Este artigo apresenta uma sistemática para implementar atividades práticas em disciplinas ministradas em cursos de Graduação e Pós- Graduação na área de Ciência da Computação no ITA. Ele aborda situações encontradas em ambientes reais do mercado de trabalho, e expõe os alunos às dinâmicas e dificuldades desses meios. Para verificar esta sistemática, um Estudo de Caso foi desenvolvido,visando aumentar os níveis de integração entre Protótipos de Sistemas de Software em desenvolvimento a serem embarcados numa Estação de Controle chamada VIGILANTE e num Veículo Experimental do tipo Carro Anfíbio Voador denominado TRIPHIBIUS. Neste Estudo de Caso, aplicou-se o estado da arte em termos de tecnologias existentes de Engenharia de Software Orientadas a Objetos. 1. Introdução As universidades brasileiras carecem de incluir experiências práticas de desenvolvimento de sistemas computadorizados, utilizando o estado da arte em termos de tecnologias nas matérias oferecidas em programas de Graduação e de Pós-graduação, principalmente na área de Informática. Dentre as principais deficiências encontradas nas Instituições de Ensino Superior (IES) do Brasil, destacam-se a falta: de iniciativas, de projetos práticos, de sistemáticas e de dispositivos e softwares que propiciem a realização de experiências práticas com resultados positivos. No domínio do conhecimento dos Sistemas de Software Embarcados e de Tempo Real, além do Paradigma de Engenharia de Software, de Metodologias e Padrões Orientados a Objeto de última geração, a comunidade científica e tecnológica necessita utilizar-se mais de Ambientes Integrados de Ferramentas de Engenharia de

2 Software Ajudada por Computador (Integrated Computer Aided Software Engineering Environment - I-CASE-E) e de Ambientes de Desenvolvimento Rápido de Sistemas (Rapid Application Development RAD). Diante disso, faz-se necessário dotar as Universidades Brasileiras de uma sistemática de aplicação das novas tecnologias existentes, de forma pragmática e experimental, visando melhorar a experiência prática dos alunos e reduzir recursos de toda ordem, desenvolvendo metodologias e algoritmos que possibilitem aos alunos aplicar e incrementar, suas habilidades e conhecimentos a partir das exposições teóricas, preparando-os para as exigências do mercado de trabalho. Nos últimos 03 (três) anos, no Instituto Tecnológico de Aeronáutica (ITA), vêm sendo ministradas experiências práticas para o desenvolvimento de Sistemas computadorizados, utilizando-se o estado da arte em termos de tecnologias orientadas a objetos. Essas experiências vêm sendo realizadas nos Programas de Graduação e Pós- Graduação em Engenharia Eletrônica e Computação, principalmente, nas matérias de Banco de Dados, Qualidade e Confiabilidade de Software, e Sistemas de Software Embarcados e de Tempo Real. O presente artigo descreve o desenvolvimento de uma experiência de sucesso realizada nas disciplinas CES32 e CE230-Qualidade, Confiabilidade e Segurança de Software, CES63 Sistemas Embarcados e CE235-Sistemas Embarcados de Tempo Real, durante os anos de 2001 e 2002 no ITA. Ele descreve aspectos metodológicos de um Estudo de Caso, envolvendo um Veículo Experimental e uma Estação de Controle, abordando os principais passos realizados, dentro de Etapas e s pré-definidas, em três diferentes níveis de integração. Dividido em seções, este artigo além desta primeira introdução possui: a seção 2 que descreve a sistemática adotada para a implantação de recursos práticos nas disciplinas; a seção 3 que apresenta o Estudo de Caso adotado para o experimento, bem como as tecnologias e recursos utilizados para o seu desenvolvimento; a seção 4 que relata os principais resultados alcançados; e, por último, a seção 5 com algumas conclusões e considerações finais. 2. Sistemática Adotada para Aulas Práticas Ao iniciar as aulas das disciplinas acima citadas, o professor apresenta aos alunos uma temática ou cenário a ser considerado para a realização dos seus trabalhos práticos. Este cenário viabiliza a escolha de aplicações a serem desenvolvidas, criadas baseando-se nos conteúdos teóricos apresentados em aula. Práticas laboratoriais são realizadas de forma interativa, envolvendo técnicas de Educação a Distância e recursos computacionais em ambientes que extrapolam os muros da academia. Os cenários geralmente mostram uma situação ou ambiente real, necessitando da aplicação de novas tecnologias para facilitar ou melhorar o estado atual. Devido ao ITA estar envolvido com as problemáticas do Centro Técnico Aeroespacial (CTA), geralmente as temáticas escolhidas abrangem assuntos envolvendo transporte aéreo, segurança nacional e assuntos tecnológicos relacionados, como a problemática do ambiente Communication Navigation and Surveillance / Air Traffic Management (CNS/ATM).

3 Os alunos matriculados nas disciplinas são divididos em grupos. Cada grupo escolhe um subsistema dentro do cenário apresentado como temática. A partir dessa escolha, eles seguem heurísticas para especificar requisitos, modelar, implementar e testar suas aplicações. Após a escolha de seus protótipos, os alunos de cada grupo utilizam uma ferramenta para gerenciamento de projetos. Esta atividade visa a familiarização com Ferramentas de Software para o Gerenciamento de Projetos, como por exemplo, o MS- Project, cujo conhecimento pode ser aplicado ao projeto de sistema a ser desenvolvido. Com este tipo de ferramenta, os grupos podem especificar: o cronograma das atividades de desenvolvimento; a atuação das pessoas dentro do projeto; bem como estabelecer metas e estipular prazos. O Processo de Desenvolvimento do Protótipo de um Sistema de Software (como produto) deve seguir a Metodologia das Técnicas de Modelagem de Objetos - TMO (Object Modeling Technique - OMT), de Rumbaugh, adaptada ao Padrão da Linguagem de Modelagem Unificada - LMU (Unified Modeling Language - UML) ou a Metodologia do Processo Unificado da Rational - PUR (Rational Unified Process - RUP), conforme citado em [Cunha 2002; Rumbaugh, Jacobson e Booch, 1998; Rumbaugh, Jacobson e Booch, 2000]. A Figura 1 apresenta a metodologia adotada. 1ª Etapa Pré-Análise 2ª Etapa Desenvolvimento 3ª Etapa Implementação 1 a Con texto 2 a Obje tivo 3 a Título 4 a Esp.de Req. 1 a Análise 2 a Proj. de Sistema 3 a Proj de Objetos 1 a Codificação 2 a Testes 3 a Reengenharia Con tex tu a li za ção Ob je ti va ção In ti tu la ção Espe cifi cação de Requisitos! Mod Funcional! Mod Objetos! Mod Dinâmico Estrutura e Requisitos do Sistema Refinamento, Preparação e Depuração para a Implementação Geração Automática de código Testes: Caixa Branca e Caixa Preta Engenharia Reversa e Sincronização 1 ª Revisão 2 ª Revisão 3 ª Revisão 4 ª Revisão Linha Base de Proj de Objeto 5 ª Revisão 6 ª Revisão 7 ª Revisão Linha Base de Sincronização Linha Base de Pré- Análise Linha Base de Análise Baseline Funcional Linha Base de Proj de Sistema Baseline Alocada Linha Base de Codificação Linha Base de Implem. e Testes Baseline de Produto Figura 1: Etapas de Desenvolvimento de um Projeto [Cunha 2002] 1ª Etapa: Pré-Análise A 1ª Etapa do trabalho prático proporciona aos alunos métodos e técnicas para identificar o problema e as propostas de solução para o mesmo, assim como a especificação dos requisitos [Cunha 2002]. Esta etapa abrange a s de Contextualização, Objetivação, Intitulação e Especificação de Requisitos. A de Contextualização visa apresentar de forma clara e sucinta o contexto sob o qual o protótipo encontra-se inserido. A de Objetivação permite identificar o problema, enunciando o problema e a solução escolhida, e reduzir o escopo do sistema. Baseando-se nessas informações torna-se possível especificar os

4 requisitos do Protótipo de Sistema, assim como identificar o seu Título, considerando a solução escolhida. 2ª Etapa: Desenvolvimento Esta etapa abrange as s de Análise, Projeto de Sistema e Projeto de Objeto. Nela, faz-se necessário utilizar o paradigma da Orientação a Objetos, o Padrão UML e uma metodologia de desenvolvimento de software orientada a objetos (OMT ou RUP). Para auxiliar o desenvolvimento das atividades exigidas por esta etapa, torna-se indispensável o uso de I-CASE-E, tais como Rational Rose e UML Suíte da Telelogic, visando aumentar o nível de familiarização e compreensão dos Alunos sobre esses ambientes. 3ª Etapa: Implementação A terceira etapa apresenta as s de Codificação, Testes e Sincronização. A de Codificação prevê a Geração Automática de Esqueletos de Código a partir da modelagem na ferramenta CASE utilizada, da Sincronização, da Engenharia Direta, da Engenharia Reversa e da Implementação das funcionalidades especificas de determinados métodos. Na de Testes são ensaiadas e analisadas as funcionalidades do protótipo desenvolvido, certificando-se que as mesmas estejam atendendo aos requisitos especificados. Após o desenvolvimento da versão inicial do projeto, com alto grau de abstração, os alunos são reagrupados para os níveis de integração, baseando-se nas funcionalidades dos subsistemas desenvolvidos. 1º Nível de Integração O 1º nível de integração reúne um conjunto de alunos que desenvolveram subsistemas afins, permitindo o desenvolvimento de um novo protótipo, unificando suas funcionalidades. Neste nível, todas as etapas de desenvolvimento do protótipo devem ser revisadas, de forma que o novo subsistema seja devidamente documentado. 2º e 3º Níveis de Integração Esses níveis de integração unificam, de forma mais ampla, os subsistemas gerados pelos grupos, até atingirem um protótipo único para cada disciplina. Em todos os níveis de integração, faz-se necessária a revisão da modelagem, documentação, implementação e testes, permitindo-se a integração das funcionalidades dos subsistemas sem que os mesmos percam suas funcionalidades iniciais. Para facilitar essas integrações, os alunos são reagrupados e cada um desempenha um papel dentro do seu grupo, exercendo funcionalidades diferenciadas, tais como: Especificador, Modelador, Documentador e Programador. A divisão das funcionalidades pelos alunos facilita as próximas integrações, pois nos novos grupos formados, cada membro estará especializado no desenvolvimento de uma das atividades. Desta forma, no 2º e no 3º nível, as integrações são realizadas de acordo com as funcionalidades dos sistemas, prevendo um sistema mais geral. Assim, especificadores dos subsistemas, refazem as especificações gerais em níveis cada vez mais altos; modeladores, documentadores e programadores respectivamente remodelam, redocumentam e reimplementam o sistema resultante da Integração.

5 Esta sistemática possibilita aplicar em diversas disciplinas, diferentes técnicas de desenvolvimento prático e experimental. A próxima seção apresenta um Estudo de Caso desenvolvido com sucesso nas disciplinas: CES-32, CE-230, CES-63 e CE-235 no ITA, nos anos de 2001 e Estudo de Caso: Protótipos da Estação de Controle VIGILANTE Integrada ao Sistema Embarcado do Veículo TRIPHIBIUS O Estudo de Caso escolhido baseou-se na problemática do ambiente CNS/ATM, mais especificamente no Projeto do Veículo Experimental do tipo Carro Anfíbio Voador - TRIPHIBIUS, que prevê um veículo tripulado ou não, capaz de voar, deslocar-se em hidrovias ou rodovias, possuindo um nível adequado de controle fornecido por uma Estação de Controle denominada VIGILANTE, principalmente no caso da versão não tripulada do veículo Cenário O cenário principal pode ser dividido em dois. O primeiro cenário enfoca a necessidade de soluções para os constantes engarrafamentos existentes nos grandes centros urbanos, devido ao excesso de veículos. O segundo cenário aborda a necessidade de vigilância do grande quintal brasileiro, inóspito, chamado Amazônia Primeiro Cenário: Uma Solução para o Tráfego nos Centros Urbanos Hoje, nos grandes centros urbanos existem grandes concentrações de carros, causando engarrafamentos, gastos com combustíveis e perda de tempo pelos motoristas, em quase todas as principais avenidas das cidades. A criação de um veículo tripulado que voe e desloque se em rodovias ou hidrovias, apesar de ser uma idéia considerada por alguns como futurista, pode vir a se tornar uma solução viável para as dificuldades acima citadas, já que existem espaço aéreo, rodovias e rios em abundância, nas grandes cidades Segundo Cenário: Uma Solução para a Vigilância da Amazônia O território brasileiro possui grandes áreas inóspitas e de difícil acesso, principalmente na região Norte, abrangendo 60% do território nacional e incluindo a Amazônia. Devido à dificuldade de fiscalização pelas autoridades, partes desse território vêm sendo utilizadas de forma inadequada, como por exemplo, para o tráfico de drogas, contrabando, desmatamento de florestas, etc. Apesar do grande esforço que vem sendo realizado pelo governo nos últimos anos, a Amazônia ainda encontra-se desprovida de um sistema de controle e monitoramento adequado para os baixos níveis do espaço aéreo, rios e rodovias que permita aos órgãos governamentais atuarem em sua defesa, assim como controlar seus recursos, bem como a invasão desordenada (e às vezes ilícita) da região. Os órgãos de controle encontrados hoje na região abrangem pequenas áreas, e ainda não possuem uma integração geral nos baixos níveis. Neste cenário um Veículo tripulado ou não, com as características apresentadas pelo TRIPHIBIUS, monitorado por um Centro de Controle, poderia ser de grande utilidade para auxiliar na vigilância dessas áreas.

6 Projetos Experimentais do Veículo TRIPHIBIUS e da Estação VIGILANTE O Projeto do TRIPHIBIUS prevê uma Estação de Controle, denominada VIGILANTE, para o monitoramento de veículos tripulados ou não. Além de não existir no mercado, veículos capazes de atender as necessidades de deslocamentos rápidos, transportes de pequenos grupos de pessoas entre centros urbanos, e até mesmo operações flexíveis em regiões inóspitas como a Amazônia [TRIPHIBIUS 2002], também não existe ainda um Centro de Controle adequado para monitorá-los. O Veículo TRIPHIBIUS: A idéia original descreve o TRIPHIBIUS como um veículo, capaz de operar com agilidade, a partir de rios, lagos, superfícies curtas e até pouco preparadas, podendo representar uma alternativa de solução viável para os problemas de transporte que afligem a sociedade moderna. O resultado do projeto visa o desenvolvimento de um Carro Anfíbio Voador capaz de comportar-se como um carro nas rodovias, como uma aeronave nas aerovias e como um barco em pequenos portos e hidrovias [TRIPHIBIUS 2002]. Um veículo desta categoria tripulado ou não, exige controles e monitoramentos mais rígidos. Estação VIGILANTE: Para o monitoramento dos veículos TRIPHIBIUS, faz-se necessária uma Estação de Controle com os recursos encontrados nos aeroportos para o controle do tráfego aéreo, das hidrovias e das rodovias. Como esses veículos podem ser tripulados ou não, seus controles devem ser mais rigorosos e automatizados. Diferentemente do sistema embarcado para o TRIPHIBIUS, a estação VIGILANTE ainda não possui nenhum protótipo ou estudo para o seu sistema de controle. Diante disso, a temática escolhida para as disciplinas em 2002 envolveu a modelagem e a implementação de um conjunto de Subsistemas para a Estação de Controle VIGILANTE. O seu protótipo foi inicialmente especificado nos 4 (quatro) Subsistemas de: 1) Comunicação e Navegação; 2) Vigilância e Segurança de Vôo; 3) Gerenciamento de Fluxo em Rota; e 4) Gerenciamento de Tráfego em Terminais Aplicando a Metodologia de Desenvolvimento ao Estudo de Caso Primeiramente cada grupo de alunos realizou a 1ª Etapa da Pré-Análise, conforme descrito no item 2. Em seguida, realizou-se a 2ª Etapa de Análise, e finalmente, a 3ª Etapa de Implementação ª Etapa: Pré-Análise Nesta Etapa foram realizadas as s de Contextualização, Objetivação, Intitulação e Especificação de Requisitos. de Contextualização O Projeto TRIPHIBIUS prevê um veículo tripulado ou não. Desta forma, notou-se a necessidade de prover uma Estação de Controle em terra que permita controle e acompanhamentos dos referidos veículos. O Sistema da Estação de Controle é responsável pelo controle do veículo em terra e possibilita a execução de tarefas tais como: controle em rota, navegação, comunicação, vigilância, segurança em vôo, etc, para atender os Requisitos Técnicos, Logísticos e Industriais Preliminares - RTLIP de desenvolvimento do protótipo de um Projeto Piloto para o Sistema de Software e a ser embarcado na Estação Experimental de Controle VIGILANTE.

7 A Estação de Controle VIGILANTE é desenvolvida para apoiar o emprego do veículo TRIPHIBIUS, e possui Requisitos de Sistemas Embarcados similares aos descritos nos artigos da Empresa CDL Systems, de Calgary, Alberta, Canadá: "Ground Control Station Capabilities" e "A General Purpose Control Station for Unmaned Vehicles" [Weiler, Wong e Vila 2001]. de Objetivação A técnica de Objetivação prevê a definição exata do problema a ser resolvido, por meio da identificação dos efeitos adversos, das causas, da tarefa e do propósito pelo qual estas atividades devem ser realizadas [Cunha 2002]. Objetivo do Protótipo: Desenvolver o Sistema da Estação de Controle VIGILANTE para o TRIPHIBIUS, com um conjunto de recursos de software que possibilite o comando e a navegação precisa do veículo, viabilizando a execução de suas missões da forma mais eficiente possível, bem como vigiar o espaço aéreo em que este se encontra. Além disso, o sistema deve possibilitar a execução de procedimentos comuns ao gerenciamento de terminais aeroportuários dentro do contexto do TRIPHIBIUS. de Intitulação O título para o enunciado da solução escolhida foi Protótipo do Sistema VIGILANTE. de Especificação de Requisitos A versão do protótipo desenvolvido buscou atender alguns dos requisitos identificados para uma Estação de Controle. O Protótipo do Sistema Embarcado da Estação VIGILANTE dever ser capaz de propiciar: 1. A comunicação efetiva e segura com o TRIPHIBIUS e com outras Estações VIGILANTE; 2. O monitoramento e o controle remoto da navegação do veículo TRIPHIBIUS; 3. A execução da Pré-Vôo: a) Validar plano de vôo, b) Autorizar posicionamento na cabeceira da pista, e c) Taxiar; 4. A execução das s de Vôo: a) Autorizar diferentes fases de vôo, b) Decolar, c) Voar em rota, d) Aproximar, e e) Aterrissar; 5. O controle de limites de vôo: a) Comunicar e Confirma mudança de área de controle, e b) Transferir entre áreas de controle; 6. O Controle de posicionamento para: a) Monitorar latitude, longitude e altitude (posição, direção e velocidade), e b) Monitorar distância entre aeronaves ª Etapa: Desenvolvimento As s de desenvolvimento do sistema foram auxiliadas pelo uso das ferramentas CASES disponíveis no ITA: a UML Suite da Telelogic; e a Rational Rose da Rational. A metodologia utilizada baseou-se na OMT, adaptada ao padrão UML, inicialmente utilizando a ferramenta UML Suíte e posteriormente no Projeto final de integração, a ferramenta Rational Rose. Nessas s, geraram-se os modelos Funcional, de Objetos e Dinâmico. A Figura 2 mostra Diagramas de Caso de Uso geral do Sistema VIGILANTE. Já a Figura 3 mostra um Digrama de Seqüência. A Figura 4 apresenta exemplos de Digramas de Transição de Estados, e finalmente, a Figura 5 exibe um trecho do Diagrama de Classes gerado para o sistema.

8 ª Etapa: Implementação e Testes A ferramenta CASE Rational Rose depois de realizado o processo de modelagem, gerou automaticamente o código fonte em linguagem Java. O código gerado apresenta as classes do modelo de Objetos com seus respectivos atributos, relacionamentos e assinaturas dos métodos. As funcionalidades particulares dos métodos necessitam ser implementadas pelos programadores. As implementações dos métodos foram realizadas de acordo com os itens especificados nos requisitos do sistema, desta forma validando suas funcionalidades. Figura 2.a) Figura 2.b) Figura 2: Diagramas de Caso de Uso do Sistema VIGILANTE Figura 3: Diagrama de Seqüência para Atualização de Posicionamento

9 Figura 4.a) Transferência de Controle das Aeronaves pelos Centros de Controle Figura 4.b) Mudança de Nível de Vôo Figura 4: Digramas de Transição de Estados Figura 5: Diagrama de Classes do Pacote Comunicação Classes de Integração entre a Estação VIGILANTE e o veículo TRIPHIBIUS 3.3. Integrações Na integração, os alunos foram expostos a problemas práticos do mercado de trabalho, onde sistemas devem ser integrados com novos sistemas ou com outros sistemas existentes. Desta forma, tornou-se necessária a avaliação prévia dos sistemas existentes e a identificação dos possíveis caminhos para a união desses sistemas, sem que houvesse perdas de funcionalidades. 1º Nível de Integração O primeiro nível de integração uniu o Subsistema de Gerenciamento de Fluxo em Rota e o Subsistema de Gerenciamento de Tráfego em Terminais, originando o primeiro Protótipo FLUXO-ROTA-TERM do Sistema da Estação de Controle VIGILANTE. A integração desses Subsistemas acarretou na realização novamente das 3 etapas da metodologia, sendo necessária uma nova documentação de todas as s.

10 2º Nível de integração Este nível de integração propiciou a realização da união corporativa dos Grupos de Sistemas de Software Embarcados Afins na Estação de Controle VIGILANTE. Para isso, desenvolveu-se uma nova atualização na documentação e implementação dos softwares integrados. Algumas mudanças foram necessárias para que os sistemas pudessem se comunicar. Desenvolvidos isoladamente e funcionando de forma autônoma, estes Sistemas requeriam uma certa análise e remodelagem para funcionar de forma integrada. Após análises do funcionamento individual de cada Subsistema, tornou-se possível realizar a comunicação de informações entre eles, como apresentada abaixo: - Integração dos Subsistemas: FLUXO-ROTA-TERM e SEGU-AERO-PORTO Esta integração foi realizada através da base de dados denominada CNSATM, desenvolvida no gerenciador de banco de dados Access. As Tabelas CheckIn, CheckOut e CheckList fazem parte do Subsistema SEGU- AERO-PORTO, tendo ligação com o Subsistema de FLUXO-ROTA-TERM por meio do relacionamento com a tabela PlanoVoo. O Subsistema SEGU-AERO-PORTO realiza o check-in de passageiros/bagagens e checklist do veículo e armazena todas as informações no Banco de Dados, o qual é lido pelo Subsistema FLUXO-ROTA-TERM que se utiliza das informações para liberar o veículo para decolagem, sendo responsável pela veículo até o destino contido no plano de vôo. No destino, o Subsistema SEGU-AERO-PORTO realiza o check-out de passageiros/bagagens e checklist do veículo e é responsável pela liberação dos passageiros/bagagens no terminal de desembarque. - Integração dos Subsistemas: FLUXO-ROTA-TERM e COMU-NAVE-VIGI A integração desses dois Sistemas envolveu a alteração do código fonte e troca de informação. O Sistema COMU-NAVE-VIGI ficou responsável pela comunicação da Estação VIGILANTE e o FLUXO-ROTA-TERM com o controle dos veículos tanto nos Terminais como nos Vôos em Rota. Criou-se uma nova classe denominada VIGILANTE, para iniciar o Sistema. Esta classe inicia a aplicação do Sistema de comunicação COMU-NAVE-VIGI e o Sistema FLUXO-ROTA-TERM. Após criar um objeto que instancia o sistema de comunicação, passa este objeto para o sistema FLUXO-ROTA-TERM, visando manter uma forma de interação entre os dois sistemas. O sistema FLUXO-ROTA-TERM é uma aplicação Java. Tem como característica principal ser uma aplicação distribuída, rodando sob a tecnologia RMI da linguagem Java. Com esta característica é possível se executar, em diversos locais, cópias do Sistema, permitindo-se que estes Sistemas interajam entre si (comunicação entre Estações de Controle VIGILANTE). Além da comunicação com sistemas de mesmo tipo (Sistema VIGILANTE instalado em diferentes Centros de Controle), o Sistema VIGILANTE comunica-se com os veículos TRIPHIBIUS por ele controlados. 3º Nível de Integração Com a integração dos Sistemas Afins da Estação de Controle VIGILANTE, tornando um módulo conciso de software, e principalmente, com a característica distribuída do Sistema, trabalhando como uma aplicação Cliente/Servidor, foi possível que os sistemas de controle embarcados no veículo TRIPHIBIUS, trocassem informações com a estação

11 de controle VIGILANTE. A figura 6 apresenta o esquema de integração/comunicação entre os Sistemas embarcados da Estação VIGILANTE e do veículo TRIPHIBIUS. HIDRA- ARMA COMU- NAVE- MAPA Triphibius CONTE- PORTE- COMB COMU- NAVE- VIGI SEGU-AERO- PORTO FLUXO- ROTA- TERM CNS ATM Figura 6: Esquema de Integração e comunicação do Protótipo de Software Embarcado da Estação de Controle VIGILANTE e do Veículo TRIPHIBIUS A integração dos Sistemas VIGILANTE e TRIPHIBIUS ocorreu por meio da transformação das duas aplicações em sistemas distribuídos, utilizando-se a tecnologia RMI da linguagem Java. Ambos os sistemas funcionam como aplicações Cliente/Servidor podendo trocar mensagens entre si. 4. Principais Resultados Obtidos Este experimento prático permitiu desenvolver o Primeiro Protótipo para a Estação de Controle VIGILANTE. O sistema VIGILANTE prevê procedimentos para validar as informações recebidas em um Plano de Vôo, para controlar as filas de decolagem e pouso dos veículos, para realizar a comunicação e transferência do controle dos veículos de um Centro de Controle para outro, e para controlar o fluxo aéreo dentro de cada Centro. Como se trata de um protótipo, não foi possível implementar todas as funcionalidades planejadas, existindo algumas em operação, tais como: Validação do Plano de Vôo, Controle de Mensagens Recebidas e Enviadas, Comunicação entre os Sistemas Embarcados do TRIPHIBIUS e Sistema da Estação de Controle VIGILANTE, Interação entre vários Centros de Controles Distribuídos, incluindo Comunicação e Transferência de Controle dos veículos, Controle de Rota, entre outras. O sistema VIGILANTE apresenta duas interfaces, uma para estabelecer a comunicação e outra para o controle e a visualização dos veículos TRIPHIBIUS, como

12 mostra a Figura 7. A Interface da versão atual do Protótipo de Software do Veículo TRIPHIBIUS pode ser visualizada na Figura 8. Figura 7: Interface de Comunicação e Controle da Estação VIGILANTE Figura 8: Interface do Protótipo do TRIPHIBIUS [Cunha 2002] 5 Conclusões e Recomendações Este artigo teve como objetivo apresentar um exemplo bem sucedido da utilização e do desenvolvimento de Projetos práticos em disciplinas no ITA, empregando tecnologias que representam o estado da arte na área de Engenharia de Software, tais como: Ferramentas I-CASE-E, Metodologias Orientadas a Objetos e o Padrão UML. Esta experiência demonstrou ser possível realizar com sucesso atividades práticas vivenciadas em ambientes reais do mercado de trabalho mesmo em instituições acadêmicos. Também demonstrou que o uso de tecnologias de ponta pode facilitar as atividades de desenvolvimentos de aplicações, desde que utilizadas baseadas em metodologias de desenvolvimento, tais como: OMT e RUP. Além do protótipo modelado e implementado, esta sistemática de ensino permitiu aos alunos aplicar o conteúdo teórico das disciplinas em um projeto prático, visando fundamentar os conhecimentos adquiridos. Com o desenvolvimento do protótipo de Software, tornou-se possível estar em contato com problemáticas do CNSATM, principalmente, viabilizando e acrescentando funcionalidades automatizadas aos sistemas existentes. As aplicações de Software desenvolvidas objetivaram solucionar ou auxiliar no controle de algumas das tarefas

13 consideradas críticas nesse ambiente, como o controle do fluxo de tráfego aéreo, segurança, comunicação, entre outras. Esta sistemática direciona os alunos ao trabalho em equipe, expondo-os a problemáticas reais e cotidianas. Temáticas reais motivam os alunos a desenvolverem seus projetos práticos, utilizam-se dos conceitos teóricos apresentados em aula. Agradecimentos Os autores deste artigo agradecem ao Departamento de Controle do Espaço Aéreo (DECEA) e ao Centro Técnico Aeroespacial (CTA), pelas bolsas do projeto Communications, Navigation and Surveillance / Air Traffic Management (CNS/ATM), que viabilizaram as pesquisas e o desenvolvimento deste trabalho, na divisão de Ciência da Computação do ITA. Referências Bibliográficas: CUNHA, Adilson Marques da. Projeto do Sistema TRIPHIBIUS, pesquisado em novembro de CUNHA, Adilson Marques da, FOLLMANN, Zsolt Eugenio Geza. Triphibian Flying Car Design, In: World Aviation Congress & Exposition 97, Society of Automotive Engineers - SAE, 97WAC-111, Anahein, CA, USA, October 13-16, RUMBAUGH, James; JACOBSON, Ivair; BOOCH, Grady, Modelagem Visual com Rational Rose 2000 e UML. ADDISON-WESLEY RUMBAUGH, James; JACOBSON, Ivair; BOOCH, Grady, The Rational Unified Process. An Introduction. Second Edition. ADDISON-WESLEY WEILER, David R., WONG, Tony e VILA, Wladimir. A General Purpose Control Station for Unmaned Vehicles, pesquisado em setembro de 2001.