MODELAGEM E ANÁLISE DO SOFTWARE …livros01.livrosgratis.com.br/cp109012.pdfembarcado de piloto...

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




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


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


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


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


Calculate Rudder Positioning


Calculate Elevator Positioning


Adjust Attitude


<<include>><<include>> <<include>><<include>>

<<include>><<include>><<include>><<include>>

Send Output Data


Motor

RudderAilerons

Signal Converter

Elevator

Pilot

Guidance

Receive Input Data


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


/ guidanceR1 : Guidance


/ gPSR1 : GPS


/ 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



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



/ signal_ConverterR1 : Signal Converter





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



/ pilotR1 : Pilot / pilotR1 : Pilot


/ gPSR1 : GPS

/ gPSR1 : GPS



/ 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).




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”







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



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


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.







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


FalseInitial False

True

TrueTrue

mode_received

False False

True


True

calculating

False

True


Mode2Mode2


FalseInitial False

True

TrueTrue

mode_received

False False

True


True

calculating

False

True

Mode 0?Mode 1?

Mode 2?FalseFalse


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






3: calculate elevator command3: calculate 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





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


FalseInitial False

True

TrueTrue

mode_received

False False

True


True

calculating

False

True


Mode2Mode2


FalseInitial False

True

TrueTrue

mode_received

False False

True


True

calculating

False

True

Mode 0?Mode 1?

Mode 2?FalseFalse


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










http://www.livrosgratis.com.br/cat_1/administracao/1







http://www.livrosgratis.com.br/cat_2/agronomia/1







http://www.livrosgratis.com.br/cat_3/arquitetura/1







http://www.livrosgratis.com.br/cat_4/artes/1







http://www.livrosgratis.com.br/cat_5/astronomia/1







http://www.livrosgratis.com.br/cat_6/biologia_geral/1









http://www.livrosgratis.com.br/cat_8/ciencia_da_computacao/1











http://www.livrosgratis.com.br/cat_9/ciencia_da_informacao/1











http://www.livrosgratis.com.br/cat_7/ciencia_politica/1









http://www.livrosgratis.com.br/cat_10/ciencias_da_saude/1











http://www.livrosgratis.com.br/cat_11/comunicacao/1







http://www.livrosgratis.com.br/cat_12/conselho_nacional_de_educacao_-_cne/1















http://www.livrosgratis.com.br/cat_13/defesa_civil/1









http://www.livrosgratis.com.br/cat_14/direito/1







http://www.livrosgratis.com.br/cat_15/direitos_humanos/1









http://www.livrosgratis.com.br/cat_16/economia/1







http://www.livrosgratis.com.br/cat_17/economia_domestica/1









http://www.livrosgratis.com.br/cat_18/educacao/1







http://www.livrosgratis.com.br/cat_19/educacao_-_transito/1









http://www.livrosgratis.com.br/cat_20/educacao_fisica/1









http://www.livrosgratis.com.br/cat_21/engenharia_aeroespacial/1









http://www.livrosgratis.com.br/cat_22/farmacia/1







http://www.livrosgratis.com.br/cat_23/filosofia/1







http://www.livrosgratis.com.br/cat_24/fisica/1







http://www.livrosgratis.com.br/cat_25/geociencias/1







http://www.livrosgratis.com.br/cat_26/geografia/1







http://www.livrosgratis.com.br/cat_27/historia/1







http://www.livrosgratis.com.br/cat_31/linguas/1







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

http://www.livrosgratis.com.br/cat_28/literatura/1







http://www.livrosgratis.com.br/cat_30/literatura_de_cordel/1











http://www.livrosgratis.com.br/cat_29/literatura_infantil/1









http://www.livrosgratis.com.br/cat_32/matematica/1







http://www.livrosgratis.com.br/cat_33/medicina/1







http://www.livrosgratis.com.br/cat_34/medicina_veterinaria/1









http://www.livrosgratis.com.br/cat_35/meio_ambiente/1









http://www.livrosgratis.com.br/cat_36/meteorologia/1







http://www.livrosgratis.com.br/cat_45/monografias_e_tcc/1







http://www.livrosgratis.com.br/cat_37/multidisciplinar/1





http://www.livrosgratis.com.br/cat_38/musica/1







http://www.livrosgratis.com.br/cat_39/psicologia/1







http://www.livrosgratis.com.br/cat_40/quimica/1







http://www.livrosgratis.com.br/cat_41/saude_coletiva/1









http://www.livrosgratis.com.br/cat_42/servico_social/1









http://www.livrosgratis.com.br/cat_43/sociologia/1







http://www.livrosgratis.com.br/cat_44/teologia/1







http://www.livrosgratis.com.br/cat_46/trabalho/1







http://www.livrosgratis.com.br/cat_47/turismo/1







MODELAGEM E ANÁLISE DO SOFTWARE …livros01.livrosgratis.com.br/cp109012.pdfembarcado de piloto...

Documents

Transcript of MODELAGEM E ANÁLISE DO SOFTWARE …livros01.livrosgratis.com.br/cp109012.pdfembarcado de piloto...