A Figura 7.8 ilustra todos os mecanismos e procedimentos do MASS que foram imple- mentados e perfeitamente integrados à plataforma Aglets. O protótipo que implementa o conceito de teia de federações, adotado no MASS e proposto em Santin (2004), ainda não se encontrava totalmente implementado quando o protótipo do MASS foi desenvolvido. Como o mecanismo de controle social e a técnica para verificação da reputação das plataformas proposto no MASS dependem da infra-estrutura da teia de federações SPKI, estes não fo- ram implementados. Também por isto, a análise mais detalhada do histórico das plataformas
18A sintaxe definida pela Sun para o arquivo de configuração de política está disponível em
http://java.sun.com/j2se/1.4.2/docs/guide/security/PolicyFiles.html
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE policy SYSTEM "policy.dtd"> <policy>
<grant>
<privAttrib>messenger</privAttrib>
<description>messenger mobile agent</description> <permissionCollection> <permission> <java.io.SerializablePermission> <enableSubclassImplementation/> </java.io.SerializablePermission> </permission> <permission> <java.util.PropertyPermission PropertyPermissionActions="read, write"> <any>/home/config/savedAglets.props</any> </java.util.PropertyPermission> </permission> </permissionCollection> </grant> </policy>
Figura 7.7: Arquivo XML da Política SPKI conforme definida na Figura 7.6
visitadas por um agente, que também dependeria da teia de federação SPKI, não pôde ser realizada.
Plataforma de Origem
Plataforma Destino Protocolo Estabelcimento de Canal Seguro 2
Técnicas para Criação de Agentes Móveis Protegidos 1 Autenticador Multi-hop 3 Esquema para Geração de Domínios de Proteção 4 - Assinatura do código
- Repositório Somente-Leitura (RORepository) - Repositório de Resultados Parciais (PRRepository) - Repositório de Dados Direcionados (DDRepository) - Histórico de Plataformas Visitadas (PathRegister)
- Protocolo SSL - Autenticação Mútua agente assinado + certificados_autorização + registrador de caminhos + repositórios seguros
Figura 7.8: Mecanismos e Procedimentos do MASS Implementados no Protótipo
Visando melhorar a confiabilidade do protótipo do MASS, durante o seu desenvolvi- mento, procurou-se analisar a sua corretude através de atividades de verificação e validação (V&V) — testes de software20. Testar é um método dinâmico para verificação e validação em que o comportamento do sistema é observado pela execução do sistema (Jalote, 1991). Os níveis básicos de testes para tentar detectar diferentes tipos de falhas são: testes de unidade, testes de integração e testes de sistema e de aceitação. A relação das falhas introduzidas em diferentes níveis de testes é apresentada na Figura 7.9. O primeiro nível de teste, chamado
20Verificação é o processo que determina se os resultados (produtos) de uma determinada fase do desenvolvimento do
software preenchem as especificações dos requisitos estabelecidos durante a fase anterior e Validação é o processo que
avalia o software no final do seu processo de desenvolvimento para garantir a conformidade com os requisitos definidos para esse software (Jalote, 1991).
teste de unidade, é usado para testar a lógica interna dos módulos. Seu objetivo é detectar erros na codificação dos módulos (verificação). No próximo nível, chamado teste de inte- gração, módulos testados são combinados em sub-sistemas para então serem testados. O objetivo aqui é testar o projeto do sistema e então verificar as interações entre os módulos. Os próximos níveis são os testes de sistema e o de aceitação. Nestes níveis o sistema inteiro é testado, validando assim o sistema de acordo com os requisitos definidos para esse.
Necesidades do Cliente Requisitos Projeto Código Teste de Unidade Teste de Integração Teste de Sistema Teste de Aceitação
Figura 7.9: Níveis de Testes
Um documento básico para guiar o processo dos testes do protótipo do MASS — Plano de Testes — foi redigido visando especificar os níveis de testes, as unidades a serem testadas, os casos de testes (testcases), bem como a abordagem dos testes e o cronograma para execução dos testes. Dois tipos de testes foram executados: testes de unidade e testes de sistema. As unidades testadas foram: os objetos responsáveis pelo protocolo de autenticação mútua, os objetos que implementam as técnicas para criação de agentes móveis protegidos e a auten- ticação de agentes móveis e os objetos responsáveis pelo processo de geração de domínios de proteção. Os testes de unidades seguiram uma abordagem estrutural (teste caixa-branca), tendo como critério a cobertura de ramos (execução de caminhos lógicos dos módulos) e foram aplicados nos agentes estacionários (AuthenticatoreSecurityInterceptor), nos repositórios seguros de dados (RORepository,DDRepositoryePRRepository), no objeto que representa a política de segurança (SPKIPolicy) e nas interfaces gráficas que auxiliam a configuração do esquema de segurança e o seu uso (SPKIPolicyTool, QOPSettings e AgletsPropertiesSettings)21.
Os testes de sistema realizados seguiram a abordagem funcional (teste caixa-preta) com o objetivo de verificar os requisitos e especificações do protótipo. Os métodos utilizados foram o particionamento de classes de equivalência (utilização de um conjunto de valores válidos e inválidos), a análise de valores limites e de conjuntos de dados especiais e os grafos de causa-efeito para testar combinações de entradas.
Todas as faltas e erros detectados nos testes de software foram corrigidos. A documenta- ção dos testes de software do protótipo do MASS, que compreende o plano de testes e os re- latórios dos testes de unidade e de sistema, está disponível emhttp://www.das.ufsc.br/ AgenteSeg/testes. A documentação do código-fonte Java (em arquivos HTML) foi ge- rada com o utilitáriojavadocdo Java 2 e está disponível emhttp://www.das.ufsc.br/ AgenteSeg/javadoc.