Anais do 13 O Encontro de Iniciação Científica e Pós-Graduação do ITA XIII ENCITA / 2007 Instituto Tecnológico de Aeronáutica São José dos Campos SP Brasil Outubro 01 a 04 2007. ESPECIFICAÇÃO DE REQUISITOS MODELAGEM E IMPLEMENTAÇÃO DE UM SISTEMA DE SOFTWARE EMBARCADO E DE TEMPO REAL PARA OS SUB-SISTEMAS DE CONTROLE DE VÔO POTÊNCIA E COMBUSTÍVEL DE UM VEÍCULO AÉREO NÃO TRIPULADO VANT César Augusto Melo Haenisch Filho Instituto Tecnológico de Aeronáutica Bolsista PIBIC-CNPq Correio eletrônico: he1000ton@gmail.com Adilson Marques da Cunha Instituto Tecnológico de Aeronáutica Correio eletrônico: cunha@ita.br Diogo Branquinho Ramos Instituto Tecnológico de Aeronáutica Correio eletrônico: diogobranquinho@gmail.com Resumo. Esta pesquisa em nível de Iniciação Científica (IC) teve por objetivo dotar o Software de um Veículo Aéreo Não Tripulado - VANT de um Componente de Software de Computador (CSC) composto pelos seguintes Sub-Sistemas ou Unidades de Software de Computador (USC): USC de Controle de Vôo USC de Potência e USC de Combustível. Para isso foram utilizadas Ferramentas de Engenharia de Software Ajudada por Computador (Computer Aided Software Engineering - CASE) em atendimento à especificação de alguns requisitos pré-definidos. O trabalho foi dividido em duas Fases: Capacitação Tecnológica do Bolsista e Modelagem e Implementação dos Sub- Sistemas ou USCs. Na Fase inicial de Capacitação realizou-se pesquisas sobre o Processo Unificado da Rational (Rational Unified Process - RUP) a Linguagem de Modelagem Unificada (Unified Modeling Language - UML) e os Sistemas Embarcados de Tempo Real em paralelo com treinamentos na Ferramenta IBM Rational Rose RealTime (RRRT) e numa Ferramenta de Software Livre para Estimativas em Pontos de Casos de Uso (EPCU). Na Fase final de Modelagem e Implementação desenvolveu-se e integrou-se com sucesso os três Sub-Sistemas ou USCs num CSC de Controle de um VANT. Palavras chave: Sistemas Embarcados e de Tempo Real Modelagem Visual VANT. 1. Introdução O Projeto VANT tem por objetivo propiciar o desenvolvimento de um veículo capaz de ser operado e mantido em nível orgânico como: um conjunto auto-suficiente de dispositivos de hardware e software que possa ser pilotado manualmente dentro de um alcance visual; remotamente a partir de uma Estação Solo por meio de comandos enviados a um Software de Navegação e Controle (SNC); ou autonomamente por intermédio de um plano de vôo prédeterminado. Diferentemente dos produtos de prateleira obtidos o software crítico embarcado e de tempo real tem seu foco na implementação de funcionalidades voltadas para a solução final a ser utilizada pelos clientes. O produto deverá disponibilizar funcionalidades: de plataforma de vôo; de sistema de navegação e controle; de sistema de comunicação; e de Estação Solo com uma equipe de apoio que podem ser utilizadas tanto por usuários civis quanto por militares. Existem alternativas possíveis para o desenvolvimento deste Projeto como por exemplo contratar empresas (provavelmente estrangeiras) principalmente para desenvolver o seu software. Mas devido à natureza estratégica do produto pode tornar-se difícil ou até mesmo impossível este tipo de contratação. Em caso de contratação de uma empresa estrangeira haverá maiores custos de desenvolvimento em função da necessidade de treinamento das equipes desenvolvedoras além do usuário final não conseguir internalizar as tecnologias de desenvolvimento de software para o SNC da Plataforma de Vôo a Estação Solo e o Dispositivo de Integração de Teste (Aircraft Integration RIG AIR) causando dependabilidades de fornecedores estrangeiros. Em caso de crise haverá risco dos fornecedores nacionais e estrangeiros interromperem os respectivos suportes ocasionando também graves conseqüências aos usuários. Outras iniciativas existem no país para desenvolvimento de VANTs mais específicos e de menor porte. Entre elas destaca-se o desenvolvimento de um VANT para a vigilância de linhas de transmissão na Divisão de Engenharia
Anais do XIII ENCITA 2007 ITA Outubro 01-04 2007 Aeronáutica do Instituto Tecnológico de Aeronáutica ITA na qual o software é considerado menos sofisticado e praticamente adaptado de aeromodelos. Devido ao grau de complexidade do Projeto endereçado neste Trabalho de IC fez-se necessária a adoção de metodologias e processos. Segundo (Cunha 2006) em Engenharia de Software uma Metodologia consiste de uma série recomendada de passos e procedimentos que devem ser seguidos para se obter o desenvolvimento de um Sistema. Ela conduz ao como fazer mas não produz resultados efetivos. Enquanto um Processo representa um conjunto de passos parcialmente ordenados com a intenção de atingir uma Meta. Finalmente uma Meta pode ser entendida como a criação ou o aperfeiçoamento de um Software existente conduzindo ao como fazer e propiciando a obtenção de resultados efetivos. Destarte decidiu-se por utilizar o RUP como o processo regente deste trabalho envolvendo Engenharia de Software desenvolvido pelos metodologistas: Booch Jacobson e Rumbaugh. Conforme anteriormente mencionado o Software Embarcado e de Tempo Real de um VANT é de grande complexidade e tal qual a proposta do RUP o desenvolvimento de um Sistema desta natureza deve se utilizar de Modelagem Visual provendo um robusto conjunto de notações para a Análise e Projeto (Design) de sistemas de software. Nesta IC utilizou-se a modelagem visual por meio da UML para reduzir a complexidade envolvida no desenvolvimento das USCs. Segundo Cunha et al. (2006) em Engenharia de Software modelos são usados para auxiliar no entendimento de problemas e de processos complexos para facilitar a Comunicação entre os envolvidos num Projeto (clientes especialistas do domínio analistas projetistas etc.). Isso se torna ainda mais importante para a construção de visões em diferentes níveis de abstração filtrando-se detalhes essenciais ao entendimento do problema como um todo. Torna-se também importante tanto na documentação de decisões arquiteturais em Projetos de Software reduzindo-se ambigüidades quanto na formação de uma base para sua implementação. Na construção de modelos utilizou-se de notações de projetos gráficos textuais e semanticamente ricos para capturar os detalhes do Projeto de software. Uma vez definidos o processo e a notação para o desenvolvimento do Projeto a investigação das tecnologias supracitadas resultou na escolha da Ferramenta RRRT como parte integrante da Suíte IBM Rational. 2. Resultados Obtidos Como já descrito as atividades realizadas foram divididas em duas Fases. A 1ª Fase de Capacitação Tecnológica do Bolsista encontra-se descrita na seção 2.1 e a 2ª Fase de Modelagem e Implementação dos Sub-Sistemas ou USCs de Controle de Vôo Potência e Combustível de um VANT na seção 2.2. 2.1. 1ª Fase - Capacitação Tecnológica do Bolsista Nesta 1ª Fase do Trabalho de IC foram realizadas pesquisas sobre o RUP a UML e os Sistemas Embarcados de Tempo Real e um Treinamento para capacitação tecnológica na Ferramenta IBM RRRT e no Software Livre EPCU. O início dos trabalhos de capacitação consistiu de uma pesquisa sobre o RUP um processo de Engenharia de Software que aumenta a produtividade da equipe e propicia a utilização das melhores práticas relacionadas ao desenvolvimento de software através de diretrizes padrões e orientações sobre ferramentas para todas as atividades críticas de seu desenvolvimento. Segundo (Cunha 2006) o RUP oferece uma abordagem baseada em Disciplinas atribuindo Tarefas e Papéis dentro de uma organização de desenvolvimento de software. A sua meta principal é garantir uma produção de Software de alta qualidade que atenda às necessidades dos Usuários dentro de Cronogramas e Orçamentos previsíveis. A Figura 1 representa a Arquitetura Geral do RUP. Nela pode-se observar a existência de duas dimensões com significados distintos: 1) o eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo na medida em que ele se desenvolve portanto o aspecto dinâmico do processo em termos de fases iterações e marcos; e 2) o eixo vertical representa as Disciplinas que agrupam as Atividades de maneira lógica por natureza logo o aspecto estático do processo em termos de Componentes Disciplinas Atividades Fluxos de Trabalho Artefatos e Papéis do Processo.
Anais do XIII ENCITA 2007 ITA Outubro 01-04 2007 Figura 1. Arquitetura Geral do RUP A Figura 1 mostra como a ênfase dedicada a cada fase no desenvolvimento se altera através do tempo de forma iterativa e incremental. A UML consiste de uma linguagem de especificação documentação visualização e desenvolvimento de sistemas orientados a objetos. Ela propicia a sintetização dos principais métodos existentes e é considerada uma das linguagens mais expressivas para modelagem de sistemas orientados a objetos. Por meio de seus diagramas representa-se sistemas de softwares sob diversas perspectivas de visualização facilitando a comunicação entre as equipes envolvidas no processo de desenvolvimento de um sistema - gerentes coordenadores analistas desenvolvedores - por apresentar um vocabulário de fácil entendimento. A UML propicia também a definição de uma notação e de um meta-modelo suportando as quatro fases do ciclo de desenvolvimento de Software previstas no RUP: Iniciação Elaboração Construção e Transição. Para cada uma dessas fases do desenvolvimento utilizam-se cinco tipos de visões nove tipos de diagramas e vários modelos de elementos na criação dos diagramas e mecanismos gerais. Todos em conjunto servem para especificar e exemplificar a definição do sistema tanto na definição das funcionalidades estáticas quanto das dinâmicas do desenvolvimento de um sistema. A importância dos modelos aumenta à medida que os sistemas se tornam mais complexos. Na construção de modelos é permitido ao desenvolvedor se concentrar na visão geral entender como os componentes interagem e identificar falhas fatais. A UML possibilita a criação de modelos simples e a modificação dos mesmos a baixo custo explorando novas alternativas de projeto. Quando associada ao desenvolvimento iterativo a modelagem visual ajuda aos desenvolvedores a avaliar mudanças de projeto e a comunicar essas mudanças a toda à equipe de desenvolvimento. Utilizando-se a UML com o suporte das ferramentas adequadas um modelo de projeto pode ser usado para gerar um conjunto inicial de códigos-fonte para implementação. Neste caso tira-se proveito das técnicas de Engenharia Direta com a geração automática de códigos-fonte e de Engenharia Reversa com a sincronização de códigos-fonte com o modelo. Durante a pesquisa sobre Sistemas Embarcados de Tempo Real verificou-se que o mercado tem crescido em grandes proporções ao longo dos últimos anos. Uma grande quantidade de atividades realizadas pelo homem é auxiliada por dispositivos embarcados e a sua presença no cotidiano tende a aumentar ainda mais devido aos avanços tecnológicos. Pode-se citar sistemas de automação industrial e residencial automação automotiva controle aeroespacial equipamentos médicos entre outros. O projeto de sistemas embarcados com requisitos de tempo real possui grande complexidade pois envolve conceitos específicos pouco explorados e analisados pela computação de propósito geral. Normalmente um Projeto desses sistemas envolve a definição do hardware e do software necessários à realização da tarefa para a qual o sistema foi projetado. Existem vários fatores limitantes num Projeto desta classe de sistemas destacando a baixa quantidade de memória disponível o pouco poder de processamento o limite do consumo de energia sem perda de desempenho ou ainda o curto espaço de tempo de Projeto. Segundo (Wehrmeister Becker Pereira) o aumento do número de funções que vêm sendo incorporadas a um único sistema embarcado faz surgir a necessidade de metodologias e técnicas de projeto que visam gerenciar essa complexidade. Além disso existe a multidisciplinaridade das equipes de projeto que devem se utilizar de uma comunicação clara e uniforme de modo a minimizar os erros causados pela interpretação incorreta de requisitos e de funcionalidades do sistema. Para tentar amenizar os problemas dos Projetos de Sistemas Embarcados diminuindo sua complexidade como alternativa deve-se utilizar a Orientação a Objetos um paradigma de Engenharia de Software já consagrado para o desenvolvimento de sistemas computacionais de grande porte e robustez.
Anais do XIII ENCITA 2007 ITA Outubro 01-04 2007 Em toda a referência bibliográfica consultada para este Trabalho de IC pôde-se observar um fator comum quanto ao desenvolvimento do sistema. Em geral os sistemas são desenvolvidos utilizando-se a UML e permitindo-se padronizar a descrição em alto nível para diferentes casos propiciando-se assim a vantagem da reutilização implicando numa redução no tempo de projeto utilizando a orientação a objetos o suporte à automação a geração de modelos executáveis e a geração automática de códigos-fonte. Ademais os sistemas embarcados normalmente apresentam altas restrições em termos de funcionalidade e implementação. Em particular eles devem reagir a eventos externos em tempo real adaptar-se a limites de tamanho e peso gerenciar consumo de potência satisfazer requisitos de confiabilidade e segurança e adequar-se a restrições de orçamento. Até a década de 80 os projetos de sistemas embarcados davam ênfase maior ao desenvolvimento do hardware do que ao do software. Normalmente a parte da solução em software desses produtos costumava ser bem reduzida e servia apenas para definir como o hardware deveria operar. Até essa época como mostram (Dourado Allex) os sistemas embarcados contavam com processadores de recursos extremamente limitados nos quais a linguagem assembly era geralmente usada para programar um conjunto de funções imutáveis o que os considerava como simples programas que forneciam algum tipo de inteligência aos servosmecanismos. Ainda na Fase de Capacitação iniciou-se um treinamento na Suíte de Ferramentas CASE IBM Rational e mais especificamente no software IBM RRRT. A referida capacitação foi adquirida com a realização de um Curso de Introdução às Suítes de Ferramentas I- CASE-E constituído de 19 módulos teóricos 7 Exercícios de Aquecimento (Warm-Ups) e 6 Exercícios Práticos de Laboratório (Labs). Durante este Curso os seguintes módulos teóricos foram abordados: 1. Modelando Sistemas de Tempo Real; 2. Modelos do Rose RealTime; 3. Classes Passivas; 4. Estruturas de Cápsulas: Portas Protocolos e Capsule Roles; 5. Modelando Estados; 6. Serviços de Sistemas; 7. Análise de Requisitos; 8. Projeto de Classes; 9. Hierarquia de Estrutura; 10. Hierarquia de Herança; 11. Hierarquia de Comportamento; 12. Packanging and Layering; 13. Gerência de Configuração; 14. Integrando Código Externo; 15. Modelagem Adaptável; 16. Modelando Concorrentemente; 17. Modelos Distribuídos; e 18. Design Patterns. Uma vez fixados os conceitos aprendidos nos módulos prosseguiu-se na aplicação prática da modelagem por meio da realização dos seguintes exercícios de aquecimento: 1. Hello World; 2. Passive Classes; 3. Traffic Light; 4. Electronic Lock; 5. Battleship; 6. Traffic System; e 7. Client/Server. Por fim realizou-se os 6 Exercícios de Laboratórios seguintes: 1. Controller / Tester; 2. Valve Start Low-Temp System; 3. Complete Low-Temp System; 4. Master and Tank Containers; 5. Start High-Temperature System; e 6. Complete High-Temperature System. Esses Exercícios de Laboratório tiveram como pano de fundo um Sistema de Tingimento que possui um tanque a ser preenchido com corante para deixar o tecido por um tempo nesta condição e por fim esvaziar o tanque.
Anais do XIII ENCITA 2007 ITA Outubro 01-04 2007 A modelagem e implementação do Sistema de Tingimento encontra-se esquematizada na Figura 2. Nela pode-se observar que o sistema compõe-se de um tanque (Tank) no qual o corante permanece por algum tempo e um controle (Controller) responsável por seqüenciar o tanque durante todo o processo de tingimento. Por fim um operador (Operator) externo ao sistema programa o controle e então começa o processo de tingimento. Figura 2. Overview Dyeing System O tanque contém o tecido a ser tingido e o corante. A válvula de enchimento (fill valve) permite a entrada de corante no tanque e a válvula de drenagem (drain valve) permite a remoção deste. O sensor de nível (level sensor) informa continuamente o nível atual no tanque. O controle possui duas responsabilidades primárias: a primeira de agir segundo os comandos do operador; e a segunda de encher e drenar o tanque monitorar a quantidade de corante do tanque e o tempo de exposição do tecido ao corante. Uma vez que o operador inicia o controle este imediatamente abre válvula de enchimento permitindo ao corante encher o tanque. Quando o controle percebe que o tanque está cheio fecha essa válvula e inicia um contador (timer). Depois de um tempo predeterminado o contador dispara um aviso ao controle para abrir a válvula de drenagem. Com o tanque vazio o processo completa-se e pode-se iniciar outro tingimento conforme mostrado na Figura 3 a seguir. Figura 3. Gráfico do comportamento do sistema O sistema desenvolvido ao final desses 6 laboratórios e utilizando os conhecimentos adquiridos pode ser representado pelo Diagrama de Classes apresentado na Figura 4 a seguir.
Anais do XIII ENCITA 2007 ITA Outubro 01-04 2007 Figura 4. Diagrama de Classes para o sistema 2.2. 2ª Fase Modelagem e Implementação dos Sub-Sistemas de Controle de Vôo Potência e Combustível Para efeito deste Trabalho de Pesquisa em nível de IC os Sub-Sistemas serão chamados de Unidades de Software de Computador - USCs (Computer Software Units - CSU) os conjuntos de USCs serão chamados de Componentes de Software de Computador CSCs (Computer Software Components - CSC) os conjuntos de CSCs serão chamados de Itens de Configuração de Software de Computador ICSCs (Computer Software Configuration Items CSCI) e os conjuntos de ICSCs serão chamados de Sistema de Software de Computador SSC (Computer Software System CSS). Os CSCs podem ser formados por outros CSCs e/ou USCs enquanto que os USCs são itens discretos e não podem ser mais sub-divididos dentro da hierarquia. Os ICSCs devem ser selecionados de maneira que se permita o desenvolvimento paralelo e os testes ou seja que ocorram tão poucas dependências entre os ICSCs quantas forem necessárias. Segundo (Roetzheim 1991) alguns dos fatores para se decidir como particionar Softwares em ICSCs são: A Complexidade Funcional dos Componentes; O Tamanho Estimado e Estado Crítico dos Componentes; A Interface a Base de Dados e a Complexidade de Integração entre os componentes; A Complexidade dos Requisitos de Segurança dos Componentes; Os Requisitos de Certificação dos Componentes; A Probabilidade de Mudança durante o Ciclo de Desenvolvimento; O Estado Crítico Operacional dos Componentes; A Localização do Desenvolvimento para os Componentes; e A Agenda. Uma vez definidas as USCs e os CSCs pôde-se então passar ao desenvolvimento propriamente dito de cada deles. O desenvolvimento da USC de Controle (CTRL) de Vôo de um VANT tem por objetivo prover o controle aerodinâmico para o veículo. Para desenvolver a USC de CTRL de Vôo de um VANT foi necessário inicialmente especificar-se que ela propiciasse controle de direção de velocidade e de altitude sincronizados com a disponibilidade de combustível num intervalo de potência disponível variando de 0 a 100 %. O Diagrama de Casos de Uso elaborado para a USC de CTRL de Vôo encontra-se na Figura 5 a seguir.
Anais do XIII ENCITA 2007 ITA Outubro 01-04 2007 Figura 5. Diagrama de Casos de Uso para a USC de CTRL de Vôo de um VANT A implementação da USC de CTRL de Vôo foi realizada em 3 estados sendo 2 deles responsáveis por enviar sinais para a ativação das outras Cápsulas responsáveis respectivamente pela Potência e pelo Combustível. Os Diagramas de Seqüência de Estados e de Estruturas referentes à implementação da USC de CTRL de Vôo encontram-se a seguir na Figura 6. Figura 6: Diagramas (a) de Estados; (b) de Estrutura; e (c) de Seqüência da USC de CTRL de Vôo de um VANT Note-se a existência de algumas transições entre os 3 Estados desta USC e também de ações de entradas nos Estados Solicita_Nível e Altera_altura. A transição altura é ativada quando um sinal doravante chamado de Out_Sinal_Alterar_Altura é enviado pela porta Porta_V_CTR_Recebe e ativa Solicita_Nível que por sua vez deve enviar um sinal doravante chamado Out_Verifica_Nivel pela porta Porta_V_CTR_SolicitaN_Comb a fim de ativar na Cápsula responsável pelo Combustível uma ação para informar a quantidade de combustível no tanque. Por essa mesma porta o sinal In_Verifica_Nivel aciona a transição nível que deve passar pelo ponto de escolha Verif_Comb_Missao para verificar se há combustível suficiente para realizar a mudança de altura solicitada por Out_Sinal_Alterar_Altura. Se houver passa-se para Altera_altura onde há o envio do sinal Out_Alterar_Potencia pela porta Porta_V_CTR_Envia a fim de alterar a potência do motor utilizando uma ação na Cápsula responsável pela Potência. Em caso contrário volta-se ao estado inicial. Para a realização das comparações e enviar os sinais necessita-se de 2 atributos denominados AlturaRequerida e Nível_Combustível. A implementação da USC de CTRL de Vôo numa Cápsula gerou um total de 615 linhas de código-fonte. O desenvolvimento da USC de Potência (POTE) de um VANT tem por objetivo prover o controle propulsivo do veículo. Para desenvolver a USC de POTE de um VANT foi necessário que se especificasse suas alterações de potência num intervalo entre 0 a 100% de acordo com a solicitação da cápsula de controle de vôo. O Diagrama de Casos de Uso elaborado para a USC de POTE de um VANT encontra-se na Figura 7 a seguir.
Anais do XIII ENCITA 2007 ITA Outubro 01-04 2007 Figura 7: Diagrama de Casos de Uso para a USC de POTE de um VANT A implementação da USC de POTE foi realizada em 3 estados e uma série de transições culminando ou não em pontos de escolha. Os Diagramas de Seqüência de Estados e de Estruturas referentes à implementação da USC de POTE encontramse a seguir na Figura 8. Figura 8: Diagramas (a) de Estados; (b) de Estrutura; e (c) de Seqüência da USC de POTE de um VANT. Ativou-se a transição Potencia pelo sinal Out_Alterar_Potencia recebido pela porta Porta_V_CTR_Recebe culminando no ponto de escolha Potencia_Mudou com o objetivo de verificar caso necessário a alteração na potência do motor. Realizou-se tal verificação via dois atributos PotenciaRequerida e PotenciaAtual verificação esta que resultará em mudança de estado ou então retorno ao estado inicial. Mesmo que a mudança de estado ocorra necessita-se alterar a potência do motor precisando-se ainda determinar se essa mudança é um aumento ou uma diminuição. Tal determinação é realizada com a utilização de outro ponto de escolha que culminará em outros dois estados: Aumenta_Potencia e Diminui_Potencia. Na transição desses dois estados para o estado inicial deve haver o envio de um sinal Out_Alterar_Vazao pela porta Porta_VPOT_Envia a fim de ativar na Cápsula responsável pelo Combustível uma ação para alterar a vazão de combustível no tanque e por conseguinte a potência do motor. A implementação da USC de POTE numa Cápsula gerou um total de 670 linhas de código-fonte. O desenvolvimento da USC de Combustível (COMB) de um VANT tem por objetivo prover o controle do consumo de combustível do veículo. Para desenvolver a USC de COMB de um VANT foi necessário inicialmente especificar-se que há necessidade de se controlar o nível de combustível num intervalo de 0 a 100% alterando-se o seu fluxo de acordo com a potência solicitada. O Diagrama de Casos de Uso elaborado para a USC de COMB encontra-se na Figura 9 a seguir.
Anais do XIII ENCITA 2007 ITA Outubro 01-04 2007 Figura 9: Diagrama de Casos de Uso da USC de COMB de um VANT A implementação da USC de COMB foi realizada através de 3 Estados e uma série de transições. Os Diagramas de Estados de Estrutura e de Seqüência referente a essa modelagem é mostrado na Figura 10 a seguir. Figura 10: Diagramas (a) de Estados; (b) de Estrutura; e (c) de Seqüência da USC de COMB de um VANT. A transição verifica é acionada pelo sinal Out_Verifica_Nivel recebido pela porta Porta_VCOMB_Recebe_Ped_N_Comb culminando em Verificar_Nivel que por sua vez deve enviar o sinal In_Verifica_Nivel pela porta Porta_VCOMB_Recebe_Ped_N_Comb informando o nível de combustível via o atributo Nivel_Comb. Aciona-se a transição altera pelo sinal Out_Alterar_Vazao recebido pela porta Porta_VCOMB_Recebe culminando em Alterar_Vazao estado o qual deve realizar a alteração no nível de combustível atual via o atributo VazaoAtual. Ambas as transições retorna são transições com o objetivo de retorno ao estado inicial após um timeout a fim de que se possa realizar sucessivas alterações no nível de combustível. A implementação da USC de COMB numa Cápsula gerou um total de 548 linhas de código-fonte. O desenvolvimento do CSC de Controle (CTR) de um VANT integra as três USCs anteriormente desenvolvidas de modo que os controles aerodinâmico propulsivo e de consumo de combustível estejam interligados e possam realizar as devidas alterações entre si. O desenvolvimento do Diagrama de Caso de Uso deste CSC contemplou a maneira como os Sub-Sistemas deveriam se comportar individualmente entre si e interagindo com os respectivos Atores e Casos de Uso envolvidos conforme mostrado na Figura 11 a seguir.
Anais do XIII ENCITA 2007 ITA Outubro 01-04 2007 Figura 11: Diagrama de Casos de Uso para o CSC de CTR de um VANT. A implementação desta CSC de CTR de um VANT foi realizada por meio de três Capsule Roles baseadas nas três Cápsulas anteriormente implementadas. O Diagrama de Seqüência e de Estruturas referente a tal modelagem é apresentado nas Figura 12 e Figura 13 a seguir. Figura 12: Diagrama de Seqüência do CSC de CTR de um VANT
Anais do XIII ENCITA 2007 ITA Outubro 01-04 2007 Figura 13: Diagrama de Estruturas do CSC de CTR de um VANT Para existir a comunicação entre as Cápsulas ou seja para que os sinais de uma Cápsula possam atuar em outras os três Capsule Roles devem comunicar-se entre si utilizando as portas corretas com as devidas conjugações. A USC de CTRL de Vôo comunica-se: com a USC de COMB por meio das portas Porta_V_CTR_SolicitaN_Comb e Porta_VCOMB_Recebe_Ped_N_Comb; e com a USC de POTE via as portas Porta_V_CTR_Envia e Porta_VPOT_Recebe. A USC de POTE comunica-se com a USC de COMB utilizando-se respectivamente das portas Porta_VPOT_Envia e Porta_VCOMB_Recebe. Algumas considerações estatísticas sobre o Desenvolvimento do CTR de um VANT merecem ser citadas. Para a implementação da CSC de CTR de um VANT foram utilizadas quatro Cápsulas um Protocolo e geradas um total de 2722 linhas de código-fonte. Este desenvolvimento foi baseado em (Chagas Silva Franco 2006) documentação constante em dez Artefatos do RUP dos Protótipos de Projeto de USCs e CSCs. O Diagrama de Classe obtido ao final do desenvolvimento do CSC de CTR de um VANT encontra-se mostrado na Figura 14 a seguir. Figura 14: Diagrama de Classes do CSC de CTR de um VANT Os Tipos e quantidades de Diagramas da UML utilizados neste Trabalho de IC encontram-se listados na Tabela 1 a seguir.
Anais do XIII ENCITA 2007 ITA Outubro 01-04 2007 Tabela 1: Tipos e Quantidades de Diagramas da UML Tipo de Diagramas Quantidades Diagramas de Casos de Uso 8 Diagramas de Seqüências 4 Diagramas de Estados 3 Diagramas de Estruturas 4 Diagramas de Classes 1 Total 20 Para realizar uma Estimativa de Esforços baseada em Casos de Uso foi utilizado o EPCU desenvolvido por (Silva 2006) que propicia estimativas de esforços de desenvolvimento de software baseadas em parâmetros inseridos pelo Usuário sobre Casos de Uso e Atores criados no IBM RRRT. Ajustando-se os pesos dos Atores e dos Casos de Uso do CSC de CTR de um VANT e levando-se em consideração que somente o bolsista realizando esta Pesquisa em nível de IC poderia estar envolvido neste Projeto as principais estimativas e resultados que esta ferramenta propicia encontram-se detalhados nas Figura 15 16 e 17 a seguir. Figura 15: Estimativa de Esforços Baseada nos Diagramas de Casos de Uso Figura 16: Pesos dos Atores e Casos de Uso Interpretando-se os dados apresentados na Figura 17 constata-se que para desenvolver de forma completa todos os Sub-Sistemas de Controle do Vôo Potência e Combustível de um VANT estima-se que com uma Percentagem de Segurança (folga) de 15 % uma pessoa (como o bolsista desta IC) com Dedicação Mensal na Equipe de 80 horas de trabalho levaria 3051 meses ou 254 anos.
Anais do XIII ENCITA 2007 ITA Outubro 01-04 2007 Figura 17: Valores para Estimativa de Esforços 3. Conclusões Para o desenvolvimento com sucesso do Protótipo de Software envolvendo as 03 (três) USCs (de Controle de Vôo de Potência e de Combustível) e as suas integrações num só CSC de Controle de um VANT foram utilizados: 10 (dez) artefatos do RUP; 20 (vinte) Diagramas da UML de 05 (cinco) diferentes tipos; geradas 2.722 linhas de código-fonte; a partir de duas ferramentas CASE uma para Especificação de Requisitos Modelagem e Implementação e outra para cálculo de Estimativas de Esforços por Pontos de Casos de Uso. O Software utilizado mostrou-se bastante poderoso e apropriado para a modelagem e utilização na Solução de Problemas de Engenharia. O autor deste Trabalho de Pesquisa após a sua realização sente-se devidamente capacitado para utilizar a Ferramenta CASE IBM RRRT em seu futuro Trabalho de Graduação (TG). Os novos conhecimentos adquiridos permitem vislumbrar soluções novas para os problemas relacionados com a área de Controle da Engenharia Aeronáutica. Com o treinamento realizado foi possível sentir-se capacitado a realizar novas tarefas de modelagem de sistemas embarcados de tempo real e aplicar conceitos e Ferramentas de Modelagem Visual que representam o estado da arte o estado da técnica e o estado da prática em termos de Engenharia de Software ajudada por computador. Durante a sua realização ficou evidente que este Trabalho de IC tem o potencial de propiciar ainda grandes frutos para a continuidade da pesquisa a ser endereçada sob a forma de um TG para o autor dentro da mesma Linha de Pesquisa. Mais tarde outras pesquisas ainda com maior nível de profundidade poderão ser realizadas em nível de Tese de Mestrado. 4. Agradecimentos Agradeço às pessoas envolvidas no Projeto e mais diretamente ao Prof. Dr. Adilson Marques da Cunha e aos Alunos de Pós-Graduação do ITA Diogo Branquinho Ramos Caio Monteiro e Débora Aparecida Chagas que até a data de publicação deste artigo me apoiaram com os seus conhecimentos na área de Engenharia de Software propiciandome aprender cada vez mais sobre a modelagem e o desenvolvimento do importante Projeto do Veículo Aéreo Não Tripulado VANT. Agradeço também ao CNPq que vinculado ao Ministério da Ciência e Tecnologia (MCT) vem apoiando as pesquisas brasileiras contribuindo diretamente para a formação de jovens pesquisadores investindo e promovendo o aumento da produção de conhecimento e gerando novas oportunidades para jovens universitários desejosos de iniciar uma vida de pesquisa e desenvolvimento nas diversas áreas do conhecimento. 4. Referências Chagas D. A. Silva C. M. B. da Franco G. D. 2006 Artefatos do RUP da Matéria CE-235 Sistemas Embarcados de Tempo Real. Instituto Tecnológico de Aeronáutica São Paulo Brasil. Cunha A. M. da 2006 Notas de Aulas do Curso de Introdução a Suítes de Ferramentas I-CASE-E. Instituto Tecnológico de Aeronáutica São Paulo Brasil. Dourado Rogério; Allex Elthon. Construção de uma metodologia para desenvolvimento de software embarcado (Consultado em 2006). Roetzheim W. H. 1991 Developing Software to Government Standards. Wehrmeister M. A. Becker L. B. Pereira C. E. Metodologia de Projeto Orientada a Objetos Baseada em Plataformas para Sistemas Tempo-Real Embarcados (Consultado em 2006).