Tese apresentada à Pró-Reitoria de Pós-Graduação e Pesquisa do Instituto
Tecnológico de Aeronáutica, como parte dos requisitos para obtenção do título
de Mestre em Ciências no Curso de Pós-Graduação em Engenharia Aeronáutica
e Mecânica, Área de Sistemas Aeroespaciais e Mecatrônica.
Paulo Claudino Véras
MODELAGEM E ANÁLISE DO SOFTWARE EMBARCADO
DE PILOTO AUTOMÁTICO DE UM VANT
Tese aprovada em sua versão final pelos abaixo assinados:
Emília Villani Orientadora
Homero Santiago Maciel Pró-Reitor de Pós-Graduação e Pesquisa
Campo Montenegro São José dos Campos, SP – Brasil
2007
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
Dados Internacionais de Catalogação-na-Publicação (CIP) Divisão de Informação e Documentação Véras, Paulo Claudino Modelagem e análise do software embarcado de piloto automático de uma VANT / Paulo Claudino Véras. São José dos Campos, 2007. 135f. Tese de mestrado – Curso de Engenharia Mecânica e Aeronáutica. Área de Sistemas Aeroespaciais e Mecatrônica – Instituto Tecnológico de Aeronáutica, 2007. Orientadora: Dra. Emília Villani. 1. Desenvolvimento de software. 2.Aeronave não-tripulada. 3. Sistemas de computadores embarcados. I. Comando-Geral de Tecnologia Aeroespacial. Instituto Tecnológico de Aeronáutica. Divisão de Engenharia Mecânica-Aeronáutica. II. Título.
REFERÊNCIA BIBLIOGRÁFICA VÉRAS, Paulo Claudino. Modelagem e análise do software embarcado de piloto automático de um VANT. 2007. 135f. Tese de mestrado – Instituto Tecnológico de Aeronáutica, São José dos Campos.
CESSÃO DE DIREITOS NOME DO AUTOR: Paulo Claudino Véras TÍTULO DO TRABALHO: Modelagem e análise do software embarcado de piloto automático de um VANT TIPO DO TRABALHO/ANO: Tese / 2007 É concedida ao Instituto Tecnológico de Aeronáutica permissão para reproduzir cópias desta tese e para emprestar ou vender cópias somente para propósitos acadêmicos e científicos. O autor reserva outros direitos de publicação e nenhuma parte desta tese pode ser reproduzida sem a sua autorização (do autor). ___________________________ Paulo Claudino Véras Pça Mal-do-Ar Eduardo Gomes, 50 – Vl. Acácias 12228-900 – São José dos Campos – SP
ii
MODELAGEM E ANÁLISE DO SOFTWARE EMBARCADO
DE PILOTO AUTOMÁTICO DE UM VANT
Paulo Claudino Véras
Composição da Banca Examinadora: Prof. Osamu Saotome Presidente – ITA Profa. Emília Villani Orientadora – ITA Prof. Luiz Alberto Vieira Dias Membro interno – ITA Profa. Ana Maria Ambrósio Membro externo – INPE Prof. Cap. Taranti Membro externo – IAE/CTA
ITA
iii
Aos meus pais Adaildson e Eli, aos meus irmãos Ju, Tiago e Pedrinho
e à minha namorada Raquel
iv
Agradecimentos
À minha orientadora Profa. Dra. Emília Villani, que sempre me orientou de forma
constante e precisa durante todo meu mestrado, me dando todo apoio necessário e sempre
preocupada com o andamento da pesquisa.
Ao Prof. Dr. Luiz Carlos Sandoval Góes, pela orientação, direcionamento e todo apoio
durante toda a realização deste trabalho.
A Benedito Carlos Oliveira Maciel e Nei Salis Brasil Neto que forneceram o estudo de
caso deste trabalho e a infra-estrutura da Flight Technologies, bem como pelas discussões,
sugestões e preocupações para o bom andamento na elaboração deste trabalho e execução da
modelagem e simulação do software embarcado.
Ao Prof. Dr. Adilson Marques da Cunha e Prof. Dr. Vieira Dias pela ajuda e sugestões
na elaboração deste trabalho.
Aos colegas de pós-graduação, em especial a Rofino, Osvandre, Noli, Diogo e Denis
pela ajuda em alguns assuntos.
Aos meus pais e minha irmã que sempre me deram todo apoio necessário e
indispensável para prosseguir neste trabalho.
À minha namorada Raquel, que sempre me deu todo apoio e ajuda e sempre foi
compreensível nos momentos de ausência.
Aos meus grandes amigos de Recife, Adriano, Anderson, Daniel e Eduardo por toda
ótima convivência durante este período e George, que mesmo de longe me deu valiosa ajuda.
Ao Instituto Tecnológico de Aeronáutica – ITA e à Divisão de Engenharia Mecânica-
Aeronáutica – IEM, que institucionalmente viabilizaram este trabalho.
À Coordenação de Aperfeiçoamento de Pessoal de Nível Superior – CAPES, pelo
apoio financeiro.
v
A todos aqueles que contribuíram direta ou indiretamente de alguma forma para
elaboração deste trabalho e não foram citados nominalmente aqui.
vi
“A educação modela as almas e recria os corações, ela é a alavanca das mudanças sociais.”
(Paulo Freire)
vii
Resumo
Entre as principais dificuldades do desenvolvimento de software de qualidade está a
especificação e o projeto conceitual. Neste contexto, a modelagem de sistemas tem um papel
importante, pois torna possível a análise das características do projeto e sua validação antes da
fase de implementação. Esta tese aborda o problema de modelagem e análise do software
embarcado de piloto automático de um VANT utilizando UML e a ferramenta CASE
Rational® Rose® RealTime. A partir do modelo obtido são utilizadas três abordagens para
sua análise e avaliação: (1) aplicação de um conjunto de métricas no código gerado pela
ferramenta CASE; (2) integração do modelo implementado na ferramenta CASE com um
simulador da dinâmica do VANT, desenvolvido em MatLab®, de forma a verificar o
comportamento do sistema em malha fechada; e (3) conversão do modelo em UML para redes
de Petri, um formalismo matemático que permite a verificação formal de propriedades do
sistema.
viii
Abstract
One of the main difficulties of the embedded software development is the conceptual
specification and design. In this context, system modeling has an important role as it makes
possible the analysis of the system behavior and the design validation before the
implementation phase. This thesis approaches the problem of modeling and analyzing the
embedded software of a UAV automatic pilot using UML and the Rational® Rose®
RealTime CASE tool. It proposes three approaches for the analysis and assessment of the
UML model: (1) to apply a set of metrics to the code generated by the CASE tool; (2) to
integrate the CASE tool with a simulator of the VANT dynamics, developed in MatLab®, in
order to verify the behavior of the system in closed loop; and (3) to convert the UML model
to a Petri net model, which is a mathematic formalism that allows the formal verification of
the system properties.
ix
Lista de Ilustrações
Figura 1.1 Abordagem proposta versus abordagem tradicional. ..............................................27 Figura 2.1 Ilustração da origem da UML (QUATRANI, 2003)...............................................31 Figura 2.2 Diagramas propostos pela UML (OBJECT MANAGEMENT GROUP, 2005). ...32 Figura 2.3 Diagrama de atividades. ..........................................................................................33 Figura 2.4 Diagrama de casos de uso. ......................................................................................34 Figura 2.5 Diagrama de seqüência. ..........................................................................................36 Figura 2.6 Diagrama de colaboração........................................................................................37 Figura 2.7 Diagrama de estados. ..............................................................................................38 Figura 2.8 Diagrama de classes. ...............................................................................................40 Figura 2.9 Diagrama de classes com multiplicidade, navegação e herança. ............................41 Figura 2.10 Diagrama de componentes. ...................................................................................42 Figura 2.11 Diagrama de implantação......................................................................................43 Figura 3.1 Esquema simplificado dos componentes de hardware do VANT. .........................47 Figura 3.2 Malha de controle do profundor..............................................................................49 Figura 3.3 Malha de controle para o modo de operação 0. ......................................................49 Figura 3.4 Malha de controle para o modo de operação 1. ......................................................50 Figura 3.5 Malha de controle para o modo de operação 2. ......................................................50 Figura 3.6 Diagrama de casos de uso do piloto automático. ....................................................51 Figura 3.7 Diagrama de atividades do caso de uso “Receive Input Data”. ..............................53 Figura 3.8 Diagrama de atividades do caso de uso “Adjust Attitude”. .....................................55 Figura 3.9 Diagrama de atividades do caso de uso “Calculate Elevator Positioning”. ...........56 Figura 3.10 Diagrama de atividades do caso de uso “Send Output Data”. ..............................57 Figura 3.11 Diagrama de seqüência do recebimento dos dados de entrada do sistema em modo não autônomo. ..........................................................................................................................58 Figura 3.12 Diagrama de seqüência do recebimento dos dados de entrada do sistema em modo autônomo. .................................................................................................................................59 Figura 3.13 Diagrama de seqüência do ajuste de atitude. ........................................................60 Figura 3.14 Diagrama de seqüência de atuação do atuador “Elevator”. ..................................61 Figura 3.15 Diagrama de colaboração de recebimento dos dados de entrada do sistema. .......62 Figura 3.16 Diagrama de colaboração do ajuste da atitude......................................................62 Figura 3.17 Diagrama de colaboração de atuação no atuador “Elevator”................................63 Figura 3.19 Diagrama de estados do “DataReceiver”..............................................................64 Figura 3.20 Diagrama de estados do “ElevatorController”. ....................................................64 Figura 3.21 Diagrama de estados do “Elevator”. .....................................................................66 Figura 3.22 Diagrama de classes. .............................................................................................67 Figura 3.18 Diagrama de estrutura do software. ......................................................................69 Figura 4.1 Exemplo de grafo de fluxo de controle. ..................................................................74 Figura 4.2 Exemplo de grafo de fluxo de controle com contagem das regiões........................75 Figura 4.3 Diagrama de estados do “ElevatorController”. ......................................................79 Figura 4.4 Grafo de fluxo simplificado para o “ElevatorController”. .....................................79 Figura 5.1 Diagrama conceitual básico de um sistema de controle (MIYAGI, 1996). ............86 Figura 5.2 Diagrama conceitual básico do sistema de controle do VANT em estudo. ............87 Figura 5.3 Esquema de montagem da simulação integrada......................................................88
x
Figura 5.4 Diagrama de seqüência para a configuração de integração com o simulador de vôo...................................................................................................................................................90 Figura 5.5 Estrutura geral do simulador de vôo. ......................................................................91 Figura 5.6 Simulador de vôo desenvolvido no Simulink®. ......................................................92 Figura 5.7 Bloco responsável pela comunicação serial com o modelo no RRRT....................94 Figura 5.8 Monitor de estados da cápsula “DataReceiver”......................................................96 Figura 5.9 Monitor de estados da cápsula “ElevatorController”. ............................................96 Figura 5.10 Monitor de estados da cápsula “Elevator”. ...........................................................97 Figura 5.11 Horizonte artificial no Simulink®. ........................................................................98 Figura 6.1 Exemplo de rede de Petri e sua representação matricial (Cardoso, Valette, 1997).................................................................................................................................................103 Figura 6.2 Diagrama de estados da cápsula “DataReceiver”. ................................................111 Figura 6.3 Rede de Petri correspondente ao “DataReceiver”. ...............................................112 Figura 6.4 Diagrama de estados do “ElevatorController”. ....................................................113 Figura 6.5 Rede de Petri correspondente ao “ElevatorController”........................................113 Figura 6.6 Diagrama de estados do “Elevator”. .....................................................................115 Figura 6.7 Rede de Petri correspondente ao “Elevator”.........................................................115 Figura 6.8 Modelo completo em rede de Petri. ......................................................................116 Figura 6.9 Redes de Petri do sistema com mecanismos de tratamento de falhas...................118 Figura 6.10 Rede de Petri do modelo sem “User”. ................................................................120 Figura 6.11 Grafo de alcançabilidade da rede de Petri do modelo.........................................121
xi
Lista de Tabelas
Tabela 1.1 Níveis de autonomia de VANTs (FABIANI, 2006)...............................................18 Tabela 1.2 Domínios e algumas aplicações típicas de sistemas de tempo real (LAPLANTE, 2004; BIHARI, 1992). ..............................................................................................................22 Tabela 3.1 Lista de atores do VANT........................................................................................52 Tabela 4.1 Divisão das métricas em categorias (PRESSMAN, 1995). ....................................72 Tabela 4.2 Valores limites da complexidade ciclomática (VANDOREN, 1997a). .................75 Tabela 4.3 Valores de complexidade ciclomática obtidos. ......................................................76 Tabela 4.4 Significados das métricas de Halstead (HALSTEAD, 1977). ................................81 Tabela 4.5 Valores obtidos das métricas de Halstead. .............................................................82 Tabela 4.6 Valores da métrica de linhas de código e comentários...........................................84 Tabela 5.1 Dados enviados pelo simulador para o software. ...................................................93 Tabela 6.1 Algumas interpretações típicas de transições e lugares (MURATA, 1989). ........102 Tabela 6.2 Propriedades comportamentais das redes de Petri (MACIEL, 1996)...................105 Tabela 6.3 Relação entre os elementos de UML e Redes de Petri. ........................................110 Tabela 6.4 Significados das siglas do grafo de alcançabilidade.............................................120
xii
Lista de Abreviaturas e Siglas
ANAC – Agência Nacional de Aviação Civil Bps – bits per second CASE – Computer-Aided Software Engineering CBR – Checklist-Based Reading CEA – Centro de Estudos Aeronáuticos CTA – Comando-Geral de Tecnologia Aeroespacial DOF - degrees of freedom GPS – Global Positioning System IFI – Instituto de Fomento e Coordenação Industrial IncubAero – Incubadora Aeroespacial OMG – Object Management Group OMT – Object Modeling Technique PC – Personal Computer PID – Proporcional Integral Derivativo PWM – Pulse Width Modulation RAM – Random Access Memory ROM – Read Only Memory RRRT – Rational Rose RealTime RTRT – Rational Test RealTime UAV – Unmanned Aerial Vehicle UFMG – Universidade Federal de Minas Gerais UML – Unified Modeling Language USB – Universal Serial Bus VANT – Veículo Aéreo Não Tripulado
xiii
Lista de Símbolos
p – Velocidade angular de rolamento q – Velocidade angular de arfagem r – Velocidade angular de guinada θ – ângulo de arfagem θref – ângulo de arfagem de referência φ – ângulo de rolamento ψ – ângulo de guinada H – altitude da aeronave a – velocidade do som rho – densidade do ar
xiv
Sumário
Lista de Ilustrações ....................................................................................................................ix Lista de Tabelas .........................................................................................................................xi Lista de Abreviaturas e Siglas ..................................................................................................xii Lista de Símbolos ....................................................................................................................xiii 1 Introdução.........................................................................................................................16
1.1 VANT - Veículo Aéreo Não Tripulado....................................................................16 1.2 Sistemas Embarcados ...............................................................................................19 1.3 Sistemas de Tempo Real ..........................................................................................21 1.4 Linguagens de Modelagem e a Unified Modeling Language - UML ......................22 1.5 Objetivo ....................................................................................................................26 1.6 Organização da Tese.................................................................................................28
2 Orientação à Objeto, UML e RRRT.................................................................................29 2.1 Conceitos Básicos de Orientação a Objeto...............................................................29 2.2 Unified Modeling Language - UML ........................................................................30 2.3 Rational® Rose® RealTime.....................................................................................43
3 Modelagem do Software de Piloto Automático................................................................46 3.1 Descrição do VANT .................................................................................................46
3.1.1 Hardware..........................................................................................................47 3.1.2 Software ............................................................................................................48 3.1.3 Malha de Controle ............................................................................................48
3.2 Modelagem em UML ...............................................................................................50 3.2.1 Diagrama de Casos de Uso...............................................................................50 3.2.2 Diagramas de Atividades..................................................................................53 3.2.3 Diagramas de Seqüência...................................................................................57 3.2.4 Diagramas de Colaboração...............................................................................61 3.2.5 Diagramas de Estados.......................................................................................63 3.2.6 Diagrama de Classes.........................................................................................66
3.3 Diagrama de Estrutura ..............................................................................................68 3.4 Considerações Referentes ao Teste do Modelo........................................................69
4 Aplicação de Métricas ao Código do Software ................................................................71 4.1 Complexidade Ciclomática – V(G) ..........................................................................73 4.2 Métricas de ciência de software de Halstead............................................................80 4.3 Linhas de Código – LOC..........................................................................................83 4.4 Considerações sobre a Aplicação de Métricas .........................................................85
5 Descrição da Simulação do Modelo .................................................................................86 5.1 Descrição da Montagem de Integração ....................................................................86 5.2 Modificações no Modelo do RRRT .........................................................................89 5.3 Descrição do Simulador de Vôo...............................................................................90 5.4 Simulação .................................................................................................................95 5.5 Considerações sobre a Integração RRRT - MatLab® ..............................................99
6 Modelagem em Redes de Petri do Software Embarcado................................................101 6.1 Introdução às redes de Petri....................................................................................101 6.2 Redes de Petri e UML ............................................................................................106 6.3 Do modelo do RRRT ao modelo em redes de Petri ...............................................109 6.4 Conversão do Modelo do Software Embarcado do VANT....................................111 6.5 Análise do Modelo em redes de Petri.....................................................................117
xv
6.6 Considerações sobre a Modelagem e Análise baseada em Redes de Petri.............123 7 Conclusões......................................................................................................................125 Referências .............................................................................................................................128
16
1 Introdução
Esta tese aborda o desenvolvimento de software para sistemas embarcados em VANTs
(Veículos Aéreos Não Tripulados), também conhecidos pela sigla em inglês UAVs (Unmaned
Aerial Vehicles). Em particular, considera-se o problema de modelagem e verificação do
software de piloto automático.
Este capítulo inicia-se com alguns conceitos e definições necessários para melhor
compreensão da proposta, dos objetivos e das motivações deste trabalho. Apresenta-se uma
breve introdução sobre VANTs. Em seguida caracteriza-se o que são sistemas embarcados e
sistemas de tempo real. Discute-se então o papel das linguagens de modelagem no
desenvolvimento de software para sistemas embarcados de tempo real, considerando em
particular a UML (Unified Modeling Language – Linguagem Unificada de Modelagem).
Após estes conceitos, são descritos os objetivos, as motivações e as contribuições
deste trabalho, bem como a organização do restante do documento.
1.1 VANT - Veículo Aéreo Não Tripulado
Um VANT pode ser definido como um veículo aéreo motorizado sem tripulação e
reutilizável que é controlado remotamente, é autônomo ou possui uma combinação destas
características. Possui a capacidade de levar vários tipos de carga útil (payload), o que o torna
capaz de realizar alguma missão/tarefa específica (BLYENBURGH, 1999). É importante
observar que mísseis de cruzeiro e veículos balísticos não são considerados VANTs.
Os VANTs podem ser divididos em três grandes categorias (THE UAV INDUSTRY,
1999): com asas fixas, com asas rotatórias e mais leves que o ar (airships). O primeiro é o
mais produzido e utilizado no mundo, cujas aplicações são predominantemente militares. O
segundo vem em seguida, é menos utilizado que o primeiro, porém o número de fabricantes
vem crescendo constantemente e é largamente utilizado na agricultura. Por fim, os VANTs
17
que são mais leves que o ar são os menos utilizados e também os que entraram em operação
há menos tempo. O número de pessoas que desenvolve este tipo de VANT cresce lentamente
e eles são utilizados principalmente em aplicações científicas e comerciais.
De acordo com o Department of Defense (2006) os VANTs são utilizados
majoritariamente em aplicações militares, como por exemplo, para detecção de mísseis de
cruzeiro através de radares, vigilância e proteção de forças de ataques. A justificativa para a
utilização militar de VANTs é a grande necessidade da realização de diversas missões
perigosas onde há risco de abatimento ou de queda da aeronave. Recentemente as aplicações
civis têm aumentado, como por exemplo, no Japão, onde os VANTs são empregados na
agricultura (BLYENBURGH, 1999).
A seguir estão listadas algumas das tarefas que podem ser realizadas por VANTs
(BLYENBURGH, 1999; BORGES, 2005; CESTINO, 2006; COX, 2004; DEPARTMENT
OF DEFENSE, 2005; FABIANI, 2006; HOLDER, 2001; KIM, 2006; NEWCOME, 2004;
VASCONCELOS, 2006):
• Aplicações militares:
o Reconhecimento e vigilância de áreas perigosas;
o Avaliação de danos de batalha;
o Localização de alvos;
o Detecção de mísseis de cruzeiro;
o Proteção contra ataques de pequenas armas, morteiros e foguetes;
o Alvo aéreo manobrável;
o Transporte de mantimentos;
o Detecção de minas terrestres.
Aplicações civis:
o Pulverização de agrotóxicos e fertilização em áreas de plantio;
18
o Inspeção visual em áreas de plantio, barragens, redes de transmissão de energia;
o Previsão do tempo;
o Pesquisa acadêmica;
o Busca e salvamento;
o Comunicação;
o Vigilância de queima florestal;
o Filmagem de eventos esportivos.
De acordo com Fabiani (2006), os VANTs variam também em relação ao nível de
autonomia que possuem. Em um extremo encontram-se os VANTs onde o piloto fornece
remotamente as ordens diretamente para os atuadores, observa a atitude resultante e controla a
estabilidade da aeronave. No extremo oposto, de maior autonomia, estão os VANTs onde o
operador define a missão do sistema e são fornecidas para a aeronave habilidades de decisão e
processamento de informações a bordo. A Tabela 1.1 apresenta uma relação entre as ações do
operador, as funcionalidades fornecidas pelo sistema embarcado e a autonomia do sistema.
Tabela 1.1 Níveis de autonomia de VANTs (FABIANI, 2006). Ações do operador Funcionalidade embarcada Autonomia do sistema
Definição do alvo Ação e planejamento de objetivo Estratégia
Definição do caminho Planejamento do caminho Navegação
Controle de trajetória Planejamento de trajetória Guiamento
Controle de atitude Piloto automático Pilotagem
Controle de atuadores Controle de vôo Estabilização
Para que estas funcionalidades sejam providas, os VANTs possuem sistemas
computacionais cuja complexidade do software varia de acordo com a autonomia desejada.
Esta tese trata do problema de como desenvolver este software de forma confiável e eficiente.
19
As próximas seções apresentam as principais características de sistemas embarcados e
sistemas de tempo real, justificando a classificação do sistema computacional de um VANT
como sistema embarcado de tempo real. Com base nesta caracterização, é identificada a
necessidade de incorporação de técnicas de modelagem e uso de ferramentas CASE no
desenvolvimento de software embarcado para VANTs.
1.2 Sistemas Embarcados
Guerrouat (2005) define um sistema embarcado como sendo “qualquer sistema ou
dispositivo computacional que desempenha uma função dedicada ou é projetado para uso com
uma aplicação de software embarcado específica”. Esta definição exclui computadores
pessoais (PCs ou desktops) da categoria de sistemas embarcados, pois eles não são projetados
para desempenhar aplicações específicas ou funções dedicadas. “Sistemas embarcados
representam uma parte de um produto com o qual o usuário final não interage diretamente”
(GUERROUAT, 2005).
Abaixo estão listadas algumas características dos sistemas computacionais
embarcados (BERGER, 2002; WUYTS, 2005):
São dedicados a tarefas específicas;
Possuem ampla variedade de arquiteturas de processador disponíveis;
São usualmente sensíveis ao custo;
Possuem restrições quanto ao tempo de execução das tarefas;
Implicações de falhas no software são mais severas do que em desktops;
Possuem restrições quanto ao consumo de energia;
Usualmente devem operar sob condições de ambiente extremas;
Possuem menos recursos de sistema do que os computadores desktops, em
particular no que se refere à disponibilidade de memória (ROM e RAM), e
capacidade de processamento.
20
Entre os aspectos mais importantes de um sistema embarcado estão a confiabilidade, a
eficiência e o custo (LAPLANTE, 2004). A confiabilidade se refere ao correto funcionamento
do sistema na presença de falhas e erros (DOUGLASS, 2003). A eficiência diz respeito a
propriedades como energia, tamanho de código, tempo de execução e peso (GUERROUAT,
2005).
Sistemas embarcados podem ser encontrados em diversas aplicações, como sistemas
automotivos (controles de motor, sistemas de frenagem anti-derrapagem), periféricos
computacionais (impressoras, scanners, modem), robôs, aeronaves (sistemas de
gerenciamento de vôo, controle de turbina), eletrodomésticos (fornos microondas, máquinas
de lavar), plantas de usinas nucleares (LABROSSE, 2002; GUERROUAT, 2005), entre
outras. A diversidade das aplicações é ilustrada pela extensa coleção de trabalhos científicos
publicados. Alguns exemplos são Amir et al. (2005), que utiliza um sistema embarcado como
sensor para identificação de olhos, Kwakye (2006), que projetou um sistema miniaturizado
baseado em microcontrolador para detecção eletroquímica, Ko (2006), que desenvolveu um
sistema embarcado baseado em conhecimento para estimar o custo de fabricação de peças
moldadas e Kroll (2003) que utiliza um sistema embarcado para inserir assinaturas digitais em
objetos padrões, como imagens, formas de onda e relatórios estruturados da área médica.
Com o desenvolvimento da tecnologia de circuitos integrados e microprocessadores,
os sistemas embarcados têm se tornado cada vez mais sofisticados e complexos. Como
conseqüência, o processo de desenvolvimento de software embarcado também se torna uma
atividade custosa e propensa a erros (GUERROUAT, 2005; HATTON, 2005; KIMOUR,
2005; NEEMA et al., 2004). Devido às características já apresentadas, os programas
computacionais desenvolvidos para sistemas embarcados são em geral classificados como
sistemas de tempo real. A próxima seção descreve o que são sistemas de tempo real.
21
1.3 Sistemas de Tempo Real
De acordo com Laplante (2004), um sistema de tempo real pode ser definido como
aquele que deve satisfazer restrições explícitas de tempo de resposta ou há risco de
conseqüências severas, incluindo a ocorrência de falhas. Um sistema com falha é definido
como aquele que não pode satisfazer um ou mais dos requisitos estipulados na especificação
formal do sistema. Em outras palavras, um sistema de tempo real deve satisfazer as
especificações de requisitos do sistema quanto ao tempo limite para fornecer suas respostas.
Kopetz (1997), por sua vez, define um sistema de tempo real como aquele onde a
exatidão de seu comportamento não depende apenas do resultado lógico, mas também do
instante físico em que suas respostas são produzidas.
Os sistemas de tempo real podem ser classificados em soft e hard. Labrosse (2002)
define sistemas soft como aqueles em que as tarefas são desempenhadas pelo sistema o mais
rápido possível, porém nem todas elas têm que ser finalizadas dentro de um limite de tempo
específico (deadline). Já nos sistemas hard, todas as tarefas devem ser desempenhadas não só
corretamente, mas dentro de um limite de tempo. O não cumprimento do limite de tempo
estipulado em sistemas hard pode provocar situações de conseqüências catastróficas,
diferentemente do ocorrido em sistemas soft, onde o não cumprimento não necessariamente
resulta em uma operação inadequada do sistema ou produz conseqüências graves (BURNS,
1999; LEWIS, 2001). Observa-se que a maioria dos sistemas de tempo real são aplicações
embarcadas e possuem uma combinação de requisitos soft e hard.
A Tabela 1.2 apresenta uma lista de domínios e aplicações de sistemas de tempo real
(LAPLANTE, 2004, BIHARI, 1992).
22
Tabela 1.2 Domínios e algumas aplicações típicas de sistemas de tempo real (LAPLANTE, 2004; BIHARI, 1992).
Domínio Aplicações
Navegação
Displays Aviação
Controle do tráfego aéreo
Jogos Multimídia
Simuladores
Cirurgia robotizada
Cirurgia remota Medicina
Imagem médica
Inspeção automática
Linhas robóticas de montagem Sistemas Industriais
Controle de plantas químicas e nucleares
Controle de elevador
Sistemas automotivos
Sistemas bancários Civil
Sistemas de telecomunicação
A crescente complexidade dos programas computacionais de tempo real para sistemas
embarcados justifica a introdução de linguagens de modelagem no processo de
desenvolvimento do software. A próxima seção é dedicada a este tópico e apresenta a UML
(Unified Modeling Language), utilizada neste trabalho para a modelagem do software
embarcado de piloto automático de VANTs.
1.4 Linguagens de Modelagem e a Unified Modeling Language - UML
No processo de desenvolvimento de um software, a utilização de uma linguagem de
modelagem é necessária para “descrever a base da construção conceitual do software”
(PAIGE, 2000). Dentre os objetivos das linguagens, podem ser destacadas a padronização,
simplicidade e facilidade de projeto e argumentação. Estes objetivos levam ao
23
desenvolvimento de sintaxe, semântica, documentação e suporte para criação de ferramentas
que auxiliem a programação (PAIGE, 2000).
Entre as vantagens da modelagem, destaca-se a possibilidade de analisar as
funcionalidades do software já modelado através da simples visualização de seus diagramas,
uma vez que o conjunto deles forma um cenário completo do software. É possível ainda a
utilização de ferramentas CASE (Computer-Aided Software Engineering) para implementar a
modelagem do software em um computador e, através de simulação, verificar se o mesmo
atende aos requisitos antes mesmo de sua codificação. Além disso, o software ficará
devidamente documentado, o que facilitará uma possível análise e futura modificação,
melhorando assim sua manutenibilidade.
Entre as principais dificuldades do desenvolvimento de software de qualidade está a
especificação e a estruturação do software (BROOKS, 1995). Quando técnicas de modelagem
são utilizadas, estas atividades são deslocadas da fase de codificação para a fase de
modelagem do software, que compreende, dentre outras, a atividade de captura e análise de
requisitos do sistema através de casos de uso (IWU, 2007) antes da definição da estrutura do
software. Neste sentido, a modelagem permite minimizar as dificuldades encontradas no
desenvolvimento de software. Damaševičius (2004) afirma que a importância da modelagem
está no fato desta focalizar os aspectos mais importantes do problema, propiciar a
comunicação entre os projetistas e permitir a validação do sistema projetado e a avaliação de
suas características antes mesmo de sua implementação.
Paige (2000) afirma que as linguagens de modelagem freqüentemente são notações
gráficas, contudo também existem algumas que são notações formais, ou seja, fornecem um
modelo matemático de um sistema que pode ser argumentado. Alguns exemplos de
linguagens gráficas são a SOMA (GRAHAM, 1998) e a MASCOT (SIMPSON, 1979). Está
24
última é uma abordagem de tempo real. Dois exemplos de linguagens formais são CSP
(HOARE, 1985) e Z (SPIVEY, 1989).
No caso de linguagens baseadas em formalismos matemáticos, é possível ‘provar’
matematicamente propriedades do modelo e desta forma validar funcionalidades do sistema.
Neste sentido, métodos formais têm se mostrado uma alternativa para o projeto de sistemas
embarcados mais confiáveis, fornecendo suporte às diferentes fases de seu desenvolvimento
(GUERROUAT, 2005; LÜTTGEN, 2001). Iwu et. al. (2007) afirma que “a aplicação de
métodos formais no desenvolvimento de softwares de segurança crítica tem sido defendida
por várias normas”, como por exemplo, a DO-178B (1992).
Além das vantagens já apresentadas, a modelagem também auxilia a certificação do
software, uma atividade obrigatória no caso de software embarcado em sistemas
aeroespaciais. No Brasil o órgão responsável pela certificação de software para aviação civil é
a Agência Nacional de Aviação Civil – ANAC, e para aviação militar e sistemas espaciais, é o
Instituto de Fomento e Coordenação Industrial – IFI, alocado dentro do Comando-Geral de
Tecnologia Aeroespacial – CTA. De acordo com Palma (2005), o desenvolvimento de
software de acordo com um processo padronizado e documentado facilita a obtenção de
certificação. Palma (2005) lista ainda um conjunto de procedimentos que visa o
desenvolvimento de software com qualidade e confiável. Dentre estes procedimentos, cita-se
o emprego de “recursos como padronização, estruturação, linguagens de especificação
formais e outras ferramentas consideradas capazes de reduzir a probabilidade de introdução
de erros”.
A linguagem para modelagem de software que vem ganhando maior destaque na
comunidade acadêmica e industrial é a Unified Modeling Language – UML (RUMBAUGH,
1999). A UML tornou-se a linguagem padrão para modelagem orientada a objeto de sistemas
de software (IWU, 2007; PAIGE, 2000). A UML consiste de um conjunto de notações para
25
modelagem de sistemas de diversas visões e de vários níveis de abstração (FRANCE, 1998).
Rumbaugh (1999) define a UML como sendo “a linguagem padrão para especificar,
visualizar, construir e documentar todos os artefatos de um sistema de software”. A crescente
utilização da UML como padrão para modelagem de sistemas tem encorajado o uso de
ferramentas CASE, o que facilita o processo de desenvolvimento desde a análise até a
produção do código (KIMOUR, 2005).
Esta linguagem utiliza várias notações gráficas para capturar requisitos de sistemas e
realizar sua análise e projeto (GILMORE, 2005; IWU, 2007). A Seção 2.2 apresenta uma
descrição detalhada com os aspectos de todos os diagramas propostos pela UML. Douglass
(2003) destaca alguns motivos pelos quais a UML tornou-se a linguagem de modelagem de
software padrão utilizada para desenvolvimento de sistemas. Em primeiro lugar, a UML
possui um modelo semântico bem definido, que cobre a maioria dos aspectos necessários para
especificação e projeto de sistemas e é profundo, o que significa que é possível criar modelos
executáveis. Em segundo lugar, a UML é fácil para dominar e simples para entender. Embora
seja argumentado que a linguagem é composta por muitos diagramas, é possível desenvolver
sistemas complexos com apenas três diagramas (de classe, de estado e de seqüência). Em
terceiro lugar, a UML é um padrão, o que significa que a pessoa que desenvolverá poderá
escolher a ferramenta e o serviço que utilizará.
Douglass (2003) afirma ainda que a UML “permite ao usuário definir um modelo do
sistema” e define modelo como sendo “um conjunto integrado e coerente de abstrações que
representam o sistema a ser projetado”. Portanto, é possível abstrair o sistema a ser
desenvolvido para propósito de análise e projeto utilizando a UML.
Além das vantagens apresentadas, a UML tem sido a base para o desenvolvimento de
novas técnicas de análise em diferentes campos de aplicações, como comprova a extensa
bibliografia publicada sobre o assunto. Gilmore (2005), por exemplo, modela um sistema em
26
UML para, em seguida, compilar os modelos através de uma linguagem intermediária e
traduzir para um diagrama de decisão, a partir do qual é obtida uma “capacidade de
representação eficiente”. Baudry (2005) propõe uma medida da capacidade do sistema ser
testado através dos diagramas de classe da UML. Já Massink (2006) faz uma abordagem de
teste do sistema utilizando um “subconjunto comportamental” de diagramas de estado da
UML. Laitenberder (2000) faz uma comparação de técnicas de leitura para detecção de
defeito entre documentos de projeto de UML e uma tradicional abordagem de leitura baseada
em checklist (CBR em inglês).
1.5 Objetivo
As seções anteriores caracterizaram os sistemas embarcados de tempo real, apontando
os principais fatores que implicam na complexidade do desenvolvimento de software
embarcado de tempo real. Apresentou-se então a modelagem como possível solução para lidar
com esta complexidade. Podemos enquadrar nesta categoria os VANTs que realizam o
controle de atitude de forma autônoma durante o vôo, onde um erro pode ocasionar falhas que
levam a conseqüências graves, como a destruição da aeronave.
Neste contexto, o objetivo deste trabalho consiste em utilizar a linguagem UML para
modelagem do software de piloto automático de um VANT e, a partir dos modelos
construídos, aplicar diferentes técnicas para verificação do software desenvolvido.
O VANT utilizado como estudo de caso pertence à Flight Technologies, empresa
incubada na Incubadora Aeroespacial – IncubAero, dentro do CTA. A modelagem em UML
utiliza-se da ferramenta CASE Rational® Rose® RealTime – RRRT. Para verificação do
software propõem-se três abordagens distintas. Observa-se que estas três abordagens não têm
como objetivo abranger todos os aspectos da verificação de um software embarcado, mas
devem ser utilizadas em conjunto com outras técnicas disponíveis na literatura.
27
A primeira abordagem consiste na aplicação de um conjunto de métricas ao código
fonte gerado pelo RRRT. Esta abordagem visa demonstrar que o código gerado através da
modelagem em UML está dentro do limite estipulado nas métricas. São aplicadas as métricas
de complexidade ciclomática (V(G)), de ciências de Halstead e de linhas de código (LOC) e
de comentário por arquivo fonte. Nesta abordagem utiliza-se o Rational® Test RealTime –
RTRT.
A segunda abordagem consiste em integrar a ferramenta CASE com um ambiente de
simulação de modelos dinâmicos de forma a observar o comportamento do sistema
embarcado em interação com o ambiente físico. Ao contrário da visão adotada
tradicionalmente em Engenharia de Software, o objetivo é verificar o comportamento do
conjunto software de controle + planta1 controlada (Figura 1.1). Através desta abordagem é
possível verificar como o software de controle interfere no comportamento da planta
controlada e vice-versa, permitindo assim detectar erros e falhas resultantes desta interação.
Figura 1.1 Abordagem proposta versus abordagem tradicional.
O simulador utilizado foi desenvolvido na plataforma MatLab®-Simulink®, onde
foram implementadas as equações de movimento que refletem o comportamento dinâmico do
VANT. O RRRT é integrado a este simulador de vôo, cujo papel é gerar os sinais que seriam
1 A palavra ‘planta’ se refere ao objeto controlado, ou seja, o objeto que está sendo controlado pelo sistema de controle, que neste caso é o VANT.
Planta
Software de Controle
Abordagem proposta
Usuário
Sistema analisado Planta
Software de Controle
Usuário
Sistema analisado
Abordagem tradicional
28
produzidos pelos sensores da aeronave e os enviar para o modelo, assim como receber o valor
do comando de atuação enviado pelo modelo no RRRT e calcular novos valores dos sensores.
A terceira abordagem consiste em converter os modelos em UML para um formalismo
matemático que permita a verificação formal de propriedades, isto é, a prova matemática de
que o comportamento do sistema obedece a estas propriedades. O formalismo adotado é a
rede de Petri. Através de um conjunto de regras, propõe-se a conversão dos diagramas de
estado, que são então integrados em uma única rede de Petri contendo também uma abstração
em eventos discretos do comportamento da planta. Este modelo em redes de Petri é analisado
através de simulação e da aplicação de técnicas para verificação formal de propriedades.
1.6 Organização da Tese
Esta tese está organizada da seguinte forma.
O Capítulo 2 introduz o paradigma de orientação a objetos, apresenta uma descrição
detalhada dos diagramas que compõem a UML e descreve a ferramenta CASE utilizada para
modelar o software embarcado do VANT, o RRRT.
O Capítulo 3 descreve o VANT utilizado como estudo de caso e detalha a modelagem
do software embarcado em UML usando o RRRT. Em seguida, o Capítulo 4 apresenta a
aplicação de algumas métricas aos arquivos de código fonte gerados pelo RRRT.
O Capítulo 5 apresenta uma descrição do simulador de vôo utilizado para representar o
comportamento do VANT e descreve sua integração ao RRRT.
O Capítulo 6 faz uma breve introdução às redes de Petri e propõe a conversão dos
modelos em UML para este formalismo. São então verificadas algumas propriedades do
modelo construído.
Por fim, as conclusões deste trabalho são apresentadas no Capítulo 7, bem como
algumas sugestões para trabalhos futuros.
29
2 Orientação à Objeto, UML e RRRT
2.1 Conceitos Básicos de Orientação a Objeto
Rumbaugh define orientação a objeto como “uma nova maneira de pensar os
problemas utilizando modelos organizados a partir de conceitos do mundo real. O
componente fundamental é o objeto que combina estrutura e comportamento em uma única
entidade”, apud Furlan (1998).
Dentre as vantagens da utilização de alguma linguagem de programação orientada a
objeto, pode ser citada a maior facilidade para entender, adaptar e reutilizar o código
(BIHARI, 1992).
Entre os ‘pilares’ que sustentam a orientação a objetos destacam-se os conceitos de
“objeto” e “classe”. Jacobson et al (1998) definem um objeto como uma entidade com
fronteiras bem definidas e identidade, que encapsula estado e comportamento. Objetos
possuem atributos, que podem assumir diferentes valores de acordo com o estado do objeto, e
operações, que descrevem o comportamento do objeto. Uma classe é a descrição de um
conjunto de objetos que compartilham os mesmos atributos e operações.
Um exemplo de classe pode ser “aeronave”. Exemplos de atributos são o tipo de asa, a
capacidade de passageiros, capacidade de carga útil, tipo de propulsão, entre outros.
Exemplos de operações para esta classe são “decole” e “pouse”, que representam ações que
podem sem executadas pelos objetos da classe.
Outro conceito em orientação a objeto é a de troca de mensagens entre os objetos. Um
objeto pode solicitar um serviço de outro objeto através da passagem de uma mensagem
contendo ou não algum valor (atributo) para outro objeto, que por sua vez, executará o serviço
(operação) e enviará de volta o resultado através de outra mensagem. Uma mesma operação
30
pode assumir vários comportamentos, pois sua execução pode depender dos atributos a ela
passados. Isto caracteriza o conceito de polimorfismo.
No desenvolvimento de um software orientado a objeto pode ser necessária a
utilização de classes muito parecidas, que possuem a mesma estrutura, porém diferem entre si
em algum detalhe. Neste caso, não há a necessidade de se criar uma nova classe, é possível
herdar as propriedades de uma classe já existente (superclasse) e adicionar as características
novas a esta nova classe (subclasse). Isto caracteriza o conceito de herança, que é definida
como “um mecanismo através do qual, elementos mais específicos incorporam a estrutura e o
comportamento de elementos mais genéricos” (JACOBSON et al, 1998).
Como exemplo de herança, pode-se citar “aeronave” como uma superclasse (que pode
conter propriedades como potência e autonomia de vôo) e “VANT” como uma subclasse, que
herda todas as características da classe e adiciona as suas específicas, como por exemplo,
ausência de tripulação.
Para a representação de sistemas desenvolvidos com base nos conceitos de orientação
a objeto, foram criadas várias linguagens. A próxima seção apresenta a Unified Modeling
Language – UML, considerada atualmente o principal padrão para modelagem de sistemas
orientados a objetos.
2.2 Unified Modeling Language - UML
A UML surgiu a partir de outras três linguagens de modelagem de software que eram
as mais utilizadas no final da década de 80 e início dos anos 90. São elas: OMT, Objectory e
Booch Methodology, desenvolvidas, respectivamente, por Jim Rumbaugh, Ivar Jacobson e
Grady Booch. Cada uma destas linguagens possuía seus pontos fortes e fracos. A OMT era
muito forte em análise, Booch Methodology era mais adequada para projeto, e Objectory era
uma linguagem apreciada por usuários mais experientes (QUATRANI, 2003). Em 1994
Rumbaugh e Booch se uniram para compor a Rational® Software. Ambos trabalharam no
31
desenvolvimento de uma nova linguagem, até que em outubro de 1995 foi lançado o Unified
Method. Em seguida Jacobson foi incorporado ao grupo e em 1997 a UML foi proposta e
submetida ao Object Management Group (OMG) para padronização. A origem da UML é
ilustrada na Figura 2.1 (QUATRANI, 2003).
Figura 2.1 Ilustração da origem da UML (QUATRANI, 2003).
A UML propõe que a modelagem seja realizada através de vários diagramas que
mostram de forma visual as características do software modelado. São ao todo oito diagramas,
cada qual com sua função, que em conjunto possibilitam o entendimento do funcionamento
do software como um todo. Estes diagramas estão divididos em comportamentais e estruturais
como pode ser visto na Figura 2.2 (OBJECT MANAGEMENT GROUP, 2005).
32
Figura 2.2 Diagramas propostos pela UML (OBJECT MANAGEMENT GROUP, 2005).
A seguir apresenta-se cada diagrama proposto pela UML.
• Diagrama de atividades
Este diagrama fornece uma visão dinâmica do comportamento de um sistema. Ele
apresenta o fluxo de uma atividade para outra atividade, de forma abstrata e relativamente
simples, utilizando uma notação de fácil compreensão (JACOBSON et al, 1998). Uma
atividade descreve uma unidade lógica de trabalho e pode ser dividida em ações, que
representam a menor unidade de trabalho não mais passível de decomposição (KIMOUR,
2005).
A Figura 2.3 apresenta um exemplo de diagrama de atividades. Este diagrama
descreve as atividades do software embarcado de um VANT que deve realizar uma
determinada missão de forma autônoma.
UML
Diagramas comportamentais Diagramas estruturais
Diagrama de atividades
Diagrama de casos de uso
Diagrama de seqüência
Diagrama de colaboração
Diagrama de classes
Diagrama de componentes
Diagrama de implantação
Diagrama de estados
33
Figura 2.3 Diagrama de atividades.
Cada retângulo arredondado do diagrama representa uma atividade, correspondente a
um estado de ação. A transição entre duas atividades ocorre automaticamente quando a
atividade em execução é completada. A barra horizontal modela a execução de duas ou mais
atividades de forma paralela.
• Diagrama de casos de uso
O propósito deste diagrama é fornecer uma visão dos serviços em alto nível a serem
supridos pelo sistema, as relações entre eles e os atores envolvidos (LAITENBERGER et. al.,
2000). Os atores são quaisquer entidades externas ao sistema que interagem com ele.
Definidos os atores, o próximo passo é definir os casos de uso, que são as funcionalidades que
o sistema deve fornecer, ou seja, uma capacidade do sistema nomeada (DOUGLASS, 2002).
Receber missão Decolar
Percorrer trajetória
Retornar para base
Realizar controle de atitude
Realizar coleta de dados
Pousar
34
Os casos de uso capturam os requisitos do sistema, porém, eles devem ser bem
documentados, pois o simples nome dado a ele não o descreve completamente. A melhor
maneira de defini-los é verificar o que os atores devem fazer ao utilizarem o sistema. Os
atores são representados por “pessoas” (mas não significa que os atores devem ser humanos,
eles podem ser quaisquer objetos que interagem diretamente com o sistema) e os casos de uso
são representados por balões. Cada caso de uso deve ser documentado com o fluxo de evento
a ser executado. Este fluxo mostra o(s) evento(s) que inicia(m) o caso de uso, o(s) evento(s)
que deve(m) ser executado(s) e o(s) evento(s) que finaliza(m) o caso de uso. Devem ser
documentados os possíveis eventos e possíveis caminhos que o sistema pode percorrer (mas
não todos, pois pode haver infinitas possibilidades).
Então, através deste diagrama é possível verificar quais são os atores que interagem
com o software e as funcionalidades que ele deve fornecer. A Figura 2.4 apresenta um
exemplo de um diagrama de casos de uso, no qual um ator (Boom, que representa os sensores
de pressão estática e dinâmica) fornece dados de entrada para um VANT, que por sua vez
envia dados a dois atores representando os atuadores do sistema (Motor e Profundor). O
Boom fornece tanto a velocidade do VANT quanto sua altitude, permitindo calcular o sinal de
controle que deve ser enviado ao profundor e ao motor.
Figura 2.4 Diagrama de casos de uso.
Fornece altitude atual
Atua no profundor Boom
Motor
Calcula atuação no profundor
Profundor
Fornece velocidade atual
Calcula atuação no motor
Atua no motor
35
A última consideração sobre os casos de uso é a forma como ele realiza suas tarefas.
Isto é especificado nos próximos dois diagramas (diagrama de seqüência e diagrama de
colaboração) e no diagrama de classes.
• Diagrama de seqüência
Este diagrama mostra a seqüência de mensagens entre objetos em ordem cronológica
(DIPIPPO, 2000). O fluxo de eventos pode ser usado para determinar quais objetos e
interações serão necessárias para realizar a funcionalidade especificada.
Levando-se em consideração o processo de análise, o diagrama de seqüência é
bastante útil para a verificação dos requisitos do sistema. Cada linha no diagrama que parte de
um ator (que representa uma mensagem) mostra que ele necessita de alguma funcionalidade
do sistema. A melhor maneira de verificar os requisitos é com a ajuda do cliente que usará o
programa.
Desta forma, diagramas de seqüência são úteis para mostrar o que está acontecendo,
para definir os requisitos e para trabalhar com os clientes. Fazer um diagrama de seqüência
para cada fluxo básico de cada caso de uso é o suficiente para abranger todo o sistema. A
Figura 2.5 apresenta um exemplo de diagrama de seqüência ilustrando a interação entre a
estação de controle em solo e o VANT em vôo, a partir do momento em que a aeronave passa
a operar de forma autônoma (a decolagem foi considerada rádio-controlada). Primeiramente o
computador de bordo recebe os dados dos sensores e os envia para a estação. Em seguida,
envia a potência de operação para o motor e os ângulos de inclinação para cada superfície de
controle (ailerãos, leme e profundor) de acordo com a missão estabelecida antes do início do
vôo. Esta seqüência de ações se repete continuamente até o final da missão, quando então o
computador de bordo envia o sinal de término de missão para a estação.
36
Figura 2.5 Diagrama de seqüência.
• Diagrama de colaboração
Este diagrama também permite visualizar as trocas de mensagens entre dois ou mais
objetos dentro de um caso de uso particular ou de um cenário. No entanto, ele apresenta uma
visão diferente de um cenário com objetos, onde o objetivo principal não é ilustrar a ordem
cronológica das mensagens, mas enfatizar as ligações entre os objetos. Um exemplo deste
diagrama é apresentado na Figura 2.6, que ilustra o cenário de comunicação entre a estação de
controle e a aeronave (com seus dispositivos sensitivos e de atuação). A estação envia a
missão e manda o sinal de início da mesma para o computador de bordo da aeronave, que por
sua vez, se comunica com seus atuadores, formados pelo motor e pelas superfícies de
computador de bordo motor superfícies
de controle sensores
Estação
2: enviar status da aeronave
3: enviar potência
4: enviar ângulos de inclinação
1: enviar status da aeronave
5: enviar status da aeronave
6: enviar status da aeronave
7: enviar potência
8: enviar ângulos de inclinação
N: missão finalizada
37
controle, e com os dispositivos de detecção de sinais, formados pelos sensores e pelo receptor
de GPS.
Figura 2.6 Diagrama de colaboração.
• Diagrama de estados
Este diagrama apresenta a história da vida de uma determinada classe. Ele mostra os
eventos que causam uma transição de um estado para outro e as ações que resultam de uma
mudança de estado. Ele deve ser elaborado para classes de objetos que possuem
comportamento dinâmico. Douglass (2002) define estado como sendo uma “condição de
existência de um Classificador que persiste por um período significante de tempo e é
distinguível2 de alguma forma de outra condição de existência”.
Para que o sistema passe de um estado a outro, é necessário que ocorra algum evento
que constitui um gatilho (trigger) para esta mudança. As tarefas podem ser desempenhadas
2 O estado pode ser distinguido em termos de:
Comportamento do objeto enquanto entra, sai ou existe naquele estado; Eventos aceitos enquanto naquele estado; e Gráfico de alcançabilidade de estados subseqüentes.
computador: ComputadordeBordo
motor: Motor
superfíciesdeControle: Ailerãos
Leme Profudor
3: ligar motor 4: ajustar potência 5: desligar motor
1: atribuir missão 2: iniciar missão
6: ajustar atitude
: Estação
detectoresdeSinais: SensorPressão SensorInercial
GPS
7: enviar status da aeronave
1: finalizar missão
38
tanto na passagem de um estado a outro, quanto dentro do estado (em sua entrada ou em sua
saída). O primeiro estado é aquele que recebe a seta do círculo escuro e o diagrama é
finalizado numa circunferência com um círculo dentro. Um estado pode possuir uma transição
para ele mesmo (self-transition).
Na Figura 2.7 é possível visualizar um exemplo deste diagrama que ilustra como
poderia ser o controle do ângulo de inclinação do profundor de uma aeronave. O controle é
iniciado no primeiro estado e logo em seguida avança-se para o segundo estado, cuja função é
obter a altitude atual e a altitude de referência da aeronave. Feito isto, o próximo estado
calcula o erro (diferença entre as duas altitudes obtidas) e então é realizada a atuação no
profundor no estado seguinte. Em seguida retorna-se para o segundo estado para obter
novamente as altitudes. A execução realiza este laço até a finalização do programa.
Figura 2.7 Diagrama de estados.
• Diagrama de classes
Este diagrama ilustra a natureza estática do sistema, apresentando as classes existentes
e como elas se relacionam entre si. Um modelo pode ser ilustrado em vários diagramas de
Iniciacao
faca: Inicie controle
Atuacao
faca: Calcule angulo profundor faca: atue profundor
Calcular erro
faca: Calcule erro
Obtenha Altitude
Obtenha Altitude
Atue
Calcule erro
Receber Altitude
entrada: Altitude entrada: Referencia
Obter Altitude Obter Referencia
39
classes. O fato de duas classes estarem conectadas indica que pode haver troca de mensagens
entre elas.
Conforme apresentado na Seção 2.1, uma classe representa um conjunto de objetos
com estrutura, comportamento, relações e semânticas comuns. As classes são definidas
através do exame dos objetos nos diagramas de seqüência e diagramas de colaboração. Na
UML elas são representadas por retângulos divididos em três compartimentos: o primeiro
contém o nome da classe, o segundo apresenta sua estrutura (atributos) e o terceiro apresenta
seu comportamento (operações).
Os principais elementos de modelagem da UML encontrados em diagramas de classes
são:
classes e sua estrutura e comportamento;
relacionamentos de associação, agregação, dependência e herança; e
indicadores de multiplicidade e navegação.
As operações de uma classe são encontradas examinando-se os diagramas de
interações (diagramas de seqüência e de colaboração). Já os atributos são definidos
analisando-se os requisitos.
Os relacionamentos representam um caminho de comunicação entre objetos. Há três
tipos principais de relacionamentos na UML: associação, agregação, dependência e herança.
A associação é uma conexão bidirecional entre classes e significa que uma classe pode
mandar uma mensagem para outra, pois conhece a existência da mesma. Este relacionamento
é representado por uma linha conectando as classes. A agregação é uma forma mais forte
onde o relacionamento é entre um todo e suas partes. É representada por uma linha
conectando as classes com um diamante próximo à classe que representa o todo. A
dependência é uma forma mais fraca que mostra o relacionamento entre um cliente e um
fornecedor, onde o cliente não tem conhecimento semântico do fornecedor. É representado na
40
UML por uma linha tracejada apontando do cliente para o fornecedor. Estes relacionamentos
são ilustrados na Figura 2.8, que exemplifica uma forma de como pode ser feito o controle de
velocidade e de altitude de um VANT através de classes distintas de controle de cada uma
destas grandezas.
Figura 2.8 Diagrama de classes.
A ilustração dos relacionamentos pode incluir também multiplicidade e navegação. A
multiplicidade define quantos objetos participam de um relacionamento. É o número de
instâncias de uma classe relacionada a uma instância de outra classe. Ela é representada por
um número próximo à classe e pode ser um número ou um intervalo e caso o número de
instâncias seja muito grande, pode ser utilizado um asterisco. A navegação diz respeito ao
sentido da mensagem numa comunicação. Por definição, um relacionamento é bidirecional,
porém, sempre que possível, é aconselhável definir o sentido da mensagem, caso esta ocorra
Profundor
angulo
ajusteAngulo(ângulo)
ControleProfundor
altitude angulo erro
ajusteAltitude(altitude)
ControleVelocidade
velocidade potencia erro
ajusteVelocidade(potencia)
ControleVoo
ajusteAtitude() envieAtitude() recebaMissao()
Motor
potencia
ajustePotencia(potencia)
CalculoAtuacao
erro
calculeAtuacao(erro)
Estacao
recebaAtitude() envieMissao()
41
em apenas um sentido. Ele é representado com uma seta ligando as duas classes, partindo da
classe de onde sairá a mensagem e chegando à classe que receberá a mensagem.
Um outro tipo de relacionamento entre classes é a herança, já introduzida na Seção
2.1. É a relação entre uma superclasse e uma subclasse e é ilustrada por um triângulo no
terminal da linha próximo à superclasse. A Figura 2.9 apresenta um diagrama de classes com
os conceitos de multiplicidade, navegação e herança. As classes “ControleVelocidade” e
“ControleProfundor” são herdadas da classe “ControleVoo”. Apresenta-se ainda a quantidade
de instâncias nas relações e o sentido da comunicação nos casos em que ela ocorre em apenas
um sentido.
Figura 2.9 Diagrama de classes com multiplicidade, navegação e herança.
Profundor
angulo
ajusteAngulo(ângulo)
ControleProfundor
altitude angulo erro
ajusteAltitude(altitude)
ControleVelocidade
velocidade potencia erro
ajusteVelocidade(potencia)
ControleVoo
ajusteAtitude() envieAtitude() recebaMissao()
Motor
potencia
ajustePotencia(potencia)
CalculoAtuacao
erro
calculeAtuacao(erro)
Estacao
recebaAtitude() envieMissao()
1...* 0...1
1 1
1
1...4
42
• Diagrama de componentes
É utilizado para ilustrar a organização e as dependências entre os componentes do
software, incluindo componentes do código fonte, componentes de tempo de execução ou um
componente executável. Os componentes são representados por um retângulo com dois
retângulos menores ao lado, como pode ser visto na Figura 2.10.
Os símbolos circulares representam as interfaces, que neste caso, mostram que
“Controle.exe” é dependente da interface “Sensoriamento”, associada a “Sensores.dll” e
“Guiamento.exe” é dependente da interface “Atuação”, associada a “Atuadores.dll”.
Figura 2.10 Diagrama de componentes.
• Diagrama de implantação
Mostra os processadores que compõem o sistema e as conexões entre eles. Ilustra a
distribuição dos componentes através do sistema. É uma forma visual de saber quais
executáveis estão sendo executados em quais processadores. Um exemplo de diagrama de
implantação é apresentado na Figura 2.11, onde ilustra-se o caso em que o programa de
controle, navegação e guiamento está sendo executado no computador de bordo do VANT,
enquanto que microcontroladores dedicados fazem a interface entre ele e sensores e atuadores,
que possuem outro programa executável. O programa do computador de bordo se comunica
ainda com a estação de controle em solo e com um satélite.
Guiamento.exe Controle.exe
Atuadores.dll Sensores.dll
Sistema de Comunicação
Atuação
Sensoriamento
43
Figura 2.11 Diagrama de implantação.
A seguir é descrita a ferramenta CASE utilizada para implementar a modelagem do
software no computador, o RRRT.
2.3 Rational® Rose® RealTime
O Rational® Rose® RealTime – RRRT é uma ferramenta CASE (Computer Aided
Software Engineering) utilizada para modelar sistemas de software baseada em UML.
Entende-se por ferramenta CASE “uma coleção integrada de ferramentas projetadas para
auxiliar no processo de ciclo de vida de desenvolvimento de produtos de software
compatíveis” (SCHULMEYER, 1992).
Schulmeyer (1992) lista alguns dos benefícios da utilização de uma ferramenta CASE,
dentre os quais estão benefícios de custo, retrabalho reduzido, suporte automático para o
usuário, processos melhor gerenciados e desempenho de produto melhorado. Ainda segundo
Schulmeyer, a necessidade para um ambiente CASE integrado é destacada pelo custo do
software, sua qualidade, sua consistência e confidência.
O RRRT permite a modelagem de sistemas de software utilizando a UML como
linguagem de modelagem e fornece suporte para utilização das linguagens de programação C,
Computador de Bordo (VANT)
Estação de Controle
Acionamento e Sensoriamento
(VANT)
Satélite
44
C++ e JavaTM. Ele gera o código fonte a partir dos diagramas da UML do modelo
desenvolvido pelo usuário e utilizando algum compilador já instalado no computador, produz
o arquivo executável a partir deste código fonte gerado. É possível gerar o código para ser
executado em vários sistemas operacionais (como Windows® NT/2000/XP/CE, QNX® ou
Linux, por exemplo) e várias arquiteturas de processador (como x86 ou sparc).
A motivação para o desenvolvimento do RRRT foi a necessidade da criação de uma
ferramenta que facilite o desenvolvimento de software. Em aplicações típicas de tempo real
dirigidas a eventos, em torno de 85% do código é derivado do projeto de alto nível e
comportamento detalhado de estado. Os 15% restantes são detalhes que são melhor expressos
utilizando uma linguagem de programação tradicional, pois precisam ser especificados
manualmente (RATIONAL SOFTWARE CORPORATION, 2003). Projetistas podem utilizar
o RRRT e a UML para capturar o projeto do sistema, então o compilador de UML (e não o
próprio projetista) traduz o projeto em código. Desta forma, o projetista deve se preocupar
apenas com os detalhes de projeto. Além do mais, a geração automática de código diminui
substancialmente a probabilidade de ocorrência de erros, aumenta a produtividade e diminui o
esforço e o tempo requerido para o desenvolvimento de um produto de software.
O RRRT distingue as classes que compõem um modelo em duas categorias: as
cápsulas, correspondentes às classes dinâmicas, que possuem comportamento, e as classes
estáticas, que não possuem comportamento. No restante deste texto, o termo classe será
utilizado para referenciar classes estáticas, enquanto o termo cápsula será utilizado para classe
dinâmica.
A geração de código realizada pelo RRRT é feita da seguinte forma (RATIONAL
SOFTWARE CORPORATION, 2003): para cada cápsula, classe e protocolo existentes no
modelo é gerado um arquivo fonte (extensão .c) e um arquivo de cabeçalho (extensão .h).
Além destes arquivos, são necessários alguns arquivos relativos aos serviços oferecidos pelo
45
RRRT, como por exemplo, de temporização (em geral, são criados quatro arquivos de código
fonte: “TimerControlBlock.c”, “Timer”, “SelfTimer” e “BaseTimer”, porém, um estudo
destes arquivos não faz parte do escopo deste trabalho).
Os arquivos gerados referentes às cápsulas possuem várias funções que refletem sua
construção. Dentre elas, há uma função onde é refletido o comportamento da cápsula, ou seja,
o desenho do diagrama de estados (a formação desta função depende da quantidade de
estados, transições, a interligação entre estes elementos e os possíveis eventos que disparam
estas transições). Existe também uma função para cada transição do diagrama, que possui
algumas chamadas de funções que são executadas ao ocorrer um evento que dispare esta
transição, e há o corpo de cada uma destas funções.
Além destas funções, estes arquivos possuem uma estrutura de mapeamento dos sinais
de protocolo que podem ser utilizados para comunicação com outras cápsulas através de suas
portas. Também há várias definições de vetores que contêm, dentre outras coisas, os nomes
dos estados do diagrama de estados, índices associados a cada um deles, as portas da cápsula
com protocolo e cardinalidade e os atributos com seus respectivos tipos.
Já os arquivos gerados referentes às classes são bem mais simples do que os das
cápsulas, pois elas não possuem comportamento (diagrama de estados). Há apenas as
declarações dos atributos da classe e seus tipos, de suas operações e descrição do tipo da
classe.
O próximo capítulo apresenta a modelagem no RRRT do software de piloto
automático do VANT usado como estudo de caso neste trabalho.
46
3 Modelagem do Software de Piloto Automático
Antes de apresentar a modelagem do software embarcado do VANT utilizado como
estudo de caso, é realizada uma breve descrição deste VANT, bem como seu hardware e
software. Em seguida, são introduzidos detalhes da malha de controle e modos de
funcionamento, para então, por fim, apresentar a modelagem em UML. Observa-se que neste
trabalho foi modelado apenas o software referente ao controle do profundor3 da aeronave.
Esta modelagem pode ser expandida de forma semelhante para as demais superfícies de
controle.
3.1 Descrição do VANT
O VANT considerado neste trabalho é de asas fixas, para aplicações civis e com nível
de autonomia de controle de trajetória, isto é, com capacidade para planejar de forma
autônoma sua trajetória e efetuar seu guiamento. Observa-se que este VANT não possui
capacidade para realizar pousos e decolagens de forma autônoma.
A finalidade deste VANT é servir como testbed para o estudo, desenvolvimento e
domínio de diversas tecnologias relacionadas ao projeto de sistema de controle e à
comunicação em tempo real com a estação em solo. Uma vez dominadas estas tecnologias, os
conhecimentos adquiridos devem ser aplicados no desenvolvimento de VANTs com missões
específicas, como as descritas na Seção 1.1.
O VANT considerado possui um metro e oitenta centímetros (1,8m) de comprimento,
três metros e sessenta centímetros (3,6m) de envergadura e capacidade de carregar carga útil
de até doze quilogramas (12 kg). A plataforma aérea utilizada foi desenvolvida no Centro de
Estudos Aeronáuticos – CEA, da Universidade Federal de Minas Gerais – UFMG. Já os
3 O profundor é uma das superfícies de controle de uma aeronave. As superfícies de controle são os atuadores do sistema que controlam sua atitude, fazendo o veículo efetuar determinada trajetória.
47
circuitos eletrônicos e o software embarcado de pilotagem e guiamento foram especificados
e/ou desenvolvidos na Flight Technologies.
3.1.1 Hardware
O computador de bordo do VANT utiliza um microprocessador ADSP-BF533,
também conhecido como Blackfin. Este microprocessador opera com clock de 300 MHz,
possui 128 MB de RAM e 10 níveis de pipeline. Um esquema da arquitetura de hardware é
apresentado de forma simplificada na Figura 3.1, onde estão indicados os periféricos ligados
ao processador. Os dispositivos que estão do lado esquerdo fornecem dados de entrada, que
são convertidos através de um condicionador de sinal para o protocolo de comunicação serial
RS-232. O receptor de rádio se comunica diretamente com o processador Blackfin,
transmitindo os comandos do piloto em terra. Do lado direito, encontram-se os dispositivos de
atuação do VANT. O sinal enviado pelo processador também segue o padrão de comunicação
RS-232, que é então convertido por um conversor de sinais usando a técnica de Modulação
por Largura de Pulso (Pulse Width Modulation – PWM). Os sinais de saída deste conversor
são enviados para servomotores (designados na figura por SM), que por sua vez são
conectados nas superfícies de controle (ailerãos, profundor e leme) e no motor de combustão.
Figura 3.1 Esquema simplificado dos componentes de hardware do VANT.
GPS
Sensor inercial
Sensor pressão
Receptor rádio-
controle
Conversor de sinais
RS-232
Ailerãos
Profundor
Leme
Motor de combustão
PWM
PWM
Condicionador de sinais
Microprocessador Blackfin
RS-232
SM
SM
SM
SM
PWM
48
O conversor que faz a interface entre o microprocessador e os servomotores consiste
em um microcontrolador cuja programação é realizada diretamente na liguagem C e não faz
parte do escopo deste trabalho.
3.1.2 Software
O software embarcado no processador Blackfin está organizado em dois módulos
principais: “Guiamento” e “Pilotagem”. O módulo “Guiamento” é responsável por calcular a
trajetória da aeronave para chegar a um determinado destino quando o piloto automático está
em operação. O módulo “Pilotagem” é responsável por calcular o sinal de comando a ser
enviado aos servomotores de forma que a direção de vôo seja aquela definida pelo
“Guiamento”, no caso de piloto automático, ou aquela definida pelo piloto em terra, caso o
piloto automático esteja desativado. Para tanto, o módulo “Pilotagem” recebe os dados do
receptor de GPS e dos demais sensores. O objetivo deste trabalho se restringe ao módulo
“Pilotagem”.
3.1.3 Malha de Controle
O VANT em questão possui três possíveis modos de operação, selecionados pelo
usuário, onde a diferença entre eles é a lei de controle utilizada para calcular o sinal de
atuação para a superfície de controle em questão.
A Figura 3.2 apresenta a malha de controle do profundor e suas possíveis conexões,
que caracterizam a diferença entre os modos de operação para o módulo “Pilotagem”. O sinal
identificado como “Piloto automático” corresponde à trajetória enviada pelo módulo
“Guiamento” ao módulo “Pilotagem”.
49
ControladorPID de θ
CAS
ControladorPID de q
Simulador
Profundor
q m
θ m
Deflexãodo manche
Piloto automático
1 2
3
4
5
Figura 3.2 Malha de controle do profundor.
O modo de operação da aeronave pode assumir os valores 0, 1 e 2, conforme descrito
abaixo:
Modo 0: a aeronave é controlada pelo piloto e o software não realiza nenhum tipo de
controle sobre o valor da variável de entrada vinda do manche (ângulo de inclinação
ou tilt angle). Ou seja, o comando dado no manche age diretamente na atuação do
profundor. Neste modo, a conexão de número 4 da malha de controle é fechada,
resultando na malha apresentada na Figura 3.3.
Deflexãodo manche
Simulador
Profundor
q m
θ m
Figura 3.3 Malha de controle para o modo de operação 0.
Modo 1: a aeronave é controlada pelo piloto, porém existe realimentação de q
(velocidade angular de arfagem) e é incluso na malha um controlador PID para o erro
de atuação desta variável, além de um sistema de aumento de controle (Control
Augmentation System – CAS) para a deflexão do manche. A malha de controle para
este modo possui as conexões 2 e 5 fechadas, resultando na malha apresentada na
Figura 3.4.
50
CASControlador
PID de qDeflexão
do manche
Simulador
Profundor
q m
θ m
Figura 3.4 Malha de controle para o modo de operação 1.
Modo 2: a aeronave não é controlada pelo piloto, é controlada pelo módulo do
software de “Guiamento”, caracterizando um piloto automático e, além da
realimentação de q e seu controlador, possui ainda realimentação de θ (ângulo de
arfagem) e um controlador PID para o erro desta variável. Sua malha de controle é
obtida fechando-se as conexões 1 e 3, como pode ser observado na Figura 3.5.
ControladorPID de θ
ControladorPID de q
Piloto automático
Simulador
Profundor
q m
θ m
Figura 3.5 Malha de controle para o modo de operação 2.
A seguir é apresentada a modelagem em UML do software embarcado do VANT em
estudo. Estes diagramas são baseados nas especificações de requisitos do software
apresentadas pela Flight Technologies.
3.2 Modelagem em UML
3.2.1 Diagrama de Casos de Uso
O passo inicial da modelagem em UML é a elaboração do diagrama de casos de uso,
que ilustra, em alto nível, as tarefas desempenhadas pelo software e sua interação com o
mundo externo, representado pelos atores. A Figura 3.6 apresenta este diagrama.
51
GPS
Inertial Sensor
Boom
Signal Conditioning
Calculate Ailerons Positioning
(from Use Cases and its diagrams)
Calculate Motor Power
(from Use Cases and its diagrams)
Calculate Rudder Positioning
(from Use Cases and its diagrams)
Calculate Elevator Positioning
(from Use Cases and its diagrams)
Adjust Attitude
(from Use Cases and its diagrams)
<<include>><<include>> <<include>><<include>>
<<include>><<include>><<include>><<include>>
Send Output Data
(from Use Cases and its diagrams)
Motor
RudderAilerons
Signal Converter
Elevator
Pilot
Guidance
Receive Input Data
(from Use Cases and its diagrams)
Figura 3.6 Diagrama de casos de uso do piloto automático.
O caso de uso central é “Adjust Attitude”, que é a principal tarefa do software. Ela é
executada através de várias outras tarefas mais detalhadas, como controlar o ângulo do
profundor, controlar o ângulo do leme, a velocidade do motor, entre outras. Os atores que
estão do lado esquerdo da figura são os que enviam sinais de entrada para o sistema, como o
GPS e o sensor inercial. Eles enviam seus respectivos dados para o condicionador de sinal,
também representado por um ator (por ser um elemento externo que interage diretamente com
o sistema). Para este ator, existe um caso chamado “Receive Input Data”, cuja função é
receber todos os dados provindos de todos os dispositivos. Os atores “Pilot” e “Guidance”
enviam seus dados diretamente ao software modelado, sem o intermédio do ator “Signal
Conditioning”.
Para ajustar a atitude, o caso de uso principal recebe os dados dos atores e calcula as
posições dos atuadores: elevator, ailerons, rudder e motor, como pode ser visto nos casos de
52
uso que estão na parte superior da figura. Em seguida, estas posições são enviadas aos
atuadores que são representados pelos atores ilustrados na parte inferior pelo caso de uso
“Send Output Data”, por intermédio do ator “Signal Converter”. Para modificar a posição das
superfícies de controle, o sistema interage com os servomotores, que por sua vez, atuam nas
superfícies de controle. A Tabela 3.1 apresenta uma lista dos atores e uma breve descrição da
funcionalidade de cada um deles.
Tabela 3.1 Lista de atores do VANT. Ator Funcionalidade
GPS Enviar as coordenadas da aeronave por intermédio do ator “Signal Conditioning”
Inertial sensor Enviar as acelerações lineares e angulares da aeronave por intermédio do ator “Signal Conditioning”
Boom Enviar a velocidade e a altitude do VANT por intermédio do ator “Signal Conditioning”
Pilot Enviar os comandos para a aeronave, como por exemplo, a trajetória a ser percorrida através do caso de uso “Receive Input Data”
Guidance Enviar a trajetória calculada no modo piloto automático através do caso de uso “Receive Input Data”
Signal Conditioning Receber os dados dos atores “GPS”, “Inertial Sensor” e “Boom” e retransmiti-los para o sistema através do caso de uso “Receive Input Data”
Signal Converter Retransmitir os dados de atuação provindos do sistema através do caso de uso “Send Output Data” para os atuadores
Elevator Controlar a altitude do VANT de acordo com os comandos recebidos por intermédio do ator “Signal Converter”
Ailerons Controlar o ângulo de rolamento do VANT de acordo com os comandos recebidos por intermédio do ator “Signal Converter”
Rudder Controlar o ângulo de guinada da aeronave de acordo com os comandos recebidos por intermédio do ator “Signal Converter”
Motor Controlar a velocidade do VANT de acordo com os comandos recebidos por intermédio do ator “Signal Converter”
Observa-se que este diagrama não tem efeito na compilação do modelo dentro do
RRRT e na geração automática de código. Sua função é apenas de documentação do sistema.
Uma vez elaborado o diagrama de casos de uso, o próximo passo consiste em detalhar
cada caso de uso através de diagramas de atividades.
53
3.2.2 Diagramas de Atividades
Definidos os casos de uso e atores do sistema, são então elaborados os diagramas de
atividades, que detalham em alto nível as ações desempenhadas no cenário de cada caso de
uso, mostrando passo a passo como cada um deles é realizado.
A Figura 3.7 apresenta o diagrama de atividades correspondente ao caso de uso
“Receive Input Data”, cuja função é receber os dados provindos dos sensores e do receptor de
GPS por intermédio do ator “Signal Conditioning” e do piloto ou do guiamento, e em seguida
enviá-los ao caso de uso “Adjust Attitude” através da atividade em comum “Communicate
input data”.
Start execution Start timer
Receive data from Signal Conditioning
Comunicate input data
Receive data from Pilot
Receive data from Guidance
[Execution finished]
[Else]
[Timeout ocurred]
[Else]
[Else]
[Autonomous mode]
[Execution finished]
[Else]
[Timeout ocurred]
[Else]
[Else]
[Autonomous mode]
Figura 3.7 Diagrama de atividades do caso de uso “Receive Input Data”.
54
Os dados recebidos pelo sistema de cada sensor, GPS e piloto ou guiamento têm uma
amostragem de 20 ms, pois o sistema de aquisição trabalha numa freqüência de 50 Hz. Desta
forma, ao ser iniciado o sistema, é disparado um timer e logo em seguida o caso de uso recebe
os dados vindos do condicionador de sinal e do piloto (modo controlado) ou do guiamento
(modo autônomo) e os envia para o caso de uso que o utilizará. Em seguida o sistema verifica
se a execução do software foi finalizada. Em caso positivo, o diagrama passa para o estado
final. Em caso negativo, ele verifica se ocorreu timeout. Estas verificações são repetidas até a
ocorrência de timeout, quando então é disparado novamente o timer e repetido os passos
acima descritos.
O diagrama de atividades que detalha as ações do caso de uso “Adjust Attitude” é
apresentado na Figura 3.8 e seu papel é receber os dados provindos de atores (que
representam a realimentação do sistema de controle à malha fechada do VANT) e calcular os
comandos de atuação das superfícies de controle e do motor da aeronave através de
funcionalidades fornecidas por outros casos de uso.
55
Start Execution
Comunicate input data
Calculate ailerons positioning
Calculate rudder positioning
Calculate elevator positioning
Select operation mode
Comunicate output data
Prepare to receive data
Calculate motor power
[ Else ]
[ Execution not finished ]
[ Else ]
[ Execution not finished ]
Figura 3.8 Diagrama de atividades do caso de uso “Adjust Attitude”.
Para realizar o caso de uso Adjust Attitude, este diagrama de atividades mostra que,
primeiramente são recebidos os dados vindos do caso de uso “Receive Input Data” através da
atividade “Comunicate input data”. Em seguida, ele verifica o modo de operação do VANT,
pois isto altera a forma com que será realizado o controle. São, então, calculados os comandos
que devem ser enviados aos atuadores com utilização de funcionalidades fornecidas por
outros casos de uso, para em seguida serem enviados aos respectivos atuadores pelo caso de
uso “Send Output Data” através da atividade “Comunicate output data”. Caso a execução do
56
software tenha sido finalizada, o diagrama passa para o estado final, em caso negativo, ele
retorna para a atividade “Prepare to receive data” e se repete este ciclo.
O próximo diagrama, apresentado na Figura 3.9, detalha o caso de uso “Calculate
Elevator Positioning”.
Receive data
Calculate elevator positioning
Send elevator positioning
Start Execution
Figura 3.9 Diagrama de atividades do caso de uso “Calculate Elevator Positioning”.
Este diagrama de atividades é bastante simples. Seu papel é apenas o de calcular a
posição do profundor sempre que solicitado pelo caso de uso “Adjust Attitude”. Assim, suas
atividades consistem em receber os dados necessários para este cálculo, em seguida calcular a
nova posição do profundor (elevator) e enviar a resposta para o caso de uso solicitante.
Os outros casos de uso que calculam as posições das superfícies de controle e a
potência do motor possuem diagramas de atividades semelhantes a este, onde a diferença está
apenas no atuador para o qual eles vão calcular as novas posições/potência. As atividades em
seus diagramas são as mesmas do diagrama da Figura 3.9. Portanto, estes diagramas não são
apresentados neste trabalho.
O diagrama de atividades apresentado na Figura 3.10 corresponde ao caso de uso
“Send Output Data”.
57
Comunicate output data
Start execution Prepare to receive data
Send output data to Signal Converter
[ Execution finished ][ Execution finished ]
[ Else ][ Else ]
Figura 3.10 Diagrama de atividades do caso de uso “Send Output Data”.
Este caso de uso possui o papel de enviar os comandos calculados aos atuadores do
sistema por intermédio do ator “Signal Converter”. Em caso de finalização de execução, o
diagrama passa ao estado final, em caso negativo, o ciclo é repetido.
Uma vez finalizados os diagramas de atividades, são construídos os diagramas de
seqüência, apresentados na próxima seção.
3.2.3 Diagramas de Seqüência
A função deste diagrama é apresentar em ordem cronológica as trocas de mensagens
entre os objetos, como explicado na seção 2.2. Como no caso dos diagramas de atividades,
nesta e nas próximas seções são apresentados apenas os diagramas referentes ao cálculo do
comando de atuação do profundor. Diagramas referentes às demais superfícies de controle são
semelhantes.
O primeiro diagrama de seqüência ilustra o cenário de recebimento dos dados de
entrada do sistema em modo não autônomo. Este recebimento é realizado pela cápsula
“DataReceiver”, cuja função é explicada mais à frente. Ele é apresentado na Figura 3.11.
58
/ signal_ConditioningR1 : Signal Conditioning
/ pilotR1 : Pilot / gPSR1 : GPS
/ inertial_SensorR1 : Inertial Sensor
/ boomR1 : Boom
/ dataReceiverR1 : DataReceiver
Idle
1: open serial communication1: open serial communication
Port opened1: send coordinates1: send coordinates
1: send attitude1: send attitude
1: send speed and altitude1: send speed and altitude2: send output data2: send output data
1: send command1: send command
Active
Figura 3.11 Diagrama de seqüência do recebimento dos dados de entrada do sistema em modo
não autônomo.
Antes de receber os dados, é aberta e configurada a comunicação através da porta
serial. A partir daí, as trocas de mensagens são um ciclo em que o ator “Signal Conditioning”
recebe os dados dos sensores do sistema, os envia para a cápsula “DataReceiver”, que
também recebe os comandos do piloto.
O diagrama da Figura 3.12 é referente ao mesmo caso de uso, porém em um cenário
de vôo autônomo, em que o piloto é substituído pelo guiamento.
59
/ signal_ConditioningR1 : Signal Conditioning
/ guidanceR1 : Guidance
/ dataReceiverR1 : DataReceiver
/ gPSR1 : GPS
/ inertial_SensorR1 : Inertial Sensor
/ boomR1 : Boom
Active1: send coordinates1: send coordinates
1: send attitude1: send attitude
1: send speed and altitude1: send speed and altitude
2: send input data2: send input data
1: send command1: send command
Active
Figura 3.12 Diagrama de seqüência do recebimento dos dados de entrada do sistema em modo
autônomo.
A diferença deste diagrama para o anterior é que quando o sistema entra no modo
autônomo, a porta de comunicação já está aberta e configurada (o que ocorreu quando a
aeronave ainda estava em modo não autônomo), descartando esta etapa, e o piloto é
substituído pelo “Guidance”.
Após receber os dados, a cápsula “DataReceiver” os envia para as cápsulas
responsáveis por calcular o comando a ser enviado às superfícies de controle. O diagrama da
Figura 3.13 retrata o cenário de cálculo do comando de atuação do profundor da aeronave e o
envio do sinal de comando calculado para a cápsula “Elevator”.
Procedimentos semelhantes são executados para os demais atuadores, resultando no
cálculo do comando para todas as superfícies de controle.
60
/ elevatorR1 : Elevator
/ elevatorControllerR1 : ElevatorController
/ dataReceiverR1 : DataReceiver
1: send input data1: send input data
2: calculate elevator command2: calculate elevator command
3: send elevator command3: send elevator command
Figura 3.13 Diagrama de seqüência do ajuste de atitude.
Para finalizar, apresenta-se na Figura 3.14 o diagrama de seqüência referente ao
cenário de atuação do sistema. Neste caso, a cápsula “Elevator” recebe do
“ElevatorController” o comando que deve ser repassado ao profundor, o que é realizado por
intermédio do ator “Signal Converter”. Procedimentos semelhantes são executados para os
demais atuadores, resultando no cálculo do comando para todas as superfícies de controle.
61
/ elevatorControllerR1 : ElevatorController
/ elevatorR1 : Elevator
/ signal_ConverterR1 : Signal Converter
/ elevatorR2 : Elevator
1: send elevator command1: send elevator command
2: send elevator command2: send elevator command
3: send elevator command3: send elevator command
Figura 3.14 Diagrama de seqüência de atuação do atuador “Elevator”.
3.2.4 Diagramas de Colaboração
Estes diagramas enfatizam a interação entre os objetos. Existe um diagrama de
colaboração correspondente a cada diagrama de seqüência elaborado. São apresentados neste
texto apenas alguns exemplos ilustrativos.
A Figura 3.15 apresenta o diagrama de colaboração referente ao diagrama de
seqüência de recebimento dos dados de entrada do sistema. Neste, o ator “Signal
Conditioning” recebe mensagens dos atores “GPS”, “Inertial Sendor” e “Boom” e os envia à
cápsula “DataReceiver”, que também recebe dados do piloto.
62
/ signal_ConditioningR1 : Signal Conditioning
/ signal_ConditioningR1 : Signal Conditioning
/ pilotR1 : Pilot / pilotR1 : Pilot
/ dataReceiverR1 : DataReceiver
/ gPSR1 : GPS
/ gPSR1 : GPS
/ inertial_SensorR1 : Inertial Sensor
/ inertial_SensorR1 : Inertial Sensor
/ boomR1 : Boom
/ boomR1 : Boom
Figura 3.15 Diagrama de colaboração de recebimento dos dados de entrada do sistema.
Para o cenário de vôo autônomo, basta substituir o ator “Pilot” pelo ator “Guidance”
na figura acima.
O diagrama apresentado na Figura 3.16 é referente ao caso de uso “Adjust Attitude”. É
possível verificar que há troca de mensagens entre a cápsula responsável por receber os dados
dos atores (DataReceiver) e a cápsula de controle do atuador (ElevatorController), que por
sua vez, troca mensagens com a cápsula responsável por enviar dados ao atuador (Elevator).
/ dataReceiverR1 : DataReceiver
/ elevatorControllerR1 : ElevatorController
/ elevatorR1 : Elevator
Figura 3.16 Diagrama de colaboração do ajuste da atitude.
O último diagrama de colaboração do modelo ilustra a atuação do sistema e pode ser
visualizado na Figura 3.17. Este diagrama mostra que o atuador é controlado por uma cápsula
63
responsável pela atuação (Elevator) por intermédio do ator “Signal Condiotining”, que por
sua vez, troca mensagens com uma cápsula de controle, chamada “ElevatorController”
/ elevatorControllerR1 : ElevatorController
/ elevatorR1 : Elevator
/ signal_ConverterR1 : Signal Converter
/ signal_ConverterR1 : Signal Converter
/ elevatorR2 : Elevator
/ elevatorR2 : Elevator
Figura 3.17 Diagrama de colaboração de atuação no atuador “Elevator”.
3.2.5 Diagramas de Estados
Cada cápsula possui um diagrama de estados que modela seu comportamento. São
apresentados a seguir os diagramas de estados das cápsulas “DataReceiver”,
“ElevatorController” e “Elevator”.
Diagrama de estados do DataReceiver
Este diagrama pode ser visto na Figura 3.18. Ele possui três estados em seqüência,
onde o último estado possui uma transição para ele mesmo (Transition to Self) para
implementar sua funcionalidade principal, que é receber os dados provindos da porta de
comunicação serial e enviá-los para a cápsula “ElevatorController”. A transição chamada
“open_serial_port” é disparada tão logo o modelo é executado, pois seu gatilho (trigger) é
disparado por timeout e sua função é apenas de abrir a comunicação com a porta serial, definir
suas configurações, como por exemplo, a taxa de transferência de dados (baud rate), e enviar
para a cápsula “Elevator” uma variável ponteiro que aponta para a porta serial. A transição
chamada “send_mode” envia o modo de operação para a cápsula “ElevatorController”. Já a
transição chamada “receive_and_send_vector” possui a função de receber os dados provindos
da porta serial (sensores e receptor de GPS), além do comando do piloto ou do módulo de
guiamento, e enviá-los para a cápsula “ElevatorController”. Seu gatilho pode ser disparado
64
por timeout (apenas na primeira vez em que é executado) ou por requerimento da cápsula
“ElevatorController”, que faz esta requisição sempre que o software estiver pronto para
receber novos dados.
port_opened
Active
Idle
receive_and_send_vectorsend_mode
Initial open_serial_port
receive_and_send_vectorsend_mode
Initial open_serial_port
Figura 3.18 Diagrama de estados do “DataReceiver”.
Diagrama de estados do ElevatorController
A função do “ElevatorController” é calcular o ângulo de inclinação do profundor
(Elevator) para que a aeronave mantenha ou alcance a altitude requerida pelo controlador
(piloto ou módulo de guiamento). Seu diagrama pode ser visto na Figura 3.19.
Idle
Angle_Calculating_0 Angle_Calculating_1 Angle_Calculating_2
FalseInitial False
True
TrueTrue
mode_received
False False
True
calculatingcalculating
True
calculating
False
True
Mode0Mode0Mode1Mode1
Mode2Mode2
Mode2_2Mode2_2Mode1_2Mode1_2Mode0_2Mode0_2
FalseInitial False
True
TrueTrue
mode_received
False False
True
calculatingcalculating
True
calculating
False
True
Mode 0?Mode 1?
Mode 2?FalseFalse
Figura 3.19 Diagrama de estados do “ElevatorController”.
65
A transição “mode_received” ao ser disparada recebe o modo de operação (0, 1 ou 2)
da aeronave provindo do “DataReceiver”. Em seguida, é verificado qual foi o modo recebido,
resultando na transição para o estado correspondente, onde são realizados os cálculos do
comando de atuação de acordo com o modo. Caso o modo de operação enviado para esta
cápsula seja um valor inválido (diferente de 0, 1 ou 2), a cápsula assume o modo 0. Após o
recebimento de um valor de modo, o programa ficará em laço efetuando o cálculo do ângulo
de flexão do profundor intermitentemente até que o modo de operação seja alterado, fazendo
com que a cápsula execute o laço correspondente ao novo modo.
Nos estados “Angle_Calculating_0”, “Angle_Calculating_1” e
“Angle_Calculating_2” a cápsula recebe todos os dados enviados pelo “DataReceiver”
através das transições “calculating”, onde também é calculada a atuação do profundor de
acordo com os dados recebidos e enviada para a cápsula correspondente a este atuador. Caso
o modo de operação tenha sofrido alguma alteração, o programa volta para o estado “Idle” e
imediatamente passa para a o estado correspondente ao novo modo. Caso o modo não tenha
sido alterado, o programa se mantém no laço de recebimento dos dados e cálculo da atuação
(seqüência de transições “calculating” – “True” sendo disparada repetidamente).
Diagrama de estados do Elevator
Está cápsula tem como única função mandar o sinal de atuação do profundor através
da porta de comunicação serial de acordo com o sinal recebido do “ElevatorController”. Seu
diagrama de estados pode ser visto na Figura 3.20.
66
W aiting_for_pointer
Active
Initial
send_command
receive_pointer
Initial
send_command
receive_pointer
Figura 3.20 Diagrama de estados do “Elevator”.
Na transição “receive_pointer” é recebido o ponteiro para a porta de comunicação
serial provindo do “DataReceiver”. O próximo passo é aguardar um evento para executar a
transição “send_command”, cuja função é receber o comando de atuação do profundor e
enviá-lo ao driver que transmitirá o comando ao servomotor correspondente. Esta última
transição é disparada diversas vezes durante a execução, sempre que é calculado um novo
comando de atuação.
3.2.6 Diagrama de Classes
Este diagrama é gerado automaticamente pelo RRRT, assim não é necessária sua
criação. A Figura 3.21 mostra as cápsulas e classes do software de controle do profundor do
VANT.
67
Elevator<<Capsule>>
port : int
+ / to_elevatorController : elevatorProtocol+ / to_dataReceiver : elevatorProtocol# / timer : CTiming
DataReceiver<<Capsule>>
cont : int = 0
# / timer : CTiming+ / to_elevatorController : elevatorProtocol~+ / to_elevator : elevatorProtocol~
Serial
serial_port : int*
read()write()open()read_teste()
Vector
mode : floatstick_tilt : floatq : floattheta : floattheta_ref : float
TOP<<Capsule
ElevatorController<<Capsule>>
mode : floate_theta0 : float = 0e_theta1 : float = 0e_theta2 : float = 0tilt : floatq : floattheta : floati : int = 0theta_ref : floatt : int = 0u_theta1 : float = 0e_q0 : float = 0e_q1 : float = 0e_q2 : float = 0u_q1 : float = 0port : int
+ / to_elevator : elevatorProtocol~# / timer2 : CTiming+ / to_dataReceiver : elevatorProtocol
Controller
A : int
PID()
Figura 3.21 Diagrama de classes.
Este diagrama ilustra a natureza estática do sistema, indicando a comunicação entre as
cápsulas (classes dinâmicas). Através dele pode-se verificar as associações e dependências
entre as classes e a estrutura de cada uma – seus atributos, suas operações e suas portas de
comunicação com seus respectivos protocolos.
As cápsulas “DataReceiver”, “ElevatorController” e “Elevator” foram detalhadas na
explicação de seus respectivos diagramas de estados. A cápsula “TOP” foi criada apenas para
fazer a interligação entre as outras cápsulas, como mostrado no diagrama de estruturas, na
Figura 3.22. A classe chamada “Serial” foi criada para fornecer as funcionalidades de
comunicação através da porta serial. Nela foram criadas operações para abrir, ler e escrever na
68
porta serial. Estas operações são utilizadas pelas cápsulas que precisam destes serviços. A
classe “Vector” foi criada para ser utilizada como tipo de dado para a variável que recebe os
dados provindos da porta serial. Ela é utilizada por “DataReceiver” e “ElevatorController”,
que manipulam estes dados. Por fim, a classe “Controller” foi criada para fornecer a
funcionalidade de cálculo do controlador PID do sistema. Ela possui uma operação chamada
“PID” que efetua estes cálculos. Caso seja necessária a implementação de outras leis de
controle, pode-se adicionar novas operações a esta classe para realizar os cálculos
correspondentes aos novos controladores, seguindo a filosofia de reusabilidade de código
pregada pelas boas práticas de engenharia de software.
Foi necessário implementar algumas características no modelo em UML do software
embarcado de piloto automático para permitir sua simulação dentro do ambiente utilizado
(RRRT + MatLab®). A primeira delas foi a funcionalidade de comunicação através da porta
serial do computador (PC), para possibilitar a integração entre o modelo dentro do RRRT e o
simulador de vôo dentro do MatLab®.
3.3 Diagrama de Estrutura
Para finalizar a modelagem dentro do RRRT, o último diagrama que falta é o de
estruturas, que é específico do RRRT e não faz parte do conjunto de diagramas proposto pela
UML. Seu propósito é interligar as cápsulas (classes dinâmicas, que possuem
comportamento) dentro do modelo através de portas de comunicação. Desta forma, define-se
quem troca dados com quem, através de qual porta de comunicação e através de qual
protocolo. A Figura 3.22 apresenta este diagrama para o software modelado, considerando
apenas o controle do profundor. As portas são representadas por pequenos quadrados na borda
das cápsulas. Os quadrados vazios representam portas conjugadas e os cheios representam
portas-base. A diferença entre elas é o sentido das mensagens dos sinais utilizadas por seu
protocolo na comunicação. Na porta-base, os sinais de entrada são utilizados para mensagens
69
de entrada e os de saída, para mensagens de saída. Já nas portas conjugadas, os sinais de
entrada são utilizados para mensagens de saída e os sinais de saída para mensagens de entrada
na porta.
/ dataReceiverR1 : DataReceiver
/ dataReceiverR1 : DataReceiver
/ elevatorControllerR1 : ElevatorController
/ elevatorControllerR1 : ElevatorController
/ elevatorR1 : Elevator
/ elevatorR1 : Elevator
Figura 3.22 Diagrama de estrutura do software.
3.4 Considerações Referentes ao Teste do Modelo
O RRRT possui um modo de simulação, que permite verificar o comportamento do
software modelado não apenas através da observação do valor de variáveis do sistema, mas
também através da evolução dos diagramas de estado das cápsulas. Para esta finalidade o
RRRT apresenta monitores dos diagramas de estado e uma janela de prompt de comando que
permite a visualização de valores e a digitação de dados de entrada durante a simulação.
Utilizando este modo de simulação foram realizados os seguintes testes no software
modelado:
• Testes da comunicação entre as cápsulas e execução dos diversos cenários através do
grafo de fluxo do software modelado.
70
• Testes referentes à implementação da malha de controle. Neste caso analisa-se o dado de
saída da malha de controle para diversos dados de entrada.
Com a execução do modelo, foi testada a troca de dados entre as diversas cápsulas,
verificando a existência de erros na comunicação entre elas. Esta verificação é suportada pelo
modo de simulação do RRRT, que indica a ocorrência de erro quando uma cápsula tenta
enviar um dado para outra sem que esta última esteja preparada para recebê-lo. Foi também
testada a execução do software nos três modos de operação e a mudança entre eles,
verificando que o modelo se comporta da forma esperada.
No que se refere à implementação da malha de controle, foram inseridos dados de
entrada conhecidos (hipoteticamente enviados pelos sensores) e verificada a resposta dada
pelo modelo (comando de atuação do profundor), em seguida comparado com o valor
esperado, previamente calculado a partir da lei de controle implementada.
Estes testes analisam o comportamento do software modelado no que se refere à
correta execução das tarefas necessárias ao piloto automático do VANT. O próximo capítulo
apresenta a aplicação de um conjunto de métricas para avaliação da qualidade do software
gerado pelo RRRT.
71
4 Aplicação de Métricas ao Código do Software
Este capítulo apresenta a aplicação de métricas ao código fonte do software
embarcado gerado pelo RRRT com o objetivo de analisar sua qualidade.
Métrica de qualidade de software pode ser definida como “uma função cujas entradas
são dados de um determinado software e cuja saída é um único valor numérico que pode ser
interpretado como o grau em que o software possui um dado atributo que afeta sua qualidade”
(IEEE, 2005).
A aplicação de métricas de software em seu processo de desenvolvimento tem o
propósito de medir vários de seus atributos e relacioná-los a diferentes aspectos de qualidade
de software (GRADY, 1987; SCHULMEYER, 1992). Alguns destes atributos que podem ser
medidos são tamanho, custo, defeitos, comunicações, dificuldade e complexidade. Cunha
(2006) afirma que “a aplicação de métricas (...) objetiva o fornecimento de informações
tangíveis (...) para o planejamento, projeto, gerenciamento e controle do software, e para a
realização de estimativas de custo e esforços”. Algumas das razões pelas quais um software é
medido são: a indicação da qualidade do produto; a avaliação da produtividade das pessoas
que produzem o produto; a avaliação dos benefícios derivados de novos métodos e
ferramentas de software; e, formação de uma linha básica para estimativas (PRESSMAN,
1995). As medições e métricas permitem entender o processo técnico usado para se
desenvolver um produto, como também o próprio produto.
Segundo Schulmeyer (1992), as métricas podem ser classificadas em três categorias:
detecção de anomalia, previsão e aceitação. As métricas do primeiro grupo identificam
deficiências na documentação ou no código fonte. As métricas de previsão são medidas da
lógica do projeto e da implementação (tratam de forma, estrutura, densidade e complexidade).
As métricas da última categoria são aplicadas ao produto final para avaliar sua conformidade
com os requisitos.
72
Pressman (1995) apresenta uma segunda classificação, onde as métricas são divididas
em duas categorias principais, cada uma das quais dividida ainda em três subcategorias. A
primeira delas agrupa métricas de produtividade, métricas de qualidade e métricas técnicas. Já
a segunda categoria inclui as métricas orientadas ao tamanho, métricas orientadas à função e
métricas orientadas às pessoas. A Tabela 4.1 apresenta uma breve descrição destas duas
categorias e suas subdivisões.
Tabela 4.1 Divisão das métricas em categorias (PRESSMAN, 1995). Categoria Descrição
Métricas de produtividade Concentram-se na saída do processo de engenharia de software
Métricas de qualidade Indicam a conformidade do software às exigências do cliente
Métricas técnicas Concentram-se na característica do software (complexidade lógica, grau de modularidade, etc)
Métricas orientadas ao tamanho Compilam as medições diretas da saída e da qualidade da engenharia de software
Métricas orientadas para a função Oferecem medidas indiretas
Métricas orientadas às pessoas Compilam informações sobre a maneira que as pessoas desenvolvem software e percepções humanas sobre a efetividade das ferramentas e métodos
As métricas apenas complementam as práticas de teste e garantia de qualidade, porém,
não substituem nenhuma técnica já utilizada para garanti-la (SCHULMEYER, 1992). As
métricas de software adicionam formalidade e quantificação aos documentos e revisões de
código. Comparando-se a atividade de teste de software com a aplicação de métricas, a
primeira visa à correção, confiabilidade e desempenho. Já a segunda, tem por objetivo auxiliar
na avaliação de outras qualidades, como manutenibilidade, portabilidade e flexibilidade.
O IEEE (Institute of Electrical and Electronic Engineers) define manutenibilidade
como “a facilidade com que um sistema de software ou componente pode ser modificado para
corrigir falhas, melhorar o desempenho ou outros atributos, ou adaptar a um ambiente
modificado”. Portabilidade é definida como “a facilidade com que um sistema ou componente
73
pode ser transferido de um ambiente de hardware ou software para outro”, e flexibilidade é “a
facilidade com que um sistema ou componente pode ser modificado para uso em aplicações
ou ambientes diferentes daqueles para os quais ele foi especificamente projetado” (IEEE,
1990).
Neste trabalho são abordadas a métrica de Complexidade Ciclomática - V(G), as
métricas de ciência de software de Halstead e a métrica de Linhas de Código – LOC. A
escolha destas métricas é norteada pela disponibilidade de ferramentas para cálculo
automático das mesmas. A métrica de complexidade ciclomática tem sido alvo de pesquisa
por parte de diversos autores (NURMINEN, 2003; JUNG, 2000; TAKAHASHI, 1997;
CURTIS, 1980), apontando sua importância no meio acadêmico (PRESSMAN, 2001;
JORGENSEN, 2002; SOMMERVILLE, 2003). Já as métricas de ciência de software se
encontram entre as mais conhecidas (CURTIS, 1980), fornecendo indicadores referentes à
dificuldade de desenvolvimento do código fonte. Por fim, a métrica de Linhas de Código trata
do nível de documentação do código gerado, o que pode ser considerado um indicador da
facilidade de leitura ou entendimento do código. A seguir apresenta-se um detalhamento de
cada uma destas métricas, assim como sua aplicação para o código fonte gerado pelo RRRT a
partir dos modelos construídos.
4.1 Complexidade Ciclomática – V(G)
O índice de complexidade ciclomática foi proposto por McCabe (1976) e utiliza a
teoria de grafo para medir a complexidade de um software. O cálculo do V(G) é realizado a
partir dos caminhos básicos possíveis que um software pode percorrer. No entanto, qualquer
programa que possui uma ramificação regressiva potencialmente tem um número infinito de
possíveis caminhos. Desta forma, McCabe propõe que sejam considerados apenas os
caminhos linearmente independentes, cujas combinações entre eles formam todos os possíveis
caminhos. Assim, a partir do código fonte é construído um grafo de fluxo de controle G
74
contendo todos os caminhos linearmente independentes. Todo e qualquer possível caminho
pode ser expresso através de uma combinação linear de circuitos deste grafo. A complexidade
ciclomática é então calculada através da seguinte expressão:
pneGV +−=)( (4.1)
Nesta expressão, e é o número de arestas do grafo G, n é o número de nós do grafo e p
é o número máximo de nós conectados por um arco. Como exemplo, a Figura 4.1 apresenta
um grafo de fluxo de controle. Para este grafo, e = 12, n = 9 e p = 2, resultando em V(G) igual
a 5 (V(G) = 12 – 9 + 2 = 5).
Figura 4.1 Exemplo de grafo de fluxo de controle.
Também é possível obter-se o V(G) diretamente a partir da inspeção visual do grafo de
fluxo, através da identificação da quantidade de regiões do mesmo. Uma região pode ser
informalmente definida como uma área incluída no plano do gráfico. O número de regiões é
computado contando-se todas as áreas delimitadas e a área não delimitada fora do gráfico. A
Figura 4.2 apresenta as regiões do grafo de fluxo da Figura 4.1.
75
Figura 4.2 Exemplo de grafo de fluxo de controle com contagem das regiões.
A partir do índice de complexidade ciclomática, tem-se uma medida de quantas
iterações serão necessárias para se percorrer todos os caminhos possíveis a fim de se testar
todas as possibilidades e verificar se ocorrerá algum erro.
Alguns autores, como Vandoren (1997a), apresentam uma avaliação de risco do
software de acordo com o valor obtido do V(G). Esta associação entre o valor do V(G) e o
risco é baseada no fato do V(G) oferecer uma medida quantitativa da dificuldade de se fazer
testes que avaliem de forma completa os possíveis cenários de execução, garantindo assim a
ausência de erros. A Tabela 4.2 apresenta esta associação entre o valor do V(G) e o risco.
Tabela 4.2 Valores limites da complexidade ciclomática (VANDOREN, 1997a). Complexidade Ciclomática Avaliação de risco
1-10 Um programa simples, sem muito risco
11-20 Mais complexo, risco moderado
21-50 Complexo, programa de alto risco
Maior que 50 Programa não-testável (risco muito alto)
1
23
4
5
76
Todos os arquivos dos códigos fontes gerados automaticamente pelo RRRT a partir
dos modelos construídos foram avaliados quanto a métrica de complexidade ciclomática. Os
resultados obtidos para o V(G) dos arquivos gerados são apresentados na Tabela 4.3. Estes
valores de métricas foram obtidos com uso do RTRT cujo cálculo é feito automaticamente
com a inserção dos arquivos dos códigos fontes.
O V(G) é calculado para cada função dentro de cada arquivo gerado pelo RRRT. O
V(G) máximo de cada arquivo listado na tabela é o maior valor obtido dentre suas funções. O
V(G) médio é a média de todos os valores obtidos de todas as funções de cada arquivo.
Tabela 4.3 Valores de complexidade ciclomática obtidos. Arquivo de código fonte V(G) médio V(G) máximo
TOP 4,5 8
Serial 2,59 5
ElevatorController 2,33 43
Elevator 4,28 24
DataReceiver 4,09 32
Controller 1 1
TimerControlBlock 2,33 3
Timer 3,66 8
SelfTimer 3,33 8
BaseTimer 5,09 9
Os quatro últimos arquivos listados na tabela não correspondem a nenhuma cápsula,
classe ou protocolo criados pelo usuário do RRRT, mas são arquivos gerados pelo RRRT para
gerenciamento da temporização de execução do modelo. Desta forma, eles não são
considerados na discussão dos resultados. Os demais arquivos são correspondentes às
cápsulas ou classes do modelo criadas pelo usuário. Uma descrição do procedimento adotado
pelo RRRT para gerar o código fonte a partir dos modelos foi apresentada na Seção 2.3.
Para cada função de cada arquivo listado na tabela analisou-se o valor de V(G) obtido.
Verificou-se que, com exceção da função que possui o maior V(G) de cada arquivo, todas as
77
demais funções possuem complexidade ciclomática menor do que 10 (mais precisamente 1, 2
ou 3), resultando em 91,67% das funções classificadas como simples, sem muito risco. Isto
pode ser constatado pelo V(G) médio de cada arquivo.
Analisando o valor máximo do V(G) de cada arquivo, observa-se em particular os
arquivos “ElevatorController”, “Elevator” e “DataReceiver”, que possuem uma função (e
apenas uma) com o V(G) mais elevado. Não coincidentemente, estes são os arquivos dos
códigos fontes das três cápsulas que implementam as principais funções do modelo, que
realmente executam suas tarefas (de receber os dados do simulador, tratá-los e enviar o
comando de atuação de volta).
Foi verificado que a função que possui o V(G) mais alto de cada arquivo é a que
representa o diagrama de estados da cápsula, descrevendo seu comportamento. A
complexidade desta função é alta devido à forma como ela é criada pelo RRRT. Basicamente,
ela é composta por um laço principal com diversos comandos de decisão internos, o que gera
um elevado número de ramificações no grafo de fluxo da função. Os parâmetros recebidos por
esta função são o estado atual do diagrama de estados, a porta por onde eventualmente é
recebido um determinado sinal e o sinal eventualmente recebido. Desta forma, dentro do laço
existem três níveis de comando switch, um para cada índice que é passado para a função.
No primeiro nível (verificação do estado atual) haverá tantos case quantos forem os estados
mais um. No segundo nível (verificação da porta de onde vem o sinal) haverá tantos case
quantos forem as portas disponíveis para chegada de sinais que disparem uma transição mais
um. Enfim, no último nível (verificação do sinal recebido pela cápsula), haverá tantos case
quantos forem os sinais que estão habilitados para serem recebidos pela porta em questão para
disparar a transição.
A justificativa para o elevado número de switch é a segurança imposta pela geração
de código automatizada para evitar que o software entre em deadlock. De acordo com o
78
procedimento adotado para conversão do modelo em código, sempre há um caminho a ser
percorrido no grafo de fluxo formado a partir do diagrama de estados, mesmo que não haja
nenhum sinal chegando, ou ocorra alguma falha em outro ponto do software que cause o
envio de um sinal que não existe por uma porta qualquer.
Desconsiderando os sinais recebidos e as portas de comunicação, é possível construir
um grafo de fluxo correspondente ao comportamento associado a um diagrama de estados.
Em geral, este grafo de fluxo é mais simples do que aquele correspondente ao código gerado
pelo RRRT a partir do diagrama e resulta em um V(G) significativamente menor. A
desconsideração das portas e sinais é válida uma vez que independentemente da porta de
origem e do sinal, o software percorre o mesmo caminho e executa os mesmos trechos de
código em cada transição. Este resultado indica que em geral, para um mesmo diagrama de
estados, é possível obter códigos fontes com menor V(G) do que aquele gerado
automaticamente pelo RRRT.
Considerando-se, por exemplo, o diagrama de estados da cápsula
“ElevatorController” (apresentado na Figura 3.19, e repetido na Figura 4.3) tem-se que a
transição “mode_received” pode ser disparada por dois sinais provindos de duas portas
diferentes, porém, independentemente de qual seja a porta ou o sinal, o caminho percorrido
será o mesmo. Desta forma, numa geração de código visando à minimização do V(G), isto não
caracterizaria dois caminhos possíveis num grafo de fluxo.
79
Idle
Angle_Calculating_0 Angle_Calculating_1 Angle_Calculating_2
FalseInitial False
True
TrueTrue
mode_received
False False
True
calculatingcalculating
True
calculating
False
True
Mode0Mode0Mode1Mode1
Mode2Mode2
Mode2_2Mode2_2Mode1_2Mode1_2Mode0_2Mode0_2
FalseInitial False
True
TrueTrue
mode_received
False False
True
calculatingcalculating
True
calculating
False
True
Mode 0?Mode 1?
Mode 2?FalseFalse
Figura 4.3 Diagrama de estados do “ElevatorController”.
Considerando simplificações deste tipo, pode-se gerar o grafo de fluxo apresentado na
Figura 4.4, a partir do mesmo diagrama de estados.
Figura 4.4 Grafo de fluxo simplificado para o “ElevatorController”.
Fazendo-se uma rápida inspeção visual deste grafo de fluxo, chega-se a um valor de
V(G) igual a 8, muito inferior a 43, valor este obtido a partir do código gerado
automaticamente pelo RRRT a partir do diagrama de estados da Figura 4.3.
1
2
3
4
5
6
7
8
80
Foi verificado ainda que uma cápsula que não possui diagrama de estados, ou seja, não
possui comportamento (é o caso da cápsula “TOP”), possui o valor de complexidade
ciclomática igual a 8. Isto é uma indicação da complexidade da estrutura criada pelo RRRT
para representar o esqueleto de um diagrama de estados em linhas de código fonte.
Concluindo, caso seja necessária a diminuição do valor do V(G), podem ser
introduzidas alterações na estrutura do modelo construído no RRRT, adicionando-se novas
cápsulas e dividindo-se as tarefas da função original com alto V(G). Observa-se, no entanto,
que este procedimento não garante necessariamente uma diminuição do número de erros ou
do risco, uma vez que estas cápsulas devem se comunicar e esta comunicação deve ser
definida pela pessoa que está modelando o sistema. Em outras palavras, deve-se balancear a
complexidade interna das cápsulas com a complexidade da comunicação entre as cápsulas,
lembrando que a estruturação do código fonte correspondente ao comportamento da cápsula é
realizada de forma automática (a princípio, livre de erros) pelo RRRT, enquanto que a
comunicação entre as cápsulas é responsabilidade de quem define o modelo no RRRT.
4.2 Métricas de ciência de software de Halstead
Segundo Curtis (1980), as medidas de complexidade mais bem conhecidas e mais
estudadas são aquelas resultantes da teoria de Halstead (1977). Halstead propõe o cálculo de
algumas métricas a partir de quatro grandezas básicas medidas diretamente do código fonte
produzido. Estas quatro grandezas são:
n1 = número distinto de operadores contidos em um programa;
n2 = número distinto de operandos contidos em um programa;
N1 = número total de ocorrências de operadores;
N2 = número total de ocorrências de operandos.
A partir destas grandezas, calcula-se o “vocabulário” n e o “comprimento” N a partir
das seguintes expressões:
81
21 nnn += (4.2)
21 NNN += (4.3)
A partir destas métricas básicas, Halstead desenvolve expressões para obter diversas
outras métricas, como comprimento estimado Ne, volume V, dificuldade D e esforço E:
222121 loglog nnnnNe += (4.4)
nNV e 2log= (4.5)
⎟⎟⎠
⎞⎜⎜⎝
⎛⎟⎠⎞
⎜⎝⎛=
2
21
2 nNn
D (4.6)
VDE = (4.7)
As demonstrações destas expressões estão fora do escopo deste trabalho, e podem ser
encontradas em (HALSTEAD, 1977). A Tabela 4.4 lista os significados destas grandezas.
Tabela 4.4 Significados das métricas de Halstead (HALSTEAD, 1977). Métrica de Halstead Significado
Vocabulário – n Número total de ocorrências de operadores e operandos distintos
Comprimento – N Número total de ocorrências de operadores e operandos
Volume – V Quantidade mínima de bits necessários para codificar o programa
Dificuldade – D Medida da habilidade de o programa ser entendido
Esforço – E Estimativa de esforço mental necessário para desenvolver o programa
Todos os arquivos gerados pelo RRRT também foram analisados de acordo com as
métricas propostas por Halstead listadas na Tabela 4.4. Os valores obtidos estão listados na
Tabela 4.5.
82
Tabela 4.5 Valores obtidos das métricas de Halstead. Arquivo de código
fonte Vocabulário
n Comprimento
N Volume
V Dificuldade
D Esforço
E
TOP 61 249 1.476,75 22 32.488,6
Serial 145 627 4.501,79 26 117.047
ElevatorController 238 3.206 25.310,80 96 2.429.840
Elevator 122 693 4.803,00 26 124.878
DataReceiver 146 1008 7.247,33 42 304.388
Controller 51 152 862,21 8 6.897,66
TimerControlBlock 57 288 1.679,86 18 30.237,7
Timer 72 273 1.684,39 28 47.162,9
SelfTimer 65 250 1.505,58 24 36.134,2
BaseTimer 158 1.634 11.934,4 95 1.133.770
De forma semelhante ao realizado para complexidade ciclomática, não são
considerados aqui os quatro últimos arquivos listados na tabela, uma vez que estes não são
referentes ao modelo definido pelo usuário. Analisando-se os dados listados na tabela
observa-se que a cápsula “ElevatorController” possui os maiores valores para todas as
métricas, seguida das cápsulas “DataReceiver” e “Elevator”.
A utilização das métricas de Halstead serve de referência para fazer comparações entre
vários arquivos de código fonte de um ou mais softwares, mas não são sugeridos ou impostos
limites máximos e/ou mínimos para cada um dos valores obtidos. Assim, as conclusões que
podem ser tiradas dos dados obtidos a partir do código gerado são de certa forma, similares às
já obtidas com a métrica de complexidade ciclomática: o código referente à cápsula
“ElevatorController” possui maior complexidade que os demais. O tamanho do código, o
esforço e a dificuldade para seu desenvolvimento são os maiores de todo o software. Isto pode
ser explicado pelo fato de esta cápsula possuir o maior diagrama de estados, com a maior
quantidade de estados e transições, além de ser a cápsula que efetua a maior parte do
processamento durante a execução do modelo.
83
4.3 Linhas de Código – LOC
Diferentemente das duas métricas anteriores, que são medidas indiretas do software, a
métrica de linhas de código é uma medida obtida diretamente do código fonte produzido e é
uma métrica orientada ao tamanho. Ela fornece a quantidade de linhas de código fonte, como
também a quantidade de linhas que são comentários. A relação entre estas duas grandezas
fornece uma noção da facilidade de leitura do código, pois os comentários facilitam o
entendimento das tarefas desempenhadas pelo programa.
A inserção de comentários em um código fonte “pode aumentar a habilidade para
entender e manter programas”, porém, “comentários sem sentido ou incorretos podem ser
nocivos” (WEISSMAN, 1974). Qualquer programa que não seja trivial e não contenha
comentários é difícil de ser compreendido e oferece risco de introdução de erros durante sua
evolução e manutenção (YANG, 2003).
Exemplos de outras métricas orientadas ao tamanho e que são medições diretas são o
custo de produção de um software, a quantidade de páginas de documentação geradas, de
erros encontrados antes da entrega do software (release), de defeitos encontrados depois da
entrega ao cliente, de pessoas que trabalharam no desenvolvimento, entre outras. Nenhuma
destas métricas foi estudada neste trabalho.
Como para as métricas anteriores, foi calculada a quantidade de linhas de código fonte
total e percentual de linhas de comentários para todos os arquivos gerados pelo RRRT. Yang
(2003) estabelece a partir de um estudo baseado em observação de vários códigos fontes
como valor padrão utilizado em diversos projetos de software uma média de 1 linha de
comentário para cada 3 linhas de código fonte, ou seja, uma média de 25% das linhas
formadas por comentários. A Tabela 4.6 apresenta os valores obtidos com uso do RTRT para
esta métrica.
84
Tabela 4.6 Valores da métrica de linhas de código e comentários. Arquivo de código fonte Quantidade total de linhas Taxa de comentários
TOP 130 13,84%
Serial 287 33,1%
ElevatorController 1273 30,63%
Elevator 337 25,33%
DataReceiver 463 29,37%
Controller 88 27,27%
TimerControlBlock 104 20,19%
Timer 126 15,87%
SelfTimer 120 16,66%
BaseTimer 562 15,83%
Como apresentado anteriormente, a cápsula “TOP” não possui comportamento,
portanto, não possui diagrama de estados. Desta forma, ela não possui nenhum código
inserido pelo usuário, o que acarreta que o código fonte produzido é totalmente elaborado
pelo RRRT, incluindo os comentários. Neste caso, a taxa obtida foi de 13,84% das linhas
formadas por comentários, abaixo da média estipulada.
Desconsiderando os quatro últimos arquivos da tabela (que não são referentes ao
modelo definido pelo usuário), para os demais arquivos a taxa obtida foi superior aos 25%,
pois todos estes possuem comportamento ou operações criadas pelo usuário, o que possibilita
a inclusão de comentários por ele, de forma a melhor documentar o arquivo fonte produzido.
Nos quatro últimos arquivos listados na tabela acima, o usuário não participa de sua geração,
então os comentários são gerados pelo próprio RRRT.
A quantidade total de linhas produzidas pelo RRRT nos arquivos de código fonte
referentes aos elementos criados pelo usuário no modelo (cápsulas e classes) foi de 2578, com
uma taxa média de comentários de 26,59%, o que mantém o software gerado
automaticamente a partir dos modelos dentro do estipulado pela literatura.
85
4.4 Considerações sobre a Aplicação de Métricas
De uma forma geral, a aplicação das métricas selecionadas ao código fonte gerado
pelo RRRT apresentou resultados considerados satisfatórios. Um aspecto importante a ser
observado é que a geração de código automático, apesar de resultar em um código maior ou
mais complexo, pode ser considerada mais segura, uma vez que as regras para construção da
estrutura do código podem a princípio ser consideradas livres de erros.
Outro ponto relevante é que, no que se refere ao entendimento do código, o mesmo
tem uma correspondência direta com os modelos construídos. Assim, a compreensão do
código é significativamente auxiliada pela compreensão dos modelos em UML.
A próxima seção apresenta a integração do RRRT com um simulador de vôo
desenvolvido no MatLab®. O objetivo é verificar o comportamento do software de controle
integrado à dinâmica do VANT.
86
5 Descrição da Simulação do Modelo
O objetivo deste capítulo é descrever a integração entre o RRRT e o simulador de vôo
implementado no MatLab® e apresentar a utilização desta integração para verificação do
comportamento do software de controle integrado ao comportamento da planta controlada.
Observa-se que esta simulação restringe-se ao controle do profundor. O controle das
demais superfícies pode ser facilmente incorporado seguindo o mesmo procedimento
utilizado para o profundor.
5.1 Descrição da Montagem de Integração
A Figura 5.1 ilustra o diagrama básico de um sistema de controle (MIYAGI, 1996).
De acordo com este diagrama o dispositivo de realização de controle interage com o ambiente
físico (objeto de controle, ou planta controlada) através de sensores e atuadores. Além disso,
ele interage ainda com o usuário ou operador através de dispositivos de monitoração e
comando. O dispositivo de realização do controle computa os dados provindos dos sensores e
dos dispositivos de comando e envia os dados de resposta para os atuadores (GUERROUAT,
2005), além de informar o usuário sobre o estado atual do sistema através dos dispositivos de
monitoração.
Figura 5.1 Diagrama conceitual básico de um sistema de controle (MIYAGI, 1996).
Operador/Usuário
Dispositivo de comando
Dispositivo de monitoração
Dispositivo de realização de controle
Dispositivo de atuação
Dispositivo de detecção
Objeto de controle
Sistema de controle
87
A Figura 5.2 especifica o diagrama da Figura 5.1 para o VANT em estudo,
considerando o caso da simulação integrada do RRRT com o simulador de vôo.
Neste caso, o usuário é o piloto do VANT que, através do joystick, envia os dados de
entrada referentes à trajetória desejada para o software de controle executado no ambiente
RRRT, através do simulador de vôo executado no Simulink®. O software de controle executa
a malha de controle e envia os dados de atuação de volta para o simulador de vôo, onde está
modelado o comportamento dos dispositivos de atuação (servomotores conectados às
superfícies de controle da aeronave e motor), de detecção (GPS e sensores inerciais e de
pressão) e o objeto de controle (dinâmica do VANT). A monitoração do estado do sistema
também é realizada através do simulador de vôo, que contém elementos que permitem a
visualização da atitude da aeronave.
Figura 5.2 Diagrama conceitual básico do sistema de controle do VANT em estudo.
Para executar a simulação integrada do software de controle com o simulador de vôo
foram utilizados dois computadores que se comunicam através de suas respectivas portas de
comunicação serial, como ilustrado na Figura 5.3. O modelo do software embarcado é
executado no ambiente RRRT em um dos computadores e o simulador de vôo é executado no
ambiente MatLab® - Simulink® no outro computador. Um joystick é ligado na porta USB
Piloto
Joystick
Monitor
Computador
Atuador do Profundor
GPS, sensor inercial e boom
Veículo Aéreo Não Tripulado
Sistema de controle
Software modelado no RRRT Simulador no Simulink®
Simulador no Simulink®
88
(Universal Serial Bus) do computador onde é executado o simulador de vôo para simular o
comando do piloto no manche nos casos em que o software é executado em algum modo de
operação que não seja de vôo autônomo (modos 0 e 1).
Figura 5.3 Esquema de montagem da simulação integrada.
Na simulação integrada, o modelo do RRRT opera de forma passiva, a iniciação e
finalização da simulação são comandadas pelo simulador, através do qual o usuário interage
com o RRRT. Quando é iniciada a execução do modelo, o RRRT aguarda o recebimento de
dados do simulador, para então realizar suas tarefas e enviar a resposta referente aos
comandos para os atuadores.
Para que a simulação integrada ocorra sem conflitos e erros, o modelo no RRRT deve
ser executado num intervalo de tempo menor do que aquele resultante da freqüência de
trabalho do simulador. A troca de mensagens pela porta de comunicação serial ocorre numa
taxa de transferência (baud rate) de 115200 bits por segundo (bps) e a troca de dados ocorre
numa freqüência de 20 Hz, ou seja, a cada 50 ms. O modelo deve, portanto, receber os dados,
processá-los, enviar a resposta para o simulador em menos de 50 ms.
Comunicação serial
Comunicação via porta USB
Simulador no Simulink® Modelo no RRRT
89
5.2 Modificações no Modelo do RRRT
A integração entre o modelo do RRRT e o simulador de vôo requer que algumas
adaptações sejam introduzidas no modelo do RRRT.
Nesta configuração todos os dados recebidos pelo software embarcado provêm do
simulador de vôo. Sendo assim, modifica-se a cápsula “DataReceiver” para interação com um
único ator externo ao sistema, o Simulator, que substitui não apenas o Signal Conditioning e
os atores a ele conectados (GPS, Inertial Sensor, Boom), mas também o Pilot, Guidance,
Signal Converter e os atores a ele conectados. Os dados trafegam formatados em um único
vetor. A Figura 5.4 ilustra o diagrama de seqüência para o cálculo de um comando do
profundor nesta nova configuração. Este diagrama contempla o cenário completo de cálculo
deste comando, desde o envio dos dados de entrada do modelo, até o envio do comando de
atuação de volta para o simulador. Nos diagramas mostrados na Seção 3.2, este cenário é
dividido em vários diagramas de seqüência.
90
/ simulatorR1 : Simulator
/ dataReceiverR1 : DataReceiver
/ elevatorR1 : Elevator
/ elevatorControllerR1 : ElevatorController
1: send input data1: send input data
2: send input data2: send input data
3: calculate elevator command3: calculate elevator command
4: send elevator command4: send elevator command
5: send elevator command5: send elevator command
Figura 5.4 Diagrama de seqüência para a configuração de integração com o simulador de vôo.
5.3 Descrição do Simulador de Vôo
O simulador de vôo utilizado neste trabalho foi desenvolvido por Nei Salis Brasil Neto
e Benedito Carlos de Oliveira, da FlightTechnologies. Este simulador é executado em
ambiente MatLab®, dentro do Simulink® e descreve a dinâmica de vôo do VANT utilizado
como plataforma aérea para testes do sistema de controle projetado para aeronaves.
Neste simulador a aeronave é considerada um corpo rígido com seis graus de liberdade
(6DOF), formados pelas rotações em torno de cada um dos três eixos do sistema de referência
fixo no corpo da aeronave, e pelos movimentos de translação ao longo de cada um destes
eixos. A estrutura básica do simulador é composta por cinco blocos, conforme ilustrado na
Figura 5.5: Actuators, Atmosphere Model, Auto Pilot, Interfaces e 6 DOF Non-Linear Aircraft
Model.
91
Figura 5.5 Estrutura geral do simulador de vôo.
Neste trabalho, a versão do simulador de vôo utilizada não inclui o bloco “Atmosphere
Model”, pois desconsideraram-se perturbações atmosféricas. O “Auto Pilot”, por sua vez, foi
decomposto em dois blocos, “Sensores” e “HARDWARE”. O diagrama de blocos resultante, já
implementado no Simulink®, pode ser observado na Figura 5.6.
Atmosphere Model
6 DOF Non-linear Actuators Interfaces
Auto Pilot
92
Figura 5.6 Simulador de vôo desenvolvido no Simulink®.
O primeiro bloco, chamado “No Actuators”, representa os atuadores da aeronave,
cujas entradas são os comandos que devem ser enviados para eles e, no caso deste trabalho,
são provindos do modelo do RRRT. Suas saídas são os dados de controle da aeronave. O
próximo bloco (6 DOF Non-Linear), que recebe como entrada as saídas do primeiro bloco,
representa o modelo não-linear da aeronave. Neste bloco está modelada a dinâmica de vôo da
plataforma aérea utilizada através das equações de movimento. Em seguida tem-se um bloco
de interface (Interfaces), cuja função é organizar seus dados de entrada (saídas do bloco
anterior), de forma que cada saída deste bloco possua os dados necessários para seu destino.
Por exemplo, a saída chamada “Auto Pilot” possui os dados que devem ser enviados para o
software embarcado do VANT (neste caso, para o modelo no RRRT). Estes dados estão
listados na Tabela 5.1. Por fim, o bloco chamado “HARDWARE” possui a interface de
93
comunicação entre o simulador e o software embarcado (neste caso, o modelo no RRRT). A
única função deste bloco é enviar os dados para o RRRT através da porta de comunicação
serial e receber os dados de retorno correspondentes aos comandos de atuação da aeronave
(dados de saída do modelo). Estes dados são então processados pelo simulador no bloco “No
Actuators”, fechando a malha de controle descrita acima.
Tabela 5.1 Dados enviados pelo simulador para o software. Dado Descrição
Operation Mode Modo de operação da aeronave (valores possíveis: 0, 1 e 2)
Tilt angle Ângulo de inclinação do manche do piloto
q Velocidade angular de arfagem (pitch)
θ Ângulo de arfagem (pitch)
θref Ângulo de arfagem de referência (pitch)
As entradas “Wind Body” e “Wind Inertial” (blocos 6 DOF Non-Linear e Interfaces)
são vetores cujos elementos têm valor zero (0), o que indica que o modelo atmosférico
(perturbações atmosféricas) foi desconsiderado no simulador. Os modelos dos sensores
considerados são ideais, não foram considerados ruídos de nenhuma natureza para a
simulação.
O simulador possui ainda um recurso para que a simulação ocorra aproximadamente
em tempo real (‘pseudo real time’), onde cada segundo de execução corresponde a um
segundo decorrido na realidade.
O bloco “HARDWARE”, que é responsável pela comunicação entre o simulador e o
modelo no RRRT através da porta de comunicação serial, é detalhado na Figura 5.7.
94
Figura 5.7 Bloco responsável pela comunicação serial com o modelo no RRRT.
Este bloco coloca os dados a serem enviados no formato correto, descartando os dados
não utilizados. O envio dos dados ao RRRT é realizado por uma ‘s-function’ do MatLab®,
chamada através do bloco “Comunicação Serial”. Após o envio, o simulador aguarda os dados
de retorno do RRRT, correspondente ao comando para o profundor.
Após a decomposição do vetor de dados de entrada (bloco “INPUTS”), é possível
visualizar os dados descartados. O primeiro vetor resultante da decomposição é formado pelos
dados H, a e rho, correspondentes a altitude, velocidade do som e densidade do ar,
respectivamente. Estes dados não são necessários para o controle do profundor e são,
portanto, descartados. O segundo vetor apresenta os ângulos de Euler (φ, θ e ψ). Destes,
apenas o ângulo θ é utilizado. O outro dado utilizado no cálculo do comando do profundor é a
velocidade de arfagem (q), que está contida dentro do quarto vetor de entrada. Este vetor é
composto pelas três velocidades angulares da aeronave: p, q e r, velocidades angulares de
rolamento, arfagem e guinada, respectivamente.
Além de θ e q, este bloco envia para o modelo pela porta de comunicação serial a
inclinação do manche, proveniente do bloco “Joystick Input” (este bloco reconhece
95
diretamente o joystick conectado ao computador no ID correspondente). São enviados
também o modo de operação da aeronave e o ângulo de arfagem de referência (θref).
O dado de saída do bloco de comunicação serial é o comando para o profundor, cujo
valor varia entre -0,5 e 0,5 e é diretamente proporcional ao ângulo que o profundor deve
assumir, onde -0,5 é o menor ângulo possível (que resulta num movimento de subida da
aeronave) e 0,5 é o maior ângulo possível (que resulta num movimento de descida da
aeronave).
5.4 Simulação
A simulação inicia-se com a execução do modelo do software no RRRT e do
simulador de vôo no Simulink®. A sincronização dos processos é comandada pelo simulador
de vôo, uma vez que o software embarcado aguarda o recebimento de dados do simulador.
Durante a simulação é possível visualizar os monitores de estado das cápsulas da
modelagem, conforme descrito no Capítulo 3. Desta forma, pode-se verificar em que estado
de cada cápsula o software encontra-se em determinado momento. Durante a simulação são
impressos em uma janela DOS os dados recebidos pelo software e o dado de comando do
profundor enviado para o simulador (valor entre -0,5 e 0,5).
A Figura 5.8 apresenta o monitor de estado da cápsula “DataReceiver” após a abertura
e configuração da porta de comunicação serial e o envio do modo de operação para a cápsula
“ElevtorController”. No estado retratado na figura, o modelo está executando a transição que
recebe os dados provindos do simulador de vôo e enviando-os para o “DataReceiver”. Esta
transição, que está em destaque na figura, é executada seguidamente pelo modelo durante toda
sua simulação num intervalo de aproximadamente 20ms, pois a freqüência de envio dos dados
pelo simulador é de 50 Hz.
96
Figura 5.8 Monitor de estados da cápsula “DataReceiver”.
A Figura 5.9 apresenta o monitor de estados da cápsula “ElevatorController”. Ao ser
iniciada a simulação do software, o modelo se mantém no estado “Idle” aguardando o
recebimento do modo de operação enviado pelo “DataReceiver”, que é o gatilho da transição
“mode_received”.
Figura 5.9 Monitor de estados da cápsula “ElevatorController”.
O modelo então verifica o modo de operação e passa para o estado correspondente
(Angle_Calculating_0 para o modo de operação 0, Angle_Calculating_1 para o modo de
operação 1 e Angle_Calculating_2 para o modo de operação 2). Percebe-se que a figura
97
mostra a situação em que o modo de operação é o 1. Através da transição “calculating” esta
cápsula recebe o vetor com os dados provindos da cápsula “DataReceiver”, onde também é
feito o cálculo do comando de atuação na superfície de controle em questão, que neste caso é
o profundor. Ainda nesta mesma transição, a cápsula envia este comando calculado para a
cápsula “Elevator”. Em seguida é verificado se o modo de operação foi alterado. Em caso
positivo, passa-se para o estado Idle e imediatamente para o estado correspondente ao novo
modo de operação. Em caso negativo, o modelo retorna ao estado do modo atual, recebe
novamente o vetor e realiza o cálculo. Este laço se mantém enquanto o modo de operação não
for alterado.
A Figura 5.10 mostra o monitor de estados da cápsula “Elevator”. No momento em
que é iniciada a execução do modelo, é executada a transição que recebe o ponteiro da cápsula
“DataReceiver” (“receive_pointer”) que aponta para a porta de comunicação serial. Em
seguida a cápsula permanece no estado “Active” esperando o recebimento do comando que
deve ser enviado para o simulador, o que ocorre na transição “send_command”. Durante o
restante da simulação, este monitor de estado executa apenas a transição de envio do
comando, pois o ponteiro é recebido apenas uma vez no início da execução.
Figura 5.10 Monitor de estados da cápsula “Elevator”.
98
Da parte do simulador de vôo, é possível observar o estado do sistema através do
monitoramento do valor das variáveis manipuladas pelo modelo. Além disso, o simulador
dispõe de um horizonte artificial, ilustrado na Figura 5.11, que responde aos comandos
enviados. Através deste horizonte artificial, é possível perceber a diferença na resposta do
sistema para os diferentes modos de operação, uma vez que o modo 0 passa o comando do
manche direto para o atuador, enquanto que no modo 1 existe realimentação e um controlador
PID para a variável controlada (θ). De uma forma geral, foi possível observar que a resposta
ao comando no modo de operação 1 é mais suave do que no modo de operação 0.
Figura 5.11 Horizonte artificial no Simulink®.
A simulação integrada permite observar de forma paralela o comportamento do
software embarcado e da planta controlada (VANT). É possível verificar o efeito das
transições de estado do software embarcado na dinâmica do VANT (software → VANT),
assim como a sua resposta a esta dinâmica (VANT → software). Também é possível observar
como o conjunto VANT+software reage aos comandos do piloto. Neste sentido, foram
executados diversos comandos de entrada através do joystick, incluindo a realização de
99
manobras de voltas de 360º dos ângulos de arfagem e rolamento, de forma a verificar o
comportamento do VANT frente à resposta calculada pelo software embarcado.
5.5 Considerações sobre a Integração RRRT - MatLab®
A abordagem apresentada neste capítulo permite a verificação da execução do
software a ser embarcado ainda na forma de modelos (diagramas de estado), mas de forma
integrada com a dinâmica da planta controlada. A integração do RRRT com o simulador de
vôo fecha a malha de controle com dados “reais” provenientes do simulador. O comando de
atuação calculado pelo modelo do software embarcado enviado para o simulador de vôo
também possibilita a análise do comportamento do ambiente controlado (o VANT) através do
horizonte artificial que responde a este comando.
De uma forma geral, existem diferentes abordagens para simulação do sistema de
controle em malha fechada em diversos estágios do processo de desenvolvimento do software
embarcado de um VANT. De acordo com o modelo construído, é possível detectar diferentes
tipos de erros. Além da abordagem apresentada neste capítulo, foram utilizadas também as
seguintes abordagens:
• Modelagem e simulação da lei de controle. Este é o caso onde se simula em um mesmo
ambiente (ex.: Simulink®) a lei de controle e a dinâmica da planta. Neste caso o software
de controle se resume às equações que representam a lei de controle projetada para o
sistema. Em relação a esta abordagem, a abordagem proposta neste capítulo é
caracterizada por um maior detalhamento do software de controle. Além da lei de
controle, o modelo no RRRT inclui rotinas de comunicação para interface do software
embarcado com demais dispositivos, interação com o usuário, recursos para detecção de
falhas, entre outras coisas.
• Modelagem e simulação do tipo hardware in the loop. Neste caso, o software de controle
é embarcado no computador de bordo do VANT, enquanto a dinâmica da planta é
100
executada em outro computador, em um ambiente do tipo MatLab®-Simulink®. É
possível verificar o comportamento do software de controle no que se refere a requisitos
de tempo de resposta, entre outros. Em relação a esta abordagem, a abordagem proposta
neste capítulo apresenta um maior grau de abstração do software de controle, ela permite
acompanhar a execução do software nos diagramas de estado. Desta forma, a detecção e a
correção de erros são realizadas no nível de modelos e não de código.
O próximo capítulo apresenta a conversão do modelo do RRRT para redes de Petri,
um formalismo matemático que permite a verificação matemática de propriedades do modelo,
além de representar, num mesmo diagrama, a dinâmica dos diversos componentes e suas
interfaces.
101
6 Modelagem em Redes de Petri do Software Embarcado
Este capítulo apresenta a modelagem do software embarcado do VANT em redes de
Petri com o objetivo de permitir a verificação formal de propriedades do modelo.
Rede de Petri é um formalismo matemático proposto por Carl Adam Petri para
modelagem de sistemas dirigidos a eventos discretos (MURATA, 1989). Nos sistemas a
eventos discretos, as variáveis que descrevem o estado do sistema são modificadas de forma
discreta de acordo com a ocorrência de eventos instantâneos, isto é, transições. Os valores
destas variáveis de estado permanecem constantes entre a ocorrência de eventos. A evolução
dinâmica do sistema é dirigida pela ocorrência de eventos. De acordo com esta definição, o
software embarcado do VANT pode ser claramente classificado como um sistema dirigido a
eventos discretos, onde os estados e eventos que caracterizam o sistema podem ser
identificados, por exemplo, nos diagramas de estados das cápsulas.
A próxima seção apresenta uma introdução às redes de Petri, indicando os principais
tipos de propriedades analisadas neste tipo de modelo. Em seguida a Seção 6.2 traz uma breve
revisão bibliográfica das propostas de utilização em conjunto dos diagramas da UML e redes
de Petri, de forma a melhor caracterizar a contribuição deste capítulo. Finalmente, a Seção 6.3
define as regras para conversão do modelo construído no RRRT para um modelo em redes de
Petri. Estas regras são aplicadas ao modelo do software embarcado do VANT gerando uma
rede de Petri correspondente para a qual são verificadas diversas propriedades.
6.1 Introdução às redes de Petri
Entre os formalismos matemáticos propostos para modelagem de sistemas a eventos
discretos, as redes de Petri se destacam como ferramenta gráfica e matemática para
representação de sistemas concorrentes, assíncronos, distribuídos, paralelos e não-
determinísticos (MURATA, 1989). Comparando com a modelagem desenvolvida no RRRT,
102
com a modelagem em redes de Petri, esta última apresenta como principal vantagem a
possibilidade de verificação formal de propriedades. Verificação formal é a prova matemática
de que o comportamento do software embarcado obedece a determinadas propriedades
independente do cenário executado ou do caminho percorrido pelo software.
De acordo com Gomes (1999), uma rede de Petri é um grafo bipartido com dois tipos
de nós: lugares (representados graficamente por círculos) e transições (representados
graficamente por barras). Arcos conectam lugares a transições e transições a lugares. Os
lugares estão associados a estados ou condições do sistema, e as transições representam
eventos. Uma possível interpretação é que os lugares de entrada de uma transição (conectados
à transição por um arco que sai do lugar e chega à transição) e os lugares de saída (conectados
à transição por um arco que sai da transição e chega ao lugar) representam as pré-condições e
pós-condições, respectivamente, do evento modelado pela transição. A Tabela 6.1 apresenta
outras possíveis interpretações de transições e lugares de entrada e saída.
Tabela 6.1 Algumas interpretações típicas de transições e lugares (MURATA, 1989). Lugares de entrada Transição Lugares de saída
Pré-condições Evento Pós-condições
Dado de entrada Etapa de computação Dado de saída
Sinais de entrada Processador de sinal Sinais de saída
Recursos necessários Tarefa ou trabalho Recursos produzidos
Condições Cláusula em lógica Conclusão (conclusões)
Buffers Processador Buffers
Os lugares de uma rede de Petri podem conter um número inteiro e não negativo de
marcas. A presença de uma marca em um lugar representa a veracidade da condição associada
ao lugar (MURATA, 1989). Em um determinado instante, a distribuição de marcas nos
lugares de uma rede de Petri indica o estado atual do sistema.
103
Do ponto de vista matemático, uma rede de Petri marcada (Cardoso; Valette, 1997) é
um par N=<R, M0>, onde:
• R é uma rede de Petri definida pela 4-tupla <P, T, Pre, Pos>, onde:
− P={p1, p2, p3, …, pm} é um conjunto finito de lugares.
− T={t1, t2, t3, …, tn} é um conjunto finito de transições.
− P ∩ T = Ø, P ∪ T ≠ Ø.
− Pre: P x T → ℕ define os arcos de entrada das transições (ℕ é o conjunto de números
naturais).
− Pos: T x P → ℕ define os arcos de saída das transições.
• M0: P → ℕ é a marcação inicial da rede.
Pre e Pos podem ser representados na forma de matrizes, onde as linhas representam
lugares e as colunas transições. O valor de um elemento da matriz indica o peso do arco ligando
o correspondente lugar à correspondente transição. Um elemento igual a zero indica que não
existe arco entre os correspondentes lugar e transição. Um exemplo é apresentado na Figura
6.1.
Pre = ⎥⎥⎥
⎦
⎤
⎢⎢⎢
⎣
⎡
100003010010
Pos = ⎥⎥⎥
⎦
⎤
⎢⎢⎢
⎣
⎡
010030100001
M0 = ⎥⎥⎥
⎦
⎤
⎢⎢⎢
⎣
⎡
030
t3t1
p2 p1 p3
t2 t4
3
3
p1
p2
p3
t1 t2 t3 t4
Figura 6.1 Exemplo de rede de Petri e sua representação matricial (Cardoso, Valette, 1997).
A evolução dinâmica da rede de Petri, isto é, a modificação da marcação da rede,
ocorre através do disparo de transições. Uma transição ti está habilitada para disparo quando
todos os lugares à sua entrada (lugares pj, onde Pre (pj, ti)>0) possuem um número de marcas
M(pj) ≥ Pre (pj, ti). Quando uma transição ti dispara, de cada lugar pj de entrada da transição,
removem-se Pre (pj, ti) marcas, e para cada lugar pj de saída da transição adicionam-se Pos (pj, ti)
P2
P1 P3
3
3
T1
T2
T3
T4
104
marcas. A matriz de incidência (W) de uma rede de Petri representa o balanço das alterações
realizadas na marcação da rede após um disparo. Ela é definida como:
W = Post – Pre
Na forma matricial, uma seqüência de disparo de transições é dada por:
M = M0 + W*s
Na equação acima M é a nova marcação e s é o vetor de disparo, onde o valor de s[i]
representa o número de disparos da transição ti.
A definição de redes de Petri apresentada nesta seção corresponde à rede de Petri
ordinária (Cardoso, Valette, 1997). Este é o tipo de rede utilizado nesta tese. São também
utilizados arcos habilitadores e inibidores, que não fazem parte das redes de Petri ordinárias,
mas proporcionam flexibilidade à modelagem. Os arcos habilitadores conectam apenas
lugares a transições, e tem como finalidade habilitar o disparo da transição quando o lugar de
origem possui um número de marcas igual ou superior ao peso do arco. À diferença dos arcos
orientados, no entanto, eles não alteram a marcação do lugar de origem quando do disparo da
transição, influenciando apenas na habilitação da transição. Os arcos inibidores também
conectam lugares a transições, mas diferentemente dos arcos habilitadores, os inibidores
impedem o disparo da transição quando o lugar de origem possui marcas em número igual ou
superior ao peso do arco.
Uma vez construída a rede de Petri que modela o comportamento de um sistema, esta
pode ser analisada através de simulação ou através da verificação formal. No primeiro caso,
observa-se a evolução da marcação da rede através do disparo de transições. Quando duas ou
mais transições estão em conflito, o simulador dispara uma delas e escolhendo assim o
cenário a ser executado (de forma aleatória). A simulação permite, portanto, observar uma das
possíveis evoluções para o sistema, não garantindo a ausência de erros para os cenários que
não foram executados.
105
Por outro lado, a verificação formal garante a veracidade de propriedades para
qualquer cenário possível de ser executado na rede de Petri, ou seja, considera-se todo o
espaço de estado alcançável pela rede de Petri em análise.
Em geral, classificam-se as propriedades a serem analisadas em propriedades
comportamentais e propriedades estruturais. No primeiro caso, a veracidade ou não da
propriedade depende da marcação inicial definida para a rede de Petri. A Tabela 6.2 apresenta
as principais propriedades comportamentais de uma rede de Petri. Uma abordagem para a
verificação de propriedades comportamentais é a construção do grafo de alcançabilidade da
rede de Petri em análise. Este grafo contém todas as marcações alcançáveis pela rede de Petri
e as transições que podem ser disparadas em cada marcação.
Tabela 6.2 Propriedades comportamentais das redes de Petri (MACIEL, 1996). Propriedades comportamentais Descrição
Alcançabilidade Possibilidade de uma marcação ser atingida pelo disparo de um número finito de transições a partir da marcação inicial.
Limitação Uma rede de Petri é limitada se o número de marcas em cada lugar não excede um determinado valor para qualquer marcação alcançável.
Segurança Uma rede de Petri é segura se cada lugar possui no máximo uma marca para qualquer marcação alcançável.
Vivacidade
Indica que a partir de qualquer marcação alcançável existe uma seqüência de disparos que permite disparar qualquer transição da rede. A vivacidade garante, entre outras coisas, a ausência de deadlocks no sistema.
Cobertura Indica se determinada marcação pode ser obtida a partir de uma outra com o disparo de um número finito de transições.
Persistência Uma rede de Petri é persistente se, para qualquer par de transições habilitadas, o disparo de uma transição não desabilita o disparo da outra.
Reversibilidade Uma rede de Petri é reversível se a partir de qualquer marcação alcançável é possível retornar a marcação inicial.
No caso das propriedades estruturais, a veracidade da propriedade independe da
marcação inicial, sendo definida pela estrutura da rede (lugares, transições e arcos). As
principais propriedades estruturais em geral verificadas em uma rede de Petri são:
106
• Paralelismo estrutural: indica se duas transições podem disparar de forma independente,
isto é, uma transição pode disparar antes ou depois ou em paralelo com a outra. Duas
transições ti e tj são paralelas estruturalmente se Pre (p, ti) ∩ Pré (p, tj) = Ø, ou seja, se as
duas transições não têm nenhum lugar de entrada em comum.
• Conflito estrutural: indica uma situação que pode levar a uma disputa não determinística
de recursos (marcas). Duas transições tj e tk estão em conflito estrutural se existe um pi tal
que Pre(pi, tj).Pre(pi, tk) ≠ 0, isto é, se as duas transições têm pelo menos um lugar de
entrada em comum.
• Invariante de lugar: indica um determinado conjunto de lugares cuja soma ponderada das
marcas contidas nestes lugares é constante para qualquer seqüência possível de disparos
independentemente da marcação inicial. Um invariante de lugar pode ser representado por
um vetor f, tal que, f(1).M(p1) + f(2).M(p2) + ... + f(n).M(pn) = cte, onde p1, p2, ..., pn
formam o conjunto de lugares que compõem o invariante de lugar.
• Invariante de transição: indica uma determinada seqüência de disparos de transições que,
quando completada, não altera a marcação da rede, independentemente da marcação
inicial. Um invariante de transição pode ser representado por um vetor s, tal que, cada
elemento s(i) indica o número de disparos da transição ti para este invariante.
6.2 Redes de Petri e UML
Diversos trabalhos na literatura propõem a utilização em conjunto da modelagem em
UML com a modelagem baseada em redes de Petri. Vários autores argumentam a falta de
precisão na semântica formal fornecida pela UML (BOUABANA-TEBIBEL, 2007;
PHILIPPI, 2006; BARESI, 2001; KAMANDI, 2006; BERNARDI, 2002). Conseqüentemente,
a maioria dos trabalhos consiste em, de alguma forma, apresentar procedimentos para migrar
modelos de sistemas baseados em UML para algum tipo de formalismo, como por exemplo, a
107
rede de Petri. A seguir apresentam-se alguns dos diversos trabalhos disponíveis na literatura
que abordam este tema, e a relação entre estes e a abordagem proposta neste capítulo.
Baresi (2001) aponta uma deficiência da UML no que se refere ao processo de
simulação e análise de modelos, o que pode afetar profundamente os custos de
desenvolvimento e a qualidade dos resultados. De acordo com o autor, a falta de uma
semântica para a dinâmica na notação UML limita a capacidade de analisar certas
especificações. Assim, as ferramentas CASE, que dão suporte a este tipo de metodologia,
apesar de disporem de uma grande capacidade de análise para propriedades sintáticas e para
semânticas estáticas, não são efetivas para a análise semântica da dinâmica, como por
exemplo, para a análise e execução de testes de alcançabilidade, cujos benefícios são
largamente conhecidos. A UML, apesar da riqueza sintática, de ser amigável para usuário,
simples e flexível, carece da formalidade requerida para suportar simulação e análise. Visando
preencher esta lacuna, o trabalho de Baresi busca complementar a UML com redes de Petri
temporizadas de alto nível (high-level timed Petri nets – HLTPN) de forma a permitir a
simulação do comportamento de objetos e, se necessário, analisá-los formalmente.
Bernardi (2002) propõe um método para transformar diagramas de estados e
diagramas de seqüência em redes de Petri Estocástica Generalizada (Generalized Stochastic
Petri Nets – GSPNs). Este trabalho também é motivado pela falta de semântica formal nos
diagramas da UML. No entanto, neste caso, utiliza-se apenas um subconjunto dos diagramas,
uma vez que, de acordo com o autor, podem existir ambigüidades entre os diversos diagramas
da UML.
Hee et. al. (2006) discursa sobre a importância de manter a consistência entre os
diversos diagramas fornecidos pela UML. Como solução é proposto o uso de modelos
integrados que são derivados dos demais modelos nos estágios iniciais do processo de
desenvolvimento de um software. Isto é realizado através da representação de casos de uso e
108
ciclos de vida de objetos como simples redes de Petri. A integração das redes em uma rede
única é realizada através da fusão de lugares. Desta forma, o modelo integrado pode ser
utilizado para geração de cenários do sistema.
Bouabana-Tebibel (2007) propõe um mapeamento de modelos de workflows em UML
2.0 para rede de Petri orientada a objeto (Object Petri Nets - OPNs). O propósito deste
trabalho é solucionar o problema de modelagem de processos organizacionais (os workflows),
que são definidos como um conjunto de atividades de negócio e ordenadas de acordo com um
conjunto de regras para entrega de serviços.
Em relação aos trabalhos de Baresi (2001), Bernadi (2002) e Bouabana-Tebibel
(2007), a abordagem proposta neste capítulo limita-se às redes de Petri ordinárias, uma vez
que se considera o poder de modelagem desta rede suficiente para representar, de forma
simples, a dinâmica de um sistema embarcado, facilitando a especificação de regras de
conversão.
Comparando com o trabalho de Hee et. al. (2006), a proposta aqui apresentada não usa
as redes de Petri nas atividades iniciais do ciclo de desenvolvimento do software (como por
exemplo para a modelagem da relação entre casos de uso). Esta tese limita a utilização das
redes de Petri para modelagem do sistema após a elaboração dos diagramas de estado,
seqüência, casos de uso e classes, isto é, quando o modelo em UML é passível de simulação
na ferramenta CASE. O objetivo é primeiramente elaborar e testar o modelo com os recursos
oferecidos pela ferramenta CASE, para então executar a conversão para redes de Petri e a
verificação formal de propriedades. A principal motivação para esta abordagem é permitir a
detecção de grande parte dos erros na ferramenta CASE, uma vez que a verificação formal de
propriedades (executada, por exemplo, através da construção do grafo de alcançabilidade do
sistema) em geral requer maiores recursos computacionais e um maior esforço da parte do
projetista.
109
Finalmente, observa-se que, comparando a proposta apresentada nesta tese com os
trabalhos apresentados na literatura, neste caso a modelagem em redes de Petri não se limita
ao software embarcado modelado em UML, mas inclui também o comportamento da planta
de forma a permitir a verificação de propriedades para o sistema integrado.
6.3 Do modelo do RRRT ao modelo em redes de Petri
A abordagem proposta para obtenção do modelo em redes de Petri a partir do modelo
no RRRT é baseada na conversão do diagrama de estados. Para a identificação e modelagem
da interação entre as cápsulas utilizam-se os diagramas de estrutura e de classes.
No RRRT, os diagramas de estado de cada cápsula são construídos separadamente. A
comunicação entre eles é realizada através de troca de mensagens e/ou dados. Esta
comunicação, porém, não está explícita no diagrama de estados, assim como também não está
explícito o comportamento resultante da composição dos diversos diagramas de estado. Neste
sentido, a conversão dos diagramas de estado para um único modelo em redes de Petri
permite observar em um único modelo o comportamento interno de cada cápsula e sua
interação com as demais cápsulas do sistema.
Como para o caso do modelo no RRRT, o modelo em redes de Petri pode ser
analisado de forma independente ou em conjunto com a dinâmica da planta controlada. Neste
trabalho, optou-se por incluir apenas um modelo simplificado da dinâmica da planta, onde são
representados apenas alguns eventos e estados referentes à comunicação com a planta e ao
comportamento do piloto.
A Tabela 6.3 apresenta a relação proposta entre os elementos do diagrama de estados
da UML e as redes de Petri para a conversão de modelos.
110
Tabela 6.3 Relação entre os elementos de UML e Redes de Petri. UML Redes de Petri
Estado Lugar
Transição Arco – Transição – Arco
Ponto de escolha Lugar com duas transições em conflito
N Pontos de escolha em seqüência Lugar com N + 1 transições em conflito
Estado inicial Lugar com uma marca inicial
Troca de mensagens Lugar de interface ou transição em comum
Para cada estado no diagrama de estados da UML, deve ser definido um lugar
correspondente na rede de Petri. Uma transição entre dois estados do diagrama de estados é
convertido em uma seqüência de arco-transição-arco no modelo em rede de Petri. O ponto de
escolha do diagrama de estados representa uma situação de conflito, desta forma, ele é
modelado na rede de Petri por um lugar com duas transições de saída em conflito. Caso haja
N pontos de escolha numa seqüência, basta inserir (N + 1) transições em conflito na rede de
Petri. O estado inicial na UML é o primeiro estado que o diagrama alcança, representado na
rede de Petri por uma marca inicial dentro do lugar correspondente a este estado. Por fim, a
troca de mensagens entre duas cápsulas é modelada na rede de Petri por um lugar de interface
que é simultaneamente um lugar de saída de uma transição do modelo da cápsula que envia
mensagem e lugar de entrada de uma transição do modelo da cápsula que recebe a mensagem.
Uma forma alternativa de modelagem da troca de mensagens é por uma transição em comum
entre os modelos em rede de Petri das duas cápsulas.
Devido à possibilidade de inserção de código fonte nas transições dos diagramas de
estado, é possível que sejam executados trechos de código diferentes em cada disparo de uma
determinada transição. Se for desejável distinguir na rede de Petri entre a execução de cada
um dos possíveis trechos de código, cada trecho deve ser associado a uma transição distinta,
sendo que o conjunto de transições está em conflito.
111
Outro caso particular que não se inclui no conjunto de regras definido é a existência de
dois eventos distintos que disparam a mesma transição no diagrama de estados da UML.
Neste caso, pode-se também inserir duas transições em conflito na saída do mesmo estado,
configurando as duas situações distintas.
6.4 Conversão do Modelo do Software Embarcado do VANT
O modelo do software embarcado de piloto automático do VANT utilizado como
estudo de caso neste trabalho foi convertido para redes de Petri usando as regras definidas na
seção anterior. Foram convertidos para redes de Petri o modelo do software embarcado, um
modelo simplificado dos eventos na planta controlada e um modelo correspondente ao
comportamento do piloto.
A Figura 6.2 apresenta o diagrama de estados da cápsula “DataReceiver”, que possui 3
estados e 3 transições, sendo uma delas uma transition to self. O componente correspondente
a este diagrama em redes de Petri é apresentado na Figura 6.3, que também possui 3 lugares
com 3 “arcos-transições-arcos” conectando-os, conforme definido nas regras de conversão.
port_opened
Active
Idle
receive_and_send_vectorsend_mode
Initial open_serial_port
receive_and_send_vectorsend_mode
Initial open_serial_port
Figura 6.2 Diagrama de estados da cápsula “DataReceiver”.
112
Figura 6.3 Rede de Petri correspondente ao “DataReceiver”.
O lugar correspondente ao estado inicial da UML (Idle) é o que possui uma marca
inicial (P2). Os arcos de entrada e saída das transições que aparecem cortados na rede de Petri
da Figura 6.3 correspondem às trocas de mensagens entre esta cápsula e as demais cápsulas
do modelo. Na transição T1, por exemplo, onde é aberta e configurada a porta de
comunicação serial do computador, há um arco de saída que envia uma variável que é um
ponteiro desta porta para o componente que representa o “Elevator”. Na transição T2 há um
arco de chegada por onde são recebidos os valores dos sensores provenientes do simulador de
vôo e dois de saída, por onde são fornecidos o modo de operação e os demais valores das
variáveis, respectivamente. A última transição (T3) possui dois arcos de entrada, um
correspondente a requisição de novos dados provenientes do “ElevatorController” e o outro
correspondente ao fornecimento dos dados, proveniente do simulador de vôo.
A Figura 6.4 apresenta o diagrama de estados do “ElevatorController”, que possui
quatro estados, seis pontos de escolha e várias transições. A Figura 6.5 apresenta o modelo
correspondente em redes de Petri.
113
Idle
Angle_Calculating_0 Angle_Calculating_1 Angle_Calculating_2
FalseInitial False
True
TrueTrue
mode_received
False False
True
calculatingcalculating
True
calculating
False
True
Mode0Mode0Mode1Mode1
Mode2Mode2
Mode2_2Mode2_2Mode1_2Mode1_2Mode0_2Mode0_2
FalseInitial False
True
TrueTrue
mode_received
False False
True
calculatingcalculating
True
calculating
False
True
Mode 0?Mode 1?
Mode 2?FalseFalse
Figura 6.4 Diagrama de estados do “ElevatorController”.
Figura 6.5 Rede de Petri correspondente ao “ElevatorController”.
As regiões delimitadas em vermelho, verde e azul representam os três possíveis modos
de operação: 0, 1 e 2, respectivamente. As malhas dos 3 modos são similares, portanto
apresenta-se apenas a explicação correspondente ao modo 0. O lugar definido como “Aguarda
114
variáveis” é correspondente ao estado “Angle_Calculating_0”. A transição T5 representa a
transição “calculating” e o lugar identificado como “Verifica modo”, com duas transições de
saída em conflito (T6 e T7), correspondem ao ponto de escolha “Mode0_2”.
As elipses tracejadas destacam as transições em conflito que partem do lugar inicial da
rede (P1). Existem seis transições agrupadas duas a duas (T4 e T8, T9 e T13, T14 e T18)
devido ao fato de que existem duas situações descritas nas regras que ocorrem
simultaneamente: pontos de escolha em seqüência e trechos de código fonte diferentes
executados na mesma transição em diferentes disparos. Se não houvesse diferentes trechos de
código para mesma transição, bastariam três transições (uma para o modo 0, outra para o
modo 1 e outra para o modo 2, que seriam T4, T9 e T14, respectivamente). Porém, devido aos
trechos de código fonte diferentes, é necessária mais uma transição em conflito para cada
modo (T8, T13 e T18). Observa-se que as transições de saída dos modos de operação são
habilitadas apenas se o modo de operação for alterado, caso contrário, o sistema se mantém no
mesmo modo.
Os arcos que entram ou saem da rede são relativos às trocas de dados entre o
ElevatorController e os outros componentes (“DataReceiver” e “Elevator”). Os arcos
habilitadores e inibidores são utilizados apenas para comunicações entre o modelo e o usuário
de forma a permitir a seleção do modo de operação desejado durante a simulação.
A Figura 6.6 apresenta o diagrama de estados da última cápsula do modelo, o
“Elevator”. A rede de Petri correspondente a este diagrama é apresentada na Figura 6.7.
115
W aiting_for_pointer
Active
Initial
send_command
receive_pointer
Initial
send_command
receive_pointer
Figura 6.6 Diagrama de estados do “Elevator”.
Figura 6.7 Rede de Petri correspondente ao “Elevator”.
Conforme definido nas regras propostas na seção anterior, este componente possui
dois lugares (P4 e “Aguarda atuação”) conectados por um arco-transição-arco (T19) e outro
(T20) retornando para o segundo lugar. O arco que chega à transição T19 representa o
recebimento do ponteiro para a porta de comunicação serial, referente à transição
“receive_pointer” do diagrama de estados. Já o arco que chega à transição T20 representa o
recebimento do comando de atuação do profundor e é referente à transição “send_command”,
que além de receber o comando do “ElevatorController”, o envia para o simulador de vôo,
representado na rede de Petri pelo arco de saída nesta transição.
As redes correspondentes a cada uma das cápsulas compõem uma única rede de Petri
do software embarcado. Esta rede é apresentada na Figura 6.8.
116
Figura 6.8 Modelo completo em rede de Petri.
Os lugares que estão destacados com circunferências tracejadas representam as
interfaces entre os componentes. Existem tantos lugares de interface quantas são as trocas de
dados/mensagens entre os diagramas de estados da UML. Entre o “DataReceiver” e o
“ElevatorController” existem três tipos de trocas de dados/mensagens: envio do modo de
operação do primeiro para o segundo (circunferência número 1), envio de requerimento de
novos dados de sensores do segundo para o primeiro (circunferência número 2) e envio dos
dados dos sensores e do modo de operação do primeiro para o segundo (circunferência
número 3). A circunferência de número 4 representa a interface de envio do ponteiro da porta
de comunicação serial do “DataReceiver” para o “Elevator”. Por fim, o envio do comando de
1
2
34
5
117
atuação enviado do “ElevatorController” para o “Elevator” é representado pela circunferência
de número 5.
Durante a simulação do modelo em UML, o modo de operação é escolhido pelo
usuário, que o define como dado de entrada no simulador de vôo implementado no
Simulink®. Para tornar possível esta escolha na rede de Petri, foi introduzido um componente
chamado “User”, como pode ser observado na Figura 6.8. A comunicação entre este
componente e a parte da rede que representa o software embarcado é realizada através de
arcos habilitadores e inibidores. O sistema sempre opera no modo de operação selecionado
pelo usuário, pois o mesmo habilita as transições de entrada do modo atual e inibe as
transições dos demais modos.
Além do “User”, foi inserido também um componente para representar os eventos do
simulador de vôo (bloco chamado “Flight Simulator (MatLab – Simulink). Observa-se que
estes eventos não incluem o equacionamento da dinâmica da aeronave, uma vez que esta não
pode ser modelada como um sistema a eventos discretos. O objetivo é apenas representar a
troca de dados entre o software embarcado e o simulador de vôo. Desta forma, este modelo
possui apenas dois lugares, um para representar o recebimento do comando de atuação e o
outro correspondente ao envio dos novos dados de sensores para o software embarcado.
6.5 Análise do Modelo em redes de Petri
Conforme apresentado anteriormente, duas abordagens podem ser utilizadas para
análise de modelos em redes de Petri: simulação e verificação formal de propriedades. As
duas abordagens são apresentadas neste trabalho.
A simulação é usada para verificar o comportamento do sistema na ocorrência de
falhas. Neste caso, a rede de Petri correspondente ao comportamento da planta e do usuário é
alterada para incluir a simulação da ocorrência de falhas. O objetivo neste caso é verificar
como o software embarcado responde a estas falhas. Como resultado desta simulação, são
118
propostas modificações na rede do software embarcado para incluir o adequado tratamento
das falhas. Dois tipos de falhas foram considerados nesta análise. O novo modelo, com a
inserção de mecanismos de tratamento destas falhas, é apresentado na Figura 6.9.
Figura 6.9 Redes de Petri do sistema com mecanismos de tratamento de falhas.
A primeira falha visa verificar a resposta no sistema no caso de algum problema na
comunicação entre o software embarcado e os sensores utilizados no sistema. Neste caso os
valores dos sensores não são enviados para o sistema. A modificação proposta neste caso
consiste na inserção de algumas transições temporizadas que indicam um timeout de espera
por estes valores. Caso o software não receba os dados dos sensores dentro do tempo
estipulado, ele executa uma rotina de tratamento de falha (representada por um lugar), onde
1 23
4
119
permanece até que os dados sejam recebidos. Estas transições e lugares estão destacados pelas
elipses 1, 2 e 3 (transições T29, T31 e T33). Caso os dados sejam recebidos enquanto está
ocorrendo o tratamento de falha, então a transição T30 ou T32 ou T34 (depende do modo de
operação) é disparada e o software retorna ao funcionamento normal.
A segunda falha inserida simula o envio de um modo de operação inexistente pelo
usuário. Neste caso, o sistema passa a operar no modo de operação 0 como padrão. Foi
necessária a inserção do lugar e das transições destacadas pela elipse de número 4 (lugar
“Modo Inválido” e transições T25 e T26) e das transições destacadas pelas circunferências
tracejadas (T27, T28 e T35).
No que se refere à verificação formal, as propriedades verificadas neste trabalho são as
de vivacidade (liveness), segurança (safeness), limitação (boundness) e invariantes de lugar. A
propriedade de vivacidade garante a ausência de deadlock e a inexistência de “zonas mortas”,
isto é, partes do modelo que não podem ser executadas. As propriedades de segurança e
limitação garantem que nenhum lugar da rede terá mais do que uma marca em qualquer
cenário possível. Esta propriedade é desejável porque, do ponto de vista da interpretação da
rede, a presença de duas ou mais marcas não tem significado no modelo proposto. Por fim os
invariantes de lugar garantem que as redes correspondentes a cada uma das cápsulas possuem
sempre e exatamente uma marca em seus lugares. Isto equivale a garantir que cada cápsula
possui apenas um estado ativo em cada instante, o que reforça a consistência entre o modelo
em redes de Petri e o modelo em UML.
A verificação das três primeiras propriedades é realizada através da construção do
grafo de alcançabilidade da rede, que apresenta todos os seus possíveis estados alcançáveis
pelo sistema de um ponto de vista global, com todas as possíveis seqüências de disparo de
transições. Este grafo é obtido a partir da rede da Figura 6.10 e é apresentado na Figura 6.11.
120
Figura 6.10 Rede de Petri do modelo sem “User”.
Tabela 6.4 Significados das siglas do grafo de alcançabilidade. Sigla Significado
DI Dados Iniciais EP Envio de Ponteiro AR Aguarda Requisição AA Aguarda Atuação EMO Envio de Modo de Operação RV Recebimento das Variáveis AV0 Aguarda Variáveis (no modo 0) AV1 Aguarda Variáveis (no modo 1) AV2 Aguarda Variáveis (no modo 2) VM0 Verifica Modo (no modo 0) VM1 Verifica Modo (no modo 1) VM2 Verifica Modo (no modo 2) EC Envio de Comando RF Requisição Feita CNS Cálculo dos Novos valores dos Sensores
121
As siglas dentro dos balões representam os lugares da rede, cujos significados estão
listados na Tabela 6.4, que possui ainda na última linha o significado da transição “CNS”.
Figura 6.11 Grafo de alcançabilidade da rede de Petri do modelo.
P1,P2,P4,DI
P1,P3,P4,DI,EP
P1,AR,AA,EMO,RV
AV0,AR,AA,RV AV1,AR,AA,RV
VM1,AR,AA,EC
AV1,AR, AA,EC,RF
AV1,AR, AA,RF,P6
AV2,AR,AA,RV
P1,AR, AA,P5
T1 T2
T4 T14
T9
T5 T10
T11
CNS
T12
T3
T8
T13
T18
P1,AR,P4,EP,EMO,RV P1,P3,AA,DI
T19
T20
TF1,AR,AA,RV
T31
T32
VM1,AR,AA,P5
AV1,AR, AA,RF,P5
T20 T11
TF1,AR, AA,RF,P5
T31
T2 T19
TF1,AR, AA,RF,P6
P1,AR, AA,EC
VM1,AR,AA,P5
CNS
T20
T12
T20
VM2,AR, AA,EC
AV2,AR, AA,EC,RF
AV2,AR, AA,RF,P6
T16
CNS
T17T3
T20
TF2,AR,AA,RV
T34
VM2,AR,AA,P5
AV2,AR, AA,RF,P5
T20 T16
TF2,AR, AA,RF,P5
T33
TF2,AR, AA,RF,P6
P1,AR, AA,EC
VM2,AR, AA,P5
CNS
T20
T17
T20
T15 T33
T3
T3
VM0,AR, AA,EC
AV0,AR, AA,EC,RF
AV0,AR, AA,RF,P6
T6
CNS
T7
T3
T20
TF0,AR, AA,RV
T30
VM0,AR, AA,P5
AV0,AR, AA,RF,P5
T20 T6
TF0,AR, AA,RF,P5
T29
TF0,AR, AA,RF,P6
P1,AR, AA,EC
VM0,AR, AA,P5
CNS
T20
T20
T29
T3
T7
122
A obtenção deste grafo de alcançabilidade desconsiderou o componente “User” da
rede, pois o mesmo possui a única função de possibilitar ao usuário a escolha do modo de
operação durante a simulação do modelo. Sem ele, o modo escolhido pelo HPSim é aleatório.
A retirada deste componente não altera os possíveis estados do sistema.
Neste grafo de alcançabilidade, a presença de uma sigla dentro do balão indica que há
uma, e apenas uma, marca dentro do lugar com o referente nome no estado corrente. Desta
forma, percebe-se que o número máximo de marcas em qualquer lugar, para qualquer estado
alcançável, é um. Assim, como cada lugar é binário, a rede também o é, o que caracteriza a
propriedade de segurança.
De acordo com a definição de vivacidade (liveness), uma rede é viva se toda e
qualquer transição é disparável a partir de uma seqüência de disparos de transições a partir de
uma dada marcação. Assim, pelo grafo de alcançabilidade, percebe-se que as transições T1,
T2, T19, T4, T9 e T14 podem disparar apenas uma vez, o que as torna quase vivas. Esta
característica corresponde ao comportamento desejável para o sistema uma vez que estas
transições correspondem a atividades de iniciação do sistema. Através da análise do grafo de
alcançabilidade também é possível afirmar que não existem situações de deadlock no modelo.
Após o disparo de T4, T9 ou T14 o modelo entra numa seqüência de disparos onde todas as
demais transições são vivas.
A última propriedade verificada no modelo é a existência de invariantes de lugar. Um
invariante de lugar corresponde a uma expressão no formato da Eq. 6.1 que permanece válida
para qualquer marcação alcançável pela rede.
ctepMnfpMfpMfpMf n =++++ )().(...)().3()().2()().1( 321 (6.1)
123
Nesta equação f é um vetor em que f(n) indica a quantidade de marcas no lugar M(pn).
Aplicando esta expressão a cada componente separadamente, obtêm-se as Equações 6.2, 6.3 e
6.4 correspondentes ao “DataReceiver”, ao “ElevatorController” e ao “Elevator”,
respectivamente.
1)AR()3P()2P( =++ MMM (6.2)
1)2VM()2AV()1VM()1AV()0VM()0AV()1P( =++++++ MMMMMMM (6.3)
1)AA()4P( =+ MM (6.4)
Estes invariantes garantem que em cada componente separadamente tem-se apenas
uma marca. Para o “DataReceiver” pode-se concluir, por exemplo, que o sistema nunca estará
abrindo e configurando a porta de comunicação serial e aguardando dados do simulador de
vôo ao mesmo tempo. Para o “ElevatorController”, pode-se concluir que o sistema nunca
funcionará em dois modos de operação ao mesmo tempo, o que não é possível. E para o
último componente, o sistema não ficará aguardando o ponteiro da porta serial e o comando
de atuação ao mesmo tempo.
6.6 Considerações sobre a Modelagem e Análise baseada em Redes de Petri
A principal contribuição das redes de Petri está na formalização da dinâmica discreta
do modelo proposto em UML. Esta formalização permite a verificação de diversas
propriedades do conjunto ‘software de controle + planta controlada’, complementando a
abordagem apresentada no Capítulo 5.
Observa-se que a modelagem em redes de Petri representa apenas a dinâmica dirigida
a eventos discretos. No entanto, o comportamento dinâmico do VANT pode ser classificado
124
como um sistema híbrido, onde coexistem características dinâmicas de sistemas a eventos
discretos e de sistemas de variáveis contínuas. Enquanto o software embarcado pode ser
considerado um sistema dirigido a eventos discretos, a dinâmica da planta é tipicamente
contínua e, portanto, representada por equações diferenciais. Neste sentido, a abordagem
apresentada no Capítulo 5, apesar de não permitir a verificação formal de propriedades,
permite a análise do comportamento do sistema como um todo, considerando aspectos
discretos e contínuos.
O próximo capítulo apresenta as conclusões finais deste trabalho.
125
7 Conclusões
Este trabalho aborda o problema de modelagem e verificação do software embarcado
do piloto automático de um VANT. A modelagem baseada em UML é utilizada como forma
de trabalhar a complexidade do software e aumentar sua confiabilidade, facilitando a
verificação do mesmo e correção de erros.
Os modelos propostos são implementados na ferramenta Rational Rose RealTime -
RRRT. Além da simulação do software modelado no ambiente RRRT, neste trabalho são
também apresentadas três abordagens para análise do modelo proposto.
A primeira abordagem consiste na aplicação de métricas ao código gerado
automaticamente pelo RRRT, utilizando a ferramenta Rational® Test RealTime – RTRT. As
métricas utilizadas são a métrica de complexidade ciclomática, as métricas de ciência de
software de Halstead e a métrica de linhas de código. Estas métricas avaliam a complexidade,
a dificuldade, o esforço requerido para compreensão e a legibilidade do código, refletindo
indiretamente a “qualidade” do código gerado através da modelagem em UML. De uma
forma geral, os valores obtidos na aplicação das métricas satisfazem os limites encontrados na
literatura disponível sobre o assunto.
A segunda abordagem proposta para análise do modelo do software embarcado
consiste em integrá-lo a um ambiente de simulação dinâmica, onde se encontra modelado o
comportamento do VANT. Através desta integração é possível a simulação em malha fechada
do software de controle. Esta abordagem é uma etapa intermediária entre o uso de uma única
plataforma, como por exemplo, MatLab®-Simulink®, para representar ambos sistema de
controle e planta controlada, e uma abordagem do tipo “hardware in the loop”, onde o sistema
de controle é substituído pelo sistema embarcado real que se comunica com o simulador de
vôo. Na abordagem que utiliza uma única plataforma, apenas a lei de controle é modelada, as
rotinas de comunicação e outros detalhes da implementação do software não são
126
considerados. Assim, o tipo de erro que pode ser detectado é limitado. Por outro lado, quando
comparada à abordagem “hardware in the loop”, a abordagem proposta oferece como
vantagem a possibilidade de utilização das ferramentas de debugging do ambiente do RRRT,
podendo assim acompanhar o estado atual do software em execução através dos monitores
dos diagramas de estado, e verificar os valores das variáveis do sistema através de uma janela
de prompt de comando.
A última abordagem utilizada para analisar o modelo em UML do software embarcado
consiste em convertê-lo para um modelo em redes de Petri, com o propósito de realizar a
verificação formal de propriedades do sistema integrado. Verificou-se que o sistema é seguro,
livre de bloqueios (deadlocks) e não apresenta inconsistências, como, por exemplo, operar em
mais de um modo de operação ao mesmo tempo. Além disto, foram introduzidos dois tipos de
falhas e, através da análise do comportamento do sistema em resposta a estas falhas, foram
propostas modificações de forma a tornar o sistema tolerante a estas falhas.
Fazendo-se uma comparação entre estas abordagens, pode-se perceber que elas, de
certa forma, se complementam, uma vez que a primeira é útil para avaliar a qualidade do
código em si, a segunda possibilita a verificação do comportamento dinâmico do sistema de
controle em conjunto com a planta controlada, e a última abordagem permite a realização de
verificação formal do sistema, o que não é possível com as duas primeiras. Ou seja, elas
possuem propósitos diferentes, o que justifica a importância de cada uma.
Este trabalho apresenta uma importante ‘lacuna’ que abre espaço para futuras
contribuições no que se refere à definição dos requisitos que servem de base para validação e
verificação do sistema. Neste trabalho, os requisitos foram definidos de modo informal pelo
usuário do sistema, a Flight Technologies. Como resultado, as abordagens utilizadas para
análise do modelo proposto em UML avaliaram o funcionamento do sistema também de
modo informal, isto é, verificou-se que o sistema funciona de acordo com o ‘esperado’, mas
127
este comportamento ‘esperado’ não foi formalizado em um conjunto de requisitos a serem
obedecidos. Um trabalho importante, portanto, consiste em definir formas de se especificar os
requisitos do sistema e relacionar esta especificação com as abordagens propostas para análise
do modelo em UML. Em outras palavras, devem ser propostos procedimentos para, a partir
dos requisitos, especificar seqüências de testes no RRRT, definir valores desejados para as
métricas e definir propriedades a serem verificadas na rede de Petri do sistema.
Outro ponto a ser explorado é o detalhamento das abordagens propostas nos Capítulos
5 e 6 para o desenvolvimento de sistemas tolerantes a falhas. Uma vez que estas abordagens
representam de forma integrada o comportamento do software de controle e da planta
controlada, é possível inserir no modelo a ocorrência de falhas e observar a resposta do
sistema a estas falhas. A partir desta resposta, devem ser especificados procedimentos para
tornar o sistema mais robusto e tolerante a falhas.
128
Referências
AMIR, Arnon et. al. An embedded system for an eye-detection sensor. Computer Vision and Image Understand, v. 98, n. 1, p. 104-123, Apr. 2005. BARESI, Luciano; PEZZÈ, Mauro. Improving UML with Petri nets. Electronic Notes in Theoretical Computer Science, v. 44, n. 4, p. 107-119, July 2001. BAUDRY, Benoit; TRAON, Yves Le. Measuring design testability of a UML class diagram. Information and Software Technology, v. 47, n. 13, p. 859-879, Oct. 2005. BELL, Donald. UML Basics: An introduction to the Unified Modeling Language. 2003a. Disponível em: <http://www-128.ibm.com/developerworks/rational/library/769.html> Acesso em 16 mai. 2006. BELL, Donald. UML Basics: Part II: The activity diagram. 2003b. Disponível em: <http://www.therationaledge.com/content/sep_03/f_umlbasics_db.jsp> Acesso em 29 mai. 2006. BELL, Donald. UML Basics: Part III: The class diagram. 2003c. Disponível em: <http://www.therationaledge.com/content/nov_03/t_modelinguml_db.jsp> Acesso em 29 mai. 2006. BERGER, Arnold S. Embedded Systems Design: An Introduction to Processes, Tools and Techniques. Lawrence, Kansas: CMP Books, 2002. 237 p. BERNARDI, Simona; DONATELLI, Susanna; MERSEGUER, José. From UML Sequence Diagrams and Statecharts to analyzable Petri Net models. In: Proceedings of the 3rd international workshop on Software and performance. Rome, Italy: 24-26 July 2002. WOSP’02. ACM Press, New York, NY, 35-45. BIHARI, Thomas E.; GOPINATH, Prabha. Object-oriented real-time systems: concepts and examples. Computer, v. 25, n. 12, p. 25-35, Dec. 1992. BLYENBURGH, Peter van. UAVs: an Overview. Air & Space Europe, v. 1, n. 5-6, p. 43-47, Sept.-Dec. 1999. BORGES, Aderbal Alves. Veículos Aéreos Não-Tripulados. In: SEMINÁRIO INTERNACIONAL DE VANT, 1., 2005, São José dos Campos. Apresentação, São José dos
129
Campos: CTA, 2005. Disponível em: <http://www.aviacao-civil.ifi.cta.br/svant/vant.asp>. Acesso em 27 jun. 2006. BOUABANA-TEBIBEL, Thouraya; BELMESK, Mounira. An object-oriented approach to formally analyze the UML 2.0 activity partitions. Information and Software Technology, v. 49, n. 9-10, p. 999-1016, Sept. 2007. BROOKS JR., Frederick P. The mythical man-month: essays on software engineering. Reading, MA: Addison-Wesley, 1995. 322 p. BURNS, Alan; WELLINGS, Andy. Real-Time Systems and their Programming Languages. Wokingham: Addison-Wesley, 1990. 575 p. BYTE CRAFT LIMITED. First Steps with Embedded Systems. Waterloo, Ontario. 2002. 202 p. CESTINO, Enrico. Design of solar high altitude long endurance aircraft for multi payload & operations. Aerospace Science and Technology, v. 10, n. 6, p. 541-550, Sept. 2006. COAD, Peter; NICOLA, Jill. Object-Oriented Programming. Englewood Cliffs, New Jersey: Prentice Hall, 1993. 582 p. COX, Timothy H. et al. Civil UAV Capability Assessment: Draft Version. Dec. 2004. Disponível em: <http://www.nasa.gov/centers/dryden/research/civuav/civ_uav_doc-n-ref.html>. Acesso em 15 set. 2006. CUNHA, Adilson Marques da. CES-32 e CE-230: Qualidade, Confiabilidade e Segurança de Software: Os Conceitos de Confiabilidade, as Métricas de Ponto de Função e suas Aplicações. Notas de aula. São José dos Campos, Instituto Tecnológico de Aeronáutica, 2º Semestre de 2006. CURTIS, Bill. Measurement and Experimentation in Software Engineering. Proceedings of the IEEE, v. 68, n. 9, p. 1144-1157, Sept. 1980. DAMAŠEVIČIUS, R.; ŠTUIKYS, V. Application of the object-oriented principles for hardware and embedded system design. Integration, the VLSI Journal, v. 38, n. 2, p. 309-339, Dec. 2004.
130
DIPIPPO, Lisa Cingiser; MA, Lynn. A UML package for specifying real-time objects. Computer Standards & Interfaces, v. 22, n. 5, p. 307-321, Dec. 2000. DOUGLASS, Bruce Powel. Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems. Boston, MA: Addison-Wesley, 2003. 500 p. (The Addison-Wesley Object Technology Series). DOUGLASS, Bruce Powel. Real-Time UML: Developing Efficient Objects for Embedded Systems. 2. ed. New York, NY: Addison-Wesley, 2002. 328 p. (The Addison-Wesley Object Technology Series). FABIANI, P. et. al. Autonomous flight and navigation of VTOL UAVs: from autonomy demonstrations to out-of-sight flights. Aerospace Science and Technology, v. 11, n. 2-3, p. 183-193, Mar-Apr. 2007. FRANCE, R. et. al. The UML as a formal modeling notation. Computer Standards & Interfaces, v. 19, n. 7, p. 325-334, Nov. 1998. FURLAN, José Davi. Modelagem de Objetos através da UML: Análise e desenho orientados a objeto. São Paulo, SP: MAKRON Books, 1998. 329 p. GILMORE, Stephen; KLOUL, Leïla. A unified tool for performance modelling and prediction. Reliability Engineering & System Safety, v. 89, n. 1, p. 17-32, July 2005. GOMES, Luís. Redes de Petri e Sistemas Digitais: uma introdução. Revisão 1.2. Universidade Nova de Lisboa, 1999. GRADY, Robert B.; CASWELL, Deborah L. Software Metrics: Establishing a Company-Wide Program. Englewood Cliffs, New Jersey: PTR Prentice-Hall, Inc., 1987. 288 p. GRAHAM, I. Requirements Engineering and Rapid Development: an object-oriented approach. Reading, MA: Addison-Wesley, 1998. 271 p. GUERROUAT, Abdelaziz; RICHTER, Harald. A Formal Approach for Analysis and Testing of Reliable Embedded System. Electronic Notes in Theoretical Computer Science, v. 141, n. 3, p. 91-106, Dec. 2005. HALSTEAD, Maurice, H. Elements of Software Science. New York, New York: Elsevier, 1977. 127 p.
131
HATTON, Les. Embedded System Paranoia: a tool for testing embedded system arithmetic. Information and Software Technology, v. 47, n. 8, p. 555-563, June 2005. HEE, Kess von et. al. Consistency in model integration. Data & Knowledge Engineering, v. 56, n. 1, p. 4-22, Jan. 2006. HOARE, C. A. R. Communication Sequential Processes. UK: Prentice-Hall International, 1985. 256 p. HOLDER, Bill. Unmanned Air Vehicles: an illustrated study of UAVs. Atglen, PA: Schiffer Publishing, 2001. 72 p. INSTITUTE OF ELECTRICAL AND ELECTRONIC ENGINEERS. Número da Norma: Std 1068TM-1998 (R2004). IEEE Standard for a Software Quality Metrics Methodology, New York, NY: Institute of Electrical and Electronic Engineers, 2005. INSTITUTE OF ELECTRICAL AND ELECTRONIC ENGINEERS. Número da Norma: Std 610.12-1990. IEEE Standard Glossary of Software Engineering Terminology, New York, NY: Institute of Electrical and Electronic Engineers, 1990. IWU, Frantz et. al. Integrating safety and formal analyses using UML and PFS. Reliability Engineering & System Safety, v. 92, n. 2, p. 156-170, Feb. 2007. JACOBSON, Ivar; BOOCH, Grady.; RUMBAUGH, James. The Unified Software Development Process. Reading: Addison Wesley Longman, Inc., 1998, 463 p. JORGENSEN, Paul C. Software Testing: A Craftsman’s Approach. 2 ed. Boca Raton, FL: CRC, 2002. 359 p. JUNG. Ho-Won; PIVKA, Marjan; KIM, Jong-Yoon. An empirical study of complexity metrics in Cobol programs. Journal of Systems and Software, v. 51, n. 2, p. 111-118, Apr. 2000. KAMANDI, Ali; AZGOMI, Mohammad Adbollahi; MOVAGHAR, Ali. Transformation of UML Models into Analyzable OSAN Models. Electronic Notes in Theoretical Computer Science, v. 159, p. 3-22, May 2006. KIM, Jonghyuk; SUKKARIEH, Salah. Real-time implementation of airborne inertial-SLAM. Robotics and Autonomous Systems, v. 55, n. 1, p. 62-71, Jan. 2007.
132
KIMOUR, Mohamed T.; MESLATI, Djamel. Deriving objects from use cases in real-time embedded systems. Information and Software Technology, v. 47, n. 8, p. 533-541, June 2005. KO, K. H.; POCHIRAJU, K; MANOOCHEHRI, S. An embedded system for knowledge-based cost evaluation of molded parts. Knowledge-Based Systems, v. 20, n. 3, p. 291-299, Apr. 2007. KOPETZ, Hermann. Real-Time Systems: Design Principles for Distributed Embedded Applications. Boston, MA: Kluwer Academic Publ., 1997. 338 p. KROLL, M. et. al. Embedded systems for signing medical images using the DICOM standard. International Congress Series, v. 1256, p. 849-854, June 2003. KUMARAKULASINGAM, Prabhaharan; SAIEDIAN, Hossein. A framework for evaluating the effectiveness of real-time object-oriented models. Information and software technology, v. 44, n. 7, p. 395-404, May 2002. KWAKYE, Sylvia; BAEUMNER, Antje. An embedded system for portable electrochemical detection. Sensors and Actuators B: Chemical, v. 123, n. 1, p. 336-343, Apr. 2007. LABROSSE, Jean J. Embedded Systems Building Blocks: Complete and Ready-to-Use Modules in C. 2 ed. San Francisco, CA: CMP, 2002. 611 p. LAITENBERGER, Oliver et. al. An experimental comparison of reading techniques for defect detection in UML design documents. Journal of Systems and Software, v. 53, n. 2, p. 183-204, Aug. 2000. LAPLANTE, Phillip A. Real-Time Systems Design and Analysis: an engineers’ handbook. 3 ed. Piscataway, NJ: IEEE, 2004. 505 p. LEWIS, Daniel W. Fundamentals of Embedded Software: Where C and Assembly Meet. Upper Saddle River, NJ: Prentice-Hall, 2002. 266 p. LÜTTGEN, Gerald; MENDLER, Michael. Statecharts: From Visual Syntax to Model-Theoretic Semantics, in Workshop on Integrating Diagrammatic and Formal Specification Techniques (IDFST 2001), p. 615-621, Vienna, 2001.
133
MACIEL, Paulo Romero Martins; LINS, Rafael Dueire; CUNHA, Paulo Roberto Freire. Introdução às Redes de Petri e Aplicações. Campinas, SP: Universidade Estadual, 1996, 187 p. MASSINK, Mieke; LATELLA, Diego; GNESI, Stefania. On testing UML statecharts. Journal of Logic and Algebraic Programming, v. 69, n. 1-2, p. 1-74, Aug.-Dec. 2006. McCABE IQ. McCabe IQ – Software Metrics Glossary. Disponível em <http://www.mccabe.com/iq_research_metrics.htm> Acesso em: 18 mar. 2007. McCABE, Thomas J. A Complexity Measure. IEEE Transactions On Software Engineering, v. SE-2, n. 4, p. 308-320, Dec. 1976. MIYAGI, Paulo Eigi. Controle Programável: Fundamentos do Controle de Sistemas a Eventos Discretos. São Paulo, SP: Edgard Blücher LTDA, 1996, 194 p. MURATA, Fellow Tadao. Petri Nets: Properties, Analysis and Applications. Proceedings of the IEEE, v. 77, n. 4, p. 541-580, Apr. 1989. NEEMA, Sandeep et. al. Autonomic fault mitigation in embedded systems. Engineering Applications of Artificial Intelligence, v. 17, n. 7, p. 711-725, Oct. 2004. NEWCOME, Laurence R. Unmanned Aviation: A Brief History of Unmanned Aerial Vehicles. Reston: American Institute of Aeronautics and Astronautics, Inc., 2004. 171 p. OBJECT MANAGEMENT GROUP. Unified Modeling Language: Superstructure, v. 2.0, Aug. 2005. PAIGE, R. F.; OSTROFF, J. S.; BROOKE, P. J. Principles for modeling language design. Information and Software Technology, v. 42, n. 10, p. 665-675, July 2000. PALMA, Diego Pivoto. Estudo sobre os aspectos de Desenvolvimento e Certificação de Software para Produtos Aeroespaciais de Emprego Militar. 2005 55f. Trabalho de Conclusão de Curso. (Curso de Extensão em Engenharia de Armamento Aéreo – CEEAA) – Instituto Tecnológico de Aeronáutica, São José dos Campos. PETERSON, James L. Petri Nets. Computing Surveys, v. 9, n. 3, p. 223-252, Sept. 1977.
134
PHILIPPI, Stephan. Automatic code generation from high-level Petri-Nets for model driven systems engineering. Journal of Systems and Software, v. 79, n. 10, p. 1444-1455, Oct. 2006. QUATRANI, Terry. Introduction to the Unified Modeling Language: A Technical discussion of UML. Rational Development Network, 2003. Disponível em: <http://www-128.ibm.com/developerworks/rational/library/998.html>. Acesso em 18 abr. 2006. RATIONAL SOFTWARE CORPORATION. Rational Rose RealTime Overview. Rational Rose RealTime Help (version 2003.06.00), 2003. RTCA Inc. and EUROCAE. DO-178B: Software considerations in airborne systems and equipment certification, Dec. 1992. RUMBAUGH, J.; JACOBSON, I.; BOOCH, G. The Unified Modeling Language Reference Manual. New York, NY: Addison-Wesley, 1999. SCHULMEYER, G. Gordon; MCMANUS, James I. (Ed.). Handbook of Software Quality Assurance. 2 ed. New York, New York: Van Nostrand Reinhold, 1992. 562 p. SIMPSON, H. R.; JACKSON, K. Process Synchronization in MASCOT. Computer Journal, v. 22, n. 4, p. 332-345, 1979. SPIVEY, J. M. The Z notation: a reference manual. Upper Saddle River, NJ: Prentice-Hall, 1989. 155 p. TAKAHASHI, Ryouei. Software Quality Classification Model Based On McCabe’s Complexity Measure. Journal of System and Software, v. 38, n. 1, p. 61-69, July 1997. The UAV industry. Air & Space Europe, v. 1, n. 5-6, p. 48-50, Sept.-Dec. 1999. UAVs: Launch and Recovery. Air & Space Europe, v. 1, n. 5-6, p. 59-62, Sept.-Dec. 1999. UNITED STATES. Department of Defense. Dictionary of military and associated terms. Joint Publication 1-02. 12 apr. 2001 (As Amended Through 17 September 2006). Disponível em: <http://www.dtic.mil/doctrine/jel/doddict/>. Acesso em 05 out. 2006. UNITED STATES. Department of Defense. Unmanned Aircraft Systems Roadmap: 2005-2030. Aug. 2005. Disponível em: < http://www.uavforum.com/library/library.htm>. Acesso em 05 out. 2006.
135
VANDOREN, Edmond. Cyclomatic Complexity. Carnegie Mellon University, 1997a. Disponível em: <http://www.sei.cmu.edu/str/descriptions/cyclomatic_body.html>. Acesso em: 07 mai. 2007. VANDOREN, Edmond. Halstead Complexity Measures. Carnegie Mellon University, 1997b. Disponível em: <http://www.sei.cmu.edu/str/descriptions/halstead.html>. Acesso em: 07 mai. 2007. VASCONCELOS, Yuri. Ajuda do céu. Revista FAPESP, n. 122, p. 72-75, 2006. WEISSMAN, Larry. Psychological Complexity of Computer Programs: An Experimental Methodology. ACM SIGPLAN Notices, v. 9, n. 6, p. 25-36, June 1974. WUYTS, Roel; DUCASSE, Stéphane; NIERSTRASZ, Oscar. A data-centric approach to composing embedded, real-time software components. Journal of Systems and Software, v. 74, n. 1, p. 25-34, Jan. 2005. YANG, Helen Hua; WILLIAMS, Shirley; MCCRINDLE, Rachel. Derivation of a Measurement for Defining Ideal Number of Comments in Code. Proceedings of the 21st IASTED International Conference, Applied Informatics, p. 1103-1108, Innsbruck, Austria, 2003. YANG, Hong Iris; ZHAO, Yiyuan J. Trajectory Planning for Autonomous Aerospace Vehicles amid Known Obstacles and Conflicts. Journal of Guidance, Control and Dynamics, v. 27, n. 6, p. 997-1008, Nov.-Dec. 2004.
FOLHA DE REGISTRO DO DOCUMENTO
1. CLASSIFICAÇÃO/TIPO
TM
2. DATA
12 de fevereiro de 2008
3. DOCUMENTO N°
CTA/ITA-IEM/TM-031/2007
4. N° DE PÁGINAS
135 5. TÍTULO E SUBTÍTULO: Modelagem e análise do software embarcado de piloto automático de um vant
6. AUTOR(ES):
Paulo Claudino Véras 7. INSTITUIÇÃO(ÕES)/ÓRGÃO(S) INTERNO(S)/DIVISÃO(ÕES): Instituto Tecnológico de Aeronáutica - Divisão de Engenharia Aeronáutica Mecânica - IEM
8. PALAVRAS-CHAVE SUGERIDAS PELO AUTOR:
Modelagem de software, UML, Redes de Petri, Vant 9.PALAVRAS-CHAVE RESULTANTES DE INDEXAÇÃO:
Desenvolvimento de software; Aeronave não-tripulada; Sistemas de computadores embarcados; Modelagem (processos); Avaliação de desempenho de software; Pilotos automáticos; UML; Ferramentas Case; Redes de Petri; Engenharia mecânica. 10. APRESENTAÇÃO: X Nacional Internacional
ITA, São José dos Campos, 2007, 135 páginas
11. RESUMO:
Entre as principais dificuldades do desenvolvimento de software de qualidade está a especificação e o projeto conceitual. Neste contexto, a modelagem de sistemas tem um papel importante, pois torna possível a análise das características do projeto e sua validação antes da fase de implementação. Esta tese aborda o problema de modelagem e análise do software embarcado de piloto automático de um VANT utilizando UML e a ferramenta CASE Rational® Rose® RealTime. A partir do modelo obtido são utilizadas três abordagens para sua análise e avaliação: (1) aplicação de um conjunto de métricas no código gerado pela ferramenta CASE; (2) integração do modelo implementado na ferramenta CASE com um simulador da dinâmica do VANT, desenvolvido em MatLab®, de forma a verificar o comportamento do sistema em malha fechada; e (3) conversão do modelo em UML para redes de Petri, um formalismo matemático que permite a verificação formal de propriedades do sistema.
12. GRAU DE SIGILO:
(X ) OSTENSIVO ( ) RESERVADO ( ) CONFIDENCIAL ( ) SECRETO
Livros Grátis( http://www.livrosgratis.com.br )
Milhares de Livros para Download: Baixar livros de AdministraçãoBaixar livros de AgronomiaBaixar livros de ArquiteturaBaixar livros de ArtesBaixar livros de AstronomiaBaixar livros de Biologia GeralBaixar livros de Ciência da ComputaçãoBaixar livros de Ciência da InformaçãoBaixar livros de Ciência PolíticaBaixar livros de Ciências da SaúdeBaixar livros de ComunicaçãoBaixar livros do Conselho Nacional de Educação - CNEBaixar livros de Defesa civilBaixar livros de DireitoBaixar livros de Direitos humanosBaixar livros de EconomiaBaixar livros de Economia DomésticaBaixar livros de EducaçãoBaixar livros de Educação - TrânsitoBaixar livros de Educação FísicaBaixar livros de Engenharia AeroespacialBaixar livros de FarmáciaBaixar livros de FilosofiaBaixar livros de FísicaBaixar livros de GeociênciasBaixar livros de GeografiaBaixar livros de HistóriaBaixar livros de Línguas
Baixar livros de LiteraturaBaixar livros de Literatura de CordelBaixar livros de Literatura InfantilBaixar livros de MatemáticaBaixar livros de MedicinaBaixar livros de Medicina VeterináriaBaixar livros de Meio AmbienteBaixar livros de MeteorologiaBaixar Monografias e TCCBaixar livros MultidisciplinarBaixar livros de MúsicaBaixar livros de PsicologiaBaixar livros de QuímicaBaixar livros de Saúde ColetivaBaixar livros de Serviço SocialBaixar livros de SociologiaBaixar livros de TeologiaBaixar livros de TrabalhoBaixar livros de Turismo
Top Related