Instituto
Tecnológico de Aeronáutica
Divisão de Ciência da Computação
CE-230
Qualidade, Confiabilidade e
Segurança de Software
Prof. Dr. Adilson M. Cunha
Exame
Projeto Final – Protótipo de Veículo Autônomo - PVA
Aluno: Walter Abrahão dos Santos
30 de Novembro-2004
I . Introdução
1.1
Motivação
Visando proporcionar uma experiência hands-on na disciplina CE-230 (Qualidade, Confiabilidade e Segurança de Software) busca-se aplicar os conceitos e as metodologias fundamentais adquiridos para o caso de estudo do veículo autônomo - PVA (Protótipo de Veículo Autônomo) - capaz de realizar missões pré-programadas dentro de um ambiente pré-definido, vide [Martins04] para detalhes do PVA.
A importância dos conceitos Qualidade, Confiabilidade e Segurança de
Software é evidente quando hoje se nota que sistemas embarcados possuem CPUs
que em número superam a população humana e exercem um papel crescente nas vidas
de cada ser humano. [Storey96].
Com este objetivo em mente, motiva-se a familiarização e utilização dos
seguintes dispositivos:
- Artefatos
e metodologia do RUP – Rational Unified Process,
- Ferramentas
I-CASE-E (Integrated CASE Environment),
- Métricas para
Qualidade, Confiabilidade e
Segurança de Software e
- Modelagem
UML para RT.
A principal necessidade apresentada é a familiarização com a utilização
de ferramentas I-CASE-E (Rose RT [Rose03],
Together [Together04], etc) que são
ambientes de desenvolvimento de software com funcionalidades diversas, dentre
elas para Qualidade de Software.
1.2 Contexto
O texto, a seguir, foi o mesmo utilizado em CE-235 (Sistemas Embarcados de
Tempo Real) para a prospecção de entidades, classes, ou objetos de interesse do
sistema de software uma vez que, para fins de testes, as mesmas variáveis estarão
em jogo.
“ O PVA irá receber uma missão via interface wireless ao
MCM (Módulo Central de Monitoramento) através de um protocolo
pré-definido. Missões podem ser carregadas e enfileiradas numa fila de
missões para serem tratadas posteriormente.
O PVA possui como atuadores dois motores (direito e esquerdo)
para se locomover e dispõe de um sensor de proximidade para acusar obstáculos,
um sensor de Way-point para detectar pontos chaves na missão (carga,
descarga) e de dois sensores de rota (direito e esquerdo) para auxílio à
navegação e correção de rota.
Ao receber uma missão, o PVA se dirige a ponto de carga onde um
dispositivo carregador realiza a carga de um objeto que deverá ser
entregue a um ponto único de descarga.
Regularmente, o PVA envia status para o MCM informando dados
referentes a seu estado interno, obstáculos e missão. Na presença de
um obstáculo, o PVA notifica o MCM e aguarda sinalização do mesmo para a
remoção do obstáculo e retomada da missão. ”
1.3
Objetivação do Protótipo de Sistemas de Software com Qualidade
O objetivo primordial do protótipo de sistema de software com Qualidade
do PVA é garantir a qualidade, a confiabilidade e a segurança (safety)
no funcionamento do PVA de forma a diminuir custos de desenvolvimento e
manutenção do software. Para tal são implementados testes de forma a cobrir todos
cenários possíveis de operação do PVA, vide detalhes na seção 1.5.
1.4 Redução do Escopo
Da disciplina CE-235, para fins de praticidade serão assumidas as
seguintes simplificações:
- O PVA
deverá ter um buffer limitado de missões;
- Obstáculos
presentes na rota do PVA serão removidos mediante notificação ao MCM;
- O PVA não
dispõe de freios, pois para frenagem simplesmente remove potência de seus
motores;
- O PVA
possui uma interface dedicada para comunicação wireless com o MCM e
recebe apenas uma cadeia de caracteres como status;
- Para
navegação será adotada uma fita com fundo de contraste para sinalização;
- O
carregador lidará com detalhes de carga de objetos no PVA;
1.5 Especificação
de Requisitos
A seguir é descrita e refinada a especificação de requisitos do PSVA
(Protótipo de Sistema de Veículo Autônomo) com ênfase a aspectos de Qualidade,
Segurança e Confiabilidade.
O PSVA deverá ser submetido a testes de forma a propiciar:
1.5.1 A recepção de
sinais de localização do tipo lat/long via um GPS embarcado.
1.5.2 A transmissão
para o MCM, em Tempo Real (t <= 3´´), de sinais de status (localização,
estado interno de sensores e atuadores, informações sobre a missão, etc).
1.5.3 A recepção de
informações do MCM sobre missões atribuídas ao PVA, tipicamente ponto de carga
em termos de lat/long.
1.5.4 O controle de
navegação do PVA em Tempo Real (t <= 1´´).
1.5.5 O cumprimento
da missão de localizar, identificar, transportar e entregar cargas.
1.5.6 A leitura de
sensores e o comando de atuadores.
1.5.7 A simulação das condições de falha e verificação dos processos de recuperação (manuais e automatizados) para restaurar o estado conhecido e desejado do sistema.
Os seguintes tipos de condições estão incluídos no teste para observar e registrar o comportamento-alvo após a recuperação:
· Interrupção da energia para o CPU;
· Interrupção da comunicação com sensores e atuadores;
· Sensores e atuadores com problemas;
· Perda/interferência na comunicação com o módulo MCM;
· Ciclos incompletos (dados interrompidos, processos de sincronização de dados interrompidos) e
· Elementos de dados inválidos ou corrompidos entre as interfaces.
1.5.8 Verificação da instalação de firmware no hardware do PVA nas condições a seguir pra observar e registrar o comportamento da instalação:
· Nova instalação: um novo PVA, em que nunca foi instalado anteriormente o SPVA.
· Atualização: um PVA em que foi instalado anteriormente o SPVA, na mesma versão.
·
Atualização: um PVA em que foi instalado anteriormente
o SPVA, em uma versão mais antiga.
1.6 Ordem
de Apresentação do Projeto Final
1.6.1 Na Seção 1 (Introdução), apresenta-se a
Motivação, o Contexto, Objetivação do Protótipo de Sistemas de Software com
Qualidade, a Redução do Escopo e a Especificação de Requisitos deste Projeto
Final.
1.6.2 Na Seção 2
(Desenvolvimento) descreve-se a Linha Base Funcional e a Linha Base Alocada e a
Linha Base de Produto de Qualidade dentro de cada fase do RUP (Rational
Unified Process).
1.6.3 Na Seção 3
(Conclusões e Recomendações), são sintetizadas as principais conclusões,
recomendações e sugestões para aperfeiçoamento deste Protótipo e para a
melhoria dessa disciplina.
1.6.4 Finalmente, são
inclusas as referências bibliográficas e anexos.
II. Desenvolvimento
Para cada Fase do RUP, será reportada a consolidação do material que foi produzido, na Linha Base Funcional e na Linha Base Alocada. Para detalhes sobre os artefatos produzidos vide os portais de documentação do projeto [Dos-Santos04] e [Itami04].
2.1 Linha Base Funcional
A Linha Base Funcional enfoca a 1ª Fase de Iniciação
(Inception) do RUP onde foi gerada uma série de artefatos abordando aspectos
de Qualidade, Confiabilidade e Segurança do Protótipo de Software do Grupo, a
saber: Plano de Testes,
Casos de Teste e Estimativa de Esforços por Pontos de Casos de Uso.
O Plano de Testes tem por finalidade reunir todas as informações necessárias ao planejamento e ao controle do esforço de teste referente ao PSVA (Protótipo de Sistema de Veículo Autônomo). O Plano de Teste visa atender aos seguintes objetivos:
· Apresentar as técnicas, tipos e estratégias de teste a serem utilizadas;
· Identificar os itens-alvo que devem ser testados;
· Descrever o fluxo de trabalho dos testes e respectivos critérios de entrada e saída;
· Identificar os recursos necessários e fornecer uma estimativa dos esforços de teste necessários e
· Listar os produtos liberados do Projeto de Teste.
O Plano de Testes abrange diversos níveis de testes: Unidade, Integração e Sistema. Também aborda os vários tipos de testes: funcionalidade, usabilidade, confiabilidade e desempenho. Como alvo dos testes, são citadas as seguintes interfaces:
· Interface de Comunicação RF
· Interface dos Motores
· Interface dos Sensores
· Memória dos Dados da Missão
· Processamento de Missões
Os seguintes testes são
abordados no Plano de Testes: (a) Teste de Função do PSVA, (b) Teste de
Interface com MCM, (c) Teste de Interface com o Hardware do PSVA, (d)
Determinação do Perfil de Desempenho, (e) Teste de Tolerância a Falhas e de
Recuperação e (f) Teste de Instalação.
Os
Casos de Testes tem por finalidade
identificar e comunicar formalmente as condições específicas detalhadas que
serão validadas para permitir a avaliação de determinados aspectos dos Itens de
Teste-alvo. Os Casos de Teste podem ser motivados por vários fatores, mas
normalmente incluem um subconjunto dos Requisitos (Casos de Uso,
características de desempenho etc.) e dos riscos envolvidos no projeto.
Um dos Casos de Testes é referente ao
teste unitário que é implementado com base no menor elemento testável
(unidades) do software e implica em testar a estrutura interna (como fluxo
lógico e de dados), a função da unidade e os comportamentos observáveis. O
design e a implementação de testes com ênfase na estrutura interna de uma
unidade se baseiam no conhecimento da implementação da unidade (abordagem caixa
branca). No entanto, o design e a implementação de testes com a finalidade de
verificar os comportamentos observáveis e as funções da unidade não se baseiam
no conhecimento da implementação; por isso, são conhecidas como abordagem caixa
preta. Os Casos de Testes
Unitários são definidos quando estiverem fechados e aprovados os documentos que
definem os elementos de software (classes e objetos) que serão desenvolvidos e
implementados. Para detalhes referir-se a [Itami04].
Finalmente, a
Estimativa de Esforços por Pontos de Casos de Uso
fornece, em Homem x horas (Hxh), os esforços necessários para o desenvolvimento
do PSVA. A estimativa foi realizada através da metodologia de Pontos de Caso de
Uso, tendo por base o artefato de Casos de Uso produzido pela Equipe de
Desenvolvimento (Disciplina CE235).
Para apoiar a
elaboração das estimativas, foi implementada uma planilha, baseada nos passos
vistos em aula para determinação do esforço e em artigos disponibilizados no
portal em [Cunha04]. Para apresentação das partes mais significativas da
planilha com os cálculos necessários para as estimativas e o resultado final
referir-se a [Itami04].
2.2 Linha Base Alocada
A Linha Base Alocada enfoca a 2ª Fase – Elaboração (Elaboration) e 3ª Fase - Construção (Construction) do RUP onde foram desenvolvidos artefatos das diversas visões do projeto do PSVA, da visão de Casos de Uso até a visão de Deployment. A abordagem é voltada para aspectos de Qualidade, Confiabilidade e Segurança do Protótipo de Software.
Para esta fase será dado maior enfoque ao Caso de Uso
“VerificarObstáculo” e seus diagramas detalhados, a saber:
·
Um Caso de
Teste Estendido;
·
Um Diagrama de
Seqüência (focando Testes);
·
Um Diagrama de
Classe integrado com os Diagramas de Classes dos demais do Grupo, focando Testes;
·
Um Diagrama de
Transição de Estado focando Testes;
·
A partir de
Fragmentos de Códigos-Fonte gerados, deverá ser utilizado 03 (três) Métricas
para medir Qualidade, Confiabilidade e / ou Segurança de Software e
· Uma Análise de Sensitividade de Software e uma Análise de Traçabilidade de Requisitos.
Os diagramas citados anteriormente são ilustrados, um a um, a seguir.
1. DESCRIÇÃO Este Caso de Uso ocorre durante a
execução de missões no qual o PVA necessita constantemente verificar a
existência de obstáculos a sua frente. Caso seja detectado, via o Sensor de
Proximidade, a presença de algum objeto na frente do PVA, é enviado um
comando de parada ao PVA seguido de um comunicado do incidente ao MCM. O
veículo só retomará a missão com a desobstrução de seu caminho que é
percebida pelo mesmo sensor. Para fins de testes foram inclusos procedimentos
de autoteste tanto do leitor de status (VerificarObstaculo) quanto do
sensor de proximidade e os possíveis cenários discutidos a seguir. 2. FLUXO
DE EVENTOS
2.1 FLUXO BÁSICO PARA
TESTE Cenário:
Sensor de proximidade e cápsula operacionais 2.1.1 PVA pede inicialização da cápsula 2.1.2 Cápsula autotesta e esta retorna OK 2.1.3 Capsula
testa sensor de proximidade e este retorna OK 2.1.4 O sensor de proximidade detecta um
obstáculo 2.1.5 PVA lê sensor e acusa obstáculo 2.1.6 PVA informa presença de obstáculo ao
MCM 2.1.7 MCM remove obstáculo e sinaliza
desobstrução 2.1.8 Sensor de proximidade detecta
desobstrução 2.1.9 PVA retoma missão 2.2 FLUXOS
ALTERNATIVOS PARA TESTE Cenário
1: Cápsula com erro de execução e
sensor de proximidade operacional 2.2.1.1
PVA pede inicialização 2.2.1.2
Cápsula autotesta e retorna NOK 2.2.1.3 Missão do PVA é abortada Cenário
2: Cápsula com erro de execução e sensor de proximidade não-operacional 2.2.2.1
PVA pede inicialização 2.2.2.2
Cápsula autotesta e retorna NOK 2.2.2.3 Cápsula testa sensor de proximidade que
retorna NOK 2.2.2.4 Missão do PVA é abortada Cenário
3: Cápsula operacional mas sensor de proximidade não-operacional 2.2.1.1
PVA pede inicialização 2.2.1.2
Cápsula autotesta e retorna OK 2.2.1.3 Missão do PVA é abortada 3. REQUISITOS
ESPECIAIS Sensor
de proximidade operacional (não defeituoso) Cápsula
operacional (sem bugs) 4. PRÉ-CONDIÇÕES 4.1 PVA possui uma missão em execução. 4.2 Autoteste de sensor e de leitor concluidos 4.3 Leitor inicializado 4.4 Sensor de proximidade detecta obstáculo. 5. PÓS-CONDIÇÕES Sensor
de proximidade acusa desobstrução. PVA
retoma missão. 6. PONTOS
DE EXTENSÃO Nenhum.
Figura 1 – Descrição textual do Caso de Teste Estendido para PSVA.
